Xilinx S3 I/O robustness question

[lecroy]

I have spent the last 60 days trying to get an answer from Xilinx on
their new S3 devices. During a review, it was stated that the new S3s
were very sensitive to transients on the I/O pins. Because they made a
point to mention this during the review, I posed the following
question to Xilinx:

"If we look at the incident versus reflected energy and tune the stub
(trace)
for a worst case match is it possible the driver could be damaged or
the
chip lock up due to the reflected energy?"

"The circuit would be as follows:
Spartan III Output ------------------------------ Tunable Stub"

I wonder if anyone in this group has asked this question and what was
the responce from Xilinx?

 

[Steven K. Knapp]

When using Spartan-3 FPGAs in an 3.3V LVTTL or LVCMOS application, the
output voltage, VCCO, must be within the "narrow" voltage range defined in
the EIA/JEDEC JESD8-B specification, namely 3.15V to 3.45V, with a nominal
3.3V value.

The primary consideration on Spartan-3 I/Os is to keep the voltage at the
pin below the 3.75V absolute maximum specification. Going above 3.75V
doesn't immediately destroy the device, but prolonged exposure degrades
device lifetime. If the voltage remains below 3.75V, there is no
degradation.

So, if VCCO should be below 3.45V, how can the voltage at the pin possible
reach 3.75V? Mismatched impedance can cause overshoot and undershoot,
raising the voltage on the pin by hundreds of millivolts. Properly
terminating a trace eliminates or reduces the over/undershoot to acceptable
limits. Application note XAPP659 describes some of the techniques to
guarantee that signals stay under 3.75V. Although written for the Virtex-II
Pro family, these same techniques apply to Spartan-3 FPGAs.

Using 3.3V I/O Guidelines in a Virtex-II Pro Design.
http://www.xilinx.com/bvdocs/appnotes/xapp659.pdf

I hadn't seen this question coming in from our FAE team, so my apologies on
not receiving an answer before this time. Should you have any other
questions, please feel free to contact me directly. Just be sure to remove
the "NOSPAM" from my return E-mail address.
---------------------------------
Steven K. Knapp
Applications Manager, Xilinx Inc.
Spartan-3/II/IIE FPGAs
http://www.xilinx.com/spartan3
---------------------------------
Spartan-3: Make it Your ASIC



"lecroy" <lecroy7200@chek.com> wrote in message
news:9297c711.0309080520.260aa01b@posting.google.com...

I have spent the last 60 days trying to get an answer from Xilinx on
their new S3 devices. During a review, it was stated that the new S3s
were very sensitive to transients on the I/O pins. Because they made a
point to mention this during the review, I posed the following
question to Xilinx:

"If we look at the incident versus reflected energy and tune the stub
(trace)
for a worst case match is it possible the driver could be damaged or
the
chip lock up due to the reflected energy?"

"The circuit would be as follows:
Spartan III Output ------------------------------ Tunable Stub"

I wonder if anyone in this group has asked this question and what was
the responce from Xilinx?

 

[lecroy]

"Steven K. Knapp" <steve.knappNO#SPAM@xilinx.com> wrote in message news:<bjiivv$oae1@cliff.xsj.xilinx.com>...

When using Spartan-3 FPGAs in an 3.3V LVTTL or LVCMOS application, the
output voltage, VCCO, must be within the "narrow" voltage range defined in
the EIA/JEDEC JESD8-B specification, namely 3.15V to 3.45V, with a nominal
3.3V value.

The primary consideration on Spartan-3 I/Os is to keep the voltage at the
pin below the 3.75V absolute maximum specification. Going above 3.75V
doesn't immediately destroy the device, but prolonged exposure degrades
device lifetime. If the voltage remains below 3.75V, there is no
degradation.

