[SI-LIST] Re: package SSN model accuracy requirements
- From: "Pratt, Gary" <gary_pratt@xxxxxxxxxxx>
- To: <Chris.Cheng@xxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Mon, 14 Mar 2005 09:19:25 -0500
Chris-> Every circuit I dealt with has design tweaks that breaks a
generic behavioral model ...
Gary-> I hear you there!
Chris->... Say tomorrow you can describe the main switching current,
what about the gate voltage modulation. Ah ha, we are going to create
new spec to describe that.
Gary-> That is *exactly* the point of AMS. It is a completely
self-contained language. It provides the vendor complete flexibility
and eliminates the need to go back to the standards committee to
provide, and the tool vendors to support, any new standard or features.
Enhancing the model for any new effects in the next generation device
will become fairly routine once this becomes part of the process. Soon,
nobody will remember the birthing pains, just like no one remembers the
angst when the industry transitioned from schematics to HDLs (or from
paper schematics to electronic; or tape-out (literal reference) to
tape-out (historical reference), etc).
Chris-> ... Why not just let the user have the original circuit and if
it is appropriate, they can always generate the behavioral model
themselves.
Gary-> Since there are so many more users than there are silicon
providers, I would think market forces would eventually push the
solution to that which is most efficient for the users. That would
include characteristics such as simple to use, fast simulation speed,
and reliable convergence.
Chris-> Why would I trust a EDA tool vendor to tell me "this level of
abstraction is good enough" when he/she has no clue of what my circuit
really looks like ?
Gary-> Since the silicon vendor is in full control of an AMS model, they
are the ones to decide if its good enough. No need to trust -- or even
involve -- an EDA vendor. Except possibly for some help getting up to
speed on the new technology. =20
Thanks for your feedback,
Gary
=20
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx]
On Behalf Of Chris Cheng
Sent: Friday, March 11, 2005 1:33 PM
To: si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: package SSN model accuracy requirements
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 ...
Chris->Because that's the way the I/O circuit designers design and lay=20
Chris->it
out. Every circuit I dealt with has design tweaks that breaks a generic
behavioral model. Say tomorrow you can describe the main switching
current, what about the gate voltage modulation. Ah ha, we are going to
create new spec to describe that. How about if the pre-driver is on a
separate power domain and suffer a different SSO modulation... uhh let's
give it another spec or model. You will be going into this infinite loop
of trying to describe a new phenomenon every time a new circuit is
design. Why not just let the user have the original circuit and if it is
appropriate, they can always generate the behavioral model themselves.
But the reverse is not true. Once you confine yourself to what YOU think
is a good behavioral model, critical information may be lost and you
will have no way of verifying it. Why would I trust a EDA tool vendor to
tell me "this level of abstraction is good enough" when he/she has no
clue of what my circuit really looks like ? There are times even the I/O
designer may not be fully aware of the so call secondary effects is
truly secondary until a full detailed model is simulated and analyzed.=20
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.
Chris->BTDT, if I can convince the largest and most conservative Si=20
Chris->company
in the world to do it, there is a way. What security measure is put into
it is something we are not going to talk here.
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.
Chris->If you go back to even those old and dated GTL papers we=20
Chris->published in
the early 90's, there are already measured and simulated SSO analysis
included. The last time I have to make these methodology public outside
my employer is six years ago. That's the only reference I can refer to
since those are the things I can talk about. Things have changed and my
I/O's are getting much faster and complicated. There may be S-parameter
added here and there but overall I feel the basic remains the same.
However, my new employer has no incentive to make the world know what we
are doing so, sorry. No one needs to simulate 64 separate drivers to
understand the worst case SSO. There is a difference between BTDT
designers and EDA tool vendors.
That's all I want to say.
All these constant back and forth on "hey I can do this in SPICE but why
can't you do it in IBIS" and "No no, I can add this to my description
and do the same thing as SPICE" makes me wonder, if at certain point of
time, wouldn't it be easier to just protect the circuit and hand it out
? Remember that Cheech and Chong movie ? "It feels like SPICE, tastes
like SPICE, man I am so glad we didn't step on it"
------------------------------------------------------------------
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
Other related posts: