Basic FPGA question about Reset

Hi Jey,

No, you can't set this in the UCF. However, in most FPGAs, the state of the design is set to a known state on configuration, usually in the source code. At other times, you must have an input somewhere to initiate reset, correct?

Also, I suggest this link.

HTH., Syms.

p.s. It looks like the Xilinx techxclusives have been resurrected as white papers.

Hi Jey, Does this reset only happen once? I.e. at configuration time? Cheers, Syms.

Thanks for your comments Symon. I have a design where a reset signal is required for lets say some clock cycles to initialise the status of my design. So I wonder how this can be done easy? Having an own reset module is probably also a little bit akward, isnt it?

cheers!

Jey;

You could use a separate chip to reset the FPGA, such as a one-shot or a voltage supervisor that has a reset push button input. HTH

-Dave Pollum

Thanks Dave, was some sort of hoping that there is any simpler way as that I could do it without an additonal hardware source. It there a way to do that with Chipscope? Maybe with a VIO core?

Cheers,

Yes!

The tech-X's were scrubbed, and polished, and the more useful ones will re-appear in the coming months as white papers.

If someone REALLY wants an old tech-X, email me, as we have retrieved the tape, and placed the old web pages on an internal server as a means of supporting folks.... (I know, it isn't like this shouldn't have been done in the first place, well, let us just say 'a lesson learned."

Aust>> Hi

Why not use a counter? The counter gets set to 0 at configuration, and counts up after that until it gets to whatever value you choose. The reset signal can be keyed from the count value. I usually like using an on-board power-on-reset chip, but if you can't do that, this is another way.

signal reset_shifter: std_logic_vector(5 downto 0) := "00000"; signal synchronous_reset: std_logic;

...

process(clk) begin if rising_edge(clk) then reset_shifter

I have seen a number of designs where unpredictable operation (particularly FPGA's not loading reliably) was traced to a sloppy reset circuit.

You should use a reset circuit external to the FPGA. There are many makers of suitable devices, they are often listed as 'microprocessor supervisors'.

They are typically in the half-dollar price range, and make it easy to generate a proper reset.

G.

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

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.

1. 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

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.

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.

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

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."

-- Mike Treseler