Spartan6 PCB debugging: how badly do you have to screw up for JTAG to not shift?

I'm troubleshooting the first rev of my first Spartan 6 PCB design; this is sort of a learn-by-making-all-the-mistakes process, but I could sure use a hint or two here from the gurus.

Obviously there are a million things that can lead to a board not coming up, but my understanding is that very few things can lead to the situation where the JTAG interface won't even shift (i.e. TDO stuck at zero).

For example, the JTAG interface doesn't rely on any of the clock inputs, nor the I/O banks. Basically, if Vcore (1.2v) and Vccaux (3.3v) are supplied, and there are no shorts, then the JTAG ought to work, right? Even mis-configured mode pins (M0, M1) shouldn't affect this.

Designing a good power distribution network (bypass caps) is tricky, but even getting that wrong shouldn't matter for something running at the JTAG TCK rate (dozens of khz), right? FWIW, I tried the board without any of the bypass caps -- nothing soldered down but the two voltage regulators and the Spartan chip -- still no luck.

Current draw is around 11mA from the 6V supply, so I doubt there's a short. I think that sounds right for an unconfigured device with no pins toggling, right? I'm only powering one of the four I/O banks (same supply as Vccaux); the others are unconnected.

Thanks for any ideas or suggestions or ideas on what to try next (or pointers on which M to RTF)!

(PS: this board doesn't use any high speed I/Os or anything fancy like that.. in fact, unbelievably, the design clock input is the *only* user I/O pin! All communication with the device is via BSCAN_SPARTAN6. For that reason and others this is probably the simplest Spartan6 board ever designed, which is the only reason I attempted it!)

Reply to
karl schrunk
Loading thread data ...

Correct.

Correct.

Depending on your JTAG cable, it's probably clocking in the range 1MHz to 33MHz. Signal integrity does matter for JTAG, but it should be easy to make it good enough - use serial termination resistors of 30-60 ohms at the sources and make sure that the traces are never very far away from a ground plane.

For a small Spartan 6 that sounds right.

That's your show stopper. Don't ever leave ground or power pins unconnected unless the data sheet specifically tells you to do so.

If you can, hook up your Vccaux supply to the unconnected banks. Should solve the problem.

One thing I always do when bringing up a new board: assemble two or three of them, minimum. When you see something unexpected, test to see if it affects all three boards in the same way - that way you can tell whether it's a design problem or just dodgy soldering on one board.

Another suggestion is to buy an off the shelf development board that uses the same FPGA so that you have a known working system to compare with. If you're using Spartan 6 LX4 or LX9 you'll find some very affordable ones here:

formatting link

Best regards, Stephen

Stephen Ecob Silicon On Inspiration Sydney Australia

formatting link

Reply to
Steve

Hi Stephen, thanks so much for taking the time to reply...

Hrm, I only did that because page 32 of UG393 seemed to say that it was okay to:

"In some cases, one or more I/O banks in an FPGA are not used (for example, when an FPGA has far more I/O pins than the design requires). In these cases, it might be desirable to leave the bank=92s associated VCCO pins unconnected, as it can free up some PCB layout constraints (less voiding of power and ground planes from via antipads, less obstacles to signals entering and exiting the pinout array, more copper area available for other planelets in the otherwise used plane layer)."

Clearly in an ideal world I should have spent the time wiring up those pins. But in light of the paragraph above, I'm a bit hesitant to bet a week and a board order on this being the problem... unless I've misread it, which is absolutely possible. Have I?

33MHz

I tried forcing the clock rate to 2400 hz (no, that's not a typo) in urjtag; still all zeroes on TDO.

It's an LX25, so it's sort of middle-size.

Reply to
karl schrunk

You're right, UG393 says that it's okay to leave unused VCCO pins unconnected. Sorry for steering you wrong there.

33MHz

How are you converting the 6V down to 3.3V and 1.2V ? Have you checked that these supply rails aren't noisy ?

I'm happy to take a quick look if you want to send me your schematic offline.

Best regards, Stephen

Stephen Ecob Silicon On Inspiration Sydney Australia

formatting link

Reply to
Steve

In a hand soldered engineering design, bad contacts or shorts in the JTAG chain can be common...

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

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Reply to
Uwe Bonnes

What's also common is for the JTAG to be connected incorrectly. Assuming th= is is the only device in the chain, TDI of the programmer goes to TDI of th= e FPGA, _not_ TDO. Then, obviously, TDO of the programmer goes to TDO, _not= _ TDI.=20

As someone else already stated, make sure you have some series termination = resistors (roughly 33ohm) in place. Put them as close as practical to the d= riving pin. That would be near the TDI, TCK, and TMS pins of the JTAG conne= ctor and TDO pin of the FPGA. Signal integrity is not dependent on the freq= uency of your signal, it's dependent on the edge rate. You could have signa= l integrity issues even at your 2400Hz.

Also make sure that you supply ground and a reference voltage to the progra= mmer. Make sure you have all the required pull ups and downs on the JTAG si= gnals.

Look at the JTAG signals on a scope and make sure that the edges look clean= . Look at TDO coming out of the FPGA to see if it really is low all the tim= e. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can ex= ercise the lines.=20

-- Marc

Reply to
Marc Guardiani

is the only device in the chain, TDI of the programmer goes to TDI of the FPGA, _not_ TDO. Then, obviously, TDO of the programmer goes to TDO, _not_ TDI.

resistors (roughly 33ohm) in place. Put them as close as practical to the driving pin. That would be near the TDI, TCK, and TMS pins of the JTAG connector and TDO pin of the FPGA. Signal integrity is not dependent on the frequency of your signal, it's dependent on the edge rate. You could have signal integrity issues even at your 2400Hz.

programmer. Make sure you have all the required pull ups and downs on the JTAG signals.

Look at TDO coming out of the FPGA to see if it really is low all the time. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can exercise the lines.

In case it didn't already get mentioned, the PROG_B pin of Xilinx FPGA's is a sort of master reset and it *does* affect JTAG operation. This pin should be pulled up.

-- Gabor

Reply to
Gabor

Yikes, I left it unconnected.

Double yikes: I found block of ground pins that were not connected (due to the strangely-arranged Eagle schematic symbol I'm using). That's obviously a gigantic mistake, although I'd still expect all the GNDs to be internally connected by the fill on the upper metal layers, so I'm still not sure if this explains the JTAG problems, but it certainly must be fixed!

Between that and Stephen (and other's) recommendations about terminating the JTAG bus (which I didn't do) and the fact that I only have one board right now, I think I've got enough possible solutions for it to be worth another run of boards (four this time in case I screw one up like I did with the last batch). I'll also bring out more of the pins so I can probe them this time.

I'll report back in a week or so.

Thank you all so much for your help! I really didn't expect such a great response. You guys are awesome.

- k

Reply to
karl schrunk

Hi Karl,

Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration". p48 shows the basic connections for JTAG (ignore the BPI Flash). The

4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done are important - only connect those three pins differently if you have a good reason and know what you're doing. Ch3 also covers JTAG and is worth a read.

Have fun!

Stephen Ecob Silicon On Inspiration Sydney Australia

formatting link

Reply to
Steve

I know I have seen a FPGA checklist to walk through before you manufacture your circuit. At least Altera has one.

Reply to
Morten Leikvoll

Oh yeah, definitely went over that. I was kind of disappointed though that they gave sample circuit diagrams for every configuration mode

*except* JTAG. Oh well.

Is it okay to use the internal pullups for those (by typing HSWAPEN to GND)?

Reply to
karl schrunk

I strongly advise against it. Resistors cost about one tenth of a cent, I can't think of a reason to leave them out. Built in pullups are quite weak, roughly equivalent to something like 50K ohms. The pins we're talking about need to have pullups stronger than that. Have a read of this:

formatting link

Regards, Stephen

Stephen Ecob Silicon On Inspiration Sydney Australia

formatting link

Reply to
Steve

ne

,

Well, board space is a reason -- I'm awful at soldering SMT components, and a through-hole resistor is a big chunk of real estate.

But it isn't a good reason. I'll put in the discrete pull-ups.

Wow, thanks for that link, that explains a lot. They ought to mention the internal-resistor-is-only-for-slow-CCLKs rationale in the configuration guide.

Reply to
karl schrunk

You may also want to read through the config guide again. HSWAPEN does not affect all pins. Some dedicated pins are always pulled up, some others are always tristated. DONE is probably the only pin you an get away without pulling up, but only if you set the bitgen configuration to "drive DONE high".

-- Gabor

Reply to
Gabor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.