Minutes from the 04 September ibis-atm meeting are attached
IBIS Macromodel Task Group
Meeting date: 04 September 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:
- Arpad to email the ATM regarding ideas on the proper definition of Vref.
- Done.
- Randy to investigate if/why/how a clock waveform input might be used.
- In progress. Arpad noted that Justin had given a presentation last week
that touched on the subject, but a direct answer is still pending.
- Michael M. to investigate if/why/how a clock waveform input might be used.
- In progress.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
Arpad asked for any comments or corrections to the minutes of the August 28
meeting. Curtis moved to approve the minutes. Ambrish seconded the motion.
There were no objections.
-------------
New Discussion:
Vref definition:
Arpad noted the previous week's discussion regarding the Vref topic and the need
for a precise definition before we could start any work on a BIRD.
Ken noted that he agreed with Walter's reply to Arpad's Vref email (see ARs
above). He noted that VcentDQ and VcentCA are the important values. He said
Vcent** values are derived from the analog waveforms. You need to do it for
each waveform (for all the data lines, for example). Then you take the highest
and lowest of those, and the average of the two becomes the VcentDQ for the
entire DRAM component and is used to center the eye mask against which you
check.
Walter agreed with Ken's description about how Vcent is calculated and the way
the tool should optimize it.
Ken noted that the question for an AMI model is whether the equalization
functionality in the model, especially if it's adaptive, depends on the Vcent
value. If it does, then the model has to know about Vcent. Fangyi noted that
VrefDQ is used in the device itself, by the DFE, and is not necessarily equal
to the VcentDQ used to check the mask. We generally expect them to be close,
but they aren't necessarily the same thing. As Walter had previously noted,
VrefDQ is optimized and set by the controller, while Vcent is a measurement
result. Walter noted that Fangyi and Ken were "both right". VrefDQ in DDR5 is
a register in the DRAM that the controller sets. The controller needs to go
through some training methodology. It could be based on simulations and setup
ahead of time, or it could be a training algorithm.
Walter noted that Vref in legacy IBIS is something different and describes a
voltage set at one end of the load under which timing measurements are done.
Walter noted that VrefDQ implies a memory interface. He said that there may be
other single-ended standards, but he preferred the name VrefDQ to avoid
confusion. Arpad asked if we could use a name like VrefAMI in order to avoid
being locked into something DRAM specific. Walter said he would be okay with
that. He noted the VrefDQ is a register input in the DRAM set by the
controller. In the future, it's conceivable the DRAM might determine VrefDQ
itself, but that hasn't been the case for DDR4/5.
Fangyi noted that this raised the question of how the AMI flow would work and
how the VrefDQ (VrefAMI) would be set. Arpad said it sounded like a back-
channel scenario. Walter noted that the memory Tx model has no equalization
at all. The memory Rx model has DFE taps that need to be determined, and the
controller needs to set the VrefDQ and adjust the skew between the controller
DQS and DQs during writes. The controller may have these preset ahead of time
and may set the registers in the DRAM as part of the bios, or the controller
may figure it out with a training process. If it's a training process, then
we can think about how we would use a BIRD147 type flow for training.
Ambrish asked if, for a first pass at an AMI flow, the user could enter VrefDQ.
Walter said yes. Fangyi noted that VrefDQ depends on the voltage supply in
channel, and asked if Ambrish wanted the user to do some manual simulations
to figure it out the value to set for VrefDQ. Ambrish said the tool could
figure it out. Ambrish noted that memory experts he had consulted with said
the DFE in their hardware is actually differential, so they would prefer that
differential waveforms be sent into the model. The simulator could take care
of the DC common mode (VrefDQ) issue. Walter noted that in the picture he had
sent out in response to Arpad's Vref email, VrefDQ essentially makes the
waveform differential. He noted that he and Ambrish agreed that the common mode
info could be pulled into VrefDQ. He noted that if we decided we wanted to do
other things like pass in a full single-ended waveform, for example to model
certain saturation effects, then we would need to modify the standard.
Arpad asked if we might want a combination of a default mode in which
the tool/user provides a value and a full training solution available if the Tx
can train and determine the actual VrefDQ to set in the Rx. Ambrish said we
could let the simulator handle all of this. It has the step response and the
Vdd values, so it can figure it out. We ought to simply let the simulator
handle the common mode shifting. Ken noted that the tool could figure it out
from the step response, or optionally let the user override it. Arpad noted
the either way we would need a reserved parameter for the Rx to take in the
value.
Ambrish said that to keep it simple we should simply document things and let the
simulator keep track of the common mode shifting. Arpad asked if we would want
a reserved parameter for the Tx to pass the value out and the Rx to take it in.
Walter said that was more complicated than necessary. If the Tx wanted to train
then it could use back-channel to set the Rx. Ambrish said we should go with
the simplifying assumption that the differential waveform will suffice and the
tool can handle the common mode shifting. Ken noted that we could have a
reserved parameter that is optional, and if it's absent then the tool just
handles it.
Fangyi disagreed. He said that if we say the input to the model is a
differential signal, then the model doesn't need Vref because the DFE operates
on a differential signal and the slicer compares to 0V. If we go that way, then
we are saying we don't need this parameter at all. Even if we did introduce the
parameter, we can't allow the user to arbitrarily set a value to it. They might
set something that violates the physical electrical conditions of the circuit.
The user can't be allowed to enter some arbitrary value that might be nonsense.
Fangyi then noted that he wasn't sure it was a good idea to follow this path and
keep the AMI waveform as differential even for a single-ended device. He noted
that if we instead pass in the full single-ended waveform the VrefDQ would have
a totally different meaning.
Ambrish suggested that it was not necessary to move away from the differential
waveform. Doing so would make the models more complicated and the tools dumber.
Fangyi noted that if at some future time we wanted to include a training method
for VrefDQ, then keeping the waveform differential might preclude that. Ambrish
said nothing prevented us from adding it in the future if necessary. Fangyi
said this was a chance to make the AMI interface more extensible and more
physical and allow us to move beyond SERDES. Ambrish said that speeds are only
going to go up from here, and we may even find a CDR in future DDR standards.
Therefore, he suggested it was not worth spending time on adapting AMI to
single-ended applications if the existing differential solution could be made
to work. He thought everything would be trending toward differential anyway.
Fangyi noted that DDR5 has a mix of single-ended and differential signals, and
if we take care of them now we are more future proof. Fangyi also noted that
as it currently stands VrefDQ is shared amongst all the DQs in a byte lane. But
it's not physically the same for each DQ, and the JEDEC spec actually captures
that variance of Vcent within the byte lane. Fangyi said this was the
opportunity to address a lot of issues and make this sustainable for future DDR
development.
Arpad asked how many more single-ended signaling interfaces we expected to see
in the future. Is it worth the time to try to extend to single-ended, or
will it fade out soon anyway? What's beyond DDR5? Randy said DDR5, LPDDR5,
and DDR6 will retain single-ended equalization, and suggested that's probably
at least five years. Walter noted that he had also spoken Steve Parker about
non-DDR single-ended interfaces. Fangyi noted he had heard from other vendors
interested in single-ended too.
Ambrish said the question wasn't single-ended vs. differential interfaces. The
question should be: How much are we losing by keeping things simple and using
a differential waveform, and what would we gain by going to single-ended?
Walter noted that even if your model treats the signal as differential, you
still need VrefDQ to figure out saturation curves. Fangyi said that if your
model needs a differential signal and a VrefDQ, then it really needs a single-
ended signal. So why bend over backwards to force it into the current form and
send in a differential signal and a VrefDQ? Why not pass in the full single-
ended signal and take advantage of it? Ambrish countered by asking why we
should complicate things and modify the existing spec. if we could get good
results staying with differential and possibly an extra offset parameter.
Arpad asked if we had enough to begin working on a BIRD. Fangyi said he felt
the single-ended vs. differential waveform was the fundamental question to
answer, and it is still open. Answers to other questions, like step response
vs. IR, would follow from this decision. He noted another issue was whether
we wanted to consider a component-based model.
Ambrish noted that they were planning on writing a BIRD on a common clock
reference, which they considered the most important topic (assuming we decide
we don't need to change to single-ended waveforms). Walter noted 3 issues:
1. Who is going to generate that DQS signal?
2. Do the IC vendors think there is a need for that clock? There is no CDR in
DDR5, but what you need in modeling is a clock with a phase. So, the Rx
model could have a CDR in it. In reality the hardware on the controller
figures it out. But since you're asking the Rx what the best phase is,
according to bit-error-rate, the Rx model can determine the best phase.
3. Or, do the IC controller vendors want to be able to develop and model their
own training methods? In that case, having a CDR on the Rx side might not
be good enough.
- Michael M.: Motion to adjourn.
- Ken: Second.
- Arpad: Thank you all for joining.
-------------
Next meeting: 11 September 2018 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
