Hi All, I vote for the following in this discussion: 1. Emphasize the use of "call external model," where the complexity of a model doesn't fit within settled and established IBIS modeling. Who can predict what will work best in a given situation: macromodeling, measured behavioral modeling (example: S-Parameters), or AMS equation based? The user's familiarity (and personal attachment to) with the various modeling methods, also availability of a model, etc., also influences their choice. I believe that IBIS's mission is to provide a means for data exchange. I also believe there is no such thing as the best model for all cases. It depends on the application. Regarding the detail versus speed (abstraction, simplification, portability) question, it also depends on the application . Therefore, the "best" model will be a tradeoff of type, abstraction, portability and skill of the user applying it. To settle on any one type of modeling approach, especially at this point, actually constricts the ability to design. More on user application and skill in item 3, below. 2. Users must vote with their wallets if they want good models. Model quality depends mostly on who is doing the modeling and do they see producing a good circuit level model as in their bottom line interest. Model makers, especially those who sell parts and are in the best position to make meaningful models, will not put forward the expensive effort to make good circuit level models unless there is a payoff. If there is no negative impact on business due to poor, or non-existent models, why spend a ton of money producing something that doesn't really apply to semiconductor process control? We would still have inaccurate, unsuitable models were we to convert completely to HSPICE (widely used in process control) in our tools, models and simulations. The type of characterization needed for process control is NOT the same as for circuit simulation. SPICE models can also be just plain wrong, especially as technology continues to evolve. ANY step away from process control modeling to -- you name it: HSPICE that includes non-zero diode clamp resistance, IBIS, AMS, macromodeling, behavioral black-box -- requires additional investment by the model maker and there has to be a payoff or penalty involved. 3. IBIS should facilitate an understanding of modeling, simulation, and application skill. This can be done by posting articles and collateral on the IBIS web site. We don't have to endorse any EDA tool, model provider OR modeling method. Rather than embrace any one modeling technique, let's facilitate anything that contributes to design solutions. Modeling will continue to evolve as technology evolves. All circuit designers know, or should know, that ANY model has speed, accuracy, range of application, and availability issues. That is why we design with guard bands, seek more accurate models when we need/can get them, simulate early with generic and approximate models when we can still make strategic circuit and layout choices, and much more besides. But, it would certainly help us to get educated in the tradeoffs. As product delivery date approaches and circuit choices narrow we need (if we are unlucky, or unskilled) to go to more accurate, longer simulating models. Let's focus on problem solution, not modeling method. Anyway, that's my story, and I'm sticking to it. Best Regards to All, Roy -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org]On Behalf Of Todd Westerhoff (twesterh) Sent: Tuesday, April 05, 2005 9:05 AM To: 'ibis' Subject: RE: [IBIS] AMS tastes great and leaves your teeth shiny white, too! Arpad, 1) Geez, I'm really, really sorry. I completely understand your position and feelings, and you'll never hear me bring up the IBIS prayer again. My first point wasn't meant to be an allusion of any kind. I was pointing out that you've done as much work with AMS for SI as anyone, and if you're convinced it has the capabilities to go forward, I'm inclined to agree. I was simply saying you're in the lead with modeling experience at this point - nothing more. 2/3/4) It's a conundrum, isn't it? We fix the present, we delay the future. We focus on the future, we have trouble getting by in the present. I don't have the answer here; it's a balancing act we have to sound out as we go forward. I was intrigued by last night's discussion of EFGH sources. I agree we can't end up endorsing a specific SPICE version ... so the question is, is there any set of sources we can reliably take as common? Macromodeling could still have value without controlled sources, but I'm inclined to agree that it probably isn't worth the effort without them. I think we need to figure out whether there are a viable set of controlled sources we can rely on or not, and go from there. Going forward, I think we need to continue to look at the "big" picture in modeling - the combination of language, model development tools, documentation and EDA tool support. As you point out, it does us little good to define a standard if EDA vendors do what they want anyway. Similarly, a great language and simulator does us little good if few people can develop models for it. It's taken quite a while to get IBIS in its present state - if we're going to move toward AMS, we will repeatedly have to ask ourselves the question "what does this mean to the average user?" My apologies again for my inappropriate humor. It was never meant to offend - it was only meant to highlight your leadership in a lighthearted way. Your contributions to SI are welcomed and sincerely appreciated, and I was just trying to point that out. Todd. Todd Westerhoff High Speed Design Group Manager Cisco Systems 1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@cisco.com ph: 978-936-2149 ============================================ "Always do right. This will gratify some people and astonish the rest." - Mark Twain -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad Sent: Monday, April 04, 2005 5:23 PM To: ibis Subject: RE: [IBIS] AMS tastes great and leaves your teeth shiny white, too! Todd, 1) Please don't start that again... "if he says AMS is the future, it probably is". In fact I would like to take this opportunity and publicly ask you not to make a habit of these kinds of allusions, and please stop that IBIS prayer "tradition" if possible... Not because I don't understand jokes, I could tolerate it once, but simply because I am a religious man and have a very difficult time with being elevated to levels (even in the form of a joke) where God alone deserves to be... I hope you can relate to that. 2/3) I agree completely. I don't think that the macromodeling proposal is a bad idea. I am just concerned that if this is made into a a standard, people will get too cozy in it to move on towards something better, or may divert the general direction for the long term solution. Plus, there are a few of us who could already use that long term solution NOW. 4) I agree with your observation in this too. In fact I wonder some times what good is it to have the IBIS Open Forum if the major players pretty much do anything they want to do anyway? Little active participation, out-of spec or partial spec implementations, etc... I don't want to go too deep here, but I feel we are in different times from the way IBIS started... Arpad =================================================================== -----Original Message----- From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Todd Westerhoff (twesterh) Sent: Monday, April 04, 2005 1:15 PM To: 'ibis' Subject: [IBIS] AMS tastes great and leaves your teeth shiny white, too! Sorry, couldn't help myself ;-). A few points I'm still stubbornly trying to make .... 1) The future of AMS I have little doubt that Arpad can do great things with AMS models. Heck, if he says AMS is the future, it probably is. Long term, I agree ... it's where we will probably end up 2) The practical issues with AMS Unfortunately, it took us years to get vendors to create good IBIS 2.1 models - and there are a number that haven't figured that out, either. Handing the modeling community a programming language is a non-solution. We need to create the modeling infrastructure that goes with it, both in terms of constructing models (the "standard building blocks" Arpad mentioned) and the processes that extract data the models use (in other words, s2ibis3 for AMS). Requiring model builders to hand craft models isn't going to get us very far - we need the corresponding model development tools for AMS that we had for IBIS. AMS is a programming language. Declaring AMS as the modeling language of choice doesn't automatically get us good models any more than the definition of C++ automatically resulted in superlative graphics programs. C++ may have been a key building block, but there was much, much more to it than that. We need to be realistic about the infrastructure required to put AMS "into production" as a SI technology, and make sure that we can stay afloat from a modeling perspective until we get there. Which brings me to (you knew it was coming) ... 3) IBIS Macromodels I don't see this as a long-term solution - I see it as a bridge technology. I'm not sure why Donald's point of "we do everything with a B-element and macromodeling" didn't resonate more than it did. This isn't Cadence banging on a proprietary drum, at least not in my view - it's saying that this approach has worked for years, and still has some life left in it. I think it's the thing that can buy us time while we figure out what comes next. 4) EDA Vendors and IBIS Support Arpad had a really good point earlier - why are people arguing about this now, instead of when the BIRDs were passed? Personally, I've seen that IBIS support is no longer a competitive issue among EDA tools. There was a time when vendors rushed to support new IBIS standards for fear of losing sales. I don't see that anymore - in fact, I see some vendors that can't articulate which IBIS features their tool does or doesn't support. That tells me vendors don't see IBIS support as an issue, because customers don't see it as an issue. Todd. Todd Westerhoff High Speed Design Group Manager Cisco Systems 1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@cisco.com ph: 978-936-2149 ============================================ ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.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 email a 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 1993 ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.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 email a 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 1993 ----------------------------------------------------------------- |For help or to subscribe/unsubscribe, email majordomo@eda.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 email a 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 Apr 5 08:50:53 2005
This archive was generated by hypermail 2.1.8 : Tue Apr 05 2005 - 08:51:10 PDT