For almost three decades the JTAG or boundary-scan standard (IEEE 1149.

1) has been a workhorse, but let’s

face it, there are some functions it was never intended to perform and, as a result, it doesn’t do them well. It
certainly has been a great access mechanism for testing circuit boards and in-system programming. But, over the
last five years or so, as more and more IP in the form of embedded instruments has been integrated into chips,
the JTAG standard has frayed a bit around its edges. Specifically, the explosive proliferation of embedded
instruments has challenged JTAG with regards to issues such as scalability, IP portability, sustainability, ease
and efficiency of operation of embedded IP, and others.

Clearly, another standard developed from scratch to serve the newly emerging requirements of embedded
instruments was needed. Consequently, the IEEE 1687 Standard for Access and Control of Embedded
Instrumentation within a Semiconductor Device, or more commonly known as Internal JTAG (IJTAG), was
developed, not to replace JTAG, but to supplement it with the flexibility, re-configurability and functional features
that would make working with the myriad of embedded instruments we now see in chips and on circuit boards
easier and more effective.

More and more

engineers are relying on embedded instruments to perform functions throughout the life cycle of chips and
systems, functions like characterization, verification and various operational monitors at the chip level, and, on
circuit boards, test, validation, hardware debug, chip programming and many others.

Of course, change is always difficult. Some in the industry thought: Let’s just add to the JTAG standard, even
though the use cases of embedded IP require functionality never imagined three decades ago when JTAG was
ratified. Others thought a new standard dedicated to the requirements of embedded IP, but which also took
advantage of JTAG’s capabilities, would be more effective. This latter position resulted in the development of
IEEE 1687 IJTAG.

IJTAG rationale
As boundary scan, defined under IEEE 1149.1 became better established, the capabilities of the
JTAG test access port, TAP, interface were explored. The interface allowed for a much greater
level of access into the core of circuits and chips themselves without the need for intrusive
access.

The development of IJTAG has come about to a large degree because of the growing level of
functionality within each silicon chip or die. These days, manufacturers do not just use their own
IP on the chip, but also that bought in from other specialists.

Even though the different functional modules within the overall die have their operation and
interfaces specified, there is still a great need for integration testing, even if many simulations
have been performed. This testing is not always easy to achieve because access to a die is
obviously difficult.

To overcome this issue, on board test instruments can be incorporated into the system and the
boundary scan JTAG interface used to access them and control them.

To ensure the greatest level of functionality the new IJTAG system defined by IEEE 1687
provides additional access and functionality over that which could be obtained from the basic
JTAG TAP.

IJTAG basics
IJTAG uses the JTAG TAP as the primary interface, but extends the operation considerably. One
of the key features is that it standardises the interface for embedded instruments, along with the
description of their operation, and connectivity through the design hierarchy.

IJTAG is simple to implement and use because of the plug-and-play approach for both in-house
and third party elements.

The key advantages and elements of the IJTAG system are summarised in the table below:

PARAMETER JTAG IJTAG

External interface to Instrumentation control is Standardised and with plug-and-play capability.

internal elements. vendor specific.

Internal control. Ad-hoc and typically Standard protocol.

vendor specific.

Instrument access. manually defined at the Automated re-targeting from IJTAG TAP to instrument
JTAG TAP interface. through a logical hierarchical structure.
Register size Fixed for each instruction. Variable.

Two elements of the IJTAG interface that are key to its operation.

Two elements of the IJTAG interface that are key to its operation.

● Instrument Connectivity Language, ICL: The Instrument Connectivity Language is

based on the design description. It focuses on the information necessary to write to or
to read from the instrument, i.e. typically the tests required. In other words the ICL
essentially describes where the IJTAG Test Data Registers, TDRs are, the scan paths
that connect and access them, how and when these scan paths should vary. It also
describes the connections between the IJTAG scan paths and the boundary-scan
TAP controller on the device, and the parallel connections between the embedded
IJTAG instruments and the IJTAG TDRs.
● Procedural Description Language, PDL: This language defines the syntax of the
read, write and scan operations. The PDL defines the operations and functions of the
instrument, and it is converted into test vectors that are associated with each IJTAG
instrument that is within a device. A further function of the PDL is to document the
actions and sequences of the instruments.

Internal JTAG - A cutting-edge solution for embedded instrument 

testing in SoC: Part 1 
By Medha Thakar , Chintan Panchal
(eInfochips, an Arrow company)

Abstract

The semiconductor industry has been

