[ibis-macro] Re: clock times
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 01 Apr 2010 20:06:35 -0400
Humor me. I have a follow on addition to the previous comment/question.
Given the specification:
The clock times are the times at which clock signal at the output of
the clock
| recovery loop crosses the logic threshold. It is to be assumed
that the
| input data signal is sampled at *exactly one half clock period*
after a
| clock time.
And Mike's interpretation that 1/2 the nominal UI is the commonly
accepted interpretation of one half clock period.
And the specification is implemented in the DLL exactly as stated.
And the clock_ticks truly represent the points where the CDR clock has
locked on the data transition.
Then we've lost information regarding the instantaneous sample point.
Since the internal sampler of the Rx is based upon the instantaneous
clock period, not the nominal clock period.
And the cycle-to-cycle deviation of the clock is known as the
cycle-to-cycle jitter.
Then there is additional jitter added to the sample point, that is equal
to (nominal UI - instantaneous UI) / 2 that is unaccounted for in the
model and EDA platform.
This is equivalent to 2X sample jitter multiplication.
If I am correct in my analysis, the current specification guarantees an
incorrect estimation of sampler uncertainty, and higher BER as a result.
The only way around this is to either change the specification of the
clock sample point delivered by the DLL to the EDA platform, or to
change the specification of how the EDA platform performs the sample
point correction. Currently I believe the specification is not tenable
for current modeling needs.
regards,
Scott
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Scott McMorrow wrote:
Mike
Thank you for taking the time to answer. Sorry to be a bother. I have
another question. Based on this, we know what the EDA platform should
do. But, do we know what the DLL will provide? There are two choices:
A) clock_ticks truly represent the points where the CDR clock has
locked on the data transition. In this case our waveforms are
essentially differential crossing aligned, as the spec requires,
but we've lost any information regarding the sample point, and it
is impossible to determine where the sample point is.
B) clock_ticks represents the the sample point minus 1/2 the UI
period. In this case our waveforms are sample point aligned, and
all is right with the world.
If option A is chosen, I don't believe that sample jitter is properly
modeled. In both cases the eye is displayed correctly, since both are
based on the same clock, but the exact sample point is unknown.
regards,
Scott
Mike Steinberger wrote:
Scott-
We've been using your option A.
Mike S.
Scott McMorrow wrote:
All
We are looking at the specification for clock_times and have come
across the following problem with these two sentences:
The clock times are the times at which clock signal at the output
of the clock
| recovery loop crosses the logic threshold. It is to be assumed
that the
| input data signal is sampled at *exactly one half clock period*
after a
| clock time.
I really hate assumptions in specifications since they may be wrong,
and are up to interpretation. I believe that the spec really means
to define the internal sample point of the sampler, slicer, track
hold ... whatever, by having the EDA platform move the delivered
clock tick from the clock_times vector by 1/2 a clock period, or
UI. If that interpretation is correct then which of the two is
correct?
1/2 a clock period is defined to be:
A) one half of the nominal UI
B) one half of the instantaneous UI between two clock samples
How is this currently being implemented in currently developed models?
regards,
Scott
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
--
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
