[ibis-macro] Request for Participation in IBIS Macro Modeling Working Group

  • From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
  • To: <ian_dodd@xxxxxxxxxxx>
  • Date: Thu, 28 Jul 2005 14:12:58 -0700

Dear Ian,

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

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:


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


IBIS Macro Modeling Committee Members

Other related posts: