Xilinx S3 I/O robustness question

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

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

Austin Lesea wrote:
> 
> 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.  

I don't understand why you feel the need to shoot the messenger.  The
hotline staff of most companies is just as Lecroy described, eager to
end the call as that is how they are evaluated.  Xilinx is no exception
and this has been noted here on more than one occasion.  

This newsgroup is a place of all of us to share our experiences and
opinions and I, for one, don't appreciate your criticism of Lecroy's
post.  If you feel his experience is not typical, then feel free to say
so, but certainly you have no expectation that he should not express his
experience or opinion.  


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

That is your opinion of how the process works.  Many people have had
different experiences.  Often it is not escalated until the customer
requests.  Overall the experience can be so frustrating that the
customer doesn't push very hard to get a real answer and gives up after
a few conversations.  

Anyone can be in denial about a problem with their company.  But that
does not make the problem go away.  The problem is also not eliminated
by comparing yourself to your competition and saying "we are better than
they are".  It can still be a problem.  


-- 

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,

Here is my 5th try to respond.  Maybe I will send it.

See below.

Austin

rickman wrote:
<snip>

>
> > 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.
>
> I don't understand why you feel the need to shoot the messenger.

I did not shoot him.  I merely mentioned that he should try to get support through the normal channels.  And if that
did not work, to contact the folks who are watching the watchers.  And not slam a service that he did not use.

>  The hotline staff of most companies is just as Lecroy described, eager to
> end the call as that is how they are evaluated.  Xilinx is no exception
> and this has been noted here on more than one occasion.

Perhaps in your mind, but to us it is deadly serious, and we deny that your comments are accurate, or truthful.  Sure,
one can get a bad answer, or a wrong answer, and occasionally an answer that did not meet your timeline;  but if that
case is closed before you say you are happy, it is cause for dismissal.

>
> This newsgroup is a place of all of us to share our experiences and
> opinions and I, for one, don't appreciate your criticism of Lecroy's
> post.

OK.  Like you said, all opinions are welcome.

>  If you feel his experience is not typical, then feel free to say
> so,

I did.

> but certainly you have no expectation that he should not express his
> experience or opinion.

He is free to say anything he wants, as are you.

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

> That is your opinion of how the process works.

No, that is the way it does work.  I helped re-write it.  And audit it.

>  Many people have had different experiences.

Then let Peter and I know:  I want dates, case numbers and names.  I want to know of any unhappy customers anywhere.
And yes, I would prefer it sent directly, not the newsgroup, so we can research it properly, and get it resolved ASAP.

>  Often it is not escalated until the customer requests.

Uh, that is how it works, the proceedure is that the customer has to say how urgent the matter is AND the time limits
have to start getting exceeded.

>  Overall the experience can be so frustrating that the
> customer doesn't push very hard to get a real answer and gives up after
> a few conversations.

Haven't met any like that.  Perhaps there are those who are so timid they can't use a hotline?  The customers that I
meet are not shy at all about demanding the best service.  And right now, if they don't get the answer, they are likely
to be part of the next layoff, so it is hard for me to see how a customer would not make every effort to get their
problem resolved.

Austin Lesea wrote:
> 
> Rick,
> 
> Here is my 5th try to respond.  Maybe I will send it.
> 
> See below.
> 
> Austin
> 
> rickman wrote:
> <snip>
> 
> >
> > > 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.
> >
> > I don't understand why you feel the need to shoot the messenger.
> 
> I did not shoot him.  I merely mentioned that he should try to get support through the normal channels.  And if that
> did not work, to contact the folks who are watching the watchers.  And not slam a service that he did not use.

You didn't shoot him with a gun, but you criticized him for "slamming"
your service which he *HAS* used and found to be lacking.  


> >  The hotline staff of most companies is just as Lecroy described, eager to
> > end the call as that is how they are evaluated.  Xilinx is no exception
> > and this has been noted here on more than one occasion.
> 
> Perhaps in your mind, but to us it is deadly serious, and we deny that your comments are accurate, or truthful.  Sure,
> one can get a bad answer, or a wrong answer, and occasionally an answer that did not meet your timeline;  but if that
> case is closed before you say you are happy, it is cause for dismissal.

I also like the way that I get survey requests on every case, but I have
never heard back from anyone when I fill one out and indicate that a
case was prematurely closed or the result was otherwise unsatisfactory.  


