[SI-LIST] Re: Internal package aggressors/PCB routing
- From: agathon <hreidmarkailen@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Wed, 24 Jan 2007 00:40:24 -0800
"Obviously, step 2 stim can be derated by step 1 results, by breaking into N
sims instead of 1,..."
Actually, it could remain 1 sim. X is derated by sum of return currents
from step 1. This 1 sim is done for each x,y1...yn data pattern where each
driver is 1 UI, so pattern is n+1 bits. Each driver uses a 1 or 0 single
pulse.
On 1/23/07, agathon <hreidmarkailen@xxxxxxxxx> wrote:
>
> Sorry for the delay in replying.
>
> "Afterall, if you truly have done what you said and measured against what
> you simulate, you would have picked it up very quickly."
> It's bad to just assume. What makes you think I'm even interested in SSN
> deep quicksand? Siwwy wabbit.
>
> "In step 2, your return coupling sum will be excessive without negative
> feedback."
> In step 2 I measure V xtalk on N aggressors; what is "return" here?
> Actually, you did find on of the duly placed defects. Clever fellow.
>
> "So you now have to re-sum your coupling again in 2), do 3) again, so on
> and so forth."
> I don't see how this fixes the problem.
>
> Lesson 3 commences to solve the defect ...
>
> Obviously, step 2 stim can be derated by step 1 results, by breaking into
> N sims instead of 1, and instead of using it in step 3 as I originally have
> it. Each of the N is derated by each corresp. sim in step 1.
> Also, it's obvious the stim in 1 and measurements in 2 must be consistent
> regarding "0" or "1".
> Further, this assumes linearity in the x driver slew rate effect. This is
> easily true for the weak couplers. Separate linear function deratings on
> x's edge rate can be done for sets of aggressors, then combined where
> necessary.
>
> Shame on you. Now you really must pay. I insist. :-)
> PS: There is one last defect, though of minimal impact I believe. Can
> you find it? Hint: step 1 & accuracy of return current. Or, a chicken &
> egg dilemma. Some initial looping of derating each aggressor AND x may be
> needed to converge on V waveforms for both.
> Higher order effects (multiple aggressors) at this stage are ignored.
>
> "BTW, nothing you mentioned below is new or innovative."
> I am so glad to be so informed. I was a little worried, if you look back
> to my original email. Yes, grasshopper, nothing is new under the Sun. Such
> has been written before.
>
> "As we dig deeper and deeper, it is clear to me you just talked about your
> ideas and have never actually done it yourself."
> We? You and what army? Keep digging. Yet, this may be true. But
> irrelevant. I believe my solution, by thought process alone, is potentially
> worth more than the efforts of 50 wanderers digging in the desert. Maybe
> not. I fully accept the possible existence of any number of unrealized
> obstacles to making my solution a cost saver in the end. I give you leave
> to try my method.
> Again, if it works I insist you pay up. ;->>
>
> As we can see (there's that "we" again), I've dug a little deeper in that
> hole and found that you haven't used the correct shovel.
> Further, here's a tidbit you may have overlooked, hopefully what ibis
> authors you mentioned are working on - already perhaps doable with
> Verilog-AMS since IBIS is inherently inextensible, requiring more hacks &
> special sections than some CAD pgms have switches & menus:
> Method to characterize ibis driver for N aggressors' return currents, as
> described above. Ie: Have N sections with curves of return or xtalk current
> vs. delta-slew-rate. Then model could be used in a smaller set of sims
> using single-driver (the virtual victim). The sims would emulate the
> presence of N aggressors. Recap: The "single driver" is the victim line in
> the present method. Reciprocity is used to emulate N aggressors. This
> should be the further natural goal of behavioral models: express the impact
> of multiple components in a system, not just replace each instance.
>
> Regards,
> Agathon
>
>
> On 1/18/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
> >
> > Not quite.
> > In step 2, your return coupling sum will be excessive without negative
> > feedback.
> > When you go to step 3, your excessive return coupling will results in
> > too much feedback correction and your individual victim/aggressor will have
> > worst than expected edge rate degradation i.e. too little coupling to
> > the others. So you now have to re-sum your coupling again in 2), do 3)
> > again, so on and so forth.
> > I don't believe this will be fundamentally diverging. But on a strong
> > coupling case you may have to loop quite a few more times.
> > BTW, nothing you mentioned below is new or innovative. Credit it to the
> > late Larry Rubin (now that's a true Master) of Quad Design fame who first
> > have this discussion with me way back in early 90's when he tried to move
> > from TLC to XTK and do SSO at the same time. I pointed out the problem then
> > and I will point out the problem now.
> > The point is not whether you can eventually work the problem out, it is
> > at the beginning when you yap about how trivia the problem is and people
> > should pay you for the obviously simple minded methodology that now you have
> > to correct over and over again. As we dig deeper and deeper, it is clear to
> > me you just talked about your ideas and have never actually done it
> > yourself. Afterall, if you truly have done what you said and measured
> > against what you simulate, you would have picked it up very quickly.
> > ________________________________
> >
> > From: si-list-bounce@xxxxxxxxxxxxx on behalf of agathon
> > Sent: Wed 1/17/2007 2:19 AM
> > To: si-list@xxxxxxxxxxxxx
> > Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> >
> >
> >
> > Chris,
> > Aha! The next problem dilemma...
> > Should I answer and get no reward ...
> > ... or ignore it and suffer possible decrement at the hands of the
> > master?
> >
> > Feels like Super Mario. :-)
> >
> > First, my solution works best for a limited region, esp. where these
> > package
> > effects are out of scope of already taken care of.
> >
> > first:
> > Net "x" is eventual victim in final analysis.
> > Nets y1, y2, ... yN are final analysis aggressors.
> > Stims are only done with roles reversed, as below in "reciprocal xtalk".
> > Reciprocity is used to effect the above roles.
> >
> > Your new problem: Aggressors' return current on x driver:
> > 1. First, stimulate yn, n=1...N, each alone. N sims. In each sim,
> > measure
> > return current at location of interest for x driver. Add 'em up. Use 1
> > UI
> > one and zero and you have a building block for any pattern. The sum is
> > the
> > xtalk return for net x, what you asked.
> >
> > Reciprocal xtalk...
> > 2. Proceed as previously stated: stim x, measure xtalk on y1,...,yN &
> > sum.
> > That's the total xtalk on victim x, by reciprocity. This assumes all yn
> >
> > will have same pattern as x. If not then, before sum, change x stim to
> > get
> > different effect on selected y where they will have different stim as
> > aggressors. Ie: different pattern (or 1/ 0 UI) per each y net.
> > 3. Run x w/o coupling but w/ return current effect with ICVS or whatever
> > at
> > the appropriate driver node, controlled by result from #1 above. Post
> > sim,
> > add in #2 xtalk at measurement node for x. Simmer for 3 hrs. Serve
> > straight from stove.
> > 4. Send me money if it works.
> >
> >
> > Regards,
> > Agathon
> > ----------
> >
> >
> >
> > On 1/16/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
> > >
> > > >The method I described ...blah blah blah.... superposition applies =
> > > again.
> > >
> > > Here is a new problem for you, those return signals has a negative =
> > > feedback effect on the driver itself. The higher the coupling, the =
> > > slower the edge rate the less noise gets in. This is another reason
> > why =
> > > SSO noise doesn't blows up beside the spatial degradation of noise. =
> > > Without the negative feedback on the driver, your superposition will =
> >
> > > blow up if there is sufficient aggressor and the spatial coupling does
> > =
> > > not drop off fast enough. In reality that doesn't happen.
> > > This is something those IBIS 4.1 guys picked up when they realise they
> > =
> > > need to account for pre-driver feedback. Something I have published on
> > =
> > > papers since the early 90's and the IBM people knew since the 70's.
> > > How does your superposition works in the presence of negative feedback
> > ?
> > >
> > > -----Original Message-----
> > > From: si-list-bounce@xxxxxxxxxxxxx
> > > [mailto:si-list-bounce@xxxxxxxxxxxxx ]On Behalf Of agathon
> > > Sent: Monday, January 15, 2007 11:10 PM
> > > To: si-list@xxxxxxxxxxxxx
> > > Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> > >
> > >
> > > Chris,
> > > "How will your superposition work if the aggressors are asynchronous
> > to =
> > > each
> > > other ?"
> > >
> > > A: So make 'em asynchronous. They won't mind a bit (er, a UI). How
> > you =
> > > use
> > > the xtalk info is up to you. I know some ways from practice (heh
> > heh). =
> > > The
> > > superposition works, period. How will YOUR simulations work if the
> > > aggressors are asynchronous?
> > >
> > > "How will your superposition work if the crosstalk is never saturated
> > =
> > > inside
> > > the package and the switching current is depending on the external =
> > > loading
> > > that the package designer has no priori knowledge ?"
> > >
> > > A:
> > > Saturation? I guess this means the backward capacitive xtalk is
> > max'd =
> > > out
> > > for the entire bit period or other window of concern, yes? Again, how
> > =
> > > will
> > > YOURS work? No a priori knowledge? Well, game over then. Just do a
> > =
> > > wild
> > > ass guess (WAG) and be done wid it.
> > > Actually... apply some std loading as a reference. The "std" usually
> > > defines a bunch of those, anyway.
> > >
> > > The method I described doesn't "care". It uses 1 UI pulse; you apply
> > =
> > > the
> > > brain's frontal lobe to do the rest. Ie: change occurrence (UI =
> > > boundaries
> > > or not) of the multiple aggressors' xtalk as you wish; they were the =
> > > victims
> > > in 1st pass. Next, you add their xtalk directly to the single
> > victim's
> > > response, w/o any xtalk environment (which effect was already found);
> > it =
> > > was
> > > the aggressor from the 1st sim. This is a "peak distortion"
> > procedure. =
> > > You
> > > will find the unsaturated boundaries prit' near quick, I reckon. The
> >
> > > duration involved is pretty small for a pkg. Then go to pkg+board
> > sims. =
> > > If
> > > I understand, superposition applies again.
> > >
> > > Moral of the story: Linear time invariance w/ reciprocity is our =
> > > friend.
> > > Remember "Young Frankenstein" the movie? Frennnnndd!
> > >
> > >
> > > On 1/15/07, Chris Cheng <Chris.Cheng@xxxxxxxxxxxx> wrote:
> > > >
> > > > Because the observation was made on real measurements not a =
> > > simulation.
> > > > How will your superposition work if the aggressors are asynchronous
> > to =
> > > =3D
> > > > each other ?
> > > > How will your superposition work if the crosstalk is never saturated
> > =
> > > =3D
> > > > inside the package and the switching current is depending on the =3D
> > > > external loading that the package designer has no priori knowledge ?
> >
> > > > It goes back to my opinion last week, if your package/PCB is poorly
> > =
> > > =3D
> > > > constrained, no amount of simulation will save you.
> > > >
> > > > -----Original Message-----
> > > > From: si-list-bounce@xxxxxxxxxxxxx
> > > > [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of agathon
> > > > Sent: Monday, January 15, 2007 1:17 PM
> > > > To: si-list@xxxxxxxxxxxxx
> > > > Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> > > >
> > > >
> > > > Hello,
> > > > Agreed.
> > > > In addition, to try to contribute to the "overview" or just resolve
> > my
> > > > misperception, why should the xtalk aggressor/victim selections be
> > as
> > > > stated: 1 victim, multiple aggressors ? That assumes, a priori, we
> > =
> > > can
> > > > perfectly select aggressors, which is not the case. A
> > self-evincing =
> > > =3D
> > > > method
> > > > would be the reverse, with superposition: There are N
> > experiments. =
> > > In
> > > > each, take a net as agressor. Use a 1 UI pulse. Record the xtalk
> > of
> > > > interest in a large neighborhood. By reciprocity, the sum is the =
> > > xtalk =3D
> > > > that
> > > > will appear on that net as victim (in the original
> > arrangement). And =
> > > =3D
> > > > ...
> > > > viola ... you've found the return path effects
> > automatically. Uh... =
> > > =3D
> > > > isn't
> > > > this the way it's done by all, or just me?
> > > >
> > > > Regards,
> > > > Agathon
> > > >
> > > >
> > > > On 1/12/07, Henry J. Campbell <hankcampbell@xxxxxxxx> wrote:
> > > > >
> > > > > This is one of those examples where we learn a lot more from an
> > =3D
> > > > overview
> > > > > explanation than we would have even from a direct answer to a =
> > > specific
> > > > > question.
> > > > > Great job! HJC
> > > > >
> > > > > At 11:08 AM 1/12/2007, you wrote:
> > > > > >Ray,
> > > > > >I wish crosstalk in packages is as simple as flagging the
> > neighbor =
> > > =3D
> > > > =3D3D
> > > > > >traces.
> > > > > >Unlike most of the PCB boards, large BGA packages tends to use a
> > =
> > > lot =3D
> > > > of =3D3D
> > > > > >blind and buried vias. Power and ground planes are highly meshed
> > =
> > > and =3D
> > > > =3D3D
> > > > > >with evil degassing holes. A lot of times I found the crosstalk =
> >
> > > does =3D
> > > > not
> > > > > =3D3D
> > > > > >come from the traces to traces coupling but rather from the
> > current =
> > > =3D
> > > > =3D3D
> > > > > >return path overlapping each other on the reference
> > planes.=3D3D20
> > > > > >A while ago there was a thread about someone challenging the need
> > =
> > > for =3D
> > > > =3D3D
> > > > > >ground via drills for return vias. I have used an example in =
> > > package =3D
> > > > =3D3D
> > > > > >crosstalk and I will use the same here. Every time a group of
> > slow =
> > > =3D
> > > > speed
> > > > > =3D3D
> > > > > >nets hundreds of mils aways switch, the victim line take a huge
> > =3D
> > > > glitch. =3D3D
> > > > > >If you purely use the seperating distance to estimate the =
> > > crosstalk, =3D
> > > > the
> > > > > =3D3D
> > > > > >amplitude will be near zero. What really happen was there was
> > =3D3D
> > > > > >insufficient return vias on the reference plane for those slow =
> > > speed =3D
> > > > =3D3D
> > > > > >signal and the return current decided to take the nearest vias =
> > > which =3D
> > > > is =3D3D
> > > > > >right next to the critical victim lines.=3D3D20
> > > > > >I believe that's exactly why Al Ruehli and friends developed PEEC
> > =
> > > to =3D
> > > > =3D3D
> > > > > >estimate those crosstalk for TCM modules back in the 70's.
> > Because =
> > > =3D
> > > > they =3D3D
> > > > > >realize the return path is just as critical as the signal traces
> > =
> > > =3D3D
> > > > > >themselves in a highly meshed substrate. Things just don't change
> > =
> > > =3D
> > > > that =3D3D
> > > > > >much since then, electrons move the same then and now, =3D
> > > > unfortunately.=3D3D20
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: si-list-bounce@xxxxxxxxxxxxx
> > > > > >[mailto: si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Ray Anderson
> > > > > >Sent: Friday, January 12, 2007 10:08 AM
> > > > > >To: si-list
> > > > > >Cc: james.f.peterson@xxxxxxxxxxxxx; scott@xxxxxxxxxxxxx;
> > > > > >jmartinson@xxxxxxxxxxxxxxxxx; Ray Anderson
> > > > > >Subject: [SI-LIST] Re: Internal package aggressors/PCB routing
> > > > > >
> > > > > >
> > > > > >Jerry-
> > > > > >
> > > > > >I can't speak how other silicon vendors provide the data, but we
> > =
> > > =3D
> > > > perform
> > > > > >a full package extraction on all of our package designs to
> > generate =
> > > =3D
> > > > RLC
> > > > > >data for nets operating below about 1GHz (for MGT nets we provide
> > > > > >s-parameter data). We typically generate mutual coupling data for
> > =
> > > the =3D
> > > > 4
> > > > > >nearest neighbors since we feel that crosstalk coupling from
> > lines =
> > > =3D
> > > > more
> > > > > >than 4 away from the victim contribute negligible crosstalk. The
> > L =
> > > =3D
> > > > and C
> > > > > >mutual coupling values are available in IBIS .pkg file format as
> > a =
> > > =3D
> > > > data
> > > > > >item we make available for each package type. Given that data you
> > =
> > > can
> > > > > >simulate or calculate crosstalk voltages.
> > > > > >
> > > > > >Besides the standard IBIS .pkg file format we can also provide
> > =3D
> > > > customers
> > > > > >the data in a number of other formats upon request (with > 4 =3D
> > > > neighbors
> > > > > >coupling if desired).
> > > > > >
> > > > > >-Ray
> > > > > >
> > > > > >
> > > > > >Raymond Anderson
> > > > > >Senior Signal Integrity Staff Engineer
> > > > > >Advanced Platforms Group
> > > > > >Advanced Products Division
> > > > > >Product Technology Department
> > > > > >Package Design Engineering
> > > > > >Xilinx Inc.
> > > > > >2100 Logic Drive
> > > > > >San Jose, California 95124
> > > > > >(408) 626-6277
> > > > > >=3D3D3D20
> > > > > >
> > > > > >
> > > > >
> > >------------------------------------------------------------------
> > > > > >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: =3D20
> > > > //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
> > > > =3D20
> > > >
> > > > ------------------------------------------------------------------
> > > > 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: =20
> > > //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
> > > =20
> > >
> > > ------------------------------------------------------------------
> > > 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 technical documents are available at:
> > http://www.si-list.net
> >
> > 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 technical documents are available at:
http://www.si-list.net
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:
