[SI-LIST] Re: package SSN model accuracy requirements
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: "steve weir" <weirsi@xxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Thu, 24 Mar 2005 14:59:20 -0800
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]=20
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=20
you state including limited volunteer resources, that it has been a=20
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=20
have today, I think it could be very valuable for all of us as a =
community=20
to attempt to take as much as a dispassionate, and nonparochial =
evaluation=20
of where we are, and what will make the best use of our collective =
efforts=20
moving forward. I suggest that perhaps what we want to do is poll the=20
community on the basis of vision, and willingness to commit dollar and=20
human resources over the next one to three years:
1) Encrypted SPICE - Portability, security, "speed", sometimes =
convergence,=20
and labelling conventions seem to be the awkward points.
2) IBIS evolution - Can IBIS make up for lost ground, and keep from =
losing=20
it again? Is the evolution of IBIS4.1 going to become a labelling =
wrapper=20
for SPICE models?
3) AMS - If this is going to fly, how do we propagate en-masse into the=20
community? Can we afford to try and propagate both VHDL and Verilog=20
AMS'? If not, how do we vote out the loser before monstrous investment =
is=20
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=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 =
=3D
>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, =3D
>Version
>| 2.0. This document is maintained by Accellera (formerly Open Verilog
>| International), an independent organization. Verilog-AMS is a =3D
>superset
>| that includes Verilog-A and the Verilog Hardware Description Language
>| 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 =
IBIS, =3D
>it
>can't model a simple problem like SSO. If you are a customer, would you
>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 just
>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 the
>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 =3D
>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, =3D
>whoever
>give the model out has the ultimate responsibility. But ever since the
>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 behavioral
>models can address those problems long time ago but look at how long =
=3D
>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 =
=3D
>out of
>that. Am I supposed to wait for another sabbatical if I want to model =
my
>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 =3D
>without
>encryption ?
>
>Like I said before, it's like asking "Can you tell me the secret of =
your
>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 =3D
>impact
>on the I/O, may be SSO is no longer an important issue for GB serial =
=3D
>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 =
=3D
>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 =
=3D
>crazy
>FSB ringback, over-drive specs. Try a few case of real over drive and =
=3D
>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, =3D
>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:
>//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
>
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:
//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:
