爱学习的张哥-优快云博客

原创 UDP协议栈之整体架构处理

接下来查看单包信息的传递情况，需知道MAC层使用的目的AMC地址，是在ARP缓存表中进行读取的，在数据报文到达IP层时，向ARP缓存表进行读取，寻找目的IP的MAC地址是否存在于ARP缓存表中，将寻找到的MAC地址发送给MAC层，所以在仿真中进行检验，是否使用了正确的MAC地址。

2025-03-14 15:39:30 698

而根据输出赋值的优先级，会出现，巨型帧输出不完全，被新一帧数据报文顶替输出，以及当前报文优先级低，无法获得总线使用权，报文丢失，所谓的优先级，即是在一个时序控制逻辑内，else if的上下级，当两个else if语句满足时，总是先执行最上面的else if语句，单纯的文字解释这个问题，可能会给读者的理解造成混乱，笔者接下来就流程示意框图、代码仿真波形两方面展现这类情况，使得读者更加清晰的理解这些逻辑。情况三：对应仿真情况如下，可以看出在输出单包数据完成后，在单包数据输出期间被缓存的单帧数据包成功进行输出。

2025-03-13 19:03:34 982

原创 ICMP、UDP以及IP、ARP报文包的仲裁处理

关于输出trans总线，根据读取的是哪一个缓冲区，进行FIFO数据数据的复制即可，以及类型、长度、都从FIFO中对读取，而ro_trans_last拉高则是在本次读取的数据长度等于FIOF中缓存的本帧数据长度信息确定。在数据缓存区，由两个FIFO组成，一个是数据报文，另一个FIFO则是缓存本帧的数据长度以及报文类型，因为这是一个通用的仲裁处理，不考虑是在仲裁UDP/ICMP还是IP/ARP。关于流程图中的Frame_refuse，即帧拒绝信号，指示上一级模块，暂时不要进行数据的发送，

2025-03-13 11:19:00 621

原创 MAC层接收逻辑处理及CRC校验接收数据

在上一章节中，笔者就以太网的CRC计算规则做了简单介绍，并对实现流程进行了讲解，以及代码仿真验证，在本节中，笔者将就以太网MAC层的接收代码做逻辑实现，并且做CRC计算，只有当板卡计算得到的CRC计算结果，与接收数据中的CRC校验结果一致，才认为本帧数据可靠，进行进一步接收利用，并且还需要判断MAC地址是否符合以及接收的报文类型是IP报文还是ARP报文，以传给不同的协议层模块进行处理，对于MAC地址的判断，主要判断当前数据要发送给的MAC地址是否是本机MAC地址或者是广播地址，这两类地址都进行接收，而对于源

2025-01-14 22:51:04 540

原创以太网CRC校验解读及代码实现

看到这里，可能读者会产生疑惑，上述规则中，对结果只是描述了取反，并没有说要进行位反序操作，这里为什么反而需要了呢，其实，这与我们使用的CRC模板有关，上述生成的CRC使用大端序模式计算，我们需要对输入数据进行，位反序，然后再进行计算，再对结果进行位反序以及取反操作，下面我们介绍，CRC使用小端序模式计算。其中8位的data为以太网传输数据，在代码中，需要做进一步修改，即在以太网的 CRC 校验中，数据的每个字节在计算时需要按照位序进行处理。输入一段相同的数据，如上一章节中，要进行发送的一段数据报文。

2025-01-14 11:20:45 1366 1

原创 MAC层协议解读及发送代码实现

在本节中，笔者就MAC发送层的帧封装，CRC校验，流量控制等功能进行实现，关于以太网CRC的计算，在下一章节中，做详细介绍，本章节中实现这三个功能，但不对CRC计算的代码实现进行讲解。所谓流量控制，即保证传输的ready信号在合适时间内进行拉高以及拉低处理即可，本代码实现的流量控制较为简单，保证以太网传输的最小帧长即可帧间隙(IFG)：以太网相邻两帧时间间隔,为96bit time如1000Mbit/s最小时间为96*1ns，即12个时钟周期。

2025-01-13 18:51:05 1302 1

原创 IP层之分片包的整合处理

在上一章节中，笔者就IP层的接收代码逻辑做了简单介绍，并对实现代码进行了逻辑梳理以及仿真测试，并且在上一章节中，就IP层的分片包问题，如何确定分片包是否存在已经进行了简单介绍，并在接收模块中，将分片信息进行了输出，因为在设计中，只会对IP报文中包含的数据包中UDP报文和ICMP报文，并且ICMP的报文大小不会产生分包情况，所以可知在判断出当前的IP报文中数据包为UDP数据包后，将UDP数据包输入至IP分片处理模块，进行相应处理标志字段标志字段是IP头部的一部分，用于控制分片的行为。

2025-01-13 11:23:30 1028

原创 IP层接收代码的逻辑实现

在数据到达IP层时，其数据组成就是IP报文包了，MAC首部的信息都已经被过滤掉，所以在IP层的接收逻辑中，重要的是判断该包数据是否属于板卡要接收的数据包，即判断IP 地址即可，关于IP层的首部校验和的校验和，因为在到达IP层的数据，已经经过了CRC校验，在一定程度上保证了数据的可靠性，而IP校验和的计算，可判断IP首部是否正确，所以在接收时，代码中，是否计算首部校验和都可，可以进行选择，笔者在这里选择进行首部校验和的判断。在之前的章节中，笔者已经就IP层的传输逻辑做了简单的介绍，其报文结构组成相对复杂。

2025-01-11 13:27:26 1093

原创 UDP层接收代码的逻辑实现

在数据到达UDP层时，其数据组成就是UDP报文包了，IP首部，MAC首部的信息都已经被过滤掉，所以在UDP层的接收逻辑中，重要的是判断该包数据是否属于板卡要接收的数据包，即判断端口号即可，关于UDP的校验和，因为在到达UDP层的数据，已经经过了CRC校验，在一定程度上保证了数据的可靠性，而UDP校验和的计算，需要计算UDP首部和UDP数据，需要一定的时钟周期，并且UDP首部的校验和在协议中规定是可以省略的，所以在接收时，代码中，便不对UDP校验和进行计算。进行仿真，查看UDP接收模块能否正确解析数据。

2025-01-11 11:24:09 262

原创 ARP层协议解读及ARP层代码实现

ARP（地址解析协议，Address Resolution Protocol）是一个用于将网络层（IP地址）地址转换为数据链路层（MAC地址）地址的协议。它通常在局域网（LAN）中使用，尤其是在以太网网络中。仿真测试3：缓存192.168.1.10，11-22-33-44-55-66，缓存192.168.1.20，A5-67-B3-A6-D5-E6；主机A收到响应并缓存：主机A收到ARP应答后，更新其ARP缓存表，记录下目标设备的IP地址与MAC地址的映射关系，之后它可以直接用该MAC地址与主机B通信。

2025-01-07 11:19:18 1354

原创 ICMP层协议解读及ICMP层代码实现

同样，在上文中的UDP、IP报文中，也可以使用这一方式，可以使用两个网口调试助手，在电脑端使用127.0.0.1这一IP地址进行回环测试，使用wireshark抓包，观察数据报文组成，有利于我们对各个协议报文组成的理解。ICMP接收端的逻辑按照ICMP包的报文信息顺序进行解包即可，主要检查type，code信息，确定是回显请求，并且保存标识符与序列号，传输给ICMP发送端，进行回传。ICMP_RX的逻辑主要是检测传输进来的ICMP报文，若是回显请求报文，则传输给ICMP_TX，进行回显应答。

2025-01-04 10:53:07 641

原创 IP层协议解读及IP层传输代码实现

