数字IC设计概述_ic系统验证思想

一、芯片架构设计

在拿到产品需求书之后，要做芯片的需求评估，确定体系结构和基本组件后，要做其整合做架构评估，以确认设计的体系结构是否恰当、总线是否能满足吞吐量和实现性要求以及存储器是否满足需求等。

Spec文档

芯片整体系统以及细分模块都需要功能详述文档，包含信息：

• 接口信息
  接口版本，标准，若是标准接口，则不需要时序信息，命令，数据传输信息等，只需要时钟，复位，接口信号名；若是自定义接口，则需要详细描述。
• 结构信息
  模块细分为各个功能组件，以及逻辑关系；
• 交互信息
  模块和外界模块交互示意图，时序信息

ESL设计

ESL（Electronic System Level）设计方法学的目的在于提供让设计人员能够在一种抽象层次上对芯片进行描述和分析的工具和方法。

文献1解释了ESL设计没有大规模应用的原因，提出只有大厂才有能力支撑ESL模型的开发。

本人预测，未来的20年里，只要以LLM为代表的人工智能大模型持续火热，对DSA开发的需求就会一直存在，而掌握了用户群的大厂经过财务的成本评估，也一定会跟进DSA的开发，那么为了追求DSA芯片的性能和投入成本，系统级建模一定必不可少。

二、数字IC逻辑设计

1 设计过程

整体上分为系统设计到电路/逻辑设计，最后得到GDSII文件后交由Fountry生产
（1）系统设计
   根据产品Spec，制定编码规范，设计实现算法，然后开展架构设计。例如可以用SystemC进行性能估算和仿真，确定设计中采用的数据通路结构。如设计中需要多大乘法器，采用何种滤波器，采用并行还是串行方式，是否需要流水线等；在该过程中，需考虑那些模块用IP完成，哪些自己实现。
（2）电路/逻辑设计
数字IC设计一般分为前端设计和后端设计，前端完成硬件逻辑的编码设计验证工作，后端完成逻辑综合、时钟树综合、物理版图设计、等价性检查、静态时序分析、功耗分析等过程

2 低功耗设计

3 DFT设计

芯片出厂后运用一种算法检测芯片错误，这种算法（差异算法）实际上是一种固定输入对应唯一输出的逻辑，这种逻辑可在芯片设计过程中确定

4 功耗分析

功耗分为静态功耗和动态功耗。

动态功耗分析事关芯片功能和性能，设计过程中就可以根据动态功耗情况对设计进行反馈。

参考链接：安全验证 - 知乎

三、数字IC逻辑验证

验证贯穿了设计的每个阶段，验证是为了穷尽所有的可能的情况给设计产生激励，在各种激励情况下监测出不符合硬件描述的行为并提交到前端设计解决。

绝对好文，验证新手入门，老手总结：IC验证的一种最佳实践：pandora-v0.5

 http://www.ee1024.com/thread-176665-1-1.html

软硬件同时工作，协同仿真的概念：如何验证复杂的RISC-V设计-电子工程专辑

3.1 基本验证知识

验证流程

1. 制定功能规范
   通信接口的规范、必须实现的功能和触发设计的条件
2. 编写验证计划
   验证计划要解决的是what的问题，即要验证的内容；具体包括具体测试和方法，所需的工具，完成标准，需要的资源和详细进度，待验证的功能，未被覆盖的功能

3. 开发验证环境
   是使验证工程师可以发现设计缺陷的一系列软件代码和工具的集合。包括基于模拟验证的测试激励生成和检查机制；形式验证环境的规则生成等，具体可有：
   1）搭建测试平台（testbench）
   2）编写测试用例
   3）参考模型

4. 调试硬件设计和环境
   将验证环境和HDL设计集成起来，运行测试集来调试硬件及环境

5. 回归测试
   是验证计划中定义的测试集的完整运行，当在某个缺陷修复或功能修改后，按照以前所有的测试用例（testcase）和可能添加的新的测试用例进行测试。
   测试要求：
   1）确保本次改动修复以前的漏洞，没有引入新的缺陷，实现了新功能。
   2）递交不同的随机种子（random seed）进行随机测试，确保每次测试都能提高功能覆盖率

6. 硬件制造
   流片，将芯片设计交给Fountry（Tape-out），流片前需有一个检查列表来追踪所有的项目（物理的和逻辑的），此前回归测试的错误发现率应接近0
   流片期间验证仍在进行

7. 调试流片后的硬件

   芯片流片完成，且通过了制造测试，芯片被装配到测试台或专门的系统中，运行真实的软件
8. 逃逸错误分析
   对真实硬件中错误的分析，在验证环境中尽可能重现这个错误，改进测试计划和环境
9. 常见的中断验证周期的情况

验证阶段

可划分为前端仿真和后端仿真。前端主要为了检测功能逻辑的缺陷，RTL、门级仿真都是不带时序的仿真，主要用于功能验证。后端是为了检测问及电路由延迟导致采样失败所产生的功能缺陷。

前端验证包括
RTL功能验证：行为级功能验证，无延时的理想情况
门级仿真：验证综合后网表的功能是否与期望相符
形式化验证：保证门级网表与RTL代码的等价性

为了便于拆解功能模块，方便分工协同，通常会把进行分层次验证，以手机通信芯片为例：

1. 系统级验证
   系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证。也就是说系统级验证侧重于验证芯片的输入输出；从寄存器检查和数据检查入手，实现定向测试子系统间的交互协作。
   
   在系统级验证中，往往要构建虚拟目标系统，如中科SoC芯片在实施验证时，将其所有对外接口挂接许多虚拟 IP核，同时编制了BIOS、RTOS及应用测试程序（包括驱动程序）。首先做功能验证，验证是否满足要求; 其次做软硬件性能验证; 第三做系统级基准测试（自顶向下验证策略），抽取特定功能，编制测试向量/程序，定义对错条件，覆盖所有功能，形成基准测试程序（反复迭代），用于模拟仿真。
   
   功能仿真: 主要关注模块-模块（IP核-IP核）间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。
   
   对于一款裸机CPU来说，系统级验证的激励输入是一段段C代码程序或者汇编程序，而针对目标CPU所采用的指令集，需要相应的该指令级工具链将 .c 或 .asm转换成 .bin文件，并输入到CPU的指令存储器中；同时，转换时还需要考虑到该款CPU的寄存器初始化，整个系统初始化等，需要将boot初始化代码、syscall代码、crt代码一同链接到bin文件中，使CPU在从系统、寄存器初始化等指令处开始执行。
   
   对于内含操作系统的CPU来说，初始化和系统调用则更加复杂。
2. 子系统级验证
   需完成设计包；验证包；回归测试表；覆盖率收集脚本和数据；完整的文档（设计，验证，集成，后端）
3. 模块级
   考虑的因素：内部功能（状态机等）；内部数据存储；数据打包，编解码；指令执行；寄存器配置；与其他模块，子系统，芯片系统以及电源开关的互动情况
4. 应用扩展验证
   在系统级验证之后，对特定应用场景验证。

验证透明度

1. 黑盒测试
   只使用模块端口验证， 不关心实现细节， 不访问内部逻辑。
   但是该测试透明度较低，导致无法深层次地定位问题，从而解决一些较深的缺陷。
   应用场合：对设计细节缺乏认识。
2. 白盒测试
   使用模块端口和内部信号验证，可以植入监视器和断言来检查各个内部逻辑，从而对底层的设计细节进行测试。但是该测试专注于设计内部逻辑检查而忽视整体功能测试，且一旦设计更新，验证文件的可复用性很差。
   应用场合：了解内部工作逻辑、层次，信号等。
3. 灰盒测试
   实际应用场合中通常将黑百盒两种测试方法结合。其特点是前两种测试折中。
   只使用模块端口验证， 完全了解实现细节， 模拟时仅访问少数内部逻辑

验证方式

1）动态仿真

通过测试序列和激励生成器给入待测设计适当的激励，跟随仿真进程的推进，判断输出是否符合预期。

1. 定向测试
   激励内容在仿真前确定下来，测试用例给出的激励序列不会在下一次提交任务时改变。一般应用在模块测试早期或这系统级芯片测试场景中，它适合于测试设计的基本功能
2. 随机序列测试
   通过预先定义的约束，每次随机产生合理的数值，通过激励产生器给出测试序列。使用随机激励时，需要用功能覆盖率来评估验证的进展情况
   随机序列数要尽可能多一些，否则很有可能error检测不出来。
3. 参考模型测试
4. 断言检查
   针对某特定的逻辑或时序进行预设，一旦设计的实际行为不符合断言的描述，则给出检查报告。

2）静态检查

本身不需要仿真、波形激励，可通过工具的辅助发现设计中存在的问题。在设计早期发现功能实现意外的设计问题，完善设计代码。检查方法包括：

1. 语法检查
2. 语义检查
   在语法检查的基础上做深入检查，检查范围包括设计错误，影响覆盖率收敛的问题，可能会产生X值以及受其影响的设计部分
3. 跨时钟域检查（CDC）
   跨时钟通信要考虑同步问题，由此导致的随机性可能会导致建立时间和保持时间无法满足，导致功能失败。
   跨时钟可能带来的问题和解决办法：
   1）Glitch
       在A->B两个时钟域交叉的部分若存在组合逻辑电路，B在不同时钟的驱动下可能会检测出不应被检测的A信号边沿变化。
       解决办法：在A、B输入和输出侧添加触发器
   2）亚稳态
       在B端信号发生变化式，B端输出电压尚未稳定，若扇出多个信号，对应器件接收可能会翻译成不同的逻辑值。
       解决办法：B端使用两级Flip Flop
   3）convergence
       由上述亚稳态问题而使用的两级FF输出时有可能会存在1个cycle的延迟
       解决办法：使用一些逻辑电路来识别这个延迟，并根据延迟的影响判断是否需要做修改
     
   CDC检查的步骤
   结构检查：电路结构的检查
   检查信号的协议
   jitter检查：动态的插入jitter，检查后续电路的稳定性
    
4. 形式验证
   形式验证可以通过数学方法遍历状态空间，进而证明设计行为符合属性描述。
   
   等价检查：
   用数学方法证明原模型和输出模型逻辑是等价的，转换保持了相同的功能。可以比较两个netlist来保证一些后处理（扫描链插入、时钟树生成或手动修改）没有改变电路的功能
   
   模型检验：
   也就是属性检查，电路的行为通过验证语言来描述其属性，随后通过静态方式证明在所有状态空间都满足该条件，否则举出反例。
   关于形式验证的11个误区 - 半导体/EDA - -EETOP-创芯网

验证环境

验证环境由Testbench、测试用例、运行脚本等要素组成。包含了验证结构中的各组件，组件间的连接关系，测试平台的配置和控制，编译仿真流程，结果分析报告和覆盖率检查。

1）testbench
平台包括时钟/重置，激励发生器，DUT，比较器，监测器五个组件

验证评估指标

覆盖率是检测验证效果的基本指标。

1）代码覆盖率

语句覆盖率：
也叫做块覆盖率，检查HDL的每一行代码是否被执行过
一些好的具有保护性的代码语句没有运行是正常的（检查代码覆盖率时应把保护性语句排除在代码覆盖统计之外。）

表达式覆盖率：
相比语句覆盖，粒度更细。

条件覆盖率：
每个条件中的逻辑操作数被覆盖情况

分支覆盖率：
指在if, case, while, repeat, forever, for, loop语句中各个分支执行的情况

事件覆盖率
记录某一个事件被触发的次数

翻转覆盖率
记录某个边界信号数据位的0/1跳转情况

状态机覆盖率
记录状态被进入的次数，以及状态间的跳转情况。

2）断言覆盖率

记录断言的先决条件是否被触发，以及判断语句成功或失败。基本可分为基于动态仿真或者硬件加速的断言覆盖率和形式验证的静态断言覆盖率。

3）功能覆盖率

主要关注设计的输入，输出和内部状态，衡量是否实现设计的各项功能，且是否按预想的行为执行。主要检测代码覆盖未检测到的错误。

功能覆盖属于黑盒测试，只关心功能，不依赖于实际的代码，功能覆盖涉及到测量一些相关值，不能从RTL级设计代码中自动提取，必须进行人工操作。

3.2 验证技能

验证环境的构建

Verilog TB构建参见链接:

IC验证——testbench编写_KGback的博客-CSDN博客_ic验证

SystemVerilog TB构建参见链接:

IC验证——SystemVerilog学习_ic验证必须要用system verilog语言吗-CSDN博客

UVM见链接:

IC验证——UVM学习_KGback的博客-CSDN博客

动态仿真工具的使用：

IC设计——EDA软件篇——xcelium-CSDN博客

IC设计——EDA软件篇——VCS使用_vcs 显示多维数组-CSDN博客

便携式测试用例：

数字IC验证——PSS可移植测试用例_pss验证-CSDN博客

验证代码生成和规范检查类工具开发，比如AutoTB：

数字IC验证——AutoTB-CSDN博客

四、数字IC物理设计

参考链接：IC后端设计——后端设计过程_KGback的博客-CSDN博客

数字IC类别

SoC

SoC设计与验证——概览索引-CSDN博客

CPU

参考文献

1. 在体系结构黄金期，ESL设计方法学能否“焕发青春”? - 知乎