================================================================================ 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 14, 2019 Meeting (* means attended at least using audio) ANSYS Curtis Clark Cadence Design Systems Bradley Brim Intel Corp. Michael Mirmak Keysight Technologies Radek Biernacki Mentor, A Siemens Business Arpad Muranyi* Micron Technology Justin Butterfield, Randy Wolff* SiSoft Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* Mike LaBonte convened the meeting. No patents were declared. Randy Wolff took minutes. Review of Minutes: - Mike called for review of the minutes from the August 7, 2019 meeting. Randy moved to approve the minutes. Bob seconded. The minutes were approved without objection. Review of ARs: - Bob to send proposed Aggressor_Only rules. Bob reported this as complete. - Walter to make the changes to reflect the changes to the EMD draft from the August 7 motions and the changes recommended by Michael. Walter reported the changes were made and sent out last week. Opens: - Michael will not be able to host on August 21. Touchstone survey: Mike showed the Touchstone survey was linked on the IBIS web page. Mike wanted to make sure there was a survey on the page, since Eric Bogatin's article mentioned the survey results were available. Mike asked if anything else is needed for publishing the results. Randy asked if the survey was stored elsewhere on the web site. Mike noted it is stored on the Interconnect task group page. Mike added that there are other formats of the survey such as a PowerPoint format and the raw Excel data. Bob wasn't sure that other formats were necessary. Mike noted we did start discussing in other meetings what to do next. He suggested deferring further discussion for another meeting. IBIS 7.0 Aggressor_Only Syntax Rules: Bob discussed 3 rules from his email. 1. If one pin_name is marked Aggressor_Only, then all of the same pin_names are considered Aggressor_Only This means that pairs of Aggressor_Only markings are not required. 2. A WARNING is generated If All terminals are considered Aggressor_Only in a single [Interconnect Model] or through combinations of [Interconnect Model]s in [Interconnect Model Set]s or by references in an [Interconnect Model Group] Bob noted this is a warning that there is no automatic selection of a victim interconnect model. This is changed from an error. Mike asked if this is expressly prohibited. Bob noted it is not. On page 47 where there is an example, there is Pin 4 which can never be selected as a victim. If all pins are tagged Aggressor_Only, then there is no automatic selection of that model. Walter noted a warning should note that there is no connection that is a victim. Mike suggested we propose the exact warning message for the parser developer. Randy noted the warning might state that coupling is incomplete. Arpad agreed. Mike thought it was important to note this. Walter mentioned the word crosstalk could be in the statement. Bob suggested the statement "Victim cannot be identified, cross-talk may be incomplete." Bob noted we are dealing with a syntax checker, so we should not get too much into details of potential simulations problems. Mike noted the tool will string together multiple interconnect models to create a circuit netlist. Bob noted this is done by the Interconnect Model Groups. Bob showed his Example 3 detailing correct grouping for victim selection. Mike asked what would happen if a group created no valid victims. Bob noted that ibischk will look at the groups and issue a warning if there is a violation in the group. Arpad wondered if the parser was going to issue this warning, it would have to put all combinations together to check the rule. Should the EDA tool do this? Bob noted the tool shouldn't be expected to select an Interconnect Model within a set. Tools could allow a selection mechanism for cases where there is no clear single choice for a net to be a victim. Mike asked if the check should be done per pin in the group. Bob thought this would create a lot of warnings for larger models. Bob showed example 4 from his document "aggressor_only_syntax3.docx". Mike noted that the combination of BBB and EEE yields Aggressor_Only for every pin. Combining CCC and EEE yields a valid path for A2. Randy questioned why there would be a warning for A3 and not for other pins A1 and A4. Bob noted you don't have to give a complete set for every pin as a victim. Randy noted it is important to mention the specific Interconnect Model with the problem. Bob stated that the message is to the effect that no combination involving Interconnect Model BBB allows for victim selection, and this related to A3. Bob will propose the exact warning message for review by email [AR]. Bob started to discuss the 3rd rule: 3. An ERROR would be generated if there are any two Buffer_I/O pin_names OR any two Pin_I/O pin_names without Aggressor_Only in an [Interconnect Model Set] or referenced by an [Interconnect Model Group] There was not time for further discussion. Mike proposed that Bob provide more details be email. Mike will ask Michael to setup a meeting for next week, and this topic should be on the agenda. Next Meeting: Mike volunteered to host the meeting the next week. The next meeting will be August 21. Arpad moved to adjourn. Randy seconded. The meeting adjourned without objection. ================================================================================ Bin List: EMD Comments to be Resolved: 1. Resolve if [Component Pin List] is required. IBIS-ISS Parser: - IBIS-ISS parser scope document