[SI-LIST] Re: package SSN model accuracy requirements

Yafei, this is the chicken and egg problem with promoting a new standard, 
no matter how good it is, or can be.  In order to get end users to pay for 
the tools, ( capital and labor ) they need to get models from their IC 
vendors that use them.  But the IC vendors are unlikely to add cost and 
time to their process to provide those models unless there is a substantial 
OEM user base demanding those models.  Now, maybe if the tools could 
guarantee that given a good SPICE netlist that a useful AMS netlist would 
be automatically generated that was no slower, and sufficiently accurate, 
then we might be able to overcome the resistance at the IC vendor 
side.  But are the tool vendors willing to make such an investment on their 
own?

Regards,


Steve.
At 03:27 PM 3/24/2005 -0800, Yafei Bi wrote:
>Steve,
>
>NOW I understand the problem of AMS acceptance: board
>designer doesn't have access to the simulator which
>has AMS capability. Tools used by IC designers do.
>
>The AMS capability is available for IC Design Tools
>from Cadance and Mentor for some time now.
>
>IC designers have been using it for PLL locking
>simulation or other timing consuming simulation task.
>There are many success stories in these regard to
>discuss accuracy of AMS etc.
>
>Please tell me as a board designer, which simulator
>has the capability of accepting AMS model?
>
>As for AMS language, here is an example of your own
>resistor model, this is all it takes to have your own
>model:
>
>===========================
>module resistor (a,b);
>inout a, b;
>electrical a,b;
>parameter resistance;
>
>analog begin
>I(a,b) <+ V(a,b)/resistance
>end
>endmodule
>==========================
>
>You can even instantiate Spice primitive inside the
>module to creat your own "macormodel"
>
>Happy Modeling
>
>Yafei
>--- steve weir <weirsi@xxxxxxxxxx> wrote:
>
> > Arpad, personally I really like the possibilities
> > that AMS offer.  I am
> > very concerned on how as a community we turn
> > potential into reality.  Our
> > industry is littered with the bones of different
> > languages and methods that
> > were excellent concepts but failed in the market,
> > while technically lesser
> > solutions prevailed.
> >
> > If we poll and find out that AMS is sorely lacking
> > in the support that it
> > needs to succeed, then I think there are only three
> > viable courses of action:
> >
> > 1) "Educate", ( some might say lobby ) to get
> > sufficient market support to
> > make this direction viable
> > 2) Force by edict such as gov't.  Generally that
> > kind of thing is a bad idea.
> > 3) Abandon for a path that can succeed in the
> > market.
> >
> > Regards,
> >
> >
> > Steve.
> > At 02:59 PM 3/24/2005 -0800, Muranyi, Arpad wrote:
> > >Steve,
> > >
> > >Thank you for your excellent suggestion.  I agree
> > with them completely.
> > >
> > >I hope that I don't come across as being blindly
> > biased towards AMS.
> > >What I write is because of the merits and
> > capabilities of these
> > >languages and the kinds of things I would like to
> > be able to write
> > >models for.
> > >
> > >However, if and when we do these polls we need to
> > be careful about
> > >how we do it!  If you ask someone the question
> > which one they would
> > >prefer, SPICE or AMS, they better know the
> > capabilities and/or
> > >limitations of both.  Otherwise they may end up
> > choosing the one
> > >they know, and not the one that is better than the
> > other...  Of
> > >course, a definition for the word better may also
> > be useful when
> > >trying to make such decisions.  Something that is
> > better for me
> > >may not be good for you.  I may like the freedom in
> > AMS because
> > >it has a programming language style, others may
> > like canned solutions.
> > >Who will decide what is good for the industry in
> > general?
> > >
> > >Arpad
> >
> >-----------------------------------------------------------------------
> > >
> > >-----Original Message-----
> > >From: steve weir [mailto:weirsi@xxxxxxxxxx]
> > >Sent: Thursday, March 24, 2005 2:42 PM
> > >To: Muranyi, Arpad; Chris.Cheng@xxxxxxxxxxxx;
> > si-list@xxxxxxxxxxxxx
> > >Subject: Re: [SI-LIST] Re: package SSN model
> > accuracy requirements
> > >
> > >Arpad, I think a very salient point from Chris is
> > that for all the reasons
> > >you state including limited volunteer resources,
> > that it has been a
> > >struggle to get IBIS to be able to provide needed
> > answers in a number of
> > >important and growing circumstances.  Cadence's
> > IBIS Summit presentation
> > >showing the intrusion of SPICE makes this very
> > clear.
> > >
> > >While it may be instructive on how we have gotten
> > into the situation we
> > >have today, I think it could be very valuable for
> > all of us as a community
> > >to attempt to take as much as a dispassionate, and
> > nonparochial  evaluation
> > >of where we are, and what will make the best use of
> > our collective efforts
> > >moving forward.  I suggest that perhaps what we
> > want to do is poll the
> > >community on the basis of vision, and willingness
> > to commit dollar and
> > >human resources over the next one to three years:
> > >
> > >1) Encrypted SPICE - Portability, security,
> > "speed", sometimes convergence,
> > >and labelling conventions seem to be the awkward
> > points.
> > >2) IBIS evolution - Can IBIS make up for lost
> > ground, and keep from losing
> > >it again?  Is the evolution of IBIS4.1 going to
> > become a labelling wrapper
> > >for SPICE models?
> > >3) AMS - If this is going to fly, how do we
> > propagate en-masse into the
> > >community?  Can we afford to try and propagate both
> > VHDL and Verilog
> > >AMS'?  If not, how do we vote out the loser before
> > monstrous investment is
> > >lost?
> > >
> > >Regards,
> > >
> > >
> > >Steve.
> > >At 02:19 PM 3/24/2005 -0800, Muranyi, Arpad wrote:
> > > >Chris,
> > > >
> > > >Here are my responses.
> > > >
> > > >When we started IBIS, our main goals were not SSO
> > simulations, at least
> > > >not the way it is done today.  That's why we put
> > only a partial and
> > > >crude solution for it into the IBIS specification
> > in the form of the
> > > >[Pin Mapping] keyword.  It did provide some
> > capability for SSO, exactly
> > > >with the same thinking you are saying: "at least
> > give you a chance to
> > > >predict the problem".  Your assessment that IBIS
> > can't do it at all is
> > > >plain wrong.
> > > >
> > > >The thinking in those days was that if it becomes
> > necessary to do
> > > >something better, we will add it to the spec.
> > This is actually
> > > >happening right now in the form of BIRD95.
> > > >
> > > >There may be many reasons it took this long to
> > get this far.  One
> > > >may be that instead of doing something about it,
> > people just kept
> > > >complaining about it.  Another could be that none
> > of us in the IBIS
> > > >Open forum are "professional standards
> > attendees", we all do this
> > > >above and beyond our normal everyday work on a
> > volunteer bases,
> > > >which leaves little time for making improvements
> > on the specification.
> > > >
> > > >The same goes for the receiver modeling problem.
> > When IBIS was started,
> > > >there was no need for doing that, so we didn't
> > put it in the spec.  In
> > > >those days most everything was measured at the
> > pin of the device.  Later
> > > >we started to move the measurement point to the
> > inside of the package,
> > > >the die pad.  This was still doable with IBIS.
> > Timing measurements at
> > > >the output of the receiver are not widely done in
> > the SI world yet.
> > > >Since IBIS is mostly demand driven, this hasn't
> > been addressed yet
> > > >in the spec.  However, with the *-AMS
> > capabilities we are not going to
> > > >need to change the spec any more if it becomes
> > necessary to model the
> > > >receiver.  As I stated it before, in *-AMS you
> > can model things any
> > > >whichever way you want to.  You can make an exact
> > SPICE equivalent if
> > > >you like, or you can write a behavioral block if
> > that is your choice.
> > > >
> > > >Regarding your original question, you have
> > already gotten two responses,
> > > >so I will not go into that any further.
> > > >
> > > >Regarding the rest of your questions:
> > > >
> > > >a)  I don't want to go into encryption, because
> > that is a separate
> > > >subject all together.  However, regarding my
> > company's secret in
> > > >English, or Russian, or Martian, I disagree some.
> >  Think about a=20
> > > >simple voltage divider example.  You can write a
> > Thevenin equivalent
> > > >for it using one voltage source, and one
> > resistor.  The resistor's
> > > >value will be the parallel combination of the
> > original circuit's
> > > >resistors, and the voltage source will have the
> > value
>=== message truncated ===

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