Minutes from the 10 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 10 November 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
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 Tuesday ATM meetings do not directly conflict with most
holidays this year. He asked if people wanted to cancel any and suggested
attendees think about it so we can decide next week. Randy suggested we
cancel the meetings the last two weeks of December.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the November 3rd
meeting. Randy moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
Walter summarized his recent email on the topic. He said the redriver flow
becomes simple if the input to every model is the accumulated upstream
channel information. This makes the Init flow similar to the GetWave flow.
There is still at least one troublesome case. If the terminal Rx is Init-only
then there are still some issues, but most things are simplified if the input
to every model is its upstream IR.
Fangyi asked if this included redrivers' Tx Init functions. Walter said it did.
The input to a redriver Tx would be the IR output by the redriver Rx. Arpad
asked if this meant the initial Tx Init would not be passed the channel
IR. Walter said yes, the input to the initial Tx would just be a unit impulse
response. He said it's more aligned with the way the hardware works.
Fangyi noted that this is different than the flow that is currently in the
specification. Walter agreed and said his proposal is to add a new optional
parameter that specifies whether the input IR to the Tx is the upstream
channel (unit IR for the initial Tx) or the downstream channel. If the Tx does
not adapt its equalization, i.e., if it's independent of the downstream channel,
you just convolve the downstream channel after the Tx instead of making it an
input to the Tx. It only becomes an issue if the Tx wants to optimize itself
based on the downstream channel. Walter recalled that the idea of passing the
downstream channel IR to the Tx seemed like a neat idea to some people when it
was first introduced in the days before we had back-channel communication
(BIRD147.6, BIRD201.1). Walter said he had objected to it initially, and now
we do have a history to deal with. But if we allow the option to make the input
to the Tx the upstream channel, then almost all of the flow problems go away.
Arpad said he understood the proposal, but he wasn't sure it made sense from a
practical point of view. If the redriver Rx gives its equalized output to the
redriver Tx, is there any reason for the redriver Tx to add more equalization?
After all, they are on the same chip back to back. Walter said the Rx model
might do CTLE, and the Tx model might add gain. Arpad observed that a redriver
chip and model come from one vendor. Walter agreed the model maker could put
everything in the Rx, or put it all in the Tx, or split it up as they saw fit.
The important point is that the redriver Rx gets the initial Tx equalization
convolved with the initial channel as an input, and its output goes to the
redriver Tx. He noted that there are some subtleties and the EDA tool would
have to know how to deal with the crosstalk IR terms properly.
Fangyi said the important aspect of Arpad's question was that the Tx
equalization, no matter how it's adjusted, is meant to compensate for downstream
loss, not upstream loss. Arpad agreed and asked how the Tx would know what it
wants to do to compensate for the downstream channel, unless it had back-channel
communication. Walter said that before we had back-channel, it seemed like a
good idea to pass the Tx the downstream channel so it could optimize itself
based on the downstream channel and improve the answer. He said we now know
that is not the thing to do. Often the Tx over equalizes, and the Rx undoes
some of it anyway. Now that we have back-channel, there's no need for the Tx to
know about the downstream at all. Once you say every model only needs to know
about the upstream channel, all the flow issues go away.
Arpad said that for a single-channel simulation we now have back-channel that
could allow the Rx to tell the Tx what to do, so the Tx can optimize for the
downstream channel. He asked if this would still be possible if there were
two channels with a redriver in the middle, i.e., would we have a back-channel
capable redriver Tx that is told what to do by the terminal Rx? Walter said
that BIRD147.6 (time domain back-channel) and BIRD201.1 (statistical back
channel) both allow for this exact scenario. The details would be defined in
the protocol, but each model along the chain can write info to and read info
from the file (BIRD147.6) or string pointer (BIRD201.1) to communicate with the
other models. Arpad asked if Walter's new parameter that specifies whether
a Tx is looking at the upstream or downstream IR would mess up the back-
channel flow. Walter said this would all be captured in the protocol, e.g.,
the protocol would state that none of the Tx models optimize themselves, and
the terminal Rx decides it all. The protocol would define it. For most
protocols the terminal Rx would control everything, and everyone else would
listen. One exception is DDR5, where the primary Tx does the controlling, but
it has to ask the terminal Rx to report what it sees in terms of signal quality.
Arpad said the other important question involves mixing and matching Init-only,
GetWave-only and Dual models. He said he thought the simplest way of dealing
with the issue might be to state that every model has to have an Init that
returns an impulse (statistical flow), or every model has to have a GetWave
(time domain flow), but the specification doesn't make that restriction. He
asked if we could simply add that restriction. Walter said that if every model
in the path returns an impulse, then if it doesn't have a GetWave the tool can
create a proxy GetWave for it. This is especially true if the input to Init is
always the upstream channel. In that case, then if a model also has GetWave the
tool can use it, or if not the tool can apply the proxy GetWave using the
equalization from the Init.
Fangyi asked how this would work if the terminal Rx has DFE. Walter said a
typical channel might have all upstream models Init-Only and the terminal Rx a
Dual model. In fact, the terminal Rx is the one model that would not have to
have an Init that returns an impulse. If all the upstream models have an Init,
then whether they have a GetWave doesn't matter, and the terminal model can be
Init-only, GetWave-only or Dual, and everything is fine. Walter said the only
problem is if you have a GetWave-only model anywhere upstream and the final Rx
is Init-only. That case is problematic because the tool would have to use
deconvolution. Arpad asked if it would be sufficient to make a statement that
this problematic case is not supported, or do we need to find a way to support
it?
Fangyi said the redriver flow has problems if the upstream Tx for any channel
has a GetWave function and the downstream Rx is Init-only. The problem exists
whether the Tx is GetWave only or Dual. Walter said anytime you have an Init-
only model (that is only dependent on its upstream), then the input to that
model can just be a unit IR and you get the equalization of the model back as
the returned IR. Then the tool can use that to create a proxy GetWave. Fangyi
said if you give the redriver Rx an ideal unit IR, then it can't optimize
itself. Walter agreed that if the redriver Rx optimizes itself then we have a
problem.
Walter agreed that if the Tx has to have a GetWave to handle non-linear effects
such as saturation, then in that case you want your Rx models to be Dual. He
said he would prefer that all models were Dual, and the statistical flow gets
all it can from the Init, but you need the GetWave time domain flow for non-
linearities.
Arpad asked how to handle this in the specification. He noted that when we
started these discussions a year ago we came up with all of these problematic
combinations and struggled to figure out how to support all of them. He said
some of the issues remained, even with Walter's proposed new parameter, and he
wondered if we should enumerate/prohibit the combinations that are problematic
or try to figure out how to support all of them. Walter said we could state
that if every model were Dual or Init-only, except that the final Rx could be
GetWave-only, and this new parameter were set to say that they all look only at
their upstream channels, then the flows are simple, and everything works.
Outside of that, the user risks tool-dependent behavior and incorrect results.
Fangyi said if we allow arbitrary combinations we will likely always run into
trouble. Since we have to restrict certain combinations, why don't we just make
it simple and require that every model is a Dual model? Then the flows are
simple and they work. Walter said he totally agreed. Arpad said he was okay
with this idea, but he and several others recalled that Ambrish was likely to
disagree.
Hansel asked if the specification would have to add anything to deal with cross-
talk for the redriver flow. Walter and Fangyi said this was already handled.
Fangyi noted that the Rx impulse matrix includes the IRs from all potential
aggressors, and the Tx impulse matrix includes the IRs to any potential victims.
PI Modeling in IBIS:
Zhiping reported that he was planning to meet with TI to gauge their interest in
joining the discussion. He is putting together a list for another IEEE sandpit
event for Q1 and asked anyone interested in joining to contact him.
- Curtis: Motion to adjourn.
- Zhiping: Second.
- Arpad: Thank you all for joining.
AR: None.
-------------
Next meeting: 17 November 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
