[SI-LIST] Re: package SSN model accuracy requirements
- From: steve weir <weirsi@xxxxxxxxxx>
- To: gary_pratt@xxxxxxxxxxx, <Chris.Cheng@xxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Fri, 11 Mar 2005 13:34:50 -0800
Gary, I was looking at the IBIS Summit information, and a couple of the
presentations make it apparent that compliance and usage beyond 2.0 is
poor. Cadence in particular did a survey that showed that SPICE is taking
a lot of ground from IBIS because the IBIS world has not provided the
models needed for OEMs to get their jobs done. I guess this all sounds
great if you're Synopsys.
I think that if this situation is to reverse, it is going to require some
real courage and $$$ from: tool vendors, silicon vendors, and OEMs to get
over the hump and make IBIS w/AMS something that reverses the trend towards
SPICE. How will Mentor and Cadence convince Synopsys to play when the
current trend favors Synopsys? Who is going to champion this at the IC
vendors when their customers almost universally have H-SPICE capability and
not a spiffy 4.1+ compliant IBIS tool with engineers trained and willing to
use it?
Don't get me wrong, I like the reported results of AMS and the benefits it
brings. I just see a major set of market hurdles.
Regards,
Steve.
At 01:32 PM 3/11/2005 -0500, Pratt, Gary wrote:
>Chris,
>
>Comments are embedded below.
>
>Gary
>
>=20
>
>-----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.=20
>
>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=3D> Not exactly. I was suggesting the slow, convergence-prone =
>SPICE
>models be replaced with fast, highly-reliable, industry standard Analog
>Behavioral Models (aka AMS). =20
>
>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=3D> 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=3D> But, I think there is a larger concern here ... I admit to =
>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=3D> 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=3D> Yes. That's one advantage to this tool I forgot to mention. =
>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.=20
>
>Gary=3D> 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.
>=3D20
>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.) =3D20 So, the benefits
>to spice experts are good: =3D20
>
> 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. =3D20
> A huge improvement over traditional SPICE behavioral
>modeling. Believe me, as someone=3D20
> who spent a great deal of the 80s and 90s doing SPICE
>behavioral modeling ... once you=3D20
> go to an analog programming language, you will never go back
>to SPICE behavioral. Here=3D20
> are some analogies (of varying accuracy):
>
> 1) Assembly language versus C - assembly language is
>more powerful than SPICE, don't=3D20
> 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=3D20
> be more flexible than the early digital
>macro-modeling techniques.
>
> 3) IBIS provides the connectivity information missing from
>SPICE, allowing simple and easy=3D20
> 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=3D20
> IBIS 4.1, it can automatically create a file containing all
>the information SPICE needs=3D20
> for an SSN simulation (which outputs are being switched, how
>each output is configured,=3D20
> which outputs are tied high or low to improve SSN, etc). =3D20
> 6) This is all done within an industry standard framework. No
>more proprietary or defacto=3D20
> 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.
>
>=3D20
>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=3D20
> 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=3D20
> its associated package power planes. =3D20
> 3) This assumes the I/O and its associated power supplies can be
>divided into relatively=3D20
> independent banks (consisting of port counts in the low
>hundreds).=3D20
>
>Does this still sound useful even with these caveats?
>=3D20
>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. =3D20 =3D20 I attached a =
>couple
>of postings to the IBIS list which you might find interesting as well.
>=3D20
>Gary
>=3D20
>=3D20
>************************************************************************
>************************************************************************
>*********
>Reprints of IBIS postings
>************************************************************************
>************************************************************************
>**********
>Hello Itzik,
>=3D20
>=3D20
>=3D20
>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.
>=3D20
>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). =3D20 =3D20 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. =3D20 =3D20 As I understand, the reason the IBIS committee adopted =
>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). =3D20
>=3D20
>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. =3D20 =3D20 Thats my 2 cents =
>worth.
>Hope that helps.
>=3D20
>=3D20
>Gary
>=3D20
>=3D20
>=3D20
>------------------------------------------------------------------------
>--------
>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>=3D20
>Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling.
>=3D20
>
>Hello IBIS users
>=3D20
>I want to comment on the Macromodeling:=3D20 =3D20 But, 1st proper
>disclosure:
>=3D20
>I am familiar with spice language and not familiar with AMS
>languages.=3D20 =3D20 Some questions:
>=3D20
>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.
>=3D20
>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').
>=3D20
>Open for dissociation / comments.
>=3D20
>--
>Regards
>=3D20
>Itzik Peleg
>Board Technology Group
>=3D20
>***********************************************************
>Please Note: email address change to: itzikpe@xxxxxxxxxxx
><mailto:itzikpe@xxxxxxxxxxx>=3D20
>***********************************************************
>=3D20
>Marvell Semiconductor Israel Ltd
>6 Hamada Street=3D20
>
>Mordot HaCarmel Industrial Park
>Yokneam 20692, ISRAEL
>Email - itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=3D20
>Tel - +972 4 9091192
>Cell - +972 54 4452482
>Fax - +972 4 9091501
>WWW Page: http://www.marvell.com <http://www.marvell.com>=3D20 =3D20 =
>=3D20
>************************************************************************
>************************************************************************
>*********
>Second Reprint of IBIS postings
>************************************************************************
>************************************************************************
>**********
>=3D20
>Hi Lee,
>=3D20
>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.
>=3D20
>(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. ) =
>=3D20
>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.
>=3D20
>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.
>=3D20
>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.
>=3D20
>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. =3D20 =3D20 I hope =
>that
>helps, =3D20 Gary =3D20 -----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 =3D20 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=20
> >of=3D20 flexibility. So for instance, instead of waiting for=20
> >functionality to=3D20 be added to the IBIS standard and then waiting =
>for=20
> >SI tool vendors to=3D20 implement the function; VHDL-AMS provides you =
>the
>
> >ability to implement=3D20 the function immediately. To date, the=20
> >flexibility of VHDL-AMS has=3D20 provided significant benefit in=20
> >simplifying modeling of highly=3D20 configurable devices such as PCI=20
> >Express drivers and difficult to model
>
> >receivers containing internal equalization. I suspect VHDL-AMS=20
> >could=3D20 also be applied to implementing the functionality required =
>for
>
> >modeling
>
> >power integrity.
> >
> >Gary
> >
> >
> >
> >-----Original Message-----
> >From: owner-ibis-users@xxxxxxx [mailto:owner-ibis-users@xxxxxxx] =
>On=3D20=20
> >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=3D20 =
>
> >anyone please give some background about it?
> >Since we already have IBIS model, what is the reason we need to =
>use=3D20=20
> >VHDL-AMS model instead? What is the pros and cons compared to IBIS=3D20 =
>
> >model?
> >Thanks and appreciate if someone can shed some light.
> >
> >-Lee Yang
>=3D20
>=3D20
>************************************************************************
>************************************************************************
>*********
>END OF Reprints of IBIS postings
>************************************************************************
>************************************************************************
>**********
>=3D20
>=3D20
>=3D20
>=3D20
>=3D20
>________________________________
>
>From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx]=3D20
>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
>=3D09
>=3D09
> The tool is [Pratt, Gary] XXXXXXXXX . Its been available from
>[Pratt, Gary] XXXXXXXX for almost two years now. =3D20
>=3D09
> =3D20
>________________________________
>
> 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
>=3D09
>=3D09
>
> 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.
>=3D09
> -----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
>=3D09
>=3D09
> 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).
>=3D3D20
>=3D09
> 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. =3D3D20
>=3D09
> 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. =3D3D20
>=3D09
> Gary
>=3D09
>=3D09
>=3D09
> -----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
>=3D09
> Chris-
>=3D09
> I think you may be misinterpreting what Lynne and the other
>posters in
> this thread have been discussing so far.
>=3D09
> No one seems to be saying that SSO simulations should be done
>with IBIS
> (as it stands today).
>=3D09
> 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.
>=3D09
> -Ray
>=3D09
>=3D09
>=3D09
> Chris Cheng wrote:
>=3D09
> >You can say what you want with IBIS, at the end of the day
>(today, not=3D3D20
> >tomorrow or some future spec), can you do an SSO analysis based
>on a=3D3D20
> >pure IBIS model ?
> >
> >I am a complete N00b on FPGA so I am curious how many people
>really do=3D3D20
> >SSO analysis with just a standard IBIS description of a chip. I
>can't,=3D3D20
> >so please tell me how you did it.
> >
> >Those who know me and my previous life somewhere should
>remember some=3D3D20
> >of those reference SPICE SSO models I generated, there is only
>a small=3D3D20
> >number of SPICE drivers, interconnect and receivers set that
>need to be
>=3D09
> >included to accurately model SSO, x-talk, package/interconnect
>loss.=3D3D20
> >Remember, m=3D3D3Dx is a very powerful macro that doesn't even
>need to be =3D3D
> an
> integer.
> >
> >Another interesting side note, some of the so call speedy
>"IBIS=3D3D20
> >engines" end up barely faster or even slower in some cases when
>the=3D3D20
> >same interconnect complexity is added to get the accuracy close
>to
> acceptable level.
> >
> >All of the above SSO modelling methodolgies are well documented
>and=3D3D20
> >correlated with actual characterization numbers. I am not
>talking about
>=3D09
> >vaporware analysis here.
> > =3D3D20
> >
>=3D09
>=3D09
> --
> Raymond Anderson
> Senior Signal Integrity Staff Engineer
> Product Technology Dept.
> Package Engineering Group
> Xilinx Inc.
>=3D09
>=3D09
>=3D09
>
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
> http://www.si-list.org
>
>List archives are viewable at: =20
> //www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
> =20
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
> http://www.si-list.org
>
>List archives are viewable at: =20
> //www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
> =20
>
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
> http://www.si-list.org
>
>List archives are viewable at:
> //www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
Please update your address book with weirsi@xxxxxxxxxx
------------------------------------------------------------------
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
Other related posts:
