一种基于UVM的网络协议报文发包器

王潇枫

（南京邮电大学，江苏南京 210023）

0.引言

随着超大规模集成电路功能的日趋丰富，尤其在当前的热点方向如5G、AI、工业4.0等，更高性能、更快速度、更多功能、更低功耗成为芯片设计制造商的追求目标。随之而来对于验证工作的挑战在不断增大，验证的工作量已经占到整个SOC研发的70%左右，因此提高芯片验证工作的效率也成为了研发流程中的重要一环[1]。作为以太网芯片中必不可少的功能点，报文解析及处理是验证对象中不可或缺的重要组成部分。而对于报文解析及处理的验证工作，网络协议报文发包器是必不可少的验证组件，它作为验证用例激励的约束与生成组件，是用例能精确覆盖各功能点的基础与核心。一个全面且实用的发包器组件不仅能实现对各协议字段的约束、报文的生成和封装，同时也能具备对协议报文字段的解析功能。除此之外，优秀的验证组件还要具备良好的复用性与即插即用的特点，即不需要配合验证平台结构做组件结构上的修改，能简洁高效地运用于仿真场景构建中。

1.UVM方法学

针对传统RTL（寄存器传输级）验证平台重用性差、自动化程度低等缺陷，Accellera标准组织采用OVM为标准，在此基础之上推出了新一代的基于系统及硬件描述语言System Verilog的通用验证方法学UVM，并于2011年推出了UVM的正式版本。UVM完全继承了OVM，同时采纳了VMM中的RAL、Callback机制等，为验证工程师建立了一套基于面向对象思想的System Verilog语言标准组件库，提高了验证环境的重用性与灵活性[2]。

如图1所示，UVM采用树形结构构建自顶向下的验证平台。各结点按照既定层次关系实现验证平台的整体功能[3]，具体组件包含：

图1 UVM树形结构图

（1）Driver：是验证平台最基本的组件以及数据流的源泉，将激励驱动至RTL逻辑；本设计中，他将实现将发包器生成的激励按约束封装成数据流驱动至DUT引脚或内部接口；（2）Sequencer：是Driver与Sequence间沟通的仲裁方，实现transaction的传递；（3）Monitor：监测DUT的行为及信号变化；（4）Scoreboard：比对Monitor采样的DUT输出结果与Reference Model模拟的预期输出；（5）Reference Model：完成与DUT相同的功能设计并输出结果与DUT输出相比较；（6）Agent：将处理相同协议的driver与monitor封装为更高一层的抽象组件[4]，便于验证平台的复用性与环境管理；（7）Env：引入容器类概念，将Agent例化于Env中，并实现各Agent中组件的通信链接；针对不同验证层次使用不同的容器类Env，增加了验证平台的复用性，便于验证工作的管理与平台维护。

2.发包器设计

发包器设计结构图2所示。

图2 发包器设计结构图

2.1 发包器层次结构

基于UVM自顶向下层次逻辑，发包器由3大组成部分构成——报文生成组件frame_tools、流量控制组件flow_tools、相关工具算法组件svlib。

2.1.1 Frame_tools

Frame_tools组件包含了两大基类：

（1）frame_tools_item。发包器核心基类，由该类中定义的parse、generate函数实现报文字段解析与数据流生成，其包含了frame_tools_head与frame_tools_payload两大子类。

frame_tools_head为报文首部类，其包含了L2层协议首部类frame_tools_head_l2_ethernet、frame_tools_head_l2_llc、frame_tools_head_l2_llc_snap，并通过自定义枚举类型frame_tools_protocol_t引导L2层首部使用何种协议格式。由此向内递进，在L2层各协议首部类中，包含了L3层协议首部类frame_tools_head_l3_ipv4、frame_tools_head_l3_ipv6、frame_tools_head_l3_pppoe等，并通过自定义枚举类型frame_tools_protocol_t引导L3层首部使用何种协议格式。在L3层中衍生出L4层首部协议字段，由此生成报文首部字段。

而frame_tools_payload为报文负载字段类，其包含负载内容子类frame_tools_payload_value，以及报文信息子类frame_tools_payload_info。负载内容子类frame_tools_payload_value可以依据自定义枚举类型frame_tools_payload_value_mode_e的约束生成递增、递减、随机、规定值字节序列；报文信息子类中包含数据流号、port号、报文id以及fcs校验位。

headlib中存放了自uvm_sequence_item派生的L2至L4各种协议报文首部字段类。若需根据自定义协议构建新首部格式，需要在headlib中放入自定义首部字段类的System Verilog文件，并针对对应类型的报文，在frame_tools_head_defines文件中增添对应报文类型名称的frame_tools_protocol_t类枚举元素。而frame_tools_head_defines文件中不仅定义了枚举类型frame_tools_protocol_t，还封装了多层次各种不同类型报文的宏定义，根据不同类型协议约束各种报文各层次首部字段的protocol_next指针，以实现由L2向L3、L4的帧首部字段嵌套。这些宏定义将在发包器调用时约束报文类型，并指导各字段的内容的封装。

（2）frame_tools_sequence。该sequence采用参数化定义方式，由本发包器设计中frame_tools_sequence_defines文件封装于宏中，在该文件内，由宏定义实现了发包器的调用方式，以宏FRAME_TOOLS_SEQ_BASE_BEGIN、FRAME_TOOLS_SEQ_BASE_END限定了发包器sequence生成框架，同时宏FRAME_TOOLS_SEQ_BASE_BEGIN在调用时将传入sequence定义所需参数seq_name、总数据流数stream_total、sequence推送时间drop_us。同时还定义了参数化类frame_tools_sequence_lib，此类由frame_tools_sequence_library.svh文件中定义的frame_tools_sequence_library类派生，该类定义了一些对sequence的操作与绑定task。

宏FRAME_TOOLS_SEQ_BASE_BEGIN内调用数据流启动宏FRAME_TOOLS_SEQ_STREAM_DO。该宏内封装了数据流控制宏FRAME_TOOLS_SEQ_STREAM_BEGIN，其调用 flow_tools中流量启动函数starting并传入发包数量pkt_num参数，并启动`uvm_create函数实例化transaction；调用FRAME_TOOLS_SEQ_STREAM_END宏，通过例化的frame_tools_item类中的generat函数生成数据流queue。调用 flow_tools中流控函数check_credit并将item中报文长度传入其中，以调整帧间隔，实现流量控制，而后启动`uvm_send函数将sequence发出，最后调用 flow_tools中停止函数stopping结束流量监控。

2.1.2 Flow_tools

（1） flow_tools_monitor。包含 starting()，stopping()两个控制task。starting()中例化一monitor process，调用速率计算函数rate_calculate()可计算周期流量及整体流量，并可以实时打印出流量数据；stopping()中关闭monitor process。（2） flow_tools_driver。该driver同样包含starting()，stopping()2个控制task。starting()中例化一drive process，调用rate_calculate()函数做时钟周期性计数，并配合credit_add()函数累计。累计参数供check_credit()函数实时检查，由frame_tools在sequence生成完后调用，以调整帧间隔。

2.1.3 Svlib

Svlib中包含math_lib、pack_lib。其中math_lib中定义了报文生成中所需的例如CRC-32算法的计算函数；pack_lib中则定义了一些例如bit位倒序、多字节对齐等函数。

2.2 使用方法

在使用该发包器生成报文时首先需在用例中调用宏FRAME_TOOLS_SEQ_BASE_BEGIN、FRAME_TOOLS_SEQ_BASE_END以生成发包器整体框架，并输入数据流参数seq_name、总数据流数stream_total、sequence推送时间drop_us。其次，需根据数据流数以及对数据流的定制化约束，调用数据流控制宏FRAME_TOOLS_SEQ_STREAM_DO，传入发包数量pkt_num，并由上文中对head_defines文件的介绍，调用报文类型宏定义，以约束报文类型，并根据其类型填写各字段内容。

3.结语

在验证领域，高效性和复用性是评判一个组件实用程度的重要指标。本文提出的基于UVM的网络协议报文发包器，从使用灵活度以及可定制化程度均体现了高效、可复用性，能够对网络数据报文解析与处理功能的验证起到较好的辅助作用，提高验证效率。