Minutes from the 20 June ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 20 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:
- Ambrish to submit his proposal as BIRD 190.
- Done.
--------------------------
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 190:
- Arpad: Two weeks ago we tabled BIRD 166.
- Walter is back today so we could untable it if we want to discuss it.
- I'd like to discuss BIRD 166 vs. BIRD 190 and try to come up with a
recommendation to the Open Forum on which way to proceed.
- Walter had sent an email regarding BIRD 190, so we could discuss that.
- No one leaves the meeting until we make a decision ;-)
- Walter: I think BIRD 190, with the changes I proposed, would be acceptable.
- [reviewing changes to BIRD 190 proposed in the email]
- Instances of "Rx" changed to "Rx2" (editorial).
- Removed "always default to valid values or"
- The important thing is to have a way to accept user defined coefficients
and turn off optimization. The phrase "always default to valid values"
didn't add anything.
- Removed "to ensure successful simulations"
- I'm not sure what "successful simulation" means, and I question whether
this would ensure accurate simulation results.
- Arpad: I think it was trying to say the model should work without having to
run its optimizer first, but I understand your point.
- Bob M.: The problem is defining "successful simulations." You might end up
with a tightly closed eye using some default "valid values."
- Walter: [continuing list of changes to BIRD 190]
- Add the following sentence at the end:
- "An EDA tool may elect to include the upstream channel characteristics
and/or equalization effects in the input to the downstream Rx2 AMI_Init
function instead of including them in the output of the Rx2 AMI_Init
function."
- With those changes I think it satisfies Ambrish's intent and I would be
able to support it.
- Arpad: That last sentence conflicts with the "does not include" sentence
earlier in the text. If the first sentence says it "does not include"
upstream effects, then the last sentence shouldn't say that it may
include them in some cases.
- Walter: That first "does not include" sentence describes the prescribed
flow.
- The last sentence says the EDA tool need not follow the prescribed flow.
- Arpad: I understand that.
- But we have a flow in the spec, and then that last sentence tells the EDA
tools they don't have to follow it.
- Walter: The statistical redriver flow in the spec, even if the Rx2 does not
optimize itself, will give the wrong answer.
- I'm only talking about statistical flow, so all models must have
Init_Returns_Impulse = true.
- Ambrish: Optimization is the problem.
- Walter: No, even if the Rx2 doesn't optimize itself, the current statistical
flow gives the wrong answer.
- Fangyi/Ambrish: I disagree.
- Arpad: Can you explain that Walter?
- In your email you mentioned that DFE could be approximated in the Init()
function. If it's done there, doesn't it become an LTI approximation and
the summation doesn't apply anymore?
- Walter: I will give a simple example to illustrate.
- Suppose the Rx2 has a DFE, and consider the following example:
- 1. Tx1 is an ideal Tx. No equalization, it doesn't do anything.
- 2. Upstream channel is an ideal channel (Its IR is a Dirac delta, i.e.
unit IR (area = 1)).
- 3. Rx1 simply has a gain of 2.
- 4. Output of Rx1 is a Dirac delta with an area of two.
- 5. Tx2 is also an ideal Tx with no equalization.
- 6. Downstream channel is also an ideal channel (Its IR is a Dirac delta).
- 7. Rx2 has a DFE tap with a value of -.1.
- 8. With the 6.1 flow, the output of Rx2 will be a Dirac delta at zero
with an area of 1 and another at 1 UI with an area of -.1. Then you
go ahead and convolve with the output of Rx1, which doubles everything.
- 9. With the BIRD 166 flow, you get a Dirac delta at zero with an area of 2
and another 1 UI with an area of -.1 (not the -.2 you would get from
the
6.1 flow).
- So by scaling the output of Rx2 Init() by 2, instead of scaling the input
by 2, you get two very different answers. Only BIRD 166 gives you the
right answer.
- That's a plain vanilla scenario that shows the IBIS 6.1 statistical
redriver flow is incorrect.
- Fangyi: It's up to the model to normalize the slicer output. That shouldn't
scale with the input.
- Bob M.: But when you do the scaling (convolution with Rx1 output) after the
fact it ends up looking like it does.
- Fangyi/Ambrish: You have GetWave().
- Walter: No, I'm talking strictly about statistical flow.
- Arpad: How do we proceed? Can we discuss Walter's revisions to BIRD 190?
- Fangyi: I think Walter's last sentence just reintroduces BIRD 166 again.
- Ambrish: That additional sentence in the note will not change the official
flow, the results would still be different. The EDA tool could
always do something outside the recognized flow in the spec anyway.
- Bob M.: I understand the objection to the way Walter's sentence is basically
trying to slide BIRD 166 in through the back door.
- But that sentence is trying to accomplish something.
- The emphasis of the basic BIRD 190 statement is telling model makers and
users of statistical models that if you are doing a redriver simulation you
get no support from us.
- If the sentence Walter is trying to add isn't accepted in some form, then
I'd rather just see BIRD 190 tabled as well, because all it's doing is
enforcing a statement that if you want to write Init() models you're out
of luck.
- Arpad: BIRD 190 wasn't intended to solve any technical problems, just to
alert the user/reader to an existing limitation in the spec.
- Adding Walter's sentence goes back to trying to solve a technical problem.
- Bob M.: But Walter's non-adaptation example showed the existing flow is wrong.
- Arpad: The problem was we couldn't agree on a technical solution to go into
IBIS 7.0.
- If we had a good technical solution, for example a variant of Fangyi's
proposal, then I would be all for it.
- But I think we all agree we don't have enough time to do that before 7.0.
- Walter: We all have to recognize and accept that IBIS 6.1 gives the wrong
answer.
- I think anything that suggests or reinforces a flow that is almost
guaranteed to give the wrong answer is unacceptable.
- I recommend BIRD 190 not be approved without the added sentence.
- I don't mind tabling BIRD 190 along with BIRD 166 and ending this discussion
for IBIS 7.0.
- I think we've fully documented the flow issues (minutes, emails, etc.)
- We could write a white-paper or known issues document, to which we could
all contribute, instead of modifying the spec right now.
- If we want to change the flow or add that last sentence, I'm okay with that.
- Discussion: Walter proposed a straw man poll with several options for how to
proceed including tabling both BIRD 166 and BIRD 190, adopting BIRD 190, or
adopting BIRD 190 with Walter's additional sentence. Bob R. and Radek
suggested we also include Fangyi's proposal amongst the options. Radek noted
that with AMI versioning Fangyi's proposal would effectively address the
legacy model issue because they could be upgraded to the newer version if
necessary. Fangyi confirmed his willingness to work on an official BIRD
draft of his proposal. Bob R. said we could see if it could make it into
IBIS 7.0. The final straw poll choices were:
1. Table BIRD 166 and BIRD 190.
2. Adopt BIRD 190 as submitted to the Open Forum.
3. Adopt BIRD 190 with Walter's modifications.
4. Consider going forward with Fangyi's proposal (perhaps for 7.0).
Organizations voted for the options as follows:
ANSYS: 1, 4
Broadcom: 1, 4
Cadence: 2, 4
Intel: 1
Keysight: 2, 4
Mentor: 1, 2, 4
Micron: Abstain
SiSoft: 1
Teraspeed: 1, 4
- Walter: I think consensus is that we should table both BIRD 166 and BIRD 190.
- This group also proceeds with Fangyi's proposal.
- I think we should also create a known-issues list for the current spec.
- Ambrish: Can we file a bug report?
- Arpad/Radek: We don't have bug reports against the spec itself.
- Radek: A "known issues" idea is okay.
- I'm not sure we have anything like that on the website currently.
- We have documentation via meeting minutes, working directories, etc., but
they might not be that easily accessible to new readers or visitors.
- Arpad: Anything modifying the spec needs a BIRD.
- But perhaps we could start a new known issues document.
- Bob R.: Main conclusion is that after we introduce BIRD 190 we should
immediately table it in the Open Forum.
- We can table BIRD 190 here in the ATM next time.
- Radek: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 27 June 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
