Minutes from the 19 July ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
19-JUL-2016 Randy Wolff Micron Technology C_comp Model Using IBIS-ISS or
Touchstone BIRD draft rev 1 (zip
<http://ibis.org/macromodel_wip/archive/20160719/randywolff/C_comp_Model_Using_IBIS-ISS_or_Touchstone_BIRD_draft_rev_1.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160719/randywolff/C_comp%20Model%20Using%20IBIS-ISS%20or%20Touchstone%20BIRD%20draft%20rev%201/C_comp_Model_Using_IBIS-ISS_BIRD_diff.pdf>
)
IBIS Macromodel Task Group
Meeting date: 19 July 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
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that he had decided to remove the "Pin Reference Concerns" item
from the agenda, as Bob had completed his presentation last week. He noted
that any related discussions could continue under the "IO Buffer Reference
Terminal" topic. No one objected.
-------------
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]
- Radek: Motion to approve the minutes.
- Bob: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Improved C_comp proposal:
- Randy: [ sharing 'C_comp Model Using IBIS-ISS or Touchstone BIRD draft rev 1']
- We can walk through changes today and wait for comment and feedback offline.
- BIRD text from the year-old draft moved into the new BIRD template 1.3.
- Solution Requirements section: Updated based on feedback from the recent ATM
meeting where we discussed it [May 31, 2016 ATM meeting].
- Text has been updated using newer language from the Interconnect BIRD draft.
- Trying to tie it in better with how it might be used in the specification.
- [Summary of Proposed Changes: section]
- New C_comp Model.
- Existing C Comp Corner keyword is required if using C_comp Model.
- So EDA software can use the C values in C_comp Corner for computing the
K-T compensation functions.
- A new location can be specified for the Si_location and Timing_location
Sub-Params.
- Currently values are Pin and Die. Die should be interpreted as Pad.
- Adding a new value "Buf" to refer to the Buf_rx* terminal(s) of a
C_comp Model.
- Discussion: Bob and Arpad noted that in the past pad and buffer terminal had
been one and the same. Arpad noted that this is the first feature that will
acknowledge the non-ideal connection between buffer terminal and die pad.
Randy noted that this is a way to indicate to an EDA tool that we want a
waveform measurement from a certain location (a new location). Arpad noted
the [External Model] had provided some capability to observe the waveforms
after the [External Model]. Walter said we may want to add "Pad" as an
alias for the existing "Die" value, so that we can have Pin, Pad, Buf as is
done in the Interconnect BIRD. Bob agreed with this idea. He noted that,
unfortunately, without an on-die interconnect, this alias would still mean
the Buf location.
- [Usage Rules: section]
- Added a sentence stating how the EDA tool may use C Comp Corner for the
K-T extraction.
- This is the only real statement on how the EDA tool could compensate for
having this much more complicated C_comp Model.
- Discussion: Arpad wondered if the "K-T" terminology should be changed to
something more general to describe the issue more broadly. Radek noted
that it could be better defined, but that the concept is already used in
the spec for the power aware models [ISSO_PU, ISSO_PD keywords: note,
however, that terminology in that section is of the form Kpu(t) and
Kpd(t)].
Bob said he felt that this BIRD should only be concerned with
the location of electrical terminal connections. The group agreed to
consider this terminology later, with suggestions including "compensation
algorithm", "waveform processing", and "v(t) curve shaping".
- [Sub-Params of C_comp Model]
- Param (optional, only valid with File_IBIS-ISS)
- File_IBIS-ISS (either this or File_TS is mandatory).
- File_TS (either this or File_IBIS-ISS is mandatory).
- Number_of_terminals (mandatory).
- Param
- Used for passing parameter values into an IBIS-ISS subcircuit.
- Unlike in the Interconnect BIRD, we need to be able to pass in corner
values.
- Can pass in a single value or a corner type value.
- [Number_of_terminals and Terminal line rules:]
- The intent is that we don't want to have to deal with a 50 terminal
subcircuit and how to terminate all the terminals that don't correspond
to a C_comp Model terminal.
- The number of terminals in the subcircuit should match the number of
terminals defined for the C_comp Model connection.
- Discussion: Arpad asked if the intention of this was that a five
terminal subcircuit could not be connected to a 3 terminal buffer model.
Walter said that this was the intent, and that, for example, an Input
model with only pc, gc, and input terminals would use a 3 terminal
subcircuit for its C_comp Model. Bob, Radek and Arpad expressed concern
about this concept, and noted that a terminal might exist in the model
even if no I/V table were defined for it, or that it might not be clear
what the terminal count should be if two terminals, such as pu and pc,
were tied together. Arpad noted that two *_ref terminals having the
same [* Reference] value would not imply that they could be treated
as tied together, since the package model might connect to them
differently. Radek summarized by stating that we have possible terminals
to connect to, and we have the actual number of terminals for the model at
hand, and we need to specify them properly. He noted that he still
objects to the fact that there is still no provision for providing the
reference terminal for the I/O signal, which would make it impossible for
this C_comp Model to fall back to model the standard C_comp. Walter
pointed out that Ext_Ref was one of the available Terminal_type
definitions and could be specified. Radek felt that Ext_ref generally
has a different purpose and meaning.
- [Figure Y:]
- If your C_comp Model has some series resistance or inductance elements,
then you can separate out new internal nodes for the input and output.
- Discussion: Radek expressed concern about the use of Buf_I/O and DIE-PAD
together on the right hand side of the figure. Randy and Walter said the
C_comp Model is at the buffer level, but the figure assumes there might
be some on-die interconnect between them. Randy noted that this on-die
interconnect might even be built into the C_comp Model itself. Radek felt
the figure could cause confusion given the explicit mention of Die, Pad,
Buf added in the Si_location discussion. Walter noted that the appearance
of Buf_I on the right hand side of the figure made it look like Buf_I was
in input to the model along with the four rail voltages. Randy said it
was his graphical attempt to show that the new model allows for access to
all five of these terminals. Bob asked if this "Buf_I" was a modal
connection, in receiver mode there is no Buf_O, and in driver mode there
is no Buf_I? He suggested the possibility of switching in one C_comp
Model for driver mode and another for receiver mode. Walter said that he
had thought of it differently, and thought of Buf_I as a pc curve and a
gc curve, and Buf_O as a pu curve and a pd curve turned on and off by
K(t) functions. When not in driving mode, you would just get pc and gc.
Radek said that he thought Bob's idea for two distinct C_comp Models for
the two different modes of an I/O might be quite simple and elegant. He
felt it would allow all the capabilities shown in the figure without
forcing the model maker to deal with the complexity of combining the two
modes. Randy agreed that he liked the idea, and noted that he currently
does something similar when he wants to specify a different C_comp value
for the driver mode vs. various termination modes.
- [Figure Z: Differential C_comp Model]
- I have introduced language for a differential C_comp Model.
- I also prepared a version in which I simply removed this section.
- For single ended and pseudo-differential buffers we work fine with the
single ended form of C_comp.
- If we want a true differential model, the only we can currently do that is
with [External Model], but in that case C_comp is ignored altogether
because it's assumed everything is wrapped up in the [External Model].
- I'm therefore wondering if this differential C_comp Model would not be
very useful.
- Discussion: Walter noted that the approach shown in the figure had actually
proven useful for a sort of pseudo-differential approach where a "parallel
termination" (connection between the Buf_I/O_pos and Buf_I/O_neg) could be
could be created via a subcircuit. Radek noted that there was currently no
way to specify such a connection, given that it was made up of two single
ended buffers and [Diff Pin] currently has no provision to specify the
connection of this type of model. Walter agreed that this would require an
extension to the specification. Arpad noted an editorial suggestion based
on Radek's earlier comments, and suggested that "DIE-PAD" be replaced with
"buffer terminal" on the right hand side of figures X, Y, and Z.
- Arpad: AR for Randy to get this proposal posted to the ATM work archives.
IEEE P370 email discussion:
- Walter: IEEE P370 has three subcommittees.
- Intention is to create a document on how to get good s-parameter data, how
to measure it and how to correct it for things like causality, etc.
- This particular subgroup I'm on is doing the various analysis tools that one
can do on s-parameter data.
- This is a first draft written by the chair of the group.
- I want to take all your feedback back to the committee.
- Radek: I found it pretty disappointing.
- It's an imprecisely stated mix of guidelines and actual requirements.
- For example, stating that the current entering the plus terminal must
equal the current minus terminal is correct.
- On the other hand, you can't say a signal must be connected to a signal.
First, you must distinguish between a signal and a signal terminal, and
second you can't state that something must be done. You can say that there
are certain consequences, but you can't say something "must" be
connected a certain way. There are guidelines, and they should clearly be
stated as guidelines or intent.
- The goal of the project, as stated by Walter, is good.
- Walter: If you want to daisy chain s-parameter blocks by connecting a port of
one s-parameter block to a port of another, the assumption is that
the reference terminal should have been more or less the same when
both s-parameter blocks were measured. That's the point they're
trying to make, and I think it's connected to our reference
terminal discussions.
- Two contexts for reference:
- There's a voltage between two nodes, and one node is the "reference" node.
- When you have I/O going out to the outside world it has to be imaged, on
a plane, usually of its reference signal name. So there it means
something different than it does inside the buffer.
- Radek: If they're saying these are good guidelines, that's fine.
- But saying these are requirements is not true at all.
- Walter: They're not requirements for how to build the system.
- They're saying that it's required that you measure things a certain way.
- This is just a small subset of the project and not shown in context.
- Radek: S-parameters have been used for many years in many contexts, so this
document can't just take it over from previous users.
- Walter: This document is strictly confined to s-parameter measurements of
packages, connectors, boards, end-to-end.
- They do this because the IEEE802.3 has a COM [Channel Operating Margin]
that takes the s-parameter model of a channel from Tx pin to Rx pin, does
some Fourier arithmetic and tells you if the channel will work.
- If you're going to make the measurement for that test, you have to know how
to make the measurement properly.
- That's the background for this.
- Arpad: Thank you all for joining.
-------------
Next meeting: 26 July 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
