Minutes from the 25 Jun 2019 IBIS ATM meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 June 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 asked if we would have any trouble getting people to attend next week's
meeting because of the US holiday on Thursday the 4th. Only one attendee said
they couldn't make it next week, so the meeting on July 2nd will occur as
scheduled.
- Bob noted that the ibischk 7.0 parser will be available shortly and asked
interested parties to be ready to try it out. He noted that final details of
the licensing agreement are being completed.
-------------
Review of ARs:
- Fangyi to modify BIRD197.3_draft_5 to create draft_6 per last week's
discussion.
- Done. (Note: the BIRD NUMBER field in the new version sent to ATM
remained 197.3_draft_5 instead of being bumped to draft_6).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the June 18
meeting. Bob moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD197.3_draft_5(DC_Offset):
The group reviewed the latest version Fangyi had sent to ATM incorporating last
week's changes. Arpad noted one typo, signle -> signal, in the "Definition of
the Issue" section.
Arpad also asked a question about the following sentence:
âIt is assumed that the waveform input to the Rx AMI_GetWave function is the
physical Rx input waveform minus this DC_Offset.â
He noted that the EDA tool computes the value of the DC_Offset from the
channel's step-response and passes it in to AMI_Init(). He wanted to make sure
this sentence should not be interpreted as "the input waveform to the Rx GetWave
function is centered about the X-axis", because the EDA tool does not know what
the Tx GetWave() function might return. Walter confirmed that it should not be
taken to mean that the Rx input waveform must be centered about the X-axis.
He said the Tx GetWave() output is likely to be centered about the X-axis, so
the waveform passed into the Rx is likely to be centered about the X-axis, but
it's not required to be. Radek agreed with Walter's interpretation.
Randy asked whether we had yet answered the question he'd previously raised
about what the EDA tool should do with the output of Rx GetWave(). Should the
EDA tool shift the output waveform for display? He wanted to make sure we'd
provided clear guidance to the EDA tools. Walter said the EDA tool can generate
an eye diagram with the exact waveform that is returned by Rx GetWave(). It
can use the NRZ_Threshold to compute BER, etc. How the tool displays the
waveform is up to the tool. Arpad pointed out the phrase "physical waveform" in
this sentence from the "Other Notes" section of the DC_Offset description:
"The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch.
It can have a non-zero DC component, which can be time-varying."
Walter said he still didn't know what "physical waveform" meant. We don't
really know what the reference point is, and the waveform returned by Rx GetWave
may or may not have a DC component. He said that the Rx model returns
whatever waveform it wants, and it returns the corresponding threshold in the
NRZ_threshold parameter. He noted that if the waveform coming out Rx GetWave()
is zero-centered, as is true for all current models he knew of, the tool could
display the raw waveform or add DC_Offset at its discretion. Arpad summarized
Walter's position by saying the only thing incumbent on the model is to return
a threshold value that corresponds to the output waveform.
Randy noted that we are not really defining what to do. He said it's convenient
if the tool adds the DC_Offset back in for display of the waveform, but if the
model has returned a waveform that already contains the offset this could be
a problem. By not defining things, we may end up with inconsistencies in the
way various tools display the same output waveform.
Arpad asked if this was ready for submission to the Open Forum. Bob moved that
we submit Fangyi's latest draft, with the one typo fix noted by Arpad, as
BIRD197.3. Randy seconded. There were no objections. Arpad asked if he should
just make the typo fix and submit it, since Fangyi was not in attendance. The
group agreed, and Arpad took the AR to submit BIRD197.3.
Complex C_comp modeling:
Arpad asked about the new sentence proposed for the [Component] Usage Rules:
"The 'Die' location refers to the Buffer_I terminal of a [C Comp Model],
if [C Comp Model] is present and includes the Buffer_I terminal."
He asked if this change was up to date with IBIS 7.0. He noted that BIRD189
had introduced 3 terminal types, but this section of this BIRD did not address
all 3. Randy noted that the text shown preceding this new sentence was from
IBIS 7.0, and that this sentence is up to date with respect to IBIS 7.0. Bob
agreed and noted that for IBIS 7.0 the decision had been taken to leave the
'Die' and 'buffer' locations merged together from the point of view of the
Si_location and Timing_location SubParams.
Radek asked why it was necessary to include Si_location and Timing_location
changes in this BIRD at all. Randy said that if you're using a [C Comp Model]
you can point to the new Buffer_I terminal as the location for your SI or
timing location. Arpad agreed and noted that the new Buffer_I terminal is not
the same location as the buffer terminal in the interconnect section. It is
separated from the buffer terminal by other series elements (Note: see "Input
Filter Circuit" in Figure X in the BIRD draft).
Arpad said the language in [C Comp Model] Usage Rules: could be confusing. He
noted that it says [C Comp Model] overrides [C Comp Corner] or C_comp*, but the
next sentence says [C Comp Corner] is required if [C Comp Model] is present.
He suggested we change the text to state that [C Comp Model] overrides the
others during the simulation, but [C Comp Corner] is required because it's
necessary for deriving the K-T curves.
Bob asked if [C Comp Model] were only provided for the typ case, but
[C Comp Corner] were provided for typ/min/max, would [C Comp Model] override
[C Comp Corner] for min and max? Randy said normal precedence rules say it
would. If [C Comp Model] exists at all, it overrides the others in all cases.
He also referred to the File_IBIS-ISS rules section as an example. It states
that if a min or max entry is NA then the typ value shall be used. Randy
noted that you might only provide one typ case for the File_IBIS-ISS but pass
in a parameter controlling the corner settings.
Arpad questioned the following sentence in Param rules:
"The Param values shall all be numerical or all string values (or NA)."
He said this was confusing and implied that if multiple parameters were used
they all had to be the same type. He proposed the following language:
"The three corner values of any parameter shall be of the same type."
Arpad asked about the section on converting IBIS parameters to IBIS-ISS
parameters, particularly:
"For example, the Param value âtyp.s1pâ would be converted to
str(âtyp.s1pâ)
in IBIS-ISS subcircuits."
Randy said this text had been taken directly from existing IBIS 7.0 text.
Randy shared his latest modified version in which he had tried to incorporate
new language on making sure proper [C Comp Corner] values were provided. Bob
expressed concern that "K-T curves" hadn't really been defined. Randy noted
that the point of the section is that [C Comp Corner] will be used by the EDA
tool to develop the K-T curves. Bob and Arpad proposed language changes
intended to remove any reference to a specific algorithm or prescription for
using the [C Comp Corner]. Curtis expressed concern that we could water down
Randy's language so much that we gave the model maker no indication of how they
could decide that their [C Comp Corner] values were good. Walter suggested we
state that "[C Comp Corner] values may be used by the EDA tool for C_comp
compensation." Walter noted that there were other ways to do C_comp
compensation, but they were all much harder than using [C Comp Corner] so tools
would use [C Comp Corner].
Radek objected to the term "may" (may be used by the EDA tool). He noted that
an EDA tool should be able to connect the buffer model to the test load
specified in the model's v(t) waveform (e.g., [Rising Waveform] or
[Falling Waveform]) and generate that exact waveform. So, we have to be precise
about specifying the C_comp compensation rules.
Arpad noted that further discussion will be needed.
- Randy: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.
AR: Arpad to submit BIRD197.3 to the Open Forum per Bob's motion.
-------------
Next meeting: 02 July 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
