[SI-LIST] Re: DDR2 Trace Length Margin

  • From: "Tom Biggs" <tbiggs@xxxxxxxxxxxxxxxxxxxxx>
  • To: <si-list@xxxxxxxxxxxxx>
  • Date: Fri, 25 Jul 2008 10:24:07 -0700

It doesn't help when you have a problem with a company's chipset, and
their support engineer says "You mean you didn't match the memory clocks
to 5 mils like our design guidelines say? Well, there's your problem." =20

    -tom

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Ken Cantrell
Sent: Friday, July 25, 2008 7:49 AM
To: Moran, Brian P; Scott McMorrow; Aubrey_Sparkman@xxxxxxxx
Cc: Dan.Smith@xxxxxxxxx; leeritchey@xxxxxxxxxxxxx; Loyer, Jeff;
si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR2 Trace Length Margin

Jeff and Brian,
That's OK, I've ignored your specs for years! Kidding of course.  I do
use them as guidlines though, not as imperatives.  Don't get me wrong, I
have all the respect in the world for you guys,and like you said, you
have to spec for "one size fits all".  However, I think the higher your
routing density, the less you can afford to match lengths to an
artificially small target.  I length match in degrees of phase, which is
something Doug Brooks talked about years ago.  And it's just a metric,
nothing written in stone.
Velocity*(period/360) =3D length for 1 degree of phase. For the most =
time
critical elements, I try and keep it to 5 degrees or less.  It's simple
and seems to work pretty well.  At 1GHz and a permittivity of 4.0, 1 deg
of length is ~30 mils =3D ~5pS.  5 deg =3D ~150 mils =3D ~25pS.  I might
actually do 50 mils on clocks, 100 mils on strobes, 200 mils on data,
and whatever fits on add/cmd/ctrl.  Of course, with any of the FPGA
serdes with training, the matching requirements are essentially gone.
You can have a >foot of delta on some of the lines, and it really
doesn't matter.  CAD loves it.
Unlike your CAD group, my CAD guys whine incessantly about tight routing
specs.  They are trying to put a bushel of shinola in a shoe box
already, and don't need me unnecessarily tying their hands.  As you said
Brian, it's all in your perspective.

Ken


-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Moran, Brian P
Sent: Thursday, July 24, 2008 10:45 PM
To: Scott McMorrow; Aubrey_Sparkman@xxxxxxxx
Cc: Dan.Smith@xxxxxxxxx; leeritchey@xxxxxxxxxxxxx; Loyer, Jeff;
si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR2 Trace Length Margin


Hi All,

A couple final comments. I think part of this back and forth is somewhat
due to the different perspectives one might have.=3D20

I certainly do not assume that a perfectly length matched bus is a
perfectly delay matched bus.=3D20 Some amount of velocity mismatch will
always need to be accounted for.
However, it would seem that
this will be there whether you length match to +/-5 mils or +/-100 mils.
On some busses we do
recommend velocity compensated matching, which even then in not perfect.
Nor do I imply that
just because I might spec a +/-20 mil length matching rule, that my
timing margins are in the 5ps realm. Rather it is my opinion that you
should preserve all the margin you can, where you know how, in order to
leave margin for those timing issues less easily made deterministic.
That is not done out of laziness.  It is done out of respect for all
those things that can bite your ass, and reduce margins in ways not so
easily restored. =3D20

I will admit, however, that I'm coming from the perspective of someone
writing generic platform independent pre-route guidelines, where you do
not know how much of the available margin may have been allocated to
things other than the interconnect, or how many non-optimizations might
exist in the design. If I had the luxury of knowing the exact
implementation I might choose to engineer with less guardband. Given all
the things we do not know about the final implementation, it seems
prudent to preserve all the margin we can. But if I were to be analyzing
a specific design, I might take a completely different position.=3D20


Brian Moran
MPG/MPHD/EDE/PEA Group
Intel Corporation

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Scott McMorrow
Sent: Thursday, July 24, 2008 5:09 PM
To: Aubrey_Sparkman@xxxxxxxx
Cc: Dan.Smith@xxxxxxxxx; leeritchey@xxxxxxxxxxxxx; Loyer, Jeff;
si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR2 Trace Length Margin

Aubrey

I agree wholeheartedly about doing a margin and risk assessment
before=3D20 starting simulations.  In my world, simulations are often an
integral=3D20 part of the final assessment


Scott

Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax

http://www.teraspeed.com

Teraspeed(r) is the registered service mark of Teraspeed Consulting
Group LLC



Aubrey_Sparkman@xxxxxxxx wrote:
> Scott,=3D20
> =3D20
>  "then you must believe that if the CAD tool says that the traces are=20
> matched to 1 mil, that their delays are identical".
> Nope.  Don't know how you reached this conclusion....
> =3D20
> But you make a good point; it's under-design that takes less time and
> thought.   It is over-design that wastes time.  But I think that's
> nit-picking....   I recommend doing a margin and risk assessment
BEFORE
> doing any simulations.
> =3D20
> BTW, I'm not defending 2 or 10 mil length matching; I've railed
against
> that many times in the past.  In this case, I'm complaining about a
few
> people jumping to the wrong conclusion.
> =3D20
> Aubrey Sparkman
> Enterprise Engineering Signal Integrity Team Dell, Inc.
> Aubrey_Sparkman@xxxxxxxx
> (512) 723-3592=3D20
> "The single biggest problem in communication is the illusion that it
has
> taken place." -- George Bernard Shaw=3D20
>
>
> =3D20
>
> ________________________________
>
> From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]=3D20
> Sent: Thursday, July 24, 2008 5:22 PM
> To: Sparkman, Aubrey
> Cc: Dan.Smith@xxxxxxxxx; leeritchey@xxxxxxxxxxxxx;
jeff.loyer@xxxxxxxxx;
> si-list@xxxxxxxxxxxxx
> Subject: Re: [SI-LIST] Re: DDR2 Trace Length Margin
>
>
>
> Aubrey_Sparkman@xxxxxxxx wrote:=3D20
>
>       I totally agree that overdesign requires less thought.  =3D20
>
>
>
> Really now!  And then you must believe that if the CAD tool says that=20
> the traces are matched to 1 mil, that their delays are identical, no=20
> matter how may bends, fabric weave crossings and cross-coupled
sections
> were required to meet the requirement.
>
> In my world, someone who specifies near-perfect trace matching is
guilty
> of under design.
>
> In my experience, there are several fallacies at work here.
>
> 1) That the CAD tool correctly measures trace length.  In actuality,
PCB
> CAD tools measure the length of the polyline, which is the centerline
of
> the trace.  This measurement can be converted to delay if, and only
if,
>
>
> *     The dielectric medium is uniform and has constant Er in all
> directions.=3D20
>
>       *       Or the trace is perfectly straight.=3D20
>
> *     The signal propagation is down the centerline of the trace.=3D20
>
>       *       Thus there are no bends=3D20
>
> *     There is no coupling to other structures.=3D20
>
>       *       Vias, other traces, trace serpentines.=3D20
>
> 2) Delay of serpentine traces have been shown by many studies to vary=20
> from a straight trace of the same polyline length, due to:
>
>
> *     Corner bend capacitance=3D20
> *     Signals cutting the corners and coupling across corner bends.=3D20
> *     Cross-coupling of adjacent traces in the serpentine.=3D20
> *     Directional differences in PCB Er=3D20
> *     Positional differences in PCB Er=3D20
>
> 3) Delay matching always requires more space than non-matched lines,
and
> perfectly matched trace lengths can be shown to require the maximum=20
> amount of space.  This additional space takes away from room for=20
> crosstalk mitigation through spacing.=3D20
>
> 4) Additional space required for trace matching of a large bus
sometimes
> results in multiple layers being used.
>
> regards,
>
> Scott
>
>
>
>
>
>       And I would add
>       that it also takes less *engineering* time.   My point was on
> the "Lazy"
>       comment.  Good engineering is about making design trade-offs and
>       resource allocation.  Which engineer would you prefer to have
you=20
> your
>       team; one who spent a month doing simulations to find out
exactly=20
> what
>       lengths could be tolerated or one who spends a day to figure out
that
>       you would still have to use the same number of layers,
components,=20
> etc
>       regardless of how tight the traces were matched.
> =3D09
>       When I get a recommendation, I get to decide whether I follow it
and
>       move on, challenge the recommendation, or do my own work to
develop=20
> my
>       own rules.  Personally, I want to see a "pay-back" for my
efforts.
> =3D09
> =3D09
>       Aubrey Sparkman=3D3D20
>       Enterprise Engineering Signal Integrity Team=3D3D20
>       Dell, Inc.=3D3D20
>       Aubrey_Sparkman@xxxxxxxx=3D3D20
>       (512) 723-3592=3D3D20
>       "The single biggest problem in communication is the illusion
that it=20
> has
>       taken place." -- George Bernard Shaw
> =3D09
> =3D09
> =3D09
>       -----Original Message-----
>       From: Dan Smith [mailto:Dan.Smith@xxxxxxxxx]=3D3D20
>       Sent: Thursday, July 24, 2008 2:43 PM
>       To: Sparkman, Aubrey; leeritchey@xxxxxxxxxxxxx;
jeff.loyer@xxxxxxxxx;
>       si-list@xxxxxxxxxxxxx
>       Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin
> =3D09
>       Overdesigning always requires less thought.
> =3D09
>       -----Original Message-----
>       From: Aubrey_Sparkman@xxxxxxxx [mailto:Aubrey_Sparkman@xxxxxxxx]
>       Sent: Thursday, July 24, 2008 12:15 PM
>       To: leeritchey@xxxxxxxxxxxxx; jeff.loyer@xxxxxxxxx; Dan Smith;
>       si-list@xxxxxxxxxxxxx
>       Subject: RE: [SI-LIST] Re: DDR2 Trace Length Margin
> =3D09
>       Lee,
> =3D09
>       So you think the only reason someone would not do what you
consider
>       proper analysis is because they are lazy?
> =3D09
> =3D09
>       Aubrey Sparkman
>       Enterprise Engineering Signal Integrity Team Dell, Inc.
>       Aubrey_Sparkman@xxxxxxxx
>       (512) 723-3592
>       "The single biggest problem in communication is the illusion
that it=20
> has
>       taken place." -- George Bernard Shaw
> =3D09
> =3D09
> =3D09
>       -----Original Message-----
>       From: si-list-bounce@xxxxxxxxxxxxx
> [mailto:si-list-bounce@xxxxxxxxxxxxx]
>       On Behalf Of Lee Ritchey
>       Sent: Thursday, July 24, 2008 1:17 PM
>       To: Jeff Loyer; Dan Smith; si-list@xxxxxxxxxxxxx
>       Subject: [SI-LIST] Re: DDR2 Trace Length Margin
> =3D09
>       The problem with inserting add length arbitrarily is what it
does to=20
> the
>       routing surface.  I've seen messes around DDR2 sockets that are=20
> totally
>       unnecessary and use board space that cold well be used for other

