验证广义方法学的探讨
目前一般芯片验证流程大致分三个阶段：
【验证规划阶段】包括 验证方案、验证特性划分、测试点规划、随机规划、验证用例制定。这个它关乎验证的完备性。
【验证开发阶段】包括 环境搭建、参考模型编写、随机代码编写，定向用例编写，自动化脚本编写
【验证实施阶段】包括 用例调试，波形确认，回归，覆盖率确认和补充，自检等等。
花时间最多的是【验证实施阶段】，对完备性影响最大的是【验证规划阶段】。 但初入验证的人，最愿意化花时间的是第二阶段，目前所谓的UVM方法学，也是解决初学者在第二阶段遇到的问题。这样看，UVM方法学只是验证的狭义方法学，我们姑且称之为【验证开发方法学】
根据小编不自量力的多年实践，在第一阶段，我们参考软件设计方法，引入了 验证设计流程，即对应【验证规划方法学】，目的是提供一套可操作的方法和工具，使验证人员能够按步骤地完成验证完备性规划，顺带 实现验证代码自动生成。
在第二阶段，我们参考大型软件的敏捷开发和持续集成理论，引入了 芯片持续集成体系，即对应【验证实施方法学】，当然这个芯片持续集成，还囊括设计的语法检查，代码管理，综合，FPAG布线，后端的formal等流程。只不过验证活动 站在核心位置。
因此，我认为 【验证规划方法学】+【验证开发方法学】+【验证实施方法学】的合集才能 称为 验证广义方法学。
UVM等开发方法学大家很熟悉，我们不讨论，后续在帖子里 与大家一起分享讨论LZ这边实践过的 验证第一阶段和第三阶段的体系化方法。
谢谢小编分享，期待下文。
有關[验证规划阶段]實作方面的資料非常少, 有這方面的書嗎? 期待小编的下文
这方面的书籍和工具的确很少，大家现在 基本都是采用 自然语言 作为描述工具。要想做好很难把握。
说说我的野路子的想法，好让小编开口，讲起来也更有优越感：
验证方案：随机策略，UVM。人力资源分配之类不是我们这个级别要考虑的。
验证特性划分：spec上一般都有特性的总结，这里再划分一次是为了归纳出可以一起验的特性或是将一些大的特性分成几个小的去验吗?我现在接触的模块特性都不是很多，我的做法是每个都去确认验证，宁可重复也不错过。这个和UVM的case划分对应。
测试点规划：感觉和特性划分重复了啊。还是说测试点是指check的时候需要观察的对象，比如一个和寄存器的值有关的信号，测试点就是这个寄存器的值；再比如一个单比特周期波形的测试点就是这个波形的值（0或者1）与这个值维持了多久（low_time, high_time）。这个和UVM的transaction,scoreborad,monitor和打印信息有关。
随机规划：1. 单配置以及配置中个寄存器值的随机：0的附近，全1的附近，中间的一定范围内的值。按特性设计对应权重比。2. 各配置间互相切换的随机 3. 按需求加入一些特殊情况随机，例如突然关掉模块信号再打开，总线冲突等情况。这些和UVM中的sequence, virtual sequence对应。
验证用例制定：写一个验证用例作为例子?
总结：UVM真心很赞很强大，不能简单的说成你所谓的《验证开发方法学》，更不该只把它划在第二阶段。你所谓的验证广义方法学，只不过是UVM衍生出的一个分支而已。
你讲得很好啊，提供了一个思路！ 最近为招聘指标的事情发愁，在忙找简历。后面我肯定会补全的。
说说个人鄙陋的见解。
uvm是一个方法学，可以根据该方法学开发出不同的体系架构，可以覆盖到前两个阶段，甚至第三阶段的部分。方法学的特点是特别宽泛，比如测试点的规划，seq的分层可以解决大部分的问题，在前期我们就可以使用方法学进行任务的分解。
uvm强不强大看怎么看，如果看成一种抛砖引玉的思想，那么他给我们看到的是不一样的空间，巨人的肩膀上总比巨人高么。如果当成一个架构，那么他的局限就挺大的。
UVM的出现的确改善了验证的效率、降低入门者门槛，对验证行业是有非常大的贡献的。还带来了楼上几位都讲到了UVM的好处和优势。在UVM和VMM出现之前，很多公司包括sony和海思都在验证开发环节拥有自己的 与此类似方法和流程。这些都是大同小异。其核心还是把面向对象设计思想应用到环境和用例的分层和开发，再封装一些运行流程、接口以及基本库。如果让软件工程师来做验证，肯定也会这么去提炼和抽象。把UVM当成一本经典是必要的，学好，用好,理解好，好处很多，尤其是刚入验证的同学。
UVM的很多概念就是为了验证环境和用例的实现而提出的，在这里不讨论把它应用到规划阶段的问题，对此有信心的同学可以去实践，并与大家分享下。目前在验证规划阶段，业界各个公司的采用方法、流程、概念定义都不一样。八仙过海，各显神通。小编要说的验证设计，也只是验证规划阶段采用的众多过海方法的一种。只不过它有普适性和可操作性，我就把纳入规划方法学的范畴。它目前只是小编的规划方法学，不是业界的和你们的。仅供参考。
一直以来，验证方案和验证分解(包括验证特性提取，验证用例制定、测试点提取等等)都是采用自然语言来描述的，映射到实际的环境代码基本也是靠人工完成的；这样就导致规划的完不完备，环境写的对不对得不到理论上的保障；另外，对于复杂的验证，针对业务的提取和抽象非常重要，它会封装复杂度，提高场景的规划清晰性和便利性，这种抽象一般是在验证方案里采用图表或自然语言去描述。这种业务抽象也基本无章可循。引入验证设计概念，就是要解决上述问题：即实现验证完备性规划的规范化、形式化。并自动化衔接到验证开发。
根据软件的设计方法，我们若要模拟一个系统，第一步是找出所有名词，提取出概念和集合，分析概念上的层次关系，即提取类和派生关系；第二步提取概念之间的包含关系，即对象与对象之间例化关系；第三部为每个概念细分出特征和属性。形成类内部的成员变量。前三步基本都是对系统中涉及的所有名词的整合。第四步是整合这些名词的加工动作和接口动作，即动词或过程的提取，形成函数或通用方法类。
按软件的思路，建模一个系统，名词的提炼是关键。而我们过去的套路上，提取出来的验证特性和测试点，大部分就是对rtl代码的处理过程的分类描述，再加一些验证关心的场景。有些团队把名词提取成测试点，实现了形式化描述，自动生成随机参数。但我们需要更进一步：
1.我们把一个模块的验证过程和业务运行过程合一当成一个独立系统。进行运行过程分解，分条列出，描述业务的运行过程，也描述验证过程、随机过程，用例场景，对比过程等，使用自然语言。形成《系统过程分解》，该步骤作为熟悉业务和思考的辅助手段，以及《验证设计》的验收参照。
2.采用软件的设计方法，对该系统进行建模，提取各个类，每一个类对应Excel的一个标签页
3.提取各个类之间包含关系，在Excel各标签页里，填写对象例化
4.提取每个类的属性和特性，包括验证相关控制的参数，作为普通成员。填写在Excel中
5.输出形成《验证设计》Excel。
6.召开串讲会议，对照《系统过程分解》的每一条过程，将《验证设计》里的模块配合串起来，手动画图方式，调整划分，反复迭代直到合理为止。
7.在《验证设计》里添加各变量及其之间的随机约束
8.在《验证设计》里新建标签页，规划定向随机场景
9.随机约束和定向规划检视，评估各种场景概率
至此设计环节的事情已经完成，使用形式化语言完成业务验证的建模。可《验证设计》输入给脚本，自动生成参数基类代码，随机代码、用例文本格式化输入输出代码、用例代码、参考模型基类。并以此为基础进入 验证开发阶段。至此系统所有变量的建模已定，TB和RM的结构基本被框定。
这里涉及很多技术问题，比如公共参数共享，二次开发，Excel填写格式等等，不细讲了。
学习一下
感谢小编分享这么珍贵的经验，先mark一下，有空向小编请教