OPENCORES.ORG

Yes Markus,

Dipak Modi wrote:
> Yes Markus,
>
> Your answer is satisfactory. Now I can understand that if xfer is with 
> NRZI then no matter of the data content the line regularly changes 
> it's state and from this we can detect the xfer rate.
>
> If xfer data stream is not NRZI then there must be either separate 
> clock bus or 'PREAMBLE' pattern support. I would like to know about 
> this PREAMBLE pattern technique for clock retrieval.
>

Manchester codes are not the only possibility.
Codes such as  8b10b are  chosen with lower overhead  than the 2x 
manchester requires
to produce a transition-rich bitstream. And transitions are what you 
need to recover a clock.

alternately the telecomms world scrambles data  by xor-ing with a  PRBS 
polynomial.
Statistically this raises the transition density (for most data..)
Overhead is less - and strings of more then 40  consecutive  same bits 
are pretty rare.

> Thanks OC group,
>
> Dipak
>
>
>
> markus@r... wrote:
>
>> From: Dipak Modi<dipakm@e...>
>>  
>>
>>> What is 'embedded clock' concept? I've heard that receiver device 
>>> extracts clock from the data at its end. Any information given would 
>>> be appreciated.   
>>
>>
>> Do you mean those serial protocols, where the encoding of the data 
>> contains some means to synchronize the receiver to the data stream 
>> (like USB's NRZI). The common thing is, that no matter of the data 
>> content the line regularly changes it's state (using encoding or 
>> synchronization patterns), so that you can synchronize the receiving 
>> to the edges (and possibly detect the transfer speeds).
>>
>> This way you don't need additional clock line in the implementation, 
>> while still getting somewhat reliable transfers.
>>
>> Google search: "return-to-zero" and "non-return to zero"
>> _______________________________________________
>> http://www.opencores.org/mailman/listinfo/cores
>>
>>
>>  
>>
>
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/cores