Minutes from the 18 Jun 2019 IBIS ATM meeting are attached.
IBIS Macromodel Task Group
Meeting date: 18 June 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
Radek Biernacki
Ming Yan
Stephen Slater
Maziar Farahmand
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
SPISim: * Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Fangyi to prepare a version of the DC_Offset BIRD utilizing approach #2.
- Done.
- Fangyi to send his DC_Offset BIRD presentation to ATM.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the June 11
meeting. Bob moved to approve the minutes. Randy seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD197.3_draft_5(DC_Offset):
Arpad reviewed his most recent summary email and highlighted the differences
between approach 1 and approach 2 as defined in Fangyi's presentation and
discussed at the previous meeting. Arpad noted that approach 1 might also
need DC_Offset to be InOut in order to be equivalent to approach 2.
Walter noted that he preferred approach 0, simply leaving things alone and
sticking with the BIRD197.2 he had submitted to the Open Forum. Ambrish agreed
and said he thought the threshold (returned via NRZ_Threshold in approach 2) was
what the model needed for itself for error correction and DFE. It didn't need
to be returned by the model. He also noted that it shouldn't be confused with
the DC_Offset the BIRD originally introduced.
Arpad noted that BIRD197.2 did not contain the DC_for_Statistical parameter.
He asked if Walter did not want that either. Walter confirmed that he did not
think DC_for_Statistical was necessary. Walter suggested returning to BIRD197.2
and possibly drafting a second BIRD for NRZ_Threshold.
Walter reviewed a preliminary draft he had written for an NRZ_Threshold BIRD.
After the group reviewed it, Fangyi noted that his latest (draft_5) proposal
defined NRZ_Threshold in the same way. Walter agreed and noted that he was
okay with having NRZ_Threshold and DC_Offset in the same BIRD.
Fangyi said he thought we still needed DC_for_Statistical. Walter said it was
not needed, and that NRZ_Threshold could be returned by Init() and GetWave().
Fangyi proposed an example in which the waveform at the slicer had a .7V DC
offset, but the model had decided the threshold was at .8V. In this case
GetWave() could return a waveform containing the .7V offset and an NRZ_Threshold
value of .8V, but statistical flow would not be able to provide the .7V offset
information. So, the model would produce different results for statistical and
time domain flows.
Walter said he didn't think it was meaningful for people to ask for the
"physical waveform" at the slicer, or to care about the .7V offset relative to
some local reference, as this waveform couldn't be readily measured in a lab.
Walter suggested the natural thing to do is just worry about the difference
between the signal voltage and the threshold voltage. So, the model should
simply return the .1V difference between the .8V threshold and the .7V DC
offset in this example. Fangyi asked Arpad if he was okay giving up on the
offset information and the ability to provide the waveform in absolute terms.
Arpad said he was fine with removing the DC_for_Statistical parameter for now,
because we could always write a new BIRD later if we discovered that it would be
useful to have this parameter.
Walter suggested we take Fangyi's latest draft_5, remove the DC_for_Statistical
parameter, and add Rx_Receiver_Sensitivity information to the NRZ_Threshold
description. Fangyi took the AR to make those updates to draft_5 so that ATM
can review it at the next meeting.
Complex C_comp modeling:
Randy reviewed his latest draft:
- Removed use of the undefined term "token" per Bob's suggestion.
- Replaced "Mode" Subparam with "C_comp_model_mode" per Bob's suggestion.
- Based on a suggestion from Arpad, the text explaining what to do for any
undefined modes was moved into its own paragraph.
Bob noted one suggestion he had forgotten to make previously. In the "Rules of
Precedence" section, Bob objected to the use of the phrase "... assume that
[C Comp Model] is more accurate than C_comp*." He suggested "more detailed" to
avoid any value judgement on accuracy. Randy was unsure about this suggestion
because the whole point of the section is to give a justification for the rules
of precedence, and "more accurate" would justify the higher precedence for a
[C Comp Model]. Arpad suggested the term "realistic" instead.
Arpad expressed concern about the weakness of the final sentence in the section.
"The EDA tool may use the [C Comp Corner] values for V-T curve shaping
during simulation."
He said this statement should be strengthened to make sure model makers
understand that [C Comp Corner] is what will be used by tools for deriving the
K(t) curves, so the [C Comp Corner] values are critical even when [C Comp Model]
exists. Walter agreed and noted that he had experimented with developing an
algorithm that would use the [C Comp Model] and an iterative approach to
deriving the K(t) curves. He said it turned out to be a difficult problem,
so it's important that the model provide accurate [C Comp Corner] values for
tools to use during K(t) generation. Walter proposed:
"The model maker should anticipate that EDA tools will use [C Comp Corner]
values to derive the K(t) curves."
Arpad noted that we can continue the discussion next time.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Fangyi to modify BIRD197.3_draft_5 to create draft_6 per today's discussion.
-------------
Next meeting: 25 June 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
