Ten GbE

From Casper

(Redirected from 10GbE)
Jump to: navigation, search

Block: 10GbE Transceiver (ten_GbE)
Block Author: Pierre Yves Droz
Document Author: Jason Manley



This block sends and receives UDP frames (packets). It accepts a 64 bit wide data stream with user-determined frame breaks. The data stream is wrapped in a UDP frame for transmission. Incoming UDP p ackets are unwrapped and the data presented as a 64 bit wide stream. Only tested for the BEE2 platform.

Mask Parameters

Parameter Variable Description
Port port Selects the physical CX4 port on the iBOB or BEE2. The iBOB has two ports; the BEE2 has two for the control FPGA and four for each of the user FPGAs. CORR is not used by CASPER.
Use lightweight MAC mac_lite Toggles the use of a lightweight MAC implementation, which does not perform checksum validation.
Pre-emphasis pre_emph Selects the pre-emaphasis to use over the physical link. Default: 3 (see Xilinx documentation)
Differential Swing swing Selects the size of the differential swing to use in mV. Default: 800 (see Xilinx documentation)


Port Dir Data Type Description
rst in boolean Resets the transceiver when pulsed high
tx_data in UFix_64_0 Accepts the data stream to be transmitted
tx_valid in boolean The core accept the data on tx_data into the buffer while this line is high
tx_dest_ip in UFix_32_0 Selects the IP address of the receiving device
tx_dest_port in UFix_16_0 Selects the listening port of the receiving device (UDP port)
tx_end_of_frame in boolean Signals the transceiver to begin transmitting the buffered frame (ie signals end of the frame). tx_valid must also be high to send a packet.
tx_discard in boolean Dumps the buffered packet and empties the FIFO buffer
rx_ack in boolean Used to acknowledge reception of the data currently on rx_data and signals the transceiver to produce the next 64 bits from the receiver FIFO.
led_up out boolean Indicates a link on the port
led_rx out boolean Represents received traffic on the port
led_tx out boolean Represents transmitted traffic on the port
tx_ack out boolean Indicates that the data just clocked-in was accepted (will not acknowledge when buffer is full).
rx_data out UFix_64_0 Outputs the received data stream.
rx_valid out boolean Indicates that the data on rx_data is valid (indicates a packet, or partial packet is in the RX buffer).
rx_source_ip out UFix_32_0 Represents the IP address of the sender of the current packet.
rx_source_port out UFix_16_0 Represents the sender's UDP port of the current packet.
rx_end_of_frame out boolean Goes high to indicate the end of the received frame.
rx_size out UFix_16_0 Represents the total size of the packet currently in the RX buffer


This document is a draft and requires verification.


The transceiver is configured through BORPH. Each transceiver instance has an entry in BORPH's /proc filesystem. A simple way to modify configuration is to generate a text file and cat the contents into the ten_GbE block's /proc entry. The text file's contents should be as follows:

mac = 10:10:10:10:10:10
ip =
gateway =
port = 50000

To load this new configuration file:

cat /path/to/setup_ten_GbE.txt > /proc/PID/hw/ioreg/ten_GbE

Note that ioreg_mode must be in mode 1 for this to work.

Alternatively, the 10.1 toolflow includes the option to configure the core automatically. In the "Show Implementation Parameters" section, there are added options to "Enable fabric on startup". This allows you to set the core's MAC address, IP address, Gateway address and fabric port. When sending to any IP, the MAC address used is the broadcast address (unless you manually populate the ARP table with the correct MAC address. Not yet supported.)


To transmit, data is clocked into a TX buffer through tx_data in 64 bit wide words using tx_valid. When ready to transmit, pulse the tx_end_of_frame line; the transceiver will add a UDP wrapper addressed to tx_dest_ip:tx_dest_port and begin transmission immediately. The tx_end_of_frame line must be brought high simultaneously with the last valid data word to be transmitted. Ie the tx_valid and tx_end_of_frame lines must be pulsed together to effect an end-of-frame.

If you do not wish to send the packet (and discard the data already clocked in), pulse tx_discard instead of tx_end_of_frame. The tx_dest_ip and tx_dest_port lines are ignored until a valid tx_end_of_frame is received. The sending port field in the UDP packet contains the listen port address (see below for configuration). Bear in mind that if the board is running at much over 120MHz, you cannot clock data into the core on every clock cycle (maximum transmission rate is 10Gbps and there is additional UDP packetization and ARP overhead). Maximum packet size appears to be in the order of 1100 words (of 64 bits each).


Upon receipt of a packet, rx_valid will go high and rx_size will indicate the length of the packet in 64 bit words. The received data is presented on rx_data in 64 bit wide words. You acknowledge receipt of this data using rx_ack, at which point the next data word will be presented. When the end of the packet is reached, rx_end_of_frame will go high.


To transmit, the IPv4 address is represented as a 32 bit binary number (whereas it's usually represented as four 8 bit decimal numbers). For example, if you wanted to send all packets to, you would enter

192\times2^{24} + 168\times2^{16} + 1\times2^8 + 1 = 3 232 235 777

as the IP address. The port is represented by a 16 bit number, allowing full addressing of the UDP port range. Ports below 1024 are generally reserved for Linux kernel and Internet functions. Ports 1024 - 49151 are registered for specific applications and may not be used without IANA registration. To ensure inter-operability and compatibility, we recommend using dynamic (private) ports 49152 through 65535.

To receive, the MAC address, IP address and listen port of each transceiver can be configured through BORPH or TinySH. Transceivers may have different IP addresses and listen ports, however, it is only possible for any given transceiver to listen on one port at a time. This can be reconfigured while running.

LED Outputs

The LED lines indicate port activity and can be connected to external GPIO LED interfaces. Bear in mind that even if no packets are being transmitted or received through the Simulink interface block, miscellaneous configuration packets are still sent and may be received by the microprocessor core. This activity will also be reflected on the activity LEDs.


Apart from configuring the block, the processor is also used to map the routing tables. ARP requests and responses are handled by the microprocessor. All packets to the block's IP address that are not on the configured port are redirected to the processor running TinySH for management.

Personal tools