So, if VCCO should be below 3.45V, how can the voltage at the pin possible
reach 3.75V? Mismatched impedance can cause overshoot and undershoot,
raising the voltage on the pin by hundreds of millivolts. Properly
terminating a trace eliminates or reduces the over/undershoot to acceptable
limits. Application note XAPP659 describes some of the techniques to
guarantee that signals stay under 3.75V. Although written for the Virtex-II
Pro family, these same techniques apply to Spartan-3 FPGAs.

Using 3.3V I/O Guidelines in a Virtex-II Pro Design.
http://www.xilinx.com/bvdocs/appnotes/xapp659.pdf

Steve, keep in mind I am talking about the reflected signal on an
output only. I was provided the following link from Xilinx. Does
this refer to the S3 devices as well, as it conflicts with your
original responce?



http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=11001

Problem Description:

Keywords: FPGA, overshoot, undershoot, reliability

Urgency: Standard

General Description:
Does ringing (overshoot and undershoot) compromise the reliability of
an FPGA device?

Solution 1:

For all FPGA families, ringing signals are not a cause for reliability
concerns. To cause such
a problem, the Absolution Maximum DC conditions need to be violated
for a considerable
amount of time (seconds).

Keep in mind, however, that ringing can create many functional issues,
causing glitches, double-
clocking, setup/hold errors, etc.

 

[Hal Murray]

In devices like V2Pro and S3, the maximum allowed voltages
(both positive and negative) on the I/O pins form a smaller
window than in some previous families. ...

Is that window just smaller in terms of volts, or is it
smaller in terms of percent?

Why wasn't this a problem several years ago? Consider
a 5V IOB or junk CMOS logic. It would get pulsed to 10 V from
nasty reflections if the clamp diodes didn't do their thing.
Clearly that's way above the max ratings. So we have been
operating out-of-spec for a long time.

Has technology in this area changed in the past few years?
Have I missed similar discussions in other areas? (That
would be easy.)

Is there something about the way transistors scale that
I don't know about? (yet) Are fab lines cutting things
closer now? ...

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Symon]

Hi Rick,
As a rule of thumb, when the signal's rise time is faster than
1/6th the time for the signal to get to the other end of the trace,
(guess at 170ps/in of track) then you MUST consider the SI
implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx
pin, you can have 1 inch of track before you have to worry about
reflections!) You can find the rise time data in the IBIS files Xilinx
provides on their website. Remember, the frequency of the signal isn't
important, it's the rise time. Leave those pins in 'SLOW' mode
whenever possible!
As Austin says, the simulation tools are a BIG help here. Those
IC pins drive bloody hard and fast and I would never like to be
relying on the clamp diodes to save the day, this dumps energy into
the supplies and Austin is not joking when he says that ground bounce
is (and will continue to be) a big consideration. There's a reason
Xilinx have gone to the trouble of putting DCI on their devices!
The receivers warrant the most attention as they can appear as
an open circuit, the drivers have low impedance and so limit
deviations a bit better. It's time to dust off "High-Speed Digital
Design" for some bed time reading! There's a new edition out I
believe? (Just found it:- High-Speed Signal Propagation: Advanced
Black Magic) I also recommend http://www.sigcon.com/ also by Dr.
Howard Johnson. More v. helpful stuff there for free!!
HTH, cheers, Syms.


rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F70705F.EAB8FBC5@yahoo.com>...

Hal Murray wrote:

The receiver pin is the one that gets the big hit.

So how bad is that hit? How good are the protection diodes?

If the clamp diodes are any good they will reduce the reflection
and make things easier back at the transmitter.

This is a good question. So far I have only read people considering the
S3 chip driving. What about the case where is is on the receiving end
of the signal?

My designs typically don't consider signal integrity on traces other
than edge sensitive clock lines and chip enables. For non-edge
sensitive signals, I have always treated it a bit like metastability,
allow some time for the signal to settle out and all will be good by the
time of the clock edge. But if we have to consider *every* trace on the
board for reflections and overshoot, board design can become a
nightmare!

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Symon wrote:

Hi Rick,
As a rule of thumb, when the signal's rise time is faster than
1/6th the time for the signal to get to the other end of the trace,
(guess at 170ps/in of track) then you MUST consider the SI
implications. (So for a 1ns rise time, i.e. a normal 'FAST' Xilinx
pin, you can have 1 inch of track before you have to worry about
reflections!) You can find the rise time data in the IBIS files Xilinx
provides on their website. Remember, the frequency of the signal isn't
important, it's the rise time. Leave those pins in 'SLOW' mode
whenever possible!

But your use of the term "must" is not totally accurate. The numbers
you give are a good rule of thumb for when reflections will be
significant to the signal waveform, but that does not automatically
indicate a problem will be created. A data line can bounce around for
an extra ns or two and won't matter if there is extra time in the
setup. Up until now I have not seen a chip rated to exclude ringing or
overshoot (or undershoot) because of damage. In fact, most data sheets
specifically say that this will not be a problem if it only persists for
a few ns.

As Austin says, the simulation tools are a BIG help here. Those
IC pins drive bloody hard and fast and I would never like to be
relying on the clamp diodes to save the day, this dumps energy into
the supplies and Austin is not joking when he says that ground bounce
is (and will continue to be) a big consideration. There's a reason
Xilinx have gone to the trouble of putting DCI on their devices!

I have not heard of ringing being the cause of ground bounce. My
experience has been that ground bounce is caused by the initial current
slug when an output changes state, not the result of a reflection from
the other end. As the numbers that have been posted in this thread have
indicated, the reflection current is much smaller than the initial
slug.

The receivers warrant the most attention as they can appear as
an open circuit, the drivers have low impedance and so limit
deviations a bit better. It's time to dust off "High-Speed Digital
Design" for some bed time reading! There's a new edition out I
believe? (Just found it:- High-Speed Signal Propagation: Advanced
Black Magic) I also recommend http://www.sigcon.com/ also by Dr.
Howard Johnson. More v. helpful stuff there for free!!
HTH, cheers, Syms.

If I actually have to simulate every signal on the board I am designing,
it may never get done. I think there is something wrong with the idea
that this is a overly complex issue and can't be dealt with in a simpler
manner. Or am I missing something of what you are saying?


--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[John_H]

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3F71B6DF.8885BD55@xilinx.com...

[snip]

And yes, if you do not pay attention now, you will cause ground bounce
(50 -
60 mA of reflection current per IO is possible)

[snip]

Austin,

I appreciate your continued push to get us to look at signal integrity more
closely but please help me out here. "Ground bounce" that I'm aware of
involves shifting voltage reference thresholds - a voltage effect - due to
the parasitic inductance of the chip's ground to the board's ground plane.
The change in current draw (dI/dt) across the package inductance produces
the voltage change.

Are you suggesting the voltage effect will be caused by the current change
due to reflected energy getting absorbed in the transistors driving those
signals to ground? This would make some sense to me though I would expect
the current surge to be spread over a much larger time (different
open-circuit lengths) than the original current surges that generated the
synchronous signals getting the reflection.

If my interpretation is not correct and you're suggesting ground-bounce is
related to current rather than current-change related voltage, please help
me understand.

If logic-high reflections are suspected of causing ground bounce, I'd
appreciate some elaboration. Is there a path for this current through the
ground on-chip? Are the voltage references not entirely ground-referenced?

Thanks for your help.

 

[rickman]

Symon wrote:

Hi Rick,
OK, I suppose 'MUST' isn't strictly accurate, you might not care
whether the design works or not! How about 'SHOULD' instead? ;-) Those
signals bouncing back and forth may not affect the circuits functional
operation, but what are you gonna do when it happens on a 5 inch, 32
bit data bus and you can't pass the CE/FCC mark tests? Sell it in
Elbonia, I guess!

