Walter,
Thanks for your explanation. Do you mind if I asked you to insert “DQ” and
“DQS”
in front of each “Rx” in your explanation to be absolutely clear?
I don’t think it is necessary to introduce more memory consumption because
memory is cheap…. 😊 Some simple explanations (along the lines of what you
just provided) should be sufficient to keep everyone on the same page…
Thanks,
Arpad
======================================================================
From: Walter Katz <wkatz@xxxxxxxxxxxxx>
Sent: Thursday, September 8, 2022 7:51 AM
To: Muranyi, Arpad <Arpad_Muranyi@xxxxxxxxxx>; IBIS-ATM
<ibis-macro@xxxxxxxxxxxxx>; ibis-editorial@xxxxxxxxxxxxx
Subject: RE: What is the meaning of "clock_times"?
…
WMK> First, you are correct the meaning of clock_times as in input is different
than the meaning of clock times as an output. Example:
For the moment, let’s assume that the DQ is 0T, and that there is the same
delay in the Rx of the DQ and DQS to the latch. This is a traditional Rx where
the DQS transitions through zero occur at the center of the DQ eye. Since there
is no skew between DQ and DQS introduced inside of the Rx, the clock_times
output of the Rx AMI_Getwave will occur ½ UI before the clock_times input
times.
The standard is unambiguous on this point. On the other hand, so many people
are confused about this then it has to be explained more clearly in a BIRD with
example(s) such as this one.
The same thing is true about *wave. As an input to AMI_GetWave it is the
waveform input at the I/O buffer Pad. As an output it is the waveform at the
I/O buffer Latch. Way back when, we could have had a *waveIn and a *waveOut.
But this would have required allocating twice as much memory. Because memory is
so cheap and allocating memory is so fast we may have chosen to have *waveIn
and a *waveOut.
Walter
