Async reset

Hello all,

I have a general question regarding asynchronous and synchronous resets.
Does an async. reset slow down the speed of a circuit? Is it better to use a
synchronous reset, or if possible no reset at all to speed up a design? I'm
just curious as I have a larger project which has a single async reset to a
lot of different blocks using the typical:

if (reset = '0') then
...
elsif (rising_edge(clk)) then
...
else
...
end if;

Not all block require the reset since they are downstream of earlier ones
with a reset and their state isn't critical, I have just always included
them. That being said I want to speed up the design, and in one block I took
out the reset and it seemed to boost the performance slightly.

Any comments would be appreciated.

Jason

Jason Berringer wrote:

> I have a general question regarding asynchronous and synchronous resets.
> Does an async. reset slow down the speed of a circuit? Is it better to use a
> synchronous reset, or if possible no reset at all to speed up a design? I'm
> just curious as I have a larger project which has a single async reset to a
> lot of different blocks using the typical:

If the target logic has an asynchronous reset, which I believe
all FPGAs have, then it is already there and all you need to do
is wire it up.

Synchronous reset will be done using logic resources.  It might
be that there are enough CLB inputs not to add more, though it
might need another column, depending on the function.

A separate question is that asynchronous reset needs not to be
too close to the clock edge, so it might need to be synchronized
(even though not synchronous).

-- glen

On Wed, 2004-10-20 at 18:41 -0400, Jason Berringer wrote:
> Hello all,
> 
> I have a general question regarding asynchronous and synchronous resets.
> Does an async. reset slow down the speed of a circuit? Is it better to use a
> synchronous reset, or if possible no reset at all to speed up a design? I'm
> just curious as I have a larger project which has a single async reset to a
> lot of different blocks using the typical:
> 
> if (reset = '0') then
> ...
> elsif (rising_edge(clk)) then
> ...
> else
> ...
> end if;
> 
> Not all block require the reset since they are downstream of earlier ones
> with a reset and their state isn't critical, I have just always included
> them. That being said I want to speed up the design, and in one block I took
> out the reset and it seemed to boost the performance slightly.
> 
> Any comments would be appreciated.
> 
> Jason
> 
> 

If you are using Xilinx FPGAs then they have a nice techxclusives
article about just this. 

http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?
sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=kc_smart_reset

"Jason Berringer" <jberringer@sympatico.ca> wrote 
> Does an async. reset slow down the speed of a circuit? 

I guess synchronous reset need extra logic, so it may speed up a
little if you use asynchronous reset.

> Is it better to use a
> synchronous reset, or if possible no reset at all to speed up a design? 

Yes, it is possible to have no reset at all in an FPGA since FPGA will
automatically clear all FFs inside the chip during downloading from
the bitstream. However, not having the reset will make it harder to
simulate since some simulators require all the FFs to be resetted
before you can do any simulation. Moreover, what would happen when for
some reason your FFs go to undesired state, then you can not get out
of the loop!

There are some articles regarding sync vs async at
http://www.sunburst-design.com/papers/

Hendra

On Wed, 20 Oct 2004 18:41:08 -0400, "Jason Berringer"
<jberringer@sympatico.ca> wrote:

>Hello all,
>
>I have a general question regarding asynchronous and synchronous resets.
>Does an async. reset slow down the speed of a circuit? Is it better to use a
>synchronous reset, or if possible no reset at all to speed up a design? I'm
>just curious as I have a larger project which has a single async reset to a
>lot of different blocks using the typical:
>
>if (reset = '0') then
>...
>elsif (rising_edge(clk)) then
>...
>else
>...
>end if;
>
>Not all block require the reset since they are downstream of earlier ones
>with a reset and their state isn't critical, I have just always included
>them. That being said I want to speed up the design, and in one block I took
>out the reset and it seemed to boost the performance slightly.
>
>Any comments would be appreciated.
>
>Jason
>

For standard cell based designs, flops without async resets are almost
always faster than the ones which do (and they are smaller as an added
bonus), so if you don't need them don't use them. For FPGAs, when
programmed not have an async reset a flop might have a different clk
to Q delay (or a faster setup) which would make the design faster. One
method would be to use async resets only for the registers which you
know would need them and then add the ones later if you have to.
Of course you should never let an async reset reach a flop without
being synchronized to its clock, at least the release of the reset
signal. Not doing so would cause unmentionable heart-ache in a
real-life design.

"Jason Berringer" <jberringer@sympatico.ca> wrote in message
news:5QBdd.26143$J16.1307307@news20.bellglobal.com...
> Any comments would be appreciated.

I'd like to point out that async resets aren't free in all FPGAs.
I've been producing reset-free designs for years in the Xilinx parts having
started with reset-free designs in Altera.

The FPGAs have power-up states that are or can be predefined to specific
values.  The S/R pins can be used as *either* sync or async but cannot be
used as both.  There are no resources needed for a synchronous reset above
and beyond what an asynchronous reset uses in those devices.  What about
when the system goes haywaire and the device needs to be reset?  If the
system is in need of serious reset, just reprogram the part.

Some logic can be sped up by using the integrated synchronous S/R
functionality as long as your synthesizer knows how to use it.  Synplify
does a great job of adding additional logic through the S/R ports often
providing a slightly shorter path in timing sensitive designs.  The one
negative from this practice is that the S/R logic integration tends to be
more widespread than I would like, typically locking out the adjacent
register in a slice from use; both registers need the same S/R, clk, and CE
signals.

