跑4层接收的测试例时，发现怎么调SNR，最后都全错，而小于4层接收就没问题。百度了很多次，总算发现了一个bug，而且据说是OAI官方在2024年就发现此bug了，但为啥我用的2.4.0版本（2025年）没有纠正这个bug，奇怪。。。百度描述的bug如下：
在 #if defined(__aarch64__) && defined(USE_NEON) 分支中，Layer 2 (tx2) 和 Layer 3 (tx3) 的数据源完全错了。它们重复读取了 Layer 0 和 Layer 1 的数据，导致第 3、4 层接收到的全是错误数据（实际上是第 1、2 层的副本或错位数据），这直接解释了为什么 4 层接收会全部解错。
1. 错误分析
请看这段有问题的 NEON 代码：
c
#if defined(__aarch64__) && defined(USE_NEON)
// SIMDe doesn't handle this properly, gcc up to 14.2 neither
for (; i < (n_symbs & ~3); i += 4) {
uint32x4_t d4 = *(uint32x4_t *)(mod + i); // 加载 mod[i], mod[i+1], mod[i+2], mod[i+3]
*(uint32_t *)tx0 = vgetq_lane_u32(d4, 0); // tx0 取 mod[i] (正确: Layer 0)
tx0++;
*(uint32_t *)tx1 = vgetq_lane_u32(d4, 1); // tx1 取 mod[i+1] (正确: Layer 1)
tx1++;
// --- 错误开始 ---
*(uint32_t *)tx2 = vgetq_lane_u32(d4, 0); // tx2 取 mod[i] (错误! 应该是 mod[i+2])
tx2++;
*(uint32_t *)tx3 = vgetq_lane_u32(d4, 1); // tx3 取 mod[i+1] (错误! 应该是 mod[i+3])
tx3++;
// --- 错误结束 ---
}
#endif
预期行为：将交错存储的 mod 数组解映射到 4 个独立的层数组 tx0-tx3。
tx0 应获取索引 0, 4, 8...
tx1 应获取索引 1, 5, 9...
tx2 应获取索引 2, 6, 10...
tx3 应获取索引 3, 7, 11...
实际行为：
tx2 获取了 mod[i]（即 tx0 的值）。
tx3 获取了 mod[i+1]（即 tx1 的值）。
后果：Layer 2 和 Layer 3 的数据完全被污染。在 4 层 MIMO 解码时，接收机期望 Layer 2 和 3 携带独立的信息流，但实际收到的是 Layer 0 和 1 的重复/错位数据。这会导致信道估计和均衡完全失效，CRC 校验必然失败。
为什么 3 层没问题？
因为 3 层 MIMO 通常不会进入这个 case 4 分支，或者即使进入，如果代码逻辑是 case 3，它可能使用了不同的实现路径（或者标量路径），从而避开了这个特定的 NEON Bug。
2. 修复方案
你需要修改 vgetq_lane_u32 的索引，使其对应正确的数据位置。
修正后的代码：
c
#if defined(__aarch64__) && defined(USE_NEON)
// Fix: Correct lane indices for tx2 and tx3
for (; i < (n_symbs & ~3); i += 4) {
uint32x4_t d4 = *(uint32x4_t *)(mod + i);
*(uint32_t *)tx0 = vgetq_lane_u32(d4, 0); // mod[i]
tx0++;
*(uint32_t *)tx1 = vgetq_lane_u32(d4, 1); // mod[i+1]
tx1++;
*(uint32_t *)tx2 = vgetq_lane_u32(d4, 2); // mod[i+2] <-- 修正: 索引从 0 改为 2
tx2++;
*(uint32_t *)tx3 = vgetq_lane_u32(d4, 3); // mod[i+3] <-- 修正: 索引从 1 改为 3
tx3++;
}
#endif
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。