Minutes from the 01 August ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the ATM work archives.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
01-AUG-2017 Bob Ross Teraspeed Labs BIRD 191.1 draft 2 (zip
<http://ibis.org/atm_wip/archive/20170801/bobross/BIRD_191_1_draft_2.zip>)(
docx
<http://ibis.org/atm_wip/archive/20170801/bobross/BIRD%20191.1%20draft%202/BIRD191.1_draft2.docx>
)
01-AUG-2017 Walter Katz SiSoft BIRD 166 - BIRD 190 Summary (zip
<http://ibis.org/atm_wip/archive/20170801/walterkatz/BIRD_166_-_BIRD_190_Summary.zip>
)(pdf
<http://ibis.org/atm_wip/archive/20170801/walterkatz/BIRD%20166%20-%20BIRD%20190%20Summary/BIRD166_BIRD190_Aug_1_2017.pdf>
)
IBIS Macromodel Task Group
Meeting date: 01 August 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:
- Arpad noted that Walter had suggested the BIRD158.6 draft be given higher
priority in this meeting. Arpad said he agreed, and we could discuss it today
despite the fact that Radek had notified us that he could not attend.
-------------
Review of ARs:
- Bob Ross and Arpad to look into any BIRD191.1 interaction with [External ***].
- Done. A draft 2 of BIRD191.1 was mailed to the ATM reflector.
--------------------------
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.
- Randy: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD191.1 draft2:
- Bob R.: [sharing draft2 of BIRD191.1]
- Arpad: We found five instances of "at-pad", all of which were under
[External Model], not [External Circuit].
- Bob R.: We changed the terminology from "at-pad" to "at-buffer terminal".
- The "at-buffer terminal" location is identical to the [Model] buffer
terminals.
- Ambrish: I've always found this portion of the [External Model] text that
you are changing to be confusing.
- The text says, "If at-pad measurements are desired, the A_signal port would
be named in the A_to_D line under port1." It also says, "If internal
measurements are desired, the user-defined signal port would be named in the
A_to_D line under port1."
- Can we add a line to the spec to make it clear that both the A_signal and a
user-defined "internal" node can be included in the Ports line at the same
time? So the multi-lingual model could provide both ports and the model
maker or user could select which one they want to use at [Model] creation
time or run-time.
- Since you're modifying this portion of the spec., perhaps we can add this
clarification as well.
- Arpad: Draft a sentence that you would like to include.
- Bob and I weren't sure we would be touching this section until we reviewed
it this past week.
- Bob R.: I'll take what Ambrish submits and insert it. Then I'll submit that
to the Open Forum as BIRD 191.1.
BIRD158.6:
- Arpad: [sharing 158.6 draft2 and the email thread with his comments]
- We don't need to go over all of my comments. The one comment I'd like to
discuss is the sentence where Radek and I seem to disagree the most:
"Please note that the package data is added to the channel by the user using
user’s own data or using some other vendor’s data."
- First, a minor aesthetic issue with user-using-user's wording.
- More importantly, I think this statement shouldn't be in the specification.
- It is true that old style RLC matrices and other IBIS package models were
so bad that people didn't use them. So users manually added different
package models that they got by some other means.
- But this statement is a description of what is currently the common
practice, not the true intent of the spec.
- The intent of the spec. is to provide packaging information, and now with
BIRD189 we will have the ability to provide good packaging information.
- I would oppose adding this sentence to the spec.
- Walter: I agree. I would throw away that sentence.
- We can come up with wording to explain how Ts4file_Boundary can be used by
the EDA tool to determine if IBIS package model information should also be
included or not.
- BIRD158 was written well before BIRD189.
- Why don't Arpad and I take the AR to reword this to make it compatible with
BIRD189, and then we can see if what we come up with is acceptable to Radek?
- Arpad: Okay.
- Bob R.: Okay. I have two comments:
- We define a "pad" in Ts4file_Boundary, but we don't really show what that
is.
- Is that a physical pad or a pad related to something else?
- It may not relate to BIRD189.
- I'm still puzzled as to why these parameters are all Usage Dep, but not Out.
- Every other Reserved parameter that can be Usage Dep can also Usage Out.
- What is special about these?
- I think they should be Usage Info, Dep, or Out.
- Fangyi/Mike L.: Usage Dep parameters are resolved before Init() or GetWave().
BIRD166.3:
- Walter [sharing his "BIRD166 - BIRD190 Summary" presentation]
- [sharing slide 8 to start]
- There are two redriver flows in the spec., statistical flow and time-domain
flow.
- BIRD166.3 is now limited to the statistical flow.
- In the current IBIS 6.1 redriver statistical flow, the IR input to Rx2
Init() does not include the upstream channel effects.
- With BIRD166.3, the upstream channel IR is convolved with the downstream
channel information prior to calling Rx2 Init().
- Does anyone object to this change to the statistical flow for redrivers?
- Fangyi: I do.
- Walter: Why?
- Fangyi: First, with this change the IR matrix grows exponentially when you
have more redrivers in the channel. Without the self IR of each
section, one can't form IRs of all the possible crosstalk paths by
combining the self IRs of different sections. So IRs of all cross-
talk paths must be included in the IR matrix, causing the matrix size
to grow exponentially with the number of channels and redrivers in
the system.
- Second, when you have a feedback loop, this method won't work because you
can call Init() only once.
- Walter: What feedback loop are you talking about?
- Fangyi: Any time you have a network you can always have a feedback loop.
- Arpad: How is it related to the redrivers? Are you saying a chain of
redrivers goes back to the original driver?
- Fangyi: The signal can go through a feedback loop and experience the
equalization of a redriver a second time. It doesn't need a redriver
ring to form a feedback loop. In general, a feedback loop can exist
in any network that has multiple channels and multiple redrivers.
- Mike L.: Are you saying this would be handled correctly in the current spec.?
- Fangyi: Yes. In the current spec you have the self IR of each section of
the channel.
- With the self IR of each section, the tool can represent any path it wants
using the individual self IRs.
- With BIRD166.3 you only have the cumulative IR at each redriver, and you
don't have the self IRs of the individual sections.
- So a loop can't be handled. You can only call Init() once, so you
can't have a signal experience a redriver twice.
- Crosstalk is a problem without the self IRs. If the tool doesn't have
the self IRs, then it has to put the crosstalk IRs that couple in at each
redriver into all the subsequent redrivers' IR matrices. So the IR matrix
grows as you go down the chain.
- Ambrish: This (BIRD166.3) will make the time domain Init() flow different from
the statistical Init() flow.
- Walter: I think the same change belongs in the time domain flow, but I took
the time domain flow change out of BIRD166.3 because you objected.
- [sharing "Alternative Redriver Time Domain Flow" slide 10]
- Current time domain flow has this step 6.
- Your BIRD190 would add this new note. I have no problem with this note. It
identifies and highlights the problem with the current flow.
- I would like to add this alternative step 6 (that says the convolution
may be done prior to calling Rx2 Init()).
- Your option relies on running the Rx2 Init() in manual configuration mode.
- Both options can get the same answer eventually, but my proposed flow would
arrive at it much more quickly.
- Ambrish: The main assumption in this is that you're modeling optimization in
Init().
- That's a huge assumption (for time domain flow) about what all the upstream
models are doing (Init_Returns_Impulse must be true for all of them), and
you can't really mandate that in the spec.
- Walter: The redriver section already refers back to the single channel flow,
where your optimization warning already exists.
- The user will know if all of the models have Init_Returns_Impulse=true, and
in that case all the information would be available to Rx2 Init() to
optimize itself (with BIRD166.3 flow).
- Walter: I think we should drop this whole discussion and table BIRD166 and
BIRD190 and not consider them for IBIS 7.0.
- If Ambrish will allow BIRD190 to be tabled, I will table BIRD166.3 after
introducing it at the Open Forum.
- We table both and let the market decide what flow is correct.
- [sharing "Bob Miller's Comments" slide 5].
- Bob Miller is a model maker and finds it "hugely disappointing" that BIRD190
would codify this limitation.
- Four years ago SiSoft published the problem with the existing 6.1 flow, and
we documented our own flow.
- Ambrish: The main problem in what Bob M. is asking for is that he's doing
optimization in Init() and has that huge assumption about what
upstream models are doing.
- Walter: That warning about optimizing in Init() is true for all Rx models.
- Ambrish: What Bob wants, he could get by having the user enter preset tap
coefficients manually.
- Walter: I know you believe in adaptation in GetWave().
- If you look at modern Rx models, e.g. 802.3bj, they expect 14 tap DFEs.
- They expect hardware to adapt in perhaps 1 second. At 25GHz, that gives
them 25e9 UIs to work with.
- Typically GetWave() simulations in EDA tools are on the order of 1e6 UI per
minute. You can take 25,000 minutes to do adaptation.
- Many companies are committed to a statistical flow.
- Michael Mirmak has said Intel is committed to a statistical flow.
- Other IC vendors are committed to a statistical flow.
- Ambrish: I have models from Intel that provide a GetWave().
- Walter: They may generate models with GetWave(), but internally they are
committed to supporting statistical flow.
- Ambrish: How do you expect the flow to work if it assumes all models have
Init_Returns_Impulse=true?
- Walter: When we have a GetWave() only model, we create a proxy Init().
- When we have an Init() only model, we make a proxy GetWave().
- We presented Mike Steinberger's paper on this subject at DesignCon.
- We would prefer all models were Dual models, and many of our customers make
their vendors provide Dual models.
- We think it's silly to give out an Init only model. If you have an Init
only model you can easily generate a GetWave() function. David Banas
provides open source code to do it.
- Optimizing a 14 tap DFE in Init() is trivial. If you have AGC and CTLE it
adds complications, but we still have ways to do it.
- Ambrish: We can't force model makers to produce dual models.
- Fangyi: We can't put something in the spec. that is mathematically wrong.
Your change would break the time domain flow.
- Arpad: We have been round and round on this for months.
- I don't think we are getting any closer to an agreement.
- Motion to table BIRD190 and BIRD166.
- Walter: Second. [none opposed]
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Mike L. to post BIRD 191.1 draft 2 to the ATM archives.
AR: Ambrish to draft a proposed sentence to add to the [External Model] section
as part of BIRD191.1 and send it to Bob R.
AR: Bob R. to create BIRD 191.1 draft 3 with Ambrish's sentence and submit it
to the Open Forum as BIRD191.1.
AR: Walter and Arpad to modify the current BIRD158.6 draft to make it compatible
with BIRD189.
AR: Mike L. to post Walter's "BIRD166 - BIRD190 Summary" to the ATM archives.
-------------
Next meeting: 08 August 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