对于首部校验和，在这里简单介绍下校验和的计算方式，首部校验和长度为2字节，16位，在计算IP首部校验和时，按照如下流程进行计算，定义一个32位变量，对IP首部以16位为单位进行划分，进行累加操作，对于累加后的结果，判断其高16位是否为0，若高16位不为0，则对32位变量进行重新赋值，32位变量 = 高16位+低16位；在上一章节中，笔者对UDP层协议进行了简单介绍，并通过编写verilog代码，实现了UDP发送包的逻辑搭建，在本章节中，笔者将就IP层传输协议做简单介绍，并编写IP层传输代码。

2025-01-03 19:54:05 467

原创 UDP层协议解读及UDP传输的代码的实现

由文章开篇的贴图可知，UDP首部为8字节，而千兆以太网的传输标准是8bit，故在接收数据报文后，需要对数据报文进行缓存或延迟处理，先进行UDP首部的处理，对于数据报文的缓存或是延迟，可以考虑使用FIFO，或者是移位RAM实现。而对于最小字节18的计算则是，在以太网中，最小帧长度为64字节，以太网帧头为14字节，尾部CRC校验和为4字节，则要求数据部分最小为46字节，而这里的数据部分包含了IP头部和UDP头部，28字节，故UDP数据报文的最小长度即为18字节。通过仿真可知，UDP组包成功。

2025-01-03 18:38:18 487

原创 vivado使用tcl命令重建工程

可以通过TCL脚本完成这个工作，新建一个TCL脚本，将其放在图中所示的目录下进行运行，运行TCL可以使用vivado的TCL工具，也可以安装Active TCL进行脚本的运行。以这部分为例，其加载的本地目录文件路径如图所示，我们可以将TCL和图中所示的这些文件直接放入一个文件夹中，但笔者为了重建工程的逻辑更加清晰，加这些文件分别放在了不同文件夹下，那么这些目录名字也要对应修改。相应的TCL文件中，也需要进行修改，进行文件路径对应，注意，所用用到的文件，都需要保证其路径的正确。可以快速的提取所有XCI文件。

2024-12-04 15:12:20 1009

原创 USB传输ADC数据之FPGA整体工程逻辑梳理

代码的主要思路是检测有效信号的上升沿，表示第一个数据到来，并且数据流是连贯的，在信号的上升沿，需要判断数据的类型以及传输长度，消耗1个时钟周期。再下一个时钟周期，则进行帧头类型长度信息的传输，故有效数据需要延迟两个时钟周期，再进行传输，并且因为需要传输帧尾，故将有效指示信号延迟3个时钟周期。这一模块的实现是相对简单的，只需要注意数据对齐就好，虽然USB传输为8位并口，但考虑到数据都是以4字节为单位，故扩展帧头为2字节，类型为1字节，长度为1字节，便于上位机进行数据的处理。帧头、类型、长度信息传输正确。

2024-12-04 10:17:41 997 2

原创 USB传输ADC数据之频谱最大值及频率获取

在之前章节，笔者介绍了如何通过FFT的输出结果，以及下标索引，确定检测到的信号频率，其中一个关键的信息是频率分辨率，在固定的运行时钟以及单次FFT长度下，频率分辨率为定值，可以直接在上位机中进行配置即可，故想要在上位机进行频率计算，只要FPGA向上位机传输输出索引即可，本节将介绍如何获取最大幅值以及索引，并完善之前章节的代码，将下位机的整体工程初步确定。至此，下位机代码基本完成，还缺少的则是数据上传部分，该部分功能简单，只需要使能对应数据长度的时钟周期，将数据写入FIFO，供上位机读取即可。

2024-12-03 18:12:26 405

原创 USB传输ADC数据之交互协议代码编写

