[ibis-macro] Minutes from the 5 Nov 2013 ibis-atm meeting

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Mon, 11 Nov 2013 09:27:12 -0500

Minutes from the 5 Nov 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.

IBIS Macromodel Task Group

Meeting date: 05 November 2013

Members (asterisk for those attending):
Agilent:                      Fangyi Rao
                            * Radek Biernacki
Altera:                     * David Banas
                              Julia Liu
                              Hazlina Ramly
Andrew Joy Consulting:        Andy Joy
ANSYS:                        Samuel Mertens
                            * Dan Dvorscak
                            * Curtis Clark
                              Steve Pytel
                              Luis Armenta
Arrow Electronics:            Ian Dodd
Cadence Design Systems:       Terry Jernberg
                            * Ambrish Varma
                              Feras Al-Hawari
                            * Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cavium Networks:              Johann Nittmann
Celsionix:                    Kellee Crisafulli
Cisco Systems:                Ashwin Vasudevan
                              Syed Huq
Ericsson:                     Anders Ekholm
IBM:                          Greg Edlund
Intel:                        Michael Mirmak
Maxim Integrated Products:    Mahbubul Bari
                              Hassan Rafat
                              Ron Olisar
Mentor Graphics:            * John Angulo
                              Zhen Mu
                            * Arpad Muranyi
                              Vladimir Dmitriev-Zdorov
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
NetLogic Microsystems:        Ryan Couts
Nokia-Siemens Networks:       Eckhard Lenski
QLogic Corp.                  James Zhou
SiSoft:                     * Walter Katz
                            * Todd Westerhoff
                              Doug Burns
                              Mike LaBonte
Snowbush IP:                  Marcus Van Ierssel
ST Micro:                     Syed Sadeghi
Teraspeed Consulting Group:   Scott McMorrow
                              Bob Ross
TI:                           Casey Morrison
                              Alfred Chong
Vitesse Semiconductor:        Eric Sweetman
Xilinx:                       Mustansir Fanaswalla
                              Ray Anderson

The meeting was led by Arpad Muranyi


- Need a volunteer to take minutes, Curtis to take the minutes.
- Review of upcoming meeting schedule.  Only 12/24 and 12/31 canceled.

Call for patent disclosure:

- None

Review of ARs:

New Discussion:

Decide on IBIS [Component] vs. EBD/EMD direction for improvements:
- Arpad - I believe Walter wants to share something with us.
- Walter - [sharing his Package and On-Die Interconnect presentation]:
  - Presentation from last Open Forum meeting.
    - Fair summary of what's going on.
      - Current state:
        - IBIS [Component] limitations.
        - EBD limitations.
        - EMD solution.
        - Power Distribution Models.
        - Stacked Memory and other special cases.
        - My recommendations.
    - IBIS Limitations (Assumptions):
      - IBIS [Component] - package and single die.
      - One to one between signal [Component][Pin], die pad, and buffer 
      - No info on supply die pads.
      - Relationship between buffer supply terminals and supply 
      - Not explicit, but people talk of implicit Pin/Pkg/Buffer hierarchy.
    - IBIS Limitations:
      - Power distribution is [Pin]->die pad, then,
        die pad-> "instance" supply terminals [multiple buffer instances].
      - Impossible to do with existing IBIS [Component].
      - Pin/Pkg/buffer hierarchy is not reality.
      - Does not support IBIS-ISS subckt models for pkg and on-die interconnect.
- John - [Circuit Call] exists in 6.0.
- Arpad - What do you mean by "Pin/Pkg/Buffer is not reality"?
- Walter - In reality, there are pins, package models, buffers.
 - Current IBIS associates a buffer with a pin.
 - That's not reality for real die and packages.
- Ambrish - The last statement "does not support IBIS-ISS..."?
  - This is supported with [External Circuit].
- Walter - Okay, yes.
- Walter -  [next page of presentation]:
 - EBD limitations:
   - EBD can't be extended to connectors, cables, or multi-chip modules (MCM).
     - It is limited to "board".
   - Does not support IBIS-ISS subcircuits.
- John - People do use EBD to model packages.
- Walter - But other people say a package is not a board and EBD is for boards.
  - EBD doesn't support ISS and connections between [Component]s and MCM.
