BCM4375 Wi-Fi 6双频并发与零等待DFS解析

简介：这份博通BCM4375数据手册面向Wi-Fi 6与蓝牙5.0无线芯片的硬件设计、射频调试及驱动开发人员，可用于移动终端、平板与物联网设备的方案选型、原理图设计和板级问题排查。文档系统梳理双频双路802.11ax架构，说明单频段最高1200Mbps、双频同时工作1430Mbps的速率表现，并覆盖20/40/80MHz信道、1024-QAM调制、多用户多输入多输出、零等待动态频率选择以及旧版协议兼容等特性。接口与处理部分介绍PCIe主机通道、Cortex R4处理器及片上存储配置；蓝牙部分涉及Core 5.0、高速UART主机控制接口、PCM音频与串行闪存升级通道。硬件设计信息还给出3.0V至5.25V供电范围、OTP配置区、GPIO数量及WLCSP封装尺寸。资源包仅含1个PDF文件，约1.02MB，便于按章节查阅功能框图、电气参数和引脚定义。已有2348人学习下载，适合需要快速核对芯片规格并完成驱动适配的工程师参考。

1. 1430 Mbps 不是双频叠加，而是两套射频同时在跑

翻 BCM4375 的 datasheet，最容易被误读的一行是 1430 Mbps。直觉会把它算成"2.4 GHz 跑一份、5 GHz 跑一份，加起来"，可同一页又写着单频段只有 1200 Mbps——如果两个频段只是分时轮着用，凭空多出来的 230 Mbps 没有出处。真相是这颗 Wi-Fi 6（802.11ax）SoC 内部塞了两套完整的 2×2 MAC/PHY：主核跑 20/40/80 MHz、1024-QAM，辅核跑 20 MHz、256-QAM，两个频段可以真正同时在线，也就是 RSDB。

把这件事想明白，后面一连串看起来零散的设计才有解释：为什么主核和辅核的调制阶数不一样、为什么天线数量不等于空间流数量、为什么零等待 DFS 和双频并发抢的是同一份射频资源。这颗芯片的很多"参数"，本质都是同一块硅片面积在不同维度上的切分，参数表只是结果，框图和时序才是原因。

2. RSDB 的双 2×2：两颗 WLAN 核怎么共用一套射频前端

2.1 主核与辅核不是对称的：80 MHz/1024-QAM 对 20 MHz/256-QAM

框图里两个 WLAN 核是分开画的：5 GHz Radio 挂 HE80 的 2×2 PHY 和 MAC，2.4 GHz Radio 挂 HE20 的 2×2 PHY 和 MAC，各自有独立的 MAC 层。这一点很关键——RSDB 不是"一个 MAC 在两个频段之间快速切换"，而是两个 MAC 各自持有自己的信道上下文、各自的退避计时器、各自的省电状态机。分时复用的方案在切换瞬间必然丢 beacon 和丢 ACK，两套 MAC 并行才谈得上"同时在线"。

不对称是刻意的。5 GHz 侧给到 80 MHz 带宽和 1024-QAM（每子载波 10 bit），2.4 GHz 侧压到 20 MHz 和 256-QAM（每子载波 8 bit）。看起来像阉割，但 1024-QAM 对 EVM 的要求比 256-QAM 高出近 10 dB，只有在 5 GHz 的干净信道加 80 MHz 带宽下才稳定成立；2.4 GHz 上 40 MHz 几乎找不到连续干净的空隙，给了也是纸上参数。

这张表还解释了一个常被忽略的兼容性细节：datasheet 里写 full IEEE 802.11a/b/g/n/ac legacy compatibility，意思是对端设备还停留在 11n 的时候，这颗芯片不会退化成"只能连 2.4 GHz 的老设备"，而是让辅核去承接这段慢速链路，主核继续在 5 GHz 上跑高速业务。老设备拖慢全网，在双核架构里被隔离掉了。

2.2 1430 是怎么算出来的：把子载波数量和符号时间都摆进去

厂商在 datasheet 上写的峰值速率不是随口报的，它是 OFDM 的乘除法。802.11ax 的子载波间隔固定 78.125 kHz，一个符号 12.8 µs，加上 0.8 µs 的短保护间隔，每个符号占 13.6 µs。剩下的就是把每个符号能塞多少比特算清楚。

