Re: How to develop a random number generation device

On Sun, 09 Sep 2007 15:56:53 +0000, Guy Macon
<http://www.guymacon.com/> wrote:




John Larkin wrote:

And my point is that it shouldn't "accidentally" get into a broken
state, any more than the program counter of a CPU should accidentally
find itself in never-never land.

If a digital system is unreliable, the cause should be found and
fixed. The problem with kluges like this is the same problem with
watchdog timers: they hide the real problem, so keep it from getting
fixed.

I always turn off the watchdog timer on test units, and protos
delivered to customers. I only enable it after we're sure we don't
need it.

I have seen engineers get into trouble that would have been
avoided had they only followed the above advice.

Another problem-hider is filling unused ROM with jumps to the
reset vector. I only do that on the production units; for
the prototype (and sometimes for the pilot run) I like to fill
unused ROM with stop instructions.

A technique that I sometimes use when designing toys is to
have the button / switch that tells the toy to start moving
and making noise cause a hardware reset, and the timeout at
the end of play that tells the toy to stop moving and conserve
power to invoke the deepest available sleep mode -- usually
with the clock stopped entirely -- to be woken up by the next
hardware reset. In industrial control applications you
sometimes see the same sort of thing but with a counter causing
the resets to occur every N seconds. This techniques isn't
always applicable (check to see how fast the oscillator can
come up, for example; some are annoyingly slow) but in some
limited cases it works well.

Some things have to run continuously, with microsecond response to
inputs, so can't be periodically reset. Most of my products have long
startup times, too, as long a 5 seconds, so a true system reset is
pretty traumatic.

The reliability of a good digital system should be dominated by
classic hardware MTBF, not by bugs or glitches. It should have *no*
bugs or glitches.

John

.

Quantcast