clock path delay

That report does not start at the clock input pad. It starts at the PLL.

The PLL cannot eliminate the delays. What is does is to produce a phase shifted clock such that, once it goes to those 3.9 ns of delays, the clock delivered to ff1 is actually in phase with the clock at the input pad.

But the delays are still there and they still show up in the report.

--- Quote Start ---

That report does not start at the clock input pad. It starts at the PLL.

The PLL cannot eliminate the delays. What is does is to produce a phase shifted clock such that, once it goes to those 3.9 ns of delays, the clock delivered to ff1 is actually in phase with the clock at the input pad.

But the delays are still there and they still show up in the report.

--- Quote End ---

Hi, I am sorry, I am totally confused. If pll is compensating for clock network skew, then the delay shouldn't show up in the setup, isn't it.

What I am seeing in the report is that data_arrival = clock_delay + data_delay.

And clock_delay is over 3.9ns as noted above (which means my internal clock can never be fast in this case)

I am trying to reconcile my understanding with the following statement in the clocks and plls document: "In normal mode, the delay introduced by the GCLK or RCLK network is fullycompensated. Figure 5–25 shows an example waveform of the PLL clocks’ phase relationship in normal mode" I double checked that the PLL_B1 is fed by dedicated clock in, so it

should be fully compensated. So almost all of the time between launch clock edge and latch edge should be available for data delay.

--- Quote Start ---

Hi, I am sorry, I am totally confused. If pll is compensating for clock network skew, then the delay shouldn't show up in the setup, isn't it.

What I am seeing in the report is that data_arrival = clock_delay + data_delay.

And clock_delay is over 3.9ns as noted above (which means my internal clock can never be fast in this case)

I am trying to reconcile my understanding with the following statement in the clocks and plls document: "In normal mode, the delay introduced by the GCLK or RCLK network is fullycompensated. Figure 5–25 shows an example waveform of the PLL clocks’ phase relationship in normal mode" I double checked that the PLL_B1 is fed by dedicated clock in, so it

should be fully compensated. So almost all of the time between launch clock edge and latch edge should be available for data delay.

--- Quote End ---

I add my vote to that of rbugalho that delay is compensated through clock phase. physical delay will still be reported because clkin to pll takes time and clkout to register takes time and the pll can't pass clk in zero time but makes it appear with minimum delay through phase i.e. your clkout should reach the register as if there was no delay. After all do timing and see if you have problems in which case you can manually change the pll phase.

--- Quote Start ---

I add my vote to that of rbugalho that delay is compensated through clock phase. physical delay will still be reported because clkin to pll takes time and clkout to register takes time and the pll can't pass clk in zero time but makes it appear with minimum delay through phase i.e. your clkout should reach the register as if there was no delay. After all do timing and see if you have problems in which case you can manually change the pll phase.

--- Quote End ---

@kaz, thanks.

my problem is that: data-arrival reported by timequest is clock-path-delay+data-path-delay = 3.9 + 7 = 10.9

clock period itself is 7.5, so data path by itself is meeting setup. But the additional clock path delay is now causing the violation.

clock path delay shouldn't be there in the arrival report (or it should be reported the same in arrival and required) if its compensated.

how should i find out more bout this

--- Quote Start ---

@kaz, thanks.

my problem is that: data-arrival reported by timequest is clock-path-delay+data-path-delay = 3.9 + 7 = 10.9

clock period itself is 7.5, so data path by itself is meeting setup. But the additional clock path delay is now causing the violation.

clock path delay shouldn't be there in the arrival report (or it should be reported the same in arrival and required) if its compensated.

how should i find out more bout this

--- Quote End ---

I see. I just tried some work on PLL and it turned out that the tool does not actually report physical delay but it reports delay after compensation so you should not get 3.9 ns (I got about 0.3 ns in compensation mode but 3.2 ns without compensation and was reported as such).

Now the question is back why do you get 3.9 ns? are you looking at right path? Do you actually pass timing after setting set_input_delay and how much slack do you get?

--- Quote Start ---

I see. I just tried some work on PLL and it turned out that the tool does not actually report physical delay but it reports delay after compensation so you should not get 3.9 ns (I got about 0.3 ns in compensation mode but 3.2 ns without compensation and was reported as such).

Now the question is back why do you get 3.9 ns? are you looking at right path? Do you actually pass timing after setting set_input_delay and how much slack do you get?

--- Quote End ---

i think i found some clues. The launch and latch clocks are out of phase by 90 deg but derived from same pll. I am wondering if clock delay will show up in such a case i.e. if the launch and latch clocks are not exactly the same. I am not passing timing, i get -ns as i mentioned earlier. But fitter does say the first clock was compensated.

--- Quote Start ---

i think i found some clues. The launch and latch clocks are out of phase by 90 deg but derived from same pll. I am wondering if clock delay will show up in such a case i.e. if the launch and latch clocks are not exactly the same. I am not passing timing, i get -ns as i mentioned earlier. But fitter does say the first clock was compensated.

--- Quote End ---

It is not clear from your post what is your launch clock and what is your latch clock. I assumed so far you are looking at external data coming in with its clock being fed into PLL then pll clockout used as latch for same data at io registers. Then timing will depend on your set_input_delay value which tells the tool the relation of your incoming data to its clock at pins. It will help to have brief account of your clocking and data failure section.

Can you post a complete timing report for the failing path?

In the case of the attached file, I have a 200 MHz clock and the PLL generates two 200 MHz clock: c0 with 0º phase shift and c1 and 90º phase shift. The PLL is in normal compensation mode using c0 as feedback clock.

Note that you can see all the clock propagation delays, but the PLL compensation is also accounted in the large negative COMP parcels