随着混合语言仿真验证的能力不断增强，跨语言、跨方法的库的可用性越来越高，一般情况下，激励已经能够满足我们的要求了，但是带约束的随机激励仍然仅限制于SystemVerilog testbenches或者混合语言环境（比如混合了SystemC 和SystemVerilog），当把一个SystemVerilog带约束的随机激励模型移植到C或C++抽象算法模型时，还是会出现很多问题。虽然SCV（SystemC Verification）库也支持随机激励和种子管理，但是性能并不理想，需要费力气去维护独立的激励模型，并且激励模型缺乏随机稳定性，所以未被广泛采用。

所以，很多验证工程师想要构建独立于验证语言和方法的激励模型。比如验证工程师在开发最终会合成在HLS(HighLevel Synthesis )流程里的算法时，会有一个很普遍的想法，如果能在纯粹的C环境里进行验证，而且这个环境还包含有随机激励以及功能覆盖率这些高级功能，那该有多好。

所以本文想提供一种适用于C或SystemC验证环境的可移植激励模型。在纯粹的C、SystemC、SystemVerilog UVM testbench或者其他的验证环境中，这样的模型都可以产生可复用的激励。

 C / C ++算法的验证

传统上，纯粹的基于c的验证环境主要是用于检查算法的性能以及对比浮点与定点模型。算法的性能是由变化的设计参数和一些其他的因素决定的，这些都在架构早期就已经确定了，假如起初的C和随后的RTL实现之间能够建立等价关系，就不需要在RTL上对他们重新验证。

可移植的激励模型示例

本文将参照一个基于图表的激励模型，展现这样的一个可移植激励如何适用于各种跨语言跨环境的验证方法。实际上，基于图表的激励并不是很先进的方法，在软件验证上也已有很长的历史了，在硬件验证上也使用有10年了。图表只是一个合法的激励脚本，是独立于任何特定的硬件验证语言和环境的。图表语言是基于类似Backaus-Naur形式的规则进行描述的，将场景的元素合法的包含在序列中，下图就是一个关于规则的示意例程。

描述规则是分层的，并包含三个基本结构：顺序，选择和循环。在下图的图形化结构示例中，可以清晰的明白这些规则的内容，这里展示了do_trans的内部结构。

这个简单的例子描述了基于图表的激励的含义，以及它与传统的UVM sequence/sequence item方法的区别。激励模型的可移植性源于图表中节点独立于任何语言和环境的能力。

为了可以替代SystemVerilog带约束的随机激励，语法规则还必须要结合数字量的申明方法，以及一些特定代数约束。图表例程里的约束可以进行拓展，进而得到包含并行和串行transactions操作的新约束。如下图，在典型的UVM testbench 环境中，该图表模型成为多个虚拟sequences产生的来源，在这种情况下，图表中的数字量和节点成为sequence items的字段，可由sequence item API调用。

上图描述的场景是以太网控制帧后跟一个数据帧，或者以太网控制帧后接着一个IPv4帧。倒梯形的蓝色区域表示不同的路径上变为active状态的新约束。棕色矩形是每个数据结构独立字段的容器。绿色部分是动作节点，表示sequence item API的调用。针对抽象的C testbench，这些数据量和节点会被封装成数据类的成员以及适当的函数，验证环境可以随意调用他们。

将可移植的激励应用于HLS 流程

HLS（High-level Synthesis）的使用越来越广泛，使得纯粹基于C的验证环境迫切需要更先进的验证方法，同时也使能够用于底层验证的可复用激励模型变得更有价值。典型的HLS流程开始于C或C++的算法的执行，这时C或C++是高层次综合工具的输入以及待验证的DUT。HLS流程中，理论上，HLS工具可以基于对算法的分析，综合出激励模型，甚至可以推断出合适的验证目标以及具体的覆盖目标。下图显示了一个可载入系数的FIR滤波器的C方法实现方式。

在代码中可以很容易看到DUT激励模型有许多数据量申明，如fir_filter_ld函数的输入里申明的inp, coeffs , addr和ld。实际上激励使用的数据类型需要被转化成更加通用的形式，这样更便于移植。这个例子中我们随机化时使用了如 rand()之类的函数，并且使用了while或for循环产生输入参数序列。我们可以调整这个testbench，使其更具备UVM结构风格，对参数进行了一些类的封装，得到下图显示的这样一个激励类。

使用这种方式组织C testbench使得一般的激励模型更容易移植用于纯C仿真环境。可移植的激励模型最终都会被用于到具体的场景中，这时候可能会需要执行一些初始化操作，然后循环执行函数输入的一些带约束的设置。如下图的一个FIR滤波器激励模型。

高效的HLS验证流程

下图显示了将验证的各种元素加到一起的HLS验证流程。

为了能有较佳的性能和自动化水平，按照预想的流程实现验证，这里需要做到：

1.能产生激励模型，由HLS工具初始化覆盖率目标

2.能够跨验证语言，复用激励模型和参考结果

3.能够跨验证环境，完成覆盖率结果的合并

结论及未来的应用展望

这个方法的最主要优点在于，对于同一设计，其激励模型的可移植性极高，验证工程师可以专注于更抽象层次的验证目标，然后在恰当的底层采用相同的激励去完成具体的细节验证。总的来说，可移植的激励模型的复用，能优化验证流程，提高整体的项目生产率。

此外，指标驱动验证的概念，已经在RTL域建立和成熟，正扩展到ESL（electronic system level）级，这会提供让设计和验证都更效率。而激励模型本身可以在ESL级得到完全的验证，验证工程师不需要为用于低抽象层次的testbenche重写或者转化激励模型，只用根据低抽象层次的具体要求，再细化定义ESL激励模型。所以，可移植的激励模型的应用空间还很大。

感谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。