SV学习笔记（二）-芯片验证概述

什么是验证

• 证明设计功能正确，符合设计功能描述的流程

• 确认产品功能、服务或系统是否符合规则、要求、规范和强制条件，通常是还没有面向客户的内部过程，看有没有“把事情做对”

• 验证要占据前端设计70%左右的工作量

什么是测试平台

 

• 对DUT(design under test)创建测试序列

• 观察DUT的输入输出

• 对DUT的输出数据与预期数据进行对比

• 报告检查结果

设计与验证要不要独立工作

• 如果是一个人同时做RTL设计和验证的话（不规范）

  

   

• 如果是不同的人做RTL设计和验证的话

  

   

芯片开发流程

 

• 从市场人员和客户沟通开始

• 系统设计人员按照功能划分为各个子系统

• 子系统被进一步划分为功能模块，并由设计团队实现

• 验证人员对设计功能展开验证，发现设计缺陷，交由设计人员修正

• 验证没有出现漏洞后，交由后端人员进行综合、布局、布线

• 后端将核心数据交由FAB进行流片

验证和设计的紧密关系

• 设计如果没有经过验证，是没有任何信心去流片的

• 设计如果没有经过充分验证，是不够信心去流片的

• 设计如果没有经过充分量化验证，是缺一点信心去流片的

• 验证如果不懂设计，发现了漏洞是没法跟设计好好沟通的

• 设计如果不懂验证，是没法体会验证已经在慢慢转向软件化的

• 设计需要验证尽早尽快尽量地去测试设计发现漏洞

• 验证人员需要行业的尊重，使其认识到验证为公司带来的价值

• 设计和验证都需要围绕功能描述文档

• 设计初步实现之后需要验证入场

• 验证发现结果不符合预期时，如果漏洞明显可交由设计修正，带返回再测试；如果功能实现与设计存在分析，则需要共同回顾功能描述，决定哪一方理解正确，统一对功能的理解

• 在系统由低层向高层集成过程中，验证与设计需要在每一个层次展开各自工作，确保验证在每个阶段的充分性

验证人员做了哪些工作

在设计人员根据设计功能描述，实现各个模块RTL代码之后，开始构建验证环境，做几项工作来检查设计：

• 设计文件是否正确地按照功能描述文档去实施了

• 硬件设计人员是否有遗漏掉的边界情况（corner case）

• 硬件设计是否足够稳定来处理一些错误情况（error response）

验证和设计的协作

• 验证和设计都需要认真阅读功能描述文档

• 设计会将其翻译为RTL模型

• 验证会按照功能发送激励和比较结果

验证的概述

• 重大缺陷造成额外的成本损失时越靠后越巨大

• 缺陷率增长曲线的曲率有事逐渐减小的

• 快而全地提供缺陷率增长是理想目标

 

验证的目标

• 对于一名验证工程师(verifier)，他的工作就是完成分配给他的任务，这个任务可能是模块级(module level)、子系统级(subsystem level)或者系统级(chip level)

• 准确来讲验证的目标，就是“按时保质低耗”完成目标硬件设计的验证工作，这句话实际也包含了要完成验证目标需要考虑到的三个方面

  • 按时

    • 需要按照项目预先的进度来考虑验证的节点(milestone)，在项目一开始的时候就将节点挂在心里

    • 要知道“一个都不能少”在芯片流程中的重要性，没有一款芯片可以因为其中一个模块的验证延迟而又信息去流片

    • 整支验证队伍自上而下，覆盖到各个模块的验证人员都应该又这意识，时间是第一位的，时间就意味着客户的耐心和市场的窗口

  • 保质

    • 尽可能少的将缺陷暴露到流片以后，至少要尽可能少的暴露在客户和市场面前

    • 从成本的角度来看，缺陷暴露在不同阶段造成的损失是指数递增的，而且，如果芯片交付给客户以后才被反馈出一些大的缺陷，那么芯片设计方会背负很大的压力，除了要同客户进行高密度的对话、联调，整个产品链都要为这个缺陷付出巨大的人力物力成本

    • 如果芯片是在客户一侧通过测试却被市场发现自身性能不如预期，那么芯片设计公司和客户双方都会造成消极影响，无论是从市场反馈，还是用户对品牌的认知度上面都是如此

  • 低耗

    • 一是用更短的时间，更少的人力来完成芯片设计任务，这对芯片设计公司而言，是一笔前期看得见的可以预期控制的成本

    • 二是某些成本是突发的，在不同研发阶段暴露缺陷，其造成的额外成本是会影响芯片项目成败的

验证周期