Minutes from the 05 April 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
05-APR-2016 Mike LaBonte SiSoft IBIS Model Connection Figures draft 1 (zip
<http://ibis.org/macromodel_wip/archive/20160405/mikelabonte/IBIS_Model_Connection_Figures_draft_1.zip>
)(pptx
<http://ibis.org/macromodel_wip/archive/20160405/mikelabonte/IBIS%20Model%20Connection%20Figures%20draft%201/IBIS_Model_Connection_Figures.pptx>
)
IBIS Macromodel Task Group
Meeting date: 05 April 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:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Michael M.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
New Redriver Flow:
- Discussion: Fangyi said he had nothing new to present. Arpad noted that there
had been some discussion about getting a group together off line to discuss
the proposal and work on drafting a BIRD, but that he had not seen anything
recently. Fangyi noted that after the last discussion Walter had said he
wanted to review it and make sure he understood the flow. Fangyi said he
would email Walter to check on status. Arpad said he would do the same with
Vladimir.
BIRD 147.1 and Co-optimization:
- Discussion: Ambrish noted that he has a new version nearly ready. He is
waiting for feedback from a partner. He said he would ping them for feedback
and keep Arpad up to date with respect to the status.
GND, reference, and C_comp:
- Arpad: Does anyone have any updates or discussion starters on this one?
- Michael M.: Are the C_comp improvements waiting on the referencing
discussions?
- Arpad: I'm not sure, but it was recently mentioned that C_comp is one of the
most important topics we face for accurate results with power integrity
simulations.
- Randy: Walter had a recent email on the ATM reflector on that topic.
- It talked about C_comp referencing as something we need to discuss and
whether we want the spec to say how that is done or if EDA tools can do what
they want to.
- Arpad: I was a bit confused about this discussion in last week's meeting.
- I recall that this whole C_comp issue came up as part of the ground cleanup
effort in the editorial task group, which is itself closely related to the
s-parameter referencing issues being discussed in the interconnect group.
- I thought the editorial task group was waiting on a resolution of the
question about the C_comp reference connection.
- Then, near the end of last week's meeting, Walter stated that there's
nothing to do as far as changing the spec.
- If anyone has a better understanding of where this stands, especially with
respect to Michael M.'s comments, let us know.
- Michael M. (MM): There are two interlocking issues:
- We need a circuit-block to substitute for the simple C_comp.
- What is the de-embedding mechanism for the K(t) derivation?
- How is it connected or referenced?
- Arpad: The circuit block is mostly for putting series elements between the
buffer terminal and the pad. Series decoupling caps, for example.
- The other aspect is the referencing, specifically the ground.
- MM: From the editorial discussion there's a trend to either take the following
approach or not:
- Take the Device Under Test view of IBIS that Walter was proposing, and go
with a single node that serves as the reference node for all the C_comp,
Vinl, Vinh, [Pullup Reference], etc. and all the other traditional IBIS
keywords.
- Mike L. (ML) has produced some nice drawings showing the connection
assumptions.
- Open questions are whether it's called universal reference node, or it's
unnamed, or whether it can be tied to another reference, etc.
- Arpad: Your (MM's) recent email added a new twist regarding confusion with the
[*** Reference] keywords.
- Has that discussion reached a conclusion?
- Radek: Those conversations are happening in different mailing lists.
- Some are in editorial, interconnect, etc.
- Unfortunately, not everyone on this call may have seen all the discussions.
- The referencing MM mentioned is that when we do the measurements (DUT) we
specify [Pullup Reference], [Pulldown Reference], etc.
- ML produced some nice pictures that show voltage sources connected to a
common node that is also the reference for the I/O signal.
- That is the extension of the DUT measurements described in the spec, and it
is valid for non-power-aware IBIS simulations in which the reference
terminals are all kept constant.
- One bit of controversy in this case is that some say the reference node is
node 0 in this case. But, it may or it may not be. What's important is
that there is one local reference node that is present in the model.
- When you have power-aware simulations and you allow the rail voltages to
fluctuate, then it is really important to know where a single C_comp is
connected. I have mentioned many times that it should be connected to the
common reference for the model, which should be considered the local ground.
- That needs to be specified by the model maker.
- We need to give the model maker the capability to do that using [Pin
Mapping] or some other method.
- Otherwise we will keep going in circles and say local ground is the pd_ref
or local ground is the gc_ref, and people disagree and we get nowhere.
- Arpad: I would like to specifically address one of MM's email's questions
regarding [*** Reference] keywords.
- Are those keywords defining a node or terminal where a connection is made,
or are they defining voltages that must be referenced to something.
- My understanding was that we meant voltages and not nodes, and that the
assumption, which is not spelled out in the spec, was that the reference
was somewhere on the board or VRM or test fixture.
- MM: If you look very carefully in the spec at the [Pullup Reference] and
[Pulldown Reference] language: [sharing that section of the spec]
- [Pullup Reference] explicitly says it is defining a "rail."
- [Pulldown Reference] is more confused. It mentions 0V with no indication
of what the reference is.
- Radek: For the nodes or rails it's probably better not to use those
[*** Reference] keywords.
- We should use pu_ref, pd_ref, etc., and we already have those terms.
- Bob put together a document showing all the various terms we use.
- What MM is referring to should probably be cleaned up.
- Bob: The [Pulldown Reference] section "rail" language is wrong.
- MM: I disagree.
- I think the "rail" statement is correct.
- It defines a "rail" as a reference for the [Pullup] I-V data.
- Change "reference voltage" to "reference" in that sentence and it works.
- Then we can add a sentence saying, "The value given here is a value
for the voltage on that rail with respect to (need to define what)."
- Radek: The language is inconsistent.
- If you say it's a rail, then you don't also say voltage.
- You have a voltage at the rail.
- Arpad: I could see it both ways.
- You have a rail with a voltage connected to it. It needn't be exclusive.
- MM: I agree that we don't want to use "define" in relationship to the rail.
- If we wanted to redo this, we would say:
- This provides the voltage value associated with a source connected between
the pu_ref node and some "reference node" we need to define.
- Arpad: I would suggest using the verbiage "applying a voltage" between the
rail(s) defined by these keywords and some reference node, instead of
"connecting" a voltage to them.
- Arpad: [Sharing slide 2 "Bare Die" from ML's IBIS Model Connection Figures]
- I agree with this drawing. All the voltage sources associated with the
*_ref terminals are connected to one common GND.
- Bob: That GND is the "ground."
- We have to define a ground as part of the [Model], whether a node exists for
it or not.
- That is the reference, i.e. the other side of a voltage declaration, for
many keywords.
- Radek: That's what I've been saying all along.
- We need to have that node. We need to have that reference in the [Model].
- MM: Bob, you meant an accessible node, right?
- Bob: No. It can be an implicit node.
- MM: Okay, as long as there's a node.
- I really want to get away from any concept of a voltage as some number
hanging in space. There has to be a reference.
- So, we have a reference node here even if we can't access it directly.
- Radek: This GND is fine. It does not have to be the earth ground symbol.
- Somewhere in your entire circuit you may have a global ground somewhere.
- This GND node may be offset or floating with respect to that global ground.
- MM: I agree, but I strongly advise we not use "GND" as it causes confusion.
- We should call it "reference" or something else and allow the EDA tool to
connect to it.
- Or, we should use some other symbol so as not to imply that the node is
necessarily accessible like the I/O pad.
- Radek: It must be accessible. Even I/O is only defined with respect to some
reference node, and it must be accessible. It must be in the picture.
- Arpad: Walter has a good point when talking about DUT vs. DIA.
- As a DUT the GND node could be the test fixture reference.
- But we need to spell out where the package model is located on this drawing
in an actual simulation. Is it between the sources and the I/V curve boxes,
or on the other side of the sources?
- Radek: The legacy model was an extension of the signal node through the
package to the signal Pin. You had R_pkg, L_pkg, C_pkg. C_pkg was
connected to the node shown as GND here (or could be called ref).
- It's been like that forever. We may want to clean up the terminology.
- MM: If we say that there is a reference node there, do we provide a way to
specify it in the model or do we leave it up to the EDA vendor to figure
out how that node should be connected?
- Can the model maker say, "I want that node to be a Pin, or pu_ref, or..."?
- There may be some call to define things like a reference that is only inside
the package.
- Radek: We need to give the tools to the model makers so they can specify it.
- Bob: I disagree.
- That GND might be the ground plane reference, and it's the reference for all
supplies that are defined internally.
- Your pc_ref, gc_ref, etc. could be hooked up to external supplies instead
the [* Reference] values.
- Radek: Okay, then why do you disagree?
- This GND does not have to be absolute ground.
- What's important is that [GND Clamp Reference] as a value gives the voltage
between the gc_ref terminal and this GND, this reference.
- Bob: I agree, but GND can't vary.
- Arpad: In this picture I would put a box around the 4 I/V boxes to represent
the Die. Then another box could show the package. I could not see a
die having ideal sources in real life. That could be made clear.
(Note: ML agreed, and the presentation that is posted to the work
archive does contain a box around the [Model] elements).
- ML: [Sharing his "IBIS Model Connection Figures" presentation.]
- Slide 2, "Bare Die": what we have been reviewing.
- Slide 3, ECL and PECL.
- Only difference is that the pullup and pulldown tables are both connected
to the [Pullup Reference].
- Slide 4, includes Package.
- Supply sources and test fixture common reference node shown outside of the
package.
- Where is C_comp connected?
- Arpad: I don't want to deal with C_comp now.
- As the [* References] go, I would agree with this picture.
- I would simply put a box around the I/V curves to clearly indicate the die
boundaries. (see Note above, ML agreed and added the box)
- In light of MM's question, can we agree to this drawing and figure out how
to best describe it?
- Bob: We can agree on the partitioning.
- There's a model section.
- There's a package section.
- There is the possibility of internally provided rails, or external rails fed
to the [Model] via the package.
- The K(t) table is based on fixed absolute voltage references. They are
fixed internal references defined within the model. They are fixed
"numbers" defined with respect to node 0. We have a lot of data with
respect
to node 0.
- We have to agree there is some local reference from which all of the single
valued voltage data keywords are defined, except for the tables that are
defined relative to some reference keyword.
- Arpad: I think Vinl, Vinh would be examples of these single value parameters.
- Originally we only had [Voltage Range], not the [* Reference] keywords.
- We assumed the VSS Pins are connected directly to the ground node.
- The [Voltage Range] "source" was between the ground pins and the VCC pins.
- Because those ground nodes were at 0V with respect to node 0, it went
without saying that Vinh, and Vinl were also referenced to node0.
- When we introduced the [* References] and added the capability of providing
some non-zero values for the [Pulldown Reference] and [GND Clamp Reference]
(VSS Pins), we didn't think it through and we forgot about what would
happen to Vinh, and Vinl and the other single valued numbers.
- We have to find a good way to correct the spec and say those single valued
voltages are referenced to something.
- I would say it should be the internal pd_ref or gc_ref terminals.
- Bob: I think the spec is okay the way it is, and those values get changed and
they're referenced to the absolute ground.
- Your algorithm doesn't work for some cases.
- In a PECL spec, Vinh and Vinl track the pu_ref, not the pd_ref.
- The way models are issued now for PECL, we change the numbers around if the
rails change.
- Arpad: We can put verbiage in the spec with a special case for PECL.
- Using node 0 does not make sense.
- As Walter stated in an email the other day, it's still a 5V device whether
it has + or - 2.5V rails or 1000V and 1005V rails.
- Bob: A model at 1000 and 1005V would have Vinl at 1001.5 and Vinh at 1003.5.
- Arpad: A model maker wouldn't know if you're going to run it at 1000V and
1005V.
- Bob: You shouldn't operate that model well outside the range of the fixed
voltages given in the [Model].
- Arpad: I'm not providing a pathological case.
- Just like you take ECL and lift it up to the positive supply to make PECL, I
could take CMOS and push it into negative and run it between -5 and 0.
- Bob: Models being created by model makers today are just created with absolute
voltages and you assume the models will be operated in that voltage
range.
- Radek: But those voltages "values" are with respect to something.
- We could make them relative to something other than node 0.
- Radek: [Commenting on slide 4]
- When you are a DUT there is no package in the picture.
- When you are simulating, we have a decision to make.
- It will make a difference whether we say pu_ref, gc_ref, etc.
- If we give the model maker the opportunity to be precise it will
be far better, unless we are willing to just say "it will always
be connected to pd_ref, or always gc_ref, ..."
- Arpad: Where do we stand now in making a decision about how the spec.
should be corrected?
- I don't see a problem with saying all the single valued entries should be
referenced to the bottom rail (or top rail for ECL, PECL)?
- Is there an issue with doing that, or are we all in agreement?
- How should we proceed with the editorial work?
- Radek: I agree.
- We can revisit what we say for PECL/ECL for Vinl and Vinh, because I believe
it's not quite correct. But that is definitely part of that work.
- Radek: [Referring back to slide 4]
- When the device is being simulated, we don't have those fixed supplies.
- Voltage rail may vary, and it may vary around those values.
- The package is present.
- We still need to say what the reference node for the signal pin is, and it
is not stated here.
- Arpad: In the simulation the rails might be non-ideal.
- Radek: Yes, then the supplies shown can't be called [Pulldown Reference],
etc. because those are fixed values.
- Bob: Yes, [Voltage Range] and [* Reference] are the ideal values.
- We don't have those values outside the package.
- We have VSS1, etc. that can modulate.
- The [Model] itself is based on the ideal values, but it can now take into
account variations in the rail ([Composite Current], etc.).
- Arpad: Most of the data in IBIS is basically measurement conditions.
- Voltage, temperature, process variations, etc.
- When you simulate those conditions might change.
- Bob: I do still contend that there is some reference for the internal model
voltages.
- We are changing IBIS if we don't recognize that even the threshold values
are with respect to a fixed local reference.
- We cannot declare that something tracks one or something tracks another.
- CMOS thresholds may be 30% and 70% of the difference of pc_ref and gc_ref.
- For some other technology like TTL it might follow the pd_ref.
- MM: No one is disagreeing with the need for a reference.
- Arpad: We are over time, so we will have to continue.
- Thank you all for joining.
AR: Fangyi to email Walter to check on the status of his review of the Redriver
Flow proposal.
AR: Arpad to email Vladimir for the same purpose.
AR: Ambrish to check for a collaborator's feedback on his nearly ready new
version of the Backchannel proposal.
-------------
Next meeting: 12 April 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
