Please e-mail comments and suggestions for these guidelines and criteria.
A. Reset logic circuit (consider transient behavior): Transient effects must be considered on the reset circuit; indeed, this must be the focus of the analysis. For the application of power, the output of the POR or reset circuit should ideally be a solid logic level and be glitch-free. Inrush currents to timing capacitors must not exceed the maximum for that capacitor type. Rise times to logic gates, if used as a comparator, must not exceed the input's specifications; often gates with hysteresis inputs are used. Note that even with that type of input, output glitches may occur and several stages of logic gates must be used. The most robust solutions often utilize a comparator. Another transient factor to consider is the rise time of the flight power supply, both best and worst cases. These will often differ substantially from laboratory supplies and may be non-monotonic or have substantial overshoot and ringing. Note that flight power supplies are often slew-rate limited to minimize conducted emissions on the power bus. The time constant of the supply may exceed that of the POR circuit! For discharge, ensure that there is a low impedance path for timing capacitor discharge and that the inputs of logic gates are protected. Most CMOS inputs, but not all, have ESD diodes from the input to the supply rail. Discharging a large capacitance through that input may damage it. Also, consider the requirements and response of the circuit to momentary disruptions on the power bus. While many circuits may recover or be recoverable from a power-on reset, this is not true for all circuits. One such example is non-volatile, erasable memories, which need to be carefully protected.
Many diagrams of reset circuits show "asynchronous application, synchronous removal" of the reset circuit. However, note that for many devices, in particular many programmable devices, the inputs can be blocked or ignored during the power-on transient. This may be because of the need for charge pumps to start or configurations to be loaded and then released. For devices with synchronized inputs, the clock oscillators must start, perhaps taking many tens of milliseconds, before the reset can be applied. Outputs of these devices must be handled at the system level as the reset, which may look just fine on the schematic or in the HDL code, will be ignored by the real circuits.
Steady state or DC effects are also important. Check the leakage currents of timing capacitors and logic gates, as the amount of leakage current times the resistance of the timing resistor may result in a voltage drop that eliminates all noise margins.
B. Tree: Drawing a tree of all of the reset sources is often helpful in ensuring that the reset logic is well defined. Often there are multiple forms of reset from system resets, software resets, watchdog timers, etc., and having a good tree diagram shows the relationships between them. Ensure that proper synchronization is made when required. Additionally, if the reset needs to be activated fast, for instance to protect non-volatile memories from false writes, or other circuits from initiating one-time events such as firing pyrotechnics, the tree will help ensure that the logic and delays are well understood.
C. Reset active time vs. startup of components such as FPGAs and crystal clock oscillators: Ensure that the guaranteed reset time is sufficiently long for all circuits in the system. This is often overlooked. For instance, many FPGAs require time to "start," where the charge pump must build up voltage and charge internal capacitances, wait for a delay, and then release it's outputs. Premature release of the POR signal may result in an indeterminate state. Other FPGAs may require a sequence of resets for proper loading and release, with many circuits having internal power-on reset circuits. The timing of all of these resets must be analyzed for best and worst-case behavior. Additionally, some standard components on digital logic boards such as crystal clock oscillators can have a substantial startup time, often many tens of milliseconds. Complicating this further, components such as FPGAs and crystal clock oscillators may have startup times that are a function of the rise time of the power supply. Even worse, this behavior is often poorly specified or not specified at all. Robust start times are critical.
D. Protection of signals for mission critical or one-time events (i.e., pyrotechnic initiation): This topic was partially addressed in B, above. However, because of the importance of this signal, it also earns its own section. Note that many logic elements do not follow their truth tables as the power supply ramps up. Thus, the POR signal must act as a gate, blocking false signals during the power supply rise time transient and then release after all circuits are stable. On the other side, when the power comes down, the POR circuit may need to be asserted early, ensuring that critical circuits are safe before the logic elements lose control as the voltage drops. Devices that often need protection are pyrotechnic initiators, EEPROMs, flash memories, etc. Note that some devices such as microcontrollers have internal flash memories, so evaluate all components and system interfaces for necessary protection by the POR signals.
Start times of oscillators may be a function of power supply rise time and may not start up clean. Example with a 50 ms power supply rise time. For the same oscillator, this is a summary of performance over a range of rise times.
"Some Characteristics of Crystal Clock Oscillators During the Turn-On Transient." This application note discusses and shows what the output of an oscillator may be during the turn-on transient. Examples shows include runt pulses of various sizes and polarities.
"Asynchronous & Synchronous Reset Design Techniques - Part Deux"
Timing Analysis of Asynchronous Signals
"Analysis of POR Circuit Topologies"
TOP LEVEL: "Design Guidelines and Criteria for Space Flight Digital Electronics"
NASA Office of Logic Design
Last Revised: February 03, 2010
Digital Engineering Institute
Web Grunt: Richard Katz