Shop OBEX P1 Docs P2 Docs Learn Events
P2 clock issues — Parallax Forums

P2 clock issues

rjo__rjo__ Posts: 2,114
in Propeller 2
Issue 1

If we set the system clock from Spin2 in the usual way...what actually happens?
'debug_clock.spin2
CON
_clkfreq	= 297_175_000

VAR
PUB go() 

debug(`d `udec_(clkfreq))

debug shows an actual clkfreq = 297_187_500

Is the actual system clock 297_175_000 with a 12KHz jitter? or is actually a solid 297_187_500?

debug_clock1.spin2 exercises the logic a little.


spin2
spin2
debug_clock.spin2
80B
spin2
spin2
debug_clock1.spin2
639B

Comments

  • JonnyMacJonnyMac Posts: 9,104
    Is is possible to get 297_175_000 manually? I never use odd frequencies, so I've not seen this problem. If 297_175_000 can be achieved manually, perhaps there's a better algorithm that can be applied to the compiler.
  • rjo__rjo__ Posts: 2,114
    edited 2020-12-03 21:08
    JonnyMac et.al.

    Yes. It is what Rayman uses to set his NCO frequency... he wrote a nice description at rayslogic.com/Propeller2/NCO.htm

    He targets the NCO frequency to be 12.375 MHz.

    The issue for me was that the accuracy depends up the ratio between the system and NCO periods. At 297_175_000 you end up with something close to nice integer which can be fed back into the smart pin... producing an error frequency of about 7.2916667 kHz

    but if the actual system is running at 297_187_500 the ratio is not so close to a nice integer and the error frequency goes up ton about
    7.8125 kHz

    The problem tends to gets worse as your intended output frequency increases.

    et.al.
    I don't have a scope... but I think actual behavior of the system clock is important.

    Anyone?

  • RaymanRayman Posts: 14,646
    Wonder if we need a different crystal to get it exactly...

    Fortunately, most things don't seem to need precision...
  • rjo__rjo__ Posts: 2,114
    But some things do... I'm working on one right now.

    Stay tuned and be ready:)

    Whatever it is, it is.
  • jmgjmg Posts: 15,173
    rjo__ wrote: »
    Issue 1
    debug shows an actual clkfreq = 297_187_500
    Is the actual system clock 297_175_000 with a 12KHz jitter? or is actually a solid 297_187_500?
    Why would there be jitter ?

    Expanding on the above,
    1-297175000/297187500 = 42.061ppm deviation
    or one part in = 23775

    P2 uses integer dividers of 6-10 bits, in the PLL, so the quantize/rounding effect of those will determine the actual PLL result.

    You might be able to manually find a N/M ratio that is better than 42ppm, but 42ppm is sounding quite good.
    If you really need better than 42ppm, you will need better than a simple crystal ?

  • AribaAriba Posts: 2,690
    You are aware that the difference from 297_175_000 to 297_187_500 is about 42 ppm, this in the region of the accuracy of a normal crystal.
    If you have a high precision clock source at the P2 input, you need to choose a system frequency that the PLL divider and multiplier together can produce exactly.
    rjo__ wrote: »
    ...
    but if the actual system is running at 297_187_500 the ratio is not so close to a nice integer and the error frequency goes up ton about 7.8125 kHz
    ...

    You don't need a nice integer ratio for exact NCO frequencies. The ratio between system clock and NCO frequency affects the jitter, but not the error of the output frequency.

    Andy
  • TonyB_TonyB_ Posts: 2,178
    edited 2020-12-03 22:55
    A system clock of 297_175_000 Hz is not achievable with a 20.0MHz crystal.
    The closest possible is 20MHz * 951 / 64 = 297_187_500 Hz.
  • cgraceycgracey Posts: 14,153
    Spin2 in PNut.exe (and the PropellerTool.exe) computes the best fit. There will be no unusual jitter. It just can't always hit the exact frequency.
  • rjo__rjo__ Posts: 2,114
    So... if we put a quality scope on the system clock output ... the answer is 297_187_500 Hz?
  • rjo__rjo__ Posts: 2,114
    Jmg,

    The problem gets worse the higher you go. Let's say trying to output 121.223MHz. +/- 2%.

    There are a lot of ways to skin this cat... I'm just trying to get the lay of the land at this point.

    Thanks,
    Rich
  • AribaAriba Posts: 2,690
    rjo__ wrote: »
    So... if we put a quality scope on the system clock output ... the answer is 297_187_500 Hz?

    If there were a system clock output, and the scope had a frequency counter included and the crystal oscillates with exactly 20 MHz +- 0 ppm.
  • rjo__rjo__ Posts: 2,114
    Ariba,

    Thank you.

  • Peter JakackiPeter Jakacki Posts: 10,193
    I use 25 or 26Mhz crystals with the Si5351 clock generator to output a default 20MHz clock on the P2D2. This is but one of the reasons I used the Si5351 but this also allows me to pick the precise frequency that I need as well. Mind you though, I need to sit down and write some routines that will do this properly, either changing the P2 PLL if it can, or by also changing the Si5351 settings as well. There's also an option to use a cheap high precision 26MHz TXCOs on the flipside rather than a crystal.
  • jmgjmg Posts: 15,173
    rjo__ wrote: »
    So... if we put a quality scope on the system clock output ... the answer is 297_187_500 Hz?

    Yes.
    rjo__ wrote: »
    The problem gets worse the higher you go. Let's say trying to output 121.223MHz. +/- 2%.
    2% should be no problem, with integer ratios.
    A simple x6 (PFD = 20MHz) gives 120MHz which is 1.02% error
    As PFD lowers you can get more choices :
    eg 20M/17 gives a solution x 103, to give = 0.038% error
    Another solution is 20MHz / 33, then x 200, for a ~ 90ppm error
    Lower PFD's give slightly higher jitter, so usually a design chooses the highest PFD that is 'good enough' to comfortably meet spec.



  • RaymanRayman Posts: 14,646
    Chip once remarked in the mixed signal scope thread:
    You could make a nice frequency counter using the reciprocal-counter smart pin modes, too.

    I've been meaning to try that... Might be fun with things like this...
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    One could also measure the actual sysclock by measuring the apparent period of a known signal (such as the 32.768kHz output of an RTC)
  • rjo__rjo__ Posts: 2,114
    Many thanks to all.

    Peter,

    I was wondering if you have tried Chips new stuff with the debugger... I'm a big fan. Don't have to use serial to see results... couple of lines of code... wow. But, I think it might assume a 20Mhz crystal. Can you run any of the resent examples in PNUT 35b download?

    Regards all.

    Thanks
    Rich

  • cgraceycgracey Posts: 14,153
    rjo__ wrote: »
    Many thanks to all.

    Peter,

    I was wondering if you have tried Chips new stuff with the debugger... I'm a big fan. Don't have to use serial to see results... couple of lines of code... wow. But, I think it might assume a 20Mhz crystal. Can you run any of the resent examples in PNUT 35b download?

    Regards all.

    Thanks
    Rich

    It just needs 10MHz or more from a crystal or external source. It can't use RCFAST.
  • rjo__rjo__ Posts: 2,114
    Chip...

    I think I got myself confused by putting different values for the crystal into the configuration... I got away with values close to 20MHz but problems away from that value... putting in the wrong crystal frequency was probably not a good idea:)
  • cgraceycgracey Posts: 14,153
    rjo__ wrote: »
    Chip...

    I think I got myself confused by putting different values for the crystal into the configuration... I got away with values close to 20MHz but problems away from that value... putting in the wrong crystal frequency was probably not a good idea:)

    I think _xtalfreq is the symbol that lets you set the crystal frequency away from 20MHz. Then, _clkfreq lets you select the PLL frequency.
  • rjo__rjo__ Posts: 2,114
    yes. I understood it all. Just misused it;)
Sign In or Register to comment.