当前位置: 首页 > news >正文

物理层的FPGA实现的思考总结(1)

转换层级物理概念单位核心决定因素下层映射关系
射频频谱层信道带宽 (Bandwidth)MHz国家无线电管控空域资源宽度通过时频采样映射 (RE Grid)
符号速率层波特率 (Baud Rate)Msps子载波间隔(IFFT 点数决定)通过空间映射 (MIMO) 与星座映射 (QAM)
基带硬比特层原始物理层速率Gbps调制方式 (16/64/256QAM)、天线并发流数通过信道纠错 (LDPC/Polar) 与层级协议包头
用户应用层有用吞吐量 (Throughput)Gbps有效码率(Coding Rate)与系统开销无(最终应用层)

3GPP 协议把 Sub-6GHz(FR1 频段)的单载波最大带宽死死限制在 100MHz,是由于物理世界残酷的硬件和数学限制。

1. 原因一:无线电频谱就像“切蛋糕”,没有完整的 200M 连片空地
电磁波频谱是极其稀缺的国家资源。在 Sub-6GHz(比如主流的 3.5GHz 频段),空中早就挤满了卫星通信、雷达、军用无线电、残存的 4G 信号等。
政府(比如工信部)在划分频谱时,能给每个运营商(移动、电信、联通)好不容易切出一段
连续的 100MHz 已经是极限了。如果协议把单载波定成 200MHz,绝大多数国家的运营商根本找不到这么宽的“连片处女地”,这个标准就废了。
2. 原因二:ADC(模数转换器)的“功耗与精度”天花板
这是最卡硬件的地方。物理带宽越宽,前端 ADC 的采样率就必须成倍飙升。
100MHz 带宽,数字域采样率一般要达到 122.88 MHz。
如果直接做 200MHz 带宽,采样率就要飙到 245.76 MHz 甚至更高。
代价:超高速 ADC 的功耗呈指数级上升,发热量大得能烧毁基站;同时,采样太快会导致 ADC 的有效位数(ENOB)严重下降,原本 12-bit 的精度可能跌到 8-bit,这就导致高阶调制(如 256QAM)根本解不出来。
3. 原因三:射频功率放大器(PA)的“非线性噩梦”
功率放大器在把信号喷射到空中时,带宽越宽,它的非线性失真(比如记忆效应)就越恐怖。你们日常调测中头疼的 DPD(数字预失真) 模块,如果面对 200MHz 的超宽信号,FPGA 内部的反馈路径和乘法器资源可能要翻好几倍才能压得住邻道泄漏比(ACLR)。

那如何从最初的带宽,到最终的FPGA实现呢?

假设现在需要100M带宽的一个系统,需要怎么最后到FPGA的实现的一些考虑,需要考虑哪些因素,下面是一个例子。

步骤 ①:确定极限物理场景

要想推导硬件的极限位宽,必须代入协议允许的最高规格参数(查 3GPP MCS 表):

单载波带宽 (B) = 100 MHz。
子载波间隔 (SCS) = 30 kHz(5G Sub-6G 黄金频段)。
调制方式 = 256QAM(每个符号携带 bit)。
最大空间流数 (NLayers) = 4 层(4x4 MIMO)。
LDPC 目标码率 (R) = 0.92。

步骤 ②:套用协议公式,计算极限系统吞吐量

根据 3GPP TS 38.306 标准,5G 的理论峰值吞吐量公式为:

其中,22.08是估算出来的香农工程综合系数。

在 100MHz 带宽、30kHz 间隔下,协议规定最大可用资源块为273 。

OH(协议开销,Overhead):物理层往上,PDCP/RLC/MAC 层还要加各种包头,还要传信令,这部分大约占 10% ~14%。

NLayer(MIMO 空间流数/层数):公路设计成了几层立交桥(天线并发)。 比如 4x4 MIMO 就是 4 层立交桥,吞吐量直接乘以 4。

