[ibis-interconn] IBIS Interconnect Task Group Meeting Minutes - December 18, 2019

  • From: "Justin Butterfield" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "jdbutterfiel" for DMARC)
  • To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
  • Date: Fri, 20 Dec 2019 21:43:30 +0000

Minutes from the December 18, 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 December 18, 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 December 11, 2019 meeting. 
  Randy Wolff moved to approve the minutes.  Walter Katz seconded.  The minutes 
  were approved without objection.


Review of ARs:   
- Walter to send out EMD draft 27.
  - Michael reported this was done.

   
Opens:
- Michael asked if the change from pin list to terminal is done.  Walter 
  replied he has defined some of these terms and changed the text where he 
  thought appropriate.

- Michael noted we still need to have the "what does connected mean" discussion.

- Bob Ross commented we should consider organizing the sections a little 
  differently.  We do not want too many details in the introduction, but we do 
  want to introduce some of the files.  Michael asked if the rest of the IBIS 
  specification follows this.  Bob noted some of the sections are different.  
  Walter noted he followed the structure of the EBD section, and that this is 
  an editorial issue.  Michael agreed and noted, if we are not consistent, we 
  will need to review the entire IBIS specification.  Bob commented it might be 
  better for follow the format of the Interconnect section.  Walter suggested 
  EBD and EMD could be separate documents, and this should be discussed in an 
  Editorial group meeting.  Michael suggested this should be discussed in the 
  IBIS Open Forum.  Bob noted separating the specifications would result in a 
  lot of overlap.

- Bob commented there are some syntactical rules that may not be documented, 
  and we may need some additional review of these.  Michael asked if there were 
  examples of this.  Bob noted there are some differences between Interconnect 
  and EMD.  In EMD, we can have multiple designator interfaces.  Walter 
  suggested to submit the issues in writing.  Bob stated he is not opposed to 
  submit this as a BIRD to get a number, but there is still significant work to 
  be done.  Michael agreed to get the comments in writing.


EMD Draft 27 review:
Walter showed the changes from draft 26.  He changed "module pin_names" to "EMD 
pin_names".  On page 14, Walter added text to define designator terminal and 
EMD terminal.  Bob asked if this applies to rail or IO pins.  Michael asked if 
we define the rail pins and I/O pins before this section.  Walter replied these 
are defined, and we are defining a terminal.  He noted a terminal only applies 
when you are talking about a model.  Bob asked what section this is in.  Walter 
replied this is under the [EBD Group] keyword.  These are the rules relating to 
the models in the EMD group.  

Walter noted, on page 16, "module" was changed to "EMD", there are also changes 
from "modules" to "pins".  There are similar changes on pages 22 and 23.  Bob 
suggested, on page 23, to add A_gnd to the Terminal_type list.

Michael asked if we need any diagrams to show the physical meaning of pins, 
I/Os, rails, etc.  Randy asked if a picture of a DIMM module would be helpful.  
Bob asked if this would be a board or a stacked die.  Michael suggested one of 
these would be a big addition.  Walter commented this is intended to replace 
the EBD for DIMMs, and a picture of DIMM routing would be useful.  Randy will 
look into adding a picture of DIMM routing [AR].  Walter suggested it would be 
good to look at an RDIMM with a Register and PLL.

Bob noted we can route the I/O signals from the designator to the EMD interface 
or to another designator.  Walter agreed this is an important use case of EMD.  
Randy asked if it would be helpful to look at a case with a series resistor.  
Walter suggested the resistor could be modeled inside the EMD model or as a 
separate designator.  Bob suggested the connections should be clearly 
documented, and he suggested to not connect these with a designator.  

Michael noted the term "connection" needs to be defined in IBIS.  Bob asked if 
we do not have a syntax that automatically shorts signals of the same name at 
the same interface of the same designator.  Walter replied there is no 
mechanism to short signals of the same name at a given interface.  Bob stated, 
at the EMD Set level, we might have two IO pins with the same name.  He asked 
how to handle this case.  Walter stated this is not the case for I/Os.  
Connectivity is not determined by the signal_name.  Bob commented there is an 
association issue.  Walter noted they could be be connected, which is defined 
in the email proposal he sent out.  There are good connections and not good 
connections.

Bob commented there are Aggressor_Only issues, where it is possible to 
determine that an aggressor tag of one I/O pin is added at any of the 
designator interfaces.  This propagates to all of the designators.  In 
interconnect, we determined this with pin_names.  We can route an I/O through 
different designators, and tagging one as a aggressor would tag them all.  
Walter suggested that the software can determine all of the connections and 
extended nets.  Randy asked what is the case Bob is worried about.  Bob 
replied, in the EMD file, we have an Aggressor_Only that is based on the EMD 
designators with the same signal_name.  This could be an issue when we have 
nested EMDs and multiple interfaces.  Walter stated the signal_names would all 
be connected.  Bob stated they would be shorted.  Walter noted you would have 
terminals at each interface, and this is not something people would do.  
Michael asked if this is a specific case and if it needs to be addressed in the 
BIRD.  Walter suggested we are using the common definitions of connected and 
shorted.  Bob will look for some examples to show the issue.

Walter will send out draft 28 [AR].  He intends, after the next meeting, to 
have a BIRD ready to submit to the IBIS Open Forum.  He suggested for comments 
to be submitted in writing.  Michael suggested to have a tracking list of 
comments.

Bob suggested, on page 25, to add A_gnd to the Terminal_type list and to Table 
41.


Next Meeting:
The next meeting will be January 8.


Randy moved to adjourn.  Walter seconded.  The meeting adjourned without 
objection.

================================================================================
Bin List:

EMD Comments to be Resolved:


IBIS-ISS Parser:
- IBIS-ISS parser scope document

Other related posts:

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