- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are right. The change you want to make is
set t(mimic_shift) 1.600
to set t(mimic_shift) 2.100
It 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- You are right. The change you want to make is
set t(mimic_shift) 1.600
to set t(mimic_shift) 2.100
It 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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).
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page