Minutes from the 21 February ibis-atm meeting are attached,
IBIS Macromodel Task Group
Meeting date: 21 February 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
Cisco: Seungyong (Brian) Baek
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 Graphics: John Angulo
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Bob Ross to submit BIRD 186.1 to the Open Forum.
- Done.
- Arpad to email the Open Forum regarding BIRD 186.1.
- Done.
- Arpad to email the Open Forum regarding BIRD 147.6.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Two sets of minutes needed review, as the February 7th minutes were not
prepared and posted in time for the February 14th meeting.
- February 7th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Bob R.: Second.
- Arpad: Anyone opposed? [none]
- February 14th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 187.2:
- Discussion: Radek noted that the Open Forum had deferred the vote on
BIRD 187.2 after he had pointed out some inconsistencies in a new sentence
describing Format Increment:
The Increment Format defines, for Usage In and InOut, a range of
discrete integer values which can be swept by the EDA tool using a
specified value ("delta"), where min <= typ <= max and delta is
always positive.
Radek noted that the text seemed to mistakenly imply the values defined by the
increment were integers. In addition, "swept by the EDA tool" was a new
descriptive phrase not used elsewhere and perhaps not desirable. Walter and
Arpad asked Radek to take the AR to send an email to Michael Mirmak (and the
ATM reflector) to make him aware of the issue, as he had not been on the Open
Forum call and likely was not yet aware of the issue.
BIRD 158.3:
- Walter: [sharing a draft BIRD 158.4 from a private email with Radek]
- Radek: I changed some information on packaging and requirements for the BIRD.
- We should discuss it.
- Walter: Some graphics have changed.
- We've replaced the earth ground symbol with "reference."
- I recommend we change the symbol to the triangle local reference symbol.
- Ambrish: I've been waiting for the updated version to start my review.
- Radek: There are some minor differences between this and 158.3.
- One issue is a bit more important. It involves the question of whether the
4-port data file includes the package or not. I think users and model
makers might want the flexibility of not including the package in the
4-port
data file and providing the package model in an additional 4-port provided
with the channel.
- Discussion: Walter noted that intent had never been to include the package
model in the 4-port data file. It has always been referred to as the on-die
interconnect, and it was an alternate method for what could be in [External
Model], which was also on-die. Walter then observed that a sentence in the
introductory text that said "including the Tx package" was a mistake and was
meant to say "not including". This might have caused the confusion. Radek
noted that if we decide to pursue this BIRD we might want to elaborate on each
possibility (including the package or not including the package). Walter said
he felt that it would complicate the BIRD if it went beyond on-die
interconnect. He noted that if a model maker wanted to include the package
in the 4-port data file then it could be done, and any legacy location for the
package model should contain a null package in that case. Arpad asked how the
package model would be provided, if the approach of this BIRD is to bypass
everything in the IBIS file. Walter clarified that the BIRD intends to bypass
everything in the [Model], not entire IBIS file. So, package models could
still be provided by the IBIS file. Arpad noted that if the BIRD makes it
clear that it only replaces the [Model], then it shouldn't be hard to make
this BIRD compatible with the other approaches to providing the on-die
interconnect.
- Ambrish: If you read in an IBIS model, and you could potentially get the same
information about the analog model for the on-die interconnect from
two places ([External Model] or the 4-port from this BIRD), does this
BIRD make it clear how that's handled?
- Discussion: Radek noted that this BIRD says the information from the IBIS
[Model] is bypassed. So, both the traditional [External Model] approach and
this BIRD's 4-port could be present at the same time. If a tool doesn't
support this BIRD then it could use the [External Model] approach. Walter
said that, as currently written, the BIRD would not obligate the model maker
to provide the [External Model] equivalent. He said the BIRD was written for
model makers who did not want to deal with [External Model]. Radek said this
BIRD could be considered AMI only in that sense. Walter suggested that a tool
could extract the information from the .ami file even for a non-AMI
simulation if it wanted to. Walter and Radek noted the "in lieu of the analog
model" statement as an answer to Ambrish's question. Ambrish noted that this
statement was in the supporting documentation for the BIRD, but not in the
text that would actually be part of the spec. Ambrish said that text in the
spec should address any issues regarding multiple ways of specifying the same
data and how the data should be used.
- Editorial Discussion: Arpad asked that the terminals 2 and 4, labelled as
"to channel", be changed to "Buffer terminal". Radek/Walter agreed. Bob R.
said the parameter name "Tstonefile" should be changed to something else, such
as "Ts4", since this BIRD is restricted to a four port model. Bob also noted
that Touchstone format supports Y and Z data as well, so the BIRD should not
say S-parameter data. Radek suggested this could be changed to Touchstone
data. Bob noted that he felt this BIRD was restricted to the specific role in
AMI simulations, since the Touchstone model in this BIRD had additional
information folded in with the passive interconnect model. He noted that
Touchstone files provided by this BIRD were restricted to one direction of
flow.
- Walter: I'll send the current draft to Radek, and he can incorporate the
changes we've discussed.
- Radek: Okay.
- Arpad: Let's get this posted with today's changes, so we can all review it.
Single Ended Applications of AMI:
- Walter: I think we need Fangyi and Michael M. here for this topic.
- Radek: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Radek to email Michael Mirmak and ATM regarding BIRD 187.2.
AR: Radek to send out the modified draft of BIRD 158.4.
-------------
Next meeting: 28 February 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
