What is IJTAG: IEEE 1687 for Accessing Embedded Instruments

IJTAG (Internal JTAG) is the common name for IEEE 1687, a standard published in 2014 for accessing and operating the instruments embedded inside a chip, such as BIST engines, sensors, PLL and I/O controls and debug logic. It uses the existing JTAG (IEEE 1149.1) test access port as the way in, adds a reconfigurable on-chip scan network so that only the instruments you need are in the scan path, and defines two description languages: ICL for how the network is connected and PDL for how each instrument is operated. Tools then retarget instrument-level procedures to the chip pins automatically.

If you are a chip designer or a test engineer, you will know JTAG, the standard that gives access to a chip's boundary and test logic for validation, test and debug. IJTAG extends that idea to the many instruments embedded deep inside the chip. This post explains what IJTAG is, how it works, how it differs from JTAG and why it is useful for chip design and test.

Key takeaways

• IJTAG is IEEE 1687-2014. It standardises how embedded instruments are connected, described and operated, not what the instruments do.
• The JTAG TAP (IEEE 1149.1) is the primary top-level access port, so no new pins are needed.
• Segment insertion bits (SIBs) and scan multiplexers make the scan path reconfigurable, which shortens access time.
• ICL (Instrument Connectivity Language) describes the network; PDL (Procedural Description Language) describes instrument operations.
• Instrument procedures written once at IP level can be retargeted to any chip that uses that IP, which is the main productivity gain.

What is IJTAG?

IJTAG stands for Internal JTAG. It is a standard that streamlines the use of instruments that have been embedded in chips, and makes those instruments usable across a wider range of chip, board and system level validation, test and debug applications. Chip designers use it during design verification together with a simulator or emulator. On automatic test equipment (ATE) it becomes part of chip test, debug and diagnosis, and characterisation, and the same access can be reused on the board and in the system.

At the heart of IJTAG is an on-chip network of scan segments that connects the instruments to the JTAG port. Each instrument exposes its control and status through test data registers, and the network can be reconfigured so that different instruments are placed in the scan path for different purposes. The network is hierarchical, so instruments inside an IP block can be reached through that block's own segments without the chip integrator having to know the internal details. (The earlier version of this post called this network an Instrument Access Network with Instrument Data Registers. Those names are used informally in some literature, but the standard itself speaks of scan networks built from registers, SIBs and scan multiplexers, so this version uses those terms.)

IJTAG also defines standard formats for describing the instruments and their access:

• ICL (Instrument Connectivity Language) describes the scan network: the registers, SIBs, multiplexers and how they connect, from the instrument interface up to the TAP.
• PDL (Procedural Description Language) describes how to operate an instrument at its own interface, for example "write 1 to start, wait, read the done bit". PDL is based on Tcl.

Software tools read the ICL of the whole chip and the PDL of each instrument, then retarget the instrument procedures into scan operations at the chip pins. The result can be applied as test patterns on ATE, used for diagnosis and calibration, or run interactively in the lab.

How the scan network works

The key building block is the segment insertion bit (SIB). A SIB is a one-bit register in the scan path with a multiplexer behind it. When the SIB is closed, the scan path passes over the segment behind it, so that segment adds no length. When a scan operation sets the SIB to open, the next scan includes the segment behind it, which can hold an instrument's registers or further SIBs.

Worked example: access time with and without SIBs (illustrative numbers)

Suppose a chip has four instruments with register lengths of 32, 64, 128 and 16 bits, and you want to read only the 32-bit status register.

Network style	Scan operations	Bits shifted
One flat chain of all instrument registers	1 scan of 32 + 64 + 128 + 16 bits	240
Four SIBs, all closed at the start	1 scan of 4 bits to open one SIB, then 1 scan of 4 + 32 bits	40

The SIB network shifts about six times fewer bits here, plus a small fixed cost in TAP state transitions for the extra scan. On a real SoC with hundreds of instruments and long memory BIST or sensor registers, the difference grows much larger, and the network can be arranged so that frequently used instruments sit close to the top.

How does IJTAG differ from JTAG?

JTAG is named after the Joint Test Action Group, which developed the standard published as IEEE 1149.1 in 1990. It defines a test access port (TAP) with the TCK, TMS, TDI and TDO pins (and an optional TRST), a 16-state TAP controller, an instruction register and a set of test data registers, including the boundary scan register around the chip's I/O, the bypass register and usually an IDCODE register.

JTAG has been widely used for testing printed circuit boards (PCBs) and integrated circuits since 1990. It has also been used in many ad-hoc ways to reach embedded instruments such as BIST engines, I/O characterisation logic and on-chip timing instruments, typically through private instructions and custom test data registers that every company described differently.

IJTAG differs from JTAG in the following ways:

• IJTAG uses the JTAG infrastructure within silicon as the physical way in, then adds a network of reconfigurable scan segments to reach the embedded instruments.
• IJTAG was developed to give JTAG the flexibility, reconfigurability and description standards needed to work with large numbers of embedded instruments. Its plug-and-play approach simplifies the integration and reuse of IP blocks that contain instruments.
• JTAG is compatible with IJTAG and can be modelled within the IJTAG standard. The JTAG port is the primary top-level interface, so IJTAG access works through the TAP to control many test features and other instruments.
• 1149.1 defines the hardware and the boundary-scan description language (BSDL); IEEE 1687 adds ICL and PDL to describe what lies beyond the TAP, and a methodology for retargeting procedures through it.

Aspect	JTAG (IEEE 1149.1)	IJTAG (IEEE 1687)
Main purpose	Boundary scan and access to chip test logic	Access to and operation of embedded instruments
Physical access	TAP pins and controller	Uses the 1149.1 TAP as primary access
Scan path	Selected by the instruction register	Reconfigured on the fly by SIBs and scan multiplexers
Description language	BSDL	ICL for connectivity, PDL for operations
Reuse	Chip level	Instrument and IP level, retargeted to any chip

A short PDL sketch

The fragment below shows the style of a PDL procedure for a hypothetical memory BIST instrument with a start control bit and done and fail status bits. It is written at the instrument's own interface; the tool works out which SIBs to open and which bits to shift at the chip pins.

iProcsForModule mbist_ctrl

iProc run_bist {} {
    iWrite start 0b1
    iApply
    iRunLoop 20000 -tck
    iRead done 0b1
    iRead fail 0b0
    iApply
}

The register names, the loop count and the exact options are illustrative; check the details against your tool's PDL documentation.

Why is IJTAG useful?

IJTAG improves testability over earlier methods by giving one standard way to access and control the instruments inside a chip. It allows reconfigurable scan paths, shorter access time and retargeting of patterns across levels of hierarchy, and its plug-and-play approach simplifies the integration and reuse of IP blocks.

IJTAG builds on the existing JTAG infrastructure but provides more flexibility than JTAG alone. It supports validation, test and debug throughout the chip and system life cycle, from first silicon bring-up and characterisation to production test and in-field diagnosis. The main savings come from reuse: instrument procedures are written once by the IP provider and reused in every design, rather than rewritten by each integration team.

What counts as an embedded instrument?

Embedded instruments are logic structures within a device whose purpose is design for test (DFT), design for debug (DFD), design for yield (DFY), test, debug, characterisation, monitoring or similar activities. They can generate test patterns, measure signals, calibrate I/Os, monitor performance and more. Examples include:

• BIST (built-in self-test) engines: test the function of a block without external stimulus or equipment.
• Complex I/O characterisation and calibration: measure and adjust the parameters of high-speed serial I/Os, such as voltage, timing and jitter.
• Embedded timing instrumentation: measure the timing characteristics of clocks and signals inside the device.
• Bit error rate test (BERT) engines: measure the error rate of a communication channel by comparing transmitted and received patterns.
• Margining engines: vary operating conditions such as voltage and frequency, often while monitoring temperature, to find the performance margins.
• Memory BIST: tests embedded memories such as SRAM and register files, and in some systems external DRAM or flash through the memory interface.
• Random pattern generators: produce random or pseudo-random data, often from an LFSR, for testing.
• Logic analysers: capture and analyse the logic states of internal signals.
• Process, voltage and temperature monitors: on-chip sensors used for characterisation and, increasingly, for in-field health monitoring.

Common mistakes and review points

• Putting every instrument in one flat chain, which makes access slow and a single broken segment blocks everything.
• Leaving ICL out of sync with the RTL; reviewers should check that ICL is generated from, or verified against, the design.
• Forgetting reset and security: debug and test access often needs to be locked in production parts.
• Not simulating retargeted PDL against the gate-level netlist before sending patterns to ATE.

FAQ

Does IJTAG need extra pins?

No. It normally uses the existing 1149.1 TAP pins. Some designs also reach the network from other interfaces, which is the subject of the follow-on IEEE P1687.1 project.

Is IJTAG only for manufacturing test?

No. The same network and procedures are used in simulation, on ATE, in the lab during bring-up and characterisation, on the board and in the field.

What is the difference between ICL and PDL?

ICL describes the structure: what is connected to what. PDL describes behaviour: the sequence of reads and writes to operate an instrument.

Do I have to replace my JTAG logic to use IJTAG?

No. The 1149.1 TAP and its registers stay, and the 1687 network hangs off it through a test data register selected by a JTAG instruction.

Conclusion

IJTAG is a standard that streamlines the use of embedded instruments within chips. It provides a way to access and control those instruments through the JTAG port, and a standard way to describe them with ICL and PDL. It is useful for chip design and test because it improves testability, reduces the effort of integrating and reusing instruments, and gives one access method from simulation to the field. IJTAG works with JTAG, while providing far more flexibility, which makes it a practical tool for any chip with more than a handful of embedded instruments.