Cyclone V PLL Normal compensation not working as it should

[jrrguzman]

Hi,

I'm trying to meet IO timing with a Cyclone V based design. The design uses a clock (135 MHz) connected to a dedicated clock PAD with direct connection to the PLLs. After setting up the PLL into normal compensation mode, I find out that the PLL is not compensating what it should (about 2 ns of additional clock skew) and my IO can't meet timing, no matter what I do (and I've tried several approaches but non of them work). Is there a known issue with the clock network compensation for these devices?

I'm currently using Quartus Prime Standard 17.0.

I would appreaciate any help in this matter.

Kind regards

[LinuxFanatic2018]

​How you determine that "not compensating"? Modeling? Oscilloscope? Or just timing analysis report tells you that? Give more details about.

[jrrguzman]

Hi,

After running timing analysis and checking any IO path, I see that the PLL compensation does not cover the whole delay introduced by the clock network by far.

If I check the Cyclone V device handbook Volumen 1 I get this (p91, s4-33):

An internal clock in normal compensation mode is phase-aligned to the input clock pin. The external clock output pin has a phase delay relative to the clock input pin if connected in this mode. The Intel Quartus Prime TimeQuest Timing Analyzer reports any phase difference between the two. In normal compensation mode, the delay introduced by the GCLK or RCLK network is fully compensated.

So from that statement and the image describing normal mode compensation provided by Intel/Altera within the same document I should see almost 0 skew between the clock PLL input fref and any register driven by the PLL output.

Maybe I am confusing or misunderstanding how the compensation works. That's why I'm posting this on the forum.

Cheers

[jrrguzman]

Hi,

Could anyone from Intel/Altera give me any feedback about this topic? Are my assumptions right or am I missing something regarding the compensation modes for the Cyclone V PLL?

The issue is as follows:

I am using a PLL with normal compensation. From my understanding this compensation should account for the clock routing delay from the PLL to the registers, making the skew between the PLL input clock and the clock arriving at the register almost 0. What I see when I implement the design is that I have a skew of several nanoseconds, no matter what I do. This becomes specially bad when I try to drive the IO registers and meet timing.

Thanks in advance.

[jrrguzman]

Any takers for this question?

I am using a PLL with normal compensation. From my understanding this compensation should account for the clock routing delay from the PLL to the registers, making the skew between the PLL input clock and the clock arriving at the register almost 0. What I see when I implement the design is that I have a skew of several nanoseconds, no matter what I do. This becomes specially bad when I try to drive the IO registers and meet timing.

As an example, my design (Cyclone V SoC) uses a 125 MHz clock which is used to clock some FPGA logic and the an external device. There is a SDR bus between the FPGA and the external device running at that frequnecy. The clock (single ended) is placed on a positive clock pad. I'm trying to meet IO setup/hold with this clock, but it can't be done with a direct connection (tried and discarded due to the long propagation delay of the clock network) so I am currently using a PLL phase shift in combination with a multicycle constraint for setup (no hold) to shift the data valid window.

The settings for the PLL are as follow: PLL, fin=fout=125 MHz, Phase shift: 144°, Normal compensation.

The location of the IOs and the reduced logic size allows me to use a regional clock network, so I force the output clock buffer of the PLL to be regional.

The output registers are are forced to be packed into the IOs to reduce as much as possible the data propagation delay.

With all these, the PLL does not seem to be working as expecting:

8.823   5.623            

3.200    0.000            (source latency, due to phase shift I guess)

3.200    0.000         1   PIN_AF14

3.200    0.000   RR   IC   1   IOIBUF_X32_Y0_N1

4.100    0.900   RR   CELL   1   IOIBUF_X32_Y0_N1

5.421    1.321   RR   IC   1   PLLREFCLKSELECT_X0_Y7_N0

5.754    0.333   RR   CELL   1   PLLREFCLKSELECT_X0_Y7_N0

5.754    0.000   RR   IC   10   FRACTIONALPLL_X0_Y1_N0

1.841    -3.913   RR   COMP   1   FRACTIONALPLL_X0_Y1_N0

1.841    0.000   RR   IC   1   PLLOUTPUTCOUNTER_X0_Y0_N1

3.369    1.528   RR   CELL   2   PLLOUTPUTCOUNTER_X0_Y0_N1

4.511    1.142   RR   IC   1   CLKCTRL_R31

4.771    0.260   RR   CELL   1390   CLKCTRL_R31

7.899    3.128   RR   IC   1   DDIOOUTCELL_X14_Y0_N44

8.823    0.924   RR   CELL   1   DDIOOUTCELL_X14_Y0_N44

So I'm getting an effective clock skew of -5.6 ns. As can be seen, the PLL compensates for 3.913 ns. Anyone can explain to me if this is the intended behaviour, or what am I doing wrong?

Kind regards

[jrrguzman]

Any Intel employee who can answer this?

I am using a PLL with normal compensation. From my understanding this compensation should account for the clock routing delay from the PLL to the registers, making the skew between the PLL input clock and the clock arriving at the register almost 0. What I see when I implement the design is that I have a skew of several nanoseconds, no matter what I do. This becomes specially bad when I try to drive the IO registers and meet timing.

As an example, my design (Cyclone V SoC) uses a 125 MHz clock which is used to clock some FPGA logic and the an external device. There is a SDR bus between the FPGA and the external device running at that frequnecy. The clock (single ended) is placed on a positive clock pad. I'm trying to meet IO setup/hold with this clock, but it can't be done with a direct connection (tried and discarded due to the long propagation delay of the clock network) so I am currently using a PLL phase shift in combination with a multicycle constraint for setup (no hold) to shift the data valid window.

The settings for the PLL are as follow: PLL, fin=fout=125 MHz, Phase shift: 144°, Normal compensation.

The location of the IOs and the reduced logic size allows me to use a regional clock network, so I force the output clock buffer of the PLL to be regional.

The output registers are are forced to be packed into the IOs to reduce as much as possible the data propagation delay.

With all these, the PLL does not seem to be working as expecting:

8.823   5.623            

3.200    0.000           (source latency, due to phase shift I guess)

3.200    0.000         1   PIN_AF14

3.200    0.000   RR   IC   1   IOIBUF_X32_Y0_N1

4.100    0.900   RR   CELL   1   IOIBUF_X32_Y0_N1

5.421    1.321   RR   IC   1   PLLREFCLKSELECT_X0_Y7_N0

5.754    0.333   RR   CELL   1   PLLREFCLKSELECT_X0_Y7_N0

5.754    0.000   RR   IC   10   FRACTIONALPLL_X0_Y1_N0

1.841    -3.913   RR   COMP   1   FRACTIONALPLL_X0_Y1_N0

1.841    0.000   RR   IC   1   PLLOUTPUTCOUNTER_X0_Y0_N1

3.369    1.528   RR   CELL   2   PLLOUTPUTCOUNTER_X0_Y0_N1

4.511    1.142   RR   IC   1   CLKCTRL_R31

4.771    0.260   RR   CELL   1390   CLKCTRL_R31

7.899    3.128   RR   IC   1   DDIOOUTCELL_X14_Y0_N44

8.823    0.924   RR   CELL   1   DDIOOUTCELL_X14_Y0_N44

So I'm getting an effective clock skew of -5.6 ns. As can be seen, the PLL compensates for 3.913 ns. Anyone can explain to me if this is the intended behaviour, or what am I doing wrong?

Kind regards