================================================================================ IBIS INTERCONNECT TASK GROUP https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibis.org_interconnect-5Fwip_&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=bwQrVgC2AgDylV8dsGRFsha9boK_c3u1kTmh7el8n0o&s=JOqym-9KnFF8wmqE8uKbmFtnQwMQunbnIxtI-SuM14s&e= Mailing list: ibis-interconnect@freelists.org Archives at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freelists.org_archive_ibis-2Dinterconn_&d=DwIGAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DcQR-qLpQg5lIreuM6-NYECRIAFXt268PRNS5WO043M&m=bwQrVgC2AgDylV8dsGRFsha9boK_c3u1kTmh7el8n0o&s=vazawclfRYfDTNOO3vBwLx_HFjJjxWz2sDFi7SAS6sE&e= ================================================================================ Attendees from December 9, 2020 Meeting (* means attended at least using audio) ANSYS Curtis Clark* Intel Corp. Michael Mirmak* Ifiok Umoh Eric Edwards 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* Zuken USA Lance Wang* Michael convened the meeting. No patents were declared. Justin took minutes. Review of Minutes: - Michael called for review of the minutes from the December 2, 2020 meeting. Michael displayed the minutes. Randy moved to approve the minutes. Lance seconded. The minutes were approved without objection. Review of ARs: - Michael to review moving the definition of designators to section 13. - Randy was not sure what this relates to. - Michael to send out EMD 202.2 draft2. - Done. Opens: - Michael noted we need to discuss the upcoming meeting schedule. Upcoming Meeting Schedule: Michael asked if there are any preferences for the upcoming meeting schedule. Randy moved to cancel the meeting on December 23 and 30. Curtis seconded. There were no objections. Michael stated we will plan to meet again on January 6. BIRD202.2 draft2 review: Michael noted we left off on page 7 with the comments regarding terminals vs. ports. In the last meeting, we moved the definitions of terminals to much earlier in the document on page 7. Michael asked if we have resolved the comment or only part of it. Arpad stated this is consistent now. Michael asked if we should mention ports. Arpad thought it is okay. Michael searched for ports and noted it is typically associated with Touchstone specifically. Arpad stated the comment is resolved. Michael noted the next comment is also asking about the word "ports". Randy commented we have addressed this in the definition. Michael asked about the third comment on page 27 which is similar. Arpad replied this is okay now. Michael noted the next comment is on page 28 and relates to the phrase "are connected" vs. "can be connected". Arpad commented there is an analogous sentence on page 7. Randy noted, on page 13, there is also a comment about the phrase "can be connected" in the Designator Pin List section. On page 10 under EMD Pin List, the text uses "are connected". We are inconsistent for IO pins. When they have the same signal_name, they are connected, if they have an EMD Model connecting them. Arpad suggested we could say "connected through the EMD models". Bob commented there is a difference between "are" and "can be". Arpad stated we are not consistent in how we state what the same signal_name means. Michael suggested to change "can be connected" to "are connected". Michael also suggested to change this on page 7 to "are considered connected". He noted there is a related comment on page 13, and he changed this to "are considered connected". Bob asked about the pin matching requirement, where the pins have to match in the Pin List for the signal_names to be connected. Michael asked if this is legal and if this would be caught by the parser. Arpad thought it would be legal. Bob commented we can have a path that is incomplete. He was not sure if this would be an additional parser rule. Arpad stated we do not have a rule on this. If you have a designator and you only connect some of the pins, the designator can list all the pins, but you are not forced to have connections to all those pins. Randy agreed, if we have an EMD Model, then we can connect to it, but there is no requirement. Arpad the problem with the phrase "can be considered connected" is whose decision is it to make the connection. Michael stated usually the tool has to make these decisions. Arpad thought it is okay now. He suggested consider the phrase "can be considered connected by the EMD Model". Randy commented the EMD Model must describe the connection. Michael asked if we want to add this as a parenthetical. Randy suggested to add this in the introduction on page 7. Arpad asked if we can remove the word "considered" now. Curtis suggested to add the word "and". Arpad suggested to change the order of the sentence. Michael asked if we can leave the phrase "are considered connected" in the rest of the document without adding the definition. Curtis thought it would be nice to not repeat this, but people may start reading mid-document. Michael asked about the sentence on page 13: "For I/Os, all EMD pins and designator pins that have the same signal_name can be connected." Arpad asked if this applies to rail pins. Bob replied this is only for I/O pins, as the rail pins have a different set of rules. Michael asked if we have similar rules for rail pins. Randy replied this is under Designator Pin List, and we have overlap with other sections. Michael suggested to add a parenthetical on page 13 to say rail pin connection rules are similar to those defined for EMD Pin List. Bob commented the difference is that it is optional. Arpad stated we should not get into the details of the rail rules. Randy suggested to copy what is in EMD Pin List to make it consistent. He also suggested to change Interconnect Model to EMD Model. Michael asked if we want to copy part of this to page 13. Randy suggested to copy the entire paragraph to page 13. Michael copied the paragraph into page 13 and merged with the existing paragraph. Arpad asked about the second sentence. He suggested to change it to "may combine into a single terminal". Curtis asked if "may combine" is correct. Randy suggested to remove the word "may". Michael will send out BIRD202.2 draft3 [AR]. Randy asked if we are done with Arpad comments. Michael replied yes. On page 10 under the EMD pin list in the last sentence of the second paragraph, Arpad asked if this should go in the definition. Michael highlight the sentence and added a comment. Next Meeting: The next meeting will be December 16. Randy moved to adjourn. Arpad seconded. The meeting adjourned without objection. ================================================================================ Bin List: EMD Comments to be Resolved: (See BIRD202.1 tracking spreadsheet) IBIS-ISS Parser: - IBIS-ISS parser scope document