JTAG

embedded world 2012 - February 28 to March 1, 2012, 2011

2012-01-30T10:53:00.000-08:00

The embedded world Exhibition&Conference is the world´s biggest exhibition of its kind and the meeting-place of the international embedded community. Embedded technologies are in action everywhere - whether in the car, data and telecommunication systems, industrial and consumer electronics, military systems or aerospace.

embedded world 2012 - February 28 to March 1, 2012, 2011

More here: http://www.embedded-world.de

embedded world 2011 - March 1-3, 2011

2011-01-21T16:59:00.000-08:00

The embedded world Exhibition&Conference is the world´s biggest exhibition of its kind and the meeting-place of the international embedded community. Embedded technologies are in action everywhere -whether in the car, data and telecommunication systems, industrial and consumer electronics, military systems or aerospace. 730 exhibitors showed the 18.350 visitors the full range of products for embedded technologies in 2010: hardware, software, tools, services and lots more.

March 1-3, 2011

More here: http://www.embedded-world.de

Flash Programming Speed

2010-11-17T14:13:00.000-08:00

Introduction

Calculating the theoretical Flash programming speed using boundary-scan can
provide a good estimate for the time it will take and allows us to evaluate how
specific factors will affect programming speed. To follow the Tips to Reduce
Flash Programming Time, we’ll look at how to calculate the theoretical
programming speed, and then use the formula to get a better idea of how
different factors may affect programming speed.

Calculating Theoretical Programming Time

For this discussion, let's assume a 16-bit wide S29GL512P Spansion device using
single-word program mode. While this device supports buffered programming with a
32-word buffer, due to the way boundary-scan accesses the Flash, the difference
between single-word and buffered programming times is often minimal. The time it
takes to scan the chain for each data write—which takes up the bulk of the
programming time—remains the same.

The following equation, pulled from our DFT Guidelines, is commonly used for
calculating the theoretical time that it takes to program Flash memory time
using the boundary-scan interface. This equation assumes ideal conditions and
will show the best programming time that can be achieved.

