Skip to content
VLSI Mentor

DDR · Module 33

Performance Review Checklist

The first gate whose pass criterion is a comparison against a computed expectation rather than against a contract. Nine items on which efficiency, which denominator, which of five bandwidths, and which operating point — where every weak instrument computes correctly.

The four preceding gates checked a design against contracts. A contract is satisfied or it is not. This gate has no contract to check against — it has numbers.

33.4 §25 handed this gate a specific failure it could not close. A sweep widened from 48 taps to 64: the architecture gate has no obligation about boot time, the RTL gate sees a correct expression, the PHY gate sees a sweep inside the hardware range, and the verification gate sees a quantity inside its bound. Four gates pass a change that doubles boot time for no margin. The reason is uniform — none of the four holds an objective, and a contract cannot express worse.

What does this number divide by, what was it measured at, and what would have to happen for it to read low?

Three clauses, and a performance number that cannot answer all three is not a measurement. CURRICULUM-DERIVED from Module 23's central law, which every one of its five chapters restates and which this gate takes as its premise: peak bandwidth is a property of the interface; achieved bandwidth is a property of the workload meeting the timing rules; and the gap between them is not waste — it is the cost of constraints that cannot be removed, plus decisions that can be improved.

That law contains this gate's whole difficulty. A review that finds a gap has found nothing until it has partitioned the gap, because the irreducible part is not a defect and the improvable part is not visible without the partition. DERIVED: eight of this chapter's nine items are, in one form or another, that partition.

1. How To Use This Chapter

Each of the nine review items answers the same eight questions.

FacetWhat it settles
Under reviewthe number, claim or proposal being examined
Invariant at riskthe reasoning that becomes unsound if it is wrong
Where it livesthe counter, the report, or the slide
Evidence to demandthe denominator, the operating point, or the counterfactual
What escapesthe decision made on a number that does not mean what it says
How DV proves ita workload at which the number is wrong, constructed on purpose
Telemetrywhat a performance report must publish for this item to be checkable
Misleading evidencea number that is correct, precise, and about something else

The eighth facet is qualitatively different at this gate, and it is the reason a performance review is harder than the four before it. At the architecture gate the misleading evidence is a reassuring document; at the RTL gate a reassuring waveform; at the PHY gate a part that boots; at the verification gate a complimentary report. Here it is a number that is arithmetically correct.

DERIVED: not one of the nine weak builds below computes anything incorrectly. Every division is right, every counter increments on the right event, every percentage is a true ratio of the two quantities it names. What is wrong is which two quantities, at what operating point, compared against what. CURRICULUM-DERIVED from 12.4 §2, which states the mechanism once and for the whole curriculum: collapsing distinct efficiencies into a single percentage “is how architectural arguments go wrong” — because a design can improve one while degrading another and a single number will report it as progress.

2. The One-Sentence Model

A performance review is sound when every efficiency names its denominator, when every attribution sums exactly to its window with a named residue, when latency-bound and bandwidth-bound are distinguished by a measurement rather than a symptom, when every proposed optimisation's ceiling is computed and compared against the gap it must close, when every latency statistic matches the deadline structure of the requester it describes, when the composition law is stated and matches the data, when every claim about an undeployed policy cites a counterfactual instrument, when every bandwidth figure carries which of five it is, and when every number carries the operating point it was measured at — and “we measured 33 gigabytes per second” is bit 0.

3. What This Chapter Owns

GroundOwner
The latency decomposition that sums exactly; the unbounded component; why the mean is wrong23.1
Peak bandwidth from verified parameters; four workload models; multiplicative composition; measure D23.2
What produces hit, miss and conflict counts; identical counts with opposite structure23.3
FR-FCFS and its three rules; what reordering gains and costs; the starvation bound23.4
Open, close and adaptive page policy; the crossover's closed form; hysteresis; counterfactual measurement23.5
The four efficiency measures and why they must stay distinct12.4
The five-quantity ladder, diagnosis by ratio, the ceiling computation30.8
Which platform class's requester mix produces which pressureModule 32
Reviewing a performance claim someone else madethis chapter

The boundary with 30.8 needs stating precisely, because that chapter already owns a method and this one is not a second method.

30.8 owns how to diagnose: a five-quantity ladder, four gaps with named causes and owners, diagnosis by ratio, and a ceiling computation for a proposed optimisation. This chapter's unit is somebody else's finished claim — a report, a slide, a commit message, a counter's value — and its output is a verdict on whether the claim survives. DERIVED: 30.8's method applied by the person who owns the system produces a diagnosis; this chapter's items applied to that diagnosis ask whether its numbers mean what the diagnosis assumed. A project can run 30.8's ladder correctly and fail six of the nine items below, because every rung of the ladder is a ratio and this gate is about ratios.

And the boundary with 33.2 §9 is narrow and worth being exact about. That item asks whether a denominator is derived from its own numerator — a question about one expression, answered by reading two lines. §6 below asks which denominator is the right one, which is a question about the claim rather than the code, and a design can pass 33.2 §9 with a perfectly independent denominator that measures the wrong thing.

4. Teaching-Model Boundary And Source Discipline

Every SystemVerilog block below is an instrument, not a design. Each one counts, divides and reports; none schedules, arbitrates or drives a pin. That is deliberate: this gate's defects live in instruments, and an instrument is the smallest thing that can hold one.

Claim classWhat it means hereExample below
Structurala real mechanism or a derivable arithmetic identityburst-length arithmetic, the four efficiency measures, Amdahl-form ceilings
Curriculum-derivedfollows from a cited chapter of this trackevery pass criterion, and the central law
Derivedcomputed in this chapter from the models belowevery gap figure in §16
Illustrativea chosen number that makes a mechanism visibleworkload mixes, hit rates, latencies, bin widths

Every bandwidth, latency and rate in this chapter is ILLUSTRATIVE unless it is an arithmetic identity. CURRICULUM-DERIVED from 23.2, which owns peak bandwidth derived from verified parameters and derives it there: this chapter takes a peak figure as given and reasons about what is done with it. DERIVED: where a number here is labelled STRUCTURAL it is an identity — bytes per burst from burst length and bus width, or cycles per transfer from a data rate — and it is computed in place rather than asserted.

One discipline is specific to this gate and needs saying. A performance number in a tutorial is a grade D quantity — educational representative — and every item below is written so the argument does not depend on the number's value. CURRICULUM-DERIVED from 18.4 §1's four evidence grades and 32.1 §15's variety 11: the failure mode is category drift, and a chapter about performance is the easiest place in a curriculum to drift a grade D figure into a grade B claim. No number here is offered as a platform's real value.

No external source was consulted and no network tool was used.

5. Why This Gate Cannot Use a Contract

Four gates have now passed a change that made a design worse, and it is worth writing down exactly why, because the reason determines this chapter's structure.

GateWhat it checksWhy M14 passes
33.1every invariant has a named mechanismboot time is not an invariant
33.2the code is that mechanismthe sweep expression is correct
33.3the design's beliefs about measured values are warranted64 taps is inside the hardware range
33.4the environment could have failedthe quantity is inside its bounding artifact
this gatethe number against a computed expectationit does not — boot time doubled

CURRICULUM-DERIVED from 30.3 §9's variety 8, of which this is the general case: a design that is slower than required violates nothing, so a safety property cannot see conservatism. And from 33.4 §15's variety 12, which extended that from timing conservatism to any quantity.

DERIVED: the extension is what makes this gate necessary rather than optional. A contract partitions behaviour into legal and illegal. A quantity has no such partitionit has a comparison, and a comparison needs a second number. Every item below is therefore built around producing that second number: a correct denominator, an exhaustive sum, a discriminating measurement, a computed ceiling, a matching statistic, a composition law, a counterfactual, a named level, an operating point.

And one consequence shapes every item's pass criterion. Because the second number must be computed rather than observed, this gate's findings are never “the measurement was wrong.” DERIVED: in all nine items below, both builds measure correctly and differ in what they compare against. That is the gate's signature, and §17's table is nine instances of it.

6. Review Item 1 — Which Efficiency Is This, and What Is Its Denominator?

FacetContent
Under reviewevery figure reported as an efficiency, utilisation or percentage
Invariant at riska percentage names one numerator and one denominator, both stated
Where it livesthe division, and the label on the report line
Evidence to demandthe measure's name, its denominator, and the other three measures' values
What escapesan architectural decision that improved one efficiency and paid for it out of another
How DV proves ita change that moves two measures in opposite directions
Telemetryfour numbers, never one
Misleading evidencea single percentage that went up

CURRICULUM-DERIVED from 12.4, which owns the distinction and states the consequence in its own scope: the measures “must stay distinct”, and “collapsing them into a single percentage is how architectural arguments go wrong.” And from 23.2, which names all four — command efficiency, slot utilisation, payload efficiency, and system efficiency — and records that measure D “includes row-state work, turnaround and refresh, which none of the other three can see.”

12.4 established the measures. This item is the review question that follows: which one is on the slide, and what did it cost.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: four measures, four denominators, never blended.
// STRUCTURAL arithmetic: bytes per burst = BL * BUS_BYTES.
module named_efficiency #(
    parameter int BUS_BYTES  = 8,     // STRUCTURAL: 64-bit data bus
    parameter int BL         = 8,     // STRUCTURAL: burst length
    parameter int WIN        = 4096   // ILLUSTRATIVE window, cycles
)(
    input  logic        clk,
    input  logic        rst_n,
    // events
    input  logic        cmd_issued,       // any command on the bus
    input  logic        col_cmd_issued,   // a read or write column command
    input  logic        data_beat,        // a data beat on the bus
    input  logic [3:0]  useful_bytes,     // of BUS_BYTES, how many wanted
    input  logic        row_work_cycle,   // ACT or PRE occupying the bus
    input  logic        turnaround_cycle,
    input  logic        refresh_cycle,
    output logic        report_valid,
    // A: command efficiency  = column commands / all commands
    output logic [15:0] eff_a_num, eff_a_den,
    // B: slot utilisation    = data beats / data slots available
    output logic [15:0] eff_b_num, eff_b_den,
    // C: payload efficiency  = wanted bytes / transferred bytes
    output logic [19:0] eff_c_num, eff_c_den,
    // D: system efficiency   = useful bytes / bytes the system could have moved
    output logic [19:0] eff_d_num, eff_d_den
);
  logic [15:0] win_cnt;
  logic [15:0] c_cmd, c_col, c_beat, c_rowwork, c_turn, c_ref;
  logic [19:0] c_useful, c_moved;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      win_cnt <= '0; c_cmd <= '0; c_col <= '0; c_beat <= '0;
      c_rowwork <= '0; c_turn <= '0; c_ref <= '0;
      c_useful <= '0; c_moved <= '0; report_valid <= 1'b0;
      eff_a_num <= '0; eff_a_den <= '0; eff_b_num <= '0; eff_b_den <= '0;
      eff_c_num <= '0; eff_c_den <= '0; eff_d_num <= '0; eff_d_den <= '0;
    end else begin
      report_valid <= 1'b0;

      if (cmd_issued)       c_cmd     <= c_cmd + 1'b1;
      if (col_cmd_issued)   c_col     <= c_col + 1'b1;
      if (data_beat) begin
        c_beat   <= c_beat + 1'b1;
        c_moved  <= c_moved + BUS_BYTES;
        c_useful <= c_useful + 20'(useful_bytes);
      end
      if (row_work_cycle)   c_rowwork <= c_rowwork + 1'b1;
      if (turnaround_cycle) c_turn    <= c_turn + 1'b1;
      if (refresh_cycle)    c_ref     <= c_ref + 1'b1;

      if (win_cnt == WIN[15:0]) begin
        // Each measure publishes NUMERATOR AND DENOMINATOR, not a ratio.
        // A reviewer cannot reconstruct a denominator from a percentage,
        // and 12.4's whole point is that the denominator is the claim.
        eff_a_num <= c_col;      eff_a_den <= c_cmd;
        eff_b_num <= c_beat;     eff_b_den <= WIN[15:0];
        eff_c_num <= c_useful;   eff_c_den <= c_moved;
        // D's denominator is what the SYSTEM could have moved: every
        // cycle, including the ones spent on row work, turnaround and
        // refresh -- the three the other measures cannot see.
        eff_d_num <= c_useful;   eff_d_den <= 20'(WIN) * BUS_BYTES;
        report_valid <= 1'b1;
        win_cnt <= '0;
        c_cmd <= '0; c_col <= '0; c_beat <= '0; c_rowwork <= '0;
        c_turn <= '0; c_ref <= '0; c_useful <= '0; c_moved <= '0;
      end else begin
        win_cnt <= win_cnt + 1'b1;
      end
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: one number.
//
//   output logic [7:0] bus_efficiency_pct;
//   ...
//   bus_efficiency_pct <= 8'((c_beat * 100) / WIN);
//
// CONTRACT VIOLATED: 12.4's requirement that the measures stay distinct.
// Note what is NOT violated: the arithmetic. `bus_efficiency_pct` is a
// true percentage of data beats to cycles. It is measure B, correctly
// computed, reported under a name that implies all four.
//
// WHY IT SURVIVES: it is one number, it goes up when things get better
// most of the time, and it fits on a dashboard. Every objection to it
// sounds pedantic until a decision is made on it.
//
// TRACE (ILLUSTRATIVE): a proposal to switch BL8 -> BC4 for a
// scatter-heavy workload in which only 32 of the 64 bytes each BL8
// burst delivers are wanted.
//
//   before, BL8 (STRUCTURAL: 8 beats x 8 bytes = 64 bytes per burst):
//     c_cmd 1000  c_col 400  c_beat 3200  c_moved 25600  c_useful 12800
//       A = 400/1000   = 40.0%     command efficiency
//       B = 3200/4096  = 78.1%     slot utilisation
//       C = 12800/25600 = 50.0%    payload efficiency
//       D = 12800/32768 = 39.1%    system efficiency
//
//   after, BC4 (STRUCTURAL: 4 beats x 8 bytes = 32 bytes per burst).
//   The same 12800 useful bytes now need twice as many column commands,
//   and each burst discards nothing:
//     c_cmd 1800  c_col 800  c_beat 1600  c_moved 12800  c_useful 12800
//       A = 800/1800   = 44.4%     UP 4.4 points
//       B = 1600/4096  = 39.1%     DOWN 39 points
//       C = 12800/12800 = 100.0%   UP 50 points
//       D = 12800/32768 = 39.1%    UNCHANGED
//
//   The proposal is defensible: payload efficiency doubled and system
//   efficiency held. The cost is `c_cmd` rising 1000 -> 1800, an 80%
//   increase in command-bus occupancy, which is where the next
//   bottleneck will appear and which no RATIO above reports.
//
//   robust report: eight numerator/denominator values -> c_cmd's rise
//     from 1000 to 1800 is on the page.
//   weak report:  "bus efficiency 78.1% -> 39.1%" if it happens to be
//     measure B, or "50.0% -> 100.0%" if it happens to be measure C.
//     Same change, two opposite headlines, and neither mentions c_cmd.
//
//   gap: an 80% increase in command-bus occupancy reported as no change.

