FPGA Reset implementation

[guybrush]

fpga reset

I'm trying to design a reliable project in an FPGA ACTEL, for space application. This technology has F/F with asyncronous preset or clear. So I put a simple POR circuit with a long time constant so that the oscillator will already produce a stable clock while the reset is released. But I think that some timing violation can arise when the reset is released near to the rising clock edge, because of skew that in a signal routed to each F/F can be high. My solution was to assert the reset asynchronously but deassert it on a rising edge of the system clock. You think that this is the best solution or not ? Thank you.

 

[zape]

reset fpga

Reset generates always controversy. I have designed several FPGA for space, always Actel devices, and my philosophy for a general reset is that must be asserted asynchronously but released synchronously. You may design a simple synchronizer with three registers.

A reset like the one I propose shall consume more logic resources so that the maximum clock frequency shall be decreased (not a problem in most space applications) but you ensure that all ff's shall be initialized at the same time and your design shall work properly.

Anyhow I recommend you to analyze carefully your interfaces getting a good knowledge of the board logic. You may need to do some special cases.

 

[delay]

reset in fpga

A reset must always be asynchronous, you just can't wait for a stable clock for deassertion even if you assert it asynchronously. If you do, you need to make sure that oscillator is stable. Although if the clock never becomes stable, holding system in set or reset mode wouldn't matter much.

See below excerpt from NASA's WIRE failure:

This section is a shortened transcription of the failure investigation report, RD5, for the Wide- Field Infrared Explorer (WIRE) spacecraft. There are several other findings in the aforementioned report that are not covered in this document since being outside its scope.

The NASA WIRE spacecraft was launched in 1999 and a problem was detected during its second pass over the ground station, when the spacecraft was observed to be spinning. It was determined by the failure review board that the cover was ejected at approximately the time that
the WIRE pyro box was first powered on. The instrument's solid hydrogen cryogen supply started to sublimate faster than planned, causing the spacecraft to spin up to a rate of sixty revolutions per minute once the secondary cryogen vent was open. Without any solid hydrogen
remaining, the instrument could not perform its observations.

The probable cause of the WIRE mishap is logic design error. The transient performance of components was not adequately accounted for in the design. The failure was caused by two distinct mechanisms that, either singly or in concert, resulted in inadvertent pyrotechnic device
firing during the initial pyro box power-up. The control logic design utilized a synchronous reset to force the logic into a safe state. However, the start-up time of the crystal clock oscillator was not taken into consideration, leaving the circuit in a non-deterministic state for a significant period of time. Likewise, the start-up characteristics of the FPGA were not considered. These devices are not guaranteed to follow their truth table until an internal charge pump starts the part and the uncontrolled outputs were not blocked from the pyrotechnic devices' driver circuitry. A contributing factor to the mishap was the lack of documentation for the FPGA's power-up transient characteristics in the device data sheet. This information is however available in the FPGA data book and design guide in two application notes.

At least three conclusions can be drawn from the WIRE mishap:
• the design should never rely on the default value of the device output during power-up
• the designers should continuously collect and read all available device documentation
• there should be a direct asynchronous path from the reset input for initialising the device state, being independent of any clock activity

 

[zape]

fpga resets

I agree with your comment "delay" I was aware about the WIRE failure and it goes in the line of my comments. I have designed several pyrothecnics controllers and the best solution is the use of external tri-state buffers which are enabled by means of your power-on reset. As you remark you must know that your oscillator may have an start-time from 10 to 100 ms ( so your POR must be active for a time > 100ms) but also that depending on the rise time of your supply the output pins of your FPGAs may be driving the loads independently of the state of your reset.
Once again I must say reset set asynchronously but released synchronously and study the behaviour of all the components in your design during power up and power down.