Jim Granville wrote:
> langwadt@ieee.org wrote:
> > Paul Keinanen wrote:
> >
> <snip>
> >>For instance for the original 4000 series CMOS gates, the propagation
> >>delay with 50 pF load was about 100 ns at 5 V, but only 20 ns at 15 V.
> >>I do not have the figures for the whole 3 .. 18 V operating supply
> >>voltage range.
> >>
> >>Paul
> >
> >
> > yes trippling the voltage should make a difference, but how much can
> > you expect
> > from a modern process? +/-10%  before it either doesn't work or lets
> > out the smoke
>
> Not sure what you mean - modern process does not have an implicit narrow
> voltage range, but they DO often restrict the Vcc in order to meet speed
> targets, and to lower their testing costs.
>
> eg uC are available today that cover 1.8-5.5V, and AUC (?) logic
> covers 0.8V to 3.3V
>
> Part of the appeal of Async design, is to remove that tight requirement
> on Vcc.
>
> -jg

Last time I worked in something in 90nm, 1V was minimum to just retain
the state
of memory etc. nominal was 1.2V. How high do you think you could go
before it lets
out the smoke?  Just getting 3.3V IOs is a problem

-Lasse

langwadt@ieee.org wrote:
> Paul Keinanen wrote:
> 
<snip>
>>For instance for the original 4000 series CMOS gates, the propagation
>>delay with 50 pF load was about 100 ns at 5 V, but only 20 ns at 15 V.
>>I do not have the figures for the whole 3 .. 18 V operating supply
>>voltage range.
>>
>>Paul
> 
> 
> yes trippling the voltage should make a difference, but how much can
> you expect
> from a modern process? +/-10%  before it either doesn't work or lets
> out the smoke

Not sure what you mean - modern process does not have an implicit narrow
voltage range, but they DO often restrict the Vcc in order to meet speed 
targets, and to lower their testing costs.

eg uC are available today that cover 1.8-5.5V, and AUC (?) logic
covers 0.8V to 3.3V

Part of the appeal of Async design, is to remove that tight requirement 
on Vcc.

-jg

Paul Keinanen wrote:
> On 11 Sep 2006 15:01:13 -0700, langwadt@ieee.org wrote:
>
> >
> >Paul Keinanen wrote:
> >> On 11 Sep 2006 12:02:52 -0700, "rickman" <gnuarm@gmail.com> wrote:
> >>
> >> >A coworker suggested that async parts would be harder to produce to
> >> >work over a wide temperature range.
> >>
> >> If you have e.g. a simple multiple bit adder with ripple carry, there
> >> is a specific number of gate delays between the lowest Carry_in to the
> >> highest Carry_out. Add a similar chain of dummy gates (plus one or two
> >> extra gate delays), send the strobe pulse to this dummy chain at the
> >> same time as the actual values are loaded into the adder, the strobe
> >> pulse will arrive to the other end of the dummy chain, when the adder
> >> output has stabilised and thus, can be latched.
> >>
> >> Since the dummy chain is operating at the same temperature and supply
> >> voltage as the actual adder, any variation in the adder delay would
> >> also affect the dummy gate delay chain in the same way.
> >
> >couldn't you accomplish the same running everything off an on-chip
> >oscillator
> >that also tracks supply and temperature.
> >And how much does logic speed actually change over temperature and
> >voltage?
>
> For instance for the original 4000 series CMOS gates, the propagation
> delay with 50 pF load was about 100 ns at 5 V, but only 20 ns at 15 V.
> I do not have the figures for the whole 3 .. 18 V operating supply
> voltage range.
>
> Paul

yes trippling the voltage should make a difference, but how much can
you expect
from a modern process? +/-10%  before it either doesn't work or lets
out the smoke


-Lasse

In article <1157838835.360150.20320@i42g2000cwa.googlegroups.com>,
          gnuarm@gmail.com ("rickman") wrote:

> Wasn't there a real ARM (or other) MCU designed using async clocking?
> Anyone remember which company this was? 

I think there was a university project called Amulet.

   Tim

