Forum Discussion

TK99's avatar
TK99
Icon for New Contributor rankNew Contributor
11 months ago

Timing Analyzer - pll clkout - pessimistic timing estimation

Hello,

I'm wondering about the timing analysis of the Quartus STA.

I have a small test design with a PLL and some test logic drven by the PLL output.

Simple question: Why doesn't use the STA the OUTPUT of the PLL as the entry point for the worst case analysis?

For my opion the pll outclk is one logical AND physical net = dedicated clock network and should be the entry point for the setup/ hold analysis.

As shown in the picture the worst case timing estimation is starting at the PLL input pin.
I can't belive that the possible cycle to cycle (launch-latch = ascending edges) jitter (would be quite high) is the reason for that.

The timing estimation should be the same up to Line 16, why not?

The option 'clock-path-pessimism-removal' is not longer available.

best regards Tim

Timing

5 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    11 months ago

    To clarify your terminology first, the clock defines the "data required time" for both meeting setup and hold timing requirements.

    It appears from your screenshot that the same base clock is used to drive the PLL which in turn clocks both the source register and the destination register in the path you are analyzing.

    But you have to remember that there will be clock skew between the clock arriving at the source register and destination register that needs to be taken into account. As such, the entire clock path(s), including its entry on the I/O pin and through the PLL (which performs compensation as noted in the COMP row) must be taken into account for the analysis.

    Also, notice that the "latch edge time" in the data required path starts one cycle later (is this a 1GHz clock?) so that has to be taken into account for the data required path.

    Seeing the waveform view of this path would help make things clearer.

    • TK99's avatar
      TK99
      Icon for New Contributor rankNew Contributor
      11 months ago

      Hello,

      first of all thank you for your reply!

      The analyzed path is using the clock output of the PLL. (250MHz)

      Due to the nature of the PLL there will be some jitter.

      The Agilex 5 data sheet is defining a 'period jitter for dedicated clock output of 175ps p-p' (max. >100MHz)

      For me it seems that the jitter is included in the calculations from line 1 to 16 of the given picture.

      The difference for the clock at the end in line 16 is .673 - 0.42 --> 253ps is more than the expected 175ps.

      My initial problem is the following.
      The Agilex 5 does not support a dedicated LVDS Serdes with 1:6 or 1:7 ratio!

      This was surprising for me because Cyclone 10GX and Arria 10 were able to support such things and Agilex 7 too!

      My idea was to use the DDRIO to be able to implement the required interface (at least 504MBit ... up to 700MBit).
      AN433 is the guide to implement source synchronous interfaces with some hints regarding clocks in the chapter 'input clocks'.

      For that reason it seems to be a better approach to use an external clock without the PLL inside the FPGA.
      But up to now I was still not able to have a implementaton with a valid timing.

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    11 months ago

    I think something is wrong with your post, causing the picture/attachment to not be visible.

    Could you try attaching it again?

    This is what I am seeing and I cant open the file.

    Could you help to share your design by archiving the project (Project > Archive Project) so that I can investigate it further?

    Regards,

    Richard Tan

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    10 months ago

    Any update on this?

    Do you need further help in regards to this case?

    Regards,

    Richard Tan

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    10 months ago

    We noticed that we haven't received a response from you regarding the latest previous question/reply/answer, and will now transitioning your inquiry to our community support. We apologize for any inconvenience this may cause and we appreciate your understanding.


    If you have any further questions or concerns, please don't hesitate to reach out. Please login to https://supporttickets.intel.com/s/?language=en_US, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


    The community users will be able to help you on your follow-up questions.


    Thank you for reaching out to us!


    Best Regards,

    Richard Tan