> > This newsgroup is a place of all of us to share our experiences and
> > opinions and I, for one, don't appreciate your criticism of Lecroy's
> > post.
> 
> OK.  Like you said, all opinions are welcome.
> 
> >  If you feel his experience is not typical, then feel free to say
> > so,
> 
> I did.
> 
> > but certainly you have no expectation that he should not express his
> > experience or opinion.
> 
> He is free to say anything he wants, as are you.

And receive criticism for giving his experiences.  


> > > 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.
> 
> > That is your opinion of how the process works.
> 
> No, that is the way it does work.  I helped re-write it.  And audit it.

But you don't execute it.  As far as I am aware you have not monitored
any of the cases described here either.  I don't believe you are in the
chain of command for the hotline.  The bottom line is that you feel the
hotline works one way and many of us have different experiences. 
Obviously our experiences are only "in our minds".  


> >  Many people have had different experiences.
> 
> Then let Peter and I know:  I want dates, case numbers and names.  I want to know of any unhappy customers anywhere.
> And yes, I would prefer it sent directly, not the newsgroup, so we can research it properly, and get it resolved ASAP.

It is seldom worth an engineers effort to persue a hotline case for more
than a couple of days, much less follow up with a bad case.  If you want
to follow up on poorly handled cases, why aren't the surveys read and
responded to?  


> >  Often it is not escalated until the customer requests.
> 
> Uh, that is how it works, the proceedure is that the customer has to say how urgent the matter is AND the time limits
> have to start getting exceeded.

So if a customer does not know that there are levels of support and the
person providing the support has run out of ideas, the customer is
expected to figure out to ask for a higher level?   Sounds pretty silly
to me.  Once engineers get familiar with support that may be automatic,
but I remember my experiences with support and just how long it took me
to learn how to navigate the support pathways to try to get to someone
who actually knows about the problem.  

I have also had the first level of support refuse to let me talk to the
engineer who actually knew something about the problem.  Instead he
insisted that he be my point of contact and that he would relay the
information back and forth to the other engineers.  Unfortunately this
required several relays just to get the question across since the second
level support kept believing that the first level was relaying the
question wrong.  

The bottom line is that many engineers refuse to contact support even
when told to.  Their experience has led them to feel that the whole
process is poor and not worth the effort.  

You can believe what you want, but this is what I have found at most of
the companines where I have worked.  This is not just my opinion, but
that of many engineers.  


> >  Overall the experience can be so frustrating that the
> > customer doesn't push very hard to get a real answer and gives up after
> > a few conversations.
> 
> Haven't met any like that.  Perhaps there are those who are so timid they can't use a hotline?  The customers that I
> meet are not shy at all about demanding the best service.  And right now, if they don't get the answer, they are likely
> to be part of the next layoff, so it is hard for me to see how a customer would not make every effort to get their
> problem resolved.

<sarcastic mode on> 
Yes, I think you are right.  The problem is not with the hotline, it is
with the customers.  Of course the hotline has been designed to provide
the best level of support under all conditions and any customer who has
less than a fully satifactory experience must have been poorly trained
or is suffering from a personality disorder. 
<sarcastic mode off> 

Denial is not just a river in Egypt.  

Enjoy your boat tour Austin. 

-- 

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 wrote:
> 
<snip>
> 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.

 Interesting. 
 So this is stress-time effect, that causes a degrade in leakage spec ?

 What time/uA orders are we talking about here ?

 Does this never cause a more drastic point failure ?

 Any idea why Lattice quote a MAX of 64 pins at IO MAX voltage stress
levels ?  (I'm bemused at how the 65th pin knows the state of the other
64 :)

- jg

Jim,

I will try to add to our knowledge below,

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> >
> <snip>
> > 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.
>
>  Interesting.
>  So this is stress-time effect, that causes a degrade in leakage spec ?

Yes.  It is interesting because it does not follow the "accepted" failure
mechanisms, and is being studied by many (not at all new, just new to us because
it is the first time we have used this particular .25u pmos transistor for 3.3v
IO).

>
>  What time/uA orders are we talking about here ?

In one set of early tests before they improved the process, we saw 6uA in 10
weeks with a peak voltage stress of ~4.5v.  The leakage started out in the nA
range.  Traditional gate breakdown is defined as a 100x increase in leakage, but
it is then usually followed by a complete gate breakdown.  The leakage stopped
increasing.

