Question bank — Sequential logic and always blocks

False. It is event-driven: it executes its body exactly once per rising clock edge, then sleeps until the next edge. The word "always" describes availability to react, not repetition.

False. If an output is not assigned in every branch, the synthesizer infers a latch to hold the old value — accidental memory, even though you wrote no clock.

False. That describes blocking =. Non-blocking evaluates all right-hand sides using old values first, then updates all left-hand sides together — modelling parallel flip-flops.

False (subtle). One isolated flop may simulate fine; the danger appears with multiple registers where ordering leaks new values between them. It is still a bad habit because it invites mismatch the moment you add a second register.

False. Putting rst in the sensitivity list makes it asynchronous — the block wakes on rst rising independently of the clock. A synchronous reset keeps only clk in the list.

False. negedge rst_n is a perfectly standard active-low async reset: the flop clears when rst_n falls to 0, matching the common convention where the reset line rests at 1 and is pulsed low. Inside the body you then write if (!rst_n) q <= 0;.

False. Counting requires remembering the previous value, which pure combinational logic cannot do — its output depends only on current inputs. You need a clocked flip-flop to store the running count.

False. Two drivers on one register create a race / multiple-driver error. One register must have exactly one always block that owns it.

False — and here is the concrete failure. Consider always @(*) begin temp <= a; y = temp; end. With <=, temp updates at the end of the time-step, so y reads the old temp on this pass — simulation shows a one-delta-cycle stale y. Synthesis, however, has no notion of delta cycles: it wires y directly from the new temp. The two disagree → a sim/synth mismatch. Blocking = keeps in-block order = data flow, so both agree. Rule: combinational → =.

Blocking = updates q2 first, so line 2 reads the new q2 (= q1). The two stages collapse into one — you get a single flop, not a shift. Fix: use <=.

The sensitivity list misses a and b. Simulation only re-evaluates when sel changes, so y goes stale when a or b change, while synthesis builds a real mux → mismatch. Fix: always @(*).

An inferred latch: when en is 0 there is no assignment, so y must "remember" its previous value. Usually a bug. Fix: add else y = 0; or a default y = 0; at the top.

There is no else q <= d;, so q is only ever cleared, never loaded. The flop captures nothing. Add the else branch for normal capture.

rst is listed as a level, not an edge. Async control signals must be given as posedge rst (or negedge rst_n for active-low) so the block reacts to the transition, matching the flip-flop's async set/reset port.

A multiple-driver / race condition — the value of count becomes ambiguous. Consolidate into one block that fully owns count.

Reset must have priority: it should override normal capture. Checking it first makes reset dominate whenever it is active, which is the intended safety behaviour.

Async reset must act the instant rst changes, so the block needs to wake on that edge — hence it's in the list. Sync reset should only take effect on a clock edge, so it stays out and is tested inside the clocked body.

Convention and safety: a line that rests high and asserts low is naturally held reset by a pull-down during power-up glitches, and matches most vendor cells. Functionally it is identical to active-high — only the asserted polarity and the if (!rst_n) test differ.

Real flops all sample their inputs at the same instant using pre-edge values, then update simultaneously. <= reproduces this by reading every RHS first, then writing every LHS — no line sees another's new value.

The * auto-includes every signal read in the block, so you can never forget one. A hand-written list that misses a signal causes stale simulation output and a synthesis mismatch.

A mux has no memory; it must respond instantly to any input change. Triggering on a clock edge would wrongly delay and register its output.

Because all storage updates happen only at the same clock edge, every stage sees a well-defined, stable value — removing timing chaos and making the whole system's state advance in lockstep.

Still a proper edge-triggered flip-flop (it lives in @(posedge clk)), but a broken one — it can be reset yet never loaded. The concern here is missing function, not a latch. Inferred latches come from @(*) blocks, not clocked ones.

Legal — it builds a flip-flop that samples on the falling ($1\to 0$) edge instead of the rising edge. Valid, but mixing edge polarities across a design complicates timing; keep it deliberate.

Because "active-low" means the reset is asserted when the line is 0. !rst_n is true exactly when rst_n == 0, so that branch fires during reset — matching the negedge rst_n that woke the block.

q captures whatever d holds, which in simulation is often x (unknown) and propagates. This is why real designs use a reset to force a known starting state before relying on outputs.

In simulation the if (rst) branch wins because it is tested first, so reset appears to dominate. But this exact-coincidence outcome is not guaranteed by the Verilog LRM — it depends on the simulator's event scheduling and, in silicon, on real setup/hold timing near the reset-release edge. Never rely on it: use a proper reset-synchronizer so reset de-assertion is clean. See Clocking and timing constraints.

If the same block leaves the output unassigned on some path, yes, that block infers a latch. The fix is a default assignment at the top so every path defines the output.

A synchronous reset — rst is left out of the sensitivity list and tested inside @(posedge clk), so it only takes effect on a clock edge. See Clocking and timing constraints for the timing trade-off.