Minutes from the 12 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 12 November 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
* Todd Bermensolo
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. Justin Butterfield took the minutes.
--------------------------------------------------------------------------------
Opens:
- None
-------------
Review of ARs:
- Wei-hsing to create a slide to show how the pass-through Tx model training
approach would work.
- Arpad reported Wei-hsing sent out on slides.
- Randy and Michael M. to invite DDR memory and controller vendors to comment
on new protocols.
- Michael reported he is still working on this, but he is prepared to comment
to
represent Intel on the issues as they are discussed.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the October 29
meeting. Walter moved to approve the minutes. Michael seconded the motion.
There were no objections.
-------------
Proxy Based Back Channel Flow:
Wei-hsing presented his slides. He made some changes based on comments from
Walter.
The proposed technique uses a proprietary API between the Rx and Tx. The
motivation
is that File IO is not efficient and could be error prone. This approach does
not
require any changes to the AMI specification, and there could be some
flexibility
with older EDA tools. The methodology uses File IO only twice: at the
beginning and
when training is complete. The models to be trained are loaded as proxy models
to
perform the iteration needed for the training. The "getenv" C++ function can
be used
and the models can use DLL_ID and DLL_PATH to know the system and path
information.
Wei-hsing detailed the two modes of operation for training and normal
simulation.
The modes can be set by a Model_Specific parameter called OP_MODE. Fangyi
asked if
this is set by the EDA tool. Wei-hsing noted this can be handled by the user
and set
based on the user guide. In the normal operation mode, the models will report
errors
when the "config." setting file cannot be found in the case where model does
not find
an optimized setting. In training mode, a file is generated with the DLL_ID
and
DLL_PATH and obtains the path using the "getenv" function, then the training
can run
in the working directory. The result of the training is an output file with
the AMI
parameters optimized. This file can be written to the temp folder that can be
seen
by both the Tx and Rx. The timestep can be used to distinguish between
different Tx
and Rx pairs. The AMI models should be able to find this file without help
from the
EDA tool. The Tx and Rx can be instantiated in pairs by the EDA tool and use
the
timestep to match them. Fangyi asked if this will allow for multi-threading of
the
process. Wei-hsing stated the process ID can be used to setup multi-threading.
Fangyi commented the Tx and Rx will have to be in the same thread. Wei-hsing
noted
the EDA tool will have to declare the Tx and Rx pairs in the correct order.
Once
training is done, the "config." is used. With this the Tx and Rx can have the
handle
for the other model. He noted this approach could work for both AMI_Init and
AMI_GetWave.
Arpad asked about reading the AMI parameter file and if the model would have to
parse
the file. Wei-hsing replied there is no parsing required by the model. The
2nd
instance of the model is trained. The memory for the first model is released,
and
the training is transparent to the EDA tool. The model makers need to be
careful of
using static variables. There also could be issues with non-LTI repeaters.
Walter noted he would like to have the functionality to have the Tx Init call
the Rx
Init and preform impulse processing. He asked how does the Tx know what memory
is
used by the Rx. Wei-hsing replied that the AMI_Init will only be called once,
and Rx
AMI_Init will have the memory handle. Walter asked how do you have the Tx DLL
point
to the memory. The Rx must tell the Tx to generate a pulse response with
specific
FFE taps. When you run the DLL code, it is memoryless. He asked how do you
allow
the memory to be passed between Rx and Tx. Wei-hsing replied the Rx can pass
the
memory back and forth with C++ classes. Fangyi stated the Rx can use the
proprietary
protocol to set the FFE taps with the API protocol. Wei-hsing commented all
these
operations are performed in the same function, so they are seamless to the EDA
tool.
Walter stated you are asking the model maker to write a simulator in the model.
The
model would have to do the Rx Init iteration. Walter noted, in his proposal,
the
models would be called separately and pass the information between them with
strings. Wei-hsing stated his approach can be more efficient, since the
iteration is
between the Rx and Tx. Walter thought this approach would be more complicated,
as
the model makers will have to handle interprocess communication.
Arpad noted this could work, with the proprietary nature of the model, when the
same
vendor makes both the Rx and Tx model. He asked if there is a way to extend
this
idea so that different vendors could use the technique. Wei-hsing stated the
API
needs to be documented, then both vendors can support it. Fangyi stated that
the
model developers could have to support different versions for different vendors
if it
is not standard. Wei-hsing stated that the same is true of Walter's approach.
Fangyi commented the Rx will know how to load the DLL. Wei-hsing stated this
should
be doable by model developers. Fangyi asked if the Rx needs to load the Tx
parameters. Wei-hsing stated this is done by the pass-through Tx. Fangyi
asked how
the metrics would be generated and if the Rx would have to run a simulation.
Wei-hsing stated the metrics can be reported. Walter stated there could be
several
metrics used by the model. Fangyi summarized that handling the loading of the
DLL
inside the model is the biggest difference between the two approaches.
Wei-hsing asked, in Walter's approach, how the optimized parameters get written
out.
Walter stated that the data is iterated over time and the optimized parameters
are
stored in memory. Wei-hsing asked if there is a way to use the same parameters
if
nothing has changed in the simulation. Walter stated the history of the
simulation
is saved. Wei-hsing stated that one file IO operation is inevitable, and the
result
is saved so that the iteration does not have to be done again. Fangyi agreed
that it
is required if the result must be the same.
Arpad asked if we can expect to support both 32bit and 64bit machines and if we
can
still use wrappers which will change the process. Walter stated we had this
issue on
BIRD147. Arpad asked if the process ID needs to be the same. Wei-hsing stated
the
use of the process ID would be for filtering to the correct Rx and Tx pair.
Walter stated in his approach the protocol is defined by the BCI protocol
string
which can be read between the Tx and Rx. Walter noted in the other approach
the API
is between the models. Wei-hsing noted that his approach does not require any
changes to the IBIS specification. He noted it is one method that could be
used.
Arpad suggested we should continue this discussion next time.
- Arpad: Thank you all for joining.
AR: None
-------------
Next meeting: 19 November 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
