[参考译文] TMS320TCI6614：AIF2快速 CNM 勘误表权变措施

您好！

很抱歉耽误你的回答。
我已通知雷达团队。

此致、
Yordan

我们有一个更新：

我们创建了一个 DSP 可执行文件、用于在出口时以32位计数发送数据包。  代码的入口侧会检查计数并更新错过的序列计数器或正确的序列计数。  DSP 代码发送一个前导码55's 和一个5D。
我们将 DSP 置于串行器/解串器环回4b5b 编码中、并正确接收到100%的数据包。

然后、我们在 Xilinx CPRI 内核之后的 RRH 中执行了回送。
在这种情况下、DSP 发送的每4个数据包中、我们损失了大约3个数据包。  此外、在本例中、我们看到的是802.1兼容以太网数据包的前导码为 Seven 55和 A D5。

然后、我们在 RRH FPGA 中创建了一个数据包发生器。  
发电机只有6 55个。  
然后、我们能够获得100%的数据包通过。

我们对此感到有些惊讶。  我们的理解是：

DSP 出口 -> 6 55 -> AIF2 (附加 SSD)-> SSD + 6 55 -> Xilinx Core Rx (用55替换 SSD)-> 7 55 ->
-> Xilinx Core Tx (用 SSD 替换55)-> SSD + 6 55 -> AIF2入口(移除 SSD)-> 6 55至 DSP 存储器
如果是这种情况、则我们的数据包发生器应该不起作用、因为只有 SSD + 5 55进入 AIF2。  您能不能对此有所说明？

谢谢、

Bryan

您可以忽略先前关于55的帖子。  我们被骗以为有五个。  另一个进程将55添加回原来的数据包、因此所发送的数据包应该具有755 x。

但我们还有其他一些重要的发现：

我们现在能够监听从 RRH 到 DSP 的 CPRI 流量。  我们从未看到任何表明数据包在 DSP AIF2中被丢弃的坏或缺失数据包。

此外、我们还测量了与 bfn_strobe (CPRI 帧 stobe 的开头)相关的偏移。  我们有一个 FPGA 构建、在重置 RRH CPRI 内核后、会获得100%或0%的数据包丢失。  我们还注意到、这个构建具有一个来自 bfn_strobe 的固定偏移、此偏移在 RRH CPRI 内核复位后发生改变。

我们有另一个构建、它始终会丢失约50%的数据包。  我们注意到该构建中的数据包在两个偏移之间跳过。  一个偏移量具有良好的数据包、另一个偏移量具有不良数据包。

我们有另一个构建、在 bfn_strobe 之后向数据包发送可编程数量的时钟。  我们看到、计数器偏移会影响接收到的数据包。  有时、我们将获得50%的数据包、有时我们将获得0%的数据包、有时我们将获得更低的数据包损耗。  这也是非常可预测的。  特定的计数值将始终提供相同的结果。  

同样、对于这些构建中的每个构建、通过 CPRI 传输的数据包看起来都很好。

这是否与 AIF2配置相关？  我看到了以下部分：

注意到：在 AIF2规范中：

7.3.4.2符号对齐

所有使用8b10b 编码数据的标准都采用了基于 K28逗号符号的符号对齐。将 ALIGN 设置为01将启用基于逗号符号的接收数据流对齐。 b 但是、一旦收到一定数量的对齐逗号、通过将 align 设置为00来禁用逗号检测是正常的。  SYNC 表示已接收到对齐的逗号。 如果位错误将另一个符号更改为逗号、则可以防止意外的领域。 通常、需要每个接收器通道的小型硬件状态机来控制对齐。 确切的对齐协议取决于所使用的标准。

这是：

SD_auto_align_en -一位

使 RM 能够在接收器状态机达到 ST3状态时自动禁用串行器/解串器符号对齐。 在 OBSAI 模式下可能需要禁用逗号对齐、因为 K28.7逗号字符与某些数据组合在一起会诱使 SerDes 进行错误的重新对齐。

•0：禁用自动对齐

•1：启用自动对齐

这些线索是否能说明发生了什么情况？

谢谢、

Bryan

我们非常确定问题是 AIF2未检测到与 CPRI 控制字边界不对齐的数据包。  在本例中、控制字为40位(3G 速率)。

我们从 DSP 和 RRH 捕获了数据包、并看到了以下对齐方式：

对齐方式如下所示、其中最右边的零是数据包的第一个位。 从右向左读取的数据包。

 

DSP：

0110101110110110110110101010101011011000100

偏移量=40

右侧

主题1.

 

数据包1

10110001001111111111111111111111111111111111111111111111

偏移量=10

数据包2

0001001111111111111111111111111111111111111111111111111111

偏移= 6

 

要求 CPRI 控制字对齐、而不是 CPRI 规范、因此 AIF2不符合要求。

 

请注意：我们认为 AIF2会检测其他对齐方式、因为即使我们认为控制字未对齐、我们也会看到20%的数据包经过。  我们无法固定对齐有效的点。

 

请告知 AIF2可以检测控制字内任何位置的数据包。  

一些背景：我们有一些 FPGA 测试构建、可以在特定时间发送预封装数据包。
有时，这些编译会在 AIF2所喜欢的时间发送，有时甚至不发送。
‘，Xilinx CPRI 内核需要随机重置次数，才能使其进入“良好”模式。
‘再次通过实验尝试强制在“正常”时间发送数据包。
但是、这不是一种长期解决方案。

问题是我们
没有位级时序控制。
Xilinx CPRI 内核(它是加密 IP)执行位级计时。
作为一种长期解决方案、我们正在与 Xilinx 合作、让它们进行对齐。
但是、这可能需要几个月的时间、因为他们的优先级高于制定
其 IP 块的非规格兼容解决方案。

我们希望 TI 提供：

1) 验证数据包是否必须对齐以及如何对齐。
根据我们的实验、似乎需要进行对齐、但如果 TI 能够做到这一点、将会很有帮助
验证情况是否如此。 此外、必须如何对齐数据包。
我们发现、有时它们不需要40位对齐、其他偏移将起作用。
我们正在努力与 Xilinx 合作进行对齐、但我们不知道
是否可以解决100%的问题。 我们需要完全了解 SOC 是什么
以便我们可以描述 Xilinx 的修复。

2) 是否有任何其他变通办法或配置允许 SOC 以4b5b 模式接受非对齐数据包？
这显然是最佳情况解决方案。

谢谢

我回去看了我的笔记-我们上次谈论的是2015年12月和2016年1月。 我的记忆从那时起就已经消失了... 这是否有效、现在是否有效、或者在这段时间内是否未进行过处理？

据我所知、任何偏离 CPRI 4.2协议规范的情况都已记录在器件勘误表中。 快速 C&M 处理是其中之一、但它没有提到任何特殊的对齐要求。 其他客户实施了控制字、但没有抱怨对齐问题。

在我看来、令我有点困惑的是、初始帖子提到如果您从4b5b 切换到空定界、则不会丢失任何数据包。 您是否还切换了在 Xilinx 中运行的固件？ 我认为在使用空定界符时，每当遇到空定界符字符时，就会遇到数据包分段的问题。

此时、我们需要找到一个有效的快速解决方案。 您是否考虑使用空定界符、或可能使用您提到的其他偏移？

此外，您能否发送以下信息：

1) 1)您配置的 LTE 速率是多少？
2) 2) AIF2的链路速率是多少？