Digital Crystal Oscillator

1uW is the typical recommended limit for them.

2.5nsec resolution is 2.7Hz off for that 32.768kHz watch crystal. Quite a lot. I wonder if they ever held a spectrum analyzer to that. Maybe Niagara Falls has a better noise performance? ... :-)

You can't use a regular scope probe to measure this stuff. The minimum effort should be a FET probe with not much more than 1pF.

All devices in a chip are resistors, nothing you can do about that. Resistors aren't the major energy wasters, usually. Quiescent currents in analog stuff are. So are leakage in push-pull stages and losses due to constant swinging around of inputs. Capacitances that must be driven by N/P channel devices with finite conductivity.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

[...]

If the time step resolution is really 2.5nsec that would result in some serious phase noise. Also, if you regulary have to "goose it" how would they maintain longterm accuracy? Dithering like on DFLs in modern uC?

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I think you'd have to dither the excitation frequency, yes. Actually, if you're letting the crystal control the excitation frequency with some sort of a PLL you _would_ dither the excitation frequency; it's just a question of how _well_ you dither the excitation frequency, and whether you do it purposely or just let the loop make it happen.

I'd have to do some analysis first, but I suspect that a 1st-order delta-sigma modulator would work pretty well -- like this:

The big question is that if you're phase locking an RC clock, is it going to vary enough that external dither will make a difference, or not?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Did you read the article? I think you may have missed the basic concept of what they are looking to do. The concept is that a sustained square wave of close to the resonant frequency would be used to initially excite the crystal and get it resonating. This is the part they tested. Using a software loop with 2.5 ns resolution they excited the crystal and set it oscillating. Then they turned off the output and watched the crystal with the scope.

The rest of the story which they outline, but do not test is to use the input threshold to detect the oscillations and to control the timing of the "spur", a brief as possible pulse to maintain the oscillations. This is not regulated by a separate clock. The processor is async and is in wait mode. When the crystal voltage crosses the threshold of the input, the process is triggered out of wait and it generates the "spur" to maintain the excitation of the crystal.

The author lists the remaining steps to complete the design.

To be continued...

• Using the chip as a very high impedance active probe * Automating the crystal start-up * Keeping it running * Energy estimation and measurement * Comparison with other implentations [sic] * Ceramic resonator * External R-C network

I have been running some simulations on this idea and found that a single pin oscillator likely won't work. To drive the crystal, pulses both positive and negative (ground) must be used to keep the crystal voltage within the range of Vdd and Vss. If the input threshold is not well centered in this range, the magnitude of the two pulses will not be equal pushing the bias of the crystal in the opposite direction of the threshold. The end result is that the crystal voltage will either exceed the power supply range and start being clipped by the protection diodes or the crystal voltage will not swing enough to cross the input threshold on every cycle and oscillations will stop. By using more than one pin, separate input and output, I am able to make the simulation work well with a range of crystal frequencies. But the design quickly becomes more complex than what is described in Application Note 2. I'm actually a bit disappointed that they didn't pursue this effort a bit more and determine if their idea was actually practical or not.

Rick

Nice write-up.

But isn't it that they shun resistors? Then all they'd have is a dither of the "gooser signal" and if that's quantized to 2.5nsec time slivers they'll run up to a hard limit. IIUC the purpose is to coax the external crystal into resonating for as long a time possible. Almost like trying to make the champagne glasses on the shelf "sing" with just the right blast from a trumpet :-)

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

this:

I'm not sure what you are talking about here. The idea is that once the crystal is resonating, the processor monitors the input threshold crossings to control the "goose" or "spur". I suppose there are any number of ways to do that. I was thinking that you would spur the crystal for a minimum amount of time in the appropriate direction each time the input threshold is crossed.

I don't think the app note author was thinking of something like a sigma-delta based drive. That would take a lot of compute resources and one of the goals of this design is to use as little power as possible. Spurring the crystal on the threshold crossings would use on the order of 50 uW in the processor which is a pretty good number for a 1 MHz oscillator.

