Minutes from the 10 December ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 10 December 2019
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: * Ambrish Varma
Ken Willis
Kumar Keshavan
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
Ming Yan
* Todd Bermensolo
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
SPISim: * Wei-hsing Huang
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that there had been a mix-up in the agenda email. He confirmed
that we will have an ATM meeting on December 17th, and then the following
meeting will occur on January 7th, 2020.
-------------
Review of ARs:
- Randy and Michael M. to invite DDR memory and controller vendors to comment
on new protocols.
- In progress.
- Walter to prepare a draft BIRD based on the AMI_Impulse approach.
- Done.
- Bob to submit BIRD197.6 to the Open Forum.
- Done.
- Mike L. to send out a BIRD181.2_draft2 with the changes as noted in the
meeting.
- Done, sent to ATM several hours after the previous meeting.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Review of the minutes for the November 26 meeting had been deferred at the
December 3 meeting:
Arpad asked for any comments or corrections to the minutes of the November 26
meeting. Walter moved to approve the minutes. Randy seconded the motion.
There were no objections.
Minutes for the December 3 meeting had been sent to ATM, but several
participants had not received them. Curtis then noted that he discovered a spam
filter had captured his. Randy moved that we wait until the next meeting to
review them. Walter seconded. Justin sent the minutes out to ATM again as a
precaution.
-------------
New Discussion:
BIRD198.1:
Randy said he, Arpad, Bob, Mike L., and Walter had received a new response from
the authors. Walter noted that he had been reviewing it, and he shared the
response and summarized his view the important points:
- The authors agree that [PDN Group] should be scoped under [Component].
- They don't like the use of the ISS syntax.
- They think magnitude versions of typ/min/max don't make sense for this.
- Walter and Randy noted that we are in agreement on this point.
- There are questions about whether things align with process or not.
- They provide several syntaxes.
Walter reviewed the important points from their example #2:
- Concept of a PDN domain
- e.g., all the interconnect models between Vcc and Vss
- rails could be bus_labels or signal_names
- Their example provides 3 models for the domain.
- PDN domain becomes something like a Model Selector.
- Another PDN domain is defined for interconnect between Vdd and Vss.
- again several different models
Randy referred to a figure a on slide 7 of their response that helped
illustrate their domain concept. He noted that they wanted to represent
separate MOS and MIM caps. Randy noted that they're saying that the MOS caps
are aligned with transistor process corners, but with the MIM caps there's no
relationship to process corners so they have a Model Selector type approach
for the MIM caps. Randy noted that both the MOS and MIM caps exist at the same
time in parallel. They define separate PDN_for_VCC_MOS and PDN_for_VCC_MIM
domains. Randy noted that since the MIM caps do not depend on any
process-voltage-temperature conditions, their example 2 MIM domain repeats the
same parameter values in all three columns. Randy suggested NA could be used
instead for the repeated columns.
Walter suggested the rail connections should be handled with two separate lines,
Rail 1 and Rail 2, either of which could be a bus_label or a signal_name. Bob
asked about pin_names, and Walter said the purpose of this proposal was supposed
to be simplicity. People could use BIRD189 syntax if individual pin_name
connections were required.
Bob asked about how this could be included in multiple [Component]s. Randy
agreed that you might have one die with several different packages. Bob
suggested it might simply be repeated in multiple [Component]s, but this could
be wasteful. Bob suggested the concept of pointing to a PDN model that is not
scoped by [Component], but Arpad pointed out that this could be a problem if
a PDN model refers to bus_labels or signal_names that are [Component] specific.
Bob agreed this wasn't the solution.
Arpad commented on Randy's suggestion that NA might be used for columns instead
of repeating identical values. Arpad noted that we had to be very careful to
explain the intent of NA, which actually stands for not-available. He noted
that in some places the spec states that if min or max values are NA, then the
EDA tool should fall back to the typ value. However, the meaning of "fall back"
can be vague, especially with I/V curves and related parameters where you might
violate Ohms law or something fundamental if you fall back in one area but not
in another. Arpad noted that he would probably prefer to keep the repeated
values instead. Randy noted that he understood Arpad's point.
Radek asked if all 3 parameters C_pdn, R_pdn, R_leak were required. Walter and
Randy said yes. Bob said it's a fixed topology, and we could define default
rules if we wanted to do so. Radek said the BIRD should clearly state it one
way or the other.
Walter suggested he and Randy take an AR to redo the examples with a new syntax
proposal and deal with NAs, bus_label vs. signal_name, etc. Randy agreed.
Enabling Back-channel in Statistical Mode - AMI_Impulse BIRD:
Walter reviewed his draft BCI Statistical BIRD based on AMI_Impulse():
- New parameter BCI_Training_Mode
- Usage In
- allowed values "Impulse", "GetWave", "Dual"
- default is "GetWave" for backward compatibility
- New AMI_Impulse() function
- Like AMI_Init() in terms of arguments except:
- AMI_memory argument is handled as it is in GetWave(). AMI_memory will
contain the value returned by AMI_Init().
- Has BCI_parameters_in and BCI_parameters_out arguments that allow the EDA
tool to pass BCI protocol defined strings between the Tx and Rx models'
AMI_Impulse() functions.
- EDA tools should keep a copy of the impulse_matrix before passing it to the
initial call to AMI_Impulse() because the iterative calls to AMI_Impulse()
will modify the impulse_matrix.
- AMI_Impulse() will know the values of number_of_rows, aggressors, etc. from
the original call to AMI_Init().
- Flow with a single Tx/Rx channel is defined
- Flow with repeaters is defined
- Every Tx and Rx in the entire chain must support the protocol.
- The AMI_Init() portion of the flow is identical to that of the existing
time domain repeater simulation flow. (IBIS 7.0, pg. 264)
- The AMI_Impulse() portion follows the same flow, except with calls to
AMI_Impulse() replacing the calls to AMI_Init()
- BCI_parameters_out string is passed down the entire chain from one model
to the next until the final Rx then loops back to the original Tx.
Arpad asked if, in the case of redrivers, each Rx was optimizing its own Tx,
i.e., optimizing channel-by-channel. Walter said he would typically expect the
final Rx to optimize everything, but the BCI protocol could define it. Since
we're passing the BCI_parameters_out along all the way down the chain, the
first Rx could optimize the first Tx if it wanted to, or the last Rx could
do it. It's up to the protocol itself.
Ambrish asked if a model that supported "Dual" BCI_Training_Mode would still
perform a GetWave() based BCI optimization starting with the initial channel
IR. That is, the GetWave() optimization flow would not start with the final
IR arrived at by the statistical BCI flow. Walter agreed. The GetWave()
optimization flow does not use the final IR arrived at by the statistical
optimization flow.
- Walter: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.
AR: Walter and Randy to work on a new iteration of a proposal for BIRD198.
-------------
Next meeting: 17 December 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
