Xilinx S3 I/O robustness question

[rickman]

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

 

[Austin Lesea]

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.

 

[Jim Granville]

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 Granville]

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

 

[lecroy]

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

 

[Austin Lesea]

All,

A reflection back to an output should not cause a problem, as the nmos is ON, or the pmos is ON, effectively
clamping the IOB pin to either gnd or Vcco. If, however, the reflections have enough current to pump up the
Vcco, then you have to be careful you do not exceed the max Vcco voltage.

It is not recommended to have poor signal integrity (ie unterminated fast edge rate signals) in any design, let
alone S3.

Austin

lecroy wrote:

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

 

[lecroy]

Austin,

I am guessing that you did not work on the design for the S3. Xilinx
has told me everything from there would be no adverse effect from a
mismatched output, to causing complete failure. I have kept all of
the correspondences if you would like me to post them, but I really
don’t see the value in doing so. I am not sure why they seem
unable to come up with an answer that they all agree upon.

I do not agree with your statement “…, as the nmos is ON,
or the pmos is ON, effectively clamping the IOB pin to either gnd or
Vcco.” . If we look at an example of an I/O pin (so not a
dedicated output), when we transition from a low to high state on the
output, the high side driver is sourcing current to the load. As the
signal propagates down our transmission line and reaches the end, some
energy will reflect back. Let’s use a very high impedance for
our termination, so the reflected signal is in phase with the
incident. As the reflected signal reaches the output pin it will
raise the voltage. Because the driver is sourcing, it has no way to
clamp this transient. So, the catch diodes would clamp the reflected
signal to a level just over the supply voltage.

It’s nice to make the comment about “is not recommended
to have poor signal integrity”, but it does not help with the
problem. If the devices MTBF decreases with the amount of reflected
energy, it would be good to know how close the impedance must be
matched. Let’s say you did all of your homework in the layout.
You have simulated every trace. Even so, most of the board houses
will not guarantee a perfect board is made. There will be a tolerance
for the board. Especially if you are playing around with FR-4. So,
then we have to ask how close do we need to match the impeadances
before we start to see an increase in the failure rates.

If this is really an issue with the S3, it will be the first time I
have seen this in a digital device. I have seen damage to some
higher-powered RF output devices when they have not been matched
correctly, due to overheating. Maybe the S3 is so sensitive that it
can be damaged this way. Had they not mentioned the S3 being so
sensitive during their presentation, I would not have tried to
investigate it.

Well, Xilinx, can you come up with an answer that you KNOW is correct?

 

[Peter Alfke]

This is a long and complex e-mail.
Let me just correct one fundamental popular misconception below:

lecroy wrote:

Austin,
I do not agree with your statement “…, as the nmos is ON,
or the pmos is ON, effectively clamping the IOB pin to either gnd or
Vcco.” . If we look at an example of an I/O pin (so not a
dedicated output), when we transition from a low to high state on the
output, the high side driver is sourcing current to the load. As the
signal propagates down our transmission line and reaches the end, some
energy will reflect back. Let’s use a very high impedance for
our termination, so the reflected signal is in phase with the
incident. As the reflected signal reaches the output pin it will
raise the voltage. Because the driver is sourcing, it has no way to
clamp this transient. So, the catch diodes would clamp the reflected
signal to a level just over the supply voltage.

This is a fairly common misconception.
A p-channel output transistor, when active, has a certain impedance, say
10 Ohm. It sources and also sinks current with that impedance . All MOS
transistors behave like resistors (at least over a certain voltage
range). They conduct current in BOTH directions. Therefore, the active
p-channel output transistor will snub the incoming reflection.
If you don't believe it, just try it out. It's a simple enough experiment.

Peter Alfke, Xilinx Applications

 

[lecroy]

I just got the following e-mail..... It has some data, but a better
article may have been:

http://support.xilinx.co.jp/xapp/xapp329.pdf

I am still looking for an answer to my question.





This is a long and complex e-mail.
Let me just correct one fundamental popular misconception below:

lecroy wrote:

Austin,
I do not agree with your statement “…, as the nmos is ON,
or the pmos is ON, effectively clamping the IOB pin to either gnd or
Vcco.” . If we look at an example of an I/O pin (so not a
dedicated output), when we transition from a low to high state on the
output, the high side driver is sourcing current to the load. As the
signal propagates down our transmission line and reaches the end, some
energy will reflect back. Let’s use a very high impedance for
our termination, so the reflected signal is in phase with the
incident. As the reflected signal reaches the output pin it will
raise the voltage. Because the driver is sourcing, it has no way to
clamp this transient. So, the catch diodes would clamp the reflected
signal to a level just over the supply voltage.

This is a fairly common misconception.
A p-channel output transistor, when active, has a certain impedance,
say
10 Ohm. It sources and also sinks current with that impedance . All
MOS
transistors behave like resistors (at least over a certain voltage
range). They conduct current in BOTH directions. Therefore, the active
p-channel output transistor will snub the incoming reflection.
If you don't believe it, just try it out. It's a simple enough
experiment.

Peter Alfke, Xilinx Applications

 

[Peter Alfke]

Let me help you, and rephrase your original question:
If a 3.3 V output on Spartan3, going active Low to active High, drives a
transmission line of arbitrary length that is open ended at the far end,
there will be a return signal that wants to pull the 3S pin higher than
Vcco = 3.3 V.
Can this cause do damage to the Spartan3 pin?

My answer would be: NO.
The returning 3.3V wave wants to pull the pin to 6.6 V, but the
transmission line impedanec is roughly 50 Ohm, and the chip pull-up
impedance is roughly 10 Ohm, so you have a voltage divider that raises
the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
resulting theoretical 3.85 voltage is really a bit lower since the
reflection is not perfect, and there are losses on the line.
Also, this spike will only last a few nanoseconds.
I would say that this poses no problem. But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

Peter Alfke, Xilinx
=============================
lecroy wrote:

I am still looking for an answer to my question.

ę

 

[Hal Murray]

The returning 3.3V wave wants to pull the pin to 6.6 V, but the
transmission line impedanec is roughly 50 Ohm, and the chip pull-up
impedance is roughly 10 Ohm, so you have a voltage divider that raises
the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
resulting theoretical 3.85 voltage is really a bit lower since the
reflection is not perfect, and there are losses on the line.
Also, this spike will only last a few nanoseconds.

I would say that this poses no problem. But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

There is nothing special about Spartan or FPGAs in this area. Right?

Is there a general rule in output pad design that the pad must
be rugged enough so that it can't shoot itself in the foot with
its own reflections? (I don't remember seeing any warnings about
this in data sheets.)

What about busses, like PCI, where the driver might be in the middle
so the effective line impedance is half of the nominal 50 ohms.
(Can it get even lower than that due to capicative loading?)

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

 

[lecroy]

Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...

What happens at 25 ohms??

My answer would be: NO.
But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

This is what I have been running into. There seems to be no one at
Xilinx who is sure. I had hoped that with this news group being a bit
more visable that I could find the right person to ask. Here is David
Anderson’s and Paul’s (who both work for Xilinx) responses
which are different from yours. In Paul's note, he even talks about
asking the factory.



*****************************************

So yes the reflected energy can still cause damage, but again if you
limit
the current to 10mA there shouldn't be any damage. This will be the
same
limitations as if this was an input. So you can refer to the max
specs
in the first page of the datasheet. See link below:
http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
Mainly you need to take a look at Vin and note 4. When VCCO is 3.0 V
or
less, VIN overshoot may go as high as VCCO + 1.0 V for up to 11 ns
provided
that the current entering the I/O pin is limited to 10 mA. Also, when
VCCO
is 3.0 V or less, VIN undershoot may go as low as -1.0 V for up to 11
ns
provided that the current entering the I/O pin is limited to 10 mA.

Hope this helps.

Regards,
David Anderson

*****************************************


Going back to your original question, the answer back from the factory
is at
3.3 V signaling, it is possible to have reflections damage the part.
If you have a particular circuit that you would like to model for you
we can
do that.

In general, IBIS simulation is the way to go in, to insure signal
integrity
(especially for high speed designs). It should be possible to use the
XCITE
technology to use a few resistors to impedance match the board layout,
assuming that most trace lengths are about the same. Should a few
signals be
much longer/shorter, XCITE or DCI can be disabled on an IO by IO
basis, and
these pins can then be terminated separately, if necessary (do IBIS
simulation to see if overshoot will be a problem).

Hope this helps,
Paul

*****************************************


I know we have gone back and forth on this, but I think the answer is
that
there is not an issue. The from what I have seen, the IO on the
Spartan III
are speced the same as the Virtex II Pro, regarding maximum voltage,
and
reflections are not an issue with Virtex II Pro.

Brain,

Please correct me if I am wrong. Again, I believe the initial
response was
wrong, and that reflections cannot damage the IO. Also, what data can
we
provide that backs our position.

Thanks,
Paul

 

[lecroy]

hmurray@suespammers.org (Hal Murray) wrote in message news:<vm9n0if1mm4fda@corp.supernews.com>...

There is nothing special about Spartan or FPGAs in this area. Right?

Well, let's see if they can answer this. My fear was that they boasted
about their lastest 90nm technology and then turned around and made a
comment about how sensitive it is to transients.

Is there a general rule in output pad design that the pad must
be rugged enough so that it can't shoot itself in the foot with
its own reflections? (I don't remember seeing any warnings about
this in data sheets.)

What about busses, like PCI, where the driver might be in the middle
so the effective line impedance is half of the nominal 50 ohms.
(Can it get even lower than that due to capicative loading?)

I agree, a very interesting question.

 

[Magnus Homann]

lecroy7200@chek.com (lecroy) writes:

hmurray@suespammers.org (Hal Murray) wrote in message news:<vm9n0if1mm4fda@corp.supernews.com>...

What about busses, like PCI, where the driver might be in the middle
so the effective line impedance is half of the nominal 50 ohms.
(Can it get even lower than that due to capicative loading?)

I agree, a very interesting question.

PCI requires that the input withstands higher voltages during 11ns, if
I recall correctly.

Homann
--
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se

 

[Eric Crabill]

Hello,

There seems to be a great deal of interest on this topic.

I can tell you what I believe to be the case, and I invite
others from Xilinx to correct what I write here, if I make
any errors. Most of this I have learned from others. As
I do not specify or guarantee device behavior, the device
datasheet takes precedence over anything I might say...

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. In the I/O itself,
there are structures that experience a "stress" that is:

* Pin voltage above GND.
* Pin voltage below VCCO.

When you are using a VCCO of 3.3 volts, you must be diligent
in your board design so that you do not have big reflections
from signal integrity problems. If you have severe reflections
when using a VCCO of 3.3 volts, you can possibly exceed the
maximum ratings of the device. Yes, there are diode clamps
on the pin, to both VCCO and GND, but with a VCCO of 3.3v,
the clamps will allow the voltage to rise above the maximum
rating of the device when VCCO is 3.3 volts.

So, when using a VCCO of 3.3v, it is a wise idea to simulate
the I/O you are using, along with your board, to make sure
you are operating the device within the maximum ratings. I
think this homework is worthwhile, even in other cases.

If IBIS models aren't your thing, and you can't be bothered
with them, you can read XAPP659 for pre-engineered solutions.

What about busses, like PCI, where the driver might be in
the middle so the effective line impedance is half of the
nominal 50 ohms.

