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

Forum Discussion

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

17 Replies

Recent Discussions

Quartus 25.1std | Signal Tap Crash

BSP generation for I2C

The DC_FIFO issue of Cyclone 10 GX devices

Request of private case

Schematics/layout for TerasIC SoCKit rev. D with Cyclone V