Forum Discussion

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

can't false path PLL input clock

I am getting a setup delay in my design, but the path includes the clock10 input transition time and all the time in the PLL. None of this should matter since everything is driven by the output clock.

8.33 0.00 source latency

8.33 0.00 1 PIN_H13 clk10

8.33 0.00 RR IC 1 IOIBUF_X38_Y61_N1 clk10~input|i

9.51 1.18 RR CELL 3 IOIBUF_X38_Y61_N1 clk10~input|o

10.33 0.82 RR IC 1 PLLREFCLKSELECT_X68_Y60_N0 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~PLL_REFCLK_SELECT|clkin[0]

10.66 0.33 RR CELL 1 PLLREFCLKSELECT_X68_Y60_N0 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~PLL_REFCLK_SELECT|clkout

10.66 0.00 RR IC 10 FRACTIONALPLL_X68_Y54_N0 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|refclkin

5.81 -4.85 RR COMP 2 FRACTIONALPLL_X68_Y54_N0 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~FRACTIONAL_PLL|vcoph[0]

5.81 0.00 RR IC 1 PLLOUTPUTCOUNTER_X68_Y53_N1 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|vco0ph[0]

7.55 1.74 RR CELL 1 PLLOUTPUTCOUNTER_X68_Y53_N1 PLL0|main_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk

8.69 1.14 FF IC 1 CLKCTRL_G13 GB0|altclkctrl_0|Gclk_buf_altclkctrl_0_sub_component|sd1|inclk

9.01 0.32 FF CELL 7431 CLKCTRL_G13 GB0|altclkctrl_0|Gclk_buf_altclkctrl_0_sub_component|sd1|outclk

I have false pathed the input clock but the tool seems to ignore this.

set_false_path -from [get_ports {clk10}] -to [get_clocks {main_clk}]

How do I make it ignore this delay?

3 Replies

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

    Are you doing this in TimeQuest?

    The Data Arrival Path includes your clock delay + data path delay. The Data Required is the clock delay to the latch register. For slack calculations it will do Data_Arrival-Data_Required, which means the two clock delays will be subtracted from each other(and the result will not be 0, which means the clock delay is important and can't be fully ignored, although hopefully the skew is small)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    You're not supposed to have it ignore this delay. As you can see by the negative value in the COMP row, the PLL is compensating for the delay through the PLL and the clock network. What are you trying to do here?

    If you really want no delay through the device, set the PLL mode to zero buffer delay (I think that's what it's called). That way the PLL compensated for delay all the way through the device.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    Are you doing this in TimeQuest?

    The Data Arrival Path includes your clock delay + data path delay. The Data Required is the clock delay to the latch register. For slack calculations it will do Data_Arrival-Data_Required, which means the two clock delays will be subtracted from each other(and the result will not be 0, which means the clock delay is important and can't be fully ignored, although hopefully the skew is small)

    --- Quote End ---

    It goes to timequest when you click on the setup time error.

    The clock delay includes ti crystal input and PLL times, which are totally irrelevant and could be msec without having any effect since the clock to data out is only related to the PLL clock output. So there cannot be a delta in the clock delays (like best vs worst case timing) since it is the same clock for both endpoints.