cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
6,901 Views
Registered: ‎10-17-2016

Block memory (64bit wide) skips every other value

Jump to solution

I am working on an Zynq UltraScale+ MPSoC (zcu102 ES2 board) and I'm trying to write 64 bit values to a Block Memory.

 

My block design is as  follows:
- AXI BRAM Controller with 64 bit data width, 131072 Memory Depth, no ECC.

- Block Memory Generator in 'BRAM Controller' mode, 'True Dual Port RAM'

 

AXI-64bit_problem.png

The additional connections you see in the screen shot lead to the ILA core for debugging.

 

When I write a sequence of 64bit values to this memory block, every second value is not written to the memory. To investigate the source of the problem, I added an ILA core and traced the address, data, en and we signals.

The traced waveform shows:
- the address is correctly set for every value.

- the we (byte select) is only asserted for every other value.

- the en (enable) is asserted for every value at the same time the address is valid

- the data is kept stable during two address/enable cycles, every other value is skipped.

bram_wave.png

 

Is this a known issue with the UltraScale+? Since the cores are all marked as pre-production: are they verified or is it possible that there are bugs?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
671 Views
Registered: ‎10-17-2016

Just an update to point other users to the actual solution of this problem:

I had not updated the hardware description of the petalinux project. In consequence, the AXI bus had an incorrect width set in the device tree.

 

You always need to update the hardware description in your petalinux project in order for the device tree to reflect the changes.

View solution in original post

0 Kudos
12 Replies
Highlighted
Scholar
Scholar
6,879 Views
Registered: ‎03-22-2016
Hmm f8e4 is not 64-bit aligned. That might be the problem. Try with an aligned address.
vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Highlighted
Adventurer
Adventurer
6,833 Views
Registered: ‎10-17-2016
Thank you for the suggestion, but that is part of the data, not the address. The address is the fourth row to be seen in the waveform, they are 0x00, 0x08, 0x10 and so on.
0 Kudos
Highlighted
Scholar
Scholar
6,825 Views
Registered: ‎03-22-2016

@welo_zhaw what happens when you try to set 32-bit sequences?

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Highlighted
Adventurer
Adventurer
6,772 Views
Registered: ‎10-17-2016

I traced a transfer of 32bit values, looks just as expected and the incorrect behaviour persists:
- transfers occur correctly to 128 bit aligned addresses, with expected byte enables and addresses for the lower and the upper 32 bit words

- when writing to a 64-bit aligned address, byte enables and data are not set, only address and enable are correct.

 

Expected sequence of data would be:
0000: 00000000 00020000
0008: 00001947 0001FE37
0010: 00003209 0001F8E4
0018: 000049C7 0001F026

 

bram_wave_32_bit.png

 

To describe my setup a bit more in detail:

- Using the AXI HMP0 LPD interface of the Zynq UltraScale+, Data Width is set to 64 bit

- AXI Interconnect uses 64 bit wide data bus

- Four slaves connected to AXI interconnect, two have 64bit data width, the other two 32bit.

0 Kudos
Highlighted
Adventurer
Adventurer
6,748 Views
Registered: ‎10-17-2016

Is there any way I can file a bug report? I have upgraded to Vivado 2017.2 to verify the problem persists and it is still present.

0 Kudos
Highlighted
Adventurer
Adventurer
6,740 Views
Registered: ‎10-17-2016

AXI interconnect to AXI BRAM controller

I have now traced the AXI4 interface between the AXI interconnect and the AXI BRAM Controller. The same behaviour is shown here. See the below waveform.

AXI-64bit_problem_interconnect.png

 

Zynq PS to AXI interconnect

Between the Zynq PS and the AXI4 interconnect, the same error applies. This seems to be a serious bug, how can I report it?

Tags (2)
0 Kudos
Highlighted
Adventurer
Adventurer
6,717 Views
Registered: ‎10-17-2016

Still looking for a solution...

I checked the device tree and I think I found a problem:

axi_bram_ctrl_input: axi_bram_ctrl@82000000 {
compatible = "xlnx,axi-bram-ctrl-4.0";
reg = <0x0 0x84000000 0x0 0x100000>;
xlnx,bram-addr-width = <0x11>;
xlnx,bram-inst-mode = "EXTERNAL";
xlnx,ecc = <0x0>;
xlnx,ecc-onoff-reset-value = <0x0>;
xlnx,ecc-type = <0x0>;
xlnx,fault-inject = <0x0>;
xlnx,memory-depth = <0x20000>;
xlnx,s-axi-ctrl-addr-width = <0x20>;
xlnx,s-axi-ctrl-data-width = <0x20>;
xlnx,s-axi-id-width = <0x10>;
xlnx,s-axi-supports-narrow-burst = <0x1>;
xlnx,select-xpm = <0x0>;
xlnx,single-port-bram = <0x1>;
};

The device tree source was generated using the XSDK. The S-AXI data width (xlnx,s-aci-ctrl-data-width) is set to 0x20 = 32 bit. The AXI Interconnect and the AXI BRAM Controller are both 64bit wide. Can anyone confirm that this is correct?

I have manually changed the dts to set the data width to 64bit and rebuilt the petalinux system. The entry at /proc/device-tree/amba_pl@/axi_bram_ctrl@82000000 show a data width of 64bit, but the trace of the AXI Interface still shows the same behaviour: all writing operations to non-128bit-aligned adresses fail.

I have no more ideas where the problem could be coming from. Any help would be appreciated!

Any Xilinx employees?

0 Kudos
Highlighted
Adventurer
Adventurer
10,390 Views
Registered: ‎10-17-2016

I finally found a fix for this:

The AXI HPM0 FPD Data Width in the Zynq PS block must be set to 128 bit, even if you are only going to connect 64 bit wide memories to it.

With this setting, the device tree still shows a data width of 0x20 which is strange, but at least the 64bit transfers work to all addresses.

Highlighted
4,329 Views
Registered: ‎05-05-2018

I had a similar problem and I fixed it with your workaround. Thank you @welo_zhaw
Now I find a problem with the slave HP AXI ports. I have a master in the PL that have to access the data in the DDR through a 64 bit AXI interconnect connected to the S_AXI_HP0_FDP port. It access correctly only the words in location for which address ends with 0.
For example:
0x0000 -> ok
0x0008 -> not ok
0x0010 -> ok
0x0018 -> not ok
...
If I try to read the content of a location ending with 8 I get the content of the previous location.

 

I solved this problem with a similar workaround setting the port width to 128 and adding a width converter.

0 Kudos
Highlighted
Adventurer
Adventurer
3,288 Views
Registered: ‎10-17-2016
Gianfranco, I found out that the board support package does not get updated automatically by petalinux. This was the actual cause of my problem. You need to manually re-import the board support package into your linux project.
0 Kudos
Highlighted
Visitor
Visitor
695 Views
Registered: ‎11-21-2019

Similar problem in another thread; bumping this one in hopes one of the previous responders will have insight. Thanks!

https://forums.xilinx.com/t5/Memory-Interfaces-and-NoC/64-bit-SDRAM-access-from-PL-on-ZCU-102-board-reads-wrong-value/m-p/1067300 

0 Kudos
Highlighted
Adventurer
Adventurer
672 Views
Registered: ‎10-17-2016

Just an update to point other users to the actual solution of this problem:

I had not updated the hardware description of the petalinux project. In consequence, the AXI bus had an incorrect width set in the device tree.

 

You always need to update the hardware description in your petalinux project in order for the device tree to reflect the changes.

View solution in original post

0 Kudos