Minutes from the 07 August ibis-atm meeting are attached.
IBIS Macromodel Task Group
Meeting date: 07 August 2018
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: * Michael Mirmak
Keysight Technologies: * Fangyi Rao
* Radek Biernacki
Ming Yan
* Stephen Slater
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
* Justin Butterfield
SiSoft: * Walter Katz
* Mike LaBonte
SPISim: * Wei-hsing Huang
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
The meeting was led by Arpad Muranyi. Curtis Clark 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 July 31
meeting. Radek moved to approve the minutes. Bob seconded the motion.
There were no objections.
-------------
New Discussion:
Question from the Quality Task Group regarding BCI_State (BIRD147.6):
Mike L. and Bob sought the group's opinion on what, if any, checking ibischk
should perform on the value of BCI_State in the .ami file. Mike said he was
leaning toward none. Arpad asked if the spec defined the value in the .ami
file as a place holder, similar to DLL_ID? (it does not). Radek noted that
in fact it is defined as Usage InOut and Format List. The five valid values
in the list are "Off", "Training", "Converged", "Failed", "Error". Radek
noted that the user should select "Off" or "Training" at the start of the
simulation (see BCI_State Definition:). Arpad noted that since it is defined
as a List the user must make a selection, and if they don't the EDA tool has
to pass the default value to the .dll. The .ami file will contain the list
definition, not some unused Value. Radek agreed. Bob noted that the parser
could just check for valid values in the List.
Single-ended applications of algorithmic modeling:
Clock Forwarding - Fangyi noted the proposal to use the existing clock_times
argument in AMI_GetWave() to send clock ticks into the .dll, and wondered if
we should consider other solutions. Walter noted that if people object to using
the existing clock_times bi-directionally, then the easiest thing to do would be
to create a new GetWave() call that has another pointer argument to an input
array of clock ticks that go with the data. The .dll then fills the existing
clock_times with the clock ticks that it chooses, so it might be easier to
add a new GetWave() signature with a separate pointer to input clock_ticks.
Fangyi noted that he preferred to go one step further and pass the entire clock
waveform into the .dll, not just the clock ticks. Arpad asked if the clock
waveform would have the same sampling as the data waveform. Fangyi said it
would. Arpad asked if we would need to pass in threshold information, too.
Walter said we could do the same thing we do for the Tx stimulus waveform
(+0.5 to -0.5 with a crossing at zero). Arpad asked if this solution would be
general enough. Walter said the DDR5 clock is differential. Fangyi asked if
Arpad was worried about the possibility of a single-ended clock. Arpad asked
if we need to consider it, in order to provide a more general solution than
something specific to DDR5. Randy said he didn't think we would encouter a
single-ended clock at the data rates we are working with.
Walter stated that it would be easy to implement a way to pass in clock times.
The question, however, is whether we should consider doing it without someone
asking for it. Is there a model maker who wants to have the input clock
waveform? The requestor would have to describe how they want the EDA tool to
generate those input clock times.
Arpad returned to Fangyi's suggestion of passing in the clock waveform itself.
The reason to pass the entire waveform was that the model might do something
different with it than the EDA tool would. But, if we were to keep it simple
and pass clock waveforms as -0.5 to +0.5 with a zero crossing, why would it
be useful to pass the waveform itself? What could the model do that the EDA
tool couldn't with that simple waveform? Walter noted one possibility was that
the waveform would have a slew rate, and derating tables could include the slew
rate of the waveform. So, Walter said maybe it was better to just pass in the
DQS waveform itself and let the model maker's .dll figure it out.
Arpad noted that if we were going to change the GetWave() footprint, then we
might as well consider addressing other issues that may be resolved more
appropriately with a footprint change. Walter noted that he would like to add
a parameters_in string to GetWave().
Stephen noted that current practice is for EDA tools to calculate the Vref per
the spec. But now, with equalization on the receiver, internal to the DRAM you
have a DFE that is being clocked externally but also uses the Vref in
determining the DFE tap settings. So, he wondered if you can have a single AMI
model treating everything independently, or if you need a new AMI model that has
multiple inputs and lets the .dll work out internally what the correct Vref
should be and what the DFE settings should be for each DQ. He asked for DRAM
vendors to comment on whether this would be more complicated than is necessary.
Walter noted that Vref is important inside the .dll, even though most initial
applications of AMI to DDR5 assume the AMI waveform is centered around zero.
The only way you can get the Vref information to the Init() function is to
pass it in along with the impulse response. This is straightforward for the
tool, since the IR is typically calculated from a step response, and Vref is
the mid-point of the step response. For GetWave() we have the choice of whether
to have the waveform centered on zero or to leave the Vref in the waveform.
Walter noted that GetWave() needs the absolute value of the incoming voltage
waveform because it could get into saturation if your Vref were very high and
you tried to add too much from the DFE. Walter also suggested that we could
instead pass a step response to Init() and let it calculate Vref and the IR for
itself.
Arpad noted the rise/fall asymmetry issue and suggested we might address it in a
more robust manner if we are considering changing the AMI footprint. Fangyi
agreed, and said it would be a good idea to have a new Init() that takes more
than one IR. Walter proposed a new Init() that takes rising and falling step
responses. Then you don't need to pass Vref. Fangyi agreed.
Arpad noted the redriver flow discussions and noted that some solutions to the
flow issue had involved changing the AMI footprint. Walter said a new Init()
could take rising and falling step responses, drop the cross talk terms, and
allow both the Tx and Rx to return their linear and non-linear(DFE) equalization
terms. The EDA tool could then perform all the cross talk convolutions.
Michael M. noted that someone had once proposed an additional "Stat" function
that would handle statistical flow and allow the Init() function to focus solely
on initialization. Mike L. noted that he and Todd proposed it because they'd
encountered scenarios where it might have been better if Init() only handled
initial setup and not IR processing too. Arpad noted that this could help with
redriver flow issues, as there had been some proposals to call Init() more than
once, but this was difficult because Init() performed initial setup and not just
IR processing.
Arpad suggested we create a list of the current issues with the AMI flow and
possible solutions if we changed the AMI footprint.
Walter noted that none of the issues yet discussed would provide a solution to
the problem of providing a correct input waveform to Rx GetWave() when you have
a single-ended DQ with different rise and fall rates. Walter said the EDA tool
is responsible for generating this waveform input to Rx GetWave(), and he
reiterated that he and Ambrish think the tool can do it without any changes to
AMI. Walter noted Fangyi says the spec is broken. Walter acknowledged that it
is incomplete, but suggested that anyone who wants to change AMI should write
the BIRD. He and Ambrish don't think it's necessary.
Fangyi noted that we all agree that what the spec says is incorrect for a DDR5
scenario. If the system has different rising and falling edge rates, then it
is not LTI. If a tool vendor says they can convert Tx GetWave() output to Rx
GetWave() input, then that particular process is based on some assumptions. If
you have different assumptions you'd have a different approach to the algorithm.
There is no first principle theory that lets you do that in a general way, and
whatever you are doing is based on some assumptions or approximations. Radek
noted that there is not sufficient information in the AMI flow to create the
correct input waveform. Yes, if you had the correct input waveform the Rx
GetWave() could handle it properly. But there is not sufficient information
to guarantee that you've created the correct input.
Walter said if a tool vendor can give their user arithmetic to tell them how
accurate the model would be in each given scenario, then the user can decide
if that's good enough. Fangyi did not think such an accuracy guarantee was
possible.
Arpad asked if someone would create a list of the issues we would like to fix in
AMI that could possibly be addressed with a footprint change. Arpad noted that
he would like the redriver flow issue included in this list. He noted that
Walter's original redriver flow proposals had been considered incomplete, and
competing suggestions relied on footprint changes. Fangyi took the AR to draft
such a list. Stephen noted that Walter had proposed several solutions that
could be included in the list.
Mike L. asked if the clock forwarding issue couldn't be handled by a second AMI
model dedicated to the diff pin pair that received the clock. That Rx AMI model
could process the clock waveform and return clock ticks. The EDA tool could
then take those returned clock ticks and pass them in to the AMI model handling
the data waveform. Walter said one complication is that the phase of DQS
and DQ are often determined by the transmitter not the receiver. He reiterated
that he would like to hear someone developing DQ AMI models describe how they
would use the clock waveform input. If no one knows how they would use it, why
put a lot of effort into defining it at this point? Arpad asked Michael M. and
Randy if they would take an AR to investigate this. They agreed.
- Mike L.: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.
AR: Fangyi to draft a list of AMI issues that could be addressed by an AMI
footprint change.
AR: Randy to investigate if/why/how a clock waveform input might be used.
AR: Michael M. to investigate if/why/how a clock waveform input might be used.
-------------
Next meeting: 14 August 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