# 802.11ax(HE) 峰值速率估算：数据子载波 × 每子载波比特 × 空间流 × 编码率 ÷ 符号时间 # data_sc: 去掉导频、DC 和保护带后的数据子载波数 # bits_per_sc: 每个子载波携带的比特（1024-QAM 是 10，256-QAM 是 8） def he_peak_mbps(data_sc, bits_per_sc, nss, coding, symbol_us=12.8, gi_us=0.8): bits_per_symbol = data_sc * bits_per_sc * nss * coding # 单位是 bit/µs，数值上恰好等于 Mbps return bits_per_symbol / (symbol_us + gi_us) main_5g = he_peak_mbps(data_sc=980, bits_per_sc=10, nss=2, coding=5/6) # HE80，1024-QAM，2 流 aux_2g = he_peak_mbps(data_sc=234, bits_per_sc=8, nss=2, coding=5/6) # HE20，256-QAM，2 流 print(f"{main_5g:.1f} + {aux_2g:.1f} = {main_5g + aux_2g:.1f} Mbps") # 输出：1201.0 + 229.4 = 1430.4 Mbps

跑出来的 1430.4 和 datasheet 上的 1430 对得上，误差出在四舍五入。参数含义值得逐个扣一遍：980 是 HE80 在 996 个子载波里扣掉导频、DC 和保护带之后的净数据子载波数；234 是 HE20 对应的数字；coding=5/6 是 MCS11（1024-QAM）和 MCS9（256-QAM）用的编码率；0.8 µs 是短 GI。把 GI 改成 1.6 µs，主核立刻掉到 1129 Mbps，这就是为什么实际抓包看到的速率永远比标称低一截。

2.3 天线不会变成四副：射频前端才是 RSDB 的真实成本

两个 2×2 加起来是 4 条空间流，但 datasheet 的框图里射频前端（PAs、LNAs、Switches）是作为一个整体模块画的，天线数量由板级设计决定，不由芯片决定。常见的实现思路是：手机和平板这类产品用两副天线加双工器，2.4 GHz 和 5 GHz 共用辐射体，靠开关切换；只有在空间和成本都宽松的场景才给两频段各配一副。

这意味着 RSDB 的收益不在"吞吐叠加"，而在"延迟可控"。当主核在 5 GHz 上做大包传输时，辅核还能在 2.4 GHz 上应答 beacon、跑 ARP、维持一条后台连接，不需要等主核的 TXOP 结束。用户体验上的差别是"微信不会因为下载大文件而延迟"，而不是"下载速度翻倍"。

真正的代价体现在三个地方：射频开关的插入损耗要吃掉 0.5～1 dB 的链路预算；两个频段同时发射时的互调产物需要靠滤波器和天线隔离度压住，否则 2.4 GHz 的二次谐波会直接盖住 5 GHz 的接收；还有功耗——两套 PHY 同时供电，静态电流不便宜，所以 RSDB 在固件里是可以关的，省电模式下会退化成单频。这就是参数表背后的取舍，评估方案时只看 1430 这个数字会很容易翻车。

3. 零等待 DFS：把静默期挪到后台去

3.1 一次信道切换为什么能让整屋设备掉线

5 GHz 有一部分信道属于 DFS 信道，用之前必须先做信道可用性检查（CAC）：在一段时间内安静监听，确认没有雷达脉冲，才能开始发射。传统实现是串行的——发现当前信道被占用或者收到切换通告，先停业务，再静默监听，监听通过再切过去。整个过程对用户来说就是断网几十秒，中间所有 TCP 连接都会因为超时而重连。

零等待 DFS 想解决的就是这段空窗。datasheet 的措辞很克制：background channel availability check (CAC) scan for immediate switch to candidate DFS channel。关键词是 background 和 immediate——CAC 在后台做完了，切换就是一次射频重配置，不需要再等静默期。对一颗同时承载语音和视频的 combo 芯片来说，这不是锦上添花，是能不能上某些市场的门槛。

3.2 后台 CAC 的状态机：候选信道是一份有寿命的缓存

把 CAC 结果当缓存来管，是最容易想清楚的模型。候选信道不是"查一次记一辈子"，它有过期时间，也可能被雷达事件作废，所以需要一个显式状态机，而不是一个布尔标志位。

/* 示意结构：把候选信道的 CAC 结果当成有寿命的缓存来管理 */ enum cac_state { CAC_IDLE, CAC_SCANNING, CAC_READY, CAC_EXPIRED }; struct dfs_candidate { uint16_t chan; /* 候选信道号，必须和最终切换目标一致 */ uint8_t bw; /* 20/40/80，带宽变了要重新算 CAC */ enum cac_state st; /* 状态机：IDLE -> SCANNING -> READY -> EXPIRED */ uint32_t cac_ms; /* 已累计的静默监听时长，够了才能进 READY */ uint32_t stamp_ms; /* 进入 READY 的时间戳，用于判过期 */ uint8_t radar_hit; /* 监听期间是否命中雷达脉冲，命中即作废 */ };

