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.
Reprints
