Minutes from the 18 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 18 July 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:
- Arpad to email his BIRD158.6 draft 1 comments to the ATM reflector.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Ambrish: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Walter's 3 proposed motions (from an email regarding BIRD190 & BIRD166):
*******
Motion 1:
Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Init-Only
models:
1. IBIS 6.1 Redriver Flow gives the wrong answer.
2. BIRD 166 gives the right answer.
Motion 2:
Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Dual
models:
1. IBIS 6.1 Redriver Flow may give the wrong time domain answer.
2. BIRD 166 gives the right answer
Motion 3:
Do you agree that a redriver channel with Tx1, Rx1, Tx2 and Rx2 being Dual
models:
1. IBIS 6.1 Redriver Flow gives the wrong statistical answer.
2. BIRD 166 gives the right answer
********
- Arpad: I'm confused by these "motions" in the form of questions.
- Are these just discussion proposals/questions?
- Walter: The intent was to establish who believes these statements are true.
- I believe IBIS 6.1 is wrong under these 3 circumstances, and BIRD 166 gets
the correct results under these 3 circumstances.
- I believe BIRD190 reinforces an incorrect flow.
- If we go to the Open Forum and Ambrish defends BIRD 190, I will explain that
it's a bad idea.
- Bob R: I think it's fair to discuss each of the technical points without
prejudice, to see if there is any common agreement.
- Arpad: Okay, we will start with discussion here, and we can make any motions
later if we need them.
- Ambrish: BIRD166 affects statistical and time domain flows, correct?
- Walter: Yes.
- Ambrish: Do you agree that the 6.1 time domain flow is not broken if there
is no optimization in Init()?
- Walter: Yes, if all the models have GetWave() and there is no optimization in
Init().
- Ambrish: That is the reason that we have the note (warning about optimizing
in Init()) in the spec.
- Fangyi: Regarding motion 2, number 2: When the redriver has non-linearities
and internal noise your BIRD166 will artificially inflate them.
- Walter: No, motion 2 says all models are Dual, so they all have GetWave().
- Fangyi: Then we need to add an additional motion for mixed Dual mode and
Init Only models.
- Walter: I think your counter argument (see ATM minutes and work archive
May 9, 2017 for counter example) was specious.
- In your example you treated the Rx2 as having a linear part and an additive
DFE part. It's technically correct. However, if the input waveform has the
correct amplitude, then you can treat the DFE as multiplicative not
additive. It's a different way to do the deconvolution to get the
equalization of the Rx2, as long as the amplitudes are reasonable.
- Fangyi: That's not a valid issue.
- Walter: That same issue occurs for the single channel case if the Rx is
Init Only and the Tx has a GetWave().
- But we know those mixed mode cases can be problematic, and there may be
other flows that handle them.
- I want to concentrate on three basic cases I described (in the motions).
- case 1: All Init Only models - Are statistical simulations correct with
the current flow?
- Arpad: With or without optimization in Init()?
- Walter: There are two reasons it's wrong.
- First, it's obviously incorrect if there's optimization in Rx2 Init(),
because Rx2 doesn't get the upstream effects in its input IR.
- IBIS 6.1 guarantees that the input IR to Rx2 will not be the complete IR
(the upstream information will not be included), so the results will not be
correct.
- Second, even if there's no optimization in Rx2 Init(), if Rx2 has DFE then
when you convolve the output of Rx2 Init() with the output of Rx1 Init() you
end up scaling the linear and DFE portions of the Rx2 equalization. So you
get the wrong answer with the current flow.
- Time domain simulation when all the models are Init Only is broken for the
same two reasons.
- Arpad: If Rx1 had a DFE then even your BIRD166 would still have a problem?
- Walter: We are talking about redrivers not retimers. DFE requires a CDR and
other things a redriver won't have.
- Ambrish: You would change the flow for this one-in-a-trillion case where
all four models are Init() only and you want to do a time domain
simulation?
- Walter: If you use BIRD 166, and use the IR output of Rx2, then you will get
the right answer for statistical or time domain flows. IBIS 6.1 will
give you the wrong answer for both.
- There are companies that only do Init() models.
- Fangyi: The redriver simulation is all about non-linearities in the redriver
device, otherwise we wouldn't have needed the redriver extensions to
AMI. A redriver will have GetWave(), and most have two modes, a
linear mode and a limiting mode.
- Walter: Yes, statistical is not a complete solution if there are
non-linearities. I'm not disagreeing.
- There are problems with mixed Init Only, GetWave Only, Dual model
simulations.
- But we ought to get it right if all four of the models are Init Only.
- Ambrish: Redriver is already a special case of AMI flow.
- The spec. goes into great detail about a single Tx to Rx channel.
- There are already exceptions and warnings in the spec.
- You're modifying the flow for a special case.
- Walter: In a simple channel Init Only flow, the Rx has all the upstream
equalization.
- With a redriver I'm simply saying the terminal Rx (Rx2) needs all of the
equalization for everything upstream.
- Ambrish: My problem is that you're taking a one-in-a-million case and trying
to drive the conversation with it.
- Fangyi: I agree with that.
- Walter: The all dual model case is not as rare.
- Walter: Why do you object to having Rx2 Init() get the right input IR if all
the models have GetWave() anyway (all dual models)?
- Ambrish: Because as the spec is written, the Rx2 IR does not matter at all
if you have a GetWave().
- Fangyi: Also because if you have the combined IR you introduce more problems.
- Ambrish: You're trying to circumvent the warning note in the spec.
- Walter: No. The note in the spec is a valid note to all Rx model writers.
- It says that the Rx model can't be assured that the IR it gets will be
complete. Therefore, it can't always rely on automatic optimization and
needs to provide an override mechanism. That is true in all cases.
- What I'm trying to do is give the Rx2 Init() in a redriver simulation the
best IR it can get.
- IBIS 6.1 guarantees that Rx2 will not get the complete equalization it needs
under any circumstances (because the redriver flow says you convolve with
the output of Rx1 Init() after Rx2 Init() is called instead of before).
- BIRD 166 corrects that.
- Ambrish: The original warning says IR "may" not include all the effects.
- The EDA tool could already do something different if it wanted to.
- Arpad: I need to comment on that point.
- We do say somewhere in the spec that these reference flows need not be
implemented exactly, but that whatever method is implemented should generate
identical results.
- Here the spec clearly says to combine the output of Rx1 Init() with the
output of Rx2 Init(). If a tool changes this order the results would be
different and you're not spec compliant.
- Walter: I had proposed adding a line to BIRD 190 that would have made it
acceptable to me.
- I wanted to add a line saying the EDA tool could choose to combine the
upstream channel with the Input to Rx2.
- Are you saying you now agree with that Ambrish?
- Ambrish: I would like to add an additional discussion point to this list.
- Do people think any optimization should happen in Init() or only GetWave()?
- If the original intent of the specification was that optimization can happen
in Init() then why would the note be there?
- Walter: Going back 9 years ago, Kumar wanted to do optimization in the Tx so
it could choose coefficients optimized for the channel to open the
eye at the Rx input pad.
- That's why the input to the Tx or Rx Init() is the channel IR itself.
- From day one it was expected that the Init() functions would optimize
themselves.
- Ambrish: That was for getting the tap weights in the Tx if you didn't want
to bother with a GetWave() for the Tx.
- If you have a GetWave() in the Tx then you can ignore the Init().
- If you've done the hard work of implementing a GetWave(), why would you want
to use the Init()?
- Walter: Question: How can Tx GetWave() optimize itself?
- Ambrish: Tx GetWave() just implements the tap coefficients.
- Walter: How does GetWave() get the tap coefficients?
- It gets them from the Init(), either as user input or as values the Init()
selected based on the IR to optimize the channel and open the eye at the
Rx input.
- How could Tx GetWave() optimize itself dynamically (its input waveform is
just the "digital" stimulus waveform)? It can't.
- Ambrish: Not true, you can have pattern dependent GetWave() that optimizes in
the Tx.
- Walter: I think we are not going to get an agreement on this.
- I think we have documented these points of disagreement.
- If people want to pursue BIRD190 in the OF, I will present this discussion
and argue against it.
- Ambrish: BIRD190 is just a clarification.
- Walter: By adding BIRD190 you are reaffirming that we guarantee Rx2 won't have
the complete IR.
- Radek: I think BIRD190 would be perfectly fine if we change the word "note" to
"warning." That may be all we need.
- Ambrish: I'm fine with that.
- Walter: If BIRD190 just said, "warning Rx2 Init() does not necessarily get the
full IR," that would be OK.
- But I don't want to reaffirm the problem in IBIS 6.1 with Rx2 Init().
- I'm okay with doing nothing at all if we can't come to agreement.
- Arpad: A few meetings back we had a straw poll.
- The results of that were that we would do neither BIRD166 or BIRD190.
- We were going to consider further developing Fangyi's proposal.
- Where do we stand on that?
- Ambrish: I think that poll was flawed because BIRD190 was considered to apply
to statistical flow as well, and I don't think it does.
- We have major disagreements because Walter says the current spec doesn't
work.
- We can't guarantee all of the special cases will work.
- Walter: BIRD190 is tabled in the Open Forum. I guess that will continue.
- Ambrish: I will have a motion on BIRD190 for this meeting next week.
BIRD158.6:
- Radek: I sent out a response to Arpad's comments just before this meeting.
- I'm not available for next week's meeting, but we can work on this via
email and discuss it in the following week's meeting.
- Arpad: I encourage everyone to review that email discussion.
BIRD191:
- Bob R.: I'm thinking of drafting a BIRD191.1.
- The gist of it is a one sentence statement that "Die" shall be considered
the buffer location.
- Walter/Arpad: Send it to the ATM reflector and we will review it.
- Bob R.: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 25 July 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
