Browse > Home / 信息中心 / SNUG / 2003年论文集 / 利用 IP Workbench 结合 SystemC 构建复杂芯片系统验证平台

利用 IP Workbench 结合 SystemC 构建复杂芯片系统验证平台


邬旭永 凌魏 张克亮
华为技术有限公司　固网逻辑部
wuxuyong@huawei.com lingwei@huawei.com klang@huawei.com

摘要

本文中我们将对使用Synopsys IPWB结合 SystemC技术完成项目开发的一些心得体会与大家进行讨论，并针对开发中利用参考模型进行自校验的方法进行论述，希望大家提出宝贵意见。

1.0 引言

在本文中我们将对 Synopsys IP Workbench 实际应用中一些收获和体会简陈于下。限于篇幅和一些其他原因，我们将只讨论工具与设计方法方面的问题，对具体项目不做详述。

我们从2000年开始接触IP Workbench（IPWB），在与 Synopsys PSG （即现在的SPS：Synopsys Professinal Service）专家组多次接触的过程中，我们逐渐了解和熟悉了这套仿真验证工具，并最终选择了该产品作为我们一个重大项目（以下简称ICXXX）的验证工具。结合我们利用 SystemC 为芯片的模块及系统建立的参考模型，成功高效的完成了该项目的集成和系统验证阶段工作。

2.0 复杂芯片系统在验证中面临的问题

随着芯片复杂度的上升，验证工作的复杂度和工作量呈指数上升。实现部分RTL代码每多一倍，验证的工作量往往要增加到4倍甚至更大。相对上世纪末几十万门的芯片系统，目前动辄上千万门的芯片的验证工作量已无可避免的成为芯片设计的大部分工作。目前的复杂芯片的整个设计团队往往是验证人员占到大部分，然而芯片系统的 TTM（Time To Market） 的重担，每每仍然都落在项目中验证阶段，问问每个正在忙得焦头烂额的验证负责人，往往都是一句话：“我们需要增加人力！”增加人力是个办法，对于一个几百万门的芯片，如果你用上100个验证工程师，经验丰富的管理者，利用上有条不紊的CMM流程，多半能及时完成计划。然而如果真的这样作的话，这个公司也将无法生存下去，原因很显然：成本！用最少的人力成本达成既定的目标永远是投资者的追求目标，也是人类加速发展的重要动力。芯片系统要尽快推向市场，目前可以认为验证已经成为极重要的一环，甚至是最重要的一环。但是如何利用已有的资源和工具高效率的完成验证呢？

方法学：

验证复杂度和工作量的急剧上升，方法学的提高成为必需和必然。方法学的目的也不外乎：减少工作量、提高效率、提高验证效果。目前各种方法层出不穷，但是注意：采用新方法带来的学习成本。
工具、语言：

说到验证工具Vera、Specman、Testbuilder、TelecomWorkbench……让人眼花缭乱，验证语言C/C++、E、systemC、SystemVerilog、Tcl/Perl ……不知如何选择。同样，当你完成艰难的选择之后，学习将是一个艰苦的过程。
经验：

缺乏有经验的设计人才，是事实。而有设计经验的验证专家更是少，专家的作用并不是他能一天比你多编多少行代码，而是他能给你指明方向、能告诉你陷阱在哪，告诉你如何聪明的做事，省下来这些工作量和时间比多编几行代码重要的多。
验证的完备性、高效性、权威性：

验证的完备性，即最大可能地验证设计的各方面特性，提高覆盖率；

验证的高效性，即用尽量少的时间来完成验证工作。此处“时间”既指验证人员的工作时间，又指验证中设备、软件的工作时间；

验证的权威性，即需要保证验证计划、验证激励的生成、验证结果分析等等环节、要素的正确性，以确保通过验证的设计的正确性。

Synopsys IPWB 除了提供workbench工具本身，还提供了针对整个验证流程、方法的用户服务以及强有力的技术支持，从工具语言、方法学、经验丰富的资深工程师三个方面，全面提升客户的能力。站在别人的经验之上，你会提升得很快。 概括地说，利用IPWB能够快速地定义各种复杂的IP业务激励，可以缩短验证人员的工作时间，即直接提高效率，同时在有限的时间内验证人员可构造更多的测试用例，因此能间接提高覆盖率。此外，由于该工具开发队伍的高水准和工具用户全球化以及与协议标准的兼容，在验证激励生成和结果分析方面保证了其正确性和权威性。

