================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from September 13, 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. Arpad Muranyi moved to approve the minutes. Bob Ross seconded. No objections were raised and the minutes were approved. During AR review, Michael noted that his two ARs were still open: to contact Sam Chitwood on port referencing and loop inductances, and to contact Pete Pupulaikis on S-parameter compression algorithms. Arpad reviewed his latest pole-residue document draft. He also requested that time be allocated to review referencing information he has received from his colleagues. He stated a few items regarding what needs to be decided before we can advance on port-mapping. We do not yet have a TSIRD draft, but only a few slides from Walter Katz and a few slides on the Siemens EDA Hyperlynx syntax. What is our general direction? Walter provided a format proposal. Who will write the TSIRD? Michael suggested that the team gather questions, answer them, then perform a "side-by-side" comparison to address specific issues. Walter stated his desire for an optional list of pins (pin number or "pindef"/group) as a feature. His proposal can be updated to have a reference terminal with pin or pindef/group. Which specific format is used is not important; we simply need the functionality. So long as the two formats have mappable functions, which is chosen is not important. "Group" as a term today is heavily overloaded but "pindef" has a specific meaning to several commercial tools. Differences are resolvable; "CONNECT" is already in Walter's proposal. Arpad reviewed draft 10 of the pole-residue document. Currently, the document approach and Arpad's preference is for un-normalized Y- or Z- parameters. Whoever is generating the fitting should un-normalize the Y- or Z-parameters first. Units should be ohms or siemens. The current draft repeats some text, which implies that a section may be needed before the keywords to describe what is common between them. Also, per Bob's comment, the equal sign has been added for subparameters but no text has been included yet to explain the rules on this. S-parameter impedance and normalization not yet added. Touches on option line and reference keyword questions. The team reviewed some of the answers Arpad received on questions regarding normalization. 1) For Y- and Z-parameters, if we fit to normalized parameters, are the results still good? A: yes. We would still need the reference information in the option line. Bob noted that this needs further discussion; it's unclear how to handle off-diagonal data as opposed to differential terms. There are equations for this; it is more complex than just using the sqrt(2), etc. Touchstone 2 is unnormalized for Y-, Z-parameters; Touchstone 3 could be defined that way as well. The issue is what to do with Touchstone 1.x data. Arpad suggested unnormalizing first, then converting. Bob responded that one could convert then, then unnormalize as well. Q2: On identifying Z-parameter normalization, tools will have to know whether data is normalized or unnormalized Z-parameter data. Arpad's current draft requires the use of unnormalized data. Q3, Q4: same questions as above, but on S-parameters. Both versions of TS use normalized S-parameters. One cannot unnormalize the data, but can only convert from one normalization to another. The solution is to ensure the resistance value in the [Reference] keyword or option line is present. Michael asked whether data that is unnormalized is the same as data normalized to 1. Arpad suggested that, for Y-, Z-parameters it's the same, but was not sure for S-parameters. Arpad thinks of reflections when thinking about references as terminations; the data set values are bounded between -1 and 1. Walter asked what bad things would happen if we said our pole-residue format is strictly for S-parameter data. Bob added that he also had considered that option. This would make the normalization issue moot but we would still need to have the reference impedance information. Walter made a motion to limit pole-residue format to S-parameters; no second or voting was needed at this point. Bob expressed support for this, for pole-residue. This motion will be kept on the table. Michael noted that IEEE 2401 LPB refers specifically and only to Touchstone S-parameters, not including other network functions. Bob showed two slides from an earlier presentation from Jose Schutt-Aine regarding matrix equations (University of Illinois ECE546 Lecture 13, from the spring 2022: https://urldefense.proofpoint.com/v2/url?u=http-3A__emlab.illinois.edu_ece546_Lect-5F13.pdf&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=e2nAk4P9xDedjhfymRf4h_IFnXNKjKPBeEOaJMmLbp0qliZagBFceS7unhPJ6Xx7&s=a5fzJgtTvuTgUPWDf6SDXD2LmVtk8mtQMmyIKc8o2OM&e= ) This explains how one can convert S-parameters to normalized Z-parameters in Touchstone 1.x. For the parser, we can use numerical recipes rather than commercial tool equations. No proposal for pole-residue is included in this material. Michael asked about the name field and tried to associate its contents with the three functions identified for Touchstone mapping: - terminal (e.g., U1.25, for external connectivity) - net/extended net (for internal connectivity) - function (e.g., "power", "ground", "IO") Arpad replied that the name field is just a comment or identifier. The format already uses "S" or "P" for signal or power. The CONNECT statement defines the extended net. Arpad asked whether we can have reserved functional names (drain, source, gate, etc.). Walter suggested rather to use pin_name and signal_name, similar to IBIS. Arpad noted that signal_name was already part of the format's defined parenthetical fields. These include pin_name/group_name, signal_name, S or P. Walter suggested that "pin_name" is what the industry calls "pin number". Signal name is DQ1, DQ2 Michael asked whether model_name is overloaded with the model or signal function. Walter replied that this is making an error. We need to separate pin number and logical signal name; we also want nets identified separately, as well as "end" identified separately (e.g., "near", "far", "controller", "DIMM1" or "DIMM2"). Arpad noted that, in the parenthetical fields, multiple ports can have the same signal_name. Walter replied that, in some tools, pin number is used for external connectivity. The signal_name is specifically for pre-layout. One needs to know which is DQS, or DQS#, for example, to support automated connectivity of S-parameters. Walter stated that he insists on separate fields. Arpad asked how the signal_name field is not fulfilling that need. Walter replied that every port should have a physical pin name, a logical pin name, and then other fields. Arpad suggested having "A0" as a signal_name field, connecting the BGA and three memories in the topology. Here, A0 is signal_name, identifying an extended net. The use of an IBIS comment-like signal_name is not shown. Walter noted that the function associations are pin U1.94 is "M1", pin U2.94 is "M2", U3.94 is "M3", and BGA.K2 is "controller". Arpad asked whether the reference designators such as U1, U2, U3 and BGA serve the same purpose. Walter replied that "M3", "controller", etc. identifiers are strictly for the user. Arpad suggested that a dictionary could associate these. Walter noted that there is a need for this information for human use, and a dictionary may cause confusion. Arpad moved to adjourn; Bob seconded. The meeting adjourned. The next meeting will be held Wednesday, September 20, 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.