Async reset

Hello all,

I have a general question regarding asynchronous and synchronous resets. Does an async. reset slow down the speed of a circuit? Is it better to use a synchronous reset, or if possible no reset at all to speed up a design? I'm just curious as I have a larger project which has a single async reset to a lot of different blocks using the typical:

if (reset = '0') then ... elsif (rising_edge(clk)) then ... else ... end if;

Not all block require the reset since they are downstream of earlier ones with a reset and their state isn't critical, I have just always included them. That being said I want to speed up the design, and in one block I took out the reset and it seemed to boost the performance slightly.

Any comments would be appreciated.

Jason

Reply to
Jason Berringer
Loading thread data ...

If the target logic has an asynchronous reset, which I believe all FPGAs have, then it is already there and all you need to do is wire it up.

Synchronous reset will be done using logic resources. It might be that there are enough CLB inputs not to add more, though it might need another column, depending on the function.

A separate question is that asynchronous reset needs not to be too close to the clock edge, so it might need to be synchronized (even though not synchronous).

-- glen

Reply to
glen herrmannsfeldt

If you are using Xilinx FPGAs then they have a nice techxclusives article about just this.

formatting link

Reply to
Prasanth Kumar

"Jason Berringer" wrote

I guess synchronous reset need extra logic, so it may speed up a little if you use asynchronous reset.

Yes, it is possible to have no reset at all in an FPGA since FPGA will automatically clear all FFs inside the chip during downloading from the bitstream. However, not having the reset will make it harder to simulate since some simulators require all the FFs to be resetted before you can do any simulation. Moreover, what would happen when for some reason your FFs go to undesired state, then you can not get out of the loop!

There are some articles regarding sync vs async at

formatting link

Hendra

Reply to
Hendra

For standard cell based designs, flops without async resets are almost always faster than the ones which do (and they are smaller as an added bonus), so if you don't need them don't use them. For FPGAs, when programmed not have an async reset a flop might have a different clk to Q delay (or a faster setup) which would make the design faster. One method would be to use async resets only for the registers which you know would need them and then add the ones later if you have to. Of course you should never let an async reset reach a flop without being synchronized to its clock, at least the release of the reset signal. Not doing so would cause unmentionable heart-ache in a real-life design.

Reply to
m

I'd like to point out that async resets aren't free in all FPGAs. I've been producing reset-free designs for years in the Xilinx parts having started with reset-free designs in Altera.

The FPGAs have power-up states that are or can be predefined to specific values. The S/R pins can be used as *either* sync or async but cannot be used as both. There are no resources needed for a synchronous reset above and beyond what an asynchronous reset uses in those devices. What about when the system goes haywaire and the device needs to be reset? If the system is in need of serious reset, just reprogram the part.

Some logic can be sped up by using the integrated synchronous S/R functionality as long as your synthesizer knows how to use it. Synplify does a great job of adding additional logic through the S/R ports often providing a slightly shorter path in timing sensitive designs. The one negative from this practice is that the S/R logic integration tends to be more widespread than I would like, typically locking out the adjacent register in a slice from use; both registers need the same S/R, clk, and CE signals.

How does more logic get in through a set/reset? The FDR primitive can be used as an OR gate (Q = D & !R where the inversion is free) and an FDS can be used as an OR gate (Q = D | S) with the FDRS providing a little more functionality. Throw the clock enable in there and things get more flexible but keep in mind (as the synthesis does) that the reset is higher precedence than the set which is higher than the clock enable. This "logic integration" into the register has saved my designs with respect to I/O timing by allowing live signals to feed the CE, and S/R directly from other I/Os allowing a very short setup plus output time for the same clock edge. Without this functionality, getting on and off the logic fabric without global routing killed my timing.

Reply to
John_H

I disagree. In an FPGA, all flip-flops in the logic fabric (what Xilinx calls CLBs or slices) are the same. They all have a Reset input, whether you use it or not, and the clock-to-Q delay is unaffected by the way the user configures the design and uses or not uses asynchronous or synchronous Reset or Clear. Regarding the basic need for reset, Ken Chapman published an interesting (and perhaps provocative) article 3 years ago ( Oct 2001, but it is still on the Xilinx website under TechXclusives), and here is his conclusion:

"Summary "A design implemented in a Xilinx FPGA does not require you to insert a global reset network. For the vast majority of any design, the initialisation state of all flip-flops and RAM following configuration is more comprehensive than any logical reset will ever be. There is no requirement to insert a reset for simulation because nothing will be undefined. Since a Xilinx FPGA is already fully tested silicon, you won't be inserting scan logic in your design and running test vectors, so you will not need a global reset as part of this process either.

"Inserting a global reset will impact your development time and final product costs even if these factors can not be easily quantified. With the trend towards higher speed clocks and complete systems on a chip, the reliability issues must be taken seriously. The critical parts of a system that must truly be reset should be identified and the release of those resets on start up, or during operation, must be controlled as carefully as any other signal within a synchronous circuit.

As you are creating each section of your next design, simply ask yourself: "Does this bit need to be reset"? from the TechXlusives paper by Ken Chapman, Xilinx

Peter Alfke

Reply to
Peter Alfke

(snip)

I don't believe they are guaranteed to be cleared, as far as user logic is concerned. The synthesis often moves inverters around, and many signals, including ones through FF's, are actually the inverse of the expected signal. I have seen warning messages from Quartus for FF's that don't have a reset or preset input that the initial state is not guaranteed.

-- glen

Reply to
glen herrmannsfeldt

There is nothing to disagree about. I was just trying to suggest an explanation for the observed behavior. You being from xilinx, I'll take your statement over my speculation about a xilinx design.

Also there is one case where one can't really depend on an FPGA to do all the resetting for you and that's when you're prototyping an ASIC. That's my main focus right now.

Reply to
m

Hi,

I hope someone will correct me if I'm wrong on this...

For Xilinx FPGAs, all SLICE flip flops (and some other synchronous elements, too, like BlockRAM output registers, IOB flops, etc...) are initialized to a known state at the end of configuration by an internal, chip-wide async reset called GSR, or "global set/reset". It also happens to be the case that there's another signal, GTS, or "global three-state" that forces all I/O to be three-stated during configuration. These signals are not "visible" in the FPGA Editor view of the part at any place other than the STARTUP component.

If you instantiate specific primitives, like FDC or FDP, you are also making a request on how you want these to be initialized by GSR (regardless of your use of an additional, async user reset). FDC initializes to 0. FDP initializes to 1.

If you code stuff like:

reg [1:0] myflop;

always @(posedge clk or posedge init) begin if (init) myflop expected signal.

I would hope anyone doing this transformation would also change the "initialization state" of the flip flop when they also change it's sense -- otherwise the transformation is not really transparent... (I would argue it's wrong)

Eric

Reply to
Eric Crabill

While we are on the subject of asynchronous clear or initialization at the end of configuration: The problem is the non-synchronous and non-simultaneous timing of the release of this reset/preset signal, while the user clock is already running. (Sorry for the convoluted sentence). That's where state machines can get screwed up: the asynchronous (p)reset might linger a little longer on one flip-flop than on the other, and the user clock might occur during this timing difference. Bad luck! That's why smart designers identify such state machines and give them an additional, longer and synchronous reset input. An SRL16 is a convenient tool to control this delay. This subject has been covered here many times, but it bears repeatung... Peter Alfke

Reply to
Peter Alfke

In theory, it's perfectly fine not to reset a bunch of FF's if you can guarantee that a reset value will ripple through or if you really don't care about a state. In practise, we tend to reset all our FF's (synchronously, though it doesn't really make a difference) and then remove the reset for those FF's for which we can guarantee that it will get a defined state after we toggle the clock for a few cycles while reset remains asserted. We prefer not to have any FFs with an unknown condition when going out of reset. The risk is just to high that we overlook cases where we DO get into an unknown state. Reset behavior is one of the cases for which we still run a gatelevel simulation.

As for speed, a case can be made that synchronous reset will eat some of your setup time because it puts an AND port in between the functional logic and the D input. But asynchronous FFs can have slower clock-to-Q times, which may or may not compensate. You'll have to check your datasheet.

As for area: there's no fixed rule. Some libraries have FF's where the synchronous reset FFs has the same area as a similar FF without any reset at all. Again, check you databook. FPGA is another story alltogether. Check the other answers. :-)

Tom

Reply to
Tom Verbeure

Another tidbit: When Xilinx says reset or preset, we really mean that we force the flip-flop into one state or the other. None of that trickery with virtual preset, implemented by reset plus inverting D and Q (which would affect timing). Peter Alfke

Reply to
Peter Alfke

Perhaps the tools need a [AsyncReset with SyncRelease] option/tickbox, that novice users (and others) can enable ? For years in our uC products, we have used a tiny (6 byte) library that clears all user memory at power on. Saves a ton of grey hairs, and chasing erratic startup phantoms, plus eliminates chunks of InitVar code overhead.

-jg

Reply to
Jim Granville

But that does not mean that the tools won't invert the sense of a FF when they move inverters around.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Nice idea, but you still have to define the physical area to be covered. If you instantiate several independent such blocks, they might not be macro-syncheronous ( I mean: synchronous to the clock, but not necessarily to the same clock tick). And within the area covered, you cannot tolerate a control-signal delay longer than one clock period. All that makes it difficult to provide one universal library element that covers all situations and all speeds... Peter Alfke

Reply to
Peter Alfke

Understood, you clearly would need to specify the covered elements. Tho the tools could allow "all for that clock domain", and then tell the user the cost of that ?

Understood, but at these extremes, the tools should/could catch and warn on this ?

Can you give a feel, via real examples, for when the control signal delay on a "Auto SyncRelease" reset, might end up longer than one clock period ?

-jg

Reply to
Jim Granville

This is not entirely true. Xilinx Virtex and later families can have the flip-flops with either synchronous or asynchronous (re)sets, but not both unless you use the LUT for the sync reset. The wiring to the built in reset pins on the flip-flop can be connected to the global reset net. The flip-flops come up in a known state at the end of configuration.

Generally speaking (asIC prototyping excepted...maybe), it is not advisable to use an async reset in the FPGA. The issue is that the release of reset is asynchronous to the clock, so you will get a situation where some flip-flops see the release on one clock cycle where others see the release on the next cycle when the reset is released close to the clock edge. The other issue is that an async reset propagates through the flip-flop making a timing path that does not end at the flip-flop. The timing tools historically have missed this timing path (thinking back to the 4000 series tools), so there is a possibly hidden danger to using async resets as well.

As far as resett>

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

unless

the

a

My current project is with Altera ACEX, so I now looked up more exactly what it does.

It seems that they provide asynchronous CLEAR and LOAD. If you specify only CLEAR (RESET) it is fine. If you specify only PRESET it will invert the logic and use CLEAR. If you use both, it needs one LUT input (DATA3) to be used for that function. So, it is a little more efficient to invert the logic if preset is used, and in that case the global reset will act as a preset.

If neither is used, Quartus seems to be free to do it either way, and gives a warning to tell you that.

I don't see that ACEX supplies a synchronous preset or clear, so I believe that would be done through LUT logic.

It would seem that one should know the details for the logic family being used.

-- glen

Reply to
glen herrmannsfeldt

unless

the

a

use

see

when

async

at

to

I think advising against using an async reset is a bit strong. With attention to the issue, an async reset will work just fine. You just can't assume that all FFs will be released on the same clock edge.

As to the timing issue, that timing condition applies to the assertion of the reset. If you are using the async input to reset the entire chip, I don't think the propagation time is an issue.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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.