Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20750 Discussions

DDR3 timing errors on Cyclone V

Seadog
Beginner
1,975 Views

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.

 

0 Kudos
17 Replies
AdzimZM_Intel
Employee
1,938 Views

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


0 Kudos
Seadog
Beginner
1,911 Views

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
0 Kudos
AdzimZM_Intel
Employee
1,896 Views

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


0 Kudos
Seadog
Beginner
1,880 Views

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

 

Thanks.

0 Kudos
AdzimZM_Intel
Employee
1,842 Views

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


0 Kudos
Seadog
Beginner
1,834 Views

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.

0 Kudos
AdzimZM_Intel
Employee
1,773 Views

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


0 Kudos
Seadog
Beginner
1,761 Views

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.

0 Kudos
AdzimZM_Intel
Employee
1,692 Views

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.





0 Kudos
Seadog
Beginner
1,645 Views

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.

0 Kudos
AdzimZM_Intel
Employee
1,639 Views

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


0 Kudos
Seadog
Beginner
1,620 Views

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.

0 Kudos
AdzimZM_Intel
Employee
1,551 Views

Hello Seadog,


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


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


Please let me know your feedback.


Thanks,

Adzim


0 Kudos
Seadog
Beginner
1,535 Views

Adzim,

 

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

0 Kudos
AdzimZM_Intel
Employee
1,517 Views

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


0 Kudos
Seadog
Beginner
1,458 Views

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.

0 Kudos
AdzimZM_Intel
Employee
1,411 Views

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.


0 Kudos
Reply