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

  • How to Use This Course
  • Reading Path
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
  • Reconvergence and Gray Coding16
    • Gray Code Crossing
      • The One-Bit-Change Rule
      • Gray Counters
      • Where Gray Fails
      • Non-Power-of-Two Depths
    • Reconvergence Analysis
    • Multi-bit Crossing Strategies
    • Reconvergence Debug
  • Reset Domain Crossing16
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Gray Code Crossing
  1. Topics
  2. CDC & RDC
  3. Reconvergence and Gray Coding
  4. Gray Code Crossing
  5. The One-Bit-Change Rule

Part 4 · Reconvergence and Gray Coding · All levels

The One-Bit-Change Rule

Why Gray coding makes a counter safe to sample in another domain, and the exact condition it needs.

On this page

    Every FIFO pointer and every free-running counter that crosses into another clock domain faces the same hazard: the sampling edge can land while the value is changing. Binary code then tears, because each bit resolves independently to old or new. Gray code is ordered so that consecutive values differ in exactly one bit, which bounds the damage of a torn sample.

    The rule

    g=b⊕(b≫1)

    Each step of the counter flips exactly one Gray bit, including the wrap from the last value back to zero. If a destination flop samples the bus while that one bit is changing, the bit settles to the old or the new value, so the whole sample reads the old value or the new value. There is no third logic outcome; the per-bit synchroniser is still required because the one changing bit can itself go metastable.

    Count

    Binary

    Gray

    Bits changing (binary / Gray)

    0

    000

    000

    –

    1

    001

    001

    1 / 1

    2

    010

    011

    2 / 1

    3

    011

    010

    1 / 1

    4

    100

    110

    3 / 1

    At count 3 to 4 the binary value changes three bits at once while Gray changes one. That row is the whole argument.

    The exact condition

    1. Consecutive values only. The source must advance (or retreat) one step at a time. Loads, resets to arbitrary values, and skipped counts break the rule, because the jump changes several bits.

    2. Sampled values may be stale but never wrong by more than the step. Synchroniser latency means the destination sees older values, typically two to three cycles behind. For a FIFO pointer that staleness is conservative (full early, empty early), never corrupt.

    3. One changing bit at a time. The Gray value must come straight from source-domain flops. Combinational logic after the conversion can glitch several bits during the step and reintroduce tearing.

    What the checking and the review look for

    Check

    Evidence

    The crossing carries a Gray-coded value

    Conversion g = b ^ (b >> 1) feeding a register, not a bare binary bus

    Single-bit steps hold on every transition

    Exhaustive adjacency check, including the wrap (next lesson)

    No jumps on the crossed value

    No load, reset-to-arbitrary, or skip on the Gray register

    Registered source, per-bit synchronisers

    Gray flops in the source domain, one synchroniser chain per bit

    Common pitfall

    Gray coding does not remove metastability. The single changing bit can still be sampled inside its setup-hold window and resolve either way. That is exactly the old-or-new outcome the rule promises, and the synchroniser behind each bit still needs its settling time.

    Interview

    “Why is Gray code safe across a clock domain?” Answer in two sentences: consecutive values differ in one bit, so a sample torn mid-step reads the old or the new value. Then state the condition: the counter must step by one, and the Gray value must be registered. Expect “when does it fail?” next.

    Check yourself A Gray counter steps from one value to the next while the destination samples it. List every value the destination can observe from that sample.

    Two: the old value or the new value. Only one bit is in flight, so the sample resolves each bit to old or new and the two outcomes are exactly the two consecutive values.

    Check yourself The destination reads a Gray pointer three cycles after it was sent. Is that a violation?

    No. Latency makes the sample stale, not wrong. The value observed is a genuine past value, one whole step, which conservative full and empty logic tolerates.

    Related topics

    • Next: Gray counters

    • Design: async FIFO

    Previous

    47 / 179

    Next: Gray Counters

    Up next

    Up nextGray Counters

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Where Gray Fails
    • Non-Power-of-Two Depths