=============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from June 12, 2024 Meeting (* means attended at least using audio) ANSYS Curtis Clark*, Juliano Mologni Broadcom James Church Intel Corp. Michael Mirmak* [Michael Brownell] Xiaoning Ye* 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. New participant Xiaoning Ye introduced himself. He is involved with signal integrity at Intel, in the Data Center and AI group. He was chair of IEEE 370 standards development for a few years, though the team is not meeting presently. They have, however, left the "door open" to reconvene as needed, for example, to address supporting frequencies beyond 50 GHz. During the review of the June 5 meeting minutes, Michael noted that the date of the meeting needed correction. Arpad Muranyi moved to approve the minutes with this correction; Lance Wang seconded. The minutes were approved without objection. During AR review, Michael noted a few completed and in-progress ARs assigned to him: - Contact Tammy at SAE-ITC on meeting transcription rights - IN PROGRESS - Contact Dr. Yuriy Shlepnev for comments on port-mapping proposals - DONE - Send a proposed update to the language as a response to Arpad's e-mail reflector post - IN PROGRESS - Ask Xiaoning Ye of the IEEE 370 team to participate in the Interconnect meeting - DONE - Send the updated port-mapping priority list to the reflector for comment - DONE Arpad stated that the meeting minutes and other documentation should use the term "chord" from now on (the reflector discussion and the minutes omitted the letter "h" in many cases). Arpad showed a document he prepared comparing various IEEE 370 keywords with IBIS and Touchstone keywords and concepts. Non-highlighted keywords are only found in 370; yellow highlight shows where changes are needed, while green shows where IEEE 370 and Touchstone or IBIS keywords overlap significantly. For instance, "Data Source" overlaps between specifications, but could be made consistent through management of entry options. Arpad noted that there are some issues with the [Interconnect] concept in IEEE 370. Several bracketed terms are offset from the rest of the text with no clear definitions, while there are numerous terms that seem to have fixed meaning. Xiaoning confirmed Arpad's assumptions: brackets don't imply keyword-like meanings. [Data Source] is such a keyword which could be adopted into Touchstone. Xiaoning summarized several IEEE 370 options and their intended meanings. Section 3.5.x includes definitions of the options available for formal analysis or checking of data. "Calibration" supports SOLT and TRL as options, though these are really more for de-embedding. Note that "De-embedding" is a separate keyword. IEEE 370 doesn't specify alternating vs. sequential ports, which Xiaoning notes may interact with the Touchstone port mapping effort. The code for normative data metrics is posted publicly and could be referenced by Touchstone. The Manufacturer, Interconnect, Boundary, and Sequence keywords are open-ended without specific or required text arguments or entries. Arpad asked about the port-mapping format in IEEE 370: only port numbers are supported, without reference terminals, names, etc. Is this deliberate? Xiaoning confirmed this was purely arbitrary; mapping was not discussed in 370. IBIS is in a much better position to control this direction. Samtec's Jim Nalodny proposed the format used below the MANUFACTURER tag, but the specification did not get into connection assumptions and specific formatting. There is no consideration for which port relationships represent crosstalk, insertion loss, etc. These differences may result in two specifications, each continually evolving independently. Comments were used for these concepts to avoid slowing down IEEE specification approval due to Touchstone revision process. In addition, the IEEE 370 community needs a sandbox to permit experimentation; the eventual Touchstone 3.0 parser will need to handle both approaches. Michael suggested the teams can take advantage of the difference in cadence of updates between IEEE and IBIS; IBIS can move slightly faster. Walter added that IBIS can pull in all formal keywords extant in 370 now; when 370 as a committee reconvenes, they could pull in the IBIS developments as time goes on. Walter noted that some Touchstone data is measured, while some is simulated. He has some customers who use this information within the Touchstone format as a container, to track how the data is established. Is this identified by Sij in IEEE 370? Michael asked whether this could be alternately broken down by port. Xiaoning replied that measurement vs. simulation identification applies to the entire data set. In this context, synthesized data means concatenating two different S-parameter sets. Walter replied that the team can figure out how to handle the combination. Xiaoning noted that the spirit or purpose was to show data sources at a high level. Walter asked whether IEEE 370 represented point-to-point systems (2-point connections) mostly, rather than memory structures. Xiaoning responded that this was not necessarily true. The DUT can be 3- or 6-port, and the whole approach can be applicable to it. The focus is on de-embedding. There is some talk about supporting an odd number of ports, in Appendix B, Reference 33. Walter suggested that how two ports are connected is a common discussion point. Do we define low-loss as zero reflection at 0 Hz? 100 MHz? Something else? Is there some automated way of seeing this from the data alone? Xiaoning replied that this was out of scope for IEEE 370. Some structures may only have their crosstalk measured. No one knows what is going on unless you tell people explicitly. The best way to be sure is to put assumptions in a description field or comment regarding which aggressor and victim pairs are used for crosstalk measurements. Walter replied that the person creating the Touchstone file will know which ports are connected. Xiaoning agreed, adding that forcing inclusion of the information at the source is his philosophy. You can propagate the information from this point appropriately. Otherwise you have to guess. Michael asked whether there were referencing assumptions in the data format or calculations. Xiaoning replied that this was an excellent point but that there is no built-in assumption. The location of the physical ground pin will make a difference to the S-parameter. You need a picture of the probing setup along with the data and you cannot get away from that. Arpad noted that some pictures are present later in the IEEE 370 document, with carefully laid-out boards and SMA connectors. Real cases, however, could feature very non-ideal reference planes. Walter asked whether IEEE 370 assumes a single reference location for the measurement. Xiaoning replied that this is a typical assumption, but was not explicitly discussed. We have seen successful measurements without a reference, where only differential mode is captured. Michael asked whether this was a complete characterization of all differential data from all ports. Xiaoning replied that these measurements were missing common mode; as only differential mode was of interest, the measurement would not be true mixed-mode. Arpad asked about measurements of, say, a component package on the die side versus the pin side. Are there any issues in IEEE 370 where measurements call for specifying the location for the reference used for particular ports? Xiaoning replied that this was an "old school" question, and one could trace it back to the ground-reduced data concept. This question occurred a long time ago to the IEEE 370 team: it depends on what you want. If I am sending my signal to Arpad, if I only care about my signal to my reference, we should not worry about ground-reduced vs. not-ground-reduced. S-parameters as a format deliver that information. The relationship between two local references, however, cannot be determined. Arpad agreed, noting this was like measuring an ideal transformer: each coil is a completely isolated system with no common referencing between them. Xiaoning noted that cross-referencing different ports needs a totally different and more difficult approach. Characterizing ground bounce is the classical case here. Arpad asked whether power supply, rail, or plane information was included in IEEE 370 data. Xiaoning replied that the procedures covered only signal characterization, but they should be applicable to power. For power, the measurements would cover a lower frequency range, but the DUT is the DUT. Arpad asked whether measurements could include a full-loop with power and ground combined, or whether these measurements should be made through separate ports. Xiaoning suggested treating the power plane as a signal. The same approach should be applicable, but you must ask yourself if you need to de-embed the power connection. Some do, but this is a different question, involving low-frequency de-embedding. A different approach may be needed if one does not perform low-frequency de-embedding. In this case, a low reference impedance is required. Michael mentioned the mixed reference impedance support which was introduced in Touchstone 2.0 (and revised in Touchstone 2.1) for just this purpose. Michael thanked Xiaoning for his participation and assistance in clarifying so much of IEEE 370. This will have a very big impact on Touchstone 3.0 development. Arpad moved to adjourn the meeting; Curtis Clark seconded. The meeting adjourned. The next meeting will take place on June 26, 2024. ================================================================================ Bin List: 1) Complete port naming proposal (Katz et al) 2) Complete ISS-IRD 1 Draft - enable cascading of S-parameters through W-element (Mirmak) - TABLED 3) Complete/revise Touchstone 3.0 draft outline (Mirmak) – dependent on items above Tabled ARs: - Arpad to give an example of the physical connectivity needed for EMD automation.