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

  • From: Chris Cheng <Chris.Cheng@xxxxxxxxxxxx>
  • To: "'si-list@xxxxxxxxxxxxx '" <si-list@xxxxxxxxxxxxx>
  • Date: Sat, 12 Mar 2005 16:23:22 -0800

Ray and Vadim,

This seems to remain a good discussion so let's continue.

I open my mouth in this thread by starting on my own 
curiosity on how real designers, not tool vendors or 
Si app people think on how to do analyze SSO in actual 
system now. I have yet to hear a single designer in 
this board standing up and say he/she is doing SSO 
analysis TODAY with a tool other than SPICE. If I
am incorrect, please come forth and correct me.

Sure I hear promises of a magic spec that can do it 
in the future and great tools that will speed things 
up a 1000 times faster. Has anyone actually done it 
yet ? Well, I know one, me. While my own experience 
could be obsolete or dated, that's how I have to draw 
my own conclusion. Like I say many times before, I 
don't shoot from my hip, I have to do it and get my 
own experience before I say anything about it. If 
you have your own experience and contradict mine,
great ! I love to hear it and please share with me. 
I want to learn from your experience and elighten mine.
What I can't accept is statements like "I think this 
will be better blah blah blah" but you have zero 
experience and data to back it up. And my experiences
included the following : a behavioral model that can 
model real SSO noise that can correlate with both 
SPICE and lab measurement, a behavioral model that
can model a unique receiver that I believe will be 
even more important for >2G I/O since there will be 
substantial equalization at the receiver level (i.e.
the eye will fail at pin but will be properly received
after equalization inside the Si). Lot's of very 
smart people and big name EDA tool vendors helped me
out and at the end of the day, both objectives has 
been achieved. However, when I sat back and looked at
the experience I had to ask myself "was it worth it ?"
When it was all said and done, in order to achieve the
criteria I set up (not some hypothetical benchmark
by some standard committees but actual correlation 
with real Si measurement in lab), the effort to 
extract the correct model and the speed up (or slow
down in some cases vs. SPICE simulation) just 
make it not that attractive. Especially the behavioral
abstraction of receiver part where a simple SPICE
circuit out perform the behavioral model hands down.
YMMV but that's my own experiences, not some promises 
from tool vendors or standard committee. And that was
more than 7 years ago. What takes the rest of the 
industry so long to even attempt to model SSO beyond 
SPICE sadden me. What takes you guys so long ? I 
have heard of many horror stories about SSO noise 
for the pass seven years. What did people do to 
predict these problems other than using SPICE ? 
I really want to know.

You may not agree with my opinions. But at least 
I deserved the credit for trying to work my problem 
out from the other side. I actually tried to handle 
my analysis using behavioral models. Have you even 
tried beyond making some hypothetical spec ? Do you 
have any real design data TODAY to back up your 
claims ?

I would like to end once again with a polite request
for the answers to any Si vendors and Michael in 
particular :

a) Does your company believe these so call secondary 
effects like package parasitics and SSO will impact 
your I/O performance ?
b) Does your company feels it is necessary to 
provide a model that can model and analyze these 
effect correctly ?
c) What model is provided TODAY to address 
those analysis needs ?
d) What CAD tool is currently supporting those 
models so that your customers can analyze the 
problem accurately ?
 

-----Original Message-----
From: Ray Anderson
To: si-list@xxxxxxxxxxxxx
Sent: 3/12/2005 8:59 AM
Subject: [SI-LIST] Re: package SSN model accuracy requirements


This conversation regarding what  are the kinds of models and/or 
simulators required to do effective SSN simulations along with the 
obligatory Spice vs IBIS discussion has been most interesting and 
informative. This is a issue just about all concerned with SI issues 
(model users, model providers and EDA tool vendors) have a vested 
interest in seeing resolved with a workable solution.

I have to agree with Chris and Vadim (and possible others) who mentioned

that we need a workable solution now (today) that is supported by  the 
tools that the majority of the SI community is using. I think we can all

acknowledge that none of the solutions available today are what we could

call optimal solutions (they are either too slow, too inaccurate, too 
complex, too simplistic, require tools that very few have access to, or 
suffer from some other perceived flaw). However the reality is that 
there are designs on the drawing board that need to be simulated today 
(not next quarter or next year or whenever) to verify that they are 
going to work correctly. Marketing has very little sympathy for a missed

window of opportunity because the designers needed an extra year or so 
for some, as of yet, unidentified development in modeling so that they 
can get an extra 10% accuracy in the SSN simulations.

The long term solutions that are being discussed  (new simulators, 
behavioral modeling advancements, languages standards and so forth) are 
necessary and ultimately will lead to a better (whatever that means) 
solution sometime in the future. These ongoing developments are 
necessary to get to where we need to go, but unfortunately they don't 
have a great impact on the need to have usable simulations today.

So it seems that the problem can be divided into a tactical component (a

"good enough" or adequate solution) for today's designs, and a long-term

strategic solution that might take a long time to eventually become 
available but will be technically more elegant, accurate and faster. How

good "good enough" is  is debatable and it depends on the user's 
requirements. If you use a 'legacy' 3.2 style IBIS model and are able to

get  an answer within 25% of the true answer in 5 minutes is that 
preferable to using an encrypted Hspice model that could provide an 
answer with 5% accuracy after a 20 hour simulation run? I think the 
answer is that it depends on what you need from the answer.

Most of the above discussion has focused on the format of the buffer 
model and havn' addressed the packaging parasitic part of the issue. In 
that arena we have the choice of lumped, distributed, coupled, 
uncoupled, n-port s-parameter and probably other formats as well. 
Depending on the use (timing and crosstalk simulations vs SSN 
simulations vs  eye-diagram sims) the optimum format may differ. (is 
anyone supplying s-parameter based n-port models for SSN simulations 
today??)(and if they are, do the majority of the users know how to use 
them?)

With the above in mind,  perhaps we can discuss what silicon vendors can

provide to customers today for today's problems. Some companies provide 
Hspice models, some IBIS models and some provide both of the above to 
allow the customer to make the ultimate decision as to which model makes

sense for their situation. With the current state of the simulation 
landscape that exists today with respect to SSN simulations it seems to 
me that providing models in both formats and letting the customer do the

tradeoff decision (accuracy vs speed vs whatever) is one workable 
solution. I'm sure others have other opinions.

Chris seems to favor Hspice models for doing SSN simulations (certainly 
an option), Gary is a proponent of Eldo, AMS and n-port package models  
does anyone else have  opinions on what  other  solutions for SSN 
simulations (or what works for them) are out there that can be utilized 
today (are IBIS 3.2 models "good enough" for SSN today??) ?

Regards,

-Ray

Senior Signal Integrity Staff Engineer
Advanced Package Development R&D
Xilinx  Inc.
------------------------------------------------------------------
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: