Forum Discussion

matferronato's avatar
matferronato
Icon for New Contributor rankNew Contributor
2 years ago

DDR4 EMIF - Read without read valid

In my design, I instantiated and configured the EMIF IP via IP Catalog (not platform designer).

I then correctly connected the signals according to design examples from Terasic.

The flow of data from input up to the EMIF is:

PCIe -> Dual Clock Fifo -> EMIF

This usually works fine, however what I see now is that for certain combination of inputs, I will always get the same error. After some read transcations, I will assert the read line but I will never receive a readdata valid.

When retrieving data from DDR4, I would:

  • Check if ready/waitreq_n signal is '1'
  • Be sure that the write pin is cleared
  • Assert the read pin for one clock cycle
  • Set the correct values for the address and burst lines

Then I would not receive a readdata valid response from the IP.

The images attached show the error happening.

What could cause a read without a read valid? What would be the best way to debug this issue?

Environment:

  • DE10 Agilex Board
  • AGFB014R24B2E2V

Thank you for your help.

Memory

5 Replies

    • matferronato's avatar
      matferronato
      Icon for New Contributor rankNew Contributor
      2 years ago

      Continuing from my previous reply, I'd say this part is not correct

      ---------------------------------------------

      One cycle after waitrequest goes low is when valid data appears, qualified, in the case of a burst, with readdatavalid

      ---------------------------------------------

      From Figure 15, paragraph 3 in chapter 3.5.5.2. Read Bursts

      "Host B drives address (A1), burstcount, and read. The agent asserts waitrequest, causing all inputs except beginbursttransfer to be held
      constant. The agent could have returned read data from the first read request at this time, at the earliest."

      Implying that the agent may delay the readvalid response, which makes sense. For an emif IP that must fetch data from outside the fpga, one must expect several cycles of delay

  • matferronato's avatar
    matferronato
    Icon for New Contributor rankNew Contributor
    2 years ago

    I agree that this should be the case according to the manual, but that is not what I observe when simulating the IP (please refer to the attached image).

    the emif signal is:

    ----------------------------------------------------------
    output wire amm_ready_0, // ctrl_amm_0.waitrequest_n, Wait-request is asserted when controller is busy

    ----------------------------------------------------------

    which matches your description.

    However when simulating the example design, we see that the amm_ready is set to 1 when accepting data

    the whole confusion seems to starts because the example design negates the ready signal on the TG

    ----------------------------------------------------------
    ed_sim_tg tg (
    .emif_usr_reset_n (emif_fm_0_emif_usr_reset_n_reset), // input, width = 1, emif_usr_reset_n.reset_n
    .ninit_done (ninit_done_ninit_done_reset), // input, width = 1, ninit_done.reset
    .emif_usr_clk (emif_fm_0_emif_usr_clk_clk), // input, width = 1, emif_usr_clk.clk
    .amm_ready_0 (~tg_ctrl_amm_0_waitrequest), // input, width = 1, ctrl_amm_0.waitrequest_n
    .amm_read_0 (tg_ctrl_amm_0_read), // output, width = 1, .read
    .amm_write_0 (tg_ctrl_amm_0_write), // output, width = 1, .write
    .amm_address_0 (tg_ctrl_amm_0_address), // output, width = 33, .address
    .amm_readdata_0 (tg_ctrl_amm_0_readdata), // input, width = 576, .readdata
    .amm_writedata_0 (tg_ctrl_amm_0_writedata), // output, width = 576, .writedata
    .amm_burstcount_0 (tg_ctrl_amm_0_burstcount), // output, width = 7, .burstcount
    .amm_byteenable_0 (tg_ctrl_amm_0_byteenable), // output, width = 72, .byteenable
    .amm_readdatavalid_0 (tg_ctrl_amm_0_readdatavalid), // input, width = 1, .readdatavalid
    .traffic_gen_pass_0 (tg_tg_status_0_traffic_gen_pass), // output, width = 1, tg_status_0.traffic_gen_pass
    .traffic_gen_fail_0 (tg_tg_status_0_traffic_gen_fail), // output, width = 1, .traffic_gen_fail
    .traffic_gen_timeout_0 (tg_tg_status_0_traffic_gen_timeout) // output, width = 1, .traffic_gen_timeout
    );

    ----------------------------------------------------------

    I observe the same using signal tap, the emif ip is sets ready to 1 when available. The initial value for that pin is 1 after calibration.

  • AdzimZM_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi,


    Maybe you can check if the address is satisfied with the burstlength.

    Try to get which address that start to have read issue by testing multiple times.


    You also can verify if the EMIF IP setting is matching to the memory device datasheet.


    Regards,

    Adzim


  • AdzimZM_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    As we do not receive any response from you on the previous reply that we have provided, I now transition this thread to community support. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.