Spartan changes in glitch sensitivity

[Jon Elson]

Hello, all, I know this refers to graveyard parts, but
we have reason to keep using them.

Anyway, I made a new batch of motherboards that use a 5 V Spartan
as the slot select control logic. I have made over 20 of these
before. i did a revision of the design, but this particular area
had no schematic change, and I really didn't move any traces,
either. I do have a case for bus reflections, as the bus is
16 inches long. The FPGA detects unoccupied card slots and jumps
serial config strings across the empty positions, and also has
some serial config registers on the FPGA. Well, this newest
version worked erratically, and after a couple days working with
it, I figured out reflections on the serial clock that goes to all
board slots plus the FPGA were double-clocking the FPGA. I patched
a series termination resistor on the output of the driver, and
the board now works perfectly.

So, what caused this change? I'm fairly sure the board layout is
not to blame. The older boards were made with 2003 Spartan
XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
chips, otherwise the same designation, and just purchased a few
weeks ago from Avnet. Could a more recent fab run at Xilinx
have been made with significantly different speeds in the I/O?
Of course, this COULD just be a circuit that was so close to the
edge that I've just been really lucky, but I did make 20+ of these
with no sign of this problem before.

(This is a 6-layer board, always made at the same board house.)

Jon

 

[glen herrmannsfeldt]

Jon Elson <elson@pico-systems.com> wrote:

Anyway, I made a new batch of motherboards that use a 5 V Spartan
as the slot select control logic. I have made over 20 of these
before. i did a revision of the design, but this particular area
had no schematic change, and I really didn't move any traces,
either. I do have a case for bus reflections, as the bus is
16 inches long.
(snip)
version worked erratically, and after a couple days working with
it, I figured out reflections on the serial clock that goes to all
board slots plus the FPGA were double-clocking the FPGA. I patched
a series termination resistor on the output of the driver, and
the board now works perfectly.

I don't know any specifics about the chips, but certainly faster
switching outputs could cause reflection problems. Series
termination is often needed on lines much shorter than 16in.
With a dielectric constant of about 2.5, that is in the 4ns to 5ns
range, which is easily slow enough to double clock those.

So, what caused this change? I'm fairly sure the board layout is
not to blame. The older boards were made with 2003 Spartan
XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
chips, otherwise the same designation, and just purchased a few
weeks ago from Avnet.

-- glen

 

[Jim Granville]

On Oct 13, 5:26 pm, Jon Elson <el...@pico-systems.com> wrote:

 Could a more recent fab run at Xilinx
have been made with significantly different speeds in the I/O?

It does not need to be 'significantly' in absolute terms, just enough
to trigger the problem

You can build a ring oscillator test cell, to check the raw MHz of
the silicon, and see if that differs by much.

I think Xilinx parts had a small hystereis, so maybe that varied ?
6 years is a reasonable time too, so the exact same fab line is
unlikely to have been used.
-jg

 

[RCIngham]

Hello, all, I know this refers to graveyard parts, but
we have reason to keep using them.

Anyway, I made a new batch of motherboards that use a 5 V Spartan
as the slot select control logic. I have made over 20 of these
before. i did a revision of the design, but this particular area
had no schematic change, and I really didn't move any traces,
either. I do have a case for bus reflections, as the bus is
16 inches long. The FPGA detects unoccupied card slots and jumps
serial config strings across the empty positions, and also has
some serial config registers on the FPGA. Well, this newest
version worked erratically, and after a couple days working with
it, I figured out reflections on the serial clock that goes to all
board slots plus the FPGA were double-clocking the FPGA. I patched
a series termination resistor on the output of the driver, and
the board now works perfectly.

So, what caused this change? I'm fairly sure the board layout is
not to blame. The older boards were made with 2003 Spartan
XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
chips, otherwise the same designation, and just purchased a few
weeks ago from Avnet. Could a more recent fab run at Xilinx
have been made with significantly different speeds in the I/O?
Of course, this COULD just be a circuit that was so close to the
edge that I've just been really lucky, but I did make 20+ of these
with no sign of this problem before.

(This is a 6-layer board, always made at the same board house.)

Jon

Does the 'old' design with the 'new' chips fail?
Does the 'new' design with the 'old' chips fail?
Does the 'new' design use a newer version of ISE than before?

Slight changes in logic can cause surprisingly large changes in placemen
and routing. Changes in ISE version can cause large changes in placemen
and routing.


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Gabor]

Jon Elson wrote:

Hello, all, I know this refers to graveyard parts, but
we have reason to keep using them.

