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.