FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6359 Discussions

DDR2 High Perfomance Mimic Path failing timing

Altera_Forum
Honored Contributor II
964 Views

I am getting setup errors from the DDR_CLK to the mimic_data_in_metastable[0] path (launch clock is DDR_phy_DDR_CLK_mimic_launch_clk, latch clock is DDR_phy_ddr_mimic ). 

 

In the 9.0 errata (http://www.altera.com/literature/rn/rn_ip.pdf) I found: 

 

--- Quote Start ---  

The Quartus II software may fail to place the mimic path correctly. The report timing 

script then indicates a timing setup failure on the mimic path. 

--- Quote End ---  

 

 

This is vague but it does describe my problem. The listed workaround is: 

 

--- Quote Start ---  

Manually edit the following parameter in the autogenerated Synopsis design 

constraint (.sdc) script to correct the timing analysis: 

mimic_shift 

Add a value of at least the worst case failed slack to the value already stated in the 

Synopsis design constraint file. 

--- Quote End ---  

 

 

I don't fully understand the workaround. Theseare the items in the .sdc file that are related to the mimic path: 

 

# The maximum allowed length of the mimic path. set t(mimic_shift) 1.600 

 

foreach ck $pins(ck_p) { create_clock -period $t(period) $ck -name ${instname}_${ck}_mimic_launch_clock -add } set_max_delay -from -to $t(mimic_shift) set_false_path -from |*]  

 

Do I need to declare mimic_shift independently? Is the "set t(mimic_shift) 1.600" assigning the wrong number? Should I add the negative slack to the 1.600 value? If my slack is -.488, should I change the number to 1.112 or 2.088? Would it be safer to change the numbers to 1.1 or 2.1 (or 1.0/2.0) to add a safety margin? 

 

There are not a lot of details on the cause of the errata, the consequences, or the workaround.
0 Kudos
3 Replies
Altera_Forum
Honored Contributor II
184 Views

You are right. The change you want to make is 

set t(mimic_shift) 1.600to 

set t(mimic_shift) 2.100It is worth checking that the mimic path register (the one that samples the clock that is driven out) is being placed close the the clock pin in the chip planner too. It should be in the first LAB in from the IOE.
0 Kudos
Altera_Forum
Honored Contributor II
184 Views

 

--- Quote Start ---  

You are right. The change you want to make is 

set t(mimic_shift) 1.600to 

set t(mimic_shift) 2.100It is worth checking that the mimic path register (the one that samples the clock that is driven out) is being placed close the the clock pin in the chip planner too. It should be in the first LAB in from the IOE. 

--- Quote End ---  

 

 

This change does allow the design to pass timing, but when I try to find the register it doesn't look like it's been placed near the IO block. 

 

First, I'm not sure if I found the right register. When I generate fan-out from the DDR_CLK pin, it send me to  

 

...DDR_phy_alt_mem_phy_inst|DDR_phy_alt_mem_phy_mimic:mmc|mimic_data_in_metastable[0]~feeder) 

 

which is not in the adjacent LAB, but is almost directly in the middle of the chip (I am using a Stratix II GX ). The path is listed at 1.9 ns. 

 

Should I be concerned about this? I'm not 100% sure if this was the path that was failing before.
0 Kudos
Altera_Forum
Honored Contributor II
184 Views

 

--- Quote Start ---  

First, I'm not sure if I found the right register. When I generate fan-out from the DDR_CLK pin, it send me to  

 

...DDR_phy_alt_mem_phy_inst|DDR_phy_alt_mem_phy_mi mic:mmc|mimic_data_in_metastable[0]~feeder) 

 

which is not in the adjacent LAB, but is almost directly in the middle of the chip (I am using a Stratix II GX ). The path is listed at 1.9 ns. 

--- Quote End ---  

Yes, that is the right register. The ~feeder node is inserted because Quartus has used the LUT in front of the register as the route into the register itself, rather than the SLOAD inputs. Either of these is fine, and it is simply a matter of routing which gets picked. If you look at the fanout of the ~feeder register there will be the actual ...mimic_data_in_metastable[0] register. 

 

The fact that the register is not by the IOE is a problem though. The routing delay will mean that the mimic path will not track correctly. I guess that this is because the clock that is used for the mimic register (clk[6], as I recall) is routed on a local clock network, which only feeds one side of the chip. 

 

The solution is to either move the PLL such that it can drive local clock on the same side of the chip as the memory interface is on, or force the mimic clock to be on a global clock network. Manually placing the mimic path register next to the clkout pin is a good thing to do, since that will either sort things out or cause a error in fitting (which can then be addressed by moving the PLL of forcing the mimic clock onto a global).
0 Kudos
Reply