Connect - ASSET InterTech

Until this point, Mr. PCB had thought he was bringing Chip around to realizing the value of inserting JTAG correctly. After all, he had gone through the horror stories about the device designers who had failed to pay attention or simply didn't realize the importance of inserting a fully complaint JTAG infrastructure into their designs. Chip, it turns out, has a short memory. You might say that his functionality is impaired by the limited amount of memory the Big Designer had given him. The stories of lost orders and liquidated damages against device suppliers that provided semiconductors without properly implementing JTAG had gone into one of Chip's IOs and out the other.

PCB: “Happy? Easy for you to say! You're not around when we're trying to make something work the way it's supposed to work and we don't have the information we need because someone like you….well, we've gone over that already. Let’s talk about the things you need to pay attention to.”

Chip: “Yeah, let's do that. And let's calm down a bit too. No more triple shot lattes for you.”

PCB: “OK, now listen carefully. I'm going to go through this quickly. I've got to get back to work. We're trying to debug this design and some of the devices on the board aren't cooperating. I wonder why!”

At this point, Mr. PCB began rattling off a number of questions that semiconductor designers need to ask themselves as they are inserting JTAG into their devices. Dave, our ardent reporter, scribbled down as many as he could. Here's what he brought back:

PCB: “First, let's talk about the device's JTAG Test Access Port (TAP).

Does the TAP include the four mandatory signals? (TMS, TDI, TDO and TCK)

Are the TAP signal pins dedicated?

Are the stored-states within the device maintained indefinitely when TCK is at logic 0?

Is the logic state on the TMS signal sampled on the rising edge of TCK?

Does an un-driven TMS pin provide a logic 1 to the internal IEEE1149 logic?

Is the logic state on TDI sampled on the rising edge of TCK?

Does an un-driven TDI pin provide a logic 1 to the internal IEEE1149 logic?

Is there no logical inversion of data when shifting data between TDI and TDO?

Is the signal present on the TDO pin sampled on the falling edge of TCK?

Does the TDO pin provide an inactive HIGHZ state when not driving data?

Does the TRST pin asynchronously reset the TAP to the "Test Logic Reset" when a logic 0 is present?

Does an un-driven TRST pin provide a logic 1 to the internal IEEE 1149.1 logic?

Does the TRST pin initialize any system logic within the component?

Does the TAP controller only change states when the following events occur?

Is the TAP controller forced into Test-Logic-Reset on power up?

Are there restrictions on simultaneous switching of I/O pins when in IEEE1149.1 EXTEST mode?

Is the IEEE 1149.1 TAP logic tested during normal device test?

PCB: “After you've got the TAP right, you need to pay attention to the JTAG instructions. Let's talk about those now.”

Are all the mandatory IEEE1149.1 instructions implanted and fully functional? Including the following:

For the BYPASS instruction, ask these questions:

Is the binary code for BYPASS equal to {111...1}? Does BYPASS put the bypass register between TDI and TDO in the Shift-DR state? Is the BYPASS register 1 bit long? When in BYPASS do all the core logic operations perform their normal system functions? When BYPASS is selected, does the operation of the TAP have any effect on system function? Is the BYPASS instruction documented in the BSDL file?

For the SAMPLE instruction ask these questions:

Does SAMPLE select only the BSR (boundary scan register) for access between TDI and TDO in the Shift-DR state? Does the SAMPLE instruction affect the operation of core logic functionality? Does SAMPLE capture all on-chip signals states into the BSR on the rising edge of TCK in the Capture-DR state?

For the PRELOAD instruction ask these questions:

Does PRELOAD select only the BSR to be connected for access between TDI and TDO in the Shift-DR controller state? Does the use of PRELOAD affect the operation of the on-chip system logic or the flow of signals between the system pins and the on-chip system logic? Does PRELOAD load the data held in the associated shift register on the falling edge of TCK in the Update-DR state?

For the EXTEST instruction ask these questions:

Does EXTEST select only the BSR between TDI and TDO in the Shift-DR state? Does EXTEST isolate on-chip logic so it cannot be damaged by signals received at the device pins? During EXTEST are all signals driven from system pins completely defined by the data held in the BSR and does it change only on the falling edge of TCK in the Update-DR state? During EXTEST are all signals received at system input pins loaded into the BSR on the rising edge of TCK in the Capture-DR state?

PCB: Of course, Chip, there are several optional 1149.1 instructions, such as HIGHZ, IDCODE, USERCODE and RUNBIST, but I suggest you get the basics down first and we’ll worry about the optional instructions later. And then there are other issues like programmable logic and how it can be configured and programmed via the 1149.1 TAP. There are aspects of the 1149.1 standard that you need to be aware of so the device you’re working on will support in-system programming later. And for in-system configuration of complex logic devices, you’ll want to know about the requirements of the IEEE 1532 standard, which operates in concert with the 1149.1 standard.

Chip: “Golly, that’s a lot to take in.”

PCB: “It sure is and it's all necessary if you want your device to function the way your customers expect it to. Oh, and there are just a few more things you should be aware of.”

You’re going to have to generate a Boundary Scan Description (BSDL) file that describes your device so it can be used by automatic test program generation (ATPG) systems, like ASSET's ScanWorks.

Once you have the BSDL file, ask if it's been syntactically and semantically checked for conformance with the IEEE1149.x standards. This is pretty easy to do, given the fact that ASSET offers a BSDL validation service on the web and its free. (www.asset-intertech.com/bsdl_service). Make sure you use it!

Was the BSDL and RTL generated with a commercially available and reputable tool?

Was the JTAG logic verified against a third-party generated testbench like those you can get at the ASSET BSDL validation site?

Has the BSDL file been verified against actual silicon? It will save you a lot of headaches later and ASSET can help you with this too.

At this point, Mr. PCB looked at Chip and it seemed as though his jaw had dropped to the floor.

Chip: “I never realized I should have been paying attention to all these issues.”

Mr. PCB smiled condescendingly.

PCB: "I know, son," he said. "Lucky for you there are a number of tools out there that can help you. All you have to do is care about doing a good job."

And so ends the saga of Mr. PCB and Chip. We would like to report that all the characters in this little fable lived happily ever after. Unfortunately, we still hear reports from time to time that there are semiconductor designers who haven't learned the lessons that Chip did.