On Jan 6, 7:35=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <faf105a2-d3ae-4bda-89c2-f38b31ba6...@y3g2000vbm.googlegroups.=
com>,
>
>
>
> rickman =A0<gnu...@gmail.com> wrote:
> >On Jan 5, 8:42 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> >wrote:
> >> In article <3ec31eb2-736f-46c1-8495-387068276...@d8g2000yqf.googlegrou=
ps.com>,
>
> >> rickman =A0<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. =A0The problem is that the input
> >> >threashold is not set exactly in the center of the power-ground
> >> >range. =A0Any displacement causes the two pushes (positive or negativ=
e)
> >> >to unbalance and move the bias point in the opposite direction of the
> >> >threashold. =A0With 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. =A0I can only assume
> >that either you didn't bother to read that or you read it and don't
> >understand the details. =A0I will try to explain it again.
>
> >I have already tried the bidirectional "kick". =A0The 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. =A0The 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. =A0Otherwise the
> >crystal voltage can exceed Vdd or Vss and be clamped by the protection
> >diodes. =A0From 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. =A0In 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. =A0Each time the input threshold is crossed,
> >the I/O pin is "kicked" in the appropriate direction. =A0This is the
> >simulation model I am using.
>
> Experiment trumps theory. As the Green Array folks have it running
> this means your simulation is somehow off.


That must be why their app note shows all the details of how this
circuit works...  If they have it running, why wouldn't they have that
posted?  What exactly do they have running?

BTW, in case you didn't actually read my several postings on the
problem I encountered, understanding the problem has nothing to do
with the Spice simulation.  I was not aware of the issue until I saw
it in the simulation, but the problem is very easily understood if you
know how to add and subtract.  I would like to know exactly how they
are making the circuit work if it is indeed working properly.
Oscillating and oscillating with stability, accuracy, etc are totally
different.

Rick

In article <faf105a2-d3ae-4bda-89c2-f38b31ba6585@y3g2000vbm.googlegroups.com>,
rickman  <gnuarm@gmail.com> wrote:
>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.

Experiment trumps theory. As the Green Array folks have it running
this means your simulation is somehow off.

<SNIP>

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

I didn't wait, I just contacted them.

>
>Rick


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

In article <14f11b9a-e087-42c5-b981-74540d965f0b@fj8g2000vbb.googlegroups.com>,
rickman  <gnuarm@gmail.com> wrote:
>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.

I stand corrected. The point is that GreenArrays counts the total
drain on the power supply.

>
>Rick


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

On Jan 5, 7:59=A0pm, malcolm <malcolm...@gmail.com> wrote:
> On Jan 6, 12:40=A0pm, Jeff Fox <f...@ultratechnology.com> wrote:
>
>
>
> > 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.
>
> Are you simulating the chip in question ?
>
> Can you give Icc/Vin simulation results, for both Schmitt and non-
> schmitt pin options, (if a choice exists) ?
>
> Re threshold variations, these are the numbers from Atmel's ATF1504BE
>
> ATF1504BE : Table 8-5. Schmitt Trigger Input Threshold Voltage
> VCCINT =A0VTHL =A0 Min..Max ; VTLH =A0Min..Max
> 1.70 0.68..0.73 ; 1.05..1.08
> 1.95 0.81..0.88 ; 1.18..1.22
>
> So Atmel spec =A050mV & 30mV at 1.70V, and 70mV & 40mV at 1.90V.
>
> -jg

That's a Schmitt trigger circuit.  The variations in input threshold
have nothing to do with the threshold variations in a non-Schmitt
trigger input.

Rick

Jeff, I want to respond to a couple of points you made.


On Jan 5, 6:40 pm, Jeff Fox <f...@ultratechnology.com> wrote:
> On Jan 5, 1:01 pm, Joerg <inva...@invalid.invalid> wrote:
>
> > > 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%.

Please don't exaggerate my statements.  I said that the circuit stops
working well as the threshold moves away from center.  I said that
most CMOS chips I have seen have specs on the input threshold of 30 to
70% Vdd and some are 25% to 75% Vdd.  I don't know what the GA144 will
be.  That's because there is a lack of data available yet.  But no one
has said it would be 49% to 51% of Vdd.  If so, it would work just
fine.  But that would require that not only are a handful of chips
tested to this spec, but that by some means the production devices are
assured to meet a given spec that will allow this circuit to work.  We
will see what come from GA over the next few months.


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

I'm not making guesses, I am exploring the design space.  At Vth = .85
volts the circuit works ok.  At Vth = 0.5 the circuit doesn't work at
all.  When I know where in that range the actual threshold is
guaranteed to fall, I will do more tests.



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

I think you need to make a distinction between Spice and the models
Spice uses.  When you try to simulate a transistor drawn on near state
of the art process dimensions you are working in a zone that is not as
well understood as capacitors and resistors.  Not simulating chips
accurately is not the same as not being able to accurately simulate a
resonant circuit.


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

When I found the biasing problem running the Spice simulation I
realized that this was actually pretty obvious.  I don't need Spice to
tell me that if Vth < 1/2 * Vdd, then Vdd - Vth is greater than Vth.
So a deviation in threshold voltage from 1/2 * Vdd will produce a bias
to the crystal oscillation voltage in the opposite direction.  If that
deviation is large enough the oscillations are disturbed or or stop.
So I will wait until the threshold voltage range is specified or GA
provides an oscillator circuit design that they assure me will work
reliably and within some provided specs.

I actually would not be using Spice for simulation, but using such a
non-linear drive as this narrow impulse is hard to describe
mathematically in a way that has meaning in an oscillator circuit.
I'm not an analog guy.


> 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 guess GA must think the oscillator issue is one that has some
interest.  After all, they wrote a small piece of an app note about
it.  It would have been nice if they had finished it.  I'm actually a
little leery though.  Albert has quoted someone from GA as saying
something like once you have the crystal oscillating sustaining the
oscillations "is trivial".  Personally, I think that is backwards.
Pinging the crystal hard enough to make it ring is pretty trivial.  As
the author of the app note says, "even mechanically banging on the
crystal should get it to oscillate at its resonant frequency with low
amplitude".  Making the crystal oscillate reliably, in a stable manner
with low jitter (phase noise) is a much harder problem.


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

I'm not sure what you can measure really.  The threshold variation is
something that will happen some with temperature, maybe, but much more
so with process variation.  My understanding is that this is something
that has to be specified and tested on the production chips.  But I am
sure you know more about this than I do.

I did another round of simulations to try to pin down how much the
threshold offset impacts the oscillations.  Of course this will also
depend on the details of the crystal model and the other circuit
components.  I used a resistor between the crystal and the I/O pin
driver and varied it to see if it helps.  I was not able to get
sustained oscillations even with a threshold voltage of 0.85 volts.
Perhaps I have something wrong in the simulation, but the circuit is
pretty durn simple.

Rick

On Jan 6, 4:13=A0pm, rickman <gnu...@gmail.com> >
> Do you really think all digital chips are the same? =A0Is a quad nand
> gate as noisy as an x86 processor drawing tens of amps of current?
> How do you know anything about how much noise this chip will
> generate?

 Well, it is CMOS, and metalized, and complex, so I apply experience
in such devices, and get some ball park numbers, as well as obvious
combinations to avoid. (one is the core running, when you need a low
jitter threshold cross)

  This was re the branch topic of lowering Jitter;

 However, if you are serious about power, that's rather moot as you
will not be trying to use a digital pin as a (lousy) comparator.

 If we get the Icc/Vin sim's I asked for, you will see why.

-jg

On Jan 5, 7:47=A0pm, malcolm <malcolm...@gmail.com> wrote:
> On Jan 6, 12:01=A0pm, rickman <gnu...@gmail.com> wrote:
>
> > > =A0However, setting that to one side for a moment, another reality ch=
eck
> > > 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. =A0What does the 20,000:1
> > jitter mean and how do you get that value? =A0I won't argue the issue o=
f
> > jitter in the analog vs. digital conversion. =A0I 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.
>
> =A0That ~20,000 ballpark is for a good comparator, and you can measure
> it, or you can look at the delayed timebase specs on good scopes.
> (1:20,000 is 86dB)
> I'd expect a generic digital pin, to be rather worse than that.

