FPGA Central

Ken,
We are already talking about using the on-die S-parameter data as part of
theanalog model - in fact, we're talking about using S-parameter data as
pretty much the entire analog model, as shown in slide 10 of the
presentationArpad referenced.

I think confusion may come from conversations in the IBIS-ATM working group,
where we've been talking about referencing on-die S-param data (used for the
analog model) from the .ami file instead of the .ibs file.

Walter is welcome to comment on the reasons for this, but I'll share my view
- this is a purely pragmatic decision, designed to move SerDes modeling
forward as fast as possible. We proposed syntax for including on-die
S-params in the .ibs file at the Feb 2009 IBIS Summit, and the working group
soon realized there were issues for single-ended, non-SerDes I/O that needed
significant discussion. We've been looking for a way to limit scope and
moveforward faster - using the .ami file is one way to clearly indicate this
is targeted for SerDes use and not intended as part of a broader, more
general purpose solution.

Todd.
Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250
Maynard, MA 01754 (978) 461-0449 x24 twesterh (AT) sisoft (DOT) com[1]
www.sisoft.com[2]

Ken Willis wrote: Hi Todd, On #1, it makes sense to incorporate S-parameters
into IO models, especially since some major IP suppliers have this data
today. I think the item that brings some uncertainty is why this would be
pushed into the algorithmic (AMI) portion of the model, especially if new
syntax/API has to be invented and supported. The intent of AMI was to
capturethe adaptive filtering behavior of these advanced Serdes devices,
which you couldn't really model well in a circuit model. If the S-parameters
are largely parasitic data, it seems more straightforward to include them in
the analog circuit part of the model. I understand that there is no standard
"IBIS" syntax for S-params right now, but I would agree with Arpad that
Touchstone is widely supported. Maybe we should be looking at [External
Model] >Touchstone or something like that. But we can continue the
discussionin the IBIS forum. Thanks, Ken Willis Sigrity, Inc. 860-871-7070
kwillis (AT) sigrity (DOT) com[3] -----Original Message----- From:
si-list-bounce (AT) freelists (DOT) org[4] [mailto:si-list-bounce (AT) freelists (DOT) org[5]] On
Behalf Of Todd Westerhoff Sent: Tuesday, February 09, 2010 9:29 AM To:
Muranyi, Arpad Cc: si-list (AT) freelists (DOT) org[6] Subject: [SI-LIST] Re: IBIS-AMI
Vendor Support Help Arpad, Two points worthy of note: 1) I think there's a
balance between adapting models to fit the current standard and extending
thestandard to improve the way we utilize vendor data. One of the goals we
had for IBIS-AMI was to utilize model data vendors already have, S-parameter
characterizations of on-die behavior being the obvious case. This should
legitimately be considered part of the device model and IBIS-AMI should
accommodate it as such. Telling people to include on-die S-parameters as
partof the channel may comply with the current spec, but I don't think
that'sthe way semiconductor vendors or users want to manage that data ... it
just creates more opportunity for error. 2) A clear and unambiguous
definition of on-die S-parameter syntax was presented at the Feb 2009 IBIS
Summit, for exactly the reasons you mentioned. Thanks, Todd. Todd Westerhoff
VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA
01754(978) 461-0449 x24 twesterh (AT) sisoft (DOT) com[7] www.sisoft.com[8] Muranyi,
Arpad wrote: Sanjeev, I would recommend the following: Zero out the package
related stuff in the .ibs file to basically turn package modeling off in it.
Provide an S-parameter package file separately the same way as the channel's
S-parameter file would be distributed. This could be documented in the .ibs
file behind comments. The customer will use whatever method to include this
in their favorite EDA tool. If there is a need for on-die interconnect
parasitic modeling, it could be done the same way as the package model
described in the previous paragraph. The two might even be combined into a
single S-parameter file if that is more convenient or practical. I would NOT
provide a speculated IBIS syntax or any tool specific syntax in the .ibs
filefor anything, unless a clear and unambiguous description is given, so
that another EDA vendor could reproduce the same results with their
products.For the rest of the buffer description I would encourage everyone
touse existing IBIS constructs as far as possible. And again, if certain
features cannot be described that way, I would encourage everyone to provide
a detailed description for what needs to be modeled so that anyone could
maketheir own model implementations using their favorite EDA tools based on
that description. Thanks for asking the question. Arpad
================================================== ==============
-----Original Message----- From: sanjeev_gupta (AT) agilent (DOT) com[9]
[mailto:sanjeev_gupta (AT) agilent (DOT) com[10]] Sent: Monday, February 08, 2010 5:29
PM To: Muranyi, Arpad; si-list (AT) freelists (DOT) org[11] Cc:
sanjeev_gupta (AT) agilent (DOT) com[12] Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor
Support Help Hello Arpad, What will be your advice to companies who are
ramping up on AMI? Should they include some non-AMI syntax for package
modeling assuming that IBIS AMI standard will support these keywords in near
future or provide these package model as a separate Touchstone file which
canbe integrated within simulation environment? Best regards Sanjeev
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request (AT) freelists (DOT) org[13] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: http://www.freelists.org/webpage/si-list[14] For help:
si-list-request (AT) freelists (DOT) org[15] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[16] List
archives are viewable at: http://www.freelists.org/archives/si-list[17] Old
(prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu[18]
------------------------------------------------------------------ To
unsubscribe from si-list: si-list-request (AT) freelists (DOT) org[19] with
'unsubscribe' in the Subject field or to administer your membership from a
web page, go to: http://www.freelists.org/webpage/si-list[20] For help:
si-list-request (AT) freelists (DOT) org[21] with 'help' in the Subject field List
technical documents are available at: http://www.si-list.net[22] List
archives are viewable at: http://www.freelists.org/archives/si-list[23] Old
(prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu[24]

--- Links ---
1 mailto:twesterh (AT) sisoft (DOT) com
2 http://www.sisoft.com
3 mailto:kwillis (AT) sigrity (DOT) com
4 mailto:si-list-bounce (AT) freelists (DOT) org
5 mailto:si-list-bounce (AT) freelists (DOT) org
6 mailto:si-list (AT) freelists (DOT) org
7 mailto:twesterh (AT) sisoft (DOT) com
8 http://www.sisoft.com
9 mailto:sanjeev_gupta (AT) agilent (DOT) com
10 mailto:sanjeev_gupta (AT) agilent (DOT) com
11 mailto:si-list (AT) freelists (DOT) org
12 mailto:sanjeev_gupta (AT) agilent (DOT) com
13 mailto:si-list-request (AT) freelists (DOT) org
14 http://www.freelists.org/webpage/si-list
15 mailto:si-list-request (AT) freelists (DOT) org
16 http://www.si-list.net
17 http://www.freelists.org/archives/si-list
18 http://www.qsl.net/wb6tpu
19 mailto:si-list-request (AT) freelists (DOT) org
20 http://www.freelists.org/webpage/si-list
21 mailto:si-list-request (AT) freelists (DOT) org
22 http://www.si-list.net
23 http://www.freelists.org/archives/si-list
24 http://www.qsl.net/wb6tpu
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:
http://www.freelists.org/archives/si-list

Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu

Todd,

Regarding the reasons you brought up for fixing these analog problems
in the .ami file's specification take me out a few thousand feet to
look at the broader picture of IBIS.

For years, we have mentioned every once and a while the need to give
the IBIS specification a complete overhaul. The reasons are quite
obvious, there are many problems and limitations in the existing
specification which needs to be fixed. The interaction between these
issues is huge. The longer we wait, the worse the situation will get.
If we don't do anything, the entire spec may collapse under its own
weight.

On the other hand, if we keep diverting everything from the original
IBIS specification into other new specifications (such as the IBIS-ISS
proposal, and this suggestion of describing analog buffer behaviors in
the AMI specification), the IBIS specification could also die from
becoming a useless empty balloon.

So I would like to raise the question: Are we (consciously or
unknowingly)
leaving IBIS behind gradually, allowing it to die because we never have
enough time to fix the real causes and reasons of the problems? Does
this mean that there is no more value in having an IBIS specification?

Thanks,

Arpad
================================================== ======================



________________________________
From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
Sent: Tuesday, February 09, 2010 10:32 AM
To: Ken Willis
Cc: Muranyi, Arpad; si-list (AT) freelists (DOT) org
Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help


Ken,

We are already talking about using the on-die S-parameter data as part
of the analog model - in fact, we're talking about using S-parameter
data as pretty much the entire analog model, as shown in slide 10 of the
presentation Arpad referenced.

I think confusion may come from conversations in the IBIS-ATM working
group, where we've been talking about referencing on-die S-param data
(used for the analog model) from the .ami file instead of the .ibs file.

Walter is welcome to comment on the reasons for this, but I'll share my
view - this is a purely pragmatic decision, designed to move SerDes
modeling forward as fast as possible. We proposed syntax for including
on-die S-params in the .ibs file at the Feb 2009 IBIS Summit, and the
working group soon realized there were issues for single-ended,
non-SerDes I/O that needed significant discussion. We've been looking
for a way to limit scope and move forward faster - using the .ami file
is one way to clearly indicate this is targeted for SerDes use and not
intended as part of a broader, more general purpose solution.

Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com
www.sisoft.com


Ken Willis wrote:

Hi Todd,

On #1, it makes sense to incorporate S-parameters into IO
models, especially
since some major IP suppliers have this data today. I think the
item that
brings some uncertainty is why this would be pushed into the
algorithmic
(AMI) portion of the model, especially if new syntax/API has to
be invented
and supported. The intent of AMI was to capture the adaptive
filtering
behavior of these advanced Serdes devices, which you couldn't
really model
well in a circuit model. If the S-parameters are largely
parasitic data, it
seems more straightforward to include them in the analog circuit
part of the
model.

I understand that there is no standard "IBIS" syntax for
S-params right now,
but I would agree with Arpad that Touchstone is widely
supported. Maybe we
should be looking at [External Model] > Touchstone or something
like that.
But we can continue the discussion in the IBIS forum.

Thanks,

Ken Willis
Sigrity, Inc.
860-871-7070
kwillis (AT) sigrity (DOT) com

-----Original Message-----
From: si-list-bounce (AT) freelists (DOT) org
[mailto:si-list-bounce (AT) freelists (DOT) org] On
Behalf Of Todd Westerhoff
Sent: Tuesday, February 09, 2010 9:29 AM
To: Muranyi, Arpad
Cc: si-list (AT) freelists (DOT) org
Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help

Arpad,

Two points worthy of note:

1) I think there's a balance between adapting models to fit the
current
standard and extending the standard to improve the way we
utilize vendor
data. One of the goals we had for IBIS-AMI was to utilize model
data
vendors already have, S-parameter characterizations of on-die
behavior
being the obvious case. This should legitimately be considered
part of
the device model and IBIS-AMI should accommodate it as such.
Telling
people to include on-die S-parameters as part of the channel may
comply
with the current spec, but I don't think that's the way
semiconductor
vendors or users want to manage that data ... it just creates
more
opportunity for error.

2) A clear and unambiguous definition of on-die S-parameter
syntax was
presented at the Feb 2009 IBIS Summit, for exactly the reasons
you
mentioned.

