[ibis-macro] Minutes from the 18 February ibis-atm meeting

  • From: Curtis Clark <Curtis.Clark@xxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Sat, 22 Feb 2020 01:02:33 +0000

Minutes from the 18 February ibis-atm meeting are attached.

Documents discussed during the meeting were sent to the ATM list and will be 
uploaded here:

http://ibis.org/atm_wip/archive-date.html

IBIS Macromodel Task Group

Meeting date: 18 February 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.  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 February 11
meeting.  Michael moved to approve the minutes.  Bob seconded the motion.
There were no objections.

-------------
New Discussion:

DDR Clock Forwarding:
Fangyi reviewed the current state of his in-progress draft of a new BIRD.
The Definition of the Issue section states that clock forwarded DDR systems are
the motivation for the BIRD.  The BIRD proposes a new AMI_GetWave2() function
and a new GetWave2_Exists Reserved Parameter.

Note: During the meeting, two changes were made to the draft Fangyi presented.
They were incorporated into the version he sent to ATM after the meeting (the
version posted to the ATM work archives):
1.  Arpad noted his comment, from a previous meeting, that the name of the new
    "wave_ref" argument to AMI_GetWave2() was misleading.  Fangyi changed all
    references to "wave_ref" to "wave_clk".
2.  The draft originally stated that GetWave_Exists and GetWave2_Exists could
    not both be true.  That is, a model could provide one or the other (or
    neither) but not both.  Walter suggested that it would be helpful to allow
    a model to provide both.  If the DQS simulation were available, the new
    AMI_GetWave2() could be used.  If the DQS were not available, the existing
    AMI_GetWave() could be used, and the model could figure out what it thought
    the best timing was.  This would allow us to support existing functionality
    and add the new functionality.  Fangyi agreed that we could relax the 
    mutually exclusive requirement and allow the user/tool to choose which one
    to use if both were provided.  Randy noted that he liked this approach and
    thought it would be easier for model makers.
These changes were made to the draft, and the minutes below reflect them.

- New AMI function AMI_GetWave2()
  - same signature as the existing AMI_GetWave(), except for the addition of a
    new wave_clk argument for passing in the clock waveform.
  - wave_clk definition
    - same size and sample interval as the existing wave argument
    - Algorithmic model can use this signal to control the timing of the DFE
      slicer.
    - If sample timing is based on wave_clk, the model should return clock_times
      based on wave_clk.
    - The model may internally process wave_clk before using it.
    - The EDA tool provides the wave_clk to the model.
      - In the case of a DQ Rx model in a DDR channel, the input waveform for
        wave_clk is the output wave from the corresponding DQS's Rx model.
  - Other arguments and the return value have the same definitions as
    AMI_GetWave().

Walter described the flow for the EDA tool in the GetWave2() case.  The EDA tool
will generate 1000 UI (for example) waveforms for DQ and DQS from the basic
time-domain simulation flow.  It will take the waveform for DQS -> pass it to
the DQS Rx .dll GetWave()-> take the wave out (which must be the same length as
the input) -> pass it to the DQ Rx .dll GetWave2() in the wave_clk argument
along with the DQ waveform in the wave argument.  Fangyi agreed.

Arpad asked if DQ was the only model that needed a GetWave2() and whether some
usage rules should be added to make it clear.  Fangyi noted that his earlier
presentation had mentioned that GetWave2() is only implemented in the DQ Rx
model.  DQS, command and address, etc., don't need a forwarded clock, and their
models would only implement a traditional GetWave().

Arpad asked if the existing GetWave() section of the spec would also have to
be modified to keep it consistent with what the new GetWave2() section stated.
Fangyi agreed it probably would.  Arpad noted we might have to search the
spec for all references to GetWave().  Radek suggested we might be able to
make a blanket statement that all references to GetWave() could mean GetWave()
or GetWave2().

Radek suggested that we might consider a more descriptive name than
AMI_GetWave2(), for example, AMI_GetWaveClock().

