Minutes from the 15 December ibis-atm meeting are attached.
The documents discussed during the meeting can be found 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%7C9aee85f0037d43e028af08d89df93d27%7C34c6ce6715b84eff80e952da8be89706%7C0%7C0%7C637433041085673527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5OEr8vcq2f8UcJFyF5cWAUfVoDF2hjBEGQNKfLJr%2BC4%3D&reserved=0>
IBIS Macromodel Task Group
Meeting date: 15 December 2020
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 the meeting would be the last of the year, and meetings
normally scheduled for December 22nd and December 29th are cancelled. Arpad
thanked everyone for their efforts in 2020.
-------------
Review of ARs:
- Arpad to ask Steve Parker to post Alaeddin's presentation to the ATM archives.
- Done. Arpad said he had sent the request, but the document was not yet
posted. Arpad noted that the original slides had not been sent to the ATM
list, and Alaeddin had sent out revised slides based on feedback from
Curtis. Arpad asked Curtis to summarize the issue. Curtis said Alaeddin's
presentation had proposed new Reserved Parameters allowing the model maker
to specify whether the Redriver Tx took the PRE (upstream) or POST
(downstream) IR information or BOTH as an input. In slides illustrating the
flow of IR processing in the PRE and BOTH cases, the upstream IR information
had been double counted because the upstream IR was explicitly convolved
into the input to the final Rx even though it was already contained in the
output of the redriver Tx. Curtis noted that Alaeddin had provided an
update/errata on slide 2 of the revised presentation. Arpad said that to
avoid spreading the original mistake, he had sent the revised version to
Steve and asked him to post it to the archives instead of the version that
was presented in the meeting.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the December 8th
meeting. Randy moved to approve the minutes. Jared seconded the motion.
There were no objections.
-------------
New Discussion:
Clock Forwarding BIRD (BIRD204) issue:
Walter shared his recent email regarding a problematic scenario. 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 noted that we do not have a Reserved parameter that indicates whether a
GetWave function does or does not return clock ticks. So, we should mandate
that the DQS model corresponding to a DQ that wants "Times" must return clock
ticks. Also, we should not allow such a DQS model to be Init-Only.
Walter said that if the DQ model wants "Wave" as an input, then the existing
language in the BIRD is fine. The existing language stating what the EDA tool
should do if the DQS model has no GetWave is sufficient. However, for the
"Times" case, he suggested adding a new sentence:
For the "Time" option, the Clock shall have a DLL with an AMI_GetWave that
returns clock_times.
Ambrish said he agreed with Walter, and that it would be ironic if the Clock
model didn't return clock times ;-).
Walter summarized: If the DQ model wants "Times" (clock ticks), the DQS model
that goes with that DQ should have a GetWave function, and it should return
clock_times. Otherwise, we're asking the EDA tool to create the clock_times.
Ambrish said the EDA tool already has to generate the clock times in the case
of Init-Only models in general. Walter said each EDA tool has its own way to
generate a clock, but that may not agree with how the DQS would generate the
clock. Fangyi agreed with Walter and also agreed with his suggestions. Walter
said that if the model maker is sophisticated enough to create a DQ model that
takes the clock_times as an input, then they can create a DQS model that returns
clock ticks in the clock_times argument.
Fangyi mentioned one other combination. What if two DQ models utilize the same
DQS, and one has Rx_Use_Clock_Input set to "Times", and the other has it set to
"Wave"? Walter said it was an odd combination, but as long as the DQS model
returned clock_times the EDA tool would know what to do for each DQ.
Arpad noted that BIRD204 had already been approved, and any proposed addition to
the language of BIRD204 would require us to create a superseding BIRD.
DC_Offset clarification:
Hansel discussed an issue with BIRD197.7's interaction with the PAM4 threshold
parameters and Rx_Receiver_Sensitivity, which he thought might require
clarification. He noted that BIRD197.7 says the EDA tool "may" use the value of
DC_Offset to post process data returned by the model. Hansel suggested a model
maker doing single-ended PAM4 might not know whether the threshold values should
include the DC_Offset or not. Do we need to add a line stating that the EDA
tool utilizes the Rx_Receiver_Sensitivity and PAM4 thresholds prior to applying
the DC_Offset?
Randy said if the EDA tool is using the DC_Offset then it may need to adjust
these parameters, too. Ambrish said these parameters are always to be applied
to the waveform returned by the model without the DC_Offset. He noted that
BIRD197.7 makes it clear the EDA tool may utilize DC_Offset for "post
processing". Hansel agreed, but he said the specification could be clearer.
Fangyi said there is no issue of ambiguity with Rx_Receiver_Sensitivity, since
it is applied relative to whatever thresholds are decided. That leaves the PAM4
thresholds, and Fangyi agreed with Ambrish that they do not contain the
DC_Offset. Fangyi also noted that BIRD197.7 says the tool may use DC_Offset for
post processing and display.
Randy said that if he were developing a GDDR6x model he wouldn't know what PAM4
thresholds to use, as those have to be trained. Fangyi noted that the model can
return new values for them with each and every GetWave call, so they can move
around. Ambrish said that the EDA tool can also compute them, and he recalled
that he'd introduced a topic a few weeks ago about the fact that the PAM Upper
and Lower thresholds are required according to the current specification (the
PAM4 Center can be left unspecified and the assumed default is 0V). He plans to
write a BIRD to remove the requirement that PAM4 Upper and Lower threshold
values be returned by the model.
Fangyi agreed with the gist of Hansel's clarification question. He said in a
real device the DC_Offset is gone after the comparator, and the device is
working with a differential signal. The model maker should be thinking of the
differential signal, and the threshold values should not include the DC_Offset.
Randy said the system has to train the 3 Vref levels used by a single-ended
PAM4 receiver, which makes it a bit more difficult for the model.
Arpad asked if we had consensus that Hansel's suggestion was useful and that
he should create a BIRD. Curtis said we seem to have consensus on what the
intent was, and he suggested the first sentence of Usage Rules: for the PAM4
threshold parameters might be the place to make Hansel's clarification. The
sentence ends:
"...when the signal is sampled:"
Curtis suggested the definition of signal could be clarified. Fangyi agreed
and said the intent was that "signal" meant the waveform returned by the Rx
GetWave, which has no DC_Offset. No one disagreed, and Hansel took an AR to
draft a BIRD to clarify the language.
Hansel asked Randy if the hardware would ever train the DC_Offset itself and
if it would be useful to have this parameter as an InOut instead of just an In.
Randy said there's a difference between DC_Offset, which is based on the driver
termination choices that set a particular DC level, versus training the Vref(s),
which represents the sampling voltage(s) and can be trained by the Rx. Hansel
said his question came from an NRZ example he'd been playing with, and he said
that he'd seen an issue with pre-emphasis in his Tx knocking down the DC level.
He asked if this was expected and if we had to worry about the DC_Offset value
being changed by the Tx. Fangyi said this question had come up in previous
discussions, and that in the physical system pre-emphasis should not affect the
DC offset. Hansel said he hadn't fully sorted his experiments yet, and it was
likely he just had a signal processing issue.
Redriver Flow Issues:
Arpad summarized the issues we had been discussing and reiterated his request
that we come up with some way to address the issues. He said we have identified
certain combinations of Init-Only, GetWave-Only and Dual models that are
difficult or impossible to support. We had spelled out some rules during the
discussion, for example, having an Init-Only model appear downstream of a model
with GetWave can be problematic. Arpad asked if Alaeddin's proposal would be
free of these problems, and if not, how do we address them?
Fangyi and Curtis said their impression was that Alaeddin's proposal did not
solve the issues with troublesome combinations. Arpad said the bottom line is
we have to find a way to address these combinations. Are we okay with spelling
out situations where model types will work together flawlessly and saying, "use
at your own risk" otherwise? Alternatively, do we have to find a solution that
supports everything?
Arpad noted that some people prefer Init-Only and GetWave-Only models or at
least think it's very important to support them. Others prefer Dual models.
With those two competing views, he wasn't sure we had a solution. Fangyi agreed
that before we try to resolve flow issues, we should decide what combinations
we support. Michael asked if we needed more specific BIRD language from
Alaeddin as opposed to his proposal presentations. He said from their
perspective Alaeddin's proposals introduced some needed clarifications and some
potential new parameters, even if they did not address all of the troublesome
combinations. Arpad said he wasn't yet sure exactly what changes Alaeddin was
proposing.
Arpad noted that Ambrish had drawn an interesting distinction in an earlier
meeting. He had said that Dual models were part of the flow in the sense that
such models could support the statistical and time domain flows. However, the
original flow discussions did not anticipate GetWave being dependent on what was
passed into Init. Arpad asked if eliminating that situation would reduce the
number of problem cases.
Michael asked if "Dual" model implied that the Init and GetWave are entirely
independent. Arpad said Dual does not imply any dependence between Init and
GetWave. Dual model means that the same EQ functionality is implemented in
both the Init and GetWave functions so that the EDA tool could perform the AMI
analysis in statistical or in bit-by-bit (time domain) mode. Ambrish agreed a
Dual model is one that supports both statistical and time domain flows using
one model. He reiterated his concern that the original intent was not to have
the GetWave function's results have any dependence on what was passed to Init.
David asked if Init_Returns_Impulse is the way we differentiate between the two
cases (i.e., if Init_Returns_Impulse is true, then the model returns a modified
IR and supports statistical flow). Michael said that he's focused on whether
the model supports the statistical flow, and deducing that from
Init_Returns_Impulse seems cumbersome. He said he'd prefer a parameter like
Model_Supports_Statistical_Flow, but he understood David's point. Michael
reiterated that his group wants models that support the statistical flow if at
all possible. They like to use DOE with statistical mode models.
Walter said that as an EDA vendor, if we see a model with Init_Returns_Impulse
true, then we assume the output of the Init function can be used for statistical
flow. If that model also provides a GetWave, then it means that statistical may
capture a lot, but to be more precise one needs to use the GetWave functionality
as well. We have to balance good use of statistical with its limitations vs.
using GetWave where you're likely limited to simulating to 1e-5 or 1e-6 BER. He
said the assumption is that the Init output IR includes all of the equalization,
and the GetWave output includes all of the equalization.
Walter said a third thing that Init can do is adaptive equalization for things
like CTLE, which it can provide to GetWave even if it doesn't return an IR.
David asked how the info gets communicated between Init and GetWave. Walter
said it's done internally within the model. The Init function may adapt the
CTLE based on its input IR, and then the GetWave uses the CTLE settings and may
do further optimization itself. Ambrish said this behavior represents a design
decision by the model maker and is independent of EDA tools.
Walter summarized and stated that there are 3 possible functions of Init:
- memory allocation and setup
- output a modified IR (Init_Returns_Impulse is true)
- Internally pass information to the GetWave function.
Walter summarized his position on the flow issues:
- We need a corrected flow.
- GetWave flows are fine, and the input to every GetWave is the cumulative
upstream waveform.
- We need to change the Init flow to focus on the upstream information as well.
We should never pass a downstream IR to an Init function. This is already
true for Rx models, but we should change Tx models to this upstream flow as
well.
- Walter said almost every Tx model he had ever encountered could work fine in
a new upstream mode. The only Tx model he'd ever seen that optimized itself
was never used in that mode because its optimization didn't work well.
Ambrish said we'll have to solve this next year. Arpad thanked everyone for
joining and for their work in 2020.
AR: Steve Parker to post Alaeddin's presentation to the ATM archives.
-------------
Next meeting: 05 January 2021 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
