[SI-LIST] Re: to what extent recovered clock depends on the serdes ref clock
- From: Vinu Arumugham <vinu@xxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Thu, 12 Apr 2012 11:05:30 -0700
Venkat,
A recovered clock if one is available should always match the incoming
data rate.
If you are observing different behavior, I don't think it can be the
recovered clock.
I don't know if an IBM HSS serdes TX can accept a recovered clock as
reference. I have never seen it used that way. If the TX has to use the
local reference clock, your device will need to implement PCS
functionality to descramble/decode, add/remove characters (to handle the
ppm difference) and scramble/code the data back before re-transmitting.
Thanks,
Vinu
On 04/11/2012 10:29 PM, prasad wrote:
> 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
>
>
>
------------------------------------------------------------------
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:
