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

From: "C. Kumar" <kumarchi@xxxxxxxxx>
To: si-list@xxxxxxxxxxxxx
Date: Wed, 16 Mar 2005 06:13:09 -0800 (PST)
I have been following these discussions with great interest. These are my few 
cents.

 

   First some terminology. First I will like to use the term ?post layout 
circuit(model)? instead of ?spice mode /spice transistor model?. The post 
layout model is vastly unstructured and generally huge compared to the 
schematic level models the circuit designer started his work on.  The principle 
consumers of this post layout model is mainly system designers. The unwieldy 
size of these circuits may in future, if not already,  limit what is included 
in them. For example complex equalization structures may not be included in 
these models at all for practical reasons.

 

   Is it possible to effect ?model reduction?? Is it possible to maintain the 
accuracy  at the same time? I believe it is possible to derive an efficient and 
accurate macro model IF the circuit architecture is known a priori. In the 
ideal case the macro modeling effort will start early much before the ic layout 
work. The new high speed devices are increasingly using variations of known 
circuit architectures. This gives, in my view, a window of opportunity to 
standardize on these ?structural macro models?.

 

   ?Standardizing? means coming up with a schematic of the macromodel along 
with ?golden? waveforms and other data for a given set of macromodel 
parameters. In this way various flavors of the implementations can be compared 
and measured against the same standard. 

 

   I fail to see how just providing place holder for some particular flavors of 
implementation like AMS, Berkeley spice etc qualify as a standard. There will 
be no basis for comparing any of these models. This is akin putting the cart 
before the horse. Rather the standards body should be prioritizing and focusing 
on the selection of appropriate circuit architectures and macromodels to 
represent them. Macromodels are implementation independent and can be described 
in plain circuit diagrams. These standards can even and should be published in 
plain English in the form of data sheets. 


Donald Telian <donaldt@xxxxxxxxxxx> 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




                
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - Find what you need with new enhanced search. Learn more.

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