[SI-LIST] Re: package SSN model accuracy requirements, now Behavioral Modeling

From: steve weir <weirsi@xxxxxxxxxx>
To: "Donald Telian" <donaldt@xxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
Date: Mon, 14 Mar 2005 18:49:36 -0800
Don, it is my pleasure.  Yes, I did notice that in your presentation, and 
agree that ultimately all of our models are behavioral.  Otherwise they are 
called prototypes.  I think a more precise distinction in the discussion 
has been between the use of transistor-based SPICE behavioral models, 
versus macro-behavioral models.

For the immediate future the market seems to really be struggling to find a 
viable answer.  The notion of using a newer commercial SPICE variant versus 
Berkeley 3 as the basis for IBIS extensions is eminently reasonable to 
me.  This seems an issue of political will and fortitude amongst the EDA 
vendors.  Amongst the EDA vendors, who will be willing to let it be "the 
other guy's SPICE"?  What would the prevailing dialect owner be willing to 
provide to their competitors, and on what terms for the good of the 
industry and ultimately their own growth?

Personally, I do not have a problem with what I agree is IBIS + SPICE being 
a competitor to AMS. I think that is both perfectly fine and natural in 
eras of transition.  The legacy methods get shored-up, while the new 
methods get developed and propagated.   Assuming as I do that AMS will 
eventually dominate, as you, I expect this to be a very slow process.  The 
risk that I see particularly in the US is that inertia will allow foreign 
competitors to overtake us in this area.

Regards,


Steve.


At 06:01 PM 3/14/2005 -0800, Donald Telian wrote:
>Steve,
>
>Thanks for puzzling over this with us.  As the author of the
>data/proposal you mention below, I'd like to add a couple more thoughts.
>http://www.eda.org/pub/ibis/summits/jan05/telian.pdf
>
>If you look towards the end of the presentation I point out that SI
>engineers have used SPICE effectively for behavioral modeling for many
>years.  In 1992 Arpad designed the first IBIS implementation using SPICE
>macromodeling and still today Cisco used it to demonstrate their BIRD
>95/SSN implementation at the Jan05 Summit.  In the years in between
>Cadence used behavioral SPICE macromodeling to implement not only IBIS
>3.2/4.0 structures, but also many other complex devices (see
>presentation).
>
>The proposal to the IBIS Committee was to enable common SPICE elements
>as an additional way to do behavioral modeling.  While there is a
>serious chicken and egg problem with AMS, there is much less of a
>problem with behavioral SPICE.  It is more common to SI engineers, and
>it is here today in many tools.  The problem is that IBIS 4.1 limits
>itself to "Berkeley SPICE" which hasn't been updated since 1993.  Yet a
>couple more elements would make even that fairly effective.  If you
>think an extension like this would be a good idea, you should let the
>IBIS Committee know.
>
>Some view the proposal to augment IBIS' definition of "SPICE" as
>competing with AMS.  I view it as a complementary step towards enabling
>progress with behavioral modeling.  All languages (Verilog-AMS,
>VHDL-AMS, SPICE) have their merits to those who speak them, and
>currently many are more fluent in SPICE.  The IBIS Committee could offer
>a good service by providing model templates for structures beyond native
>IBIS syntax in a variety of languages.  It's the device's
>behavior/structure that must be understood and modeled; the question of
>the best language is secondary.  The basic IBIS 2.1 driver was an
>important structure to model, and now there are more.
>
>Whatever we do with behavioral modeling, it will not likely be a
>complete replacement for layout-derived transistor-based SPICE models
>anytime soon.  They will not go away.  As such, behavioral and
>transistor model types must co-exist.  And that seems an additional
>reason to enable SPICE-based macromodeling.
>
>Donald Telian
>
>
>
> >-----Original Message-----
> >From: si-list-bounce@xxxxxxxxxxxxx
> >[mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of steve weir
> >Sent: Friday, March 11, 2005 5:56 PM
> >To: Mirmak, Michael; gary_pratt@xxxxxxxxxxx;
> >Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
> >Subject: [SI-LIST] Re: package SSN model accuracy requirements
> >
> >Michael, you are very welcome.  I just don't know any easy way
> >to get past this chicken and egg problem.  Widespread Si
> >vendor support tends to want to wait for OEM customer pull.
> >OEM customers won't pull without Si vendor support, and tools
> >in-place.  Consequently, OEM customers hesitate to purchase
> >tools for specific capability that doesn't get used.  And tool
> >vendors sure don't have a monetary incentive to give away new
> >capability for free.  It seems this places us at something of
> >an impasse.
> >
> >Just brainstorming a little bit, what it might take is for the
> >tool vendors to essentially provide both tools and support to
> >the Si industry gratis so that the libraries get built.  With
> >libraries in place that can be demonstrated provide value,
> >OEMs would be far more inclined to purchase the tools to use
> >AMS.  Maybe if the industry could convince the US DoD that AMS
> >is necessary for advanced military H/W, we could plow some
> >gov't dollars into this effort to prime the pump.  If funds
> >were provided to Si vendors with the specific requirement that
> >silicon has to be delivered with AMS models that match SPICE
> >accuracy, we might get somewhere.
> >
> >Regards,
> >
> >Steve.
> >
> >At 05:42 PM 3/11/2005 -0800, Mirmak, Michael wrote:
> >>Steve et al,
> >>
> >>Thanks for your comments and for visiting the IBIS Summit
> >presentation
> >>site.
> >>
> >>While I cannot comment on specific vendors' tools, I do have a few
> >>general observations about IBIS and SPICE in the industry.
> >>
> >>Discussions about SPICE versus traditional IBIS versus IBIS with AMS
> >>may be missing a larger point: as is apparent from this thread alone,
> >>not everyone is convinced that behavioral modeling can be more
> >>compelling than transistor-level modeling for certain
> >applications.  We
> >>-- EDA vendors, system designers and silicon vendors, as you
> >point out
> >>-- need to review and demonstrate publicly that proper behavioral
> >>modeling *per
> >>se* can have significant advantages over transistor-level solutions,
> >>particularly proprietary ones.
> >>
> >>I personally believe that behavioral modeling can provide the
> >speed and
> >>accuracy required by the industry for large system simulations.  I
> >>further believe that behavioral modeling, if approached with an eye
> >>toward flexibility and standardization, can ease some of the
> >>information exchange, feature support and correlation issues
> >mentioned earlier.
> >>
> >>Will behavioral modeling specification extensions and improvements be
> >>needed as designs advance?  Certainly.  However, as an
> >example, I would
> >>offer that BSIM is not exactly static; it has been updated
> >and changed
> >>regularly, as effects considered unimportant become more prominent.
> >>Further, BSIM and proprietary SPICEs are themselves behavioral model
> >>sets for transistor devices -- behavioral modeling at a lower
> >level of
> >>abstraction, in other words.  Some semiconductor vendors even
> >use their
> >>own internal transistor model equation sets for their own
> >needs, beyond
> >>what commercial tools or BSIM can offer.
> >>
> >>Is there a barrier to switching to abstract behavioral approaches?
> >>Definitely.  In many cases, the barrier is as Chris pointed out --
> >>low-level design and layout teams tend to use SPICE-oriented
> >tools, and
> >>netlist extraction/encryption takes less effort (and know-how) than
> >>creating a correlated behavioral model.  Again, we need to
> >demonstrate
> >>that the advantages of more abstract behavioral modeling approaches
> >>justify the time needed to create and correlate those models.  Once
> >>that is demonstrated, the more specific choices regarding behavioral
> >>modeling styles and features become easier to make.
> >>
> >>The IBIS 4.1 specification supports the VHDL-AMS and Verilog-AMS
> >>languages plus Berkeley SPICE.  The IBIS community is now
> >hard at work
> >>developing models and modeling techniques using these languages, plus
> >>analyzing other behavioral modeling proposals to address the issues
> >>above.  We are trying to "make the case" for behavioral
> >modeling and to
> >>offer accurate, standard solutions in the near term.  Your input is
> >>welcome, particularly on how best we can make that case to
> >the industry.
> >>We can use all the help we can get in this. :)
> >>
> >>- Michael Mirmak
> >>   Intel Corp.
> >>   Chair, EIA IBIS Open Forum
> >>
> >>   http://www.eigroup.org/ibis/
> >>   http://www.eda.org/ibis/
> >>
> >>
> >>-----Original Message-----
> >>From: si-list-bounce@xxxxxxxxxxxxx
> >>[mailto:si-list-bounce@xxxxxxxxxxxxx]
> >>On Behalf Of steve weir
> >>Sent: Friday, March 11, 2005 1:35 PM
> >>To: gary_pratt@xxxxxxxxxxx; Chris.Cheng@xxxxxxxxxxxx;
> >>si-list@xxxxxxxxxxxxx
> >>Subject: [SI-LIST] Re: package SSN model accuracy requirements
> >>
> >>Gary, I was looking at the IBIS Summit information, and a
> >couple of the
> >>presentations make it apparent that compliance and usage
> >beyond 2.0 is
> >>poor.  Cadence in particular did a survey that showed that SPICE is
> >>taking a lot of ground from IBIS because the IBIS world has not
> >>provided the models needed for OEMs to get their jobs done.  I guess
> >>this all sounds great if you're Synopsys.
> >>
> >>I think that if this situation is to reverse, it is going to require
> >>some real courage and $$$ from:  tool vendors, silicon vendors, and
> >>OEMs to get over the hump and make IBIS w/AMS something that reverses
> >>the trend towards SPICE.  How will Mentor and Cadence
> >convince Synopsys
> >>to play when the current trend favors Synopsys?  Who is going to
> >>champion this at the IC vendors when their customers almost
> >universally
> >>have H-SPICE capability and not a spiffy 4.1+ compliant IBIS
> >tool with
> >>engineers trained and willing to use it?
> >>
> >>Don't get me wrong, I like the reported results of AMS and
> >the benefits
> >>it brings.  I just see a major set of market hurdles.
> >>
> >>Regards,
> >>
> >>
> >>Steve.
> >
> >The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
> >Please update your address book with weirsi@xxxxxxxxxx
> >
> >
> >------------------------------------------------------------------
> >To unsubscribe from si-list:
> >si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >
> >or to administer your membership from a web page, go to:
> >//www.freelists.org/webpage/si-list
> >
> >For help:
> >si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> >List FAQ wiki page is located at:
> >                http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> >List technical documents are available at:
> >                http://www.si-list.org
> >
> >List archives are viewable at:
> >               //www.freelists.org/archives/si-list
> >or at our remote archives:
> >               http://groups.yahoo.com/group/si-list/messages
> >Old (prior to June 6, 2001) list archives are viewable at:
> >               http://www.qsl.net/wb6tpu
> >
> >
> >
> >

The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
Please update your address book with weirsi@xxxxxxxxxx


------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

List archives are viewable at:     
                //www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu
[SI-LIST] Re: package SSN model accuracy requirements, now Behavioral Modeling

Other related posts:
