Minutes from the 15 May ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have been
posted to the ATM Task Group archive.
*DATE* AUTHOR <http://ibis.org/atm_wip/archive-author.html> ORGANIZATION
<http://ibis.org/atm_wip/archive-org.html> TITLE
<http://ibis.org/atm_wip/archive-title.html> FORMATS
15-MAY-2018 Michael Mirmak Intel Corporation Terminators as IBIS-AMI
Receivers (zip
<http://ibis.org/atm_wip/archive/20180515/michaelmirmak/Terminators_as_IBIS-AMI_Receivers.zip>
)(pdf
<http://ibis.org/atm_wip/archive/20180515/michaelmirmak/Terminators%20as%20IBIS-AMI%20Receivers/Terminators-as-IBIS-AMI-Receivers.pdf>
)
15-MAY-2018 Michael Mirmak Intel Corporation BIRD194 and Lab Correlation (
zip
<http://ibis.org/atm_wip/archive/20180515/michaelmirmak/BIRD194_and_Lab_Correlation.zip>
)(pdf
<http://ibis.org/atm_wip/archive/20180515/michaelmirmak/BIRD194%20and%20Lab%20Correlation/BIRD194%20and%20Lab%20Correlation.pdf>
)
IBIS Macromodel Task Group
Meeting date: 15 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:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Bob: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Michael Mirmak's "Terminators as IBIS-AMI Receivers":
- Michael M: [sharing presentation]
- slide "Needs and Issues"
- For AMI, modeling receiver terminations as parallel RC circuits is
attractive.
- Most AMI analog buffers are LTI "enough" to be modeled as simple RC
circuits.
- Generating IBIS analog I-V tables for simple terminations is annoying and
can be mistake prone.
- Ideal to have SPICE-like RLC values, per corner, available as an
alternative to I-V tables for this purpose.
- slide "The Barrier and Potential Solutions:"
- Model_type Terminator permits several RLC combinations as simple values.
- [Rgnd], [Rpower], [Rac], [Cac]
- Problem: Terminator is explicitly prohibited for use with AMI models.
- Apparently done to ensure logic thresholds are present on AMI analog Rx.
- slide "Three Options for a BIRD"
- 1. Remove the prohibition on Terminator use with AMI.
- Means logic thresholds won't be available.
- Easiest BIRD to write.
- 2. Permit [Rgnd], [Rpower], [Rac], [Cac] for non-Terminator input
Model_types.
- The [Rac], etc. keywords would override other analog behavioral keywords
aside from C_comp.
- 3. Create a new Model_type that uses only [Rac], etc., keywords plus
thresholds.
- e.g., Model_type Linear_input, Model_type Linear_input_diff.
- Could address related issues for single-ended buffers.
- Discussion: Radek said the first option was perfectly fine. He noted that the
other options were too complicated, traditional logic thresholds (Vinl, Vinh)
in the Input type models weren't really useful in AMI simulations anyway, and
all that was needed for AMI simulations was the analog loading information a
Terminator could provide. Curtis agreed and noted that some AMI Rx models and
simulators already ignored the prohibition on Terminators as AMI Rx models.
Arpad agreed with Radek's points, but questioned whether this was only wanted
in the AMI context. He noted that he had heard people asking for it even in
traditional IBIS contexts. He therefore leaned toward the second option as a
more general solution to provide [Rac], etc., in all scenarios. Radek noted
the issue at hand was the restriction on the use of Terminator in AMI models.
Walter confirmed with Michael M. that his current concern was purely in the
AMI context. Walter then noted two other options. One could use [External
Model] to wrap a simple RC schematic. Alternatively, we could introduce new
AMI Reserved parameters (e.g. Rx_C) similar to the way Rx_R was introduced in
BIRD158(BIRD194). Arpad again noted that these constructs could be handy for
more than just AMI applications. He noted that series RC models could not
be handled with I-V tables. He noted the Terminator model had even been a
big topic in the late 1990s when Rambus produced models with an RC type
C_comp model.
Michael M. said he thought Randy's upcoming Improved C_comp proposal would
address the need for Rac, Cac, etc. in other contexts. He said he thought
resolving the AMI issue was important for this discussion. He noted that he
considered Walter's proposal of new AMI reserved parameters a valid fourth
option, and that this was preferable to the [External Model] suggestion. He
did note that there was an issue with mixing the analog modeling info
into the AMI file and blurring the line between analog and algorithmic. Radek
said this was just another way to override what was in the IBIS buffer model.
He noted that the real question should be why we had prohibited the use of
Terminator in the first place. Arpad said it had been done for consistency,
and that a distinction had been made between Terminators and Inputs (Inputs
have thresholds).
Bob noted that he thought what we currently had was fine. However, he noted
that he would support option 1, though he disliked mixing the Terminator and
receiver concepts. He said the other options would corrupt IBIS. He noted
that inconsistencies exist already, for example, an Input model could be used
legally as an AMI Rx model even if it had all sorts of non-linear stuff
contained within it. Simply allowing Terminator for an AMI application and
not worrying about the missing threshold parameters would solve the problem
at hand most easily.
Michael M. and Arpad suggested everyone consider the four options and be
prepared for a discussion or vote at the next meeting.
Michael Mirmak's "BIRD194 and Lab Correlation":
- Michael M: [sharing presentation]
- slide "Current Definitions in BIRD194"
- Review of BIRD194 and the prescribed Tx and Rx circuit topologies.
- slides "Issue - How to Extract from Real Silicon?"
- In the laboratory, assuming package de-embedding is possible, only an s2p
may be available from extraction.
- Probing at the pins or buffer pads should be possible.
- Probing more deeply on-die (i.e., ports 2 and 4 shown on the BIRD194 Rx
figure) maybe be impossible or prohibitively expensive.
- The only way to turn the measured s2p into an s4p for correlation would
make assumptions as to termination.
- Termination may not be controllable through test nodes.
- Verification of termination is part of the purpose of lab correlation in
the first place.
- The s4p in BIRD194 becomes an s2p if you assume Rx_R is known and ensure
the reference is the same as the "Ref" for extraction at ports 1 and 3.
- If you have to assume you know the termination, then you're going beyond
strict correlation tests.
- slide "Key Questions"
- Should BIRD194 only support s4p files?
- Can s2p be supported?
- Either explicitly...
- Or through conversion from or to s4p using stated rules?
- slide "An Example Circuit - RX"
- Contrived example. Example circuit on the right has the two reference
nodes smuggled into the circuit to make an s2p.
- Is the referencing for the internal terminations appropriate for
conversion to s2p? Non-ambiguous conversion rules may not be possible
without considering referencing.
- slide "AC Analysis Makes Rx and Tx Identical"
- For AC lab analyses in the frequency domain, the transient and dc sources
go to zero and the Tx case reduces to the Rx case.
- Discussion: Michael M. asked if BIRD194 was arbitrarily limiting us by only
supporting s4ps. Is there a way to make s2p based extractions work with
BIRD194 s4p definitions? Radek said that you're losing some information on
the behavior of the receiver if you just provide an s2p. Without the
termination info you lose information about the output signal. Arpad noted
that ports 2 and 4 were the locations at which the impulse response waveform
was captured and passed on to the AMI processing. If we made an s2p instead,
where would we get that impulse response waveform? Michael M. acknowledged
that this was a great point. He noted that we might currently have to live
with the ambiguity. If one measures the s2p, then they are getting the s4p
and the Rx_R termination network in one group. We can convert that s2p to an
s4p given some assumptions about the value of the Rx_R termination. But we
can't necessarily measure and determine the actual Rx_R value. Having to make
assumptions about the value of Rx_R leads to the ambiguity.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 22 May 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
