一 芯片开发概述
开发流程：
1. 从市场人员与客户沟通开始
2. 系统设计人员按照功能划分为各个子系统
3. 子系统被进一步划分为功能模块，并由设计团队实现
4. 验证人员对设计功能展开验证，发现设计缺陷，交由设计人员修正
5. 验证没有出现漏洞后，交由后端人员进行综合、布局、布线
6. 后端人员将核心数据交由FAB进行流片 pre-silicon
验证和设计的紧密关系：
- 设计如果没有经过验证，是没有任何信心去流片的
- 设计如果没有经过充分验证，是不够信心去流片的
- 设计如果没有经过充分量化验证，是缺一点信心去流片的
- 验证如果不懂设计，发现了漏洞是没法和设计好好沟通的
- 设计如果不懂验证，是没法体会验证已经在慢慢转向软件化的
- 设计需要验证尽早尽快尽量地去测试设计发现漏洞
- 验证人员需要行业的尊重，使其认识到验证为公司带来的价值
- 设计和验证都需要围绕功能描述文档
- 设计初步实现后需要验证入场
- 验证发现结果不符合预期时，如果漏洞明显可交由设计修正，待返回再此时；如果功能实现与设计存在分歧，则需共同回顾功能描述，决定哪一方理解正确，统一对功能的理解
- 再系统由底层向高层基础过程中，验证与设计需要在每一个层次展开各自工作，确定验证在每一个阶段的充分性
开发流程>>>>>>>>>>>
系统结构 -> 子系统及模块定义->硬件设计及功能验证 -> 自动后端综合布局布线 -> 驱动，固件及软件开发
<<<<<<<<<<<<<<集成过程
验证人员做了哪些工作？
在设计人员根据设计功能描述，实现各个模式RTL code之后，开始构建验证环境，做几项工作来检查设计：
- 设计文件是否正确地按照功能描述文档去实施
- 硬件设计人员是否遗漏掉的边界情况(corner case)
- 硬件设计是否足够稳定来处理一些错误情况(error response)
note：验证人员的发送的激励和要做的比较都是依赖于功能描述文档
验证目前面临的挑战：
1. 如何穷尽所有可能的情况给设计产生激励
2. 如何在各种可能的激励情况下判断出不符合硬件描述的行为并报告出来
分类：仿真验证和形式验证
二 验证任务和目标
验证的目标：“按时、保质、低耗”
必须按照项目预先的进度来考虑验证的节点
尽可能少的将缺陷暴露在流片以后
功能验证是唯一可以用低成本在硅前流程将上述目标达成的方法
三 验证周期
验证周期中的检查点：
模块功能详述 验证计划问题 验证代码检查 验证完备性检查
创建验证计划 -> 开发验证环境 -> 调试环境和HDL文件 -> 递归测试 -> 硅后系统测试 -> 展开逃逸分析
功能描述文档：
- 接口信息
- 结构信息：将模块进一步细分为各个功能组件，以及包含组件之间的逻辑关系
- 交互信息：包含模块之间交互信息图
该文档是硬件设计和功能验证的基础部分，也是共同参考依照的标准
制定验证计划：
- 验证方法：直接验证、随即约束验证、形式验证
- 验证完备标准：量化出一些参数可以衡量验证任务是否完成
- 验证的功能点：需要给出验证的功能点，以及在什么层次去验证它，更具体的包括生成何种激励，检查设计ID何种状态和数据输出
开发环境：
从搭建环境开始，实现激励产生器(stimulus generator)、参考模型(reference model)和数据比较器(data comparator)
note：不同的验证方法会决定不同验证环境的结构使用软件
验证人员在调式方面的时间投入最多
调试环境好RTL文件：
- 环境是否有瑕疵
- 测试序列是否合理
- 参考模型是否遵循功能详述文档
回归测试：
去验证硬件在某个缺陷修复或者添加了某项新功能以后，仍然可以通过以前的所有测试用例和可能添加的新的测试用例
目标——
1. 确保这次改动没有引入新的缺陷
2. 由于随机验证在每次递交时，默认的随机种子不同。伴随功能覆盖率，可以通过王府的回归测试和补充定向测试来将逐步提高验证完备性
逃逸分析(Escape Analysis)!!!
硅后测试失败在硅前验证重现难度更大
