bfin:jtag:timing [Open Source @ Analog]

The test logic consists of a Boundary-Scan register and other building blocks. The test logic is accessed through what is commonly referred to as the Test Access Port or TAP. The TAP consists of 6 pins

Name	Type	Description
TCK	Input	JTAG Clock
TDO	Output	JTAG Serial Data Out
TDI	Input	JTAG Serial Data In
TMS	Input	JTAG Mode Select
TRST	Input	JTAG Reset
EMU	Output	Emulation Output

The first step of understanding JTAG is understanding the validity of the data, or when is the data clocked into/out of the JTAG port by the test device, or emulator. If we use the Blackfin processor as an example - the datasheet indicates something like:

Timing Requirements

symbol	Description	Specification
t_TCK	TCK Period	min 20 ns
t_STAP	TDI, TMS Setup Before TCK High	min 4 ns
t_HTAP	TDI, TMS Hold After TCK High	min 4 ns
t_TRSTW	TRST Pulse Width (Measured in TCK cycles)	min 4 TCK cycles

Switching Characteristics

symbol	Description	Specification
t_DTDO	TDO Delay from TCK Low	max 10 ns

The JTAG specification section 6.3.1.c indicates “Where a dedicated reset pin (TRST*) is provided to allow initialization of the TAP controller, initialization shall occur asynchronously when the TRST* input changes to the low logic level.”, this is not true on the Blackfin, where a min TRST pulse width of 4 TCLK cycles is necessary.

So, lets check the hardware on Data In – or when should we wiggle the datain pin for the Blackfin. To do this, we look at how the VDSP++ In Circuit Emulator does things.

We can see from this that the ADI emulators change TDI on the falling edge of TCLK, so it is stable on the rising edge. This agrees with the datasheet, and shows that the TDI changes within 4ns of TCLK changing.

The TDO is similar – coming out of the Blackfin on the falling edge of TCLK, and being stable on the rising edge. However, it takes almost 10ns to become stable (this is with the specifications of the datasheet). Anything that is reading the TDO must wait at least 10ns after TCLK falls, or expect to get bad data.

Things are a little more interesting when we speed things up to 50MHz (max JTAG speed). Yellow is TCLK, Pink is TDI and Green is TDO.

Here you can see that when the JTAG clock is sped up, the inputs (outputs from the emulator) still change on the falling edge, although TMS (in blue) seems to have about a 1 ns delay from TDI (in pink). TDO (in green) still has the 10ns delay until it is valid.

Here we can see a blown up version of the above. Again – reinforcing that TDO (Green) should is not stable until 10ns after the falling edge of TCLK (when TCLK is under 0.6V). By this, it is safe to use the logic that everything on the JTAG bus is at a fixed state on the rising edge of TCLK.

This is the assumption that the rest of this document will use for the analysis.

Parallel Port

Because low cost cables also connect to the parallel port of a Linux Machine, their timing can be uncontrollable. For example:

Since making a constant clock on a PC is very difficult (both under Windows or Linux) , the TCLK has a tendency to drift, and not be stable. If is very difficult just by looking at this to understand where things are being clocked in or out of either device. (Yellow is TCLK, Pink is TDI and Green is TDO.) We can see that with the ByteBlaster Cable, TDO is not pulled high or low, in the cable, nor on the target, and can drift anywhere it wants when connected to the byteBlaster. You can also notice that the speed of this is close to 800kHz, more than 50 times slower than the ADI emulators. (although the ByteBlaster is over 175 times cheaper).

We can see here that TDI changes state within the required prameters. And TDO (as expected) is stable on the rising edge of TCLK.