RTL bug很大一部分原因是设计没有理解和预见到芯片的需求和使用场景，以及验证没有测试到相应的状态空间。
bug是不可避免的，需要设计和验证一起尽可能地把bug排除在芯片开发周期之外。
其中涉及到bug的预防和bug的检测。本文主要讨论芯片的bug预防。
bug预防
bug预防技术一般是从设计角度来说的，包括设计规范，代码 review，lint检查，单元测试。所有的这些bug预防技术都有些根本的问题或者需要注意的地方：
问题1:“设计一般是同一个模块的糟糕验证
让设计寻找自己代码中的bug，这种方法的有效性很值得怀疑。因为设计是从功能实现的角度出发，所以他们必然会有盲点。这就是为什么绝大多数公司都会聘用不同的人来验证电路，其实就是要求验证人员从不同于设计的视角来验证芯片，这样的验证过程不会带有开发人员的固有成见。而且验证人员拥有的那种“如何才能攻破这个功能”的态度和设计那种“如何才能实现这个功能”的态度是相辅相成、缺一不可的。
这不是说设计自身不需要做任何验证。一个简单的验证也是一个设计人员的任务。即使这样，我们还需要第二双眼睛来检查一些corner case。
问题 2:“处于静止状态的芯片”
类似代码lint的技术不要求实际运行芯片，也就是说它们分析的是处于静止状态的芯片。如果芯片不在真实运行环境中运行起来，很多bug不会被触发，这些bug仍然隐藏得很深。
问题3:“缺乏数据”
芯片需要接收输入，才能覆盖芯片中的各个代码路径（状态空间）。具体执行的是哪些代码路径由芯片输入、当前芯片的内部状态共同决定的。
往往会出现这样的情况：芯片运行一段时间后，当数据量积累到一定程度，芯片出现故障了。这是因为设计时的验证一般要求在短时间内必须完成，所以设计自己做的验证往往不能覆盖这样的情况。
未来也许会出现一些工具或技术,设计凭借它们可以写出无bug的代码。当然这里说的更多是狭义上的bug，例如，使用lint工具检查latch、cdc问题，很大程度上消除这方面的芯片bug。
如果高效地利用这些工具，芯片验证所需要的工作量就会相应减少很多。目前，我们仍然需要在验证中使用不同于设计视角的“第二双眼睛”，在仿真环境中运行芯片以及使用大量接近真实数据的验证输入数据。
谁能提供前面所说的“第二双眼睛”呢?答案就是芯片验证人员。芯片验证人员可以熟练使用各种验证技术来检测芯片bug，并将其上报，这样bug才能被修复。
验证是一个动态的过程，它包括在不同的环境中运行芯片，使用合理的验证数据，并在较短的验证周期内尽可能多地尝试不同的输入值。这就是芯片验证人员可以施展身手的地方。