Anyway, I made a new batch of motherboards that use a 5 V Spartan
as the slot select control logic. I have made over 20 of these
before. i did a revision of the design, but this particular area
had no schematic change, and I really didn't move any traces,
either. I do have a case for bus reflections, as the bus is
16 inches long. The FPGA detects unoccupied card slots and jumps
serial config strings across the empty positions, and also has
some serial config registers on the FPGA. Well, this newest
version worked erratically, and after a couple days working with
it, I figured out reflections on the serial clock that goes to all
board slots plus the FPGA were double-clocking the FPGA. I patched
a series termination resistor on the output of the driver, and
the board now works perfectly.

So, what caused this change? I'm fairly sure the board layout is
not to blame. The older boards were made with 2003 Spartan
XCS20-3PQ208C chips, the newer ones were made with 2009 vintage
chips, otherwise the same designation, and just purchased a few
weeks ago from Avnet. Could a more recent fab run at Xilinx
have been made with significantly different speeds in the I/O?
Of course, this COULD just be a circuit that was so close to the
edge that I've just been really lucky, but I did make 20+ of these
with no sign of this problem before.

(This is a 6-layer board, always made at the same board house.)

Jon

Over the years, without "changing" the process, the fab houses do
a better job of producing parts that fall into the highest speed
grade bin. In 2003 when you ordered a -3 part, it was therefore
more probable that this part did not meet the -4 speedgrade than
it is now with the 2009 parts. In other words, your 2009 "-3" chips
were *tested* to the -3 speed grade requirements, but most probably
*meet* the -4 speedgrade. Xilinx has commented on increased yields
over the life of newer products, and I don't see why Spartan parts
would be any different.

-- Gabor

 

[Jon Elson]

On 10/13/2011 07:11 AM, RCIngham wrote:

Does the 'old' design with the 'new' chips fail?
Does the 'new' design with the 'old' chips fail?
Does the 'new' design use a newer version of ISE than before?

Slight changes in logic can cause surprisingly large changes in placement
and routing. Changes in ISE version can cause large changes in placement
and routing.
No, this is running the exact same EPROM image as all older revs. The

only change is the mfg date of the FPGA and other chips on the board,
and whatever changes might have occurred on the PCB layout and
fabrication details of the PCB itself. The serial clock is generated by
a 74HC14, and it is also possible that the output driver of this
commodity part might be different than the ones used before.

Thanks for all the interesting comments! This is now mostly an academic
curiosity, as the board runs with this additional resistor. Almost
certainly I SHOULD have been using such a scheme from the beginning on
the several clock lines on the board. But, it worked without them.......

Jon

 

[Bob Perlman]

Could you describe this serial clock that goes to all boards in a bit
more detail? Is it a single clock that is daisy-chained to all card
slots? If so, you may still have a problem. The driver on a series-
terminated net will send a half-height wave down the trace when it
transitions, followed by a half-height reflection in the reverse
direction. The upshot is that the signal at the very last load will
look fine, because the return wave launches at the same time the
incident wave arrives, producing a clean rising or falling edge. But
all other loads along the line will see a half-height pedestal in the
edge, with the pedestal becoming more pronounced as you get closer to
the driver. If that pedestal happens to be in the transition region,
the receiver could see a double (or triple, or whatever) clock.

On the other hand, if you send a separate, series-terminated clock to
each load, each clock should look fine at its destination (well, there
are other considerations, but I'm going to conveniently ignore them
for the moment).

If this is a series-terminated, daisy-chained clock, take a look at
the clock going into the FPGA with a high-bandwidth scope and probe,
and see if there's a pedestal. If there is, there's more work to be
done.

Bob Perlman
Cambrian Design Works

On Oct 13, 3:48 pm, Jon Elson <jmel...@wustl.edu> wrote:

On 10/13/2011 07:11 AM, RCIngham wrote:



Does the 'old' design with the 'new' chips fail?
Does the 'new' design with the 'old' chips fail?
Does the 'new' design use a newer version of ISE than before?

Slight changes in logic can cause surprisingly large changes in placement
and routing. Changes in ISE version can cause large changes in placement
and routing.

No, this is running the exact same EPROM image as all older revs.  The
only change is the mfg date of the FPGA and other chips on the board,
and whatever changes might have occurred on the PCB layout and
fabrication details of the PCB itself.  The serial clock is generated by
a 74HC14, and it is also possible that the output driver of this
commodity part might be different than the ones used before.

Thanks for all the interesting comments!  This is now mostly an academic
curiosity, as the board runs with this additional resistor.  Almost
certainly I SHOULD have been using such a scheme from the beginning on
the several clock lines on the board.  But, it worked without them........

Jon

 

[glen herrmannsfeldt]

Bob Perlman <cambriandesign@gmail.com> wrote:

(snip)

