Minutes from the 28 July ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 28 July 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 send out a modified version of the BIRD207 draft (Component_Name and
Signal_Name proposal).
- Done.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the July 21
meeting. Michael moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
New Discussion:
Component_Name and Signal_Name Reserved Parameters, BIRD207 draft:
Arpad shared the new BIRD draft Randy had sent out. Arpad noted that the
example specifying a Default had been removed, as was agreed upon at last week's
meeting.
Michael asked why the [Component] name and signal_name are being passed into the
model instead of Pin name. To answer, Walter illustrated an expected use case
for the BIRD. Suppose one is modeling a memory, in this case a x8 with DQ0
through DQ7. You're using the clock-forwarding BIRD (BIRD204), and there's a
clock tree in the component, and the delay in the tree may be different for each
DQ. By passing in the signal_name, the model can then apply the different
internal DQ to DQS delay for each DQ. On top of that, imagine the IBIS file has
ten different [Component]s. If the internal delay for a given DQ is the same
for all the [Component]s, then the signal_name would be sufficient. However,
the internal delays might be different for each [Component], so having the
[Component] name and signal_name helps in that case.
Walter said he thought signal_name is likely to be a requirement for the model,
but [Component] name might be optional. However, if the user is doing a pre-
layout simulation, then the tool might not know which DQ either, and it could
leave both Component_Name and Signal_Name empty. In that case, the model will
know that the tool doesn't have the unique information.
Arpad noted that the proposal states that both Component_Name and Signal_Name
are required if either one exists. Curtis said this meant that both must appear
in the .ami file if either appears, but the tool is free to pass "" in for
either value if it doesn't have the information.
Bob asked why put "placeholder" as the Value in the examples? When would that
be passed into the model? Arpad said the proposal states that this value will
never be sent to the model. The tool replaces it with the name of the Component
or signal_name, or it passes "" if it does not know that information. Bob asked
how the tool could not know this information, since it's right in the IBIS file.
Curtis said Randy was trying to support tools that might offer simulations based
only on the .ami file and executable model, and not the full Component and Pin
info from the IBIS file.
Michael said this proposal assumes the executable model knows all the
information about the delays, and it will figure it all out. He said that he'd
always thought the tool would be the one that figured out the delays. So how
could the executable model contain this information? Arpad clarified that the
executable model knows about the on-die differences (e.g. DQ-DQS delay) for
different DQ lines on the Component. This proposal lets the executable model
use a look up table based on the signal and Component names, rather than have
to create a separate executable model for each DQ. Ambrish agreed that the
assumption is that the same executable model could be used for all the DQs (or
even multiple Components). Walter added that the EDA tool only knows the DQ-DQS
skew up to the pad of the memory device. This proposal takes the perspective
of the memory model maker. A skew is generated between DQ and DQS at the
controller, and then there's additional delay in the interconnect, and all of
that is the tool's responsibility. But this proposal is limited to helping the
model maker keep track of differences internal to the memory module. Michael
said this answered his question.
Arpad asked if the group thought this was ready to submit as a BIRD. Bob moved
to recommend that Randy submit the BIRD to the Open Forum. Curtis seconded.
There were no objections.
DDR5 DQ Write Protocol:
Walter noted that BIRD201.1 "Back-channel Statistical Optimization" had been
approved at the last Open Forum meeting. Walter shared his presentation
"DDR5_DQ_Write_Protocol (BIRD147/201)".
- slide 2: General BCI Flow (BIRD147/201)
Walter reviewed a block diagram of the BCI components and flow. He noted that
this proposal applies equally to statistical optimization (BIRD201.1) and time-
domain optimization (BIRD147.6). The protocol describes the information that
is passed between the Tx and Rx. The EDA tool does not have to process this
information in any way. It simply passes the BCI_parameters_in and
BCI_parameters_out back and forth to the Tx and Rx in the case of BIRD201.1, or
the information is written directly to a file with no EDA tool intervention in
the case of BIRD147.6.
Walter noted that there is no proposed protocol for a DDR5 Read cycle, because
in that case there is no need for back-channel optimization. The memory is the
Tx on a Read cycle, and the Rx (controller) handles everything on its end since
the Tx isn't programmable. For the DDR5 Write cycle, the controller is the Tx
and it wants to decide what the Rx equalization settings should be and what its
own equalization settings should be, if it has any. How does it go about doing
that?
- slide 3: JEDEC and Generic protocols
Walter noted that JEDEC standards have the Tx telling the Rx tap indices to
use (register values) and a requested BER. His JEDEC protocol supports this.
For his Generic protocol, which supports cases where we don't have a JEDEC
compliant Tx and or Rx, the Tx tells the Rx the actual tap coefficients and
a requested BER. In actual hardware the Tx can't request a BER of 1e-16, as
this would take too long. Typically it expects to run 1k to 10k UI, for a
practical BER of 1e-3 or 1e-4. The Tx requests the setup, the Rx says it
complied or says how close it was able to come to honoring the request, and the
Rx returns a metric. The metrics proposed are eye width, eye height, and area
of the eye (not width * height) at a given BER, and COM.
- slide 4: What the Tx tells the Rx each iteration
- JEDEC protocol
- BER for the metrics
- Gain register setting
- VrefDQ register setting
- DFE indices and register settings
- Generic protocol
- same information, but passing real values instead of integral register
settings.
- slide 5: What the Rx tells the Tx each iteration
The Rx takes what it was told to do, tries to do it, and responds. For example,
it might have been asked to provide a metric at BER 1e-5, but if the eye was
closed at that contour it might return the metric at the 1e-3 BER contour.
- JEDEC protocol
- Return the BER used
- Return the gain value corresponding to the register setting the Tx
requested
- Return the VrefDQ value
- 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
- slide 6: Metrics - optPulseMetric()
One can generate the metrics from an IR. The Rx has an IR available. Many
tools can take an IR and generate a statistical eye, but their methods might
vary and the results could be slightly different. Walter proposed using a
specific calculation, as defined by the optPulseMetric() function in MATLAB.
He suggested that if IBIS were to approve this, they could put the algorithm
for that function in the public domain.
- slide 7: Next Steps
- IBIS has left it unspecified how BCI protocols are:
- published
- approved
- amended
Walter noted that this presentation amounted to a first step in publishing this
protocol. Approval would have to come from IBIS. Amending a protocol has not
yet been considered. Walter said he would like to work out the protocol in ATM
and then notify the Open Forum and see what it decides to do in terms of
approving a protocol or merely posting it. Walter said his goal was to propose
a common protocol that memory and controller vendors would agree to support.
Bob said one option would be for IBIS to approve it and give it a name such as:
IBIS_<company name>_<protocol_name>.
Walter agreed.
Zhiping asked if this proposal is only for the simulation or also for the
hardware. Walter said the protocol just defines what the Tx and Rx AMI models
exchange during simulation. It allows the person creating the Tx model to know
how to communicate with the Rx model. The algorithm the Tx model uses can be
the same as the one in the hardware or its own special algorithm. It's
possible the algorithm developed for the model could be what is ultimately
compiled to create the controller firmware itself.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Randy to submit the Component_Name and Signal_Name BIRD draft to the Open
Forum as an official BIRD.
-------------
Next meeting: 04 August 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
