Minutes from the 31 May ibis-atm meeting are attached.
The following document, which was first posted April 7th of 2015, was
reviewed during the discussion.
07-APR-2015 Randy Wolff Micron Technology C_comp Model Using IBIS-ISS BIRD
draft 6 (zip
<http://ibis.org/macromodel_wip/archive/20150407/randywolff/C_comp_Model_Using_IBIS-ISS_BIRD_draft_6.zip>
)(dir
<http://ibis.org/macromodel_wip/archive/20150407/randywolff/C_comp%20Model%20Using%20IBIS-ISS%20BIRD%20draft%206/>
)
IBIS Macromodel Task Group
Meeting date: 31 May 2016
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
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
C_comp Improvements:
- Randy: I've started with the last revision of this BIRD draft, approximately
a year old, and I'm converting it to the new BIRD template.
- The first thing in the new template is the Solution Requirements table.
- I've drafted the rough text of the entries in the Solution Requirements
table, and I wanted to discuss the requirements with the group and come to
agreement on them before I proceed.
- [Sharing Solution Requirements table from new BIRD draft]
- Requirement #1: Allow an IBIS-ISS subcircuit or Touchstone file to be
used as a C_comp model.
- Note #1: Up to three models should be allowed to cover typ/min/max corners.
Define how they align with corners.
- Discussion: Arpad asked if the Note indeed meant no-more-than three.
Randy said the intention was that you might have one subcircuit (or
Touchstone file) for each corner, or one that served for all corners, but
that three would be the max.
- Requirement #2: Define the terminals of the C_comp model including
references, signal (both internal and external to allow a series R model)
and a receiver terminal for probing the input buffer.
- Note #2: Terminals for single-ended and differential models should be
defined.
- Discussion: Mike asked if probing the input buffer were optional or
mandatory? Randy said the model could include this terminal and the EDA
tool could optionally use it. He said the reason for specifying that
terminal was that one may have some series R or C filtering between the pad
and the actual input receiver, and that Micron had found it very useful to
be able to probe that node. Bob noted that a series C could cause problems
for many tools, and Randy agreed and said we should restrict that series
element to a resistance [change already made in the text above]. Randy
also said the Note might actually be considered a separate requirement.
Arpad agreed and said we might need to clarify pseudo vs. true differential.
Arpad noted that true differential is only available with [External Model].
Bob said we might require that this works with or without External Model.
Walter noted that true differential is really only available with [External
Model], in which case C_comp or this new C_comp model would not be used
anyway. It would all be embedded in the [External Model].
- Randy: [Sharing C_Comp Model Using IBIS-ISS draft 6 (posted April 7, 2015)]
- Discussion: Randy briefly reviewed Figure Y in order to discuss the internal
and input buffer terminals (A_signal_I and A_receive). Walter asked if this
figure meant that for an I/O the A_receive section just goes into the [POWER
Clamp] and [GND Clamp] curves, and the A_signal_I section goes into the
[Pullup] and [Pulldown] curves? Walter said his interpretation of the
figure was that the receiver is always receiving, and its load would be
captured in the clamping tables. The driver aspect would be completely
switched off if the buffer weren't driving, and that aspect would be
captured in the [Pullup] and [Pulldown] tables. Bob said that his
interpretation was that driver mode was represented by the top buffer in the
figure, and the receiver part was disconnected when driving, so the driver
portion also considered the clamping tables. The receiver portion is
switched in during receive mode, but the generalized C_comp model can
support a different path from the signal pad to the receiver. He said the
A_receive was a new terminal not in the current multilingual. Arpad stated
that it didn't necessarily require a new terminal because at simulation
time the device is either in driver mode or receiver mode (can't switch
during the simulation) so the node would either be one or the other. Bob
agreed that this was possible if the generalized C_comp model had a way to
switch between driver and receiver modes. Randy pointed out that a series
element in the path to A_signal_I was the result of an on-die interconnect,
where the series element in the path to A_receive might be there for
intentional filtering. Arpad noted that we didn't have to solve the actual
implementation issues (new terminal vs. two separate C_comp models for
driver or receiver mode) at this point.
- Requirement #3: Explain handling of the reference for Touchstone files.
- Note #3: [none]
- Discussion: Radek and Mike recommended this be changed to the general
statement shown above, and said this can ultimately rely on the solution
being worked out in the interconnect meetings.
- Requirement #4: Define how parameters can be instantiated and passed into
the IBIS-ISS subcircuits for each of the typ/min/max corners.
- Note #4: Parameters should be single values that can be passed into either
the typ, min or max corner subcircuit. Parameters are not meant to define
ranges.
- Discussion: Randy noted that the interconnect task group allowed only single
valued parameters to be passed into a subcircuit. For this C_comp proposal
we need a way to pass parameters into one of three subcircuits (corners),
but that his intention is that those parameters are still single valued
and not ranges, etc. Bob pointed out that we would need to carefully define
how the C_comp subcircuit corners align with the typ/min/max model corners.
Randy agreed and added this definition of alignment to Note #1. Mike noted
that we might want to require that the three subcircuits for the corners
all take the same parameters, since we probably want to avoid a case
where the typ subcircuit takes a param called typ_ABC while the max
subcircuit takes one called max_ABC.
- Requirement #5: Explain hierarchy of the new C_comp model with existing
keywords including [C Comp Corner] or any other C_comp* models.
- Note #5: The new C_comp model should override other C_comp models. May need
to explain how a simulator could use traditional C_comp* values for K-T
curve generation.
- Discussion: Randy said this requirement captured the need to describe how a
simulator would actually use this new C_comp model. For example, we might
adopt Walter's suggestion and describe how legacy C_comp is used only to
generate the K(t) curves, and then the new C_comp model is inserted at
simulation time. Bob expressed concerns about the alignment of various
C_comp parameters and or the [C Comp Corner] parameters. Walter said he
thought we would need to require the use of [C Comp Corner] because
every v(t) curve has to be compensated for C_comp, and we need to know the
right C_comp for each corner. Bob agreed. He noted that some tools made
assumptions about how to choose standard C_comp parameters to match various
corners, but that would open up a whole separate set of issues.
Referencing Question:
- Discussion: Walter reviewed a brief email he had sent to the ATM list. We
have three voltages VDD, VSS (the rails) and V at the I/O (IO) all relative to
some simulator reference node. Does everyone agree that the operation of the
buffer is only a function of two of the following three voltages?:
1. VDD - VSS
2. VDD - IO
3. VSS - IO
The third can be derived given any two of them. Arpad said he tended to agree
with this statement, since we have two I/V curves based on VDD-IO and IO-VSS.
Radek felt the question was too simplified since it said nothing of the load.
Arpad asked what the exact purpose of asking the question was. Walter said he
would send out another email and rephrase the question and explain its intent.
- Bob: Motion to adjourn.
- Mike: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 7 June 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
