Clock recovery / serial communication

[sonaiko]

Guys I have a question..

Lets say I am receiving digital serial data. For example 1Gbps. I need a clock to sample such data and be able to retrieve it, since it could be totally random.

I need to extract such clock from my data, in whats called clock recovery.

Now my questions are:

1. Do I HAVE to use PLL to recover my clock? (phase locked loop)
2. If yes, is there anyway I can do it with all digital PLL?
3. Anyway I can simulate such work in verilog?
4. If I am receiving 1Gbps, could it become 900Mbps due to noise, for example?

Thanx.

 

[Sceadwian]

What clock encoding method are you using, or none?
https://en.wikipedia.org/wiki/Line_code

If you're not using clock encoding you have to establish some kind of handshaking protocol or frame system where a standard clock can be sampled at some point in the data stream. If you're using no encoding method and a standard serial bit stream like 8 bits no parity 1 stop bit sending a capital letter "U" over the serial line will generate a clock at the bitrate of the transmission line. You need to describe the serial stream in a little more detail for a better responce. And whatever bit rate you're transmitting at you will NEVER see that throughput on the recieving end, there is always overhead, either for clock encoding or frameing and then there's also the protcol overhead.

 

[sonaiko]

What clock encoding method are you using, or none?
https://en.wikipedia.org/wiki/Line_code

If you're not using clock encoding you have to establish some kind of handshaking protocol or frame system where a standard clock can be sampled at some point in the data stream. If you're using no encoding method and a standard serial bit stream like 8 bits no parity 1 stop bit sending a capital letter "U" over the serial line will generate a clock at the bitrate of the transmission line. You need to describe the serial stream in a little more detail for a better responce. And whatever bit rate you're transmitting at you will NEVER see that throughput on the recieving end, there is always overhead, either for clock encoding or frameing and then there's also the protcol overhead.

Thanx for the response.

I am using NRZ encoding. My input rate is still unknown, thats why I only suggested an example up there. My point is, if I know for a fact that im receiving for example 1Gbps data, then why not just have a 1GHz clock ready to sample? why go through all the complex design of PLL? maybe im mistaken here..

Lets just forget about parities and talk pure hardware design in here.. Ofcourse i can shape up my results later using parities and other methods..

Thanx.

 

[Sceadwian]

You could rely simply on supplying a clock rate the same but 1Gbit is a very high data rate. Clock jitter and natural clock error between the two clocks will cause them to go out of phase very rapidly and if they're not exactly in phase all you're going to get is random giberish on the receiving end. You could do such a setup and test it with small byte packets and get good results, but as soon as you start sending large hunks of unbroken data you're clock will drift if it's not synchronized somehow and you'll go from good data to bad.

What is the transmission media, is this for a local board interconnect or is it some form of wireless?
PLL aside you have to be able to extract clock information and you can't do that with simple NRZ encoding, you have to use something like Manchester or any of the byte mapping methods that provide overall DC ballance. I think ethernet still uses Differential Manchester encoding, it sacrifices a lot of bandwidth but you get a phase perfect clock and data out at the other end as long as the stream remains intact, no PLL needed you just have to extract the clock from the serial stream. I think that can be done with simple discrete logic and some registers though I don't know the specific layout. That'd be a topic for another thread.

 

[Sceadwian]

Just another note.
I'd read the entire 'line code' entry on Wikipedia that will explain how the various encoding methods work. Look at the 64b/66b mapping. You need to send data in 64 bit packets but it's very efficient, it only wastes 3% of bandwidth instead of the 50% of Manchester encoding, but decoding the clock is going to be significantly more complicated, that's why Manchester encoding is still used in a lot of applications, especially in noisy environments.

 

[sonaiko]

Just another note.
I'd read the entire 'line code' entry on Wikipedia that will explain how the various encoding methods work. Look at the 64b/66b mapping. You need to send data in 64 bit packets but it's very efficient, it only wastes 3% of bandwidth instead of the 50% of Manchester encoding, but decoding the clock is going to be significantly more complicated, that's why Manchester encoding is still used in a lot of applications, especially in noisy environments.

Thanx for the replies.

What if I receive NRZ and transform it to RZ in the receiver side before I extract its clock? Is it -theoretically- possible?

Actually I am trying to make a low power design, so PLL is not my best friend in this case. I still dont know the exact application I will be using it on coz it depends if im using PLL (high power, high speed) or not (low power, low speed).. I thought I could combine (low power, high speed) together but seems only in my dreams!..

Yeah I gotta read more about the bit encoding.. So ur saying if I use 8b/10b or 64b/66b I dont need a PLL to extract clock from NRZ data?

 

[Sceadwian]

