Minutes from the 07 July 2015 ibis-atm meeting are attached.
The following document presented during today's meeting has been posted to
the work archive:
*DATE*AUTHOR <http://www.eda.org/ibis/macromodel_wip/archive-author.html>
ORGANIZATION <http://www.eda.org/ibis/macromodel_wip/archive-org.html>TITLE
<http://www.eda.org/ibis/macromodel_wip/archive-title.html>FORMATS
07-JUL-2015Walter KatzSiSoftBuffer Rail Mapping Ground in Legacy Package
Models(zip
<http://www.eda.org/ibis/macromodel_wip/archive/20150707/walterkatz/Buffer_Rail_Mapping_Ground_in_Legacy_Package_Models.zip>
)(pdf
<http://www.eda.org/ibis/macromodel_wip/archive/20150707/walterkatz/Buffer%20Rail%20Mapping%20Ground%20in%20Legacy%20Package%20Models/Buffer_Rail_Mapping_PKG_Ground.pdf>
)
IBIS Macromodel Task Group
Meeting date: 07 July 2015
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Avago (LSI) Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
IBM Steve Parker
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
Radek Biernacki
Nicholas Tzou
Maxim Integrated Products: Hassan Rafat
Mentor Graphics: * John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
QLogic Corp. James Zhou
Andy Joy
SiSoft: * Walter Katz
Todd Westerhoff
* Mike LaBonte
Synopsys Rita Horner
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
(Note: Agilent has changed to Keysight)
The meeting was led by Arpad Muranyi.
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad to contact Romi Mayder regarding BIRD 157.
- Done. The BIRD is no longer considered important.
- Walter to send his "GND BIRD" presentation to the reflector.
- Done.
- Mike LaBonte to post the "GND BIRD" presentation.
- Done.
- Arpad to send an email to the reflector regarding EDA vendor input on C_comp
not being connected to node 0.
- Done.
- Walter to forward/reply Arpad's email privately to Zuken and Synopsis to
ensure they get the request for input.
- Done.
-------------------------
Review of Meeting Minutes:
- Curtis: I received no comments or corrections for last week's minutes.
- Arpad: Does anyone have any comments or corrections? [none]
- The minutes are approved.
-------------
New Discussion:
LTI analog models for AMI:
- Arpad/Bob/Walter: Defer until Scott McMorrow can join us.
GND cleanup in IBIS:
- Arpad:
- We have a draft 3 of a document on this topic.
- Draft 3 is not yet posted to the ATM website. Should it be?
- Walter: No.
- That document is no longer needed.
- Superseded by the Ground presentation from last week.
- Clear decision, unanimous amongst those who responded to last week's "C_comp
not connected to node 0" question.
- Wait until 6.1 is finished. Then create a 6.2 to address Ground issues.
- Arpad: No need to post draft 3 then.
- Mentor is the one EDA company yet to confirm the C_comp connection question.
- I personally agree that C_comp should not be connected to node_0.
- Just need to confirm with my colleagues.
- Walter: [sharing "Buffer Rail Mapping Ground in Legacy Package Models"]
- We have made our decision for C_comp.
- What about legacy RLC [Package] and [Pin] models? Where is C connected?
- For [Define Package Model], capacitors and implied W-elements need a
reference node. Nothing in IBIS says where to hook them up.
- I think the correct answer is what we did for C_comp.
- An RLC model on a particular pin, C should be hooked to the same local
ground that the [Pin]'s [Model] is hooked up to.
- For a legacy package model you need to be able to figure out what the ground
clamp reference or pull down reference is.
- [Buffer Rail Mapping] makes this much easier.
- New keyword in IBIS interconnect proposal.
- Similar to [Pin Mapping], but it simplifies it dramatically.
- [Pin] has a signal_name column. Signal_name is a data book name.
- If two [Pin]s have the same signal_name (e.g. VDD), they're connected.
- The signal_names replace the concept of bus names from [Pin Mapping].
- [Pin]s with [Model] names POWER or GND that have the same signal_name are
connected.
- [Buffer Rail Mapping] provides the names of all the connections you need
to pass to the package models, and you can avoid using node 0 anywhere.
- A [Model] has a "Local Circuit Reference Node".
- Either A_pdref of A_gcref using [External Model] naming conventions.
- [Buffer Rail Mapping] defines the signal_name connected to A_pdref or
A_gcref.
- Ground in package and on-de interconnect models for I/O buffers should be
connected to this "I/O Buffer Model Reference signal_name."
- Bob: A_pdref and A_gcref can coexist legally within an Output or I/O buffer.
- Walter: Could you provide an example?
- Bob: Not right now. But it's still legal.
- What do we do if we have a difference?
- Walter: If they coexist with different values, then you are out of luck for
dealing with a legacy package model.
- Walter:
- RLC Package to ground:
- IBIS is silent on which ground to connect to the C.
- It should go to the local ground.
- We could state explicitly, 'The Capacitor of an I/O Buffer [Pin] Package
RLC should be connected to the "I/O Buffer Model Reference signal_name".'
- One C_pkg Reference to Ground:
- IBIS terminator [Model] diagram shows C_pkg connected to GND.
- Shows C_comp hooked up to the same GND node.
- So this is consistent and makes sense. We hook C_pkg up to the same
local ground as C_comp.
- Bob: I agree.
- Walter:
- [Define Package Model] with "Sections" to Ground:
- IBIS is silent on which ground to connect to a C or RLC section.
- The C, and W-element lines should also be referenced to "I/O Buffer Model
Reference signal_name".
- [Define Package Model] with "Matrices" to Ground:
- Gets complicated if the [Pin]s don't share a common reference signal_name.
- What if there is an off diagonal matrix element between two [Pin]s that
have different I/O Buffer Model Reference signal_names?
- Perhaps there's no correct solution for that with RLC matrices.
- Could be hard to address for legacy models.
- All these issues go away with the new interconnect modeling.
- All the appropriate references can be passed in to avoid these issues.
- Should that be required, for interconnect modeling, however?
- Is it really necessary?
- We know the errors introduced by hooking C_comp to node 0 are
significant for real examples.
- But what about using node 0 as a reference for a W-element in a package
model? Has anyone shown that introduces meaningful errors?
- When we get to IBIS 6.2, do we want to bother trying to solve all the issues
for legacy package models? I think not, but what do others think?
- Bob: The issue is that there's a reference at each end of a W-element, right?
- We could connect ends of a W-element to two different local references.
- Walter: Yes. Imagine a single W-element from Pin to buffer.
- One end referenced to VSS at the Pin, the other to VSS at the die.
- Arpad: Is that the correct interpretation of the W-element reference?
- Those ground plane connections would be handled by another conductor node.
- Those are different from the W-element's reference node. The current on
that ground plane wouldn't go through the W-element's reference.
- Walter: The W-element line I'm used to in such a case would have 4 terminals.
- One at the Pin, one at node 0, and one at the Pad, and one at node 0.
- In my subcircuit for that package I would have node 0.
- Big debate in the interconnect group was if we should forbid node 0 in IBIS
ISS subcircuits for interconnect models.
- C_comp hooked up to node 0 showed differences in the tens of mV.
- W-element hooked up to node 0, I saw more like .1mV differences.
- Do we need to forbid node 0 in interconnect models?
- Brad Brim lobbied strongly to forbid it.
- Vote was close, but at the time we decided not to forbid it.
- Arpad: We might need to discuss it when other experts are here.
- Bob: We might still recommend local reference nodes and leave it at that.
- Walter: If you had a pulldown resistor in your package model, then it would
really be important to hook it up to the local reference node. In
that case using node 0 might introduce serious differences.
- Do we really care to deal with all these issues in 6.2?
- We are doing the new interconnect modeling scheme to deal with all these
issues.
- Maybe in 6.2 we just say for legacy models you connect C to the local
reference node if you can figure out which one it is.
- Arpad: Should we extend this discussion to EBD as well?
- Walter: Yes.
- Maybe we just say this is a limitation of legacy EBD and package models?
- IBIS ISS interconnect will take care of it for components and eventually for
EBD as well.
- Arpad: It may be slightly different for EBD vs. package.
- When IBIS was started in the 1990s, the board's ground plane was considered
a fairly solid reference.
- When the EBD spec was developed, it might have considered the board's ground
plane a solid reference for the transmission lines above it.
- For package it's a bit different, and the package usually has its own ground
plane that might be less solid.
- It could be a tricky question.
- Walter: I think it's tricky and probably not worth the effort to resolve it.
- None of this matters in a non-power-aware simulation.
- You can have a power aware simulation where ground is not floating and all
variation is in the power rail.
- But if you want to do serious power aware simulations you can get into lots
of trouble using legacy package models and EBD.
- Bob: Given all this, we should leave it as is with a general recommendation to
use local ground.
- Walter: That's my conclusion and recommendation.
- Arpad: Any other comments on this topic? [none]
- Any other topics? [none]
- Let us close today's meeting.
- Thank you all for joining.
AR: Walter to send his "Buffer Rail Mapping Ground in Legacy Package Models"
presentation to Mike LaBonte to post.
AR: Mike LaBonte to post Walter's presentation.
-------------
Next meeting: 14 July 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
