================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from March 20, 2024 Meeting (* means attended at least using audio) ANSYS Curtis Clark, Juliano Mologni Broadcom James Church Intel Corp. Michael Mirmak* Michael Brownell Keysight Technologies Ming Yan Marvell Steve Parker MathWorks Walter Katz* Micron Technology Justin Butterfield Siemens EDA Weston Beal, Arpad Muranyi*, Randy Wolff* ST Microelectronics Aurora Sanna Synopsys Ted Mido, Edna Moreno Teraspeed Labs [Bob Ross] University of Illinois Jose Schutt-Aine Zuken USA Lance Wang Michael Mirmak called the meeting to order. No patents were declared. Before the minutes were reviewed, Michael discussed the news that longtime IBIS contributor and former chair Bob Ross had passed away the previous week. Walter Katz commented that this was a very sad day for IBIS. Michael invited more statements from the participants, and noted that the IBIS Open Forum meeting on Friday would provide more details as to organizational changes and any observances that may be made by IBIS as a whole. Michael reviewed the minutes of the March 20 meeting. Randy Wolff moved to approve the minutes; Arpad Muranyi seconded. The minutes were approved without objection. Michael noted that only he had a standing AR to review the IEEE 370 document for its sampling treatment. During opens, Arpad noted that he is working on TSIRD 7.1, to correct minor typographical and other issues. It will likely not be submitted to the IBIS Open Forum yet, as it is not yet ready. Arpad opened the discussion of the port-mapping topic by noting that he has two documents to share, with both already distributed via e-mail. The team reviewed one presentation from 2023, showing the port map format in an earlier form. In the format, connectivity comes from the pin list, and includes pad list, etc. Arpad also found some issues with the original HL_portmap syntax has revised it. In that form, the syntax was PORT followed by portnumber, +, descriptor, -, descriptor, and an optional name. We have since added "side"; Arpad noted that he dislikes an approach that organized the list by port number and added "Group_by_Name". Arpad also added the *.PinName syntax (not yet supported in EMD) to use references by reference designator. This feature seems to be able to co-exist with the syntax. He proposes adding SPICE NodeName in the netlist and schematic forms, and including x,y,z coordinates in PCB packages. Walter asked about the context of a physical port name. Imagine a 10 sheet schematic, with indication of location of a given port on a specific sheet. For an IO, a physical port name is just a name. It may depend on whether you are an EMD, or a C_comp model, or an IBIS. For IBIS, the format would be Pad:pin_name, or buffer:pin_name. RefDes.pin_name would be used for EMD. Walter prefers pindef and does not really like "group" as a term, as it is overloaded. Arpad replied that some of the names stem from the original HL syntax, and were selected to ensure minimal changes. Walter stated that the format should be generally readable. He suggested, per page 13, adding more readable examples, for example, using "net name" for the logical name. He likes the original HL names. Arpad replied that the IBIS specification forced changes to some of them (e.g., bus label, signal name, rail signal names, etc.). The names can be changed. Walter responded that, if you use the physical pin names, they will map directly to IBIS. He prefers that the first entry is the physical port name instead of "pin". One could generate a wrapper automatically with consistency if the mapping were done this way. Arpad noted that Pin_IO and Pad_IO are used for connections to IBIS package names. One would have to include actual connection points. Walter suggested that a format like pin.A7 and pad.A7 would be easier to read. Michael asked whether the intent here to have a single TS file for an entire package. Walter replied that one may want to generate a Touchstone file for the DQ lanes. Michael asked whether the entire path from buffer to pin was to be described. Randy suggested the format could describe any path. Arpad suggested that users were unlikely to do this, but Michael replied that this is a common usage approach. Walter stated that we don't want to make Touchstone a netlist format, BUT we do want to use it as a documentation format for an entire system where needed. We know what it represents. Randy suggested that the file format can include reference designator information. Walter added that parentboard, childboard designations would also be needed. Randy added that board name vs. device name distinctions would be needed. Arpad replied that the original HL is both a pre- and post-layout format; under the hood, the tool will save the entire system as a single S-parameter. He added that he does not think we should write a specification for it. Randy noted that he has seen measurements in a lab for multi-board systems. Walter suggested there was too much focus on having multiple capabilities in the same file. Arpad replied that the focus here is the link, for instance, between IBIS buffer and package file set because they are "married for life". Walter responded that 99% of people generating Touchstone files do not need the connectivity data for IBIS. Physical port names can be used to identify logical names. *If* it's for an EMD or an IBIS model, then you can generate the interconnections. Randy suggested that the explanation be reorganized, perhaps using sub-chapters, such as on creating port names for an IBIS package, creating port names for an EMD usage, etc. We need to prevent people from reading this super-complicated format and giving up. Walter added that he has customers that say that they want certain information in the file, want it parsable, then can use it any way they want to. They may want to use this for tracking what has been measured, for instance, and want this data put into the context of the Touchstone format. He will be requesting a keyword with "status" as a field for adding information (e.g., measurement); this may be needed for i,j or x,y not a port. He agreed with Randy that the document should be organized for onboarding new users. Michael asked whether 1) non-physical descriptions in this format are acceptable (e.g., ideal ground) 2) any technical features were still missing from the format. Walter stated that, even without x,y locations, netlists are still non-physical connections. Antennas and filters can be represented through Gerbers. Walter took the AR to re-send his commentary e-mail to the reflector, and will re-do slide 7 (the complete feature list) his way. [AR] Arpad to lead the document with simple examples. [AR] Arpad moved to adjourn; Randy seconded. The meeting adjourned. The next meeting will take place on April 3, 2024. ================================================================================ Bin List: 1) [Complete draft Touchstone document separating version 1.0 and 2.0 into their own chapters] - REMOVED 2) Create structures to encapsulate Touchstone 1.0 data in Touchstone 2+ specifications - TABLED 3) Complete draft Touchstone 2.0 document containing TSIRD3 and TSIRD4 draft (Muranyi) – COMPLETED 4) Complete pole-residue format BIRD draft (Muranyi) - COMPLETED 5) Complete port naming proposal (Katz) - COMPLETED 6) Create alternatives to the Touchstone 1.0 option line before the "R" character - TABLED 7) Complete ISS-IRD 1 Draft - Enable Cascading of S-parameters Through W-element (Mirmak) - TABLED 8) Complete/revise Touchstone 3.0 draft outline (Mirmak) – dependent on several items above Tabled ARs: - Arpad to give an example of the physical connectivity needed for EMD automation.