================================================================================ IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from March 13, 2024 Meeting (* means attended at least using audio) ANSYS Curtis Clark, Juliano Mologni* 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 called the meeting to order. No patents were declared. Juliano Mologni introduced himself. He serves as the product manager for SI/PI products at ANSYS, including HFSS and SIWave products. He is based in Michigan. Michael noted that the minutes from the last meeting were not available for review. No ARs were still outstanding from previous meetings, aside from his action to review the IEEE 370 specification for sampling information. Arpad Muranyi reviewed his initial text of a port-mapping proposal. Some TSIRD required form text is still to be completed. The slides Arpad sent out raised a few suggestions and questions. Some were addressed in the Task Group meeting of Sept. 27, 2023. The intent is to make this proposal work with EMD, package (IBIS Interconnect), etc. The fundamental new feature is an optional keyword pair, [Begin Port Map]/[End Port Map]. Description for this is still to be written. It is to be placed immediately after the Number of Ports keyword and supports four subparameters. Some syntax improvements over the original proposal have been included. Port numbers have been removed; only port name under Group is supported. Michael suggested that the introductory material should mention an interconnect focus. It's not clear this language would apply to a 3-terminal RF transistor. Arpad replied that the proposal could support base, emitter, collector identifiers; the original background text in the presentation talked about this. Walter Katz disagreed; for RF transistors, we could apply some features and ignore others (e.g., "side" is a don't-care for active RF transistors). Arpad noted that Port name is required; other fields are now optional. Connect and Diffport are optional, depending on differential state. Note that the parser cannot enforce or check these beyond basic syntax. Walter noted he had sent out an e-mail with comments on the proposal; he briefly summarized them. He favors "pin number" rather than "pin name", as opposed to using numbers or physical port ID, etc. There is widespread confusion in industry between pin "name" and pin number. He added that none of the examples is complete. A single example without ellipses is needed. Measurements and reference points are linked; they have physical locations. In many cases, these refer to a single SPICE node. There is no concept of Group, PinDef, or Bus Label for a measurement-based S-parameter data set for a reference. Arpad noted that this issue was discussed last summer/fall, with examples, in a presentation. Groups as a concept were accepted then. Walter replied that bus labels do not belong in Touchstone files as opposed to wrapper files. Juliano noted that, when he imports a layout, his company's approach lets the user automatically associate port references to a closest ground pin OR group them into a single reference point. For IBIS models, this is not usually applied. For pin groups with lots of VDD pins, customers like to group these for IBIS to reduce the complexity of the model. This applies mostly to pins and not pin groups. Walter suggested imagining a scenario where, for power integrity, we want to represent a Touchstone file for the power distribution network in a package. How would we group these? Arpad replied that, if you have a slow device, you wouldn't benefit from having a 30-60 port reference network. But for a multi-gigahertz device, giving the reference port details might make a difference to results. Walter replied that, in the first case you have 1 VDD port; in the second case, you have 20 VDD ports. Arpad responded that the question is not grouping vs. not-grouping. The issue is having information in the Touchstone file about the connections of the pins, etc. If you have 10 VDD pins associated with 1 port, how do you list the pins as associated with one port? Walter asked, for that case, how the measurement was done? Michael asked whether a mapping wrapper is still assumed or not. Walter asked whether we need to have IBIS information in the Touchstone file at all. He added that measurement is always with respect to the closest reference point. Shorting may be needed. Arpad asked where the short would be made. We cannot rely on the IBIS file to make the short using the bus label. Regarding groups on rail ports: imagine one of the ports of the S-parameter is Vcc. One application for representing Vcc itself. The other application for Group is as the reference node for a signal port. In this case, it's always the closest return path location you can use for your reference point. Walter replied that this approach will confuse people about Groups; a reference point is Vss and should be treated this way. Arpad noted that his referencing vs. grouping presentation, with justification, dates from August 30, 2023 and consists of five slides. Arpad will send this out to the reflector. [AR] Michael noted that a non-physical reference point can be used in simulation for data representation; the proposal needs to make a distinction between measurement and simulation. Walter replied that a Touchstone measurement is a differential measurement between a "port" and a reference node; it's either an X, Y location or a SPICE node. Arpad noted that the user can connect ports in any way. The objective here is to include in the Touchstone file information about the netlisting connection to use with an IBIS file. This port mapping approach is either describing what it is or what it connects to. Randy Wolff noted, on the grouping concept, that for VDDs with 1 or 2-layer packages, a designer might have 10 VDDQ pins. Some of them might be connected together and others not, depending on their physical placement. We may have 5 groupings between those 10 VDDQ pins. Whose responsibility is it to make the associations? The model generator? The recipient? Where should this information reside? Walter replied that one could have 1 VDD pin in an S-parameter, with a need to group them into ports. Groupings for signal ports is understandable. Why use grouping for reference nodes? Walter specified that he is arguing against groups for reference nodes. He suggested a justification for grouping ports be part of the discussion. Juliano noted that his products have "smart pin groups" which group VDD pins together. What he has seen is that companies can create a Touchstone file including all the reference ports, then group them after the fact. Randy replied that you tend to have different people making Touchstone package files and IBIS models; there are different syntax approaches to both. Michael suggested that these are two different issues: connections to outside formats and data is a separate problem than documenting information about a specific structure and its behavior. Randy asked whether the proposal should be documenting the connections at all. Arpad replied that the problem is that there could be different mapping on, say, the pad as opposed to the pin side. One is the grouping, one is the referencing, and one is the description of what is measured. Does the format need to be limited such that it won't be able to tell the user how a component should be connected? Arpad moved to adjourn; Lance Wang seconded. The meeting adjourned. The next meeting will take place on March 20, 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 4) Complete pole-residue format BIRD draft (Muranyi) - COMPLETED 5) Complete port naming proposal (Katz) - COMPLETED 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.