[ibis-macro] Re: Summary of DDR5 issues - and one more items to add to this list

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 11 Sep 2018 16:05:57 -0400 (EDT)

All,

 

This is the e-mail I shared in today's IBIS-ATM meeting.

 

Walter

 

1.      Asymmetric rise and fall times of a single ended channel.

a.      Both Cadence and SiSoft believe that this can be done by the EDA
tool without any changes to the standard
b.      Keysight believes that the standard is incomplete because

                                                               i.      It
does not define how to generate the Impulse Response input to AMI_Init

                                                             ii.      It
does not define how to generate the waveform input to the Rx AMI_GetWave
(mostly this)

                                                           iii.      Or
the AMI methodology is invalid for single ended DDR5 DQ channels

2.      Adding DC Offset or replace the Impulse Response Input to AMI_Init
with a Step Response

a.      Both are equivalent since a step response can be derived from an
Impulse Response and DC Offset and vice-versa
b.      In any case, one of these need to be done

Impact of Tx equalization on the offset

3.      VrefDQ

a.      The physical memory DDR5 buffer has a register that must be set by
the controller to define the VrefDQ in the chip.
b.      This will be very close to the DC Offset defined above, but not
necessarily so.
c.      Need to define how an EDA tool handles the impairment caused by
the VrefDQ register resolution, and because a single VrefDQ register may
control several DQ channels with slightly different DC Offsets

4.      Clock Ticks

a.      The DQS to DQ skew in the DDR5 memory receiver is defined by the
Controller. This skew is determined by simulation, or by a hardware
training algorithm
b.      One way to handle this is to put a CDR in the memory DQ Rx and
assume that this CDR will find, use and report the optimal DQS/DQ phase.
c.      A possible useful reserved parameter is the DQS/DQ interconnect
skew.
d.      Another way is to have the Controller Tx AMI Model generate clock
ticks that the Memory Rx AMI Model reads and uses. A BIRD 147 protocol can
be defined between the Tx and Rx to optimize this skew (and the Rx DFE
taps as well).

I did leave out one issue "Component Based AMI Simulations"

1.      Both Cadence and SiSoft believe that this should be dealt with by
the EDA tool. It knows the DQS/DQ interconnect skew for each DQ in a
"Component", and therefor can determine the required skew training
parameters or the impairment added to the nibble. Note that a component in
this context can be a single memory chip or multiple memory chips in a
module. Similarly, the EDA tool knows the Vcent for each DQ channel and
can calculate the ideal VrefDQ for the module and the impairment. There is
little or no difference between DDR4 and DDR5 in this regard.
2.      Keysight believes that IBIS AMI needs to be enhanced (or a new
methodology) to deal with Component Level AMI Simulations for DDR5.

 

Power Aware

 

 

BIRD required to do all of the above:

1.      Define a new AMI Reserved Parameter DC_Offset that is the voltage
half-way between the step response low and high limits.

 

That all folks!

*       Cadence and SiSoft do not think BIRD is required to deal with the
asymmetric rise and fall times, although we do need to convince both DDR5
AMI Model developers and users that the solutions we have implemented are
sufficiently accurate.
*       We do not need to create a VrefDQ reserved parameter, it just
becomes a voltage impairment that can be included in
Rx_Receiver_Sensitivity. In any case, since the model is told what the DC
Offset is it can determine what its VrefDQ granularity impairment.
*       I will defer to the Controller IC Vendors as to the need of
training the DQS/DQ skew using clock ticks created by the Tx and used by
the Rx, but if required it does not need a BIRD. It can be done under the
auspices of a BIRD 147 protocol. The Tx AMI_GetWave can simply write out
the clock ticks to a file that the Rx AMI_GetWave reads. AMI Time domain
simulations typically run at a rate of 1 Million bits per minute. It takes
4 seconds to write an 8 Megabyte file - a 12% performance hit over using
the clock_times memory. If the 12% performance hit is an issue that we can
always write a BIRD that would support use clock_times. I think writing
this BIRD now is a classic example of pre-mature optimization.

 

Comments?

 

Walter

 

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Office 978.461-0449 x 133

Mobile  720.417-3762

 

Other related posts: