================================================================================ IBIS INTERCONNECT TASK GROUP http://www.ibis.org/interconnect_wip/ ; Mailing list: ibis-interconnect@xxxxxxxxxxxxx Archives at //www.freelists.org/archive/ibis-interconn/ ; ================================================================================ Attendees from August 21, 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. Justin Butterfield took minutes. Review of Minutes: - Mike called for review of the minutes from the August 14, 2019 meeting. Walter Katz moved to approve the minutes. Bob Ross seconded. The minutes were approved without objection. Review of ARs: - Bob to propose the exact warning message for review by email where there is no suitable victim found. - Bob reported this done. Opens: - Bob has a IBIS 7.0 topic to raise. - Walter would like to discuss to how determine extended nets in EMD. IBIS 7.0 Aggressor_Only Syntax Rules: Bob noted it was decided to not take the rules on page 33 of IBIS 7.0 literally. The tagging of Aggressor_Only does not have to be by pin only but can be the full path. Walter restated the rule as: no I/O pin_name without the Aggressor_Only column can be in one or more interconnect model. The issue is in any model a pin_name defines a connection and all pin_names with the same name are connected. Connections define the complete path through the terminals. What we want to say is the complete connection is Aggressor_Only. If you have two I/O models in the same group without Aggressor_Only, that is an issue. Mike noted the problem is the EDA tool has two choices and does not know what to select. Bob is proposing to create a BIRD to modify the text to make this more clear. Bob gave an example where the only way to select pin A1 as a victim was a model where two interconnect models were used. Mike commented if you interpret the specification literally this is illegal. We need some language that says Aggressor_Only applies to the complete path. Bob stated the parser will comply with the intent. Mike noted we need agreement on this and that we need to write a clarification BIRD. Mike suggested to add this to the known issues list for IBIS 7.0. Bob noted this is not an editorial issue, and we should look at creating a clarification BIRD. Mike asked if we have any text or example that clearly explains the issue. Bob replied his top priority is to help the parser developer. Mike to come up with text to add the Aggressor_Only rules issue to the IBIS 7.0 known issues list [AR]. Bob noted the other issue is the warning message when all of the terminals are Aggressor_Only through the complete path. There were suitable victims in each interconnect model, but when they are connected, there is not a suitable victim. This will now give a warning. Mike asked if the plan is to add this check. Bob replied, he has asked for this. Randy Wolff asked about the examples all referencing the same ISS subcircuit and if this is a problem. Bob replied this should not be a problem. Mike noted it is odd to have different representations of the same subcircuit. Randy agreed we are defining different meanings for the same subcircuit. Bob noted this test case generates errors today. Mike asked if these errors will be changed. Bob replied these will be resolved. Arpad Muranyi asked about the schedule for the parser developer to implement this. Bob replied, once we give him direction, it will likely be a week or so. Determining Extend Nets in EMD: Walter sent out an email with the latest EMD draft and another email with an explanation. He has added a paragraph detailing the new extended nets rule. In EBD, each path defines a connection between one or more of the pins. This allows the EDA tool to determine the connectivity. In EMD, one could have only coupled models, and there would be no way to extract the connections. We need functionality to determine the connections. Walter added a rule that there must be at least one electrical module for each unique I/O connection between EMD pins and/or component pins. Bob asked if we are considering both I/O and rail pins. Walter replied signal I/O pins are an absolute must, and for rails, at least one of the pins for each of the rails would work. Bob asked if there could be EMD pins connected to EMD pins. Walter replied this could be the case, as one-to-one connections for EMD pins is not required. When you have coupled models, this becomes an issue, but requiring that an uncoupled model also be provided solves the issue. Randy asked if we can add the component pin list to include this information. Bob replied we do not know where the connections are at exactly. Walter noted he wants to find what the extended nets are in a complex system, such as one including a DIMM, mother board, daughter card, etc. Bob asked if this is another board layout database. Walter replied it is not, as we need a way to protect the IP of the interconnect by providing the interconnect model rather than the layout. Bob suggested we could use a mapping function. Walter noted this was done by the component pin list. Bob suggested to not call it component pin list. Walter noted that component appears many times in the BIRD draft and at the beginning of the BIRD there is a note about component vs. the [Component] keyword. Bob suggested to have a similar name to EMD designator map. He noted we mean IBIS component or EMD modules. Next Meeting: The next meeting will be August 28. Bob 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