Xilinx S3 I/O robustness question - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Xilinx S3 I/O robustness question
Rick,

Good point, and without the termination (load or receiver) the difference is:

100 mV higher (lower) peak voltage (+/- 237 mV from Vcco and ground).

Still well within the datasheet limits.

Again, simulate what you are doing!

http://support.xilinx.com/xlnx/xweb/xil_tx_display.jsp?BV_SessionID=@@@@2073323889.1064333725@@@@&BV_EngineID=ccceadcjhgejgjicflgcefldfgldgjh.0&sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=al_fathers

Austin

rickman wrote:

Quoted text here. Click to load it
correct, it
Quoted text here. Click to load it
possibility in
Quoted text here. Click to load it
addresses.
Quoted text here. Click to load it


Re: Xilinx S3 I/O robustness question
Quoted text here. Click to load it

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

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness question

--------------53B8F2F545754BA2978FBFA8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rick,

You are going to have to consider the receiving end SI.

In addition to violating the specifications (possible) you can also create
EMI/RFI, and cause substatial substrate and Vcco bounce by slamming the
clamp diodes at the inputs.  The bounce leads to changing the substrate
(ground) and Vcco on die, which causes jitter, and timing failures.  All of
this is trivially prevented by choosing the right series termination at the
driver (or using DCI drivers).

With the Vccint at 1.5V and dropping fast, ground bounce is now becoming
public enemy number 1.

Like I said, you can't get around LA without a car.  Get the simulator.  Use
it.

Austin

rickman wrote:

Quoted text here. Click to load it

--------------53B8F2F545754BA2978FBFA8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Rick,
<p>You are going to have to consider the receiving end SI.
<p>In addition to violating the specifications (possible) you can also
create EMI/RFI, and cause substatial substrate and Vcco bounce by slamming
the clamp diodes at the inputs.&nbsp; The bounce leads to changing the
substrate (ground) and Vcco on die, which causes jitter, and timing
failures.&nbsp;
All of this is trivially prevented by choosing the right series termination
at the driver (or using DCI drivers).
<p>With the Vccint at 1.5V and dropping fast, ground bounce is now becoming
<b>public enemy number 1.</b>
<p>Like I said, you can't get around LA without a car.&nbsp; Get the
simulator.&nbsp;

Use it.
<p>Austin
<p>rickman wrote:
<blockquote TYPE=CITE>Hal Murray wrote:
<br>>
<br>> >&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The receiver pin is the one
that gets the big hit.
<br>>
<br>> So how bad is that hit?&nbsp; How good are the protection diodes?
<br>>
<br>> If the clamp diodes are any good they will reduce the reflection
<br>> and make things easier back at the transmitter.
<p>This is a good question.&nbsp; So far I have only read people considering
the
<br>S3 chip driving.&nbsp; What about the case where is is on the receiving
end
<br>of the signal?
<p>My designs typically don't consider signal integrity on traces other
<br>than edge sensitive clock lines and chip enables.&nbsp; For non-edge
<br>sensitive signals, I have always treated it a bit like metastability,
<br>allow some time for the signal to settle out and all will be good by
the
<br>time of the clock edge.&nbsp; But if we have to consider *every* trace
on the
<br>board for reflections and overshoot, board design can become a
<br>nightmare!
<p>--
<p>Rick "rickman" Collins
<p> snipped-for-privacy@XYarius.com
<br>Ignore the reply address. To email me use the above address with the
XY
<br>removed.
<p>Arius - A Signal Processing Solutions Company
<br>Specializing in DSP and FPGA design&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; URL
<a href="http://www.arius.com ">http://www.arius.com </a>
<br>4 King
Ave&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

301-682-7772 Voice
<br>Frederick, MD
21701-3110&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

301-682-7666 FAX</blockquote>
</html>

--------------53B8F2F545754BA2978FBFA8--


Re: Xilinx S3 I/O robustness question
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.


Quoted text here. Click to load it

Re: Xilinx S3 I/O robustness question
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it

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.  


Quoted text here. Click to load it

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

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness question
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....).

And yes, if you do not pay attention now, you will cause ground bounce (50 -
60 mA of reflection current per IO is possible), 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.

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.

Austin

rickman wrote:

Quoted text here. Click to load it


Re: Xilinx S3 I/O robustness question

[snip]

Quoted text here. Click to load it
(50 -
Quoted text here. Click to load it

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



Re: Xilinx S3 I/O robustness question
John_H,

Take a simple CMOS inverter inside the IC (not part of the IO).  Its switching
threshold is directly related to its ground reference, and its Vcc reference.
Any ground bounce (LdI/dt) or Vcc bounce (same formula) will move ground and
vcc around, even in a perfect bypass world, as there is no "C" used in the
spelling of "LdI/dt."

Basically, assuming perfect bypass caps, a perfect AC short, you still have
that damned LdI/dt to deal with, and the only way to deal with it is to reduce
L, dI, or increase dt, or don't switch everything at once (switch banks on
different phases of the clock).

Now add to the dI/dt that comes from switching outputs, you have a transmission
line with signals launched from chip 1, towards chips 2, and at chip 2, the
overshoot and undershoot of the mismatched signal to the t-line causes the
input clamp diodes to become forward biased.  Now you have a current, and it is
changing, so now there is an additional dI/dt into Vcc, or out of ground at the
RECEIVER.  From the clamp diodes, this current has to traverse the same path as
an output switching current, that is through the various metal layers, and the
package, to get to the ground and Vcc planes in the pcb, so LdI/dt appplies for
these signals (inputs at chip 2) as well, and because of the mismatch,
overshoot and undershoot, you add to the ground bounce/vcc bounce that is from
chip 2's outputs.

All of this shifts the switching threshold of that poor inverter (in chip 1 or
2), and the result is much more jitter than you suspected was in the design.

I have not even taken into account what dI/dt results from the reflected wave
as it comes back to the alread ON driver transistor in chip 1 (the
TRANSMITTER), and then has to go to/from Vcco and ground, which is another
added LdI/dt on top of the previous LdI/dt from the intitial switching of the
output transistor (just will make things worse from not being matched).....

To look at currents in a simulation, place a 1 ohm resistor in series with the
line, and then you can see just what dI/dt's are happening.....(so every
1mV=1mA)

Austin

John_H wrote:

Quoted text here. Click to load it


Re: Xilinx S3 I/O robustness question
Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

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?  


Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness question
Rick,

Get off that horse:  'typical' ringing is not the issue here.

Have said it a number of times:  overshoot and undershoot is bad (period), and is
a sign of a bad board design.  The fact that if you have

1) 85C Tj AND
2) you have a power supply at 3.6 volts AND
3) you have crappy SI over long t-lines (which store more energy -- like 12 -
24")

MAY lead to exceeding the Abs Max spec.

The point is that you have to simulate to get good SI, so do so.  While you are
at
it, if the SI is terrible, fix it.  If you can't fix it, then make sure you are
within the Abs Max specs.

Austin

rickman wrote:

Quoted text here. Click to load it


Re: Xilinx S3 I/O robustness question
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
will not be 3.6 volts.  So what you are now talking about is not a
typical board design, but rather a *bad* board design.  That is not what
you said.  Your statements, as well as others, was that *every* board
needs to be simulated.  I agree that clock signals are very sensitive to
signal integrity, but most data lines, that are not excessively long,
will do no hard to most chips and SI issues will only add to the setup
time.  

So if my traces are 6" and under and my Vccio is 3.3 volts or less, is
it likely that a data trace will be at issue if it is not simulated?  As
I said, this is the first time I have heard anyone say that it can be an
issue, *especially* an issue of doing damage to a chip.  

Ringing has been an accepted part of digital logic design since logic
was invented.  It is a problem, not because it exists, but only if it
creats a malfunction.  It can ring for an hour and I won't care if I
have two hours of settling time on my bus.  

If you don't wish to discuss this politely, then please feel free to
ignore my post.


Austin Lesea wrote:
Quoted text here. Click to load it
is
Quoted text here. Click to load it
24")
Quoted text here. Click to load it
are at
Quoted text here. Click to load it
-
Quoted text here. Click to load it

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness question
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


Quoted text here. Click to load it
[snip]



Re: Xilinx S3 I/O robustness question
Rick,

Sorry to have offended, but you really are arguing a lost cause.  Ignore SI?  At
your
peril.  And not (just) for relibility reasons, just plain work reasons.

As for your example, of less than 12", and 3.300V, again, I ask you to go
simulate the
exact situation you are asking about.

What impedance trace?  What strength driver?  What is(are) the load(s)?  What is
potentially coupling to the trace(s)?  Too many variables to just say:  "hey, no
problem."

By the way, I would never state "hey, no problem,"  as Murphy says, "whatever
can go
wrong, will go wrong...."     that is why we simulate.

Austin

rickman wrote:

Quoted text here. Click to load it
and is
Quoted text here. Click to load it
- 24")
Quoted text here. Click to load it
are at
Quoted text here. Click to load it
are
Quoted text here. Click to load it
(50 -
Quoted text here. Click to load it
3.0V,
Quoted text here. Click to load it
technology
Quoted text here. Click to load it
robustness
Quoted text here. Click to load it


Re: Xilinx S3 I/O robustness question
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!
     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.
     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.
     cheers, Syms.

Quoted text here. Click to load it

Re: Xilinx S3 I/O robustness question
Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness: is that your final answer?
Last post:

See below,

Austin

rickman wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Yes.


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


Re: Xilinx S3 I/O robustness: is that your final answer?
Quoted text here. Click to load it

Thank you for that comment Austin.  You are the first person to ever
call my work garbage.  


Quoted text here. Click to load it

That is the part that is not practical and I don't believe that it is
required for most signals.  Of course, the sensitivity of the Spartan 3
chips seem to place new boundries on ringing and SI.  According to what
you are saying, signal ringing can do damage to these chips while most
chips in the past have not been that sensitive to it.  


Quoted text here. Click to load it

As I said in my other posts, I have been reading absolute max specs for
years and many have specific exclusions for the brief time of over (or
under) voltage due to ringing.  A couple of ns of overvoltage has never
fried a chip in any lab that I have worked in.  


Quoted text here. Click to load it

I understand.  But your comments seem to be self contraditory.  First
you tell me the issue is SI which is common to all boards and then you
say the issue is the extreme sensitivity of the new Spartan 3 chips to
SI.  SI is always relative.  In the past the threshold of failure had to
do with delayed settling or double clocking of edge signals.  Now these
new chips are much more sensitive to a new issue, SI induced failure.
That is all we had to say and admit.  


--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Xilinx S3 I/O robustness question
Hi Rick,
    Stuff below:-

Quoted text here. Click to load it
PC's only pass because they're in metal boxes. Not everyone has that
luxury!
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Re: Xilinx S3 I/O robustness question

Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

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

Re: Xilinx S3 I/O robustness question
Quoted text here. Click to load it

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.  


Quoted text here. Click to load it

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.  


Quoted text here. Click to load it

He is not the only one who is frustrated.  My questions were not about
the issues of designing for SI, but about the sensitivity of the Spartan
3 chips to damage from ringing.  His replys are not responsive to my
comments and questions.  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.  


--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline