转眼自己已经硕士毕业快两年了，时间过得很快。保持头脑清醒找准方向比努力更重要，所以作为一名技术工程师应该每隔一段时间就要跳出技术细节好好思考下自己做过的和未来要做的事情。这次谈谈自己从事芯片验证工作中学到的知识和感受吧。
我们到底需要干什么？
芯片验证就是保证设计满足预期和需求。第一步便是制定验证计划，要知道验什么，怎么验，哪个先验，哪个后验，哪些能一起验。SoC验证的先决条件是认为IP都没有问题，当然这只是假设的理想情况。那重点关注的就是IP的例化、连接，IP之间的匹配性，IP与CPU的协同运作。归结为一句话：带有功能属性的连接性检查。故通过总线实现寄存器访问、DMA传输、中断响应、IP与IP协同工作、IP与I/O交互数据、时钟复位、基本功能、异常响应处理以及特殊工作模式下状态都是必不可少的检测点。特殊工作模式常见的是low power。
这是只是基本套路。如果待验证IP是在之前基础上更新的产物，那更新feature非常容易出问题。你以为这就结束了？这仅仅保证了功能正确，现实往往还需要分析performance和power。验证是伴随着整个设计流程推进的。当RTL确保没大问题了，接下来要检测被SDF反标的netlist行为是否与RTL一致。总不能全部case都跑一遍，deadline不允许，那保留哪些呢？高速数据传输、I/O相关。当时钟频率变高，出问题的风险就越大。I/O上也经常会出问题，比如8bit位宽的数据一起翻转，结果其中一bit往后延迟了0.2ns导致所有数据错乱也不是不可能。
该如何验证呢？
在上一小节提到的验证task有被惯性思维束缚的意味，为什么这么说？人们从项目中发现写测试用例这种动态仿真方式没办法覆盖到所有场景，因为有时候你根本不知道用户会怎么用。这时候遍历穷举的老方法随着计算机和EDA技术的高速发展又进入到工程师的视野。
相对的静态验证即是采用这种思想。用工具遍历所有可能激励，自动观察响应与预期的关系。笔者之前参与过IOMUX的静态连结性检查，它就是利用Synposys厂家的property formal verification (PFV) 配合Verdi观测波形分析连接性。静态验证由于工具比较傻，所以只能使用脚本来做许多前期处理，主要是文件操作和正则匹配任务。静态仿真如此强大还要动态仿真何用？naive，你以为端口连接与预期一致就能保证功能无误？打个比方，A和B两个模块，A的输出连接到B的输入。当A输出高脉冲时，B输出信号b拉高。使用静态仿真方式发现连接是对的。但是A输出的脉冲宽度没有达到B的输入要求，结果就是信号b始终为0。
所以呢，动态仿真更贴近真实场景，而静态仿真可以覆盖到边界情况。不难看出，芯片验证是没有尽头的，因为那个所谓的“边界情况”也可能出现之前例子中的疏忽！顿时下出一身冷汗，兄弟们辛苦两年做的项目变成砖头了。。。这是后可能的补救措施是：在user guide里写明该芯片不支持这一“边界情况”。当然这是后话了。
什么时候是个头？
从静态仿真角度讲，所以已知连接全部正确。从动态仿真角度来说，验证RTL的前仿所有function test case PASS，performance test case PASS, low power test case PASS, IP顶层toggle coverage 达到100%，验证SDF+netlist的后仿所有test case PASS，power gating test case PASS, power analysis test case PASS。再完善点，客户定制项目中用户重点关注功能点相关use case 前后仿均PASS。交差！总结起来时间维度前仿+后仿，方法学维度动态仿真与静态仿真，测试点维度function, performance和power。是不是有点头大了？
怎么快点结束？
资本家压榨劳动力我们还得配合:) 首先和design team的思想类似，复用嘛！已经有的资源就不要重复造轮子，除非时间充裕单纯为了学习锻炼（我干过这事）。可复用的东西很多，包括VIP、testbench、script、test plan、test case、EDA tool usage甚至是包含这一切的整个flow。所有验证需要的资源都能够通过分析表格一键生成岂不美哉？除了自己闷头干，高效率沟通在较大项目中尤为重要。现在chip规模大的吓人，你所有模块都懂对于普通人短短几年时间是不可能的。很多时候问下别人就能快速解决，至少也能提供一个思路。再有一点：拉低完美主义的优先级，先做出来再完善是永恒的策略。
这都是方法层面，时间层面主要包含两点：加快仿真速率和多task并行跟进。仿真毕竟是软件模拟硬件行为，时间进度推进1ms到真实时间慢的时候要按小时计算。提高仿真速率应该是未来必然趋势了。高性能服务器是一方面，更经济的办法应该是减少编译次数，减少需要编译的面积，提高clock频率，去除与当前test case无关的配置操作。。。这个仿真在执行，就看看另一个bug有没有被修复。
如何更胜一筹？
SoC验证就是系统级验证，了解更多MCU结构和工作原理事半功倍，所以尝试着去验证和SoC工作机制本身相关的common模块会给你带来更多的收获。比如DMA、IOMUX、external memory controllor interface、权限访问控制单元、platform、bus infrastructure (fabric)、power control、clock generator等等。
上述知识点会解决你很多困惑：怎么时钟突然不toggle了？这个信号是干什么的？为什么产生异常中断了？CPU hung住了怎么回事？寄存器读写失败问题在哪里？系统进入low power模式后没有被成功唤醒怎么回事？但归根到底，每个人关注的还是具体某几个IP集成到这个chip上的行为和表现。特定应用领域对应特定的IP，懂PLC、网络通信、USB、加密解密等等能避免一头雾水，即使所有case跑PASS了还不知道自己在干什么。
懂知识的同时也要精通手段。system verilog常见用法，写个VIP、testbench、assertion。script功底一键生成C function甚至是test case、definition，分析log file。UVM的约束随机化快速抵达边界条件，基于此的验证平台也可以通过script来自动生成。
写道最后
由于经验欠缺和懒的关系写的比较浅显，算是对一段时间工作生活的记录。从横向和纵向上多接触多磨练一直是本人所期望的。干IC这一行我始终认为挣钱是顺带的事情，可贵的是能干着自己喜欢的事情。