====================================================================== IBIS INTERCONNECT TASK GROUP MEETING MINUTES AND AGENDA http://www.eda.org/ibis/interconnect_wip/ Mailing list: ibis-interconn@xxxxxxxxxxxxx<mailto:ibis-interconn@xxxxxxxxxxxxx> (archive: http://www.freelists.org/archive/ibis-interconn/) ====================================================================== Next Meeting Wednesday, September 22, 2010 9 AM US Pacific Time Telephone Bridge Passcode 916-356-2663 5 646-9283 (for international and alternate US numbers, contact Michael Mirmak) LiveMeeting: https://webjoin.intel.com/?passcode=6469283 Agenda: - Attendees - Call for patents - Opens - Presentation on Mixed-Signal Coverage in MCP (T. Kukal) - MCP Comments Review and live editing (NOTE: this is a change to our usual meeting alteration between MCP and ISS discussions, in order to accommodate attendee schedules) ====================================================================== Minutes from September 15: Attendees: ---------- (* denotes present) Agilent - Radek Biernacki, John Moore, Ken Wong Ansoft - Denis Soldo Cadence Design Systems - Terry Jernberg, Brad Griffin, Dennis Nagle*, Taranjit Kukal* 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, Michael Mirmak noted that the web page for the Interconnect Task Group had been updated with the latest documents and minutes sets. In addition, the file location has been moved from "adhoc" to a permanent location, though a virtual link remains for those with older URLs. The web pages also now feature a direct link to the mailing list archives. A fix to the existing mailing list footers plus updates to the September 1 minutes are still in progress. Taranjit Kukal noted that MCP has been implemented in a Cadence tool, and support includes extending MCP to include analog content and mixed signal coverage. Kukal will present details in the next MCP meeting. Michael reviewed the draft MCP document. Kukal mentioned that the Signal Nets will be more like extended nets, therefore, MCP needs two net names with shorting 0-ohm resistor to ensure connectivity. Michael responded that the shorting is assumed by MCP's structure. Kukal suggested waiting for Brad Brim to be able to participate, as the original proponent of MCP, to explain the concepts correctly. Michael added that a diagram would be most helpful in clarifying the structure of MCP and how it's used. John Angulo added that something other than declarations may be needed to ensure correct interpretation. In response to a query from Michael on where MCP should go, Bob Ross proposed keeping MCP as an independent document. It could therefore fit into any SPICE variant. John added that MCP might naturally fit into ISS. Arpad asked whether, if the goal of IBIS-ISS was to unify behind a universal SPICE format, MCP could be linked to ISS. ISS is not a SPICE variant but should be viewed as *the* SPICE standard. Bob responded that MCP could end up in proprietary implementations for PCB purposes. Michael initially noted that MCP "calls" Touchstone but this was later corrected, as the MCP document examples don't include Touchstone as part of MCP proper. ISS calls Touchstone; ISS can therefore call MCP. Michael voiced his concern that MCP keywords are commented out, therefore overloading the comment character and forcing parsing of comments and MCP comments as separate. Bob noted that the idea here is that tools understand MCP syntax within comments. The ultimate user is the tool user, as the EDA tool creates/adds MCP syntax automatically. John added that the comment character makes it easy to "piggyback" on SPICE syntax without having an MCP understanding within SPICE. Randy Wolff asked whether we need a comment-definition keyword as in IBIS. Michael noted that he was uncomfortable with using a comment character outside its intent and relying on SPICE assumptions to define a new function. We now have a spec within a spec; therefore a parser within a parser will be needed. Bob noted that MCP and similar variants in the approach have already been widely adopted. Walter Katz added SPICE tools don't read this; EDA tools do. Note that there's an alternative way to give exactly the same information, which is to make this all keyword-driven: [Power Net] A01 [Power Net] xxx, etc. such that everything between the keywords would be unambiguous and would not conflict with existing comments; each line starts with some sort of designator. Michael asked whether MCP should be analyzed through a separate parser or within an ISS parser. Walter responded that they should be separate. John agreed, adding that perhaps future revisions would allow ISS direct support without comments. Walter responded that the industry could eventually view ISS as a pre-processed format, with translation to proprietary format internally to tools. John suggested that MCP is a "decorator" of SPICE subcircuits; one can, for example, already call Touchstone from SPICE subcircuits but having MCP information in Touchstone file might be useful. Michael asked whether the node-to-port mapping concept in Touchstone would therefore become unnecessary. Bob noted that the discussion assumed that MCP adopts the local comment structure. Walter responded that this was explicitly stated. Bob asked whether [REM] should be used wherever MCP is present. The team found mention of [REM] usage rules in the current draft. Local tool comment characters may be used in most places, except the net listing itself. Arpad asked about the dangers of using the local tool's comment character, as this might eliminates portability of MCP. Michael responded that the MCP concept is challenging because one has to think of connectivity outside of generation/distribution of separate files. Walter suggested that, at time of SPICE deck generation, MCP is inserted. This would occur at the GUI level, to help tool connectivity. Proprietary variants of MCP now exist that are functionally equivalent. Michael responded that a flowchart as part of the introduction to the document would help explain the usage model.