rockeric.com
如果读者习惯看段落清晰的论文结构，恐怕会很容易遗落这篇论文。来自Vtool公司的Djuro Grubor针对数据流设计在验证环境复用性方面，尤其是scoreboard复用性上面有自己的一套完整见解。从国内目前的IC设计产品领域分布来看，通信（~40%）依然是最大的部分，而通信类的SoC设计验证经常会跟数据流设计（data stream）紧密相关。这篇文章《Verification strategy for pipeline type of design》虽然段落切分有待提高（显然就是钢铁直男型工程师的风格），但其一套完整的想法和经验，还是值得针对该论文写一篇分析的。
另外说一句Vtool这家公司，这是一家才成立不久的EDA初创公司，如他们所宣称的“Smart Verification”，他们这两年很积极地在DVCon Europe/US/China发表文章，定制展位宣传他们的EDA工具。在DVCon2018 China，他们还对他们的工具（Cogita）做了宣传，这个工具可以根据仿真的log信息生成可视化的数据，可以用来分析性能和调试，也同昨天的文章谈到，在弥补verification 3.0 （Verification 3.0 你准备好了么？）的缺口上，一些小公司会有他们的机会窗口。
这篇论文的思路也是切割数据流设计，将其分为各个子模块。每个子模块，按照独立的设计，为其建立模型，包括命令接口，数据接口，外部存储读写，寄存器模块。在大致建立好这样的模型以后，数据流的模块之间的硬件连接，也可以在验证环境中得到一致的映射，这种思路也是这篇论文主要讨论的。相信不少verifier在处理数据流模块验证的过程中，也是按照类似于这篇论文的方法，只是这篇论文提出了一个理论原型，供大家参考，同时也指出了这种方法在具体实现中需要注意的地方。
在抽象数据流系统中的每个子模块sub_core时，读者可以结合后续代码来理解验证环境中对每个子模块的建模方式：
- 每个子模块sub_core都由一个uvm_component构成
- 相邻两级的sub_core通过uvm_tlm_fifo完成通信
- 内置寄存器模型
- 内置行为模型通过获取上一级uvm_tlm_fifo获取数据，结合指令进行行为数据预测
- 内置比较器comparer，用来比较外部存储的数据读写
- 行为模型将预期数据写出到下一级的uvm_tltm_fifo
类似于sub_core1的这种模型构建起来以后，每一个模型都可以对应设计中的一个子模块，做数据预测和检查。而在顶层集成时，也可以利用组件之间的缓存uvm_tlm_fifo做通信。
在顶层时的集成环境就如下图，比如sub_comp_{0,1,2,3,4}原本是各个设计模块的验证环境，既做predictor(reference model)，也内置comparer做必要的数据检查，而在顶层集成时，依赖于中间的数据缓存完成通信。
这篇文章有一些讨论的细节值得注意：
- 验证组件sub_core之间的tlm_fifo是为了模拟数据的同步和缓存。
- 将指令端口和数据端口可以进行拆分，内置的predictor在完成数据预测后，可以同时启动内置的数据比对，数据比对可以发生在设计与外部存储发生数据读写时触发数据比对。
- 整个验证环境尽量将设计按照黑盒方式来验证，也就是尽量降低监测设计的内部信号，比如状态机、寄存器、开关等信号，交由存储器模型和predictor来完成。也就是说，图2中各个sub_core之间的连接完全模拟硬件之间的流水线集成方式。
- 至于当设计模块访问外部存储时，这将由外部存储接口的monitor保持监测和广播，即bus monitor的analysis_port会广播连接到各个sub_core组件的analysis_imp端口。sub_core通过write()方法监测到外部存储的访问行为，继而得到外部数据，再结合寄存器配置和指令，进行数据预测和更新。
- 由于同一个存储的不同存储空间可能会映射到不同的设计访问地址段，所以在每个sub_core组件write()方法中也该设置地址过滤，确保捕捉到的transaction与自身有关。
- 某些sub_core可以访问多个外部存储，也存在同一个时间有多个sub_core访问同一个外部存储。为了避免死锁和互锁的情况，可以使用semaphore来模拟该种数据访问。
- 指令或者数据都可能bypass某些组件，那么可以在该组件中实现bypass的功能，例如当寄存器或者指令中包含bypass指令时，可以不做数据读写存储的预测，直接由上一级tlm_fifo取得数据，继续交由下一级tlm_fifo处理。
- 各个sub_core组件都有独立的时钟、复位和电源开关信号，例如独立的复位信号可以对单独的sub_core进行寄存器复位、tlm_fifo刷新等功能。
- 顶层环境的scoreboard可以实例化上述各个sub_core组件和tlm_fifo，并且完成连接和最终整体的数据比对。
这种通用的参考模型有哪些优势呢？
- 独立性使得它们可以在模块级跨界到更高系统层面环境。
- 当设计中的某一个模块功能修改时，只需要修改对应模块的sub_core组件，而且由于不涉及内部信号，这也更加便于维护。
- 由于各个sub_core内置comparer，当顶层环境测试中出现问题后，可以第一时间定位到具体哪个模块的数据发生了损坏。
- 拆分的参考模型便于阅读，没有那么庞大，从底层到顶层集成时的复用性也好。
从这篇文章还可以得到哪些启发和需要考虑的地方呢？
- 如果各个sub_core的维护由不同的verifier实现，那么各级sub_core组件之间通信的tlm_fifo的接口transaction类型就需要协调清楚。在这里，UVM TLM2.0的通信transaction类uvm_tlm_generic_payload就可以参考，可以在规定的公共数据内容基础上，添加数据扩展类uvm_tlm_extension_base。
- 与这种模式相对的另外一种方式则是，各个子模块的环境均独立集成在一起，在顶层环境中通过配置，使一些子环境的组件变为passive，继续发挥scoreboard的作用。这种方式也依然可以在上层可以验证模块环境，然而无法做整体的数据通路完整性验证。
- 该论文给出的方式，则是在顶层只保留顶层系统的外部总线agent，而将模块级的reference model组装链接在一起完成的验证，该方式兼顾了各个模块和整体系统的数据完整性验证，不过也需要在顶层环境完成对应组件的集成。
- 论文中的sub_core组件（reference model）与设计发生时序同步的地方主要在设计发生外部存储访问时，也由此使得sub_core组装起来的顶层reference model的时序会尽量与设计中需要消耗的时钟周期相差不多,减小了时序预测的误差。
往期精彩：