Ethernet / digital logic questions

Cheers, Jon

What you are discussing here is all done by the phy chip. You don't have to care unless you are replacing it yourself

Simon

The Ethernet MAC pass the data to the Ethernet PHY at a rate o

100Mbps. It pass it via standard MII protocol, which is a 4-bit wid data bus (4 bits for TX, 4 for RX)

The MAC doesn't have any knowledge of the actual encoding of th

signal on the wire. This is the PHY's job

You could well use the same MAC for either 100B-TX or 100B-FX fo

example (electrical or optical)

Manchester encoding use the same rate than the data. I.e. 100Mbps.

The PHY thus do have a clock multiplier. Manchester encode a 0 a '01' and 1 as '10'

The pattern of bits " 0 1 1 1 1 0 0 1 " encodes to " 01 10 10 10 10 0

01 10"

Another more curious example is the pattern " 1 0 1 0 1 etc" whic

encodes to "10 01 10 01 10 " which could also be viewed as "1 00 1

00 11 0 ". Thus for a 10 Mbps Ethernet LAN, the preamble sequenc encodes to a 5 MHz square wave! (i.e., One half cycle in each 0. microsecond bit period.

First keep in mind that while 25M for FastEthernet is still available slowly more and more there is a move to 50M with 2 bit known as RMII as

50M and RMII have simple implementation and clock is still relatively slow while the benefit of half the pin in multi-port is tremendous, and to some extend might be even easier for you as you have single source of clock and no more rx and tx clock each have its own ppm's.

Manchester is generally speaking used only in Fiber and not over cupper.

As for Manchester Freq since each bit is represents by two bits (0 become 01, 1 become 10) the Manchester frequency is double the Data frequency.

As for FastEthernet Cupper the freq over the wire as far as I know will be

100M from Mac to Phy let say using 25Mx4 Than in the phy after the 4/5 bit encoding 25x4/5 =125 Than after MLT3 125x2/3= ~83M.

While 100x10/8 is also giving 125 keep in mind that 8/10 bit encoding is used in GigEth and not in FastEth which use 4/5. The main difference is that both give extra range for special character however the 8/10 also take into account how many zero and one are send and balance them while 4/5 don't.

Never the less as mention before you don't need to worry about the encoding and frequency over the line as this is the phy responsibility and not the MAC.

Talking about Manchester there are two way to sync, one which use a pre known stream send like preamble (The problem of sync is since if you see infinite stream like ...10101010... you don't know if the source was all 0 or all 1). However in my opinion a better way to sync if you have the option to do it is to look for change. The interesting thing in Manchester is that when you get something like ....001 you have no clue about the past but you know for sure that the last 2 digit is due to 0 in the source and you are now in sync. Similar ......110 tell you the last two digits are due to 1 in the source and you are now in sync.

Have fun.

The MAC interfaces to the phy using MII, which is a parallel bus. So all of your questions are not really applicable to the MAC. They are good questions vis-a-vis the phy, but (sensible) people don't generate phy's on FPGA's. ;-)

[snip]

--Mac

I see, so MLT3 is used for copper Ethernet.

Ok, understood, but I would like to understand how a PHY might decode

100 Mbps Ethernet copper (MLT3) and how it might handle Manchester data. This is more for my understanding than anything else.

Can you explain the Manchester decoding a bit more? So if the source sends all 1's or all 0's as a sync. frame, then how exactly do you extract the clock/data?

I'm assuming the local circuit is running at the data rate; i.e. if I have 100 Mbps serial stream, then I have a 100 MHz clock available.

So I would clock a shift register at 100 MHz and RX the 100 MBps stream (assuming it is Manchester encoded) and study the 1's and 0's to figure out how close I am to matching?

(I think 12 Mbps USB uses a 48 MHz clock for DPLLing, so I guess you have to oversample)?

Thanks all. H.

The result of Manchester coding is that in the "high" part of the clock you send the data bit and in the "low" part of the clock you send the opposite Therefore if you want to send the data 0 and your period is 100n than for 50n you will send 0 and for the next 50n you will send 1. This is why from frequency point of view you have double the frequency however from "effective" data you have the same throughput.

How to extract the clock from any serial stream whether it have Manchester or not usually mean you have some sort of PLL (might be digital not necessarily analog but to make life easier I will simple use the word PLL for all) which get reference clock from probably an on board oscillator and than use to to recover the clock of the incoming data.

In order to be able to find the right place to put the edge of the clock as well as the right frequency you need "enough" changes as just imagine you send only 0 how the receive side can tell what freq and what is the phase.

This is by the way one of the reason there is preamble because the receive side need some data to be able to align itself. In FastEth the Phy don't really need so much preamble/sfd however recall that in Eth (10M) the media was quite most of the time (in FastEth there is constantly transmission of idle even when there is no data to send to the receive Phy is constantly in sync)

As for how to find the best position for the clock in Manchester that once the CDR recover the clock you have double the clock so divide by two will give the right frequency as for the phase take the ....001... as the sync point than knowing that the last 01 was due to 0 if the clock move from 0 to 1 the 01 pattern and go to zero after the 1 and so on you have now the clock in the middle of your data and than you can sample this data with the new clock and you are back in business.

Have fun.