软件行业流行敏捷开发已经二十年了，迭代快、反馈快、调整快，几乎成了现代软件工程的标配。
芯片研发行业偏偏还在大量使用瀑布模型。瀑布模型的核心逻辑是：每个阶段完成，输出检查合格，才进入下一阶段。
在芯片前端的研发流程里，典型的顺序是：架构设计 → RTL编码 → 功能仿真 → 逻辑综合 → 静态时序分析 → 形式验证 → 版图。每一步的输入，都强依赖于上一步的输出质量。
这就是为什么芯片行业很难照搬软件敏捷方法的根本原因。
软件的"快速迭代"有一个隐含前提：每次修改的代价相对低，跑一次CI/CD流水线，发现问题，回滚或修复，成本可控。
芯片研发里有一个东西叫流片——把设计交给晶圆厂制造出实际的芯片。一次流片的费用从几十万到几千万美元不等，周期通常三到六个月。
这个成本结构，从根本上决定了芯片研发不能像软件那样"先上线再迭代"。每一次流片之前，必须尽可能把问题消灭在设计阶段。瀑布模型的每个阶段门控，就是这个目标的执行机制。
当然，瀑布模型也有它的代价，而且在快节奏的研发压力下，代价会被放大。
最典型的问题是：前期阶段的问题发现越晚，修复成本越高。如果架构阶段的设计决策有缺陷，到了验证阶段才被发现，这时候改动的影响面可能覆盖整个RTL，相当于重来一大半。
这不是瀑布模型本身的错，是前期阶段评审不严格的代价。瀑布流程最脆弱的地方，不是它的顺序性，而是对上游阶段质量的强依赖。
业内的一些实践，是在瀑布的大框架里加入局部迭代机制，来弥补这个弱点。
比如，架构设计阶段同步进行高层次仿真验证，在RTL还没写出来之前就发现接口设计问题；RTL编码阶段引入持续集成的自动化lint和基础功能测试，尽早暴露编码错误；验证和综合阶段并行推进。
这些方法没有颠覆瀑布，而是在每个阶段内部引入了更快的反馈循环。目标是用局部的"小敏捷"，缩短在瀑布各阶段内的问题暴露周期。
瀑布模型既不是守旧，也不是完美方案。
它是芯片研发物理约束和工程现实在流程层面的直接映射。在这个约束下，真正的竞争力来自于每个阶段本身的质量水平，而不是对流程结构的改造。
把架构评审做深，把RTL检查做细，把验证覆盖率做高——这些才是在瀑布框架里真正能积累护城河的地方。
