Async reset

[Jason Berringer]

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

 

[glen herrmannsfeldt]

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

 

[Prasanth Kumar]

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

 

[m]

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.

 

[m]

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.

 

[Ray Andraka]

This is not entirely true. Xilinx Virtex and later families can have the
flip-flops with either synchronous or asynchronous (re)sets, but not both unless
you use the LUT for the sync reset. The wiring to the built in reset pins on the
flip-flop can be connected to the global reset net. The flip-flops come up in a
known state at the end of configuration.

Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use
an async reset in the FPGA. The issue is that the release of reset is
asynchronous to the clock, so you will get a situation where some flip-flops see
the release on one clock cycle where others see the release on the next cycle when
the reset is released close to the clock edge. The other issue is that an async
reset propagates through the flip-flop making a timing path that does not end at
the flip-flop. The timing tools historically have missed this timing path
(thinking back to the 4000 series tools), so there is a possibly hidden danger to
using async resets as well.

As far as resetting every flip flop in the design: it is not necessary. As long
as you break every synchronous feedback look in the design when you apply reset,
you can get your design to a known state in a known number of clocks. I described
this technique here within the past two weeks.

glen herrmannsfeldt wrote:

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

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[glen herrmannsfeldt]

Ray Andraka wrote:

This is not entirely true. Xilinx Virtex and later families can have the
flip-flops with either synchronous or asynchronous (re)sets, but not both unless
you use the LUT for the sync reset. The wiring to the built in reset pins on the
flip-flop can be connected to the global reset net. The flip-flops come up in a
known state at the end of configuration.

My current project is with Altera ACEX, so I now looked up more exactly
what it does.

It seems that they provide asynchronous CLEAR and LOAD. If you specify
only CLEAR (RESET) it is fine. If you specify only PRESET it will
invert the logic and use CLEAR. If you use both, it needs one LUT
input (DATA3) to be used for that function. So, it is a little
more efficient to invert the logic if preset is used, and in that
case the global reset will act as a preset.

If neither is used, Quartus seems to be free to do it either
way, and gives a warning to tell you that.

I don't see that ACEX supplies a synchronous preset or clear,
so I believe that would be done through LUT logic.

It would seem that one should know the details for the logic
family being used.

-- glen

 

[John_H]

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

 

[Peter Alfke]

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

 

[glen herrmannsfeldt]

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

 

[Jason Berringer]

Thanks to all who have posted here, I have read all of the helpful
information pointed out on the Xilinx site. Very interesting, and has made
me rethink my coding style significantly with regards to the reset signal.

Jason

 

[Hendra]

"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

 

[Tom Verbeure]

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

 

[rickman]

Ray Andraka wrote:

This is not entirely true. Xilinx Virtex and later families can have the
flip-flops with either synchronous or asynchronous (re)sets, but not both unless
you use the LUT for the sync reset. The wiring to the built in reset pins on the
flip-flop can be connected to the global reset net. The flip-flops come up in a
known state at the end of configuration.

Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use
an async reset in the FPGA. The issue is that the release of reset is
asynchronous to the clock, so you will get a situation where some flip-flops see
the release on one clock cycle where others see the release on the next cycle when
the reset is released close to the clock edge. The other issue is that an async
reset propagates through the flip-flop making a timing path that does not end at
the flip-flop. The timing tools historically have missed this timing path
(thinking back to the 4000 series tools), so there is a possibly hidden danger to
using async resets as well.

I think advising against using an async reset is a bit strong. With
attention to the issue, an async reset will work just fine. You just
can't assume that all FFs will be released on the same clock edge.

As to the timing issue, that timing condition applies to the assertion
of the reset. If you are using the async input to reset the entire
chip, I don't think the propagation time is an issue.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Subroto Datta]

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:cl8qle$uk8$1@gnus01.u.washington.edu...

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


Quartus synthesis will take advantage of registers which do not specify a

power-up condition in don't care optimizations. Note that this can often
result in registers being synthesized away because they are stuck-at in one
power-up state, so it is important for designers to read the messages as
warnings, not info. The assignment editor allows one to protect a register
from this optimization, or specifically give a power-up value to a register
or set of registers.

Hope this helps.

- Subroto Datta
Altera Corp.