Ian, Does this mean that you don't want SPICE in IBIS after all? Or are you suggesting that we develop a STANDARD SPICE? Arpad ============================= -----Original Message----- From: Dodd, Ian [mailto:ian_dodd@mentor.com] Sent: Friday, November 10, 2006 2:17 PM To: Muranyi, Arpad; ibis@eda.org; ibis-macro@freelists.org Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit Arpad, Such is the beauty of an International Standard such as VHDL-AMS. Ian -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad Sent: Friday, November 10, 2006 3:00 PM To: ibis@eda.org; ibis-macro@freelists.org Subject: [ibis-macro] Re: Your presentation at Asia Summit Ian, And what is the poor customer going to do if he gets an IBIS file from Intel, say for a memory controller, that links to an (encrypted) HSPICE model, and he gets another IBIS file from a memory chip vendor which links to a TLsim model (that is incompatible with the HSPICE controlled sources) and there is no simulator that can simulate the two models together? Arpad ======================================================== -----Original Message----- From: Dodd, Ian [mailto:ian_dodd@mentor.com] Sent: Friday, November 10, 2006 1:51 PM To: Muranyi, Arpad; ibis@eda.org; ibis-macro@freelists.org Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit Arpad, I would only be really happy if it were an encrypted Eldo model :-) ... Ok before you all flame me, I was only joking! We have always tried to make IBIS vendor neutral. In my opinion, if we decide to support parameter passing, it must equally support all of the major SPICE (or SPICE like) simulators. That includes HSPICE, Spectre, Eldo, Tlsim etc (my apologies if your favorite commercial simulator is not here). I don't see a difference as to whether the SPICE netlist is partially or completely encrypted. Is there something I have missed? Ian -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad Sent: Friday, November 10, 2006 2:32 PM To: ibis@eda.org; ibis-macro@freelists.org Subject: [ibis-macro] Re: Your presentation at Asia Summit Ian, and Lance, Neither one of you said anything on how you would go about this SPICE support, and which SPICE? Even if we say that on the interface level in IBIS, [External Model] and [External Circuit], there is no need to know which SPICE language is inside the external SPICE file, what happens if I made an IBIS file that references as encrypted HSPICE model and distributed it to my customers? Would Mentor and Cadence be happy? Arpad ================================================== -----Original Message----- From: Dodd, Ian [mailto:ian_dodd@mentor.com] Sent: Friday, November 10, 2006 1:14 PM To: lwang@cadence.com; Muranyi, Arpad Cc: ibis@eda.org; ibis-macro@freelists.org Subject: RE: [ibis-macro] Re: Your presentation at Asia Summit Lance, I agree with the majority of your statements. There is a need to better support SPICE macro-modeling. I support giving the High Speed user the option to use either SPICE macro-modeling or AMS. As part of this I support parameter passing into SPICE models (macro or otherwise). I do very much disagree with your comment about needing to be a rich company to afford to purchase AMS enabled tools. At least one of the big three EDA vendors is presently offering a full VHDL-AMS option with all of their SI tools. The charge for the additional AMS functionality is around 15% of the SI product base price. Incidentally, let's not let marketing and the internal politics of EDA companies get in the way of the user having the best tools. Many EDA companies have developed AMS simulation technology. Those that have not, can almost certainly license it from third parties. When safeguards are put in place, so that tools intended for High Speed Analysis cannot be used for IC design, the EDA vendor has the opportunity to set a very aggressive price for AMS functionality. I have been very careful not to try to use this as a marketing platform. I hope you take my statements in the way they were intended: about technology and its availability, not about selling a particular brand. Note again that, with the exception of your comments about the price charged for AMS, I agree with your initiative. Ian Dodd Mentor Graphics Inc. -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Lance Wang Sent: Thursday, November 09, 2006 1:23 PM To: arpad.muranyi@intel.com Cc: ibis@eda.org; ibis-macro@freelists.org Subject: [ibis-macro] Re: Your presentation at Asia Summit Hi, Arpad, Thanks for reading my prez and asking so detailed questions about the conclusions. :) Let me give you some backgrounds for making this presentation first. As everyone noticed, PCIe/Serdes type devices are more and more shown in current electronic market especially 2.5/3.125GHz devices. The first problem the vendors met is how to deliver the SI models to their customers so they can do the simulations accurately, fast and also IP protected since the simulation is required for this kind of designs. What they have in hands first is the Spice transistor-level models (mainly HSpice compatible models). They would look for IBIS solutions as well for these models. However, unfortunately, traditional IBIS can't correctly model them. Then, people looked into IBIS [External model] in 4.1 and 4.2. What they found is that IBIS only allows Berkley-Spice (3f4?). This is not what they look for. (I think I don't need to list the issues using Berkley-Spice here.) Will AMS do the trick? Yes or No. Yes, AMS is functional for this technology. No, not a lot of people (companies) want to spend extra-cost for the tools expect some rich companies. (These are not $9.99 products. Correctly me if I am wrong.) More naturally problem is that there is no push button solution for AMS SI models now. What did they end up? Using IBIS [External model] with Spice transistor-level models. Please note these are NOT Berkley Spice models. Also, there are a lot of parameter settings in PCIe models. For the ease of use, Parameter passing is required for Spice [External model] even if IBIS didn't allow them. In this stage, simulation performance and IP protection are the big concerns for the IBIS "Advanced" Spice [External model]. The macromodeling is kicking in solving these issues, I meant IBIS "Advanced" Spice Macromodeling. Yes, the requirements from this presentation conclusion are somehow related. When IBIS opens for "Advanced" Spice, parameter passing requirement can be processed. However, "self-containing" capability should be required for IBIS Macromodeling in general included AMS types as well. Thanks, Lance Wang Cadence Design Systems, Inc. -----Original Message----- From: ibis-macro-bounce@freelists.org [mailto:ibis-macro-bounce@freelists.org] On Behalf Of Muranyi, Arpad Sent: Thursday, November 09, 2006 1:28 PM To: ibis@eda.org; ibis-macro@freelists.org Subject: [ibis-macro] Your presentation at Asia Summit Lance, I read your presentation you gave at the Asia IBIS Summits and I would like to ask you a couple of questions regarding your "IBIS future enhancement requests" on the "conclusions" slide (pg. 31). http://www.vhdl.org/pub/ibis/summits/oct06b/wang.pdf You are asking for opening the SPICE link in IBIS to other commercial SPICE simulators, and consequently you are also asking for the parameter passing capabilities for [External Model] (and probably [External Circuit] also) which was not made available in the IBIS specification because Berkeley SPICE does not have that capability. Questions: 1) The first sentence in Section 2 of the IBIS specification which is entitled "Statement of Intent" says the following: | In order to enable an industry standard method to electronically transport | IBIS modeling data between semiconductor vendors, EDA tool vendors, and end | customers, this template is proposed. The intention of this template is to | specify a consistent format that can be parsed by software, allowing EDA | tool vendors to derive models compatible with their own products. In other words, the IBIS specification was intended to provide a common modeling language for the EDA industry. Your request seems to be asking the endorsement of proprietary SPICE languages in IBIS, which goes in the exact opposite direction of the "IBIS philosophy" which was to eliminate the need to make zillions of tool specific models for the same product. How do you see your request to be fulfilled? 2) The very reason the IBIS macro modeling subcommittee spent about two years to put together the IBIS macro modeling library was to solve this problem. We wrote a SPICE compatible library in the *-AMS languages so that tools which cannot interpret the *-AMS languages could by substitution use their own native SPICE equivalents. See pg. 2 in the following presentation: http://www.vhdl.org/pub/ibis/summits/mar06/muranyi2.pdf See pg. 7 in the following presentation: http://www.vhdl.org/pub/ibis/summits/feb06/westerhoff.pdf Everything that you showed in the above presentation could have been implemented with the IBIS macro modeling library. Why are you not making use of this library, and why are you requesting that features which are already available in IBIS through the macro library be made available with proprietary SPICE languages which is what we wanted to avoid with the entire IBIS macro modeling initiative? Thanks, Arpad ====================================================================== --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: http://www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@freelists.org Subject: unsubscribe -------------------------------------------------------------------- |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 14:19:36 2006
This archive was generated by hypermail 2.1.8 : Fri Nov 10 2006 - 14:19:46 PST