fpga4fun ethernet

[Paul]

Hi

I've just read through the page. Found one problem:

// IP header
7'h14: pkt_data <= 8'h08;
7'h15: pkt_data <= 8'h00;

According to my textbook from Tanenbaum.
This 2 bytes should be the length of the MAC data.
From the rest of codes, it should be "0x48 - 8" , i.e.
7'h14: pkt_data <= 8'h00;
7'h15: pkt_data <= 8'h40;
// IP header
...
...

I wonder why it should work if it did. (I can't test it yet.)
Does that imply you can switch positions for CRC and some 4 data bytes?

Also one more question:
I notice there are idle bits inserted for mechester encoding. is that necessary?
Since I have a PHY chip, I guess I don't have to worry about that. Just curious.

Thanks.

 

[Allan Herriman]

On 18 Jan 2004 17:31:14 -0800, paulw@mmail.ath.cx (Paul) wrote:

Hi

I've just read through the page. Found one problem:

// IP header
7'h14: pkt_data <= 8'h08;
7'h15: pkt_data <= 8'h00;

According to my textbook from Tanenbaum.
This 2 bytes should be the length of the MAC data.
From the rest of codes, it should be "0x48 - 8" , i.e.
7'h14: pkt_data <= 8'h00;
7'h15: pkt_data <= 8'h40;
// IP header
...
...

I wonder why it should work if it did. (I can't test it yet.)
Does that imply you can switch positions for CRC and some 4 data bytes?

Also one more question:
I notice there are idle bits inserted for mechester encoding. is that necessary?
Since I have a PHY chip, I guess I don't have to worry about that. Just curious.

You've come across the difference between Ethernet II and IEEE802.3.

Ethernet II frame:

Dest Addr (6 bytes)
Src Addr (6 bytes)
Ethertype (2 bytes, 0800 for IPv4)
Data
FCS (4 bytes)

IEEE802.3 SNAP frame:
Dest Addr (6 bytes)
Src Addr (6 bytes)
Length (2 bytes)
DSAP (1 byte)
SSAP (1 byte)
CTRL (1 byte)
OUI (3 bytes)
type (2 bytes)
Data
FCS (4 bytes)

Note that the Ethertype fields have values that are (usually) greater
than the maximum frame length, so that (usually) there is no
ambiguity.
I say usually because jumbo Ethernet frames can have lengths up to 9k
bytes or so, and some Ethertypes have values less than 9k. This is
probably why jumbo ethernet frames always use Ethernet II framing (and
are not approved by the IEEE).

BTW, you could try reading the IETF RFC that describes how to
encapsulate IPv4 in ethernet frames (rather than relying on
Tanenbaum). I don't recall the RFC number, but I'm sure you know how
to use a search engine.
http://www.ietf.org

Regards,
Allan.