[ibis-editorial] clock_times clarification questions

From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
To: "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>, "ibis-editorial@xxxxxxxxxxxxx" <ibis-editorial@xxxxxxxxxxxxx>
Date: Fri, 7 Oct 2022 20:02:11 +0000

Hello Everyone,

As "promised" below, I would like to ask a few technical questions about clock
times.  Let's go first with normal SerDes models without considering clocked
Data Rx AMI models.  My questions are about the highlighted text on pg. 229:

[cid:image001.png@01D8DA56.742A4700]

Paraphrasing the first highlighted text, it seems that a GetWave call is
allowed to
return clock times whose time values are beyond the last time point of the
waveform
in that same GetWave call.  Are we restricting this to adjacent GetWave calls
only,
or, could a GetWave call return many more clock times to be used on waveforms
more than just one GetWave call away in the future?

How about the opposite?  Could a GetWave call return fewer clock times than the
number of UIs in the waveform that goes through it, and could the remaining
clock
times for that waveform be returned in the next (or more distant) GetWave call?

These questions are "reinforced" by the text in the second highlight.  If there
is no
requirement for having a relationship between the clock times and the waveform,
any of the above scenarios would be legal.  For example, consider a CDR that
takes
some time to "wake up".  Is it possible for such a CDR to start returning clock
times
in the 10th GetWave call for the waveform that passed through the 1st GetWave
call
while getting nothing but -1s in the first 9 GetWave calls?  If so, how long is
the EDA
tool going to have to wait before realizing that this Rx model doesn't return
any
clock times?

Now, let's turn to the clocked Data Rx AMI models.  Does all of the above
"freedom"
apply to the clock times returned by the Clock Rx AMI model too?  The reason I
am
asking is because I observed with a couple of models that they would only work
properly if the clock times returned by the GetWave function of the Clock Rx AMI
model were within the time span of the waveform that went through the same
GetWave function.  If the 1st GetWave function returned a few additional clock
times
which were applicable to the waveform in the next GetWave call, the Data Rx
Model
would simply lose (ignore) those clock times, because it wouldn't store the
excess
clock times received in the 1st GetWave call for the next GetWave call.
According to
the first highlight, this is legal for SerDes models, but we don't say anything
about
this for clocked Rx models.  What are the expectations/rules for clocked Rx
models?

Of course the question about this situation in a reversed manner has to be
raised too.
Can the 1st GetWave call of the Clock Rx AMI model return fewer clock times
than the
number of zero crossings in the waveform that lasses through it, and get the
rest
of the clock times for the end of that waveform form the next GetWave call?
And,
if the answer to these questions is a yes, are we restricting this to adjacent
GetWave
calls only, or are we allowing this between more distant GetWave calls also?

I think these details should be spelled out in the specification (i.e., in the
clarification
BIRD), because I am already seeing models which "surprised" me, based on what I
read in(to) the specification.

I would like to hear how our experts would answer these questions.

Thanks,

Arpad
=======================================================================

From: ibis-macro-bounce@xxxxxxxxxxxxx <ibis-macro-bounce@xxxxxxxxxxxxx> On
Behalf Of Muranyi, Arpad
Sent: Wednesday, October 5, 2022 8:13 PM
To: ibis-macro@xxxxxxxxxxxxx; ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-macro] clock_times clarification BIRD draft 0.3

Hello Everyone,

Please find draft 0.3 of the clock_times clarification BIRD in the attachment.
This version includes the feedback received in the ATM meeting yesterday
and some editorial work based on that in the Editorial meeting this morning.
Please take a few moments to review it and comment on it.

There are a couple of items that are mentioned in the summary but not
addressed in the main body of the BIRD.  I still think that we should add a
simple statement that the Ignore_Bits should not be applied to the clock
times or waveform coming out of the clock (DQS) AMI model.

I also have another question regarding the number of clock times values
and the terminating -1 at the end of each such vector in each GetWave call,
but I will describe this question/problem in another email.

Questions, comments on the attached BIRD draft are welcome and encouraged.

Thanks,

Arpad
==================================================================

[ibis-editorial] clock_times clarification questions

Other related posts: