在普通软件开发中，程序员写完代码，编译通过后跑几个测试用例，如果没发现大问题，似乎就可以发布上线了。即便上线后发现了Bug，也可以通过发布补丁或版本更新来快速修复。
那么，在芯片设计这个同样以写代码（RTL）为核心的领域，为什么不能也这么“潇洒”，而是必须投入极其庞大的人力、时间和计算资源去做验证呢？
今天，我们分三个角度来分析一下“设计为什么要做验证”？

1、芯片设计的高难度、高成本

没有任何一个工程师或团队能够完全理解整个芯片中所有模块在任意时刻、任意场景下的所有交互行为。在设计过程中，不可避免地会产生理解偏差、逻辑遗漏、边界条件考虑不周、模块接口通信错误等问题。写代码必然会产生Bug，这是一个客观规律，而不是能力问题。
芯片一旦制造完成，就基本无法修改。一个隐藏在数十亿晶体管中的微小错误，其代价可能是数千万美元的流片费用、一整年的项目时间，甚至是一家公司的声誉和市场机会。这不仅仅是“修复Bug”的问题，而是一场代价高昂的“灾难”与一次成本可控的“调试”之间的天壤之别。
所以对于企业来说，验证是一种“性价比”极高的投资。
一方面是越早发现Bug，成本越低：在RTL设计阶段发现一个Bug，修复成本可能只是工程师几个小时的调试时间。如果在流片后才发现，成本则是千万美元和数月的项目延迟。验证就是在用可控的工程成本，去规避不可控的巨量风险。
另一方面，是抢占市场窗口。电子产品市场瞬息万变，错过了关键的上市窗口（Time-to-Market），即使芯片功能完美，也可能失去商业价值。一次流片失败导致的项目延期，很可能意味着将市场拱手让给竞争对手。
简言之，芯片设计不是 “写代码”，而是 “造硬件”。一切有可能出现的问题，都必须在流片之前预判并解决。

2、对IC设计的好处

当然，验证工作主要由专职的验证工程师完成。这里说到的“IC设计做验证”主要是指体验一下验证的工作内容。这一定不是白白浪费时间，反而对于自己的工作有一定的助益。
当IC设计工程师亲自上阵验证代码时，他们会更快发现哪些接口定义模糊、哪些状态机难以覆盖、哪些功能在仿真环境下几乎无法测试。这种体验会促使他们在下一次写RTL代码时，下意识地写出：
· 结构更清晰的代码，便于验证工具分析。
· 添加必要的观测点（如断言、性能计数器），方便调试。
· 避免过于奇巧淫技（Over-tricky）的实现，提高代码的可读性和可预测性。
另一方面，也有助于培养更加严谨的工程思维。之前芯易君分析过验证思维，应该是一种极度严谨、追求完备、怀疑一切的思维模式。
在一定程度上体验验证工作，可以帮助IC设计工程师培养这种思维模式。它能让设计者习惯于思考 corner case、边界条件和异常流，从而在设计之初就规避掉大量潜在问题，成为一名更优秀的工程师。

“设计做验证可以从另外一个角度提升设计能力，整天看testcase能弥补你设计时候各种考虑不周”——cr：dadadupi

再从长期发展来说，设计和验证兼修，证明工程师具备更全面的技能树。一个既懂设计又懂验证的工程师，更容易成为架构师。

3、设计其实很少做验证

其实在业内，“设计做设计、验证做验证”是常规的工作模式，一般很少会出现需要设计做验证的情况。
所以标题中的“设计也要做验证”属于业内比较的特殊情况：

尤其是初创公司发展初期或者成本敏感的项目，那就会出现一种奇景：设计同时需要单独架构工作（算法硬化为芯片和系统架构），本职设计工作，flow搭建（工具适配或编写），BES（搞sdc
cdc跑流程摆位置分析结果）以及同样海量的验证工作。——cr：尼德兰的喵

综上所述，芯易君认为设计可以体验一下验证工作，但要是长期做验证工作肯定是不靠谱的。
体验验证工作，可以帮助IC设计工程师系统理解芯片开发工作，对芯片开发全流程有更深刻的认识，也能更好地与验证工程师沟通，理解对方的需求。
所以能体验一遍全流程 设计→验证→后端，是非常难得的机会和加分项。
欢迎了解AI芯片NPU 22nm流片全流程项目