Forum Discussion
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
- dlevit4 years ago
New Contributor
Hi Roee,
I'm in the same situation as you, moved recently from Xilinx to Intel, and puzzling about the same problem. Could you please share the approach which you found in regard to deskewing the clocks?
Thanks,
Dima