The driver on a series-
terminated net will send a half-height wave down the trace when it
transitions, followed by a half-height reflection in the reverse
direction. The upshot is that the signal at the very last load will
look fine, because the return wave launches at the same time the
incident wave arrives, producing a clean rising or falling edge. But
all other loads along the line will see a half-height pedestal in the
edge, with the pedestal becoming more pronounced as you get closer to
the driver. If that pedestal happens to be in the transition region,
the receiver could see a double (or triple, or whatever) clock.

That is what is supposed to happen, but there are other possibilities.

First, consider no termination. The reflection comes back at
double height, hits the protection diode, and pulls Vcc up.
That can't be good. That might be enough to mess up IOB
flip-flops.

Next, try a smaller than optimal impedance match resistor.
The signal going out might be at 3/4 height, instead of 1/2,
the reflection will then come back at 3/2, but goes through
the resistor before hitting the protection diode.

There will also be a negative reflaction back again, which
should be about half the reflection coming in, which shouldn't
bother things too much.

Also, the resistor, into the transmission line load impedance,
should round off the sharp edge a little bit, but not too much,
reducing the effects of a too-fast transition.

If the bus is TTL levels, then half of 5V, or even half of 4V
will meet the Vhigh level.

A small series termination resisitor is a lot better than
none at all.

-- glen

 

[Jon Elson]

Bob Perlman wrote:

Could you describe this serial clock that goes to all boards in a bit
more detail? Is it a single clock that is daisy-chained to all card
slots?
Yes, a horrible situation, a 16" long trace that is fed roughly

from the middle, to all 16 board slots, with the FPGA in the middle.

If so, you may still have a problem. The driver on a series-
terminated net will send a half-height wave down the trace when it
transitions, followed by a half-height reflection in the reverse
direction. The upshot is that the signal at the very last load will
look fine, because the return wave launches at the same time the
incident wave arrives, producing a clean rising or falling edge. But
all other loads along the line will see a half-height pedestal in the
edge, with the pedestal becoming more pronounced as you get closer to
the driver. If that pedestal happens to be in the transition region,
the receiver could see a double (or triple, or whatever) clock.

Yup, I am not inexperienced in transmission line design. I tried a

number of combinations of daughter boards, but obviously not a full
combinatorial test. There was no sign of trouble in those test
cases. Our control system runs test patterns on the serial config.
register, and found no trouble.

On the other hand, if you send a separate, series-terminated clock to
each load, each clock should look fine at its destination (well, there
are other considerations, but I'm going to conveniently ignore them
for the moment).

This is already a 6-layer board filled with traces, so I don't think that

is practical.

If this is a series-terminated, daisy-chained clock, take a look at
the clock going into the FPGA with a high-bandwidth scope and probe,
and see if there's a pedestal. If there is, there's more work to be
done.
Yes, I ought to do some more testing to make sure this HACK is as

robust as I hope it is.

Jon

 

[Jon Elson]

glen herrmannsfeldt wrote:

Also, the resistor, into the transmission line load impedance,
should round off the sharp edge a little bit, but not too much,
reducing the effects of a too-fast transition.

That is what I was hoping to do, round off the edge so that loads,

and the board itself pretty much absorbs the reflection.

If the bus is TTL levels, then half of 5V, or even half of 4V
will meet the Vhigh level.

Everything is CMOS, but may have "TTL" input thresholds.

A small series termination resisitor is a lot better than
none at all.
Well, it SEEMS to have solved the problem. I will probably

do some more testing to be sure it is solid.

Jon

 

[Jon Elson]

Bob Perlman wrote:

On Oct 15, 2:03 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
A small series termination resisitor is a lot better than
none at all.

-- glen

Sometimes. And clearly in this case it *is*better, because the new
motherboards seem to work. But the question before us is whether this
is a legitimate fix, i.e., one that will work for the next batch of
boards, and the batches after that. Without probing at the signals to
see what they look like, and perhaps simulating over the range of
likely driver output impedances and risetimes, you can't say. But in
general, using a series-terminated, daisy-chained net to drive
multiple clock inputs is a bad idea, and is to be avoided.

For those who want to learn more about this, here's a paper I wrote a
while back:


http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_paper.pdf

Thanks for the link. Well, in this system, the daughter boards have two
chips made by MOSIS for us on the half um AMI process, now ON Semi.
Not a really fast process, but the important stuff there is all
analog, and the slower digital is fine. There are some Maxim
serial-controlled MOS switches on the motherboard that have the slowest
digital logic I've ever seen, dating back to the discrete transistor
computer days. I had to slow the serial clock down to 1.2 us to
get valid data to clock through these chips, almost twice as slow
as their datasheet!

So, the ONLY thing fast on this board seems to be the FPGA! That's
why I got away with this design before. Having the FPGA in the
center of the board may be the worst spot for reflections.

