Spartan changes in glitch sensitivity

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

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

On Oct 13, 5:26=A0pm, Jon Elson <el...@pico-systems.com> wrote:
>=A0Could 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

>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 placement
and routing. Changes in ISE version can cause large changes in placement
and routing.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

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

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

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=A0pm, 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 placeme=
nt
> > and routing. Changes in ISE version can cause large changes in placemen=
t
> > and routing.
>
> No, this is running the exact same EPROM image as all older revs. =A0The
> 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. =A0The serial clock is generated b=
y
> 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! =A0This is now mostly an academi=
c
> curiosity, as the board runs with this additional resistor. =A0Almost
> certainly I SHOULD have been using such a scheme from the beginning on
> the several clock lines on the board. =A0But, it worked without them.....=
..
>
> Jon

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

On Oct 15, 2:03=A0am, 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_p=
aper.pdf

Bob Perlman
Cambrian Design Works

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