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

Thanks, @Ash_R_Intel.

For experiment's sake, modifying my trivial design example to feed the PLL directly from the FPGA input pin, the PLL's refclk arrives at 0.704ns, and clk2 arrives at ff3 at -0.687ns. And to recap the original scenario, having a CLKCTRL upstream of the PLL, the PLL's refclk arrives at 3.784ns, and clk2 arrives at ff3 at -1.334ns.

With the addition of an upstream CLKCTRL / GCLK in the latter case, one would expect a later clk2 arrival time, not earlier as observed. So one must ask, does this observed result even make sense on the face of it?

It's the compensation figure in the PLL that is coming up vastly different between the two scenarios, -5.601ns vs. -9.485ns, respectively, and that's what's responsible for clk2 arriving even earlier with the upstream CLKCTRL rather than much later as one would expect. It is unclear where that difference in compensation arises, as the clock distribution downstream of the PLL is identical between the two scenarios, and I think we're both agreeing that the PLL should not in any way be compensating for the added delay of a CLKCTRL / GCLK upstream of it. Right? The observed difference in compensation does not correspond to a difference in the clock network delays. So from where does this difference in compensation arise?

A purely speculative possible interpretation of the observations above, it almost looks as though Quartus is attempting to adjust the delay of the compensation loop somehow to phase-align clk2 to the FPGA clock input pin in both cases, as though it IS trying to compensate for the added delay of the upstream CLKCTRL / GCLK if present (which is NOT what we expect nor want). Could that be the case? Is that what it's trying to do? And if so, is there a way via constraints or otherwise to prevent Quartus from doing that?

Taking a step back:

The available documentation (UG-01155 and A10-HANDBOOK) does seem to indicate, in the text and in block diagrams, that the IOPLL can optionally receive its refclk input from a GCLK or RCLK network. So, is that fully supported, or not? And if so, what are the expected compensation characteristics with refclk fed from a GCLK or RCLK network?

As to the suggestion of feeding the PLL directly from the FPGA input pin instead:

The trivial design example I presented for discussion is just that. In reality, I don't have the luxury of feeding the PLL directly from the FPGA's input pin. What I'm developing is a reusable IP block that will be integrated into numerous different FPGA designs, where other parties may own the top level and other IP blocks residing in it. There will generally not be much visibility between parties and their respective IP, nor the opportunity to collaborate on the top level clocking scheme. The top level FPGA designs into which this IP block will be integrated may have different and unknown top level clocking schemes, and I can't really make any assumptions about the ultimate origin of the system clock provided to my IP block other than it will already be on a GCLK when I receive it. Then, internally in my IP block, I have a need to generate one or more derived clocks at integer multiples of the incoming system clock frequency and in-phase with it (and possibly also with dynamic gating).

I hope that gives you some context and a better idea of what I'm ultimately trying to accomplish. And if you have other suggestions that can accomplish these requirements within these limitations, I'm all ears.

I should mention too, just for background, that I've been doing this routinely in Xilinx devices, with which admittedly I am far more familiar. I naturally assumed that a similar capability exists in Altera devices, and the documentation seemed to suggest as much, though not clearly... I hope that was not an incorrect assumption/interpretation on my part.

Fundamentally, the capability I'm seeking is this: To be able to take into my block what is already a global clock, and from it to generate new global clocks that are in-phase with it. Is that possible in the Arria 10's PLL / clocking architecture, or not? And if so, how?

I look forward to your input.

Thanks,
-Roee

Hi,

The compensation factor is dependent upon the routing that takes place during fitter. With design changed, the placement of the CLKCTRL blocks and the registers also changes. So, it is very much possible to have that variation in the compensation factor.

I agree, PLL does not compensate for the upstream CLKCTRL. It just takes care of the clocks that are generated from it.

Coming back to the original query, want to mention couple of points here.

1) GCLK networks provide less skew for a clock that passes through it.

2) Two different clocks on two different CLKCTRL blocks cannot have identical delays, just because of the fact that they are independent and have to reach to different flops in the chip and different locations.

3) For the PLL generated clocks as well, the same logic applies. They cannot have zero skew between themselves because they drive different paths.

4) The PLL definitely maintain the phase relationship between its input and output clock.

5) As long as the tool reports that there are no timing failures in the design, skews between the clocks should not be a matter of concern.

6) When the data path changes from one clock to other clock, it is better to either provide a set_max_skew constraint or declare that path as a false path.

If you look at a path in the tool driven by the same clock going through CLKCTRL, you will find a near to zero skew, but the same cannot be expected from different clock paths even though they have fixed relation. The skew on all the reported paths between the two clocks however, should remain same. If the tool reports the same clock skew number in these paths, then we are good.

Hope this helps.

Regards.

Hi @Ash_R_Intel,

Thanks for the feedback. I've gathered additional information on this issue from other sources as well, and the bottom line is that the Arria 10 IOPLL can't properly support the approach I was trying to take. It can't phase-align a GCLK output to a GCLK reference input. So I will use a different approach to accomplish my design goals.

Note however that there is an incorrect piece of information here, an incorrect understanding/assumption that we both made, as I've now learned. And this is key to the whole thing.

@Ash_R_Intel wrote:
>> I agree, PLL does not compensate for the upstream CLKCTRL. It just takes care of the clocks that are generated from it.

Turns out that's not entirely true, and that's the primary cause for the skew I'm seeing. I've received confirmation that, as I suspected, Quartus is actually trying its best to compensate for all of the delay upstream of the IOPLL, including for the upstream CLKCTRL / GCLK if present (presumably coarsely matching those delays using static delays alone). Even if there's an upstream CLKCTRL / GCLK, it will try to match the output phase of the IOPLL to that of the FPGA input pin upstream of it all, not to the phase of the GCLK at the IOPLL's refclk input. Though this is never made clear in the documentation, this is the defined behavior for the IOPLL's normal mode when downstream of a GCLK. And there is no means by which to disable this behavior.

I wanted to clarify that here for anyone else who may be affected by this.

Thanks,

-Roee

Apologies for that statement. You are right, the IOPLL does try to compensate from pin to pll path. Please refer below link:

Intel® Quartus® Prime Pro Edition Help version 21.1 - PLL Compensation Mode logic option

Regards