3.1.12 · D5Boolean Algebra & Logic Gates
Question bank — Don't-care conditions in K-maps
Vocabulary you must have before the traps
We use a handful of words on every line. If any feels vague, this is where they get pinned down.
Now the traps. When an answer says "Rule 1" or "Rule 2", it means the two above.
True or false — justify
A don't-care cell must be assigned a definite 0 or 1 before you begin grouping.
False. Its whole purpose is to stay flexible during grouping; you decide per-group whether reading it as 1 helps enlarge a group, otherwise you leave it out (Rule 1).
Every don't-care in a K-map must end up inside some group.
False. Only the real 1s must be covered; an that helps no group is simply ignored, costing nothing.
Using don't-cares can only ever make the final expression simpler, never more complex.
False. The freedom they offer can only help, but a careless choice can hurt: if you draw a group just to swallow an , that group is a brand-new product term (a new gate) added for nothing. Example: with the single 1 already covered by a large group, wrapping a lone into an extra pair adds a whole term — one more gate than reading the as 0. So misuse genuinely increases complexity; only disciplined use (Rule 1) guarantees improvement.
A group made entirely of don't-cares is legal as long as it is a valid power-of-two block.
False. Geometrically it is a valid block, but it becomes a product term covering nothing you care about — pure wasted hardware, so Rule 2 forbids it.
The same don't-care cell may be covered by two different groups at once.
True. Like a real 1, an can be shared by overlapping groups if that helps both grow; overlap never adds cost.
Don't-cares change the number of minterms that equal 1 in the function's truth table.
False. The function's specified 1s are unchanged; don't-cares are unspecified rows, not extra 1s — you merely gain freedom to treat them as 1 when convenient.
If a K-map has no 1s at all, only don't-cares, the simplest output is (a constant).
True. With no real 1 to cover, you draw no groups, so every may be read as 0 and the whole function collapses to the constant 0 — free hardware (see the edge-case note below for how "unspecified" becomes this concrete choice).
Don't-cares are equally useful whether you minimise as SOP or POS.
True. In SOP you may read an as 1 to enlarge a group of 1s; in POS you may read it as 0 to enlarge a group of 0s — the same freedom, applied to the opposite value.
Spot the error
"I grouped the four don't-cares in the corner into a nice block to reduce terms."
Error: that block covers zero real 1s, so it adds a product term for inputs you never wanted — it increases hardware. Rule 2 forbids all- groups.
"There's an next to my lone 1, so I merged them into a pair — that's always the smaller answer."
Error: merging is only worthwhile if the pair drops a literal you'd otherwise pay for (Rule 1). If that 1 was already inside a bigger group, absorbing the into a separate pair just adds a redundant term.
"Reading every as 1 gives me the most 1s, hence the biggest groups, hence the simplest circuit."
Error: more 1s can force you to cover those cells, splitting groups or adding terms elsewhere. You must choose each 's value to minimise literals, not maximise the count of 1s.
"In BCD the codes 10–15 are don't-cares, so I set them all to 1 in the truth table permanently."
Error: setting them to a fixed value throws away the flexibility. Leave them as so each map/group can pick the value that helps; a permanent 1 might hurt a different output of the same BCD circuit.
"My covering used a don't-care, so I can skip the sanity check on real minterms."
Error: you must still verify every specified 1 is covered and every specified 0 is left uncovered. Don't-cares don't excuse you from checking the defined rows.
"The two 's are at the far-left and far-right of the same row, so they can never be in one group."
Error: a K-map wraps around like a torus, so the left and right edges are adjacent. Those two end cells are neighbours and may form a legal pair — provided the group also contains a real 1 (Rule 1).
"I treated the as 1 in the SOP map, so when I switch to POS I'll treat it as 1 again."
Error: the choice is per-derivation. In POS you're grouping the 0s, so you'd read that same as 0 if that enlarges a 0-group. The cell's flexibility is re-evaluated for each method.
Why questions
Why does absorbing a don't-care into a group of 1s sometimes remove a whole variable from the term?
Because a group's size must be a power of two; adding the can double the group from (say) 2 cells to 4, and each doubling that spans both values of a variable cancels that variable out of the product term (fewer literals).
Why is an all-don't-care group described as "hardware you paid for that does nothing useful"?
Each group becomes a gate producing output for its input combinations. If none of those combinations is a real 1, the gate switches on for inputs the system never intended — cost with no benefit (Rule 2).
Why do impossible-input don't-cares arise so naturally in BCD systems?
Four bits encode 16 patterns but decimal digits only need 10 (0–9), so patterns 1010–1111 are never generated by a valid BCD source — their outputs can be anything.
Why can't you just always ignore don't-cares to "play it safe"?
Ignoring them (reading all as 0) forfeits the free simplification. You'd build a larger, more expensive circuit than necessary — safe in correctness but wasteful in cost, which is exactly what minimisation fights.
Why does the Quine-McCluskey algorithm include don't-cares when forming prime implicants but exclude them when selecting essential ones?
They're allowed into implicants so those implicants can grow larger, but only required minterms (the real 1s) drive the essential-implicant choice — so you never keep a term just to cover an .
Why does using a don't-care never risk producing a wrong output for a case the system actually uses?
By definition the system never presents a don't-care input (or ignores its output), so whatever value your simplified circuit gives for that combination is irrelevant — only the specified rows must match, and those are unchanged.
Why does the torus wrap-around matter specifically for don't-cares?
Because an sitting on a map edge may pair with a 1 on the opposite edge; if you forget the wrap-around you miss a legal, larger group and produce a needlessly big expression.
Edge cases
If a K-map is entirely don't-cares (every cell , no 1s and no 0s), what is ?
The spec leaves unspecified on every input, which means you are free to define it however is cheapest. Since no input ever demands a 1, the cheapest legal completion reads every as 0, giving the constant — zero gates. "Unspecified" becomes "" precisely because minimisation picks the cheapest allowed value.
A function has exactly one 1, surrounded by don't-cares filling the rest of the map. What's the minimal SOP?
You may enlarge the group of that single 1 by absorbing neighbouring s (including across the toroidal edges) up to the largest useful power-of-two block, ideally reducing it to a single literal or even if the whole map can legally read as 1.
Two 1s sit in opposite corners; a don't-care sits between them but merging all three isn't a valid rectangular block. Can the still help?
Only if the forms a valid power-of-two block with one of the 1s (K-map groups must be rectangular blocks of size , edges wrapping allowed). If no legal block includes it, the is useless here and stays uncovered.
A don't-care lies adjacent to a 0 you must keep as 0 in POS. Does that constrain the ?
No — the is never forced. In POS you'd read it as 0 only if it enlarges a 0-group; you're free to read it as 1 (leave it out of 0-groups) if that's better. The neighbouring fixed 0 imposes no constraint on the wildcard.
Can adding more don't-cares to a problem ever make the minimal expression larger?
No. Extra freedom can only keep the minimum the same or reduce it — you're never forced to use a don't-care, so worst case you ignore them and get the same answer as before. (Contrast this with misusing a fixed set of don't-cares, which can enlarge the result — that's a bad choice, not extra freedom.)
If two outputs of a multi-output circuit share the same don't-care input, must both outputs read that the same way?
No. Each output is minimised independently, so the same physical never-occurring input may be read as 1 for one output's map and 0 for another's — the input never arrives, so no conflict exists.
Recall One-line survival summary
Real 1s are the only cells you must cover; each is a free wildcard you may read as 1 (SOP) or 0 (POS) only when it enlarges a group that already holds a real 1 (Rule 1) — never a group of 's alone (Rule 2). When an helps no group, you read it as 0 (SOP), which is why an all- map minimises to .
Connections
- Parent: Don't-care conditions in K-maps — the concepts these traps test.
- Karnaugh Maps (K-maps) — the grid, Gray-code adjacency and toroidal wrap-around.
- Sum of Products (SOP) and Product of Sums (POS) — read as 1 for SOP, 0 for POS.
- BCD - Binary Coded Decimal — where impossible-input don't-cares come from.
- Quine-McCluskey Method — how don't-cares enter implicants but not the essential set.
- Boolean Simplification — the payoff for using wildcards well.
- Logic Gates & Hardware Cost — why an all- group is wasted silicon.