You'll find it much easier to justify putting boundary-scan capabilities
into early versions of ASICs (application-specific ICs) and systems-on-a-chip (SOC) devices, rather than later versions. In the
late stages of development, ASIC and SOC projects tend to be expedited through the final stages of development so that a product
can be brought to market quickly. That's not the best time to apply design-for-test (DFT).
The best way to ensure that ASICs and SOCs include all the needed boundary-scan capabilities is to involve the people who
stand to gain from an effective implementation of boundary scan. Because of the versatility and flexibility of boundary scan,
many groups in an enterprise should have an interest in its implementation at the chip level. Such groups include prototype-board
debug engineers, board-test programmers, system-integrator personnel, and even field-service repair engineers.
The First Step
Back to top
The best first step is to gather together all of these groups, or representatives from them. The intent is to be able to come
to an agreement on the boundary-scan capabilities to be included in the device's requirements specifications.
As a first step, consider specifying all the optional public boundary-scan instructions such as IDCODE, RUNBIST,
CLAMP, HIGHZ, and others (refer to Boundary-Scan Testing—Part
1: An Introduction). Do that unless someone in the group can make a very strong case that a certain instruction will never be
used. If a case can be made that the instruction might possibly be needed sometime in the future, include the instruction in the
original requirements document to help avoid headaches down the line.
IDCODE, for example, will permit the identification of the device's manufacturer, as well as the artwork number and version
number. HIGHZ is important for on-board programming of flash memory, and to reduce problems caused by two or more active outputs
vying for a bus line (bus conflict). In addition, RUNBIST could be very valuable for board-level diagnosis in the future.
The optional test reset (TRST) control signal, discussed in Part 1
of this series, may be particularly critical later when boundary-scan tests are applied to your printed circuit board, or PCB. Some
engineers may be tempted to leave out TRST. That's because TRST is an optional active-low asynchronous reset signal, and
boundary-scan already includes a mandatory synchronous reset. It's achieved by holding the TMS signal at a Logic 1 and applying
five consecutive TCK (test clock cycles). However, the next article in our series will point out the value of the TRST
control signal during board test.
Check Your BSDL Files
Back to top
As your ASIC and/or SOC development progresses, the accuracy of your device's boundary-scan description language (BSDL) file must be
monitored continually. The slightest error in the BSDL file can disrupt board-level test-pattern generation processes and cause anomalous
or unpredictable test responses.
These responses can be very difficult to diagnose and troubleshoot. A faulty BSDL file can cause many problems that can be readily
avoided with just a modicum of attention to detail.
BSDL files should be checked both syntactically and semantically before they're ever used by a board-level test-pattern generating
system. If the BSDL file is inaccurate, the generated test patterns may be faulty.
When applied, faulty test patterns can mislead test engineers to the point where the test may indicate faults on the board when, in
fact, no faults are present. In any event, checking the accuracy of a BSDL file is too easy to ignore. Commercial checking services are
available from companies such as Asset InterTech and Agilent
Technologies.
The positive proof of the accuracy of a BSDL file comes when a conformance test for the 1149.1 boundary-scan specification is compiled.
This conformance test can be applied to the device on a chip tester or a PC-based boundary-scan tester to verify the accuracy of the BSDL
file.
Next
>>