deeply influenced to spur innovations,
owing to the expansion of IoT, AI, and
wireless communication in the market. It is
essential to shape these innovations into
products within a stipulated time frame and
at high quality to withstand competitive
demands. In order to achieve this, IP
re-usability has become significant and is
driving the industry towards standalone IP
testing.

The highly-efficient utilities offered in our

smartphones, tablets, smart TVs, and voice
assistants like Alexa or Google Home are
made possible due to the integration of
embedded memories, microprocessors,
CPU, Analog IPs, mixed-signal IPs, DSP,
clock and power control on a single chip
that is present within these sophisticatedly
designed gadgets.

The most recent breakthrough in Apple A11

Bionic SoC has made it possible to have a
6-core 64-bit ARM CPU, two of which are
running at 2.33 GHz, a 3-core GPU, DSP for
image processing capabilities, a security
coprocessor, and multiple IPs present on a
single chip. For such complex SoCs, it
becomes crucial to have a uniform interface
mechanism to access these IPs individually
in order to test and diagnose for defects
introduced during the fabrication process.
Conventional approaches towards system
testing described under standards of IEEE
11491/1500 are not equipped to handle the
demand for test design automation.
Further, these standards pose certain
limitations related to test access time and
test vector re-usability of an IP when it gets
instantiated multiple times at different
levels of hierarchy. In order to address
these test challenges, the IEEE IJTAG
working group coined an IEEE-P1687 IJTAG
(Internal JTAG) Standard with the
motivation to provide a uniform and
efficient methodology for control and access
of embedded instrument within a
semiconductor device.

This article is divided into two parts. The

first part outlines the important features of
the IJTAG use model, while the latter part
describes a network interface, its
architecture, and how it addresses the
major challenges of the SoC test.

Introduction

Making lives simpler and easier through

automation is indeed leading to a more
complex architecture of SoCs. With the
increasing complexity of SoCs,
implementing an efficient system test
methodology becomes of utmost
importance.

This can be achieved through the

implementation of the IEEE P1687 standard,
also called Internal JTAG (IJTAG) standard.
According to the documentation provided in
IEEE P1687, IJTAG is defined as the
“​Standard for Access and Control of
Instrumentation Embedded within a
Semiconductor Device. This Standard will
develop a methodology for access to
embedded test and debug features, (but
not the design of the features themselves)
via the IEEE 1149.1 Test Access Port (TAP)
and additional signals that may be required.
The elements of the methodology include a
description language for the characteristics
of the features and for communication with
the features, and requirements for
interfacing to the features​” [1]. This
standard does not intend to define the
instrument themselves, but standardize the
description of the features of the instrument
and define its connectivity with other
instruments via standard protocols [2].

An instrument may be referred to as any

on-chip circuit under test and diagnosis,
which can be accessed, configured, and
communicated with via an IEEE 1149.1 TAP
& TAP controller. Broadly, an Intellectual
Property (IP) can be called an instrument.
This standard has not replaced the existing
test protocols of IEEE 1149.1 (JTAG) or
IEEE 1500 (WTAP). In fact, it defines
network connectivity of instruments that
have been interfaced through the
WTAP/JTAG interface to communicate with
JTAG TAP present at the chip-level.

Let us understand the meaning and

importance of IJTAG through the following
scenario:

Consider a simple SoC that has 2

hierarchical components; Blocks- B1 & B2
as illustrated in Fig. 1. B1 has a WTAP
interface while B2 has a JTAG interface. The
SoC also has a top-level TAP, through which
the 2 blocks are to be accessed. WTAP can
easily provide the signals/bits from the core
of B1 at its boundary, while the bits/signals
associated with the core of B2 are brought
at the boundary via TAP2 & TDR. However,
to access these blocks from the SoC level,
bits present at the respective block
boundary have to be brought at the
top-level. IJTAG P1687 provides a uniform
access framework, communication protocol,
and interface description required to define
these bits at top-level. Furthermore, the IPs
in SoC design need to communicate with
one another as well. IEEE P1687 defines the
scan path configurations between different
IPs of the SoC and scan path configuration
between the IP and the TAP controller that
controls the communication among two IPs.

Fig. 1 Access WTAP/JTAG interface core

from SoC TAP via unstructured network
interface

Why is the JTAG/1500 standard not

sufficient?

One may wonder whether the additional

