【Block-LevelVerification】芯⽚开发通识_验证⽬标_验证语⾔_
验证职。。。
SystemVerilog验证通识
1、芯⽚开发概述
不同于通⽤电路，专⽤集成电路为了专门解决或者优化相关⼯程问题，例如专⽤算法的电路实现，如芯⽚⾥加⼊⼈⼯智能处理单元，为CPU\GPU减负，⽬的是提⾼应⽤效率和降低能耗。
芯⽚体积有多⼤？2017年5⽉⼀款芯⽚采⽤12nm FFN ⼯艺，核⼼⾯积为惊⼈的815平⽅mm，⼀共包含211亿个晶体管。⼤于10亿门为⼤型SOC，现在⾮常多，⼀款4G 芯⽚⼤约为40-50亿门。
28nm流⽚价格为 200万美⾦，14nm double，7nm double。
2、芯⽚开发流程（Pre-Silicon）
1、市场⼈员与客户沟通开始，市场⼈员整合⽤户需求。
2、平台的架构师，要把需求分为软件实现和硬件实现，系统设计⼈员按照功能划分为各个⼦系统，⼀般
来讲各个⼦系统是相互独⽴的。
3、⼦系统被进⼀步划分为各个功能模块，并由设计团队实现，交给设计团队实现的是功能描述⽂档，每个模块都有⼀个特定的功能描述⽂档，。
4、验证⼈员对设计（HDL file）开展功能验证，发现设计缺陷，并交由设计⼈员修正。
5、验证没有出现漏洞后，交由后端⼈员进⾏综合、布局、布线。
6、后端⼈员将设计数据交给fab进⾏流⽚。
英语翻译转换器3、验证与设计的紧密关系
1、设计如果没有经过充分验证，是没有任何信⼼去流⽚的。
2、设计如果没有经过充分验证，是不够信⼼去流⽚的。
3、设计如果没有经过充分验证，是缺⼀点信⼼去流⽚的。
4、验证如果不懂设计，发现了漏洞是没法跟设计好好沟通的。
5、设计如果不懂验证，是没法体会验证已经在慢慢转向软件化的。
6、设计需要验证尽早尽快尽量地区测试设计发现漏洞。
7、验证⼈员需要⾏业尊重，使其认识到验证为公司带来的价值。
⼀般⼀个⼤型的SOC设计需要⼀年（10个⽉），如果验证出漏洞，前6个⽉可以在RTL⽂件⾥进⾏修正，后6个⽉要在门级⽹表做修正，越往后期发现漏洞，修复成本就越⾼，需要在系统级、⼦系统级、门级上做修正。
设计和验证都要围绕spec，验证可以超前于设计来搭建验证环境，在拿到spec之后就可以做验证⽂档了。在前期如果发现设计有较⼤的漏洞，不符合预期，反馈给设计⼈员，验证出问题之后，要反馈给设计⼈员，如对spec理解不同，则需要共同回顾。
FPGA的仿真输⼊⾮常低阶的验证，是不能严格意义成为验证的。
4、验证⽬标--验证⼈员做了哪些⼯作？
设计⽂件是否正确地按照功能描述⽂档去实施了？
硬件设计⼈员是否有遗漏掉的边界情况 (corner ca)? 验证⼈员和设计⼈员都会有对spec理解不到位的情况，会有想不到的corner ca，基于随机的验证可能会解决这个问题。
硬件设计是否⾜够稳定处理⼀些错误情况 (error respon) ？在汽车航天领域，对验证的完备性需求⽐较⼤，对错误零容忍，会考虑这样⼀种设计，如果灾难性影响发⽣，我们的冗余设计可以显著地对那些出现的错误情况对整个系统的影响降低，也叫做容错设计。
5、验证语⾔
验证的简单⽬标：在⼀定时间内尽可能多的测试硬件设计，发现设计缺陷并报告出来，同时验证本⾝也书⼀项棘⼿的挑战，这⼀点可以从语⾔发展和各种快速发展的EDA⼯具上得到佐证。
⾯向对象，⽅法UVM是基于Systemverilog语⾔的，动态仿真⼗年内不会过时。
三家EDA公司都在美国，所以有UVM。欧洲现在也有基于VHDL的UVM，VHDL-bad UVM（87和93标准）。欧洲⽤VHDL的多，⽤specman多。
VHDL语⾔（有87和93年标准，还有02，08标准）
Verilog语⾔（95 01 05年标准）
Systemverilog语⾔（09 12 17年标准）因为验证总有⼀些新的需要，所以需要引⼊新的标准，所以验证的发展是逐渐蓬勃向上的
6、芯⽚验证⾯临的挑战
做SOC的公司在国内是占主流的。伴随着芯⽚⾃⾝的复杂度⽇渐提⾼，以及⼀直存在的项⽬进度的压⼒，如何解决验证的完整性和⾼效性变成⼀个⼤家都关注的话题。
验证⽬前⾯临的挑战：
1、如何穷尽所有可能的情况给设计产⽣激励，如何划分出有效的测试空间，以及如何给出随机约束的激励。
2、如何在个中可能的激励的情况下，判断出不符合硬件描述⾏为的设计并报告出来。
3、硬件类型分类，不同设计的激励类型和结果判断⽅法。针对不同的类型、不同的复杂度、不同的集成度的设计，会采⽤不同的验证⽅法。equalization
4、从验证⼯具的分类看，两⼤类，仿真验证、形式验证，从复杂度来讲的话。分为⿊盒验证、⽩盒验证、灰盒验证。
7、验证职业前景
应届⽣要求：
1、微电⼦、计算机、通信⼯程、⾃动化、电磁场相关专业
2、熟悉 VHDL/Verilog、SV等数字芯⽚及验证语⾔参与过FPGA设计或验证
3、具备芯⽚数字综合（SYN）/时序分析（STA）经验
4、了解芯⽚设计基本知识，如代码规范、⼯作环境和⼯具、典型电路（异步、状态机、FIFO、时钟复位、memory、缓存管理等）
5、接触过多种验证⼯具，了解⼀种或多种验证⽅法 (UVM)，并根据项⽬特点制定不同的验证策略、⽅案，搭建测试环境，完成验证执⾏和Debug
6、理解CPU各个模块的详细功能，熟悉CPU体系架构
7、搭建测试平台，指定测试计划、开发测试⽤例
wef8、分析设计问题，帮助定位和修复设计问题
9、分析覆盖率报告，保证CPU核的设计质量
10、熟悉验证⽅法学，掌握SystemVerilog、Verilog、SVA等语⾔。
11、系统级或⼦系统级的功能仿真验证
12、开发脚本以⽀持验证流程⾃动化及仿真结果处理⾃动化、验证流程⾃动化
13、为验证环境编写功能覆盖及断⾔语句以增强功能覆盖率
14、能开发基于架构的测试计划新人教版七年级上册
15、可以在C-model， RTL， Emulator，Silicon上运⾏和调试测试程序并分析和定位功能⽅⾯的架构问题（会使⽤VCS和Questasim）
16、如何从0构建验证环境且量化测试进度，⽽不是修改测试⽤例/增加测试⽤例，⽽不是维护测试环境
17、会写验证⽂档
18、会跑回归测试
cesium19、熟悉脚本语⾔，⽀持验证流程⾃动化和仿真结果管理。
验证与设计同样重要，验证的需求量更⼤，与设计的⽐例接近2:1，甚⾄更⾼。
做验证和做设计的⼈是分开的，验证的知识迭代更短，三年打⼋折，做验证要学的⽐设计的多好多，验证需要不断地学习。
⽹上有CPU开源验证代码可以练习CPU的验证。
8、业内瓶颈
connectionstring
设计业能⼒不⾜，IP核供给不⾜，重点的IP核来⾃三⼤EDA公司，收购⼩的IP核公司可能都弥补不了产业链的缺失，中国的IP核太少了。EDA公司严重缺失，国内严重依赖具备成熟IP核的⼯艺资源，还不具备COT设计能⼒，带动验证⾏业的蓬勃发展，集成电路产业有可能再发展100年。
半导体存储器的布局虽然意外不断，但总体情况尚可。
顶会受不到重视，影响因⼦相当于材料的特别⽔的⽂章、顶会连索引都索引不到。
模块级与系统级的验证团队有很多的区别。
AI的应⽤场景可以⽤到验证上⾯。机器学习验证⾃动收敛，验证⾃动写测试⽤例。
很多硬件问题在软件上是修复不了的。
中国的IP核太少了。
芯⽚设计的企业：紫光展讯、中兴微电⼦、艾派克、湖南国科微、北⽃星通、深圳国微、盛科⽹络、硅⾕数模、芯原微电⼦。
国内企业验证第⼀梯队：海思、联发科、芯原
starup公司如地平线（CEO余凯）有验证团队，互联⽹的公司也会做芯⽚如阿⾥百度。
9、验证的任务和⽬标
company验证任务可能是模块级(module level)，⼦系统级(subsustem level)，系统级(chip/system level)。
验证的⽬标就是按时保质低耗的完成⽬标硬件的设计验证⼯作。
按时：验证⼯程师⾸先按照预先的进度来考虑验证的节点，明晰进度。⼀个都不能少，没有⼀款芯⽚可以因为其中⼀个模块的延迟⽽有信⼼去流⽚。整个验证团队要平衡好验证效率与项⽬进度的关系。尽可能少地将缺陷暴露在流⽚以后。缺陷到不同阶段造成的损失是指数递增的。只要是⾃动化的，即是有规范的。
低耗：低耗有两⽅⾯，⽤更短的时间、更少的⼈⼒来完成芯⽚的设计任务，这对于芯⽚设计公司⽽⾔，是⼀笔前期看得见的可以预期控制的成本。同时，也有⼀些成本是突发的，其中⼀个就是缺陷你的暴露问题。从下图可以看出暴露在不同研发阶段的缺陷，其造成的额外成本是会影响芯⽚项⽬成败的。⼆次流⽚也是⾮常普遍性的操作。
⼀旦芯⽚在出⽚以后被检测出严重的缺陷，会导致芯⽚的⼆次流⽚，这对于成本控制是⼀种额外的损失，同时也会将时间和⼈⼒资源消耗在本可以避免的⼆次流⽚上⾯。
量化的⽅式来衡量验证的产出进度，⽤来衡量的⼀般是两个标准，⼀个是时间，⼀个是发现缺陷的数量（coverage）。
通过缺陷数量在时间线上的记录，我们可以绘制出缺陷数量的增长曲线，⼀般来讲，缺陷数量的增长曲线书逐渐逼近趋于缓慢的。功能验证需要保证的就是将缺陷的数量的增值（⾄少是致命缺陷数量）保证在硅前阶段，不应该发⽣在硅后测试阶段。针对缺陷的类型，我们⼀般会遵循先易后难的验证⽅saints row
法。
我们给出的激励向量应该也是先易后难，我们发现出的缺陷也应该是先基本后⾼级。
缺陷率的曲线是否在收敛，或者说斜率是否在变⼩，这⼀定程度上可以说明验证状态是否在收敛和趋于完备。
需要注意验证过程中的发现的缺陷种类，应该是从基本的缺陷再到⾼级缺陷，假如到了后期缺陷率尽管在收敛，然⽽却发现了基本的却休闲，那么这时候应该问责芯⽚验证⼯程师，对芯⽚的验证质量打个问号。
10 、验证的周期
⼀个验证团队会基于时间差同时进⾏多个项⽬，多个项⽬之前也存在借鉴、更新的关系，所以验证的环境和复⽤性是在不断提⾼的。
1、根据功能模块详述，创建验证计划。
2、做验证计划回顾，开发验证环境，准备环境完毕后要进⾏初步验证环境的测试⽐对，确保验证环境开发⽆误。
3、调试环境和HDL⽂件，对验证代码进⾏检查（设计代码、验证代码都要检查）。
4、递归测试（回归测试），即将已经存在的测试全部执⾏⼀遍。
5、流⽚前的验证完备性检查，看看回归测试有没有通过，代码覆盖率、功能覆盖率有没有达到指标，回归测试就是将已有的测试全部执⾏⼀遍.
6、漏洞还会出来，为什么之前没有cover到呢？所以要展开逃逸分析（Escape Analysis），吸取教训。
11、功能描述⽂档都包含什么
⼯程描述⽂档是硬件和实际共同的依照，设计⼈员通过⾃⼰的理解来实现RTL⽂件，验证⼈员也会按照⾃⼰的理解来构建测试环境。这样看来是两次理解，确保功能描述⽂件可以被验证和设计⼈员理解⼀致。
验证⼈员⾃⼰设计参考模型(reference model)，通过结果⽐对，来检查出是否有不符合预期的情况。
接⼝信息，如果是标准接⼝，在功能描述中，不需要详尽列出接⼝的时序信息，命令、数据传输情况，⽽值需要给出基本的时钟、复位、接⼝信号名。如果是⾃定义接⼝，由于这种接⼝没有被规范化，那么这个时候功能⽂档中就应该尽可能周全地描述需要给出的信息。
车次英文
时尚的英文单词结构信息，结构信息会讲模块进⼀步细分为各个功能组件，以及包含组件之间的逻辑关系。
交互信息，由于模块稍后会被集成到更⾼⼀级的⼦系统中，所以在功能详述⽂档中，会包含模块之间的交互⽰意图，在必要的情况时，这些交互信号之间也会给出准确的时序信息，确保在集成之后，两个模块之前的交互会按照预期定义的时序发⽣。
功能描述⽂档是硬件设计和功能验证的基础部分，也是共同参考依照的标准。设计⼈员会通过⾃⼰的理解，将其实现成RTL⽂件，⽽验证⼈员也会按照⾃⼰的理解，为设计构建出验证环境。尽管看起来，验证⼈员⼜重复了⼀次功能上的理解，但正也是因为这个部分，⼆次确保了功能描述⽂件可以被设计和验证双⽅理解⼀致。只不过验证的理解是不可综合的。
这样验证⼈员⾃⼰设计的参考模型（reference model）才也会按照功能描述⽂档做出正确的⾏为和数据输出。参考模型对应着硬件设计，会通过结果⽐对，来将车出是否有不符合预期结果的情况。通过这种⽅式，我们可以更好地让功能⽂档变得易读清晰，也降低了设计⼈员误解功能描述⽂档和实现错误硬件的可能。
12、制定验证计划
验证对象是谁？如何去验证它？
