Yes - along those lines, I've recently taken the stance that a board reset should clear the FPGA since that's the state it would be in at power-up, and I just use a configuration reset as my hard reset. Then I have a register-controlled soft reset.
Ken
Not entirely sure what you mean... that board reset kills the bitfile
in the FPGA, leaving it in its unprogrammed state? Draconian, bit I
agree with the philosophy (laughs evilly), at least in some cases.
I see something like soft errors (Xray) causing two very distinct
classes of problems: (1) LUTs themselves get corrupted, which means
the device now implements a different logic function than it was
supposed to, and (2) state-holding variables change in bad/unexpected/
nondeterministic ways. If case (1) happens, then you're screwed and
the reset-as-total-FPGA-annihilation strategy makes sense. But if case
(2) happens, its' really immaterial if it was due to Xrays, clock
glitches, or just bad design. My philosophy around (2) is that you
ought to be able to hit the design with with a simple reset and get
the chip up and running again without all the pain and elapsed time of
a full FPGA reconfiguration. By "pain" I mean losing more data than
you really needed to, as well as stuff like syncing software drivers
to the fact that the FPGA vanished from the face of the earth, the PCI
bus may have gone non-responsive (and caused fatal exceptions to be
raised in various micros), etc etc.
The example I like to use (taken from a real design in a deployed
product a few years ago) is that of a video input chip feeding a
recovered clock and data to a brand X series 4000 FPGA. The video
input chip was a multi-standard device and would "hunt" or sweep
across various clock frequencies ranging from 10 MHz to 40 MHz when
the input cable was removed. But when proper video was connected, a
relatively clean 27 MHz was output. The FPGA guy assumed that the
clock was *always* 27 Mhz and set the constraints in the FPGA synth &
PAR to 27 MHz. Then his one-hot state machine got blown out of the
water and went into all kinds of illegal states as soon as the video
input cable was pulled, and 40 Mhz came into his clock, and the timing
constraints were all violated. The FPGA locked up and wouldn't recover
even when legal input was reconnected. The problem was, he couldn't
reset the state machine in the FPGA, because he assumed "why would I
ever need to reset the state machine?", not realizing that the
physical one-hot-hardware in the FPGA could be in states his state
machine never described in the nice little VHDL model.
Now arguably, this design was architecturally flawed from day one and
would have required one of a number of possible solutions, potentially
(1) a hard PLL to limit the clock frequency when the input went
hunting, (2) more paranoid clock constraints of 40 MHz on the FPGA
synth run, which may or may not have been achievable at the time, or
(3) a simple reset, just like I said was on the stone tablet. A simple
reset that the micro (or in this case the "loss-of-carrier" signal)
could have fired is always a good design principle, IMHO. No need to
wait 500 ms for a reload. I strongly encourage all FPGA designs to
have a reset input which is capable of recovering all state-holding
elements so that FPGA reconfig is never required.
- Kenn
