Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
    • Reset Architecture
    • Metastability and Synchronisation
    • Asynchronous FIFO
    • CDC Protocols
    • Reset Domain Crossing
    • CDC Verification
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹RTL Design
  1. Topics
  2. RTL Design
  3. Reset & CDC

Part 6 · Reset & CDC · Intermediate

Reset & CDC

Reset architecture, synchronisers, async FIFOs, handshakes, reset-domain crossing and verification.

  • 6topics
  • 34lessons

Real chips use several clocks and resets. This section builds reset trees, synchronisers, Gray-coded FIFOs and handshakes, then proves them with window-counted simulation, assertions and checklists.

Learning path through the reset and CDC topics.
Suggested order. Reset architecture and synchronisers are the foundation; the others build on them.

Topic

Lessons

After it you can…

Study time

Reset architecture

5

Build a reset tree with a synchroniser per domain and an ordered release.

2 h

Metastability and synchronisation

5

Use 2FF/3FF synchronisers and avoid bus-bit mistakes.

2–3 h

Asynchronous FIFO

7

Design and test a Gray-coded async FIFO.

3–4 h

CDC protocols

5

Choose and build handshake, pulse and load-pulse crossings.

2–3 h

Reset domain crossing

5

Make crossings robust to one-sided resets.

2–3 h

CDC verification

7

Verify crossings with hostile simulation, assertions, scoreboards and mutations.

2–3 h

Study time covers reading each lesson and running its examples. The section's hands-on project takes extra hours on top.

  • Simulations use a metastability-aware flip-flop model: a data change inside the setup/hold window gives a random old/new output. Window hits are counted, so a test that never hit the window is visibly inconclusive.

  • Several lessons include a mutation: the design was deliberately broken (binary pointers instead of Gray, unstable data, a too-short hold time, resets on one side only) and the test was shown to fail. Those results are quoted in the lessons.

  • SVA properties run in Verilator and were each shown to fire on their own violation.

  • Reliability (MTBF) tables use stated illustrative parameters; real work needs library values.

Tip

Whenever a CDC test passes, ask: how many times did it hit the dangerous window, and would it have failed if the design were wrong? If you cannot answer both, the test proves little.

Check yourself Before starting the section: why can't a 4-bit counter be synchronised with four independent two-flop synchronisers?

Because the bits can be sampled at different times, so the destination sees values that never existed on the counter. The bus lesson measures this and shows the Gray-code fix.

Interview

Typical screening tasks from this section: draw a two-flop synchroniser and say its MTBF dependence, explain async assert/sync release, design an async FIFO (pointers, Gray, full/empty), pass a pulse between clocks, and say what happens if only one side of a handshake is reset.

End-of-section checkpoint

Use these four questions to decide whether you are ready to move on: explain, predict, implement and debug. If one is shaky, each answer names the lesson to revisit. New readers can skip this until they finish the section.

Check yourself Explain: why do most designs assert reset asynchronously but release it synchronously?

Asynchronous assertion puts the logic in a known state immediately, even with no clock running. Synchronous release, through a small reset synchronizer, makes every flop leave reset on the same clock edge and away from it, which avoids recovery and removal violations and flops that leave reset in different cycles. Revisit The async-assert, sync-deassert template.

Check yourself Predict: an 8-bit counter is passed to another clock domain with a 2-flop synchronizer on each bit. It steps from 0x7F to 0x80. What can the receiver see?

Any mix of old and new bits, because each bit resolves independently: 0x7F, 0x80, but also values such as 0xFF or 0x00 that the counter never held. Multi-bit values need Gray code (one bit changes per step), a handshake, or an async FIFO. Revisit Do not synchronize buses bit by bit.

Check yourself Implement: in an async FIFO with Gray pointers one bit wider than the address, how are empty and full detected?

Empty, in the read domain: the read pointer equals the synchronized write pointer. Full, in the write domain: the write pointer equals the synchronized read pointer with its two most significant bits inverted. Each flag is computed in its own domain, so it can only be late, never early. Revisit Full, empty and almost flags.

Check yourself Debug: a one-cycle pulse from a fast domain is sometimes missed in a slow domain, even through a 2-flop synchronizer. Why, and what fixes it?

The slow clock can take no edge while the pulse is high, so the pulse never gets sampled. Convert the event to a level first: toggle a flop on each event in the source domain, synchronize the toggle, and detect its edges in the destination; or use a request/acknowledge handshake when events can come close together. Revisit Pulse synchronizers and event toggles.

Related topics

  • Previous: Timing & Clocking

  • Next: Memory & Buses

PreviousNext: Reset Architecture

Up next

Up nextReset Architecture

Sign in to save progress

Practice this lessonReport an error

See also

  • RTL Foundations
  • Combinational Design
  • Sequential Design