CONNECT NEWSLETTER

Issue Home

 

See us at the 43rd Design Automation Conference July 24-28, Booth 3449
 

asset-intertech.com

ScanWorks®

Services

Customer Support

ASSET University

Success Stories

Global Contacts

 

INSIDE ASSET

Boundary-scan process starts with BSDL files

A chip’s BSDL file can be used to validate the device’s JTAG implementation, but the BSDL file must be accurate. Inaccuracies are frequently introduced into BSDL files from any number of sources. Fortunately, several services (free and otherwise) are available to validate the accuracy of a device’s BSDL and make this information more useful.

JTAG capabilities must be designed into chips during the design process. And for automatic test pattern generation (ATPG) to take place, a chip’s JTAG features must be described in a BSDL file. To take full advantage of boundary scan to perform testing at the chip-, board- and system-levels, as well as to perform in-system programming of on-board programmable devices, accurate BSDL files are an imperative. The IEEE 1149.1 standard requires that chip vendors provide BSDL files for all IEEE 1149.1-compliant devices.

The Limitations of CAE-generated JTAG and BSDL

JTAG capabilities are often added to chip designs by CAE tools that insert the JTAG features as one of the last steps in the design process. Insertion tools also generate test benches for use with simulators to validate that the chip’s JTAG features have been implemented correctly. A validated JTAG design is required for chip testing and for generating a BSDL file.

This process is well defined and generally results in accurate BSDL files and complete test sets. Although most JTAG insertion tools are very effective and accurate, the JTAG implementations generated by CAE tools often must be modified manually for specific chip designs or to implement special JTAG features, such as support for new technologies not yet supported by the insertion tools. For example, many new technologies recently have used the JTAG infrastructure as a foundation. These technologies include 1149.4 (analog test), 1149.6 (testing of AC-coupled high-speed interconnects) and 1532 (concurrent in-system programming). When these technologies are required by a design, the BSDL files for the boundary-scan components in the design often must be modified to reflect the inclusion of these special features. When a BSDL file is manually edited, it is prone to error.

In other cases, chip designers may choose to manually insert JTAG into their designs instead of using a JTAG insertion tool. As with any standard, the IEEE 1149.1 specification is open to interpretation. Chip designers may attempt to “optimize” the chip’s JTAG features to save silicon space or pins on the device. They may not always realize the implication their shortcuts have on the subsequent testability of boards where the device is deployed. Manual insertion of JTAG features means that the BSDL file also must be created manually, as well as any chip-level tests to validate the device’s JTAG features.

In addition, new technologies like 1149.4 and 1149.6 also may not be supported by the test generation tools. This means that the JTAG implementation in the chip can not be fully tested in simulation before tape out.

The Problems of Manually Generated BSDL

Most chip designers are not experts in board test in general and they are certainly not experts in boundary scan in particular. When JTAG features are inserted manually by a chip designer, the resulting implementation is often non-compliant or marginally compliant with the IEEE 1149.1 standard.

For example, the developer of a DSP chip designed JTAG into the device and purchased ScanWorks  to test the evaluation boards that included the device. He could not get the JTAG features to work and further investigation by ASSET application engineers discovered that the chip designer had implemented the JTAG test access port (TAP) controller as a four-state state machine, while the JTAG specification requires a 16-state controller with specific state-to-state transition paths. The chip designer believed he would not need most of the states, so he decided to “optimize” the JTAG interface by implementing only four states. As a result, the first boards with this particular DSP chip could not be tested by ScanWorks or any commercially-available JTAG tools.

Another example of chip designers taking liberties with the JTAG specification involved the programming of PLDs. Designers at a major PLD vendor decided to implement a feature that required a specific state transition in order to trigger the programming of the devices. This worked well with the vendor’s programming tools, but no commercially available boundary-scan tool supported the vendor’s state transition path. As a result, the vendor’s devices could not be programmed in-system by any third-party boundary-scan tools. Before long, large customers of this particular PLD supplier complained. The only way to solve the dilemma was for the PLD vendor to work with ASSET to make special modifications in the boundary-scan tools to support the vendor’s PLD devices. This could have been avoided if the PLD vendor or a third-party had validated the devices’ designs with a boundary-scan tool before the devices were built. 

The lessons learned from these kinds of examples are that if JTAG is manually implemented at the chip level or if manual changes are made to the features added by boundary-scan insertion tools, additional tests and BSDL validation tools are needed.  The best source for these tools are those tools that will eventually read the BSDL files and create simulation patterns, or board- and system-level test patterns based on these BSDL files.

Validating a BSDL File

Tools are available to read a BSDL file, check it for syntax and semantic errors, then use it as the basis for generating Verilog simulation test patterns to be run against the design before IC tape-out. These patterns can also be used for production tests. The output is a theoretically correct implementation of IEEE 1149.1 in an IC. Examples of these products are SAJE™-JTV from SiliconAid, BSDArchitect™ from Mentor Graphics, Encounter Test Architect™ from Cadence, or the free web-based service sponsored by ASSET InterTech and Agilent technologies (http://www.asset-intertech.com/bsdl_service)

ASSET InterTech / Agilent BSDL Validation Service

Validation of correct IEEE 1149.1 test features in simulation is an essential step, but the real test is if the device will work in a board or system test environment with commercially available boundary-scan test tools. The process of validating a BSDL file using tools based on commercially-available boundary-scan board test tools not only ensures that the BSDL accurately describes the silicon, but to some extent it also validates that the chip’s boundary-scan features are IEEE 1149.1-compliant. It validates the chip will work with other JTAG devices and can be supported by commercially-available boundary-scan tools. 

Chip suppliers can now turn to several alternatives that verify and validate the accuracy and functionality of BSDL files. Each method ascertains the accuracy of BSDL files in a different way and to varying degrees. The benefits of greater accuracy in BSDL files will include greater user satisfaction with semiconductor devices because this will enable more effective testing and troubleshooting methods in end equipment products, which, in turn, will make end equipment products easier to develop, manufacture, support and maintain.

The Next Step: BSDL Silicon Validation

Syntactically and semantically validating the accuracy of a BSDL file is certainly critical, but it does not replace a functional verification of actual silicon. ASSET’s BSDL Silicon Validation Service takes the first samples and places the device in a known-good-board environment where ScanWorks can be used to generate test patterns as a functional test of the chip’s JTAG implementation and the corresponding accuracy of the chip’s BSDL file.

The silicon is placed in a fixture that provides proper power and ground, access to each I/O pin and the boundary scan TRST, TMS, TCK, TDI and TDO signals, as well as static control of compliance enable pins. At this point a test sequence consisting of the following is generated for the device and the BSDL file:

  • RESET Action
  • DR Verify Action
  • Scan Path Verify Action
  • Device ID and Bypass DR Scan only
  • IR Capture
  • Bypass Register
  • IDCODE
  • Boundary-scan Register Length
  • USERCODE (if applicable)
  • Interconnect/Pin Test

Based on the results of this test sequence, the silicon supplier can be assured that the BSDL file for the device accurately reflects its boundary scan characteristics. Of course, of utmost concern to chip vendors is whether their devices will function properly for their customers in a board-test environment. This too is validated by this process.

For more information on both of ASSET’s BSDL services, click here.