转----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值，我没有找到任何理论依据，公式推导的文档中也没有提，如果有人对此有过研究的可以联系我，希望能让我请教一下。工作邮箱：[e-mail]