VLSICoding

Mastering Asynchronous Resets in ASICs/FPGAs

2026-10-01T02:35:15.753+05:30

We’ve seen in the last few posts mastering Clock Domain Crossing (CDC)—learning how to safely move single bits, multi-bit buses, and fleeting pulses across different clock domains without triggering metastability.

Today, we are looking at a signal that goes to almost every single flip-flop in your entire design: The Reset Signal.

In academia, the reset is just a theoretical switch that initializes your system. In the real world, releasing a reset at the wrong time will send your entire chip or FPGA into a catastrophic, unrecoverable metastable state. Let’s explore why this happens and how industry experts fix it.

Synchronous vs. Asynchronous Resets

When designing RTL, you generally have two choices for how to implement your resets:

Synchronous Resets: The flip-flop only clears its value on the active edge of the clock.
- Pros: Completely immune to metastability from the reset signal itself.
- Cons: If your clock is turned off (e.g., to save power), you cannot reset the chip!
Asynchronous Resets: The flip-flop clears its value the instant the reset signal is asserted, regardless of what the clock is doing.
- Pros: Works perfectly even if the clocks are stopped or haven't stabilized yet.
- Cons: Extremely dangerous when you release the reset.

Because modern System-on-Chips (SoCs) use aggressive clock-gating to save power, Asynchronous Resets are the industry standard. But they come with a massive hidden trap.

The Trap: Recovery and Removal Time Violations

We know from our previous CDC posts that data signals have Setup and Hold times. If data changes too close to a clock edge, the flip-flop goes metastable.

Asynchronous resets have the exact same physical limitations, but they go by different names: Recovery Time and Removal Time.

Asserting an asynchronous reset is perfectly safe. It forces the flip-flop to 0 immediately. The danger happens when you de-assert (release) the reset. If you release the reset button at the exact moment the clock edge is ticking, the flip-flop’s internal transistors get confused. Should they stay at 0 (because of the reset) or should they capture the new incoming D data (because of the clock)?

Just like a setup/hold violation, the flip-flop goes metastable. But unlike a data path where a single bad bit might corrupt a packet, a metastable reset signal means your state machines boot into illegal states. Your chip is effectively dead on arrival.

The Industry Solution: "Async Assertion, Sync De-assertion"

To get the best of both worlds—the ability to reset without a clock, but the safety of a synchronous release—engineers use a specific circuit topology called a Reset Synchronizer.

The rule of thumb for this architecture is: Asynchronous Assertion, Synchronous De-assertion.

Here is how the circuit works:

The Assertion (Asynchronous): When the external reset button is pressed, the signal bypasses the synchronizer's clock entirely and routes directly to the asynchronous clear pins of the reset synchronizer's flip-flops. The reset propagates instantly across the whole chip.
The Wait: The input data pin (D) of the first synchronizer flip-flop is permanently tied to 1 (or VDD).
The De-assertion (Synchronous): When the external reset is released, the chip doesn't wake up immediately. Instead, on the next clock edge, the first flip-flop captures that permanently tied 1. On the following clock edge, the second flip-flop captures it.
Safe Wakeup: The clean, synchronized 1 finally reaches the rest of your design, releasing the whole clock domain from reset perfectly aligned with the clock edge.

Why You Need a Tree

You cannot just use one reset synchronizer for your entire SoC. If you have 10 different clock domains (e.g., 1GHz, 400MHz, 50MHz), you must instantiate a dedicated Reset Synchronizer for each clock domain.

The raw external reset goes to all of them, but each domain wakes up perfectly aligned to its own specific clock frequency. This distributed architecture is known as a Reset Tree.

Takeaway

Treating a reset signal like a simple wire is a classic beginner mistake. In reality, a reset is a massive, high-fanout network that requires just as much architectural planning as your clock tree.

Whenever you are writing Verilog or SystemVerilog for a new module:

Use asynchronous resets for your registers.
Never feed an external reset directly into your main logic.
Always pass your raw reset through a Reset Synchronizer clocked by that module's specific domain before letting it touch your functional flip-flops.

Reconvergent Logic and the +/- 1 Cycle Uncertainty during Clock Domain Crossing

