Interview Review Checklist

Six gates asked whether a design is ready. This one asks whether an engineer is — and it is a technical self-review, not a scorecard.

1. The One-Sentence Model

Interview readiness means you can derive the answer after the question changes — a memorised answer works only for the wording you rehearsed; understanding survives the follow-up.

That is the whole distinction this chapter turns on. "How many credits do you need?" has a memorised answer for the case someone practised and a derivation that works for any case (§6). An interviewer who hears the first will change the numbers, and the difference becomes visible in one question.

So this chapter is organised around what you can reconstruct, not what you can recall. Seven derivations (§6), five whiteboard-sized mechanisms (§7), and thirty questions presented with the weak answer and the follow-up that exposes it (§14) — because knowing how an answer fails is more useful than knowing how it goes.

2. What This Gate Owns

Three things this chapter deliberately is not.

It is not a cram sheet. 25.1–25.10 are the interview-mastery module and they teach the material. This is a review — a structured way to find out what you cannot yet derive, in the same spirit as the six gates before it.

It is not a scoring system. §15's rubric has four levels because a self-review needs vocabulary for "where am I", not because anyone should have a number. There are no points, no badges and no percentage.

And it is not a substitute for the modules. A gap found here is a pointer back to a chapter, and every row in §4 says which one.

3. Sourcing and Uncertainty Discipline

4. The Revision Matrix

Fourteen domains. For each: what you must be able to explain, draw, code and debug — and the trap that catches most candidates.

Three readings.

The "must draw" column is the one candidates skip and interviewers use most. A whiteboard exposes structure instantly: someone who can describe the three layers but cannot place FDI and RDI on a diagram has learned the words rather than the arrangement.

The "must debug" column separates the levels more sharply than any other. Explaining flow control is common; being handed a symptom and reasoning to the contract that broke is not (§11).

And the trap column is where preparation pays best, because each trap is a plausible answer. "Credits are buffers" and "a retry is a duplicate" are both nearly right, which is why they survive self-study and fail in a room.

5. Three Depths for Every Topic

A good answer is the right size. Practise each major topic at three lengths, because an interviewer chooses the length by how they ask.

Worked example — "What is UCIe?"

15 seconds. "An open standard for die-to-die interconnect inside a package — it lets chiplets from different sources connect over a standardised physical and link layer, with existing protocols mapped on top."

90 seconds. Add the problem: multi-die products existed long before the standard, but each vendor's die-to-die interface was proprietary, so dies could not be mixed across suppliers. Add the structure: a physical layer, an adapter, and protocol layers with established protocols mapped onto it — so the ecosystem reuses existing protocol stacks rather than inventing new semantics. Add the boundary: it is a link, not a fabric — it moves bits across one die boundary and does not own coherence, routing or system topology (23.3 §5).

Whiteboard. Draw the stack; mark which layer owns framing and integrity, which owns reliability if it is provided, and which owns semantics. Then say the sentence that shows you understand scope: "everything above this line is a property of the system graph and cannot be owned by a link."

Three readings.

The 90-second version leads with the problem, not the feature list. "It supports X GT/s and these protocols" is a datasheet. "Proprietary die-to-die interfaces prevented multi-vendor chiplets" is an explanation — and every follow-up flows naturally from it.

The whiteboard version's value is in the ownership labels, not the boxes. Three rectangles are worth nothing; three rectangles with "who owns reliability?" answered is a senior answer.

Second worked example — "Explain flow control." The same topic at three sizes, because this one is asked at all three.

15 seconds. "Credits are permission to send. A sender may only transmit when it holds a credit for the receiving resource, and the receiver returns credits as that resource frees — so the sender can never overrun it."

90 seconds. Add what a credit is not: "a credit is permission, not a buffer — the buffer is what the credit refers to, and conflating them is where most bugs start." Add the invariant: issued + available = configured total, always. Add the failure shape: "a leak degrades monotonically — one lost return per million transactions is invisible in a short test and fatal in a soak, because credits only ever drift one direction." And add the sizing question, because it is the natural follow-up: "how many you need is rate × round-trip, not a fixed number."

