陷阱二：架构设计陷阱——过度设计导致面积和功耗超标
各位工程师朋友，咱们接着聊。今天要说的这个陷阱，我估计做过两三款芯片的人都踩过。那就是——过度设计。
什么叫过度设计？说白了，就是“想太多”。你总觉得未来可能有某种场景，于是提前加了一堆功能。你担心性能不够，于是把每个模块都做得特别“强壮”。结果呢？芯片面积大了，功耗高了，成本上去了，但实际用到的功能不到一半。
我见过最夸张的一个项目，架构师画框图时加了三个加速器，理由是“万一客户需要呢”。最后流片回来，客户只需要一个。那两颗加速器白白占了30%的面积，功耗还多出200mW。你说亏不亏？
为什么会掉进这个坑？
原因其实很简单。做架构设计的时候，我们往往有两个心理在作祟：
- “万一”心理——万一客户需要这个功能呢？万一性能不够呢？万一协议升级呢？
- “炫技”心理——这个算法很牛，那个架构很新，我都想放进去。
这两种心理叠加在一起，架构就越来越臃肿。你想想看，一个通信芯片，本来只需要处理三种协议，结果你硬是塞了七种。面积不超标才怪。
我在项目中遇到过类似的情况。有一次做基带处理器，团队里有个同事特别执着，非要加一个全并行FFT引擎，说“这样性能最好”。我问他：“你算过面积吗？”他说：“大概比串行的大三倍。”我又问：“你算过实际吞吐需求吗？”他沉默了。后来我们改用混合架构，面积省了60%，性能完全够用。
对策：TDD方法——技术驱动设计
怎么避免过度设计？我个人习惯用TDD方法。注意，这里的TDD不是测试驱动开发，而是技术驱动设计（Technology-Driven Design）。
TDD的核心思想就一句话：用数据说话，别拍脑袋。
具体怎么做？我总结了三步：
- 先定边界，再定方案
- 先做减法，再做加法
- 先跑仿真，再定架构
咱们一个一个说。
第一步：先定边界，再定方案
做架构之前，先把需求边界画清楚。不是“可能需要的功能”，而是必须满足的规格。
我建议你做一个表格，把每个功能模块的“必要性”列出来：
| 功能模块 | 必要性（高/中/低） | 面积预估 | 功耗预估 | 决策 |
|---|---|---|---|---|
| 协议A处理 | 高 | 0.5mm² | 50mW | 必须实现 |
| 协议B处理 | 高 | 0.3mm² | 30mW | 必须实现 |
| 协议C兼容 | 低 | 0.8mm² | 80mW | 暂不实现 |
| 全并行FFT | 中 | 1.2mm² | 120mW | 改为混合架构 |
你看，这么一列，哪些该做、哪些不该做，一目了然。别小看这个表格，它能帮你省下至少20%的面积。
第二步：先做减法，再做加法
这是TDD方法里最关键的一步。我个人的习惯是：先做一个“最小可行架构”。
什么叫最小可行架构？就是只包含必须的功能，一个多余的功能都不要。然后在这个基础上，根据仿真结果和性能分析，逐步添加必要的优化。
举个例子。做通信芯片里的信道估计模块，你可能会想到很多算法：LS估计、MMSE估计、LMMSE估计、基于深度学习的估计……但实际需求可能只需要LS估计就够了。
那你就先只做LS估计。等仿真发现性能不够，再考虑加MMSE。这叫“按需添加”，不是“提前堆砌”。
第三步：先跑仿真，再定架构
这一步很多人会忽略。他们喜欢先画框图，再写RTL，最后才跑仿真。结果发现架构有问题，改起来成本极高。
我建议你反过来：先搭一个高层次的仿真模型。用Matlab、Python或者SystemC都行。在这个模型里，你可以快速验证各种架构方案的性能、面积和功耗。
比如，你想知道用串行FFT还是并行FFT。那就建两个模型，跑一下实际的数据流。看看吞吐量够不够，延迟能不能接受。数据会告诉你答案。
// 伪代码示例：架构探索
// 场景：比较串行FFT和并行FFT
// 串行FFT模型
module serial_fft_model {
area = 0.4 mm²
power = 40 mW
latency = 1024 cycles
throughput = 1 sample/cycle
}
// 并行FFT模型
module parallel_fft_model {
area = 1.2 mm²
power = 120 mW
latency = 64 cycles
throughput = 16 samples/cycle
}
// 实际需求：吞吐量 10Msps，延迟 < 200 cycles
// 结论：串行FFT完全够用，面积省60%
你看，数据摆在这里，你还会选并行FFT吗？
避坑指南
讲到这里，我分享几个实战中容易踩的坑：
- 过度追求“通用性”——结果芯片什么都能做，但什么都不精。客户宁愿用两颗专用芯片。
- 忽视“暗面积”——有些模块看似不大，但布线、时钟树、电源网络会额外占用大量面积。我有个项目，就因为加了太多小模块，最后布局布线时面积爆了20%。
- 低估“动态功耗”——有些功能平时不用，但一旦激活，功耗瞬间飙升。记得留好功耗余量。
总结一下
过度设计这个陷阱，说白了就是“想太多，做太多”。用TDD方法，其实就是逼自己用数据说话，别拍脑袋。
我做了15年芯片，见过太多因为过度设计而失败的案例。有的芯片面积超标，成本翻倍；有的功耗过高，散热搞不定；还有的因为功能太复杂，验证覆盖率不够，流片回来一堆bug。
嗯，记住一句话：好的架构不是“功能最多”的，而是“刚刚好”的。
下一章，咱们聊聊验证策略的陷阱。那个坑更大，我当年差点因为验证不充分，把整个项目搞黄了。到时候细说。