this JTAG thing is a joke

This post is a bit of a flame, but seriously, JTAG has got to go. The
signals are weak. The various drivers and controllers for it are weak.
It causes nonstop headaches for hardware developers and FPGA developers
alike. It's slow, hardly customizable, hard to use, ultra extremely
fantastically flaky on every piece of FPGA hardware I've ever used
(which includes at least a dozen vendors), and ancient technology.

Here is what I want:

1. Support for a lot of chips, say 2048 of them. JTAG supposedly
supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
three or four. The 200KHz signal dies after eight or nine. This will
require some strong signals with error correction, but, heck, if a
basic ethernet layer can do it....

2. Endpoint enabling. The JTAG methods for specifying an endpoint are
both flaky and redundant. We need some nice protocols, maybe even
packets with headers, etc.

3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
And put some standard, accessible plugs on there while you're at it.

4. Standard driver interface. Need I say more? How many of you write
directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
you all enjoy it too. How about something like this:

mycard = code to locate the right driver and device and open it....
ioctl(mycard, HOW_MANY_DEVICES, &devices)
id_struct = new ID_STRUCT[devices]
ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
for each d in devices {
  if( id_struct[d].devId == Virtex4Id ) {
     targetlist = { d }
     ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
     command_struct.mode = programming
     ioctl(mycard, SEND_COMMAND, &command_struct)
     write(mycard, "c:\my programming file.bit")
     ioctl(mycard, READ_STATUS, &status_struct)
     if( status_struct.mode & programmed) break
     else return failed
  }
}
Then we go into a loop for reading and writing debug data, etc.

We could have drivers for a dozen different interfaces including
Firewire, parallel port (urrrg), serial port (double urrrg), etc.

Yo Xilinx, let's remove the great mystery from Impact. Let's open the
hat on the "platform" driver and make the thing useful for the parallel
port as well.

Maybe I'm taking this too far. I just want something that works
reliably and is not a pain in the ars to use programmatically. Is that
too much to ask?

While I agree with you that it is outdated and too slow,
I'd say some single chip USB 2.0 <-> much-faster-than-todays-JTAG
would be a practical enough solution. It will take care of the level
conversion and everything, and the speed will be as high as it
gets. Need more speed for too big a board, put several JTAG chains
on it, ready.

I do not understand what you mean by "the 5 MHz clock dies out after",
what's wrong with buffering it? But 5 MHz is too slow for todays big
chips anyway, so the point is valid nonetheless .
Now error correction, packet headers etc. sounds like
suggesting an entire tcp/ip for the backyard of something which
may not have as much in the front yard... that's a bit (way?) too far
for me.
We won't make a consumer interface out of JTAG, will we (I hope we
don't ... :-) .

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


Brannon wrote:
> This post is a bit of a flame, but seriously, JTAG has got to go. The
> signals are weak. The various drivers and controllers for it are weak.
> It causes nonstop headaches for hardware developers and FPGA developers
> alike. It's slow, hardly customizable, hard to use, ultra extremely
> fantastically flaky on every piece of FPGA hardware I've ever used
> (which includes at least a dozen vendors), and ancient technology.
>
> Here is what I want:
>
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....
>
> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
> both flaky and redundant. We need some nice protocols, maybe even
> packets with headers, etc.
>
> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
> And put some standard, accessible plugs on there while you're at it.
>
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:
>
> mycard = code to locate the right driver and device and open it....
> ioctl(mycard, HOW_MANY_DEVICES, &devices)
> id_struct = new ID_STRUCT[devices]
> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
> for each d in devices {
>   if( id_struct[d].devId == Virtex4Id ) {
>      targetlist = { d }
>      ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>      command_struct.mode = programming
>      ioctl(mycard, SEND_COMMAND, &command_struct)
>      write(mycard, "c:\my programming file.bit")
>      ioctl(mycard, READ_STATUS, &status_struct)
>      if( status_struct.mode & programmed) break
>      else return failed
>   }
> }
> Then we go into a loop for reading and writing debug data, etc.
>
> We could have drivers for a dozen different interfaces including
> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
>
> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
> hat on the "platform" driver and make the thing useful for the parallel
> port as well.
>
> Maybe I'm taking this too far. I just want something that works
> reliably and is not a pain in the ars to use programmatically. Is that
> too much to ask?

I might suggest that the standardization process is an open one and that 
individuals motivated to develop new ones are free to do so.  You can 
use this thread to gather support and volunteers and then approach your 
favorite standards body (IEEE, JEDEC, etc.) and move ahead

Further comments...

Brannon wrote:
> This post is a bit of a flame, but seriously, JTAG has got to go. The
> signals are weak. The various drivers and controllers for it are weak.
> It causes nonstop headaches for hardware developers and FPGA developers
> alike. It's slow, hardly customizable, hard to use, ultra extremely
> fantastically flaky on every piece of FPGA hardware I've ever used
> (which includes at least a dozen vendors), and ancient technology.
> 
> Here is what I want:
> 
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....

There is no limit.  Additional drivers ought to be used on board to 
strengthen the parallel signals (TCK, TMS) on long chains.  Just because 
TCK and TMS are "slow" doesn't mean that you can ignore layout and 
signal integrity considerations for them.

> 
> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
> both flaky and redundant. We need some nice protocols, maybe even
> packets with headers, etc.
> 
> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
> And put some standard, accessible plugs on there while you're at it.

Boundary-scan is as fast as the slowest device in the serial chain. 
This is a weakness of all serial protocols.

> 
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:
> 

The development of standards of this sort is certainly easy to sketch 
out but the devil is in the details.  Start a standards committee and 
have at it.

> mycard = code to locate the right driver and device and open it....
> ioctl(mycard, HOW_MANY_DEVICES, &devices)
> id_struct = new ID_STRUCT[devices]
> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
> for each d in devices {
>   if( id_struct[d].devId == Virtex4Id ) {
>      targetlist = { d }
>      ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>      command_struct.mode = programming
>      ioctl(mycard, SEND_COMMAND, &command_struct)
>      write(mycard, "c:\my programming file.bit")
>      ioctl(mycard, READ_STATUS, &status_struct)
>      if( status_struct.mode & programmed) break
>      else return failed
>   }
> }
> Then we go into a loop for reading and writing debug data, etc.
> 
> We could have drivers for a dozen different interfaces including
> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
> 
> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
> hat on the "platform" driver and make the thing useful for the parallel
> port as well.
> 
> Maybe I'm taking this too far. I just want something that works
> reliably and is not a pain in the ars to use programmatically. Is that
> too much to ask?
> 

dp wrote:

> While I agree with you that it is outdated and too slow,
> I'd say some single chip USB 2.0 <-> much-faster-than-todays-JTAG
> would be a practical enough solution. It will take care of the level
> conversion and everything, and the speed will be as high as it
> gets. Need more speed for too big a board, put several JTAG chains
> on it, ready.
> 
> I do not understand what you mean by "the 5 MHz clock dies out after",
> what's wrong with buffering it? But 5 MHz is too slow for todays big
> chips anyway, so the point is valid nonetheless .
<snip>

JTAG itself is OK, it is the implementations that are sometimes 'left 
till last'.

Speed-sag is solved with TinyLogic buffers, as dp suggests.

Seems there are two paths :
a) Start a committee as Neil suggests (no smiley seen?)

b) Start an openCore project, that defines a CPLD fast JTAG interface,
to either a Parallel port, or a FTDI device, or a Cypress USB uC etc
This would have a BAUD select, and have the ability to run multiple JTAG
stubs - ie if Chain is broken ( seems to be common ) then run a star 
structure.

-jg

>2. Endpoint enabling. The JTAG methods for specifying an endpoint are
>both flaky and redundant. We need some nice protocols, maybe even
>packets with headers, etc.

>1. Support for a lot of chips, say 2048 of them. JTAG supposedly
>supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
>three or four. The 200KHz signal dies after eight or nine. This will
>require some strong signals with error correction, but, heck, if a
>basic ethernet layer can do it....
>3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
>And put some standard, accessible plugs on there while you're at it.

Two pins differential interface with crc check should enable more robustness?
(while keeping things simple=cheap at the same time)

>4. Standard driver interface. Need I say more? How many of you write
>directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
>you all enjoy it too. How about something like this:

>mycard = code to locate the right driver and device and open it....
>ioctl(mycard, HOW_MANY_DEVICES, &devices)
>id_struct = new ID_STRUCT[devices]
>ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
>for each d in devices {
>  if( id_struct[d].devId == Virtex4Id ) {
>     targetlist = { d }
>     ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>     command_struct.mode = programming
>     ioctl(mycard, SEND_COMMAND, &command_struct)
>     write(mycard, "c:\my programming file.bit")
>     ioctl(mycard, READ_STATUS, &status_struct)
>     if( status_struct.mode & programmed) break
>     else return failed
>  }
>}
>Then we go into a loop for reading and writing debug data, etc.

>We could have drivers for a dozen different interfaces including
>Firewire, parallel port (urrrg), serial port (double urrrg), etc.

An jtag <-> mcu <-> usb could do the job ..?

>Yo Xilinx, let's remove the great mystery from Impact. Let's open the
>hat on the "platform" driver and make the thing useful for the parallel
>port as well.

One way is to make fake usb device with help of a virtual device driver.
A kludge ofcourse but still =)

>Maybe I'm taking this too far. I just want something that works
>reliably and is not a pain in the ars to use programmatically. Is that
>too much to ask?

As long as the money comes in.. :-)

