随着集成电路的快速发展，数字集成电路（Integrated Circuits, IC）设计的复杂度越来越高，其功能验证也变得更具有挑战性。验证工作量占整个芯片开发工作量的70%～80%
[1-2] 。传统的Verilog验证通常基于定向测试，更适用于功能和结构相对简单的硬件设计，因此无法满足当前场景多样化的验证需求。通用验证方法学（Universal Verification Methodology, UVM）是一种标准的、基于SystemVerilog的验证方法学，提供了一致的验证框架，提高了验证环境的可维护性和可扩展性
[3-4]。由于UVM通用验证方法学的标准化和结构化的验证特点，能够适应不同规模和类型的芯片设计，成为目前主流的芯片验证方法，具备非常广泛的应用潜力
[5]。
2019年，文献[
6]讨论了SHA-256和MD5两种哈希函数，其研究方向只针对这两种哈希函数搭建UVM验证平台对其进行验证，并没有涉及通过哈希函数改进验证平台的讨论。同样文献[
7] X对SHA-256算法进行了分析，仅仅是把SHA-256算法作为一个IP核，并使用UVM验证平台对其设计进行了验证。文献[
8]提出在硬件中实现哈希函数，讨论并使用数学方程式描述了哈希函数的各个阶段。文献[
9]探究了UVM验证平台中不同的参考模型对验证时间和内存消耗的影响。综上所述，现阶段的研究缺少利用哈希算法的特性与优势去改造或提升UVM验证平台的效率。
在构建协议转换的验证平台中，增加了一个单独用于建表和查表的组件，旨在利用布谷鸟哈希算法的优势，实现不同协议转换的场景下快速查表映射，降低UVM验证平台的设计难度，提高验证效率。在此过程中，采集功能覆盖组确保足够的覆盖范围。
1 验证平台总体框架
搭建验证平台需要验证人员一定程度上了解待测设计的内部逻辑，这有助于设计更全面的测试用例。本节先介绍待测设计的结构和功能实现流程，最后介绍验证平台的总体框架、组件功能及关键特性。
1.1 异构协议转换模块
异构协议转换在计算机通信网络中可以将一个协议的数据格式转换为另一个协议的数据格式，实现不同协议之间的互操作性或兼容性
[10-11]。协议转换模块是交换芯片的核心，负责各个不同协议的包级转换，如
图1所示，异构协议转换模块在芯片中以独立交换端口的形态存在，负责全芯片各端口之间的统一协议转换。
整个交换芯片的端口可以连接不同协议端点设备，路由信息通过协议数据交换中心时，如果目的端口的协议类型与源端口的协议类型不同，数据帧就需要通过协议转换模块进行协议格式转换，再转发到目的端口，实现不同协议的互连互通。如
图2所示，协议转换模块主要用于实现Etherent UDP、FC-AE-ASM、PCIE Mwr和RapidIO 这4种协议类型中任意2种协议之间的逐包级实时线速转换，在全芯片中起着关键作用。
根据协议包中源、目的端口信息，以及全局寄存器中源、目的端口对应的协议类型等信息提取出协议转换所需要的包头字段和包净荷。通过协议转换引擎查找协议转换表获取转换后的对应字段，完成协议转换过程必要的包头替换，形成新的协议包头。根据新的协议包头和BUFFER内的包净荷组成新的协议包，最后再输出至协议数据交换中心进行后续协议处理。主要包括RX、slice、TX模块，具体功能如下。
1）RX模块。通过提取包头有效信息，同时将数据进行去包头处理后，数据帧头交由3级slice处理，负载则发送到BUFFER中供后续TX模块组包。
2）slice模块。3级slice结构基本相同，每级silce因存在查表键值的提取方式和表项消化方式不同而有所差别。第1级slice通过哈希键值（Hash_Key）查询哈希表得到一个会话号（Session_ID），并通过Session_ID查询协议header表得到一个新的报文头高位和报文头长度。同样第2 级与第3 级slice也需要利用Session_ID查询到新报文头的SOF、EOF、SEQ_ID和SEQ_CNT等其他字段的信息。
3）TX模块。主要处理最后1级silce发送过来的新的报文头，最后将包头和BUFFER中读取的包负载进行封装后发送到数据协议交换中心。
1.2 验证平台总体框架
针对协议转换模块所搭建的UVM验证平台总体框架如
图3所示，采用层次划分。由于异构协议之间的冗余度较大，且对设计模块稳定性要求较高的特点，在激励源的选择上定义4种类型报文ITEM，包括ETH、FC、SRIO和PCIe。分别由4个sequence管理对应的item，产生每种报文内部需要的特殊字段值，并用Virtual_aqr统一管理各个sequence。在激励产生之后，除了要通过总线发送到硬件设计，同时还需要将激励发送至参考模型（Ref_Model）1份，以供验证平台自身做预期使用。平台产生的激励都需要与哈希匹配表的表项和寄存器配置绑定，以此确定发送报文的数量和类型。
验证平台整体架构使用UVM验证方法学搭建，各个组件功能与通用验证平台的组件基本一致，以下是对验证平台各个组件的描述。
1）env是验证平台的整体验证环境，包括一些公共信号的定义与连接，env下面例化了rx_agent、tx_agent、hash_tbl_gen、env_config、apb_agent、Ref_Model和Scoreboard等组件。
2）env_config完成对验证环境的整体配置。包括源协议与目的协议端口的配置和协议类型配置。
3）tx_agent是active agent发送激励。模拟被测器件（Design Under Test, DUT）的输入端硬件设备的行为，发送验证所需的输入激励，同时采集输入激励发送至Ref_model。tx_agent下面例化了sequencer、driver和monitor等组件。其中driver接受来自sequencer的事务，然后将这些事务信号转化为DUT可读取的序列信号或者协议数据包，并通过总线驱动到DUT里。monitor负责捕获和分析接口数据。
4）rx_agengt是passive agent，进行信号采集工作。模拟DUT的输出端硬件设备行为，主要功能是采集DUT输出的处理结果，同时将输出结果发送至Scoreboard。
5）Ref_Model为验证中的参考模型，实现DUT相同的功能和模拟DUT的行为，根据输入的报文类型和用户指定的报文转换类型，产生相应的报文输出。
6）Scoreboard是计分板，提供比较函数，分别从Ref_model和rx_agent中获取报文，比对DUT的输出结果和Ref_model的输出结果，结果一致则说明DUT功能正确，当发现结果不一致时，则说明DUT功能是有缺陷的或者参考模型等有缺陷，同时产生错误报告，反馈给验证和设计人员进行论证修改。
7）hash_tbl_gen直接继承uvm_component组件，完成哈希匹配表和协议header表的建立，并与测试用例发送的激励绑定。
在UVM验证环境中采用了一种树形结构来管理验证平台中的各个组件，如sequencer、driver、monitor、Ref_model、Scoreboard、env等都是树的1个结点。如
图4所示是验证平台的树形结构。UVM树形结构的设计范式使得验证平台能够管理自己之下的所有组件统一步伐做事情，促使了每个组件都可以被视为独立的单元，实现了各个组件的可复用性。
验证平台主体框架是在硬件设计和验证方案的基础之上做出的一种架构选择，换言之，验证平台与硬件设计密不可分且有着诸多的相似点
[4,12]，如下是对验证平台的关键特性的描述。
1）平台中支持通路自动比对，包括支持协议转换后的目的协议以及响应包等对比。
2）支持最大1 024 个会话数。其中4种协议的各个session可以灵活配置，便于平台中约束一定数量的会话ID。
3）支持后门操作。由于协议转换模块中涉及的Memory种类和数量较多，若全部采用前门配置操作，则会耗费较多的仿真时间，支持从文本文件中导入存储器的后门配置操作。
4）支持功能覆盖率和代码覆盖率收集。
2 哈希匹配表的设计与实现
2.1 哈希匹配表的重要性
根据协议转换模块的功能，3级slice中的后2级都需要通过第1 级输出的Session_ID进行查表来获取新报文头的大部分特殊字段值，因而第1级slice中的哈希匹配表尤为关键。
对用户而言，在实现协议转换时，用户给出协议包的包头必须和哈希匹配表绑定，就需要通过软件定义把相关的哈希匹配表和报文header表提前配置好。
从验证人员的角度看，所有的用户应用场景都需要通过验证平台来模拟实现，包括将平台产生的激励与哈希匹配绑定，然而4种异构协议之间的冗余度较大，如果针对每个协议单独建表，验证平台则会显得非常臃肿，增加了验证平台的设计难度。为了降低验证平台的搭建成本，提高验证平台的搭建效率，提出将建表过程单独作为1个组件，例化在env下面。依据协议转换模块的功能点和4种协议的帧头格式建立了与激励绑定的匹配表，并通过利用布谷鸟哈希算法进行建表，因此也称其为哈希匹配表。具体来说，首先建立3张哈希表，并根据不同协议转换场景提取关键值，然后利用布谷鸟哈希算法实现离线哈希无冲突建表。之后根据哈希键值来查找本次协议转换的会话ID，确定需要调用的协议包头字段达到协议映射的目的。
2.2 布谷鸟哈希算法
哈希表（Hash Table）是网络报文进行流量管理的关键数据结构，哈希表基于报文关键字，利用哈希函数可以访问存储键值所映射的索引信息，能有效提高建表效率
[13-14]。
布谷鸟哈希（Cuckoo hashing）最早是为了解决哈希冲突问题，其特点是占用空间少、查询速度快
[15]。其建表的基本思想是建立
d（
d≥2）个哈希表，每个哈希表对应1个哈希函数。根据
d个哈希函数，为每1个键值设定了相应的哈希表存储位置，以保证这个键值可以被存储在
d个可能的地址中的任意1个。在进行查找时，每次只需要查询
d个候选地址即可。当然，在进行插入操作时，如果发生地址冲突则可能需要移动大量已有表项的位置来重新组织表项，直到冲突消除
[16]。布谷鸟哈希算法通过探测更多的候选位置，总能在确定的时间内完成查询操作。算法步骤简述如下：分别使用HashA、HashB计算对应的键值，查看其位置是否为空，如
图5所示。
1） 2个位置均为空，则任选1个插入；
2） 2个位置中有1个为空，则插入到那个空位置；
3） 2个位置均不为空，则随机踢出1个位置的Key，然后插入到踢出后的位置，被踢出的Key值再执行步骤1）找到另1个位置，循环直到1个空位置并插入成功；
4） 如果被踢出的次数达到事先约定的最大阈值，则认为插入失败，需要重新哈希。
2.3 表项设计与实现
依据协议转换模块的功能和平台验证需求，每个哈希表项的数据结构如
图6所示，表项深度为512，宽度为203位，包含1 bit的有效位、10 bit的Session_ID和192 bit的哈希键值。
在进行哈希建表或查询时，192 bit的哈希键值是作为哈希函数的输入值，哈希地址则会插入对应的Session_ID。哈希键值取决于4种原协议的包格式中能够唯一表征一对端点的特征，针对每种协议的关键字段的不同含义，采用192 bit位宽，各个协议的键值具体位域如
图7所示。Src_type表示原协议类型，Tgt_type表示目的协议类型。一般情况下在验证过程中二者的值是不相同的。
布谷鸟哈希算法的查询非常简单，即使在最坏的情况下也能够保证在固定的时间内完成查询操作
[13]。
根据验证平台的特性最大支持1 024会话数，为保证哈希无冲突建表，采用3个哈希表实现对键值的哈希插入与查找，3个哈希表分别对应3个哈希函数，每个哈希表包含512个条目，3个哈希表对应1 536个条目，空间里利用率为66.7%。每个哈希表的大小是203 bit×512，每1个条目的位宽是203 bit={1’b1, Session_ID, Key_value}，其中Session_ID为10 bit，Key_value为192 bit。如
图8所示，验证平台在初始化阶段会进行离线建表，根据仿真随机测试验证，最大迭代次数设置为30可保证无冲突建表。
查表根据输入的192 bit键值，通过3个哈希函数计算得到3个哈希值作为哈希表的存储地址，分别提取这3个哈希表的存储地址192 bit的哈希键值与输入的192 bit的Key值进行比较，只要有1个存储表项的值与之相等，说明Hash查表匹配成功，从而可获得该查表的Session_ID。如果3个存储地址所存储的表项哈希键值都与输入的192 bit的Key值不相等，说明查表失败，这时就需要上报此事件。
无论是建表还是查表，计算CRC函数的结果得到访问哈希表的存储地址是设计实现首先需要解决的问题。3个哈希函数对应采取3组CRC多项式计算得到CRC校验值。因为每个哈希表的条目为512，因此取运算结果的最低9位，即CRC[8:0]作为哈希表的存储地址。在验证平台中，CRC采用并行运算以匹配硬件设计提高计算速度，具体则选择采用异或操作实现这种并行计算。下面是3 组CRC多项式的表达式。
CRC0对应的多项式：；
CRC1对应的多项式：；
CRC2对应的多项式：。
在协议转换模块中，每次协议转换都有对应的Session_ID，因此验证平台也会根据Session_ID分析源协议与目的协议的包头对应字段的含义，提取出相应的字段组成1个192 bit哈希键值，并与Session_ID一同组成哈希匹配表；同时验证人员要在平台发送激励前，完成哈希匹配表的建立并发送至DUT，帮助DUT完成表项配置。
3 验证结果与分析
验证平台搭建完成后进行仿真验证，根据输出的波形图和日志分析工具，比对参考模型和DUT的输出结果，并查看覆盖率和测试用例的通过率，确保验证的完备性
[17]。
3.1 测试用例设计
验证过程的首要工作是构造多样化的测试用例以覆盖不同的应用场景，确保测试用例能够覆盖DUT所有的功能，包括正常操作、关键特性、特殊场景和可能的故障模式
[18]。为验证所提出的生成哈希匹配表组件的有效性，在设计一系列正常的协议转换的场景基础上，单独构造了哈希查找失败场景的测试用例。
使用VCS和Verdi工具对不同测试用例进行仿真。根据验证平台中Scoreboard组件进行结果判断，所有的测试用例都会通过仿真日志显示比对结果；其次，通过波形文件进一步结果检查和比对，确保设计中相应的功能点的准确实现。
表1展示了部分测试用例及其仿真状态。
3.2 波形图分析
分析波形可以获得硬件设计内部行为的关键信息
[19]，如信号状态、数据传输和时序关系等，因此在一定程度上仿真波形也成了评估模块功能的重要基础，下面以测试用例tc_unicast_udp_to_fc和tc_udp_to_fc_match_fail为例进行分析。
在tc_unicast_udp_to_fc中将源协议设置为Etherent UDP，将目的端口设置为FC协议设备，发送1 000个负载长度为14~20 000 byte不等的UDP源协议包。
图9是Etherent UDP协议包转FC-AE-ASM协议包成功的波形图。sw_tx0端是UDP协议端口，sw_rx0端是FC-AE-ASM协议端；sop和eop分别表示报文的第1个与最后1个字节的数据，keep信号值表示协议数据data的有效值。
如
图10所示哈希匹配表查表成功。Search_valid信号拉高表示哈希键值search_key有效且开始进行查表操作。hash_search_addr代表哈希地址，存储着协议转换的会话号，当hash_search_valid拉高且hash_search_addr有值时，表示哈希查找成功。当输入的数据包从包头提取的Key值与哈希匹配表中存储的hash_key不匹配时，即hash_search_fail拉高且hash_search_addr无值时，哈希查找失败。Key值也会被记录到hash_search_fail_cont中,用于定位问题和调试，如
图11所示。
3.3 覆盖率统计与分析
覆盖率是衡量RTL代码是否被充分验证的1个重要指标，如
图12所示，只有同时达到高的代码覆盖率和功能覆盖率才具有测试的完备性
[20] 。通过自动执行回归测试用例，总共212个测试用例验证全部通过。完成回归测试后查看覆盖率，包括代码覆盖率评估和功能覆盖率评估。
1）代码覆盖率。该模块总代码覆盖率为100%，其中包括行覆盖率、反转覆盖率、分支覆盖率和条件覆盖率。从不同的角度评估测量代码的执行情况，如
图13所示。可以看出，代码覆盖率达到100%，实现了完全覆盖。
2）功能覆盖率。代码覆盖率100%，但并不能完全证明验证的充分性，代码覆盖率仅反映当前代码执行情况，并不能保证DUT功能点或其对应的功能正常运行。为全面评估，收集功能覆盖率格外重要，功能覆盖率的收集需要依据待测功能点定义功能覆盖组和样本采集点。如
图14所示，功能覆盖率100%表明验证覆盖了不同的配置场景。
从多个指标来看，构建的UVM验证平台实现了良好的验证完整性，通过收集不同类型的覆盖率范围监测验证的进度与完备性。此外，整个验证平台具有很高的可重用性，这不仅归功于SystemVerilog和UVM的固有优势，也归功于对验证平台的优化。因此，所提出的测试平台更容易在更高级别的验证平台中重用。
4 结束语
芯片验证时间占据芯片研发周期的三分之二甚至更多，在保证验证质量的同时提高验证速度具有重要意义。针对该协议转换模块的功能和4种异构协议之间的冗余度，在传统UVM验证框架的基础上提出了将建立匹配表的过程单独作为1个平台组件，波形图与覆盖率统计结果也表明这个验证平台能够完全实现对DUT的功能验证，同时哈希匹配表的建立也降低了验证平台的设计难度和搭建成本，减少了验证人员的工作量。后期研究着重考虑，如何优化验证平台的参考模型和计分板来进一步提高功能验证的效率。
京公网安备11010202008535号
PDF
(4548KB)