Thanks,

Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com
www.sisoft.com



Muranyi, Arpad wrote:


Sanjeev,

I would recommend the following:

Zero out the package related stuff in the .ibs file to
basically turn package modeling off in it.

Provide an S-parameter package file separately the same
way as the channel's S-parameter file would be
distributed.
This could be documented in the .ibs file behind
comments.
The customer will use whatever method to include this in
their favorite EDA tool.

If there is a need for on-die interconnect parasitic
modeling,
it could be done the same way as the package model
described
in the previous paragraph. The two might even be
combined into
a single S-parameter file if that is more convenient or
practical.

I would NOT provide a speculated IBIS syntax or any tool
specific syntax in the .ibs file for anything, unless a
clear and unambiguous description is given, so that
another
EDA vendor could reproduce the same results with their
products.

For the rest of the buffer description I would encourage
everyone to use existing IBIS constructs as far as
possible.
And again, if certain features cannot be described that
way,
I would encourage everyone to provide a detailed
description
for what needs to be modeled so that anyone could make
their
own model implementations using their favorite EDA tools
based on that description.

Thanks for asking the question.

Arpad

================================================== =============

-----Original Message-----
From: sanjeev_gupta (AT) agilent (DOT) com
[mailto:sanjeev_gupta (AT) agilent (DOT) com]
Sent: Monday, February 08, 2010 5:29 PM
To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
Cc: sanjeev_gupta (AT) agilent (DOT) com
Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help

