( ESNUG 396 Item 1 ) --------------------------------------------- [07/11/02]
Subject: ( ESNUG 393 #1 ) Synchronous vs. Asynchronous Resets In Designs
> 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 the
> Synthesis tool 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: Marco Winzker <MWinzker@Liesegang-electronics.com>
Dear John,
You definitely need an asynchronous reset and not a synchronous reset. Two
arguments:
- An asynchronous reset will always be synthesized to a
FF-cell with a reset, while a synchronous reset might be pulled
into a complex combinational cell. Then, in gate-level simulation
this combinational cell has the reset input which is '1' and
maybe two or three undefined signals. Depending on how the
library-guys implemented the library, the simulator might set the
output of the cell to undefined (as it has undefined inputs).
- If you have a synchronous reset, you must make sure, that
during reset you have a clock. This might sound trivial, but
imagine the clock comes from an AD-converter or video
decoder which outputs no clock, when it does not detect
a proper input signal.
Regards,
- Marco Winzker
Liesegang electronics GmbH Germany
---- ---- ---- ---- ---- ---- ----
From: [ Chicken Man ]
Hi, John,
This must be anonymous!
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). This can prevent reset skew from allowing
different flip-flops to see reset in different clock periods (e.g. two flops
in a state machine seeing reset release just before and just after the clock
edge due to skew in the reset net). An extension to this is to cascade
reset-out from one section of the circuit to another to control start up
sequencing (e.g. different clock domains).
This has been implemented on multiple ASICs using a Synopsys flow.
In response to Jerry Yang's concern this puts the logic in the reset circuit
and leaves the logic on the D input untouched.
- [ Chicken Man ]
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jlk@brecis.com>
Hi John,
Regarding Jerry Yang's question about the set/resets in a design being
synchronous or asynchronous with respect to the clock, there seem to be two
schools of thought in making a choice and obviously they do not preach the
same methodology. I am not sure if one is better over the other because I
know SOC designs that have been done in both ways are currently working
first-silicon. As I am a backend engineer, I prefer the resets being
async, because my library does not have sync reset flops and therefore I do
not like more logic in my datapath eating up timing and I also do not like
the reset pins being wasted (tied high or low to deactivate it). But there
are libraries that have sync reset flops and one of Artisan's datasheets
talks about a sync reset flop. And now,thanking the RTL people who helped
me with their suggestions, here are the thoughts.
1. All set/resets should be Asynchronous.
Reasons: Typically in a CPU design, the clock is stable when reset
comes in and so synchronous reset is used, but in system design
(chipset/networking) the clock (internal) takes quite a while to
stablize and may be unpredictable due to different clock domains
in the same design. So it is safer to use asynchronus reset. Or
else some clocks might not be stable when reset goes away causing
some flops to propagate unknowns instead of reset values.
2. All set/resets should be Synchronous.
Reasons: Async controls on Registers create paths that the designer
is unaware of. Many async designs CAN NOT be proven to work with
timing analysis tools and/or simulation. Synchronous designs are
easy to analyze for timing, and therefore easy to determine that they
will work. By definition using an async input to a register creates
an asynchronous design which makes the problem of timing analysis much
more difficult. In a system with multiple clocks with different
stabilization times, each clock domain should reset synchronously
within its time domain.
In the best of all worlds, the external reset would be sent to a central
system reset block and then distributed to the individual blocks so that the
system reset sequence could be controlled. The reset state of each block
(in the time domain of that block) could go back to the central system
reset block (where it would be synchronized to its time domain) to complete
the reset sequence control loop. The reset of a system should be designed
instead of being a result of the way the individual blocks happen to reset
themselves. This can be difficult to do if a block resets asynchronously.
When each block resets asynchronously, the system reset sequence may be
constrained by one or more of the lower level blocks. The typical result is
to add extra time for reset to be asserted. This is particularly true for
controlling X propagation, which is not only a pain for simulation, but can
affect how a chip must be tested (on a tester). What may seem like a good
idea for an individual block may not work when the block is a small part of
a larger system.
A common mistake with systems that use async resets to initialize themselves
is that the reset path is not considered as a valid timing path (it is
ignored). The result of this usually is a reset timing path that is
multiple clocks long. Although this has little affect on simulation, it
is a big deal for test. In some cases the tester is limited to running
functional patterns at the frequency that makes the reset path single cycle.
- Jay Pragasam
Brecis Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Jay Pragasam <jlk@brecis.com>
Hi John,
Here is some more that I've found on sync/async set/resets issue:
"Each has its pros and cons. This is another religious issue. I prefer
asynchronous resets to synchronous ones. Early in DC's life there were
problems with merging the synchronous reset signal in with the cloud of
logic in front of a flip-flop. This would result in a simulation lock-up
of unknowns as the Verilog simulator started each flip flop in an unknown
state and they never came out of the unknown state. It was never really
a DC problem, but DC got the blame. It is no longer an issue since DC
has had the ability to recognize synchronous reset/set signals and put
them as close to the inputs of the flip-flops as possible (no merging
with regular functional logic). The ability to check for synchronous
resets is activated by setting a variable to true:
hdlin_ff_always_sync_set_reset = true
But I got used to describing asynchronous resets and the coding style
stuck. The big thing you ve got to watch out for is not when the
asynchronous reset goes active, but rather when it goes inactive. As
soon as the asynchronous reset goes inactive the flip-flop is free to
change state when the next clock edge occurs. If the reset signal is
distributed throughout your design without care to how long the delay is
on the reset network you can have parts of the chip working in
functional mode while other parts of the chip are still in reset mode.
You've got to treat the asynchronous reset signal like a clock line and
balance it so that the signal goes inactive within the same clock cycle
throughout the entire chip. In case you don t plan to have a perfectly
balanced reset signal you can define the reset states for the flip-flops
and the combinatorial logic sections to hold their values stable for X
number of cycles or until the data inputs to the chip change (or some
other equivalent trigger event occurs). What this means is that you
design your default states or reset states such that they don't cause a
change in the logic values downstream from their position in the logic
cone when they are released (and free to change) from the reset state.
This could also save power if the chip doesn't start switching as soon
as the reset is released but rather when there is work to do."
This was in a paper presented in the SNUG'02.
- Jay Pragasam
Brecis Communications San Jose, CA
|
|
