在第一次写vPlan的时候，对于其中的Verification requirements (Features to be tested)这一章怎么写，脑子里没有一个清晰的概念，只是朦胧地认为“这一章列出了所需要验证的功能，应该把DUT的所有功能都写出来”。于是就写出了形如“DUT读存储器、DUT写存储器、DUT被FW配置、DUT解码、FW读取DUT的结果”（v1）之类的所谓功能（这里只是举例子，写得不完整也不精确），就好像告诉自己“以后在验证的时候，要验证这些功能都正常；在写bench的时候，通过参考所列的功能我就能得到bench编写的灵感”。但是仔细想一想，我发现我所列的上述功能简直是太不具体了，几乎起不到什么指导作用。

我下一个想法就是“把功能写清楚，使之能够更好地指导仿真”。于是我开始思考DUT(Rx)、FW、Tx_model在真实场景下的整个工作流程，我想到“如果我把系统运行时的行为描述得很具体，同时具体地标出涉及到的寄存器、信号线的名字，那么我就可以知道如何编写bench以重现真实环境下的DUT及其周围环境的运行情况了”。在此基础上我又加入了一些必不可少的东西，比如每次发送给Tx的数据应该是随机的，并且这个激励的每一种情况都应该被尝试一遍。于是我v2：“发给Tx_Model的13bit信号的每种情况都应该被遍历到、FW通过写寄存器A初始化DUT、FW通过寄存器B开启DUT工作、DUT读存储器、DUT写存储器、DUT发出完成信号irq、FW读取DUT运算结果、FW根据本次结果决定下一次对DUT的配置、等”（v2）。比之前的v1版本的要详细得多，并且所描述的功能都是按照实际运行的时间顺序来整理的。此时非常困扰我的是：若想让仿真环境运行的和真实情况中的一样，即模仿真实DUT和周围环境的工作过程是难以利用bench实现的。因为系统的工作流程依靠一些DUT外部的逻辑设计，比如FW中的功能，甚至是更抽象的层面上的SW的功能所决定的。想要完全真实的模仿这些东西是不可能的或者说根本就不是DVer的工作（相关的内容我在《请专注于DUT的功能》中有描述）。在这个练习案例中，我根本没必要想得那么复杂，没必要把DUT外部提供的功能全都放到仿真环境中去。我在进一步修改vPlan时，着重区分哪些是DUT真正的功能，即真正应该被验证的东西。而且，在Verification requirements这部分，我更应该关注要验证什么，而不是怎么验证，所以按照时间顺序来写Verification requirements可能本来就是错误或者不必要的。

DUT的功能其实很简单：在某种寄存器配置状态下，读取某一段待译码的数据，DUT经过运算后返回一个结果和其它功能信号。至于v2中提到的“FW读取DUT的结果、FW根据DUT结果决定下一次配置”等，都不能算作是DUT本身的功能，是不需要验证的。至于DUT读写存储器这一功能，是一个非常常见的功能，在design spec中并没有强调读写过程有什么特殊性或者值得特别关注的地方，所以可以不写在vPlan里面。 这样看来似乎vPlan中的Verification requirements这一章没什么功能好写的了，但是，这一章在列出“Features to be tested”的同时还要定义“Verification Scope”，也就是对feature的特性作进一步的描述（约束）。所以在v3中我写道：“输入待解码数据的可能范围、输入UEID码的可能范围、DUT寄存器的可能配置方案、配置方案存在的约束关系、DUT解码的最长时间、等”（v3）。这样似乎更符合“Verification requirements”的称呼。