2026-09-08T05:34:00.000+05:30

If you have been following our CDC (Clock Domain Crossing) series, you know the golden rule of single-bit transfers: Always use a 2-Flop Synchronizer.

So, you design your RTL. You have two independent control bits—let's call them enable and mode—crossing from a 100MHz domain to a 500MHz domain. Like a good design engineer, you place a 2-flop synchronizer on each signal. The metastability resolves, the linting tools pass, and you tape out.

But when the silicon comes back, your destination state machine occasionally jumps into an illegal state and freezes. What went wrong?

Welcome to the hidden trap of CDC: Reconvergent Logic.

The +/- 1 Clock Cycle Uncertainty

To understand why your design crashed, we have to look at how synchronizers actually behave in the physical world.

When a signal goes metastable in the first stage of a 2-flop synchronizer, it will eventually settle to a 1 or a 0. But which one it settles to during that specific clock cycle is entirely random.

If it settles to the new value, the destination domain sees the signal change this cycle.
If it settles to the old value, the destination domain won't see the signal change until the next cycle.

This introduces a fundamental hardware rule: Every synchronizer has a built-in temporal uncertainty of +/- 1 clock cycle.

The Reconvergence Disaster

Now, let's look back at your enable and mode signals. Let's assume the source domain asserts both of them at the exact same time.

Because of microscopic routing delays and the +/- 1 cycle uncertainty of synchronizers, these two signals might not exit their respective 2-flop synchronizers in the destination domain simultaneously.

Cycle 1: enable synchronizer resolves to 1. mode synchronizer resolves to 0 (it needs one more cycle).
Cycle 2: enable is still 1. mode synchronizer finally resolves to 1.

For exactly one clock cycle, your destination domain saw enable = 1 and mode = 0. If your downstream logic combines these two signals (i.e., the logic reconverges), that temporary mismatch can trigger a fatal false state in your state machine.

Key Takeaway: You successfully prevented metastability, but you destroyed the logical relationship between your signals.

How to Fix Reconvergent CDC Paths

The rule for fixing this is simple: Never synchronize related control signals separately if they will be evaluated together in the destination domain.

Here is how experienced design engineers handle this:

1. Consolidate Before Crossing

Instead of sending enable and mode as separate signals, combine them into a single validation signal in the source domain. For example, create a new signal: valid_operation = enable & mode; in the source clock domain. Then, pass only that single valid_operation bit through a 2-flop synchronizer.

2. Use a Multi-Bit CDC Technique

If you truly need both distinct bits in the destination domain, you can no longer treat them as independent control signals. You must treat them as a multi-bit bus. As we covered in a previous post, this means you must use a Gray Code encoding scheme or a Request/Acknowledge Handshake to ensure both bits are stable before the destination domain is allowed to read them.

Wrapping Up

CDC bugs are notoriously difficult to catch because they rarely show up in standard RTL simulations. A standard simulator doesn't model the microscopic silicon delays that cause the +/- 1 cycle uncertainty.

When designing your architecture, always trace your synchronized signals. If two signals cross domains separately and then meet at an AND gate, a MUX, or a State Machine evaluation down the line, you have a reconvergence bug waiting to happen.

Pulse Transfers and Fast-to-Slow Clock Domain Crossing

2026-08-15T13:00:00.000+05:30

From the last post, you know how to use a 2-Flop Synchronizer for single control bits, and you know how to use Handshakes and Asynchronous FIFOs for multi-bit data buses.

But there is one specific, highly common scenario that will silently break a standard 2-Flop Synchronizer: passing a single-cycle pulse from a very fast clock domain to a very slow clock domain.

Let's dive into the "Disappearing Pulse" problem and the clever hardware tricks VLSI engineers use to solve it.

The Disappearing Pulse Problem

Imagine you have a high-speed networking chip. A packet arrives, and the 1GHz receiver logic generates a single-cycle packet_received pulse. You need to send this pulse to a 100MHz microcontroller on the same chip so it can log the event.

You route the 1GHz pulse directly into a standard 2-Flop Synchronizer running at 100MHz. You run the simulation, and... nothing happens. The microcontroller never sees the pulse. What went wrong?

