RTL (register transfer level) design: Question bank

Before we start, one shared vocabulary reminder so nothing below uses an unearned word. Look at the picture first — it is the whole RTL machine on one slate: two registers with a cloud of logic between them, all whipped by one clock line.

Figure — RTL (register transfer level) design

Definition Terms these questions assume

Register / flip-flop: a 1-bit memory that copies its input D to its output Q only at the rising clock edge, and holds it frozen otherwise. In the picture these are the two boxes R1 and R2.
Combinational logic: gates whose output is a pure function of the current inputs — no memory, no clock. That is the cloud between R1 and R2.
Blocking = vs non-blocking <=: two Verilog assignment operators. = updates immediately, in written order; <= reads every right-hand side first, then updates all left-hand sides together (models parallel latching).
Setup / hold time: how long the input must be stable before the edge (setup) and after the edge (hold) for reliable capture.
Critical path: the slowest combinational path between two registers — it decides the fastest clock you can run.

Definition The timing symbols (so nothing below is unearned)

$T$ = the clock period — the time from one rising edge to the next rising edge. It is the whole budget the data has to travel from R1 to R2. In the s02 waveform it is the yellow double-arrow across the top, between the two pink whistle-marks (clock edges).
$t_{c q}$ (clock-to-Q) — after the edge, R1's output does not appear instantly; it takes this long to show up. In s02 it is the left white double-arrow just after the first pink edge.
$t_{co mb}$ — the delay through the logic cloud. Because the cloud has many paths, we care about two extremes: $t_{co mb, m a x}$ = the slowest path (the critical path) and $t_{co mb, m i n}$ = the fastest path (a possible shortcut through few gates). In s02, $t_{co mb, m a x}$ is the middle white double-arrow along the dashed blue trace.
$t_{se t u p}$ — how long R2's input must be stable before the edge. In s02 it is the yellow-shaded band hugging the second pink edge.
$t_{h o l d}$ — how long R2's input must stay stable after the edge. In s02 it is the pink-shaded band hugging the first pink edge, with the fast-path arrow beside it.
$t_{s k e w}$ (clock skew) — the clock edge does not reach R1 and R2 at the same instant; the difference in arrival times is skew. It can help or hurt depending on which register the clock reaches later.
$t_{j i tt er}$ (clock jitter) — the period is never perfectly constant; edges arrive slightly early or late from cycle to cycle. We must budget for the worst early edge.

Formula Where the two constraints come from (derivation sketch — each term tied to the s02 trace)

Watch one bit travel in the s02 figure, left to right. Setup. Start at the first pink edge. R1's output does not move for a while — that gap is the left white double-arrow, $t_{c q}$ . Then the blue trace climbs and holds along the dashed blue line; the length of that dashed segment is the middle white double-arrow, $t_{co mb, m a x}$ . Finally the value must be frozen before the second pink edge, and it must be frozen early by the width of the yellow band, $t_{se t u p}$ . All three must fit inside the yellow top double-arrow, $T$ : $t_{c q} + t_{co mb, m a x} + t_{se t u p} \leq T$ Add the real-world clock terms. Skew and jitter shrink the usable period. If the capturing edge at R2 can arrive earlier than ideal by skew $t_{s k e w}$ and by jitter $t_{j i tt er}$ , the honest budget is: $t_{c q} + t_{co mb, m a x} + t_{se t u p} \leq T - t_{s k e w} - t_{j i tt er}$ Hold. Now look at the first pink edge again. The new data must not race so fast that it corrupts R2 while R2 is still latching the old value. The pink-shaded band, $t_{h o l d}$ , is how long R2 needs the old value to stay put; the fast-path arrow (the fastest arrival, $t_{c q} + t_{co mb, m i n}$ ) must land outside that band: $t_{c q} + t_{co mb, m i n} \geq t_{h o l d} + t_{s k e w}$ Here skew makes hold worse if R2's clock is late. Notice: $T$ appears only in the setup line. That single fact explains why a slow clock cures setup but never hold.

Intuition Timing

exceptions: not every path lives under one period The setup equation assumes data must cross in one clock period. Two common exceptions relax that:

Multi-cycle path — a slow path you deliberately allow N clock periods to settle (e.g. a big multiplier whose result is only read every 3 cycles). You tell the timing tool $T \to N \cdot T$ for that path so it stops flagging a false failure.
False path — a physical connection that can never actually propagate a real transition in normal operation (e.g. a test-mode-only route). You tell the tool to ignore it so it doesn't waste effort or block the clock unnecessarily. These are declared as constraints to Static Timing Analysis, not written in RTL — but a good RTL designer must know they exist, or the tool will report bogus violations.

