CONNECT NEWSLETTER

New Stuff on
asset-intertech.com

asset-intertech.com

TEST DATA OUT

Some considerations for system-level JTAG
By Mike Westermeier
Senior Applicatons Engineer
ASSET InterTech

System-level boundary scan is attracting the attention of more and more equipment manufacturers these days and for good reason. The benefits can reach from prototype debug in design and development, through system commissioning in manufacturing and into the marketplace where systems are supported by field service organizations.

The benefits of system-level JTAG are truly far reaching. For example, even if the initial intent is to only enable remote reprogramming to reduce module updating costs, with the capabilities in place, system-level JTAG can be leveraged throughout the company in many other ways. It can be very useful in environmental testing, for instance. Many companies use techniques such as HALT (Highly Accelerated Life Testing) or other environmental tests as part of design validation. If a manufacturing fault is detected, system-level JTAG diagnostics can identify net- or pin-level faults and eliminate the time the test group might spend trying to find a design fault. System-level scan, once it has been deployed, will be available in the environmental test chamber at whatever temperature or stress the system is subjected to.

For a manufacturer to reap all of the benefits of system-level JTAG, early planning must take place across multiple disciplines within the organization. That means a planning team made up of board designers, test engineers, system designers and architects, manufacturing engineers, quality and reliability engineers, field service and repair engineers.

Define the Requirements

In many cases, the process will begin with company-specific cost justification analysis. These exercises will lead to a commitment on the part of all concerned organizations within the company to system-level JTAG. A cross-discipline project team is usually formed and, as a first step it defines a set of basic considerations. These would include issues such as: Will the system’s JTAG infrastructure be used when the system is online or offline? If so, for what purpose? Test, and retest, or to reconfigure on-board programmable devices? If test is the primary purpose of system-level JTAG, what level of precision should the tests address? (That is, what is the smallest replaceable unit in the system?) What’s the organization’s tolerance for average response time? What’s the tolerance for average system down time? How would system-level boundary scan affect the system’s warranty and warranty costs? Answering these types of questions will establish the backdrop against which a system-level JTAG suite of operations, embedded or applied remotely, can be developed.

Next, the team must decide the aspects of the system that system-level JTAG will test. This will include questions like: Are all of the boards, daughter cards and subassemblies present and, if they are present, are the correct boards and assemblies installed in their proper places? Are boards and other elemental units in the system properly connected to any system-level buses? Are functional interconnects working properly? Are boards and assemblies working correctly?

Typical testing procedures should also be discussed. Will the system be tested automatically at power up? Will it be tested in background mode? If boundary scan operations are embedded, will they only be launched on demand by service engineers? Will the tests be simple pass/fail tests or pass/fail tests followed automatically by diagnostic routines? In addition, if system-level boundary scan will perform in-system programming, the types of programmable logic devices and memories in the system must be identified and planned for. Also, how will the backplane or any system-level buses be tested?

Design-for-System-Test

Since the early days of JTAG, design-for-test (DFT) has been a critical concept that has eased the deployment of boundary scan technology. System-level JTAG is no exception to this. Implementing system-level boundary scan begins during a system’s design phase.

Embedded boundary scan operations can be implemented by scan controllers or built-in self test (BIST) sequencers on every board or other elemental unit in the system.

With embedded scan controllers, the following procedure would be followed: a master embedded scan manager would first interrogate each board to determine the types of boards configured in the system. Then, based on the board types, the appropriate tests would be assembled by the in-system embedded scan manager. And lastly, the appropriate test or programming operation would be applied by each board with the assistance of a local microprocessor. In this type of scenario, tests will usually be stored in system memory or downloaded from system storage devices and delivered by way of a primary test bus across a backplane to the board-under-test. The delivered vectors will test the integrity of the board itself as well as its connectivity to the rest of the system. Since test vectors will be stored in-system, they will likely be compacted and stored in a binary file format such as BIST vector format (BVF).

Implementing a BIST sequencer would not require the assistance of an on-board microprocessor throughout the test process, but significant on-board or system-level memory would be required for the BIST actions. The BIST sequencer would support a full complement of board tests, including device-level BIST vectors, which could be initiated at power-on, by a command from the system’s scan manager, or by resetting the board or system.

Local and/or Remote Test Access

