================================================================================ IBIS INTERCONNECT TASK GROUP https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibis.org_interconnect-5Fwip_&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=GbpAQrH6gobirHmJ3b-BSvUp_6Z9NdLRAF3KdZBBpZusl72hoYRCZHQYw6RQcivi&s=Y1ASiFxwFwX91O57zTM9EKW_xh6z0_rCoU_xvIRya3I&e= Mailing list: ibis-interconnect@freelists.org Archives at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_archive_ibis-2Dinterconn_&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=GbpAQrH6gobirHmJ3b-BSvUp_6Z9NdLRAF3KdZBBpZusl72hoYRCZHQYw6RQcivi&s=XJv52RHkTM2mxVD-gqY_XGxd6g0geABtxsXr4C82QYA&e= ================================================================================ Attendees from February 23, 2022 Meeting (* means attended at least using audio) ANSYS Curtis Clark Intel Corp. Michael Mirmak* Marvell Steve Parker MathWorks Walter Katz* Micron Technology Justin Butterfield* Randy Wolff* Siemens EDA Arpad Muranyi* ST Microelectronics Aurora Sanna Teraspeed Labs Bob Ross* University of Illinois Jose Schutt-Aine Zuken USA Lance Wang Michael Mirmak convened the meeting. No patents were declared. Justin Butterfield took minutes. Review of Minutes: - Michael called for review of the minutes from the February 16, 2022 meeting. Michael displayed the minutes. Randy Wolff moved to approve the minutes. Bob Ross seconded. The minutes were approved without objection. Review of ARs: - Bob to create a test case for the parser with network data on multiple lines. - Bob reported the parser works okay in this regard, and the data can be split between real and imaginary parts in Touchstone 2. In Touchstone 1, the number of pairs per line is more rigid. - Michael to propose changes to Example 15 [AR]. - Michael suggested to keep this open, since he is still working on TSIRD(4). - Arpad Muranyi to send out the latest draft of the Designator Pin List Relaxation BIRD. - Arpad reported this is done. Opens: - None. Discussion: Designator Pin List Relaxation: Arpad shared the latest BIRD draft. He did not make any changes made outside of the last meeting. Michael asked if there was any further discussion on the meaning of "NC" in different contexts. Arpad suggested we could move forward without further defining what "NC" means. There is one sentence which addresses the definition already. Randy asked if the text allows you to relax the parser requirement that "NC" does not have to be repeated. He asked if we need to say that the signal_name has no meaning when "NC" is used. Bob commented the wording is okay and that the signal_name is meaningless due to the "NC" signal_type. Randy asked if the concept is clear from the text. Arpad asked if the phrase "may be ignored" is strong enough. Bob suggested it is okay, since we do not dictate what the EDA tools must do. Randy suggested we could say the signal_name is ignored when the signal_type is "NC". Bob noted there could be connection details that interact with the EMD connections. Arpad asked if it would be an error or warning to connect to it, since you should not make a connection to the "NC" signal_type. Bob replied it will be a parser extension to give a warning about connecting to an "NC" pin. Randy gave an example of an "RFU" (Reserved for Future Use) pin that could be an "NC". Bob noted the board might have routing for the RFU pin. Michael asked if only the pin should be checked by the parser and EDA tool. He asked if we could have repetitions in the pin name if the signal_type is "NC". Bob replied we do not allow repeated pins. Michael stated we do not allow connectivity for "NC" pins. Randy agreed and noted the connectivity is determined by the signal_name. Michael suggested to change the word "meaning" to "connectivity". Michael stated that the phrase "the entire line can be ignored" is not correct. He suggested to say "there is no connectivity". Randy suggested to say "no connectivity implied". Michael suggested to remove the second part of the sentence. Randy asked if there is a similar rule for the terminal lines. Arpad suggested to say "shall not appear on any terminal lines". Randy asked if this would be better in the EMD model section. Arpad will check if the "NC" pins shall not appear on any terminal lines rule should be stated in the EMD Model section [AR]. Randy suggested to add a statement that the pin names with signal_type "NC" should not appear in the terminal lines. Bob noted this would be a change in the parser checking. Randy commented that we have always matched the number of terminals. Bob commented there is an error if you have a Terminal line with an "NC" signal_type. Randy noted "designator pin name" is a new phrase only used once in the specification. He suggested "designator pin" would be more appropriate. Bob highlighted a case where VCC could be an issue. Michael asked Bob to come up with a test case for a VCC problem example [AR]. Arpad motioned to adjourn. Randy seconded. The meeting adjourned. Next Meeting: The next meeting will be March 2. ================================================================================ Bin List: 1. Touchstone 3 2. Pole-residue support for Touchstone 3. Clarification BIRD drafts from ATM 4. TSIRD(4) 5. ISSRD process 6. Frequency data in multiple lines 7. Port naming