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 *********************************************************** Marvell Semiconductor Israel Ltd 6 Hamada Street Mordot HaCarmel Industrial Park Yokneam 20692, ISRAEL Email - 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! ======================================================================== |------------------------------------------------------------------ |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 08:01:36 2005
This archive was generated by hypermail 2.1.8 : Tue Feb 22 2005 - 08:06:11 PST