[ibis-macro] Minutes from the 19 & 26 Jun 2012 ibis-atm meetings
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Sun, 1 Jul 2012 19:23:45 -0400
Minutes from the 19 & 26 Jun 2012 ibis-atm meetings are attached.
Thanks to Curtis and Arpad for taking minutes in my absence.
Mike
IBIS Macromodel Task Group
Meeting date: 26 Jun 2012
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
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
Maxim Integrated Products: Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. James Zhou
Sigrity: Brad Brim
Kumar Keshavan
Ken Willis
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
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to submit the following BIRDs to the IBIS Open Forum:
- ParameterTreeKeyword_BIRD_draft4
- BIRD 117.4 draft6
- BIRD 118.3 draft5
- BIRD 116 as 116.1 (last week's "ISS" to "IBIS-ISS" change)
- done
- Arpad & Walter to propose an alternative to using "Labels" to control the
Dependency Table.
- done
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- not done
-------------
New Discussion:
BIRD 150 (Dependency Tables):
- Walter: (sharing BIRD 150.1 Draft)
- There was a request that the string substitution capability be removed.
- Arpad: Just to be clear, I only asked to separate it into a different BIRD.
- Walter: yes, so it's been removed. Separate BIRD will come later.
- New "Usage" Dependency Table.
- Instead of Labels within the Table serving as column headings:
- Two New Reserved Leaf Names
- ParameterNames
- ColumnTypes
- Had to remove the paragraph describing 5.0 and 5.1 compatibility.
- Note that some vendors have used the 5.0 "parser" compatible style.
- Editorial changes including changes to examples to reflect new approach.
- Everything else has been quite stable for a long time.
- Please read it thoroughly so we can discuss it next time.
- Arpad: Is this the document that is posted on the ATM website?
- Walter: Yes.
- David: motion to table this until next time (per Walter's suggestion).
- Arpad: second the motion. (no objections)
Package Modeling Discussion:
- Walter: I sent an email out shortly before the meeting.
- It is consistent with Brad Brim's approach
- It describes a current modeling requirement in the market.
- Arpad: I read it, are your comments related to my presentation?
- Walter: yes
- Walter: sharing IBIS file format model email (example)
- IBIS file has 6 Power Pins and 8 Buffer Pins
- Looking at the Silicon
- same number of buffer pads
- greater number of power pads (4 bump pads per power pin)
- Power distribution modeling in low, med, high frequency.
- David:
- What is the significance of the underscore?
- Walter:
- underscore - ball (pin)
- without underscore pad.
- Walter:
- Low frequency - perhaps 1 power pin node and one pad node.
- High Frequency - 6 pin nodes and 24 power pad nodes.
- Med Frequency - 2 pin nodes and 6 power pad nodes.
- Could depend on how the EDA tool extracts the model.
- Walter:
- Similar problems on die.
- Multiple buffers
- Low frequency - 1 power pad, 1 buffer pad
- High frequency - 24 power pads, 8 buffer pads.
- May even provide multiple power models and package "slices".
- Brad Brim, Sigrity, Cadence, IC and package vendors have a solution.
- Model Connection Protocol - standard for one die and package power models.
- comment characters in HSPICE provide the syntax a tool can read and use.
- subcircuit advertises how it is to be used and connected.
- Real world example as SiSoft has done it.
- I recommend that we not include the package distribution model in IBIS.
- Arpad: Are these model variants supposed to be:
- separate models to be selected by a "model selector" type arrangement or
- a single model which supports "compression" or "expansion" capabilities
like swathing, to cover the various levels of simulation conditions?
- Walter: The way we do it you select a subcircuit to use for power
- The user makes the choice of which subcircuit to use for given conditions.
- Opportunity for IBIS is to utilize MCP.
- I don't like many things about the MCP syntax, but it does work.
- With MCP you drop models into your netlist.
- Michael: Do you foresee this coming from model makers, or made by EDA tools?
- Walter: I would expect with Sigrity's tool to press a button and have it
generate this model.
- EDA tools make their models via extraction, measurement, etc.
- put the model in a subcircuit
- perhaps generated automatically.
- Michael: I'm having a tough time envisioning manual creation of these.
- Does the end user care about this?
- Walter: Model makers, IC vendors, systems integrators care.
- Model makers care about what is exposed.
- A consortium of IC vendors came up with this to define how to connect.
- Somewhat painful process about a year ago as MCP was discussed.
- This example was trying to illustrate some of what came out of that.
Move on to Arpad's Presentation on this topic:
- Arpad: (sharing his power point presentation)
- Summary of where we are now (last week's discussion)
- BIRD 116-118 review
- Legacy overview
- Important point - IBIS does not declare pads on the die.
- Current state of BIRD 125
- Introduces Die_Port_Names
- [Package Circuit] provides IBIS-ISS description.
- David: Do we have that functionality already with Signal Names in the [Pin]?
- Arpad: Use Signal Name column for that purpose?
- My first reaction is that it might be dangerous, not sure.
- David: I would recommend a new column instead of repeating "Die_Port_Name="
- Arpad: Okay, I'm open to syntax suggestions once we get through this.
- Michael: Sorry, another syntax question:
- Are you saying even the [Pin] keyword could have a new column?
- Are you ruling this out?
- Arpad: If it's okay I'd like to hold syntax questions for now.
- Arpad: (sharing picture of the "famous Figure #12" from the IBIS spec)
- This example is famous because we had a lot of discussions on it when
trying to implement it with ICM.
- How do we declare [Model] power terminal connections to specific pins?
- Extend the use of [Pin Mapping] keyword.
- Modified Figure #12 explicitly showing power and ground connections.
- Arpad: Major issue with legacy IBIS:
- Only one way to define the buffer model for a pin.
- If a pin is tied to multiple buffers, how do we handle it?
- Similar problem arises if multiple signal pins feed one buffer.
- Now we also need on die interconnect.
- Legacy IBIS one-to-one pin to buffer is useful for some things.
- identify which [Model] is used on a net for a PCB layout or IC footprint
- can't be abandoned entirely.
- Best solution for instantiating [Model]s might follow [External Circuit]:
- use a [Model Call] syntax analogous to the existing [Circuit Call].
- Allows multiple [Model]s to be instantiated per pin.
- Provides named terminal definitions.
- Doesn't rely on the cumbersome [Pin Mapping] syntax.
- [Node Declarations] can define nodes on either side of the on-die
interconnect model.
- No need for one to one legacy scheme.
- Michael: That's a nice diagram, very helpful.
- Is this different than what a "clean sheet of paper" would produce.
- If you started with pins, pads, packages, buffers, would you come up with
this?
- Arpad: Interesting question.
- I started with a "clean sheet" approach and ended up with these legacy
keywords.
- Their use did not seem to be stretched.
- I started with a solution similar to the SPICE X-element syntax.
- We could consider that, but it seemed that this syntax provides everything
we need with the least amount of change, and everything shown here is
covered
by BIRDs 116, 125 and 145.
- Walter: My email focused only on power distribution on die.
- Signaling is an independent problem not addressed in my example email.
- I think your scheme might work for a single package model.
- In practice it won't work or will be very cumbersome for multiple models.
- Arpad: Okay, we're out of time.
- Arpad: What should we do about next week's meeting (July 3)?
- Will people not be attending?
- Michael: I think we should cancel it.
- Arpad: Next week's meeting is canceled.
-------------
Next meeting: 10 Jul 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 19 Jun 2012
Members (asterisk for those attending):
Agilent: * Fangyi Rao
Radek Biernacki
Altera: David Banas
Andrew Joy Consulting: * Andy Joy
Ansys: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
Ambrish Varma
Feras Al-Hawari
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: Michael Mirmak
LSI Logic: Wenyi Jin
Maxim Integrated Products: Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: Randy Wolff
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. James Zhou
Sigrity: Brad Brim
Kumar Keshavan
Ken Willis
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
The meeting was lead by Arpad Muranyi
------------------------------------------------------------------------
Opens:
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad & Walter to propose alternative to "Labels" as Dependency Table control
- in progress
- Arpad to write a new revision of BIRD 117 and 118 to generalize references
to parameters in files (.ami or any)
- in progress
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- not done
-------------
New Discussion:
Parameter Tree Keyword BIRD draft 4 discussion:
- Arpad: The draft now contains the fixed parenthesis and description.
- These changes were made during last week's meeting, nothing new.
- I would like to discuss this and perhaps vote to send it to the Open Forum.
- Get an official BIRD # assigned.
- <no discussion or questions forthcoming>
- Eckhard: motion to vote to submit it to the Open Forum.
- Arpad: second the motion.
- Walter: I have no objections to this proposal.
- Arpad: Are there any objections?
- <none forthcoming> Unanimous approval.
BIRD 117.4 draft 6 and BIRD 118.3 draft 5 discussion:
- Arpad: The draft now contains the fixed parenthesis and description.
- Summarize the overall changes:
- Generalized parameter file references. No longer exclusive to AMI models.
- Generalized [External Model] and [External Circuit] parameters from AMI
style parameter trees.
- This led to another idea, submitted in the BIRD draft we just voted on,
to allow the tree in the IBIS file.
- <no discussion or questions forthcoming>
- Curtis: motion to vote to submit them to the Open Forum.
- Eckhard: second the motion.
- Arpad: Are there any objections?
- <none forthcoming> Unanimous approval.
BIRD 116 discussion:
- Arpad: Summarize the changes:
- Simply added IBIS-ISS as a supported language.
- We call it "IBIS-ISS" in the description, but use "ISS" in language names.
- Should we call it "IBIS-ISS" or "ISS"?
- Walter: I'd like to restate:
- I fully support this proposal.
- At some point in the Open Forum process I will draft ISS reference circuits.
- These will correspond to the reference topologies from BIRD 122.
- At that point I will then recommend that BIRD 122 be rejected.
- Walter: I think we should use "IBIS-ISS"
- Arpad: I'll make a version with the "IBIS-ISS" change.
- Could we vote to submit that version I will create?
- Walter: motion to vote on the modified version.
- Dan: second the motion.
- Arpad: Are there any objections?
- <none forthcoming> Unanimous approval.
BIRD 150 discussion:
- Arpad: Walter mentioned before the meeting that he was not quite ready.
- I'll keep this on the agenda for next week.
- Walter: Hopefully I'll have something ready by then.
BIRD 125 Package Modeling discussion:
- Arpad: <shared "IBIS-AMI Analog Modeling" power point presentation>
- I've pulled together enough to get started.
- We should get started as this is our next big topic.
- This can be used to document our discussions.
- I've updated this to reflect the latest parameter tree and file BIRDs.
- Grayed out the AMI keyword section.
- BIRD 116 introduced use of IBIS-ISS.
- BIRD 125 also uses IBIS-ISS.
- Summarizes legacy package model handling. "Miraculous" connections rely on:
- Implicit die pads with a one-to-one pin to pad relationship.
- [Pin] names in IBIS file must match [Pin Numbers] names in .pkg file.
- BIRD 125 proposes a second column under [Pin Numbers] for die pad.
- IDP_<pin name> is an implicit die pad. ISS subcircuit needs a die node.
- Explicit pad2 example. Node on die declared by [Node Declaration] keyword
in legacy IBIS.
- [Package Circuit] keyword defines the ISS circuit.
- Simple Example, all implicit pads.
- nodes 5, 6, 7, 8 on one side and IDP_8, IDP_7, IDP_6, IDP_5 on the other.
- More complicated example, number of pads and pins don't match.
- Use [Node Declaration] to define pad node names.
- Walter: I think I understand what you're doing, and I think it is okay.
- I'd like to describe what I think we need to deal with:
- Signal line might have one pin to multiple buffers.
- Power, however, might have 10 pins to 20 pads and vice-versa.
- In reality it might be even more like 100 pins to 500 pads.
- Need a power distribution model for the package.
- On die, high frequency, wavelength < chip size.
- Package power distribution model for certain subsets of the pads.
- On die power models between pads.
- Extend the scheme to handle:
- which buffers attach to which ports on the on-die model
- which die pads go to which ports on the power distribution package.
- Arpad: I agree.
- I have one problem to highlight that is not yet written up here.
- Problem: Legacy IBIS the [Pin] goes to the buffer model.
- Okay with a one-to-one pin to pad mapping.
- Two different pads might have two entirely different buffer models.
- If we need the signal on a pin to join or split to get to a pad... trouble.
- Walter: I believe there is a solution available.
- We could introduce a Model Connection Protocol wrapper.
- We could use a parameter tree syntax to define connections such as:
- One port on a subcircuit goes to -> these pins on the package.
- One port on a subcircuit goes to -> these ports on die side.
- One more layer of abstraction.
- On die power distribution defines buffers attached.
- Port info in wrappers for package and on-die models.
- MCP by Brad Brim, while I have objections to its format, could be applied.
- Arpad: Introduce a Pad keyword similar to the [Pin] keyword.
- It would associate a pad on the die with a buffer.
- Simpler?
- Walter: Perhaps.
- Let's make real examples.
- Then we can try various techniques on the real examples.
- We can look at on-die power and go to IC vendors for their input.
- We can look at package power modeling and go to package vendors and others.
- Get their input on whether the models are buildable and useful.
- Arpad: If we go to buffers <-> pad then we need a new keyword.
- Walter: I think changes to legacy IBIS should be very conservative.
- If we can stay outside IBIS in the package model it is preferable.
- Creating power distribution models these days is a science project.
- expensive, may not want to give out the details
- that information might not belong in the IBIS file.
- Arpad: Okay, I think this is a good stopping point for this week.
- Walter: I think we should ask Brad Brim to join in.
- Arpad: Good idea.
- Walter: I've described what SiSoft wants.
- Arpad: Oh, I see, get early feedback from people.
- Walter: We need to see other opinions.
- We might all be myopic in seeing only our customer's needs.
- Arpad: I will create an "invitation" email to encourage people to attend.
-------------
Next meeting: 26 Jun 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
- » [ibis-macro] Minutes from the 19 & 26 Jun 2012 ibis-atm meetings - Mike LaBonte