Whiteboard. Draw the loop — sender, link, receiving resource, return path — and label where each credit is consumed and where it is returned. Then mark the three failure points explicitly: returned too early (the resource is not actually free, so the receiver overruns), returned twice (the invariant breaks upward and the sender oversends), and never returned (the invariant breaks downward and the link wedges). Finish with the diagnostic: "the conservation check catches all three at the cycle they happen; a timeout catches them thousands of cycles later" (27.6 §6).

Notice what the 90-second version does that the 15-second one cannot: it states what the thing is not, which is where the common misconception lives (§14 row 7). Almost every good 90-second answer contains a negation.

And the same three-depth drill works for every major topic — credits, recovery, UVM architecture, partitioning, debug. Practising only the long version is the most common preparation mistake, because the interviewer often asks the short one first.

6. The Derivation Test

Seven results a senior candidate reconstructs rather than recalls. If you can derive them, the numbers in the question can change and your answer still works.

D1 — required outstanding. "How many credits do we need?"

required ≈ target_rate × round_trip_latency

Derive it in units. Rate in operations per cycle, latency in cycles → the product is a count of operations. Worked: target 1 op/cycle, round trip 20 cycles → 20 outstanding. With 8, the ceiling is 8/20 = 0.4 op/cycle (27.4 §17) — 40 % of target, with a perfectly correct design.

D2 — credit conservation. Credits are permission to send, not storage.

issued + available = configured_total, always

A violation is a leak or a double-return, and it degrades monotonically — so a soak test fails at hour nine and a short test never does (25.6 §10).

D3 — a retry is not a semantic duplicate. There are three identities: the semantic operation, the transport object, the physical attempt (25.5 §11). A retry increments the attempt and must not touch the semantic ID. Derivation: if a retry allocated a new semantic identity, a coherent write would be applied twice with every CRC passing — which is the failure the layering exists to prevent.

D4 — link ACTIVE is not function ready. Readiness is seven ordered conditions: present, powered, clocked, reset released, link ACTIVE, configuration valid, semantically ready (26.5 §13). ACTIVE is level 5. Derivation: the transport being usable and the function being usable are separated by configuration commit, which happens on a different die on a different timeline — hence the "fails only on the first access after boot" race.

D5 — physical route is not logical identity. They coincide until a failover or remap separates them (26.5 §19). Derivation: if a response is correlated on the link it arrived over, a failover makes valid responses arrive on the "wrong" link — so they are rejected, and the availability feature becomes the cause of the hang.

D6 — a predictor must be independent. An environment is only checking something when the expected value comes from somewhere other than the thing being checked (27.3 §7). Derivation: if expected is derived from the DUT's output, a dropped transaction produces no expectation and a duplicated one produces two matching expectations — both bugs pass.

D7 — the first error is not the first divergence. (27.6 §6.) A credit return goes missing at cycle 1 000; a timeout fires at 44 000. Derivation: designs detect conditions they were built to detect, and a timeout is a consequence. Hence the rule: capture invariant violations, not symptoms.

And one meta-observation worth internalising. All seven derivations are two or three sentences long. That is why they survive a changed question — there is nothing to misremember, and an interviewer who alters the numbers or the framing is met with the same reasoning.

7. Five Whiteboard-Sized Mechanisms

Small enough to write correctly under pressure, and each one carries a principle. Reproduce them from understanding, not memory.

W1 — a counter with simultaneous increment and decrement.

// The classic. An else-if chain here LOSES the decrement whenever both fire,
// drifts upward, and wedges at the limit with an empty queue (27.2 §8).
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) occ_q <= '0;
  else        occ_q <= occ_q + 16'(alloc_fire) - 16'(free_fire);
end

Say while writing it: "one register, one next-state expression — because these two events are independent, not prioritised."

W2 — the accepted-event gate.

// valid means "I have something"; valid && ready means "it moved".
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n)                  count_q <= '0;
  else if (valid && ready)     count_q <= count_q + 32'd1;
end

