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


I am hoping to achieve a little bit of #1 with the messages I am writing
lately on this thread.  (I would have better things to do...)

I agree #2 is out, especially since I grew up behind the iron curtain...

I fear #3 may happen for the wrong reasons.


-----Original Message-----
From: steve weir [mailto:weirsi@xxxxxxxxxx]=20
Sent: Thursday, March 24, 2005 3:09 PM
To: Muranyi, Arpad; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements

Arpad, personally I really like the possibilities that AMS offer.  I am=20
very concerned on how as a community we turn potential into reality.  =
industry is littered with the bones of different languages and methods =
were excellent concepts but failed in the market, while technically =
solutions prevailed.

If we poll and find out that AMS is sorely lacking in the support that =
needs to succeed, then I think there are only three viable courses of =

1) "Educate", ( some might say lobby ) to get sufficient market support =
make this direction viable
2) Force by edict such as gov't.  Generally that kind of thing is a bad =
3) Abandon for a path that can succeed in the market.


At 02:59 PM 3/24/2005 -0800, Muranyi, Arpad wrote:
>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?
>-----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 =
>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 =
>important and growing circumstances.  Cadence's IBIS Summit =
>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 =
>to attempt to take as much as a dispassionate, and nonparochial  =
>of where we are, and what will make the best use of our collective =
>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 =
>and labelling conventions seem to be the awkward points.
>2) IBIS evolution - Can IBIS make up for lost ground, and keep from =
>it again?  Is the evolution of IBIS4.1 going to become a labelling =
>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 =
>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 =
> >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, =
> >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 =
> >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 =
> >
> >The same goes for the receiver modeling problem.  When IBIS was =
> >there was no need for doing that, so we didn't put it in the spec.  =
> >those days most everything was measured at the pin of the device.  =
> >we started to move the measurement point to the inside of the =
> >the die pad.  This was still doable with IBIS.  Timing measurements =
> >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 =
> >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 =
> >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=3D20
> >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 of the voltage
> >division the divider gives you.  If you don't know anything about
> >the original circuit and I gave you only the Thevenin equivalent,
> >are you going to be able to tell me what the two resistor values are
> >in the original circuit and what voltage they are connected to?
> >That's how behavioral equivalents can be useful to hide my
> >company's secret.  I agree, it may not be always possible to hide
> >everything like that, and the lawyers may find that my Thevenin
> >equivalent is IP, but that is a different story.
> >
> >b)  Asking how AMS can handle gate modulation is equivalent to ask
> >how the C++ language can handle your favorite software projects.
> >By the way, the HSPICE B-element has done this for years now, try
> >the "spu_scal" and "spd_scal" parameters of the B-element.  It just
> >hasn't been made official by the IBIS specification yet, because
> >there was not enough demand for it up to now.  However, you can
> >look at BIRD97 and the comments Katja wrote recently how this=3D20
> >would work and how it could potentially become part of the spec.
> >
> >Regarding your concerns about speed when the simulation deck is
> >dominated by interconnects, you can actually combine all your
> >interconnect pieces into one big S-parameter block (i.e. make
> >a behavioral model for them), and then your simulation is going
> >to go orders of magnitude faster.  Same principle as combining
> >the thousands of transistors into a behavioral buffer block...
> >
> >The equalization stuff or receiver modeling doesn't have to be done
> >with multi dimensional lookup tables to be behavioral.  This is
> >exactly where the AMS languages provide a tremendous capability.
> >You could write FIR filters, decision feedback loops, etc. with its
> >digital equation capabilities, which would execute lightening
> >fast, because they are event driven, and don't have to be
> >evaluated at every single analog time step (iteration).
> >
> >c)  Again, I do not want to go into the subject of encryption,
> >it is a different story.  However, when we write *-AMS or AMS,
> >we are talking about VHDL-AMS and Verilog-AMS.  Quote from the
> >IBIS4.1 specification:
> >
> >| "VHDL-AMS" refers to "IEEE Standard VHDL Analog and Mixed-Signal
> >| Extensions", approved March 18, 1999 by the IEEE-SA Standards Board =
> >and
> >| designated IEEE Std. 1076.1-1999.
> >|
> >| "Verilog-AMS" refers to the Analog and Mixed-Signal Extensions to
> >| Verilog-HDL as documented in the Verilog-AMS Language Reference, =
> >Version
> >| 2.0.  This document is maintained by Accellera (formerly Open =
> >| International), an independent organization.  Verilog-AMS is a =3D
> >superset
> >| that includes Verilog-A and the Verilog Hardware Description =
> >| IEEE 1364-2001.
> >
> >Sincerely,
> >
> >Arpad
> =

