[ibis-macro] Re: Question on seeting the EMD direction
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Sat, 28 Jun 2008 19:42:10 -0700
Todd,
I am not sure that we understand each other completely yet...
First, I agree on the simplicity part 100%. But as I said it
before, I think this should be the model maker's choice. Let
me illustrate this with an example.
How many people can you name who turned away from using HSPICE
because it ALLOWS someone to use arbitrary expressions for the
element values like this:
R1 n1 n2 R='ArbitraryExpression'
or for the controlled sources:
E1 n1 n2 VCVS VOL='ArbitraryExpression'
etc..., where the expression may include any node voltages and
branch currents anywhere in the entire netlist?
On the contrary, how many people do you know who turned away
from using Berkeley SPICE because it didn't allow the above
syntax and has numerous other limitations in the direction of
"simplicity"? (You can count me in on this list, and all those
who are trying to shoehorn HSPICE or other proprietary SPICE
into the IBIS external model and external circuit syntax).
Now, the beauty of the above SPICE implementation is that the
user is not forced to use the complicated syntax if they do
not need it or like it. The simple R1 n1 n2 R=50 syntax will
still work. So in general, a well written language does allow
simple things as well as complicated things.
So is HSPICE more complicated than Berkeley SPICE? By all means.
Does that prevent people from preferring it over Berkeley SPICE?
No way... So I have to disagree with you on the statement that
if "...a language that's so flexible and capable it can describe
anything, ... there's a chance no one will want to use it". I
think this is dead wrong. This can only be true for badly designed
complicated languages which FORCE someone to write something
complicated even for the simplest thing they want to describe.
And sorry to rehash this topic again, but I tend to feel about
ANSI-C (as a modeling language for IBIS-AMI) that way. Other,
more modern languages have come a long way to simplify the
programmer's life, and there are times when you can write a
single line of code with the more modern variants of C and
other languages that you can only describe by lots of lines
of code in ANSI-C. But that is a different topic...
Now, as to how we ended up in this discussion? I think this
rathole(?) started with my question in one of the recent IBIS-ATM
meetings which went something like this: How are we going to
decide on the syntax details of the Interconnect-SPICE language?
Are we going to pick the lowest common denominator among all
known SPICE languages (which may be overly limiting) so that
our language could be easily converted any SPICE? If so, what
are we going to do if we need a feature that doesn't exist in
some or any of the SPICE flavors?
Unfortunately we got sucked into this rathole about LTI and
related questions, but I think even if we put that on the
side, the original question would still exist, since Walter's
presentation does discuss some new, never heard before features
(pole/zero, impulse response based T-lines, etc...). What are
we going to do with these elements when it comes to the
translation from our Interconnect-SPICE to a specific vendor's
SPICE?
My concern simply is that writing a new language spec that is
basically a simplified subset of most of the SPICE variants will
not satisfy most of the SI/PI people because most SPICE variants
are more capable. This is why I feel that we may end up wasting
our time on this.
Regarding how soon I want this? The answer is yesterday. The
good news is that we already have two languages that IBIS choose
to embrace several years ago. The netlisting portions of those
is very much like SPICE, and the underlying elements can be made
very much like SPICE as the Macro Modeling Library demonstrated
it years ago. The goal of that library was to make it translatable
to any SPICE by guaranteed compatibility. I agree, we didn't do
too much for the T-lines, but why don't we just focus on extending
that library so that we could do lossy T-lines in any shape or form
(S-parameter, Pole/Zero, Impulse Response, etc...)? Why do we have
to start writing a new spec from scratch?
Arpad
====================================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Saturday, June 28, 2008 9:23 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on seeting the EMD direction
Arpad,
I understand what you're getting at, but I think you haven't
acknowledged the other side of the
problem: define a language that's so flexible and capable it can
describe anything, and there's a
chance no one will want to use it. We've already had that experience
too; it's part of how we got
here.
I'm a big fan of keeping things simple - to me that means taking time up
front to define the problem
clearly and quantifiably, then considering potential alternative
solutions ... at which point I tend
to favor approaches that are simple and flexible. It's not that I don't
believe in designing for
future growth and expansion - it's just that I think designing a
solution for a problem that hasn't
been described yet is a trap. Such a project is plagued by questions
like "well, what if ...", but
it's almost impossible to describe the likelihood that such a situation
will actually occur. At
that point, it's not engineering anymore - it's conjectureering.
SPICE is a good example of something that was designed to solve a
particular problem, with a syntax
that was simple and flexible enough to allow expansion. Of course, one
SPICE became many SPICEs,
became countless SPICEs, which is also part of how we got here.
Walter's EMD proposal, in part, is
intended to give us a common SPICE-like syntax we can all point to. If
we have a language that
allows us to describe connectivity and hierarchy in a standard way, then
(I think) it's just a
matter of choosing the right building blocks and properties. Adding new
building blocks or
properties as needs arise shouldn't be a spec-killer.
The original IBIS approach (table & template-based, with no general
purpose interconnect
description) was designed to solve a very specific problem, and it
solved that problem reasonably
well. S2IBIS2 was also a step in the right direction, because it helped
vendors create models,
although many vendors lacked the resources they needed to develop and
distribute good models.
Where IBIS could have done better was adaptation. The template-based
approach for the push-pull
buffer was a good one, but we all would have been better served if there
was a general purpose
interconnect language to go with it, instead of having of having to
amend the core spec for new
requirements as they came along. We now have a language with lots of
syntax, but too few tools and
developers with enough knowledge to effectively deploy what we have.
The template approach also contributed to the delay in supporting new
features for the customer -
first the language had to be amended, then the tools had to be updated.
That tended to be a pretty
long cycle, and hard to take in the face of accelerating design
schedules.
I don't see that we're headed down that path again, or I would have said
so. I think we need to
define a base set of elements and properties for our first effort.
Getting a first spec together
involves a simple tradeoff - the more building blocks and properties you
want, the longer definition
and debate takes. How soon do you want a usable spec?
... which brings me back to point 1. We need to spend more time
defining the bounds of the problem
we're trying to solve.
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
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi,
Arpad
Sent: Friday, June 27, 2008 3:39 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question on seeting the EMD direction
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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:
