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

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

日志

UVM世界观篇之一:我们所处的验证时代

已有 4030 次阅读| 2017-6-11 23:34 |个人分类:验证系统思想|系统分类:芯片设计

如果你将来或者已经在一家超过20年以上的IC公司工作,那么作为一名verifier,你会很有幸像参观验证“历史博物馆”一样阅读过去20年以前的验证代码,说不定由于历史和其它不得而知的原因,这些代码仍然躺在你所在的项目库里面,整个公司内真正了解它们的人并不多,而项目执行却又离不开它们。这些“老古董”们放在那里,同已经被silicon proven过的设计一样一方面既供人参观,另外一方面也供人使用。

红酒品酒师懂得什么年份的红酒好喝,而陈年的苏格兰威士忌靠着那浓浓的“泥煤味”口感征服了全世界的威士忌酒友,那对于路桑来讲哪个年份的验证代码最“迷人”呢?要我说,代码也是陈的美,无论是C++以前的C(请原谅我忽略不属于我那个时代的汇编代码),还是SV以前的Verilog,在它们有限特性手段内,它们偏偏可以去创造满足出高级的需求。这除了让我感叹在十多年以前Verilog的专家如何去实现随机环境和巧妙字符串处理方式的时候,也为现在的verifier所处的时代感动高兴。

因为硬件的验证方式已经明显倾向于软件化方式了。在之前《验证的管理篇》中我们就不断提到IP的复用性其重要程度关乎到项目的执行节点,而这一挑战对IP验证和芯片验证来说更甚。在Verilog和VHDL时代停留的语言依然受限制于静态例化,无法随着仿真场景做动态变换;同时,天生地随机约束短板也让后期发展的功能覆盖率驱动验证方式没有可以依靠的专用验证语言。所以,在意识到验证环境需要一种更“软”的语言之后,当年的EDA厂商们都开发出了良好的平台限定性语言,Specman/e语言和Vera语言就是非常优秀的两款语言。这些平台专用语言的特性推动了功能空间覆盖率的发展,对覆盖率驱动验证产生了深远影响。

然而,所谓“天下合久必分,分久必合”的定律也应验到了IC验证领域。SystemVerilog从早先的Accellera 2002年的SystemVerilog 3.0标准,逐步发展到IEEE-1800 SystemVerilog 2012标准经历了十多年的更新和完善,已经全面雄起为IC验证领域的霸主语言。这一点从下图中的使用比例和趋势图中一览无遗。


除了底层语言的逐步统一以外,上层的高级验证方法学也在2011年2月份之后逐步得到了融合,即UVM(Universal Verification Methodology) 1.0的发布。讲到这里,我们更应该为现如今从零搭起的验证环境干杯,祝贺你们没有一点儿历史包袱,我们也应该为EDA厂商们干杯,感谢你们终于不再各自为阵,而是将AVM、VMM、OVM最终融合为UVM。读者在这里需要认识到此举的意义在于,打通了各家的门户,极大地方便了用户的选择自由度。这就好比“三网”要融合成为“一网”,而移动通信网络的制式都改为了一种。那么,三大EDA厂商拼的是什么?自然就是工具、设计和验证服务的质量了啊。厂商们能做到这一点,不得不为它们的觉悟点个赞啊。验证语言SystemVerilog和验证方法学UVM的统一使得语言和方法学不再局限于特定的工具,用户也不再受限于特定的仿真器,无法切换到另外一家。通过UVM编写的验证IP,可以实现跨平台的应用。

就验证编程语言SystemVerilog而言,之前在关于SV的核心介绍篇章中,读者可以理解它的面向对象、随机约束、线程通信和管理等高级的特性,同时这些特性也为建立一个验证环境提供了足够多的便利。而就一种验证方法学而言,它的思想却并不是必须要与某一种语言绑定的。因此,UVM的验证方法学通过吸取了eRM(Specman/e验证方法学),AVM,OVM,UVM等之前不同方法学的优点, 可谓集众家之所长。读者需要认识到的是,所有的验证方法学服务的目的都在于提供一些可以重用的类来减轻在项目之间水平复用和垂直复用(《SV系统集成篇》介绍过)的工作量,而同时对于验证师新人又能提供一套可靠的框架来帮助他们解决为搭建房子构思图纸一砖一瓦添加的苦恼。

UVM是面向所有数字设计,涵盖了从模块级到芯片级,ASIC到FPGA,以及控制逻辑、数据通路到处理器验证对象的全部场景。UVM中的Universal(通用)的含义代表的是该方法学可以适用于大多数的验证项目,而它自身提供的基础类库(basic class library)和基本验证结构可以让具有不同程度软件编程经验的verifier们能够快速构建起一个结构良好可信的验证框架。UVM自定义的框架构建类和测试类能够帮助verifier减轻环境构建的负担,进而将更多的精力集中在如何制定验证计划和创建测试场景当中去。

从UVM的诞生说起的话,那是在2010年UVM发展委员会提出了从OVM(Open Verification Methodology)基础中来构建UVM的第一个版本UVM 1.0EA(Early Adopter),该版本几乎是OVM的直接跨接。伴随着UVM的快速发展,它汲取了VMM的特性例如寄存器级(Register Layer),以及其它被证明有效的验证理念。直到目前为止,UVM标准已经制定到UVM1.2,而对于其每个版本的信息统计可以从下图中看出:

在这些版本中,有重要意义的是UVM1.1和UVM1.2。其中UVM1.1之前的演变进化更多地是在于汲取OVM的方法学框架以及创建UVM的寄存器模型;而在UVM1.2版本时重要的版本变化是UVM的消息机制更新和transaction记录能力的增强。截止到本书撰写的2017年初,UVM已经作为IEEE标准的预制定阶段(IEEE-1800.2),而且仍然会保持标准发展下去。

由于UVM的演变发展历史中,使得在新版本中新的构建平台方式和测试方式可以同旧的方法并存。UVM的新版本兼顾了兼容老版本用法的同时,也注毁了一些之前的陈旧用法。关于这一点我们会在后面的具体用法中为大家详述。

在探索UVM的世界之前,我们会遵循着下面的这种方式来全面认识目前业界趋于统一的验证方法学:
  1. 认识UVM世界的版图(类库)和核心机制。
  2. 学习核心的UVM组件和层次构建方式。
  3. 了解常见的UVM组件间的通信方式。
  4. 深入UVM测试场景的构成。
  5. UVM的寄存器模型应用。



下一节我们将带着读者先领略UVM世界的地图,看看不同UVM类的继承和联系。心中有一份UVM的类库地图,可以为后面的学习提供一份指南。

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





点赞

评论 (0 个评论)

facelist

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

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

    周排名
  • 0

    月排名
  • 0

    总排名
  • 0

    关注
  • 253

    粉丝
  • 25

    好友
  • 33

    获赞
  • 45

    评论
  • 访问数
关闭

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

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

GMT+8, 2024-3-28 18:53 , Processed in 0.015523 second(s), 12 queries , Gzip On, Redis On.

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