> things.
> =3D09
>       Add length is not free nor does it take zero time.  It should be
used
>       only when necessary, not when engineers are too lazy to do
proper
>       analysis.
> =3D09
> =3D09
>        =3D20
>
>               [Original Message]
>               From: Loyer, Jeff <jeff.loyer@xxxxxxxxx>=20
> <mailto:jeff.loyer@xxxxxxxxx>=3D20
>               To: Dan Smith <Dan.Smith@xxxxxxxxx>
> <mailto:Dan.Smith@xxxxxxxxx> ; <si-list@xxxxxxxxxxxxx>=20
> <mailto:si-list@xxxxxxxxxxxxx>=3D20
>               Date: 7/24/2008 10:28:16 AM
>               Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>       =3D09
>               In my experience, CAD folks have constantly fed back
that, if=20
> I'm=3D3D20
>               going to constrain the lengths, there's not much
difference=20
> between=3D3D20
>               matching to within 100 mils or 5.  Based on that, we
often put=20
> the=3D3D20
>               constraints to
>               5 mils, even though that number appears ridiculously
tight.  It=20
> also=3D3D20
>               allows them to keep constraints consistent throughout a
design,=20
> and=3D3D20
>               less prone to error.  And, if it's over-tight, we don't
have to=20
> worry=3D3D20
>               about how much of the length matching gets applied to
each board (of=20
> a
>                  =3D20
>
> =3D09
>        =3D20
>
>               multi-board design).
>       =3D09
>               For me, it allows me to ignore length matching as a
variable in=20
> my=3D3D20
>               design; another place I don't have to expend energy.
> Instead, I can=3D3D20
>               spend it on things that are challenging and critical.
>       =3D09
>               Yes, you are correct that often the constraints appear
absurd. =20
> But,=3D3D20
>               there are practical reasons for having those tight
constraints. =20
> If=3D3D20
>               there were significant challenges at meeting the tight
numbers,=20
> often=3D3D20
>               some back-of-the-envelope calculations can be used to
provide=3D3D20
>               relaxation.
>       =3D09
>               This paradigm has been in place for years, with FSB
length=20
> matching=3D3D20
>               rules of within 10 mils, for instance.  Yes, the design
could=20
> tolerate
>                  =3D20
>
> =3D09
>        =3D20
>
>               much more, but CAD folks had little problem meeting it,
and it=20
> made=3D3D20
>               length matching a moot point.
>       =3D09
>               Disclaimer:
>               The content of this message is my personal opinion only
and although=20
> I
>                  =3D20
>
> =3D09
>        =3D20
>
>               am an employee of Intel, the statements I make here in
no way=3D3D20
>               represent Intel's position on the issue, nor am I
authorized to=20
> speak=3D3D20
>               on behalf of Intel on this matter.
>       =3D09
>               Jeff Loyer
>       =3D09
>               -----Original Message-----
>               From: si-list-bounce@xxxxxxxxxxxxx
>               [mailto:si-list-bounce@xxxxxxxxxxxxx]
>               On Behalf Of Dan Smith
>               Sent: Thursday, July 24, 2008 9:21 AM
>               To: Lee Ritchey; Moran, Brian P; sreekanthn;
si-list@xxxxxxxxxxxxx
>               Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>       =3D09
>               The last DDR-2 design I did I had DQS and DQ matched to
as sloppy as
>                  =3D20
>
>       1"
>        =3D20
>
>               and=3D3D3D3D
>                I still had 15% margin on reads and over 50% margins on
writes -=20
> and=3D3D20
>               this =3D3D3D3D included PCB impedance variations and loss
due to=3D3D20
>               reflections.  I implement=3D3D3D3D ed more strict rules
than 1" but to=20
> me,
>               +/- 20 mils is a way over burden on=3D3D3D3D  the CAD
designer.
>       =3D09
>               Danno
>       =3D09
>               -----Original Message-----
>               From: si-list-bounce@xxxxxxxxxxxxx
>               [mailto:si-list-bounce@xxxxxxxxxxxxx]
>               On=3D3D3D3D
>                Behalf Of Lee Ritchey
>               Sent: Thursday, July 24, 2008 9:06 AM
>               To: Moran, Brian P; sreekanthn; si-list@xxxxxxxxxxxxx
>               Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>       =3D09
>               Length matching to +/- 20 mils means length matching to
> 3.2 pSec.
>               That is
>               unrealistically tight.    Why not couch length matching
> in terms of
>                  =3D20
>
>       time
>        =3D20
>
>               tolerance and then allow designers to turn this into
length.
>       =3D09
>               I match 2.4 Gb/S differential paths to +/- 150 mils or
> +/- 24 pS.  How
>                  =3D20
>
> =3D09
>        =3D20
>
>               could DDR2 require tighter than that or even that tight?
>       =3D09
>               Lee Ritchey
>       =3D09
>       =3D09
>                  =3D20
>
>                       [Original Message]
>                       From: Moran, Brian P <brian.p.moran@xxxxxxxxx>=20
> <mailto:brian.p.moran@xxxxxxxxx>=3D20
>                       To: sreekanthn <sreekanthn@xxxxxxxxxxxxxxx>=20
> <mailto:sreekanthn@xxxxxxxxxxxxxxx> ; <si-list@xxxxxxxxxxxxx>=20
> <mailto:si-list@xxxxxxxxxxxxx>=3D20
>                       Date: 7/21/2008 9:27:41 PM
>                       Subject: [SI-LIST] Re: DDR2 Trace Length Margin
>               =3D09
>                       Hi Sreekanth,
>               =3D09
>                       There is no single specification for length
matching.  You=20
> generally
>                            =3D20
>
> =3D09
>        =3D20
>
>                       need to simulate and do an AC analysis of each
application.
>                       However, I can give you some general rules of
thumb from our=20
> DDR2=3D3D20
>                       design guides. However, our guidelines are based
on=20
> motherboard=3D3D20
>                       rules to the module connector. If your SDRAMs
are down on the=3D3D20
>                       motherboard, then you do not need to account for
the length=3D3D20
>                       variation on the modules.  Which should give you
slightly=20
> looser=3D3D20
>                       rules then our guidelines stipulate.=3D3D3D3D3D20
>               =3D09
>                       The length matching between DQ and DQS within a
byte lane is=20
> the=3D3D20
>                       tightest constraint. Here we receommend +/- 20
mils, but this=20
> might=3D3D20
>                       be overkill in some cases.
>                            =3D20
>
>               I
>                  =3D20
>
>                       would recommend no
>                       more than +/-50 between DQs and their associated
DQS =3D3D
>                            =3D20
>
>       strobe.=3D3D3D3D3D20
>        =3D20
>
>                       The length matching between CTRL and CLK and
between ADR/CMD and=20
> CLK
>                            =3D20
>
>               is
>                  =3D20
>
>                       much looser in terms
>                       of the length window, but the relative offset
between each of=20
> these=3D3D20
>                       groups and CLK must be adjusted in some cases,
in order to=20
> center=3D3D20
>                       the valid window.  This offset is very much
dependent on the=3D3D20
>                       controller timing. Most controller allow this to
be done
>                            =3D20
>
>               through
>                  =3D20
>
>                       register control.=3D3D3D3D3D20
>               =3D09
>                       But is terms of the length mismatch windows you
can generally live
>                            =3D20
>
>               with
>                  =3D20
>
>                       a length window of 1.0"=3D3D3D3D3D20
>                       (+/- 0.5") on CTRL to CLK, and perhaps 2.0"
> (+/-1.0") on ADR/CMD to
>                            =3D20
>
>               CLK,
>                  =3D20
>
>                       assuming you are using
>                       2N timing on ADR/CMD.
>               =3D09
>                       DQS to CLK is also constrained. Here the overall
length window=20
> is=3D3D20
>                       generally 1.0" to 1.5" wide.=3D3D3D3D3D20
>               =3D09
>               =3D09
>                       So you start by routing and length matching your
CLKs.  Then=3D3D20
>                       establish your length window around CLK for
CTRL, CMD, and DQS. =20
> If=3D3D20
>                       you find it hard to route within these windows,
then lengthen=20
> CLKs=3D3D20
>                       as required to get the length window in the
required range. =20
> Usually
>                            =3D20
>
> =3D09
>        =3D20
>
>                       this is dictated by the min and max length of
the DQS strobes,=20
> since
>                            =3D20
>
> =3D09
>        =3D20
>
>                       the DQ bus has the largest natural length
variation between=20
> the=3D3D20
>                       shortest byte lanes and the longest. =3D3D3D3D3D20
>               =3D09
>                       The controllers generally have a timing offset
control that=20
> will=3D3D20
>                       allow you to optimize setup and hold by shifting
CLK, CTRL and=20
> CMD,=3D3D20
>                       at the source. =3D3D3D3D3D20 =3D3D3D3D3D20
>               =3D09
>               =3D09
>                       Brian Moran
>                       MPG/MPHD/EDE/PEA Group
>                       Intel Corporation
>               =3D09
>                       -----Original Message-----
>                       From: si-list-bounce@xxxxxxxxxxxxx
>                            =3D20
>
>               [mailto:si-list-bounce@xxxxxxxxxxxxx]
>                  =3D20
>
>                       On Behalf Of sreekanthn
>                       Sent: Monday, July 21, 2008 5:07 AM
>                       To: si-list@xxxxxxxxxxxxx
>                       Subject: [SI-LIST] DDR2 Trace Length Margin
>               =3D09
>               =3D09
>               =3D09
>                       Hi Experts,
>               =3D09
>                       I would like to know the length matching
requirement of a  DDR2
>                            =3D20
>
>               design.
>                  =3D20
>
>                       I have two memory devices in my board (NOT
DIMMs).
>                       Each has 16 bit data (Total 32) ,Each byte has
its own Data=20
> strobe=3D3D20
>                       and Mask signals.
>               =3D09
>                       Datas ,Stobes,Masks,Clk etc are point to point
topology.
>                       Address and other common signals (
> RAS,CAS,WE,RE,CS,CLKEN etc...)=3D3D20
>                       has to be routed in T topology.
>               =3D09
>                       Could someone please explain the rule of length
matching for=20
> each=3D3D20
>                       groups.
>                       Is there any standard docs available ? I refered
JDEC  specs,=20
> I=3D3D20
>                       could n't get any routing recommendations.
>               =3D09
>                       How can we engineer the trace length margin ?
>               =3D09
>                       My Max clock would be 667MHz.
>               =3D09
>                       Regards,
>                       Sreekanth=3D3D3D3D3D20
>               =3D09
>               =3D09
>                       The information contained in this electronic
message and any
>                            =3D20
>
>               attachments
>                  =3D20
>
>                       to this message are intended for the exclusive
use of the
>                       addressee(s) and may contain proprietary,
confidential or=20
> privileged
>                            =3D20
>
>       information.
>        =3D20
>
>               If
>                  =3D20
>
>                       you are not the intended recipient, you should
not=20
> disseminate,=3D3D20
>                       distribute or copy this e-mail. Please notify
the sender=20
> immediately
>                            =3D20
>
>               and
>                  =3D20
>
>                       destroy all copies of this message and any
attachments contained in
>                            =3D20
>
>               it.
>                  =3D20
>
>                       Contact your Administrator for further
information.
>               =3D09
> =3D09
> ------------------------------------------------------------------
>                       To unsubscribe from si-list:
>                       si-list-request@xxxxxxxxxxxxx with 'unsubscribe'
> in the Subject=3D3D20
>                       field
>               =3D09
>                       or to administer your membership from a web
page, go to:
>                       //www.freelists.org/webpage/si-list
>               =3D09
>                       For help:
>                       si-list-request@xxxxxxxxxxxxx with 'help' in the
Subject field
>               =3D09
>               =3D09
>                       List technical documents are available at:
>                                       http://www.si-list.net
>               =3D09
>                       List archives are viewable at:    =3D3D3D3D3D20
> =3D09
> //www.freelists.org/archives/si-list
>                       or at our remote archives:
> =3D09
> http://groups.yahoo.com/group/si-list/messages
>                       Old (prior to June 6, 2001) list archives are
viewable at:
>                                     http://www.qsl.net/wb6tpu
=3D3D3D3D3D20
>               =3D09
> =3D09
> ------------------------------------------------------------------
>                       To unsubscribe from si-list:
>                       si-list-request@xxxxxxxxxxxxx with 'unsubscribe'
> in the Subject=3D3D20
>                       field
>               =3D09
>                       or to administer your membership from a web
page, go to:
>                       //www.freelists.org/webpage/si-list
>               =3D09
>                       For help:
>                       si-list-request@xxxxxxxxxxxxx with 'help' in the
Subject field
>               =3D09
>               =3D09
>                       List technical documents are available at:
>                                       http://www.si-list.net
>               =3D09
>                       List archives are viewable at:
> =3D09
> //www.freelists.org/archives/si-list
>                       or at our remote archives:
> =3D09
> http://groups.yahoo.com/group/si-list/messages
>                       Old (prior to June 6, 2001) list archives are
viewable at:
>                                     http://www.qsl.net/wb6tpu
>               =3D09
>                            =3D20
>
> =3D09
> ------------------------------------------------------------------
>               To unsubscribe from si-list:
>               si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject=20
> field
>       =3D09
>               or to administer your membership from a web page, go to:
>               //www.freelists.org/webpage/si-list
>       =3D09
>               For help:
>               si-list-request@xxxxxxxxxxxxx with 'help' in the Subject
field
>       =3D09
>       =3D09
>               List technical documents are available at:
>                               http://www.si-list.net
>       =3D09
>               List archives are viewable at:
> =3D09
> //www.freelists.org/archives/si-list
>               or at our remote archives:
> =3D09
> http://groups.yahoo.com/group/si-list/messages
>               Old (prior to June 6, 2001) list archives are viewable
> at:
>                               http://www.qsl.net/wb6tpu
>       =3D09
>       =3D09
> =3D09
> ------------------------------------------------------------------
>               To unsubscribe from si-list:
>               si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject=20
> field
>       =3D09
>               or to administer your membership from a web page, go to:
>               //www.freelists.org/webpage/si-list
>       =3D09
>               For help:
>               si-list-request@xxxxxxxxxxxxx with 'help' in the Subject
field
>       =3D09
>       =3D09
>               List technical documents are available at:
>                               http://www.si-list.net
>       =3D09
>               List archives are viewable at:    =3D3D3D20
>                             //www.freelists.org/archives/si-list
>               or at our remote archives:
> =3D09
> http://groups.yahoo.com/group/si-list/messages
>               Old (prior to June 6, 2001) list archives are viewable
> at:
>                             http://www.qsl.net/wb6tpu  =3D3D3D20
>       =3D09
> =3D09
> ------------------------------------------------------------------
>               To unsubscribe from si-list:
>               si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject=20
> field
>       =3D09
>               or to administer your membership from a web page, go to:
>               //www.freelists.org/webpage/si-list
>       =3D09
>               For help:
>               si-list-request@xxxxxxxxxxxxx with 'help' in the Subject
field
>       =3D09
>       =3D09
>               List technical documents are available at:
>                               http://www.si-list.net
>       =3D09
>               List archives are viewable at:
>                             //www.freelists.org/archives/si-list
>               or at our remote archives:
> =3D09
> http://groups.yahoo.com/group/si-list/messages
>               Old (prior to June 6, 2001) list archives are viewable
> at:
>                             http://www.qsl.net/wb6tpu
>       =3D09
>                  =3D20
>
> =3D09
> =3D09
> =3D09
> ------------------------------------------------------------------
>       To unsubscribe from si-list:
>       si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field
> =3D09
>       or to administer your membership from a web page, go to:
>       //www.freelists.org/webpage/si-list
> =3D09
>       For help:
>       si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> =3D09
> =3D09
>       List technical documents are available at:
>                       http://www.si-list.net
> =3D09
>       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
> =3D09
> =3D09
> =3D09
> ------------------------------------------------------------------
>       To unsubscribe from si-list:
>       si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field
> =3D09
>       or to administer your membership from a web page, go to:
>       //www.freelists.org/webpage/si-list
> =3D09
>       For help:
>       si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> =3D09
> =3D09
>       List technical documents are available at:
>                       http://www.si-list.net
> =3D09
>       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
> =3D09
> =3D09
>        =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 technical documents are available at:
>                 http://www.si-list.net
>
> 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
>
>
>  =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 technical documents are available at:
                http://www.si-list.net

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 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:    =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 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: