Re: comp.arch.fpga: reset strategy
Hendra Gunawan
John Retta
The previously mentioned article was an interesting read. I have always
been a strong
advocate of synchronous design, and this includes the application of resets.
My rule of thumb is use synchronous resets in all areas, unless
exceptional
conditions arise. There are at least two good exceptions :
[1] Block of logic may have a clock which after power-up disappears, example
clock derived from a DDS which might be reset operationally. In order to
restore outputs
to inactive states in absence of clock, asynchronous reset needs to be used.
[2] Sequential logic drives tristate enable control - During powerup or
during
in-circuit test mode, clock may not be present, and multiple drivers causing
contention
can cause device failure.
My rationale for avoiding asynchronous resets is two-fold. Once you
develop
synchronous design devotion, then allowing asynchronous resets seems to be
a strong violation. Second, is kind of the real basis for synchronous
design
practices. The only timing paths that need to be analyzed are from Q
outputs
of flops to D- Inputs. I think static timing analyzers are much better at
timing
asynchronous reset paths, but as recently as 2-3 years ago, I don't think
this
was the case. Problem is that the start of the path is no longer the
originating
D-FF, but rather the reset source which drives the reset to this device.
Sometimes historical problems which have been later resolved still don't
cause a designer to abandon coding styles that were reinforced by hard to
trace problems.
--
Regards,
John Retta - Colorado based Xilinx Design Consultant
Owner and Designer
Retta Technical Consulting Inc.
email : jre...@rtc-inc.com
web : www.rtc-inc.com
<pop> wrote in message news:ee86f...@webx.sUN8CHnE...
Hi
I have inherited a design containing both asyncrous and syncronous FF. I
started to rewrite the code but started to doubt the strategy. Does anybody
know which is better. The FPGA is very large.
Thomas Stanka
"John Retta" <jre...@rtc-inc.com> wrote:
> The previously mentioned article was an interesting read. I have always
> been a strong
> advocate of synchronous design, and this includes the application of resets.
> My rule of thumb is use synchronous resets in all areas, unless
> exceptional
> conditions arise. There are at least two good exceptions :
> [1] Block of logic may have a clock which after power-up disappears, example
> clock derived from a DDS which might be reset operationally. In order to
> restore outputs
> to inactive states in absence of clock, asynchronous reset needs to be used.
> [2] Sequential logic drives tristate enable control - During powerup or
> during
> in-circuit test mode, clock may not be present, and multiple drivers causing
> contention
> can cause device failure.
I think you forgot logic that drives external cirquits (which might be
true for most designs). Normaly you start your fpga while powerup of
the pcb. There exists cirquits that wil be destroyed if the fpga
drives its outputs in a state which generates unacceptable currents or
voltages on external parts over a longer periode (beside tristate
busses).
I prefer a asynchronous reset and an internal logic, that will recover
out of every failure mode. In some cases it might be clever to use a
synchron deassert of the asynchronous reset.
bye Thomas
glen herrmannsfeldt
> My rule of thumb is use synchronous resets in all areas,
> unless exceptional conditions arise.
> There are at least two good exceptions :
(snip of exceptions)
(snip)
To me, a global asynchronous reset driven from an external
pin, or by the FPGA itself, is fine. The user of the system
is then responsible for any required timing. (I believe most
FPGA will do asynchronous reset on all FF at initialization time.)
Otherwise, I would agree that asynchronous reset driven by other
parts of the design results in an asynchronous design.
-- glen
rickman
I believe that all FPGAs have power on resets that keep the IO in a
defined state which is always hiZ AFAIK.
As to the synchronous deassert of the async reset, the async reset
nearly always has a slow propagation time. So if you clock is at all
fast, you will need to have FFs which reset other parts of the circuit
and can add a delay once the async reset is released. Being async is
just one problem of the async reset. The other part is the slow
propagation which will make an sync release an async one. So break up
the reset on the critical circuits so that each circuit can be reset
with a clearly synchronous release. I hope that is clear... :)
--
Rick "rickman" Collins
rick.c...@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
Rajeev
> (snip)
>
> To me, a global asynchronous reset driven from an external
> pin, or by the FPGA itself, is fine. The user of the system
> is then responsible for any required timing. (I believe most
I was puzzled by your saying this. It seems clear that neither the system
nor user (ie external to the chip) has any control over the reset skew
internal to the device, and that they cannot fix a startup problem caused
by this. Perhaps the answer is application-dependent:
I can see global external async reset being fine for the class of
designs which reset into an idle state, ie they don't do anything until
they receive an external trigger.
> FPGA will do asynchronous reset on all FF at initialization time.)
>
> Otherwise, I would agree that asynchronous reset driven by other
> parts of the design results in an asynchronous design.
>
> -- glen
My two cents,
-rajeev-
roller
<pop> escribió en el mensaje news:ee86f...@webx.sUN8CHnE...
>Hi
>
>I have inherited a design containing both asyncrous and syncronous FF. I
started to rewrite the code but started to doubt the strategy. Does >anybody
know which is better. The FPGA is very large.
hi,
i'd also like to know if there are design guidelines about reset as there
are for clocks. Like i know that you shouldnt put any logic on the clocks as
it messes with the clock tree generation, but is there design rules about
reset for ASIC and FPGA?
is it good or bad practice to put something like
process(clk, reset, reset2)
begin
if reset = '0' or reset2 = '1' then
reset stuff;
elsif clk'event and clk = '1' then
sync stuff;
end if;
end process;
instead of:
process(clk, reset)
begin
if reset = '0' then
reset stuff;
elsif clk'event and clk = '1' then
if reset2 = '1' then
reset stuff;
else
sync stuff;
end if;
end if;
end process;
because the second approach will use muxes, while the first one will use
only gates in the reset path to the DFFs
i started reading about resets, but i think i still havent read anything
about not putting logic in the reset path
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote in message news:<Oxmxc.15640$HG.9409@attbi_s53>...
>>(snip)
>>To me, a global asynchronous reset driven from an external
>>pin, or by the FPGA itself, is fine. The user of the system
>>is then responsible for any required timing. (I believe most
> I was puzzled by your saying this. It seems clear that neither the system
> nor user (ie external to the chip) has any control over the reset skew
> internal to the device, and that they cannot fix a startup problem caused
> by this. Perhaps the answer is application-dependent:
> I can see global external async reset being fine for the class of
> designs which reset into an idle state, ie they don't do anything until
> they receive an external trigger.
Yes, that is the type of device I was considering.
The external trigger might be a clock edge, though, so one
should be sure not to enable that clock too soon.
-- glen