- Walter - [next page of presentation]:
 - Power Distribution Models of IBIS [Component] - single package, single die.
   - Requirements:
     - Different number of supply pins and supply die pads.
     - Supply interconnect models between supply pins and supply die pads,
       and between supply die pads and buffer supply terminals.
   - Two Possible Solutions:
     - Enhance IBIS [Components] to have a separate list of supply die pads.
     - Implement the die as a "Bare Die IBIS [Component]" with its pins
       really corresponding to die pads, and use EMD to connect to [Component]
- Walter - [next page of presentation]:
 - Stacked Memory:
   - Package has multiple identical dies.
   - Typically Address and Command pins connected to all dice.
   - Typically Cntrl pins connected to single die.
   - No connections just between individual dice.
- Walter - [next page of presentation]:
 - Other Special Cases:
   - Single package pin connected to multiple buffers.
   - Multiple package pins connected to a single buffer.
   - Handle with EMD or by enhancing IBIS [Component].
- Walter - [next page of presentation]:
 - Recommendations:
  - Proceed with EMD as a new IBIS standard.
  - Enhance IBIS component

- Walter - [now reviewing email sent to ATM group]:
 - What we've learned about die in the 20 years since IBIS...
 - Die consists of:
   - Die Pads - x,y,z locations on the die that connect to a package.
   - Signal pads.
     - Connected to a single buffer ([Model]).
     - Can be paired to form a differential connection.
       - Two single ended or a true differential buffer.
     - Signal name
     - Die pad number (name - character string)
- John - Don't you sometimes have routing or switching behind the die pad before
         you get to the buffer?
- Walter - What do you mean by switching?  It goes through some buffer?
- John - Maybe you'll hit some sort of buffer or something first.
  - What about a topology in which behind the pin there is a single die pad
    and behind the pad there are multiple buffers?
- Walter - Explain that to me.
  - Die pad goes to multiple buffers? How?
  - An I/O buffer is one input and one output, but another example?
- John - I'm thinking of a design by a particular IC vendor.
  - Wants an output, plus an input buffer (maybe also I/O), separated by some
    conductance, which can vary.
  - All sits behind a [Component] [Pin] and pad on the die.
- Walter - Buffer is really an input and I/O with a non-trivial connection.
  - Lump that in as a type of I/O buffer.
- Arpad - I would call that a join or split on the die interconnect.

[New join on the call - Ramana - worked for Intel, Maxim, and others.  Now has 
a consulting business.  Welcomed by Arpad after introducing himself.]

- Walter - Let's defer discussion on that point.
- Randy - Example:
  - NOR flash device, die pad can be either input or output.
  - Different because output driver is hidden behind a pass gate.
  - Input mode the pass gate is turned off and you only see C of the input 
  - Output state, pass gate enabled, driver drives through pass gate with some 
  - Sort of two different buffers on the same pad.
- Walter - Basically saying it's an I/O.
  - Typically an Input and a 3-state.
  - When it's driving you have one set of characteristics.
  - When it's not driving you have another set.
  - May have a different Ccomp, for example.
  - Does our current I/O allow for that?
- Arpad - A [Series Switch] type R decouples the driving and receiving models.  
  two models because the Ccomp is different for the Input and Output models and 
  can't model an I/O with different Ccomp in its drive and receive mode.
- Randy - It becomes a [Model Selector] issue.
- Walter - Limitation in the existing I/O [Model] type.
  - All are really two buffers.
  - Need to support different Ccomp, etc.
  - We've identified some complications we aren't going to solve here.
- John - The point here is:
  - One and only one signal to a particular die pad.
  - Generalize I/O to include these complications we've discussed.
- Walter - Yes, that's my approach.
- Walter - [returning to email]:
  - Supply Pads
    - Connected to one or more buffers.
    - Have a supply name (aka signal name).
    - Have a die pad number (name - character string).
  - What's a buffer?
    - Single ended or differential.
    - Input, Output, 3-state, I/O.
    - Have signal terminals connected to signal pads (two if true differential).
    - Can have control terminals.
    - Control terminals of multiple buffers may be connected.
      - ex. "buffer" or "Mux" component.
  - On-Die Interconnect
    - 1.  Connect signal die pads to buffer signal terminals
    - 2.  Connect supply die pads to buffer supply terminals.
    - 3.  Connect buffer control terminals.
  - A method to enhance IBIS to describe a die.
    - New keyword [Die].
    - [Single Ended Signal Pad] section.
      - Each instance is an instance of a buffer, so it names its supply
        connections (pu, pd, pc, gc).
    - [Differential Signal Pad] section.
    - [Supply Pad] section.
  - I think this is all the info needed to define a bare die.
