For many the term ‘JTAG’ is still a point of confusion, as well it might since, for some engineers, it is a programming port whilst for others it is there to plug-in an emulator or debugger. In fact it was devised for neither of these purposes.
The acronym JTAG is actually short for the Joint Test Action Group and its initial aims were just that, to provide an aid to circuit board testing.
The ‘group’ met over a period of some five years, from 1985 to 1990, all the time devising and then finalising a scheme to embed test circuitry into digital devices to assist in the structural test of the PCBs onto which they would be placed. So far, so good.
Since then the structure of JTAG as a test port has been well documented and understood. It has been a recognised IEEE standard (reference 1149.1) since 1990 and many articles have been published extolling the virtues of the system as a fault-finding tool, especially when harnessed to one of the growing number of test software systems available in the market.
In the meantime, a number of alternative uses for ‘JTAG‘ have been developed, such as its use for debugging and programming. The ‘hi-jacking’ of the JTAG port for debugging goes way back to the early 90s when TI and the fledgling ARM Ltd. figured that this neat bundle of wires and a state-machine could help them access internal (debug) registers, in addition to the IEEE Std. 1149.1 test registers defined by JTAG committee.
At this point it might have been useful for someone to think up their own name for the system deployed but that was not to be, so, along with ‘JTAG for test’, we also have ‘JTAG for debug’, although the latter is not defined by the IEEE standard. To confuse matters a little further, in 1993 Intel introduced a range of PLDs (soon to be sold to Altera in order to compete with the then market leader AMD) that were among the first to utilise the JTAG mechanism for directly accessing configuration registers.
So there you have it, within three years of its formal launch the JTAG committee’s test port had spawned two other prolific applications: RISC/DSP processor debug and device on- board programming (OBP). In the remainder of this article we will examine how device OBP has developed over the past few years and how it can add value to the manufacturing process.
Programming PLDs Using JTAG Directly
In 1994, when we introduced our first vendor-independent OBP software, only a few CPLDs from AMD (later Vantis) and Intel used JTAG as a programming port. Lattice Semiconductor was still using its cut-down in-system programming (ISP) protocol devices and had yet to migrate to the full JTAG state machine. Hence, there were no software standards, and for many years arguments ensued about whose system performed best.
As other companies (for example, Altera, Actel, Cypress and Xilinx) added JTAG ports for programming, standards abounded until some vendors adopted the long-winded but simple SVF (serial vector format ) originally devised by TI, Tektronix and Teradyne for test vector description.
Along the way, IC vendors vaunted numerous systems as the next ‘standard’ in OBP, and readers may remember "XSVF" from Xilinx and "VirtualMachine" from Lattice. However, nothing really superseded SVF.
IEEE Std 1532 – Harmonised Programming for PLDs
Initially Altera proposed its JAM and then (latterly) its ‘standard’ programming language (STAPL) formats as new standards, but as you might imagine this was not well received by its competitors. It was not until IEEE banged some heads together however that the principal IC vendors started working not only together but also with tool vendors to form a working party for a harmonised programming system for CPLDs and other devices.
In 1998, the IEEE 1532 working party began to create a formal extension to the original boundary-scan standard IEEE 1149.1. The new ISC (In-System Configuration) format, as it was to become known, built on the BSDL (Boundary-Scan Description Language) device model format with additional standard instructions and associated registers.
Device specific ‘procedures’ and ‘flows’ built-in to every 1532-BSDL model would allow high-level software tools to parse the information needed to offer hardware independent programming. Coupled with the newly defined ISC data format the new standard offered previously unseen possibilities such as: concurrent programming of devices from different vendors, and (in some cases) vendor-by-vendor device substitution.
Actel, Altera, Atmel, Cypress, Lattice and Xilinx now all offer 1532-compliant PLDs within their ranges at little or no additional cost, and JTAG ProVision from JTAG Technologies includes a standard feature for concurrent programming of IEEE 1532 devices across all vendors.
Flash and SPROM Programming
CPLDs and variants can be programmed quickly by directly accessing control registers within the part. But what of discrete flash parts and serial PROMs?
Provided that the device is fully connected to a boundary-scan compliant device it can often be programmed ‘indirectly’ by simulating memory writes and reads using the boundary-scan register.
By adding additional signals to your design the overhead of shifting data serially then latching parallel onto the ‘programming device’ pins is diminished and the throughput increased. Even serial comms protocols such as I2C and SPI bus can be supported using this technique, making JTAG/Boundary-scan an extremely viable technique for small (less than 1Mbyte ) to medium (between 1 and 32Mbyte) sized flash blocks.
If it is also possible to influence IC designs then special OBP short chains can be implemented in the silicon to further reduce the serial shift overhead. These short chains target only the boundary-scan cells needed to program the target device and can affect up to 10x speed increases in programming times. If an FPGA is used as the programming part then a pseudo BSR(Boundary-Scan Register) scan chain can be temporarily configured for the flash programming step and then erased and reprogrammed with ‘mission code’ for functional testing.
Special Devices
To further add to the value offered by the JTAG interface, a special projects group worked on a number of mixed technology parts such as microprocessors with embedded flash that can be programmed using JTAG/boundary-scan. Although these devices may deviate from the ‘true’ IEEE 1149.1 standard, JTAG has been proven to be an effective means of on-board programming.
One example of a non-standard interface can be observed within the STMicro’s (formerly WSI) µPSD series of microcontrollers. In this instance the devices features the correct TAP pins but a state machine which is non-IEEE 1149.1 compliant.
The popular TI MSP 430 series is another part which ostensibly features JTAG but has no boundary-scan register to enable testing and a non-standard arrangement which involve multiplexing an additional clock signal onto the TDI pin.
Other supported vendors include Freescale with the MPC5500 series of automotive aligned microcontrollers with embedded flash.
The JTAG committee’s boundary-scan test access port (TAP) started out in life almost 20 years ago as a facility for production/test engineers to aid in fault-finding on PCBs which were increasingly using surface mount devices.
Since then applications for this versatile port have grown and the value to both design and test engineers has increased. Whilst designers can enjoy cheap and easy access to the debug registers of their microprocessor, test and production engineers can get a low-cost versatile on-board device programmer coupled to their structural tester right at the point of assembly. This reduces the costs not only for handling but also for pre-programming, possible reprogramming, and the storage of pre-programmed parts.
James Stanbridge is sales manager UK for JTAG Technologies.