Boundary-Scan Testing: JTAG GM Peter van den Eijnden Introduces the Latest Tools

Estimated reading time: 9 minutes

While the basic, so-called "dot 1" IEEE 1149 (boundary-scan) standard has not changed much in recent years--although some proposals are outstanding by the current working party--several exciting developments have recently occurred with regard to boundary-scan tools.

Indeed, both the hardware and software solutions that allow engineers to harness the boundary-scan already embedded in their existing designs, for board testing and the programming of devices, have developed at a pace. Also, and perhaps most interestingly, boundary-scan has pushed further into the development space with low-cost and, in some cases, free debug tools. This has made the technology available to even the most modest of electronic engineering departments.

A Short History of JTAG/Boundary-Scan

Boundary-scan test architecture was developed in the late 1980s by an ad hoc group, the Joint Test Action Group, JTAG, whose initial aim was to solve the problems associated with building and testing PCBs that would (at the time) soon start using surface mount technology (SMT) components.

JTAG became the name for the group’s solution, which was standardised as IEEE 1149.1 in 1990. Subsequently, as the JTAG standard gained acceptance throughout the 1990s, a number of boundary-scan tool vendors introduced solutions to make life easier for test engineers looking to add JTAG-powered board testing into their programme.

With such tools, engineers could extract basic design information from their design team’s EDA tools and quickly create structural tests for detecting short- and open-circuits, plus perform simple logic tests.

Since then the tools have improved in many aspects, including overall effectiveness, quality of test generation, ease-of-use, and their ability to integrate with other test methods such as flying probe, bed-of-nails, and functional test. However, in nearly all cases, the improvements and enhancements were aimed at test engineers and the tools themselves carried relatively high price tags. This meant the tools, and most notably their access to silicon, remained inaccessible to other interested parties; most notably, design engineers who wanted to benefit from the power of boundary-scan, but could certainly not justify investing in a production tool.

Access Granted

Though boundary-scan was developed primarily as a structural test technique for production purposes, the JTAG Test Access Port (TAP, Figure 1) was soon being used for other functions, specifically by the silicon vendors themselves. For instance, many designers will be familiar with JTAG as an in-circuit programming port for the devices of Altera, Lattice, Cypress, Xilinx, and other PLD vendors.Figure 1: Above, a reminder of how boundary-scan is implemented at board-level showing boundary-scan components daisy-chained together. Essentially, the test data out (TDO) of one device connects to the test data in (TDI) of the next, and so on. Test clock and (TCK), test mode select (TMS) and test reset (TRST), if present, are effectively in parallel. The balloons illustrate the variety of tests and programming applications that can be developed using boundary-scan.

Similarly, developers of embedded systems firmware will no doubt know JTAG as a means of accessing the on-chip debug features within microprocessor, RISC, and DSP cores.

Now though, a growing number of hardware designers and developers are realising the potential of the hidden boundary-scan features, utilising the technology as a means of debugging prototype hardware, but without access to a large production tools budget. Moreover, this user group greatly benefitted from a step-change in the world of boundary-scan when, in 2009, a family of no-cost/low-cost boundary-scan debug tools called JTAGLive was launched.

These were, for the first time, aimed more specifically at design engineers and are able to make use of existing design interface hardware such as Altera’s USB Blaster, Xilinx’ programming cables and FTDI chip’s embedded USB to JTAG device. What’s more, the basic ingredients, i.e. models, needed to set-up these tools are simply the boundary-scan description language (BSDL) files; readily available from IC vendors’ websites and other online repositories. No other EDA information such as a netlist or BOM is required to start testing.

For any design that features one or more boundary-scan compliant components designers can choose from several debug tools depending on their needs or budget.

The first is a free-of-charge, entry level tool called Buzz, so called as it affords practically instant pin-to-pin continuity tests (akin to buzzing out with a DMM). Also, up to 10 nets can be exercised in a measure mode. Using the boundary-scan SAMPLE instruction users can also monitor activity (asynchronously) on any given pin; just as you would with a logic probe.

Users can, for a fee, augment their system with AutoBuzz, which can learn the connection data from a known good PCB and use this as a reference against which faulty boards can be assessed. This unique "seek and discover" mode of working boards means that users only have to supply data on the boundary-scan parts (BSDL models) and do not have to source net connection information of other device data. Since its introduction in 2011 AutoBuzz has proved a success in design labs and repair centres alike.

Another tool, Script, provides a command and control structure to manipulate and sense cluster I/Os. Specifically, it can be used for functional, device-oriented test. For example, it can be used for testing mixed signal parts, operations that require user intervention or looping test patterns to set up device registers. Script uses the open-source Python™ programming language popular throughout the engineering world due to its easy syntax yet powerful data manipulation capabilities.

