Ethernet: IEEE 802.

3 Local Area Network (LAN) protocols Ethernet protocols refer to the family of local -area network (LAN) covered by the IEEE 802.3. In the Ethernet standard, there are two modes of operation: half-duplex and full-duplex modes. In the half duplex mode, data are transmitted using the popular Carrier-Sense Multiple Access/Collision Detection (CSMA/CD) protocol on a shared medium. The main disadvantages of the half -duplex are the efficiency and distance limitation, in which the link distance is limited by the minimum MAC frame size. This restriction reduces the efficiency drastically for high-rate transmission. Therefore, the carrier extension technique is used to ensure the minimum frame size of 512 bytes in Gigabit Ethernet to achieve a reasonable link distance. Four data rates are currently defined for operation over optical fiber and twisted-pair cables: y y y y 10 Mbps - 10Base-T Ethernet (IEEE 802.3) 100 Mbps - Fast Ethernet (IEEE 802.3u) 1000 Mbps - Gigabit Ethernet (IEEE 802.3z) 10-Gigabit - 10 Gbps Ethernet (IEEE 802.3ae).

In this document, we discuss the general aspects of the Ethernet. The specific issues regarding Fast Ethernet, Gigabit and 10 Gigabit Ethernet will be discussed in separate documents. The Ethernet system consists of three basic elements: 1. the physical medium used to carry Ethernet signals between computers, 2. a set of medium access control rules embedded in each Ethernet interface that allow multiple computers to fairly arbitrate access to the shared Ethernet channel, and 3. an Ethernet frame that consists of a standardized set of bits used to carry data over the system. As with all IEEE 802 protocols, the ISO data link layer is divided into two IEEE 802 sublayers, the Media Access Control (MAC) sublayer and the MAC-client sublayer. The IEEE 802.3 physical layer corresponds to the ISO physical layer. The MAC sub-layer has two primary responsibilities: y y Data encapsulation, including frame assembly before transmission, and frame parsing/error detection during and after reception Media access control, including initiat ion of frame transmission and recovery from transmission failure

The MAC-client sub-layer may be one of the following: y Logical Link Control (LLC), which provides the interface between the Ethernet MAC and the upper layers in the protocol stack of the end station. The LLC sublayer is defined by IEEE 802.2 standards. Bridge entity, which provides LAN-to-LAN interfaces between LANs that use the same protocol (for example, Ethernet to Ethernet) and also between different protocols (for example, Ethernet to Token Ring). Bridge entities are defined by IEEE 802.1 standards.

Each Ethernet-equipped computer operates independently of all other stations on the network: there is no central controller. All stations attached to an Ethernet are connected to a shared si gnaling system, also called the medium. To send data a station first listens to the channel, and when the channel is idle the station transmits its data in the form of an Ethernet frame, or packet. After each frame transmission, all stations on the network must contend equally for the next frame transmission opportunity. Access to the shared channel is determined by the medium access control (MAC) mechanism embedded in the Ethernet interface located in each station. The medium access control mechanism is based on a system called Carrier Sense Multiple Access with Collision Detection (CSMA/CD). As each Ethernet frame is sent onto the shared signal channel, all Ethernet interfaces look at the destination address. If the destination address of the frame matches with the interface address, the frame will be read entirely and be delivered to the networking software running on that computer. All

other network interfaces will stop reading the frame when they discover that the destination address does not match their own address. When it comes to how signals flow over the set of media segments that make up an Ethernet system, it helps to understand the topology of the system. The signal topology of the Ethernet is also known as the logical topology, to distinguish it from the actual physical layout of the media cables. The logical topology of an Ethernet provides a single channel (or bus) that carries Ethernet signals to all stations. Multiple Ethernet segments can be linked together to form a larger Ethernet LAN using a signal amplifying and retiming device called a repeater. Through the use of repeaters, a given Ethernet system of multiple segments can grow as a "non-rooted branching tree." Non-rooted" means that the resulting system of linked segments may grow in any direction, and does not have a specific root segment. Most importantly, segments must never be connected in a loop. Every segment in the system must have two ends, since the Ethernet system will not operate correctly in the presence of loop paths. Even though the media segments may be physically connected in a star pattern, with multiple segments attached to a repeater, the logical topology is still that of a single Ethernet channel that carries signals to all stations.

Network Monitoring and Troubleshooting Easy to use tool with comprehensive features at a fraction of the cost of others. Click here for free demo.

Technical books, quick guides and posters Networking, telecom, computing, wireless, information technologies, security and much more ... Click here for details.

Protocol Structure - Ethernet: IEEE 802.3 Local Area Network protocolsThe basic IEEE 802.3 Ethernet MAC Data Frame for 10/100Mbps Ethernet: 7 Pre y 1 SFD 6 DA 6 SA 2 Length Type 46-1500bytes Data unit + pad 4 FCS

y y y

y y

Preamble (PRE)- 7 bytes. The PRE is an alternating pattern of ones and zeros that tells receiving stations that a frame is coming, and that provides a means to synchronize the framereception portions of receiving physical layers with the incoming bit stream. Start-of-frame delimiter (SFD)- 1 byte. The SOF is an alternating pattern of ones and zeros, ending with two consecutive 1 -bits indicating that the next bit is the left -most bit in the leftmost byte of the destination address. Destination address (DA)- 6 bytes. The DA field identifies which station(s) should receive the frame.. Source addresses (SA)- 6 bytes. The SA field identifies the sending station. Length/Type- 2 bytes. This field indicates either the number of MAC -client data bytes that are contained in the data field of the frame, or the frame type ID if the frame is assembled using an optional format. Data- Is a sequence of n bytes (46=< n =<1500) of any value. (The total frame minimum is 64bytes.) Frame check sequence (FCS)- 4 bytes. This sequence contains a 32-bit cyclic redundancy check (CRC) value, which is created by the sending MAC and is recalculated by the receiving MAC to check for damaged frames.

MAC Frame with Gigabit Ethernet Carrier Extension (IEEE 803.3z) 1000Base-X has a minimum frame size of 416bytes, and 1000Base-T has a minimum frame size of 520bytes. The Extension is a non -data variable extension field to frames that are shorter than the minimum length.

7 Pre

1 SFD

6 DA

6 SA

2 Length Type

Variable Data unit + pad

4 FCS

Variable Ext

Related Protocols IEEE 802.3 , 802.3u , 802.3z , 802.2 , 802.1, 802.3ae , 802.1D , 802.1G, 802.1Q , 802.1p , 802.1X , FDDI , Token Ring Sponsor Source Ethernet is defined by IEEE (http://www.ieee.org ) 802.3 and related specifications.

Reference http://standards.ieee.org/getieee802/download/802.3 -2002.pdf : Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specification. http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm : Ethernet Technologies http://www.cisco.com/warp/public/cc/techno/media/lan/gig/tech/gigbt_tc.htm : Introduction to gigabit Ethernet

Gigabit Ethernet Description

The Ethernet standard uses Manchester Encoding and Decoding. Access control is gained via Carrier Sense, Multiple Access with Collision Detect (CSMA_CD). However 10 Gigabit Ethernet [10GE] only uses Fullduplex, so CSMA/CD is not required. Preamble Field: A 56 bit pattern of alternating ones and zeros which are used to synchronize the receiver clock to the incoming data packet. SFD Field: Start Frame Delimiter Field, indicates the beginning of the frame; [10101011].

Ethernet Packet

1000Base-T. [Gigabit Ethernet] operates up to 100 meters on EIA568, 4-pair [CAT-5] UTP [Un-Shielded Twisted Pair] 100 ohm copper wiring. This is backwards compatible with 100Base-T. Also uses Fibre Channel as the physical layer, and runs at 1000Mbps, using 8B/10B encoding [10 bits = 1 byte].

10-Gigabit Ethernet Block Diagram

10Gb Attachment Unit Interface [Gigabit Ethernet XAUI] is used as an interface extender for 10-gigabit media-independent interface [XGMII]. The XAUI interface is a backplane interface, Chip-to-Chip interface, or board interface. XAUI uses four full-duplex serial links operating at 3.125 Gbps in each direction. In aggregate, a total of 12.5 Gbps can be transferred in each direction. The Gigabit Media Independent Interface [GMII] is the interface between the Media Access Controller [MAC] layer and Physical Layer and is divided into three sublayers : PCS, PMA and PMD. The MII [Media Independent Interface] was developed for Fast Ethernet. Physical Coding Sublayer [PCS] is the GMII sub-layer responsible for the interface to the Reconciliation layer. The PCS layer uses 8B/10B encoding. Physical Medium Attachment [PMA] is the GMII sub-layer responsible for providing a mediumindependent for the PCS to support serial bit -oriented physical media. This layer serializes code groups for transmission and deserializes bits received from the medium into code groups. The Gigabit Ethernet PMA interface is identical to the PMA interface used in FiberChannel, but the difference is FiberChannel utilizes 1.062-gigabaud signaling while Gigabit Ethernet utilizes 1.25-gigabaud signaling. Encoding is 8B/10B. Physical Medium Dependent [PMD] is the GMII sub-layer responsible for mapping the physical medium to the PCS. The Medium Dependent Interface [MDI] is the physical layer interface, and is part of the PMD.

Gigabit XAUI Physical Layer

10Gb Sixteen-Bit Interface [XSBI], WAN Interface Sublayer [WIS], XAUI Extender Sublayer [XGXS] The frame check sequence is derived from a Cyclic Redundancy Code (CRC); the coefficients are generated modulo-2: X31 + X26 + X23 + X22 + X16 + X12 + X11 + X10 + X8 + X7 + X5 + X4 +X2 + X + 1 10Base Ethernet is listed on the Ethernet Bus page, which contains a description and additional links {Gigabit Ethernet Interface Bus Index}

Ethernet Bus 1000BaseT RJ45 Pin Out

RJ45 Connector

Ethernet 1000BaseT (Twisted Pair Pinout) Pin # Signal Name Function 1 BI_DA+ Bi-directional pair +A

2 3 4 5 6 7 8

BI_DABI_DB+ BI_DC+ BI_DCBI_DBBI_DD+ BI_DD-

Bi-directional pair -A Bi-directional pair +B Bi-directional pair +C Bi-directional pair -C Bi-directional pair -B Bi-directional pair +D Bi-directional pair -D

The pinout table above describes what some call the CAT-5 pinout as found on an RJ-45 connector. The CAT-5 pinout pairs 1/2, 3/6, 4/5, and 7/8 pins together. Another version of the pinout is called the Standard pinout and also uses an RJ45 connector. The standard pin out pairs pins 1/2, 3/4, 5/6, and 7/8 together. The MII interface pinout is listed on it's own page [Media-independent interface]. Refer to the AUI Pinout page for the pin out of the AUI connector, used with older Ethernet interfaces.
================================================================================== FPGA4FUN WEBSITE

10BASE-T FPGA interface part 0 - A recipe to send Ethernet traffic

Here we demonstrate how to send Ethernet traffic directly from an FPGA to a PC. For this recipe, you'll need: 1. 2. 3. An FPGA development board, with 2 free IOs and a 20MHz clock. A PC with an Ethernet card, and the TCP-IP stack installed (if you can browse the Internet, you're good). Optionally, a network hub or switch.

1. Connect the FPGA board to the Ethernet network

Here's a view of a typical test setup, using an Ethernet hub or switch.

Using a hub or switch allows the PC to stay connected to your regular network (if you have one) while doing this experiment. But you can also connect the FPGA directly to the PC. We are using a Pluto board here with an external 20MHz oscillator. Connect two IOs from the FPGA board to an Ethernet cable.

y y

If the cable's other end connects to a hub or switch (like on the picture above), use pin 1 and 2 of the Ethernet cable. If the cable's other end connects directly to the PC, use pin 3 and 6.

For the pin numbers, get help from this picture:

Note that the polarity usually doesn't matter, because the signal is differential and Ethernet equipment can detect the polarity from the incoming signal. Also even if that works in practice, we are not compliant to the Ethernet electrical requirements by just connecting the FPGA to a cable (we would need a filter and a transformer). So let's just consider that a "lab" experiment.

2. Get the network info from the PC

Type "ipconfig /all" on the command-line.

Write down your "Physical Address" and your "IP Address".

3. Program the FPGA

Compile the following Verilog HDL code. Make sure to:

y y

Update the data values ("IP source", "IP destination" and "Physical Address") in the code. Do the correct pin assignment for your board (there are just 3 pins used!).

module TENBASET_TxD(clk20, Ethernet_TDp, Ethernet_TDm); // a 20MHz clock (this code won't work with a different frequency) input clk20; // the two differential 10BASE-T outputs output Ethernet_TDp, Ethernet_TDm; // "IP source" - put an unused IP - if unsure, see comment below after the source code parameter IPsource_1 = 192; parameter IPsource_2 = 168; parameter IPsource_3 = 0; parameter IPsource_4 = 44; // "IP destination" - put the IP of the PC you want to send to parameter IPdestination_1 = 192; parameter IPdestination_2 = 168; parameter IPdestination_3 = 0; parameter IPdestination_4 = 2; // "Physical Address" - put the address of the PC you want to send to parameter PhysicalAddress_1 = 8'h00; parameter PhysicalAddress_2 = 8'h07; parameter PhysicalAddress_3 = 8'h95; parameter PhysicalAddress_4 = 8'h0B; parameter PhysicalAddress_5 = 8'hFB; parameter PhysicalAddress_6 = 8'hAF; ////////////////////////////////////////////////////////////////////// // sends a packet roughly every second reg [23:0] counter; always @(posedge clk20) counter<=counter+1; reg StartSending; always @(posedge clk20) StartSending<=&counter; ////////////////////////////////////////////////////////////////////// // we send a UDP packet, 18 bytes payload // calculate the IP checksum, big-endian style parameter IPchecksum1 = 32'h0000C53F + (IPsource_1<<8)+IPsource_2+(I Psource_3<<8)+IPsource_4+ (IPdestination_1<<8)+IPdestination_2+(IPdestination_3<<8)+(IPdes tination_4); parameter IPchecksum2 = ((IPchecksum1&32'h0000FFFF)+(IPchecksum1>>16)); parameter IPchecksum3 = ~((IPchecksum2&32'h0000FFFF)+(IPchecksum2>>16)); reg [6:0] rdaddress; reg [7:0] pkt_data; always @(posedge clk20) case(rdaddress) // Ethernet preamble 7'h00: pkt_data <= 8'h55; 7'h01: pkt_data <= 8'h55; 7'h02: pkt_data <= 8'h55; 7'h03: pkt_data <= 8'h55; 7'h04: pkt_data <= 8'h55; 7'h05: pkt_data <= 8'h55; 7'h06: pkt_data <= 8'h55; 7'h07: pkt_data <= 8'hD5; // Ethernet header 7'h08: pkt_data <= PhysicalAddress_1;

