Scaling JTAG architecture to cope with evolving systems

Most complex electronic systems take advantage of the IEEE 1149.1 (JTAG) standard in one way or another. If the system uses complex FPGAs or CPLDs, then they are almost certainly configured using the JTAG port. If emulation tools are used to debug hardware and software, the emulation tool most likely talks to the Microprocessor through a JTAG port. If Ball- Grid-Array (BGA) packaged IC devices are used, then JTAG is the most efficient technique to test the connections between the BGA devices and the underlying printed circuit board.

The IEEE 1149.1 Standard for Boundary Scan Test (often referred to as JTAG, 1149.1, or just “dot 1”) is an industry standard method for accessing test features on complex ICs and circuit boards. Compliant ICs and boards have a 4-wire serial bus (with a 5th, optional reset line) to support JTAG testTDI (test data in), TDO (test data out), TMS (test mode select), and TCK (test clock). This bus primarily enables structural testing of interconnects such as solder joints, board vias, shorts, opens. In addition to its use for structural test, many CPLD and FPGA manufacturers are using JTAG as a standard method for in-system programming or configuring their devices. JTAG supports not only structural (interconnect) test, but is now a well supported standard approach for enabling systemlevel access for configuration, programming, and mixed signal test.

But most design teams rarely make a complete leap of faith for new designs into JTAG; instead they prefer to take small manageable steps towards complete adoption. Some team disciplines make extensive use of this access while others use the access in a limited manner. Each discipline adapts JTAG to their needs. As each discipline joins the effort, these several distinct “generations” of JTAG adoption evolve, each characterized by a major enhancement in the capabilities that the JTAG access provides.

With all of these various JTAG access requirements, the development team must adopt a cross-discipline JTAG access strategy to maximize the capabilities of JTAG access. This strategy is necessary to enable a standard approach that can be re-used and built upon in later generations of the product. To understand this approach better, let’s consider how JTAG is used in the various generations of system development and design with the goal to evolve designs to the next generation by continually building upon the previous experiences or investments in JTAG access.

Generations of JTAG

In the first generation of JTAG adoption, some of the JTAG features or capabilities on the board are being utilized, but there has likely been little effort to coordinate or standardize this approach.

This is typically a minimalist approach with little to no investment in software tools, usually free IC vendor tools are used where available. Typically there are limited or no diagnostic capabilities, or software for generating vectors for test or programming. The JTAG access is used only in production for configuring CPLDs or programming flash memory. More complex cards may use it for test as well.

Surprisingly this approach may not be the lowest cost. Each discipline likely specifies a separate header just for their needs, so multiple JTAG headers are placed on the board, adding cost and tying up board space. And each discipline may be developing their own “homebrew” software tools and hardware to interact with the JTAG features, often redundantly to other disciplines. This method is very difficult to migrate into the next generation of product because of its custom development. If used during production, it adds cost because multiple insertions are required.

Many development teams get stuck at this generation. Eventually a JTAG access strategy becomes necessary to remain competitive if system complexity continues to increase.

Generation 2

In Generation 2 of JTAG adoption there is joint effort across development team disciplines to manage access to JTAG capabilities for a new board design. There is an investment at some level in ATPG (Automatic Test Program Generation) software tools with robust diagnostics for managing programming and test vector development and delivery. Suppliers of these ATPG tools offer services and support from simple per-job vector generation services and consulting up to multi-seat full software suites for production.

Figure 1. Generation 2: Using a JTAG multi-drop multiplexer to simplify access to multiple JTAG chains.

Click to Enlarge

To eliminate multiple 1149.1 headers on the board and manage multiple JTAG paths, a single strategic IC component is added to each board: a JTAG multiplexer device. The JTAG mux device usually takes up less board space than a secondary JTAG header and makes it simple to isolate components or organize scan paths for efficiency of access.

For instance, it may be desirable to isolate FPGAs from different vendors onto separate scan chains to simplify access by each vendor’s tools. It is also desirable to place the microprocessor onto a separate chain to maximize speed while emulation tools are being used to debug software, or during flash programming. These devices are well-supported by the ATPG vendors, so software support is generally simple and turn-key.

Now our Generation 2 design has a single point of JTAG access, and with this basic configuration a simple PC-based system can be used for all emulation, configuration, programming and 1149.1 test of the entire card, at a single test station, during a single insertion.

One additional and innovative new use of the JTAG bus emerges at this stagethe ability to use this access at all stages of the product life cycle. Entire board-level vector images can be archived for reprogramming or debugging cards when field service is necessary. This same access can be used in the field for FPGA firmware updates or for diagnosing a problem to an FRU (Field Replaceable Unit). Equipment returned to the factory for failure analysis can use the same vector images (and factory or development test station) to isolate the problem.

If there is any shortcoming to this generation it is usually that the development team still has a single-card mentalitywhich is a perfectly normal perspective given that the design team responsibilities usually end outside of their card and its interfaces. Failure to evolve to Generation 3, however, establishes a bottleneck and limits the use of JTAG access for multi-card capabilities.

Figure 2. Generation 3: Extending the JTAG bus across the backplane for accessing multiple cards.

Click to Enlarge

Generation 3

The next generation of JTAG access is achieved when JTAG features can be exploited at the multi-card system level across a backplane. In this environment the card-level JTAG capabilities can still be independently accessed, but inter-card features may now also be utilized. This generation of JTAG adoption not only forces cooperation across the disciplines at the board level, but also across board design teams for the entire system. If a JTAG mux was adopted at the prior generation, then the mux device typically supports multi-drop access. Using an addressing scheme, the serial JTAG bus can be used in a multi-drop configuration, supporting multiple cards. With JTAG access to multiple cards on a backplane, system-level configuration or programming can be accomplished (i.e.; multiple cards can be accessed in parallel).

The integrity of backplane interconnects between cards can also be tested or high-speed LVDS serial links between cards can be verified if JTAG accessible at-speed BIST is a feature of the driver/receiver pair. Or access IEEE 1149.6 test when the high speed interconnects are capacitively-coupled and the driver/receiver support this feature.

All these JTAG features can be accessed using the same equipment as in previous generations a PC-based JTAG station can act as the JTAG master through a single connection to the backplane JTAG header. This master drives the vectors and manages the access across the backplane to the JTAG features.

Perhaps the most interesting new capability added at this generation is that the entire system can also be accessed through this sideband JTAG channel while the system is operating. This enables a host of new system-level abilities, such as on-line health monitoring, prognostics, fault detection, fault insertion (for failover or redundancy testing), and diagnostics. All levels of the organization should be encouraged to exploit the JTAG architecture at this generation to maximize the investment in JTAG for multiple cards.

Generation 4

The highest level of implementation, Generation 4, occurs when the vector delivery and management is embedded within the system itself. At this level, an onboard JTAG master is used to drive the backplane JTAG bus. Onboard memory for vector storage and a microprocessor are employed to drive the JTAG master. A multi-card system level master may reside on a separate card, or the master can reside on each card for more power.

Figure 3. Generation 4: Embedded external JTAG master in a multi-drop environment.

Click to Enlarge

At this generation all the capabilities of previous generations can be accessed remotely, including programming, configuration, interconnect test, and diagnostics significantly lowering field service and support costs. When it’s time for a firmware upgrade in a fielded system, new configuration files can be downloaded to the JTAG master for delivery across the backplane JTAG bus to the target device. Naturally the PC-based JTAG access station can still be used during production by disabling the master, further maximizing flexibility and access options at all levels of integration.

Use of the JTAG access can be initiated either externally or internally, or by some system event, for example, power-on or power reset.

Summary

By far the biggest hurdle to JTAG adoption and integration is recognizing that a strategy is needed across multiple development disciplines, and then convincing management of the economic benefits. Once this step has been initiated and initial adoption of ATPG support and a JTAG mux device is completed, it becomes easier to evaluate or implement additional new JTAG capabilities one small step or generation at a time. Building upon prior successes and knowledge of JTAG adoption allows the development team to maximize the utility of the JTAG bus.

Increasing the complexity of the JTAG architecture doesn’t have to be a burden to the system instead, JTAG can be used for its full value: as a well supported, industry standard way to access system-level test, programming, configuration, and health monitoring features in modern complex electronic systems.