feature article
Subscribe Now

Not Your Father’s JTAG

Before we start – a little word association test. What is the first thing that comes into your mind when I say JTAG? If you think of boundary scan and board testing – you are a hardware engineer. If you think of debugging, in circuit emulation, and programming flash memory – you are probably a software engineer.  But if you think of both at the same time, you are probably an embedded engineering super-hero running a dual-core mind. (And if you are saying J-What, read on for an introduction to some of the trends in debugging and testing in the age of high speed processors and high speed serial communication.)

JTAG as an idea goes back to the long lost world of the 1980s. In those dark ages, printed circuit boards were tested on beds of nails – probes that tracked the progress of signals between chips as the board was exercised. Other tests were conducted by attaching clips to the pins of the package. As ball grid arrays replaced physical pins and circuit boards became multi-layered, dense, and double-sided, it was recognised that there was a need for a different approach. The industry got together in the Joint Test Action Group (JTAG) to create what became IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture. (As an aside, it is interesting how some standards get referred to by numbers and others are always known by a name.)

The approach decided on was to create a small cell on the input and output pins of every device. These are connected in a daisy chain to each other and to the Test Access Port (TAP – often also called the JTAG port.). This is a controller with an extra four (sometimes five) pins on the device. TAPs are themselves daisy chained to the TAPs on other devices on the board and to an external connector. The cells, normally transparent to signals, are turned on for testing. Under external control, it is possible to confirm that devices are connected together correctly and that the connections are functioning correctly. An extension to the standard defines the Boundary Scan Description Language (BSDL), which is used to run the tests, normally under the control of a PC communicating through a low-cost pod.

Given that the TAP provides connectivity to a chip, processor designers seized on this as a way of providing information that would help in debugging software and in programming flash memory and other useful things. Low cost JTAG probes allow software developers to step though programmes, set breakpoints to discover the state of registers at a particular point, or even to download stored information on programme behaviour for analysis.

JTAG has worked well for over twenty years, but there are now further technical advances that make new steps forward necessary. One of these is the use of high-speed communications, running at gigabits/second. These are essentially AC-coupled connections, normally using SerDes (Serialiser-Deserialiser) technology at each end of the connection, and they require different test methods from the earlier DC-coupled connections. To help resolve this, IEEE 1149.6 Boundary-Scan Testing of Advanced Digital Networks was released in 2003. This is gradually being adopted by chip manufacturers and supported by the test equipment world.

Another standard, IEEE 1149.7, Reduced-pin and Enhanced-functionality Test Access Port and Boundary Scan Architecture, is designed as a superset of 1149.1, needing fewer pins (normally two) and increased functionality aimed at supporting new device technologies, such as multi-core chips, and 3D approaches, like stacked die using through-silicon vias for communication.

Some manufacturers have developed Built-In Self Test (BIST), where the device essentially runs test patterns on its own operations, using the JTAG TAP to export test results. This approach, of instrumenting the device rather than applying instruments to the device, has sparked the idea of embedded instrumentation: building test equipment into the chip and running the tests through the JTAG port. Traditional oscilloscopes, logic analysers, bus analysers and other test systems are running into severe problems with high-speed serial busses. Just putting a probe onto a bus is going to alter the behaviour of the bus, through the probe’s own capacitance. Connectorless probes are available, costing $3,000 and upwards – and that is just for the probes.

IP for embedded instrumentation is being developed in different ways by IC manufacturers, including FPGA companies and EDA companies. An example of what is being developed is Xilinx’s ChipScope. An FPGA developer can use it to build in logic analyser, system analyser, and virtual I/O low-profile software cores, and can then examine internal signals and nodes, including either soft or hard implementations of processors. The IC vendors and the EDA people generally see embedded instrumentation as a supplement to the automated test equipment (ATE) that they deploy. Particularly at 90 nm process nodes and below, ATE equipment is hugely expensive and testing is extremely time consuming, both in preparing the tests and in actually running them. Generally they are not thinking about the developer using the device.

However, embedded instrumentation is going to be useful to the system developers, both hardware and software, in looking at the behaviour of specific devices. And the availability of these features is going to form an increasing role in the specification and selection of processors in particular. Today, builders of ARM-based devices are selective in which of the diagnostic tools that are available within the ARM cores they actually implement. This may save a few cents on production costs by omitting some of them, but it may also make the work of the system developer more complex. This same thinking may influence the implementation of embedded instrumentation.

Having embedded instruments will be valuable beyond system development. Since the instruments are still there when the chip is in a product in field service, they can be used by the support team. Dragging expensive test equipment from the lab to a working environment is not all that easy or desirable, but the embedded instruments can be used with a laptop and an appropriate JTAG interface module.

Since the different people involved are starting from different perspectives, there is the scope for still more standards. Work at the moment is going forward on IEEE P1687 IJTAG (Internal JTAG), and the statement of scope reads:

“This standard will develop a methodology for access to embedded test and debug features, (but not 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.”

So all they are standardising here is the communications; what the instrumentation will do and how it will work is left to the device designer.

So far the developments in this area have been driven largely by the needs of device manufacturers to test their chips. But the companies providing tools for system developers to exploit the insights that JTAG can give into the behaviour of devices and the software running on them are continuing to find ways to make them more useable and powerful.  ASSET InterTech, for example, which I used to refer to as the Texas based JTAG company, no longer fits that description. They now describe themselves as “driving embedded instrumentation,” and, when you visit their web site, it’s difficult to find the term JTAG – at least initially. Glenn Woppman, the President, Founder, and CEO, is a great evangelist, and he is determined to drive through flexibility in understanding systems based on the company’s ScanWorks platforms. Talking to Glenn provided one of those surreal moments that this industry sometimes comes up with. Instead of meeting in a high-tech office environment, we were in a three-hundred-year-old English pub with open fires burning large logs and brightly-polished old-fashioned hand-pulled beer engines dispensing different types of real ale, discussing the difficulties of measuring 10 gigabit serial signals. Glenn managed to drink his ale, eat his fish and chips and talk about the issues of eye patterns for high-speed serial links without turning a hair.

ASSET and other tools companies are pushing hard to make it less complicated to develop systems, even as the systems themselves become more complex.

One thought on “Not Your Father’s JTAG”

Leave a Reply

featured blogs
Aug 15, 2018
Yesterday was the first of two posts about Cadence Automotive Solutions. Today we go down into the details a bit more. However, there are so many details that this will be more of a map of the landscape so you get an idea of the breadth of our technology. Each item could have...
Aug 14, 2018
I worked at HP in Ft. Collins, Colorado back in the 1970s. It was a heady experience. We were designing and building early, pre-PC desktop computers and we owned the market back then. The division I worked for eventually migrated to 32-bit workstations, chased from the deskto...
Aug 14, 2018
Introducing the culmination of months of handwork and collaboration. The Hitchhikers Guide to PCB Design is a play off the original Douglas Adams novel and contains over 100 pages of contains......
Aug 9, 2018
In July we rolled out several new content updates to the website, as well as a brand new streamlined checkout experience. We also made some updates to the recently released FSE locator tool to make it far easier to find your local Samtec FSE. Here are the major web updates fo...
Jul 30, 2018
As discussed in part 1 of this blog post, each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store its configuration bits. The time required to pr...