Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

DDR2 High Perfomance Mimic Path failing timing

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.

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- 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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- 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).