Minutes from the 08 May 2018 ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 08 May 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
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:
- Mike L. noted that he wanted to briefly discuss some questions about BIRD187
and BIRD188.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Quality group's question regarding BIRD187 and BIRD188:
- Discussion: Mike noted that BIRD187 was a clarification BIRD "Format and Usage
Out Clarification." The discussion in the Quality group related to the
"Increment" and "Steps" AMI Formats. These are like "Range" except Increment
specifies the delta between steps, and "Steps" specifies the number of steps
that spans the range. BIRD187.3 specifies that the sign of "delta" in the
Increment shall be positive. Mike noted that the ibischk code allows deltas
to be anything non-negative. Mike noted that if min and max were not equal
then a delta of zero would never get from min to max. Arpad noted this was
similar to a recent discussion about whether to certain BIRD158 parameters
should explicitly state > 0, and that we had decided not to change the spec
language to address all possible non-sense models. Mike asked if the
behavior of the parser should be changed to disallow zero. Arpad noted that
if min and max could be the same then zero could be a valid delta. Radek
noted that the only problematic case was if min and max were not equal and
delta were specified as zero. He noted that particular case should be caught
and flagged as an error. Bob and Mike noted that the new language of
BIRD187.3 says "the sign of delta shall be positive" which could leave open
the possibility that the value is zero, where the original language had
specified positive value (implying zero was invalid). Arpad noted that
neither BIRD187 nor BIRD188 were yet in the spec and asked what we needed
to do. Bob and Mike suggested that it could be handled by an editorial
change to clarify BIRD187.3's use of "sign" and make it clear whether or not
a zero delta was allowed at all.
Review of Topic bin list:
- Discussion: Arpad noted two new topics to consider for this list. He asked
if the EMD topic should be taken up by ATM or the Interconnect group. Randy
said it was best handled in the Interconnect group and could be picked up as
soon as BIRD189 was finished. Bob agreed and emphasized it would be taken up
after BIRD189 was completed. Arpad agreed to remove it from the ATM agenda.
Arpad noted that the term "port" had been used in the VHDL-AMS sense in the
[External Model] and [External Circuit] sections. He noted that this use of
port was quite different from what EEs think of as ports. He asked if the
"port cleanup" task to address this language inconsistency could be handled as
an Editorial task or needed further discussion in ATM. Radek said he thought
ATM could provide its input/opinion on the topic to the Editorial group, and
it could then be handled as a strictly editorial matter. Bob thought we
needed to review it more carefully in ATM first to make sure we didn't miss
or introduce other inconsistencies. He also suggested we might just leave it
as is and not address the language inconsistency. Bob noted that it would not
be strictly editorial in the search-and-replace sense. He said he preferred a
full BIRD for this task that would identify all changes to text, figures, etc.
He noted that the Editorial group might be able to deliberate and create the
BIRD, it did not have to be done in ATM. Arpad agreed it could come back to
ATM if further technical changes were required, and noted that the Editorial
group typically did not create BIRDs. Arpad said the minimum requirement, if
we chose not to tackle the entire cleanup, would be to explain that we
currently use the term "port" with two different interpretations. The group
expected this work would not be part of 7.0.
Arpad suggested reorganizing the bin list and placing the highest priority
items on top.
Radek suggested that "Allowing Terminator as a model_type for IBIS-AMI
receivers" could be moved to the top of the list, as it could likely be
handled quickly. It was moved to the top of the list, but Michael M.
and Bob noted that it might not be a quick one-liner as some envisioned.
Arpad asked if the two topics "Removing single-ended input threshold
requirements for differential buffers" and "Removing single-ended
characterization load requirements for differential buffers" should be
moved up along with the "Terminator" topic. Bob said this would be a big
discussion because it changed IBIS tradition in the sense that it would make
earlier IBIS models not upgradeable (a simple update of the version would
cause them to be non-compliant). Arpad asked if the threshold changes were
required for the Terminator as AMI model_type topic. Michael M. said that
we needed to discuss the differences between Terminator and Input, but that
these two topics were not required in order to address the Terminator issue.
These two topics address the need for more useful thresholds for differential
buffers. Bob noted that IBIS historically made compromises and left certain
keywords required even if they weren't strictly necessary. For example,
[Ramp] is still required even if waveforms are available. He said this was
done to avoid having confusing syntactical logic necessary to decide when
things were or weren't required. Michael M. said these changes would not
be easy.
Randy noted that he was willing to continue discussion on the new C_comp
proposal at any point, and noted that he would like to make sure people have
time to focus on it (after BIRD189). Arpad asked how urgent this topic was.
Michael M. said it was important, especially for single ended buffers. Randy
agreed and said he wanted to get it into the first 7.x version. Bob agreed
and noted that now that "terminals" have been clarified in BIRD189 we can
revisit this proposal. Michael M. noted that he thought this topic would also
get bogged down in referencing discussions. He noted that the clarifications
on referencing topic would be useful for this topic, though he wanted the
clarifications topic to stay at the bottom of the list. This new C_comp topic
was moved to second on the list.
Arpad asked about the "Guidance for power-aware vs. AMI models" topic.
Michael M. asked if there is a way to include some non-LTI information, such
as ISSO data, in AMI. Randy said this topic would need a lot more input from
people investigating DDR5. He noted that power-aware is more important for
people looking at single-ended signaling with equalization (e.g. DDR5). Arpad
asked if that was the point of this topic. He noted that he thought the topic
hadn't been proposed for that reason, but had been proposed so that we would
clarify that you shouldn't expect ISSO, etc., to be used in AMI simulations.
Arpad noted his response to an email question asking about using ISSO with
differential buffers. His answer had been that ISSO keywords can't be used
with true differential modeling. Michael M. said we need to explain how they
interact. This topic was left below the single-ended items topics.
The FEC topic was renamed to "IBIS AMI post simulation processing" and moved
to the bottom of the list per Mike L.'s suggestion.
Michael M. said he could discuss the first topic (Terminator in AMI) next
week.
Tabled Topics:
- Discussion: The group briefly reviewed the tabled topics. Item 9 (new C_comp)
was removed from this list since it is now a priority topic (above). Randy
noted that Item 10 (single-ended AMI) will likely come up later and should
not be removed. Bob and Radek said item 11 should stay. Arpad suggested 12,
13, and 14 (all related to Redriver flow) should stay. Arpad noted that he
would keep item 15 as well, though it is low priority. All items remained
except item 9.
- Radek: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 15 May 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
