FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6543 Discussions

DDR4 EMIF - Read without read valid

matferronato
Beginner
855 Views

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.

Labels (1)
0 Kudos
5 Replies
sstrell
Honored Contributor III
797 Views

If this is Avalon, waitrequest is active high, not active low, so you have to hold the address and read control until waitrequest goes low.  One cycle after waitrequest goes low is when valid data appears, qualified, in the case of a burst, with readdatavalid.

See the Avalon spec: https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html

0 Kudos
matferronato
Beginner
724 Views

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

0 Kudos
matferronato
Beginner
764 Views

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.

 

0 Kudos
AdzimZM_Intel
Employee
699 Views

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


0 Kudos
AdzimZM_Intel
Employee
483 Views

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.


0 Kudos
Reply