1. Home
  2. Field-Programmable Gate Arrays
  3. Oh no! Resets Again? Yes, but it could be important.

Oh no! Resets Again? Yes, but it could be important.

Important if you need your designs to cleanly reset every time.

Apologies, but many folks are still post "I use exactly this template of three top procedures in every new design entity:

begin -- process template if reset = '1' then init_all_regs; -- no port init required elsif rising_edge(clock) then update_process_regs; end if; update_output_ports; -- wires ok for reset or clk end process template; " This is only the most recent example, and seeing this asynchronous reset code over and over again is starting to worry me, particulary considering that some FPGA's may be in critical environments, where cleanly coming out of reset is vital.

Xilinx[Ken Chapman] suggests this is not the most efficient strategy for LUT utilization in

formatting link
Ken cheats a bit in his article (he re-works an async reset to be sync to get a more compact circuit, but the behavior of the smaller circuit is different than the original!), but overall he has a good point. And there is a stronger reason to write your code to reset synchronously. The following is quoted verbatim from the Xilinx Constraints Guide (cgd.pdf), in the Timing Constraints section:

"The tools do not automatically analyze asynchronous set/reset paths." (I assume tools means Map/Place/Route)

This bears repeating. "The tools do not automatically analyze asynchronous set/reset paths."

Following that scary statement is a reference to the "Enable" and "Disable" constraints, which control timing checks over these two paths (among others):

"Asynchronous Set/Reset to output propagation delay" and "Synchronous Set/Reset to clock setup and hold checks"

But lo and behold! There is NO checking (according to cgd above) of the path:

"Asynchronous Set/Reset to clock setup and hold checks"

(I like the convention of calling "async reset" clear, and calling "async set" preset, leaving set/reset for the sync functions, and will try to stick with that for the rest of this discussion)

The clear pin may be released at various registers in a process with uncertain timing relative to clock, _even_ if the clear signal started out synchronous. This has the same potential for trouble as any other async input to a synchronous state machine, because clear is just another input after all. A one-hot state machine can go no-hot or many-hot; a binary coded (non-Gray) SM may enter an illegal state; or see Ray's counter example (which is _not_ a counter-example) at

formatting link
These are not good things.

I've modified my style to ALWAYS reset synchronously, using a sync reset (with considered exceptions for certain unique circuits):

process(clock) begin if RISING_EDGE(clock) then if reset = '1' then init_regs; -- the ones that need it. else [elsif enable = '1' then] -- I like this form, it's free update_process_regs; end if; end if; end process;

Sure, it means that reset has to be synchronized somewhere, and (egad, worse yet!) typing an extra "end if" and indenting a level deeper, but this is a small price to pay for designs that start up first time, every time.

To quote Ray: " Generally speaking, asynchronous resets are a very bad idea in FPGAs." Because this might be mis-interpreted, I'd clarify that and say even synchronous resets, if used as a clear function, are a bad idea. Write code to reset synchronously. Keep clear of that clear pin.

Regards to all, John

Reply to
JustJohn
Loading thread data ...

"JustJohn" schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...

Do you want to take the fun out of the world of electronic design ?

Our evolution is try and error. Do you want to hinder our evolution ? Do you want to take the exitement out of our lives ?

And Frankly, every modern (since the Wintel revolution) user of any electronic device will "reboot" it until it works without worrying. I've already adapted this behaviour subconsciously. I also experience a much higher rate of failure during operation of electronic devices.

Raymund Hofmann

Reply to
Raymund Hofmann

You can turn this on the UCF. Every UCF I have ever written has contained the lines:

# magic incantation to make the tools trace timing through reset paths ENABLE= reg_sr_q;

Regards, Allan

Reply to
allanherriman

Without seeing the rest of Mike's code, I would be willing to bet that "reset" is in fact the Xilinx power on reset. This reset is going to happen in the actual hardware asynchronously whether you like it or not. All Mike has done (I assume) is to explicitely code the actual behavior of the builtin Xilinx hardware. This is in fact a perfectly reasonable thing to do, and I also insist on all VHDL code I control explicitly show asynchronous POR behavior, in the same way.