(#bits in chain) * (#scans/write) * (#writes/location) * (#locations)

TCK frequency

Where the parameters are defined as:

Table 1: Flash Programming Parameter Descriptions

Example Calculation

We’ll perform an example calculation using the following conditions:

Table 2: Example Flash Program Speed Calculation Data

The absolute minimum programming time that can be achieved when programming the
entire device is:

370 seconds for each megabyte of data isn’t great—that’s over 6 minutes!
Hopefully there’s something we can do to improve this speed. Let’s see how the
chain length and TCK rate will affect programming speed.

How TCK Rate and Chain Length Affect Programming Speed

Using our equation for calculating program time, we can explore how different
factors affect programming speed. First, vary the TCK rate between 1 MHz and 25
MHz. The data is presented in the graph below.

Figure 1: Flash Program Rate vs. TCK Frequency

Note that utilizing the External Write signal cuts the programming time
approximately in half—utilizing this feature can often provide dramatically
improved performance.

Figure 2: Program vs. Scan Chain Length

Notice that as the scan chain length approaches 650 bits with external write and
300 bits without external write, the boundary-scan programming rate crosses the
programming rate based on typical write time. At this point, the boundary-scan
Flash programming performance will be similar to the programming rate described
by the device data sheet, and boundary-scan will be able to scan faster than the
device can program! To prevent data errors, the poll-for-done option will need
to be utilized to ensure that the previous program operation has completed
before the next scan begins.

Conclusion

Now that we have an intuitive understanding of how chain length and TCK rate
affect programming rate, we can put our knowledge into practice. Programming
rate too slow? See if the TCK rate can be adjusted for Flash programming, and
make sure that the chain is being optimized as much as possible.

Source: Calculate Flash Programming Speed

Adaptive FPGA Programming for SVF and STAPL/JAM

2010-11-16T14:19:00.000-08:00

Introduction

There are two common file standards for programming FPGAs: SVF and STAPL/JAM.
Most vendors can generate either type of file, but which should you choose?
First we should look at a significant difference between the two: STAPL allows
the use of conditional expressions, while SVF does not. In terms of FPGA & CPLD
programming, this means STAPL can provide adaptive programming, while SVF is
limited to delays.

How It Affects Programming Speed

In general, an adaptive programming algorithm will run faster than a
non-adaptive programming algorithm, since it can poll the device status and
determine exactly when programming has been completed and execution may resume.
Non-adaptive programming algorithms must wait a pre-defined time—usually the
device’s worst case program time—before proceeding.

The flow charts below show simplified examples of programming algorithms:

Figure 1: Programming flow charts

If the worst case delay far exceeds the typical and minimum delay, then the
adaptive programming will finish first. In some cases, increasing the clock rate
and shortening the delay on the non-adaptive file may allow it to surpass the
adaptive programming speed.

Conclusion

STAPL files can often provide better programming performance than SVF files.
Despite the lack of adaptive programming features in SVF, ScanExpress Runner and
ScanExpress Programmer JTAG implement some techniques in SVF execution to speed
up programming, such as re-scanning on failure and adjusting delay time when a
particular suffix (_xilinx.svf, etc.) is used. Additionally, Lattice has
expanded their SVF files to include non-standard LOOP statements to facilitate
adaptive programming.

What is your experience with CPLD and FPGA programming? We’re always seeing new
and unusual cases—a new FPGA programs slower than its previous version, STAPL
executes much faster than SVF and in the odd case, SVF executes much faster than
STAPL, etc.—and look for input to help improve our software.

Source: SVF and STAPL/JAM: Adaptive FPGA Programming

HSWAP pin for FPGA

2010-11-15T14:17:00.000-08:00

Introduction

The HSWAP pin (also known as HSWAP_EN or PUDC) is commonly found on Xilinx FPGAs.
This pin controls whether the FPGA’s user IO pins will have a pull-up resistor
or float—when HSWAP is LOW, each IO pin will have an internal pull-up resistor.
For our example we’ll look at a particular Spartan-3 case, but this may apply to
other parts as well.

Consequences

In most cases, the JTAG and configuration control pins will keep their
pull-ups regardless of the state of the HSWAP—but in our experience we’ve seen
evidence of exceptions where the internal pull-up on some FPGAs has an effect on
compliance pins, such as INIT_B or PROG_B. This is an important distinction—in
certain cases INIT_B & PROG_B will have a dependence on HSWAP, so it’s often a
good practice to use external pull-up or pull-down resistors rather than relying
on the internal pull-ups to control these lines.

Example

Consider the four cases below:

Figure 1: Four cases of HSWAP & INIT_B/PROG_B configuration

Note: These cases make the assumption that the HSWAP_EN pin will have an effect
on PROG_B and INIT_B, but this is not always the case. Consult the device
documentation and errata for details.

In the cases 1 and 2, important compliance and input pins are connected to
strong pull-up/pull-down resistors and the state of HSWAP should have no effect
on the state of these pins. In case 3, INIT_B and PROG_B are floating and may
cause test failures. In case 4, the pull-down on HSWAP ensures that input pins
are pulled up, but does not cover the case where an input or compliance pin may
need to be pulled down.

Conclusion

When designing for boundary-scan test, it pays off to consider the
pre-configuration behavior of FPGAs. To cover all scenarios—though it may not
always be necessary for boundary-scan test—it’s a good idea to include a strong
pull-down on HSWAP during boundary-scan test, but consider the consequences of
pull-ups on IOs before relying on it for pre-configuration cases. Whenever
possible, include pull-ups/pull-downs on configuration and mode pins such as
INIT_B & PROG_B. As always, when in doubt check the device documentation!

Source: FPGA: HSWAP pin

Bypass Boundary-Scan Devices

2010-11-14T14:15:00.000-08:00

Introduction

On occasion and due to incompatibilities, non-compliance, debugging, or various
other factors related to the boundary-scan chain, it may be necessary to
physically bypass a boundary-scan device and remove it from testing. The most
common approach is to add a bypass resistor, but there are important
consequences with this approach. We’ll discuss some considerations that should
be noted when bypassing an installed device to remove it from the scan chain.

Active TDO

When physically bypassing a boundary-scan device, note that the output of the
bypassed device may still be driving unless explicitly disabled. This may result
in two devices driving the input to the next device at the same time. In the
following diagram, if U2 is bypassed with U2_BYPASS_RESISTOR and U2 remains
installed, both U1.TDO and U2.TDO drive U3.TDI.

Figure 1: Common device bypass configuration

Hardware solutions to the active TDO problem

The simplest method of removing the contention between TDO pins is to physically
remove the connection between the conflicting TDO pins. Some options include:

Remove the series termination resistor. If there is a series termination
resistor as shown below, it may be removed to eliminate the contention on TDO
pins.

Figure 2: Series termination resistor on TDO

Lift the U2.TDO pin

Remove U2

Cut the trace connected to U2.TDO, before it connects to the bypass
resistor trace

Lift the U3.TDI pin, and wire from U1.TDO to the lifted pin

Software solutions to the active TDO problem
In cases where modification to the hardware is undesirable, there are some
additional solutions that may be used. These solutions rely on specific behavior
with respect to the JTAG control signals and, in our experience, not all devices
will perform the same way.

Keep TMS to the device high, and provide at least 5 TCK during testing
Per the IEEE-1149.1 2001 standard section 6.2, the TDO pin should be inactive
(tri-stated) when it is not driving data. This can be guaranteed by forcing U2
into JTAG reset mode by giving it five or more clocks with TMS high. Note that
some devices may not fully conform to the standard. Additionally, in the typical
design, the TMS signal connected to U2 is connected to other devices as well.

If the device uses TRST, hold it active
Note that in a typical design, the TRST connected to U2 is connected to other
devices, too. This option is only viable if the TRST line connected the device
to be bypassed does not affect other boundary-scan devices.

Additional Considerations

TCK and TMS
Even after the TDO connection has been removed, the bypassed device still
receives TCK and TMS signals. This causes the device to receive all JTAG state
machine commands (on the still connected TMS) and data (on the still connected
TDI). This may place the device in an unknown and possibly undesirable state.
This rarely has an effect on testing or board safety, but it is a possibility.
If TMS on this device is not shared with additional boundary-scan devices, the
solution is to hold TMS high.

Boundary-scan device operation in non-boundary-scan mode
This is not a factor for boundary-scan chain operation, but is a factor in
testing. Now that the device is not in the scan chain, it will operate
“normally”, which may involve driving pins to unknown states. Just like all
other non-boundary-scan devices, for maximum test coverage it is advantageous to
control the device so that the outputs are disabled. If the outputs drive, those
nets cannot be tested due to contention.

Conclusion
While it’s great when things go well, it’s important to be prepared for some
debugging. Whenever possible, it’s a good idea to design the board to facilitate
test and debug—not only do series termination resistors improve signal quality,
but can ease the process of wiring around a problem device. For more tips on
designing for testability, visit the Design Tips and Guidelines section of our
website.

Source: Bypassing Boundary-Scan Devices

JTAG Program CPLDs & FPGAs

2010-11-13T14:11:00.000-08:00

Introduction

In-system programming (ISP) of CPLDs & FPGAs is a key application of JTAG. Most
modern CPLDs & FPGAs include a JTAG port for programming and boundary-scan
tests, and each vendor provides the software to generate an SVF or STAPL/JAM
file for execution in ScanExpress Runner or Programmer.

In this topic we'll discuss the basic topologies—with respect to JTAG and ISP—of
CPLDs, FPGAs, and Configuration Devices and how each one affects our approach to
ISP. For the purposes of this discussion, we’ll keep the topic vendor
agnostic—the methods for each vendor are remarkably similar.

CPLDs

CPLDs present the simplest case: the lack of external configuration devices
means that you’ll be directly programming the logic device through JTAG.
Creating a JTAG programming file should be a straightforward process when using
the appropriate vendor’s software—usually a matter specifying the part number,
the configuration data, then generating the SVF or STAPL/JAM file.

It should be noted that some CPLDs internal “configure” on power up, loading
data from an internal Flash to an internal SRAM. In this respect, they resemble
FPGAs. Additionally, some modern FPGAs include non-volatile memory as well,
further blurring the lines between FPGAs and CPLDs. Fear not—with respect to
ISP, these CPLDs may be treated the same as traditional CPLDs.

FPGAs

FPGAs present some complications due to their volatile nature. Rarely will it be
necessary to program an FPGA through JTAG—instead, we want to program the
configuration device such that the next time (and any subsequent times) the
board boots, it will load the new configuration data.

FPGA and configuration device connections usually come in one of two flavors:

The FPGA and configuration device are both connected to the scan chain. The
configuration device may be programmed directly through JTAG.
FPGA is on the scan chain, but the configuration device does not have a
JTAG port. The configuration device must be programmed indirectly through
the FPGA.

JTAG Programmable Configuration Device

We’ll first examine the case of a JTAG programmable configuration device, as
shown below. Since we have direct JTAG access to the configuration device, it is
simply a matter of scanning out the correct instructions and data. The vendor’s
generated SVF or STAPL/JAM file will be ideal.

Figure 1: JTAG programmable configuration device

Note that since the FPGA’s connection (other than TDO to TDI) is not necessary
for programming, the FPGA’s boundary-scan register does not need to be scanned
each time. Configuration devices generally have few pins. Taking these two
factors together, we observe that programming through JTAG is very efficient in
this case, and can result in significantly better programming times than the
cases we’ll explore next.

When a JTAG connection is available on the configuration device or CPLD,
programming is about as simple as it can get. In the next post, we’ll discuss
how to deal with FPGAs that utilize non-JTAG configuration devices.

Source: JTAG Programming of CPLDs & FPGAs

Phase-locked Loops (PLLs) in Clock Buffers - JTAG Boundary-scan Tip

2010-11-12T14:09:00.000-08:00

PLLs contained in clock distribution ICs generally will not function correctly with a clock input that neither maintains a constant frequency nor operates in the correct frequency range. This applies to both the JTAG clock (TCK) and to synchronous device clock pins, such as those found on SDRAM.

However, all hope is not lost! Many buffers have a method of disabling or bypassing the PLL. For boundary-scan testing this mode should be used whenever possible, and the clock distribution device should use a transparent model in ScanExpress TPG. Some common methods for dealing with PLLs include:

PLL disable pin, such as a test pin.

Mode pins, which include a bypass mode. Sometimes this is stated by
saying the “reference” is applied to the outputs.

Applying a different voltage (sometimes no power) to a power pin,
usually the PLL power pin.

Please refer to the device data sheet to determine if and how the
internal PLL can be disabled.

For example, compare the popular Cypress CY2305 & CY2309 clock buffers (data sheet available from the Cypress website at

http://www.cypress.com/?rID=13269). See table 2 of the referenced data sheet: CY2309 includes select input pins not available on the CY2305, adding a PLL shutdown mode in which the output source follows the reference clock, allowing the clock buffer to be treated as a transparent device during boundary-scan tests.

Source: JTAG Boundary-scan Tip: Phase-locked Loops (PLLs) in Clock Buffers

Strong Pull-ups on FPGAs - JTAG Boundary-Scan Test Tip

2010-11-11T14:07:00.000-08:00

Introduction

Many FPGAs in their preconfigured state include relatively strong internal
pull-up/pull-downs, often in the 4.7k-ohm range or lower. If a weak
pull-up/pull-down resistor is attached to such a pin, there is risk that the
pull-up/pull-down test may fail.

Explanation

Consider the simplified diagram below:

Figure 1: 10k Pull-down attached to a pre-configuration
BIDIR FPGA pin

The pre-configuration boundary-scan pin has an effective internal pull-up
resistance of 4.7k-ohms. It is externally strapped with a weak 10k-ohm pull-down
resistor. Driving the net will not be a problem—when the output buffer is
enabled, current will flow through either resistor, allowing the output node to
be driven and sensed both HIGH and LOW.

However, the pull-up/pull-down test will tri-state the output of this pin and
then expect the 10k pull-down to take the value (as sensed by the input cell)
down to “0”. This is not the case—let’s determine why.

Voltage Dividers

When the output buffer tri-states, we end up with a simple voltage divider
between the internal effective resistance and the external pull-down. We can
calculate the value here:

Vpd = Vcc * Rext/(Rext + Rint) = Vcc * 10k/(4.7k + 10k) ~= 0.7Vcc

This is a very high value and will likely not meet the VIL requirements, causing
the resistor test to fail, possibly intermittently.

Resolution

When this situation occurs, the best solution may be to remove the net from
testing during the resistor test. While—depending on resistor values—it may be
on the border of meeting the threshold requirements and often sense LOW, it is
probable that it will not be reliable and cause false test failures. In reality
the pull-down should be considered un-testable by boundary-scan
pull-up/pull-down test methods.

Source: JTAG Boundary-Scan Test Tip: Strong Pull-ups on FPGAs

JTAG Cables

2010-11-10T14:03:00.000-08:00

Introduction

TAP adapter cables are often necessary to convert from the standard
pinout to the TAP connector pinout of a particular target. The pinout may be
Altera or Xilinx programming headers, CPU emulation headers, or other
proprietary pinout. In this discussion, we’ll cover design considerations for
creation of custom TAP adapter cables.

Creating TAP Adapter Cables

Most TAP connectors are two rows of 0.025 inch square posts on 0.1 by 0.1 inch
centers, making them suitable for mass terminated ribbon cable. In some cases,
the TAP connector may be single row, or part of a much larger connector, such as
a DIN connector.

When designing and constructing an adapter cable, there are a few design factors
to consider.

Which Boundary-scan controller is being used? If only
controllers with 20-pin TAPs will be used, a 20-pin ribbon cable connector
such as a 3M 3421-6620 will plug directly into the controller. If an older
controller will be used or a variety of controllers will be used, we
recommend using a 10-pin cable connector such as a 3M 4610-6351 for maximum
compatibility. This will accept the 10-pin cable connector from all
controllers.
Ensure that the mating connectors are obtained first. The acquisition
process may take days, so get it started as soon as possible.
Maintain good signal integrity by using as short a cable as
practical. This will help EMI, crosstalk, cable capacitance, etc.

Maintain good signal integrity with good signal return paths. The ground
wires affect signal integrity because they are the return path for the
signals. To enable high TCK rates, our boundary-scan controllers have signal
slew rates in the 2-5 ns range. This requires a good signal return path,
commonly called ground, to insure signal quality. On the standard
pinout, there is a signal return path for every signal. Many TAP connectors
on boards to not have a ground for every signal. We recommend connecting all
the grounds of the boundary-scan controller cable to the target ground pin
or pins. If there is one ground pin, it should be fanned out to all the
cable grounds. If there are two ground pins, we recommend connecting the
board ground pin closest to the board TCK pin to the cable ground wire
closest to the cable TCK signal. All other ground wires in the cable should
be connected to the second ground. For example, for the Altera programming
header, the wirelist should be as follows:

Table 1: Example Pinout for Altera Programming Header
Maintain good signal integrity with signal termination. Serial
and pullup/pulldown termination is best done on the board. However, if the
board lacks the appropriate termination, it can occasionally be solved by
placing the termination on the cable.
Verify the pinout. It is very easy to swap the TDO/TDI pin
assignments of the target versus the boundary-scan controller cable. Do not
rely on the signal names. Check that the direction of the data flow matches.

Test the cable. Once the infrastructure test is working,
determine the maximum TCK rate. We recommend then looping infrastructure so
it runs at least two minutes. This will test the signal integrity of the
scan chain, including the adapter cable.
If an adapter PCB is used instead of an adapter cable, the same
concepts apply. Verify the pinouts. Use a ground plane to insure good
signal return paths. Connect as many ground pins as possible to the ground
plane.

If the UUT does not have the recommended termination, it may be
helpful to implement the termination in the cable or adapter PCB.

A cable with a ground plane is usually not needed. If the signal
return paths are limited, it may help, replacing the signal return paths. If
testing in a high EMI environment, it may help provide some shielding when
oriented so that the ground plane is between the EMI source and the signal
wires.

If in a high EMI environment, use twisted pair wires, preferably
twisted, shielded pairs. This can be awkward to implement, so this
is recommend as a last resort when EMI is a strong suspect as a problem
source.

When using wire wrap wires to make connections, the same concepts
apply. At least twist the TCK with a ground wire. Preferably, twist all
signal wires with a signal return wire. Connect the signal return wire
at both ends. On the controller end, connect to the “paired” return wire
(1&2, 3&4 etc). At the target end, connect to grounds as close as possible
to the signal connection.

Source: JTAG TAP Adapter Cables

Tutorial: The Role of JTAG in system debug & test throughout the embedded system development lifecycle

2010-04-15T17:21:00.000-07:00

JTAG Debug Advantages
The primary advantages of using a debugger with JTAG access are:
* The JTAG connection provides direct access to the otherwise hidden CPU core
* The JTAG interface consumes no system I/O ports (serial, Ethernet)
* The JTAG debug method uses little or no system memory allocation (as in monitors)
* There is no monitor to crash along with a system crash (not useful at board bring-up)
* The JTAG connection does not require target system power (except some USB-only probes)
* A JTAG debugger can "steal cycles" to read registers/memory without stopping CPU (assuming that the debug logic built into the CPU provides this capability)
* A JTAG debug session can reset and/or initialize the system (Note: System reset is not part of JTAG. Rather, it is an adjunct to using JTAG for remote debugging, enabling a remote reset of a JTAG probe and target over a network.)
* A JTAG debugger can connect to the debug logic without perturbing the system
* Provides the only reasonable means to connect to targets that do not yet have working bootcode or I/O drivers

JTAG Debug Limitations
The JTAG debug connection does not solve all the world's debug problems because of some serious limitations:

1) Code download over JTAG is not the fastest way to download large programs (>20MB), especially for target systems that rely on 10/100BaseT Ethernet access.

2) Multicore system debug where multiple CPU cores are daisy-chained on the same scan chain and can be individually accessed, but implementing a synchronous debug operation requires additional on-chip hardware to circumvent skidding associated with JTAG operations.

