1. 物理层概述：蜂窝通信系统架构、物理层在协议栈中的位置、物理层核心功能
各位同学，大家好。我是你们这门课的老朋友。今天咱们正式开讲《蜂窝通信芯片物理层实现精讲》的第一章。
做芯片物理层实现，说白了就是跟“空气”打交道。你想想看，手机里那点电信号，怎么就能穿越几公里，准确无误地传到基站？这背后全是物理层的功劳。我个人习惯把物理层比作“通信系统的地基”——地基没打好，上面协议栈盖得再漂亮，也是空中楼阁。
1.1 蜂窝通信系统架构长什么样？
先看宏观。一个典型的蜂窝系统，从芯片视角看，主要分三块：终端（UE）、基站（gNB）、核心网（5GC）。
终端就是你的手机、CPE、物联网模组。基站是那个挂在铁塔上的大盒子。核心网在机房深处，负责认证、计费、移动性管理。
物理层芯片主要待在终端和基站的基带处理单元里。我当年做第一块4G芯片时，最头疼的就是终端和基站之间的“握手”——时偏、频偏、信道估计，一个没对齐，整个链路就断了。
核心要点：物理层芯片只关心“比特流”到“无线波形”的转换，不关心上层是发微信还是看视频。
下面这张图，是我用SVG画的系统架构简图。你看一眼就能明白物理层的位置。
1.2 物理层在协议栈中的位置
协议栈分三层：L1（物理层）、L2（MAC/RLC/PDCP）、L3（RRC/NAS）。
物理层在最底下，直接跟硬件打交道。L2的MAC层会给物理层下发传输块（Transport Block），物理层负责把它变成OFDM符号，从天线发出去。
嗯，这里要注意：物理层和MAC层之间有个“控制接口”，叫DCI（下行控制信息）和UCI（上行控制信息）。我刚开始做芯片时，总搞混DCI和MAC CE的区别。后来踩了个坑——有一次DCI解析错了，导致整个子帧的PDSCH数据全废了。从那以后，我每次做物理层设计，都会先画一张“控制流与数据流分离图”。
我的经验：物理层实现时，一定要把“控制信道”和“数据信道”的硬件路径分开。控制信道对时延极其敏感，数据信道对吞吐量敏感。混在一起设计，后期调试会痛不欲生。
1.3 物理层核心功能拆解
物理层到底干哪些活？我把它归纳为四大块：编码、调制、多天线、资源映射。
1.3.1 编码：给数据穿上防弹衣
无线信道太恶劣了。信号会衰落、会受干扰、会多径。编码的目的就是加冗余，让接收端能纠错。
5G NR里主要用两种编码：
- LDPC码：用于数据信道（PDSCH/PUSCH）。吞吐量高，适合硬件并行实现。
- Polar码：用于控制信道（PDCCH/PUCCH）。短码性能好，适合小包场景。
我记得第一次在FPGA上实现LDPC译码器时，迭代次数设得太高，导致延迟超标。后来发现，对于高信噪比场景，提前终止迭代能省一半功耗。这个技巧后来成了我们团队的“祖传代码”。
避坑指南：我曾经在芯片流片前发现LDPC的校验矩阵配置错了——基图（Base Graph）选成了BG2，但实际场景需要BG1。改一次掩膜花了三个月。所以，编码器的参数配置一定要做成可编程的，别写死。
1.3.2 调制：把比特变成符号
调制就是把0/1比特映射到复数平面上。5G NR支持：
| 调制方式 | 每符号比特数 | 典型场景 |
|---|---|---|
| QPSK | 2 | 控制信道、低信噪比 |
| 16QAM | 4 | 中等速率数据 |
| 64QAM | 6 | 高速率数据 |
| 256QAM | 8 | 近点、高信噪比 |
你想想看，256QAM的星座点间距非常小，对信道估计精度要求极高。我做过一个测试：信道估计误差超过5%，256QAM的BLER直接飙到50%以上。所以，调制阶数越高，对物理层算法的要求就越苛刻。
1.3.3 多天线：MIMO的魔法
多天线技术是5G吞吐量翻倍的核心。物理层要处理：
- 层映射：把码字映射到多个空间层上。
- 预编码：根据信道状态信息（CSI）调整天线权重。
- 信道估计：从DMRS中提取每根天线的信道响应。
我个人习惯把MIMO接收机分成两类：线性接收机（MMSE）和非线性接收机（ML/SIC）。芯片实现时，MMSE是主流，因为复杂度可控。但如果你追求极限性能，SIC（串行干扰消除）是必选项。
关键点：多天线实现的瓶颈往往不在算法本身，而在“数据搬运”。4发4收的MIMO，基带数据量是单天线的16倍。总线带宽和DDR访问冲突，才是真正的硬件杀手。
1.3.4 资源映射：把符号放到时频格子上
5G NR的资源网格是二维的：时域（OFDM符号）和频域（子载波）。物理层要把调制后的符号，按照协议规定的位置，填到资源元素（RE）上。
资源映射的难点在于“灵活”。5G NR支持多种参数集（Numerology），子载波间隔可以是15kHz、30kHz、60kHz... 时隙长度也跟着变。芯片设计时，资源映射器必须能处理动态配置。
我曾经在项目中遇到一个bug：资源映射时，把DMRS的位置算错了两个RE，导致信道估计出来的结果全是噪声。查了三天，最后发现是查表索引少加了1。从那以后，我要求团队所有资源映射的代码，必须用形式化验证工具跑一遍。
1.4 物理层实现的“三座大山”
做物理层芯片，说白了就是跟三个东西死磕：
- 实时性：一个子帧只有1ms（NR里是0.5ms或1ms），所有处理必须在这个时间内完成。
- 灵活性：协议版本在变，运营商需求在变，芯片不能动不动就重流片。
- 功耗：手机电池就那么大，物理层占了基带功耗的60%以上。
嗯，这三座大山，我们会在后续章节里一个一个翻过去。今天先给大家搭个框架，后面每一章都会深入细节。
给新人的建议：别急着看代码。先把物理层的“数据流”和“控制流”画清楚。数据从MAC层下来，经过编码、加扰、调制、层映射、预编码、资源映射、OFDM生成，每一步的输入输出是什么，位宽是多少，时钟周期是多少——这些搞明白了，写代码就是体力活。
公众号:蓝海资料掘金营，微信deep3321