PCIe Compliance & Test Hooks (PRBS, Margining, Error Injection)
← Back to: USB / PCIe / HDMI / MIPI — High-Speed I/O Index
Core idea
“Compliance & Test Hooks” turns PCIe bring-up and pre-compliance into a repeatable evidence pipeline: define callable hooks (loopback/PRBS/margining/error injection), standardize counters/windows/log schema, and prove stability, headroom, and recovery with auditable artifacts. The goal is not more tests—it’s consistent acceptance criteria that can be replayed and trusted across builds, labs, and teams.
Output format: evidence must include Test ID, config hash, window/reset policy, and raw artifacts.
H2-1 · Definition & Scope: “Compliance & Test Hooks”
Scope Contract (read this before the details)
What this page solves
Defines testable, scriptable hooks that turn PCIe bring-up and pre-compliance into
repeatable evidence (not “one-off lab screenshots”).
In-scope (allowed)
- Hook types (executable): loopback, PRBS/BERT, margining, error injection, observability (counters/log/trace).
- Hook landing zones (where they live): silicon/PHY, firmware, board access, fixture mapping, lab instruments & automation.
- Evidence outputs: run sheets, config hashes, structured logs, margin summaries, reproducible reports (thresholds as X/Y/Z placeholders).
Out-of-scope (not covered here)
- Clause-by-clause spec walkthroughs or full compliance item enumeration.
- Signal integrity fundamentals (impedance theory, return-path lectures, long SI derivations).
- Protocol “classroom” content (deep LTSSM/TLP/DLLP/AER explanations beyond what must be observed).
Links to sibling pages (to prevent overlap)
- Protocol/feature behavior & error semantics: Controller / Endpoint / Root Complex.
- Channel layout, SI budgets, equalization theory: PHY / SerDes (or Cross-Protocol SI).
- Component selection details: Retimer / Redriver, Switch / Bifurcation, Cabled PCIe / External Boxes.
Practical definition: a Hook must satisfy 4 dimensions
1) Control
· can trigger/sweep/inject
Enables an intentional action (e.g., enable loopback, select PRBS pattern, sweep EQ knob, inject a controlled disturbance).
2) Observe
· can measure without guessing
Exposes counters/events/trace signals that explain outcomes (error counts, retrain events, link stability windows, lane status).
3) Automate
· can be scripted & replayed
Uses stable interfaces (CLI/API/register sequences) to rerun exactly the same experiment across builds and environments.
4) Evidence
· produces auditable artifacts
Generates structured outputs: test ID, config hash, environment tags, run duration, pass criteria placeholders (X/Y/Z), and reports.
Diagram: “Hook is a connector” (DUT → Evidence)
H2-2 · Where Hooks Fit in the Lifecycle (Design → Bring-up → Pre-compliance → Lab)
Why lifecycle matters
Hooks are not consumed once. Each phase demands a different minimum closed loop, a different evidence artifact,
and a different gate to enter the next phase.
Phase invariant (never optional)
- Log schema: structured fields instead of free text.
- Config hash: the exact knob state that produced the result.
- Window policy: run duration and counter reset rules.
Phase A — Design Time (embed hooks before hardware regret)
Goal
Ensure every critical test can be controlled, observed, and replayed with evidence.
Must-have hooks
- Loopback enable & PRBS control paths (silicon/firmware).
- Counter readout with stable semantics (reset/window rules defined).
- Board access points (test pads/straps/clock inject where applicable).
- Automation interface (CLI/API/register scripts) + evidence folder structure.
Run recipe (minimum)
- Define hook inventory (what/where/how to invoke).
- Define log schema + config hash method.
- Define a baseline run sheet template (placeholders X/Y/Z).
Outputs (artifacts)
- Hook Inventory v1 (auditable list).
- Automation entrypoints (commands/API) & evidence layout.
- Board hook map (access points & ownership).
Gate (placeholder)
Hooks can be invoked and logged via script in under X minutes with a reproducible config hash.
Phase B — Bring-up (prove the physical link with a minimum closed loop)
Goal
Establish a baseline that separates “link physics” from “traffic/software variables”.
Must-have hooks
- Loopback mode(s) to bound what is proven.
- PRBS generator/checker with stable counter semantics.
- Link events & error counters (snapshot + reset policy).
Run recipe (minimum)
- Enable the chosen loopback and verify link stability over X minutes.
- Run PRBS for Y bits or Z minutes; record bit/error counts and environment tags.
- Archive evidence (log + config hash + counter snapshot).
Outputs (artifacts)
- Bring-up baseline report (loopback + PRBS + counters).
- Known-good config hash (“golden starting point”).
Gate (placeholder)
Link stays stable for X minutes and PRBS shows BER within X over Y bits under a recorded environment tag set.
Common pitfalls (bring-up)
- Counter windows are inconsistent (different reset times, different denominators).
- Loopback chosen bypasses the real channel element that fails later (connector/retimer/backplane).
- Evidence is not archived with config hash; reruns become non-comparable.
Phase C — Pre-compliance (measure headroom & prove recovery)
Goal
Convert pass/fail into measurable headroom and validate robust recovery, not just a clean eye.
Must-have hooks
- Margin knobs (Tx/Rx EQ controls) + a way to record the exact knob state.
- Error injection mechanism(s) + recovery observability (retrain counters, down/up timing).
- Structured logging for sweeps (test IDs, environment, worst-lane summary).
Run recipe (minimum)
- Single-variable margin sweep → identify worst lane (report as “worst-lane = Lx”).
- Hold worst-lane settings → run PRBS for a longer confidence window.
- Inject controlled errors → validate recovery timing and stability windows.
Gate (placeholder)
Demonstrated headroom across worst-lane and controlled recovery within X seconds, repeated across Y environment corners.
Phase D — Compliance Lab (turn results into acceptable evidence packages)
Goal
Make every run traceable and replayable so lab outcomes can be compared with pre-compliance data.
Must-have hooks
- Automation scripts that reproduce run sheets (no manual-only steps).
- Fixture & lane mapping table (ports, polarity, lane IDs).
- Evidence packaging rules (names, folders, metadata, config hashes).
Gate (placeholder)
A complete evidence pack exists for every test ID: logs + screenshots + matrix + config hash, with replay steps in X lines.
Diagram: Lifecycle timeline & deliverables (what to ship at each phase)
H2-3 · Hook Inventory: A Taxonomy You Can Audit
Why this inventory exists
A hook is only useful when it is auditable: it has a named entrypoint, stable observability semantics, scriptability,
and a clear evidence output. Without an inventory, results become non-comparable across builds, lanes, and labs.
Hook record template (use the same fields everywhere)
- Hook name: stable ID (example: PRBS_GEN).
- Landing zone: silicon / firmware / board / lab.
- Entrypoint: CLI/API/reg-seq/SCPI (placeholder).
- Proves: one sentence boundary (“what it proves / what it cannot”).
- Observe: counters/events/trace + window/reset policy.
- Evidence: log fields + report name + config hash.
- Phase mapping: Design / Bring-up / Pre-compliance / Lab.
Inventory strategy (keeps scope tight)
- List entrypoints, not theory: record “what can be invoked and logged”.
- Bind to gates: each hook should map to at least one lifecycle gate (baseline, BER confidence, margin headroom, recovery proof, evidence pack).
- Keep semantics stable: define counter windows and reset rules; avoid “looks good” screenshots without denominators.
Hook inventory (by landing zone)
Use one accordion per layer to prevent mobile overflow and keep scanning fast.
Silicon / PHY hooks (PRBS, loopback, EQ knobs, lane control)
PRBS_GEN / PRBS_CHK
- Entrypoint: register/firmware API placeholder (pattern select + start/stop).
- Proves: physical error behavior with a defined denominator (not traffic stack behavior).
- Observe: bit_count, err_count, lane_id, window, reset_policy.
- Evidence: PRBS run log + config hash + environment tags.
LB_MODE_SET (loopback mode selector)
- Entrypoint: loopback mode ID (NE/FE × Digital/Analog) placeholder.
- Proves: stability within a bounded loopback boundary (not necessarily the full channel).
- Observe: link_up_time, retrain_events, error_counters, temperature_tag.
- Evidence: loopback certificate (mode + window + counters + hash).
EQ_KNOBS (Tx/Rx knobs)
- Entrypoint: tx_swing / tx_deemph / rx_ctle / rx_dfe placeholders.
- Proves: enables controlled margin sweeps and reproducible worst-lane identification.
- Observe: knob_state export + per-lane status snapshot.
- Evidence: margin sweep log + worst_lane + config hash.
LANE_MAP (lane/polarity control)
- Entrypoint: lane_id map + polarity flags placeholders.
- Proves: prevents “good run on wrong lane mapping” confusion and supports fixture alignment.
- Evidence: lane map snapshot included in every evidence pack.
Firmware hooks (CLI/SDK, parameter export, structured logs)
CLI_API (script entrypoints)
- Entrypoint: commands for loopback/prbs/margin sweeps (names as placeholders).
- Observe: standard JSON-like fields printed to console/file (no free text only).
- Evidence: run logs saved with test_id + timestamp + config hash.
PARAM_EXPORT (training/config export)
- Goal: ensure the exact knob state can be recovered and compared.
- Observe: exported parameter set + version + build ID.
- Evidence: config hash derived from exported fields (placeholder list).
EVENT_SUB (events/counters subscription)
- Observe: link events (up/down/retrain) + error counters with window/reset policy.
- Evidence: periodic snapshots (t=0..N) to catch “looks fine but drifting”.
Board hooks (test pads, straps, MUX points, clock & power observability)
TEST_PADS (access points)
- Entrypoint: pad IDs and locations documented as a map (no ambiguity).
- Proves: enables measurement or injection without changing the channel unknowingly.
- Evidence: pad map included in evidence pack (revision-tagged).
STRAPS / MUX (mode forcing)
- Goal: force known test modes or route access paths deterministically.
- Evidence: strap/mux state recorded as tags in logs + config hash.
CLOCK_IN / POWER_SENSE
- Observe: clock source tags and power rails tags correlated with errors.
- Evidence: environment corner tags included in every run (placeholder format).
Lab hooks (fixture mapping, instrument control, automation)
FIXTURE_MAP (ports → lanes)
- Fields: port_id, lane_id, direction, polarity, revision tags (placeholders).
- Evidence: fixture map snapshot packaged with every test matrix run.
INSTR_CTRL (SCPI/automation)
- Goal: run sheets become scripts; scripts produce evidence packs automatically.
- Evidence: logs + screenshots + metadata saved under test_id with replay steps.
Diagram: Hook Map Matrix (types × layers)
H2-4 · Loopback Modes: What Each Loopback Proves (and what it cannot)
The core rule
Loopback is a boundary proof. It proves stability only inside the chosen boundary.
A “passing loopback” can still miss the element that fails later (connector, retimer, cable segment, or a different lane map).
Minimum evidence bundle (record these every time)
- Mode ID: NE/FE × Digital/Analog.
- Stability window: stable for X minutes (placeholder).
- Accounting: counters + window/reset policy (no ambiguity).
- Corner tags: temperature/voltage/topology tags (placeholders).
- Config hash: knob state snapshot for replay.
Loopback taxonomy (keep terms stable)
Two independent axes define a loopback boundary: Near vs Far and Digital vs Analog.
The same hardware can expose multiple loopbacks; the chosen mode must be recorded as Mode ID in evidence.
- Near-end: boundary closes on the local side; validates local path and immediate interface behavior.
- Far-end: boundary closes near the remote side; validates more of the channel chain.
- Digital: validates digital pipeline sections; can bypass analog channel segments depending on implementation.
- Analog: validates a more physical boundary; still must be checked for bypassed elements.
Loopback decision tree (Goal → Mode → Observe)
Goal 1 — establish a local baseline quickly
- Pick: Near-end + Digital (Mode ID placeholder).
- Observe: stability window, error counters, retrain events, config hash.
Goal 2 — validate more of the physical chain
- Pick: Far-end + Analog (Mode ID placeholder) when available.
- Observe: same evidence bundle + corner tags across temperature/voltage.
Goal 3 — rule out “bypassed element” false positives
- Pick: switch boundary (NE ↔ FE) and compare outcomes under the same window policy.
- Observe: element coverage tags (connector/retimer/cable segment flags as placeholders).
Common false positives (and the first accounting check)
- Bypassed element: loopback does not include the failing connector/retimer segment → switch boundary (NE↔FE) and rerun under same window policy.
- Window illusion: short windows miss tail events → extend stability window to X minutes and snapshot counters periodically.
- Counter semantics mismatch: different denominators/reset points → record reset policy + denominator fields in evidence.
- Environment mismatch: lab baseline not covering corners → rerun with temperature/voltage/topology tags captured.
Diagram: Loopback topology (NE/FE × Digital/Analog)
H2-5 · PRBS / BER: Patterns, Counters, Windows, and Evidence
What PRBS/BER is for (scope stays evidence-driven)
PRBS/BER is an evidence pipeline: a repeatable run produces comparable numbers across builds, lanes, and labs.
The goal is to separate channel behavior from stack behavior using a stable denominator and window semantics.
PRBS run hard definition
PRBS run = Pattern ID + Denominator + Window + Reset policy + Lane scope + Evidence pack.
Counter accounting (makes results comparable)
A BER number is only meaningful when numerator/denominator and window semantics are explicitly recorded.
Avoid free-text “looks good” notes without denominators.
Denominator
bit_count (or equivalent unit count) captured per lane and/or aggregate (scope must be stated).
Numerator
error_count with a declared definition (bit error / block error placeholder).
Window
Duration + sampling strategy: continuous vs segmented snapshots (policy placeholder).
Reset policy
When counters are cleared: run start / per-lane / manual (policy placeholder). No implicit resets.
Two mandatory declarations
- Lane scope: per-lane vs aggregate (must be stated).
- Pattern ID: PRBS7/9/15/31 (placeholder) and polarity if applicable.
Run strategy (Quick → Standard → Confidence)
Use tiered runs to move from sanity checks to replayable evidence. No numeric thresholds are required here; only structure.
Quick sanity
- Goal: detect obvious physical instability fast.
- Scope: single-lane focus + short window (placeholders).
- Evidence: minimal fields still captured (pattern, window, denom).
Standard evidence
- Goal: comparable per-lane BER with stable accounting.
- Scope: lane-by-lane + segmented snapshots + corner tags (placeholders).
- Evidence: logs contain reset policy + lane map + config hash.
Confidence build
- Goal: stability across corners and time.
- Scope: longer windows + repeated runs + environment variation (placeholders).
- Evidence: confidence field populated by run repetition metadata (placeholder).
PRBS Run Sheet template (field list only)
Treat this as the minimum evidence schema. Each run should be replayable and comparable without tribal knowledge.
- Test ID: unique run identifier (placeholder).
- Build tags: DUT silicon/board rev + firmware build (placeholders).
- Topology tags: lane count, retimer presence, cable/trace class (placeholders).
- Pattern: PRBS ID + polarity (placeholders).
- Lane scope: per-lane vs aggregate + lane map snapshot (placeholders).
- Window: duration + segmented/continuous policy (placeholders).
- Reset policy: when counters are cleared (placeholder).
- Counters: bit_count + error_count (placeholders).
- Result: BER (placeholder) and “confidence” metadata (placeholder).
- Artifacts: log filename(s), screenshot(s), config hash (placeholders).
Diagram: BERT evidence loop (window + denominator are first-class)
H2-6 · Margining: Turning “Pass/Fail” into “How Much Headroom”
Why margining is the most valuable pre-compliance work
Margining converts “it works” into measurable headroom. A repeatable sweep produces curves,
identifies the worst lane, and exposes sensitivity to temperature/voltage/topology tags (placeholders).
Margining hard definition
Margining = set knob → lock/train → PRBS run → collect counters → curve output → worst-lane attribution → evidence pack.
Margin dimensions (concept-level, evidence-oriented)
Only classify the controllable knobs here. Theory and deep SI derivations remain on sibling pages.
Tx family
swing / de-emphasis (placeholders) → sweep for curve output.
Rx family
CTLE / DFE knobs (placeholders) → correlate with worst-lane changes.
Timing / Voltage family
timing/phase and voltage-related offsets (concept placeholders) → document as part of replay bundle when used.
Margin playbook (Quick / Standard / Deep)
Each tier defines goal, knobs, method, and output. Use the same evidence accounting as PRBS/BER.
Quick
- Goal: estimate headroom direction quickly.
- Knobs: one primary knob family (Tx or Rx placeholder).
- Method: 1D sweep on worst-suspected lane (placeholder).
- Output: coarse curve + early worst-lane hint.
Standard
- Goal: repeatable curves per lane with stable accounting.
- Knobs: Tx or Rx family + one secondary knob (placeholder).
- Method: 1D then limited 2D sweep, lane-by-lane.
- Output: margin curves + worst-lane + replay bundle.
Deep
- Goal: sensitivity across corners and system combinations.
- Knobs: multi-family sweeps (Tx+Rx placeholders) with defined constraints.
- Method: system sweep with temperature/voltage/topology tags (placeholders).
- Output: worst-lane stability + corner sensitivity summary.
Common pitfalls (keep sweeps repeatable)
- Auto-training vs fixed knobs: training can mask the sweep boundary → record whether training is on/off and capture the final trained state in the evidence pack.
- Window too short: tail events are missed → use segmented snapshots and keep window policy identical across points.
- Aggregate-only reporting: worst lane can be hidden → always preserve per-lane results and worst-lane attribution.
- Unlabeled corners: curves become non-comparable → tag temperature/voltage/topology placeholders in every run.
Diagram: Margin sweep workflow (repeatable evidence loop)
H2-7 · Error Injection: Proving Recovery, Not Just Eye Quality
What error injection proves (recovery policy under controlled faults)
Many “link drops” are caused by recovery behavior (retrain/reset/backoff/state-machine) rather than pure signal integrity.
Error injection turns failures into controlled, repeatable experiments that validate robustness.
Hard definition (evidence-oriented)
Error injection = controllable fault + bounded safety + observable recovery KPIs + replayable report.
Injection taxonomy (concept-level, experiment-ready)
Classify injections by temporal shape and scope. Keep details device-agnostic and replayable.
Temporal shape
- Glitch: short disturbance → verifies no lock-up / no stuck state.
- Burst: clustered errors → verifies retry/backoff correctness.
- Sustained: persistent fault → verifies exit/degenerate path (placeholder).
Scope
- Lane disturb: single-lane vs multi-lane (placeholder) → isolates worst-lane behavior.
- Training disturb: perturb training/lock window → validates rollback and stable re-entry.
- Policy disturb: firmware recovery knobs (placeholder) → validates robustness policy, not eye quality.
Safety boundaries (must remain recoverable and non-destructive)
Every injection must be bounded. A run is invalid if it cannot return the system to a known-good baseline.
Recoverable
Post-injection must reach a stable state (link stable + counters controllable) within policy-defined windows (placeholders).
Rollbackable
Knob changes and scripts must have explicit undo steps; record a config hash before/after each run.
Non-destructive
Avoid injections that can cause permanent states (overstress/overheat). Keep injection within lab-safe bounds (placeholders).
Safety gate (checklist)
- Pre-check: baseline counters + config hash captured.
- Abort criteria: defined stop conditions (placeholder) to prevent runaway retries.
- Post-check: stable link + no re-flap within a declared window (placeholder).
Recovery KPIs (structure first, values later)
Treat KPIs as structured fields tied to a window and reset policy. Without those, recovery numbers are not comparable.
- Recovery attempts: retrain_count / reset_count (placeholders).
- Time to recover: down→up duration (placeholder, time base declared).
- Stability after recovery: re-flap within window (placeholder).
- Error accounting: error counters delta tied to reset policy (placeholder).
- Application impact tag: timeout / drop / degraded mode tag (placeholder).
Experiment card template (Goal / Inject / Observe / Pass criteria)
Use this four-line structure for every injection so results remain audit-ready.
Goal
What recovery behavior must be proven (placeholder).
Inject
Injection type + location + duration/budget (placeholders).
Observe
Recovery KPIs + window + reset policy recorded (placeholders).
Pass criteria
Recover within X; no re-flap within Y; counters stable within Z (placeholders).
Output artifact: Error Injection Report (template)
- Test ID + build tags + topology tags (placeholders).
- Baseline reference (PRBS run sheet placeholder).
- Inject recipe (type/location/budget placeholders).
- Observe schema (KPIs + window + reset policy placeholders).
- Result summary + conclusion (placeholders).
- Evidence links (logs/screens/config hash placeholders).
Diagram: Injection points (validate recovery KPIs)
H2-8 · Observability: Counters, Event Tracing, and a Log Schema That Prevents Self-Deception
Logging contract (structure beats free-text)
Strong observability is defined by what must be recorded, not by how many tests are executed.
A unified schema prevents “looks passed” conclusions caused by window/denominator/reset mismatches.
Hard definition
Observability = counters + events + timestamps + schema + normalization + report.
Required counters (category + accounting rules)
Each counter category must declare window, reset policy, and scope (per-lane vs aggregate).
State counters
link_up_count / link_down_count (placeholders) + timestamped transitions.
Recovery counters
retrain_count / reset_count / fallback_count (placeholders) tied to the same window policy.
Error counters
error_counter family (bit/block/packet placeholders) with explicit denominator semantics.
Timestamp discipline (the minimum that makes deltas honest)
- Time base: declare the clock source used for timestamps (placeholder).
- Windowing: continuous vs segmented snapshots (policy placeholder).
- Reset alignment: log counter resets explicitly; otherwise deltas are ambiguous.
Logging Contract (field list)
Prefer structured fields. Free-text is allowed only as a brief annotation; it must not replace required fields.
Must-have fields (missing any → not comparable)
- Test ID (unique) + run timestamp.
- Config hash (before/after) + knob summary (placeholders).
- Window policy + reset policy (placeholders).
- Lane scope (per-lane vs aggregate) + lane map snapshot.
- Build tags (silicon/board/firmware placeholders).
- Result summary with denominator semantics (placeholders).
Recommended fields (accelerates attribution)
- Environment tags (temperature/voltage placeholders).
- Topology tags (retimer presence, cable/trace class placeholders).
- Event trace (link state transitions + recovery events placeholders).
- Artifacts (log filenames/screenshots/script revision placeholders).
Forbidden patterns (create self-deception)
- Free text replaces structure: “passed” without window/denominator/reset policy.
- Mixed endpoints: combining counters from different endpoints/lane maps into one conclusion.
- Hidden resets: counters cleared without a logged reset timestamp.
- Window mismatch: comparing runs with different snapshot policies as if identical.
Diagram: Observability data path (normalize before reporting)
H2-9 · Lab Setup & Instrument Control (Pre-compliance Friendly)
Scope: interfaces and integration, not instrument shopping
The goal is to connect hooks to a lab loop: data path for measurement and
control path for automation and evidence capture. Details such as brand/model selection and deep SI methods are out of scope.
In-scope
- Minimum lab loop: pattern/check + trigger + capture + environment tags.
- Fixture/lane mapping sanity checks (no large tables).
- Scripted control (SCPI/SDK/CLI) + evidence naming and archiving.
Out-of-scope
- Brand/model recommendations and procurement checklists.
- Full SI measurement theory or compliance clause-by-clause details.
- Fixture mechanical design deep-dives (only integration reminders).
Setup tiers: Minimum vs Nice-to-have
Define lab gear by closed-loop capability and evidence export, not by model lists.
Minimum Setup (must close the loop)
- Pattern + check: counters exportable; run metadata capturable (placeholders).
- Trigger / sync: aligns capture with link events (placeholders).
- Capture: minimum evidence artifacts (screenshots/files) with names (placeholders).
- Environment tags: temperature/voltage/load recorded (placeholders).
Nice-to-have Setup (improves repeatability)
- Automation runner: runs a test matrix and writes a manifest (placeholders).
- Config snapshots: instrument profiles + script revision recorded.
- Artifact packager: bundles logs/plots/screens into a single evidence package.
- Normalization: enforces schema/window/reset alignment before reporting.
Pre-flight checks (prevent measuring the wrong thing)
Before any long run, lock down mapping and sanity evidence so later reports remain comparable and auditable.
Mapping snapshot (fixture + lane) — keep it structured
Record a compact mapping snapshot as a field list (avoid wide tables):
- Fixture mapping: instrument channel → fixture port (placeholders).
- Lane mapping: logical lane → physical lane + polarity/orientation note (placeholder reminder).
- Scope tagging: per-lane vs aggregate scope declared (placeholder).
Sanity run (short proof of correctness)
- Short loopback/PRBS: confirms the physical/control paths are wired as intended (placeholders).
- Counter reset alignment: reset timestamp is logged before the run starts (placeholder).
- Artifact capture: one screenshot + one counters dump stored with the run ID.
Evidence naming and archiving (keep it replayable)
Use deterministic filenames and a manifest so reports remain auditable:
- Run ID: unique and stable across tools (placeholder).
- Script revision: stored in every artifact header/manifest.
- Config hash: instrument profile + DUT knob snapshot (placeholders).
- File naming rule: <project>-<testid>-<timestamp>-<lane>-<env>-<rev> (placeholder).
Diagram: Instrument Integration Map (control path vs data path)
H2-10 · Compliance Workflow Mapping (From Hook → Evidence → Gate)
Goal: pass gates with auditable evidence, not just run tests
A compliance-friendly workflow treats hooks as inputs to gates. Each gate has defined inputs, outputs, and rollback paths.
Evidence must conform to the logging contract (schema/window/reset alignment placeholders).
Gate checklist (inputs → run → observe → outputs → rollback)
Use the same structure for every gate to prevent scope creep and ensure consistent evidence.
Gate 1 · Link stability (Loopback)
- Inputs: loopback hooks + mapping snapshot (placeholders).
- Run: minimal closed-loop proof run (placeholder duration).
- Observe: link up/down events + counters delta (window/reset placeholders).
- Outputs: loopback summary + artifacts (placeholders).
- Rollback: stop-the-line → re-check mapping + reset alignment.
Gate 2 · BER confidence (PRBS)
- Inputs: PRBS generator/checker + run sheet fields (placeholders).
- Run: per-lane then aggregate strategy (placeholder policy).
- Observe: bit count + error count + window semantics (placeholders).
- Outputs: PRBS run sheet + counters dump (placeholders).
- Rollback: if unstable, return to Gate 1 and verify scope/time base.
Gate 3 · Headroom (Margining)
- Inputs: margin knobs + training policy snapshot (placeholders).
- Run: sweep plan (quick/standard/deep placeholders).
- Observe: worst-lane + sensitivity tags (temp/voltage placeholders).
- Outputs: margin report + knob matrix (placeholders).
- Rollback: if training conflicts, pin policy and re-baseline Gate 2.
Gate 4 · Robustness (Error injection)
- Inputs: injection points + safety gate + KPI schema (placeholders).
- Run: controlled fault recipe with abort criteria (placeholders).
- Observe: retrain/reset counts + down→up timing + re-flap window (placeholders).
- Outputs: error injection report + artifacts (placeholders).
- Rollback: if runaway recovery occurs, stop-the-line → re-baseline Gate 1/2.
Gate 5 · Evidence package (logs / reports / manifest)
- Inputs: all gate reports + artifacts + schema contract (placeholders).
- Run: packager produces a bundle + manifest file (placeholders).
- Observe: cross-run comparability checks (window/reset alignment placeholders).
- Outputs: evidence bundle with deterministic naming + config hashes.
- Rollback: missing fields → mark bundle invalid and re-run the failing gate.
Diagram: Gate pipeline (Hook → Run → Observe → Report → Decision)
H2-11 · Engineering Checklist (Design → Bring-up → Production)
Purpose: turn “hooks” into a repeatable SOP that produces auditable evidence.
Each item is written as Action + Evidence & Pass (threshold placeholders), so results remain comparable across builds and teams.
Design checklist (hooks must exist before bring-up)
-
Action: freeze a Hook Inventory that names every callable hook (loopback / PRBS / margin / inject / counters).
Evidence & Pass: inventory file + owner + version tag; pass if required hook types covered (X of Y) and review signed. -
Action: guarantee a scriptable control path (CLI/SDK/register map) for every knob that will be swept.
Evidence & Pass: “one-command” dump of config snapshot; pass if config can be applied + exported reproducibly within X minutes. -
Action: define a counter window policy (denominator, duration, reset rules) before any testing begins.
Evidence & Pass: metric definition sheet; pass if two independent runs match within X% under same config hash. -
Action: require timebase alignment (timestamps, monotonic clock, event ordering) for logs and traces.
Evidence & Pass: log schema with timestamp fields; pass if event ordering remains consistent across collectors for ≥ X minutes. -
Action: reserve board-level hook points (test pads, straps, mux points, clock inject/sense, power sense).
Evidence & Pass: schematic hook map + bring-up access notes; pass if each hook is reachable without rework (X/Y accessible). -
Action: plan a fixture mapping that preserves lane mapping and avoids silent lane swaps.
Evidence & Pass: lane-map manifest; pass if lane identity checks match expectation (X mismatches allowed = 0). -
Action: add a config hash (firmware + registers + topology) into every report header.
Evidence & Pass: report template includes config hash; pass if any run missing hash is rejected (0 tolerated). -
Action: define gate ownership (who can declare pass/fail and who approves evidence package).
Evidence & Pass: RACI-style ownership row; pass if gate decision requires two roles (owner + reviewer). -
Action: choose reach-extension parts only after confirming required hook surfaces (automation, observability, lane control).
Evidence & Pass: feature checklist filled; example IC families to evaluate: TI DS160PT801, TI DS160PR810, TI DS320PR810, Broadcom PEX88T32 (verify hook coverage per build). -
Action: for fan-out topologies, require switch diagnostics and error containment hooks in the selection checklist.
Evidence & Pass: switch feature checklist filled; example parts: Broadcom PEX8796-AB80BI G, Broadcom PEX88096, Microchip Switchtec PFX (PM40100A-FEIP).
Bring-up checklist (minimal closed loop + baseline)
-
Action: run a minimal closed loop first (loopback → PRBS/BER → counters) before any tuning.
Evidence & Pass: baseline run folder; pass if link remains stable for X minutes and counters stay within X per window. -
Action: capture a golden baseline snapshot (register dump + topology + environment tags).
Evidence & Pass: snapshot + config hash; pass if re-apply reproduces results within X% BER delta. -
Action: validate counter reset correctness (no silent resets, no mixed epochs).
Evidence & Pass: reset-policy log; pass if denominators and durations match declared window (0 ambiguities). -
Action: establish minimum environment coverage early (temperature/power/load) to avoid false confidence.
Evidence & Pass: run matrix with tags; pass if coverage meets minimum grid (X temps × Y rails × Z load points). -
Action: enforce “stop-the-line on measurement ambiguity” (window mismatch, missing hash, missing tags).
Evidence & Pass: rejection log; pass if all accepted runs include required fields (100% compliance). -
Action: isolate failures by lane-by-lane runs before aggregate testing.
Evidence & Pass: per-lane summary; pass if worst-lane is identified and tracked across builds (1 worst-lane ID). -
Action: preserve raw artifacts (counters, logs, screenshots) as immutable evidence.
Evidence & Pass: artifact manifest; pass if every report row maps to raw files (X/Y mapped).
Production checklist (regression + traceability)
-
Action: lock a regression matrix aligned with gates (stability / BER / headroom / robustness / evidence).
Evidence & Pass: matrix version + run IDs; pass if all required rows executed per release (X/Y coverage). -
Action: maintain a golden configuration with explicit change control.
Evidence & Pass: golden snapshot + change log; pass if any delta requires approval and updates config hash. -
Action: archive exceptions with full reproduction recipe (no “free text only” failures).
Evidence & Pass: exception bundle (raw + recipe + environment); pass if reproduction succeeds within X attempts. -
Action: enforce traceability (firmware version, register snapshot, topology, environment, tool versions).
Evidence & Pass: evidence package manifest; pass if every report row is traceable end-to-end (100%). -
Action: require a rollback path when a gate fails (restore golden, re-run baseline, re-check counters).
Evidence & Pass: rollback checklist; pass if rollback reproduces baseline within X% of prior evidence.
Diagram: “Checklist Wheel” — each lifecycle stage must cover Hooks / Evidence / Repeatability / Ownership.
H2-12 · Applications & IC Selection (Hooks-first)
This section maps use-cases → required hooks → selection knobs without replacing any device-specific pages.
Focus: what evidence must exist, and what capabilities must be verified during selection (examples include concrete part numbers).
Use-case A · Long channel / backplane / cabled extension
The economic value comes from headroom: pass/fail is insufficient; margin trends and worst-lane sensitivity must be comparable across environments.
Required hooks
PRBS/BER
Margining
Counters
Config hash
Selection knobs (fields to verify)
- Automation surface: CLI/SDK/register control; snapshot export present (Y/N).
- Lane control: lane mapping/polarity/bypass controllable (Y/N).
- Observability: retrain and error counters readable with defined windows (Y/N).
- Evidence export: run manifests can be generated automatically (Y/N).
Example ICs to evaluate (reach extension): TI DS160PT801, TI DS160PR810, TI DS320PR810, Broadcom PEX88T32.
Use-case B · Multi-accelerator / storage fan-out
System failures are frequently dominated by recovery behavior and topology interactions; robustness must be proven with controlled injections and timeline evidence.
Required hooks
Error inject
Event trace
Retrain timeline
Gate reports
Selection knobs (fields to verify)
- Diagnostics: error containment / isolation hooks present (Y/N).
- Telemetry: per-port/per-lane counters accessible and timestamped (Y/N).
- Automation: evidence package generated from scripts without manual steps (Y/N).
- Topology control: partitioning / lane routing constraints exportable (Y/N).
Example switch parts to evaluate: Broadcom PEX8796-AB80BI G, Broadcom PEX88096, Microchip Switchtec PFX (PM40100A-FEIP / PM40084A-FEIP).
Use-case C · Rugged / thermal systems
Temperature and power excursions convert “marginal” into “intermittent”; evidence must carry environment tags and identify worst-case corners.
Required hooks
Env tags
PRBS/BER
Margin curves
Worst-lane
Selection knobs (fields to verify)
- Evidence schema includes temperature/rail/load tags (Y/N).
- Counter windows remain valid across throttling or retrains (Y/N).
- Automation captures corner metadata without manual edits (Y/N).
- Configuration export includes thermal/power policy knobs (Y/N).
Example reach parts to evaluate under corners: TI DS160PT801, Broadcom PEX88T32 (plus system-specific retimers/redrivers).
Feature checklist (fields for a comparison sheet)
- Margining: supported knobs + automation path (Y/N).
- Observability: counters/events + timestamping + reset policy (Y/N).
- Lane control: mapping/polarity/bypass + export/import (Y/N).
- Evidence export: manifest + raw artifacts + config hash (Y/N).
- Robustness: injection hooks + recovery timeline metrics (Y/N).
Diagram: Use-case → Hook mapping (stickers) to keep selection “hooks-first”.
Recommended topics you might also need
Request a Quote
H2-13 · FAQs (Field Debug & Acceptance, Hooks-Only)
Scope: close long-tail field debug and acceptance criteria without adding new domains.
Hard rule: each answer is exactly 4 lines — Likely cause / Quick check / Fix / Pass criteria (threshold placeholders).
Loopback passes but real traffic fails — first check what hook gap?
Likely cause: loopback bypassed a segment/state (connector/fixture/retimer mode) and observability for traffic-mode failures is missing.
Quick check: compare topology manifest + lane_map for loopback vs traffic; correlate retries/CRC with fifo_underrun and retrain_count in the same window_s.
Fix: add a traffic-mode hook run that exercises the full path; enable counters/events needed for traffic (underrun, retrain timeline); record config_hash + fixture_map.
Pass criteria: at throughput Y for X minutes, fifo_underrun=0, retrain_count ≤ X, and error counters remain within the declared window/reset policy.
PRBS BER is clean but apps see retries — counter window mismatch?
Likely cause: PRBS used a different denominator/window (or counter reset epoch) than app retry metrics; retries may be buffer/scheduling, not bit errors.
Quick check: verify PRBS report contains bit_count, error_count, window_s, and reset_policy; plot retries vs fifo_underrun and latency using the same timestamps.
Fix: standardize one reporting window for PRBS + app KPIs; log both layers under one Test ID and one config_hash with explicit window/reset policy.
Pass criteria: within window X, PRBS BER ≤ X and app retry_rate ≤ Y per defined denominator; no ambiguous reset/epoch mixing.
Margin sweep looks “good” once, but not reproducible — which variable is uncontrolled?
Likely cause: an uncontrolled variable (auto-training policy, temperature, rail droop, cable/fixture swap, background load) changed between runs.
Quick check: diff config_hash and training policy flags across runs; confirm env tags (temp_C, rail_V, load_state) exist and match; verify fixture/lane map unchanged.
Fix: freeze policy mode for compliance runs, lock the swept knob sequence, and capture env tags at start/end + on retrain events; reject runs missing tags/hashes.
Pass criteria: worst-lane margin stays within X steps across Y reruns under identical config hash + env tags; no hidden policy drift.
Only one lane fails margin — mapping/polarity or per-lane EQ state?
Likely cause: lane identity drift (mapping/polarity swap) or a lane retained a different EQ/training state than others.
Quick check: snapshot lane_id → physical pins mapping + polarity flags; read back per-lane knob states; run PRBS lane-by-lane with identical window/reset policy.
Fix: correct mapping/polarity in topology manifest; reset per-lane EQ state to a known baseline; re-run sweep with per-lane evidence files named by lane_id.
Pass criteria: 0 lane_id mismatches between manifests and readbacks; worst-lane meets margin target X and stays stable across Y reruns.
Retimer hides issues — how to design a test that exposes the raw channel?
Likely cause: re-timing masks the raw segment’s weaknesses, so “system pass” provides no evidence about the native channel headroom.
Quick check: run an A/B matrix: with retimer vs bypass/short path (or transparent mode) using identical PRBS pattern, duration, and evidence schema.
Fix: add a “segment exposure” recipe: test each segment separately (endpoint↔retimer, retimer↔connector/cable) and store per-segment evidence under one Test ID.
Pass criteria: raw segment evidence meets BER ≤ X (denominator ≥ Y bits) and the delta vs retimed run is explained and repeatable across reruns.
Error injection causes permanent down — recovery criteria too strict or missing rollback?
Likely cause: injection exceeded the safe boundary, recovery policy is too strict, or rollback hooks are absent/untested.
Quick check: confirm a bounded injection recipe exists (amplitude/duration/burst count) and logs include recovery_state, down_time_ms, and rollback_invoked.
Fix: add an abort + rollback path (restore golden config + re-run baseline); tighten injection scope and ensure recovery transitions are observable and timestamped.
Pass criteria: after injection, link recovers within X seconds, no re-flap for Y minutes, and rollback restores baseline within tolerance if recovery fails.
Errors correlate with temperature — where to log thermal state in the schema?
Likely cause: environment is not captured as structured fields, so the same “test” is actually different thermal/power corners.
Quick check: verify logs include structured temp_C, rail_V, throttle_state, and their timestamps aligned with link events and counter windows.
Fix: add periodic env sampling plus event-triggered snapshots (on retrain/down/up); embed env tags in every report row and evidence filename.
Pass criteria: 100% of runs include env tags at start/end + on key events; temperature-binned results reproduce within X across Y reruns.
Training parameters keep changing — firmware auto policy vs fixed compliance settings?
Likely cause: auto policy adapts parameters during the run, invalidating comparisons and making evidence non-repeatable.
Quick check: capture config_hash pre/post; diff policy mode flags and “effective settings” readback; check if changes correlate with retrain events.
Fix: define a fixed-policy mode for compliance/pre-compliance runs; record policy_version and export applied settings at run start and after retrain.
Pass criteria: 0 unexpected parameter changes within X-minute window (except declared retrain steps); all changes, if any, are logged with timestamps and reasons.
BER confidence questioned — duration/denominator not enough, what to report?
Likely cause: BER is reported without the denominator, window, and reset policy, so statistical confidence cannot be evaluated.
Quick check: confirm the report includes pattern, bit_count, error_count, duration_s, and notes any counter resets within the window.
Fix: extend duration and report a standard “run sheet” row for every lane/segment; include a confidence field placeholder derived from denominator/error count.
Pass criteria: denominator ≥ X bits, error_count ≤ Y, no mid-window resets, and the report contains a confidence placeholder plus raw artifact references.
Pre-compliance vs lab mismatch — evidence package missing what artifact?
Likely cause: the lab cannot reproduce the run because mapping, config, tools, or raw artifacts are missing or not traceable.
Quick check: validate the package includes config_hash, lane_map, fixture_map, tool_versions, raw counters/logs, and a recipe script ID.
Fix: enforce an evidence manifest (file list + hashes) and naming rules that bind every artifact to Test ID + config hash + environment tags.
Pass criteria: a second operator can replay the recipe and reproduce key metrics within X% using only the evidence package (no “tribal knowledge”).
Passing at low load, failing at full throughput — buffer/underrun masquerading as link errors?
Likely cause: throughput triggers buffer underrun/scheduler jitter; resulting retries/CRC look like SI but originate from the stack.
Quick check: align timestamps and correlate CRC/retry spikes with fifo_underrun, DMA backlog, and latency under the same window and reset policy.
Fix: increase buffering, reduce jitter sources, or throttle traffic; re-run PRBS and traffic-mode tests with identical evidence schema to separate channel from stack.
Pass criteria: at throughput Y for X minutes, fifo_underrun=0, retry/CRC remain within X per window, and link stability gate passes.
“Clean scope eye” but fails compliance — which hook proves this is not SI-only?
Likely cause: eye quality alone does not prove training stability, policy consistency, or recovery robustness; failures may be lifecycle/policy/evidence gaps.
Quick check: demand hooks that produce: margin report, retrain timeline, error injection recovery, and a complete evidence manifest under one config hash.
Fix: gate runs through stability → BER → headroom → robustness → evidence completeness; lock policy mode, standardize windows, and add rollback for injections.
Pass criteria: all gates pass with structured evidence: stable link for X minutes, denominator ≥ Y bits, worst-lane headroom ≥ X, and recovery within X seconds.