20,000 of what to 1 of what?  I don't know what this ratio is about...


> > > =A0If your SW / project was such that you were sure that the Async Co=
re
> > > 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. =A0There is no massive clock tree swinging voltage
> > from rail to rail. =A0Instead 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 ~50=
00
> > > 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. =A0This chip is not like others you have worked
> > with.
>
> What ? to say a Digital chip operating, is going to be over 100x
> noisier than a digital chip not operating ? - Feel free to measure
> one, and report back.

Do you really think all digital chips are the same?  Is a quad nand
gate as noisy as an x86 processor drawing tens of amps of current?
How do you know anything about how much noise this chip will
generate?


> > > =A0All of this makes an external oscillator, more preferred for anyth=
ing
> > > where jitter matters.
>
> > How exactly will an external oscillator reduce the jitter? =A0If a
> > buffer or transistor is used, they will still see measurable noise in
> > the ground and power planes of the board.
>
> Yes, but
> a) A separate oscillator AVOIDs any common mode inductance noise
> sources
> b) =A0You can easily further filter a separate oscillator.
>
> > 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. =A0The total power budget would be abou=
t
> > 100 uA or 180 uW. =A0I expect the processor to need most of that. =A0So
> > maybe as much as 50 uW would be used by the oscillator at 600 kHz to 1
> > MHz. =A0I don't know enough about designing oscillators to know if this
> > is practical with a buffer or transistor oscillator.
>
> If you are chasing sub 50uA, then a linear-mode digital pin will
> likely not meet that.
> Ask the vendor for a Icc/Vin plot to be sure (or, derive your own)
>
> My rule of thumb, is appx 20uA/MHz for a 'well designed' =A0current feed
> Oscillator+Buffer.

I haven't spoken with the vendor at all as they are very busy and have
asked not to be bothered unless you have a real question... by that I
assume they mean unless you are interested in buying a bunch of chips
which I can't commit to in any meaningful way.

How do you come up with the 20 uA/MHz figure?  The canned oscillators
I find are more like 1 mA/MHz.  Maybe I should try simulating a
discrete oscillator in spice.  I could measure the actual power
consumption easily.  But I am on to other things at the moment.
Perhaps in a week or two.

Rick

On Jan 6, 12:40=A0pm, Jeff Fox <f...@ultratechnology.com> wrote:
>
> 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.

Are you simulating the chip in question ?

Can you give Icc/Vin simulation results, for both Schmitt and non-
schmitt pin options, (if a choice exists) ?

Re threshold variations, these are the numbers from Atmel's ATF1504BE

ATF1504BE : Table 8-5. Schmitt Trigger Input Threshold Voltage
VCCINT  VTHL   Min..Max ; VTLH  Min..Max
1.70 0.68..0.73 ; 1.05..1.08
1.95 0.81..0.88 ; 1.18..1.22

So Atmel spec  50mV & 30mV at 1.70V, and 70mV & 40mV at 1.90V.

-jg

Jeff Fox wrote:
> On Jan 5, 1:01 pm, Joerg <inva...@invalid.invalid> wrote:
> 
[...]

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

That will be tough on the shallow slope that a 32.768kHz crystal
generates. Regular oscillators have no problem with that as there is no
threshold to worry about. If the tap-off to the circuit to be clocked is
a concern that can be handled differentially but not if there's only one
pin.


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

What I meant was that unless there is a clock or PLL (and there isn't
here) the consecutive jitter values add up. Because an async processor
goes from one step to the other based on the completion of prior steps,
on the time that takes.


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

A clean CMOS design would be smack in the middle as you wrote, at 50%,
and stay there. Much of the threshold uncertainty actually comes from
VCC sags and ground bounce and this translates into phase noise or
jitter. When the processor is doing other jobs at the same time VCC will
not be stable. Decoupling caps can hold it rock solid externally but
there's still the bond wires and the substrate.


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

