Minutes from the 06 June ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 06 June 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]
- Mike L.: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD 166.3 draft 5 Redriver Flow:
- Arpad: Last week I presented a summary of the issues.
- Concluded that we had conflicting requirements for this BIRD.
- We either have to compromise, or go the whole way with Fangyi's proposal
for the additional IRs in Init(), or perhaps call the Init() function
multiple times to create the "self response" and the "cumulative response"
for the series of channels up to that point.
- Walter made a proposal at the end of last week's discussion that we might
document the flow for Init Only (statistical), GetWave Only (time domain),
and all Dual models.
- Leave the rest of the combinations undocumented.
- In my email I described my feeling that this is a mild way of saying that we
only support those 3 cases, and the rest is at your own risk.
- We had discussed this idea earlier when we considered disallowing anything
other than those 3 flow cases. There were objections to that, so I wonder
how people would react to this milder form of the same thing.
- We also have an issue with "8b" in this BIRD draft.
- If any model in the chain doesn't have a GetWave(), then we basically fall
back to using Init() functions only.
- But in a time domain flow we can't guarantee that every model has
Init_Returns_Impulse = true. So 8b could fail. 8b could only be
guaranteed to work if all models had Init_Returns_Impulse = true.
- So, I have the following questions:
- Should we keep 8b and add the statement that all models must have
Init_Returns_Impulse = true, or should we remove 8b completely?
- Should we go with Walter's verbal proposal to only document the confirmed
"no problems" cases?
- I'd like to try to get some answers today so we can move on.
- Mike L.: I believe the proposal is to simply describe the flow in detail for
those three scenarios (All Init Only, All GetWave Only, All Dual).
- It doesn't mean the other scenarios won't work.
- All our tools have been simulating mixed cases, but because it's not defined
fully in the spec there could be some loss of consistency.
- Arpad: Yes, we have been able to simulate, but we uncovered issues with BIRD
166 when we started considering mixed scenarios.
- Primary problem was that some of the deconvolution scenarios are made worse
by BIRD 166.
- So there are some technical challenges with adding BIRD 166.
- The fundamental problem BIRD 166 is trying to address is that the redriver
flow is not working when Init() functions in channel 2 do optimization.
- The second channel Init() functions are not aware of the cumulative channel.
- Ambrish: Before the redriver flow was ever drafted, we had already considered
this scenario in the original single channel flow.
- We thought about it and put it in the spec: (IBIS 6.1 pg. 178)
"Note: The Rx executable model file writer should keep in mind that it is
not guaranteed that the impulse response that is presented to the Rx
AMI_Init function will always include the effects of the Tx filter.
Therefore the Rx AMI_Init function may not be able to perform accurate
optimization under all circumstances. For this reason..."
- I believe we should simply carry over that warning to the redriver flow.
- If your Init() optimizes, be careful because you may not be getting the IR
of the entire channel.
- The precedent has already been set for non-redriver cases.
- Ken: Rx Init() models that don't optimize work in the current flow.
- If there are multiple settings in the Rx, the user/tool can sweep them.
- I don't think it's unreasonable to say automated optimization works with a
GetWave() model but not necessarily with an Init() model.
- Arpad: To rephrase, Ambrish is saying that the flow in the spec is correct,
but it does not support optimization in the downstream Init().
- Ambrish: Yes, but it's the model's issue if it assumes it will get the IR of
the entire upstream channel.
- That's an assumption the model maker is making. It's then between the user
and the model maker.
- Arpad: If we go with your interpretation and extension of this warning
statement, then we don't need BIRD 166 at all.
- Ambrish: Yes, correct.
- Ideally, the user seeing an Init Only Rx model should have gone back to
the model maker and said, "I want an optimizing Rx, so give me a GetWave()
model or something that will work with all the other models in my channel."
- Instead we are trying to modify the specification to make that model work.
- The original concept was that if you want a comprehensive solution use
GetWave(). Use Init() for a quick and dirty approach.
- Bob R.: Summarizing, we might be leaning toward rejecting BIRD 166.
- We are considering the cautionary statement instead.
- We have a more comprehensive proposal from Keysight that may solve it.
- So we could plan to reject BIRD 166 and go toward a clarification statement.
- Ambrish: The beauty of this is it's already in the spec.
- We just have to copy and paste it into the redriver section.
- Arpad: Ambrish, could you take the AR to write that simple editorial BIRD?
- Would it have a chance to make it into 7.0?
- Ambrish: Yes.
- Bob: We could simply reject BIRD 166 and do nothing else.
- Arpad: Can we make a that recommendation for the Open Forum now and put
BIRD 166 to rest?
- Ambrish: Walter, Fangyi, Radek aren't here. We should wait.
- Bob: We don't have to do anything now.
- We can wait for Ambrish's proposal.
- Bob/Mike L.: Let's compromise and table it for now.
- Arpad: I thought we could make a recommendation now.
- Discussions on a technical level seem to say it's not a sufficient solution.
- So this BIRD 166 will probably have to be rejected no matter what.
- But I'm okay with putting it in the tabled topics for now.
- Bob: Motion to table BIRD 166.
- Curtis: Second. [none opposed]
BIRD 158.5
- Arpad: At the last Open Forum meeting we were asked to take this up again.
- What is the current status?
- Bob R.: BIRD 158.5 had been formally submitted for a vote.
- Michael M. then submitted some comments.
- Others also weighed in.
- Radek agreed with some of the suggestions.
- We are waiting for a BIRD 158.6 update from Radek.
- Bob R.: Motion to adjourn.
- Dan: Second.
- Arpad: Thank you all for joining.
AR: Ambrish to prepare a BIRD draft extending the warning about optimization in
Init() to the redriver flow section.
-------------
Next meeting: 13 June 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
