1
\$\begingroup\$

I'm trying to understand the ethernet interface.

My understanding is that Ethernet is an asynchronous interface since there is no explicit clock signal transmitted along with data.

So, when there is no clock explicit transmission, is it right that all forms of ethernet (10base-t, 100base-tx and 1000base-t) transmit clock and data on the same line? Like do all PHY transceivers use clock data recovery?

For example : In the 100base-tx transmit, we don't have a block that mentions the clock and data are combined together. In which stage does the data modulate the clock?

enter image description here

But in 100base-tx receive, we have this clock data recovery block.

enter image description here

Can someone tell me how the data is modulated on the clock and transmitted? And do all PHY (10base and 100base and 1000base) receivers have the CDR block?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ where are these diagrams from? Is this standards material, or just one specific implementation of the system (more likely)? Make very sure to tell "how this one device does it" from "how this kind of problem is generally solved" from "that's how the kind of problem is formulated". \$\endgroup\$ Commented Mar 11, 2022 at 14:15
  • 3
    \$\begingroup\$ we don't have a block that mentions the clock and data are combined together. We do. I mentioned "line coding" in my answer to your previous question. Can you spot the line coding in the transmitter? \$\endgroup\$ Commented Mar 11, 2022 at 14:16
  • 2
    \$\begingroup\$ by the way, it is generally not the case that you need to "combine clock and data signals"; the data is clocked, by itself. \$\endgroup\$ Commented Mar 11, 2022 at 14:19
  • \$\begingroup\$ Is the line coding (clock and data combined) done, in the NRZ-NRZI block in the transmitter? \$\endgroup\$
    – user220456
    Commented Mar 11, 2022 at 14:54
  • \$\begingroup\$ Exactly! So, that solves the first question. The second question, "do all receivers have CDR" is already answered in your previous question – no. You only need CDR if you need to recover the clock. So, don't think there's any questions left here? \$\endgroup\$ Commented Mar 11, 2022 at 15:35

1 Answer 1

1
\$\begingroup\$

Serious problem in assumption : Not explicitly sending a clock does not mean asynchronous.

Both are synchronous interfaces, the clock is implicit by looking at the received data stream.

Just like morse code, you can listen to it and receive it at any speed because the morse code data stream clocks itself because the data stream consists of symbols and framing you can easily determine the speed of symbols and each symbol. As you can determine how to receive the symbols correctly instead of accidentally receiving the symbols incorrectly.

So no, clock and data are not sent on the same line. The data stream just has clock information embedded in it, thanks to the line coding (manchester, 4b5b, etc). And yes the receiver needs to be able to lock on to the data stream to receive it correctly, and it can do it by looking at the data stream to determine when it is synchronized to it.

In 100Base-TX the data and clock are basically combined by replacing each 4-bit block of data with unique 5-bit symbol. So the 4b5b coding creates a data stream that is a self clocking signal. As only 16 symbols with less than three consecutive zero bits are used for data, a part of the remaining symbols that have 3 or more consecutive zero bits are used for framing, such as start of packet, end of packet, or sending IDLE symbol if no data is being transmitted.

\$\endgroup\$
5
  • \$\begingroup\$ Thank you. But in your 2nd para of the answer, you mentioned, "The data stream just has clock information embedded in it, thanks to the line coding (manchester, 4b5b, etc).". But in the comment from Marcus muller, it is mentioned that clock and data are combined in the NRZ-NRZI block? Can you please clarify and explain that too? Because NRZ and NRZ-I is also a line coding technique right? So, why can clock & data be combined on the NRZ & NRZ-I block? Is it because, 4b/5b line coding block comes 1st? If so, could you please help me understand the specific purpose of NRZ-NRZ-I and MLT-3? \$\endgroup\$
    – user220456
    Commented Mar 12, 2022 at 5:03
  • \$\begingroup\$ And one more doubt. In the receiver block diagram, we have a specific block that mentions clock and data recovery. Why do we need to mention specifically that there is a block for clock and data recovery in the receiver when we don't have the clock and data combination block explicitly mentioned in the transmitter ? \$\endgroup\$
    – user220456
    Commented Mar 12, 2022 at 5:05
  • 1
    \$\begingroup\$ You can read Wikipedia and find out NRZ means there is no coding at all and NRZ-I just means the output toggles state or not based on input data so these encodings do not embed clock. Again, NRZ-I encoding is required because standard says that is how it must be for both fiber and copper interfaces, and MLT-3 is to reduce signal bandwidth to make it fit through copper cables. Regarding the block diagrams, these are simplified drawings, it is clear that transmitter uses local transmit clock and it is clear that 4b5b encoding encodes clock and data into one data stream. \$\endgroup\$
    – Justme
    Commented Mar 12, 2022 at 8:40
  • \$\begingroup\$ Thank you for the clarification. Sorry as I am new to the topic and hence these questions. I am trying to understand the specific reasons of each block. So NRZ to NRZ-I is just a standard. And MLT-3 is only for reducing signal bandwidth. (Basically I understand like all encodings like, Manchester, 4B/5B, 8B/10B, MLT-3, PAM5 all purpose is to reduce the signal bandwidth)? \$\endgroup\$
    – user220456
    Commented Mar 12, 2022 at 12:47
  • 1
    \$\begingroup\$ That's a very odd assumption, as it's rather obvious that Manchester, 4b5b and 8b10b all increase the bandwidth as you get more data out than what you put in. \$\endgroup\$
    – Justme
    Commented Mar 12, 2022 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.