Your first point is not so difficult to address anymore. The silicon vendor publishes a testbench and results which the simulator vendors must prove match (to some reasonable degree). This is a fairly quick and easy process which is becoming quite common. In fact, after being exposed to the superiority of the underdog, some have actually reversed the process. Your second point is dead-on. No one would give up their monopoly without a major fight. -----Original Message----- From: Tom Dagostino [mailto:tom@xxxxxxxxxxxxx]=20 Sent: Friday, March 11, 2005 1:28 PM To: Pratt, Gary; Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements There are another aspects of getting the silicon vendors to agree upon a common encryption technology that needs a little discussion. In a past life I was charged with getting one silicon vendor to agree with using the SPICE engine a past employer has. This silicon vendor was having enough problems with getting consistent results from HSPICE being their customer base had multiple different versions of HSPICE running on different platforms. When I asked this well known and highly regarded vendor to offer encrypted models for another SPICE simulator the response was "we have enough problems supporting HSPICE, we don't have the budget nor want the pain of another simulator. Who is going to validate the models in your simulator?". The problem is not just the technical aspect but also the business aspects for the silicon vendor. If there are any differences between the published results of a buffer and what comes out of brand XX simulator, how does it get resolved? And why would Synopsis agree to support an open encryption standard when they have the market locked up with their present approach? Tom Dagostino Teraspeed Labs 13610 SW Harness Lane Beaverton, OR 97008 503-430-1065 http://www.teraspeed.com tom@xxxxxxxxxxxxx Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 401-284-1827 Teraspeed is the registered service mark of Teraspeed Consulting Group LLC -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Pratt, Gary Sent: Friday, March 11, 2005 10:33 AM To: Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements Chris, Comments are embedded below. Gary =3D20 -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Chris Cheng Sent: Thursday, March 10, 2005 6:45 PM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements Gary, That's an interesting tool to say the least.=3D20 So basically you are suggesting using IBIS 4.1 to get the SPICE level circuit description of the I/O and perform the analysis. Gary=3D3D> Not exactly. I was suggesting the slow, convergence-prone = =3D SPICE models be replaced with fast, highly-reliable, industry standard Analog Behavioral Models (aka AMS). =3D20 Why not just have the EDA tool vendors agreed on a common encryption standard and have the vendor hand out a standard encrypted BSIM3 circuit then ? Gary=3D3D> Hmm. One could ask why go to the trouble of making a = standard for something that runs slow and has trouble converging, when we already have a standard for a solution that runs fast and converges well ... GARY=3D3D> But, I think there is a larger concern here ... I admit to = =3D much ignorance in the latest encryption technology, but to be a standard it seems it would have to be available to any SPICE vendor. Like Gary's Garage Shop -- proud vendor of GSpice. Not sure how enthused silicon vendors would be knowing Gary's Garage Shop has access to their IP. (Though, I happen to personally know this shop is well above reproach.) Gary=3D3D> Lame humor aside, even if we somehow limited it to the top 10 SPICE vendors, would there be a way for a silicon vendor to trace a leak back to the leaky tool vendor? Somehow, I just don't think silicon vendors would go for that. And, I'm not sure who would drive this and who would support it, and how long it would take. But, I'm more than willing to be proven wrong, if that's the way the industry wants to go. If I read Mark McKee's summary of what he has been doing, it is basically a DYI approach which starts with a structural description of the package, generate a package model that fit the analysis need and send it to a SPICE engine to do the analysis. I dig it, that's not too far from what I've been doing with ASIC or processor I/O design. I also like the digital extension in your tools where it will really comes in handy with these multi-stage equalizing circuits. Gary=3D3D> Yes. That's one advantage to this tool I forgot to mention. = =3D All of the logic and control can be partitioned to the event-driven solver. So, that part of the simulation basically takes no time. This can make a fast simulation even faster. As for needing S-parameters and these 200 port circuits, it seems I still could get away with a small set of ports to handle the SSO models even for these multi-giga hertz blocks. It is a matter of how you partition your circuit blocks in the worst case situation.=3D20 Gary=3D3D> I don't know. It seems to me that if one has 64 drivers switching at the same time, and these all get their power from the same set of bumps, one should really simulate all the drivers, traces, and a good portion of the package power planes to get an accurate result. But, I certainly make no claim to be an expert in this area. That is actually what I was hoping to learn from this discussion. -----Original Message----- From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx] Sent: Thursday, March 10, 2005 3:07 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements Lets try this again ... With perhaps some better text formatting this time ... Very good questions Chris. I've sanitized our thread of any product names, and am going back on-list as I think your questions might be of interest to the general community. =3D3D20 Guilty as charged. Though, the price of the SPICE simulator is included in the price of the SI tool, so you really get SPICE for free. And, the version of SPICE in this tool is actually much more than a SPICE simulator. And, we really aren't downgrading to IBIS, instead we are using the best of both worlds. You may want to look at IBIS 4.1 in more detail. For us SPICE enthusiasts, it really is a match made in heaven -- a great marriage between the simplicity of IBIS and the power of SPICE+. (That is actually how my employer was able to convince me, as 25 year SPICE veteran, to go anywhere near IBIS.) =3D3D20 So, the = benefits to spice experts are good: =3D3D20 1) As stated, the price of a superior SPICE tool is included in the price of the IBIS tool. 2) This SPICE+ simulator provides a modern, industry standard, analog programming language. =3D3D20 A huge improvement over traditional SPICE behavioral modeling. Believe me, as someone=3D3D20 who spent a great deal of the 80s and 90s doing SPICE behavioral modeling ... once you=3D3D20 go to an analog programming language, you will never go back to SPICE behavioral. Here=3D3D20 are some analogies (of varying accuracy): 1) Assembly language versus C - assembly language is more powerful than SPICE, don't=3D3D20 need to go back to microprocessor vendor to get more features 2) Unix CSH script versus C++ - pretty close analogy 3) Early macro-based digital simulator modeling versus VHDL or Verilog - Spice may=3D3D20 be more flexible than the early digital macro-modeling techniques. 3) IBIS provides the connectivity information missing from SPICE, allowing simple and easy=3D3D20 post-routing analysis with large pin-count components 4) The IBIS tool can extract an accurate model of the I/O loading from the post-layout PCB information. 5) If the IBIS file is generated by the silicon configuration software using the features of=3D3D20 IBIS 4.1, it can automatically create a file containing all the information SPICE needs=3D3D20 for an SSN simulation (which outputs are being switched, how each output is configured,=3D3D20 which outputs are tied high or low to improve SSN, etc). =3D3D20 6) This is all done within an industry standard framework. No more proprietary or defacto=3D3D20 standards and the interoperability problems they cause. However, to your average FPGA/PCB designer, many of whom would find more pleasure in poking themselves in the eye with a sharp stick than learning that archaic SPICE language (software developed by hardware engineers, in Fortran, in the early 1970s -- even before Disco), the benefits are huge: 1) The digital designer can perform complex SPICE simulations without any knowledge of SPICE. 2) The digital designer can work in an environment specifically created and highly optimized for SI analysis. =3D3D20 Now, this having been said, let me add three concerns on which I would appreciate your opinion: 1) This is not a PDN solution. This assumes the detailed PCB power distribution is minor=3D3D20 compared to the package, and can be modeled in a simple, fixed way. 2) This solution requires an accurate s-parameter model of the package for a bank of I/O and=3D3D20 its associated package power planes. =3D3D20 3) This assumes the I/O and its associated power supplies can be divided into relatively=3D3D20 independent banks (consisting of port counts in the low hundreds).=3D3D20 Does this still sound useful even with these caveats? =3D3D20 I do know there are occasionally free and for-fee Analog Modeling Language courses touring the world. I can let you know when one might be in your area next, if you are interested. =3D3D20 =3D3D20 I attached = a =3D couple of postings to the IBIS list which you might find interesting as well. =3D3D20 Gary =3D3D20 =3D3D20 ************************************************************************ ************************************************************************ ********* Reprints of IBIS postings ************************************************************************ ************************************************************************ ********** Hello Itzik, =3D3D20 =3D3D20 =3D3D20 Allow me to comment on your #1. The capabilities of spice macromodeling and AMS languages are quite different. This is primarily the reason AMS languages were developed, and are gaining momentum in the IC and System design space. =3D3D20 AMS languages are self-contained programming languages. They can accommodate any future technologies or applications with no need to add further syntax to the standard, or involve any standards committee or tool-vendor engineering team. Macro-modeling is much like UNIX scripting. It is a great way to quickly accomplish some automation, but can become complex for larger tasks or impossible if the task requires a UNIX command which isn't available (similar analogy applies to DOS batch files, or WORD macros if you are a Windows user). =3D3D20 =3D3D20 Spice macro-modeling is similar to the situation which existed for digital modeling in the 1970s and early 80s. At that time, modeling for digital simulators was done with primitives such as flip-flop blocks, Boolean logic blocks, etc. Complex macro models could be built from these primitives, but often times extreme cleverness was required when an application came along that needed different primitives than were provided by the simulator vendor. And, since simulator vendors weren't able to decide on a fixed set of primitives, models were not transferable. For many of the same reasons VHDL and Verilog replaced replaced digital macro modeling in the 80s (synthesis, notwithstanding), AMS has been slowly replacing other alternatives in the late 90s and 00s. =3D3D20 =3D3D20 As I understand, the reason the IBIS committee = adopted =3D AMS is to avoid the need to add further syntax to the IBIS language for each new application and technology. It seems like the macro-modeling SPICE syntax, and proposed standard templates, are prime examples of the syntax creep AMS was intended to avoid (SSO enhancements as well, perhaps). =3D3D20 =3D3D20 In an ideal world, the creator of the next generation of spice2ibis would target AMS as their output. In that way they have, immediately at their disposal, everything they could possibly need to accurately model new technologies and applications (in a well documented, industry standard, structured language). There would be no need to make proposals to the IBIS committee, wait for ratification, and then wait for adoption by the SI tool vendors for each new technology. Everything would be completely self-contained, and would run in every SI tool that support the current IBIS 4.1 standards. =3D3D20 =3D3D20 Thats my 2 cents = =3D worth. Hope that helps. =3D3D20 =3D3D20 Gary =3D3D20 =3D3D20 =3D3D20 ------------------------------------------------------------------------ -------- From: owner-ibis-users@xxxxxxx <mailto:owner-ibis-users@xxxxxxx> [mailto:owner-ibis-users@xxxxxxx] On Behalf Of Itzik Peleg Sent: Sunday, February 20, 2005 11:04 AM To: ibis-users@xxxxxxx <mailto:ibis-users@xxxxxxx>=3D3D20 Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling. =3D3D20 Hello IBIS users =3D3D20 I want to comment on the Macromodeling:=3D3D20 =3D3D20 But, 1st proper disclosure: =3D3D20 I am familiar with spice language and not familiar with AMS languages.=3D3D20 =3D3D20 Some questions: =3D3D20 1. As far as I understood the spice Macromodeling has the same capabilities as the AMS languages (in terms of behavioral modeling). 2. IBIS support the external languages, SPICE, VHDL-AMS and Verilog-AMS. The requirement from IBIS EDA tool developer to support these 3 languages is too much in my opinion. The implementation of this languages in simulation tool will take a long time (if it will be implemented) shouldn't we focus on the concept of Macromodeling by a fixed syntax (one only). By that allowing the EDA tool vendors develop complete IBIS support for one set of commands (this will enable them to support IBIS 4.1). The models author will use only one set of commands (or use his own scripts for translation to the IBIS format from different formats that he might use) this will enable a consist usage of the language by all with the flexibility of the author to develop any kind of buffer type. 3. Today there are simulation tools that support IBIS. How can we verify that all the tools run the IBIS in the same way? When we are going to use complex modeling the problem will be more severe. =3D3D20 My opinion is: 1. Use only one language for Macromodeling. 2. IBIS forum should recommend and develop templates for different buffer modeling needs. 3. The IBIS forum should check each EDA tool simulator for compliant (there could be different levels of compliant like the different IBIS specs 1.1 2.1 3.2 etc'). =3D3D20 Open for dissociation / comments. =3D3D20 -- Regards =3D3D20 Itzik Peleg Board Technology Group =3D3D20 *********************************************************** Please Note: email address change to: itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=3D3D20 *********************************************************** =3D3D20 Marvell Semiconductor Israel Ltd 6 Hamada Street=3D3D20 Mordot HaCarmel Industrial Park Yokneam 20692, ISRAEL Email - itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=3D3D20 Tel - +972 4 9091192 Cell - +972 54 4452482 Fax - +972 4 9091501 WWW Page: http://www.marvell.com <http://www.marvell.com>=3D3D20 =3D3D20 = =3D =3D3D20 ************************************************************************ ************************************************************************ ********* Second Reprint of IBIS postings ************************************************************************ ************************************************************************ ********** =3D3D20 Hi Lee, =3D3D20 Your question of ease and accuracy can be answered on several levels. For instance, assuming you could develop a traditional IBIS 3.x model for a high-speed source-synchronous serial I/O (note 1), it will take an enormous amount of time to create a model for each permutation of configuration. For instance, assume your driver has 4 different voltage levels, 4 different pre-emphasis levels, 2 different terminations, and 3 different process corners; you have 96 different IBIS models to create. A VHDL-AMS model would be much easier to develop, and much easier for your model users to manage the configurations. =3D3D20 (Note 1: I've heard strong arguments both ways on this issue. Since I don't have any first-hand experience, I won't comment either way. ) =3D =3D3D20 On the other hand, there is currently no spice-to-vhdlams tool like there is spice-to-ibis. So, it is currently up to the model creator to make the appropriate SPICE simulations of the transistor-level design, make the appropriate measurements, and build those measurements into a VHDL-AMS model. In that respect, using spice-to-ibis for a simple IBIS model would be much easier. Though, hopefully, as the popularity of AMS grows, spice-to-AMS tools will become available. =3D3D20 As for accuracy, because VHDL-AMS allows more degrees of modeling freedom, my feeling is that it can be more accurate than IBIS. However, on well-behaved drivers which fits the IBIS model template well, there may be no difference in accuracy. On the other hand, since I have no idea how to model a receiver containing internal equalization in traditional IBIS, for me, a VHDL-AMS model would be infinitely more accurate in this application. Likewise, for attempting to use IBIS for power integrity purposes, etc. In summary, I would say if your model will fit the traditional IBIS 3.x mold, use traditional IBIS. If not, consider VHDL-AMS. =3D3D20 You should also be aware that in addition to AMS languages, IBIS 4.1 allows for modeling with Berkeley SPICE primitives. This can be an easier alternative for someone knowledgeable in SPICE doing some simple modeling. SPICE versus AMS is somewhat analogous to Unix scripting versus C programming. Like UNIX scripting, SPICE provides some basic building blocks that are easy to assemble and run. But also like UNIX, scripting will run slower, and if your scripting requires more complexity than is provided in the basic UNIX commands, it can be difficult or impossible to accomplish your task without someone creating another UNIX command for you (most likely, in C). In the case of SPICE, you would need to convince your SPICE tool vendor of the need for the additional building block, then wait for them to implement and release the new feature (then hope that all SPICE vendors follow suit so your model will be relatively universal). In the case of AMS, if you need some additional functionality, you just add it to your model. Since the AMS language is self contained, anything you add to the model will be immediately available to anyone using a simulator which supports the IBIS 4.1 VHDL-AMS standard. =3D3D20 Speaking of support, most of the major SI tool vendors have AMS simulators in their company. All we need to do now is convince them to go to the work of porting them to their SI tools. =3D3D20 =3D3D20 I hope = =3D that helps, =3D3D20 Gary =3D3D20 -----Original Message----- From: lee yang [mailto:changly_80@xxxxxxxxxxx] Sent: Tuesday, February 01, 2005 7:46 AM To: Pratt, Gary Subject: RE: [IBIS-Users] VHDL-AMS Model =3D3D20 Hi Gary, Appreciate the information you provided. Does it mean that VHLS-AMS model is much easier to be produced compared to IBIS model? Do we need to run the Hspice simulation in order to generate the VHDL-AMS model like what is being done to generate IBIS model? What is the accuracy of the model compared to IBIS model? Thanks a lot and hope to hear from you soon! -Lee >From: "Pratt, Gary" <gary_pratt@xxxxxxxxxxx> >To: "lee yang" <changly_80@xxxxxxxxxxx>,<ibis-users@xxxxxxx> >Subject: RE: [IBIS-Users] VHDL-AMS Model >Date: Mon, 31 Jan 2005 12:18:49 -0500 > >Hello Lee, > >A simple answer to your question is VHDL-AMS provides a high level=3D20 = >of=3D3D20 flexibility. So for instance, instead of waiting for=3D20=20 >functionality to=3D3D20 be added to the IBIS standard and then waiting = =3D for=3D20 >SI tool vendors to=3D3D20 implement the function; VHDL-AMS provides you = =3D the >ability to implement=3D3D20 the function immediately. To date, = the=3D20=20 >flexibility of VHDL-AMS has=3D3D20 provided significant benefit in=3D20 = >simplifying modeling of highly=3D3D20 configurable devices such as = PCI=3D20 >Express drivers and difficult to model >receivers containing internal equalization. I suspect VHDL-AMS=3D20=20 >could=3D3D20 also be applied to implementing the functionality required = =3D for >modeling >power integrity. > >Gary > > > >-----Original Message----- >From: owner-ibis-users@xxxxxxx [mailto:owner-ibis-users@xxxxxxx] =3D On=3D3D20=3D20 >Behalf Of lee yang >Sent: Sunday, January 30, 2005 11:35 PM >To: ibis-users@xxxxxxx >Subject: [IBIS-Users] VHDL-AMS Model > >Hi, > >Recently I heard about another behavioral model call VHDL-AMS, = can=3D3D20 >=3D >anyone please give some background about it? >Since we already have IBIS model, what is the reason we need to =3D use=3D3D20=3D20 >VHDL-AMS model instead? What is the pros and cons compared to = IBIS=3D3D20 >=3D >model? >Thanks and appreciate if someone can shed some light. > >-Lee Yang =3D3D20 =3D3D20 ************************************************************************ ************************************************************************ ********* END OF Reprints of IBIS postings ************************************************************************ ************************************************************************ ********** =3D3D20 =3D3D20 =3D3D20 =3D3D20 =3D3D20 ________________________________ From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx]=3D3D20 Sent: Wednesday, March 09, 2005 8:43 PM To: Pratt, Gary Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements So you are asking me to get a SPICE tool but down grade the analysis to IBIS ? Why not just use SPICE then ? -----Original Message----- From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx] Sent: Wednesday, March 09, 2005 6:23 PM To: Chris.Cheng@xxxxxxxxxxxx Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements =3D3D09 =3D3D09 The tool is [Pratt, Gary] XXXXXXXXX . Its been available from [Pratt, Gary] XXXXXXXX for almost two years now. =3D3D20 =3D3D09 =3D3D20 ________________________________ From: si-list-bounce@xxxxxxxxxxxxx on behalf of Chris Cheng Sent: Wed 3/9/2005 8:53 PM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements =3D3D09 =3D3D09 Cool ! Say tomorrow my boss wants me to do such analysis, which company is shipping this excellent tool ? I want to get my hands on it like yesterday. Is any one of your FPGA customer doing it yet ? Please share your insight. =3D3D09 -----Original Message----- From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx] Sent: Wednesday, March 09, 2005 5:40 PM To: ray.anderson@xxxxxxxxxx; si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements =3D3D09 =3D3D09 Actually, there was one irreverent poster who was saying SSO could be done with IBIS (as it stands today). That is assuming one can generate an accurate (causal, passive, etc) s-parameter model for an appropriate section of the package (with say, up to perhaps 200 ports). =3D3D3D20 =3D3D09 IBIS 4.1 with IEEE standard 1076.1 provides all the facilities one would need to create an IBIS standard model which would simulate supply current and driver output characteristics to any level of accuracy desired. Couple this with an SI tool that accepts large s-parameter models, and I believe you are ready to roll. =3D3D3D20 =3D3D09 Couple this with silicon configuration software that can write an IBIS 4.1 file, and one has the makings of an easy to use application for SSO analysis. =3D3D3D20 =3D3D09 Gary =3D3D09 =3D3D09 =3D3D09 -----Original Message----- From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Ray Anderson Sent: Wednesday, March 09, 2005 10:48 AM To: si-list@xxxxxxxxxxxxx Subject: [SI-LIST] Re: package SSN model accuracy requirements =3D3D09 Chris- =3D3D09 I think you may be misinterpreting what Lynne and the other posters in this thread have been discussing so far. =3D3D09 No one seems to be saying that SSO simulations should be done with IBIS (as it stands today). =3D3D09 The discussion is centered around the various package models. An IBIS model consists of the silicon model portion and the package model portion. One can take the package model portion (that is described in IBIS syntax) and rewrite it in Spice syntax if you so desire. So while some of the statements earlier in the thread may have referenced "IBIS lumped models" and "IBIS ICM" models, the crux of the discussion is related to model topologies, model complexity, model bandwidth, and model size where the "model" in question is the package model. All of these model attributes are relevant to SSO simulations regardless of what you choose as the silicon driver model. =3D3D09 -Ray =3D3D09 =3D3D09 =3D3D09 Chris Cheng wrote: =3D3D09 >You can say what you want with IBIS, at the end of the day (today, not=3D3D3D20 >tomorrow or some future spec), can you do an SSO analysis based on a=3D3D3D20 >pure IBIS model ? > >I am a complete N00b on FPGA so I am curious how many people really do=3D3D3D20 >SSO analysis with just a standard IBIS description of a chip. I can't,=3D3D3D20 >so please tell me how you did it. > >Those who know me and my previous life somewhere should remember some=3D3D3D20 >of those reference SPICE SSO models I generated, there is only a small=3D3D3D20 >number of SPICE drivers, interconnect and receivers set that need to be =3D3D09 >included to accurately model SSO, x-talk, package/interconnect loss.=3D3D3D20 >Remember, m=3D3D3D3Dx is a very powerful macro that doesn't even need to be =3D3D3D an integer. > >Another interesting side note, some of the so call speedy "IBIS=3D3D3D20 >engines" end up barely faster or even slower in some cases when the=3D3D3D20 >same interconnect complexity is added to get the accuracy close to acceptable level. > >All of the above SSO modelling methodolgies are well documented and=3D3D3D20 >correlated with actual characterization numbers. I am not talking about =3D3D09 >vaporware analysis here. > =3D3D3D20 > =3D3D09 =3D3D09 -- Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Dept. Package Engineering Group Xilinx Inc. =3D3D09 =3D3D09 =3D3D09 ------------------------------------------------------------------ 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: =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: //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