基于FPGA的百兆以太网RGMII接口设计(读书笔记)

基于FPGA的百兆以太网RGMII接口设计(读书笔记),第1张

这篇文章的整体架构就是先介绍了百兆以太网的背景,百兆以太网又成为快速以太网。再介绍了用FPGA来实现的优点。接着介绍整体的方法和实验,具体介绍了各个模块的作用,并用视频传输作为测试工具,测试结果。

百兆以太网应用场景广,适用于突发通信和继续传送大型数据文件,互换 *** 作性好,具有广泛的软硬件支持。

FPGA是使用逻辑处理专用硬件,无需 *** 作系统,各条处理路径均是并发平行的,因此不同的 *** 作过程不会争夺相同的处理资源,意味着处理速度非常快。FPGA的芯片是Altera的Cyclone IV,PHY芯片是88E1111。

介绍了FPGA芯片EP4CE115F29C7N的功能,并列举了两个方案一是单物理芯片,二是物理层加MAC层继承与同一芯片。本文采用的是第一个方案,采用的芯片是88E1111,并采用的模式是RGMII模式。

系统的整体框架分为上行和下行两个通道,数据通过PHY芯片进入 FPGA,在FPGA中进行数据处理,再送出到PHY芯片传输出去。

preamble_complete模块对前导码进行处理。

4bits_to_8bits将4bits的数据拼接为8bits。

data_processing进行IP和MAC地址替换等 *** 作。

8bits_to_4bits模块将数据拆分成4bits送到PHY芯片输出。

要将88E1111设置为RGMII借口模式,从芯片手册中看到,HWCFG_MODE[3:0]决定了MAC层的接口模式,而HWCFG_MODE[3:0]的值由CONFIG[6:0]来进行映射,因此需要CONFIG4=011,CONFIG5=XX1。并将HWCFG_MODE[3:0]设置为1011,如图所示

说好了配置方法,然后再硬件电路实现

本文的时钟由外部晶振输入的50MHZ作为参考时钟,系统需要的时钟有

1、12.5MHZ以8bit为单位的数据的参考时钟

2、25MHZ以4bit为单位的数据的参考时钟

3、125MHZ时钟来处理数据

4、90°相移之后的25MZH作为参考时钟去产生输出参考时钟CTX_CLK。

这四个时钟都由PLL产生

这是收发时序图。

这个模块主要解决的问题就是前导码的问题,

接收端遇到的问题,首先由于前同步码不是8的整数倍,在拼接成8位时,会产生错位。

如过前导码同步是5_55_55_55_55_55_55,接着是arp的目的地址为FF_FF_FF_FF_FF_FF。那么组成8位就是55_55_55_55_55_55_55_FD,就定位不到5D。

还有一个问题就是在实际观察中,前同步码会有半个周期的0xF。

解决的方法就是使用状态机

分为两个作用,对两组4bits的数据拼接成8bits。

对参考时钟进行转换,从25MHZ转换为12.5MHZ。

拼接部分的RTL图如图

对时钟进行转换只需要通过异步FIFO,以25MHZ写入拼接后的数据,以12.5MHZ读出拼接数据即可。

这模块是核心模块,实现PORT,IP和MAC地址的过滤。使用的时钟是125MHZ,这样的处理速度更快,遇到的问题就是如何将12.5MHZ的时钟转换为125MZH,再将处理完后的时钟转换为12.5MHZ输出数据。

有三个难点:

1、数据长度的不确定性

2、相邻两个数据包间隔不确定性

3、如何保证转换后数据网络的有效性,即使data信号和DV信号的时序关系

这里采用两级FIFO解决,第一个FIFO用来存储数据,同时记录数据长度,将写完后的数据长度写入第二个FIFO,当第二个FIFO非空时,读出数据的长度,这样就做到了data和DV信号的同步。同理需要讲125MHZ转换为12.5MHZ时,再使用上述模块。

需要将8bits拆分为4bits,输出的参考时钟为25MHZ再进行相移。采用DDIO IP核来实现。该IP核如图

如图输入datain_h为1,输入datain_l为0,输出的信号就是参考时钟相移了90°。

前导符(7个8'h55的字节)+开始位(1个8'hD5字节)+目的mac地址(6个字节)+源mac地址(6个字节)+类型/长度(2个字节)+数据+padding(optional)+32bitCRC;

你按照上面的顺序把这些数据按照RGMII接口时序发送出去就应该可以看到,反正我最近是这么构造了跟软件发送的,能收到。

