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

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 July 15, 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 Mirmak convened the meeting.  No patents were declared. 
Michael also took the minutes.

No patents were declared.

The team reviewed two sets of minutes, from the July 7 and July 8, 2020.
Michael displayed both sets of minutes for review by the attendees.
He noted that the text for the July 7 meeting included a comment 
about keeping some of the "statement" regarding the EMD models.  This should
instead be "statements".

Arpad Muranyi moved to approve the minutes with this change.  Lance Wang
seconded.  There were no objections and the minutes were approved. 

For the July 8 minutes, Randy Wolff moved to approve the minutes as written.
Arpad seconded the motion.  There were no objections and the minutes were 
approved.

ARs:
Randy will send out EMD draft17 - DONE

During Opens review,  Bob Ross noted that he has a suggested revision of a 
rule mentioned in a last meeting.  Michael responded that this can be dealt 
with later in the meeting, if time permits.

Randy presented draft 18 he has started.  

On page 13, a comment appears reading "need to add statement about use of 
NC for prototype/incomplete models."  Randy noted that the text had been 
changed from last time regarding requiring all pin names to be listed.  The 
text applied only to I/Os earlier, but now the intent is to group rail pins
into that same statement.  How to handle incomplete models, or models used 
for prototyping would become a "cookbook type of statement."

Bob noted that this is a suggestion of one usage, but the rule does not 
prohibit using a NC pin if the pin exists and is truly not connected.  
Arpad replied that the concern is to distinguish between a pin that is not 
connected versus one that has not yet been populated

Randy suggested putting this text earlier as part of the statement, "In 
addition, 'NC' is a legal signal_type..."  Michael asked whether this is 
meant to resolve a requirement for connection rules that are cross-
checked.  Arpad suggested adding it as a parenthetical to the earlier 
statement.  Randy made this change.

On page 16, Randy had already changed the usage rules for [Begin EMD] 
to remove mention of Touchstone terminals.  Michael pointed out the 
inconsistency in "Begin EMD" vs. "EMD Group"/"End EMD Group" structure, 
but did not ask for a change in any of the keywords.

Also on page 16, Randy removed the red instruction text as it was not 
intended to be part of the BIRD.  Similarly, on page 17, Randy removed 
"ADD a New Section 13?:".

On page 21, the bulleted EMD Model descriptions for power delivery 
network modeling need integration; Arpad noted that they need to be 
integrated with the EMD Model rules.

Bob stated that the rules are for rail-only, but the entire section 
covers I/Os and rails.  Michael asked whether power delivery had even 
been mentioned yet at this point in the document.  Bob replied that the
small bullets are just examples, while the new material is the actual 
rules.  Randy added the statement "In the case of rails:" preceding the 
bullets to inroduce the requirements.  Randy also edited the text to 
include proper "shall" and "may" language (the latter to replace "can").  
Arpad suggested additional gramamtical and style edits, including removal 
of periods and correction of case.

On page 26, red text remains for a rule for I/O terminals without 
Aggressor_only terminals.  Arpad and Bob agreed that, without 
Aggressor_Only, an I/O terminal may be either aggressor or victim.  
No text changes were made, but some formatting was fixed by Randy.

On page 27, under bus_label, a comment notes that there is no example 
for "Pin_Rail bus_label U7.VDD"
Bob stated that, for VDD in current examples, you may have bus_label 
for some of the connections.  Randy replied that he was not sure if an 
example is needed at all.  Arpad agreed.  Randy replied that multiple 
examples of the syntax are present later.  Bob suggested adding a text 
comment to an existing example.  Randy deleted the document comment.

On page 35 in rule iv., "At any one interface and for all [EMD Model]s...", 
Randy noted that review was needed for branching topologies.  Bob stated 
that the rule should be that, if the EMD Group contains references to 
sets or models within a set, specifically to two different models, only 
one duplicate pin name is permitted.  The rule is not that *no* pin name 
is permitted; one or two are, but three or more would be illegal.

Arpad asked whether splits in EMD were supported.  The purpose there was 
to support stacked-die structures.  Randy replied that it would be within 
an Interconnect model (inside the subcircuit).  Here, however, it is as 
if every EMD model is one trace, and one splits the trace up one EMD at 
a time.

Bob asked whether this was splitting the trace up into different paths.  
Randy asked in turn whether covering this is expecting too much of the 
EDA tool.  He was not sure why someone would want to create an EMD model 
for every segment of routing; it would be more sensible to include 
everything in subcircuits.

Bob noted that the terminal in EMD is defined once.  Randy agreed, adding 
that we want them at places where we are connecting models, or at major 
interfaces like package balls or DIMM connectors.  Bob compared them to 
a stacked die.  Michael asked whether this was intended as a measurement 
point.  Randy replied that you can bring out test points already.  Bob 
added that this is either a real terminal or a point.

Bob stated that we do not want connections going off in three different 
directions, for example.   \Randy replied that one can combine S-parameter 
blocks, too; there's no real justification for this syntax. We do not need 
that cascading feature.  Bob disagreed, saying we need it because we will 
"blow a hole" in the whole specification otherwise, as cascading is often 
assumed.  You can, for example, cascade the reference pads with the I/O 
pads, combining models.  True, you would likely perform the cascading 
within the IBIS-ISS model, but we should not require it as part of the 
specification.

Bob observed that one could get different results for different tools.  
Randy asked for alternatives.  Arpad advocated for simplicity.  Randy 
asked whether this extended to not allowing cascading.

Bob stated that the team must eliminate the complication associated with 
Aggressor_Only.  This includes which groups of paths are pulled in when 
we have I/O terminals that are documented without aggressor only.  

Randy will send out draft 18 [AR].  Arpad moved to adjourn, and Randy 
seconded the motion.  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