Ethernet · Module 26
Architecture and Integration Review
Twenty review items, each a number somebody has to produce and a chapter that derives it — with a readiness model, a budget reconciler and a claims auditor that make the review itself able to fail.
Twenty-five modules of this track have derived numbers. This chapter is the pass that collects them, and its one rule is that a review item without a number is not a review item.
The failure mode of an architecture review is not that it misses things. It is that it cannot fail.
| A review item that reads | Can it fail? | Why |
|---|---|---|
| "the packet buffer is adequately sized" | NO | adequate has no failing value |
| "the interfaces are correctly specified" | NO | correctly is not a predicate |
| "performance has been considered" | NO | considered is an activity, not a threshold |
| "the buffer holds 64 MB — a 2 224 µs burst at one port" | yes | Chapter 23.3 §9, against a stated requirement |
| "the descriptor store holds 149 at 100 Gb/s" | yes | Chapter 23.4 §7, against Little's law |
Rows one to three are what most architecture checklists contain and every one of them is satisfied by the act of holding the review.
A review whose items are qualities rather than quantities is Chapter 24.3 §20's class 114 at the level of a programme: the design and the criterion share a custodian, and the criterion has no failing value.
So this chapter builds the review the other way. Twenty items, each a number somebody must produce, with the chapter that derives it named — and three RTL models that make the review itself a computable object: a readiness model that counts produced numbers against adjectives, a budget reconciler that adds the claims against the die and the end-to-end latency, and a claims auditor that asks whether each item has a number, a threshold and a witness who is not its author.
1. Scope — A Review That Can Fail
This chapter owns one checklist and three models.
| What is built | |
|---|---|
| Sections 2 to 3 | the twenty items, each with its number and its deriving chapter |
| Sections 4 to 7 | the readiness model and the area reconciliation, worked at 64 ports |
| Sections 8 to 11 | the latency reconciliation and the claims auditor |
| Sections 12 to 17 | what a review must never do, and why an item's threshold is the hard part |
What this chapter does not own. Chapter 26.2 covers RTL and verification sign-off, Chapter 26.3 performance closure and observability, and Chapter 26.4 what an interviewer is testing. This is the architecture and integration pass: the one held before RTL exists, where the outputs are numbers rather than code.
And it is not a summary of the track. Every item below is a decision somebody has to make with a number attached, and the chapter that derives the number is named so the item is checkable rather than merely listed.
2. The Twenty Items
Each row is a quantity, a value at a 64-port 100 Gb/s reference design, and the chapter that derives it. The threshold column is Section 12's subject and is the part a programme must supply.
Group A — rate, framing and the packet budget (4).
| # | Quantity | Reference value | Derived in |
|---|---|---|---|
| 1 | aggregate packet rate at minimum frame size | 9.524 Gpps | Chapter 23.3 §2 |
| 2 | pipeline width at the core clock | 8 lanes at 1.2 GHz | Chapter 23.3 §2, Chapter 25.6 §8 |
| 3 | framing efficiency at the deployment's mean frame | 97.53% at 1 518 octets | Chapter 8.3 §2 |
| 4 | the tag's cost if VLANs are carried on trunks | 4.76% at minimum frame size | Chapter 25.4 §3 |
Group B — forwarding state (4).
| # | Quantity | Reference value | Derived in |
|---|---|---|---|
| 5 | MAC table effective capacity | 105 465 of 131 072 offered — 80.5% | Chapter 12.5 §9, Chapter 25.5 §6 |
| 6 | the occupancy alarm threshold, against that ceiling | 70%, not 90% | Chapter 25.5 §8 |
| 7 | flood amplification at the port count | 63 copies — 98.4% of the frame budget | Chapter 12.4 §3, Chapter 25.5 §2 |
| 8 | the key width if VLANs are supported | 60 bits — +1 572 864 BCE at 128k entries | Chapter 13.4 §8, Chapter 25.4 §11 |
Group C — buffering and flow control (4).
| # | Quantity | Reference value | Derived in |
|---|---|---|---|
| 9 | packet buffer, and the burst it absorbs | 64 MB — 2 224 µs at one port | Chapter 23.3 §9 |
| 10 | PAUSE headroom, per link, if PFC is enabled | 7.67 KiB at 100 Gb/s over 100 m | Chapter 14.2 §9 |
| 11 | the credit reservation, if the fabric is lossless | 73 000 B per link at 400 Gb/s over 100 m | Chapter 24.2 §2 |
| 12 | head-of-line blocking bound, if ingress queues are FIFO | 58.6% — 2 − √2 | Chapter 14.3 §4 |
Group D — the host interface (4).
| # | Quantity | Reference value | Derived in |
|---|---|---|---|
| 13 | descriptor prefetch depth | 149 at 100 Gb/s and 1 µs | Chapter 23.4 §7 |
| 14 | outstanding-read tags and the reorder buffer | 196 tags, 425 088 BCE at 400 Gb/s | Chapter 24.1 §4 |
| 15 | context-cache miss cliff, if TCP is offloaded | 39.4% | Chapter 23.4 §10 |
| 16 | the striping bound the cache imposes on the fabric | stripes ≤ cache entries ÷ participants | Chapter 23.4 §12 |
Group E — the boundary, integrity and time (4).
| # | Quantity | Reference value | Derived in |
|---|---|---|---|
| 17 | parse window, and whether a crossing is declared | 22 octets, or a declared 134 | Chapter 25.1 §3 |
| 18 | MACsec gates and wire cost, if integrity is required | 407 200 GE; +24 octets | Chapter 25.3 §10 |
| 19 | timestamp accuracy budget, if PTP is carried | Chapter 16.5's limit terms | Chapter 16.5 |
| 20 | duplicate-address detection, and its cost | 36 bits per entry — 0.84% of the switch | Chapter 25.2 §10 |
Twenty items, twenty numbers, twenty chapters. A programme that can fill this table has an architecture; one that cannot has a diagram.
3. RTL 1 — The Review Package and the Item Model
// ---------------------------------------------------------------------
// archreview_pkg -- the reference values Module 25 and Module 23
// derived, and the shape a review item must have to be checkable.
//
// Unit: Chapter 23.3 Section 2's bitcell equivalent.
// 1 BCE = 0.35 GE = one bit of usable on-die SRAM
// 1 flip-flop = 20 BCE
// Chapter 19.7 Section 19's MAC receive datapath = 283 320 BCE
// Chapter 23.3's 64-port switch = 5.62e8 BCE
// ---------------------------------------------------------------------
package archreview_pkg;
localparam int unsigned DATAPATH_BCE = 283_320;
localparam int unsigned BCE_PER_FLOP = 20;
localparam int unsigned SWITCH_BCE_E4 = 56_200; // 5.62e8 / 1e4
localparam int unsigned ITEM_COUNT = 20;
// ---- an item's four parts, Section 1's callout ------------------------
typedef enum logic [1:0] {
ITEM_ADJECTIVE = 2'd0, // a quality: no failing value
ITEM_VALUED = 2'd1, // a number, no threshold
ITEM_THRESHOLDED= 2'd2, // a number and a bound
ITEM_AUDITED = 2'd3 // and a witness who is not its author
} itemkind_e;
typedef enum logic [1:0] {
CLAIM_UNFALSIFIABLE = 2'd0,
CLAIM_SELF_WITNESSED= 2'd1,
CLAIM_AUDITABLE = 2'd2
} claimstate_e;
// ---- the reference design's derived quantities ------------------------
localparam int unsigned REF_PORTS = 64;
localparam int unsigned REF_GBPS = 100;
localparam int unsigned REF_CORE_MHZ = 1_200;
localparam int unsigned REF_AGG_PPS_K = 9_524_000; // Chapter 23.3 §2
localparam int unsigned REF_PIPE_WIDTH = 8;
localparam int unsigned REF_TBL_ENTRIES = 128 * 1024;
localparam int unsigned REF_TBL_WAYS = 4;
localparam int unsigned REF_EFF_CAP_PCT = 80; // Chapter 12.5 §9
localparam int unsigned REF_BUFFER_MB = 64; // Chapter 23.3 §9
localparam int unsigned REF_PREFETCH = 149; // Chapter 23.4 §7
localparam int unsigned REF_TAGS = 196; // Chapter 24.1 §4
localparam int unsigned REF_MISS_CLIFF = 39; // Chapter 23.4 §10
localparam int unsigned REF_PARSE_OCTETS = 22; // Chapter 25.1 §3
// ---- derived: an item's state from its three flags --------------------
function automatic claimstate_e claim_state(bit has_value,
bit has_threshold,
bit has_witness);
if (!has_value || !has_threshold) return CLAIM_UNFALSIFIABLE;
if (!has_witness) return CLAIM_SELF_WITNESSED;
return CLAIM_AUDITABLE;
endfunction
function automatic itemkind_e item_kind(bit has_value,
bit has_threshold,
bit has_witness);
if (!has_value) return ITEM_ADJECTIVE;
if (!has_threshold) return ITEM_VALUED;
if (!has_witness) return ITEM_THRESHOLDED;
return ITEM_AUDITED;
endfunction
// ---- derived: readiness ------------------------------------------------
function automatic int unsigned readiness_ppm(int unsigned produced,
int unsigned total);
return (total == 0) ? 0 : ((produced * 1_000_000) / total);
endfunction
function automatic int unsigned datapaths_milli(int unsigned bce);
return (bce * 1000) / DATAPATH_BCE;
endfunction
function automatic int unsigned switch_share_x100(int unsigned bce_e2);
return (bce_e2 * 10_000) / (SWITCH_BCE_E4 * 100);
endfunction
endpackage// ---------------------------------------------------------------------
// review_item_model -- one row of Section 2's table, classified by
// whether it can fail.
//
// The output that matters is can_fail, which is low for an item that
// names a quality -- and Section 20's rejected property is the
// conjunction over a review made of them.
// ---------------------------------------------------------------------
module review_item_model
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic eval,
input logic has_value,
input logic has_threshold,
input logic has_witness,
input logic [31:0] value,
input logic [31:0] threshold,
input logic threshold_is_upper_bound,
input logic [15:0] deriving_chapter_x10,
output logic [1:0] kind,
output logic [1:0] state,
output logic can_fail,
output logic item_passes,
output logic item_fails,
output logic provenance_recorded,
output logic is_decoration,
output logic [31:0] c_items_evaluated,
output logic [31:0] c_decoration
);
always_comb begin
kind = 2'(item_kind(has_value, has_threshold, has_witness));
state = 2'(claim_state(has_value, has_threshold, has_witness));
// THE property of a usable item.
can_fail = has_value && has_threshold;
item_fails = can_fail && (threshold_is_upper_bound
? (value > threshold) : (value < threshold));
item_passes = can_fail && !item_fails;
// Part four: somebody can check the number.
provenance_recorded = (deriving_chapter_x10 != 16'd0);
// An item that cannot fail and has no provenance is decoration.
is_decoration = !can_fail;
end
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
c_items_evaluated <= '0; c_decoration <= '0;
end else if (eval) begin
c_items_evaluated <= c_items_evaluated + 32'd1;
if (is_decoration) c_decoration <= c_decoration + 32'd1;
end
end
endmoduleClassification: a four-field classifier over a review item, with one output that decides whether the item is an instrument.
What it teaches: that can_fail needs a value AND a threshold, and that an item with a value and no threshold is CLAIM_UNFALSIFIABLE rather than half-good. "The buffer holds 64 MB" is a fact; "the buffer holds 64 MB against a requirement of 40" is a review item, and the difference is one number somebody has to commit to.
And it teaches that provenance_recorded is a separate axis from can_fail. An item can fail and still be unauditable — somebody wrote 149 and nobody can check it — which is Chapter 24.3 §20's class 114 at the level of a single row. Naming the deriving chapter is what makes the value checkable by a reader.
Deliberately simplified: threshold_is_upper_bound handles only monotone thresholds, where several of Section 2's items are two-sided — a pipeline width must be at least the packet rate and a design that makes it four times that has wasted area. deriving_chapter_x10 encodes a chapter number and not a section. And the model treats has_witness as a boolean where Chapter 24.3 §13 established that an independent witness has two conditions: a separate author, and one who did not see the design.
Production implication: the two-sided threshold is the one that catches over-provisioning, and a review that only checks lower bounds never does. A packet buffer sized at 256 MB when 64 suffices is 2.15 × 10⁹ BCE — 3.8 times Chapter 23.3's entire switch — and it passes every at least check in the review. The item that catches it is a two-sided bound with a stated justification for the margin, and the general habit is that every threshold in a review should state both a floor and a ceiling, because a design fails in both directions and only one of them is ever checked.
4. The Readiness Metric
Section 2's table has twenty rows. This section is about how many of them a programme can actually fill, and what the answer means.
Readiness is the share of items that have a produced number. Not an estimate, not a reference value copied from this chapter — a number somebody computed for this design and will be held to.
| Items with a produced number | Readiness | Items that cannot fail | What the review establishes |
|---|---|---|---|
| 20 of 20 | 100% | 0 | the architecture is specified |
| 14 of 20 | 70% | 6 | six decisions have not been made |
| 6 of 20 | 30% | 14 | a diagram with a schedule attached |
| 0 of 20 | 0% | 20 | the review is a meeting |
Every item without a number is an item that cannot fail, and a review's pass is the conjunction over its items — so a review with fourteen adjectives passes on six.
And the readiness figure is not a percentage of work done; it is a percentage of the review that is load-bearing. A programme at 30% readiness that passes its review has passed on six items, and the fourteen that carried no number contributed nothing to the verdict and nothing to the risk assessment.
Three properties of the metric are worth stating.
One — it is monotone in time and that is the point. An item acquires a number when somebody makes a decision; readiness measures decisions made, not documents written.
Two — a reference value is not a produced number. Copying 149 from Chapter 23.4 §7 into a design targeting 400 Gb/s and a 2 µs host latency is wrong by a factor of eight — the requirement there is 1 190 — and the item reads as filled. Section 11's auditor is where that is caught.
Three — the metric says nothing about whether the numbers are right. That is the claims auditor's job, and Sections 10 and 11 are about it.
5. RTL 2 — The Readiness Model
// ---------------------------------------------------------------------
// readiness_model -- how much of a review is load-bearing, and what a
// verdict is a conjunction over.
//
// The output that matters is verdict_information_bits, which is the
// count of items that could have failed -- and it is what a pass
// should be reported against.
// ---------------------------------------------------------------------
module readiness_model
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic item_valid,
input logic [1:0] item_kind_i,
input logic item_passed,
input logic item_failed,
input logic value_is_reference_copy,
output logic [15:0] c_items,
output logic [15:0] c_adjectives,
output logic [15:0] c_valued,
output logic [15:0] c_thresholded,
output logic [15:0] c_audited,
output logic [15:0] c_can_fail,
output logic [15:0] c_passed,
output logic [15:0] c_failed,
output logic [15:0] c_reference_copies,
output logic [31:0] readiness_ppm_o,
output logic [15:0] verdict_information_bits,
output logic verdict,
output logic verdict_is_diluted
);
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
c_items <= '0; c_adjectives <= '0; c_valued <= '0;
c_thresholded <= '0; c_audited <= '0; c_can_fail <= '0;
c_passed <= '0; c_failed <= '0; c_reference_copies <= '0;
end else if (item_valid) begin
c_items <= c_items + 16'd1;
case (item_kind_i)
2'(ITEM_ADJECTIVE): c_adjectives <= c_adjectives + 16'd1;
2'(ITEM_VALUED): c_valued <= c_valued + 16'd1;
2'(ITEM_THRESHOLDED): c_thresholded <= c_thresholded + 16'd1;
default: c_audited <= c_audited + 16'd1;
endcase
if (item_kind_i >= 2'(ITEM_THRESHOLDED)) c_can_fail <= c_can_fail + 16'd1;
if (item_passed) c_passed <= c_passed + 16'd1;
if (item_failed) c_failed <= c_failed + 16'd1;
if (value_is_reference_copy)
c_reference_copies <= c_reference_copies + 16'd1;
end
end
always_comb begin
readiness_ppm_o = 32'(readiness_ppm(int'(c_items) - int'(c_adjectives),
int'(c_items)));
// THE number a pass should be reported against.
verdict_information_bits = c_can_fail;
// A review's verdict is the conjunction over its items.
verdict = (c_failed == 16'd0);
// And it is diluted whenever some items could not have failed.
verdict_is_diluted = (c_can_fail < c_items);
end
endmoduleClassification: a counter bank over a review's own items, whose primary output is how much of the verdict is load-bearing.
What it teaches: that verdict and verdict_information_bits must be reported together, and that a report giving only the first is Chapter 25.6 §20's class 120 in a management document. "20 of 20 passed, 6 could have failed" is a true and useful sentence; "20 of 20 passed" is a true and misleading one.
And it teaches that c_reference_copies is a separate hazard from c_adjectives. An item filled with a value copied from this chapter counts as valued, thresholded and audited — it has a number, a bound and a citation — and the number is for a different design. Section 4's example: 149 descriptors is right at 100 Gb/s and 1 µs and wrong by a factor of eight at 400 Gb/s and 2 µs.
Deliberately simplified: value_is_reference_copy is a human judgement the model takes as an input, because no automated check distinguishes a correctly-reused value from a copied one — the reference value and the correct value coincide whenever the design matches the reference. The counters are per review rather than per revision, so a programme cannot see its readiness improving without keeping snapshots. And verdict is a plain conjunction where a real review has severities.
Production implication: the missing revision history is what makes readiness usable as a schedule instrument rather than as a gate. A programme that records readiness_ppm_o at each milestone has a curve, and the curve's shape says more than any single value: a readiness that rises steadily is a design being decided; one that jumps from 30% to 100% in the week before sign-off is a table being filled in. The second is the common case and it is detectable for the cost of one 32-bit register per milestone — sixteen milestones is 512 bits, 10 240 BCE, 0.036 datapaths — and it is the only quantity in this chapter that distinguishes a review from a formality without reading a single item.
6. The Area Reconciliation, Worked
Section 2's items name quantities. This section adds the ones that are areas and compares the total against a die budget, which is the check a review most often skips.
A 64-port 100 Gb/s Ethernet subsystem, every structure this track has derived, in BCE.
| Structure | BCE | × the datapath | Derived in |
|---|---|---|---|
| packet buffer, 64 MB | 5.12 × 10⁸ | 1 807 | Chapter 23.3 §2 |
| ACL TCAM, 16k × 256 b | 2.10 × 10⁷ | 74.1 | Chapter 23.3 §2 |
| L3 host and LPM, 128k × 128 b | 1.68 × 10⁷ | 59.3 | Chapter 23.3 §2 |
| MAC table, 128k × 96 b | 1.26 × 10⁷ | 44.5 | Chapter 23.3 §2 |
| VLAN key widening, 128k × 12 b | 1 572 864 | 5.55 | Chapter 25.4 §11 |
| duplicate detector, 128k × 36 b | 4 718 592 | 16.65 | Chapter 25.2 §10 |
| per-set occupancy census, 32 768 × 4 b | 131 072 | 0.46 | Chapter 25.5 §5 |
| RMON counters, 64 × 27 × 64 b | 111 000 | 0.39 | Chapter 23.3 §2 |
| CRC engine state, 64 × 70 flops | 89 600 | 0.32 | Chapter 19.4 §8 |
| MACsec SA state, 4 × 64 ports | 73 728 | 0.26 | Chapter 25.3 §10 |
| queue state, 512 queues | 33 000 | 0.12 | Chapter 23.3 §2 |
| PN gap detectors, 4 × 64 | 8 192 | 0.03 | Chapter 25.3 §13 |
| per-ingress flood counters, 64 × 48 b | 3 072 | 0.01 | Chapter 25.5 §15 |
| total | 5.691 × 10⁸ | 2 009 | — |
The additions this track's later chapters argue for total 7.14 × 10⁶ BCE — 25.2 datapaths, 1.27% — on top of Chapter 23.3's 5.62 × 10⁸ BCE switch.
Two readings of that total are worth separating.
One — the buffer is 90.0% of it. Every argument in this track about tables, detectors and telemetry concerns the other 10%, and Chapter 23.3 §2's original observation holds: a merchant switch's on-die state is one array and a rounding error.
Two — the diagnostic structures are 0.85% together. The duplicate detector, the occupancy census, the flood counters and the PN gap detectors — every instrument Module 25 asked for — come to 4.86 × 10⁶ BCE, 17.2 datapaths, against failures that cost days of investigation each.
And the reconciliation's purpose is the subtraction, not the sum. A review that adds the claimed areas and compares them against a die budget catches the two failures a per-block review cannot: a total that exceeds the budget, and a total that falls short of it by enough to indicate something was forgotten.
7. RTL 3 — The Area Reconciler
// ---------------------------------------------------------------------
// area_reconciler -- the sum of a design's claimed structures against
// both a budget and an independent reference bill.
//
// The output that matters is below_reference_estimate, because a total
// that is too SMALL is the omission a block-by-block review cannot see.
// ---------------------------------------------------------------------
module area_reconciler
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic entry_valid,
input logic [31:0] entry_bce_e2, // BCE / 100
input logic entry_is_diagnostic,
input logic [31:0] budget_bce_e2,
input logic [31:0] reference_bce_e2,
input logic [15:0] tolerance_pct,
output logic [31:0] total_bce_e2,
output logic [31:0] diagnostic_bce_e2,
output logic [15:0] entries_counted,
output logic [31:0] total_dp_milli,
output logic [15:0] diagnostic_share_x100,
output logic exceeds_budget,
output logic below_reference_estimate,
output logic [31:0] shortfall_bce_e2,
output logic reconciles,
output logic [31:0] c_reconciliations
);
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
total_bce_e2 <= '0; diagnostic_bce_e2 <= '0; entries_counted <= '0;
c_reconciliations <= '0;
end else if (entry_valid) begin
total_bce_e2 <= total_bce_e2 + entry_bce_e2;
entries_counted <= entries_counted + 16'd1;
if (entry_is_diagnostic)
diagnostic_bce_e2 <= diagnostic_bce_e2 + entry_bce_e2;
c_reconciliations <= c_reconciliations + 32'd1;
end
end
always_comb begin
total_dp_milli = 32'(datapaths_milli(total_bce_e2 * 32'd100));
diagnostic_share_x100 = (total_bce_e2 == 0) ? 16'd0
: 16'((diagnostic_bce_e2 * 32'd10_000)
/ total_bce_e2);
exceeds_budget = (total_bce_e2 > budget_bce_e2);
// THE check a block-by-block review cannot perform: is the total
// implausibly SMALL against an independent bill of materials?
shortfall_bce_e2 = (reference_bce_e2 > total_bce_e2)
? (reference_bce_e2 - total_bce_e2) : 32'd0;
below_reference_estimate =
(reference_bce_e2 != 32'd0)
&& ((shortfall_bce_e2 * 32'd100)
> (reference_bce_e2 * 32'(tolerance_pct)));
reconciles = !exceeds_budget && !below_reference_estimate;
end
endmoduleClassification: an accumulator with two comparisons, of which the second is the one nobody makes.
What it teaches: that below_reference_estimate is the omission detector and that it needs a reference bill the design team did not write. A total 1.27% below a reference is not a rounding difference; it is thirteen structures against five, and the missing eight are all diagnostics.
And it teaches that diagnostic_share_x100 deserves its own accumulator. Module 25's instruments come to 0.85% of the total, and a review that reports the share makes the cut argument explicit: somebody proposing to remove the duplicate detector is proposing to save 0.84% of the switch, and the review should say so rather than leaving it to a schedule pressure.
Deliberately simplified: areas are summed in units of 100 BCE to keep the accumulator in range, which loses resolution on the small entries — the flood counters at 3 072 BCE round to 30. tolerance_pct has no principled default. And the reference bill must come from outside the programme, which is the same organisational requirement Chapter 24.3 §13 established for an independent model and for the same reason.
Production implication: the reference bill is the artefact this chapter is trying to be, and its provenance is what makes it work. A bill assembled by the design team from its own architecture reproduces the omissions it is meant to catch — the team lists what it thought of, twice. A bill assembled from a track like this one, or from a previous generation's post-silicon inventory, is independent by construction, and comparing against it costs one subtraction. The honest statement is that Section 6's table IS the reference bill for a 64-port 100 Gb/s Ethernet subsystem, derived across twenty-five modules by somebody with no stake in a particular programme's schedule — which is the only property that matters about it.
8. The Latency Reconciliation, Worked
Area is a sum somebody can check. Latency is a sum nobody adds, and the omission has a different signature.
One hop through a 100 Gb/s switched path, 1 518-octet frames, 100 metres of fibre.
| Term | Value | Derived in |
|---|---|---|
| ingress serialisation | 121.44 ns | Chapter 8.1 |
| PHY latency, receive | 50 ns | Chapter 9.6's FEC term |
| lookup pipeline, 36 stages at 1.2 GHz | 30.00 ns | Chapter 23.3 §2 |
| fabric and queueing, uncongested | 50 ns | Chapter 23.1 §4 |
| egress serialisation | 121.44 ns | Chapter 8.1 |
| PHY latency, transmit | 50 ns | Chapter 9.6 |
| propagation, 100 m fibre | 490.00 ns | Chapter 8.2 §3 |
| one hop | 912.88 ns | — |
| five hops | 4 564.4 ns — 4.564 µs | Chapter 23.1's topology |
Propagation is 53.7% of a single hop and it is the term no design owns, no review budgets and no optimisation touches.
And the two terms a design does own are 8.76% together — the lookup pipeline at 30 ns and the fabric at 50 — so a team that halves its pipeline depth has improved the end-to-end latency by 1.64%.
Which is the reconciliation's first finding: most of the budget belongs to somebody else.
| Share of one hop | Who owns it | |
|---|---|---|
| serialisation, both directions | 26.6% | the frame size and the line rate |
| PHY, both directions | 11.0% | Chapter 9.6's FEC — a standard |
| propagation | 53.7% | physics and the cable plant |
| lookup and fabric | 8.76% | the design |
The second finding is what the table does not contain, and it is the one a review must add: the congested case. Every value above is uncongested. Chapter 23.3 §9's buffer holds 2 224 µs at one port — which is 487 times the five-hop uncongested latency — so a single congestion event dominates every term in the table by three orders of magnitude.
9. RTL 4 — The Latency Reconciler
// ---------------------------------------------------------------------
// latency_reconciler -- a path's latency terms summed, with the share
// each party owns and the congested case as a separate column.
//
// The output that matters is design_owned_share_ppm, which is 88 000
// uncongested and near a million congested -- the same design, two
// completely different answers to "is this our problem".
// ---------------------------------------------------------------------
module latency_reconciler
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic term_valid,
input logic [31:0] term_ns_x100,
input logic term_is_design_owned,
input logic [15:0] hops,
input logic [31:0] buffer_max_queue_ns_x100,
input logic [31:0] budget_ns_x100,
input logic [15:0] specified_percentile,
output logic [31:0] hop_total_ns_x100,
output logic [31:0] design_owned_ns_x100,
output logic [31:0] path_total_ns_x100,
output logic [31:0] congested_total_ns_x100,
output logic [31:0] design_owned_share_ppm,
output logic [31:0] congested_ratio_x10,
output logic within_budget,
output logic percentile_specified,
output logic budget_is_uncongested_only,
output logic [31:0] c_terms
);
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
hop_total_ns_x100 <= '0; design_owned_ns_x100 <= '0; c_terms <= '0;
end else if (term_valid) begin
hop_total_ns_x100 <= hop_total_ns_x100 + term_ns_x100;
if (term_is_design_owned)
design_owned_ns_x100 <= design_owned_ns_x100 + term_ns_x100;
c_terms <= c_terms + 32'd1;
end
end
always_comb begin
path_total_ns_x100 = hop_total_ns_x100 * 32'(hops);
// Chapter 23.3 Section 9: one congestion event dwarfs the structure.
congested_total_ns_x100 = path_total_ns_x100 + buffer_max_queue_ns_x100;
design_owned_share_ppm = (hop_total_ns_x100 == 0) ? 32'd0
: ((design_owned_ns_x100 * 1_000_000)
/ hop_total_ns_x100);
congested_ratio_x10 = (path_total_ns_x100 == 0) ? 32'd0
: ((congested_total_ns_x100 * 32'd10)
/ path_total_ns_x100);
within_budget = (path_total_ns_x100 <= budget_ns_x100);
// THE two fields a review must record and usually does not.
percentile_specified = (specified_percentile != 16'd0);
budget_is_uncongested_only = !percentile_specified;
end
endmoduleClassification: an accumulator with an ownership tag, and a second total that is three orders of magnitude larger.
What it teaches: that design_owned_share_ppm is 87 623 uncongested — 8.76%, the lookup pipeline and the fabric — and that the same design owns 99.8% of the congested case. A review that asks "is latency our problem" gets two opposite answers depending on a condition the question does not name.
And it teaches that budget_is_uncongested_only is a one-bit check with a large consequence. A latency budget with no specified percentile is a budget for an idle network, and Chapter 23.3 §9's buffer can add 2 224 µs to a 4.564 µs path.
Deliberately simplified: the model sums terms without regard to whether they are per hop or per path — propagation is per hop and depends on that hop's length, which a single scalar cannot express. buffer_max_queue_ns_x100 is a worst case that a dynamic-threshold buffer reaches only when other ports are idle — Chapter 23.3 §9's 2 793% over-commitment at idle. And specified_percentile is recorded and not used, deliberately: the model cannot compute a percentile from structural terms, and pretending otherwise is exactly the error the field exists to flag.
Production implication: the unused percentile field is the honest form of a limit, and it points at what a review can and cannot do. An architecture review can establish a latency FLOOR — the sum of structural terms — and cannot establish a distribution, because a distribution needs an offered load and a scheduling policy that do not exist yet. What the review can require is that the floor is stated, the buffer's maximum contribution is stated, and a percentile target is named for Chapter 26.3 to measure against. A review that produces three numbers and a deferral is doing its job; one that produces a single latency figure has answered a question nobody asked.
10. The Claims Auditor
Sections 6 and 8 reconciled two sums. This section audits the individual claims, and the test has three parts because there are three ways an item can be hollow.
A claim is auditable if it has a number, a threshold, and a witness who is not its author.
| Number | Threshold | Witness | State | What a reader can do |
|---|---|---|---|---|
| no | — | — | unfalsifiable | nothing |
| yes | no | — | unfalsifiable | read a fact |
| yes | yes | no | self-witnessed | check the arithmetic, not the premise |
| yes | yes | yes | auditable | check both |
Row three is the state most architecture reviews are in and it is Chapter 24.3 §20's class 114 at the level of a row. The value and the threshold were produced by the same team; when they disagree, moving the threshold is cheaper than moving the design, and nothing in the review distinguishes a relaxed threshold from a met one.
The distinguishing question is not "is the number right" but "who would be able to say it was wrong".
And the witness requirement has two conditions, which Chapter 24.3 §13 derived and this chapter inherits.
| Condition | Why | |
|---|---|---|
| 1 | a different author | otherwise the two agreements are one |
| 2 | who did not see the design | otherwise the model is a second description of the same artefact |
For an architecture review the witness is usually one of three things, and all three are available.
| Witness | What it checks | Cost |
|---|---|---|
| a derivation from a public source | the number follows from a published bound | a citation — Section 2's right-hand column |
| a previous generation's measured value | the number is plausible for this class of part | a post-silicon inventory |
| a second team's independent calculation | both the number and its premises | engineer-weeks — Chapter 24.3 §22 |
Row one is what this chapter's twenty items provide — each value's derivation is named, so a reader can recompute it — and it is the cheapest of the three by a wide margin.
11. RTL 5 — The Claims Auditor
// ---------------------------------------------------------------------
// claims_auditor -- the three-part test on each item, and the tally
// across a review.
//
// The output that matters is auditable_share_ppm, because a review's
// credibility is the share of its items a reader could have disputed.
// ---------------------------------------------------------------------
module claims_auditor
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic item_valid,
input logic has_value,
input logic has_threshold,
input logic has_witness,
input logic witness_saw_design,
input logic witness_is_citation,
input logic threshold_declared_unknown,
output logic [1:0] state,
output logic witness_is_independent,
output logic [15:0] c_items,
output logic [15:0] c_unfalsifiable,
output logic [15:0] c_self_witnessed,
output logic [15:0] c_auditable,
output logic [15:0] c_threshold_unknown,
output logic [31:0] auditable_share_ppm,
output logic review_is_auditable,
output logic open_questions_visible
);
always_comb begin
// Chapter 24.3 Section 13's two conditions.
witness_is_independent = has_witness
&& (witness_is_citation || !witness_saw_design);
state = 2'(claim_state(has_value, has_threshold, witness_is_independent));
end
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
c_items <= '0; c_unfalsifiable <= '0; c_self_witnessed <= '0;
c_auditable <= '0; c_threshold_unknown <= '0;
end else if (item_valid) begin
c_items <= c_items + 16'd1;
case (state)
2'(CLAIM_UNFALSIFIABLE): c_unfalsifiable <= c_unfalsifiable + 16'd1;
2'(CLAIM_SELF_WITNESSED):c_self_witnessed <= c_self_witnessed + 16'd1;
default: c_auditable <= c_auditable + 16'd1;
endcase
if (threshold_declared_unknown)
c_threshold_unknown <= c_threshold_unknown + 16'd1;
end
end
always_comb begin
auditable_share_ppm = (c_items == 16'd0) ? 32'd0
: ((32'(c_auditable) * 1_000_000) / 32'(c_items));
review_is_auditable = (c_unfalsifiable == 16'd0)
&& (c_self_witnessed == 16'd0);
// Section 10's callout: an item that declares its threshold unknown
// is honest and names a person to ask.
open_questions_visible = (c_threshold_unknown != 16'd0)
|| (c_unfalsifiable == 16'd0);
end
endmoduleClassification: a three-state classifier and a tally, whose one derived rule is Chapter 24.3 §13's two-condition witness.
What it teaches: that witness_is_independent is not the same as has_witness, and the difference is one OR. A citation is independent by construction — the deriving chapter existed before the design — and a colleague's review is independent only if they did not see the design, which is Chapter 24.3 §13's condition and is rarely met.
And it teaches that open_questions_visible treats a declared-unknown threshold as a GOOD state. An item reading 64 MB against an unknown requirement contributes to c_threshold_unknown and not to c_auditable — it is not a pass — but it names the gap, where an item reading 64 MB alone reads as complete and hides it.
Deliberately simplified: witness_saw_design is an input a human supplies and nothing can verify — the same unavoidable gap Chapter 24.3 §16 left open. A citation is treated as automatically independent, which is true of a published derivation and false of an internal document the same team wrote. And the auditor examines items one at a time, so it cannot catch the failure Section 6's reconciler is for: an item that is absent entirely.
Production implication: the absent-item blind spot is why this chapter has three models rather than one, and the division of labour is worth stating. The claims auditor checks the items that are present; the area and latency reconcilers check for items that are missing; and the readiness model counts how much of the verdict is load-bearing. No one of them catches the other two's failures — an auditor cannot notice a row that was never written, and a reconciler cannot tell a well-sourced number from an invented one. A review that runs only the auditor is thorough about the wrong half, and running all three costs the same afternoon.
12. Thresholds Are the Hard Part
Section 2 gave twenty numbers and Section 10 established that a number without a threshold cannot fail. This section is about where thresholds come from, and the answer is uncomfortable.
Three kinds of threshold, and only one of them a design team can produce.
| Kind | Example | Who owns it |
|---|---|---|
| derived | the pipeline must be ≥ 7.94 lanes because the packet rate is 9.524 Gpps | the architect — it follows from a requirement |
| structural | the occupancy alarm must be ≤ 80% because the table's ceiling is 80.5% | the design — Chapter 25.5 §8 |
| environmental | the buffer must absorb a burst of X microseconds | NOBODY IN THE ROOM |
Row three is the one that stalls a review, and this track has met it repeatedly under different names.
| Threshold | Depends on | Who knows it | Chapter |
|---|---|---|---|
| buffer size | the burst distribution | the deployment | Chapter 23.3 §9 |
| MAC table size | the address population | the deployment | Chapter 25.5 §6 |
| ageing interval | the address recycle rate | the orchestrator | Chapter 25.2 §8 |
| replay window | the fabric's path skew | the topology | Chapter 25.3 §15 |
| storm-control setting | the legitimate flood rate | the deployment | Chapter 25.5 §12 |
| flap threshold | the legitimate move rate | the site | Chapter 25.2 §16 |
| pause watermark | the link's dead time | the cable plant | Chapter 14.2 §9 |
Seven thresholds, seven owners, and none of them is the design team. Every one has a documented default that this track has shown to be wrong in at least one deployment — 300 seconds, 75%, 90%, a 1% storm-control setting — and every default is a guess standing in for a derivation nobody performed.
A design team can derive a threshold from a requirement and cannot invent the requirement. The review's job is to name the person who can, not to fill the cell.
Which gives the review a fourth outcome besides pass, fail and unknown: DEFERRED WITH AN OWNER.
| Outcome | What it means | What happens next |
|---|---|---|
| PASS | value meets threshold, both auditable | nothing |
| FAIL | value misses threshold | the design changes |
| UNKNOWN | no value | the architect decides |
| DEFERRED | value exists; the threshold's owner is named | somebody outside the room is asked |
And a review that cannot express the fourth outcome converts every one of them into a PASS, because the item has a number and nobody present can say it is wrong.
13. RTL 6 — The Threshold Binder
// ---------------------------------------------------------------------
// threshold_binder -- where each threshold comes from, and what happens
// to the ones nobody in the room owns.
//
// The output that matters is becomes_a_default, which is high for every
// deferred threshold that the design hard-codes -- and Section 12's
// callout lists four that did.
// ---------------------------------------------------------------------
module threshold_binder
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic item_valid,
input logic threshold_is_derived,
input logic threshold_is_structural,
input logic threshold_is_environmental,
input logic owner_named,
input logic design_exposes_parameter,
input logic design_hardcodes_value,
output logic [1:0] outcome,
output logic deferred,
output logic becomes_a_default,
output logic deferred_correctly,
output logic [15:0] c_derived,
output logic [15:0] c_structural,
output logic [15:0] c_environmental,
output logic [15:0] c_deferred,
output logic [15:0] c_silent_defaults,
output logic [15:0] c_exposed,
output logic [31:0] exposure_share_ppm
);
// outcome: 0 pass, 1 fail, 2 unknown, 3 deferred.
always_comb begin
// Only an environmental threshold can be deferred; the other two
// are the design's own to produce.
deferred = threshold_is_environmental && !owner_named;
outcome = deferred ? 2'd3 : 2'd0;
// THE failure. A deferred threshold that the design hard-codes
// becomes a deployment decision made at architecture time.
becomes_a_default = threshold_is_environmental && design_hardcodes_value
&& !design_exposes_parameter;
// And the correct handling: expose it and name the owner.
deferred_correctly = threshold_is_environmental
&& design_exposes_parameter && owner_named;
exposure_share_ppm = (c_environmental == 16'd0) ? 32'd0
: ((32'(c_exposed) * 1_000_000) / 32'(c_environmental));
end
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
c_derived <= '0; c_structural <= '0; c_environmental <= '0;
c_deferred <= '0; c_silent_defaults <= '0; c_exposed <= '0;
end else if (item_valid) begin
if (threshold_is_derived) c_derived <= c_derived + 16'd1;
if (threshold_is_structural) c_structural <= c_structural + 16'd1;
if (threshold_is_environmental)c_environmental <= c_environmental + 16'd1;
if (deferred) c_deferred <= c_deferred + 16'd1;
if (becomes_a_default) c_silent_defaults <= c_silent_defaults + 16'd1;
if (design_exposes_parameter) c_exposed <= c_exposed + 16'd1;
end
end
endmoduleClassification: a three-way classification of a threshold's provenance, and a counter for the ones that become defaults.
What it teaches: that becomes_a_default is the review's real failure mode and it does not look like one. An environmental threshold the design hard-codes passes every check in Sections 5, 7, 9 and 11 — it has a value, it is internally consistent, the arithmetic is right — and it has made a deployment decision that the deployment will discover as a symptom.
And it teaches that exposure_share_ppm is the number a review should carry forward. Of the environmental thresholds, how many does the design expose? Section 12's callout lists four that were not, and in each case the fix was a register the design could have had for nothing.
Deliberately simplified: the three provenance kinds are treated as exclusive where a threshold can be both structural and environmental — the occupancy alarm's ceiling is structural at 80.5% and its useful setting depends on how fast the address population grows. owner_named is a fact about a document. And outcome never reports PASS or FAIL, because this module classifies a threshold's origin and Section 3's model evaluates it — the two are deliberately separate so that a threshold can be well-sourced and still missed.
Production implication: the exposure list is the artefact to carry out of the review and it is short. Seven parameters, from Section 12's table — buffer size, table size, ageing interval, replay window, storm-control setting, flap threshold and pause watermark — and for each the review records the owner and whether the design exposes it. That list is simultaneously the product's configuration specification, the deployment guide's contents page, and the set of things Chapter 26.3 will have to measure. A programme that produces it has turned its deferred decisions into a deliverable; one that does not has turned them into defaults.
14. What a Review Must Never Do
Five prohibitions.
| # | Never | Because |
|---|---|---|
| 1 | accept an item that names a quality | Section 4: it cannot fail, and it crowds out the item that could |
| 2 | report a pass count without the count that could have failed | Section 5: "20 of 20" and "6 of 20 could fail" are the same report |
| 3 | accept a value without a threshold, or mark it PASS | Section 10: it is unfalsifiable, and DEFERRED is the honest outcome |
| 4 | reconcile a total against a budget alone | Section 6: a budget catches excess and an independent bill catches omission |
| 5 | hard-code an environmental threshold | Section 12: it becomes a default, and four of this track's four were wrong |
Row two is the cheapest to fix and the most often missing, and it is Chapter 25.6 §20's class 120 in a management report: a pass total that includes items which could not have failed.
15. RTL 7 — Review Telemetry
// ---------------------------------------------------------------------
// review_telemetry -- what a review should report about itself, so a
// reader can weigh the verdict.
//
// Design rule: every number here is about the REVIEW rather than about
// the design, because a verdict's credibility is a property of the
// instrument that produced it.
// ---------------------------------------------------------------------
module review_telemetry
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic clear,
input logic item_valid,
input logic can_fail_i,
input logic passed_i,
input logic failed_i,
input logic deferred_i,
input logic auditable_i,
input logic reference_copy_i,
input logic exposed_i,
input logic [15:0] milestone_id,
output logic [15:0] c_items,
output logic [15:0] c_can_fail,
output logic [15:0] c_passed,
output logic [15:0] c_failed,
output logic [15:0] c_deferred,
output logic [15:0] c_auditable,
output logic [15:0] c_reference_copies,
output logic [15:0] c_exposed,
output logic [31:0] readiness_ppm_o,
output logic [31:0] auditable_ppm,
output logic [31:0] dilution_ppm,
output logic verdict_o,
output logic verdict_is_reportable
);
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n || clear) begin
c_items <= '0; c_can_fail <= '0; c_passed <= '0; c_failed <= '0;
c_deferred <= '0; c_auditable <= '0; c_reference_copies <= '0;
c_exposed <= '0;
end else if (item_valid) begin
c_items <= c_items + 16'd1;
if (can_fail_i) c_can_fail <= c_can_fail + 16'd1;
if (passed_i) c_passed <= c_passed + 16'd1;
if (failed_i) c_failed <= c_failed + 16'd1;
if (deferred_i) c_deferred <= c_deferred + 16'd1;
if (auditable_i) c_auditable <= c_auditable + 16'd1;
if (reference_copy_i) c_reference_copies <= c_reference_copies + 16'd1;
if (exposed_i) c_exposed <= c_exposed + 16'd1;
end
end
always_comb begin
readiness_ppm_o = 32'(readiness_ppm(int'(c_can_fail), int'(c_items)));
auditable_ppm = (c_items == 16'd0) ? 32'd0
: ((32'(c_auditable) * 1_000_000) / 32'(c_items));
// Section 5: how much of the verdict was not load-bearing.
dilution_ppm = (c_items == 16'd0) ? 32'd0
: (((32'(c_items) - 32'(c_can_fail)) * 1_000_000)
/ 32'(c_items));
verdict_o = (c_failed == 16'd0);
// THE rule: a verdict is reportable only with its denominator.
verdict_is_reportable = (c_can_fail != 16'd0);
end
endmoduleClassification: a counter bank whose subject is the review rather than the design.
What it teaches: that verdict_is_reportable is low when no item could have failed, which is the degenerate case Section 4's table's last row describes — a review of twenty adjectives produces a pass that is true of every possible design. One comparison catches it.
And it teaches that dilution_ppm belongs beside the verdict. A review reporting "PASSED, dilution 700 000 ppm" has said that 70% of its items could not have failed; one reporting "20 of 20 PASSED" has said the same thing and concealed it. The two reports differ by one field.
Deliberately simplified: the counters are per review and milestone_id is accepted and unused — Section 5's production note argues for a per-milestone history and this module records only the current pass. reference_copy_i is a human judgement, as in Section 5. And verdict_o is a plain conjunction where a real review has severities and a single FAIL on a minor item should not block a programme.
Production implication: the severity omission is the one that makes a binary verdict unusable in practice, and the fix has a shape worth borrowing from elsewhere in this track. Chapter 21.6 §13 argued for a reason field on a drop and Chapter 12.4 §4 for a cause classifier on a flood; a review item needs the same thing — a failure that names its consequence. An item failing because the buffer is 10% under its requirement and one failing because the parse window does not cover a declared offload are different events, and a verdict that cannot distinguish them is either ignored or blocks on everything. Three severity levels and a required consequence sentence per failure is the whole mechanism, and it converts a gate into a risk register.
16. RTL 8 — The Review Conformance Monitor
// ---------------------------------------------------------------------
// review_conformance -- the checks that hold a review to being an
// instrument rather than a ceremony.
//
// Every check here is about the review's own structure. There is no
// check that the design is good, because that is what the items are.
// ---------------------------------------------------------------------
module review_conformance
import archreview_pkg::*;
(
input logic clk,
input logic rst_n,
input logic [15:0] items_total,
input logic [15:0] items_can_fail,
input logic [15:0] items_auditable,
input logic [15:0] items_unfalsifiable,
input logic verdict_reported_with_denominator,
input logic reconciled_against_reference,
input logic reconciled_against_budget,
input logic [15:0] environmental_thresholds,
input logic [15:0] environmental_exposed,
input logic latency_percentile_specified,
output logic v_no_failable_items,
output logic v_verdict_without_denominator,
output logic v_unfalsifiable_present,
output logic v_no_reference_bill,
output logic v_threshold_hardcoded,
output logic v_latency_uncongested_only,
output logic [5:0] violations,
output logic conformant
);
always_comb begin
// 1. Section 4's last row: a review with nothing that can fail.
v_no_failable_items = (items_can_fail == 16'd0) && (items_total != 16'd0);
// 2. Prohibition 2 -- class 120 in a management report.
v_verdict_without_denominator = !verdict_reported_with_denominator;
// 3. Section 10 -- an item nobody could dispute.
v_unfalsifiable_present = (items_unfalsifiable != 16'd0);
// 4. Section 6 -- a budget catches excess, a bill catches omission.
v_no_reference_bill = reconciled_against_budget
&& !reconciled_against_reference;
// 5. Section 12 -- a deferred threshold that became a default.
v_threshold_hardcoded = (environmental_exposed < environmental_thresholds);
// 6. Section 8 -- a budget for a network with no traffic.
v_latency_uncongested_only = !latency_percentile_specified;
violations = { v_latency_uncongested_only, v_threshold_hardcoded,
v_no_reference_bill, v_unfalsifiable_present,
v_verdict_without_denominator, v_no_failable_items };
conformant = (violations == 6'b000000);
end
endmoduleClassification: six checks whose subject is a review's structure, and none of which examines the design.
What it teaches: that a review can be audited the same way a design can, and that the checks are the same shape: a number, a threshold, and a witness. v_unfalsifiable_present fires on a single hollow item; v_no_failable_items fires on the degenerate review that is otherwise indistinguishable from a thorough one.
And it teaches that v_no_reference_bill is the check with no precedent elsewhere in this track. Every other conformance monitor in twenty-six modules checks a design against a specification; this one checks a review against an independent inventory, which is Chapter 24.3 §20's class-114 repair applied to a programme's own process.
Deliberately simplified: every input is a fact about a document that a human asserts, so the monitor is a design-review aid and not a guarantee — the same limitation Chapter 24.3 §16 and Chapter 25.2 §16 both carry, and for the same structural reason. v_threshold_hardcoded compares two counts and cannot tell which threshold is missing. And there is no check on the reference bill's provenance, which is the recursion: an independent bill written by the same team is not independent, and no check inside the process can establish that it was not.
Production implication: the recursion is where this chapter stops and it is worth stating plainly rather than papering over. A process cannot verify its own independence — that is Chapter 24.3 §20's class 114 in its most general form — and every mechanism in this chapter is a way of making the dependence visible rather than removing it. The twenty items' deriving chapters are independent because they were written without this programme in view; that is the only property that makes them a witness, and it is a property of their history rather than of anything a monitor can check. A review's honest claim is therefore not we verified the architecture but we compared it against twenty numbers somebody else derived, and here is what did not match — which is a smaller claim and a true one.
17. The Review, Priced Against What It Prevents
Twenty items and three models. This section asks what the pass costs and what it is worth.
The instruments, in the unit the rest of the track uses.
| Structure | BCE | × the datapath |
|---|---|---|
review_item_model | 1 920 | 0.007 |
readiness_model | 3 200 | 0.011 |
area_reconciler | 2 560 | 0.009 |
latency_reconciler | 2 560 | 0.009 |
claims_auditor | 2 240 | 0.008 |
threshold_binder | 2 560 | 0.009 |
review_telemetry | 3 200 | 0.011 |
review_conformance | 0 — combinational | 0 |
| total | 18 240 | 0.064 |
None of it ships, which is the point of stating it: the review is an instrument, its cost is a few engineer-days, and the only reason to express it as RTL is that the checks are the same kind of object as every other check in this track.
And what it prevents, from the failures this track has derived.
| Failure | What it costs when it ships | Which item catches it |
|---|---|---|
| a prefetch store sized for the last generation | receive drops at line rate, an idle host — Chapter 23.4 §7 | 13 |
| an occupancy alarm above the table's ceiling | 19.5% of destinations flooding, no alarm — Chapter 25.5 §8 | 6 |
| no duplicate detection | half of two stations' inbound traffic lost — Chapter 25.2 §4 | 20 |
| a fabric striping past the context cache | 35.1 Gb/s of a 100 Gb/s port — Chapter 23.4 §12 | 16 |
| an undeclared parse crossing | a checksum over the wrong range — Chapter 25.1 §12 | 17 |
| FIFO ingress queues | 58.6% throughput — Chapter 14.3 §4 | 12 |
| a credit reservation nobody budgeted | a link at 3.9% of its rate — Chapter 24.2 §12 | 11 |
Seven failures, seven items, and every one of them is a number somebody could have written down before RTL existed.
The review's value is not that it finds mistakes. It is that it forces twenty decisions to be made with numbers attached, at a point where changing them costs a conversation rather than a respin.
18. What the Review Assumes
Eight assumptions.
| # | Assumption | If it is false |
|---|---|---|
| 1 | a 64-port 100 Gb/s reference design | every value in Section 2 scales; the items do not change |
| 2 | Chapter 23.3's structure sizes | the reconciliation's reference bill moves; the method does not |
| 3 | the twenty items are complete for an architecture pass | RTL and verification are Chapter 26.2's; performance and observability are Chapter 26.3's |
| 4 | a citation counts as an independent witness | true of a published derivation, false of an internal document the same team wrote |
| 5 | environmental thresholds have owners outside the room | Section 12's seven; a programme where they do not has a different problem |
| 6 | a verdict is a conjunction | a real review has severities — Section 15's production note |
| 7 | latency terms are additive | true of the structural floor and false of the queueing distribution |
| 8 | BCE prices the instruments | Section 19 examines it; the interesting answer is that it prices almost nothing here |
Assumption 3 is the scope boundary and it is worth stating what is deliberately absent. No item here is about RTL quality, coverage, timing closure or verification methodology — those are Chapter 26.2's — and none is about measured performance or field observability, which are Chapter 26.3's. This pass is held before RTL exists and its outputs are numbers, not code.
19. The Cost, Accounted — in BCE
This chapter's blocks, totalled in Section 17: 18 240 BCE, 0.064 of a MAC receive datapath.
And the structures the items are about, which is the reconciliation Section 6 performed.
| BCE | × the datapath | % of the total | |
|---|---|---|---|
| packet buffer | 5.12 × 10⁸ | 1 807 | 90.0% |
| forwarding tables | 5.04 × 10⁷ | 178 | 8.86% |
| Module 25's diagnostics | 4.86 × 10⁶ | 17.2 | 0.85% |
| everything else | 1.88 × 10⁶ | 6.6 | 0.33% |
| total | 5.691 × 10⁸ | 2 009 | 100% |
| this chapter's instruments | 18 240 | 0.064 | 0.0032% |
20. Properties Worth Asserting, and One Worth Refusing
Fifty-one properties in six groups, and the refused one is the verdict of a review made of adjectives.
Group A — item structure (9).
// A1. An item can fail only with a value and a threshold.
p_it_can_fail: assert property (@(posedge clk) disable iff (!rst_n)
(can_fail == (has_value && has_threshold)));
// A2. An item with no value is an adjective.
p_it_adjective: assert property (@(posedge clk) disable iff (!rst_n)
!has_value |-> (kind == 2'(ITEM_ADJECTIVE)));
// A3. A value with no threshold is unfalsifiable.
p_it_unfalsifiable: assert property (@(posedge clk) disable iff (!rst_n)
(has_value && !has_threshold) |-> (state == 2'(CLAIM_UNFALSIFIABLE)));
// A4. Both plus no witness is self-witnessed.
p_it_self: assert property (@(posedge clk) disable iff (!rst_n)
(has_value && has_threshold && !has_witness)
|-> (state == 2'(CLAIM_SELF_WITNESSED)));
// A5. Pass and fail are exclusive and need can_fail.
p_it_exclusive: assert property (@(posedge clk) disable iff (!rst_n)
!(item_passes && item_fails));
// A6. Neither is asserted without can_fail.
p_it_gated: assert property (@(posedge clk) disable iff (!rst_n)
!can_fail |-> (!item_passes && !item_fails));
// A7. A lower-bound item fails below its threshold.
p_it_lower: assert property (@(posedge clk) disable iff (!rst_n)
(can_fail && !threshold_is_upper_bound && (value < threshold)) |-> item_fails);
// A8. Decoration is exactly the items that cannot fail.
p_it_decoration: assert property (@(posedge clk) disable iff (!rst_n)
(is_decoration == !can_fail));
// A9. Provenance is recorded when a chapter is named.
p_it_provenance: assert property (@(posedge clk) disable iff (!rst_n)
(deriving_chapter_x10 != 16'd0) |-> provenance_recorded);Group B — readiness (8).
// B1. Readiness is the share of items that are not adjectives.
p_rd_readiness: assert property (@(posedge clk) disable iff (!rst_n)
(c_items != 16'd0) |-> (readiness_ppm_o ==
32'(readiness_ppm(int'(c_items) - int'(c_adjectives), int'(c_items)))));
// B2. The verdict's information content is the failable count.
p_rd_information: assert property (@(posedge clk) disable iff (!rst_n)
(verdict_information_bits == c_can_fail));
// B3. A verdict is diluted when some items cannot fail.
p_rd_diluted: assert property (@(posedge clk) disable iff (!rst_n)
(c_can_fail < c_items) |-> verdict_is_diluted);
// B4. The kinds partition the items.
p_rd_partition: assert property (@(posedge clk) disable iff (!rst_n)
(c_items == c_adjectives + c_valued + c_thresholded + c_audited));
// B5. Failable items are the thresholded and audited ones.
p_rd_failable: assert property (@(posedge clk) disable iff (!rst_n)
(c_can_fail == c_thresholded + c_audited));
// B6. A passing verdict means no item failed.
p_rd_verdict: assert property (@(posedge clk) disable iff (!rst_n)
verdict |-> (c_failed == 16'd0));
// B7. Passes and failures never exceed the failable count.
p_rd_bounded: assert property (@(posedge clk) disable iff (!rst_n)
((c_passed + c_failed) <= c_can_fail));
// B8. A reference copy is counted separately from an adjective.
p_rd_copies: assert property (@(posedge clk) disable iff (!rst_n)
(item_valid && value_is_reference_copy) |=>
(c_reference_copies == $past(c_reference_copies) + 16'd1));Group C — the area reconciliation (9).
// C1. The total is the sum of the entries.
p_ar_sum: assert property (@(posedge clk) disable iff (!rst_n)
entry_valid |=> (total_bce_e2 == $past(total_bce_e2) + $past(entry_bce_e2)));
// C2. Diagnostics are a subset of the total.
p_ar_subset: assert property (@(posedge clk) disable iff (!rst_n)
(diagnostic_bce_e2 <= total_bce_e2));
// C3. Exceeding the budget is reported.
p_ar_budget: assert property (@(posedge clk) disable iff (!rst_n)
(total_bce_e2 > budget_bce_e2) |-> exceeds_budget);
// C4. THE check a per-block review cannot make.
p_ar_omission: assert property (@(posedge clk) disable iff (!rst_n)
((reference_bce_e2 != 32'd0) &&
((shortfall_bce_e2 * 32'd100) > (reference_bce_e2 * 32'(tolerance_pct))))
|-> below_reference_estimate);
// C5. Reconciliation needs both checks to pass.
p_ar_reconciles: assert property (@(posedge clk) disable iff (!rst_n)
reconciles |-> (!exceeds_budget && !below_reference_estimate));
// C6. A shortfall is zero when the total meets the reference.
p_ar_no_shortfall: assert property (@(posedge clk) disable iff (!rst_n)
(total_bce_e2 >= reference_bce_e2) |-> (shortfall_bce_e2 == 32'd0));
// C7. The diagnostic share is bounded.
p_ar_share: assert property (@(posedge clk) disable iff (!rst_n)
(diagnostic_share_x100 <= 16'd10_000));
// C8. Entries are counted.
p_ar_counted: assert property (@(posedge clk) disable iff (!rst_n)
entry_valid |=> (entries_counted == $past(entries_counted) + 16'd1));
// C9. A thirteen-entry bill exceeds a five-entry one.
p_ar_completeness: assert property (@(posedge clk) disable iff (!rst_n)
(entries_counted >= 16'd13) |-> !below_reference_estimate);Group D — the latency reconciliation (8).
// D1. The path total is the hop total times the hops.
p_lt_path: assert property (@(posedge clk) disable iff (!rst_n)
(path_total_ns_x100 == hop_total_ns_x100 * 32'(hops)));
// D2. The congested total includes the buffer's maximum.
p_lt_congested: assert property (@(posedge clk) disable iff (!rst_n)
(congested_total_ns_x100 == path_total_ns_x100 + buffer_max_queue_ns_x100));
// D3. The design owns a minority uncongested.
p_lt_minority: assert property (@(posedge clk) disable iff (!rst_n)
(c_terms >= 32'd7) |-> (design_owned_share_ppm < 32'd150_000));
// D4. And the congested case dwarfs the structural one.
p_lt_dwarfs: assert property (@(posedge clk) disable iff (!rst_n)
(buffer_max_queue_ns_x100 > path_total_ns_x100) |->
(congested_ratio_x10 > 32'd20));
// D5. A budget with no percentile is uncongested only.
p_lt_percentile: assert property (@(posedge clk) disable iff (!rst_n)
(budget_is_uncongested_only == !percentile_specified));
// D6. Design-owned terms are a subset of the total.
p_lt_subset: assert property (@(posedge clk) disable iff (!rst_n)
(design_owned_ns_x100 <= hop_total_ns_x100));
// D7. Within-budget compares the structural path only.
p_lt_budget: assert property (@(posedge clk) disable iff (!rst_n)
within_budget |-> (path_total_ns_x100 <= budget_ns_x100));
// D8. Terms are counted.
p_lt_counted: assert property (@(posedge clk) disable iff (!rst_n)
term_valid |=> (c_terms == $past(c_terms) + 32'd1));Group E — claims and thresholds (9).
// E1. A witness who saw the design is not independent unless cited.
p_ca_independent: assert property (@(posedge clk) disable iff (!rst_n)
(has_witness && witness_saw_design && !witness_is_citation)
|-> !witness_is_independent);
// E2. A citation is independent by construction.
p_ca_citation: assert property (@(posedge clk) disable iff (!rst_n)
(has_witness && witness_is_citation) |-> witness_is_independent);
// E3. The three states partition the items.
p_ca_partition: assert property (@(posedge clk) disable iff (!rst_n)
(c_items == c_unfalsifiable + c_self_witnessed + c_auditable));
// E4. A review is auditable only with no hollow items.
p_ca_auditable: assert property (@(posedge clk) disable iff (!rst_n)
review_is_auditable |-> ((c_unfalsifiable == 16'd0) &&
(c_self_witnessed == 16'd0)));
// E5. Only an environmental threshold may be deferred.
p_tb_deferred: assert property (@(posedge clk) disable iff (!rst_n)
deferred |-> threshold_is_environmental);
// E6. A hard-coded environmental threshold becomes a default.
p_tb_default: assert property (@(posedge clk) disable iff (!rst_n)
(threshold_is_environmental && design_hardcodes_value
&& !design_exposes_parameter) |-> becomes_a_default);
// E7. And exposing it with an owner is the correct handling.
p_tb_correct: assert property (@(posedge clk) disable iff (!rst_n)
deferred_correctly |-> (design_exposes_parameter && owner_named));
// E8. Exposure share is bounded.
p_tb_share: assert property (@(posedge clk) disable iff (!rst_n)
(exposure_share_ppm <= 32'd1_000_000));
// E9. Silent defaults are counted.
p_tb_counted: assert property (@(posedge clk) disable iff (!rst_n)
(item_valid && becomes_a_default) |=>
(c_silent_defaults == $past(c_silent_defaults) + 16'd1));Group F — telemetry and conformance (8).
// F1. A verdict is reportable only with a nonzero denominator.
p_tl_reportable: assert property (@(posedge clk) disable iff (!rst_n)
(verdict_is_reportable == (c_can_fail != 16'd0)));
// F2. Dilution is the complement of readiness.
p_tl_dilution: assert property (@(posedge clk) disable iff (!rst_n)
(c_items != 16'd0) |-> ((dilution_ppm + readiness_ppm_o) <= 32'd1_000_001));
// F3. A review with nothing failable is a violation.
p_cf_no_failable: assert property (@(posedge clk) disable iff (!rst_n)
((items_can_fail == 16'd0) && (items_total != 16'd0)) |-> v_no_failable_items);
// F4. A verdict without its denominator is a violation.
p_cf_denominator: assert property (@(posedge clk) disable iff (!rst_n)
!verdict_reported_with_denominator |-> v_verdict_without_denominator);
// F5. A budget-only reconciliation is a violation.
p_cf_reference: assert property (@(posedge clk) disable iff (!rst_n)
(reconciled_against_budget && !reconciled_against_reference)
|-> v_no_reference_bill);
// F6. An unexposed environmental threshold is a violation.
p_cf_hardcoded: assert property (@(posedge clk) disable iff (!rst_n)
(environmental_exposed < environmental_thresholds) |-> v_threshold_hardcoded);
// F7. A latency budget with no percentile is a violation.
p_cf_latency: assert property (@(posedge clk) disable iff (!rst_n)
!latency_percentile_specified |-> v_latency_uncongested_only);
// F8. Conformance is the disjunction of its six checks.
p_cf_vector: assert property (@(posedge clk) disable iff (!rst_n)
conformant |-> (violations == 6'b000000));Coverage — the review states a programme reaches and reports as identical.
c_it_adjective: cover property (@(posedge clk) kind == 2'(ITEM_ADJECTIVE));
c_it_audited: cover property (@(posedge clk) kind == 2'(ITEM_AUDITED));
c_rd_diluted: cover property (@(posedge clk) verdict_is_diluted);
c_rd_all_adject: cover property (@(posedge clk) (c_can_fail == 16'd0) && (c_items != 16'd0));
c_rd_ready: cover property (@(posedge clk) readiness_ppm_o == 32'd1_000_000);
c_ar_omission: cover property (@(posedge clk) below_reference_estimate);
c_ar_excess: cover property (@(posedge clk) exceeds_budget);
c_lt_no_pctile: cover property (@(posedge clk) budget_is_uncongested_only);
c_ca_self: cover property (@(posedge clk) state == 2'(CLAIM_SELF_WITNESSED));
c_ca_auditable: cover property (@(posedge clk) review_is_auditable);
c_tb_default: cover property (@(posedge clk) becomes_a_default);
c_tb_correct: cover property (@(posedge clk) deferred_correctly);
c_tl_unreportable:cover property (@(posedge clk) !verdict_is_reportable);
c_cf_clean: cover property (@(posedge clk) conformant);21. Verification Scenarios
Fifty-eight scenarios in six groups, plus one directed test random stimulus will not produce.
Group 1 — item structure (10).
| # | Scenario | Expect |
|---|---|---|
| 1 | no value | ITEM_ADJECTIVE; can_fail low; decoration |
| 2 | value, no threshold | ITEM_VALUED; CLAIM_UNFALSIFIABLE |
| 3 | value and threshold, no witness | ITEM_THRESHOLDED; CLAIM_SELF_WITNESSED |
| 4 | all three | ITEM_AUDITED; CLAIM_AUDITABLE |
| 5 | value 64, lower-bound threshold 40 | passes |
| 6 | value 30, lower-bound threshold 40 | fails |
| 7 | value 256, upper-bound threshold 128 | fails — the over-provisioning case |
| 8 | an adjective item | neither passes nor fails — p_it_gated |
| 9 | a named deriving chapter | provenance_recorded |
| 10 | 1 000 items, 400 adjectives | c_decoration = 400 |
Group 2 — readiness (9).
| # | Scenario | Expect |
|---|---|---|
| 11 | 20 items, 20 valued | readiness 1 000 000 ppm; 20 failable |
| 12 | 20 items, 14 valued | 700 000 ppm; 6 failable |
| 13 | 20 items, 6 valued | 300 000 ppm; 14 adjectives |
| 14 | 20 items, 0 valued | 0 ppm; verdict_is_reportable low |
| 15 | the last case's verdict | PASS — and it is true of every design |
| 16 | 14 adjectives, 6 pass | verdict PASS; information content 6 |
| 17 | the two reports compared | "20 of 20 PASSED" in both |
| 18 | a value copied from this chapter | c_reference_copies increments; kind unaffected |
| 19 | 149 descriptors at 400 Gb/s and 2 µs | wrong by 8×; the item reads as filled |
Group 3 — the area reconciliation (10).
| # | Scenario | Expect |
|---|---|---|
| 20 | 13 entries, the full bill | 5.691 × 10⁸ BCE; 2 009 datapaths |
| 21 | 5 entries — buffer and tables only | 5.62 × 10⁸; 1.27% below the reference |
| 22 | the same against a budget of 6 × 10⁸ | within budget; below_reference_estimate HIGH |
| 23 | a 5% tolerance | 1.27% is inside it; no flag — the tolerance hides it |
| 24 | a 1% tolerance | flagged |
| 25 | the diagnostic share on the full bill | 0.85% |
| 26 | a 256 MB buffer | 2.15 × 10⁹ BCE; exceeds a 6 × 10⁸ budget |
| 27 | no reference supplied | below_reference_estimate low — the check is disabled |
| 28 | 13 entries counted | p_ar_completeness holds |
| 29 | total equals the reference | shortfall zero; reconciles |
Group 4 — the latency reconciliation (9).
| # | Scenario | Expect |
|---|---|---|
| 30 | seven terms, one hop | 912.88 ns |
| 31 | five hops | 4 564.4 ns — 4.564 µs |
| 32 | design-owned terms | 80 ns — 87 623 ppm, 8.76% |
| 33 | propagation's share | 53.7% of one hop |
| 34 | the buffer's maximum queueing | 2 224 µs — a ratio of 487 |
| 35 | no percentile specified | budget_is_uncongested_only high |
| 36 | a 99th-percentile target named | low; the item is complete |
| 37 | a 5 µs budget against 4.564 | within budget — structurally |
| 38 | the same budget against the congested case | exceeded by 487× |
Group 5 — claims and thresholds (10).
| # | Scenario | Expect |
|---|---|---|
| 39 | a witness who saw the design, no citation | not independent |
| 40 | a citation | independent by construction |
| 41 | 20 items, 6 auditable | auditable_share_ppm = 300 000 |
| 42 | any unfalsifiable item | review_is_auditable low |
| 43 | a threshold declared unknown | counted; not a pass; the gap is visible |
| 44 | a derived threshold | not deferrable |
| 45 | a structural threshold | not deferrable |
| 46 | an environmental threshold, no owner | deferred |
| 47 | the same, hard-coded, not exposed | becomes_a_default |
| 48 | the same, exposed with an owner | deferred_correctly |
Group 6 — telemetry and conformance (10).
| # | Scenario | Expect |
|---|---|---|
| 49 | 7 environmental thresholds, 3 exposed | exposure_share_ppm = 428 571; v_threshold_hardcoded |
| 50 | all 7 exposed | clean |
| 51 | 20 items, 6 failable | dilution 700 000 ppm |
| 52 | a verdict reported without its denominator | v_verdict_without_denominator |
| 53 | 0 failable items | v_no_failable_items; verdict_is_reportable low |
| 54 | budget reconciliation only | v_no_reference_bill |
| 55 | both reconciliations | clean |
| 56 | no latency percentile | v_latency_uncongested_only |
| 57 | one unfalsifiable item | v_unfalsifiable_present |
| 58 | all six checks clear | conformant high |
22. Debugging a Review That Passed
Six symptoms, all of them after the fact.
| Symptom | First question | Where to look |
|---|---|---|
| an unbudgeted structure appearing during RTL | was there a reference bill? | Section 6 — a budget catches excess, a bill catches omission |
| a parameter nobody can change in the field | was its threshold environmental? | Section 12 — it became a default |
| a latency target missed under load | was a percentile specified? | Section 8 — the budget was for an idle network |
| a review that passed and a design that did not work | how many items could have failed? | Section 21's directed test |
| a number in the review that is wrong for this design | was it copied from a reference? | Section 5 — 149 is right at 100 Gb/s and wrong at 400 |
| an item everybody agreed with and nobody checked | who was its witness? | Section 10 — self-witnessed is the common state |
Row four has a procedure and it takes ten minutes: count the items whose predicate names a quantity. If that count is below the item count, the difference is the part of the review that could not have failed, and it is where the surprises came from.
23. Misconceptions
Six, in the wrong-model / what-it-costs / corrected-model form this track has used since Chapter 1.1.
Misconception 1 — "A review that passes is good news."
Wrong model. Twenty items, twenty passes, the design is sound.
What it costs. Section 21's directed test: two programmes, the same report, and one of them checked nothing. The cost is the failure that shipped — Chapter 25.5 §8's occupancy alarm set above a ceiling it cannot reach, reviewed and approved as "set appropriately".
Corrected model. A pass is good news in proportion to what could have failed. 20 of 20 PASSED, 20 could have failed is a strong result; 20 of 20 PASSED, 0 could have failed is not a result at all — and the two sentences differ by one number that most review templates do not carry.
Misconception 2 — "The numbers come from the review."
Wrong model. The review meeting is where the architecture's quantities get worked out.
What it costs. A room of senior engineers deriving Chapter 23.4 §7's descriptor count from memory, live, under time pressure — and getting 149 when the design runs at 400 Gb/s, where the same formula gives 595 — Chapter 23.4 §21, scenario 30. Section 5's c_reference_copies counts exactly this: a value that is correct in its source chapter and wrong for this design.
Corrected model. The review reads numbers that already exist and checks them against thresholds. Section 4's readiness metric is measured before the meeting: if it is below 100%, the meeting's output is a list of missing derivations, not a verdict.
Misconception 3 — "We reconciled against the budget, so the area is checked."
Wrong model. Total under budget means the area is understood.
What it costs. Section 6's arithmetic: five entries give 5.62 × 10⁸ BCE against a 6 × 10⁸ budget — comfortably inside — and the true bill is 5.691 × 10⁸ across thirteen entries. The shortfall is 1.27%, which is inside every tolerance a programme normally sets, and the eight missing structures appear during RTL as unbudgeted additions.
Corrected model. Reconcile against an independent bill, not a budget. A budget catches excess; only an itemised reference catches omission, and omission is the failure mode that arrives late.
Misconception 4 — "The latency budget is met."
Wrong model. One number, compared against one target.
What it costs. Section 8's one hop is 912.88 ns structurally and 2 224 µs with the buffer full — a ratio of 487. A design signed off at 4.564 µs over five hops meets its budget on an idle network and misses it by more than two orders of magnitude under the load it was bought for.
Corrected model. Three numbers and a deferral: the structural floor, the maximum the buffer can contribute, and the percentile the specification is written at. 53.7% of one hop is propagation — physics nobody in the room owns — and only 8.76% is design-owned, which is the number the review can actually act on.
Misconception 5 — "Everyone in the room agreed, so the claim is checked."
Wrong model. Consensus is verification.
What it costs. Section 10's distinction: a witness who saw the design is not independent of it. The failure is silent — the claim is recorded as reviewed, and the observation that would have refuted it was never made.
Corrected model. A witness is independent when it could have disagreed without having been in the room — a citation, a measurement, a simulation, a vendor datasheet. The twenty deriving chapters in Section 2 are the cheapest independent witnesses this design has, and using them costs one line per item.
Misconception 6 — "The thresholds we do not control are not ours."
Wrong model. Environmental parameters belong to the deployment, so the review skips them.
What it costs. Section 12's trap: a skipped threshold does not stay empty. The RTL needs a number, so somebody chooses one, it is hard-coded, and it ships as a default nobody agreed to — Section 21's scenarios 47 and 48 are exactly this pair, distinguished only by whether the parameter is exposed.
Corrected model. An environmental threshold is DEFERRED WITH AN OWNER, and the parameter is exposed. The review's obligation is not to know the value; it is to ensure the value is changeable by the person who will know it.
24. Interview Questions
Question 1 — "What makes a review item useful?"
A quantity, a threshold and a witness. Without the quantity the item is an adjective and cannot fail; without the threshold it can be evaluated but not decided; without a witness it is decided by the people who built the thing. Section 3's review_item_model classifies items into exactly these four grades — ADJECTIVE, VALUED, THRESHOLDED, AUDITED — and only the last one is a check.
Question 2 — "Your area reconciliation is 1.27% under an independent bill. Good or bad?"
Bad, and worse than being over. Under-total means structures are missing from the model, and Section 6 names the eight: the diagnostic and telemetry blocks, the conformance monitors, the FEC state, the parse contexts and the rest — 0.85% of the bill in diagnostics alone. Being over budget is a planning problem found early; being under an independent bill is an omission found in RTL.
Question 3 — "Where does a 400 Gb/s hop's latency actually go?"
53.7% is propagation. Of 912.88 ns, the design owns 80 ns — 8.76%. The consequence for review is that a demand to "cut hop latency 20%" is a demand for 182.6 ns against a design-owned budget of 80, which is impossible before anyone opens the RTL, and the review is where that becomes visible.
Question 4 — "A parameter's correct value depends on the deployment. What does the review do with it?"
Defer it to a named owner and require the parameter be exposed. Section 12's three kinds: derived thresholds follow from the design's own numbers, structural ones from its topology, and environmental ones from somebody outside the room. Only the third is deferrable — and a deferral without exposure becomes a hard-coded default, which is the same outcome as skipping it.
Question 5 — "Why is a review that cannot fail worse than no review?"
Because it produces the same artefact a real one does. Section 20's class 121: a predicate with no failing value passes by being evaluated. No review leaves the programme knowing it has not checked; a review of adjectives leaves it holding a signed report that says twenty of twenty passed — and the report is used downstream to justify skipping the check again.
Question 6 — "You have one hour with an architecture you have never seen. What do you ask for?"
Section 2's twenty rows, filled with this design's numbers, and the readiness percentage. Not opinions — the share of items that have a quantity. If it is 30%, the hour's output is a list of fourteen derivations somebody must produce, which is a more useful deliverable than a verdict; if it is 100%, the hour is spent on thresholds and witnesses, and a verdict is possible.
25. Questions and Answers
26. What's Next
This chapter closes the batch by turning the track's own derivations into a list somebody signs. Every row of Section 2 names a chapter, and the chapter is the item's witness — which is why the review is possible at all after twenty-six modules and would not have been after two.
The remaining chapters of Module 26 take the review outward.
| Next | What it adds to this chapter |
|---|---|
| 26.2 — RTL and Verification Review | the same discipline applied to coverage: what a closed coverage model could have failed to reach |
| 26.3 — Performance and Debug Review | the items whose thresholds only the first wafer can supply, and how the deferrals from Section 12 are closed |
| 26.4 — How Ethernet Is Actually Probed | the twelve rejected-property groups as one argument, and what the 121 classes have in common |
Before that, the two arithmetic results worth carrying forward. One hop is 912.88 ns and the design owns 80 of them — Chapter 8.4's budget, reconciled. Thirteen entries total 5.691 × 10⁸ BCE against Chapter 23.3's 5.62 × 10⁸ — the switch, plus everything the track added to make it observable.
And the sentence this batch ends on, which is the same one Section 21's directed test proves and Chapter 25.6 §20 stated for an assertion: a check is worth exactly the set of observations that would have refuted it. For a property that set is a waveform. For a review item it is a number. An empty set produces a pass in both cases, and the pass looks identical either way.
Continue learning
Related tutorials
- Related topic
The MAC/PHY Boundary in RTL
What five chapters described as one boundary is three in silicon: a data boundary at the port list, a clock boundary inside the elastic buffer, and a reset boundary that is an order rather than a place. Confusing any two produces a specific, recognisable integration failure.
- Related topic
The Ethernet MAC as an SoC IP Block
A MAC integrated into an SoC demands 1.143 times its line rate in memory bandwidth, crosses four clock domains, and at 100 Gb/s asks for 1.79 bus transactions per cycle.
- Related topic
RTL and Verification Review
546 declared coverage bins, 243 unreachable by construction, and one regression that is 51.832% or 93.399% depending on the denominator — plus the twenty bins random stimulus will never reach.
- Related topic
Performance and Debug Review
Seven thresholds the design cannot set, a five-hop latency that is 4.564 µs or 41.941 µs depending on the percentile, and a complete observability apparatus for 0.0820% of the die.
Standards & specifications
- Governing standard
- IEEE Std 802.3 (Ethernet)(opens IEEE in a new tab)
Defines the Ethernet MAC, the media-independent interfaces and the physical-layer sublayers, including framing, access control, auto-negotiation and per-rate PHY specifications. VLAN tagging, priority and time-sensitive shaping are defined by IEEE 802.1, not by 802.3.
This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.
Where this fits
Part of the Ethernet curriculum.
