[ibis-macro] Re: Let me explain one of the architectures of an Rx CDR
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <kwillis@xxxxxxxxxxx>
- Date: Fri, 15 Apr 2011 13:57:26 -0400 (EDT)
Ken,
I gave one architecture, but all CDR architectures have the problem of
first being able to tell the User and the EDA tool what the recovered
clock distribution is for statistical analysis, and these are:
Rx_Clock_PDF
Rx_Clock_Recovery_Mean
Rx_Clock_Recovery_Rj
Rx_Clock_Recovery_Sj
Rx_Clock_Recovery_DCD
Secondly, the EDA tool MUST be able to account for the additional Jitter
added because of Jitter in the reference clock of the CDR. And, yes, all
CDR also have a reference clock that has Jitter. Sometimes the model maker
knows what this jitter is and tells the EDA tool what the tool needs to
add, so why not define Reserved Parameters so that all model makers can
describe this jitter the same way with:
Rx_Rj
Rx_Sj
Rx_DCD
OF course there can be clock architectures that cannot be described this
way. In the case the User/EDA tool can generate exact clock_times for the
reference clock and pass them to GetWave, and GetWave will return exact
clock_time of the recovered clock without any of the above adjustments.
Similarly, the EDA tool has complete control on how it chooses to add Tx
Stimulus Jitter since the EDA tool generates the stimulus.
So why should we not take this opportunity to resolve Jitter properly in
5.1?
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Friday, April 15, 2011 1:38 PM
To: 'Walter Katz'
Cc: 'IBIS-ATM'
Subject: [ibis-macro] Re: Let me explain one of the architectures of an Rx
CDR
Hi Walter,
This does explain why you proposed 2 sets of jitter parameters. But your
first line here was "This is one of possibly many CDR architectures". Then
after that you have listed 8 proposed Reserved_Parameters:
Rx_Clock_PDF
Rx_Clock_Recovery_Mean
Rx_Clock_Recovery_Rj
Rx_Clock_Recovery_Sj
Rx_Clock_Recovery_DCD
Rx_Rj
Rx_Sj
Rx_DCD
A key issue here is that (just like previously with circuit models) you
are proposing to essentially hard-code a whole bunch of
Reserved_Parameters for a "canned" architecture. But as you said there can
be MANY architectures. So it seems logical to assume that following this
path we would need a whole boatload more Reserved_Parameters that would
have to be proposed/debated/spec'd/implemented for the next architecture.
And the one after that. If so, we will be in perpetual addition of
Reserved_Parameters for every new architecture we run across, which does
not sound sustainable to me.
I think we are getting too fine with a particular canned architecture, and
that we need to be more general with the jitter injection. There are
really only 3 practical places the EDA tool can insert itself into this;
a) into the impulse response generation (which does not involve the AMI
part); b) into the stimulus bit stream for the Tx; and c) post-processing
the eye distribution. I think it is problematic to go too fine in
granularity with the Reserved_Parameters, and that we should keep them
higher level from the EDA tool standpoint. The next level of detail is
really for the Model_Specific parameters, where model developers can put
in whatever parameter inputs they need for their specific architecture.
Let's not try to guess those all in the IBIS spec and explode the
Reserved_Parameters section. I am concerned with that direction.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
_____
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, April 14, 2011 5:43 PM
To: IBIS-ATM
Subject: [ibis-macro] Let me explain one of the architectures of an Rx CDR
All,
This is one of possibly many CDR architectures. The Rx CDR has a reference
clock that is supplied to it. Suppose this reference clock generates
clocks at the UI. This clock will have several sources of jitter that can
be represented by Rx_Rj, Rx_Sj, and Rx_DCD. In this architecture there is
a delay added to these clock times. This delay can be between 0 UI and 1
UI in increments of UI/32. The amount of delay is controlled by the CDR.
There is jitter introduced by this CDR. The jitter in this delay is
represented by Rx_Clock_PDF, Rx_Clock_Recovery_Mean, Rx_Clock_Recovery_Rj,
Rx_Clock_Recovery_Sj, Rx_Clock_Recovery_DCD. The time that the sampling
latch samples the data therefor includes both the jitter in the reference
clock and the CDR. Thus for statistical analysis, since there are no clock
time to determine the CDR jitter, or where the center of the clock is
relative to the center of the eye of the data at the latch, the EDA tool
should use Rx_Clock_PDF, Rx_Clock_Recovery_Mean, Rx_Clock_Recovery_Rj,
Rx_Clock_Recovery_Sj, Rx_Clock_Recovery_DCD and Rx_Rj, Rx_Sj, and Rx_DCD.
In time domain simulation the CDR distribution is extracted from
*clock_times. If the clock_times generated by the CDR in time domain
simulations does not include the Jitter in the reference clock that the
CDR uses, then Rx_Rj, Rx_Sj, and Rx_DCD jitter needs to be added by the
EDA tool. External clocks can be handled by either passing them into the
Rx AMI_GetWave through *clock_times, or can be represented by using the
parameters Rx_Rj, Rx_Sj, and Rx_DCD.
Does this not explain why there are two sets of jitter parameters and how
they should applied?
Walter
Walter Katz
wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 720.333-1107
Other related posts:
