Minutes from the 19 Nov 2013 ibis-atm meeting are attached. Thanks to Curtis Clark for an excellent job taking minutes.
Mike
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
