Architecture Tradeoffs

Chapters 25.3 to 25.6 answered questions that have a right answer. This one does not — and the interviewer knows it. What they are watching is how you get to a defensible one.

1. What They Ask

"Here's a rough SoC. Partition it into chiplets."

Or: "Where would you put the die boundaries?" · "Would you split this?" · "You have four blocks and a package budget — go."

It is the senior prompt, it is open-ended on purpose, and the most common way to lose it is to start drawing in the first thirty seconds.

2. The One-Sentence Model

A good chiplet boundary separates implementation ownership without creating a high-rate, latency-sensitive semantic dependency across the package.

Everything in this chapter is that sentence unpacked. "Implementation ownership" is why you split (§12); "high-rate, latency-sensitive semantic dependency" is why you must not (§9, §10) — and the second clause overrides the first.

3. What They Are Really Testing

And the first row is worth more than the rest combined. An interviewer running this prompt has watched dozens of candidates draw boxes immediately. Asking six good questions first puts you in a different category before you have proposed anything.

4. Sourcing

5. The First Sixty Seconds — Ask, Do Not Draw

This is the single highest-value habit in the chapter.

INTERVIEWER:  "Here are five blocks. Partition them."
 
WEAK:         [walks to the board and starts drawing]
 
STRONG:       "Before I draw anything, can I ask a few things? They'll
               change the answer a lot.
 
                - What's the dominant workload? A partition that's right
                  for streaming is wrong for pointer-chasing.
                - Do we have a rough traffic matrix between these blocks —
                  even relative magnitudes?
                - Are any of those edges in a tight dependent loop, where
                  one block waits on the other before it can continue?
                - Is anything here intended for reuse across products, or
                  is this one part?
                - Any process-node constraints — is something analog-heavy
                  or SRAM-heavy?
                - What's the packaging budget, roughly? That bounds what's
                  even possible.
                - And is anything expected to come from outside the team?"
 
INTERVIEWER:  [answers some, says "assume X for the rest"]
 
STRONG:       "Good — then let me state my assumptions and work from those."

Four properties.

Each question changes the answer, which is why asking them is not stalling. A candidate who asks about dependent loops has already signalled they know §9.

The last question is the sharpest. "Is anything coming from outside the team?" is 23.2 §8's organisational boundary — the variable that decides standard versus proprietary, and very few candidates raise it.

If the interviewer says "just assume," state your assumptions aloud and proceed. The questions still did their work: they showed you knew what mattered.

And do not ask more than six or seven. Beyond that it reads as avoidance rather than scoping.

6. The Scorecard

Thirteen dimensions. Say early that no single one decides it — and mean it.

Three properties.

Rows 1–3 can veto everything else. A boundary with high traffic, tight dependent latency and shared coherent state is a bad die boundary regardless of how attractive the node split looks — and saying that unprompted is a senior signal.

Row 12 is a hard constraint, not a preference. A partition the package cannot support is not a partition (24.3 §6).

And row 13 is the one that decides standard versus proprietary interface (23.2 §8) — a different question from where to cut, and worth separating explicitly.

7. The Prompt

Three things to notice before proposing anything.

The edges are labelled by character, not bandwidth. "Dependent loop" versus "pipelined bulk" is the distinction that decides this, and §10 is why.

The CPU-to-fabric edge is a dependent loop, and it is the one everybody wants to cut because it separates two obvious functional units. It is the worst cut on the diagram.

And the management edge is negligible, which makes it the safest boundary and the least valuable one — splitting there costs nothing and buys nothing.

8. Step One — Build the Traffic Graph

Before topology, characterise every edge. Five attributes, not one.

The column that decides it is dependency depth, not rate. Two edges can carry identical bytes per second and be opposite in partition suitability — §10 is that, worked.

9. Step Two — Identify the Bad Cuts

A bad partition crosses one of four things.

