============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from August 5, 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 June 3, 2026 meeting minutes. Arpad Muranyi suggested a change to the minutes, replacing the phrase “with expanded ground support” with “with expanded reference terminal support”. Arpad moved to approve the minutes with this change. Randy Wolff seconded. The minutes with changes were approved without objections. Michael reviewed the June 10, 2026 meeting minutes. Arpad noted two typographical errors: "mdoels" and the phrase "could have add data". Arpad moved to approve the minutes with this change. Randy seconded. The minutes with changes were approved without objections. Michael reviewed the July 15, 2026 meeting minutes. Arpad noted several corrections were needed: 1) The phrase, "Net is a wire; net is short for network" should be changed to something approaching: "Net is a wire; a network is a collection of circuit elements connected with wires." Arpad also noted that the correct spelling of "HyperLynx" throughout the minutes should include a capital letter "L". He also suggested changing the phrase: "Arpad added that he consulted a board layout tool that used the KiCAD database;" to: "Arpad added that he checked the KiCAD board layout tool with the associated schematics;" In addition, he pointed out that the name "NG SPICE" should not include a space. Arpad moved to approve the July 15 minutes with the suggested changes. Randy seconded. The minutes were approved without objection. Michael showed a summary presentation on wildcard usage in both IBIS (for EMD) and Touchstone 3.0 Port Mapping so far. He proposed some simple language additions to clarify how wildcards should apply to power port declarations (as opposed to signal ports). Arpad noted that, in his comments prepared during review of Draft 30, there is a discussion of wildcards. The text is quite short where wildcards are discussed; he suggested Michael look at them. Randy asked whether the wildcards are trying to indicate all the GND at the die. What is the GND reference terminal? Is this terminal intended as the reference for the entire PCB? This is unlikely unless your model is only valid to 100 MHz. Michael asked whether we want indirect declarations of ports (meaning through Reference) rather than using the Port parameter. Randy added the question regaring whether we want to stick with Group, not Bus_label, if this isn't actual EMD syntax (it's "EMD-like"). Arpad added that this applied to EMD too. Arpad asked what text would be present in place of * if wildcards were not availble. Would this be U1.gnd, U2.gndj, etc.? Would this replace all the reference designators? Randy additionally asked whether these are just ground at the die. Arpad asked whether GND is actually a bus_label. Michael asked whether we can declare a terminal without an explicit name. Randy observed that there can only be pins in EMD; there is no die concept in EMD. Arpad added that bus_label is not present in the IBIS file, but is instead present in the EMD pin list. You can declare an EMD pin or a designator pin. If the bus label is not there, the signal name is the bus label. Michael asked whether, in the context of a model-maker or reader, should Port Map data be self-contained and self-explanator or do you have to have the EMD in front of you to understand the map? Arpad replied that "U1.A1" does not have to be defined, for example, in the Port Map; just in the EMD. The limitation in EMD references is the side, not the name; the designator pins vs. EMD pins use different references, even though they use the same name. Michael took the AR to clarify the language in Port Mapping to spell out that Type S references can use wildcards, just not Type S ports. [AR] Michael showed an initial version of Draft 31, from which he had removed all "-like" examples. Randy noted that Example 16 could be modified to use a wildcard without using EMD-like structures. Arpad added that wildcards can only be applied to EMD pins, not designator pins. Without two different references, you can't have a global wildcard. Randy suggested keeping Example 16 unchanged but adding a variant with wildcards, replacing part of these ports with wildcards and the ":" character: Port 163 (Type P)(Physical U1.VDD)(Side Die1) (Net VDD) Port 164 (Type P)(Physical U2.VDD)(Side Die2) (Net VDD) Port 165 (Type P)(Physical U3.VDD)(Side Die3) (Net VDD) Port 166 (Type P)(Physical VDD) (Side EMDpin)(Net VDD) … Port 200 (Type P)(Physical U1.GND)(Side Die1) (Net GND) Port 201 (Type P)(Physical U2.GND)(Side Die2) (Net GND) Port 202 (Type P)(Physical U3.GND)(Side Die3) (Net GND) Port 203 (Type P)(Physical GND) (Side EMDpin)(Net GND) [End Port Map] Arpad stated that there should not be a pin name called "GND". Randy suggested that this could be allowed, as in "U1.Bus_label.GND". Arpad replied that "U1.102" would be more appropriate. Michael asked about the format "U1: Bus_label: GND". Randy replied that this is correct but confusing. Arpad pressed on the point regarding "GND" - the pin of interest is "102" not "GND". Randy: have an individual pin that is VDD. Michael again asked whether the Port Mapping data should be self-contained. Randy replied that the examples should just use Bus_label; the EDA tool will short everything together correctly. Michael will implement this in the text and examples. [AR] Arpad noted that, as part of his own review and commentary on Draft 30, he found a technical hole: there are two different types of wildcards used in the document. One use of wildcards is to point out the additional syntax that is possible; for instance, look at example 3b but imagine a larger device. If this was a 4-die MCM, theoretically, you can say *.E7 includes U1, U2, U3, U4. It is indeed intended to short these connections. Part of the problem is that wildcards appear in the group line, not the port line. But this is no longer explicitly described in the text. Randy asked why we have both Group and Bus_label. Arpad replied that Group can do more than Bus_label. If you use Bus_label, you can only get to those pins that use Bus_label, but Group can gather more than Bus_labels. Randy cited the language Michael highlighted in his presentation for EMD in IBIS vs. non-IBIS (Port Mapping) grouping. Arpad emphasized that two Bus_labels can be gathered into a larger GROUP. Randy replied that the previous "Group" syntax, on separate Port Mapping lines using wildcard declarations, should be added back to the document. Michael will make this change. [AR] There should also be language documenting how a list of pins can be grouped together into 1 port. [AR] Arpad raised the problem of tracking signal paths through Xnets. He noted that he held an offline discussion with Weston Beal and Randy. No agreement has yet been reached. Randy suggested that "Xnet" definitions should be a future meeting discussion topic. Arpad added that we may need, in addition to "Net", an "Xnet" parameter in Touchstone Port Mapping. Tools can only search so far in models that are provided to establish connectivity. He added that SPICE will still not be possible to parse for connectivity. Randy moved to adjourn the meeting; Arpad seconded. The meeting adjourned without objection.