Re: Register with a default Value

On Jan 8, 5:47 pm, Ken Cecka <cec...@xxxxxxxxxxxxxxxxxxxxx> wrote:
Andy Peters wrote:
On Jan 2, 7:24 am, kennheinr...@xxxxxxxxxxxx wrote:

In my personal opinion, it's a bad idea to try to do this in the first
place. One of the commandments that came down from the Mount on stone
tablets was "Thou shalt have an external reset on every device which
dang well resets the thing!". If you rely on power-up or load
conditions that cannot be repeated when you externally reset the
device, then your reset is, by definition, not really a reset and
violates the commandment. If you don't have a reset, then you can't
control the state of your FPGA, and you're just asking for trouble in
a big way.

One could argue that if the FPGA goes so tits-up (perhaps from x-rays
or other weirdness) that it requires a global reset, it might be
better to simply reconfigure the device.

-a

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
.

Relevant Pages

  • Re: clk synchronization of reset signal
    ... the double FF sync. ... But if your design is not all that fast, ... will have to work harder to distribute the sync'd reset across the ... Sometimes the tools will use a global clock line for this. ...
    (comp.arch.fpga)
  • Two hierarchy designs
    ... even though the "clock" signal has been used in the same as the ... valid design? ... module top1(clock, reset, read, busy); ...
    (comp.lang.verilog)
  • Re: sync vs async reset
    ... I have some basic questions on sync and async reset schemes. ... be thankful if any design experts clarify them for me. ... clock being present, which is quoted as one of the main disadvantage ...
    (comp.arch.fpga)
  • Two hierarchy designs
    ... even though the "clock" signal has been used in the same as the ... The two design examples are as following: ... module top1(clock, reset, read, busy); ...
    (comp.lang.verilog)
  • Re: clk synchronization of reset signal
    ... the double FF sync. ... But if your design is not all that fast, ... will have to work harder to distribute the sync'd reset across the ... Sometimes the tools will use a global clock line for this. ...
    (comp.arch.fpga)
Loading