AXI4 -> Litedram write mask issue

[Dolu1990]

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]

@Dolu1990 , do you think there's any chance whatsoever this might be loosely related to what I've experienced in #1753 ?

I'm (slowly) working my way up to coming up with a plan to troubleshoot that, but there are lots of "moving parts" (and, therefore, potential suspects) :)

[Dolu1990]

@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.

[Dolu1990]

Let's close this issue and continue on your one