IJTAG network architecture is worth the
cost of having extra hardware, which would
increase the design area, especially when
the embedded IPs can be accessed via JTAG
TAP and TDR methodology. Here’s the
answer; the purpose is to interface with the
embedded MBIST instrument of B1. The
instruction code fed into the IR selects the
instrument to be interfaced. Thus, only one
instrument can be accessed at once via
single active IEEE 1149.1 instruction. The
length of the TDR is fixed irrespective of the
instrument selected on the chip. This
means, the boundary scan chain length is
fixed and has a fixed instruction
configuration. Moreover, all the instruments
would have to remain accessible throughout
even if all of them are not targeted
simultaneously since all are connected in a
single-daisy chain [3]. The
above-mentioned features make JTAG
network inefficient with respect to Scan
Path Management, which in turn leads to
longer test time and ultimately higher test
cost. IEEE P1687 standard has been
proposed and formulated to overcome all of
these limitations.

IJTAG use model

The IJTAG use-model shown in Fig. 2

explains the implementation of access
methodology with the P1687 standard. It
depicts three regions – the ‘Instrument
zone’, which is targeted or which is to be
interfaced with (rightmost region), the
‘IJTAG Network Interface zone’ present in
the middle region, and the leftmost region
is that of the ‘controller zone’ and
comprises the TAP and its controller. It
must be noted that the TAP controller, the 4
ports of the TAP, and the instrument are
not a part of the IJTAG standard. In this
model, the access of the instrument is done
through the TAP just like in the previous
scenario, however, the IJTAG network
provides an interface platform that
facilitates active scan path management
thus providing a powerful plug and play
feature to this standard.

The IJTAG use-model operates as follows:

● The ‘scan in’ (si) signal from TDI of

TAP first enables the ‘select bit’
associated with the scan path of the
instrument.
○ This helps activate the
specific scan path associated
with the instrument which is
to be interfaced with; in this
case, the MBIST instrument
○ This ‘select bit’ is referred to
as Segment Interconnect Bit
(SIB).
● The SIB generates the select signals
locally that are fed to the TDR, which
is responsible for access of MBIST
instrument.
● MBIST controller begins the memory
test once the ‘RUN’ signal is provided
by the TDR. After the memory test is
completed, the ‘DONE’ signal and
‘STATUS’ indicating PASS/FAIL
status is fed back to the SIB via
‘from_so’ signal of TDR.
● SIB provides this PASS/FAIL signal
to the TAP via the ‘so’ signal.

In this manner, the embedded MBIST

instrument can be accessed via the
top-level TAP in a SoC through the use of
the IJTAG network interface.

Scan paths that enable access to the

instrument under test can be closed after
the instrument has been started [3]. For
example, after all the start signals for the
MBIST instrument are activated, testing of
all the memory instances in complex SoCs
would take a long time. Until the test is
complete and produces PASS/FAIL status,
the path would remain active if the SIB
continues to be 1.

Fig. 2 IJTAG use model

This would unnecessarily keep the

resources on this scan path busy and lead
to longer test times. To prevent this, after
all the instruments and TDR present on this
scan path are made active, independent
tests can be run offline and SIB control bit
can be set to 0 again. This would allow the
operations to start on other instruments
and would not affect the instruments on
inactive scan paths [3]. Launching
simultaneous tests thus helps in reducing
test access time. Furthermore, while we
access a particular instrument, other
instrument access is not required; the SIB
associated with them can be disabled to
keep it off the scan path. This too helps
reduce access time, which is another
significant benefit of this standard. The
operation of the standard can be
understood clearly once all the components
of the IJTAG standard are described. This
shall be covered in the next part of the
article to be released soon.

Conclusion

In this part of the article, we examined how

the fixed-length TDR and fixed instruction
configuration of the JTAG standard make it
inefficient to meet the growing demand of
test design automation in a SoC with
multiple embedded IPs. According to our
brief description of the IJTAG use-model in
this section, we looked at how test
automation could be enabled using this
standard. We also learnt that the IJTAG
standard does not replace the existing IEEE
1149.1/1500 standard. Some of the leading
vendors of the silicon industry are adopting
this standard at a rapid pace as it provides
ease of access to MBIST, internal scan
chains of the chip, and in turn expedites
debug features.

References:

1. A Presentation Based on Slides

Created by Members of the IEEE
P1687 (IJTAG) Working Group, “IEEE
P1687 (IJTAG) Draft Standard for
Access and Control of
Instrumentation Embedded Within a
Semiconductor Device”, Jun 2006
2. Laung-Terng Wang. Charles E.
Stroud. Nur A. Touba, Laung-Terng
Wang, “System-on-chip Test
Architectures: Nanometer Design for
Testability” Morgan Kaufmann
Publishers, Version 2008.
3. Al Crouch, “IEEE P1687 Internal
JTAG (IJTAG) taps into embedded
instrumentation” Asset White Paper,
Version 2011