[ibis-macro] Re: Question on seeting the EMD direction
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 27 Jun 2008 00:39:25 -0700
Todd,
Good question regarding what I was getting at with
my last point. I will try to summarize it briefly.
Having had the "IBIS experience" multiple times over
(criticism that IBIS is not as accurate as SPICE,
ICM can't do this and that, etc...) I would think
twice before I wrote a new spec to avoid a similar
experience later again, so I tend to ask myself more
general questions about what makes our specs so useless
in some people's minds?
The fundamental problem I see in most of our IBIS and
related specs is that the modeling language they describe
have "built-in" limitations (intentional or unintentional)
and a lot of hard coded stuff.
While I agree that not all models we write have to be
valid all the way out to 1000's of THz and include all
non-linear and time variant effects, I think the choice
should be up to the model maker, and not a limitation
of the language. Don't forget, we are trying to write a
language specification here, not the models... A modeling
language always has to be more capable and flexible than
the models people want to write with it at any given time.
Or as a minimum, the language has to be extensible so that
at any given time more capabilities could be added to it.
However, we are already talking about fundamental limitations,
such as assuming that this language will be used for
interconnects ONLY, everything is LTI, element values are
constants (during the simulation) which may be hard to
remove at a later time if there was a need for something
that is outside our predefined limitations.
So when we are talking about writing a new Interconnect-SPICE-like
specification that is basically a subset of what the existing
languages are already offering, I ask myself the question:
Does the world really need another limited, specialized, and
inflexible modeling language, most of whose features (plus
more) already exist in other languages?
(I know, there are a few novel technical features we want to
put into this new language which don't exist elsewhere, but
there may be other ways to make those available for ourselves).
As a (ridiculous) analogy I would ask the question, would it
make sense to write a new standard for a programming language
which is C-like, but is limited to draw only rectangles on the
screen because we decided that for our purpose the world is
rectangular? I am sure we will be able to draw beautiful
rectangles on our screens, but if someone comes along and
needs to draw them with rounded corners, they will start
complaining. So was it worth it to invent this new standard
language as opposed to figure out ways to make the more
universal C language available for our purpose?
Arpad
===============================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Thursday, June 26, 2008 10:53 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on seeting the EMD direction
Arpad,
Not sure what you're getting at with your last point.
I think the first challenge we have with an interconnect modeling spec
is defining the problem we're
trying to solve, the intended applications and what assumptions we're
willing to make. Drawing from
an example earlier today, we need to state our assumptions about how
things like temperature and
process are represented.
There are two fundamental approaches to modeling interconnect as I see
it:
1) An electrical equivalent modeling approach, providing a simulation
model that is precise and
accurate enough for an intended purpose
2) A physical description approach, describing the actual materials and
geometries so that
simulation tools can extract their own electrical equivalent models as
needed
We've been talking about the first approach with EMD and ICM.
One challenge with simulation is the tradeoff between speed and accuracy
(actually, the tradeoff is
between speed and precision, but that's another discussion). Model
detail is one of the key
enabling elements of increased *precision*, and thus always gets caught
up in the argument. The
usual challenge to a given level of modeling detail is "yeah, but your
model doesn't represent such
and such a physical effect, and therefore it isn't accurate enough".
Here as before, we would be
better served if we distinguished between precision and accuracy.
The level of detail required is case-dependent, which is what makes
these discussions so difficult.
If you have a system that's close enough to the edge, physical effects
that don't matter in 9 out of
10 systems will still be the difference between success and failure in
that one case. If you try to
create the system (or language) that can represent any possible case,
you'll probably end up with a
system (or language) that no one wants to use (which is what I think
Mike was getting at).
So now what?
If I've followed the discussion correctly, thus far we've said we're
interested in created a spec
for modeling interconnect at the electrical level. I think we should
spend some more time hashing
out our mission statement - are we modeling interconnect for any purpose
at all? Over what
frequency range? For what purpose (for example, if we said we wanted to
model serial links for
periods < 10**17 bits, how big a factor would temperature variation be)?
The practical aspect here is that the more succinctly we can define our
mission statement, and the
more clearly we can articulate intended applications and fundamental
assumptions, the greater our
chance for success will be. If we can't clearly articulate these
things, then we're taking on a
very big task indeed.
Todd.
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
---------------------------------------------------------------------
IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/
IBIS Macro reflector: //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
To: ibis-macro-request@xxxxxxxxxxxxx
Subject: unsubscribe
Other related posts:
