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

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

glen herrmannsfeldt

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=&iLang uageID=1&multPartNum=1&sTechX_ID=kc_smart_reset

Prasanth Kumar

"Jason Berringer" <> 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

Hendra

On Wed, 20 Oct 2004 18:41:08 -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
>

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.

mk

"Jason Berringer" <> wrote in message
news:5QBdd.26143$ ...
> 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.

John_H

> From: mk<>
> 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"
> <> 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

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

glen herrmannsfeldt

On Thu, 21 Oct 2004 10:02:02 -0700, Peter Alfke <>
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.

mk

In theory, it's perfectly fine not to reset a bunch of FF's if you can
guarantee that a reset value will ripple through or if you really don't
care about a state. In practise, we tend to reset all our FF's
(synchronously, though it doesn't really make a difference) and then
remove the reset for those FF's for which we can guarantee that it will
get a defined state after we toggle the clock for a few cycles while
reset remains asserted. We prefer not to have any FFs with an unknown
condition when going out of reset. The risk is just to high that we
overlook cases where we DO get into an unknown state. Reset behavior is
one of the cases for which we still run a gatelevel simulation.

As for speed, a case can be made that synchronous reset will eat some
of your setup time because it puts an AND port in between the
functional logic and the D input. But asynchronous FFs can have slower
clock-to-Q times, which may or may not compensate. You'll have to check
your datasheet.

As for area: there's no fixed rule. Some libraries have FF's where the
synchronous reset FFs has the same area as a similar FF without any
reset at all. Again, check you databook.
FPGA is another story alltogether. Check the other answers.

Tom

Tom Verbeure