| |
|
August 17, 1998
Checks and questions to head off disaster in IEEE 1149.1 boundary-scan
board test
IEEE 1149.1 is supposed to make your product testable. But if ICs that
promise to implement the standard fail to do so or if the IC vendor supplies inaccurate
BSDL files, you may find your project and your job in jeopardy. Here are some steps that
can help you head off disaster.
A serious implementation problem jeopardizes the credibility of the IEEE 1149.1
boundary-scan board-test standard. ICs that some vendors claim comply with the standard in
fact do not. And errors appear all too often in the vendor-supplied documentation on which
test departments rely. The problem is a direct result of neither the standard itself nor
the equipment designers. Yet these EEs are most likely to suffer the consequences, and the
consequences can be severe. Failure to recognize the problem in time can result in delays
that force management to scrap entire projects at the 11th hour. Board-level designers,
board-test developers, and IC-design engineers have the power to prevent such unpleasant
outcomes. They just need to know what steps to take.
BSDL common sense
Designers often underestimate the importance of accurate and up-to-date Boundary Scan
Description Language (BSDL) files for IEEE 1149.1-compliant ICs. Virtually every
application that uses 1149.1 is a computer program. Therefore, if you use erroneous
information in designing a pc board that contains 1149.1-compliant ICs, the maxim
"garbage in, garbage out" predicts the result. In 1994, the IEEE formalized IEEE
1149.1b-1994, the most comprehensive version of BSDL to date (see sidebar
"IEEE 1149.1: the good, the bad, and the history"). For example, the 1b version
of the standard enables BSDL files to describe compliance-enable pins.
The test system must hold the compliance-enable pins in a static logic state before and
during any 1149.1 operation that involves the IC. For example, a device that implements
internal scan may include the entire 1149.1 design in the internal-scan path. Thus, for
the 1149.1 circuitry to work, the test program must disable the internal-scan
path—usually by conditioning several of the IC's inputs. The 1990 version of BSDL
appeared before the development of compliance-enable pins. When FPGAs started to use these
pins, the result was board- and system-debugging problems of legendary proportions.
BSDL syntax and semantics
IC suppliers that are serious about IEEE 1149.1 work hard to comply with the standard
and provide high-quality, verified BSDL. By asking the vendors a few pointed questions
about compliance and BSDL, board designers and test engineers can identify which vendors
comply with the standard and which only claim to do so. The IEEE version of BSDL
(1149.1b-1994) provides semantic checks that uncover compliance problems, but the IC
manufacturer must first produce and compile the BSDL files. Once the files exist, a
compiler can perform the semantic checks to identify violations of 1149.1 rules. A
semantic check is different from a syntax check: Syntax checks determine whether the file
uses BSDL in accordance with its rules of grammar; semantic checks determine whether the
statements are meaningful.
The following are examples of 1149.1 violations that BSDL syntax cannot describe:
- The Bypass register is not a 1-bit register.
- The DeviceID register is not a 32-bit register.
- The test-clock (TCK) signal can be stopped only in the high state.
- The following are examples of semantic errors in syntactically correct BSDL:
- The TCK signal is attached to a boundary-register cell.
- A bidirectional I/O pin does not have 1149.1 support for bidirectionality in the
boundary register.
- The instruction-bit pattern for an instruction reserved for Bypass has been assigned to
some other instruction.
- More cells reside in the boundary register than were specified.
- The test-data output (TDO) pin (required to be an output) is actually an input.
- The boundary register is missing a signal pin.
When you have a clean compile that eliminates all semantic violations, you are on the
road to ensuring that the IC and its BSDL description comply with IEEE 1149.1.
Generate test vectors
Once the BSDL description exists, you can execute software that automatically generates
verification patterns. Automatic-test-pattern-generation (ATPG) software creates tests for
1149.1 circuitry and can use various ATPG algorithms to target problems.
You can uncover problems by using both production-test vectors and verification-vector
sets. Verification-vector sets aim to uncover discrepancies in the IC's 1149.1
configuration and compliance. Not surprisingly, 1149.1 compliance problems can be
difficult to resolve.
In the absence of an 1149.1 verification suite, IC designers can use the following
checkpoints. The checkpoints are the work of a vertically integrated workstation
manufacturer that strives for 1149.1 compliance. It provides an overview of items to look
for when performing the tests (Reference 1):
- Verify the test-access port (TAP) instruction-register-capture pattern. Here,
verification simply means reading out the bits that the IC should capture in the
Capture-IR state. Shifting operations verify TCK-edge rules.
- Verify the IDcode, if it exists.
- Verify the Usercode, if it exists.
- Verify that the Bypass register captures 0 at the Capture-DR state.
- Pass through all 16 states and 32 transitions in the TAP's state diagram. During one
instruction-load sequence and one data-load sequence, take paths through the Pause-xR and
Exit-xR states to exercise these transitions. Also traverse the states and arcs associated
with the Run-Test/Idle state.
- Verify that every (nonprivate) operation code targets a register of the specified length
between the test-data-input (TDI) and TDO pins. Sending streams of contiguous ones
followed by zeros verifies only the length of these registers. The boundary, Idcode, and
Bypass registers are tested elsewhere.
- Verify the mapping between the boundary register and every input pin (and every
bidirectional pin that acts as an input). Mapping verification is a lengthy process, which
takes that is more or less proportional to the square of the number of device pins. To
verify mapping, you must address the N pins one at a time. The boundary register is about
as long as the number of pins. Thus, scanning an (approximately) N-bit register N times
takes (roughly) N2 shift cycles. For mapping verification, walk a one through a
field of zero bits on all input pins. Capture the input-pin states and read them out
through TDO. If two inputs are swapped, a one appears out of the expected sequence of bits
shifted out on TDO. At this stage, you often uncover a boundary register that is longer or
shorter than the BSDL description declares.
- Verify the mapping between the boundary register and every output pin and every
bidirectional pin that acts as an output. Similarly, walk a one through a field of zero
bits on all outputs. Each setup takes a full scan of the boundary register.
- Verify the mapping between the output-driver enable lines and the
boundary-register-control cells. Drive all of the outputs of drivers controlled by any one
control cell to one and then to zero while disabling all other control cells.
- Verify that each cell's capture flip-flops perform as the BSDL describes. For advanced
ATPG algorithms, this verification is an automatic side effect of additional
boundary-register testing. Beware of algorithms that ignore BSDL packages' cell
definitions. To determine if the algorithm is reading this data, delete the information
and see if the algorithm responds to its absence.
- Verify that the run built-in self-test (RUNBIST) instruction, if it exists, functions as
described. The RUNBIST operation mostly clocks in the RUN-TEST/IDLE state. A test-result
readout appears in the target register. To be thorough, use some known-good ICs and some
ICs that fail RUNBIST to verify proper indication of RUNBIST failures.
Failure to catch some of these problems before the test is assembled has little impact
on a boundary-scan board test. For example, regardless of what problems you have caught
before test assembly, a test engineer still immediately discovers an incorrect IDcode.
However, an incorrectly stated instruction-register length has a devastating and highly
ambiguous effect on the overall test. Such problems are difficult to ferret out, but
software to perform these checks is publicly available over the Internet (Reference 2).
Simulate against ATPG vectors
ATPG patterns simulate the 1149.1 circuitry and predict how that circuitry responds.
Unpredicted responses can result in a compliance problem or an undetected mismatch between
the silicon and the BSDL description. You increase your likelihood of catching these
problems when you use several ATPG vector sets.
Executing the verification pattern set directly on an IC tester can uncover problems
that do not show up in a software simulation, such as ground-bounce problems in the 1149.1
implementation. The downside to using an IC tester is that verification patterns can be
quite long; thus, it can be difficult to fit them into a typical IC tester.
Production test
ATPG can generate a less vector-intensive test to verify that an IC has been
manufactured correctly. This test toggles all inputs and outputs, turns all three-state
drivers on and off, reads out IDcodes, exercises the bypass register, and shifts data
through user-defined registers. Because the test assumes that the implementation complies
with 1149.1 and that the BSDL is accurate, it eliminates the need for lengthy pin-mapping
validation during the production test. If this assumption is invalid, the production test
may fail to discover the problem.
You gain an added measure of confidence by simulating these vectors against the 1149.1
circuitry to measure the coverage against expected fault modes. You have to expect some
missing coverage at the interface between the boundary register and the IC's system logic,
but you can compensate by implementing an Intest-based test. However, such a test requires
additional system-logic information, which the BSDL does not provide.
Materials engineers and buyers should use the following set of questions to evaluate
boundary-scan-IC vendors' level of 1149.1 compliance and BSDL quality. The questions also
help weed out the vendors that merely give lip service to compliance.
Silicon
- What level of the standard (1149.1-1990, 1149.1a-1993, or 1149.1b-1994) do you use for
your designs?
- How many years have you been implementing 1149.1?
- How many unique ICs have you implemented with 1149.1?
- How do you verify that the 1149.1 implementation complies with the standard?
- Do you explicitly test the 1149.1 implementation during production?
- How do you create the 1149.1 production test?
- Can you provide a copy of this test for audit?
- How do you fix defects in an 1149.1 implementation?
- Have you had to fix defects in previous ICs? What improvements were made in future ICs
as a result?
BSDL
- Do you provide BSDL for each IC for which you claim 1149.1 conformance? If so, which
edition of BSDL (1990 or 1994) do you use?
- Have you checked the BSDL for syntax and semantic errors? How?
- Have you verified that the BSDL matches the silicon implementation? How?
- In what form do you supply BSDL?
- How do you track the effect of changes in an IC implementation and on the related BSDL?
- How do you notify users of changes in silicon or BSDL?
- How do you fix defects in a BSDL description? Do you inform users if you have not
inspected, checked, tested, updated or otherwise certified a BSDL?
Answers to these questions will help you to evaluate vendors' compliance. Asking the
questions and insisting on good answers provides an incentive for improvement. Vendors
will find that they must comply if they want to compete and will eventually produce
improved products with measurable reliability.
- Parker, Kenneth P, and S Oresjo, "A language for describing boundary-scan
devices," Proceedings of the International Test Conference, September 1990, pg 222,
IEEE Computer Society Press, Los Alamitos, CA.
- Internet-based ATPG for 1149.1 Compliance and BSDL Verification, BSDL/IEEE 1149.1
Verification Service, http:// HPBScanCentral.Invision1.com.
- IEEE Standard 1149.1, IEEE Standard Test Access Port and Boundary-Scan Architecture,
IEEE Standards Board, New York, NY. (The IEEE sends the most recent revision including any
supplements. BSDL is part of this.)
- Parker, Kenneth P, The Boundary-Scan Handbook, Kluwer Academic Publishers, Norwell, MA
1991.
IEEE 1149.1: the good, the bad, and the history
IEEE 1149.1 aims to reduce the need for nodal access in testing connections among ICs
on pc boards. As components and pc traces shrink, nodal access often becomes impossible or
at least impractical. New packaging technologies, such as BGAs, place solder joints beyond
the reach of visual inspection and increase the need for electrical verification of
interconnect integrity. IEEE 1149.1 lets you perform such tests by using a standardized
five-pin test-access port (TAP) on compliant ICs. You use the TAP to serially load test
vectors into boundary-scan registers in the devices. You also read out the test results
serially through the TAP.
Too often, though, IC manufacturers inaccurately or incompletely implement the
standard. Manufacturers often furnish incorrect Boundary Scan Description Language (BSDL)
files that make it difficult and sometimes impossible to create test programs. Test
programs based on erroneous or incomplete files either don't run or provide incorrect
results. Frequently, design engineers become aware of these problems only when the test
department discovers them.
Often, the discovery comes only after pc-board layouts are complete, resulting in an
untestable product that requires redesign. The extra effort can be so time-consuming that
the product can't reach the market while the market still exists. In such cases,
management has no choice but to scrap the entire project.
Over IEEE 1149.1's eight-year existence, the industry's attitude toward IEEE 1149.1
compliance has become cavalier. For too long, IC vendors have gotten away with treating
compliance as a "check-off" item on customers' device specifications. In other
words, when reviewing a customer's IC specification, the vendor checks the box that
indicates IEEE 1149.1 compliance but does not really consider what compliance implies.
Equipment-design engineers must accept some responsibility for this situation. These
engineers have been too willing to take IC vendors' claims at face value rather than
demand proof of compliance. Undoubtedly, part of the problem results from the manner in
which companies organize their design and test activities: The design group controls the
device specs, and the test group is responsible for the programs that fail when the parts
don't comply.
Understanding the standard
When a complex standard appears, its early adopters often uncover ambiguities. The
1149.1 standard is a collection of written rules without formal mathematical parameters.
Therefore, deciding if an implementation violates the standard requires documentation of
the feature and submission of a written request for interpretation to the IEEE Standards
Board. Obviously, this method of evaluation is time-consuming and impractical.
The 1993 revision of IEEE 1149.1 replaces all of Chapter 10, which describes the
boundary register. This is the part of the standard that IC designers use. Since 1993,
there have been virtually no changes in the standard that affect the design of compliant
ICs. More notably, for the last five years the standard itself has provided the answers to
all requests for interpretation.
Still, IC manufacturers must recognize that halfhearted attempts at IEEE 1149.1
compliance are ultimately self-defeating. Although an incomplete or incorrect 1149.1
implementation may enable a manufacturer to speed its ICs to market and thus may increase
short-term profit, equipment designers will eventually discover which companies make
credible claims. In the end, companies that adopt a slipshod approach to compliance will
suffer.
To be fair to the IC manufacturers, one of the reasons they have trouble producing IEEE
1149.1-compliant designs is the lack of compliance-testing tools. All too often, IC
designers make basic errors in implementing the standard because they cannot execute a
simple compliance test. A test suite of proven designs or implementations (similar to that
available for compilers) would be a valuable design tool. |
