4、设计规格（Spec）制定：如何读懂通信协议（以LTE为例）、关键指标提取（吞吐率、时延、功耗）、撰写设计文档

好，咱们进入正题。这一章聊的是怎么把一本厚厚的通信协议，变成芯片设计团队能用的设计规格书。

说实话，我见过不少新人，一上来就抱着3GPP的协议啃。啃了三个月，越看越懵。为什么？因为协议是写给系统工程师看的，不是写给芯片设计师看的。你得学会“翻译”。

4.1 读懂通信协议：以LTE为例

LTE协议，说白了就是一套“收发双方怎么说话”的规矩。它规定了什么时候说、说多快、用什么调调、说错了怎么办。

我个人习惯，拿到一份协议，先不看细节。先看目录。3GPP 36.211、36.212、36.213这些，各有分工：

• 36.211：物理信道和调制。说白了就是“信号长什么样”。
• 36.212：编码和复用。就是“数据怎么打包”。
• 36.213：物理层过程。就是“什么时候该干什么事”。

举个例子，你要设计一个LTE下行接收机。你该看什么？

先看36.211，搞清楚OFDM符号怎么映射到资源格上。再看36.212，知道数据比特是怎么加CRC、怎么Turbo编码的。最后看36.213，了解HARQ的时序要求。

4.2 关键指标提取：吞吐率、时延、功耗

协议读完了，下一步就是提取关键指标。这三个指标，是芯片设计的“铁三角”。

4.2.1 吞吐率

吞吐率，说白了就是“一秒钟能传多少比特”。LTE的峰值速率怎么算？

公式其实不复杂：

峰值速率 = (RB数 × 每个RB的子载波数 × 每个子载波的调制阶数 × 码率 × 天线数) / 时隙长度

举个例子，20MHz带宽，100个RB，64QAM（6比特），码率0.93，4×4 MIMO：

峰值速率 ≈ (100 × 12 × 6 × 0.93 × 4) / 0.001 = 约 300 Mbps

嗯，这里要注意。这只是理论峰值。实际中，控制信道、参考信号、保护间隔都会吃掉一部分。我做过一个项目，客户非要我们达到理论值的95%。结果发现，光是CP（循环前缀）就占了7%的开销。最后只能靠优化调度算法来弥补。

4.2.2 时延

LTE对时延的要求很苛刻。用户面时延要求小于5ms。这意味着什么？

从数据到达MAC层，到从物理层发出去，中间只有几个毫秒。你的硬件流水线必须设计得足够快。

我曾经遇到过一个坑。协议上写的是“TTI（传输时间间隔）为1ms”。我们想当然地认为，处理一个TTI的数据，有1ms的时间。错！实际上，你必须在下一个TTI开始前处理完当前的数据。留给你的时间，可能只有0.5ms甚至更少。

4.2.3 功耗

功耗这个事，协议里不会直接写。但你可以从协议的特性推导出来。

比如，LTE支持DRX（不连续接收）。协议规定了DRX的周期和持续时间。这直接决定了接收机可以睡多久。

再比如，MIMO的层数。4层MIMO的功耗，肯定比单层高得多。你得在性能和功耗之间做权衡。

我做过一个IoT芯片，要求峰值速率不高，但待机功耗要极低。我们就把DRX周期设到了2.56秒，接收机大部分时间都在睡觉。结果待机电流做到了10uA以下。

4.3 撰写设计文档

好了，指标提取完了。下一步，写文档。

设计文档（Design Specification）是给整个团队看的。架构师、前端设计、验证、后端，都要靠它沟通。写不好，后面全是坑。

我个人的文档模板，大概长这样：

章节	内容	说明
1. 概述	芯片功能、应用场景、主要指标	让读者3分钟知道这是干什么的
2. 接口定义	输入输出信号、时序、协议	这是验证团队最关心的
3. 模块划分	顶层框图、子模块功能、接口	架构师和前端设计一起看
4. 详细设计	每个模块的状态机、算法、流水线	这是最核心的部分
5. 性能分析	吞吐率、时延、功耗的计算和仿真结果	用来证明设计满足指标
6. 验证计划	测试用例、覆盖率目标	验证团队照着这个干活

写文档有个原则：让别人能复现你的设计。你想想看，三个月后你自己回头看，能不能看懂？如果看不懂，那别人更看不懂。

嗯，这一章就到这里。下一章，咱们聊聊系统架构设计。怎么把功能模块划分清楚，怎么定接口，怎么避免“牵一发而动全身”的悲剧。