Minutes from the 10 September ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 10 September 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
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:
- Walter to draft an alternate proposal for BIRD198.1.
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the September 03
meeting. Michael M. moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
Jitter HF/LF components and jitter amplification:
Michael M. noted that it will be a while before he has a new version of this
proposal. The next update will be in the form of a new BIRD draft, and it will
pursue a spectral distribution approach. Michael moved to put this topic in the
Tabled Topics section. Arpad seconded. There were no objections.
DC_Offset BIRD:
Walter moved to table this topic too, because it is potentially related to the
BCI for statistical topic. Fangyi asked how they are related. Walter said that
the DDR5 DQ Write protocol discussion would explain the connection. It might be
useful to use the output value of DC_Offset to return the VREFDQ value that the
Rx model ends up using after the training is complete. Michael M. seconded the
motion. There were no objections.
BIRD198.1:
Walter reviewed his "BIRD 198 Response" presentation.
Walter noted that he thought introduction of a new Model_type was unnecessarily
complicated. He proposed a new [PDN Model] keyword that would contain the
series R and C, a parallel Rleak, and two bus labels (or signal_names) that it
connected. At the [Component] level, an [On Die PDN Models] section could
contain multiple [PDN Model]s. Walter noted that he agreed that this type of
simplified RC model would be good to have for PDN modeling.
Walter posed the following questions:
- Do we need bus_labels, or are signal_names enough?
- Why do we need the concept of [Model Selector]s in this case?
- Models and [Model Selector]s were designed for Pins, which are configurable.
- What does it mean to have selectable PDN models?
- This proposal deals with supply rails not Pins.
- Do we need the amplitude version of typ, min, max, or can we just use the
process corner version?
- How should this interact with BIRD189 (rules for the interaction)?
- Always instantiating both is the easiest rule to define and understand.
- One-or-the-other is the second easiest.
- Complicated overlapping usage rules are hard to understand.
Arpad noted that he thought the authors had added Model Selector simply because
they had added a new Model_type, and [Model Selector]s choose models. He noted
that he liked Walter's attempt to simplify things, but he thought we might want
to keep the magnitude and process corner versions of typ, min, max as the
authors intended. Arpad noted that there might be some technical fine tuning
necessary with Walter's proposal (keyword vs. Sub-param, etc.). Walter said
that he had focused on proposing something similar to what the authors had,
and there could be fine tuning.
Bob said [Model Selector] support isn't strictly necessary, since BIRD198.1
proposes a new Model_type, and we already have the Series and Series_Switch
Model_types that aren't used with [Model Selector]s. Bob said he thought
Walter's proposal was promising. Bob said he wasn't sure how a corner for
an on-die decoupling model would be associated with a semiconductor process
corner. Arpad said it might depend on how it's implemented. If it's
implemented with metal layers it might be independent of the silicon process
corner, but if it's implemented as a transistor it might depend on it.
Walter said that we could add process corner and magnitude options to his
proposal.
Walter said the concept of [Model Selector] isn't needed here. It's typically
used for things like selecting different on-die termination impedances. What
does it mean to have two different models between VDDA and VSS? Arpad said it
might be used for user convenience, e.g., to switch between a per DQ decoupling
model or an overall decoupling model. It might also be used to allow what-if
analyses where the models may not match physical reality but are useful for
finding a solution space. Bob noted that we could add a new keyword if we
needed a different type of Model Selector. He said he agreed with Walter that
Models and Model Selectors are Pin focused and this proposal is bus_label
focused.
Radek asked about the rules for interaction with BIRD189 models. Walter noted
instantiated, then they could plan accordingly. You could put simple parallel
that if a model maker knew both the BIRD189 model and this new model would be
terminations in this new model and more complicated series distributions in
a BIRD189 model if necessary. Randy noted that the parser would not have any
complicated rules to check if we went with the approach of instantiating both
model types.
Randy took the AR to draft a response to the authors containing:
1. Description of Walter's proposal.
2. Question about the intended use of Model_Selector.
3. Request for feedback on rules for interaction with BIRD189.
Enabling Back-channel in Statistical Mode:
Walter asked for questions or comments on the previous week's presentation.
Fangyi asked what IR matrix is passed to the proposed new function. Walter said
it was the same IR passed to the Init() function. Fangyi asked if the IR
returned by the Rx function gets passed back to the Tx. Walter said it did not.
Walter said that each iteration was just running the entire channel over again
with a different set of tap coefficients.
Walter shared a presentation about developing a DDR5 DQ Write Protocol. Walter
noted that his goal was to describe the issues to be resolved. He hoped we
could then attract input from other DDR5 IC vendors.
- Overview (slide 2)
- DDR5 DQ Write Protocol
- How does the hardware train?
- What can the Tx tell the Rx?
- What can the Rx tell the Tx?
- Generic Tx N-Tap FFE protocol
- Hardware training diagram (slide 3)
- Controller (Tx) trains the memory (Rx).
- What can it set?
- VREFDQ register.
- Gain register.
- Tap registers.
- Looking for target BER of 1e-16 in hardware training isn't practical.
- Controller sweeps VREFDQ up and down until errors occur, then it chooses
something in the middle.
- Controller also varies the phase of DQS and looks for errors, then it
chooses something in the middle.
- Hardware likely looking for a BER between 1e-3 and 1e-5 when it's sweeping
and looking for errors.
- What can the Tx tell the Rx? (slide 4)
- The VREFDQ, Gain, and Tap register settings.
- JEDEC standard specifies the min and max values.
- What can the Rx tell the Tx? (slide 5)
- Value of VREFDQ (Volts)
- This is the value that could be returned as the output value of DC_Offset.
- Value of Gain.
- Value of each DFE Tap (Volts)
- Eye Metric information, possibilities include:
- Eye Height, Eye Width, Eye area, COM at a specified BER.
- The IR at the latch.
- The Tx may also need to know additional impairment info (RxDj, etc.)
Walter noted that the Eye Metric decision is critical. If the Rx computes the
metric and returns it, not much data is exchanged. If we have to pass the IR
at the latch back to the Tx so it can compute the metric, then it could affect
performance. BIRD147 had always assumed the Rx would do the training, so data
exchange between the Tx and Rx was minimal. BIRD147 implemented a simple file
I/O approach for GetWave() training. If we have to pass the IR at the latch
back to the Tx, then the file gets larger and affects performance.
Walter noted that Fangyi had raised a point about training nibbles instead of
individual lines. Walter said we could create an additional protocol to allow
4, 8, etc. bits to be trained simultaneously. For now, Walter wanted to focus
on a single-bit DQ Write protocol.
Fangyi (referring to slide 5) noted that in the physical system the controller
(Tx) probably only gets an eye metric back. Walter said that the controller
sweeps VREFDQ and finds out when errors occur, that's the metric for hardware
training. Fangyi agreed. Walter noted that when developing this BCI protocol
we can be smarter than the hardware and have access to more information (e.g.,
the IR at the latch) if necessary.
Walter asked for ways to get more contributors to this discussion before we
go into further details. He asked if there was a way to get these presentations
in front of a JEDEC meeting. Michael M. and Randy said they would each do some
research internally and see if they could identify any possible audiences.
- Walter: Motion to adjourn.
- Michael M.: Second.
- Arpad: Thank you all for joining.
AR: Randy to draft a response to the BIRD198 authors.
-------------
Next meeting: 17 September 2019 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
