I'm trying unsuccessfully to use an IOPLL to synthesize a clock and have it be in-phase with the reference clock, where both the reference clock and the synthesized clock are routed on GCLKs. By "in-phase" I mean ideally zero or near-zero skew, i.e. where the rising edges of the synthesized clock and the reference clock line up with each other. And to clarify/simplify, both the reference clock and the synthesized clock are just used to clock internal fabric resources, there is no external I/O involved. With all attempts thus far, I'm seeing very large skew between the synthesized clock and the reference clock, as much as ~5 ns. So I can only assume that something is fundamentally wrong with how I'm configuring the IOPLL. If necessary I can provide a simple design example, timing reports, etc. But before diving into that, possibly unnecessarily, let's start with some basic questions. And just for background reference, I'm well familiar with PLLs and de-skewing techniques in general, and have done this routinely in Xilinx devices. But I'm not as familiar yet with the Arria 10 PLL resources, and am finding it somewhat difficult to find good information. The Intel/Altera documentation I've found describing the IOPLL has been fairly scant, and the IP generator and simulation library models obscure critical details on low-level configuration options, internal functionality, feedback paths, etc... so at this point I must humbly request some guidance from knowledgeable Intel/Altera insiders, please. So, here we go: I'm using the IP generator wizard to configuring the IOPLL to "normal" compensation mode (and all other options default). "Normal" mode as tersely described in Altera documentation "compensates for the delay of the internal clock network used by the clock output". Of the listed compensation modes, that description, while not entirely clear, sounded like the appropriate choice for what I'm trying to accomplish. Is it? It claims to compensate, and yet it doesn't expose the lock feedback path to the user, so any means by which it is trying to compensate is hidden from me. So firstly, was that even a correct interpretation of the description of "normal" mode? Is "normal" mode meant to produce clocks that on GCLKs will be in phase with the reference clock that is also on a GCLK? And if not, please steer me in the right direction, and we'll go from there. Thanks,-Roee

Hi Dima, The approach I ended up taking was to use an IOPLL in its "direct" compensation mode, and then deal with the non-zero skew at the clock domain crossings. With the IOPLL in direct compensation mode, you do end up with some positive skew from the upstream clock to the downstream clock. But this skew is predictable/repeatable, doesn't vary significantly from build to build, and is on the order of a couple of nanoseconds. So, knowing the approximate skew relationship between the clocks, you can still deal with it statically using fully synchronous design techniques. As to handling the domain crossings, the following is a relatively simple approach that can meet timing up to moderately high clock frequencies (for an Arria 10 in -1 speed grade, say ~350 MHz): Crossing from the downstream clock domain to the upstream clock domain is the simpler of the two crossings. You can simply go direct reg-to-reg. Setup is the limiting factor here, and the time available for the reg-to-reg path is essentially the entire clock period minus the clock skew (and of course minus the clock-to-out of the source reg and the setup time requirement of the destination reg). Even after losing those couple of nanoseconds to clock skew, at the clock frequencies we're talking about you should still have ample setup slack on a direct reg-to-reg path. Crossing from the upstream clock domain to the downstream clock domain is the more tricky crossing, with hold being the limiting factor. If you simply go direct reg-to-reg, you will probably end up with unfixable hold violations due to the clock skew. My solution to this was to go reg-to-reg-to-reg, where the first register stage is on the rising edge of the upstream clock, the second is on the falling edge of the downstream clock, and the third is on the rising edge of the downstream clock. This ensures that you have no less than half a clock period of time available for each reg-to-reg path, assuming a 50% duty cycle on the downstream clock. Or more precisely, you have half a clock period plus the clock skew for the first reg-to-reg path, and exactly half a clock period for the second reg-to-reg path. This should ensure ample hold slack, though we are now setup limited again. If you're pushing for a high clock frequency where the half-period reg-to-reg path becomes the critical path for setup, you can further balance the time available between the register stages by modifying the duty cycle of the downstream clock, which you can naturally do using the configuration of the IOPLL. You have a total of one clock period plus the skew to go reg-to-reg-to-reg, so nominally you'd want the falling edge used for the middle register stage right in the middle of that, which you can get closer to by adjusting the duty cycle of the downstream clock. But again, I'd only bother with this optimization if this crossing becomes your critical path. Otherwise just keep it simple with a 50% duty cycle. For applications where the attainable timing performance is adequate, the above approach has the advantages of being relatively simple, fully synchronous, having no timing exceptions, requiring no additional clock phases, and requiring no special timing constraints. And if you need to push the performance even higher, you'll have to get even more creative, and I have... but I won't go into that here. Hope this helps, and let me know if you have any questions. -Roeeroee@porcupinetech.com

I think you may be using the wrong mode. See the user guide: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug_altera_iopll-18-1.pdf Maybe you want to be using zero-delay buffer mode? It's not entirely clear what your goal is so I'm kind of guessing.

Thanks, @sstrell, but zero delay buffer mode doesn't seem to be what I need. That's for putting out a clock to the board via a chip level I/O pin, and de-skews the clock for that external output, not for an internal GCLK.From that doc (UG-01155), which I have been scouring:"If you select the zero delay buffer mode, the PLL must feed an external clock output pin and compensate for the delay introduced by that pin. The signal observed on the pin is synchronized to the input clock. The PLL clock output connects to the altbidir port and drives zdbfbclk as an output port. If the PLL also drives the internal clock network, a corresponding phase shift of that network occurs."My situation is purely on-chip, no external I/O involved. Assume I have a given clock signal "clk1" that's already on a GCLK, and I need to produce another clock signal "clk2" that is also on a GCLK, is at an integer multiple of the frequency of "clk1", and is phase-aligned with "clk1". That's what I'm trying to accomplish.It seems like in principle what I need is more analogous to the IOPLL's "external mode", which exposes the feedback path to the user. Except that instead of running the feedback path off-chip through I/O pins, I need to run the feedback path on-chip through just a clock control block and GCLK. But "external mode" doesn't allow that either, it already has the input pin and output pin I/O buffers built in and has to go off-chip. So...?

Hi,In the Normal mode the FBCLK_IN pin of the IOPLL is fed by a CLKCTRL block whose input is driven by the FBOUT output pin of the IOPLL. The CLKCTRL block is added automatically by the tool. Hence, the FBCLK_IN is not exposed to user by the IP. You can check this in the Technology map viewer after running fitter. IOPLL User Guide mentions the following, and the tool seems to implement the same.If you select the normal mode, the PLL compensates for the delay of the internal clock network used by the clock output. If the PLL is also used to drive an external clock output pin, a corresponding phase shift of the signal on the output pin occurs.Now I want to ask a question related to the measurement technique used to verify whether there is a delay between the input clock and the generated output clock or not. How are you measuring the delay between the clocks.Regards

Hi @Ash_R_Intel, thank you for your response.Your description of normal mode matches what I thought it should do, and yes, I can confirm via the technology viewer that it is in fact implementing the feedback path exactly as you described. So it should be able to de-skew as intended, but it doesn't seem to. I say this based on the clock skew shown in the static timing analysis report.Pasted below is a snippet from the .sta.rpt from a trivial design example showing a reg-to-reg timing path going from the "clk2" domain (the output clock from the IOPLL) to the "clk1" domain (the input clock to the IOPLL). As you can see in the report, the clock path is mapped as expected, with "clk1" on CLKCTRL_2I_G_I7, which then goes to the IOPLL, then to "clk2" on CLKCTRL_3C_G_I21 (and the IOPLL's feedback path is not explicitly shown in this report but is confirmed via technology view to be exactly as you described).Now, as you can see in the report, there is a massive hold violation (-4.661ns) resulting from a massive skew between these two clocks (5.084ns). And we can see in the report there is a compensation delay being applied in the IOPLL (-9.485ns, shown as type "COMP"), but it isn't obvious to me how it's coming up with that compensation amount, as this is not having a de-skewing effect. Rather, it actually seems to be far too large of an "anti-delay".Path #1: Hold slack is -4.661 (VIOLATED)===============================================================================+---------------------------------------------------------+; Path Summary ;+---------------------------------+-----------------------+; Property ; Value ;+---------------------------------+-----------------------+; From Node ; ff3 ;; To Node ; ff4 ;; Launch Clock ; clk1 ;; Latch Clock ; clk1 ;; Data Arrival Time ; -0.543 ;; Data Required Time ; 4.118 ;; Slack ; -4.661 (VIOLATED) ;; Worst-Case Operating Conditions ; Slow 900mV -40C Model ;+---------------------------------+-----------------------++-------------------------------------------------------------------------------------+; Statistics ;+------------------------+-------+-------+-------------+------------+--------+--------+; Property ; Value ; Count ; Total Delay ; % of Total ; Min ; Max ;+------------------------+-------+-------+-------------+------------+--------+--------+; Hold Relationship ; 0.000 ; ; ; ; ; ;; Clock Skew ; 5.084 ; ; ; ; ; ;; Data Delay ; 0.787 ; ; ; ; ; ;; Number of Logic Levels ; ; 0 ; ; ; ; ;; Physical Delays ; ; ; ; ; ; ;; Arrival Path ; ; ; ; ; ; ;; Clock ; ; ; ; ; ; ;; IC ; ; 5 ; 4.989 ; 61 ; 0.000 ; 2.573 ;; Cell ; ; 9 ; 3.166 ; 39 ; 0.000 ; 0.804 ;; PLL Compensation ; ; 1 ; -9.485 ; 0 ; -9.485 ; -9.485 ;; Data ; ; ; ; ; ; ;; IC ; ; 1 ; 0.529 ; 67 ; 0.529 ; 0.529 ;; Cell ; ; 2 ; 0.086 ; 11 ; 0.000 ; 0.086 ;; uTco ; ; 1 ; 0.172 ; 22 ; 0.172 ; 0.172 ;; Required Path ; ; ; ; ; ; ;; Clock ; ; ; ; ; ; ;; IC ; ; 3 ; 2.587 ; 66 ; 0.000 ; 2.587 ;; Cell ; ; 4 ; 1.321 ; 34 ; 0.000 ; 0.632 ;+------------------------+-------+-------+-------------+------------+--------+--------+Note: Negative delays are omitted from totals when calculating percentages+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+; Data Arrival Path ;+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+; 0.000 ; 0.000 ; ; ; ; ; ; launch edge time ;; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;; -1.330 ; -1.330 ; ; ; ; ; ; clock path ;; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;; 0.762 ; 0.130 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;; 0.762 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;; 1.211 ; 0.449 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;; 3.784 ; 2.573 ; RR ; IC ; 1 ; IOPLL_3C ; High Speed ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|refclk[0] ;; 4.526 ; 0.742 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vco_refclk ;; 4.526 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vctrl ;; -4.959 ; -9.485 ; RR ; COMP ; 2 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vcoph[0] ;; -4.155 ; 0.804 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|outclk[0] ;; -4.155 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~io_48_lvds_tile/pllcout[4] ;; -4.155 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|inclk ;; -3.746 ; 0.409 ; RR ; CELL ; 1 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|outclk ;; -1.330 ; 2.416 ; RR ; IC ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3|clk ;; -1.330 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3 ;; -0.543 ; 0.787 ; ; ; ; ; ; data path ;; -1.158 ; 0.172 ; FF ; uTco ; 1 ; FF_X77_Y121_N55 ; ; ff3|q ;; -1.072 ; 0.086 ; FF ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3~la_lab/laboutb[16] ;; -0.543 ; 0.529 ; FF ; IC ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4|asdata ;; -0.543 ; 0.000 ; FF ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------++----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+; Data Required Path ;+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+; 0.000 ; 0.000 ; ; ; ; ; ; latch edge time ;; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;; 3.754 ; 3.754 ; ; ; ; ; ; clock path ;; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;; 0.791 ; 0.159 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;; 0.791 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;; 1.321 ; 0.530 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;; 3.908 ; 2.587 ; RR ; IC ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4|clk ;; 3.908 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;; 3.754 ; -0.154 ; ; ; ; ; ; clock pessimism removed ;; 3.754 ; 0.000 ; ; ; ; ; ; clock uncertainty ;; 4.118 ; 0.364 ; ; uTh ; 1 ; FF_X77_Y121_N53 ; ; ff4 ;+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+----------------------------; Extra Fitter Information ;----------------------------HTML report is unavailable in plain text report export.

Clock synthesis and de-skewing using an IOPLL in Arria 10

17 Replies

roeekalinsky
Contributor
4 years ago
Hi Dima,

The approach I ended up taking was to use an IOPLL in its "direct" compensation mode, and then deal with the non-zero skew at the clock domain crossings.

