[ibis-interconn] IBIS Interconnect Task Group Sept. 15 Minutes and Sept. 22 Agenda
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
- Date: Tue, 21 Sep 2010 19:11:53 -0600
======================================================================
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: //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.
Other related posts:
- » [ibis-interconn] IBIS Interconnect Task Group Sept. 15 Minutes and Sept. 22 Agenda - Mirmak, Michael
