Minutes from the 09 June 2015 ibis-atm meeting are attached. The following
document, which was presented during the 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
09-JUN-2015Walter KatzSiSoftC_comp in IBIS(zip
<http://www.eda.org/ibis/macromodel_wip/archive/20150609/walterkatz/C_comp_in_IBIS.zip>
)(pdf
<http://www.eda.org/ibis/macromodel_wip/archive/20150609/walterkatz/C_comp%20in%20IBIS/C_comp.pdf>
)
IBIS Macromodel Task Group
Meeting date: 9 June 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:
- Mike LaBonte to post Michael Mirmak's latest Directionality document.
- Superseded by the following AR.
- Michael Mirmak to submit the Directionality BIRD with the discussed changes.
- Done - submitted as BIRD 178.1.
-------------
New Discussion:
- Arpad: I anticipate a motion to untable the optimization topics.
- Ambrish, are you prepared to discuss Walter's proposal.
- Ambrish: We have not yet had a chance to discuss it.
- Nothing for the meeting this week.
- Arpad: No need for a motion to untable this week.
- Arpad: Walter sent an email today.
- He has something regarding the C_comp improvements proposal from Randy.
- Walter: [sharing "C_comp in IBIS" presentation]
- IBIS describes hook up of C_comp for *deriving* I/V curves. [* for emphasis]
- IBIS 6.0 spec. mentions "Data Collection" to determine I/V curves.
- [Showing IBIS 5.0 Terminator Model diagram]
- Don't have other good examples for I/O, Output, etc.
- POWER Clamp Curve - for data derivation is hooked up to [Voltage Range]
*value* or [POWER Clamp Reference] *value*.
- People point out that it's referenced to something.
- IBIS would say it's referenced to GND.
- Can be thought of as node 0, but not necessarily.
- GND Clamp curve - hooked to GND (often 0) or a [GND Clamp Reference]
value, also relative to GND.
- C_comp - for derivation of I/V curves it's hooked up directly to GND not
to supply rails.
- As long as the supply rails are static, it doesn't matter where C_comp is
hooked up.
- The IBIS 5.1 Terminator Model diagram is incorrect.
- GND became the ground symbol on the diagram as an editorial mistake.
- Symbol is typically interpreted as chassis ground, misleading.
- We should stick with the 5.0 diagram's GND.
- Arpad: Is that a universally accepted interpretation of this ground symbol?
- Walter: I'm not sure what it means universally.
- It's different from GND, and that is misleading and confusing.
- David: What we can say is that GND and this ground symbol are thought of as
"0" in SPICE simulators.
- Radek: The ground symbol most typically is setting that node voltage to "0".
- GND can be used as "0", but not as commonly as the ground symbol.
- GND can be interpreted as a reference node, not "0".
- IBIS should be able to have GND as the ground of the component, not
necessarily "0".
- Arpad: It's in the eye of the beholder, not spelled out.
- Walter: IBIS says:
- For C_comp_*, it tells you how to hook it up.
- For C_comp, IBIS never specifies what it is between, other than when you
are deriving I/V and v(t) and there are constant voltages on the rails.
- Radek: There is another picture of a v(t) derivation.
- It shows C_comp connected to GND.
- Walter: As part of simulation or derivation?
- Radek: Simulation must be consistent with derivation.
- Walter: No, in the derivation you know that the rails are constant.
- In that case it doesn't really matter.
- IBIS 6.0, page 70, "Potential numerical problems ... C_comp ... may be
handled differently by different simulators."
- It's the only text description of how to handle C_comp. Very vague.
- Radek: I think the original intent was different from how we see it now.
- It is a strange statement.
- Walter: I'm just making the point that IBIS doesn't describe how to hook up
C_comp.
- [Showing corrected Terminator diagram using A_pcref, A_gcref terminals]
- When you're doing simulation (time varying rail voltages), this is the
proper Terminator picture.
- I think C_comp should be hooked to A_gcref, as opposed to "0" or GND.
- I think C_comp to "0" is fundamentally wrong.
- Randy and I have done simulations:
- With a real power deliver network, there are significant differences when
you hook up C_comp between the Model pad and "0" vs. hooking it up between
the Model pad and A_pdref.
- C_comp to A_pdref yields excellent agreement with a SPICE model.
- C_comp to "0" or GND is incorrect.
- Conclusion:
- IBIS should recommend that Model makers use C_comp_* (informative).
- IBIS should recommend or require that EDA tools connect C_comp to A_pdref
or split it between power rails.
- Similar to the way the Interconnect proposal says package models should
not use node "0".
- Arpad: This connection makes a difference only if powered by non-ideal
sources, i.e., through a package model.
- Walter: Correct.
- Arpad: This is the background for my next comment.
- If we don't have enough info in the IBIS Model to associate the buffer with
individual power and ground pins, we can't do much with Power Integrity.
- This only starts to make sense if the [Pin Mapping] keyword is present.
- Only makes sense when the Model maker can give us this info.
- David: Summary, this is only pertinent to Power Aware simulations.
- Arpad: Yes, now in terms of what we want to do about it:
- We can't vaguely say "applies to power aware...".
- We can say, "If [Pin Mapping] is present," do it this way.
- Walter: [Pin Mapping] or the new [Buffer Rail Mapping].
- If the buffer is running with ideal rails, it doesn't matter.
- If the buffer is not running with ideal reals, some sort of power
distribution network, then it matters.
- If the buffer supply is non-ideal, C_comp should be hooked up to the same
rail supplying the buffer.
- Local ground, not "0".
- I think we all agree on this.
- Getting the words right might take some work.
- Radek: I think the problem is the other way around.
- We should describe what GND is, not redefine what C_comp is hooked to.
- GND is really the reference for the output node, too.
- If the model maker tells you the pull down ref is GND, you have to do it.
- Yes, the ground symbol in the 5.1 diagram is wrong.
- The "0" reference is wrong.
- Let's describe the real floating reference GND.
- Problem originated from the first IBIS spec, when it was global ground.
- GND was never clarified.
- Defining GND as the local ground is the sensible solution.
- Walter: I think we can all agree.
- C_comp should not go to "0".
- It should be going to some local ground.
- We can hash that out.
- Radek: Yes.
- Arpad: Yes.
- In the early 90s, even when there was only one C_comp, I had a slide for my
IBIS courses. Even in that first version I connected it to die ground, not
node "0".
- Walter: Randy and I have done experiments.
- We don't find that it matters much how the C_comp is split up amongst the
rails, as long as you avoid node "0".
- Unfortunately, one of the standard simulators out there connects it to "0".
- Radek: There is one location where the spec mistakenly equates GND and "0".
- The mistake is only made once.
- That reference should be changed to A_gnd.
- Not too much to clarify, but we should be clear.
- If you have a pseudo-diff buffer, you need a common node to connect them.
- Arpad: What is the suggestion or proposal to come out of this discussion?
- Incorporate it into Randy's BIRD?
- Create a separate BIRD?
- Walter: I think it's an editorial effort to address this in IBIS.
- We adopt one of the suggestions.
- Mike L: I think it's more than editorial in nature.
- Arpad: How do we make that decision on what suggestion to adopt?
- Do we need a BIRD to vote on?
- I'm not sure the Editorial Committee can do this on its own.
- Walter: In Interconnect we agreed to finish interconnect and not address IBIS.
- We agreed there had to be a separate effort to clean up GND in IBIS.
- Radek: I think a BIRD is needed and should be voted on.
- It may take some time, and is probably beyond the Editorial Committee.
- Arpad: It could start as editorial, but certain changes need technical review.
- Walter: The whole thing is one big BIRD.
- Let's start by reviewing and making the changes.
- The ATM group might be too big to start tackling this one.
- A small editorial group could work on it and bring it to the ATM.
- David: Assume we do adopt one of these two suggestions.
- We preclude the EDA tool from connecting to "0".
- How does the EDA tool define the ground clamp reference in a simulation if
the user hasn't specified it in the simulation?
- Walter: Whatever element your SPICE deck uses provides voltage internally or
you supply it externally.
- In the buffer there is a voltage rail or a ground rail.
- Now we are saying C_comp is hooked to one of those, not "0".
- Radek: Let me put it differently.
- If we properly define the local ground, and it's available, then if you
simulate a single buffer it really doesn't matter.
- David: A typical IBIS user uses a component with only one node, the output.
- They place a triangle with only one point on their schematic.
- The simulation tool defines the rails.
- Walter: No, the tool goes to the IBIS file to decide.
- David: The positive rail.
- Walter: IBIS specifies that the ground rail is zero volts in the
[Voltage Range] case.
- Mike L: Isn't this problem for the Model maker?
- The simulator should be able to connect any node it wants.
- Walter: One simulator's b-element connects C_comp to "0".
- Mike L: Are you saying that because one simulator does it Model makers depend
on it?
- Walter: I'm not saying that. I'm saying it's vague and undescribed.
- David: Isn't the problem that we allow the user to drop a one-node triangle on
the schematic?
- Arpad: The tool is providing the nodes.
- Either way, the spec doesn't define it properly.
- Walter: The spec didn't anticipate power delivery.
- I don't think Model makers understand that.
- David: Since the default definition for the ground clamp reference value is
zero, you're not going to change the behavior in the default case.
- Walter: Yes, it's not a disaster where default results change.
- It only changes if you're doing power delivery.
- Even if you don't have a Power Aware Model [ISSO_PU, etc.], if there is an
external PDN then it will make a difference.
- Arpad: Okay, we are at the top of the hour.
- This was a good discussion, and we will address it.
- We're not going to solve it all today.
- Walter: Thanks, that was my intention.
- Arpad: We will continue next week. Thanks everyone.
AR: Mike LaBonte to post Walter's "C_comp in IBIS" presentation.
-------------
Next meeting: 16 June 2015 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