And the CPU ↔ fabric edge in §7 crosses the first three at once, which is why it is the answer to "which boundary would you not split?" — a question §24 says will come.

10. The Quantitative Argument

Two edges, identical bandwidth, opposite verdicts. This is the calculation to do aloud.

ILLUSTRATIVE. Symbolic units; no UCIe or vendor figure is used (§4).
 
EDGE A — CPU <-> fabric
  rate              1 transaction / cycle
  bytes             8 per transaction
  bandwidth         8 bytes / cycle
  dependency        depth 1 — each transaction waits for the previous
  outstanding       1
 
EDGE B — fabric <-> accelerator
  rate              0.125 transactions / cycle
  bytes             64 per transaction
  bandwidth         8 bytes / cycle          <-- IDENTICAL
  dependency        deep — independent
  outstanding       32
 
NOW ADD A DIE BOUNDARY, crossing latency c = 15 each way:
 
  EDGE A:  loop time was 1 cycle.
           loop time becomes 1 + 2(15) = 31 cycles.
           throughput = 1/31 of before  ->  ~97% LOST.
           No buffering helps: buffers hide latency by overlapping
           INDEPENDENT work, and there is none (21.5 §25).
 
  EDGE B:  latency per transaction rises by 30 cycles.
           But 32 transactions are outstanding, so the added latency is
           hidden as long as:
                outstanding >= rate x latency
                32 >= 0.125 x (base + 30)
           which holds comfortably.
           throughput ~UNCHANGED. Tail latency rises by ~30 cycles.
 
SAME BANDWIDTH. OPPOSITE ANSWERS.

Five readings.

Bandwidth was a red herring on both edges, and stating that explicitly is the point of doing the arithmetic.

Edge A's 97% loss is not a slowdown, it is a collapse — and it is functionally invisible: every transaction is correct.

Edge B's cost is real but it is tail latency, not throughput (22.4 §8) — so whether it is acceptable depends on the workload, which is why §5's first question mattered.

The condition outstanding ≥ rate × latency is the reusable test, and it is 21.5 §26's bandwidth-delay product used as a partition criterion.

And the sentence to say: "So I'd measure dependency depth on each candidate edge before I looked at bandwidth at all."

11. Step Three — Process, Yield, Reuse

Separate the architectural reasons from the manufacturing and business ones, and say you are doing it.

12. Step Four — Failure Domains

A boundary is also a fault boundary, and interviewers ask.

And the highest-value observation: a boundary carrying coherent state is a far worse fault boundary than one carrying bulk data, because a lost coherent request is a hang, not a retry — which is another reason §7's CPU ↔ fabric edge is the wrong cut.

13. Step Five — The Software Model

A physical partition does not have to be visible to software — and deciding whether it is, is an architectural choice rather than a consequence.

And the sentence worth having: "I'd want the software model to be a decision, not a side effect. If we change the partitioning next generation, I'd rather the software abstraction not change with it."

14. Step Six — Configuration Ownership

And the failure to avoid is every die deciding for itself (24.2 §12): a die that sees a configuration write and immediately changes behaviour produces a window where the two ends interpret traffic differently — §18 is that at runtime.

15. RTL — The Route Contract

// ILLUSTRATIVE ONLY. What crosses a chiplet boundary. Note the separation:
// a STABLE logical identity, a MUTABLE route, and two epochs.
typedef struct packed {
  logic [SEM_W-1:0]   sem_id;          // the operation — stable everywhere
  logic [GEN_W-1:0]   generation;      // which use of that id
  logic [15:0]        dst_logical_id;  // WHAT it is — NOT a link number (§16)
  logic [TC_W-1:0]    traffic_class;
  logic [EPOCH_W-1:0] cfg_epoch;       // which configuration it runs under
  logic [EPOCH_W-1:0] route_epoch;     // which route table produced its path
  logic [FD_W-1:0]    fault_domain;    // for attribution (§12)
} chiplet_txn_t;
 
