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

  • From: "Tom Dagostino" <tom@xxxxxxxxxxxxx>
  • To: <Chris.Cheng@xxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
  • Date: Fri, 11 Mar 2005 13:55:49 -0800

Chris

That is not an urban legend, it is an experience I had with a silicon vendor
in the Bay Area in 2001.

Differences in SPICE engines are small compared to IBIS, you mean like those
that will not converge and those that will?  I'm not aware of any IBIS
simulators that will not converge on valid models but am aware of different
SPICE simulators that will not converge on valid SPICE models.

I was not arguing either IBIS or SPICE is better.  I was pointing out that
trying to get everybody to sit down and hold hands is not going to work.
There a variety of business reasons inside the various silicon vendors and
the various EDA vendors that will prevent the universal encrypted model to
ever succeed.


Tom Dagostino
Teraspeed Labs
13610 SW Harness Lane
Beaverton, OR 97008
503-430-1065
http://www.teraspeed.com
tom@xxxxxxxxxxxxx

Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827

Teraspeed is the registered service mark of
Teraspeed Consulting Group LLC

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Chris Cheng
Sent: Friday, March 11, 2005 11:55 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements


Tom,
That is the biggest urban legend I've have ever heard.
I have one simple answer to that, whatever difference those SPICE engine may
have, it will be smaller than those IBIS model and simulation engine being
handed out today. It's like some weekend biker telling Lance Armstrong "hey,
your bike sucks".
I didn't pull SPICE out of the thin air. It was the customers who were
frustrated about the inadequate behavioral models that drives the demand.
You can come out with any hypothetical whatif's you want. At the end of the
day if your customers tell you your model sucks and they want something
different, that's what it counts.
All I am saying is give the customer a choice. If they want IBIS, good for
them. If they want encrypted SPICE, more power to them. For a while, I saw
this "customer is King" poster in certain Si company. I thought it was cute.

-----Original Message-----
From: Tom Dagostino [mailto:tom@xxxxxxxxxxxxx]
Sent: Friday, March 11, 2005 11:28 AM
To: gary_pratt@xxxxxxxxxxx; Chris.Cheng@xxxxxxxxxxxx;
si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: package SSN model accuracy requirements


There are another aspects of getting the silicon vendors to agree upon a
common encryption technology that needs a little discussion.  In a past life
I was charged with getting one silicon vendor to agree with using the SPICE
engine a past employer has.  This silicon vendor was having enough problems
with getting consistent results from HSPICE being their customer base had
multiple different versions of HSPICE running on different platforms.  When
I asked this well known and highly regarded vendor to offer encrypted models
for another SPICE simulator the response was "we have enough problems
supporting HSPICE, we don't have the budget nor want the pain of another
simulator.  Who is going to validate the models in your simulator?".

The problem is not just the technical aspect but also the business aspects
for the silicon vendor.  If there are any differences between the published
results of a buffer and what comes out of brand XX simulator, how does it
get resolved?

And why would Synopsis agree to support an open encryption standard when
they have the market locked up with their present approach?

Tom Dagostino
Teraspeed Labs
13610 SW Harness Lane
Beaverton, OR 97008
503-430-1065
http://www.teraspeed.com
tom@xxxxxxxxxxxxx

Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827

Teraspeed is the registered service mark of
Teraspeed Consulting Group LLC

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Pratt, Gary
Sent: Friday, March 11, 2005 10:33 AM
To: Chris.Cheng@xxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements



Chris,

Comments are embedded below.

Gary

=20

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Thursday, March 10, 2005 6:45 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements

Gary,
That's an interesting tool to say the least.=20

So basically you are suggesting using IBIS 4.1 to get the SPICE level
circuit description of the I/O and perform the analysis.

Gary=3D> Not exactly.  I was suggesting the slow, convergence-prone =
SPICE
models be replaced with fast, highly-reliable, industry standard Analog
Behavioral Models (aka AMS). =20

Why not just have the EDA tool vendors agreed on a common encryption
standard and have the vendor hand out a standard encrypted BSIM3 circuit
then ?

Gary=3D> Hmm.  One could ask why go to the trouble of making a standard
for something that runs slow and has trouble converging, when we already
have a standard for a solution that runs fast and converges well ...

GARY=3D> But, I think there is a larger concern here ...  I admit to =
much
ignorance in the latest encryption technology, but to be a standard it
seems it would have to be available to any SPICE vendor.  Like Gary's
Garage Shop -- proud vendor of GSpice.  Not sure how enthused silicon
vendors would be knowing Gary's Garage Shop has access to their IP.
(Though, I happen to personally know this shop is well above reproach.)


