[ibis-interconn] IBIS Interconnect Task Group Meeting Minutes - October 16, 2019

  • From: "Justin Butterfield" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "jdbutterfiel" for DMARC)
  • To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Tue, 22 Oct 2019 19:23:06 +0000

Minutes from the October 16, 2019 IBIS Interconnect Task group meeting are 
attached.

Regards,
Justin

================================================================================

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

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 

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 

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

Other related posts:

  • » [ibis-interconn] IBIS Interconnect Task Group Meeting Minutes - October 16, 2019 - Justin Butterfield