[ibis-macro] Re: Let me explain one of the architectures of an Rx CDR
- From: "Ken Willis" <kwillis@xxxxxxxxxxx>
- To: "'Walter Katz'" <wkatz@xxxxxxxxxx>
- Date: Fri, 15 Apr 2011 13:37:52 -0400
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:
