November 20, 1997

Program ICs in your system via IEEE 1149.1 and enjoy the benefits throughout the system's life

Matt Boutin, Stratus Computer and Dave Bonnett, Asset InterTech

Programming ICs in-system solves many problems for system manufacturers. If you use ICs that you can program via the IEEE 1149.1 test-access port, the benefits extend beyond production testing into the field.

Programmable components, such as logic devices, FPGAs, flash-memory chips, and microcontrollers with em-bedded memory, have grown in popularity over the past five years. The ICs' popularity results from the system-configuration flexibility that they make possible. The care that these ICs require in handling, assembly, and warehousing can cause problems, however. By incorporating in-system programming (ISP) into the production flow and using IEEE 1149.1 boundary scan as the access method for ISP, system manufacturers can reduce, if not eliminate, most of these problems.

ISP involves loading software, data, or both into programmable devices after mounting the devices on a pc board. To properly use this technique, designers must observe certain precautions from the beginning of a system's design.

ISP benefits

ISP eliminates three major problems with conventional programmable devices. First, without ISP, you must preload software or data into programmable devices before board assembly. Board assembly can then introduce errors into the system-level product's software or data. Second, without ISP, assembly personnel must remove from pc boards devices whose contents have become corrupted. They must then reprogram the devices and reinstall them--a labor-intensive and error-prone process. Third, ISP obviates the need to manage an inventory of programmable devices. Devices that you program before board assembly seem to be identical but actually are several versions, each containing different data. You should handle the programmed ICs as if they were the different parts that programming created.

The payoff from ISP takes several forms. First, board costs go down because many previously socketed programmable devices no longer require sockets. Second, manufacturers can integrate device programming into the normal production work flow and thereby avoid the costs of sending parts outside for programming. Third, if the system manufacturer uses a boundary-scan tool set that works during all phases of a product's life cycle, software and firmware enhancements no longer wreak havoc on assembled-board inventories. By using ISP to reprogram devices, you can upgrade firmware on boards already in systems as well as on boards in inventory. Board swapping for field upgrades thus becomes unnecessary. Boundary-scan-based ISP is more attractive than its alternatives: performing ISP using automatic-test-equipment (ATE) systems' nodal-access methods or using vendor-specific programmers' serial protocols.

Using the boundary-scan path for access bases ISP on a fully defined and broadly applicable industry standard. Someday, one ISP method may program all devices that conform to the IEEE 1149.1 standard. So far, though, you can't take for granted that identical methods can program different vendors' IEEE 1149.1-compliant ISP parts, even though the parts behave identically after you program them.

Several boundary-scan tool sets offer capabilities that suit them for use throughout a product's life. Most such tool sets consist of low-cost hardware units and accompanying software. You might use one such tool set to perform ISP during the design-debugging phase. Manufacturing might then use the same tool set during final system testing. When the system is in customers' hands, support and maintenance personnel might use the same tools to test and modify embedded software without removing devices or boards from the system (Figure 1).

In many cases, a system manufacturer may already use boundary scan for static manufacturing tests and diagnostics. In such cases, boundary scan is an easy choice for ISP. Manufacturing tests and ISP can take place during the same step in the manufacturing flow. Technicians who know how to use boundary scan for testing need little training on how to use boundary scan for ISP.

IEEE 1149.1 provides a good starting point from which programmable-device vendors can migrate from proprietary programming-data formats to a common format for ISP. Several activities address the need for an industrywide ISP-data format. A coalition of test-equipment, programmable-device, and programming-equipment vendors has been working with the IEEE through an 1149.1 subcommittee to devise a standard ISP-hardware architecture. A complement to this effort is the recently proposed ISP language, Jam, which will be compatible with all current ISP devices. Jam, an interpreted language optimized for use with a boundary-scan path, aims to provide a device-hardware-independent ISP-software standard that boundary-scan tools will support.

Additionally, several programmable-device vendors already create ISP files using the Serial Vector Format (SVF) open standard. Most boundary-scan test systems can apply SVF files to programmable devices. Texas Instruments (Dallas) developed SVF, and Asset InterTech now maintains it. Because SVF was not originally a programming format, the SVF specification required revision to support programming delays and other ISP features. Asset InterTech welcomes additional input on SVF from interested parties in the industry.

Alternative ISP methods

Once you choose the IEEE 1149.1 test-access port (TAP) for ISP access, you must think about your programming hardware. Your choices are PC-based boundary-scan test stations, traditional in-circuit testers (ICT--a form of ATE), and IC manufacturers' proprietary programmers.

You can use ICT systems for ISP, but doing so ties up expensive manufacturing-test systems for tasks that the ATE designers did not originally have in mind. Most board manufacturers hold down costs by jealously limiting the time a board spends on an ATE system. For ISP, PC-based boundary-scan stations can be more cost-efficient than large ATE systems. You might think that, because ATE systems can perform ISP faster than can PC-based programming stations, ATE systems would be more cost-effective. In addition, if you use ATE for board testing, using different equipment for programming adds the cost of another handling step. Still, PC-based test stations often show a cost advantage. For example, a PC-based programming station that is one-fifth as fast as an ATE system might cost only 1% as much.

Moreover, because PC-based boundary-scan stations are relatively inexpensive, companies that can afford only one ATE system can afford several boundary-scan stations. These companies can thus simultaneously program multiple boards. If these companies used their one and only ATE system for programming, they would have to program the boards one by one. Most important, unlike ATE systems, which normally remain in manufacturing, PC-based boundary-scan stations support ISP and testing in design, in manufacturing, and in the field.