7'h09: pkt_data <= PhysicalAddress_2; 7'h0A: pkt_data <= PhysicalAddress_3; 7'h0B: pkt_data <= PhysicalAddress_4; 7'h0C: pkt_data <= PhysicalAddress_5; 7'h0D: pkt_data <= PhysicalAddress_6; 7'h0E: pkt_data <= 8'h00; 7'h0F: pkt_data <= 8'h12; 7'h10: pkt_data <= 8'h34; 7'h11: pkt_data <= 8'h56; 7'h12: pkt_data <= 8'h78; 7'h13: pkt_data <= 8'h90; // IP header 7'h14: pkt_data <= 8'h08; 7'h15: pkt_data <= 8'h00; 7'h16: pkt_data <= 8'h45; 7'h17: pkt_data <= 8'h00; 7'h18: pkt_data <= 8'h00; 7'h19: pkt_data <= 8'h2E; 7'h1A: pkt_data <= 8'h00; 7'h1B: pkt_data <= 8'h00; 7'h1C: pkt_data <= 8'h00; 7'h1D: pkt_data <= 8'h00; 7'h1E: pkt_data <= 8'h80; 7'h1F: pkt_data <= 8'h11; 7'h20: pkt_data <= IPchecksum3[15:8]; 7'h21: pkt_data <= IPchecksum3[ 7:0]; 7'h22: pkt_data <= IPsource_1; 7'h23: pkt_data <= IPsource_2; 7'h24: pkt_data <= IPsource_3; 7'h25: pkt_data <= IPsource_4; 7'h26: pkt_data <= IPdestination_1; 7'h27: pkt_data <= IPdestination_2; 7'h28: pkt_data <= IPdestination_3; 7'h29: pkt_data <= IPdestination_4; // UDP header 7'h2A: pkt_data <= 8'h04; 7'h2B: pkt_data <= 8'h00; 7'h2C: pkt_data <= 8'h04; 7'h2D: pkt_data <= 8'h00; 7'h2E: pkt_data <= 8'h00; 7'h2F: pkt_data <= 8'h1A; 7'h30: pkt_data <= 8'h00; 7'h31: pkt_data <= 8'h00; // payload 7'h32: pkt_data <= 8'h00; // put here the data that you want to send 7'h33: pkt_data <= 8'h01; // put here the data that you want to send 7'h34: pkt_data <= 8'h02; // put here the data that you want to send 7'h35: pkt_data <= 8'h03; // put here the data that you want to send 7'h36: pkt_data <= 8'h04; // put here the data that you want to send 7'h37: pkt_data <= 8'h05; // put here the data that you want to send 7'h38: pkt_data <= 8'h06; // put here the data that you want to send 7'h39: pkt_data <= 8'h07; // put here the data that you want to send 7'h3A: pkt_data <= 8'h08; // put here the data that you want to send 7'h3B: pkt_data <= 8'h09; // put here the data that you want to send 7'h3C: pkt_data <= 8'h0A; // put here the data that you want to send 7'h3D: pkt_data <= 8'h0B; // put here the data that you want to send 7'h3E: pkt_data <= 8'h0C; // put here the data that you want to send 7'h3F: pkt_data <= 8'h0D; // put here the data that you want to send 7'h40: pkt_data <= 8'h0E; // put here the data that you want to send

7'h41: pkt_data <= 8'h0F; // put here the data that you want to send 7'h42: pkt_data <= 8'h10; // put here the data that you want to send 7'h43: pkt_data <= 8'h11; // put here the data that you want to send default: pkt_data <= 8'h00; endcase ////////////////////////////////////////////////////////////////////// // and finally the 10BASE-T's magic reg [3:0] ShiftCount; reg SendingPacket; always @(posedge clk20) if(StartSending) SendingPacket<=1; else if(ShiftCount==14 && rdaddress==7'h48) SendingPacket<=0; always @(posedge clk20) ShiftCount <= SendingPacket ? ShiftCount+1 : 15; wire readram = (ShiftCount==15); always @(posedge clk20) if(ShiftCount==15) rdaddress <= SendingPacket ? rdaddress+1 : 0; reg [7:0] ShiftData; always @(posedge clk20) if(ShiftCount[0]) ShiftData <= readram ? pkt_data : {1'b0, ShiftData[7:1]}; // generate the CRC32 reg [31:0] CRC; reg CRCflush; always @(posedge clk20) if(CRCflush) CRCflush <= SendingPacket; else if(readram) CRCflush <= (rdaddress==7'h44); reg CRCinit; always @(posedge clk20) if(readram) CRCinit <= (rdaddress==7); wire CRCinput = CRCflush ? 0 : (ShiftData[0] ^ CRC[31]); always @(posedge clk20) if(ShiftCount[0]) CRC <= CRCinit ? ~0 : ({CRC[30:0],1'b0} ^ ({32{CRCinput}} & 32'h04C11DB7)); // generate the NLP reg [17:0] LinkPulseCount; always @(posedge clk20) LinkPulseCount <= SendingPacket ? 0 : LinkPulseCount+1; reg LinkPulse; always @(posedge clk20) LinkPulse <= &LinkPulseCount[17:1]; // TP_IDL, shift-register and manchester encoder reg SendingPacketData; always @(posedge clk20) SendingPacketData <= SendingPacket; reg [2:0] idlecount; always @(posedge clk20) if(SendingPacketData) idlecount<=0; else if(~&idlecount) idlecount<=idlecount+1; wire dataout = CRCflush ? ~CRC[31] : ShiftData[0]; reg qo; always @(posedge clk20) qo <= SendingPacketData ? ~dataout^ShiftCount[0] : 1; reg qoe; always @(posedge clk20) qoe <= SendingPacketData | LinkPulse | (idlecount<6); reg Ethernet_TDp; always @(posedge clk20) Ethernet_TDp <= (qoe ? qo : 1'b0); reg Ethernet_TDm; always @(posedge clk20) Ethernet_TDm <= (qoe ? ~qo : 1'b0); endmodule

About the "IP source" that you have to choose in the code above, pick something that is compatible with your network, but still unused. The example network shown above have IPs starting with "192.168.0" (the PC IP is 192.168.0.2 with a mask of 255.255.255.0). So here IPs like 192.168.0.x can be used. To check if an IP is used or not, "ping" it.

4. Incoming packets
Run this UDP receiver software on the PC (source code included). You get something like this:

Send useful traffic

The code above sends 18 data bytes in each UDP packets. The 18 bytes can come from anywhere, so for example, you can modify the code to send the value of FPGA pins. Have fun sending UDP packets!

>>> NEXT: 10BASE -T FPGA interface part 1 - How Ethernet works >>>

10BASE-T FPGA interface part 1 - How Ethernet works

This is a short introduction to the Ethernet technology. If you are new to it, you can get more details from Charles Spurgeon's Ethernet web site. The comments on this page apply equally for 10BASE-T and 100BASE-T (the later being 10 times faster).

IEEE 802.3
The 10/100BASE-T interface is described in the IEEE 802.3 standard. The standard is freely available on the IEEE 802.3 Standards Association page. If you want a copy, select the latest standard "IEEE 802.3-2002". Relevant chapters include chapter 3 (MAC frame structure) and 14 (10BASE T).

RJ-45 connectors
10/100BASE-T uses RJ-45 8 pins connectors. They look like that:

Out of the 8 pins, only 4 are used: 1. 2. 3. 4. 5. 6. 7. 8. TD+ (transmit +) TD- (transmit -) RD+ (receive +)

RD- (receive -)

One pair of pins is used for transmission (TD+/TD-), one for reception (RD+/RD-). Note: This pinout is good for the RJ-45 coming out of your computer. The pinout of a hub or switch is inverted (TD on pins 3 & 6, and RD on pins 1 & 2).

Differential signal
Each pair uses a differential electric signal (differential signals are more immune to external interferences). Also each wire pair is twisted in the cable, which further improves the immunity.

Packet encoding
To send data on Ethernet, you cannot just send it like that; you have to encapsulate it into an Ethernet packet. The packet contains a header with the information necessary for the data to r each its destination. The Ethernet is based on the idea of a shared medium - if a station sends a packet, everybody on the line receives it. Each Ethernet card has a unique ID (the "MAC address"), so each card can automatically discard packets meant for another station. The MAC address is 6 bytes long (48 bits), which is big enough to allow each Ethernet card on earth to have a unique number!

Half-duplex versus Full-Duplex

Ethernet was originally built using a truly shared medium (a single coaxial cable connected to several stations). The same cable was used for both transmission and reception. So of course, you could not transmit and receive at the same time. Communication was half-duplex. Half-duplex uses a protocol called "CSMA/CD" (Carrier Sense Multiple Access with Collision Detection): In half-duplex:

y y

Before transmitting, each station has to listen to make sure the line is free ("Carrier Sense"). Still, it is possible that two stations transmit just at the same time. So a complex protocol has to exist to abort ("Collision Detection") and resume transmission later.

10/100BASE-T uses "unshielded twisted pair" cables ("UTP" cables) to replace coaxial cables. UTP cables allow full duplex because they contain separate wire pairs for transmission and rece ption. Full-duplex communication is better:

y y

You get twice the bandwidth. Each station has a dedicated medium and can start transmitting at any time without complication (CSMA/CD doesn't apply anymore).

So now, the question is, how do you get your 10/100BASE-T network to work in full-duplex?

Hubs and Switches

10/100BASE-T is a "star-topology" network. It requires the use of a concentrator appliance to connect multiple computers together. There are two types of concentrator available: "hub" or "switch".

A hub is a simple electronic device that provides electrical separation between each link but still connects them "logically" together. That forces the communication to be half-duplex. Worse: at any given time, only one computer can speak. So the network bandwidth is shared among all the computers. A switch (or "switching-hub") is a more complicated electronic device that isolates each computer link both electrically and logically. It does that by storing internally each transmitted data before re-transmitting it. So each computer can speak whenever he wants: that allows full-duplex communication. Even better: each computer has a full link bandwidth for itself. And since the medium is not shared, each stati n o receives only the packets intended to itself (privacy is improved).

In summary, for 10BASE-T networks (multiply the numbers by 10 for 100BASE-T):

Hub-ed: half-duplex on each link, with 10Mbps shared among all the computers. Slow...

Switch-ed: full-duplex on each link, with 20Mbps (10Mbps each way) dedicated for each computer. Fast!

A switch might cost a little more, but that's well worth it! This project recommends the use of a full-duplex links, because it doesn't implement CSMA/CD. Using half-duplex links would still work, but at the cost of potential packet losses (especially when using a hub-ed shared medium).

Links
You can find more details on these pages: Introduction to switch technology (PDF) from Contemporary Control Systems, Inc. An Introduction to Auto-Negotiation from Bill Bunch, National Semiconductor.

y y

>>> NEXT: 10BASE -T FPGA interface part 2 - IP/UDP over Ethernet >>>

10BASE-T using MAC and PHY chips

Making a connection to an Ethernet network usually requires the use of a "MAC" and "PHY" chips (for "media access controller" and "physical-Layer Interface"). The MAC connects to the PHY using a standard "MII" bus (Medium Independent Interface), so different MACs and PHY can communicate together. The project on this site doesn't use a MAC/MII/PHY but try instead to provide the minimum MAC/PHY functionality required for Ethernet inside the FPGA. The MAC functionality is easy to emulate in an FPGA. The PHY provides many services that can be easily implemented in an FPGA (serialization/Manchester encoding...). It also provides some analog filtering ("wave shaping"), since the Ethernet specification calls for specific wave shapes on the output. See chapter 14.3 from the IEEE 802.3-200 standard. A transformer usually follows the PHY (for electrical isolation).

Links
y y
Example of PHY chip: LXT972A from Intel. Physically Realizable Filter from sci.electronics.design

10BASE-T FPGA interface part 2 - IP/UDP over Ethernet

Let's concentrate on Ethernet/IP/UDP packets. These packets are simple to produce; yet powerful, they can make their way on the Internet (and be sent anywhere in the world!). Here's an example: 55 55 55 55 55 55 55 D5 00 10 A4 7B EA 80 00 12 34 56 78 90 08 00 45 00 00 2E B3 FE 00 00 80 11 05 40 C0 A8 00 2C C0 A8 00 04 04 00 04 00 00 1A 2D E8 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 B3 31 88 1B Read on, it is decoded below.

Protocol stack
The packet uses three different protocols: Ethernet, IP and UDP (low to high level protocols). Each protocol adds its own functionality and is embedded into a lower level one.

y y y

The UDP part contains the data to be sent (the "payload"). The IP part allows the packet to be routed through the Internet. The Ethernet part allows the packet to be sent locally on an Ethernet network.

The UDP is embedded into the IP, which itself is embedded into the Ethernet. This is a good example on how network protocols are used together. The packet shown above is decoded here:

y y y y y y y y y y y y y y y

Ethernet preamble/SFD (synchronizer): 55 55 55 55 55 55 55 D5 Ethernet destination address: 00 10 A4 7B EA 80 Ethernet source address: 00 12 34 56 78 90 Ethernet type: 08 00 (=IP) IP header: 45 00 00 2E B3 FE 00 00 80 IP protocol: 11 (=UDP) IP checksum: 05 40 IP source (192.168.0.44): C0 A8 00 2C IP destination (192.168.0.4): C0 A8 00 04 UPD source port (1024): 04 00 UPD destination port (1024): 04 00 UDP payload length (18): 00 1A UPD checksum: 2D E8 UDP payload (18 bytes): 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 Ethernet checksum: B3 31 88 1B

You can notice the IPs used: from "192.168.0.44" to "192.168.0.4". These are local IPs, thispacket won't go very far...

Create your own packets

Here's a simple software that allows to create custom Ethernet/IP/UDP packets. Download it here. Source code is included (Delphi for now, if anyone translates it to C/C++, please send).

Every time you press the "Send!" button, the software builds a packet, displays it and sends it to the serial port (that will be useful later in part 3 of this project).

>>> NEXT: 10BASE -T FPGA interface part 3 - Sending packets >>>

10BASE-T FPGA interface part 3 - Sending packets

Now that we know what needs to be transmitted, let's do it. The software from part 2 sends raw Ethernet packet data to the serial port of the PC. Our FPGA board will just need to receive it from the serial port (slow...) and send it on the 10BASE-T wire pair (fast!). Having the PC calculate the raw packet data allows us to experiment very easily with all the packet parameters . That's fine, but ultimately the FPGA should work in standalone mode and cook/send the packets all by himself.

Manchester encoding
A 10BASE-T network works at 10Mbps (10 megabits per seconds). But 10BASE-T requires the bits to be "Manchester encoded". That requires doubling of the number of bits!

y y

A logical '0' is sent as a high bit followed by a low bit. A logical '1' is sent as a low bit followed by a high bit.

So our 10Mbps network actually requires a 20Mbps stream of bits on the wires...

FPGA clock
Simplicity would dictate that we use a 10MHz clock and we generate the 20Mbps Manchester bitstream by 'xoring' the clock with the output data bits. That may work. But we are gating the clock. That's not recommended in FPGA designs. In this particular ca se, that would degrade the 20Mbps signal quality because each bit transition would have glitches (the data output never exactly coincide with the clock). So let's use a 20MHz clock.

Keeping the link alive

Even if no packets are sent on a 10BASE-T cable, a pulse has to be sent periodically (called the "Normal Link Pulse" or "NLP"). It is used to keep the connection "alive". A pulse needs to be sent every 16ms or so. The NLP can also be replaced by a "Fast Link Pulse" (FLP) burst, during a process called " auto-negotiation". The FLP carries information about the capabilities of the sender, so that the hardware at both end of a cable can negotiate the link parameters, like the speed and the half/full duplex status.

HDL design
Let's assume the packet to be sent is available in a RAM in the FPGA.

ram512 ram( .data(ram_input), .wraddress(wraddress), .clock(clk), .q(ram_output), .rdaddress(rdaddress) );

We assume we also know the length of the packet. We are going to read the packet data and send it on the Ethernet. First we need a start signal.

wire StartSending; // pulse indicating when to start sending the packet reg SendingPacket; always @(posedge clk) if(StartSending) SendingPacket<=1; else if(DoneSending) SendingPacket<=0;

At 20MHz, we require 2 clock periods per bits. 16 clocks are required for an 8-bits byte.

reg [3:0] ShiftCount; // count from 0 to 15, as 16 clocks are required per 8 -bits bytes always @(posedge clk) if(SendingPacket) ShiftCount <= ShiftCount+1; else ShiftCount <= 0;

When we reach the last bit of a byte, we read a new byte from the RAM and put it into a shift-register. The shift register gives us a new bit every other clock.

wire readram = (ShiftCount==15); // time to read a new byte from the RAM? reg [7:0] ShiftData; always @(posedge clk) if(ShiftCount[0]) ShiftData <= readram ? ram_output : {1'b0, ShiftData[7:1]}; always @(posedge clk) if(readram) rdaddress <= SendingPacket ? rdaddress+1 : 0;

Each packet needs to end with a "TP_IDL" (a positive pulse of about 3 bit-times, followed by an idle period).

reg [2:0] idlecount; // enough bits to count 3 bit-times always @(posedge clk) if(SendingPacket) idlecount<=0; else if(~&idlecount) idlecount<=idlecount+1;

Finally, a Manchester encoder sends the bits, followed by the TP_IDL.

reg reg reg reg

qo; always @(posedge clk) qo <= SendingPacket ? ~ShiftData[0]^ShiftCount[0] : 1; qoe; always @(posedge clk) qoe <= SendingPacket | (idlecount<6); q1; always @(posedge clk) q1 <= (qoe ? qo : 1'b0); q2; always @(posedge clk) q2 <= (qoe ? ~qo : 1'b0);

The code shown here is a little bit simplified. For example, the NLP pulses required to keep the link alive are missing. The complete code can be found here. This code works with both hubs and switches. Since we used only NLP, the link is half-duplex and packet losses are possible when collisions occur. Switches show very few drops - since we transmit only here, collisions never happen unless another station sends broadcast packets (could be fixed by using FLP pulses to bring the link into full duplex). Hubs show high numbers of packet drops, due to the high probabilities of having collisions.

Incoming packets
The FPGA sends UDP packets. But how do you detect them? Here's a simple UDP tester software that can send and/or receive UDP packets on a PC (using the PC's Ethernet network adapter).

y y

The software listens to port 1024. If it receives a packet on this port, it displays how many bytes it got. The software can also send on port 1024. Just press the "Send UDP" button.

You can send packets to yourself - just use your machine own IP. But in that case packets are routed internally and never have a chance to go on the network, so that's not too useful.

To find a PC's IP or Ethernet MAC address, you can type "ipconfig /all" on the command-line. Note that the port value 1024 is hard-coded in the software (only the destination IP and payload length are configurable in the GUI). That's not a problem in practice as it is unlikely that your machine has another application already listening to this particular port.

>>> NEXT: 10BASE -T FPGA interface part 4 - Receiving packets >>>

10BASE-T FPGA interface part 4 - Receiving packets

The receiver can be used for 2 things:

y y

Create a legitimate port on the network. "Sniff" the network (spy on the packets) - just connect the receiver in parallel to another connection.

Here's an example of packet that I sniffed on my local network: 55 55 55 55 55 55 55 D5 00 C0 02 37 57 28 00 10 A4 7B EA 80 08 00 45 00 00 3C 02 24 00 00 80 01 B7 47 C0 A8 00 04 C0 A8 00 01 08 00 42 5C 02 00 09 00 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 7172 73 74 75 76 77 61 62 63 64 65 66 67 68 69 62 31 C5 4E I'll let you dissect it (ping from "192.168.0.4" to "192.168.0.1").

10BASE-T receiver
A 10BASE-T receiver consists of the following:

y y y

A differential receiver circuit (easy). A clock extraction circuit (the hard part). A preamble synchronizer, de-serializer and Ethernet checksum checker (easily done in the FPGA).

Differential input
We receive a differential (2 wires) signal from RD+/RD-. The signal is usually coupled magnetically (using a little transformer), and then converted to a common -mode signal (1 wire plus ground) using an integrated comparator or a couple of transistors. I didn't have a transformer on hands, nor a fast enough integrated comparator. So I used a capacitive coupling scheme followed by transistors. The schematic of my circuit is:

The 2K resistor on the collector of the second transistor is higher than the value on the first transistor (1K) to help getting a 50% duty cycle ratio signal on the output. Otherwise, the signal at the output is not square... About the capacitive coupling: I believe that it works as well as inductive coupling but has one drawback: when you insert the cable to the receiver, the voltage potential difference between the receiver and the driver might send a current pulse into the receiver (if the driver is not isolated himself by an transformer). Just my idea, I haven't found any relevant information anywhere. Anybody has more info?

Clock extraction
The data in common-mode is still Manchester encoded. The Manchester encoding scheme works in such a way that a transition is always created in the middle of a logical bit. Remember that:

y y

A logical '0' is sent as a high (50ns) followed by a low (50ns) (failing edge). A logical '1' is sent as a low (50ns) followed by a high (50ns) (rising edge).

That means that a transition may also appear in between 2 bits (if the same logical bit is sent twice consecutively). I know of three basic ways to do the clock extraction:

y y y

Oversample the encoded signal using a much faster clock, and extract the bits using regular FPGA logic (edge detector plus state machine). Use a PLL with a modified phase-comparator circuit to re-generate the clock used at the transmitter. Use a fixed delay non-retriggerable monostable whose duration is 1.5 encoded bit (75ns for 10BASE-T). The monostable is triggered by the middle-bit transitions and ignores the bit-spacing transitions.

I plan to try all three techniques. For now, let's try the first one.

Oversampling the signal

That's the "brute force" method. The advantage is that the complete decoding is done in the FPGA. The inconvenient is that you need a high frequency clock.

Bits extraction
I decided to use a 48MHz sampling frequency. Doing the Manchester decoding takes 3 steps. 1. 2. Sample and synchronize the data coming in. Detect the edges and start a counter. The trick is that the counter is made so that it ignores any subsequent edge until it rolls-over (to detect only Manchester middle-bit transitions).

3.

Once an edge is detected, the next bit is available 3 counts away (at 48MHz, the period is about 21ns, so three counts are 63ns, right in the middle of the next bit). We move each bit into an 8 -bits shift register.

reg [2:0] in_data; always @(posedge clk48) in_data <= {in_data[1:0], manchester_data_in}; reg [1:0] cnt; always @(posedge clk48) if(|cnt || (in_data[2] ^ in_data[1])) cnt<=cnt+1; reg [7:0] data; reg new_bit_avail; always @(posedge clk48) new_bit_avail <= (cnt==3); always @(posedge clk48) if(cnt==3) data<={in_data[1],data[7:1]};

The bits are coming in!

Preamble/SFD synchronization
So far, we just have bits synchronization (we know when each bit is coming, and its value). We know that a byte is starting every 8 bits, but starting at which bit? To allow byte synchronization, the Ethernet frame starts with this 8 bytes sequence: 55 55 55 55 55 55 55 D5 In binary, 0x55 is 01010101, while 0xD5 is 11010101. Also Ethernet specifies that the LSB is sent first (for example 0xD5 is sent as 1, 0, 1, 0, 1, 0, 1, 1). So we receive an alternate pattern of 1's and 0's, and as soon as we detect 2 consecutives 1's, we know that the real data is coming next.

reg end_of_Ethernet_frame; reg [4:0] sync1; always @(posedge clk48) if(end_of_Ethernet_frame) sync1 <= 0; else if(new_bit_avail) begin if(!(data==8'h55 || data==8'hAA)) // not preamble? sync1 <= 0; else if(~&sync1) // if all bits of this "sync1" counter are one, we decide that enough of the preamble // has been received, so stop counting and wait for "sync2" to detect the SFD sync1 <= sync1 + 1; // otherwise keep counting end reg [9:0] sync2; always @(posedge clk48) if(end_of_Ethernet_frame) sync2 <= 0; else if(new_bit_avail) begin if(|sync2) // if the SFD has already been detected (Ethernet data is coming in) sync2 <= sync2 + 1; // then count the bits coming in else if(&sync1 && data==8'hD5) // otherwise, let's wait for the SFD (0xD5) sync2 <= sync2 + 1; end

wire new_byte_available = new_bit_avail && (sync2[2:0]==3'h0) && (sync2[9:3]!=0);

Finally, Ethernet data is flowing in!

End of frame
If no clock transition is detected for some time, that's the end of the Ethernet frame.

reg [2:0] transition_timeout; always @(posedge clk48) if(in_data[2]^in_data[1]) // transition detected? transition_timeout <= 0; else if(~&cnt) transition_timeout <= transition_timeout + 1; always @(posedge clk48) end_of_Ethernet_frame <= &transition_timeout;

Wrapping it up
A standalone application would require checking the CRC (present at the end of the Ethernet packet) for bad transmission errors. Here, I just send the complete data to a PC - that displays it or does whatever it likes.

wire [7:0] q_fifo; fifo myfifo(.data(data), .wrreq(new_byte_available), .wrclk(clk48), .q(q_fifo), .rdreq(rdreq), .rdclk(clk), .rdempty(rdempty)); wire TxD_busy; wire TxD_start = ~TxD_busy & ~rdempty; assign rdreq = TxD_start; async_transmitter async_txd(.clk(clk), .TxD(TxD), .TxD_start(TxD_start), .TxD_busy(TxD_busy), .TxD_data(q_fifo));

The complete code is available here.

--- to be continued --- to be continued --- to be continued --- to be continued ---

Links
y
Ethernet Receiver using phase locked loop (PLL) clock recovery

=============================================================