Forum Discussion
Occasional ContributorDDR3 timing errors on Cyclone V
Regular ContributorHello,
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.
SeadogThe 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.