It comes down to simple math and timing:

A single clock cycle at 1GHz is exactly 1 nanosecond long. Your pulse exists for exactly 1ns.
A 100MHz clock only ticks once every 10 nanoseconds.

If the 1ns pulse fires and disappears between the 10ns ticks of the slow clock, the slow clock's flip-flops will never see it. The data violates the fundamental rule of sampling: the signal must be stable long enough for the destination clock to actually sample it.

The Solution: Pulse-to-Toggle Synchronization

To fix this, we cannot just send the raw pulse. We need to "stretch" the event so the slow clock has time to notice it. The most elegant, open-loop way to do this is using a Pulse-to-Toggle Synchronizer.

Instead of trying to catch a fleeting pulse, we convert the pulse into a permanent state change (a toggle). The slow domain then looks for that state change and converts it back into a pulse.

Here is the step-by-step architecture:

Step 1: The Toggle Flip-Flop (Fast Domain)

In the fast domain (1GHz), we route the incoming pulse into the enable pin of a Toggle Flip-Flop (T-Flop) or a simple XOR gate.

Every time a packet_received pulse arrives, the output of this register flips its state (from 0 to 1, or from 1 to 0).
Because the state stays flipped forever (until the next pulse), we have effectively stretched a 1ns event into a permanent level change.

Step 2: The 2-Flop Synchronizer

Now that we have a stable, long-lasting level change, we can safely pass it through a standard 2-Flop Synchronizer into the slow domain (100MHz). Because the signal is now a continuous level, the slow clock is guaranteed to capture it, completely avoiding the disappearing pulse problem.

Step 3: The Edge Detector (Slow Domain)

Once the synchronized toggled signal is safely inside the slow domain, we need to turn it back into a single-cycle pulse.

Remember the Rising and Falling Edge Detector code I shared on this blog back in November? This is exactly where you use it!

We run the synchronized signal through an edge detector in the 100MHz domain.
Whenever the edge detector sees the signal change (either rising or falling), it generates a clean, single-cycle pulse in the 100MHz domain.

The event has successfully crossed the chasm!

Alternative: Closed-Loop Pulse Stretching (The Handshake)

If you absolutely cannot afford to miss a pulse, and you need confirmation that the slow domain received it, you can use a closed-loop handshake.

The fast domain receives the pulse and sets a req (request) signal to 1. It holds this signal high indefinitely.
The slow domain captures the req signal through a 2-Flop Synchronizer and generates a pulse.
The slow domain then sends an ack (acknowledge) signal back to the fast domain through another 2-Flop Synchronizer.
Once the fast domain sees the ack, it finally drops the req signal to 0.

While this is incredibly safe, it requires the fast domain to wait several slow-clock cycles before it can send a second pulse. If your fast domain is generating rapid-fire pulses (e.g., multiple packets arriving back-to-back), the handshake mechanism will bottleneck your system. In those cases, a fast-to-slow Asynchronous FIFO is required.

The Practical Takeaway

When designing RTL, you must always look at the frequencies of your clock domains.

Going from Slow to Fast: A 2-Flop synchronizer usually works fine, because a slow pulse is naturally wide enough for a fast clock to sample it multiple times (though you will need an edge detector to prevent a single slow pulse from turning into multiple fast pulses!).
Going from Fast to Slow: Never send a raw pulse. You must use a Pulse-to-Toggle circuit, a Handshake, or an Async FIFO to stretch the data so the slow clock can actually see it.

Mastering these topologies ensures your chips won't just work in perfectly timed academic simulations, but in the chaotic, multi-frequency reality of physical silicon.

Handshakes, FIFOs, and the Magic of Gray Code in Multi-Bit CDC

2026-08-11T05:33:00.155+05:30

In our last post, we tackled the silent silicon killer known as Metastability and explored how the trusty 2-Flop Synchronizer safely passes a single control bit across different clock domains.

But what happens when you need to send an entire 32-bit data bus from a 1GHz processor to a 400MHz memory controller?

