Minutes from the 5 Nov 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.
Mike
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
------------------------------------------------------------------------
Opens:
- 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
instance.
- No info on supply die pads.
- Relationship between buffer supply terminals and supply
[Component][Pin]s.
- 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]
pins.
- 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
buffer.
- Output state, pass gate enabled, driver drives through pass gate with some
R.
- 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.
Needs
two models because the Ccomp is different for the Input and Output models and
we
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
[Component].
- 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
and
others have proposed for dealing with the t-coil showing up in new
transceivers?
- 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
s-params.
- 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
distribution?
- 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
