Minutes from the 19 January 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%7C8dad7722bd734951c32508d8a6c5ec2b%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637442716313655554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5v1iwFn4fdW7EyUYvnzxNkIWBufHY6AWxyZpfCC1jvY%3D&reserved=0>
IBIS Macromodel Task Group
Meeting date: 19 January 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:
- None.
-------------
Review of ARs:
- Fangyi to add information on the new hybrid variant to his presentation.
- Done. Fangyi to present the new slides today.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the January 12th
meeting. Michael moved to approve the minutes. David seconded the motion.
There were no objections.
-------------
New Discussion:
Redriver Flow Issues:
Fangyi shared his updated presentation "AMI Redriver flow".
Note: The slides were sent to ATM about 12 hours after the meeting and are
available.
Fangyi noted that variant 3 is the union of the previously discussed variants 1
and 2. (variant 3 was referred to as the hybrid variant in the previous
minutes)
Fangyi reviewed 3 new slides on variant 3.
slide 10 - Variation 3: Combinations of Variants 1 & 2
This slide shows the possible inputs to and outputs of Init.
slides 11 & 12 - Variant 3 notes
Two new AMI Reserved Parameters are defined:
- Init_Includes_Cumulative_Impulse
- True/False - if True, this is variant 1.
- Init_Returns_EQ_Filter
- True/False - if True, this is variant 2.
Fangyi noted that both of these should be Usage In. A model is a Variant 3
model if and only if its .ami file specifies one or both of these two new
parameters. Any Variant 3 model must support the case in which both parameters
are false (false is the default if either parameter is not in the .ami file), in
which case the model operates according to the legacy flow.
The new flow, proposed to overcome the issues in the current redriver flow,
assumes that all models are Variant 3 models. No mixing with legacy models is
supported, as they could corrupt the new flow. The new flow assumes all models
are Dual, or they could be Init-Only with Init_Returns_EQ_Filter specified in
the .ami file. The one exception is a terminal Rx with DFE, which must have a
GetWave to support time domain simulation. The EDA tool must always set at
least one of the new parameters to True for the new flow.
Slide 13 (added to the slides emailed out after the meeting) includes a truth
table for the 4 combinations of settings for the two new parameters, per Arpad's
suggestion.
Ambrish asked if we really gained much by using variant 3 as opposed to variant
1. He said he thought the need for two parameters with variant 3 was overly
complicating things. Fangyi said one thing variant 3 supports over variant 1
is the ability for the EDA tool to provide a proxy GetWave for an Init-Only
model (see bottom row of slide 9). Walter said another benefit is that the EDA
tool can choose not to bother putting the crosstalk terms into the IR matrix
input to Init. The tool could choose to do all the convolution externally.
Fangyi agreed, assuming the tool/user know that the model does not need to know
the strength of any crosstalk terms. Fangyi noted that, for simplicity, his
table
on slide 10 always assumes/shows the crosstalk terms are passed in.
Ambrish asked if we couldn't implement variant 1 now and add variant 3 later if
necessary. Arpad said that if an EDA tool developer is implementing variant 1,
it's a small increment of work to add support for variant 2 as well and arrive
at full variant 3 support. Curtis said that even variant 1 would require the
addition of one new parameter to indicate variant 1 vs. legacy flow, and the
extra complication of having a second parameter seemed worth it given the
benefits of having variant 2 as well. Fangyi said that because the parameters
are Usage In, a tool developer could choose to only support the variant 1
functionality if they wanted to.
Arpad asked if we needed a straw poll to decide. Bob said he thought we should
move ahead with variant 3. Ambrish asked to review the slides and decide at the
next meeting. Fangyi took an AR to send the updated slides to the ATM list.
Arpad took an AR to ask Steve Parker to post them to the ATM archives.
Clock Forwarding BIRD (BIRD204) issue:
At the December 15, 2020 meeting, Walter noted a problematic case. If the Data
(e.g., DQ) model has Rx_Use_Clock_Input set to "Times", and the Clock model
(e.g., DQS) does not return clock ticks, what should we do? Walter suggested
that we should require the DQS model to have a GetWave function and to return
clock ticks if the DQ model wants clock ticks as an input.
Walter had suggested modifying the Other Notes for Rx_Use_Clock_Input to add:
For the "Times" option, the Clock shall have a DLL with an AMI_GetWave that
returns clock_times.
Arpad asked if we needed a new BIRD for this, since BIRD204 had already been
approved. Walter said we could instead leave BIRD204 as is and add this as an
extra admonition to avoid this case. For example, we could add:
For the "Times" option, the Clock should have a DLL with an AMI_GetWave that
returns clock_times. The model maker cannot rely on all EDA tools generating
clock ticks from a waveform in the same way, and it would be a burden on the
EDA tool to find out that the Clock AMI_GetWave did not return clock_times
after the simulation started.
Bob noted that the IBIS 7.0 Known Issues Document now contains a section for
editorial issues with BIRDs approved for the next release. He said Randy
controls this document and asked Curtis to start an email thread to discuss
whether we could handle it that way.
- Curtis: Motion to adjourn.
- David: Second.
- Arpad: Thank you all for joining.
AR: Fangyi to email his "AMI Redriver Flow" presentation to the ATM list.
AR: Arpad to ask Steve Parker to post the presentation to the ATM archives.
AR: Curtis to start an email thread about whether the BIRD204 modifications
can be handled in Editorial.
-------------
Next meeting: 26 January 2021 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
