Who gets the benefit of using IEEE 1687 (IJTAG)? The simple answer is, “there is something for everyone!”
Once organizations and engineers have been exposed to IEEE P1687 IJTAG, the Proposed Draft Standard for Access to Embedded Instruments, and no matter which part of the semiconductor-based product lifecycle they are involved with, they all seem to find something that excites them. The IEEE 1687 standard resonates with engineers and managers because it either solves a technical problem, it provides a cost advantage, it reduces the amount of work, or it enables automation of some (onerous) task…
It doesn’t matter where the people work in the semiconductor lifecycle, 1687 seems to represent a positive efficiency over currently applied methods, or provides a solution where one didn’t exist previously. The reason for this is intentional—the working group committee comprises many members from across industry (and academia) that represent the complete semiconductor life-cycle, and every one of them put forth what they would like to get out of the 1687 standard. As a result, even though IEEE 1687 has a stated Purpose and Scope that may seem narrow and focused on vector re-targeting, the Standard still includes advantages to all processes of the semiconductor lifecycle. For example:
The Instrument Provider—a very basic business is created/supported where providers (companies, consultants or automation software) can generate instruments that represent embedded logic items and can deliver them as described plug-&-play units, complete with their operation vectors. A Raw Instrument may not include any 1687 access mechanism logic or wrapper, but the PDL vectors can be delivered with respect to the instrument’s signal interface, and the signal interface can be described in 1687 ICL. Making a “Raw Instrument” (an instrument with no 1687 wrapper) compliant, no matter how it is delivered (hard macro, soft Verilog/VHDL model, Verilog/VHDL-generation code, etc.), only requires including the 1687 PDL and ICL. This adds a measure of portability for the instrument for insertion/integration, verification and use.
The IP provider—IP can be anything from an individual instrument to a complete, complex core. Larger IP may include several instruments and additional test and debug support—for example, the core may be wrapped with an IEEE 1500 Core Test wrapper and may support an IEEE 5001 Nexus Debug Port. A larger IP may support one or more entire 1687 IJTAG Instrument Access Networks and the delivery of that IP Core, if it includes PDL and ICL, can represent a plug-&-play instrument architecture that easily integrates with the 1687 architecture in the overall chip. Providing a 1687-compliant architecture and the associated PDL and ICL make the instruments within the IP “portable” and “reusable”. The IP provider may create tests for their IP and then hand these off to the IP/Chip Integrator (the IP-provider’s customer). For the 1687 portion, the integrator only needs to connect the 1687 signals associated with the IP…
The Chip Integrator—the person or organization that takes the various instruments or 1687 instrument networks and connects them into a test/debug/real-time architecture has a much simpler task, which may be easily automatable because the instruments can be “wrapped” with a P1687 interface—then all that is needed is for the integrator to connect the 1687 control signals and the scan-path. The PDL can then be applied and used for verification at any level of the 1687 architecture by means of vector re-targeting tools. 1687 architectural exploration is also possible to figure out the specific configuration of the 1687 network to achieve a particular access time, a power consumption or activity target, efficient instrument scheduling, and so on. 1687 architecture exploration includes mapping engineering or development tradeoffs (how many TDR registers are needed, how long is any given scan path, how much routing/gate-area will be consumed, etc.), which can be facilitated by the use of scan path branches, embedded network instructions, and instrument-interface register configurations.
The IC Test Developer—one of the most powerful advantages of P1687 is to allow instruments to be portable and reusable. Reusable means that the vectors that are delivered with the instrument at the design-development stage can be used over and over again and by different users across the semiconductor life-cycle. For the IC Test Developer, who may be placing the silicon implementation of the IC onto an Automatic Test Equipment (ATE) or into a development/characterization board, the test operations and routines developed by IP/Instrument/Chip design for simulation and verification can be re-used. This type of reuse can significantly reduce the amount of work and the knowledge requirement of creating chip tests and chip test programs. In addition, if an error arises during the testing, the task of debug-diagnosis is correlated much more closely to the design-simulation stage of the chip development since the vectors applied to silicon can be done in exactly the same manner as was done during design-verification. The test engineer doesn’t have to understand the nature of the instrument to the extent that they can create vectors to operate that instrument at the chip-level from scratch. More simply, the test engineer can take an existing test/operation procedure written in 1687 PDL, which documents the test intent, and can then just apply that PDL through the chip-level 1149.1 JTAG port by use of a vector re-targeting tool.
The Board Test Developer—the same powerful advantage passed on to the IC Test Developer—portability of vectors and reuse of instruments (described in 1687 PDL and ICL)—provides higher impact cost/work savings at the board-level. Test development at the board level follows the “anecdotal 10X cost curve” (each level of abstraction represents 10X the cost of the previous level of abstraction for development or for debug). The board test developer must deal with multiple chips, and in the past, multiple access mechanisms (some custom) on each chip to access the test and debug logic. The board test developer is also far removed from understanding the individual instruments buried within chips. The 1687 ICL and PDL provide the documentation for the instruments and carry the intent of the test as well as the mechanism for applying the test. A PDL re-targeting tool can apply the test to the instrument in the exact same manner as with design verification and with chip test, even though the chip is now on a board with many other chips—without the board test engineer having to learn all of the design and operation specifics of the instrument or the chip that contains the instrument. A second major advantage is that the board test developer can now “collect data” from instruments embedded within chips and the cores within those chips and the interpretation of that data can be included within the PDL—as opposed to having to capture and sample bus data or signal values at the board “test point” level and having to understand and analyze that data at the board functional level.
The Chip/Board Manufacturing Engineer—similarly, tests from design verification, IC ATE test, and board test can now be reused—and they carry much finer resolution or binning information when a test/operation fails. With vector (PDL) re-targeting tools, the ability to conduct adaptive test and to optimize test scheduling becomes a much easier reality—the order of applied tests, the coordination of instruments to be operated simultaneously, and the ability to mask tests can be simple drag-and-drop or select-and-assert functions on a tool interface. With higher pass/fail resolution (to the PDL operation, for example) and with ease of automated test-scheduling, developing a test program that minimizes test time and maximizes coverage can be automated—and managing that test program over time with changes to eliminate tests, move tests in the overall sequence, or even to add new tests, becomes a function of the re-targeting tool.
The Debug-Diagnosis/Yield-Analysis Engineer—it is anticipated that the highest “value-add value” after reducing the cost/effort of test development, would be the ability to reduce the time and effort involved with debug-diagnosis and yield-analysis. If the evaluation of the test results of a chip or board can be started from “which PDL failed”, or from “which PDL command within a PDL procedure was active at the time of miscompare”, then analysis from the fail or miscompare starts at a very-localized and repeatable point (being able to repeat the failing operation). Beyond this initial error logging or bin, 1687 then allows data-collection to occur at the instrument-level, which is from within the chip. This allows failure-analysis to be much more localized even in the first-level of drill-down (the miscompare is already localized to a chip, and may further be localized to a core, logic unit, or instrument). The data collected (for example, at board test) will also be identical to data collected at IC test and even IC simulation-verification. The data collected may be passive (non-disruptive to ongoing operation) or may be active (requires the chip to be in test configurations), but it is significantly more data and localized data than current methods.
Summary
As has been described, the IEEE 1687 standard will provide a user-case and an advantage to most participants of the semiconductor design life-cycle; from design through field-returns. The advantages can be realized by actively using PDL and ICL to describe features and functions embedded within chips and to use vector re-targeting at the various levels of instrument operation. The same vector re-targeting function or tool is useful for design verification, IC-test, board-test, and for debug-diagnosis and can provide a 10X decrease in cost and effort as the life-cycle level moves to higher levels of integration.