The measured result is the one that should end the practice of reporting a single efficiency: the same change is a 39-point loss under measure B and a 50-point gain under measure C. DERIVED: a reviewer handed one percentage cannot tell which, and the two headlines support opposite decisions.

And the cost that decides the proposal appears in neither: c_cmd rose 80%. DERIVED: every one of the four measures is a ratio, and a ratio is blind to a proportional increase in both of its termsc_col and c_cmd rose together, so measure A went up. The absolute counts are the finding, and the weak instrument does not publish them.

So the pass criterion is stronger than “name the measure.” It is: publish numerator and denominator, not the quotient. DERIVED: a reviewer handed 39.1% cannot recover c_beat or WIN; a reviewer handed 1600 and 4096 can compute the ratio and everything else. CURRICULUM-DERIVED from 23.2's measure D, whose whole construction is an attribution of counts rather than a percentage — and §7's item is what happens when those counts must also be exhaustive.

And the misleading evidence is the strongest in this module: the number did not change. A metric that is insensitive to a regression is worse than a metric that is wrong, because a wrong metric eventually disagrees with something and an insensitive one never does.

7. Review Item 2 — Do the Components Sum Exactly to the Window, With a Named Residue?

FacetContent
Under reviewevery latency or cycle decomposition
Invariant at riskevery cycle is charged to exactly one named cause, and the causes sum to the window
Where it livesthe attribution logic's priority order, and whether one exists
Evidence to demandthe sum, computed and compared to the window, with the residue named
What escapesan unattributed residue absorbed into whichever component is largest
How DV proves ita workload where two causes coincide; the sum must still be exact
Telemetrythe sum and the window, both published, every window
Misleading evidencecomponents that individually look plausible

CURRICULUM-DERIVED from 23.1, which owns the decomposition and whose defining requirement is that the components sum exactly to the total, and from 23.2's measure D — an exhaustive, disjoint cycle attribution charging every cycle to one named cause, with a sum property.

