======================================================================
IBIS INTERCONNECT TASK GROUP
http://www.eda.org/ibis/interconnect_wip/
Mailing list: ibis-interconnect@freelists.org
Archives at http://www.freelists.org/archive/ibis-interconn/
======================================================================

Attendees from August 5 Meeting (* means attended)
ANSYS                                        Curtis Clark
Cadence Design Systems                       Bradley Brim
Cisco                                        David Siadat
Intel Corp.                                  Michael Mirmak
Keysight Technologies                        Radek Biernacki*
Mentor Graphics                              Arpad Muranyi*
Micron Technology                            Justin Butterfield, Randy Wolff*
Signal Integrity Software                    Walter Katz*, Mike LaBonte*
Teraspeed Labs                               Bob Ross*
University of Aveiro in Portugal             Wael Dghais

No patents were declared.  No opens were raised.  The discussion focused on
the alternative proposals for the "Terminal" structure in the draft
Interconnect BIRD.

ARs:

Walter: I had an AR to generate examples. Things have been simplified. Bob and
I came to an agreement in list emails.

Terminal Syntax:

Walter showed an email sent to the ibis-interconn reflector.
Walter said that pre-layout features had complicated the problem, so he had been looking at a
postlayout-inly solution.
Arpad: Lack of pre-layout was a stumbling block, wouldn't some of my proposals
uch as "sliders" elp.
Walter: I can show how a pre-layout IBIS file could use post-layout interconnect.
He said for a buffer instance we only need to know the pin number. The pad and
all "ref" terminals are associated with the pin. This syntax eliminates the
"A_".
Each pin is associated with a signal.
Pads are associated with pin and signal name, but also have a pad name.
There is no relationship between supply pins and any specific die pad.
A rail is associated with a signal, but not a specific single pin.
Bob found some minor problems with this.
The example is simple.
Bob: A model name can't be assigned to supply pins.
Wsalter showed an example.
- Arpad: What is the meaning of Buffer here?
Walter: We used to call that A_signal.
Arpad: I would prefer the existing names.
Walter; We end up with different forms of A_signal for true differentials.
Bob: For [Series Pin Mapping] it is documented in IBIS.
Radek: "I/O_Buffer" is a good name.
Bob: It is really the Model location.
Arpad: Models have multiple terminals, we need to distinguish.
Walter: We might use "Buffer_Rail" as an alternative. There can be circuits
connecting various combinations of object kterminals. For prelayout we can
have a prelayout IBIS file. A package model from the prelayout file can be
applied to all of the DQS pins in the full IBIS file.
Radek: A cross-IBIS file implementation might have hazards.
Walter: It would be easy to replicate the prelayout calls in the full IBIS
file.
Radek: That would abandon the model name. An IBIS file could have both of
these use models and we could choose which one we want.

Walter: One issue is that for pseudo-diff what gets applied to DQS+ impicitly
is applied to DQS-.
Bob: If you use independent I/V curves it becomes psuedo even if called true.
Even for true diff you have to designate both pins.
Walter: Even though each side does not connect to both pullup and pulldown?
Bob: It may not even relate to I/V tables. Even a true differential model such
as LVDS does have supplies.
Walter added syntax covering this to the examples.
Bob: I/O_Diff imples true differential. It should be legal to designate both
PUrefs.
Walter: For pseudo there is no [External Model]. Do we still provide both terminals?
Radek: 
Walter: I will change the example to reflect that.
Bob: We probably will not check that each buffer has a rail connection. If we
don't pin out all of the supplies internal supplies will be used.

Walter: If we have 128 DQ pins the small prelayout example would suffice to
model all of them. Walter showed a live example of building a postlayout model with crosstalk by copying and pasting from prelayout content, identifying the aggressor pins.
A simulation of the worst 3 nets would avoid the need to simulate all 128.
Radek: This is like a slider.
Walter: This is often done for serdes designs.
Bob: Why would the aggressor be at the buffer, not the pin?
Walter: It could be either, I just did it that way.
Bob: Rail is already covered by pad signal name.
Walter: This is buffer rail. We add a [Buffer Rail Mapping] keyword for this.

AR: Walter update BIRD examples with new syntax.