验证广义方法学的探讨

zhhzfang

个人认为 做芯片EDA验证的核心任务，就是在网表冻结前完成 完备性验证。既有时间要求，又有质量要求。要做好还是比较难的。本帖中的验证特指芯片EDA验证，欢迎大家发言，但建议不要用一些书上理论在这个帖子里咬文嚼字，来判断是非，避免浪费大家口水。
目前一般芯片验证流程大致分三个阶段：
    【验证规划阶段】包括 验证方案、验证特性划分、测试点规划、随机规划、验证用例制定。这个它关乎验证的完备性。
    【验证开发阶段】包括 环境搭建、参考模型编写、随机代码编写，定向用例编写，自动化脚本编写
    【验证实施阶段】包括 用例调试，波形确认，回归，覆盖率确认和补充，自检等等。
     花时间最多的是【验证实施阶段】，对完备性影响最大的是【验证规划阶段】。 但初入验证的人，最愿意化花时间的是第二阶段，目前所谓的UVM方法学，也是解决初学者在第二阶段遇到的问题。这样看，UVM方法学只是验证的狭义方法学，我们姑且称之为【验证开发方法学】
     根据楼主不自量力的多年实践，在第一阶段，我们参考软件设计方法，引入了 验证设计流程，即对应【验证规划方法学】，目的是提供一套可操作的方法和工具，使验证人员能够按步骤地完成验证完备性规划，顺带 实现验证代码自动生成。
     在第二阶段，我们参考大型软件的敏捷开发和持续集成理论，引入了 芯片持续集成体系，即对应【验证实施方法学】，当然这个芯片持续集成，还囊括设计的语法检查，代码管理，综合，FPAG布线，后端的formal等流程。只不过验证活动 站在核心位置。
     因此，我认为 【验证规划方法学】+【验证开发方法学】+【验证实施方法学】的合集才能 称为 验证广义方法学。
     UVM等开发方法学大家很熟悉，我们不讨论，后续在帖子里 与大家一起分享讨论LZ这边实践过的 验证第一阶段和第三阶段的体系化方法。

zhhzfang

回复 3# kuolifeng
这方面的书籍和工具的确很少，大家现在 基本都是采用 自然语言 作为描述工具。要想做好很难把握。

zhhzfang

回复 5# jimbo1006
你讲得很好啊，提供了一个思路！ 最近为招聘指标的事情发愁，在忙找简历。后面我肯定会补全的。

zhhzfang

UVM的出现的确改善了验证的效率、降低入门者门槛，对验证行业是有非常大的贡献的。还带来了楼上几位都讲到了UVM的好处和优势。在UVM和VMM出现之前，很多公司包括sony和海思都在验证开发环节拥有自己的 与此类似方法和流程。这些都是大同小异。其核心还是把面向对象设计思想应用到环境和用例的分层和开发，再封装一些运行流程、接口以及基本库。如果让软件工程师来做验证，肯定也会这么去提炼和抽象。把UVM当成一本经典是必要的，学好，用好,理解好，好处很多，尤其是刚入验证的同学。
    UVM的很多概念就是为了验证环境和用例的实现而提出的，在这里不讨论把它应用到规划阶段的问题，对此有信心的同学可以去实践，并与大家分享下。目前在验证规划阶段，业界各个公司的采用方法、流程、概念定义都不一样。八仙过海，各显神通。楼主要说的验证设计，也只是验证规划阶段采用的众多过海方法的一种。只不过它有普适性和可操作性，我就把纳入规划方法学的范畴。它目前只是楼主的规划方法学，不是业界的和你们的。仅供参考。

    一直以来，验证方案和验证分解(包括验证特性提取，验证用例制定、测试点提取等等)都是采用自然语言来描述的，映射到实际的环境代码基本也是靠人工完成的；这样就导致规划的完不完备，环境写的对不对得不到理论上的保障；另外，对于复杂的验证，针对业务的提取和抽象非常重要，它会封装复杂度，提高场景的规划清晰性和便利性，这种抽象一般是在验证方案里采用图表或自然语言去描述。这种业务抽象也基本无章可循。引入验证设计概念，就是要解决上述问题：即实现验证完备性规划的规范化、形式化。并自动化衔接到验证开发。
    根据软件的设计方法，我们若要模拟一个系统，第一步是找出所有名词，提取出概念和集合，分析概念上的层次关系，即提取类和派生关系；第二步提取概念之间的包含关系，即对象与对象之间例化关系；第三部为每个概念细分出特征和属性。形成类内部的成员变量。前三步基本都是对系统中涉及的所有名词的整合。第四步是整合这些名词的加工动作和接口动作，即动词或过程的提取，形成函数或通用方法类。
    按软件的思路，建模一个系统，名词的提炼是关键。而我们过去的套路上，提取出来的验证特性和测试点，大部分就是对rtl代码的处理过程的分类描述，再加一些验证关心的场景。有些团队把名词提取成测试点，实现了形式化描述，自动生成随机参数。但我们需要更进一步：
    1.我们把一个模块的验证过程和业务运行过程合一当成一个独立系统。进行运行过程分解，分条列出，描述业务的运行过程，也描述验证过程、随机过程，用例场景，对比过程等，使用自然语言。形成《系统过程分解》，该步骤作为熟悉业务和思考的辅助手段，以及《验证设计》的验收参照。
    2.采用软件的设计方法，对该系统进行建模，提取各个类，每一个类对应Excel的一个标签页
    3.提取各个类之间包含关系，在Excel各标签页里，填写对象例化
    4.提取每个类的属性和特性，包括验证相关控制的参数，作为普通成员。填写在Excel中
    5.输出形成《验证设计》Excel。
    6.召开串讲会议，对照《系统过程分解》的每一条过程，将《验证设计》里的模块配合串起来，手动画图方式，调整划分，反复迭代直到合理为止。
    7.在《验证设计》里添加各变量及其之间的随机约束
    8.在《验证设计》里新建标签页，规划定向随机场景
    9.随机约束和定向规划检视，评估各种场景概率
    至此设计环节的事情已经完成，使用形式化语言完成业务验证的建模。可《验证设计》输入给脚本，自动生成参数基类代码，随机代码、用例文本格式化输入输出代码、用例代码、参考模型基类。并以此为基础进入 验证开发阶段。至此系统所有变量的建模已定，TB和RM的结构基本被框定。

    这里涉及很多技术问题，比如公共参数共享，二次开发，Excel填写格式等等，不细讲了。