BSDL is a subset of the very-high-speed-integrated-circuits (VHSIC) hardware description language (VHDL). The formal standard for BSDL is IEEE 1149.1, supplement B. For ASIC designer, the tool supplier probably has a BSDL file-creation tool.
Purchasers of a device/design that uses boundary scan should insist that the vendor supply them with the BSDL file(s). While there are many tools to assist the test engineer in the "reverse engineering" of BSDL files, the best and least painful method is to get the files from the device manufacturer or designer. The most commonly stated reason for the failure to successfully implement boundary scan is the lack of accurate BSDL files.
The preceding mistakes are generally easy to spot. Most companies with robust DFT processes avoid them. There are numerous, more subtle problems, though, which require a more in-depth analysis to spot and correct. Many arise from incomplete or inaccurate design documentation.
These problems can include mixed-logic-level scan chains, the use of initialization pins to implement boundary scan on a device, logical constraints, and non-boundary-scan device issues. There also are general BSDL errors. They can be boundary-scan register inversions or missequenced incorrect boundary-cell descriptions, missing package types, and errors in register length.
When scan devices using incompatible logic families are interconnected, designers must be careful (Fig. 5). The mixing of traditional 5-V logic signals with the newer logic families, such as 3.3 and 1.1 V, can lead to device electrical overstress. At a minimum it will result in the detection of incorrect logic states. This problem may seem like a contradiction to the previously stated rule that it's best to create a single scan chain. Yet, there are solutions that allow users to maintain a single logical-scan chain while mixing logic families.
The first solution is to develop a scan chain that groups similar logic family devices together. Next, allow higher voltage families to drive lower voltage families through resistor prescalers (Fig. 6). Finally, use level-shifter devices to deal with the transition from one logic family to another.
If designers are unable to provide a single scan chain, due to real estate or cost issues, then test pads should be provided at the beginning and end of each scan chain. This will allow the test engineer to interconnect the chains with suitable level-shifter devices provided in the test fixture.
Some designers have produced devices that can be placed in boundary-scan test mode by using special control pins. Problems with this approach occur if the exact usage of the control pin(s) isn't properly understood, or the designer hasn't provided a clear method to put the device into this mode.
There are devices that allow the test mode to be selected at any time. But, some require the control pin to be held in a given state during the actual power-up sequence. This can be difficult to implement in a test environment. The tester has no resources or access to hold a pin to a known state prior to the application of power to the unit under test (UUT). Often the test-mode pin is under the control of an on-board device. This causes problems if there's no easy method of forcing the on-board device to place the desired device into boundary-scan mode.
To deter this, the method for placing a device into boundary-scan mode should be clearly documented and verified using the actual UUT, if possible. Test-mode control pins should be made accessible via test pads. If necessary, post-test-process jumper pins must be used to ensure normal device operation in the field. Devices requiring power-on configuration pins or in-system reprogramming to implement boundary scan should be avoided.
Subtle problems can also crop up in the BSDL file, which sometimes doesn't accurately describe the device. Syntax errors, though easily dealt with by today's boundary-scan test-development tools, can still be found in BSDL files. The errors in question relate to missing or incorrect descriptions of the boundary-scan registers.
An example is the implementation of boundary-scan registers in an ASIC or VLSI device that results in swapped bit positions for bus groups, like address or data (Fig. 7). Such errors are incorrectly documented in the supplied BSDL file.
Another situation arises when the polarity of scan-register control cells is inverted. This results in the enable states being reversed.
Incorrect instruction-register length can occur. Even a single-cell difference can result in useless test patterns.
Reprints