As to the dithering, once the crystal is ringing, you don't need to dither anything. The crystal sets the timing and the processor just responds to that timing. The processor is asynch so there is no clock to dither.

Rick

I got the impression that the chip is run off of an RC clock, or other "Q-less" multivibrator.

Whatever their main clock is, it can't have crystal stability or they wouldn't need a crystal.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

this:

That may work, that may not.

The author's idea is that he's a hot-shit rocket scientist because he can get a crystal to ring but can't keep an oscillation going. All he says about specifics is:

"Now that we know it will be feasible to start the crystal under program control regardless of the variables affecting our timing, we need to develop and test that program and then to implement the code for replenishing the energy of the crystal so it will oscillate indefinitely. Along the way we will be seeking ways to minimize the energy consumed in both starting and sustaining the oscillation. "

IOW: he hasn't figured it out yet. So where does he say how he's going to give it a kick, and where's his demonstration that his intended scheme works?

I don't think the app note author's thinking was based on much knowledge of crystals at all, so I don't feel like I have to put much weight on whatever confused and uninformed thinking was going on.

If you read the article I cited, you'll see that a 1st-order sigma delta can be implemented with little more resources than a loop counter. If that's "a lot of compute resources" then the computer is pretty lame, and it's a darn good argument for not having something so compute-intensive as the software loop that he's using.

Which leads us right back to: why waste the thousands of transistors in the processor (and the energy it takes to make them switch states at

400MHz or whatever) when we could use just one stinking little transistor, pulling very little current, to run the crystal?

It's a _watch crystal_. This is the guy that, when it's in a wristwatch, can be kept running for well over a year by a battery that has maybe 0.1cc of active material in it. For this we need to devote a _processor_??? Running at 400MHz??? How long is _that_ going to run on an itty bitty watch battery?

It's a 32kHz oscillator. Get your facts straight. And 50uW is a hell of a lot more drive than the crystal needs or can stand -- so where's the targeted "low power" dissipation?

That depends on how you need to architect the loop. If the derived timebase in the processor needs to coast at all well, you need dithering. If you can get by with cycle-by-cycle corrections, then maybe you don't need _explicit_ dithering -- but you need dithering. If you do cycle-by-cycle corrections, you can bet your sweet bippy that the frequency of the derived internal clock _will_ dither. It'll quite probably dither more than if it's dithered internally in a controlled manner, and it'll certainly dither in a way that'll be more objectionable to most applications.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

You have run some simulations and found that you are not smart enough, or determined enough, to make a single pin oscillator work.

There is no theoretical reason that I can see that would prevent an oscillator of this architecture from working. I'm not questioning its feasibility, just its practicality.

How can that possibly be? If indeed you do this by generating a narrow pulse at each sensed crossing (which may or may not work), then you will perforce have to generate as many "pull to Vss" pulses as "pull to Vdd" pulses. All you have to do is control the pulse width so that they are equal, and -- voila! -- the DC content of the signal is centered on Vdd/2.

How did you determine this? Did you turn off the computer for long enough to get out some paper and a pencil and go through the theoretical calculations?

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

From what I read the issue I see is that they had to measure the thing very accurately to get the initial pumping frequency close enough to pump it into resonating with enough amplitude that the micro could see it. If it starts with a more crude estimate of that timing and varies it slowly until the micro can see the xtal oscillate the first stage might work better. I would be inclined to pump it a little differently to get it to that stage.

The big issue is indeed that when a timing loop has 2ns increments and a poll loop has 7ns increments on a penny-processor-and-pin it would introduce terrible timing jitter on each xtal cycle and likely very serious timing drift over time. If the pumping gets out of phase the xtal will stop oscillating.

I think once an xtal is oscillating it needs to get right sized vcc and gnd pulse on each cycle or over a period of cycles if 2ns precision on the pulse timing for one cycle is not precise enough.

It needs to sync up on each cycle more accurately than can be done with a poll loop or interrupt. That's where I would see it using the pin wake feature.

