Minutes from the 21 March ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the work archive.
21-MAR-2017 Walter Katz SiSoft Reference_terminal BIRD draft 1 (zip
<http://ibis.org/atm_wip/archive/20170321/walterkatz/Reference_terminal_BIRD_draft_1.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170321/walterkatz/Reference_terminal%20BIRD%20draft%201/Reference_Terminal.docx>
)
28-FEB-2017 Radek Biernacki Keysight Technologies BIRD 158.4 AMI
Touchstonefile Analog Buffer Models draft 2 (zip
<http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD_158_4_AMI_Touchstonefile_Analog_Buffer_Models_draft_2.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170228/radekbiernacki/BIRD%20158.4%20AMI%20Touchstonefile%20Analog%20Buffer%20Models%20draft%202/bird158.4_draft2.docx>
)
IBIS Macromodel Task Group
Meeting date: 21 March 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 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:
- Arpad noted that he had cleaned up the Pending BIRDs sections of the agenda
email by removing BIRDs that had been approved (BIRDs 147.6 and 188.1) and
removing a duplicate entry for BIRD 158.3.
- Arpad noted that he had forgotten to renumber the list of agenda items in
this week's agenda email.
- Walter noted that he had prepared a new BIRD proposal to address the reference
terminal issue. He asked that we review it during the meeting. He noted that
it was related to the ongoing referencing discussion Bob R. and Radek had been
having (item #12 New BIRDs from the Editorial Task Group). Mike LaBonte noted
that since the Editorial Task Group had reconvened this item might move to a
lesser priority in ATM. Radek said that this issue was technical in nature
and
slightly more than just editorial, and he suggested it should maintain its
place on the ATM agenda.
-------------
Review of ARs:
- Michael Mirmak to submit BIRD 187.3 to the Open Forum.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Bob R.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow BIRD:
- Arpad: Fangyi said he could not attend today.
- Vladimir and I have sent him some comments on his proposal.
- A discussion is taking place.
- We are reviewing the convolution equations, which are now utilizing the
notation suggested by Walter and Todd.
- Anyone else feel free to comment on the proposal.
- Ambrish: Is the version from Jan 17th on the ATM website the latest?
- Arpad: Yes.
BIRD 158.4:
- Walter: I think Radek and I were waiting for Ambrish's review.
- Ambrish: Where in the specification will this BIRD actually go?
- Radek: In the AMI section.
- Ambrish: A new chapter?
- Bob R.: A new section in the AMI Reserved Parameters.
- Ambrish: Is there going to be cross referencing with this BIRD in the analog
buffer and [External Model] sections?
- Will there be a recommendation that the model maker should provide both
methods ([External Model] and BIRD 158) or just one?
- Walter: Model makers have requested that they do the Touchstone this way
(BIRD 158) instead of using the [External Model].
- Nothing will force the model maker to use BIRD 158.
- Ambrish: We have some history for suggesting alternatives, C_comp is used if
C_comp_xxx isn't supported, for example.
- Radek: Based on your earlier comments, we already added the "in lieu of"
language. It explicitly states that this is a replacement for what is
in [Model].
- That statement can be expanded to say that if the model maker wants to have
the same functionality in both there is nothing wrong with that.
- Ambrish: Something to the effect that this BIRD 158 approach is only for AMI
simulation.
- The user should not expect other simulation types to utilize this.
- Radek: That can be added.
- We should probably clarify the general approach for this one.
- Ambrish: If both BIRD 158 and [External Model] are available, which one takes
precedence?
- Radek: That precedence is already stated. BIRD 158 replaces the contents of
[Model]. [External Model] is part of the [Model].
- Bob R.: I support making this a clean separation.
- You can't use BIRD 158 as a quick and dirty way to introduce a Touchstone
model in regular applications. BIRD 158 is only for AMI applications.
- I would explicitly add a new statement that if you have an [Algorithmic
Model] then you can use the Ts4file to replace everything in [Model] for
an AMI simulation per BIRD 158.
- Radek: That is the intent.
- Ambrish: Should there be any discussion regarding mixing Tx or Rx models that
use BIRD 158 or don't?
- Radek/Walter: No, there is no restriction. They can be mixed and matched.
- Ambrish: Did we clarify how package models will be handled?
- Radek: There were some good suggestions by Bob Miller.
- We can at least indicate the boundary of what is being included in the
Ts4file data.
- Whether we have to have the package model in an additional Touchstone file
is unclear at this moment if we leave it entirely to the user.
- Ambrish: I'll distribute this for further comment.
- Radek: The current working version is still draft 2 (Feb 28th ATM archives).
We know there are plenty of editorial issues to deal with if we decide
to move forward with this proposal.
- Walter: I think consensus is that we incorporate the discussions from last
week into a new draft.
- I think it would be clear and complete at that point.
- I think it's worthwhile for Radek to do it, and I will help.
- Radek: Okay, we can work on it.
- Arpad: There seems to be some urgency to this given discussions of what will
go into the next revision of the spec.
Walter's new BIRD proposal (reference terminal):
- Walter: [sharing the proposal]
- This is another attempt to address the voltage referencing issue.
- IBIS defines the derivation of "IBIS Data" consisting of I-V, V-T, ISSO,
and threshold voltages for a device under test (DUT).
- IBIS data assumes the buffer rail terminals are supplied specific rail
voltages prescribed by the [Voltage Range] or [* Reference] keywords.
- IBIS has assumed the test fixture reference was "ground", which was at 0.0V
relative to simulator "node 0".
- That assumption was made when data rates were 20 Meg. Now they are 56 Gig.
- "Ground" is no longer a valid concept. Voltages at I/O buffer terminals
must be measured relative to a local signal reference.
- The only possible local signal references in an I/O buffer are the rail
terminals of the buffer.
- Discussion: Walter asked if everyone agreed with the "definition of the issue"
statements. Bob R. disagreed and said that the construction of the I/V tables
remains relative to simulator reference "node 0". He said that high speed
simulation involved a different type of reference, which was where a reference
terminal concept comes in. He said the two should not be mixed. Walter
disagreed and said the two had to be mixed. He said the measurements of the
DUT were made relative to the test fixture reference node ("node 0"), but that
node (with rare exceptions) was usually one of the terminals of the device.
Michael M. also expressed concern at Bob's assertion that node 0 was somehow
smuggled into the I/V tables. Walter said that at DUT measurement time
"node 0" was simply the point where the black probe of the volt meter was
placed. He said this test fixture reference should be as close as possible to
the I/O buffer itself. Bob said this was a key misunderstanding, but Walter
asked that we defer further discussion on this point until after the full
review.
- Walter: [continuing the review]
- The BIRD introduces a new optional sub-parameter Reference_terminal.
- It specifies the rail reference terminal that is used to make voltage
measurements at all the terminals of the I/O buffer (except for control
terminals like stimulus, enable, etc., which are always relative to
node 0).
- The BIRD also defines which rail terminal shall serve as the reference when
Reference_terminal is not specified.
- The BIRD does not attempt to define how voltage measurements should be
compared to measurement threshold values in the IBIS [Model] when the
voltages measured at the rail terminals relative to the Reference_terminal
are not the same as the DC values given in the [* Reference].
- Reference_Terminal
- Required: No
- Value shall be one of the following (adopting the [Pin Mapping] names):
- pulldown_ref
- pullup_ref
- gnd_clamp_ref
- power_clamp_ref
- ext_ref
- pulldown_ref and pullup_ref are illegal for Input models
- Discussion: Bob noted the sentence stating that ext_ref was illegal unless the
[Model] contained an [External Model] was incorrect. He said they were
entirely independent concepts. Radek agreed. Walter removed the offending
sentence from the draft.
- Walter: [continuing the review]
- If there is an [External Model], the Reference_terminal must be one of the
ports of the [External Model].
- The map between Reference_terminal allowed values and [External Model]
port names is listed here.
- If you say the Reference_terminal is power_clamp_ref, for example, then your
[External Model] must have A_pcref.
- The Voltage at an I/O or rail terminal shall be:
Voltage at terminal = V(terminal, Reference_terminal) +
the value of the [* Reference] keyword corresponding to the
Reference_terminal.
- If no Reference_terminal is specified:
- All [* Reference] keywords that are zero have their associated *_ref
terminals shorted together. Any one of these terminals can then be used
as the Reference_terminal.
- If none of the [* Reference] keywords are zero, then the EDA tool can
choose any of the corresponding terminals as the Reference_terminal.
- On page 72, change:
The absolute GND is the reference for the V_fixture voltage and the
package model equivalent network. It can also serve as a reference for
C_comp, unless C_comp is optionally split into component attached to
the other reference voltages.
to:
The Reference_terminal shall serve as a reference for C_comp, unless
C_comp is optionally split into reference terminals.
- Bob: The last section now mixes extraction and simulation.
- We had assumed in the notes on derivation that we zero out all packages and
have perfect supplies.
- So it's equivalent to C_comp going to ground.
- C_comp includes by definition all the capacitance to all the exposed
terminals.
- So I have a problem saying C_comp now has to go to any terminal listed as
0 in its [* Reference]. We would now be arbitrarily deciding that C_comp
is really C_comp_xxx to a particular terminal.
- We could be redefining things in a way that isn't consistent with
extraction.
- I do like this idea of a sub-parameter.
- I think we should provide a list of suggestions but not new rules.
- Discussion: Walter said the fundamental point is that you can only make
measurements on a buffer pad (especially the I/O pad) relative to the rail
terminals of that buffer. Only the rail terminals and the I/O pad are
available to the actual measurement probe or the simulator. Bob disagreed
and said with a simulation you're free to measure your voltages relative to
any node. Walter disagreed and asked Bob to draft an email to ATM containing
his concerns. Walter said he would send his proposal to Mike LaBonte for
posting.
- Radek: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Walter and Radek to work on a draft 3 of BIRD 158.4.
AR: Walter send a draft 1 of his Reference_terminal proposal to Mike LaBonte
for posting.
AR: Bob Ross to email ATM with his concerns about the Reference_terminal
proposal.
-------------
Next meeting: 28 March 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives