Xilinx S3 I/O robustness question

[Hal Murray]

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

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

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

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

 

[Austin Lesea]

Symon,

The line was 440 ps long.

I will send the simulation to you directly, as posting it here bothers the folks that have to
archive the newsgroup (no graphics or html, text only).

Austin

Symon wrote:

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.

 

[Austin Lesea]

Hal,

Simulation includes a receiver at the end of a 2ns line, and you are correct, it
makes things better.

Why simulate a driver drving nothing? Unless of course that is a possibility in
a system....not a very useful system, though....

Austin

Hal Murray wrote:

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

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

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

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

 

[Austin Lesea]

Austin,

Did both a 440 ps and a 2ns line. Not to confuse.

Austin

Austin Lesea wrote:

Hal,

Simulation includes a receiver at the end of a 2ns line, and you are correct, it
makes things better.

Why simulate a driver drving nothing? Unless of course that is a possibility in
a system....not a very useful system, though....

Austin

Hal Murray wrote:

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

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

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

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

 

[rickman]

But if you are simulating to check the possibility of damage, it seems
reasonable to allow for an unconnected trace due to a component being
left off a board intentionally or not or the possiblity of an open trace
on the board. I don't think many people would expect an open trace to
be the cause of a chip failure in a properly designed board. If you
don't analyze for this, a chip may have a higher than expected failure
rate due to typical repairable board defects.


Austin Lesea wrote:

Hal,

Simulation includes a receiver at the end of a 2ns line, and you are correct, it
makes things better.

Why simulate a driver drving nothing? Unless of course that is a possibility in
a system....not a very useful system, though....

Austin

Hal Murray wrote:

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

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

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

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

--

Rick "rickman" Collins

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

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

 

[rickman]

Hal Murray wrote:

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

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

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

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

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

--

Rick "rickman" Collins

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

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

 

[Austin Lesea]

Rick,

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

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

Still well within the datasheet limits.

Again, simulate what you are doing!

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

Austin

rickman wrote:

But if you are simulating to check the possibility of damage, it seems
reasonable to allow for an unconnected trace due to a component being
left off a board intentionally or not or the possiblity of an open trace
on the board. I don't think many people would expect an open trace to
be the cause of a chip failure in a properly designed board. If you
don't analyze for this, a chip may have a higher than expected failure
rate due to typical repairable board defects.

Austin Lesea wrote:

Hal,

Simulation includes a receiver at the end of a 2ns line, and you are correct, it
makes things better.

Why simulate a driver drving nothing? Unless of course that is a possibility in
a system....not a very useful system, though....

Austin

Hal Murray wrote:

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

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

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

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

--

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,

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

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

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

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

Austin

rickman wrote:

Hal Murray wrote:

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

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

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

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

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

--

Rick "rickman" Collins

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

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

 

[Austin Lesea]

Rick,

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

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

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

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

Austin

rickman wrote:

Symon wrote:

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

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

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

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

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

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

--

Rick "rickman" Collins

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

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

 

[Symon]

Hi Rick,
OK, I suppose 'MUST' isn't strictly accurate, you might not care
whether the design works or not! How about 'SHOULD' instead? ;-) Those
signals bouncing back and forth may not affect the circuits functional
operation, but what are you gonna do when it happens on a 5 inch, 32
bit data bus and you can't pass the CE/FCC mark tests? Sell it in
Elbonia, I guess!
As for ground bounce, if those diodes are dumping energy, be sure
you've decoupled the Rx IC as well as the Tx one! Generally, it's
better not to have to rely on the diodes, don't you think? You end up
trading decoupling capacitors for termination resistors.
I'm not saying simulate every trace. Simulate one, and layout the
rest accordingly, as I think Austin says in a parallel post. Check the
PCB layout very carefully, watching out for traces that don't comply
with your SI design. I like Austin's idea of adopting a standard
(HSTL, SSTL, PCI), makes it easy.
cheers, Syms.

rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F71115D.9CC86144@yahoo.com>...

Symon wrote:

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

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


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

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


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

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


--

Rick "rickman" Collins

 

[Austin Lesea]

John_H,

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

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

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

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

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

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

Austin

John_H wrote:

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

[snip]

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

[snip]

Austin,

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

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

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

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

Thanks for your help.

 

[Austin Lesea]

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

 

[rickman]

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

 

[rickman]

Austin Lesea wrote:

Last post:

See below,

Austin

rickman wrote:

Symon wrote:

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

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

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

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

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

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

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



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

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

Yes.

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

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

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

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

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

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


--

Rick "rickman" Collins

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,

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

 

[rickman]

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

 

[Andy Peters]

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

 

[Austin Lesea]

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

 

[rickman]

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]

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