// Identity and route are SEPARATE state with different lifetimes.
logic [15:0]        logical_id_q [N_CHIPLETS];   // stable while present
logic [LINK_W-1:0]  route_q      [N_CHIPLETS];   // may change
logic [EPOCH_W-1:0] route_epoch_q;

Architecture. Three separated things — what a destination is, how to reach it, and which mapping produced a given path.

State. A stable identity per chiplet, a mutable route per chiplet, one route epoch.

Event. A route commit writes route_q and increments route_epoch_q. No branch writes logical_id_q — and that absence is the correctness argument.

Contract. Software is published dst_logical_id. The route is internal and may change without any software-visible event (22.4 §12).

Failure. §16.

DV/debug. Both epochs in the trace (21.7 §16) are what let you distinguish a straggler from a violation — a response whose route_epoch predates the current one is late, not illegal.

16. Wrong RTL — the Link Number Is the Identity

// WRONG — the destination field is a physical port, and software is told the
// port number is the chiplet's identity.
assign egress_port  = txn.dst;             // dst IS a port index
assign sw_visible_id = link_id;            // published to software
assign resp_match   = (resp_port == pending_port[slot]);   // correlate on PORT

Four readings.

The failover worked perfectly. Every mechanism did its job — and the system broke because identity was defined as a route.

Step 6 is the serious one, and it is 22.4 §11's correlation problem: unmatched responses are dropped or matched to the wrong request.

Step 5 is the one an interviewer will react to, because it is a user-visible symptom from a purely internal event.

And the fix is §15's separation — stable logical_id, mutable route, and a route_epoch carried on the transaction so a live operation stays correlatable across a change.

17. RTL — Changing Configuration at Runtime

// ILLUSTRATIVE ONLY (§15). The standard senior follow-up: "how would you
// change a route or profile while traffic is running?"
//
// Shadow -> validate -> quiesce -> atomic commit -> epoch.
route_e_t bank_q [2][N_DEST];
logic     active_sel_q;            // the DATA PLANE reads this bank ONLY
 
logic shadow_validated_q;
logic commit_fire;
 
assign shadow_sel  = ~active_sel_q;
assign commit_fire = commit_req && shadow_validated_q && quiesced;
 
// The data plane's entire coupling to configuration is ONE mux select.
assign lookup_port = bank_q[active_sel_q][lookup_addr].port;
 
always_ff @(posedge clk or negedge rst_n) begin
  if (!rst_n) begin
    active_sel_q       <= 1'b0;
    route_epoch_q      <= '0;
    shadow_validated_q <= 1'b0;
  end else begin
    // A shadow write INVALIDATES a previous validation, so a late write
    // cannot ride in on an earlier approval.
    if (shadow_we) begin
      bank_q[shadow_sel][shadow_addr] <= shadow_entry;
      shadow_validated_q              <= 1'b0;
    end else if (validate_req) begin
      shadow_validated_q <= shadow_is_consistent;
    end else if (commit_fire) begin
      active_sel_q       <= shadow_sel;          // ATOMIC — one bit
      route_epoch_q      <= route_epoch_q + 1'b1;
      shadow_validated_q <= 1'b0;
    end
  end
end
 
// MANDATORY. English: the active route table changes only on a validated
// commit at quiescence. Fires at the cycle of §18's premature update.
a_active_only_on_valid_commit: assert property (
  @(posedge clk) disable iff (!rst_n)
    $changed(active_sel_q)
      |-> ($past(commit_req) && $past(shadow_validated_q) && $past(quiesced))
);

Architecture. Two banks and a one-bit selector, so every lookup sees a wholly-old or wholly-new table — never a mixture.

State. 2 × N_DEST entries, the selector, a validation flag, the epoch.

Event. Software writes the shadow; validation checks it; commit swaps only if validated and quiesced.

Contract. A shadow write clears the validation flag. Without that, a write arriving after validation and before commit is committed unvalidated.

Failure. §18.

DV/debug. The epoch on every transaction is what makes a cross-update trace interpretable at all — and in silicon it is the register that distinguishes a straggler from a fault.

18. Wrong RTL — Updating the Live Table

// WRONG — software writes the active table one entry at a time.
always_ff @(posedge clk)
  if (sw_we) route_tbl[sw_addr] <= sw_entry;      // the LIVE table

Four readings.

The primary failure is correlation, not routing. The response went to the right place and was matched against a table that had moved.

Every transport counter is clean — CRC fine, no link errors — so the investigation starts in the wrong place (21.4's ledger all closes).

It reproduces only when a response is in flight during the update, so an update on an idle system works perfectly.

And the fix is §17's atomic swap plus the route_epoch on the transaction — so no transaction is issued under one table and correlated under another, and even a legitimate straggler after a later change is attributable.

19. Is the Link Even the Bottleneck?

Before proposing a boundary on performance grounds, prove the edge binds.

And the failure to name: "low link utilisation with a full downstream queue means the constraint is behind the link, and standardising or widening that edge changes nothing" — 22.3 §9's wrong-boundary case, which is the exact mistake this question invites.

20. Every Boundary Is a Verification Cost

And the sentence worth saying unprompted: "Partitioning is also a verification-cost decision. Each boundary I add is an interface I have to verify against every legal peer, plus a place where post-silicon failures become harder to attribute."

21. "How Would You Verify Your Partition?"

And this is the natural bridge to 25.8 — "design a multi-agent UVM environment for UCIe" — which is the question this answer invites.

22. Flagship — the Bad Partition

Two tightly coupled blocks separated because they wanted different process nodes.

Five readings, and this is the case to have ready.

Every correctness instrument is clean, so the investigation starts in the wrong place (21.5 §51).

outstanding = 1 is the diagnosis — nothing could be issued while a response was in flight, so the loop time is the throughput (§10).

No buffer depth helps, and the team will try several before believing it (21.5 §25).

The node argument was real and was overridden by rows 1–3 of the scorecard (§6) — which is the whole lesson.

And the fix is a re-partition, which after contract freeze means respinning both dies (24.3 §5) — which is why §10's measurement belongs in a prototype, months earlier.

23. Flagship — the Good Partition

The fabric ↔ accelerator edge, split.

And the honest framing to give the interviewer: "This is a good boundary for this workload. If the accelerator were in a dependent loop with the fabric — if each request depended on the previous response — I'd give the opposite answer at the same bandwidth."

That sentence is worth more than the recommendation itself, because it shows the decision was derived rather than pattern-matched.

24. When They Push Back

Two properties.

Concede the true part first, every time. "That may well be better" costs nothing and makes the narrowing read as precision rather than defensiveness (25.2 §17).

And row 7 is the one to relish — "what if latency doubles?" is an invitation to do the arithmetic aloud, which is the most convincing thing you can do at a whiteboard.

25. Contract Assertions

And if asked which one you would build first: a_live_txn_dest_stable. It is one comparison, it catches §16 at the cycle, and the bug it prevents is user-visible.

The two worth being able to write on the spot:

// MANDATORY. English: a live transaction's logical destination never changes,
// however the route underneath it moves. Sampled every cycle while the
// transaction is outstanding. Catches §16 — a failover re-tagging in-flight
// work — at the cycle it happens, and the bug it prevents is user-visible.
a_live_txn_dest_stable: assert property (
  @(posedge clk) disable iff (!rst_n)
    (txn_live && $changed(route_epoch_q)) |-> $stable(txn_dst_logical_id)
);
 
// MANDATORY. English: a reroute never produces two completions for one
// operation. Bounded by an OBSERVED retirement rather than an invented
// window (21.6 §29), so it both terminates and reports a real pass. Catches
// §18's escalation, where a timed-out identity is reused and a straggler
// retires the wrong transaction.
property p_failover_no_duplicate_completion(int unsigned s, int unsigned g);
  @(posedge clk) disable iff (!rst_n)
    (complete_fire && (complete_sem_id == s) && (complete_gen == g))
      |=> !(complete_fire && (complete_sem_id == s) && (complete_gen == g))
          throughout (1'b1 [*1:$] ##0 (retire_fire && (retire_sem_id == s)));
endproperty
a_failover_no_dup: assert property (p_failover_no_duplicate_completion(TEST_ID, TEST_GEN));
 
// MANDATORY. English: accepted work survives a transport recovery that the
// contract says retains it. Sampled on the recovery EXIT edge, because that
// is when retention is observable; sampling during recovery compares against
// a transient (25.3 §16).
a_accepted_survives_recovery: assert property (
  @(posedge clk) disable iff (!rst_n)
    ($fell(in_recovery) && contract_retains_across_recovery)
      |-> (live_txn_set_q == $past(live_txn_set_q, RECOVERY_DEPTH))
);

Architecture. Three properties covering the three ways a runtime change can damage in-flight work: identity re-tagging, duplicate completion, and lost obligations.

State. The live-transaction set, its identities, and the two epochs.

Event. The first two sample continuously while a transaction is live; the third samples on the recovery exit edge only.

Contract. p_failover_no_duplicate_completion requires that retirement is guaranteed to occur, or it is vacuously true forever — and saying that unprompted is the strong move, because it shows you know an unbounded never reports nothing.

Failure if omitted. Without the first, §16's failover ships and presents as a device disappearing from software. Without the third, a recovery silently drops outstanding work and the symptom is a hang with a healthy link.

DV/debug. In silicon these become counters rather than assertions (21.7 §21): a live-transaction count that drops without a matching retirement is the third property in register form, and it is cheap.

26. Weak Senior Answers

And the last row is the one that costs the most, because it happens before any technical content and colours everything after it.

27. The Full Exercise

A senior walkthrough, condensed:

Scope first (§5): workload, traffic matrix, dependent loops, reuse, node constraints, package budget, external sourcing.

Do not cut CPU ↔ fabric (§9). Dependency depth 1, coherent state, latency-critical — the arithmetic in §10 gives roughly a 97% throughput loss, and no buffering repairs it.

Do cut fabric ↔ accelerator (§23). Deep dependency, 32 outstanding, latency hidden; the accelerator is reusable and may come from another team — which is also the argument for a standard interface there rather than a private one.

Consider I/O as a second boundary, driven by reuse rather than performance — and say that you are separating architectural from business reasons (§11).

Keep memory controllers with the fabric unless area or independent respin argues otherwise — and name that as a real tradeoff rather than a default.

Then: fault domain (accelerator link failure should isolate, not reset), software model (present one device; keep logical identity stable across reroute — §16), one invariant (a_live_txn_dest_stable), and one risk (is the accelerator edge actually binding, or is memory service the constraint? — §19).

There is no single correct partition. What is being assessed is whether the reasoning is derived, quantitative and honest about its assumptions.

28. Controlling the Next Question

And the second row is the best hook in the chapter. Volunteering a boundary you would refuse to cut is counter-intuitive, immediately credible, and lands you in §22 — the case where every test passes and the system collapses.

29. Understanding Check

30. Summary

Five things.

Scope before you draw (§5). Six or seven questions, including whether a die comes from outside the team — and the interviewer notices before you have proposed anything.

Dependency depth decides, not bandwidth (§10). Identical bytes per second, opposite verdicts, and the test is outstanding ≥ rate × latency.

Node affinity is one dimension of thirteen (§6, §11). Rows 1–3 can veto it, and §22 is what happens when they are ignored.

Identity is not a route, and configuration commits atomically (§15–§18). Otherwise a correct failover looks like a device swap, and a routine remap silently corrupts.

And volunteer the boundary you would not cut (§28). It shows the analysis, invites the best follow-up, and answers "do you know when not to?" without being asked.