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

  • From: "Donald Telian" <donaldt@xxxxxxxxxxx>
  • To: "Syed Huq" <shuq@xxxxxxxxx>
  • Date: Wed, 16 Mar 2005 10:14:16 -0800

Syed,

Sounds like our definitions of macromodeling are different.  According
to my definition when you put a current source in parallel with a B
element and an RLC circuit to demonstrate IvsT BIRD95, you were
"macromodeling".  My proposal to the IBIS Committee is to allow/enable
clever engineers to invent solutions just as you have done. =20

Call it what you will, but your IvsT implementation is a classic example
of what I'm talking about enabling.  Wouldn't you agree that allowing
SPICE B elements, paramters, and various current sources would permit
others to make and distribute models such as yours *within the spec*?=20

Donald


>-----Original Message-----
>From: Syed Huq [mailto:shuq@xxxxxxxxx]=20
>Sent: Monday, March 14, 2005 6:35 PM
>To: Donald Telian
>Cc: weirsi@xxxxxxxxxx; si-list@xxxxxxxxxxxxx; Michael Mirmak;=20
>Gary Pratt; Chris.Cheng@xxxxxxxxxxxx
>Subject: Re: [SI-LIST] Re: package SSN model accuracy=20
>requirements, nowBehavioral Modeling
>
>Donald,
>
>A correction of your statement below:
>
>>In 1992 Arpad designed the first IBIS implementation using SPICE =20
>>macromodeling and still today Cisco used it to demonstrate=20
>their BIRD =20
>>95/SSN implementation at the Jan05 Summit.
>
>Cisco *did not* use macromodeling to demonstrate BIRD95/SSN as=20
>you have stated. Our data showed comparison of HSPICE(xtor=20
>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,
>>=20
>> Thanks for puzzling over this with us.  As the author of the=20
>> data/proposal you mention below, I'd like to add a couple=20
>more thoughts.
>> http://www.eda.org/pub/ibis/summits/jan05/telian.pdf
>>=20
>> If you look towards the end of the presentation I point out that SI=20
>> engineers have used SPICE effectively for behavioral=20
>modeling for many=20
>> years.  In 1992 Arpad designed the first IBIS implementation using=20
>> SPICE macromodeling and still today Cisco used it to=20
>demonstrate their=20
>> BIRD 95/SSN implementation at the Jan05 Summit.  In the years in=20
>> between Cadence used behavioral SPICE macromodeling to implement not=20
>> only IBIS 3.2/4.0 structures, but also many other complex=20
>devices (see=20
>> presentation).
>>=20
>> The proposal to the IBIS Committee was to enable common=20
>SPICE elements=20
>> as an additional way to do behavioral modeling.  While there is a=20
>> serious chicken and egg problem with AMS, there is much less of a=20
>> problem with behavioral SPICE.  It is more common to SI=20
>engineers, and=20
>> it is here today in many tools.  The problem is that IBIS 4.1 limits=20
>> itself to "Berkeley SPICE" which hasn't been updated since=20
>1993.  Yet=20
>> a couple more elements would make even that fairly=20
>effective.  If you=20
>> think an extension like this would be a good idea, you=20
>should let the=20
>> IBIS Committee know.
>>=20
>> Some view the proposal to augment IBIS' definition of "SPICE" as=20
>> competing with AMS.  I view it as a complementary step towards=20
>> enabling progress with behavioral modeling.  All languages=20
>> (Verilog-AMS, VHDL-AMS, SPICE) have their merits to those who speak=20
>> them, and currently many are more fluent in SPICE.  The IBIS=20
>Committee=20
>> could offer a good service by providing model templates for=20
>structures=20
>> beyond native IBIS syntax in a variety of languages.  It's the=20
>> device's behavior/structure that must be understood and modeled; the=20
>> question of the best language is secondary.  The basic IBIS=20
>2.1 driver=20
>> was an important structure to model, and now there are more.
>>=20
>> Whatever we do with behavioral modeling, it will not likely be a=20
>> complete replacement for layout-derived transistor-based=20
>SPICE models=20
>> anytime soon.  They will not go away.  As such, behavioral and=20
>> transistor model types must co-exist.  And that seems an additional=20
>> reason to enable SPICE-based macromodeling.
>>=20
>> Donald Telian
>>=20
>>=20
>>=20
>> >-----Original Message-----
>> >From: si-list-bounce@xxxxxxxxxxxxx=3D20=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;=3D20=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=20
>way=3D20 to=20
>> >get past this chicken and egg problem.  Widespread Si=3D20 vendor=20
>> >support tends to want to wait for OEM customer pull. =3D20 OEM=20
>> >customers won't pull without Si vendor support, and tools=3D20=20
>> >in-place.  Consequently, OEM customers hesitate to=20
>purchase=3D20 tools=20
>> >for specific capability that doesn't get used.  And tool=3D20 =
vendors=20
>> >sure don't have a monetary incentive to give away new=3D20 =
capability=20
>> >for free.  It seems this places us at something of=3D20 an impasse.
>> >
>> >Just brainstorming a little bit, what it might take is for the=3D20=20
>> >tool vendors to essentially provide both tools and support=20
>to=3D20 the=20
>> >Si industry gratis so that the libraries get built.  With=3D20=20
>> >libraries in place that can be demonstrated provide value,=3D20 OEMs =

>> >would be far more inclined to purchase the tools to use=3D20 AMS. =20
>> >Maybe if the industry could convince the US DoD that AMS=3D20 is=20
>> >necessary for advanced military H/W, we could plow some=3D20 gov't=20
>> >dollars into this effort to prime the pump.  If funds=3D20 were=20
>> >provided to Si vendors with the specific requirement=20
>that=3D20 silicon=20
>> >has to be delivered with AMS models that match SPICE=3D20=20
>accuracy, we=20
>> >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=3D20
>> >presentation=3D20
>> >>site.
>> >>
>> >>While I cannot comment on specific vendors' tools, I do have a=20
>> >>few=3D20 general observations about IBIS and SPICE in the industry.
>> >>
>> >>Discussions about SPICE versus traditional IBIS versus IBIS with=20
>> >>AMS=3D20 may be missing a larger point: as is apparent from this=20
>> >>thread alone,=3D20 not everyone is convinced that behavioral=20
>modeling=20
>> >>can be more=3D20 compelling than transistor-level modeling for=20
>> >>certain=3D20
>> >applications.  We=3D20
>> >>-- EDA vendors, system designers and silicon vendors, as you=3D20
>> >point out=3D20
>> >>-- need to review and demonstrate publicly that proper=20
>behavioral=3D20=20
>> >>modeling *per
>> >>se* can have significant advantages over transistor-level=20
>> >>solutions,=3D20 particularly proprietary ones.
>> >>
>> >>I personally believe that behavioral modeling can provide the=3D20
>> >speed and=3D20
>> >>accuracy required by the industry for large system simulations. =20
>> >>I=3D20 further believe that behavioral modeling, if=20
>approached with an=20
>> >>eye=3D20 toward flexibility and standardization, can ease some of=20
>> >>the=3D20 information exchange, feature support and correlation=20
>> >>issues=3D20
>> >mentioned earlier.
>> >>
>> >>Will behavioral modeling specification extensions and improvements=20
>> >>be=3D20 needed as designs advance?  Certainly.  However, as an=3D20
>> >example, I would=3D20
>> >>offer that BSIM is not exactly static; it has been updated=3D20
>> >and changed=3D20
>> >>regularly, as effects considered unimportant become more prominent.
>> >>Further, BSIM and proprietary SPICEs are themselves behavioral=20
>> >>model=3D20 sets for transistor devices -- behavioral modeling at a=20
>> >>lower=3D20
>> >level of=3D20
>> >>abstraction, in other words.  Some semiconductor vendors even=3D20
>> >use their=3D20
>> >>own internal transistor model equation sets for their own=3D20
>> >needs, beyond=3D20
>> >>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
>> >>--=3D20 low-level design and layout teams tend to use=20
>> >>SPICE-oriented=3D20
>> >tools, and=3D20
>> >>netlist extraction/encryption takes less effort (and know-how)=20
>> >>than=3D20 creating a correlated behavioral model.  Again, we need=20
>> >>to=3D20
>> >demonstrate=3D20
>> >>that the advantages of more abstract behavioral modeling=20
>> >>approaches=3D20 justify the time needed to create and=20
>correlate those=20
>> >>models.  Once=3D20 that is demonstrated, the more specific choices=20
>> >>regarding behavioral=3D20 modeling styles and features=20
>become easier to make.
>> >>
>> >>The IBIS 4.1 specification supports the VHDL-AMS and=20
>Verilog-AMS=3D20=20
>> >>languages plus Berkeley SPICE.  The IBIS community is now=3D20
>> >hard at work=3D20
>> >>developing models and modeling techniques using these languages,=20
>> >>plus=3D20 analyzing other behavioral modeling proposals to=20
>address the=20
>> >>issues=3D20 above.  We are trying to "make the case" for=20
>behavioral=3D20
>> >modeling and to=3D20
>> >>offer accurate, standard solutions in the near term.  Your input=20
>> >>is=3D20 welcome, particularly on how best we can make that case =
to=3D20
>> >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=3D20=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;=3D20=20
>> >>si-list@xxxxxxxxxxxxx
>> >>Subject: [SI-LIST] Re: package SSN model accuracy requirements
>> >>
>> >>Gary, I was looking at the IBIS Summit information, and a=3D20
>> >couple of the=3D20
>> >>presentations make it apparent that compliance and usage=3D20
>> >beyond 2.0 is=3D20
>> >>poor.  Cadence in particular did a survey that showed that SPICE=20
>> >>is=3D20 taking a lot of ground from IBIS because the IBIS world has =

>> >>not=3D20 provided the models needed for OEMs to get their=20
>jobs done. =20
>> >>I guess=3D20 this all sounds great if you're Synopsys.
>> >>
>> >>I think that if this situation is to reverse, it is going to=20
>> >>require=3D20 some real courage and $$$ from:  tool vendors, silicon =

>> >>vendors, and=3D20 OEMs to get over the hump and make IBIS w/AMS=20
>> >>something that reverses=3D20 the trend towards SPICE.  How=20
>will Mentor=20
>> >>and Cadence=3D20
>> >convince Synopsys=3D20
>> >>to play when the current trend favors Synopsys?  Who is=20
>going to=3D20=20
>> >>champion this at the IC vendors when their customers almost=3D20
>> >universally=3D20
>> >>have H-SPICE capability and not a spiffy 4.1+ compliant IBIS=3D20
>> >tool with=3D20
>> >>engineers trained and willing to use it?
>> >>
>> >>Don't get me wrong, I like the reported results of AMS and=3D20
>> >the benefits=3D20
>> >>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=20
>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:    =3D20
>> >            //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
>> > =3D20
>> >
>> >
>> >
>> ------------------------------------------------------------------
>> To unsubscribe from si-list:
>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>>=20
>> or to administer your membership from a web page, go to:
>> //www.freelists.org/webpage/si-list
>>=20
>> For help:
>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>=20
>> List FAQ wiki page is located at:
>>                 http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>>=20
>> List technical documents are available at:
>>                 http://www.si-list.org
>>=20
>> 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

Other related posts:

  1. Home
  2. si-list
  3. Archive
  4. 03-2005