3、需求分析与规格定义：从系统需求到芯片规格书（PRD）、关键性能指标（吞吐量、延迟、功耗、面积）、通信协议栈的拆解
说实话，很多团队做芯片失败，不是设计能力不行，而是第一步就走歪了。需求分析这活儿，看着像文档工作，实际上决定了芯片的生死。我见过太多项目，需求没理清楚就急着画架构图，结果流片回来发现性能差一截，或者功耗压不住，只能降频用——那叫一个难受。
今天我们就聊聊，怎么从模糊的系统需求，一步步推导出清晰的芯片规格书。说白了，就是把「客户想要什么」翻译成「芯片该怎么做」。
3.1 从系统需求到PRD：别让需求「飘」着
系统需求通常来自产品经理或者系统工程师。他们说的往往是：「我们要做一个5G小基站基带芯片，支持64个用户，峰值速率1Gbps。」听起来很明确对吧？但作为芯片架构师，你得追问三个问题：
- 这个1Gbps是物理层速率还是应用层速率？ 差一个协议栈，可能差30%的开销。
- 64个用户是同时激活还是在线？ 激活用户数直接决定处理器的并行度。
- 功耗预算多少？ 没给功耗约束的规格书，都是耍流氓。
我个人习惯，拿到系统需求后，先做一件事：画一个「需求-指标」映射表。把每一条系统需求，拆解成可量化、可验证的芯片指标。举个例子：
| 系统需求 | 芯片指标 | 关键约束 |
|---|---|---|
| 峰值吞吐量1Gbps | 物理层处理能力≥1.2Gbps（含开销） | 时钟频率、数据位宽、流水线深度 |
| 支持64用户 | MAC层调度器支持64个上下文 | 片上SRAM容量、DMA通道数 |
| 端到端延迟<1ms | 基带处理延迟<200μs | 流水线级数、硬件加速器响应时间 |
| 功耗<5W | 动态功耗+静态功耗<4.5W（留余量） | 工艺节点、电压域划分、门控时钟 |
嗯，这里要注意：PRD不是需求清单，而是设计约束的集合。每一行指标，都要能追溯到某一条系统需求。我曾经在一个项目中，客户说「支持VoIP」，我们想当然地加了个语音编解码器，结果发现客户用的是第三方DSP方案——白白浪费了面积和功耗。
3.2 关键性能指标：吞吐量、延迟、功耗、面积的博弈
这四个指标，就像芯片设计的「四角兽」。你不可能同时做到最好，必须做取舍。我习惯用一句话概括：在给定的功耗和面积预算下，满足吞吐量和延迟要求。
3.2.1 吞吐量：别只看数字，要看数据流
吞吐量不是简单的「数据量/时间」。你得考虑数据流的路径。比如一个OFDM解调器，输入是时域采样点，输出是频域符号。中间经过FFT、信道估计、均衡等多个模块。每个模块的吞吐量必须匹配，否则就会出现瓶颈。
我常用的方法是画一个数据流图，标注每个模块的处理速率。然后问自己：
- 哪个模块是瓶颈？
- 能不能用流水线或并行来提升？
- 数据缓冲够不够？
举个例子，一个LTE基带接收机，采样率是30.72MHz，每个采样点16bit。那么输入数据率就是30.72M × 16bit = 491.52Mbps。但经过FFT后，数据率会变成符号率乘以子载波数乘以每个符号的比特数。你想想看，如果FFT模块的处理速度跟不上输入，就得加FIFO，但FIFO大了延迟就上去了。
3.2.2 延迟：硬实时和软实时的区别
通信芯片对延迟极其敏感。比如5G的URLLC场景，要求端到端延迟1ms。这意味着基带处理必须在几十微秒内完成。我建议把延迟拆成两部分：
- 处理延迟：数据从进入芯片到处理完成的时间。取决于流水线深度和时钟频率。
- 排队延迟：数据在缓冲区等待处理的时间。取决于调度策略和负载。
硬实时场景下，排队延迟必须可控。我一般会采用时间触发调度，而不是事件触发。说白了，就是给每个任务分配固定的时间片，避免任务之间互相干扰。
3.2.3 功耗与面积：一对冤家
功耗和面积通常是矛盾的。你想降低功耗，就得用更小的工艺节点，但面积成本更高。你想节省面积，就得用更简单的电路，但动态功耗可能更大。
我常用的方法是：先定面积预算，再优化功耗。因为面积直接决定芯片成本，而功耗可以通过门控时钟、电压频率调节等技术来优化。具体来说：
- 面积优化：复用硬件资源、减少冗余逻辑、用查找表代替复杂运算。
- 功耗优化：多电压域、时钟门控、数据使能信号、低功耗状态机。
举个例子，一个FFT处理器，如果用流水线架构，面积大但吞吐量高；如果用迭代架构，面积小但延迟大。怎么选？看你的应用场景。如果是基站芯片，面积预算宽松，选流水线；如果是手机芯片，面积敏感，选迭代。
3.3 通信协议栈的拆解：从软件到硬件的映射
通信协议栈通常分为L1（物理层）、L2（MAC/RLC/PDCP）、L3（RRC/NAS）。芯片设计的关键，就是决定哪些功能用硬件实现，哪些用软件实现。我称之为「软硬件划分」。
3.3.1 拆解原则：看吞吐量和实时性
我一般遵循两个原则：
- 高吞吐量、高实时性的功能 → 硬件。比如FFT、信道编码、调制解调、CRC校验。这些功能数据量大，处理时间要求严格，软件跑不动。
- 低吞吐量、控制逻辑强的功能 → 软件。比如RRC信令处理、调度算法、重传管理。这些功能逻辑复杂，但数据量小，适合用CPU跑。
你想想看，一个5G物理层，每秒要处理几百兆比特的数据。如果用CPU做FFT，就算跑2GHz，也跟不上。但用硬件加速器，一个时钟周期就能算完一个点。这就是硬件的优势。
3.3.2 拆解实例：以LTE协议栈为例
假设我们要设计一个LTE基带芯片。协议栈拆解如下：
| 协议层 | 功能模块 | 实现方式 | 理由 |
|---|---|---|---|
| L1（物理层） | OFDM调制/解调 | 硬件（FFT加速器） | 高吞吐量，实时性要求高 |
| L1 | 信道编码（Turbo/LDPC） | 硬件（专用编码器） | 计算量大，软件无法满足 |
| L1 | 信道估计 | 硬件+软件协同 | 核心算法用硬件，参数配置用软件 |
| L2（MAC） | 调度器 | 软件（CPU） | 逻辑复杂，需要灵活调整 |
| L2 | HARQ重传 | 硬件（状态机） | 实时性要求高，需要快速响应 |
| L2（RLC/PDCP） | 分段/重组、加密 | 硬件加速器 | 数据量大，但逻辑相对固定 |
| L3（RRC） | 连接管理、移动性 | 软件（CPU） | 控制面，数据量小 |
这里有个关键点：软硬件之间的接口定义。硬件加速器怎么跟CPU通信？用寄存器、DMA还是共享内存？我建议用描述符队列的方式。CPU往队列里写任务描述符，硬件自动读取并执行，完成后通过中断通知CPU。这样既高效又解耦。
3.4 从PRD到架构设计：最后一步
有了PRD和协议栈拆解，下一步就是画架构图了。但我建议先做一件事：写一份「关键场景分析」文档。列出芯片可能遇到的最坏情况，比如：
- 满用户同时调度时，MAC层的处理能力够不够？
- 信道条件最差时，解码器的迭代次数会不会超标？
- 温度最高时，功耗能不能压住？
这些场景分析，能帮你发现PRD中遗漏的约束。我曾经在一个项目中，客户说「支持256QAM」，但我们没考虑高阶调制对EVM的要求，结果射频前端设计不达标，最后只能降阶使用。嗯，这个教训挺深刻的。
好了，需求分析和规格定义就聊到这里。下一章我们讲架构设计，到时候会拿一个具体的通信芯片做例子，从PRD一步步推导出微架构。到时候见。