The drive toward embedded instrumentation is not new. The force of miniaturization has been pervasive in the industry for more than three decades. Typically, it’s only a matter of time before a popular technology that was first implemented discretely in multiple chips or multiple circuit boards is eventually shrunk down and integrated into one or more chips.
Now, instruments that were once embodied in external boxes or modules consisting of multiple circuit boards are being embedded into chips to provide solutions at the chip, board, and system levels. In addition, logic items that once were exclusively used for chip-level test, debug, and yield analysis now are called instruments and being considered for use at the board and system levels.
To maximize the usefulness of these embedded instruments, an open industry standard, Internal JTAG (IJTAG), formally the IEEE P1687 preliminary standard, is being developed. When ratified, IJTAG will optimize the effectiveness of embedded instrumentation no matter the source of the instrument’s intellectual property (IP), including chip makers, third-party providers, EDA tool vendors, or in-house design groups. This will result in an open embedded instrumentation ecosystem.
Why Embedded Instrumentation?
Embedded instrumentation has been thrust into the limelight because external test technologies are coming up short as the capabilities of electronic systems continue to progress. Consider a few examples.
Traditional stand-alone instruments have a difficult time keeping up with the increasing data transfer speeds and frequencies of chip-to-chip interconnects and I/O buses. In addition, semiconductor vendors are designing-in signaling enhancements such as preconditioning, pre-emphasis, and equalization to help move signals at higher frequencies. Unfortunately, these techniques make accurate measurements even more difficult for traditional instruments.
At the chip level, sub 100-nm fabrication processes have dramatic effects on device-level parametric performance characteristics, and traditional testing techniques are ineffective at identifying many common problems. External instruments at the corners of a chip cannot see parametric variations like thermal conditions, timing issues, clock propagation, and power distribution across the chip.
In addition, placing an oscilloscope’s probe on a test pad on a high-speed serial bus like PCI Express 2.0 or 3.0, Fibre Channel, 10-Gb/s Ethernet, InfiniBand, or Intel®’s Quick Path Interconnect architecture introduces capacitance anomalies on the bus. The validation or test engineer can’t tell the difference between an instrument-induced anomaly and a design or manufacturing fault.
Another fly in the ointment comes from some of the more advanced chip-level packaging techniques that are becoming indispensable in today’s advanced electronic systems. These increasingly complex packaging technologies typically incorporate several processing cores, multiple stacked dies, and other features that make physical access to logic, chip test features, and pins impossible.
For example, an individual die may include sophisticated test and debug logic. But when it is stacked with other die in a SiP device, the die’s test or debug logic is useless since its die-level access mechanisms typically are not supported at the package level.
Why an Open Standard for Embedded Instrumentation?
Embedded instrumentation has been around for a while although it has had several aliases. Examples of embedded instruments include scan and scan compression architectures, memory BIST engines, logic BIST engines, clock controllers, data capture buffers, embedded logic analyzers, hardware logic assertions, and voltage-temperature-process monitors, and the list goes on.
These software-driven instruments were developed and embedded into chips to perform chip-level verification, characterization, and test as well as board-level design validation and system test. Unfortunately, each piece of embedded instrumentation IP may come from a different source, and typically each instrument has had its own distinct access mechanism.
The various embedded instruments typically have been targeted at different points in a chip’s, circuit board’s, or a system’s life cycle, such as chip simulation, wafer probe, package test, stacked-die test, board test, system development, and system use. There have been different access mechanisms for the instruments that address each of these phases in the life cycle. As a result, some instruments can only be accessed and used at a certain period in the life cycle. Obviously, a standard access mechanism applicable to the entire life cycle is needed, and this is where IJTAG comes in.
In addition, operating multiple embedded instruments simultaneously has been very difficult if not impossible. With parallel operations of multiple embedded instruments, an embedded logic BIST engine for chip test might be operated simultaneously with a voltage monitor intended for yield analysis, for example. The resulting simultaneous operation of these two embedded instruments could determine whether failures identified at the ATE- or board-level correlated with voltage starvation.
This is where an open standard for embedded instrumentation could optimize the effectiveness of the technology. With an open standard like the preliminary IJTAG standard, one access method could be provided for all instruments no matter where the instrument came from or what its purpose is. Moreover, all instruments that conform to the open standard could be accessed simultaneously, and the effects of multiple instruments working together would be synergistic.
When designing and deploying an IJTAG architecture, the development team might be confronted with trade-offs involving cost, engineering constraints, and usage scenarios. For example, the standard’s flexibility gives designers the ability to minimize the amount of additional logic or routing, maximize the flexibility and concurrence of scheduling when instruments execute their tasks, or limit the amount of power usage or activity level by limiting the number or type of active instruments. Or, the latency involved in accessing a particular instrument might be critical to a system, and the decision could be made to minimize the number of clock cycles needed to access that instrument.
The IJTAG Architecture
The basic IJTAG architecture, as it is described in the IEEE P1687 working group’s hardware architecture document, involves three partitions or zones (Table 1). The first zone is not really under the purview of IJTAG standard per se. Rather, this zone involves the access technology that ultimately interfaces the other two IJTAG zones as well as the embedded instruments to the outside world.
Initially at least, this first zone will consist of IEEE 1149.1 JTAG technology since this standard is well accepted and extensively implemented in the industry. In theory though, this first zone could be any sort of access technology that can communicate with the second or gateway zone defined in the IJTAG standard. For example, the first zone might consist of an embedded CPU or a packet router with serial-to-parallel conversion from a high-speed serial bus.
The second zone described in the IJTAG hardware architectural document is referred to as the gateway zone. This transitional partition buffers the access technology zone from the actual IJTAG instrumentation zone.
With a gateway zone, the technology featured in the access zone need not be limited to any one technology. Moreover, a gateway zone removes complexity from the actual IJTAG instruments since the instruments are not strictly required to conform to any access technology like JTAG.
The embedded instruments can simply be instruments. Even though instruments are the focus of P1687 IJTAG, the standard will not attempt to impose any standardization upon instruments themselves other than the requirement to have static signal interfaces.
In the case where JTAG is the access technology to the outside world, the gateway zone conforms to IEEE 1149.1, and the gateways in the gateway zone function as bridges between the embedded 1687/IJTAG instruments and JTAG’s test data in (TDI)/test data out (TDO) serial data path which leads to the JTAG test access port (TAP) controller. In a generic sense, the gateway register acts as an off-loaded and distributed instruction register. In other words, the gateways enable board-level access to the embedded IJTAG instruments from the 1149.1 JTAG TAP.
The P1687 IJTAG standard includes a GateWay ENable (GWEN) JTAG instruction that selects, configures, and enables P1687 gateway registers. A P1687 gateway can be an instrument in its own right, but to be considered a gateway, it also must enable a hierarchical connection to another embedded instrument for which it acts as a gateway. This hierarchical gateway connection involves passing JTAG’s TDI-TDO signals and a local select signal to the instrument or instruments the gateway is connected to.
The third and final zone in the P1687 IJTAG architecture is the P1687 zone where the embedded instrumentation IP resides. In addition, the P1687 zone can include one or more IJTAG Alternate Controllers (AC). The AC is a conversion element that allows instruments that do not comply with the IJTAG standard to be controlled by the IJTAG access method, which typically is JTAG.
An AC can create control signals for one instrument, multiple instruments or groups of instruments, or every instrument in the P1687 zone. The AC provides the possibility that certain types of complex instruments that do not conform to the IJTAG standard, such as sophisticated IEEE 1500 core wrappers that include the transfer function, can be incorporated in the design and controlled like other IJTAG instruments. Besides embedded instruments and one or several ACs, the P1687 zone also could include direct I/O connections or high bandwidth I/O ports.
Juggling the Trade-Offs
IJTAG P1687 is being developed with enough flexibility and adaptability to allow for a wide range of trade-offs depending upon the goals of the design team. Designers may decide to optimize a number of factors, including risk, power, activity, concurrence, routing, area, and access latency. As a result, different access configurations of the embedded instruments must be supported so that these trade-offs can be juggled.
Basically, there are five architectural schemes possible under the IJTAG standard. They are the flat, daisy-chain, star, concatenated, and hierarchical configurations. Table 2 provides descriptions of each of these architectures.
For chip-level access, each of these connectivity schemes has its advantages and disadvantages, and each is best suited for a certain number of instruments. The flat and daisy-chain architectures work best when the number of instruments is fewer than 10 (Table 3).
The star configuration is more complex. It requires that the designer group the instruments that will interact or have concurrence with each other. As a result, this structure is efficient up to around 100 instruments.
The concatenated configuration is a daisy chain with an active bypass register that is always in-line. Approximately 300 to 500 instruments result in long bypass scan chains that keep all the instruments awake and powered. To grow into thousands of instruments embedded on a die, a truly hierarchical structure is required
(Figure 1).
The typical operating parameters of certain instruments can determine which IJTAG architecture will be best suited to the chip or circuit board. As an example, consider a memory BIST instrument with a simple test interface consisting of an Invoke and Reset as static input signals and a Done and Fail as static output signals. An IJTAG test data register (TDR) interface would consist of two shift-capture-update bits where the update bits would drive the Invoke and Reset signals and the shift-capture side of those bits would collect the Done and Fail responses.
Now consider 300 embedded on-chip memory arrays with memory BIST. Configuring all these instruments in a daisy-chain configuration would result in a single instruction and a single active scan path 600 bits long. Conversely, a star configuration would necessitate 300 individual instructions, a much-expanded instruction register, and scan paths that were only 2 bits long.
The daisy-chain configuration would provide the most flexible arrangement for instrument concurrency, that is simultaneous operations of multiple instruments, and test scheduling because any or all of the 300 memory BISTs could be activated at one time. But it also would have the longest latency period and power consumption because all 600 bits would be active even when only one memory BIST is operating. Activating a memory BIST would involve a 600-bit shift followed by an update to activate or deactivate any instrument and a capture followed by a 600-bit shift to poll any instrument for status.
In contrast, the star configuration would provide the least flexible concurrency and test scheduling because it would only allow one memory BIST to be activated at any given time. But a star architecture would have the least latency and power consumption because it would only require a 2-bit capture-shift-update to activate, deactivate, and check status.
Moreover, the 600-bit scan path of the daisy-chain architecture has the most operational risk since one single defective bit in the scan path can deny access to all instruments. The star configuration’s 2-bit scan path carries the least risk since a defective instrument interface or scan path bit only breaks the access to one instrument. In addition, the daisy chain’s 600-bit scan path activated with one instruction requires the least amount of logic and routing. This is because there is only one instruction and instruction decode and one TDI-TDO pair that can be routed from one instrument to another in a physically optimized manner.
This is in contrast to the star configuration that requires an instruction decode and a TDI-TDO pair from the 1149.1 JTAG TAP controller to each instrument. This shows that the daisy-chain and the star configurations form opposite ends of the trade-off spectrum.
The proposed IJTAG standard adds the other configuration options by calling for instructions from the JTAG TAP controller to be processed by gateway elements in the instrument access or transitional zone. The presence of gateways allows for hierarchical connections that enable a flexible mixture of daisy-chain and star configurations.
In the example of the 2-bit memory BIST interface with 300 distributed memory BISTs, another option would be to implement a 15-bit gateway, and each gateway bit would further support a 5-bit gateway. Each bit from the 5-bit gateway would support four memory BIST interfaces. This allows one instruction from the TAP instruction register to select the 15-bit gateway, and this gateway then becomes a distributed 15-bit hierarchical instruction register.
In this scenario, a 15-bit shift update would provide access to the 5-bit gateway that would, in turn, provide access to a hierarchical grouping of 20 memory BISTs. Ultimately, accessing and operating one memory BIST would have a latency of shifting just 24 bits through a scan path and just three update DR passes through the TAP state machine.
The risk of loss from scan path failure would be limited to just four instruments in a local daisy chain and up to 20 instruments if a gateway bit failed. The additional logic required for this would only be the gateway bits. The routing would be optimized as TDI-TDO connections between the small instrument daisy chains and the gateway bits.
Concurrency and test scheduling is very flexible with this configuration because two or more memory BISTs can be operated simultaneously by simply accessing the correct gateways with shift data. Power consumption can be minimized by scheduling and operating the number of memory BISTs that is actually called for. Moreover, power distribution can be optimized by accessing memory BISTs that are in particular areas of the chip.
Offering Design Validation, Test, and Debug Solutions
Embedded instrumentation holds much promise for solving a slew of design validation, test, and debug difficulties at the chip, circuit board, and system levels. To take full advantage at every phase in the life cycle of the instruments that already are being embedded into silicon, open tools and access mechanisms are imperative.
The IEEE P1687 IJTAG standard under development is a step in the right direction. Although JTAG is being called upon as the initial access method for IJTAG, the P1687 standard does not preclude other access methods in the future. Certainly alternative access technologies to the edge of the IJTAG world will be deployed as they are needed and as their benefits warrant their implementation.
About the Author
Al Crouch is chief technology officer for core instruments at ASSET InterTech. He is a senior member of the IEEE and vice chairman of the IEEE P1687 IJTAG working group. Mr. Crouch has filed for more than 30 DFT-related patents and been granted 15. ASSET InterTech, 2201 N. Central Expressway, Suite 105, Richardson, TX 75080, 888-694-6250, e-mail: [email protected]
February 2009