Subsequently, hundreds of CPU cycles may go by after an asynchronous JTAG stop command is issued. Examples of these capabilities are now beginning to appear, e.g., the global inter-processor control logic in Cavium Networks Octeon family, with up to 16 64-bit cnMIPS cores.

3) "Printf" still provides an easy complement for extracting a variety of debug status reports.

JTAG to the Rescue - Boundary Scan Testing
The Joint Test Action Group (JTAG) began solving board-level test problems in the 1990's by standardizing a serial scan chain method (JTAG; IEEE 1149.1) for accessing on-chip resources and additional shift registers built into the I/O paths of every IC for boundary scan testing.

Before the emergence of boundary scan testing, debugging of potential solder bump issues underneath a chip assembly was difficult. Prior to board assembly, every IC is tested to assure its flawless operation. Thus, if the assembled printed circuit board PCB does not work properly, the malfunction must be caused by a solder bridge, gap or a flaw in the printed circuit board. But what if the flaw is underneath the chip assembly, where it can't be seen or repaired easily?

The boundary scan testing methodology addresses this issue. As illustrated in Figure 1, a serial scan path through I/O registers was added and exercised by a sophisticated test program unique to each board to help identify a faulty chip or other device, so that these can be reworked or replaced. In the diagram in Figure 1, each grey box represents a category of device function, e.g., flash, peripherals, I/O ports, etc.