> >
> >-----Original Message-----
> >From: si-list-bounce@xxxxxxxxxxxxx =
[mailto:si-list-bounce@xxxxxxxxxxxxx] =3D
> >On Behalf Of Chris Cheng
> >Sent: Wednesday, March 23, 2005 5:27 PM
> >To: si-list@xxxxxxxxxxxxx
> >Subject: [SI-LIST] Re: package SSN model accuracy requirements
> >
> >Arpad,
> >
> >I can give you an even simpler answer, ever since the existence of =
> >it
> >can't model a simple problem like SSO. If you are a customer, would =
> >choose a method that may be error if it is done wrong but at least =
give =3D
> >you
> >a chance to predict the problem if it is done right, or, something =
> >can't do the analysis AT ALL ? There are many road accidents with =
cars, =3D
> >but
> >that doesn't mean you have to walk to work.
> >
> >Let me repeat the question I've asked many many times, how many of =
> >member of the Si-list who are NOT just professional standards =
attendee =3D
> >or
> >EDA tool vendors and have real responsibility to design system are =
> >actually
> >using a standard IBIS model to analyze SSO today ? I rest my case.
> >
> >Garbage in garbage out, no matter it is SPICE or IBIS. At the end, =
> >whoever
> >give the model out has the ultimate responsibility. But ever since =
> >existence of IBIS, it can't address the problem high performance =
design =3D
> >(SSO
> >and receiver performance to name a few). You and I know that =
> >models can address those problems long time ago but look at how long =
> >since
> >the first known successful attempt (if you disagree with me on that
> >reference, ping me off-line) until the standard committee even catch =
up =3D
> >with
> >the idea. Seven years is a very long time, people can earn sabbatical =
> >out of
> >that. Am I supposed to wait for another sabbatical if I want to model =
> >equalizing receivers ? I've got problems on things I need to ship =3D
> >tomorrow.=3D20
> >
> >Let's take a closer look at AMS
> >Here are the claims :
> >
> >a) It abstract your I/O to protect your IP
> >Well, Gary's reference seems to suggest every I/O design is as simple =
as =3D
> >a
> >university paper so may be your company have no problem handing out =
the =3D
> >I/O
> >state machine design. Is that true ?
> >On the same reference we are led to believe a SPICE level=3D3D1'ish =
model =3D
> >is
> >really a behavioral model, ok I dig it, but do you think your company
> >lawyers and design managers will buy that and freely handing it out =
> >without
> >encryption ?
> >
> >Like I said before, it's like asking "Can you tell me the secret of =
> >company ?"
> >Ans : "I can't tell you in English, but I can tell you in Martians =
(just =3D
> >not
> >to offend my earthly friends :-D)"=3D20
> >Is that really possible (besides the fact that there is no Martian)?
> >
> >b) It is accurate and fast
> >I still haven't seen any mention of SSO or how AMS can handle power =
> >impact
> >on the I/O, may be SSO is no longer an important issue for GB serial =
> >ports ?
> >How does one handle such modulation by predriver and substrate =
feedback =3D
> >from
> >multiple power sources (core power for predriver, I/O power for main =
> >driver)
> >without resorting to those level=3D3D1'ish transistor model ? A =
marketing =3D
> >paper
> >like what Gary present can carefully craft the example to the =
advantage =3D
> >of
> >the simulator but in reality how many interconnect is one simple =3D
> >S-parameter
> >deck ? I would bet the real customer topology will more like a mix =
bag =3D
> >of
> >circuit elements different vendor provide such as chip package, =3D
> >transmission
> >line, terminators, discrets, connector models. How the speed of AMS =
will =3D
> >do
> >when it is overloaded with a lot more circuit elements like R,L,C,
> >transmission lines and S-parameters by different components ?
> >Let's focus more on this little problem like a receiver, if you have =
to =3D
> >use
> >the output of the receiver to predict a equalization how would you =
use =3D
> >your
> >behavioral models to predict that ? Just take a look at those typical =
> >crazy
> >FSB ringback, over-drive specs. Try a few case of real over drive and =
> >ring
> >back cases which depends on common, differential mode, operating =
point, =3D
> >over
> >drive, hysteretic etc and try construct a multi-dimensional =3D
> >equation/table
> >to describe it and let's see how fast you will get. Ask the friends =
we =3D
> >both
> >know and have already make pitches in this thread what do they think =
? I =3D
> >am
> >a fair person, show me a real life case and data and I will be =3D
> >convinced.
> >
> >c) It is standard and everyone support it
> >I still couldn't figure out whether AMS is VHDL-AMS or Verilog-AMS, =
> >which
> >one we are talk about here ? Can you tell me ?
> >Does everyone use the same encryption to protect your IP ? If every =
tool =3D
> >has
> >a different encryption, what kind of ZBB do you think you will get =
for =3D
> >ten
> >different kinds of encryptors from ten different vendors ?
> >------------------------------------------------------------------
> >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
> >
>The weirsp@xxxxxxxxxx e-mail address will terminate March 31, 2005.
>Please update your address book with weirsi@xxxxxxxxxx

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:

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List FAQ wiki page is located at:

List technical documents are available at:

List archives are viewable at:     
or at our remote archives:
Old (prior to June 6, 2001) list archives are viewable at:

Other related posts: