Re: this JTAG thing is a joke
- From: "dp" <dp@xxxxxxxxxxx>
- Date: 22 Mar 2006 09:53:15 -0800
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?
.
- Follow-Ups:
- Re: this JTAG thing is a joke
- From: Jim Granville
- Re: this JTAG thing is a joke
- References:
- this JTAG thing is a joke
- From: Brannon
- this JTAG thing is a joke
- Prev by Date: Re: JTAG programing specs for XC18V01 PROM
- Next by Date: Re: Going from CLK1X to CLK2X.. really safe?
- Previous by thread: this JTAG thing is a joke
- Next by thread: Re: this JTAG thing is a joke
- Index(es):
Relevant Pages
|
