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

------------------------------------------------------

Brann> This post is a bit of a flame, but seriously, JTAG has got to go. The

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...

Brann> This post is a bit of a flame, but seriously, JTAG has got to go. The

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.

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

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.

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

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

An jtag mcu usb could do the job ..?

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

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

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.

For an ready-to-use USB to JTAG solution based on FTDI FT2232 have a look at:

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

Have you considered an approach like the National SCANSTA112?

Henk

Jim Granville schrieb:

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:

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

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.

Aust> This post is a bit of a flame, but seriously, JTAG has got to go. The

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.

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.

Symon schrieb:

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

;-)

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).

One more thing,

We also AC terminate at the endpoints of TMS and TCK.

This was also shown to be necessary in the simulations.

But don't just assume this is the "solution", you must simulate your pcb, and decide what to do.

Aust> Brannon,

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

------------------------------------------------------

Falk Brunner wrote:

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

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

underestimate

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

Jim Granville schrieb:

Uuups!

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

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

Austin,

I thought AC termination only worked with 50/50 duty cycle clocks? you got it going with TMS ?

I have always used an up/down resistor terminator and lived with the static power dissipation that implies.

One thing we did do a while ago was replace the JTAG chain (18 VirtexE devices per board) with a cpu bus interface CPLD which wired directly to the din / cclk pins of each device - programmed 18 different designs in parallel, much faster ...

/MikeJ