第一条死线:FPGA 的纯比特级物理层,必须具备每秒喂饱 个硬比特 的处理能力。

步骤 ③:引入核心时钟,计算“每拍硬比特需求”

由于外围光口硬件晶振卡死,FPGA 的骨干工作时钟必须跑在 Fclk=312.5MHz或者Fclk=250MHz。

现在,我们把一秒钟的总任务量,平摊到每一个时钟周期(拍)里:

这意味着,为了不爆仓,你的 FPGA 纯比特总线(如加扰、CRC)理论上每拍至少要能吐出 7.04 个比特。如果是250M,则为9bit 。

步骤 ④:演进到软信息层(LLR 精度量化)
数据流经过无线信道到达接收端,变成了复数 IQ 信号。解调器(Demodulator)把信号解调,吐出软信息 LLR。
根据 MATLAB 链路仿真压榨出的“高能效比奇点”:单个 LLR 的黄金量化精度为 6 bit。
那么,为了运送这 7.04 个硬比特对应的软信息,总线容量需要放大:

如果按照250M,则需要54bit/拍。

步骤 ⑤:对接商业 IP 核,定型物理总线位宽(终点)

在真实的 FPGA 设计中,我们不可能让总线跑 42.24 这种带小数的位宽。我们需要去对齐后级商业 LDPC 译码器硬核(SD-FEC IP)的物理结构。
5G 的 SD-FEC 核内部为了实现极其恐怖的矩阵并行乘法,底层的硬件计算单元(PE)并行度通常焊死为 (即一拍必须强制喂入 32 个数据,不支持挤牙膏式的挤入)。
架构师决定:为了迎合译码 IP 的胃口,前级的解速率匹配模块在输出时,必须用“乒乓 RAM”把零散的数据攒起来,然后以 32路并行 的规格一口气喷进译码器:

位宽闭环验证:192-bit 的总线一拍能运送 32 个 LLR。而我们步骤③算出来极限状态下每拍只需要 7.04 个 LLR。这意味着,在 100M 带宽下,这根 192-bit 的总线根本不需要每拍都拉高有效信号(valid)。状态机只需要每 4 拍里面拉高 1 拍( 22%的总线利用率),就能轻轻松松喂饱和满足 2.2Gbps 的极限吞吐量。这也解释了为什么同样的 192-bit 总线,可以一动不动地直接复用到 200MHz 双载波聚合( 44%利用率)甚至更高规格的架构中。

FPGA实现中的一些考虑

1、是不是 LDPC 译码这里决定了最终的最大吞吐量?

是的!在整个 5G 物理层接收端(Rx)的 FPGA 实现中,LDPC 译码器就是那个公认的、绝对的“算力瓶颈与吞吐量终结者”。

  • 解调、解扰、解速率匹配:这些模块在硬件上属于“时钟驱动型逻辑”,结构相对简单,只要有数据,硬件电路一拍就能吐出一个结果。它们天然具有超高的吞吐量上限。

  • LDPC 译码器:它属于“迭代纠错型逻辑”。数据进去了,不能马上出来,硬件在内部必须根据 H 矩阵,左手算校验节点,右手算变量节点,像揉面团一样反复迭代(比如跑 4 次、6 次甚至 10 次迭代)。

  • 结论:前级模块一拍就能处理完的数据,LDPC 译码器要在肚子里憋好几十个时钟周期。 只要 LDPC 译码器的物理计算速度被卡住,整个前级总线就会立刻通过ready信号拉低反压,让全机减速。所以说,是 LDPC 译码器的硬件极限,直接决定了整颗物理层芯片的吞吐量天花板。

2、为什么LDPC的延迟会成为影响吞吐量的一个很大的原因?

一是致命的“停等”死锁(HARQ 进程空转)

5G 引入了 “8或16个独立 HARQ 进程”,其实是在硬件缓冲区里开辟了 8 或 16 个独立的货运流水线编号。

