reset: asynchronous vs. synchronous 
Author Message
 reset: asynchronous vs. synchronous

Hi  there!

What are the advantages or disadvantages about using asynchronous or
synchronous resets
in HDL designs ? (synthesis, reuse, tools, libraries, test....)

Does anybody know where i could find related documents ?

Thanks alot in advance,

Kambiz Khalilian
IC Design Engineer
Siemens Semiconductors




Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

> Hi  there!

> What are the advantages or disadvantages about using asynchronous or
> synchronous resets
> in HDL designs ? (synthesis, reuse, tools, libraries, test....)

> Does anybody know where i could find related documents ?

> Thanks alot in advance,

> Kambiz Khalilian
> IC Design Engineer
> Siemens Semiconductors



 In my opinion it makes no sense to talk about (dis-)advantages of
(a-)synchron reset because it depends highly on
Your application which is the right one to use. Imagine p.e. a Situation
where it's necessary to complete the current command before
executing the reset -> synchronous. On the other hand think about a
watchdog resetting a CPU in case of any failure. This would't work
synchronously because You could wait a looooong time until the next
clock....
So look at Your design and then decide which kind of reset is the
required one.

Hope this helps,
Yours Osama Abu-Aish

Intitute for Microelectronics Stuttgart / Germany



Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

>What are the disadvantages about using asynchronous
>resets in HDL designs ? (synthesis, reuse, tools, libraries, test....)

A FEW OF THE MANY DISADVANTAGES
OF STATE ELEMENTS (LATCHES, FLIPFLOPS)
HAVING ASYNCHRONOUS RESET

1. It creates a timing race between the
    reset signal(s) and the clock signal(s).
   Specifically, the de-assertion edge of
   the reset signal, and the capture edge
   of the clock signal.  For a concrete example,
   in the TTL flipflop "74LS74", the race is
   between the rising edge of CLRbar and
   the rising edge of CK.  Some of the state
   elements in your design might be resetted
   during clock cycles 0-1000, and others
   might be resetted during clock cycles 0-1001.
   This would be bad.

2. Automatic test pattern generation ("ATPG")
   software that uses scan-chains, doesn't
   know how to deal with asynchronous
   reset.

3. Some of the transistor-level implementations
    of asynchronous reset, have the possibility
    of creating an unwanted tug-of-war between
    the signal driving the input of the flipflop,
    and the reset transistor inside the flipflop.
    This causes excess power consumption.

--

   "... The world will little note, nor long remember, what is said
    here today..."   -Abraham Lincoln, "The Gettysburg Address"



Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

> What are the advantages or disadvantages about using asynchronous or
> synchronous resets
> in HDL designs ? (synthesis, reuse, tools, libraries, test....)

IF     the clock is not constant during and after the powerup reset pulse
THEN   use asynchronous reset
ELSIF  the clock is constant
       AND there are reset events at times other than powerup
THEN   use synchronous reset
ELSE   use whatever fits best in the target device
END IF;

      -Mike Treseler



Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous
I was wondering if there was a difference in the behavior of the
'EVENT vs. the 'STABLE (without a time) attribute.

I simulated, in ModelSIM, the simple flip flop example below. The GUARD
signal in the block follows the clock in architecture DFF3.  In the DFF1
architecture, the GUARD signal in the block has "spikes" at the positive
edges of the clock:
                    _____       _____       _____
CLOCK          ____|     |_____|     |_____|     |_____
                    _____       _____       _____
DFF3/GUARD     ____|     |_____|     |_____|     |_____

DFF1/GUARD     ____|___________|___________|___________

Is this the right behavior??

Thanks for your help.
Jacob.

library IEEE;
use IEEE.STD_LOGIC_1164.all;

entity DFF is
  port(DATA, CLOCK, CLEAR: in STD_ULOGIC;
       Q, QN: out STD_ULOGIC);
end dff;

