================================================================================ 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 October 16, 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* 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 October 9, 2019 meeting. Bob Ross moved to approve the minutes. Randy Wolff seconded. The minutes were approved without objection. Review of ARs: - Randy to create a stacked die EMD model example with power rails. - Randy noted he has not done this yet, as he would like to discuss this further. - Randy to propose some rules for the merged pin cases. - Randy would like to discuss these further as a group. - Arpad Muranyi to present a review of the merged pin syntax issue. - Arpad sent out an email about this. Michael noted we can review this today. Opens: - None. Merged Pins History: Arpad reviewed the summary of the merged pins issue history. His goal is that EMD should have the same features and functionality as the merged pins BIRD. Randy noted he ran into some issues, and he sent a follow up email to this which details some pin rail examples. Michael asked if the issue is understood. Walter Katz stated he does not understand the problem that is trying to be solved. Michael noted if you are missing pins in the pin list, we need to know how to handle these missing pins. Arpad noted these pins are effectively included as part of other pins in parallel combinations. There are two interpretations of this case and this could result in shorting things in an undesired way. Michael noted this only applies to power rails. Walter asked what problem that EMD is not able to solve. Randy stated there were a few issues that came up in the last meeting. He sent an email with the relevant sections on his EMD example with the VDD connections. Randy commented he has a VDD ball in the package example that is separated from the others called VDDDLL which is isolated. Walter asked if the PDN is separated. Randy noted that these may be merged on the board while this EMD is describing a stacked die, where the PDNs are separated. Walter noted one could have a bus_label on all the other VDDs. Randy agreed this could a possible solution. Randy showed the EMD designator and designator pin list sections for his example, which include bus_labels. In the ISS model, there are two VDD terminals at the die side and two VDDDLL at the die side and one each at the BGA side. Randy noted one option is to list out all the pin_names. He asked if labeling VDDDLL as VDD will be a problem since it has a different bus_label. Walter stated this violates one of the rules that two terminals cannot connect to both J1 pin_name and VDD signal_name. Arpad asked if this applies to both signal IOs and rails. Bob replied it applies to both. Walter commented we need improvements in the syntax to better handle this case. He suggested to have a bus_label such as VDDX for all the other pins and to have the terminals map to the VDDX and VDDDLL bus_labels. Bob noted we could change the rules to allow the bus_label to be created by the signal_name by omission, and the bus_label can override the terminals. Walter thought this would be more confusing to have this shortcut. Bob commented this is exactly the pin_mapping BIRD, which defines bus_labels based on the pin mapping. Walter stated this is a different case. Arpad asked if we are running into a conflict of where these are connected, and which connection takes precedence. Walter noted we would be applying a rule to this. We are not using signal_name to connect these, but we are using bus_label. Arpad stated this can be confusing. Bob commented that there is no restriction to have bus_label and signal_name preventing both from being signal_name. Randy commented another issue is that we have only defined one syntax to connect the pin_names to the terminals. He suggested to add the ability to connect by signal_names. Walter agreed we could add this functionality to connect by bus_label or signal_name. Walter asked, if you had an additional terminal and only connected it to VDD, where would you want to connect all the VDD pins in the package. Randy asked if this would be an ideal power connection. Walter stated you may have the PDN model not included. He suggested to label these as signal_name. Arpad asked where this short would be. Walter replied all of the pins at both the EMD and designator map are shorted. Randy noted this would be a shortcut where you would not need a wrapper to add shorts. Walter noted we could have two options where you short all the pins together or break them out by designator map. Arpad asked how we tell where the connection is at. Walter replied we know this from the qualifier. Walter suggest we could add a dot in front of the name "VDD". Bob commented at any designator we have three options where we can connect with the pin_name, which does not indicate a short, signal_name, or bus_label. In the fourth column, we define the EMD or designator interface. We can collapse the pins with signal_name or bus_labels. Bob noted we do not have a short, but this is a terminology discussion. He suggested to include the shorts in the model where necessary. Randy noted he looked at the case of ideal power to have a reference such as a VSS for the return path. This would not work with this the syntax, but the desire is to short all the pins. Next Meeting: The next meeting will be October 23. Randy moved to adjourn. Arpad seconded. The meeting adjourned without objection. ================================================================================ Bin List: EMD Comments to be Resolved: 1. Should the [Define Module] keyword be renamed? - RESOLVED 2. Documentation of CAD nets, extended nets and signal names definitions. - RESOLVED 3. Add bus_labels as possible Terminal_type_qualifiers. - RESOLVED 4. Add [End EMD Pin List], [End Designator Pin List] to keyword hierarchy. - RESOLVED 5. Remove [Number of EMD Pins] keyword? - CLOSED 6. Add definition of "Nyquist". - CLOSED IBIS-ISS Parser: - IBIS-ISS parser scope document