[SI-LIST] Re: to what extent recovered clock depends on the serdes ref clock
- From: prasad <hariprasad.palli@xxxxxxxxx>
- To: Mike Brown <bmgman@xxxxxxxxxx>, si-list@xxxxxxxxxxxxx
- Date: Thu, 12 Apr 2012 10:59:27 +0530
Hi All,
thank everyone a lot for taking your time to clarify.
what i understand from your replys is the recovered clock need not
necessarly be tracking the input stream of data. please Correct me
otherwise.
in that case, lets say i have to design a repeater/regenerator, where on
one side the Rx takes the data and then it just re-drives the data on other
side, with out chaning timing. In this case, i mus be providing the
recovered clock in the Rx section to the ref clock for the following
section's Tx.
in the above scenario, if there is any off set in the input ref clock to
the Rx section, even though the data doesnt have any ppm offset, but my Tx
on the following section transmits with offset? ( as the recovered clock
doesnt entirely track the incoming signal but ref clock).
please clarify.
Thanks,
VEnkat
On 12 April 2012 01:02, Mike Brown <bmgman@xxxxxxxxxx> wrote:
> Hari,
>
> This seems to be a continuation of your question of 9/8/2011, attached.
>
> Let's look at what clock domains the SERDES must support; in particular
> the receive side.
>
> on the receive side, there must be a clock domain that is synchronous to
> the remote transmitter's clock, in order to recover the inbound data
> stream. That clock's frequency and phase is generated by the CDR block.
> There must also be a clock domain which is synchronous to the local data
> transfer machine. If these "must s" are not satisfied the data transfer
> *cannot* be reliable.
>
> The receive reference clock, (in at least one older IBM technology) is
> multiplied to be at the incoming data rate (or perhaps some small divisor
> of the incoming data stream). This multiplied clock is not used directly
> in the data recovery, but provides the CDR block with a clock that is
> "close enough" for data recovery. The CDR in the SERDES which I worked
> with (0.8u o.5u?? memory fails!) used this multiplied reference to drive
> a "phase rotator" which coarsely locked to the transitions in the incoming
> data stream. The lock was close enough to recover the incoming data
> stream. The inevitable phase drift between the transmit data stream
> clock and the multiplied receive reference was detected and used to change
> the tap selection in the phase rotator to reduce the phase error. The
> recovered data was written to a shallow FIFO (elastic FIFO, iirc)
> synchronously with the phase rotator output. The local data transfer
> machine unloaded the elastic FIFO at its own speed.
>
> Now, IIRC, you really have no need for, nor access to, that recovered
> clock. Or to information about it. That recovered clock is done when
> the write of the recovered data to the elastic FIFO is accomplished. It
> seems to me that the frequency offset between the local receive reference
> and the inbound data stream is accounted for in the design of the phase
> rotator. The more the difference, the faster the rotator taps are
> switched. The jitter of the reference clock, as present in the multiplied
> input to the phase rotator, is present in the rotator's output timing.
>
> Practically speaking, your local machine probably is synchronous to the
> receive reference. There's some handshaking logic that inserts or removes
> padding characters into the data stream to prevent FIFO overrun/underrun.
>
> As to your first question, I'm afraid that I don't know of any literature
> that would answer your question. I studied the available IBM block
> diagrams and literature, and formulated the above as a logical bridge
> between "what IBM shows in their docs" (pretty good, but not terribly
> instructive in some cases) and "What does it have to do in order to
> function?". Considering especially in that context the asynchronous nature
> of the interfaces. So, my descriptions above (and below) may not be
> exactly correct, but the net effect of the logic must accomplish
> essentially this.
>
> I'm sure that any vendor's CDR accomplishes similar function, although
> implementation may vary. There's no magic in the crossing of asynchronous
> domain boundaries. They must be managed by a FIFO with asynchronous read
> and write ports, or logic which emulates this.
>
> Regards
>
> Mike
>
>
> On 4/5/2012 11:54 PM, prasad wrote:
>
>> Hi everyone,
>> might this be a fundamental question. If this can be answered by some self
>> reading, please point me to the source of such notes. Thanks in advance.
>>
>> My question is , to what extent the recovered clock of the CDR inside the
>> SERDES depend on the reference clock given to it?
>>
>> I believe the RX side of the SERDES uses the input ref clock given to it
>> as
>> a guiding clock , to track the incomind data signal.
>>
>> which means, for eg, if
>>
>> I/p serial signal is at 10.3125Gbps ( 10GELAN)
>> serdes is of BW 64 on parallel side ( FYI this is IBM HSS11G serdes)
>> ref clock given is 161.13MHz ( 10.3125G/64, this gets multiplied by
>> HSPLL to generate the guiding clock fr the serdes)
>>
>> in this case, i should be/am getting, the recovered clock/64 as
>> 161.13MHz.
>>
>> But what happens if my ref clock is 161.13MHz+100ppm?
>>
>>
>> shouldnt the recovered clock/64 be still 161.13MHz, as the CDR shuld be
>> still tracking 10.3125GHz? From an experiment I did, i observed the
>> recovered clock/64 be around 161.13MHz+100ppm (roughly).
>>
>>
>>
>> I am not sure why this happens. It would be great if any of you kindly
>> help me understand this.
>>
>> Thanks one and all...
>>
>>
>> Best Regards,
>> VEnkat
>>
>>
>> ------------------------------**------------------------------**------
>>
>
> On 9/8/2011 3:26 PM, prasad wrote:
>
> Hi everyone,
>> i need your help in understanding effect of ref clock on serdes operation.
>>
>> I am trying to understand one design, where IBM's 6.4Gbps serdes was used.
>> I went through its architecture, and i could see that the same ref clock
>> is
>> being used for Rx and Tx.
>>
>> i would like to understand the effect of frequency variation and Phase
>> variation of the reference clock provided on both Tx side and Rx side.
>>
>> I assume on RX side, there might be dependancy on the frequnecy but not
>> phase, where as on Tx side, there would be dependancy on both phase and
>> frequency. Please correct if i have mistaken.
>>
>> It would help , even if you point to good source of document related to
>> this
>> SERDES and CDRs.
>>
>>
>> Thank you everyone in advance....
>>
>>
>> Regards,
>> prasad
>>
>> As an "a while back" (0.8 u, IIRC) IBM SerDes user, I doped out the
> design concept of their clock recovery circuit. I don't believe I'm
> violating any NDA that was in force at the time. That older design used
> the same ref clk for both transmit and receive blocks. However, they
> cleverly built a block called a "PHASE ROTATOR" into the clock
> recovery of the RX block. It generated a multi-phase clock at the data
> frequency (or F/2?) and used a mux to apply one of those phases to the
> data recovery register. When a data edge appeared early or late in the
> register, the phase selection was changed by an amount which would tend
> to center the next edge when it appeared.
>
> In essence, they generated a variable frequency/phase data clock,
> coarsely locked to the data transitions, from a fixed frequency/multi
> phase reference. At the time, I was pretty impressed by the technique.
> Now that I'm retired, I'm still impressed, but much less concerned!
> Since the supplied reference controls the TX clocking, its phase
> stability and frequency tolerance will directly effect the BER of the
> link.
>
> All that to say that using a single fixed reference freq/phase for both
> TX and RX has been done for a while now; I'm not sure how they are doing
> it in today's technology.
>
> Mike
>
>
>
>
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List forum is accessible at:
http://tech.groups.yahoo.com/group/si-list
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