>
>
>  Does this never cause a more drastic point failure ?

Not in the testing we did.  That is what we found strange, and led to a reading
of some of the more obscure papers on voltage stresses in the public literature.

"Defect generation and breakdown of ultra-thin silicon dioxide induced by
substrate hot-hole injection" by Eric M Vogel, Journal of Appplied Physics, V90,
N5, 1 September, 2001....as one example of bedtime reading.  We concluded that
the mechanism described by this paper was NOT what we saw, but then, it wasn't
any of the other ones folks know about, either.

Baking the device at a high temperature also did not make the device recover (as
would be expected from hot electron damage, for example).

>
>
>  Any idea why Lattice quote a MAX of 64 pins at IO MAX voltage stress
> levels ?  (I'm bemused at how the 65th pin knows the state of the other
> 64 :)

There is no agreement on how to spec this:  the area under stress (number of IOs)
and temperature figure prominently in the models, but had virtually no effect in
the tests we conducted.  Now, of course, we have to stress it enough to see an
effect  (in our limited lifetimes), and one can say with some confidence that
such a stress is not going to lead to the actual failure mechanism, but may be
causing a new, and artifical failure mechanism.  Thus, we combine the older
techniques and models, with the latest data and guesses, and error on the side of
extreme caution so that we can state that if you do not exceed the abs max
numbers, the part lives it regular life.

So, 64 IOs may be just under the 15 or 20 year life projection model limit, and
65 IOs may be just over the limit in the model.  Our experience was that the
number of IOs under stress did not make a measurable difference.  I agree that it
is pretty hard to imagine that having a next door neighbor with a hot plate
increases your chances of burning down your house, but it does make sense that
overall, the more devices you have under stress, the sooner one would expect a
failure........even if we did not see that in our testing.

The most recent tests did allow us to relax the bank requirements for V2P, so now
all banks may operate at 3.3V, and it will not affect the lifetime nor the
reliability of the part (as opposed to the original banking restrictions).

It could be that they have not seen the same results in their testing from their
fab?  Turns out this is very tricky stuff, and implants, layout, etc affects the
performance of these devices under these extrememly high field stress
conditions.  There is a magic recipe that one finds, and then sticks with it
(just like any other IC process).

Austin Lesea wrote:
> >  Any idea why Lattice quote a MAX of 64 pins at IO MAX voltage stress
> > levels ?  (I'm bemused at how the 65th pin knows the state of the other
> > 64 :)
<snip> 
> So, 64 IOs may be just under the 15 or 20 year life projection model limit, and
> 65 IOs may be just over the limit in the model.  Our experience was that the
> number of IOs under stress did not make a measurable difference.  I agree that it
> is pretty hard to imagine that having a next door neighbor with a hot plate
> increases your chances of burning down your house, but it does make sense that
> overall, the more devices you have under stress, the sooner one would expect a
> failure........even if we did not see that in our testing.

Yes, I'm sure it's some arbitrary FIT number, or could be some test
equipment
limit :) - but it does raise the eyebrows ....

> 
> The most recent tests did allow us to relax the bank requirements for V2P, so now
> all banks may operate at 3.3V, and it will not affect the lifetime nor the
> reliability of the part (as opposed to the original banking restrictions).
> 
> It could be that they have not seen the same results in their testing from their
> fab?  Turns out this is very tricky stuff, and implants, layout, etc affects the
> performance of these devices under these extrememly high field stress
> conditions.  There is a magic recipe that one finds, and then sticks with it
> (just like any other IC process).

Thanks, interesting summary.

 I recall seeing a note from Philips research a couple of years ago,
about
a breakthrough in high voltage devices (> 100V) in (IIRC) 0,5u process.
 Seems what they found was thinner worked better, the opposite of what
E field stress would suggest, and they concluded it was because the
'loose electrons' has less time to accelerate, and so had less energy
with which to do serious damage :)
 Does show there is no substitute for bench tests...

-jg

It appears that Xilinx does not care to discuss their models.

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7B1765.D691F1C5@yahoo.com>...
> 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

Surely as hard as you Xilinx guys pushed simulation as the answer for
this, you would know the details of the S3 models.  Are you looking
into it?  Is the part just to new and there is no information
available at your level?