Closed Jzone315 closed 6 years ago
I'm not sure exactly what you're doing with your code, but it is absolutely possible to use this lfsr code for an Ethernet MAC. Here is a 64 bit 10G MAC that uses this code to generate the FCS: https://github.com/alexforencich/verilog-ethernet/blob/master/rtl/eth_mac_10g_tx.v . Note that it uses the bare lfsr module, not the lfsr_crc module. Management of the actual CRC computation is done within the MAC, it's not really possible to use the lfsr_crc module for this application (the wrapper modules in this repo are mainly intended as a examples for how to use the core lfsr module). This is very important as the MAC module actually has 5 instances of the CRC module, one each for 8, 16, 24, 32, and 64 bits of input data. The 64 bit one is used for most of the frame while the smaller widths are required to 'finish' the CRC in a single clock cycle at the end of the frame. There is also an optimization in that module to re-use the 8, 16, and 24 width instances for 40, 48,and 56 bits by feeding the 32 bit output back around. For a 32 bit interface, you'll probably need 4 instances, one each for 8, 16, 24, and 32 bits. I actually have an adaptation of that MAC module for 32 bits, but it's not in the repo right now. I'll get that cleaned up and committed soon if I have some free time.
Oops, the TX has instances for all 8 width settings (8, 16, 24, 32, 40, 48, 56, 64) while the RX has only 5 (8, 16, 24, 32, 64). Only the RX side has the feedback optimization to eliminate the 40, 48, and 56 bit lfsr modules. See https://github.com/alexforencich/verilog-ethernet/blob/master/rtl/eth_mac_10g_rx.v . The RX can get away with this optimization because it has to strip off the FCS which will 'bleed over' to the next cycle for the 40, 48, 56, and 64 bit cases. It may be possible to do something similar with a 32 bit interface and burn some of the IFG to save some logic resources.
Thanks a lot for your reply. The 10G ethernet has two modes :156.25Mhz 64-bits and 312.5Mhz 32-bits; i am using the second one , so i needed to modify the DATA_WIDTH to be 32-bits; for now i am only using the full byte mode, which means the tkeep will be x"F" with the tlast, so i thought just the 32-bits instance will work well, but i got the wrong result with the MAC core, i didn't know why, so I am looking for your help, i am still in the issue now, thanks very much.
Here is the core for a 32 bit XGMII MAC: https://github.com/alexforencich/verilog-ethernet/blob/master/rtl/axis_xgmii_rx_32.v , https://github.com/alexforencich/verilog-ethernet/blob/master/rtl/axis_xgmii_tx_32.v . Let me know how it works.
And here is the updated 10G MAC with selectable data width: https://github.com/alexforencich/verilog-ethernet/blob/master/rtl/eth_mac_10g.v
Thanks a lot , i have fixed my issue now by following the axis_xgmii_tx_32.v , you really do me a good favor , thanks very much again.
Good to hear!
Hi: First show my appreciates. I am trying to use the lfsr_crc in my 10G ethernet mac design with the DATA_WIDTH is 32-bits ,but when I simulated this I found the results is different from xilinx's MAC IPcore, i just modified the parameter DATA_WIDTH, so how could i use the lsfr_crc in 32-bits ethernet? Thanks again。