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

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Wed, 20 Nov 2013 12:49:51 -0500

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


- 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 
  - [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 
  - status, opponents, proponents, etc.
- Walter - The syntax column: Yes means there is a proposed IBIS syntax for the 
- 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 
- 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 
- 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 
  - 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 
      to make these up.  We need supply die pads.
    - If we decide not to do this then we can't support independent package and 
- 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 
- 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 
- Walter - True.
  - Suppose we have 50 on-die interconnect models, and using some package tool 
    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 
  - Those subcircuits could in fact just call one from the 50 and one from the 
  - Model maker would still need 1000 subcircuits, even if they're just 
  - 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 
- 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 
         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 
  - One common view is that this is what's required. [necessary, but not 
  - Someone else may really be into power distribution, someone else crosstalk 
  - If you have a list of pins, pads, buffers, now you can just give 
  - 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 
  - 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, 
         etc., do you mean different IBIS files?
- Walter - No.
  - Michael Mirmak Example - parameterize a package model, but also want to 
    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 
  - With relationships - pins, buffers, die pads, and subcircuits to hook them 
  - 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 
- 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 
  - #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 
  - 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

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

Other related posts:

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