Digital Crystal Oscillator

On Jan 5, 7:54=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <b193a963-a25f-45c8-8a1a-5de0bc5f2...@k14g2000pre.googlegroups=
.com>,
>
>
>
> malcolm =A0<malcolm...@gmail.com> wrote:
> >On Jan 4, 5:19=3DA0pm, rickman <gnu...@gmail.com> wrote:
>
> >> I'm not sure what your 1 uA figure refers to. =3DA0
>
> >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.
>
> >> MY need is for an
> >> oscillator in the range of 300 kHz to 1 MHz. =3DA0If you buy a canned
> >> oscillator they aren't drawing 1 uA. =3DA0The lowest I can find is 3 m=
A
> >> and that is an all silicon unit.
>
> >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. =A0(and 0.3%-0.5% tolerance)
>
> 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 =A0itself : =A0X pJ
> instruction one : =A0Y pJ
> .....
> instruction five: =A0Y pJ
> instruction wait-for-pin : =A0Z pJ
> =A0 =A0 =A0total =A0 say =A0 =A0 : 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 =3D 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.

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

On Jan 5, 12:26=A0pm, Joerg <inva...@invalid.invalid> wrote:
> Jeff Fox wrote:
> > On Jan 4, 2:11 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> > wrote:
> >> 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.
>
> > Working chips in versions with 24, and 40 core were working
> > as long as five years ago. =A0 =A0The 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. =A0 The 144 core chips in fab today
> > do have changes from previous designs =A0and 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. =A0The processor goes from full sleep to full speed
> > within 300ps of an external event on the pin. =A0This 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. =A0It switches
> > in about 300ps, speed tends to vary by about 1% not 100%.
>
> 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 quickl=
y.
>
> 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

Thanks for your inputs.

Rick

On Jan 5, 9:26=A0am, Joerg <inva...@invalid.invalid> wrote:
> 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?

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

> In an asynchronous processor
> (sans clock) the latencies and thus phase noise effects can add up quickl=
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.

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

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.

> Use at
> least a 10dB step attenuator in order not to fry in, and a FET probe of
> course.

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

On Jan 5, 8:42 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <3ec31eb2-736f-46c1-8495-387068276...@d8g2000yqf.googlegroups.com>,
>
> rickman  <gnu...@gmail.com> wrote:
> >I've spent some more time with the simulation looking at alternative
> >ways to make it work and I'm pretty sure a single pin for stimulation
> >and observation is not practical.  The problem is that the input
> >threashold is not set exactly in the center of the power-ground
> >range.  Any displacement causes the two pushes (positive or negative)
> >to unbalance and move the bias point in the opposite direction of the
> >threashold.  With even a modest offset in the threshold the
> >oscillations end up not crossing the threashold and operation stops.
>
> 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'm going to explore a two pin approach.
>
> I hope you give the one pin another shot.
>
>
>
> >Rick
>
> Groetjes Albert

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

Jeff Fox wrote:
> On Jan 5, 9:26 am, Joerg <inva...@invalid.invalid> wrote:
>> 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?
> 
> 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..
> 

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?


>> In an asynchronous processor
>> (sans clock) the latencies and thus phase noise effects can add up quickly.
> 
> 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.
> 

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


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

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.


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

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


> Richman's concern is with the width of the threshold of the
 ^^^^^^

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


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

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


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

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


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

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.


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

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.


>> Use at
>> least a 10dB step attenuator in order not to fry in, and a FET probe of
>> course.
> 
> 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.
> 

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.

On Jan 6, 1:54=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> 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 =A0itself : =A0X pJ
> instruction one : =A0Y pJ
> .....
> instruction five: =A0Y pJ
> instruction wait-for-pin : =A0Z pJ
> =A0 =A0 =A0total =A0 say =A0 =A0 : 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 =3D 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.

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

On Jan 6, 10:01=A0am, Joerg <inva...@invalid.invalid> wrote:

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

 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

On Jan 5, 4:01 pm, Joerg <inva...@invalid.invalid> wrote:
> Jeff Fox wrote:
> > On Jan 5, 9:26 am, Joerg <inva...@invalid.invalid> wrote:
> >> 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?
>
> > 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..
>
> 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?
>
> >> In an asynchronous processor
> >> (sans clock) the latencies and thus phase noise effects can add up quickly.
>
> > 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.
>
> Ok, the "few picoseconds" I'd want to see. Not in simulations but in
> real life, on an analyzer :-)
>
>
>
> > 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.
>
> 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.
>
> > 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.
>
> Unless it's people like me who use processors in the signal acquisition
> of Doppler ultrasound and similar apps :-)
>
> > Richman's concern is with the width of the threshold of the
>
>  ^^^^^^
>
> That would be after he rakes in the first million in royalties :-))
>
> > 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.
>
> Right on. Measuring it is the only way to know for sure.
>
>
>
> > 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.
>
> >> 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.
>
> > 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.
>
> I'd wager that we are talking more than a picosecond here. A lot more.
> But you do need a good analyzer.
>
> > 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.
>
> 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.
>
>
>
> > 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.
>
> 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.
>
>
>
> >> Use at
> >> least a 10dB step attenuator in order not to fry in, and a FET probe of
> >> course.
>
> > 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.
>
> 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.

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

On Jan 5, 5:23=A0pm, malcolm <malcolm...@gmail.com> wrote:
> On Jan 6, 10:01=A0am, Joerg <inva...@invalid.invalid> wrote:
>
> > Ok, the "few picoseconds" I'd want to see. Not in simulations but in
> > real life, on an analyzer :-)
>
> =A0There 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)
>
> =A0However, 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.
> =A0A good comparator on a slow edge, has ~20,000:1 jitter, which on a 2V
> 32.768KHz signal, maps to ~1.5ns =A0- so that is one timing ballpark.
> =A0Note that 1.5ns is also =A0~100uv, which is a big ask in a digital die=
.

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.


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

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.


> =A0However, 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)

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.


> =A0All of this makes an external oscillator, more preferred for anything
> where jitter matters.

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

On Jan 5, 1:01=A0pm, Joerg <inva...@invalid.invalid> wrote:

I haven't run any tests that ran for loner than three weeks.  I saw a
maximum of less than 1% over a period of weeks.  I didn't see a 1%
drift
every few nanoseconds.  If it did have a 1% variation after only a few
nanoseconds it could show a jitter of 100ps on that 10ns of code
but I have no evidence that it changes that fast.

> Ok, the "few picoseconds" I'd want to see.

Many people have reacted to the 300ps latency
to sync nodes as it faster than what they are
used to.  The fact that it will vary by only a
few picoseconds is in line with everything else
tested.

> On the ubiquitous 32.768kHz watch crystal the wait time between
> half-cycles is about 15.26usec.

Sure.  You sync to changes.  The pulse kick timing is subject
to probably less than the 1% variation on that 10ns of code
from pulse to pulse than over a total of 10^15 cycles in a test.
I have seen no reason to suspect that the driving pulse cannot
tolerate that much variation.  I think it a tempest in a teacup.
If it were that hard to drive an xtal then all those simple circuits
with cheap transistors would have the same problem.

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

I don't know what hardware you think you are describing.
I am beginning to get a sense that you are not talking about
the hardware that original poster asked about.  When there
is no clock to drive the design there is also no PLL or
PWM hardware connected to the non-existence clock circuit.

> > Richman's concern is with the width of the threshold of the

Yes. He imagines something terrible like 20-80% and his
simulations suggest that wouldn't work when he assumes
it is that bad.  I wonder what results he would get with
51% and 49%,  I am used to seeing something very close
to 50% so I hadn't imagined  concerns over other things
being between 20% and 80%.

> > I can certainly measure it and give rickman the actual
> > numbers that he wants to understand the process.
>
> Right on. Measuring it is the only way to know for sure.

Sure. Simulations are fine, but if you make the wrong
guesses about things like where the sense threshold is
the simulation may not do what the real chip does.

For twenty years I have been working on the develop
of these sorts of chips.  You have to do lots of simulation
in the development process before you can make chips
so you can't start by testing the chips.  To make the
whole process work you have to get the simulation to
be accurate as possible to reduce chances that actual
hardware may not work.  We have things close enough
that all the designs in the last few years have worked
as predicted by simulation.

