Digital Crystal Oscillator

The document you linked to, uses 32.768Khz, so that was the data point I took the thread to apply to : 32.768KHz Crystals

viz: 1-5uA is the ballpark for operational 32,768KHz oscillators.

err, but 300KHz -1MHz is rather no-mans-land in Crystal terms ?

Digikey lists 1MHz xtals at $17, and jumps to 307KHz ones at $5.00 ?

Or, did you mean a Digital Ceramic Resonator Oscillator ?

For ~455KHz Murata resonator, and 2V swing, a power budget of 10-20uA is reasonable. (and 0.3%-0.5% tolerance)

-jg

This is an asynchronous processor. 2.5 nsec is approximate granularity time for a software delay loop but that is only used for exciting the crystal. If the processor reacts to a level generated by a crystal, jitter is claimed to be in the picoseconds or less.

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

That I'd want to see :-)

As the ancient forefathers said, hic Rhodos, hic salta. They should put some spectrum analyzer plots on the table. Claims alone ain't cutting it.

--
Regards, Joerg

http://www.analogconsultants.com/

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

Working chips in versions with 24, and 40 core were working as long as five years ago. The 24 code models that were put in USB sticks and given away for a couple of years didn't have access to I/O pins, but chips have also been on development boards for about five years. The 144 core chips in fab today do have changes from previous designs and have not returned from fab to be tested and characterized so specific performance details for those chips are not yet available. All that exists for those chips so far are cad simulations, but those simulations have proved quite accurate over the years.

300ps is a reasonable estimate of the latency of pin wake circuit. The processor goes from full sleep to full speed within 300ps of an external event on the pin. This might vary by as much as percent, and introduce about 3ps if jitter to the system. 300ps is reasonable estimate for latency but as an estimate for pin wake jitter it is off by a factor of about 100. It switches in about 300ps, speed tends to vary by about 1% not 100%.

Best Wishes

Yeah, that's what I found about crystal freqs. You can buy them at

100's of kHz, but not from stock. I have no idea what power level is reasonable. Where did you get the number you came up with? 1 MHz is not too far from what I would like and is available as a crystal easily, 1.8432 MHz is another that is very common and very cheap, but every time you double the frequency, the power would double I expect. It certainly does in the processor.

Rick

It doesn't work yet, so it is not a claim, it is what I expected. Probably too optimistic, indeed. Let's say 300 pS jitter, i.e. a third of the fastest instruction.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Hi Jeff,

I think I have posted this here, but I'm not sure. I've been running simulations in Spice to see how a crystal will behave when operated in a manner similar to this. One thing I found is that when stimulus and monitoring is done with one pin, the actual threshold of the input is important. Typically this threshold is not well controlled. CMOS data sheets typically allow input threshold range to be 25% to 75% of Vdd or even 20% to 80% of Vdd. I don't know how much of this range is actually found in real devices.

Do you have any idea what to expect for the range of input threshold?

Rick

The people at green arrays calculate differently. They sum the energy needed for a computation, i.e. useful work. They use pJ which amounts to 1V 1 uA during 1 uS.

So in the case of the 32 khz crystal:

wake up itself : X pJ instruction one : Y pJ ..... instruction five: Y pJ instruction wait-for-pin : Z pJ total say : XXX pJ This is the cost of one cycle to be expended 32,000 time each second.

Then the processor goes to sleep which takes 7.5 nA which drains the battery at the rate of 1.8 * 7.5 nAV = 13500 pJ/second

Here you have to add the energy budget for driving the crystal which is quite possibly the largest of all. So you can see the motivation to keep the extra circuitry down.

P.S. The Ah li-ion accu of my Nokia cell phone contains 11,764,000,000,000,000 pJ

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

I don't argue with the need to keep things symmetric. I had a private exchange with GreenArrays and Greg Baily literally says: "At any rate the working oscillator once started is trivial"

This has drawn my attention to a point you seem to have missed. Look at the document F18 I/O where it says pin wakeup. You can wait for either polarity change! So you can wait for it to be up and yank the output one way, and then you can wait for it to be down and yank it the other way. This should take care of your unbalance problem.

As others have pointed out the real problem is to get things started with a higher frequency crystal like 1 Mhz. The Q is too high so that it is very difficult to hit the exact right frequency.