它的真实工作流程是像转轮手枪一样,把完全不同的新包连续打出去:
第 1 毫秒:基站通过 进程 #1,向手机发射 “新数据包 A”。发完不等反馈!
第 2 毫秒:基站通过 进程 #2,向手机发射 “新数据包 B”。
第 3 毫秒:基站通过 进程 #3,向手机发射 “新数据包 C”。
……
第 5 毫秒:此时,手机终于把 “数据包 A”(进程 #1) 的译码做完了。手机发现错了,向上发送 NACK #1。
第 6 毫秒:基站收到了 NACK #1。哦!原来进程 #1 的货翻车了。于是基站立刻抽出进程 #1 的缓冲区,重新打包并重传“数据包 A”。

大局观:这就叫 HARQ 进程。它们是 16 个并行独立运转的停等机制。如果你的 LDPC 译码太慢(比如超过了 16 毫秒都没解完进程 #1),基站把 16 个进程发完一轮后,手里没有空闲的进程号可用了,系统就会瞬间被反压堵死,彻底停工打摆子。

二是内存爆仓与反压(Backpressure)
如果后级 LDPC 译码器因为延迟大而堵塞,它的 ready 信号就会无情地拉低(相当于告诉前级:我还没算完,别给我塞数了)。
这一拉低,会导致前级的 解速率匹配乒乓 RAM 瞬间写满。
乒乓 RAM 满了,就会向上级解调模块反压。
一路反压上去,最终导致 PCIe 总线或者光口直接丢包。

3、怎么确定需要多少个LDPC的IP核呢?

在真实的 5G 加速卡项目立项时,架构师既要看手册静态计算(做底线防御),又要跑高级仿真(做压力测试)。这是一个“两步走”的严密工程过程:

第一步:看 IP 核手册进行“理论静态确定”(算绝对下限)

通常手册会告诉你:

“在 312.5MHz 工作时钟下,单核支持 5G 极限 Basegraph 1 矩阵,跑最大 8 次迭代时,单个核所能提供的理论硬核吞吐量

用带宽算出来的物理层极限吞吐量需求(比如双载波拉满需要 4.4 Gbps)。

结论一:通过看手册静态计算,你确定了绝对不能少于 4 个核。如果只放 3 个核,纯数学上就注定了在好信道满载时一定会爆仓。

第二步:跑多核动态链路仿真(算“乱序重组”和“极端噪声”的代价)

静态计算非常理想化(默认每个块都整整齐齐地进来),但现实中由于我们前面聊过的“乱序吐出”和“Early Termination(提前终止)”,数据流在时间轴上是极度无序且具有突发性(Burst)的。 这时候,算法工程师需要在 MATLAB 或 C++ 的系统级仿真平台(Simulink 或 SystemC 架构仿真)中,搭建一个“多核分发调度仿真模型”

4、一般HARQ进程设为多少,实际项目中,设置的数目考虑的因素是什么?

在目前的 5G(Sub-6GHz)实际商用网络中,几乎全行业统一默认设置为 16 个 HARQ 进程。虽然 3GPP 协议允许更少的进程(如 4 或 8),但为了压榨速率,主流基站和手机卡死在 16。

考虑的核心因素只有四个字:“往返时延(RTT,Round Trip Time)预算”。基站把
进程 #0 发出去之后,这个数据要经历以下漫长的硬件物理旅程:
空中传输时延:信号在空气里飞过去。
手机 Low-PHY 处理:解调、FFT 变换、解速率匹配。
手机 High-PHY 译码:LDPC 译码(这就是最大的耗时点!)。
上行反馈准备:手机打包 ACK/NACK,在下一个上行时隙通过天线喷向基站。
基站接收处理:基站解调出 ACK/NACK,并通知 MAC 层 CPU 调度器。
这一整圈跑下来,在 5G 30kHz 子载波(一个时隙 )的硬性规定下,全链路的总往返时间大约需要 。也就是相当于折合 个时隙(Slots)。

如果你只设 8 个进程:基站发完 8 个包(耗时 4 毫秒)后,由于第 1 个包的 ACK 还在空中飞(需要 6 毫秒才到),基站手里已经没有空闲的进程号了,只能被迫原地刹车等反馈,造成吞吐量暴跌。
如果设 16 个进程:基站一口气发了 16 个包(耗时 8 毫秒)。当它正准备发第 17 个包时,第 1 个包的 ACK 刚好在第 7 毫秒热乎乎地送到了基站手里!进程 #0 瞬间解锁,基站可以无缝连接继续发新货。
所以,HARQ 进程数必须刚好大于“全链路硬件处理时延的总和”。只要你的 LDPC 译码器设计得太慢,导致总时延超过了 16 个时隙,这 16 个进程就会不够用,系统就会发生死锁空转。

5、一般 LDPC 译码的迭代次数是多少呢?

在 5G 实际硬件落地中,最大迭代次数通常限制在 $6 \sim 8$ 次,而在信道环境完美时,平均迭代次数往往只有 1~2次。

这是一个在“误码率性能(BER)”与“硬件时延/功耗”之间做出的标准工程折中(Trade-off):

  • 迭代 1~2:只能纠正极少量的随机噪声。如果信道环境极好(比如手机就在基站底下),1次迭代 CRC 就能全绿通过,立刻触发提前终止(Early Termination),数据直接出港。

  • 迭代 4~6:瀑布效应(Waterfall Region)最明显的阶段。绝大多数中等噪声砸坏的比特,在这个阶段会被硬生生纠正回来,这是硬件工作最密集的区间。

  • 迭代 8 次以上(Diminishing Returns):进入了严重的边际效益递减状态。数学理论上,迭代 20 次确实比 8 次误码率更好。但是,从第 8 次迭代到第 20 次,为了换取微乎其微的 0.1dB增益,你付出的代价是硬件译码时延暴增一倍、功耗直接翻倍、前级 FIFO 彻底爆仓。

所以在商用 FPGA IP 核(如 Xilinx SD-FEC)的配置界面里,架构师会严酷地把 MAX_ITERATION(最大迭代次数)死死限制在 8 次(或者极端恶劣信道下开到 10 次)。如果迭代了 8 次 CRC 依然报错,硬件立刻放弃挣扎,直接判定这个块死亡,大方地向后级吐出 NACK,让系统走 HARQ 重传机制去要新包。用一次空中重传的代价,换取 FPGA 内部流水线的绝对时序安全,这就是最纯粹的工业落地思维。

6、那像这种在FPGA实现的物理层,实现的硬件架构是什么样子的?

在通信和数据中心工业界,5G 物理层在 FPGA 中的落地,有着非常标准且成熟的硬核硬件架构和系统部署形态。

宏观部署架构:物理层拆成“两半”跑

在 5G 时代,物理层(PHY)因为计算量实在太大,被 3GPP 协议一分为二:High-PHY(高物理层) 和 Low-PHY(低物理层)。这就导致了两种不同的硬件形态:

形态 A:插在 CPU 主板上的“基带加速卡”(负责 High-PHY)
这就是你提到的最核心的形态,在业界通常叫 Inline 加速卡 或 Lookaside 加速卡(比如 Xilinx 的 T1/T2 卡,或者 Intel 的 N6000 系列)。
物理形态:它是一块标准的 PCIe 板卡,直接插在通用服务器(如浪琴、中兴、戴尔的 X86/ARM 服务器)的 PCIe 插槽上。
分工协作:
CPU(主服务器):擅长跑复杂的条件分支逻辑,所以负责跑 5G 的 3 层(RRC)、2 层(MAC/RLC)以及核心网协议。
FPGA 加速卡:擅长跑高并发的密集数学计算。当 CPU 收到用户数据要下发时,通过 PCIe 总线(如前面推导的 250MHz 核心时钟),把硬比特数据如同倒水一样源源不断地灌进 FPGA 加速卡中。
卡内:FPGA 加速卡吃进比特后,全速运行我们之前讨论的 CRC 加扰 LDPC 编码 速率匹配(High-PHY 阶段)。

形态 B:挂在铁塔天线罩里的“射频前端 SOC”(负责 Low-PHY)
数据在加速卡里做完编码和速率匹配后,并不会在本地直接变成无线电,而是通过卡上的 25G/100G 光口(eCPRI 协议,跑在 156.25MHz 或 312.5MHz 基准时钟上),走光纤直接打到高高挂在铁塔上的 AAU(有源天线单元) 内部。
AAU 内部形态:天线罩里面也有一颗强劲的芯片(通常是专用的高端 FPGA/ASIC,或者是 Xilinx 的 RFSoC 芯片)。
卡内:它在塔顶实时接收光纤传来的数据,在芯片内部全速跑物理层的下半部分(Low-PHY):IFFT/FFT(OFDM 调制) 数模转换(DAC) 到功率放大器(PA)和天线阵列中。

7、层映射中,比如4T4R,四路功率放大器射频通道,对应四个基站天线的话,那如果只用一层层映射,四路PA都有功率吗?

是的,都有功率。当手机掉到 1 层(Rank 1)时,说明信道已经极其恶劣了。这时候如果基站真的关掉 3 路 PA,只剩 1 路天线在孤军奋战,手机可能直接就彻底断网了。
基站此时正确的做法是:让 4 根天线、4 个 PA 同时开足马力,同时发射这 1 层的数据(通过预编码矩阵 进行相位微调)。4 路信号在空中叠加,手机天线收到的信号能量会瞬间放大 4 倍(获得
6dB 的阵列增益)!这能生生把濒临断网的手机从生死线上拉回来。

8、 在物理层(PHY)和 MAC 的最前端,时钟频率和速率是被 PCIe 或 eCPRI 协议绑定的吗?

不管是 PCIe 还是 eCPRI(光口),它们都属于高速串行接口(SerDes)。这类接口有一个共同特点:不需要在外面单独连一根时钟线,而是把时钟信号直接“揉”进高速数据流里(时钟数据恢复,CDR 机制)。为了让接收端的 FPGA 能把数据完美解出来,协议必须对时钟做出极其严苛的硬性规定:

PCIe 接口:外部基准:PC 主板的 PCIe 插槽第 A11、A12 号引脚,会雷打不动地向外输出一个 的基准参考时钟(REFCLK)。
芯片内部:当你例化 Xilinx 的 PCIe IP 核(如 XDMA / QDMA)时,IP 核内部的锁相环(PLL)会吃进这个 ,并根据你配置的 PCIe 世代(Gen)和通道数(Lane),自动倍频并吐出一个“用户时钟(User Clock)”。
PCIe Gen3 x8:IP 核硬核会硬性吐出 250MHz。
PCIe Gen4 x8:IP 核硬核会硬性吐出 250MHz 或 500MHz。
结论:这个接口一侧的时钟是由 PCIe 组织和 Xilinx 硬件团队写死了的 。

eCPRI 光口:对齐无线的“黄金频率”
在光通信里,为了实现标准的线速(如 10Gbps / 25Gbps),全行业的硬件物理层统一对齐两个黄金频率:156.25MHz 或者 312.5MHz。
晶振焊死在板子上,它的频率是雷打不动的。你用 Vivado 配置以太网/eCPRI IP 核时,顶多只能选择“把这个 156.25MHz 分频变成78.125MHz ”或者“倍频成312.5MHz ”,你绝不可能把它配置成自定义频率。

FPGA 必须用接口分频出来的时钟吗?能用单独的晶振吗?

可以用板子上完全独立的、干净的本地晶振时钟来跑你的 5G 物理层算法逻辑。

在大型 FPGA 加速卡设计中,时钟树通常被划分为两个阵营:
接口时钟域(Interface Clock Domain):由 PCIe 核或 eCPRI 核直接提供(比如 或 )。这个时钟域范围非常小,仅仅用来驱动 IP 核自身的数据接口。
核心用户逻辑时钟域(Core/User Logic Clock Domain):由板子上的另一个独立高精度晶振(比如专用的通信同步差分时钟源)输入给 FPGA 的锁相环(MMCM/PLL),产生一个例如 的时钟,专门用来跑你的解调、加扰和 LDPC 译码。

但是,当你决定接口用接口时钟、算法用独立晶振时,这就变成了典型的“异步时钟系统”。此时,数据要从 PCIe 接口进入你的算法模块,必须跨越时钟边界。需要用异步 FIFO(Asynchronous FIFO)进行跨时钟域的处理,异步 FIFO 内部通过格雷码(Gray Code)和两级寄存器同步(2-Stage Synchronizer)技术,把两个独立晶振的相位差在底层死死化解掉,确保数据不会变毛刺。

在工业界,如果没有极其特殊的需求,绝大多数 5G 物理层架构师都会选择直接使用接口(特别是光口 eCPRI/以太网)吐出来的用户时钟来跑核心算法逻辑。

http://www.jsqmd.com/news/984626/

相关文章:

  • Paperxie 工科攻坚利器:AI 代码生成一键搞定毕业论文程序源码难题
  • 防眩光AG+硬化复合板厂家推荐:复合功能板适合哪些应用场景
  • 番禺洛浦奢侈品回收第一名|金小福名表名包名酒钻石翡翠黄金全品类专业回收 - 花生花生1
  • PyMuPDF:这个 Python 库,把 PDF 所有操作都覆盖了
  • 苹果WWDC26引爆全端AI产品,Meta/WIMI微美全息加速抢滩XR眼镜硬件市场
  • BiliBili-UWP桌面版终极秘籍:告别卡顿,打造你的专属B站体验
  • 2026年AI问答流量服务公司选购指南:技术架构、行业应用与决策框架 - 优质品牌商家
  • LumeValley|企业级Agent全栈开发,AI智能体规模化落地
  • 2026必看!独立开发者高性价比AI编程工具大全
  • Boss-Key:Windows用户的隐私守护神,一键隐藏窗口的终极解决方案
  • 2026 主流 GEO 源码厂商实测:云罗 GEO、摘星智能、棋引科技技术与落地能力对比
  • Effective C++ 条款06:若不想使用编译器自动生成的函数,就应该明确拒绝
  • 重新定义音乐自由:插件化播放器如何让你真正掌控音乐体验
  • 抗垢水路:SEGE在硬水地区保持清爽
  • idea+git插件+云备份实现项目新分支新建维护
  • 视觉伺服:基于图像的IBVS与基于位置的PBVS
  • 如何让《Honey Select 2》游戏体验全面升级:HS2-HF_Patch终极指南
  • Whisky终极指南:在macOS上轻松运行Windows程序的5个简单步骤
  • 3分钟搞定Windows和Office激活:KMS_VL_ALL_AIO智能脚本全解析
  • 3个月完成全链路升级:300人汽配制造企业SAP升级落地真实案例
  • 告别手忙脚乱:如何用League-Toolkit让英雄联盟游戏体验更丝滑
  • Docker Compose 深度剖析:一文打尽所有配置信息
  • 基于Spring Boot的智能停车导航与管理系统设计与实现
  • MPV播放器终极配置指南:从零构建专业级媒体播放体验
  • 阿里云Linux部署PHP项目:LNMP搭建+域名HTTPS+性能优化全流程
  • 前端周刊2026W22 | React 13周年、TanStack Router、Deno 2.8、Node.js 26、npm 分阶段发布
  • 【人工智能】Gemini回复:“Cherry studio跟Monica 选一个,你选谁?理由是?”
  • 机械泵维修方法?机械泵维修费用多少!
  • Windows系统文件dhcpcsvc6.dll文件丢失找不到问题解决
  • 2026年主流AI招聘工具深度对比:哪款真正能帮你省下80%筛选时间