====================================================================== 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 June 1 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. Randy Wolff moved to approve the minutes of the May 25 meeting. Mike LaBonte seconded the motion. No objections were raised and the motion carried. From last meeting, Mike had an AR (action required) to post the Interconnect BIRD draft 35 with changes as discussed. This was done. During Opens, Radek Biernacki mentioned that he has a comment regarding May 11 minutes, which he will send via e-mail. Mike additionally noted that, per a discussion in the last meeting, there can be interconnect elements that connect buffer-pad and pad-pin, you can also have buffer-pin elements. An alternate view is that an IBIS file might contain only the Interconnect part has been provided, but not all of it. Partial circuits are allowed? Walter Katz responded that there is no path from pin to buffer; meaning this is an incomplete path. Does this demand a warning/error? Do we want to have a diagnostic for the complete path? Mike: found it needed to make files that didn’t represent a full path to the pin (in context of BIRD161.1). Bob Ross stated that this is simply an incomplete and faulty model; not in relation to BIRD161.1. Michael asked whether this is due to missing data or data being placed elsewhere due to specification limitations. Mike suggested that the team imagine a board substrate with package information separate. Walter Katz replied that this is basically an EBD. Michael will add notes to BIRD161 to address this case, including an on-chip interconnect model. This addition was blocked earlier in favor of Pin Reference. Walter noted that most EDA tools are handling buffer-only models today; the question is whether we want to formalize it. Bob stated that models that only go partway (buffer to pad) would be illegal, and are not part of BIRD161. Radek suggested the team can finalize BIRD 161 after Interconnect work is complete; whichever is approved first will affect the other. Requirements List Mike shared his list and Bob’s comments on it. Coupled and uncoupled models must be supported. Bob suggested that Rule 5 is incorrect, and package-only interconnects are not supported. He added that, on Rule 8, the mix of terminology should be corrected. An additional Rule 8+ was added to refer to Power and GND pins. Walter noted that a model can have just I/O pins, or just rails, or both. The text must allow all these combinations. On Rule 9, Radek was not sure of its intent. Walter stated that there is a need to know which models need those signals and what the connections from pin to I/O pad are. Radek noted that the parser should be able to identify these. Walter suggested that, where it says “EDA tool” it should instead say “parser”. Radek added that it is unclear whether the model maker shall provide multiple interconnect models, or some other requirement. This may involve MB of data. Walter suggested a discussion for next time how to address “views” (variants or “sets”) for alternate descriptions of the same pin paths. Bob added that this also involves Rule 12. The two rules could be merged. For Rule 13, Walter noted that we can’t assume EDA tool can/should do simulations with mixed package models. We may need to address memory command and address with two different methodologies. Radek asked, why not do sims of two different pins simultaneously? Walter replied that these cannot be represented through an overlapping set. Randy noted that, if two different pins have different package models, they are likely not related and therefore unlikely to need to simulate them simultaneously. On Rule 14, Walter noted that it will be covered in the “sets” discussion next week. Mike noted that the text should be deleted based on earlier “incomplete” conversation. Back on Rule 13, Bob suggested that the model can provide full path for user selection, but the tool Would have to be able to identify it. The EDA tool must have a default as well. On Rule 15, Bob asked why, if there are all I/O pins, how “aggressors” became involved. Walter replied that a bad sentence change somehow happened; the correct one is noted in an e-mail. Bob stated that he stands by the change; how do you have an aggressor from an input model? Walter replied that an N=6 W-element or S6P can be used to represent input and output cases. Bob responded that therefore a series model, a terminator, etc. can be aggressors. Walter agreed, adding that NA cannot be aggressor; neither can power/ground. Bob responded that yes, NA can be an aggressor. Under this definition, anything can be an aggressor. Walter moved to accept original version 23 language. This was withdrawn from consideration, to be raised and reviewed next time. Also next time, the team will assess Draft 35 in light of Resolutions document. Mike moved to adjourn. Radek seconded. The meeting adjourned.