Bonala Ravi Kishore BITS ID: 2017HT80522

IJTAG
Need of IJTAG

To manage the complex requirements of testing a heterogeneous set of embedded IP, the
industry developed IEEE 1687 (IJTAG). It standardizes a language for describing the IP interface
and how IPs are connected to each other. It also introduces a language that defines how
patterns that operate or test the IP are to be described. IEEE 1687 draws a clear line between
what must be covered by the standard and what is better left to the ingenuity of the tool
developers.

IJTAG provides automation and features far beyond the basic implementation of the languages of IEEE
1687. It simplifies the process of connecting any number of IEEE 1687 compliant IP blocks into an
integrated, hierarchical network and to communicate commands to the blocks from a single top level
access point. It provides a flow in which the user does not need to know the ins-and-outs of IEEE 1687

 Uniform access and usage of embedded IEEE 1687 compliant IP independent of the IP source
 Expands availability of embedded IP choices
 Reduces design schedules by accelerating integration of IEEE 1687 compliant IP

 Achieves minimum cycle count for accessing IP within a reconfigurable network

IJTAG is a reaction to the growing integration of functionality in the same die. With this trend
comes the need to quickly integrate not only in-house intellectual property (IP), but also third-
party IP. For design integration, such IP comes with a large, de-facto standard library, including
layout views, simulation libraries, and design-rule checks.

IP test information usually is not part of this library. The method of delivery of test information
is often an ad-hoc agreement between the different parties. The test view of the IP, in-house or
purchased, might be provided “textually” as part of the documentation, for example, explaining
how to execute logic BIST-based tests.

Furthermore, thorough testing becomes increasingly challenging with the numbers and types of
instruments. Limited top-level access to each instrument due to pin limitations is an additional
challenge. As device complexity increases in this way, the value of IJTAG becomes more
 Bonala Ravi Kishore BITS ID: 2017HT80522

apparent. Instead of replacing JTAG, it adds capabilities to allow more automation and reuse for
embedded instruments Additional capabilities added by IJTAG include:

 Support for dynamic data-register configurations. This is especially useful with large numbers of
internal instruments in an effort to reduce test-data volume and test time
 The ability for IP providers to supply control and interface information with their instruments in
a standardized exchange format
 The ability for the test integrator to rely on automation for mapping embedded instruments
and generating test patterns as defined by the IP providers

Who will use IEEE P1687 IJTAG?

The IEEE P1687 IJTAG standard will be applied at the chip and board levels. Chip designers, for
example, will find IJTAG useful during design verification when it will be used in conjunction with a
simulator or emulator. IJTAG will also be deployed in the ATE test environment where it will become
part of chip test, chip debug/diagnostics and chip characterization. At the circuit board level, the IEEE
P1687 IJTAG standard will be used to access instruments that are embedded in chips to perform board-
level test, debug/diagnostics and characterization. Finally, when a system is failing in the field,
maintenance personnel can utilize the same tests based on embedded instruments to extract failure
data from a device. This data, along with other environmental data, such as voltage and temperature,
can be fed back to the organization’s failure analysis team which can analyze the root causes of failures.
This will allow the duplication of the failure conditions and as a consequence reducing reduction in the
amount of No Trouble Found (NTF) cases

Previous Method

Boundary Scan is an IEEE standardized architecture for test access to complex PCB’s and the
integrated circuits on those PCB’s, as well as the control of on-chip test features such as scan paths

Development started in 1985 by the Joint European Test Action Group and in 1986 became the
Joint Test Action Group (JTAG) following North American involvement.

– In 1988, a proposal from this group for a boundary scan standard JTAG Version 2.0 was offered
to the IEEE Testability Bus Standards Committee (P1149) for inclusion in the standard being developed.
This submission became the basis for the IEEE standard and JTAG became the working group developing
the standard. – IEEE std. 1149.1 was accepted in 1990. The latest revision was published in 2012
Bonala Ravi Kishore BITS ID: 2017HT80522
Bonala Ravi Kishore BITS ID: 2017HT80522

What is iJTAG includes

• iJTAG 1687 is an IEEE Standard • It is made up of 3 components

– A flexible instrument access architecture leveraging a network of serial scan chains

– A programming language to describe the network (Instrument Connectivity Language: ICL)

– An instrument vector language (Procedural Description Language: PDL)

Bonala Ravi Kishore BITS ID: 2017HT80522

The Basic P1687 On-Chip Architecture

