Asynchronous reset synchronization and distribution – Special cases -

Asynchronous reset synchronization and distribution – Special cases


Lack of coordination between asynchronous resets and synchronous logic clocks leads to intermittent failures on power up. In this series of articles, we discuss the requirements and challenges of asynchronous reset and explore advanced solutions for ASIC vs FPGA designs.

Asynchronous resets are traditionally employed in VLSI designs for bringing synchronous circuitry to a known state after power up. Asynchronous reset release operation must be coordinated with the synchronous logic clock signal to eliminate synchronization failures due to possible contention between the reset and the clock. A lack of such coordination leads to intermittent failures on power up. The problem exacerbates when large, multiple-clock domain designs are considered. In addition to the synchronization issues, the distribution of an asynchronous reset to millions of flip-flops is challenging, calling for techniques similar to CTS (Clock Tree Synthesis) and requiring similar area and routing resources.

The requirements and challenges of asynchronous reset are reviewed, focusing on synchronization and distribution issues. The drawbacks of classic solutions for reset synchronization (reset tree source synchronization) and distribution (reset tree synthesis) are discussed. Advanced solutions for faster and simpler timing convergence and more reliable reset synchronization and distribution are presented. Different approaches for ASIC versus FPGA designs are detailed.

Part 1 describes the issues surrounding asynchronous resets and outlines approaches for resolving those issues. Part 2 discusses additional solutions for correct asynchronous reset in ASIC and FPGA. Some useful special cases are discussed in Part 3 (this article).

3. Asynchronous reset special cases, tips and tricks

3.1. Asynchronous reset in FPGA – Power up initialization

FPGA vendors do not recommend using asynchronous resets for FPGA designs ‎[11]. In addition to the synchronous reset option, modern FPGA synthesis tools provide another initialization option as follows.

During FPGA programming process, each cell is initialized. This can serve as a global reset covering not just flip-flops but also other internal IP modules of FPGA, such as memories and DSP blocks ‎[8]. Note that resetting memories and DSP blocks by an asynchronous reset is not supported at all.

Such power up initialization can be safely employed for all FPGA flip-flops that do not belong to the following special categories:

  1. Reset is functional during the application run, and not only at power up.

  2. Reset value depends on an external pin value.

In many designs, the number of flip-flops that belong to the special categories above is very limited. For these flip-flops an asynchronous reset cannot be replaced by the power up initialization option, and the asynchronous reset synchronization schemes, discussed in Part. ‎2, should be employed. The rest of the design flip-flops can be reset at power up by the programming initialization option, which leads to a significant reduction of FPGA utilization ‎[12].

A few examples of flip-flop initialization for VHDL and Verilog are shown in Figure 10. FPGA vendor synthesis tools support a few more coding styles in addition to those shown in the figure.

click for larger image

Figure 10: FPGA power up initialization value example (Source: vSync Circuits)

Summarizing this section, it is important to emphasize that this technique is NOT suitable for an ASIC design.

3.2. Asynchronous reset de-bouncing

The asynchronous reset network must be kept clear of glitches and unintentional toggles to ensure correct operation. Unfortunately, asynchronous reset drivers can be noisy, calling for a special treatment inside the ASIC or FPGA. A few examples of noisy drivers include:

  1. A noisy reset button, generating multiple toggles when pressed and released.

  2. An inductive coupling between asynchronous reset board trace and other board traces ‎[10]. This one is extremely dangerous, as it can cause an unintentional full or partial design reset during normal operation.

  3. In an environment exposed to radiation, a Single Event Transient (SET) may take place due to radiation, causing spurious glitches over on-chip interconnect ‎[1].

Glitch filters are employed for de-bouncing of the signal. The filters can be either purely combinational or synchronous. In the reset tree, special asymmetric buffer cells can be employed, filtering the glitches at each stage with a minimal timing penalty on the de-assertion edge. The asymmetric buffers filter relatively small glitches (e.g., up to 100 ps for the 65nm node). To filter longer glitches, combinational filters are used, taking into account glitch polarity, as shown in Figure 11. Although combinational glitch filters can be built directly using gates (or provided as part of the library) in an ASIC, in an FPGA they are built using LUTs with a special constraining ‎[10].

click for larger image

Figure 11: Glitch Filters. (a) Active High glitch filter (b) Active Low glitch filter (Source: vSync Circuits)

