Minutes from the 22 March ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been
posted to the work archive.
*DATE* AUTHOR <http://ibis.org/macromodel_wip/archive-author.html>
ORGANIZATION <http://ibis.org/macromodel_wip/archive-org.html> TITLE
<http://ibis.org/macromodel_wip/archive-title.html> FORMATS
22-MAR-2016 Bob Ross Teraspeed Reference Models in IBIS (zip
<http://ibis.org/macromodel_wip/archive/20160322/bobross/Reference_Models_in_IBIS.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160322/bobross/Reference%20Models%20in%20IBIS/ross_ref_mod.pdf>
)
IBIS Macromodel Task Group
Meeting date: 22 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 and Bob Ross had each created some slides related to the
referencing topic.
--------------------------
Call for patent disclosure:
- None.
-------------
Review of ARs:
- None
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob: Motion to approve the minutes.
- Michael M.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Reference [Model]s in IBIS:
- Bob: [Sharing his new presentation]
- Summary: Many Topics
- C_comp connected to GND.
- Reference Models used in EDA tools.
- Some C_comp issues.
- Some extraction assumptions and methods.
- [Slides 3, 4]
- Figure 11 - Terminator [Model] figure.
- C_comp connected to GND (IBIS 5.0), now ground symbol (6.1).
- Note that Rac and Cac are also connected to the same "ground". No
specific solution for them.
- [Slide 5]
- Figure 15 is just an extraction setup for waveform measurement.
- It defines the R_dut, L_dut, C_dut, which emulate a package if you have to
extract by measurement.
- Unfortunately, this method is flawed and most tools don't support R_dut,
L_dut, C_dut at all.
- Not recommended.
- In my opinion, it is irrelevant, because there are better ways to
de-embed the package information.
- C_comp is embedded in the DUT die anyway.
- [Slide 6]
- [Composite Current] extraction figure.
- It's defined from the [Pullup Reference].
- Radek: "C_comp not needed" is a bit misleading?
- Bob:
- C_comp is also embedded in the "DUT die" in this figure. It is not shown
as a separate element (that is what is meant by the phrase "C_comp not
needed" on the slide).
- [Slide 7]
- Figure 17 actually shows some internal currents.
- This figure doesn't show C_comp, so there is inconsistency when we break
up internal currents.
- That's what we have in IBIS.
- We have some details but are missing others for a general configuration.
- [Slide 8, Slide 9]
- I've shown some EDA Tool Reference [Model]s documented by some tools.
- In all cases the user can override the C_comp to ground (effectively
creating C_comp_xxx behavior).
- My conclusion is IBIS should not change its reference model because the
tools will not change theirs.
- I don't know what all other tools do.
- Randy: Although the HSPICE documentation appears to be behind, they have
changed their behavior as of late 2015 to connect C_comp to pd_ref.
- Walter: SiSoft in its internal SPICE simulator also hooks C_comp to the gc_ref
or pd_ref. We use a local ground not earth ground.
- We have various EDA vendors documenting that they do it both ways.
- Radek: We may have the local ground being separate from the pd_ref or gc_ref,
but not necessarily make it global ground.
- You just allow everything to be referenced to a different single node.
- It wouldn't change the picture, just the interpretation of the ground
symbol.
- Ming: We also give the user the option to split the basic C_comp.
- Bob: Yes, all tools do as far as I know.
- But you do not automatically connect C_comp to pd_ref or gc_ref, right?
- Radek: No, there is nothing in the spec that would suggest that explicitly.
- Bob: So we have different tools doing thing differently.
- [Slide 10]
- From the IBIS cookbook. Diagram from Arpad's work.
- C_comp is Not constant.
- Extraction generally assumes all rails are ideal, so what you get is the
overall C_comp.
- [Slide 11]
- From the cookbook. Arpad proposed one method for deriving the individual
C_comp_xxx values from simulations.
- [Slides 12, 13]
- Results from Lance Wang's IBIS Summit Tokyo presentation.
- Plots show the total C_comp and his results when he extracted the
individual split C_comp values.
- In his example, C_comp_pc was actually the dominant term.
- This counter example shows that arbitrarily deciding that C_comp goes to
pd_ref or gc_ref is technically questionable.
- [Slide 14]
- IBIS [Model] Extraction
- From Simulation:
- Remove the package then do extractions.
- From measurement:
- Much more complicated, details outside the scope of IBIS and even the
cookbook.
- [Slide 15]
- EDA Tool IBIS Model Simulation
- Various different approaches may be employed.
- No one approach is "correct," so we should avoid defining certain fixed
approaches in IBIS.
- We agree that C_comp to "ground" provides a model that is probably not
suitable to power aware analysis.
- [Slide 16]
- A more general IBIS I/O Reference [Model]
- The separate C_comp_xxx values are shown.
- [Slide 17]
- Recommendations
- Non power aware just keep the legacy C_comp to ground.
- State that such models are not recommended for power aware analysis.
- Add a new reference model diagram showing the C_comp_xxx connections
(like Slide 16), since that is supported anyway.
- Note that IBIS Model extraction from simulation assumes that package
circuitry is removed.
- Extraction details in IBIS cookbook should focus on simulation.
- Details regarding extraction from physical measurements are outside the
scope of IBIS or even the cookbook.
- Arpad: With regard to [Slide 17], when you say "state", or "add", or "note" do
you mean in the IBIS spec or in the model or where?
- For example, "not recommended for power aware", or "Add a new reference
model...", should those be added to the spec?
- Bob: Yes, in the spec.
- Radek: We have a C_comp_xxx option for the model maker that is unambiguous.
- We can add a new reference figure.
- If the model maker only gives us C_comp, we have to deal with that and how
it is referenced, regardless of whether it is a power aware simulation.
- For new models we can describe what to do. The recommendation to provide
C_comp_xxx is a good one.
- We still have to address how to handle C_comp if that's all that is given.
- Arpad: I want to restate what several people have mentioned at various times,
that this issue of where to connect C_comp is only relevant when non-
ideal sources are used to power the buffers for a power aware
simulation.
- As soon as you use ideal sources then the connection point of C_comp is
irrelevant because the ideal sources are AC shorts between all the
terminals.
- For that reason I still maintain that we should consider a solution for this
C_comp connection that is relative to other keywords. For example, if [Pin
Mapping] doesn't exist and there are multiple power and ground Pins then we
cannot use them for power integrity purposes because we don't know which
buffers are associated with which power and ground pins. One method for
deciding if C_comp is valid is to look at whether the [Component] has a
[Pin Mapping] keyword. Another would be look at whether the [Model] has
[Composite Current] or [ISSS_**] parameters.
- I would suggest formulating a rule that if those keywords don't exist then
it is okay to use C_comp, no matter what DC node is used for its reference,
but if they do exist then the model maker should use C_comp_xxx, and if the
model maker doesn't use C_comp_xxx then suggest that the tool split the
value of C_comp evenly amongst various C_comp_xxx.
- Radek: My understanding of Bob's example from Lance [Slide 12] is that there
is no reliable way to decide how to split C_comp.
- We are dealing with non-linear devices.
- For example, if the gc_ref shifts from zero, then it shifts the point at
which clamping occurs and this significantly affects the buffer's operation.
- We can't arbitrarily move C_comp from one place to another.
- Bob: Radek's point is well taken.
- The best algorithm we might have here is a 25/25/25/25% split assuming 4
terminals.
- C_comp has lots of issues, but my main conclusion is that attaching it to
one specific terminal is technically questionable.
- Arpad: It's only questionable if you're using non-ideal sources.
- Walter: I agree with Arpad.
- If you're doing a simulation with fixed rails then it doesn't matter.
- You can hook C_comp to any DC rail and get the same simulation results.
- When rails vary it can be for two reasons:
- You have a power delivery model and the power rail could vary for
external reasons.
- The rail can vary due to current pulled by the buffer itself.
- In that case it matters where C_comp is hooked up.
- But as a practical matter, in simulation you'll generally find you get a bad
result if you hook C_comp to node 0, but you generally do okay if you
connect C_comp to any of the local references.
- Arpad: I disagree with the last statement.
- If I hook C_comp to the pd_ref and the power rail is what wiggles then you
don't see anything in the signal.
- Walter: Yes, it can make a difference.
- But in reality, the large voltage variations tend to occur on both rails.
- For practical purposes, if you model real power delivery systems then it
usually works out.
- Arpad: You could have a collapse when there's a crowbar momentary short
circuit between the pu and pd terminals.
- What about the interconnect models that are made such that the references
all rely on node 0? Everything from the ground parasitics is figured in
to the signal or the power lines. With that approach C_comp location would
have serious consequences. If you hook it to pd_ref it would do nothing for
you. You would have to hook it to pu_ref.
- Walter: You mentioned the very important part.
- The impact of clamping ground and using the universal ground reference for
your power integrity is that your signal moves up and down. The signal
moving up and down will have the exact same effect when you put C_comp to
pd_ref as pu_ref, because the signal now moves up and down "half" as much
as the power rail.
- My point is that it's not so simple that it's obvious.
- Model makers generally have no idea how to split C_comp up when they do
an extraction. So most model makers just split it up evenly.
- We have to deal with what we have.
- We can force the model maker to split C_comp.
- We might as well just have the EDA tool do it.
- We both agree that for the purposes of power aware simulation C_comp must be
split somehow between the local rail voltages.
- Arpad: If we agree on this statement, then why don't we just add the new rule
to the spec that "C_comp should only be used for non power aware IBIS
models," which could be determined based on existence of certain
keywords.
- Walter: That only takes care of doing power aware simulations when we do have
[Composite Current].
- Wouldn't you also want to support simulations where the rail voltages are
moving because of external influences?
- I agree with you. Without [Pin Mapping] we can't hook it up at all.
- Arpad: If [Pin Mapping] exists you must have C_comp_xxx.
- Walter: Yes, or say if it's not given the EDA tools splits C_comp up amongst
the rails.
- If that's not good enough, then the model maker should give C_comp_xxx.
- Bob: Yes, we already have C_comp_xxx so the model maker can do it.
- Suggested guidance may be for the tool to split C_comp equally.
- But we should not mandate a connection to one particular rail.
- Arpad: I don't think we should say how the tool should split it up.
- Tool maker might give the user the option.
- But we can say that if [Pin Mapping] exists you should not use plain C_comp.
- Radek: I think we are going in the wrong direction in general.
- We really need the definition of the local ground as well as the reference
for the output signal.
- This can be the same rail as the gc_ref or the pd_ref, and this is entirely
up to the model maker.
- We are trying to avoid this solution of specifying it fully.
- We are trying to reinterpret old data in a different way.
- It's entirely up to the user and not the EDA tool to know what kind of
simulation is done and how to reinterpret the data.
- Arpad: Are you saying we should provide another parameter in the model to say
where C_comp should be connected if the model maker isn't using
C_comp_xxx.
- Radek: Yes, that's what I've been saying all along.
- Arpad: Why not just tell the model maker to use the C_comp_xxx?
- Why introduce another parameter to define the reference, when the model
maker can just use the C_comp_xxx to produce the same effect.
- Radek: That might work for C_comp for now, but what about the future?
- What about defining a reference for the signal output itself?
- We don't provide any means to say what the output signal is with respect to.
- Arpad: Thank you all for joining.
-------------
Next meeting: 29 March 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
