路科验证的个人空间 https://blog.eetop.cn/1561828 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

验证的策略篇之六(终):集成的环境

已有 1888 次阅读| 2016-8-12 10:57 |个人分类:验证系统思想


在分析完激励的原则的检查的方法之后,我们关于验证平台(testbench)的核心要素就大致齐备了。接下来我们将进一步分析整个验证集成环境要考虑的部分有哪些,通过这些分析了解这些部分之间的关系。从下面这张图我们将验证集成环境分为了:

  • 验证平台(verification platform)

  • 运行环境(runtime environment)

  • 待验设计(design under verification)

  • 验证管理(verification management)



验证平台

验证平台是验证人员日常工作的对象,在建立或者复用验证框架时,主要从激励分类和检查方法两部分考虑,这两部分会直接影响验证的框架。


激励分类

  • 直接激励:一般通过文本激励、C代码激励、预先生成激励码等形式给入测试激励。

  • 随机激励:通过约束随机给入测试激励,这里的随机方式不局限于SV,也包括其他随机验证语言,或者脚本语言用来的随机生成。


检查分类

  • 线上检查(online check):在仿真的过程中动态比对数据,并且给出比较结果信息。

  • 线下检查(offline check):在仿真结束之后将仿真中收集的数据进行比对,再给出比较结果。

  • 断言检查(assertion check):可以通过仿真或者形式验证的方式利用断言检查设计的功能点。


待验设计

硬件设计根据功能描述的定义阶段和功能划分,可以分为两个部分:

  • HDL硬件模型:即使用HDL语言描述的硬件模型,按照硬件层次划分可以分为RTL和网表。该模型的特定是与硬件设计师距离最近,也是最贴合硬件逻辑行为的模型。

  • 虚拟原型(virtual prototye):在硬件定义的早期阶段,我们会引入虚拟原型来对硬件的框架和性能进行评估。同时,在数字信号处理模块中,需要较为复杂的算法参与,所以在硬件实施之前,我们也可以采用软件算法模型来代替硬件的功能(不考虑时序替代)。常用的虚拟原型语言包括SystemC、C/C++、Matlab等。


在仿真过程中,我们也可以将HDL硬件模型与虚拟原型组合进行联合仿真,这时需要考虑虚拟原型的接口是否可以较为方便地在硬件环境中集成,以及是否对虚拟原型的接口时序有要求。


运行环境

运行环境的主要职责是将验证平台和待验设计做一个融合(软件激励端和硬件模型端的互动),而根据上面验证平台和待验设计的分类,运行环境需要考虑的因素有:

  • 验证平台:运行环境需要传入参数来实现根据测试场景来选择特定测试序列、随机种子数值、参数化验证环境的结构、实例化验证平台等跟所有跟通过运行参数来控制验证平台的因素。

  • 待验模型:除了考虑如何实现HDL硬件模型与虚拟原型在仿真器中协同仿真之外,还需要实现验证平台和待验设计的接口对接,这包括硬件信号接口连接和内部信号的接口连接。

  • 仿真全流程建立:这包括了验证和设计的文件提取(extraction)、文件依赖度分析(dependancy analysis)、编译(compilation and elaboration)、仿真(simulation)、结果分析(result analysis)和递归测试(regression test)等。全流程的建立一般是由环境建设者(environment builder)通过脚本(script)语言来做管理的,常见的用于仿真流程建立脚本语言包括Shell、Makefile、Perl、Tcl、Python等。


验证管理

无论我们芯片的尺寸有多大,作为验证人员和验证经理都需要对自己负责的模块或者芯片做一个量化的验证管理,除了常见的Excel表格管理之外,我们也会通过其它验证管理工具来进行管理。这些验证管理工具需要考虑的因素有:

  • 验证计划和进度管理(verification plan and progress management):验证计划需要从抽象文字一级与量化后的测试用例、功能覆盖率对应,进而给出一个可视化的验证进度。

  • 文件版本控制管理(file version control management):文本版本控制在团队协作中几乎是必需品,常见的工具有SVN、Git、Clearcase。

  • 项目环境配置管理(project environment configuration management):项目环境的配置文件不但包括有项目中使用的各种工具的版本、单元库的版本、验证IP的版本,也包括验证环境的顶层配置,通过这些环境配置管理每一个参与到项目的人可以很快地实现环境配置,省去同步协调验证环境的工作。

  • 缺陷率跟踪管理(defect tracking management):在之前提到的缺陷率曲线,需要验证人员和验证经理保持记录的习惯,除了可以通过缺陷率曲衡量验证的进度,还需要通过记录的缺陷来跟踪缺陷的修复、后续验证的工作。


有了足够稳定的验证平台,能够在更早期利用不同抽象级别的待验模型展开验证环境的搭建和设计验证,通过模块化自动化的运行环境实现环境从建立到检查,这是一个完善的验证环境能够提供给验证人员的。在此之上,从项目管理角度出发,我们也需要一个完善的工具(可能是几个工具共同协助)帮助我们完成验证管理,最终可以达到验证的目标。


到这里,我们的《验证的策略篇》就介绍完了。从下一季开始,我们将进入《验证的方法篇》,将结合常用的验证方法、运行环境、验证管理等验证构成的要素来谈一谈贯穿验证周期内的工具。


感谢你对路科验证的关注,我们下一章再见。



您可以在手机移动端同步关注订阅号“路科验证”。

如需转载请联系路科验证,并注明出处“路科验证”。


点赞

评论 (0 个评论)

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

站长推荐 上一条 /2 下一条

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-4-19 11:36 , Processed in 0.015977 second(s), 11 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部