UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
454 Views
Registered: ‎04-12-2012

Impact of design wide asynchronous resets on performance

Jump to solution

Hello,

In the past I've been taught (as a good design practice) that every DFF in my FPGA design should have an asynchronus reset.

The actual reset I'd use will come from a central "asynchronus assert - synchronus deassert" reset circuit that will feed all the DFF's in the specific clock domain.

 

However, in the last years I came across some Xilinx educational material that discourages the use of resets in a design whenever possible.  And If absolutely required a synchronous reset is suggested instead of the DFF asyncrhonous reset.

 

Questions:

1. Is there no dedicated routing of asynchronus resets to the DFFs ? If there is - why not use it ? Is the high fanout such a big problem ?

2. As I see it, an asynchronous reset is a function inbuilt in the silicon of the DFF, while a synchronous reset is essentialy a MUX on the datapath implemented in general purpose FPGA fabric...if my assumption is correct - wouldn't such a MUX decrease performance compared to an asynchronous reset ? 

1 Solution

Accepted Solutions
144 Views
Registered: ‎01-22-2015

Re: Impact of design wide asynchronous resets on performance

Jump to solution

@shaikon 

    But what about the fact that a synchronus reset is essentialy a MUX on the datapath ?
I see where you’re going with this.  We could really rock the reset-boat if the answer to this question were in favor of asynchronous resets. 

Below is a circuit from Vivado implementation (clk=85MHz) showing a reset-bridge feeding both the asynchronous-reset of a FDCE and the synchronous-reset of an FDRE.  If there is “essentially a MUX (or something else) in the datapath” then it is Xilinx proprietary information (as Avrum suggests), since Vivado is not showing it.
resets.jpg

I tried to peek under the hood of the proprietary design by looking at the timing reports generated by:

  report_timing -to [get_pins adat_reg/CLR] -setup
  report_timing -to [get_pins sdat_reg/R] -setup
 --
  report_timing -to [get_pins adat_reg/CLR] -hold
  report_timing -to [get_pins sdat_reg/R] -hold

-and got slack values of 10.814, 10.727, 0.372, 0.315.   No smoking guns, I think.

So, I can’t answer your question – but I had fun trying.

Finally, just to keep the reset-boat rocking, <here> is a paper by a very respected digital wizard, Clifford Cummings, who concludes that asynchronous-resets are the way to go.  I didn’t have the courage to read any more of the paper than his conclusions.

 

17 Replies
Scholar drjohnsmith
Scholar
405 Views
Registered: ‎07-09-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

Sorry, if were talking sram based FPGAs like xilxin , then yo uhave been taught wrong.

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

https://www.xilinx.com/support/documentation/white_papers/wp275.pdf

 

0 Kudos
Scholar dpaul24
Scholar
395 Views
Registered: ‎08-07-2014

Re: Impact of design wide asynchronous resets on performance

Jump to solution

@shaikon,

I would also recommend reading the two papers stated above. It has helped me a lot, clear doubts & misunderstandings.

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Scholar drjohnsmith
Scholar
389 Views
Registered: ‎07-09-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

To answer directly,

why no large asyncronous reset circuit built into fpga,  because its large , uses up silicon, and is not needed.

Flipflops can ever be syncronous  or asyncronous set / clears, cant have one as syncronous , one asyncornous, without using extra logic. As rest of design is syncronous, only having an asyncronous reset would cost extra logic to impliment,

Reset still needs to meet set up // hold requirments. The bigger a net is across a chip, the slower it is. So a big reset becomes your speed limitation, ans is not needed, so a waste.

 

 

0 Kudos
Explorer
Explorer
367 Views
Registered: ‎04-12-2012

Re: Impact of design wide asynchronous resets on performance

Jump to solution

Hello drjohnsmith,

You say:

why no large asyncronous reset circuit built into fpga,  because its large , uses up silicon, and is not needed.

Flipflops can ever be syncronous  or asyncronous set / clears, cant have one as syncronous , one asyncornous, without using extra logic. As rest of design is syncronous, only having an asyncronous reset would cost extra logic to impliment,

