Minutes from the 9 February ibis-atm meeting are attached.
The documents discussed during the meeting will be uploaded here:
http://ibis.org/atm_wip/archive-date.html<https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fibis.org%2Fatm_wip%2Farchive-date.html&data=04%7C01%7Ccurtis.clark%40ansys.com%7Cfc71cf2118ef40e13f3f08d8c1bce5c6%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637472364775488087%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g6QmbyqzibPpFZG3YFxBC8JAsTHLy5yqksu9o7I0VU8%3D&reserved=0>
IBIS Macromodel Task Group
Meeting date: 9 February 2021
Members (asterisk for those attending):
Achronix Semiconductor * Hansel Dsilva
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Jared James
Google: Zhiping Yang
Intel: * Michael Mirmak
Kinger Cai
Alaeddin Aydiner
Keysight Technologies: * Fangyi Rao
Radek Biernacki
Ming Yan
* Todd Bermensolo
Rui Yang
Luminous Computing * David Banas
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SAE ITC Jose Godoy
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
Teraspeed Labs: * Bob Ross
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that given the groups' decision and Fangyi's new BIRD draft, he
had moved all the other redriver flow proposal agenda items to the Tabled
topics.
- Arpad noted that Hansel had a new "Clarification of PAM4 Thresholds" document
for us to review. He said we could plan to review it today time permitting.
-------------
Review of ARs:
- Fangyi to send out the Redriver BIRD draft and updated slides.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the February 2nd
meeting. Curtis moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Redriver Flow Issues:
Fangyi shared his updated presentation "AMI Redriver flow". He noted that he
had added clarifying text regarding the value the EDA tool could pass in with
the Use_New_Flow parameter:
The EDA tool can set the value to either True or False in the AMI_Init
function call regardless of the value specified in the .ami file.
Arpad brought up a point he had raised in an email reply to ATM prior to the
meeting. Arpad said he thought the Use_New_Flow parameter should be Format
List, not Value. He said he thought if we expect user interaction to set the
parameter's value then it should be a List of choices (True, False in this
case, as the Type is Boolean). If it is of Format Value, then he thought its
value was being strictly defined by the .ami file, and the GUI of the EDA tool
shouldn't allow the user to modify it. Fangyi said there's no difference
between the tool deciding to modify it or letting the user decide. As far as
the specification is concerned, it's only that the intention is that the caller
of AMI_Init can decide what value is to be passed to the model. Fangyi noted
that some Usage In Reserved Parameters of Format Value, such as DLL_ID, specify
placeholder values in the .ami file that are replaced by the EDA tool.
Curtis said he understood the approach in Fangyi's draft, because it does seem a
bit counterintuitive that you can't just specify Type Boolean and Format Value
and assume the value can be set to True or False for the In parameter. In fact,
since this is a Reserved Parameter, we probably could define the behavior as
Fangyi had. However, the definition of Format Value in the specification states
that the model maker is providing the value to be used. So, in a case like this
where it's an In parameter and we want the tool/user to decide amongst 2
choices,
he thought Arpad's suggestion of Format List was correct.
Fangyi said he had gotten similar feedback regarding using Format List from
Walter. Fangyi asked if it would satisfy everyone if he changed it to Format
List and stated that the List must include both True and False. No one
objected.
Ambrish said the user/tool would be making this decision based upon all of the
models in the channel since the new flow requires all models to support it.
Walter said that isn't necessarily a requirement in practice. For example, you
could have a legacy Rx and a new flow Tx, and this could be a perfectly
legitimate flow. Fangyi asked if the legacy Rx would know what to do with the
additional information in the IR matrix. Walter said the EDA tool could/would
know not to provide the two extra columns to the legacy Rx.
Fangyi noted a section he had added to the statistical flow descriptions based
on Walter's input:
Note that the input and output impulse_matrix of each AMI_Init call in this
alternative Redriver channel statistical flow are identical respectively to
those of the corresponding AMI_Init call in the alternative Redriver channel
time domain flow.
Arpad suggested that Fangyi also add sub-headings to highlight the start of each
of the 4 new flow descriptions to make the proposal easier to read. Arpad
suggested that "can" be changed to "may" in all instances of "... can use filter
impulse response". Fangyi agreed with both suggestions.
Ambrish asked if the name Use_New_Flow had been discussed and whether it would
age well. Arpad said there was agreement that a better name is needed. Arpad
said he had suggested something indicating the version of the specification in
which it was introduced (e.g., 7p1 as part of the name representing IBIS 7.1).
He said we used to refer to the "5.1 flows" as opposed to the original 5.0 AMI
flows. Bob didn't like this idea, and he noted that we already have a table in
the specification that documents the version in which each of the Reserved
Parameters was introduced. He said the parser would already reject the new
parameter if someone attempted to use it in a .ami file with an earlier version.
Fangyi suggested Arpad and Ambrish take an AR to come up with a better name.
Ambrish asked if the proposal is only addressing statistical flow, and he asked
if we agree that the current flow works if all models have GetWave. Fangyi
agreed that the current time domain flow works if all models have GetWave.
However, he said this proposal is not just addressing statistical flows. He
shared the Definition of the Issue: section of the BIRD, and he noted that issue
#3 is the problem with deconvolution being required when the Tx has a GetWave
and the Rx is Init-Only. The new flow will address that problem too, and it's
not limited to redriver flows. Walter agreed.
Fangyi reluctantly asked whether we should update the regular flow descriptions
too. Arpad said that if this new flow proposal fixes those too, then we should
update them. Fangyi said maybe that should be another BIRD. Arpad thought we
should probably fix them all at once, since EDA vendors will be updating their
flows based on this BIRD.
Ambrish asked how often anyone has seen a case where the Tx model has GetWave
and the Rx model is Init-Only. Arpad said Tx models and Rx models could come
from different vendors, so this combination could occur. Ambrish agreed, but he
asked how often in our ten years of AMI experience this happened? Walter said
the Tx model author will want his model to work in any flow, and this new flow
is a best-practice: Init and Get-Wave should be provided, and Init should
return its equalization.
Arpad asked if we should have a straw poll next week to decide on whether to
address the regular flows as well. Ambrish asked if we should wait until
there's a real problem before we fix it. Fangyi suggested everyone think about
it until next week.
Fangyi took an AR to send out his BIRD draft with the suggested updates from the
meeting. Arpad asked him to mention in his email the question about whether to
also update the regular flows.
AR: Fangyi to email his updated redriver flow BIRD draft and mention the
question about whether to update the regular flows as well.
AR: Arpad and Ambrish to suggest a better name for Use_New_Flow.
-------------
Next meeting: 16 February 2021 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
