spartan-3e idcode

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

I recently had a problem with my Spartan-3e design and my programming setup that has worked for years. Here is the thread:

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

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

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.

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

Alan Nishioka

schematic

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

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.

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.

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

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

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.

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

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

Alan

"> Thinking about it more, I figure whoever designed the Spartan-3e

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.

Austin