Figure 1. JTAG connection used for boundary scan testing

The JTAG approach provides a method to test very complex systems, while keeping the pin count low. Specifically, the IEEE1149.1 specification requires only 5 pins for the JTAG connection, no matter how long the scan chain register path is. The standard pin functions for the JTAG Test Access Port include:

TRST Test Reset (output from JTAG probe to chip to reset JTAG test logic)
TCK Test Clock (output from JTAG probe to chip to set JTAG scan rate)
TDI Test Data Input (serial test data input to chip)
TDO Test Data Output (serial test data output from chip)
TMS Test Mode Select (determines run or debug mode by state at TCK rising edge)

Several companies focus almost exclusively on boundary scan testing, specializing in both the JTAG hardware connection devices and host-based test software tools to adapt the test program to each board design.

The 2nd Role of JTAG - CPU Core Access for Software/Hardware Debug
Given that the CPU processor core is now hidden from observation or control by integrated caches in the core, by local on chip busses, by an MMU that dynamically allocates memory, and by other SOC peripherals and I/O blocks, the JTAG path provides a direct connection into the debug logic inside the CPU. Thus, we now have a means of observing and controlling program execution. Since caches and peripherals have moved on chip, so must the debug logic (Figure 2 below).

Figure 2. JTAG connection use for software debug/development

With this direct core access, host-based debugger software can now assert a "debug exception", redirecting the processor to get the next instruction from the debug logic registers instead of the program counter, thus effectively taking control of the processor to perform software debug operations:

* Run-control: Start, Stop, Single-Step, Step Into/Over (source or instruction)
* Set hardware and software breakpoints
* Specify conditions to be met or scripts to be executed at breakpoints
* Control reset and initialization of the target system
* Download code to be debugged or code to be programmed into flash
* Execute flash programming and other semi-hosting utilities

Note that in both of the above applications, boundary scan and software debug, the role of JTAG is only to provide the physical layer communications interface, analogous to the PHY layer in the ISO Open Systems Interconnect model.

The protocol for what debug functions are supported is embodied in the debug logic, designed into the CPU core and the debugger software capabilities running on the host computer.

[1][2][3][4]

Source: Tutorial: The Role of JTAG in system debug & test throughout the embedded system development lifecycle by Lyle Pittroff

embedded world 2010

2010-03-01T14:22:00.000-08:00

The embedded world Exhibition&Conference is the world´s biggest exhibition of its kind and the meeting-place of the international embedded community. Embedded technologies are in action everywhere -whether in the car, data and telecommunication systems, industrial and consumer electronics, military systems or aerospace. 704 exhibitors showed the about 16.000 visitors the full range of products for embedded technologies in 2009: hardware, software, tools, services and lots more.

More here: http://www.embedded-world.de

FREE JTAG Boundary-Scan Training Classes

2009-11-16T14:23:00.000-08:00

For those interested in learning more about Boundary-Scan, Corelis (a JTAG Boundary-Scan company) offers free three-day training classes that include a boundary-scan tutorial and hands-on lab exercises using Corelis ScanExpress hardware and software. The training class covers all aspects of boundary-scan testing using Corelis ScanExpress tools. Design for testability (DFT), JTAG embedded functional test (JET), in-system programming (ISP) and test procedure generation are also covered.

