[ibis-editorial] Re: clock_times conflict?
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: "ibis-editorial@xxxxxxxxxxxxx" <ibis-editorial@xxxxxxxxxxxxx>
- Date: Fri, 18 May 2012 16:00:46 +0000
This is great material. Could we get a discussion, or even a cross-posting,
involving the ATM group?
- MM
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, May 18, 2012 8:58 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: clock_times conflict?
Arpad,
Your other type of CDR failure is detected by the test that
abs(clock_time(n)-clock_time(n-1)-1UI)<UI/2, same test described to verify
that clock inc clock_times are skipped..
We ignore the output of Rx AMI_GetWave until Ignore_Bits. For times before
Ignore_Bits (converted to time) we discard clock_times values. Your question
is what is the model maker to output in the Rx AMI_Getwave call that has
Ignore_Bits (in time) in the middle of the Getwave call. We must assume that
the model maker will do one of two things:
1. Include clock_time for all times before Ignore_Bits in this GetWave
entry
2. First entry in clock_times must be at, or before the Ignore_Bits
time
In reality, the clock is always switching at near the UI data rate, the only
thing that a CDR does is change its phase. So there is no excuse for a model
maker from outputting all clock_times, but he must at least do 2.
Walter
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Friday, May 18, 2012 11:33 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: clock_times conflict?
Walter,
I have seen other types of CDR failures too, like
writing out clocks too close to each other, much
closer the 1UI +/- jitter. Don't remember the
numbers but something like a few ps apart when the
UI was on the order of a few 100 ps.
Question: What is the Rx CDR returning during the
Ignore bits time? It can't be -1, correct? It
can't be repeated zeroes either, because the numbers
must increase monotonically. So what will it do?
Thanks,
Arpad
=======================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, May 18, 2012 7:36 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: clock_times conflict?
MM, Arpad,
If an Rx AMI_Getwave function that returns clock_times is operating
correctly, it should return (after ignore_bits), one clock time every ~ 1UI.
Two bad things can happen:
First the CDR can lose lock, and the reported clock times are at the "wrong
frequency" causing them to drift through the recovered eye. The EDA tool
will simply report a terrible BER, as it should.
The second is that the Rx AMI_Getwave skips clock times. I would consider
this a flawed DLL, since clocks in CDRs do run continuously, the CDR just
adjusts the phase of the clock. The EDA tool should be able to detect this
flawed DLL since adjacent clock times should be separated by 1UI +/- Jitter.
Jitter should be < UI/2, so this is an easy sanity check tat an EDA tool
should make.
Walter
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, May 17, 2012 9:50 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: clock_times conflict?
Mike,
A -1 marks the end of the series of clock time values, but
-1 itself is really not a clock time value. Also, the tool
is not required to continue reading the clock times vector
after it found a -1.
So for an Rx that doesn't return clock times it is enough to
have a single -1 at the beginning of this vector, but the
model can also fill the entire vector with -1's if it has
nothing else to do. It doesn't matter, because the tool is
not required to read past the first -1.
An interesting question which I am not sure if it is explained
clearly is: what happens if the CDR goes out of lock and then
regains its normal operation. What is it supposed to do while
it is out of lock? It can't put -1 into the vector because
that's the end of the data. It can't put 0 there either
because that will make the data non monotonic. It can't keep
repeating the last number either because the numbers supposed
to get bigger. So what can it do? Does this mean that going
in/out of lock can't happen?
Thanks,
Arpad
================================================================
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Thursday, May 17, 2012 7:34 PM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] clock_times conflict?
In the current draft, clock_times (part of AMI_GetWave) contains as part of
its definition, the following text:
Any non-strict monotonic behavior of clock times (including two identical
values) should be considered by EDA tool as an algorithmic model failure.
This suggests that two successive identical values should be an error and
cause simulation failure.
But later, the following text appears:
In the case of a receiver without a CDR, it is possible for only -1 to ever
be output during all AMI_GetWave calls.
This suggests that the EDA tool should *not* flag an error if successive
identical clock_times values are seen, so long as they are -1. Without a
separate flag for "no_CDR", the tool has no insight into whether a CDR is
actually present or not.
Am I interpreting this correctly?
- MM
Other related posts:
