====================================================================== 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 August 17 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. Mike mentioned that Michael Mirmak was not able to make it and he will chair the meeting in his place. No patents were declared. Review of ARs: No ARs were reviewed. Review of Minutes: Mike called for review of the minutes from the August 10 meeting. Randy moved to approve. Walter seconded. The minutes were approved without objection. Opens: Mike proposed to discuss the one buffer per pin rule. He asked if we still accept this rule and if it applies to the Interconnect BIRD. Arpad suggested that we instead discuss the [Interconnect Model Set] scoping proposals in regards to what the EDA companies prefer. He suggested to finish and resolve that issue first before moving to a new topic. He has received feedback from his developers, and he was expecting to have the vote soon. Mike agreed that issue should be resolved first. Scoping discussion: Mike called on Bob or Walter to present any additional material they had. Walter said his examples and arguments were sent out over the Interconnect Reflector. And he believes looking at these should be clear and make a compelling case. He mentioned that Bob also sent out similar examples for his approach. Bob mentioned that he would like to bring up his thoughts. Arpad expressed concern about limited EDA participation, but thought we should push for a vote. He mentioned that the developers at Mentor had looked at both approaches and have come to a conclusion about their preference. Walter asked if Arpad could reveal their preference. Arpad said they prefer Walter's approach of scoping the [Interconnect Model]s inside the [Interconnect Model Set]s. Bob asked Randy for his preference on the issue. Randy thought that Bob's examples showing different packages with lots of reuse would be low speed signals that would probably be okay to use the [Pin] list or [Define Package Model] formats. He does not see much reuse of models for his package models. Bob asked Randy if he would ship an IBIS file without the full component model. And if he would have a need to break out into separate types of models for different buffers such as DQ and Address. Randy mentioned that he would have S-parameters and spice models for different parts of a package. Bob asked Randy if he would also issue a full version of the package model with all the pins. Randy said, yes, it could be an option to have a fully coupled model with all the pins. But the S-parameter models could be better for the high speed signals, while the fully coupled spice model has the disadvantage that it may not be broadband. Bob commented that you could have different groupings of interconnect models, but if there is need for a full package model even if it is not fully coupled. There are benefits to referencing parts of a full model for other partial models. His approach can give more options to the model maker while keeping a smaller file size. This approach could also create less work for the model user in terms of knowing which model to use. Randy replied that he would have a default model with all the pins. Bob agreed that would be there should be a default model. And agreed that a lot of this discussion does not apply to low speed packages. The key point of his proposal is that the power and ground pins are always the same and always in place, so the PDN can always be reused. He added that it is also easier to read the model and create comments when you include by reference. His argument is that for model makers his approach makes more sense, and that in his view it is not a big programming challenge. Arpad commented that it is not necessarily that challenging of programming to include by reference, but in their case it does not fit in the tool architecture they have. And this would result in more development time and cost. Randy asked Walter if the names next to the [Interconnect Model] keywords were required. Walter compared it to the EBD approach of having a name for readability and for the parser. Bob commented that the name of the [Path Description] is informational and that the name has no relation to the [Pin] list. But, this is a deviation from other IBIS keywords. He added that with his approach you have the option to deliver more options to connect the PDN models with smaller file sizes. Mike mentioned that if we have a motion we could hold the vote. He said that there are a few people not present, but that both approaches are compatible and he does not foresee any issues going either direction. And we can always raise the issue again and re-vote on it if new information is presented. Walter moved to include and scope the [Interconnect Model]s within the [Interconnect Model Set]s. Bob seconded the motion. Bob called for a roll call vote. Mike initiated a roll call vote by company to adopt Walter's proposal for encapsulating the [Interconnect Model]s within the [Interconnect Model Set]s. For Mentor Graphics, Arpad voted - Yes For Micron Technology, Randy voted - Yes For Signal Integrity Software, Walter voted - Yes For TeraSpeed Labs, Bob voted - No Mike noted the motion passed 3 to 1. Randy thanked everyone for their work on the proposals and examples. Interconnect BIRD Draft37: Mike asked Walter to provide comments and resend the required changes to the BIRD for his [Interconnect Model Set]s proposal. Walter accepted the AR. Arpad asked who is in charge of editing the Interconnect BIRD. Mike took the AR to contact Michael and find out who should do the edits. Mike asked if the [Path Description] names are required and have rules such as no spaces and being unique. And should the [Interconnect Model]s follow the same rules. Bob commented that they should be required, as they are necessary for understanding. Mike asked if we decided to remove begin from [Begin Interconnect Model]. Walter expanded his AR to rewrite the [Interconnect Model] section. Mike suggested adding the requirement for names to be unique within a set. Bob commented that we need to check that the IO pins are not duplicated. It could be illegal and confusing as you could create splits. Walter mentioned that he has some of those rules written in an email, and he will resend it to the group. Repeated Pin: Mike asked Arpad about the repeated pin in the pin list proposal. Arpad replied that the compelling reason for keeping the proposal is for splits and joins you would have to use an EBD or EMD style model. Walter recalled when we started the interconnect discussion, we agreed that we would not have IBIS support repeated pins. And, instead EBD or EMD as a future evolution would be used for this functionality. We had a vote and the decision was made. Randy agreed, and added we should focus on EBD/EMD as a high priority after the Interconnect BIRD is finished. Agenda for next time: Mike mentioned we will review Walter's changes to the Interconnect BIRD text. Arpad suggested to have a cleaned up copy of the BIRD draft. Arpad moved to adjourn. Bob seconded. The meeting adjourned without objection. Summary of ARs: Mike - Find out from Michael who should edit the Interconnect BIRD draft. Walter - Rewrite the [Interconnect Model] section of the Interconnect BIRD.