Minutes from the 17 December ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 17 December 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. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that this would be the final meeting of 2019 and thanked everyone
for their work this year.
-------------
Review of ARs:
- Randy and Michael M. to invite DDR memory and controller vendors to comment
on new protocols.
- In progress. Arpad asked if we should consider tabling this one until we
have an update. Walter agreed. Walter noted that he'll be serving on an
AMI panel at DesignCon, and one subject is DDR5. Walter noted that he will
talk about the DDR5 DQ Write protocol we are developing, and he will invite
other memory and controller vendors to participate. Michael M. said he was
okay with tabling it. Walter moved to table it. Michael M. seconded.
There were no objections. Arpad said he would move it to the Tabled AR
list.
- Walter and Randy to work on a new iteration of a proposal for BIRD198.
- In progress. Randy noted that he and Walter had discussed this privately,
but Walter said they did not yet have anything ready for review with ATM.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Review of the minutes for the December 03 meeting had been deferred at the
December 10 meeting:
Arpad asked for any comments or corrections to the minutes of the December 03
meeting. Walter moved to approve the minutes. Curtis seconded the motion.
There were no objections.
Arpad asked for any comments or corrections to the minutes of the December 10
meeting. Walter moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Arpad suggested a quick review of the existing Tabled ARs:
- Investigate if/why/how a clock waveform input might be used.
- Randy noted that his AR was still in progress, they are looking into how
this would be added to their models, and they will likely reach out to EDA
tool vendors. Randy stated that this will probably require input from
everyone to look at simulation flows in the tools.
- Michael M. said his answer was similar. This issue can be handled in many
ways, but one question is on whom does the burden fall? Do we rearchitect
models to deal with it, or are there ways to finesse this at the risk of
slightly reduced accuracy?
- Arpad noted that these two will stay on the Tabled AR list.
- Check with IP experts on whether DC_Offset is useful for Tx.
- Michael M. said that this could be closed. He noted that they had provided
all the feedback they could for now. Arpad said he would remove it from the
list.
BCI for statistical mode:
Walter noted that he had not received any comments via email on his draft 1. He
said he thought it was sufficiently formed to submit it to the Open Forum and
get an initial BIRD number prior to DesignCon. He asked if people wanted more
time to review it.
Radek noted that he had mixed feelings about introducing AMI_Impulse(), and he
wondered whether we should instead just augment AMI_Init() to address this
issue. Walter noted that we had held a straw poll vote at the December 3rd
meeting to choose a direction, and AMI_Impulse() had won 6 to 0. Walter noted
that the current state of the proposal was what had been decided upon by the
vote.
Radek said he was not against AMI_Impulse(), he just wasn't sure we gained
anything by introducing it. Arpad noted that with the AMI_Init() approach
a file was needed to facilitate communication (as in BIRD147), but the new
AMI_Impulse() had BCI_parameters_in and BCI_parameters_out arguments for
that purpose. Arpad noted that adding a new function might be cleaner than
overloading existing functions with additional options and conditions. Radek
noted that with AMI_Init() you had the same flags available as for the bit-
by-bit BCI simulations, and the only thing we'd talked about overloading was
the value passed in by ami_memory_handle. Radek reiterated that AMI_Impulse()
could work just fine, he just wasn't sure it was necessary to add the new
function. Walter asked people to review the draft and noted that at the first
meeting of 2020 he expected to move to submit the current draft, or a draft 2
if we modified anything today, to the Open Forum.
Ambrish noted an internal discussion with his colleagues about this proposal.
He said that he understood the goal of filling the statistical flow hole, but he
said they were interested in knowing if IP industry vendors were actively trying
to get this functionality added. He said they would like to chat with any such
IP vendors about what they feel they can't do with the bit-by-bit BCI we already
have in IBIS.
Michael M. said he could answer that question. He noted that almost all of
their internal analyses were based on AMI_Init(), i.e., statistical flow. He
said that for many reasons their focus is on getting statistical flow results
that can be applied to a Design of Experiments. If you want to run very many
statistical flow simulations, and your buffer designs are "LTI enough," then the
only gap in the current AMI flow for something like PCI Express or other
industry standards that use backchannel adaptive equalization is this
BCI-in-statistical feature. He noted that right now they have to do that
negotiation between the endpoints "manually" in a statistical flow, and they
would like to have link training in a statistical flow. He also spoke to
Radek's earlier point about AMI_Impulse() vs. AMI_Init(). He said the question
is whether you modify AMI_Init() and change your flow, or you add a new
function and leave AMI_Init() alone. He said the new AMI_Impulse() function to
handle link training would address all of these issues.
Ambrish asked if an "LTI enough" buffer design meant we would be talking about a
one-vendor solution. He noted we can't make a general assumption that a Tx and
Rx are "LTI enough." Michael M. said it was not a vendor-specific issue, it was
a methodology. He noted that they had used the same methodology for
specification-based generic buffers too. He noted that the model maker might
need to make additional assumptions about how a buffer design really works, but
for something like PCI Express there's enough information in the standard to
formulate a statistical model set to do this type of statistical mode analysis.
Arpad brought up the long-standing questions and discussions about Init Only vs.
GetWave Only vs. Dual models. He asked what would happen if one model had
AMI_Impulse() and the other only had AMI_GetWave() based BCI? Michael M. said
he hadn't thought through those details, but the effectiveness of this technique
might boil down to whether a device vendor could give you a buffer that was LTI-
enough that you could get good results from a statistical analysis.
Ambrish noted that back-channel, by its nature, is a long time-dependent
simulation that determines the tap weights at either end. He asked how much
correlation had been done to see if these statistical results could be accurate
enough. Do we have other IP vendors who need this? He said that if a single
vendor needs a solution for this problem, it can be handled today by a proxy-
model approach like Wei-hsing had described (in previous meetings). Michael M.
said he thought the proxy-model approach was non-trivial in a software sense for
most model makers. Leaving that issue aside, he noted that PCI_Express, for
example, if it's going through one of these training algorithms, is not going to
get anywhere near the full 3 x 1/BER target during training. The training takes
place over an extremely short period of time, so there's a whole bunch of
assumptions made even in the actual system when it's training. So, there are
already lots of assumptions even in the full time-domain training flow. Michael
said he did not think they were unique in the industry in wanting this
statistical BCI flow.
Wei-hsing noted that there was already a certain complexity in implementing eye
metrics and other issues with training. He said not to underestimate the
complexity of implementing the model even with the current AMI_Impulse()
proposal. Michael M. said he agreed completely, and that Wei-hsing's comments
opened the door to a wider discussion he expects at the DesignCon Summit. He
noted that as the AMI flow is currently written, models are returning some
simple
information like the waveform and modified parameter values, and the EDA tools
handle sampling, eye diagrams, eye metrics, etc. He suggested that it might be
better if the models reported these things directly, as they could more
accurately reflect what the device is actually doing.
Walter noted that the metrics returned by the models would be defined by the
particular BCI protocol. He noted that we are currently working on our first
protocol for DDR5 DQ Write. He said he planned to propose a straightforward
method of generating some metrics from the IR output of the Rx, which the Rx
model has available. He said he could provide a short MATLAB function as an
example. He noted that complexity shouldn't be too bad for this first
protocol. Wei-hsing suggested it would be good to implement something that
is consistent with other metrics like COM. Walter agreed and noted that the
MATLAB function he created computes eye height, eye area, and COM for a given
IR and BER.
Arpad asked if this proposal was ready to submit to the Open Forum. Michael
noted a cut-and-paste type error with "IEEE Std 802.3" appearing before
SOLUTION REQUIREMENTS. Walter removed it. Radek noted that the second
sentence in the Usage Rules needed editorial work. Walter reviewed it and
removed it entirely. Walter asked if anyone wanted to be listed as an author.
Arpad asked if Michael should be. Michael suggested he be listed as a
"contributor" in the Background Information section. Walter saved the resulting
document as draft 2.
Walter noted that if you're going to run the statistical BCI flow, then all of
the models have to have BCI_Training_Mode "Impulse" or "Dual". If you're going
to run the time-domain BCI flow, then all of the models have to have
BCI_Training_Mode "GetWave" or "Dual". Arpad noted that all of the models would
have to handle the right training mode and understand the same protocol. He
asked who would enforce this. Walter said the EDA tool enforces it. The
protocol name is contained in a Reserved parameter (BCI_Protocol), so the EDA
tool can check to ensure the right protocol and mode are supported by all
models.
- Michael M.: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining. Happy New Year.
AR: Walter to email draft 2 of the BCI for statistical proposal to ATM.
-------------
Next meeting: 07 January 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
