Minutes from the 10 May ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
10-MAY-2016 Fangyi Rao Keysight Technologies AMI Simulation Flow Round 3 v4
(zip
<http://ibis.org/macromodel_wip/archive/20160510/fangyirao/AMI_Simulation_Flow_Round_3_v4.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160510/fangyirao/AMI%20Simulation%20Flow%20Round%203%20v4/AMI_flow_round3_v4.pptx>
)
IBIS Macromodel Task Group
Meeting date: 10 May 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
* Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
[Pin Reference] BIRD Draft:
- Discussion: Bob suggested that we defer discussion until Walter is available.
Bob noted that Walter had sent out a draft for private review. Bob said that
he was working on some suggestions and some added examples. Radek asked if he
was on the recipients list of the private review email. Bob said he thought
so, but would forward it to Radek. Arpad asked if anyone else had any
comments or questions on the topic. There were none.
- New Redriver Flow:
- Fangyi: [sharing his updated "AMI Simulation Flow Round 3" version 4]
- I've updated the presentation with Walter's suggestions.
- [Slide 3 - Summary]
- Walter's first suggestion is reflected in the top row.
- RxInit() returns the IR of the non-DFE portion (gain and linear EQ).
- Previously RxInit() returned the convolution of the non-DFE portion with
the "Rx in partial". (CTLE and non-DFE used as synonyms below).
- Walter suggested the RxInit() should only output the CTLE portion.
- Tool can do the convolution.
- CTLE can also be used by the tool as it wants (cross talk for example).
- Input to RxInit() is still the same.
- [Slide 5 - Normal Time Domain Flow: if Tx has GetWave]
- Inputs are the same.
- Model returns CTLE IR.
- Model returns DFE IR.
- Model must internally perform the convolution of CTLE impulse and the
input AC so it can align the DFE cursor with that combined impulse.
- Time Domain Simulation:
- If Rx has GetWave()
- TxGetWave() output is convolved with AC and passed into RxGetWave().
- If Rx is Init-only
- EDA tool takes the output of TxGetWave() and convolves it with the
AC and with the Rx non-DFE, and on top of that it adds in the
convolution of the digital Tx input and the Rx DFE.
- Only difference is that AC * Rx non-DFE used to be returned directly by
RxInit(). Now the tool has to do the convolution.
- Radek: What are the advantages of returning the non-DFE separately, instead
of the non-DFE convolved with the AC?
- Fangyi: Walter mentioned that their tool has use of the CTLE filter, but he
didn't articulate the detail.
- One reason I can think of is that if the model doesn't support cross-talk,
then the tool can take this CTLE portion and apply it to the cross-talk
impulse matrix itself.
- Curtis: Originally, Walter had also suggested that we might not have to pass
in the cross-talk impulse matrix at all, right?
- Fangyi: Yes, that's true. He subsequently clarified that and decided that he
also wanted to keep the cross-talk matrices as well.
- Need to emphasize that because the model internally performs this
convolution (AC * Rx non-DFE) and uses it to align the DFE cursor, and the
tool will also perform this convolution, they must do it consistently. We
must have raw convolution only, without adding any arbitrary delay.
- At times I can imagine a tool or model might remove or add some delay before
the main cursor for efficiency reasons. But that would destroy the
alignment between the tool's convolution and the DFE taps from the model.
- [Slide 6 - Normal Time Domain Flow: if Tx is Init-only]
- Same returns from RxInit() (same as slide 5).
- Time Domain Simulation:
- If Rx has GetWave()
- EDA tool just convolves the Tx digital input with the TxInit() output
and passes it to RxGetWave(). Same as the current flow.
- If Rx is Init-Only
- EDA tool convolves the Tx digital input with the blue box output that
contains everything. Same as current flow.
- Note that the total output (blue box) is the partial input convolved
with the Rx CTLE, plus the Rx DFE. This is what current AMI models
are doing.
- [Slide 7 - Normal Statistical Flow]
- Same returns from RxInit() (same as slides 5 and 6).
- But the tool will just use the Total output (blue box) to represent the
entire system (same as current flow).
- [Slide 8 - Redriver Time Domain Flow: If Tx2 has GetWave]
- Time Domain Simulation:
- If Rx2 has GetWave()
- EDA tool convolves the Tx2GetWave() output with AC2 and passes it to
Rx2GetWave().
- If Rx2 is Init-only:
- EDA tool takes the output of Tx2GetWave() and convolves it with the
AC2 and with the Rx2 CTLE, and on top of that it adds in the
convolution of the digital Tx1 input and the Rx2 DFE.
- This convolution of AC2 and Rx2 CTLE by the tool is the change that
was made to incorporate Walter's suggestion.
- [Slide 9 - Redriver Time Domain Flow: Init-only Tx2]
- Time Domain Simulation:
- If Rx2 has GetWave()
- EDA tool convolves the Rx1 output with the Tx2Init() output and passes
it to the Rx2GetWave().
- If Rx2 is Init-only
- EDA tool convolves the Rx1 output with the Tx2Init() output and with
the Rx2 CTLE, and on top of that it adds in the convolution of the
digital Tx1 input and the Rx2 DFE.
- [Slide 10 - Redriver Statistical Flow]
- For the victim channel, the Rx total output (blue box) will be used.
- For crosstalk, the convolution of the Tx2Init() output and the Rx2 CTLE
output will be used for the aggressors that come in from Rx1.
- [Slide 11 - Summary]
- Updated the definition of the item in the first row (Rx in partial).
- The output returned by RxInit() in this location is now just the CTLE of
the Rx (gain and linear eq). Before it was the convolution of the CTLE
with the Rx in partial.
- Update to row 3.
- Note that the Rx DFE cursors are aligned to the convolution of the Rx in
partial and the Rx CTLE.
- Mike: Could you explain again the reason the DFE portion is separated off?
- Fangyi: The DFE is extremely non-linear. The filter representation of DFE can
only work with a square wave. It doesn't work with a continuous
arbitrary wave.
- Discussion: Mike wondered if we couldn't focus on something like the "non-
linear" portion or something not as specific to a certain technique as "DFE"
and "non-DFE" with an eye toward future solutions. Arpad asked if perhaps
calling the blocks linear and non-linear would work, but Fangyi noted that the
actual combinations of terms, like adding in the DFE convolved with the square
wave Tx Input, were specific to DFE and not just a general "non-linear" block.
Mike noted that he was just suggesting that we keep an eye toward using
terminology as general as possible.
- Fangyi: [Slide 12 - New Reserved Parameters]
- Based on the last discussion, we decided we could use one parameter as per
Walter's suggestion.
- New single parameter indicating newly proposed flow.
- Optional, Boolean, In, Default = False, Format = List {False, True}.
- Its presence in the .ami file indicates the model supports BOTH the
proposed and current (6.1) flows.
- A model that supports the proposed flow must also support the 6.1 flow.
- If the parameter is not specified in the .ami file, the tool executes
the 6.1 flow without passing this parameter in to AMI_Init().
- If it is specified in the .ami file, and the EDA tool wants to execute
the new flow, then it sets the value to true and passes it in to
AMI_Init().
- If it is specified in the .ami file, and the EDA tool wants to execute
the 6.1 flow, then it would not set its value in the string passed to
AMI_Init().
- Discussion: Radek commented that the second and third bullet points were
restating the same thing, both lines stated that a model that supported the
proposed flow must also support the 6.1 flow. Fangyi said the third point
emphasizes that a model must support both flows if it supports the proposed
flow, it cannot support only the newly proposed flow. Arpad asked if the
intention was to allow a model that advertised itself as "6.2" to only
support the 6.1 flow. Fangyi said yes, there is no intention to rely on the
version parameter and force any model greater than 6.1 to support the new
flow. Arpad asked if there would be a problem in a redriver channel if one Rx
supported the new flow and the other only the 6.1 flow. Fangyi said he had
considered that possibility and believed that such a mixed environment would
work properly. Fangyi expressed some reservations about the last bullet
point, which said the tool should not set the value if it wants to use the 6.1
flow. Radek said a tool that recognizes the parameter should be able to set
it to false (as opposed to not setting it at all). Curtis pointed out that
the bullet point implied the model should treat "false" as the default in case
a tool that didn't understand the parameter didn't pass it at all. Fangyi
agreed that this was the case he was considering with that bullet point.
Some people expressed concerns about what EDA tools using old parsers would do
with these new parameters, but this was viewed as something that affects any
new parameters not these in particular. Mike reiterated his thought from an
earlier meeting that using a single parameter for what could be considered two
way communication between the model and the tool was not ideal. Mike
suggested that an Info parameter could be used by the model to advertise its
support for the proposed flow, and a different In parameter could be used by
the tool to select the flow it wanted to use. Fangyi agreed that he felt that
Walter's single parameter suggestion amounted to hacking the parameter.
Fangyi noted that he had originally proposed two parameters (see v3 of the
document, posted April 19, 2016). The group reviewed Fangyi's earlier two
parameter proposal. Fangyi said he would prepare a version that reverted to
the two parameter approach, and asked for suggestions for improved names for
the two parameters. Name suggestions based on "Rx Supports" for the Info
parameter and "Simulator chooses" for the In parameter were made.
- Mike: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 17 May 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