Hello Arpad,

What will be your advice to companies who are ramping up
on AMI? Should
they include some non-AMI syntax for package modeling
assuming that IBIS
AMI standard will support these keywords in near future
or provide these
package model as a separate Touchstone file which can be
integrated
within simulation environment?

Best regards
Sanjeev

------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the
Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject
field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:

http://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 (AT) freelists (DOT) org with 'unsubscribe' in the Subject
field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:
http://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 (AT) freelists (DOT) org with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:
http://www.freelists.org/archives/si-list

Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu

Arpad,

Good questions, but probably a bit much for this forum. Tell you what -
let's take them up in today's call.

Todd.

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh (AT) sisoft (DOT) com
www.sisoft.com



Muranyi, Arpad wrote:
> Todd,
>
> Regarding the reasons you brought up for fixing these analog problems
> in the .ami file's specification take me out a few thousand feet to
> look at the broader picture of IBIS.
>
> For years, we have mentioned every once and a while the need to give
> the IBIS specification a complete overhaul. The reasons are quite
> obvious, there are many problems and limitations in the existing
> specification which needs to be fixed. The interaction between these
> issues is huge. The longer we wait, the worse the situation will get.
> If we don't do anything, the entire spec may collapse under its own
> weight.
>
> On the other hand, if we keep diverting everything from the original
> IBIS specification into other new specifications (such as the IBIS-ISS
> proposal, and this suggestion of describing analog buffer behaviors in
> the AMI specification), the IBIS specification could also die from
> becoming a useless empty balloon.
>
> So I would like to raise the question: Are we (consciously or
> unknowingly)
> leaving IBIS behind gradually, allowing it to die because we never have
> enough time to fix the real causes and reasons of the problems? Does
> this mean that there is no more value in having an IBIS specification?
>
> Thanks,
>
> Arpad
> ================================================== ======================
>
>
>
> ________________________________
> From: Todd Westerhoff [mailto:twesterh (AT) sisoft (DOT) com]
> Sent: Tuesday, February 09, 2010 10:32 AM
> To: Ken Willis
> Cc: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Subject: Re: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
>
> Ken,
>
> We are already talking about using the on-die S-parameter data as part
> of the analog model - in fact, we're talking about using S-parameter
> data as pretty much the entire analog model, as shown in slide 10 of the
> presentation Arpad referenced.
>
> I think confusion may come from conversations in the IBIS-ATM working
> group, where we've been talking about referencing on-die S-param data
> (used for the analog model) from the .ami file instead of the .ibs file..
>
> Walter is welcome to comment on the reasons for this, but I'll share my
> view - this is a purely pragmatic decision, designed to move SerDes
> modeling forward as fast as possible. We proposed syntax for including
> on-die S-params in the .ibs file at the Feb 2009 IBIS Summit, and the
> working group soon realized there were issues for single-ended,
> non-SerDes I/O that needed significant discussion. We've been looking
> for a way to limit scope and move forward faster - using the .ami file
> is one way to clearly indicate this is targeted for SerDes use and not
> intended as part of a broader, more general purpose solution.
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
> Ken Willis wrote:
>
> Hi Todd,
>
> On #1, it makes sense to incorporate S-parameters into IO
> models, especially
> since some major IP suppliers have this data today. I think the
> item that
> brings some uncertainty is why this would be pushed into the
> algorithmic
> (AMI) portion of the model, especially if new syntax/API has to
> be invented
> and supported. The intent of AMI was to capture the adaptive
> filtering
> behavior of these advanced Serdes devices, which you couldn't
> really model
> well in a circuit model. If the S-parameters are largely
> parasitic data, it
> seems more straightforward to include them in the analog circuit
> part of the
> model.
>
> I understand that there is no standard "IBIS" syntax for
> S-params right now,
> but I would agree with Arpad that Touchstone is widely
> supported. Maybe we
> should be looking at [External Model] > Touchstone or something
> like that.
> But we can continue the discussion in the IBIS forum.
>
> Thanks,
>
> Ken Willis
> Sigrity, Inc.
> 860-871-7070
> kwillis (AT) sigrity (DOT) com
>
> -----Original Message-----
> From: si-list-bounce (AT) freelists (DOT) org
> [mailto:si-list-bounce (AT) freelists (DOT) org] On
> Behalf Of Todd Westerhoff
> Sent: Tuesday, February 09, 2010 9:29 AM
> To: Muranyi, Arpad
> Cc: si-list (AT) freelists (DOT) org
> Subject: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Arpad,
>
> Two points worthy of note:
>
> 1) I think there's a balance between adapting models to fit the
> current
> standard and extending the standard to improve the way we
> utilize vendor
> data. One of the goals we had for IBIS-AMI was to utilize model
> data
> vendors already have, S-parameter characterizations of on-die
> behavior
> being the obvious case. This should legitimately be considered
> part of
> the device model and IBIS-AMI should accommodate it as such.
> Telling
> people to include on-die S-parameters as part of the channel may
> comply
> with the current spec, but I don't think that's the way
> semiconductor
> vendors or users want to manage that data ... it just creates
> more
> opportunity for error.
>
> 2) A clear and unambiguous definition of on-die S-parameter
> syntax was
> presented at the Feb 2009 IBIS Summit, for exactly the reasons
> you
> mentioned.
>
> Thanks,
>
> Todd.
>
> Todd Westerhoff
> VP, Software Products
> SiSoft
> 6 Clock Tower Place, Suite 250
> Maynard, MA 01754
> (978) 461-0449 x24
> twesterh (AT) sisoft (DOT) com
> www.sisoft.com
>
>
>
> Muranyi, Arpad wrote:
>
>
> Sanjeev,
>
> I would recommend the following:
>
> Zero out the package related stuff in the .ibs file to
> basically turn package modeling off in it.
>
> Provide an S-parameter package file separately the same
> way as the channel's S-parameter file would be
> distributed.
> This could be documented in the .ibs file behind
> comments.
> The customer will use whatever method to include this in
> their favorite EDA tool.
>
> If there is a need for on-die interconnect parasitic
> modeling,
> it could be done the same way as the package model
> described
> in the previous paragraph. The two might even be
> combined into
> a single S-parameter file if that is more convenient or
> practical.
>
> I would NOT provide a speculated IBIS syntax or any tool
> specific syntax in the .ibs file for anything, unless a
> clear and unambiguous description is given, so that
> another
> EDA vendor could reproduce the same results with their
> products.
>
> For the rest of the buffer description I would encourage
> everyone to use existing IBIS constructs as far as
> possible.
> And again, if certain features cannot be described that
> way,
> I would encourage everyone to provide a detailed
> description
> for what needs to be modeled so that anyone could make
> their
> own model implementations using their favorite EDA tools
> based on that description.
>
> Thanks for asking the question.
>
> Arpad
>
> ================================================== =============
>
> -----Original Message-----
> From: sanjeev_gupta (AT) agilent (DOT) com
> [mailto:sanjeev_gupta (AT) agilent (DOT) com]
> Sent: Monday, February 08, 2010 5:29 PM
> To: Muranyi, Arpad; si-list (AT) freelists (DOT) org
> Cc: sanjeev_gupta (AT) agilent (DOT) com
> Subject: RE: [SI-LIST] Re: IBIS-AMI Vendor Support Help
>
> Hello Arpad,
>
> What will be your advice to companies who are ramping up
> on AMI? Should
> they include some non-AMI syntax for package modeling
> assuming that IBIS
> AMI standard will support these keywords in near future
> or provide these
> package model as a separate Touchstone file which can be
> integrated
> within simulation environment?
>
> Best regards
> Sanjeev
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request (AT) freelists (DOT) org with 'unsubscribe' in the
> Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject
> field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
>
> http://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 (AT) freelists (DOT) org with 'unsubscribe' in the Subject
> field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://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 (AT) freelists (DOT) org with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request (AT) freelists (DOT) org with 'help' in the Subject field
>
>
> List technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> http://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 (AT) freelists (DOT) org with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request (AT) freelists (DOT) org with 'help' in the Subject field


List technical documents are available at:
http://www.si-list.net

List archives are viewable at:
http://www.freelists.org/archives/si-list

Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu