- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, this works : inverting the amm_ready from EMIF
thanks for the help!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, this works : inverting the amm_ready from EMIF
thanks for the help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page