• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 99 subscribers
  • Views 2390 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x clock jitter

Kees van de Leur
Prodigy 60 points

Hi all,

we have a design with an XAM3359BZCZ100 and see clock behavior we can't explain. There seems to be excessive jitter on the 200MHz from the DPLL_CORE dpll. To investigate we let the PRU generate a 25MHz square wave by simply making an output low for 4 clocks, then high for 4 clocks. We run the processor from a 25MHz Xtal and have the internal signal CLCKIN routed to pin CLKOUT1. As expected, both pins now show a 25MHz square wave. However, there is a severe jitter of almost 10ns (pk-pk) between the two clocks. As both are ultimately linked to the 25MHz Xtal we were expecting a jitter of a few hundred ps. Spread Spectrum Clocking is off and in the standard setup the dpll is running at 2000MHz (N=24, M=1000, M4=10). As this is on the upper end of the dpll range we have also tried it with 1000MHz (N=24, M=500, M4=5). Again, 25MHz clocks and 10ns jitter.

Am I missing something here?

regards,

  Kees

  • 0
    TI__Guru**** 393215 points
    Hi Kees,
     
    Please read section 4.2.4 of the AM335X Datasheet Rev. F. CLKOUT behaiviour is explained in the note at the beginning of this section.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 60 points

    Thanks Biser,

    I have seen that note and basically it says that there is no guarantee on jitter performance. That's fine with me, but I would like to know why there is so much jitter. Comparing CLKOUT with the Xtal signal shows around 1ns jitter, probably because of a very bad measurement set-up. So the observed 10ns jitter basically stems from the core dpll. I don't know much about digital pll's, but in an analog pll with synchronous dividers that amount of jitter would be called excessive, I guess.


    regards, Kees

  • 0 in reply to Kees van de Leur
    TI__Guru**** 393215 points
    What the note explains is that the CLKOUT outputs have had no timing constraints imposed during the design stage, therefore their jitter performance is not guaranteed. CLKOUT1 is a buffered output from the main oscillator, it doesn't come from a PLL, and it isn't synchronized to any internal clocks.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 60 points

    Hi Biser,

    that is all clear and, as I said in the previous mail, it is ok if it is not guaranteed. I just want to understand why a pll, that is locked to a Xtal, can have that amount of jitter. After all, as the name implies, it is phase locked to the Xtal.

    Kees

  • 0 in reply to Kees van de Leur
    TI__Guru 62855 points

    The PLL multiplies the pre-divided reference clock by the value of M*2.  In your case, the pre-divider is configured to 24 which divides the oscillator reference clock by 25 (N+1) and provides a 1MHz reference to the digital PLL.  The output of the DPLL is divided by the value of M*2 and this divided down clock is input to the phase comparator which checks the phase of this signal relative to the pre-divided reference clock of 1MHz.  Therefore, the DPLL will only correct its output frequency at the rate of 1MHz.  The DPLL is locked as long as the two clock signals going into the phase comparator never slips (inserts or drops) a cycle of the 1MHz clock.

    If you measure clock period jitter, the result would be a few ps.  The minimum clock period jitter is the most important parameter for core logic because this determines if the minimum clock period provides enough time for the internal logic to settle between rising edges of the clock.  However, your measurement accumulates any long-term drift error over many clock cycles.   

    Configuring the DPLL with a higher frequency pre-divider reference clock would reduce the time between DPLL updates which should improve long-term drift.  You might want to try to increase the DPLL update rate by using a value of 0 for N and a value of 40 for M.

    Regards,
    Paul

  • 0 in reply to peaves
    Prodigy 60 points

    Hi Paul,

    that's it! We have changed the values to N=0 and M=40 as you suggested. The jitter went from 10ns to around 1ns, excellent! Now that we know where to look for, we can change the other pll's as well, should we wish to do so. The 1MHz reference clock is only needed for a 1MHz granularity in the clock frequencies, which we absolutely do not need. The 25MHz will do just fine, except maybe for the peripheral pll. That has to be 5MHz to maintain the 960MHz, still a lot better than 25.

    Thanks Paul, and we can probably close this subject now.

    Regards,

      Kees

  • 0 in reply to Kees van de Leur
    TI__Guru 62855 points

    You need to be careful changing DPLL register values from the standard values.  The DPLLs have limitations that are not disclosed in the TRM.  For example, the maximum pre-divided reference clock frequency supported by ADPLLLJ is much lower than the maximum pre-divided reference clock frequency supported by ADPLLS.

    The alternate values I provided in my previous post were verified to be within the valid operating range of ADPLLS. 

    We may need to discuss your requirements in more detail before you begin changing DPLL settings.

    Regards,
    Paul

  • 0 in reply to peaves
    Prodigy 60 points

    Hi Paul,

    In general we would like to have least amount of (un-controlled) jitter in the system as possible. If we need jitter, for EMC-reasons for instance, we could revert to Spread Spectrum Clocking to do that in a controlled way.

    So basically the peripheral pll is the difficult one, being the only ADPLLLJ. Is it possible to run that one with N=4, M=192 and M2=5? That would give us a reference clock at 5MHz and the same two clocks at 960 and 192MHz as before.

    The other 4 pll's could then run with N=0 or 4, and the appropriate M dividers. Only the DDR3 pll would have a slightly different frequency of 305MHz i.s.o. 303.

    regards,

      Kees

  • 0 in reply to Kees van de Leur
    TI__Mastermind 27890 points

    For the ADPLL_LJ PHY (PER_PLL in this case), your REFLCK frequency (CLKIN/(N+1)) must be between 0.5 and 2.5MHz and your DCO frequency ((M/(N+1))*CLKIN) must be between 500 and 2000MHz. Values outside these bounds are not supported and could result in undefined behavior.

    Don't forget that the LJ PHY also adds a Sigma-Delta divider select function that needs to be programmed based on the formula provided in the associated register (CM_CLKSEL_DPLL_PERIPH). Incorrectly setting this Sigma-Delta divider select will negatively impact jitter.

  • 0 in reply to -DK-
    Prodigy 60 points

    Thanks Paul,

    so the minimum value of N for the PER_PLL is 9 for a 2.5MHz refclk. With M=484 we end up with the same frequencies of 192 and 960MHz, and a DCO at 1920MHz. The DCO is the same as before, so Sigma-Delta is still at 4. At the end the refclk is still 2.5 times higher than before, leading to less jitter.

    If there are no other pitfalls then this is probably what we will do.

    Thanks again Paul for your swift and excellent response.

    Regards, Kees

  • 0 in reply to Kees van de Leur
    TI__Mastermind 27890 points

    Kees,

    Yes, these settings are ideal for the jitter performance of PER_PLL.  A lot of work has been out into quantifying the optimal parameters of this PLL lately so it's nice to see this effort bear fruit for our customers.

    -DK

  • 0 in reply to peaves
    Genius 5940 points

    Hello Paul,

    Now, We are changing ADPLLS register value for LCDC Clock gitter issue.
    However ADPLLS is unlocked depending on the register setting value.
    So I'm looking for the information. And then I found this your post.

    peaves said:

    The alternate values I provided in my previous post were verified to be within the valid operating range of ADPLLS. 



    But I couldn't find your previous post.
    Please let me know the limitations for ASPLLS

    Best Regards,
    Taka

  • 0 in reply to Takahiro Ogo
    TI__Guru**** 393215 points
    Paul means his previous post on this same thread: e2e.ti.com/.../1126396