Asynchronous ARM

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
 

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

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

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

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

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