AXI4 -> Litedram write mask issue
Dolu1990 opened this issue · comments
Hi, currently testing stuff with the following config :
AXI4 64 bits -> digilent nexys video DDR (16 bits physical, 128 bits access bus)
Things seems to mess up between lower and upper 64 bits of the 128 access bus (likely due to data mask ?)
Here are the symtoms is got, by reading sdcard in linux :
hexdump -C -s 5120000 -n 512 /dev/mmcblk0
Gives me on litex SoC
004e2000 c6 01 a3 00 66 00 23 01 00 10 00 00 00 65 47 69 |....f.#......eGi|
004e2010 b6 00 23 03 d6 00 a3 03 00 10 00 00 00 65 47 69 |..#..........eGi|
004e2020 82 80 49 55 82 80 97 a7 00 10 00 00 00 65 47 69 |..IU.........eGi|
Should have been :
004e2000 87 00 23 02 a6 00 23 00 c6 01 a3 00 66 00 23 01 |..#...#.....f.#.|
004e2010 16 01 a3 01 06 01 a3 02 b6 00 23 03 d6 00 a3 03 |..........#.....|
004e2020 e6 00 23 04 f6 00 21 45 82 80 49 55 82 80 97 a7 |..#...!E..IU....|
As you can see there is two cumulating alteration :
- upper 64 bits is apparently written on lower 64 bits
- readed upper 64 bits seems trashed
I probed the AXI4 bus, and it look good, mbus of:
iladata.vcd.zip
Main issue is i have no easy way for you to reproduce, unless you have a digilent video card and are willing to run alternative branches, the ideal would be instead to have a simulation which write into the DDR using the AXI4 dma-bus i would say. But i have no idea how to setup it.
Here is the Litex toplevel for reference
Uploading digilent_nexys_video.v.zip…
So how can we proceed to track that bug ?
let's me know if you want me to probe more buses inside the FPGA, maybe the litedram one ? what bus would it be in the above verilog ?
@gsomlo lolol
You have the same symptomes as me, especialy the :
00001b0 7b5b 0558 0000 2000 2efc 804f ffff ffff
00001c0 0000 0000 0040 3500 2efc 804f ffff ffff
00001d0 0040 5170 1cdc 0000 2efc 804f ffff ffff
00001e0 0000 0000 0000 0000 2efc 804f ffff ffff
00001f0 0000 0000 0000 aa55 2efc 804f ffff ffff
(i was testing with NaxRiscv + sdcard with DMA coherency)
So, yes, we hit the same issue i think. I guess the upsizer is at fault ?
Looking at the AXI4 upsizer code, i can see :
# W Channel.
w_converter = stream.StrideConverter(
description_from = [("data", dw_from), ("strb", dw_from//8)],
description_to = [("data", dw_to), ("strb", dw_to//8)],
)
self.submodules += w_converter
self.comb += axi_from.w.connect(w_converter.sink, omit={"id", "dest", "user"})
self.comb += w_converter.source.connect(axi_to.w)
self.comb += axi_to.w.id.eq(axi_from.w.id)
self.comb += axi_to.w.dest.eq(axi_from.w.dest)
self.comb += axi_to.w.user.eq(axi_from.w.user)
Thing is, that code does not seem to take in acount the alignement of the AW channel address, which is i think the issue.
Can't make an AXI upsizer without the W channel checking the alignement of the address.
Let's close this issue and continue on your one