True or false — justify

Each is a claim. Answer strictly True or False, then explain why — the reason is the answer.

Every wire or reg you name in Verilog becomes a physical flip-flop.

False — only signals assigned inside @(posedge clk) (or with genuine feedback) become registers; combinational wire/assign signals are just gates, storing nothing across a clock.

Using reg in Verilog always means the tool builds a flip-flop.

False — reg is only a simulation datatype (something an always block may assign). A reg driven by always @(*) synthesizes to pure combinational gates, not a register.

assign y = a & b; describes a circuit with memory.

False — assign is continuous/combinational: y is a pure function of the current a and b with no clock, so it cannot remember a past value.

Slowing down the clock can fix a setup-time violation.

True — setup needs

T \geq t_{c q} + t_{co mb, m a x} + t_{se t u p} + t_{s k e w} + t_{j i tt er}

, and a larger period

T

gives the logic more time to settle, so a slower clock relaxes setup.

Slowing down the clock can fix a hold-time violation.

False — the hold constraint

t_{c q} + t_{co mb, m i n} \geq t_{h o l d} + t_{s k e w}

contains no

T

at all, so changing the clock period does nothing; you must add delay on the fast path instead.

The critical path is the longest wire on the chip.

False — it is the path with the largest propagation delay between two registers, which depends on gate levels and load, not raw geometric length.

Non-blocking <= makes hardware run faster than blocking =.

False — both synthesize to the same gates; the difference is purely simulation semantics (order of update), so it changes correctness, not speed.

A synchronous reset takes effect the instant rst goes high.

False — a synchronous reset only acts on the next rising clock edge, since it is just data feeding the flip-flop's D input, gated by the clock.

If the combinational logic between two registers is empty (a direct wire), timing is automatically safe.

False — a direct connection is exactly where hold violations bite, because new data races to the next register with almost zero delay, possibly arriving before the same-edge capture finished.

Adding a pipeline register can never reduce a design's throughput.

False — usually it raises throughput by shortening the critical path, but if the register is placed badly (very unbalanced stages, or it stalls) throughput may not improve, and latency always grows; it is a trade, not a guarantee. See Pipelining.

Clock skew always hurts your timing.

False — skew that makes the capturing register's edge arrive later actually helps setup (more time to settle), while hurting hold; its sign matters, so it is not uniformly bad.

A multi-cycle path is a bug that must always be fixed in RTL.

False — it is a legitimate design intent (a path allowed several clock periods); you declare it as a timing constraint so the tool checks it against

N \cdot T

instead of one

T

Spot the error

Read the described code/intent and name what is wrong and why.

always @(posedge clk) begin a = b; b = a; end — intended to swap a and b.

Blocking = runs in order: a=b first, so b=a reads the new a; both end as old b. Use <= so both right-hand sides read pre-edge values and swap truly.

always @(a) y = a + b; — meant to be combinational.

The sensitivity list is incomplete (b is missing), so a change in b won't re-evaluate y in simulation → sim/synth mismatch. Use always @(*) to auto-include all inputs.

always @(posedge clk) if (en) y <= d; with no else, intended purely combinational.

This isn't combinational at all — it's a clocked, enabled register: when en is low y holds its old value, inferring exactly the flip-flop the author didn't want.

always @(*) if (sel) y = a; (no else), intended combinational mux.

With no else, when sel is false y must "keep" its value → the tool infers an unwanted latch, a transparent memory that breaks the clean combinational model.

Mixing = and <= for the same variable inside one always @(posedge clk) block.

This gives ambiguous, tool-dependent update ordering and is a classic sim/synth mismatch source; keep one style per block — <= for all sequential assignments.

Trying to speed up a design by writing #5 delays inside RTL to "help timing."

# delays are simulation-only and are ignored by synthesis; real timing is fixed by gate delays, so this changes nothing on silicon and only lies to the testbench.

assign a = b; assign b = a; in combinational logic.

This is a combinational feedback loop with no register to break it — it either oscillates or latches unpredictably; combinational signals must be acyclic.

Declaring a genuinely single-cycle path as a multi-cycle path to make timing "pass."

This silences the tool but the silicon still only gets one period, so the chip will produce wrong data at speed — a false relaxation, not a fix.

Why questions

State the reason, not just the fact.

Why do we use <= (non-blocking) for sequential logic but = (blocking) for combinational?

Because real flip-flops all latch simultaneously on the edge — <= models that parallel update — while combinational logic is a step-by-step data flow that = mirrors naturally within one evaluation.

Why is

t_{c q}

(clock-to-Q) in the setup equation but appears with the same sign in the hold equation?

In both cases

t_{c q}

is how long after the edge the source register's output starts moving; for setup that delay eats into the period budget, for hold it delays the earliest-possible arrival — helping hold, hurting setup.

Why do we subtract

t_{s k e w}

and

t_{j i tt er}

from

T

in a realistic setup budget?

Because the capturing clock edge may arrive earlier than ideal (skew) and wander cycle-to-cycle (jitter); budgeting for the worst early edge shrinks the usable period, so we must reserve that time up front.

Why does RTL sit between gate-level and behavioral abstraction?

Gate-level is too low to reason about (thousands of gates by hand) and behavioral is too abstract for tools to map deterministically; RTL — "which register gets which computed value each edge" — is both human-readable and synthesizable predictably.

Why can't you fix a hold violation by pipelining?

Pipelining adds registers to shorten long paths (helps setup); hold is about paths being too short, so inserting registers can even make it worse — the cure is adding delay buffers on the fast path.

Why does splitting "compute" and "store" (combinational math, then one always @(posedge clk)) capture the RTL idea?

Because it directly mirrors silicon: logic gates evaluate a next-value function continuously, and a single register bank samples that value on the edge — exactly the "transfer between registers through logic" definition.

Why does a longer combinational path lower your maximum clock frequency?

Because

f_{ma x} = 1/ (t_{c q} + t_{co mb, m a x} + t_{se t u p})

— a bigger

t_{co mb, m a x}

enlarges the denominator, so the period must grow and the frequency must fall.

Why declare a false path instead of just letting the tool time it?

Because a path that can never carry a real transition would otherwise be reported as a bogus critical path, forcing you to slow the clock for something that physically never happens.

Why is crossing between two clocks a special hazard even in clean RTL?

A signal sampled by an unrelated clock can be caught mid-transition, entering metastability — an undefined in-between voltage that hovers between 0 and 1 (see the wobbling trace in the figure below) — which no single flip-flop guarantees to resolve in time. See Clock domains and metastability.

Edge cases

Boundary and degenerate scenarios the naive model misses.

What happens to timing if

t_{co mb} = 0

(two registers wired directly)?

Setup is trivially met, but you approach the hold boundary

t_{c q} \geq t_{h o l d} + t_{s k e w}

— if clock-to-Q is smaller than hold plus skew, it fails and you must insert delay.

What if two paths reach the same register — a fast one and a slow one?

Setup is governed by the slowest path (

t_{co mb, m a x}

) and hold by the fastest path (

t_{co mb, m i n}

); both constraints must hold simultaneously on the one register.

What does a combinational block with an incomplete if/case (no default) infer at the boundary case where no branch matches?

It infers a latch to "hold" the unassigned value — a degenerate memory element that violates the intended memory-free combinational design.

At the very first clock edge after power-up with no reset, what is a register's value?

Unknown (x in simulation, arbitrary in silicon) — which is exactly why a reset (sync or async) is needed to force a known starting state.

If the clock is stopped entirely (held constant), what do the registers do?

They freeze — with no rising edge, no register updates, so the whole machine holds its last state indefinitely (the basis of clock gating for power saving).

What is the smallest meaningful design that is still "RTL"?

A single flip-flop fed by one combinational function of its own output and inputs (e.g. a toggle) — it already has both required pieces: state plus a next-state function updated on the edge.

If your combinational logic settles exactly at the setup deadline (zero margin), is the design correct?

In theory it just passes, but with zero slack any voltage/temperature/process variation — plus jitter — pushes it into violation; real designs demand positive timing margin, not a knife-edge pass.

When does clock skew flip from friend to foe for a single register pair?

If the capturing edge arrives later than the launching edge, skew adds to the setup budget (helpful) but subtracts from the hold margin (harmful); the same skew helps one constraint and hurts the other.

Recall One-line self-test (with the picture in your head)

Cover everything above. Picture the s01 slate: R1 → logic cloud → R2, one clock line. Ask yourself: "Does this signal need to remember across a clock?" If no it lives inside the cloud (a wire/gate, combinational); if yes it is one of the boxes (a register). Every RTL question here is a variation on that single boxes-vs-cloud distinction plus the realistic timing budget $t_{c q} + t_{co mb, m a x} + t_{se t u p} \leq T - t_{s k e w} - t_{j i tt er}$ .