Minutes from the 08 October ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 08 October 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
Stephen Slater
Maziar Farahmand
* 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:
- None
-------------
Review of ARs:
- Ambrish to look into adding graphic or improved example to BIRD197.5.
- In progress.
- Randy to add "post-process" versus "post process" to the IBIS 7.0 known
issues document.
- In progress.
- Randy and Michael M. to invite DDR memory and controller vendors to comment
on new protocols.
- In progress. Arpad asked if this topic was still relevant and needed to be
an active AR. He noted that at the previous meeting someone had mentioned
that JEDEC, for example, isn't getting involved in writing specs like this.
Walter noted that he had thought JEDEC meetings might be a good place to
invite people to contribute, even if JEDEC itself didn't get involved with
this sort of discussion directly. Walter thought the AR should stay open
because we need to get other memory and controller vendors involved in the
DDR5 DQ Write protocol discussions.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the October 1
meeting. Walter moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
New Attendee:
- Todd Bermensolo of Keysight introduced himself. He is interested in AMI
modeling. His experience has been on the creation and usage side, and now
he is gaining experience on the EDA tool side of the process.
BIRD197.5 DC_Offset:
Arpad asked if the current status is that we are waiting for a new draft version
in which DC_Offset is an In parameter only. Walter and Ambrish agreed. Walter
noted that he had produced a version, and Ambrish was going to add an example.
Ambrish noted that Fangyi had also had comments on Walter's version. Walter
suggested that once we have Ambrish's example we can work on further clarifying
the language. Arpad said this topic would be continued next week.
BIRD198.1:
Arpad noted that the authors had sent us a response to our earlier feedback. He
noted that Walter had prepared some slides for this meeting to continue the
discussion.
Randy noted that we had asked the authors to provide an example of the use of a
Model_Selector. The authors had replied that they really wanted this feature,
and they provided an example of a DDR3/4 combo phy where the on-die capacitance
value would change between the two modes. Another example was power-gating
affecting the value of the on-die capacitance.
Walter presented a new proposed syntax designed to meet the authors'
requirements. He proposed a new [PDN Group] keyword, each of which could
include multiple PDN models. He noted that he had tried to use names similar
to BIRD189. He noted one idea he had was to designate on particular Group as
the PDN models which would be used in combination with a BIRD189 interconnect
model.
Walter noted that each model contains a C and two Rs (series and parallel).
Walter thought corners should always be typ/slow/fast as opposed to typ/min/max
but noted this was up for debate. Arpad noted that in our response we had asked
the authors if they included magnitude based typ/min/max corners and
typ/slow/fast corners simply to be consistent with the rest of the spec, or if
there was a need for both. He expressed concern that the authors may not have
understood the question. He noted that in the latest response they had removed
typ/min/max corners from their proposal, but they had left the C_pdn, etc.,
names without the _corner suffix. So they now had typ/slow/fast corner values,
but the parameter names without _corner looked more like the typ/min/max version
of the C_comp parameters. Randy agreed that there might have been confusion in
the correspondence. He noted that he thought there really only needed to be one
way to specify the corners, but we need to make it clear and be clear that any
column selection applies to the C and both the R values. Walter added _corner
to the names in his proposal. Randy noted that he would prefer the name
[On Die PDN Group] for the keyword. Bob said he preferred that we not use
"Group" at all in this context but said he didn't yet have an alternative.
Bob asked if there was in fact a need to support both. He asked if decoupling
capacitors had strong and weak values that were tied with the silicon process,
or are they separate discrete components not tied to silicon. If both
possibilities exist, then we might need both types of corners. Randy noted that
corners for these PDN components might not align with transistor behavior at
all. Arpad and Bob noted that we might want to preserve both types of corners
if this were the case.
Arpad asked if we needed a typ/min/max version. Walter said we had typ/min/max
for C_comp only because the spec originally defined it that way. Bob noted that
C_comp tracked silicon process and having the original typ/min/max version was
probably a mistake. Arpad said it was not a mistake, and he noted that when
C_comp was first defined in the spec it was intended to include both the
transistor parasitics as well as the parasitics of the metal conductors which
are placed between the transistors and the die pads. The capacitance of
these metal layers does not track the silicon process variations. Arpad noted
that he was not familiar with how on-die PDN circuits are implemented
today, so he wasn't sure how they should be modeled correctly for these
corner cases.
Randy said he didn't think the typ/min/max version made much sense, since when
the model maker is creating a model they want to ensure corresponding values of
the parameters are used together. If you choose one column (typ/slow/fast) you
should get that same columns value for all the parameters. Arpad said that if
PDN values didn't vary with the silicon process we might need typ/min/max too.
Walter's syntax example contained two PDN Groups, each of which contained two
PDN decoupling models, one for VSSA and one for VSSB. He modified the example
so that one Group used typ/slow/fast keywords with the _corner suffix, and the
other example used typ/min/max keywords without the _corner. Arpad noted that
it was understood that for typ/slow/fast keywords you should get the value from
the same column for each of the parameters (i.e., the user/tool should not mix
C_pdn slow with R_pdn fast, etc.). He suggested that we should add a similar
statement for the typ/min/max corner values. Bob, however, wondered if we
should allow tools to mix the typ/min/max versions to create best or worst
case decoupling at their discretion.
Walter said he would send the modified proposal presentation to Arpad, Randy,
Bob, and Mike L. for further discussion prior to responding to the authors.
Enabling Back-channel in Statistical Mode:
Walter reviewed his Impulse Optimization Training presentation, which summarized
the previous discussions and the options.
- Alternatives (slide 2):
- Iterate AMI_Init().
- Iterate a new AMI_Impulse() function.
- do nothing...
- Do we want to formalize a way for EDA tools to iterate one of these two
functions to enable IC Vendors (model makers) to optimize/train a channel using
IR processing?
Arpad noted that he had spoken with Vladimir about the proposal, and Vladimir
felt with should leave the optimization routines up to the EDA vendors. If the
model maker still wanted to do their own optimization, then they could handle it
with a proprietary scheme. This would likely imply that the Tx and Rx came from
the same vendor and could communicate. He feared the spec would have to be too
long and detailed if it were to describe how this communication takes place.
Walter said we do that already with BIRD147. BIRD147 says the Tx and the Rx can
agree to communicate via a protocol of their choosing. This proposal would
simply extend that capability to AMI IR processing instead of waveform
processing. Arpad noted questions about what would be used as the eye metric
(eye opening, SNR, etc.) and asked whether it was possible to describe those in
a BIRD147 type protocol. Walter said it was, and noted that his earlier
presentation had included some possible approaches for the DDR5 DQ Write
protocol. The protocol could specify how the Rx generates the eye metric, or
an alternative method would be to have the Rx send its modified IR back to the
Tx so the Tx could handle computing the eye metric. Wei-hsing said he agreed
with Arpad. There are many ways the Tx and Rx could communicate. The Tx .dll
could even load the Rx .dll itself and directly handle the optimization. Walter
noted that the goal was to model the optimization done by the Tx in the real
system.
- Iterate Existing AMI_Init() (slide 4)
- Done by EDA tools now.
- Blind sweeps
- Intelligent sweeps
- User input
- AMI_Init() would need to maintain history. EDA tool would have to call
AMI_Init() differently the first time.
- Iterate AMI_Impulse (slide 5)
- Could be a more efficient version of iterating with AMI_Init(), since
AMI_Impulse() would maintain the history in memory.
- Do nothing (slide 6)
- IC Vendors and EDA vendors would deliver proprietary solutions.
- Do IC Vendors want that, or do they want standardized AMI models that should
give the same answer on all tools?
Mike L noted that the AMI_memory_handle passed in to AMI_Init() is a pointer to
the memory block allocated by the model. One the first call to AMI_Init() what
it points to is expected to be null. On subsequent calls the handle would
instead point to the block returned by the initial call to AMI_Init(). Radek
agreed that this was all that was needed to iterate with AMI_Init(). Walter
agreed that this was one solution. He noted that AMI_Resolve() could have been
handled the same way, but we had instead added the new AMI_Resolve() function.
- Mike L.: Motion to adjourn.
- Radek: Second.
- Arpad: Thank you all for joining.
AR: Walter to send today's modified BIRD198 syntax proposal to Bob, Randy and
Arpad, and Mike L.
-------------
Next meeting: 15 October 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
