uvm实践 学习第一章

第一章节

1：验证主要保证从特性列表到RTL转变的正确性，包括但不限于以下几点：
·DUT的行为表现是否与特性列表中要求的一致。
·DUT是否实现了所有特性列表中列出的特性。
·DUT对于异常状况的反应是否与特性列表和设计规格说明书中的一致， 如中断是否置起。
·DUT是否足够稳健， 能够从异常状态中恢复到正常的工作模式。

2；Verilog在验证方面最大的问题是功能模块化、随机化验证上的不足，这导致更多的是直接测试用例（即direct test case，激励是固定的，其行为也是固定的） ，而不是随机的测试用例（即random test case，激励在一定范围内是随机的，可以在几种行为间选择一种），笔者亲身经历过一个使用Verilog编写的设计，包含有6000多个测试用例。假如使用SystemVerilog，这个数字至少可以除以10。

3；SystemC 算法需求非常复杂的，如图形图像处理等。那些对算法要求非常高的设计在使用Verilog编写代码之前，会使用C或者C++建立一个算法模型，即参考模型（reference model） ，在验证时需要把此参考模型的输出与DUT的输出相比，因此需要在设计中把基于C++/C的模型集成到验证平台中，   用户需要自己管理内存，指针会把所有人搞得头大，内存泄露是所有C++用户的噩梦。除了内存泄露的问题外，SystemC在构建异常的测试用例时显得力不从心。

4；SystemVerilog 它具有所有面向对象语言的特性：封装、继承和多态，同时还为验证提供了一些独有的特性，如约束（constraint） 、功能覆盖率（functional coverage），它提供了DPI接口，可以把C/C++的函数导入SystemVerilog代码中，SystemVerilog语言本身提供内存管理机制，它还支持系统函数$system，可以直接调用外部的可执行程序，就像在Linux的shell下直接调用一样。用户可以把使用C++写成的参考模型编译成可执行文件，使用$system函数调用。

5：方法学；

1）验证平台中都有哪些基本的组件， 每个组件的行为有哪些？
2）验证平台中各个组件之间是如何通信的？
3）验证中要组建很多测试用例， 这些测试用例如何建立、 组织的？
4）在建立测试用例的过程中， 哪些组件是变的， 哪些组件是不变的？

5）验证平台中数据流与控制流如何分离？
6）验证平台中的寄存器方案如何解决？

7）验证平台如何保证是可重用的？

方法学又不仅仅是一个库，库只是方法学的具体实现，如同上面的那些问题，如果能够把它们都完整地规划清楚，那么这就是属于读者自己的验证方法学；如果把思考结果用代码实现，那就是一个包含了验证方法学的库

7；如何用UVM搭建验证平台：包括如何使用sequence机制、 factory机制、 callback机制、 寄存器模型（register model） 等。

如何编写代码才能保证可重用性：如何保证自己在这个项目写的代码在下一个项目中依然可以使用， 如何保证自己写出来的东西别人能够重用， 如何保证子系统级的代
码在系统级别依然可以使用； 对于同一公司来说， 如何保证下一代的产品在验证过程中能最大程度使用前一代产品的代码