Minutes from the 7 June ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
07-JUN-2016 Walter Katz SiSoft IO Buffer Reference Terminal (zip
<http://ibis.org/macromodel_wip/archive/20160607/walterkatz/IO_Buffer_Reference_Terminal.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160607/walterkatz/IO%20Buffer%20Reference%20Terminal/IO_Buffer_Reference_Terminal.pdf>
)
IBIS Macromodel Task Group
Meeting date: 07 June 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
* Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp.: James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys: Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
- In progress.
--------------------------
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.
- Dan: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
[Pin Reference] BIRD Draft:
- Walter moved to untable this topic. Bob seconded. No one objected.
- Walter: [sharing new "IO Buffer Reference Terminal" presentation]
- [Slides 2 and 3, fundamental Physics]
- Measurement between two nodes in a circuit.
- There is a potential difference between them.
- Not practical to measure it when the distance between the nodes is greater
than 1/10th of the wavelength of the highest frequency of interest.
- 20 years ago, at 30MHz, 1/10th wavelength was about a foot.
- At 28Gbps, 1/10th wavelength is about 10 mils.
- [Slide 4]
- If it's not practical to measure, it doesn't make sense to do any analysis
based upon it.
- [Slide 5 - Current Return Path]
- E&M theory says return currents are always close to the signal current. So,
you should make measurements nearby. This is an oversimplification, but
it is illustrative.
- [Slide 6 - Measuring potential difference of two nearby points]
- You can have a single probe between them.
- You can have two probes, each measuring the difference between one of the
points and a common good ground (e.g. node 0).
- You can measure each of the points relative to a simulator node zero, but
the only thing meaningful is the difference between the two voltages.
- [Slide 7 - Correct terminology is "Return Path"]
- No such thing as "ground" in modern signal integrity.
- Return paths are what are important.
- Node 0 is a mathematical reference in a simulator, it's not meaningful in a
physical design.
- [Slide 8 - Measurements at an I/O buffer]
- The only things that makes sense for measurements at a buffer are
measurements between the terminals of the buffer.
- [Slide 9 - IBIS Figure 16]
- Most basic case, only [Voltage Range] specified, so [Pulldown Reference] =
[GND Clamp Reference] = 0.0V.
- So pulldown_ref and gnd_clamp_ref (same node in this case) are the reference
node for all DUT measurements.
- Three distinct nodes in this case, pullup_ref, pulldown_ref, IO.
- Only Three voltages you can measure in this case. Measure any two of them,
for example, (pullup_ref - pulldown_ref) and (IO - pulldown_ref), and
you can compute the third.
- [In response to others challenging this simple example] Yes, all the
[* Reference] values could be specified and could be different, and in
that case you do have five nodes (including I/O) and you need four
voltage measurements to define the problem.
- [Back to the simple example] In this simple example, it's only logical
to make the pulldown_ref terminal the reference terminal.
- Make the two measurements relative to that reference terminal.
- The measurement of the IO pad relative to the reference is what is
compared against the threshold values.
- [Slide 10 - Return Path Terminal]
- If one of the [* Reference] values is specified as 0.0V in the IBIS [Model],
then its corresponding *_ref terminal is the "DUT Reference Terminal."
- Note that Bob would have a different special rule for making this choice
for ECL. The default *_ref terminal to choose would be the one that
corresponds to the [* Reference] with the largest (including sign, not just
magnitude) value.
- Discussion: Arpad noted that the IBIS spec does not require the presence of
any of the four [* Reference] values in the [Model], and asked if we should
add some conditional statement with regard to the "rule" for choosing the
reference terminal. Walter replied that the EDA tool would be choosing this
reference terminal, since it applies the voltages to the various I/V tables.
The EDA tool would choose the reference terminal from amongst the terminals
that actually existed. For a typical [Model], it would choose the *_ref
terminal that existed and corresponded to a [* Reference] specified as 0.0V.
For the ECL model, the EDA tool might choose the existing *_ref terminal that
had the [* Reference] set to the largest value. Walter noted that the logic
would get touchy if none of the [* Reference] values were specified as
0.0V, but the new BIRD would allow the model maker to unambiguously state
which terminal to use as the reference terminal.
- [Slides 11,12 and 13 - new [Model] subparameter DUT_ref_term]
- Defines which rail terminal serves as the reference terminal.
- If the reference terminal corresponds to a [* Reference] with a non-zero
value, then voltages are measured relative to the reference terminal and
then the non-zero value of [* Reference] is added to the measured voltages
to correct for this offset.
- [Slide 14 - proposed text of the new DUT_ref_term BIRD]
- Please review the proposed text and provide feedback.
- [Slide 15 - What if Some Thresholds Are Sensitive to the Power Rail?]
- This is an important issue, but one that is entirely separate.
- This is what [Receiver Thresholds] currently tries to address.
- If the voltage difference between the power and ground rails during
simulation is different from the difference during DUT measurements,
how are thresholds affected?
- One might have overshoot going up linearly with the max voltage.
- Undershoot might be relative to pulldown reference only.
- Others might scale based on the delta between power and ground.
- etc.
- It's still important that one makes consistent measurements relative to the
reference terminal.
- Bob is going to draft a BIRD to deal with this "scaling" issue for the
thresholds in a general way.
- [Slide 16 - What about Pin vs. Buffer Measurements?]
- In the old days, a package was half an inch long, and we had a 10 inches to
play with (based on 30MHz).
- Now, a package that's half an inch long might have five full bits in it
(approx. 100 mil wavelength at 28Gbps).
- All your measurements really have to be at the buffer to keep them close.
- If you make measurements at the pins, all of them should be made at the
pins, and you should keep the pin and its rail pins as close as possible.
- Pin measurements aren't accurate at very high data rates.
- For DDR4 and certainly SerDes, you can't do timing measurements at the pin
anymore.
- Various standards still have rules that require measurements at the pin.
Those measurements are made for compliance tests, not necessarily to predict
the actual timing performance of the device.
- Discussion: Radek noted that circuit theory relies on a quasi-static
assumption and that this topic is related to that assumption, and that there
area always tradeoffs involved in choosing E&M tools or circuit simulation.
Radek noted that he felt the new proposal differed from the previous [Pin
Reference] BIRD in that the earlier one was primarily concerned with Power
Integrity simulations and Component Pins as references. The new proposal
was instead looking at individual [Model] terminals rather than Pins. Walter
said that the earlier proposal specified the reference for a given buffer by
signal_name or bus_label. But by specifying signal_name, which directly goes
to a given buffer terminal, the actual buffer terminal serving as the
reference was specified. With the new proposal, the terminal name is given
directly, and there is no longer a dependence on [Pin Mapping] to map the
bus_label (signal_name) to the actual buffer terminal. Walter felt the
proposals were equivalent, but Radek felt they might be complementary. Radek
expressed concern about a possible hole in this approach if all four of the
[* Reference] values were non-zero. Walter agreed that this was a case where
IBIS is flawed. He described an RS232 example, and said the rails might be
specified as + and - 15V. In reality there was a "0V" (local ground) pin
also provided on the component, but IBIS had no way of capturing that. He
said one option would be to choose the most stable of the [* Reference]
associated terminals and add the non-zero [* Reference] value to the voltages
measured relative to that terminal. Radek suggested that IBIS should finally
add a way to capture the true local ground terminal in all cases. Arpad noted
that such a device might have a "local ground" pin, but it might instead
derive that local ground internally, for example with a resistor divider
between the pullup_ref and pulldown_ref. He felt the latter case was the one
IBIS didn't really handle. Walter said you could handle that case if you
resorted to the full ground-based referencing scheme, or you simply wouldn't
do power aware simulations with such a model. Bob said that he supported this
BIRD and its notion of moving the information into the [Model]. While the new
approach no longer explicitly relies on [Pin Mapping] to specify the reference
terminal for a buffer, [Component] level simulations would still need
[Pin Mapping] to properly process interactions of power buses. Bob said he
would prepare the separate "scaling" BIRD. Walter and Arpad noted that the
DUT_ref_term BIRD's concept is fundamental to the issues at hand in the
editorial and interconnect groups. The "scaling" BIRD is important in its
own right, but what it addresses is not currently holding up any other task
groups. Radek agreed, but he noted that we have to make sure we keep the
"scaling" BIRD's concepts in mind during the other discussions.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 14 June 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