This is discussed in detail in XAPP653. You use a VCCO of
3.0 volts. It works, is PCI compliant (even if the PCI
bus voltage VIO, which is an independent supply, rises as
high as 3.6 volts -- which is allowed). Xilinx has verified
this in hardware. The concept is that lowering VCCO to 3.0v
reduces the "stress" applied:

* (Pin voltage above GND) by clamp diode to VCCO = 3.0v.
* (Pin voltage below VCCO) by reduced VCCO = 3.0v.

An added benefit of our I/O design is that all programmable
I/O are identical, so you won't find yourself forced into a
larger part if (for example) you need more PCI capable I/O.

It is unfortunate that someone (incorrectly) suggested the
device I/O is not "robust". It is robust, and guaranteed
by Xilinx, when you use it as directed in the FPGA device
datasheet.

Hope that helps,
Eric

 

[lecroy]

Hello Xilinx, are you there???



lecroy7200@chek.com (lecroy) wrote in message news:<9297c711.0309150524.12171322@posting.google.com>...

Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...

What happens at 25 ohms??


My answer would be: NO.
But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

This is what I have been running into. There seems to be no one at
Xilinx who is sure. I had hoped that with this news group being a bit
more visable that I could find the right person to ask. Here is David
Anderson’s and Paul’s (who both work for Xilinx) responses
which are different from yours. In Paul's note, he even talks about
asking the factory.



*****************************************

So yes the reflected energy can still cause damage, but again if you
limit
the current to 10mA there shouldn't be any damage. This will be the
same
limitations as if this was an input. So you can refer to the max
specs
in the first page of the datasheet. See link below:
http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
Mainly you need to take a look at Vin and note 4. When VCCO is 3.0 V
or
less, VIN overshoot may go as high as VCCO + 1.0 V for up to 11 ns
provided
that the current entering the I/O pin is limited to 10 mA. Also, when
VCCO
is 3.0 V or less, VIN undershoot may go as low as -1.0 V for up to 11
ns
provided that the current entering the I/O pin is limited to 10 mA.

Hope this helps.

Regards,
David Anderson

*****************************************


Going back to your original question, the answer back from the factory
is at
3.3 V signaling, it is possible to have reflections damage the part.
If you have a particular circuit that you would like to model for you
we can
do that.

In general, IBIS simulation is the way to go in, to insure signal
integrity
(especially for high speed designs). It should be possible to use the
XCITE
technology to use a few resistors to impedance match the board layout,
assuming that most trace lengths are about the same. Should a few
signals be
much longer/shorter, XCITE or DCI can be disabled on an IO by IO
basis, and
these pins can then be terminated separately, if necessary (do IBIS
simulation to see if overshoot will be a problem).

Hope this helps,
Paul

*****************************************


I know we have gone back and forth on this, but I think the answer is
that
there is not an issue. The from what I have seen, the IO on the
Spartan III
are speced the same as the Virtex II Pro, regarding maximum voltage,
and
reflections are not an issue with Virtex II Pro.

Brain,

Please correct me if I am wrong. Again, I believe the initial
response was
wrong, and that reflections cannot damage the IO. Also, what data can
we
provide that backs our position.

Thanks,
Paul

 

[Austin Lesea]

lecroy,

Of course we are here, and reading.

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

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.

But let me know the case number, so I can make sure that the hotline is kept in the loop.

Austin

lecroy wrote:

Hello Xilinx, are you there???

lecroy7200@chek.com (lecroy) wrote in message news:<9297c711.0309150524.12171322@posting.google.com>...
Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...

What happens at 25 ohms??


My answer would be: NO.
But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

This is what I have been running into. There seems to be no one at
Xilinx who is sure. I had hoped that with this news group being a bit
more visable that I could find the right person to ask. Here is David
Anderson’s and Paul’s (who both work for Xilinx) responses
which are different from yours. In Paul's note, he even talks about
asking the factory.



*****************************************

