零零碎碎笔记

1.阅读功能文档，提取验证所需要的的信息，如设计接口、寄存器、配置流程等。

2.撰写验证计划划分测试点：使用何种语言或验证方法学搭建验证环境；使用哪些EDA工具、验证技术以及对设计进行仿真验证；将采用什么样的寄存器配置方式或激励进行测试；功能覆盖组的定义和覆盖率收集的方式，功能覆盖率确保需要验证的设计功能有没有疏漏，而代码覆盖率可以发现设计内部的逻辑错误导致的无法执行的语句和冗余的代码；验证环境的结构图；验证环境中将会使用到哪些VIP；参考模型如何准备；

3.搭建验证环境，冒烟测试。4.根据测试点编写seq及case，收集分析覆盖率....

前端：

spec（确定项目需求）
system model（使用C/C++以及matlab等高级语言设置模型）
RTL coding
形式验证/功能验证
后端：

逻辑综合（部分公司仍认为是前端，使用DC综合）
DFT （design for test）（部分公司仍认为是前端）
Auto P&R(自动布局布线,使用ICC(IC compile））
sign off（使用PT)

断言可以放在过程块(procedural block)、模块(module)、接口(interface)和程序(program)中

wire表示导线结构，reg表示存储结构。
wire使用assign赋值，reg赋值定义在always、initial、task或function代码块中。
wire赋值综合成组合逻辑，reg可能综合成时序逻辑，也可能综合成组合逻辑。
logic是reg类型的改进，它既可被过程赋值也能被连续赋值，编译器可自动推断logic是reg还是wire。

唯一的限制是logic只允许一个输入，不能被多重驱动，所以inout类型端口不能定义为logic。不过这个限制也带来了一个好处，由于大部分电路结构本就是单驱动，如果误接了多个驱动，使用logic在编译时会报错，帮助发现bug。所以单驱动时用logic，多驱动时用wire。

 UVM测试平台基本是由object和 component组成的，其中 component搭建了TB的一个树形结构，其基本包含了driver、monitor、sequencer、agent、scoreboard、model、env、test、top;然后object一般包含sequence_item、config和一些其他需要的类。各个组件相互独立，又通过TLM事务级传输进行通信，除此之外，DUT 与driver和 monitor 又通过interface进行连接，实现驱动和采集，最后在top层进行例化调用test进行测试。

UVM中通过objection机制来控制验证平台的关闭，需要在drop_objection之前先raise_objection。验证在进入到某一phase时，UVM会收集此phase提出的所有objection，并且实时监测所有objection是否已经被撤销了,当发现所有都已经撤销后，那么就会关闭此phase，开始进入下一个phase。当所有的phase都执行完毕后，就会调用$finish来将整个验证平台关掉。如果UVM发现此phase没有提起任何objection，那么将会直接跳转到 下一个phase中。

UVM的设计哲学就是全部由sequence来控制激励生成，因此一般情况下只在sequence中控制objection。另外还需注意的是，raise_objection语句必须在main_phase中第一个消耗仿真时间的语句之前。

Config_db 的参数主要由四个参数组成，如下所示，第一个参数为父的根parent，第二个参数为接下来的路径，对应的组件，第三个是传递时的名字（必须保持一致)，第四个是变量名。
uvm_config_db #(virtual interface) :: set(uvm_root:.get(),“uvm_test_top.c1”,'vif",vif);
uvm_config_db #(virtual interface) :: get(this,"”,“vif”,vif);

Q63. UVM中各个component之间是如何组织运行的，串行还是并行，通过什么机制进行调度的？
      Component 之间通过在new函数创建时指定parent参数指定子关系，通过这种方法来将TB形成一个树形结构。
UVM中运行是通过Phase机制将各组件进行同步，进行层次化仿真的。从组件来看各个组件并行运行，从phase上看是串行运行，有层次化的。Phase机制的9个phase是串行运行的，不同组件中的同一个phase都运行完毕后才能进入下一个phase运行，同一个phase在不同组件中的运行也是由一定顺序的,build 和 final是自顶向下。

