Arria10 FPGA's Emif Hard IP showing deviation in behavior from expected Avalon bridge protocol

[dpk23]

Hi, we are using the Intel device kit DK-DEV-10AX115S-A with 10AX115S2F45I1SG FPGA device  and HiLo DDR4 mounted on this.  The FPGA design has a cortex core with AXI bridge integrated with Emif hard IP for DDR4 i/f. We have AXI <-> Avalon CDC bridge (generated by platform designer) to interface the core with Emif controller, where the core/AXI is running at a much lower freq compared to Emif's avalon i/f. We find that Emif controller’s Avalon bridge is not behaving as expected. This is the observation :- In the case of a single read transfer - waitrequest is asserted by Emif controller for multiple clock cycles during read, which is delaying the de-assertion of read. This is getting translated as multiple reads by the Emif controller and multiple reads to DDR4 are happening. Similar observations for a single write transaction also. Finally all these read data and readdatavalids are going back to AXI bus causing it to stall.

We are using the Quartus prime pro version 23.4

Please let us know if any more information is needed

[sstrell]

This doesn't make sense (and you're not showing the waitrequest signal in question).  If waitrequest is asserted, control signals must continue to be asserted until 1 clock cycle after waitrequest is deasserted.  If you are holding the read signal past this point, then yes, multiple reads will occur.

I'm assuming these are the signals at the EMIF.  You should also look at the signals on the other side, whatever is issuing the commands.

[dpk23]

Hi, the waitrequest is same as amm_ready

I have attached snapshot of avalon read/write protocol as per spec - for a single data transfer

The read (along with other control signals) is delayed as long as the waitrequest is asserted 

The commands issues from master side follow the protocol, i.e. as long as amm_read/waitrequest is asserted the control signals dont change.

But the EMIF is sending multiple readdatavalids - instead of just 1 - and also even before the amm_read/waitrequest is de-asserted

[sstrell]

You're saying amm_ready is waitrequest?  That doesn't make sense since "ready" is not a standard Avalon signal.  And if "ready" is the signal you are using, it sounds like an inverted version of waitrequest which would make the behavior you show in your Signal Tap capture expected.

Can you verify this is actually waitrequest?  I've never seen it referred to as "ready".

[dpk23]

Hi, i have attached snippet from the EMIF documentation

We will try out inverting the amm_ready from EMIF to Avalon CDC bridge as per your suggestion and validate the result

Thanks

[dpk23 · Accepted solution]

Hi, this works : inverting the amm_ready from EMIF 

thanks for the help!

[sstrell]

So the IP is naming the signal wrong (compared to the Avalon spec) and inverting its function without any details.  Wow.

Glad it's working for you.

[AdzimZM_Intel]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.