一、流片前检查总览：为什么需要检查清单？流片失败的常见原因分类
说实话，我见过太多流片失败的案例了。
有些是低级错误，比如电源接反了。有些是高级错误，比如时序收敛没做好。但不管哪种，结果都一样——芯片回来不工作，几百万打水漂。
我自己就吃过这个亏。刚做芯片那会儿，有个项目流片前我自信满满，觉得该查的都查了。结果回来一测，某个模块的复位信号极性搞反了。嗯，那种感觉，你想想看，就像考试交卷后发现最后一道大题看错了题。
为什么需要检查清单？
说白了，人脑不可靠。
一个芯片设计项目，从架构定义到GDSII输出，中间要经过几十个环节。每个环节都可能出错。我个人的习惯是，把检查清单当作「第二大脑」来用。
检查清单的价值在于三点：
- 防止遗漏——你不可能记住所有检查项，尤其是项目周期长达半年以上的时候
- 标准化流程——团队里每个人都知道该查什么，不会因为换人而漏项
- 可追溯——出了问题能回溯，知道是哪个环节没查到位
核心观点：检查清单不是束缚，而是保护。它保护你的项目，也保护你的职业生涯。
我在项目中遇到过最惨的一次，是某个团队流片前忘了检查IO pad的供电域。结果芯片回来，所有IO都不工作。为什么？因为pad的供电域和核心逻辑的供电域搞混了。这种错误，如果有一份清单，根本不会发生。
流片失败的常见原因分类
根据我这些年的经验，流片失败的原因大致可以归为以下几类。我把它画成了一张图，方便你理解。
上面这张图，是我根据实际项目经验总结的。三类原因基本覆盖了90%以上的流片失败场景。下面我展开说说。
第一类：功能逻辑错误
这类错误最致命，因为它直接决定了芯片能不能干活。
我见过最典型的例子是：RTL仿真跑得挺好，但实际芯片回来就是不对。为什么？因为仿真覆盖率不够。你想想看，如果只测了正常路径，没测边界条件，那漏掉bug是迟早的事。
| 子类别 | 典型表现 | 检查要点 |
|---|---|---|
| RTL仿真遗漏 | 功能覆盖率低于90% | 检查覆盖率报告，补充遗漏场景 |
| 状态机异常 | 进入非法状态或死循环 | 检查状态转移图，确认所有状态可达 |
| 接口协议错误 | 握手信号时序不匹配 | 用断言检查协议合规性 |
警告：千万不要相信「仿真跑过了就没事」这种话。仿真只能证明你测过的场景没问题，不能证明没测过的场景也没问题。
第二类：时序收敛问题
这类错误，说白了就是芯片跑不到你想要的频率。
我记得有个项目，设计团队花了三个月做功能验证，结果STA一跑，发现关键路径有200ps的建立时间违例。改版又花了一个月，流片时间硬生生被拖后了。
时序问题里，跨时钟域（CDC）是最容易出幺蛾子的。我曾经在一个项目中，因为两个异步时钟域之间的同步器少打了一级，导致数据采样出错。芯片回来，测了三天才定位到问题。
我的建议：CDC检查一定要用工具自动跑，别指望人工检查。人眼看不出来那些深层次的同步问题。
第三类：物理实现缺陷
这类错误往往在流片前最后阶段才暴露，而且修复成本最高。
天线效应、IR Drop、电迁移（EM）——这些词听着就让人头疼。但没办法，它们是物理世界的铁律，绕不过去。
我印象最深的是一个28nm的项目，流片前一周跑IR Drop分析，发现某个区域的电压降超过了10%。查了半天，原来是电源网络规划不合理，供电密度不够。最后只能临时加电源strap，勉强把IR Drop压到8%以内。
避坑指南：物理检查一定要留足时间。我建议至少留出两周专门跑PV（物理验证），别等到流片前三天才想起来查。
检查清单的核心逻辑
说了这么多，你可能会问：那检查清单到底该怎么用？
我个人习惯是分三层：
- 设计阶段检查——每完成一个模块，就做一次自查
- 集成阶段检查——所有模块合在一起后，做全芯片检查
- 流片前最终检查——GDSII输出前，做一次终极确认
这三层检查，每一层都不能省。我在项目中遇到过有人想跳过集成阶段检查，觉得「每个模块都查过了，合在一起肯定没问题」。结果呢？模块间的接口信号命名不一致，连错了线。这种低级错误，就是省步骤的代价。
好了，这一章的内容就到这里。记住一句话：流片前的检查清单，不是给别人看的，是给自己保命的。
公众号:蓝海资料掘金营，微信deep3321