思想误区解答：请专注于DUT的功能（全部为菜鸟个人总结不保证正确）

feature listing中的误区，关于FW model的思索:

我们的验证对象是DUT的功能，而现实中的FW只是使用了DUT的功能中在某一情形（真实应用场景）下的部分。如果我把FW model编写得十分真实（先不管有没有可能达到），我不但要在FW coding上花费大量时间，而整个bench却只能验证DUT的一部分功能（被FW限定了）。当我的验证目标是一个不是很大的工程，把FW编写得太过于细致和真实是得不偿失的，不如将DUT的全部feature scope都验到，这样bench（FW in this case)的编写要简单得多；反之，当我们的验证对象是一个很大很大的工程的话，如果不对FW加以限制（使之更靠近真实情况），我们对紧要部分（真正关心的情况、现实中使用的情况）的验证就会显得没有效率，而要cover到整个feature scope则非常耗时。

应该记住，我们验证的目的是并且仅仅是检测DUT的功能，应该更多关注DUT本身，而不是搭建一个和现实应用一模一样的仿真环境。

不要过多地纠结于仿真环境运行的过程是否满足现实中的规则，否则很可能掉入无限完善仿真环境的泥潭。举个例子，我们要验证一辆汽车的功能：加速、减速、转弯。我们只需要给它指令在空地上跑一跑，看一下它的反映和我们的标准车辆（ref model）的反应是不是一致的，我们大没有必要为之编写一套公共交通准则和城市交通系统。

上面说到简化FW的编写。这里我分析得更具体一些。真实的FW往往有很多的内部规则、逻辑、协议等等，而且FW之上一般还有SW层面的东西，所以DVer想在仿真环境中搭建一个真实的FW是几乎不可能的，一定会做一些缩减。比如真实的FW需要遵守这样的规则：在侦测到DUT输出1之后会发出0，侦测到DUT输出0之后会发出1。那么在搭建bench中的FW model时，DVer一定要遵守这个规则吗？我认为没必要，我们把FW的输出做成random就行了。这样在仿真时，FW的回应有时候是满足规则的，有时则是违反规则的，可是即便违反规则又怎么样呢？我们只需要比较DUT和reference model的反应就行了，不管FW的动作是否违反规则，只要DUT的反应和ref model的反应一致，我们就认为DUT是好的。那么有人可能要问，有些时候DUT的功能需要和FW进行连续几个来回的互动才能实现，如果FW根本就是在乱（随机）回应，又如何验证到DUT的这些功能呢？我的答案：应为FW是随机反应的嘛，所以只要测试的次数够多，总会蒙到（命中）你所需要的那个组合的。我们要做的只是在定义coverage的时候，把这种组合的情况写进去，并在仿真时采样有关的变量，时刻关注是否打到了我们所需要验证的那些组合（顺序发生的 or 并行发生的），我相信任何组合早晚都会被random到，早晚我们会cover到100%的function coverage。

那么问题来了：如何让coverage捕捉到时间上顺序出现的组合呢？这是个问题，留作下次解答。Assertion coverage?