Spoiler alert: You cannot just slap thirty-two 2-Flop Synchronizers in parallel and call it a day. Today, we are diving into the practical magic of Asynchronous FIFOs and why a mathematical curiosity from the 1940s called Gray Code is the only thing keeping modern microchips from collapsing into chaos.

The Multi-Bit Disaster: Why 2-Flop Synchronizers Fail on Buses

Imagine trying to pass a binary counter value of 3 (011 in binary) changing to 4 (100 in binary) across a clock domain using parallel synchronizers. Notice that three separate bits are changing simultaneously to make that jump.

In the physical world of silicon, perfectly simultaneous events do not exist. Microscopic variations in wire routing, parasitic capacitance, and temperature mean those three bits will arrive at the destination flip-flops at slightly different picoseconds. This is called Bus Skew.

If the destination clock ticks exactly while those bits are transitioning, some flip-flops will capture the old value, some will capture the new value, and some will go metastable. Your destination domain might stitch those bits together and read 7 (111) or 0 (000). This generates a garbage memory address that will instantly crash your system.

To fix this, we have two primary weapons in RTL design: Handshaking and Asynchronous FIFOs.

Solution 1: The Handshake Protocol (Slow but Safe)

If you only need to send multi-bit data occasionally—like writing to a configuration register—the Request/Acknowledge (Req/Ack) Handshake is your best friend.

Instead of synchronizing the multi-bit data directly, we freeze the data and synchronize a single control bit to act as a messenger.

Here is the step-by-step dance of a standard handshake:

Source Domain: Places the 32-bit data onto the bus and holds it steady.
The Request: The source asserts a 1-bit Request signal. Because it is a single bit, we can safely pass it through a standard 2-Flop Synchronizer into the destination domain.
Destination Domain: Once it receives the synchronized Request, it knows the 32-bit data bus has been stable for several clock cycles. It safely reads the data bus.
The Acknowledge: The destination asserts a 1-bit Acknowledge signal back to the source (again, passed through a 2-Flop Synchronizer).
Completion: The source receives the Acknowledge, drops the Request, and knows it is finally safe to put new data on the bus.

While incredibly safe, handshaking is very slow. A single transfer can take 4 to 6 clock cycles due to the round-trip delay of the synchronizers. For high-speed, continuous data streaming, we need something much faster.

Solution 2: Asynchronous FIFOs and the Gray Code Savior (Fast and Continuous)

To safely pass multi-bit data without corrupting it, VLSI engineers use an Asynchronous FIFO (First-In, First-Out memory buffer).

Think of an Async FIFO like a dual-door waiting room:

The Write Interface: Operates entirely on the source clock (Clock A). It blindly pushes data into the room until it is full.
The Read Interface: Operates entirely on the destination clock (Clock B). It blindly pulls data out of the room until it is empty.

The actual data payload never crosses a clock domain; it just sits statically in the memory buffer. However, the control logic must cross domains. The Write domain needs to know if the room is full (so it stops writing), and the Read domain needs to know if the room is empty (so it stops reading).

They do this by sharing Pointers—counters that track the current read and write addresses.

The Pointer Problem and the Gray Code Savior

We are immediately back to square one: sharing pointers means we have to pass multi-bit counters across clock domains. If we use standard binary counters, we hit the exact same bus skew disaster described above.

This is where Gray Code saves the day.

Invented by Frank Gray at Bell Labs, Gray Code is an alternate way of counting where only one single bit changes at a time between any two consecutive numbers.

Take a look at how Standard Binary counts versus Gray Code:

Decimal Value	Standard Binary	Gray Code	Bits Changed (from previous)
0	`000`	`000`	-
1	`001`	`001`	1
2	`010`	`011`	1
3	`011`	`010`	1
4	`100`	`110`	1
5	`101`	`111`	1

Why Does This Fix CDC?

Because only one bit changes at a time in Gray Code, we completely eliminate the bus skew problem!

If a Gray Code pointer transitions from 3 (010) to 4 (110), only the first bit is transitioning. If the destination clock samples the bus right in the middle of that transition, the metastable bit will eventually resolve to either a 0 or a 1.

If it resolves to 0, the destination reads 010 (the old value, 3).
If it resolves to 1, the destination reads 110 (the new value, 4).