Creating test modules in Script promotes device-orientated testing and hence re-use of test code. Using Python open-source means that thousands of auxiliary routines can be obtained from a now well established user community.

The most recent addition to the JTAGLive range is CoreCommander. Unlike traditional JTAG/boundary-scan tools, CoreCommander functions control pins not by the conventional, serial boundary-scan register (BSR), but by taking control of a processor’s core, usually via the device’s on-chip debug (emulation) mode.

In some instances, devices have a JTAG port solely for on-chip debug and do not feature any boundary-scan logic for test purposes. However, users can still perform a degree of testing via CoreCommander which can be synchronised with fully compliant JTAG/boundary-scan parts. CoreCommander currently supports devices with the following cores ARM 7/9/11, Cortex, plus PowerPC, X-scale, and some TI DSPs

More Automation

In addition to the arrival of free and low-cost tools, the industry has also seen the introduction of attractively-priced software and hardware bundles aimed at the designer-cum-test engineer.

Typically systems include a highly automated test program generator for infrastructure and interconnects that takes advantage of a library of thousands of non-boundary-scan (a.k.a. cluster) device models to create a safe, high-quality foundation test.

Additional features for developing cluster tests and in-system device programming are also likely to be included. The use of scripting languages, such as Python™, further increase the capability of the tool and adds more sophisticated test options for logic clusters and device programming. Flexible licencing terms for these bundles can bring JTAG/boundary-scan testing within the reach of many more companies and institutions as a result.

To illustrate the ease of getting started with modern tools, here is a summary of the process needed to get the base-level interconnect test up and running:

Import net data: Following start-up, a project guide typically prompts the user to add netlist information that is usually gathered from the designer’s schematic entry tool. The best systems allow multiple netlists to be added to a project making it simpler to support stacked designs comprising main boards and mezzanine cards and/or system cards in a plug-in back-plane.

Add device details: To complete the picture, device models are then assigned to the netlist-derived device types list (Figure 2). Models are of either BSDL-type, in the case of the JTAG devices, or ProVision models (with .model extensions) for the non-JTAG (cluster) devices. To aid re-use, the device model assignments can be exported as a model map and kept for use in future projects.Figure 2: Assigning ProVision and BSDL models to the netlist-defined device types.

Press the "go" button: With models assigned invoking the automatic program generator for interconnect testing is a fully guided process. The generator dialogue box also offers a number of test pattern options for the advanced user.

Read the results: Following a test execution, results are displayed in a Truth Table Reporter (TTR – see figure 3). Each net is displayed showing the status of each boundary-scan driver/sensor at each vector level. Any sensor error is highlighted to enable speedy identification of faults such as net or pin ‘stuck-at’ faults or net shorts. The TTR also has advanced modes, such as device-by-device vector displaying.Figure 3: The truth table reporter (TTR) for visualising faults such as net or pin "stuck-at" faults or net shorts.

An interconnect test can often contribute over 80% of a digital board’s fault coverage if most of the high pin-count parts are JTAG (IEEE Std.1149.1) compliant. Moreover, using the Python Scripting and other software modules, users can ‘"op-up" the fault coverage to get figures of up to 95% of nets and pins tested by implementing cluster tests (a type of functional test targeted at a specific device or device group).

Cluster tests typically target devices such as memories, flash parts, SPROMs, ethernet PHYs, and other register-based parts and can be used for structural test as well as in-system programming. Of course, there will always be a proportion of interconnects such as power connections to regulator parts and so on that are not tested. However, it is likely these will have been inspected visually and/or tested functionally.

The Future

As more and more designers see the benefits of improved time-to-market, thanks to a less frustrating debug phase, the use of JTAG for hardware debug is expected to increase rapidly and the cost of tools will fall even further.

In the near future you can also expect that the on-chip debug features of processors will provide opportunities to increase test coverage and will be joined by built-in self test (BIST) logic cores (for example embedded into FPGAs) that will provide at-speed testing of peripherals such as DDR memories, etc. Further additions to the JTAG standard including IEEE Std. 1687 should also define mechanisms to access embedded ‘test instruments’ to offer even more value via the tried and trusted JTAG port.

Peter van den Eijnden is co-founder and director of JTAG Technologies in Eindhoven, Netherlands. He graduated in 1981 from the Eindhoven University of Technology in Electrical Engineering/Digital Systems. After graduation, he has worked as a scientist at this university and taught at the New Teacher Training Group several years of research and teaching in the field of microprocessors, circuit theory, and design of programmable logic and ASICs.From 1985 to 1993 van den Eijnden was employed by the Philips testing equipment group and was involved in the development of ASICs and microprocessors emulators and logic analyzers, and was project manager of the boundary-scan test equipment development and later director of that group. JTAG Technologies was founded by van den Eijnden and a partner in 1993.