Dear Geoffrey, Thank you for your company's continued commitment to IBIS model support. By supporting IBIS, you provide your users with access to a large number of quality, simulator independent models for SI analysis. You are most likely aware of the fact that IBIS is having a hard time keeping up with advanced technology modeling. Even though the IBIS specification has been extended numerous times with new keywords, the time lag between the emergence of new I/O buffer technologies, their support in the IBIS specification and support in IBIS simulators has continued to grow. As the operating frequencies of I/O buffers increase, many model makers and/or users leave IBIS behind in favor of SPICE models. Since most semiconductor vendors support their models with a single vendor's version of SPICE, this trend brings the industry back towards a single EDA vendor solution, which is what IBIS was designed to prevent. However, behavioral modeling still has significant advantages. The three tenets of IBIS have always been: 1. Simulator independent modeling standard 2. IP protection (hide transistor-level netlist and manufacturing process information) 3. Fast simulations with accuracy close to SPICE The latest language extensions in IBIS 4.1 gave IBIS a much desired flexibility and have opened the door to practically unlimited behavioral and structural modeling capabilities. The problem is that the *-AMS languages are slow in making their way into SI tools and the SI community. However, the burning need is here today to model and simulate advanced buffers. If we don't do anything about this situation, we may end up with nothing but SPICE models. If we just continue to add new keywords to IBIS, we will not be able to catch up with the ever faster evolution of complicated buffers. Clearly the future is in the adoption of flexible modeling languages, such as the ones accepted by IBIS 4.1. But how can we bridge the gap that exists today between these languages and the need for modeling advanced buffers? Many tools today allow a modeling technique which we will refer to as macro modeling. With this technique, a complex buffer may be constructed from one or more IBIS models along with some additional controlled voltage or current sources, delays, etc... This technique is gaining popularity because it helps to overcome the well known IBIS limitations. However, since macro modeling is currently done differently in each simulator, this is again a tool dependent solution. On the other hand, due to its capabilities and immediate availability, macro modeling would be useful to the industry if this capability was available in a standard, tool independent form. It turns out that AMS supports a variety of modeling styles - a buffer can be described purely behaviorally, but also in a structural manner with a circuit netlist and semiconductor process description. In addition, the netlist portion of the *-AMS languages is very similar to the familiar SPICE netlists, and therefore it can be used very well to describe the macro models in a familiar style. We believe that a library of standard *-AMS "building blocks" can be defined and developed in *-AMS to support behavioral macro modeling. This will also make it easier for model developers to transition into developing *-AMS based models. These "building blocks" would include items like the IBIS B-element model, controlled voltage and current sources, and functions similar to features found in many SPICE simulators. However, only a few EDA tools support *-AMS modeling today, raising the question of whether the new models could be supported by simulators without *-AMS support. We believe that it is not a difficult task to perform an automated netlist syntax translation and element mapping if we have a standard building block library containing a set of functions commonly found in SPICE simulators. Such a standard library would be useful for two reasons. First, this would give model developers a set of functions they are already familiar with. We believe this will simplify the task of utilizing the *-AMS languages, since model developers can use *-AMS purely as a structural modeling language, calling out predefined elements, interconnecting them and passing the parameters (data) they need. The second potential benefit of the building block library is realized by EDA vendors whose tools don't yet support *-AMS. By keeping the building block library small, well-defined and simple, we hope to come up with a set of functions that can be mapped into EDA tools that don't have native support for *-AMS. An EDA tool without native *-AMS support could "map" the building blocks into elements supported in the simulator and use the instantiations and connectivity from the *-AMS model to reproduce the model's overall structure. The key to success here is a well defined, controlled building block library than can be successfully mapped into different EDA tools. That's where we need your help, and why we're asking for your company's participation in the "IBIS 2010" working group. This group has been meeting for several months and currently includes representation from Intel, Cisco, Cadence, Teraspeed Consulting and SiSoft. We have developed the ideas outlined here and presented them at the recent IBIS Summit in Anaheim, CA: http://www.eda.org/pub/ibis/summits/jun05/muranyi.pdf Participants in this work would be divided into two categories. We expect only a few participants will be needed to actively develop and test the *-AMS libraries. The remaining participants will help us to define and test an AMS building block library for SI models. Specifically, we're looking for help in determining what building blocks the library should contain, along with callout syntax and required data parameters. We're also looking for your company to test the building block library as it gets developed, to ensure that you can use the building blocks directly in your AMS implementation or parse the resulting models into elements directly support by your simulator. The goal of this effort is to have a prototype library defined and implemented to present at the IBIS Summit this September coinciding with DesignCon East. If you're not the right contact at your company to make a decision to get involved with this effort, we would greatly appreciate your help in identifying the right contact. Please pass this request on to the appropriate people and/or provide us with the appropriate contact information. We're confident that, with your help, we can create the next generation of IBIS models that will take the original IBIS goals of simulator independence, IP protection and accuracy/efficiency forward. Sincerely, IBIS Macro Modeling Committee Members ======================================================================