architecture DFF1 of DFF is
begin
  B1:block(CLOCK='1' and not CLOCK'STABLE)
  begin
    Q <= guarded '0' when CLEAR='1' else DATA;
    QN <= guarded '1' when CLEAR='1' else not(DATA);
  end block;
end dff1;

architecture DFF3 of DFF is
begin
  B1:block(CLOCK='1' and CLOCK'EVENT)
  begin
    Q <= guarded '0' when CLEAR='1' else DATA;
    QN <= guarded '1' when CLEAR='1' else not(DATA);
  end block;
end dff3;



Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous
If you are using the reset as a "power-on" type reset, or a master
reset for the system, there are no problems with asynchronous im-
plementations.  Note that this requires a dedicated pin on the device
for the reset signal.  This external control ensures that the reset is
not effected by any activity on the device in question.

If, on the other hand, you are using the reset to clear out a flip-flop as
part of normal operation (programmed reset), then the only safe
method is with a synchronous reset.  As stated in another response,
the use of asynchronous resets in this case will introduce race
conditions and cause the design to be incompatible with scan testing.

R. Nuth



Sat, 19 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

> If you are using the reset as a "power-on" type reset, or a master
> reset for the system, there are no problems with asynchronous im-
> plementations.

Although I agree that this is the correct and appropriate use of an FPGA's
asynch reset, what you say is not quite true.  If you can distribute the
reset signal around the device on a clock-driving network then all is well
(thanks for getting that right QuickLogic!); but if you allow the reset
signal to rumble around the device on normal nets, its extremely large
fanout will make its propagation very slow and unpredictable.  So you
risk a deeply unpleasant situation in which, as you remove the reset
signal, some parts of the system see the _next_ clock but other parts
have to wait until the _next clock but one_ before they are rid of the
shackles of reset.  This can cause state machines to get deeply screwed.

Given that high-fanout global distribution networks tend to be a fairly
precious resource on most FPGAs, this is a bit of a problem and needs
watching.

Quote:
> If, on the other hand, you are using the reset to clear out a flip-flop as
> part of normal operation (programmed reset), then the only safe
> method is with a synchronous reset.  As stated in another response,
> the use of asynchronous resets in this case will introduce race
> conditions and cause the design to be incompatible with scan testing.

100% agree.

Jonathan Bromley



Sun, 20 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:


> > If you are using the reset as a "power-on" type reset, or a master
> > reset for the system, there are no problems with asynchronous im-
> > plementations.

> Although I agree that this is the correct and appropriate use of an FPGA's
> asynch reset, what you say is not quite true.  If you can distribute the
> reset signal around the device on a clock-driving network then all is well
> (thanks for getting that right QuickLogic!); but if you allow the reset
> signal to rumble around the device on normal nets, its extremely large
> fanout will make its propagation very slow and unpredictable.  So you
> risk a deeply unpleasant situation in which, as you remove the reset
> signal, some parts of the system see the _next_ clock but other parts
> have to wait until the _next clock but one_ before they are rid of the
> shackles of reset.  This can cause state machines to get deeply screwed.

> Given that high-fanout global distribution networks tend to be a fairly
> precious resource on most FPGAs, this is a bit of a problem and needs
> watching.

I don't know much about FPGAs, but there is no way that you can
guarantee that all parts of the circuit sees the reset on the same
cycle. In my opinion, a circuit should stay in its reset state after
reset is de-asserted until some external input change. This is of
course not possible for all circuits. In that case, start the circuit
with a synchronized, possibly delayed version of the reset signal (run
it through a couple of flip flops, then start a counter to delay the
synchronized reset signal some thousand clock periods if you wish).

Then you can distribute asynchronous power-on reset any way you wish.

--

University of Oslo                             phone: +47 22 85 24 52
Dept. of Informatics, Microelectronics Group     fax: +47 22 85 24 01
Box 1080 Blindern, N-0316 OSLO, NORWAY



Sun, 20 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

>Given that high-fanout global distribution networks tend to be a fairly
>precious resource on most FPGAs, this is a bit of a problem and needs
>watching.

Xilinx has the GSR nets that are used for reset.
--
------------------------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719

"In the beginning, there was darkness.  And it was without form, and void.
And there was also me!"
-- Bomb #20, John Carpenter's "Dark Star"

Quote:
>Jonathan Bromley



Sun, 20 May 2001 03:00:00 GMT  
 reset: asynchronous vs. synchronous

Quote:

> I was wondering if there was a difference in the behavior of the
> 'EVENT vs. the 'STABLE (without a time) attribute.

> I simulated, in ModelSIM, the simple flip flop example below. The GUARD
> signal in the block follows the clock in architecture DFF3.  In the DFF1
> architecture, the GUARD signal in the block has "spikes" at the positive
> edges of the clock:
>                     _____       _____       _____
> CLOCK          ____|     |_____|     |_____|     |_____
>                     _____       _____       _____
> DFF3/GUARD     ____|     |_____|     |_____|     |_____

> DFF1/GUARD     ____|___________|___________|___________

> Is this the right behavior??

> Thanks for your help.
> Jacob.

> library IEEE;
> use IEEE.STD_LOGIC_1164.all;

> entity DFF is
>   port(DATA, CLOCK, CLEAR: in STD_ULOGIC;
>        Q, QN: out STD_ULOGIC);
> end dff;

> architecture DFF1 of DFF is
> begin
>   B1:block(CLOCK='1' and not CLOCK'STABLE)
>   begin
>     Q <= guarded '0' when CLEAR='1' else DATA;
>     QN <= guarded '1' when CLEAR='1' else not(DATA);
>   end block;
> end dff1;

> architecture DFF3 of DFF is
> begin
>   B1:block(CLOCK='1' and CLOCK'EVENT)
>   begin
>     Q <= guarded '0' when CLEAR='1' else DATA;
>     QN <= guarded '1' when CLEAR='1' else not(DATA);
>   end block;
> end dff3;

I think it is the correct behavior.
There is indeed a difference in 'EVENT and 'STABLE (even in the
case that 'STABLE and no explicit time expression).

(see page 187, LRM VHDL 93)
'EVENT is a *FUNCTION* that returns a boolean that indicates if the
       corresponding signal has an event.
'STABLE is an *Implicit SIGNAL* that ..

With this in mind let see what happens with the quarded expression
   CLOCK='1' and not CLOCK'EVENT
Assume that at time t1 there is a rising edge of signal CLOCK. That means
that the implcit signal GUARD ("CLOCK='1' and not CLOCK'EVENT") will be TRUE
since the guarded expression evaluates to TRUE.
Nothing happens until there is a falling edge of the CLOCK. Than the guarded
expression evaluates to FALSE. E.g. this guarded expression has the same
wave as th signal clock.

Now the case in which CLOCK'STABLE is used:
   CLOCK='1' and not CLOCK'STABLE
Assume that at time t1 there is a rising edge of signal CLOCK. That means
that the implcit signal GUARD ("CLOCK='1' and not CLOCK'STABLE") will be TRUE
since the guarded expression evaluates to TRUE.
**NOTICE that the implicit signal "CLOCK'STABLE" is FALSE at that time!**
Than after one delta step .. signal CLOCK is stable again. This means that
signal "CLOCK'STABLE" is changed (an event!) and the guarded expression is
evaluated again and results in FALSE. This explains why the guarded expression
with attribute clock'stable only shows 'spikes'.

Egbert Molenkamp
University of Twente
the Netherlands



Sat, 02 Jun 2001 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. reset: asynchronous vs. synchronous

2. RESET --- Synchronous Vs Asynchronous

3. RESET --- Synchronous Vs Asynchronous

4. Synchronous vs. Asynchronous Reset

5. synchronous reset/set or asynchronous reset/set

6. synchronous reset/set or asynchronous reset/set

7. Synchronous vs Asynchronous RAM on power consumption

8. Asynchronous components in a synchronous design.

9. synchronous v. asynchronous I/O

10. Synchronous over asynchronous VHDL -- any advantages?

11. Asynchronous components in a synchronous design.

12. Difference between synchronous and asynchronous

 

 
Powered by phpBB® Forum Software