tcp硬件校验和rx&tx开启是啥意思_UDP/IP硬件协议栈设计(九):仿真
![2e224309b57df88b4336ce096addd2e3.png](https://img-blog.csdnimg.cn/img_convert/2e224309b57df88b4336ce096addd2e3.png)
对于仿真没啥好说的
因为还未学习验证相关的知识
只会写一些简单的仿真用的testbeach
所以简单分享下还凑活的仿真吧
![05e304b505d9370a34f1e3248b2c786a.png](https://img-blog.csdnimg.cn/img_convert/05e304b505d9370a34f1e3248b2c786a.png)
仿真前先得知道这个弟弟协议栈做了个啥东西
前面八篇文章基本就完成四件事:
- 接收ARP请求帧并给予应答;
- 接收ICMP回显请求并给予应答;
- 接收UDP帧解析得到数据向用户端送;
- 收到来自用户端的数据使用UDP协议进行发送;
所以,仿真也就要完成这四件事情
- 构造ARP请求给协议栈并等待其应答;
- 构造ICMP回显请求给协议栈并等待其应答;
- 构造UDP帧给协议栈观察其是否可解析送给用户端;
- 构造用户数据给协议栈等待其采用UDP协议发送出来;
写个TB来产生这些数据看看弟弟协议栈是否能够工作
对于ARP/ICMP/UDP的组成这里不再多说,笔者直接采用Task方式完成各数据报文的生成,直接上代码(见下面附1)。
来,发包吧!
笔者直接调用上述的Task发送一帧ARP请求帧、一帧ICMP回显请求帧和2帧的UDP帧,其中用户端的接口直接接收和发送直连(内部回环),仿真结果如下图所示:
![9735b8d8fc73924ea5aecf1372991aa4.png](https://img-blog.csdnimg.cn/img_convert/9735b8d8fc73924ea5aecf1372991aa4.png)
emmmmm,似乎密密麻麻的波形对眼睛不大友好,况且也根本不知道构造的数据报文和接收到的数据报文是否一致。
这么长的波形看不清可以试试别的方法打开
- 对发送和接收的报文直接转成TXT文本?
于是在TB里写了如下代码,即将协议栈接收的数据帧和发送的数据帧(不包括前导码/FCS)写入TXT中:
integer
输入一帧ARP帧,仿真结果和得到的TXT如下:
![3edcdeee1647474260c1c552c11adc03.png](https://img-blog.csdnimg.cn/img_convert/3edcdeee1647474260c1c552c11adc03.png)
似乎直接观察TXT文本里的数据也看不出啥东西,还是得手动按照帧格式去观察得到各字段,才能知道该帧是什么。
- 我能像使用wireshark一样一目了然数据帧吗?
答案是可以的,wireshark提供了text2pcap工具,就是将TXT文本格式的数据转为pcap格式的数据。
不过该工具对TXT文本格式的内容有要求,如下所示:
![744849f6f7eaa497e77851950202d9b2.png](https://img-blog.csdnimg.cn/img_convert/744849f6f7eaa497e77851950202d9b2.png)
格式要求即:
- 每行开头有个16进制、4字节的偏移量,“00000000”表示该行从0字节起始,相应第二行"00000010"表示该行从第16字节开始;
- 每行的数据从左开始,最多有16个字节的数据,末尾行不足16字节的,左边对齐;
然后在新建批处理脚本gen_pcap.bat并输入:
![787aa9e819af7e0f1861f414e6368ba6.png](https://img-blog.csdnimg.cn/img_convert/787aa9e819af7e0f1861f414e6368ba6.png)
其中,"c:/Program Files/Wireshark/text2pcap.exe"即为text2pcap工具的路径(在wireshark安装目录下),“rx_data_0.txt”为当前目录下的txt格式的数据,“data_0.pcap”为在当前目录下需转为的pcap格式的数据,然后运行gen_pcap.bat即可得到一个pcap格式的文件,使用wireshark打开结果如下:
![db254cb228c4fd812f7eecf9d442e3c6.png](https://img-blog.csdnimg.cn/img_convert/db254cb228c4fd812f7eecf9d442e3c6.png)
由上图可以清楚的看到,这是ARP的请求帧,这就大大减轻了仿真的时间。
由上操作过程可以分别得到接收端和发送端的pcap包,但似乎还是不够,因为只是分别得到,而不是在同一个pcap包下观察接受和发送的报文。
这时,wireshark又提供了另一个工具mergecap,即将多个pcap包合成一个,于是再在gen_pcap.bat中加入一行指令如下:
![334ed08f8e21b7e32d8452f41a86a145.png](https://img-blog.csdnimg.cn/img_convert/334ed08f8e21b7e32d8452f41a86a145.png)
其中:“-a”表示按文件顺序合并,“-w”表示写入pcap文件,“all_data.pcap”为合并后的pcap包,“data_0.pcap”和“data_1.pcap”为两个待合并的pcap包。
再次运行gen_pcap.bat即可得到如下文件:
![3f3eb58c782ac53555708b2e3cdaa432.png](https://img-blog.csdnimg.cn/img_convert/3f3eb58c782ac53555708b2e3cdaa432.png)
此外,在txt中,首行可以加入时间戳,即如下所示:
![c7f145a5a99518974a4b64577ddcf97f.png](https://img-blog.csdnimg.cn/img_convert/c7f145a5a99518974a4b64577ddcf97f.png)
其中时间戳格式为"H:M:S",即“0:0:12.761000”表示为0时0分12.761000秒的数据帧,对于如何在TB中写入时间戳,可参见附2源码,此外,为实现这一操作还需在.bat命令中加入如下内容:
![63e2d0818aa5d198daa25b1cf7279e47.png](https://img-blog.csdnimg.cn/img_convert/63e2d0818aa5d198daa25b1cf7279e47.png)
加入时间戳的好处是,生成得到的pcap报文会有相应的时间戳表示,可以更清楚的观察到接收和发送的时间,如下所示:
![29a42f156401eace5af4453578c9a789.png](https://img-blog.csdnimg.cn/img_convert/29a42f156401eace5af4453578c9a789.png)
总结一下
为验证写的协议栈是否正确,本文进行了一系列的操作:
- 编写ARP/ICMP/UDP的task,产生相应的数据帧;
- 将输入协议栈和输出协议栈的数据帧写成txt本文格式,并转成pcap格式,方便观察;
最后,笔者再回到最开始的测试过程,即调用上述的Task发送一帧ARP请求帧、一帧ICMP回显请求帧和2帧的UDP帧,然后通过wireshark来直接观察最后的仿真结果如下:
![ab7609830e295678f1bd289457ef80c0.png](https://img-blog.csdnimg.cn/img_convert/ab7609830e295678f1bd289457ef80c0.png)
一顿操作后,可算是实现理想中的仿真结果了!
最后,从仿真结果看,似乎没啥大问题了,就是为了验证校验正确导致延迟太长(自行优化吧),此外发现如果全部采用system verilog来写TB的话可能会更好点,不过先这样凑活下吧,之后就是见证奇迹的上板测试了。
如有不足之处还望批评指正!
十二点过九分:UDP/IP硬件协议栈设计(十):测试zhuanlan.zhihu.com
![c725fbdb62551a42e6aea32782e24dd4.png](https://img-blog.csdnimg.cn/img_convert/c725fbdb62551a42e6aea32782e24dd4.png)
附1-三个TASK源码:
task
附2-TB中写TXT本文:
//---------------------print TXT------------------------