Assume the same memory test passes at low traffic and fails under concurrent DMA. A training pass establishes the exercised calibration result, not all runtime command timing, supply integrity or traffic-dependent behaviour. Split hypotheses by the evidence each predicts before changing frequency or voltage.
Use the same data pattern, address range, temperature and failure definition for comparisons. Keep the memory contents and test setup controlled so a reduced error count does not silently mean reduced work.
Turn a training pass into a useful debugging experiment — worked trace
Illustrative isolated example; not measured silicon behaviour.
Experiment | Prediction if hypothesis holds | Evidence to retain |
|---|---|---|
Hold traffic fixed; inspect first failing command sequence | Command timing issue gives an illegal event relationship | Bank/row, command timestamps, active timing values |
Sweep offered traffic with fixed clocks | Load-correlated failure may track contention or operating conditions | Useful bytes, queue occupancy, error locations and supply/margin evidence |
Repeat the lane capture sweep | A margin hypothesis changes the measured pass window | Lane/rank, pass/fail taps, voltage and temperature |
Reduce frequency alone | Several hypotheses may improve | This is a discriminator only when correlated with more specific evidence |
No. It changes command timing, PHY margins and load-related behaviour together. Retain evidence that discriminates the hypotheses rather than assigning ownership from that one change.
Start from the symptom and collect evidence across the boundary it crosses. Boot failure suggests collecting the initialisation/training transcript; ECC reports need the reporting stage, syndrome and physical-address mapping; a throughput regression needs traffic and command profiles. These are investigation routes, not deterministic root-cause assignments.
A fault reported by one layer can originate elsewhere. Illegal scheduling can look like PHY failure, and incorrect memory attributes can look like corrupted memory. Preserve the original observation before changing timing or enabling retries that may hide it.
Controlled regression investigation
A repeatable workload reports 42 GB/s before a firmware change and 21 GB/s after. The numbers are illustrative observations at one unchanged measurement boundary, not a promised channel rate. Temperature, transfer size and address replay must be recorded.
Candidate | Compare | Discriminating experiment |
|---|---|---|
Changed address mapping | Physical-address decode and row-hit/conflict counts | Replay the same addresses with the old mapping only; measure command mix and latency. |
Changed refresh policy | Selected mode, recovery occupancy and rank availability | Restore the known-good supported mode only; never violate refresh requirements to gain bandwidth. |
QoS or traffic change | Per-class arrivals, queue occupancy and service | Hold traffic fixed and change the relevant policy; retain other classes' deadline/starvation checks. |
PHY/mode mismatch | Negotiated width/rate, mode registers and errors/retries where present | Compare the actual interface configuration with the same firmware intent; a training pass alone is insufficient. |
No. Request ordering, workload shape, competing traffic and page policy can also change that counter. Hold the replay and operating conditions fixed and isolate the mapping change while checking resulting commands and useful throughput.
Always collect: training log, mode registers, ECC counters, traffic replay.
Temperature correlation: compare margin measurements and error rates at controlled conditions; correlation does not identify the failing layer on its own.
Multi-channel: localise the affected channels, ranks, banks, lanes and addresses before ranking SI, power, device, controller, firmware and mapping hypotheses.