Content deleted Content added
Line 15:
Most tool-supported DFT practiced in the industry today, at least for digital circuits, is predicated on a ''Structural test'' paradigm. Structural test makes no direct attempt to determine if the overall functionality of the circuit is correct. Instead, it tries to make sure that the circuit has been assembled correctly from some low-level building blocks as specified in a structural [[netlist]]. For example, are all specified [[logic gate]]s present, operating correctly, and connected correctly? The stipulation is that if the netlist is correct, and structural testing has confirmed the correct assembly of the circuit elements, then the circuit should be functioning correctly.
Note that this is very different from ''[[Acceptance test|
One benefit of the Structural paradigm is that test generation can focus on testing a limited number of relatively simple circuit elements rather than having to deal with an exponentially exploding multiplicity of functional [[State (computer science)|state]]s and state transitions. While the task of testing a single logic gate at a time sounds simple, there is an obstacle to overcome. For today’s highly complex designs, most gates are deeply embedded whereas the test equipment is only connected to the primary [[Input/output]]s (I/Os) and/or some physical test points. The embedded gates, hence, must be manipulated through intervening layers of logic. If the intervening logic contains state elements, then the issue of an exponentially exploding [[state space]] and state transition sequencing creates an [[Computational complexity theory|unsolvable problem]] for test generation. To simplify test generation, DFT addresses the accessibility problem by removing the need for complicated state transition sequences when trying to control and/or observe what’s happening at some internal circuit element.
| |||