Although built-in tests and diagnostics have replaced some traditional test techniques, what happens when a board cannot be booted up to run the diagnostics? Do we dust off the microscope and look for shorts by eye? Throw away the board?
Nothing that drastic. Testing with boundary scan can provide a fast method of testing interconnects on densely populated SMT PCBs. Actually, boundary scan has become a preferred test method, especially when there is no other cost-effective way to test interconnects.
Designing a board with programmable gate arrays and microprocessors that are scannable can provide a relatively easy way to manipulate these devices through boundary scan. Usually just a few of these large devices will comprise most of the design which will, in turn, allow boundary scan test access to a great deal of the real estate on the board.
Boundary scan allows virtual pogo pins at practically every pin on a scannable device (Figure 1). This is more test-node access than we had before SMT.
Considerations
Once the decision to design with boundary scan has been made, a test tool must be considered. Initial cost, reliability, implementation time, support and reputation should all be considered when looking at boundary scan test packages.
How much development time can you afford? Will you be using boundary scan for more than one design? What is your budget? You may want to purchase a fully automated system, such as Victory from Teradyne, or a manual system, such as ASSET from Texas Instruments. You may even want to hire a consultant.
If you are ultimately responsible for the system, you may want to implement it yourself. You will never understand how the system works unless you perform or oversee the implementation. A consultant may get you up and running more quickly; but once they leave, you must be the expert.
What Do You Need?
Choose a boundary scan test system that supports a language you are familiar with, such as C++. The system should have the capability to apply tests in a binary vector format.
Make sure the system provides a method for recording or translating the tests from your language to their vector format.
In our case, we used ASSET, which comes with hardware and a software interface. It is not an automated system and most of the software tools do not lend themselves to a production environment.
ASSET does, however, support various C++ compilers, allowing you to develop your own tests. Also, ASSET translates tests written in C++ to Texas Instruments’ proprietary vector format.
Setting the Scene
Boundary scan is typically used to test a multitude of interconnections between scannable components. Although it is possible, boundary scan is usually not used for individual device operation tests; that is, flip-flops or logic gates.
Boundary scan tests are implemented serially and are not used for real-time testing. The main objective is to test all scannable interconnections quickly and accurately.
The boundary scan test system is initially unfamiliar with the design to be tested. The test system only clocks values through the scan ring as prescribed by the operator. In virtually all cases, it is unrealistic to perform this manually. A program must be written to perform these actions.
But even if a program were written line by line and, in the end, ran quickly, what if the design changes? What if a new design comes along? You’ll be back at square one—recoding the entire test line by line.
Automating boundary scan will reduce development time even when only one design is to be tested. A test can be written to dynamically accommodate board and device information producing the outputs needed to evaluate the board.
The information you need to automate is, by and large, available. Schematic output files contain the devices and their interconnections.
The Boundary Scan Description Language (BSDL) files contain all the pin vs scan cell relationships. The BSDL files also contain control cells, enable values and other pertinent scan information needed for test. You know the types of interconnect tests that need to be performed. Now you need a test program to bring the hardware, software and test philosophies together.
Overall Plan
An ASCII netlist file from a schematic capture package is required for the test program. There are various netlist output formats, and a schematic capture package will typically support several types.
Choose an output format that is easiest to parse and supported within your company. The files may be large and cumbersome and, in some cases, may need to be broken into two or more parts. Use BSDL files which may be downloaded from the manufacturer or ordered through the mail.
Develop a structure set that can model the design to be tested. The structure set will model the scannable devices within the design, the pin vs cell information, cell addresses, cell types, cell states and all interconnections between scannable devices.
This will be done by creating a top level structure which points to the first device structure in the scan path. The device structure will contain a pointer reserved for the first pin of the device, represented as a pin structure. The pin structure will contain all pin vs cell information as well as pin pointers. Pin pointers are assigned to the next pin of the device and also point to an interconnecting pin structure from another device.
The structure sets will be dynamically allocated, allowing conformity to large or small designs. The structure set will expand to accommodate a larger design and shrink for a smaller one. This way, the structure set will support a design that has any number of scannable devices that have any number of pins with any number of interconnections to each other.
Various functions will be needed to support the reading, writing and traversing of the structure set. File names, file contents and devices will all contain the same reference designators, pin names and cell names; therefore, the code need not mention specific names.
The code will be driven solely by information contained within the files. The structure set will be the heart of the test program, a dynamic software model of the design tracking the address and state of each device, pin and cell where and whenever necessary.
Details
The test program can be split into several parts or steps. The first step will interpret all files, such as schematic capture and BSDL, and fill the dynamic structure set. This program will save the completed structure set, preferably in binary format, to save time and space and provide security (Program #1, Figure 2).
Once the binary file has been created, the original ASCII files are no longer required, unless the design changes. The binary file will now be the master file that contains a description of the design in terms of board layout, pin interconnects and boundary scan cell information.
A program may now be written to enact tests upon the master binary file (Program #2, Figure 2). The test structure’s scan cell state parameters will be set and used to exercise the board. The program should be written to perform a particular test, such as walking 0, on a generic device or bus.
The program will not know any information about what it is testing. The code will not refer to any specific device, pin or cell. It will simply conform to the rules of the particular test. A walking 0 from one device to another will set one interconnected output to 0 and all others to 1, repeating this procedure from the first interconnection to the last.
At this point, the structure’s state parameters are filled with values to test the board. This same philosophy can be implemented for a variety of tests and devices. The test is still completely dynamic and nonspecific. If a new design or a design change comes along, the same executable can be used to test the new design.
At this point, your C++ program will work, but typically will be rather slow due to the added software overhead. Each test goes through the test structure, then through ASSET’s proprietary data base.
We are now ready to translate our C++ program into the vector format. This translation will turn your tests into binary test vectors. ASSET provides an alternate direct method of applying these test vectors—a simple 1s and 0s bit blast.
The bit stream is applied to the hardware in seemingly random fashion. The program doesn’t know it is applying particular values to particular device cells. It simply applies and reads a serial stream. It would not be worthwhile to code by hand or even to read, which is why we created the C++ test program in the first place.
Now we are ready for speed. With ASSET, the vectors are recorded via the C++ test program. Our program took three hours to generate approximately 3,000 vectors with the C++ program (Program #2, Figure 2). Once the binary test vector format was recorded, the test was run from the next-level C++ program, which applied the binary vectors in 45 seconds (Program #3, Figure 2).
Now we have a test program which accurately tests the hardware as described by input files and runs quite fast. But there’s still more to consider.
Once the test has run, we need to know what happened. Outputs produced by boundary scan test systems vary and may be as cryptic as the vector format applied. A list that is impractical to read by eye is not acceptable and must be interpreted by a program.
When a failure occurs, you need to know what part and what pin failed. If you have to read the output file manually, it could take hours.
This is where the structure set is handy again. Remember that the structure set, as represented in the master binary file, is an exact model of the design. It contains all cell addresses, and the current state parameters can be used to store actual or expected values.
The output report file generated by applying the test vectors will also contain both the expected and the actual values. After rebuilding the structure set from the master binary file, the interpretation program will read the results file and fill in the state parameters of the structure set (Program #3, Figure 2).
The structure set can be declared and filled twice, once with the expected values and once with the actual values. These sets can be compared, returning the interpreted results to the calling program, which will report the results as required.
Wrap-Up
Boundary scan testing can be an efficient method of testing boards. Sometimes it may be the only way. To automate boundary scan tests, invest a little time and planning in getting the right tests implemented for your design.
Most importantly, remember to implement the scan tests so they are as close to 100% portable as possible. There is no reason to write code that specifies reference designators, bus names and pin or cell addresses.
Let the design output files and the BSDL files tell the code what to do. The benefits will be much greater if you write test code that lets the board design exercise the code, so the code can exercise the board.
About the Author
Rick Gadbois is the Senior Test Engineer at Siemens Medical Systems. He joined the company in 1987 and was a Test Supervisor until assuming his present position in 1990. He has a B.S. degree in computer science from Wentworth Institute of Technology. Siemens Medical Systems, 16 Electronics Ave., Danvers, MA 01923, (508) 750-7545.
Copyright 1995 Nelson Publishing Inc.
November 1995