Anyone who knows me will tell you that I hate global
asynchronous resets with a passion! If you don’t know me that well, then please
take a while to read white papers WP272 and WP275 and, hopefully, you will
understand why. If, like so many other people, you do have a coding style that
results in global asynchronous resets, then I totally understand that you won’t
immediately welcome my suggestions, and I can appreciate why. Let’s face it,
there is an abundance of coding examples out there that include this nasty
habit and we all copy something to begin with.
http://www.xilinx.com/support/documentation/white_papers/wp272.pdf
http://www.xilinx.com/support/documentation/white_papers/wp275.pdf
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.
Message Edited by kcmman on 06-16-2008 09:35 AM