Counter PLL won't sync at 5.71 MHz (Never Mind)

Rayman

I'm looking into what frequencies can be generated by the PLL without jitter...
·
Doing this by setting PHSA in an assembly loop.
·
I've been able to generate 7 frequencies in the range of 4 to 5.71 MHz this way.

But, the PLL won't sync right and I don't see why...
·
I've attached my test file set to produce a perfectly symmetric 5.71 MHz square wave [noparse][[/noparse]175ns period] in NCO mode.
But, when I turn on the PLL, it won't sync.· I think it should sync with anything between 4 and 8 MHz, so I'm stumped...

Anybody see what's going on?

Thanks to Phil for showing me the error of my ways.

Post Edited (Rayman) : 7/11/2008 6:01:19 PM GMT

VIRAND

This is an idea but I'm definitely not an expert on the counters and I think I really need to get a
hard copy of the Propeller Manual soon. It may be OT because it's not relevant to your code.

Is this way of synthesizing frequencies possible? ... :
To use a clock crystal for the propeller that's 8.192 Mhz (yes this works).
To output one bit of a counter running at 8.192 Mhz x PLL to get 1 kHz (I don't know but I think so).
To count the counter by not only 1 but by adding any other number to it. (I'm not sure but I think so).

The number that you add to the counter should make that (n Khz) frequency come out of the bit without any jitter
up to a certain frequency maybe 4.096 Mhz and probably even 5.71 Mhz.
This is like square wave DDS I guess, and the PLL shouldn't be unstable with it for
any reason that I know about since PLL would be crystal controlled to a multiple of 8.192 MHz all the time.

(This is simple: a counter clocked by F=8192 will output F=1 on bit 12 unless it's not counting by ones,
in which case bit 12 outputs F=whatever number is added to the counter on every clock tick.)

I'll assume that since everyone says the Propeller can't synthesize High Frequencies without jitter that
this idea can't be done, but maybe only the method of locking the PLL on variable frequencies jitters.

Post Edited (VIRAND) : 7/9/2008 10:25:45 PM GMT

stevenmess2004

If I remember correctly, it goes like this. The input to the PLL must be between 4 and 8 MHz. The only frequency you can get that is perfect in that range is 5MHz (with a 5MHz crystal, you could probably get away with 10MHz if its just for mucking around with). So the output frequencies of the PLL will be 80MHz or the same as the clock speed. If you use a different clock than you will get different values but they will always be in the 64-128MHz (possibly up to 160MHz) range. Of course you can use one of the different taps to get a frequency in a different range if you want.

However, because the pll essentially takes the average of the input signal over a few cycles the signal you feed in doesn't have to be quite perfect. For instance if there is a glitch in every second cycle the pll will probably clean it up. This means that you should have a few more frequencies to play with.

VIRAND

Hydra boards typically use 10Mhz x PLL8x clock instead of 5Mhz x PLL16x, with apparently the same results.

I think Rayman and I are both interested in whether it is possible to make a frequency synthesizer
with the Propeller that doesn't jitter, but although a typical frequency synthesizer uses a PLL and one
crystal and counters, the Propeller PLL apparently doesn't work well that way,
and I hope a different method will work that doesn't need the PLL.

Rayman

I was just looking at using the counters the regular way with the PLL and seem to have found that for some reason frequencies that are even multiples of 10MHz work best...
I.e.,
130 MHz, 120 MHz, 110 MHz, 100 MHz, 90 MHz, 80 MHz, and 70 MHz
look relatively stable...

Paul Baker

Qualitatively, the larger the span of set bits in FRQA/B the more jitter the signal will have, so $8000_0000 has no jitter (other than that introduced by the "slop" of the PLL), whereas $5555_55555 would have massive amounts jitter because the span between the first and last set bit is 31. To quantify this you would need to go with the progression $4000_0000 (1 bit span), $6000_0000 (2 bit span), $7000_0000 (3 bit span), $7800_0000 (4 bit span) and so on analyzing the jitter at each step. The numbers chosen can be different, so long as the span is incremented each time (IOW $5000_0000 and $0A00_0000 are also instances of a 3 bit span). Returning to qualitative, the PLL does a good job at stabilizing a 2 bit span, an OKish job with a 3 bit span, and it deteriorates from there. Basically the smaller the window of time you need to incorporate in order to·average out to the specified frequency, the better the PLL will perform in averaging out the frequency.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Rayman

Makes sense. That's pretty much what I found... But, the PLL is said to only accept ~4-8 MHz input...
The above frequencies come from FREQA= $1000_0000, $1200_0000, $1400_0000, $1600_0000, $1800_0000, $1A00_0000, $1C00_0000

I would still like to know why the PLL doesn't work in the code with the first post.

Beau Schwabe

Paul Baker,
·
To be completely jitter free, shouldn't the desired frequency have a·period that's exactly·divisible by the PLL Clock?
·
i.e.
·
80MHz = 12.5ns
5.71MHz = 175.131348...ns

175ns would be divisible, but I don't think that was the intent.· That would give a frequency of·5.714285...MHz
·


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Phil Pilgrim (PhiPi)

Beau,

I think there's more to it than that. Every time FRQx is added to PHSx, causing bit 31 to toggle, there's a residual remainder — or not. This remainder accumulates over time, causing an earlier bit 31 toggle somewhere down the line. The earlier toggle is what causes the jitter. The more "1" bits there are after the first "1" bit in FRQx, the more often (per toggle) a non-zero remainder occurs; hence, the more pronounced the jitter.

-Phil

Update: Reading the thread again, I think Paul and I are talking about one thing (letting the counter generate the frequency); Beau and Rayman, about another (doing it under program control). The former can produce more different frequencies at the high end of the spectrum, but they are subject to jitter. The latter produces more frequencies at the lower end of the spectrum (frequency = clkfreq/n), but they are jitterless. Also, many of the jitterless frequencies produced under program control can't be replicated without jitter by the counters which, I think, is what Rayman was trying to demonstrate.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Post Edited (Phil Pilgrim (PhiPi)) : 7/11/2008 5:25:29 AM GMT

Rayman

Beau Schwabe (Parallax) said...
·175ns would be divisible, but I don't think that was the intent.· That would give a frequency of·5.714285...MHz

I may have rounded the frequency a bit in my first post...· But, it does cycle on an even number of clocks...· I believe it is 175ns, 14 clock period.

The code in the first post produces a perfect square wave in PHSA[noparse][[/noparse]31] and yet it won't work in PLL mode...

Phil Pilgrim (PhiPi)

Rayman,

The reason your code didn't work in PLL mode is that your waitpeq is looking at the pin (ina), which is the output of the PLL, not phsa.31, which is the input to the PLL. Even if you were using the x1 output (PLL / 16 tap), there's no reason to expect the output to be in phase with phsa.31. The phases may be locked, but that doesn't mean they're identical. I don't know what kind of phase detector the Propeller uses, but some PLLs lock when the the input and output phases are in quadrature (90 degrees out of phase) with each other.

-Phil

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!

Post Edited (Phil Pilgrim (PhiPi)) : 7/11/2008 3:30:11 PM GMT

Beau Schwabe

Phil Pilgrim,
·
Right, even allowing the counter to do this might still introduce a system "heart beat" as the PLL gets updated or adjusted.· My limited understanding of a·PLL, is that you basically have a VCO (voltage controlled oscillator)...·If for example you are multiplying by a factor of 16 as a function of the PLL, then for the·coarse adjustment of the PLL, you look for 16 pulses on a counter incremented from the VCO and that gets reset·every system clock interval.· (Too many pulses, the VCO gets bumped down ; Too few pulses, the VCO gets bumped up)· For the fine adjustment of the PLL you do a Phase comparison on the last edge of the 16 pulses against the edge of the system clock.· In this case, simply dividing the output of the VCO by 16, and then doing a Phase comparison with the system clock.· Depending on the lead or lag in Phase delay, the VCO gets bumped up or down.· The adjustments are made by bumping up or bumping down the input voltage to the VCO.· The difference between coarse and fine is usually controlled·by the amount of current or how many transistors are switched on to charge or discharge the VCO caps.··A dynamic approach would have several current levels.· Depending on the magnitude of the Phase error determines·the charge or discharge current used.·
·
Selecting a frequency that is·closer to the system heartbeat, I would think, will introduce the least amount of jitter no matter which method you choose.
·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/11/2008 4:27:27 PM GMT

Rayman

Phil Pilgrim (PhiPi) said...
Rayman,

The reason your code didn't work in PLL mode is that your waitpeq is looking at the pin (ina), which is the output of the PLL, not phsa.31, which is the input to the PLL. Even if you were using the x1 output (PLL / 16 tap), there's no reason to expect the output to be in phase with phsa.31. The phases may be locked, but that doesn't mean they're identical. I don't know what kind of phase detector the Propeller uses, but some PLLs lock when the the input and output phases are in quadrature (90 degrees out of phase) with each other.

-Phil

Phil

Thanks!· I had a feeling I was missing something...· Now, I feel stupid...
I appreciate you taking the trouble to set me straight!

Ray