[SI-LIST] Re: package SSN model accuracy requirements
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: <si-list@xxxxxxxxxxxxx>
- Date: Fri, 25 Mar 2005 09:23:09 -0800
Chris,=20
I only want to reply to one thing now. Regarding the rest of the
conversation, I feel we are in a bottomless pit, spiraling down
endlessly. I think it is time to quit and do some work, so that
we won't have to wait seven more years for better models to come
out... With this I am telling you now, upfront, that I am going
to stop responding to your messages (unless we change subjects),
but this is not because I ran out of answers... I just simply
don't think it is worth our time to continue with this.
Your quote from Michael actually supports what I told you before.
Michael says that "IBIS ... does not include enough data to provide
a consistent power integrity result between tools" tells me that you
CAN use IBIS for power integrity (or SSO), but the results are not
consistent between tools (i.e. there is room for improvement). You
said "IBIS can't do it AT ALL". Not being able to do something
AT ALL and not being able to do something CONSISTENTLY are two
different things, as far as my English understanding goes...
Elsewhere you said that you would rather have something than nothing,
so there, IBIS CAN give you something as far as SSO is concerned...
I agree, there is a lot of room for improvement, but the IBIS
committee is working on that as we speak.
Sincerely,
Arpad
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] =
On Behalf Of Chris Cheng
Sent: Thursday, March 24, 2005 6:50 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements
One thing I have to agree with your, none of us have any time left to =
get
into this infinite loop of endless "my **** is better than your ****". =
As
long as I am getting encrypted HSPICE from vendors today, I could care =
less
Joe engineer thinks IBIS is all he needs.=20
>Your assessment that IBIS can't do it at all is plain wrong.
"On IBIS and SSN: many in the industry recognize that, for effects such
as SSN, traditional IBIS (3.2, 4.0) today does not include enough data
to provide a consistent power integrity result between tools."
I didn't say the above, Michael did.
And for the last time, NO ONE in Si-list response saying he/she is doing =
SSO
analysis with IBIS today. How many tools out there really support the =
latest
spec of IBIS 4.x anyways ?
You can't dance around the encryption issue because that was one of the
biggest reason IBIS exist in the first place.=20
Call it SPICE or AMS, at the end of the day, you can't be accurate =
enough on
your model without someone in your chain of command thinks that's too =
much
IP and you need to encrypt the information.
And do you really think all favors of Verilog-AMS, VHDL-AMS with =
different
encryptions for different vendors will really fly ? With your busy =
schedule
between real design work and your IBIS meetings ?
Call me crazy, I've design plenty of big irons with SPICE and I never =
felt
its slowest hinder my work, I am more worry about garbage models that =
lead
me to incorrect results. If tomorrow you can show me an AMS model that =
can
simulate SSO on drivers accurately, I'll take it. But so far Gary's =
example
is no more than a two pass simulation with digital verilog simulation
feeding into a SPICE level=3D1'ish transistor model and S-parameter. And =
your
example is just a mix of couple of IBIS drivers pumping current out at
different time. None of this address the problem with SSO noise. Unless =
we
think that's not any issue, you haven't even start to address the =
problem. I
can take a few standard IBIS driver models, run a digital verilog
simulations and pump the different drivers at the output based on the
verilog timing and I can get the same results. What's so special about =
it ?
It doesn't address the problem of SSO noise. I think at this time you =
and
Gary will probably say "but hey, I can modify this and that and it will =
do
the job". Here lies the problem, if you and Gary are already the =
bleeding
edge of AMS users and both of you still can't generate the SSO model, =
how
long do you think the rest of the app engineer crowd can catch up the
methodology ? I hope its not seven years.
I am really glad Al actually make his presence in Si-list. May be he can
share with us how long since he did those SSO analysis on IBM TCM =
modules.
To see us little disciples still struggling to figure it out will =
probably
make him laugh. But it also tells us how slow the entire industry is =
moving.
A promising technology may be great but let's not loose sight we need to
address a lot of problems today.
Arpad, you should know better I can make any methodology you throw at me
works. SPICE BTDT, behavioral BTDT. AMS, no problem, I am sure I can =
make it
work also. But can you say the same about the Joe app engineer of the
majority of the industry ? Why can't there be a SINGLE IBIS SSO model
generated and people are using it today ? Is there no SSO problem today =
?=20
Up to this point IBIS has some reasonable strict definition, I-V curves,
package parasitics etc. It may not be good enough for SSO but at least =
we
all know where/how it comes from. If tomorrow everything becomes this
magical AMS model and all users see is a bunch of equations, who is =
going to
guarantee the accuracy or the methodology used to abstract it from SPICE
(which I believe is what 100% of Si I/O designers use) to AMS ? I've ask =
you
previously already, how do you determine what kind of abstraction is =
good
enough for what kind of application ? Can it even be defined ? If the =
answer
is no, who is going to guarantee the level of accuracy ? HSPICE may not =
be
good, but at least I've never heard of any Si vendor unwilling to =
correlate
their process with it because, like it or not, it is considered a de =
facto
industrial standard. Can you say the same about all those AMS =
abstractions
that will exist in the future ?=20
I am a practical man, if tomorrow AMS is the heat it claims to be, I =
will be
the first to jump on it. But you have to show me a single case where the
average Joe app engineer can hand out an AMS model with SSO model first. =
Can
you ? I am not talking about "I think it can be done this way", I =
talking
about "here is the I/O with SSO model, here is a scope picture of actual
measurement of SSO of the I/O and here is an AMS simulation that matches
it".
I will be waiting for that picture.=20
And how long do you think the rest of the industry will show me that =
kind of
pictures ? Please don't tell me another seven years.
------------------------------------------------------------------
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:
