Gary, That's an interesting tool to say the least. So basically you are suggesting using IBIS 4.1 to get the SPICE level circuit description of the I/O and perform the analysis. 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 ? 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. 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. -----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. =20 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.) =20 So, the benefits to spice experts are good: =20 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. =20 A huge improvement over traditional SPICE behavioral modeling. Believe me, as someone=20 who spent a great deal of the 80s and 90s doing SPICE behavioral modeling ... once you=20 go to an analog programming language, you will never go back to SPICE behavioral. Here=20 are some analogies (of varying accuracy): 1) Assembly language versus C - assembly language is more powerful than SPICE, don't=20 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=20 be more flexible than the early digital macro-modeling techniques. 3) IBIS provides the connectivity information missing from SPICE, allowing simple and easy=20 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=20 IBIS 4.1, it can automatically create a file containing all the information SPICE needs=20 for an SSN simulation (which outputs are being switched, how each output is configured,=20 which outputs are tied high or low to improve SSN, etc). =20 6) This is all done within an industry standard framework. No more proprietary or defacto=20 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. =20 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=20 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=20 its associated package power planes. =20 3) This assumes the I/O and its associated power supplies can be divided into relatively=20 independent banks (consisting of port counts in the low hundreds).=20 Does this still sound useful even with these caveats? =20 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. =20 =20 I attached a couple of postings to the IBIS list which you might find interesting as well. =20 Gary =20 =20 ************************************************************************ ************************************************************************ ********* Reprints of IBIS postings ************************************************************************ ************************************************************************ ********** Hello Itzik, =20 =20 =20 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. =20 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). =20 =20 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. =20 =20 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). =20 =20 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. =20 =20 Thats my 2 cents worth. Hope that helps. =20 =20 Gary =20 =20 =20 ------------------------------------------------------------------------ -------- 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>=20 Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling. =20 Hello IBIS users =20 I want to comment on the Macromodeling:=20 =20 But, 1st proper disclosure: =20 I am familiar with spice language and not familiar with AMS languages.=20 =20 Some questions: =20 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. =20 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'). =20 Open for dissociation / comments. =20 -- Regards =20 Itzik Peleg Board Technology Group =20 *********************************************************** Please Note: email address change to: itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=20 *********************************************************** =20 Marvell Semiconductor Israel Ltd 6 Hamada Street=20 Mordot HaCarmel Industrial Park Yokneam 20692, ISRAEL Email - itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=20 Tel - +972 4 9091192 Cell - +972 54 4452482 Fax - +972 4 9091501 WWW Page: http://www.marvell.com <http://www.marvell.com>=20 =20 =20 ************************************************************************ ************************************************************************ ********* Second Reprint of IBIS postings ************************************************************************ ************************************************************************ ********** =20 Hi Lee, =20 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. =20 (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. ) =20 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. =20 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. =20 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. =20 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. =20 =20 I hope that helps, =20 Gary =20 -----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 =20 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 of=20 >flexibility. So for instance, instead of waiting for functionality to=20 >be added to the IBIS standard and then waiting for SI tool vendors to=20 >implement the function; VHDL-AMS provides you the ability to implement=20 >the function immediately. To date, the flexibility of VHDL-AMS has=20 >provided significant benefit in simplifying modeling of highly=20 >configurable devices such as PCI Express drivers and difficult to model >receivers containing internal equalization. I suspect VHDL-AMS could=20 >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=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=20 >anyone please give some background about it? >Since we already have IBIS model, what is the reason we need to use=20 >VHDL-AMS model instead? What is the pros and cons compared to IBIS=20 >model? >Thanks and appreciate if someone can shed some light. > >-Lee Yang =20 =20 ************************************************************************ ************************************************************************ ********* END OF Reprints of IBIS postings ************************************************************************ ************************************************************************ ********** =20 =20 =20 =20 =20 ________________________________ From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx]=20 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 =09 =09 The tool is [Pratt, Gary] XXXXXXXXX . Its been available from [Pratt, Gary] XXXXXXXX for almost two years now. =20 =09 =20 ________________________________ 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 =09 =09 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. =09 -----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 =09 =09 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). =3D20 =09 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. =3D20 =09 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. =3D20 =09 Gary =09 =09 =09 -----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 =09 Chris- =09 I think you may be misinterpreting what Lynne and the other posters in this thread have been discussing so far. =09 No one seems to be saying that SSO simulations should be done with IBIS (as it stands today). =09 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. =09 -Ray =09 =09 =09 Chris Cheng wrote: =09 >You can say what you want with IBIS, at the end of the day (today, not=3D20 >tomorrow or some future spec), can you do an SSO analysis based on a=3D20 >pure IBIS model ? > >I am a complete N00b on FPGA so I am curious how many people really do=3D20 >SSO analysis with just a standard IBIS description of a chip. I can't,=3D20 >so please tell me how you did it. > >Those who know me and my previous life somewhere should remember some=3D20 >of those reference SPICE SSO models I generated, there is only a small=3D20 >number of SPICE drivers, interconnect and receivers set that need to be =09 >included to accurately model SSO, x-talk, package/interconnect loss.=3D20 >Remember, m=3D3Dx is a very powerful macro that doesn't even need to be =3D an integer. > >Another interesting side note, some of the so call speedy "IBIS=3D20 >engines" end up barely faster or even slower in some cases when the=3D20 >same interconnect complexity is added to get the accuracy close to acceptable level. > >All of the above SSO modelling methodolgies are well documented and=3D20 >correlated with actual characterization numbers. I am not talking about =09 >vaporware analysis here. > =3D20 > =09 =09 -- Raymond Anderson Senior Signal Integrity Staff Engineer Product Technology Dept. Package Engineering Group Xilinx Inc. =09 =09 =09 ------------------------------------------------------------------ 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