( ESNUG 409 Item 11 ) ------------------------------------------- [03/25/03]
Subject: ( ESNUG 396 #1 ) A Boatload Of Letters On Sync vs. Async Resets
> We are starting a new ASIC design and had new member coming from another
> group. When discussing methodology, our new collegue suggested using a
> synchronous reset flip-flop over asynchrous flip-flop which was a shock
> to us. Our past design guideline has been using async reset flops only
> (because all ASIC vendors we know about only have async reset flops in
> their libraries, so if you choose to code a sync reset flop Design
> Compiler will try to build some logic in front of your D pin.)
>
> Do your readers have any suggestions on this?
>
> - Jerry Yang
> Nortel Networks Nepean, Ontario, Canada
From: Pieter Hulshoff <school=lucent brought sawn fish=hulshoff>
Hello John,
Everything you always wanted to know about resets, but never dared to ask
can be found at:
http://www.xilinx.com/support/techxclusives/global-techX19.htm
We use synchronous resets only. Our ASIC vendors do not have any problems
in accommodating us in this.
- Pieter Hulshoff
Lucent Technologies Huizen, The Netherlands
---- ---- ---- ---- ---- ---- ----
From: Dave Smith <army=st lot prom soldier=dave.smith>
John,
I think that there are valid arguments to support both views on resets.
Personally, I prefer asynchronous resets because:
- The design will go into a defined state immediately on the assertion
of reset, without requiring a clock. This can be useful in multi-clock
designs.
- Designs which contain flip-flop based clock dividers are easier to
handle - if you have synchronous reset, then you cannot reset the
dividing flops and the flops which are clocked from the divided clock
at the same time, since the clock will not propagate while the divider
is held in reset. The alternative (not resetting the clock divider)
is a DFT issue, since the phase relationship of the output waveform
is undefined, and therefore the expected data could arrive in one of
many clock cycles. If reset is asynchronous, all the FFs can be reset
at the same time in complete safety.
- As mentioned, if the ASIC library does not have special sync reset
FFs, the synthesis tool will add logic in front of the D pin. This
can cause problems if you wish to use a separate tool to generate
your reset buffer tree
Off the top of my head, I can think of three reasons *for* synchronous
reset:
- A design using synchronous reset should be able to synthesise into
any cell library. Designs using asynchronous reset require
asynchronous-reset FFs.
- Any logic feeding an asynchronous reset signal needs to be
glitch-free, whereas synchronous reset can tolerate glitches.
- Care needs to be taken when using asynchronous reset, to avoid DFT
problems - in particular, if you allow FFs to generate or
resynchronise the reset signal, you must make sure that they do not
block scan chains.
It's never black or white, just shades of grey here.
- David Smith
STMicroelectronics Bristol, UK
---- ---- ---- ---- ---- ---- ----
From Brian Logsdon <his_company=philips pot hon his_name=brian.logsdon>
John,
I can see only one real reason for using a synchronous reset. If you have
a system in which the behavior must be controlled (or provide specific
responses) as it transitions into the "reset state", then you must use
synchronous resets. If the application of reset is to be indicative of
a power-on or remedy for a catastrophic failure, then there is really no
need for the additional logic that synchronous reset logic implies.
There maybe some argument for synchronous resets for software initiated
reset events. But I think it would be a weak one.
I consider it more likely that this is just a crutch for those designers
that don't want to consider system level issues.
Believe it or not, I'm seeing logic written with BOTH styles.
- Brian Logsdon
Philips Semiconductors
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <movie=agere wrought brawn actor=derti>
Hi, John,
For a while now, and at various companies, we always use asynch reset flops,
but with a caveat that we synchronize the "release" of the reset state.
In our clock/reset block usually at the top of the design, we create a
little circuit out of a flip-flop and an AND gate.
We tie the D-pin of the flop to high (Vdd, or "1") Reset feeds the RST-pin
(read also CLEAR) of the flop (clocked by the clock that is going to the
network which is being reset) Q of the flop goes to one pin of the AND
gate, and the reset signal itself goes to the other pin:
_________
| | ____
tied hi to VDD "1" -------| D Q |---------| \
| | | AND |----- Chip_Reset
Reset -------| RST | -----|____/
| |_________| |
| |
--------------------
Now when system reset goes low, the AND gate pulls the chip reset low
immediatedly. We let the vendor use clock-tree insertion to lay out the
reset lines just like clock lines. When reset goes high, the flop continues
to hold the reset low until after the next clock edge -- thus doing what we
can to eliminate the timing issues between clock and reset.
On some designs, we've even used the falling edge of clock to drive the
"reset" flop. It all depends on fixing reset setup or hold to clock.
I know that some will argue the other way, but for alot of systems, I like
to know where the flops start out, even if the clocks are off, and async
resets with the above circuit give me what I want.
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Jerry Yang <jail=nortelnetworks shot psalm prisoner=yangj>
To: Gzim Derti <movie=agere wrought brawn actor=derti>
Gzim,
What you have described in your email is almost the same as what we have
been doing before, e.g. assert reset asynchronously but deassert reset
synchronously. However, there are two issues with the async
implementaion as described in your email:
1. how do you test the reset path?
2. reset input to the chip has to be "clean", i.e. no glitches.
But even so, I still prefer async reset just like you.
- Jerry Yang
Nortel Networks Nepean, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <movie=agere wrought brawn actor=derti>
To: Jerry Yang <jail=nortelnetworks shot psalm prisoner=yangj>
Jerry,
When you say "test the reset path" do you mean to make sure that it
functionally works, the timing of the path, or Scan testing??
For the functional part, well, functional sims.
For timing static timing usually takes it, like I said, we treated resets
as clocks so post route is the only way.
Now for ATPG/Scan testing: there you've got me. That's one flop that I
don't think can be in the path.
And yes, I'm always assuming a clean, i.e. glitchless input. Don't know a
way around that one...
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Eric Stine <mountainrange=ti tot con mountain=e-stine2>
Hi, John,
I have never been a big fan of asynchronous resets. Since the async reset
directly controls the flop output it is equivalent to adding a second clock
domain to your design. As such it adds all the extra complexities and
problems of a second clock.
Second, it is a problem for full scan since all clocks and async resets must
be directly controllable during scan mode and in my experience it tends to
reduce scan coverage.
Third, DC by default does not check async reset timings.
Forth, the reset better not have any glitches since that could leave the
flop in an unknown state as you might violate minimum pulse width timings.
Having said all that the biggest reason IMHO for not using async resets
is the more green your team the more likely they are to misuse async resets
and have the problems mentioned above. In almost every project I have been
involved with there is a new guy coding RTL. If I just tell him he can't
use async resets then all these possible problems go away.
- Eric Stine
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: Manish Shrivastava <bowl=ieee.org goldfish=manish>
Hi John,
Synchronous and Asynchronous reset should depend on what you are looking at.
There is a timing constraint on the rising edge of the reset ( assuming an
active low reset) which can create one cycle uncertainity in the data being
latched in by the FF. So for example if the start of a state machine depends
on when the input FF gets the data and it doenst matter if it starts one
cycle early or late, there is no problem in using Asynchronous Reset.
But if you have a high speed interface with say 6 bits of data being latched
by the FF's and reset release happens very close to the clock edge then you
have a serious problem that some Flops can get the data and some won't.
So it is really dependend on what your design does on what kind of reset you
should have. The safe methodology from my point of view is to use Asynch
resets as long as the clock starts after the reset has been released. Or to
synchronize the Reset with the clock and make sure that the reset network
delay including the CLK->Q delay of the synchronizing flop is less then the
clock period - the worst removal timing of the FF's on the network.
If you use a synchronous reset as an enable, it is a little tricky. You
can't initialize the system without the clock. On the other hand if
you synchronize the reset with clock and use it as the ASYNC Reset input
of the functional FF's, you can safely reset the synchronizing FF with the
same Reset, as what we are worried about is the rising edge of the reset
(active low) and not the falling edge in terms of race conditions.
- Manish Shrivastava
IEEE
---- ---- ---- ---- ---- ---- ----
From: [ Liberte, Egalite, Fraternite ]
Hi John, please have me anon.
I am a SoC project leader in a French company (sorry for my poor English).
Our design rule is to use async reset inputs of DFF. We think it uses less
area. But we reshape the reset input to drive these async inputs properly:
the reset signal of each DFF is asynchronously asserted when the external
reset source gets active. It is deasserted when the external reset source
gets back inactive on the inactive edge of the clock which drives the DFF.
This prevents conflicts between reset & clock when the reset is de-asserted.
In full scan, the reset circuitry is bypassed and the external reset
directly drives the internal reset signals.
This implies to associate two reset clock signals (one for each edge,
sometimes only one is used) with each clock. If a reset signal has a big
load, we prefer to insert a clock tree to drive it.
One point with that internal reset signals are not simultaneously
deasserted, which can be critical when using internal slow clocks with other
internal fast clocks. The slow clock domain is still under reset while the
fast clock domain is already working. It is often easily solved from a
functional point of view.
When required, we use these internal reset signals for the SW reset
functions. In this case, the reset signal is asserted and deasserted on the
inactive edge of the clock it is associated with. It can sound like bad
design practice, but it works and saves area.
- [ Liberte, Egalite, Fraternite ]
---- ---- ---- ---- ---- ---- ----
From: Ujjwal Konar <nightclub=noida.atrenta plot pawn dancer=ujjwalk>
Hi, John,
An asynchronous reset can cause problems for your DFT tools. If you use
asynchronous reset, ensure that there is only one asynchronous reset signal,
driven from the top-level of the design. Further, consider adding logic so
that assertion of the reset is asynchronous but de-assertion is synchronous
with the clock. This will avoid problems that might be caused if reset is
released too close to the active edge of the clock.
- Ujjwal Konar
Atrenta EDA India
---- ---- ---- ---- ---- ---- ----
From: Rick Vreeland <pictureframe=quadic fraught mom picture=rick>
John,
My preference is to combine the best of both and have asynchronous resets
with synchronous deassertion of reset. It seems beneficial that when a
board is powered up and a reset yanked, the chips go immediately to their
reset state, independent of whether all the clocks are running, particularly
if the resets are controlling flops which control the drive of the I/O
buffers in the pads. However, it is equally important to know that resets
are being removed synchronous to the clocks, to avoid timing problems
associated with the removal/recovery constraints on the async reset pins of
the flops (the equivalent of setup/hold constraints on data pins.)
The Verilog RTL looks roughly as follows:
input nreset; // Active low RAW reset from pad
input scanmode; // Active high signal indicating in scan
input clk; // Clock related to flops being reset
output sync_nreset; // Active low reset to flops
reg meta_nreset;
reg sync_nreset;
wire gated_nreset = nreset | scanmode; // Disable reset in scan
always @ (posedge clk or negedge gated_nreset)
if (!gated_nreset)
begin
meta_nreset <= 1'b0;
sync_nreset <= 1'b0;
end
else
begin
meta_nreset <= nreset;
sync_nreset <= meta_nreset;
end
This uses the equivalent of a standard 2-flop synchronizer circuit. The
flops are asynchronously reset by gated_nreset, which is your chip reset
gated with your scan mode enable (if you have scan), so that the flops are
controllable during scan. Note that the D input of the first flop
(meta_nreset) is fed directly by the un-gated reset. This allows the D
input of that flop to be controlled during scan to improve the test
coverage. The output of the circuit (scan_nreset) is what is used to reset
the flops on that clock domain. It goes into reset asynchronously, but
exits synchronously, so the timing to the reset pins of the flops now
have a "normal" full-cycle time. This is then very clean during synthesis
or static timing.
A separate reset synchronizer should be used for each different clock domain
and a separate one for POS vs NEG edge triggered flops on the same domains.
Otherwise the NEG edge triggered flops will have only 1/2 a cycle to come
out of reset and, if your clock period is short, this can show up as removal
or recovery violations.
One more tip - during back-annotated simulation (in Verilog anyways) use the
$disable_warnings system task to suppress timing violation warnings when
"nreset" is brought low to reset the chip. Any such warnings related to
removal or recovery are meaningless, since all elements are going into a
forced reset state. Then, re-enable the warnings with $enable_warnings
before releasing the "nreset". That way you will see any violations
associated with the synchronous removal of the reset.
This methodology has worked very well for me through many chips.
- Rick Vreeland
Quadic Systems South Portland, Maine
---- ---- ---- ---- ---- ---- ----
From: [ Ich Bin Ein Berliner ]
John,
I would consider this:
1) Can you make sure, that under all (ALL!!!) circumstances your design
has a functioning clock ALWAYS available, because *without* clock you
will definitely not be able to reset your design! Can you make sure
that the clock will still run while anything else around it might fail?
2) Never ever use gated signals for an async reset. The async reset
should be reserved for THE ONE Asic pin "reset" (or "reset_n"). Not
only does this help the test-people at the hardware foundry, it also
helps during startup/debug measurements of the ASIC in the completed
system. Only then you can definitely force the chip into a defined
state, by applying just one signal. Often there are dependencies on
the reset state that may cause a system deadlock.
I must be anon.
- [ Ich Bin Ein Berliner ]
---- ---- ---- ---- ---- ---- ----
From: John Weiland <library=intrinsix aught non book=jweiland>
Hi, John,
James Buchanon's books on systems design cover topics like this pretty well
(Jim - we'll discuss my cut later). I'll paraphrase and expound. A reset
should put a system into a guaranteed safe state, i.e. no bus contention, no
spurious writes to nonvolatile memory, etc. The question is, are you
absolutely, positively sure that the clock will ALWAYS be running whenever
the reset is active, both at power-up and during any later resets? Usually
the answer will be "I'm pretty sure but not absolutely positive". In that
case, you should definitely use an asynchronous reset. Note that resets
should always be SYNCHRONOUSLY released (but asynchronously asserted). This
is required to ensure that some flops are not released one clock before
others, which could have disastrous results. Designers usually add a small
amount of logic on-chip to ensure that they know exactly when within the
clock cycle the reset will be released. They sometimes also add circuitry
to ensure that the reset is at least X clocks long, depending on the
particulars of the design.
- John Weiland
Intrinsix Corp.
---- ---- ---- ---- ---- ---- ----
From: Matt Weber <bowl=siliconlogic thought sawn cherry=matt>
Hi John,
I have always used synchronous resets in my designs. However, this is
primarily because all of my designs so far have gone through IBM ASICs
where asynchronous resets are "tolerated, but not recommended." Using
async resets in IBM ASICs requires some special handling during netlist
processing and test insertion, and requires extra control and constraints
for static timing analysis. The last time I checked, the app note which
described this special handling was over 50 pages long. I can take you
through the gory details if you like.
Even for other ASIC vendors, synchronous resets still have some advantages.
Cliff Cummings and Don Mills presented a paper at SNUG'02 about this exact
issue. (John probably has a copy of it on DeepChip.com downloads by now.)
The disadvantage, of course, is that you may get one extra gate in front of
the D pin of your flop. However, synthesis is generally able to get this
out of the critical timing path, and I have never failed to meet timing
objectives because of the choice to use synchronous resets.
Obviously, other ASIC vendors are more tolerant of asynchronous resets. I
would still suggest that you make sure that the de-assertion of reset is
synchronous, otherwise you run the risk of portions of your logic coming out
of reset at different times or with some metastability. Cliff and Don's
SNUG paper talks about this as well.
- Matt Weber
Silicon Logic Engineering, Inc. Eau Claire, WI
[ Editor's Note: Cliff's Reset paper is #41 of DeepChip Downloads - John ]
---- ---- ---- ---- ---- ---- ----
From: Lee Tatistcheff <group=cadence rot balm individual=leet>
Hi John,
One reason not to use asynchronous resets is that Verilog cannot model
them without a race condition. Typical async reset flop:
always @ (posedge ck or negedge rst) begin
if (!rst) q <= 0;
else q <= d;
end
What happens when rst is DEasserted at the same time as ck is asserted?
Either ck goes high first, and rst is still low, so q gets zero. Or rst
goes high first, and when ck fires, q gets d.
Uh-oh. Do you get your new d or not?
- Lee Tatistcheff
Cadence Design Systems Chelmsford, MA
---- ---- ---- ---- ---- ---- ----
> A technique we have been using is asynchronous activation of reset and
> synchronous release.
>
> |-----| |-----|
> clock ---|> | clock --|> |
> | | | |
> reset ---|D Q|-----------|D Q|---reset-out
> | |--O--| |--O--|
> |____|_________________|
>
> The two flip-flops are for metastability control. Reset causes reset-out
> to go active, but reset-out will not release until after two clock edges.
> This gives a full clock period for all downstream logic to respond to
> reset since reset-out always goes inactive on a rising clock edge
> (assuming you are not using lots of negative logic.)
>
> - [ Chicken Man ]
From: Chris Byham <forrest=philips pot gone tree=chris.byham>
Hi John,
I use a slightly different version of the circuit provided by Chicken Man.
Rather than using circuit he provided, I would add an extra flop and OR
the Q from the second and third flops. This gives some protection from
noise (i.e. all the flops in the little circuit need to see a valid reset
to put the internal reset on.) If staggered resets are needed (for
power-up sequence, etc.), simple add more flops to the chain and OR the Q
of the nth with the (n-1)th. Heck, add a scantestmode disable to the ORs
and you can scan these reset-sync flops!!! No worries then about 100%
test coverage!!!
For layout, you will need to group the flops together. Also ensure that
the same clock is received by each flop (i.e. same branch of tree.)
I've used this technique on several devices both here at Philips and at
previous employers.
- Chris Byham
Philips Semiconductors
---- ---- ---- ---- ---- ---- ----
From: Cliff Cummings <company=sunburst-design shot don worker=cliffc>
Hi, John,
Don Mills and I did a simple little resets paper for San Jose SNUG'02 last
year that included all types of pros and cons related to synchronous
resets, asynchronous resets and multi-clock reset issues. I asked Don if
we could do the simple little paper so that I could reference it in my FIFO
papers, also given at SNUG'02. We gathered all types of ESNUG postings,
SolvNet articles and great input from guys like Chris Kiegle of IBM and
Steve Golson of ESNUG-fame (er, I mean Trilobyte Systems) to write a simple
little 31-PAGE resets paper.
One technique not described in the paper but that was shared with us by
Steve Golson was to put a synchronous reset-controlling flip-flop in every
major module of the design to avoid issues related to reset distribution
trees that are discussed in the paper. Maybe we can coax Steve into
sharing more info on this interesting technique for your ESNUG viewers?
;-) Steve? :-0
It's amazing how a simple little reset can be such a methodology topic!
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
[ Editor's Note: Cliff's Reset paper is #41 of DeepChip Downloads - John ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 16,627 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
