====================================================================== 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 2 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 October 26 meeting. Mike moved to approve the minutes. Bob seconded. The minutes were approved without objection. Review of ARs: - Michael to look for a public domain picture. - Walter mentioned he has some pictures, but they may require some additional labels. These are included in the document he sent to Michael. He will send the images to Mike and Michael for review. - Walter to incorporate his introductory text in the BIRD document. - Walter's latest version is posted. Michael will incorporate the text in the latest version of the BIRD document. Opens: - Bob mentioned that we should go over the introductory text that Walter sent out. Michael agreed but said he wanted to finish the review of the rest of the document first. Bob expressed concern over the pictures which have a SiSoft label and suggested the text not be integrated until it is reviewed. Once the text has been integrated, it can be posted as a draft 43. Interconnect BIRD draft 42: Michael stated that we left off on the Terminal_type_qualifier section. Michael took an AR to look into the actual name of the Touchstone Reference Port Impedance to resolve the comment for Touchstone Files. Michael asked about the Terminal N+1 and if are there any additional connections. He asked if the statement regarding the N+1 Terminal connection is complete and correct. Bob thought that we can disregard the comment about "wires of interest vs. reference". Arpad asked about a 3 pin, 3 pad example which would have a model with 6 ports and 7 terminals including the reference. He asked which side should connect to the reference. Walter commented that the reference node is connected to the reference for the measurements. Typically this is a pin, signal_name, or bus_label which is ground at 0V and is referred to as local ground. He stated that it may be difficult to define. Walter said that the specification should support power integrity, but we are not going to resolve the best method to connect the reference. Michael stated that this is still an issue that we should provide guidance on, but the specification should leave it up to the model makers. Michael asked if there is any way to check that the Terminal N+1 is connected to power or ground. Bob said yes, but the path is not checked. Randy agreed. Arpad expressed concern over the statement in the BIRD text which implies a Pin is connected to a Pin. Michael changed this sentence to make it more clear that there are two cases for Pin and for Pad and Buffer. Randy and Arpad agreed that this made more sense. Mike asked on this page when we say "terminal" do we really mean node. Arpad thought it is okay, since we are referring to connections to a subcircuit or [Model]. Michael noted that the Terminal_type_qualifier table has been fixed for the [Receiver Threshold] naming convention. Bob suggested to change Buf_I/O and Buf_Rail to Buffer_I/O and Buffer_Rail to match BIRD 181, which is the IV table clarification BIRD. Mike suggested to hold off on changing these names, as he, Bob, and Radek are still looking into these names and their consistency and definitions throughout the IBIS specification. Bob suggested to expand the Allowed Terminal_type Associations table. For Pin_I/O, the pin_name is used, but for Pad_I/O, there is no pad_name defined. Although, we could use the pad_name same as the pin_name. Michael stated that we do not have a pad_name keyword, and Pad_I/O, Buf_I/O, and Pin_I/O all use the pin_name. Michael thought we would need to see an example and a diagram showing why it would be useful. Bob commented that he will send an email. Walter commented that there is always one Pad_I/O, Buf_I/O, and Pin_I/O all with pin_name as the name. Michael asked about the comment on "Package models" and suggested that the term "Interconnect models" should be used instead. Bob mentioned that there was another instance of the term "Package models" on page 11. Michael asked about the comment on page 20 about requiring multiple [Interconnect Model Set Selector]s and if the highlighted statement is correct. Arpad asked if this text means that both Pins to Pads and Pads to Buffer sections are required for the Interconnect models. Bob thought that if only one set is defined it should contain Pin to Buffer. Walter commented that the purpose of [Interconnect Model Set]s is to group Interconnect models into logical groups. There should not be any constraints, but there are practical ways to group them. Arpad stated that his concern is that this sentence is saying that a single interconnect can have all the connections or it can be split in to sections. If the split is done, then you have to have both sections, but he doesn't think that is the intent. Michael asked if we have the syntax necessary to do the two sections. Randy said the [Interconnect Model Set] does allow for this. Bob suggested we can check the qualifiers for Pin, Pad and Buffer to ensure there are connections from Pin to Buffer. For completeness, we should have some sort of rule to ensure people don't send incorrect models. Mike suggested to have a more restrictive rule that we must connect both in the split model case, and we can open it up with later BIRDs. Mike commented that he had brought up this issue before and suggested that we could default back to the [Pin] list and [Pin Mapping]. Michael stated that the comment about requiring multiple [Interconnect Model Set Selector]s is correct and the BIRD text should be changed accordingly. Walter commented that the purpose of having separate models is that they are generated by separate tools. Also, you can have different packages that use the same die. Randy agreed and added that he has cases like this. Walter stated the EDA tool can automatically create the connections. Michael suggested that we need to continue this discussion off-line and resolve the issue in the next meeting. Mike moved to adjourn. Randy seconded. The meeting adjourned without objection.