================================================================================ 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 December 13 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, A Siemens Business 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. Justin Butterfield took minutes. Review of Minutes: - Michael called for review of the minutes from the December 8 meeting. Mike LaBonte moved to approve the minutes. Bob Ross seconded. The minutes were approved without objection. Review of ARs: - Walter Katz and Arpad Muranyi to write up Groups and Sets into the latest draft. - Walter noted that this done and was discussed in the ATM meeting. Walter noted it was e-mailed out as BIRD189.5_draft13.0. Mike stated that he posted BIRD189.5_draft12 which was done before these changes, and he posted Walter's version with the Groups and Sets changes as BIRD189.5_draft13. Opens: - Mike stated he has a comparison of draft12 and draft13 if we want to show them. Arpad asked if we could change the website so that the draft12 and draft13 are in order. - Michael noted we need to discuss upcoming meeting schedule. Summary From ATM: Walter went over the changes he made for draft13. He noted that we should consider removing two of the requirements in the BIRD. There are a lot of editorial changes to make including defining what is meant by "legacy" package models. Most of the disagreement was surrounding rules specific to victims and aggressors. Walter commented that he sent out an email with an example of a classic case, and he thought that might be a good place to start the discussion. Bob thought the changes are good, but he would like to go over the details. Walter noted that when the term "models" is used in the BIRD we need to clarify it. Bob agreed. Michael suggested to add this to our editorial task list. Walter suggested to add clarifying the terms "Groups" and "Sets" to the list as well. Bob noted that some of the rules are split between signals and rails, and we need to get some clarity on these. Michael stated he will add this to the agenda. Aggressor treatment: Walter noted that the email he sent to the reflector did not go through. He shared the email as a discussion point. It details a 100 pin package example and all pins have 99% of the crosstalk from the pins on either side. There are 100 models and they are all in one Set and one Group with one victim and its two aggressors. Bob asked if the pin and pad terminals would be repeated. Walter said yes, but as a victim a signal is found in one and only one model. Walter thought we should support the case from his e-mail, and it should not generate any errors or warnings. Bob agreed that we can support this, but we should have the models in separate Groups. He thought that no Group should duplicate the same pin name. Walter asked if Bob would put these models in 100 separate Groups. Bob said he would. Arpad agreed that separate Groups would better for overlap, but from the user perspective they would have to make a different selection for each pin. If we had them in one Group, then the EDA tool could automatically select the model based on the pin selection. Mike agreed that the tool could automatically select the correct model, if not we would need another selection method. Bob asked about how the aggressors are selected. Walter noted that you cannot have a victim pin in more than one model. Michael asked if it is the model maker's decision on which pins to include as the aggressors. Walter said that it is. Bob noted that the Aggressor field is optional. Walter stated that if you have a fully-coupled model that is a legitimate case where every pin could be a suitable victim. Arpad noted that the only option is to have Aggressor or not and if it is not there the signal could be victim. Bob stated the way most EDA tools can work to determine the aggressor. The way to setup aggressors is for the EDA tool to measure the responses on nearby signals. Bob stated that EDA tools work to determine which signals are aggressors by applying a stimulus and measuring responses on nearby signals. Walter noted that EDA tools don't simulate every net as aggressor, but they scan the board to determine the aggressors. If the EDA tool does not have the layout of the package, it can use the BIRD189 models to find additional aggressors from crosstalk in the package. Bob noted that denoting Aggressors is optional and cannot be relied on in all cases. Arpad noted that if the Aggressor field is not stated and the model is fully coupled, then it will not help to determine the victims. Walter stated in that case every net including other victims are aggressors on all nets. An EDA tool should be able to calculate the crosstalk. Arpad has an issue with how the term "Aggressor" is used. Walter noted that if you do not have the Aggressor designator then all nets have all their coupling. Michael stated that the Aggressor designator could removed and not lose fidelity of the model. Walter noted in that case, you could use the model, but you might not have all the information. Bob asked about receiver cases and if the term "aggressor" could be confusing for some model types. Walter noted that it does not matter whether it is the Rx or Tx end. Mike showed an 8 pin connector example. He noted that we have a model which includes only 3 pins. He showed a few cases where you would use the Aggressor field to denote that the signals do not have all of the crosstalk noise. Arpad is concerned that sometimes a certain pin is an aggressor and sometimes it is a victim could be confusing. Arpad is concerned that having a pin as an aggressor is some models and a victim in others could be confusing. Michael asked about a resolution to this issue and if Bob has any issue with the Aggressor designator as it is. Walter noted that this has been discussed by EDA companies, and they have agreed with it. Walter suggested to discuss this in the open forum. Bob's suggestion is that duplicate pins should not be in the same Group. The next meeting is scheduled for Wednesday December 20. Mike moved to adjourn. Walter seconded. The meeting adjourned without objection. Task List BIRD189.5 editorial additions/changes to be completed: 1. File_TS0 and File_TS referencing warning language. 2. Remove the word "reference" from the IBIS-ISS examples. 3. Clarify the terms "Model", "Sets" and "Groups".