[SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system
- From: Don Nelson <dhwn@xxxxxxx>
- To: SI List <si-list@xxxxxxxxxxxxx>, weirsi@xxxxxxxxxx
- Date: Mon, 7 Mar 2005 12:03:41 -0500
Steve, Dr. Johnson, et al,
Thank you very much for your responses; this question of the efficacy
of stuck-low/high I/O has been troubling me as I continue with our
current design with Stratix IIs.
I will try to clarify some of the other questions as best as I can,
as I was not part of the team that tried this technique but only was
advised on dealing with the Stratix crosstalk issue. I can confirm
that the team was able to greatly reduce measured crosstalk by
converting formerly unused (and unconnected) I/O to stuck-high/low and
tying them high/low--they did not choose a bigger package to
accommodate the additional "returns". I do not believe that they
re-arranged the ball-out either, but I'm checking.
Dr. Johnson,
Your MathCad results are compelling, and seem to indicate that it is
unlikely that the additional I/O are functioning as effective signal
returns; I wonder if your findings reveal that the "stuck-low/high"
technique is not reducing inductive coupling between signals, but
rather is improving ground bounce/VCCIO droop at the die. If we assume
that there is a measurable impedance from an I/O bank's ground/VCC
rails on the die to the board's ground/VCCIO, we know that a large
di/dt from simultaneously switching outputs will result in a voltage
generated--ground bounce, or VCCIO droop. If I tie 10 stuck-low I/O
and 10 stuck-high I/O of the same I/O bank to the board rails, can I
assume that the overall impedance between the die and the board of the
power and ground has been reduced? Would that not result in a smaller
generated noise voltage for the same di/dt generated from the same
simultaneously switching outputs?
I will talk to the team who observed this effect to see of they have
any more quantitative results for me to pass along--they are famously
organized, so I'm sure they have good data. Since we are too far along
in our design to switch from Stratix to Virtex, I am *highly motivated*
to get a handle on this as early as possible! Also, I think that this
is a very interesting question and would love to understand it better.
Again, thanks to everyone who has contributed to this discussion,
-don
--
Don Nelson
The [United States] Constitution only gives you the right to pursue
happiness; you have to catch it yourself. --Ben Franklin
On Mar 7, 2005, at 2:20 AM, steve weir wrote:
> Dr. Johnson,
>
> snipped
>
>> Of course there will be engineers that use "stuck at ground" returns
>> and
>> report good results. I do not doubt that such systems work, but tend
>> to
>> believe that stuck-at-zero returns provide good benefits only when at
>> least
>> one of several conditions is met:
>>
>> 1) The IO output resistance is strikingly low (lower than commonly
>> available
>> in FPGA implementations),
>>
>> 2) The BGA power/ground patterns are particularly poor, even worse
>> than
>> either of the alternatives in my study, in which case ANYTHING would
>> be an
>> improvement,
>>
>> 3) The vias are particularly long, in which case the relationship
>> between
>> the exaggerated inductance of the long vias and the resistance of the
>> IO
>> drivers would be modified, or perhaps
>>
>> 4) There wouldn't have been much crosstalk in the first place but
>> nobody
>> ever checked.
>>
>> If there are other conditions that make these stuck-low arrangements
>> useful,
>> please write, as I would be pleased to hear about them.
>
> 5) Flux density falls by virtue of conscripting I/O's as intended
> returns
> and retiring them as aggressor signals. There is simply less current
> returning on the same common impedance as before.
>
> This is just a way of scaling the application to use a package within
> its
> limits. We don't impose more di/dt within a region than it can
> tolerate
> for the application noise / timing budgets.
>
> I agree that I don't think the connection to the return plane really
> did
> much measurable in terms of reducing return impedance. I suspect that
> given the chance to really measure a test case ( is Don's available?
> ), we
> would find as you predict, that programming the extra pins as opens
> yields
> little or no cross-talk / bounce degradation versus leaving them open.
> I
> think this idea of programming I/Os to create extra returns is in
> several
> ways analogous to the idea of using ground guard traces to reduce
> cross-talk: Observed cross-talk does fall, primarily not for any
> return
> path provided by the guard trace, but for the space needed to insert
> it.
>
>
> Regards,
>
>
> Steve.
>
> At 08:29 PM 3/6/2005 -0800, Dr. Howard Johnson wrote:
>> Dear Tegan et. al.,
>>
>> I'm traveling this week teaching in Boston and so can't respond
>> quickly to
>> all inquiries, but I'll do what I can tonight about two subjects:
>> using
>> stuck-at-zero I/O pins as returns, and the overall magnitude of
>> crosstalk.
>>
>> The question of using I/O pins as additional grounds is an intriguing
>> one,
>> and something I would like to share with you, as there doesn't seem
>> to have
>> been much quantitative information published about the efficacy of
>> that
>> approach.
>>
>> What I would like to show is that the effective output RESISTANCE of
>> the I/O
>> driver has a keen impact on its ability to serve as a stuck-low
>> ground-return pin (or stuck-high power return pin).
>>
>> In my simple scenario I will consider only four pins, in order that
>> this
>> result might be easily corroborated (or refuted) by others. The same
>> principle extends easily to other situations.
>>
>> Imagine a BGA package with only four pins located at the following
>> purely
>> real positions in the complex plane: 0, 2*p, 3*p and 4*p, where p is
>> the
>> ball pitch (0.040 in. in the problem under discussion). If you would
>> like,
>> my approach can do other locations including complex 2-D patterns as
>> well,
>> but let's start with these four.
>>
>> I will plan for location zero to be a permanent ground ball.
>> 2*p will be a victim location
>> 3*p will be an IO that we plan to leave stuck low, and connected to
>> ground,
>> 4*p will be an aggressor ball.
>>
>> So in plan view the vias appear in a straight line, like this:
>>
>> Ground Nothing Victim IOstucklow Aggressor
>>
>> The ball height H will be 0.025 in. (that's 20-mil of ball plus 5-mil
>> of
>> via), and I assume an effective radius R of the ball/via combination
>> of
>> 0.005 in. (that's radius, not diameter).
>>
>> As in any linear circuit theory problem, I represent the circuit as a
>> system
>> of matrices. I calculate the mutual inductances between each current
>> pathway
>> and each relevant voltage loop in the circuit. I then express the
>> constraints that the voltages around each loop must sum to zero, as
>> must the
>> currents into each node. Solving this system of equations (using
>> MathCad)
>> gives me a transfer function for the crosstalk from aggressor to
>> victim.
>>
>> I then drive a 1.5-volt, 500-ps step through the aggressive ball into
>> a
>> 50-ohm load and examine the crosstalk in the victim. My program
>> draws the
>> entire step response, and I report here the peak values (the crosstalk
>> waveform looks very much like the measured pictures in my paper: a
>> well-damped pulse).
>>
>> I extract the PEAK value from the time-domain result, and repeat the
>> experiment for SEVERAL VALUES OF IO RESISTANCE.
>>
>> Here is the peak crosstalk, in mV, versus IO resistance:
>>
>> R (ohm) Xtalk (mV)
>>
>> .001 5
>> 2 17
>> 4 21
>> 6 24
>> 8 25
>> 10 25
>> 1E+12 27
>>
>> When the resistance is low, the IO pin functions effectively as a
>> return
>> pathway, reducing the crosstalk to 5 mV. As the resistance rises, the
>> IO pin
>> functions progressively less well until crosstalk floats up to a value
>> commensurate with not having the IO return (27 mV).
>>
>> My conclusion from this experiment is that the I/O resistance in this
>> configuration must be very small (less than two ohms) in order for a
>> stuck-low IO driver to provide much beneficial effect.
>>
>> The general principle of stuck-low return paths is that the
>> resistance of
>> the driver must be at least comparable to (or hopefully lower than)
>> the
>> inductive impedance of that ground location, or else the IO resistance
>> prevents the stuck-at-low output from achieving your goal of noise
>> reduction. In the present case, a stuck-low IO of 10 ohms right next
>> door
>> provides no perceptible improvement that you don't already get from a
>> grounded ball three doors further away.
>>
>> Let's step back and look at this another way: in a 50ohm world if your
>> signal:ground ratio is 10:1, then when all ten IO's swing low what
>> you are
>> really doing is driving each local ground pin with an impedance of
>> 50/10 =
>> five ohms. If you want to limit crosstalk to less than twenty percent
>> of the
>> signal swing, you had better provide at every ground location an
>> impedance
>> to ground of less than 1 ohm. I claim you won't achieve this with a
>> stuck-at-low IO driver.
>>
>> I ran this sort of simulation years ago at the request of my mentor,
>> Martin
>> Graham, and assumed that the issue of resistive IO returns was
>> well-understood. Sorry I didn't make my views more explicit in the
>> paper.
>>
>> Of course there will be engineers that use "stuck at ground" returns
>> and
>> report good results. I do not doubt that such systems work, but tend
>> to
>> believe that stuck-at-zero returns provide good benefits only when at
>> least
>> one of several conditions is met:
>>
>> 1) The IO output resistance is strikingly low (lower than commonly
>> available
>> in FPGA implementations),
>>
>> 2) The BGA power/ground patterns are particularly poor, even worse
>> than
>> either of the alternatives in my study, in which case ANYTHING would
>> be an
>> improvement,
>>
>> 3) The vias are particularly long, in which case the relationship
>> between
>> the exaggerated inductance of the long vias and the resistance of the
>> IO
>> drivers would be modified, or perhaps
>>
>> 4) There wouldn't have been much crosstalk in the first place but
>> nobody
>> ever checked.
>>
>> If there are other conditions that make these stuck-low arrangements
>> useful,
>> please write, as I would be pleased to hear about them.
>>
>> If anyone has some quantitative data showing improvements due to
>> stuck-at-low implementations, and can turn the stuck-at-low pins to a
>> tri-state condition to show how much difference they really make, I
>> would
>> like to see the data.
>>
>> Also, if any of you field theory gurus would like to check my
>> implementation
>> of the equations I would be pleased to send you a copy when I return
>> to my
>> office March 14th.
>>
>> Lastly, you may have heard some recent comments to the effect that
>> maybe 300
>> millivolts of crosstalk "isn't too bad" for a high speed system.
>>
>> Please remember that every digital link has a noise budget. Even if
>> you
>> don't write it down, the spread between what your transmitter
>> produces and
>> what your receiver needs is a finite, rather small number. Within this
>> budgetary constraint you must fit all the ground bounce, BGA
>> crosstalk, pcb
>> crosstalk, connector crosstalk, ringing, and other external noise you
>> expect
>> in your system. Allocating your entire noise budget to any one
>> particular
>> sort of noise without considering other factors may be a poor choice.
>>
>> Best regards,
>> Dr. Howard Johnson, Signal Consulting Inc.,
>> tel +1 509-997-0505, howie03@xxxxxxxxxx
>> High-Speed Digital Design seminars, books, and articles
>> WILL BE IN AUSTIN IN APRIL - www.sigcon.com
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: si-list-bounce@xxxxxxxxxxxxx
>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On
>> Behalf Of Tegan Campbell
>> Sent: Friday, March 04, 2005 9:10 AM
>> To: SI List
>> Subject: [SI-LIST] FW: Re: Paper on BGA crosstalk and power system
>> (Altera
>> Responds)
>>
>> Originally sent to Don, he suggested this might be interesting to
>> everyone.
>>
>> Tegan
>>
>>
>> Don,
>> I am no expert on in-package crosstalk, but the biggest contributing
>> factor
>> to inductive crosstalk is how far away from a reference pin you
>> are(if I
>> remember my physics). So, it seems that if you tie an I/O to a
>> reference
>> near pins that are actively sourcing/sinking current, wouldn't that
>> reduce
>> the loop area AND the shared currents through dedicated ground pins?
>> If I'm
>> thinking about this correctly, what your team did is akin to what the
>> Xilinx
>> package designers force on you: a lot of pwr/gnd pins spread out
>> around the
>> package to reduce ball/ball crosstalk.
>> Personally, I look at the results and say to myself "Hmm, I'd rather
>> have a
>> few more signal pins and more crosstalk."
>> Anyway, that's how I view it. We've done the same thing before in
>> large
>> FPGA designs before we even looked at signals.
>> Just my $.02.
>> Tegan
>>
>> -----Original Message-----
>> From: si-list-bounce@xxxxxxxxxxxxx
>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On
>> Behalf Of Don Nelson
>> Sent: Friday, March 04, 2005 8:51 AM
>> To: SI List
>> Subject: [SI-LIST] Re: Paper on BGA crosstalk and power system (Altera
>> Responds)
>>
>> Thank you for your reply, Steve.
>> One of the reasons that this debate between Xilinx and Altera is
>> relevant to me is that our team is currently deciding between the
>> Virtex-4 and the Stratix II for our next product. Another group at my
>> company used the Stratix I series and experienced excessive--and
>> crippling, in their application--SSO noise. They were able to improve
>> matters *tremendously* by taking several unused outputs and internally
>> driving them high or low, then tying them to the board ground or
>> respective power plane.
>>
>> I have been trying to figure out how (if at all) this fits in with the
>> measurements made by Howard Johnson and Mark Alexander. It seems to
>> me
>> that if tying the stuck-high/low outputs to power/ground made a
>> measurable difference in SSN, the power/ground bounce they were
>> observing must have been due to PDN impedance in the die, rather than
>> inductive crosstalk, since these newly purposed i/o would not attach
>> to
>> the package power and ground planes. Their efforts may have reduced
>> the impedance of the PDN, but would not have a significant effect on
>> the inductive coupling between the signal I/Os in the package as
>> demonstrated by Howard and Mark. Indeed, I doubt that sticking a
>> driven-and-tied-low ball in the middle of a 'return void' in the
>> Stratix II ball grid would have resulted in much of a change for
>> Howard's and Mark's results if they were observing package inductive
>> coupling effects (would it?)--Howard Johnson said that he determined
>> the on-chip decoupling to be nearly ideal in both devices. Would not
>> the circuitous return path through a stuck-hi/low I/O be of little
>> help
>> in alleviating inductive coupling of signal I/O?
>>
>> Based on all of these assumptions, my thought is that if Altera
>> managed
>> to improve the on-die decoupling for their Stratix II, the SSN effect
>> seen by our other team with the Stratix I may have been addressed in
>> Stratix II, and that adding extra driven-and-tied-low I/Os wouldn't
>> help any potential SSN problems with Stratix II.
>>
>> Does my reasoning seem even the slightest bit reasonable?
>>
>> Thanks,
>> -don
>>
>> P.S. Your and Scott McMorrow's DesignCon 2005 papers on the Teraspeed
>> web site have been very helpful in designing our board-level PDN. It
>> was a great piece of work!
>> --
>> Don Nelson
>> The [United States] Constitution only gives you the right to pursue
>> happiness; you have to catch it yourself. --Ben Franklin
>>
>> On Mar 4, 2005, at 6:54 AM, steve weir wrote:
>>
>>> Don, the different tests evaluate different characteristics.
>>>
>>> While Altera notes a number of measures they have taken to make their
>>> offering compelling, there is no free lunch. I believe that the
>>> cross-talk
>>> demonstrated by Dr. Johnson's models and experiments done for Xilinx
>>> is
>>> real, and is due to the sparse return paths in the I/O fields on the
>>> StratixII parts tested. However, the next question should IMO be:
>>> how
>>> much do these differences matter to applications any given user would
>>> consider? Altera notes that Vil even with all signals in a bank
>>> switching
>>> does not get violated. What they do not comment on is timing
>>> push-out. We
>>> can of course turn that around and apply the same reasoning to the
>>> Xilinx
>>> test results.
>>>
>>> We aren't going to get that answer from IBIS models that lack
>>> cross-talk
>>> effects from the PDN. ( See one of Chris Cheng's repeated points. )
>>> So,
>>> while Altera has apparently used a reasonable method to conduct their
>>> evaluation, just as Xilinx via Dr. Johnson used reasonable methods in
>>> their
>>> experiments, they each evaluate separate phenomena. I do not believe
>>> that
>>> either test is adequate to draw conclusions on the suitability of
>>> either
>>> part to a given application.
>>>
>>> There is probably quite a bit of opportunity here to do some papers
>>> that
>>> compare what can be done with each part for a particular type of
>>> application, and what has to be done in the external environment to
>>> really
>>> achieve that performance.
>>>
>>> Steve.
>>>
>>> At 12:49 PM 3/3/2005 -0500, Don & Melissa Nelson wrote:
>>>> I thought that you all might be interested in reading Altera's
>>>> response
>>>> to the the recent Xilinx Webinar:
>>>> http://www.altera.com/literature/wp/signal-integrity_s2-v4.pdf
>>>>
>>>> I'm hardly qualified to comment on this, but they do raise some
>>>> interesting points. However, they seem to be limiting their
>>>> analysis
>>>> of Xilinx to simulations (understandable, as Virtex-4s are hard to
>>>> come
>>>> by right now) and they don't comment on the i/o strength selected
>>>> for
>>>> each device.
>>>>
>>>> Interestingly, they seem to confirm Xilinx's claim that the ground
>>>> bounce can reach 300mV, but note that, for HSTL-II at least, this is
>>>> still within the Vil allowance.
>>>>
>>>> I would be very interested to hear an expert comment on the test
>>>> methodology of this paper compared with Xilinx's, which seemed quite
>>>> rigorous to my inexperienced eyes.
>>>>
>>>> cheers,
>>>> -don
>>>> --
>>>> Don Nelson
>>>> Sr. Hardware Development Engineer
>>>> Marconi Corporation, Plc.
>>>> Pittsburgh, PA 15086
>>>> (724) 742-6044
>>>>
>>>> The [United States] Constitution only gives people the right to
>>>> pursue
>>>> happiness; you have to catch it yourself. --Ben Franklin
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------
>>>> To unsubscribe from si-list:
>>>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
>>>> field
>>>>
>>>> or to administer your membership from a web page, go to:
>>>> //www.freelists.org/webpage/si-list
>>>>
>>>> For help:
>>>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>>>
>>>> List FAQ wiki page is located at:
>>>> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>>
>>>> List technical documents are available at:
>>>> http://www.si-list.org
>>>>
>>>> List archives are viewable at:
>>>> //www.freelists.org/archives/si-list
>>>> or at our remote archives:
>>>> http://groups.yahoo.com/group/si-list/messages
>>>> Old (prior to June 6, 2001) list archives are viewable at:
>>>> http://www.qsl.net/wb6tpu
>>>>
>>>
>>> The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
>>> Please update your address book with weirsi@xxxxxxxxxx
>>>
>>>
>>> ------------------------------------------------------------------
>>> To unsubscribe from si-list:
>>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>>
>>> or to administer your membership from a web page, go to:
>>> //www.freelists.org/webpage/si-list
>>>
>>> For help:
>>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>>
>>> List FAQ wiki page is located at:
>>> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>
>>> List technical documents are available at:
>>> http://www.si-list.org
>>>
>>> List archives are viewable at:
>>> //www.freelists.org/archives/si-list
>>> or at our remote archives:
>>> http://groups.yahoo.com/group/si-list/messages
>>> Old (prior to June 6, 2001) list archives are viewable at:
>>> http://www.qsl.net/wb6tpu
>>>
>>>
>>
>>
>> ------------------------------------------------------------------
>> To unsubscribe from si-list:
>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>
>> or to administer your membership from a web page, go to:
>> //www.freelists.org/webpage/si-list
>>
>> For help:
>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>
>> List FAQ wiki page is located at:
>> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>
>> List technical documents are available at:
>> http://www.si-list.org
>>
>> List archives are viewable at:
>> //www.freelists.org/archives/si-list
>> or at our remote archives:
>> http://groups.yahoo.com/group/si-list/messages
>> Old (prior to June 6, 2001) list archives are viewable at:
>> http://www.qsl.net/wb6tpu
>>
>> ------------------------------------------------------------------
>> To unsubscribe from si-list:
>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>
>> or to administer your membership from a web page, go to:
>> //www.freelists.org/webpage/si-list
>>
>> For help:
>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>
>> List FAQ wiki page is located at:
>> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>
>> List technical documents are available at:
>> http://www.si-list.org
>>
>> List archives are viewable at:
>> //www.freelists.org/archives/si-list
>> or at our remote archives:
>> http://groups.yahoo.com/group/si-list/messages
>> Old (prior to June 6, 2001) list archives are viewable at:
>> http://www.qsl.net/wb6tpu
>>
>>
>>
>> ------------------------------------------------------------------
>> To unsubscribe from si-list:
>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>
>> or to administer your membership from a web page, go to:
>> //www.freelists.org/webpage/si-list
>>
>> For help:
>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>
>> List FAQ wiki page is located at:
>> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>
>> List technical documents are available at:
>> http://www.si-list.org
>>
>> List archives are viewable at:
>> //www.freelists.org/archives/si-list
>> or at our remote archives:
>> http://groups.yahoo.com/group/si-list/messages
>> Old (prior to June 6, 2001) list archives are viewable at:
>> http://www.qsl.net/wb6tpu
>>
>
> The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
> Please update your address book with weirsi@xxxxxxxxxx
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> //www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
