Spartan-3e JTAG no device id

Alan,

I did bring up the 2.5 volt issue, but I guess you were chasing some other issue. Virtex 4, Spartan 3 (basically, everything since the first

90nm products) did change from 3.3 volts to 2.5 volts (3.3V compatible...) on the JTAG. It is the "compatible" that is not so easy: older programming cables, aren't.

Sorry you got bit by this. Glad to hear you did not have a toasted chip.

Austin

Reply to
austin
Loading thread data ...

Austin,

the Xilinx "Cable problem" is pretty much serious one. It bites again and again.

there are boards that can be programmer with USB cable or with Cable IV both not with both. there are boards that can be programmed using Impact 8.2 but not with Impact 9.1

the list is endless.

so in case of Xilinx JTAG trouble: check ALL your cables you can get hands on try different version of software. try impact try download with chipscope, etc..

there have been cases where chipscope can configure but impact cant, etc...

Antti

Reply to
Antti

Alan,

I am not sure whether my own experiences have anything to do with your case but here they are:

I had built me my own parallel-3 compatible jtag cable. Instead of 74HC125 (original) I used 74AHC125 buffers in the cable which should even perform better in the necessary level translation. With this cable I had programmed a lot of different Xilinx devices without any problem. Then came the day when I tried to program an XC3S400 with this cable with pretty much the same effect as you have noticed: Even reading the device idea failed.

The person who had developed the board with the XC3S400 on it

formatting link
had also an matching download cable to sell, developed by himself. I ordered one and see: This one worked. By looking at the pcb I could not find any big differences to my own circuit, thats why I contacted the developer to ask for his advice. When I told him about my experiences he explained that he had had pretty the same problem and that he has found an solution for it. However, as he said, while he has an solution for it , he has NOT an deeper understanding WHY it is an solution. The solution is to terminate the TCK line behind the 100 Ohm resistor with abt

560 Ohms to ground and it is important that this termination happens on the driving side of the cable and not on the fpga side. That's all. I included the termination and my cable worked like charme with the XC3S400. Weeks later he called me on the phone to tell me that he had found a second way to make it run: Putting 470 Ohm instead of 100 Ohm into all jtag lines had also given him a stable result.

So while I would not warrant for 100% it seems to be more a problem of clock conditioning than level translation. Clock conditioning in this case does not necessarily mean that the clock generated by the cable is by some means

*bad* and needs to be conditioned. It may also be possible (which I believe in) that the Spartan device can source/sink high amounts of current on its TDO output and/or generate high slew rates on this pin. Both of that could be the source of crosstalk happening on the cable which (when big enough) may be the cause for additional false edges appearing on the TCK line. Please note that this is an assumption and that it is not easy to verify. Even the few picofarads capacity of an scope's probe applied to an jtag pin may make an big difference alone when it comes to really fast signals.

Best regards Ulrich Bangert

"Alan Nishioka" schrieb im Newsbeitrag news: snipped-for-privacy@d30g2000prg.googlegroups.com...

Reply to
Ulrich Bangert

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.