（微电子学与固体电子学专业论文）基于vmm的局端ugtc验证.pdf

摘要 摘要 随着集成电路设计规模和复杂度的不断增大，验证工作越来越困难。验证往 往占到整个产品开发周期的7 0 ，成为了现代数字系统开发周期的瓶颈。如何快 速地搭建一个强大、高效、灵活、可扩展性好的验证平台成为验证工程师们关注 的重点。 本文的研究目标：在掌握o l t ( o p t i c a ll i n et e r m i n a l ) 芯片中u g t c 模块测试要 求的基础上，研究基于v m m ( v e r i f i c a t i o nm e t h o d o l o g ym a n u a l ) 验证方法学实现 u g t c 模块高效、层次化、可重用验证平台的方法。 在实现了验证平台的基础上，本文研究了基于覆盖率的测试用例开发策略， 并开发测试用例完成了u g t c 所有功能的仿真验证。代码覆盖率各项指标达到了 项目组的要求，其中行覆盖率为9 8 7 ，条件覆盖率为9 5 7 ，状态机覆盖率为 9 6 5 。在对u g t c 模块进行验证的过程中体现了v m m 验证方法学的优势。 关键字：v m m u g t c 验证 a b s t r a c t a b s t r a c t w i t ht h eb o o m i n go ft h es c a l ea n dc o m p l e x i t yo fi cd e s i g n ，v e r i f i c a t i o nw o r k b e c o m e sm o r ea n dm o r ed i f f i c u l t b e c a u s ev e r i f i c a t i o nw o r ka c c o u n tf o r7 0p e r c e n to f t o t a lp r o d u c td e v e l o p m e n tc y c l e ，i tb e c o m e st h eb o t t l e n e c ko ft h em o d e r nd i g i t a l s y s t e m sp r o d u c td e v e l o p m e n tc y c l e h o wt op u tu pap o w e r f u l ，e f f i c i e n t l y , f l e x i b l ea n d g o o ds c a l a b i l i t yv e r i f i c a t i o np l a t f o r mb e c o m e st h ef o c u s e st ow h i c he n g i n e e r sa r ep a y a t t e n t i o n o nb a s i so fm a s t e r i n gt h et e s tr e q u i r e m e n t so fu g t cm o d u l ei no l e ( o p t i c a ll i n e t e r m i n a l ) c h i p ，t h i sp a p e rm a i n l ys t u d i e sh o wt op u tu pae f f i c i e n t l y , h i e r a r c h i c a la n d r e u s a b l eu g t cv e r i f i c a t i o ne n v i r o n m e n tb a s e do nv m m ，w h i c hi st h eg o a lo ft h i s p a p e r a f t e ri m p l e m e n t a t i n gv e r i f i c a t i o np l a t f o r m ，t h ed e v e l o p m e n ts t r a t e g yo ft e s tc a s e b a s e do nc o v e r a g ei ss t u d i e di nt h i sp a p e r t h i sp a p e rh a sd e v e l o p e dt e s tc a s et o s i m u l a t ea n dv e r i f i c a t ea 1 1t h ef u n c t i o n so fu g t c a l li n d e x e so fc o d ec o v e r a g ef u l f i l l t h er e q u i r e m e n t so f p r o j e c tt e a m ，t h el i n ec o v e r a g ei s9 8 7 ，t h ec o n d i t i o nc o v e r a g ei s 9 5 7 ，t h ef s mc o v e r a g ei s9 6 5 t h ep r o c e s so fv e r i f i c a t i o no fu g t cm o d u l e e m b o b y st h ea d v a n t a g eo f v m m k e y w o r d ：v m mu g t cv e r i f i c a t i o n 西安电子科技大学 学位论文创新性声明 秉承学校严谨的学风和优良的科学道德，本人声明所呈交的论文是我个人 在导师指导下进行的研究工作及取得的研究成果。尽我所知，除了文中特别加以 标注和致谢中所罗列的内容以外，论文中不包含其他人已经发表或撰写过的研究 成果；也不包含为获得西安电子科技大学或其它教育机构的学位或证书而使用过 的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中做了明确的 说明并表示了谢意。 申请学位论文与资料若有不实之处，本人承担一切的法律责任。 本人签名：鱼丝 _ 妒 西安电子科技大学 关于论文使用授权的说明 本人完全了解西安电子科技大学有关保留和使用学位论文的规定，即：研究 生在校攻读学位期间论文工作的知识产权单位属西安电子科技大学。学校有权保 留送交论文的复印件，允许查阅和借阅论文；学校可以公布论文的全部或部分内 容，可以允许采用影印、缩印或其它复制手段保存论文。同时本人保证，毕业后 结合学位论文研究课题再撰写的文章一律署名单位为西安电子科技大学。 ( 保密的论文在解密后遵守此规定) 本学位论文属于保密，在一年解密后适用本授权书。 本人签名：歪；量日期丝望：主! 查 本人签名：在4 匕 日期丝翌：主! 查一 导师签名： 型i 逸 日期羔翌刍! 王。曼 第一章绪论 第一章绪论 随着s o c e 】芯片成为市场的主流，巨大的验证压力迫使验证工程师必须寻找 新的方法来解决面临的挑战。芯片设计的复杂度持续增长，如果继续采用传统的 方法，芯片的开发将面临巨大的风险。因为传统的验证方法已经不再让人觉得安 全，为了尽快弥补验证与现实产品设计之间的差距，很多专门的高抽象级的验证 语言不断涌现，比如v e r a 4 - 7 ，e 语言 8 - 9 1 ，j e d a 1 0 1 等。这些语言普遍采用先进的技 术，比如带约束的随机、基于断言以及覆盖率驱动e l l , 1 2 】的功能验证。然而只有先进 的验证方法才能充分利用这些技术的优点，帮助验证工程师建立起一个功能强大 的验证平台，从而更好的迎接复杂芯片验证的挑战。 对于验证而言，我们正处在一个转折点：逐步抛弃已经落后的传统验证平台 去开发全新的验证平台。关于这些验证平台的一些共性如下： 可重用，可扩展 易于管理，配置 可读性强，易于维护 可以完全取代传统的环境 可以提高验证效率 更高的仿真速度 在介绍新的方法前，让我们一起来回顾一下验证方法学的发展历史。 1 1 验证方法学的发展史 验证方法学【1 3 - 1 5 1 是伴随着集成电路的设计【1 6 ，1 7 】规模逐渐变大而发展起来的。 在集成电路发展早期，设计规模比较小，并且也不存在专门的e d a 工具，更多的 是工程实践中的经验和产品测试。随着7 0 8 0 年代专门的硬件描述语言、仿真器 以及综合工具的出现，设计规模急剧变大，设计效率也有了质的改变。随着设计 规模的增大，功能验证的缺陷导致的芯片失败或着重新流片的比例逐步提高，目 前公认的比例是7 0 ! 在h d l 语言时代，最早的验证方法局限于语言本身的描述能力。v h d l 本身 具有比v e r i l o g h d l 更强的抽象描述能力以及更好的文件接口，所以在验证平台的 开发上更高效。但是随着集成电路的发展，大家更渴望h d l 语言能够提供高抽象 语言接口。于是v e r i l o g 因为其特有的p l i 接口能直接和c 通讯，而大获成功，并 大大的提高了人们在开发验证平台时的抽象描述能力。在这个基础上验证方法进 入了一个繁荣时期，首次出现了层次化的验证平台思想。这一时期在验证方法学 2 基于v m m 的局端u g t c 验证 方面最富盛名的著作就是j a n i c kb e r g e r o n 的w d t i n gt e s t b e n c h e s ：f u n c t i o n a l v e r i f i c a t i o no fh d lm o d e l s ) ) ，而工业界最成功的验证产品就是c a d e n c e 公司基于 p l i 开发的t e s t b u i l d e r 。 8 0 年代末到9 0 年代中，随着通讯的快速发展和工艺的进步，集成电路的设计 规模又上了新台阶。在新的验证挑战面前，验证工程师们感觉原有的验证方法和 语言从验证的角度来讲都不够高效，于是出现了专门的高抽象级的验证语言，像 v e a r 、j e d a 、e 语言等。从方法学的角度来说他们都在朝层次化的方向发展，并且 有高效率的带约束的随机引擎。这些语言帮助验证工程师们取得了成功，其中尤 以e 语言为最。 随着9 0 年代末s o c 的兴起，系统中往往有更多的软件参与，这就产生了更 多的系统建模和软硬件协同验证的需求。并且随着芯片的设计规模成指数增长， 原有的这些特殊语言抽象建模【l3 】能力不足的缺点也暴露出来了。于是业界一致把 目标指向了统一的高抽象描述语言，很多人想到了c c + + 。不可否认，c c + + 确实 是一种非常优秀的语言。但是它毕竟不是为设计硬件而发明的语言，在描述硬件 时有其固有的不足，需要在许多方面作层层改装，才可以用于硬件建模。最重要 的是，现在v e r i l o g 拥有众多的使用者，有不计其数的v e r i l o g 代码正在被使用，而 且很多硬件工程师并不是很熟悉c 。基于此，a c c e l l e r a 在2 0 0 2 年6 月推出了下一 代v e r i l o g 标准s y s t e m v e r i l o g 1 8 - 2 0 o 它混合了v e r i l o g 、c c + + 和c o d e s i g n a u t o m a t i o n 公司s u p e r l o g 语言的一个断言能力( a s s e r t i o n c a p a b i l i t y ) ，用以提供更高的抽象层 次。此后，s y n o p s y s 推出了基于s v ( s y s t e m v e r i l o g ) 语言的v m m ( v e r i f i c a t i o n m e t h o d o l o g y m a n u a l ) 验证方法学【2 心4 1 。这种新的方法学因为部件可重用、平台结 构化、以覆盖率驱动和高度自动化等特点大幅度地提高了芯片验证的效率，成为 目前最被看好的验证方法学。 1 2 传统的验证平台 传统的验证平台把被测对象作为最核心的部分事例化在v e r i l o g h d l 或v h d l 语言环境中。验证平台的仿真流程通过一个简单的测试用例文件来控制，该测试 平台采用专门定制的验证平台来为被测设计d u t ( d e s i g nu n d e r t e s o 仓 j 建特别的测 试激励。 图1 1 描述了传统的基于h d l 的验证环境。 这种验证平台具有以下两大特点： ( 1 ) 验证环境包含一组h d l 程序，这些程序用于向d u t 写入数据和从d u t 读出数据。 ( 2 ) 在测试过程中，必须人工选择d u t 的输入激励，并由人工检查结果。 第一章绪论 3 h d l 仿真器 错误报告 测试计划 彳、 ji 事例1 卜 事例2 卜、 i 八 事例3 h d l d u tr _ 波形观察 y t e s t e a s e 叫。 r _ 、 图1 1 基于h d l 的验证环境示意图 当设计规模比较小并且测试环境相对简单时，这种方法能够很好地解决问题。 但对于规模庞大的复杂设计来说，这种方法具有以下致命的缺点： ( 1 ) 缺乏层次化，测试的可读性和可维护性差。 ( 2 ) 缺少很高效的带约束的随机仿真功能。 ( 3 ) 都是直接的测试用例，对于有限的人力来说，不可能考虑到所有的测试 向量，导致很多场景没有被测试到。因此这种方法很难达到比较高的覆盖率。 ( 4 ) 测试过程冗长，花费大量的时间。 ( 5 ) 这种验证平台的可共享代码非常少，平台的扩展性和可重用性差，每次 都需要花费大量的时间开发新的验证平台。 随着集成电路设计规模的不断扩大，传统的验证环境在可重用性、覆盖率、 验证效率等方面存在的缺点越来越明显，芯片开发过程中验证面临的挑战也越来 越多。 1 3 芯片开发面临的验证挑战 随着s o c 的快速发展，从验证角度看验证工程师面临以下挑战【2 5 】： 越来越大的快速产品上市的压力 快速增长的产品开发和验证复杂度 传统的验证方法不能满足今天的验证挑战 标准的e d a 工具也不再满足所有的验证需求 没有时间和资源被分配来学习跟踪最新的e d a 和验证方法 没有时间和资源可以分配到重新开发满足自己需求的验证平台中 软硬件的协同验证的问题 系统仿真速度太慢 还有很多其他的潜在风险，比如在一个公司内部，i c 开发团队经常发现自己 并不具备足够的知识或者是验证专家，不可以为公司定义一个足够好的验证方法 4 基于v m m 的局端u g t c 验证 来解决他们所面临的那些负责的需求。即使有这样的验证专家，他们还是无法避 免开发早期的平台不稳定所带来的验证效率降低问题，以及重新开发所带来的巨 大工作量。 从整个芯片开发的角度，以下挑战也非常关键： 早期的算法评估，包括功能和性能的评估 系统架构评估 早期的软件开发 可重用的规划 仿真速度的问题 以上所有的挑战都要求我们转变现有的验证方法。利用v m m 的层次化、随 机约束和覆盖率驱动等特点，能提升现有验证方法，建立一个通用的可重用的验 证平台。下面将重点介绍目前业界领先的基于s v 语言的、仆n 嗄验证方法学。 1 4v m m 验证方法学 v m m 是一种基于s y s t e m v e r i l o g 语言的验证方法学 2 6 。2 9 】。它在传统的验证方 法学上发展起来，并结合s y s t e m v e r i l o g 的特点通过一系列机制提高了验证的生产 率。v m m 中浓缩了当前最新的技术，包括带约束的随机激励产生【3 0 】，覆盖率驱动 的验证【3 l 】，基于断言的验证【3 2 】，基于开放的以及精心定义的方法学的系统验证。 v m m 的目标就是要创造一个验证方法和验证平台的标准，革命性的改变验证工程 师的工程实践。 为了使验证环境具有较高的效率，最好的发式就是采用层次化的结构。众所 周知，只有精心的规划才能使重用得以实现。为了满足广泛的验证需求，验证平 台【3 3 3 4 】必须具有层次化结构，同时还必须具有相当的灵活度以满足不同验证环境 的需求。v m m 验证方法学将整个验证平台根据功能划分为五个层次：信号层、命 令层、功能层、场景层、测试层，每个层次用于完成不同的功能。 信号层提供与d u t 直接的信号互联。该层提供的信号抽象可以被它以上的任 何层次直接访问，这就保持了平台极大的灵活性。当然功能验证环境和测试用例 应该在底层提供的封装基础上实现尽可能高的抽象，保持完整的层次调用关系， 并避免直接访问接口信号，除非是万不得己。 典型情况【2 1 】下，命令层包含了总线功能模型、物理层的驱动、监测模块、结 果比对模块以及相关的各种接口和d u t 的物理接口协议，而不用去关心d u t 的 具体功能。在这个层中，事务被定义为基于接口的最小数据传输或命令操作，比 如寄存器读写，发送一帧图像。从时序角度来看，典型的基于接口协议的最小操 作是完全根据接口规格书来定义独立的时序图。 第一章绪论 5 功能层提供必须的抽象层来处理应用层事务并验证d u t 功能的正确性。不同 于命令层基于接口的事务，功能层的事务不要求和某个接口或物理事务有一对一 的对应关系。功能层的事务是被整个d u t 或其主要的子系列所执行的高抽象层的 操作，其抽象级远远超过物理层接口模块。一个简单功能事务可能需要执行几十 个命令层的事务，它会根据物理层事务完成的状态来决定重新发送一些事务或者 是延迟发送其它事务。 测试场景层负责提供可控的数据以及事务的生成，缺省情况下负责d u t 所需 的基本激励。该层也包含了一个d u t 配置生成模块，该模块可以从文件中读取 d u t 寄存器的配置值。测试场景是一系列随机的有着某种关联的事务，每种测试 场景代表着一种独立的事务来针对一个特殊的边界功能。 测试层就是测试用例，包括修改激励产生模块的约束，定义新的随机场景， 同步不同的事务并创建直接测试用例。该层也可以提供额外的特别的测试用例， 一般是功能层不提供的事务，并自己检测。该层还提供文件接口来方便快速的测 试用例开发。 图1 2 就是v m m 所倡导并被业界目前广泛认可的层次化验证环境结构图。 o j t e s t 良露：o o ：0 羹羹蠢鬈鬈。：i ，l“* ，kt， 一m ，” 。“7 rt，。 毵皆戮婚泐* 。“篪。：嘧：移x 饿谚羚x * ：。瓤也x 皆x 一雩t 黔争x * i k 赍：嚏露 习艮支拣搿搿搿麓鬈忿礤始心搿骧 辏剩g e n e r a t o r 麟馨辩麓麓饕麓鬈潆 y ，t 舅* 乃：。：s ”a ，s ”y 。” 。4 * 2 y t 。* o 。”= 7 。，：一鬈 象；圣蟹，! ，鹣荔拦c 钇，b ；巍；甄o ，受z 。：“麓乏x 。乏麓* 电盘豢；蔓圣；謦：囊；奄纛；墨! ：；“：；0 ；受0 潦 上 ! l t r a n s a 嘶 r mhc h e c 蛔e ，。一：一，-，。， ，一、| ：， ： t 一 霪茗疆鋈：i：辨ssertions蘸：|：,i一 孤弘4 。酽凸冬4 x ：r 。4 粤强：。冰冬0 旗：善，；为* ，冀冀；冬謦移拳。要t lc “。4 。! 办! 旃“8 。4 。b 4 好赌进0 q虻、知：，为 7 。：77 7 vv了v7 ，“7 一li a ui i i 11一 。、，。 4 ：， lij ? = ：，? 。4 ；，y 。b 。，4 f * 1 “i 。，? f ? r ， r 一，i?ny ? ，r 。，。w 。r * 4 1 ，+ r 7 ，矿* 图1 2v m m 架构图 v m m 的分层结构使验证从信号级抽象到事务级，使验证不须了解d u t 内部 是如何实现的，只须了解d u t 外部需要的激励和时序关系，就可以进行验证平台 设计的工作。 v m m 方法学对制定可重用属性的标准进行了定义，这能有效地对这些属性进 6基于v m m 的局端u g t c 验证 行仿真，并能在形式上对这些属性加以验证。v m m 对创建事务和数据描述的标准 的定义，使得随机地产生受约束的信号而同时又能维持灵活的控制能力成为可能。 v m m 方法学对总线功能模型、监视器( m o n i t o o 和事务处理器( t r a n s a c t o r ) 的设计也 进行了标准化，以便这些模型能为模块级到系统级的验证提供测试激励和检查功 能。另外，在v m m 方法学中，各种验证组件有统一的标准，这样有利于系统环 境的集成。按标准设计的验证组件，可以方便地结合成一个整体，接受控制，并 且以后还可以移植到其他验证环境中去。v m m 还定义了实现覆盖率模型和软件验 证环境的标准。把这些标准一起放在一个连贯一致的方法学中，有助于减少验证 设计所必须付出的努力。 v m m 方法学通过4 个不同的机制提高了项目验证的效率。这四个机制分别为： 断言、抽象化、自动化和重用。 当用断言来鉴别接口的故障或者假设运行目标的故障时，总能在距离故障源 最近的地方和时刻报告发现故障；否则，只有当故障到达被监视的输出口，并被 检查出与期望的输出不一致时，才能检测到故障，这可能需要好几个时钟周期。 有些类型的故障，例如丢失一个数据包，在设计的接口上可以很容易地检测到其 症状。但是有些类型的故障，例如能恢复的仲裁故障，其症状表现得很不明显， 这类故障只是在某类服务中减少一些吞吐流量而已。断言在设计的关键点上设置 了一些监视器，不需要编写独立的测试代码，便能从测试平台的外观察到这些关 键监视点所发生的情况。 在越来越高的抽象层次上进行验证是历史不断发展的趋势。但是与以往抽象 层次的提高有所不同，验证并没有必要伴随着设计抽象层次的提高而进行等价的 提高。低层次的实现和物理细节的验证仍旧很有必要进行。一旦低层次的功能得 到验证，就能借助于层次结构化的测试平台在更高的层次上进行验证工作。单一 的占统治地位的总线功能模型使得我们很难添加或结合新的协议层，对这种情况 需要进行突破。事务处理器的层次化形成了递归层次的抽象化，我们可以借助于 事务处理器层次化所做的工作来促使总线功能模型的突破。 测试必须与特定设计配套的本质，以及响应检查的机制，使得通用验证过程 的自动化不可能完成。真正的测试自动化，应该能产生出与人工编写完全相同的 测试案例，可是这根本就不可能实现。但是随机仿真能模拟自动化，让被测试器 件自动仿真，精心设计的随机信号源，最终是可以生成想要的激励的。随机激励 也将能生成一些目前也许还不能预知的有显著意义的测试信号和条件。当随机激 励源不能生成所需的激励信号时，或者所需的激励不能用无侧重的随机信号源来 产生时，验证者可以对激励信号源施加约束，以便增加产生人为规定激励的概率( 有 时可达1 0 0 ，即激励完全由人工来控制1 。由于激励的随机本质，很有必要用覆盖 率机制来识别到目前为此哪些测试案例己经准自动地产生过了。对己完成的测试 第一章绪论 7 案例的个数进行统计，这样就可以把精力集中在那些留下的有待满足的验证需求 上。 代码的重用避免了重复编写功能相同的模块。重用不只是限于项目执行过程 中代码的重复使用，最重要的重用是同一个项目中的很多个测试案例都使用同一 个验证环境完成。若能坚持尽可能多地重复使用代码，则只需添加几句代码就能 完成某个特性的验证。最终，将能把高度重用的部件经过简单的配置，将其组合 起来，构造出针对某个设计的专用验证环境或平台，随后就能方便地完成测试工 作。 1 5 本文研究内容及章节安排 本文主要研究如何基于v m m 验证方法学搭建一个高效的、层次化的、可重 用的验证平台。课题来源于海思g p o n ( g i g a b i t c a p a b l ep a s s i v eo p t i c a ln e t w o r k ) 系 列的一款o l t ( o p t i c a ll i n et e r m i n a t i o n ) 芯片开发项目，该芯片主要为接入网提供网 络侧与核心网之间的接口，u g t c 是其中一个极其重要的模块。本文就是针对 u g t c 模块搭建一个高效的、易扩展的、重用性好的验证平台，来满足该芯片以 及后续类似芯片中u g t c 模块的验证需求。在验证平台开发完成的基础上，本文 研究了u g t c 测试用例的开发策略，并开发测试用例完成了u g t c 所有功能的仿 真验证。 本文各章的内容安排如下： 第一章，主要介绍了验证方法学的发展史。讨论了传统验证环境的实现方式 及其缺点，提出芯片开发所面临的验证挑战的同时研究了v m m 验证方法学。 第二章，分析了u g t c 的实际工作环境，并基于v m m 验证方法学构建了 u g t c 的验证平台，讨论了u g t c 的验证流程。 第三章，分析研究了u g t c 验证平台中各个验证组件的具体实现方法，包括 场景产生器、参考模型、接口、总线功能模型、自动比较器等。 第四章，通过分析代码覆盖率和功能覆盖率的优缺点得出u g t c 测试用例的 开发策略，并对u g t c 进行了仿真，给出了代码覆盖率的最终结果。 第五章，为本文的总结。 第二章验证平台的搭建及验证流程 9 第二章验证平台的搭建及验证流程 2 1u g t c 模块分析 在g p o n 系统【3 5 - 3 7 】中，光线路终端o l t 位于局端，为接入网提供网络侧与核 心网之间的接口，通过光分配网络o d n ( o p t i c a ld i s t r i b u t i o n n e t w o r k ) 与各光网络 单元o n u ( o p t i c a ln e t w o r ku n i t ) 连接。作为p o n 系统的核心功能设备，o l t 具 有带宽分配、控制各个o n u 、实时监控、运行维护管理p o n 系统的功能。o n u 为接入网提供用户侧的接口，提供话音、数据、视频等多业务流与o d n 的接入，受 o l t 集中控制。 u g t c 是o l t 芯片中一个相当重要的模块。它一方面在开窗时完成对o n u 上报的p l o a m 消息的提取，以保证o n u 能够顺利上线，另一方面还要在正常业务 时完成对上行突发数据的定界、提取，对数据进行一系列处理后分离出相应的数 据送到不同的接口。除此之外，u g t c 还需要根据光模块所给的数据状态信息和 对数据处理的结果产生一系列的告警，主要有l o s 告警、l o s i 告警、l o f 告警、l o f t 告警、s 6 告警、s d i 告警、t i a 告警、r d i 告警等。 u g t c 的工作环境如图2 1 所示： 图2 1u g t c 工作环境示意图 u g t c 从b w f i f o 获得下行带宽的分配信息后对b c d r 恢复出来的上行g t c 帧数据进行定界、提取，经过解扰、f e c 解码、b i p 校验后分离出p l o a m 消息、 d b r u 数据、g e m 数据送到相应的接口。m p i 主要对u g t c 进行一些参数的配置 和表项的读写。 u g t c 模块的规模很大，要完成的功能很多。所以需要搭建一个强大的、高 效的验证平台，以实现既能完成u g t c 所有功能的验证又能为整个项目节省比较 1 0 基于v m m 的局端u g t c 验证 多的时间这样一个目的。 2 2 验证平台搭建 通过分析u g t c 模块的功能和工作环境，基于v m m 验证方法学所提倡的验 证架构，本文将u g t c 的验证平台分层为信号层、命令层、功能层、场景层和测 试层。 2 1 1 信号层 鉴于s v 语言的优势，在信号层定义多组端口i n t e r f a c e 用于和u g t c 端口连 接，通过i n t e r f a c e 就可以采样和驱动u g t c 端口信号的值。 2 1 2 命令层 在命令层中，根据u g t c 实际的工作环境构建相应的总线功能模型。m p i 模 块、b w f i f o 模块、p l o a m 模块和u g e m 模块的功能互相独立，所以构造对应 的四个总线功能模型：m p ib f m 、b w f i f ob f m 、p l o a mb f m 和u g e mb f m 。 考虑到光模块的数据状态信息和上行数据帧的关系紧密，本文将两个模块的功能 集合到一个总线功能模型g p o nb f m 里面。这样既减少了一个环境组件，使环境 更简洁，又可以降低信号处理的难度。b f m 通过相应的i n t e r f a c e 对u g t c 的端口 信号进行操作。 2 1 3 功能层 u g t c 模块对数据的处理比较多，如果直接根据u g t c 送出来的数据内容进 行判断则难度相当大，而且在数据随机时这种做法也显得无能为力。所以本验证 平台采用搭建参考模型和自动比较器的方法来对u g t c 输出的数据进行检测。在 功能层中需要设计两个组件：参考模型r m 和自动比较器c h e c k e r 。r m 是对u g t c 功能的行为级建模，没有时序的概念。r m 对数据进行处理的过程不必要跟u g t c 保持完全的一致，只要最终输出的数据正确就可以，采用的方式越简单越好，这 样可以极大的减小出错的可能性。c h e c k e r 用来完成对u g t c 数据和r m 数据的自 动对比，测试人员只需要关注最后结果即可。采用这种自动比较方式一方面减轻 了测试人员的工作量，另一方面也提高了仿真验证的效率。 2 1 4 场景层 u g t c 正常工作需要两种类型的数据，一是下发的b w m a p ，在b w m a p 中包 含了每个t c o n t 的带宽分配信息；二是上行的g t c 帧，g t c 帧包含了每个o n u 的数据。在场景层中，有两个组件用来产生这两种类型的数据，分别是b w m a p _ g e n 第二章验证平台的搭建及验证流程 和u g t c p a c k c t _ g e n 。b w m a p _ _ g e n 用来产生下发的b w m a p 数据，u g t c p a c k e tg e n 根据b w m a p 数据和环境配置产生相应的上行g t c 帧。鉴于上行数据帧的基本特 性都是一样的，在场景层中，通过扩展v m m 提供的基本类v m md a t a 产生一个基 本帧格式的类b a s e p a c k e t 。u g t c p a c k e t _ g e n 通过例化b a s e p a c k e t 产生基本数据帧， 再根据b w m a p 数据和环境配置产生最终的上行g t c 帧。为了便于控制和覆盖更 多的场景，在这两个组件中需要设置相应的参数和随机变量。测试时可以通过修 改参数值和随机变量的约束范围来产生不同的工作场景。 2 1 5 测试层 测试层包含了很多直接或随机的测试用例，在测试层可以根据需要修改参数 的配置值以及随机变量的约束范围从而产生更多的场景。在测试层中除了要构造 正常情况下的测试用例，还要考虑到异常的情况。这就要求验证平台在构建时留 有足够的灵活性。 u g t c 验证平台的架构如图2 2 所示： 图2 2 u g t c 验证平台 1 2 基于v m m 的局端u g t c 验证 b a s e p a c k e t ：基本帧格式。包含数据的长度、净荷类型，产生数据包、比对数 据包的t a s k 0 ，主要用于后面g e n e r a t o r 和c h e c k e r 的调用。 u g t c p a c k e tg e n ：调用中产生数据的任务，根据带宽分配情况和具 b a s e p a c k e t 体的配置产生需要的包，然后组装成完整的上行g t c 帧后分别送给r m 和g p o n b f m 。 b w m a p：根据配置产生上行带宽的分配以及上行数据的组成情况，生成gen b w m a p 表送给u g t c p a c k e t 、 。gen b w f i f ob f mr m b w f i f ob f m ：产生上下行的8 k 帧头，下行8 k 帧头用于控制b w m a p 的发 送时间，上行8 k 帧头用于控制上行帧数据的发送时间。根据下行帧头，b w f i f o b f m 将b w m a p 数据按照f i f o 时序送给u g t c 。 g p o nb f m ：根据8 k 帧头按照u g t c 的接口时序把上行数据送给u g t c ， 并模拟光模块给出正确的数据状态信息。 m p ib f m ：根据m p i 的读写时序配置u g t c 的表项或读取u g t c 相关的统计 数据。 u g e mb f m ：根据u g t c 和u g e m 模块的接口时序接收送出来的g e m 数据 和d b r u 数据，然后将这些数据送给c h e c h e r 进行比较。 p l o a mb f m ：根据u g t c 和p l o a m 模块的接口时序接收送出来的p l o a m 数据，然后将这些数据送给c h e c h e r 进行比较。 r m iu g t c 模块的参考模型。根据b w m a p 信息对上行数据进行定界、解绕、 f e c 解码、b i p 一8 校验、c r c 校验，并提取出g e m 数据、d b r u 数据以及p l o a m 消息分别送给自动比较器进行比较。 c h e c k e r ：结果自动比较模块。主要完成对r m 和b f m 送出的数据进行比 较的功能，b f m 送出的数据是u g t c 进行数据处理的结果，如果两者结果相同则 p a s s ，否则f a i l 。 c o m m a n d ：测试命令集。包含了一些通用功能的函数和任务，如c r c 校验的 函数、加解扰的任务等。在验证组件中只需要直接调用这些函数或任务即可，不 用多次出现相同的代码。这样环境简洁了很多，层次也更清楚。 t e s t c a s e ：测试向量。每一个测试向量有一个p r o g r a m 结构，在p r o g r a m 结构 中实例化验证顶层的类，控制整个验证平台的运行。测试向量中可以修改场景产 生器的随机约束范围和配置参数，这样就能产生各种需要的场景。 2 3 验证组件开发方式 本文通过类( 对象) 的方式来封装和实现这些验证组件的功能。每一个验证组件 就是一个类，与这个组件相关的数据和操作统一放在这个类里面。这样处理可以 第二章验证平台的搭建及验证流程 1 3 使整个验证平台的结构变得清晰，并且更容易维护和重用。 由于u g t c 的验证平台是基于v m m 开发的，v m m 提供了很多有用的基类， 这些基类包括v l l l me i l v 、v i l md a t a 、v m mx a c t o r 、mc h a n n e l 、v m m 等。_log 所以可以通过例化或者扩展这些基类来生成验证组件及搭建验证平台。本文所设 计的各个验证组件都是在扩展恤d a t a 、v m mx a c t o r 的基础上实现的，这样有利 于在验证顶层统一管理这些组件，而验证组件是通过扩展v i n mc n v 实现的。通过 例化v m mc h a n n e l 可以得到用于数据通信的数据通道，灵活的运用数据通道不仅 可以实现组件之间的数据传输，还可以协调组件进行工作。v m m 提供的基本类 v n l ml o g 可以用来打印信息。相对于传统的用d i s p l a y o 打印信息的方式，用 v l l a ml o g 打印信息具有更好的可控性。 u g t c 验证平台各个组件开发方式如表2 1 所示： 表2 1 验证组件开发方式 验证组件 开发方式 b a s e p a c k e tv m 1 l ld a t a 的扩展 b w m a p _ _ g e n 瑚x a t o r 的扩展 u g t c p a c k e t _ _ g e n v m mx a t o r 的扩展 口i b f 】v i n mx a t o r 的扩展 b w f i f ob f mv m mx a t o r 的扩展 g p o n b n 订v m mx a t o r 的扩展 u g e m b f mv n l mx a t o r 的扩展 p l o a mb f m皿x a t o r 的扩展 r mv m mx a t o r 的扩展 c h e c k e r v m m _ x a t o r 的扩展 c o m m a n d自己开发 t c s t c a g e 自己开发 2 4u g t c 验证流程 仿真验证是指在软件的环境下模拟硬件电路工作的实际情况，完成对设计电 路的功能测试，从而提高芯片设计的成功率。 在验证的初期，要有明确的验证计划：验证平台需要完成的功能、验证平台 的架构、验证环境编码所使用的语言、测试用例开发的策略、验证完成的标准以 及仿真所用的工具等等，所有一切与验证相关的都要考虑到，并作出明确的计划。 1 4基于v m m 的局端u g t c 验证 通过分析u g t c 的功能和工作环境可以得到u g t c 的验证需求，根据u g t c 的验证需求来确定验证平台需要完成的功能。验证平台的搭建包括两个方面，一 个是架构，另一个是语言。本文所设计的验证平台是由s v 语言+ v m m 架构搭建 的，仿真结果分析采用自动比较+ 图形界面d e b u g 的方式。 在验证平台各个组件的详细设计方案确定后开始验证环境编码，这样就避免 了在设计方案不确定的情况就进行编码带来的多次返工。 完成验证平台编码之后，需要对r m 和r t lc o d e 分别仿真调试，减少自身的 缺陷，然后再将两部分合在一起作集成验证，并相互检查结果是否一致( c r o s s c h e c k i n g ) ，逐步实现r m 和r t lc o d e 的收敛。 u g t c 的验证按时间段划分，大体上分为3 个阶段： 第一阶段，验证平台只产生一帧上行g t c 帧，如果测试通过，编写一些简单 的测试用例，检测r m 和d u t 输出结果是否一致。不一致的话则定位、解决问题， 直到r m 和d u t 收敛。 第二阶段，开始逐条增加测试向量的仿真，这时应该有一定数目的测试用例 编码已经完成，测试用例的仿真可以分为直接测试和随机测试两种测试方法。直 接测试是针对u g t c 的f e a t u r e 做逐条测试，一条测试用例只是指定地验证某条， 或者某几条f e a t u r e ，而随机测试则是在一定的随机约束之下，对多个互相影响的 相关功能做验证，随机测试所产生的激励是随机的，可以通过改变随机种子来改 变随机测试的随机序列。正是因为具有这种不定的特点，随机测试才常常会发现 一些c o m e rc a s e ，或者意料之外的b u g 。 第三阶段，在完成大部分功能的测试后，开始进行回归测试，并同步地进行 覆盖率分析、t cr e v i e w 等工作，发现测试遗漏的地方，及时补充测试向量，加入 到回归测试中。如果设计做了修改，除了要增加新的测试用例以外还要将之前测 试通过的用例都进行回归。因为设计修改了就会出现一些新的逻辑，这就有可能 引入一些新的问题，导致之前测试通过的功能出现问题。回归验证就是用来检查 修改是否正确以及修改是否影响其他功能。这种验证是有针对性的对某些已经进 行过的验证的某些子集再重新进行验证，以保证修改不会传播没有预料到的副作 用。 回归时除了增加直接测试外，还要增加随机配置测试，直到测试结果覆盖率 达到要求为止，当覆盖率分析结果满足要求，并且在较长一段时间内没有发现电 路缺陷时，可以结束功能验证。 综上所述u g t c 的验证流程可以用图2 3 来说明： 第二章验证平台的搭建及验证流程1 5 图2 3 u g t c 验证流程图 2 5 本章小结 本章首先分析了u g t c 模块所要完成的功能和工作环境，在掌握了u g t c 验 证需求的基础上，基于v m m 验证方法学的验证架构，设计了u g t c 模块的验证 平台。u g t c 的验证平台由五个层次组成，分别是：信号层、命令层、功能层、 场景层、测试层。每层包含相应的验证组件，负责完成不同的功能。除此之外， 本章还分析介绍了u g t c 的验证流程。 第三章验证组件的设计 1 7 第三章验证组件的设计 3 1 数据结构和格式 从外部输入u g t c 的数据主要有三部分，一部分是c p u 对u g t c 的配置数据， 另一部分是上行数据包激励，还有一部分就是b w m a p 数据。c p u 对u g t c 的配 置数据是通过m p ib f m 按照接口时序写入u g t c 的，这些数据主要用来完成对 u g t c 表项的配置。上行数据包激励来自b c d r 接口，u g t c p a c k e t产生上行gen g t c 帧后通过数据通道送给g p o nb f m ，g p o nb f m 按照b c d r 接口时序将数 据输入u g t c 中，经过u g t c 处理后再分发给u g e mb f m 和p l o a mb f m 。 b w m a p 数据中包含了下行带宽的具体分配情况，由b w m a p 产生后通过 转化为时序送给 ，要根据这些g 信e n b w f i f ob f mf i f ou g t c u g t c 息对上行数据 进行定界、接收、提取处理。 u g t c 是整个上行数据的入口，所以它处理的数据格式是上行的g t c 帧。上 行g t