Jon

 

[Bob Perlman]

On Oct 15, 2:03 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

A small series termination resisitor is a lot better than
none at all.

-- glen

Sometimes. And clearly in this case it *is*better, because the new
motherboards seem to work. But the question before us is whether this
is a legitimate fix, i.e., one that will work for the next batch of
boards, and the batches after that. Without probing at the signals to
see what they look like, and perhaps simulating over the range of
likely driver output impedances and risetimes, you can't say. But in
general, using a series-terminated, daisy-chained net to drive
multiple clock inputs is a bad idea, and is to be avoided.

For those who want to learn more about this, here's a paper I wrote a
while back:

http://cambriandesign.squarespace.com/downloadable-files/pads_series_term_paper.pdf

Bob Perlman
Cambrian Design Works

 

[RCIngham]

glen herrmannsfeldt wrote:
Also, the resistor, into the transmission line load impedance,
should round off the sharp edge a little bit, but not too much,
reducing the effects of a too-fast transition.

That is what I was hoping to do, round off the edge so that loads,
and the board itself pretty much absorbs the reflection.

If the bus is TTL levels, then half of 5V, or even half of 4V
will meet the Vhigh level.

Everything is CMOS, but may have "TTL" input thresholds.
A small series termination resisitor is a lot better than
none at all.
Well, it SEEMS to have solved the problem. I will probably
do some more testing to be sure it is solid.

Jon

If available, I advise doing tests in a cold chamber, which should increas
edge rates (reduce rise/fall time). It wasn't until we got to lo
temperature qualification tests that I discovered signal integrity issue
relating to series termination on one of my designs...


---------------------------------------
Posted through http://www.FPGARelated.com

 

[Jon Elson]

On 10/24/2011 03:06 PM, rickman wrote:

There is more than one way to skin a cat. IF your FPGA has a clock on
board that is significantly faster than the serial clock (> 2x) you
can sample the serial clock and detect the edges in this faster clock
domain. This is pretty robust against the sort of double clocking you
are seeing since the problem is not noise per se, but reflections
which have a defined timing relationship with the clock edge.

I used this in a design for a customer, not for the noise advantages,
but as part of a digital PLL design and the customer realized the lack
of sensitivity to reflections and expressed his approval.
Yes, this is where it gets really messy. This is a mixed-signal system

with VERY sensitive preamps. Any digital signals clocking while the
analog section is open for signals would likely be a problem.
So, there is NO continuous clock available.

I know what I was forced to do broke all the digital rules, but it was
necessary to make the analog part work.

Jon

 

[rickman]

On Oct 15, 7:33 pm, Jon Elson <el...@pico-systems.com> wrote:

glen herrmannsfeldt wrote:
Also, the resistor, into the transmission line load impedance,
should round off the sharp edge a little bit, but not too much,
reducing the effects of a too-fast transition.

That is what I was hoping to do, round off the edge so that loads,
and the board itself pretty much absorbs the reflection.

If the bus is TTL levels, then half of 5V, or even half of 4V
will meet the Vhigh level.

Everything is CMOS, but may have "TTL" input thresholds.> A small series termination resisitor is a lot better than
none at all.

Well, it SEEMS to have solved the problem.  I will probably
do some more testing to be sure it is solid.

Jon

There is more than one way to skin a cat. IF your FPGA has a clock on
board that is significantly faster than the serial clock (> 2x) you
can sample the serial clock and detect the edges in this faster clock
domain. This is pretty robust against the sort of double clocking you
are seeing since the problem is not noise per se, but reflections
which have a defined timing relationship with the clock edge.

I used this in a design for a customer, not for the noise advantages,
but as part of a digital PLL design and the customer realized the lack
of sensitivity to reflections and expressed his approval.

Rick

 

[glen herrmannsfeldt]

Jon Elson <jmelson@wustl.edu> wrote:

(snip)

I know what I was forced to do broke all the digital rules, but it was
necessary to make the analog part work.

Maybe not all of them. While most of the modern rules are based
on synchronous logic, asynchronous (sometimes called self-timed)
logic is still around, with its own, different, rules.

-- glen

 

[Jon Elson]

On 10/24/2011 03:57 PM, glen herrmannsfeldt wrote:

Jon Elson<jmelson@wustl.edu> wrote:

(snip)
I know what I was forced to do broke all the digital rules, but it was
necessary to make the analog part work.

Maybe not all of them. While most of the modern rules are based
on synchronous logic, asynchronous (sometimes called self-timed)
logic is still around, with its own, different, rules.
Well, when the digital part fires up, I do have a clock, the serial

clock for the shift register. As long as that is clean (enough), then
there is no problem. This design has been working fine since 2004 or so.

Jon