Clock Speed Switch Delay

pjv

Hello Chip;

I'm trying to understand something about switching clock speeds, and I need some help.

My understanding of the Propeller is that it is a "static" device, and can run at any clock speed from DC to maximum, currently around 80 or 90 MHz. In the normal "PLL" mode, the basic crystal oscillator is always cranked up by a constant 16X, and any slower "PLL" value is then a binary tap-down from there.

What I don't understand then, is the need for the approximate 75 uSec delay in making a speed change. I could understand it if in fact the PLL loop changed a divider and needed to recover from a step change, but the divider is after the PLL loop, and hence there is no change to that when selecting a different speed. And since the Propeller is "DC" capable, speedwise, why is this delay necessary?

Am I misunderstanding this?

It would be a great benefit to those of us who wish the unit to mostly run at slow speeds with bursts of high speed to not have this delay. At high speeds the 75-ish microseconds alone is enough to get some tasks completed, permitting a switch back to low speed.

Any chance of improving this in a next rev of silicon?

Thanks for listening,

Cheers,

Peter (pjv)
·

Tracy Allen

I'd like to hear Chip confirm or kebash this too, but I'd guess the issue addressed by the delay requirement is that the clock be up to speed so that it will meet the timing requirement and that the value stored in the clkfreq register will be correct. And it is not an issue of the Propeller crashing as a result of some weird clock glitch. Chip?

The Propeller manual suggests (in the section introducing the CLK register) that the crystal be allowed 10 milliseconds from activation (oscena bit), before switching over to it as it as the master clock source. And once the xtal is up to speed, the PLL can be enabled (pllena bit) and an additional 100 microseconds should be allowed for it to lock. Since the PLL is supposed to operate between 64 and 128 megahertz, there might be a strange output waveform if it is driven by a lower frequency while the crystal gets up to speed. My guess is that it would just be erratic, but not fatal.

The following is a snippet of code I've been using to step up through clock settings. This switches from the 20khz oscillator to the much faster RCfast=12mhz oscillator, and then enables the crystal, while still running from RCfast, then after a delay swiches over to operation from the xtal at 5mhz, then enables and steps through several PLL settings. I didn't put the required delay of 100 microseconds after turning on the PLL. But nothing bad happened. The next time I have this hooked up, I'll look at how long the PLL is taking to lock.

The switch from RCslow to RCfast is lightning fast for those quick response but lowest current situations.

repeat
    clkset($01, 20_000)    ' using RCslow
    twiddle(23,10,2)
 
    clkset($00, 12_000_000)    ' switch to using RCfast=12mhz
    twiddle(22,10,2)
 
    clkset($28,  12_000_000)  ' contiue using RCfast=12mhz, but enable xtal to warmup
    twiddle(21,10,2)
 
    clkset($2A,  5_000_000)  ' switch to using xtal oscillator=5mhz
    twiddle(20,10,2)
 
    clkset($6B,5_000_000) ' switch on pll, run on pll1x+xtal 5mhz
    twiddle(19,10,2)
 
    clkset($6E,40_000_000) ' switch to pll8x, 40mhz
    twiddle(18,10,2)
  
    clkset($6F,80_000_000) ' switch to pll16x, 80mhz
    twiddle(17,10,2)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pjv

Hi Tracy;

My tests have all been in assembler, and in making the switch from 80 Mhz with PLLX16 to 40 Mhz with PLLX8, which I believe to be a divide-by-two of the same crystal setting and PLLX16, there is simply a pause in execution of approximately 75 uSec.

And since neither the crystal nor the actual PLL is altered, I don't understand the need for the delay...... there is nothing to be stabilized.

Cheers,

Peter (pjv)

cgracey

pjv said...


My understanding of the Propeller is that it is a "static" device, and can run at any clock speed from DC to maximum, currently around 80 or 90 MHz.

This is correct. The device is fully static and has no dynamic memory or registers, so it doesn't care if·a 1 Hz clock·cycle is followed by an 80 MHz clock cycle, or that the clock is held high or low indefinitely.

In the normal "PLL" mode, the basic crystal oscillator is always cranked up by a constant 16X, and any slower "PLL" value is then a binary tap-down from there.

Yep.

What I don't understand then, is the need for the approximate 75 uSec delay in making a speed change. I could understand it if in fact the PLL loop changed a divider and needed to recover from a step change, but the divider is after the PLL loop, and hence there is no change to that when selecting a different speed. And since the Propeller is "DC" capable, speedwise, why is this delay necessary?

