spartan-3e idcode

Hi all,

       I've recently built a prototype board using a xilinx xc3s250e-
ft256. The idcode read back through jtag is not recognized and has a
different manufacturer, i believe it to be corrupt. The code is
0x000c1003. This is very much unlike the 0x0000000000 problems i
usually have. This happens using xilinx impact, digilent export, and a
custom program i wrote to try and debug this. I've looked at all the
signals on my scope and they seem to be in great shape. In my custom
software i have an idcode looping function and the chip returns this
number millions of times with out error. What could this possible be?

Thanks

jonpry@gmail.com wrote:
> Hi all,

>        I've recently built a prototype board using a xilinx xc3s250e-
> ft256. The idcode read back through jtag is not recognized and has a
> different manufacturer, i believe it to be corrupt. The code is
> 0x000c1003. This is very much unlike the 0x0000000000 problems i
> usually have. This happens using xilinx impact, digilent export, and a
> custom program i wrote to try and debug this. I've looked at all the
> signals on my scope and they seem to be in great shape. In my custom
> software i have an idcode looping function and the chip returns this
> number millions of times with out error. What could this possible be?

Look with a scope if the 0x000c1003 is something real. Check for 
ringing on the sck line.

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

On Jul 14, 3:51 pm, jon...@gmail.com wrote:
>        I've recently built a prototype board using a xilinx xc3s250e-
> ft256. The idcode read back through jtag is not recognized and has a
> different manufacturer, i believe it to be corrupt. The code is
> 0x000c1003. This is very much unlike the 0x0000000000 problems i
> usually have. This happens using xilinx impact, digilent export, and a
> custom program i wrote to try and debug this. I've looked at all the
> signals on my scope and they seem to be in great shape. In my custom
> software i have an idcode looping function and the chip returns this
> number millions of times with out error. What could this possible be?


I recently had a problem with my Spartan-3e design and my programming
setup that has worked for years.  Here is the thread:
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/b56a80c653060e70/

I finally got it to work by using a platform usb cable instead of a
parallel III cable.
I have not had the time to investigate why one works and the other
doesn't.

Alan Nishioka
alan@nishioka.com

All,

The Parallel III cable was built before we had JTAG that had its Vcco 
lowered to 2.5V, and a whole slew of features added ...

http://direct.xilinx.com/bvdocs/userguides/ug332.pdf

Figure 9-1, has a good schematic of what is going on:  input pins 
require series resistors, as they all use 2.5 V as their internal Vdd, 
output is optionally able to pullup (to Vccaux), see XAPP453.  Also note 
Table 2-9 in the above referenced document, specifically what the TMSPIN 
does (enables, disables pullup to Vccaux internally).

So, may an older parallel III cable work?:  yes, but, you need to have 
the series resistors on input, and you need to address the TDO output, 
by either setting the TMSPIN to the right state, or providing an 
external pullup on TDO.

The newer cables are 'smart' enough to figure out what to do, even 
though there may be settings that are enabling/disabling pullups.

Austin

I am not totally sure if the 0x000c1003 is what is being sent by the
fpga. I don't have a logic analyzer so its hard to tell when the
bitstream starts. On my scope it looks like this:

----------        --      ---              ----------------
          -------   ------   --------------

Which does not exactly correspond 11000001000000000011. I'm not sure
what the id should be and if there is any correlation between what is
read and the correct value.

My scope is only 100mhz, but the edges look really sharp to me. I
doubt the jtag circuits are fast enough to respond to anything above
this speed.

I was using a home made parallel 3. I know people have tons of trouble
with these, but the data going in/out seems to be really clean. Just
in case, i hooked my board into the jtag chain of digilent nexsys
board with a spartan-3e on it. It also has a integrated usb
programmer. My device was shown in the chain with the same garbage id
i see on my parallel 3. When trying to program the other devices, it
fails, leading me to believe the device cannot enter bypass mode.

Is there some combination of tdo,tdi,tms,tck that could be shorted
togeather to cause this? Are these kinds of things symptomatic of a
bad chip. I've also noticied some strange behavior on the
configuration port. The chip is setup to configure over SPI. CCLK is
going, but cso_b never goes low, and mosi never toggles. I've checked
the connections a thousand times.

On Jul 15, 8:44 am, austin <aus...@xilinx.com> wrote:
> All,
>
> The Parallel III cable was built before we had JTAG that had its Vcco
> lowered to 2.5V, and a whole slew of features added ...
>
> http://direct.xilinx.com/bvdocs/userguides/ug332.pdf
>
> Figure 9-1, has a good schematic of what is going on:  input pins
> require series resistors, as they all use 2.5 V as their internal Vdd,
> output is optionally able to pullup (to Vccaux), see XAPP453.  Also note
> Table 2-9 in the above referenced document, specifically what the TMSPIN
> does (enables, disables pullup to Vccaux internally).
>
> So, may an older parallel III cable work?:  yes, but, you need to have
> the series resistors on input, and you need to address the TDO output,
> by either setting the TMSPIN to the right state, or providing an
> external pullup on TDO.
>
> The newer cables are 'smart' enough to figure out what to do, even
> though there may be settings that are enabling/disabling pullups.
>
> Austin


So are you saying the parallel cable III output is 3.3V?

I thought it had a CMOS buffer inside, powered by the red vcc line
(2.5V in my case).  Also it has 100ohm series resistors and a TDO
pullup.

I finally found a schematic
http://www.xilinx.com/support/programr/files/0380507.pdf

Alan Nishioka

On Jul 15, 12:52 pm, Alan Nishioka <a...@nishioka.com> wrote:
> On Jul 15, 8:44 am, austin <aus...@xilinx.com> wrote:
>
>
>
> > All,
>
> > The Parallel III cable was built before we had JTAG that had its Vcco
> > lowered to 2.5V, and a whole slew of features added ...
>
> >http://direct.xilinx.com/bvdocs/userguides/ug332.pdf
>
> > Figure 9-1, has a good schematic of what is going on:  input pins
> > require series resistors, as they all use 2.5 V as their internal Vdd,
> > output is optionally able to pullup (to Vccaux), see XAPP453.  Also note
> > Table 2-9 in the above referenced document, specifically what the TMSPIN
> > does (enables, disables pullup to Vccaux internally).
>
> > So, may an older parallel III cable work?:  yes, but, you need to have
> > the series resistors on input, and you need to address the TDO output,
> > by either setting the TMSPIN to the right state, or providing an
> > external pullup on TDO.
>
> > The newer cables are 'smart' enough to figure out what to do, even
> > though there may be settings that are enabling/disabling pullups.
>
> > Austin
>
> So are you saying the parallel cable III output is 3.3V?
>
> I thought it had a CMOS buffer inside, powered by the red vcc line
> (2.5V in my case).  Also it has 100ohm series resistors and a TDO
> pullup.
>
> I finally found a schematichttp://www.xilinx.com/support/programr/files/0380507.pdf
>
> Alan Nishioka

I hooked my parallel-3's vcc to 3.3v so it's output would be high
enough for my pc to read. Then i put 100ohm resistors on all the lines
to the fpga. Xilinx only says 68 ohms are necessary as per the
document suggested by austin. I've had good luck with my parallel-3.
I think the key is using 74hc parts. Next is having a computer that
happens to have low thresholds :-)

Alan,

The 74hc125 is powered from the connections... or is it?

VDD is not VCC, and connection to pin 14 is not shown...

Again, the 2.5 V inputs on 3SE will clamp a 3.3V output (to one diode 
drop above 2.5V), and you should know what the TDO is set to do (pullup, 
or not).

Lots of people have problems with the older cables, and the newer parts.

There is the issues I mentioned, and then there is cable length (from 
some to a lot), as well as how the pcb was wired to the JTAG header.

I have seen cases where there was a LED directly on some wires to 
ground, or to Vcc(?).  These LED's 'worked" for old parts, but clearly 
made the interface not work at all on the newer 2.5V parts.

Last but not least, we have seen issues with the green wire safety 
ground for the computer, with 3V of AC, making the interface really 
confused.  Can't happen on a laptop, however (if it isn't plugged into 
the wall).

Just relaying what I see....

Austin

On Jul 15, 12:49 pm, jon...@gmail.com wrote:
> My scope is only 100mhz, but the edges look really sharp to me. I
> doubt the jtag circuits are fast enough to respond to anything above
> this speed.

This has come up before regarding xilinx jtag circuits.  Because they
are all part of the same chip, the jtag circuit is just as fast as any
other part of the chip.  So high speed transitions *could* still be a
problem.


> I was using a home made parallel 3. I know people have tons of trouble
> with these, but the data going in/out seems to be really clean. Just
> in case, i hooked my board into the jtag chain of digilent nexsys
> board with a spartan-3e on it. It also has a integrated usb
> programmer. My device was shown in the chain with the same garbage id
> i see on my parallel 3. When trying to program the other devices, it
> fails, leading me to believe the device cannot enter bypass mode.

Can't you borrow a Platform USB jtag cable?

Have you tried using debug mode in impact?  It allows you to step
through the jtag state machine, and do things like enter bypass mode
manually.  It even has a nice graphical depiction of the state
machine.

On the other hand, it didn't help me with my problem, but your mileage
may vary.


> The chip is setup to configure over SPI. CCLK is
> going, but cso_b never goes low, and mosi never toggles.

I thought my mode pins might be causing in a problem, but in the end,
they had no effect.


> I've checked the connections a thousand times.

Been there, done that.

Alan Nishioka

I got sick of using the impact debug chain and wrote my own software
so i could step through the commands in the debugger instead of typing
them in one at a time. TDO only clocks when i send a clock which makes
me think it is not ringing on tclk. Also, determining the scan chain
length would probably fail with bad tclk, as it would report lengths
not multiples of 32 bits.

I don't have a platform usb cable, but as i said i hooked my board
into the scan chain of a working spartan-3 board, which has onboard
usb programming and it does the same stuff.

I decided to desolder the fpga and put another one on. It looks like
the pins in the center of the bga were not completely melted. Is it
possible this is caused by inadequate ground?

Alan has suggest HSWAP as a potential problem. However, there is data
on TDO, if there was a missing pullup, wouldn't TDO be zero all the
time?

Thank