But according to page 9 Xilinx's UG974 - SDR DFFs can be configured as either FDRE & FDCE. Can you explain what "additional logic is required" ?

 
0 Kudos
Scholar drjohnsmith
Scholar
348 Views
Registered: ‎07-09-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution
because most logic design is syncronous,

and the word is either "syncronous or asyncornous"

so if you have the register with asyncornous reset,

you have to have an asyncronous register,

then you lose the ability to use the syncronous reset or preset ,

so the logic has to make another feedback term,

Old ASIC worlds , asynchronous reset was common, but even that has gone , and only the bits that "need" resetting are reset,

and that in FPGAs is always syncronous,

thats where desing skill comes in,

BTW: the reason in fpgas, is till they are configured, your reset has no effect ( as no logic in the FPGA ) . When FPGAs are configured , ever register is defined as 1 or 0, depending upon your design.

Its only after the configuration has finished , and the on chip MMCM clocks have stabilised, then you can do things with the registers.

Remeber it could be hours / days before an FPGA is configured after power up, its up to the circuit as to when it starts ,
and by the time the configuration has finished , the on board power up reset will have well passed.

Thats also why reset is always active high. Till the FPGA is configured, no external signal will have an effect, so inside the chip, just make all control signals active high.


Explorer
Explorer
332 Views
Registered: ‎04-12-2012

Re: Impact of design wide asynchronous resets on performance

Jump to solution

Your statement about "asynchronous reset cosuming more silicon" is inaccurate.

All that choosing between asyncrhonous and synchronous reset does is limit all the DFFs in a slice to the same control set (either all synchronous or all asynchronous reset).

A design consisting of 15000 FDCE registers all asynchronously reset should consume the EXACT silicon footprint compared to a design consisting of 15000 FDRE registers all synchronously reset.

If you start mixing asynchronous and synchronous resets the picture will change. But this is a special case that should be avoided.

 

 

0 Kudos
Highlighted
304 Views
Registered: ‎01-22-2015

Re: Impact of design wide asynchronous resets on performance

Jump to solution

I believe that reset handling is one of the greatest unanswered (and at same time over-answered) FPGA questions.  I say over-answered because there are many opinions but seemingly no general agreement.

Much of the disagreement stems (I think) from not distinguishing between initialization and reset.

In VHDL, we can initialize signals and variables when they are declared as follows:

  signal my_bit : std_logic := '1';
  constant my_one : std_logic := ‘1’;

These initializations happen during configuration of the FPGA and are associated with the GSR/GWE signals.  However, UG470(v1.13.1) says below Table 5-12 that, “GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique.” 

I interpret the GWE comment from UG470 to mean that the initialization associated with configuration is not to be relied upon.  In <this thread> you will find an interesting discussion between Avrum and markcurry, where markcurry ends up saying “(more often than many presume, IMHO) configuration != reset.

The discussion about initialization vs reset continues in <this thread> where Avrum, markcurry, and I end up concluding that a custom-crafted power-on reset is needed because you cannot solely rely on GSR/GWE.

With these things in mind, I think that the much-read Xilinx document, WP272, is reckless not to mention the problems with GSR/GWE initialization.

However, I find that this <EETIMES article> by a Xilinx employee describes a practical and intuitively appealing power-on reset strategy that overcomes the problems of GSR/GWE initialization.  This strategy is summarized nicely by the following Figure from this article which also describes the importance of the reset-bridge (aka async reset synchronizer).
Reset_My_FPGA.jpg

A concept that many seem to agree upon is that resets are overused.  It is absolutely not necessary to reset every flip-flop in the FPGA at power-on.  Page 45 of UG949(v2019.1), says: “RECOMMENDED: Evaluate each synchronous block, and attempt to determine whether a reset is required for proper operation. Do not code the reset by default without ascertaining its real need.”.  On the same page, UG949 also says, “Functional simulation should easily identify whether a reset is needed or not.”, which I have found to be a good guide.

There are no dedicated routing resources in the FPGA for resets.  That is, resets are normally routed through the FPGA as ordinary signals.  Although, as described on page 36 of UG472(v1.14) it is possible to route resets through the FPGA clock tree in 7-Series devices, since the clock tree can directly drive CLB control pins like SR and CE.

