Minutes from the 23 April ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 23 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:
- None.
-------------
Review of ARs:
- Ambrish to work on BIRD197.3 draft3 to address Fangyi's comments.
- Done. Ambrish sent two revisions to the ATM list.
- Mike L. to send draft6 of the BIRD198 reply to meeting attendees.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the April 16
meeting. Mike L. moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
Response to JEITA authors of BIRD198:
Mike L. shared the draft 6 he had emailed to the attendees of the previous
meeting. Arpad reviewed three concerns he had raised in an email reply. Two of
them were editorial in nature, and Mike made the changes. Arpad's third concern
was related to the use of "rail" in the reply. He noted that "rail" in the
BIRD189 context was used to distinguish power or ground from signal (I/O). But
in this reply "rail" seemed to refer strictly to the power/ground buses defined
by [Pin Mapping]. Mike agreed, and addressed the issue by changing "rails" to
"supply rail buses" in two locations. Bob noted that the underlying assumption
is that BIRD198 doesn't make sense unless you have [Pin Mapping], because that's
the only way you can document the connection of a supply rail to a buffer.
Arpad asked if further review was required. Bob moved that we should send the
response. Mike seconded. There were no objections. Mike asked if he should
send it or Arpad should send it. Arpad said Mike could send it because he had
worked on it and had been part of earlier email discussions with the authors.
Mike took an AR to send the reply, on behalf of Mike and Arpad, to the authors
of BIRD198.
BIRD197.3_draft_3.1 (DC_Offset):
Arpad shared Ambrish's latest draft and suggested we could review it and provide
Ambrish with a list of proposed changes.
Arpad noted concerns he had with the language regarding AMI_Init() and
AMI_GetWave() returning values of the parameter. He noted that in the previous
meeting Fangyi had recommended that only the value returned by AMI_Init() be
used. Arpad asked if a GetWave only model with no algorithmic information in
its AMI_Init() could return a proper value from AMI_Init(). Fangyi said the
model should be able to return the correct DC_Offset from AMI_Init(). He
recommended that we not consider using values returned by GetWave(). He noted
that this would lead to further complications such as, "Do you use the value
returned by the first call to AMI_GetWave() or the value returned by the first
call after the Ignore_Bits count has been exceeded?"
Michael Mirmak asked if DC_Offset was something that could be computed up front
based solely on the channel, or if it could change after each block, for example
capacitive charge up. Fangyi said that if it was something like capacitive
charge up, then that charge up time should be built into Ignore_Bits.
Radek and Curtis noted that by definition all Out and InOut parameters are
returned by calls to AMI_Init() or AMI_GetWave(). So, it's not necessary to
explicitly state that the model could modify DC_Offset (an InOut) and return it.
Curtis noted language from section 10.6 that states that for certain Jitter and
Noise parameters the EDA tool should only use the value returned by AMI_Init().
He suggested we could adopt similar language for DC_Offset. The group agreed to
suggest Ambrish look into this possibility.
Fangyi expressed concern about ambiguity in this sentence:
It is also assumed that the waveform input to the Rx AMI_GetWave function is
the waveform minus this DC_Offset.
Curtis noted that he had sent an email reply about this sentence after draft_1
was sent out. He noted that Walter's original sentence contained the modifier
"single ended" in front of the second instance of "waveform", but "single ended"
had been removed in draft_1. Fangyi suggested we add "physical" in front of the
second instance of waveform. The group agreed, and Arpad made the change.
Fangyi proposed the following sentence to explain the relationship between the
Rx AMI_GetWave output waveform and DC_Offset:
The physical waveform at the latch is the Rx AMI_GetWave output waveform plus
the DC_Offset returned by the Rx AMI_Init function.
Arpad added this change too. The group made other clarifications to the text.
Arpad captured the changes as draft_3.2 and took the AR to send it to Ambrish
and ATM.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Mike L. to send the response to the authors of BIRD198.
AR: Arpad to send BIRD197.3 draft_3.2 to Ambrish and ATM.
-------------
Next meeting: 30 April 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
