Minutes from the 17 November ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 17 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
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:
- David Banas reintroduced himself. He had attended in the past while a member
of Altera and eASIC. Arpad noted David's work on open-source IBIS-AMI related
tools and asked him to give a short description/overview of them to the group.
David said that he has public-domain open-source tools on GitHub. These
include infrastructure for AMI model creation, a python tool for wrapping AMI
.dlls and allowing them to be exercised and tested from python, and a serial
link simulator and design tool that can use IBIS AMI models for Tx and Rx.
Arpad suggested David send out links to these tools. David took an AR to do
so.
- Arpad's agenda noted the upcoming meetings during the holiday season. It
suggested the meetings be cancelled for November 24th, December 22nd, and
December 29th. Radek moved to cancel those 3 meetings. Curtis seconded.
There were no objections. Our next meeting will be December 1st.
-------------
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 10th
meeting. Michael moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
DDR6x:
Randy said he is still gathering data and may have more on this topic at the
next meeting.
PI Modeling in IBIS:
Arpad noted that Zhiping had sent an email to the ATM list saying that he could
not attend. Arpad suggested people reply to Zhiping's email if they have any
questions about this topic.
Redriver Flow Issues:
Based on the previous week's meeting and emails, Arpad suggested it might help
to create a list of which combinations of Init-Only, GetWave-Only, and Dual
models are easy, hard, or impossible to support. He thought having such a list
might facilitate discussion and decisions. The fundamental question is how do
we deal with the problematic combinations, or do we decide to prohibit them?
Once we make those decisions, we can figure out how to change the specification.
Walter noted that he had sent two versions of a "New Reliable AMI Flows"
document last week, and he had a third version to review in the meeting.
Walter said there are certain combinations of Init-Only, GetWave-Only, and
Dual models that are problematic. For a simple, single-channel, Tx to Rx,
there are 9 possible combinations. One that's problematic is when the Tx is
GetWave-Only and the Rx is Init-Only.
A second complication occurs because our flows support Tx Init functions that
optimize themselves based on their downstream channels. This is problematic
for a number of reasons, and he proposed that we could enhance the standard
or just create a list of recommendations that model makers to do things a
certain way.
The first suggestion is to make all models Dual. The exception is a terminal
Rx or retimer Rx can be GetWave-Only. Walter suggested that there should never
be an Init-Only model. If the model maker can create the Init function, then
it should be trivial for them to make a GetWave function that applies the same
equalization. An EDA tool trying to generate a pseudo-GetWave may rely on
deconvolution or something which is numerically problematic. Michael noted his
disagreement with the assertion that Init-Only models are never necessary but
said we could discuss that later.
Walter said that things get much simpler if Tx models don't adapt based on their
input IR. Only Rx models adapt, and they have the input IR and adapt their CTLE
and AGC and FFE, etc., but Tx models don't adapt, and they just apply their
equalization. In the case of a primary Tx, it applies its equalization to a
unit IR. In the case of a redriver, the Tx applies its equalization to the
output of the redriver's Rx. It's an unnatural act for Tx hardware to know
about the downstream channel. It was a cute idea originally to allow a Tx model
to optimize based on the downstream channel, but we now know that it's proven to
be not very useful in modeling.
Fangyi confirmed/emphasized the two assumptions Walter was making. First, all
models are dual, except the terminal Rx could be GetWave-Only or Dual
(Note: a retimer Rx could be considered a terminal Rx in this sense).
Second, the assumption is that Tx Inits do not adapt, as expressed in this
function in Walter's document:
UpstreamIR * txInit(DownstreamIR) = DownstreamIR * txInit(UpstreamIR)
note: * = convolution
note: this equation also describes Init_Is_Commutative=true
Walter agreed that these were the assumptions.
Fangyi asked for confirmation that the H1, H2, and H3 referred to that
individual
IRs of the "analog channels". Walter agreed and said they represent the IRs of
each channel along with the impedances of the Tx and Rx connected to it.
Given these assumptions, Walter's document shows the Init flow for the redriver
chain becomes a simple daisy chain of convolution operations. It becomes
identical to the GetWave flow, with IRs replacing the waveforms.
Arpad returned to his original question about problematic combinations and how
we could address them in the specification. He asked if all the problem cases
would be eliminated if we make the restriction that Tx Init functions should not
adapt. Fangyi said this was not sufficient, and that we also need the first
assumption that all models are Dual, except the Terminal Rx can be GetWave-only.
Fangyi also emphasized that the terminal Rx cannot be Init-Only. With these
restrictions, the existing flow in the specification works fine. Walter agreed.
Walter explained why every model upstream of the final Rx must have an Init that
returns an impulse. Some terminal Rx models do some of their equalization setup
during Init, even though they don't return an IR. These models may then do
additional equalization optimization in the time domain flow. He noted, for
example, that it's really hard to do CTLE optimization in time domain.
Fangyi emphasized one assumption in Walter's document that is a key difference
from the current specification. In the current flow for redrivers, the Rx Init
only gets the IR back to its nearest upstream Tx. In Walter's proposal the IR
passed to an Rx includes everything upstream (entire path back to the initial
Tx). Walter reviewed page 264 of IBIS 7.0 and confirmed Fangyi was correct
about the current flow (Note: Walter's BIRD166 proposal was originally created
to address the issue Fangyi described). Fangyi said the purpose of Walter's
proposed new "everything upstream IR" is to allow the terminal Rx to optimize
based on the entire channel, and a condition of being able to use the entire
upstream channel IR is that every upstream model has to have a GetWave.
Walter agreed but noted that it's not quite a requirement that every upstream
model is Dual. He said that in a chain from initial Tx to final Rx, the initial
models can be Init-Only, up until you hit the first model that has a GetWave.
That is, what you can't allow is an Init-Only model to appear downstream of
the first model that contains a GetWave. These combinations are explained in
Walter's document. Fangyi agreed, but said "why bother?" when we can just state
that the models should be Dual. Walter agreed that he would prefer to state
that models should be Dual. Walter said we all agree that the current redriver
flow is fatally flawed, since the terminal Rx does not get the full upstream
channel IR.
Walter noted that Michael had some reservations about the idea that an Init-Only
model can be trivially turned into a Dual model. Wei-hsing agreed that
theoretically any Init-Only model can be extended by the model maker to include
GetWave. However, he noted that this is putting extra work on the model maker,
and implementing GetWave may include non-trivial software issues such as dealing
with the multi-block waveform data in a GetWave simulation. He said that in
some common scenarios the EDA tool could provide a pseudo-GetWave instead of the
model maker providing GetWave. For example, for a Tx Init-Only model that does
not adapt and is fully LTI (i.e., the scenario Walter described with the
Init_Is_Commutative parameter in the second version of his document), the EDA
tool could reliably create a pseudo-GetWave without resorting to deconvolution
or numerically problematic methods.
Walter recalled that three years ago he had asked David to publish a GetWave
function that took an impulse response filter used in an Init function. This
GetWave function convolves the filter response with the input waveform to
create the output waveform, and it includes all the boilerplate to deal with
multiple blocks and overlap. Since David had in fact published this function
in the public domain, it was available to any model maker. So, Walter said
there is no real excuse for creating an Init-Only model, since converting it to
a Dual model is a straightforward exercise.
Arpad said we need to make sure any restrictions on types of models (e.g., Init-
Only) are carefully worded so that we don't exclude people from making their
preferred models. Walter said we didn't have to restrict the types of models,
but we could say that if someone makes Init-Only or GetWave-Only models there
are flows that don't work. Fangyi said we should hear Michael and Ambrish's
thoughts on Init-Only models. Walter took an AR to send out the document we'd
reviewed in the meeting.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Walter to send the new version of "New Reliable AMI Flows" to the ATM list.
AR: David to send the links to his public domain tools to the ATM list.
-------------
Next meeting: 01 December 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
