Minutes from the 29 March ibis-atm meeting are attached.
Walter's document, which was discussed during the meeting, can be found
here:
http://ibis.org/macromodel_wip/archive-date.html
The entry for the document is currently dated March 28, but I've asked the
web master to correct that to March 29.
IBIS Macromodel Task Group
Meeting date: 29 March 2016
Members (asterisk for those attending):
ANSYS: * Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: * Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
Cisco: Seungyong (Brian) Baek
eASIC: * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
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
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that he had slightly rearranged the weekly agenda so that the
official roll call would precede everything except the Opens.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Reference [Model]s in IBIS:
- Arpad: I would like everyone to focus on finding a way to answer the questions
or problems we have been trying to resolve.
- My understanding is that one of the questions we wanted to resolve is where
to connect the standard C_comp.
- If possible, I would encourage us to move in the direction of answering that
question.
- Walter: I think we have the following:
- When you have C_comp_xxx there is no question.
- When you have a single C_comp, the EDA tool can do multiple things with the
the other end of C_comp (one end is connected to the I/O pad):
- Use node 0.
- Use the logical local ground (e.g. pd_ref or gc_ref).
- Split it amongst the various rail nodes.
- Give the user the choice of what to do.
- If the rail voltages at the buffer are constant, none of this matters.
- This only matters for a "power aware simulation," meaning when the rail
voltages supplied to the I/V curves are not constant for any reason.
- Perhaps an I/O buffer has [Composite Current], so it's pulling current
and affecting the rail.
- Or perhaps some other external influence is causing the voltage at the
buffer to change.
- Agreed?
- Radek: Not quite. The node must be one that is present in the buffer.
- If for example, all the voltages fluctuate, but the voltages across the
buffer remain constant, it still won't work to use node 0.
- This is where I prefer we stick to the concept of local ground.
- Things must be constant with respect to the local ground.
- Walter: IBIS could stay silent on this.
- It can be left up to the EDA tool, which implements the IBIS model.
- Each tool needs to document how it hooks up C_comp.
- If the user is doing a power aware simulation, then the tool makes a logical
decision or lets the user decide.
- Nothing in the IBIS standard today says which of those choices is correct.
- IBIS has the C_comp_xxx, so the model maker has the option to make it clear.
- Therefore, I don't think we have to do anything.
- Bob: I agree, except that I think we need a caution and recommendation that
different tools may handle C_comp differently.
- To be explicit, we recommend the model maker use C_comp_xxx.
- We may even need to caution that not all tools automatically understand
C_comp_xxx? I'm not sure about this. Do all tools interpret C_comp_xxx
without any further user interaction?
- David: Is it appropriate for the standard to say anything about what an EDA
tool may or may not be doing?
- Mike L.: I don't think so.
- Walter: I don't think the standard should say what an EDA tool should do with
the data in an IBIS file.
- Other than [External Model] and [External Circuit], IBIS only describes the
format of I/V and v(t) curves, and the way to derive them from a device
under test where you supply specific voltages relative to a test fixture
ground.
- That's all that IBIS says.
- Radek: Not quite, maybe in this particular case that's all it says.
- But we have AMI and other sections that tell the tool how to use the data.
- We don't just take measurements to take measurements.
- We take measurements to use them to model certain behaviors.
- Walter: Yes, we take measurements to model behavior.
- But with the exceptions of AMI and [External Model], which tells you how to
hook up a Berkley SPICE subcircuit to the package, IBIS doesn't tell you
anything about legacy models.
- Arpad: I understand your point, but I would challenge it a bit.
- If we step back and generalize, IBIS implicitly says a lot about how things
should be used in the tool.
- As a silly example to illustrate my point, the [GND Clamp] I/V table is
specifically intended to be used to model a ground clamp. It cannot be used
as a pull up or pull down or anything else.
- We don't say that the algorithm should be such and such, but there are still
pretty clear indicators on how certain data should be used.
- Walter: There are implications, but there's no place that says, "this is how
you do it."
- It doesn't say that you use a PWL voltage controlled current source to
implement your ground clamp current.
- Arpad: True, but David's question in the context of this C_comp discussion is,
"Is it the job of the IBIS spec to tell the tool where to connect that
non-split C_comp?" Is that what you were getting at David?
- David: I was responding to Bob's comments, and the "some tools may, some tools
may not" verbiage struck me as something we shouldn't be talking about
in the standard.
- Arpad: We also strive for interoperability and portability.
- We want models to give the same results in every tool, or how good is the
model?
- David: I agree, but that would be the specsmanship.
- We need to improve the spec in that case. We don't fix that problem by
cautioning people that this may or may not work as a standard.
- Arpad: I agree.
- Walter: And we did. We added C_comp_xxx because we realized C_comp was
insufficient.
- David: Yes, I agree the C_comp_xxx was a great addition. I am not questioning
the addition of C_comp_xxx.
- Walter: The standard can certainly say that if you're doing power aware
simulations you should not use standard C_comp.
- Arpad: We are trying to figure out what to do with the standard C_comp.
- What should we conclude? Should we just say that non-split C_comp is not
allowed with power aware models?
- Walter: How do you know if a [Model] is a power aware model?
- It's the power aware simulation that is important.
- I can use a legacy IBIS 1.0 buffer in a system with variations in the
supply voltage. That's a power aware simulation, and you have to hook up
C_comp intelligently.
- Arpad: Can you even do a power aware simulation without [Pin Mapping] or
[Composite Current] or [ISSO xx]?
- You could only do that if there's one power pin or one ground pin?
- Walter: No, I could read the data book and figure out how to hook up VDDQ.
- I can't do it automatically, but I can read the data book and set up my
simulation.
- Radek: As long as the individual buffers in the EDA tool have four power
terminals explicitly available for the user to connect, then there is
the possibility of variation on the supply of those voltages. That is
what Walter is getting at. In a 3.1 IBIS file, there might be only
C_comp.
- Arpad: When we are talking about the actual IBIS file, you can't run that type
of power aware simulation in that case without manually intervening to
"fix" the model.
- Walter: That's correct.
- Radek: Yes, in general.
- Arpad: I think the spec could say that if the IBIS file doesn't contain the
[Pin Mapping] or other power aware keywords then use of C_comp is okay.
- If those keywords are there then you should use C_comp_xxx.
- Walter: Yes, we can say that.
- There's no reason we need to have a warning.
- There's nothing wrong with saying that if you're using regular C_comp and
you're going to do simulations with time varying rail voltages then you're
going to have to make some judgements on how to split up C_comp.
- The user can make the choices about how to split it, or go back to their IC
vendor and ask for a better model.
- Arpad: We are trying to make some progress and fix the spec.
- The conversation started with the question of where to connect C_comp.
- Do we need to fix it in the spec? If so, how?
- Walter: I don't think it needs to be fixed.
- Arpad: Why have we talked about it for the last few weeks?
- Walter: This conversation started when Bob said C_comp had to be hooked to
node 0.
- I responded that the IBIS spec doesn't say that, and it really leaves it up
to the EDA tool to make that decision.
- Arpad: This is related to the interconnect task group's efforts for ground
and reference nodes?
- Do we have a problem with the way C_comp is defined in the spec?
- Walter: No.
- Bob: Yes, figure 11 clearly has C_comp attached to ground.
- Walter: That is for a device under test (DUT).
- Walter: [sharing version 6 of his "GND in IBIS 6.0" document]
- I went through IBIS 6.0 (not 6.1) and looked at every occurrence of GND.
- How do we clean up IBIS based on how GND is used?
- Section 3 - change "reserved words..." to "reserved model names".
- GND is used in three ways in the document.
- Reserved model name.
- Signal_name in [Pin] records.
- It is used, along with the "earth ground symbol," as the reference node of
the test fixture (or virtual test fixture) when using SPICE-2-IBIS to
generate model data.
- It should be obvious in context how it is being used.
- With the exception of [External Model], legacy IBIS is a format and test
set-up spec.
- A new section could be added to the specification to describe how EDA
tools can use these models under different operating conditions.
- Figure 1:
- From 5.0 to 5.1 this went from GND to the earth ground symbol.
- I claim it clearly means test fixture ground.
- Figure 7: ISSO_pd data collection
- This one is confusing.
- I think GND is test fixture ground.
- I think "Vcc" is really pu_ref.
- Vcc is poor terminology.
- Figure 11: Terminator
- From 5.0 to 5.1 GND became the earth ground symbol.
- Would have been better to have two pictures for the [Voltage Range] only
case and the pd_ref, gc_ref case.
- All these GND and earth ground nodes are the same node. They are the test
fixture reference node.
- Figure 15: DUT
- Again, used to be GND, now it's earth ground (test fixture ground).
- Radek: That figure is also pretty incomplete in terms of connectivity.
- Walter: Agreed, in the pre 5.1 days it was probably too hard to draw in more.
- When we went from 5.0 to 5.1 we just converted legacy drawings.
- Figure 17:
- This throws in VDDQ and VSSQ. This gets confusing.
- VDDQ is a signal_name, usually a pu_ref.
- Here's a ground symbol. That's probably VSSQ in this case.
- Is it VSSQ or a test fixture connection? We need to review this.
- [External Model]
- A_gnd. Really an analog reference node used when you convert digital
signals to analog signals in Berkley SPICE.
- Figure 21: [External Model], [External Circuit].
- How do you hook up the [Model] to the board or package?
- This has GND and VCC.
- Here GND is not the reserved model name or node 0.
- I think here GND is the signal name, as also implied by the use of VCC in
this figure.
- I had the idea of eliminating one of the uses of GND by converting all the
signal_name uses to Vss so it is clearly a signal name. That idea has
been rejected more than once by others.
- Where C_comp is hooked up to GND, it's only because it's a DUT, and you're
measuring voltages at multiple locations and you need a reference node.
- If you're doing simulations and the rail voltages are varying IBIS doesn't
say anything about what to do with plain old C_comp.
- Bob: [referring back to figure 11]
- I consider that a definitional diagram.
- What that states is that the power clamp and ground clamp tables and the
Rpower and Rgnd can go to a node that can be gc_ref, but C_comp still by
definition goes to essentially "ground."
- That is used by several tools as the basis for C_comp going to global ground
regardless of the pd_ref.
- So GND for C_comp, Cpkg, and Rac Cac, by definition goes to ground.
- That's a flawed definition, but it is the current definition.
- That's the basis of my suggested "caution."
- The accompanying verbiage, which may or may not be complete, says Rgnd can
go to gc_ref. I don't know if it says anything about C_comp or Rac and Cac.
That's the basis for the confusion and tools interpreting C_comp as going to
global ground and not anticipating power aware simulations.
- Walter: There's a subtle distinction because text with Figure 16 actually
talks about C_comp often going to GND but could go to gc_ref.
- So I think the text with Figure 11 is an error in the standard.
- Bob: Yes and the source of confusion.
- That's why I go in circles on this.
- Instead of trying to clean it up and specify where things go, maybe we
should just give a caution on use of C_comp with power aware simulations.
- Arpad: Would it help to figure out what we need to say to satisfy current
simulation needs instead of focusing on what was originally meant?
- Bob: Yes. Use C_comp_xxx and don't use C_comp.
- Arpad: [referring back to figure 11]
- This is a terminator model.
- It is the only kind that uses Rac and Cac.
- In the RAMBUS days they always wanted this capability for Input and I/O
devices, but they couldn't do it because this was only defined for
terminators.
- But this whole concept is still flawed, since it's just a single RC between
the pad and whatever ground.
- In a power aware simulation this would probably be distributed between other
rails too.
- Is this type of model even worth fixing?
- Should we just say that is old stuff and implement something new?
- Bob: I don't think we should waste time fixing this.
- The new enhanced C_comp models will take care of this.
- Fixing this old terminator would require at least two different C_comps.
- Arpad: Yes, I ask because no matter how much we argue about what GND is, the
lumped RC circuit is still not going to be accurate anyway.
- Bob: The only area of relevant discussion in this diagram is the C_comp
portion we have been discussing.
- In this diagram it shows C_comp as going to global ground.
- Arpad: If you want to fix C_comp in this diagram just hook C_comp to the node
used by Rgnd instead.
- Bob: No, then we're deciding C_comp always goes to one particular terminal.
- Arpad: Isn't that what we were talking about?
- Walter had his poll of EDA vendors.
- If we all agreed that it should go to some local ground, can't we just
change the picture that way?
- Walter: Yes, and if [GND Clamp Reference] isn't specified, then they are
already the same node.
- GND is confusing here because you have [Voltage Range], [POWER Clamp
Reference], [GND Clamp Reference], which are values to be applied at the
terminals for DUT, as opposed to device in action.
- Arpad: Thank you all for joining.
-------------
Next meeting: 05 April 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