Registration is now open for 2010.

JTAG Boundary Scan Engineers on Facebook

2009-11-12T13:39:00.000-08:00

This group is dedicated to Engineers who currently work with and would like to learn more about JTAG Boundary-Scan testing tools and In-System Programming.

Join Now!

Do you love JTAG? There's a JTAG Lovers Group also! Join Now!

JTAG Hacking

2009-05-01T13:33:00.000-07:00

A JTAG enthusiast writes of his experience using JTAG to de-brick a router with corrupted firmware. JTAG is used to basically get access to the chips containing corrupted firmware and reprogram/reset code in the memory.

Read about it here:
http://www.networkworld.com/community/node/38699

iNEMI Boundary-Scan Adoption Survey

2009-01-15T14:16:00.000-08:00

iNEMI wants to hear about your experiences with boundary scan. Whether you work with printed circuit boards and use the technology (e.g., are a PCB designer, test engineer, engineering manager, design-for-test consultant, service & support staff, system architect, test equipment provider, etc.) or are an IC designer who integrates boundary scan into your products - iNEMI wants to hear from you. iNEMI is gauging the adoption rate of boundary scan and identifying any impediments to widespread use. Your input can provide valuable feedback to help improve test implementation and coverage for electronic products.

Survey Closed

How to Embed BSDL File Names in the Board Schematics and Netlist with Cadence OrCAD Capture

2009-01-12T09:57:00.000-08:00

This article explains how to use the Cadence OrCAD Capture program to embed the BSDL file names in the schematics. The BSDL file name and package information will then be included in the packages section of a Telesis format netlist when it is created by OrCAD Capture.

EMA Currents - Winter 2008 Edition

TMAG Testability Management Action Group

2008-12-16T10:13:00.000-08:00

The Testability Management Action Group (TMAG) is a grass roots organization made up of test professionals who believe that success for Testability in general, and Design for Testability (DFT) in particular, requires the involvement and the support of management at all levels.

We commend them for their hard work in DFT.

TMAG Testability Management Action Group

DFT Digest

2008-12-15T11:04:00.000-08:00

DFT Digest is a weblog about electronics Design-for-Test to discuss state-of-the-art DFT methods, technologies and best-practices, with the ultimate aim of better understanding design-for-test through the increased participation of the greater DFT community.

They are starting to offer tutorial materials and links to resources on DFT there: DFT Digest

Popular BSDL Files

2008-12-02T08:56:00.000-08:00

Corelis, a JTAG test vendor, now offers BSDL files for boundary-scan compatible devices to popular semiconductor vendors and their BSDL files.

You can locate the links and request form page here: BSDL file

Using BSDL

2008-12-01T16:10:00.000-08:00

When a board is designed, boundary-scan-compliant devices are organized into “chains”. Scan chains form the basis for system-level and board-level tests that are capable of detecting and diagnosing pin-level structural faults such as opens and shorts. Automated tools are used to generate test programs or procedures circuit boards. The most important inputs to this process are the BSDL files for JTAG devices and the netlist that describes the interconnects between the devices of the circuit board. The generated test program, when applied to a target board, reports structural test failures and can be used to assist in QA and board repair.

Some tools are capable in utilizing boundary-scan for creation of test patterns for component clusters which include non-boundary-scan-compliant devices. Some tools can generate test patterns which on-board processors can run to enable at-speed functional testing. These test procedures can be stand-alone or applied in conjunction with other test techniques, such as In-Circuit Testing (ICT), with the ultimate goal of producing optimal test coverage at low cost and with short development time.

The Boundary-Scan Handbook

2008-11-26T09:33:00.000-08:00

The Boundary-Scan Handbook, by Kenneth P. Parker, contains a collection of design rules applied principally at the Integrated Circuit level that allow software to alleviate the growing cost of designing, producing and testing digital systems. Chapter 2 is tutorial in nature.

Find it on Amazon: http://www.amazon.com/Boundary-Scan-Handbook-Kenneth-P-Parker/dp/1402074964/ref=cm_cr_pr_product_top

Informational guide to IEEE 1149.1
Since the mid-1970s, the structural testing of the loaded printed circuit boards (PCBs) has relied very heavily on the use of the so-called in-circuit "bed-of-nails" technique. This method of testing makes use of a fixture containing a bed-of-nails to access individual devices on the board through test lands laid into the copper interconnect, or other convenient contact points. Testing then proceeds in two phases: the power-off tests followed by power-on tests. Power-off tests check the integrity of the physical contact between nail and the on-board access point. They then carry out open and shorts tests based on impedance measurements. Power-on tests apply stimulus to a chosen device on a board, with an accompanying measurement of the response from that device. Other devices that are electrically connected to the device-under-test (DUT) are usually placed into a safe state (a process called "guarding"). In this way, the tester is able to check the presence, orientation, and bonding of the DUT in place of the board.

Fundamentally, the in-circuit bed-of-nails technique relies on physical access to all devices on a board. Such was the technique in the mid-1980s when a group of concerned test engineers got together to examine the problem and its solutions. The method of solution was based on the concept of a serial shift register around the boundary of the device - hence the name "boundary scan".

Principles of Boundary Scan
Each primary input signal and primary output signal is supplemented with a multi-purpose memory element called a boundary-scan cell. Cells on device primary inputs are referred to as "input cells"; cells on the primary output are referred to as "output cells". The input and outputs is relative to the core logic of the device. The collection of the boundary cells is configured into a parallel-in, parallel-out shift register. A parallel load operation, called a "capture" operation, causes signal values on device input pins to be loaded into input cells and, signal values passing from the core logic to the device output pins to be loaded into output cells. A parallel unload operation called an "update" operation causes signal values already present in the output scan cells to be passes out through the device output pins. Signal values already present in the input scan cells will be passed into the core logic.

Data can also be shifted around the shift register, in serial mode, starting from a dedicated device input called TDI and terminating at a dedicated device output pin called TDO. The test clock TCK, is fed in via another dedicated device input pin and the mode of operation is controlled by a dedicated TMS serial control signal. At the device level, the boundary scan elements contribute nothing to the functionality of the core logic. In fact, the boundary scan path is independent of the function of the device. On board the four; boundary scan devices are connected from one to the next in a serial format. The TDI input to the board is connected to the TDI input of the first device; the TDO output of the first device is connected to the TDI input of the next device; and so forth; creating a global scan path terminating at the TDO connecter output. TCK is connected in parallel to each device, TMS the control pin works similarly.

In this way, particular tests can be applied to the device interconnects via the global scan path by loading the stimulus into the appropriate device output scan cells via the edge connecter TDI (shift-in operation), applying the stimulus (update operation), capturing the responses at the device input scan cells (capture operation), and shifting the response values out to the edge connector TDO (shift-out operation). Essentially the boundary scan cells can be thought of as the "virtual nail".

