fcs Project

Introduction

FCS

This project and the nomenclature used within are based on IEEE standard 802.3-2008 clause 3.

IEEE standard 802 documents were obtained via the IEEE Get Program.

Use Cases

Supported Use Cases

• Reference implementation of IEEE 802.3 FCS functions for various datapath widths
• Validation of FCS functions
• Demonstration of FCS for a 512-bit datapath with varying packet lengths

Unsupported Use Cases

• Invalid data between start of frame (SOF) and end of frame (EOF) indications

FCS Calculation

The FCS calculation proceeds by first calculating the FCS intermediate value using an LFSR then bit-reversing the result to get the final value.

FCS LFSR

The FCS intermediate value calculation is shown below implemented in a linear feedback shift register (LFSR).

The value is accumulated in the R[31:0] registers from data fed LSB-first into the LFSR.

This LSB-first protocol matches the requirement of 802.3 clause 3 for how non-FCS bits are placed on the wire.

FCS Bit-Reverse

The accumulated R[31:0] value is inverted according to the algorithm in 802.3 clause 3.2.9 and bit-reversed per byte to support transmission of bit 31 first.

FCS Functions

FCS Functions implemented as part of this project cover datapath widths of 1, 8, 16, 32, 64, 128, 256 and 512 bits. The 1-bit function may be useful only for demonstration purposes, but the other functions could be useful in real applications.

FCS Residue

The residue for this FCS implementation is 0xC704DD7B.

Test Benches

Test benches implemented as part of this project are used to validate FCS functions, individually or in groups.

SystemC

The test benches use the Accellera implementation of the SystemC classes to provide a simulation kernel and the basis of the driver, checker and utility classes within test benches.

The path to the SystemC installation is set in the makefiles using the make variable SYSC_DIR.

Verilator

The verilog units under test (UUTs) are compiled into SystemC classes using Verilator.

The verilator environment is wrapped around the verilator executable using the "env-veripool" wrapper script such that the command

env-veripool verilator --version

returns the verilator version and

env-veripool

returns a listing of the verilator environment.

The paths to the Verilator and SystemC installation directories are set in the script using the variables VERIPOOL_DIR and SYSTEMC_DIR, respectively.

Test Benches

The test benches drive a verilog unit under test and verify that the UUT outputs are correct.

The verified outputs are FCS (the FCS value calculated over destination address, source address, length/type, MAC client data and pad) and residue (the FCS value calculated over the entire frame, including FCS).

The test bench name indicates the width in bits of the implemented datapath.

Test Bench List

• tb_1
• tb_8
• tb_16
• tb_32
• tb_512

Test Bench tb_1

Demonstrates serialization of 8-bit data into a 1-bit FCS function.

Test Bench tb_512

Demonstrates how bytes from a wide datapath are fed into a series of FCS functions to obtain a final FCS. The core of the UUT FCS implementation is shown in the block diagram below. Note that it is implemented as a pipeline where all registers have a common clock.

Frames are delimited by SOF and EOF. Datapath modulo is indicated by mod[5:0]. When mod[5:0] is zero, all 64 bytes of dat[511:0] are valid. Other mod[5:0] values directly indicate the number of valid bytes in dat[511:0]. For arriving data, valid bytes are always in the MSBs. Note that the datapath maintains this by shifting valid bytes to the MSB in the later pipeline stages.

In the input and first stages, the EOF and mod[5:0] values are modified to remove the FCS from the incoming frame. In subsequent stages, data is applied to the inputs of the individual FCS blocks based on the value of mod at that stage.

Verilog Files

Verilog File List

• FCS functions
  • fcs32_1.v
  • fcs32_8.v
  • fcs32_16.v
  • fcs32_32.v
  • fcs32_64.v
  • fcs32_128.v
  • fcs32_256.v
  • fcs32_512.v
  • fcs32_brev.v
• UUT implementations
  • uut_1_top.v
  • uut_1_bytep.v
  • uut_1_bitp.v
  • uut_8_top.v
  • uut_16_top.v
  • uut_32_top.
  • uut_512_top.

Verilog Files and Doxygen

Note that verilog file documentation consists only of per-file documentation written by hand and variable listings generated by doxygen.

The Doxygen platform may be modified to support Verilog by patching the Doxygen source or by specifying a filter script specifically for Verilog files. Searches for "doxygen verilog" point to resources for doing this.

Dependencies

Validated Environments

Linux	libc	gcc	SystemC	Verilator	make	bash	Python	Scapy
Debian 3.2.0-4-amd64	2.13	4.7.2	2.3.0	3.847	3.81	4.2.37	2.7.3	2.2.0

Other Dependencies

Dependencies beyond those listed above under the Validated Environments heading are the projects

• SyscMake
• SyscMsg
• SyscJson
• SyscDrv
• SyscClk
• SyscFCBus

Installation

1. Make sure you have installed the components shown in the "Validated Environments" section
   • Install SystemC from source, since it is unlikely to be packaged
   • Install Verilator from source to get the latest version
2. Clone repos listed in "Other Dependencies"
   • Clone such that fcs and the Sysc* repos are in the same directory
3. Modify the path to the SystemC installation, SYSC_DIR, in SyscMake/vars.mk
4. Modify the path to the SystemC and Veripool installations, SYSTEMC_DIR and VERIPOOL_DIR respectively, in SyscMake/env-veripool
5. execute "make" for a list of available targets

Licenses

License for Code

The code in this (fcs) project is licensed under the GPLv3

License for This Project Summary

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.