转----FPGA做MAC功能,直接挂PHY芯片发送网络报文

  最近花了一周时间调试这个功能,因为网上找的很多文章,包括MAC层协议说明与FPGA做CRC32算法的研究等,有些地方描述的不一致,导致调试的过程中走了很多弯路,特地把最近收集的以及自己思考的成果记录下来,如果有什么地方不对的,希望看到的人能指点一下。

一、FPGA做MAC首先就是与PHY的接口问题,常用的百兆接口有MII和RMII,传输速率一样,不过MII是4bit传输,时钟25M,而RMII是2bit传输,时钟是50M,这两种接口每秒钟传输的数据量一样,具体区别就不做介绍了。

        我用的是MII接口,看PHY的芯片手册观察,操作大概就是25M的txc的下降沿,把使能en和数据txd赋值,上升沿的时候PHY芯片会锁存这些值并做处理。


二、其次FPGA做MAC与PHY通信上之后,需要遵循一定的协议,才能借助于PHY把想要发送的数据通过报文方式发送出去,这种协议就是MAC协议,也叫IEEE 802.3

        a、引导码和定界字符,PHY在捕捉到7个字节101010....相间的二进制后,再捕捉一个字节的10101011,PHY就判断后面的数据就是6个字节的目标MAC,6个字节的源MAC,2个字节的报文类型等等。MAC层要求定界字符之后的内容要在64字节到1518个字节之间,其中包括14自己的目标和源MAC,4字节的CRC32值。并且报文帧之间的传递间隔要大于9.6us。

大概了解了MAC协议之后,就要知道这些引导码等如何实用到MII接口的4bit传输。拿最后的定界字符1010,1011来说,现发送1010,后发送1011,依次对应txd的关系是txd[0],txd[1],txd[2],txd[3],也就现发送txd[3:0]=0101=4'h5,后发送txd[3:0]=1101=4'hD,引导码同样推理出4'h5,7个字节及14个4'h5,加一个定界符4'h5,4'hD。

        b、上传了一篇经过我注释的关于FPGA并行4bit计算CRC32的公式推导过程的文档:http://wenku.baidu.com/view/bba215c7a0116c175f0e48c7.html

        概念:CRC32也就是循环沉余校验,说白了就是一串数据除以一个G(X)=0X04C11DB7所得到的余数就是CRC32了,因为一串数据长度不确定,数据量非常大,系统不可能像其他取余计算那样直接x%y的方式,这就衍生了好多算法,比如查表法等。

        用法:人们把CRC32(余数)加到串数据后面4个字节,这样接收端接收到的数据就变成了原来的一串数据左移4个字节加上余数,把接收到的数据除以G(X)的话,余数就肯定为0了,如果传输过程中数据有损坏等,那么接收到的数据除以G(X),余数就不等于0了,这样就能最快的判断传输的一长串数据有没有错误。

并行算法的推导过程我就不详细说明了,我提供的文档说明的已经很详细,需要讲的就是计算出来的CRC32值怎么传输,并行算法计算出来的CRC32按文档说的方式加到数据帧后面,把包括CRC32的数据帧带入算法计算能得出魔数0XC704DD7B,说明CRC32的计算结果已经正确了。

        问题:把正确的CRC32值加到数据帧后面,还是发送不出去?Wireshark软件还是抓不到FPGA发送出来的网口数据?不知道是不是很多人会遇到这个问题,总之我是遇到了,而且折磨我又调试了好长时间,不断的怀疑自己,是不是文档介绍的算法不行,还是什么原因,通过各个途径都没有找到原因,请教了高手是校验值发送次序的问题,晚上研究了一下,发现CRC32并行算法推导过程中d3, d2, d1, d0 为读入的数据顺序,对应关系为datain(txd),时候可以得出魔数,对应关系换成datain({txd[0],txd[1],txd[2],txd[3]}),得出的CRC32按位取反结果才是要发送到PHY的FCS,这一点让我很奇怪,但又找不到原因,如果有人了解的更深一点,希望能指点一下。这里得出的CRC32取反后值如何4bit方式发送出去呢,其实和前面的引导码一样发送,例如CRC32[31:28]=4'hE=4'b1110,取反等于4'b0001,其中txd[3]=1'b1,txd[2:0]=3'b000,即得出txd=4'h1000=4'h8,依此类推。
        关于按照文档推导的并行计算出来的CRC32结果,为什么不是直接充当MAC层的FCS值,我没有找到任何理论依据,公式推导的文档中也没有提,如果有人对此有过研究的可以联系我,希望能让我请教一下。工作邮箱:[email protected]

你可能感兴趣的:(FPGA)