In rad-hard designs, an asynchronous reset network must contain no inverters, but only (asymmetric) buffers with the glitch filters inside, in order to ensure that following a SET, an induced glitch is filtered out by the closest buffer that encounters the glitch. Otherwise the glitch could be amplified, possibly causing an unintentional reset. This, however, restricts designs that require both asynchronous active low and asynchronous active high resets (e.g., due to an integration of different third-party IP modules). In that case, two separate asynchronous reset and asynchronous set networks can be employed (Figure 12), spanning the two separate groups of modules. It is worth noting that the asynchronous reset synchronizer shown in Figure 12 must be constructed of rad-hard protected flip-flops to minimize a chance of an unintended reset assertion due to a Single Event Upset (SEU) event in the flip-flops.

click for larger image

Figure 12: Separate asynchronous reset networks for active low and active high resets to prevent glitch propagation (Source: vSync Circuits)

A synchronous filter can provide longer filtering time (e.g., for manual button noise filtering). An example of a synchronous de-bouncer is shown in Figure 13. The filter requires a free running clock. It filters both negative and positive bouncing. The filter time is configurable using either a pipeline of flip-flops or a synchronous counter. The output of this filter is an input to an asynchronous reset synchronizer.

click for larger image

Figure 13: De-bouncing synchronous filter (Source: vSync Circuits)

3.3. Asynchronous Reset of Multiple Clock Domains

In a multiple clock domain design, an asynchronous reset should be separately synchronized for each clock domain (Figure 14a). A design may have multiple asynchronous reset sources, such as external reset (possibly cleaned up from glitches by a bouncing filter as in section ‎3.2), internal controls (e.g. voltage domain status indication) and PLL lock conditions. All these mutually asynchronous indications may be combined to a single Reset Enable condition, as shown in Figure 14a.

click for larger image

Figure 14: Reset Synchronization in Multiple-Clock Domain (MCD) design (Source: vSync Circuits)

Since each reset synchronizer incurs an additional non-deterministic synchronization delay, expressed in terms of the targeted clock domain cycles, the different clock domains may leave the reset state at arbitrary different times (Figure 14b). This creates a system level challenge, requiring a specific definition and management of the reset release sequence to ensure specific order for exiting reset. In the example of Figure 14, assuming that a CLK1 domain module sends data to a slower CLK2 domain module, the system may require that clock domain CLK2 reset is released before that of CLK1, to ensure that CLK2 domain module is ready to receive data when CLK2 domain module starts sending it. This can be achieved by adding RSTO_CLK2 to the CLK1 reset synchronizer reset conditions (dashed line in Figure 14a).

Considering the complexity of multiple clock domains, multiple reset conditions and multiple inter-clock reset dependencies, an IP-based management of the reset circuitry is preferred. An example of a generic multiple clock domain reset synchronizer generator is shown in Figure 15 ‎[5]. The generator customizes reset synchronizer IP cores. Each synchronized reset output of the module can depend on a custom combination of input conditions and on other reset outputs, enabling a multi-stage timed reset release sequence. An IP-based reset synchronization not only reduces design and verification time, but also allows an automatic generation and management of reset constraints for synthesis and P&R tools.

click for larger image

Figure 15: Global reset management by vSync vReset module [5] (Source: vSync Circuits)

A special note should be made regarding PLL/DLL reset. The reset to PLL/DLL should be separate from the reset of the logic that is clocked by the PLL/DLL outputs. Figure 16a exemplifies a wrong reset design. The asynchronous reset is directly connected to both PLL and a Reset Synchronizer. When the external reset is active, depending on PLL implementation, the PLL may output either a “glitchy” clock or no clock at all at its CLKO port. Thus, if using a trailing-edge reset synchronizer (Figure 3a) or when both asynchronous reset edges are synchronized creating a completely synchronous reset, the reset synchronizer flip-flops stay uninitialized upon the external reset release. This leads to a synchronization failure. The vdd-based synchronizer of Figure 3c behaves better as its flip-flops are asynchronously reset. However, it still may malfunction if CLKO is still unstable for some time after the reset release.

click for larger image

Figure 16: Reset Synchronization with a PLL. (a) WRONG Reset design: reset disappears before it is synchronized; (b) Vdd-based reset synchronization depends on clock stability (Source: vSync Circuits)

