frequency-stable monolithic CMOS oscillator topology
cgracey
Posts: 14,152
in Propeller 2
Does anyone know anything about circuit topologies for frequency-stable monolithic CMOS oscillators?
I just finished the new Prop2 PLL, and now I'm wondering if there's anything I can do to improve the quality of our currently-20MHz RC oscillator which boots the chip.
I think JMG might know something about this.
I just finished the new Prop2 PLL, and now I'm wondering if there's anything I can do to improve the quality of our currently-20MHz RC oscillator which boots the chip.
I think JMG might know something about this.
Comments
There are two portions of RC osc 'quality', one is calibration, and one is temperature coefficient.
MCUs have been improving over the years, and most (even sub 40c ones) now spec calibrate to 2% or 1% or better.
One I have open right now, specs like this for their 16MHz RC Osc.
TA = - 10℃ ~ +70℃ ± 1 %
TA = - 40℃ ~ +105℃ ± 2 %
and this for the low speed, less/not calibrated
TA = + 25 ℃ ± 10 %
TA = - 40 ℃ ~ +105 ℃ ± 35 % (estimated, not tested in production)
With a flash MCU, that calibrate is a little bit of a cheat - they do not build a RC Osc cell to sub 2% PVT, but instead either run a mini-init-rom that loads a stored CAL value, or give users a location they can load from.
SiLabs are one of the leaders, but we found their oscillators are still just short of being VGA-usable.
In part due to LCD monitor sampling effects, and the jitter looks worse on lower resolution monitors, because any pixel-jump is a larger % of the display X-Axis.
That means you will need a crystal for any display work, and if you wanted to run UART level precision, some calibrate would be needed.
That's a little hard on P2, which has no FLASH cells, and (currently) also no trim means on the RC Osc.
You can side-step this somewhat with AutoBAUD code, and now, the Temperature drift matters.
Spice should give you some idea of Freq vs Temp for both Fast and Slow Osc ?
What do those curves look like with PV spreads ?
One low-cost idea for Temperature compensation and measurement, would be to engineer the Fast and Slow OSC to have significantly different, but predictable, curves, and then ensure the hardware can measure both values, and use the ratio to determine the temperature (and thus correction needed)
For example, here are the SiLabs specs :
That ppm/°C is quite good, and the %/V is also good.
As long as it boots, why do the specs matter?
1) US patent US9325323
CMOS oscillator having stable frequency with process, temperature, and voltage variation
(google don't have figures, search inside uspto.gov instead)
2) Design of a Fully Integrated CMOS Highly Temperature Stable frequency Reference
Tsiolis Georgios
http://repository.tudelft.nl/islandora/object/uuid:238c86a5-ea5b-4dc8-9ff0-9bc5f490a779
SPI boot is the most clock tolerant, but serial boot needs AutoBaud to get within spec.
Chip has that working quite nicely to some MBd IIRC, with finer Baud control in UARTS.
Boot can be a multi-stage process in P2, and it is nice to complete boot before enabling an external oscillator, from a reliability angle.
Better chip designs give a means to enable, then verify, external Clocks, before switch over, to give a fall-back path.
A blind switch over to a failed clock source, will totally freeze.
Interesting - I see they use a 4046 topology oscillator, with N-Fet sense.
Their numbers do not match their curves, & the curves are poorly labeled, so I hope their Prof gave a C-
It seems quite strongly positive temperature dependent. ~ 0.58%/℃
Here are some curves from Atmel MCU, for older ATtiny84A and newer ATMega16PB
Things to note:
Lowest Osc likely uses simple circuit, with high R-equiv with positive tempco in R, so gives a falling Frequency vs Temp.
Higher Osc is more complex, and often includes active compensation. A slight rising Freq-Temp is seen.
The newer parts are better than the older parts, especially at higher temps. Vcc variation is less.
If the high speed clock source fails, it might as well freeze.
Better freeze than try to do USB, VGA, etc. on RC oscillator...
The chip would be able to report the failure.
The other thing I was thinking is that if Chip gets this the way he wants it...
there might be some applications at the lower end that would benefit (in terms of cost by eliminating the absolute need for an
external clock source).
It will be interesting to wire up just power and serial and see just how much you can do:)
Yeah, this, eg: Being able run at lowest operating power, popping in and out of sleep so to speak, and still be reliable at its tasks.
This is the right idea.... The two OSC's should both have a common convergence point at the desired target frequency. The voltage control input should be common between BOTH OSC's. a PLL of sorts is used to track and "lock" the convergence point and maintain error correction. If the frequency ranges of the two OSC's are binary weighted they will make the PLL interface easier from a design perspective. If the two OSC are designed in a way that one references the +V rail and the other references the GND rail, then temperature effects will be minimized/mathematically canceled.
I'm not sure if the P2 can measure the LowFreq OSC whilst running on the HF Osc ?
If that is possible, you could
a) use either no-clock at all, and temperature compensate by way of curve-difference.
Depending on the tempco-spreads, this may be enough to pull to inside a UART tolerance.
Some Spice runs may be able to show how realistic this idea is ?
b) Use a Ceramic Resonator (with fast startup) in a sw gated mode.
For sleep, Xtal Osc is OFF and a calibrated run-time of low-freq osc is used.
With a Re-Cal each wakeup, the LF osc can get close to ceramic resonator precision.
c) As b) but with Crystal or TCXO, slightly longer wake up times, but higher precision.
CMOS Self-Compensated Oscillator (SCO)
http://www.si-ware.com/wp-content/themes/Si-ware/pdfs/A Highly Stable CMOS Self-Compensated Oscillator.pdf
http://www.si-ware.com/wp-content/themes/Si-ware/pdfs/A Single LC Tank Self-Compensated CMOS.pdf
Self-referenced CMOS (Mobius):
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.212.837&rep=rep1&type=pdf
Keywords : PVT, Self-referenced, Self-compensated, CMOS Oscillator
Chip, quite interesting question you made here.
'Who wants to bother with an RC oscillator for accuracy and stability? Use a Xtal instead !' (this is what common sense will told me). But you want to improve it, and so do we.
Almost all documents I have seen (RC, or LC based) rely on a compensating circuit that use a current (or voltage) reference to apply feedback/correction signal to the oscillator. They also can have some manufacturing trimming via resistors or configurable registers.
As you maybe don't want to mess with factory trimming, this is my suggestion:
- include a current and/or voltage reference,
- also a temperature sensor,
- include a user configurable feedback path for the RC/LC oscillator.
I think this fits quite well with parallax way of doing things. You put the tools inside and someone will found the way to made them work (in unimaginable ways).
I'm thinking that most of these ideas provide a repeatable stable frequency across temperature and voltages ... but not a specific frequency. For a specific settable frequency, each Prop2 IC would need calibration.
Given the wide operating nature and synchronous clocking of SPI, this calibration set could be loaded from the external boot memory without needing to switch on any crystal clock.
Ie: Factory trimming becomes a mute point.
I took RJO as talking about applications rather than implementation.
I presume you mean software measuring it? I suspect this sort of thing would all be in hardware with no need for the software to measure any of the oscillators. The software will just set some calibration registers is all.
Not quite.
The question relates to the P2 as it is designed now.
Many MCUs have two Oscs, just like P2 and they allow the LowFreq Osc to be captured by the HfOsc (ie it feeds a timer as capture, and/or as Clock), and then you can use that hardware to do a simple SW calculation.
Single point (or more) calibrate would still be needed, but that could be done at Board-test time.
He was talking about this :
"there might be some applications at the lower end that would benefit (in terms of cost by eliminating the absolute need for an external clock source)."
I agree.
Many of those can be met with nothing more complex that an ability to have RcFAST measure RcSLOW.
Plus some others, as I detailed above, where this ability saves not just cost, but can save power in designs with longish idle specs.
Or, someone running P2 on a Crystal/TCXO may wish to check the (appx) die temperature - again, possible with RcSLOW measure.
I'm not sure if the P2 can measure the LowFreq OSC whilst running on the HF Osc ?
Usually just a simple MUX & control bit - may even already be there ?
I played around with simple topologies for the 20MHz oscillator and found that it may be possible to make a temperature-stable oscillator without any temperature feedback, just by using components with low temperature coefficients and circuit design that maximizes precision.
Here are some graphics that show what I got done:
And are you going give us a glimpse into your new command and control center?
Is it getting to be an old friend yet, and not a struggle that complicates matters.
How does that compare in area, and Icc, with the older 20MHz design ?
Most P2 users are going to use a regulator for the Core Vcc, so Bandgap may not be so important.
Re the Schmitt threshold movement - that likely adjusts how much MOSFET Threshold variation applies to the Resistor variation, and they could have a sweet spot where they cancel.
You could try 'a bit each way' from where you are, and see if that 2% is a minimum.
If you meant 2% over the whole temp range, that sounds very good for a simple topology.
That's ~ 111ppm/℃, which is not as good as SiLabs, but given the simplicity, impressive.
Can the P2 measure the 20kHz, using the 20MHz FastRC, and can the XtalIN, be measured using the 20MHz FastRC (or RC -> PLL ) ? The latter can be useful to confirm ExtOSC = OK, before clock source switch. ?
The stability seems quite impressive considering it is just an RC oscillator. I appreciate your concern about every detail. In the end, this attention is what creates a good quality product.
Kind regards, Samuel Lourenço
I'm doing well. I've lost 26 pounds and I feel pretty good.
Today I finished simulating, to my satisfaction, all the schematic changes to the pad frame for the Prop2. It goes over to the layout guys tomorrow for a quick review.
Here is my desk now. Those are 49-inch 4k monitors you can get from WalMart for only $249 each. Being TV's, really, they have an annoying contrast-enhancement algorithm that can't be turned down/off, but by setting the brightness up to 85, they seem to get over it and look normal, but a little washed out. They are really nice for working, though. I use a trackball now, which is nice, as it doesn't require precise arm movement, just your thumb. My desk is messy. Parallax had an extra chair that I brought home. It's way better than what I had.
The 20KHz oscillator is a lot looser, as its 'resistors' are really long-channel FETs which vary quite a bit with temperature. It's really designed for low-power, not precision.
The 20MHz does simulate within 2% over the temp range.
Ah, I never did put in a way for software to tell if the crystal is working, or not. I was thinking about it, but I'd have to come up with some new conduit to get the signal into the logic and back into the cogs. I don't want to mess with that, at this point.
Thanks, Samuel. I hope it all works when we make a chip. I've tried to test everything ahead of time pretty thoroughly. It's a horrible stress to spend lots of time and money and not be able to change anything once the fab process begins.
Yes, the idea behind measuring the 20kHz with the RC_Fast or Xtal sources, is to allow
a) Simple Temperature Sense
and/or
b) Tracking Calibrate for burst low power operations, were LowF Osc is run in bursts, then flips to FastOsc (Xtal, or RC) and then goes back to low power.
As usual, you are way ahead of me. I could see doing that. Let me think about it a little more. We'd need a 4:1 mux to select among PLL/XTAL/RC20MHz/RC20KHz and maybe do a fixed divide-by-16 before routing the selected clock back into the logic for inspection by software. I have to come up with some instruction conduit. Too much to think about right now.
Wow! 26 pounds, that's great.
I bet you do feel a lot better, not carrying that sausage, pepperoni and extra cheese sludge around with you.
I have lost 20 pounds since the beginning of November, and it makes a world of difference.
Moderation works for me, not taking it all too seriously. Like checking your BP ten times a day, or checking your weight, and worrying about a pound or two. My wife frets about the weight fluctuations, which in turn effects the BP, just from the worrying.
I really like your work station, if I had something like that back when I was into gaming, I could have saved the world.