Minutes from the 21 May ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 21 May 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:
- Arpad to forward Walter's comments on BIRD197.3 to the entire ATM.
- Done.
- Bob to update the latest BIRD197.3 draft with revision info corrections.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the May 14
meeting. Radek moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
IBIS v7.0 parser developer questions:
Bob wanted to review two questions posed by the parser developer to ensure the
group agreed on the answers. (Note: BIRD188.1, included in IBIS 7.0,
introduced Rx_GaussianNoise as the preferred synonym for Rx_Noise, and it also
introduced Rx_UniformNoise).
1. Should the parser throw an error if Rx_Noise and Rx_GaussianNoise appear
in the same .ami file?
Bob noted that he thought the answer was yes. Radek agreed that it should be
an error. Arpad noted that pg. 249 of IBIS 7.0 defines Rx_GaussianNoise as the
recommended equivalent name for the Rx_Noise parameter. Ambrish noted that we
could add a statement to the spec explicitly stating that they can't both
appear in the same .ami file. Bob noted that this would be an editorial
addition to 7.1. The group agreed the parser should throw an error.
2. Can Rx_GaussianNoise and Rx_UniformNoise appear in the same .ami file?
Bob noted that he thought the answer was yes. They are independent parameters
and can both appear. The group agreed. Mike L. noted that there is some
parallel with the different jitter distribution parameters that are allowed to
co-exist. Arpad noted that if we allow them to co-exist, perhaps the spec
should say something about how they are combined. Michael M. noted that we are
currently leaving the combination and budgeting up to the EDA tools. He said
sometimes by including multiple parameters the model maker is making assumptions
about how they should be added together. He suggested there should be some way
for the model maker to state, "we are assuming the budgeting will be performed
the following way..." He noted that the industry probably agrees pretty well on
the way things should be combined. Arpad said that would end up in a BIRD. Bob
noted confusion could exist because the two noise parameters currently each
define an equation for determining the Output_wave(t). Ambrish wasn't sure the
spec needed to address this, and he asked where it would end. Radek said we
currently have two different formulas stating: Output_wave(t) = wave(t) + ...
and we should specify how the parameters are combined if they both exist. Mike
L. said it's important to give the model maker a way to be sure that they know
how their different jitter and/or noise parameters will be combined. Arpad said
he wasn't sure we needed to explain every detail about how they are additive,
but we should certainly explain it if/when any of them are mutually exclusive.
The group agreed that addressing the clarifications would require a BIRD, and
that the parser currently does not need to do anything if both of these
parameters are present in a given .ami file.
BIRD197.3_draft_4(DC_Offset):
Arpad asked for further comments and discussion and asked if this was almost
ready to send to the Open Forum. Ambrish noted that he had several questions.
He noted that the waveform input to Rx GetWave() is centered about zero. Now
with the new language, the model is supposed to add the DC offset back in to
the output waveform, and the EDA tool should not add anything to the output.
Ambrish said he thought the language was too vague and wishy-washy. Item 2.
in the Other Notes: says "It CAN have a non-zero DC component..." Fangyi noted
that the first sentence of that section explicitly states that,
"The Rx AMI_GetWave output waveform is the physical waveform at the Rx latch."
Ambrish suggested we explicitly state that if the waveform at the Rx latch has
a DC offset then the model must return a waveform with that DC offset. Fangyi
said he had no objection to adding a statement to that effect.
Walter objected to the latest language with respect to the waveform returned by
Rx GetWave. He noted that when he and Ambrish first drafted the BIRD the entire
point was to keep the waveforms passed in and out of AMI models differential.
He noted that the waveforms would typically be differential about VrefDQ, which
itself is usually the same value as the amplitude midpoint of the step
response. He said the DC_Offset parameter was introduced because when the
signal heads down the channel it goes through amplifiers, and even though it's
centered about VrefDQ there could be saturation issues if the voltage amplitudes
get large relative to VrefDQ. So, there are non-linear effects that the model
maker may want to include for a DDR5 Rx, and DC_Offset enables them to do it.
But having done that, the basic output of Rx GetWave() should be a differential
waveform centered about zero. When the tool samples that waveform, anything
below zero should be considered a zero, and anything above zero should be
considered a one.
Arpad noted that further discussion will obviously be needed.
- Mike L.: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 28 May 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