Say while writing it: "counting valid alone counts each stalled cycle again — under 50 % backpressure the number is 2× reality" (27.4 §10).

W3 — an outstanding-ID bitmap.

// Allocation gated by availability. The bitmap IS the concurrency limit, so
// its width is D1's derivation made concrete.
logic [N_ID-1:0] busy_q;
assign can_issue = !(&busy_q);
 
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) busy_q <= '0;
  else begin
    if (issue_fire)  busy_q[alloc_id] <= 1'b1;
    if (retire_fire) busy_q[retire_id] <= 1'b0;
  end
end

Say while writing it: "N_ID is not a free parameter — it is rate × latency from D1, and an ID must not be reused while the peer may still hold it."

W4 — atomic configuration commit (the concept).

// Shadow -> all peers prepared -> quiesced -> ONE-cycle swap + epoch bump.
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    active_cfg_q <= CFG_DEFAULT; cfg_epoch_q <= '0;
  end else if (commit_fire && all_prepared && (outstanding == '0)) begin
    active_cfg_q <= shadow_cfg_q;          // atomic: one cycle, whole config
    cfg_epoch_q  <= cfg_epoch_q + 1'b1;    // stale requests become detectable
  end
end

Say while writing it: "the quiesce is what makes the epoch check an assertion rather than a repair mechanism — and there must be exactly one committer" (27.5 §11).

W5 — sticky first-fault capture.

// The !valid guard is the entire difference between a usable register and one
// that reports the last consequence of a cascade (27.6 §9).
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n || ff_clear) begin
    ff_valid_q <= 1'b0; ff_count_q <= '0;
  end else if (fault_detected) begin
    if (!ff_valid_q) begin
      ff_valid_q <= 1'b1; ff_class_q <= fault_class;
      ff_id_q <= fault_id; ff_time_q <= cycle_q;
    end else ff_count_q <= ff_count_q + 16'd1;   // count, never overwrite
  end
end

Say while writing it: "note the reset expression — a link reset must not clear this, or the recovery erases the cause of the failure that triggered it."

And the meta-point about all five. Each is under ten lines and each has exactly one line that is easy to get wrong: the signed expression, the ready term, the reuse rule, the quiesce condition, the !valid guard. Writing the code is not the demonstration — narrating that line is.

8. Code-Review Prompts

A common senior format: you are handed fifteen lines and asked "review this." It tests whether you read code for events and lifetimes or for style — and it is the fastest way an interviewer distinguishes a reviewer from a coder.

The method to say out loud before you start (27.2 §3): "I'll look at three things — what events write each register and whether any two can coincide; what happens at zero, at maximum and after a reset; and whether the accepted event is the transfer or the offer."

Exhibit A.

always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n)          occ_q <= '0;
  else if (alloc_fire) occ_q <= occ_q + 16'd1;
  else if (free_fire)  occ_q <= occ_q - 16'd1;
end

What to say. "else if is a priority encoder and these two events are independent. When both fire the decrement is unreachable, so the count drifts upward and never recovers — it wedges at the limit with an empty queue, thousands of cycles after the first coincidence. One register, one next-state expression." Then add the invariant: occ_q == alloc_total - free_total, which fires on the first coincidence rather than at hour nine.

Exhibit B.

assign credits_avail = credit_limit_q - credits_used_q;   // 8-bit unsigned
assign can_send      = (credits_avail != 8'd0);

What to say. "Unsigned subtraction with no clamp. If used ever exceeds limit — one double-count, one credit returned twice — then 4 - 5 is 255, not −1, and can_send asserts. The design goes from correct backpressure to unlimited sending in one cycle, and the receiver overruns: data loss, not a stall." Then the senior addition: "clamping alone isn't the fix — it would hide the accounting error forever. I'd clamp, add a sticky violation bit, and assert credits_used <= credit_limit so the root cause is caught rather than the overrun."

Exhibit C.

if (cmpl_fire) txn_live_q[cmpl_idx] <= 1'b0;

What to say. "Retirement on the index alone. There's no check that the entry is live and no generation comparison — so a completion from a previous use of that slot retires the transaction currently occupying it. The real transaction then times out and looks like a drop, which sends debug to the wrong subsystem." The follow-up you should pre-empt: "and this is exactly the state a link reset creates if ID allocation restarts while the peer still holds the old identities."

Exhibit D.

always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n || !link_rst_n) begin
    err_valid_q <= 1'b0;
    err_code_q  <= ERR_NONE;
  end else if (error_detected) begin
    err_code_q  <= error_class;
    err_valid_q <= 1'b1;
  end
end

What to say — two findings, and naming both is the point. "First, it's last-error-wins: every error overwrites, so after a cascade this register holds the final escalation — usually a timeout, which is consistent with a dozen root causes. Second, and worse, link_rst_n is in the reset expression — so the recovery triggered by the fault erases the record of the fault. The field will only ever report failures that didn't trigger a reset." (27.6 §9, §16.)

Three readings on the format itself.

Name the failure, not the rule. "You should use one next-state expression" is a style comment. "When both fire you lose the decrement, drift upward, and wedge with an empty queue" is a review finding — and only the second demonstrates that you know why the rule exists.

Say what you would add, not just what is wrong. Every exhibit above has a natural assertion or counter attached, and volunteering it moves you from spotting bugs to preventing them.

And if you genuinely cannot see anything, say what you checked. "Events look independent and correctly gated on the transfer; the reset scope looks right; what am I missing?" is a far better answer than silence — it shows the method even when it did not fire.

9. SVA — Explain, Do Not Memorise

Three readings.

The disable iff question is the best single SVA interview probe, because the wrong use is plausible. disable iff (!rst_n || err_active) looks like it ignores reset. It also disables the property during every error condition — which is exactly when retention behaviour matters (27.2 §17).

Vacuity is where "we have 200 assertions" collapses. A property whose antecedent never occurs passes forever and proves nothing — and the fix is one line, a cover property on the antecedent.

And the strongest thing to volunteer, unprompted: "an assertion that has never failed during development is suspicious rather than reassuring — I'd deliberately break the RTL to confirm it fires." That single sentence separates candidates who write assertions from candidates who trust them.

10. UVM — the Six Questions

Three readings.

Row 1 is the question a serious interviewer opens with, and the best answer names the topology: "I'd read connect_phase — independence is a property of the wiring, not of file organisation."

Row 5 catches more candidates than it should. "The sequence completes" is a natural answer and it means the driver stopped driving, not that the protocol finished. Killing the simulation with transactions in flight makes every incomplete entry indistinguishable from a real drop.

And the senior addition to row 4 is mutation testing: "and I'd prove the scoreboard can fail — inject a duplicate delivery and confirm it reports an orphan" (27.3 §22). Unprompted, that answer changes the interview.

11. Debug — Start From the First Failed Contract

The single most common weak answer in a debug question is "I'd look at the waveform." It is not wrong; it is unstructured, and it does not scale past a small block.

The structure to use instead.

Worked example — throughput collapse.

Step 1. Contract: sustained N ops/cycle. Observed: 0.4N. Correctness contracts are intact — no drops, no errors. So this is a performance failure, not a functional one, and that halves the search space immediately.

Step 2. Walk the staged counters in order: offered → accepted → transmitted → delivered → retired (27.4 §8). The first stage whose rate falls below target is the boundary. Upstream of it queues are full; downstream they are empty.

Step 3. If nothing is full anywhere, the discriminating counter is stalled-on-no-free-ID/credit — the signature of a concurrency window rather than congestion (D1). If the upstream queue is full and no-credit is high, it is flow control. If a single channel is at maximum occupancy and the rest are idle, it is distribution (26.4 §9).

Step 4. A good experiment predicts two different outcomes. "Increase the outstanding limit: if the window is the constraint, throughput scales roughly linearly; if congestion is the constraint, it does not move."

Step 5. State the limits. "I can conclude the constraint is at this boundary. I cannot yet conclude whether the round-trip latency is inherent or a queueing effect — that needs the latency distribution split into queueing and service" (27.4 §14).

And the same five steps handle a hang. Step 1: which obligation is outstanding and unfulfilled? Step 2: which side believes it is owed? Step 3: obligations_outstanding_at_recovery on both dies — the discriminator for a retention disagreement (27.5 §8). A candidate who reaches for that counter rather than a waveform is demonstrating exactly what Module 27 teaches.

12. The Architecture Whiteboard

A common senior prompt: "Here is an SoC — CPU cluster, accelerator, memory subsystem, I/O, management. Partition it into chiplets."

What a weak answer does. Draws boxes immediately, splits by functional block, and justifies it with "chiplets allow different process nodes."

What a strong answer does — talk before drawing.

Three readings.

There is no single correct partition, and saying so is part of a strong answer. 26.1 and 26.2 are two shipping products with opposite partitions — replication versus function — and both are right for their pressures. A candidate who states their assumptions and derives a partition from them is doing the job; one who produces the answer is not.

The two cuts that are almost always defensible are I/O separated onto a mature node and compute on the leading node. Starting there and then arguing the harder cuts shows judgement about which decisions carry risk.

And the answer that marks seniority is naming what you would not cut and why (26.1 §12). Declining a boundary is a decision, and most candidates only justify the boundaries they drew.

13. Uncertainty Discipline

Accuracy under uncertainty is an interview strength, and fabrication is the fastest way to lose a room.

Three readings.

Every strong answer has the same two-part shape: name the boundary of your knowledge, then continue with what you can reason about. Stopping at "I don't know" gives up the question; continuing without the caveat risks being wrong with confidence. The combination is what a senior colleague sounds like.

Row 3 is a specific and testable discipline this curriculum has practised throughout. "Company X ships chiplets" and "company X ships UCIe" are different claims, and a candidate who separates them has demonstrated evidence handling — which is a rarer skill than protocol recall.

And row 5 matters more than it looks. An interviewer who corrects you is often testing whether you can update. Defending a wrong position costs far more than the original error did.

14. Thirty Questions, With the Weak Answer and the Follow-Up

Foundations and scope

Flow control and identity

Reset, recovery, integration

RTL, verification, performance, debug

And the pattern across all thirty is worth naming. Every weak answer is nearly right — a buffer is nearly a credit, a reference model is nearly independent, 98 % utilisation is nearly good news. The follow-up column is where the difference appears, which is why practising the follow-ups is more valuable than practising the answers.

15. Readiness Rubric

Four levels, for orientation rather than scoring. There are no points.

Three readings.

The Strong→Senior step is not more knowledge — it is more scepticism about your own answer. Deriving the required window is Strong; asking "what latency did that assume, and who owns that number?" is Senior (27.1 §9 D4).

The Debug column separates levels most reliably, because it cannot be prepared by memorisation. Reasoning to a first divergence requires the framework, and stating what cannot be concluded requires confidence.

And the Uncertainty column is the one to fix first if it is weak, because a single fabricated answer damages every correct one that follows. It is also the fastest to improve — it is a habit, not a body of knowledge.

16. Final Whiteboard Simulation

The prompt. "A multi-die accelerator reaches ACTIVE and passes light traffic. Under heavy load, throughput falls well below target — and one transaction hangs after a recovery event. Walk me through it."

A strong answer does not start with a cause. It starts by splitting the problem.

Step 1 — separate the two failures. These are probably two different problems and must be treated as such. The hang is a correctness failure — an obligation outstanding and unfulfilled. The throughput shortfall is a performance failure. A single explanation covering both is a hypothesis, not a starting point, and assuming one is how investigations go wrong early.

Step 2 — the hang, because correctness comes first. Which side believes it is owed something? A transaction outstanding after a recovery is the classic retention disagreement (27.5 §8): one die retained the obligation and waits for a response; the other discarded it and waits for a re-issue. Both are defensible readings, and the specification may not have chosen.

The discriminator is two counters on each die (27.6 §13): obligations_outstanding_at_recovery, reissued_after_recovery, completed_after_recovery. A shows 1 retained and 0 re-issued; B shows 1 discarded and 0 received — and the disagreement is explicit in one read per side. Also check first-fault capture on both dies, and confirm it survived the recovery (27.6 §16) — if the recovery cleared it, that is a second finding.

Step 3 — the throughput shortfall, with a counter walk. Offered → accepted → transmitted → delivered → retired (27.4 §8). The first stage whose rate falls below target is the boundary.

Then split by symptom. If nothing is full anywhere — link idle, receiver idle, source ready and blocked — it is a concurrency window (D1), and the confirming counter is stalled-on-no-free-ID/credit. If the upstream queue is full and no-credit is high, it is flow control; check the conservation invariant (D2), because a leak degrades monotonically and "falls under heavy load" is consistent with it. If utilisation is high but useful throughput is not, split retry bytes from useful bytes (27.4 §11).

Step 4 — consider whether they are related after all. One mechanism connects them: if the recovery left an obligation permanently outstanding (step 2), that entry never releases its credit or its ID. Every recovery then leaks one unit of concurrency, so throughput degrades progressively and the window shrinks under load — exactly the reported symptom. The confirming evidence is credits or free IDs trending down across recovery events, which is a snapshot comparison rather than a new experiment.

Step 5 — the experiment, with two predicted outcomes. "Run the load without inducing recoveries. If throughput recovers to target, the two symptoms share a cause — the leak. If throughput is still low, they are independent and the window was under-sized from the start." One experiment, two distinguishable results.

Step 6 — state what cannot be concluded. "I cannot yet say whether the retention behaviour is a specification gap or an implementation bug — that requires both sides' written answer, not more data (27.5 §4). And if the counters in step 2 don't exist, I can't discriminate at all — which would itself be a finding against the observability gate" (27.6 §3).

What makes this a senior answer, in four points: it separates correctness from performance before theorising; it names specific discriminating counters rather than "look at the waveform"; it proposes one experiment with two predicted outcomes; and it states its own limits, including the possibility that the necessary evidence was never designed in.

17. Module 27 Complete — the Seven Gates

Three readings that tie the module together.

Every gate has the same evidence standard (§14 of each chapter, in its own words). A review statement is not evidence. "Retry is tested", "bandwidth meets spec", "both dies are compliant", "we have error registers" — each is a sentence that ends a conversation and closes nothing. The accepted form always names what was applied, what independently checked it, and what proves the check can fail.

And every gate has the same three decisions (27.3 §3), with the same trap: CONDITIONAL PASS must not become a polite FAIL. The mechanical test is whether a downstream gate could proceed assuming the item closes — if not, it is blocking.

The failures compound in a specific order, which is why the gates are ordered as they are. An unanswered architecture question produces two correct implementations (27.2 passes both), two green verification runs (27.3 passes both), and a product that hangs at integration (27.5). Each gate catches what the previous one structurally cannot — and 27.6 decides whether you will be able to find out which one it was.

18. Understanding Check

19. Summary

Seven things.

Derivation beats recall (§1, §6). Seven results, each two or three sentences long — required outstanding, credit conservation, retry versus duplicate, ACTIVE versus ready, route versus identity, predictor independence, first error versus first divergence. Nothing to misremember when the question changes.

Answer at the right size (§5). Fifteen seconds to scope, ninety to explain the problem before the features, and a whiteboard that labels who owns what rather than drawing boxes.

Five mechanisms, each under ten lines (§7) — and in each, narrating the one risky line is the demonstration, not writing the code.

Debug starts from the first failed contract (§11), not the waveform: which contract, which boundary, which counter discriminates, which experiment has two predicted outcomes, and what cannot be concluded.

Partitioning has no single right answer (§12). State the assumptions, work the scorecard, and name what you decided not to cut.

Uncertainty discipline is a strength (§13). Bound your knowledge, then continue with what you can reason about — and separate "ships chiplets" from "ships UCIe".

And the thirty weak answers are all nearly right (§14). A credit is nearly a buffer; a reference model is nearly independent; 98 % utilisation is nearly good news. Practise the follow-ups, not the answers.