To All: Itzik and Gary raised some good points related to the motivation for both the SPICE-based macromodeling and AMS approaches. The macromodeling approach is still in the proposal stage, so it is too early to speculate on how it will evolve. IBIS Version 4.1 already allows a link to Berkeley SPICE (a lowest common denominator to avoid favoring any vendor-specific SPICE). As I understand the macromodel approach, IBIS would allow some extensions that are missing in Berkeley SPICE, but common to most of the popular SPICEs including: (1) an IBIS Version 2.1 Buffer element, (2) EFGH tables, (3) some paramater passing method such as the .PARAMS syntax, and (4) some other extensions for relative or triggered time control sources. These functions along with existing equation processing and basic SPICE elements provide a possible set of "primitives" from which macromacromodels can be created to mimic more complex behaviors including those within and beyond IBIS Version 3.2/4.0. Public templates for such features can enable the industry. Several EDA vendors already connect IBIS with specific SPICE or SPICE-like languages and can immediately support the macromodeling approach. However, these approaches are vendor-specific, and the models are not portable. The IBIS challange is how to address the portability issue based on (1) a defined IBIS linkage such as in Version 4.1 and (2) a portable generic-SPICE language. The EDA tool support issue reduces to a compatibility mode to bring in any syntactically unique elements within a standardized linkage structure as in IBIS Version 4.1. Or at a lower level, the support could consist of build-in or stand-alone language convertors. IBIS needs to pick the syntax. It could range from adopting (and favoring) one vendor's syntax to a mixture of some existing syntaxes, or even to creating a new syntax to equalize the playing field, but delay support. Any supporting equation syntax already requires conversion to some vendor SPICEs. The AMS approach already gives two choices to standarize the syntax in a much more formal and robust manner. That provides its theoretical and potential future advantage. However, there are barriers to wide-spread AMS acceptance including lack of familarity, very slowly emerging EDA tool support, lack of a clearly defined "lockout" technical or performance advantage, perhaps some weaknesses in the IBIS linkage and its capbility, plus the lack of the whole industrial infrastructure involving templates, development and validation tools and industrial knowledge. The consequence is that models and linkages still have to be uniquely crafted for each vendor to overcome limitations or to add vendor-specific features. As a result, the AMS approach offers no practical model portability advantage over any vendor-specific syntax. So the AMS and macromodeling approaches could emerge as competing alternatives. From a model providers perspective (which could also be the customer's and semiconductor vendor's perspective), a winner could emerge based on how well IBIS promotes and industry accepts model portability as a driving factor (assuming one tool does not become dominant based on other factors). Bob Pratt, Gary wrote: > Hello Itzik, > > 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. > > 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). > > 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. > > 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). > > 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. > > Thats my 2 cents worth. Hope that helps. > > Gary > > ------------------------------------------------------------------------ > From: owner-ibis-users@eda.org [mailto:owner-ibis-users@eda.org] On > Behalf Of Itzik Peleg > Sent: Sunday, February 20, 2005 11:04 AM > To: ibis-users@eda.org > Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling. > > Hello IBIS users > > I want to comment on the Macromodeling: > > But, 1st proper disclosure: > > I am familiar with spice language and not familiar with AMS languages. > > Some questions: > > 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. > > 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’). > > Open for dissociation / comments. > > -- > > Regards > Itzik Peleg > Board Technology Group > > *********************************************************** > Please Note: email address change to: itzikpe@marvell.com <mailto:itzikpe@marvell.com> > *********************************************************** > Marvell Semiconductor Israel Ltd > 6 Hamada Street > Mordot HaCarmel Industrial Park > Yokneam 20692, ISRAEL > > Email - itzikpe@marvell.com <mailto:itzikpe@marvell.com> > Tel - +972 4 9091192 > Cell - +972 54 4452482 > Fax - +972 4 9091501 > > WWW Page: http://www.marvell.com <BLOCKED::http://www.marvell.com> > > ======================================================================== > > This message may contain confidential, proprietary or legally privileged > information. The information is intended only for the use of the > individual or entity named above. If the reader of this message is not > the intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > If you have received this communication in error, please notify us > immediately by telephone, or by e-mail and delete the message from > your computer. > > Thank you! > > ======================================================================== -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 503-750-6481 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com Teraspeed is a registered service mark of Teraspeed Consulting Group LLC |------------------------------------------------------------------ |For help or to subscribe/unsubscribe, email majordomo@eda.org |with just the appropriate command message(s) in the body: | | help | subscribe ibis <optional e-mail address, if different> | subscribe ibis-users <optional e-mail address, if different> | unsubscribe ibis <optional e-mail address, if different> | unsubscribe ibis-users <optional e-mail address, if different> | |or email a written request to ibis-request@eda.org. | |IBIS reflector archives exist under: | | http://www.eda.org/pub/ibis/email_archive/ Recent | http://www.eda.org/pub/ibis/users_archive/ Recent | http://www.eda.org/pub/ibis/email/ E-mail since 1993Received on Tue Feb 22 19:09:57 2005
This archive was generated by hypermail 2.1.8 : Tue Feb 22 2005 - 19:12:07 PST