验证，设计相处的几个原则

1.     重视spec，拒绝口口相传的feature。完善的spec意味着2方面，一是设计把芯片架构和设计细节想清晰了，代码质量自然会高，bug数目自然会少，后期的收敛速度自然会快。二是给验证提供了正确的输入，验证有了完整的spec,才有可能做出完善的vplan和验证环境；如果设计都没想清楚怎么做，写到哪，想到哪，必然存在很多漏洞，后面通过打补丁修复bug，还有可能引入更多的bug, 甚至还存在推倒重来的可能。验证的唯一依据只有spec, 拒绝任何口口相传的feature。验证应该催促设计或者架构，尽快出具完善的design spec 和 feature lis。另外一定要拒绝口口相传的feature, 所有的feature 应该白纸黑字写清楚，防止日后“扯皮”。哈哈，其实不是为了推卸责任，人的记忆是有限的，短短1-2个月可能记得，后面就慢慢忘记了，到后面有没有这个feature 没有人知道了，对于后面的芯片迭代升级或者后期的芯片调试都极为不利。

2.     相互尊重，勇于承担责任。设计和验证是一个相辅相成的工作，设计要实现的功能，验证也需要在参考模型或者其它检查中实现，只不过两者实现的维度和语言不一样而已。设计和验证的思维方式不一样，技能树也有区别，工作无卑劣之分，需要相互尊重。任何一个芯片的bug，都会有“天时地利人和”的条件和各种机缘巧合的故事，切勿出现Bug，相互甩锅。大家应该勇于承担责任，总结出现bug的原因，从设计和验证两者角度去避免这个问题再次发生。

3.     就是论事，对事不对人。设计和验证，有一个共同的目标，那就是按时、保质、保量完成项目目标。简单来说，在既定时间内，保证芯片功能正确无bug，性能符合定义，功耗满足要求，面积符合目标。为了这一目标，验证、设计、后端，DFT，版图都要付出艰辛的努力，任一环节出现纰漏，都可能影响这个目标。整个芯片开发过程其实是个迭代收敛的过程，在这个过程中，各个团队之间经常交流，拉通对齐，不断减少理解偏差，最终收敛。千万不要因为不喜欢某个人，而导致和他的合作打折扣，缺少交流，甚至不交流，要知道这种不负责的行径将给芯片带来极大的风险。要知道，我们的目标是一致的，只有芯片成功了，公司才有钱给大家涨工资，所以大家一定不要把个人喜好恩怨，带到工作中来。

4.     心胸大度，不要拒绝别人的意见。有些人不喜欢别人给他提意见，非常抗拒，认为这种意见小题大做，给他找事，给他增加无谓的工作量。其实这种思维不对，其实项目做好了，别人往往会记住负责这个工作的人，而不会记住当初是谁提的意见。换句话说，别人帮你提意见，一是别人曾经在这个地方出现过问题，是经验的传授，二来提意见这个行为是对你百利而无一害，我们应该学会开放自己的思路，虚心接受别人的意见。不管别人说得对不对，可以脑子里过一遍，想想有没有可能相关的潜在风险。

5.     重视简单或者频繁变动的feature。频繁变更的feature点或者几经转手的代码，设计和验证更要保持200%的警惕。往往这种地方会存在很多漏洞，会有很多理解的偏差，有很多深挖的价值。另外需要重视clk/rst相关的feature。很多验证，只要仿真能跑，就认为这部分没问题。其实真实的芯片，有一套完善的时钟树和复位树，有严格的释放时序关系，clk/rst一旦出现问题，就是一块砖，没有任何价值。

6.     重视讨论。验证尽可能抽时间参与设计，架构相关的讨论。尽早参与设计、架构的讨论，对模块、芯片的熟悉很有好处，对于后期验证架构的制定有至关重要的作用。另外，资深的验证专家，能在架构的定义、具体的设计，提出自己的见解和意见，从而提升芯片的性能。设计也可以参与验证架构（包含激励覆盖率）相关的讨论，提升验证质量和效率。另外，要提高讨论效率，讨论之前准备充足的材料，对于存在疑问或者有风险的点提前记录，及时提出，供大家讨论。