Validate your BSDL files and 1149.1 implementations
Many of you have written to thank us for the improvements we made to the original Agilent BSDL Validation Service. A little over a year ago, we changed the old email-based interface to a web-based service so that users could quickly and easily submit, compile, update and retrieve results on BSDL files, using syntactic and semantic checking, and pattern generation methodologies. At this point, we have 800 users across 350 companies and almost 20,000 BSDLs have been submitted for validation. In collaboration with Agilent, we’re proud of what we’ve done and know that the BSDL Validation Service website is providing a valuable service in our industry.
Why is this important? Simply stated, boundary scan/JTAG has become “table stakes” for many downstream processes in the areas of software testing, design validation, printed circuit board testing and device programming. It is used in hardware and software design, signal integrity verification, prototyping, manufacturing test, repair and other areas too numerous to mention. (For an article in this issue of Connect on how boundary scan is being used with embedded instruments in design validation applications, click here.) It’s safe to say that the vast majority of new hardware designs could not be introduced successfully without correct JTAG implementations at the chip level. And having correct BSDL files is essential to this.
And yet we estimate that over 10 percent of new semiconductors are initially brought to market with improper 1149.1 implementations and/or inaccurate BSDL files. This causes no end of churn between chip companies and their customers; and chip designers typically never hear about the problems because they are usually one step removed from troubles in the field.
Since ASSET’s test and programming products are deployed at virtually all hardware design companies, we are often the first to hear about faulty BSDL files or poorly implemented 1149.1 in silicon. And many of these problem chips had, in fact, already been checked by our online BSDL Validation Service. What went wrong?
Let’s look at the possible pitfalls of chip-level JTAG validation techniques and how chip designers might expand their methodologies to catch many common errors. Semiconductor companies could thereby save money in the long run and accelerate new chip introductions.
Validating Your Devices
There are numerous ways to validate that a chip has implemented 1149.1 correctly and that its BSDL file accurately characterizes its JTAG performance. The following methods are listed in order of increasing rigor:
- Compile your BSDL using the ASSET/Agilent BSDL Validation Service website.
- Place the Verilog/VHDL-testbench output from your chip design tool into a 1149.1 simulation environment such as Cadence NC-Verilog, Mentor ModelSim or Synopsis VCS.
- Generate testbench Pattern Capture Format (PCF) vectors based on your BSDL file using the ASSET/Agilent BSDL Validation Service, convert these patterns to VHDL/Verilog and apply them in a simulator.
- Take the Verilog/VHDL-testbench output from your chip design tool and run it on a chip ATE system.
- Generate testbench PCF vectors from the BSDL file by using the ASSET/Agilent BSDL Validation Service, convert these vectors to VHDL/Verilog/native 93K format (or whatever your tester supports) and apply them to your chip on your ATE system.
- Submit your device and its BSDL file to ASSET and we will independently validate the chip with our BSDL Silicon Validation service.
Let’s look at these test strategies in greater detail so we can understand the pros and cons of each.
Compiling with the ASSET/Agilent BSDL Validation Service
The BSDL Validation Service’s most commonly-used utility is “Compile.” This runs a BSDL file through a software module which compiles the BSDL and validates syntax and semantics against the IEEE 1149.1B-2001 specification. This catches common errors such as invalid tokens, spelling errors, misplaced alphanumerics and others. For example, look at this excerpt from a BSDL file:
entity chipxyz is
generic (PHYSICAL_PIN_MAP: string:= "BGA");
CKMODE_SEL : in bit;
MDC : in bit;
MODE_SEL : in bit;
2WENT : in bit;
C5 : in bit;
Below is a portion of the output from the BSDL Validation Service noting the errors in the input file:
Entity name: chipxyz
Error, Line 9, parse error near symbol ‘2’.
Error, Line 9, Improper Port declaration.
BSDL file chipxyz.bsdl contains errors, stopping
BSDL syntax is based on VHDL syntax and names must begin with an alpha character. The correct BSDL syntax would be:
entity chipxyz is
generic (PHYSICAL_PIN_MAP: string:= "BGA");
CKMODE_SEL : in bit;
MDC : in bit;
MODE_SEL : in bit;
A2WENT : in bit;
C5 : in bit;
The resulting corrected BSDL file would read:
Entity name: chipxyz
IEEE Std 1149.1-1994 (Version 1.0)
Packaging option selected is BGA.
Inputs = 22
Outputs = 5
Bidirectionals = 14
Instruction Reg Length = 4
Boundary Reg Length = 69
BSDL compilation of 256 lines completed without errors.
The ASSET/Agilent BSDL Validation Service is located at:
What Compiling Does NOT Do
Doing a syntactic and semantic check only validates that the file compiles correctly and that it adheres to the BSDL language conventions defined in the IEEE 1149.1 specification. It certainly does NOT validate that the BSDL correctly describes the implementation of JTAG features in the silicon, nor does it validate that the device itself implements JTAG correctly. In this case, OEMs will not be able to fully test circuit boards with the device on them, increasing the cost of test and decreasing the bottom-line profits for the product.
To validate that a chip’s JTAG implementation is correct, additional, more rigorous steps must be taken.
Using Testbenches: The Fox in the Henhouse?
Before they reach tapeout, chip designers have typically used simulation to validate that their design functions to specification. Simulation with tools such as Cadence NC-Verilog, Mentor ModelSim, and Synopsis VCS can also validate that the boundary-scan logic has been implemented correctly. Boundary-scan logic, consisting of the Test Access Port (TAP) and boundary scan cells, can be inserted into a design in a number of ways. The logic can be implemented by third-party EDA tools such as Mentor’s BSDArchitect or Synopsys’s BSD Compiler. These tools provide a Register Transfer Level (RTL) description of the logic for inclusion in the design and automatically generate testbenches and a BSDL file. The boundary-scan logic can also be inserted by proprietary tools which may or may not generate testbenches and BSDL files automatically. With either method, the chip’s boundary-scan logic should be simulated to validate that it functions correctly.
The problem with simulation in this context is that the testbench created for the design is generated by the same tool which does the JTAG insertion. So, unfortunately, errors that may have been introduced during JTAG insertion may not be detected during simulation. We call this the “Fox in the Henhouse” scenario. To reduce the chance of this happening, we recommend that chips should be tested by testbench vectors independently generated by a third-party.
Third-Party Pattern Generation: A Panacea?
One way to offset the risk of JTAG insertion errors propagating through the validation process is to have an independent third-party application generate the test vectors from a chip’s BSDL file, rather than its logical implementation. This is one area where the ASSET/Agilent BSDL Validation Service really shines and where it is commonly used. The BSDL Validation Service generates vectors in a Pattern Capture Format (PCF) truth-table. PCF is the native Agilent 3070 format and can be easily converted to VHDL, Verilog, native Agilent 93000 and other formats. This conversion can be accomplished manually through scripting or through one of the utilities that are readily available, such as VTRAN from SourceIII. (For more information on SourceIII, click here.)
Note that if a BSDL file compiles correctly following a syntactic/semantic check, the ASSET/Agilent BSDL Validation Service compiler usually generates patterns successfully. Unfortunately, successfully generated patterns do not necessarily mean that the chip’s JTAG implementation conforms to the standard. The silicon does not need to match the BSDL file for patterns to be created! Simulating the BSDL-related vectors against the device’s logic is necessary to validate that the BSDL describes the design. Using third-party vectors in a device’s testbench is an effective way of reducing the risks of non-compliance.
More Possibilities Abound
Once first samples of a device are available, the same patterns which were used pre-tapeout can again be implemented, but in a full ATE setting. The caveats discussed above still apply, of course. For example, successfully testing a device using patterns generated by the EDA tools will prove that the JTAG logic designed by the tool was implemented correctly, but not necessarily that the BSDL is correct or that the device is in fact compliant to 1149.1. However, testing with independently generated patterns based on the BSDL will confirm the validity of the design and the BSDL. It has been our experience that few semiconductor companies actually take this final step. One reason why this is happening is the expense involved with time on ATE test systems. Increasing test costs are usually frowned upon. But independently generated patterns must only be applied to first samples of the chip. Once the device passes the tests based on these patterns, the BSDL has been validated and subsequent samples of the device do not need to be tested with new patterns.
Things Can Still Go Wrong
Despite rigorous simulation and testing, BSDL file issues can still cause problems when board-level tests are developed on a JTAG tool such as ASSET’s ScanWorks. For example, compliance enable signals, which are pins that must be held at a static state during JTAG testing, might be specified in the BSDL file as shown below:
attribute COMPLIANCE_PATTERNS of chipxyz : entity is
ScanWorks knows to check that this signal can be driven to a ‘1’ during boundary-scan testing and alerts the user if it is not. However, the EDA tool that generated the BSDL file and patterns may control this signal in the patterns and fail to place the compliance attribute in the BSDL. Simulations and chip tests will work but when the JTAG test tool tries to test a board with this device on it, the device may not go into JTAG mode and the board test will fail to execute. Even though it appears that everything was developed correctly, the chip designer still may end up with a BSDL file that causes problems for users.
And, of course, the possibility of human error is always present when version control of the BSDL is not managed properly. We have encountered numerous situations where BSDL files are changed manually after tapeout. These manual changes may involve adding ground pins, changing pin or cell mappings, adding comments and other actions.
It is apparent that even if a device has been validated through syntactic/semantic checking, independent third-party pattern generation, simulation and ATE testing, problems with the physical implementation of 1149.1 within the device could be encountered.
Alternatively, some semiconductor suppliers elect to have independent third-parties validate their devices after tapeout in order to assure the highest quality JTAG implementations. This is especially true if JTAG insertion is done manually or if simulation/ATE test steps were dropped because of cost and time constraints.
The Final Check – Silicon Validation
Post-tapeout, the most rigorous way to validate the 1149.1 implementation in a chip is with ASSET’s BSDL Silicon Validation service. This takes place early in the “engineering sample” process. The device is sent to ASSET headquarters in Richardson, TX, and, for a nominal fee, it is placed in a fixture which provides proper power and ground, boundary-scan access to each I/O, access to TRST, TMS, TCK, TDI and TDO, and static control of compliance enable pins. The test sequence generated by ASSET for the device and BSDL file consists of:
- RESET Action
- DR Verify Action
- Scan Path Verify Action
- Device ID and Bypass DR Scan only
- IR Capture
- Bypass Register
- Boundary scan Register Length
- USERCODE (if applicable)
- Interconnect Pin Test
One very effective aspect of ASSET’s service is it can also test the IEEE 1149.6 (AC-coupled high-speed I/O) and IEEE 1532 (concurrent ISP programming) attributes of a device. IEEE 1149.6 compliance is especially difficult and often impossible to validate with any other third-party solution.
ASSET validates IEEE 1149.6 compliance with a methodology similar to 1149.1 validation, but with an emphasis on 1149.6 input, output and control cells. The device is checked to see if it can properly execute 1149.6 instructions and detect signal modes. For example, output cells are tested by applying the EXTEST_PULSE and EXTEST_PULSETRAIN instructions to verify that the 1149.6 output signals from the chip are properly detected on 1149.6 receiver cells on the test fixture.
Similarly to 1149.6 validation, IEEE 1532 conformance is verified by first testing the device’s basic JTAG (1149.1) operation. Then, after syntactic and semantic checking is performed for the Action, Process and Flow statements, the device is erased, programmed and verified with a third-party 1532 player and a user-supplied bit-stream file. During this stage, “all actions” paths are verified first, followed by all “recommended” paths.
Of course, unless a re-spin has been planned for other reasons, changes to the silicon at this stage in design may be time- or cost-prohibitive. Nonetheless, ASSET often recommends changes to a device’s BSDL file that can help provide some measure of JTAG testability. It is better for circuit board designers to have slightly lower test coverage, than no test coverage at all.
ASSET’s BSDL Silicon Validation Service is used extensively by many large semiconductor companies to assure as close to full compliance with 1149.1, 1149.6 and 1532 as possible. For example, Xilinx has subscribed to this service for several years now. Accurate BSDL files and quality JTAG implementations accelerate the test generation process for users of Xilinx’s chips, shortening the user’s time-to-market and time-to-profit. For more information on how Xilinx is using our BSDL Silicon Validation Service, click here. For more information on all of our chip services click here.
The good news for the industry is this: more and more chip manufacturers are realizing that saying a device is compliant with the IEEE 1149.1 standard requires upfront testing of the design as well as samples of a device to verify the functionality of its embedded boundary-scan infrastructure and other requirements, such as its BSDL file. After all, it is in the best interests of chip manufacturers to provide high quality silicon that delivers full functionality as advertised. Building a brand known for quality pays off in the long run.
Moreover, it is in the best interests of system designers and manufacturers when they are able to rely on the JTAG functionality of the chips they purchase because there is so much riding on boundary scan these days. Not only many of our current test practices, but also many of the most advanced board-level and system-level design validation, test and debug techniques of the future will hinge on boundary-scan capabilities that were embedded in chips well before system development even began. Getting JTAG right from the beginning simply avoids many possible downstream risks for everyone involved.