Spartan6 PCB debugging: how badly do you have to screw up fo

[karl schrunk]

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

 

[Steve]

Hi Karl,

On 08/18/2011 01:53 PM, karl schrunk wrote:

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

Correct.

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.

Correct.

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.

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.

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?

For a small Spartan 6 that sounds right.

I'm only powering one of the four I/O banks
(same supply as Vccaux); the others are unconnected.

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.

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

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:

www.sioi.com.au/shop/

Best regards,
Stephen


Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au

 

[Steve]

On 08/18/2011 05:11 PM, karl schrunk wrote:

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


I'm only powering one of the four I/O banks
(same supply as Vccaux); the others are unconnected.

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

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’s 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?

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

Depending on your JTAG cable, it's probably clocking in the range 1MHz to 33MHz

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


Current draw is around 11mA from the 6V supply

For a small Spartan 6 that sounds right.

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

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
www.sioi.com.au

 

[karl schrunk]

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

I'm only powering one of the four I/O banks
(same supply as Vccaux); the others are unconnected.

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

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’s 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?

Depending on your JTAG cable, it's probably clocking in the range 1MHz to 33MHz

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

Current draw is around 11mA from the 6V supply

For a small Spartan 6 that sounds right.

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

 

[Uwe Bonnes]

karl schrunk <karlschrunk@gmail.com> wrote:

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

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

 

[Marc Guardiani]

On Thursday, August 18, 2011 5:18:07 AM UTC-4, Uwe Bonnes wrote:

karl schrunk <karls...@gmail.com> wrote:
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).

In a hand soldered engineering design, bad contacts or shorts in the JTAG
chain can be common...
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de

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

What's also common is for the JTAG to be connected incorrectly. Assuming this 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.

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

Also make sure that you supply ground and a reference voltage to the programmer. Make sure you have all the required pull ups and downs on the JTAG signals.

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 time. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can exercise the lines.

-- Marc

 

[Gabor]

Marc Guardiani wrote:

On Thursday, August 18, 2011 5:18:07 AM UTC-4, Uwe Bonnes wrote:
karl schrunk <karls...@gmail.com> wrote:
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).
In a hand soldered engineering design, bad contacts or shorts in the JTAG
chain can be common...
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de

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

What's also common is for the JTAG to be connected incorrectly. Assuming this 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.

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

Also make sure that you supply ground and a reference voltage to the programmer. Make sure you have all the required pull ups and downs on the JTAG signals.

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 time. IIRC, Xilinx has a debug mode for the JTAG programmer so that you can exercise the lines.

-- Marc

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

 

[karl schrunk]

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.

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

 

[Steve]

On 08/19/2011 09:25 AM, karl schrunk wrote:

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.

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.

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
www.sioi.com.au

 

[Morten Leikvoll]

"karl schrunk" <karlschrunk@gmail.com> wrote in message
news:c2a98d3d-418e-4b62-ae24-8bd77be36da0@p37g2000prp.googlegroups.com...

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!

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

 

[karl schrunk]

On Aug 18, 7:35 pm, Steve <theecobs@gmail.com> wrote:

Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration".
Ch3 also covers JTAG and is worth a read.

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.

The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done

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

 

[Steve]

On 08/19/2011 05:59 PM, karl schrunk wrote:

On Aug 18, 7:35 pm, Steve<theecobs@gmail.com> wrote:
Do take a look at Xilinx document UG380 "Spartan-6 FPGA Configuration".
Ch3 also covers JTAG and is worth a read.

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.

The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done

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

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:

http://www.xilinx.com/support/answers/35002.htm

Regards,
Stephen


Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au

 

[karl schrunk]

On Aug 19, 11:25 pm, Steve <theec...@gmail.com> wrote:

The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done

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

I strongly advise against it.  Resistors cost about one tenth of a cent,
I can't think of a reason to leave them out.

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.

http://www.xilinx.com/support/answers/35002.htm

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.

 

[Gabor]

karl schrunk wrote:

On Aug 19, 11:25 pm, Steve <theec...@gmail.com> wrote:
The 4K7 pullups for PROGRAM_B and INIT_B plus the 330 ohm pullup on Done
Is it okay to use the internal pullups for those (by typing HSWAPEN to
GND)?
I strongly advise against it. Resistors cost about one tenth of a cent,
I can't think of a reason to leave them out.

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.


http://www.xilinx.com/support/answers/35002.htm

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.

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