If a particular part of the circuit needs a synchronous reset, then that is simply added to the synchronous part of the process. That is a completely separate issue from POR.

Reply to
Duane Clark

This is interesting Allan...

I did read the docs, that's where I quoted from. Are you saying that ENABLE= reg_sr_q; which provides timing coverage for paths including:

1) "Asynchronous Set/Reset to output propagation delay"

will eventually somehow undergo a transformation into a check for paths including:

2) "Asynchronous Set/Reset to clock setup and hold checks"

Because I am not talking about a reset -> output issue, This is a matter of set-up/hold. Another Enable/Disable constraint, reg_sr_clk, as listed in Tables 7-1 and 7-2, gives path checking for

3) "Synchronous Set/Reset to clock setup and hold checks"

but 3) is clearly different from 2). Do you see the difference I'm suggesting?

Either my reasoning is totally kaflooeey, or the Xilinx documentation is fairly misleading and should be changed to something like:

Enable = reg_sr_clk; implies

4) Any (Synchronous or Asynchronous) Set/Reset to clock setup and hold

It might be nice to have someone from Xilinx weigh in on this.

Regards, John

Reply to
JustJohn

This bears This bears This bears This bears This bears

Anyway, two things:

1) Do you guarantee a power-on reset either by always asserting the reset pin or through constraints?

2) What if your system is in an environment where the clock is stopped during your reset event?

Power-on states are guaranteed by the asynchronous reset. Those of us who try to keep away from async resets MUST make sure there isn't an erroneous power-up state that confuses our logic OR guarantee that everything has the synchronous reset applied before the circuit affect the rest of our system.

Reply to
John_H

Quite possibly. It wouldn't be the first time Xilinx software did something completely contrary to the documentation. At least reg_sr_q is mentioned in the documentation now (it wasn't always).

I'm a bit confused as to why you would attempt to use async resets to implement logic functions that are better handled by synchronous resets. At least with synchronous resets you can know that the results will be reliable. If I caught any of the designers here trying to use async resets that way they would get a stern talking to.

Any reasonable FPGA coding guide should strongly advise against using async resets or sets to implement logic functions. (At least for Xilinx) async resets should only be connected to one net, and that net should be connected to the reset input of a startup block. Any other usage should be illegal. You should use a well known name for that net as well. Here we use the name 'gsr'.

Such guidelines are based upon studies made of non-working designs and failing projects over many years. You can ignore them at your peril.

Allan

Reply to
allanherriman

HA HA HA, Thanks for the smile this morning, I was up late last night when I made that post, maybe got too long winded.

Hmm, to answer both John and Duane, I was talking about an individual reset for an entity, that may be asserted individually to that entity, separate from others in the same design and not "globally" across the chip, as a power-on reset. Perhaps code examples here in c.a.f. can make the distinction, and generally use 'por' for power-on resets, and 'rst' for not necessarily global resets.

Personally, I admit to being a little lazy, and writing code so that power-on state is irrelevant for most of the the system, except in one place where a rst event is guaranteed to be generated. That rst does the real work, and does not depend on the whether the FPGA has a por or not.

I'll duck this for now and say that's one of the "considered exceptions for certain unique circuits". Hey, it's Saturday morning, and a bright and sunny day here in southern California. Time to get outside.

Reply to
JustJohn

Apologies to you Allan, I was not trying to confuse you, and I would NOT attempt such a thing, this was exactly the point of my post! Xilinx docs say they don't check clock set-up for asynchronous reset input, and yet, time after time, people post examples of async resets, which will lead the unwary into trouble. As I said on the other thread, it's a nice day out, time for a walk...

Reply to
JustJohn

I started out using TTL parts. They (usually) didn't specify setup times of async inputs with respect to the clocks. Propagation delay (async reset -> Q) was the only timing parameter specified. (I just checked the data sheet for a SN54AHC74, it seems these parameters are specified in more contemporary devices.)

