Code Conversion · Same input, four very different outputs

BCD to Gray Code Converter

Converting a 4-bit BCD digit (0-9) to its Gray code equivalent needs four separate output bits, each a function of the same four input bits. What makes this genuinely interesting: some of those four outputs simplify dramatically once don't-cares are applied, and others don't simplify at all — no matter what you do.

The problem

Standard binary-to-Gray conversion is normally done with XOR: G3=B3, G2=B3⊕B2, G1=B2⊕B1, G0=B1⊕B0. That formula is correct for a full 4-bit binary input (0-15). But a BCD digit only ever takes values 0-9 — codes 10 through 15 are impossible — which opens the door to simplifying beyond the generic XOR formula, for at least some of the four bits.

DigitBCDGray (G3 G2 G1 G0)
000000000
100010001
200100011
300110010
401000110
501010111
601100101
701110100
810001100
910011101

G3 and G2: don't-cares do real work

G3 is trivial — it's always just B3 directly, no gates needed at all. G2 is the interesting one:

G2 = B2 + B3

That's a 2-input OR gate — no XOR required. Checked against every valid BCD digit (0-9), it produces exactly the same output as the full XOR formula B3⊕B2 would. The two only disagree on codes 10-15, which is precisely why the simplification is valid here: those codes are declared don't-care, so it doesn't matter that the simplified version behaves differently there. Outside the guaranteed-valid range, "simpler" and "correct" quietly diverge — which is the whole reason don't-cares need to be genuine impossibilities, not just convenient guesses.

G1 and G0: no simplification available, and that's normal

The lower two bits don't get the same benefit:

G1 = B2′B1 + B2B1′    (i.e. B2 ⊕ B1)
G0 = B1′B0 + B1B0′    (i.e. B1 ⊕ B0)

Both reduce to exactly the standard XOR formula, don't-cares included — because the required 1s and 0s for these two bits are checkerboarded across the map in a way that don't-cares can't help consolidate into larger groups. This is a useful thing to internalize: don't-cares help when they sit adjacent to cells that would otherwise be small isolated groups. If the required pattern is inherently XOR-shaped, no amount of don't-care flexibility changes that — XOR is famously the case K-maps can't simplify around (see the parity checker example for the extreme version of this).

Try G2 live below

The solver is pre-loaded with G2's actual truth table. Try clearing the don't-cares (set 10-15 back to 0) and watch the expression grow back into the full XOR form — a direct, hands-on way to see exactly what the don't-cares were doing.

Input
Karnaugh Map
Minimal Result
Output format
F = 0
Prime Implicant Analysis
Auto-generated Circuit
Universal Gate Conversion

Frequently asked questions

Why does G2 simplify but G1 and G0 don't?

It comes down to which cells the don't-cares (codes 10-15) sit next to. For G2, those don't-care cells happen to sit adjacent to required 1s in a way that lets B3 and B2 alone cover everything needed. For G1 and G0, the required pattern is inherently checkerboarded (true XOR structure), and no adjacent don't-care placement changes that.

Is this specific to BCD, or would any restricted-range binary-to-Gray conversion behave this way?

The specific bits that simplify depend on exactly which codes are valid. BCD (0-9) happens to make G3 and G2 simplify but not G1/G0 — a different restricted range would likely simplify a different subset of bits, or none at all.

What happens if this circuit ever actually receives an input of 10-15?

Undefined behavior — the whole simplification is valid only because those inputs are guaranteed never to occur. If there's a realistic chance they could (a glitch, a bug elsewhere), they're not a genuine don't-care and shouldn't be treated as one; see Handling Don't-Care Conditions in K-Maps.