The figure above illustrates the architecture that the IEEE P1687 IJTAG standard would
implement at the chip level. On the right, it shows how the IJTAG network interfaces to the IJTAG-
compliant embedded instruments with the IEEE 1149.1 boundary-scan standard’s Test Access Port (TAP)
on the left. The TAP functions as the interface for the embedded P1687 IJTAG architecture to the world
outside of the chip.

Essentially, IEEE P1687 IJTAG allows the boundary-scan TAP and its TAP Controller to access
instruments that are embedded on-chip. Several IJTAG concepts are shown in this illustration, including
the Segment Insertion Bit (SIB) and Procedural Description Language (PDL). These will be described at
greater length below
Bonala Ravi Kishore BITS ID: 2017HT80522

The Instrument Gateway (Interface)

The above drawing illustrates how the hardware interface or gateway for the IEEE P1687 IJTAG
standard on-chip architecture can interface to a standard IEEE 1149.1 boundary-scan standard Test Data
Register (TDR). Isolating the P1687 IJTAG architecture from the requirements of the interface leading off
the chip ensures the portability of embedded instrument intellectual property (IP) as well as any vector
IP that may be associated with them. In fact, an off-chip interface other than the IEEE 1149.1 boundary-
scan TDR could emerge in the future and this would not affect the portability of IEEE P1687 IJTAG
instruments or vectors
Bonala Ravi Kishore BITS ID: 2017HT80522

One of the key elements defined in the IEEE P1687 IJTAG standard is the Segment Insertion Bit
(SIB). The composition of a SIB is shown in the illustration above. A SIB is similar to an IEEE 1149.1
boundary-scan shift/update cell, but the SIB is used to dynamically configure an on-chip P1687 IJTAG
scan path to meet the requirements of a particular set of test vectors. ‘Selecting’ a certain SIB can
activate a portion of the chip’s IJTAG scan path and consequently activate the instrument(s) on that
segment of the scan path. Conversely, ‘de-selecting’ a SIB will deactivate a portion of the chip’s overall
scan path and render the instruments on that segment inaccessible. Instruments on a deactivated
segment of the scan path cannot be accessed as long as the scan path segment is deactivated, but they
can still execute test vectors while they are offline.
Bonala Ravi Kishore BITS ID: 2017HT80522

The drawing above illustrates the most basic unit or building block in an IEEE P1687 IJTAG architecture.
Shown here as a block diagram is an IEEE 1149.1 boundary-scan standard’s TAP controller on the left,
which provides access from the outside world to the on-chip IJTAG architecture. The TAP’s Test Data In
(TDI) and Test Data Out (TDO) registers are connected in a scan path to a boundary-scan Test Data
Register (TDR) which acts as a read/write front-end to an IEEE P1687 IJTAG embedded instrument. As
noted in the drawing, IJTAG’s ICL language defines the read/write signals that interface the TDR to the
embedded instrument. And IJTAG’s PDL defines the actions, test vectors and other operations that the
instrument executes.
Bonala Ravi Kishore BITS ID: 2017HT80522

Advantage :

The benefit of aliases and enumeration tables becomes clearer when we consider the second language
that P1687 defines: PDL, or Procedural Description Language. PDL is a command language that instructs
an application tool how to generate patterns. It does not describe the patterns themselves, which may
include control values to gain access to instruments. Instead PDL defines at the instrument level where
(either a port or a register) to apply care bit values. The application tool follows the PDL instructions and
retargets the care bits through the ICL hierarchy, automatically adding control values as needed. When
the top-most ICL level is reached, the final PDL can be translated into any common pattern format, like
STIL, WGL, or can be written out as a verification test bench.

Using the example design, here’s how you would enable the IP3 connection to the first WTAP (see
Figure 2):

iWrite core1.instWTAP.IR enableIP3

iApply

This tells the application tool to generate a sequence of operations for the TAP and WTAPs that puts the
bit-sequence 01000 in the instruction register ‘IR’ of the instance ‘instWTAP’ in ‘core1’. The ‘iApply’
keyword ends the instruction block.

Notice the absence of any user-defined control operations. What needs to be done to get the user-
defined care bits ‘enableIP3’ into the specified location ‘core1.instWTAP.IR’ is up to the application tool
and doesn’t concern you as the P1687 user.
Bonala Ravi Kishore BITS ID: 2017HT80522

Let’s move the test one hierarchy

level higher. Figure 3 shows two dice in a system.

Conclusion

• iJTAG 1687 is an IEEE Standard • It is made up of 3 components

– A flexible instrument access architecture leveraging a network of serial scan chains

– A programming language to describe the network (Instrument Connectivity Language: ICL)

– An instrument vector language (Procedural Description Language: PDL)