Minutes from the 16 May ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the ATM work archives.
16-MAY-2017 Walter Katz SiSoft To Dual Or Not To Dual (zip
<http://ibis.org/atm_wip/archive/20170516/walterkatz/To_Dual_Or_Not_To_Dual.zip>
)(pptx
<http://ibis.org/atm_wip/archive/20170516/walterkatz/To%20Dual%20Or%20Not%20To%20Dual/To_Dual_Or_Not_To_Dual.pptx>
)
16-MAY-2017 Walter Katz SiSoft Resolving problems with Redriver Init Flow
BIRD 166.3 draft 1 (zip
<http://ibis.org/atm_wip/archive/20170516/walterkatz/Resolving_problems_with_Redriver_Init_Flow_BIRD_166_3_draft_1.zip>
)(docx
<http://ibis.org/atm_wip/archive/20170516/walterkatz/Resolving%20problems%20with%20Redriver%20Init%20Flow%20BIRD%20166.3%20draft%201/bird166.3_draft1.docx>
)
IBIS Macromodel Task Group
Meeting date: 16 May 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
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:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 166.3 Redriver Flow:
- Arpad: Last week Fangyi's presentation showed that BIRD 166 flow changes could
get us into more trouble in some situations, particularly with
deconvolution and non-linearities.
- We need to make a decision on whether to go forward with BIRD 166 and how to
plan to move on with the redriver flows.
- Walter: [sharing his "To Dual or not to Dual" presentation]
- [slide 2]
- Defines the terms Init-Only, GetWave-Only, Dual.
- Based on the settings of Init_Returns_Impulse and GetWave_Exists.
- Arpad: Does Dual just mean Init_Returns_Impulse and GetWave_Exists are true?
- Or, does it mean that GetWave() duplicates all the functionality in Init()?
- Walter: When Init_Returns_Impulse is true, the IR output contains all the
equalization (limited to LTI portion).
- GetWave_Exists being true means the GetWave() function returns a waveform
that also includes all the equalization, but GetWave() has the ability to
deal with non-LTI behavior.
- Arpad: That implies whatever was in the Init() is also in the GetWave()?
- Discussion: There was some disagreement over the true definition of a dual
model. Arpad's question was getting at whether Init() and GetWave() had
to implement their equalization independently. Consider the types of
models described by Bob Miller, wherein the Init() function determines
the taps based on its input IR. His GetWave() function then applies
those same taps, with the possibility of additional corrections for non-
linear effects. In such a model, the GetWave() output is not correct if
the Init() were not given the proper IR. Walter considered such a model
a dual model (because both Init() and GetWave() provide the equalization).
Ambrish did not consider such a model a true "dual" model, because the
GetWave() output cannot independently achieve the correct equalization
(it is reliant upon the Init() flow). Ambrish objected to the GetWave()
flow being tied to the IRs available at Init() time.
- [slide 3] Additional Configuration Subtleties
- GetWave() function's behavior may depend on the IR input to Init(),
whether or not Init_Returns_Impulse is True.
[Again, models of the type Bob Miller described]
- [slide 4] With BIRD 166.3, flow validity.
- Note: David suggested replacing "upstream" with "non-terminal". Walter
made the change(s) in the document as discussion continued.
- Statistical flow valid if:
- Init_Returns_Impulse is true for every model.
- Time Domain Flow (guaranteed) valid if:
- Every non-terminal model has:
- Init_Returns_Impulse is true
- GetWave_Exists is true
- The terminal Rx has:
- GetWave_Exists is true
- (no requirements for Init_Returns_Impulse)
- Ambrish: You are saying the time domain flow is not (guaranteed) valid if
Init_Returns_Impulse is false for any of the (non-terminal) models?
- David: Yes, based on the models described by Bob Miller.
- Ambrish: That's a model requirement (of Bob's models), not a flow requirement.
- [slide 5] Problematic Flows
- Statistical flow is problematic if any model's Init_Returns_Impulse is
false.
- Ambrish: Is this a surprise to the model maker?
- The model maker understands this if they've chosen to make a GetWave Only
model.
- [slide 5] continued
- Time domain flow is problematic if any non-terminal model has
Init_Returns_Impulse set to false. (because it breaks the chain of IRs
at Init time and could cause problems for models such as Bob Miller's).
- Terminal models are the exception, and only need a GetWave().
- We recognize that the Terminal Rx is a unique model. It may have a CDR,
and DFE, and it's adaptive, and people may want to generate GetWave()
only models and have difficulty generating a meaningful IR from Init().
<Bob Miller joined the call>
- Ambrish: Again, you're saying that if an upstream model has a GetWave(), but
it doesn't return an IR from its Init(), that's a problem for a
time domain flow?
- Walter: Yes. Two years ago I would have said having a GetWave() was enough.
- Now we've discovered Bob is delivering models where GetWave() doesn't work
properly if the correct IR wasn't given to Init().
- Bob M.: Appropriate for me to give a brief explanation of how we got there.
- Historically, the Rx models we were generating were not in channels with
repeaters. We were talking to a Tx, particularly ones that were LTI, so
it was trivial for them to return an IR from Init(). If everything
upstream is LTI, there is no difference between taking that IR and
convolving it with an internal bit pattern into a time domain waveform
inside Init() or taking the bit-by-bit pattern that comes through the Tx
and the channel from the EDA tool in GetWave(). So, in an effort to
allow our customers to run Init() based simulation and tune them, we
moved our tuning up into Init().
- Ambrish: There's adaptation in GetWave() or no?
- Bob M.: For virtually all of the models we've built, there is no adaptation in
GetWave().
- Walter: Fangyi noted that some of your models do saturation in GetWave().
- Bob M.: Yes, we encourage our customers to run models in GetWave() because the
Rx, in particular, is subject to non-linearities and it's difficult to
provide an IR that adequately characterizes the behavior in the
presence of non-linearities.
- Walter: To summarize, you get the equalization from Init(), but then in
GetWave() you can saturate.
- Bob M.: Yes, the initialization done in Init() is in the presence of all the
Rx non-linearities. So we have a tuning that's valid in GetWave().
- Fangyi: Your GetWave() also has a CDR, doesn't it?
- Bob M.: Yes.
- Again, I want to say that we were not even considering any repeater problems
when we settled on doing models this way.
- [slide 6] Problematic Flows continued
- Time domain flow is problematic if any model has GetWave_Exists False.
- Simulator must create a proxy GetWave() using mathematical operations
on the input and output IRs from Init() (such as de-convolution).
- This is described in the original AMI flow stuff from 5.1.
- Fangyi: That's not true. It's not problematic.
- Walter: Problematic - it depends on the actual combination of models.
- Fangyi: It's an implementation issue, I wouldn't call it problematic.
- [slide 6] continued
- Time domain flow can be very problematic with various combinations of
Init Only and GetWave Only models.
- [slide 7] Ways to fix Init-Only Models
- Model makers should never deliver Init Only models.
- Init Only models can easily be converted into Dual Models.
- One suggestion is to make source code available for this so model
makers can do it to their own models.
- David Banas has public domain source code for a GetWave() based on the
equalization computed during Init().
- Keysight proposal is an alternative
- Adds additional IR outputs.
- Allows the EDA tool to create proxy GetWave() without deconvolution.
- Requires additional functionality in Init() and the EDA tool.
- Is it easier than writing a GetWave() to make an Init Only model
become Dual?
- Michael M: If there were a "statistical" function call, and Init() could go
back to being just about setup and configuration, would you still
say no to a "statistical"-only Model?
- Walter: The EDA tool needs to have a GetWave() or be able to make a proxy
GetWave() to apply the equalization to a waveform.
- Bob M.: One other difference between the EDA tool handling the
GetWave() and the model maker doing it is clock and data
recovery. In the Keysight proposal, you already have the source
bit pattern, all you need to do is correctly align it so you can
apply the DFE based on it to the Rx waveform, without explicit
clock and data recovery. We should consider that.
- Walter: I agree with having an option to have these additional IR outputs.
- I'm just saying we still have to support the legacy models, and I want
to present ways to do it.
- If a model maker has an Init Only model, he could presently add a GetWave()
or in the future add the additional IR outputs.
- Bob M: Agreed.
- [slide 8] Ways to fix Tx GetWave Only Models
- Tx models are almost always LTI and can be well represented by Init().
- Usually no excuse for making a GetWave Only Tx model.
- [slide 9] Ways to fix Rx GetWave Only Models
- Rx terminal model with CDR, etc. Valid for time domain simulations.
- Rx redriver model that is GetWave Only will not be able to influence the
IR passed in to downstream Init() functions.
- [slide 10] Conclusions
- IBIS should clearly recommend Dual models.
- Only exception is terminal Rx models
- No real excuse for Init Only models
- No real excuse for Tx GetWave Only models
- One problematic case, Rx redriver models
- May contain effects that require GetWave() to be captured properly.
- Model maker should still output a best approximation IR from Init so
that downstream models' Init() functions see the upstream effects.
- Walter: I propose that IBIS only document the following flows:
- Statistical flow when all models have Init_Returns_Impulse true.
- Time domain flow when all non-terminal models are Dual, and the terminal Rx
model may be dual or GetWave Only.
- Ambrish: Can we recommend that if it's a GetWave Only model it should still
work in a time domain flow?
- You're saying it worked that way two years ago.
- I understand Bob's model won't work with it.
- Shouldn't we say a GetWave Only model always works in a time domain
simulation? I'm shocked that we're now suggesting it won't.
- Walter: If you add that language to the spec, you effectively deprecate Bob's
model.
- Ambrish: Doesn't Bob's model effectively violate the flows?
- Arpad: It seems we are recommending these two parameters (Init_Returns_Impulse
and GetWave_Exists) are always true.
- That eliminates a whole bunch of the combinations.
- Effectively we are trying to deprecate them, or cause them to be deprecated
over time.
- Walter: We're not removing them.
- We're recommending that they be true.
- I'm proposing we document a limited number of flows.
- Arpad: Why not just bite the bullet and deprecate them?
- Walter: We can say every model should have a GetWave() and deprecate
GetWave_Exists.
- We can then say every model except the terminal Rx should have
Init_Returns_Impulse true.
- Michael M: Perhaps we'd be better off to introduce a new function in a new
version of IBIS and set up cleaner new flows?
- Bob M.: One of the issues is models that adapt in Init() like mine.
- What if we introduce a new reserved parameter "Init_Requires_Impulse"?
- Then the EDA tool can detect incompatibilities between models.
- Ambrish: Why not add adaptation to your GetWave()?
- Bob M.: There are problems with adapting in GetWave(), but they are
surmountable.
- Ambrish: I feel like we are retrofitting the spec for Bob's type of model.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 23 May 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
