X-Blocking to Prevent X Propagation; X-Masking in Test Compression
Source: VLSI Test Principles and Architectures
Okay, let's take this gently—when we talk about test compression, one big headache is those 'X' values, or unknowns, sneaking into our compactors. If an X gets there, it messes up our signature and hides errors. So, how do we stop them? We don't just tolerate them; we block them right at the source. See this bit? During the design phase, we use special checkers to find where these X-generators are hiding. Once we spot a likely troublemaker, say a non-scan flip-flop, we insert control logic nearby. Think of it as putting a gatekeeper right where the problem starts, rather than waiting for it to cause chaos downstream. The most common tool here is a multiplexer, or MUX. In normal operation, it might pass data through, but during test mode, we switch it to select a safe, constant zero instead of that unpredictable X-source output. This simple swap ensures that only clean, known values travel down the path toward the compactor. Now, does that click? By forcing a constant value, we guarantee that no X reaches the compactor inputs. It’s a very direct approach. But remember, there’s a trade-off. Because we’re cutting off the signal path, any faults that could only have been seen *through* that blocked source are now invisible. We gain reliability, but we might lose some fault coverage. So, if you’re designing for high reliability and want to keep your compactor happy, blocking is your friend. Just keep an eye on those lost faults. If the cost is too high, you might need to add extra observation points earlier in the chain. But for now, the core idea is simple: intercept the unknown before it causes trouble. Nice—keep going. You’ve got the basic mechanism down. Block Xs before they reach the compactor. That’s the golden rule for this technique. Let’s make sure that sticks as we move forward.
Instead of letting unknown values corrupt the response compactor, X-blocking stops them upstream. It is a clean way to keep test responses readable. Does that click? See this bit? The X Source feeds an unknown into a multiplexer, while a constant 0 sits ready as a safe alternative. The select line decides which path passes through. During test, we steer it to 0, so no X ever reaches the compactor. Oh—that's clean. One catch: blocking here can hide faults that only propagate through this source, so we may add an observation point before the block to preserve coverage.
Okay, let's take this gently. When over a quarter of scan cycles carry unknown X values, blocking them at the source adds area and delay. X-masking offers a softer path: suppress the X right before compaction instead. Does that click? See those OR gates? Each Scan Out line meets a control bit from the Mask Controller. When the controller drives a logic 1, the gate forces the output high, hiding any X on that chain. The clean stream then feeds the Compactor. Oh, that's clean. The tradeoff is needing stored mask data, but we avoid the fault-coverage loss that hard blocking can cause. Nice, keep going.