============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from January 21, 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. Michael reviewed the January 7 meeting minutes. Randy Wolff moved to approve the minutes; Walter Katz seconded. The minutes were approved without objections. Michael summarized his findings from his AR in the last meeting, noting he had sent out several IEEE unit references. Arpad mentioned a few e-mail exchanges, some offline, focused on the issue of pluralization of "unit" vs. "units". Michael suggested just keeping the usage grammatically correct. Michael summarized the changes he made to the Port Mapping draft to define a new Probe parameter. Arpad expressed disagreement with the new Probe and Physical definitions. Michael noted that Example 2a appears to be a purely measurement description. Randy stated that the descriptive text for Physical and Probe are extremely similar. We need something to set them apart, as the difference is not obvious. Michael asked whether the difference between Physical vs. Probe needs to be parsable. Arpad asked whether connectivity is defined at measurement time or use time. Michael noted that we overload a lot of these terms in the contexts of connectivity versus measurement. Randy stated that Probe is coordinate-type information; Physical is a pin or identifier for a pin. Arpad replied that, even when you perform a measurement, you may use pin/ball names. Michael asked the team regarding their preferences between ditching Probe vs. overloading Physical but restricting coordinates for connectivity. Randy noted that examples show the same syntax and usage. Arpad asked whether one can mix and match Probes and Physicals in the same map. Michael answered yes. Michael suggested that he could remove Probe and overload Physical with new rules. Arpad asked, before any changes are made, hypothetically, how do we make a distinction between the two. The only rule is that Data_usage and coordinates can't be combined. Michael replied that Probe and Data_usage don't interact. Randy asked whether we need to include XYZ for some other reason. Michael replied that it won't be common, but it will be used; Probe will be used with coordinates, and Physical for connectivity. Arpad asked whether there are any other structures with measurement conflicts. Michael suggested Net but no others. Arpad replied that Net is a line, not a point. Walter clarified that Net is a description of low-loss connectivity. Physical is how you connect it; Probe is how you measure it. Randy observed that he is seeing Physical as a refdes for connectivity, from a data book; Probe is for XYZ locations. He asked whether a model-maker would put Physical and Probe in the same file with exact copies of the same information. Walter stated no; one should use coordinates and one should use refdes in different contexts. This may not be automatic; it may need user intervention. Arpad asked whether one would ever describe a measurement with a refdes and pin number. Walter answered that one could do either or both. Randy added that it seems as if Physical is meant to be a pin name (from a datasheet), whereas Probe is the physical location. Walter clarified that Probe is for the person who wants to repeat the measurement. In some cases, probing may be at the closest accessible point, not at the exact connection point. Walter added that these are probably most useful when they are NOT at the same location. Arpad asked how, if the model-maker doesn't use both, one knows (for example) how measurement was done if Physical is present. Michael asked whether the issue is that Probe and Physical examples are the same. Randy replied the issue is whether Physical locations can also be Probe locations. Arpad asked how, if they are different, do we know they refer to the same thing. Walter noted that, if one has the XYZ coordinates and the schematic, and am the EDA tool or user, I can report the differences between the two contexts. Randy responded that, if they are both present, they are there for different reasons. XYZ is the location OF the refdes; Physical is only the refdes as a name. Walter noted that the XYZ information has a reference to a database, ODB++, etc. Automation may not be possible. Arpad asked how one would know the XYZ coordinate origin for a given Touchstone file. Michael answered that a lot of context is assumed; XYZ will likely be used for a known set of collected information, and user interaction will be needed. It's not the same as in simulation where files are grabbed from the internet and connected together "in the blind". Arpad asked whether the team wanted to allow XYZ usage for Physical or not. Randy replied that this issue needs more discussion/debate. Walter stated that he could accept Probe supporting only XYZ coordinates, and Physical only supporting refdes; then you could have one, the other, both or neither. Michael proposed updating the language of Probe and Physical, with explanations of how they differ, using the rules Walter proposed. Arpad moved to adjourn. Walter seconded. The meeting adjourned.