With the IOPLL in direct compensation mode, you do end up with some positive skew from the upstream clock to the downstream clock. But this skew is predictable/repeatable, doesn't vary significantly from build to build, and is on the order of a couple of nanoseconds. So, knowing the approximate skew relationship between the clocks, you can still deal with it statically using fully synchronous design techniques.

As to handling the domain crossings, the following is a relatively simple approach that can meet timing up to moderately high clock frequencies (for an Arria 10 in -1 speed grade, say ~350 MHz):

Crossing from the downstream clock domain to the upstream clock domain is the simpler of the two crossings. You can simply go direct reg-to-reg. Setup is the limiting factor here, and the time available for the reg-to-reg path is essentially the entire clock period minus the clock skew (and of course minus the clock-to-out of the source reg and the setup time requirement of the destination reg). Even after losing those couple of nanoseconds to clock skew, at the clock frequencies we're talking about you should still have ample setup slack on a direct reg-to-reg path.

Crossing from the upstream clock domain to the downstream clock domain is the more tricky crossing, with hold being the limiting factor. If you simply go direct reg-to-reg, you will probably end up with unfixable hold violations due to the clock skew. My solution to this was to go reg-to-reg-to-reg, where the first register stage is on the rising edge of the upstream clock, the second is on the falling edge of the downstream clock, and the third is on the rising edge of the downstream clock. This ensures that you have no less than half a clock period of time available for each reg-to-reg path, assuming a 50% duty cycle on the downstream clock. Or more precisely, you have half a clock period plus the clock skew for the first reg-to-reg path, and exactly half a clock period for the second reg-to-reg path. This should ensure ample hold slack, though we are now setup limited again.

If you're pushing for a high clock frequency where the half-period reg-to-reg path becomes the critical path for setup, you can further balance the time available between the register stages by modifying the duty cycle of the downstream clock, which you can naturally do using the configuration of the IOPLL. You have a total of one clock period plus the skew to go reg-to-reg-to-reg, so nominally you'd want the falling edge used for the middle register stage right in the middle of that, which you can get closer to by adjusting the duty cycle of the downstream clock. But again, I'd only bother with this optimization if this crossing becomes your critical path. Otherwise just keep it simple with a 50% duty cycle.

For applications where the attainable timing performance is adequate, the above approach has the advantages of being relatively simple, fully synchronous, having no timing exceptions, requiring no additional clock phases, and requiring no special timing constraints.

And if you need to push the performance even higher, you'll have to get even more creative, and I have... but I won't go into that here.

Hope this helps, and let me know if you have any questions.

-Roee
[email protected]
- dlevit
  New Contributor
  4 years ago
  Thank you for the detailed answer!
  
  I appreciate your insight. I need to cross signals from the upstream to the downstream clock domain, but the frequency is rather low, and your method looks very promising.
  
  Thanks,
  
  Dima
  - roeekalinsky
    Contributor
    4 years ago
    You're welcome. Good luck!
    
    -Roee
sstrell
Super Contributor
5 years ago
I think you may be using the wrong mode. See the user guide:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/archives/ug_altera_iopll-18-1.pdf

Maybe you want to be using zero-delay buffer mode? It's not entirely clear what your goal is so I'm kind of guessing.
roeekalinsky
Contributor
5 years ago
Thanks, @sstrell, but zero delay buffer mode doesn't seem to be what I need. That's for putting out a clock to the board via a chip level I/O pin, and de-skews the clock for that external output, not for an internal GCLK.

From that doc (UG-01155), which I have been scouring:
"If you select the zero delay buffer mode, the PLL must feed an external clock output pin and compensate for the delay introduced by that pin. The signal observed on the pin is synchronized to the input clock. The PLL clock output connects to the altbidir port and drives zdbfbclk as an output port. If the PLL also drives the internal clock network, a corresponding phase shift of that network occurs."

My situation is purely on-chip, no external I/O involved. Assume I have a given clock signal "clk1" that's already on a GCLK, and I need to produce another clock signal "clk2" that is also on a GCLK, is at an integer multiple of the frequency of "clk1", and is phase-aligned with "clk1". That's what I'm trying to accomplish.

It seems like in principle what I need is more analogous to the IOPLL's "external mode", which exposes the feedback path to the user. Except that instead of running the feedback path off-chip through I/O pins, I need to run the feedback path on-chip through just a clock control block and GCLK. But "external mode" doesn't allow that either, it already has the input pin and output pin I/O buffers built in and has to go off-chip. So...?
Ash_R_Altera
Regular Contributor
5 years ago
Hi,
In the Normal mode the FBCLK_IN pin of the IOPLL is fed by a CLKCTRL block whose input is driven by the FBOUT output pin of the IOPLL. The CLKCTRL block is added automatically by the tool. Hence, the FBCLK_IN is not exposed to user by the IP. You can check this in the Technology map viewer after running fitter. IOPLL User Guide mentions the following, and the tool seems to implement the same.
If you select the normal mode, the PLL compensates for the delay of the internal clock network used by the clock output. If the PLL is also used to drive an external clock output pin, a corresponding phase shift of the signal on the output pin occurs.

Now I want to ask a question related to the measurement technique used to verify whether there is a delay between the input clock and the generated output clock or not. How are you measuring the delay between the clocks.

Regards
roeekalinsky
Contributor
5 years ago
Hi @Ash_R_Intel, thank you for your response.

Your description of normal mode matches what I thought it should do, and yes, I can confirm via the technology viewer that it is in fact implementing the feedback path exactly as you described. So it should be able to de-skew as intended, but it doesn't seem to. I say this based on the clock skew shown in the static timing analysis report.

Pasted below is a snippet from the .sta.rpt from a trivial design example showing a reg-to-reg timing path going from the "clk2" domain (the output clock from the IOPLL) to the "clk1" domain (the input clock to the IOPLL). As you can see in the report, the clock path is mapped as expected, with "clk1" on CLKCTRL_2I_G_I7, which then goes to the IOPLL, then to "clk2" on CLKCTRL_3C_G_I21 (and the IOPLL's feedback path is not explicitly shown in this report but is confirmed via technology view to be exactly as you described).

Now, as you can see in the report, there is a massive hold violation (-4.661ns) resulting from a massive skew between these two clocks (5.084ns). And we can see in the report there is a compensation delay being applied in the IOPLL (-9.485ns, shown as type "COMP"), but it isn't obvious to me how it's coming up with that compensation amount, as this is not having a de-skewing effect. Rather, it actually seems to be far too large of an "anti-delay".

Path #1: Hold slack is -4.661 (VIOLATED)
===============================================================================
+---------------------------------------------------------+
; Path Summary ;
+---------------------------------+-----------------------+
; Property ; Value ;
+---------------------------------+-----------------------+
; From Node ; ff3 ;
; To Node ; ff4 ;
; Launch Clock ; clk1 ;
; Latch Clock ; clk1 ;
; Data Arrival Time ; -0.543 ;
; Data Required Time ; 4.118 ;
; Slack ; -4.661 (VIOLATED) ;
; Worst-Case Operating Conditions ; Slow 900mV -40C Model ;
+---------------------------------+-----------------------+

+-------------------------------------------------------------------------------------+
; Statistics ;
+------------------------+-------+-------+-------------+------------+--------+--------+
; Property ; Value ; Count ; Total Delay ; % of Total ; Min ; Max ;
+------------------------+-------+-------+-------------+------------+--------+--------+
; Hold Relationship ; 0.000 ; ; ; ; ; ;
; Clock Skew ; 5.084 ; ; ; ; ; ;
; Data Delay ; 0.787 ; ; ; ; ; ;
; Number of Logic Levels ; ; 0 ; ; ; ; ;
; Physical Delays ; ; ; ; ; ; ;
; Arrival Path ; ; ; ; ; ; ;
; Clock ; ; ; ; ; ; ;
; IC ; ; 5 ; 4.989 ; 61 ; 0.000 ; 2.573 ;
; Cell ; ; 9 ; 3.166 ; 39 ; 0.000 ; 0.804 ;
; PLL Compensation ; ; 1 ; -9.485 ; 0 ; -9.485 ; -9.485 ;
; Data ; ; ; ; ; ; ;
; IC ; ; 1 ; 0.529 ; 67 ; 0.529 ; 0.529 ;
; Cell ; ; 2 ; 0.086 ; 11 ; 0.000 ; 0.086 ;
; uTco ; ; 1 ; 0.172 ; 22 ; 0.172 ; 0.172 ;
; Required Path ; ; ; ; ; ; ;
; Clock ; ; ; ; ; ; ;
; IC ; ; 3 ; 2.587 ; 66 ; 0.000 ; 2.587 ;
; Cell ; ; 4 ; 1.321 ; 34 ; 0.000 ; 0.632 ;
+------------------------+-------+-------+-------------+------------+--------+--------+
Note: Negative delays are omitted from totals when calculating percentages

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Data Arrival Path ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; 0.000 ; 0.000 ; ; ; ; ; ; launch edge time ;
; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;
; -1.330 ; -1.330 ; ; ; ; ; ; clock path ;
; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;
; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;
; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;
; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;
; 0.762 ; 0.130 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;
; 0.762 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;
; 1.211 ; 0.449 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;
; 3.784 ; 2.573 ; RR ; IC ; 1 ; IOPLL_3C ; High Speed ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|refclk[0] ;
; 4.526 ; 0.742 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vco_refclk ;
; 4.526 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vctrl ;
; -4.959 ; -9.485 ; RR ; COMP ; 2 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vcoph[0] ;
; -4.155 ; 0.804 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|outclk[0] ;
; -4.155 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~io_48_lvds_tile/pllcout[4] ;
; -4.155 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|inclk ;
; -3.746 ; 0.409 ; RR ; CELL ; 1 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|outclk ;
; -1.330 ; 2.416 ; RR ; IC ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3|clk ;
; -1.330 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3 ;
; -0.543 ; 0.787 ; ; ; ; ; ; data path ;
; -1.158 ; 0.172 ; FF ; uTco ; 1 ; FF_X77_Y121_N55 ; ; ff3|q ;
; -1.072 ; 0.086 ; FF ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3~la_lab/laboutb[16] ;
; -0.543 ; 0.529 ; FF ; IC ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4|asdata ;
; -0.543 ; 0.000 ; FF ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+

+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Data Required Path ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; 0.000 ; 0.000 ; ; ; ; ; ; latch edge time ;
; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;
; 3.754 ; 3.754 ; ; ; ; ; ; clock path ;
; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;
; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;
; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;
; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;
; 0.791 ; 0.159 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;
; 0.791 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;
; 1.321 ; 0.530 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;
; 3.908 ; 2.587 ; RR ; IC ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4|clk ;
; 3.908 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;
; 3.754 ; -0.154 ; ; ; ; ; ; clock pessimism removed ;
; 3.754 ; 0.000 ; ; ; ; ; ; clock uncertainty ;
; 4.118 ; 0.364 ; ; uTh ; 1 ; FF_X77_Y121_N53 ; ; ff4 ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+

----------------------------
; Extra Fitter Information ;
----------------------------
HTML report is unavailable in plain text report export.
roeekalinsky
Contributor
5 years ago
Minor correction to my previous post. I just discovered that in the SDC I need to explicitly specify "derive_pll_clocks". With that in place, the same skew problem is still present, but the .sta.rpt more clearly refers to clock from the IOPLL output as a separate clock.

Path #1: Hold slack is -4.670 (VIOLATED)
===============================================================================
+-----------------------------------------------------------------+
; Path Summary ;
+---------------------------------+-------------------------------+
; Property ; Value ;
+---------------------------------+-------------------------------+
; From Node ; ff3 ;
; To Node ; ff4 ;
; Launch Clock ; iopll_ip_01_i|iopll_0|outclk0 ;
; Latch Clock ; clk1 ;
; Data Arrival Time ; -0.242 ;
; Data Required Time ; 4.428 ;
; Slack ; -4.670 (VIOLATED) ;
; Worst-Case Operating Conditions ; Slow 900mV -40C Model ;
+---------------------------------+-------------------------------+

+-------------------------------------------------------------------------------------+
; Statistics ;
+------------------------+-------+-------+-------------+------------+--------+--------+
; Property ; Value ; Count ; Total Delay ; % of Total ; Min ; Max ;
+------------------------+-------+-------+-------------+------------+--------+--------+
; Hold Relationship ; 0.000 ; ; ; ; ; ;
; Clock Skew ; 5.084 ; ; ; ; ; ;
; Data Delay ; 1.088 ; ; ; ; ; ;
; Number of Logic Levels ; ; 0 ; ; ; ; ;
; Physical Delays ; ; ; ; ; ; ;
; Arrival Path ; ; ; ; ; ; ;
; Clock ; ; ; ; ; ; ;
; IC ; ; 5 ; 4.989 ; 61 ; 0.000 ; 2.573 ;
; Cell ; ; 9 ; 3.166 ; 39 ; 0.000 ; 0.804 ;
; PLL Compensation ; ; 1 ; -9.485 ; 0 ; -9.485 ; -9.485 ;
; Data ; ; ; ; ; ; ;
; IC ; ; 1 ; 0.830 ; 76 ; 0.830 ; 0.830 ;
; Cell ; ; 2 ; 0.086 ; 8 ; 0.000 ; 0.086 ;
; uTco ; ; 1 ; 0.172 ; 16 ; 0.172 ; 0.172 ;
; Required Path ; ; ; ; ; ; ;
; Clock ; ; ; ; ; ; ;
; IC ; ; 3 ; 2.587 ; 66 ; 0.000 ; 2.587 ;
; Cell ; ; 4 ; 1.321 ; 34 ; 0.000 ; 0.632 ;
+------------------------+-------+-------+-------------+------------+--------+--------+
Note: Negative delays are omitted from totals when calculating percentages

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Data Arrival Path ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; 0.000 ; 0.000 ; ; ; ; ; ; launch edge time ;
; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;
; -1.330 ; -1.330 ; ; ; ; ; ; clock path ;
; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;
; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;
; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;
; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;
; 0.762 ; 0.130 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;
; 0.762 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;
; 1.211 ; 0.449 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;
; 3.784 ; 2.573 ; RR ; IC ; 1 ; IOPLL_3C ; High Speed ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|refclk[0] ;
; 4.526 ; 0.742 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vco_refclk ;
; 4.526 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vctrl ;
; -4.959 ; -9.485 ; RR ; COMP ; 2 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~vcoph[0] ;
; -4.155 ; 0.804 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst|outclk[0] ;
; -4.155 ; 0.000 ; RR ; CELL ; 1 ; IOPLL_3C ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|iopll_inst~io_48_lvds_tile/pllcout[4] ;
; -4.155 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|inclk ;
; -3.746 ; 0.409 ; RR ; CELL ; 1 ; CLKCTRL_3C_G_I21 ; ; iopll_ip_01_i|iopll_0|altera_iopll_i|twentynm_pll|outclk[0]~CLKENA0|outclk ;
; -1.330 ; 2.416 ; RR ; IC ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3|clk ;
; -1.330 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3 ;
; -0.242 ; 1.088 ; ; ; ; ; ; data path ;
; -1.158 ; 0.172 ; FF ; uTco ; 1 ; FF_X77_Y121_N55 ; ; ff3|q ;
; -1.072 ; 0.086 ; FF ; CELL ; 1 ; FF_X77_Y121_N55 ; High Speed ; ff3~la_lab/laboutb[16] ;
; -0.242 ; 0.830 ; FF ; IC ; 1 ; FF_X77_Y121_N53 ; Mixed ; ff4|asdata ;
; -0.242 ; 0.000 ; FF ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;
+----------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+

+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Data Required Path ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; Total ; Incr ; RF ; Type ; Fanout ; Location ; HS/LP ; Element ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+
; 0.000 ; 0.000 ; ; ; ; ; ; latch edge time ;
; 0.000 ; 0.000 ; ; borrow ; ; ; ; time borrowed ;
; 3.754 ; 3.754 ; ; ; ; ; ; clock path ;
; 0.000 ; 0.000 ; ; ; ; ; ; source latency ;
; 0.000 ; 0.000 ; ; ; 1 ; PIN_AR36 ; ; clk1_p ;
; 0.000 ; 0.000 ; RR ; IC ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|i ;
; 0.632 ; 0.632 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input|o ;
; 0.791 ; 0.159 ; RR ; CELL ; 1 ; IOIBUF_X78_Y115_N47 ; ; clk1_p~input~io_48_lvds_tile/ioclkin[2] ;
; 0.791 ; 0.000 ; RR ; IC ; 2 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|inclk ;
; 1.321 ; 0.530 ; RR ; CELL ; 5 ; CLKCTRL_2I_G_I7 ; ; altclkctrl_ip_01_i|altclkctrl_0|altclkctrl_ip_01_altclkctrl_2000_dpnsueq_sub_component|sd1|outclk ;
; 3.908 ; 2.587 ; RR ; IC ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4|clk ;
; 3.908 ; 0.000 ; RR ; CELL ; 1 ; FF_X77_Y121_N53 ; High Speed ; ff4 ;
; 3.754 ; -0.154 ; ; ; ; ; ; clock pessimism removed ;
; 4.064 ; 0.310 ; ; ; ; ; ; clock uncertainty ;
; 4.428 ; 0.364 ; ; uTh ; 1 ; FF_X77_Y121_N53 ; ; ff4 ;
+---------+----------+----+--------+--------+---------------------+------------+---------------------------------------------------------------------------------------------------+

----------------------------
; Extra Fitter Information ;
----------------------------
HTML report is unavailable in plain text report export.
roeekalinsky
Contributor
5 years ago
@Ash_R_Intel ?
Ash_R_Altera
Regular Contributor
5 years ago
Hi,
Sorry for the late response. One thing that I want to point out from your report is that the incoming clock is fed to the CLKCTRL block for some reason. Does the the CLKCTRL block has two fanouts, PLL and core logic?
If yes, then that might be the issue. The PLL will not be able to compensate for the network that is fed by the incoming clock. You may want to generate a same frequency clock from PLL to operate. I think the set_max_skew constraint should also be set between the two clock domains.

If the CLKCTRL block is driving only the PLL, then it can be avoided. Use dedicated clock pin to feed the PLL directly.

Regards
roeekalinsky
Contributor
5 years ago
Hi @Ash_R_Intel, thanks for the response.

Yes, clk1 is on a GCLK via a CLKCTRL block, and it fans out to core logic as well as to the reference clock input of the PLL. That is as intended, and shouldn't be an issue, unless I'm missing something here (?).

I'm not expecting the PLL to compensate for the delay of the clk1 distribution network. We're agreeing on that. The clk1 distribution network has an uncompensated insertion delay of about 3.8 to 3.9 ns, and that's fine.

What I am expecting is that the PLL will compensate for the delay of the clk2 distribution network only. And as such, clk2 should end up in phase with clk1, since clk1 is the reference clock input of the PLL. In other words, with the PLL compensating properly, there shouldn't be any significant skew between the endpoints of the clk2 network and the endpoints of the clk1 network.

Now, in the timing report snippet I provided, we can see that the total insertion delay of clk1 is 3.908 ns to the clock input of ff4, and 3.784 ns to the reference clock input of the PLL. That's plenty close enough, practically zero clock skew (just 0.124 ns), which is as expected. We'd expect to see very little clock skew between different endpoints of a given clock network, clk1 in this case, and that's what we're seeing. So far so good.

Now what doesn't look right is downstream of that, the compensation loop of the PLL. The reference clock input of the PLL, again, is an endpoint of the clk1 network, which arrives at 3.784 ns. So far so good. What I would then expect to see downstream is that the PLL's compensation loop in this topology should make it such that the endpoints of the clk2 network (such as the clock input of ff3) should also arrive at around 3.784 ns, plus/minus very little skew. And that's not at all what we're seeing. What we are seeing in the report is that clk2 arrives at the clock input of ff3 at -1.330 ns. That's about 5 ns earlier than it should be. Not good, and that's what remains unexplained.

Does my analysis make sense? Am I missing something?

BTW, about set_max_skew, I don't think that applies here (although I did try it anyway, and it didn't work). As I understand it, set_max_skew pertains to registered paths or ports, not to clocks. Although if I'm wrong or if I missed your point, please correct me and show an example of what you mean.

About generating both clocks as outputs of the same PLL, I understand how that could be a possible work-around. But there are practical reasons why that's not an option in my application, and I don't know of a reason why what I'm doing shouldn't work. I've used this clock topology in Xilinx devices before with great success, and Altera Arria 10 documentation also seems to suggest that it should work. And Quartus isn't complaining about it, it just produces timing reports that don't seem like it's working right. So I'd very much like to get to the bottom of it, figure out what's wrong, and make it right. Any more thoughts?

Thanks,
-Roee
Ash_R_Altera
Regular Contributor
5 years ago
Hi,
The PLL can compensate for the clocks that are generated by it, not other network path. Though both clk1 and clk2 are driven by the GCLK network, they may be placed far away (you may find out from the ChipPlanner).
You may experiment with the scenario that I explained in my previous answer. Generate both clk1 and clk2 from same PLL. That will definitely give you better result.
I did these experiments on a simple design and suggesting them based on those.

Regards.