|
[SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system
- From: steve weir <weirsi@xxxxxxxxxx>
- To: Don Nelson <dhwn@xxxxxxx>, SI List <si-list@xxxxxxxxxxxxx>
- Date: Mon, 07 Mar 2005 11:05:11 -0800
Don, if you can obtain the before / after data and/or provide Teraspeed
with a sample board, we would be interested in analyzing this specific
example. Not only does one need to contend with the I/O resistance, but
the transmission line impedance of the in-package interconnect for an
I/O. A squirrely little 4 mil trace running 100 or more mils back to the
die attach can easily exhibit a nH or more of inductance. Now if as Dr.
Johnson said the power / ground interconnects were similarly suboptimal,
then adding I/Os as poor man's return path could help, provided you add a
LOT of them.
StratixII has a ball pattern that concentrates most of the returns into the
center ground slug with a surrounding power ring. Depending on what
application you are trying to signal, you would be wise to be mindful of
this in planning your I/O. By the way, we offer some IP to help with the
SSO problem.
Regards,
Steve.
At 12:03 PM 3/7/2005 -0500, Don Nelson wrote:
>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>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>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>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:
>>>>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>>>
>>>>>
>>>>>
>>>>>List technical documents are available at:
>>>>> <http://www.si-list.org>http://www.si-list.org
>>>>>
>>>>>List archives are viewable at:
>>>>>
>>>>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>>>>
>>>>>
>>>>>or at our remote archives:
>>>>>
>>>>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>>>>
>>>>>
>>>>>Old (prior to June 6, 2001) list archives are viewable at:
>>>>> <http://www.qsl.net/wb6tpu>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:
>>>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>>
>>>>
>>>>
>>>>List technical documents are available at:
>>>> <http://www.si-list.org>http://www.si-list.org
>>>>
>>>>List archives are viewable at:
>>>>
>>>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>>>
>>>>
>>>>or at our remote archives:
>>>>
>>>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>>>
>>>>
>>>>Old (prior to June 6, 2001) list archives are viewable at:
>>>> <http://www.qsl.net/wb6tpu>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:
>>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>
>>>
>>>
>>>List technical documents are available at:
>>> <http://www.si-list.org>http://www.si-list.org
>>>
>>>List archives are viewable at:
>>>
>>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>>
>>>
>>>or at our remote archives:
>>>
>>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>>
>>>
>>>Old (prior to June 6, 2001) list archives are viewable at:
>>> <http://www.qsl.net/wb6tpu>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:
>>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>
>>>
>>>
>>>List technical documents are available at:
>>> <http://www.si-list.org>http://www.si-list.org
>>>
>>>List archives are viewable at:
>>>
>>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>>
>>>
>>>or at our remote archives:
>>>
>>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>>
>>>
>>>Old (prior to June 6, 2001) list archives are viewable at:
>>> <http://www.qsl.net/wb6tpu>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:
>>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>>
>>>
>>>
>>>List technical documents are available at:
>>> <http://www.si-list.org>http://www.si-list.org
>>>
>>>List archives are viewable at:
>>>
>>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>>
>>>
>>>or at our remote archives:
>>>
>>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>>
>>>
>>>Old (prior to June 6, 2001) list archives are viewable at:
>>> <http://www.qsl.net/wb6tpu>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:
>><http://www.freelists.org/webpage/si-list>http://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>http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>
>>
>>
>>List technical documents are available at:
>> <http://www.si-list.org>http://www.si-list.org
>>
>>List archives are viewable at:
>>
>><http://www.freelists.org/archives/si-list>http://www.freelists.org/archives/si-list
>>
>>
>>or at our remote archives:
>>
>><http://groups.yahoo.com/group/si-list/messages>http://groups.yahoo.com/group/si-list/messages
>>
>>
>>Old (prior to June 6, 2001) list archives are viewable at:
>> <http://www.qsl.net/wb6tpu>http://www.qsl.net/wb6tpu
>>
></blockquote></x-html>
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:
http://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:
http://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:[SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system [SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system
|
|
|
[ Home |
Signup |
Help |
Login |
Archives |
Lists
]
All trademarks and copyrights within the FreeLists archives are owned
by their respective owners.
Everything else ©2008 Avenir Technologies, LLC.
|
|
|