3.0 IP Workbench 的引入

具体到项目，验证可以分为：制定策略、创建环境、测试执行三个阶段。

策略阶段最重要，也主要有三部分：测试向量规划、测试平台策略、激励产生和结果分析策略。测试向量规划和具体的项目相关，其目的主要是采用最小的测试集完成最佳的测试效果，这和经验、方法都相关。

测试平台策略的问题：首先是平台的架构，一个合理、高效、易扩充的架构；然后是具体的实现技术：用什么语言、怎样和HDL对接（大多数复杂的验证都不用HDL做平台开发语言）、仿真过程中的动态控制、自动化及回归测试等。

激励产生和结果分析策略：激励产生方法：全覆盖激励、受控激励、随机激励及受控随机激励、边界覆盖激励。利用自定义的一些激励描述的语法和小工具产生激励，利用工具进行结果解析，结果比较以及自动校验等等。

由这些策略为指导，根据项目需求，寻找合适的商用测试平台。然而，目前EDA 产品之中对宽带部分的工具库几乎是一个空白。宽带产品需要更多的是经验和对系统的熟悉。但是面对宽带中大量的协议标准，接口模型，流量模型等等繁杂的工作，难道我们就只能 DIY 吗？

IPWB 给了我们一个比较满意的答案，IPWB 实际上是Synopsys TWB（Telecom Workbench）家族的一员，其TWB 产品包括：IP ATM SDH PDH SONET ETHERNET等模块。

IPWB 产品实际上是一个工具库的包，其利用C++作为基本的建模语言，并集成了与HDL 的接口。产品分为几个部分：

1、IP data 激励器

2、IP data 分析器

3、专用转换接口（POS_PHY3，SPI4）

3、HDL 接口 (用PLI实现)、DCI（动态控制接口）

以使用时的灵活程度来分，可以将此产品的应用分为初级应用和高级应用。或称为原工具包应用和用户自定义扩展。工具包中原有定义的部分使用比较方便，如图：

图1.IPWB 运行结构示意图

用一定的语法来写generator.cmd和analyzer.cmd文件，就能产生激励和简单分析结果。IPWB 的命令非常丰富，能满足客户的各种需求。激励主要有：

1、定义一个IP包的各个域的值：checksum可以自动计算

2、各域值定义的方式：可以是给定值，也可以是递增序列，也可以是文本中的自己随意定义的一堆数据，还可以是PRBS伪随机序列，非常灵活。

3、多个包形成流，流定义的功能也十分强大。可以定义流速率、单个流占总带宽的百分比、包之间的间隔（间隔可以是恒定，也可以是服从柏松或高斯分布的序列，最大限度的模拟实际情况）。

4、还可以在payload中加入TimeMark信息，用于分析侧对流量提供强大的分析和统计功能。比如速率、平均速率、丢包率、时延、乱序等。

从这些命令可以看出IPW的方便和实用，能快速、高效的组合出各种各样复杂的激励，而且尽量拟和实际情况。

高级应用其实是在其原有的基础上扩展用户的项目需要的独特的部分，或者是工具尚未支持的部分。主要有Custom Function 、DCI 和 API 扩展应用几种方式，目前我们用得比较多的是Custom Function，即根据项目的特殊需求，自己编写用户函数来完成特殊的激励包格式，比如IP包前面还需要加其他的封装。DCI是一个非常灵活的功能，能让你在仿真过程中，和被测对象进行实时交互。而普通模式是：预先产生数据，让后运行，然后再分析数据，按部就班的一步一步运行，在运行过程中，是不能根据被测对象的反馈来灵活的改变激励和仿真过程的。当然，DCI固然功能强大和灵活，但也要考虑到DCI的使用也是复杂的，而且绝大部分测试用例，用普通模式就可以完成。

4.0 SystemC 在验证中的作用

对于一个复杂项目的验证，一套好的工具只是一个方面，一套有效的验证策略和验证方法则是更重要的关键。实际上验证策略的万灵丹是没有的，我们必须根据每个项目的特点指定适合该系统的验证方法，是直接写testbench 和 case 还是利用已有的重用资源进行扩充，还是借助成套的工具包，或是编写系统的参考模型解决系统设计的同时解决验证，又或是专门为验证制作参考模型以供冗余比较等等，这些都根据项目的规模和复杂程度，团队的积累和后续开发的需求，人员技能资源组成，合作的资源，项目的预期投入和产品时间表等等有着必然的关系。

