============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from July 1, 2026 Meeting (* means attended at least using audio) Chipletz Stephen Newberry* Intel Corp. Michael Mirmak* MathWorks Walter Katz* Siemens EDA Weston Beal, Arpad Muranyi*, Randy Wolff* Synopsys Ted Mido, Edna Moreno ============================================================================== Michael Mirmak called the meeting to order. No patents were declared. Michael reviewed the minutes of the February 18 meeting. Arpad Muranyi moved to approve the minutes; Randy Wolff seconded. The minutes were approved without objection. Michael reviewed the minutes of the March 4 meeting. Arpad Muranyi moved to approve the minutes; Randy Wolff seconded. The minutes were approved without objection. Michael mentioned the IBIS Summit in Turin, Italy. While he delivered a Touchstone 3.0 and Port Mapping summary presentation at the Summit, no comments or feedback were received during or after the event. Michael presented a summary of terms appearing in IBIS 8.0, focused on "net" and "extended net". He noted that over 300 instances of "net" appear in the specification text. Arpad asked whether a search specific to the whole word "net", as opposed to variants such as "network", was conducted. Michael stated that even singular instances of "net" still number around 100 in the document. Michael asked whether writing BIRDs for EMD and IBIS Interconnect referencing expansion, plus net clarifications means that the Interconnect Task Group should hold development of Touchstone 3.0 until these BIRDs are approved. Arpad asked about the logistics of such an approach: should we time the votes for the same day? Does this scale of change warrant going to IBIS 9.0? Would an IBIS 8.1 with PI plus corrections to examples and reference corrections be sufficient? Michael noted that the new IBIS Open Forum membership approach means that parser update rules have changed for major releases. The new metric may be how much EDA vendor work is required. Arpad replied that some work for the netlisting part of EDA tools would still be required; this should be less than the work needed to support the new power integrity features. Walter Katz suggested that the referencing changes are simply the Touchstone return path. Tools figure that out based on an appropriate local ground. There are no issues there, and no issue with mating Touchstone files to Touchstone files. The limiting issue is interfacing SPICE and Touchstone, where SPICE has ground terminals. Arpad stated that he does not like the "CAD net" language in the current IBIS document. Walter replied that a CAD net is a thing that is shorted together; a net is in the eye of the beholder Arpad noted that "CAD net" is used at least once; Randy added that the usage is in the same section as "extended net" is used. One distinction to note is between parallel vs. series terminations; are these both extended nets? Arpad added that ferrite beads become a question here. Walter noted that a distinction exists between rail nets and extended nets. Connections between a power and signal net would not be an extended net. Randy noted that there were no technical Known Issues with IBIS 7.2 or 8.0 that would affect this issue. Arpad asked whether a signal name clarification BIRD would be needed. Michael replied that a clarification for signal name vs. net is likely needed. Are they the same? Arpad noted that, in the package RLC days, the package is a series element between pins and pads. On the two sides of that "box", they are all extended nets. In IBIS terminology, this is always a signal name and an extended net. Michael asked whether an extended net like a superset group name in a database with unlimited net names subsumed within it. Walter noted that we have a board layout, a package layout, and a die layout. Arpad stated that, if the designator is another EMD that could do weird things, the extended net becomes crucial. What comes back from a designator could connect to another designator; the input and output paths from various sub- blocks can be complex. This is not a problem in IBIS with the 1-to-1 assumption. In EMD, the signal name approach is different; it identifies where the signal goes from ball side to designator side, but doesn't go from designator to designator (it may be a different signal name). Randy replied that this is the only thing that needs to be fixed in EMD. Arpad asked for clarification: the fix is to the definition of signal name? Randy replied that only the item identified by Arpad for extended net needs a fix. Arpad reviewed the original issue flagged by one of his customers, as requested by Walter. Walter noted that the right approach is shown in the bottom-left corner of Arpad's diagrams; only two extended nets should be created. We often have this problem in layout with muxes. Arpad suggested that we don't know the signal path in that case. Randy noted that the document has a statement that EMD tools have to figure it out. Arpad replied that, for signal name, the format of the pin lists in EMD were grandfathered from IBIS [Pin] or [Pin Mapping] keyword. At the time, we did not think of this complication. Michael stated that the team should check that Net in Port Mapping is sufficient to cover both nets and extended nets. Michael took the AR to send draft 30 to the reflector. [AR] Arpad moved to adjourn the meeting; Walter seconded. The meeting adjourned without objection.