============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from August 12, 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 August 5, 2026 meeting minutes. Arpad Muranyi suggested several changes to the minutes: Address misspellings: “regaring” and “availble” “U2.gndj” – remove the "j" “self-explanator” – missing “y” at the end In addition, the sentence: “Arpad added that wildcards can only be applied to EMD pins, not designator pins.” ... should be changed to: “Arpad added that wildcards can only be applied to Designator pins, not EMD pins.” Randy Wolff confirmed that the suggested change is correct. Arpad moved to approve the minutes with changes noted; Walter Katz seconded. The minutes were approved without objection. During Opens, Michael noted that the Interconnect Task Group page on ibis.org had been updated to correctly list most of the recent minutes and discussion documents posted to the reflector. Randy suggested limiting the time spent in the meeting on extended nets and EMD. A limit of approximately 30 minutes was set. Michael asked whether "extended net" as a concept was actually needed, given that some tools don't use it. Randy replied that the language was already in IBIS; should we keep it? Arpad: problem is signal names and connectivity through EMD; net, extended nets, CAD net. Michael asked whether the extended net language should just be removed. Randy replied that we already have examples with a resistor, showing net name changes on either side of the resistor, where each of these has a different signal name. Randy asked whether EDA tools would be expected to check everything. We want there to be some link in the created netlist for what is connected from A to B. Arpad noted that the text on page 388 in the IBIS document uses the language "'connected' by the content of the [EMD Model]." This implies that the signal name and designator do not indicate connectivity. The problem is the way EMD Model is used and defined. Walter replied that the EDA tool is responsible for understanding series components; we are defining interconnect models between Designator pins and EMD pins. We do the same in IBIS package models as well. We are describing the interconnect between designator pins. Randy added that extended nets share the same signal name. Walter replied that a resistor between terminals can be treated as a separate component or part of the entire, single net. This is not important for single-ended nets, but very important for differential nets; high side of one pair has to match the high side of the other pair. But there may be a parallel termination between them; they are one extended net tying CAD nets and components together. It's important for tools to know which is the high side, and which are aggressors. Arpad pointed out an example in IBIS with two different signal names routed through a resistor, using names A7 and A7R. Randy replied that this example doesn't follow the rule on the first sentence of page 388, but instead follows the second item in the list which defines exceptions. Arpad replied that he could not agree. Randy suggested that the specific tool, used in the problem statement provided by Arpad, is wrong for not tracing the signal path through the Series Model present there. Arpad asked whether users and tools were going to be able to trace the signal path through an EMD model. Walter added that the problem in the case identified by Arpad was that the connecting component was a switch and not a resistor. He added that we need to explain what a signal_name means in EMD because we don't have extended nets. If a signal_name is the same is extended net, we have half an answer. If a signal_name is the same as a net, we need another definition. Randy replied that the implication is that in one case, the EDA tool is required to trace through series models. Arpad stated that the team needs to be careful about creating or supporting an "extended net" of "extended nets". Michael took the AR to update the draft BIRD, including examples. [AR] Randy suggested that the signal name identifies a CAD net rather than an extended net; this is not quite the same as a logical extended net. The team finished the EMD discussion, and switched to discussing Port Mapping. Michael noted that his latest draft reintroduces Examples 10 and 11 for Group lines. Arpad noted that, if we do not want wildcards to be supported, we can change Example 11 to use only one Reference, Group:GND_Ux. Randy asked whether we actually need an example like that. We already have at least one or two EMD examples which are legal under IBIS 8.0 today. Michael wanted to confirm whether everything becomes referenced to GND_ux in a non-EMD example. Randy stated that he was wondering why we even allow Group in an EMD example; we already have Bus_label, so why do we even have Group? It's for non-IBIS usage. Arpad suggested that Group can do more than Bus_label. Randy asked whether we are creating examples that we cannot support easily by using Group. Michael asked which action was more important: fixing EMD in IBIS due to industry needs, or getting Port Mapping done with limited referencing support for EMD. Randy replied that the team needed to get Touchstone done. Walter added that we only need Physical referencing for connecting two S-parameters. Randy noted that, if the Physical references are different, you have created a problem. Walter clarified that everyone assumes an N+1 structure, where the +1 is node 0. Having a different "gnd" at board and silicon requires two nodes. No one is using 2N structures now. Randy made an argument that if we have an example that uses EMD, we shouldn't use Group. If there's something that Group does that Bus_label doesn't, such as wildcarding, it should not be illustrated using EMD. Randy noted that Group is also useful for Power rails and Type P ports; we invented it for a reason. Michael took the AR to clarify the text to ensure that it only uses Group in non-IBIS examples, including wildcards. [AR] Randy added that the format can still use Bus_label to declare grouping after EMD is fixed in IBIS. Bus_label can be used for IBIS examples; Group for non-IBIS examples. Declaring Data_usage EMD, etc. with special names for terminals was a mistake; we shouldn't have done that. Bus_label is for declaring the group of pins for a rail (voltage). Walter noted that one can declare an IBIS Interconnect model that only has VDD: one port for all VDD terminals on the silicon side and one port for all the terminals on the pin side, for power-aware applications. Arpad moved to adjourn; Randy and Walter seconded. The meeting adjourned.