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

  • From: Mike LaBonte <mike@xxxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Wed, 27 Nov 2013 13:02:11 -0500

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

IBIS Macromodel Task Group

Meeting date: 26 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 (ML).


- None

Call for patent disclosure:

- None

Review of ARs:

- Spreadsheet discussed last week
  - Walter to contact listed parties to make sure use of their names was okay.
  - A few names were removed, and the spreadsheet was posted to the work 
archive. (done)

New Discussion:

- ML - I planned on starting with item #5 again (IBIS [Component] changes).
  - The spreadsheet was posted with very slight adjustments.
  - Walter has brought it one step further.
  - I'll pass control to Walter if there are no objections.

- Walter - [sharing updated spreadsheet and a new email]
  - I've made minor reference changes and moved some rows in the spreadsheet.
  - Major item for this discussion is the new ["AA"] section.
    - We were talking last week about detail changes to [Component].
    - I wanted to go back and say, "What are the shortcomings of IBIS for 
      - 1. Connectors
      - 2. Cables
      - 3. Broadband EBD
      - 4. MCM
      - 5. Interposers
      - 6. 3-D Structures
      - 7. Stacked Memory
      - 8. RDL
      - 9. Broadband I/O Package Modeling.
      -10. Package Power Distribution Network (PDN).
      -11. Broadband I/O On-Die Modeling.
      -12. On-Die PDN.
      -13. Interconnect coupling (cross-talk) between I/O and I/O.
      -14. Interconnect coupling between I/O and PDN.
  - I made this list 4 years ago, and started on EMD to solve it.
  - That got sidetracked because we needed IBIS-ISS.  So we did that.
  - Now I have a proposal for EMD that can handle these.
  - Now, for historical reasons, we have objections that lead to "Can we do it 
  - Does anyone object to this list of shortcomings?
  - Does anyone think there are other interconnect shortcomings?
- ML - One Question, do we really want to solve every problem related to 
- Walter - Yes, that is a question.
  - But first, do we currently agree that an IC vendor has no way of generating 
    broadband interconnect model an EDA tool can just run?
  - An IBIS-ISS subcircuit can be created, but not just dropped into the EDA 
- MM - Clarification question - You're saying "IBIS" generally?
  - Any spec managed by the organization, or just the IBIS document itself?
- Walter - On the top of the document I wrote, "IBIS.org" [entire organization].
- Ambrish - SPICE can solve them, why do we need to know if IBIS can handle 
- Walter
  - I totally agree that someone can do an IBIS-ISS subset SPICE circuit to 
    each of them.
- Bob - If that's true then the answer based on the clarification question is 
  - IBIS-ISS and touchstone both do parts of it.
- Walter - Can I generate an IBIS [Component] that will do it?
  - ex. I can do a non-broadband EBD.
  - ex. For [Component] I can't just generate an IBIS [Component] model.
    - I can generate subcircuits, but not the whole model.
- John - You can do everything except the connections.
- MM - Exactly.  Bits and pieces and say, "Hey, the tool vendor will figure it 
  - Walter is saying there's nothing where everything is self-contained and 
  - It's not just IBIS.org, it's IBIS.org things tied together in an automated 
- Ambrish - We should do this, but it should not be in the IBIS spec itself.
- MM - Clarify - You're okay with having some other specification for that?
- Ambrish - Yes.  IBIS is for buffers, and was stretched to accommodate package.
  - Now we don't want to stretch it accommodate cables, connectors, etc.
- ML - We didn't mind stretching it for package, but now...?
- Walter - The three questions in my email are pertinent.
  - 1.  Does IBIS want to create standards for IC Vendors to deliver 
interconnect models
        that satisfy any, some or all of the requirements (shortcomings) listed 
  - Michael [Mirmak]'s comments are good clarification of this question.
  - Meaning, provide models so a tool can tie it all together with simple drop 
down box.
  - Ambrish is saying the answer is yes, at least for most items on the list.
  - If so, I make an observation that we created EMD to do all of these.
  - That leads to question 2.
  - 2. Is EMD sufficient by itself or should we do some by enhancing 
  - 3. Which things, if any, should be done in IBIS [Component]?
  - Can we get agreement that we should answer these questions before 
  - Comments?
- John - I believe this is the right way to organize the discussion.
  - Features vs. functional implementation.
- Walter - Any objections?
- Ambrish - I don't understand your interpretation of what I said.
  - I believe we should not be going to 1, 2, 3, 4, .. in your list and trying 
    extend IBIS to do it.
- Randy - I don't think anyone wants to do this.
- John - Is this the right question?  I think it is.
- Walter - You're saying "not in .ibs".
- Ambrish - Yes.
- Walter - I don't think anyone wants that.
- Ambrish - 7 through 13 is "Yes" in .ibs.
- Walter - Do we agree IBIS should have a solution for connectors?
- Ambrish - IBIS?
- Walter - Meaning the IBIS collection of specs, not just .ibs.
- MM - Does anyone really truly desire having the formal IBIS document be 
  - Is that what anyone wants? [implied "No"].
  - If we're just saying these are desirable features and can be included in 
    document then, sure, the discussion can move right along.
- Walter - So email question #1, the answer is yes.
  - We need a way for IC vendors to do this.
  - EMD can handle all this.
  - What portion do we want to do in .ibs?
    - One comment from Ambrish: 5, 7-13 are "Yes" in .ibs.
- Ambrish - Isn't SPICE already able to do all this?
  - Aren't we discounting the fact that tools can do this if we drop them 
[models] in?
- ML - SPICE is not plug-and-play.  Always have data layered on top to organize 
- MM - SPICE is not standard except for IBIS-ISS.
- Ambrish - IBIS-ISS and touchstone provide support for standardized models.
- MM - Whole portions of the industry are saying that for complicated systems 
it's the
       connections between these blocks that are really the problem.
  - We can't leave that to the user.
  - If we just say SPICE can do it and it's up to the tool user...[that's 
- ML - These days, if someone says SPICE I just think IBIS-ISS.
- John - Same here.
- MM - Need to mention a specific SPICE if you're talking top-level netlist.
- ML - Need to specify.  Just saying SPICE can do it isn't helpful.
- ML - [to Walter] - Since we're going to archive this spreadsheet, could you 
       IBIS.org to "IBIS family"?
- Ambrish - We have touchstone, IBIS, IBIS-ISS, anything else?
- MM - EBD, package, ICM - superseded by IBIS-ISS.
- ML - By something using IBIS-ISS.  I haven't written off ICM completely yet.
- ML - So the purpose of adding section "AA" is...
  - A different view point of what we had in "A"?
  - Is it sort of a binary decision, in or out of the .ibs file?
- Walter - No, it's a pre-cursor.
  - It's silly to talk about all that stuff in "A" if we haven't decided to do 
    things in "AA".
  - I point out that EMD was designed to do all of these things.
  - I think that if we agree on this list...
    - And I want to make sure I didn't miss anything.  Did I miss anything?
      - Do we want to do Optical Interconnects?
- Ambrish - What about 3D ICs, multi-die, more complicated stuff?
- Walter - MCM, interposers, RDL, stacked memory...MCM in general handles all 
  - Already taken care of, but useful to explicitly say it.
- John - EBD models boards, but you could talk more about direct geometry of 
  - Answer may be, "No we don't want to..." but...
- ML - I think Optical Interconnect is worth adding.
  - It has been discussed at IBIS summits, so people are interested in it.
- Walter - [adding it as item #15] - Yes, we should have it on the radar.
- ML - Probably not in .ibs, but who knows.
- ML - Is it correct that all the items in list "A" overlap with all the items 
in "AA"
       that say "in .ibs"?
- Walter - 
  - There is debate about "stacked memory," but all others seem to be "in .ibs".
  - If we answer the stacked memory question then we can start matching up the 
- ML - I'm saying it's interesting to look at it from the point of view of all 
of the
       "in .ibs" vs. "not in .ibs".
  - So it looks like we've already started down the path of working on what's 
"in .ibs".
- John - I think .ibs vs. EMD is jumping the gun.
  - Let's go over the list of enhancements first.
- Walter - I'd like to resolve the one contentious issue from last week.
  - Stacked Memory - John sent out an excellent email.
  - Gist of the email:
    - IBIS is traditionally one pin, one buffer (ignoring power pins, just 
signal pins).
    - There are a bunch of EDA tools that may rely on that one-to-one 
    - I answered John privately, but my answer was basically:
      - "I don't care whether it's associated with 'stacked memory' in a .ibs, 
or .emd,
        or .ebd".
      - SiSoft doesn't care.  We'll deal with whatever IBIS chooses to support.
      - There are other EDA vendors here who have a lot of weight because they 
will have
        to support it.
     - IC vendors may still do it any way they want.
   - I didn't see any other responses to John's email.
- John - I got no other private responses.
  - Yes, you described the issue fully.
  - It's not tradition just because we like tradition.
  - This assumption is hard-coded into many tools.
  - We can deal with this as well and make these changes.
  - There are lots of consequences.
  - We are today already using models that do stacked die with EBD.
  - Downside for the IC vendor is to release a model with an EBD and a .ibs 
  - When we're doing a broadband model we've got to have an accompanying 
    subcircuit file as well.  So the addition of one more file is not a serious
  - Since we'll be investing a lot in the EMD side for all the other 
capabilities, how
    much work do we invest to deal with breaking this hard coded assumption vs. 
how much
    do we invest in the new capability.
- Walter - If we choose stacked memory as "not in .ibs" and use EMD and EBD 
  - If that is a decision, all of the things in "A" marked xxx fall into that 
    - No joins or splits in the die or the package.
- John - In the pads going to the I/O buffers.
- Walter - No joins, splits, MCM, stacked,...
  - We're just going to say that if you have these situations you go to EMD, 
and now
    we have to focus on package and on-die modeling.
  - Randy may object.
- Randy - I'm fully in support of everything you just talked about.
  - Stacked memory in a .ibs file is a book keeping thing.
  - After listening to what John has been saying, it probably doesn't make 
sense to come
    up with two solutions and make EDA vendors write a lot more code.
  - In the end, I just want a solution customers can use and if the models are 
in EMD
    format we can deal with that for stacked memory.
- ML - In the same place as MCM.
- Randy - Yes, no special case.  Same as every other multi-die situation.
- Walter - No objections that stacked memory is not included in the .ibs file?
- ML - So those "xxx" are proposed "No" now?
- John - They go away in the .ibs context.  Working on them in EMD context.
- Walter - Only thing not resolved...
  - Note - terminology (signal = I/O, supply = PDN).
  - Do we need to enhance [Component] to include a list of die pads?
- ML - From the list above, it looks like the answer is "yes."
- Walter - Not necessarily.
  - The list above says we will support it, but how?
    - One way is to say - Yeah, I can have 10 pins of Vdd but I assume at the 
pads of
      the die they're all shorted together - maybe different at the buffers.  
      distribution within the buffers.
    - Or, if I were to represent PDN separately on-die and package and merge at 
      die pads, I could choose to combine on-die and package and just have PDN 
all the
      way between the pins and buffers.
    - Those are two options where you don't need supply die pads.
  - My gut feeling is that we need this and the enhancement to [Component] is 
  - Does anyone say, "No, we should not have a list of pads..."?
- John - I think we need that in some form.
  - We have to look at what [Component] needs to do.
  - We need to look at what we need to do to avoid the extra layer of 
indirection of
    wrapper subcircuits to combine them [on-die and package distribution 
- Walter - And requirements would be that package and on-die models have to use 
them            [list of pads].
  - Any objections to taking the question mark of this item?
- Bob - Assumption is we still support one-to-one mapping.
  - [Pin Mapping] keyword can give the same information.
- Walter - [Pin Mapping] is fundamentally flawed.
  - It associates pins with buffers.  It's flawed and has nothing to do with 
the physics
    of a PDN.
- ML - It sort of leaves out the middle.
- MM - It assumes an ideal short.
  - How much of the original scheme needs to be preserved?
  - Keep [Pin Mapping] around if people want to use it.
    - But don't try to accommodate it in the new scheme.
- Walter - [noting in item A6 the restriction MM just described]
  - I think it's a wrap.
- Ambrish - I think you could remove Brad as a proponent.
- Walter - No, he's okay with it.
  - I also put him as "opponent" temporarily as a joke because he had mentioned 
that you
    could avoid it if you wanted to combine them all [on-die and package]."
- ML - Concerning BIRD161, should that be left blank so it doesn't appear to be 
a vote?
  - May not want to bring it up right this minute.
  - May want to wait for Arpad to return.
  - It seems like having had all these discussions we should have less trouble 
    past this one.
- MM - I don't care if it gets ditched or accepted.
  - As long as we're clear about whether existing keywords are expected to work 
with it.
- Walter - An IBIS file with just one Tx and one Rx [ex. seen with some AMI 
  - May or may not have package or on-die models, but isn't a real component.
  - Adding some switches (like BIRD 161) that tell the tool, "this isn't a real
    component, it's just a..."
  - Some tweaking of BIRD 161 might be appropriate.
- Walter - I think we've made tremendous progress.
  - Five minutes left, I just want to review something else, item "B", "RDL".
    - RDL - added to chip, often added by package vendor.
      - Common practice is if there's an R included in the interconnect from 
the RDL
        it is put in the package model, or it could be put in the on-die model.
    - I think everyone here said, No.
      - We don't want to add another section to IBIS to have one for package, 
        on-die and an RDL layer.
      - Put it all in the package or on-die model.
- Walter - We can review the IBIS syntax I offered for "A6" (supply die pads)?
- Walter - I plan on taking a memory chip model we've been using as an example 
           doing various package and on-die models based on what Randy has done.
- ML - BIRD 125, BIRD 145, or EMD?
- Walter - I did them in EBD, but now that we're focusing on functionality I'm 
           to take this simple memory component and generate PDN and I/O 
package and
           on-die subcircuits...
  - I want to go back to item 14 [interconnect coupling between I/O and PDN] 
    that will complicate those examples.
  - I'd like to end the meeting by discussing 14.
- ML - Wait, you'll create EMD like examples for those things?
- Walter - Yes, and BIRD 125 and BIRD 145 proponents can generate examples for 
- John - That's a reasonable way to go ahead.
- ML - It would be cool if your examples can be done soon enough to consider 
C1, C2
       [EMD vs. BIRD125 for package models] and D1, D2 [EMD vs. BIRD145 for 
  - Probably too late with the short week.
- Walter - I can have them done this week.
- ML - They can be generated using EMD-like format.
  - We'll review them and ask others to generate similar examples using BIRD 
125 and BIRD 145.

AR: Walter produce new syntax examples using EMD-like format

- Walter - One last topic - item 14.
  - We need to have cross-talk, which is coupling between I/O and I/O.
  - Do we need to have coupling between the PDN and signaling (I/O)?
    - We certainly have coupling in the simulation (PDN affects voltage buffer 
    - But do we need coupling in the interconnect model?
    - Coupling between the PDN and the signal in the interconnect model?

- ML - Okay, any final comments before we close this meeting? [none]
  - Thanks everyone for joining.  See you next week.

Next meeting: 3 December 2013 12:00pm PT

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

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