“CXL Is Only for Memory”

"CXL is only for memory" is the second belief almost everybody forms, and unlike 31.1's it is not built from a reasoning error. It is built from a sampling error, which is harder to see and harder to argue with, because everything the believer has personally observed is true and consistent.

The question this chapter turns on:

How many KINDS have you seen — and how many does the family have?

"Only" is a claim about the size of a set. The evidence people offer for it is a claim about membership: the devices they met were memory devices, so memory is what the family is. Those are different statements, and the second does not imply the first.

1. Twenty Examples Of One Kind Is One Kind

The structure of the error is ordinary statistical sampling, and naming it is most of the cure.

Twenty examples of one kind is one kind sampled. The number that decides a scope question is how many categories the evidence covers, and it is a different number from how many examples it contains — a number that rises with effort and says nothing about coverage.

That is the whole refutation, and the rest of this chapter is nine different ways of making it concrete: by counting protocol members, by enumerating device roles, by naming access directions, by separating capabilities from deployments, and by listing what would have to be true.

2. How To Use This Chapter

Each of the nine dimensions below is a working test of the claim, and every one answers the same seven questions:

The last row matters most. A correction that only says "that is wrong" leaves the listener with nothing; the answer is the structure, and the structure is more interesting than the belief.

3. The One-Sentence Model

The family defines several members, a device may present memory, cache host memory, both or neither, and the two directions of access are independent — so "only for memory" is a claim about one member, one role and one direction, offered as a claim about all three.

4. What This Chapter Owns

The boundary with 31.1 is worth stating. That chapter refutes a claim about displacement — what stopped being needed. This one refutes a claim about scope — how much of a family one observation covers. They fail in different ways: displacement is settled by counting what remains, and scope is settled by counting what was sampled.

5. Teaching-Model Boundary And Source Discipline

Every model in this chapter is a teaching model, and each computes a property of a CLAIM rather than of a protocol.

Nothing in this chapter states a normative detail of any specification. No opcode, packet layout, bit position, field width, response encoding, device type, class code, capability, register definition, timing guarantee, link rate or specification revision appears anywhere — checked by a scan over the finished page as well as by writing the models that way. No model names any sub-protocol; they speak of a family with members, and the naming happens only in prose.

And the refutation needs no specification detail, which is itself the argument: a scope claim is settled by counting members, roles and directions, and a bit position would not help.

6. Test 1 — Count The Members, Not The One You Met

The claim under test. That the family has one member.

What "only" would require. That nothing is left when you subtract what this device uses.