So yes the reflected energy can still cause damage, but again if you
limit
the current to 10mA there shouldn't be any damage. This will be the
same
limitations as if this was an input. So you can refer to the max
specs
in the first page of the datasheet. See link below:
http://direct.xilinx.com/bvdocs/publications/ds099-3.pdf
Mainly you need to take a look at Vin and note 4. When VCCO is 3.0 V
or
less, VIN overshoot may go as high as VCCO + 1.0 V for up to 11 ns
provided
that the current entering the I/O pin is limited to 10 mA. Also, when
VCCO
is 3.0 V or less, VIN undershoot may go as low as -1.0 V for up to 11
ns
provided that the current entering the I/O pin is limited to 10 mA.

Hope this helps.

Regards,
David Anderson

*****************************************


Going back to your original question, the answer back from the factory
is at
3.3 V signaling, it is possible to have reflections damage the part.
If you have a particular circuit that you would like to model for you
we can
do that.

In general, IBIS simulation is the way to go in, to insure signal
integrity
(especially for high speed designs). It should be possible to use the
XCITE
technology to use a few resistors to impedance match the board layout,
assuming that most trace lengths are about the same. Should a few
signals be
much longer/shorter, XCITE or DCI can be disabled on an IO by IO
basis, and
these pins can then be terminated separately, if necessary (do IBIS
simulation to see if overshoot will be a problem).

Hope this helps,
Paul

*****************************************


I know we have gone back and forth on this, but I think the answer is
that
there is not an issue. The from what I have seen, the IO on the
Spartan III
are speced the same as the Virtex II Pro, regarding maximum voltage,
and
reflections are not an issue with Virtex II Pro.

Brain,

Please correct me if I am wrong. Again, I believe the initial
response was
wrong, and that reflections cannot damage the IO. Also, what data can
we
provide that backs our position.

Thanks,
Paul

 

[Symon]

Hi Peter,
If the pin has 10 Ohms of drive impedance the initial sent pulse
will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
Ohms driver drives a 50 Ohm line. The reflected signal from the
unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
then increases the voltage at the pin to 3.667, as it's driven from 50
Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
absolute maximum rating of 3.75V. Hooray!
As you say, this calculation disregards the attenuation due to
the trace propagation function, which will further reduce the
amplitude of the pulse as it travels back and forth down the
transmission line(pcb trace). This is caused by skin effect and stuff.
I guess you could also reduce the drive strength of the pin from the
default 12mA, to increase the source impedance.
The receiver pin is the one that gets the big hit.
cheers, Symon.


Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...

Let me help you, and rephrase your original question:
If a 3.3 V output on Spartan3, going active Low to active High, drives a
transmission line of arbitrary length that is open ended at the far end,
there will be a return signal that wants to pull the 3S pin higher than
Vcco = 3.3 V.
Can this cause do damage to the Spartan3 pin?

My answer would be: NO.
The returning 3.3V wave wants to pull the pin to 6.6 V, but the
transmission line impedanec is roughly 50 Ohm, and the chip pull-up
impedance is roughly 10 Ohm, so you have a voltage divider that raises
the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
resulting theoretical 3.85 voltage is really a bit lower since the
reflection is not perfect, and there are losses on the line.
Also, this spike will only last a few nanoseconds.
I would say that this poses no problem. But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

Peter Alfke, Xilinx
=============================
lecroy wrote:
I am still looking for an answer to my question.

ę

 

[Austin Lesea]

Symon,

As if often the case, if you do not run a simulation, you will not get results that are
even close to the truth (by guessing at what is happening).

With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back
at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx).

Why does this not scale exactly as you state? Because the ON resistance of the
transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground.

So, unless you simulate the actual circuit, you will not get the actual result.

Austin

Symon wrote:

