背景：目前负责模块的验证工作基本进展完毕，包括所有功能验证、场景覆盖、用例编写调试和仿真、功能覆盖率收集、sva检测时序等，在当前的进度上和开发、验证同时对我的工作进行了评审。

        问题：在评审中间讨论到一个当前tc实现的问题，由于当前模块的input/output信号非常的多，分别有六七十个，对应的控制信号也非常的多，并且每个控制信号都是多态的，这个导致所有的控制信号的组合是非常多的。基于以上在实现用例时，我想到了随机产生输入参数的方式，之后在附加上cov_func检测即可，正常的这套流程是没有问题的。但是，上面的这种方式会存在一个潜在的问题，就是你cov_func的覆盖点是充分的吗？下面举例来说：

        如下图，我当时验证的时候仅仅认为clk1和clk2是独立的，并且对于其clken*、fclken*都是进行了随机，通过在tc中的检测机制，是可以确保G门控的正确性的。并且cov_func中是有clken1、fclken1的交叉覆盖点和clken2、fclken2的交叉覆盖点的，所以可以通过cov_func来确保两者的全部覆盖的，即：00、01、10、11。

        通过上面的描述发现，我一开始就是将clk1、clk2当做独立的个体进行验证，并且我自己认为两者的连线是一定正确的。通过观察可以发现，clk1和clk2都是其中o_clk[*]的输出，这里很容易出现笔误，比如o_clk[2]准备将o_clk[1]复制过去之后，修改中括号中的数字即可，当时当笔误出现时，会导致clk1也连接到了clk2的位置。并且，重要的是我的检测机制是检测不出来的，并且cov_func中也没有两组之间clken*、fclken*的交叉覆盖点（这里的交叉其实是不明智的，因为共有N组，这种交叉应该是N的排列组合，肯定是实现不了的），所以一旦这里出现上述的问题，一定是验证不出来的。该种错误一般通过cov_dut也是验证不出来的。

         综上，对于这种问题的出现，问题的源头是我自己认为clk1、clk2处的连线是正确的；并且在随机场景的用例中cov_func的覆盖点也没有组与组之间的交叉覆盖点。这两点导致了验证的不完整性，一旦dut中出现上述的问题，我现阶段的的验证平台肯定是会将bug遗漏过去的。  

        解决：最终的解决方式是一个方框（图中的门控单元）的验证，并且对每个clken*、fclken*都进行全覆盖，即00、01、10、11。

        反思：最近的工作确实很多，自己也加班加点乐此不疲，但是心理确实还是有一些毛毛躁躁的感觉，并且总觉着自己能把所有的事情做好，经过今天的事情之后，深刻的认识到自己经验不足、知识匮乏的本质，还没有耐心，最重要的的是今天没有对大佬的敬畏之心，其实是自己盲目的骄傲之心而已。真的很惭愧，今天在这里啰嗦这么多，就是为了反思自己。

        不仅是知识方面，自己的心境更应该好好修炼，自己要更加稳重一些、虚心一些，要认真听别人讲完，特别是一些大佬讲的时候，一定要认真的听讲和思考，当大佬讲完，并且自己依旧觉着我目前的做法没有问题，这时候也要说出来，并且耐心的听大佬讲，毕竟是大佬的经验和解释，肯定是在我之上。对于不会或者没有听懂的地方，一定要及时询问、请教和讨论。

        建议：平时尽量多接触、多积累、多主动学习一些验证经验，这样在自己做某一些工作时，才能灵光一现的想到一些很关键的验证点。

        最后：非常感谢Y大佬二十分钟的耐心解释、讨论，在今后的学习、工作和生活中都应该更加的虚心和细心，并且要多多积累验证经验，这样才能让自己的维度更高，看待问题的方式更加全面，思考问题的维度更多更高，解决问题的速度更快。

继续加油！