============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from January 28, 2026 Meeting (* means attended at least using audio) ANSYS Curtis Clark, Wei-hsing Huang, Juliano Mologni Arista Networks Jim Antonellis Broadcom James Church Chipletz Stephen Newberry Intel Corp. Michael Mirmak*, Xiaoning Ye Keysight Technologies Ming Yan Marvell Steve Parker MathWorks Walter Katz* Micron Technology Justin Butterfield Siemens EDA Weston Beal, Arpad Muranyi*, Randy Wolff* Simberian Yuriy Shlepnev ST Microelectronics Aurora Sanna Synopsys Ted Mido, Edna Moreno University of Illinois Jose Schutt-Aine ============================================================================== Michael Mirmak convened the meeting. No patents were declared. During the review of the January 11 minutes, Arpad Muranyi moved to approve the minutes. Randy Wolff and Walter Katz seconded the motion. The minutes were approved without objection. Michael noted that Pete Pupalaikis would be presenting at DesignCon on S-parameter referencing. He accepted the AR to contact Pete, providing contact information to the IBIS Officers, and suggest he present to the DesignCon IBIS Summit. [AR] During review of draft 26 of the Port Mapping proposal, Arpad presented his own markup copy, featuring red-highlighted draft comments; many suggested changes are simply grammatical. Some of these are listed below: - Is the rule correct that non-reference Physical names shall not be used as Group names? This may need to be changed as we support power now. - "Identical name/value pair"; can't have both be identical. Change to value. - "non-zero" should be altered to cover negative values - "determined" -> "defined" - "Where... to be connected" should be "where... is to be connected" - "PCB system" should be changed to also support packages? Michael noted that descriptions of full PCB systems are implied to require reference designators, but this is not parsable. Arpad replied that the Physical aspects go beyond just PCBs (C_comp model, package). Randy suggested that the team revise special cases, but in general the syntax is correct. Michael: OK to have Physical 3 vs. Physical U7.3? Sentence is too strong; change "shall" to "for example", or equivalent. Randy asked whether terminals are grouped, or are pins grouped into terminals? Michael added the question how do you identify a terminal that's not a pin? Randy replied that a terminal can be one or many. Michael responded that everything is a terminal unless we create more syntax for pin descriptions. He added that the text specifies that Type P ports can be grouped but not Type S. Can terminals be Type S or P? The Type parameter is port-specific. Arpad replied that we are just grouping pins. Look at EMD for multi-chip modules, for example. Note that the same concept applies to pads or buffer terminals. We cannot use Group with any Port that isn't Type P. Arpad noted a use of the phrase "and which", which should be split into separate "and" or "which" phrases. He also suggested using a separate reference phrase for descriptions of Physical and Probe parameters. Arpad proposed a new sentence: "Terminals used in Type P ports may be collected into Groups." This is because we are not collecting ports. We are assigning pins, pads, terminals, etc. Arpad added that, in the examples, we should not have U7.3 pin. This should be a name (and is only a name). Randy added that the text should have a definition later. Arpad suggested that the text should have a sentence restricting what can be part of a group name (e.g., prohibiting a period). He added that the asterisk should apply to power and ground, and that this should be clarified in the text. Wildcards are independent of whether Groups are used or not. Michael suggested that one can also use asterisks for Power rails (i.e., the rule statement in the text is incorrect). Arpad suggested Example changes: Example 10 and 11 should be included with and without wildcards. Example 13 shows wildcards on the Port line, which should be checked. Randy noted that the text is effectively creating a group with a wildcard. Michael asked whether this should be allowed. Arpad noted the example of a stacked, 3-die component. In this case, the "port" is actually a signal. Randy added that the EMD here has a number of ground pins collected into one terminal at the EMD side. We have a PDN model with two terminals for ground. Michael observed that the text is "smuggling" a lot of EMD assumptions into Touchstone without defining the syntax. Arpad replied that one needs to understand EMD syntax to properly define a Touchstone model to be used for EMD. Randy added that the text has already listed some of those rules under Data_usage. Michael replied that the text has "backed into'\" a second way to define a group as currently written. The Data_usage EMD rules don't show wildcards at all. Randy asked whether there is a limitation under "Group" later. Arpad asked whether we allow wildcards in the Interconnect syntax. [AR] He noted that EMD does support it. Whatever is supported in one should be in both. The team started reviewing examples. Arpad requested that the negative symbols be placed in single or double quotes. He also noted that several U3 references should instead be U1 (also, there are missing groups in Example 11). Arpad suggested reordering the examples, so that several EMD and several Interconnect examples are shown, but not collected into one "bunch". Arpad moved to adjourn; Randy and Walter seconded. The meeting adjourned without objection.