============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from July 15, 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. During Opens, Arpad Muranyi noted that he is writing an annotated copy of Draft 30 with his comments, including net and extended net distinction language. Michael thanked him for his efforts. During review of the minutes of the July 1 meeting, Arpad suggested two changes, which he had already forwarded to the reflector. First, change the following: “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.” ... to... “Arpad noted that "CAD net" is used at least once; Randy added that the usage is in the same section where "extended net" is used.” Second, Arpad wished to note a correction regarding his statement below: “…but doesn't go from designator to designator (it may be a different signal name)” The highlighted statement on pg. 388 doesn’t say that a signal_name only defines connections between EMD pins and Designator pins, and not between Designator pins. Arpad asked that the statement be striken from the minutes. Arpad moved to approve the minutes with these changes; Randy Wolff seconded. Michael shared a presentation where he indicated how "net" language is used, and how often, in the IBIS specification. He also attempted to distinguish between schematic drawing, SPICE connectivity, and post-layout PCB routing "net" concepts. Arpad noted that schematic drawings are often present in simulation tools that support graphical user interfaces. Michael replied that this approach is a source of the fundamental confusion that exists between these concepts in specifications and common industry usage. Randy noted that "CAD net" refers to physical layout; it's a name associated with physical metal. Michael replied that this is another key confusion point. Arpad objects to the "short for 'network'" language for "net" on p. 388. Circuit elements are connected by wires and nodes. Arpad summarized his experiments with the KiCAD public layout tool, which features a graphical schematic user interface. Net is a wire; net is short for network. No extended net concept seems to exist in the tool. Randy stated that it was unnecessary to feature this, and that mention of "network" should be removed. Michael asked which the most unclear terms were on page 388. Ideally, we should include a series resistor example with two wires joined as an extended net on either side for connectivity (signal path) purposes. This is a database exercise, where two named wires also share an additional identifier. Arpad replied that the difference between Hyperlynx and KiCAD is that those two wires in Hyperlynx cannot share the same net name. Randy added that this was similar to SPICE netlist and shorting. Arpad added that, in KiCAD, "labels" are on the wires in the schematic, but the user is allowed to give the same name to the wires on both sides of a series component. Randy replied that this has to be an extended net for use as a SPICE netlist. Arpad added that he consulted a board layout tool that used the KiCAD database; the two copper pieces on either side of the resistor had the same name. But the DRC checker flagged this as a disconnect. Stephen Newberry replied that, in KiCAD, that approach is specifically for the purpose of connecting two pins without cluttering the schematic. Shorting is the intended behavior. Arpad suggested that "net" connects elements (like a SPICE node); "extended net" is the full path from A to B with series elements. Randy asked whether this was what a "CAD net" as noted in the IBIS document was. Arpad pointed out the specific language used: 'each pin in a CAD database is assigned with a CAD "net"... name'. Michael asked what the overall KiCAD purpose was; what function was it intending to serve? Stephen replied that it was meant to generate layout from a schematic diagram. It later tacked on NG SPICE netlist-generation capabilities. Michael noted that metal attachments to points on a plane are not the same as a path in SPICE. Arpad clarified that assigning two pins to the same CAD net name was already mentioned (shorted is different than connected). Randy added that the exception is when there are series terminations, also as already mentioned. Walter Katz stated that there are two uses for extended net: 1) linear elements like R, C, and L that you can include inside an S-parameter 2) the other case that Arpad brought up: a switch, mux, buffer, etc. The latter are usually non-linear devices with their own SPICE models. For SI simulation purposes, those switches, muxes, buffers create an extended net; you can't include those in S-parameters. If we limit our discussion to Touchstone, where an extended net only includes linear elements, then everything is straightforward. We would therefore exclude buffers, muxes, etc. Arpad replied that the linear/non-linear distinction does not matter. Look at page 388, point 1: this states that the assumption is to combine two CAD nets into an extended net. The phrase above refers to a net, not an extended net. Arpad added that, from his observations, Michael was leaning toward "CAD net" becoming an extended net; Arpad sees CAD net as different than an extended net. Randy stated that a CAD net is a physical wire between A to B and C to D; an extended net includes both. Arpad asked whether this was a customer issue (meaning, a misuse by the customer, rather than a tool or modeling error). Randy replied that section 2 of the text is the troublesome area of this concept. Arpad noted that EMD says a signal_name tells you what is connected (not shorted). Signal_name is the equivalent of the extended net: it connects EMD pin and designator pin. In this case, the field solver gave a net name to each wire associated with a pin; signal_name and net name are the same in this case. Arpad argued that a signal_name is the same as an extended net name. Randy observed that we describe EMD in other places where we leave connectivity up to the EMD tool; we have not so far defined how this has happened. That is not always possible. Michael suggested that IBIS needs syntax to indicate the Series Switch electrical path. Randy replied that we already have that for Series Switch, and so no new syntax is needed. Michael then suggested that "net" for Port Mapping is the same as EMD signal_name. There's a distinction between EMD labeling and usage in a full system. Arpad noted that he had a two-pin EMD model, showing connections to two dies. Arpad took the AR to send out his full EMD syntax example so that the team could offer interpretations. [AR] Randy added that the team has simpler RDIMM examples in the IBIS document, and should use those for illustrating the extended net concept. Randy advocated defining CAD net or extended net for the "Net" name/value pair (associating the label with a greater meaning) in Port Mapping. He also advocated making the Port Mapping wildcard treatment and draft 30 top priority in the agenda for the next meeting. Arpad moved to adjourn; Randy seconded. The meeting adjourned without objection.