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

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

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

On Jul 5, 12:26 am, Alan Nishioka <a...@nishioka.com> wrote:
> On Jul 3, 2:03 pm, austin <aus...@xilinx.com> wrote:
>
> My next thought is I fried the chip in some weird way and I will try
> replacing it.
>
> Alan Nishioka- Hide quoted text -
>
> - Show quoted text -

its another try, sure.
I happen to own 3 dead FPGA boards with XC3S100E-TQ144 on them..
they are those "sample pack boards", think there is something badly
wrong with power supply on that board
so I managed to get all 3 boards to fry..

at least one of them was damaged in a way that FPGA was half dead, eg
can configure ok, but not all LUTS work

Antti

Alan,

Holding PROG_b low should hold the JTAG state machine in reset.

I did not check the V2P schematics, so maybe they did something different.

Austin

On Jul 3, 2:03 pm, austin <aus...@xilinx.com> wrote:
> INIT is not the signal that holds the JTAG block in reset, it is the
> PROG signal, or the power ON reset.
>
> So, if the core voltage AND the Vccaux AND the IO bank which has the
> config pins on it are all powered ON, AND if the PROG_b is not being
> intentionally held low, THEN the JTAG state machine should be released,
> and should operate.  Basically, when INIT goes high, the mode pins are
> sampled, and then based on the mode pins, the configuration state
> machine goes to whatever mode is specified, and proceeds with configuration.
>
> If JTAG is specified by the mode pins, then the part waits to be
> configured through the JTAG port.
>
> JTAG device ID can be read out prior to configuring (by any mode).
>
> Amazing what digging through the schematics reveals.
>
> Austin

I tried tying PROG_B to gnd on my working virtex-2p board, and
identify works fine (JTAG reads device id okay).

Is there any reason to expect spartan-3e to behave differently from
virtex-2p in this respect?

I also tried using a bench power supply for vint (in case my on board
supply was bad), but this made no difference.

My next thought is I fried the chip in some weird way and I will try
replacing it.

Alan Nishioka

On Jul 3, 1:54 pm, "Tim (one of many)"
<t...@nooospam.roockyloogic.com> wrote:
> Alan Nishioka wrote:
> > I have tried changing the mode pins (difficult because they are
> > connected directly to V33 and gnd) to no effect.  But JTAG should work
> > regardless of the mode pin settings, right?
>
> Yes, JTAG works in all modes. And maybe you have the mode pins set to
> salve serial. Or even floating, which means that the default pullups
> pull them to slave serial, depending on the HSWAP pin.
>
> What I was suggesting is that you try programming the part in slave
> serial mode. That could show up any one of a host of problems. If slave
> serial works and JTAG doesn't...
>
> Good luck.


Thank you all for your ideas.  I now have a few more things to try.

Alan Nishioka

Alan,

INIT is not the signal that holds the JTAG block in reset, it is the 
PROG signal, or the power ON reset.

So, if the core voltage AND the Vccaux AND the IO bank which has the 
config pins on it are all powered ON, AND if the PROG_b is not being 
intentionally held low, THEN the JTAG state machine should be released, 
and should operate.  Basically, when INIT goes high, the mode pins are 
sampled, and then based on the mode pins, the configuration state 
machine goes to whatever mode is specified, and proceeds with configuration.

If JTAG is specified by the mode pins, then the part waits to be 
configured through the JTAG port.

JTAG device ID can be read out prior to configuring (by any mode).

Amazing what digging through the schematics reveals.

Austin

Alan Nishioka wrote:
> I have tried changing the mode pins (difficult because they are
> connected directly to V33 and gnd) to no effect.  But JTAG should work
> regardless of the mode pin settings, right?

Yes, JTAG works in all modes. And maybe you have the mode pins set to 
salve serial. Or even floating, which means that the default pullups 
pull them to slave serial, depending on the HSWAP pin.

What I was suggesting is that you try programming the part in slave 
serial mode. That could show up any one of a host of problems. If slave 
serial works and JTAG doesn't...

Good luck.