======================================================================
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 June 8 Meeting (* means attended at least using audio)
ANSYS                              	Curtis Clark*
Cadence Design Systems             	Bradley Brim
Cisco                             	David Siadat
Intel Corp.                        	Michael Mirmak
Keysight Technologies              	Radek Biernacki*, Ming Yan*
Mentor Graphics                    	Arpad Muranyi*
Micron Technology                  	Justin Butterfield*, Randy Wolff*
SAE ITC                            	Maureen Lemankiewicz, Logen Johnson
Signal Integrity Software          	Walter Katz, Mike LaBonte*
Teraspeed Labs                     	Bob Ross*
University of Aveiro in Portugal   	Wael Dghais

Mike LaBonte convened the meeting. No patents were declared.

Minutes from the June 1 meeting were reviewed. Radek Biernacki commented
that it was difficult to correlate items related to the numbered Interconnect
BIRD draft requirements because the document had not been sent or posted. Bob
Ross moved to approve the minutes of the June 1 meeting. Radek seconded
the motion. No objections were raised and the motion carried.

Mike showed Interconnect BIRD draft 35+requirements. The requirements section
was reviewed. Mike said this document contained some changes as discussed in
the previous meeting, but it had not been posted as draft 36.

Mike said the statement that coupled models would be supported was moved to
the notes column, and the only actual requirement would be that models with
connections for multiple pins must be supported. Bob said coupling should be
assumed for those models.

Looking at requirement 5, Randy Wolff noted that we did not agree to support
assigning I/O terminals by signal name. We looked at the Terminal Type
Associations table and found that I/O terminals were indeed not assignable
by signal_name. Mike changed the requirement.

Looking at requirement 8 Bob asked why we would allow both legacy and
new models for a [Component]? Radek said there should be a stated order of
precedence if they overlap. Randy noted that requirement 14 covered that. Radek
said there might be overlap between IBIS-ISS and TS models, and we might
want to set a precedence for those. Mike felt that the EDA tool and/or use
would have to make those choices based on needs at the time of analysis.

Mike described requirements 9, 10, and 11, in terms of the procedure an EDA
tool would likely use to assemble a final circuit. The selected models might
cause additional pins to enter an analysis, above and beyond the initial pin
selection. Bob said for example one might have only a single pin to analyze but
the only available model is coupled. He said that would be OK.

Looking at requirement 12 Mike said we had previously discussed requiring
the full path from buffer to pin to be modeled if the pin is modeled at all.
Randy said some models would necessarily span only from buffer to pad (ball),
but tools would work that out. Radek suggested someone might use a legacy model
for the package portion and a new model for the die portion. Mike said legacy
packages are already considered to span from buffer to pin, so it would be
inconsistent to use them for only the package portion. Given Randy's comment
about buffer to pad models, Mike deleted the note for requirement 12 stating
that that would be disallowed.

Looking at requirement 15 Mike explained that for example we should not use
the combination of [Pin] RLC models for the "through pin path" and a new model
for just the crosstalk coupling. Radek agreed.

Mike said requirement 16 related to the discussion about the Aggressor
qualifier, but it actually required identification of suitable victim pins,
not aggressors. Radek said any multi-pin model should be assumed to have
coupling. Mike noted that some pins could be either victim or aggressor,
not supported by Mike's suggested syntax. Radek agreed pins must be able to
serve as both.

Bob said tools might have trouble with the complexity of using various sets
of interconnect models to derive a complete and reasonable arrangement of
models. Mike said that only one set at a time would be used.

Bob said there was an issue regarding near end and far end crosstalk, making
it difficult to determine whether to state victim/aggressor relationships at
outputs or inputs. Mike said that crosstalk appears at both ends always. Bob
agreed.

Mike showed an email from him suggesting a syntax that would
both identify which pins have coupling, and which kind of coupling.
Randy said it may not be appropriate for the model maker to label a pin as
aggressor only. Radek agreed, saying that would be a user choice.
Bob suggested that interconnect model sets could have information indicating
something about the scenario it can be used for. Randy said for example it
could be useful to know which model has more coupling than others.

AR Mike LaBonte post Interconnect BIRD draft 36

Bob moved to adjourn. Radek seconded. The meeting adjourned.