Is there a good market there? If a 5 inch 32 bit data bus without
termination precludes passing CE/FCC RFI tests, then no PC would ever be
sold. Few RFI issues are solved purely at the PC board level. In US
commercial markets, the requirements are very different than consumer
markets as well.

As for ground bounce, if those diodes are dumping energy, be sure
you've decoupled the Rx IC as well as the Tx one! Generally, it's
better not to have to rely on the diodes, don't you think? You end up
trading decoupling capacitors for termination resistors.

That is assuming that the diodes would be triggered. I seem to recall
that the basic analysis done here showed that this was unlikely.

I'm not saying simulate every trace. Simulate one, and layout the
rest accordingly, as I think Austin says in a parallel post. Check the
PCB layout very carefully, watching out for traces that don't comply
with your SI design. I like Austin's idea of adopting a standard
(HSTL, SSTL, PCI), makes it easy.

That is the part I am not clear about. These traces are all individual
circuits. If you have the luxury of a lot of open board space to route
straight lines here and there, then sure, you can make each one very
similar. On a small, tight board it will be very difficult to make them
that similar. If the signal is critical enough to require a simulation,
then I expect I would need to simulate each of them.

I am surprized that the Spartan 3 chips are so sensitive to over and
undershoot that this has become a major issue. I have seen lots of high
speed boards and none had FPGAs or any other chips that needed this
degree of analysis to prevent damage.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[rickman]

Austin Lesea wrote:

Rick,

Fight it as long as you can, but everyone else is using the more advanced
tools, and simulating everything (at the companies where they want to be
successful on the first pcb turn -- as for the others, I don't hear from
them often anymore....).

Funny. But I doubt it is very accurate. I have worked at some of the
larger companies making telecom test equipment and I have yet to meet a
board designer who simulates all of the traces. The ones I spoke with
only simulate the clock lines or other signal lines when the timing is
tight with no time for settling.

Like I said, this is the first time I have heard a chip maker claim that
typical ringing and undershoot can cause chip damage. Of course an
absurdly designed trace and create excessive swings. But the typical
amount of ringing is normally listed in data sheets as being within spec
for chips.

And yes, if you do not pay attention now, you will cause ground bounce (50 -
60 mA of reflection current per IO is possible),

Under what conditions is this "possible"? I would expect this to be an
extreme case. The analyis listed here indicated much lower currents
(~35 mA) and only for the brief time (< 1 ns) of the overshoot. If the
device can't handle these low currents without ground bounce, how can it
possibly provide the much larger currents (> 55 mA) for the initial
level change without ground bounce?

and with the Virtex II Pro,
and Spartan 3 if the IOs are operated at 3.3V, you may exceed the Abs Max
data sheet limits if you do not pay attention to what you are doing. And
that will cause a reduction in the 20 year projected lifetime. Below 3.0V,
there are no reliability issues to consider, as the clamp diodes are
sufficient to protect the IOs. Smaller, faster, less expensive technology
from the foundries has some drawbacks: leakage current, and IO robustness
at voltages greater than 3.75 volts being two of them.

The new tools allow for extraction of all pcb parameters, and easy
simulation of all tracks/traces. You can also create a design that is
correct by construction: use DCI or series or parallel termination, and
make 50 ohm (or whatever) traces. Then you do not have to simulate
everything.

So the DCI in the S3 chips will allow matching of the chip IO impedance
to the trace, right?

Or use a standard: HSTL, SSTL, PCI. Then you also don't have to think.
But I also simulate to make sure I haven't missed anything.

I only wish standards really did preclude the "thinking". I have worked
with RS-232 and many others too long to beleive that.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Austin Lesea]

Last post:

See below,

Austin

rickman wrote:

Symon wrote:

