Minutes from the 11 April ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 11 April 2017
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
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor, A Siemens Business: 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
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Mike LaBonte to post Walter's BIRD 166.1 proposal and presentation.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Radek: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow BIRD:
- Discussion: Arpad asked for clarification on a point Ambrish had made at the
previous meeting. Ambrish said his point had been that Walter's BIRD 166.1
fixes today's flow, while changes proposed by Fangyi affect the IR matrix
passed to Init(), but would not change the flow. Arpad again said that he
wanted to ensure that if we accepted the BIRD166.1 proposal it would be an
incremental step, and we could add Fangyi's proposed changes later to get
time domain working without having to backtrack on any BIRD 166.1 changes.
Walter noted that in his proposal and Fangyi's the final IR input to the Rx2
Init() was the same, but Fangyi's proposal included some additional outputs
from the Rx Init() functions. He also said that our time domain flow was
already working because the output of Rx1's GetWave() is passed to Tx2's, and
the output of Tx2's is convolved with the IR of channel 2 and passed to Rx2's
GetWave(). Therefore, everything is accounted for at Rx2's GetWave().
Fangyi said the issue is with Init() processing, even for a bit-by-bit
GetWave() flow. Arpad asked if our flow was okay for a pure GetWave() only
flow. Fangyi said no, even for GetWave() flow the AMI model for the Rx may
optimize its tap settings in Init(). He said Init() has two effects, one
might be to change the IR if it supports Init only flow, but the other could
be to initialize internal settings, optimize, choose tap weights, etc. An
Rx might have DFE, for example, and not return an IR from its Init() but
still use the IR input to Init() to decide on its taps.
Walter described a scenario in which none of the AMI_Init() functions returned
an IR. In this scenario, the input to the Rx2 Init() would only contain the
the upstream channels and none of the upstream equalization effects. In this
scenario, if the Rx were doing its optimization of the DFE taps in Init(),
then even the time domain flow is broken. He noted that this had always been
broken, and that workarounds had been presented in a DesignCon paper. He
noted that even a regular flow (no repeater) was subject to this flaw.
Fangyi asked how this could occur in a regular flow. Walter said that if the
Tx were GetWave() only, and if the Rx optimized its tap weights in Init() and
not in GetWave(), then the same problem existed. Fangyi said that would be a
Tx model problem, not a flow problem.
Ambrish objected to Fangyi's characterization of the GetWave() only Tx as a
"model problem," and said the spec allows a Tx model to be GetWave() only.
Bob Miller noted that he had produced Rx models that behaved as Fangyi and
Walter had described. These models do not return an IR from Init() (i.e.
"GetWave() only"), but their Init() functions expect IRs that represent
everything in front of them, and they generate the tap weights accordingly.
The GetWave() flow then uses the tap weights set during Init(). This led to
a discussion about dual-mode models vs. Init Only vs. GetWave Only. Arpad
asked if we needed to tighten up the spec to ensure that simulations would
produce the right results when models from different vendors were mixed.
Walter and Fangyi felt that ideally the models should be dual mode. Ambrish
acknowledged that there were certain limitations if a model did not provide
some approximation of its behavior in a modified IR returned by Init(), but
he objected to any sort of mandate for dual mode models. He said that dual
models caused confusion for some users when Init() flow and GetWave() flow
provided different results. He did not think the solution was to mandate
that a model handled equalization in the Init() and GetWave() (dual mode).
He noted that the spec currently warns against issues that can occur when
mixing models of various types. Walter agreed with Ambrish that the spec
shouldn't mandate dual mode models.
Returning to Arpad's original question, Walter said that he felt his proposal
would not interfere with Fangyi's. He said there could still be problem
scenarios, but these were pre-existing. Arpad noted a comment from Vladimir
that we should be very clear that BIRD 166.1 is only talking about statistical
flow. Walter said he thought this was already implied, but he was open to any
suggestions for modified wording.
Fangyi said he was not sure BIRD 166.1 was compatible with his proposal. He
noted that it still did not provide the IR from Rx1 to Rx2 so it still did not
handle crosstalk, and it was unclear how it would extend to cascaded
redrivers. Walter noted that he had suggested one additional change to
Fangyi's proposal, passing the Tx Init() two IRs, one which was the output
of the redriver Rx Init(), and one which was the downstream channel. Walter
said if this were done it would resolve the crosstalk issues entirely. Fangyi
said this led to the question about how it would extend to cascaded redrivers.
In a two-repeater system, what would be the input to Tx2? Walter said Tx2
would get the output of Rx2 Init(), which contained everything upstream, and
also the IR of the downstream channel. Walter said the IR representing the
downstream channel would only be for the next channel, not all subsequent
channels, because all we needed was the information to get to the next Rx.
He noted that the very first Tx in the chain would only get the one IR
representing the immediate downstream channel. Fangyi asked why, even in
a single repeater case, the initial Tx stopped at the first Rx? Why wouldn't
the initial Tx want to optimize the entire channel? Walter said this got into
back channel and optimizing everything together. Fangyi said in theory any
Tx and Rx could communicate (via backchannel) to optimize, but in reality all
of the redrivers ran on fixed set-ups and did not optimize. Walter said in
that case it was academic and the BIRD 166.1 flow worked. He said one might
in theory have a complicated system in which the primary Tx wants to optimize
based on what's happening at the terminal Rx, but silicon doesn't do that.
Fangyi said perhaps that's actually where backchannel should happen, between
the terminal Tx (initial Tx) and the terminal Rx. Walter noted that in some
cases (DDR5) the Tx on the controller is optimizing the Rx, not the Rx
optimizing the Tx as we often think of it in backchannel discussions. Fangyi
said this raised another fundamental issue with AMI, we always call Tx Init()
first. Walter noted that we may need another BIRD to add iterative AMI_Init()
sequences or some other method to allow every Tx and Rx to communicate. He
noted that BIRD 147.6 had been dramatically simplified and only contained
iterative backchannel calls during GetWave().
- Arpad: I'd like to encourage everyone to look over the proposal again to see
if we can come to a decision on this BIRD draft.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 18 April 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