Walter again noted that this proposal requires that the output of the DQS
model's GetWave() will become an input to the DQ model's GetWave2(), and it
must have the same length as the DQ waveform.  He said it's the model maker's
responsibility to deal with any delays inserted in the DQS GetWave() that have
to be accounted for in the DQ GetWave2().  He noted that a DQS will only have a
CTLE and gain (amplification and frequency filtering).  The frequency filtering
implies that a delay will be inserted in the DQS path because of the way CTLEs
are implemented.  The assumption is that the DQ waveform going into the DQ Rx
model and the DQS waveform going into the DQS Rx model were measured at their
respective pads at the same time.  The model maker takes that assumption, and
then it's up to them to make sure any delays in the DQS path through the DQS
model and the DQ and DQS paths through the DQ model are accounted for and
things are aligned properly.

Fangyi agreed, and said he thinks about the read and write cycles separately.
In the write cycle, the DRAM is the Rx.  It probably doesn't do any timing
training.  All the DQ-DQS alignment depends on the controller and would have
been determined during write-leveling at bootup time.  Similarly, the EDA tool
could perform this task.  The EDA tool could adjust the controller's DQ and
DQS so they're aligned properly at the DRAM.

Justin asked how the EDA tool will know that it has successfully aligned the
clock and strobe.  Will it expect feedback from the model?  Fangyi said the
EDA tool could assume that the DRAM expects the DQS and DQ to be center
aligned.  Randy asked if the model should assume that the DQS passed in as
wave_clk has been shifted so that it's in the center of the DQ.  Fangyi said the
EDA tool's optimization should provide that, and then the model maker can do
what they want internally.  For example, the model could internally adjust
the skew if the device has the capability.  Randy noted that the controller
shifts the strobe to align within a bit or byte, but then the controller also
shifts each data bit to optimize it.  So inside the DRAM those delays can be
different for every bit.  Randy said this is where we need some write-leveling
training performed by the tool to figure out that alignment assuming the
models build in all the actual delays.  He noted that the model makers want to
model the multiple UI shift in DQS relative to data so they can model the
jitter effects.

Fangyi agreed, and noted that the EDA tool could provide different ways of
performing write-leveling training.  It could assume the DRAM prefers center
aligned DQS.  It could also perform a sweep and look at BER levels to determine
which phase relationship is best.  In the real device, the controller typically
looks at the error bit to determine write-leveling.  Randy said it seems that
it's still an open question how the EDA tools will deal this issue.  If you
just run a simulation without defining the write-leveling procedure you might
end up clocking the DFE at the wrong location.  Fangyi agreed.

Fangyi noted that for the read cycle the controller is the Rx, and it typically
has on-the-fly adjustment of the skew between DQ and DQS.  It has an internal
phase interpolator to optimize the phase relationship, and that behavior can
be captured in the Rx model.

Fangyi said he would send out the current draft for posting to the ATM work
archives.  Fangyi said he expected to have a more complete version in a week
or two.

BCI for statistical flow:
Walter noted that he had nothing new to discuss, but he was working on an update
to the DDR5 DQ Write protocol proposal.

Discussion on "Gap in IBIS for sampling with statistical mode AMI models":
Michael noted the goal of the presentation and the previous discussions was to
address the issue with a BIRD.  Walter agreed and noted that an email discussion
on where to locate the clock in statistical analysis was ongoing.  He said there
were two possibilities being discussed:
1.  The model tells the EDA tool where the eye should be sampled.  It provides
    a "time" where the tool should sample.  This time might not be trivial to
    define, and it would have to be defined carefully.
2.  The alternative is for the model to specify which particular algorithm the
    EDA tool should use to determine that time.
    
Arpad noted that he thought it made more sense for the model to return the time.
He said that since the Rx model has a DFE, it must know where the UI begins
since the DFE switches at the UI boundaries.  So it would make more sense for
model to tell the tool where the UI sits on the IR waveform.  Walter said he
also favored that approach.  He noted that defining that time has to be done
carefully.

Arpad said he would send a reminder email to ATM.  He noted that at the previous
meeting we had planned to have a straw poll on which approach to choose.

- Michael M.: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

AR: Fangyi to email his draft GetWave2() BIRD to ATM.
AR: Arpad to send an email reminder about a straw poll on the sampling issues
    in statistical flow AMI.

-------------
Next meeting: 25 February 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives

Other related posts:

  • » [ibis-macro] Minutes from the 18 February ibis-atm meeting - Curtis Clark