"Brannon" <brannonking@yahoo.com> wrote in message 
news:1143048778.266522.35020@z34g2000cwc.googlegroups.com...
>
> Here is what I want:
>
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....
>
Hi Brannon,
I agree with much of what you write.
As a workaround for your clocking problems, you could try source terminating 
the clock driver from your JTAG controller. On my platform cable USB I use a 
2x7 2mm header with 4 50 ohm resistors in series with the signal lines. 
Improves the performance significantly for me.
HTH, Syms. 

Jim Granville wrote:
> dp wrote:
> 
>> While I agree with you that it is outdated and too slow,
>> I'd say some single chip USB 2.0 <-> much-faster-than-todays-JTAG
>> would be a practical enough solution. It will take care of the level
>> conversion and everything, and the speed will be as high as it
>> gets. Need more speed for too big a board, put several JTAG chains
>> on it, ready.
>>
>> I do not understand what you mean by "the 5 MHz clock dies out after",
>> what's wrong with buffering it? But 5 MHz is too slow for todays big
>> chips anyway, so the point is valid nonetheless .
> 
> <snip>
> 
> JTAG itself is OK, it is the implementations that are sometimes 'left 
> till last'.
> 
> Speed-sag is solved with TinyLogic buffers, as dp suggests.
> 
> Seems there are two paths :
> a) Start a committee as Neil suggests (no smiley seen?)
> 
> b) Start an openCore project, that defines a CPLD fast JTAG interface,
> to either a Parallel port, or a FTDI device, or a Cypress USB uC etc
> This would have a BAUD select, and have the ability to run multiple JTAG
> stubs - ie if Chain is broken ( seems to be common ) then run a star 
> structure.
> 
> -jg
> 

For an ready-to-use USB to JTAG solution based on FTDI FT2232 have a 
look at:
  http://www.amontec.com/jtagkey.shtml
  http://www.ftdichip.com/Products/EvaluationKits/3rdPartyKits.htm

The Amontec JTAGkey is certainly what you are searching for building 
custom JTAG application over USB in the best time and for the best price.

IO voltage in a wide range : 1.4V to 5V
JTAG freq: from 1Hz to 6Mhz

Laurent

Brannon wrote:
> 1. Support for a lot of chips, say 2048 of them.

Have you considered an approach like the National SCANSTA112?

Henk
www.mediatronix.com

Jim Granville schrieb:
> JTAG itself is OK, it is the implementations that are sometimes 'left 
> till last'.

First, I would like to separate two issues, which I believe have no 
interdependencies with each other:
- the protocol
- the electrical implementation

_protocol_
I believe the protocol is quite ok. The TAP state machine, the commands, 
the way pins or internal bits are controlled are all reasonable. So 
software-wise, I believe JTAG is here to stay. One of the interesting 
observations here is, that most APIs controlling JTAG devices are *not* 
based on the pure essence of the protocol, i.e. the SVF commands. 
Instead most APIs are using a bit-bang paradigm, which makes it 
impossible to make high-level optimizations.

_electrical implementation_
The electrical implementation might be outdated and not reflect the 
current state-of-art. Even if this is the case (I am not sure about 
this), I still doubt that everybody out there really wants to implement 
more advanced protocols, based on whatever standard (I read Ethernet in 
previous posts). In my impression, the most critical question is not 
JTAG itself, but the clumsy interface between JTAG and typical PCs. 
Parallel Cables are really not the way to do things any more. USB 
requires a proper protocol, as read-backs have to be avoided as much as 
possible (which is sometimes impossible due to poor software interfaces).

This all looks very similar to what the music industry did to the 
ancient MIDI protocol. While the five-pin cable is almost gone now, the 
protocol itself is still alive: in PCI, USB and FireWire implementations.

_suggestions_

I am dreaming for a few years now, that Xilinx would open and document 
Impact's JTAG API. This would allow everybody (especially 3rd party eval 
board manufacturers) to plug in their own electrical implementations 
(e.g. USB-based), while sticking to the JTAG software paradigm.

Going from there, maybe some open source project might start, 
implementing a standardized and powerful JTAG interface (plus Impact 
drivers), based on USB, Ethernet or whatever feels appropriate.



Any comments highly welcome,
best regards


Felix

-- 
Dipl.-Ing. Felix Bertram
http://homepage.mac.com/f.bertram

Symon schrieb:

>>1. Support for a lot of chips, say 2048 of them. JTAG supposedly
>>supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
>>three or four. The 200KHz signal dies after eight or nine. This will
>>require some strong signals with error correction, but, heck, if a
>>basic ethernet layer can do it....
>>
> 
> Hi Brannon,
> I agree with much of what you write.
> As a workaround for your clocking problems, you could try source terminating 
> the clock driver from your JTAG controller. On my platform cable USB I use a 

HMMMM??? SOURCE-Termination for a multidrop CLOCK signal? It may work, 
but more due to murphys law than by design .  . .

AC-termination at the end of a clock line is most probably the better 
way to go. And don't forget, those parallel port often enough spit out 
really ugly signals. So a buffer for the clock line with a schmitt 
trigger input and a RC-filter in front pays off.

Regards
Falk