================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from November 8, 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 Weston Beal*, Arpad Muranyi*, Randy Wolff* ST Microelectronics Aurora Sanna Teraspeed Labs Bob Ross* University of Illinois Jose Schutt-Aine Zuken USA Lance Wang Michael Mirmak convened the meeting and took minutes. No patents were declared. During review of the minutes, Arpad Muranyi noted that the phrase "per se was not remember" should be "per se was not remembered". Arpad moved to approve the minutes with this change. Bob Ross seconded the motion. The minutes were approved without objection. During opens, Michael mentioned that his AR regarding obtaining Sam Chitwood's papers on referencing and loop inductance has been closed: he posted Sam's recommended links to the reflector. Similarly, his AR regarding suggested additional noise parameter references for the Touchstone 2.1 document was also closed; an updated reference list using IEEE formatting was posted to the reflector. Michael added that he was still awaiting a web update after sending approximately three months' worth of minutes and documents to Steven Parker to post. He was also waiting on the compression algorithm update from Pete Pupalaikis. The team turned to discussion of the pole-residue format. The first question was whether both Touchstone network parameters and pole-residue formats should be supported as part of the same standard. Arpad stated that he would not prefer having separate documents; both formats should be supported as part of Touchstone 3.0. Further, any single Touchstone 3.0 file should not include both types of data; at most, a file containing pole-residue data should only contain a file pointer to the original Touchstone data. Arpad added that he was considering fields for such a file, in addition to the name, to include file date, author, and checksum, to remove ambiguity for similar filenames. Arpad asked the question of whether we want to have a pointer to pole-residue data files in Touchstone files containing network data. Bob stated he would rather have separate documents. Michael added that the file name reference would be highly similar to the IBIS [Manufacturer] keyword (which is required for quality control but is essentially a comment) as well as book references. Arpad suggested that a key problem with pole-residue data without reference to the original data set is that the fitting algorithm could change; there could be better and worse varieties or descriptions of the same network. Walter Katz suggested that source companies may object to giving access to the original Touchstone files. Randy Wolff replied that there would be no need or expectation to give access; the reference is just a filename. He suggested identifying the network file with a keyword, such as [Pole-Residue Source] or [Pole-Residue Source Data]. Weston Beal suggested another alternative, [Network Data Source]. Bob reiterated that the reference keyword would only apply to pole-residue information, "one-way". The model author could put garbage data in the keyword; the contents are still a comment, in effect. Bob asked whether the filename should still be Touchstone. The reason is practical: there are 8-10 links to what is called Touchstone in IBIS, EMD, etc. Michael added that IBIS and IEEE 2401 have this problem already. Links to files can be established, but the version and feature set are not limited; this will need to be solved for multiple specifications. Arpad asked about the filename extension: .snp is assumed today for network data, but with pole-residue support, what about .ynp, .plsnp, etc.? Michael summarized the document direction: no swath support, one document for both formats, a filename reference only for Touchstone network data if pole-residue data is provided, with pole-residue being entirely optional. Weston Beal requested confirmation that the document would not require both data types. Bob confirmed that the presence of both in the same document would be prohibited. Arpad summarized this as "XOR logic" between the formats. Arpad noted that the urgent question to settle before further writing of the TSIRD is whether the three main keywords (Poles, Residues, Common Poles) should refer to a common core of text or simply repeat many of the same usage rules Bob replied that a common set of rules might work, then each section would refer to that common set with additional detail and/or exceptions. In addition, the team agreed that some cross-checking parameters would be needed to ensure that missing information represented zero-valued data and not errors. Arpad will supply some proposals here. Arpad moved to adjourn; Bob seconded. The meeting adjourned. The next meeting will be held Wednesday, November 15, 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.