Gary=3D> Lame humor aside, even if we somehow limited it to the top 10
SPICE vendors, would there be a way for a silicon vendor to trace a leak
back to the leaky tool vendor?  Somehow, I just don't think silicon
vendors would go for that. And, I'm not sure who would drive this and
who would support it, and how long it would take.  But, I'm more than
willing to be proven wrong, if that's the way the industry wants to go.

If I read Mark McKee's summary of what he has been doing, it is
basically a DYI approach which starts with a structural description of
the package, generate a package model that fit the analysis need and
send it to a SPICE engine to do the analysis.

I dig it, that's not too far from what I've been doing with ASIC or
processor I/O design.

I also like the digital extension in your tools where it will really
comes in handy with these multi-stage equalizing circuits.
Gary=3D> Yes. That's one advantage to this tool I forgot to mention.  =
All
of the logic and control can be partitioned to the event-driven solver.
So, that part of the simulation basically takes no time.  This can make
a fast simulation even faster.

As for needing S-parameters and these 200 port circuits, it seems I
still could get away with a small set of ports to handle the SSO models
even for these multi-giga hertz blocks. It is a matter of how you
partition your circuit blocks in the worst case situation.=20

Gary=3D>  I don't know.  It seems to me that if one has 64 drivers
switching at the same time, and these all get their power from the same
set of bumps, one should really simulate all the drivers, traces, and a
good portion of the package power planes to get an accurate result.
But, I certainly make no claim to be an expert in this area.  That is
actually what I was hoping to learn from this discussion.


-----Original Message-----
From: Pratt, Gary [mailto:gary_pratt@xxxxxxxxxxx]
Sent: Thursday, March 10, 2005 3:07 AM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements


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.
=3D20
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.) =3D20 So, the benefits
to spice experts are good: =3D20

        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. =3D20
           A huge improvement over traditional SPICE behavioral
modeling.  Believe me, as someone=3D20
           who spent a great deal of the 80s and 90s doing SPICE
behavioral modeling ... once you=3D20
           go to an analog programming language, you will never go back
to SPICE behavioral.  Here=3D20
           are some analogies (of varying accuracy):

                1) Assembly language versus C - assembly language is
more powerful than SPICE, don't=3D20
                   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=3D20
                   be more flexible than the early digital
macro-modeling techniques.

        3) IBIS provides the connectivity information missing from
SPICE, allowing simple and easy=3D20
           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=3D20
           IBIS 4.1, it can automatically create a file containing all
the information SPICE needs=3D20
           for an SSN simulation (which outputs are being switched, how
each output is configured,=3D20
           which outputs are tied high or low to improve SSN, etc). =3D20
        6) This is all done within an industry standard framework.  No
more proprietary or defacto=3D20
           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.

=3D20
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=3D20
           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=3D20
           its associated package power planes. =3D20
        3) This assumes the I/O and its associated power supplies can be
divided into relatively=3D20
           independent banks (consisting of port counts in the low
hundreds).=3D20

Does this still sound useful even with these caveats?
=3D20
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. =3D20 =3D20 I attached a =
couple
of postings to the IBIS list which you might find interesting as well.
=3D20
Gary
=3D20
=3D20
************************************************************************
************************************************************************
*********
Reprints of IBIS postings
************************************************************************
************************************************************************
**********
Hello Itzik,
=3D20
=3D20
=3D20
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.
=3D20
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).  =3D20 =3D20 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.  =3D20 =3D20 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).   =3D20
=3D20
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. =3D20 =3D20 Thats my 2 cents =
worth.
Hope that helps.
=3D20
=3D20
Gary
=3D20
=3D20
=3D20
------------------------------------------------------------------------
--------
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>=3D20
Subject: [IBIS-Users] Comments on the 18 Teleconference - Macromodeling.
=3D20

Hello IBIS users
=3D20
I want to comment on the Macromodeling:=3D20 =3D20 But, 1st proper
disclosure:
=3D20
I am familiar with spice language and not familiar with AMS
languages.=3D20 =3D20 Some questions:
=3D20
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.
=3D20
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').
=3D20
Open for dissociation / comments.
=3D20
--
Regards
=3D20
Itzik Peleg
Board Technology Group
=3D20
***********************************************************
Please Note: email address change to: itzikpe@xxxxxxxxxxx
<mailto:itzikpe@xxxxxxxxxxx>=3D20
***********************************************************
=3D20
Marvell Semiconductor Israel Ltd
6 Hamada Street=3D20