You can't get accurate enough numbers from other
people to simulate the effect of things like the package
will have on pads.  So all you can do it make it and
test it.  You test the last one back from fab.  You can't
give the results of tests on chips with foundry, design,
or package changes while the chips are in fab and
are not yet packaged.   You can predict a lot of things
but the exact result of what the foundry and package
house actually did always has to be tested.

We developed all the software for 4OS and the Internet
Appliance at iTV in the bit level simulator on the PC
and dropped a working application into the FLASH
memory when chips came back from FAB and were
tested. So I like simulations since they don't have
the observer effect problem with probing things
in the real world.  All the ROM code on these chips
was developed in simulation before the chips were
made.

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

A logic analyzer won't show the circuit from the pin that
starts the processor running at full speed in 300ps.  That's
internal to each processor ith one and not a circuit you
can probe with hardware.  Of course we had to make
tests circuits with on-chip probes long ago to
characterize these circuits and fine tune cad simulation.

Years ago we looked at a different chip as it was running
in a scanning electron microscope.  You could see
individual transistors switching but you really couldn't
measure the number of picoseconds of jitter on a
300ps internal circuit.

I have no idea how much variation in time take place in a
300ps transistor circuit from one switch to the next.  Words
like small, large, and very large are pretty meaningless.
5% sounds absurdly large to me but 15ps doesn't sound
like a "very large" amount of time.  You are free to make
a value judgment that a couple of picoseconds sounds
like a large amount of time to you.

My experience is that most people get argumentative when
you go from milliseconds and microseconds in embedded
computing to talking nanoseconds, and many people object
when they start hearing discussions of picoseconds.   And
you are the first person to tell me that a couple of picoseconds
is a long period of time.

> SPICE is a good start.

With the danger of spinning further of subject I will say that
rickman's SPICE simulations are fine.  However the history of
this whole project, for twenty years, has been designing and
building circuits that SPICE says can't work.  What was said
almost twenty years ago was that SPICE has to be tuned down
by about an order to magnitude to be able to predict what
the circuits that come out of the fabs will actually do and
the characterization that the fabs provide themselves are
not very accurate.  The fabs love FPGA because they use
them to calibrate their own processes as best they can.

By working out where it was in error it was possible to get
closer to the actual limit of the silicon.  When we made a
500MHz processor in the 90s without pipelining or cache
and in .8u CMOS we were told by SPICE and many chip
experts in top companies around the world that we were
off by an order of magnitude in our estimates and that
50MHz was the best we could expect to work.  The
experts on usenet said the same thing. We had lots of
proof that SPICE said 50MHz was possible in .8u but that
500MHz was impossible. They would say, "Do you realize
that Intel was only able to get 64MHz in .8u even with deep
pipelining and cache?"  Sure.

Some of the companies where these SPICE experts worked,
besides our own, contracted for consulting to raise the
skill of their designers and many licensed patents that
were developed and that they wanted to use.

It was fun to then ask how it was possible for the person
at that desk to be surfing the internet using an internet
appliance using one of the chips that SPICE said could
not possibly run at all.  We have seen that on several
generations of designs so I just warn you that SPICE
isn't the last word on the subject, working circuits are.

We have learned how to tweak SPICE to get results
that are closer to what our simulator predicts and
to what the actual circuits do.   But thinking that SPICE
can simulate what goes on in the circuits inside of
the chip is an error.

Since the new parts are not available yet people
have only been able to place advanced orders.
If they have something they need to know now they
can ask and we can say what we have seen on the
last version of the chip and what we expect.   If it
is something important attention will be paid to it.

> I was just trying to help, with suggestions how to
> measure it (I have don't it a lot).

I can say is that I never saw more than 1% variation in pulse timing
over 10^15 cycles in a test.    To me that says that things don't
change
more than that from one cycle to the next so I think concern about
that
is misplaced. I have also seen a threshold very close to 50% so again
I think concern that it might be anywhere from 30% to 70%  or from
20% to 80% also seems like misplaced concern.

I will run some threshold tests to see how much of an issue it is
and we can see what simulation says with those numbers.

Best Wishes