JTAG Whisperer: help with TCK polarity

[sowbug]

Summary: if you want to play an XSVF to a JTAG device and have an Arduino handy, then https://github.com/sowbug/JTAGWhisperer will soon be your friend. But not yet.

I'm writing an XSVF player for Arduino. It doesn't work yet, and I'm 99% sure it's because I'm sending the TDI/TMS/TCK signals wrong (as opposed to having an error in my state machine or other silly logic errors, etc.). The basic problem is that no implementation of JTAG programming I've seen on the web, including the very helpful article on this site, does what you'd expect from Xilinx's XAPP058 description of JTAG electrical signals. XAPP058 suggests that the core sequence of writing TDI and reading TDO should be this:

1. Output TDI/TMS as appropriate.
2. Set TCK.
3. Clear TCK.
4. Wait TDOV nanoseconds.
5. Read TDO.

However, nobody does this. I've seen all of the following:

1. Read TDO.
2. Clear TCK at the same time as outputting TDI/TMS.
3. Set TCK.
4. Clear TCK.

or...

1. Set TCK.
2. Read TDO.
3. Clear TCK.

or...

1. Output TDI/TMS.
2. Clear TCK.
3. Read TDO.
4. Set TCK.

or something else. But nothing matches the XAPP058 diagram. This leads me to the conclusion that XAPP058 is wrong, or else that every real-world implementation I've seen to date represents trial-and-error rearrangements of the signal manipulation. Is there a better authority than XAPP058 on the electrical characteristics of the JTAG protocol?

[sowbug]

I'll try to answer my own question. Most of those sequences are consistent with XAPP058. They're just telling the story in an inverted fashion. Think of it as corresponding by written letter with a pen-pal. From your perspective, the exchange starts when you get a letter and write a response, then ends when you drop it in the mailbox. It cycles when your friend writes back. But from the Post Office's perspective, the story *starts* when the letter is dropped in the mailbox, and *ends* when it arrives at your friend's house. These two stories are correct, just looking at the overall story differently.

It's a bit like that. The time when TCK is *clear* is when the master does its work. So we start the cycle clearing TCK, then reading TDO, writing TMS/TDI, etc., then setting TCK to let the target know it gets to reply. While we're waiting for the target's reply we go and do all the other work we need to be ready for the next cycle. From a timing perspective it might all be the same, but from a code perspective it's better to do the work while you'd otherwise be waiting for the other party to respond.

Anyway, I now think that most of the code I've seen agrees with XAPP058, so all is well again in my own universe.