Minutes from the 1 May 2018 ibis-atm meeting are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 01 May 2018
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
Curtis Clark
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: Walter Katz
Todd Westerhoff
* Mike LaBonte
SPISim: Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Mike LaBonte took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that Mike LaBonte was taking minutes. He also suggested we might
discuss Bob's recent email. Bob said that email was sent to the interconnect
group, and should be discussed the next day.
-------------
Review of ARs:
- Michael M. to produce BIRD189.6 draft18 version 9 and email it to the list.
- Done (should be BIRD189.5 draft18 version 9).
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob noted that the AR should have stated "BIRD189.5 draft18 version 9".
- Mike L.: Motion to approve the minutes with correction as noted.
- Bob: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD189 related issues:
- Discussion: Michael M. reaffirmed that Bob's rail proposal would be discussed
the
next day.
BIRD158 related issues:
- Arpad showed a version of BIRD158.7 with all recently agreed updates made.
- Discussion: Arpad noted that he had an AR to check with Fangyi and keep all
original
authors listed. With the informational messages recently removed from
BIRD189, we
should refrain from discussing the topic of channel referencing in BIRD158.
The text
explaining the Rx figure has been updated. Arpad said it should be ready to
submit
to the Open Forum. Radek noted that the channel figure had been removed. He
said
that he had already pointed it out that with A_gnd being now the global
ground it is
critical to state that the channel needs to be referenced to A_gnd as well.
Otherwise
there would be a direct connection between Tx and Rx bypassing the channel
and that is
incorrect. For that reason the removed figure should be reinstated. Arpad
said that
would be just educational material. Radek felt IBIS should describe what is
allowed.
Arpad said in SPICE we get an error is there is no path to node 0, asking if
it our
job to prevent such mistakes, noting that we had discussed preferring not to
do that.
Michael M. asked if there could be a cookbook. Arpad noted that Walter had
written
an email about IEEE P370, giving an example of a simple statement about
connections.
Radek said that seemed like a digression. Arpad said that polarities could be
reversed, but that would be an unconventional use. He asked if we really
needed to say
anything about it in the spec. Michael M. asked if such a statement would be
parsable.
Radek said yes, and the package should be referenced to A_gnd at the pin
interface.
Arpad said the packages could be referenced in several different ways, and we
might
need to show that. The deleted drawing shows only a subset of the
possibilities.
Radek disagreed, saying that at the pin interface there should be just two I/O
terminals and A_gnd. Arpad said we would not want to imply that just one way
is the
only way to do it. Radek disagreed, saying that having two I/O terminals and
A_gnd
is the only way. Furthermore, package modeling allows other terminals to be
present
at the pin interface and. For example, with no guidance it might not be clear
how
to connect a 6-port model to a 4-port channel. Randy suggested that that
would be
white paper material, and it was not what our specification is for. He was
prepared
to motion to move forward.
Bob noted that the BIRD158 format was for AMI usage only, and that delineating
reference connections was irrelevant in that case. Mike L. asked if IBIS
wasn't
clear on how to connect AMI buffers before we introduced Touchstone analog
models.
Arpad said we had issues in that area since the beginnings of the spec with
figures
package capacitance and C_comp connected to âGNDâ. Those problems were
masked by
not doing power delivery analysis in those days as we do them today.
Radek said now that we have A_gnd, new questions are raised about how to
connect, and
that this topic should not be excluded. He said we can not wait for another
cookbook.
Michael M. suggested we could have articles in industry magazines. Arpad
agreed
with that suggestion. He asked what problems would exist if we did not have
the
channel figure. No one raised any problems. Bob said the BIRD suggests a
common
reference throughout, and that node 0 is acceptable for that. Michael M.
suggested
one or maybe a couple drawings would be needed, and that it would take too
long to
add those, given our expected IBIS 7.0 schedule. We could instead have
articles, a
cookbook, and maybe a panel discussion. Arpad said we would need to work
carefully
on the verbiage, noting that packages can also be described with IBIS-ISS.
Radek
said without guidance someone could allow the channel to be floating, for
example.
Arpad said he did not want to hold up IBIS 7.0.
- Randy moved to submit the BIRD as is to the Open Forum.
- Michael M. seconded.
- Arpad: anyone opposed?
- Roll call vote:
Intel: Yes
Keysight: No
Mentor: Yes
Micron: Yes
SiSoft: Yes
Teraspeed Labs: Yes
- With 5 Yes and 1 No, the motion passed.
AR: Arpad to submit BIRD158_new to Open Forum
Agenda discussion:
- Arpad showed the list of potential agenda topics. He noted that Walter was
not present,
and therefore we should not discuss his drawing. Arpad asked for suggestions
on what
to discuss next week.
Michael M. asked if complex C_comp would be part of IBIS 7.0. Randy said it
would
be after IBIS 7.0. Arpad asked if it was still needed. Randy said yes,
because
it is a buffer level feature. Bob agreed. Mike L. asked if EMD would address
this.
Arpad asked if we discuss EMD in this group. Randy said this was a buffer
level issue.
Michael M. said it was important.
Mike L. said the FEC topic had been brought up at the DesignCon summit, and
that it
was really about how to let models provide post-simulation analysis.
Radek said the third item was important, using Terminator models for AMI Rx.
Arpad said the fourth item about thresholds was described as a model issue,
not
a specification issue. Michael M. asked if a buffer can be used in several
contexts, how do you communicate the context. Arpad suggested we could point
to
other specifications. Mike L. suggested that this seemed related to FEC and
other
needs for post-simulation analysis. Bob asked if the issue was tied to IEEE,
JEDEC
specifications, etc. Arpad said it was more about things the model should
not violate,
not the operation of the model itself. For example, the TTL high and low
limits.
That was not model behavior. Mike L. noted that IBIS already contain
information
that is not about model behavior. Bob said it would be referring to
something that
can be measured, such as an eye diagram. Arpad noted that that kind of
information
helps EDA tools automate the process. Bob asked if a single buffer could be
used
for multiple industry specifications.
Arpad asked if removing single ended characterization requirements for
differential
buffers was important. Michael M. said Vmeas, Cref, etc. should not be
required
for diff pairs, because they are not defined for those buffers. Mike L. said
that
would be a rule relaxation, and should be no problem. Bob said that that was
a
mistake made in AMI. Arpad said the issue was about diff pairs, not AMI,
noting
that in IBIS, diff pairs are really a pair of single ended buffers.
Michael M. said the guidance for how to use power aware keywords such as
[ISSO] with
AMI was not clear. He suggested it should be defined in the specification if
and how
[ISSO] etc. affect AMI buffers. Arpad said that could become a big
discussion topic.
- Michael M.: Motion to adjourn.
- Mike L.: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 08 May 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
