================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from January 10, 2024 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 Synopsys Ted Mido*, Edna Moreno* 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. Edna Moreno introduced herself as a new participant. She is a Synopsys applications engineer, and their current tool sets use a lot of IBIS models. She is based out of Mexico. Michael reviewed three sets of minutes: December 6, 13, and 20. Randy Wolff moved to approve the December 6 minutes; Bob Ross seconded. No objections were raised to approval. Lance Wang moved to approve the December 13 minutes; Bob seconded. No objections were raised to approval. Michael mentioned that there is a book citation error in the December 20 minutes, which was corrected in a post to the Interconnect reflector: The sentence… “Bob cited the book "Passive Network book by Stephan Gralocia, p. 170.“ … should read: “Bob cited the book, ‘Passive Macromodeling Theory and Applications’ by Stefano Grivet-Talocia and Bjorn Gustavsen, 2016, page 170.” Randy moved to approve the December 20 minutes with this correction; Bob seconded. No objections were raised to approval. Michael noted that his AR to check the IEEE 370 specification to see if reciprocity, etc. apply to the matrix data or the circuit only, was still open. All other ARs were closed or complete. Michael opened the discussion to addressing RFM questions before pole-residue proposal updates were reviewed. Ted Mido noted that the current PLS-based draft is essentially the same technically as RFM from Synopsys. Her further stated two points: 1) Synopsys upper management is "very happy to donate any portion" of the RFM documentation for Touchstone use. 2) One aspect Synopsys has considered in the RFM format definition is parser-friendliness; when reading in rational functional data into the system the speed of parsing and the avoidance of errors are major objectives. He proposed the team try to minimize the number of keywords to represent rational functions. Also, when reading one line of text, you already know how many tokens should be present. Reading pole-residue data, you already know how many lines will represent that segment, to help up-front allocation of memory. Encapsulating one matrix term in a single begin/end block allows you to check the entries before End is encountered. Sometimes customers produce 10 million poles, which is significant in size and takes time to read/process. All the current industry formats have major similarities. Arpad Muranyi stated that he tends to agree that RFM and the current pole-residue draft are highly similar and convertibility is high as well. Arpad asked about the PRECFAC parameter. Ted noted that he had contributed this parameter. Arpad asked whether this deals with internal implementation details; more information is needed to see if it is required for a standard format. Ted replied that it is only needed for the transfer functions in the Y-parameter domain; he is seeing less and less need for PRECFAC with 99% of the data being sent today being S-parameter-based. Y-parameters can easily go to infinity with cases like lossless lines, resistors, etc. Circuit simulators treat circuits in admittance domain (as the basis for nodal analysis). PRECFAC helps embed some of the reference impedance (resistivity) to prevent lossless systems from going to infinity in terms of admittance. This also helps match circuit behavior to its representation. The argument is a single parameter which is the coefficient of the reference impedance vector. This is only used in Y-parameter domain AND when the system has lossless behaviors. Ted added that he does not see any need to use PRECFAC in this proposal. Synopsys plans to actually "obsolete" this parameter; as it is not that user-friendly. Most are now using S-domain parameters directly in circuit simulation. Arpad noted that this kind of data is useful for power delivery analysis, including the Z-domain. Is any extension there planned? Ted replied that some Z-domain direct treatments are available, but these can encounter the same Y-parameter infinity issue. Up to this point, he does not see a particular need to open up RFM to Z-parameters. If a need emerges, Synopsys is very open to extending the interface. Bob asked whether PRECFAC is a yes/no parameter. Ted replied that PRECFAC ranges from 0 to 1; if 1, HSPICE injects 1x the reference impedance into the system, 0.5 for 0.5x, etc. Arpad asked how the best value is known. Ted replied that anything is possible mathematically, but stability is an issue. The conditioning of the circuit matrix is best between 0.5 and 1. PDN analysis may use different values. The default is 0.75. Bob asked whether RFM supports per-port references. Ted replied that this was good point. Yes, for conventional Touchstone as the rational function data is based on that. Code supports per-port; however, we need to check the parser of the RFM model to ensure it correctly supports this. Their implementation assumes the option line data is present, so the reference would be present. The S-element pulls in the RFM data directly. Arpad replied that PLS files are used by their simulator directly, "under the hood". No reference impedance is provided. Arpad accepted the AR to check into whether reference impedance is needed [AR]. Once the keyword is available, the S-element would have a file pointer to point to the Touchstone file. Michael asked whether the team preferred prohibiting Reference keyword for pole-residue data or not. Arpad replied that pole-residue would be mutually exclusive with Network Data only. Bob asked whether the reference impedance Z0 is real only. Is a complex value possible? Ted answered that the developers had considered complex values, but this is too tricky to represent. The current implementation assumes a real value only. Bob asked about "symmetric" data. Upper and lower matrix data in current Touchstone can be identified as identical to reduce size; is this supported in pole-residue format? Ted replied that Arpad's format does not talk about a matrix format; he thought the pole-residue data would be encapsulated within Touchstone existing keywords (e.g., matrix formats). The "Symmetric" term in RFM files identifies S12 and S21 as being identical. Arpad advised the team to remember that there are matrix index keywords identifying the structure of the data. He has not added the specifics to the pole-residue proposal yet. He added that, on reference impedance, there is a strong statement in the proposal on page 5. A lot of reference information is related to normalization. In Touchstone 2.0, we did away with normalization (S-parameters are not normalized any version). Bob noted his disagreement with adding normalization statements in proposal text. Ted added that RFM does not normalize anything (historically, it was not done for Y- or Z-parameters, as the need wasn't obvious). Bob stated that, for matrix data, we still document the reference impedance regardless of normalization. The implication is that if you mix power and signal with low and high reference impedances, respectively, the cross terms take into account the reference impedances in Y- and Z-parameter data. Ted replied that one cannot represent a system in the S-domain without reference impedances. He does not see a specific need for Y- or Z-parameter per-port normalization. Michael asked about Ted's POLES_FROM feature proposal. He also referred to the need for data source information (bandwidth, step size, etc.) which Arpad is also adding to his own proposal. Ted noted that RFM reuses common poles to reduce computational cost. But pole-sharing not explicitly supported yet; Arpad's version is quite good for shared poles. Today, designers try to put multiple sets of data into Touchstone 1, which is inefficient. This can be done in RFM, which is a tricky situation that helps with large networks like HBM. A simple way to define pole sharing is with a single master matrix entry, with other entries pointing to that master. Ted added that his team is considering enhancements to RFM based on decisions here. Arpad noted that the PLS format uses per-port impedance data directly; the information is present in the file. He was not sure if this information is used or just documentation. Arpad noted his concerned about legalities for EDA vendors to directly view Synopsys documentation available through web searches. Ted replied that the safest way is for the vendors to contact Synopsys directly. Arpad moved to adjourn; Ted seconded. The meeting adjourned without objection. The next meeting will take place January 17, 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 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.