How does more logic get in through a set/reset?  The FDR primitive can be
used as an OR gate (Q = D & !R where the inversion is free) and an FDS can
be used as an OR gate (Q = D | S) with the FDRS providing a little more
functionality.  Throw the clock enable in there and things get more flexible
but keep in mind (as the synthesis does) that the reset is higher precedence
than the set which is higher than the clock enable.  This "logic
integration" into the register has saved my designs with respect to I/O
timing by allowing live signals to feed the CE, and S/R directly from other
I/Os allowing a very short setup plus output time for the same clock edge.
Without this functionality, getting on and off the logic fabric without
global routing killed my timing.

> From: mk<kal@delete.dspia.com>
> Organization: SBC http://yahoo.sbc.com
> Newsgroups: comp.arch.fpga,comp.lang.vhdl
> Date: Thu, 21 Oct 2004 05:20:35 GMT
> Subject: Re: Async reset
> 
> On Wed, 20 Oct 2004 18:41:08 -0400, "Jason Berringer"
> <jberringer@sympatico.ca> wrote:
> 
>>  For FPGAs, when
> programmed not have an async reset a flop might have a different clk
> to Q delay (or a faster setup) which would make the design faster.
I disagree.
In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
slices) are the same. They all have a Reset input, whether you use it or
not, and the clock-to-Q delay is unaffected by the way the user configures
the design and uses or not uses asynchronous or synchronous Reset or Clear.
 
Regarding the basic need for reset, Ken Chapman published an interesting
(and perhaps provocative) article 3 years ago ( Oct 2001, but it is still on
the Xilinx website under TechXclusives), and here is his conclusion:

"Summary
"A design implemented in a Xilinx FPGA does not require you to insert a
global reset network. For the vast majority of any design, the
initialisation state of all flip-flops and RAM following configuration is
more comprehensive than any logical reset will ever be. There is no
requirement to insert a reset for simulation because nothing will be
undefined. Since a Xilinx FPGA is already fully tested silicon, you won't be
inserting scan logic in your design and running test vectors, so you will
not need a global reset as part of this process either.

 "Inserting a global reset will impact your development time and final
product costs even if these factors can not be easily quantified. With the
trend towards higher speed clocks and complete systems on a chip, the
reliability issues must be taken seriously. The critical parts of a system
that must truly be reset should be identified and the release of those
resets on start up, or during operation, must be controlled as carefully as
any other signal within a synchronous circuit.

 As you are creating each section of your next design, simply ask yourself:
"Does this bit need to be reset"?
from the TechXlusives paper by Ken Chapman, Xilinx

Peter Alfke

 

Hendra wrote:

(snip)

> Yes, it is possible to have no reset at all in an FPGA since FPGA will
> automatically clear all FFs inside the chip during downloading from
> the bitstream. However, not having the reset will make it harder to
> simulate since some simulators require all the FFs to be resetted
> before you can do any simulation. Moreover, what would happen when for
> some reason your FFs go to undesired state, then you can not get out
> of the loop!

I don't believe they are guaranteed to be cleared, as far as user
logic is concerned.  The synthesis often moves inverters around,
and many signals, including ones through FF's, are actually the
inverse of the expected signal.  I have seen warning messages from
Quartus for FF's that don't have a reset or preset input that the
initial state is not guaranteed.

> There are some articles regarding sync vs async at
> http://www.sunburst-design.com/papers/

-- glen

On Thu, 21 Oct 2004 10:02:02 -0700, Peter Alfke <peter@xilinx.com>
wrote:
>> 
>>>  For FPGAs, when
>> programmed not have an async reset a flop might have a different clk
>> to Q delay (or a faster setup) which would make the design faster.
>I disagree.
>In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or
>slices) are the same. They all have a Reset input, whether you use it or
>not, and the clock-to-Q delay is unaffected by the way the user configures
>the design and uses or not uses asynchronous or synchronous Reset or Clear.

There is nothing to disagree about. I was just trying to suggest an
explanation for the observed behavior. You being from xilinx, I'll
take your statement over my speculation about a xilinx design.

Also there is one case where one can't really depend on an FPGA to do
all the resetting for you and that's when you're prototyping an ASIC.
That's my main focus right now.

Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other
synchronous elements, too, like BlockRAM output registers,
IOB flops, etc...) are initialized to a known state at
the end of configuration by an internal, chip-wide async
reset called GSR, or "global set/reset".  It also happens
to be the case that there's another signal, GTS, or "global
three-state" that forces all I/O to be three-stated during
configuration.  These signals are not "visible" in the FPGA
Editor view of the part at any place other than the STARTUP
component.

If you instantiate specific primitives, like FDC or FDP,
you are also making a request on how you want these to be
initialized by GSR (regardless of your use of an additional,
async user reset).  FDC initializes to 0.  FDP initializes
to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init)
begin
  if (init) myflop <= 2'b10;
  else myflop <= two_bit_whatever;
end

You have just inferred an FDC and and FDP, both of which are
initialized by GSR at configuration, and both of which also
have an asynchronous user control called "init".

For a more detailed look, try implementing the code above,
and then make a back-annotated netlist using netgen and you
will see that the simulation model has the init signal
logically OR'ed with a signal called GSR, located in the
glbl.v file that you are supposed to use during simulation
of back-annotated designs.

If you code stuff like:

reg [1:0] myotherflop;

always @(posedge clk) myotherflop <= two_bit_whatever;

You have just inferred two generic D flip flops, probably
FD components, and even though you don't have an asynchronous
user control on this, it will get initialized once at the
end of configuration, by the GSR signal.  I believe FD will
default to 0, unless you specify otherwise.

If you repeat the exercise using netgen, you will see that
GSR is still used as an async reset, but there's no other
signal OR'ed with it.

> The synthesis often moves inverters around, and many signals,
> including ones through FF's, are actually the inverse of the
> expected signal.

I would hope anyone doing this transformation would also change
the "initialization state" of the flip flop when they also change
it's sense -- otherwise the transformation is not really
transparent... (I would argue it's wrong)

Eric