When switching among the PLL taps, the crystal oscillator, and the internal RC modes, there is no assurance of an instantaneous·glitch-free transition. So, two clock cycles of the slow RC oscillator get used to connect from one clock source to the next, no matter where you're coming from or where you're going to, or what clock source might have just been shut down as a result of switching.·This is a simplistic, but fits-all approach to the clock switch problem.·Using the·slow RC·oscillator as·a traffic cop to oversee·the switchover does take some·time (50us-100us), but it is simple and fail-safe. This could be improved, I suppose, perhaps most easily by using the fast RC clock to do the job. I think there was more reasoning behind the current design than I am remembering right now, though, so I can't say for sure.

It would be a great benefit to those of us who wish the unit to mostly run at slow speeds with bursts of high speed to not have this delay. At high speeds the 75-ish microseconds alone is enough to get some tasks completed, permitting a switch back to low speed.

Any chance of improving this in a next rev of silicon?

YES.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

pjv

Hi Chip;

Thanks for the clarification, and I look forward to the next rev......... lots of new goodies and improvements in store, I'm sure!

Cheers,

Peter (pjv)

Tracy Allen

Yes, thanks for insight into the nuances.

How about the other delays that are suggested in the manual? For example, is there any danger of a clock glitch if we switch directly from RCslow to xtal+pll16, without first going through the software delays of 10 milliseconds for oscena + 100 microseconds for pllena? Not that I really need to do that, but is it a gotcha?


-- Tracy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

pjv

Hi Chip;

I was giving this section some more thought:

 
What I don't understand then, is the need for the approximate 75 uSec delay in making a speed change. I could understand it if in fact the PLL loop changed a divider and needed to recover from a step change, but the divider is after the PLL loop, and hence there is no change to that when selecting a different speed. And since the Propeller is "DC" capable, speedwise, why is this delay necessary?
 
[b][color=blue]When switching among the PLL taps, the crystal oscillator, and the internal RC modes, there is no assurance of an instantaneous glitch-free transition. So, two clock cycles of the slow RC oscillator get used to connect from one clock source to the next, no matter where you're coming from or where you're going to, or what clock source might have just been shut down as a result of switching. This is a simplistic, but fits-all approach to the clock switch problem. Using the slow RC oscillator as a traffic cop to oversee the switchover does take some time (50us-100us), but it is simple and fail-safe. This could be improved, I suppose, perhaps most easily by using the fast RC clock to do the job. I think there was more reasoning behind the current design than I am remembering right now, though, so I can't say for sure.[/color][/b]
 

In the PLL mode, the binary taps behind the 16X crank-up are likely a muxed selector into a simple counter chain. If that chain is made from synchronous dividers, and a speed change is implemented with an instruction driven from that chain, would that not imply that it is impossible to get a glitch?

I can understand the issue·if the PLL loop·were thrown out of sync, and had to recapture the control point, but in the case of selecting a different tap in a divider chain, not so.

When you have time (I'm sure you're run off your feet just now), could you add some more insight here for us?

Cheers,

Peter (pjv)
·

cgracey

Peter,

I·knew you were going to bring this up!

No, even if it was made from a synchronous counter it would glitch, because if you go from a high-speed tap to a slow-speed tap, you have no assurance that the new slower tap will be in a known state. Going from slow to fast is another story because when the slow tap toggles, you know that all faster taps just went from low to high. As it is implemented, the taps are a cascade of flipflops with·each Q-not tied back to both·D and the next-slower tap's clock input. You can see this is totally chaotic, as it forms a ripple counter. This takes the lowest power, though. Since we have three loosely- or un-related clock sources that we need to switch among, I thought a simple, singular solution would be best. I was very cautious/conservative with the approach we took on this clock switching because I knew that a screw-up here could undermine the whole design. Yes, what we have is slow (average 75us), but it's rock-solid. I will see about improving this in the next chip, perhaps by using the fast RC clock.

pjv said...
Hi Chip;

I was giving this section some more thought:

 
What I don't understand then, is the need for the approximate 75 uSec delay in making a speed change. I could understand it if in fact the PLL loop changed a divider and needed to recover from a step change, but the divider is after the PLL loop, and hence there is no change to that when selecting a different speed. And since the Propeller is "DC" capable, speedwise, why is this delay necessary?
 
[b][color=blue]When switching among the PLL taps, the crystal oscillator, and the internal RC modes, there is no assurance of an instantaneous glitch-free transition. So, two clock cycles of the slow RC oscillator get used to connect from one clock source to the next, no matter where you're coming from or where you're going to, or what clock source might have just been shut down as a result of switching. This is a simplistic, but fits-all approach to the clock switch problem. Using the slow RC oscillator as a traffic cop to oversee the switchover does take some time (50us-100us), but it is simple and fail-safe. This could be improved, I suppose, perhaps most easily by using the fast RC clock to do the job. I think there was more reasoning behind the current design than I am remembering right now, though, so I can't say for sure.[/color][/b]
 

