[ibis-interconn] IBIS Interconnect Task Group Sept. 1, 2010 Minutes
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
- Date: Tue, 14 Sep 2010 15:30:53 -0600
======================================================================
IBIS INTERCONNECT MODELING TASK GROUP MEETING MINUTES
http://www.eda.org/ibis/interconnect_wip/ (note new URL)
Mailing list: ibis-interconn@xxxxxxxxxxxxx
======================================================================
Wednesday, Sept. 1, 2010
Attendees:
----------
(* denotes present)
Agilent - Radek Biernacki, John Moore, Ken Wong
Ansoft - Denis Soldo
Cadence Design Systems - Terry Jernberg, Brad Griffin, Dennis Nagle*
Cisco Systems - Mike LaBonte
Green Streak Programs - Lynne Green
Hewlett-Packard - Rob Elliott
IBM - Greg Edlund
ICT-Lanto - Steven Wong*
Intel - Michael Mirmak*
Mentor Graphics Corp. - Arpad Muranyi*, John Angulo*, Vladimir
Dmitriev-Zdorov
Micron Technology - Randy Wolff, Justin Butterfield*
Sigrity - Sam Chitwood, Raymond Y. Chen, Tao Su, Brad Brim*
SiSoft - Walter Katz*
Teraspeed Consulting Group - Bob Ross*
========================================================================
No patents were declared.
During Opens, Bob Ross noted that the IBIS-ISS draft, page 16, contains
a table of first characters. The X character was omitted. Michael Mirmak will
investigate and make corrections as needed.
In response to an AR, Michael explained scaling of individual components and
what is supported in current SPICE variants. Walter Katz elaborated on the
M and S parameters, noting that M is treated as a parallel multiplier.
Walter asked whether scaling for interconnects is needed. Arpad additionally
asked
whether this affects electrical parameters as well as physical parameters (e.g.,
capacitance as opposed to transistor-based capacitor width). Walter suggested
that scaling not be supported in ISS, similar to how the M multiplier is not
supported. Arpad added that he knew of SPICE variants that may use scaling for
electrical information. Bob noted that, without good documentation, we can't
even propose using it. Michael added that the involvement of .option (and
that it is prohibited in IBIS-ISS) somewhat kills the idea anyway.
Bob suggested that only a few lengths may be affected in ISS. Arpad stated that
may we add .MODEL definitions for resistors, etc. later, so this may have use.
Michael will investigate offline.
Michael reviewed a list of MCP key questions. Resolution is needed for the
questions to
determine how MCP will be standardized and its interactions with other
specifications.
Michael asked whether MCP should be a separate file or not. Bob stated that he
prefers
MCP stay a comment block within other files. Brad added that he prefers model
definitions
to be in a single file.
Bob suggested that MCP could be part of Touchstone in comments, using the !
character,
and in ICM, using | . Walter suggested that MCP is not limited to SPICE, but
intended
for the target simulation language/simulator. MCP should certainly support
SPICE
(possibly ISS) and Touchstone.
Michael asked what ensures MCP is a parsable entity. Comments would prohibit
parsing.
The IBIS Open Form manages Touchstone and IBIS-ISS, so we could include them as
non-commented
records.
Walter suggested adding support to Touchstone 3.x. The remaining problem is
getting tools
to bypass MCP in the meantime. Touchstone 2.0 supports an information section,
so it could be
added there.
Brad Brim noted one reason to make MCP a stand-alone file: reuse. The problem
with reuse is
documentation of physical pins and electrical nodes, which carry a node name
(in SPICE,
a name from the node list; in Touchstone, a port number); these might vary from
one design
to the next.
Michael responded that parsability would still be a problem; tools and a parser
would have
to distinguish between MCP comments and non-MCP comments.
Brad suggested that any parser could parse for relevant keywords.
Brad, Bob, Walter stated their preferences for an inline MCP (MCP as part of
other text, rather
than as a stand-alone file). Brad noted that .include enables separate files
if that were needed.
John Angulo noted that .include statements will ensure MCP is inline when the
circuit is flattened.
Otherwise, a mapping to the MCP content would be needed.
Michael asked whether MCP is at the lowest level of abstraction in the SPICE
circuit; this relates
to whether MCP connections are made indirectly through levels of subcircuit
calls and definitions.
Brad responded that MCP is at the lowest level of abstraction and calling other
files isn't needed.
Michael suggested that ISS should include MCP content as an option but what
about other specs? Do
we need to include inline MCP in Touchstone?
Brad replied that Touchstone can be wrapped within SPICE. Michael responded
with the suggestion of
using MCP for node/port mapping in Touchstone.
Michael continued by asking whether MCP and IBIS should be directly linked.
Walter noted that IBIS
does not specify silicon connectivity; only package pins are really known (IBIS
has ground and power).
John added that the [Pin Mapping] keyword tries to address some of the
silicon/pin/package mapping issues.
Walter replied that die bump/pads are directly addressed through [Pin Mapping].
MCP tries to address
this but we don't distinguish between these in IBIS; an explicit die pad
keyword in IBIS would be helpful.
John answered that [External Model]/[External Circuit] can do this, but people
may not like the syntax.
Arpad added that the [Node Declarations] keyword could help the die pad/node
mapping problem when used
to specifically list die nodes.
Michael suggested that EBD and PKG formats would be affected if IBIS is
supported by MCP (or vice-versa); details TBD.
Walter noted that MCP is a nice enhancement to IBIS-ISS, with IBS-ISS existing
because of EBD issues.
Michael asked whether MCP should appear only in .subckt definitions (not
netlists). Brad replied that all x, y
locations are in a physical database, which already includes pin names, etc.
Within the SPICE top-level circuit,
you still need all the mapping information. MCP could therefore appear in both
locations.
Michael noted that the text will assume that MCP isn't restricted to only
appear within .subcircuit.
John added that the definitions suggest MCP is only intended for within
subcircuits. Bob stated that MCP
should not show up twice and that to allow so would be confusing.
Brad explained that SPICE has a set of nodes, which are arbitrary but
electrical; MCP is defining a set of bus
connections, with one bus connecting to another bus, tolerant of node name
changes, node ordering changes, etc.
MCP only has local scope/domain; it doesn't propagate downward to called
subcircuits. MCP's scope is only at
a single level.
Michael asked why this is needed within model definitions as opposed to being
defined by the user in an EDA GUI.
Brad noted an example of having a pin "A1" on PCB vs. a pin "A01" on a package
model. These must be explicitly
tied together or a tool won't automatically do so.
------------------------------------------------------------------
The IBIS Ad Hoc Interconnect Task Group Mailing List
Archives are available at:
//www.freelists.org/archives/ibis-interconn
TO UNSUBSCRIBE:
Send a message to "ibis-interconn-request@xxxxxxxxxxxxx"
with a subject of "unsubscribe"
To administer your subscription status from the web, visit:
//www.freelists.org/list/ibis-interconn
Other related posts:
