你的位置：
&& 详细内容
2014超算大会上的三个FPGA演示：键值存储，低延迟25G以太网MAC，NVMe控制器
热度168票&&浏览1967次
时间：日 17:33
作者：Steve Leibson, 赛灵思战略营销与业务规划总监
今天是新奥尔良SC14（2014年超算大会）展览大厅开放的第一天，赛灵思展台已经充满了各种演示。赛灵思公司数据中心架构师Shreyas Shah为我快速了演示其中的三个demo：
• FPGA快速键值存储
• FPGA25G以太网Mac
• 基于FPGA的NVMe存储控制器
键值存储用于许多数据库应用中，如NoSQL和memcached。键值数据库存储关联的一个简单数据对（也即键与值），而且数据库通过键来访问相
关联的值。键值存储很简单，扩展性很好，这意味数据库的规模可以相当大，而这正是基于Web为消费者提供服务的应用的关键需求。尽管关系型数据库曾经在复
杂数据中心应用中风靡一时，但许多常见的、基于Web的服务和应用通常只包括简单的查询，并不需要关系数据库相关的复杂性。
SC14 上的演示展示了带有一个板上赛灵思FPGA &的
一个PCIe开发板，其上运行一个memcached应用。一个英特尔8核至强CPU
以软件方式运行同一个memcached应用。Memcached的FPGA技术实现不需要CPU的任何干预，并且以太网线路速率高达10Gbps。而软
件版本，需要8个之中的3个CPU参与，并且依据Linux调度器的不同性能表现差异很大。即便软件版本采用最佳的调度器，其吞吐率也只有
1.8Gbps，峰值也只是FPGA实现的不到20 %。平均来说，相较于CPU实现，FPGA版本速度快10倍，而且功耗只需大约10%。
下面是该演示的视频：
低延迟25G以太网MAC演示展示了赛灵思新的以太网MAC和PCS IP，支持新的&规范。该演示显示了两个评估板上的，每个运行一个25G以太网MAC，驱动两板之间的5米铜电缆。电缆直接连接到FPGA上。
Shreyas并没有明确告诉我“低延迟”对25G以太网MAC来说到底意味什么。他只说了两件事：第一，延迟小于100纳秒；第二，您需要联系您附近友好的赛灵思销售人员来获取更多技术细节。
下面是低延迟25G以太网MAC的演示视频：
最后，shreyas演示了一个基于FPGA的NVMe存储控制器的实现，在PCIe接口上面运行NVMe协议。NVMe为基于PCIe的
SSD（固态硬盘）定义了优化的寄存器接口、指令集和特征集。在演示中，FPGA操作一个作为NVMe驱动器的512G字节Flash存储器。
下面是基于FPGA的NVMe演示视频：
原文链接：
© Copyright 2014 Xilinx Inc.
如需转载，请注明出处
对本篇资讯内容的质量打分:
当前平均分：-0.12 （78次打分）
【已经有90人表态】
[感动最多的]
[路过最多的]
[高兴最多的]
[难过最多的]
[搞笑最多的]
[愤怒最多的]
[无聊最多的]
[同情最多的]需要确认注册邮箱后才能开通博客，
&&&以太网，FPGA就一定能搞定系列之MACRAW模式下的ARP请求
6年会员勋章目前未领取。领取条件：?凡是注册时间六年以上的活跃用户即可领取该勋章。
特权同学的博客——特权's Blog——永远忠于年轻时的梦想！
博主：????
在实践中学习，在实践中思考，在实践中总结，在实践中提高；也许，在特权同学的原创博文中会有一些不成熟的思考和文字，也非常期待各路好手分享自己的看法和见解，特权在此先谢过了！～_～
你们必认识真理，真理必叫你们得以自由。And you shall know the truth, and the truth shall set you free. ----John 8:32
文章(614)????
访问(2449654)????
评论(1981)????
投票(837)????
订阅本博??
博文列表查看方式：
需要确认注册邮箱后才能下载，
就一定能搞定系列之MACRAW模式下的ARP请求
本系列博文节选自特权同学的FPGA开发电子书《SF-CY3 FPGA套件开发指南》。
最新设计文档下载地址：/s/1em79m
如图所示，这是本实例的硬件架构和互联示意图。上一节对整个架构已经有所介绍，这里不重复描述。由于上一节只是简单的验证FPGA和CH395之间的通信状态，而没有涉及以太网通信应用，而这一节我们需要连接网络，进行实际的以太网通信测试。所以，在本实例中，大家需要使用网线将SF-NET子板的以太网接口连接到路由器（当然了，也必须确保PC机连接到了同一个路由器上）或者直接连接到PC机上。
以太网协议概述
TCP/IP协议是网络的基础，是Internet的语言，可以说没有TCP/IP协议就没有互联网的今天。网络的速度发展非常快，学习网络的人也越来越多。而本教程将会通过使用FPGA驱动PHY/MAC集成芯片CH395进行各种以太网通信，来和大家一起认识并掌握TCP/IP以及其他常用的以太网协议，甚至能够达到学以致用的水平。这里我们先扫盲式的和大家一起认识一下以太网分层和帧协议内容。
网络协议通常分不同层次进行开发，每一层分别负责不同的通信功能。一个协议族，比如TCP/IP，是一组不同层次上的多个协议的组合。TCP/IP通常被认为是一个四层协议系统，如图所示。
每一层负责不同的功能：
1) 链路层，有时也称作数据链路层或网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口卡。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。
2) 网络层，有时也称作互联网层，处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。
3) 运输层主要为两台主机上的应用程序提供端到端的通信。在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。而另一方面，UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。任何必需的可靠性必须由应用层来提供。这两种运输层协议分别在不同的应用程序中有不同的用途，这一点将在后面看到。
4 ) 应用层负责处理特定的应用程序细节。如Telnet 远程登录、FTP 文件传输协议、SMTP 简单邮件传送协议、SNMP 简单网络管理协议等。
当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，同时去掉各
层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识，以确定接收数据的
上层协议。这个过程称作分用（Demultiplexing），如图展示了该过程是如何发生的。
对于以太网协议的分层是一件比较头疼的事情，比如为协议I C M P和I G M P的定位。在前面的分层中，我们把它们与IP放在同一层上，那是因为事实上它们是IP的附属协议。但是在这里，我们又把它们放在IP层的上面，这是因为ICMP和IGMP报文都被封装在IP数据报中。
对于ARP和RARP，我们也遇到类似的难题。在这里把它们放在以太网设备驱动程序的上方，这是因为它们和IP数据报一样，都有各自的以太网数据帧类型。但在某些分层中，我们可能会把ARP和RARP作为以太网设备驱动程序的一部分，放在IP层的下面，其原因在逻辑上却是合理的。
CH395内部集成了IPv4、ARP、ICMP、IGMP、UDP、TCP等协议，其关系如图所示。
TCP和UDP是两种比较重要的传输层协议，两者都使用IP作为网络层协议。
TCP是一种面向连接的传输，能够提供可靠的字节流传输服务。
UDP是一种简单的面向数据报的运输层协议，与TCP不同的是UDP无法保证数据报文准确达到目的地。
TCP为网络设备提供了高可靠性的通讯，它所做的工作包括把应用程序交给他的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置超时时钟等，由于运输层提供了高可靠性的端到端的通信，应用层客户忽略所有细节。而UDP则为应用层提供一种非常简单的服务，速度较TCP快，它只是把数据报从一个网络终端发送到另一个网络终端，但是并不保证该数据报能够达到另一端，任何必需的可靠性都必须由应用层来提供。
IP是网络层上的协议，同时被TCP和UDP使用，TCP和UDP的每组数据都通过IP层在网络中进行传输。
ICMP是IP协议的附属协议，IP层用它来与其他主机或者路由器交换错误报文或者其他重要信息，例如CH395产生不可达中断，就是通过ICMP来进行错误报文交换的。PING也使用了ICMP协议。
IGMP是Internet组管理协议，主要用来把一个UDP数据报多播到多个主机。
ARP为地址解析协议，用来转换IP层和网络接口层使用的地址。
CH395提供了MACRAW传输模式、IPRAW传输模式、UDP传输模式、TCP客户端模式、TCP服务器模式、DHCP传输模式和PPPOE传输模式。各个模式下，数据流基本都是相应模式所支持协议的有效数据，可以满足用户的各种不同应用需求。我们将会使用该SF-CY3核心板和SF-NET子板对各种不同的传输模式进行测试，给出各种以太网传输协议的实例。
在MACRAW模式下，CH395会透明传输以太网和单片机之间的数据，不会对数据进行TCP/IP封装，CH395接收数据时会对以太网冗余校验CRC32进行校验，如果校验错误，数据包不会转发给单片机。CH395发送数据时会在数据包尾部加入以太网冗余校验CRC32。单片机每次向CH395写入的数据长度不得大于1514，CH395会将单片机每次写入的数据封装成一帧数据进行发送。当CH395从以太网收到数据后会通知单片机，此时单片机应立即将所有数据从CH395内部接收缓冲区读走。 仅Socket0可以设置此模式，且其他Socket将不可用。如图所示，对于一个标准的IEEE802.3以太网帧而言，MACRAW模式下，用户可以通过编程读写的数据流包括了目的MAC地址、源MAC地址、协议类型和有效数据等内容，CRC32数据则由CH395芯片自动给出。
我们可以简单的来看看前面所提到的ARP和RARP协议的数据帧格式，如图所示。我们就重点看看ARP协议，这是一个地址解析协议，简单讲，就是以太网目的主机和源主机之间进行握手寻址的一个协议机制。ARP协议由三大部分数据内容组成，第一部分是以太网首部，分别传输6个字节的目的MAC地址和6个字节的本机MAC地址；第二部分是有效传输数据，头两个字节用于区分不同的协议类型，如IP协议对应两个字节16进制的0800，ARP协议则对应为0806，如果确定是ARP协议传输，那么随后的28个字节为ARP的请求或应答帧数据，具体帧定义后面会讨论，由于IEEE802.3以太网帧协议规定，有效数据传输最少必须是46个字节，而ARP的请求或应答帧只有28个字节，因此后续必须填充18个字节数据，这18个字节一般以全零数据填充；第三部分则是CRC校验数据，通常由芯片自动计算给出。
我们后面希望通过发出一个ARP请求，然后看看PC端传回来的ARP应答，验证MAC的功能。先来简单的了解ARP请求的帧格式。
下面是我们要发送给笔者测试PC机的60Byte的ARP请求数据，正好可以对照上面给出的ARP帧请求定义。
//以太网首部（14Byte）
0000: ff ff ff ff ff ff???????????????????????????????? //目的主机为广播地址
e4 f0 08 ef ???????????????????? //源主机MAC地址为84-C2-E4-F0-08-EF
000c: 08 06??????????????????????????????????????????? //上层协议类型0x0806表示ARP或RARP
//ARP请求（28Byte）
000e: 00 01?????????????????????????????????????????? //硬件类型0x0001表示以太网
?????????????????????????????????????????? //协议类型0x0800表示IP协议
?????????????????????????????????????????? //MAC地址长度为6； IP地址长度为4
?????????????????????????????????????????? // op为0x0001表示请求目的主机的MAC地址
e4 f0 08 ef ???????????????????? //源主机MAC地址为00-1C-23-17-4A-CB
001c: c0 a8 01 65???????????????????????????????? //源主机IP地址（192.168.1.101）
00 00 00 00 ????????????????? //目的主机MAC地址未知，全0待填写
0026: c0 a8 01 67????????????? ?????????????????? //目的主机的IP地址（192.168.1.103）
//填充数据（18Byte）
002c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003c: 00 00
目的主机便是我们的PC，它的MAC地址和IP地址都不是瞎编的，在目标PC的startàcmd中敲击“ipconfig /all”命令，如图所示。我们可以看到这个目标主机的MAC地址为2C-27-D7-1F-1D-E1，IP地址为192.168.1.103。假设我们只知道目的主机的IP地址，而不知道MAC地址，那么上面的ARP请求中就给出目的主机的IP地址，但使用广播MAC地址进行寻址。理论上，目的主机在接收到对他的ARP请求后，会产生一个ARP应答帧给源主机，实际是否如此，随后我们便可验证。
该实例的软件流程如图所示，除了一系列的初始化外，main函数中不断的发送ARP请求帧，PC机通常会回复ARP应答，而连接FPGA的输入GIO的CH395中断信号会产生相应中断，main函数中相应的轮询处理中断，将接收到的ARP应答帧通过JTAG UART打印到Nios II Console中。
下一步，该连接的连接，该下载的下载，该运行的运行……在一切就绪之后，我们可以来确认一下EDS的Nios II Console打印的收发数据帧，如图所示。
FPGA发送的ARP请求，数据如下：
0xff,0xff,0xff,0xff,0xff,0xff,0x84,0xc2,0xe4,0xf0,0x08,0xef,0x08,0x06,0x00,0x01,0x08,0x00,0x06,0x04,0x00,0x01,0x84,0xc2,0xe4,0xf0,0x08,0xef,0xc0,0xa8,0x01,0x65,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0xa8,0x01,0x67,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
FPGA接收到的ARP应答，数据如下：
0x84,0xc2,0xe4,0xf0,0x08,0xef,0x2c,0x27,0xd7,0x1f,0x1d,0xe1,0x08,0x06,0x00,0x01,0x08,0x00,0x06,0x04,0x00,0x02,0x2c,0x27,0xd7,0x1f,0x1d,0xe1,0xc0,0xa8,0x01,0x67,0x84,0xc2,0xe4,0xf0,0x08,0xef,0xc0,0xa8,0x01,0x65,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
FPGA发出的ARP请求前面我们已经做了解析，而ARP应答是PC端发送回来的，我们不妨也分析下它的帧结构。
//以太网首部（14Byte）
e4 f0 08 ef?????????????????????? //目的主机（FPGA端）MAC地址84-C2-E4-F0-08-EF
d7 1f 1d e1 ??????????????????? //源主机（PC端）MAC地址为2C-27-D7-1F-1D-E1
000c: 08 06??????????????????????????????????????????? //上层协议类型0x0806表示ARP请求或应答
//ARP请求（28Byte）
000e: 00 01?????????????????????????????????????????? //硬件类型0x0001表示以太网
?????????????????????????????????????????? //协议类型0x0800表示IP协议
?????????????????????????????????????????? //MAC地址长度为6； IP地址长度为4
?????????????????????????????????????????? // op为0x0002表示ARP应答
d7 1f 1d e1????????????????????? //源主机（PC端）MAC地址为2C-27-D7-1F-1D-E1
001c: c0 a8 01 67???????????????????????????????? //源主机（PC端）IP地址（192.168.1.103）
e4 f0 08 ef ???????????????????? //目的主机（FPGA端）MAC地址84-C2-E4-F0-08-EF
0026: c0 a8 01 65??????????????????????????????? //目的主机（FPGA端）的IP地址（192.168.1.101）
//填充数据（18Byte）
002c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003c: 00 00
回到目标PC机，我们在cmd命令行中，输入一个命令“arp -a”，此时，我们看到发出ARP请求的源主机已经出现在了它的动态列表中了，而且IP和MAC与发出ARP请求的FPGA端给出的别无二致。
最后，我们再借助一个抓包工具“科来网络分析系统”来解析下FPGA发过来的ARP请求帧。“科来网络分析系统”可以到官方网站（.cn/download/capsa.php）下载，大家可以选择“技术交流版”进行下载。下载并安装完成后，可以根据提示到他们官方网页注册，接着系统会自动将注册码发送到我们的邮箱中。
如图所示，我们打开已经安装并注册好的科来网络分析系统。选择“本地连接”以及“全面分析”，点击“Start”开始运行。
如图所示，“节点浏览器”中选择“ARP”项，然后双击“物理端点”下的“84:C2:E4:F0:08:EF”（即ARP请求发送端的MAC地址）。
如图所示，这里我们看到了详细的ARP请求帧的协议解析。大家可以比对我们前面给出的ARP请求帧解析，和这里是完全一致的。
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
1.扫描左侧二维码
2.点击右上角的分享按钮
3.选择分享给朋友
??????有[ 1 ]名读者喜欢此文
阅读(3987)??
评论是对思考最好的总结…
你还可以输入1000字
--- 现有 2 个主题，共 1 页 ---
转发到我的博客
评论??的“以太网，FPGA就一定能搞定系列之MACRAW模式下的ARP请求”
以太网，FPGA就一定能搞定系列之MACRAW模式下的ARP请求本系列博文节选自特权同学的FPGA开发电子书《SF-CY3FPGA套件开发指南》。最新设计文档下载地址：/s/1em79m1概述如图所示，这是本实例的硬件架构和互联示意图。上一节对整个架构已经有所...
你还可以输入30000字
同时评论给?特权同学
你还可以输入1000字
你还可以输入1000字
在成功的时候我学习谦虚在失败的时候我学习坚毅在快乐的时候我学习节制在痛苦的时候我学习忍耐在愤怒的时候我学习冷静在害怕的时候我学习勇敢在焦虑的时候我学习乐观在迷惑的时候我学习分析在犹豫的时候我学习
zgq800712??19:48 06-19
zcz2004??15:48 06-17
mirchell??09:24 06-13
jwdxu2009??22:54 06-09
幻听绿蓝??10:53 06-08
EDN助学—FPGA/CPLD学习小组
成员18969名创建者：
《FPGA快速系统原型设计权威指南》书友会
成员471名创建者：
《FPGA/CPLD边练边学》书友会
成员269名创建者：
成员1698名创建者：
《基于FPGA的快速系统原型开发》翻译
成员1038名创建者：
Numonyx存储小组
成员427名创建者：
工程师读《圣经》
成员162名创建者：
成员11372名创建者：
EDN助学—CAN学习小组与书友会
成员4533名创建者：
FPGA讨论组
成员3308名创建者：
EDN帮助小组
成员405名创建者：
振南的znFAT 单片机上的FAT32文件系统
成员714名创建者：
EDN助学小组之51单片机
成员4860名创建者：
图像视频讨论区
成员140名创建者：
电子制作交流区
成员4841名创建者：
深入浅出玩转FPGA之学习小组
成员937名创建者：
成员363名创建者：
《匠人手记》书友会
成员900名创建者：
《感悟设计》书友会
成员356名创建者：
EDN助学---TCP学习小组
成员793名创建者：
《华为研发》书友会
成员270名创建者：
SD/MMC DESIGN
成员583名创建者：
成员59名创建者：
点评EDN文章
成员24名创建者：
抗震救灾，爱心捐助小组
成员88名创建者：
-- Use of this website is subject to its terms of use.
京ICP备号-4 |
京公网安备37 |
新版社区已上线，旧版论坛、博客将停用
1、为防数据丢失，旧版论坛、博客不再接受发帖；
2、老用户只需重设密码，即可直接登录新平台；
3、新版博客将于8月底完美归来，敬请期待；
4、全新论坛、问答，体验升级、手机阅读更方便。您的位置： >
来源：　　作者：郭航;
以太网MAC控制器的FPGA实现　 根据OSI七层参考模型[1],以太网对应模型中的物理层和数据链路层,并把数据链路层分为逻辑链路层(LLC)和介质访问控制(MAC)层。逻辑链路层是与上层协议的接口,负责接收上层协议的数据和向上层协议输出接收的数据内容,并不对接收或发送的数据进行处理,因此以太网技术主要集中在物理层(PHY)和介质访问控制层(MAC)的实现上,MAC子层协议是收发帧的基础,负责上层数据和物理层比特流的封装和解封、流量控制以及差错校验等功能,是以太网控制器的核心。1总体方案MAC控制器由4个主要部分构成包括发送模块、接收模块、主机接口模块、控制模块。其中数据发送和接收模块主要完成数据的接收和发送工作,包括MAC帧的解包和封装以及错误检测。主机接口是以太网控制器和上层协议进行通信的接口,将接收的数据帧保存在存储器中,在从存储器中把需要的数据向上传入上层协议或向下传入物理层(PHY)芯片。控制模块主要完成对输入和输出状态的完全控制,以及接收和发送数据的缓冲。总体框图如图1所示。图1 MAC控制器总体框图2 MAC控制器的详细设计2.1发送模块数据发送模块主要由计数器模块、数据发送状态机、错误处理模块和CRC校验(本文共计2页)　　　　　　　　　　
相关文章推荐
看看这些杂志对你有没有帮助...
单期定价：16.00元/期全年定价：12.80元/期　共153.60元
　　　　　　博客访问： 186122
博文数量： 50
博客积分： 834
博客等级： 军士长
技术积分： 683
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Verilog
&&&&&&&&最近花了一周时间调试这个功能，因为网上找的很多文章，包括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....相间的二进制后，再捕捉一个字节的，PHY就判断后面的数据就是6个字节的目标MAC，6个字节的源MAC，2个字节的报文类型等等。MAC层要求定界字符之后的内容要在64字节到1518个字节之间，其中包括14自己的目标和源MAC，4字节的CRC32值。并且报文帧之间的传递间隔要大于9.6us。
大概了解了MAC协议之后，就要知道这些引导码等如何实用到MII接口的4bit传输。拿最后的定界字符来说，现发送1010，后发送1011，依次对应txd的关系是txd[0],txd[1],txd[2],txd[3]，也就现发送txd[3:0]=，后发送txd[3:0]=1101=4'hD，引导码同样推理出4'h5，7个字节及14个4'h5，加一个定界符4'h5,4'hD。
&&&&&&&&b、上传了一篇经过我注释的关于FPGA并行4bit计算CRC32的公式推导过程的文档：
&&&&&&&&概念：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'h，依此类推。
& &&&&& 关于按照文档推导的并行计算出来的CRC32结果，为什么不是直接充当MAC层的FCS值，我没有找到任何理论依据，公式推导的文档中也没有提，如果有人对此有过研究的可以联系我，希望能让我请教一下。工作邮箱：zhangw_
阅读(3324) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。