comp.arch.fpga: reset strategy

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.

Reply to
pop
Loading thread data ...

=_NextPart_000_0008_01C44CCC.5EA27140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

formatting link
f
formatting link

2.pdf

Hendra

Reply to
Hendra Gunawan

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
 Click to see the full signature
Reply to
John Retta

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

Reply to
Thomas Stanka

(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

Reply to
glen herrmannsfeldt

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.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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.

My two cents,

-rajeev-

Reply to
Rajeev

escribió en el mensaje news: snipped-for-privacy@webx.sUNCHnE...

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

Reply to
roller

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

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.