In short: X-masking gates unknown (X) logic values out of the scan-chain response before it reaches the compactor and MISR, so a single undefined bit cannot smear across the signature and destroy every test it touches.
Scan compression is wonderful right up to the moment an unknown value shows up. On a modern design with 50–200 scan chains feeding a single EDT (Embedded Deterministic Test) compactor, one X bit entering a space compactor can corrupt the observed response on dozens of chains at once. Feed that same X into a MISR (Multiple-Input Signature Register) and it pollutes the running signature for the rest of the pattern, turning a trustworthy pass/fail into garbage. X-masking is the discipline of identifying where those unknowns come from and blocking them before they can do damage. If you have not yet read how the compactor itself is built, start with our primer on scan compression and EDT.
Where do X values come from?
An X in ATPG is not noise on a scope. It is a logic value the test model cannot resolve to a known 0 or 1. The usual suspects:
- Uninitialized memories and black boxes — read data from an SRAM or a hard macro with no scan model drives X into the fabric.
- Non-scan flops and clock-gating latches that are not controlled during the capture window.
- Bus contention and floating nets — multiple drivers, or a tristate with no enabled driver.
- Analog/mixed-signal boundaries and asynchronous crossings that the structural model treats as indeterminate.
- Setup/hold-violating paths deliberately marked X to stay pessimistic.
These Xs are legitimate; the point of masking is not to make them disappear but to stop them from reaching the observation point unfiltered.
Why one X is a disaster in compression
In an uncompressed design each scan cell is observed on its own pin, so an X only loses the one bit it sits on. Compression changes the arithmetic. A space compactor is typically a tree of XOR gates: the identity X ⊕ anything = X means an unknown at any input forces the whole XOR output to X. With a 10:1 spatial compaction ratio, one bad chain blinds the other nine sharing that output.
Time compaction is worse. A MISR XORs each cycle's compacted response into a feedback shift register. Once an X enters the MISR it is shifted and fed back, so it contaminates the signature on every subsequent shift cycle. One X near the start of a long capture can invalidate the entire pattern.
A single unknown bit entering a 32-bit MISR can, within a few shift cycles, drive the entire signature to X — losing coverage for thousands of good scan cells that happened to share the compactor.
How X-masking actually works
The mask is a per-cycle, per-chain gating decision. Each chain's response passes through an AND gate (or equivalent) whose second input is a mask-enable signal. When the mask bit is 0 the chain output is forced to a constant (0) so the X never reaches the XOR tree; when it is 1 the real response flows through. The control is itself compressed — a dedicated mask-control chain or an LFSR-driven decoder generates the mask pattern so you are not paying one tester channel per scan chain.
Vendors implement this with named blocks: Siemens Tessent uses an X-blocking / observe-mask network inside its EDT logic; Synopsys DFTMAX and TestMAX call it X-tolerant compression with a masking register; Cadence Modus offers XOR-compactor masking tied to its sequential compression. In every case ATPG computes the mask offline: it knows from the fault-model simulation which cells carry X on a given pattern and sets the mask to block exactly those while leaving observable faults visible.
Masking versus X-tolerance — two philosophies
| Approach | Mechanism | Cost | Risk |
|---|---|---|---|
| Dynamic X-masking | Per-pattern mask control blocks X chains | Mask control bits add to pattern volume | Over-masking hides real faults → coverage loss |
| X-tolerant compactor | Redundant XOR coding (e.g. finite-field) survives some X | Extra compactor logic / area | Limited X density tolerance |
| X-bounding (RTL/DFT) | Force known values at the X source | Extra gating logic + timing | None to compactor, but area/power |
Good flows combine all three: bound the worst offenders in RTL, use an X-tolerant compactor for residual low-density Xs, and apply dynamic masking for the rest. The goal is to keep the X-density — the fraction of scan cells carrying X per pattern — below what the compactor can absorb, usually a few percent.
Rule of thumb: if more than ~5–10% of your scan cells are X-sources on typical patterns, no amount of masking will save coverage — you must bound the X at the source in RTL/DFT instead.
Watch the animation: an X getting blocked
Practical pitfalls
Over-masking is the silent coverage killer. Because the mask is generated per pattern, an aggressive tool can mask a chain to kill an X and accidentally hide a real defect on a neighboring cell in the same cycle. Always track the delta between masked and unmasked fault coverage and investigate large gaps. Equally, forgetting to model an X-source (a late-arriving memory wrapper, say) lets Xs leak silently — your signatures mismatch on silicon even though simulation was clean. Teams building rigorous DFT sign-off flows, like those at Avecas design services, treat the X-source list as a first-class deliverable reviewed alongside the netlist.
For the deeper interaction between masking and diagnosis resolution, see our companion piece on X-sources and failure diagnosis, and browse the full DFT course catalogue for hands-on labs.
FAQ
Does X-masking reduce test coverage?
It can, if applied too aggressively. Masking a chain to remove an X also removes observability of any genuine fault on that chain in that cycle. A good ATPG flow masks the minimum set of cells and reports the coverage delta so you can bound the loss.
What is the difference between X-masking and X-tolerance?
Masking actively gates unknowns out before the compactor using control logic. X-tolerance builds a compactor (with redundant coding) that can survive a limited density of Xs without any masking. Most designs use both.
How do I know how many X-sources my design has?
Run ATPG with X-source analysis enabled (Tessent, TestMAX, or Modus all report it). The tool lists cells driven to X per pattern and the resulting X-density; aim to keep it within the compactor's tolerance.
Can I avoid masking by fixing RTL?
Partly. X-bounding at the source — gating memory outputs, initializing non-scan flops, resolving contention — eliminates Xs before they enter the fabric and is the most robust fix, but it costs area/power, so it is reserved for the worst offenders.
Want to run real X-masking experiments in Tessent and TestMAX on a live netlist? Our DFT track on CourseTron walks you from scan insertion to compression sign-off with industry EDA tools. For instructor-led cohorts see ChipXpert VLSI training.