There are four modes to be aware of normal, update, capture, and serial shift. During normal mode, data_in is passed straight through to Data_out. During update mode, the content of the output register is passed through the Data_out. During capture mode, the Data_in signal is routed to the shift register and the value is captured by the next ClockDr state. During shift mode, the scan_out of the register flip flop is passed through to the scan_in of the next via a hard wired path.

What is BSDL?

2008-11-20T16:29:00.000-08:00

The Boundary-Scan Description Language enables users to provide a description of the way in which boundary-scan is implemented in any particular device. As each chip designer tends to apply the boundary-scan standard in a slightly different way, it is necessary to express tests in a comprehensible, specific and usable fashion.

BSDL is written within a subset of VHDL. VHDL is commonly used as a design-entry language for FPGAs and ASICs in electronic design automation of digital circuits, and as such it is suitable for work with boundary-scan since design of many chips is performed using this language. However BSDL is a "subset and standard practice" of VHDL, i.e., the scope of VHDL is thereby limited for boundary-scan application.

During the design of BSDL there were two main criteria for the language:

It should be easy to use
It should be parsable by a computer in a simple and unambiguous fashion

BDSL enables accurate and useful descriptions of the features of a device that uses boundary-scan. The BSDL file is used by the boundary-scan tools to make use of the device features to enable test program generation, failure diagnosis, as well as use in any testability analysis. BSDL is not a language that can be used for hardware description; rather, it is used to define the data transport characteristics of the device, i.e. how it captures, shifts, and updates scanned data. This is then used in defining the test capability. The BSDL file includes the following data:

Entity Declaration: The Entity Declaration is a VHDL construct that is used to identify the name of the device that is described by the BSDL file.
Generic Parameter: The Generic Parameter is the section that specifies which package is described.
Logical Port Description: This description lists all the connections on the device. It defines its basic attributes, i.e., whether the connection is an input (in bit;), output (out bit;), bi-directional (inout bit;) or if it is unavailable for boundary-scan (linkage bit;).
Package Pin Mapping: The Package Pin Mapping is used for determining the internal connections within an integrated circuit. It details how the pads on the device die are wired to the external pins.
Use Statements: This statement is used to call the VHDL packages that contain the data that are referenced in the BSDL File.
Scan Port Identification: The Scan Port Identification identifies the particular pins that are used for the boundary-scan / JTAG implementation. These include: TDI, TDO, TMS, TCK and TRST (if used).
Test Access Port (TAP) Description: This entity provides additional information on the boundary-scan or JTAG logic for the device. The data includes the instruction register length, instruction opcodes, device IDCODE, etc.
Boundary Register Description: This description provides the structure of the boundary-scan cells on the device. Each pin on a device may have up to three boundary-scan cells, each cell consisting of a register and a latch.

Source: BSDL Tutorial

History of BSDL; Definition

2008-11-19T11:03:00.000-08:00

JTAG Boundary-scan is a well established test technology. JTAG Boundary-scan has been in use since the early 1990s when the Joint Test Action Group (JTAG) devised a solution to testing the many new printed circuit boards that were being developed and manufactured where there was little or no physical access for test probes. Once boundary-scan was established, the next step was to develop a standard modeling language for silicon vendors to model their boundary-scan devices, for tool vendors to develop automation tools, and for end-users to create boundary-scan tests. Thus the Boundary-Scan Description Language (BSDL) was created.

BSDL is the standard modeling language for boundary-scan devices. Its syntax is a subset of VHDL and it complies with IEEE 1149.1-2001. It is used by boundary-scan test developers, device simulators, semiconductor testers, board level testers, and anyone using boundary-scan. The use of BSDL promotes consistency throughout the electronics industry. Additionally, it enables the specification of any boundary-scan functions on a device in a useful, understandable, and consistent manner.

BSDL came out of the development of the boundary-scan test philosophy. The initial IEEE 1149.1-1990 standard describing boundary-scan was approved and released in 1990, and as a result the use of boundary-scan techniques started to grow. The next revision of the standard occurred in 1993. In 1994 a further revision incorporated BSDL into the IEEE 1149.1-1994 standard.

Source: TI Wiki

Differential Signals and JTAG Boundary Scan

2008-11-18T16:47:00.000-08:00

IEEE 1149.6
AC-coupled differential interconnections on very high speed (1+ Gbps) data paths are not testable using traditional IEEE 1149.1 techniques. The IEEE 1149.1 structures and methods are intended to test static (DC-coupled), single ended networks. IEEE 1149.6 is specifically designed for testing high speed differential, including AC coupled networks.

PCI Express Signalling/Connector Testing Support
JTAG Boundary-scan testing of PCIe connectors is pretty much out of the question. The PCIe differential signals are capacitively coupled so the boundary-scan devices on both sides of the PCIe connector would have to have some kind of dot6 compliant cells to test through the series capacitor. All of the boundary-scan compatible chips with PCIe interfaces that I saw had the PCIe signals specified as linkage bits so they wouldn't be testable anyway. If the customer has a specific device that needs to be tested we can look at the bsdl file to see if anything can be done.
We may be able to run software on the chips on both sides of the PCIe connector and test the link functionally (note that the link speed is 2.5Gb/s!!!).

Questions about JTAG Boundary Scan?

2008-11-18T16:42:00.001-08:00

JTAG: What topics interest you or would you like to read about? Comments?

IEEE Standard

2008-11-12T08:59:00.000-08:00

You can obtain a copy of the IEEE standard from http://www.ieee.org/.

The IEEE Std 1149.1-1990 - Test Access Port and Boundary-Scan Architecture, and the Std 1149.1-1994b - Supplement to IEEE Std 1149.1-1990, are available from:

IEEE Inc., 345 East 47th Street, New York, NY 10017, USA

1-800-678-IEEE (USA)

1-908-981-9667 (Outside of USA)

Applying JTAG

2008-11-10T09:18:00.000-08:00

Applying JTAG for Field Service

Once a product ships, the role of JTAG does not end. Periodic software and hardware updates can be performed remotely using the JTAG chain as a non-intrusive access mechanism. This allows Flash ROM updates and reprogramming of programmable logic for example. Service centers that normally would not want to invest in special support equipment to support a product, now have an option of using a standard PC or lap-top for JTAG testing. A simple PC based JTAG controller can be used for all of the above tasks and also double as a fault diagnostic system, using the exact same test vectors that were developed during the design and production phase. This concept can be taken one step further by allowing an embedded processor access to the JTAG chain. This allows diagnostics and fault isolation to be performed by the embedded processor. The same diagnostic routines can be run as part of a power-on self-test procedure.

JTAG for Production Test

2008-11-07T12:27:00.000-08:00

