[ibis-interconn] Re: IBIS Interconnect Task Group Sept. 1, 2010 Minutes
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>
- Date: Wed, 15 Sep 2010 08:59:32 -0700
Please add to this sentence:
Arpad added that he knew of SPICE variants that may use scaling for
electrical information.
Arpad added that he knew of SPICE variants that may use scaling for
electrical information, and expressed his concern that element
values inside the IBIS-ISS subcircuit may be affected in those tools
without our intention and/or knowledge. We need to prohibit that
by spelling out what is expected and what is not allowed.
Thanks,
Arpad
=======================================================================
-----Original Message-----
From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak,
Michael
Sent: Tuesday, September 14, 2010 4:31 PM
To: IBIS-Interconnect
Subject: [ibis-interconn] IBIS Interconnect Task Group Sept. 1, 2010
Minutes
======================================================================
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
------------------------------------------------------------------
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:
