Minutes from the 25 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 25 July 2017
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
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
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:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Ambrish: Motion to approve the minutes.
- Mike L.: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
BIRD189:
- Discussion: Arpad introduced two topics that had been the subject of email
discussions and discussions in the Interconnect Task Group meetings. The
subjects were how to terminate any unused ports in the Touchstone or ISS
Models used in an Interconnect Model, and the question of reference terminals.
Bob Ross noted that most of these discussions would be handled in Interconnect
meetings, but some discussion could be done in ATM in case certain people only
attended ATM meetings. Arpad recapped some public and private email threads
over the previous week in which many people had given their input on
s-parameter termination. Arpad noted that his bottom-line conclusion was that
perhaps we should revert to using the built in reference impedance values in
the Touchstone file (version 1, or version 2). The question was then what to
do with IBIS ISS models, which have no equivalent concept. Bob noted that
discussions had gone back and forth on using the Touchstone reference
impedance(s) and that using them might be easier than other solutions, but
this left the issue of getting different answers than ISS models that lack
the concept of a reference impedance. Arpad noted that one option might be
to add a parameter to IBIS-ISS that would act like the Touchstone reference
impedance. Bob noted that he and Radek had concerns about using the
Touchstone reference impedance, which is why this had become a big decision.
Ken asked if there was universal agreement that this is a spec issue instead
of an issue for EDA tools. He noted that tools offer the user various options
for terminating unused terminals. He said we'd been dealing with similar
issues with connector models for quite some time. He suggested this might be
handled with a note that tools may have various options for termination.
Arpad agreed that this was a valid point, but said he thought it was important
to address it in the spec because the Interconnect Models have a Sub-Param
Number_of_terminals, which does not have to match the number of terminals in
the underlying Touchstone file. Therefore, we need to at least mention in the
spec that the possibility for unused ports in the underlying model exists.
Arpad also noted that he thought the concept of the unused ports in the
underlying model was that we wanted to pretend they don't exist. He said
this seemed like a different concept than simply terminating a port to model
an impedance mismatch or some physical connection.
Ambrish asked if this discussion could have any bearing on BIRD158. Arpad
said he didn't think so, because BIRD158 shouldn't involve any unused ports.
Bob R. noted that reference terminal discussions could affect BIRD158. Arpad
agreed, and said the first order issue of the discussions was the termination
value and the second order issue was the reference terminal.
Mike L. suggested that the model maker can only advise on what to do in this
case. Since the spec is giving the facility for the model maker to provide
this advice, the reference impedance the model was made with seems like a good
piece of information to provide. However, he did not think the spec should be
prescribing any termination requirements. Arpad said at some point we would
need to arrive at a collective decision. Arpad noted that we might consider
removing the Unused_port_termination Sub-Param and section altogether. The
group agreed to continue discussions in the Wednesday Interconnect meetings.
BIRD166.3:
- Discussion: In Walter's absence, Arpad noted that BIRD166.3 had been formally
submitted to the Open Forum. He asked everyone to review it. Arpad and
Curtis noted that they had spoken with Walter and confirmed that this new
draft intentionally removed all changes from the time domain section.
Therefore, this new draft changes the sequencing so that the Rx1 Init()
output is convolved with the downstream channel prior to calling Rx2 Init(),
but it makes this change only for the statistical flow. The Init() flow
portions of the statistical and time domain flows are different in BIRD166.3.
Bob R. noted that there was no markup with BIRD166.3, so it was hard to see
what was changed.
BIRD190:
- Discussion: Ambrish said he wanted to move forward with this, but he didn't
want to proceed without Walter here. Ambrish noted that BIRD 190 merely
states a warning. He noted that Radek had suggested changing the "note" to
"warning" in the previous meeting. Ambrish said he thought a "note" was a
statement of fact, and a "warning" said to watch out for something that may
or may not happen. Arpad noted that we don't have a hard rule that says the
ATM must make a recommendation on every BIRD that is submitted to the Open
Forum. Ambrish said he preferred to have some consensus recommendation from
ATM, though it need not be unanimous. Bob R. said one big problem was that
both BIRD166 and BIRD190 could be presented to the Open Forum, but if they
contained mutually exclusive changes there could be a collision if both were
approved. Arpad and Curtis noted that BIRD166 and BIRD190 didn't necessarily
overlap anymore, as BIRD190 only affected time domain flow and the new
BIRD166.3 only affected statistical flow.
Fangyi noted that he still had problems with BIRD166.3. In statistical
flow it caused an explosion in the number of crosstalk IR terms that had to
be presented to each successive Init() call in the chain. In general, the
lack of the self-response of each channel causes problems later if they are
needed. He said that a loop couldn't be handled without the self-IR because
you only get to call Init() once for each device. Michael M. asked if we were
back to this being a problem with doing more than just initialization in
Init(), and asked if we needed a separate function for IR modification for
statistical flow. Arpad noted that merely separating the initialization and
simulation portions of the Init() function would not solve this flow problem.
If the simulation portion of the current Init() function were simply moved to
a new function, the same problems would exist. Fangyi said this was one
possible option, and you could pass Init() and this new function different
inputs. Ken suggested that this would be pretty major surgery for a ten-year-
old spec. He said this issue was like anything else, and that you had simple
models that couldn't do everything and more complex models that were needed
for more complex tasks. He felt it was unnecessary to try to make Init() only
models handle complex repeater chain simulations.
BIRD191.1:
- Bob R.: [sharing BIRD191.1 draft email]
- Changed the title of the BIRD to "Clarifying Locations for Si_location and
Timing_location"
- Abided by suggestions from the previous meeting.
- Removed the new "Buffer" location that was proposed in the original BIRD191.
- The existing spec. has "Die" and "Pin" locations ("Pin" is default).
- This revisions states that "Die" will always mean the buffer location,
even if an Interconnect Model has separate buffer, pad, and pin locations.
- The existing "Die" is really the same as buffer terminal in the existing
spec, i.e., there is no concept of on-die interconnect prior to BIRD189.
- Four reasons for making this simplifying assumption are stated in the
Background Information/History at the end of the BIRD191.1 text.
- Michael M.: Do we view this as something that has to be resolved, as part of
the interconnect proposal, for IBIS 7.0?
- Arpad/Bob R.: Yes, it's related to BIRD189 so it would be good to deal with it
simultaneously.
- Arpad: It's probably not a show stopper for BIRD189, but there could be some
ambiguity without this BIRD.
- Arpad: How does this relate to [External Circuit] or [External Model]?
- In those multi-lingual sections we talk about where to probe the waveform.
We mention "pad", but now that pad is not the only thing on the die and we
also have buffer terminal, we may need to redefine these choices.
- Bob R.: We don't support [External Circuit] with Interconnect Models, so I
think we don't have an issue with [External Circuit].
- Arpad: Right, that may eliminate this issue for [External Circuit].
- Bob R.: I will think about effects on [External Model].
- Arpad: Bob R. and I will look into this issue offline.
- Mike L.: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Bob R. and Arpad to look into any BIRD191.1 interaction with [External ***].
-------------
Next meeting: 01 August 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
