[SI-LIST] Re: FW: Re: Paper on BGA crosstalk and power system

  • From: steve weir <weirsi@xxxxxxxxxx>
  • To: Mark McKee <mmckee@xxxxxxxxx>
  • Date: Mon, 07 Mar 2005 15:00:36 -0800

Mark,
If you can share the data, that will be great.

Yes, some BGAs are interesting to say the least, putting us closer to case 
1), than case 2).  If you are free to identify the part then we can put 
that together with a 3D model of the package to get a complete picture of 
what we think should be happening versus the measured results.  That looks 
like something you have done some work on.

Steve.
At 02:49 PM 3/7/2005 -0800, Mark McKee wrote:
>When we've completed the measurements have results, I will share them of 
>course.  Your point of reference planes is correct - however, the 
>reference planes I've seen on some of the leading FPGA packages don't look 
>like planes, and certainly can provide a very convoluted return path.
>
>I will add that I believe package considerations such as package stack up, 
>layout, and the path the signals (and power and ground) take from the 
>balls on the package to the die play a big factor, are vender specific and 
>even FPGA family specific. Without the specific insight into those 
>factors  I'm not sure of the usefulnessof my measurements except with 
>respect to the specific vender/package I'm using.
>
>Someone on a previous email thread eluded to the relationship between the 
>ball on the package and a ground/power ball being the dominating factor I 
>believe.  I think it is wise to look deeper as we've found (through 
>package extraction and simulations) depending on how badly or how good the 
>rest of the picture might be, other things can dominate.
>
>We have looked at the details of several package stackups from several 
>leading venders.  Just like a board stackup and layout, you can imagine 
>how bad (and fortunately) how good some of the packages can be - depending 
>on the level of appreciation of the issues by the teams designing the 
>packages.
>
>All good stuff once you understand what you're up against - commending Dr. 
>Johnson for his work.
>
>Mark
>
>steve weir wrote:
>>
>>Mark,
>>
>>The stubs will couple a limited amount of energy.  I can think of two
>>extreme cases:
>>
>>1) Very poor in-package signal trace to plane coupling, perhaps 10%
>>coupling to adjacent grounded signal traces.
>>2) Very good in-package signal trace to plane coupling, very little coupling
>>
>>I would be very interested in your specific results.
>>
>>Steve.
>>
>>At 11:57 AM 3/7/2005 -0800, Mark McKee wrote:
>>
>>>
>>>Dr. Johnson, thank you for your analysis.  We have incorporated
>>>stuck-at-zero and stuck-at-one I/Os in some of our designs and have the
>>>ability to remove these so we can measure the benefit.  This was on our
>>>list of this to do during post FCS characterization plan.
>>>I have a couple of questions regarding this though.
>>>
>>>Since the board cannot be changed (tied to ground and power planes for
>>>those pins), removing the drivers from the design will leave a ground
>>>and power "stub" from the board to die and I'm wondering if you see this
>>>as having a measureable effect on this experiment?
>>>
>>>BTW, these were incorporated into the design specifically for the reason
>>>you site - i.e. for signal return path purposes.
>>>
>>>I've had one vender whose signal ratio to ground was on the order of
>>>1-to-20 tell me that if I was concerned about SSN (or the die bouncing
>>>as a result of the extremely poor signal to ground ratio) - and to say
>>>the least, my comment was to ask "why do think this will even work?" -
>>>anyway they said I could use the "virtual power and grounds" and would
>>>get a lot of benefit - which I am in disbelief - any comments?
>>>
>>>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,  <mailto:howie03@xxxxxxxxxx>howie03@xxxxxxxxxx
>>>>High-Speed Digital Design seminars, books, and articles
>>>>WILL BE IN AUSTIN IN APRIL - <http://www.sigcon.com>www.sigcon.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: <mailto:si-list-bounce@xxxxxxxxxxxxx>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: <mailto:si-list-bounce@xxxxxxxxxxxxx>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:
>>>>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>>>>
>>>>>>For help:
>>>>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>>>>> 
>>>>>><//www.freelists.org/archives/si-list>//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 <mailto:weirsp@xxxxxxxxxx>weirsp@xxxxxxxxxx e-mail address will 
>>>>>terminate March 31, 2005.
>>>>>Please update your address book with 
>>>>><mailto:weirsi@xxxxxxxxxx>weirsi@xxxxxxxxxx
>>>>>
>>>>>
>>>>>------------------------------------------------------------------
>>>>>To unsubscribe from si-list:
>>>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>>>
>>>>>For help:
>>>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>>>> 
>>>>><//www.freelists.org/archives/si-list>//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:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>>
>>>>For help:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>>> 
>>>><//www.freelists.org/archives/si-list>//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:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>>
>>>>For help:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>>> 
>>>><//www.freelists.org/archives/si-list>//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:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>>
>>>>For help:
>>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>>> 
>>>><//www.freelists.org/archives/si-list>//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:
>>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>>
>>>For help:
>>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>>> 
>>><//www.freelists.org/archives/si-list>//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 <mailto:weirsp@xxxxxxxxxx>weirsp@xxxxxxxxxx e-mail address will 
>>terminate March 31, 2005.
>>Please update your address book with 
>><mailto:weirsi@xxxxxxxxxx>weirsi@xxxxxxxxxx
>>
>>
>>------------------------------------------------------------------
>>To unsubscribe from si-list:
>><mailto:si-list-request@xxxxxxxxxxxxx>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>//www.freelists.org/webpage/si-list
>>
>>For help:
>><mailto:si-list-request@xxxxxxxxxxxxx>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:
>> 
>><//www.freelists.org/archives/si-list>//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:
//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: