There are a number of issues that can affect your FPGA designs. One very important concern is when the core and/or input/output (I/O) voltages dip below the design limits for an FPGA. One of the first things this causes is the part to slow down, which can lead to timing faults and other difficult-to-find logic errors.
This means that most types of FPGA circuits upon which one must depend should employ some form of independent "brownout" monitoring of all voltages. This function should control a pin that will (a) drive the FPGA into reset and (b) drive the I/O into a safe state. Ideally, the safe state should be defined such that the system as a whole will still operate under brownout conditions. Further food for thought is that individual cards on a backplane can unseat or vibrate their connectors causing momentarily power issues.
Many different types of voltage monitoring circuits are available. TI, Maxim, and many others make these parts for a variety of applicable voltages. For example:
Another important issue that can affect FPGA designs is the loss of the clock oscillator, which can leave the I/O hung in an unsafe state. There are a couple of techniques that can be used for detecting and handling these events.
The first method is the "windowed watchdog." This uses an external integrated circuit (IC) that implements a windowed watchdog function completely independently of the FPGA -- except for the I/O to "pet the dog" to keep it happy. These ICs also typically monitor one or more voltages as well as perform a power-on reset (POR).
The "petting the dog" can be performed by your control state-machine or by your processor core, which are clocked by your PLL/Oscillator. An example of this type of component is the TPS3813J25 supervisor with programmable watchdog window from TI.
Another method is to use two different oscillator time bases. One then divides down each of these to a nice, even, similar frequency and compares the divide counts one gets versus each other (ratio).
Lastly (for this column), the act of performing a reset can be an issue for many FPGA circuits. This can be especially true when bypassing the PLL and using a direct oscillator drive to the part. In this scenario, prior to releasing the FPGA to run wild and free, one must give the oscillator time to come up and get on frequency and duty cycle (see my earlier blog -- The Right FPGA Reset for the Right Purpose -- for more details on this.)
Which of the issues presented here do you find yourself facing? And how do you solve them?