Steve wrote:
> In my opinion one should only reset those state bits that
> need to be reset for proper functioning of the circuit.
> This helps in debugging because values that you should have
> initialized, but failed to, will show up as "x" in your
> testbenches. If you globally reset everything, then no
> "x's" appear and it much less easy to find initialization
> problems.

Perhaps I am just dense here, but this solution seems counter-
intuitive to me. I assume that the reason is initialization means
something other than reset and this could be an ASIC/FPGA difference.
To me a circuit is initialized once the reset logic has been exercized
and not before. Before the reset has been appliead and the cirucuit
has settled, the circuit state is undefined, because one doesn't know
what random static charges are left where when one first powers-on the
circuit until the circuit has reset itself.

If you take that interpretation, then Steve's statement reads
something like this:

I suggest you don't reset all the bits, only the necessary ones,
because not reseting the bits allows you to find the bits you forgot
to reset. That is the problem bits are only the ones you didn't
reset. If you reset them all, there are no bits you forgot to reset
and there can be no problem ones.

Now, some of those bits you reset won't actually ever get read before
being set in operation, but that's a different problem (and it sounds
like the preceding poster's question). If you want to save some
circuitry by not reseting certain bits, then you need to determine
which bits you can safely not reset.

And in this sense Steve is correct, in a simulation, the bits you
don't set will have an "x" value. That can help you determine when a
bit isn't set that needs to be. If the bit is ever read as an "x" it
is a potential problem. It's not a problem if it goes into a circuit
that ignores the "x", for example an or gate with the other input
being a 1, or a mux that is selecting a different input.

However, the maxim that testing can only reveal the presence of
problems and never the absence applies. Just because in some set of
simulations, the signal was never "x" at a bad time, doesn't
necessarily mean that the signal will never ben an "x" at a bad time,
unless you can prove that your simulations have covered all the
possible cases, which you probably can't--atleast you can't for many
of the kinds of circuits that I find interesting to design.

Now you get to the trade-off area. Some of the signals don't need to
be reset. Some of those signals you may be able to prove that you
don't need to reset. Which signals do you reset?

If you aren't short on resources, then reset all the signals. It is
always safe to do so. That is especially true if it doesn't take any
significant design time to define the global reset. You have saved
your time, by not trying to determine which signals you need to
reset and you haven't consumed any scarce resources in doing so.

A global reset is often a good starting point even if resouces are
scarce. You design the circuit assuming that it will fit within your
resource budget and then when it doesn't you trim things. So,if the
routing becomes the constraining factor, you can eliminate some
signals from the global reset after determining that it is safe to do
so. However, you don't waste time determining whether any particular
signal is safe to remove until you have determined that removing it
will save your constraining resource.

Now, that over simplifies things a little. If you no some constraint
is likely to be limiting and it is easy enough to reduce the pressure
on it early on in the design, then do so. I don't do fpga design, so
I have no intuition as to whether global reset signals often push one
over the limit. However, in things where I do have experience, I have
found that global resets that initialize everything are generally good
solutions to problems. Skimping on the reset logic, because something
can never be accessed in the invalid state, is usually a recipe for
fragility.

Hope this helps,
-Chris

************************************************** ***************************
Chris Clark Internet : [email protected]
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------