This would let it sync up on each cycle with a couple of picoseconds of jitter and a couple of hundred ps of latency. It is when you need that sort of timing that you need to add the external xtal and traces.

Different pin wake circuit design might change to a different version which would effect code. But the code for what I would write should be shorter than the english description of it above and it should only take a few minutes to test.

A more sophisticated version in an application might put a watchdog somewhere else to monitor the modulation phase of the xtal and do the right thing to get the driver node to recover should it fail. If one uses only pin wake to get jitter down to a few picoseconds it means that if the xtal quits ringing then that processor would sleep forever.

So to guard against that it could use a multiport read rather than just a pin port read. Then if the watchdog detects if the xtal is about to go away or that it has gone away it can do the appropriate thing for recovery.

A more sophisticated version still might use a D/A or A/D or add software to measure temperature and fine tune things further. A GA144 has more than eighty pins but only six analog pins. A GA4 has eight or twelve pins with only two of them are analog. It is still a fraction of a cent of hardware but there are fewer of them available than gpio pins or gpio pins with the pin wake feature.

I would think there should be many ways the software could be coded to do the stuff I described above could be written. It should only take a few lines of code.

I would think it possible to drive an xtal from both ends with two pins using similar techniques or simulate other external circuits. I see the poll loop vs pin wake synchronization issue to be at the heart of the problem to getting phase locked to a timing source through a gpio pin.

I might hook up an xtal and see how long it takes to get a working solution in code.

Best Wishes

this:

I agree that this is a bit iffy. The simulations I've been running seem to show that driving and monitoring the crystal on a single pin is not very workable. The problem I encounter is that any offset of the input threshold from center of the power supply range gives a bias to the "push" from the output which will eventually push the crystal bias point until the circuit either runs into the protection diodes or no longer crosses the input threshold.

Yes, he says there is much left to do and even provides a list at the end. I don't want to make excuses, but I believe they are designing this chip on a shoestring and aren't spending much time on the app notes until they are a bit further along. They may have done themselves a disservice by releasing this one before it was complete.

Guilty. I didn't read your reference.

Ok, you are guilty of not bothering to learn how the GA144 chip works. The processor goes to sleep when it has nothing to do. I don't mean it stops processing while the processor clock continues or that it spends a lot of time shutting down and starting back up again. It seems they have a way to stop and start the async processors in no more time than a couple of gate delays and with virtually no power.

I won't argue about the use of a simple circuit to construct an oscillator, but I'm not going to condemn the idea until I've given it a chance. If this can be made to work easily, then it would be a great feature of the chip.

Yes, he used a watch crystal. The technique can also be used with other crystals to replace a higer speed oscillator that might use as much as 20 or 30 mA or 100 mW! I have some simulations running that seem to work at 16 MHz. I can't say they are realistic since I'm not really sure what circuit would be best. I can't get it to work with one pin so I'm looking at two pin approaches.

Sorry, my data is on much faster oscillators. I am simulating 200 kHz, 1 MHz and 16 MHz. I think the 50 uW is for the 1 MHz simulation. Also, the 50 uW is what the processor dissipates, not the crystal. When I look at oscillator power consumption they are all multiple mA, even the low power silicon resonators.

You don't understand the GA144 chip or the F18A processor. The processor is async. It waits for an input change and is fired up within tens of picoseconds. There is no clock so only leakage power dissipation when it's not running. The crystal controls the timing of the processor, not at the instruction level, but at the task level. The rising and falling edges of the crystal signal kick the processor into run state and the processor kicks the crystal to continue ringing.

The problem is that in the real world many problems, like sampling analog signals, require an accurate time base. So crystal oscillators can't be eliminated even from async processors.

I was discussing this in a Linkedin group and the guy there just insisted that the only way to build a crystal oscillator was the standard Pierce circuit, anything else was pointless and doomed to failure. I'm not overly enthusiastic with the digital approach at the moment, but I'm willing to give it a try.

Rick

Yes, the app note author says that he needs to do a search of the frequency space to find the right stimulus to get the crystal ringing.

This is the most critical thing from the simulations I have run. Input thresholds are seldom centered in the power supply range from what I've been told. Data sheets often state a range of 30% to 70% of Vdd. An offset from center for the threshold results in an imbalance of the push from Vdd and gnd which pushes the bias to the other direction from the input offset. If it gets to 0.5 volts for example, it is very hard to make the circuit continue to oscillate in my simulations.

Is this something that is being worked on? I'm surprised that a crystal oscillator has not been designed an tested so far, but then I don't really know what stage the chip design is in.

A watchdog should be pretty simple, but it requires another time base somewhere, somehow. I can't see using a processor in a timing loop for that. The other alternative is to just have any other process that doesn't depend on the clock to ask the clock node if it is running. All the clock node has to do is to note that it has received transitions on the clock pin, that shouldn't be much code in the power consumption loop.

My concern is not just that it can or can't be done, but how well it works. An oscillator needs to work over temperature, voltage and process, start reliably and not falter. It also has to meet requirements for accuracy and in many apps will have a requirement for phase noise, like when using ADC and DAC for something other than power supply or temperature measurements. Verifying that an oscillator does all this is not a simple task.

I would love to see your results. I have to say that the app note on the web site actually raises more questions than it answers.

Rick

Was that necessary? I'm trying to have a professional conversation and I don't consider that to be a professional comment.

I don't know what you are saying. I've run simulations based on what can be reasonably done with the GA144 and a crystal connected to one pin. When the threshold is not centered, the timing of the "kick" pulses are not at the time when the crystal voltage is at the midpoint of the power supply and so the "kick" magnitude is not the same for the two directions. If you can figure out how to do this with just positive kicks, this problem goes away. Do you know of a way to get around this problem?

.

Read my description carefully. All information to understand this is presented. The energy delivered to the crystal is not just a function of the width of the pulse, it is also a function of the voltage. The voltage in question is the voltage between the output pin (either power or ground approximately) and the crystal at that moment. The voltage on the crystal will be the input threshold voltage with a very small offset for the series resistor I added (if nothing else there is the resistance of the driver and pin). So if the threshold is offset, the drive will be offset. Instead of centering the oscillations about the threshold, the unequal drive pushes the crystal bias in the other direction! Clearly this is a problem if the magnitude of the offset is very high. At a threshold of 0.5 volts and Vdd of 1.8 volts I found it very hard to keep the crystal oscillating and the duty cycle of the threshold crossings is far from 50/50.

I thought I said I have been running spice simulations. I've been talking about this in several places so maybe I didn't say this here. Some of my sims have added power and ground clamping diodes and they change the results greatly! I would love some useful advice on how to actually analyze such a design. Because of the impulse nature of the drive and the complication of the feedback, I have not come up with a way to analyze this rather than just simulate it.

Rick

this:

If there's something you can do to guarantee that the pulse width is the same in the positive direction as the negative then this problem goes away. If I'm wrong about that, then loading the thing with a pair of matched, high-value resistors to Vss and Vdd should keep it straight, at the cost of some crystal Q.

(snip)

er, ehem --- OK.

(snip)

I still think a crystal oscillator is within reach. Certainly if you can catch every transition, and you can make sure that your average contribution is DC, then you can make it work.

So Butler oscillators don't work, and the classic tuned-base, tuned-collector overtone oscillators don't work, etc., etc.?

He may be right in that the Pierce circuit is the most commonly used one and the easiest to get going. He is probably exactly right that if you're trying to do it with a logic gate that's your only hope -- but there's a lot of more esoteric circuits out there for more specialized uses.

What Linked-in group?

It seems like a better solution would just be a processor that has a crystal oscillator that can be turned on, but I understand the temptation to make the processor do everything.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

... and most designers would include a Power Budget in there too.

My conclusion is you can probably, with enough effort, make a resonator, ( note this is not really an independent oscillator, as it needs another Oscillator, to start, and some means to check it is still running ? ) - but I also think there is zero chance of getting anywhere near the power budgets of more common solutions (ie close to 1uA, or sub 5uA)

Which raises the question of, why bother ?

-jg

this:

Just the drive turn-off and turn-on (so you can sense) is most likely coting more power than the crystal itself consumes. Remember such watch crystals are running at a microwatt. Nothing beats a dedicated oscillator circuit there, either on-chip or off-chip.

Many do that, like the MSP430 series. But each wake-up is (usually) either slow, noisy, or power-consuming. Or a combination thereof. But maybe the GA144 guys found a way around that. Wonder why these aren't available at Digikey though, maybe too new?

I am "the guy" :-)

No, I don't think anything else is doomed, just that it may not make much sense to try that on a digital pin.

The "Mixed Signal" group.

Rick, I can't see your posts because you are using Google but I'll see your text when someone responds.

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

I noticed that in the experiment online the lines to the pin and to ground had slightly different length. What effect that has on the bias and how much it would be effected by threshold detection not always being at a fixed point in the xtal output if its output level varies isn't clear to me because I haven't tried the experiment on actual hardware to chacterize it or adjust for it.

I don't have the scope described in the article so I would have to attack the experiment a little differently. Once an xtal oscillates with sufficient magnitude to be detected then you know it is oscillating and might be able to detect that it needs longer vcc or gnd pulses to operate in a desired range. I read what your simulations showed but I haven't tried it myself on real hardware yet.

I only have a GA32 at the moment but the I/O should be close enough to the GA144 at the fab now to see what effect the small changes I/O circuits will have when the code is also run on one of the new GA144.

My impression was that the web page was meant to show how easy it is to setup an experiment and try something. I did not get the impression that it intended to go to a working solution for any specific application or project where there were any "requirements."

People have asked for very simple things to start. How do you install the software? How do you use the editor or ide? How do you write a simple pin toggle loop? How do you run simulations? How do you connect external devices?

Those were what people asked for first and I think that a demo of an experiment using the Interactive Development Environment was put on their site to provide a simple IDE demo.

I think there are important priorities. Design work for the chips in fab now is done but custom test equipment and software is in the works. There is also design work on things for newer chips that Greg Bailey described in his presentation in November and there are other development projects going on. My impression was that the experiment and the documentation of was more on the scale of a post to usenet than a real project.

The sort of watchdog I was thinking of would just monitor the duty cycle of the signal to see if it looks like it is being under or over pumped and it would detect if the xtal stopped oscillating and the serving processor went to sleep. That idea does not require anything more precise than software on another penny node. It is a little like saying you can or can't do it on one function block on some FPGA.

The point I was trying to make was that if you use sleep mode to sync to a few picoseconds then you will need to use a second processor to wake it up if there is any chance that it will let the xtal stop oscillating and sleep forever waiting to sync to the next xtal cycle, another processor block is neded for that.

I understand that. But you have had trouble communicating that you really wanted to see a stable algorithm and/or code example of how this would be one on some very inexpensive parallel hardware. You got answers about alternate hardware circuits, processors with bazillions of transistors or with hundreds of pins and which appeared to me to miss the idea of staying synchronized to the xtal with a pin wake-up circuit.

I was just trying to bring things back to what looked to me like the original subject, a discussion of the limitations of software a particular thing on hardware with very small embedded asynchronous processors running in parallel.

Yes. I would be included to use a precision oscillator and some good equipment to measure it in an initial design and then see if I could get similar results with a few cents worth of parts instead of a few dollars. I think you would do the same. If you need to make a precise and reliable crystal oscillator work and save a few cents in external parts that becomes part of a project.

It looked more to me like a IDE demo than an example of finished code from a library. It looked more like a simple experiment for a class of new students than part of some system where "it also has to meet requirements for accuracy" or "will have a requirement for phase noise, like when using ADC and DAC for something other than power supply or temperature measurements. Verifying that an oscillator does all this is not a simple task."

I was thinking of things like bit-banging protocols that have strict timing requirements, soft radio phase decoding of rf signals, doing 21-bit audio with a few cents worth of hardware by adding some software to the hardware.

Sure. I'll put it on my list. I do have a higher priority task in progress to replace a $40 part with a couple of cents of external components and some software. It doesn't seem like a big deal.

You ask some interesting questions that it appears can only be answered with some experimentation. I will do some follow through before long and get back to you.

Best Wishes

this:

You aren't grasping what I am saying. The pulse widths are assumed to be the same. But the voltage difference between the power rails and the driven point is not the same in each direction because of the offset in the input threshold. If the threshold is at 0.5 volt and the Vdd rail is 1.8 volts, there is 1.3 volts across the output impedance for the positive pulse when triggered and only 0.5 volts across the output impedance for the negative pulse when triggered. This will pull the I/O pin toward Vdd until either the voltage from the crystal biases the protection diode on which sucks power from the circuit or the amplitude of the crystal oscillations is not enough to cross the input threshold anymore.

Adding a biasing circuit with a voltage divider will not offset this effect as it is an active force and not just a small bias that can be overpowered. I didn't realize this would happen until I saw it in simulation and then understood the effect. If the chip had an LVDS input one pin could be used to set the threshold to a consitent level at the midpoint of Vdd-ground.

I'm sure an illustration would make the effect clear. A picture is worth a kiloword. If you really want me to, I'll do a screen capture to show this in action.

Those are two big ifs. I have a circuit working and I thought it only used two pins. It separates the input from the crystal and the output with a small cap. I had to use a third pin to bias the input from the inverted clock. This generates a PWM bias that helps to minimize the duty cycle distortion that results. The third pin is not "wasted" if the clock needs to be on an output.

I would also like to consider if this can be done by connecting the crystal between two pins and treat the digital loopback as the inverter in a Pierce configuration. But this appeal of the approach is rapidly losing its charm. Once you have used two pins, added a handful of passive components, it starts to seem silly to avoid adding an inverter or two to the chip when it was designed.

Who said any of these won't work. They are all analog oscillators, no? I don't understand.

Unless a chip or transistor is added, the GA144 doesn't have any logic gates accessible. Everything I've considered so far has considered the use of software controlling the I/O pin.

It is tempting to see if the idea can be made to work. But it is also practical in that the GA144 has no support for a normal oscillator and there are no other processors like the GA144. So switching processor is not really an idea I want to consider. If needed, an external crystal oscillator circuit could be added, but I'm willing to bet it will use more power than a processor based one... assuming a processor based oscillator can be made to work properly.

I do appreciate the conversation about this. So far others have mostly just told me to add a transistor and call it a day. I've never learned anything by doing that.

Rick

this:

That's a bit silly. Turning the pin on and off is not really very power consuming. That is one instruction to set the drive and one to turn it off. But yes, the processor uses more power than the crystal. On the other hand, I expect the oscillator buffer uses more power than the crystal in an analog circuit. A canned oscillator uses

3 mA for the all silicon devices up to 30 mA for a 10 MHz crystal based can. That's several orders of magnitude more than this digital based approach. I don't have a way to compare the power used by an internal buffer in an MCU.

I just realized you are the guy from the Linkedin group. You really aren't getting the concept here. You need to go read up on the GA144 if you want to participate in the conversation. Yes, they found a way around the (relatively) long and power consuming actions required to enter and leave sleep mode (what GA just calls "wait"). Their processor is asynchronous, meaning there is no widely distributed clock. We don't know the details of how the GA folks implemented it, but the processor can stop on a dime... literally. At the end of an instruction that pends the processor on an input, the processor just stops. When the input transitions the processor continues. No overhead and virtually no power other than the leakage of the part which is very small, 100 nW for each processor.

Yes, they are new. The only people who have chips are those affiliated with the company. I am intrigued by the novel concepts involved and am giving consideration to implementing a radio controlled clock as to illustrate the capabilities of this chip.

Yeah, I figured that out a few minutes ago. We weren't getting very far with that discussion.

Why can't you see Google posts? Are they blocked from your newserver because of the spam?

Rick