前言
上文介绍的MAC_RX模块实现了接受字节对齐的功能,但是尾端存在4字节CRC校验未处理。
一、并行CRC处理
前面在千兆以太网里对CRC代码和使用进行了介绍,千兆里面数据是一个一个byte进来的,但是在万兆里面数据一次性进来8byte,所以需要修改CRC模块使其进行并行处理,一次性计算8个byte的CRC结果。
注意一下几点:
- CRC数据需要单独提取,因为CRC是从目的MAC就开始进行校验,其过程与恢复AXIS_data一致,充分理解上文内容即可。
- 解析接收到的CRC结果,与我们计算出来的进行比对,得出CRC_ERROR结果
- 最后一拍进入CRC计算模块的数据需要增加一个keep掩码信号,原来指示这拍数据当中需要几个数据参与校验
这部分代码极其繁琐,具体参考:https://github.com/shun6-6/Ten_gig_eth_design 当中的 CRC32_64bKEEP文件
module CRC32_64bKEEP(
input i_clk ,
input i_rst ,
input i_en ,
input [7 :0] i_data ,
input [7 :0] i_data_1 ,
input [7 :0] i_data_2 ,
input [7 :0] i_data_3 ,
input [7 :0] i_data_4 ,
input [7 :0] i_data_5 ,
input [7 :0] i_data_6 ,
input [7 :0] i_data_7 ,
output [31:0] o_crc_8 ,//8个byte全部参与校验的结果
output [31:0] o_crc_1 ,//1个byte全部参与校验的结果
output [31:0] o_crc_2 ,//2个byte全部参与校验的结果
output [31:0] o_crc_3 ,//3个byte全部参与校验的结果
output [31:0] o_crc_4 ,//4个byte全部参与校验的结果
output [31:0] o_crc_5 ,//5个byte全部参与校验的结果
output [31:0] o_crc_6 ,//6个byte全部参与校验的结果
output [31:0] o_crc_7 //7个byte全部参与校验的结果
);
o_crc_8表示当前输入的8byte数据全部需要参与CRC校验,也就是说crc_keep为8‘b1111_1111,o_crc_1则表示只有第一个byte参与CRC,也就是说crc_keep为8‘b1000_0000。
通过http://www.ip33.com/crc.html在线计算CRC来验证模块是否正确校验。
第一个8byte数据为ff ff ff ff ff ff 01 02 03
- 全部有效的时候,查看o_crc_8波形可以看出校验结果为68779D8E,与网站计算一致;
- 若只有7个byte有效,结果如下图所示为A54406F6,在波形里查看o_crc_7,结果一致。
二、添加CRC处理的MAC_RX模块
添加CRC处理之后这部分代码整体可以分为俩部分,第一部分为上文当中的AXIS恢复过程,只不过在此基础上又去除了尾端4字节的CRC;第二部分则是仿照AXIS恢复的过程,将参与CRC校验的字段r_crc_data提取出来,以及r_crc_keep、r_crc_end、r_crc_en等信息,其实就是分别对应AXIS当中的data、keep、last以及valid,所以这俩部分极度相似。
俩者波形样子也差不多一致,粉色波形为CRC相关信号,上面绿色为AXIS相关信号。