Hi, Arpad, I am trying to answer the questions in your email below. Please note these may not be necessary Cadence views but my personal's. 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 4:54 PM To: ibis@eda.org; ibis-macro@freelists.org Subject: [ibis-macro] Re: Your presentation at Asia Summit Lance, Thanks for your reply. I agree, the ultimate goal is to get models into the hands of the customer. But this is a lot easier said than done... I also agree that traditional IBIS is falling short for these high speed models. Your summary of the history is also pretty good, saying that there was SPICE, then IBIS and then SPICE started to regain strength again. But I am starting to disagree with what you say after that. 1) It is true that there are not too many "push button" *-AMS solutions out there, but there are some, or some which come close. [LW] this might be the key to get *-AMS really take off in the future. 2) What you don't seem to realize or acknowledge is that the IBIS macro model library was written in such a way that those tool vendors who do not have *-AMS engines in their SI tool could also make use of it BY SUBSTITUTION. The only thing these tools need to develop is an *-AMS netlist reader or converter which takes the Verilog-A(MS) or VHDL-A(MS) formatted macro netlist (template) and convert it to the tool's internal netlist syntax. This could be achieved with relatively simple Perl scripts. So there is no need for extra cost and richness. [LW] You are under-estimates how I looked closely to the IBIS Macro model library works, especially your works inside. However, these are just templates or suggestions or recommendations. The issue for them is that users may easily go out of them to make the functionalities they needed. IBIS didn't specify AMS usage limitations in multilingual extensions. (I don't know how IBIS could do so.) This is out of Perl scripts or simple translations to Spice syntax. 3) Actually ending up with transistor level SPICE under [External Model] is not completely true either. Yes, there may be a lot of these out there, but most everyone agrees that these are way too slow, and there is an increasing number of SPICE behavioral models out there too. These could very well be written using the IBIS macro library elements. In fact your presentation seems to be on this level, that's why I was wondering why you didn't do it using the IBIS macro library elements. [LW] You are right. The end should not be the transistor-level models. Spice Macromodeling is about to solve this problem. The reason to not use Macro library elements is because there is no Spice syntax element and practically Spice is the most popular syntax for now at least. I would love to make a presentation using these AMS elements when it is getting more mainstream. 4) The "advanced" IBIS macro modeling project is actually not talking abut addressing the above problems. It is mostly addressing those problems which are most commonly done in Matlab, C or other languages. [LW] I pointed out the case study is for 2.5/3.125GHz PCIe. Beyond of this, due to more algorithms used inside, Matlab, C or other languages will be needed. 5) Even if we put aside all of the above arguments and assume that we want to make your request a reality, how would you go about it? Would you make HSPICE legal under IBIS? If we did that, all of the non-HSPICE vendors will start screaming. Should we make all SPICE flavors legal under IBIS so we don't hurt anyone's feelings? If we did that, we would be back to 1993, when we could not simulate anything because there were so many different types of incompatible models. Continuing with these thoughts in the light of the IBIS advanced technology modeling activities for high speed SERDES modeling, how would you feel if we also made Matlab, Mathematica, C, C++ and other favorites legal under IBIS? Wouldn't that create a tower of Babel situation in the world of EDA tools and models? Would your company be willing to support ALL of these languages in your SI tool, so that people could use models written in any of these languages and cosimulate them together? I think that would eve cost you more than supporting only one of the *-AMS languages that your company already has in your other tools... [LW] my view is to open IBIS to allow all languages as long as it will fit in for the ports/nodes requirements/definitions in IBIS. This solves immediate needs, I think. About supports, vendors usually not support all but mainstreams and strategic ones. (Again, this is my personal view.) For example, if HSpice is the most popular one, the HSpice compatibility project will be launched. If AMS is the strategic one in your company, it will be supported. 6) How would you propose to solve this language problem? [LW] To be honestly, I don't have an obviously solution for this. However, open IBIS multilingual to others would solve some immediate needs. Ideally, I would like to see some enhancements inside native IBIS not through multilingual extensions in the future. Please remember the recent IBIS' growing is not because of IBIS linked with AMS. Using AMS to solve all the issues IBIS has is not helping IBIS grown at all. (Actually it is killing IBIS in the long run, as my personal view.) Thanks, Arpad ============================================================ -----Original Message----- From: Lance Wang [mailto:lwang@cadence.com] Sent: Thursday, November 09, 2006 12:23 PM To: Muranyi, Arpad Cc: ibis@eda.org; ibis-macro@freelists.org Subject: RE: [ibis-macro] 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 -------------------------------------------------------------------- |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 12:44:37 2006
This archive was generated by hypermail 2.1.8 : Fri Nov 10 2006 - 12:45:08 PST