That's a necessity in IC design. Same here, but my stuff is mostly
analog, at least >50% of it. If the simulator is wrong the chip won't
work and the boss (or client) would not be too happy.


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

Doing something similar for ultrasound right now, where the code needs
to be part of the simulation. But it's partly analog and a white-knuckle
ride because we are pushing the design rules.


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

I meant a spectrum analyzer where you can measure noise sidebands.
HP8566 and similar. Direct connection isn't necessarily needed, getting
close to a metal layer trace might be enough. No joke, we have on
occasion carved a notch into the package and embedded a wee pickup coil.


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

In time domain you can't, I prefer spectrum analyzers. But not the
highfalutin newfangled kind that secretly switches to FFT sometimes.


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

15psec is *huge* in my world :-)


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

When it's jitter, yes. But again, this depends on your application. In
mine it usually is critical. In fact, we gauge things like track&hold
aperture jitter during AD conversion in hundreds of femtoseconds. To
give you an example, this one is claimed to be well under 0.1psec:

http://www.analog.com/static/imported-files/data_sheets/AD9445.pdf

On many of my designs a couple of psec would have adverse effects on
image quality. But it might not matter so much in Rick's case, I don't know.


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

I would have cheered you on and not told you that it's impossible.
Because we also made chips in the 90's that lived with 7-8nsec pulses
and all we had (at reasonable cost) were 0.8um processes.


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

Sure is, I agree. However, it's the models that aren't allowing it to
simulate the real world.


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

Well, on the chip we are doing right now it better be accurate because
that's all we've got until first silicon :-)


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

If you see 1% over 10^15 cycles that's pretty darn good although that
still doesn't tell you about short term jitter. Anyhow, then the
performance of this single-pin crystal oscillator might indeed hinge on
the threshold performance (offset drift and such).


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

If you do that maybe let some other reasonable stuff happen in the
various processor cores. It has an impact on threshold (bond wires,
substrate bounce, crosstalk, and so on).

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

On Jan 6, 12:01=A0pm, rickman <gnu...@gmail.com> wrote:
> > =A0However, setting that to one side for a moment, another reality chec=
k
> > 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 2=
V
> > 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 d=
ie.
>
> I'm not sure I understand this calculation. =A0What does the 20,000:1
> jitter mean and how do you get that value? =A0I won't argue the issue of
> jitter in the analog vs. digital conversion. =A0I 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.

 That ~20,000 ballpark is for a good comparator, and you can measure
it, or you can look at the delayed timebase specs on good scopes.
(1:20,000 is 86dB)
I'd expect a generic digital pin, to be rather worse than that.


> > =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. =A0There is no massive clock tree swinging voltage
> from rail to rail. =A0Instead 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. =A0This chip is not like others you have worked
> with.

What ? to say a Digital chip operating, is going to be over 100x
noisier than a digital chip not operating ? - Feel free to measure
one, and report back.

>
> > =A0All of this makes an external oscillator, more preferred for anythin=
g
> > where jitter matters.
>
> How exactly will an external oscillator reduce the jitter? =A0If a
> buffer or transistor is used, they will still see measurable noise in
> the ground and power planes of the board.

Yes, but
a) A separate oscillator AVOIDs any common mode inductance noise
sources
b)  You can easily further filter a separate oscillator.

> 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. =A0The total power budget would be about
> 100 uA or 180 uW. =A0I expect the processor to need most of that. =A0So
> maybe as much as 50 uW would be used by the oscillator at 600 kHz to 1
> MHz. =A0I don't know enough about designing oscillators to know if this
> is practical with a buffer or transistor oscillator.

If you are chasing sub 50uA, then a linear-mode digital pin will
likely not meet that.
Ask the vendor for a Icc/Vin plot to be sure (or, derive your own)

My rule of thumb, is appx 20uA/MHz for a 'well designed'  current feed
Oscillator+Buffer.

-jg