Implementing a Boundary Scan Methodology

When a global provider of air traffic, navigation, and landing system solutions began implementing its next-generation system, limitations of an existing test and debug methodology directly impacted the bottom line. But adding boundary scan testability to an existing product greatly reduced test and debug time.

More Efficient Test Methods Needed

Air traffic systems must be designed and built to maximize safe and reliable operations and meet stringent requirements of regulatory agencies while minimizing life-cycle costs over the service life of the equipment. Additionally, these products need to satisfy challenging and diverse operating demands and terrain. Because of these requirements, testing must be thorough and complete.

With low production run volumes, the complex systems required sophisticated testing by knowledgeable technicians and engineers. As next-generation technologies were implemented, the complexity of the systems increased, as did the test requirements. With the increase in complexity, test and debug time increased as well as overall product costs for a surveillance processing system.

The processing system board shown in Figure 1 comprises a 32-bit embedded processor, flash memory, an FPGA, ADCs, amplifiers, and buffers. Analog RF signals from an aircraft approaching an airport enter the board to be digitized and are sent to the FPGA for conditioning and preprocessing. The FPGA then sends the encoded information to the processor.

Figure 1. Surveillance Processing System Board

Under the existing test procedure, after a production run of the boards, each one was visually inspected at the manufacturing site. To ensure proper performance, sophisticated equipment and highly trained technicians were needed. But instead of providing these resources at the manufacturing site, interconnect testing and further debugging were performed in-house.

Upon receipt of the boards, a technician again performed a visual inspection and began a thorough testing process that typically would last two hours. Next, each board was manually probed to check resistive values to identify any problems that could not be found with visual inspection.

Then, power was applied to check voltage levels. Once a board was successfully powered up, programming the flash memory was attempted. If the flash programming was unsuccessful, an emulator and simulator were used to troubleshoot and identify the source of the problem. Previous product experience indicated that the problem might be in a buffer, the processor, or the flash itself.

Once the flash memory was operational, the board was put in a cabinet containing a test model of the complete system for functional testing. If a board did not pass these cabinet tests, the board was removed for troubleshooting.

Engineers would perform exhaustive calibrations and measurements with sophisticated simulations designed to thoroughly exercise functionality and register accesses. Problems discovered at this stage often were interconnect issues such as shorted or open nets. Sometimes, debugging one board would take several hours due to the complexity of the surveillance processing system.

Eventually, all of the boards would be repaired and become fully functional using this test and debug methodology, but the costs in manpower were significant. A new approach was needed.

A Boundary Scan Solution

Problems discovered on the processing system and other products had been difficult to visually or manually identify. Yet, once a problem was diagnosed, it often was a simple repair to correct an open or shorted interconnection or a cold-soldered connection.

In-circuit testing (ICT) could automate these kinds of checks, but a costly test fixture would need to be developed for each board type. And due to increasing board density, access to all test points was not assured.

The costs for test fixtures were prohibitive with respect to the low volumes of manufacturing production runs, and any engineering change order (ECO) on the product would require the development of a new or modified ICT test fixture. Further, manufacturers that serve low-volume product runs such as those for this processing system typically cannot justify investment in ICT systems. As a result, ICT often is not a suitable solution.

The connectivity problems discovered while testing and debugging the boards, however, were exactly the types of problems that the Joint Test Action Group (JTAG) had in mind when developing the IEEE 1149.1 boundary scan testing specification. As designed, the surveillance processing system contained two boundary scan test access ports (TAPs), one for in-system programming (ISP) of the flash memory and the other for functional access to the processor and the FPGA.

Although the JTAG ProVision™ Tool can provide full boundary scan testing for multiple-chain configurations, there was an additional desire for a single boundary scan chain to maximize throughput. This would allow for simultaneous testing of four boards using a JTAG Technologies 4-TAP QuadPOD as shown in Figure 2. For that reason, an approach was adopted to combine the two chains into one.

Figure 2. Boundary Scan Test Configuration

With the product boards already built, an ECO to redesign the board was too costly and time-consuming. To create a single boundary scan chain without an ECO on the product board, a separate test board was constructed that would effectively connect the two boundary scan chains into a single chain.

The test board's main component was an FPGA with an on-board serial peripheral interface (SPI) EEPROM. The FPGA, programmed by the EEPROM, provided both the physical connectivity and control logic required to create a nonconventional implementation of a boundary scan series loop. The test FPGA also could be used to enhance the testability of the board.

Generating Tests

Once modifications to allow for boundary scan test were in place for the surveillance processing system design, software tools and hardware controllers were required to implement the boundary scan test solution. A tool was needed that would use the design data from the existing design flow. JTAG ProVision met the need, importing the following design data with no modifications:
• The board design netlist, created using the Altium P-CAD PCB design entry tool.
• Boundary scan description language (BSDL) files for each boundary scan component.
• Models for all non-scan devices, most of which were available in the library provided with the JTAG ProVision tool.
• Input/output buffer information specification (IBIS) models for the buffers.

BSDL files, supplied for each part by the vendor, describe the boundary scan capability while models from the JTAG ProVision library address the non-scan components. The model for an ADC, not in the library, was created using the device datasheet as a reference.

Once the necessary design data for the processor board was imported and entered, the JTAG ProVision application generators analyzed the design netlist in combination with BSDL descriptions for the boundary scan devices. Based on this information, a scan-chain topology was automatically constructed. Using models for the non-scan devices, a board application was created for optimum test coverage and ISP performance while providing safe conditions on all the board components. To ensure safe conditions, nets with possible driver conflicts were identified as potentially hazardous.

