This time, I’m going to focus on just how dangerous asynchronous resets can be. Maybe after this repeated horror story, you will be thinking twice about your coding style in the future.
Unreliable Sporadic Behaviour!
Three times now I have had Spartan users come to me saying that their designs are behaving “erratically” (well, that’s the polite way of saying it!). Ken asking them if they have a global asynchronous reset was not exactly what they wanted to hear back, but it did become the start of their investigation. In each case, there was indeed a large, if not truly global, asynchronous reset sourced by a pin on the device. The following picture is a simplification of their situation. Not surprisingly, the reset signal was also quite a big network on their PCB’s as well.
[see image (1) below]
The problem with such a big trace on a PCB is that it can also be a rather good antenna waiting to pick up signals. In fact, let’s not rule out that it may also reach out across multiple boards, or even pass through wiring looms, to reach a big black reset button somewhere! In the three cases that came my way, this was exactly the situation, and as the red trace on the PCB illustrates, there was indeed an opportunity for some inductive coupling to take place between the traces and induce a very narrow pulse into the FPGA causing at least a partial reset of the logic. As the pulse propagates through the programmable interconnect of the FPGA, it tends to ‘decay’ and hence effects only some of the flip-flops to which the reset signal connects.
Looking in the Spartan-3A data sheet, you can see that the minimum pulse width to reset a CLB flip-flop is TRPW_CLB and is stated to be 1.61 ns in the -4 speed grade. The key thing is that this is the minimum pulse width to guarantee that the flip-flop is reset under worst case conditions (low voltage, high temperature and slowest device we might ever manufacture). In practice, devices are nearly always faster under normal conditions and often significantly so. This means that induced pulses less than 1 ns can easily be enough to cause problems, which is nasty because very often you don’t have an oscilloscope fast enough to see them. It’s also one of those annoying situations where simply attaching the scope probe often introduces enough capacitance to suppress the pulse adequately to stop the issue when you try to observe it.
The Quick Fix!
Of course, I’m going to say that it is time to remove the asynchronous reset from your design. Certainly, that should be true at the start of your next design, but these things tend to happen when you have little time to fix them. Likewise, this is unlikely to be the time to consider better layout of traces on the PCB to prevent signals coupling. So if you find yourself in this situation, the quick fix is to add a filter to the reset signal as it enters the FPGA. Note that PROG_B could be considered to be the ultimate global asynchronous reset for the FPGA, and because of that we include a filter which prevents any pulses less than 100 ns or so from triggering reconfiguration; we need to mimic that filter using look-up tables as shown below.
[see image (2) below]
One or more buffers implemented in separate LUTs combined with their associated interconnect provide a delay to the incoming signal such that only a pulse longer than that delay will provide a High level to the AND gate when the directly routed input signal is still High. This will eliminate those spurious unintentional pulses for now, but in the future don’t even allow this to be a potential problem for your designs.
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.