本帖最后由 正点原子运营 于 2024-1-2 17:02 编辑
第五十章 以太网ARP测试实验
1)实验平台:正点原子 ATK-DFPGL22G开发板
2) 章节摘自【正点原子】ATK-DFPGL22G之FPGA开发指南_V1.0
6)FPGA技术交流QQ群:435699340
在以太网中,一个主机和另一个主机进行通信,必须要知道目的主机的MAC地址(物理地址),而目的MAC地址的获取由ARP协议完成。本章我们来学习如何通过ATK-DFPGL22G开发板实现ARP协议的功能。 本章分为以下几个章节: 1.1 简介 1.2 实验任务 1.3 硬件设计 1.4 程序设计 1.5 下载验证
1.1 简介ARP概述 ARP(Address Resolution Protocol),即地址解析协议,是根据IP地址(逻辑地址)获取MAC地址的一种TCP/IP协议。在以太网通信中,数据是以“帧”的格式进行传输的,帧格式里面包含目的主机的MAC地址。源主机的应用程序知道目的主机的IP地址,却不知道目的主机的MAC地址。而目的主机的MAC地址直接被网卡接收和解析,当解析到目的MAC地址非本地MAC地址时,则直接丢弃该包数据,因此在通信前需要先获得目的的MAC地址,而ARP协议正是实现了此功能。 ARP协议的基本功能是通过目的设备的IP地址,查询目的设备的MAC地址,以保证通信的顺利进行。MAC地址在网络中表示网卡的ID,每个网卡都需要并有且仅有一个MAC地址。在获取到目的MAC地址之后,将目的MAC地址更新至ARP缓存表中,称为ARP映射,下次通信时,可以直接从ARP缓存表中获取,而不用重新通过ARP获取MAC地址。但一般ARP缓存表会有过期时间,过期后需要重新通过ARP协议进行获取。 ARP映射是指将IP地址和MAC地址映射起来,分为静态映射和动态映射。 静态映射指手动创建一张ARP表,把IP地址和MAC地址关联起来。手动绑定之后,源主机在通信之前,就可以直接从ARP表中直接找到IP地址对应的MAC地址,但这样做有一定的局限性,因为MAC地址可能会变化,比如: 1) 机器可能更换NIC(网络适配器),结果变成一个新的物理地址; 2) 在某些局域网中,每当计算机加电时,他的物理地址都要改变一次。 3) 移动电脑可以从一个物理网络转移到另一个物理网络,这样会改变物理地址。 要避免这些问题出现,必须定期维护更新ARP表,此类比较麻烦而且会影响网络性能。 动态映射指使用协议来获取相对应的物理地址,之所以用动态这个词是因为这个过程是自动完成的,一般应用程序的用户或系统管理员不必关心。已经设计出用于实现动态映射协议的有ARP和RARP(逆地址解析协议)两种,如下图所示。 ARP把IP地址映射为物理地址,RARP把物理地址映射为IP地址。RRAP是被那些没有磁盘驱动器的系统使用(一般是无盘工作站或 X终端),此类应用较少,本章不做讨论。 ARP协议分为ARP请求和ARP应答,源主机发起查询目的MAC地址的报文称为ARP请求,目的主机响应源主机并发送包含本地MAC地址的报文称为ARP应答。 当主机需要找出这个网络中的另一个主机的物理地址时,它就可以发送一个ARP请求报文,这个报文包含了发送方的MAC地址和IP地址以及接收方的IP地址。因为发送方不知道接收方的物理地址,所以这个查询分组会在网络层中进行广播,即ARP请求时发送的接收方物理地址为广播地址,用48’hff_ff_ff_ff_ff_ff表示。ARP请求的示意图如下图所示:
上图中的主机A发起ARP请求,由于发送的目的MAC地址为广播地址,所以此时局域网中的所有主机都会进行接收并处理这个ARP请求报文,然后进行验证,查看接收方的IP地址是不是自己的地址。是则返回ARP应答报文,不是则不响应。 只有验证成功的主机才会返回一个ARP应答报文,这个应答报文包含接收方的IP地址和物理地址。ARP应答的示意图如下图所示:
主机B利用收到的ARP请求报文中的请求方物理地址,以单播的方式直接发送给主机A,主机A将收到的ARP应答报文中的目的MAC地址解析出来,将目的MAC地址和目的IP地址更新至ARP缓存表中。当再次和主机A通信时,可以直接从ARP缓存表中获取,而不用重新发起ARP请求报文。需要说明的是,ARP缓存表中的表项有过期时间(一般为20分钟),过期之后,需要重新发起ARP请求以获取目的MAC地址。 ARP协议通过以太网进行传输,那么必须也要按照以太网所规定的格式进行传输,我们先来介绍下以太网的帧格式,随后再来向大家详细介绍ARP协议的具体格式。 以太网是目前应用最广泛的局域网通讯方式,同时也是一种协议。以太网协议定义了一系列软件和硬件标准,从而将不同的计算机设备连接在一起。我们知道串口通信单次只传输一个字节,而以太网通信是以数据包的形式传输,其单包数据量达到几十,甚至成百上千个字节。下图为以太网通过ARP传输单包数据的格式,从图中可以看出,以太网的数据包就是对协议的封装来实现数据的传输,即ARP数据位于以太网帧格式的数据段。这里只是让大家了解下以太网数据包的格式,后面会逐个展开来讲。
以太网MAC帧格式 以太网技术的正式标准是IEEE802.3,它规定了以太网传输数据的帧结构,我们可以把以太网MAC层理解成高速公路,我们必须遵循它的规则才能在上面通行,以太网MAC层帧格式如图 50.1.5所示。
以太网传输数据时按照上面的顺序从头到尾依次被发送和接收,我们下面进一步解释各个区域。 前导码(Preamble):为了实现底层数据的正确阐述,物理层使用7个字节同步码(0和1交替(55-55-55-55-55-55-55))实现数据的同步。 帧起始界定符(SFD,Start Frame Delimiter):使用1个字节的SFD(固定值为0xd5)来表示一帧的开始,即后面紧跟着传输的就是以太网的帧头。 目的MAC地址:即接收端物理MAC地址,占用6个字节。MAC地址从应用上可分为单播地址、组播地址和广播地址。单播地址:第一个字节的最低位为0,比如00-00-00-11-11-11,一般用于标志唯一的设备;组播地址:第一个字节的最低位为1,比如01-00-00-11-11-11,一般用于标志同属一组的多个设备;广播地址:所有48bit全为1,即FF-FF-FF-FF-FF-FF,它用于标志同一网段中的所有设备。 源MAC地址:即发送端物理MAC地址,占用6个字节。 长度/类型:上图中的长度/类型具有两个意义,当这两个字节的值小于1536(十六进制为0x0600)时,代表该以太网中数据段的长度;如果这两个字节的值大于1536,则表示该以太网中的数据属于哪个上层协议,例如0x0800代表IP协议(网际协议)、0x0806代表ARP协议(地址解析协议)等。 数据:以太网中的数据段长度最小46个字节,最大1500个字节。最大值1500称为以太网的最大传输单元(MTU,Maximum Transmission Unit),之所以限制最大传输单元是因为在多个计算机的数据帧排队等待传输时,如果某个数据帧太大的话,那么其它数据帧等待的时间就会加长,导致体验变差,这就像一个十字路口的红绿灯,你可以让绿灯持续亮一小时,但是等红灯的人一定不愿意的。另外还要考虑网络I/O控制器缓存区资源以及网络最大的承载能力等因素,因此最大传输单元是由各种综合因素决定的。为了避免增加额外的配置,通常以太网的有效数据字段小于1500个字节。 帧检验序列(FCS,Frame Check Sequence):为了确保数据的正确传输,在数据的尾部加入了4个字节的循环冗余校验码(CRC校验)来检测数据是否传输错误。CRC数据校验从以太网帧头开始即不包含前导码和帧起始界定符。通用的CRC标准有CRC-8、CRC-16、CRC-32、CRC-CCIT,其中在网络通信系统中应用最广泛的是CRC-32标准。 在这里还有一个要注意的地方就是以太网相邻两帧之间的时间间隔,即帧间隙(IFG,Interpacket Gap)。帧间隙的时间就是网络设备和组件在接收一帧之后,需要短暂的时间来恢复并为接收下一帧做准备的时间,IFG的最小值是96 bit time,即在媒介中发送96位原始数据所需要的时间,在不同媒介中IFG的最小值是不一样的。不管10M/100M/1000M的以太网,两帧之间最少要有96bit time,IFG的最少间隔时间计算方法如下: 10Mbit/s最小时间为:96*100ns = 9600ns; 100Mbit/s最小时间为:96*10ns = 960ns; 1000Mbit/s最小时间为:96*1ns = 96ns。 接下来我们介绍ARP协议以及它和以太网MAC层的关系。在介绍ARP协议之前,我们先了解下TCP(传输控制协议)/IP(网际协议)协议簇。TCP/IP是网络使用中最基本的通信协议,虽然从名字看上去TCP/IP包括两个协议,TCP和IP,但TCP/IP实际上是一组协议,它包括上百个各种功能的协议,如:TCP、IP、ARP、UDP等。而TCP协议和IP协议是保证数据完整传输的两个重要的协议,因此TCP/IP协议用来表示Internet协议簇。 TCP/IP协议不仅可以运行在以太网上,也可以运行在FDDI(光纤分布式数据接口)和WLAN(无线局域网)上。反过来,以太网的高层协议不仅可以是TCP/IP协议,也可以是IPX协议(互联网分组交换协议)等,只不过以太网+TCP/IP成为IT行业中应用最普遍的技术。下面我们来熟悉下ARP协议。
ARP协议 ARP协议属于TCP/IP协议簇的一种,从前面介绍的图 50.1.4可以看出,ARP协议位于以太网MAC帧格式的数据段,ARP数据包格式如下图所示。
硬件类型(Hardware type):硬件地址的类型,1表示以太网地址。 协议类型(Protocol type):要映射的协议地址类型,ARP协议的上层协议为IP协议,因此该协议类型为IP协议,其值为0x0800。 硬件地址长度(Hardwaresize):硬件地址(MAC地址)的长度,以字节为单位。对于以太网上IP地址的ARP请求或者应答来说,该值为6。 协议地址长度(Protocolsize):IP地址的长度,以字节为单位。对于以太网上IP地址的ARP请求或者应答来说,该值为4。 OP(Opcode):操作码,用于表示该数据包为ARP请求或者ARP应答。1表示ARP请求,2表示ARP应答。 源MAC地址:发送端的硬件地址。 源IP地址:发送端的协议(IP)地址,如192.168.1.102。 目的MAC地址:接收端的硬件地址,在ARP请求时由于不知道接收端MAC地址,因此该字段为广播地址,即48’hff_ff_ff_ff_ff_ff。 目的IP地址:接收端的协议(IP)地址,如192.168.1.10。 以太网的帧格式、ARP数据格式到这里已经全部介绍完了,关于通过以太网传输ARP报文的格式如下图所示:
由上图可知,28字节的ARP数据位于以太网帧格式的数据段。由于以太网数据段最少为46个字节,而ARP数据包总长度为28个字节,因此在ARP数据段后面需要填充18个字节的数据,以满足以太网传输格式的要求。这个填充的过程称为Padding(填充),填充的数据可以为任意值,但一般为0。
RGMII接口介绍 以太网的通信离不开物理层PHY芯片的支持,以太网MAC和PHY之间有一个接口,常用的接口有MII、RMII、GMII、RGMII等。 MII(Medium Independent Interface,媒体独立接口):MII支持10Mbps和100Mbps的操作,数据位宽为4位,在100Mbps传输速率下,时钟频率为25Mhz。 RMII(Reduced MII):RMII是MII的简化版,数据位宽为2位,在100Mbps传输速率下,时钟频率为50Mhz。 GMII(Gigabit MII):GMII接口向下兼容MII接口,支持10Mbps、100Mbps和1000Mbps的操作,数据位宽为8位,在1000Mbps传输速率下,时钟频率为125Mhz。 RGMII(Reduced GMII):RGMII是GMII的简化版,数据位宽为4位,在1000Mbps传输速率下,时钟频率为125Mhz,在时钟的上下沿同时采样数据。在100Mbps和10Mbps通信速率下,为单个时钟沿采样。 在千兆以太网中,常用的接口为RGMII和GMII接口。RGMII接口的优势是同时适用于10M/100M/1000Mbps通信速率,同时占用的引脚数较少。但RGMII接口也有其缺点,就是在PCB布线时需要尽可能对时钟、控制和数据线进行等长处理,且时序约束相对也更为严格。 为了节省引脚,ATK-DFPGL22G开发板板载的PHY芯片采用的接口为RGMII接口,下图是MAC侧与PHY侧接口的连接。
ETH_RXC:接收数据参考时钟,1000Mbps速率下,时钟频率为125MHz,时钟为上下沿同时采样;100Mbps速率下,时钟频率为25MHz;10Mbps速率下,时钟频率为2.5MHz,ETH_RXC由PHY侧提供。 ETH_RXCTL(ETH_RX_DV):接收数据控制信号。 ETH_RXD:四位并行的接收数据线。 ETH_TXC:发送参考时钟,1000Mbps速率下,时钟频率为125MHz,时钟为上下沿同时采样;100Mbps速率下,时钟频率为25MHz;10Mbps速率下,时钟频率为2.5MHz,ETH_TXC由MAC侧提供。 ETH_TXCTL(ETH_TXEN):发送数据控制信号。 ETH_TXD:四位并行的发送数据线。 ETH_RESET_N:芯片复位信号,低电平有效。 ETH_MDC:数据管理时钟(Management Data Clock),该引脚对ETH_MDIO信号提供了一个同步的时钟。 ETH_MDIO:数据输入/输出管理(Management Data Input/Output),该引脚提供了一个双向信号用于传递管理信息。 其中ETH_RXC、ETH_RXCTL和ETH_RXD为MAC接收侧引脚;ETH_TXC、ETH_TXCTL和ETH_TXD为MAC发送侧引脚;ETH_MDC和ETH_MDIO为MDIO接口引脚,用于配置PHY芯片内部寄存器;ETH_RST_N为PHY芯片硬件复位信号。由于PHY芯片的内部寄存器在默认配置下也可以正常工作,因此本次实验没有对MDIO接口进行读写操作,只用到了以太网的RGMII接口信号和复位信号。 RGMII使用4bit数据接口,在1000Mbps通信速率下,ETH_TXC和ETH_RXC的时钟频率为125Mhz,采用上下沿DDR(Double Data Rate)的方式在一个时钟周期内传输8位数据信号,即上升沿发送/接收低4位数据,下降沿发送/接收高4位数据。ETH_TXCTL和ETH_RXCTL控制信号同样采用DDR的方式在一个时钟周期内传输两位控制信号,即上升沿发送/接收数据使能(TX_EN/RX_DV)信号,下降沿发送/接收使能信号与错误信号的异或值(TX_ERR xor TX_EN、RX_ERR xor RX_DV)。当RX_DV为高电平(表示数据有效),RX_ERR为低电平(表示数据无错误),则异或的结果值为高电平,因此只有当ETH_RXCTL和ETH_TXCTL信号的上下沿同时为高电平时,发送和接收的数据有效且正确。 当RGMII工作在100Mbps时,ETH_TXC和ETH_RXC的时钟频率为25Mhz,采用上升沿SDR的方式在一个周期内传输4位数据。不过此时ETH_TXCTL和ETH_RXCTL控制信号仍采用上下沿DDR的传输方式。 当RGMII工作在10Mbps时,ETH_TXC和ETH_RXC的时钟频率为2.5Mhz,采用上升沿SDR的方式在一个周期内传输4位数据。ETH_TXCTL和ETH_RXCTL控制信号也采用SDR的传输方式。
RGMII接口时序 PHY芯片的RGMII接口时序,其时钟、控制信号和数据的对齐方式,一般由MDIO接口或者硬件上的特殊引脚进行配置。 RGMII接收端口时钟、控制信号和数据对齐的时序图如下:
由上图可知,RXC的上下边沿与RXD和RX_CTL信号对齐,相位相同。 RGMII接收端口时钟和控制/数据信号增加延时的时序图如下:
图 50.1.10 RGMII接收信号增加时钟延时 由上图可知,RXC的上下边沿与RXD和RX_CTL信号的中间位置对齐,RXC的时钟周期为8ns,单个高电平或者低电平为4ns,RXC相对于RXD和RX_CTL延时约2ns。 YT8511 RGMII接收端口的信号对齐模式由硬件上的特殊引脚外接上下拉电阻进行配置,如图 50.1.11所示。从下图中可以看出,当管脚LED_10_100接上拉电阻时,表示RXC时钟相对于RXD信号,会增加约2ns的延时。而ATK-DFPGL22G硬件原理图中YT8511的管脚LED_10_100连接的是上拉电阻,因此RXC和RXD之间会有约2ns的延时,RGMII接收端口的时序图如图 50.1.10所示。
RGMII发送端口正常模式时序图如下:
由上图可知,RGMII发送端口正常模式下,需要满足TXC的上下边沿与TXD和TX_CTL信号对齐,相位相同。YT8511在硬件上面没有做TX端的delay模式,可根据实际情况,选择是否在代码中进行延时(因为一般对端设备的接收端会有延时处理的功能,因此发送端也可以不延时),延时后的时序图如下所示:
由RGMII的接口时序可知,RGMII发送端口在TXC时钟的上升沿传输TXD的低4位和TX_CTL的使能信号;下降沿传输TXD的高4位和TX_CTL的错误信号(实际上是使能信号和错误信号的异或值);RGMII接收端口在RXC时钟的上升沿传输RXD的低4位和RX_CTL的使能信号;下降沿传输RXD的高4位和RX_CTL的错误信号(实际上是使能信号和错误信号的异或值)。
Pango原语 原语是Pango器件底层硬件中的功能模块,它使用专用的资源来实现一系列的功能。相比于IP核,原语的调用方法更简单,但是一般只用于实现一些简单的功能。本章主要用到了GTP_OUTBUFT、IDDR、ODDR。 GTP_OUTBUFT使用说明: 1) 功能介绍 GTP_OUTBUFT:是一个三态输出BUFFER,如下图所示:
2) 端口描述 表 50.1.1 GTP_OUTBUFT端口列表描述 3) 参数描述4) 实例模板 - GTP_OUTBUFT#(
- .IOSTANDARD ("DEFAULT"),
- .SLEW_RATE ("SLOW "),
- .DRIVE_STRENGTH (8)
- )
- GTP_OUTBUFT_inst (
- .I (i),
- .O (o),
- .T (t)
- );
- GTP_OSERDES
复制代码OutputDDR的主要功能是把来自Fabric的数据,从CLK_SYS转移到SERCLK时钟域,并转换成高速的串行数据流发送出去。每个Output DDR单元可支持输出速率转换2:1,4:1,7:1和8:1。 OutputDDR单元可通过参数OSERDES_MODE配置成不同的工作模式,这些工作模式包括:ODDR,OMDDR,OSER4,OMSER4,OSER7,OSER8和OMSER8。 PDS软件库为方便用户使用Output DDR单元提供了专用原语,用户可以在源代码(Verilog/VHDL)中例化GTP_OSERDES原型模块。以Verilog例化为例: - GTP_OSERDES#(
- .OSERDES_MODE (“ODDR” ),
- .WL_EXTEND (“FALSE”),
- .GRS_EN (“TRUE” ),
- .LRS_EN (“TRUE” ),
- .TSDDR_INIT (1'b0 )
- )u_OSERDES(
- .DO (DO ),
- .TQ (TQ ),
- .DI (DI ),
- .TI (TI ),
- .RCLK (RCLK ),
- .SERCLK (SERCLK ),
- .OCLK (OCLK ),
- .RST (RST )
- );
复制代码GTP_OSERDES的参数及信号说明如下: GTP_OSERDES通常跟GTP_OUTBUF,GTP_OUTBUFDS,GTP_OUTBUFCO,GTP_OUTBUFTCO,GTP_OUTBUFTDS和GTP_OUTBUFT一起使用。 下图以GTP_OUTBUFT为例,说明了GTP_OSERDES与之连接的关系,GTP_OUTBUFT的详细说明如图 50.1.14 所示。 图 50.1.15 GTP_OSERDES常用连接方法 在使用GTP_OSERDES时,分为有三态控制和没有三态控制两类模式。当没有三态控制时,GTP_OSERDES是不开放TI和TQ的。
下面分别介绍Output DDR不同的工作模式。 ODDR: 当Output DDR配置为ODDR模式时,其功能图可化简为下图。 ODDR时序图如下所示。 ODDR及OMDDR,OSER4,OMSER4,OSER8和OMSER8均有两种形态,一种为如上图所示的带三态控制TS_TO的输出,另一种为不带三态输出的输出,OSER7只有不带TS_TO的输出。 OMDDR: 当Output DDR配置为OMDDR模式时,其功能图可化简为下图。 图 50.1.18 OMDDR框图
跟ODDR相比,OMDDR多一次从CLK_SYS到OCLK的时钟域转换。时序图如下所示。OSER4: 当Output DDR配置为OSER4模式时,与GTP_OUTBUFT,GTP_OUTBUFTDS或GTP_OUTBUFTCO配合使用。其功能图可化简为下图。 OSER4时序图如下所示。 OMSER4: 当Output DDR配置为OMSER4模式时,其功能图可化简为下图。 跟OSER4相比,OMSER4增加了从SERCLK到OCLK的时钟域转换。OMSER4的时序图如下所示。 OSER7: 当Output DDR配置为OSER7模式时,与GTP_OUTBUF,GTP_OUTBUFDS或GTP_OUTBUFCO配合使用。其功能图可化简为下图。 OSER7时序图如下所示。 OSER8: 当Output DDR配置为OSER8模式时,使用方法与OSER4相同。其功能图可化简为下图。 OSER8时序图如下所示: OMSER8: 当Output DDR配置为OMSER8模式时,其功能图可化简为下图。 这里的CLK_R选择是DQSL接口时钟相移180度。 跟OSER8相比,OMSER8增加了从SERCLK到OCLK的时钟域转换。OMSER8时序图如下所示。
GTP_ISERDES: InputDDR单元主要由IFIFO和GEAR LOGIC两部分组成。其中,IFIFO主要作用于DDR memory interface中,其功能包括从外部非连续DQS到内部连续时钟的时钟域转换,DDR3读数据的realign,一些特殊的Generic DDR应用以及补偿采样时钟和内部时钟的相位差;GEAR LOGIC的主要功能是扩展采样后的数据的位宽,并把它从高速的DESCLK转移到较低速的系统时钟域,以方便Fabric处理。InputDDR单元可通过参数ISERDES_MODE配置成不同的工作模式,这些工作模式包括:IDDR,IMDDR,IDES4,IMDES4,IDES7,IDES8和IMDES8。PDS软件库为方便用户使用Input DDR单元提供了专用原语,用户可以在源代码(Verilog/VHDL)中例化GTP_ISERDES原型模块。以Verilog例化为例: - GTP_ISERDES#(
- .ISERDES_MODE (“IDDR”),
- .GRS_EN (“TRUE”),
- .LRS_EN (“TRUE”)
- ) u_ISERDES(
- .DI (DI ),
- .ICLK (ICLK ),
- .DESCLK (DESCLK ),
- .RCLK (RCLK ),
- .WADDR (WADDR ),
- .RADDR (RADDR ),
- .RST (RST ),
- .DO (DO )
- );
复制代码GTP_ISERDES的参数及信号说明如下: GTP_ISERDES通常会与GTP_INBUF,GTP_INBUFG,GTP_INBUFDS和GTP_INBUFGDS一起使用,下图以GTP_INBUFDS为例说明GTP_ISERDES与之连接的方式。 图 50.1.30 GTP_ISERDES常用连接方式 下面分别介绍Input DDR的不同工作模式。 IDDR: 当Input DDR配置为IDDR模式时,其功能图可化简为下图。 注:时序图中的a,b,c,d等字母用以代表bit数据的位置信息,就数据而言数值为‘0’或‘1’。 IMDDR: 当Input DDR配置为IMDDR模式时,与IDDR结构相比,IMDDR使能了其中的IFIFO。其功能图可简化为下面的图例。 IMDDR时序图如下。
IMDDR时序图 IDES4: 当Input DDR配置为IDES4时,与GTP_INBUF,GTP_INBUFG,GTP_INBUFDS或GTP_INBUFGDS配合使用。其功能图可简化为下面的图例。 IDES4时序图如下所示。 IMDES4 当Input DDR配置为IMDES4时,与IDES4相比,IMDES4使能了其中的IFIFO。其功能图可简
化为如下图例。 IMDES4时序图如下。 upd信号在异步RESET之后的1个clk周期后,开始起作用,并且每两个CLK_IO有效一次。 IDES7: 当Input DDR配置为IDES7时,使用方法与IDES4相同。其功能图可简化为如下图例。 IDES7时序图如下所示。 IDES8: 当Input DDR配置为IDES8时,使用方法与IDES4相同。其功能图可简化为如下图例。 IDES8时序图如下所示。 IMDES8 当Input DDR配置为IMDES8时,与IDES8相比,IMDES8使能了其中的IFIFO。其功能图可简化为如下图例。 IMDES8时序图如下所示。 IMDES8功能时,upd信号在异步rst之后的2个clk周期后,开始起作用,并且每4个clk周期有效一次。
1.2 实验任务本节实验任务是使用ATK-DFPGL22G开发板上的以太网接口,和上位机实现ARP请求和应答的功能。当上位机发送ARP请求时,开发板返回ARP应答数据。当按下开发板的触摸按键时,开发板发送ARP请求,此时上位机返回应答数据。
1.3 硬件设计千兆以太网接口部分的硬件设计原理和“MDIO接口读写测试实验”完全相同,请参考“MDIO接口读写测试实验”中的硬件设计部分。 本实验中,各端口信号的管脚分配如下表所示:
对应的FDC约束语句如下所示: - create_clock-name {eth_rxc} [get_ports {eth_rxc}] -period {8} -waveform {0.000 4.000}
- create_clock-name {sys_clk} [get_ports {sys_clk}] -period {20} -waveform {0.000 10.000}
- define_attribute{p:eth_txd[3]} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_txd[3]} {PAP_IO_LOC} {V11}
- define_attribute{p:eth_txd[3]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_txd[3]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_txd[3]} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_txd[3]} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_txd[2]} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_txd[2]} {PAP_IO_LOC} {U11}
- define_attribute{p:eth_txd[2]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_txd[2]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_txd[2]} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_txd[2]} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_txd[1]} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_txd[1]} {PAP_IO_LOC} {V12}
- define_attribute{p:eth_txd[1]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_txd[1]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_txd[1]} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_txd[1]} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_txd[0]} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_txd[0]} {PAP_IO_LOC} {U12}
- define_attribute{p:eth_txd[0]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_txd[0]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_txd[0]} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_txd[0]} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_rxd[3]} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rxd[3]} {PAP_IO_LOC} {V17}
- define_attribute{p:eth_rxd[3]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rxd[3]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_rxd[2]} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rxd[2]} {PAP_IO_LOC} {V18}
- define_attribute{p:eth_rxd[2]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rxd[2]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_rxd[1]} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rxd[1]} {PAP_IO_LOC} {P12}
- define_attribute{p:eth_rxd[1]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rxd[1]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_rxd[0]} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rxd[0]} {PAP_IO_LOC} {P11}
- define_attribute{p:eth_rxd[0]} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rxd[0]} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_rst_n} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_rst_n} {PAP_IO_LOC} {D10}
- define_attribute{p:eth_rst_n} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rst_n} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute {p:eth_rst_n}{PAP_IO_DRIVE} {4}
- define_attribute{p:eth_rst_n} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_tx_ctl} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_tx_ctl} {PAP_IO_LOC} {T11}
- define_attribute{p:eth_tx_ctl} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_tx_ctl} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_tx_ctl} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_tx_ctl} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_txc} {PAP_IO_DIRECTION} {OUTPUT}
- define_attribute{p:eth_txc} {PAP_IO_LOC} {R11}
- define_attribute{p:eth_txc} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_txc} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_txc} {PAP_IO_DRIVE} {4}
- define_attribute{p:eth_txc} {PAP_IO_SLEW} {SLOW}
- define_attribute{p:eth_rx_ctl} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rx_ctl} {PAP_IO_LOC} {U18}
- define_attribute{p:eth_rx_ctl} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rx_ctl} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:eth_rxc} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:eth_rxc} {PAP_IO_LOC} {U17}
- define_attribute{p:eth_rxc} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:eth_rxc} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:sys_clk} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:sys_clk} {PAP_IO_LOC} {B5}
- define_attribute{p:sys_clk} {PAP_IO_VCCIO} {3.3}
- define_attribute{p:sys_clk} {PAP_IO_STANDARD} {LVCMOS33}
- define_attribute{p:sys_rst_n} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:sys_rst_n} {PAP_IO_LOC} {G5}
- define_attribute{p:sys_rst_n} {PAP_IO_VCCIO} {1.5}
- define_attribute{p:sys_rst_n} {PAP_IO_STANDARD} {LVCMOS15}
- define_attribute{p:sys_rst_n} {PAP_IO_NONE} {TRUE}
- define_attribute{p:touch_key} {PAP_IO_DIRECTION} {INPUT}
- define_attribute{p:touch_key} {PAP_IO_LOC} {F1}
- define_attribute{p:touch_key} {PAP_IO_VCCIO} {1.5}
- define_attribute{p:touch_key} {PAP_IO_STANDARD} {LVCMOS15}
- define_attribute{p:touch_key} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_txd[3]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_txd[2]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_txd[1]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_txd[0]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_rxd[3]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_rxd[2]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_rxd[1]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_rxd[0]} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_tx_ctl} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_txc} {PAP_IO_NONE} {TRUE}
- define_attribute{p:eth_rx_ctl} {PAP_IO_NONE} {TRUE}
- define_attribute {p:eth_rxc}{PAP_IO_NONE} {TRUE}
- define_attribute{p:sys_clk} {PAP_IO_NONE} {TRUE}
复制代码 |