-- 
Tim Partridge. Any opinions expressed are mine only and not those of my employer

On 11 Sep 2006 15:01:13 -0700, langwadt@ieee.org wrote:

>
>Paul Keinanen wrote:
>> On 11 Sep 2006 12:02:52 -0700, "rickman" <gnuarm@gmail.com> wrote:
>>
>> >A coworker suggested that async parts would be harder to produce to
>> >work over a wide temperature range.
>>
>> If you have e.g. a simple multiple bit adder with ripple carry, there
>> is a specific number of gate delays between the lowest Carry_in to the
>> highest Carry_out. Add a similar chain of dummy gates (plus one or two
>> extra gate delays), send the strobe pulse to this dummy chain at the
>> same time as the actual values are loaded into the adder, the strobe
>> pulse will arrive to the other end of the dummy chain, when the adder
>> output has stabilised and thus, can be latched.
>>
>> Since the dummy chain is operating at the same temperature and supply
>> voltage as the actual adder, any variation in the adder delay would
>> also affect the dummy gate delay chain in the same way.
>
>couldn't you accomplish the same running everything off an on-chip
>oscillator
>that also tracks supply and temperature.
>And how much does logic speed actually change over temperature and
>voltage?

For instance for the original 4000 series CMOS gates, the propagation
delay with 50 pF load was about 100 ns at 5 V, but only 20 ns at 15 V.
I do not have the figures for the whole 3 .. 18 V operating supply
voltage range.

Paul

Paul Keinanen wrote:
> On 11 Sep 2006 12:02:52 -0700, "rickman" <gnuarm@gmail.com> wrote:
>
> >A coworker suggested that async parts would be harder to produce to
> >work over a wide temperature range.
>
> If you have e.g. a simple multiple bit adder with ripple carry, there
> is a specific number of gate delays between the lowest Carry_in to the
> highest Carry_out. Add a similar chain of dummy gates (plus one or two
> extra gate delays), send the strobe pulse to this dummy chain at the
> same time as the actual values are loaded into the adder, the strobe
> pulse will arrive to the other end of the dummy chain, when the adder
> output has stabilised and thus, can be latched.
>
> Since the dummy chain is operating at the same temperature and supply
> voltage as the actual adder, any variation in the adder delay would
> also affect the dummy gate delay chain in the same way.

couldn't you accomplish the same running everything off an on-chip
oscillator
that also tracks supply and temperature.
And how much does logic speed actually change over temperature and
voltage?

>
> This approach will require some extra gates and hence extra power
> consumption, but on the other hand, the strobe needs to be sent to
> only those units that are required for a specific operation.

gating the clock would do the same, though them clock tree would always

be using power

>
> With multiple units operating in parallel, you would have to perform a
> logical AND operation on the strobe signals arriving through the dummy
> chains of each corresponding unit.
> 
> Paul

-Lasse

On 11 Sep 2006 12:02:52 -0700, "rickman" <gnuarm@gmail.com> wrote:

>A coworker suggested that async parts would be harder to produce to
>work over a wide temperature range. 

If you have e.g. a simple multiple bit adder with ripple carry, there
is a specific number of gate delays between the lowest Carry_in to the
highest Carry_out. Add a similar chain of dummy gates (plus one or two
extra gate delays), send the strobe pulse to this dummy chain at the
same time as the actual values are loaded into the adder, the strobe
pulse will arrive to the other end of the dummy chain, when the adder
output has stabilised and thus, can be latched.

Since the dummy chain is operating at the same temperature and supply
voltage as the actual adder, any variation in the adder delay would
also affect the dummy gate delay chain in the same way.

This approach will require some extra gates and hence extra power
consumption, but on the other hand, the strobe needs to be sent to
only those units that are required for a specific operation. 

With multiple units operating in parallel, you would have to perform a
logical AND operation on the strobe signals arriving through the dummy
chains of each corresponding unit.

Paul
 

A coworker suggested that async parts would be harder to produce to
work over a wide temperature range.  I had commented that the only
parts I could find any reference to were commercial temp.  He
attributed this to the difficulty of making them work correctly over
temperature.  I am assuming it is a market issue.  The applications
that require very low power and don't have demanding real time
requirements are typically commercial, battery operated things like key
fobs and pager displays.  The industrial apps likely have more
stringent real time requirements.

Or maybe it is just a question of risk.  If you are making key fobs, do
you care if 1 in 1000 times you have to hit the button again?  But if
you are making the engine control computer I would expect you don't
want predetonation even once in 1000 spark plug fires.

rickman wrote:
> Jim Granville wrote:
> 
>>rickman wrote:
>>
>>
>>>This is interesting.  I personally don't believe there are significant
>>>advantages to async systems, but I would be willing to consider using
>>>such a chip, especially if it is an ARM chip.  My current applications
>>>require low EMI as well as efficient power usage.  I would be more than
>>>willing to evaluate a real product for my current application where I
>>>am planning to use an ARM7 with a power consumption of 100 - 300 mW at
>>>full speed.  To meet our deisgn goals power managment will need to be
>>>used.  If I can use an async part and meet our power goals with no
>>>added software burden, that would be a significant advantage.
>>>
>>>Wasn't there a real ARM (or other) MCU designed using async clocking?
>>>Anyone remember which company this was? I found the async 8051 from
>>>Philips which might just be useful.  It is not overly fast, but I'm not
>>>sure we really need an ARM CPU in this design.  Unfortunatly it uses
>>>OTP memory which would not work for us.  Obvously designed for the
>>>consumer device market.
>>
>>  If you need low power, and are in the middle ground between vanilla
>>8051 and small ARM, you could look at the C8051F41x series from Silabs ?
>>  These have an on chip 2V regulator, and low and ~200uA/MHz to 50MHz.
> 
> 
> Thanks for the info, but I wanted to explore the low EMI aspects as
> well.  I actually have two apps for an MCU.  One is fairly conventional
> where it does some simple control of hardware.  The other is much
> simpler where it has two slave SPI ports and controls a handful of
> relay drivers.  This app is on an RF board and it would be nice to not
> have *any* clocks running.

  These parts have on-chip Osc, and we've found the C8051F series to be 
low EMI,(but have not tested the F410 yet), I'd expect the lower Vcc and
on chip regulator, to make it even better. mA/MHz is less :)
  If the SPI App is too complex for HCMOS Shift registers,
(or even a HEF4094 is you want it really quiet) you could wake up the uC 
on the SPL_SS and shut the clock right down in other cases.
  Just needs a lead-in time allowance after the SPI_SS to re-start the 
on chip osc.

-jg

Jim Granville wrote:
> rickman wrote:
>
> > This is interesting.  I personally don't believe there are significant
> > advantages to async systems, but I would be willing to consider using
> > such a chip, especially if it is an ARM chip.  My current applications
> > require low EMI as well as efficient power usage.  I would be more than
> > willing to evaluate a real product for my current application where I
> > am planning to use an ARM7 with a power consumption of 100 - 300 mW at
> > full speed.  To meet our deisgn goals power managment will need to be
> > used.  If I can use an async part and meet our power goals with no
> > added software burden, that would be a significant advantage.
> >
> > Wasn't there a real ARM (or other) MCU designed using async clocking?
> > Anyone remember which company this was? I found the async 8051 from
> > Philips which might just be useful.  It is not overly fast, but I'm not
> > sure we really need an ARM CPU in this design.  Unfortunatly it uses
> > OTP memory which would not work for us.  Obvously designed for the
> > consumer device market.
>
>   If you need low power, and are in the middle ground between vanilla
> 8051 and small ARM, you could look at the C8051F41x series from Silabs ?
>   These have an on chip 2V regulator, and low and ~200uA/MHz to 50MHz.

Thanks for the info, but I wanted to explore the low EMI aspects as
well.  I actually have two apps for an MCU.  One is fairly conventional
where it does some simple control of hardware.  The other is much
simpler where it has two slave SPI ports and controls a handful of
relay drivers.  This app is on an RF board and it would be nice to not
have *any* clocks running.