Need for reset in FPGAs

The state of I/Os on a Spartan3 is known immediately post-configuration (and may be high, low, Z or input - you can specify it in the constraints), but that is the only time it's known, without knowing implementation details.

If you are, however, in an environment with lots of clocks and signals (pretty much the standard, one might think) you have to wait until the

*system* is in a known state. The best way to do that is with a global reset. Then there's the time when a system controller needs to reset just the FPGA (quite common), so a local reset for that purpose is always a good idea [tm].

Just my $0.02

Cheers

PeteS

1 - If it were guarenteed that logic would always come up in a known and valid state, why would the manufacturer include pins that are dedicated to being a global reset? Does most logic power up into a known and valid state or does it need a solid reset signal? 2 - What about a brown out condition that scrambles the logic. Does the device contain a built in power supply monitor that detects the brownout and asserts a proper reset? 3 - what about an application where a processor or other system needs to control the timing of the reset or wants to reset the circuit on watchdog timeout? 4 - Would you rather be safe or sorry?

One more thing I forgot to mention.

Unless you specify it in the contraints file, any FSM controls (usually one-hot encoded) will come up cleared, which is an invalid state for a one-hot encoder. The reset is usually used (and should be) to get the FSM back to the default (usually idle, but could be anything) state

Something like this:

//parameters for processor bus state machine parameter statecount = 8; parameter idle = { {(statecount-1){1'b0}},1'b1}; parameter int_write = idle

a Spartan3 will "live-up" in a known state (after configuration), because FF's inital value is stored within the bitstream - this does NOT mean, that the FFs will start at '0': this depends on your hdl-code (and the tools).

If you use any form of PLL/DLL in your design I don't think you can be sure of what's going to happen until it's locked. This can throw logic/state machines into complete disarray.

I generate a synchronous reset which de-activates some period after all my PLLs have locked.

Nial

If you have a design that doesn't *need* an unusual reset - just a power-on reset - then you can get by without it. If your system is subject to conditions that need to reset the logic, you can include the reset or just reprogram the FPGA (with the associated time lag and normal configuration issues).

It may be improtant to note that the reset will not affect the contents of memories, distributed or otherwise.

The global reset has been in the chips from the beginning (ASICs have their resets for good reason, the FPGAs carried this along) but ARE NOT RECOMMENDED for normal use because of the excessively long delays for those signals.

The operation with a PLL/DLL is moot if your device waits until the loop is stable before coming in to operation.

Not all synthesizers let you conveniently set the initial states of registers and memories. To get good RTL simulation, the age-old async reset may give you the match between simulation and synthesis that can easily cut a couple days off the debug time for an FPGA.

Some synthesizers do a great job using the synchronous set and/or reset (unavailable if you use the async reset) to give you a little extra density beyond just cascaded 4-input LUTs. Some synthesizers to a piss-poor job with the synchronous set/reset, tying up resources and increasing the overall delay in high-speed logic that just needs simple 4-input LUTs.

So. Depending on the design and the synthesis tools, you can get by quite nicely without the power-up async reset that's left unused for the rest of the device operation.

Regardless of whether you use an async reset, a synchronous system reset, or no reset at all, you are only as safe as your engineering is thorough.

- John_H

I agree. It also makes accurate simulation easier.

New total is $0.04

-- Mike Treseler

To give you an idea how important a reset is, google for the WIRE mission, this 70Million dollar satellite was lost due to an incorrectly designed reset circuit......

Hans.

A poor reset circuit crashed several ferries into the docks in Puget Sound.

-- Mike Treseler ______________________________________________

"As part of the state's Department of Transportation, Washington State Ferries in Seattle operates 24 vessels, encompassing a variety of control systems. No others have had the problems of the six boats in the Issaquah class, which are unique in having variable-pitch propellors, one at each end of the boat. When the captain sets the control handle positions for transit or movement near the dock, the control system must set the appropriate propellor speed, pitch, and clutch engagement. Variable pitch makes the craft extremely maneuverable, able to move sideways and turn on the spot.

Many of the problems could be traced to the vendor, Propulsion Systems Inc. (PSI), which went bankrupt in 1981 and was then bought by the ferry builder, the now-defunct Marine Power and Equipment Co. "The problem is not so much with digital controls," said Davis, "as with horribly shoddy control system design."

Whether or not you need a reset depends on your design and the application. If you have nothing more than, say, a data pipeline that will eventually flush itself out, and your application is insensitive to the garbage that the pipe emits initially, you may not need a reset at all. But if your circuit has control, perhaps in the form of finite state machines, relying on the FPGA to correctly initialize state can be dangerous. FPGAs generally use a very slow global net to initialize device state--so slow, in fact, that there's no way to guarantee when the deassertion of the initialization signal arrives at each flip-flop relative to the clock's active edge. If it arrives at just the right time (or just the wrong time, depending on your perspective), some FSM flip-flops may be inhibited from transitioning while others are not, and away you go into a bogus state. You can design FSMs that always eventually transition to a valid state, but sometimes it's easier and better to guarantee that you never enter a bogus state in the first place.

The following article describes how FSMs can be corrupted by inputs that are asynchronous to the FSM clock.

Once you realize that the FPGA initialization signal is asynchronous, you'll understand the problem.

Bob Perlman Cambrian Design Works

The FFs always come up in a guaranteed way after power-up - the bitstream you feed into the FPGA defines their power-up state.

Normally this will be a zero, but there are situations where this can change. Either because you tell the tools you want a '1' there instead - or because the tools decided it would make their life easier for it to power-up to '1'. If you're lucky they'll even tell you they did it :-)

The old Altera 10K series FFs could only reset to '0', so if you asked for a preset FF, the mapper (or whatever it was called back in those days) would stick not gates either side of it to make it behave how you asked it to. This had the side-effect of power-up to '1' also, which was *usually* what you wanted... Anyway, those days are passed, I'll be quiet now :-)

Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

It is important to have a reset that is synchronously deasserted relative to every clock used. These may be fully syncrhonous resets or asynchronous resets that have the trailing edge syncrhonized.

The reason for this is that if a reset input is not syncrhonized to the same clock as the circuitry being reset, then all flops in the circuit will not come out of reset on the same clock, which, unless it is handled very carefully, will cause problems that can be very hard to debug.

Whether or not you have a separate reset, or are only resetting on configuration, the above requirements hold true.

Andy

Nial Stewart wrote:

One of my current designs has a AC97 and GSM modem PCM interface to a Bluetooth link, multiplexed. This link may obviously be switched from one to the other (yes, I play system sounds across bluetooth ;) at any time. i.e. relatively asynchronous events. The other thing is GSM PCM data is 8k frame rate, AC97 can be up to 192k, variable rate (you have to extract valid data) so there are retimers for the data stream, which is simple enough if you only have one source; with two or more it becomes imperative to ensure clean switching.

I have to make sure when I switch into either mode that the state machine for data reframing is in a known state, so at every switch I assert an synchronous reset to the retimer - in reality the switching signal is synchronised to the frame generator so I am guaranteed to switch cleanly from one input to the other and change the rates at which I retime.

Reset costs one pin and saves untold misery

Cheers

PeteS

Because you might want to reset all the FF after power-up. I believe that the FF are loaded with their reset value when the FPGA is configured whether or not the reset is there.

Mike