100m JTAG cable

jvdh wrote

Could you switch to using a USB cable, extended via off-the-shelf fiber optic USB extenders?

I like the (off the shelf) simplicity of your suggeston :)

The way I see it, the main options would be changing the medium (esp to fibre), or slowing the comms down - the later would probably be preferable from a cost point of view...

But I'm first trying to confirm that it definitely is the transmission delay that's messing me around.

Thanks!

Tim wrote:

Isn't there an option to set the JTAG CLK speed in impact?

Another option beside the USB Extender is to convert the levels to a RS422/485 signal and use a twisted pair cable.

Can you clarify hazardous - is this electrically noisy, or soemthing else. If it is electrically noisy, RS485 may not be enough.

You could create a deliberate bench-delay, ( schmitt buffers and RC elements ) and see if that is ok in your lab. It should also let you test various download software's delay tolerances.

- that helps isolate delay effects from other noise effects.

You may need an isolated link system, RS485 has finite common mode limits - but isolation will add to your delay budget...

I think analog devices have some high speed isolators ?

-jg

Jim Granville wrote: ...

I use the ADUM1401 for that task, in connection with SPI transfers. Jtag shouldn't be too different.

Uwe:

The speed setting in impact apparently doesn't apply to my Parallel Cable 3.

This is exactly what i'm doing, with an RS485 driver and receiver on each end of my cable. I'm getting 230kbps on the system for serial communication:), but I think my transmission delay is too large for Impact to be happy. I measured the duration of a clock pulse to be as little as 1us - with a delay of 800ns, the reading of data fails.

Jim: Hazardous as in high energy particles, especially protons and neutrons. The board will be used to test radiation tolerance techniques, but background radiation is too high to put a PC nearby for control. (and want to use it afterwards:) It is inside a faraday cage, so even very high speed wireless options are also out.

I'm using a differential line pair for every input signal - the R485 is only used as a repeater and receiver pair, with no other 485 protocol on top of it.

Right now I'm looking into the open source options, hoping I can do (slower) readback with openwince-jtag.

thank you!

jvdh ( snipped-for-privacy@gmail.com) wrote: : This might be slightly OT for an FPGA group, but maybe someone has run : into a similar problem before:

: I'd like to connect my FPGA, via JTAG, to my PC, 100m away. Due to a : hazardous environment, putting the PC any closer isn't feasible

One approach, nicely agnostic to the deviecs and manifactuers etc, would be to extend the physical JTAG signals with fibre transcievers. I guess that doesn't work for Vref directly... :-)

Assuming fibres aren't killed by the radiation...

The FTDI FT2232 happily generates serial protocols. I have a modified version of Andrew Rogers's xc3sprog thats talks JTAG to XC3S and XCF via FT2232. It knows about JTAG speed. Let me know if you are interested (and willing to give feedback).

Uwe Bonnes schrieb:

I guess the point is, that the OP want a quick & dirty solution, wich is most probably not possible due to the high delay of 100m cable (which is ~500ns). Even optical fiber would be that slow.

Regards Falk

I'd ask Xilinx about this. What you are trying to do may be specialised, but this ability to tolerate slower links has quite widespread applications - for example, opto isolated JTAG could have similar delays. It sounds like an easy thing to fix, if you can get at the right place in the software :)

any large magentic fields ? - I think you may still need isolation, as the common mode tolerance of RS485 is only around -7V/+12V - which is not a large spike....

That may be the best path.

-jg

Not whre I'm working - I'm staying relatively far away from the actual beam line, and a previous experiment we had (without the JTAG) didn't show significant magnetic effects.

Uwe Bonnes schreib:

Thanks for reminding me of x3sprog - I had used it a while ago, but couldn't define a narrow enough search to find it on google again, until you gave me the name now.

But, I've now downloaded it again, and it happily identifies the JTAG chain and handles the downloading of data. (so I'm feeling GOOD right now).

Next problem: Readback. The whole purpose behind JTAG is to get the configuration data back to the computer, to check what's going on... And x3sprog doesn't support readback.

This modified version of yours doesn't perhaps have readback implemented?

Otherwise I can see myself spending tonight extending either x3sprog to do readback, or openwince-jtag (to support my programmer)... (Or disguising my jtag3 cable as a parallel 3 cable)

Thanks for everybody's suggestions and support!

If you implement readback, let me know :-)

Another obscure idea. It seems you run on linux. Impact via windriver uses /dev/parport to access the parallel port. Define inp() and outport() with an appropriate delay function, recompile and reload the module to get slower jtag access. Perhaps even make the delay configurable via /proc/sys/dev/parport/parport0/ :-)

It might be obscure, it might be late, but it's attractive in a deliciously perverse way... :) Although I fear it might fail if the delay is specified inside impact - they have the frequency setting for the other programmers, so I don't think they are merely depending on the delays in windriver??? (I dream of the day when an FPGA manufacturer decides to put their software on sourceforge...)

Looking through the x3sprog code, it seems (touching wood, making sure that I'm not discharging static electricity onto a sensitive CMOS device) relatively simple to add the readback code. I've also spent a fair amount of time on getting to know the configuration interface of Spartan 3, so I'm a happy coder right now!

Will keep you up to date...

johannes

'All' FPGA software could have issues, but yes, there IS a strong case for placing this level of software on sourceforge.

It has very low risk exposure, no trade secrets ( it is a transport layer only ), but has good benefits : More users can deploy their FPGAs in areas they have not thought of - and THAT has to be good for business! That means the designer community can do slower, (and faster!), JTAG variants.

Austin ? - or anyone in Xilinx willing to shake the tree a little ?

-jg

Jim,

Been down that road (making any software source public). Nope. Dead end. I have more useful things to attend to right now.

There are already many vendors that support JTAG, and the BSDL files are their for them (or you). Feel free to buy and use their software instead of ours. I am sure it can be made better than ours, and provide more features than ours does.

I would not want to appear to be competing with these vendors, nor making their business any less profitable.

Austin

Thanks, Sounds like that may be viable for programming (and is what the OP is now doing), but what about the Logic analyzer/probe tools, don't they use JTAG pathways ? Or do they also work fine, with anyones JTAG system ?

-jg

What about a USB programming cable and some USB CAT5 extender modules?

I am not sure if they go up to 100m though, might only do 50m.

Another possibility would be to use a (potentially) 'sacrificial' PC to talk JTAG from CableServer and control it from your workstation over ethernet.

(As I read further into the thread.. maybe one in a farking big lead box :)

AFAIK the Parallel III is locked at 200kHz.

There is already a XC3SPROG project on sourceforge, but with no code yet.

End of June Eric(?) told that he had not had time yet to put something into the project he put on sourceforeg. Hopefully things change.

Austin Lesea schrieb:

Hi Austin,

I partially agree - making something open-source doesnt necessarily improve anything.

But having programming-jtag cable driver support done properly should not be of very low importance for Xilinx. If people are frustrated with the JTAG cables and drivers and programming software, then it of course has influence on later decisions.

Cable IV did never get proper support and as legacy will never get. So only official cable is USB Cable. And this cable is not accesible for the users any more at all. So no wonder a replacement firmware and CPLD code for it has already been made public (under GPL).

Xilinx is big enough company to hire people good enough to master the low level driver programming. But no, Xilinx is still using the 'cheap solution' and has the jungo-windriver stuff inbetween. Its not so complicated todo it properly without jungo stuff.

To my understanding jungo is only good for small-medium companies that need to get something working fast and cant afford to hire programmers capable to write to good quality OS hardware drivers.

And no, I am not looking for that job. But I know the driver internals. My last commercial driver was Teletext kernel mode driver for some early windows (286 based machine?) - the board had an XC3030 on it. The driver programming is way simpler now and not so cirit=EDcal has PC horsepower is increased a lot. So not so impossible for a company like Xilinx to get it done properly. But no, the Cable IV still works in Cable III compat mode on most PCs I have seen. For no understandable reason and no solution.

Antti