Axi port write data error

[Yuxin-Yu]

Hello, my application scenario requires a DDR3 controller with axi interface, so I generated my DDR3 source code based on the stlv7325 development board. However, even if DDR3 initialization is successful during use, there may be issues with DDR reading and writing data failure.
In order to verify the data read and write issues of the axi interface, I connected the axi interface of the litedram core to the official mig example of xilinx. After successful DDR initialization, I found that the axi interface of the litedram core can read data normally, as follows:

However, the write data failed, and the write preparation signal remained low, as follows:

From the picture, it can be seen that the writing error signal write_err has also been raised. May I ask if this is due to the different functions of the Litedram core and Mig design, which caused the testing to fail in the official Mig testing example of Xilinx, or is it because I overlooked which part was not set properly?

[Yuxin-Yu]

@enjoy-digital

[Qiange516]

If you are emulating a litedram_core alone, you need to initialize the core, that is, you need to read and write the wishbone bus. Take a look at this article, it may help you：https://blog.csdn.net/weixin_46423500/article/details/130983066

[Yuxin-Yu]

If you are emulating a litedram_core alone, you need to initialize the core, that is, you need to read and write the wishbone bus. Take a look at this article, it may help you：https://blog.csdn.net/weixin_46423500/article/details/130983066

Hello, thank you for your reply. In fact, I have already implemented the initialization of the Litedram kernel before using the AXI interface, and the DDR has also been successfully initialized (init_done raised and init_error lowered). However, I don't know why there is an issue with writing data to the AXI interface.In addition,this is my yml file:

{
    # General ------------------------------------------------------------------
    "speedgrade": -2,          # FPGA speedgrade
    "cpu":        "vexriscv",  # CPU type (ex vexriscv, serv, None)
    "memtype":    "DDR3",      # DRAM type
    "uart":       "rs232",     # Type of UART interface (rs232, fifo)

    # PHY ----------------------------------------------------------------------
    "cmd_latency":     1,             # Command additional latency
    "sdram_module":    "MT8JTF12864", # SDRAM modules of the board or SO-DIMM
    "sdram_module_nb": 8,             # Number of byte groups
    "sdram_rank_nb":   1,             # Number of ranks
    "sdram_phy":       "K7DDRPHY",    # Type of FPGA PHY

    # Electrical ---------------------------------------------------------------
    # "rtt_nom": "60ohm",  # Nominal termination
    # "rtt_wr":  "60ohm",  # Write termination
    # "ron":     "40ohm",  # Output driver impedance

    # Frequency ----------------------------------------------------------------
    "input_clk_freq":   100e6, # Input clock frequency
    "sys_clk_freq":     100e6, # System clock frequency (DDR_clk = 4 x sys_clk)
    "iodelay_clk_freq": 200e6, # IODELAYs reference clock frequency
    # "init_clk_freq":    25e6,# Init clock frequency

    # Core ---------------------------------------------------------------------
    "cmd_buffer_depth": 16,    # Depth of the command buffer

    # User Ports ---------------------------------------------------------------
    "user_ports": {
        "axi_0" : {
            "type": "axi",
            "id_width": 4,
            "data_width": 64,
        },
        # "wishbone_0" : {
        #     "type":  "wishbone",
        #     "block_until_ready": True,
        # },
        # "native_0" : {
        #     "type": "native",
        # },
        # "fifo_0" : {
        #     "type":  "fifo",
        #     "base":  0x00000000,
        #     "depth": 0x01000000,
        # },
    },
}

@Qiange516

[Yuxin-Yu]

Hello, @enjoy-digital .
I found the parameter --sim in gen.py. By opening this parameter, I integrated the DDR3 simulator into the DDR3 controller, successfully completed the initialization process, and reproduced the phenomenon of AXI writing data errors. I found that before axi failed to write, two successful burst write operations were performed, and the number of burst write data was relatively small, only 3 and 5, respectively. However, when the number of burst writes reaches 27, axi writes fail and the write preparation signal '_wready' has been consistently low since then, as shown below:

May I ask if this is a bug in the AXI interface, or is there a problem with my configuration?

[enjoy-digital]

Hello @Yuxin-Yu,

thanks for reporting the potential issue and providing waveforms. As a first test, could you increase w_buffer and r_buffer here: https://github.com/enjoy-digital/litedram/blob/master/litedram/frontend/axi.py#L324 to 32 or 64 and see if you test still fails?

I'll then also try to do more simulation similar to yours.

[Yuxin-Yu]

Hi @enjoy-digital
First of all, thank you for your answer. I tried the method you mentioned to increase the depth of reading and writing FIFO to 64 , but the same error occurred and it took longer to start (approximately 60ms more than before the change). At this point, the waveform is as follows:

Also, I roughly understand what you mean. You may think that the depth of the fifo is not enough and it is stuck, so I also checked the number of data written to the fifo inside Litetram. I found that it got stuck after completing 27 (the number of last burst write) and did not fill it to 64. Therefore, I don't think it is a problem with the depth of the fifo. Additionally, I found that soc_write_w_buffer_syncfifo_re signal that hasn't been raised. I feel like it's a problem with these signals, but I don't know how to solve it

[Yuxin-Yu]

Hi @enjoy-digital
Here are my engineering files. You can directly use sim.do for simulation in modelsim. Additionally, before the formal simulation, you need to use stlv7325_ Modify the absolute paths of two init files in the stlv7325_mig file
ddr_litexdram_litecore_sim.zip

[Yuxin-Yu]

Hi @enjoy-digital .
Hello, if that's right, there should be a problem during the process of converting axi to wishbone writing, because I am using other axi to wishbone modules, coupled with the literam of the wishbone interface, which can be simulated through axi reading and writing,and it also runs normally on FPGA