--- 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.
Honored Contributor
