Nitin,
If RJdram is zero, for a signal that meets the mask, the BER will be 0.
In other words, if there is no random jitter component, the DRAM is
guaranteed to latch the data correctly when the mask is met.
The BER 1e-16 requirement therefore acknowledges that RJdram is non-zero.
This also means system BER can be improved by providing a wider eye.
Thanks,
Vinu
On 10/31/2017 10:26 AM, Bhagwath, Nitin wrote:
Hi Hermann,
I think you're asking a very important, and very commonly misunderstood
question for DDR4.
Summary: As long as you don't violate the eye mask (by an inch or by a mile),
you can expect one DRAM error every 10e16 bits.
Jedec is a body which defines standards for DRAMs, not for system
manufacturers.
So, the BER defined is meant to be the BER for the DRAM. If the signal
*never* violates the mask, the DRAM will still nevertheless have errors due
to DRAM internal imperfections - one error every 10e16 bits. The original
intent was to define the DRAM Rx Buffer's Rj and Dj at a given DRAM BER, with
the intent that the system designer can assume a dual-dirac extrapolation to
get a DRAM BER at a lower level if needed by increasing the Rx region of the
eyemask. With a larger eye-mask, the DRAM would respond with fewer errors
(i.e. if the signal stays farther away from the deterministic eye, there will
be fewer errors due to DRAM mislatchings)
However, an Rj was never defined - it has always been 0 (Tj = Dj). This
makes the entire procedure somewhat irrelevant. So what we have now is that
regardless of how far from the deterministic/total eye the signal stays (i.e.
how big the signal eye opening is), the DRAM can only guarantee a BER of
10e-16.
What does this mean to the system designer? It does *not* mean that the
system designer needs to analyze system signals down to 10e-16. That's
something the DRAM manufacturer needs to do. The system's BER is defined by
the system designer, and not by Jedec. Jedec could have provided the DRAM's
behavior when the signal is some distance from the Dj mask. But without
showing the relationship between BER and Rj (by setting Rj to 0), all the
system designer can currently do is to know that the DRAM will misbehave
about once every 10e16 bits, no matter how clean the system delivers the
signal to the DRAM.
Regards,
-Nitin
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Hermann Ruckerbauer
Sent: Tuesday, October 31, 2017 7:53 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5 ==> RX or TX Random Jitter in the DDR4
Mask?
Hello,
please excuse: the following is just a quick'n'dirty thinking about BER
definition in DDR4 DRAM (If I do not get any response I know it is bullsh...
;-) )
As there is just a discussion on BER of DRAM interfaces .. (even this was
triggered by DDR5 discussion):
Yes, we had some Random jitter considered in the DDR4 Spec, but so far I
never thought about what the definition really meant!
So far I was thinking: I can measure Deterministic jitter and can add some TX
Random jitter on top of this to Calculate the BER of my system!
(maybe this assumption was just stupid).
As mentioned by Vinu below: The spec is a DRAM input Spec.
What does this mean for the Random jitter definition in the Mask with Random
and Deterministic jitter ?
Is this Random jitter really what can be provided as input to the DRAM?
or is this the margin for the random jitter required by the Receiver to
ensure you will get 1e-16 ?
As this is a Device input specification I would assume the second one.
So any kind of Transmit jitter is still to be considered separately.
But this discussion might be anyhow obsolete:
I just compared JESD79-4B vs. JESD79-4A: while in the 4A you still find the
Random and deterministic separation in the 4B the spec only talks about tdiVW
as "RX timing windows" required to achieve a BER 1e-16.
No separation of Deterministic Vs. Random jitter any more (so ... what have
we discussed the last 5 years (since the release of the initial
DDR4 Spec) ?)
Excerpt to tdiVW (RX Timing window) parameter from JESD79-4B Spec:
1. Data Rx mask voltage and timing total input valid window where VdIVW is
centered around Vcent_DQ (midpoint) after VrefDQ training is completed. The
data Rx mask is applied per bit and should include voltage and temperature
drift terms. The input buffer design specification is to achieve at least a
BER = e-16 when the RxMask is not violated. The BER will be characterized and
extrapolated if necessary using a dual dirac method from a higher BER(tbd).
What seems to support my assumption above: The spec was talking about
RECEIVER Random jitter and have to deal with TX Random jitter anyhow
independent and we need to ensure, that we do not violate the RX mask with a
specific amount of Random jitter from the Transmitter.
Maybe this is clear to others on the List.. I have to admit, after thinking
now for an hour on this one .. the meaning of the spec is still not really
clear to me (but 4B spec at least simplifies this one)..
Best regards
Hermann
P.S.
Maybe the Deterministic Jitter is as well defined as the CA timing was in
JESD-79-4A.
on several places the spec refers to de-rating tables .. but there are none.
In the 4B spec at least up to DDR4-2400 values are given .. all above is TBD.
How mature is this spec? Initial release was 2012!
I also like e. g. overshoot definitions with overshoot above VDD absolute max
(this was spec 4A .. but 4B did not really improve).
... and then having a drawing in, that equipment vendors take serious and
calculate the area of a triangle.
It seems industry does not need the accuracy that we talk about ?!?
EKH - EyeKnowHow
Signal Quality - Made in Bavaria
Hermann Ruckerbauer
www.EyeKnowHow.de
Hermann.Ruckerbauer@xxxxxxxxxxxxx
Itzlinger Strasse 21a
94469 Deggendorf
Tel.: +49 (0)991 / 29 69 29 05
Mobile: +49 (0)176 / 787 787 77
Fax: +49 (0)3212 / 121 9008
Am 30.10.2017 um 22:53 schrieb Vinu Arumugham (Redacted sender vinua for
DMARC):
1) Looking at the DDR4 spec., BER of 1e-16 is specified only for the------------------------------------------------------------------
DRAM input timing. For DDR4-3200, that's an error every 36 days. That
error rate is acceptable when CRC is enabled and data is retransmitted
on error. But the read direction has no CRC. So it must be
"error-free", which in practice means a BER requirement of 1e-18.
2) Stephen wrote:
"Our recommendation is that since the SSO is a deterministic jitter,
simulate with transient with an ideal power supply, then simulate with the
real PDN, and note the change in amplitude noise, and jitter. You only need
a few thousand bits to capture the spread of this effect."
The PDN "pulse response" has to settle in 10 to 12 bit times for "a few
thousand bits" to be sufficient. That may not be true.
Thanks,
Vinu
On 10/30/2017 08:25 AM, Todd Westerhoff wrote:
Chris,------------------------------------------------------------------
Sorry for the delay in response - was off watching college hockey on
Friday.
As always, you raise good points. I'm not going to take a position
here, other than to say we'll be figuring this stuff out as an
industry. EQ for
DDR5 is coming straight at us, and we need to figure out how we
design / simulate / verify this stuff. No method is going to be
perfect, but there is going to be considerable debate of what is good
enough, what is accurate but unattainable in a practical sense, and
what is wishful thinking / marketing bunk.
The British Statistician George Box was known to say "All models are
wrong. Some models are useful." I think that applies to much of what
we do in SI - we need to quantify where our models are off and by how
much, so we can decide how to use them productively in our decision
making process
- or whether to use them at all. I take simulation results with a
grain of salt - and I've been using simulators since before the term
EDA was coined. I trust simulation results only when I think I have a
good reason to do so - and try to make sure I'm aware of what
assumptions those results are based on.
To the AMI point - you're quite right, the assumption of output
driver / channel / receiver termination linearity and time invariance
is baked into the fundamental architecture of IBIS-AMI. The paper I
posted touches on that but sidesteps the whole debate of SSO and I/O
drivers - not as a dodge, but simply to keep the paper within a
reasonable length. The debate of whether or not statistical methods
and AMI can be applied to DDR5 is a real one and will continue for a
while. It will be ... interesting. Yeah - I'm going with interesting.
There's no easy out here. Traditional SPICE / SSO won't get us to the
statistical coverage we need ( ... and I don't mean 1e-16; I'm not
even touching that one), and AMI is based on strict assumptions that
we've never applied to DDR analysis before.
And ... by way of a pre-emptive assertion, using AMI with an impulse
response derived from SSO analysis is just as bad as using an impulse
response based on ideal power modeling. One's pessimistic, one's
optimistic, and while they probably bracket the problem, it's really
hard to say where in the middle the answer lies.
So - it's gonna be interesting. But that's a good thing - because
that's how we advance the state of the art.
Thanks for your comments!
Todd.
Todd Westerhoff
VP, Semiconductor Relations
Signal Integrity Software Inc. . www.sisoft.com
6 Clock Tower Place . Suite 250 . Maynard, MA 01754
(978) 461-0449 x124 . twesterh@xxxxxxxxxx
"I want to live like that"
-Sidewalk Prophets
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Sunday, October 29, 2017 12:09 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
I have publicly presented our view of deep BER analysis for multiple
times and privately talked to multiple tool companies. I will not use
this thread as a platform to do so.
I will sent out the links to one of my presentation once it is
uploaded in a separate thread.
To focus back on statistical and BER16 for DDR. If you drink that
koolaid of 10-16, you are talking about 50+ bits sequences. Do you
even think a
50+ bit sequence driven by a single driver ever exist in real DDR
read/write access ?
Or is it bursts of 4x,8x,16x driven by multiple drives at multiple
locations on a read (different ranks, DIMM) or even mingled between
read or write bursts ? How do you construct your "worst case
patterns" under realistic protocol access condition with multiple
drives at different locations and random burst length and timing ?
Is your statistical BER16 analysis by a single driver just some
pretty pictures that will never happen in real life ?
You either believe every read/write transection is properly set up
and terminated by the protocol and focus on the limited burst length
or you have to scare yourself to packed in all the transections
possible under multiple drivers and driven locations (even at the
receiving location for a read follow by a write) within the BER depth you
are told to reach.
What truly scare DDR designers are the protocol misses the DDR specs
made because the device community never factor in real life system
implementation. A real example was the DDR3 strobe pre/postamble
timing that everyone got burnt and end up violating the spec to make
the system work. Does leveling even work under limiting cases ? Those
will be the one keeps us awake at night.
If I want a good dish of Kung Pao Chicken, I don't need a better wok,
I need to work on my cooking.
Chris Cheng
Distinguished Technologist , Electrical Hewlett-Packard Enterprise
Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx / Email
4209 Technology Dr
Fremont, CA 94538
USA
-----Original Message-----
From: slater@xxxxxxxxxxxx [mailto:slater@xxxxxxxxxxxx]
Sent: Saturday, October 28, 2017 1:35 AM
To: Nitin_Bhagwath@xxxxxxxxxx; Cheng, Chris <chris.cheng@xxxxxxx>;
si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: EQ for DDR5
Hi Chris,
I'll chime in again. DFE does not easily have a representation in
Transient (i.e. SPICE) simulation, since the DFE is applied after the
latch.
If you had the full transistor level circuitry for the EQ you could
simulate it with a transient solver, but that is not what is
available to a system designer. It would also be much slower to
simulate the full SPICE level circuitry than any IBIS (or IBIS-AMI)
model representation of the same.
The EQ can be more easily applied in statistical because
mathematically you can calculate what the impact of the CTLE and DFE
will be on the impulse responses (one for rising, one for falling)
and compute the final eye.
The point Nitin makes about when statistical analysis becomes
important really has to do with the worst case bit pattern. At lower
speed grades you could simulate a few thousand bits and feel
comfortable you've captured the worst case bit pattern. As the data
rate increases, the number of bits 'in flight' in the channel
increases (the channel is electrically longer, and reflections affect
many future bits). To make things worse, the same is true for every
neighboring line, which means crosstalk also has impact on many
future bits. The number of possible permutations for bit patterns
increases exponentially; One of which is the worst case.
At DDR4 and DDR5 rates, the BER is specified... and it is very low
(1e-16). Statistical channel simulations calculate down to this
level very quickly. It always captures the worst case eye closure.
That is the point of using it (well that and the case that statistical sim
is fast).
However you also mentions SSO... that is a time-varying affect.. It
can only be captured by a transient simulation. In that respect transient
and
statistical channel simulation are very much complementary. Our
recommendation is that since the SSO is a deterministic jitter,
simulate with transient with an ideal power supply, then simulate
with the real PDN, and note the change in amplitude noise, and
jitter. You only need a few thousand bits to capture the spread of this
effect.
That change needs to be fed into the channel simulation either as a
Dj variable, or by simply increasing the Rx BER mask by the same
amounts, effectively giving yourself less margin. There's a DesignCon
2017 paper on this topic and it correlates well to measurement.
I hope this helps.
Best regards,
Stephen.
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Bhagwath, Nitin
Sent: Friday, October 27, 2017 6:51 PM
To: chris.cheng@xxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
in DDR ?Why do you think equalization can only be done by statistical
analysis
I don't.
As in my first sentence, we need to separate equalization from
statistical. For DDR5, DFE Equalization is needed. Discussions are
ongoing about whether/how IBIS-AMI can be used as a solution, given
some limitations. I think it's a bit premature to call out any
methodology as standard yet.
At what datarate statistical analysis becomes really useful for DDR
(maybe because it takes too many UI to get all combinations in) is a
separate interesting topic. Maybe an interesting Designcon paper someday.
So as in my last sentence, I'm still a bit confused about what the
question is...
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Friday, October 27, 2017 6:01 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
Why do you think equalization can only be done by statistical
analysis in DDR ?
Chris Cheng
Distinguished Technologist , Electrical Hewlett-Packard Enterprise
Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx / Email
4209 Technology Dr
Fremont, CA 94538
USA
-----Original Message-----
From: Bhagwath, Nitin [mailto:Nitin_Bhagwath@xxxxxxxxxx]
Sent: Friday, October 27, 2017 5:30 PM
To: Cheng, Chris <chris.cheng@xxxxxxx>; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: EQ for DDR5
We need to separate the need for statistical analysis from the need
for equalization analysis. Both have been used for Serial links with
IBIS-AMI, but DDR5 really only needs support for DFE. If this
involves requiring IBIS-AMI, well, that's the fun conversation in the
IBIS-AMI committee to make sure that SSO, DQS, non-asymmetric and
other limitations are worked around. An industry-standard support is
still a work-in-progress.
If you're talking only about being able to do SSO and incorporate
DQS, well, many tools support that today (including HyperLynx).
Simply do a time-domain simulation with a few thousand bits. The
ringing should die down within a couple of round-trips.
There's the answer. What's the question again?
Regards,
-Nitin
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Cheng, Chris
Sent: Friday, October 27, 2017 5:00 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: EQ for DDR5
Single end source synchronous bus like DDR is very difficult to do
statistical analysis.
Single ended driver with active termination is most likely non-LTI.
SSO is a worst case analysis with odd and even mode SSO impact. Also,
strobe placement is different between read and write so SSO impact is
different between the two conditions. While protocol guarantee only
50% bus switching, nearby bit switching will saturate the SSO impact
within a few local bits. You always simulate only the worst case
impact because you're like to run into it in real life.
DDR bus is very different from serial bus. The burst is mostly limit
to 4x, 8x bit for random cache line access. Deep BER analysis is
really meaningless in real life. Just pretty pictures.
However, protocol corner cases like strobe pre/postamble timing
analysis is important also. Leveling training is notoriously problematic.
Anyone who claim there is a package for DDR bus analysis better have
answers to the above.
Chris Cheng
Distinguished Technologist , Electrical Hewlett-Packard Enterprise
Company
+1 510 344 4439/ Tel
chris.cheng@xxxxxxx<mailto:chris.cheng@xxxxxxx> / Email
4209 Technology Dr
Fremont, CA 94538
USA
[hpe-logo-sm]
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d
51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&
sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.
group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a990
8d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C63644752314153923
0&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908
d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230
&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.q
sl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545
f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4q
DyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d
51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&
sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.
group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a990
8d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C63644752314153923
0&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908
d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230
&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.q
sl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545
f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4q
DyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Fwebpage%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908d
51da6
753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&
sdata
=kC3MTS3RbyXVFDBcR29CjU5KIk%2FWS1jsYyBzcSCnS9o%3D&reserved=0
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftech.
group
s.yahoo.com%2Fgroup%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a990
8d51d
a6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C63644752314153923
0&sda
ta=gh2kFp1e6lDaj4N9jVp6%2B0f1TDAAMW1D%2BFM98ptD1uc%3D&reserved=0
List archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.f
reeli
sts.org%2Farchives%2Fsi-list&data=02%7C01%7C%7C6917a866dd4445e11a9908
d51da
6753f%7C63545f2732324d74a44dcdd457063402%7C1%7C0%7C636447523141539230
&sdat
a=3heFaY39B8WtM8GB4C9R1OksLkRtNUwDUbCnbDwJFD0%3D&reserved=0
Old (prior to June 6, 2001) list archives are viewable at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.q
sl.ne
t%2Fwb6tpu&data=02%7C01%7C%7C6917a866dd4445e11a9908d51da6753f%7C63545
f2732
324d74a44dcdd457063402%7C1%7C0%7C636447523141539230&sdata=4l37el%2F4q
DyOzh
5GYpPPPkz5fYWGvGPr2XhBk25tVZw%3D&reserved=0
------------------------------------------------------------------
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
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 forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
