Minutes from the 13 November ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the ATM Task Group archive.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
14-NOV-2018 Walter Katz SiSoft DC_Offset BIRD draft 3 (zip
IBIS Macromodel Task Group
Meeting date: 13 November 2018
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * Walter Katz
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
- Note: This was the first ATM meeting held since September 25th. All ATM
meetings since then had been cancelled in favor of devoting time to the
Editorial Task group process of preparing IBIS 7.0.
- Michael M. noted that the AMI dependent parameter example (pg. 180, IBIS 6.1)
contained some ambiguities. The Editorial Task group thought the text might
need tweaking that was beyond the scope of editorial changes. Arpad noted
that we could potentially discuss it today and add it to the agenda for future
Review of ARs:
- Randy to investigate if/why/how a clock waveform input might be used.
- In progress. Randy noted internal discussions were ongoing.
- Michael M. to investigate if/why/how a clock waveform input might be used.
- In progress. Michael M. also noted internal discussions were continuing.
He also noted that he had some thoughts/questions he could pose if we had
- Arpad to submit BIRD196. Mike L. to post it and send the email announcing the
vote at the October 12 Open Forum meeting.
- Done. The BIRD was approved by the Open Forum for IBIS 7.0.
- Walter to draft a BIRD introducing a DC_Offset Reserved AMI parameter.
- Done. On today's agenda.
- Arpad to send an email seeking input from redriver vendors on the AMI redriver
- Done. Arpad noted that he had sent the email to ATM and received no
replies. Arpad noted that at the previous meeting the suggestion was to
first email ATM and, if response was insufficient, to then email it to a
wider audience (perhaps si-list). Ambrish said he thought ATM might be the
audience most aware of this issue. Arpad noted that this question was
really for model makers, and model makers might be underrepresented on ATM.
Arpad asked if there were any objections to him sending an email to si-list.
There were no objections.
Call for patent disclosure:
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the September 25
meeting. Michael M. moved to approve the minutes. Walter seconded the motion.
There were no objections.
Advanced C_comp Modeling:
Arpad asked if Randy had anything new to discuss. Randy said there was nothing
new recently, but we could now pick up the topic again. Arpad asked if the
proposal needed to be changed based on BIRD189. Randy noted that he had already
updated the proposal based on BIRD189. Randy noted that we could move it up on
the agenda for future meetings.
DC_Offset BIRD Draft:
Walter shared and reviewed his draft1. He noted that he'd taken the liberty of
assuming it would be BIRD197. Walter noted the idea originally came from Justin
and Randy, and that Ambrish had also agreed to be a co-author.
Definition of Issue: DDR5 is single-ended. Because the input to AMI_Init() is
an IR, we lose the common mode voltage of that single-ended signal. This forces
all simulations to be centered around the midpoint of the single-ended waveform.
However, the .dll may need to know the common mode voltage in order to model
issues with saturation in the DFE summer, for example.
Walter noted that he had defined the DC_Offset value as the midpoint between the
starting and ending voltage values of the step response. However, he said he
was open to suggestions to change the wording of this definition, because it was
too closely tied to the way in which a tool might generate the IR (some tools
may not start by generating a step response).
Walter noted that DC_Offset was available to Tx and Rx models, though he thought
Rx models were more likely to need it. Michael M. asked if a Tx would need it
at all. Walter said a Tx model might also want the DC_Offset value if it had a
saturation issue with its equalization. For example, the common mode voltage
might be high with a given termination scheme. Ambrish noted AGC curves might
also exist, and a setting might be chosen based on the DC_Offset. Walter noted
that he wasn't a Tx designer, and we could leave the option available for Tx in
case a model maker wanted it, or we could remove it as an option for Tx if we
received feedback that it wasn't useful. Arpad noted that we might have an AC
coupled line case in which the DC_Offset at the Tx and Rx could be different.
Walter noted that he initially thought DC_Offset should only be usage In. The
tool would calculate the value for the given simulation, and pass it into the
model. However, in discussions others had brought up the possibility of Out,
InOut, and Dep. Walter's draft included these usages, but had a strike-through
for them to indicate that they were up for discussion. Michael M. asked to
confirm the typical scenario. The model maker would declare this parameter,
and the tool would calculate the step response, determine the DC_Offset value,
and pass it into the model. Walter agreed. Ambrish noted that he agreed with
Walter that this should only be an In parameter. No one objected, so Walter
removed the Usage Out, InOut, and Dep and associated language.
Randy noted that the language wasn't entirely clear and asked if there could be
a case in which the GetWave() function returned a waveform that included the
DC_Offset. Walter said this was not the intention. The intention was to keep
the inputs and outputs from the model unchanged. That is, the input and output
waveforms would still be "differential." Walter modified the language to make
it clear that the model could reconstruct a single-ended waveform internally by
adding the DC_Offset to the input waveform. But the waveform returned by the
model should still be centered about 0V (i.e. not include the DC_Offset).
Fangyi suggested the language state that the output waveform shall remain
"nominally" centered about zero, because the actual Rx may not always get the
perfect value for the DC_Offset or Vref. Even after the comparator it can still
have a small DC offset. Walter agreed and added "nominally" to the text.
Fangyi said this language was okay for this BIRD, but there were subtle issues
we might have to address later. We may ultimately need a way for the model to
tell the EDA tool if it wants the output waveform to be shifted by the EDA tool.
Walter said he would post the revised proposal as draft 2.
Dependent Parameter Example Issue (Editorial Task Group):
Michael M. noted that the dependent parameter example on page 180 of IBIS 6.1
has a few editorial and grammatical issues. He also noted that the example
itself actually wouldn't parse properly with ibischk because of a few minor
issues. Leaving those aside, the example itself is a bit unclear. There is
certainly a usage Dep parameter named Tstonefile. Tstonefile depends on the
OP_mode parameter, but the user only knows this because of the Description
string. In general, this is okay. The model maker knows what a Dep parameter
depends upon, but it's not necessarily supposed to be obvious to the user.
The confusion comes from the text underneath the example. There are statements
that Rx_Receiver_Sensitivity depends on bit_time, IBIS Model Name, and the
OP_mode. But it's not necessarily clear that Rx_Receiver_Sensitivity depends
on anything (it's an Out not a Dep parameter). Do we need an example or a flow
chart or something explaining how Rx_Receiver_Sensitivity is dependent on
Arpad noted that any Out parameter could be considered dependent because the
model is taking inputs and returning a value for the Out parameter. Walter
reminded everyone that the purpose of a Dep parameter is to get the EDA tool
a value it needs to have before AMI_Init() is called. The tool passes the
proper inputs to AMI_Resolve() and gets back the values of Dep parameters before
it sets up the simulation and calls AMI_Init(). In this case, Tstonefile is
clearly a Dep parameter, because the EDA tool needs to know which Tstonefile to
use when it sets up the circuit.
Michael M. noted that we could probably add language to that effect to clarify
the example. He also noted that we might explain that Rx_Receiver_Sensitivity
is only dependent upon certain other parameters in this illustrative example.
That is, Rx_Receiver_Sensitivity does not generally have to depend upon the
bit_time. Michael also noted that this is one of the few examples that utilizes
Model_Name, and we might need some clarifying text with regard to that parameter
as well. Michael said he had gotten enough information to go back to Editorial
and tweak the example.
- Ambrish: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Arpad to send an email to si-list seeking input from redriver vendors on the
AMI redriver flow.
AR: Walter to send draft2 of the DC_Offset BIRD to ATM. Mike L. to post it.
Next meeting: 20 November 2018 12:00pm PT
IBIS Interconnect SPICE Wish List:
1) Simulator directives