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> [mailto:ibis-editorial-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx]> On Behalf Of Muranyi, Arpad Sent: Thursday, May 17, 2012 9:50 PM To: ibis-editorial@xxxxxxxxxxxxx<mailto: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> [mailto:ibis-editorial-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx]> On Behalf Of Mirmak, Michael Sent: Thursday, May 17, 2012 7:34 PM To: ibis-editorial@xxxxxxxxxxxxx<mailto: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