Boundary scan goes underground

If you use boundary-scan for manufacturing test and configuration, you already have a great deal of boundary-scan infrastructure embedded in your chips, boards, and systems. You can put that infrastructure to good use throughout your product's life cycle if you take the next step and embed hardware and software boundary-scan controllers, test patterns, logic reconfiguration operations, and other facets of the technology.

The motivation behind embedding and applying boundary scan across a broader, system-wide spectrum is significant cost savings. For example, making a field upgrade to the firmware stored in programmable logic devices or flash memories might require a veritable army of field engineers and untold hours of labor. Instead, with embedded boundary scan and a little planning, you can use the Internet to upload firmware upgrades to systems in the field. In the same way, remote diagnostics could determine the cause of a poorly performing system, isolating the fault before a technician is dispatched or perhaps eliminating the need for an onsite technician altogether (Figure 1).

Figure 1.  Embedded boundary scan supports local as well as remote system troubleshooting and reconfiguration.

Embedding boundary scan

Embedding boundary-scan operations into a system implies that the system has the ability to execute JTAG operations independently of any other system, test controller, or boundary-scan engine. Of course, this capability does not vitiate the importance of externally applied boundary-scan operations. The bulk of JTAG operations are applied to the unit under test (UUT) or the unit being programmed from an external boundary-scan system linked to the UUT by a standard cable connection. Embedded boundary scan can certainly be used in both manufacturing and field service, although most embedded boundary-scan applications are limited to pass/fail testing. Pass/fail tests can be useful in a manufacturing setting to identify problems. Then, the more extensive diagnostic capabilities of an external boundary-scan system can be applied to diagnose failures offline from the manufacturing process.

To embed boundary scan, you must design some of the capabilities of an external boundary-scan engine into the system. To what extent you embed the facilities of an external JTAG system into a particular product will depend on how embedded boundary scan will be used once the product is in the field.

At a base level, embedded boundary scan requires the capabilities of a run-time JTAG engine and storage space for test vectors and programming algorithms. Figure 2 shows a typical scenario where a stand-alone boundary-scan system in the factory generates JTAG test patterns and programming algorithms, converts them to a compact binary format, and stores them in the system before it is shipped to the field. An embedded run-time engine assembles boundary-scan operations and passes them to a scan engine for application on the system.

Figure 2.  In a typical embedded boundary-scan test flow, boundary-scan software generates test vectors and converts the resulting serial vector format (SVF) information to binary test vectors stored on the system under test. An embedded test program applies the vectors to the hardware under test.

Test results may be reported as simple pass/fail results and communicated to a predefined location outside of the system. For this case, you need little in-system memory to store test results. If you intend the tests to trigger follow-on diagnostic routines, then you'll need to provide more memory to store test results in-system.

Systems with embedded boundary scan will typically consist of more than one circuit board or subassembly. Often a backplane is involved. Architecturally, you must determine how best to implement the boundary-scan interface across multiple circuit boards and subassemblies. You might choose star or ring architectures, but both have inadequacies. Most often, a multidrop architecture is effective for deploying embedded boundary scan.

Figure 3.  A multidrop architecture routes boundary-scan signals to all system boards. In this “single master, multiple slaves” configuration, an embedded JTAG master on one board controls system-wide boundary-scan operations. For fail-safe redundancy, you can choose to embed a JTAG master on each board. Boundary-scan signals can travel over a backplane or along dedicated paths.

Once you have established a multidrop architecture for embedded boundary scan, you can locally configure the elements in the system in any of four ways:

• No master, all slaves. With no master over JTAG operations, an external boundary-scan bus master or controller must apply the boundary-scan operations. A commercially available boundary-scan test system generally manages all boundary-scan operations, so you don't need to dedicate an onboard processor to that task, nor do you need to develop coordination software for a master processor. And since the external system monitors the results of the boundary-scan operations, you need not provide in-system storage for those results. The tradeoff for not having a master processor, however, is that a technician must connect an external boundary-scan system to the unit under test to execute the boundary-scan operations.
• Single master, multiple slaves. With an embedded JTAG master processor in a multidrop architecture, the system can be remotely tested, reprogrammed, reconfigured, or monitored in real time. Of course, having just one JTAG master represents a potential point of failure with no fail-safe redundancy. In addition, the JTAG master processor will require software for coordinating embedded boundary-scan operations. And the system will require memory for the software as well as for storing the results of JTAG operations. Because of the system-specific nature of embedded boundary scan, the embedded JTAG master processor is usually a proprietary program developed by the user specifically for the system under test. The JTAG master supports the communications link between the system under test and any remote boundary-scan test or diagnostic system.
• Multiple masters with a backplane. For a mission-critical system, you can design in multiple JTAG masters for fail-safe redundancy. In addition to requiring the other facets of a single master configuration, multiple masters would need software to facilitate an effective handoff from one master to another should the initial JTAG master fail. A variety of standard programming tools can be used to develop these embedded application-specific capabilities, but close consultation with the boundary-scan system provider will ensure that the embedded boundary-scan processes conform to the requirements of the JTAG standard while minimizing the internal resources devoted to embedded boundary scan.
• Multiple masters without a backplane. If you want to keep the JTAG signals off the backplane, you can provide a JTAG master on each circuit board or subsystem. Each JTAG master is connected to an external communication link through which you can initiate boundary-scan operations and retrieve test results. All boards can be tested or reconfigured simultaneously. This approach eliminates the need for a JTAG gateway device on each module, but it increases the complexity of JTAG operations because test vectors and programming algorithms for module-to-module operations must be put together for the entire system instead of a single module at a time. This approach still supports remote monitoring, testing, and programming.

Deploying embedded boundary-scan test as well as in-system programming and reconfiguration of PLDs raises additional questions beyond those involving the architecture. For example, will the configuration of systems in the field be static, or could new circuit boards or assemblies be introduced to alter the configuration at a later time?

A static system-level configuration simplifies the implementation of embedded boundary scan since the composition of the embedded boundary-scan operations is not subject to change. But if the system configuration is dynamic, as it is with most computer and communications systems, then its suite of embedded boundary-scan operations could change every time a new circuit board or subassembly is installed.

Even a system with a static configuration can require sophisticated boundary-scan test-management software. For example, in a system that contains different versions of the same circuit board, the boards could have different boundary-scan characteristics. The test-management software would have to determine the version number of the boards in the system before configuring a set of tests.

This implies the need for a repository of object-oriented boundary-scan modules that can be assembled to match any system configuration. In addition, the embedded JTAG run-time engine and scan engine must be made aware of the new configuration and adapt the system's boundary-scan operations accordingly. Of course, the question of how executable boundary-scan modules are downloaded from a central repository to a reconfigured suite of JTAG operations in a system in the field leads to issues of protocols and other facets of data communications.

Communications mechanisms also come into play with regard to remote access for firmware downloads, real-time monitoring of system status, and the application of JTAG tests and diagnostics. Consultant Ben Bennetts and representatives of system manufacturers, boundary-scan companies, and semiconductor vendors have begun ad hoc discussions on standardizing the communications protocols supporting embedded boundary scan (www.dft.co.uk/SJTAG/), but at this time, no formal study group has formed.

Of course, with a system-wide BIST capability based on embedded boundary scan, you must define how the system reacts to test results. For example, the system might launch a regularly scheduled structural test suite and discover a malfunctioning device that is critical to the overall operation of the system. This test result could set off an alarm that technicians in a centralized monitoring facility could handle manually. Or the system itself might launch a diagnostic suite that determines that the firmware in a certain PLD has been corrupted. With this information, the personnel in the monitoring facility could download a new image of the firmware via the system's embedded boundary-scan infrastructure, making it unnecessary to dispatch a service technician.

Boundary scan has been applied in board-level test and in-system programming applications for more than 10 years. The technology is well understood and well supported by tools that simplify the development and application of JTAG operations. As a result, the transition from board-level to system-level and embedded boundary scan is a natural progression.

Indeed, in some cases the board-level infrastructure may already be in place to ease the transition to embedded system-level boundary-scan operations. If board-level boundary-scan operations have already been deployed for manufacturing test, much of the work that has been done developing the board-level JTAG tests and programming algorithms can be re-used in a suite of operations for the entire system. The resulting payback for system-level embedded boundary scan can be quite rapid.