Ethernet / digital logic questions

Ok,

I'm not designing an Ethernet MAC but I see that people now make FPGA 
cores for this.

I had a few "general" questions on how these might be implemented.

1.  I know Ethernet bits flow across as Manchester encoded data.  I see 
that many of the cores run from a 25 MHz clock.  

How is the 125 Mbps (8/10 encoded data) serial stream generated without 
some sort of clock multiplication?

2.  How does the clock / data recovery work from the 25 MHz clock too?  

I've seen examples of Manchester decoding and usually there is some 
high-speed clock available that it used to examine the preamble/sync 
bits and this is clocked into a shift register at 4-8x line frequency.  
The shift register is used to adjust a counter which determines when to 
sample -- or so my understanding goes.

Are there any good resources that explain the "low-level" details of how 
hardware Ethernet implementations might work?

Thank you.
H.

> Are there any good resources that explain the "low-level" details of how
> hardware Ethernet implementations might work?

http://www.fpga4fun.com/10BASE-T.html

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

"Hw" <localhost@com.com> wrote in message
news:N1ele.34256$ya2.32286@tornado.socal.rr.com...
> Ok,
>
> I'm not designing an Ethernet MAC but I see that people now make FPGA
> cores for this.
>
> I had a few "general" questions on how these might be implemented.
>
> 1.  I know Ethernet bits flow across as Manchester encoded data.  I see
> that many of the cores run from a 25 MHz clock.
>
> How is the 125 Mbps (8/10 encoded data) serial stream generated without
> some sort of clock multiplication?
>
> 2.  How does the clock / data recovery work from the 25 MHz clock too?
>
> I've seen examples of Manchester decoding and usually there is some
> high-speed clock available that it used to examine the preamble/sync
> bits and this is clocked into a shift register at 4-8x line frequency.
> The shift register is used to adjust a counter which determines when to
> sample -- or so my understanding goes.
>
> Are there any good resources that explain the "low-level" details of how
> hardware Ethernet implementations might work?
>
> Thank you.
> H.

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.

On Thu, 26 May 2005 06:30:05 +0000, Hw wrote:

> Ok,
> 
> I'm not designing an Ethernet MAC but I see that people now make FPGA 
> cores for this.
> 
> I had a few "general" questions on how these might be implemented.
> 
> 1.  I know Ethernet bits flow across as Manchester encoded data.  I see 
> that many of the cores run from a 25 MHz clock.  
> 
> How is the 125 Mbps (8/10 encoded data) serial stream generated without 
> some sort of clock multiplication?
> 

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]

> 
> Thank you.
> H.

--Mac

Thanks all for responses.

In article <1117127547.037328.263220@g44g2000cwa.googlegroups.com>, 
wooster.berty@gmail.com says...

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

> 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.

I see, so MLT3 is used for copper Ethernet.
 
> 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.

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.
 
> 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.

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.