Minutes from the 02 August ibis-atm meeting are attached.
The following documents, which were discussed during the meeting, have 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
02-AUG-2016 Radek Biernacki Keysight Technologies Alternatives in IBIS
Ground Issues (zip
<http://ibis.org/macromodel_wip/archive/20160802/radekbiernacki/Alternatives_in_IBIS_Ground_Issues.zip>
)(pdf
<http://ibis.org/macromodel_wip/archive/20160802/radekbiernacki/Alternatives%20in%20IBIS%20Ground%20Issues/ReferenceAlternatives.pdf>
)
Note: The following document is posted in the Editorial Task Group archives.
Title <http://ibis.org/editorial_wip/index-bytitle.htm>FormatsAuthors
<http://ibis.org/editorial_wip/index-byauthor.htm>Organization
<http://ibis.org/editorial_wip/index-bycompany.htm>Date
<http://ibis.org/editorial_wip/index-bydate.htm>
IBIS 6.2 BIRD Candidates rev 1 .docx
<http://ibis.org/editorial_wip/IBIS6.2_BIRD_candidates_1.docx> Mike
LaBonte Signal
Integrity Software (SiSoft) Jul 29 2016
IBIS Macromodel Task Group
Meeting date: 02 August 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
IBM * Luis Armenta
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
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi.
--------------------------------------------------------------------------------
Opens:
- Radek noted that he had prepared a presentation for discussion. It was
motivated by last week's ATM discussions, specifically the statement that we
do not need [Pin Reference] and the tabling of the I/O Reference Terminal
discussions.
- Mike LaBonte noted that he had prepared the list of potential BIRDs for 6.2.
-------------
Review of ARs:
- Ambrish to check for collaborators' feedback on his nearly ready new version
of the Backchannel proposal.
- In progress. Ambrish said that he expects to have something ready to go on
the agenda in the next few weeks.
- Mike L. to prepare a list of IBIS 6.2 BIRD Candidates.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Two sets of minutes needed review, as the July 19th minutes were not prepared
and posted in time for the July 26th meeting.
- July 19th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Radek: Second.
- Arpad: Anyone opposed? [none]
- July 26th minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Curtis: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
List of IBIS BIRD Candidates from the Editorial Task Group:
- Mike LaBonte: [sharing IBIS 6.2 BIRD Candidates rev1]
- This document starts with the top two lines of the current BIRDs
webpage and has new potential candidate BIRDs added as A through M.
- Many may be coming to ATM because they have technical content.
- Arpad: Do we have authors, etc., for them?
- Mike: No, we need authors.
- Bob has offered to work on K.
- Bob: D likely gets folded into BIRD 180.
- Mike: D, E, and F are likely coming to ATM.
- J may also. We likely agree on it broadly, but some subtleties may need
to be discussed.
- Bob: L is a cleanup proposal by Michael Mirmak.
- Radek: The only thing I don't see in this list is the DUT_ref_terminal.
- F is [Pin Reference], but there was also a DUT_ref_terminal proposal.
- Walter: I think those were competing proposals.
- One was Pin based and one was bus_label based
- The explanation for having two is related to Radek's proposals.
- Walter: I think B will require a BIRD.
- A is editorial in my opinion.
- C is introducing the concept of a "signal" or "local" ground. I don't think
that is editorial.
- Mike: The idea is that all of these would be BIRDs. Not all have technical
content that requires review in ATM or another subgroup.
- Walter: For those not in the Editorial meetings, I want to mention that I came
up with a draft IBIS 6.2 that incorporates what I believe is the
latest thinking on all of these proposals.
- All of these have been written in some form or another.
- The idea was to get the ATM group, which may have a larger more diverse set
of attendees, to take over some of them. There's a lot of detailed work
involved in getting a BIRD written up correctly.
- Arpad: Can you post this?
- Mike: I will post this document since we showed it here today.
- It is shared with (already posted to) the Editorial Task Group archives.
Radek's IBIS Ground Issues presentation:
- Radek: [sharing: Alternatives in IBIS Ground Issues]
- Last week's private email discussions led to a statement that the [Pin
Reference] proposal was no longer needed. Then that topic was tabled in
last week's ATM meeting. That prompted me to prepare a few slides to
summarize my view on the topic. I presented them at the Editorial meeting,
and it was suggested that we discuss it in here the ATM. I've added some
text to create this presentation.
- [slide 2: Legacy IBIS]
- Buffer, package model, channel/load.
- W_Element5 in the figure represents an IBIS package model in general, it
is not meant to imply w-element only.
- Board connections, power supplies, etc., indicated in upper box next to
the IBIS file box.
- Ref rail represented 0V in DUT, but not necessarily in simulation.
- "GND" was a better notation than the ground symbol.
- "GND" was first [in the [Voltage Range] days]. Separation of the pu, pd
pc, gc terminals came later. Originally, pd and gc coincided with the
ref or "GND" terminal and both were the same.
- What's important is that ref or "GND" was considered the reference node
for the signal I/O that goes to the outside world.
- The goal of this picture is to show the pins connected to the buffer rail
terminals were not necessarily the same as that ref or "GND". They could
be the same but not necessarily.
- Discussion: Arpad and Radek noted that even a legacy per pin RLC package
model would follow this picture, as the C had to go to a reference.
Walter said the picture was a fair representation of what IBIS 6.1 says.
Walter noted that in the [Voltage Range] only days, the implied "GND" ref
would have been included in the package. It was when the separate rail
terminals were added that IBIS had been a bit sloppy and left open the
possibility of this picture. Walter noted that he understood the point
that Radek was making with the picture, but he said that once you show
a "channel" (as opposed to a "load" during DUT), the return current path
would have to be part of any valid package model. Radek agreed that the
return path would have to be part of a valid package. He noted that the
picture was drawn to show that this ref did have to be part of the
package, but that the "GND" implied ref was not really part of the IBIS
description itself. IBIS does not describe the what pin in the
[Component] serves as the reference for a specific buffer. Walter noted
that we want to distinguish between two concepts of reference. One is
the location from which you make relative voltage measurements, and the
other is where the return path currents are.
- [slide 3: Legacy IBIS "GND" Issues]
- Identification of the reference terminal for the output signal is essential.
- Legacy approach just considered GND as the reference.
- C_comp, R/L/C type package models, and [Define Package Model] are all
defined implicitly with respect to GND.
- Both types of package models contain capacitance values that will lead to
inconsistent simulation results if not connected properly.
- [slide 4: Legacy IBIS - coinciding rails]
- Case A [from slide 2] is a superset case where all the [* Reference] values
were different.
- We may have fewer separate rails if [* Reference] values are the same.
- A1 is the special case where [Pulldown Reference] is zero, and all other
[* Reference] values are different from zero and each other.
- The GND rail coincides with the pd_ref.
- We have the same concept here of the output port's reference terminal.
- This case of the reference node for the signal (GND) now coinciding with the
pd_ref seems to be acceptable to everyone.
- Discussion: Walter noted that he thought the A1 figure should include a
fourth node in the supply box and a vertical line from it to the ref line.
Radek agreed.
- [slide 5: Legacy IBIS - what's missing]
- A1 figure is not controversial.
- It may be useful to expand this idea. Perhaps it would make sense to allow
the ref to correspond to a rail with a non-zero [* Reference] value.
- For example VCC in PECL.
- One of the DUT_ref_terminal proposals exploited this idea.
- When all of the [* Reference] values are non-zero we have a clear ambiguity.
- For any simulation, power-aware or not, we should be very clear about how
the signal I/O port (the pair of the I/O terminal and the reference
terminal) is defined. We want to clarify this.
- [slide 6: Preferred Solution]
- Figure B - A Pin on the Component provides the reference node.
- [Pin Reference] keyword proposal could facilitate this and allow the model
maker to specify it.
- This figure, or trivial simplifications of it (collapsing common rails),
could cover 99 percent of cases.
- Proper handling of the collapsing of common rails could be provided with
the DUT_ref_terminal proposal, or by extending the referencing constructs
to include a [GND Reference].
- [Pin Reference] proposal has value. I was surprised last week when it was
announced that we don't need it.
- Walter: This figure B is the proper legal picture.
- It handles RS-232 (e.g., +12V and -12V rails), and it handles PECL.
- The only thing it doesn't handle is some split PECL where you don't have the
0v reference as a pin on the chip.
- For 99+% of cases this figure is sufficient.
- What is the need for identifying which Pin is that reference pin?
- If the model maker knows what that pin is, they can make their package
model accordingly without having the [Pin Reference] keyword.
- Radek: We have to think about that.
- But even if you don't have a full package model, just RLC per pin, you still
need a reference for the C. We can't neglect it.
- Arpad: I have a question based our earlier IEEE P370 discussion.
- We talked about daisy chaining s-parameter blocks and the need for the
reference terminals of connected ports to be the same.
- Given that is true. If you have a reference terminal in this package in the
IBIS file and we connect to an outside s-parameter model, how can we
determine what that common reference is if we don't define the reference in
this IBIS file?
- Walter: That question is confusing the two kinds of references.
- The return path may not be the same as the voltage reference terminal.
- For example, in figure B if the return path from the I/O signal is going to
the power clamp rail then the s-parameter blocks have to be between 3 and 2
both inside the package model and outside on the board.
- That will be known from the documentation that comes with the part.
- Your question is talking about the return path terminal.
- Arpad: If you look at the W element drawing (figure B).
- You have 5 output ports, and each one uses the ref as its negative terminal.
- If there's another w-element or s-parameter model outside the IBIS box for
PDN or signaling, wouldn't that model have to have the same referencing
arrangement as the box in the IBIS file?
- Radek: That's the case we started talking about last time.
- What you said is valid to some extent, but we have to make things very
clear to the model maker and the user.
- [returning to slide 6]
- There's an important usability aspect to providing this reference node
directly to the user. In the rare case of 4 independent rails, the
model maker or user could take advantage of 4 independent non-zero
sources defined with respect to that node to supply the four rails.
- [slide 7: Floating Buffer - do we really want this?]
- Forget about the "ref" label in this picture. It is no longer the same as
in previous pictures.
- We still have the package and its five terminals on the board side.
- The actual reference terminal for the outside world/channel now has
nothing to do with the terminals in the package model. All the definition
of this reference terminal is 100% outside of IBIS in this case.
- This set up is 100% up to the user, and we wouldn't give the user the
ability to verify the v(t) data in this case.
- This is even possible with a legacy model. We could have a per pin
RLC model with no C. We could have [Package Model] matrices such that the
location of the local ground for the measurement makes it irrelevant for
the package data.
- But if we want to support this case we need to state things very clearly.
- Walter: This picture is excellent.
- This is the case of the MECL part where VCC is +2V and VEE is -2V and there
is no GND pin on the package.
- This is fine if you use what Scott McMorrow refers to ground-based power-
aware modeling where there is a GND every place in the system that is ideal
and connected to node 0.
- We have to say:
- This particular case is very rare.
- You can't do power aware simulations where the GND is floating. All
return paths go through node 0.
- For this type of component, you have these limitations on a power aware
simulation.
- For the other cases, where the rails collapse, EDA tools know what to do.
- Bob: I disagree. I think we can support this case already.
- There may be a caveat about power aware simulations, but I think a
generalized power aware network can support it.
- Arpad: Thank you all for joining.
-------------
Next meeting: 09 August 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
