DDR3 timing errors on Cyclone V

[Seadog]

Closing timing on a design using the 5CGTFD9E5F35C7, getting a few (17) setup failures on a DDR3 controller core; launch and latch clock are different, but both are part of DDR3 core.  From: and to: nodes are also all internal to core.  An example:

slack:   -3.404

from node: ddr3_v20:ddr3_v20_inst|ddr3_v20_0002:ddr3_v20_inst|ddr3_v20_s0:s0|altera_mem_if_sequencer_cpu_cv_synth_cpu_inst:cpu_inst|W_alu_result[15]

to node:

ddr3_v20:ddr3_v20_inst|ddr3_v20_0002:ddr3_v20_inst|ddr3_v20_s0:s0|sequencer_scc_mgr:sequencer_scc_mgr_inst|scc_parallel

launch clock:

ddr3_v20_inst|ddr3_v20_inst|pll0|pll6~PLL_OUTPUT_COUNTER|divclk

latch clock:

ddr3_v20_inst|ddr3_v20_inst|pll0|pll7~PLL_OUTPUT_COUNTER|divclk

relationship: 0.000

clock skew: -0.599

data delay: 2.735

Note that launch and latch edges are coincident (doesn't seem quite fair does it?).  The clock frequencies seem to be quite low (<= 50 MHz?).  Closure recommendations provided by Timing Analyzer all seem to ask for changes to the core design (move nodes - not sure exactly what that means, duplicate nodes, ensure launch and latch frequencies are exact multiples, reduce levels of logic).

I would think that the SDC files created by Platform Designer would have constrained the core sufficiently.

Suggestions?

Thanks.

[AdzimZM_Intel]

Hi Seadog,

Thanks for using Intel Community.

I'm Adzim, AE that will assist you in this thread.

I really appreciate if you can share the design with me for replication purpose.

Thanks,

Adzim

[Seadog]

Hi Adzim,

I can not share the design, it is ITAR restricted.  I have attached  a spreadsheet with the details on the errors.  I can summarize the problem as well:

• the 'From Nodes' and and 'To Node' (all errors are associated with the same 'To Node'), and the Launch and Latch Clocks are all internal to the DDR3 core
• the Launch and Latch clock edges in question are coincident, thus the timing relationship (delay/skew budget) is 0.0 ns
• there are numerous other paths using the same launch and latch clocks which do not have timing errors; the difference is that in the error cases, the latch clock is using the falling edge, whereas in the non-error cases, the latch clock uses the rising edge

[AdzimZM_Intel]

Hi Seadog,

In that case, maybe you can share the timing report for Report DDR.

So that at least I can see where the timing issue occur.

Thanks,

Adzim

[Seadog]

I think the relevant information is in the spreadsheet I uploaded yesterday, but I am uploading the DDR timing report as a zip.

Thanks.

[AdzimZM_Intel]

Hi Seadog,

According to the Report DDR, the timing violation is not in the EMIF IP.

It's within the EMIF block and other.

Do you used the PLL IP core?

If yes, can you remove it? Because the EMIF can work without it.

Regards,

Adzim

[Seadog]

According to the Report DDR, the timing violation is not in the EMIF IP.

It's within the EMIF block and other.

Does this really matter?  The timing violation is not in my RTL code, it is in the vendor-provided memory controller code.

Do you used the PLL IP core?

If yes, can you remove it? Because the EMIF can work without it.

The only PLL I know of is in the PHY; it provides the clock used to interface to the memory, as well as the clock used for the system (Avalon) interface.  I don't know how to exclude that PLL, but something has to generate those clocks.

I am uploading a Word doc with the EMIF configuration details.

[AdzimZM_Intel]

Hi Seadog,

I already create an example design with your EMIF IP configuration.

The result is good.

No timing violation is occur.

Like I said in my previous feedback, this timing issue is not in the EMIF IP, it is occurring outside and at the custom logic.

Thus you can try some suggestions below:

1. You can try to run a few seed sweep.
2. Based on the recommendation from the Quartus, are you able to follow?
3. Explore some compiler setting, choose mode with timing performance and compile.

Below is reference for duplicate register.

https://www.intel.com/content/dam/altera-www/global/en_US/uploads/archive/a/aa/20110621141859%21Register_Duplication_for_Timing_Closure.pdf

Regards,

Adzim

[Seadog]

Please excuse my obstinacy, but I am going back to what I wrote when I first posted this problem.  All of the errors are associated with launch and latch clock edges which are coincident - the timing relationship is 0 ns.  There is no available budget for asynchronous delays.

I have uploaded another document explaining the problem as I see it.  Please explain to me why I am wrong.

[AdzimZM_Intel]

Hello,

Thanks for the attachment.

I've gone through it and below are my comments.

"The timing constraints for this core are broken."

I slightly disagree with this statement because of following reasons:

• The timing violation is occurs between the EMIF IP and other block designs as shown in the Report DDR. Therefore it's not in the core.
  • ; Core (Slow 1100mV 85C Model)         ; Slow 1100mV 85C Model ; -3.392   ; 0.173   ;
• I created a design containing EMIF IP and run through the flow and there is no violation.
• Might be not accurate so if you can provide a small toy design that can replicate the issue, that will be good.

Since this timing issue occurred between EMIF IP and user logic/module, not in the core, a normal timing closure method is applicable. e.g. add pipeline register or set max delay constraint.

[Seadog]

The timing violation is between the From Node and the To Node, by definition.  Those nodes are:

From Node:

ddr3_v20:ddr3_v20_inst

>ddr3_v20_0002:ddr3_v20_inst

>ddr3_v20_s0:s0

>altera_mem_if_sequencer_cpu_cv_synth_cpu_inst:cpu_inst

>W_alu_result[9]~DUPLICATE

To Node:

ddr3_v20:ddr3_v20_inst

>ddr3_v20_0002:ddr3_v20_inst

>ddr3_v20_s0:s0

>sequencer_scc_mgr:sequencer_scc_mgr_inst

>scc_parallel

Launch Clock:

ddr3_v20_inst

>ddr3_v20_inst

>pll0

>pll6~PLL_OUTPUT_COUNTER

>divclk

Latch Clock:

ddr3_v20_inst

>ddr3_v20_inst

>pll0

>pll7~PLL_OUTPUT_COUNTER

>divclk

Both nodes (as well as the PLL which generates the launch and latch clocks) are instantiated within the hierarchy of the memory controller IP (core name is ddr3_v20).  I didn't write any of that code.

[AdzimZM_Intel]

Hi,

Yes I can see the timing issue there.

But when I setting the EMIF IP by following your EMIF configuration, the example design doesn't show any issue.

So do you able to provide any simple design or the example design that can replicate this issue?

Regards,

Adzim

[Seadog]

I did a test build which contains just the EMIF core, a PLL and a reset circuit.  I did not rebuild the EMIF core, I just made a copy of the existing item.

Unfortunately, the timing errors do not appear in this version of the design.  In fact, the particular combinations of From Node, To Node, Launch Clock and Latch Clock which had errors in the original design do not even appear in the timing report for the test build (maybe this is a clue?).

I uploaded an archive of the test build, and a copy of the exported timing report form the original design.

[AdzimZM_Intel]

Hello Seadog,

I found a KDB that might be working in this issue.

• Link: https://www.intel.com/content/www/us/en/support/programmable/articles/000078771.html

Can you use the workaround that has been stated in the Resolution section of the KDB?

Please let me know your feedback.

Thanks,

Adzim

[Seadog]

Adzim,

I will try this and get back to you.  Thank you.

[AdzimZM_Intel]

Hello and Good day!

I just want yo know if you have any update upon your testing?

Please let me know your feedback.

Thank you.

Regards,

Adzim

[Seadog]

Sorry for the delay, I was otherwise occupied.

I just made the changes to the project and did a new build.  The existing timing errors vanished.  There is a new error, associated with the pll_afi_clk (150 MHz), for a single pair of nodes; the slack is -2 ps.

Thank you for your help with this problem.

[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.