Part 1: The ‘Why’ of IJTAG Development
Since the IEEE 1687 Internal JTAG (IJTAG) standard was formally accepted by the IEEE on November 3, 2014, all of us on the IJTAG working group, as cohorts in our little conspiracy, have received congratulations from many of our peers for finally finishing this effort. (Thank you for that!). However, the number one question I am asked is: “What are you going to do now that you have all this free time?” (Ha ha!)
I could give a short, quick answer, but it probably wouldn’t mean much to anyone who isn’t intimately familiar with the IJTAG standard and the effort that went into its realization. Instead, a little history on why the standard was developed in the first place would be in order and then a quick review of some of the really powerful features of IJTAG would definitely be beneficial before we end up talking about where IJTAG could go from here. Unfortunately, all of that is just too much for one blog; so, this is the first installment of a three-blog series on IJTAG. Watch this space for the next installment.
Why was IJTAG developed in the first place?
To begin with, the reason we started the IEEE 1687 IJTAG effort was because many of us were already dealing with problems involving embedded instruments. And, at the same time, another group of us had investigated the IEEE 1149.1 JTAG standard, which at the time was the de facto access method for instruments embedded in chips. This group anticipated that there would be growth and scalability issues with JTAG. As it was back then, JTAG was a bit too rigid and not efficiently scalable. It would be woefully inadequate for the future of embedded instrumentation.
From our observations of the industry, we saw:
- more cores and embedded intellectual property (IP) were being developed by a widely disparate and growing supply network;
- more BIST-type functions such as serdes BIST, memory BIST, PLL BIST, logic BIST, scan compression, DDR BIST and others were internalizing testing inside chips to reduce the cost and complexity of test;
- more debugging functions, and environmental and process monitoring functions were being included within chips to reduce time-to-diagnosis and time-to-yield;
- engineers needed to be enabled with greater freedom to make certain design tradeoffs, involving silicon area, route congestion, power consumption, timing impact and others;
- engineers needed to be able to implement operational tradeoffs involving test/instrument scheduling, access length, access time, power budgeting and others;
- allowances were needed for additional embedded Test Access Ports (TAP) and TAP controllers in designs for timing purposes or because TAPs were being integrated into IP cores;
- embedded instruments to test, debug, monitor and configure power and clock domains were needed;
- management techniques were needed for longer scan paths;
- additional mechanisms besides JTAG were needed to access embedded content in chips because many devices do not have JTAG, but they do have SPI, I2C and other interfaces for test, debug and configuration.
So, the IEEE 1687 IJTAG working group set out to create another standard for embedded instrumentation that would take advantage of the serial scan access mechanisms embodied in the IEEE 1149.1 and IEEE 1500 standards, which use capture-shift-update operations in accordance with the JTAG finite state machine protocol. Our goal was to address all of the growing pains I’ve listed above. 
Another of our goals for IJTAG was to make embedded instruments portable and reusable. The IEEE 1687 IJTAG development process handled some of the items on the above list with architectural allowances embodied in the IEEE 1687 IJTAG network of embedded instruments, and others by developing two languages, an architectural description language (Instrument Connectivity Language or ICL) and a procedure/vector description language (Procedure Description Language or PDL).
That’s a quick history of the ‘why’ behind the development of IJTAG. Now, you’re probably wondering what’s actually in the standard. I’ll mention some of the highpoints in my next blog in this series and relate the standard back to these growing pains. In the meantime, if you’d like to do some reading on the approved standard document, we’ve developed a second edition of our IJTAG Tutorial. I believe it’s the only IJTAG Tutorial that’s up to date and based on the approved standard. You can download it here.
One more thing. If you’re anxious to get started with IJTAG, ASSET and Mentor Graphics have collaborated to develop an in-depth technical workshop, which has been scheduled for multiple cities and countries beginning February 2015. Check it out here.
Watch for my next blog: “IJTAG features you don’t want to miss.”
