从生成的框架来看，会有一个uvm_component类simple_model_uvm_wrapper生成，这个类继承于simple_model，它的目的是为测试simple_model类，而在其内部定义更多需要的成员。随后会有一个module simple_module_unit_test，它的作用在于例化软件类simple_model_uvm_wrapper、完成SVUnit的测试环境结构，同时由单元测试者自定义一些可以用来测试的用例。从这个自动化生成的框架来看，用户无需再额外考虑如何导入SVUnit包、初始化测试框架、构建基本测试环境，这些可以通过SVUnit的Perl脚本完成，对于verifier他只需要考虑如何针对UUT构建测试环境元素和测试用例。

我们考虑按照上图构建一个测试环境，在simple_model_uvm_wrapper中新引入两个数据缓存，一端用来接收测试环境中的数据，另外一端用来与simple_model的TLM端口连接。因此在simple_model_uvm_wrapper由verifer来实现新添加的FIFO的例化和连接：

在建立了测试环境之后，就可以在simple_model_unit_test中添加具体的测试用例了。

可以看到在`SVUNIT_TEST_BEGIN和`SVUNIT_TEST_END的宏中，可以添加多个测试单元，由`SVTEST和`SVTEST_END来装载每一个单元测试名。而测试的信息报告可以通过`FAILE_UNLESS、`FAIL_IF来实现，这些信息都会在稍后运行时通过SVUnit的测试框架来处理。而在通过指令“runSVUnit -uvm -s <simulator>”来执行单元测试之后，会打印出下面的这些信息：

这些报告信息中，用户需要注意这几个关键词：test、testcase和test suit。在一个测试模板中可以定义多个test，它们在测试中使按照先后顺序执行的，在测试中如果有任意一个测试失败，那么它最终的状态也是失败的，即这个模板对应的testcase的测试状态是失败的。

而为了方便用户管理多个测试模板和其中的test，SVUnit支持通过单次调用runSVUnit来实现按照先后顺序执行多个UUT的testcase。这种将多个testcase整理起来跑测试的方式，称之为test suite。

也许在SVUnit之前，verifier在开发验证环境的同时已经隐约感到应该对一些基本的UVM组件（或者module、interface）进行测试，但这种测试的方法还没有被规范化，也因此无法将这种单元测试的方法在团队内推广开来。而通过SVUnit，这样一个轻量级的应用，它既可以自动化生成测试模板，也可以在稍后的测试管理中方便测试启动、管理和报告。整个单元测试的环节被规范下来之后，使得verifier和designer就有机会在设计环境或者硬件模块的同时，也可以准备单元测试。尽管verifier也许还不适应测试驱动开发（test driven develoment）的方式，但通过SVUnit来增强自己新代码的信心这一点，对verifier还是很有吸引力的。

单元测试的另外一个帮助在于，当你作为一段有悠久历史的老代码的维护者时，测试代码是让你试图保证原有代码结构和功能的大管家。就像一座老房子，代码的注释也许都像家具的使用说明一样过期了，但单元测试的代码还是像一个有问必答的管家帮公司（而不是某一个开发者）来看管着这些代码。无论这间老房子迎来哪一位新的主人，单元测试代码都会给你一一介绍这所房子的结构、哪一处是大门、哪一处年久失修、哪一处有一个坑。

因此SVUnit对于软件世界到验证世界来的新移民，他们会本能的欢迎；对于验证世界的原住民，伴随着他们软件经验的增长，他们也逐渐认识到单元测试的重要性；而对于那些生活在一个“世外桃源”不知魏晋南北朝的硬件设计人员，如何说服他们接受单元测试的理念，恐怕还有很长的一段路要走。

下一节我们将关注如何实现《OVM到UVM的移植》。

谢谢你对路科验证的关注，也欢迎你分享和转发真正的技术价值，你的支持是我们保持前行的动力。