There is no catastrophic 000 or 111 garbage state! The destination domain might be one clock cycle late in realizing the pointer updated, but the system remains perfectly safe and mathematically sound.

The Practical Takeaway

When crossing multi-bit buses in RTL design, you must choose the right tool for the job.

Use Handshaking protocols for slow, infrequent transfers like control signals or register configurations. It is cheaper on silicon area but costs you in latency.
Use Asynchronous FIFOs with Gray Code pointers for high-bandwidth, continuous data streams like video processing or network packets. It takes up more silicon area but allows systems with radically different clock speeds to communicate at maximum efficiency.

Understanding these hardware realities bridges the gap between academic theory—where data magically arrives on time—and physical silicon, where every nanosecond of bus skew is out to destroy your design.

Understanding Metastability and Clock Domain Crossing (CDC)

2026-08-03T08:34:34.482+05:30

If you’ve taken a digital logic class, you know the golden rule: everything happens on the clock edge. Your flip-flops read the input, store the state, and pass it to the next logic gate in perfect synchronization.

But what happens when your design has more than one clock?

In modern ASICs and FPGAs, a single chip might have a 1GHz processor, a 400MHz memory controller, and a 50MHz UART interface. When data needs to move between these independent clock domains—a process known as Clock Domain Crossing (CDC)—the perfect synchronization of the classroom goes out the window, and you enter the dangerous territory of Metastability.

The Setup and Hold Violation

To understand metastability, we have to look at the physical physics of a flip-flop. For a flip-flop to reliably capture a 1 or a 0, the data signal must be stable for a specific amount of time before the clock edge (Setup Time) and remain stable for a specific amount of time after the clock edge (Hold Time).

When data crosses from Domain A (e.g., 100MHz) to Domain B (e.g., 33MHz), Domain B's clock has no idea when Domain A's data is changing. It is almost guaranteed that eventually, Domain B's clock will tick exactly at the moment Domain A's data is transitioning between a 0 and a 1.

This violates setup and hold times, causing the flip-flop to go metastable.

What is Metastability?

When a flip-flop goes metastable, it doesn't output a clean 1 or 0. Instead, the voltage gets "stuck" somewhere in the middle, hovering at an undefined voltage level.

Worse, it can oscillate between high and low before finally settling down.

If this undefined, fluctuating signal propagates into your downstream logic, your chip will experience catastrophic failure. A state machine might jump to an illegal state, or a memory address might become corrupted. Because it depends on the precise, drifting alignment of two independent clocks, metastability bugs are incredibly difficult to reproduce in simulation—they only show up in actual silicon, completely freezing your hardware at random intervals.

The Practical Solution: The 2-Flop Synchronizer

While we cannot mathematically eliminate the probability of a flip-flop going metastable, we can increase the MTBF (Mean Time Between Failures) from a few seconds to billions of years.

The standard industry practice for crossing a single-bit control signal is the 2-Flop Synchronizer.

Here is how it works:

The First Flop: The incoming asynchronous signal is fed into the first flip-flop in the destination domain. When a setup/hold violation occurs, this flop will go metastable.
The Waiting Game: The signal is given an entire clock cycle to resolve. Physics dictates that metastable states naturally want to collapse to a stable 1 or 0 eventually.
The Second Flop: By the time the next clock edge arrives, the first flop has almost certainly resolved to a stable state. The second flip-flop then safely captures this stable value and passes it into the rest of the destination clock domain.

When 2-Flop Synchronizers Fail

While great for single bits (like an enable or reset signal), 2-flop synchronizers cannot be used for multi-bit data buses.

If you try to pass a 32-bit memory address through 32 parallel 2-flop synchronizers, the bits will resolve at slightly different speeds due to microscopic variations in the silicon. The destination domain might read a corrupted mix of the old address and the new address.

For multi-bit data, VLSI engineers use different CDC techniques:

Asynchronous FIFOs: Using memory buffers with Gray code pointers to safely pass data words between domains.
Handshaking Protocols: Using single-bit req (request) and ack (acknowledge) synchronized signals to tell the destination domain when a multi-bit data bus is stable and safe to read.