Minutes from the 3 March ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 3 March 2020
Members (asterisk for those attending):
Achronix Semiconductor: Hansel Dsilva
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
* Todd Bermensolo
Marvell Steve Parker
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. Justin Butterfield took the minutes.
--------------------------------------------------------------------------------
Opens:
- None.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the February 25
meeting. Bob moved to approve the minutes. Walter seconded the motion.
There were no objections.
-------------
DDR clock forwarding BIRD draft:
Fangyi looked at every instance of GetWave in the current IBIS 7.0
specification. He added paragraphs to the last page of the BIRD about the
differences between GetWave and GetWave2. The rules are the same, but there
are three exceptions noted in the BIRD. Fangyi suggested this should cover
all the references in the current specification. Bob asked if this version of
the BIRD was sent out to the ATM group. Fangyi replied it was. Michael
clarified if an earlier version was posted. Fangyi replied it is the same,
but it did not include these last three paragraphs.
Randy asked if this requires a specific flow with separate DLLs for DQ and
DQS. Fangyi responded there are no restrictions on this. Randy asked if this
means tools will require different flows. Fangyi noted the current AMI flow
should still apply. The exception is when the GetWave2 has to apply the
wave_clk argument. Randy asked if this will cause issues across different
tools. Walter thought this could be an issue for model makers, as it adds
complexity. He would like to see this implemented in models. Michael
commented it would be nice to have a diagram and a flow chart. Walter noted
there are pictures in Fangyi's presentation. Michael commented the issue of
when multiple DLLs vs. multiple functions should be used was not clear in
these diagrams. Arpad noted a pass-through DLL for the DQS might be
necessary. He asked if this should be made a requirement. Randy stated his
first thought is to have the DQS functionality in one DLL with the DQ. Fangyi
noted, if you put the functionality in the DQS DLL, then you don't need to
duplicate the functionality in the DQ DLL for each DQ.
Randy asked if there would be any issues with waveform alignment between DQS
and DQ and the passing of data to the DQ Rx model. Walter replied, if you
have a CTLE in the DQS, there could be some delay in the model and there can
be left over data. This delay will need to handled in the DQ. His thought is
it would be easier to put the DQS and DQ in the same to DLL to make sure they
work together. The problem is you need to know which edge from the DQS goes
with the DQ data. Fangyi stated the DQ can detect the edge. Randy commented
the simulator may have to do some alignment simulation in either case. Arpad
asked if the model maker will need to do something, and how should the
alignment would be carried out. He asked if we need a parameter in the DQ to
output the timing alignment. Randy commented in the hardware this is done
with the write-leveling. Fangyi suggested the simulator will have to do the
write-leveling.
Walter stated the skew between the DQ and DQS can cause the edges to become
uncorrelated. It is still an open issue how to analyze these systems. He
would like to see what the IC vendors come up with and if there are simpler
solutions that can model this effect. We need to know if this is a problem
that needs solved. Fangyi noted he has at least one customer asking for this.
DDR5 Write Protocol:
Walter added the ability for the Tx to tell the Rx what the Vref should be.
The other change is to have the Tx tell the Rx the DFE voltage coefficients.
The Rx can output the voltage values of the DFE tap values. He noted both
methods of reporting the DFE tap values may or may not be necessary to include
in the protocol.
Bob asked, about the parameters on slide 4, if these are reserved parameters
or model specific parameters. Walter noted these are the strings read by the
Tx and Rx models for the back-channel protocol. These have nothing to do with
the IBIS standard, but this is an agreement between the Rx and Tx model
writers. He chose to follow the parameter tree format, since model makers can
parse it. The EDA tool could read this file, but it is not required.
Michael asked about the tap values in register integer or coefficient format
and if the model can flag a preferred way of specifying the parameters.
Walter replied, since the Tx is driving, the Rx should be able to handle
either. He would recommend to have the Rx be a slave to the Tx.
Discussion on âGap in IBIS for sampling with statistical mode AMI modelsâ:
Arpad asked if we have any action on creating a BIRD for this. Walter stated
he preferred to not write this one. He suggested to have Hansel write the
BIRD. Arpad noted he had mistakenly thought Walter would write the BIRD.
Walter will contact Hansel to ask him to write the BIRD.
AR: Walter to send out the DDR5 DQ Write Protocol presentation.
AR: Fangyi to send out the latest GetWave2 API BIRD draft.
AR: Walter to ask Hansel to draft a BIRD to address the AMI statistical
sampling point issue.
- Randy: Motion to adjourn.
- Michael: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 10 March 2020 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
