Minutes from the 26 Nov 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for taking minutes.
Mike
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).
------------------------------------------------------------------------
Opens:
- 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
interconnect?"
- 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
with
[Component]?"
- 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
interconnect?
- Walter - Yes, that is a question.
- But first, do we currently agree that an IC vendor has no way of generating
a
broadband interconnect model an EDA tool can just run?
- An IBIS-ISS subcircuit can be created, but not just dropped into the EDA
tool.
- 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
them?
- Walter
- I totally agree that someone can do an IBIS-ISS subset SPICE circuit to
represent
each of them.
- Bob - If that's true then the answer based on the clarification question is
yes.
- 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
out.."
- Walter is saying there's nothing where everything is self-contained and
connected.
- It's not just IBIS.org, it's IBIS.org things tied together in an automated
way.
- 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
above?
- 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
[Component]?
- 3. Which things, if any, should be done in IBIS [Component]?
- Can we get agreement that we should answer these questions before
proceeding?
- 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
to
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
overarching?
- Is that what anyone wants? [implied "No"].
- If we're just saying these are desirable features and can be included in
another
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
it.
- 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
insufficient].
- 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
change
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
the
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
3D.
- Already taken care of, but useful to explicitly say it.
- John - EBD models boards, but you could talk more about direct geometry of
boards.
- 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
items.
- 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
assumption.
- 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
file.
- When we're doing a broadband model we've got to have an accompanying
IBIS-ISS
subcircuit file as well. So the addition of one more file is not a serious
disadvantage.
- 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
instead...
- If that is a decision, all of the things in "A" marked xxx fall into that
category.
- 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.
Power
distribution within the buffers.
- Or, if I were to represent PDN separately on-die and package and merge at
the
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
relatively
straightforward.
- 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
models]".
- 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
getting
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
models]:
- 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,
and
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
and
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
going
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]
because
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
those.
- 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
on-die
models].
- 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
sees).
- 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
