For years, engineers have neglected the "design" part of design-for-test. DFT shouldn't be an afterthought and test engineers can take on some of the task.
Design for Testability (DFT) is comprised of two very important terms. "Testability" is a condition of a circuit that makes it possible, easy, and cost-effective to test and diagnose the circuit (unit) under test (UUT). There is a wide acceptance that such a characteristic should be part of electronics ICs, boards and systems, too. After all, without DFT, faults can go undetected, making them difficult to repair. For far too long, the "Design" part of DFT that has been neglected.
Clearly, the features needed for implementing DFT, such as controllability, observability and diagnosability must be incorporated into a design. DFT shouldn't be an afterthought or a redesign activity. Designers must purposely create testable circuits. DFT is, however, more problematic than it appears. Let's examine the hurdles and see what we can do to improve design activities for testability.
Over the last decade or so, and probably with greater frequency in the last few years, circuits have been equipped with boundary scan devices using JTAG ports that follow the IEEE-1149.1 standard. Often, designers pick components for their functionality without much concern for the testability they offer. When boundary scan features are available, test engineers (not wanting to look a gift horse in the mouth) accept it as a DFT triumph. In many situations, the existence of even a single boundary-scanned device, especially a microprocessor with hundreds of pins, goes a long way to provide board-level and even system-level testability.
Image courtesy of JTAG Technologies.
Despite their good fortune resulting from boundary scanned ICs, test, testability and DFT engineers may not be satisfied. Board and system tests are complex for two main reasons:
First, unlike IC test engineers, board and system test engineers don't have a simulation or fault simulation work station that can help them predict the responses to inputs anywhere in the circuit. This makes board-level functional tests as well as system-level tests (which are always functional) more complex. The test engineer needs to predict circuit behavior for both good and faulty aspects of the circuit. Moreover, engineers need to predict responses purely from the schematic, circuit functional description, and individual component specifications. This time consuming and error-prone process increases in complexity when DFT hasn't been integrated into the design.
Second, board and system test engineers also need to isolate faults to an economically feasible number of replacement parts. In other words, at the system level the tests need not only determine whether the system is faulty, but that its root cause is within a single replaceable subsystem (typically in 90% of the cases). At the board level, functional tests are required to isolate the fault to a small group of components (maybe to 2 components in 90% of the cases). Functional board test may be comprehensive in fault detection, but it is not the best way to isolate faults. For example, ICT (in-circuit test) can usually isolate the fault to a single component, and AOI (automatic optical inspection) can often find a bridging fault between two pins.
To Page 2: Testability analysis