[ibis-macro] Re: Question on seeting the EMD direction
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, <twesterh@xxxxxxxxxx>
- Date: Sat, 28 Jun 2008 12:02:23 -0400
Scott,
We do know what the spec will be used for!
Both in my original presentation on April 4, and in the review I gave on
June 24 I included the following slide:
Module Interconnect Modeling Requirements
? Signal Interconnect Modeling
? Signal Coupling (crosstalk)
? Power Distribution
? Rail voltage AC coupling
? DC drop
? Bed Spring Model
? Voids, cutouts, islands in planes
? Coupling between Signal Interconnects and Power Distribution (SSO)
This is what the spec is to be used for. This slide was discussed in detail
during the April 4 and subsequent meetings, and was modified at the request
of some committee members.
Does this require any additional definition?
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of Scott McMorrow
Sent: Saturday, June 28, 2008 11:41 AM
To: twesterh@xxxxxxxxxx
Cc: 'IBIS-ATM'
Subject: [ibis-macro] Re: Question on seeting the EMD direction
"I think we need to define a base set of elements and properties for our
first effort."
I disagree. I suggest that we first agree on the scope of the
specification. Once that is agreed on, the elements required will
follow. We need to know what the spec will be used for before we design
the engine and chassis.
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed(r) is the registered service mark of
Teraspeed Consulting Group LLC
Todd Westerhoff wrote:
> 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
---------------------------------------------------------------------
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:
