[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




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


- 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:



(* 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 

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 

Michael initially noted that MCP "calls" Touchstone but this was later 

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 

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 

[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 

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