Hi Rick,
OK, I suppose 'MUST' isn't strictly accurate, you might not care
whether the design works or not! How about 'SHOULD' instead? ;-) Those
signals bouncing back and forth may not affect the circuits functional
operation, but what are you gonna do when it happens on a 5 inch, 32
bit data bus and you can't pass the CE/FCC mark tests? Sell it in
Elbonia, I guess!

Is there a good market there? If a 5 inch 32 bit data bus without
termination precludes passing CE/FCC RFI tests, then no PC would ever be
sold. Few RFI issues are solved purely at the PC board level. In US
commercial markets, the requirements are very different than consumer
markets as well.

Yes, you can sell garbage. I don't think that we are talking about that
here: even game toys have to have just about every government and safety
lab certification known....

As for ground bounce, if those diodes are dumping energy, be sure
you've decoupled the Rx IC as well as the Tx one! Generally, it's
better not to have to rely on the diodes, don't you think? You end up
trading decoupling capacitors for termination resistors.

That is assuming that the diodes would be triggered. I seem to recall
that the basic analysis done here showed that this was unlikely.

They are triggered at the receive end. Remember the low drive impedance,
high terminate impedance t-line case tries to as much as double the voltage
at the receive end. Remember Howard running across the room with his
pointer and banging into the wall (if you have been to one of his great
performances)? Instructive.

I'm not saying simulate every trace. Simulate one, and layout the
rest accordingly, as I think Austin says in a parallel post. Check the
PCB layout very carefully, watching out for traces that don't comply
with your SI design. I like Austin's idea of adopting a standard
(HSTL, SSTL, PCI), makes it easy.

That is the part I am not clear about. These traces are all individual
circuits. If you have the luxury of a lot of open board space to route
straight lines here and there, then sure, you can make each one very
similar. On a small, tight board it will be very difficult to make them
that similar. If the signal is critical enough to require a simulation,
then I expect I would need to simulate each of them.

Yes.

I am surprized that the Spartan 3 chips are so sensitive to over and
undershoot that this has become a major issue. I have seen lots of high
speed boards and none had FPGAs or any other chips that needed this
degree of analysis to prevent damage.

Get off the horse. It is tired already. See my other post. If you are
going to have really bad SI, at 3.6V Vcco, AND 85C Tj, then you may have to
consider the abs max specs.....so do a good SI job, and you will never get
there.

In previous families, there were Abs Max specs, and you could go past them,
too, with poor SI. This is only different because the numbers are tighter,
and the Vccint is now 1.2 volts, and bad SI will make the design fail to
function a long time before any IO will fail. Why not encourage designers
to be successful (hey, what a concept! if the design works, then we sell
more chips!).

 

[Simon Peacock]

Cutting thru the words... I will have to agree with Austin here.. as speeds
go up and voltages go down simulation is going to go from "well maybe" to
"essential"...

Sure your 12 MHz 8031 micro will never need to be simulated.. but your 800
MHz LVDS bus may not even work.. is just a matter of getting relative and
you will find the same with your FPGA... fast edges and fast clocks will
stir a hornets nest .. just be prepared for them..

and you think this is bad .. wait for the Spartan 4 at .6 instead of .9 ..
give it a bad look and it will jump of the board .. but it will probably run
at a Gig and run on an oily rag

Simon


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3F7388A0.A6A9568A@yahoo.com...

I find your tone offensive Austin. I am simply trying to understand the
issue being discussed by yourself as well as others. On my board there
will be no traces that are near 12" much less 24" and the power supply
[snip]

 

[Symon]

Hi Rick,
Stuff below:-

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7257C6.91BECAD0@yahoo.com>...

Symon wrote:

Hi Rick,
OK, I suppose 'MUST' isn't strictly accurate, you might not care
whether the design works or not! How about 'SHOULD' instead? ;-) Those
signals bouncing back and forth may not affect the circuits functional
operation, but what are you gonna do when it happens on a 5 inch, 32
bit data bus and you can't pass the CE/FCC mark tests? Sell it in
Elbonia, I guess!

Is there a good market there? If a 5 inch 32 bit data bus without
termination precludes passing CE/FCC RFI tests, then no PC would ever be
sold. Few RFI issues are solved purely at the PC board level. In US
commercial markets, the requirements are very different than consumer
markets as well.

PC's only pass because they're in metal boxes. Not everyone has that

luxury!

As for ground bounce, if those diodes are dumping energy, be sure
you've decoupled the Rx IC as well as the Tx one! Generally, it's
better not to have to rely on the diodes, don't you think? You end up
trading decoupling capacitors for termination resistors.

That is assuming that the diodes would be triggered. I seem to recall
that the basic analysis done here showed that this was unlikely.

I'm not saying simulate every trace. Simulate one, and layout the
rest accordingly, as I think Austin says in a parallel post. Check the
PCB layout very carefully, watching out for traces that don't comply
with your SI design. I like Austin's idea of adopting a standard
(HSTL, SSTL, PCI), makes it easy.

That is the part I am not clear about. These traces are all individual
circuits. If you have the luxury of a lot of open board space to route
straight lines here and there, then sure, you can make each one very
similar. On a small, tight board it will be very difficult to make them
that similar. If the signal is critical enough to require a simulation,
then I expect I would need to simulate each of them.

What I do is arrange the signal pins on my FPGA so they connect 'one

to one' to other devices. Worry about pin swapping signals inside the
FPGA fabric. Together with careful board layout, you can keep the
buses a nice regular structure. This keeps large numbers of tracks
similar. The PCB layout people like me too!! To me this is a BIG
advantage that FPGAs offer.

I am surprized that the Spartan 3 chips are so sensitive to over and
undershoot that this has become a major issue. I have seen lots of high
speed boards and none had FPGAs or any other chips that needed this
degree of analysis to prevent damage.

--

I don't think the Spartan-3 is especially oversensitive per se, just

that low voltage, small geometry parts are likely victims. It's
something to consider in more and more designs as time goes by. The
FPGA is often the device that connects a lot of disparate pieces with
varying signalling standards together so deserves special attention.

Anyway, I've enjoyed (am enjoying) our discussion, I'm sure any
(hopefully) small offence caused by some posters' robust I/O and
others' sensitive inputs can be put down to a mismatch in transmission
standards!! Maybe we should terminate this before the noise going back
and forth gets above the absolute maximum tolerance!
All the best mate, Syms.

 

[Andy Peters]

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7257C6.91BECAD0@yahoo.com>...

That is the part I am not clear about. These traces are all individual
circuits. If you have the luxury of a lot of open board space to route
straight lines here and there, then sure, you can make each one very
similar. On a small, tight board it will be very difficult to make them
that similar. If the signal is critical enough to require a simulation,
then I expect I would need to simulate each of them.

The traces may not actually be individual circuits! While Austin (and
others, including myself) advocate SI simulations to show the effects
of terminations on line ringing and what not, what can _really_ bite
you in the ass is crosstalk. In one particular case, there was an
issue with crosstalk from a data bus affecting a nearby reset line.
When a simulation was finally run, the problem was obvious.

So, yeah, I'd say that not bothering to simulate these lines because
they weren't clocks and because "the signals can bounce around for a
couple of ns" was a bad idea.

The time spent simulating upfront is well worth the investment. You
simulate your FPGA logic, because you'd rather spend the time in front
of the computer, rather than in the lab with a 'scope probe? Same
thing here, except that a board spin is a lot more expensive than
reprogramming that ISP EEPROM.

Oh, yeah, the 'scopes and probes required to really see these types of
problems in the lab cost more than the SI software.

I am surprized that the Spartan 3 chips are so sensitive to over and
undershoot that this has become a major issue. I have seen lots of high
speed boards and none had FPGAs or any other chips that needed this
degree of analysis to prevent damage.

