Open Tools and Standards Emerge for Embedded Instrumentation
by Al Crouch, ASSET InterTech
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.
To view Table 1 click here.
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.
To view Table 2 click here.
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).
To view Table 3 click here.
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.
Figure 1. Graph Relating the Number of Instruments to the Architecture
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: acrouch@asset-intertech.com