this JTAG thing is a joke

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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?


Re: this JTAG thing is a joke
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:
Quoted text here. Click to load it


Re: this JTAG thing is a joke

Quoted text here. Click to load it
<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


Re: this JTAG thing is a joke
Quoted text here. Click to load it

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

Re: this JTAG thing is a joke
Jim Granville schrieb:
Quoted text here. Click to load it

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

Re: this JTAG thing is a joke
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:
Quoted text here. Click to load 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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: this JTAG thing is a joke
Quoted text here. Click to load it


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

Quoted text here. Click to load it



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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Re: this JTAG thing is a joke
Quoted text here. Click to load 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.



Re: this JTAG thing is a joke
Symon schrieb:

Quoted text here. Click to load it

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

Re: this JTAG thing is a joke
Quoted text here. Click to load it
Falk,
I thought Murphy's Law describes why things _don't_ work, not why they _do_
work?! :-) The reason you often get some improvement is that the connections
at the destination end are close together and, particularly for big BGAs
like FPGAs, are at the end of stubs. The source is far away at the end of a
cable.
Quoted text here. Click to load it
Of course, but that's a fat lot of help when you're stuck with a board which
wasn't designed by someone like you who thought about the SI! The bodge I
suggested, together with a bit of simulation experimentation,  might just
get a board going un-modded.
Cheers, Syms.



Re: this JTAG thing is a joke
Symon schrieb:

Quoted text here. Click to load it

Theory: Nothing works but everone knows why.
Practice: Everything works but nobody knows why.
Theory + Practice : Nothing works and nobody knows why.

;-)

Quoted text here. Click to load it

Si.


Ok, for a work around this might be a way to go (If all you got is a
hammer, everything looks like a nail). But the original
complaint/cry/whatever was about a implementation of JTAG from scratch.

Regards
Falk

P.S. One of the problems with JTAG is/was, that people underestimate
problems due to the low frequencies involved. And as far as I remember,
the are/were some nasty problems with FPGAs for brand . . . because the
JTAG inputs (especially the clock) was sensitive to non-perfect
transitions, which means you have to treat the almost DC like JTAG like
a GBit transmission line. Not nice at all. The suggestion of Austin to
do a simulation is in general right, but sounds a little bit strange to
me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition
time that matters, not frequency). So why is the JTAG (clock) not
INTENTINALLY made slower (+ schmitt trigger) to avoid this problems?
Nobody needs a 100MHz++ capable JTAG port (today).

Re: this JTAG thing is a joke
Quoted text here. Click to load it

I could use one... When driving the address and data lines of
a processor in order to program a flash memory (because the
data on how to do this using the processor internal utilities for
that are secret or the processor has none), this can make some
reasonable difference in programming times (mainly during prototype
testing/bringing up, during production you typically can program
some tiny initial boot flash code which will do the rest).
But well, I do not argue I could not live without it, it would
just be nice to have it.

Dimiter

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

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


Falk Brunner wrote:
Quoted text here. Click to load it


Re: this JTAG thing is a joke



Quoted text here. Click to load it

This is one of the best I've ever heard!

Quoted text here. Click to load it

On many FPGA's, especially Xilinx, the JTAG signals are on pins that can
be used as
normal user I/O pins.  So, they would have to put special filters on the
pins when used
for JTAG, and remove the filter for normal use.  Clearly could be done,
but it gets
complicated.  And, you never know how fast any specific user might run
their JTAG.
In some cases, a user might rig an FPGA and a local memory to do very
fast loading
or testing on their production line.

I had a similar problem with a 5 V Spartan FPGA.  It implemented a long
serial chain
for configuration sensing/setup on a motherboard with up to 16
daughterboards.   The
command/control was via LVDS, which had WAY more bandwidth than needed, but
they fit the other requirements.  We had some reflections on the LVDS
lines that caused
double pulses on the serial clock.  So, I had to implement an external
filter with an RC
and a Schmitt trigger before feeding the clock to the FPGA.  It was hard
to track down,
it was one of those "only works with the scope probe on the pin"
conditions.  Once
I knew what was going on, it was easy to fix.

Jon


Re: this JTAG thing is a joke
<snip>> P.S. One of the problems with JTAG is/was, that people
underestimate
Quoted text here. Click to load it

  The latest Serial memories from Winbond can stream at 150Mbd, from an
8 pin package !

  That makes even 100MHz look sluggish.

  There is talk of USB-JTAG, which is sensible, and that should be
high speed USB, in that case, FPGA suppliers SHOULD be working on
~400MBd capable JTAG streaming.

-jg


Re: this JTAG thing is a joke
Jim Granville schrieb:

Quoted text here. Click to load it

Uuups!

Quoted text here. Click to load it

Really? But would this kick out the basic concept of JTAG being simple
and low efford? I mean a normal JTAG chain runs just TMS/TCK as a single
line from chip to chip and TDI/TDO in a daisy chain. Done. 400 Mbit/s
would require diffent I/Os than plain LVCMOS etc. Hmmm.
Maybe for some memories, but for all other ICs??

Regards
Falk

Re: this JTAG thing is a joke

Quoted text here. Click to load it

  The other postings have shown that the long lengths of JTAG chains
still can cause problems, even at 5MHz.

  Maybe if it was called a 50MHz bus, more care would be taken :)

66-75MHz is now pretty standard for SPI devices, so it's about time the
JTAG caught up a little...

  I'd suggest a Std Schmitt on the TCK, and then use the FPGA IO features
for the rest - so it does not have any real additional cost.

  ie you go to whatever the FPGA and PCB allow, and do not limit to 5-10MHz.

  Clearly one would not chain at 400Mhz, but there is a case for fast
loading to one device, or a star network, to load many, at very high
speeds.

  Anyone got numbers on how fast the JTAG can clock, on the new 65nm
Xilinx FPGAs, curently in the Labs  ?

-jg


Re: this JTAG thing is a joke
Quoted text here. Click to load it
Many years ago, I had to build a parallel-port to JTAG pod. Simple
enough, indeed. But one wrinkle I added was to take two parallel-port
bits for the clock, with a S-R flipflop in the pod. Pulse one bit to set
the clock, and one to reset. Yes, it was a fraction slower, but it
stopped any parallel line-bounce in its tracks.

Re: this JTAG thing is a joke
Quoted text here. Click to load it

Have you considered an approach like the National SCANSTA112?

Henk
www.mediatronix.com


Re: this JTAG thing is a joke
Brannon,

The most common problem with JTAG is people expect it to work, without
simulating the signal integrity of their implementation.

Bad choice.

Our Rosetta boards have ten devices per board, and ten boards (100
devices).  They are arranged in a chain.

We simulated the single card, and the chain, and found we needed to
buffer the clock, but everything else was fine.  The first card in the
chain has a wide buffer, that splits out the clock, to drive the ones on
that card, and nine more outputs, one for each additional card.

We do have to make sure we do not do something stupid, and mismatch the
signal lines.

Simulate it first, and then your problems will go away.

Austin

Brannon wrote:

Quoted text here. Click to load it

Site Timeline