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:

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

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.

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

Andy Peters wrote:
> 
> 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.

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.  


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

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

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

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

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

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F751429.40DB59C3@yahoo.com>...
> Andy Peters wrote:
> > 
> > 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.
> 
> 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 did not say that "ringing is the cause of crosstalk."  I said that
another SI issue that you ought to be concerned about is crosstalk.  I
then went on to say that, because of crosstalk, we saw that the
badness on the data lines was being coupled to a reset line.

And, yes, simulation showed us exactly what was going on.

I'm sorry if I wasn't clear.

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

Like I said -- consider that Xilinx are erring on the side of caution.
 And, as Austin points out, one can minimize the possibility of this
sort of potential damage by performing the appropriate SI simulations,
and adjusting the layout as needed.
 
> 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.  

Again, his comments are that as chip geometries shrink and rise times
get faster, one needs to consider SI issues everywhere.   Erring on
the side of caution.

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

You know your needs better than the rest of us; I can't argue with
that.

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

Ah, but you can, if you can obtain a model of the connector you're
going to use, and assume that you've got a perfect load on the other
side.  Better than nothing.  You can also deviate from "perfection"
and see the effects on your board.

--a

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.

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.

lecroy,

See below,

Austin

lecroy wrote:

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

Unfortunate.  If you don't ask, you don't get an answer.  Try it.  If it doesn't work, let us (me) know.  You
must prefer doing everything the hardest way possible.  We also do not appreciate the slamming of our hotline
staff.  Theya re all dedicated to helping our customers succeed, as that is what sells parts, not "closed
cases."  If a hotline engineer can not resolve the problem within a fixed amount of time, it is escalated.  Once
escalated, it then goes up the ladder til it reaches someone who can resolve the issue.

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

You can not even probe, nor observe the points that are in question here.  The VNA is a frequency domain tool,
and unless you convert the S parameters into their transient form (done by some advanced simulators) you will
learn nothing at all (even after simulating or trying to measure).  "Real" only applies to this one part.  What
about the next one?

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

The test chips from UMC that had all of the transistors on them and characterized.

>
> Have they continued to update the model as parts are being tested?

Yes.  That is the procedure.

>
> How much do you trust it?

Better than the real silicon, which may be from any yielding corner, and not be representative of the worst
possible cases (fast, cold corner, with hi-voltages for example.  You can not buy a fast corner IO transistor
version of the chip, you have to simulate it.  Folks who submit their chips to a third party for IBIS models do
their customers a terrible dis-service, as the model is only as good as the sample of chips sent, which is
ususally terrible.

We must support our devices through accurate and useful models.  Fact of life (and business).

The models are an IOU:  that is what we tell you you will get.

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

General Answer:  simulate it, and make sure it meets yourt needs, and our operating and abs max specifications.

>  Just how sensitive it really is and what precautions do
> I need to take to make it work.

Already stated, if you exceed the abs max specs, you may find that more than .1% of the parts do not last the
intended operating life.  Good Signal Engineering practices will result in a robust design that will meet all
goals, and all specs and last a long, long time.

A car manufacturer was once asked, "what is the safest way to use your vehicle?"  The answer:  "don't use it at
all.  Just park it, and walk away."

So ask questions that can be answered, like sending me a plot of what you think might be a problem.  Or logging a
call to the hotline (and then letting us know if you are not completely satisfied with the answer).


>  Because each layout is different, the
> loading can be anything if you consider all of the failure modes.

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.

Simulate and you will see......

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