标签：测试环境 ilog 递归 也会 描述 独立 掌握 汽车 交换
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 case)? 验证人员和设计人员都会有对spec理解不到位的情况，会有想不到的corner case，基于随机的验证可能会解决这个问题。
硬件设计是否足够稳定处理一些错误情况 (error response) ？在汽车航天领域，对验证的完备性需求比较大，对错误零容忍，会考虑这样一种设计，如果灾难性影响发生，我们的冗余设计可以显著地对那些出现的错误情况对整个系统的影响降低，也叫做容错设计。
5、 验证语言
验证的简单目标：在一定时间内尽可能多的测试硬件设计，发现设计缺陷并报告出来，同时验证本身也书一项棘手的挑战，这一点可以从语言发展和各种快速发展的EDA工具上得到佐证。
面向对象，方法UVM是基于Systemverilog语言的，动态仿真十年内不会过时。
三家EDA公司都在美国，所以有UVM。欧洲现在也有基于VHDL的UVM，VHDL-based UVM（87和93标准）。欧洲用VHDL的多，用specman多。
VHDL语言（有87和93年标准，还有02，08标准）
Verilog语言（95 01 05年标准）
Systemverilog语言（09 12 17年标准）因为验证总有一些新的需要，所以需要引入新的标准，所以验证的发展是逐渐蓬勃向上的
6、 芯片验证面临的挑战
做SOC的公司在国内是占主流的。伴随着芯片自身的复杂度日渐提高，以及一直存在的项目进度的压力，如何解决验证的完整性和高效性变成一个大家都关注的话题。
验证目前面临的挑战：
1、如何穷尽所有可能的情况给设计产生激励，如何划分出有效的测试空间，以及如何给出随机约束的激励。
2、如何在个中可能的激励的情况下，判断出不符合硬件描述行为的设计并报告出来。
3、硬件类型分类，不同设计的激励类型和结果判断方法。针对不同的类型、不同的复杂度、不同的集成度的设计，会采用不同的验证方法。
4、从验证工具的分类看，两大类，仿真验证、形式验证，从复杂度来讲的话。分为黑盒验证、白盒验证、灰盒验证。
7、验证职业前景
应届生要求：
1、 微电子、计算机、通信工程、自动化、电磁场相关专业
2、 熟悉 VHDL/Verilog、SV等数字芯片及验证语言参与过FPGA设计或验证
3、 具备芯片数字综合（SYN）/时序分析（STA）经验
4、 了解芯片设计基本知识，如代码规范、工作环境和工具、典型电路（异步、状态机、FIFO、时钟复位、memory、缓存管理等）
5、 接触过多种验证工具，了解一种或多种验证方法 (UVM)，并根据项目特点制定不同的验证策略、方案，搭建测试环境，完成验证执行和Debug
6、 理解CPU各个模块的详细功能，熟悉CPU体系架构
7、 搭建测试平台，指定测试计划、开发测试用例
8、 分析设计问题，帮助定位和修复设计问题
9、 分析覆盖率报告，保证CPU核的设计质量
10、熟悉验证方法学，掌握SystemVerilog、Verilog、SVA等语言。
11、系统级或子系统级的功能仿真验证
12、开发脚本以支持验证流程自动化及仿真结果处理自动化、验证流程自动化
13、为验证环境编写功能覆盖及断言语句以增强功能覆盖率
14、能开发基于架构的测试计划
15、可以在C-model， RTL， Emulator，Silicon上运行和调试测试程序并分析和定位功能方面的架构问题（会使用VCS和Questasim）
16、如何从0构建验证环境且量化测试进度，而不是修改测试用例/增加测试用例，而不是维护测试环境
17、会写验证文档
18、会跑回归测试
19、熟悉脚本语言，支持验证流程自动化和仿真结果管理。
验证与设计同样重要，验证的需求量更大，与设计的比例接近2:1，甚至更高。
做验证和做设计的人是分开的，验证的知识迭代更短，三年打八折，做验证要学的比设计的多好多，验证需要不断地学习。
网上有CPU开源验证代码可以练习CPU的验证。
8、业内瓶颈
设计业能力不足，IP核供给不足，重点的IP核来自三大EDA公司，收购小的IP核公司可能都弥补不了产业链的缺失，中国的IP核太少了。
EDA公司严重缺失，国内严重依赖具备成熟IP核的工艺资源，还不具备COT设计能力，带动验证行业的蓬勃发展，集成电路产业有可能再发展100年。
半导体存储器的布局虽然意外不断，但总体情况尚可。
顶会受不到重视，影响因子相当于材料的特别水的文章、顶会连索引都索引不到。
模块级与系统级的验证团队有很多的区别。
AI的应用场景可以用到验证上面。机器学习验证自动收敛，验证自动写测试用例。
很多硬件问题在软件上是修复不了的。
中国的IP核太少了。
芯片设计的企业：紫光展讯、中兴微电子、艾派克、湖南国科微、北斗星通、深圳国微、盛科网络、硅谷数模、芯原微电子。
国内企业验证第一梯队：海思、联发科、芯原
starup公司如地平线（CEO余凯）有验证团队 ，互联网的公司也会做芯片 如阿里 百度。
9、 验证的任务和目标
验证任务可能是模块级(module level)，子系统级(subsustem level)，系统级(chip/system level)。
验证的目标就是按时 保质 低耗的完成目标硬件的设计验证工作。
按时：验证工程师首先按照预先的进度来考虑验证的节点，明晰进度。一个都不能少，没有一款芯片可以因为其中一个模块的延迟而有信心去流片。整个验证团队要平衡好验证效率与项目进度的关系。尽可能少地将缺陷暴露在流片以后。缺陷到不同阶段造成的损失是指数递增的。只要是自动化的，即是有规范的。
低耗：低耗有两方面，用更短的时间、更少的人力来完成芯片的设计任务，这对于芯片设计公司而言，是一笔前期看得见的可以预期控制的成本。同时，也有一些成本是突发的，其中一个就是缺陷你的暴露问题。从下图可以看出暴露在不同研发阶段的缺陷，其造成的额外成本是会影响芯片项目成败的。二次流片也是非常普遍性的操作。
一旦芯片在出片以后被检测出严重的缺陷，会导致芯片的二次流片，这对于成本控制是一种额外的损失，同时也会将时间和人力资源消耗在本可以避免的二次流片上面。
量化的方式来衡量验证的产出进度，用来衡量的一般是两个标准，一个是时间，一个是发现缺陷的数量（coverage）。
通过缺陷数量在时间线上的记录，我们可以绘制出缺陷数量的增长曲线，一般来讲，缺陷数量的增长曲线书逐渐逼近趋于缓慢的。功能验证需要保证的就是将缺陷的数量的增值（至少是致命缺陷数量）保证在硅前阶段，不应该发生在硅后测试阶段。针对缺陷的类型，我们一般会遵循先易后难的验证方法。
我们给出的激励向量应该也是先易后难，我们发现出的缺陷也应该是先基本后高级。
缺陷率的曲线是否在收敛，或者说斜率是否在变小，这一定程度上可以说明验证状态是否在收敛和趋于完备。
需要注意验证过程中的发现的缺陷种类，应该是从基本的缺陷再到高级缺陷，假如到了后期缺陷率尽管在收敛，然而却发现了基本的却休闲，那么这时候应该问责芯片验证工程师，对芯片的验证质量打个问号。
10 、验证的周期
一个验证团队会基于时间差同时进行多个项目，多个项目之前也存在借鉴、更新的关系，所以验证的环境和复用性是在不断提高的。
1、根据功能模块详述，创建验证计划。
2、做验证计划回顾，开发验证环境，准备环境完毕后要进行初步验证环境的测试比对，确保验证环境开发无误。
3、调试环境和HDL文件，对验证代码进行检查（设计代码、验证代码都要检查）。
4、递归测试（回归测试），即将已经存在的测试全部执行一遍。
5、流片前的验证完备性检查，看看回归测试有没有通过，代码覆盖率、功能覆盖率有没有达到指标，回归测试就是将已有的测试全部执行一遍.
6、漏洞还会出来，为什么之前没有cover到呢？所以要展开逃逸分析（Escape Analysis），吸取教训。
11、功能描述文档都包含什么
工程描述文档是硬件和实际共同的依照，设计人员通过自己的理解来实现RTL文件，验证人员也会按照自己的理解来构建测试环境。这样看来是两次理解，确保功能描述文件可以被验证和设计人员理解一致。
验证人员自己设计参考模型(reference model)，通过结果比对，来检查出是否有不符合预期的情况。
接口信息，如果是标准接口，在功能描述中，不需要详尽列出接口的时序信息，命令、数据传输情况，而值需要给出基本的时钟、复位、接口信号名。如果是自定义接口，由于这种接口没有被规范化，那么这个时候功能文档中就应该尽可能周全地描述需要给出的信息。
结构信息，结构信息会讲模块进一步细分为各个功能组件，以及包含组件之间的逻辑关系。
交互信息，由于模块稍后会被集成到更高一级的子系统中，所以在功能详述文档中，会包含模块之间的交互示意图，在必要的情况时，这些交互信号之间也会给出准确的时序信息，确保在集成之后，两个模块之前的交互会按照预期定义的时序发生。
功能描述文档是硬件设计和功能验证的基础部分，也是共同参考依照的标准。设计人员会通过自己的理解，将其实现成RTL文件，而验证人员也会按照自己的理解，为设计构建出验证环境。尽管看起来，验证人员又重复了一次功能上的理解，但正也是因为这个部分，二次确保了功能描述文件可以被设计和验证双方理解一致。只不过验证的理解是不可综合的。
这样验证人员自己设计的参考模型（reference model）才也会按照功能描述文档做出正确的行为和数据输出。参考模型对应着硬件设计，会通过结果比对，来将车出是否有不符合预期结果的情况。通过这种方式，我们可以更好地让功能文档变得易读清晰，也降低了设计人员误解功能描述文档和实现错误硬件的可能。
12、制定验证计划
验证对象是谁？如何去验证它？
验证方法：是采用直接验证（定向验证）、随机约束验证、形式验证还是其他验证方式，主流有六种。
验证工具: 选择需要的验证工具来支持验证方法。
验证完备标准: 量化出一些参数可以衡量验证任务是否完成，代码覆盖率，断言覆盖率，寄存器覆盖率。
验证资源：包括人力、时间、硬件、软件等所有跟项目预算有关的内容，怎么协同分配这些资源。
验证的功能点：需要给出验证的功能点，以及在什么层次去验证它。更具体的包括生成何种激励，检查设计的何种状态和数据输出。
13、开发验证环境
验证环境是验证工程师花费时间较多的部分，验证环境一定要标准化，同一公司内的标准是一定的，否则各个背景的验证工程师会配合不成。现在很多公司不用你会搭建环境，优秀的工程主管已经给你搭建好了，你只需要编写测试用例就即可。
验证人员会从搭建环境开始，实现激励产生器（stimulus generator）、参考模型（reference model）和数据比较器（data comparator）。
验证环境的运行需要软件工具的支持，目前主流的仿真工具均可以对仿真验证提广泛支持。
当然指定验证计划的时候就需要考虑采取何种验证方法，随后才去开发验证环境。不同的验证方法决定不同的验证结构和使用的软件。
伴随着设计缺陷的发现和修正，验证环境也需要保持更新，最终同硬件设计一样趋于稳定，方可进入验证的下一阶段，设计稳定个验证环境才稳定，设计不稳定，验证环境也不可能稳定。
14、环境调制和RTL文件
验证人员在调试方面的时间投入最多，环境的建立在验证早期投入较多，而设计的功能调却是一步一步向前推进的。
环境是否有瑕疵?
测试序列是否合理?
参考模型是否遵循功能详述文档，可能是设计对了，但参考模型错了，有可能是参考模型对了，但设计错了。
硬件设计本身是否存在功能缺陷? 每次改变硬件设计都会改变环境调制。
15、回归测试
回归测试是指在缺陷修复或者添加某项新功能之后，仍然可以通过以前的所有测试用例和可能添加的新的测试用例。这些可能存在的环境变化包括硬件设计自身的改进、缺陷修复、功能添加和验证环境的更新。在每次的回归测试中可能会发现新的缺陷、添加新的测试用例或者更新验证环境。每次回归测试都会帮助完成两个目标：
确保这次的改动没有引入新的缺陷，而且修复了之前的漏洞，或者按照约定目标实现了新的功能。
由于随机验证在每次递交时，某人的随机种子是不同的，这对于重复递交一套回归测试表也是有意义的，伴随着功能覆盖率，可以通过该往复的回归测试和补充的定向测试来逐步提高验证完备性。
16、芯片生产
当经历过回归测试阶段（RTL回归和门级网表回归）之后，这意味着芯片的逻辑部分和物理部分的数据都已经经过各项检查了，在将芯片最后送交给半导体厂商（fabrication facility）之前，项目经理也会同设计经理、验证经理、后端经理一同回顾检查表（check list），确保所有的标准都已经通过，芯片的数据被提交给厂商之后，最终会被制造出来，我们称之为流片。
值得注意的是，此时的功能验证的流程并没有全部走完，而仍然需要提交回归测试，通过不停地保持随机测试的运算量在可能覆盖的新的状态空间上测试是否有可能会发现新的问题。要保证最高优先级的功能先验证完，其他的功能验证仍然一直在跑。
如果是在递交给厂商生产以后发现了新的缺陷，这样的缺陷我们也会同硅后测试发现的缺陷一样对待。通过发现这些缺陷，来考虑是否有软件不就方法，或者提交设计修改意见，甚至进行下一次流片，在下一次流片前准备好设计方案和验证方案，将其计划到下一次验证周期内。
17、硅后测试（Post-Silicon）
在芯片返回之后，系统测试人员会按照系统的集成顺序从底层模块开始测试，在测试之前，我们需要将芯片同测试开发板结合起来，或者将芯片植入到待开发的系统上面。
随后硅前人员（设计人员、验证人员、系统人员）和硅后人员（测试人员）需要保持频繁的沟通。因为一旦测试出了问题，需要第一时间判断测试的方法不恰当（硅前和硅后的测试是不是不一致），还是归属于硬件自身的问题。
之所以要求硅前人员也参与进来，是因为我们不希望硅后测试出现太多问题，尤其是致命缺陷，那么当一个硬件缺陷被发现之后，硅前人员就需要讨论这个缺陷的严重性，从软件层面上讨论可行的补救方法、最后再到硬件层面需不需要修复，如果不修复会影响什么功能，会损失什么功能，这些损失的功能对客户是不是可以勉强接受，比如第一版流片没有也行，第二版要补救回来，最终实在没有避免，需要重复流片。
18、逃逸分析（Escape Analysis）
有一些漏洞实在无避免，系统越大越容易出现这种问题，因为我们底层的verification很难去考虑系统层面场景的问题，我们很难去考虑软件人员如何去开发特定的应用场景，这也就是为什么制作验证计划时候要带上软件人员，当系统越来越大的时候，会发生各个流程的人员不在同一地点办公的情况，各个人员的有效沟通非常重要。
有些时候，我们难以避免个别的验证漏洞一直被忽视，导致它们可以从硅前验证阶段逃走，到了硅后测试才被发现，遇到这种情况，硬件设计人员和验证人员都要和测试人员进行沟通，尝试在硅前的仿真环境中重现遇到的测试失败场景。
这种硅后测试失败要求硅前验证重视重现的难度相比较在交给客户之后遇到的应用失败场景还是容易很多的，因为一旦从硬件级别向上堆叠经过驱动层、固件层再到客户的应用层，我们更难以在硅前验证环境中重现客户应用失败的场景。
在软件调试非常难发现硬件的问题，他自己都不知道是不是硬件出的问题。
当逃逸分析完成之后，这一过程会对下一个芯片周期中，设计人员如何规避设计陷阱、完善设计经验，验证软交换如何完善验证方案、产生尽可能多的有效测试序列都是非常有意义的。在整个芯片过程中国都贯穿着吸取教训四个字，因为要完成芯片从硅前到硅后的过程本身就很漫长（相比软件的迭代开发而言）。那么要积累尽可能多的经验，对于每一位芯片工程师，都一个个在每一个关键节点就养成总结的习惯，并且在下一个阶段有意识地区完善，保持一种不断成长的态度。
【Block-Level Verification】 芯片开发通识_验证目标_ 验证语言_ 验证职业前景 _挑战和瓶颈_验证周期_功能描述文档_验证计划_回归测试_硅后测试_逃逸分析
标签：测试环境 ilog 递归 也会 描述 独立 掌握 汽车 交换
原文地址：https://www.cnblogs.com/karl-marx/p/11162102.html
