Minutes from the 24 September ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 24 September 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:
- None
-------------
Review of ARs:
- Randy and Michael M. to invite DDR memory and controller vendors to comment
on new protocols.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the September 17
meeting. Randy moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD198.1:
Arpad and Randy noted that no new BIRD198 updates were available. They had not
yet heard back from the authors.
Enabling Back-channel in Statistical Mode:
Arpad noted that discussion had run out of time at the previous meeting.
Walter shared his "DC_Offset and VrefDQ" presentation.
- Memory contains a differential receiver.
- The reference is VrefDQ, which is set by the VrefDQ register.
- Input to the model is an IR and the value of DC_Offset. The model can use the
value of DC_Offset to construct the step response if it needs it. There's no
guarantee that DC_Offset will be close to the actual VrefDQ.
- The register is set in the memory, then hardware generates the VrefDQ signal.
- We could potentially have the VrefDQ register value as an input to the model.
- Alternatively, the model could choose the "best" VrefDQ register setting,
i.e., the register setting that results in the VrefDQ closest to the
DC_Offset.
- The question is, "If the model wants to modify the output value of DC_Offset,
what should it return?"
Randy said he needed to think about it more. He noted that the input value of
DC_Offset is useful, but he still wasn't sure it was useful to return an output
value. Walter said that until this question is resolved we should leave the
DC_Offset BIRD tabled.
Fangyi noted one earlier idea. In statistical simulation, The Rx model could
return a DC value to be added to the statistical eye. He noted that this did
not have to be returned via DC_Offset, it could be a separate parameter. But it
would be good to have some way for the Rx to return a DC value to the EDA tool.
Walter said perhaps the DC_Offset should only be an In parameter. If we want
some sort of output value, we could write a different BIRD. Randy agreed that
we could add that capability later with a separate BIRD if necessary. Walter
took an AR to draft another version of BIRD197.5 with DC_Offset defined only as
an In parameter.
Walter noted the previous discussions and his presentation on developing a DDR5
DQ Write protocol. He felt that we weren't yet in a position to address that
topic fully. We need more input from other DDR5 controller and memory vendors.
Walter asked for comments and discussion on the proposal to enhance BCI for
statistical use. Ambrish asked if this proposal was attempting to solve an
existing need or anticipate a future need. Walter referred to slide 3 of his
"BCI For Statistical" presentation from two weeks prior. He noted that both
model makers and end users had requested this functionality.
Fangyi asked if having the DDR5 DQ Write protocol defined was a prerequisite for
deciding on this BIRD. Walter said that the protocol would be dependent on the
BIRD. The BIRD is approved by IBIS and defines the new parameters, new AMI
function, etc. It only defines the mechanisms used. The protocol specifies
what information is passed between the Tx and Rx, and it's strictly between the
Tx and Rx model makers. Walter noted that there had been discussions about
"official" IBIS protocols, but the process for doing so had not yet been
formalized.
Fangyi asked if the contents of the protocol were passed in the newly proposed
BCI_parameters_in and BCI_parameters_out parameters? Walter noted that BIRD147
used file I/O between the Tx and Rx models, and the BIRD had only defined the
file as the communication mechanism. What the Tx and Rx put into the file was
up to the specific protocol. If we used the BIRD147 type file I/O, then these
proposed parameters would not be introduced. However, Walter preferred that we
introduce these parameters and let the Tx and Rx communicate via parameter
strings passed between them. He noted that the EDA tool still did not play any
part in the protocol itself. It merely passed the strings in these parameters
from one model to the other.
Walter suggested names of AMI_Impulse or AMI_Get_Impulse for this new function.
Walter used AMI_Impulse for the purpose of this discussion. He noted that the
AMI_Impulse function took the exact same arguments as AMI_Init. Arpad asked why
we would pass the same IR into AMI_Impulse if we'd already passed it into
AMI_Init. Walter said we still need to pass in an IR block of data so the model
can overwrite it. We need the placeholder, so let's keep it simple and the same
as AMI_Init. Walter noted that he wanted to leave the existing AMI_Init flow
untouched, so he wanted to add a new function instead of contemplating changes
to the way AMI_Init might be called.
Fangyi asked about the flow and what IR is passed in to AMI_Impulse. Walter
said the call to the Tx always gets the channel IR. The Tx's output IR is then
passed to the Rx AMI_Impulse function. The process iterates for perhaps several
hundred times until the Tx decides it has hit upon the optimum settings. At
this point, the Tx tells the Rx it has converged and gives the Rx the final tap
settings. The Rx then reports to the EDA tool that training has completed, and
the EDA tool uses the IR output from this final call to the Rx's AMI_Impulse
function. Arpad asked if the output IR of AMI_Init would ultimately be
discarded if this AMI_Impulse flow were followed. Walter said it would.
Ambrish asked why this training couldn't be handled with the existing
AMI_GetWave flow. Walter said the algorithms would be similar, but with the
AMI_GetWave flow you're typically limited to about 10k bits per block and
looking at a 1e-4 BER contour vs. 1e-16 for statistical. He noted that some
vendors only do optimization in statistical and some only in time-domain. He
noted that we already have BCI flow for time-domain, and this would give us a
way to do it in statistical. He noted the new parameter that would specify
whether BCI was supported by the model in statistical, time-domain, or both.
Ambrish noted that he was trying to weigh the tradeoff in complexity of adding
this new flow to the spec. He said it would make more sense if the flow
converged more quickly than several hundred iterations. Walter noted that it's
typical in a DDR5 example to have two FFE taps and 4 DFE taps. If you optimize
over all the combinations of those 6 parameters, several hundred iterations to
find the optimum solution is pretty fast.
Fangyi said he had the impression that this flow was a repeated statistical
simulation. The Tx could sweep through its tap settings, and at each step the
Rx could optimize its settings according to the IR it received. Walter said
that Rx hardware can't optimize itself, and the Tx is responsible for all of the
optimization. The flow Fangyi described could work as an optimization flow, but
we need to be able to model the actual hardware flow. There's an optimization
algorithm in the Tx hardware, and Tx vendors want to model that optimization.
Traditional sweeping and optimization techniques within EDA tools are what is
done now, but the customers need to model their own optimization.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Walter to draft a new revision of BIRD197.5 with DC_Offset defined only as
an In parameter.
-------------
Next meeting: 1 October 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