Contrary to what some believe, the deassertion of a reset at a flip-flop undergoes timing analysis for both synchronous and asynchronous resets.  As described in UG906, this part of timing analysis is called recovery/removal and is analogous to the setup/hold analysis for ordinary signals.

Finally, there is much good reading about resets in Xilinx document UG949(v2019.1), especially on pages 44-74.

Mark

Explorer
Explorer
275 Views
Registered: ‎04-12-2012

Re: Impact of design wide asynchronous resets on performance

Jump to solution

Thanks a lot for your input Mark.

The EETIMES article indeed takes a much more cautious approach vs WP275.

I still have one question remaining:

Suppose we made a thorough design analysis of clock domain X and determined that N flip-flops in that domain can't rely on the GSR inialization and require an explicit reset.

We implemented a reset bridge (as shown in figure 4) and we're ready to connect the bridge's output to our N flip-flops reset input.

Is there a very good reason why (besides slice saving via control set reduction) we should connect to the Syncrhonous reset pin (FDRE) instead of the Asyncrhonous reset pin (FDCE) ?

0 Kudos
235 Views
Registered: ‎01-22-2015

Re: Impact of design wide asynchronous resets on performance

Jump to solution

..continuing:
I work at a company that designs/builds microwave systems – often high-powered radar.  Mostly for reasons of safety, we never let the FPGA boards controlling our systems to just “power-up and go”.  That is, we’ve created careful power-on reset strategies that can take upwards of 20 minutes to complete.  During this 20-minutes, we are talking with the FPGA board – sending system configuration parameters, checking that the configuration parameters were received correctly, checking system voltages and temperatures, etc.  Then, when all is ready and safe, we carefully release the FPGA resets and allow the FPGA and microwave system to “go”.

Now, to your question…

We implemented a reset bridge (as shown in figure 4) and we're ready to connect the bridge's output to our N flip-flops reset input.  Is there a very good reason why (besides slice saving via control set reduction) we should connect to the Syncrhonous reset pin (FDRE) instead of the Asyncrhonous reset pin (FDCE) ?

Writing HDL that efficiently uses FPGA resources means that we must avoid the control set problem described by Avrum <here>.  Avoiding the control set problem means that we should use either synchronous-resets or asynchronous-resets – but not both.  When choosing which to use, the general rule is:

                asynchronous-resets = bad
                synchronous-resets = good

Page 76 of UG901 (v2019.1) still issues the very strong statement, “Do not asynchronously set or reset registers.”.  Fortunately, Avrum provides some balance to this strong statement with his comments <here>, saying that asynchronous resets have a small niche in the FPGA world (mostly situations where a clock is not yet “up” but a reset is needed).   I cannot add much to the small-niche comments of Avrum except to say that the reset-bridge is a really important and really needed half-exception to the “asynchronous-resets = bad” rule – because it “asynchronous-ON, synchronous-OFF”.  There is no problem routing the output of a reset-bridge to the synchronous-resets in your design as described by Avrum <here>

As I mentioned earlier, there is much special-case advice on resets scattered throughout the Xilinx documents. 

For example, page 53 of UG473 (v1.14) tells us that a reset-synchronizer (reset-bridge) has been placed inside the FIFO found in 7-Series FPGAs.  So, as Avrum explains <here>, you can safely put a timing exception on the RST pin of the FIFO and save Vivado timing analysis some work.

Another example is shown on page 46 of UG949(v2019.1) which advises us to use registers with synchronous resets for logic targeting the DSP48.  Attempting to use asynchronous reset with the DSP48 adds many extra registers(65) and LUTs(32) to the design.

A final example is shown on page 60 of UG949 which advises us not to reset memory arrays (Block RAM) – and that “only the output of the RAM can tolerate a reset”.

Historian
Historian
219 Views
Registered: ‎01-23-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

One other comment on synchronous vs. asynchronous (which is what @drjohnsmith was alluding to).

Lets say you have an explicit reset, and also have regular logic (say part of your datapath or state machine) that forces the flip-flop to 0 under certain conditions (call this the "synchronously clearing condition").

If your explicit reset is asynchronous then the reset must go to the CLR port of the flip-flop and you no longer have access to the R port (it is one or the other). So the "synchronously clearing condition" must be implemented as an AND somewhere in the up-cone of the D input.

However, if you use a synchronous reset (R) the tool now has a choice - it can put the "synchronously clearing" condition in the upcone of the D, or it can OR the "synchronously clearing condition" with the explicit reset on the R port of the flip-flop. If the timing on the path to the D input is tight, this lets the tool move some logic off the tight D input path, and move it to the (presumably) less tight R input path. This may be better (improving timing). Or it may be worse (since this now creates a new control set for the flip-flops). The point is that the tool can choose either option if the explicit reset is synchronous, but it has no choice if the explicit reset is asynchronous.

Avrum

Explorer
Explorer
193 Views
Registered: ‎04-12-2012

Re: Impact of design wide asynchronous resets on performance

Jump to solution

I see your point.

But what about the fact that a synchronus reset is essentialy a MUX on the datapath ?

Even if we follow the recommended HDL templates - the best case scenario is that the tool will infer this MUX using the DFF internal sychronous reset circuit (FDRE) without resorting to general purpose fabric. 

Nonetheless, it's still there - claiming a penalty from the datapath.

An asynchronuos reset doesn't have this MUX...so wouldn't it have better performance ?

0 Kudos
Scholar drjohnsmith
Scholar
180 Views
Registered: ‎07-09-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

@shaikon 

Can I suggest ,

you do some experiments, and colate the results and get back to us with them,

we can then all have a nice chat about your tests ,

 

 

0 Kudos
Historian
Historian
166 Views
Registered: ‎01-23-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

But what about the fact that a synchronus reset is essentialy a MUX on the datapath ?

I'm not sure what your point is here.

First, the reset would actually be an AND, not a MUX, but anyway...

When the flip-flop is set in synchronous mode (FDRE), there is a dedicated R port of the flip-flop. How this reset is accomplished inside the cell of the flip-flop is irrelevent - this port and the internal circuitry exists, regardless of whether you use it or not - Xilinx flip-flops are no slower or larger regardless of whether you use the R port or not. And I suspect (but can't prove) that any impact that may exist for the R port still exists even when the flip-flop is in asynchronous mode - the transistors inside the flip-flop don't actually change, so the mechanism whereby the R port synchrously resets the internal state is still there, it is just disabled; if your assertion is that the path from the D will go through these transistors in synchronous mode, they will still go through them even if the synchronous reset is disabled via the configuration due to the flip-flop being configured as an FDCE.

Avrum

145 Views
Registered: ‎01-22-2015

Re: Impact of design wide asynchronous resets on performance

Jump to solution

@shaikon 

    But what about the fact that a synchronus reset is essentialy a MUX on the datapath ?
I see where you’re going with this.  We could really rock the reset-boat if the answer to this question were in favor of asynchronous resets. 

Below is a circuit from Vivado implementation (clk=85MHz) showing a reset-bridge feeding both the asynchronous-reset of a FDCE and the synchronous-reset of an FDRE.  If there is “essentially a MUX (or something else) in the datapath” then it is Xilinx proprietary information (as Avrum suggests), since Vivado is not showing it.
resets.jpg

I tried to peek under the hood of the proprietary design by looking at the timing reports generated by:

  report_timing -to [get_pins adat_reg/CLR] -setup
  report_timing -to [get_pins sdat_reg/R] -setup
 --
  report_timing -to [get_pins adat_reg/CLR] -hold
  report_timing -to [get_pins sdat_reg/R] -hold

-and got slack values of 10.814, 10.727, 0.372, 0.315.   No smoking guns, I think.

So, I can’t answer your question – but I had fun trying.

Finally, just to keep the reset-boat rocking, <here> is a paper by a very respected digital wizard, Clifford Cummings, who concludes that asynchronous-resets are the way to go.  I didn’t have the courage to read any more of the paper than his conclusions.

 

Scholar drjohnsmith
Scholar
107 Views
Registered: ‎07-09-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution
Regarding the paper stated,
The BIG difference is as stated earlier, FPGAs are NOT ASICs,

This paper aimed at ASICs, and yes, in ASICs we tend to do asynchronous reset and a lot of them,

The paper also shows correctly in my view that the reset must meet set up hold times.
0 Kudos
65 Views
Registered: ‎01-08-2012

Re: Impact of design wide asynchronous resets on performance

Jump to solution

@drjohnsmith   You may or may not be aware that older coding guides targeted at Xilinx FPGAs (that predate the WP272 and WP275 that you linked) required the use of an async reset so that the synthesiser could correctly infer the usage of the GSR net.

So it's not just "FPGAs are NOT ASICs", it's also "FPGAs are not (older) FPGAs".

I still use code that predates those white papers, BTW.

0 Kudos
Historian
Historian
46 Views
Registered: ‎01-23-2009

Re: Impact of design wide asynchronous resets on performance

Jump to solution

Clifford Cummings, who concludes that asynchronous-resets are the way to go

Cliff is indeed very respected in the field, and nothing he says in this paper is incorrect given the scope of his paper. But, as others have pointed out, this paper is pretty old and is ASIC centric. So let's look at the "Disadvantages of Synchronous Resets" section from the paper.

Synchronous resets may need a pulse stretcher

This is theoretically true - an asynchronous reset does not need to be a full clock period long in order to take effect. So, in theory, an input connected directly to the async CLR ports of the flip-flops can be short. However, the same paper states (and we pretty much all agree) that an asynchronous reset input signal must be synchronized so that the deasserting edge is synchronous - this is a form of pulse stretcher; no matter how short the input pulse is, the output will be larger than one full clock period.

This same synchronizer would act as a pulse stretcher if you were planning to use synchronous resets - yes, your synchronizer itself would have asynchronous presets/clears (the 2 or 3 flip-flops) but the rest of the design would/could still use synchronous resets.

The clock must be running for synchronous resets

This remains true and was what I mentioned in my previous posts. If the clock is unreliable and you have a destructive state then you need to use asynchronous resets. However, the condition mentioned in the paper (having internal tristates) doesn't apply in FPGAs - there are no internal tristates (at least in all modern FPGAs). External destructive states, like external tristates, external devices that have duty cycle limitations (motors, power amplifiers, lasers) may necessitate asynchronous resets if the controlling flip-flops are not guaranteed to have a valid clock. However, even here, the asynchronous resets are only required on the final drivers of these pins - the remainder of the design can still use synchronous resets.

... the reset can be masked by X's

This (otherwise known as the "recirculating X problem) was a significant problem in the earlier days of ASIC design. The idea is that if the synchronous reset is implemented as circuitry in front of the D input (an AND gate) and the reset condition is less timing critical than other terms in the up-cone, the reset signal can move up the up-cone. If it gets pushed up and forms reconvergent fanout with a term that can be an X (the output of a flip-flop with this problem), then in simulation only (post synthesis gate level simulation) the D input may not resolve and will remain an X.

The above problem was a significant factor in pushing early ASIC designers to asynchronous resets - with an asynchronous reset, the CLR input is a dedicated port of the flip-flop and can't be moved...

For synchronous resets, this was mitigated (if not completely solved) by more intelligence in the synthesis tool - the tool would recognize synchronous reset conditions and either use the dedicated RESET port of the flip-flop for this condition (if it had one) or use an AND gate immediately in front of the flip-flop and ensure that that AND gate cannot be pushed back into the cone of logic.

So, can this occur in an FPGA? No! In an FPGA, all clocked cells in the FPGA are initialized via the GSR "before" the device becomes active. The post-synthesis and post-P&R simulations model this behavior (via the glbl.v or glbl.vhd file that is included in all post-synthesis simulations) - at "time 0" of the simulation, all flip-flops have their INIT value; no flip-flop output is an X. Since the flip-flop outputs are not X, there is no X to recirculate.

So, in conclusion, the disadvantages outlined in this paper either don't apply to FPGAs, or can be mitigated by the judicious use of a "few" asynchronous resets.

Avrum