Binary and Gray Code: Signal Encoding Essentials for SoC Designers
Binary and Gray Code — Designing Signal Reliability Into Silicon
SoC Architecture · Arm Cortex-A55 · Digital Design Essentials
In digital system design and SoC (System on Chip) architecture, how you represent data is far more than a bookkeeping decision. It directly determines a system's reliability, power efficiency, and timing correctness. This article examines how high-performance processors like the Arm Cortex-A55 (CA55) handle binary counters internally, and why Gray code is not merely an option but a requirement in specific design contexts.
Binary Representation in Hardware
Decimal vs. Binary: Why Hardware Thinks in Two States
The decimal (base-10) system we use daily relies on ten symbols (0–9). Logic gates inside a computer or SoC, however, can only distinguish between two voltage levels — high and low — which maps naturally to a base-2, or binary, number system.
Binary is a weighted positional code: each bit position carries a weight of 2ⁿ. For example, decimal 6 is represented as 110 in binary (2² × 1 + 2¹ × 1 + 2⁰ × 0 = 6). This positional weighting is what makes binary arithmetic directly implementable in gate-level hardware — no translation layer required.
Natural Binary in CA55 Counters
Counters inside the CA55 — such as the system counter CNTPCT_EL0 or PMU (Performance Monitor Unit) event counters — must increment at high frequency. Operating in natural binary means the value flows directly through a flip-flop chain with no additional encoding overhead. This is the most hardware-efficient representation: increment and compare operations map directly to standard adder and comparator logic, with no decode stage in the critical path. Any extra encoding or decoding latency on a hot counter path competes directly with the clock frequency target.
Three Ways to View a Binary Value
In hardware debugging and simulation, the same binary value typically surfaces in three forms:
▶ Bit stream — a raw sequence of 0s and 1s (e.g., 0110 1010). Directly reflects the physical state of each signal pin or flip-flop output.
▶ Hexadecimal — groups four bits into one hex digit (e.g., 0x6A). The dominant format in register dumps, log files, and memory maps — compresses bus width without losing bit-level precision.
▶ Waveform — voltage-level transitions rendered in a timing diagram or logic analyzer capture. Essential for verifying setup/hold timing, spotting glitches, and correlating multi-signal causality at the analog boundary.
Gray Code — Unit Distance and Why It Matters
Core Property: Hamming Distance of 1
Gray code's defining characteristic is that consecutive values differ in exactly one bit. In information theory this is expressed as a Hamming distance of 1 between adjacent codewords. This single property has profound consequences for multi-bit signal integrity in real silicon.
The Binary Glitch Problem
When a binary counter transitions from 3 (011) to 4 (100), all three bits must change simultaneously. In physical circuits, no two flip-flop outputs switch at exactly the same picosecond — process variation, routing skew, and differing load capacitances guarantee small timing offsets between bits.
If the bits switch in the sequence 011 → 111 → 100, a downstream circuit sampling at exactly the wrong moment reads 7 (111) — a completely incorrect value. This is a glitch, and it can drive a downstream flip-flop into a metastable state — where the output is neither a valid logic-0 nor a valid logic-1 for an indeterminate settling period. Metastability that propagates uncaught can corrupt system state in ways that are nearly impossible to reproduce or debug. Gray code eliminates this risk entirely: only one bit ever changes per transition, so no intermediate state is reachable.
Three Engineering Benefits of Gray Code
① Safe CDC (Clock Domain Crossing)
When a pointer or counter must cross from one clock domain to another — the defining challenge of asynchronous FIFOs — a single-bit change per step ensures that even if the receiving flip-flop samples on the wrong edge, it captures either the old value or the new value, never a nonsense intermediate. Modern SoCs contain dozens of independently clocked domains; reliable CDC is foundational to overall chip stability. This matters because a single metastability event that propagates uncaught can corrupt system state silently.
② Reduced Dynamic Power
Dynamic power is proportional to switching activity (α·C·V²·f). Gray code reduces the average number of bit transitions per count step compared to natural binary. In mobile processors like the CA55 — where battery life is a primary design constraint — lower switching activity across high-frequency counter buses translates to measurable power savings. A natural binary bus that flips multiple bits on every cycle wastes energy in wires and gates that do not need to switch.
③ Error Detection in Physical Position Sensing
Rotary encoders and linear position sensors use Gray code so that if more than one bit changes simultaneously, the system immediately flags it as an error. Because legitimate transitions flip exactly one bit, any two-bit change is an unambiguous error signature — no false negatives. This is exploited in industrial robotics, automotive steering systems, and any precision-control application where a spurious position jump could cause a safety event.
The RBGC Algorithm: Encoding and Decoding
Gray code conversion is not a designer-specific lookup table — it is a mathematically defined universal algorithm called RBGC (Reflected Binary Gray Code). The same XOR-based formula appears in every standard textbook and every production RTL implementation.
Encoding: Binary → Gray Code
XOR the binary value B with itself right-shifted by one bit (B >> 1). In RTL this is a single combinational stage with no carry chain — negligible area and zero additional timing risk on the critical path.
Formula: G = B ⊕ (B >> 1)
▶ Example — Encoding decimal 6
| Step | Value | Bits |
|---|---|---|
| Binary (B) | 6 | 1 1 0 |
| B >> 1 | 3 | 0 1 1 |
| XOR Result (Gray) | 5 | 1 0 1 |
Decoding: Gray Code → Binary
Pass the MSB (most significant bit) through unchanged. For each subsequent bit, XOR it with the decoded binary bit immediately above it. Note that decoding is sequential — each stage depends on the result of the previous stage — creating a carry-ripple-like dependency chain. For wide counters this becomes a timing consideration when mapping to RTL.
Formula: B[n] = G[n], B[i] = G[i] ⊕ B[i+1]
▶ Example — Decoding Gray code 101
| Step | Gray Bit | XOR Operation | Binary Result |
|---|---|---|---|
| MSB passthrough | 1 | — | 1 |
| Bit 1 | 0 | 0 ⊕ 1 = 1 | 1 |
| Bit 0 (LSB) | 1 | 1 ⊕ 1 = 0 | 0 |
→ Result: 110 (binary) = decimal 6 ✓
3-Bit Binary vs. Gray Code Reference Table
The table below maps all eight 3-bit values side by side. Scan the Gray Code column: every adjacent pair of rows differs in exactly one bit. The natural binary column offers no such guarantee — the 3→4 transition flips all three bits simultaneously.
| Decimal | Binary | Gray Code | Bits Changed |
|---|---|---|---|
| 0 | 000 | 000 | — |
| 1 | 001 | 001 | 1 ✓ |
| 2 | 010 | 011 | 1 ✓ |
| 3 | 011 | 010 | 1 ✓ |
| 4 | 100 | 110 | 1 ✓ |
| 5 | 101 | 111 | 1 ✓ |
| 6 | 110 | 101 | 1 ✓ |
| 7 | 111 | 100 | 1 ✓ |
Industry Standard or Designer's Choice?
RBGC Is the Universal Standard
The XOR-based RBGC encoding is the internationally adopted standard used across the industry — referenced in Arm architecture documentation, implemented in Synopsys and Cadence standard-cell libraries and synthesis flows, and taught in IEEE-aligned digital design curricula. Any mention of "Gray code" in an SoC design document or IP datasheet implicitly means RBGC unless explicitly stated otherwise.
▶ Algorithm vs. LUT — For narrow-width counters (4 to 8 bits), a precomputed lookup table (LUT) is sometimes used to trade logic depth for lower propagation latency. This is a hardware-resource optimization, not a deviation from the standard — the table values are simply precomputed RBGC results baked into a ROM or combinational block.
▶ Scalability constraint — For 32-bit or 64-bit counters common in a CA55 environment, storing a precomputed LUT is physically impractical: a full 64-bit table would require 2⁶⁴ entries. The XOR algorithm scales to any bit width with a single pass of combinational logic — one XOR gate per bit — making it the only viable option at these widths.
When Custom Gray Codes Appear
Custom Gray code variants exist for highly specialized applications — certain cryptographic protocols and proprietary sensor interfaces occasionally define custom unit-distance codes. These are rare enough that encountering one in a standard SoC or ASIC design flow is exceptional; they are never the assumed default. If a non-RBGC unit-distance code appears in an IP datasheet, it will be explicitly labeled as such.
Asynchronous FIFO: Gray Code in Production RTL
The canonical use case for Gray code in digital design is the asynchronous FIFO. Two modules operating on independent clocks share a FIFO buffer for data exchange. Read and write pointers in each domain must be made visible to the other domain — but passing a multi-bit binary pointer directly across the asynchronous boundary introduces exactly the glitch and metastability risk described above.
→ Passing the binary pointer directly risks glitches during multi-bit transitions at the clock crossing
→ Converting to Gray code before crossing guarantees at most one bit changes per step — safe for capture by a two-flop synchronizer
→ The receiving domain decodes back to binary before executing full/empty flag comparison logic
This pattern is not CA55-specific. It appears identically in GPU memory fetch pipelines, DDR memory controllers, Ethernet packet buffers, and virtually any subsystem where data crosses a clock boundary. Without correctly implemented asynchronous FIFOs using Gray code pointers, multi-clock-domain SoC design cannot be reliably hardened against metastability.
Key Takeaways
Binary is optimized for arithmetic and logic — it is the native language of computation. Gray code is a transmission wrapper that protects multi-bit values from glitches and metastability when signals cross physical or temporal boundaries.
In precision SoC environments like the CA55, converting a binary counter to Gray code before a clock-domain crossing is not optional — it is a mandatory reliability constraint.
The fact that conversion is standardized on a single mathematical algorithm (XOR) means any IP block from any design team can interoperate safely. A designer implementing Gray code today does not need to invent or validate the encoding — just apply the standard algorithm in RTL (one XOR gate per bit) or call the equivalent library function. The interoperability guarantee is built into the math itself.
References: Arm Architecture Reference Manual · Digital Design and Computer Architecture (Harris & Harris) · IEEE Gray Code Standard
Curating and cross-checking materials on semiconductor and SoC design and verification — each post reviewed before publication.
This post is based on publicly available data and cited sources. Last updated: June 8, 2026
댓글
댓글 쓰기