DDR3 timing errors on Cyclone V

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

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

Thanks.

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.

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.

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.

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.