[ibis-macro] Re: Question on setting the EMD direction
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <kumarchi@xxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 3 Jul 2008 15:59:41 -0400
Kumar,
You enumerated the exact reasons why others have failed, and then you
suggest doing to EMD exactly what caused other attempts to fail as well.
First, ?However i am not sure why IBIS will succeed here now ; since we have
had various "standards" so far (spice, vhdl, vhdl-ams, and most importantly
a host of propitiatory languages).?. That exactly the point, every one of
the ?standards? you described is either not really standard or is propriety.
Second, ?what about geometrical, timing, logical??. In every presentation I
have given, after carefully limiting the scope of the problem to
interconnect, several members of our committee want to add V elements, or
transistors, or want to expand it into other SPICE capabilities. As soon as
one leaves the realm of passive interconnect the problem expands
geometrically.
Third, ?it is obviously a big task?. No, not if we limit it to the scope of
what I have proposed.
Fourth, ?what is ibis bringing fundamentally different and compelling to the
table??. There is going to be a package modeling solution by the end of the
year. If IBIS does not do it, someone else will. The need of the industry to
get accurate models to simulate 3-10GHz is compelling.
Are you representing your own personal thoughts, or are you representing an
IBIS member?
Walter
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of C. Kumar
Sent: Thursday, July 03, 2008 3:23 PM
To: Arpad_Muranyi@xxxxxxxxxx; IBIS-ATM; michael.mirmak@xxxxxxxxx
Subject: [ibis-macro] Re: Question on setting the EMD direction
it is a fine idea to have a universal interconnect/buffer modeling language
(i.e language which can express connectivity). However i am not sure why
IBIS will succeed here now ; since we have had various "standards" so far
(spice, vhdl, vhdl-ams, and most importantly a host of propitiatory
languages).
also to be meaningful the language has to support some view(s)., meaning it
cannot be a simple connectivity; it may have to support electrical (which we
are familiar with). what about geometrical, timing, logical?
it is obviously a big task (even if it starts small it will certainly grow
big). I am not sure why IBIS will succeed while others have not (at least
based on the authors expectations); also what is ibis bringing fundamentally
different and compelling to the table?
--- On Thu, 7/3/08, Mirmak, Michael <michael.mirmak@xxxxxxxxx> wrote:
From: Mirmak, Michael <michael.mirmak@xxxxxxxxx>
Subject: [ibis-macro] Re: Question on setting the EMD direction
To: Arpad_Muranyi@xxxxxxxxxx, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
Date: Thursday, July 3, 2008, 3:03 PM
Arpad,
As a very delayed response to your question, I can only repeat what I
have said at previous summits and teleconferences: for advanced systems,
being able to provide component models is often insufficient to assure
customers of their correct *usage* in a system. For some types of
topologies, providing entire topology netlists or descriptions is
preferable (in most cases, this also allows customers to start using a
set of models "right out of the box" and eases construction of
variations).
Today, we have no
universal netlist format or language. So, anyone
interested in distributing netlists is forced to build separate
topologies in many individual tools, or simply select a single tool to
support.
As I mentioned earlier, this is subtly distinct from agreeing on a
modeling format for each of the components in the netlist. However, I
would find it hard to believe that someone constructing netlists would
select a universal format to express the netlist if the model format for
each individual netlist component weren't also supported in the tools of
interest.
- MM
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, June 25, 2008 11:01 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Question on seeting the EMD direction
Mike,
Thanks for your comprehensive summary and comments.
I think
you are absolutely right at the end when you
say that ICM was not intended to do A and B. In fact
the entire IBIS philosophy didn't have that intension
as far as I can tell. I believe our philosophy was
to provide the models and let the tool do any of the
netlisting. This makes me wonder, why are we all of
the sudden talking about the need for netlisting?
I guess the answer may be that we are starting to have
a need to ***MODEL*** complicated packages, cables,
connectors which can't be described without a good
netlisting syntax. (Is this correct)?
But then are we going to limit ourselves to this kind
of MODEL-netlists only, or are we going to need to
generalize and allow (or request) tools to spit out
an entire design (e.g. motherboard) in the future
IBIS-netlist format? In other words what should be
the scope of this
effort?
Thanks,
Arpad
======================================================
-----Original Message-----
From: Mirmak, Michael [mailto:michael.mirmak@xxxxxxxxx]
Sent: Tuesday, June 24, 2008 1:46 PM
To: bob@xxxxxxxxxxxxx; wkatz@xxxxxxxxxx
Cc: Muranyi, Arpad; IBIS-ATM
Subject: RE: [ibis-macro] Re: Question on seeting the EMD direction
Per Arpad's request, here are a few comments on the EMD direction:
1) If we are limiting ourselves to representations of interconnects
(cables, connectors, etc.) convertible to existing proprietary formats,
the elements in the EMD proposal are certainly required. However, some
types of controlled sources may also be needed for these applications.
For example, tools that convert S-parameters to rational functions by
approximation or fitting often represent the fitted response as a
circuit with controlled sources, even for entirely passive
design
elements, such as vias.
If we wish to support generic subcircuits that might result from
rational function approximation of S-parameter data, controlled sources
are a requirement.
2) We should seriously consider support in the near future under EMD of
non-interconnect circuits. In some cases, behavioral modeling of
buffers is easier with SPICE elements and function-based sources than
with traditional IBIS (leaving multi-lingual IBIS aside, behavioral
SPICE modeling makes continuous sweeping or control of parameterized
variables easy, where traditional IBIS forces generation of new keywords
or model data under [Model Selector]; this was discussed briefly at the
IBIS Summit on the 10th).
3) Let's ensure that we are not undergoing "mission creep." From
the
IBIS-ATM discussions and these reflector exchanges, several needs have
emerged that *some* IBIS-like standard(s) should
address:
A) generic, SPICE-like descriptions of system topologies, for exchange
of netlist information between tools
B) generic, SPICE-like wrappers or other representations of existing
interconnect model types
C) flexible SPICE-like modeling of interconnects (cables, connectors,
PCB traces, vias, etc.), including easy support of S-parameter swathing
Note that (A) and (B) are very similar, but are distinct in a subtle
way. In (A), we are essentially standardizing a description of
node-to-node connections. What's being connected isn't relevant and
doesn't need to be specified. This means that new kinds of models can
easily be added, so long as they have some nodal connections to the
"outside world."
(B) is different, and seems to be the current direction of EMD. A list
of existing "native" model types is assumed, and generic
representations
for them are under discussion. This makes
conversion from a generic
format to a tool-specific format easy. However, it does not necessarily
allow for *new* model types, unless a very generic subcircuit definition
syntax is included. For example, no "native" element exists for the
broadband interconnect representation proposed by Brad Brim of Sigrity
during his IBIS Summit presentation. Unless a native element were added
later, it would always have to be included as a generic subcircuit.
Solutions for (A) and (B) do not exist in a standard way today, so EMD
could cover one or both and fill industry needs very well. Partial
solutions to (C) exist, but as discussed so far, the existing solutions
are not necessarily optimally easy to use or don't cover all of today's
technical needs. To be more direct, for interconnect-specific modeling
(type (B)), ICM exists and was meant to enable exchange of RLGC and
S-parameter data in a generic way. It also
supplies information on
mapping of matrix data to signal names and nodes. However, it lacks some
fundamental capabilities:
- swathing is not permitted on S-parameter data
- some series elements are not supported at all (i.e., series
capacitances) unless S-parameters are used
- the data format is not compact; for larger components, the file size
can get unwieldy fast, due to newline requirements
- S-parameter and RLGC data cannot be combined in the same interconnect
- section-to-section RLGC coupling within the same line is not supported
(see B. Brim's IBIS Summit presentation)
- the mapping of S-parameter ports (really, pairs of nodes) to netlist
nodes (single physical points) is not clear, particularly on references
The last item has been addressed in a draft change to ICM, but was
placed on-hold until Touchstone 2.0 was resolved. With the exception of
section-to-section coupling, all the rest of
the items can be addressed
with fairly straightforward specification changes.
The key question is whether fixing ICM is worth the effort relative to
creating a more generic format for interconnect modeling that addresses
these issues.
So, is it? Personally, I believe it is, but only for type (C). ICM was
not intended to accomplish (A) or (B) and should be supported in any
format that includes (A) or (B).
Comments are welcome.
- MM
---------------------------------------------------------------------
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:
