Need for reset in FPGAs

Hello,

usually a reset signal is applied to put the FFs of an FPGA into a known
state. Just some days ago I had a discussion. Someone's point of view
is, that a reset is not necessary, since the FF's output will be always
zero, after applying the voltage. Does this happen in FPGAs really,
especially in a Spartan3?

Bye Tom

Thomas Reinemann wrote:
> Hello,
>
> usually a reset signal is applied to put the FFs of an FPGA into a known
> state. Just some days ago I had a discussion. Someone's point of view
> is, that a reset is not necessary, since the FF's output will be always
> zero, after applying the voltage. Does this happen in FPGAs really,
> especially in a Spartan3?
>
> Bye Tom

The state of I/Os on a Spartan3 is known immediately post-configuration
(and may be high, low, Z or input - you can specify it in the
constraints), but that is the only time it's known, without knowing
implementation details.

If you are, however, in an environment with lots of clocks and signals
(pretty much the standard, one might think) you have to wait until the
*system* is in a known state. The best way to do that is with a global
reset. Then there's the time when a system controller needs to reset
just the FPGA (quite common), so a local reset for that purpose is
always a good idea [tm].

Just my $0.02

Cheers

PeteS

Thomas Reinemann wrote:
> Hello,
>
> usually a reset signal is applied to put the FFs of an FPGA into a known
> state. Just some days ago I had a discussion. Someone's point of view
> is, that a reset is not necessary, since the FF's output will be always
> zero, after applying the voltage. Does this happen in FPGAs really,
> especially in a Spartan3?
>
> Bye Tom

1 - If it were guarenteed that logic would always come up in a known
and valid state, why would the manufacturer include pins that are
dedicated to being a global reset?  Does most logic power up into a
known and valid state or does it need a solid reset signal?
2 - What about a brown out condition that scrambles the logic.  Does
the device contain a built in power supply monitor that detects the
brownout and asserts a proper reset?
3 - what about an application where a processor or other system needs
to control the timing of the reset or wants to reset the circuit on
watchdog timeout?
4 - Would you rather be safe or sorry?

Noway2 wrote:
> Thomas Reinemann wrote:
> > Hello,
> >
> > usually a reset signal is applied to put the FFs of an FPGA into a known
> > state. Just some days ago I had a discussion. Someone's point of view
> > is, that a reset is not necessary, since the FF's output will be always
> > zero, after applying the voltage. Does this happen in FPGAs really,
> > especially in a Spartan3?
> >
> > Bye Tom
>
> 1 - If it were guarenteed that logic would always come up in a known
> and valid state, why would the manufacturer include pins that are
> dedicated to being a global reset?  Does most logic power up into a
> known and valid state or does it need a solid reset signal?
> 2 - What about a brown out condition that scrambles the logic.  Does
> the device contain a built in power supply monitor that detects the
> brownout and asserts a proper reset?
> 3 - what about an application where a processor or other system needs
> to control the timing of the reset or wants to reset the circuit on
> watchdog timeout?
> 4 - Would you rather be safe or sorry?

One more thing I forgot to mention.

Unless you specify it in the contraints file, any FSM controls (usually
one-hot encoded) will come up cleared, which is an invalid state for a
one-hot encoder. The reset is usually used (and should be) to get the
FSM back to the default (usually idle, but could be anything) state

Something like this:

//parameters for processor bus state machine
parameter statecount    = 8;
parameter idle          = { {(statecount-1){1'b0}},1'b1};
parameter int_write     = idle<<1;
parameter int_read      = int_write<<1;
parameter switch_write  = int_read<<1;
parameter switch_write2 = switch_write<<1;
parameter switch_read   = switch_write2<<1;
parameter switch_read2  = switch_read<<1;
parameter switch_end    = switch_read2<<1;


//processor interface state machine
always @ (posedge clk or posedge rst) begin
  if (rst) begin
    switch_exception <= 1'b0;
    cmcbus_wr       <= 1'b0;
    cmcbus_rd       <= 1'b0;
    cmcbus_rd_clr   <= 1'b0;
    addrdata        <= 32'h00_00_00_00;
    parity3         <= 1'b0;
    parity2         <= 1'b0;
    proc_parity_error <= 1'b0;
    proc_ad_rdy     <= 1'b0;
    switch0_cs_l    <= 1'b0;
    switch1_cs_l    <= 1'b0;
    switch_rw       <= 1'b0;
    switch0_request <= 1'b0;
    switch1_request <= 1'b0;
    state           <= idle;
  end
// end of reset section
  else begin
    case (state)

      idle: begin
        addrdata      <= proc_ad;  //continuously load in new bus value
        parity3       <= proc_parity3;
        parity2       <= proc_parity2;
        proc_parity_error <= 1'b0;
        cmcbus_wr     <= 1'b0;
        cmcbus_rd     <= 1'b0;
        cmcbus_rd_clr <= 1'b0;
        proc_ad_rdy     <= proc_reset_out_l_use;
        switch_rw       <= proc_reset_out_l_use;  //default to a read
        switch0_request <= proc_reset_out_l_use;
        switch1_request <= proc_reset_out_l_use;
        switch0_cs_l    <= proc_reset_out_l_use;
        switch1_cs_l    <= proc_reset_out_l_use;
        if (cs7 & !proc_ad_we_l) begin  //internal write
          addrdata  <= addrdata; //hold bus values
          parity3   <= parity3;
   // and so forth

Cheers

PeteS

Thomas Reinemann wrote:
> Hello,
>
> usually a reset signal is applied to put the FFs of an FPGA into a known
> state. Just some days ago I had a discussion. Someone's point of view
> is, that a reset is not necessary, since the FF's output will be always
> zero, after applying the voltage. Does this happen in FPGAs really,
> especially in a Spartan3?
>
> Bye Tom

a Spartan3 will "live-up" in a known state (after configuration),
because FF's inital value is stored within the bitstream - this does
NOT mean, that the FFs will start at '0': this depends on your hdl-code
(and the tools).

"Thomas Reinemann" <thomas.reinemann@aucotronics.de> wrote in message 
news:e981ph$ur5$1@news.boerde.de...
> Hello,
> usually a reset signal is applied to put the FFs of an FPGA into a known
> state. Just some days ago I had a discussion. Someone's point of view
> is, that a reset is not necessary, since the FF's output will be always
> zero, after applying the voltage. Does this happen in FPGAs really,
> especially in a Spartan3?
> Bye Tom


If you use any form of PLL/DLL in your design I don't think you can
be sure of what's going to happen until it's locked. This can throw
logic/state machines into complete disarray.

I generate a synchronous reset which de-activates some period
after all my PLLs have locked.



Nial 

"Noway2" <no_spam_me2@hotmail.com> wrote in message 
news:1152882298.931106.231460@i42g2000cwa.googlegroups.com...
>
> Thomas Reinemann wrote:
>> Hello,
>>
>> usually a reset signal is applied to put the FFs of an FPGA into a known
>> state. Just some days ago I had a discussion. Someone's point of view
>> is, that a reset is not necessary, since the FF's output will be always
>> zero, after applying the voltage. Does this happen in FPGAs really,
>> especially in a Spartan3?
>>
>> Bye Tom
>
> 1 - If it were guarenteed that logic would always come up in a known
> and valid state, why would the manufacturer include pins that are
> dedicated to being a global reset?  Does most logic power up into a
> known and valid state or does it need a solid reset signal?
> 2 - What about a brown out condition that scrambles the logic.  Does
> the device contain a built in power supply monitor that detects the
> brownout and asserts a proper reset?
> 3 - what about an application where a processor or other system needs
> to control the timing of the reset or wants to reset the circuit on
> watchdog timeout?
> 4 - Would you rather be safe or sorry?

If you have a design that doesn't *need* an unusual reset - just a power-on 
reset - then you can get by without it.  If your system is subject to 
conditions that need to reset the logic, you can include the reset or just 
reprogram the FPGA (with the associated time lag and normal configuration 
issues).

It may be improtant to note that the reset will not affect the contents of 
memories, distributed or otherwise.

The global reset has been in the chips from the beginning (ASICs have their 
resets for good reason, the FPGAs carried this along) but ARE NOT 
RECOMMENDED for normal use because of the excessively long delays for those 
signals.

The operation with a PLL/DLL is moot if your device waits until the loop is 
stable before coming in to operation.

Not all synthesizers let you conveniently set the initial states of 
registers and memories.  To get good RTL simulation, the age-old async reset 
may give you the match between simulation and synthesis that can easily cut 
a couple days off the debug time for an FPGA.

Some synthesizers do a great job using the synchronous set and/or reset 
(unavailable if you use the async reset) to give you a little extra density 
beyond just cascaded 4-input LUTs.  Some synthesizers to a piss-poor job 
with the synchronous set/reset, tying up resources and increasing the 
overall delay in high-speed logic that just needs simple 4-input LUTs.

So.  Depending on the design and the synthesis tools, you can get by quite 
nicely without the power-up async reset that's left unused for the rest of 
the device operation.

Regardless of whether you use an async reset, a synchronous system reset, or 
no reset at all, you are only as safe as your engineering is thorough.

- John_H 

PeteS wrote:

> If you are, however, in an environment with lots of clocks and signals
> (pretty much the standard, one might think) you have to wait until the
> *system* is in a known state. The best way to do that is with a global
> reset. Then there's the time when a system controller needs to reset
> just the FPGA (quite common), so a local reset for that purpose is
> always a good idea [tm].

I agree.
It also makes accurate simulation easier.

> Just my $0.02

New total is $0.04

          -- Mike Treseler

To give you an idea how important a reset is, google for the WIRE mission, 
this 70Million dollar satellite was lost due to an incorrectly designed 
reset circuit......

Hans.
www.ht-lab.com


"Thomas Reinemann" <thomas.reinemann@aucotronics.de> wrote in message 
news:e981ph$ur5$1@news.boerde.de...
> Hello,
>
> usually a reset signal is applied to put the FFs of an FPGA into a known
> state. Just some days ago I had a discussion. Someone's point of view
> is, that a reset is not necessary, since the FF's output will be always
> zero, after applying the voltage. Does this happen in FPGAs really,
> especially in a Spartan3?
>
> Bye Tom 

Hans wrote:
> To give you an idea how important a reset is, google for the WIRE mission, 
> this 70Million dollar satellite was lost due to an incorrectly designed 
> reset circuit......

A poor reset circuit crashed several ferries
into the docks in Puget Sound.

     -- Mike Treseler
______________________________________________
http://catless.ncl.ac.uk/Risks/9.69.html#subj2

"As part of the state's Department of Transportation, Washington State
Ferries in Seattle operates 24 vessels, encompassing a variety of
control systems.  No others have had the problems of the six boats in
the Issaquah class, which are unique in having variable-pitch
propellors, one at each end of the boat.  When the captain sets the
control handle positions for transit or movement near the dock, the
control system must set the appropriate propellor speed, pitch, and
clutch engagement.  Variable pitch makes the craft extremely
maneuverable, able to move sideways and turn on the spot.

Many of the problems could be traced to the vendor, Propulsion Systems
Inc.  (PSI), which went bankrupt in 1981 and was then bought by the
ferry builder, the now-defunct Marine Power and Equipment Co.  "The
problem is not so much with digital controls," said Davis, "as with
horribly shoddy control system design."