Minutes from the 02 February ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 02 February 2016
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
Cisco: Seungyong (Brian) Baek
eASIC: * David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: * Steve Parker
Intel: Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
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.
--------------------------
Call for patent disclosure:
- None.
-------------
Review of ARs:
- Ambrish to find and post the latest version of his Back Channel proposal.
- Done. The most recent version is draft #14, which was posted to the IBIS
ATM work archive on September 19, 2014.
- Walter to find and post the latest version of his co-optimization proposal.
- Done. The most recent version was posted to the IBIS ATM work archive on
April 21, 2015.
Note: ATM Work archive can be found here:
http://ibis.org/macromodel_wip/archive-date.html
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Mike L.: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Discussion of language corrections regarding "ground":
- Discussion: Mike L. noted that we had originally discussed the idea of
producing a 6.2 version of the spec with only the reference node language
corrections. The goal had been to quickly produce the new version so that
additional changes could then be made with 6.2 as the base. Mike was
concerned that if the reference node discussions bogged down and 6.2 were to
drag out, then there would be pressure to put other things into 6.2. Mike
expressed concern that the ATM group might soon be running out of time to deal
with this topic exclusively, if the Back Channel and Redriver flow BIRDs were
about to become active again. He suggested that we might want to restart the
editorial committee meetings held on Fridays and move the reference
node discussions there. Ambrish noted that he was actively working on the
Back Channel proposal again. Fangyi also noted that he had made progress on
the Redriver proposal and would be ready to discuss it soon. Walter asked if
he could first make a brief presentation regarding the reference language
cleanup, which would then affect a decision to move the discussions to an
editorial meeting.
- Walter: [Reviewing the slide 2 of last week's presentation]
- If we say IBIS is a measurement standard, and it defines how you hook up
a device to test equipment, or how you run a simulation that is acting like
a test equipment measurement, and how to make measurements and define your
ground, then IBIS actually does that right.
- One could fine tune the wording a bit, but IBIS generally defines the
measurement process well.
- IBIS does not tell you how to use the model that results, and I was
proposing last week that if we wanted to have IBIS describe what to do with
a "device in action" then we needed to define additional things.
- I've now concluded we shouldn't start trying to have IBIS describe that.
- It would lead to endless discussions.
- If we just limit ourselves to thinking of IBIS as a description of a device
under test, then the IBIS language is already essentially correct, and the
intention is certainly clear.
- [reviewing this language from the spec]:
"The DUT die shows all of the available power and ground pin reference
voltage terminals. For many buffers, only one power pin and one common
ground pin terminal are used. The absolute GND pin is the reference for
the V_fixture voltage and the package model equivalent network. It can
also serve as a reference for C_comp, unless C_comp is optionally split
into component attached to the other reference voltages."
- This is saying that for most buffers you just have [Voltage Range]
and don't specify [Pulldown Reference].
- "absolute" is confusing. If that said "common GND pin", then it has
defined it as the reference for V_fixture, C_comp, package model.
- Everything here is actually right. "absolute" is confusing.
- We don't have to talk about how to use Models. If we all agree that this is
the approach we should take, then it's really just going to be an editorial
task to scrub the document.
- As soon as you realize ground is always used in the context of a test
fixture ground, we can leave it up to the EDA tool to hook things up in
a logical way when it's not a DUT. We don't have to describe that.
- Mike L.: This makes me think it should go to the Friday editorial meeting.
- Arpad: Before we discuss Friday logistics, I would like to discuss what
Walter is suggesting. If we agree, then we can move it to Friday.
- Discussion: Bob said that he didn't mind the suggestion to use the language
"common ground" instead of "absolute", but he stated the ground should be
what the buffer saw, not the Pin. He was worried about de-embedding the
package effects since he said it's a device characterization. Arpad asked
about actual measurements vs. simulated measurements, since it might be hard
to bypass the package in a lab measurement. Walter felt that the IBIS spec
properly defined everything such that all measurements could be made and
any de-embedding requirements would be unambiguous. Radek did not agree with
Walter's new suggestion to adopt the position that IBIS only defines the
measurements. He said describing the measurement was one part, but the
purpose was to establish the data to be used in the behavioral model.
Simulation is directly linked to a behavioral model being useful, so the IBIS
spec should address both. He felt this discussion was primarily interested in
how the model should be interpreted to get an unambiguous simulation from the
model data. He said portions of the task could be editorial, but we still
have the issue of [Pullup Reference], etc., and their relationship to this
local ground. The "absolute" ground language can be replaced by "common" or
GND, but we still have to make sure we know what/where is the local ground
reference for that specific buffer. When we are doing a simulation with
different local grounds for different buffers, that's the issue that needs
to be addressed. Radek again suggested that we might extend the Pin Mapping
keyword with a new column or add a new keyword to identify the ground pin for
each buffer. Walter agreed that Radek's suggestion of adding the new keyword
would make the behavioral model better. He suggested it might be done as a
separate BIRD. Bob again expressed his concern that adding specification of
this local ground reference would cause problems. He said the existing spec
was fine for the DUT, and worried that adding the new reference node risked
breaking older models. Radek said the proposal would not affect older
models, and suggested that it would allow model makers to specify the common
ground location. If it weren't specified, then we might fall back on
rules for interpreting the model, but it is best to give the model maker the
ability to specify the reference. Walter noted that existing models didn't
even have the ambiguity unless pd_ref and gc_ref were non-zero. Arpad
expressed concern for the language, and suggested "common reference" instead
of "common ground". Radek was fine with this, but Walter didn't feel the
"common ground" language was problematic since we were specifying the local
reference from which any non-zero voltage values in pd_ref, pu_ref, etc.
were measured.
- Arpad: We are at the time limit.
- Let's think about coming up with the right word for the common reference.
- Let's also think about Walter's question about whether we can reduce the
ground language cleanup task to an editorial effort if we treat the current
IBIS spec as defining measurement only.
-------------
Next meeting: 09 February 2016 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
