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 ============================================ "Always do right. This will gratify some people and astonish the rest." - Mark Twain ----------------------------------------------------------------- |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 Mon Apr 4 13:15:08 2005
This archive was generated by hypermail 2.1.8 : Mon Apr 04 2005 - 13:17:10 PDT