Hi Peter,
If the pin has 10 Ohms of drive impedance the initial sent pulse
will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
Ohms driver drives a 50 Ohm line. The reflected signal from the
unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
then increases the voltage at the pin to 3.667, as it's driven from 50
Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
absolute maximum rating of 3.75V. Hooray!
As you say, this calculation disregards the attenuation due to
the trace propagation function, which will further reduce the
amplitude of the pulse as it travels back and forth down the
transmission line(pcb trace). This is caused by skin effect and stuff.
I guess you could also reduce the drive strength of the pin from the
default 12mA, to increase the source impedance.
The receiver pin is the one that gets the big hit.
cheers, Symon.

Peter Alfke <peter@xilinx.com> wrote in message news:<3F62569A.BB3294B0@xilinx.com>...
Let me help you, and rephrase your original question:
If a 3.3 V output on Spartan3, going active Low to active High, drives a
transmission line of arbitrary length that is open ended at the far end,
there will be a return signal that wants to pull the 3S pin higher than
Vcco = 3.3 V.
Can this cause do damage to the Spartan3 pin?

My answer would be: NO.
The returning 3.3V wave wants to pull the pin to 6.6 V, but the
transmission line impedanec is roughly 50 Ohm, and the chip pull-up
impedance is roughly 10 Ohm, so you have a voltage divider that raises
the output pin voltage by only 1/6 of the 3.3 V swing = 550 mV. The
resulting theoretical 3.85 voltage is really a bit lower since the
reflection is not perfect, and there are losses on the line.
Also, this spike will only last a few nanoseconds.
I would say that this poses no problem. But I have copied Steve Knapp,
who handles Spartan applications. He may add his opinion to this.

Peter Alfke, Xilinx
=============================
lecroy wrote:
I am still looking for an answer to my question.

ę

 

[Symon]

Hi Austin,
Agreed, the simulation is best way! My fag-packet calculation
was a worst case scenario, but still didn't exceed the specification.
Just wanted to confirm to myself there's no problem at the driver end,
and that this talk of using 3V VCCO instead of 3.3V was not needed to
be heeded! (At least for driver pin reasons.)
I imagine your simulation gets a lower value for the reflection
amplitude because the IBIS model includes rise time information and
chip capacitance, rather than variation of the transistors' impedance.
(But I'm willing to be shot down in flames!!) My calculation assumed
instant (worst case) rise time. How long was your lossless t-line? Was
the flight time longer than the rise time of the signal? (Time for
signal travel is about 180ps/in, typically.)
So, thanks for doing the simulation, I don't suppose you'd
publish the results just to put this one to bed for good?
cheers, Syms


Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F6F5B7D.7059DDE5@xilinx.com>...

Symon,

As if often the case, if you do not run a simulation, you will not get results that are
even close to the truth (by guessing at what is happening).

With a driver impedance of 8.8 ohms (from IBIS simulation), the overshoot/undershoot back
at the driver is less than 100 mV (no pcb or t-line losses, IBIS done with Hyperlynx).

Why does this not scale exactly as you state? Because the ON resistance of the
transistors is not very linear, and they are less than 8.8 ohms near Vcc or ground.

So, unless you simulate the actual circuit, you will not get the actual result.

Austin

Symon wrote:

Hi Peter,
If the pin has 10 Ohms of drive impedance the initial sent pulse
will be less than 3.3V, in fact 3.3V * 50/(10+50) = 2.75V, as the 10
Ohms driver drives a 50 Ohm line. The reflected signal from the
unterminated far end is then 2* 2.75V = 5.5V. This reflected pulse
then increases the voltage at the pin to 3.667, as it's driven from 50
Ohms into a 10 Ohm impedance to VCC = 3.3V. This is less than the
absolute maximum rating of 3.75V. Hooray!
As you say, this calculation disregards the attenuation due to
the trace propagation function, which will further reduce the
amplitude of the pulse as it travels back and forth down the
transmission line(pcb trace). This is caused by skin effect and stuff.
I guess you could also reduce the drive strength of the pin from the
default 12mA, to increase the source impedance.
The receiver pin is the one that gets the big hit.
cheers, Symon.