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

  • From: Yafei Bi <yafei_bi@xxxxxxxxx>
  • To: arpad.muranyi@xxxxxxxxx, si-list@xxxxxxxxxxxxx
  • Date: Tue, 22 Mar 2005 23:37:11 -0800 (PST)

Dear gurus,

I have been reading the post and learned a lot as an
IC designer.

I personally generated IBIS models for I/Os designed
somebody else and also designed I/O myself.

My experience is that if the users are concerned
enough about the SSO, they usally ask for Hspice
netlist of the I/O design. Depends on the relationship
and how hard the user push for it, they usally get
what they want. As a two-way street, we also try to
evaluate I/O design in an actual borad/package
environment.

Regarding AMS, I totally agree with Arpad, the AMS
model is just as good as the model writter himself.
It is a powerful tool and should use as cautions.

In the past I worked on a project in which I generated
several behavioral models for Unitrode PWMs in AMS
language. The only information I had for these PWM are
the datasheet from vendor. With AMS, I was able to
generate the models whose performance matches line by
line with the specification in the datasheet through
simulation. As a results, the user paid a good price
for the models. The model also works as expected in a
design supplied by the users.

Now, a questions related to SSO/IBIS, how do you model
the on chip power/gnd bus + on chip decoupling +
PWR/GND ball to I/O ratio(e.g.: every 3 I/O shares a
pair of PWR/GND ball) with IBIS model? 

Thanks

Yafei





--- "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx> wrote:

> Sorry for joining this thread so late, but I was out
> of my office for a
> while.  I would like to add a few my thoughts for
> brain-food.
> 
> I am happy to note that the discussion finally
> concluded that basically
> all models are behavioral, including the SPICE
> transistor or resistor
> models.  Having said that I hope we can also
> conclude that the problems
> we have with IBIS are not because it is behavioral. 
> In my opinion it is
> simply a poorly written specification.  The
> limitations are mostly =
> caused
> by the rigidity of the spec, and the close
> relationship between the
> keywords and their predefined (assumed) meaning.
> 
> Most people don't think about this, but SPICE is
> suffering from the same
> exact problem.  It may be on a different level, but
> the problem is the =
> same.
> This was actually discussed several years ago in an
> IBIS Summit =
> presentation:
> 
>
http://www.eda.org/pub/ibis/summits/sep00/secasiu.zip
> 
> To sum it up, think about the various "level"-s of
> MOSFET (or any other
> element) models.  When a semiconductor company
> invents a new process for
> which the existing models are inadequate, a new set
> of equations and a =
> new
> model "level" needs to be invented.  The
> implementation of this can only
> be done by the SPICE tool vendor, no one else.  The
> users of the SPICE =
> tool
> will have to wait, just like in the case of IBIS. 
> This is where the =
> *-AMS
> languages come to a rescue.
> 
> Another thing that most people don't seem to
> consider is that the =
> equations
> of the SPICE primitives can be, and have already
> been converted to *-AMS =
> in
> several projects.  Therefore an AMS simulator can be
> used the same exact =
> way
> as if it was a SPICE simulator.  But why bother
> going to AMS if we have =
> SPICE?
> 
> Well, the advantage of AMS over SPICE is that we get
> access to the =
> equations.
> We don't have to wait for the tool vendor to
> implement anything for us, =
> we
> can write it any time we want it to.  Also, having
> that access to the =
> equations,
> the model maker can decide what level of abstraction
> they should use for =
> their
> model.  They can choose to do it as we know it from
> SPICE (using circuit =
> elements,
> such as R, L, C, transistor, diode, etc), but they
> could also go to =
> higher or
> lower levels of abstraction.  If they wish, they
> could write equations =
> for
> the electron behavior in the crystal structure with
> all kinds of quantum
> effects, etc., but they could also do as IBIS does
> and write equations =
> for
> larger building blocks, if they like.  IT IS ALL UP
> TO THE MODEL WRITER.
> 
> Another one of the advantages of AMS over SPICE is
> that we can also =
> write
> truly digital equations, and mix them in with analog
> equations.  These =
> can
> simplify and speed up the modeling and simulation of
> logic equations and =
> state
> machines tremendously, compared with their analog
> counterparts.
> 
> I agree, writing AMS equations may not be for
> everyone, but it doesn't =
> have
> to be.  To illustrate this from the SPICE world,
> another example comes =
> to my
> mind.  Think about how many people actually write
> those so-called =
> process files.
> (Remember, a SPICE transistor primitive is useless
> by itself without the
> underlying process parameters).  Well, in my company
> there is a special =
> group
> of a handful of people who does that, while there
> are probably several =
> thousand
> of circuit designers who write schematics.  This
> discussion thread made =
> it seem
> that SPICE is easy because it is so familiar, yet no
> one mentioned that =
> none of
> those thousands of people designing circuits would
> get anywhere without =
> those few
> who provide the most important part of all, the
> process files!  Also, if =
> this
> wasn't such a sensitive subject, I could probably
> tell horror stories =
> about what
> happens when they don't get it right, because no one
> using SPICE knows =
> how to
> fix those parameters...
> 
> I see a similar distribution of work in AMS.  There
> will be a few people =
> who
> will be able to write templates, primitives, and
> there will be lots of =
> people
> who will be using them.
> 
> Arpad Muranyi
> Intel Corporation
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D
>
------------------------------------------------------------------
> 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

Other related posts:

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