Digital Crystal Oscillator

On Jan 3, 4:34 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On 01/03/2011 12:44 PM, rickman wrote:
>
> > On Jan 3, 2:25 pm, Tim Wescott<t...@seemywebsite.com>  wrote:
>
> >> 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:http://www.eetimes.com/design/embedded/4006431/Sigma-delta-techniques...
> >> (http://tinyurl.com/23xuzxq).  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?
>
> > 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.
>
> That may work, that may not.

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.


> 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?

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.


> > I don't think the app note author was thinking of something like a
> > sigma-delta based drive.
>
> 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.
>
>  > That would take a lot of compute resources
>
> 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.

Guilty.  I didn't read your reference.


> > and one of the goals of this design is to use as little power as
> > possible.
>
> 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?

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.


> 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?

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.


> > 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.
>
> 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?

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.


> > 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.
>
> 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.

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

On Jan 3, 5:25=A0pm, Jeff Fox <f...@ultratechnology.com> wrote:
> On Jan 3, 11:07 am, Joerg <inva...@invalid.invalid> wrote:
>
> > 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?
>
> 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. =A0If 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. =A0I would be inclined
> to
> pump it a little differently to get it to that stage.

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.


> 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.

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.


> Different pin wake circuit design might change to a different
> version which would effect code. =A0But 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.

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 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. =A0If 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.

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.


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

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 think it possible to drive an xtal from both
> ends with two pins using similar techniques or
> simulate other external circuits. =A0I 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.

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

On Jan 3, 4:43=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On 01/03/2011 12:21 PM, rickman wrote:
>
> > Did you read the article? =A0I think you may have missed the basic
> > concept of what they are looking to do. =A0The 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. =A0This is the
> > part they tested. =A0Using a software loop with 2.5 ns resolution they
> > excited the crystal and set it oscillating. =A0Then 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. =A0This is not regulated by a separate clock. =A0The
> > processor is async and is in wait mode. =A0When 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...
>
> > =A0 =A0 =A0* Using the chip as a very high impedance active probe
> > =A0 =A0 =A0* Automating the crystal start-up
> > =A0 =A0 =A0* Keeping it running
> > =A0 =A0 =A0* Energy estimation and measurement
> > =A0 =A0 =A0* Comparison with other implentations [sic]
> > =A0 =A0 =A0* Ceramic resonator
> > =A0 =A0 =A0* External R-C network
>
> > I have been running some simulations on this idea and found that a
> > single pin oscillator likely won't work.
>
> You have run some simulations and found that you are not smart enough,
> or determined enough, to make a single pin oscillator work.

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


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

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?


> > 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. =A0If 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.
>
> How can that possibly be? =A0If 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. =A0All 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=
.

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.


> > 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.
>
> How did you determine this? =A0Did you turn off the computer for long
> enough to get out some paper and a pencil and go through the theoretical
> calculations?

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

On 01/03/2011 03:00 PM, rickman wrote:
> On Jan 3, 4:34 pm, Tim Wescott<t...@seemywebsite.com>  wrote:
>> On 01/03/2011 12:44 PM, rickman wrote:
>>
>>> On Jan 3, 2:25 pm, Tim Wescott<t...@seemywebsite.com>   wrote:
>>
>>>> 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:http://www.eetimes.com/design/embedded/4006431/Sigma-delta-techniques...
>>>> (http://tinyurl.com/23xuzxq).  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?
>>
>>> 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.
>>
>> That may work, that may not.
>
> 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.

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)

> 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.

er, ehem --- OK.

(snip)
>
> 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.

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.

> 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.

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

On Jan 4, 12:17=A0pm, rickman <gnu...@gmail.com> wrote:
>
> My concern is not just that it can or can't be done, but how well it
> works. =A0An oscillator needs to work over temperature, voltage and
> process, start reliably and not falter. =A0It 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. =A0Verifying that an
> oscillator does all this is not a simple task.

... 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

Tim Wescott wrote:
> On 01/03/2011 03:00 PM, rickman wrote:
>> On Jan 3, 4:34 pm, Tim Wescott<t...@seemywebsite.com>  wrote:
>>> On 01/03/2011 12:44 PM, rickman wrote:
>>>
>>>> On Jan 3, 2:25 pm, Tim Wescott<t...@seemywebsite.com>   wrote:
>>>
>>>>> 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:http://www.eetimes.com/design/embedded/4006431/Sigma-delta-techniques...
>>>>>
>>>>> (http://tinyurl.com/23xuzxq).  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?
>>>
>>>> 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.
>>>
>>> That may work, that may not.
>>
>> 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.
> 

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.


> 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)
> 
>> 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.
> 

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?


> er, ehem --- OK.
> 
> (snip)
>>
>> 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.
> 
> 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.
> 
>> 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.
> 

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.


> 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?
> 

The "Mixed Signal" 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.
> 

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.

On Jan 3, 3:17 pm, rickman <gnu...@gmail.com> wrote:

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.

> 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.

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.

> A watchdog should be pretty simple, but it requires another time base
> somewhere, somehow.

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.

> My concern is not just that it can or can't be done, but how well it
> works.

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.

> 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.

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.

> 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.

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

On Jan 3, 7:00 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On 01/03/2011 03:00 PM, rickman wrote:
>
> > On Jan 3, 4:34 pm, Tim Wescott<t...@seemywebsite.com>  wrote:
> >> On 01/03/2011 12:44 PM, rickman wrote:
>
> >>> On Jan 3, 2:25 pm, Tim Wescott<t...@seemywebsite.com>   wrote:
>
> >>>> 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:http://www.eetimes.com/design/embedded/4006431/Sigma-delta-techniques...
> >>>> (http://tinyurl.com/23xuzxq).  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?
>
> >>> 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.
>
> >> That may work, that may not.
>
> > 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.
>
> 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.

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.


> > 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.
>
> er, ehem --- OK.
>
> (snip)
>
>
>
> > 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.
>
> 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.

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.


> > 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.
>
> So Butler oscillators don't work, and the classic tuned-base,
> tuned-collector overtone oscillators don't work, etc., etc.?

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


> 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.

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.


> 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.

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

On Jan 3, 9:47 pm, Joerg <inva...@invalid.invalid> wrote:
> Tim Wescott wrote:
> > On 01/03/2011 03:00 PM, rickman wrote:
> >> On Jan 3, 4:34 pm, Tim Wescott<t...@seemywebsite.com>  wrote:
> >>> On 01/03/2011 12:44 PM, rickman wrote:
>
> >>>> On Jan 3, 2:25 pm, Tim Wescott<t...@seemywebsite.com>   wrote:
>
> >>>>> 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:http://www.eetimes.com/design/embedded/4006431/Sigma-delta-techniques...
>
> >>>>> (http://tinyurl.com/23xuzxq).  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?
>
> >>>> 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.
>
> >>> That may work, that may not.
>
> >> 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.
>
> 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.

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.


> > 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)
>
> >> 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.
>
> 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 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.


> >> 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.
>
> 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.

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


> > 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?
>
> The "Mixed Signal" 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.
>
> Rick, I can't see your posts because you are using Google but I'll see
> your text when someone responds.

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

Rick

On Jan 3, 8:05=A0pm, malcolm <malcolm...@gmail.com> wrote:
> On Jan 4, 12:17=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > My concern is not just that it can or can't be done, but how well it
> > works. =A0An oscillator needs to work over temperature, voltage and
> > process, start reliably and not falter. =A0It 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. =A0Verifying that an
> > oscillator does all this is not a simple task.
>
> ... and most designers would include a Power Budget in there too.
>
> =A0My 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 ? ) -
> =A0but 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)
>
> =A0Which raises the question of, =A0why bother ?

I'm not sure what your 1 uA figure refers to.  MY need is for an
oscillator in the range of 300 kHz to 1 MHz.  If you buy a canned
oscillator they aren't drawing 1 uA.  The lowest I can find is 3 mA
and that is an all silicon unit.

Your other comments are not really valid, but I get tired of trying to
explain myself to everyone who doesn't seem to want to listen.  I
think I understand how Jeff Fox feels.

Rick