Another design consideration is how a JTAG test system such as ScanWorks will access the system-under-test. In some cases, local and remote access may be needed. Local access allows a technician to directly connect a laptop computer running ScanWorks to the system under test. The technician could select the tests to perform as well as any follow-on diagnostics that might be needed, ensuring a thorough test process. As an alternative, some portion, such as an executive kernel, of a boundary-scan system like ScanWorks could be integrated directly into the system.

Remote test access would allow the boundary-scan test system to access the system-under-test via the Internet or another wide-area communication link. Remote test access raises the question of which communications protocols will be used. Moreover, some test processes may be embedded with the system while others are streamed from a remote test station. For example, simple pass/fail routines may be embedded for easy and fast application, while more complex diagnostics and programmable logic re-configuration routines are applied remotely over a communications link since these will only be applied on an as-needed basis.

Architectural Issues

By and large, most embedded system-level boundary scan deployments will be based on a hierarchical multidrop architecture. (See figure below.) In such a scheme, a boundary scan gateway device interfaces each elemental unit in the system to the system’s maintenance bus. The multidrop architecture allows all boundary scan signals to be routed to all units in the system. Each circuit board or assembly with an addressable JTAG gateway device is capable of recognizing the boundary-scan information intended for it, which it uses to configure its local scan paths and to apply local boundary-scan tests or programming operations.

Boundary-scan gateway devices are available from a number of semiconductor vendors or gateway functionality can be implemented in a PLD from an intellectual property (IP) core. Vendors that supply off-the-shelf JTAG gateway devices include Firecron Ltd, National Semiconductor, Texas Instruments and others.

A hierarchical multidrop architecture raises the issue of master/slave arrangements among the units in the system. Several different types of arrangements are possible, such as one master/multiple slaves, multiple masters and peer-to-peer. Each has its advantages and disadvantages, but many deployments of embedded system-level boundary scan will employ a single master/multiple slave arrangement.

With a designated master embedded JTAG executive, the system can be remotely tested, re-programmed or re-configured. Moreover, the system can be monitored in real time. Of course, having just one JTAG master represents a potential point of failure with no failsafe redundancy. In addition, the JTAG master requires software capable of coordinating the embedded boundary-scan operations of the entire system. Memory storage space will be needed to store this software as well as other functionality and the results of JTAG operations.

Other Design Considerations

To retain flexibility in the final configuration of an individual system, system designers may want to ensure flexibility in the configuration of internal scan chains. Parallel serial chains, multiple independent chains, dynamically reconfigurable secondary scan chains and other scan chain infrastructures may be needed to support the system’s configuration when it is deployed to the field.

In addition, implementing other boundary-scan-based test or programming standards such as the IEEE 1149.6 Boundary-Scan Standard for Advanced Digital Networks or the IEEE 1532 Standard for In-System Configuration will bring their own sets of design considerations to ensure the proper deployment of these standards. Careful system-level design practices must be followed so that the system conforms to the requirements of all standards.

Another consideration is the length of the system’s scan chains. Shorter, more manageable scan chains are sometimes preferred because they enable faster access to FLASH devices for shorter programming times as well as their better support for related test techniques such as functional microprocessor emulation test. Shorter scan chains can be achieved relatively easily by designing in JTAG gateway devices that are capable of managing multiple scan chains. (See figure below.) For instance, a gateway device can break one long scan chain on a circuit board into several shorter chains. The gateway device then manages access to each of the shorter scan chains on the board.

System-Level Boundary-Scan Tools

Transitioning tests and programming operations from a boundary-scan development platform to a system-level implementation in the field will be easier to accomplish if the same boundary scan system is employed throughout the process. Fortunately for ScanWorks users, ASSET’s system has many of the tools they will need to deploy system-level JTAG. In addition, ASSET’s engineering and support personnel have worked closely with several large manufacturers to help them design-in and deploy system-level JTAG. This acquired expertise can be applied by companies that are just getting started with system-level JTAG to accelerate their implementations.

The Value of System-Level JTAG

When system-level boundary scan test and programming is planned for and it becomes an integral part of a system’s infrastructure, significant value can be generated for manufacturers and users during every stage of a system’s life.

To take full advantage of system-level embedded boundary scan, planning must be done during the system’s design stage to ensure the needed resources are present. Once this is done, the JTAG system infrastructure is available for enhancing diagnostics, assisting system start-up, remote monitoring, redundant access and a wealth of other possibilities that are limited only by the system designer’s imagination.