Reset or not to reset

[news.optonline.net]

What is the consensus of opinion regarding the use of a explicity coded
global reset line that is driven by a power on reset circuit?

I'm targeting Xilinx Virtex II and QuickLogic Eclipse (both are available in
radiation hardened versions). The QL part resets all flops at reset. The
Xilinx can set/reset a flop. Therefore, theoretically I wouldn't need a POR
circuit and waste the routing resources.

However, eliminating the explicitly coded reset makes the Verilog synthesis
optimizer do strange things since it doesn't know what the initial value of
the flop will be (even if a directive is provided). In addition, it makes
simulation a bit more difficult.

That being said, I'm curious regarding other people's opinions on the
subject.

I am aware that using the GSR line on some Xilinx parts results in slow
reset distribution. In my case, it really shouldn't matter...

I give the following example of a reset flag for use by a ground link to a
spacecraft:

// This works fine
always @(posedge CLOCK, posedge RESET)
if (RESET)
RESET_FLAG_N <= 1'b0;
else if (FLAGS_READ_BY_TELEMETRY)
RESET_FLAG_N <= 1'b1;

// This gets optimized to a net tied to Vcc by both XST and Synplify
// adding a preserve attribute in Synplify makes all OK. The equivalent
// attribute in XST says the attribute is not applicable (another mystery)
always @(posedge CLOCK)
if (FLAGS_READ_BY_TELEMETRY)
RESET_FLAG_N <= 1'b1;

Thanks

 

[John_H]

"news.optonline.net" <cjhjh@khkj.net> wrote in message
news:S%yee.28040$RP1.18979@fe10.lga...

What is the consensus of opinion regarding the use of a explicity coded
global reset line that is driven by a power on reset circuit?

<snip>

I've been trying to get initializations into my synthesis for a very, very
long time by begging the tool vendors and trying to extoll the virtues of
embedded inits.

Xilinx XST appears to support register initialization such as:

reg [7:0] MyByte = 8'hcb;

but the support isn't as clean as one might want. Specifically, someone
pointed out that for initialization of a vector used for a shift register
wherever the initialized bit was 1 XST would break out a register instead of
staying in the SRL16.

I've been doing most of my design work either without resets or with
synchronous resets since I always have a clock available. The real problem
comes back to simulation. If I don't include a full synchronous reset my
choices are to do a post place & route simulation which is slow and has too
many signals renamed or I can parse the EDIF file for all the FDS and FDSE
primitives that power-up high in the Xilinx parts and look for regs I intend
to init high and see if those have been implemented in an FD, FDR, FDRE,
FDRS, or FDRSE. What a mess.

The simulation AND synthesis solution still isn't here. The tools SHOULD be
intelligent enough to avoid optimizing out the single-event detection
register you mentioned *without* directives but we're not there yet. There
are huge advantages to having code that can simulate and synthesize without
much disagreement.

So.... If you need the slightly higher performance of integrating the
synchronous set/reset into the logic to get better delays in critical paths,
don't use the async reset and go through the trouble of making your
simulation and synthesis match to save a few dollars in speed grade. If you
have the luxury of using faster parts or your design isn't pushing the
limits of performance, use the more expensive parts and the async resets to
save time in simulation, saving on development cost.

I am SO looking forward to the day when I can "have it all."

 

[Neo]

Ideally reset is used to intitalize the design to a known state before
applying stimulus. you may or may not need a reset depending on your
application. but it makes good sense to have it if the design is not
small as it gives a sense of determinacy when needed. it certainly also
helps during simulation. GSR lines shouldnt suffer any significant
delay unless its very densely routed.

 

[Steve Pope]

news.optonline.net <cjhjh@khkj.net> wrote:

What is the consensus of opinion regarding the use of a
explicity coded global reset line that is driven by a power on
reset circuit?

I'm targeting Xilinx Virtex II and QuickLogic Eclipse (both
are available in radiation hardened versions). The QL part
resets all flops at reset. The Xilinx can set/reset a flop.
Therefore, theoretically I wouldn't need a POR circuit and
waste the routing resources.

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.

Steve

 

[Chris F Clark]

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 : compres@world.std.com
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)
------------------------------------------------------------------------------

 

[Steve Pope]

Chris F Clark <cfc@shell01.TheWorld.com> wrote:

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.

Thanks for your thoughtful response.

I think the last sentence embodies why I view this differently
from you.

Your opinion is a blanket reset saves time because it does
not result in undefined states which you need to track down.

Whereas in my opinion, designing a minimal reset will reveal
logic errors that would take longer to emerge if there is a
blanket reset. Tracking down the resulting undefined states
is a useful, perhaps necessary bit of debugging. The blanket
reset might disguise problems through the first couple levels
of testing; while you're correct that once fully tested, these
will emerge anyway, you could have saved yourself time (and
possibly, ensured a more accurate result) by finding them sooner.

Another way to say this is there is considerable debugging
value in verifying that signals go to a defined state
at the expected point in time, and you lose that value
if you blanketly reset everything.

(I also would observe that if the designer doesn't know
which bits of state need initilization for the circuit
to properly function, then he doesn't have his arms
around the design.)

Thanks for posting

Steve

 

[Mike Treseler]

Steve Pope wrote:

Your opinion is a blanket reset saves time because it does
not result in undefined states which you need to track down.

It also guarantees one way to make simulation
match the hardware performance exactly.


-- Mike Treseler

 

[Steve Pope]

Mike Treseler <mike_treseler@comcast.net> wrote:

Steve Pope wrote:

Your opinion is a blanket reset saves time because it does
not result in undefined states which you need to track down.

It also guarantees one way to make simulation
match the hardware performance exactly.

Yes, but I'll quibble that vectors which include
undefined values can also achieve matching.

Steve