I feel this is more about educating newbies than blaming Xilinx for faults in their tools. Surely schools teach ... wait, I can remember my classes (a long time ago) and they didn't even touch on this sort of thing.

(I'll follow your lead and take a walk outside now.)

Regards, Allan

Reply to
allanherriman

My code template assumes one global reset pulse that occurs once, on a low-skew path, after the fpga image has loaded. I also assume that this pulse has a source external to, but using the same clock as the fpga. In my case, it comes from a cpu that loads the binary fpga image.

I don't use vendor-specific resets because they are vendor-specific.

The reason I use this "asynchronous" style template is that it saves logic cells in every synthesis benchmark I have run on both brands A and X.

In summary, I use one synchronized reset pulse, on a low skew path to the asynch reset input of every D-flop in the design.

I expect that this template will work for me as long as fgpa vendors keep global routing and asynch resets on D-flops.

I will update my code examples with these comments.

-- Mike Treseler

Reply to
Mike Treseler

Is that good enough?

Don't you also need the prop time on that low-skew path to be short enough relative to your clock cycle time so that you know when it gets to your FFs?

Last I checked, the global reset on most Xilinx parts was too slow to be useful in that context.

I thought that consensus here was to use the global reset hardware to (asynchronously) force your state machines into a known state and then use a local FF that has been synchronized to get out of that state.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

It has been in many cases.

For the trailing edge, yes. On the board, a zero delay clock buffer and careful distribution to all devices does the trick. On the fpga I just have to make sure the reset node gets one of the global nets.

Yes. I don't use anyone's the built-in reset.

I don't think I'm contradicting that idea. The asynch reset gives you a starting point for simulation. After this, well-designed control logic will use an idle state for specific synchronous initialization.

-- Mike Treseler

Reply to
Mike Treseler

Aaahhh, thanks Hal, _very_ nicely put, succinct and clear. (It's been a while since those discussions, I turned 50 last month, and have been working in the wonderful world of M$ GUI design lately, so forgive me for forgetting).

Integrating everyone's good words with Mike's generic process template and my desire for an entity local reset into pseudo VHDL:

process (clock, gsrout) begin if gsrout = '1' then init_all_regs; -- Every darn one of them init_state_regs; -- To a 'dormant' reset state elsif RISING_EDGE(clock) then if reset = '1' then init_some_regs; -- Only ones really that need it, -- both to reduce routing req's, -- and because it may be useful -- to keep some values across -- a reset event init_state_regs2; -- To an 'awake' reset state else -- No enable form [elsif enable = '1' then] -- Using enable form run_reg_logic; -- And they're off to the races run_state_logic; -- (oops, bad word, no races here!) end if; end if; end process;

Signal gsrout comes from the Xilinx 'STARTBUF_arch' primitive, so that the async device clear does not take FF pins or routing. (Mike may not like this vendor specific stuff, see my parting question)

Googling back to June reveals a 'roller'

formatting link
who asked about _not_ using this format. Nobody answered then, but after going through this exercise, I would say this is a fairly solid template, don't use it at your own peril.

Ok, I'm done, except for one last question... does Altera have a similar GSR function? (Please pardon my laziness)

Thanks all,

John

Reply to
JustJohn

You're right, Mike; the async reset is helpful for simulation. Looking back at my recent designs, I see a pattern. All of my state machines have a safe reset state. A slow reset (where some of the state flops reset before others) on a one-hot machine decodes as an illegal state so the machine automatically bounces to the reset state. Once everything is reset then the machine synchronously transitions to an "idle" state where it stays until other logic tells it to do something interesting.

For things like loadable registers, the power-on reset is helpful, and the usual template of

myreg : process (clk, reset) is begin if (reset = '1') then register

Reply to
Andy Peters

Mike, All, Yep. I use the same template as you. Every process has the same async reset and is used *only* in functional simulation. Startup in real life is taken care of by the FF initialisation on configuration. Any extra resets needed after startup are synchronous. The exceptions are when I want to infer SRLUTs, distributed RAM etc. In this case the template misses out the async reset, as it is not supported by the hardware. Cheers, Syms.

Reply to
Symon

Heiner Litz wrote me personally:

following verilog statements:>

Hello Heiner,

I don't use Verilog on a regular basis (yet), and have not built up a repertoire of the natural forms of expression to produce solid results in that language. Since you wrote my personal address, I'm reposting this to c.a.f. for comment by others.

My original point is that the place/route tools do not analyse clock setup and hold paths through an async reset. Here's what can happen in the case of a state machine that gets synthesized and expressed in one-hot format (I'm sure this has been described before):

Assume the state machine starts changing states immediately after reset is removed. In one-hot form, there will be a FF, call it FF_rst, corresponding to the reset state, which is set to 1 by the reset. The first state FF after reset, call it FF_st1, will be set to 0 by reset. If working correctly, at the first clock edge after reset is removed, FF_rst -> 0, and FF_st1 -> 1. Now it is 99.99% (really, 100%) guaranteed that the delay of reset to FF_rst will be different than the delay to FF_st1. Assuming the reset delay is shorter to FF_rst, there is a timing window where the clock can transition such that FF_rst -> 0 because reset is not active there, but FF_st1 stays at 0 because reset is still asserted there. Voila, you've entered no-hotville. At the next clock edge, when reset has finally de-asserted at FF_st1, still nothing happens, because FF_st1 needs to see FF_rst = 1 in order to set. There's no road out from no-hotville. If that timing window is larger than your clock period, the SM will never start up. If that timing window is really small, you can get a design that works 99.9 % of the time and fails (by Murphy's law) when you really need it.

People often don't travel this road, because state machines sit in reset waiting for some other synchronized signal to leave reset, as described by Andy, and this is perfectly legitimate. So no _single_ template fits every situation. As Syms says, SRLs and RAM based registers can't have any reset in code that infers them. It is important to distinguish between a global async reset and distributed sync resets.

Ah-hah!, looks like there is a back door out of no-hotville. XST has a couple of new constraints on FSM expression: 'safe_implementation' and 'safe_recovery_state'. I haven't played with these yet, so don't know how much netlist inflation they produce, but if you (Heiner) want a quick and dirty way to imunize state machines from async startup woes, without having to modify any existing code, you might try these. I'm not advocating relying on these as a fix for final release, but they might be a tool to help show that a SM might be getting off track, and that you need to look deeper into your code. I would suggest them for final release if you have SEU concerns (provisionally, I haven't looked at their output yet).

Has anyone any experience with these constraints they'd like to share? Do any other synthesis tools support them?

Regards all, John

p.s. I rely on Google for my c.a.f. browsing/posting. I'm glad they've sped up their posting, I was finally able to participate in real-time with a discussion here (formerly, they had a half day wait from posting to appearance). Google makes me put my real address in, but please try to refrain from writing me directly on thread topics, I feel guilty if I don't have time or inclination to respond.

Reply to
JustJohn

How about using a bufgce instead of a bufg and gate off the clock during and sometime after async reset?

-Lasse

Reply to
langwadt

Can be done with care, but there's a chorus of "don't gate clocks in an FPGA" as a general design practice.

See e.g.

formatting link
for an answer record containing the caveat:

"CE must not change during a short setup window just prior to the rising clock edge on the BUFGCE input I. Violating this setup time requirement can result in an undefined runt pulse output."

The list of "ways to do it wrong" is far larger than "ways to do it do it right", and even the do it right list can have some ways to do it wrong as a subset.

Reply to
JustJohn

Assuming that you're talking about Static Timing Analysis tools (as opposed to P&R), this is not true in general. Definitely not true for standard cell flows and even in case of FPGA case, if you set the right parameters, it's not true. You maybe hiding it by not constraining your external reset pin with the clocks of the flops it arrives at. You can get around this by driving your async reset input of flops with a synchronized version of your reset pin. This way your internal reset signal is sourced by a clock and it is also helpful in that it reminds you to do this for every clock domain where reset is used.

Reply to
m

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.