In the PLL mode, the binary taps behind the 16X crank-up are likely a muxed selector into a simple counter chain. If that chain is made from synchronous dividers, and a speed change is implemented with an instruction driven from that chain, would that not imply that it is impossible to get a glitch?

I can understand the issue·if the PLL loop·were thrown out of sync, and had to recapture the control point, but in the case of selecting a different tap in a divider chain, not so.

When you have time (I'm sure you're run off your feet just now), could you add some more insight here for us?

Cheers,

Peter (pjv)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

cgracey

Yes, you need to allow the crystal oscillator 10ms to rev up. The PLL should only take about 10us to stabilize and it can be enabled at the same time the crystal oscillator is enabled. Then, after 10ms, you can freely switch·between any PLL, crystal, or RC clock source.

When the crystal oscillator is first enabled, it sputters around the threshold voltage, creating sporadic and unusably small clock cycles. Once the crystal's energy level builds up, it's oscillating voltage becomes big enough that it is crossing quickly over and under the threshold and there are no possibilities of these glitches. This takes ~5ms, but 10ms is a conservative allowance.

Tracy Allen said...
Yes, thanks for insight into the nuances.

How about the other delays that are suggested in the manual? For example, is there any danger of a clock glitch if we switch directly from RCslow to xtal+pll16, without first going through the software delays of 10 milliseconds for oscena + 100 microseconds for pllena? Not that I really need to do that, but is it a gotcha?


-- Tracy

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

pjv

Hi Chip;

The fact that you have a (non-synchronous) ripple counter explains the possibility of unpredictably short clock glitches.

However, in the case of a synchronous counter, I still don't believe it, as any the edges occur at the same instant. The fact that the Propeller can handle the fastest normal clock assures that it can also handle the shortest possible synchronous "glitch" pulse.

I'm not looking to pick a fight as I'm sure I would not win that one, and since the architecture is a ripple counter, the point becomes moot.

Maybe next rev!

Cheers,

Peter (pjv)

cgracey

Well, imagine if your current clock just went high, and at that edge (since that's what everything's running off of)·you switched over to a synchronous counter output that was low. That would create a too-small high pulse for a clock, wouldn't it? It would be sub-nanosecond. It's not that the new counter signal might transition at the wrong time, but that it might be in the wrong state to switch over to. There needs to be some kind of synchronizer circuit to make the transition gracefully.
If the fast RC gets used instead of the slow RC, the transition time will become 83ns - 166ns. That will be way better and that is probably how this will get improved.

pjv said...


However, in the case of a synchronous counter, I still don't believe it, as any the edges occur at the same instant. The fact that the Propeller can handle the fastest normal clock assures that it can also handle the shortest possible synchronous "glitch" pulse.

I'm not looking to pick a fight...·· Peter, I·like the points you bring up. They're plenty stimulating and never taken as fightin' words.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey) : 5/2/2006 7:16:17 PM GMT

pjv

Hi Chip;

Again, only valid for synchronous counters........ it is the very clock(s) that timed the instruction to change the speed to begin with, hence it is synchronized to the clock, and the places where edges can occur are totally deterministic, and hence can be properly allowed for.

I realize that using RCFast in a future rev will be a good improvement, abeit not deterministic relative to the crystal based oscillator. It's the determinism that I love so much..... it allows me to do unusual things, and still have it all predictable.


Cheers,

Peter (pjv)

cgracey

But it's not a matter of EDGE. It's a matter of STATE. If you switch on the positive edge of your current clock to what is a low signal, albeit synchronized, there's going to be big trouble. No sooner did the clock go high, than in the time it takes to switch a mux, the clock is forced low. The rest of the chip is not going to like that.

I think what might be really good is to just have a programmable divider on the PLL and then always use the same output. This would never glitch.

pjv said...
Hi Chip;

Again, only valid for synchronous counters........ it is the very clock(s) that timed the instruction to change the speed to begin with, hence it is synchronized to the clock, and the places where edges can occur are totally deterministic, and hence can be properly allowed for.

I realize that using RCFast in a future rev will be a good improvement, abeit not deterministic relative to the crystal based oscillator. It's the determinism that I love so much..... it allows me to do unusual things, and still have it all predictable.


Cheers,

Peter (pjv)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

pjv

Chip;

I'm all for that!

Cheers,

Peter (pjv)