A developer is experiencing issues writing 16-bit data to Block RAM (BRAM) on a Xilinx Virtex-5 board using a PowerPC processor. While writes to 4-byte aligned addresses succeed, writes to 2-byte aligned addresses (e.g., 0x00000002) fail to update the memory as expected.
The discussion explores potential causes including VHDL register assignments, byte-enable signals on the Processor Local Bus (PLB), and C-code data type definitions for memory-mapped I/O.
- The user confirmed that 4-byte aligned addresses work correctly but intermediate 2-byte offsets do not trigger the expected write operations.
- Hardware logic was modified to use hardcoded values (e.g., F0F0, F2F2) to verify which specific address triggers are reaching the BRAM.
- The 32-bit Bus2IP_Addr is being trimmed to 17-bits for the 80k depth memory, which may affect how sub-word addressing is handled.
- The group investigated whether the C 'short' data type and PLB byte-enable (BE) signals are correctly aligned with the VHDL slv_reg logic.
Hello,
I am currently working on a Xilinx development board that has PowerPC and virtex 5. I used Xilinx core generator to instantiate a bram with data width size of 2.
From a C program running on the PowerPC, I have no trouble accessing the bram if the memory address is multiple of 4. However, I cannot write to the memory if the address is a multiple of 2 (but no multiple of 4, for example 0x00000002, 0x00000006).
If I run the program along with this vhdl file, and look at the memory location using mrd, I get the following:
mrd 0x41000000 10
41000000:0000F0F0 [ I would expect this to be F2F2F0F0]
41000004:0000F4F4
41000008:00000000
4100000C:00000000
Any help is greatly appreciated. Thank you very much.user_logic.vhd
I am just getting into this exact topic, myself, so I probably don't have any real insights.
However, I noticed that on line 263 of the VHDL, and 290-295, you have the "0100..." operations commented out. If I'm reading it correctly, this is 2's place operations.
Could this be related? If not, why are those lines commented?
I assume you are talking about the lines:
----when "01000000000000000000" =>
----for byte_index in 0 to (C_SLV_DWIDTH/8)-1 loop
----if ( Bus2IP_BE(byte_index) = '1' ) then
----slv_reg1(byte_index*8 to byte_index*8+7) <= Bus2IP_Data(byte_index*8 to byte_index*8+7);
----end if;
Those lines are used to write to the register slv_reg1 through the PLB. I commented those lines out because I was using slv_reg1 as status register for the dividedby2 module's output. If I don't comment these lines out, I would get an error because of multiple sources.
Ok--thanks. Was just wondering (since I'm new). What about the C-code for the host machine? Have you confirmed that there's no problem there?
It's good to discuss this along with someone since I may miss something obvious.
The C code is just the following:
short *addr = 0x41000000; *addr = 1; // This will trigger writing F0F0 to address 0x41000000 since I hardcoded the F0F0 in the vhdl code.
addr = 0x41000002; *add = 2; // This supposed to trigger writing F2F2 to address 0x41000002 but never got written
addr = 0x41000004; *add = 3; // This will trigger writing F4F4 to address 0x41000004 since I hardcoded the F4F4 in the vhdl code.
These were verified by the xmd command mrd (memory read).
In C the short data type is usually 16 bits. In the above code it seems it is 32 bits. May be addr could be declared as int.
The address itself should be 32-bit and for PLB, the Bus2IP_Addr is 32-bit also.
Inside the vhdl code, it trims the 32-bit address to 17-bit address needed by the memory (need 17-bit address for 80k memory depth).
I have tested that if I set addr = 0x41000001 (in C), the Bus2IP_Addr will get the same number, and when I trim it down to 00....01 as input to bram, the write doesn't seem to happen.
