Uninitialized data and check bits are untrusted, not a guaranteed mismatch: their power-up values may accidentally form a valid codeword. For example, all-zero data and check bits pass the even-parity and SECDED schemes described here. A clean syndrome therefore does not prove initialization. Either initialize data and check bits together, track per-line validity independently of the syndrome, or block reads until software/hardware has written the location.
No. Protection checks codeword consistency, not write history. If the interface requires initialized contents, independent line validity or the initialization gate must still block that read, even though no ECC error is detected.
Integration work: implement line validity, the frozen 39-bit layout, response-aligned reporting, address-atomic partial writes and bounded scrub arbitration. The table below is the test plan. Transient read-path XOR tests the decoder but leaves storage unchanged. Persistent corruption must alter the stored codeword once, so it needs a second, test-only path: a raw-codeword write that bypasses the encoder (locked in production) or a backdoor/MBIST write. The read-path XOR is for transient decoder tests only. After the corruption, disable injection, run repair, then reread actual storage with injection still off to prove repair.
Read the picture from the top: the two test paths touch different places, so they test different things.
Read-path XOR: tests the decoder and reporting. Turn the mask off and the next read is clean, because storage never changed.
Raw-codeword write: tests repair. The bad word stays in storage until a scrub or write fixes it, so a reread with injection off proves the repair.
Planned harness phase | Stimulus and independent check |
|---|---|
Initialization | Hold reads blocked after reset, including an unwritten all-zero codeword; initialize data+ECC then permit reads |
39-bit decoder coverage | For known data, inject each of 39 single masks and all 741 distinct pairs; expect original data+CE for singles, UE/poison for pairs; keep an independent golden word |
Persistent repair | Corrupt stored position 5 once through the raw-codeword write bypass, read CE, scrub/rewrite under address ownership, remove all masks, reread stored 39 bits: clean syndrome and golden data |
Partial write/collision | After stored CE, merge selected golden bytes; race functional write versus scrub at same address; final storage must contain newer functional data with matching ECC |
Reporting/backpressure | Pipeline A/B, corrupt A, stall response: first address=A and exactly one event/count; check saturating counter and CSR set/clear collision |
Test | Expected result |
|---|---|
Flip each data bit | Every location yields a CE and corrected data |
Flip each check bit | Correct classification; data unchanged where appropriate |
Flip every pair in a small codeword | UE, never silent correction |
Partial write after CE | Correct old word, merge bytes, store clean codeword |
Scrub collision | No lost functional access or stale rewrite |
Repeated address faults | Diagnostic capture and repair/retirement escalation |
Keep the transient injection XOR after storage and before decode so production encoding is unchanged; keep any raw-codeword write bypass test-only and locked in production.
Protect injection controls from accidental software access.
Verify sticky flags, counters, first-error capture, and clear semantics through the CSR interface.
Hand off memory instance mapping, protection width, repair pins, MBIST ownership, and power/reset behavior.
A double-bit error that the decoder miscorrects and returns as valid data. Exhaustive pair injection on a reduced-width configuration is a strong way to expose it.
The integration items and test tables on this page are a plan. They have not been run against a final SRAM and harness.