Minutes from the 10 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 10 July 2018
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
Radek Biernacki
* Ming Yan
Stephen Slater
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Walter to send an email to ATM announcing the DDR thresholds discussion topic.
- Done.
- Mike L. to update the IBIS 6.1 known issues list to include adding Value
entries to the PAM4 thresholds Usage Out example on pg. 235-236.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the June 26
meeting. Mike L. moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
Upgrading the input thresholds/measurement info to include eye diagram specs:
- Walter reviewed the discussion of the topic, which was untabled and discussed
at the previous ATM meeting and the Open Forum meeting on June 29th (also see
Walter's "DDR4_BIRD_Requirements.pptx" posted to the IBIS Open Forum Meeting
Minutes page 2018-06-29).
Walter noted that slew rate rules in DDR4 or DDR5, for example, can be
relatively complicated not just a few numbers. It could be very useful to put
them in an "include" file instead of repeating them in every model. One basic
IBIS Model (I/V tables, etc.) might work for many speed grades, but each speed
grade might have different slew rate rules. It would be useful to avoid
copying the same Model over and over just to add different speed grade
information.
Arpad noted that another possible solution was to have something scoped at the
[Component] level instead of using include files. Walter said we could debate
the optimal solution later, but first we had to get broad agreement that this
was worth pursuing. Arpad agreed it was worth pursuing.
Bob asked how the floating Vref definition would be defined in IBIS. Walter
noted that the Vref is typically determined by the simulation waveform itself.
You create an eye diagram and pick a Vref that maximizes the mask area.
Ming asked if something like speed grade selection could be handled with a
Model_Selector. Walter noted that Model_Selectors typically already contain
lots of Models for different ODT values. Extending that technique to cover
speed grade, etc., would lead to further multiplication of the combinations.
Arpad said the proposal to add this capability makes sense. Parts are made
and operate in this way, so we should be able to model it. Bob noted that he
was in favor of it too but hoped it didn't get too complicated. Bob noted
that he was worried about having to constantly upgrade the IBIS spec to keep
up with new standards. Randy noted that what's nice about this proposal is
that EDA vendors can implement all the various parameters, but it's nice if
the information is in the model so the model maker can tie sets of parameters
to a given model. This makes it clear to the user which speed grades, etc.,
a model can support, instead of them having to rely on info and readme files.
Arpad noted that earlier discussions of proposals similar to this had leaned
toward referencing external specs/sources not defining our own parameters for
everything. This concept had been relevant to the BIRD147.6 (Back-channel
support) discussions, for example. Walter, Bob and Arpad agreed in
principle
with this approach.
Suggested outline included:
1. A new keyword to provide the specification name (perhaps IBIS would
document reserved specification names).
2. A list of the Subparam names that applied for particular specifications.
3. Allowing the user to select speed grade, etc. (various Subparams)
Bob noted that he would strongly suggest we adopt the formal specification
names for any external specifications regardless of how long and unwieldy
their official names might be.
Arpad asked everyone to take an AR to come back with feedback at the next
meeting.
Clock forwarding in IBIS-AMI:
- Walter noted that he had discussed this topic with Steve Parker of Global
Foundaries. The application was similar to DDR5 in that it had a clock
forwarding interface. Walter noted that some SERDES specs (PCIe Gen3) had
also supported clock forwarding interfaces, though differential not single
ended. Walter noted that the conclusion he had come to in his discussion
with Steve was that if one wanted AMI modeling to support clock forwarding
we would require a new BIRD. We would need a new mechanism for passing the
clock ticks along with the data to the Rx. Walter said he advised Steve that
he could either draft a BIRD himself or make a formal request to IBIS for such
an enhancement.
Arpad noted that the tabled topics list contained a topic related to various
enhancements that might be necessary for AMI to extend to DDR5. Walter agreed
and noted the DDR4/DDR5 parameters topic, clock forwarding, and asymmetric
rise fall times. Arpad asked if we should untable the topic. Mike L. moved
to untable the "Single Ended Applications of AMI modeling" topic for the next
meeting. Bob seconded. There were no objections. Arpad said he would fold
this "clock forwarding" topic into the "Single Ended Applications" topic.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 17 July 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
