This version contains one minor correction - the date of the next meeting is
now properly listed as September 03.
________________________________
From: Curtis Clark
Sent: Thursday, August 29, 2019 12:40 PM
To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Minutes from the 27 August 2019 IBIS ATM meeting
Minutes from the 27 August 2019 IBIS ATM meeting are attached.
IBIS Macromodel Task Group
Meeting date: 27 August 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Kumar Keshavan
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 Walter had asked to introduce a new topic:
Enabling Back Channel Interface in statistical mode.
- Randy noted that the authors of BIRD198 had sent a new draft to Arpad, Bob,
Randy and Mike L. Arpad suggested that those who had received a copy review
it and present a summary to ATM at next week's meeting. ATM could potentially
provide some feedback prior to any formal submittal of BIRD198.1. Bob and
Randy agreed.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the August 20
meeting. Ambrish moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
Jitter HF/LF components and Jitter amplification:
Michael Mirmak noted that his team is still working on this internally. He
reiterated that they will not be pursuing the original draft's high-low
approach and will instead pursue a spectral distribution approach.
BIRD 197.4 discussion:
Ambrish shared his latest version and asked to review it briefly then address
email comments by Arpad and Fangyi. Ambrish noted some confusion about the
"default" value of DC_Offset and said he hoped to address some of it with
this sentence:
If DC_Offset is Usage In, the EDA tool may use the input value of DC_Offset to
post process the data returned by the AMI model.
Ambrish discussed the concept of default values in terms of what the model
assumes if the EDA tool doesn't provide a value when DC_Offset is In and what
the tool assumes if DC_Offset is InOut and the model doesn't return a value.
He said the simulation shouldn't stop if the model or tool doesn't provide the
expected value at any point. Arpad objected to this concept and noted that
DC_Offset is defined as Format Value and for those parameters the IBIS
specification does not define a default. If the parameter is In then the tool
must pass in a value, and if the parameter is InOut then the model must also
return a value. Walter agreed and said there should be no concept of a default
for DC_Offset. Randy noted that the "default" value language also existed in
previous drafts. Ambrish removed any default value language to simply the text.
Arpad had raised a question about the second sentence in the definition:
...output value of DC_Offset may return a different value by Rx AMI_Init.
He said that the input value of DC_Offset was defined in the text as being
the midpoint of the step response at the Rx pad. He noted that nothing in the
text defined what output value of DC_Offset was and where it was. He noted that
the output of Rx GetWave() is not at the Rx pad, it's at the core side of the
Rx. If the output value of DC_Offset is with respect to Rx GetWave() output
then it's on the core side, and the distinction compared to the input value must
be defined. Fangyi noted that this was also the first question in his list.
What is the definition of the output value of DC_Offset? Walter said the output
value has only one possible meaning - the tool can choose to add that value
to the Rx GetWave() output waveform, or not. That's the only use for the output
value of DC_Offset. Fangyi agreed, but added that if we talk about an
NRZ_Threshold later then it may have meaning there too. Walter said that for
this BIRD (with NRZ_Threshold removed) the waveform output of Rx GetWave() is
high if it's over zero and low if it's below zero. Walter suggested we could
add language stating that the output value is at the latch to address Arpad's
concern. Fangyi said we should instead restore the following sentence:
The output value of DC_Offset returned by Rx AMI_Init is to be added to the
Rx AMI_GetWave output waveform by EDA tools to form the complete waveform
at the Rx algorithmic model output.
He said this would define the output value of DC offset and the complete
waveform. He noted that it was not important that it was "at the latch."
Radek noted that "may return a different value" is redundant because that's the
purpose of an Out parameter. Ambrish said the important part of that sentence
was "by Rx AMI_Init". That's explaining that the value returned by AMI_Init()
is the one for the EDA tool to use.
Radek noted that "can be added" is ambiguous in this sentence:
This returned value can be used by the EDA tool to post process data returned
by the AMI model.
He said that it "is" added to the Rx GetWave() output waveform to form the
complete waveform. The only way to get the "complete waveform" is to add the
output value of DC_Offset to the output of Rx GetWave(). Walter said he didn't
know what "complete waveform" was, and what's important is the differential
waveform at the latch. He said that as a convenience for waveform display
we can add DC_Offset. Radek/Fangyi noted that "complete waveform" was defined
as the sum of the output value of DC_Offset and the waveform returned by Rx
GetWave() (in BIRD197.4). Walter said that definition is fine, but the EDA tool
isn't obligated to display the "complete waveform". Arpad noted that it had
been called physical waveform in earlier drafts. Arpad suggested new wording:
The sum of the output value of DC_Offset and the Rx AMI_GetWave output
waveform forms the complete waveform.
Arpad's next question was triggered by this sentence:
It is assumed that the waveform input to the Rx AMI_GetWave function is the
physical Rx input waveform minus the input value of this DC_Offset.
He noted that implicit in this sentence is the fact that the waveform input to
Rx GetWave() has no DC offset. He said that in SERDES designs everything was
difference based, but in the single-ended applications a Tx model maker may
ask what the output of the Tx GetWave() function should be. Do we need to make
a statement for Tx model makers? What if a Tx model maker knew the output would
have some DC offset and designed their GetWave() to return a waveform with a
DC offset? Wouldn't we risk compatibility issues with Rx GetWave() models
expecting their input waveforms to have no DC_Offset? Walter noted that the
output of Tx GetWave() should contain its equalization applied to the input
stimulus waveform, which the spec defines to be between +-0.5V. If it's a
decent Tx its output will be zero centered. Kumar noted that this BIRD is for
the Rx only, and a model maker of the Tx or Rx would have no idea what this
DC offset could be ahead of time, that's why this parameter is needed. Walter
noted that a Tx .dll doesn't know how it's terminated, and it only gets an IR,
so it can't possibly know anything else and must be centered around zero.
Fangyi noted that the sentence that triggered Arpad's question is itself telling
the Tx model maker not to add any DC_Offset to their GetWave() output waveform.
Arpad thought it should be stated more clearly, but said we could move on if no
one else thought it was necessary.
Fangyi asked about this sentence:
The Rx AMI_GetWave function may use this information, for example: ...
He asked if this was meant to say GetWave or Init, since DC_Offset is passed
into the Init() function. Walter noted that it was passed in to Init() but
could also be used by GetWave(). Fangyi agreed, but asked if we needed this
sentence at all. Ambrish said it was just there to give an example to explain
and justify the need for the parameter, and that he was willing to remove it.
Walter said the parameter has three primary uses:
1. When you go through a differential gain receiver, you might saturate. The
only way for the model to know is with DC_Offset.
2. When the DFE slicer chooses to add voltage to the signal at the latch to
correct for DFE, it could add something that causes it to go into
saturation. The only way to know is with DC_Offset.
3. The value of VrefDQ is actually set by a register. It might be nice to know
the actual value of DC_Offset vs. what the register setting could provide.
Kumar said we should remove the sentence because it's too specific. Arpad
agreed that it's redundant in the same way Radek had previously said that
defining what an InOut parameter was used for was redundant. The group agreed
to simplify the text by removing the sentence.
Fangyi asked about this sentence:
If DC_Offset is Usage In, the EDA tool may use the input value of DC_Offset to
post process the data returned by the AMI model.
He asked what the definition of post processing was. Randy said it was just
to display the eye. Walter said an EDA tool can do whatever it wants with any
Out parameter. We don't need to say it for every parameter. Ambrish noted that
he had added this sentence to attempt to address one of Randy's questions about
the "default" output value when DC_Offset was an In. Randy said we should
remove this sentence since we'd removed the "default" language.
Fangyi asked about this sentence:
It is the responsibility of the EDA tool to perform any shifting of the
output waveform.
Fangyi and Radek noted that we should add "Rx GetWave()" in front of output.
Radek asked what "responsibility" meant - do we want the EDA tool to do it, or
does it have to? What is shifting, just adding the DC_Offset? Walter said
the sentence should just be removed. Randy agreed and noted that we already
say the output waveform must be nominally centered around 0V, so it's pretty
clear.
Arpad and Randy asked Ambrish to send out a new cleaned up version incorporating
all the changes discussed in the meeting. Ambrish agreed. Bob noted that the
vote on BIRD197.4 scheduled for the next Open Forum meeting will be delayed now.
Fangyi said that with the changes made today, this new proposal is essentially
BIRD197.4 with NRZ_Threshold removed and a minor difference in "default" values.
- Randy: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Ambrish to send out a new draft of BIRD197.5 incorporating today's changes.
-------------
Next meeting: 03 September 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