Q65. 你所搭建的验证平台为什么要用RAL（寄存器）
       首先，我们要了解寄存器对于设计的重要性，其是模块间交互的窗口，我们可以通过读寄存器值去观察模块的运行状态,通过写寄存器去控制模块的配置和功能改变。由于前面寄存器的重要性，我们必须先保证我们寄存器的读写正确，
     我们采用RAL寄存器模型去测试验证寄存器，寄存器模型独立于TB之外，我们可以搭建一个测试寄存器的agent，去通过前门或者后门访问去控制DUT的寄存器,使得 DUT按照我们的要求去运行。
      除此之外，UVM中内建了很多RAL的sequence，用于帮助我们去检测寄存器，除此之外，还有一些其他的类和变量去帮助我们搭建，以提高RAL的可重用性和便捷性还有更全的覆盖率。

Q66. 前门访问和后门访问的区别
前门访问，顾名思义指的是在寄存器模型上做的读写操作，最终会通过总线UVC来实现总线上的物理时序访问，因此是真实的物理操作。
后门访问，指的是利用UVM DPI (uvm_hdl_read()、uvm_hdl_deposit()),将寄存器的操作直接作用到DUT内的寄存器变量，而不通过物理总线访问。
前门访问在使用时需要将path设置为UVM_FRONTDOOR
在进行后门访问时，用户首先需要确保寄存器模型在建立时，是否将各个寄存器映射到了DUT一侧的HDL路径：使用add_hdl_path

uvm_reg_map::set_auto predict()

 显式预测
更为可靠的一种方式是在物理总线上通过监视器来捕捉总线事务，并将捕捉到的事务传递给外部例化的predictor，该predictor由UVM参数化类uvm_reg_predictor例化并集成在顶层环境中。
在集成的过程中需要将adapter与map的句柄也一并传递给predictor,同时将monitor采集的事务通过analysis port接入到predictor一侧。

79.你在进行验证的过程中，碰到过什么难点，重点是什么呢?
刚开始的难点还是TB的搭建，想要搭建出一个可重用性很高的TB，配置灵活的TB还是有一定困难，对于哪些参数应该放在配置类，哪些参数应该放在事务类的抉择，哪些单独配置。
除此之外，还有就是时序的理解，这对于driver和monitor还有sequence和 assertion的编写至关重要，只有正确理解时序才能编写出正确的TB。
最后就是实现覆盖率的尽可能高，这也是比较困难的，刚开始的case好写，也比较快就可以达到较高的覆盖率，但是那些边边角角的case需要自己去琢磨，去分析还需要写什么case。这些难点就是重点，还要能够自动化监测判断是否正确。

以下是对功能验证过程中发现的BUG尝试性地进行一些分类：

1、RTL/逻辑bugs 与 DV bugs ：bugs 既可以存在于RTL中也可以存在于DV（验证代码）中。 在验证的早期阶段，DV 代码相比RTL代码更容易存在bugs 。随机验证环境的稳定并生成良好的激励，将发现更多的 RTL bugs 。

2、简单的bugs ：简单的bugs 可能是代码中粗心的拼写错误或导致基本功能问题的简单逻辑错误。这些bugs 一般在验证的初始阶段就可以发现。

3、边界场景bugs ：边界场景bugs是当设计（或测试平台）中的各种逻辑同时发生或者以某种时序关系活动导致的bugs。 这些bugs是整个验证过程中最具价值的成果。很多时候，只有进行高质量的测试计划、测试点分解，代码审查、质量活动才能有这些重要的发现。

4、挂起、死锁、活锁bugs ：这些bugs 就是前文提到的灾难性的bugs 。 验证工程师需要彻底地了解微架构，并与设计架构师共同进行头脑风暴，确定要测试的所有潜在场景，以避免这些情况。

5、性能bugs ：这些问题可能不会导致功能问题，但可能会导致设计无法满足某些性能目标。例如更长的延迟、流水线气泡、不必要的replay逻辑等。
通过工厂进行覆盖有什么要求？
无论是重载的类（parrot）还是被重载的类（bird），都要在定义时注册到factory机制中。
被重载的类（bird）在实例化时，要使用factory机制式的实例化方式，而不能使用传统的new方式。
最重要的是，重载的类（parrot）要与被重载的类（bird）有派生关系。重载的类必须派生自被重载的类，被重载的类必须是重载类的父类。

driver给 DUT 发送激励，montior监测 DUT 输出的数据，参考模型（ reference model ）能实现与 DUT相同的功能，scoreboard把 monitor接受到的数据和 reference model的输出数据进行比对，如果比对成功就表示 DUT 能完成设计的功能，