Standard aims embedded instruments at general test

Standard aims embedded instruments at general test

IEEE P1687 Internal JTAG (IJTAG) takes embedded test beyond its limited, chip-specific past

BY AL CROUCH, Chief Technologist
Core Instrument Technology
ASSET InterTech
www.assetintertech.com

Embedding test and measurement instrumentation on chips is not new; it’s been going on for years. What is new is how these instruments can be deployed beyond their original, limited, chip-specific purposes and applied to solve seemingly insoluble difficulties in circuit board and system-level validation, test, and debug. A newly emerging standard IEEE P1687 Internal JTAG (IJTAG) will facilitate this shift from external, intrusive testers based on physically probing a chip or circuit to internal, non-intrusive, software-driven methods.

The problems with probes

What started as an inconvenience is now an impossibility. Close to 20 years ago, it was difficult to probe a board because new chip packages like ball grid arrays (BGA) denied physical access to the pins. And then there was the access problem with regards to the traces on the internal layers of multi-layer boards. Now, as interconnect speeds climb over 5 Gbits/s finding a test pad on a high-speed I/O (HSIO) bus is close to impossible. Capacitive coupling effects cause havoc on HSIO signaling to the point where test pads are typically forbidden on many new designs. The result of all this is decreased coverage from intrusive technologies like oscilloscopes for board validation during development and in-circuit test (ICT) systems that perform manufacturing test.

Unlike test equipment based on intrusive test probes, the next wave of test technologies will have to be non-intrusive if the industry is to achieve the kind of coverage that’s needed for high quality, reliable products. That’s why standards like IEEE P1687 IJTAG are being developed to help re-deploy instrumentation embedded in chips to board- and system-level validation, test and debug.

IJTAG basics

The intent of the IEEE P1687 standard is to streamline how embedded instruments function by defining a standardized instrument interface and an effective architecture at the chip level to access these instruments as well as to manage this access.

The standard also defines two languages – one to describe the architecture and the other to describe procedures and operations (vectors). The IJTAG Instrument Connectivity Language (ICL) describes the various scan paths that are possible on a chip. Activating any of these paths will allow the application of particular sets of test vectors on certain instruments.

The other IJTAG language, Procedural Description Language (PDL), represents the test vectors or operational procedures that are applied to the IJTAG embedded instruments. These languages simplify the use and portability of embedded instruments and create an opportunity for the development of third-party automation tools.

Note that the actual embedded instruments are outside of the IEEE P1687 standard, in that the standard does not define how they should be made. An instrument with an IEEE P1687 interface is generally called an IEEE P1687 or IJTAG instrument.

For the first version of the IJTAG standard, the working group borrowed from the IEEE 1149.1 boundary-scan (JTAG) standard for physical access to on-chip or embedded resources. The boundary scan infrastructure and controller are well established and understood by the industry; in addition, they are already present on many chips and board designs.

An IJTAG architecture can be implemented in a field programmable gate array (FPGA), as seen in Fig. 1 . To simplify the illustration only two memory built-in self test (MBIST) instruments are shown, but many other types of instruments could be deployed in the same device.

Fig. 1: For an FPGA with two embedded memory BIST instruments, a standard IEEE 1149.1 boundary scan/JTAG Test Access Port (TAP) and TAP Controller (left) provide access to the chip’s IJTAG resources. In the center is an example of an IEEE P1687 IJTAG architecture and on the right are two embedded instruments, each with a standardized IJTAG interface

An interesting aspect of the IJTAG architecture is the standard’s Segment Insertion Bit, or SIB (Fig. 2 ). Selecting a SIB grants on-demand access to an instrument embedded on the device and results in a change in the length of the IJTAG scan path.

Fig. 2: An IEEE P1687 Segment Insertion Bit (SIB) is a derivative of IEEE 1149.1 boundary scan’s shift/update cell. Asserting a select signal on an embedded instrument’s control SIB activates the scan path to and from that instrument.

IJTAG’s ICL language provides a map of where SIBs are located. Automation tools may make use of the architecture described by the ICL map to activate an instrument’s segment of the IJTAG scan path. Then, test vectors defined by IJTAG’s PDL can be delivered to the instrument or instruments on the activated segment of the scan path.

A SIB enables the addition or subtraction of scan path segments by multiplexing the additional scan path into an existing scan path when the Update-Cell of a SIB contains a logic-1. This logic-1 is placed there by an Update-DR operation (when the 1149.1 TAP Controller state-machine passes through the Update-DR state).

FPGA-controlled test (FCT)

Standardizing an embedded instrument’s hardware interface and the on-chip infrastructure will give rise to the development and implementation of portable and transferable processes. Portable instruments will be able to be embedded in any number of chips while an instrument’s transferable test vectors will accompany it wherever it is embedded. In this way, these vectors can be applied during every stage in a product’s life cycle with little or no re-development of the test processes. As long as the IEEE P1687 ICL and PDL files are available, vectors can simply follow the semiconductors from chip development to board design, board and system manufacturing test, and ultimately field service.

This high degree of re-use and portability makes embedded instrumentation a natural fit for programmable devices like FPGAs. For example, to validate or test a board design, certain instruments could be programmed into the FPGAs on the first prototypes of the board, long before the FPGA’s operating firmware is developed or complete. These embedded instruments can then be used to validate, test and debug the devices that are connected to the FPGA and the interconnecting signals between the FPGA and various other devices on the board (Fig. 3 ).

Fig. 3: The orange blocks indicate the first layer of validation and test coverage that could be derived from instrumentation embedded in an FPGA. Complex tests could extend this coverage further.

The instruments embedded in the FPGA could provide special purpose functionality, such as a memory BIST that can be used to test a memory outside the FPGA on the board; a digital pattern generator that can create directed, random, or pseudo-random vectors; or a Serial Peripheral Interface (SPI) parent that can more efficiently operate multiple SPI offspring. Alternatively, the embedded instruments could be more general purpose in nature, such as microprocessor intellectual property (IP), which could then be programmed to perform several different types of tests.

Embedding instruments into one or several FPGAs would allow development schedules to be maintained or even accelerated, since engineers wouldn’t have to wait for the FPGAs’ firmware to validate and test prototype boards. In addition, embedding instruments may result in a more efficient test strategy by shortening test times or providing greater test coverage for the same amount of test time. And when the FPGAs’ functional firmware is complete, it can be tested and debugged on a known good board.

Of course, a toolkit or framework of tools would let validation and test engineers make the most of instruments that are either temporarily or permanently embedded in a design’s FPGA, which is the equivalent of embedding a tester into the FPGA. This methodology is often referred to as FPGA-controlled test (FCT). Such a toolkit could provide a cohesive set of packaged operations that are capable of accessing the embedded instruments, automating their operations and analyzing their outputs. Simply inserting instruments into one or more FPGAs on a circuit board is just the beginning of the process.

Such a framework of packaged operations would have to be portable and repeatable from one board design and type of FPGA to the next. Moreover, it must be an architecture that provides optimized and efficient access to embedded instruments and ensures their effective operation. In addition to IEEE P1687 IJTAG and IEEE 1149.1 boundary scan, this FCT toolkit would likely have to support other industry standards as well, such as the IEEE 1500 core test standard and others. ■

About the author

In addition to serving as the chief technologist for core instrument technology at ASSET InterTech, Al Crouch is the co-chairman of the IEEE P1687 Internal JTAG (IJTAG) Working Group for standardizing access to chip-embedded instrumentation.