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 ------------------------------------------------------------------------ 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
Description: S/MIME Cryptographic Signature