Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

PLL "normal" compensation mode in Cyclone V devices does not work as expected

It seems Altera does not allow to post anything longer; at least with chromium, the forum software just completely ripped my post apart.

So here is a very short summary:Cyclone V PLLs do not really support "normal" compensation mode; it seems the PLL does not compensate much.

This is especially bad because the clock to output delay has a very wide (4.640 ns) window in which output data might toggle, making any high speed parallel interface very hard to implement

This is rather depressing, because Cyclone 1 devices DO NOT have this problem.

I attach two designs I used to test this; measurements were done with an oscilloscope to verify real life timings

Result: TimeQuest is correct, the Cyclone V devices do not seem to offer any useful compensation of external clocks :-(

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    It seems Altera does not allow to post anything longer; at least with chromium, the forum software just completely ripped my post apart.

    So here is a very short summary:Cyclone V PLLs do not really support "normal" compensation mode; it seems the PLL does not compensate much.

    This is especially bad because the clock to output delay has a very wide (4.640 ns) window in which output data might toggle, making any high speed parallel interface very hard to implement

    This is rather depressing, because Cyclone 1 devices DO NOT have this problem.

    I attach two designs I used to test this; measurements were done with an oscilloscope to verify real life timings

    Result: TimeQuest is correct, the Cyclone V devices do not seem to offer any useful compensation of external clocks :-(

    --- Quote End ---

    Not sure about your testing and conclusion.

    PLL normal mode compensates for internal delay of clk from its pin to input register so that it appears at same relationship to data at io register as that at pins.

    I understand you can tap the scope on pins but you can't on io registers.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    Not sure about your testing and conclusion.

    --- Quote End ---

    Conclusion: Cyclone V devices do not compensate what they should in "normal" compensation mode.

    --- Quote Start ---

    PLL normal mode compensates for internal delay of clk from its pin to input register...

    --- Quote End ---

    Not really true. Maybe you mean "source synchronous compensation mode" ?

    Plase see my very first extracted screenshot from the Cyclone 5 manual. "normal" mode means the reference clock at the input pin should be in phase with the clock as it arrives on internal registers (not ONLY input registers).

    --- Quote Start ---

    ...I understand you can tap the scope on pins but you can't on io registers.

    --- Quote End ---

    True.

    But I can measure the difference between a pin driven by an I/O register, which is clocked directly from the clock pin and a pin driven by an I/O register clocked by a PLL (in "normal" compensation mode).

    This gives me an idea how much the PLL is compensating (the pin driven by the I/O register, which is clocked by the PLL should toggle earlier than the pin driven by the I/O register clocked directly by the clock pin).

    Result: Cyclone V PLLs do not really compensate anything (TimeQuest says the difference is minimal, measurements show that the difference is higher than TimeQuest thinks, but still quite small.)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    You are right about the term "Normal". Apologies but my doubts are still valid if I am not missing some points.

    The first diagram is just example when clock at register is indeed aligned with pll reference clock. It is an example case as stated on the diagram.

    PLL output can lag or advance relatively and this could make testing your way inconclusive.

    Moreover, I don't understand your view of "normal", how can a single PLL compensate for any delays to any registers yet having one clock output...or have I misunderstood the concept of delay compensation.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    --- Quote Start ---

    ...The first diagram is just example when clock at register is indeed aligned with pll reference clock.

    --- Quote End ---

    As I tried to explain: The "cyc5_pll_normal_mode.jpg" diagram is taken directly from the Cyclone 5 manual; it just explains what normal mode should be.

    --- Quote Start ---

    Moreover, I don't understand your view of "normal", how can a single PLL compensate for any delays to any registers yet having one clock output...or have I misunderstood the concept of delay compensation.

    --- Quote End ---

    Here is how PLL might be used to do that:

    https://www.alteraforum.com/forum/attachment.php?attachmentid=14344

    Note: The global clock network should be responsible for making sure that the "CLKOUT" output from the PLL arrives (almost) at the same time at all internal registers.

    Note: Cyclone 1 devices seem to be able to exactly achieve the described behavior. TimeQuest of Quartus 9.0 reports a "clock delay path" of close to 0ns (if you compile the design attached as "tpcyc_tco_test.zip" in the original post".

    Note: Cyclone 5 devices report a clock path delay of 4.633ns in the slow corner; so the PLL does not seem to compensate much (contrary to what is documented in the manual).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    My answer got obviously killed. So let me try again, this time in prose only in the hope that this will get through. Here is how "normal" mode should work. You have a reference input pin. This signal is put through the PLL at the output of the PLL you have a feedback output and a (regular) clock output pin. For this discussion the feedback output and the clock output have exactly the same frequency. Now the feedback output will be routed through a global clock network and from this network back to the feedback input pin of the PLL. The job of the PLL is to keep the feedback input aligned to the input reference pin. Now if you route the (regular) clock output through another global clock network, the arrival time at (all) the internal registers should be around the same as the arrival time at the feedback input pin of the PLL; this is what global clock networks provide: A very similar delay to all endpoints. Of course this match will not be 100%, but it will be very close. The result is, that the following signals should all be very closely aligned: Reference input pin should be aligned to feedback input pin (that's what the PLL provides), feedback input pin should be aligned to the regular clock signal as it arrives on the internal register clock inputs (that's what the global clock networks provide). So in summary, the reference input pin should be aligned to the signal as it appears on the clock inputs of the internal registers. That's how the PLL should compensate for the delay incurred by the global clock network. Now referring back to the designs I posted: The Cyclone 1 design exactly provides that; for the Cyclone 1 design TimeQuest reports a delay of very close to 0 from the reference input clock pin to the internal registers for the design for fast and slow corners (the delay simply stays very close to 0). The same is absolutely NOT true for the Cyclone V design; here TimeQuest reports a huge delay from the reference input pin to the clock pins of the internal registers; even worse TimeQuest reports hugely different delay for the fast and slow corner; that in turn means the PLL does not really seem to compensate anything useful. And in turn you have a huge uncertainty how your I/O timings will work out, making Cyclone V devices unusable for any high speed parallel interface :-(.