Perhap Xilinx are simply erring on the side of caution. They're
informing the user of potential issues when they can be dealt with --
in the design phase -- rather than when boards are RMAed and customers
are pissed.

In any event, I think Austin's tone was one of frustration -- after
all, he's trying to help you! Basically, he's saying that if you do
the simulations up front, your board can be designed such that these
potential problems don't turn out to be actual problems.

--a

 

[Allan Herriman]

On Sat, 27 Sep 2003 00:38:01 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

Andy Peters wrote:

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7257C6.91BECAD0@yahoo.com>...
But you are making assumptions about the circuits I am building. The
original issue was the fact that the Spartan 3 chips are sensitive to
even short term overvoltage due to ringing. Like I have said, I have
never seen this in any data sheet until now. All the chips I have
worked with either have specifically indicated that there would be no
problem of damage due to small, short term transitions outside the rated
voltage spec, or this was stated when the manufacturer was contacted.
The Spartan 3 chips are the first I have heard of this being
specifically contraindicated.

I also haven't heard of this before. But then, I haven't used 90nm
parts before.
<speculation>
Perhaps this is the way of the future.
</speculation>

Allan.

 

[Symon]

Hi Rick,
Here are things that I agree completely with you on. "No amount
of simulation will correct a problem if you don't understand what is
going on." and "I can do a few simple calculations to get worst case
numbers for ringing on a 6" trace.". Without first understanding
what's going on, the simulator can be a dangerous thing. Garbage in,
garbage out! I think it's absolutely vital to know what's going on or
how will you be able to sanity check the results the simulator gives?
cheers, Syms.

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F751429.40DB59C3@yahoo.com>...

Ringing is not the cause of crosstalk. Crosstalk is coupling of the
primary wavefront coupling to adjacent traces due to proximity over
excessively long lengths. No amount of simulation will correct a problem
if you don't understand what is going on.


I can do a few simple calculations to get worst
case numbers for ringing on a 6" trace. I don't need to use expensive
software that does the same calulation with a few extra variables thrown
in that simply fine tune the calcs.

The other reason that I can't simulate the signals up front is because
the Spartan 3 in this design will be driving signals to multiple
daughter boards that are not designed or even planned yet. Obviously
this will have to be dealt with at the design level when the time
comes.

 

[lecroy]

I have been away, but was glad to see people are starting to talk
about this possible issue with the S3.

The confusion is (to many) that the question is what does the reflection back to the driver do to the
driver, right? This is a fairly obscure distinction, so I would not expect every one of the 200+ hotline
CAEs to get it perfectly right on the first try.

Did you submit multiple cases? Or call some folks you know? (IE how did you get multiple answers...) It
would help if you worked this thru the hotline, as they need to learn from their mistakes, and improve
their service sometimes. If you are talking about it here, then we are not closing the loop!

Well, like I had stated early on, I had spent about two months working
the channels at Xilinx trying to get an answer, starting with the
person who made the original comment about it being a problem. I
never opened a case with the hotline. I have never found them to be
useful and it seems their only goal to it to close as many calls as
possible, not help the customers. That's for a different topic.

Well, if the PMOS is ON, then it is really hard for a reflection to drive the output pin to a voltage that
is higher than the specification. Conversely, if the NMOS is ON, then it is really hard for the reflection
to drive the output pin below ground.

Look at the IBIS simulation at the output pin to see what the voltage excursions are, an be sure they stay
within the specifications sheet and user's guide.

Well, not like Mr. Pease, I have always been a big user of simulation
as one tool. Certainly, not the last tool and I don't see it
replacing the VNA any time soon as a way to get the 'real' picture of
what is going on. But the question I always have when some one throws
out the simulation card is how good is your model. When Xilinx
released the IBIS models for the S3, how much data was it based upon?
Have they continued to update the model as parts are being tested?
How much do you trust it?

If you have a specific waveform, you may email it to me directly, and I will get the "final word" from the
designers and technology groups.

Do I have a specific waveform, no. I am asking a general question
about the S3. Just how sensitive it really is and what precautions do
I need to take to make it work. Because each layout is different, the
loading can be anything if you consider all of the failure modes.

 

[lecroy]

That was some good reading! Thanks to everyone who had input on this
subject.

I would like to know more details about how the S3 I/O models are
being maintained. I can't seem to get Xilinx to keep up with their
timing models in their own tools.

If the S3 really is that sensitive, I would not use simulation as the
last word. While we have more "sensitive" boards tested at the
supplier's, even this may no longer be "good enough" to validate the
PCB. And if they hit 10% on their test pads I think they are doing
good.

My big fear is that while we have been doing 1G digital designs for
several years using ECL without any problems (well), as we migrate to
putting these designs into faster FPGAs that we may loose reliablity.
The best thing we could hope for is for the FPGA designers to make a
quantum jump to 100GHz+ internal routing and take all the fun out of
the layout. And while your at it, there are some other features I
would like packed in there as well. Maybe I will live to be that old,
but I don't think so.

Thanks again for putting some light on this.

 

[Tim]

Austin Lesea wrote:

Failure mode is simple: the stress on the pmos output device when
the IO pin is used as an input shall not exceed that stated in the
abs max spec (4.05V for example on Virtex II Pro and Spartan 3,
+3.75V abs max Vcco, and -0.3V abs max Vio on the io pin). If this
stress is exceeded, it will eventually cause the IO to become leaky
(ie > 10uA IOB leakage current spec will be violated). This increase
in leakage may, or may not affect your system.

If you go outside the limits with Vio and are current limited
to 10uA will there be a problem? How about 100uA? 1mA?

Please excuse my ignorance on this stuff....

 

[Austin Lesea]

Tim,

Since this is an input, there is no current going into/out of it (unless
you go to the clamp diode limit).

So assuming that the diodes are not clamping, it is purely a voltage issue.

No ignorance here at all, the effect that is actually seen (with tests at >
4.5V) result in increased leakage, but no functional failure of the IOB (it
still works, but does not meet the < 10uA IO pin spec).

This is the subject of research and PhD thesis material among the
technology communities.

Austin

Tim wrote:

Austin Lesea wrote:

Failure mode is simple: the stress on the pmos output device when
the IO pin is used as an input shall not exceed that stated in the
abs max spec (4.05V for example on Virtex II Pro and Spartan 3,
+3.75V abs max Vcco, and -0.3V abs max Vio on the io pin). If this
stress is exceeded, it will eventually cause the IO to become leaky
(ie > 10uA IOB leakage current spec will be violated). This increase
in leakage may, or may not affect your system.

If you go outside the limits with Vio and are current limited
to 10uA will there be a problem? How about 100uA? 1mA?

Please excuse my ignorance on this stuff....

 

[rickman]

lecroy wrote:

Look at the IBIS simulation at the output pin to see what the voltage excursions are, an be sure they stay
within the specifications sheet and user's guide.

Well, not like Mr. Pease, I have always been a big user of simulation
as one tool. Certainly, not the last tool and I don't see it
replacing the VNA any time soon as a way to get the 'real' picture of
what is going on. But the question I always have when some one throws
out the simulation card is how good is your model. When Xilinx
released the IBIS models for the S3, how much data was it based upon?
Have they continued to update the model as parts are being tested?
How much do you trust it?

That is a *very* important question. We have seen the timing files go
through iteration after iteration of refinement. At what point can be
believe that the IBIS models will be stable?

If you have a specific waveform, you may email it to me directly, and I will get the "final word" from the
designers and technology groups.

Do I have a specific waveform, no. I am asking a general question
about the S3. Just how sensitive it really is and what precautions do
I need to take to make it work. Because each layout is different, the
loading can be anything if you consider all of the failure modes.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX