Software Controlled Crystal Oscillator

I can't speak to startup, but for steady-state operation I would start trying to analyze the thing by finding the current out of the pin when it is driven by a sine wave at a specific frequency.

The fundamental of the current should be out of the processor (indicating that it's got a negative impedance) and in phase with the driving voltage. If it is, and if you can easily tweak the amount of current out of the pin, then you're probably made in the shade.

I'm pretty sure that this circuit is going to show poor amplitude regulation, or the amplitude will be limited by the ESD protection diodes going low impedance (which will be bad for the oscillator stability and phase noise). Sensing amplitude would be a Good Thing if you could figure out how.

I think you're safe with a couple of volts of bias on a crystal, but I'm just guessing. Put a high-Z resistor in parallel with the crystal and ground it with a cap and you'll at least make sure that any bias is short- lived.

In your analysis you might want to take a look at the crystal overtones

-- operating 3x higher than you want to might be an embarrassment.

I'm not sure I understand. Are you saying the crystal should be replace by a signal source and the current out of the pin measured? So I guess this should be measured with the software running in continuous mode (as contrasted to startup mode)? The current should be virtually zero other than the spike when the I/O pin is driven for a couple of ns. Maybe I can simulate this in spice.

I'm not sure what you mean by "tweak the current out of the pin". Are you suggesting that needs to be done in real time? Or do you just mean the current has to be adjusted to suit the crystal? I can see where the drive needs to be controlled to prevent overdriving the crystal. That should be doable by controlling the impulse width.

Not only do I think there is no way to sense amplitude (without using one of the ADC at least) but the threshold voltage will vary with temperature.

Yeah, I see lots of potential problems with this design. It may be workable in the end, but analog oscillators have been studied so much and this is starting from scratch.

It has also occurred to me that it might be better to drive the crystal with a square wave through a resistor. But the phase could not be adjusted easily. The only trigger point for the square wave is where the crystal voltage crosses the input threshold. This would require two pins, one for the sense and one for the drive. But the driving signal would have a larger fundamental content and a lot less harmonic content.

Most applications won't really care so much about stability... other than perhaps audio work. Higher end audio might be more sensitive.

A little DC across the crystal won't harm. But what's the point of all this? Aren't the usual crystal oscillators much simpler? If the purpose is to use just one pin instead of the usual two, there exist many oscillator topologies which have one side of the crystal grounded. No idea why those are never used in digital integrated circuits. Tradition?

Jeroen Belleman

Interesting problem.

But isn't the Q of a crystal high enough that just driving it once with a delta function of about the right width will start it off for a few cycles so that the startup could be optimised to hit it with progressively wider pulses until it finally rings with sufficient amplitude to detect and monitor the voltage level inbetween.

I presume the object of the exercise is to use only one pin?

I expect the phase noise will be pretty horrible.

For the purpose of simulation can't you just hack a suitable AC coupled transient pulse drive voltage and monitor how the virtual Xtal behaves?

You basically need to be sure that it will start up and ring reliably and at the right fundamental frequency and not on some overtone.

I would do this by analysis, on paper, but yes. In the frequency domain your "virtually zero other than the spike" is "very small at all integer multiples of f0", and if you know the characteristics of the pin under drive you should be able to turn that "very small" into a number dimensioned in amperes.

You should be able to do this just fine in SPICE, with intuition and lots of simulations.

If you do NOT know the characteristics of the pin under drive, or if it's got a really low impedance, or if the characteristics change over temperature and manufacturing variation then it may be advantageous to use a series resistor between the pin and crystal. Doing so would give you a more consistent circuit at the cost of that one bitty resistor and widening your pulse somewhat.

I was thinking of tweaking the pulse width, yes. (Or that resistor that I suggested).

If the average voltage on the crystal is not centered at VSS/2 then you may be able to deduce the amplitude by measuring the times of the both the rising and falling edge of the signal as sensed by the pin. Or, maybe not -- that's left as an exercise to the reader.

Come to think of it, your current should be fairly heavily dependent on the amplitude of the crystal voltage, in a way that inherently limits the crystal amplitude. This should become obvious if you do the analysis, or if you play with it enough with SPICE.

Oh, but life on the bleeding edge is much more fun. I assume you're running a processor (this is the x-something-or-other, isn't it?) that has an internal RC oscillator -- unless that oscillator were truly horrible you could program in a nominal frequency, and avoid overtones simply by not going there.

If you made my suggested resistor large enough then you could make a pulse that's fairly wide (thus not having much 3rd harmonic content), but you could still go high impedance around the expected VSS/2 crossing times of the crystal to measure phase, thus doing everything with one pin.

This just in! If you drive the crystal with six narrow pulses per cycle, evenly spaced and of the same width, in a high,high,high,low,low,low pattern, you'll kill the 3rd harmonic content. Further, there ought to be a magic combination of pulse widths that'll kill both the 3rd and 5th harmonic while still generating 1st harmonic energy. I'll guarantee the former, but figuring out the exact pattern to play for the latter is too involved for me to do for free right now.

This is probably all borrowing trouble -- your best bet is to probably not worry about overtone operation for now, and just make the damned thing work.

AFAIK Rick is using some newfangled processor that's basically a whole bunch of really fast, really teeny cores in a systolic array. So -- if I'm not mistaken -- he's planning on devoting one core and one pin to the task of being a crystal oscillator, which will be used as a time base for other operations on the processor.

Rick can correct whatever I said that's wrong in the above paragraph.

That's pretty much right. The GA144 was introduced some three or four years ago and has received no traction that anyone can tell. One of the many features they omitted was any sort of an oscillator.. who needs an oscillator for async processors? Well you don't, but you need a timing reference for many, many applications, like anything sampling with an ADC or recreating a signal with a DAC.

Green Arrays (GA) had an app note on making an oscillator from one I/O pin and a crystal, but it was very incomplete. Chuck Moore tried using a 10 MHz crystal (iirc) but couldn't get it started, so used a ceramic resonator instead which worked well enough to drive a video monitor. Other apps are a bit more demanding, so a crystal is needed. An external oscillator could be used of course, but this adds to the long list of external things needed to make the GA144 useful.

Someone posting in the forth group made it work using a dither technique he calls the Bresenham algorithm which I believe was intended to calculate pixels for a straight line and is essentially the same as an NCO. This gets around the issue of the resolution of a timing loop not being sufficient to start a crystal with its high Q. But there are a million other aspects of making a crystal work *well* and I am no expert. So I thought I would ask here.

If a chip were being designed, then yeah, just add an oscillator amplifier. But the chip is done, work with what is available.

Yeah, if I get motivated I might do that. I think I did work on this once. But spice is not so good at accurately modeling oscillators from my limited experience.

I can say pretty easily that with a 10^(some fairly large value) ohms impedance in input mode and some 10's of ohms in output mode, the I/O won't be too hard to model. I'm just not sure what to make of the result.

Seems to me a load capacitor is needed in parallel with the crystal to meet the maker's spec. Not sure if anyone has done this. Adding a resistor to the drive can be done easily.

The phasing is a part I'm not sure of. Imagine a sine wave from the crystal and positively crossing an arbitrary threshold. At that point a positive spike is driven into the crystal. It will contain some fundamental but I don't think it will be zero phase. That would require detecting the peak of the sine wave which this circuit can't do.

Spreading out the drive and using a resistor can get a better alignment of the phase, but at a cost of current in the core. When it is running the current is around 5 mA iirc. When sleeping it is approx zero (nA I believe). So sleeping is preferable. The only way the processor has to time events is to loop which is not very accurate (async proc running with variations in PVT, process, voltage and time). So timing can only be approximate unless it is sync'd to the crystal by the input.

Do you mean experimenting to find a suitable value or adjusting in real time by some measurement?

I'm not seeing that unless you mean with higher oscillations the drive is reduced because of the relative value. With a short impulse that is not the case really since the impulse is sync'd to the input transition. This would require the node to delay by some timing value.

You can call it an RC oscillator. The nodes are async and each one has it's own instruction timing which varies with the instruction.

Yeah, I thought of that. I would like to not run the processor all the time though.

I don't follow what this sequence means. You mean drive it both high and low with narrow pulses? The timing of the pulses would be very inaccurate although there are ways to sync to the crystal with something like a PLL I guess.

Ok, I'll come mow your lawn.

He has it "working" for 1 MHz and several values up to 16 MHz, but not 2 MHz which he doesn't understand why. I think he said 18 MHz doesn't work but he blames that on the limits of even the dithering technique which I'm not so sure of.

A high-Q resonator like a crystal would take a gigantic impulse to make it ring enough that a gate could detect it. At CMOS sorts of voltages, it would need to be poked for a while with a square wave to build up amplitude, and that will involve sweeping to find the resonant frequency.

HP once made a delay generator that accepted a trigger and shocked a crystal into oscillating. I recall it took hundreds of volts, and didn't work well at that.

DC on the crystal shouldn't be a problem. Lots of oscillator circuits put DC across the rock.

OK. I start to see where you are coming from and where you might want to get to. The difficulty is that to make the crystal ring you are going to need something free running a fair bit faster so that you can match frequency with a well timed pulse within the Q ringing time.

Think of it like a pendulum and you need to kick it every so often at exactly the right time to keep the amplitude up. Depending on how long the crystal will ring for you may be able to calibrate its frequency against the free running core and then pick appropriate magic constants for repetition rate, delay after 0-1 transition and pulse width.

You are basically stuck with the resolution granularity of your timing loops but you can create a pseudo delay that differs by one cycle depending on the bit state of a free running counter (assuming here you have test bit and branch instructions). Every Nth loop with N carefully chosen you add in an extra cycle delay to make the pulse hit the right moment to excite the crystal correctly. Phase noise will be horrid.

Same with hitting top dead centre you can only detect the 0-1 and 1-0 transitions but if you measure over 1024 of them you get a pretty good estimate of how many free running ticks per cycle of the crystal.

It might still be easier to feed it a nice reliable external crystal oscillator reference clock unless you enjoy pain.

I'm not going to try to stick this in where it might "belong" because it seems that I was laboring under a fundamental misapprehension.

Namely, that your processor would be running all the time, and that you'd blip the output at some fixed time _after_ a transition is noted. Because, basically, you want the current out of the pin to -- ignoring harmonics -- be in phase with the voltage going in.

Blipping the pin right as the transition is made will generate a current that's nearly 90 degrees out of phase (one way or another) with the voltage. If you do your math, you'll see that if the current were _exactly_ 90 degrees out of phase with the voltage then you'd get no power transfer at all into the crystal, which means that your oscillator won't work because power transfer into the crystal is exactly what you're trying to achieve.

If power consumption weren't an issue then you'd have a software loop that gets an edge, counts out about 1/4 of a cycle, blips, waits for an edge, counts, blips, etc.

Things may not be that bad, though: since it's a crystal you may still be able to achieve your desired goal by making the blip 100 times wider and only blipping the crystal every 100th cycle, depending on the crystal Q to sort you out in between. So for 99 cycles it'd just be waking up, doing an increment (or decrement) and a test. You'd be using full current (is it really 5mA _per core_?) for a significant fraction of, a cycle, but it would only be 1% of the time (or less, if you waited more cycles between blips).

How Rube is your Goldberg ?>:-} ...Jim Thompson

In most CPUs, there are swings (including ground bounce) at each clock pulse, which quiet down before the next pulse. In an async design, there are no quiet times, and the 'next pulse' from a quartz crystal is gonna get LOTS of jitter from data signal bleedthrough. The crystal oscillator is an analog device, it NEEDS low-noise conditions to lock onto the very small signal from the rock. High Q means very small signal coupling.

Small, cheap quartz clocks are available prebuilt, it's unlikely you will benefit from avoiding them.

Complexity is _fun_!

But sometimes it's just plain insane ;-)

The phase snap of a crystal is so swift that I doubt that a sense-it/drive-it scheme can ever work reliably... think delays.

An unbuffered inverter makes a perfectly fine crystal oscillator... because it's ONLY ONE-STAGE of gain. ...Jim Thompson

It'd be an interesting science project to find out.

True. I chose to go down Rick's road because it's more fun, but unless I were really, really constrained somehow I think that on an actual project I'd use a store-bought oscillator, or something built around a 'U04 gate.

It's not that bad. What the experimenter calls the "Bresenham algorithm" is essentially an NCO where you use the top bit to indicate when to fire the pulse. You can set any step size you want and the average rate will match the rate your program to a high accuracy, even with 1 loop cycle jitter (which is about 1.5 ns in this case).

Yes, I gave up on this some time back, or more accurately, when the chip maker didn't pursue it I didn't bother to pick it up. The point is that the GA144 has *many* shortcomings that even a $1 MCU deals with adequately. This is just another one that might be mitigated.

You might be missing a critical aspect of this design. It uses the signal from the crystal to trigger the impulse to drive it, not entirely unlike the escapement on a pendulum clock giving a small push to the pendulum each time. There is no sine wave stimulation, just a push at the right moment.

Sure, if you don't mind the added cost. It may not be much, but if this chip is used in a high volume product the extra cost can be significant.

Maybe I didn't explain the situation clearly. Someone working on this has crystals oscillating. I'm just trying to get info to help put a fine point on it.

Sweeping for the frequency is exactly what the experimenter is doing. Mostly because the instruction rate of the async processor depends on PVT. It currently is driven with a square wave during the initialization. Then the drive is turned off and the input listens to the crystal for the edge, if not found a new frequency is checked.

So it's pretty amazing that someone is making it work with a 1.8 volt supply!

Good to know, thanks.