FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > Verilog

Verilog comp.lang.verilog newsgroup / usenet

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 05-06-2005, 02:38 AM
news.optonline.net
Guest
 
Posts: n/a
Default Reset or not to reset

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


Reply With Quote
  #2 (permalink)  
Old 05-06-2005, 07:21 AM
Neo
Guest
 
Posts: n/a
Default Re: Reset or not to reset

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.

Reply With Quote
  #3 (permalink)  
Old 05-06-2005, 06:20 PM
John_H
Guest
 
Posts: n/a
Default Re: Reset or not to reset

"news.optonline.net" <[email protected]> wrote in message
news:S%[email protected]
> 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."


Reply With Quote
  #4 (permalink)  
Old 06-18-2006, 01:17 AM
Steve Pope
Guest
 
Posts: n/a
Default Re: Reset or not to reset

news.optonline.net <[email protected]> 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
Reply With Quote
  #5 (permalink)  
Old 06-18-2006, 06:51 PM
Chris F Clark
Guest
 
Posts: n/a
Default Re: Reset or not to reset

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)
------------------------------------------------------------------------------

Reply With Quote
  #6 (permalink)  
Old 06-19-2006, 12:32 AM
Steve Pope
Guest
 
Posts: n/a
Default Re: Reset or not to reset

Chris F Clark <[email protected]> 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
Reply With Quote
  #7 (permalink)  
Old 06-19-2006, 01:58 AM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Reset or not to reset

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
Reply With Quote
  #8 (permalink)  
Old 06-19-2006, 02:04 AM
Steve Pope
Guest
 
Posts: n/a
Default Re: Reset or not to reset

Mike Treseler <[email protected]> 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
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
state machine with asynchronous reset? glen herrmannsfeldt Verilog 11 10-14-2004 07:09 AM
Asynchrous reset. One Day & A Knight Verilog 1 11-21-2003 10:45 AM


All times are GMT +1. The time now is 07:42 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved