Minutes from the 26 June ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 26 June 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:
- The meeting scheduled for July 3rd is cancelled (see below).
-------------
Review of ARs:
- Michael M. to submit his "Enabling [Rgnd] and [Rpower] for Input Model_type"
v2 to the Open Forum as a BIRD.
- Done, BIRD195.
- Arpad to send an email to the Open Forum noting that the ATM had voted to
submit BIRD195.
- 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 19
meeting. Michael M. moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
Meeting on July 3rd:
- Arpad asked if we should cancel the meeting. Walter moved to cancel the
meeting scheduled for July 3rd. Michael M. seconded. There were no
objections.
Enhanced C_comp Modeling:
- Randy reviewed the latest version of his proposal (emailed to ATM on June 12).
He noted that he had not received any new feedback. Randy noted that the text
for [C_comp_Corner]'s Usage Rules had been modified to align with the changes
BIRD191.2 made to the Si_location and Timing_location descriptions. BIRD191.2
introduced clarifications to these locations that came out of BIRD189. This
proposal incorporates those changes, and notes that:
The "Die" location refers to the Buffer_I* terminal(s) of a [C_Comp_Model]
if [C_comp_Model] is present and includes Buffer_I* terminal(s).
Randy noted minor changes to the description of series elements in
[C_comp_Model]. The changes clarify that a series element could exist between
the buffer I/O terminal and the "active buffer elements", to explain the
location of on-die interconnect at the "buffer level." Randy noted, however,
that he was leaning toward removing this ability to add a series element
between the active buffer element (I/V location) and the buffer I/O terminal.
Referring to Figure X., he noted that we might only want to allow a series
element between the buffer I/O terminal and the input. It would simplify this
BIRD, and anything more complicated might not be necessary since on-die
interconnect is available with BIRD189. Bob noted that this would be a
restriction - there would be no C_comp_Model with a series element for
anything other than an input or terminator or the input path of an I/O.
Randy noted that Number_of_terminals shall always be 2 or greater, because
a reference terminal is always provided. The text states that the IBIS-ISS
subcircuit terminals shall not contain an ideal reference node (SPICE node 0,
etc.). Randy noted that the preference is that node 0 not appear anywhere in
the subcircuit. But in keeping with BIRD189's decisions, having node 0
inside
the subcircuit is not explicitly prohibited.
Upgrading the input thresholds/measurement info to include eye diagram specs:
- Walter moved to untable this topic. Michael M. seconded. There were no
objections. Walter introduced the topic and briefly reviewed some information
on the web including a Micron DDR4 overview. Walter suggested we should have
a BIRD to enhance IBIS and add JEDEC DDR3/4/5 measurement metrics, and that we
could decide which metrics to include. He noted that most EDA vendors have
some way of addressing these metrics, and we could standardize.
Arpad noted that we had discussed this previously and usually decided to just
point to some outside sources instead of inventing our own syntax and building
it into IBIS. Michael M. noted that we can't rely on having a standards
organization for every interface. He noted that in the past we had stumbled
when one model might be used for multiple interfaces. If, for example, the
thresholds associated with one type of interface were built into a [Model],
then that [Model] can't be used for other interfaces. Walter noted that for
SERDES one buffer Model could be for various standards. DDR4 and DDR5 are
different in that respect. If you're a compliant DDR4 device at a particular
speed grade, then there is an associated value for VdIVW for that speed grade.
So a tool could have the logic to pick that value. But it would be nice to
have those fundamental values as IBIS params. For example, VdIVW could be a
parameter, and it could be relative to some vref.
Randy noted that the issues Walter was describing led to some modeling
inefficiency. For example, thresholds defined per bit rate. We need to
define those thresholds differently for each frequency range. We might have
a DQ model good for 1600MBps up to 3200MBps, but if you can only specify one
threshold value per model then it becomes very inefficient. You have to copy
and paste the same model over and over just to change thresholds. Michael M.
asked if this could be handled with something like a Threshold_Selector
(similar to Model_Selector). Randy said you'd need a way to indicate the
frequency range.
Walter noted that SiSoft had implemented similar things using an "include"
file containing all the DDR4 thresholds in one file, for example. He said
SiSoft would be willing to share the methods they were using. Arpad noted
that another option might be to use a parameterized [External Model] that
could pass back values based on an input parameter.
Walter said the bottom line is whether everyone, particularly the EDA tool
vendors, agree this is something worth pursuing. Arpad asked if Walter were
going to draft a proposal. Walter said he first wanted to make sure we had
consensus that this was worth pursuing. Walter took the AR to send an email
to ATM introducing this topic and noting it will be discussed next meeting.
- Walter: Motion to adjourn.
- Bob: Second.
- Arpad: Thank you all for joining.
AR: Walter to send an email to ATM announcing the DDR thresholds discussion
topic.
-------------
Next meeting: 10 July 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
