Part 3 in a three-part series on IJTAG
This is my last of three blogs about: ‘why the IEEE 1687-2014 IJTAG standard?’ The series began by reviewing why IJTAG was developed, followed by a blog on how the growing pains surrounding embedded instruments drove the development of IJTAG’s powerful features, which were a response to the engineering needs that led to IJTAG’s development in the first place. I served as vice chairman of the IEEE 1687 IJTAG working group, so I was there when the group – the ‘founding fathers’ of IJTAG – griped about their problems and did some crystal ball predictions about the future and expected growing pains.
I suppose this is what happens whenever a new standard is being developed. You start by listing all of the capabilities you’d like to include in the document, but, in the end, you have to set priorities for the first release of the standard. (You have to draw the line on creeping elegance somewhere.) Once the standard is approved, you start thinking about what to put in the next version. That’s where we are today.
From our point of view at ASSET InterTech, one of our main concerns for the IJTAG standard is how to extend the value of the standard. IJTAG is a standard for instruments embedded in chips, many of which have been inserted to help characterize, test and validate the host device. These types of instruments will likely not be used beyond chip-level automatic test equipment (ATE). However, some embedded instruments will be re-used again after chip test when the IC has been placed on a circuit board. At that point, the instrument may be used in board validation, test and debug applications, as well as to debug system-level software and firmware. This is where the value of IJTAG can be extended by expanding in the future the types of technologies that will access on-chip IJTAG resources. Right now, this is limited to IEEE 1149.1 JTAG, but the IJTAG standard was developed so that other access methods might be accommodated in the future.
For example, some of the chips on many boards do not feature the IEEE 1149.1 JTAG Test Access Port (TAP). Instead of a TAP, these chips may support other interfaces such as SPI or I2C, while still others have no dedicated test port at all. Many devices like DRAM memories only feature a functional interface and that’s it. Some of these ICs may include embedded instruments which could be applied at the board level, and could benefit from the portability and documentation associated with the IEEE 1687 IJTAG standard.
If the intention is that the embedded instruments within certain ICs will only work independently or asynchronously to other instruments inside the IC or within other chips on the same board, then there is no need for concurrent synchronization. But if instruments need to be started at the same time, for example, or interact with each other through data transfers or simply synchronize their processes somehow, this can only be handled now in a limited way and only when the instruments are all accessible through an IEEE 1149.1 JTAG TAP. However, if some chips on a board have JTAG TAP interfaces, while others have SPI or I2C interfaces, then concurrent synchronization will probably be difficult, especially when multiple hardware sources are driving the different types of ports on the chips on the board.
As I mentioned in the first blog in this series, the IJTAG working group had many goals during the development of the first version of the standard. I showed in the second blog how most of these goals were achieved except one. Because of the complexity of the problem, an easy plug-and-play solution for the concurrent synchronization of embedded instruments was not fully implemented for circuit boards consisting of a mixture of chips, some with IEEE 1149.1 JTAG interfaces and others with another type of controller like I2C or SPI driving their embedded instruments.
Consider this: the IEEE 1687 IJTAG network is a serial scan path that is currently operated by the IEEE 1149.1 JTAG finite state machine protocol of Capture-Shift-Update. Interfacing this network to a SPI slave interface, which provides data and control to a particular chip’s embedded instruments, is not a simple task. It must be noted that a SPI slave is a selectable interface that would look very much like a selectable IJTAG eTAP. In that vein, there may be data staging, data packets and different sequencing involved with operating the network and delivering data to or extracting data from embedded instruments. Ultimately, there may need to be a method to synchronize IJTAG iReads and iWrites behind a SPI or I2C interface with iReads and iWrites behind the 1149.1 TAP controller.
So, to answer the question of what’s next for extending the value of the IJTAG standard, one promising pursuit would be to start an IEEE 1687.1 effort to define the rules, options, allowances and permissions involved with supporting alternative controller interfaces in an IJTAG on-chip network of embedded instruments. This work would need to define the following:
- A precise method for handling IJTAG’s AccessLink for alternative serial controllers such as SPI or I2C
- The conversion rules needed for alternative serial interfaces to directly drive an IJTAG network
- The rules or allowances for subordinating or nesting a JTAG eTAP controller under an alternative serial controller
- The rules or allowances for subordinating alternative controllers within a IEEE 1687 IJTAG network in a manner similar to an embedded TAP (that is, creating an eSPI or eI2C, for example)
- Extensions to ICL for describing the specific structures for including alternative controllers
- Extensions to PDL, if they are needed, to accommodate alternative controllers
- Extensions to PDL to enhance synchronized concurrent operation among embedded instruments within the same IC or in separate chips on the same board
As I mentioned in my previous blogs, we’ve published a second edition of our IJTAG Tutorial based on the approved specification.
If you haven’t read the previous blogs, haven’t registered yet or don’t know, we’re teaming up with Mentor Graphics on a series of half-day technical workshops on the standard. Come and join us.
