[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


http://www.eda.org/ibis/interconnect_wip/ (note new URL) 

Mailing list: ibis-interconn@xxxxxxxxxxxxx  


Wednesday, Sept. 1, 2010

(* 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 
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 
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 
Michael asked whether MCP should be a separate file or not.  Bob stated that he 
MCP stay a comment block within other files.  Brad added that he prefers model 
to be in a single file.

Bob suggested that MCP could be part of Touchstone in comments, using the ! 
and in ICM, using | .  Walter suggested that MCP is not limited to SPICE, but 
for the target simulation language/simulator.  MCP should certainly support 
(possibly ISS) and Touchstone.

Michael asked what ensures MCP is a parsable entity.  Comments would prohibit 
The IBIS Open Form manages Touchstone and IBIS-ISS, so we could include them as 

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 

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:

        Send a message to "ibis-interconn-request@xxxxxxxxxxxxx"
        with a subject of "unsubscribe"

To administer your subscription status from the web, visit:

Other related posts: