通信人家园

标题: SoC设计验证技术发展综述(一) [查看完整版帖子] [打印本页]

时间: 2014-8-13 09:24

作者: alfredatqq 标题: SoC设计验证技术发展综述(一)

本帖最后由 jeffyko 于 2014-8-19 07:02 编辑

引言随着工艺能力和设计能力的快速发展，为了满足嵌入式系统市场对于成本、功能和功耗的要求，SoC(System on-a-Chip)设计技术已经成为一种发展趋势。众所周知，迄今为止在集成电路发展过程中，摩尔定律（单芯片上所能集成的晶体管数目每18个月翻一番）一直在起作用，因此SoC的规模和功能在不断急剧膨胀，使得设计验证日益重要，向业界提出了巨大挑战，已成为了整个SoC设计流程的瓶颈[1]。

　　目前芯片一次投片成功率只有35左右，造成芯片重复投片的主要原因就是验证不够充分。SoC设计的验证需要投入的资源已占整个设计资源的60~80。1999年当VSIA[1]举行验证专题会时，许多世界级验证专家得出结论：验证是件困难的事（hard）,几周后更把结论更正为"Verification is not hard,it is veryhard"。现在愈来愈达成共识：单一的设计工具难以解决验证问题，而需要一系列复杂的工具和技术，来减少设计错误数，使之qvod 邻家特工英文达到可接受的程度。

　　SoC经过6、7年的发展，有了广阔的市场。SoC验证研究领域在验证技术、验证方法学、测试码提取、验证描述语言、IP核重用验证、验证流程及验证评估方面取得了长足进步。但总体而言验证技术已经落后于设计和制造能力，模拟和验证工作成为整个SoC学科发展的制约瓶颈，给提高设计生产率造成了障碍。如何构建一种更快更好的设计验证方法学是当前SoC业界所关注的问题。

　　SoC验证研究内容

　　SoC验证工作比较繁杂。Janick Bergeron给"验证"下的定义是"证明一个设计的功能是否正确的过程"。SoC的验证工作贯穿整个设计流程，从行为级HDL[2]设计，一直到芯片设计定案之前都需要做足够多的验证工作，当前验证工作已经占整个设计工作70左右。图1是SoC"设计缺陷（BUG）"分布情况，其***能缺陷超过60。可见SoC验证工作重点应在功能验证上。

　　SoC验证研究内容很多，如：IP核/模块级验证（Block-Level Verification）、系统级验证（System-Level Verification）、仿真验证（Simulation）、软硬件协同验证(Hardware/Software Co-verification)、等价性检查（Equivalent checking）、静态时序分析和时序验证（Static timing analysis & Timing Verification）、版图验证（Physical verification）等。随着验证技术的逐步发展，验证方法由最初的直接测试向量生成（Directed Test Vector Generation）,到约束随机测试(Constrainted RandomTest),再到覆盖驱动验证(Coverage- driven Verification),一直到最新的基于断言的验证方法(Assertion-based Verification),各种验证方法在不断创新发展。

　　SoC验证流程与技术

　　3.1 SoC验证流程与计划

　　SoC的验证工作始终贯穿整个设计流程。从阶段划分上说，SoC验证可以分为功能验证、等价性验证、静态时序分析、动态时序分析和版图验证等几个主要阶段，如图2所示。

　　有了SoC验证流程还很不够，需要验证计划（Verification Plan），这为SoC验证工作提供重要质量保证，它规划如何来验证一个设计，主要包括以下内容：

　　1．对模块和顶层的测试策略

　　2．组成标准测试程序（Testbench）的各个组件的定义和规范，如BFM[3]、总线监视器（Bus monitor）等

　　3．用到的验证工具和流程

　　4．仿真环境的定义和搭建

　　5．关键的验证点

　　6．验证工作结束的标准

　　一个高质量的验证计划使得验证工程师可以更早地开发标准测试程序环境。这种并行的开发验证环境，能尽早给验证团队一个明确的目标，也是保证验证可重用（re-used）的关键。为了得到一个高质量的验证计划，验证工程师要正确和充分地理解设计需求和规范，要与设计工程师及时地交互，这样才能保证验证计划的易读、易用和可重用。因此可以说一个好的验证计划可以有效提高验证效率，缩短开发周期，在SoC开发中有着重要的意义。

　　3.2 功能验证内容

　　功能验证（Functional Verification）是验证中最复杂，工作量最大同时也是最灵活的部分，包括模块/IP核级验证、系统级验证、模拟仿真等。

　　3.2.1 模块/IP核级验证

　　任何SoC设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的IP核。不论哪种情况，在系统集成前做IP核验证工作是必需的。模块/IP核级验证流程如图3所示，软性检查(Link Checking)主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等；规范模型检查(Formal Model Checking)主要做设计特征遗漏性检查，以在早期发现错误状况，尤其对控制流设计效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷；功能验证(Functional Verification)主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试（gray-box）等；协议检查(Protocol Checking)主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果；直接随机测试(Directed Random Testing)通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量；代码覆盖率分析(Code Coverage )主要根据模拟仿真时统计代码被执行数，可以按陈述句、信号拴（Toggle）、状态机、可达状态、可触态、条件分支、通路和信号等进行统计分析，以提高设计可信度。

　　3.2.2 系统级验证

　　系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证，如图4所示。

　　在系统级验证中，往往要构建虚拟目标系统，如中科SoC芯片在实施验证时，将其所有对外接口挂接许多虚拟IP核，同时编制了BIOS[4]、RTOS[5]及应用测试程序（包括驱动程序）。首先做功能验证，验证是否满足要求；其次做软硬件性能验证；第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。

　　3.2.3 模拟仿真

　　在复杂SoC设计开发中，模拟仿真占整个验证工程师团队工作量的40~70[1]，由于成本和市场压力，寻找灵巧的仿真技术显得十分迫切。

　　功能仿真：主要关注模块-模块（IP核-IP核）间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。

　　基准测试包：首先搭建SoC整体架构，然后将每一模块（IP核）经基准测试包挂接到系统总线上。这些基准测试包有利于缺陷的识别工作，但它们不是设计工作的一部分，而是为了验证而引入的。基准测试包测试向量来自于IP核供应商、直接随机产生、手工编制或由系统级测试捕获。

　　事件驱动仿真：使用比较普遍，像NC_Verilog、VCS等均支持，但受芯片规模和性能限制。首先设计代码被仿真工具所接受，其次编制基准测试向量（波形或RTL[6]），第三运行仿真，第四通过单步调试，错误定位、改正后可再次仿真。

　　时钟驱动仿真：在每一时钟结束时计算电路稳态响应，不考虑时序方面的问题，时序需要静态时序分析工具来验证是否满足要求。时钟驱动仿真比事件驱动仿真速度要快10~100倍，适合大规模电路仿真。

　　基于传输仿真：传输操作是指传输虚拟部件（TVM[7]）和设计模块间的数据或控制传递，简单的如访存读操作，复杂的如结构化数据包传递。首先获取或编制TVM，其次确定测试内容，第三步编译和连接，第四步进行仿真，第五步作输出分析，最后做功能覆盖分析。

时间: 2014-8-13 11:12

作者: yinhexitaiyang

好，连载

通信人家园 (https://www.txrjy.com/)