路科V0验证学习笔记（一）
前言
在学习路科验证V0内容的过程中，可能是能力不够，作为初学者的我（C、Verilog基础）学习起来并非那么轻松，并且完成理论学习以及实验后仍有许多不理解之处，对于大量知识点的冲击，我属实一下很难接收，所以写下学习笔记，来记录学习的知识要点，以帮助自己以及其他志同道合的同学复习验证方面知识。
学习内容来自B站路科验证教程，为了方便学习，还加入部分了我的学习感悟和理解，帮助理解记忆，感兴趣的同学建议配合路科教学视频使用，欢迎评论互相学习！
开始学习之前我先给初学验证又被打击到的小伙伴们打个气，可能想转行，听说路科验证很好，来试学一下，结果发现连V0都听不明白，不禁自我怀疑。 请不要这样想，V0内容大体分为6小时的理论和5小时的实验 ，理论部分并非听故事，理论部分的传授内容的量是其实相当大的，可以说基本把绿皮书都粗略的走了一遍。 从数据类型到过程语句、子语句，到测试平台，到面向对象编程，到随机化操作，到线程通信，到覆盖率讲述。基本上把绿皮书的内容都杀了一遍，显然只花6小时的时间就想把绿皮书的内容学懂，是很不容易的事情（尤其有些小伙伴还加速看...）
所以路桑把V0认定成小白扫盲课是很有道理的。学完理论课不是说你就学过SV（systemVerilog）了，远远不够！配合实验也是让小白走一遍验证的流程，不是说做完实验，你就能自己上手了，我在学习的过程中就发现自己代码根本下不去手，全程看答案（solution）。但是学完后如果你能对整个ic验证有个大体的认识，并觉得自己对这方面感兴趣，愿意以后做这方面的工作，我觉得就够了，再进行更深的学习。
芯片验证全视
要入门芯片行业，首先我们得知道一颗芯片是如何从0到1生产出来的。芯片的生产开发经历许多流程，可以用如下图片概括。
1. 从市场人员与客户沟通开始。
2. 系统设计人员按照功能划分为各个子系统。
3. 子系统被进一步划分为功能模块，并由设计团队实现。
4. 验证人员对设计功能展开验证，发现设计缺陷，交由设计人员修正。
5. 验证没有出现漏洞后，交由后端人员进行综合、布局、布线。
验证和设计都需要认真阅读功能描述文档，设计会将其翻译成RTL模型，验证会按照其功能发送激励和比较结果。设计和验证岗位要分开，不能一个人独揽设计和验证工作，因为自己设计出来的东西，自己验证的话，很容易漏掉自己设计时候就存在的bug，尤其是设计大规模的电路。（功能描述文档：产品经理要求芯片能够具有的功能，运算、存储、数据传输等。有了功能描述文档，设计人员就可以读功能文档，把功能转换成电路，用verilog语言实现出来。 RTL模型：Register Transistor Level 寄存器级别。）
整个芯片的开发流程是自顶向下的，而集成过程又是自底向上的。
对于一个验证工程师需要检查：
设计文件是否正确地按照功能描述文档实施了？
硬件设计人员是否有遗漏的边界情况？
硬件设计是否足够稳定处理错误情况？
如果设计与功能描述存在明显不符，验证人员需要报告设计缺陷，同时设计人员应修复设计，这样从验证到设计再转回验证即完成一个缺陷检测和修正周期。当设计和验证人员存在不可调节的分歧时，应寻找系统设计人员进行“裁决”，明确设计思想，统一功能理解。功能验证完成后，后端人员（backend）将RTL文件综合生成门级网表（gate netlist），同时进行布局布线，最终使物理电路可以在设定的时钟频率上工作。
相比于20年前的定向激励和测试通过率，目前SoC的动态验证技术将依赖更多的途径来量化验证进度。动态验证会涉及代码覆盖率和功能覆盖率，断言，随机约束。Verilog标准手册500多页，SV的标准手册有1300多页，SV有更多的约束。学完了SV紧接着就要学UVM验证方法学，必须从最底层的SV开始学起。（SOC：system on chip 片上系统。SV：system verilog。 UVM：Universal Verification Methodology 全局验证方法学，UVM是验证的方法，不是一种代码，笔试选择会遇到。）
验证有很多技术，静态验证技术与动态验证技术是完全不同的两种技术，静态验证技术又可以分为人工形式验证技术（即属性检查，property check）和自动形式验证技术。属性检查是通过断言结合形式验证工具对设计功能进行穷举检查，从数学意义上判断设计的正确性；自动验证技术包括SoC集成连接检查，死锁检测，X语义安全检查，覆盖范围可及性分析以及许多其他可自动提取然后正式证明的属性。
Emulation和FPGA原型开发即是在SoC开发中后期系统趋于稳定时，将其作为逻辑功能容器进行原型（prototyping）开发，相比于仿真技术，其速度更快，而可调试性不及仿真，同时其单体售价较仿真器要昂贵。（是一种工具，也是验证功能的一种方法）
在做验证的过程中，给出的激励向量，应该是先易后难的，发现的缺陷也是先基本后高级，假如到了验证后期，缺陷率尽管在收敛，但是却发现了基本缺陷，那么这时就要对整个验证质量打一个问号。
功能验证有着一套完备的流程，从硬件系统定义贯穿到硅后测试部分。每一个项目在进行瀑布模式的开发时，验证团队也会在细分的流程当中完成任务，同时在展开下一项任务之前会进行一些重要检查点（checkpoint）的回顾工作。.
验证周期的起始点是从创建验证计划开始的，而验证计划需要参照系统工程师给出的功能详述文档。在创建验证环境的过程中，验证人员一般会邀请设计人员和系统人员一同回顾验证计划，确保验证计划没有明显的遗漏，所以验证计划的回顾是第一个检查点。
测试人员比对设计的输出结果，如果发现比对有错误，验证人员需自己去调试环境，并且定位到硬件HDL文件存在缺陷的大致位置。
完成回归测试之前，我们需要进行第二个检查点“验证代码检查”，这一检查点的作用是通过回顾验证代码从而发现可能遗漏的测试激励、不恰当的随机约束、代码结构的缺陷等。
完成回归测试之后，我们进行第三个检查点“流片前验证完备性检查”，对于验证经理他会根据一份检查清单来将量化的验证进度综合评定，最后考虑是否已经完成验证的任务。
即使在最终流片以后，验证团队也需要和硅后系统测试团队完成对接。在经过系统测试以后，验证团队会就最后被硅后测试发现的缺陷展开逃逸分析，检讨为什么漏洞会在硅后测试环节中被发现（而不是在硅前验证环节）。
