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

From: Syed Huq <shuq@xxxxxxxxx>
To: Donald Telian <donaldt@xxxxxxxxxxx>
Date: Mon, 14 Mar 2005 18:34:39 -0800
Donald,

A correction of your statement below:

>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.

Cisco *did not* use macromodeling to demonstrate BIRD95/SSN as you have
stated. Our data showed comparison of HSPICE(xtor level), IBISv3.2 and
the new IvsT sims(BIRD95).

- Syed
Cisco Systems, Inc

On Mon, 2005-03-14 at 18:01, 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=20
> >[mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of steve weir
> >Sent: Friday, March 11, 2005 5:56 PM
> >To: Mirmak, Michael; gary_pratt@xxxxxxxxxxx;=20
> >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=20
> >to get past this chicken and egg problem.  Widespread Si=20
> >vendor support tends to want to wait for OEM customer pull. =20
> >OEM customers won't pull without Si vendor support, and tools=20
> >in-place.  Consequently, OEM customers hesitate to purchase=20
> >tools for specific capability that doesn't get used.  And tool=20
> >vendors sure don't have a monetary incentive to give away new=20
> >capability for free.  It seems this places us at something of=20
> >an impasse.
> >
> >Just brainstorming a little bit, what it might take is for the=20
> >tool vendors to essentially provide both tools and support to=20
> >the Si industry gratis so that the libraries get built.  With=20
> >libraries in place that can be demonstrated provide value,=20
> >OEMs would be far more inclined to purchase the tools to use=20
> >AMS.  Maybe if the industry could convince the US DoD that AMS=20
> >is necessary for advanced military H/W, we could plow some=20
> >gov't dollars into this effort to prime the pump.  If funds=20
> >were provided to Si vendors with the specific requirement that=20
> >silicon has to be delivered with AMS models that match SPICE=20
> >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=20
> >presentation=20
> >>site.
> >>
> >>While I cannot comment on specific vendors' tools, I do have a few=20
> >>general observations about IBIS and SPICE in the industry.
> >>
> >>Discussions about SPICE versus traditional IBIS versus IBIS with AMS=20
> >>may be missing a larger point: as is apparent from this thread alone,=20
> >>not everyone is convinced that behavioral modeling can be more=20
> >>compelling than transistor-level modeling for certain=20
> >applications.  We=20
> >>-- EDA vendors, system designers and silicon vendors, as you=20
> >point out=20
> >>-- need to review and demonstrate publicly that proper behavioral=20
> >>modeling *per
> >>se* can have significant advantages over transistor-level solutions,=20
> >>particularly proprietary ones.
> >>
> >>I personally believe that behavioral modeling can provide the=20
> >speed and=20
> >>accuracy required by the industry for large system simulations.  I=20
> >>further believe that behavioral modeling, if approached with an eye=20
> >>toward flexibility and standardization, can ease some of the=20
> >>information exchange, feature support and correlation issues=20
> >mentioned earlier.
> >>
> >>Will behavioral modeling specification extensions and improvements be=20
> >>needed as designs advance?  Certainly.  However, as an=20
> >example, I would=20
> >>offer that BSIM is not exactly static; it has been updated=20
> >and changed=20
> >>regularly, as effects considered unimportant become more prominent.
> >>Further, BSIM and proprietary SPICEs are themselves behavioral model=20
> >>sets for transistor devices -- behavioral modeling at a lower=20
> >level of=20
> >>abstraction, in other words.  Some semiconductor vendors even=20
> >use their=20
> >>own internal transistor model equation sets for their own=20
> >needs, beyond=20
> >>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 --=20
> >>low-level design and layout teams tend to use SPICE-oriented=20
> >tools, and=20
> >>netlist extraction/encryption takes less effort (and know-how) than=20
> >>creating a correlated behavioral model.  Again, we need to=20
> >demonstrate=20
> >>that the advantages of more abstract behavioral modeling approaches=20
> >>justify the time needed to create and correlate those models.  Once=20
> >>that is demonstrated, the more specific choices regarding behavioral=20
> >>modeling styles and features become easier to make.
> >>
> >>The IBIS 4.1 specification supports the VHDL-AMS and Verilog-AMS=20
> >>languages plus Berkeley SPICE.  The IBIS community is now=20
> >hard at work=20
> >>developing models and modeling techniques using these languages, plus=20
> >>analyzing other behavioral modeling proposals to address the issues=20
> >>above.  We are trying to "make the case" for behavioral=20
> >modeling and to=20
> >>offer accurate, standard solutions in the near term.  Your input is=20
> >>welcome, particularly on how best we can make that case to=20
> >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=20
> >>[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;=20
> >>si-list@xxxxxxxxxxxxx
> >>Subject: [SI-LIST] Re: package SSN model accuracy requirements
> >>
> >>Gary, I was looking at the IBIS Summit information, and a=20
> >couple of the=20
> >>presentations make it apparent that compliance and usage=20
> >beyond 2.0 is=20
> >>poor.  Cadence in particular did a survey that showed that SPICE is=20
> >>taking a lot of ground from IBIS because the IBIS world has not=20
> >>provided the models needed for OEMs to get their jobs done.  I guess=20
> >>this all sounds great if you're Synopsys.
> >>
> >>I think that if this situation is to reverse, it is going to require=20
> >>some real courage and $$$ from:  tool vendors, silicon vendors, and=20
> >>OEMs to get over the hump and make IBIS w/AMS something that reverses=20
> >>the trend towards SPICE.  How will Mentor and Cadence=20
> >convince Synopsys=20
> >>to play when the current trend favors Synopsys?  Who is going to=20
> >>champion this at the IC vendors when their customers almost=20
> >universally=20
> >>have H-SPICE capability and not a spiffy 4.1+ compliant IBIS=20
> >tool with=20
> >>engineers trained and willing to use it?
> >>
> >>Don't get me wrong, I like the reported results of AMS and=20
> >the benefits=20
> >>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:    =20
> >             //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
> > =20
> >
> >
> >
> ------------------------------------------------------------------
> 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
>   
------------------------------------------------------------------
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
References:
- [SI-LIST] Re: package SSN model accuracy requirements, now Behavioral Modeling
  - From: Donald Telian
[SI-LIST] Re: package SSN model accuracy requirements, now Behavioral Modeling

Other related posts:
