8000 GitHub - EnesErcin/Ethernet_MAC: Cyclic Redundancy Check hardware module tested with Cocotb Test Bench
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Cyclic Redundancy Check hardware module tested with Cocotb Test Bench

Notifications You must be signed in to change notification settings

EnesErcin/Ethernet_MAC

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

63 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This repository is initated to present various methodologies to design a medium accsess control for the purpose of ethernet communication which are verified by cocotb testbenches.

It will eventually include various capabilities for different PHY chips and various reconsiliation layer such as MII,GMII and RGMII. The protocol of the ethernet is defined by IEEE although due to the fact that it is a general requirments it still leaves room for designers to make personal improvments as long as it suffice the desired outcomes of IEEE 802.3 etthernet standarts.

Frame check sequance is one aspect of the ethernet's mac layer which is open to improvment.IEEE defined error checking is 32-bit cyclic reducany check, which is provenly more reliable compared to other error detecting methodologies but this comes with a price of complication. Different algorithms for calculation of frame check sequance for hardware and software have been discussed on various forms and papers. Currently this repository have four different methods impemented on hardware.

Method Description Negatives Positives Resuorces Used Time Limitations
Table Driven (x1) List all new or modified files Needs a lot of space to store a table
Table Driven (x2) List all new or modified files Uses same table for every four bits more efficient.
Bit by bit (Comb) Checks the first bit
Bit by bit (Seq) Checks the first bit, after each bit itteration uses flip flop to save new crc Requires faster clock input than which the ethernet uses Less resources used

CRC is generated by both the tansmitter and reciver. Transmitter first established a crc by doing calculations over frame packets of destination address,source address, length, data packet and padding. When data has reached the destination same calulcations also has been made and lastly compared with recived crc from transmitter. If there is any mismatch than package is droped as it is most likly to be curropted. IEEE ethernet protocol says that in pg(57 Clause 1).

The bits of the incoming frame (exclusive of the FCS field itself) do not generate a CRC value **identical** to the one received, than frame is defined as invalid.

About

Cyclic Redundancy Check hardware module tested with Cocotb Test Bench

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published
0