What’s driving the development of IJTAG

Q&A session with Al Crouch,
ASSET Chief Technologist
for Core Instruments

Q: How did the P1687 working group decide on the direction the standard development effort would take?

Al Crouch: Standards are developed to solve problems and when the 1687 working group first started talking about the problems it could address, we realized that we were facing a long list of issues.

One reason why we had such a long list was the composition of the working group. We had chip designers, board designers, chip and board test people, EDA tool developers, JTAG tool developers, and system designers. So, we did a survey of the marketplace mostly to determine the use cases for IJTAG and what capabilities in a standard would be most beneficial. Hands down, the topic that ranked the highest was vector re-use.

Q: What do you mean by re-use?

Al Crouch: If you look at the development process starting with chip development, you have verification, simulation and test development; and then chips move onto circuit board and eventually into systems, which are brought to market and deployed to users. Validation, test or debug vectors are needed at every step along the way. For example, let’s say that  a chip is being designed and a scan architecture or logic built-in self test (BIST) module on the chip must be verified. To do this, the chip designer must develop vectors  for simulation at the module level. Then, the design of the logic BIST is integrated into the overall design of the chip and more vectors are generated either by the designer or by the integrator to verify the logic BIST from the edge of the chip. Next, when silicon is available, it goes into test on automatic test equipment (ATE) and new vectors are generated or the chip’s verification vectors must go through a translation process to be used by the ATE. Then, when the chip is designed onto a circuit board, even more new vectors are developed to test the board and possibly to access the BIST logic within the chip, but in a different manner than ATE test access. Then, put the board or boards into a system and – you guessed it – more even more vectors are needed. All of these vectors are generated by different people with different environments and requirements, but ultimately, the same exact set of ones and zeros are placed in front of the control interface for the BIST. If we could find a way to just deliver and automate the use of those ones and zeros – regardless of the test environment – that’s what I mean by vector re-use.

Q: Where does IJTAG come in?

Al Crouch: Like other open industry standards, IJTAG or IEEE P1687 is an important building block. There is no other standard governing the access to any embedded test, debug, or functional configuration logic in all environments; this includes ATE test interfaces, debug logic interfaces and yield-logic interfaces. They are all unique and different. This doesn’t engender re-use. With the complexity and amount of integration of logic today, the way manufacturing problems have become parametric rather than stuck-at, and with the aggressive time-to-market requirements placed on most chips, boards, and systems – the ability to directly access logic at the module level in all environments and throughout the life-cycle would be a major time, effort and cost savings.

Q: How will 1687 help?

First you have the standard and then you start to get tools that not only support the standard, but also do a lot of other functions too, depending on the creativity and innovation of the tools supplier. The first step is the standard. An integral part of 1687 will be a modeling capability based on some sort of descriptive language. In 1687 this is called the Hardware Description Language (HDL) and it is used to define an embedded logic unit or an “instrument.” Then some standardized vector format needs to be linked to the HDL. For 1687 this is Protocol Description Language (PDL). When vectors are originated with this type of methodology, you’ll be able to re-target them to any format. This works because tools will understand the access mechanism and will be able to do the math to resolve the “instrument vectors” out to any boundary, core, chip, board, or system.

So, if you need vectors today for ATE at the chip-level, you output the HDL-based vectors for ATE. Tomorrow, it could be some other format, but there’s no more re-developing and re-generating vectors at each step along the way – it becomes an algorithmic process.

Q: Are there other needs that 1687 will address?

Al Crouch: There are several things, but one of the big ones I refer to as the Tower of Babel problem. This comes about because we’re seeing that more and more instrumentation is being embedded into intellectual property (IP) cores. Then, designers combine several cores into a silicon chip. Right there you’ve got the potential to generate a lot of data from that silicon. Now we’re seeing multiple chips and cores and embedded logics – in some cases 30 or 40 processors and memories – on complex die and stacked in a single package. You can literally end up with thousands of embedded instruments generating data that needs to be organized in a database where data mining can be done on it. IJTAG is one method that will help extract and organize that data so it can be analyzed to determine what’s going on in cores, chips, multi-chip packages, circuit boards and systems.

Q: With all those embedded instruments on-chip, does access become a problem?

Al Crouch: Yes, it definitely does, but not necessarily because it’s hard to come by. Typically, there is a multiplicity of access methods. What I mean by that is this: during chip debug, there’s one access mechanism for the output of the instruments embedded on the chip; then for IC yield analysis, there’s another access mechanism; and for board-test, there is yet another completely different access mechanism. In some cases, chip companies end up with two or three debug boards to access embedded cores on a single die. Here again, IJTAG will help because, if adopted, it will enable a single hardware platform and possibly a single tool to access all of the embedded instrumentation at the same time.

Crouch indicated that the IEEE P1687 IJTAG working group is making great progress on the standard document. The next step will be to distribute the draft standard to members for the initial ballot sometime later this year.

For more information on the IJTAG standard, click here.