Diagnosing Scan Chain Faults via Image Comparison; Classifying Common Scan Chain Fault Types
Source: VLSI Test Principles and Architectures
Okay, let's take this gently—scan chains are often touted as the hero of testing, but here’s the hard truth: they actually account for almost half of all chip failures. That’s a huge chunk of our yield problem, so we really need to understand how to diagnose them properly. To do that, we need two clear concepts: the 'snapshot' and the 'observed' image. Think of the snapshot as what *should* be stored inside the flip-flops at a specific moment—it’s the internal logical state. The observed image is what actually comes out of the scan output pin when we shift the data back. See this bit? In a perfect, fault-free world, these two images are identical. What goes in logically matches what comes out physically. It’s a clean mirror. But hardware isn’t always perfect. When there’s a fault—like a stuck-at defect—it acts like a distortion element. It changes the bits as they propagate through the chain. So, the observed image you read at the end won’t match the snapshot you expected. That mismatch is our primary signal that something is wrong. Does that click? We aren't just looking for blocked shifts; we're comparing the intended state against the actual output. If they differ, we have a fault to hunt down. So, keep this tip on your board: Scan failures are common, and the way to catch them is by comparing the snapshot versus the observed image. That difference is where the diagnosis begins.
Okay, let's take this gently. A stuck-at fault inside the chain acts like a signal distortion element, so what we read out no longer matches what was actually stored. That gap is exactly what diagnosis chases. See this bit? The snapshot across q1 to q4 holds 1, 1, 0, 0, but the s-a-0 mark between q2 and q3 forces everything downstream to collapse. Shift it out through SO and the observed image comes back all zeros. Oh, that's clean evidence: one local defect wipes the whole bitstream. Does that click? It means a simple flush test flags a failure, yet pinning down the exact cell takes more care.
Okay, let's take this gently. When a scan chain misbehaves, the first job is sorting the failure into a model we can actually test against. This tree gives us that map. Every defect lands in one of two buckets: functional or timing. Does that split click? On the left, functional faults cover logic errors like stuck-at and bridging. The right side tracks flip-flop timing windows. A late input triggers a setup-time violation, which Meera notes often splits into slow-to-rise or slow-to-fall depending on transition strength. An early output change causes a hold-time violation. Oh, and that bottom line matters: any of these can be permanent or intermittent, showing up only when power gets noisy. Want to check that edge before we move on?
Okay, let's take this gently. A single defective flip-flop inside the chain distorts every bit passing through it, turning a known input into a distinct output signature. That signature is our clue. See the table? We push the same pattern in each time, but the observed syndrome changes completely based on the defect. Stuck-at faults flatten everything to all zeros or all ones. Oh, that's clean. The slow-to-rise and slow-to-fall rows are subtler; underlined bits mark where transitions failed to finish in one clock cycle. Does that click? A flush test won't pinpoint the exact location, but it reliably classifies the fault type. Want to check that edge?