this JTAG thing is a joke

Hi Austin,

I understand what you mean, the reason I used a 100 ohm split (what I refered to as an up/down terminator) is that it always looks like 50 ohms to ground even to non-50/50 signals like TMS.

Surely with your cap/resistor terminator (which I use for most of my clocks) it is a 50 ohm to some odd voltage depeding what TMS has been doing recently ? I guess it still functions when TMS changes state, but has the advantage of consuming no power when TMS is stuck high, which of course is almost always.

/MikeJ

You are correct, in so far that it could (in theory) degrade the eye pattern, but adding some history loading on the line - but from a simple reflection/ringing viewpoint, it will work. At 5MHz you are probably not pushing the eye patterns much :)

-jg

Brannon schrieb:

There are existing JTAG APIs. Which one becomes a standard is the choice of the developers that use them. Maybe there never will be a widely accepted standard, but that does not matter as mutliple APIs can coexist.

- Openwince has a nice iAPI with drivers for quite a lot of interfaces. It is relatively easy to add new drivers.

- Xilinx provides a TCL API.

- There is an extremely primitive Java JTAG API from SUN and Xilinx.

- Any SVF player can be used to send JTAG commands from an application to the chips. (Openwince also contains an SVF player)

Unfortunately the openwince project is rather inactive for a few years now, but maybe we can change that.

As far as your other suggestion are concerned: It is important that JTAG stays extremely simple to implement. An FPGA can justify a complex JTAG replacement. But for board testing it can be very important to have bus buffers that have JTAG-ports. I do not want to pay for an IP layer in each of my buffer ics.

There exist simple controller ICs that split a JTAG chain in parts that can be individually shifted. That solves virtually all of your other concerns.

Kolja Sulimma

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.

[...]

Have you heard of buffering and multiplexing? I've seen boards with over 100 JTAG devices, with a few clock buffers and a few multiplexers and signal buffers to tie everything together. Then a few dozen of these boards are similarly mulitplexed by the backplane circuitry.

here's no way in hell that I'd want 2048 chips in one JTAG chain anyhow. Life's too short.

On the other hand, a new standard for JTAG multiplexing controlled over the JTAG itself would be quite useful. If such a standard existed, you'd probably be able to buy cheap commodity JTAG buffer/mux chips in a wide variety of port counts.

You mean the old thick-cable 10Base5 Ethernet? That only supported a maximum of 100 nodes per segment. Beyond that, you needed a repeater. Also, each node needed an expensive transceiver (vampire tap).

If you were thinking of thin coax 10Base2, that only supported 30 nodes per segment.

Neither technology is even vaguely comparable to what you seem to be asking for.

Everyone was happy to abandon these in favor of 10BaseT (and later,

100BaseT) point-to-point links? No, we definitely don't want to bring bussed Ethernet back.

Using error correction would be overkill, and would add way too much circuitry to devices. Just put a basic frame check for error detection. A parity bit or a CRC-16 should work quite nicely for that. Since you'd use multiplexing rather than putting 2048 chips in one chain, you'd be able to afford to resend a frame rather than depending on the chip to correct errors. (Note that the frame I'm talking about isn't necessarily any relation to a Xilinx FPGA configuration frame.)

I've used the JTS06 six port scan bridge with success from these people :

it's has six chains and is controlled over JTAG. Similar 3 port devices available from National /MikeJ