Question bank — Combinational logic in HDL

False — feedback that holds a value is memory; once a wire's value depends on its own past, you have a latch or a combinational loop, not pure out = f(inputs).

False — a continuous assign is a permanent equation always driving its target, so the output is never "left unassigned"; latches only sneak in through incomplete procedural blocks.

Often but not always — for a single independent output it may still synthesize correctly, yet it can cause simulation mismatches and wrong results when one line depends on another, so it is banned by convention.

Only if every possible value of the selector is truly listed; for an $n$-bit selector that means all "two-to-the-n" patterns — missing even one (or ignoring x/z in simulation) leaves a path unassigned, so a default is the safe habit.

True for that exact case — @(*) just auto-builds the same list; they diverge only when you later add a read and forget to update the manual list.

False — a default followed by a conditional override is the recommended latch-avoidance pattern; blocking = makes the last assignment win, so the output is fully defined on every path.

False — the right-hand side reads the same output y it is writing, so y depends on its own past value; the tool cannot resolve y from inputs alone and reports a combinational loop (and depending on the tool may infer a latch instead). Note the distinction: many synthesizers flag the loop separately and do not silently insert a latch.

No else, so sel==0 leaves y unassigned; the tool inserts a transparent latch to hold the old y. Add else y = ...; or a default before the if.

The sensitivity list omits b; simulation won't re-run when b changes, so sim shows a stale y while synthesized gates use both inputs — a sim-vs-silicon mismatch. Use @(*).

Order is backwards for blocking =: y reads t before t is computed, so y uses the previous t. Compute t first, then y.

Two continuous assigns drive the same net; they fight, producing an x (unknown, from contention) in simulation and multiply-driven-net errors in synthesis. One net, one driver.

Only 2 of 4 selector values are covered; for sel = 2'b10 or 2'b11 y is unassigned ⇒ latch. Add default: y = ...;.

A posedge clk edge event makes this sequential (it registers on the clock), not combinational; the output changes only on clock edges, adding a flip-flop you didn't want here.

z is assigned from w, but w is never driven, so w floats (z in simulation) and z copies that unknown/floating value. y here is fine (default covers every path); the bug is the undriven source w — every signal you read must be driven somewhere.

Because "keep the old value" is a valid meaning the tool can implement — and the only hardware that holds a previous value is storage, so it faithfully builds a latch instead of guessing you made a mistake.

It executes immediately and in written order, exactly mirroring how a signal ripples through chained gates within one instant, so intermediate wires carry their new values to later lines.

It defers all updates to the end of the time-step, so every flip-flop reads the old values and updates together on the edge — matching real registers that all sample simultaneously.

It re-derives the sensitivity list from every signal actually read, so you can never accidentally omit one; the simulator then re-evaluates on any relevant change, keeping sim behaviour equal to the synthesized gates.

Combinational logic is a Boolean function; nailing the function first guarantees you cover every input case, which is precisely what stops unassigned paths and latches. See Boolean algebra and Karnaugh maps.

The default assigns the output on entry, so even if no branch fires the output already holds a fresh, defined value — every path ends assigned, so no memory is needed.

It adds an unclocked, level-sensitive memory element that creates timing hazards, races, and static-timing paths that are hard to close, plus it can glitch through while transparent. See Synthesis and the digital design flow.

@(*) with no reads triggers once and holds; the synthesized result is simply a constant 1 driver — legal and latch-free, since the single path always assigns y.

In synthesis it's fine (real signals are 0/1), but in RTL simulation an x selector matches no branch and can leave y stale, giving a misleading sim latch — a default removes the ambiguity.

No — latch inference is per-signal; only the unassigned output gets a latch, the fully-driven ones stay combinational. So audit each output separately.

Still a latch — coverage is about input combinations, not about "there exists an assignment"; if any reachable input pattern skips all assignments, that output holds and infers a latch.

For synthesis it's technically complete, but keeping default is best practice: it protects against x/z in simulation and against later widening of the selector, costing nothing. Contrast with a MUX where the ternary ?: covers both cases inherently.

Different — a self-referencing combinational expression is usually reported as a combinational loop, which many tools flag as its own error rather than silently inferring a latch; a latch specifically comes from an incomplete assignment (a missing path), not from feedback.

Yes — a module can hold separate blocks: combinational ones use =, clocked ones use <=. The rule is per-block, not per-module. See Sequential logic in HDL and Blocking vs Non-blocking assignments.

Not a latch but a logic bug — with blocking =, reading a variable before its assignment uses a stale/previous value, producing wrong combinational output; reorder the statements so producers precede consumers.