[参考译文] AM6442：添加了运行 Nitika Verma 和 Team 为异构 SoC 提议的 RT/NRT 隧道机制的延迟

尊敬的 Christian：

我很遗憾地通知大家、我们没有测量网桥和共享存储器增加的额外延迟。 我们提供了一种解决方案、可为使用我们 PRU 固件的时间关键型应用单独处理 RT 和 NRT 流量。 这可确保 RT 流量始终与边界保持一致。 我们观察到 从外部主机 PC 到 Linux、再到 Linux 的最大 RTT 约为 4ms。 如果您想获得这些数字、我们可以计划进行一些测试并分享这些结果。

我想了解您计划使用的终端解决方案类型、因此我们可以提供更好的测试方法来反映您的用例。

谢谢。此致、
Teja。

尊敬的 Teja：

感谢您的回答。 计划的解决方案是具有高频循环流量的桥接 TSN 端点。 TSN 周期时间需要与工业以太网协议的当前先进水平相匹配。

EtherCAT 显然支持 12.5us 周期时间（请参阅 www.ethercat.org/.../etg_201202_e.pdf） 、Profinet TSN 达到 31.25us（请参阅 us.profinet.com/.../） 。

如果在 RT 路径内转发所增加的延迟超过允许的容差、则此解决方案不适合我的应用。

NRT 路径不是那么重要,但从我的角度来看仍然有趣。

此致、

基督教

尊敬的 Teja：

据我所知、任何传入的以太网数据包都将通过 ICSSG 路由到 lwip 软件桥。 然后、NRT 数据包向 A 内核发送、而 RT 数据包直接在 RTOS 中处理。 我的应用程序将使用类似的布局、其中只有 NRT 流量路由到不同的处理器。

在任何情况下、所选工业以太网协议的 RT 数据包均由软件网桥处理、然后由 R5 内核复合体中的目标进程进行处理。 这将需要在接收和发送路径中产生额外的延迟。

请纠正我,如果我不可避免地得到一些细节错误。

此致、

基督教

尊敬的 Christian：

对于 ICSSG 示例、软件桥仅放置在 NRT 路径中。 RT 数据包将采用与固件完全不同的路由。 在本文中、我们以 CPSW 为例、它不会区分 RT 和 NRT、并将为所有数据包增加延迟。

如果您的解决方案需要分别处理 RT 和 NRT 流量、我们建议您使用 ICSS 进行实施、并支持 RT 固件。 对于通用用例、我们建议使用 CPSW 将处理大量流量卸载到内核、并以更高的时界灵活性实现确定性流量。

此致、
Teja。

尊敬的 Teja：

如果我正确理解您：您的论文并不是为了展示 RT 数据包的快速处理、而 RT 数据包本应在 ICSSG 内部处理。 而是将它们转发到一个 R5 处理器中、为纸张提供某种形式的 RT 流量。

在我的应用中、RT 数据包的切换和处理应在 ICSSG 本身内处理。 这会非常快、因为这种特殊的硬件将实时处理以太网数据包。 只有 NRT 数据包会转发到 AM64xx 的其中一个 A/ R 处理器。

感谢你的帮助。

此致、

基督教