字段的设计意图比代码本身重要。bw单独存一份，是因为 80 MHz 候选信道的 CAC 覆盖范围包含它的子信道，但反过来不成立——用 20 MHz 的 CAC 结果去开 80 MHz，逻辑上是错的。cac_ms必须是累计值而不是标志位，因为后台监听的窗口是碎片化的，它需要跨多个空闲间隙累加，固件里通常还要处理"这次累计的片段是否连续"的判定。stamp_ms决定缓存寿命，超过有效期就要退回 SCANNING 重新监听，否则就会拿着过期结论做切换，切过去撞上雷达，代价是整条链路被强制迁走。radar_hit是最容易被忘的一个：监听期间只要命中一次雷达脉冲，同信道的所有缓存结果都要作废。

这里的物理约束没法绕过：这颗芯片的 5 GHz 射频只有一套，后台监听必然要和业务抢时间片。常见的实现思路是在主核的 TXOP 空隙、省电窗口、或者业务低峰期插入短暂的离信道监听，把 60 秒的静默需求摊到很多个小窗口里。窗口够不够密，直接决定"零等待"成不成立——业务满载时后台 CAC 收敛得慢，这是机制层面的必然，不是固件写得烂。

3.3 切换决策：缓存什么时候作废、失败怎么回退

零等待 DFS 的价值在切换那一刻兑现，所以决策逻辑要写得能兜住失败。切换不是"选了信道就跳"，它至少涉及三个前置条件：候选信道的 CAC 是 READY 且未过期、当前链路已经收到明确的切换通告、射频前端已经预置好对应频段的功率表。任何一条不满足，都应该走慢速路径而不是硬切，硬切的后果是切过去发现信道不可用，再切回来时两边的 CAC 都要重做。

失败回退的设计要点是保留旧信道的上下文。真实的实现里，切换过程会短暂保留原信道的 BSS 信息和密钥，只有在目标信道上成功发出第一个数据帧之后才释放；如果目标信道在若干次重传后仍然没有 ACK，就回退到原信道并重新走 CAC。这套"后悔药"机制在 datasheet 里不会写，但任何做过 DFS 客户端的人都会告诉你，没有它，一次雷达误检就能让设备卡死。

注意：零等待 DFS 的收益与并发业务量强相关。评估方案时要在满吞吐和空闲两种状态下分别测切换耗时，只测空闲状态得到的数字没有参考价值。

4. PCIe Gen2 与 1600 KB SRAM：主机接口和固件怎么分工

4.1 规范是 3.0、速率是 Gen2：这句看似矛盾的话在说什么

datasheet 里那句 PCIe mode complies with PCI Express base specification revision 3.0 for ×1 lane and power management running at Gen2 speeds，第一次读会觉得别扭：到底是 3.0 还是 Gen2？答案是两者都对，因为"规范版本"和"链路速率"是两层东西。规范版本决定的是协议层能力——配置空间布局、电源管理语义、中断机制、错误上报；链路速率由 SerDes 决定，这颗芯片训练在 5 GT/s。

把 5 GT/s 换算成可用带宽：PCIe Gen2 用 8b/10b 编码，20% 的开销，单 lane 有效速率约 4 Gbps，也就是 500 MB/s。对比 1200 Mbps 的 WLAN 峰值（约 150 MB/s）再加蓝牙的带宽，余量留得很足。选 PCIe 而不是 SDIO 或 USB，动机主要在延迟和 CPU 占用：SDIO 的中断处理要主机侧参与更多，PCIe 用 DMA 加 MSI 中断，数据从芯片到主机的路径上 CPU 几乎不介入。代价是引脚多、板级布线要求高、电源管理更复杂。

电源管理这一层值得单独说。链路空闲时进入 L1，功耗降下来，但 L1 状态下链路不能主动发起事务。这就引出一个硬件层面的必然设计：边带唤醒信号。

4.2 内存地图：1600 KB SRAM 和 1216 KB ROM 各自装什么

框图上的存储分得很清楚，WLAN 侧是 1600 KB SRAM 加 1216 KB ROM，蓝牙侧是 704 KB SRAM 加 1152 KB ROM，另外标了 WLAN RAM Sharing 和 BT Access——蓝牙在有需要的时候可以借 WLAN 侧的 SRAM。

