================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from September 6, 2023 Meeting (* means attended at least using audio) ANSYS Curtis Clark 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 Arpad Muranyi*, Randy Wolff* ST Microelectronics Aurora Sanna Teraspeed Labs Bob Ross* University of Illinois Jose Schutt-Aine Zuken USA Lance Wang* Michael Mirmak called meeting to order and took minutes. No patents were declared. During review of the August 30, 2023 meeting minutes, Arpad Muranyi referred to a reflector message he sent with suggested changes to the minutes. He requested changing: “we do different normalization in Touchstone 1 (for S-parameters only) and no normalization at all in Touchstone 2.” to: “we do normalization in Touchstone 1 for G, H, Y and Z-parameters which are not normalized in Touchstone 2. S-parameters are normalized in both versions.” With those changes, the following phrase could be removed: “G-, H-, Y- and Z-parameters are not normalized in Touchstone 2 at all.” No other feedback was received. Arpad moved to approve the minutes with these changes; Randy Wolff seconded. No objections were raised and the minutes were approved. Michael reviewed the ARs from the last meeting. Michael's AR to contact Sam Chitwood regarding loop inductance is still open. Similarly, Michael's AR to get additional details from Pete Pupalaikis regarding his compression algorithm was still open. Arpad noted that he had accepted an unlisted AR regarding contacting his colleague Vladimir Dmitriev-Zdorov regarding Touchstone referencing; he noted that this had been done. Arpad reviewed his proposal regarding port mapping, with changes. Arpad noted that he and Walter Katz are in agreement regarding the need for grouping, as discussed over the reflector. Michael asked about the three subtle differences in how connections and port mapping are applied in industry; which of these three is the actual objective of our updates to Touchstone? - showing internal netlist connectivity between interconnect "ends": no implication of specific electrical behavior, but similar to the "extended net" concept in schematics - asserting functional usage, as in a pin list or map where the meaning of each pin is stated (this could be limiting for situations where data is used in several contexts) - conveying electrical relationships, such as low-impedance paths (this could be problematic for AC-coupled nets, for example) Arpad noted, after reflection, that we don't always need all three in an improved Touchstone. The nature of EMD syntax will give you what you need in combination with Touchstone. The CONNECT statements in the current proposal accomplish much of the three purposes. Walter suggested a clarification: if you know which ports of the Touchstone file get connected to physical connections on the board, then you don't need to know end information. There was some disagreement within the team on whether the "tool needs to figure out" which receivers are associated with what ends. Walter noted that "transfer nets" are used in his employer's tools. Information about which TX and RX devices are involved in a specific network is provided, but additional information about other nets is also present. Arpad noted that Siemens calls these "net classes". Michael asked for a re-focus of the team's efforts - in addition to associating the "ends" of the interconnect: - should the specification state what connects to the outside world, and how? - should the port definition include the meaning of the net (its declared function, such as power and ground, whether it's differential, etc. Michael asked whether this is an accurate summation. Are there any other functions needed? Do we need all of these functions? Walter replied that all this is helpful information, but is not required. We do not need both physical and logical pin names, but should have at least one. The only remaining issue is how we describe a group of "ports" (or pins). He added that need groups, as illustrated in the following example: I have a board with a bunch of BGA connections on a board, and I need to know how the vias connect. This could be 500-1000 connections. A similar situation would be to have balls and silicon bump pads where there is an order of magnitude or more difference between the number of connection points between them. Arpad agrees with this as an example. Walter added that we can imagine creating an s20p with 10 balls specifically where measurements have been made, but represent a whole bunch of balls on the ends. Measurements may be at one port, but there may be a bunch of ports this represents. As long as this group does not interfere with port mapping (also optional), then Walter has no opposition with including this kind of grouping. Michael mentioned the data-only approach for Touchstone as simply a file containing numbers, where EMD or some other wrapper is used to include port information. Will the new approach cause problems with the classic RF applications (e.g., transistors) that Touchstone previously supported? Walter replied that there are two approaches: - EMD wraps Touchstone files - Touchstone is self-contained with all information He added that often trying to create Touchstone files sometimes ends up resulting in the data being thrown "over the wall" to the IBIS modeler; Walter notes that having the data in both file type locations will enable finding errors. Arpad suggested that one could have conflicts between pin connectivity in the EMD and Touchstone files. Walter replied that a good EDA tool should detect and report this situation, through cross-referencing. Michael asked whether the proposed format takes into account the three purposes. Arpad replied that the format supports grouping, pin connections, and the CONNECT concept. It's possible that these could conflict with EMD. Walter suggested Arpad's proposal includes power delivery confusion. He would like to see a simple case with two DQ lines that go from controller to SDRAM1, SDRAM2. The format example should identify which controllers and DQ devices are connected. Arpad explained the two parenthetical information blocks on slide 4. The first block includes the PIN reference designator and pin declaration; this can be a device or BGA, etc. Signals and power are distinguished; A0, A1, etc. are extended nets (using a common name). Ports do not have names in this approach. However, Walter expressed a desire for a port name. Pre-layout and post-layout are distinguished by *function* vs. *coordinate* approaches. Arpad expressed openness to having name field or other changes; he showed where a name field might easily be inserted in the provided examples. He also added that there are certain Pin versus Group inconsistencies that need to be changed for standardization. Walter expressed agreement to adding a field for names. Generally he doesn't care about the other format specifics. He did suggest a need for identifying differential ports. Arpad noted that the format contains an electrical association with CONNECT using a semicolon, but DIFFERENTIAL is not present. Randy Wolff noted that CONNECT identifies an extended net; we already have the function elsewhere in the format. Walter suggested that the names could be E, B, C (emitter, base, collector), etc. for other applications such as active RF devices. If a series cap existed between BGAs U1, U2, U3, where would that be included in the network? Arpad replied that this would be reflected in the data. Walter asked, if they are on the same net, then why have the CONNECT statement? This is redundant. Randy added that this was his earlier point about extended nets. Arpad replied that CONNECT could be supplied even if Port Map is omitted. He added that referencing is a problem as multiple references are not needed. Arpad moved to adjourn; Walter seconded. The meeting adjourned. The next meeting will be held Wednesday, September 13, 2023. ================================================================================ 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 IN DRAFT 10 4) Complete pole-residue format BIRD draft (Muranyi) 5) Complete port naming proposal (Katz) 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.