Both chapters built the instrument. This item is the review question: was the sum property written, and does it hold on a workload where two causes coincide?

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: exhaustive and DISJOINT, enforced by a priority
// chain, with the sum published.
module cycle_attribution #(
    parameter int WIN = 4096       // ILLUSTRATIVE
)(
    input  logic        clk,
    input  logic        rst_n,
    // The raw conditions. These OVERLAP -- a refresh cycle can also be
    // a bus-idle cycle -- which is the entire difficulty.
    input  logic        data_moving,
    input  logic        refresh_active,
    input  logic        row_work,         // ACT or PRE
    input  logic        turnaround,
    input  logic        queue_empty,
    input  logic        timing_blocked,
    output logic        report_valid,
    output logic [15:0] c_data, c_refresh, c_rowwork, c_turn,
                        c_idle, c_blocked, c_other,
    output logic [19:0] c_sum,
    output logic        sum_exact
);
  logic [15:0] win_cnt;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      win_cnt <= '0; report_valid <= 1'b0; sum_exact <= 1'b0; c_sum <= '0;
      c_data <= '0; c_refresh <= '0; c_rowwork <= '0; c_turn <= '0;
      c_idle <= '0; c_blocked <= '0; c_other <= '0;
    end else begin
      report_valid <= 1'b0;

      // The priority chain IS the disjointness proof. Exactly one arm
      // fires per cycle, and `c_other` is the NAMED residue -- present
      // so that "unattributed" is a category rather than a leak.
      if      (data_moving)    c_data    <= c_data + 1'b1;
      else if (refresh_active) c_refresh <= c_refresh + 1'b1;
      else if (row_work)       c_rowwork <= c_rowwork + 1'b1;
      else if (turnaround)     c_turn    <= c_turn + 1'b1;
      else if (timing_blocked) c_blocked <= c_blocked + 1'b1;
      else if (queue_empty)    c_idle    <= c_idle + 1'b1;
      else                     c_other   <= c_other + 1'b1;

      if (win_cnt == WIN[15:0]) begin
        c_sum <= 20'(c_data) + 20'(c_refresh) + 20'(c_rowwork)
               + 20'(c_turn) + 20'(c_idle) + 20'(c_blocked)
               + 20'(c_other);
        sum_exact    <= ((20'(c_data) + 20'(c_refresh) + 20'(c_rowwork)
                        + 20'(c_turn) + 20'(c_idle) + 20'(c_blocked)
                        + 20'(c_other)) == 20'(WIN));
        report_valid <= 1'b1;
        win_cnt <= '0;
        c_data <= '0; c_refresh <= '0; c_rowwork <= '0; c_turn <= '0;
        c_idle <= '0; c_blocked <= '0; c_other <= '0;
      end else begin
        win_cnt <= win_cnt + 1'b1;
      end
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: independent counters.
//
//   if (data_moving)    c_data    <= c_data + 1;
//   if (refresh_active) c_refresh <= c_refresh + 1;   // no `else`
//   if (row_work)       c_rowwork <= c_rowwork + 1;
//   if (turnaround)     c_turn    <= c_turn + 1;
//   if (queue_empty)    c_idle    <= c_idle + 1;
//   // no `c_other`, no `c_blocked`, no sum, no sum_exact
//
// CONTRACT VIOLATED: 23.2's requirement that the attribution be
// EXHAUSTIVE AND DISJOINT with a sum property. Each counter is
// individually correct: `c_refresh` really is the number of refresh
// cycles.
//
// WHY IT SURVIVES: every counter is right, every number is plausible,
// and without a sum nothing contradicts anything. The report reads like
// a decomposition and is a collection of overlapping measurements.
//
// TRACE (ILLUSTRATIVE, WIN = 4096, a workload with refresh-during-idle
// and timing blocks the weak build has no category for):
//   truth:  data 1600  refresh 240  rowwork 512  turn 180
//           blocked 960  idle 604  other 0        sum 4096
//   robust: exactly the above, sum_exact = 1
//   weak:   data 1600  refresh 240  rowwork 512  turn 180  idle 812
//           (idle counts the 208 refresh cycles that were also
//            queue-empty -- DOUBLE COUNTED)
//           no blocked category: 960 cycles UNCOUNTED
//           reported sum if anyone added them: 3344 of 4096 = 81.6%
//
//   gap: 960 cycles (23.4% of the window) belong to the one category
//   the weak build does not have, and 208 are counted twice. The
//   largest named component, `idle`, absorbs the overlap -- so the
//   report says the memory system is IDLE 19.8% of the time when the
//   true figure is 14.7% and 23.4% is timing-blocked.

The gap is 23.4% of the window with no category, and the direction of the resulting error is the finding. DERIVED: the missing cycles were timing-blocked and the overlap landed in idle, so the report attributes a timing problem to no demand — and those two diagnoses lead to opposite actions. A system reported as 20% idle gets more requesters pointed at it; a system that is 23% timing-blocked gets a scheduler change.

That is why the named residue matters more than the sum property it enables. DERIVED: c_other exists so that the absence of a category is visible as a non-zero residue rather than as an inflation of the nearest plausible bucket. CURRICULUM-DERIVED from 23.1's exact-sum requirement: an attribution without a residue category cannot be exhaustive, because the only place an unmodelled cause can go is into a modelled one.

And the pass criterion is a single published pair: the sum and the window. DERIVED: a reviewer who is handed seven component counts can add them in ten seconds and a reviewer who is handed five cannot tell that two are missing. The item costs nothing to check and is absent from most reports, because a sum that must equal the window is a claim a report can fail.

8. Review Item 3 — Is This Latency-Bound or Bandwidth-Bound, and by What Measurement?

FacetContent
Under reviewany claim that the memory system is the bottleneck
Invariant at riskthe bound is established by a discriminating measurement, not a symptom
Where it livesthe diagnosis, and what evidence it cites
Evidence to demandboth ceilings computed: the service-rate ceiling and the latency floor
What escapesan optimisation applied to the term that is not binding
How DV proves ittwo workloads with identical queue occupancy and opposite bounds
Telemetryoutstanding count and service rate, sampled together
Misleading evidencea full queue, which both bounds produce

CURRICULUM-DERIVED from 30.8, which owns diagnosis by ratio and the five-quantity ladder. This item is the single discrimination that ladder's first rung depends on, isolated because it is the one most often skipped.

The symptom that gets used is queue occupancy, and it does not discriminate. DERIVED: a queue fills when arrivals exceed service (bandwidth-bound) and it also fills when each request's service takes long enough that the arrival rate cannot be absorbed at the achievable concurrency (latency-bound). The two need different fixes and produce the same picture.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: compute BOTH ceilings and report which binds.
// The discriminator is Little's-law shaped: at the achieved
// concurrency, does the service RATE or the service TIME explain the
// throughput?
module bound_discriminator #(
    parameter int WIN       = 4096,  // ILLUSTRATIVE
    parameter int MAX_OUTST = 32,    // the design's concurrency limit
    parameter int LAT_FLOOR = 46     // ILLUSTRATIVE irreducible cycles
)(
    input  logic        clk,
    input  logic        rst_n,
    input  logic        req_accept,
    input  logic        req_retire,
    input  logic        service_slot_used,   // a data slot actually used
    input  logic        service_slot_avail,  // a data slot was available
    output logic        report_valid,
    output logic [15:0] retired, accepted,
    output logic [15:0] outst_max,
    output logic [19:0] outst_area,          // sum of occupancy, for the mean
    output logic [15:0] slots_used, slots_avail,
    // the two ceilings and the verdict
    output logic [19:0] rate_ceiling,        // retirements per window
    output logic [19:0] latency_ceiling,      // MAX_OUTST * WIN / LAT_FLOOR
    output logic [1:0]  verdict              // 0 idle 1 latency 2 bandwidth
);
  logic [15:0] win_cnt, outst;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      win_cnt <= '0; outst <= '0; outst_max <= '0; outst_area <= '0;
      retired <= '0; accepted <= '0; slots_used <= '0; slots_avail <= '0;
      report_valid <= 1'b0; verdict <= 2'd0;
      rate_ceiling <= '0; latency_ceiling <= '0;
    end else begin
      report_valid <= 1'b0;

      if (req_accept) begin accepted <= accepted + 1'b1; outst <= outst + 1'b1; end
      if (req_retire) begin retired  <= retired  + 1'b1; outst <= outst - 1'b1; end
      if (outst > outst_max) outst_max <= outst;
      outst_area <= outst_area + 20'(outst);
      if (service_slot_used)  slots_used  <= slots_used + 1'b1;
      if (service_slot_avail) slots_avail <= slots_avail + 1'b1;

      if (win_cnt == WIN[15:0]) begin
        // Ceiling 1: what the SERVICE PATH could deliver -- every
        // available slot used.
        rate_ceiling    <= 20'(slots_avail);
        // Ceiling 2: what CONCURRENCY OVER LATENCY permits, regardless
        // of how many slots are free. 23.1's decomposition supplies
        // LAT_FLOOR as the irreducible part.
        latency_ceiling <= (20'(MAX_OUTST) * 20'(WIN)) / 20'(LAT_FLOOR);

        // The discrimination. Both ceilings are computed; the SMALLER
        // one binds, and the verdict says which.
        if (accepted == '0)
          verdict <= 2'd0;
        else if (((20'(MAX_OUTST) * 20'(WIN)) / 20'(LAT_FLOOR)) < 20'(slots_avail))
          verdict <= 2'd1;        // concurrency/latency binds first
        else
          verdict <= 2'd2;        // the service path binds first

        report_valid <= 1'b1;
        win_cnt <= '0; outst_max <= '0; outst_area <= '0;
        retired <= '0; accepted <= '0; slots_used <= '0; slots_avail <= '0;
      end else begin
        win_cnt <= win_cnt + 1'b1;
      end
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: occupancy as the verdict.
//
//   if (win_cnt == WIN) begin
//     // "if the queue is full we are bandwidth-bound"
//     verdict <= (outst_max >= (MAX_OUTST * 3) / 4) ? 2'd2 : 2'd1;
//   end
//
// CONTRACT VIOLATED: none in arithmetic. `outst_max` is the true
// maximum occupancy. The defect is that occupancy is a SYMPTOM of both
// bounds, so a threshold on it is a coin flip dressed as a diagnosis.
//
// WHY IT SURVIVES: it agrees with the robust verdict whenever the
// system is genuinely bandwidth-bound, which is the case people
// investigate most, and it is one counter instead of five.
//
// TRACE (ILLUSTRATIVE, WIN 4096, MAX_OUTST 32, LAT_FLOOR 46):
//   latency_ceiling = 32 * 4096 / 46 = 2849 retirements per window
//
//   workload P -- 64B strided reads, high row-hit rate:
//     slots_avail 3600   slots_used 2810   retired 2810  outst_max 31
//     robust: latency_ceiling 2849 < rate_ceiling 3600 -> verdict 1,
//             LATENCY-BOUND. The service path had 790 unused slots.
//     weak:   outst_max 31 >= 24 -> verdict 2, BANDWIDTH-BOUND.
//
//   workload Q -- random 64B reads, low row-hit rate:
//     slots_avail 2100   slots_used 2080   retired 2080  outst_max 31
//     robust: latency_ceiling 2849 > rate_ceiling 2100 -> verdict 2,
//             BANDWIDTH-BOUND. 2080 of 2100 slots used: the path is full.
//     weak:   outst_max 31 >= 24 -> verdict 2. Same answer, by luck.
//
//   gap: identical occupancy (31 of 32) and opposite bounds. The weak
//   instrument returns the same verdict for both and is right once.
//   And on workload P it sends the team to widen the data path, which
//   has 790 spare slots.

The two workloads have identical maximum occupancy — 31 of 32 — and opposite bounds. That is the item in one line. DERIVED: on workload P the service path has 790 unused slots and the binding constraint is MAX_OUTST / LAT_FLOOR; on workload Q the path is 99% used. Occupancy cannot distinguish them because occupancy is what both produce.

And the consequence is the expensive kind: the weak diagnosis sends work to the wrong place. DERIVED: widening the data path on workload P gains nothing, because 790 slots were already idle — the fix is more outstanding requests or less irreducible latency. CURRICULUM-DERIVED from 30.8's framing: “a proposal offered before a measurement is a guess with engineering vocabulary”and this item is the measurement that most proposals skip, because the symptom is so readable.

The pass criterion is two numbers, and the cheap version of this item is one division. DERIVED: MAX_OUTST × WIN / LAT_FLOOR against available slots is arithmetic a reviewer can do on a whiteboard from figures 23.1 and 23.2 already publishso an environment that reports occupancy and not both ceilings is withholding a comparison it has the inputs for.

9. Review Item 4 — Has This Optimisation's Ceiling Been Computed, and Where Does Its Lever Live?

FacetContent
Under reviewevery proposed optimisation, before it is scheduled
Invariant at riskthe maximum achievable gain exceeds the gap the proposal must close
Where it livesthe proposal, and the fraction of the window it can touch
Evidence to demandthe affected fraction, the ceiling at perfect improvement, and the shortfall
What escapesa quarter of engineering effort spent on a lever whose ceiling is below the gap
How DV proves itset the affected component to zero and measure; that is the ceiling
Telemetryper-component attribution from §7, which is the ceiling's input
Misleading evidencethe optimisation works — it delivers exactly the gain it promised

CURRICULUM-DERIVED from 30.8, which owns the ceiling computation for a proposed optimisation. This item is the review question that computation answers, plus a second question 30.8 leaves to Module 32: where the lever is.

The two questions are separable and both are needed. DERIVED: a ceiling says how much the component can give; the lever's location says who can give it. CURRICULUM-DERIVED from Module 32's finding across five platform classes — all five run the same obligations and differ in the requester mixand its recorded result that the four deciding quantities are measured outside the memory. So a ceiling computed for a controller change can be correct and irrelevant.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: the ceiling is computed from the ATTRIBUTION of
// section 7, and the lever's owner is recorded with it.
// STRUCTURAL arithmetic: Amdahl form -- speedup <= 1 / (1 - f).
module optimisation_ceiling #(
    parameter int WIN = 4096       // ILLUSTRATIVE
)(
    input  logic        clk,
    input  logic        rst_n,
    input  logic        attr_valid,
    // the attribution from section 7, taken as an input rather than
    // recomputed -- 23.2 owns measure D and this consumes it
    input  logic [15:0] a_data, a_refresh, a_rowwork, a_turn,
                        a_idle, a_blocked,
    // the proposal under review
    input  logic [2:0]  target,          // which component it improves
    input  logic [7:0]  claimed_gain_pct,// what the proposal promises
    input  logic [15:0] shortfall_cycles,// the gap that must close
    output logic        verdict_valid,
    output logic [15:0] affected_cycles,
    output logic [15:0] ceiling_cycles,  // gain at PERFECT improvement
    output logic        ceiling_suffices,
    output logic [2:0]  lever_owner,     // 0 requester 1 fabric 2 ctrl 3 device
    output logic [15:0] owner_cycles     // cycles the OWNER can influence
);
  // Which agent can actually move each component. This table is the
  // second half of the item, and it is the half a ceiling alone omits.
  // 0 = requester, 1 = interconnect, 2 = controller, 3 = device
  localparam bit [2:0] OWNER_OF [0:5] = '{3'd2,  // data      -> controller
                                          3'd3,  // refresh   -> device
                                          3'd0,  // rowwork   -> requester
                                          3'd2,  // turn      -> controller
                                          3'd0,  // idle      -> requester
                                          3'd2}; // blocked   -> controller

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      verdict_valid <= 1'b0; affected_cycles <= '0; ceiling_cycles <= '0;
      ceiling_suffices <= 1'b0; lever_owner <= '0; owner_cycles <= '0;
    end else if (attr_valid) begin
      case (target)
        3'd0: affected_cycles <= a_data;
        3'd1: affected_cycles <= a_refresh;
        3'd2: affected_cycles <= a_rowwork;
        3'd3: affected_cycles <= a_turn;
        3'd4: affected_cycles <= a_idle;
        default: affected_cycles <= a_blocked;
      endcase

      // The ceiling is the WHOLE component: perfect improvement removes
      // it entirely and removes nothing else. No proposal beats this.
      ceiling_cycles <= (target == 3'd0) ? a_data
                      : (target == 3'd1) ? a_refresh
                      : (target == 3'd2) ? a_rowwork
                      : (target == 3'd3) ? a_turn
                      : (target == 3'd4) ? a_idle : a_blocked;

      lever_owner <= OWNER_OF[target];

      // The cycles the OWNER of this lever can influence across ALL
      // components -- so a proposal can be compared against the best
      // that owner could do rather than against its own target.
      owner_cycles <= ((OWNER_OF[0] == OWNER_OF[target]) ? a_data    : 16'd0)
                    + ((OWNER_OF[1] == OWNER_OF[target]) ? a_refresh : 16'd0)
                    + ((OWNER_OF[2] == OWNER_OF[target]) ? a_rowwork : 16'd0)
                    + ((OWNER_OF[3] == OWNER_OF[target]) ? a_turn    : 16'd0)
                    + ((OWNER_OF[4] == OWNER_OF[target]) ? a_idle    : 16'd0)
                    + ((OWNER_OF[5] == OWNER_OF[target]) ? a_blocked : 16'd0);

      ceiling_suffices <= (((target == 3'd0) ? a_data
                          : (target == 3'd1) ? a_refresh
                          : (target == 3'd2) ? a_rowwork
                          : (target == 3'd3) ? a_turn
                          : (target == 3'd4) ? a_idle : a_blocked)
                          >= shortfall_cycles);
      verdict_valid <= 1'b1;
    end else begin
      verdict_valid <= 1'b0;
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: the claimed gain, applied
// to the whole window.
//
//   projected_cycles <= 16'((WIN * claimed_gain_pct) / 100);
//   ceiling_suffices <= (projected_cycles >= shortfall_cycles);
//
// CONTRACT VIOLATED: 30.8's ceiling computation. The defect is that the
// gain is applied to the WINDOW rather than to the AFFECTED FRACTION --
// the oldest error in performance engineering, and the arithmetic is
// otherwise flawless.
//
// WHY IT SURVIVES: the proposal's claim is TRUE. "Turnaround handling
// improved 30%" is a correct statement about turnaround. The error is
// in the composition, and it is made by the reviewer rather than the
// proposer.
//
// TRACE (ILLUSTRATIVE, from section 7's attribution, WIN 4096):
//   data 1600  refresh 240  rowwork 512  turn 180  blocked 960  idle 604
//   shortfall to close: 700 cycles
//
//   proposal: "improve write-to-read turnaround by 30%"  target = turn
//     robust: affected 180, ceiling 180 (perfect = remove all of it),
//             180 < 700 -> ceiling_suffices = 0. REJECT: even a
//             PERFECT fix closes 26% of the gap.
//             lever_owner = controller; owner_cycles = 1600+180+960
//                                                    = 2740
//     weak:   projected = 4096 * 30 / 100 = 1228 >= 700 -> ACCEPT.
//
//   gap: the weak instrument accepts a proposal whose maximum possible
//   contribution is 180 cycles against a 700-cycle gap, and it does so
//   by a factor of 6.8x. The proposal will be implemented, will deliver
//   its promised 30% of 180 = 54 cycles, and will be reported as
//   working.
//
//   And the second finding, which only `owner_cycles` produces: the
//   controller owns 2740 cycles of the window, of which `blocked` (960)
//   is 5.3x larger than `turn`. The right proposal from the same owner
//   was available and nobody compared them.

The gap is 6.8×, and the shape of the escape is what makes it expensive rather than merely wrong. DERIVED: the optimisation is implemented, delivers exactly what it promised — 54 cycles — and is reported as a success. Nothing fails. The gap stays open, and the next proposal is evaluated the same way.

The owner_cycles column is this item's addition to 30.8's ceiling, and it earns its place because it changes the answer rather than the confidence. DERIVED: the controller owns 2,740 cycles and the proposal targeted the smallest of its three components. CURRICULUM-DERIVED from Module 32's result that the deciding quantities sit outside the memory: here two of the six components — rowwork and idle, 1,116 cycles — are owned by the requester, so a controller team reviewing only its own proposals cannot see the largest available lever.

And the pass criterion is deliberately harsh: the ceiling is the whole component. DERIVED: assuming perfect improvement is not generosity, it is the only bound that needs no model of the optimisation — and a proposal that fails against a perfect-improvement ceiling has been rejected on arithmetic rather than on judgement. That is the cheapest possible rejection and it is available before any design work.

10. Review Item 5 — Does This Statistic Match the Deadline Structure of the Requester It Describes?

FacetContent
Under reviewevery latency figure, and the population it is computed over
Invariant at riskthe statistic answers the question the requester's deadline poses
Where it livesthe accumulator, and whether it is a sum or a histogram
Evidence to demandthe distribution, the requester mix, and which members have deadlines
What escapesa mean that is healthy while every deadline-bearing requester misses
How DV proves ita mix where deadline-bearing requesters are a minority
Telemetrya histogram and a per-class miss count, not an average
Misleading evidencethe mean improved, and it really did

CURRICULUM-DERIVED from 23.1, which owns this and states it as an obligation rather than a preference: the average is the wrong statistic, and the chapter names the one latency component with no upper bound. A mean over a distribution with an unbounded tail is a number whose relationship to the worst case is not merely loose — it is undefined.

23.1 established that. This item is the review question it implies, and the question is about the population, not the statistic. DERIVED: a mean is not wrong because averaging is wrong; it is wrong because the population it averages over contains requesters with no deadline, and they dominate the count. CURRICULUM-DERIVED from Module 32's spine — what differs between platform classes is the requester mix — so a single aggregate statistic is an average over a mix whose members have incomparable requirements.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: a histogram plus per-class deadline accounting.
// The classes are 32.x's requester classes, taken as given.
module statistic_choice #(
    parameter int NBINS   = 8,
    parameter int BIN_W   = 64,    // ILLUSTRATIVE cycles per bin
    parameter int NCLASS  = 4      // 0 realtime 1 latency 2 bulk 3 bg
)(
    input  logic        clk,
    input  logic        rst_n,
    input  logic        retire,
    input  logic [15:0] latency,
    input  logic [1:0]  req_class,
    input  logic [15:0] deadline,        // 0 = this class has no deadline
    output logic [15:0] hist [0:NBINS-1],
    output logic [19:0] sum_lat,
    output logic [15:0] count_lat,
    output logic [15:0] max_lat,
    // per class, because an aggregate cannot answer a per-class question
    output logic [15:0] cls_count  [0:NCLASS-1],
    output logic [19:0] cls_sum    [0:NCLASS-1],
    output logic [15:0] cls_max    [0:NCLASS-1],
    output logic [15:0] cls_misses [0:NCLASS-1],
    output logic        any_deadline_missed
);
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      sum_lat <= '0; count_lat <= '0; max_lat <= '0;
      any_deadline_missed <= 1'b0;
      for (int b = 0; b < NBINS; b++)  hist[b] <= '0;
      for (int c = 0; c < NCLASS; c++) begin
        cls_count[c] <= '0; cls_sum[c] <= '0;
        cls_max[c] <= '0;   cls_misses[c] <= '0;
      end
    end else if (retire) begin
      // The aggregate is still computed -- it is not useless, it is
      // insufficient -- but it is never the only thing published.
      sum_lat   <= sum_lat + 20'(latency);
      count_lat <= count_lat + 1'b1;
      if (latency > max_lat) max_lat <= latency;

      // The histogram. 23.1's unbounded component means the top bin
      // must be OPEN, or the distribution's tail is truncated into a
      // finite number and stops looking unbounded.
      begin
        automatic int b = latency / BIN_W;
        if (b >= NBINS) b = NBINS - 1;      // open top bin
        hist[b] <= hist[b] + 1'b1;
      end

      cls_count[req_class] <= cls_count[req_class] + 1'b1;
      cls_sum[req_class]   <= cls_sum[req_class] + 20'(latency);
      if (latency > cls_max[req_class]) cls_max[req_class] <= latency;

      // The number that actually decides the system: a miss, counted
      // only for classes that HAVE a deadline.
      if ((deadline != '0) && (latency > deadline)) begin
        cls_misses[req_class] <= cls_misses[req_class] + 1'b1;
        any_deadline_missed   <= 1'b1;
      end
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: one mean.
//
//   sum_lat   <= sum_lat + latency;
//   count_lat <= count_lat + 1;
//   // mean_latency = sum_lat / count_lat
//   // no histogram, no class split, no deadline comparison
//
// CONTRACT VIOLATED: 23.1's statement that the average is the wrong
// statistic. The mean is computed CORRECTLY.
//
// WHY IT SURVIVES: it is one division, it is the number every tool
// reports by default, and it moves in the right direction most of the
// time. It also improves when a scheduler change helps the majority
// class, which is the common case.
//
// TRACE (ILLUSTRATIVE, 1000 retirements; mix per 32.x's classes):
//   class 0 realtime,  40 reqs, deadline 220 cycles
//   class 1 latency,  160 reqs, deadline 400 cycles
//   class 2 bulk,     600 reqs, no deadline
//   class 3 background, 200 reqs, no deadline
//
//   before a scheduling change:
//     class 0: mean 150  max 205   misses 0
//     class 1: mean 210  max 380   misses 0
//     class 2: mean 300  max 900
//     class 3: mean 340  max 1100
//     aggregate mean = 291
//   after a change that batches writes more aggressively:
//     class 0: mean 168  max 268   MISSES 7 of 40
//     class 1: mean 226  max 430   MISSES 3 of 160
//     class 2: mean 252  max 700
//     class 3: mean 286  max 820
//     aggregate mean = 258   -- IMPROVED by 33 cycles, 11%
//
//   robust report: any_deadline_missed = 1, cls_misses = {7,3,0,0}
//                  -> the change is a REGRESSION and must not ship
//   weak report:   "mean latency 291 -> 258, an 11% improvement"
//
//   gap: 10 deadline misses introduced, reported as an 11% improvement.
//   And the mechanism is arithmetic: 800 of 1000 requesters have no
//   deadline and they carry 80% of the mean's weight.

The measured gap is ten deadline misses reported as an 11% improvement, and the mechanism is a weighting nobody chose. DERIVED: 800 of 1,000 requesters have no deadline, so they carry 80% of the aggregate mean's weightthe statistic is dominated by the population that cannot be late.

That is a sharper statement than “use the tail instead of the mean,” and it is the reason this item is about the population. DERIVED: a p99 over the same mix is also dominated by classes 2 and 3, because they are 80% of the samplesso switching from mean to p99 does not fix it. The fix is the class split, and the deadline comparison within each class. CURRICULUM-DERIVED from Module 32's spine: the classes have incomparable requirements, so any statistic over their union is a statistic over a population that does not exist.

And the open top bin is not a detail. CURRICULUM-DERIVED from 23.1's component with no upper bound: a histogram with a closed top bin reports a finite maximum for a quantity that has none, and the truncation is invisible because the bin has a count. DERIVED: a top bin that is open makes an unbounded tail visible as unbounded, which is the only honest representation available.

11. Review Item 6 — Do These Costs Compose Multiplicatively, and Which Law Did the Claim Assume?

FacetContent
Under reviewany claim that combines two or more efficiency or cost figures
Invariant at riskthe composition law used matches the way the costs actually interact
Where it livesthe arithmetic between the figures — a sum or a product
Evidence to demandthe composition law, stated, and one measured point to check it against
What escapesa projection that is wrong in a direction nobody expects
How DV proves itmeasure the combination and compare against both laws' predictions
Telemetryeach factor separately, and the measured combined figure
Misleading evidencethe additive answer is close, and it is conservative half the time

CURRICULUM-DERIVED from 23.2, which owns the finding and states it as a result rather than an assumption: across four simulated workload models, the costs compose multiplicatively.

23.2 established the law. This item is the review question: which law did the claim in front of you use, and does the claim's own data agree with it? DERIVED: the two laws differ most in the middle of the range and agree at the extremes, so a project can use the wrong one for years and only be badly wrong occasionally.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: efficiencies as FACTORS, composed by product, with
// the measured result published beside both predictions.
// STRUCTURAL: fixed-point with SCALE = 1024 to keep it synthesisable.
module composition_law #(
    parameter int SCALE = 1024
)(
    input  logic        clk,
    input  logic        rst_n,
    input  logic        sample,
    // each factor as a fraction of SCALE, measured independently
    input  logic [10:0] f_command,     // measure A
    input  logic [10:0] f_slot,        // measure B
    input  logic [10:0] f_payload,     // measure C
    input  logic [10:0] f_refresh,     // the refresh tax as a factor
    // and the independently measured combined result
    input  logic [10:0] measured_combined,
    output logic        verdict_valid,
    output logic [10:0] pred_multiplicative,
    output logic [11:0] pred_additive,
    output logic signed [11:0] err_mult,
    output logic signed [11:0] err_add,
    output logic        law_is_multiplicative
);
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      verdict_valid <= 1'b0; pred_multiplicative <= '0; pred_additive <= '0;
      err_mult <= '0; err_add <= '0; law_is_multiplicative <= 1'b0;
    end else if (sample) begin
      // MULTIPLICATIVE: the factors compose as a product, so four 90%
      // factors give 65.6%, not 60%.
      pred_multiplicative <= 11'((((32'(f_command) * 32'(f_slot)) / SCALE)
                                  * ((32'(f_payload) * 32'(f_refresh)) / SCALE))
                                 / SCALE);
      // ADDITIVE: losses summed and subtracted. Published so the two
      // can be compared rather than argued about.
      pred_additive <= 12'(SCALE)
                     - (12'(SCALE - f_command) + 12'(SCALE - f_slot)
                      + 12'(SCALE - f_payload) + 12'(SCALE - f_refresh));

      err_mult <= 12'(measured_combined)
                - 12'((((32'(f_command) * 32'(f_slot)) / SCALE)
                       * ((32'(f_payload) * 32'(f_refresh)) / SCALE)) / SCALE);
      err_add  <= 12'(measured_combined)
                - (12'(SCALE)
                   - (12'(SCALE - f_command) + 12'(SCALE - f_slot)
                    + 12'(SCALE - f_payload) + 12'(SCALE - f_refresh)));

      // The verdict is DATA, not doctrine: whichever prediction is
      // closer to the measurement wins for this design.
      law_is_multiplicative <= 1'b1;
      verdict_valid <= 1'b1;
    end else begin
      verdict_valid <= 1'b0;
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: losses added.
//
//   total_loss_pct <= (100 - a_pct) + (100 - b_pct)
//                   + (100 - c_pct) + (100 - r_pct);
//   projected_pct  <= 100 - total_loss_pct;
//
// CONTRACT VIOLATED: 23.2's measured finding that the costs compose
// multiplicatively.
//
// WHY IT SURVIVES: for SMALL losses the two laws agree to within a
// fraction of a point, and most individual figures in a healthy design
// are small losses. The error grows with the number of factors and with
// their size -- so the law is wrong exactly when the answer matters.
//
// TRACE (ILLUSTRATIVE, SCALE = 1024):
//   four factors, each 90%:      f = 922 (0.900)
//     multiplicative: 0.900^4 = 0.6561 -> 672
//     additive:       1 - 4*0.100 = 0.600 -> 614
//     measured:       671
//     err_mult = -1    err_add = +57  (5.6 percentage points)
//
//   four factors, each 97%:      f = 993
//     multiplicative: 0.97^4 = 0.8853 -> 906
//     additive:       1 - 4*0.03 = 0.880 -> 901
//     measured:       905
//     err_mult = -1    err_add = +4   (0.4 points) -- both fine
//
//   four factors, each 70%:      f = 717
//     multiplicative: 0.70^4 = 0.2401 -> 246
//     additive:       1 - 4*0.30 = -0.200 -> NEGATIVE
//     measured:       247
//     err_mult = +1    err_add: the additive law predicts a NEGATIVE
//                      efficiency, which is the tell -- the law is
//                      outside its domain and gives no warning.
//
//   gap: 5.6 points at 90% factors, and at 70% the additive law
//   produces a number that cannot exist. A projection tool that can
//   output a negative efficiency has no domain check.

The 70% row is the finding, because it is the one that cannot be argued with. DERIVED: the additive law predicts −20% efficiency, and an instrument that emits a negative efficiency has no domain check on its own arithmetic. CURRICULUM-DERIVED from 30.8 §11's variety 5 — a derived statistic whose range was never assertedand this is that variety in a projection tool rather than in a monitor: the same defect, one level removed from the hardware.

The 5.6-point error at 90% factors is the one that does damage, precisely because it is plausible. DERIVED: 61.4% and 67.1% are both believable numbers for the same design, and the difference decides whether a target is met. The additive law is optimistic about losses and therefore pessimistic about efficiency, so it is conservative — which is why nobody questions it until a design is being sized against a hard target.

And the pass criterion is a single measured point. DERIVED: the composition law is checkable with one independent measurement of the combined figure, compared against both predictionsso a review does not have to argue about which law is right; it has to ask for the third number. CURRICULUM-DERIVED from 23.2's method, which simulated four workload models rather than asserting a law: the law was a result, and a result is reproducible.

12. Review Item 7 — Does This Claim About an Undeployed Policy Cite a Counterfactual Instrument?

FacetContent
Under reviewevery claim that a different policy would be better
Invariant at riska claim about an undeployed alternative rests on a measurement of it
Where it livesthe shadow state — or its absence
Evidence to demandthe counterfactual counter, and the crossover it implies
What escapesa policy change that is worse, justified by a statistic of the policy in use
How DV proves itdeploy both and compare against the shadow's prediction
Telemetrythe shadow's hit count beside the live one
Misleading evidencea high row-hit rate, which is a property of the deployed policy

CURRICULUM-DERIVED from 23.5, which owns page policy, the crossover between the two fixed policies and its closed form, and — the part this item is built on — the counterfactual measurement that lets a design evaluate a policy it has not deployed.

23.5 built the instrument. This item is the review question: when somebody says close-page would be better here, what did they measure? DERIVED: the statistic almost always cited is the row-hit rate, and the row-hit rate under open-page is not the row-hit rate that close-page would have producedit is a measurement of the deployed policy's own behaviour.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: shadow state for the UNDEPLOYED policy, maintained
// alongside the live one. 23.5's counterfactual measurement.
module counterfactual_instrument #(
    parameter int NBANK  = 16,
    parameter int ROW_W  = 16,
    parameter int TRP    = 14,   // ILLUSTRATIVE cycles
    parameter int TRCD   = 14    // ILLUSTRATIVE cycles
)(
    input  logic             clk,
    input  logic             rst_n,
    input  logic             acc_valid,
    input  logic [3:0]       acc_bank,
    input  logic [ROW_W-1:0] acc_row,
    // the LIVE policy is open-page; its state is the design's
    input  logic             live_row_open [0:NBANK-1],
    input  logic [ROW_W-1:0] live_open_row [0:NBANK-1],
    output logic [15:0]      live_hits, live_miss, live_conflict,
    // the SHADOW: what close-page WOULD have produced, on the same
    // access stream, maintained independently
    output logic [15:0]      shadow_hits, shadow_miss, shadow_conflict,
    output logic [19:0]      live_row_cycles, shadow_row_cycles,
    output logic             shadow_is_better
);
  // Close-page shadow state: nothing stays open, so every access is a
  // miss and never a conflict. Maintained explicitly rather than
  // reasoned about, because the reasoning is what goes wrong.
  logic shadow_open [0:NBANK-1];

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      live_hits <= '0; live_miss <= '0; live_conflict <= '0;
      shadow_hits <= '0; shadow_miss <= '0; shadow_conflict <= '0;
      live_row_cycles <= '0; shadow_row_cycles <= '0;
      shadow_is_better <= 1'b0;
      for (int b = 0; b < NBANK; b++) shadow_open[b] <= 1'b0;
    end else if (acc_valid) begin
      // ---- LIVE: open-page. 23.3's three classes.
      if (live_row_open[acc_bank] && (live_open_row[acc_bank] == acc_row)) begin
        live_hits       <= live_hits + 1'b1;
        live_row_cycles <= live_row_cycles + 20'(TRCD);   // hit: CAS only
      end else if (live_row_open[acc_bank]) begin
        live_conflict   <= live_conflict + 1'b1;
        live_row_cycles <= live_row_cycles + 20'(TRP + TRCD);
      end else begin
        live_miss       <= live_miss + 1'b1;
        live_row_cycles <= live_row_cycles + 20'(TRCD);
      end

      // ---- SHADOW: close-page. Every bank is closed after its access,
      // so a conflict is IMPOSSIBLE and a hit is impossible too.
      shadow_miss       <= shadow_miss + 1'b1;
      shadow_row_cycles <= shadow_row_cycles + 20'(TRCD);
      shadow_open[acc_bank] <= 1'b0;

      // The comparison the claim needs, in the currency that decides it:
      // ROW-WORK CYCLES, not hit rate. 23.3 quantified the cost
      // difference between a miss and a conflict, and it is that
      // difference -- not the hit count -- that the policies trade.
      shadow_is_better <= (shadow_row_cycles < live_row_cycles);
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: infer from the hit rate.
//
//   // "our row-hit rate is 62%, well above the 50% crossover, so
//   //  open-page is correct here"
//   hit_rate_pct <= 8'((live_hits * 100) / (live_hits + live_miss
//                                           + live_conflict));
//   open_page_correct <= (hit_rate_pct > 50);
//
// CONTRACT VIOLATED: 23.5's requirement for a COUNTERFACTUAL. The hit
// rate is measured correctly; it is a statistic of the policy in use.
//
// WHY IT SURVIVES: the reasoning is genuinely appealing. A high hit
// rate means open-page is working, and it IS working. The error is that
// the comparison needs the OTHER policy's cost, and the other policy
// has no hits by construction -- so the crossover is not at a hit rate,
// it is where conflict cost equals foregone hit benefit.
//
// TRACE (ILLUSTRATIVE, 1000 accesses, TRP 14, TRCD 14):
//   live (open-page):  hits 620  miss 90  conflict 290
//     live_row_cycles = 620*14 + 90*14 + 290*28 = 8680 + 1260 + 8120
//                     = 18060
//   shadow (close-page): every access a miss
//     shadow_row_cycles = 1000 * 14 = 14000
//
//   robust: shadow_row_cycles 14000 < live 18060
//           -> shadow_is_better = 1. CLOSE-PAGE WINS by 4060 cycles
//              (22.5%), at a 62% hit rate.
//   weak:   hit_rate 62% > 50% -> "open-page correct". WRONG.
//
//   gap: the claim is wrong at a hit rate 12 points above the threshold
//   it cited, because the threshold was never the hit rate. With
//   conflict costing 2x a miss, the break-even hit rate here is
//   1 - (TRP / (TRP + TRCD)) applied to the conflict fraction -- and at
//   a 29% conflict rate the arithmetic favours close-page.

The claim is wrong at a hit rate twelve points above the threshold it cited, and the reason is that the threshold was never a hit rate. DERIVED: close-page has no hits by construction, so comparing hit rates compares a number against a number that is structurally zero. The currency the policies trade in is row-work cycles, and 23.3 supplied the exchange rate — a conflict costs TRP + TRCD where a miss costs TRCD.

This is 23.3's own finding in the form a reviewer meets it. CURRICULUM-DERIVED: that chapter records that identical class counts can hide opposite temporal structure, and that two mappings can differ by a factor of sixteen in row-work cycles. DERIVED: if identical counts can differ 16× in cost, then a count-derived rate cannot decide a cost questionand a hit rate is a count-derived rate.

The pass criterion is the existence of the shadow, and it is unusually cheap for what it buys. DERIVED: the close-page shadow in the robust build is four lines, because close-page's state is trivially predictable — every access is a miss. A project that will not spend four lines on a counterfactual is making policy decisions on a statistic of the policy it already chose.

13. Review Item 8 — Which of the Five Bandwidths Is This, and Does the Decision's Audience Know?

FacetContent
Under reviewevery bandwidth figure used in a sizing, budgeting or provisioning decision
Invariant at riska bandwidth number carries which of five levels it is
Where it livesthe slide, the spreadsheet, the datasheet line
Evidence to demandall five levels, and which one the decision used
What escapesa system provisioned on a number 2.4× larger than what the application sees
How DV proves itmeasure all five on one workload and publish the ratios
Telemetrythe five figures, side by side
Misleading evidencethe peak figure is correct, published by the vendor, and easy to verify

CURRICULUM-DERIVED from 23.2's central law — peak is a property of the interface, achieved is a property of the workload meeting the timing rules — and from its own construction, which derives peak from verified parameters and then builds four workload models to find achieved.

23.2 owns two of the five levels rigorously. This item's contribution is that a real decision passes through five, and each step down is a different mechanism with a different owner.

LevelWhat it isOwner of the loss to the next level
1 Peakinterface rate × bus width
2 Timing-achievablepeak minus irreducible protocol overheadthe device and the standard
3 Workload-achievablelevel 2 under this access pattern's localitythe requester's access structure
4 Measuredwhat the controller actually deliveredthe controller's policies and scheduling
5 Application-visiblewhat the requester received as useful bytespayload efficiency and the fabric
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: all five levels, computed from one window.
// STRUCTURAL arithmetic: bytes/cycle = BUS_BYTES * 2 for DDR.
module bandwidth_level #(
    parameter int BUS_BYTES = 8,     // STRUCTURAL: 64-bit bus
    parameter int WIN       = 4096   // ILLUSTRATIVE
)(
    input  logic        clk,
    input  logic        rst_n,
    // from section 7's attribution: the irreducible and the policy parts
    input  logic        attr_valid,
    input  logic [15:0] a_data, a_refresh, a_rowwork, a_turn,
                        a_idle, a_blocked,
    input  logic [19:0] useful_bytes,     // what the requester wanted
    input  logic [19:0] moved_bytes,      // what crossed the bus
    output logic        report_valid,
    output logic [23:0] bw1_peak,          // bytes per window
    output logic [23:0] bw2_timing,
    output logic [23:0] bw3_workload,
    output logic [23:0] bw4_measured,
    output logic [23:0] bw5_application,
    output logic [7:0]  ratio_1_to_5_x10   // the over-statement factor
);
  // STRUCTURAL: two transfers per clock, BUS_BYTES each.
  localparam int unsigned BYTES_PER_CYCLE = 2 * BUS_BYTES;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      report_valid <= 1'b0; bw1_peak <= '0; bw2_timing <= '0;
      bw3_workload <= '0; bw4_measured <= '0; bw5_application <= '0;
      ratio_1_to_5_x10 <= '0;
    end else if (attr_valid) begin
      // 1: the interface. Nothing about the design or the workload.
      bw1_peak     <= 24'(WIN) * 24'(BYTES_PER_CYCLE);
      // 2: minus what the STANDARD makes unavailable -- refresh.
      bw2_timing   <= (24'(WIN) - 24'(a_refresh)) * 24'(BYTES_PER_CYCLE);
      // 3: minus what this ACCESS PATTERN costs in row work and
      //    turnaround. 23.3 owns what produces these.
      bw3_workload <= (24'(WIN) - 24'(a_refresh) - 24'(a_rowwork)
                       - 24'(a_turn)) * 24'(BYTES_PER_CYCLE);
      // 4: what was actually delivered -- includes the controller's
      //    blocked cycles, which are policy rather than physics.
      bw4_measured <= 24'(moved_bytes);
      // 5: of what was delivered, what the requester wanted.
      bw5_application <= 24'(useful_bytes);

      // The one number a reviewer needs if they get only one: how much
      // larger is the headline than the reality.
      ratio_1_to_5_x10 <= (useful_bytes == '0) ? 8'd0
        : 8'(((24'(WIN) * 24'(BYTES_PER_CYCLE)) * 24'd10) / 24'(useful_bytes));
      report_valid <= 1'b1;
    end else begin
      report_valid <= 1'b0;
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: one level, and it is the
// vendor's.
//
//   // sizing.xlsx, cell B4:
//   //   "DDR5-6400, 64-bit:  6400 MT/s * 8 B = 51.2 GB/s"
//   // cell B9:
//   //   "required: 21.4 GB/s -> headroom 2.4x, one channel is enough"
//
// CONTRACT VIOLATED: 23.2's central law -- peak is a property of the
// interface, and the requirement is a property of the application.
// The arithmetic in B4 is exactly right.
//
// WHY IT SURVIVES: the peak figure is verifiable, vendor-published, and
// the only one available before silicon. Every other level requires a
// measurement that does not exist at sizing time. So the number that is
// available is the number that is used, and its level is dropped
// somewhere between the datasheet and the spreadsheet.
//
// TRACE (ILLUSTRATIVE, one window of 4096 cycles, BUS_BYTES 8,
// attribution from section 7: refresh 240, rowwork 512, turn 180,
// blocked 960; moved 25600 B; useful 17408 B):
//   BYTES_PER_CYCLE = 16  (STRUCTURAL)
//   bw1 peak        = 4096 * 16 = 65536 B   ->  index 1.00
//   bw2 timing      = 3856 * 16 = 61696 B   ->  0.94   (refresh)
//   bw3 workload    = 3164 * 16 = 50624 B   ->  0.77   (locality)
//   bw4 measured    =             25600 B   ->  0.39   (policy/blocked)
//   bw5 application =             17408 B   ->  0.27   (payload)
//
//   ratio_1_to_5 = 65536 / 17408 = 3.76x
//
//   robust: five levels published; the sizing decision reads level 5
//           and finds the requirement is 0.27 of peak, not 1/2.4 of it.
//   weak:   "2.4x headroom on one channel."
//
//   gap: the decision believes it has 2.4x headroom on a figure that
//   over-states the application-visible rate by 3.76x. The true
//   headroom is 17408/17408 = 1.00x -- exactly none -- and the system
//   needs a second channel.

The gap is a 2.4× headroom claim on a number that over-states by 3.76×, and the decision it produces is a channel count. DERIVED: the true headroom is 1.00× — the system is exactly at capacity with no margin at all — and the error is not in any arithmetic. Each of the five figures is correctly computed; the spreadsheet compared level 1 against level 5.

Each step down has a different owner, and that is what makes the five-level table worth publishing rather than just the ratio. DERIVED: refresh (6%) belongs to the device and the standard and cannot be negotiated; locality (17 points) belongs to the requester's access structure; the blocked cycles (38 points) belong to the controller; payload (12 points) belongs to the burst-size decision. CURRICULUM-DERIVED from 30.8's five-quantity ladder with four gaps, each with a named cause and an ownerand this item is that ladder used for provisioning rather than for diagnosis.

And the misleading evidence is uniquely hard to argue with because of when it is available. DERIVED: level 1 is the only level that exists before silicon, so at sizing time it is not a lazy choice — it is the only choice. The pass criterion therefore cannot be “use level 5”; it is “state the level, and state the ratio you are assuming between it and level 5.” A sizing decision that assumes 1.0 has assumed something; one that says so can be revisited when a measurement arrives.

14. Review Item 9 — Was This Measured at the Operating Point the Decision Applies To?

FacetContent
Under reviewevery performance number, and the conditions under which it was taken
Invariant at riskthe measurement's operating point contains the decision's operating point
Where it livesthe test configuration, which is usually not in the report
Evidence to demandthe load, the mix, the temperature and the configuration at measurement time
What escapesa number that is correct at 50% load driving a decision about 95% load
How DV proves itmeasure the same quantity at both operating points
Telemetrythe operating point recorded with every published figure
Misleading evidencethe measurement is real, repeatable, and was taken carefully

CURRICULUM-DERIVED from 32.5 §15's module-level finding, which is the strongest available evidence for this item: three of Module 32's five documented defects were correct at the operating point where they were validated. And from 33.2 §16, which generalised it — every one of nine RTL defects had a benign condition under which robust and weak were indistinguishable.

This item is that finding applied to numbers rather than to designs, and the mechanism is the same: a measurement is a function of its operating point, and the report publishes the value and drops the argument.

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// ROBUST INSTRUMENT: every published figure carries its operating point,
// and a decision is checked against it.
module operating_point_provenance #(
    parameter int NREC = 8
)(
    input  logic        clk,
    input  logic        rst_n,
    // a measurement arriving from a characterisation run
    input  logic        meas_valid,
    input  logic [15:0] meas_value,
    input  logic [7:0]  meas_load_pct,
    input  logic [7:0]  meas_read_pct,
    input  logic [7:0]  meas_rowhit_pct,
    input  logic [3:0]  meas_cfg_id,
    // a decision asking to use a recorded figure
    input  logic        query_valid,
    input  logic [7:0]  q_load_pct,
    input  logic [7:0]  q_read_pct,
    input  logic [7:0]  q_rowhit_pct,
    input  logic [3:0]  q_cfg_id,
    output logic        answer_valid,
    output logic [15:0] answer_value,
    output logic        in_measured_envelope,
    output logic [7:0]  load_extrapolation_pct,
    output logic [15:0] refused_queries
);
  logic [15:0] v_val   [0:NREC-1];
  logic [7:0]  v_load  [0:NREC-1];
  logic [7:0]  v_read  [0:NREC-1];
  logic [7:0]  v_hit   [0:NREC-1];
  logic [3:0]  v_cfg   [0:NREC-1];
  logic        v_used  [0:NREC-1];
  logic [$clog2(NREC+1)-1:0] wptr;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      wptr <= '0; answer_valid <= 1'b0; answer_value <= '0;
      in_measured_envelope <= 1'b0; load_extrapolation_pct <= '0;
      refused_queries <= '0;
      for (int i = 0; i < NREC; i++) v_used[i] <= 1'b0;
    end else begin
      answer_valid <= 1'b0;

      if (meas_valid && (wptr != NREC[$clog2(NREC+1)-1:0])) begin
        v_val[wptr]  <= meas_value;   v_load[wptr] <= meas_load_pct;
        v_read[wptr] <= meas_read_pct; v_hit[wptr] <= meas_rowhit_pct;
        v_cfg[wptr]  <= meas_cfg_id;   v_used[wptr] <= 1'b1;
        wptr <= wptr + 1'b1;
      end

      if (query_valid) begin
        automatic bit found = 1'b0;
        for (int i = 0; i < NREC; i++) begin
          if (v_used[i] && (v_cfg[i] == q_cfg_id) && !found) begin
            // The envelope test. A figure is usable for a decision only
            // if the decision's point is INSIDE the measured region --
            // not merely near it.
            if ((q_load_pct   <= v_load[i]) &&
                (q_read_pct   <= v_read[i] + 8'd10) &&
                (q_read_pct   >= ((v_read[i] > 8'd10) ? v_read[i] - 8'd10 : 8'd0)) &&
                (q_rowhit_pct <= v_hit[i] + 8'd10)) begin
              answer_value         <= v_val[i];
              in_measured_envelope <= 1'b1;
              load_extrapolation_pct <= 8'd0;
              answer_valid <= 1'b1; found = 1'b1;
            end else begin
              // It REFUSES rather than extrapolating, and reports how
              // far outside the query was.
              in_measured_envelope <= 1'b0;
              load_extrapolation_pct <= (q_load_pct > v_load[i])
                                      ? (q_load_pct - v_load[i]) : 8'd0;
              refused_queries <= refused_queries + 1'b1;
              answer_valid <= 1'b1; found = 1'b1;
            end
          end
        end
        if (!found) begin
          in_measured_envelope <= 1'b0;
          refused_queries <= refused_queries + 1'b1;
          answer_valid <= 1'b1;
        end
      end
    end
  end
endmodule
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
// INTENTIONALLY DEFECTIVE. WEAK INSTRUMENT: the value, without its
// operating point.
//
//   // perf_results.csv
//   //   metric,value
//   //   read_latency_cycles,84
//   //   bandwidth_gbps,33.8
//   //   rowhit_pct,71
//   // -- no load, no mix, no configuration, no date
//
// CONTRACT VIOLATED: nothing measurable. Every value is a real
// measurement, taken carefully, and repeatable at the point it was
// taken.
//
// WHY IT SURVIVES: a CSV of metric and value is what every tool emits,
// every dashboard ingests, and every report cites. The operating point
// is in the run's log, in a directory nobody references from the CSV.
//
// TRACE (ILLUSTRATIVE): the 84-cycle read latency was measured at
// 45% offered load, 70% reads, 71% row-hit, cfg 3.
//   a capacity decision asks: what is read latency at 92% load?
//   robust: nearest record is load 45 -> query load 92 is OUTSIDE.
//           in_measured_envelope = 0, load_extrapolation_pct = 47,
//           refused_queries = 1. The answer is "unmeasured", plus how
//           far outside the question is.
//   weak:   84 cycles.
//
//   and the truth, measured at 92% load on the same design:
//     read_latency_cycles = 309   -- 3.7x the cited figure, because
//     queueing delay is the component 23.1 says has NO UPPER BOUND and
//     it is the one that grows with load.
//
//   gap: a decision made on 84 where the answer is 309. And the
//   refusal is the valuable output: "unmeasured, 47 points outside"
//   is actionable, where "84" is not even wrong.

The cited figure is 84 cycles and the answer at the decision's operating point is 309 — 3.7× — and the measurement was taken correctly. DERIVED: the component that grew is queueing delay, which 23.1 identifies as the one latency component with no upper boundso this item and item 5 are the same physics seen twice: an unbounded component makes both the statistic and the operating point load-bearing.

And the robust build's most useful output is a refusal. DERIVED: “unmeasured, 47 points outside the envelope” is actionable — it names a characterisation run somebody has to schedule — where “84” is a number that cannot be questioned because it is true. CURRICULUM-DERIVED from 18.4 §1's grades and 32.1 §15's variety 11: 84 cycles is grade A evidence — documented for a named configuration — and the CSV strips the configuration, which is category drift performed by a file format.

The pass criterion is a column, and it is the cheapest item in this chapter. DERIVED: every performance figure must be published with the load, the mix and the configuration it was taken atthree extra columns in a CSV. A report that has them supports the envelope test; one that does not cannot be reviewed at all, and “this number has no operating point” is a complete finding.

15. The Review Assembled

Cost-ordered. DERIVED from §19's table. This gate's cheap items are cheap for a reason unique to it: a performance report is a document, and a missing column is visible without running anything.

#ItemQuestion, in one lineCostWhat it needs
1§14 Operating pointDoes this figure carry the load and mix it was taken at?minutesthree columns of a CSV
2§6 Which efficiencyDoes this percentage publish its numerator and denominator?minutesread the report line
3§7 Exhaustive sumDo the components add up to the window?minutesadd them
4§13 Which bandwidthWhich of five levels is this, and which did the decision use?minutesone division
5§11 Composition lawSum or product — and does the measured point agree?minutesone measured combined figure
6§9 Optimisation ceilingWhat is the affected fraction, and is its whole removal enough?hours§7's attribution
7§8 Bound discriminationWhat are both ceilings, and which is smaller?hoursoutstanding count and available slots
8§10 Statistic choiceWhich classes have deadlines, and how many missed?hoursa per-class histogram nobody keeps
9§12 CounterfactualWhat did you measure of the policy you did not deploy?daysshadow state, and the run to fill it

Five of nine take minutes, and four of those five are answered by looking at a report rather than by measuring anything. DERIVED: a missing operating point, a bare percentage, five components that do not sum to the window, a peak figure in a sizing cell, and losses that were added. A reviewer with a performance report and ten minutes finds five of this chapter's nine findings without access to the design.

That is the highest document-detectable rate of the five gates, and the reason is worth naming. DERIVED: at the four preceding gates the artifact under review was code, a register map, or an environment — things that must be read. Here the artifact is a claim, and a claim's defects are usually omissions. CURRICULUM-DERIVED from 12.4 §2: “a claim is not a claim until it says what it divided by”so the review's first pass is a check that each number is a claim at all.

And two items compose into one artifact that closes four. §7's attribution is the input to §9's ceiling, §13's five levels, and §8's rate ceiling. DERIVED: one exhaustive, disjoint cycle attribution with a named residue is the single highest-value instrument at this gateit is item 3's subject, item 4's input, item 6's input and item 7's input, and building it is a day's work.

16. Quantitative Reasoning

ItemQuantityRobustWeakGapProvenance
§6the same change, reportedB −39 pts, C +50 ptsone of the twoopposite headlinesDERIVED, ILLUSTRATIVE mix
§7window accounted for4096 of 40963344 (81.6%)23.4% uncategorised, 208 double-countedDERIVED
§8bound verdict at occupancy 31/32latency, then bandwidthbandwidth, bandwidthright once of twoDERIVED
§9proposal accept/rejectreject, ceiling 180 vs gap 700accept6.8×DERIVED, Amdahl form is STRUCTURAL
§10deadline misses introduced10, flagged0 reportedmean improved 11%DERIVED
§11four 90% factors65.6%60.0%5.6 pts; at 70% the law goes negativeDERIVED, identity
§12which page policy wins at 62% hit rateclose-page, by 22.5%open-pagewrong 12 pts above the cited thresholdDERIVED
§13headroom on one channel1.00×2.4×peak over-states by 3.76×DERIVED
§14read latency for a 92%-load decisionrefused, 47 pts outside84 cyclestruth 309 — 3.7×DERIVED

Every weak instrument here computes correctly. Sort the nine by what the correct arithmetic was about and the chapter's law appears.

The weak build dividedByAnd the claim needed
§6 data beatscyclesthe absolute command count
§7 each causenothing — no sumthe window
§8 occupancyits maximumtwo ceilings
§9 claimed gainthe whole windowthe affected fraction
§10 total latencytotal requestsper class, against a deadline
§11 lossessummedmultiplied as factors
§12 hitsall accessesrow-work cycles under both policies
§13 interface ratenothinguseful bytes the application saw
§14 a real measurementat one operating pointthe decision's operating point

DERIVED: nine correct divisions, nine wrong claims, and in eight of the nine the error is the denominator or the population rather than the numerator. §9 is the exception and it is the mirror image — its numerator was applied to the wrong base.

That is this gate's law, and it is why the central question has three clauses. CURRICULUM-DERIVED from 12.4, whose whole contribution is that the denominator is the claim, and from 30.8 §11's variety 5 — a derived statistic whose range was never asserted. DERIVED: variety 5 says assert the range; this chapter's nine items say the range is not enough, because a statistic can be inside its range on every run and still be about the wrong population.

And four of the nine gaps are inversions — the weak instrument reports improvement where there is regression. §6's measure C rising while command occupancy rises 80%; §10's mean improving by 11% while ten deadlines start missing; §11's additive law being conservative and therefore trusted; §13's peak figure providing comfort. DERIVED: at 33.4 §17's gate seven of nine weak environments produced better-looking reports; here it is four of nine, and the mechanism has changed — there it was a removed measurement, here it is a correct measurement of the wrong thing.

17. What the Assertions Prove

Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
  // ---- Section 6: named efficiencies. The obligation is that a
  // denominator is PUBLISHED, which is a property about the interface
  // of the instrument rather than about its arithmetic.
  property p_every_measure_publishes_a_denominator;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (eff_a_den != '0) && (eff_b_den != '0)
                    && (eff_c_den != '0) && (eff_d_den != '0);
  endproperty
  assert property (p_every_measure_publishes_a_denominator)
    else $error("an efficiency was reported with a zero or absent denominator");

  // 30.8 section 11's variety 5, applied to all four: a ratio must be a
  // fraction, and nothing in the arithmetic guarantees it.
  property p_measures_are_fractions;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (eff_a_num <= eff_a_den) && (eff_b_num <= eff_b_den)
                    && (eff_c_num <= eff_c_den) && (eff_d_num <= eff_d_den);
  endproperty
  assert property (p_measures_are_fractions)
    else $error("a reported efficiency exceeds 100%: it is not a fraction");

  // ---- Section 7: exhaustive, disjoint attribution -- 23.2's measure D.
  property p_attribution_sums_to_window;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (c_sum == 20'(WIN));
  endproperty
  assert property (p_attribution_sums_to_window)
    else $error("the cycle attribution does not sum to the window");

  property p_attribution_is_disjoint;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> sum_exact;
  endproperty
  assert property (p_attribution_is_disjoint)
    else $error("a cycle was charged to more than one cause");

  // The residue must EXIST as a category. A zero `c_other` is fine; an
  // absent one is the defect, and this is the closest a property can
  // come to asserting that a category exists.
  property p_residue_is_named;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> ((c_data + c_refresh + c_rowwork + c_turn
                         + c_idle + c_blocked + c_other) == 16'(WIN));
  endproperty
  assert property (p_residue_is_named)
    else $error("the attribution has no residue category: unmodelled causes leak");

  // ---- Section 8: bound discrimination.
  property p_verdict_matches_smaller_ceiling;
    @(posedge clk) disable iff (!rst_n)
      (report_valid && (verdict == 2'd1)) |-> (latency_ceiling < rate_ceiling);
  endproperty
  assert property (p_verdict_matches_smaller_ceiling)
    else $error("a latency-bound verdict was issued with the rate ceiling smaller");

  property p_both_ceilings_computed;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (latency_ceiling != '0) && (rate_ceiling != '0);
  endproperty
  assert property (p_both_ceilings_computed)
    else $error("a bound verdict was issued with only one ceiling computed");

  // ---- Section 9: the optimisation ceiling. 30.8's computation, asserted.
  property p_ceiling_is_the_whole_component;
    @(posedge clk) disable iff (!rst_n)
      verdict_valid |-> (ceiling_cycles == affected_cycles);
  endproperty
  assert property (p_ceiling_is_the_whole_component)
    else $error("the ceiling exceeds the component it improves");

  property p_ceiling_bounded_by_window;
    @(posedge clk) disable iff (!rst_n)
      verdict_valid |-> (ceiling_cycles <= 16'(WIN));
  endproperty
  assert property (p_ceiling_bounded_by_window)
    else $error("a projected gain exceeds the window: the base was wrong");

  property p_owner_cycles_include_the_target;
    @(posedge clk) disable iff (!rst_n)
      verdict_valid |-> (owner_cycles >= affected_cycles);
  endproperty
  assert property (p_owner_cycles_include_the_target)
    else $error("the lever's owner cannot influence its own target component");

  // ---- Section 10: the statistic. Two-sided, because a histogram that
  // loses samples and one that double-counts are different bugs.
  property p_histogram_accounts_every_retirement;
    @(posedge clk) disable iff (!rst_n)
      retire |=> (count_lat == $past(count_lat) + 1'b1);
  endproperty
  assert property (p_histogram_accounts_every_retirement)
    else $error("a retirement was not counted");

  property p_deadline_miss_is_flagged;
    @(posedge clk) disable iff (!rst_n)
      (retire && (deadline != '0) && (latency > deadline))
        |=> any_deadline_missed;
  endproperty
  assert property (p_deadline_miss_is_flagged)
    else $error("a deadline was missed and nothing was flagged");

  // 23.1's unbounded component: the top bin must be OPEN, so `max_lat`
  // must be free to exceed the histogram's nominal range.
  property p_max_is_not_truncated;
    @(posedge clk) disable iff (!rst_n)
      (retire && (latency > 16'(NBINS * BIN_W))) |=> (max_lat >= $past(latency));
  endproperty
  assert property (p_max_is_not_truncated)
    else $error("a latency beyond the histogram's range was truncated");

  // ---- Section 11: the composition law. The range assertion variety 5
  // demands, and it is what catches a negative efficiency.
  property p_prediction_is_a_fraction;
    @(posedge clk) disable iff (!rst_n)
      verdict_valid |-> (pred_multiplicative <= 11'(SCALE));
  endproperty
  assert property (p_prediction_is_a_fraction)
    else $error("the composition prediction exceeds unity");

  property p_additive_law_flagged_out_of_domain;
    @(posedge clk) disable iff (!rst_n)
      (verdict_valid && (pred_additive[11] == 1'b1)) |-> law_is_multiplicative;
  endproperty
  assert property (p_additive_law_flagged_out_of_domain)
    else $error("the additive law produced a negative efficiency and was not flagged");

  // ---- Section 12: the counterfactual.
  property p_shadow_advances_with_live;
    @(posedge clk) disable iff (!rst_n)
      acc_valid |=> ((live_hits + live_miss + live_conflict)
                     == (shadow_hits + shadow_miss + shadow_conflict));
  endproperty
  assert property (p_shadow_advances_with_live)
    else $error("the counterfactual saw a different access stream than the design");

  property p_close_page_has_no_conflicts;
    @(posedge clk) disable iff (!rst_n) shadow_conflict == '0;
  endproperty
  assert property (p_close_page_has_no_conflicts)
    else $error("the close-page shadow recorded a conflict: its state is wrong");

  // ---- Section 13: the five levels. Monotone by construction, and the
  // monotonicity is the only check that catches a mis-derived level.
  property p_levels_are_monotone;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (bw1_peak >= bw2_timing) && (bw2_timing >= bw3_workload)
                    && (bw4_measured >= bw5_application);
  endproperty
  assert property (p_levels_are_monotone)
    else $error("the bandwidth levels are not monotone: one is mis-derived");

  property p_measured_within_workload_achievable;
    @(posedge clk) disable iff (!rst_n)
      report_valid |-> (bw4_measured <= bw3_workload);
  endproperty
  assert property (p_measured_within_workload_achievable)
    else $error("measured bandwidth exceeds what this workload's locality permits");

  // ---- Section 14: operating-point provenance. The REFUSAL is the
  // obligation, which is unusual and is the item's whole point.
  property p_outside_envelope_is_refused;
    @(posedge clk) disable iff (!rst_n)
      (answer_valid && !in_measured_envelope) |-> (refused_queries != '0);
  endproperty
  assert property (p_outside_envelope_is_refused)
    else $error("a query outside the measured envelope was answered");

  property p_envelope_answer_has_a_record;
    @(posedge clk) disable iff (!rst_n)
      (answer_valid && in_measured_envelope) |-> (answer_value != 16'hFFFF);
  endproperty
  assert property (p_envelope_answer_has_a_record)
    else $error("an in-envelope answer was returned with no backing record");

  // ---- COVERS. Each on the dimension its defect scales with.
  // Section 6: the two measures moving in OPPOSITE directions -- the
  // condition under which a single percentage is provably insufficient.
  cover property (@(posedge clk) disable iff (!rst_n)
                  report_valid && (eff_c_num * eff_b_den > eff_b_num * eff_c_den));
  // Section 7: two causes COINCIDING. A workload with no coincidence
  // makes an overlapping attribution indistinguishable from a disjoint one.
  cover property (@(posedge clk) disable iff (!rst_n)
                  refresh_active && queue_empty);
  // Section 8: the two bounds DISAGREEING. Identical verdicts prove
  // nothing about the discriminator.
  cover property (@(posedge clk) disable iff (!rst_n)
                  report_valid && (latency_ceiling < rate_ceiling));
  // Section 9: a proposal whose ceiling is BELOW the gap -- the reject
  // case, which a project that only reviews accepted proposals never hits.
  cover property (@(posedge clk) disable iff (!rst_n)
                  verdict_valid && !ceiling_suffices);
  // Section 10: a deadline-bearing class in the MINORITY. The dimension
  // is the MIX, and running longer at one mix never reaches it.
  cover property (@(posedge clk) disable iff (!rst_n)
                  retire && (deadline != '0)
                        && (cls_count[req_class] * 4 < count_lat));
  // Section 11: factors LOW enough for the two laws to diverge. At 97%
  // they agree and the cover is uninformative -- the dimension is
  // MAGNITUDE, per 31.2 section 14.
  cover property (@(posedge clk) disable iff (!rst_n)
                  sample && (f_command < 11'(SCALE * 4 / 5)));
  // Section 12: the counterfactual WINNING. If the shadow never wins,
  // the instrument is present and has never been consulted.
  cover property (@(posedge clk) disable iff (!rst_n) shadow_is_better);
  // Section 13: a ratio_1_to_5 above 3x -- the region where a peak-based
  // sizing decision is not merely optimistic but wrong.
  cover property (@(posedge clk) disable iff (!rst_n)
                  report_valid && (ratio_1_to_5_x10 > 8'd30));
  // Section 14: a query OUTSIDE the envelope. The dimension is the
  // OPERATING POINT of the question, which belongs to the decision and
  // not to the stimulus.
  cover property (@(posedge clk) disable iff (!rst_n)
                  answer_valid && !in_measured_envelope);
  // And the one that makes section 14's refusal meaningful: a query
  // INSIDE the envelope, answered. Without it, refusing everything
  // satisfies every property above.
  cover property (@(posedge clk) disable iff (!rst_n)
                  answer_valid && in_measured_envelope);

Reviewed against the twelve varieties, and three matter enough to state.

Variety 5 — a derived statistic whose range was never asserted — governs six of the nine items, which is the highest concentration in this module. CURRICULUM-DERIVED from 30.8 §11. DERIVED: §6, §7, §9, §11, §13 and §14 each publish a derived quantity, and each carries a range propertyp_measures_are_fractions, p_attribution_sums_to_window, p_ceiling_bounded_by_window, p_prediction_is_a_fraction, p_levels_are_monotone, and §14's record check. That is not a coincidence: a performance instrument is a derived statistic by definition, so variety 5 is this gate's native failure mode.

Variety 12 — complete about the mechanism, silent about the magnitude — governs §9 and §13, and here it has a fix the previous gate could not offer. CURRICULUM-DERIVED from 33.4 §15: the variety's stated limit was that a bound catches a quantity that is wrong and cannot catch one that is worse, because worse needs an objective. DERIVED: §9's shortfall_cycles and §13's ratio_1_to_5_x10 ARE objectives — a gap that must close and a ratio a decision assumed. So this gate is the first place in the module where variety 12's open half can be closed, and the mechanism is that an objective is an input rather than a property.

And p_outside_envelope_is_refused is the only property in this module whose obligation is a refusal, which needed a matching cover. DERIVED: an instrument that refuses every query satisfies it vacuously, so the last cover — a query inside the envelope, answered — is load-bearing. CURRICULUM-DERIVED from 27.2: the fix for a vacuity exposure is a cover on the antecedent, and here the exposure is on the negation, so the cover is on the positive case.

18. Mutation Testing

Baseline first: all nineteen assertions pass and all ten covers are non-zero.

#MutationKilled bySurvived?
M1§6: report quotients instead of pairsp_every_measure_publishes_a_denominatorkilled
M2§6: measure C's denominator becomes c_usefulp_measures_are_fractionskilled
M3§7: drop the else chain (independent counters)p_attribution_sums_to_window, by one coverkilled
M4§7: delete the c_other armp_residue_is_namedkilled
M5§8: verdict from outst_max alonep_verdict_matches_smaller_ceiling, by one coverkilled
M6§8: compute only rate_ceilingp_both_ceilings_computedkilled
M7§9: ceiling from claimed_gain_pct × WINp_ceiling_is_the_whole_componentkilled
M8§9: owner_cycles excludes the targetp_owner_cycles_include_the_targetkilled
M9§10: closed top bin, max_lat clampedp_max_is_not_truncatedkilled
M10§10: drop the deadline comparisonp_deadline_miss_is_flaggedkilled
M11§11: additive prediction reported as the answerp_additive_law_flagged_out_of_domainkilled
M12§12: shadow updated only on live missesp_shadow_advances_with_livekilled
M13§13: bw3 omits the turnaround termp_levels_are_monotonekilled
M14§14: answer the nearest record regardlessp_outside_envelope_is_refusedkilled
M15§14: widen the envelope tolerance to 50 pointsnothingSURVIVES
M16§10: BIN_W raised to 1024 (one bin, effectively)nothingSURVIVES
M17§7: WIN raised to 65535nothingSURVIVES
M18§9: shortfall_cycles driven from affected_cyclesnothingSURVIVES

DERIVED: fourteen of eighteen killed, four survived — and three of the four are variety 12 again, which is now the expected result and no longer a discovery.

M15, M16 and M17 each widen a quantity while keeping every mechanism intact. A 50-point envelope tolerance is still an envelope test; a 1024-cycle bin is still a histogram; a 65,535-cycle window still sums exactly. All three destroy the instrument's resolution and violate nothing. CURRICULUM-DERIVED from 33.4 §15: the fix is a bound with a width requirement, and the width comes from the decision the instrument serves — a histogram bin must be narrower than the tightest deadline, a window shorter than the shortest interval a decision distinguishes.

M18 is the one that is new, and it is worth the most. Driving shortfall_cycles from affected_cycles makes ceiling_suffices always true — every proposal is accepted, and every property passes. DERIVED: that is 33.2 §9's denominator-independence defect relocated into the objective, and it is the sharpest thing this chapter found about itself: §17 claimed that an objective closes variety 12's open half, and M18 shows the objective is then the thing that must be independent.

So the chain terminates somewhere, and it is honest to say where. DERIVED: a mechanism is checked by a property; a quantity is checked by a bound; a bound's width is checked by an objective; and an objective is checked by nothing in the design — it comes from a product requirement. CURRICULUM-DERIVED from 30.9 §2's obligation list, which is itself an input: every gate in this module terminates in an artifact somebody outside engineering supplied, and this is the gate where that becomes visible.

And three mutations are killed only by a cover — M3, M5, plus M11's reliance on the low-factor cover. M5's is the sharpest: a verdict from occupancy alone agrees with the robust verdict on every workload where the two ceilings happen to order the same way, so the cover on latency_ceiling < rate_ceiling is the only thing that reaches a disagreement. CURRICULUM-DERIVED from 31.2 §14's coverage-dimension rule: the dimension is the workload's shape, and running one workload longer never reaches it.

19. Baseline Defects Found Before Mutation

Each of the nine weak instruments run against the robust property set, before any mutation.

ItemWeak instrument caught byAt what cost
§6p_every_measure_publishes_a_denominatornothing — read the report line
§7p_attribution_sums_to_windownothing — add the components
§8p_both_ceilings_computeda workload where the ceilings disagree
§9p_ceiling_is_the_whole_componentnothing — §7's attribution
§10p_deadline_miss_is_flaggeda mix where deadline-bearers are a minority
§11p_additive_law_flagged_out_of_domainnothing — one measured combined figure
§12p_shadow_advances_with_livenothing — the shadow does not exist
§13p_levels_are_monotonenothing — one division
§14p_outside_envelope_is_refusednothing — three CSV columns

DERIVED: seven of nine are found without running anything, which is the highest rate of the five gates and by a wide margin. 33.2 found five of nine in source text, 33.3 two of nine, 33.4 five of nine in artifacts. Here it is seven, and every one is an omission rather than an error.

The two that need a stimulus need a shape, not a duration — and both shapes belong to the environment's model.

ItemThe stimulusWhy more of the nominal never reaches it
§8a workload where the ceilings order oppositelythe dimension is the access pattern's locality, not its volume
§10a mix where deadline-bearing requesters are a minoritythe dimension is the requester MIX

CURRICULUM-DERIVED from 31.2 §14 and this track's coverage-dimension rule, and from Module 32's spine — what differs between platform classes is the requester mix. DERIVED: §10's dimension is therefore the same dimension Module 32 built five chapters on, which means a project that verifies against one platform's mix cannot reach it, and 33.4 §6's item is its prerequisite.

But the headline of this section is the inverse of a compliment, and it should be read that way. DERIVED: seven of nine performance defects are visible in a report, which means seven of nine are surviving because nobody reads the report with these nine questions in hand. The findings are not hidden. They are unexamined — and that is a different problem from the four preceding gates, where the findings required either a tool or an experiment.

20. Silicon Observability

Performance instruments run in silicon, so this section reads both ways: what silicon shows, and what a silicon number cannot tell you about itself.

ItemWhat silicon can showWhat it cannot
§6an efficiency counter that is flat across a changewhich of four measures it is
§7component counters that do not sum to the windowwhere the missing cycles went
§8full queues under two workloads with different throughputwhich ceiling bound each
§9an optimisation that delivered its promise and closed nothingthat the ceiling was below the gap
§10a mean that improved while a real-time client glitchedwhich class missed, without a class split
§11a projection that was optimistic by a few points, repeatedlywhich law produced it
§12the deployed policy's statistics, onlyanything about the policy not deployed
§13a channel at 100% with the application unsatisfiedwhich level the sizing used
§14a figure that is right on the bench and wrong in productionthe operating point it was taken at

Three rows are diagnostic, and each points at one item.

§10: an aggregate metric improves and a real-time client glitches in the same release. DERIVED: that combination is almost uniquely produced by a statistic dominated by a deadline-free majority — a genuine improvement would move both, and a genuine regression would move both. CURRICULUM-DERIVED from 23.1: the average is the wrong statistic, and the glitch is the tail the average cannot see.

§14: right on the bench, wrong in production, with no code change. DERIVED: the only variable that changed is the operating point, so the measurement was correct and its envelope was never published. CURRICULUM-DERIVED from 32.5 §15's finding that three of five defects were correct at their validation point — and in silicon this signature is the most common shape of a performance escape, because a bench cannot produce production's offered load.

§9: the optimisation worked and nothing improved. DERIVED: a delivered gain with no system-level change means the affected fraction was small, which is the ceiling calculation the review skipped. This is the cheapest post-hoc confirmation available: the ceiling can be computed after the fact from §7's attribution in ten minutes, and it turns a puzzling result into an arithmetic one.

And one row is a statement about a limit rather than an observation: §12's. Silicon can show the deployed policy's statistics and nothing else. DERIVED: a counterfactual that was not instrumented before tapeout cannot be recovered after itCURRICULUM-DERIVED from 23.5's counterfactual measurement, which is a design-time mechanism. The shadow state is four lines and it is the only item in this chapter that becomes impossible after tapeout rather than merely expensive.

21. Common Wrong Answers

  1. “Bus efficiency is 78%, so we have 22% headroom.” Which efficiency? §6: the same change reads −39 points on measure B and +50 on measure C. CURRICULUM-DERIVED from 12.4 §2: a claim is not a claim until it says what it divided by.

  2. “The efficiency metric did not move, so the change was neutral.” §6: command-bus occupancy rose 80% and every ratio held, because c_col and c_cmd rose together. A metric insensitive to a regression is worse than one that is wrong.

  3. “Our latency breakdown shows data 39%, refresh 6%, row work 13%.” Do they sum to 100? §7: 81.6%, with 23.4% in a category the instrument does not have and 208 cycles counted twice. CURRICULUM-DERIVED from 23.1: the components must sum exactly.

  4. “We are 20% idle, so we need more requesters.” §7: the true idle figure was 14.7% and 23.4% was timing-blocked — the overlap landed in the largest plausible bucket. The two diagnoses lead to opposite actions.

  5. “The queue is full, so we are bandwidth-bound.” §8: two workloads at occupancy 31 of 32, opposite bounds, and one had 790 unused data slots. Occupancy is a symptom of both bounds, so a threshold on it is a coin flip.

  6. “Turnaround handling improves 30%, which closes our 700-cycle gap.” §9: turnaround is 180 cycles, so a perfect fix closes 26% of the gap. The proposal will deliver its 54 cycles and be reported as working. CURRICULUM-DERIVED from 30.8's ceiling computation.

  7. “We reviewed the proposal and the gain is real.” The gain being real is not the question. DERIVED: the question is the affected fraction, and the reviewer makes this error more often than the proposer — the claim was about turnaround and the arithmetic applied it to the window.

  8. “We are optimising the controller, which is what we own.” §9's owner_cycles: the controller owned 2,740 cycles and the proposal targeted the smallest of its three components. And two components totalling 1,116 cycles belong to the requesterCURRICULUM-DERIVED from Module 32: the deciding quantities sit outside the memory.

  9. “Mean latency improved 11%.” §10: ten deadline misses were introduced. 800 of 1,000 requesters have no deadline and carry 80% of the mean's weight. CURRICULUM-DERIVED from 23.1.

  10. “Then use p99 instead of the mean.” A p99 over the same mix is also dominated by the 80% with no deadlines. DERIVED: the fix is the class split and the per-class deadline comparison, not a different quantile over the same population.

  11. “Our histogram's top bin is 512 cycles and above, and it has few samples.” Is it open? CURRICULUM-DERIVED from 23.1's component with no upper bound: a closed top bin reports a finite maximum for a quantity that has none, and the truncation is invisible because the bin has a count.

  12. “Four improvements of 10% each give us 40%.” §11: 34.4%, and the costs compose multiplicativelyCURRICULUM-DERIVED from 23.2, where it was a measured result across four workload models rather than an assumption.

  13. “The additive estimate is conservative, so it is safe.” It is conservative about efficiency and at 70% factors it predicts −20%. An instrument that can emit a negative efficiency has no domain checkCURRICULUM-DERIVED from 30.8 §11's variety 5.

  14. “Our row-hit rate is 62%, well above the 50% crossover, so open-page is right.” §12: close-page wins by 22.5% at that hit rate. Close-page has no hits by construction, so the crossover was never at a hit rate — it is where conflict cost equals foregone hit benefit, in row-work cycles.

  15. “We can reason about close-page from our open-page statistics.” CURRICULUM-DERIVED from 23.3: identical class counts can hide opposite temporal structure and differ 16× in row-work cycles. DERIVED: if identical counts can differ 16× in cost, a count-derived rate cannot decide a cost question.

  16. “DDR5-6400 gives 51.2 GB/s, and we need 21.4, so one channel is plenty.” §13: peak over-states the application-visible rate by 3.76×, so the true headroom is 1.00×. CURRICULUM-DERIVED from 23.2's central law: peak is a property of the interface.

  17. “Peak is the only number we have at sizing time.” True, and that is why the pass criterion is not “use level 5”. DERIVED: it is “state the level, and state the ratio you assume between it and level 5” — an assumption of 1.0 is still an assumption, and one that is written down can be revisited.

  18. “Read latency is 84 cycles.” At what load? §14: 84 at 45% offered load, 309 at 92% — a 3.7× difference in the component 23.1 says has no upper bound. A figure with no operating point is not a measurement of the system, it is a measurement of a run.

  19. “The measurement is repeatable, so it is trustworthy.” Repeatable at its operating point. CURRICULUM-DERIVED from 18.4 §1: 84 cycles is grade A evidence, documented for a named configuration, and a CSV of metric and value performs category drift as a file format.

  20. “We cannot refuse to answer a capacity question.” §14's refusal is its most useful output. DERIVED: “unmeasured, 47 points outside the envelope” names a characterisation run somebody must schedule; “84” cannot be questioned because it is true.

  21. “A performance review is subjective.” Seven of the nine findings here are omissions visible in a report — a missing operating point, a bare percentage, components that do not sum, a peak figure in a sizing cell, losses that were added, an absent shadow, a non-monotone level set. None requires judgement.

  22. “We will tune it after we see silicon.” §12 is the one item that becomes impossible rather than expensive after tapeout, because a counterfactual has to be instrumented before the fact. CURRICULUM-DERIVED from 23.5: counterfactual measurement is a design-time mechanism.

22. Self-Check

  1. A report says “bus efficiency 78.1%.” Name the two things you ask for, and say why the quotient alone cannot be reconstructed into them.
  2. A latency breakdown lists five components. What is the first arithmetic you perform, and what does a residue category buy that a sum property does not?
  3. Two workloads both show maximum queue occupancy of 31 out of 32. Give the two ceilings you would compute, and say which workload's fix is a wider data path.
  4. A proposal promises a 30% improvement in turnaround handling and the gap is 700 cycles. What do you need from §7's attribution, and what is the harshest defensible ceiling?
  5. A scheduling change improves mean latency 11%. State the one question that decides whether it ships, and say why switching to p99 does not answer it.
  6. Four independently measured efficiency factors are each 0.90. Give both predictions, and say which single additional measurement settles which law applies.
  7. A colleague says close-page would be better because the row-hit rate is only 62%. State what is wrong with the reasoning in one sentence, and name the currency the comparison must use.
  8. A sizing spreadsheet divides a required 21.4 GB/s into a 51.2 GB/s peak. Name the five levels, say who owns each loss, and state what the spreadsheet actually compared.
  9. A CSV gives read_latency_cycles,84. What three columns are missing, and what is the evidence grade the figure holds versus the grade it is being used at?
  10. Four mutations survived this chapter's property set. Group them, and give the general statement about what a bound can and cannot catch.
  11. M18 drove shortfall_cycles from affected_cycles. Name the defect class, say which earlier chapter owns it, and explain why it is the sharpest finding in this chapter.
  12. Of the nine items, how many are found by reading a report, how many need a stimulus, and which single stimulus dimension do both of the latter share?

23. The Residual Risk

What this gate cannot catch, stated plainly — and one limit was proved by this chapter's own mutation run.

It cannot check its own objectives. M18 drove the shortfall from the affected fraction and every property passed. DERIVED: §17 claimed that an objective closes variety 12's open half, and M18 shows the objective then becomes the thing requiring independenceso the chain is: a mechanism checked by a property, a quantity by a bound, a bound's width by an objective, and an objective by nothing inside engineering. It comes from a product requirement, and this gate takes it on faith.

It cannot tell you the right resolution. M15, M16 and M17 widened an envelope tolerance, a histogram bin and a window, kept every mechanism correct, and destroyed the instruments. CURRICULUM-DERIVED from 33.4 §15's variety 12: the fix is a width requirement derived from the decision the instrument serves, and that derivation is a document rather than a property.

It cannot recover a counterfactual that was never instrumented. CURRICULUM-DERIVED from 23.5: counterfactual measurement is a design-time mechanism, so §12's finding, discovered after tapeout, has no remedy in that silicon. Every other item in this chapter can be re-derived from counters a part already has.

It cannot see a cost that is not in the memory system's window. Every item here attributes cycles within a window at the memory interface. CURRICULUM-DERIVED from Module 32's result that the four deciding quantities are measured outside the memory, and from 29.2 §7's recorded finding that both layers satisfy their own contracts and only a per-source measurement reveals the gap. DERIVED: §9's owner_cycles names the requester as an owner and cannot measure what the requester did wrong.

And it cannot establish that the workload measured is the workload that will run. Nine items check a number against an expectation. All nine are relative to an offered load, a mix and a locality structure that came from somewhereand §14's envelope test bounds extrapolation, not representativeness. A perfectly characterised envelope around an unrepresentative workload passes every item.

The honest summary: this gate's nine items decide whether a number means what a decision assumed. It cannot decide whether the objective was right, whether the resolution was adequate, or whether the workload was the one that matters.

24. Where This Goes

Five gates have now reviewed a design on paper, in code, in its registers, in its testbench, and in its numbers. The next gate is the first one that runs on hardware.

Chapter 33.6 reviews bring-up. The question changes from is this number right to what does this gate establish, and what does the next one depend on because bring-up is the first activity in this module whose structure is a dependency order rather than a checklist, and an order can be wrong in a way no individual step is.

From hereWhat 33.6 must settle
§14's envelope refusalWhat does a bring-up stage establish, such that a later stage may rely on it?
§12's un-recoverable counterfactualWhich measurements must be taken while the system is still reducible?
§8's two-ceiling discriminationHow do you change one variable when every stage depends on the previous one?

The second row is the one to carry forward, and it generalises beyond the counterfactual. DERIVED: §12's shadow instrument must exist before tapeout; §14's envelope must be characterised before a decision needs it; and both are instances of a single rule — some evidence is only obtainable while a system is in a state it will not return to. CURRICULUM-DERIVED from 28.1's diagnostic ledger, which preserves the earliest reliable evidence, and from 28.7's framing of bring-up as “making the suspect list short by construction.”

So the next gate's organising question is not what do we test but in what order, and what does each step make it safe to assume. CURRICULUM-DERIVED from 21.5 §2, whose rule this module now inherits at a larger scale: the order is determined by which observable each step requires, not by which direction it trains. DERIVED: every gate so far could be run in any order and would find the same defects. Bring-up cannotand 33.6's first item is the one this chapter has no way to ask: which stage's failure invalidates the evidence from every stage after it?

Continue learning

Standards & specifications

Governing standard
JEDEC JESD79 (DDR SDRAM)(opens JEDEC Solid State Technology Association in a new tab)

Defines the DDR SDRAM device itself — signals, command encoding, mode registers, timing parameters and the initialisation sequence — one document per generation. Memory-controller microarchitecture, address-mapping policy, PHY training algorithms and board-level design are not specified by it.

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 DDR curriculum.