Minutes from the 8 December ibis-atm meeting are attached.
The documents discussed during the meeting can be found here:
http://ibis.org/atm_wip/archive-date.html
IBIS Macromodel Task Group
Meeting date: 08 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 agenda email mistakenly said this is the last meeting of
the year. Next week's meeting on December 15th will be the last of the year,
and meetings normally scheduled for December 22nd and December 29th are
cancelled.
- Walter said that at some point he would like to discuss the clock-forwarding
BIRD (BIRD204) and some combinations we may or may not want to support. For
example, if the DQ model says it takes "times" as a clock input, then the
associated DQS model should return clock ticks in its clock_times argument.
-------------
Review of ARs:
- Randy to send his GDDR6x simulation results presentation to the ATM list.
- Done. Arpad noted that Steve Parker had posted it to the ATM work archive.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the December 1st
meeting. Michael moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
Redriver Flow Issues:
Alaeddin reviewed his new presentation "Symmetric Processing of IBIS AMI
Redrivers and Handling AMI_Init only Models_ATM". He noted that he had taken an
AR at a previous meeting to document his flow ideas with figures in addition to
his mathematical notation.
slides 5-7: Simple Tx->Rx flow
- In the current flow, the Tx Init gets the unequalized post-channel IR.
- What's nice about this legacy approach is that Tx and Rx Init functions get
invoked one time each and in sequence.
slides 8-11: Redriver Flow
- Note that pre-channel and post-channel terminology is with respect to the
redriver (also known as upstream and downstream channels).
- The IR of the channel after any Tx is always passed to the Tx unequalized.
- Note that convolution is used so the final Rx sees the entire upstream
information (slide 11).
Walter noted that slide 11 does not depict the flow currently in the
specification. In the current flow, the output of the Redriver Rx is convolved
with the output of the final Rx, and the redriver Tx and the final Rx only see
the downstream channel information. This is the flaw in the current redriver
flow, the redriver Tx and final Rx don't receive the upstream IR information.
slide 12 - handling Init-Only models
Alaeddin thought it was not a good idea to exclude existing model types from
the flow. The slide proposes that effects from Init-Only models can be
handled in a GetWave flow by substituting the IR returned by Init in place of
its nearest connected channel's original IR. He noted that he considers
"combined" Tx/Rx redriver models a pathological case, and they break the
"nearest channel" rule because a combined Tx/Rx connects to both the upstream
and downstream channels. He said in his experience these combined Tx/Rx
models are disappearing in the industry, and he hopes this continues.
Walter said that Init-Only models can be handled as long as they are the
upstream models, i.e., the first models encountered in the left to right
progression. As soon as you have a GetWave-Only model upstream of an Init-Only
model, the Init-Only model is not getting the full IR information it needs.
Curtis said a Dual model upstream of an Init-Only model could cause double
counting of the Dual model's effects in time domain flow or could require
deconvolution.
slide 14 - Proposed new Keywords (Note: actually AMI Reserved Parameters)
Alaeddin proposed two new keywords for the redriver Tx and Rx respectively.
AMI_RE_TX_EQ_MODE = POST (or PRE, or BOTH)
AMI_RE_RX_EQ_MODE = PRE (or POST, or BOTH)
The default for the Tx is POST, and the default for the Rx is PRE, to match
the existing specification. However, either could be set to PRE, POST, or
BOTH depending on what the model maker wants for input IRs to Init.
slides 15-16: Example flows with new parameter settings.
slide 15 - Note that if the AMI_RE_TX_EQ_MODE is PRE, the EDA tool knows it has
to explicitly convolve the output of the redriver Tx with the downstream channel
before passing it to the final Rx.
Arpad asked for clarification of the meaning of the left-pointing white arrows
starting in slide 5. He asked if these were meant to convey the fact that the
original IR of the channel (measured at the receiver) is what is passed into the
Tx in the existing flow. Alaeddin agreed with Arpad's explanation.
Walter noted that his recent proposal had been to change the flow so that the
input to any Tx is its upstream IR (unlike the current flow, in which the input
to a Tx is its downstream channel's IR). He said in the case of the initial Tx,
the input would be a unit IR. The EDA tool would then handle convolving the
output of the Tx Init with the downstream channel IR. He wants the Tx to only
look at the upstream information, just as the Rx only looks at the upstream
information. He said this would make the Init flow symmetric with the GetWave
flow and would simplify things considerably. He asked Alaeddin what he thought
of this proposal.
Alaeddin said the Tx Init functions might be expecting something reasonably
smooth and could have trouble with an ideal unit IR. Walter noted that if a
channel was very short the Tx would have to deal with such a case anyway.
Alaeddin said that since these are behavioral models anyway, he could see the
model maker wanting the flexibility to give PRE, POST, or BOTH as inputs. This
extra flexibility might allow the model maker to minimize the equalization
adaptation that has to take place during time domain simulation (i.e., reduce
the Ignore_Bits value). However, he agreed Walter's proposal could work.
Walter said the whole point of the original flow passing the downstream IR to
the Tx was to try to be clever and give the Tx information so it could adapt.
However, in hindsight, we've seen this wasn't a great approach. In practice,
with this method the Tx models often over equalize relative to what they would
do with proper back-channel communication with the Rx. Alaeddin said that
back-channel gets complicated, and if it becomes widely adopted in the industry
maybe it will become a real option. Walter said that when the statistical BCI
BIRD is part of the standard, industry adoption may improve.
Arpad asked if the approach in Alaeddin's slides would still leave us with
problems mixing GetWave-Only, Init-Only, and Dual models. He recalled that
Ambrish had said last week that the specification did not originally envision
a GetWave function that depended on the IR input to Init. Arpad asked, if
that's the only issue, could we resolve it with a parameter that says GetWave
depends on the Init results?
Alaeddin said there are already many redriver models with an Init-Only Rx and
a Get-Wave only Tx that exist in the industry. We have to make sure not to
disallow this combination. He said handling upstream Init-Only models isn't
hard, and the effects of such models can be folded into the IR of the channel
to which they're connected.
Hansel asked if Alaeddin's proposal was making the assumption that the Tx has
identical rising and falling edges, since it proposed folding the output of
the Init-Only model into the channel IR. Alaeddin said the case of differing
rising and falling edge rates is inherently non-linear, and Init can't handle
that. Wei-hsing agreed with Alaeddin that Init-Only models are limited to
LTI, and the model maker needs to provide a GetWave to deal with rising/falling
edge rate differences.
Walter said that if you have asymmetric rising/falling edges, and you think the
effect is important, and you don't have a GetWave, then there are creative
things an EDA tool could do to make a proxy GetWave that reflects the rise/fall
asymmetry by looking at the rising and falling IRs separately. Wei-hsing agreed
and noted a paper he had given at the DesignCon Summit two years ago. He said
there are certain shortcomings on the modeling side that can be covered over by
the EDA tool. If we make the language in the specification too restrictive, we
might deprive the tool of a chance to compensate and deal with problematic
cases.
Walter said we have a simple flow that is valid and reliable if everything
upstream of the terminal Rx is Init-Only, and the terminal Rx is GetWave-Only
(or Dual). That works fine. This can be generalized a bit to say that if we
have a chain of Tx and Rx models, then everything upstream of the first model
with a GetWave can be Init-Only, everything including and after the first
model with a GetWave should be Dual, up until the terminal Rx, which may be
Dual or GetWave-Only. In that situation we have a straightforward flow and the
tool should be able to simulate reliably.
Arpad asked if we could just put language to that effect into the specification
and be done with this issue. Alaeddin said he didn't understand why we would
want to restrict Init-Only models. Walter said that if an Init-Only model comes
after a model with GetWave, the tool needs to use deconvolution, which can be
problematic. Alaeddin agreed that deconvolution is problematic, but he said he
thought GetWave-Only models were more troublesome than Init-Only, and we should
certainly never expect the tool to synthesize an effective IR from a GetWave-
Only model.
Walter said he had asserted that any Init-Only model can/should be made into a
Dual model by the model maker. This left only GetWave-Only models to address.
Walter said that any time there's a GetWave-Only model in the chain, any
downstream Init-Only model is rendered useless even in the statistical flow,
and any models downstream can't rely on their Init functions providing proper
equalization information to their GetWave functions. He said it would be nice
if we introduced some parameters to indicate various dependencies so tool
vendors don't have to qualify models to make sure they run effectively under
various conditions.
Arpad said we will continue this discussion next week, and he asked everyone to
focus on what we can do in the specification to address these issues. Alaeddin
suggested that it would be helpful if other proposals were put into the form
used in his presentation. He thought this would make comparisons easier for
everyone.
AR: Arpad to ask Steve Parker to post Alaeddin's presentation to the ATM
archives.
-------------
Next meeting: 15 December 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