Another ISP alternative is to use device vendors' proprietary programmers. This approach poses several problems. A pc board that contains programmable devices from several suppliers requires separate access paths and connectors for each supplier's parts. In addition, each vendor's proprietary ISP method specifies its own data formats. The board manufacturer must buy several sets of tools, and manufacturing and test personnel must learn to use all of those tools. Also, unlike boundary-scan-based ISP, which uses optimized controller hardware, vendor-specific programmers can be slow because they usually interface to the controlling PC via the printer port.

Design considerations for ISP

When you design boards for boundary-scan-based ISP, you should consider several aspects of the design to ensure that you can take advantage of boundary scan throughout the system's life (Figure 2).

The four IEEE 1149.1 TAP signals--test clock (TCK), test-mode select (TMS), test data in (TDI), and test data out (TDO)--are digital signals just like the functional signals on the circuit board. Because the TAP signals switch at rates as high as 15 MHz, you must design them carefully. Proper buffering, termination, and routing are just as critical for boundary-scan signals as they are for functional signals. A built-in-test feature, such as boundary scan, should be the most reliable part of a system.

When you place unprogrammed devices on a board, the board's power-up condition differs dramatically from its condition after you program the ICs. To avoid problems with boards that contain unprogrammed ICs, use programmable devices on which you can set all output pins to a high-impedance state during programming. Also, provide proper pullup and pulldown networks to prevent floating signals from damaging devices. If you fail to connect the programmable-device inputs to proper pullup and pulldown networks, damaging board states are a real possibility until programming is complete.

Boundary scan is a relatively new concept for many programmable-device vendors. Not all boundary-scan tool sets fully support every programmable device. You must be careful to team programmable devices with tool sets that support them. Most device vendors recognize that boundary-scan ISP tools do not support certain devices. The vendors are working with the IEEE 1149.1 subcommittee and boundary-scan experts to resolve the problems.

Another aspect of ISP that affects a board's design is that programming requires more current than does the board's normal operation. You must choose the power and ground sources and design the power planes to handle the necessary power during programming. Power is an especially important consideration during concurrent programming of multiple devices.

ISP in manufacturing testing and elsewhere

You can effectively incorporate the procedures for using boundary-scan-based ISP into a system's normal manufacturing flow. Many electronics manufacturers already make extensive use of boundary-scan testing as part of their normal manufacturing flow. Adding ISP is a logical extension of boundary-scan testing.

Integrating ISP with manufacturing testing requires careful planning. ISP adds time to the manufacturing process, and time is always critical in manufacturing operations. ISP should disrupt the normal flow as little as possible and should cause no bottlenecks. The typical manufacturing process starts with board assembly and inspection. After that come board testing, environmental-stress testing, and then system assembly and final testing. Board testing is typically a combination of ICT and PC- or VXI-based boundary-scan testing, which provide manufacturing-defect analysis (MDA) and a high level of fault coverage. Normally, only military and other high-reliability products undergo stress testing. You can run boundary-scan tests and PROM-based diagnostics during thermal cycling inside an environmental chamber. After environmental testing, the boards go into a system, where boundary-scan again verifies proper assembly.

Using boundary-scan testing at all stages allows easy device programming or reprogramming at any stage. Technical requirements and economics determine when to program the devices. Device programming typically takes place after manufacturing-defect testing, ensuring that you can safely apply power to the board. Both ICT and PC-based testers can easily perform ISP at the board level (see box "Production programming--a nickel an IC").

Creating programming files for use in ISP starts with traditional design tools that define the device configuration. The tester that programs the devices sometimes converts the configuration data directly into boundary-scan vectors. Alternatively, you can transfer the data into device-vendor tools, which produce files that the programmers accept. SVF and Jam are fast becoming the standard formats for ISP. SVF and Jam files contain the programming algorithm, including the required wait periods. Improper wait periods can cause premature device failure. Using device vendors' software to produce SVF or Jam files reduces the risk of failure, because the people who have the most intimate knowledge of the device characteristics create the software. Test vectors that programming tools produce from design data depend on someone else's interpretation of device vendors' published device-programming specifications.

Although manufacturing-cost reduction most often drives the use of boundary-scan-based ISP, using it in the field can also produce major savings. For example, a boundary-scan tool set that uses a PCMCIA hardware interface can load early developmental code into PLDs during beta testing at several customer sites. If the engineers at the factory change the PLD code, a technician at the remote site can reprogram the PLDs in a matter of minutes. Without ISP, the alternative is to take apart the beta systems and transport the PLDs to another site for reprogramming. This operation could involve days or weeks of downtime. In-system reprogramming of PLDs in the field requires a PC-based ISP system. If you use ATE for ISP, you have to remove the boards from the system to reprogram the PLDs.

In summation, boundary scan is the obvious choice for ISP, and PC-based testers are an economical means of using boundary scan for ISP. Careful planning during a system's design phase improves manufacturing and field-service efficiency.

Reference

1. Asset InterTech Inc, Standard Programmable Devices, www.asset-intertech.com.

Authors' biographies

Matt Boutin is a software engineer with Stratus Computer (Marlborough, MA), where he develops test protocols for the company's fault-tolerant computer systems. He has worked at Stratus for 10 years and has helped design systems based on the PA-8000 µP. Boutin, who holds a BS in information technology from the University of Massachusetts--Lowell, works after-hours as a firefighter and an emergency medical technician.

| EDN Access | Feedback | Table of Contents |