this JTAG thing is a joke - Page 2

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

Translate This Thread From English to

Threaded View
Re: this JTAG thing is a joke
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.

Austin

Austin Lesea wrote:

Quoted text here. Click to load it

Re: this JTAG thing is a joke
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

Quoted text here. Click to load it



Re: this JTAG thing is a joke
Mikej,

What I am referring to here, is a cap in series with a 50 ohm resistor
to ground across the input at the end of the line.

signal ------------input
             |
            cap
             |
           50ohms
             |
           ground

This is less static power than a 100 ohm split from power to ground, and
is equivalent (if you really are 50/50) to a 50 ohm resistor to Vcco/2
(also another perfectly accptable termination).

Austin

MikeJ wrote:

Quoted text here. Click to load it

Re: 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

Quoted text here. Click to load it


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

  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


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

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.
http://openwince.sourceforge.net/jtag/

- 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

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

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.

Quoted text here. Click to load it

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


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

I've used the JTS06 six port scan bridge with success from these people :
http://www.firecron.com /
it's has six chains and is controlled over JTAG. Similar 3 port devices
available from National
/MikeJ



Site Timeline