Minutes from the 11 August ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 11 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:
- 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.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the August 04
meeting. Randy moved to approve the minutes. Lance seconded the motion.
There were no objections.
-------------
New Discussion:
BIRD181.2:
Bob reported that he and Mike L. have taken this topic up in the Quality task
group. They will keep Radek (and anyone else interested) up to date and
eventually bring it back to ATM for further discussion.
Support PI modeling/simulation in IBIS:
Zhiping noted that he was focusing his attention on the upcoming IBIS Summit
in conjunction with the IEEE EMC SI+PI symposium. The IBIS Summit is on August
28th from 1 to 5 PM CST. Bob reported that Zhiping had submitted some ideas,
and they now have 9 potential presentations.
DDR5 DQ Write Protocol:
Walter reviewed an updated version of his "DDR5_DQ_Write_Protocol (BIRD147/201)"
presentation. He noted that he'd had to make more changes to the original than
he had anticipated. Some changes were based on pushback he got from reviewers,
and some were features he decided we need to support.
slide 2: Pushback on Rx Calculating Metrics, Support for BIRD197 and BIRD204
- Walter said that he received several requests not to define the metrics that
the Rx would calculate from its output IR or waveform.
- Modified the protocol so that:
- Rx AMI_Impulse returns its IR to the Tx AMI_Impulse
- Rx AMI_GetWave returns the wave and clock_times to the Tx AMI_GetWave
- Added support for BIRD197 (DC_Offset) and BIRD204(DQ-DQS GetWave flow).
- Proposal now indicates which parameters are required and which are optional.
slide 6: What the Tx tells the Rx each iteration
Walter noted that he'd added DQS_Skew so the Tx could adjust the DQ-DQS skew in
the Rx, assuming the Rx DQ model supports the DQ-DQS clock forwarding flow
BIRD204. He also noted that he'd added a sequence number to aid in debugging
with protocol issues, e.g., file system flushing issues in the case of BIRD147.
- JEDEC protocol
- Sequence # (New)
- Gain register setting
- VrefDQ register setting
- DFE indices and register settings
- DQS_Skew (New)
- Generic protocol
- same information, but passing real values instead of integral register
settings.
- VrefDQ setting and DQS_Skew are optional. The others are mandatory.
slide 7: What the Rx tells the Tx each iteration (JEDEC protocol)
Walter noted the following new additions for AMI_Impulse (statistical flow):
- Sequence #
- DC_Offset
- DQS_in_clock_times (Boolean)
- Impulse_Response
He said DC_Offset is returned by the Rx AMI_Impulse the first time it is called.
It simply takes the value the EDA tool set and passes it back to the Tx. The
DQS_in_clock_times lets the Rx tell the Tx whether it is doing the DQ-DQS clock
forwarded flow.
- Impulse_Response and Sequence are required.
The slide also defines a protocol for the GetWave flow (BIRD147).
The wave and clock_times are returned by the Rx in the GetWave flow.
- Wave and Sequence are required.
slide 8: What the Rx tells the Tx each iteration (Generic protocol)
- similar updates for the generic version
Arpad asked why Walter was now defining the GetWave protocol, since this had
been a statistical BCI protocol. Walter said it was a simple extension to
define the protocol for time domain too, and it would be important for training
DQS-DQ skew.
slide 9: Tx is now responsible for determining "goodness" of the Rx's output
- sample spacing of the IR and/or waveform is set by the EDA tool and
passed in through the AMI_Init functions existing sample_interval argument
- Tx can employ its own techniques to analyze the IR or wave from the Rx.
slide 10: Notes on Sequence
- Incrementing sequence counter allows for detecting and debugging various
issues caused by the model, EDA tool, file system, etc.
slide 11: AMI_GetWave File names written by Tx and Rx:
- Tx - output filename shall be <BCI_ID>.Tx.txt
- Rx - output filename shall be <BCI_ID>.Rx.txt
slide 12: VrefDQ_Register and VrefDQ_Value Rules
- Ignored by the Rx if DC_Offset is not specified in the Rx .ami file
- If DC_Offset is specified in the Rx .ami file:
- If Tx doesn't specify, the Rx should choose optimal setting/value and
return them to the Tx.
- If Tx does specify, the Rx should try to honor the request and return the
actual values to the Tx.
Walter said one of the ways the hardware trains itself is that the Tx will
sweep the values of VrefDQ up and down and the Skew left and right until it
sees errors. So the protocol supports doing that, and the Rx model has a way to
tell the Tx if it has a DC_Offset parameter, otherwise setting VrefDQ is moot.
- slide 13: Rx May Return Values when the Tx request a Register Setting and
Return a Register Setting when the Tx Requests a Value
- JEDEC protocol
- Rx shall know how to map JEDEC register setting integer values to float
values for each of the following VrefDQ, Gain, DFE Taps.
- Rx may return values to the Tx.
- Generic protocol
- Rx may know how to map JEDEC register setting integer values to float
values for each of the following VrefDQ, Gain, DFE Taps.
- Rx may return the register settings and values to the Tx.
- slide 14: BIRD204 support
Walter said that BIRD204 was largely intended for DDR read cycles, where the
controller has a phase interpolator. But for writes, the controller sets the
DQS skew so it arrives at the memory 90 degrees out of phase with the DQ. The
skew also affects when the DFE taps get latched. He recalled that for SerDes
systems the CDR normally generates two clocks, one for when to sample the latch,
and another one half a UI away that controls when the next set of DFE
coefficients is latched into the adder. Walter said he'd added two new protocol
parameters to support this:
- DQS_in_clock_times - lets the Rx tell the Tx if it has the DQS waveform too.
- DQS_Skew - lets the Tx adjust the DQS-DQ skew at the Rx.
- slide 15: Standard Initialization of AMI_Impulse calls, Interaction with
BIRD204 and BIRD197
- Describes the initialization sequence.
- First call to Tx AMI_Impulse
- shuts off its own equalization
- tells the Rx to turn off its Gain and DFE.
- Rx can then return DC_Offset and DQS_in_clock_times.
- Tx AMI_Impulse can then search for optimal solution (statistical)
- Tx AMI GetWave can continue the search in time domain simulation
- If the BCI training is GetWave only, then the first call to Rx AMI_GetWave
returns the DC_Offset and DQS_in_clock_times to the Tx.
- slide 16: Next steps
Walter said he planned to write up the actual protocols in a Word document,
review it in ATM, and then publish it in the Open Forum.
Arpad asked if both models had to support statistical and time-domain
optimization, or if the protocols would handle the case in which one model was
Init Only or one was GetWave Only. Walter said the protocols could work as long
as both models supported the mode(s) being used. He said this was a good
question, and that if we wanted to support GetWave only optimization then the
protocol needed a mechanism for the Rx to return info to the Tx on the first
GetWave call (see the last line of slide 15 (above), which Walter added during
the meeting. This change appears in the version he emailed to ATM right after
the meeting).
Arpad asked about how to proceed. Walter said the presentation was sort of a
functional spec. He planned to write a final protocol document.
Randy said he thought the changes Walter presented all made sense.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Walter to send his updated presentation to ATM.
-------------
Next meeting: 18 August 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