You don't seem to understand encoding methods at all. NRZ and RZ are VERY basic encoding methods and don't contain any clock information at all. Even with a PLL you'll need to use some kind of encoding method that contains clock information. Basic NRZ or RZ data will contain random frequencies depending on the data being sent and will contain no information for a PLL to lock onto. 8b/10b and the other encoding methods out there use less bandwidth than Manchester encoding but it's more difficult to decode the data. Manchester encoding has been around for a long time and is widely used. Just don't forget, if you want 1Gbps of data throughput you'll need to transmit bits at 1Gbps, which means 50% of the bandwidth is the clock. The more advanced low bandwidth encoding methods were designed primarily for RF communication where bandwidth is a premium.

 

[Papabravo]

Encoding is what we do to give the clock recovery circuit a fighting chance to accurately recover the clock by limiting the bandwidth of the incoming data stream.

You cannot do what you want with RZ or NRZ. NRZI with bit stuffing might get you there. I think it's what they use on USB. Being differential USB has some other rules about what happens to the differential lines in various conditions. The spec is available online at www.usb.org

 

[Sceadwian]

The method you use strongly depends on your application, and since you don't have one the sky is the limit.

 

[sonaiko]

Ok guys thank you for ur helpful information.

So, ur saying despite the encoding im using i will have to use a clock recovery circuit. Fine. My question now is: this clock recovery circuit MUST be a PLL? I need to make a fully digital design and PLL has mostly analog components.

Is there any other methods beside PLL? (Notice that I am flexible in changing my encoding if that would get me a better solution than PLL).

 

[Sceadwian]

You appear to not actually be reading the text I've written. The encoding method you're using does NOT encode ANY clock data AT ALL, PLL or not you can not recover a clock from an NRZ data stream without using other methods to encode a clock signal on the data being transmitted in the first place.

 

[sonaiko]

Man I do understand what u have said. I do understand and I gave the idea of using NRZ only for my data.

I am asking, my first priority is "NOT to use a PLL". I can choose any kind of encoding, anything, with bit stuffing or not, anything just to make sure I am not using PLL. Anything is OK to help me achieve the goal of not using a PLL to retrieve my clock information out of my incoming bit stream.

For example I can be happy if u tell me that Manchester encoding with 8b/10b needs small circuitry and doesnt require a PLL to retrieve the clock.

In other words, which of all the available encoding techniques combination does not require a PLL to recover the clock at the receiver side?

Thanx man for the effort and time and every reply makes me closer to understanding what I need.

 

[Nigel Goodwin]

Try googling for "manchester coding", there's plenty of information about it - and is used to store data on HDD's (amongst many other things) - no need for a PLL.

 

[Papabravo]

Clock recovery without a PLL relies on the assumption that there will be periodic edges in the data stream which can be used to resyncronize a drifting clock. No need for a PLL, nobody ever said that one was necessary. What is necessary is to know how the data stream is encoded so you know the maximum time between edges. This will put a bound on the amount of drift that you can tolerate.

If your little friends are telling you that you need one, you might want to consider getting some new little friends.

I mentioned USB as an example of a serial coomunication protocol that uses NRZI and bit stuffing. Controller Area Network (CAN) is another baseband protocol that uses bit stuffing, a programmable sample point, and maximum cable distance to allow syncronization of transmitter and receiver.

Even the lowly UART manages to maintain syncronization from the leading edge of the start bit over a 10 or 11 bit frame.

It is unfortunate that you've been assigned a task for which you are long on ambition, but short on support.

 

[sonaiko]

Clock recovery without a PLL relies on the assumption that there will be periodic edges in the data stream which can be used to resyncronize a drifting clock. No need for a PLL, nobody ever said that one was necessary. What is necessary is to know how the data stream is encoded so you know the maximum time between edges. This will put a bound on the amount of drift that you can tolerate.

If your little friends are telling you that you need one, you might want to consider getting some new little friends.

I mentioned USB as an example of a serial coomunication protocol that uses NRZI and bit stuffing. Controller Area Network (CAN) is another baseband protocol that uses bit stuffing, a programmable sample point, and maximum cable distance to allow syncronization of transmitter and receiver.

Even the lowly UART manages to maintain syncronization from the leading edge of the start bit over a 10 or 11 bit frame.

It is unfortunate that you've been assigned a task for which you are long on ambition, but short on support.

Thank you for mentioning the USB as an example. I spent all yesterday reading the technical details and I came up with a good idea about that technology and what should I do next.

You have helped me alot. Thank you very much for all ur trouble. I hope u wont be bothered if I ask again in the close future

Thanx again.

 

[sonaiko]

Try googling for "manchester coding", there's plenty of information about it - and is used to store data on HDD's (amongst many other things) - no need for a PLL.

Yes I will consider this idea.

Thank you.

 

[Papabravo]

Not at all. I'm glad to have been even minimally helpful.