================================================================================
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