============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ============================================================================== Attendees from June 3, 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 May 27 meeting minutes. Arpad Muranyi moved to approve; Walter Katz seconded. The minutes were approved without objection. Michael raised an additional agenda item, related to unused connections in Port Mapping and EMD. He noted that Port Mapping can connect to only part of a defined EMD, but it wasn't clear whether only mapped connections should be available in both structures. He asked which one determines the connectivity for the other (which would exist first). Arpad noted that his assumption was that tools would automatically make EMD or IBIS Interconnect models from Touchstone data. Michael asked whether any alternatives should be supported. Arpad suggested that the other direction (e.g., EMD first, used to generate Touchstone 3.0 models) could be used as a data check or validation, but not a data generation step. Michael noted that there may be a distinction to be made between Touchstone data and Touchstone Port Mapping information. Walter agreed with Arpad: start with Touchstone then create the EMD from the Touchstone data. Michael noted that both EMD and IBIS Interconnect exist in Data_usage. Arpad replied that, if you wanted multiple options, then you would use Logical, etc. name/value pairs. If you have Data_usage, you are using only one connection. Walter added that, in Example 7, in DQ0 there's an A, B, C, D structure; this is a 4-bit DQ bus, but you can have multiple DQ buses. Only one is provided for one of the lanes, but this data can be used for any or all lanes. Arpad replied that, in this case, we shouldn't have Physical declarations; we should only have Net DQ0. Walter noted that the example actually used this approach in this specific case. Arpad replied that this was interesting but a different case than unused ports. We need a structure for unused ports. Michael outlined two different options, involving automatic terminations or restrictions on what models could be automatically connected through Touchstone Port Mapping. Randy commented that it seems bad to create a Touchstone file with data that is never used. You would have to create a new Touchstone file for the other purposes. Michael asked how to resolve Arpad's concerns. Arpad suggested that the even-numbered ports could, for example, be for another channel; why would the EMD file not include all the connections with the even ports? Who decides whether to or how to use the data? Walter replied that the purpose of the data is not to generate the EMD, etc., but to ENABLE the creation of the EMD data. You can generate the EMD file from the partial data in the incomplete Port Mapping declaration. Arpad asked who decides this. Michael suggested that the EDA tool would have an "EMD Generator". A third data set, with complete Touchstone 3.0 information, would exist. Randy added that Port Mapping is just for IBIS; a special case showing grouping or connection relationships. We would rather have the EDA tool allow an input list of terminations and ports to terminate. Arpad stated that he could accept a full Port Mapping with an EMD subset being created from it. Is the approach up to the user? Randy and Walter replied that this is up to the model maker. Arpad noted that terminations should include the Touchstone reference, open, and short; is the termination approach up to the EMD model maker or the Touchstone model maker? Randy replied that someone just measured or simulated the raw, complete data for the Touchstone file. How you use it in the IBIS model is up to the person creating the EMD. Arpad stated that the person who uses automation to create the EMD model determines the structure. Michael asked whether this presents any problems for a third-party user. Arpad replied that, if this is our choice, then we don't need to do anything. Randy suggested adding a note that the maker of the EMD is not using all ports available. The example should fill in the remaining ports. In this specific example, the model should filled in with DQ 4-7, or something similar that looks plausible. The structure could be x4 or x8. Michael asked whether the model needed pin names, designators, etc. Walter replied that one could just use J designators. The EMD is correct. Michael asked whether the team wants to keep "-like" examples (as in, should the examples which use EMD-like, IBIS Interconnect-like structures with exact correspondent in IBIS be kept?). Arpad noted that the question has been asked before, and depends on the order of approval for Touchstone 3.0 and a new version of IBIS with expanded ground support. Walter added that IBIS models don't support PI (power integrity) referencing yet, as this is being discussed in IBIS ATM for BIRDS 234 and 235; for SI (signal integrity), having "ground" is sufficient. For Touchstone, for every port, you use a nearby ground. Randy stated that he can provide offline help with Example 14. [AR] Arpad moved to adjourn; Randy seconded. The meeting adjourned without objection.