In the past decade, IEEE 1149.1, or "JTAG," has become one of the mainstream design-for-testability (DFT) techniques. It has grown from an often discussed but seldom used concept into a primary test strategy for many new designs.
Boundary scan, an element of the JTAG specification, is enjoying a rise in popularity due to many factors. One of them is the increasing use of the ball-grid-array (BGA) and other high-density interconnect packages. Board designers have adopted boundary scan to provide test coverage for circuit nets that aren't accessible by conventional test probing.
Telecom and networking companies are routinely developing boards with net counts above 5000. That's the practical limit of commercial ATE systems available today. Boundary scan offers unlimited virtual test channels.
Also, in-system programmable (ISP) devices often use the test access port (TAP) defined by the 1149.1 standard. It gives system designers a built-in port to implement in-system programming.
Today, every major telecom, network, aerospace/defense, and VLSI device manufacturer uses boundary scan in their designs. This strategy offers high test coverage, reduces life cycle costs, and shortens time-to-market.
Designers incorporating boundary scan in ASIC/VLSI designs find a variety of tools for implementing the infrastructure in a relatively painless manner. For circuit board designers, though, there are fewer tools available and more opportunities to make mistakes. To avoid some obstacles, it's important to examine some of the common pitfalls made by boundary-scan pioneers, and note techniques for optimization in board designs.
The terms "boundary scan" and "scan" are used interchangeably to refer to the technique described in IEEE 1149.1. While there are many other types of scan-based design-for-test methodologies, the most prevalent today is the 1149.1 version. The term "scan device" refers to any device that incorporates boundary scan in the device's architecture.
Basic Mistakes To Avoid Common mistakes on board designs result when designers are unaware of boundary scan's benefits and they violate the testability rules. Some examples of these blunders are TAP signals tied to VCC or GND, the lack of test pads provided for TAP signals, TAP pins either not bussed or else improperly bussed, and the failure to provide boundary-scan description language (BSDL) files.In the first case , the designer has mistakenly tied the TAP pins—test data in (TDI), test data out (TDO), test mode select (TMS), and test clock (TCK)—to either a power rail or a ground bus (Fig. 1a). This mistake often occurs when there's a blanket design rule like "tie all unused pins to power/GND".
Because the TAP pins are tied directly to power or ground, there's no way to apply scan test patterns to the device. To prevent this, never tie unused signal pins to power or ground. If you're not sure about a pin's function, leave it alone, or tie it to power or ground via a resistor (Fig. 1b).
Another problem arises when there's no method for physically accessing the TAP pins. This is the case in any surface-mount package outline where the designer hasn't provided a test pad or test connector pin. Then, there's no convenient way to connect test stimulus/response hardware for conducting boundary-scan tests. To perform boundary-scan tests, it's necessary to provide a means for physical electrical access to the first TDI and last TDO pins in the scan chain, and TMS and TCK for the entire chain (Fig. 2).
Many of boundary scan's benefits can be derived even if only a single device in the board design has scan capability. The real power and attractiveness of boundary scan, though, is obtained when multiple scan devices on the board are connected in a single-scan chain (Fig. 2, again, and Fig. 3).
There are many reasons why this connection is the best. Only a single TDI and TDO net need a test pad/test connector. This will save circuit-board real estate, and reduce the number of tester channels required to support scan testing. Commercially available test-pattern generators are generally optimized for developing test patterns and diagnostic databases for a single-scan-chain topology. Using a single chain allows all of the nets associated with boundary-scan registers to update in parallel. This will help avoid glitches.
In spite of the single-scan chain's benefits, a few cases, like very-large board designs, might require multiple-chains. The sheer distance between devices and board density may not allow the TAP signals to connect by a single chain without violating other design considerations, such as noise coupling.
Another instance is a board in which the designer selected a multidrop technique. That will partition the board into multiple sections, with the scan chains isolated to each section. This is an advanced method, practiced by very skilled designers with vast experience in DFT techniques.
Cases where mixed logic levels preclude tying all of the devices into a single chain also necessitate multiple scan chains. This generally only happens in designs where a negative-voltage logic, such as emitter-coupled logic, is used with positive-voltage logic (i.e., TTL).
Circuits also become difficult if not impossible to use for boundary-scan testing if the board designer connected the scan devices incorrectly (Fig. 4). Common versions of this problem include all TDI signals tied together, rather than in a daisy chain of TDO to TDI, and TCK pins connected to an existing on-board clock signal source. To prevent these problems, connect the devices as shown in Figure 3.
Boundary scan is a powerful DFT technique. Still, if the BSDL files defining the implementation of scan registers for a given device aren't provided to those responsible for test generation and implementation, it cannot be used.
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.
Be wary of errors in the op-code attributes too. The 1149.1 standard specifies an op-code set that must be implemented. The values for each op code must be correct.
Failure to include a PINMAP for a device package is a problem. This often happens when a newer device package becomes available, but the BSDL file hasn't been updated to include it. Even if a PINMAP is included, the mapping is sometimes incorrect.
Incorrect usage of boundary-scan cells BC_x might also be a problem. Each of the various boundary-scan cells, described by the 1149.1 standard, has unique characteristics and usages. Some BSDL files have arbitrarily assigned BC-cell types that don't accurately represent the actual device.
TAP logic levels can be incorrectly stated. A case would be if "true is high" was stated while the device had implemented "true is low" logic levels.
These problems are important. The BDSL file is the key reference for all boundary-scan test generators to develop test patterns. Nonsyntactical errors result in test patterns that don't work. This is because of discrepancies between the actual and assumed device functions as described by the BSDL file.
BSDL file problems can be avoided by verifying the actual boundary-scan design during the checkout process. Device designers using manual methods for implementing boundary scan often overlook the more subtle aspects. Current versions of the leading design tools automatically and quickly place and connect boundary-scan registers, and create accurate BSDL files.
Many designs have non-scan device pins or nets that must be kept at a certain logic state. Such conditions are referred to as constraints. In many cases, the designer will enforce constraints by connecting the net/pin directly to the logic power supply or ground. In other cases, the normal operation of the board prevents a condition from arising (Fig. 8).
An example of a constraint is the use of separate read and write control signals. Such signals may both be false, or one may be true at a given moment, but both signals should never be asserted at the same time. In normal operation, these conditions will be met. But if the control signals are part of a boundary-scan register chain, then the test patterns may yield a state where both signals are asserted at the same time. In some cases, this will only result in an unknown logic state for the device(s) being controlled. Other times the board could be damaged.
To avoid this, a logical constraint must be imposed. It's the designer's responsibility to document such constraints. Today, many automated boundary-scan test-generation tools can understand logical constraints. A survey of test tools should include examination of their ability to deal with constraints.
Boundary scan is unlike traditional in-circuit test techniques. It doesn't rely on the tester's resources to overdrive a net to a desired state. By using the boundary-scan cells as virtual test channels, the state of every accessible net can be monitored, and in most cases placed at a known state. Virtual-interconnect test patterns provide verification of the integrity of nets that have boundary-scan cells associated with them. During such tests the nets and non-boundary-scan parts on the nets will be subjected to a variety of patterns. Bidirectional nets, such as data busses, need to have all non-scan parts placed in input, or three-state mode.
Such information isn't always available to the test engineer. To obtain a stable and repeatable test sequence, test engineers must receive necessary control sequences as part of the design information handoff.
Optimizing your scan implementation will provide many benefits. Some of the more tangible ones are lower costs, shorter time-to-market, reduced manufacturing time, improved product quality, and the ability to support in-field upgrades and diagnosis.
There are several ways to optimize a design. One way is to provide a lot of control cells. A perk of boundary scan is the ability to control individual pin states in a device, without requiring complex knowledge of the device's real-world function. Adding a control cell to each logical-functional-pin grouping allows for finer resolution when using more-advanced test techniques, like virtual-component/cluster testing. In these cases the ability to three-state a single pin, while maintaining other pins at a known, active state allows the test engineer to develop more-comprehensive and stable tests in far less time. As a guideline, individual control cells should be assigned to each individual control-signal pin and bus group, such as address and data. For even better resolution, assign additional control cells at the byte, or nibble boundary of the buses (Fig. 9).
Boundary-scan cells can perform in-system testing of devices like flash-memory. Then, reducing the scan-chain length will optimize the data load or unload times. Additionally, a device with a short scan chain, and a way to exercise the control lines of the memory, further reduces the pattern overhead required to change a control line's state. An even better method would be to provide external control capability for such pins (Fig. 10).
Adding the on-board controller to perform boundary-scan tests yields significant reductions in life-cycle cost. It provides, too, value-added benefits, like the ability to perform remote field upgrades. Work done by a major satellite manufacturer shows this. The incorporation of boundary scan and in-system controllers allows the system to be remotely tested and diagnosed. That's an important feature when the nearest repairman is tens of thousands of miles away.
Providing this capability allows manufacturers to perform remote diagnosis when time is of the essence and sending a service engineer with the incorrect replacement part or board is undesirable. There are commercial TAP controller devices available to simplify the implementation of on-board boundary-scan testing.
Other Uses Too Boundary scan was originally meant as a DFT technique. A significant portion of today's usage is in on-board programming, or in-system configuration of logic arrays, such as those offered by Altera, Cypress Semiconductor, and Xilinx. These devices use the TAP to access their devices in the system. This capability allows designers to easily reconfigure their products in the field. They simply implement an on-board TAP controller, along with EPLD devices that can be reconfigured via the TAP port.A decade after its introduction, the IEEE-1149.1 boundary-scan standard has finally caught on. It's a viable and necessary technique for testing the quality of today's high-density and complex-circuit designs. It also gives system designers an easy way of remote system reconfiguration/upgrading, through in-system programmable devices.
Successful implementation of boundary scan does require care and attention during device and system design. Most of the mistakes and errors can be avoided by following the DFT guidelines that have existed for years.
Test access must be provided for all active nets. Active inputs cannot be connected to power, or ground, unless it's certain that the pins won't be used. It's necessary to document, verify, and promulgate all information about device features for the manufacturing and test functions within your organization.
Many design tools exist to make the incorporation of boundary scan into devices a relatively simple and painless process. There are, however, virtually no tools for the board designer. The design of the circuit board using boundary scan requires the obedience of a few general rules.
Wherever possible, boundary-scan devices should be combined as a single scan chain. There are a few exceptions to this rule. But in all cases, the goal should be to create the least possible number of discrete scan chains.
The standard DFT practices must be observed. These include accessability, observability, controllability, and documentation. Possible logical constraints must also be understood and documented.
When a vendor supplies a device that supports boundary scan, designers must insist on a verified BSDL file. Before specifying a device, a smart designer will ensure that the device doesn't require a "power-up" test-mode pin to activate its boundary-scan capability. And, the device will conform to the IEEE-1149.1 standard.
Designers must pay attention to the accuracy and completeness of the BSDL files for custom devices. The concurrence of scan devices and their BSDL file must be verified.