Minutes from the 05 September ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 05 September 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:
- Curtis noted that EDICON in Boston runs from September 11 until September 13.
Curtis and Mike L. said they would be at EDICON and unavailable for the next
ATM meeting. Arpad asked if we should cancel the ATM meeting on September 12.
Curtis and Mike L. were the only ones unable to attend, so the group decided
to hold the September 12 meeting as scheduled. Arpad noted that he would need
a volunteer to take the minutes at that meeting.
- Arpad noted that Michael M. had sent a private email regarding samples/bit
issues with AMI models.
- Michael M.: We occasionally run into issues with poor documentation regarding
an AMI model's samples/bit requirements.
- I'm wondering if we could have a Reserved parameter (Usage Info) to convey
any samples/bit requirements.
- This might help with model-to-model compatibility and tool-to-tool
agreement.
- Walter: We had long discussions about samples/bit years ago.
- We had proposed just such a parameter so the model could report any
samples/bit constraints.
- That BIRD was rejected.
- EDA tools could easily implement a "torque converter" to translate between
models with different samples/bit requirements.
- The BIRD was not approved because it's just as trivial for the model to
implement the torque converter itself.
- That's just a review of the status and history of this topic.
- Arpad: At the time, the decision was that all models should work at all sample
rates... famous last words.
- Walter: That decision was to make it easy for tool vendors.
- But there are currently models out there that only work at certain
samples/bit.
- There's currently no way to convey that information to the tool.
- Arpad: We've seen some models that have different samples/bit requirements at
different rates.
- We often see an inverse relationship - at lower bit rates the model needs
more samples/bit.
- It might be useful to have different bit rate ranges that have an associated
samples/bit.
- Walter: No, it should all be Nyquist related.
- If you're at 10GHz, all you should really need in order to simulate is 8 or
16 samples per bit, because above that you're so far above the Nyquist
frequency it doesn't matter.
- So models shouldn't behave that way, but some people think that way.
- Mike L.: Looking at some model documentation, some models do express a
requirement to use a given samples/bit at a certain data rate.
- Those seem to be looking to control or enforce some max sample interval.
- That does suggest something internal to the model that has some fixed time
constant.
- Other models are like Walter described and really just seem hard coded and
designed to work at one particular samples/bit.
- Right now the IBIS spec just says that models should work at any
samples/bit.
- How about 1 sample per bit? ;-)
- Is it okay if a tool or model only wants to work in powers of two?
- Arpad: Just last week I ran into a model that was simulating correctly (no
crashes, errors, etc.), but below 8Gbps at 32 samples per bit the
eye was closed and at 64 samples per bit the eye was wide open.
- The model obviously had some sample related dependency, but how would the
user know?
- Mike L.: I test a lot of models. Unfortunately, many show different, though
reasonable looking, results with different samples/bit.
- Michael M.: As Walter noted, it is possible for model makers to make their
models work for all (reasonable) samples/bit, but there are lots
of models out there that don't.
- Perhaps we could add a parameter that would allow the model maker to report
that requirement instead of having to rewrite their model.
- I will think about what to propose.
- Arpad and Walter noted that the Interconnect Task Group is again discussing
whether and how node 0 should be available for referencing. They asked people
to follow the Interconnect Task Group emails if interested.
-------------
Review of ARs:
- Radek to send out an updated BIRD 158.6 draft 5 as discussed.
- Not yet done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Minutes from the previous meeting had not been posted in time for review.
-------------
New Discussion:
BIRD158.6:
- Arpad: We did not get the updated document from Radek.
- Discussion deferred.
C_comp Improvements:
- Arpad: Randy is not here either. Walter, do you have any updates on this?
- Walter: I sent an email to Arpad, Bob R., and Randy.
- End result is I'd like to make an I/O device have I/V curves driving mode
that are entirely independent of the I/V curves for receiving mode.
- I think that makes a lot of sense if the protection circuits could be
different for driving mode and receiving mode. I've been told that this is
physically possible, and this is currently a limitation of IBIS.
- I think having separate I/V tables for driving and receiving mode makes it a
lot simpler.
- Arpad: Why are existing Submodels not sufficient for you to have different
currents under different modes?
- Walter: Submodels involve adding currents.
- I want a set of fully independent curves.
- Right now the way you'd measure an I/O is you turn it off and generate your
I/V curves for the clamps. Then you turn it on and measure your Pullup and
Pulldown curves. But then you have to subtract the clamp curves from the
Pullup and Pulldown curves. When the clamps are actually different between
driving and receiving modes then this gets messy.
- Arpad: When you talk about independent curves for driving and receiving mode,
are you talking about statically choosing a mode before the simulation
or are you also interested in dynamically switching like Randy and I
presented at DesignCon?
- Walter: No, I'm not interested in bus turnaround. That's a whole new bag of
worms with too many complications for IBIS to capture.
- Bob R.: The question is whether to support independent clamp tables vs. the
existing Submodel mechanism. People use Submodel now. Though it does
involve de-embedding some currents to make the model, it's a workable
solution.
- I don't like separate I/V tables as a solution.
- Walter: We need to wait for Randy and to discuss specific examples.
- Arpad: Yes, we need a firm proposal to discuss.
New BIRDs from Editorial Task Group: (Item 9)
- Arpad: Do we have an update on this from Bob R. and Radek?
- Bob R.: We haven't done anything with it lately.
- It should stay on the agenda.
- We decided to postpone this work until 7.1.
- Walter: Motion to table item 9.
- Bob R.: Second.
- Arpad: Anyone opposed? [no one opposed - Item tabled]
- Curtis: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 12 September 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