Using the JTAG ProVision NetExplorer, the test engineer reviewed the nets that had been identified with potential driver conflicts. Based on knowledge of the design, the engineer overruled any unnecessary controls, which allowed additional nets to be included in the test and resulted in increased test coverage.

JTAG Technologies' JT 37×7/TSI triple-serial interface controller and associated 4-TAP QuadPOD shown in Figure 2 provided the communications between the boundary scan system and the target board. The controller in this application communicated with the PC via a USB interface. The four ports on the QuadPOD directly connected to TAPs on the target boards.

Design-for-Test Considerations

During the implementation of a boundary scan test methodology for the surveillance processing system, several good design practices became clear:
• There is no standard for a JTAG TAP connector except that it contain suitable connections noted by the 1149.1 specification. It is recommended, however, that a consistent approach be used in all designs; that is, keep pin assignments the same for all projects to allow reuse of connecting cables.
• To avoid issues with clock skew of the JTAG TAP test clock (TCK) signal and signal integrity on all the JTAG TAP connections, the connection between the boundary scan hardware controller and the board should be no longer than 6 inches.
• To ensure good signal integrity, the TAP inputs—TCK and test mode select (TMS) in particular—should be buffered at the TAP connection on the board.
• One or more extra TAPs should be considered as additions to a boundary scan design for redundancy. If something in the boundary scan chain is not operating properly, the entire chain could become nonfunctional. By using jumpers to a secondary TAP, a critical component such as a boot-up FPGA could be isolated and accessed separately if another component in the scan chain were broken.

Rapid Diagnosis and Testing

With the new boundary scan test system in place, it was time to test a new lot of boards. Boundary scan tools and hardware had eased the implementation so that the boundary scan testing could be performed directly at the manufacturing site. After each board was powered up and the JTAG hardware controllers were connected, the boundary scan checks took less than 10 seconds per board.

At the end of the test, a detailed fault report and execution log were generated for each board. The fault report then was interpreted by the JTAG BSD module, which displayed pin-level diagnostic messages giving the specific location and nature of any failures.

One short, for example, was found between two data lines on the memory that would not have been found with visual inspection. Prior to implementing the boundary scan methodology, sophisticated low-level software and an emulator were used to identify problems, something that could only be performed by a skilled software engineer. Now, a problem is identified, located, diagnosed, and repaired before the board leaves the manufacturing site (Figure 3).

After the initial interconnectivity test was passed, as shown in Figure 4, the processor programmed the flash memory and the FPGA on the processor board while the FPGA on the test board was programmed using an SPI EEPROM. Both FPGAs and the flash memory, however, could have been programmed through the boundary scan chain as well.

Figure 4. Interconnect Test Using Truth Table

Enhancing Testability

Implementing boundary scan testability on a product that already had been designed required a creative solution. A secondary test board was developed to facilitate implementation of a single boundary scan chain, in effect connecting the two former chains in series. It provided a way to externally connect and check the primary I/O of the processor board. Using bidirectional buffers on the test board and controlling the output enable (OE) of each I/O buffer with the test board FPGA, the direction of the data flow could be controlled. By dynamically controlling the flow of data, external connections on the board were driven and checked. Boundary scan tests verified the interconnectivity between the JTAG boundary scan components, and additional checks on the primary I/O provided increased product testability.

Another test enhancement for the boundary scan test flow was the addition of a simple check of the flash memory. Using the boundary scan chain to fully test a flash memory would be inefficient. Other tools specifically designed to do that task would be a better choice.

However, leveraging the control and connectivity of the boundary scan chain to do initial checks on the memory was easy to implement, and it could quickly determine whether or not the basic functionality of a memory was working. By simply writing and reading back a very small file to the memory, checking the memory control lines and data interface was automated through the JTAG ProVision interface.

Manufacturing Portability and Flexibility

A functional boundary scan test process was set up at the manufacturing site. Before any board left, most problems were identified and repaired.

Implementing a boundary scan test system at the manufacturing site removes the excessive cost of shipping boards between the project team and the manufacturer for testing and repair. Also, the portable nature of a boundary scan test station allows it to be set up at any manufacturer the system company chooses. By using a hardware controller with a 4-TAP QuadPOD and with the secondary test board, four boards can be tested simultaneously and independently.

Cost and Time Savings

A boundary scan test methodology resulted in a significant reduction in the time technicians and engineers invested in testing, diagnosing, and repairing boards. Initial test times were reduced from greater than 30 minutes to less than 10 seconds per board. Additional cost savings were realized when boards no longer needed to be shipped from the manufacturing site to the company and then back to the manufacturer for repairs.

Considerable savings were achieved in engineering manpower that had been required for up-front testing as well as in the time expended troubleshooting hard-to-diagnose failures. Finally, because most problems now were rapidly identified, diagnosed, and repaired, the production yield for processor boards increased from approximately 30% to greater than 90% at the manufacturing site.

Future Possibilities

As more BGA packaged components are incorporated into the company's air traffic, navigation, and landing system products, a boundary scan test methodology coupled with comprehensive and easy-to-use tools will be critical to identify and resolve connectivity issues. The use of boundary scan tests will be expanded to provide higher test coverage for new products especially as a wider range of parts and increasingly sophisticated integrated circuits become available.

About the Author

Keith Wetterquist has been with JTAG Technologies as the applications engineer for the Midwest region for the past three years. Mr. Wetterquist has many years of experience as an applications engineer and a product development engineer and graduated from Illinois Institute of Technology. JTAG Technologies 1006 Butterworth Ct., Stevensville, MD 21666, 877-367-5824, e-mail: [email protected]