Mordot HaCarmel Industrial Park
Yokneam 20692, ISRAEL
Email - itzikpe@xxxxxxxxxxx <mailto:itzikpe@xxxxxxxxxxx>=3D20
Tel   - +972 4  9091192
Cell  - +972 54 4452482
Fax   - +972 4  9091501
WWW Page: http://www.marvell.com <http://www.marvell.com>=3D20 =3D20 =
=3D20
************************************************************************
************************************************************************
*********
Second Reprint of IBIS postings
************************************************************************
************************************************************************
**********
=3D20
Hi Lee,
=3D20
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.
=3D20
(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.  ) =
=3D20
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.
=3D20
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.
=3D20
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.
=3D20
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. =3D20 =3D20 I hope =
that
helps, =3D20 Gary =3D20 -----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 =3D20 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=20
>of=3D20 flexibility.  So for instance, instead of waiting for=20
>functionality to=3D20 be added to the IBIS standard and then waiting =
for=20
>SI tool vendors to=3D20 implement the function; VHDL-AMS provides you =
the

>ability to implement=3D20 the function immediately.  To date, the=20
>flexibility of VHDL-AMS has=3D20 provided significant benefit in=20
>simplifying modeling of highly=3D20 configurable devices such as PCI=20
>Express drivers and difficult to model

>receivers containing internal equalization.  I suspect VHDL-AMS=20
>could=3D20 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=3D20=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=3D20 =

>anyone please give some background about it?
>Since we already have IBIS model, what is the reason we need to =
use=3D20=20
>VHDL-AMS model instead? What is the pros and cons compared to IBIS=3D20 =

>model?
>Thanks and appreciate if someone can shed some light.
>
>-Lee Yang
=3D20
=3D20
************************************************************************
************************************************************************
*********
END OF Reprints of IBIS postings
************************************************************************
************************************************************************
**********
=3D20
=3D20
=3D20
=3D20
=3D20
________________________________

From: Chris Cheng [mailto:Chris.Cheng@xxxxxxxxxxxx]=3D20
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
=3D09
=3D09
        The tool is [Pratt, Gary] XXXXXXXXX .  Its been available from
[Pratt, Gary] XXXXXXXX  for almost two years  now. =3D20
=3D09
        =3D20
________________________________

        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
=3D09
=3D09

        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.
=3D09
        -----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
=3D09
=3D09
        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).
=3D3D20
=3D09
        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. =3D3D20
=3D09
        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. =3D3D20
=3D09
        Gary
=3D09
=3D09
=3D09
        -----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
=3D09
        Chris-
=3D09
        I think you may be misinterpreting what Lynne and the other
posters in
        this thread have been discussing so far.
=3D09
        No one seems to be saying that SSO simulations should be done
with IBIS
        (as it stands today).
=3D09
        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.
=3D09
        -Ray
=3D09
=3D09
=3D09
        Chris Cheng wrote:
=3D09
        >You can say what you want with IBIS, at the end of the day
(today, not=3D3D20
        >tomorrow or some future spec), can you do an SSO analysis based
on a=3D3D20
        >pure IBIS model ?
        >
        >I am a complete N00b on FPGA so I am curious how many people
really do=3D3D20
        >SSO analysis with just a standard IBIS description of a chip. I
can't,=3D3D20
        >so please tell me how you did it.
        >
        >Those who know me and my previous life somewhere should
remember some=3D3D20
        >of those reference SPICE SSO models I generated, there is only
a small=3D3D20
        >number of SPICE drivers, interconnect and receivers set that
need to be
=3D09
        >included to accurately model SSO, x-talk, package/interconnect
loss.=3D3D20
        >Remember, m=3D3D3Dx is a very powerful macro that doesn't even
need to be =3D3D
        an
        integer.
        >
        >Another interesting side note, some of the so call speedy
"IBIS=3D3D20
        >engines" end up barely faster or even slower in some cases when
the=3D3D20
        >same interconnect complexity is added to get the accuracy close
to
        acceptable level.
        >
        >All of the above SSO modelling methodolgies are well documented
and=3D3D20
        >correlated with actual characterization numbers. I am not
talking about
=3D09
        >vaporware analysis here.
        > =3D3D20
        >
=3D09
=3D09
        --
        Raymond Anderson
        Senior Signal Integrity Staff Engineer
        Product Technology Dept.
        Package Engineering Group
        Xilinx Inc.
=3D09
=3D09
=3D09

------------------------------------------------------------------
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:    =20
                //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
 =20
------------------------------------------------------------------
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:    =20
                //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
 =20

------------------------------------------------------------------
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


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