Minutes from the 19 December ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the ATM Task Group archive.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
19-DEC-2017 Mike LaBonte SiSoft Aggressor_Only diagram v1 (zip
<http://ibis.org/atm_wip/archive/20171219/mikelabonte/Aggressor_Only_diagram_v1.zip>
)(pptx
<http://ibis.org/atm_wip/archive/20171219/mikelabonte/Aggressor_Only%20diagram%20v1/Aggressor_graphic_1.pptx>
)
IBIS Macromodel Task Group
Meeting date: 19 December 2017
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Mike LaBonte. Curtis Clark took the minutes.
Arpad Muranyi was on the call, but he was traveling so Mike ran the meeting.
--------------------------------------------------------------------------------
Opens:
- Mike reviewed the schedule for upcoming ATM meetings. ATM meetings will not
be held on December 26, 2017 and January 2, 2018. The next ATM meeting will
occur on January 9, 2018.
-------------
Review of ARs:
- Walter to send BIRD189 draft12_v1 and his latest proposal to the ATM and
Interconnect lists.
- Done.
- Mike L. to post them to the Interconnect archives as BIRD189 draft12 and
draft13 respectively.
- Done. Walter noted that he had subsequently sent out a draft13.1 after
the Wednesday Interconnect meeting.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Mike L.: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Michael M.: Second.
- Mike L.: Anyone opposed? [none]
-------------
New Discussion:
Forward Error Correction:
- Mike L.: I proposed this topic for discussion, but I'd prefer to defer it
as long as any BIRD189 issues are outstanding.
- Walter: I don't think we need to consider it.
- FEC determines the bit pattern stimulus.
- We don't care about that. We only care about what physically goes down the
channel.
- Whether it's 8b/10b or 64b/66b or some FEC pattern, IBIS and IBIS-AMI don't
care about it at all.
[further discussion deferred so we can focus on BIRD189]
BIRD189 - Groups/Sets, Aggressor treatment.
- Mike L.: During the last interconnect meeting I hastily drew up a graphic I
think might be useful for the Aggressors discussion.
- [Sharing his graphic] (a crude ASCII representation is shown below)
Illustration - 8 Pin Component:
| | | | | | | |
1 2 3 4 5 6 7 8
Model 1 (first 3 pins - pins 1,2,3):
v v A
| | | | | | | |
1 2 3 4 5 6 7 8
Model 2 (pins 2, 3, 4):
A v A
| | | | | | | |
1 2 3 4 5 6 7 8
Model 3 (pins 3, 4, 5):
A v A
| | | | | | | |
1 2 3 4 5 6 7 8
v - victim
A - Aggressor_Only
- Mike L.: Do people think the BIRD would be helped by a visual like this for
the Aggressor_Only topic?
- Walter: Yes, this is worth discussing.
- Mike L: It may look a bit like swathing, but it's not. The intent is to show
3 models covering 3 different sets of pins.
- These examples are just worried about nearest-neighbor crosstalk.
- Michael M: I'd like to confirm that for the purposes of this example the 8 pin
illustration represents the entire device, right?
- Curtis: This point is important because pin 1 in Model 1 might not necessarily
be shown as a victim if there were potentially a pin 0 to the left of
it. Is that what you're getting at?
- Michael M: Exactly.
- Walter: I'd suggest Mike add a box around the top block of 8 pins that
indicates that it represents the whole Component.
- The three models shown could be in one Set included in one Group. That
would likely be the most logical way of packaging these models.
- This graphic could be very useful for illustrating the various combinations
of victim and aggressor.
- For example, let's assume Model 2 were removed from the figure and only
Model 1 and Model 3 remained:
- In that case, pin 3 would never appear as a victim and would appear in two
models as Aggressor_Only. This could help illustrate the point of a new
rule I added to address this situation, which was raised by Arpad.
- In addition, pin 5 would never appear as a victim and would appear in
only one model as Aggressor_Only.
- Randy: The new rule you added says that if the user tried to simulate pin 3 as
a victim in this scenario, then to find a model for it you'd use the
first model in the list that contains pin 3, right?
- Walter: Yes. Model 1 in this case. My new text says the "model maker shall
assume" that the first model will be used. The tool or user could
choose to select a different one.
- Walter/Randy: Of course it wouldn't make much sense for a model maker to
deliver a BIRD189 model that doesn't have every meaningful pin
listed as a victim somewhere.
- Michael M.: The way we might do this is to release a model that looks like
Model 2 in this example. We would say it represents the worst-
case crosstalk that is likely to be seen for this particular
collection of pins. We'd primarily only be interested in what's
going on in the center pin (or typically a center diff pin pair).
- Walter: That's a classic way to distribute a coupled package model.
- They might deliver a separate s2p for each pin for the single ended example
in this illustration. (an s4p for each pair if it were differential)
- They do this because the length of the interconnect might differ for each
pin, and small differences in that length can dramatically affect the
channel performance.
- Then they'll deliver an s2p for the worst-case crosstalk. This allows the
EDA tool to build the worst-case coupled model because it knows the through
path and the worst-case crosstalk.
- Another option would be that if you provide a model like Model 2 for the
worst-case crosstalk for a particular collection of pins, then the EDA tool
could go ahead and apply that same model for every victim pin of that type
(apply the same model for 1,2,3 and 2,3,4 and 3,4,5 etc.)
- This is more of a pre-layout way of distributing models.
- IBIS is describing a [Component] generally, and you'd be providing an IBIS
component that is really just for this 3 pin worst-case.
- For our internal tools I might even take that 3 pin Model, say it's for a
worst-case DQ crosstalk, and apply it for all the DQ lines. That way you
wouldn't even have to go and duplicate the same model in multiple instances.
That was a sort of pre-layout scenario we originally had in BIRD189, where
we had the model name associated with the pin. We took that out for other
reasons.
- Discussion: Bob expressed some concern that for the sake of completeness we
might want to show some Vdd and Vss pins and include PDN modeling aspects
in the graphic. Walter said we could do this, at the expense of complicating
the example, but that the current illustration was primarily for discussion
of the Aggressor_Only tag. Bob suggested that for differential examples we
might want to state that both pins in a differential pair should have the same
Aggressor_Only (or victim) designation. Walter agreed that we might say
Aggressor_Only on a pin applies to the pad and buffer as well and also
applies to the other pin of a diff pin pair.
Bob suggested that he wanted a statement that we allow interconnect models in
which no pin is tagged as Aggressor_Only. He said the EDA tool should be
capable of making decisions about what to include in a simulation. Mike L.
noted that Bob was reaffirming that Aggressor_Only is optional, but said the
purpose is to give the model maker a way to flag the limitations of the model
if necessary. Walter noted that the EDA tool can always do what it wants to
do. The Aggressor_Only flag is simply recognizing that sometimes you cannot
make a model where every pin has all of its aggressor information. You need
a way of indicating when you have a model in which certain pins do not have
all their aggressor information.
Bob suggested that at the following Interconnect meeting we review a BGA
package model diagram Randy had presented and discussed in the August 10, 2016
Interconnect meeting. He felt it would be useful to revisit it in light
of these discussions.
- Arpad: Thank you all for joining. Happy New Year.
-------------
Next meeting: 9 January 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