Applying JTAG for Production Test

Production test, utilizing traditional In-Circuit Testers that do not have JTAG features installed, experience similar problems that the product developer had and more:

Loss of Physical Access to fine pitch components such as SMTs and BGAs reduces Bed-of-Nails In-Circuit Testers (ICT) fault isolation.
Development of test fixtures for ICTs has become longer and more expensive.
Development of test procedures for ICTs has become longer and more expensive due to more complex Ics.
Designer is forced to bring out a large number of test points, which is in direct conflict with his goals to miniaturize the design.
In-system programming is inherently slow, inefficient, and expensive if done with an ICT.
Assembling boards with BGAs is difficult and subject to numerous defects such as solder smearing.

Figure 7 shows a typical production flow configuration that includes a JTAG tester that tests all the interconnects between the UUT digital components and performs in-circuit programming of all the CPLDs and Flash memories. Some test engineers complement the JTAG test with an ICT that requires simpler fixture primarily testing the analog components.

Figure 7 - Typical Production Flow Configuration

Following the ICT analog tests, a comprehensive at-speed functional test is performed before the product is shipped. However, in many cases, test engineers are skipping the ICT test and moving from JTAG interconnect test to a functional test that includes thorough testing of the analog portion of the product.

The following are major benefits in using JTAG test and ISP in production:

No need for test fixtures.
Integrates product development, production test, and device programming in one tool/system.
Engineering test and programming data is reused in Production.
Fast test procedure development.
Preproduction testing can start the next day when prototype is released to production.
Dramatically reduces inventory management – no pre-programmed parts eliminates device handling and ESD damage.
Eliminates or reduces ICT usage time – programming and screening.

Production test is an obvious area in which the use of JTAG yields tremendous returns. Automatic test program generation and fault diagnostics using JTAG software products and the lack of expensive fixturing requirements can make the entire test process very economical. For products that contain edge connectors and digital interfaces that are not visible from the JTAG chain, JTAG vendors offer a family of JTAG controllable I/Os that provide a low cost alternative to expensive digital pin electronics.

JTAG Tools

2008-11-06T14:31:00.000-08:00

Why are JTAG Tools needed?

In the previous paragraph we listed all the benefits that a designer enjoys when using boundary-scan in his product development. In this section we will describe the tools and design data needed to develop JTAG test procedures and patterns for in-circuit programming. We will use a typical board as an illustration for the various JTAG test functions needed. A block diagram of such a board is depicted in Figure 4.

Figure 4 - Typical Board with JTAG Components

A typical digital board with JTAG devices includes the following main components:

Various JTAG components such as CPLDs, FPGAs, Processors, etc., chained together via the boundary-scan path.
Non-JTAG components (clusters).
Various types of memory devices.
Flash Memory components.
Transparent components such as series resistors or buffers.

The following will introduce you to the major components of the various JTAG test tools available followed by a description of how to test and program the above board.

A typical boundary-scan test system is comprised of two basic elements: Test Program Generation and Test Execution. Generally the Test Program Generator (TPG) requires the netlist of the Unit Under Test (UUT) and the BSDL files of the JTAG components. The TPG automatically generates test patterns that allow fault detection and isolation for all JTAG testable nets of the printed circuit board (PCB). The TPG also creates test vectors to detect faults on the pins of non-scannable components such as clusters and memories that are surrounded by scannable devices.

Corelis TPGs also provide the user with a test coverage report, that allows the user to focus on the non-testable nets and determine what additional means are needed to increase the test coverage.

Test programs are generated in seconds. For example when Corelis ScanPlusExpressTPG was used, it took a 200MHz Pentium PC eight (8) seconds to generate an interconnect test for a UUT with 4,090 nets (with17,500 pins). This generation time includes netlist and all other input files processing, as well as test pattern file generation.

The test execution tool provides means for executing JTAG tests and perform in-circuit-programming in a pre-planned specific order called a test plan. Test vectors files, which have been generated using the TPG, are automatically applied to the UUT and the results are compared to the expected values. In case of a detected fault, the system diagnoses the fault and lists the failures as depicted in Figure 6. Different test plans may be constructed for different UUTs. Tests within a test plan may be re-ordered, enabled or disabled, and unlimited different tests can be combined into a test plan. Corelis test execution tool (ScanPlus Runner) also includes a test executive that is used to develop a test sequence or test plan from various independent sub tests. These sub tests can then be executed sequentially as many times as specified or continuously if desired. A sub test can also program CPLDs and Flash memories. For in-circuit programming other formats such as SVF, JAM, J-Drive and STAPL are also supported.

Figure 5 shows the ScanPlus Runner main window. As can be seen, ScanPlus Runner gives a user an overview of all test steps and the results of executed tests. These results are displayed both for individual tests as well as for the total test runs executed. ScanPlus Runner provides the ability to add or delete various test steps from a test plan, or re-arrange the order of the test steps in a plan. Tests can also be enabled or disabled, and the test execution can be stopped upon the failure of any particular test.

To test the board depicted in Figure 4, the user must execute a test plan that consists of various test steps as shown in Figure 5.

Figure 5 - ScanPlus Runner Main Window

The first and most important test is the scan-chain integrity test. The scan chain must work correctly prior to proceeding to other tests and in-system programming. Following a successful testing of the scan chain, the user can proceed to testing all the interconnects between the JTAG components. If the interconnect test fails, the ScanPlus Runner will display a diagnostic screen that will identify the type of the failure (such as stuck at, Bridge, Open) and will list the failing nets and pins as shown in Figure 6. Once the interconnect test passes, including the testing of transparent components, it makes sense to continue testing the clusters and the memory devices. At this stage the system is ready for in-circuit programming that usually is takes more time compared to the testing.

Figure 6 - ScanPlus Runner Diagnostics Display

During the design phase of a product, some JTAG vendors will provide design assistance in selecting JTAG compatible components, work with the developers to ensure that the proper BSDL (Boundary-scan Description Language) files are used, and provide advice in designing the product for testability.

Applying JTAG for Product Development

2008-11-05T15:25:00.001-08:00

Product Development

Recent marketing drive for reduced product size, such as portable phones and digital cameras, higher functional integration, faster clock rates, shorter product life-cycle with dramatically faster time to market, has created new technology trends. These new technology trends include increased device complexity, fine pitch components such as SMTs, MCMs, and BGAs, increased IC-pin count, and smaller PCB traces. This has created the following problems in product development:

Many boards include components that are assembled on both sides of the board. Most of the through-holes and traces are buried and inaccessible.
Loss of Physical Access to fine pitch components such as SMTs and BGAs makes it difficult to probe the pins and distinguish between manufacturing and design problems.
A prototype assembly is usually done by a small prototype assembly shop, in rush, with lower quality control as compared to a production house. A prototype generally will include more assembly defects than a production unit.
When the prototype arrives, a test fixture for the In-Circuit- Tester (ICT) is not available and therefore manufacturing defects can not be easily detected and isolated.
Small-size products do not have test points which makes it difficult or impossible to probe suspected nodes.
Many Complex Programmable Logic Devices (CPLDs) and Flash devices (in BGA packages) are not socketed and are soldered directly to the board.
Every time an engineer selects a new processor or a different flash device, he has to learn from scratch how to program the Flash memory
When a design includes CPLDs from different vendors, the engineer must use different in-circuit programmers to program the CPLDs.

JTAG technology is the only cost effective solution that can deal with the above problems. In the last few years, the number of devices that include JTAG has grown exponentially. Almost every new microprocessor that is being introduced includes JTAG circuitry for testing and in-circuit emulation. Most of the CPLDs and FPGAs manufacturers such as Altera, Lattice, and Xilinx, to mention a few, have incorporated JTAG logic into their components including additional circuitry that uses the JTAG 4-wire interface to program their devices in-system.

As the acceptance of JTAG as the main technology for interconnect testing and in-circuit programming has increased, the various JTAG test and in-system programming tools have matured as well. The increased number of JTAG components and mature JTAG tools, as well as other factors that will be described later, provide engineers with the following benefits:

Easy to implement Design For Testability (DFT) Rules. A list of basic DFT rules is provided later in this article.
Testability report prior to PCB layout enhances DFT.
Find packaging problems prior to PCB layout.
Little need for test points.
No need for test fixtures.
More control over the test process.
Quickly diagnose (with high resolution) interconnect problems without writing any functional test code.
Program code in flash devices.
Put design configuration data into CPLDs.
JTAG emulation and source-level debugging.

The Digital Electronics Blog

2008-11-01T09:44:00.000-07:00

Visit http://digitalelectronics.blogspot.com/ to find out information on upcoming electronics design conferences hosting organizations and agencies like IEEE, ACM, EDA, Joint Test Action Group, and more.

Digital Electronics Blog also provides information on new electronics technologies and career opening in the electronics industry. They provide a weblog about digital electronics, with industry news and short tutorials on VHDL , Verilog, timing and low power design, among other topics.

JTAG Applications

2008-10-31T15:29:00.001-07:00

Where can JTAG be applied?While it is obvious that JTAG based testing can be used in the production phase of a product, new developments and applications of the IEEE-1149.1 standard have enabled the use of JTAG in many other product life cycle phases. Specifically, JTAG technology is now applied to product design, prototype debugging and field service as depicted in Figure 3. This means the cost of the JTAG tools can be amortized over the entire product life cycle, not just the production phase.

Figure 3 - Product Life Cycle Support

What is JTAG

2008-10-29T10:49:00.000-07:00

JTAG

JTAG (also known as boundary-scan) has enjoyed growing popularity for board level manufacturing test applications since its introduction as an industry standard in 1990. JTAG has rapidly become the technology of choice for building reliable high technology electronic products with a high degree of testability. Due to the low-cost and IC level access capabilities of JTAG, its use has expanded beyond traditional board test applications into product design and service.

This overview provides a brief overview of the JTAG architecture and the new technology trends that make using JTAG essential for dramatically reducing development and production costs. The article also describes the various uses of JTAG and its application.

JTAG, as defined by the IEEE Std. 1149.1 standard, is an integrated method for testing interconnects on printed circuit boards that is implemented at the IC level. The inability to test highly complex and dense printed circuit boards using traditional in-circuit testers and bed of nail fixtures was already evident in the mid eighties. Due to physical space constraints and loss of physical access to fine pitch components and BGA devices, fixturing cost increased dramatically while fixture reliability decreased at the same time.

In the 1980s, the Joint Test Action Group (JTAG) developed a specification for JTAG testing that was standardized in 1990 as the IEEE Std. 1149.1-1990. In 1993 a new revision to the IEEE Std. 1149.1 standard was introduced (titled 1149.1a) and it contained many clarifications, corrections, and enhancements. In 1994, a supplement that contains a description of the boundary-scan Description Language (BSDL) was added to the standard. Since that time, this standard has been adopted by major electronics companies all over the world. Applications are found in high volume, high-end consumer products, telecommunication products, defense systems, computers, peripherals, and avionics. Now, due to its economic advantages, smaller companies that cannot afford expensive in-circuit testers are using JTAG.

The boundary-scan test architecture provides a means to test interconnects between integrated circuits on a board without using physical test probes. It adds a boundary-scan cell that includes a multiplexer and latches, to each pin on the device. Boundary-scan cells in a device can capture data from pin or core logic signals, or force data onto pins. Captured data is serially shifted out and externally compared to the expected results. Forced test data is serially shifted into the boundary-scan cells. All of this is controlled from a serial data path called the scan path or scan chain. Figure 1 depicts the main elements of a JTAG device. By allowing direct access to nets, JTAG eliminates the need for large number of test vectors, which are normally needed to properly initialize sequential logic. Tens or hundreds of vectors may do the job that had previously required thousands of vectors. Potential benefits realized from the use of JTAG are shorter test times, higher test coverage, increased diagnostic capability and lower capital equipment cost.

Figure 1 - Main Elements of a JTAG Device

The principles of interconnect test using JTAG are illustrated in Figure 2. Figure 2 depicts two JTAG compliant devices, U1 and U2 that are connected with four nets. U1 includes four outputs that are driving the four inputs of U2 with various values. In this case we will assume that that the circuit includes two faults: A short between Nets 2 and 3, and an open on Net 4. We will also assume that a short between two nets behaves as a wired-AND and an open is sensed as logic 1. To detect and isolate the above defects, the tester is shifting into the U1 boundary-scan register the patterns shown in Figure 2 and applying these patterns to the inputs of U2. The inputs values of U2 boundary-scan register are shifted out and compared to the expected results. In this case the results (marked in red) on Nets 2, 3, and 4, do not match the expected values and therefore the tester detects the faults on Nets 2, 3, and 4.

JTAG tool vendors provide various types of stimulus and sophisticated algorithms to not only detect the failing nets but also isolate the faults to a specific nets, devices, and pin numbers.

Figure 2 - Interconnect Test Example

Obtaining the IEEE-1149.1 Standard

2008-10-29T10:33:00.000-07:00

The IEEE Std 1149.1-1990 - Test Access Port and Boundary-Scan Architecture, and the Std 1149.1-1994b - Supplement to IEEE Std 1149.1-1990, are available from:

IEEE Inc., 345 East 47th Street, New York, NY 10017, USA

1-800-678-IEEE (USA)

1-908-981-9667 (Outside of USA)

You can also obtain a copy of the standard from http://www.ieee.org.