Control Flow, if, case, and the Traps

SystemVerilog gives you two ways to make a decision. An if else chain evaluates conditions in order, and the first true condition wins, which makes it the natural tool when conditions are arbitrary or can overlap. A case statement compares one selector against a list of values, one branch per value, which makes it the natural tool for a parallel decode: one input, many defined meanings. The rule of thumb working engineers use: deciding on one selector's value, reach for case; deciding among unrelated or overlapping conditions, reach for the if chain. Choosing the structure that matches the decision is the first habit of readable decision logic.

You met the accidental latch on the combinational logic page: leave any path through the block without assigning the output, and the output must remember its old value, so the tool infers storage you never intended. Here is the form that bug actually takes in real code. Real decision blocks drive several outputs at once, and the trap is no longer a missing branch, it is a present branch that assigns two outputs and quietly forgets the third. Every branch exists, the code looks complete, and one output on one path still grows a latch. The defence is an idiom you will use for the rest of your career: assign every output a safe default value in the first lines of the block, before any decision, then override per branch. Do that, and no branch can ever leave an output unassigned, because every output was assigned before the branching began.

A case can carry a qualifier that turns your assumptions into checked claims. Marking a case unique asserts two things: exactly one branch matches any value that arrives, no overlaps, and nothing falls through unmatched. Marking it priority asserts that overlaps are deliberate and the first matching branch is meant to win, while still claiming full coverage. These qualifiers matter because they move your intent out of your head and into the code, where tools can check it and colleagues can read it. A case with no qualifier makes no claims; a qualified case is a small contract, and tools are entitled to complain when the contract is broken.

Two closing traps complete the picture. First, unknowns: an ordinary case matches exactly, so a selector carrying an unknown bit matches none of the value branches and falls through to the default, if you wrote one — the same unknown-bit behavior you saw on Page 03. That is one more reason the default and the assign-first idiom are not optional courtesies. Second, and this is the insight to carry out of the page: an uncovered path in decision logic is not a style issue or a cosmetic gap. It is a functional hardware bug, storage where you meant computation, wrong values that arrive later and get blamed on some other block. The engine on this page treats it exactly the way a professional flow does: it names the latch, and the harness walks every input value to prove nothing was left uncovered.