1.主流验证工具融合
昆仑平台验证技术首先是基于目前主流验证工具所开发的，所以昆仑平台融合三种工具为一体，从验证策略上寻找验证加速方法。
2.1.主流验证工具特点分析
目前主流的验证工具主要有软件仿真器（如VCS、NC）、FPGA、Emulator硬件加速仿真器三种。然而三者各有优缺点： ① 软件仿真器：DUT最接近芯片真实电路设计，调试手段最多，但仿真速度最慢； ② FPGA：FPGA板级验证速度最快，场景验证最真实，但定位手段最少，效率最低； ③ Emulator：总体介于前两者之间，比软件仿真器速度快，时钟频率比FPGA真实。
2.2.验证工具融合策略支持
昆仑平台通过融合三种主流验证工具的优势，使三者取长补短，从而提供更丰富的验证策略工具包，从现有的工具特点比对中寻求资源的有效利用： ① 支持三套代码和filelist的自动生成，保持代码的一致性； ② 支持三种主流验证工具的验证用例复用。 ③ 支持RTL/门级仿真平台复用； ④ 支持FPGA代码在软件仿真器上仿真，为上板排除低级错误，上板场景在软件仿真器复现 ⑤ 支持FPGA bitfile一键生成； ⑥ 支持Emulator上构造复杂业务场景；
2.多层级验证及其加速技术
一颗芯片可以从系统的不同职能划分出各个子系统，例如外设子系统、视频处理子系统、CPU子系统等，子系统又可以细分为各个IP，每个IP一般具有相对独立的功能，通过配有数据处理接口和软件配置接口来实现和外部的交互；业界一般把IP、子系统、SoC三个层级的验证分别称之为UT（Unit test）、IT（Integration Test）、ST（System Test），本章从层级验证角度论述昆仑平台验证加速技术。
2.1.UT加速
2.1.1.为什么要做UT
芯片验证的最终目的是保证SoC的正常工作，那么为什么要做UT/IT？他们的优势是什么？效率如何？ 由于UT/IT相对于ST来说位置和角度基本相同，以下均以UT为代表展开。 UT的验证思想是先局部问题局部解决、然后从局部走向整体。UT的必要性体现在： ① 聚焦内部功能验证，方便构造性能、随机和异常测试场景； ② 验证环境相对独立，与系统验证环境解耦，调试范围小，时间可控； ③ 编译、仿真速度快，一般认为是ST的5-10倍左右； ④ 减少对系统集成版本的依赖，提早介入，发现性能、接口类问题，服务于IP集成方案；
2.1.2.UT验证平台的使命
同时UT局部验证的劣势也很明显： ① 验证人员的技术水平、经验阅历不同导致UT验证平台多样化 ② 不同类型的IP对UT验证平台的需求多样化，导致UT验证平台多样化 ③ 多样化的UT验证平台最终导致ST移植难度大，需要专人维护，人力投入大 ④ 验证平台通用组件不统一，重复开发，资源浪费 ⑤ 新人搭建验证平台的水平不够，周期长
2.1.3.UT验证平台成果
总结劣势来看，解决UT验证加速的方式是提供一套UT验证平台自动生成方案，目前昆仑平台已开发出一套能够自动生成的UT验证基础平台，成果主要有： ① 以图形界面的方式实现了友好的交互界面，降低上手难度 ② 以C语言和UVM为基础统一平台架构，解决平台多样化问题 ③ 统一平台目录结构，提高可读性和通用性 ④ 统一接口降低UT二次开发的难度，提供完善的二次开发指引 ⑤ 基础封装最大化，使用户聚焦验证场景构造和结果检查 ⑥ 提供简洁的移植策略实现自动化的ST移植
2.1.4. UT加速效率评估
2.1.4.1. 自研IP
从自研IP的UT验证本身来看，自动化方案效率评估如下：
节约搭建基础环境大约5天/人时间
节约移植ST时间大约3天/人时间 总体可以节约50%左右的时间。 相对于直接做ST来讲，节约的时间将会大大超过这个比例。
2.1.4.2. 非自研IP
另外，UT/IT自动化方案除了应用在自研IP的UT/IT验证加速方面，对于外购IP和客户IP的验证，一般会附带自己的验证环境，我们需要挑选测试用例移植到ST上。常规移植方式是熟悉环境和用例，完成测试用例转换，修改外部memory数据比对方式，如果是比较复杂的验证环境，会给验证人员带来较大的工作量。即使一天完成一条用例的移植，那么移植多条用例的工作量也会成倍增加。 而我们需要在移植时，最低限度的修改其环境和用例，一般修改内容主要涉及： a) 编程模型配置接口 b) 外部memory后门操作数据接口 统一化接口在C/UVM/Verilog等主流环境中均开发了这些统一接口，熟悉环境之后，理论上移植一条用例和移植多条用例的时间差别不大，一天时间即可完成用例的移植工作。
2.2. ST加速
UT/IT解决的是IP和子系统的内部问题，系统验证关注的是系统的事。要研究系统验证如何加速，首先要弄清楚系统验证要做什么？
2.2.1. 芯片验证框架
一般验证框架内容主要包含如下： ① 单一业务场景 ② 复杂业务场景及其带宽分析 ③ 系统启动场景 ④ 系统压力测试 ⑤ 芯片异常测试 ⑥ 低功耗场景 ⑦ DFT验证
2.2.2. 自动化与标准化
首先，单一业务场景指单个或几个IP在系统内的工作场景验证，关注IP在系统内的集成正确性、时钟复位方案合理性、性能是否满足等问题。复杂业务场景指芯片实际工作场景中涉及多个IP或子系统的场景，其他像启动场景、低功耗场景都是在单一业务场景之上开展。所以单一业务场景是系统验证的基础和前提。 单一业务场景加速技术研究的实质是找到不同项目的IP分类方法及应对策略。我们把系统中IP分成两类并采取相应验证策略： ① 系统级IP，这类IP通常在不同项目中因芯片需求变化导致原项目IP不能重复使用，通常会选择重新设计，相应的验证环境需要重新搭建，测试用例重新构造。对这类IP我们采用自动化生成验证环境和测试用例的方式来加快验证速度。目前我们已经实现自动化验证的IP有： a) 时钟 b) 复位 c) IOMUX d) PAD e) 总线 f) 中断 ② 非系统级IP指项目间重复利用率高，功能比较独立的一类IP，例如外设类IP、CPU IP。这类IP通常根据经验选择常用的、较为齐全的功能进行设计，然后作为项目储备IP。对这类IP我们采用UT/IT验证做标准化验证。在验证过程中除了验证IP功能外，也会为系统验证做准备。例如准备ST的RTL/门仿用例、场景用驱动等。我们目前已实现部分外设类IP、CPU IP的标准化验证。
2.2.3. 平台自动化
2.2.3.1. 基础平台自动化
和UT/IT自动生成基础环境一样，ST平台可根据芯片IP列表自动生成基础验证环境，并自动把已经标准化的IP环境和用例移植到ST，自动生成自动化IP的验证用例和验证组件。
2.2.3.2. 系统配置信息自动化
芯片系统部分配置信息例如memory map、IP中断分配表、CPU执行地址映射表均已实现自动化处理，生成仿真需要的配置信息。
2.2.3.3. 编程模型统一化和自动化
寄存器描述文档支持业界广泛应用的ralf、xlm格式，自研IP统一为寄存器表格。并在平台内实现自动化处理和生成仿真需要的编程模型组件。
2.2.3.4. 回归测试自动化
开发自动回归测试用例工具，工具具备以下功能： ① 使测试用例并行执行，有效利用硬盘资源 ② 汇总回归结果，报告结果异常的测试用例 ③ 收集合并所有用例的覆盖率结果
2.2.4. 效率评估
假设新的项目中使用的IP都已完成标准化和自动化，单一业务场景理论上2人/周可以完成，这将使得整个芯片验证周期缩短约30%的时间。
3. 设计代码管理原则及其自动化
设计代码做为验证的最重要的入口条件，代码的目录结构和file list原则对代码质量和自动化有着深刻的影响，一定程度上决定了芯片成败的关键，历史上曾因为代码管理问题出现的验证缺陷层出不穷。
3.1. 设计代码目录结构
3.1.1. design目录
① top：顶层和子系统目录 ② IP：模块级IP目录 ③ lib：wrapper和仿真库目录 ④ common：设计代码公共模块目录，如rst_sync.v
3.1.2. top目录
① 各目录以*_subsys为名称创建 ② chip_top：chip顶层目录，包含顶层代码和file list ③ cpu_subsys：cpu子系统顶层目录，包含顶层连线代码和file list
3.1.3. IP目录
以IP名称（字母小写）创建，如axi0、bootrom
3.1.4. lib目录
① fpga：FPGA仿真库目录
② tsmc28hpcp：28工艺仿真库目录
③ tsmc28hpcp/mem：28工艺memory仿真模型，其下按照memory类型建子目录
④ tsmc28hpcp/pad：28工艺pad仿真模型
⑤ tsmc28hpcp/pll：28工艺PLL仿真模型
⑥ tsmc28hpcp/std：28工艺stdcell仿真模型
⑦ wrapper：memory和stdcell wrapper目录
⑧ wrapper/mem：memory wrapper，，其下按照memory类型建子目录
⑨ wrapper/std：stdcell wrapper目录
3.1.5. IP/SUBSYS目录
chip顶层、子系统和IP子目录结构统一，以I2C IP为例（图左边是目录结构，右边是files.f）：
① doc：设计文档目录，包括总体设计文档，寄存器表格,portdefine等
② flow/dc：dc flow
③ flow/smoke：设计冒烟
④ flow/spyglass：spyglass flow
⑤ flow/syntax：语法检查
⑥ flow/vclp：低功耗评估
⑦ src：设计代码目录
⑧ src/asic：存放asic代码及公共代码
⑨ src/fpga：fpga部分代码
⑩ src/stub：stub代码目录，包含与模块实际代码顶层文件名、module名、接口完全相同的.v文件及相关
⑪ src/files.f：IP的filelist文件，包含stub文件、lib文件、代码filelist等，用相应宏切换。
3.2. file list管理原则
3.2.1. 总体原则
① 不可综合的仿真库文件前面加” –v” ② 可综合模块直接指定文件路径 ③ 禁用”-y”选项，dw/sim_ver目录除外 ④ 一个ip必须包含一个files.f和一个lib.f文件 ⑤ stub宏以”STUB_”作为前缀，全大写
3.2.2. files.f原则
① FPGA_SIM宏：控制用于FPGA仿真的file list ② FPGA_SYN宏：控制用于FPGA综合的file list ③ VELOCE宏：控制用于veloce硬件加速仿真需要的file list ④ ASIC_SIM宏：控制用于ASIC代码仿真的file list ⑤ ASIC_SYN宏：控制用于ASIC代码综合的file list ⑥ 默认为ASIC使用手写代码代替工艺库的file list ⑦ 代码中使用的宏define和undef分别汇总到xxx_defines.v和xxx_undef.v，并加在files.f的头和尾
3.2.3. lib.f原则
① 首行必须加`ifndef STUB_XXX ② 每片Memory的工艺库fie list均指向对应区分工艺宏的file list，lib.f的所有file list不区分工艺库宏 ③ LIB宏：控制用于综合时工具所需.db文件 ④ DB宏：控制用于综合时工具所需.db文件 ⑤ LIB_SIM宏：控制用于EDA仿真的工艺库file list
3.3. 加速技术应用
采用自定义宏体系管理file list是众多加速技术应用的基础与核心，在各个加速技术讨论中均有涉及。
3.3.1. 支持主流验证工具融合
分类管理好用于不同验证工具的file list，并通过脚本自动处理使之快速生成某个环境下的file list，能够大大减少工作量，减少手动处理的错误率，保证在不同验证流程的版本一致性。
3.3.2. 支持多层级仿真验证
IP验证需要IP设计人员提供完备的file list，除了RTL代码之外，还应该包括工艺库、stdcell、公共模块等，但当IP集成到系统中时，它的file list极有可能与其他IP的file list冲突，平台会对这些重复的file list进行去重，这样就既能满足UT/IT/ST的仿真需求，又不给设计人员带来额外工作量。
3.3.3. IP/子系统自动dummy
在进行系统仿真时，可适时把一些未参与场景的并且对仿真效率影响大的IP或子系统dummy。通过在测试用例配置文件中填写需要dummy的IP/子系统，自动剔除真实RTL代码而采用dummy的文件取而代之，减少代码编译和仿真时间。
3.3.4. 支持IP标准化自动移植
IP标准化时，设计人员提供的file list路径只针对IP验证环境，自动移植到ST时，需要工具自动处理file list，并在上级子系统或系统的file list中添加IP的file list。
3.4. 效率评估
代码目录结构的统一和file list自动化管理原则从多个方面支持系统设计和验证工作自动化，不仅提升代码维护和交付效率，其更大的意义在于减少了人工参与的工作量，减少了人为因素带来的可能是致命的失误。
4. 结尾
本文主要从平台角度介绍我们在验证加速技术领域的成果，通过支持主流验证工具从而获得更多的验证策略支持，通过支持UT/IT/ST的多层级验证从不同验证侧重点提升迭代效率，通过支持设计代码自动化管理支撑验证多种加速技术的实现。除此以外，我们还在验证质量管理和项目版本管理上取得不错的成绩，极大促进了项目研发周期的缩短和芯片质量的提升 平台是芯片研发的基础设施，是验证理念的承载，我们做芯片平台技术的方向是为优秀的研发人才提供更加友好的用户接口，更加丰富的策略支持，更加快速的入门方式，从而打造出一套战略”轻装备”，快速迭代，缩短研发周期，服务更多想做、要做芯片的人，实现芯片普惠的终极目标
文章来源：芯片开放社区
文章链接：https://occ.t-head.cn/community/post/detail?spm=a2cl5.14300636.0.0.1b87180fKD1nhm&id=641430319395766272
