[ibis-macro] Minutes from the 31 May ibis-atm meeting

  • From: Curtis Clark <curtis.clark@xxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Fri, 3 Jun 2016 11:53:33 -0400

Minutes from the 31 May ibis-atm meeting are attached.

The following document, which was first posted April 7th of 2015, was
reviewed during the discussion.

07-APR-2015 Randy Wolff Micron Technology C_comp Model Using IBIS-ISS BIRD
draft 6 (zip
<http://ibis.org/macromodel_wip/archive/20150407/randywolff/C_comp_Model_Using_IBIS-ISS_BIRD_draft_6.zip>
)(dir
<http://ibis.org/macromodel_wip/archive/20150407/randywolff/C_comp%20Model%20Using%20IBIS-ISS%20BIRD%20draft%206/>
)
IBIS Macromodel Task Group

Meeting date: 31 May 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:

C_comp Improvements:

- Randy: I've started with the last revision of this BIRD draft, approximately
         a year old, and I'm converting it to the new BIRD template.
  - The first thing in the new template is the Solution Requirements table.
  - I've drafted the rough text of the entries in the Solution Requirements
    table, and I wanted to discuss the requirements with the group and come to
    agreement on them before I proceed.
  - [Sharing Solution Requirements table from new BIRD draft]
  
  - Requirement #1: Allow an IBIS-ISS subcircuit or Touchstone file to be
    used as a C_comp model.
  - Note #1: Up to three models should be allowed to cover typ/min/max corners.
    Define how they align with corners.
  - Discussion: Arpad asked if the Note indeed meant no-more-than three.
    Randy said the intention was that you might have one subcircuit (or
    Touchstone file) for each corner, or one that served for all corners, but
    that three would be the max.
    
  - Requirement #2: Define the terminals of the C_comp model including
    references, signal (both internal and external to allow a series R model)
    and a receiver terminal for probing the input buffer.
  - Note #2: Terminals for single-ended and differential models should be
    defined.
  - Discussion: Mike asked if probing the input buffer were optional or
    mandatory?  Randy said the model could include this terminal and the EDA
    tool could optionally use it.  He said the reason for specifying that
    terminal was that one may have some series R or C filtering between the pad
    and the actual input receiver, and that Micron had found it very useful to
    be able to probe that node.  Bob noted that a series C could cause problems
    for many tools, and Randy agreed and said we should restrict that series
    element to a resistance [change already made in the text above].  Randy
    also said the Note might actually be considered a separate requirement.
    Arpad agreed and said we might need to clarify pseudo vs. true differential.
    Arpad noted that true differential is only available with [External Model].
    Bob said we might require that this works with or without External Model.
    Walter noted that true differential is really only available with [External
    Model], in which case C_comp or this new C_comp model would not be used
    anyway.  It would all be embedded in the [External Model].
    
  - Randy: [Sharing C_Comp Model Using IBIS-ISS draft 6 (posted April 7, 2015)]
  - Discussion: Randy briefly reviewed Figure Y in order to discuss the internal
    and input buffer terminals (A_signal_I and A_receive).  Walter asked if this
    figure meant that for an I/O the A_receive section just goes into the [POWER
    Clamp] and [GND Clamp] curves, and the A_signal_I section goes into the
    [Pullup] and [Pulldown] curves?  Walter said his interpretation of the
    figure was that the receiver is always receiving, and its load would be
    captured in the clamping tables.  The driver aspect would be completely
    switched off if the buffer weren't driving, and that aspect would be
    captured in the [Pullup] and [Pulldown] tables.  Bob said that his
    interpretation was that driver mode was represented by the top buffer in the
    figure, and the receiver part was disconnected when driving, so the driver
    portion also considered the clamping tables.  The receiver portion is
    switched in during receive mode, but the generalized C_comp model can
    support a different path from the signal pad to the receiver.  He said the
    A_receive was a new terminal not in the current multilingual.  Arpad stated
    that it didn't necessarily require a new terminal because at simulation
    time the device is either in driver mode or receiver mode (can't switch
    during the simulation) so the node would either be one or the other.  Bob
    agreed that this was possible if the generalized C_comp model had a way to
    switch between driver and receiver modes.  Randy pointed out that a series
    element in the path to A_signal_I was the result of an on-die interconnect,
    where the series element in the path to A_receive might be there for
    intentional filtering.  Arpad noted that we didn't have to solve the actual
    implementation issues (new terminal vs. two separate C_comp models for 
    driver or receiver mode) at this point.
    
    
  - Requirement #3: Explain handling of the reference for Touchstone files.
  - Note #3: [none]
  - Discussion: Radek and Mike recommended this be changed to the general
    statement shown above, and said this can ultimately rely on the solution
    being worked out in the interconnect meetings.
    
  - Requirement #4: Define how parameters can be instantiated and passed into
    the IBIS-ISS subcircuits for each of the typ/min/max corners. 
  - Note #4: Parameters should be single values that can be passed into either
    the typ, min or max corner subcircuit.  Parameters are not meant to define
    ranges.
  - Discussion: Randy noted that the interconnect task group allowed only single
    valued parameters to be passed into a subcircuit.  For this C_comp proposal
    we need a way to pass parameters into one of three subcircuits (corners),
    but that his intention is that those parameters are still single valued
    and not ranges, etc.  Bob pointed out that we would need to carefully define
    how the C_comp subcircuit corners align with the typ/min/max model corners.
    Randy agreed and added this definition of alignment to Note #1.  Mike noted
    that we might want to require that the three subcircuits for the corners
    all take the same parameters, since we probably want to avoid a case
    where the typ subcircuit takes a param called typ_ABC while the max
    subcircuit takes one called max_ABC.
  - Requirement #5: Explain hierarchy of the new C_comp model with existing
    keywords including [C Comp Corner] or any other C_comp* models.
  - Note #5: The new C_comp model should override other C_comp models.  May need
    to explain how a simulator could use traditional C_comp* values for K-T
    curve generation.
  - Discussion: Randy said this requirement captured the need to describe how a
    simulator would actually use this new C_comp model.  For example, we might
    adopt Walter's suggestion and describe how legacy C_comp is used only to
    generate the K(t) curves, and then the new C_comp model is inserted at
    simulation time.  Bob expressed concerns about the alignment of various
    C_comp parameters and or the [C Comp Corner] parameters.  Walter said he
    thought we would need to require the use of [C Comp Corner] because
    every v(t) curve has to be compensated for C_comp, and we need to know the
    right C_comp for each corner.  Bob agreed.  He noted that some tools made
    assumptions about how to choose standard C_comp parameters to match various
    corners, but that would open up a whole separate set of issues.
    
Referencing Question:
- Discussion: Walter reviewed a brief email he had sent to the ATM list.  We
  have three voltages VDD, VSS (the rails) and V at the I/O (IO) all relative to
  some simulator reference node.  Does everyone agree that the operation of the
  buffer is only a function of two of the following three voltages?:
  1. VDD - VSS
  2. VDD - IO
  3. VSS - IO
  The third can be derived given any two of them.  Arpad said he tended to agree
  with this statement, since we have two I/V curves based on VDD-IO and IO-VSS.
  Radek felt the question was too simplified since it said nothing of the load.
  Arpad asked what the exact purpose of asking the question was.  Walter said he
  would send out another email and rephrase the question and explain its intent.

- Bob: Motion to adjourn.
- Mike: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 7 June 2016 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 31 May ibis-atm meeting - Curtis Clark