QSYS amm interconnect delay with EMIF (Arria 10)

Thank you @sstrell and @AdzimZM_Intel for quick replies,

I didn't know we could quick visualize interconnect infos on plateform designer nodes !
Indeed I had a CDC bridge between my amm controller and EMIF amm agent because quartus thought it was different. Why is that, is because in my system view I first exported the emif_usr_clk, in order to access it in my toplevel design, then added an input clock bridge to take it back and bring it to my controller (master_amm_burst_0). It's indeed more logical to connect it directly inside qsys and export through an output clock bridge for other user stuff. Here in the pictures are the following previous and new connections which exluded the need of an interconnect adapter :

Before:

After:

I have no more waitrequest low for each write and I am almost at the theoretical datarate. I say almost, because I noticed that I have now another issue which appears obviously when I perform long writes.
For instance on 20 bursts with burstlength of 127, writing 256bit databus , we see that the "ready" signal (meaning waitrequest_n) is going more or less every 2090 clock cycles (based of emif_usr_clk) and remains low for 80-100 cycles. Here is the signaltap of signals during a write.

Mostly you can see master_amm_address incrementing each time a new burst of 127 is started, I perform the 20 bursts, and you can notice the master_amm_ready is low and stalls the master_amm_writedata and write_count for 80-100 cycles.

Do you have an idea where this behavior could be coming from ? Indeed I have timing issue :

But I'm not really comfortable with timing constraints ! If you need more information, don't hesitate. If this can be relevant, here is also the amm host parameters of my custom component amm controller in the component editor :

I only matched the parameters with amm EMIF interface, meaning "Address units" as WORDS, and "Max. pending read transactions" as 64, not anything else.

Regards,

Hello,

I found that the waitrequest every 2080 cycle is related with the refresh interval "tREFI" of 7,8 µs which exactly corresponds with 2080 cycles at 266 MHz. So I believe everything works well, I just have to take this into account for estimating maximum DDR datarate which is about 65Gbps instead of 68Gbps, which is fine.

For Timing errors, I don't have any setup error, but I have 4 hold errors for instance with this path :

-0.346 u0|emif_0|emif_0|arch|arch_inst|io_tiles_wrap_inst|io_tiles_inst|tile_gen[0].tile_ctrl_inst|pa_core_clk_out[0] auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|auto_signaltap_auto_signaltap_0|sld_signaltap_inst|acq_data_in_reg[102] u0|emif_0|emif_0_core_usr_clk u0|emif_0|emif_0_core_usr_clk 0.000 3.609 3.688 Slow 900mV 0C Model

Also I have 1 single timing error in the "Report DDR" of the timing analyser, for all 4 models (slow/fast/0C/100C), which is on the "Read Capture" signal of EMIF :

Actually the design works but I don't know what to do with these errors, do you believe it is relevant to fix them ? Maybe this is only due to signaltap logic.

Thanks

Hi Adzim,

Sorry for late response, in fact I could resolve the timing issue while keeping signaltap, this was due to the trigger clock which was set to "DDR4A_REF_CLK" (reference clock input for EMIF) instead of the emif_usr_clk of EMIF. Since these have both the same frequency, I have troubles understanding why using the dedicated ref clk in signaltap generated timing errors ? If you have any insight about this, you're welcome.

I will close the topic after this, thanks again for help !