Minutes from the 05 January ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 05 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:
- Fangyi said he had prepared some slides on the Redriver flow topic.
-------------
Review of ARs:
- Steve Parker to post Alaeddin's presentation to the ATM archives.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the December 15th
meeting. David moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Redriver Flow Issues:
Arpad noted that he had included Walter's summary of the issues, taken from the
previous meeting's minutes, in the agenda email. He reiterated his request that
we come up with some way to address the issues not just identify them.
Fangyi shared a presentation "AMI Redriver flow".
- slide 2: Problem Statement
Fangyi said his presentation is largely based on Walter's recent proposal. It
is based on the same assumptions, but it adds some modifications.
The problem statement is:
Assuming all models have GetWave and Init_Returns_Impulse=true (i.e., the Init
function returns a modified IR), the only issue is that the redriver Rx/Tx Init
doesn't have the cumulative upstream IR. So the Init cannot perform
optimization properly and can't provide the IR needed for statistical
simulations.
David asked about the formulation of the problem statement. He said the
redriver Tx Init doesn't receive the cumulative upstream IR, but he thought the
redriver Rx Init did. Fangyi said the statement could be clarified. He added
"and the terminal Rx" to the statement. He said that for any Rx after the first
Redriver (either a subsequent Redriver's Rx, or the terminal Rx) the Init
function does not get the cumulative upstream IR information.
Ambrish asked Fangyi to clarify that there is no problem in the GetWave flow.
Fangyi said not exactly, even in the GetWave flow some models may want Init to
do some of the optimization. Ambrish said this behavior is a convenience or
performance optimization used by the model maker. According to the standard,
if the GetWave does everything it needs to do, it should not rely on what was
passed into Init in order to get the right answer. Fangyi understood Ambrish's
position, and he said this presentation is only concerned with the statistical
flow.
- slide 3: Conventions
Fangyi introduced the notation conventions he uses for the channel IR, IR with
the Tx effects, redriver Rx as opposed to a regular Rx, etc.
- slide 4: Statistical Simulation with crosstalk
The diagram shows two separate channels, each with a redriver. Fangyi said that
there are many possible paths for crosstalk from one channel's Tx to the other
channel's Rx, and the diagram doesn't show all of them. He noted, for example,
that the diagram did not show the path from Tx1 directly to the Rx2. Fangyi
said it would be more efficient for the EDA tool to compute all possible paths
from one Tx to the other Rx if it has all the IRs (with Tx contributions, etc.)
available for each of the sections. To do that, we would still want to pass the
downstream IR information to the Txs (as in the existing flow).
- slide 5: Solution proposal.
Fangyi said his proposal is similar to Walter's proposal to start passing
upstream info to Tx Init instead of downstream info. The difference is that
instead of replacing the downstream IR with the upstream IR, Fangyi proposes
appending the cumulative upstream IR to the end of the existing IR matrix. The
function signature of Init would not be changed, there would just be an extra
column added to the IR matrix passed into Init. Fangyi noted that if a Tx Init
doesn't perform any optimization, then it doesn't need to use upstream
cumulative response.
Walter said that crosstalk was important, but for illustrative clarity let's not
consider any crosstalk. He said in that case the new input to the Tx Init would
be two columns, the first being the downstream (existing spec) and the second
being the cumulative upstream. Fangyi agreed, and he said he was proposing two
columns for the Rx too, the first being the immediate upstream (existing spec)
and the second being the cumulative upstream. He said two columns were needed
for the Tx and Rx to get all the IR terms the EDA tool needs to compute all the
paths.
Walter proposed what he thought was an even simpler solution (using the same no-
crosstalk terms for illustrative simplicity). The input to every Init would be
the cumulative upstream IR. The output of every Init would consist of two
columns. The first would be the modified input IR (existing spec), and the
second would be the IR of the equalization itself. Then there would be no need
to add the crosstalk terms to the input IR matrix. The reason for doing so now
is so that the model can apply the equalization of the Tx to each of the cross-
talk terms. For the Rx, the second column would be the IR of just the analog
front end (CTLE, AGC, FFE). The DFE doesn't apply to crosstalk. The EDA tool
could then take care of all the convolution (crosstalk terms, etc.). Fangyi
agreed, but he said one reason we might still need to pass in the crosstalk
IRs in the IR matrix is that he thought some Rx models optimize their gain based
on the amount of crosstalk.
Arpad said he thought the suggestion to have Init return the IR of the
equalization itself had been made several times in the past. He thought some IC
vendors had been worried about revealing IP in that case. Fangyi agreed that
when he had first gotten involved with AMI, he thought the reason we wanted the
model to return a modified channel IR was to hide the equalization that was
applied. David said that if this had been the case, then since deconvolution
techniques could often be applied it's actually pretty easy to back out the
equalization effects. He said concern about revealing IP should have more to
do with the circuitry itself, and he thought AMI already protected that since it
is a behavioral modeling technique. He asked what Si vendors thought about
whether it's realistic to hide the equalization in a Tx or Rx model. Arpad
noted that when IBIS itself was first proposed by Intel, the thought was that
the table based behavioral model was wonderful and would protect IP. However,
Intel later started releasing IBIS models under NDA only, because they found
that the I-V and V-T curves themselves could just be used by competitors who
then avoided having to do all the work to create their own.
Arpad asked, if IP protection is no longer an issue, then is Walter's simplified
version sufficient? Do we not have to pass in the crosstalk terms, or is
Fangyi's point about the model optimizing based on crosstalk important?
Arpad asked whether it's redundant to return the modified IR (existing flow) and
the IR of the equalization itself. Couldn't the tool do everything itself if
it had the IR of the equalization? Walter said this was only true for the Tx.
For the Rx, the EDA tool can't do the DFE because the model would only return
the IR of the analog front end (AFE). He said we could have the Rx model return
two equalization IRs, one for the AFE and one for the DFE. Walter said this was
a solution Fangyi had proposed during the original discussions on this topic
a few years ago. Fangyi agreed, and said at that time we didn't assume every
model had GetWave, so it was more complicated. Now perhaps we can assume all
models are Dual. Walter agreed, but he said we don't require all models to
be Dual. You can have Init only models at the beginning of the chain, but once
you have a model with GetWave every model downstream also has to have GetWave.
Arpad noted 3 variants that had been discussed today:
1. Fangyi's proposal (add cumulative upstream IR column to the input)
2. Walter's proposal (model returns additional IR of the equalization - only
the part that would apply to crosstalk terms)
3. Model returns nothing but the filter IR(s) (perhaps AFE and DFE in separate
IRs).
Fangyi said his proposal was designed to minimize impact on the existing spec
(no change to AMI function signatures). Walter said he thought his proposal had
minimal impact, since we could just add a reserved parameter to indicate whether
the model returns the crosstalk equalization IR. If it doesn't, or the tool
doesn't recognize it, then it works on the existing tools with no changes.
Arpad said we have the contentious case of a GetWave function that relies on the
IR input to Init. He asked if that would be solved by any of the three options.
Walter said you'd still have the issue of making sure each Init is getting the
full upstream channel information. The only model that could have
Init_Returns_Impulse=false would be the terminal Rx. Ambrish said we were now
venturing from addressing statistical simulation flow with redrivers all the way
to tackling a general time domain flow. He reiterated that the flow Walter
just described (with a GetWave reliant on Init's input IR) was an overload of
the Init function for the model maker's convenience/performance. A GetWave
function should always be complete, and while it may take longer to converge
without the right input to Init it must be able to deal with that possibility.
He asked if we were really now going to legislate that all models (except the
terminal Rx) must be Dual? Arpad said he had just asked the question to see
if any of the 3 variants was preferable because it would handle the problematic
case. Fangyi said that the last time we had discussed it, everyone except for
Michael Mirmak seemed okay with assuming that every model has a GW function.
Arpad recalled that Michael's primary concern was really that he wanted models
to support statistical flow if at all possible.
Fangyi said he would compile a comparison of the pros and cons of the variants.
Arpad said this would be helpful, and asked him to add the comparison to his
presentation slides. He suggested we hold off on posting today's presentation
slides and post them after a future meeting when Fangyi has added the comparison
information.
- Curtis: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Fangyi to add comparisons of proposed variants of Init function input/output
data to his presentation.
-------------
Next meeting: 12 January 2021 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
