====================================================================== 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 November 30 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 Michael Mirmak convened the meeting. No patents were declared. Review of Minutes: - Michael called for review of the minutes from the November 16 meeting. Walter moved to approve the minutes. Randy seconded. The minutes were approved without objection. Review of ARs: - Michael to summarize existing rules of precedence in the IBIS specification. - Michael reported he is still looking into this, as it is a significant task. Opens: - None Table of Terminal Types: Bob stated that the motivation for the exercise of looking at the table of Allowed Terminal_type Associations is that we have defined our syntax items up to 3 different times, including twice in the introduction in some cases. There are multiple ways to organize the information. The original table is organized by location and secondarily by function. Another organization that could make sense would be to organize by function first then by location. In Bob's proposed updated table, the Terminal_types above the heavy line are the IO functions, while those below the line are the rail functions. He thought this better organizes the entries in the table and may be a better order to introduce the concepts. He also changed the entries in the table to: "B" for buffer pin name, "R" for rail pin name, and "D" for [Die Supply Pads]. A third version of the table replaces "B" with "I" for IO and reorganizes the proposed footnotes. Bob's suggestion is to use this table and follow this as the order in which to introduce the concepts of the specification. He also made some modifications to the foot notes to explain the table entries. Michael asked what the purpose of the table is and if it is intended to be used as a reference. Bob indicated he uses the table as a reference, and that it is useful for cross checking the syntax rules. He commented that the table has a lot information and that we need examples to highlight the cases shown in the table. Walter stated that he prefers to not have rules in different places, as this can cause confusion if there are any perceived conflicts. He thought the table can be confusing. Walter asked if any of the rules in the text are incorrect. Michael asked what the purpose of the new introduction is. Walter commented that the intent is to introduce the functionality and to justify the syntax. Walter asked if anyone disagreed with the rules in the Interconnect Modeling Introduction. Bob commented that he disagrees with the order of the concepts and the wording of some of the rail terminal rules. Specifically, he does not agree with the wording of the Die-pads rules such as: "A rail can connect to a specific [Die Supply Pads]". His concern is that we do not require that [Die Supply Pads] exist, and we can have a buffer without defining the [Die Supply Pads]. Randy asked if the statement should be changed to this or that with two options. Bob stated that if you are using signal_name by itself, then you don't need to define a specific set of [Die Supply Pads]. The second bullet item under Die-pads has an implication that [Die Supply Pads] exist under the signal_names. Michael commented that we have precedence in IBIS for organizing and summarizing the syntax with a table. He asked if there are rules that are defined in the table but not in the text or vice versa. Bob commented that the introduction should be simple and limited. Michael asked if there are any conflicts between the sections in terms of rules being defined differently. Bob doesn't think there are any direct conflicts, but there are some clarifications that need to be made. We state options, but we don't clarify if we use bus_rail, can it be overlaid with the Pullup_ref and Pulldown_ref terminals. Michael summarized: we have organizational issues that need to be resolved, we need to check for rule conflicts, and we need additional diagrams to explain the concepts. Bob thought we might need some simple examples with rails, as well as a simple diagram that shows the hierarchy. Michael suggested to finish the discussion and have a decision to resolve incomplete paths issue. Michael commented that he needs test points that are measurable in simulation. Walter thought we could add a new terminal_type of "Test_Point" to address this need. Michael agreed that we need some other connection method then through the pins. Walter asked about the debate about incomplete pins. Bob agreed it is an issue. Walter suggested if there is an issue, then Bob should propose changes to the text. And, we can debate and vote on the issue. Mike moved to adjourn. Walter seconded. The meeting adjourned without objection.