主要的逻辑是状态机保持在空闲状态，检测到数据帧的帧头后，跳转至检测到帧头状态，在该状态下，检测类型帧，跳转至对应的状态，在对应的状态下，再进行传输长度的获取，当检测到帧尾时，跳转至帧尾状态，然后返回至空闲状态。在前一章节中，就ADC原始数据与FFT幅值数据的计算进行了讲解，在本章节中，需要确定交互协议，涉及到交互协议的解析，交互数据的上传。在下一节中，将介绍如何很具解析出的命令，传输对应的数据，以及保留本帧的频率与最大幅值计算模块。接下来，进行仿真，测试是可以正常进行状态跳转与指令解析。

2024-12-02 21:31:48 908

原创 USB传输ADC数据之ADC与FFT数据准备

在本章节中，笔者将ADC采集的驱动与FFT计算的驱动进行模块统一管理，在上传数据时，初步打算是使用定时上传模式，因为前端的单位时间内数据量是大于USB2.0可以上传的数据量的，并且，高速上传至上位机，对上位机的显示来讲，也是一个很大的负担。在上一章节中，笔者介绍了FT232H的驱动设计，在之后章节会介绍FT232H的上位机开发。ADC采集驱动与FFT计算驱动的整体工作流程图如下所示。

2024-11-28 20:50:56 651

原创 USB传输ADC数据之FT232H驱动设计

首先FT232H拉低RXF#信号，表示FT232H中的FIFO有数据等待读出，当FPGA接收到这个信号时，将OE#信号拉低，使能FT232H的输出，观察时序可知，在OE#拉低的t6时间后，总线开始输出有效数据，这时拉低RD#，即可读取有效数据，注意手册中明确指出OE#拉低压迫至少比RD#拉低提早一个时钟周期，故在程序设计中，将RD#拉低晚于OE#一个时钟周期即可。若此时FPGA侧的FIFO同样有数据进行发送，则拉低WR#,进行数据输出即好，保证WR#与DATA的同步即可，避免数据丢失。

2024-11-23 16:18:32 994

原创 USB传输ADC数据之FFT设计

FFT IP的配置选择输入位宽12位，架构选择流水线计算模式，实时模式，在该配置下，对原始数据进行流水输入，FFT计算结果也会流水输出，并且选择FFT的单次计算长度为2048，对于输入，实时流模式下不需要进行last信号的控制，而输出会在没2048点，拉高一次last信号。输出选择自然顺序，即0~2047即好，如果选择大端序模式，输出的索引需要经过一级环形RAM做处理，将顺序进行转换，在进行单帧谱最大值搜索时，可以使用该模式，还降低了一定资源，这种操作，如果项目有必要时，会进行介绍。

2024-11-23 12:21:31 835 2

原创 USB传输ADC数据之ADC驱动设计

本文中，笔者选择的ADC芯片为AD9238,12bit ADC，其采样时钟支持20 MSPS/40 MSPS/65 MSPS，双通道芯片，CMOS并行输出数据接口，输入电压超量程会有电平指示。其ADC架构框图如下所示。这块ADC的驱动逻辑还是很简单的，单纯的CMOS并口逻辑，不需要做延迟对齐等操作，也不需要SPI配置一类的东西，因为笔者目前只有这块ADC，便以这块adc作为整体工程的前端，后续有机会会更新多种类型的adc。

2024-11-22 21:12:34 523

原创 FPGAS设计SATA之GT收发器配置

3.0协议传输的的一个数据大小为DWORD，即32位数据，故TX与RX的位宽选择32位，编码方式选择8B/10B编码，经过编码后，32位的数据位宽扩展为40位，TX和RX选择同一时钟，勾选Use TXPLLLREFCLK。在前一节，笔者将PHY层Host的状态机跳转逻辑进行了梳理，关于OOB信号的检测，在FPGA设计中是通过GT收发器的配置输出进行检测，故在本节中，对GT收发器的配置进行记录。关于电流均衡，勾选TX的极性矫正，差分控制，预加重，去加重等选项，RX勾选极性矫正。第一页保持默认配置即可。

2024-11-22 10:51:04 533

zy12022000的博客