Minutes from the 19 Nov 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for an excellent job taking minutes.
IBIS Macromodel Task Group Meeting date: 19 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 Mike LaBonte ------------------------------------------------------------------------ Opens: - None -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None new from last week. ------------- New Discussion: - Mike - I had planned on starting with item #5 (IBIS [Component] changes). - We could start with something else if anyone wants to. [no suggestions] - I believe Walter has something to share related to item #5. Decide on IBIS [Component] vs. EBD/EMD direction for improvements: - Walter - I have prepared a spreadsheet with Mike. [sharing spreadsheet] - It is a tracking device for our decisions. - We need to decide on any [Component] changes before we get to package and on-die. - [Section A] - List of enhancements we could make (1 through 8). - Can we resolve these? - Mike - First, any questions? - Walter - Let me go over the list first. - Mike - I just want to make sure everyone understands the meaning of the columns. - status, opponents, proponents, etc. - Walter - The syntax column: Yes means there is a proposed IBIS syntax for the change. - Arpad - Has this spreadsheet been emailed to everyone? - Walter - This has not been emailed. - There may be some sensitive information (e.g. proponents, opponents). - May want to get people's approval or remove some information. - Walter - The EMD column: Do we need to do anything or can EMD do it already? - [Going over the list of [Component] enhancements]. - 1. Bare die only, but including on-die interconnect (no package). - Proposed by Michael Mirmak. - Might be useful, not required. Could just zero out the package. - 2. Bare buffer, no package and zero on-die model. - Also proposed by Michael Mirmak. - Might be useful, not required. Could also be done with existing [Component]. - Bob - These were proposed as part of BIRD 161. - Walter - Yes. - 3. Memory stacked dice supported (identical dice). - Proposed by Randy. - Some objections from John. - I've proposed some syntax, but EMD can do it. - Ongoing discussion... - Mike - Do those listed as proponents and opponents agree that they are? - John - What do other EDA tool vendors think? - This is easy for inputs, 4 in parallel, just 4 times C_comp. - What about outputs, which would be driving? - Walter - I'd like to respond. - Inputs, would be 4 instances in parallel with no increase in C_comp. - John - The larger issue for EDA tools is logistics for managing those instances. - Walter - I understand. I'd like to finish my comment... - For Output or I/O or 3State, one is driving with the others disabled. - Used for memory DQ for I/O. 4 DQs in parallel, different ODT. - Let's change this from mostly yes to "Issue for EDA vendors, will they support it?" - John - It's essentially a logistics/database issue. - Walter - I think if we say "Yes," we need consensus. - We don't want to go to the Open Forum with two EDA vendors for and two against. - We need to have this discussion and come to consensus. - John - We have to have that discussion and drill down. - Walter - - 4. non-memory stacked dice (identical) - No examples of this. - Would be nice to say "No" and remove this. - Bob - If I/O looks like "memory" then we should. - Mike - "Memory" is used as a shorthand for a list of restrictions. - Walter - I'll put "No?" as the status. This is not critical. - Walter - - 5. Multiple different dice (MCM) - Status, No. - Randy objects to this. Don't want different technologies in the same IBIS file. - 6. Supply Die Pads - If we want separate power distribution on-die from the package then we need to make these up. We need supply die pads. - If we decide not to do this then we can't support independent package and on-die distribution. - John - - Exposing the distinction in the IBIS file will enable to the tool to mix and match the on-die and package models. - If the model maker wants to release a package with a single model, they could put them both in a single IBIS ISS. - Walter - I agree, that brings us to 7 and 8. - 7. Separate package and on-die interconnect models. - Reduces the number of models delivered by memory vendors. - Randy is a proponent. - Example: Suppose you have 50 IBIS models for 50 on die distributions. - Suppose you have 20 different package models. - If separate, then you can provide 50 IBIS files, each with one one-die distribution model, and 20 package model files. - If one model includes both on-die and package, then you have to maintain 50 * 20 = 1000 models. - That's a strong reason for Randy to want it. - 8. Include on-die interconnect in the package model. - Some ASIC guys, for example, could do it this way. - But they could just as well do it like #7. - Brad - In other words, it's a convenience. A + B is less than A * B. - Walter - I get the sense that we have proponents of both, but no one rejects either. - Brad - #6 is driven by #7. - John - We want to support 50 * 20 combinations, but we're concerned about the additional overhead of a subcircuit that supports both the die and package? - Walter - True. - Suppose we have 50 on-die interconnect models, and using some package tool they generate 20 package models. - If you do item #7, you provide 70 subcircuits. - If you say, "No, we only do item #8." Then you have to have 1000 subcircuits. - Those subcircuits could in fact just call one from the 50 and one from the 20. - Model maker would still need 1000 subcircuits, even if they're just wrappers. - That would be the only approach available today. - If, as a group, we say yes to #6 and #7, then we want them separate. - So we would need supply die pads. - If the group says no to that, then they're forced to maintain 1000 subcircuits. - John - In an IBIS file you could have umpteen [Component]s. - Each could refer to a different on-die and different package. - Could avoid all the combinations. - Walter - Randy wants an IBIS file with only one die. - So only one on-die distribution model. - IBIS [Component] is a package with one die. - If you had 20 [Component]s, and therefore 20 packages, do each of them also have to include the on-die model (50 per) or are they separate on-die models? - Particularly important for power distribution. - Need supply die pads to interconnect package and on-die distributions. - Walter - So I'll put "Yes?" on #7. Clearly #8 is yes. - Bob - Question about #8, does it also assume #6? - Walter - No, the ports or terminals of this combined type of package model would be pins and buffers. - Mike - #8 does not preclude #6, does it? You could bring certain things out. - Walter - I think you do #8 or you do #6 and #7. - If you did #8 you would totally ignore the supply die pads. - John - Seems like #8 is something we already have? - Walter - Yes, right now you have a buffer with C_comp, I/V, v(t), and... - No concept of a die interconnect or die power distribution. - John - We're almost there if we had BIRD 145. - Walter - BIRD 145 is one method of implementing it. - The question is, can it do everything you want it to do? - You're saying we don't need any of this if we do BIRD 145? - John - That's not what I'm saying. I'm saying BIRD 145 could almost do it. - Ambrish - With BIRD145 we could say it's a package model. - Walter - With BIRD 125, BIRD 145, or what I'm proposing... - All would preclude the current package parasitics. - Ambrish - BIRD 145 in its current form couldn't do packages. - We could extend it or do a new BIRD. - Walter - If power distribution is in package and on-die then you need supply die pads no matter how it's done. - John - Do we need a way to refer to them independently? - Ambrish - Could a port map with [External Circuit] to that? - Randy - Too cumbersome. - John - [External Circuit] keyword, node mapping, call to it, then call to all the models behind that [External Circuit] interconnect. That's the kicker? - Randy - Yes. - Walter - [Model] has pins, die pads, buffers. - Most common subcircuits between them are s2p for single ended and s4p for differential on the package and the die. - Then you can do SI on the channel much better than with the lumped RLC package. - One common view is that this is what's required. [necessary, but not sufficient] - Someone else may really be into power distribution, someone else crosstalk issues. - If you have a list of pins, pads, buffers, now you can just give subcircuits. - Subcircuits for SI, power, crosstalk effects. - I have pins, pads, buffers, and relationships between them. - Walter - With BIRD 145 you end up with... - A hierarchy of [External Circuit] calls and each calls the models and you end up with different ones for each (relationship approach vs. hierarchy approach). - John - I would not call BIRD 145 hierarchical. - Walter - - If you're only concerned with SI channel in isolation, that works fine. - But now you want to do power or cross talk and you need different subcircuits. - To say one subcircuit will do it for all of them is not realistic. - John - Each side can come up with scenarios in which one is preferable. - Existing solution plus BIRD 145 can do certain things. - How much meta data does the tool need? - Walter - What are IC vendors willing and able to generate? - What do their customers require? - EDA tools have to be able to use them. - IC vendors have to be able to generate them. - They have to solve the customer's problems. - Mike - When you talk about different models needed for complicated power, crosstalk, etc., do you mean different IBIS files? - Walter - No. - Michael Mirmak Example - parameterize a package model, but also want to include cross talk info which is not specific to that pin. - Accurate modeling for each victim and crosstalk. - Other vendors may do no coupling at all. - Some choose to deliver power distribution models, others may not. - Need to see what IC vendors say their customers' needs are. - BIRD 145 may be built around one approach. There may be others it doesn't support. - With relationships - pins, buffers, die pads, and subcircuits to hook them together. - Now EDA tool can do whatever it wants based on the subcircuits provided. - Walter - [moving on to section B. IBIS package enhancements] - Mike - Hold on one second. - We shouldn't spend much time on B, C, D until we settle on A (1-8), right? - Walter - Yes, but I want to cover joins/splits for signals in package and on-die. - Mike - Those should be moved to section A. - Walter - [Adding #9 in A] - Signal joins and splits. - Do they happen often enough that we should add that complexity to the [Component]? - #9 is a "?" - Mike - Should we firm up the "No", "Yes" on 5 and 8? - Walter - We don't have time. - Mike - Should we go through a process to try to achieve closure? - For the ones not resolved, who's prepared to make a pitch one way or the other? - Let's stick with Section A. - Walter - Any objections to the current status of these? [none] - Does anyone request changes to the proponents and opponents? - Brad - Change the note for #6 to say "Enables #7". [done] - Mike - I propose that Walter ask everyone if they're okay with the use of their names. - Walter - If everyone's okay - we can post it. - Everyone seems to be here, but I'll send it out. - If no one objects, Mike will post it. - Mike - John asked for discussion of #3. Next week. - John - We can make an effort via email. - Mike - Thanks everyone for joining. See you next week. ------------- Next meeting: 26 November 2013 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives
Description: S/MIME Cryptographic Signature