- Arpad - I worry about function specific keywords.
  - A specific "type of pad" keyword prevents cross connecting them.
  - This could hose us later.
- Walter - Yes, good point.  But you could combine them I think.
- Arpad - I think the problem is differential is more inherent in the way the
  [Diff Pin] keyword works.
- Walter - Die pad number is associated with a buffer.
  - Association of supply names is done by signal name on the die instance.
  - As opposed to pin number, which has issues.
- Walter - [returning to email]:
  - What would new [Component] section look like?
    - [New Component]
      - [Signal Pin] Section.
      - [Differential Signal Pin] Section.
      - [Supply Pin] Section.
  - Ports/terminals of On-Die Interconnect
    - Die Pad Ports
      - Die signal pad numbers.
      - Die supply pad numbers.
    - Buffer signal terminals.
    - Buffer supply terminals.
    - Buffer control terminals.

  - An attempt to define some language for everything on the die in a 
  - Mapping an existing single-die IBIS [Component].
  - At a minimum, it satisfies:
    - Separate list of die supply pads.
      - Necessary for any on-die or package power distributions.
  - If doing a new [Component] structure, how much of the I/O complications will
    we want to support?
  - How would we enhance this new [Component] section to handle stacked memory?
  - What about other odd-ball relationships?
    - We would need to enhance this proposed language.
- David - Can you speak briefly to how all of this interacts with schemes you 
          others have proposed for dealing with the t-coil showing up in new
- Walter - People have talked about t-coil with on-die s-parameters.
  - T-coil interconnect structures effectively reduce Ccomp.
  - Traditionally included in the analog buffer model.
    - Touchstone file parameters (in some tools).
    - Or with BIRD 160 subcircuit with an sNp touchstone file.
    - Not interconnect, but considered part of the buffer itself.
    - Still could be some on-die interconnect between the die and the t-coil.
    - Could put the info in the on-die interconnect.
      - Then treat the buffer as a simple 50 Ohm with no Ccomp.
    - If one had on-die s-parameters or on die interconnect the IC vendor could
      have the choice of t-coil on the on-die interconnect as opposed to the
      on-die s-parameters.
- David - Which one do you think is better?
- Walter - On-die s-parameters would be superior.
  - Cell includes t-coil - simplifies extraction problem.
  - Don't know how good IC tools are to extract the interconnect and make     
  - Vendor creates s4ps for that on-die buffer.
  - Don't know how well simulators would handle t-coil with Ccomp correction.
    - People have just been lumping them together.
- Arpad - summary:
  - How should we solve limitations in IBIS to include package and on-die power
  - Should we improve IBIS [Component] section?
  - Should we take improvements into EBD/EMD?
- Walter - I think the correct statement is:
  - Do we enhance the IBIS [Component] (limit ourselves to power distribution)
    - Should we add a [Die Pad] section and a [Die Supply Pad] section?
    - To handle power distribution requirements between pkg and die pad and die
      pad and buffer.
  - Should one enhance IBIS [Component] for stacked memory?
  - If Bob were here I believe he would want a new keyword in that case.
- Arpad - I would like to generalize more:
  - Fundamental question -
    - Better modeling between pins and pads and pads and buffer terminals.
    - All agree IBIS-ISS would describe the interconnects well.
    - Need a way to connect them.
  - Two approaches:
    - Simplified approach in IBIS.
    - More general EMD approach later.
  - I think doing both would introduce a certain amount of overlap.
  - Do we want this redundant double approach, or a new super-duper approach?
  - Leave IBIS to deal with bare buffers and the new super-duper approach to
    model package and on-die interconnects.
- Walter - I believe in re-use [in this case].
  - I believe the basic IBIS structure is sound.
    - Only needs supply die pads and keywords for stacked memory.
    - Simple things get you part of it.
  - When we define how to use IBIS-ISS, EMD is like EBD and can handle it then.
- Arpad - I understand your thoughts.  I would like to hear others approach
    but we are running overtime, so I think this is a good time to stop.
  - Thank you for joining.  Don't be afraid to use email to continue this.
  - See you all next week.
Next meeting: 12 November 2013 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Other related posts:

  • » [ibis-macro] Minutes from the 5 Nov 2013 ibis-atm meeting - Mike LaBonte