I hope you give the one pin another shot.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Ok, that would be for the first cycle, the wake-up. However, how much stuff is going to happen in terms of processing until the chip performs the next crystal goosing if it deems it to be necessary, from first wake-up to applying current to this pin? In an asynchronous processor (sans clock) the latencies and thus phase noise effects can add up quickly.

This can be simulated until the cows come home but the only way to really find out is to hang a good spectrum analyzer to this pin. Use at least a 10dB step attenuator in order not to fry in, and a FET probe of course.

--
Regards, Joerg

http://www.analogconsultants.com/

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

A

Where did you get the number for the static leakage current of 7.5 nA. In white paper 3 dated June 2010, they state that the idle current of a processor is 55 nA or approximately 100 nW. BTW, pJ/ second is also known as a pW. I'm sure you know that, so I'm not sure what point you were trying to make by expressing the value that way, especially since the starting numbers were volts and nA.

Rick

y.

Thanks for your inputs.

Rick

Maybe you are imagining a lot of code on a bigger more complex processor.

@ drop . !b

packs to one word of code,

the fetch (@) runs for about a nanosecond before it sleeps waiting for xtal to change. When the xtal changes the processor begins the code that worries you in about 300ps. The fetch completes in about 3ns, the drop takes 1.5ns but takes place in parallel with the next instruction fetch which takes 5ns. Then it starts to "goose" the xtal about 1ns later. So it is just under

10ns between sync and pulse start in that code.

Your concern is with how much the asynchronous processor will vary in speed in this 10ns of code. I would not expect it to vary by more than pico-second or so. Since this happens on every 180 degrees of the xtal the 1ps of jitter isn't going to matter much..

y.

If the first thing a processor does after it awakens from sleep waiting for a state change on the xtal to sync up to it is to output a pulse then the pulse would start about 10 nanoseconds after each change of the xtal. This ten nano-second latency delay would be subject to a few picoseconds of jitter. It can sleep and sync up twice on each cycle.

There is only 180 degrees in each cycle before things resync again so there is an issue with the asynchronous nature of the processor but its not an issue on this 10ns window in this example.

If there is an issue, and that hasn't been determined it is that iIf the xtal is a slow one and cycles are very long then pulses to drive it are also long. So it can stay synchronized with the xtal on xtal transitions to within picoseconds, but the asynchronous nature of the processor could result in a 1% long term variability of pulse width. Whether this is enough to require a a penny watchdog monitor to measure duty cycle and adjust the pulse width needed by a nano-second or two isn't clear. It doesn't look like a big problem to me at all, and if it is a problem at all I would expect an easy solution.

This isn't one of those examples where the programmer has to get the thing to do some computation ten times faster than your Pentium, or do something that should sound hard to people, it's an xtal.

I was thinking of testing a 10MHz xtal where there are only

50ns between xtal transitions so the expected error in variation of the drive pulse due to the asynchronous nature of the processor should be a fraction of nanosecond and if that bothers people I think their concerns are misplaced.

Richman's concern is with the width of the threshold of the detector. That should be easy to measure on the last version of the chip, but might change slightly on the version in fab today. My expectation is for a very narrow range close to

50% and why it is not good to float inputs and why there is a pin input mode with weak-pulldown. Pad drivers have changed over the years to get them to work better.

I can certainly measure it and give rickman the actual numbers that he wants to understand the process.

rickman's concern is that he has read of 20%-80% variability on other systems and that would result in huge phase noise. Pad driver circuits have had changes over the last year but I have never seen anything like that in cad or on previous pad drivers.

I don't have a good spectrum analyzer or ever a gigahertz scope like the one used in the original article. My experiments could use other core on the chip if I want to record lots of data. But even if I monitor the digitally driven xtal with an analog input and record the signal and do fft and power spectrum analysis on it the probe by the a/d would effect the circuit just like the probe on the gigahertz scope they used on the first demonstration that it is easy to get an xtal ringing. My impression is that these things likely have more effect than things like the idea that a picosecond of circuit jitter is a big problem.

My take is that all rickman asked about was what would the code look like that could produce drive that would be well balanced enough over time to ensure that the thing does not get over driven and under driven once ringing as he was running some Spice simulations of something like that.

I offered the explanations I could short of giving him some new experimental results that he asked for. He has also asked for results of a different experiment, to measure the threshold detect level. That's fine.

That sort of thing is easier to do than explaining the whole context of his question to people who are not familiar with this technology that is sort of like FPGA but where the function blocks are actually small asynchronous micros with ROM and RAM that form synchronous systems using pin and communication links to synchronize processes. I understand that many people have a knee-jerk reaction to people talking about having ten one penny processors outperforming their Pentium on some number crunching application or being able to sync up to each of ten external signals with low latency and jitter.

I have just been trying to help some people who didn't seem to understand what the original question was about or how the code in question would work. Maybe I should stick to answering rickman's questions.

Turning the tutorial explanations into a project that would end with documenting what the test equipment show isn't on my to-do list. Often when people on usenet tell you to go do something it is just meant as a dismissal and insult because they don't want to discuss the subject further. That's ok. If it is something that is actually important to you send me an email and we can discuss what you need.

Best Wishes

I have described the problem with the single pin drive several times in this thread as well as multiple times in others. I can only assume that either you didn't bother to read that or you read it and don't understand the details. I will try to explain it again.

I have already tried the bidirectional "kick". The crystal is started with a square wave of a frequency that will put energy into the crystal sufficient to make it ring to 0.6 volts pp or more when the square wave is stopped. The output is then put into the high impedance state, which must be carefully timed to center the bias point of the crystal to around half the Vdd voltage. Otherwise the crystal voltage can exceed Vdd or Vss and be clamped by the protection diodes. From then on the processor is stopped waiting for the crystal voltage to cross the input threashold (in either direction) at which point it will drive the I/O pin in the same direction the crystal voltage is moving. In my simulations I assume this is done for two instruction times (3 ns); I suppose it is possible to make this one instruction time if the needed data and address values are already on the stack and/or registers. Each time the input threshold is crossed, the I/O pin is "kicked" in the appropriate direction. This is the simulation model I am using.

The problem I have found when doing all this on a single I/O pin happens when the input threshold is not at the midpoint of Vdd and Vss. In that case, the voltage difference between the I/O pin (and hence the crystal) and the drive voltage is not the same for each direction of "kick". Therefore the amplitude of the "kick" is not equal. Unfortunately, the stronger "kick" is in the opposite direction of the offset in the input threshold. This pushes the oscillations away from the threashold until one of two things happen. Either the oscillations forward bias the protection diodes which drains power from the crystal, interferring with the oscillations or the oscillations are not strong enough to overcome the bias and reach the threshold anymore at which point the oscillations become erratic or stop entirely.

You can try to add a bias circuit to drag the bias point back near the center of Vdd and Vss, but that adds a significant load and can only partially compensate for the offset drive of the uneven "kicks".

If you don't understand this, draw a sine wave centered between Vdd and Vss. Then draw the line for the threshold voltage through the full graph. The threshold crossings are the points where the "kick" will be delivered. Measure the difference in voltage between the sine wave and the corresponding voltage rail. You will easily see that they are not equal.

As long as the threshold is at 0.9 volts, this circuit works perfectly. But I don't think digital CMOS inputs are typically designed to map accurately to the center of Vdd and Vss. I regularly see specs of 0.3 to 0.7 * Vdd or even 0.25 to 0.75 * Vdd as the input threshold range. I don't know what range actually is found in production. But with a threshold of 0.5 volts (~ 0.3 * Vdd) the simulation won't continue oscillations.

If you still believe I am mistaken, please runs some simulations that show I am wrong. Or better yet, get someone to give you a board with a chip on it and show us a working circuit... by that I mean one that works in a context of the real world with some sort of temperature, duty cycle, jitter, etc. specs, not some hobby setup that will work for that one chip at room temperature, ect.

I won't make any disparaging comments about the GreenArrays people, but I think the quoted passage above is likely uninformed. If it really is so "trivial" to make a fully functional oscillator which meets some set of defined specifications, then why did the app note stop so woefully short? I think it is time that GreenArrays takes the lead on this; as was posted earlier, hic Rhodus, hic salta.

I will wait for GreenArrays to finish their app note on this.

Rick

1psec after 10nsec of handling stuff? Now that I seriously doubt. You mentioned 1% for the 300psec wakeup. That's already 3psec. 10nsec is 30 times longer. Assuming an asynchronous processor, how does this reduce the jitter to 1psec?

Ok, the "few picoseconds" I'd want to see. Not in simulations but in real life, on an analyzer :-)

On the ubiquitous 32.768kHz watch crystal the wait time between half-cycles is about 15.26usec. Unless you have a PLL any sort of PWM or frequency generation at a faster clip with this processor would most likely be quite noisy. Doesn't matter for many applications but with some it does.

Unless it's people like me who use processors in the signal acquisition of Doppler ultrasound and similar apps :-)

^^^^^^

That would be after he rakes in the first million in royalties :-))

Right on. Measuring it is the only way to know for sure.

I'd wager that we are talking more than a picosecond here. A lot more. But you do need a good analyzer.

SPICE is a good start. One can use ideal switches and then slowly alter the circuit so it mimics the real thing. But in the end you must measure.

Depends on the application. Some people do need low jitter nearly all the time. I am one of them. But Rick might not need that.

I don't need it and it wasn't meant as a dismissal at all. I was just trying to help, with suggestions how to measure it (I have don't it a lot).

--
Regards, Joerg

http://www.analogconsultants.com/

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

You've rather missed the point : My numbers are for oscillator power budgets alone, what you ADD to that does not matter.

You've also made a common error, of thinking a Sine drive to a Digital pin, has no power cost.

Do a plot of Icc/Vin, to see what really happens. Add that to the oscillator.

-jg

There will be a number of jitter sources, the worst I can see in this example/wishlist, of a 32KHz sinewave into a digital pin, will be transition oscillations. (which will also cause false clocking)

However, setting that to one side for a moment, another reality check on a Sine pin, is to convert the voltage slew, to a time domain. A good comparator on a slow edge, has ~20,000:1 jitter, which on a 2V

32.768KHz signal, maps to ~1.5ns - so that is one timing ballpark. Note that 1.5ns is also ~100uv, which is a big ask in a digital die.

If your SW / project was such that you were sure that the Async Core was NEVER still running near any sine/crystal edge, (and nothing else was switching), you just might get sub mV levels.

However, if the core was still active (and that's looking like ~5000 opcodes?) then the chip-noise would dominate, and you might be lucky to get 10mV (100x worse)

All of this makes an external oscillator, more preferred for anything where jitter matters.

-jg

Joerg,

You clearly don't understand what is being said about how the processor works and/or what claims people are making about the timing of this processor. You can make noise here all day long, but the fact remains that regardless of whether the claims are true (I can't say since I have not seen the data yet), the context in which you are doubting them is baseless. You just don't understand what is going on with the timing.

If you really want to continue discussing this, you need to lose the attitude and make it clear that you are interested in learning something. Instead you seem to be assuming that this problem is like other problems you have dealt with and are showing your lack of understanding of this one. "Unless you have a PLL any sort of PWM or frequency generation at a faster clip with this processor would most likely be quite noisy." There is no PLL and no PWM. What arrangement are you assuming is being used for the timing? Whatever it is, it is not what is being discussed.

I'm not trying to be rude, but I find your comments to be pretty close to rude. If you really want to discuss this, then stop telling us we are wrong about things you clearly do not understand and ask questions that aren't confrontational and might actually help you understand.

Rick

.

I'm not sure I understand this calculation. What does the 20,000:1 jitter mean and how do you get that value? I won't argue the issue of jitter in the analog vs. digital conversion. I am sure there will be measurable jitter there, I just don't know how much and don't have the confidence you seem to have in estimating it.

There are actually 144 of these cores on the chip, but this will be very different from a chip with the same amount of logic and a global clock for the chip. There is no massive clock tree swinging voltage from rail to rail. Instead each processor is internally clocked on its own timing creating orders of magnitude less ground noise.

Without commenting on the assumption, I don't think you have a basis for this estimate. This chip is not like others you have worked with.

How exactly will an external oscillator reduce the jitter? If a buffer or transistor is used, they will still see measurable noise in the ground and power planes of the board. I guess we can discuss this all day long, but my concern is that I haven't seen an oscillator that will run at the low currents required for an application running from a AAA alkaline cell for a year. The total power budget would be about

100 uA or 180 uW. I expect the processor to need most of that. So maybe as much as 50 uW would be used by the oscillator at 600 kHz to 1 MHz. I don't know enough about designing oscillators to know if this is practical with a buffer or transistor oscillator.

Rick