A more reliable approach is shown in Figure 16b and involves a LOCK indication from the PLL. The LOCK indication provides an asynchronous indication of the CLKO stability, thus enabling filtering out the CLKO unstable time period. The trailing-edge and synchronous reset synchronizers will still fail in this scheme for the same reason, as CLKO may only appear when LOCK is asserted. On the other hand, the vdd-based synchronizer works fine in this scheme and therefore it is the recommended one.

PLL lock indication may be unstable and can be asserted and de-asserted several times before PLL stabilization. Although the reset synchronizer of Figure 16b works functionally correctly under these conditions, to avoid multiple synchronized reset (RSTO) switchings, the Reset Synchronizer can be configured with a deeper synchronization chain (e.g., 3 stages instead of 2), providing the reset synchronous de-assertion only after PLL lock stabilization. Alternatively, a counter based delay of multiple cycles may be applied to the LOCK signal.

3.4. Asynchronous Reset CDC Verification

The complexity of modern ASIC and FPGA designs calls for an automatic verification of reset schemes employed inside the designs. Asynchronous reset paths are a special case of Clock Domain Crossings (CDC) and are treated by special algorithms of EDA CDC verification tools. The asynchronous reset verification includes an identification of reset distribution trees and an analysis of reset synchronization schemes applied. The analysis must take into account the reset connections to regular synchronous logic as well as the connections to black-box IP cores. In addition, the analysis should validate possible reconverging path problems leading to incorrect clock release sequences in between different reset domains. Special analysis is applied to verify that reset domain crossings (RDC) do not cause functional failures ‎[13].

An asynchronous reset may span an entire design, thus the number of asynchronous reset CDC paths may be of the order of the number of flip-flops in the design. To deal with such a high number of timing paths, EDA tools must be able to present the information in a concise way, enabling an efficient report analysis. An example of such report generation and analysis is shown in Figure 17, where reset distribution trees and their sources are automatically identified, and a condensed textual and visual report is generated leading to an efficient and fast design analysis ‎[5]. The verification process can be reinforced by an automatic solution generation for identified faulty asynchronous reset CDCs and by an automatic constraints generations for the CDCs ‎[5].

click for larger image

Figure 17: Asynchronous reset verification by vSync vChecker EDA tool ‎[5] (Source: vSync Circuits)

3.5. Make your IP-design ready

Digital IP products are intended for embedding in different types of design and are required to support fast and reliable integration into customer SoCs. This calls for developing highly parameterized and generic IP designs that could easily fit into a customer echo-system, including support of customer clock and reset schemes, area and power budgets, custom technology libraries and DFT. The IP design must also allow verification inside a custom system verification environment.

A generic IP product should allow the user to customize the reset options, allowing the choice of an asynchronous reset, a synchronous reset or both. Missing support for one of the reset types may prohibit using the IP or require significant re-design. It is also recommended, from DFT perspective, to separate the asynchronous and synchronous resets in the IP core, driving them from two separate IP module ports. This enables full asynchronous reset controllability for DFT. Additional generic parameters for the logic can include reset polarity and clock enable logic (for automatic clock gating insertion).

A generic template for such an IP logic development is shown in Figure 18. The left-hand size shows a VHDL process template. It employs functions for enabling asynchronous reset, synchronous clear and data sampling. The functions themselves are controlled globally through constant values (customized settings) allowing to define the polarity (c_polarity_* constants) and the function existence itself (c_use_* constants). When a c_use_* constant is false, the corresponding logic is eliminated, removing either asynchronous reset, synchronous clear or preventing clock gating insertion for the entire IP module.

click for larger image

Figure 18: A template for a generic IP development enabling asynchronous reset and synchronous clear (Source: vSync Circuits)

IP modules are mostly provided in encrypted form to protect the IP. This poses an additional limitation on multiple-clock domain IP integration and verification. While IP providers usually separate the technology dependent logic, such as memory blocks, from the IP core logic (Figure 19a), the synchronization circuits are typically kept within the encrypted logic. The inability to verify the IP synchronization logic along with the entire SoC can lead to synchronization failure of the entire design, as possible CDC reconvergence and RDC issues are not covered. It should be also noted that the synchronization logic is also a technology dependent logic as its reliability (MTBF) highly depends on a targeted technology node and operating conditions, and therefore it is better be configurable and accessible.

click for larger image

Figure 19: An integration and verification friendly IP packaging (Source: vSync Circuits)

