Minutes from the 04 August ibis-atm meeting are attached.
The following document, which was discussed during the meeting, has been posted
to the ATM work archives:
http://ibis.org/atm_wip/archive/20200728/walterkatz/DDR5%20DQ%20Write%20Protocol/DDR5_DQ_Write_Protocol.pptx
IBIS Macromodel Task Group
Meeting date: 04 August 2020
Members (asterisk for those attending):
Achronix Semiconductor Hansel Dsilva
ANSYS: * Curtis Clark
* Wei-hsing Huang
Cadence Design Systems: * Ambrish Varma
Ken Willis
* Jared James
Google: * Zhiping Yang
Intel: * Michael Mirmak
Keysight Technologies: Fangyi Rao
* Radek Biernacki
* Ming Yan
Todd Bermensolo
* Rui Yang
Marvell Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft (Mathworks): * Walter Katz
Mike LaBonte
Teraspeed Labs: * Bob Ross
Zuken USA: * Lance Wang
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- Randy to submit the Component_Name and Signal_Name BIRD draft to the Open
Forum as an official BIRD.
- Done. Submitted as BIRD207.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the July 28
meeting. Walter moved to approve the minutes. Michael seconded the motion.
There were no objections.
-------------
New Discussion:
DDR5 DQ Write Protocol:
Walter briefly reviewed his presentation "DDR5_DQ_Write_Protocol (BIRD147/201)"
from last week. (see last week's minutes for the overview discussion)
Walter noted that he had proposed two different protocols, a JEDEC protocol that
exchanges actual register settings, and a Generic protocol some people might
want to use for various reasons such as developing something before a JEDEC
standard was released.
Walter reiterated that discussions about the eye metrics to be returned by the
Rx would likely take time. He noted that the Rx IR is processed by the EDA tool
normally, and the EDA tool can convert it to a pulse response and generate
eye width, height, area, COM (essentially SNR). He said the Rx would generate
these and return them to the Tx in the proposed protocol. He noted that the Rx
could return the IR to the Tx, as it typically returns it to the EDA tool, but
for this protocol he is proposing that it return the eye metrics. This is
more like the way the actual hardware works.
Ambrish asked if the Rx could choose to return nothing at all. Walter said the
Rx has to return the metrics for these DDR5 DQ Write protocols. He said that
DDR5 memory (Rx) is told what to do by the Controller (Tx). All the
intelligence is in the Tx, and the Rx must return the eye quality information
so the optimization algorithm in the Tx can make use of it. He said this was
the antithesis of other standards like 802.x, where the Rx had the smarts and
controlled the optimization.
Walter reviewed the MATLAB function optPulseMetrics(), which he had developed
to generate the same metrics used in these protocols. The function takes an
IR as an input. Walter noted that the source code is available to anyone with
MATLAB, and that they would be putting the algorithm in the public domain.
Arpad asked which toolbox contained the function. Walter said it is part of the
SERDES toolbox, and that he would work to get it publicly available quickly.
Walter shared the MATLAB code itself and reviewed it. The function takes an
IR as in input and manipulates it such that the various metrics can be
generated. It provides the capability to automatically fall back to the first
BER for which the eye is not closed (eye area > 0).
Walter returned to the last slide of his presentation. He said it will be up
to IBIS to decide how to handle the protocol proposal. He will work to get
agreement on the details in ATM, and he will publish the protocol. Then IBIS
can decide if it wants to approve it and how the process would work (the process
for approving protocols is left unspecified by BIRD147).
Randy asked if there are protocols for other standards that have been released.
Walter said he was not aware of any. Ambrish said they had developed some with
IP vendors, and had published a protocol at DesignCon one year, but none of them
were really in the public domain. Randy asked if Ambrish would want any of them
to be public or if they wanted to keep them private. Ambrish said he wasn't
sure whether they wanted them private, or if it was just been too much work to
take them public without a specified process. Randy said he wanted to find out
how much interest there would be if IBIS created a process for approving these
protocols. Ambrish took an AR to find out if they would have any interest in
taking their protocols public.
Randy asked for clarification on slides 3, 4, 5 when they said the Tx sends "tap
indices" to the Rx. Walter said that he meant the Tx sends the Rx the actual
settings for the tap registers. Given this, slide 5 means (from last week's
minutes, with one addition to the JEDEC protocol VrefDQ item suggested by
Randy):
- What the Rx tells the Tx each iteration:
- JEDEC protocol
- Return the BER used
- Return the gain value corresponding to the register setting the Tx
requested
- Return the VrefDQ value corresponding to the register setting the Tx
requested
- Return the DFE indices and the DFE coefficients used
- Must return the metrics
- Generic protocol
- Return the BER used
- Return the gain register setting that gives the gain closest to that
requested
- Return the gain itself
- Return the VrefDQ register setting that gives the VrefDQ closest to
that requested
- Return the VrefDQ value
- Return the requested DFE indices (if they were supported)
- Return the DFE coefficients
- Return the same metrics
Ambrish asked if using an increment/decrement approach to adjusting the taps
would be easier to communicate. Walter noted that in the JEDEC DDR5 standard
the Tx is explicitly setting register values in the Rx. With JEDEC DDR5 it's
cast in stone, and the Tx has all the smarts. With things like 802.3.xx, the
options aren't so tightly defined, and you need a handshake back and forth
because the capabilities of devices may differ. There it makes sense to have
an increment/decrement approach, but for DDR5, DQ writes are much more
constrained. Randy asked if, as part of the definition, the protocol would
define values according to the actual JEDEC DDR5 specification. Walter said
now that we have a JEDEC DDR5 specification, the protocol description will say,
"for tap 1 it's 0-15... etc., according to the JEDEC DDR5" (for example). He
noted that no one will read this, it's not like an AMI file documenting what
that user/tool should know.
Arpad asked about the logistics of the process of creating this protocol. Bob
said the process remains to be seen. Walter said he would start by writing it
up and reviewing it with ATM. Randy suggested we might create a template for
protocol creation similar to the BIRD template. Arpad asked if the process
would be handled in ATM or the Open Forum or some other group. Walter said he
would have something ready to review at ATM in the near future. Randy said he
would like to get some feedback from controller vendors to confirm that the
proposed eye metrics satisfy their needs. Walter said he had some exposure to
both controller and memory vendor requirements, but he would like to get
feedback from other vendors. Arpad suggested Walter publicize his protocol on
the SIlist as well. Walter said he planned to present the protocol at the
next Open Forum meeting, and he would send it to SIlist after the presentation.
Support PI modeling/simulation in IBIS:
Zhiping reported that he hadn't received any feedback or questions based on his
presentation at a previous meeting. He said he was focusing his attention on
the upcoming IBIS Summit in conjunction with the IEEE EMC SI+PI symposium.
IEEE EMC SI+PI is a virtual conference running throughout the month of August.
The IBIS Summit is on August 28th from 1 to 5 PM CST. Randy asked if Zhiping
might lead a question/answer session to help IBIS members interact with IEEE
members. Zhiping said he had recently reached out to the IEEE EMC Chair to see
if he could present an introductory overview of IEEE EMC and perhaps talk about
ways IBIS and IEEE EMC could collaborate. Randy and Bob said this would be a
good presentation for the summit.
BIRD181.2:
Bob briefly reviewed the purpose of the BIRD and where it is currently hung up.
The BIRD is changing some of the notation used in the specification to go to a
more precise, SPICE-like terminology. For the Pullup, Pulldown, GND Clamp, and
POWER Clamp tables, it will use syntax such as:
Vtable = V(Pullup_ref, Buffer_I/O)
Bob said one area that is slowing down the effort is the Notes on Data
Derivation section. He said the change would make it more complicated to read
at first glance, but it would more precisely define the intended ranges in terms
of the lowest and highest rails. For example, it shows the recommended lower
limit of the Pulldown table extending to -V(Pullup_ref, Pulldown_ref). Arpad
asked why have the "-" sign and asked if swapping the order of the two nodes
would be easier. Randy said the notation Bob showed made it more obvious the
value was negative. Radek noted that what was shown for the upper limit of the
range V(2*Pullup_ref, Pulldown_ref) could not be correct, because the 2* was
multiplying a node name. Bob agreed it needed more review, and said it was
probably 2*V(Pullup_ref, Pulldown_ref).
Arpad asked if the changes affected other areas. Bob said they would probably
affect the Composite Current and gate modulation effect sections as well.
Bob noted, as a helpful pointer to model makers, that it's okay for tables to
extend beyond the ranges suggested in the Notes on Data Derivation. In fact, he
said he would recommend it as a way to ensure you don't get unintended
extrapolation results from tools.
- Randy: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Ambrish to find out whether his team would have any interest in taking some
of their BCI protocols public if there were a process to do so.
-------------
Next meeting: 11 August 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
