spartan-3e idcode

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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


Re: spartan-3e idcode
Quoted text here. Click to load it


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

--
Uwe Bonnes                 snipped-for-privacy@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
We've slightly trimmed the long signature. Click to see the full one.
Re: spartan-3e idcode
Quoted text here. Click to load it


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
snipped-for-privacy@nishioka.com


Re: spartan-3e idcode
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


Re: spartan-3e idcode
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.



Re: spartan-3e idcode
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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


Quoted text here. Click to load it

Been there, done that.

Alan Nishioka


Re: spartan-3e idcode
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


Re: spartan-3e idcode
Quoted text here. Click to load it

In my case, part of the JTAG state machine worked fine.  I was able to
put it into bypass and see bits go in and out, so I assumed all of
JTAG was good and something else was bad.

I was wrong.

Thinking about it more, I figure whoever designed the Spartan-3e
didn't design the JTAG block.  He just dropped in an existing ip block
and added a block with Spartan specific stuff to it.  So it is
possible for part of the JTAG state machine to work while another part
is more touchy about signals.


Quoted text here. Click to load it

The more cables you try the better.  I still think you should beg/
borrow/steal a platform usb cable (but perhaps I am blinded by the
fact it worked for me).


Quoted text here. Click to load it

That wasn't me and I don't think HSWAP is a probable problem.  In my
case I messed with it to no effect.

Alan Nishioka


Re: spartan-3e idcode
Alan

"> Thinking about it more, I figure whoever designed the Spartan-3e
Quoted text here. Click to load it

That is not how it is done around here.  JTAG is a standard, and it has
requirements that must be met, in order for the product to be qualified
(offered for sale).

The team that is responsible for the configuration block of the device,
is also responsible for the JTAG.  That team MUST meet the standard, as
the part will be checked by an outside contractor to insure that it was
done right.

The JTAG (along with all other configuration interfaces) is not only
checked by IC Design, is checked by: production test, the "storage
solutions team" (the eeproms and other bitstream storage devices), the
ISE promgen, bitgen, and all the software tools folks, and the
programming cables development team.

The interface to the block is through one, and only one design for input
and output: the IOB.  These being dedicated pins just means that a lot
of the programmable options are hardwired (who has the time to make a
new input pin, and a new output pin? and then prove it is 'correct?').

Please do not insult the designers:  sure they make mistakes, but when
they do, we issue errata.

http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=-1211408&sGlobalNavPick=SUPPORT&sSecondaryNavPick =
(3SE errata -- NONE)

Austin

Re: spartan-3e idcode
Quoted text here. Click to load it


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


Re: spartan-3e idcode
Quoted text here. Click to load it
schematichttp://www.xilinx.com/support/programr/files/0380507.pdf
Quoted text here. Click to load it

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


Re: spartan-3e idcode
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

Site Timeline