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

On Jul 5, 8:30 pm, austin <aus...@xilinx.com> wrote:
> 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

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

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
(http://www.siphec.com/) 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" <alan@nishioka.com> schrieb im Newsbeitrag
news:1183660087.898569.64290@d30g2000prg.googlegroups.com...
> I have figured it out.  (well part of it)
> I finally tried it with a Platform USB cable belonging to my Avnet
> FAE, and it WORKED!
>
> I had been using a Parallel Cable III (I guess I left that out).  I
> was certain that this would have no effect.
>
> I still can't explain why JTAG partially works, but won't read device
> id.
> I would love for someone to confirm this or explain it.
>
> My guess would be some sort of voltage incompatibility (But I was
> *sure* changing the cable would have no effect, so how good are my
> guesses?)
>
> Thank you to everyone for your suggestions.
> Alan Nishioka
>
>
> On Jul 3, 11:06 am, Alan Nishioka <a...@nishioka.com> wrote:
> > I am trying to get an xc3s250e-4tq144c to configure using JTAG.
> >
> > 1. impact reads 0x00000000 as idcode
> >     This causes impact to error out during identify with a strange
> > error about missing bsdl's
> > 2. JTAG works using impact debug mode.  I can put it in bypass and
> > also see the length of the instruction register.  I can see data
> > shifting in and out so I know JTAG works.
> > 3. Part markings are:
> > XC3250E
> > TQ144AGQ0601
> > D1392255A0
> > 4C
> > so it is a step 0 part.
> > 4.  I have tried impact 8.1.3 and 9.1
> > 5.  I get identical results with two pc boards.
> > 6.  Same software / computer / cable setup works fine with a virtex2p
> > design.
> > 7.  All power supplies look good. (1.2Vint, 2.5Vaux, 3.3Vio)
> > 8.  spartan-3e is the only part in the JTAG chain.
> >
> > I have tried removing all the parts except the spartan and power to
> > make sure nothing else was interfering with it.
> >
> > I have not made any progress with my Avnet FAE and Xilinx webcase so I
> > thought to try here.
> >
> > I have run out of things to try.  Does this look familiar to anyone?
> > Any ideas to try?
> >
> > Alan Nishioka
> > a...@nishioka.com
>
>