Part 2 in a three-part series on IJTAG
In my previous blog, "IJTAG: It's all about Embedded Instruments", I discussed why the IEEE 1687 IJTAG standard was developed in the first place. The bottom line was that a standard was needed because embedded instrumentation had been experiencing an increasing list of growing pains, which brought the issue of scalability to the fore. In this blog, I’m going to explain from my perspective as vice chairman of the IJTAG working group how the approved standard addresses those growing pains with some really powerful features, which, if you did a fast read of the standard, you might not think twice about. These are some of the ‘can’t-miss’ features of IJTAG.
One of the critical features of IJTAG is a simple thing called a Segment Insertion Bit (SIB). The working group developed the SIB concept because it addresses a number of the concerns we had, namely: managing long scan paths, accommodating power and clock domains, and allowing many of the operational and engineering tradeoffs we wanted to enable. The SIB is a method that allows a scan chain to include in-line bypass bits that could lengthen or shorten the scan chain. When closed, which effectively makes a segment of the IJTAG network inaccessible, a SIB allows the instruments on this network segment to continue to operate instead of forcing the JTAG finite state machine (FSM) to sit in the run-test-idle (RTI) state. (Remember that JTAG is the current access mechanism for IJTAG, so I’ll be referring to a lot of JTAG concepts.) While a closed SIB blocks access to the JTAG Test Data Registers (TDR) on the embedded instruments behind the SIB, it does not affect the JTAG capture-shift-update operation, which is the access mechanism for the IJTAG network, from taking place on other segments of the scan chain. A closed SIB would freeze or, technically speaking, become persistent, which would allow any active instrument that is gated by the SIB to continue running (and those not running to remain quiescent).
The SIB was also our first step toward allowing concurrent operation. For example, an engineer might open 10 SIBs, start 10 instruments sequestered behind these SIBS and then close the 10 SIBs. The 10 instruments would continue to run while the engineer was using the rest of the scan chain or IJTAG network to do other things. A SIB could also segregate or isolate a TDR and its instrument in a low power area from the active clock/power domain. The alternative would be to force the entire clock/power domain to be active all the time so that the scan path would not be broken. In summary, opening and closing SIBs on the active scan path allows the following: direct management of the scan length, low-power clock and power domains to remain off while the rest of the scan chain operates, and instruments to continue to operate while the rest of the scan path is being used.
A SIB generates a local Select signal so that an Instruction Decode that would normally be performed centrally in the device’s JTAG Test Access Port (TAP) Controller can now be performed near the SIB that is local to the instrument. (This is possible as long as JTAG’s ShiftEn, CaptureEn, and UpdateEn signals are routed as generic clock-like signals.) This feature allows engineering tradeoffs involving silicon area, wire routing, routing congestion, signal timing and power consumption to be addressed.
Including these SIB capabilities in the IJTAG standard meant some additional work for the committee. We had to invent IJTAG’s Instrument Connectivity Language (ICL) to describe a variable length scan path and to give engineers the ability to nest variable length scan paths. The result was a hierarchical architecture of scan paths where the various levels in the architecture are gated by SIBs. For example, one SIB might open and provide access to additional SIBs and behind these SIBs there might be another series of SIBs. To accomplish this, the working group had to violate a basic tenet of the JTAG standard, which requires that instructions and data are treated separately. IJTAG departs from JTAG in this regard because a SIB is actually an in-line embedded scan path instruction bit that configures the scan path during a JTAG data scan (DR-Scan) and not an instruction scan (IR-Scan). ICL was the first step in instrument and network re-use.
Another goal of the IJTAG committee was to ensure the portability and re-use of embedded instruments. Several key features of the IEEE 1687 IJTAG standard helped us achieve this goal. A plug-and-play interface to the on-chip IJTAG network allows the re-use of not only the embedded instruments themselves, but also of entire segments of an IJTAG serial access network that could be made up of multiple instruments. And another IJTAG language, Procedure Description Language (PDL), ensured the portability of the procedures or processes that operate an instrument. PDL means that when an instrument moves from one design to the next, its operating procedures go right along with it without modification. You can imagine what a time-saver this feature is. In addition, this comprehensive approach to embedded instrumentation portability solves a critical problem of portable IP delivery. If the IP doesn’t seem to work, an IP provider will always first ask whether anything had been modified. If the answer is yes, then the IP provider will not support it. IJTAG removes many of the reasons why modifications took place in the past, thereby ensuring support for as much IP as possible.
After developing the concept of a SIB and defining its operational rules, the working group turned its attention to defining architectures that included multiple embedded TAPs (eTAP). The IJTAG rules for eTAPs parrot the SIB rules. For example, when an eTAP is deselected, it is effectively frozen. When awakened again, the eTAP synchronizes with the device’s primary TAP. Of course, there’s a lot more to it than this brief description, but the long and short of it is rudimentary synchronized concurrent operations for eTAPs has been enabled in the IJTAG standard. The working group realized that the issue of synchronized concurrent operation is larger than what was addressed in the initial version of the standard, but we had to start somewhere. A limited amount of concurrent operation handling can be accomplished with IJTAG’s iTake and iRelease resource schemes. (iTake and iRelease are PDL commands.)
At this point, what can be said is that an on-chip architecture with multiple TAPs resembles a scaled-down and internalized version of a printed circuit board design featuring multiple scan path linkers. Approached from this perspective, you can see that some fairly straightforward architectures with various configurations of eTAPs can be easily described with ICL. To facilitate multiple eTAPs, the working group added the embedded TMS (eTMS) signal to the standard IJTAG plug-and-play network interface. (TMS refers to JTAG’s Test Mode Select signal.)
Multiple eTAPS and synchronous concurrence also relates to the topic of what may be added to the IEEE 1687 IJTAG standard in the future, which will be the subject of my next blog in this series. Basically, the IJTAG working group also realized that in many chip designs, some or all of the embedded IP would be accessed and operated by some other technology besides IEEE 1149.1 JTAG with its TAP and TAP Controller. 
For example, instead of a TAP, the device might have another interface for accessing embedded IP, such as SPI, I2C or ARM’s AXI bus. The IEEE 1687 IJTAG standard does not mandate or specify an IJTAG controller to drive the on-chip network of embedded instruments, but it does make allowances that enable the use of an embedded IEEE 1149.1 JTAG TAP and TAP Controller. Because of this, the IJTAG standard needed a descriptive construct to enable alternative controllers besides the JTAG TAP. The solution for the current version of IEEE 1687 IJTAG was to define a standardized descriptive device in ICL. This became IJTAG’s AccessLink.
Obviously, I’m just scratching the surface on these features and only mentioning some of the more prominent capabilities of IJTAG. For an in-depth look at these and the rest of the IJTAG standard, you could download the second edition of our IJTAG Tutorial.
And, if you’re interested in some hands-on instruction, ASSET is teaming up with Mentor Graphics beginning in February to offer an in-depth technical workshop on the standard in multiple city and countries. Check it out here.
The last blog in this series will look at the future of IJTAG. Check back for a discussion of “Extending the Value of the IJTAG Standard.”
