Arapd and all: Everybody has good points. The choice is between purity of the Berkeley SPICE linkage versus practical and useful implementations. I would support adding parameter passing for SPICE for several reasons. 1. It is needed, useful, and is equivalent to the AMS and A(MS) feature set. 2. By specifying it, we control the definition and interpretation to a lower common subset that is already compatible with most tools. For example, it would link to a .param statement within "SPICE", and not to any other proprietary syntax. 3. I suspect that all vendors with "IBIS" linkages to SPICE are already forced to add vendor-specific "IBIS" extensions for parameter passing or use some other non-compliant and awkward work-around superset implementation such as introducing artificial nodes for parameter control. 4. Technically, the IBIS parameter syntax becomes a harmless no-op in pure Berkeley SPICE. Yes, this will promote vendor-specific SPICEs, but that is already a required and dominant business reality. Ignoring this reality is like winning the battle, but loosing the war. Without an IBIS solution, vendors will continue the next immediate path of supporting proprietary, self contained "kit" solutions and thereby slow the adoption of IBIS for model portability - in all languages. Pure Berkeley SPICE is too limited to be of value for complex buffers. However, it still remains the lowest common denominator level of SPICE for maximum portability for some practical situations. So, I support some functional extensions beyond Berkeley SPICE including passing parameters. I would try to limit the syntax and intepretation, if possible, to the most popular methods for model portability. That way, IBIS remains (mostly) vendor-neutral, but becomes a real option for solving more problems with existing tools and methods. Where needed and valuable, other language solutions then follow more easily in future evolution plans. Bob Muranyi, Arpad wrote: > Ian, > > I think your observation in the last paragraph of your message > is correct, but this is exactly the problem. Whether we make > this practice legal in IBIS or not is not the issue. The issue > is that these proprietary solutions only work with their corresponding > proprietary tools. IBIS was started and motivated exactly to > eliminate that situation. These requests you and Lance are talking > about is going in the exact opposite direction of the original > goal IBIS was invented for. We might as well get rid of IBIS > and all other efforts to have any industry standard modeling > languages (*-AMS) then... > > Arpad > ===================================================================== > > > > > -----Original Message----- > From: Dodd, Ian [mailto:ian_dodd@mentor.com] > Sent: Friday, November 10, 2006 2:52 PM > To: Muranyi, Arpad; ibis@eda.org; ibis-macro@freelists.org > Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit > > Arpad, > > I want to support the customer to be provided with the best solutions. > > I have said many times, that I believe AMS is the best technical > solution for full circuit simulation of the newer technologies. > Unfortunately, there are two barriers to AMS adoption: the first is > getting the majority of the EDA vendors to make their best technology > available in their SI tools, the second is the training of model > creators to use a new languages. Progress is being made on both these > fronts, but it is not as fast as I would like to see. > > Switching from the AMS issue to SPICE: > > I think we have all agreed that for us to try to create a standard for > SPICE is not a fruitful activity. > > I do believe that SI tools should be able to pass parameters to SPICE > syntax sub-circuits that represent the behavior of IBIS components. The > SI tools that implement this feature will have to know the exact syntax > (and parameter data types) to be used for each simulator that is > supported. > > Correct me if I am wrong, but I believe that at least two SI tool > vendors already have proprietary enhancements to allow parameters to be > passed to SPICE sub-circuits. > > Ian > > -------------------------------------------------------------------- > |For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org > |with 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 e-mail a request to ibis-request@eda-stds.org. > | > |IBIS reflector archives exist under: > | > | http://www.eda-stds.org/pub/ibis/email_archive/ Recent > | http://www.eda-stds.org/pub/ibis/users_archive/ Recent > | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993 > -- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 401-284-1827 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, e-mail majordomo@eda-stds.org |with 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 e-mail a request to ibis-request@eda-stds.org. | |IBIS reflector archives exist under: | | http://www.eda-stds.org/pub/ibis/email_archive/ Recent | http://www.eda-stds.org/pub/ibis/users_archive/ Recent | http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993Received on Fri Nov 10 21:20:13 2006
This archive was generated by hypermail 2.1.8 : Fri Nov 10 2006 - 21:21:11 PST