The aforementioned reasons lead us to a conclusion that all CDCs should be exported to an upper level of the IP design, just as it is done for memory blocks (Figure 19b). This will allow their customization for a targeted technology, including their replacement by dedicated synchronization cells from the technology library. Once the CDCs are provided as open code, they can be verified by static and dynamic approaches, including the verification of the asynchronous reset distribution and its compatibility with global SoC reset scheme.

Some cell libraries miss a flip-flop cell with asynchronous set , although a flip-flop with asynchronous reset is provided. A simple trick shown in Figure 20 can solve the problem. The option of Figure 20b, when possible, is better than the one of Figure 20a as it provides better timing and area. A considerate IP provider can include such an option in its IP or move out all the asynchronously set flip-flops to the open-code section.

click for larger image

Figure 20: Building a flip-flop with asynchronous set based on an asynchronous reset flip-flop (Source: vSync Circuits)

Last but not least, a note regarding IP delivery: The documentation provided along with the IP module should include a precise clock domain association requirement for all the ports of the encrypted IP. In some cases, the clock domain association varies dependent on the customization or on the operation mode. All these should be precisely reflected in the documentation. Such description is essential to verify that the IP module is correctly integrated inside a SoC design.


This paper surveys multiple issues related to asynchronous reset employment and distribution. We describe several techniques for dealing with high fanout reset distribution networks, minimizing or completely eliminating the timing issues, reducing area and design effort. Additional topics include the treatment of asynchronous reset in FPGA, de-bouncing, assuring reset in multiple-clock domain designs and verification of designs using asynchronous reset. We also share our view of desirable IP module packaging that allows reliable integration of the IP module in a SoC that employs asynchronous reset.

The enormous number of CDC paths in modern design, including asynchronous reset paths, calls for an automatic EDA approach for dealing with both integration and verification of such complex systems. Through the text, we provide a few examples of industrial tools that deal with such complexity, leading to high reliability products.


  1. G. Wirth, F. L. Kastensmidt and I. Ribeiro, “Single Event Transients in Logic Circuits – Load and Propagation Induced Pulse Broadening,” IEEE Transactions on Nuclear Science, 55(6), 2928 – 2935, 2008.

  2. C. E. Cummings, D. Mills and S. Golson, Asynchronous & Synchronous Reset Design Techniques – Part Deux, SNUG, 2003.

  3. W. J. Dally and J. W. Poulton, Digital System, Engineering (Eds.). Cambridge University Press (1998).

  4. C. Dike and E. Burton, “Miller and noise effects in a synchronizing flip-flop,” IEEE Journal of Solid-State Circuits, 34(6), 849-855, 1999.

  5. vSync Circuits Vincent Platform,

  6. Altera, Quartus-II,

  7. Quartus II Handbook Volume 1: Design and Synthesis, pp. 11-19 – 11-29, 2014.12.15

  8. K. Chapman, “Get Smart About Reset: Think Local, Not Global”, Xilinx, WP272 (v1.0.1), 2008.

  9. K. Chapman, “Get your Priorities Right – Make your Design Up to 50% Smaller,” WP275 (v1.0.1), 2007.

  10. K. Chapman, “Xilinx-Ken Chapman-That Dangerous Asynchronous Reset!-External Antenna – Need for de-bouncer”, PLD Blog, 2008.

  11. Xilinx, XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices, UG687 (v 13.1), pp. 50, 95, 128, 2011.

  12. Yaniv Halmut, RESET architecture in Altera FPGAs: utilization effects, private communication, RAD, 2016.

  13. Chris Kwok, Priya Viswanathan and Ping Yeung, “Addressing the Challenges of Reset Verification in SoC Designs”, DVCon, 2015.

Rostislav (Reuven) Dobkin received PhD degree in electrical engineering from Technion, Israel Institute of Technology. Reuven is a co-founder and CTO of vSync Circuits LTD. (2010), a VLSI CAD company. In parallel, Reuven serves as a lecturer in Technion. Reuven has held management positions in radiation-hardened VLSI technology for space applications, in communications chip development, and in research in C4 I systems, signal processing, software systems engineering and VLSI. Reuven serves as a reviewer of numerous VLSI journals and conferences. His research interests are VLSI architectures, asynchronous logic, synchronization, GALS systems, SoC, NoC, many-core processors and parallel architectures.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.