Forum Discussion

dpk23's avatar
dpk23
Icon for New Contributor rankNew Contributor
1 year ago
Solved

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

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

  • Hi, this works : inverting the amm_ready from EMIF

    thanks for the help!

7 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    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's avatar
      dpk23
      Icon for New Contributor rankNew Contributor

      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's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    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's avatar
    dpk23
    Icon for New Contributor rankNew Contributor

    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's avatar
    dpk23
    Icon for New Contributor rankNew Contributor

    Hi, this works : inverting the amm_ready from EMIF

    thanks for the help!

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    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_Altera's avatar
    AdzimZM_Altera
    Icon for Regular Contributor rankRegular Contributor

    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.