（微电子学与固体电子学专业论文）基于specman_e的dmc功能验证.pdf

摘要 摘要 在s o c 的设计中，数字逻辑电路的规模越来越大，现在平均门数已经在百万 门以上，在如此大规模电路的设计中功能验证已经成为i c 设计的一个瓶颈，所以 设计团队不得不用5 0 0 0 7 0 的时间去进行功能验证，如此多的时间已经超过了进 行新代码开发的时间。而且随着规模的越来越大，其验证的难度也会成指数增长， 如果规模增加一倍，那么验证的难度就会是原难度的四倍。尽管耗去大量的时间 和人力，仍然会有一些边缘情况没有覆盖到，这样就导致了芯片流片的不成功。 于是业界提出了受限随机矢量生成验证方法学，即在满足条件约束的情况下随机 产生验证矢量。本文通过对d m c 在s p e c m a n e 的环境下的验证的介绍，对受 限随机矢量验证方法学进行了探索。 在本文中描述了使用e 语言结合v e d l o g 语言验证的整个过程，首先根据d u t 的规范制定出验证计划和验证覆盖率的目标，画出验证环境结构图，接着使用e 语言和v e d l o g 语言对验证环境进行编程，产生激励和约束条件。最后对发现的错 误进行纠错，同时对功能覆盖率和代码覆盖率进行收集。最后对使用s p e c m a ne 的优越性进行总结，对验证方法学发展进行了展望。 关键字：d m cs p e c m a n e功能验证 a b s t r a c t a st h ea v e r a g eg a t ec o u n tf o rd e s i g n sb o wa p p r o a c h e so re x c e e d so n em i l l i o n , f u n c t i o n a lv e r i f i c a t i o nh a sb e c o m et h em a i nb o t t l e n e c _ ki nt h ed e s i g np r o c e s s d e s i g n t e a m ss p e n d5 0 t o7 0 o ft h e i rt i m ev e r i f y i n gd e s i g n sr a t h e rt h a nc r e a t i n gn e wo n e s a sd e s i g n sg r o wm o r ec o m p l e x , t h ev e r i f i c a t i o np r o b l e m si n c r e a s ee x p o n e n t i a l l yw h e n ad e s i g nd o u b l e si ns i z e ，t h ev e r i f i c a t i o ne f f o r tc a l le a s i l yq u a d r u p l e t h o u g h ，s p e n d m u c hr e s o u r c ea n dt i m e ，b u tt h e r eh a v es om a n yc o r n e r sh a v en o t b e e nc o v e r , t h a tr e s u l ti nt h ef a i l u r eo ft h ec h i pp r o d u c t i o n s oan e wf u n c t i o n a l v e r i f i c a t i o nm e t h o d o l o g yb a s e d0 1 1g e n e r a t i o no fc o n s t r a i n t - r a n d o mt e s t b e n e hi s p r e s e n t e di ni n d u s t r y 砀em e t h o d o l o g yo ff u n c t i o n a l v e r i f i c a t i o nc a nr a n d o m l y g e n e r a t et h ed a t aw i t hl i m i t e ds o m ec o n s t r a i n t s w eu s et h ev e r i f i c a t i o np l a t f o r mo fs p e c m a n et ov e r i f yt h ed m c ( d y n a m i cm e m o r y c o n t r o l l e r ) ，a n dr e s e a r c ht h en e wm e t h o d o l o g yb a s eo nt h ep r o c e s so ff u n c t i o n a l v e r i f i c a t i o n 一 t h e r eh a v ed e s c r i b e dt h ef l o wo fv e r i f i c a t i o nw i t hel a n g u a g ea n dv c r i l o gl a n g u a g ei n t h i sp a p e r f i r s to fa l l ，w ew r o t et h ev e r i f i c a t i o np l a nb a s eo nt h es p e c i f i c a t i o no fd e s i g n , i n c l u d ef u n c t i o nc o v e r a g e ，s o u r c ec o d ec o v e r a g er e q u i r ea n dd r a w nt h ee n v i r o n m e n t w ew r i t et h ee n v i r o n m e n tc o d e 、衍me l a n g u a g ea n dv e r i l o gh d l a f t e rc o m p l e t e dt h e v e r i f i c a t i o np l a n ，a n dr e g e n e r a t e dt h es t i m u l a n ta n dr e s t r i c t l a s to fa l l ，w eu s et h e s p e c m a n ea n dn cv e r i l o gr u nt h es i m u l a t i o na n dv e r i f i c a t i o n ，d e b u gt h eb u g t h a t f o u n db ys p e m c n a _ e ，c o l l e c tt h ef u n c t i o nc o v e r a g ea n ds o u r c ec o d ec o v e r a g e t h e l a s to ft h i sp a p e rh a v es u m m a r i z e dt h ea d v a n t a g eo fs p e c m a n ea n dd e s c r i b e dt h e p r o s p e c to fv e r i f i c a t i o nm e t h o d o l o g y k e y w o r d ：d m c s p e c m a n - ef u n c t i o n a lv e r i f i c a t i o n 西安电子科技大学 学位论文独创性( 或创新性) 声明 秉承学校严谨的学风和优良的科学道德，本人声明所呈交的论文是我个人在 导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以标 注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究成 果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过的 材料。与我f 同工作的同志对本研究所做的任何贡献均已在论文中做了明确的说 明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切的法律责任。 本腔名：缢盔日期丝星垡! 西安电子科技大学 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。学校有权保 留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全部或部分内 容，可以允许采用影印、缩印或其它复制手段保存论文。同时本人保证，毕业后 结合学位论文研究课题再攥写的文章一律署名单位为西安电子科技大学。 本人签名 导师签名 日期 砂d 卟n 第一章绪论 第一章绪论 验证的目的是确保正某种变换的结果和预期的结果一样。功能验证的目的是 确保设计对象满足在功能规范中所定义的应该达到的功能要求。在i c 设计中从设 计规范到r t l 编码之间就是一种变换，而且这种变换不是自动转换的，是由某个 人或者某个设计小组根据自己对规范的理解进行的一种变换，所以在这个变换中 可能会出现由于对规范的错误理解而导致的错误。因此为了避免由于个人对规范 而造成的错误理解所导致的芯片设计错误，必须要由不同的人对编写好的r t l 代 码进行功能方面的验证。如果没有功能验证，设计人员只能主观地认为自己没有 错误地理解设计规范的意图，而不知道从设计规范到r t l 代码的变换是否正确。 功能验证也是确保芯片一次流片成功率的重要步骤。 图1 1 应该由设计之外的人来进行验证 在验证中有两种错误：一是设计本身的错误，另个是验证环境的错误。 s o c 设计是一个非常复杂和耗时的过程，这其中不可避免的会有许多因素会让 s o c 的功能不能正常表现出来，首先是系统定义的错误，这一步的功能验证就是 验证设计人员所制定的定义是否和系统定义一致。在这一步检查通过之后，硬件 设计工程师就会按照系统定义好了的规范去用硬件描述语言来实现，然后再用 e d a 综合工具把它翻译成门级网表，由于这一步过多地掺进了人工劳动和工具的 处理，最有可能引起很大的功能错误。同时，功能验证的失败还有可能是由验证 环境本身的错误造成的，主要是由于设计规范模棱两可，或验证工程师对设计规 范的理解不够。由于搭建的验证环境的质量不高，把一些非设计错误报告出来， 误导验证工程师的验证工作。验证工程师的职责就是找出设计本身的错误，避 免产生验证环境的错误。 2 基于s p e c m a n _ e 的d m c 功能验证 当设计随着摩尔定律所预言的速度持续扩张，很显然地每个芯片中都有越来 越多的功能需要被验证；但是另外一方面，迅速进入市场的压力也在同时间直线 增长。在某些状况下，验证有可能会吃掉整个设计流程七成以上的时间，我们唯 一能够做的事情便是在最短的时间之内，完成所有必须的验证工作。但是要尽快 测试完所有的功能，并能在预定时间内完成所有必备工作已经变得越来越难了， 于是有人提出了以下方法来解决这个难题： 删掉设计里部分的功能，进而让需要测试的部分减少，这种方法显然不可行， 所有设计中的功能都是为满足市场需求而设定出来的，删掉部分的功能将会使产 品变成“四不像”，因此，这不是一个好答案。 添加更多的人力来进行验证工作，这样可以写出更多的测试。这也不会是一 个好途径，因为大部分的机构都已朝着缩减预算的方向走，更何况令人沮丧的事 实是，增加人力并不会使得验证的成果呈现线性的增长。 可见以上两个方法对于提高验证效率都是不可行的，于是工程师们开始在验 证方法学上提出了一些改进方案，最后受约束型随机数据生成法成为最出众的一 个解决方法。在以仿真为主的流程里，验证工程师首先须把设计里面的基础架构 先串好，再想办法编写测试文档，然后安装到设计里面，记录并查看结果。这种 创建测试平台( t e s t b e n c h ) 的方法可能会占去绝大部分的验证时间，甚至变成整个 企划的关键步骤。受约束型随机数据生成法的思想是这样的： 将测试平台比喻作一台大机器，上面有许多的开关和旋钮，而测试文档就是 一连串运行“控制开关”和“扭转旋钮”按特定顺序指令工作。可想而知，如果机器 上面有越多的开关和旋钮，而它们上面又各自有越多的刻度，那测试文档撰写者 就必须得花更多的时间来描述所有可能的情况。每种情况会通过不同的路径进入 设计里面不同的状态，也同时测完特定的一些功能。在如此的状况下，如果想要 得到更高的生产力，似乎就得想办法让验证工具能够自动地控制旋钮和开关，以 创建更多种的环境来完成测试。而这些开关和控制按钮就利用语言来完成。e 语 言就是基于这种验证思想而产生的。在e 语言中控制这些开关和按钮的方法就是 利用语言的优势给某些参数加约束。而且在加了约束之后所产生出来的数据都是 符合所要验证的功能的。在e 语言中专门加入了一些为验证而使用的语句，比如 在收集覆盖率时可以使用c o v e r 语句。这极大地方便了验证环境的建立。 本科题的主要研究内容是s o c 芯片设计中的功能验证，介绍其模块级和芯片 级的功能验证方法和侧重点。在本文的第一章即本章介绍了本课题的背景，第二 章简单介绍了目前用于功能验证的一些方法学及传统方法学中的不足，同时也介 第一章绪论 3 绍了新的验证方法学。第三章介绍了e 语言的历史和s p e c m a n 、建构验证环境的 方法、与硬件描述语言模拟器结合起来一起仿真的步骤。第四章介绍了d m c 的结 构及其功能。第五章介绍了基于e 语言的验证环境的搭建。第六章给出实验的具体 数据，并分析这些数据所说明的问题。第七章是总结和展望。 本章总结：本章主要介绍了功能验证的概念及其在i c 设计中的重要性。同时 介绍了现在i c 设计中验证所碰到的困难。最后说明了本文的研究目的和文章结构。 第二章功能验证的发展 5 第二章功能验证的发展 1 9 7 5 年摩尔在i e e e ( 国际电信联盟) 的学术年会上提交了一篇论文，他根据 时的实际情况，提出“半导体集成电路的密度或容量每1 8 个月翻一番，或每三年 增长4 倍 ，这就是著名的“摩尔定律 。3 0 多年来半导体集成电路的容量增长基 本与摩尔定律相吻合，半导体电路的集成度已经相当于3 0 年前的几万倍，2 0 0 6 年i n t e l 为a v e r i l l 计算平台推出两款处理器，一款是6 5 n m 的 p r e s l e r 处理器， 另外一款6 5 n m 双核心 c o r t r o e 处理器，晶体管个数达到了2 9 3 亿个，2 0 0 7 年1 1 月1 2 日i n t e l 又推出了4 5 n mp e n r y n 系列处理器，晶体管更是达到了8 2 亿个， 但这都并不是现在晶体管最多的芯片，现在具有最多晶体管数的芯片是i n t e l 于 2 0 0 6 年发布的m o n t e c t e c i t o9 0 5 0 型服务器处理器，晶体管数达到了1 7 亿。随着 单个芯片内集成的晶体管数目越来越多，不但使半导体的功能越来越强大，也使 半导体价格也越来越低。但是随着芯片功能的越来越强大，使得在设计中验证这 些功能的时间也越来越长，在如今的芯片设计中一个团队用于芯片功能验证的时 么7 闻大约占去整个芯片设计5 肚粥的时间，甚至达到了8 0 。随着半导体工艺的不 断发展，芯片的规模还在不断增加，而验证的难度随芯片规模的增长呈指数增长。 在虚拟插座接口联盟( v s i a ) 1 9 9 9 年成立验证专题研究组( v e r i f i c a t i o nw o r k s h o p ) 之际，众多世界级的验证专家达成“验证很棘手 的结论。数周之后，经过相当 深入的探讨，最终的结论被改为“验证不仅是棘手，而且是非常棘手 。第三届 v s i a 验证会议的时候这个结论又被改为“验证不仅是非常棘手，而且是非常， 非常棘手一。所以业界也达成了统一认识“验证已经成为i c 发展中的一个瓶颈。 i c 设计中的其他步骤较成熟的自动设计工具，比如逻辑综合工具和布局布线 工具。而验证的工作中还是有大部分由人工去完成。所以减少验证时间成了各个 商家占领市场的最有效举措。 高效率完整准确地对系统进行验证包括两个方面：验证工具和验证方法。于 是工程师们在长期的验证发展过程中对验证方法和验证工具进行了不断的改进， 验证方法在发展过程中产生了如下几种方法： 2 1 静态功能验证一形式验证 形式验证是一种静态的功能验证方法学，它通过数学的方法来证明设计的实 现跟设计的规范是否相一致的，也有些人把它定义为是一种检查所实现的设计是 否满足某些属性特征的过程。在很多时候，一些对形式验证方法学不甚了解的工 6 基于$ p e c m a n _ e 的d m c 功能验证 程师，认为形式验证的强大优势在于它不需要写任何测试矢量，其实这种认识有 点片面! 形式验证的巨大优势在于它能够在功能验证之后，保证刚才的验证能够达 到1 0 的功能覆盖率! 但是它的缺点亦是很明显的：它的容量、它的应用范围，以及 它对硬件环境要求的苛刻都使它不适宜进行系统级的功能验证，在目前，它还主 要应用于模块级和单元级设计的功能验证。 形式验证有三个不同的类型： 令等价证明相似检查( e q u i v a l e n c ec h e c k i n g ) 令模型检查( m o d e lc h e c k i n g ) 命定理证明( t h e 0 姗p r o v e n ) 下面简单介绍一下三种方法的原理及应用的范围。 2 1 1 等价证明相似检查 通过比较两个结构来检查它们是否等价，或通过数学证明的方法来证明两者 逻辑上的等价性。 它一般应用在设计的后期，设计形式比较低的层面，主要是从r t l 到门级( 综 合后) 的过程中验证两者的一致性。图2 1 是等价证明的示意图。 2 1 2 模型检查 等价形式验证 图2 1 等价性检查的路径 第二章功能验证的发展 7 图2 2 模型检查路径 模型检查是通过形式上的检查来认可或否决模型的特征。模型检查一般用来 检查一般的! l b - 特殊的问题或检查用户定义的设计行为的行为是否违规了，断言通 常应用在设计的高级阶段，同时那些被检查的特征一般从设计规范中定义而来， 检查的过程中常常会引入一个状态机。图2 2 是原型检查的示意图。 但是这种形式验证方法学却很不成熟，具体表现在：知道那些特性需要检查 和怎样去表达这种需要很大的技巧，一般需要这类型的验证工程师有很高的数学 修养；很少有友好用户界面的e d a i 具；现存的这类型的工具其应用的容量很有限。 2 1 3 定理证明 定理证明是用形式逻辑同时去描述设计的实现和设计的规范，然后用理论证 明鬯垄婆来验证两者在逻辑上星垂宴垫担羞壁垦啦c ? 这是形式验证方法学中最早的一个方法，它的优点是形式的证点可以机械地 检查，它的缺点是推演出这些形式的原型和证点非常繁琐，不过目前它还只是在 学术上进行研究。 2 2 动态功能验证 2 2 1 仿真 动态功能验证是通过对实现的设计施加测试矢量，然后检查实现的设计的行 为是否按照它的设计规范而运作的。 这种方法的优点是易操作，并且它的适用范围比较广，不受设计规模的影响， 但它的缺点亦是明显的：难开发出比较健全的测试案例，特别是一些边缘测试案 例：其次难以分析、判断它的功能覆盖率和测试的完整性；更有可能一些未被定义的 行为会被当作设计错误报告出来；对于检查工作仅能局限在一些给定的范围之内。 8 基于s p f c m a n _ e 的d m c 功能验证 2 2 2 基于断言的验证方法 通过在r t l 代码中插入断言语句，然后在动态仿真的过程中由这些断言语句来 判断实现的设计是否跟设计的规范相一致。 使用断言验证方法学能够帮助验证工程师理解实现的设计，如果实现的设计 有不正确的地方，还能够帮助验证工程师定位出错误的地点。但是，使用断言验 证方法需要首先学会一种断言验证方法的验证语言，用它来描述d u t 的预期应发 生的以及预期不应发生的行为。 在以后的设计中插入断言语句将会变为一种趋势! 这对于口开发商和系统集成 工程师都是一种必要。 2 2 3 其他的验证方法学 在动态验证方法发展的过程中又出现了以下几种方法学： 1 硬件描述语言验证方法( h d l - b a s ev e r i f i c a t i o n ) ：验证环境和被验证的组 件( d e v i c e u n d e r t e s t ：d u t ) 都是由v e r i l o g 或者v h d l 语言进行编写的： i 数据从由硬件描述语言的t e s t b e n c h 向d u t 发送； i i t e s t c a s e s 中为了验证d u t 某一特性而向d u t 发送的数据都是由人工进行筛 选，并最后进行检查。 图2 3 验证示意图 但是由于这种验证方法有很多弊端，所以最后用到的很少： ( 1 ) 编写t e s t c a s e s 要消耗去大量的时间，同时又很乏味。 ( 2 ) t e s t c a s e s 让其他人很难读懂，就是编写者自己也可能在编写完t e s t c a s e s 一 段时间后也不能理解，所以维护就更难了。 ( 3 ) 如果使用硬件描述语言对d u t 进行验证，会出现很多边角情况不能被覆 ，u 血o ( 4 ) 由于在环境中没有共享代码的使用，所以建立或者维护一个环境都非常困 难，并且由于在硬件描述语言中没有提供一些可以支持复杂情况下建模的特 性，使得要想建立一个较复杂的验证环境成为一件困难的事。 2 面对对象语言验证方法( o b j e c t o r i e n t e dv e r i f i c a t i o n ) ：为了让验证环境易 于复用和阅读，一些验证工程师开始用一些面对对象语言去进行编写验证环境和 第二章功能验证的发展 9 t e s t c a s e s ，比如c + + 。刃 万由于面对对象语言在高层建模发面对于数据的输入和输出易于实现，所以面 对对象语言验证方法在书写t e s t c a s e s 的时候大大的减少了需要花费的时间。 在面对对象验证的时候由于必须要一些新的功能接口，这让验证环境变复杂了， 所以虽然对于单个t e s t c a s e s 上来说消耗的时间变少了，但是在验证环境上所花费 的时间却增加了，而且在验证环境的搭建上增加的时间有时候已经超过了在 t e s t c a s e s 上节省的时间，这样整个产品的验证时间还是没有减少，还有可能增加。 3 随机验证方法( r a n d o mg e n e r a t i o n ) ：在面对对象验证的时候，由于开发 t e s t c a s e s 即乏味又耗时，且开发出来的t e s t c a s e s 又不方便维护，于是工程师们就 开始着眼于使t e s t c a s e s 的开发变的省时省力。 。于是工程师们使用了自动随机生成数据的方法，这样工程师们可以在一个环 境下开发多个t e s t c a s e s ，并且每个t e s t c a s e s 可以使用不同的s e e d 进行多次运行。 这样虽然说对于开发t e s t c a s e s 来说比较方便了，但是由于随机产生的数据没有任 何限制，就产生了大量的不符合要求的激励，所以为了避免这种情况的出现就发 展出来了一种有定制的产生方法。但是维护和开发定制发生器被证明是非常困难 的。 另外随机验证方法还带来了一些新的问题： ( 1 ) 检查验证结果变的非常困难因为在随机验证方法中每次产生的激励都不 相同，所以在运行之前想要预测结果是不可能的。 ( 2 ) 功能验证的覆盖率成为了一种必需在随机验证中因为每次产生激励的不 同，所以工程师们也不可能预测到每个t e s t c a s e s 将会验证哪一个功能。 因此，虽然开发t e s t e a s e s 变的很简单了，但是其他的工作( 比如d e b u g 和分析 覆盖率) 却占去了工程师大量的时间。 4 测试平台工具( t e s t b e n c h t 0 0 1 ) ：在这种方法中，其主要目的就是减少验 证环境中各种接口和数据产生器的开发时间和维护时间。因为在验证过程中如果 d u t 的规范要进行改变，那么维护这些接口和数据产生器将是非常困难的，当要 把一个验证环境移植到另一个仿真或者不同的版本中时就需要有大量的工作去重 新做。 通常测试平台工具能够减少创建验证环境所需要的时间，但是，验证工具不 能成熟到去解决约束的问题，而且如果不说明验证环境的所有的相关知识时也不 能使工程师们在某一抽象层上去详细指明t e s t c a s e s 所要实现的功能。所以工程师 花费在验证上的时间也不能减少。 、另外，测试平台工具也不能实现所有种类的数据的顺序和相互之间的关系。 所以在 9 l ! i 试平台工具的验证方法的测试环境中要想检查测试目标和实现复杂情况 下的验证覆盖率也是一个很困难的工作。 l o 基于s p e c m a n _ e 的d m c 功能验证 5 完全验证自动化系统( c o m p l e t ev e r i f i c a t i o na u t o m a t i o ns y s t e m ) ：因为以上 方法各有特点又各有缺点，于是一种能包括各种方法优点且可以克服其缺点的方 法被发明了出来，这就是完全化验证自动系统。 而完全验证自动化方法必须具有以下几个特点： ( 1 ) 能够达到9 0 以上继承性以减少编写t e s t c a s e s 所需要的时间，能够根据 所验证的对象进行扩展。 ( 2 ) 能够根据不同的对象和t e s t c a s e s 进行约束。 ( 3 ) 能够在复杂的验证环境中对覆盖率进行收集。 ( 4 ) 具有一种简便的瞬时的驱动语句能够使工程师去捕捉协议的规则，从而 检查协议的正确性，以及d u t 的设计是否符合协议的要求。 完全验证自动化系统能够减少验证所需要的时间同时又能提高验证的正确性 是因为以下几点： ( 1 ) 定义验证计划。 ( 2 ) 编写和维护验证环境。 ( 3 ) 选择验证向量( 输入激励) 。 ( 4 ) 检查结果。 ( 5 ) 根据验证计划( 覆盖率) 估计验证的进度和验证所需要的时间。 e 语言具有完全验证自动化系统的所有要求，而s p e e m a n 是现在唯一支持e 语言的e d a 工具。 6 本章总结：本章主要介绍了功能验证的发展过程中所出现的几种验证方 法，其中包括两大类：静态功能验证和动态功能验证。而且介绍了各种验证的优 缺点。最后总结了对于大规模集成电路验证所需要的一些要求。 第三章e 语言和s p e c m a n _ e 3 1e 语言的历史及优点 e 语言是由原v 舐s i t y 公司首席技术官( c h i e ft e c h n o l o g yo f f i c e r ) 、现在 c a d c c 验证部门首席技术官m i k es t a l l f o x 提出，1 9 9 2 年e 语言和s p e c m a n 开 始在v e r i s i t y 的几个固定用户中开始使用，e 语言经过逐渐的完善后，被认为是现 在功能最强大，验证正确性最高的验证语言。于2 0 0 6 年3 月被i e e e 认定为标准。 2 0 0 6 年4 月c a d e n c e 收购v e r i s i t y ，s p e c m a n 成为c a d e n c e 的注册软件。 完全验证自动化系统的首要目的就是要高效正确的实现对d u t 的验证，作为 一个种高级语言，e 语言具有完全验证自动化系统所需的所有要求，它具有以下 几点优点： i 说明性代码搭建验证环境，这样可以方便的扩展可改动环境。这样可以 大大减少建立环境所需要编写的代码。 i i e 提供了一种动态的继承方式，这样可以使验证环境在面对对象的风格下 进行建立。 二 i i i e 语言中专门提供了针对验证所需要的数据产生，时序和功能覆盖率的结 构和语句。这些结构可以使工程师快捷的完成验证环境中各部分的搭建。 3 2 使用s p e c m a n 的验证环境的结构 e 语言所组成的部分与要验证的部分是两个独立的部分，由e 语言所编写的 部分主要是建立验证环境。而由v e r i l o g 或者v h d l 所编写的部分是逻辑设计部 分。 下图表示了e 语言所建立的验证环境和硬件描述语言所建立的逻辑设计部 分。 1 2 基于s p e c m a n e 的d m c 功能验证 e 语言结构( 验证) q 廖 d 聍刚d 鞠d 啊i 一髓i i 删 厂b 广 嘲嘲i l 纠d b 1 1 i i na 约一 厂 蚰千 厂上 厂上1 p a 删。翻嘲椎 图3 ie 语言所建立的验证部分和v e r i l o g 所建立的逻辑设计 3 3s p e c m a n 建立的验证环境 e 语言搭建的环境包括以下几部分： l 数据目标：定义需要的向量。 2 测试生成：对加入约束，以使向量满足d u t 的要求。 3 输入驱动：产生激励，以使数据能够进入d u t 内。 4 协议检查：检查协议的正确性。 5 覆盖率检查：对覆盖率进行分析，得到最后的覆盖率结果。 6 数据收集：对d u t 出来的数据进行接受。 7 数据检查：把接收到的数据进行分析比较。 e 语言建立的验证环境如下图所示： 数据目标| 协议检查 数据检查 i i 毒t 画孽享i 擘l 一输入驱动卜三l 剖t g ) ，| 输丧夏 t 覆盖率分叫 图3 2 验证环境 第三章e 语言和s p e c m a ne 1 3 3 4s p e c m a n 的运行 在对d u t 进行验证时s p e c m a n 和仿真工具比如n c _ v e r i l o g 或者 n c v h d l 同时运行，并且在运行的过程中两者之间需要一个接口不断的交换信 息，这个接口由一个叫s t u b s 的文件担当，这个文件提供两者之间主要的通信。 同时除了s t u b s 文件外，v e r i l o gp l i 和v h d lf l i 也提供s p e c m a n 和仿真器之 间的通信。 e x t m r n 8 iu 蛳薯嘲婚 s i m u l a t o rtop c 站l l o m r i e s c o h 嘲r l sc l o c k s , i n p u t , o 岫rl 静r a r i e s t o u t p u tr e g i s l e m n e t st l ! 国l $ p e c n m s 日i 慷d d v e s s a m p i e s c l k d o 唑 a， s p e o m a ne l l 蛔 8 t u b s f 融 c o n t a i n s 叠he o 凸d o + c r e a t e d 姊 一 d a 穗d 俐 口 s p e c m k t de r r 副张e 棚i 鞠畋 束剿m i u 泳l | o一 i c o v m o e l ? 龇l | h 融s i 删f 黼l 图3 3s p e c m a n 与仿真之间的互动 s p e c m a n 和仿真包括以下部分： ( 1 ) s p e m a ne l i t e ：整个验证环境都是用e 语言搭建的，包括驱动程序、 检查程序、覆盖率目标、数据目标，这些都是在对d u t 进行验证的时候必须要 求的。所有这些由e 语言编写的程序都是通过s p e c m a n e l i t e 来编译和仿真的。 ( 2 ) 外部库：如果有一些由c 语言或者c + + 语言编写的程序，那么这些程序 都是可以用e 语言直接调用的。比如有一些由c 或者c + + 编写的m p e g 解码程 序，那么就能用e 语言直接调用这个程序进行运用。 ( 3 ) d u t ：d u t 包括设计中所有的层，比如一个用v c r i l o g 语言编写的微处 理器，在它中间有各种模块，有整数处理单元、系统总线单元、浮点数处理单元 等。而d u t 表示的是整个设计的最高层，一般由v e r i l o g 和v h d l 组成。 ( 4 ) 混合仿真文件：如果在开始验证的时候工程师使用v c r i l o g 或者v h d l 来 搭建验证环境，中途又使用了e 语言来搭建后面的环境，那么这些用v e r i l o g 或 者v h d l 编写的东西就需要加入到整个验证环境中去。 ( 5 ) t o p ：这个模块表示仿真中的最高层。在这个层中所有的文件都是由 1 4 基于s p e c m a n e 的d m c 功能验证 v e r i l o g 或者v h d l 编写。这个最高层对d u t 进行了实例化，其中包括了对d u t 进行输入和接收d u t 输出的信号。 ( 6 ) s t u b s 文件：这个文件作为s p e c m a n 和仿真之间的通道，专门为两者之 间提供通信，s t u b s 是一个v e r i l o g 或者v h d l 文件，当工程师在s p e c m a n 运行 一个“l o a d 命令后，s p e c m a n 读入所有e 文档，然后就会自动生成一个s t u b s 文件。然后这个文件就加入v e r i l o g 或者v h d l 文件被仿真软件编译。 ( 7 ) 仿真器：这是与s p e c m a n 同时运行的v e r i l o g 或者v h d l 仿真器。它对 v e d l o g 、v h d l 和s t u b s 文件进行仿真。 使用s p e c m a n 和仿真器进行验证的步骤如下： s p e c m a n 和仿真器同时调用程序，s p e c m a n 调用e 文件，同时生成s t u b s 文件，仿真器调用v e r i l o g 和v h d l 文件。s p e c m a n 首先获得控制权，然后仿 真器停止在仿真时间为0 。然后控制权交给仿真器，仿真开始。 在仿真进行的过程中，碰到s p e c m a n 定义的触发点，则控制权交给 s p e c m a n ，如果没有达到触发点，则仿真继续进行。 圆如果由于到达了s p e c m a n 定义的触发点，控制权交给s p e c m a n ，那么 s p e c m a n 进行必要的计算，计算完成后如果没有其他触发点到达，那么控制权 交给仿真器。在这个过程中仿真器处于暂停，所以没有仿真时间耗费。 如果碰到触发点，那么重复、步。 控制权在仿真器和s p e c m a n 之间不停的互换，直到碰到s p e c m a n 定义 的终止事件。 对结果进行分析。 3 5e v c 因为e 语言的可扩展性，所以很多公司针对不同的协议( 比如p c i 、以太网 或者u s b ) 架构开发出了一些用e 语言编写的组件，这些组件根据不同的芯片进 行扩展，然后就可以直接使用。这就是e v c ( e 丽f i c a t i o nc o m p o n e n t ) 每个e v c 包括仿真所需要的整套部件，包括检查、针对不同协议的覆盖率信 息收集和架构。可以把e v c 作为整个环境来使用，也可以把e v c 放入一个更大 的环境中去。不同的e v c 可以同时使用在一个环境中。所以e v c 可以大大缩减 搭建验证环境的时间。e v c 可以与v e r i l o g 和v h d l 一起在s p e c m a n 所支持的 所有硬件描述语言仿真软件下运行。 e v c 与验证环境之间的区别是e v c 可以在多个环境中使用，而验证环境只 能在某个特定的验证中使用。 e v c 接口都是可见的，所以使用者可以根据自己的需要对其进行扩展。e v c 1 5 在一些关键部分进行了加密，这是对知识产权的保护。所以一些e v c 在使用的 时候需要专门的l i c 舰s o 3 6 验证的步骤一 验证的第一步是根据d u t 设计规范制定验证计划，验证计划中要包括验证 环境的架构、时钟信号的产生、d u t 的设置、覆盖项目的定义、覆盖率目标、 t c s t c a s e s 的定义。接着构建验证环境，产生时钟信号，对d u t 进行配置，用代 码对覆盖项目进行采集，编写t e s t c a s c s 。验证环境建立完成，t e s t c a s e s 编写好之 1 6 基于s p e c m a n _ e 的d m c 功能验证 后就是要进行仿真。仿真中如果有错误，就要对d u t 代码进行纠错，如果没有 错误，就继续仿真，直到仿真结束。仿真结束之后对覆盖率进行分析，直到覆盖 率达到1 0 0 ，那么验证结束。 通过覆盖率来判断验证是否完成是一个有明确标准的方法，如果验证覆盖率 没有达到1 0 0 ，那么就说明索要验证的功能没有全部实现。 要使用覆盖率组和覆盖率属性实现功能覆盖率模型，需注意以下几点： ( 1 ) 覆盖率组常用于对数据或事务建模，覆盖率属性常用于对时序行为建 模。两种语法特性各有各的特点，对不同的功能测试点要使用最合适的建模方式， 有时候还可以把两者接合起来使用。比如在覆盖率属性满足时触发覆盖率组的采 样。 ( 2 ) 与具体实现有关的边角情况应当由设计者本人用覆盖率属性来确定。例 如，在某模块中有一个f i f o ，设计者应当用覆盖率属性来保证f i f o 为空和为满 的情况被测试到过。再比如在测试状态极时，如果有一些状态只能在特殊情况下 出现，那么就必须保证这种情况能够出现。 ( 3 ) 应当仔细地设计功能覆盖率数据，使其便于理解和分析。收集覆盖率数 据的原因并不是为了收集一组数据，而是为了得到功能覆盖率的信息，为了使通 过收集到的功能覆盖率数据分析功能覆盖率信息变得容易，应当仔细地设计功能 覆盖率数据，使我们能够一目了然地得到功能覆盖率的信息。 构建了包括功能覆盖率模型的测试平台之后，设计者就可以在当前功能覆盖 率的指导下通过各种验证手段来提高功能覆盖率。例如，可以先用比较宽泛的随 机激励覆盖大多数容易覆盖的情况，然后再分析当前的功能覆盖率，根据它来约 束随机激励发生器，以覆盖一些较难覆盖的情况，如果有些边角情况难以用随机 激励的方法达到，还可以编写定向的测试激励来达到，甚至通过形式化的方法。有 了自动统计功能覆盖率的模型，我们可以较快地得到当前的功能覆盖率水平，相 比于传统的验证过程，不仅仅是节约了时间，它还能让我们根据当前的功能覆盖 率情况调整验证策略，以最少的时间达到最高的功能覆盖率，这才是针对覆盖率 验证期望达到的目标。 同时，覆盖率不只是任务是否完成的标志，同时也是纠错的一种办法，如 果在使用了各种约束之后，覆盖率仍然未达到1 0 0 ，那么可能就是r t l 代码的 问题，那么就需要对r t l 代码进行纠错，看在r t l 代码中是否实现了所要验证 的功能，或者是r t l 代码在实现此功能的时候出现了先后逻辑的错误。所以覆盖 率既可以起到任务完成的标准，又可以起到纠错的功能。 在本课题中观察错误是否存在的方法除了覆盖率，还有s c o r e b o a r d ， s c o r e b o a r d 是对预期数据和实际产生数据进行比较的一个模块。在验证环境 的建立中会进行详细介绍。 第三章e 语言和s p e c m a n _ e 1 7 本章总结：本章主要介绍了e 语言的历史，和s p e c m a n e 建立验证环境的 结构，s p e c m a ne 运行过程，c v c 的功能和复用性。最后介绍了验证的步骤。 第四章d m c 介绍 1 9 第四章d m c 介绍 d m c ( d y n a m i cm e m o r y c o n t r o l l o r ) 一个能够与外围设备相匹配的支持a m b a 总线协议的s o c 芯片。 4 id m c 的特征 用v c r i l o g 编写的软核，能够进行配置。 支持a m b a 的接口。 支持s d r ，d d r ，n v m 。 支持数据交插输入。 一 支持多重输出地址。 、 外部存储器和总线可以是同步，也可以是异步。 可以通过编程使d m c 支持低功耗功能，比如d e e pp o w c r d o w n , a c t i v ep o w e r d o w n ，p r e c h a r g ep o w e rd o w n 和s e l f - r e f r e s h 。 可是通过a p b 总线对d m c 进行编程。 同时可以连接4 个存储器。 表4 1 存储器与a x i 之间的带宽 a x i 带宽 存储器位宽 3 2 b i t6 4 b i t1 2 8 b i t 1 6 b i t 是 否否 3 2 b i t 是是 否 6 4 b i t 是是是 1 2 8 b i t 否是是 4 2d m c 结构 在d m c 中有三个部分：a x i 部分、a p b 部分和存储器部分。第一个部分是 a x i 部分，这一部分是用来连接a x i 总线，并且通过仲裁器对输入的信号进行分 析，判断出信号的意图，然后把信号发送给存储器部分。第二个部分是a p b 部分， a p b 部分的主要作用连接a p b 总线，对d m c 和存储器进行控制和配置的，通过 a p b 部分配置d m c 所连接的a x i 带宽，a p b 所要连接的存储器的类型、位宽等。 同时控制d m c 和存储器的状态。使d m c 能够在正确的状态下进行读写，或者 1 2 3 4 5 6 7 8 9 2 0 基于s ；p e c m a n _ e 的d m c 功能验证 乡，f 控制存储器是否可以读写等等。第三部分时存储器部分，这一部分的功能有两个， 一是用来连接存储器