====================================================================== IBIS INTERCONNECT TASK GROUP http://www.ibis.org/interconnect_wip/ Mailing list: ibis-interconnect@freelists.org Archives at http://www.freelists.org/archive/ibis-interconn/ ====================================================================== Attendees from October 19 Meeting (* means attended at least using audio) ANSYS Curtis Clark Cadence Design Systems Bradley Brim Cisco David Siadat Intel Corp. Michael Mirmak Keysight Technologies Radek Biernacki, Ming Yan Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield*, Randy Wolff* SAE ITC Maureen Lemankiewicz, Logen Johnson* Signal Integrity Software Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* University of Aveiro in Portugal Wael Dghais Mike LaBonte convened the meeting. No patents were declared. Logen Johnson joined the meeting as the SAE ITC representative for IBIS. Review of Minutes: - Mike called for review of the minutes from the October 12 meeting. Bob moved to approve the minutes. Randy seconded. The minutes were approved without objection. Review of ARs: - Michael to check for consistency in capitalization of words and phrases. - He has sent out a new revision of the terms list with classifications. - Mike to discuss with Walter the naming of "rail" versus "supply" Opens: - Walter sent out some new introductory text to introduce: - The Terminal lines - The Aggressor concept Terminology List Review: Mike noted that Michael has made changes based on the terms list to the draft 42 which has yet to be posted. Some names and typographical errors have been corrected for consistency throughout the BIRD document as well as to reflect recent changes, such as moving to the [Receiver Threshold] naming convention for the buffer terminals. Introduction to the Terminal Section: Walter wrote the text in an indented list, but the language could be changed to a more prose form. Bob commented that we can add "Touchstone file" to the first sentence. For the second paragraph, he suggested to add the text "added in the SPICE deck". Mike also suggested to use "positional" rather than "ordinal" in reference to the numbering of the SPICE nodes. Bob commented that the port number of the Touchstone file is okay, but he asked what is the first column when it is a Touchstone file. He asked how we cover Touchstone support in this text. Walter added the text "subckt or Touchstone file instance" to the first bullet item. Mike suggested to change "rail" to "supply-rail". Mike asked about how the term node is used. Walter commented that nodes are assigned to terminals for the instance of the subckt. Arpad commented that the word "on" does not make sense in the second main bullet point. Arpad also suggested to replace the phrase "It is assumed" with "In this specification", since it is reflecting the specification rather than a physical requirement. Walter commented that the second section of his email goes through the second and third fields of the terminal lines. Randy asked about "rail" versus "supply-rail" naming in this section as well. Introduction to Aggressors: The last section of Walter's email discusses the Crosstalk with Aggressors case. Walter mentioned he gives an example of a DQ bus. Bob commented that we should revise the wording to describe what is supported. Walter added a bullet point that the specification allows for a subset of the complete package model. Walter gave an example to illustrate the functionality and purpose of the "Aggressor" field. Mike suggested to change "crosstalk" to "coupling" in the second to last bullet item. Bob asked how do we know if DQ7 is the center pin for which the coupling is complete. Walter answered that it does not have the "Aggressor" field. Mike clarified that when you have "Aggressor" on a signal, it means that it should not be considered as a victim. Arpad suggested to add the text "not suitable for Victim" to the definition. Walter commented that this is what is commonly used in the industry. And, it is up to the model maker to tell the user and EDA tool which signals are suitable Victims with complete coupling. Why Die Pads Discussion: Walter stated that he wrote this email to answer why we need die pads. The assumption is that C_comp contains the effect of the on die interconnect. Bob commented that IBIS contains a short between the [Model] I/O terminal and the Die-pad. Arpad noted that this is not true for [External Model]. Walter commented that the assumption of the short is no longer sufficient. Mike suggested to use the word "keywords" rather than "sections" for the second bullet item in the email. Bob commented that we need to standardize the terminology at each of the buffer, die and pin interfaces. Walter commented that this email describes why it is so complex for the supply-rails. He said that he will combine the editted text (from both emails) and send it out in a word document. Bob mentioned that he will go though it and make some comments once it is sent out. Walter moved to adjourn. Bob seconded. The meeting adjourned without objection.