如果验证中确定要利用参考模型，SystemC 作为一种工具语言是一个非常不错的选择，SystemC 其实是 C++ 的一个类库，可以看做熟悉C++的硬件设计人员专门为硬件设计集中统一编写的一套库，这一点的思路倒是很象TWB。当其在芯片系统中被用来构建测试平台的参考模型时，可以说是物尽其用。

从最高层的抽象建模到最低层的硬件建模，SystemC的建模方法可以分为一下几种：

无时间概念的建模方式：也就是时间触发型的建模方式，这种建模方式非常适合与功能建模，模块间的通讯方式为抽象的接口数据。模块的执行都是在0时间执行的。

有时间概念的建模方式：这种建模方式仅仅是在模块中引入执行时间而已，譬如要求一个操作在多长时间内不能执行完毕等。

总线周期精确的建模方式：这种建模方式实际上就是在采用时钟来同步各个模块的执行，各个换句话说就是各个模块的执行是通过时钟来触发的，但是在模块内部仍然采用有时间或者无时间的建模方式，并不要求内部操作与时钟同步。

时钟精确的建模方式：也就是最底层的硬件建模方式，要求模块内部每一步的操作都是受时钟的严格控制的。RTL建模可以看作是时钟精确建模方式的一种具体形式。

这四种建模方式并不是孤立的，可以互相渗透混合建模，SystemC所推崇的逐步提炼的设计流程就是基于这样的建模方式的。从下图的设计流程我们可以很清楚的看到这几种建模方式的关系。
图2. 建模设计过程示意图

这几种建模方式或说层次在设计工作中的地位和具体用法是不同的，我们这里不再展开讨论。在我们的设计中，根据需要，我们采用了无时间建模方式用于系统级的功能验证。

无时间建模用于系统设计层次的功能建模。系统层次的建模需要满足两个条件：第一就是满足系统的功能需求，这是最基本的。第二个要求就是模型必须易于修改维护，由于系统层次的建模开始于系统设计阶段，其从开始到最后的变化可能会非常大，因此在系统建模初期考虑好模型的后续修改维护工作，尽量减少后续维护修改的工作量应该是非常明智的。而SystemC基于C++的这一特点，其提供的面向对象的编程方式为程序后续的修改维护提供了极大的方便。

我们的设计主要用于各种协议的处理，各个模块间的接口协议非常复杂，考虑到接口协议定义的不稳定性，以及接口协议修改的工作量。在接口设计上我们采用了STL中的vector数据类型定义接口：

sc_in<vector<sc_uint<8> > > inport；

sc_out<vector<sc_uint<8> > > outport；

同时统一定义模块内部使用的标准的接口协议类，为每个模块定义模块号，在模块内部通过统一的转换函数把vector中的数值转换为各个模块需要的类定义

* Vector2desc(inport, Module, Indesc);

经过转换后,模块只要处理标准数据类型Indesc就可以了，处理完毕后通过另外的转换函数把Outdesc转换为vector输出就可以了

* desc2vector(Outdesc, nextModule, outvector);

（* Indesc和Outdesc为自定义的接口协议类。）

这种统一定义函数以及类定义的工作，其初期工作量相对较大，但是它为后续的工作提供了巨大的方便。

5.0 结合 IPWB 和 SystemC 搭建复杂芯片系统验证平台

在我们最近的芯片系统的验证过程中，我们充分利用了 SystemC 和 IPWB 的长处，为该系统搭建了一个自动化的验证平台。需要说明的是，该平台只针对系统测试，即所有模块和接口合并以后的测试。对于芯片内部的模块测试，我们仅采用SystemC 进行参考模型的运行结果比较，如图：

图3 单元测试方法示意图

可以发现，我们在局部测试的时候已经不得不借助 SystemC 的参考模型完成自动的校验检查了，对于系统测试中 RM 更是责无旁代的验证主力。我们结合IPWB 和 RM 的优点，设计了一套 RM 和 HDL 同时运行、自动校验的机制，如图所示：

图4 集成测试方法示意图

框图说明：
a）符号说明：

b）流程说明：

首先，由预定的表项将 RM 和 ICXXX 的被测系统做相同的配置。

然后框图中包头产生部分根据 cmd、def、dat 文件 产生本case 预定的包头激励。这部分利用HTAG_GEN 的用户定义函数解析def 文件来完成包头产生。即 。

在包头产生完成后，利用set_error_field 和用户定义函数来进行入口信息的嵌入，由于PAYLOAD 部分在ICXXX 和RM中都是不处理的，所以利用它来完成激励到分析器的信息承载。刚才产生的包头内容将被复制到整个包末尾的若干byte当中，紧接在OH 之前将还需要添加上上面表格中的Inf 信息（13B）。供分析器分析包时使用。这样的包就是即将发向ICXXX的完整的包了。 ，其中灰色部分的位置将按照固定的规律填入数据，比如counter。

经过BFM和ICXXX的处理，一部分的包被转发到BFMA的接口，这时BFMA 将接收经过ICXXX处理的包，此时的包的头部已经被处理成NH了， , 用户定义函数将根据Payload 中承载的OH 和Inf 等信息内容将其恢复成原始的包文格式， 并输入给RM作为激励。RM将其经过处理后将输出生成自己的包头NH’,在正确的情况下NH’应与NH相同 ，用户函数将NH’与NH进行比较，实际上可以全部包文比较，得到该包是否正确处理的结果。其中灰色部分需要按照固定的规律进行检验，用来检查DUV在处理过程中是否把某些局部数据改错了。

对于送往CPU的包的检验流程基本相同（如图）。CPU接口需要额外承担的任务就是丢包的校验，Ref 是本CASE 中各原因应该丢包的记录和总的发包数的记录。本数据可以由RM事先或即时生成，本处不赘述。在每次case 结束时将由CPU 接口读出ICXXX 的统计值与预计结果进行比较。如果三处的result 都没有异常，说明本CASE 测试通过。

以上的过程主要是通过IPWB中的UDF（User Define Founction 或称为 Custom Founction）实现的，IPWB 很重要的贡献在于生成流量和提供 BFM 的 HDL 信号接口，如果自己实现工作量将很大。

6.0 结论(几点体会)

● 虽然以上的一整套方法能够解决绝大多数的测试 CASE ，我们在实际操作中却不可避免仍然需要一些特殊的 CASE 需要单独处理，比如性能测试、表项老化测试等等部分无法利用整套的解决方案，需要个别动手构建测试环境。

● 由于我们的芯片不止处理标准 IP 包，即使处理 IP 包，其IP之前的封装长度也不确定，所以无法使用 IPWB 来构建激励，这就使我们在构造激励时也不得不定义一套自己的语法，并编写相应的工具，大大提高了编写 testcase 激励的速度。繁此种种有很多细节将会影响到整个团队的工作效率。

● 程序运行中打印的多少极大的影响程序的运行速度，因此做回归测试时尽量减少打印信息，避免不必要的大量打印将非常有助于提高运行速度。

● 整个验证环境运行的自动化需要有一套好的方法，我们的环境结合了gmake、cshrc 和 perl，感觉比较杂，扩展维护起来也不易，主要是出于重用他人以前的成果考虑。这不是IPWB本身或其他工具能够解决的问题，需要对脚本的熟练运用和较长期经验的积累。

● 我们本验证组的成员都深深感觉，验证工作需要掌握的技能知识太多了，除被验证的系统知识外，语言工具方法技术等等不胜枚举。更新的速度也非常快，对每个验证工程师来说，如何高效的完成一个新的任务都是一个极大的挑战。7.0 致谢

在与 Synopsys SPS 专家和各资深 AC 合作过程中，双方都非常的愉快，我们也受益良多，在此我们再次感谢 Synopsys 的各位专家对我们在 IPWB 方面的极力推荐、细心指导以及对我们提出要求的快速答复和大力支持，特别是来自Synopsys 法国的 Frederic Krampac 先生帮助我们解决了平台建设中的大部分问题，并两次上门指导，给我们留下了深刻的印象。

8.0 参考文献

● 《Telecom WorkBench for IP Reference Manual》 [By Synopsys]

● 《SystemC Version2.0 User Guide》[By SystemC Organization 2002]

● 《Telecom WorkBench User Guide》 [By Synopsys ]

● 《An Introduction to System LevelModeling in SystemC 2.0》[By Stuart Swan, Cadence Design Systems, Inc.May 2001]

● 《FUNCTIONAL SPECIFICATION FOR SYSTEMC 2.0》 [By SystemC Organization April 5, 2002]

● 固网逻辑部技术组内部文档 [By 仿真验证技术组、支撑平台技术组 2000-2003]