电磁波在双绞线上传输的速度为0.7倍光速,在1km电缆的传播时延约为5us。传统的网络信道比较差,需要有重传机制保障可靠性。于是,在节点A向节点B发送数据进行通信的时候,要保证以太网的重传,必须保证A收到碰撞信号的时候,数据包没有传完,要实现这一要求,A和B之间的距离很关键,也就是说信号在A和B之间传输的来回时间必须控制在一定范围之内。IEEE定义了这个标准,一个碰撞域内,最远的两台机器之间的round-trip time 要小于512bit 时间。(来回时间小于512位时,所谓位时就是传输一个比特需要的时间)。因此,传统以太网有如下特点:

1、最大覆盖距离(两个站点最远的距离):2500m;

2、争用期(即一个信号最远来回的传播时间):51.2us;过来这个时间还未监听到冲突,则说明无冲突;

3、最小帧长:64字节;因为传统以太网速率是10Mbps,争用期是51.2us;即在这个时间内,帧的数据不能发完,否则将不能监听到冲突了(CSMA/CD协议是边发边听、不发不听;因为如果帧发完,则不在监听,这个时候即使来了有冲突的信号,不在监听,也不知道已经冲突了),这样的话CSMA/CD协议可靠性也就大大折扣了;即:B/10M >= 51.2us即512bit,64个字节;

4、帧间最小间隔:9.6us;相当于发送96bit;即在CSDM/CD协议下,一个站点在监测到信道空闲后,需要等待9.6us才能发送数据;(主要目的是留给刚刚接收数据的站点清理接收缓存,做好接下一阵的准备----------流量控制其实也是)

上述所说的以太网帧是针对以太网Ⅱ型帧进行的描述。帧格式如下:

那么,现在互联网中发送长度小于64字节的报文时如何传送呢?比如ARP报文。有效长度如下:

ARP报文:4字节+4字节+6字节+4字节+6字节+4字节=28字节,远不够64字节。

事实上,在传送ARP报文时,需要进行填充。

arp程序代码里,会增加一个填充程序,填充字段 18字节, 这样以太网数据部分=ARP28字节+填充18字节=46字节。这样,Dmac 6字节+S mac 6字节+ type 2字节+ARP 46字节+FCS4字节=64字节。

从而保证了互联网上可以有效的传输小于64字节的报文。上述内容来源于网络,如有侵权,请联系我删除。网上有很多很多讨论为什么以太网帧最短帧为64字节的文章,大家可以自行百度。

我们关注的问题是,如果不填充,而是强行传送小于64字节的报文呢?我们搭建了一个上板实验进行了验证。

实验环境

开发板:Zedboard。

网络:双绞线接Zedboard四端口扩展板1口和3口并形成回环。

EDA工具:Vivado2018.2、ModelSim10.5。

真实硬件验证环境如下图(请忽略图中纸箱子等杂物):

回环结构

实验目的:为了验证,在实际链路中短于64字节的mac数据帧能否通过双绞线在phy层之间传输,以及mac核对于长度不符合要求的数据帧的处理情况。

事实上,在上图中,最短帧能否通过MAC1对应的RJ45网口发出来的前提是能否顺利的通过PHY芯片,FPGA芯片、PHY芯片以及RJ45接口的关系图如下:

PHY与FPGA之间的接口为RGMII接口。在FPGA内部构建的长度小于64字节的以太网帧,通过FPGA芯片与PHY芯片之间的RGMII接口首先发给PHY芯片,如果能够顺利的通过PHY芯片,才能从RJ45接口(MAC1)通过双绞线发送给MAC2的RJ45接口,进而再经过MAC2对应的RJ45接口、PHY芯片,最后送回到FPGA芯片内部。如下图所示,左侧MAC1采用自己写的超短帧产生和接收模块,右侧MAC2采用Opencores上的开源MAC核。

数据流

Step1:通过data_gen模块循环发送定长数据32’h12_34_56_78,通过8位数据端口传给ephy_source模块。

Step2:ephy_source模块根据接收的数据,以及长度进行mac帧封装,并填写固定目的mac地址:48’h01_01_01_01_01_01以及源mac地址:48’h08_08_08_08_08_08之后依次按单字节发送数据域内数据,并进行crc计算。

Step3:通过rgmii接口模块进行8位gmii接口数据到4位rgmii接口数据的转换后接到phy层。

Step4:经双绞线传输后来到另一端的phy层,并依次经过phy层、rgmii转换送入mac处理。

Step5:mac接收的数据,在去掉前导码、crc校验后,以32位宽的形式将数据部分发送给用户侧,这里直接将数据通过回环发送到mac2的用户发送数据端口,再次通过mac2的组帧、crc计算、8位gmii到4位rgmii的转换之后通过phy2的tx发送回phy1的接收端口。

超短帧长度设置为40字节。从MAC1发出,经过PHY1芯片,经过双绞线和MAC2的PHY2芯片,可以在MAC2的RGMII接口处收到。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/7845202.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-10
下一篇 2023-04-10

发表评论

登录后才能评论

评论列表(0条)

保存