[ibis-macro] Minutes from the 7 June ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Wed, 8 Jun 2016 19:29:01 -0400

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
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.


- 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
  - 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

Other related posts:

  • » [ibis-macro] Minutes from the 7 June ibis-atm meeting - Curtis Clark