An interface protects its data bus with ECC. A single upset flips the valid signal for one cycle. The receiver accepts a transfer that the sender never made, with whatever happened to be on the bus, and its ECC checks out perfectly, because the stale data was valid ECC-protected data. A one-bit error on a control wire did what no amount of data protection can prevent: it created a transaction out of nothing.
How do you protect the signals that decide whether a transfer happens at all?
The obvious protection targets the data, because data is wide and most bits are data. But the handful of control signals (valid, ready, last, the address, the transaction type) decide what the data means. A flip on valid invents or loses a transfer; on ready, makes a sender believe a word was taken when it was not; on last, merges or splits packets; on an address bit, writes the right data to the wrong place. Data codes cannot see any of these.
Technique | Protects | How |
|---|---|---|
Parity or check bits on control signals | Valid, ready, last, type, address | Each group of control signals carries its own parity (or is covered with the data by one code); the receiver checks before acting |
Redundant encoding of key signals | Valid and ready | Send a signal and its complement, or two copies; disagreement is an error |
Duplicated checkers | The checking logic itself | Two independent checkers compare results; a fault in one is detected by the disagreement |
Lockstep logic | Whole blocks | Two copies run the same inputs in step; outputs are compared every cycle |
Watchdogs and protocol monitors | Protocol state | Detect impossible sequences (a transfer with no request, a response with an unknown tag) |
In systems where a hardware fault could cause harm (cars, industrial control, medical devices), standards such as ISO 26262 set targets for how many faults the hardware must detect or control. Integrity levels run from ASIL A to ASIL D; for ASIL D, the single-point fault metric must reach at least 99%: of the faults that could directly cause a violation, at least 99% must be covered by a safety mechanism. Interface protection, duplicated checkers and lockstep are the hardware mechanisms that earn that coverage; the coverage itself is shown with fault-injection campaigns (the UVM course covers those).
Where | Protection |
|---|---|
Safety-rated interconnects and processors | Parity or ECC on control and address as well as data, duplicated or lockstep logic, and protocol monitors. |
Standard interfaces | Optional parity or check signals on control in some protocol versions; otherwise added around the interface by the integrator. |
The opening interface (illustrative) had ECC on data but nothing on valid. Fault injection for a safety assessment showed that flips on valid, ready and last together were a large share of all dangerous faults, despite being only three wires. Adding parity on the control group, and a monitor that flagged transfers with no matching request, raised the coverage enough to meet the target.
last in a packet stream. What can go wrong?Two packets are merged into one, or one is split into two: the receiver's framing is wrong even though every data word is correct.
So that a fault in the checking logic itself is detected by disagreement between the two checkers, rather than silently disabling the protection.
Control signals decide whether, where and how many transfers happen; data codes cannot see their errors.
Protect control with parity or redundant encoding, monitor protocol state, and duplicate checkers where it matters.
Safety standards set coverage targets (for example 99% single-point fault coverage at ASIL D), shown by fault injection.