Basic FPGA question about Reset

G.

How one starts the configuration process is a different problem that how
the device after configuration, starts up.

The first problem is often caused by people "not trusting" the internal
Power On Reset circuits in the FPGA:  bad.  We spend an immense amount
of time making sure the POR circuits work under all sequences, and all
ramps from 2us to 50ms.  Mess with this, and then you have to do all the
engineering for three power supplies to make it work at least as well as
we already did.  Not a smart move.  Why would anyone want to re-invent
this wheel?

After the product has loaded the configuration, and has completed the
start-up sequence, then everything is in a known state, so a reset isn't
even required (it is implicit in the starting values you placed in the
registers in your VHDL or verilog code, and was part of the loaded
bitstream).

If at some time later, you want to return to a 'known good state', which
we will call "reset" for no better reason than it describes the action
you want to take, then the applications note (or the old Tech X) details
all kinds of ways to do this, that work.

Austin

On Wed, 16 Jan 2008 10:22:39 -0800, austin <austin@xilinx.com> wrote:

>G.
>
>How one starts the configuration process is a different problem that how
>the device after configuration, starts up.
>
>The first problem is often caused by people "not trusting" the internal
>Power On Reset circuits in the FPGA:  bad.  We spend an immense amount
>of time making sure the POR circuits work under all sequences, and all
>ramps from 2us to 50ms.  Mess with this, and then you have to do all the
>engineering for three power supplies to make it work at least as well as
>we already did.  Not a smart move.  Why would anyone want to re-invent
>this wheel?

There are a few reasons why you would want to re-invent that wheel in
a practical product:

1.  "all ramps from 2us to 50ms"  
It may be impossible to guarantee the 50ms end of that, particularly
in mains powered circuits.  If there is a slow brownout, an external
reset generator with accurate thresholds *will* result in a more
reliable design.

2.  I find that my designs rarely contain just an FPGA.  I have a
whole host (sorry about the pun) of items on the board that need to be
reset at the same time.

2b.  Sometimes (particularly when I have a host processor on the board
that configures the FPGA) I want to have different parts of the board
reset based on different criteria.

3.  I also have extra voltage rails that need to be monitored, and
these rails aren't connected to the FPGA.  An external reset generator
is required to monitor those rails.


If FPGAs had an on-die reset generator that
- was guaranteed to work for all ramp rates
- was guaranteed to work for non-monotonic ramps
- could monitor 3-4 additional voltages
- had a guaranteed 2% voltage tolerance or better
- had threshold voltages I can set (or determine by resistor ratios)
- had a dedicated reset output to drive other parts of the board,

I would use it.  Until then, I will use cheap, reliable, external
reset generator devices.


Regards,
Allan


>After the product has loaded the configuration, and has completed the
>start-up sequence, then everything is in a known state, so a reset isn't
>even required (it is implicit in the starting values you placed in the
>registers in your VHDL or verilog code, and was part of the loaded
>bitstream).
>
>If at some time later, you want to return to a 'known good state', which
>we will call "reset" for no better reason than it describes the action
>you want to take, then the applications note (or the old Tech X) details
>all kinds of ways to do this, that work.
>
>Austin

On Thu, 17 Jan 2008 13:26:53 +1100, Allan Herriman
<allanherriman@hotmail.com> wrote:

>On Wed, 16 Jan 2008 10:22:39 -0800, austin <austin@xilinx.com> wrote:
>
>>G.
>>
>>How one starts the configuration process is a different problem that how
>>the device after configuration, starts up.
>>
>>The first problem is often caused by people "not trusting" the internal
>>Power On Reset circuits in the FPGA:  bad.  We spend an immense amount
>>of time making sure the POR circuits work under all sequences, and all
>>ramps from 2us to 50ms.  Mess with this, and then you have to do all the
>>engineering for three power supplies to make it work at least as well as
>>we already did.  Not a smart move.  Why would anyone want to re-invent
>>this wheel?
>
>There are a few reasons why you would want to re-invent that wheel in
>a practical product:
>
>1.  "all ramps from 2us to 50ms"  
>It may be impossible to guarantee the 50ms end of that, particularly
>in mains powered circuits.  If there is a slow brownout, an external
>reset generator with accurate thresholds *will* result in a more
>reliable design.
>
>2.  I find that my designs rarely contain just an FPGA.  I have a
>whole host (sorry about the pun) of items on the board that need to be
>reset at the same time.
>
>2b.  Sometimes (particularly when I have a host processor on the board
>that configures the FPGA) I want to have different parts of the board
>reset based on different criteria.
>
>3.  I also have extra voltage rails that need to be monitored, and
>these rails aren't connected to the FPGA.  An external reset generator
>is required to monitor those rails.
>
>
>If FPGAs had an on-die reset generator that
>- was guaranteed to work for all ramp rates
>- was guaranteed to work for non-monotonic ramps
>- could monitor 3-4 additional voltages
>- had a guaranteed 2% voltage tolerance or better
>- had threshold voltages I can set (or determine by resistor ratios)
>- had a dedicated reset output to drive other parts of the board,
>
>I would use it.  Until then, I will use cheap, reliable, external
>reset generator devices.
>
>
>Regards,
>Allan

P.S.  I apologise if that sounded overly critical.  Still, I think my
points are valid for the sorts of boards I design.

Regards,
Allan

>1.  "all ramps from 2us to 50ms"
>It may be impossible to guarantee the 50ms end of that, particularly
>in mains powered circuits.  If there is a slow brownout, an external
>reset generator with accurate thresholds *will* result in a more
>reliable design.

That's the reason that jumped out at me.

There is an easy way to get ugly brownouts.  Just turn a system back
on shortly after you turn it off.  (Been there, done that.)

Brownouts are ugly.  Basically, you need the power-watcher system
to generate a reset before the power goes out of spec.
The power-up reset generator just doesn't cover that.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Allan,

OK, I do not disagree.  I just wished to point out that we have already
done an immense amount of work, and the only reasons why you would need
an external reset are those you bring up.

Austin

Hall,

Good point:  we do cover some brown-out, but that can only be done only
so well (there is no way to be precise enough to cover all possible
brown-out scenarios).

There are power supply regulator chips that provide a "power good"
signal, and if brown-out is possible (as in: you can not specify your
primary power supply quality) then you will need a "power good" signal
from your power supply.

See "power central" for vendors that Xilinx approves, and works with.
Many of these have products with "power good" features.

http://www.xilinx.com/products/design_resources/power_central/

Austin

On Jan 16, 10:22 am, austin <aus...@xilinx.com> wrote:
> G.
>
> How one starts the configuration process is a different problem that how
> the device after configuration, starts up.
>
> The first problem is often caused by people "not trusting" the internal
> Power On Reset circuits in the FPGA:  bad.  We spend an immense amount
> of time making sure the POR circuits work under all sequences, and all
> ramps from 2us to 50ms.  Mess with this, and then you have to do all the
> engineering for three power supplies to make it work at least as well as
> we already did.  Not a smart move.  Why would anyone want to re-invent
> this wheel?
>
> After the product has loaded the configuration, and has completed the
> start-up sequence, then everything is in a known state, so a reset isn't
> even required (it is implicit in the starting values you placed in the
> registers in your VHDL or verilog code, and was part of the loaded
> bitstream).
>
> If at some time later, you want to return to a 'known good state', which
> we will call "reset" for no better reason than it describes the action
> you want to take, then the applications note (or the old Tech X) details
> all kinds of ways to do this, that work.
>
> Austin

No offense, but after being burned by power-on reset(s) in chips more
than a few times, it's very difficult for me to trust them.  Some may
call this superstition, others may call it experience.

I prefer that the system come out of reset when *I* want, not when it
thinks it's ready.

$.02,
G.

<ghelbig@lycos.com> wrote in message 
news:f58dbc55-6061-4f25-a999-61975f1fc570@v67g2000hse.googlegroups.com...
>
> No offense, but after being burned by power-on reset(s) in chips more
> than a few times, it's very difficult for me to trust them.  Some may
> call this superstition, others may call it experience.
>
> I prefer that the system come out of reset when *I* want, not when it
> thinks it's ready.
>
> $.02,
> G.
>
Hi G.,
Do you have any specific details of reset problems for any of the number of 
designs you refer to where the problem was the FPGA's not loading reliably? 
I'm sure we'd all like to avoid that if possible, and could benefit from 
your experience.
Thanks, Syms. 

G,

I understand.  I understand perfectly.  I spent years designing telecom
equipment, and for much of that time, I didn't trust anything, except my
own power on reset solution.

Along came a Dallas Semiconductor POR chip, and I used it everywhere.

One place I never used it, was for the PROG pin of the FPGA:  the FPGA
(Xilinx, of course) was much better at "knowing" when it was OK to power
on, and configure (or power down, and go stupid -- tristate all IO).

I mention this, because when I would force the FPGA to do my bidding,
the product then failed the power on tests that AT&T had specified.  I
passed when I let the FPGA do what it was designed to do.

That is my experience,

Austin

Allan Herriman wrote:

> ... Until then, I will use cheap, reliable, external
> reset generator devices.

Well said.
Industrial systems have to just work.
Reminds me of a certain fireworks controller.
Let's see, ah yes:

"It stopped, they rebooted it,"
"They rebooted it a second time." But it didn't restart."

http://blogs.king5.com/archives/2008/01/computer_glitch.html

         -- Mike Treseler