两个核用的是 Cortex-R4 这一类实时内核，WLAN 侧还要承担 2×2 MU-MIMO 和 OFDMA 的调度运算，这是 SRAM 给到 1600 KB 的直接原因——MU-MIMO 的预编码矩阵、每个 RU 的队列状态、每个用户的速率反馈都要常驻。ROM 的容量说明固件主体是掩膜固化的，用 Mask ROM 而不是外部 flash，省掉一颗器件和对应的引脚，代价是现场不能直接改，必须靠补丁机制。

这就带出一个工程上必须提前想清楚的问题：补丁往哪放。datasheet 提到支持 serial flash 接口，实际产品里通常是"ROM 里的固件 + flash 里的补丁 + 主机下载的运行时补丁"三层结构，flash 只在需要持久保存补丁时才焊。评估方案时要问清楚补丁的下载顺序和失败恢复策略，否则量产之后发现某个补丁必须在 BT 启动前加载，现场是没法补救的。

4.3 OTP 的 1406 字节：板级参数的最后一公里

1406 字节的用户可访问 OTP，512 字节分给蓝牙、894 字节分给 WLAN，用来存板级参数。这个分配比例透露了信息量：WLAN 侧的校准项目更多，每信道的发射功率表、晶振负载电容校准值、天线路径损耗、PA 的偏置点，都是逐板逐信道测出来的。

/* 板级参数在 OTP 里的典型分区（用户区共 1406 字节） */ #define OTP_BT_BASE 0 #define OTP_BT_LEN 512 /* BT：MAC 地址、XTAL 校准、功率表 */ #define OTP_WLAN_BASE 512 #define OTP_WLAN_LEN 894 /* WLAN：MAC 地址、每信道功率、路径损耗 */ /* 每个分区头部放 magic + version + CRC，读失败就回退默认值 */ struct otp_block_hdr { uint32_t magic; /* 用于区分"没烧过"和"烧了但内容错" */ uint16_t version; /* 结构体布局变了要升版本，不能原地覆盖 */ uint16_t crc16; /* 整块校验，OTP 是不可改写的，只能靠校验兜底 */ };

magic 和 CRC 的组合不是形式主义。OTP 烧一次就回不去，产线上出现半个块烧坏、或者烧录程序中途断电，是真实会发生的。固件读 OTP 时如果校验不过，必须能退回到一组安全的默认参数继续启动，而不是直接挂死——挂死意味着整机返修，回落意味着这批板子的射频指标差一点但还能用。这个取舍在 datasheet 里不会明说，但任何做过产线的人都会做同样的选择。

894 字节的 WLAN 区还要装每信道的功率表。80 MHz 带宽下 5 GHz 有几十个信道组合，如果每个组合都存一组完整的功率值，光这一项就能吃掉大半个区。常见的做法是按信道号索引加分段线性插值，只存关键锚点，中间值由固件算出来，这样既省空间又能覆盖温度和信道差异。

4.4 边带唤醒：为什么必须有 WL_HOST_WAKE 这根线

框图里单独画了 WL_HOST_WAKE、WL_DEV_WAKE、BT_HOST_WAKE、BT_DEV_WAKE 四根线，它们和 PCIe、UART 是分开的。原因就是 4.1 提到的那个矛盾：链路进 L1 之后不能发起事务，可芯片在 L1 状态下依然要保持关联、要收 beacon、要在收到组播时判断要不要叫醒主机。这个判断结果没法通过 PCIe 事务送给主机，只能拉一根 GPIO。

方向也要分清：HOST_WAKE 是芯片叫醒主机，DEV_WAKE 是主机叫醒芯片。前者用于有下行数据到达、蓝牙来电这类场景，后者用于主机从睡眠恢复后通知芯片准备收数据。两根线都接反或者漏接的板子，表现是"休眠之后收不到推送"，而日志里一切正常——因为芯片侧确实收到了包，也拉了唤醒线，只是主机没配成边沿触发。

注意：边带唤醒的极性、触发沿、上拉电阻位置，在不同平台上要求不一样，datasheet 的信号描述章节会给出电平定义，但具体配置要和主机侧的 GPIO 控制器对上，这部分必须在硬件设计评审阶段确认。

5. 联调排查：这颗 SoC 最容易翻车的五个地方

5.1 速率对不上：先怀疑射频，再怀疑协议

现象：实验室里用 iperf 跑单流，5 GHz 只能到 400～500 Mbps，抓包看 MCS 长期停在 7 以下，偶尔冒到 9 又掉回去。

原因：最常见的是射频链路预算不够。板上射频走线的插入损耗、双工器的带内波动、天线匹配没调好，都会把 EVM 顶上去，速率自适应算法就会一路降阶。另一个高频原因是 OTP 里的每信道功率表没有烧，固件用默认值发射，功率偏低，对端也降阶。

解决：先用传导测试（拆掉天线，接衰减器直连综测仪）确认芯片出口的 EVM 和功率达标，把板级损耗单独测出来。传导达标而整机不达标，问题一定在天线到芯片这段；传导也不达标，回头查 OTP 校准和参考时钟相噪。

5.2 起不来与连不上：时序、枚举和 HCI 流控

现象 A：上电后主机侧 lspci 看不到设备，或者偶尔能识别但链路训练到 Gen1。原因：PCIe 的复位时序没守住。PERST# 释放的前提是参考时钟已经稳定若干微秒，很多板子用同一个电源给时钟芯片和 SoC 供电，上电斜率不一致就会踩到这个坑。解决：按 datasheet 的复位与启动时序章节核对 WL_REG_ON、BT_REG_ON、PERST#、参考时钟的先后关系，必要时加延时，不要指望"上电就好"。

现象 B：蓝牙能配对，但传文件或者 A2DP 播放时断断续续。原因：HCI 用的高速 4 线 UART 没有开硬件流控，主机侧缓冲满了之后只能丢包，表现为周期性的重传和音频卡顿。解决：确认 RTS/CTS 已经接上并在驱动里使能，同时核对波特率和 UART 时钟源的误差——4 线 UART 跑高速时对时钟精度是有要求的。

5.3 校准与低功耗：OTP、LPO 和唤醒丢失

现象 A：一批板子的 MAC 地址全是 FF:FF:FF:FF:FF:FF，或者两台设备的地址一样。原因：产线烧录 OTP 时校验位没写，固件读出来校验失败回落到默认值。解决：烧录工位必须做回读校验，并且把地址分配记录和烧录日志绑定，这个问题在现场无法修，只能返厂。

现象 B：设备进休眠后，蓝牙从唤醒到重连的延迟忽长忽短。原因：32.768 kHz 低频时钟的精度不够。datasheet 里专门留了外部 32.768 kHz 低功耗振荡器接口，用内部 RC 代替外部晶振能省成本，但 RC 的温漂会让低功耗定时器的误差累积。解决：对唤醒时延敏感的产品老老实实加外部 LPO，用内部时钟的方案要把温漂算进协议层的容忍窗口里。

现象 C：休眠后 Wi-Fi 收不到推送，唤醒后一堆数据集中到达。原因：边带唤醒信号的触发沿或者极性配反了，芯片拉了线但主机没响应。解决：用示波器同时抓 WL_HOST_WAKE 和 PCIe 的 REFCLK，确认唤醒发生在链路恢复之前而不是之后。

6. 取舍：为什么把两张网塞进 6.2 mm × 6.1 mm

651 球的 WLCSP 封装，6.225 mm × 6.130 mm，0.2 mm 球间距，这是把 Wi-Fi 6 双频和蓝牙 5.0 塞进一颗芯片之后必然要付的账。球间距 0.2 mm 意味着 PCB 要用到更细的线宽和更小的过孔，扇出层数上去了，板厂的工艺窗口也窄了。选这个封装不是为了炫技，是因为移动设备的主板空间只给了这么多，方案商没有第二个选项。

回头看这颗芯片的几个关键取舍，逻辑其实是一致的：用集成换面积，用面积换成本，然后把不可集成的部分推到板级。

这些选择里最值得琢磨的是 2.4 GHz 那一行。参数表上它不好看，但真实网络里 2.4 GHz 从来不是吞吐的主力，它的价值是覆盖和兼容。把有限的面积和功耗预算从 2.4 GHz 的带宽上挪走，投到 5 GHz 的 1024-QAM 和双核并行上，是典型的"按实际使用分布做设计"而不是"按参数表做设计"。判断一颗 combo 芯片好不好，先看它的资源分配和你产品的流量分布是否同构，再看峰值数字。

验证这些取舍是否成立，我一般会做三组交叉测量：单核基线（关掉 RSDB，只跑 5 GHz，确认能到 1200 Mbps 附近）、并发基线（5 GHz 跑满吞吐的同时 2.4 GHz 跑 ping，看 RTT 抖动而不是看总吞吐）、功耗基线（分别测单频空闲、双频空闲、单频满载、双频满载四个点）。四组功耗数字拉出来的曲线，比任何 datasheet 上的典型值都更能说明这颗芯片在你的产品里能不能用。

从那以后我每次拿到一颗 combo 芯片的 datasheet，都会先把框图里的射频前端和电源时序标出来，再回头看参数表——因为参数是结果，框图和时序才是原因，而踩过的坑基本都埋在原因那一层。希望帮到你。

本文还有配套的精品资源，点击获取