Boundary scan is gaining acceptance as designers better understand its benefits and implementation. Tools for automatic test-pattern generation (ATPG) and design simulation require descriptions of devices' boundary-scan implementations. Now, the IEEE-1149.1 boundary-scan standard not only defines a protocol and a device architecture, but also defines a boundary-scan description language (BSDL). Through BSDL, you can tell simulators and ATPG tools how a device implements boundary scan. But, to use BSDL, you may find it useful to learn how to develop BSDL files and how to validate their accuracy. You should also understand why validation is important.

Because a BSDL file forms the basis for testing an IC, a board, or a system, the file must accurately describe the design. Even a slight error, such as an incorrect disable value for an output cell, can give inaccurate results or even damage the device. By verifying a BSDL file, you help to prevent device damage, increase your testing confidence, ensure device compliance with IEEE 1149.1, deliver quality products, and meet customer expectations.

Generating a BSDL file

Familiarity with BSDL is a prerequisite for creating BSDL files. (A list of BSDL books appears at the end of the article.) To create a BSDL file, you can use one of four methods:

• Text editor allows you to manually create BSDL,
• BSDL editor generates the BSDL file after you input device data into predefined fields,
• Synthesis tool creates BSDL from CAE design data,
• Automatic analysis creates BSDL by stimulating a device to determine its boundary-scan structure.

Each method offers advantages and disadvantages. For example, a BSDL editor can construct a syntactically correct BSDL description that does not match the device. A synthesis tool can construct a correct BSDL description that matches the device, but the device may not conform to the IEEE 1149.1 standard. Automatic analysis can create a correct BSDL description that matches the device but fails to describe extended features or complex cell designs.

Before creating a BSDL file using either of the first two methods, you must gather all relevant design information, including the test-access port (TAP) design, boundary-register cell ordering, cell-to-pin mapping, lengths of internal scan chains, and cell designs. Because of difficulties in obtaining or interpreting the cell's design, determining the boundary cell's type is the most difficult part of creating a BSDL file. BSDL offers eight predefined cell types, BC_0 through BC_7. Usually a cell fits into one of these categories. If it doesn't, the standard lets you define a unique cell type. For example, the bidirectional cells of a recent ASIC always capture data from their functional pins. The ASIC designers created a custom cell type because none of the predefined cell types fits this design.

After you create the BSDL file, you need to generate validation vectors for the device. The process begins with generating test vectors (Fig 1). Our evaluation of the available tools shows that no single tool generates a comprehensive set of vectors. For example, Tapdance from AT&T is good at testing compliance issues, and HP's Boundary-SCAN (Bscan) generates patterns that are good for testing cell types. You obtain a higher level of boundary-scan fault coverage if you use several vector sets for validation, rather than just one.

After you've generated the vector sets, you can use them in device simulation or directly apply them to a device. Test early and often. Develop the BSDL description concurrently with the IC design, and run the test vectors on the device model. After fabricating a device, rerun the vectors to detect timing or synthesis errors. Run the tests for each type of package in which you mount the device and for any later revisions.

Fig 2 shows the flow of vectors during a device test. Step 1 involves translating the original ATPG vector formats into a common format. TI supports the Serial Vector Format (SVF) as a common exchange format between test tools and testers. In step 2, you use the Asset tool to compile and apply the SVF file. The tool saves the tester's response data in a binary format that is tens of thousands of vectors long and is difficult to analyze. Step 3 breaks down the response data and reduces it to a series of scan chains to create a "scan-view" file. The scan-view file contains the functional pin values generated during the capture and update states, a record of all responses that failed to agree with the predicted values, and other relevant data. The scan-view file lets you relate the condensed results to the device pins and scan-register values.

comparesTable 1 parallel vector sets and shows the reduction resulting from converting the tester response data into the scan-view format. The example in Table 1 shows vectors for the TMS320C50 DSP device. Compared with Tapdance, Bscan generates about four times as many vectors because it tests each I/O pin independently. Tapdance tests inputs and outputs as groups. Because the scan-view files are small compared with the original ATPG files, they simplify interpreting the response data.

ATPG tools generate go/no-go vectors that can't isolate faults. Such vectors make identifying single faults easy but make analyzing multiple faults difficult. You can usually isolate a fault by analyzing the device's scan-view file (Fig 2) or by extracting the failing vectors and running them as a smaller test. During analysis, don't assume that all possible errors lie in the BSDL file and the device. The vectors, fixture, and tester can also contain errors. You need to use your detective skills for the final analysis. If you conclude that a fault lies in the BSDL file, you must determine how to modify the file so it correctly describes the device. Then, the validation cycle starts over and repeats until the vectors pass.

To validate a BSDL file, you can use vectors in two formats, serial and parallel. The serial format defines a device as a scannable part with input and output pins. Serial vectors are compact and check pin functions, but they assume that the scan ring is working. The vectors can't detect IEEE-1149.1 violations.

The parallel format defines a device as having only input and output pins. A scan applies a series of vectors to the scan pins and manipulates the I/O pins when necessary. Parallel vectors do not assume the scan ring is working, and they can detect IEEE-1149.1 violations. Tapdance and Bscan generate parallel vectors that detect all types of boundary-scan errors. Both packages also generate large stimulus files. For example, performing a single data-register scan of a device with 86 cells (starting and stopping in the idle-TAP state) takes 182 parallel vectors, not counting overscanning or pause states.

Because you perform BSDL validation to detect all boundary-scan design errors, you need parallel vectors for testing. This requirement creates a data-management issue: The vector sets for large processors can contain between 30,000 and 200,000 vectors and can generate stimulus files of several hundred megabytes.

The vectors that ATPG tools generate check only for BSDL-file and IEEE-1149.1-compliance errors. Because BSDL describes only the length of internal scan paths, testing such paths requires manual pattern generation.

BSDL errors fall into three categories: BSDL-syntax errors, mismatches between the BSDL description and the device, and IEEE-1149.1-compliance errors. Table 2 lists some of the tests you must perform for each category.

BSDL-generation packages usually detect BSDL syntax errors. Only text editors fail to catch syntax errors. If you use a text editor, you can use a BSDL-syntax checker to detect the syntax errors you accidentally introduce.

You cause mismatches between the BSDL description and the device by supplying inaccurate information about the device. Synthesis and automatic-analysis methods generate correct BSDL by construction. BSDL that you generate using text or BSDL editors requires validation to detect mismatches.

None of the generation methods detects IEEE-1149.1-compliance errors. Therefore, you must perform validation using parallel vectors. Only parallel vectors individually control the signals that allow detection of edge changes and pin values in all TAP states. Because of the subtleties of designing IEEE-1149.1-compliant devices, you should use simulation validation for early detection of IEEE-1149.1-compliance errors.

The BSDL-validation flow described here works well, but you can improve it by having a single ATPG tool that generates go/no-go vectors and provides diagnostic capabilities. An interactive or batch diagnostic tool that uses a simple macro script is ideal because it allows custom test scenarios. However, because of the multitude of possible faults, the best diagnostic tool is an intelligent human. Finally, remember that BSDL validation is much more than a means of satisfying a device's end user; it is a valuable design-verification tool.

1. "Boundary-Scan Description Language" (Supplement (B)), IEEE Standard 1149.1-1990, IEEE, New York, NY, 1993.

2. Parker, Kenneth P, The Boundary-Scan Handbook, Kluwer Academic Publishers, Norwell, MA, 1993.

3. HP Boundary-Scan Tutorial and BSDL Reference Guide, Hewlett-Packard Co, Palo Alto, CA, 1992.

4. Bleeker, Harry, P van den Eijnden, and F de Jong, Boundary-Scan Test: A Practical Approach, Kluwer Academic Publishers, Norwell, MA, 1993.

5. IEEE-1149.1 Testability Primer, Texas Instruments Inc, Dallas, TX, 1994.