From: Mirmak, Michael Sent: Tuesday, September 14, 2010 2:31 PM To: IBIS-Interconnect Subject: 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@freelists.org ====================================================================== 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.