// RTL 1 - a family with several members, and the one you happened to meet.
//
// "It is only for X" is a claim about the SIZE OF A SET. The evidence people
// offer for it is a claim about MEMBERSHIP: the device they saw used X, so X
// is what the family is. Those are different statements, and the second does
// not imply the first. The arithmetic is the whole refutation - count the
// members the family defines, count the members this device uses, and publish
// both numbers rather than one.
//
//   BAD  : "every device I have seen uses the memory member, so that is all
//          the family has"
//   GOOD : family defines N members; this device uses K of them; N - K are
//          present in the interface and unused by this device
//
// TEACHING MODEL. It counts a property of a SCOPE CLAIM using illustrative
// member counts. It is not a model of CXL or of any protocol stack, and it
// contains no opcode, layout, field width, encoding, register definition,
// timing guarantee or specification revision from any published standard.
//
//   INITIALIZATION CONTRACT (this model is combinational):
//     power-on/reset : no state; every output is a function of the inputs
//     re-initialise  : not applicable - there is nothing to reload
//     telemetry      : n_claims / n_overclaims are the only state, and they
//                      reset to zero and count on `assess` only
module protocol_count #(parameter int USED_IS_ALL = 0) (
  input  logic clk, rst_n,
  input  logic       assess,
  input  logic [7:0] family_size, used_here,
  output logic [7:0] unused_here, n_claims, n_overclaims,
  output logic [15:0] narrowed_pct,
  output logic       uses_all, claimed_all,
  output logic       proto_err
);
  logic [31:0] n_q;
  logic [7:0]  used_c;

  // A device cannot use more members than the family defines. Clamp rather
  // than wrap: an out-of-range input is a bad measurement, not a bigger family.
  assign used_c     = (used_here > family_size) ? family_size : used_here;
  assign unused_here = family_size - used_c;

  // The truth: the device exercises the whole family only when nothing is left.
  assign uses_all = (unused_here == 8'd0);

  // How much of the family this device's usage would let you see, as a
  // percentage. A degenerate family of zero members is reported as 100 rather
  // than dividing: there is nothing left unseen.
  assign n_q = (family_size == 8'd0) ? 32'd100
             : (({24'd0, used_c} * 32'd100) / {24'd0, family_size});
  assign narrowed_pct = n_q[15:0];

  // The whole review point: what a reader concludes from one device's usage.
  assign claimed_all = (USED_IS_ALL != 0) ? 1'b1 : uses_all;

  // SAFETY-OF-CLAIM VIOLATION: the family was declared fully exercised while
  // members remain that this device never touched.
  assign proto_err = assess && claimed_all && !uses_all;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_claims <= 8'd0; n_overclaims <= 8'd0;
    end else if (assess) begin
      n_claims <= n_claims + 8'd1;
      if (proto_err) n_overclaims <= n_overclaims + 8'd1;
    end
  end
endmodule

The measurement. A family of three members, with this device using one:

family 3, this device uses 1 : unused=2 spans=33% counted_all=0 used_is_all_says=1

Two members are present in the interface and unused by this device, and the coverage this one device's usage gives you is 33 percent. The used-is-all build reports the family fully exercised — and it is not a strawman, it is what a reader concludes at the end of a data sheet for one part.

The run drives the middle case too — two of three, at 66 percent — because a stimulus that goes from one to all and never stops between is the shape 30.8 section 19 records as the batch's own blind spot.

Why the belief is reasonable. A device that uses one member of a family is completely described by that member. Nothing in its documentation is wrong, and nothing in it mentions what it does not use.

What it costs to hold. A platform specification written against one member, and a bring-up that discovers the others exist when a second device arrives.

What to say instead. "The family defines three members; this device uses one. The other two are in the interface and unused here."

Figure 1 — the two muted boxes are what the claim erases. They are in the interface whether or not the device you met has any use for them.

7. Test 2 — Enumerate The Four Roles

The claim under test. That every device is in one role.

What "only" would require. That the role set has one member.

The two independent questions. Does this device present memory the host can address? Does it cache host memory it must keep coherent? Two booleans give four roles, and three of the four are not memory-attach.

// RTL 2 - four roles, and the claim that there is one.
//
// Two independent questions decide what a device does at the interface: does
// it PRESENT memory that the host can address, and does it CACHE host memory
// that it must keep coherent? Two booleans give four roles, and "only for
// memory" is the assertion that only one of the four is reachable. Enumerating
// the four is the refutation, because three of them are not memory-attach.
//
//   BAD  : one role, assumed
//   GOOD : name the two questions, enumerate the four answers, and say which
//          one this device is
//
// TEACHING MODEL. Combinational role decode over two illustrative booleans.
// No device type, class code or capability from any specification appears.
//
//   INITIALIZATION CONTRACT (combinational):
//     power-on/reset : no state; role_id is a pure function of the two inputs
//     re-initialise  : not applicable
//     telemetry      : n_devices / n_misread count on `assess` and reset to 0
module device_role #(parameter int MEMORY_IS_THE_ONLY_ROLE = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic presents_memory, caches_host,
  output logic [7:0] role_id, role_count, n_devices, n_misread,
  output logic       only_memory, reported_only_memory,
  output logic       role_err
);
  // Role 0 neither, 1 presents memory only, 2 caches host only, 3 both.
  assign role_id = {6'd0, caches_host, presents_memory};

  // How many of the two capabilities this device actually exercises. It is the
  // population count of the role, and it is what separates role 3 from 1 and 2.
  assign role_count = {7'd0, presents_memory} + {7'd0, caches_host};

  // The truth: this device is a memory-attach device and nothing else.
  assign only_memory = presents_memory && !caches_host;

  // The whole review point: whether the reader reads every device as role 1.
  assign reported_only_memory = (MEMORY_IS_THE_ONLY_ROLE != 0) ? 1'b1 : only_memory;

  // SAFETY-OF-CLAIM VIOLATION: a device was read as memory-attach-only while
  // it is in a role the claim excludes.
  assign role_err = assess && reported_only_memory && !only_memory;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_devices <= 8'd0; n_misread <= 8'd0;
    end else if (assess) begin
      n_devices <= n_devices + 8'd1;
      if (role_err) n_misread <= n_misread + 8'd1;
    end
  end
endmodule

The measurement. A device that caches host memory and presents none:

caches host memory, presents none : role=2 count=1 only_memory=0 one_role_says=1

One capability exercised, and it is the other one. The one-role build reads it as memory-attach anyway. The run drives all four roles, and the enumerating build misreads none of them while the one-role build misreads three.

Enumerating the four is the refutation, and it needs no argument at all: writing the truth table down is the whole of it.

Why the belief is reasonable. The role that gets discussed is the one that motivates the technology commercially, and the other three are underrepresented in the material rather than in the world.

What it costs to hold. A device taxonomy with one entry, and an integration review that has no row for the device in front of it.

What to say instead. "There are two independent questions and therefore four roles. This device is in role 2, and role 2 is not memory attach."

8. Test 3 — Name The Direction

The claim under test. That the interface is characterised.

What "only" would require. That one direction described both.

The failure. Memory attach is the host reaching into the device: the device presents an address range and the host reads and writes it. Coherent caching is the device reaching into the host. These are opposite directions across the same link, and a statement about one of them carries no information about the other.

// RTL 3 - two directions, and a claim about one of them.
//
// Memory attach is the host reaching into the device: the device presents an
// address range and the host reads and writes it. Coherent caching is the
// device reaching into the host: the device holds a copy of host memory and
// must participate in the rules that keep it correct. These are OPPOSITE
// DIRECTIONS across the same link, and a statement about one of them carries
// no information about the other.
//
//   BAD  : "it is a memory technology" - a claim about host-to-device traffic,
//          used as if it described the interface
//   GOOD : name the direction the claim is about, then ask what the other
//          direction does
//
// TEACHING MODEL. Two illustrative direction flags; no packet, channel,
// encoding or flow-control detail from any specification appears.
//
//   INITIALIZATION CONTRACT. Sequential, and the state is a single sticky
//   record of which directions have been observed since the last clear:
//     power-on/reset  : both seen-bits clear
//     initialisation  : `clear_seen` is the one-shot that returns them to zero
//     re-initialise   : legal at any time, including while traffic is live -
//                       it is an explicit measurement-window reset, not a
//                       recovery action, and it is idempotent
//     telemetry       : directions_used proves which directions were observed
module access_direction #(parameter int ONE_DIRECTION_IS_THE_LINK = 0) (
  input  logic clk, rst_n,
  input  logic host_to_device, device_to_host, clear_seen, assess,
  output logic [7:0] directions_used, n_assessments, n_partial,
  output logic       seen_h2d, seen_d2h, both_directions,
  output logic       claimed_complete,
  output logic       dir_err
);
  logic h_q, d_q;

  assign seen_h2d = h_q;
  assign seen_d2h = d_q;
  assign directions_used = {7'd0, h_q} + {7'd0, d_q};

  // The truth: the interface has been characterised only when both directions
  // have been observed.
  assign both_directions = h_q && d_q;

  // The whole review point: what a reader concludes from one direction.
  assign claimed_complete = (ONE_DIRECTION_IS_THE_LINK != 0)
                          ? (h_q || d_q) : both_directions;

  // SAFETY-OF-CLAIM VIOLATION: the interface was declared characterised on
  // evidence from one direction only.
  assign dir_err = assess && claimed_complete && !both_directions;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      h_q <= 1'b0; d_q <= 1'b0; n_assessments <= 8'd0; n_partial <= 8'd0;
    end else begin
      // Clear dominates: a measurement-window reset takes effect on the edge
      // it is asserted, even if traffic is present in the same cycle. Stating
      // the priority is the point - two independent statements here would let
      // an arriving beat survive the clear.
      if (clear_seen) begin
        h_q <= 1'b0; d_q <= 1'b0;
      end else begin
        if (host_to_device) h_q <= 1'b1;
        if (device_to_host) d_q <= 1'b1;
      end
      if (assess) begin
        n_assessments <= n_assessments + 8'd1;
        if (dir_err) n_partial <= n_partial + 8'd1;
      end
    end
  end
endmodule

The measurement. Host-to-device traffic observed, device-to-host not:

host-to-device seen, device-to-host not : used=1 both=0 one_direction_says=1

One direction of two, and the one-direction build calls the interface characterised. The run then drives the other direction, and both builds agree the interface is characterised — the weak build is not always wrong, it is wrong in exactly one state.

The measurement window is explicitly re-initialisable, and the model states the priority: a clear dominates traffic arriving in the same cycle. A clear that a beat could survive would not be a clear, and the run drives that simultaneous case.

Why the belief is reasonable. A device you only ever saw being read by a host really did only ever exhibit one direction.

What it costs to hold. A verification plan with stimulus in one direction, and a device-initiated path whose first test is a customer's.

What to say instead. "Which direction is that claim about? The other one is a different question and needs its own evidence."

9. Test 4 — Name The Limit That Binds

The claim under test. That what a workload needs is memory.

What "only" would require. That every limit is answered by more addressable bytes.

Three ways to be slow. A capacity-bound workload wants more bytes. A bandwidth-bound workload wants a wider or faster path. A coherence-bound workload is waiting on ownership, and neither more bytes nor more bandwidth moves it.

// RTL 4 - three ways to be slow, and the one that more memory fixes.
//
// "It is for memory" is usually a statement about what a workload NEEDS, and
// workloads run out of three different things. A capacity-bound workload wants
// more addressable bytes. A bandwidth-bound workload wants a wider or faster
// path. A coherence-bound workload is waiting on ownership, and neither more
// bytes nor more bandwidth moves it. Only one of the three is answered by
// attaching memory, which is why "only for memory" leaves two thirds of the
// problem space unaddressed.
//
//   BAD  : "the workload needs memory"
//   GOOD : name which of the three limits binds, and say what each one wants
//
// TEACHING MODEL. Three illustrative boolean limits. No latency, bandwidth or
// capacity figure from any specification appears.
//
//   INITIALIZATION CONTRACT (combinational decode + two counters):
//     power-on/reset : counters zero; the decode is a pure function
//     re-initialise  : not applicable to the decode
//     telemetry      : n_workloads / n_wrong_fix count on `assess`
module bottleneck_kind #(parameter int MEMORY_FIXES_EVERYTHING = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic capacity_bound, coherence_bound, bandwidth_bound,
  output logic [7:0] limits_named, n_workloads, n_wrong_fix,
  output logic       helped_by_memory, more_memory_prescribed,
  output logic       kind_err
);
  assign limits_named = {7'd0, capacity_bound} + {7'd0, coherence_bound}
                      + {7'd0, bandwidth_bound};

  // The truth: adding addressable bytes helps exactly one of the three, and it
  // helps that one only when it is the limit that actually binds.
  assign helped_by_memory = capacity_bound && !coherence_bound && !bandwidth_bound;

  // The whole review point: which workloads get prescribed more memory.
  assign more_memory_prescribed = (MEMORY_FIXES_EVERYTHING != 0)
                                ? (limits_named != 8'd0) : helped_by_memory;

  // SAFETY-OF-CLAIM VIOLATION: more memory was prescribed for a workload it
  // cannot help.
  assign kind_err = assess && more_memory_prescribed && !helped_by_memory;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_workloads <= 8'd0; n_wrong_fix <= 8'd0;
    end else if (assess) begin
      n_workloads <= n_workloads + 8'd1;
      if (kind_err) n_wrong_fix <= n_wrong_fix + 8'd1;
    end
  end
endmodule

The measurement. A coherence-bound workload:

coherence-bound only : limits=1 helped_by_memory=0 memory_prescribed=1

One limit named, and it is not the one memory fixes. The memory-fixes-everything build prescribes memory anyway. The run drives six workloads — capacity alone, coherence alone, capacity with coherence, capacity with bandwidth, bandwidth alone, and nothing at all — and the weak build prescribes wrongly on four of them.

Only one of three limits is answered by attaching memory, which is why "only for memory" leaves two thirds of the problem space unaddressed.

Why the belief is reasonable. Capacity is the limit that is easiest to measure and the one most often hit first, so it is the limit most people have personally debugged.

What it costs to hold. A capacity purchase for a workload whose problem was ownership, and a second one when the first does not help.

What to say instead. "Which of the three limits binds? More memory answers exactly one of them."

10. Test 5 — Count The Kinds You Sampled

The claim under test. That the evidence covers the space.

What "only" would require. That no kind went unsampled.

// RTL 5 - the scope you infer from the examples you happened to meet.
//
// Everybody's first contact with a technology is with one product category,
// and the scope they infer is the scope of that category. The mechanism is
// ordinary sampling: if every example you have seen is of one kind, the
// evidence is consistent with the family having one kind AND with its having
// many. The number that separates them is how many KINDS you sampled, not how
// many examples - twenty examples of one kind is one kind sampled.
//
//   BAD  : count the examples
//   GOOD : count the KINDS, and publish coverage of the kind space
//
// TEACHING MODEL. Illustrative sample counts; not a survey of any real market.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : spans_pct is the kind coverage a reader should demand
module first_example_bias #(parameter int EXAMPLES_ARE_KINDS = 0) (
  input  logic clk, rst_n,
  input  logic        assess,
  input  logic [7:0]  samples_seen, kinds_seen, kinds_total,
  output logic [15:0] spans_pct, examples_pct,
  output logic [7:0]  kinds_missed, n_assessments, n_overgeneralised,
  output logic        spans_the_space, claimed_spans,
  output logic        sample_err
);
  logic [31:0] k_q, e_q;
  logic [7:0]  kinds_c;

  // You cannot have sampled more kinds than exist.
  assign kinds_c     = (kinds_seen > kinds_total) ? kinds_total : kinds_seen;
  assign kinds_missed = kinds_total - kinds_c;

  // The truth: the sample spans the space when no kind is missing.
  assign spans_the_space = (kinds_missed == 8'd0);

  assign k_q = (kinds_total == 8'd0) ? 32'd100
             : (({24'd0, kinds_c} * 32'd100) / {24'd0, kinds_total});
  assign spans_pct = k_q[15:0];

  // The flattering number: examples as a fraction of a nominal target of 20.
  // It rises with effort and says nothing about coverage, which is the point.
  assign e_q = ({24'd0, samples_seen} * 32'd100) / 32'd20;
  assign examples_pct = (e_q > 32'd100) ? 16'd100 : e_q[15:0];

  // The whole review point: which number the reader believes they have.
  assign claimed_spans = (EXAMPLES_ARE_KINDS != 0)
                       ? (samples_seen >= kinds_total) : spans_the_space;

  // SAFETY-OF-CLAIM VIOLATION: the space was declared spanned while kinds
  // remain that were never sampled.
  assign sample_err = assess && claimed_spans && !spans_the_space;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_overgeneralised <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (sample_err) n_overgeneralised <= n_overgeneralised + 8'd1;
    end
  end
endmodule

The measurement. Twenty examples, all of one kind, in a space of four:

20 examples, 1 kind, 4 kinds exist : kinds=25% examples=100% spans=0 examples_are_kinds_says=1

Two numbers, and only one of them means anything. The examples figure is 100 percent and rises with effort; the kind coverage is 25 percent and is the figure that decides. The examples-are-kinds build reports the space spanned because it compared the wrong quantity.

This is 30.5 section 7's denominator finding, met in a completely different setting: a ratio with no stated denominator is not a measurement, and here the wrong denominator is the number of examples rather than the number of categories.

The run also drives the case where the weak build is right — three examples against four kinds, where its own test fails and it claims nothing. A build that is wrong in one state and right in the others is the only kind of weak build worth modelling, because it is the only kind anybody would actually hold.

Why the belief is reasonable. Twenty careful observations feel like coverage, and there is no moment during the twentieth one at which the sampling problem announces itself.

What it costs to hold. An architecture decision made from a sample that covered one quarter of its own space, with no record that it did.

What to say instead. "How many kinds is that? Twenty examples of one kind is one kind."

11. Test 6 — Separate The Capability From The Deployment

The claim under test. That what nobody uses is not there.

What "only" would require. That an unused capability were absent.

The failure. The commonest evidence offered for a scope claim is a deployment: nobody in this fleet uses that capability, therefore it is not part of the thing. That reads a deployment as a definition, and the two differ exactly when a capability is present and unused — which is the normal state of any general-purpose interface.

// RTL 6 - a capability nobody used is still in the interface.
//
// The commonest evidence offered for a scope claim is a deployment: nobody in
// this fleet uses that capability, therefore it is not part of the thing. That
// reads a DEPLOYMENT as a DEFINITION, and the two differ exactly when a
// capability is present and unused - which is the normal state of any
// general-purpose interface. The distinguishing question is whether the
// capability would be available to a device that asked for it.
//
//   BAD  : "nobody uses it, so it is not there"
//   GOOD : separate present-in-the-interface from used-in-this-deployment, and
//          publish both
//
// TEACHING MODEL. Two illustrative booleans per capability.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : in_interface and capability_used are published
//                      SEPARATELY, which is the whole fix
module capability_vs_use #(parameter int UNUSED_MEANS_ABSENT = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic capability_present, capability_used,
  output logic [7:0] n_reviews, n_wrong_calls,
  output logic       in_interface, unused_but_present, reported_present,
  output logic       cap_err
);
  // The truth: presence is a property of the interface, not of this fleet.
  assign in_interface = capability_present;

  // The state the two readings disagree about, made observable on its own.
  assign unused_but_present = capability_present && !capability_used;

  // The whole review point: what a reader reports the interface contains.
  assign reported_present = (UNUSED_MEANS_ABSENT != 0)
                          ? capability_used : in_interface;

  // SAFETY-OF-CLAIM VIOLATION: a capability that exists was reported absent.
  // Note the direction - this build UNDER-reports, and an under-report is what
  // makes a scope claim sound modest and defensible while being wrong.
  assign cap_err = assess && !reported_present && in_interface;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_reviews <= 8'd0; n_wrong_calls <= 8'd0;
    end else if (assess) begin
      n_reviews <= n_reviews + 8'd1;
      if (cap_err) n_wrong_calls <= n_wrong_calls + 8'd1;
    end
  end
endmodule

The measurement. A capability present and nobody using it:

present, nobody uses it : in_interface=1 unused_but_present=1 unused_means_absent_says=0

The unused-means-absent build UNDER-reports, and that is the direction worth noticing. An under-report sounds modest and defensible — "we only claim what we have seen" — while being wrong, which is why it survives review better than an overclaim would.

Why the belief is reasonable. A fleet report is real evidence about a fleet. It is simply evidence about the wrong noun.

What it costs to hold. An interface specification written from a deployment census, and a device that legitimately uses a capability the specification says does not exist.

What to say instead. "Present in the interface, or used in this fleet? Publish both — they are different facts."

12. Test 7 — The Device That Presents Nothing

The claim under test. That a device with no memory to offer has nothing to gain.

What "only" would require. That the only benefit were on the presenting side.

The decisive counter-example. A device that presents no addressable memory to the host and still gains — on the other side of the interface. It holds a copy of host data, works on it, and needs the ownership rules to make that safe. Nothing about that benefit is a memory-attach benefit.

// RTL 7 - the accelerator that presents no memory at all.
//
// The decisive counter-example to "only for memory" is a device that presents
// NO addressable memory to the host and still has something to gain. It gains
// on the other side of the interface: it holds a copy of host data, works on
// it, and needs the ownership rules to make that safe. Nothing about that
// benefit is a memory-attach benefit, and a claim that excludes it excludes
// the case the technology is most often built for.
//
//   BAD  : "no memory presented, so nothing to gain"
//   GOOD : ask what the device does with HOST data, not what it offers back
//
// TEACHING MODEL. Two illustrative booleans and a benefit decode. No device
// type, class code, capability or coherence state from any specification
// appears.
//
//   INITIALIZATION CONTRACT (combinational + two counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : benefits is published beside presents_none, so the
//                      two can be compared by anybody reading the registers
module accelerator_without_memory #(parameter int NO_MEMORY_NO_BENEFIT = 0) (
  input  logic clk, rst_n,
  input  logic assess,
  input  logic presents_memory, needs_ownership,
  output logic [7:0] n_devices, n_excluded,
  output logic       presents_none, benefits, reported_benefits,
  output logic       accel_err
);
  assign presents_none = !presents_memory;

  // The truth: a device gains if it presents memory OR if it needs to
  // participate in ownership. The two paths are independent, which is exactly
  // what the misconception collapses.
  assign benefits = presents_memory || needs_ownership;

  // The whole review point: a reader who scores the memory side only.
  assign reported_benefits = (NO_MEMORY_NO_BENEFIT != 0) ? presents_memory : benefits;

  // SAFETY-OF-CLAIM VIOLATION: a device that gains was reported as gaining
  // nothing. This is an under-report again, and its cost is a device that is
  // never considered.
  assign accel_err = assess && !reported_benefits && benefits;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_devices <= 8'd0; n_excluded <= 8'd0;
    end else if (assess) begin
      n_devices <= n_devices + 8'd1;
      if (accel_err) n_excluded <= n_excluded + 8'd1;
    end
  end
endmodule

The measurement. A device presenting nothing and needing ownership:

presents nothing, needs ownership : presents_none=1 benefits=1 no_memory_no_benefit_says=0

The two paths are independent, which is exactly what the misconception collapses: a device gains if it presents memory or if it needs to participate in ownership. The memory-only build scores one of the two and reports no benefit.

And a claim that excludes this case excludes the case the technology is most often built for, which is the sharpest thing in the chapter: the misconception's blind spot is the headline application.

Why the belief is reasonable. If you have only met presenting devices, "presents nothing" reads as "does nothing", and there is no counter-example in your experience to interrupt it.

What it costs to hold. An accelerator evaluated against the wrong criterion and rejected for offering no capacity.

What to say instead. "Ask what it does with HOST data, not what it offers back."

13. Test 8 — The Question Every Device Raises

The claim under test. That knowing what a device presents settles its design.

What "only" would require. That the memory question were the only question.

The failure. Whether a device presents memory, caches host memory, both or neither, it still has to be found — enumerated, configured and reached. A scope claim about memory says nothing about that question, and a review that treats "it is a memory device" as an answer leaves it open.

// RTL 8 - the question that is there whatever the device presents.
//
// 30.6 section 9 and 31.1 section 8 both turn on the same structural fact:
// attachment and the other decisions are independent questions. This chapter
// meets it from the third side. Whether a device presents memory, caches host
// memory, both or neither, it still has to be FOUND - enumerated, configured
// and reached. A scope claim about memory says nothing about that question,
// and a design review that treats "it is a memory device" as an answer leaves
// it open.
//
//   BAD  : "it is a memory device, so the attach question is settled"
//   GOOD : every device raises the enumeration question; answer it separately
//
// TEACHING MODEL. Booleans only; no enumeration, configuration or discovery
// mechanism from any specification appears.
//
//   INITIALIZATION CONTRACT. Sequential, and the state is one sticky record of
//   whether the enumeration question has been answered for this device:
//     power-on/reset  : answered clear
//     initialisation  : `answer_it` sets it; it is a one-shot per device
//     re-initialise   : `fresh_device` clears it and is legal at any time -
//                       a new device arrives with its question unanswered
//                       whatever the previous device was
//     telemetry       : attach_open must read zero at sign-off
module io_still_there #(parameter int MEMORY_ANSWERS_ATTACH = 0) (
  input  logic clk, rst_n,
  input  logic fresh_device, answer_it, assess,
  input  logic presents_memory,
  output logic [7:0] n_devices, n_unattached,
  output logic       enumeration_answered, attach_open, reported_settled,
  output logic       io_err
);
  logic ans_q;

  assign enumeration_answered = ans_q;

  // The truth: every device needs enumeration, so the question is open until
  // it has been answered for this device - regardless of what it presents.
  assign attach_open = !ans_q;

  // The whole review point: a reader who lets one answer close two questions.
  assign reported_settled = (MEMORY_ANSWERS_ATTACH != 0)
                          ? (ans_q || presents_memory) : ans_q;

  // SAFETY-OF-CLAIM VIOLATION: the design was called settled with the
  // enumeration question still open.
  assign io_err = assess && reported_settled && attach_open;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      ans_q <= 1'b0; n_devices <= 8'd0; n_unattached <= 8'd0;
    end else begin
      // One assignment, stated priority: a fresh device always arrives with
      // the question open, even if an answer lands in the same cycle. Two
      // independent statements here would let the stale answer survive.
      if (fresh_device)   ans_q <= 1'b0;
      else if (answer_it) ans_q <= 1'b1;
      if (assess) begin
        n_devices <= n_devices + 8'd1;
        if (io_err) n_unattached <= n_unattached + 8'd1;
      end
    end
  end
endmodule

The measurement. A memory device with its enumeration question unanswered:

a memory device, enumeration unanswered : answered=0 open=1 memory_answers_attach_says=1

The memory-answers-attach build calls the design settled on a fact that has nothing to do with the open question. The run then drives a device that presents nothing, where the weak build has nothing to lean on and is right by accident — it fails only on memory devices, which is the worst possible failure distribution, because memory devices are the ones it will meet.

This is 30.6 section 9 and 31.1 section 8 met from a third side. Three chapters, three claims, one structural fact: two independent questions do not collapse because one of them was answered.

Why the belief is reasonable. In the examples that get written up, the two questions are answered together, so they look like one decision.

What it costs to hold. A design review that closes with an unanswered enumeration question, discovered at bring-up by a device nothing can find.

What to say instead. "That answers what it presents. How is it found?"

14. Test 9 — Write Down What Would Have To Be True

The claim under test. All of them, at once.

What "only" would require. Four conditions, and all four.

// RTL 9 - what would have to be true for "only" to hold?
//
// The disciplined way to handle a scope claim is the same as for a
// displacement claim: write down the conditions under which it WOULD be true,
// then check them. Four are enough here - the family defines one member, every
// device is in one role, every workload limit is the one memory answers, and
// no capability exists that this scope excludes. Checking them turns an
// argument into an arithmetic problem.
//
//   BAD  : argue about whether it is only for memory
//   GOOD : list what would have to be true, and count how many are
//
// TEACHING MODEL. Four illustrative booleans.
//
//   INITIALIZATION CONTRACT (combinational + counters):
//     power-on/reset : counters zero
//     re-initialise  : not applicable
//     telemetry      : met_pct is published beside the conjunction, so a
//                      reader can see that 75 percent is still false
module only_conditions #(parameter int MOST_IS_ENOUGH = 0) (
  input  logic clk, rst_n,
  input  logic       assess,
  input  logic       family_has_one_member, every_device_one_role,
  input  logic       every_limit_is_capacity, no_excluded_capability,
  output logic [7:0] conditions_met, n_assessments, n_overclaims,
  output logic [15:0] met_pct,
  output logic       would_hold, claimed_holds,
  output logic       only_err
);
  logic [31:0] m_q;

  assign conditions_met = {7'd0, family_has_one_member} + {7'd0, every_device_one_role}
                        + {7'd0, every_limit_is_capacity} + {7'd0, no_excluded_capability};

  // No clamp: four one-bit values over four cannot exceed a hundred.
  assign m_q = ({24'd0, conditions_met} * 32'd100) / 32'd4;
  assign met_pct = m_q[15:0];

  // The truth: a conjunction has no partial credit.
  assign would_hold = (conditions_met == 8'd4);

  // The whole review point: the disciplined form of the misconception is not a
  // refusal to check, it is a willingness to round up.
  assign claimed_holds = (MOST_IS_ENOUGH != 0) ? (conditions_met >= 8'd3) : would_hold;

  assign only_err = assess && claimed_holds && !would_hold;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_assessments <= 8'd0; n_overclaims <= 8'd0;
    end else if (assess) begin
      n_assessments <= n_assessments + 8'd1;
      if (only_err) n_overclaims <= n_overclaims + 8'd1;
    end
  end
endmodule

The measurement. Three of the four met:

3 of 4 conditions : met=75% would_hold=0 most_is_enough_says=1

Seventy-five percent, and the claim still fails. A conjunction has no partial credit, and the most-is-enough build is the disciplined form of the misconception — not a refusal to check, but a willingness to round up.

This is the technique worth taking from the chapter, and it generalises to every sweeping claim:

Write down the conditions under which the claim WOULD be true, then check them. The argument becomes arithmetic, and the answer is usually visible immediately.

What to say instead. "Here are the four things that would have to be true. Three of them are, and a conjunction needs four."

15. The Misconception Assembled

Nine tests, one summary.

// RTL 10 - the misconception examined. Nine tests, one summary.
// "I have only ever seen memory devices" is bit 0: a true statement about a
// sample, and one sixth of an argument about scope.
module only_review_signoff #(parameter int SEEN_IS_PROOF = 0) (
  input  logic clk, rst_n,
  input  logic        review,
  input  logic        only_seen_memory, family_counted, roles_enumerated,
  input  logic        directions_named, limits_named, conditions_checked,
  output logic [5:0]  fail_mask,
  output logic [15:0] conditions_met, sound_pct,
  output logic        sound,
  output logic [7:0]  n_reviews, n_sound, n_claimed,
  output logic        mis_err
);
  logic [31:0] s_q;
  logic        truly_sound, claimed;
  assign fail_mask[0] = ~only_seen_memory;
  assign fail_mask[1] = ~family_counted;
  assign fail_mask[2] = ~roles_enumerated;
  assign fail_mask[3] = ~directions_named;
  assign fail_mask[4] = ~limits_named;
  assign fail_mask[5] = ~conditions_checked;
  assign conditions_met = {15'd0, only_seen_memory} + {15'd0, family_counted}
                        + {15'd0, roles_enumerated} + {15'd0, directions_named}
                        + {15'd0, limits_named} + {15'd0, conditions_checked};
  assign s_q = ({16'd0, conditions_met} * 32'd100) / 32'd6;
  // No clamp: six one-bit values over six cannot exceed a hundred.
  assign sound_pct = s_q[15:0];
  assign truly_sound = (fail_mask == 6'd0);
  assign claimed = (SEEN_IS_PROOF != 0) ? only_seen_memory : truly_sound;
  assign sound = claimed;
  assign mis_err = review && !truly_sound && claimed;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      n_reviews <= 8'd0; n_sound <= 8'd0; n_claimed <= 8'd0;
    end else if (review) begin
      n_reviews <= n_reviews + 8'd1;
      if (truly_sound) n_sound <= n_sound + 8'd1;
      if (claimed)     n_claimed <= n_claimed + 8'd1;
    end
  end
endmodule

The measurement. Two views of the same argument:

the family was never counted : mask=000010 met=5 sound=83%
I have only ever seen memory devices : mask=111110 met=1 sound=16%

The first line is a serious argument with one condition unmet — bit 1, the family was never counted. Five of six, and one count away from usable.

The second line is the misconception itself. Bit 0 is clear and every other bit is set: the observation is true and nothing else was done. Sixteen percent of an argument, and it is the most honest-sounding sentence in the module, because everything it asserts actually happened.

Figure 3 — bit 0 is the only one the misconception evaluates, and it evaluates to true. That is why the belief is stable: the one thing it checks, it checks correctly.

16. Quantitative Reasoning

Every figure here is a teaching parameter or a value derived from one and asserted by the testbench. None is a measurement of a real system, and none is a figure from any specification.

Family coverage, derived. Three members with one used leaves 3 − 1 = 2 unused, and 1 × 100 / 3 = 33 percent coverage under integer division. The general form is unused = total − used, and "only" requires that number to be zero. At one of three it is off by a factor of three.

Roles, derived. Two independent booleans give 2² = 4 roles, of which exactly one is memory-attach-only. A reader who assumes role 1 is right 25 percent of the time by construction — and the run confirms it: four devices driven, three misread.

Directions. Two directions, and one observed gives 1 of 2. The general point is that the set of directions has a size and the evidence has a size, and a claim is licensed only when they are equal.

Limits, derived. Three limits, one of which memory answers. Six workloads driven: capacity alone (helped), coherence alone, capacity+coherence, capacity+bandwidth, bandwidth alone (four not helped), and nothing bound (not helped, and not prescribed). The memory-fixes-everything build prescribes wrongly on four of six — 67 percent — which is the fraction of the problem space a capacity-only reading gets wrong.

Sampling, derived. Twenty examples of one kind in a space of four gives kind coverage of 1 × 100 / 4 = 25 percent and an examples figure of 20 × 100 / 20 = 100 percent. The two numbers differ by 75 percentage points on the same evidence, and only the smaller one bounds what the evidence supports. The general form: effort is a numerator over a target you chose; coverage is a numerator over a space that exists.

Capability against deployment. Two booleans, four states, and the readings differ in exactly one of them — present and unused. A disagreement confined to one cell of four is what makes this error hard to notice, because three quarters of the time the shortcut agrees.

The accelerator case. benefits = presents_memory OR needs_ownership is false in one of four input combinations. The memory-only reading is presents_memory, which is false in two. The one they differ on is the decisive one, and it is the case the technology is most often built for.

Enumeration. Every device raises the attach question, so the question count is one per device, unconditionally. The weak build answers it from presents_memory, which is correct on zero of the devices that present memory and accidentally correct on every device that presents none — the worst possible distribution, since the devices it meets are the ones it is wrong about.

Conditions, derived. Four conditions with three met is 3 × 100 / 4 = 75 percent, and the claim requires four of four. A conjunction is not a percentage.

The sign-off arithmetic. Six conditions; five met is 5 × 100 / 6 = 83 percent under integer division, and one met is 100 / 6 = 16 percent.

17. Verification Method

Order of work

names.txt → ten models, each compiled alone → model-expressiveness review → boolean-tautology review → width review → structural gates → testbench → legal baseline → PASS → mutation campaign → re-baseline after every change → MDX assembled from the verified sources

A mutation campaign on a failing baseline is invalid, and all three campaigns in this chapter ran against a green one. The baseline was re-run after every testbench modification before the campaigns were re-run.

Independent oracles

chkv prints got against expected, which is what lets an oracle be wrong out loud. In this chapter it caught none — and section 18 explains why that is a fact about the models' shape rather than about the care taken.

X and Z rejected explicitly

chk(c, …) tests c !== 1'b1, so an X-valued condition fails rather than passing. chkv(got, exp, …) reduces the result and reports an explicit X/Z failure before comparing. 30.7 owes three undriven outputs to that rejection, and this batch turned the sweep it inspired into a scripted gate — see section 18.

Pulses are latched, never sampled

Every evidence output — proto_err, role_err, dir_err, kind_err, sample_err, cap_err, accel_err, io_err, only_err, mis_err — is caught by a continuous always @(posedge clk) monitor into a sticky bit, asserted outside any conditional, in a window containing a clock edge.

Stimulus never lands on the active edge, and reset is released after it

step_clk is @(posedge clk); #1;, and reset release lands one delta after the edge — carried forward from the race 30.5 exposed.

Both builds are always instantiated

Every model has both its counting build and its shortcut build wired to the same stimulus. In eight of the ten, the shortcut build computes the honest figure internally and reports a different conclusion from it. The testbench asserts those internal figures on both builds, which is what makes "the data is identical and only the conclusion differs" a checked statement rather than a claim in prose.

Safety, liveness and performance kept apart

Safety-of-claim is this chapter's safety class. A family is never reported fully exercised while members remain untouched. A device is never read as memory-attach-only while it is in another role. An interface is never reported characterised from one direction. A capability that exists is never reported absent. None requires an assumption.

Liveness — nothing in this chapter is a liveness claim.

Performance — nothing here is a performance claim. The bottleneck model is about which limit binds, not about how fast anything is.

18. Baseline Defects Found Before Mutation

RTL defects — none. Testbench defects — none. Wrong oracles — none.

The ten models compiled clean and the testbench passed on its first run with 262 checks. Recorded with the caveat 30.7 earned: a green first run is evidence about the tests that existed at that moment, not about the models. The mutation campaign is what actually probed them, and it found five things the first run did not.

The reason for the clean run is the models' shape, not the author's care. These are combinational scoring models over a handful of booleans with two small registered counters each, and two carrying a single sticky bit. There are almost no timing relationships to get wrong — and every wrong oracle in batches 030 and 031 was a timing relationship.

Coverage gaps found by the structural gates

The seven outscan gaps have one shape and the fix is a teaching point. The weak build computes the same role count, the same direction pair, the same examples percentage, the same met count and the same fail mask as the honest one. Asserting them is what makes the chapter's central claim checkable.

The splitcheck hits are the 30.3 shape. A sub-count at exactly half its total is a state an inverted counter also reaches. Two further devices were driven — and after a first fix produced two of four, which is also half — two further workloads, until the splits are three of four and four of six.

Two new structural gates were built for this batch

Both close a class that batches 030 and 031 caught only by a manual sweep.

tools/xscan.py — output connectivity and X containment. Reports any declared output never assigned inside its own module — the defect 30.7 shipped: three outputs declared, counted into internal registers, never connected, X for the entire run with no -Wall warning.

tools/simwrite.py — simultaneous writes. Reports a register assigned by sibling statements that are not arms of one if/else chain — the shape batch 030 found five times by a manual sweep, after all three of its chapters had passed every gate.

Each ships with a positive and a negative control, and each was regression-run across every chapter of batches 030 to 032.

Both gates reported a false positive on their first run, and both are worth keeping.

xscan flagged module 'probe_sensitivity' declares output 'ports' — reading the words "the three counters ARE the output ports" out of a comment that 30.7 had written to explain the very defect the gate exists to catch. Comment stripping was added.

simwrite reported a reset arm and an else arm of one chain as independent, because end else if (…) begin closes and opens a block on one line and the scanner pushed before it popped; and later flagged a wrapped else if whose condition sits on a different line from its assignment. Both were caught by the negative control.

A gate that mis-flags correct code is a gate nobody runs, which is why both controls ship with the tools.

Compiler-warning findings

Under -Wall the ten models produce no truncation, select-width, signedness, cast, multiplication-width, shift-width or loop-width warnings. The only warning is a missing timescale on models with no delay constructs.

Four width results were reasoned rather than trusted.

• used_c × 100 and kinds_c × 100 are 8-bit by 32-bit products in a 32-bit context: maximum 255 × 100 = 25,500, and each is assigned to a 16-bit net only after a division that caps it at 100.
• family_size − used_c and kinds_total − kinds_c are 8-bit subtractions that cannot underflow, because the subtrahend is clamped to the minuend first. The clamps are load-bearing, not defensive: without them an over-range input wraps to 255 rather than saturating, and the campaign kills the mutations that remove them.
• samples_seen × 100 / 20 reaches 1,275, and the explicit clamp to 100 is what makes the published figure a percentage. The campaign killed the mutation that removes it only after the stimulus was extended past the clamp — at exactly 20 samples the clamp is a no-op.
• conditions_met × 100 / 4 and / 6 cannot exceed 100: the numerator is a sum of one-bit values over its own denominator. Documented in source as needing no clamp, and counted by hand.

Simulator constraints

Icarus Verilog 13.0 rejects ref task arguments, carried forward from every chapter in this module.

19. Mutation Testing

81 mutations attempted, 1 withdrawn as equivalent, 80 non-equivalent injected, 80 killed. Zero unexplained survivors.

Five survivors across the first runs, every one classified before anything was changed.

One equivalent mutant, and it is still bad code

The direction model writes its two seen-bits with a stated priority: a clear dominates, in an if/else chain. The mutation rewrote it as three independent statements with the clear last — and under non-blocking semantics the last write to a variable in a cycle wins, so the clear still dominates in every reachable state. No stimulus separates them, and it was withdrawn rather than chased.

The interesting part is that the mutant is still bad code. simwrite flags it correctly: three sibling statements assigning one register, with the intended priority expressed only by source order. It happens to be equivalent because the order happens to be the one the design wants — reorder those same three statements and the behaviour changes, which is the whole reason the priority belongs in an if/else chain rather than in a line ordering.

It was replaced by a mutation that reverses the order, making traffic outrank the window boundary, and that one dies on the simultaneous-event case.

Three were a distinguishing input the stimulus went past

The clamp case is the sharpest. The stimulus reached the clamp's boundary exactly, which is the one value at which a clamp and no clamp produce the same answer.

For every clamp, drive below it, exactly on it, and ABOVE it. For every conjunction, drive each term false with the others true. For every pair of independently-read inputs, drive a case where they differ.

One was a checker that did not look

The examples percentage was driven at sample counts of 4 and 3 — where a halved denominator gives a different answer — and was asserted only at 20, where both denominators clamp to 100. The state was reached; nothing looked at it there.

The classification rule

Never add an assertion for a survivor before classifying it.

20. Synthesis And Implementation Reality

These models are not meant to be synthesised, and saying so is part of the source discipline this chapter is subject to. What follows is the honest reading of what they would cost, because "that would be expensive" is an argument that gets made about instrumentation and it is worth knowing when it is true.

Every scoring model here is a handful of gates. A four-role decode is two wires and a concatenation. A parts-remaining count is an 8-bit subtraction with a clamp. The entire chapter, as hardware, is smaller than one entry of any queue in 30.6.

The three percentage models are the only arithmetic of any size. A multiply by 100 and a divide by a runtime value is a genuine divider — the one structure here that would not be free — and in a real design it would be replaced by publishing the numerator and the denominator and letting the reader divide. That is the same conclusion 30.5 reached about every ratio, arrived at here from the cost side rather than the honesty side.

The clamps are two comparators and a mux each, and they are not optional. Removing one turns an over-range input from a saturation into a wrap — 255 instead of 0 — and the campaign kills every mutation that removes one. A clamp that costs two gates and prevents a wrap from 0 to 255 is the cheapest correctness in the chapter.

The two sticky bits cost one flop each. They are what turn "which directions have we seen" from a question somebody has to remember into a register somebody can read, and the model makes the window explicitly re-initialisable so a second measurement does not inherit the first one's state.

The dual-build structure costs exactly double, and it is a verification cost rather than a design cost. No shipped design instantiates two versions of itself.

No area, frequency or power figures appear in this chapter, because none was measured and none would mean anything if it had been.

21. Silicon Observability

A platform can publish the evidence this chapter counts, and most of it is a register read rather than a new structure.

The second and the fifth are the two that change decisions. Two bits per device make a role census a query rather than a survey; a present-versus-used pair makes "nobody uses it" a statement about a fleet rather than about an interface.

Publish counts, not percentages — the same conclusion 30.5 reached about denominators, 30.8 about revision coverage, and 31.1 about device populations. "One of three members" is exact; "33 percent" is rounded, and only the first lets a reader compute a different ratio than the publisher chose.

One pattern is worth reading for. A fleet in which every device reports the same single role is either a genuinely homogeneous fleet or a fleet nobody has enumerated. The two are indistinguishable without the per-device bits, and the first is what everybody assumes.

22. DebugLabs

These labs debug decisions made from the misconception, using the structure the rest of the module uses to debug a design. The symptom is always a project that went wrong, and the root cause is always a sample read as a population.

Lab 1 — A platform specification has no row for the device in front of it

Symptom. An integration team receives a device that presents no memory and caches host lines. The platform specification has no configuration for it.

Evidence. The specification enumerates one device role. Every device the platform has shipped with is in that role.

Hypothesis. The role taxonomy was written from a device census rather than from the interface.

Investigation. Write the two capability questions down and enumerate the combinations. There are four; the specification covers one.

Root cause. A sample of one role read as the role set.

Fix. Enumerate the four roles in the specification, with a configuration path for each.

Prevention. A taxonomy is written from the questions, not from the examples. Two independent booleans give four answers whether or not you have met all four.

Observability. Presents-memory and caches-host as two readable bits per device. A role census becomes a query.

Lab 2 — A device-initiated path fails on its first customer

Symptom. A device works through qualification and fails at a customer the first time it initiates traffic toward the host.

Evidence. The verification plan has stimulus in one direction. Every test in the regression drives the host.

Hypothesis. The interface was characterised in one direction and assumed in the other.

Investigation. Count the directions the regression exercises. One.

Root cause. An interface described by the direction the team happened to build first.

Fix. Stimulus in both directions, and a coverage bin for each.

Prevention. Ask which direction a claim is about before accepting it. The other one is a different question with its own evidence.

Observability. Traffic counters per direction. Zero in one column is the whole diagnosis.

Lab 3 — More memory was bought and nothing got faster

Symptom. A capacity purchase produces no improvement in a workload that was described as memory-hungry.

Evidence. The workload's memory is not full. Its access latency has not moved.

Hypothesis. The limit that binds is not capacity.

Investigation. Instrument the three limits separately. The workload is waiting on ownership.

Root cause. "Needs memory" used as a diagnosis rather than as a symptom, and the wrong one of three limits addressed.

Fix. Name the binding limit before the purchase, and instrument all three.

Prevention. More memory answers exactly one of three limits. The other two look identical from a dashboard that only reports utilisation.

Observability. A per-workload limit indicator. One field turns a purchase into a decision.

Lab 4 — An architecture decision rested on a quarter of its own evidence space

Symptom. A platform architecture is committed on the strength of a twenty-device evaluation. A device category nobody evaluated arrives and does not fit.

Evidence. The evaluation report counts devices. It does not count categories.

Hypothesis. The sample was deep and narrow.

Investigation. Classify the twenty devices by kind. All twenty are one kind, of four.

Root cause. Effort measured instead of coverage — twenty of a nominal twenty is a hundred percent of a target somebody chose, and one of four is 25 percent of a space that exists.

Fix. Re-run the evaluation with one device from each kind, which is four devices rather than twenty.

Prevention. Count the kinds, not the examples. The coverage figure is the one with a denominator you did not pick.

Observability. None — this is a process artefact. Its output is a table with a row per kind and a tick per kind sampled.

Lab 5 — An interface specification says a capability does not exist

Symptom. A device legitimately uses a capability the platform specification says is absent. The platform rejects it.

Evidence. The specification was written from a fleet census. Nothing in the fleet used the capability.

Hypothesis. A deployment was read as a definition.

Investigation. Check the interface, not the fleet. The capability is present and was simply unused.

Root cause. Present-and-unused — the normal state of a general-purpose interface — recorded as absent.

Fix. Separate the two facts in the specification: what the interface provides, and what this deployment uses.

Prevention. Publish capability-present and capability-used as different fields. An under-report sounds modest and is still wrong.

Observability. The two fields per capability. Their difference is the set of things this fleet is not exercising.

Lab 6 — An accelerator was rejected for offering no capacity

Symptom. A device that would have benefited substantially is rejected in evaluation.

Evidence. The evaluation scored devices on presented capacity. The device presents none.

Hypothesis. The scoring criterion covers one of two benefit paths.

Investigation. Ask what the device does with host data. It holds working copies and needs ownership participation.

Root cause. A benefit test of the form "does it present memory" against a truth of the form "does it present memory or need ownership".

Fix. Score both paths.

Prevention. The device that presents nothing is the case the technology is most often built for. A criterion that excludes it excludes the headline application.

Observability. The two role bits again. A device reporting caches-host and not presents-memory is exactly this case, visible without an evaluation.

Lab 7 — A design review closed with the enumeration question open

Symptom. A device cannot be found by system software after integration. Every memory-related question in the review was answered thoroughly.

Evidence. The review minutes contain a long discussion of what the device presents and no discussion of how it is discovered.

Hypothesis. One answer was allowed to close two questions.

Investigation. Ask how the device is enumerated and configured. Nobody has an answer, and nobody noticed.

Root cause. "It is a memory device" treated as settling the design.

Fix. Two agenda rows, with two owners.

Prevention. This is the third chapter in two batches to find the same structural fact — 30.6 section 9 and 31.1 section 8 are the other two. Two independent questions do not collapse because one of them was answered.

Observability. An enumeration-answered bit per device, readable before bring-up.

Lab 8 — A strategy position survived three years of contrary evidence

Symptom. An organisation holds a scope position formed early. Devices that contradict it are treated as exceptions.

Evidence. Nobody has written the position down as a proposition with conditions.

Hypothesis. A sentence is being defended rather than a claim being tested.

Investigation. Write the four conditions the claim requires. Check them. Three hold; one does not, and it is the one that decides.

Root cause. A claim that was never turned into something checkable, so each counter-example was absorbed as a special case instead of counting against it.

Fix. The list, in the first meeting.

Prevention. For any sweeping claim, ask what would have to be true. It converts an argument into arithmetic and it takes about a minute.

Observability. The condition list itself. A scope claim with no condition list is 30.8's unbounded claim at organisational scale.

23. Coverage Reasoning

Coverage of an argument has the same failure mode as coverage of a design: it measures what was considered, not whether anything was checked.

Four coverage models are worth keeping over any claim of this shape:

Kind coverage, not example coverage. A bin per category in the space, not per observation. The distinction is the chapter, and a plan that counts observations can reach 100 percent with one bin filled.

Role-combination coverage. Two independent booleans, four cells. The cells a single-role platform can never fill are three of the four, and that unreachability is the proof.

Direction coverage. A bin per direction, crossed with traffic present. The cell that a one-direction regression can never fill is the whole second column.

Condition coverage on the conjunction. Four conditions, and four cases with exactly one unmet. Section 15 shows five of six can be met and the conclusion still fail; a conjunction has no partial credit, and this model makes that checkable rather than asserted.

The bin the shortcut build cannot hit is the most valuable bin in any model. In section 7 it is "role 2 reported as not memory-attach". In section 11 it is "present and unused". In section 12 it is "presents nothing and benefits". Each is unreachable in the shortcut build and trivial in the counting one, which makes the coverage report a direct test of the review item.

24. How This Appears In Real Engineering

The misconception is not confined to conversation, and every failure in section 22 is a real class of project decision.

Platform specifications are written from device censuses, because a census is concrete and an interface enumeration is abstract, and the census is what the team has.

Verification plans acquire their directions from the order the team built things, and the direction built second gets its first real stimulus from a customer.

Capacity is the limit people have personally debugged, so it is the diagnosis that comes to mind, and dashboards that report utilisation make the other two limits look identical.

Evaluations count devices because devices are countable. Categories require somebody to define the space first, and defining it is the step that would have shown the sample was narrow.

Fleet censuses become interface definitions whenever the specification author's best available evidence is what is deployed.

Accelerators are scored on what they offer back, because that is the shape of a procurement form, and "what does it do with our data" does not have a field.

The enumeration question is answered by whoever asks it, and a review that spends its time on the interesting question does not always get to the boring one.

And the most durable form: an early sample is a strong prior, and every subsequent device that fits it strengthens the prior while every device that does not is filed as an exception. The belief and the evidence grow together.

25. Where The Misconception Comes From

It is worth being precise about why this belief is so stable, because "people generalise too fast" is not an explanation and is not useful in a review.

Every observation is true. The devices really did present memory. There is no false premise to correct, which is the normal way a belief gets fixed.

The first product category is the one that ships first, and the one that ships first is the one everybody meets. Order of availability becomes order of familiarity becomes an implicit definition.

The name of the product category leaks into the name of the technology. A part sold as a memory expander is described by what it is for, and the description attaches to the interface it uses.

Sampling problems do not announce themselves. There is no moment during the twentieth observation at which the narrowness becomes visible; the twentieth feels exactly like the first, only more certain.

The other roles are underrepresented in the material, not in the world. What gets written about is what motivates the technology commercially, and that is one of the four roles.

And the counter-example is unintuitive. "A device that presents no memory at all" sounds like a device that does nothing, and it takes a second sentence — it holds copies of host data — to become obviously real. A counter-example that needs two sentences loses to a belief that needs none.

26. Common Misconceptions

"CXL is only for memory." How many kinds have you seen? Twenty examples of one kind is one kind sampled.

"Every device I have met presents memory." True, and it is a fact about your sample. The set has a size and your evidence has a size.

"The family is what this device uses." Count the members, then count the ones this device touches. The difference is what the claim erases.

"There is one kind of device." Two independent questions give four roles. Three of the four are not memory attach.

"It is a memory technology." That is a claim about one direction. What does the other direction do?

"The workload needs memory." Which of the three limits binds? More memory answers exactly one of them.

"Nobody uses that capability, so it is not really there." That reads a deployment as a definition. Present-and-unused is the normal state of a general-purpose interface.

"It presents no memory, so it gains nothing." It gains on the other side. Ask what it does with host data.

"It is a memory device, so the attach question is settled." Every device raises the enumeration question. Answering one question does not remove the other.

"Most of the conditions hold." A conjunction has no partial credit. Three of four is false.

"I have only ever seen memory devices." That is bit 0, and it is worth one sixth of an argument about scope.

27. Interview And Design-Review Questions

The shape of the claim

1. What kind of claim is "only for memory"? A claim about the size of a set. The evidence usually offered is about membership, and membership does not bound a set.

2. What is the difference between examples and kinds? Examples count observations and rise with effort; kinds count categories in a space that exists independently. Only the second bounds what evidence supports.

3. Twenty devices, all of one category, in a space of four. What is your coverage? Twenty-five percent. The examples figure would read a hundred, and it is a measurement of effort rather than of the space.

4. Why is this harder to argue with than "CXL replaces PCIe"? Because no premise is false. Everything the believer observed is true, so correcting a premise cannot help — you have to correct the inference.

5. What single question deflates it fastest? How many kinds have you seen, and how many are there. Two numbers, and the second one is usually unknown to the speaker, which is itself the finding.

Members, roles and directions

6. A device uses one member of a three-member family. What does that tell you about the family? That the family has at least that member. The other two are in the interface and this device has no use for them.

7. What would "only" require in that count? That nothing is left when you subtract what this device uses — zero unused members, not one.

8. Name the two independent questions that give the four device roles. Does it present memory the host can address, and does it cache host memory it must keep coherent.

9. How many of the four roles are memory-attach-only? Exactly one. A reader who assumes that role is right a quarter of the time by construction.

10. What does enumerating the roles cost? Writing a two-by-two table. It is the cheapest refutation in the chapter and needs no argument at all.

11. Describe the two directions of access. Memory attach is the host reaching into the device; coherent caching is the device reaching into the host. They are opposite directions across the same link.

12. Why does a claim about one direction say nothing about the other? Because they are separate traffic classes with separate initiators. Observing one exercises the other not at all.

13. What must a measurement window support to be trustworthy? An explicit re-initialisation with a stated priority. If a clear can be survived by traffic arriving in the same cycle, the second measurement inherits the first one's state.

Limits and sampling

14. Name the three ways a workload runs out of something. Capacity, bandwidth, and ownership. They want more bytes, a wider path, and a shorter wait respectively.

15. How many of the three does more memory answer? One. That is why a memory-only reading leaves two thirds of the problem space unaddressed.

16. A workload is capacity-bound AND coherence-bound. Does more memory help? No. The binding constraint is the one that is not relieved, and adding bytes moves neither the ownership wait nor the answer.

17. Why is capacity the limit people reach for? It is the easiest to measure and the one most often hit first, so it is the one most engineers have personally debugged.

18. What makes a narrow sample invisible from the inside? Nothing about the twentieth observation is different from the first except confidence. The narrowness is a property of the space, and the space is not in the data.

19. State the general form of the sampling error. Effort is a numerator over a target you chose; coverage is a numerator over a space that exists. Reporting the first as the second is the error.

20. Which chapter in this module found the same error in a different setting? 30.5 section 7 — a ratio with no stated denominator is not a measurement. There the wrong divisor was busy time; here it is the number of examples.

Capabilities, accelerators and questions

21. A capability nobody in the fleet uses. Is it in the interface? Yes. Presence is a property of the interface and use is a property of the deployment, and they differ exactly when something is present and unused.

22. Which direction does that error go? It under-reports. That matters because an under-report sounds modest and defensible while being wrong, so it survives review better than an overclaim.

23. What should a specification publish about a capability? Both facts, separately: what the interface provides and what this deployment exercises.

24. A device presents no memory at all. Can it benefit? Yes, if it caches host memory and needs ownership participation. The benefit is on the other side of the interface.

25. Why is that the decisive counter-example? Because a claim that excludes it excludes the case the technology is most often built for. The misconception's blind spot is the headline application.

26. Write the benefit test correctly. Presents memory or needs ownership. The memory-only reading drops the second term and is wrong on exactly the cases that matter.

27. What question does every device raise, regardless of what it presents? How it is enumerated, configured and reached. A scope claim about memory does not answer it.

28. Why is a weak build that is right on non-memory devices worse than one that is wrong everywhere? Because its errors are concentrated on the devices it will actually meet. A failure distribution aligned with the population is worse than a uniform one.

Method and evidence

29. State the disciplined way to handle a sweeping claim. Write the conditions under which it would be true, then check them. The argument becomes arithmetic.

30. Give the four conditions for "only for memory". The family has one member, every device is in one role, every limit is capacity, and no capability falls outside the scope.

31. Three of the four hold. What follows? Nothing is established. A conjunction has no partial credit, and 75 percent of a conjunction is false.

32. Five of six sign-off conditions met — is the argument 83 percent sound? No. It is unsound, and the percentage describes how much work was done rather than how close the claim is.

33. What makes a mutation campaign invalid? A failing baseline. Every mutation then fails for the reason the baseline does, and the kill count is meaningless.

34. A mutation cannot be killed. Name the classes before you conclude "equivalent". Stimulus gap, missing checker, vacuous checker, a model that cannot express the experiment, a model that has not decided what it means, and dead code. Equivalent is the last resort, not the first reading.

35. This chapter withdrew one mutant as equivalent. Why was the mutated code still wrong? Because its correctness depended on non-blocking last-write-wins ordering rather than on a stated priority. Reorder the same three statements and the behaviour changes.

36. A clamp's mutation survives. What is the first thing to check? Whether the stimulus went past the clamp or stopped exactly on it. At the boundary a clamp and no clamp give the same answer.

37. Name the three stimulus rules this chapter's survivors produced. Drive above a clamp as well as on it; drive each conjunction term false with the others true; drive a case where two independently-read inputs differ.

38. -Wall is clean. What has that proved about connectivity? Nothing. An output declared, counted into an internal register and never connected produces no warning and is X for the whole run.

39. What catches that defect? Explicit X/Z rejection in the checker, and — since this batch — a scripted gate that reports any output never assigned inside its own module.

40. Why does a new checker need a negative control? Because a gate that mis-flags correct code is a gate nobody runs. Both gates added this batch reported a false positive on their first run and were fixed by their controls.

41. What did the output-connectivity gate report on its very first run? A hit on the word ports, read out of a comment explaining the defect the gate exists to catch. It was not stripping comments.

42. What does a counter sitting at exactly half its total tell you? That an inverted counter reaches the same number, so the inversion mutation is unkillable at that assertion site. Drive one more case in either direction.

43. Why publish counts rather than percentages? "One of three members" is exact and lets a reader compute their own ratio; a percentage has already chosen the denominator for them.

44. What is the one telemetry field that turns a role survey into a query? Presents-memory and caches-host as two readable bits per device.

45. What would you say to a colleague who states the misconception? Give the structure, not the contradiction: two independent questions, four roles, two directions, three limits. The structure is more interesting than the correction.

46. State the single question this chapter turns on. How many kinds have you seen, and how many does the family have?

28. Exercises

1 — Analysis · Foundation. Builds: separating a sample from a population. Take the sentence "CXL is only for memory". Bounded scope: write the four conditions that would have to be true for it to hold, mark each true or false, and write the one-sentence correction you would give a colleague. Hint: the correction should state the structure, not the contradiction.

2 — Architecture · Foundation. Builds: enumerating a space instead of sampling it. Write the two independent capability questions that generate the device roles. Bounded scope: draw the four-cell table, name a plausible device for each cell, and say which cell the misconception covers. Hint: three of the four cells are the refutation, and drawing them takes a minute.

3 — Design review · Intermediate. Builds: reading a claim for the direction it is about. You are given a platform document that describes the interface entirely in terms of host reads and writes to device memory. Bounded scope: list what the document does not say, name the traffic it never mentions, and write the two coverage bins that would have exposed the gap. Hint: an interface has two initiators.

4 — Analysis · Intermediate. Builds: choosing the denominator that bounds the claim. A team reports a device evaluation as "20 of 20 devices passed". Bounded scope: state what that number measures, state what it does not, define the coverage figure you would ask for instead, and compute both for a sample of 20 devices spanning 1 of 4 categories. Hint: one of the two denominators was chosen by the team.

5 — Debug · Advanced. Builds: separating a symptom from a diagnosis. A workload described as memory-hungry does not improve after a capacity increase. Bounded scope: name the three limits that could bind, give the one measurement that distinguishes each, and say which instrument you would add first and why. Hint: a utilisation dashboard makes two of the three look identical.

6 — Design · Advanced. Builds: making a deployment fact distinguishable from an interface fact. Specify the telemetry a platform should publish so that "nobody uses that capability" can never be mistaken for "the interface does not have it". Bounded scope: name the fields, say what each makes falsifiable, and identify which single field you would keep if area review cut the rest. Hint: the interesting state is the one where the two fields disagree.

7 — Architecture · Advanced. Builds: scoring both benefit paths. Write the evaluation criterion for whether a device benefits from a coherent attach. Bounded scope: give the criterion as a boolean expression, identify the input combination on which a presented-capacity-only criterion is wrong, and say why that combination is the important one. Hint: count the input combinations each expression is false on.

8 — Verification · Expert. Builds: testing an argument the way a campaign tests a model. Take a scope claim from your own field — "X is only for Y". Bounded scope: write it as a conjunction of conditions, construct the cases with exactly one condition unmet, identify the degenerate inputs at the edges of each condition, and state which case you would have skipped and what would have hidden behind it. Hint: this chapter's survivors lived at a clamp's exact boundary, in an unisolated conjunction term, and in two mask bits that never differed.

29. Summary

"Only" is a claim about the size of a set, and the evidence usually offered for it is a claim about membership. Membership does not bound a set.

Twenty examples of one kind is one kind sampled. Count the categories, not the observations — one of the two denominators was chosen by you and the other one exists.

Count the family's members, and the ones this device uses. The difference is what the claim erases, and "only" requires it to be zero.

Two independent questions give four device roles, and three of the four are not memory attach. Writing the table down is the whole refutation.

Memory attach and coherent caching are opposite directions across one link. A claim about one of them carries no information about the other.

A workload runs out of capacity, bandwidth or ownership, and more memory answers exactly one of the three.

A capability nobody uses is still in the interface. Present-and-unused is the normal state of anything general-purpose, and an under-report sounds modest while being wrong.

The device that presents no memory at all is the decisive counter-example — and it is the case the technology is most often built for, which makes the blind spot the headline application.

Every device raises the enumeration question, whatever it presents. Third chapter in two batches to find that two independent questions do not collapse.

Write down what would have to be true, then check it. The argument becomes arithmetic, and it takes about a minute.

A conjunction has no partial credit. Three of four is false, and so is five of six.

Six conditions, and "I have only ever seen memory devices" is one of them. A true observation, checked correctly, is 16 percent of an argument about scope.