Minutes from the 16 April ibis-atm meeting are attached.
The following document was discussed during the meeting and can be found at the
ibis.org website:
BIRD197.3 draft 2<http://ibis.org/atm_wip/archive-date.html>
IBIS Macromodel Task Group
Meeting date: 16 April 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Stephen Slater
Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
* Mike LaBonte
SPISim: * Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that he had one question that might ultimately be better suited
for
the Interconnect Task Group. With respect to Interconnect Models (BIRD189),
is
the value of Number_of_Terminals always N+1 for a File_TS model (where N is
the
number of ports in the Touchstone file), even if there are unused terminals?
The answer is yes. Number_of_Terminals is always N+1 for a File_TS model. If
there are no unused terminals, then Number_of_Terminals will be followed by
N+1 terminal lines (rows). If there are unused terminals, then
Number_of_Terminals is followed by fewer than N+1 terminal lines (rows), and
the Unused_port_termination parameter tells the EDA tool how to terminate any
unused terminals during simulation.
-------------
Review of ARs:
- Arpad to send draft_1 of BIRD197.3 to the ATM list.
- Done.
- Mike L. and Bob to produce a revised draft response to the BIRD198 authors.
- In progress. Reviewed below.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the April 09
meeting. Mike L. moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD197.3 draft 2 (DC_Offset)
Arpad had sent BIRD197.3 draft 2 along with the ATM meeting agenda. It was the
same as draft 1 emailed last week, except the "Illegal before" version was
changed from 7.0 to X.x. Bob noted that the BIRD draft used "single ended" but
the rest of the spec uses "single-ended". Arpad replaced all instances of
"single ended" with "single-ended", and the resulting version is what was posted
to the ATM archives as BIRD197.3 draft 2.
Fangyi noted the question he had posted to the ATM list in response to draft 1.
He asked about the following sentence in the BIRD:
The waveform output of the Rx AMI_GetWave shall be adjusted so that the EDA
tool can add DC_Offset to get the voltage of the waveform at the slicer
(aka latch, decision point) of the single-ended port.
He said this was ambiguous, and he posed the following question to illustrate
his problem with the sentence: If the actual waveform at the latch were centered
about zero, should the model return a waveform centered at -DC_Offset so that
the EDA tool would then add DC_Offset to get the proper zero centered waveform?
Walter said that sentence was intended to say that if the EDA tool wanted to
take the output of Rx GetWave() and adjust it so that it could be compared with
what would be observed on a single-ended scope in the lab, then it should add
DC_Offset to the waveform returned by Rx GetWave(). Radek said the issue was
that the DC_Offset, as it was then defined, applied to the input waveform to Rx
GetWave(), but there is no guarantee that offset will be the same for the
output of Rx GetWave(). Fangyi said the first thing an Rx might do with the
input waveform is go through a comparator. The output of the comparator would
be zero centered, and the rest of the Rx process, including at the latch, would
be centered at zero. In that scenario the Rx GetWave() output (the latch) will
center at zero.
Arpad and Ambrish noted that we could address this by changing DC_Offset from an
In to an InOut, as Fangyi had proposed in his original email to ATM. Then the
Rx model could return the modified DC_Offset that applies to the output
waveform. Arpad asked if each GetWave() call could return a different value.
Fangyi said the model should only return the modified value from Init(). Arpad
asked if the authors were willing to incorporate this change. Ambrish said he
would work on it. Walter said that he would not want to be a part of this
rewrite, as he considered it unnecessary.
Response to JEITA authors of BIRD198:
Mike L. noted that he and Bob had reviewed earlier drafts and meeting minutes.
Their goal was to provide a brief first email explaining ATM's interpretation of
the BIRD and forming the basis of a conversation with the authors.
Randy had noted via email response that the current draft retained an earlier
statement about addressing the same modeling issue using BIRD189. Mike removed
it. Mike reviewed the draft. The intro section explaining our interpretation
of the BIRD was similar to Walter's original draft. Subsequent sections noted
that clarification might be required for defining the interaction between this
BIRD198 and [Pin Mapping], [Interconnect Model], or the absence of either.
Radek asked if [Package Model] could be used to define the connection points
for the BIRD198 model. Mike said he and Bob had considered it, but did not see
any way for [Package Model] to declare what the rails would be.
Arpad noted that he thought the draft should propose email discussion to start,
potentially followed by having one ATM meeting at a special time to facilitate
phone conversation with the authors. Mike incorporated the change. Mike said
he would send out this draft 6 to the meeting attendees.
- Mike L.: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Ambrish to work on BIRD197.3 draft3 to address Fangyi's comments.
AR: Mike L. to send draft6 of the BIRD198 reply to meeting attendees.
-------------
Next meeting: 23 April 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
