【再说FPGA】基于ARP请求和应答的TSE-MAC功能性验证

发表于 2013/3/9 14:55:44 阅读（4873）

基于ARP请求和应答的TSE-MAC功能性验证

Qsys中集成了以太网MAC的IP核（姑且称它TSE-MAC），正所谓TSE（Triple Speed Ethernet），可以配置工作在10/100/1000Mbit的工作模式下。本文就要来试试它的功能性，自己动手，丰衣足食，搭个小系统，基本框图如下。

TSE-MAC中带了PHY芯片各个寄存器配置的MDIO接口控制逻辑，用户可以通过Avalon-MM总线相应的读写PHY芯片的寄存器。同时，MAC的一些配置寄存器也是通过Avalon-MM总线访问控制。因此，本系统也挂了个NIOS II上去，用于MAC初始化配置以及必要的PHY芯片控制。

其实大家最关注的应该是TSE MAC的数据流如何进行收发，既然是Altera的IP，那么自然要用到他们主打的Avalon-ST总线。RX和TX都有各自的Avalon-ST接口。本系统中，RX端连接到了一个256*8bit的onchip-RAM上，设计了一些逻辑，让Avalon-ST送出的数据自动的循环写入RAM中。通过JTAG接口，Quartus II中有个很实用的在线调试工具In-system Memory Content Editor可以实时的查看到当前RXRAM的所有数据情况。同样的，TX端也是连接到一个64*8bit的onchip-RAM上，也设计了一个简单的定时（2s多）发送功能，它自动读取TXRAM中的数据并通过Avalon-ST接口送往MAC，TXRAM中的数据也可以通过In-system Memory Content Editor在线写入。In-system Memory Content Editor真得是个很实用的小工具，大家在FPGA的调试和验证中可以非常灵活的使用它，力荐。

如图所示，这个仿真波形是发送端的Avalon-ST将TXRAM中存储的初始化帧数据发送给MAC。

我们后面希望通过发出一个ARP请求，然后看看PC端传回来的ARP应答，验证MAC的功能。先来简单的了解ARP请求的帧格式。

下面是我们写入到TXRAM中的一帧60Byte的ARP请求数据，正好可以对照上面给出的ARP帧请求定义。

//以太网首部（14Byte）

0000: ff ff ff ff ff ff//目的主机为广播地址

0006: 00 1C 23 17 4A CB//源主机MAC地址为00-1C-23-17-4A-CB

000c: 08 06//上层协议类型0x0806表示ARP

//ARP请求（28Byte）

000e: 00 01//硬件类型0x0001表示以太网

0010:08 00//协议类型0x0800表示IP协议

0012:06 04//MAC地址长度为6；IP地址长度为4

0014:00 01//op为0x0001表示请求目的主机的MAC地址

0016: 00 1C 23 17 4A CB//源主机MAC地址为00-1C-23-17-4A-CB

001c: c0 a8 01 69//源主机IP地址（192.168.1.105）

0020: 00 00 00 00 00 00//目的主机MAC地址未知，全0待填写

0026: c0 a8 01 64//目的主机的IP地址（192.168.1.100）

//填充数据（18Byte）填充aoc c0 a8 01 000

002c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

003c: 00 00

目的主机便是我们的PC，它的MAC地址和IP地址都不是瞎编的，在目标PC的cmd中敲击“ipconfig /all”命令，如图所示。我们可以看到这个目标主机的MAC地址为2C-27-D7-1F-1D-E1，IP地址为192.168.1.100。假设我们只知道目的主机的IP地址，而不知道MAC地址，那么上面的ARP请求中就给出目的主机的IP地址，但使用广播MAC地址进行寻址。理论上，目的主机在接收到对他的ARP请求后，会产生一个ARP应答帧给源主机，实际是否如此，随后我们便可验证。

下一步，该连接的连接，该下载的下载，该运行的运行……在一切就绪之后，我们打开In-system Memory Content Editor，确认发送端RAM的数据是ARP请求帧，接着让它运转起来，如图所示，下面是TXRAM的ARP请求帧数据，上面是256Bytes的RXRAM，已经不断的收到了目的主机发回来的ARP应答了。有兴趣大家可以自己对照ARP应答帧格式的一些细节，这果然是一个非常“理想化”的应答帧（简直是废话，否则咱的IP如何正常收发啊？）。