[SI-LIST] Re: package SSN model accuracy requirements
- From: "Pratt, Gary" <gary_pratt@xxxxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Thu, 10 Mar 2005 06:06:38 -0500
Lets try this again ... With perhaps some better text formatting this
time ...
Very good questions Chris. I've sanitized our thread of any product
names, and am going back on-list as I think your questions might be of
interest to the general community.
=20
Guilty as charged. Though, the price of the SPICE simulator is included
in the price of the SI tool, so you really get SPICE for free. And, the
version of SPICE in this tool is actually much more than a SPICE
simulator. And, we really aren't downgrading to IBIS, instead we are
using the best of both worlds. You may want to look at IBIS 4.1 in more
detail. For us SPICE enthusiasts, it really is a match made in heaven
-- a great marriage between the simplicity of IBIS and the power of
SPICE+. (That is actually how my employer was able to convince me, as
25 year SPICE veteran, to go anywhere near IBIS.)
=20
So, the benefits to spice experts are good: =20
1) As stated, the price of a superior SPICE tool is included in
the price of the IBIS tool.
2) This SPICE+ simulator provides a modern, industry standard,
analog programming language. =20
A huge improvement over traditional SPICE behavioral
modeling. Believe me, as someone=20
who spent a great deal of the 80s and 90s doing SPICE
behavioral modeling ... once you=20
go to an analog programming language, you will never go back
to SPICE behavioral. Here=20
are some analogies (of varying accuracy):
1) Assembly language versus C - assembly language is
more powerful than SPICE, don't=20
need to go back to microprocessor vendor to get more
features
2) Unix CSH script versus C++ - pretty close analogy
3) Early macro-based digital simulator modeling versus
VHDL or Verilog - Spice may=20
be more flexible than the early digital
macro-modeling techniques.
3) IBIS provides the connectivity information missing from
SPICE, allowing simple and easy=20
post-routing analysis with large pin-count components
4) The IBIS tool can extract an accurate model of the I/O
loading from the post-layout PCB information.
5) If the IBIS file is generated by the silicon configuration
software using the features of=20
IBIS 4.1, it can automatically create a file containing all
the information SPICE needs=20
for an SSN simulation (which outputs are being switched, how
each output is configured,=20
which outputs are tied high or low to improve SSN, etc). =20
6) This is all done within an industry standard framework. No
more proprietary or defacto=20
standards and the interoperability problems they cause.
However, to your average FPGA/PCB designer, many of whom would find more
pleasure in poking themselves in the eye with a sharp stick than
learning that archaic SPICE language (software developed by hardware
engineers, in Fortran, in the early 1970s -- even before Disco), the
benefits are huge:
1) The digital designer can perform complex SPICE simulations
without any knowledge of SPICE.
2) The digital designer can work in an environment specifically
created and highly optimized for SI analysis.
=20
Now, this having been said, let me add three concerns on which I would
appreciate your opinion:
1) This is not a PDN solution. This assumes the detailed PCB
power distribution is minor=20
compared to the package, and can be modeled in a simple,
fixed way.
2) This solution requires an accurate s-parameter model of the
package for a bank of I/O and=20
its associated package power planes. =20
3) This assumes the I/O and its associated power supplies can be
divided into relatively=20
independent banks (consisting of port counts in the low
hundreds).=20
Does this still sound useful even with these caveats?
=20
I do know there are occasionally free and for-fee Analog Modeling
Language courses touring the world. I can let you know when one might
be in your area next, if you are interested. =20
=20
I attached a couple of postings to the IBIS list which you might find
interesting as well.
=20
Gary
=20
=20
************************************************************************
************************************************************************
*********
Reprints of IBIS postings
************************************************************************
************************************************************************
**********
Hello Itzik,
=20
=20
=20
Allow me to comment on your #1. The capabilities of spice macromodeling
and AMS languages are quite different. This is primarily the reason AMS
languages were developed, and are gaining momentum in the IC and System
design space.
=20
AMS languages are self-contained programming languages. They can
accommodate any future technologies or applications with no need to add
further syntax to the standard, or involve any standards committee or
tool-vendor engineering team. Macro-modeling is much like UNIX
scripting. It is a great way to quickly accomplish some automation, but
can become complex for larger tasks or impossible if the task requires a
UNIX command which isn't available (similar analogy applies to DOS batch
files, or WORD macros if you are a Windows user). =20
=20
Spice macro-modeling is similar to the situation which existed for
digital modeling in the 1970s and early 80s. At that time, modeling for
digital simulators was done with primitives such as flip-flop blocks,
Boolean logic blocks, etc. Complex macro models could be built from
these primitives, but often times extreme cleverness was required when
an application came along that needed different primitives than were
provided by the simulator vendor. And, since simulator vendors weren't
able to decide on a fixed set of primitives, models were not
transferable. For many of the same reasons VHDL and Verilog replaced
replaced digital macro modeling in the 80s (synthesis, notwithstanding),
AMS has been slowly replacing other alternatives in the late 90s and
00s. =20
=20
As I understand, the reason the IBIS committee adopted AMS is to avoid
the need to add further syntax to the IBIS language for each new
application and technology. It seems like the macro-modeling SPICE
syntax, and proposed standard templates, are prime examples of the
syntax creep AMS was intended to avoid (SSO enhancements as well,
perhaps). =20
=20
In an ideal world, the creator of the next generation of spice2ibis
would target AMS as their output. In that way they have, immediately at
their disposal, everything they could possibly need to accurately model
new technologies and applications (in a well documented, industry
standard, structured language). There would be no need to make
proposals to the IBIS committee, wait for ratification, and then wait
for adoption by the SI tool vendors for each new technology. Everything
would be completely self-contained, and would run in every SI tool that
support the current IBIS 4.1 standards. =20
=20
Thats my 2 cents worth. Hope that helps.
=20
=20
Gary
=20
=20
=20
------------------------------------------------------------------------
--------
From: owner-ibis-users@xxxxxxx <mailto:owner-ibis-users@xxxxxxx>
[mailto:owner-ibis-users@xxxxxxx] On Behalf Of Itzik Peleg
Sent: Sunday, February 20, 2005 11:04 AM
To: ibis-users@xxxxxxx <mailto:ibis-users@xxxxxxx>=20
Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling.
=20
Hello IBIS users
=20
I want to comment on the Macromodeling:=20
=20
But, 1st proper disclosure:
=20
I am familiar with spice language and not familiar with AMS languages.=20
=20
Some questions:
=20
1. As far as I understood the spice Macromodeling has the same
capabilities as the AMS languages (in terms of behavioral modeling).
2. IBIS support the external languages, SPICE, VHDL-AMS and
Verilog-AMS. The requirement from IBIS EDA tool developer to support
these 3 languages is too much in my opinion. The implementation of this
languages in simulation tool will take a long time (if it will be
implemented) shouldn't we focus on the concept of Macromodeling by a
fixed syntax (one only). By that allowing the EDA tool vendors develop
complete IBIS support for one set of commands (this will enable them to
support IBIS 4.1). The models author will use only one set of commands
(or use his own scripts for translation to the IBIS format from
different formats that he might use) this will enable a consist usage of
the language by all with the flexibility of the author to develop any
kind of buffer type.
3. Today there are simulation tools that support IBIS. How can we
verify that all the tools run the IBIS in the same way? When we are
going to use complex modeling the problem will be more severe.
=20
My opinion is:
1. Use only one language for Macromodeling.
2. IBIS forum should recommend and develop templates for different
buffer modeling needs.
3. The IBIS forum should check each EDA tool simulator for compliant
(there could be different levels of compliant like the different IBIS
specs 1.1 2.1 3.2 etc').
=20
Open for dissociation / comments.
=20
--
Regards
=20
Itzik Peleg
Board Technology Group
=20
***********************************************************
Please Note: email address change to: itzikpe@xxxxxxxxxxx
<mailto:itzikpe@xxxxxxxxxxx>=20
***********************************************************
=20
Marvell Semiconductor Israel Ltd
6 Hamada Street=20
Mordot HaCarmel Industrial Park
Yokneam 20692, ISRAEL
Email - itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=20
Tel - +972 4 9091192
Cell - +972 54 4452482
Fax - +972 4 9091501
WWW Page: http://www.marvell.com <http://www.marvell.com>=20
=20
=20
************************************************************************
************************************************************************
*********
Second Reprint of IBIS postings
************************************************************************
************************************************************************
**********
=20
Hi Lee,
=20
Your question of ease and accuracy can be answered on several levels.
For instance, assuming you could develop a traditional IBIS 3.x model
for a high-speed source-synchronous serial I/O (note 1), it will take an
enormous amount of time to create a model for each permutation of
configuration. For instance, assume your driver has 4 different voltage
levels, 4 different pre-emphasis levels, 2 different terminations, and 3
different process corners; you have 96 different IBIS models to create.
A VHDL-AMS model would be much easier to develop, and much easier for
your model users to manage the configurations.
=20
(Note 1: I've heard strong arguments both ways on this issue. Since I
don't have any first-hand experience, I won't comment either way. )
=20
On the other hand, there is currently no spice-to-vhdlams tool like
there is spice-to-ibis. So, it is currently up to the model creator to
make the appropriate SPICE simulations of the transistor-level design,
make the appropriate measurements, and build those measurements into a
VHDL-AMS model. In that respect, using spice-to-ibis for a simple IBIS
model would be much easier. Though, hopefully, as the popularity of AMS
grows, spice-to-AMS tools will become available.
=20
As for accuracy, because VHDL-AMS allows more degrees of modeling
freedom, my feeling is that it can be more accurate than IBIS. However,
on well-behaved drivers which fits the IBIS model template well, there
may be no difference in accuracy. On the other hand, since I have no
idea how to model a receiver containing internal equalization in
traditional IBIS, for me, a VHDL-AMS model would be infinitely more
accurate in this application. Likewise, for attempting to use IBIS for
power integrity purposes, etc. In summary, I would say if your model
will fit the traditional IBIS 3.x mold, use traditional IBIS. If not,
consider VHDL-AMS.
=20
You should also be aware that in addition to AMS languages, IBIS 4.1
allows for modeling with Berkeley SPICE primitives. This can be an
easier alternative for someone knowledgeable in SPICE doing some simple
modeling. SPICE versus AMS is somewhat analogous to Unix scripting
versus C programming. Like UNIX scripting, SPICE provides some basic
building blocks that are easy to assemble and run. But also like UNIX,
scripting will run slower, and if your scripting requires more
complexity than is provided in the basic UNIX commands, it can be
difficult or impossible to accomplish your task without someone creating
another UNIX command for you (most likely, in C). In the case of SPICE,
you would need to convince your SPICE tool vendor of the need for the
additional building block, then wait for them to implement and release
the new feature (then hope that all SPICE vendors follow suit so your
model will be relatively universal). In the case of AMS, if you need
some additional functionality, you just add it to your model. Since the
AMS language is self contained, anything you add to the model will be
immediately available to anyone using a simulator which supports the
IBIS 4.1 VHDL-AMS standard.
=20
Speaking of support, most of the major SI tool vendors have AMS
simulators in their company. All we need to do now is convince them to
go to the work of porting them to their SI tools. =20
=20
I hope that helps,
=20
Gary
=20
-----Original Message-----
From: lee yang [mailto:changly_80@xxxxxxxxxxx]
Sent: Tuesday, February 01, 2005 7:46 AM
To: Pratt, Gary
Subject: RE: [IBIS-Users] VHDL-AMS Model
=20
Hi Gary,
Appreciate the information you provided.
Does it mean that VHLS-AMS model is much easier to be produced compared
to IBIS model? Do we need to run the Hspice simulation in order to
generate the VHDL-AMS model like what is being done to generate IBIS
model? What is the accuracy of the model compared to IBIS model?
Thanks a lot and hope to hear from you soon!
-Lee
>From: "Pratt, Gary" <gary_pratt@xxxxxxxxxxx>
>To: "lee yang" <changly_80@xxxxxxxxxxx>,<ibis-users@xxxxxxx>
>Subject: RE: [IBIS-Users] VHDL-AMS Model
>Date: Mon, 31 Jan 2005 12:18:49 -0500
>
>Hello Lee,
>
>A simple answer to your question is VHDL-AMS provides a high level of=20
>flexibility. So for instance, instead of waiting for functionality to=20
>be added to the IBIS standard and then waiting for SI tool vendors to=20
>implement the function; VHDL-AMS provides you the ability to implement=20
>the function immediately. To date, the flexibility of VHDL-AMS has=20
>provided significant benefit in simplifying modeling of highly=20
>configurable devices such as PCI Express drivers and difficult to model
>receivers containing internal equalization. I suspect VHDL-AMS could=20
>also be applied to implementing the functionality required for modeling
>power integrity.
>
>Gary
>
>
>
>-----Original Message-----
>From: owner-ibis-users@xxxxxxx [mailto:owner-ibis-users@xxxxxxx] On=20
>Behalf Of lee yang
>Sent: Sunday, January 30, 2005 11:35 PM
>To: ibis-users@xxxxxxx
>Subject: [IBIS-Users] VHDL-AMS Model
>
>Hi,
>
>Recently I heard about another behavioral model call VHDL-AMS, can=20
>anyone please give some background about it?
>Since we already have IBIS model, what is the reason we need to use=20
>VHDL-AMS model instead? What is the pros and cons compared to IBIS=20
>model?
>Thanks and appreciate if someone can shed some light.
>
>-Lee Yang
=20
=20
************************************************************************
************************************************************************
*********
END OF Reprints of IBIS postings
************************************************************************
************************************************************************
**********
=20
=20
=20
=20
=20
________________________________
From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx]=20
Sent: Wednesday, March 09, 2005 8:43 PM
To: Pratt, Gary
Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements
So you are asking me to get a SPICE tool but down grade the analysis to
IBIS ? Why not just use SPICE then ?
-----Original Message-----
From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx]
Sent: Wednesday, March 09, 2005 6:23 PM
To: Chris.Cheng@xxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: package SSN model accuracy
requirements
=09
=09
The tool is [Pratt, Gary] XXXXXXXXX . Its been available from
[Pratt, Gary] XXXXXXXX for almost two years now. =20
=09
=20
________________________________
From: si-list-bounce@xxxxxxxxxxxxx on behalf of Chris Cheng
Sent: Wed 3/9/2005 8:53 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements
=09
=09
Cool ! Say tomorrow my boss wants me to do such analysis, which
company is
shipping this excellent tool ? I want to get my hands on it like
yesterday.
Is any one of your FPGA customer doing it yet ? Please share
your insight.
=09
-----Original Message-----
From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx]
Sent: Wednesday, March 09, 2005 5:40 PM
To: ray.anderson@xxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements
=09
=09
Actually, there was one irreverent poster who was saying SSO
could be
done with IBIS (as it stands today). That is assuming one can
generate
an accurate (causal, passive, etc) s-parameter model for an
appropriate
section of the package (with say, up to perhaps 200 ports). =3D20
=09
IBIS 4.1 with IEEE standard 1076.1 provides all the facilities
one would
need to create an IBIS standard model which would simulate
supply
current and driver output characteristics to any level of
accuracy
desired. Couple this with an SI tool that accepts large
s-parameter
models, and I believe you are ready to roll. =3D20
=09
Couple this with silicon configuration software that can write
an IBIS
4.1 file, and one has the makings of an easy to use application
for SSO
analysis. =3D20
=09
Gary
=09
=09
=09
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Ray Anderson
Sent: Wednesday, March 09, 2005 10:48 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements
=09
Chris-
=09
I think you may be misinterpreting what Lynne and the other
posters in
this thread have been discussing so far.
=09
No one seems to be saying that SSO simulations should be done
with IBIS
(as it stands today).
=09
The discussion is centered around the various package models. An
IBIS
model consists of the silicon model portion and the package
model
portion. One can take the package model portion (that is
described in
IBIS syntax) and rewrite it in Spice syntax if you so desire. So
while
some of the statements earlier in the thread may have referenced
"IBIS
lumped models" and "IBIS ICM" models, the crux of the discussion
is
related to model topologies, model complexity, model bandwidth,
and
model size where the "model" in question is the package model.
All of
these model attributes are relevant to SSO simulations
regardless of
what you choose as the silicon driver model.
=09
-Ray
=09
=09
=09
Chris Cheng wrote:
=09
>You can say what you want with IBIS, at the end of the day
(today, not=3D20
>tomorrow or some future spec), can you do an SSO analysis based
on a=3D20
>pure IBIS model ?
>
>I am a complete N00b on FPGA so I am curious how many people
really do=3D20
>SSO analysis with just a standard IBIS description of a chip. I
can't,=3D20
>so please tell me how you did it.
>
>Those who know me and my previous life somewhere should
remember some=3D20
>of those reference SPICE SSO models I generated, there is only
a small=3D20
>number of SPICE drivers, interconnect and receivers set that
need to be
=09
>included to accurately model SSO, x-talk, package/interconnect
loss.=3D20
>Remember, m=3D3Dx is a very powerful macro that doesn't even need
to be =3D
an
integer.
>
>Another interesting side note, some of the so call speedy
"IBIS=3D20
>engines" end up barely faster or even slower in some cases when
the=3D20
>same interconnect complexity is added to get the accuracy close
to
acceptable level.
>
>All of the above SSO modelling methodolgies are well documented
and=3D20
>correlated with actual characterization numbers. I am not
talking about
=09
>vaporware analysis here.
> =3D20
>
=09
=09
--
Raymond Anderson
Senior Signal Integrity Staff Engineer
Product Technology Dept.
Package Engineering Group
Xilinx Inc.
=09
=09
=09
------------------------------------------------------------------
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:
