[参考译文] SK-AM64：TMDS64EVM -支持 AM64x 的 A53 CPU 上的 ICSSG 以太网驱动程序

尊敬的 Erik Wolfner：

感谢您的提问。

您计划在 AM64x-SK 电路板上运行 Linux 或 FreeRTOS 的操作系统？

此致

阿什瓦尼

我假设您正在考虑使用的是 A53 FreeRTOS Linux_Drivers 驱动程序，而如今使用 Linux 的 A53支持 ICSSG https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components / PRU-ICSS/ICSS/ PRU_ICSSG_Ethernet.html 。 请注意、Linux A53驱动程序使用 IO 缓存一致性(ASEL 14、15)。

虽然没有硬件限制、但是我们目前还没有计划对 ICSSG 提供 A53 FreeRTOS 支持。 现在支持 Linux 吗？

您是否有自己的电路板设计？ 您是否已经和现场应用工程师的 TI 销售人员合作过？ MCU+ SDK 和带 AM64x 的 ICSSG 的主要测试平台不是 SK-AM64 (主要用于 Linux 开发)，而是 https://www.ti.com/tool/TMDS64EVM 。

 佩卡

使用我们自己的 RTOS。 我已经为我们的操作系统编写了所需的驱动程序移植层、以支持 TI 的软件。 我还可以构建我们的软件以使用 FreeRTOS。

我们已经针对过去使用我们 RTOS 的产品获得了安全认证、这也是使用它的主要原因。  我们使用自己的网络堆栈进行 TCP/IP 通信、并在过去具有安全认证。

我们将在电路板上使用 AM6422、通过三个千兆位以太网端口和一个 SPI 端口与我们的 IO 卡产品进行通信。  该系统在1ms 冗余配置中支持两个或三个 CPU。 采样率。  以太网用于 CPU 间通信以及与主机的通信。

我们在 Raspberry Pi 计算模块4上运行该软件、但我们不相信能够获得所需的技术信息来确保使用 CM4的系统的安全合格。 AM6422有更好的文档记录、我们相信它与 CM4相比具有更好的价格和可用性。

当我们考虑其他解决方案时、问题通常是至少需要三个千兆以太网端口和在以太网上快速端到端通信所需的性能。  我们一直在使用英特尔 PCIe 82576双端口芯片作为以太网解决方案、但由于可用性有限、这很昂贵。  使用 CM4的解决方案需要 Intel 82576芯片除了内置以太网外还能获得两个端口。

我们使用的是 TMDS64EVM 开发板。  我们首先购买了 SK-AM64B、发现它没有用于 PRU 以太网端口的收发器。  我们的应用需要三个以太网端口。  我们设计了自己的电路板、它将三个以太网端口连接到 PRU。  遗憾的是、TMDS64EVM 开发板不支持使用板载收发器的三个 PRU 以太网端口。 我们目前仅使用两个端口进行测试。

在我与我们的 TI FAE 交谈时、他告诉我、TI 希望我们通过 TI 支持站点工作、而不是通过 FAE。  到目前为止、我一直在使用 TI 网站上的资源。

我很惊讶地发现 SDK 不支持从 A53 CPU 直接使用以太网。  另一个惊喜是、SDK 不支持直接访问同一 R5F CPU 上的 ICSW 和 ICSSG 以太网驱动程序。  我们决定、在其他一些额外的 R5F CPU 内核上实现 ICSSG 所需的额外"扔掉"代码不值得花时间。

最重要的电流问题是从 A53 CPU 到 R5F CPU 到以太网/从以太网的端到端通信延迟。  我正在尝试找到一种方法来减少这种延迟。  系统每1MS 发送三条小型以太网消息并接收三条小型以太网消息、以保持冗余 CPU 同步。  Raspberry Pi 计算模块4和英特尔82576以太网的整个交换过程耗时不到300微秒。  在 AM64x 上、同一消息交换大约需要500微秒。  这会将可用于计算的处理时间减少20%。

我正在努力寻找一种方法来减少这种时间。  我的第一个想法是将 ICSSG 以太网驱动程序放在 A53 CPU 上。  我排除了使用 R5F 上的以太网驱动程序在 A53上进行 DMA 传输的想法、因为没有简单的方法可以区分这两者。

我目前正在设计一个实现方案、它将使用 A53 CPU 直接访问 DMA 缓冲区、还执行高速缓存管理。  R5F CPU 仍将启动 DMA 并处理 DMA 完成。  但是、R5F 不会访问 DMA 缓冲区中的数据、也不会对这些缓冲区进行任何高速缓存管理。 这样可能会缩短所需的时间。

3以太网帧的500us 似乎很高。 有几个想法要优化、您是否使用 R5的 TCM 存储器、并从那里复制到 A53 (缓存 DDR)？ 或替代建议、因为这是您自己的 RTOS、只需将帧位于位置 X 的通知发送给 A53

对于任何 ICSSG 以太网开发  ，请使用 www.ti.com/.../TMDS64EVM，而不是 SK 板。

有关安全相关的详细信息，请单击此处复制的产品页面上的请求链接 https://www.ti.com/licreg/docs/swlicexportcontrol.tsp?form_id=225507∏_no=AM64x_RESTRICTED_DOCS_SAFETY&ref_url=EP %3EProc%3ESitara 。

 佩卡

Pekka、

很抱歉、我花了这么长的时间来回复。

我修改了应用程序、以便 A53 CPU 将数据存储在 DMA 缓冲区中、并从 DMA 缓冲区读取数据。  A53 CPU 还会执行必要的高速缓存操作。  R5F 执行所有以太网驱动程序调用、包括那些启动 DMA 并检查完成的调用。 我们的软件在每个缓冲区的句段列表中设置"disableCacheOps"标志。  发送三条消息和接收三条响应所需的时间减少了约200微秒。  这使我们更接近目标。

我发现、如果我尝试同时将多个数据包排队、则数据包被丢弃。  我在一个单独的线程中报告了该问题。  当我使用一个单独的队列来单独提交每个数据包时、数据包就会被正确传输。  我不清楚通过同时提交多个数据包可以节省多少时间。 我们的应用最多可以同时向四个不同的目标地址发送四个数据包。

我希望能进一步缩短时间、但我唯一的想法是将以太网驱动程序完全移植到 A53 CPU。  我担心的是、由于 CPU 速度更快、这可能会出现问题。  我在尽快发送多个数据包时已经遇到了问题。

我们的电路板硬件设计已经完成、并且我们正在制造一些原型板。  该电路板基于 TI 的 AM6422参考设计。  它有三个千兆以太网端口连接到 PRU。  我们使用的是 ICSSG 双 Mac 驱动程序。  我们将使用 SD 卡进行引导和数据存储。  一个 SPI 控制器用于与其他电路板上的 IO 设备进行通信。

我们的应用依赖于通过以太网端口进行的高性能通信、以支持 CPU 冗余和分布式 IO。  每个节点都会发送其 SPI 接口采集的数据和 CPU 间数据以实现冗余。  例如、主机发送到冗余 CPU 的每个命令也会转发到其他 CPU。  CPU 相互发送计算结果以比较结果。  CPU 对哪些数据正确进行投票，并关闭产生错误结果的 CPU。

过去、我们一直使用英特尔 CPU 和英特尔82576 PCIe 双端口以太网芯片。  比我们需要的更多以太网性能并且价格昂贵。  从82576升级的路径需要为一些新芯片编写一个新的以太网驱动程序。

Raspberry Pi 计算模块4 (CM4)具有比我们需要的更高的计算性能、但仅有一个以太网端口。  我们使用了英特尔82576来获得另外两个以太网端口。  由于82576芯片的供应有限、这不是最佳选择。  CM4的可用性和价格也不一致。  但是、CM4的主要问题是硬件大部分缺少文档。  我们计划使用此产品的安全合格版本，该版本比基于英特尔的旧产品更具成本效益。

TI 的 AM64x 是最能满足我们实际要求的解决方案。  具有三个内置以太网端口使其极具吸引力、因为它无需使用英特尔82576芯片和 PCIe 驱动程序。  A53 CPU 的单核与 Raspberry Pi CM4的单核性能大致相同。  我们的应用仅需要两个内核、我们发现 R5F 具有足够的性能来为其中一个内核运行软件、而另一个软件需要 A53。  CM4比 AM6422消耗更多电能并产生更多热量、我们甚至不会在 CM4上使用图形处理器。

使用 AM6422面临的挑战与以太网软件有关。  在 A53上运行的软件可生成和处理大多数以太网帧、并运行我们的 TCP/IP 网络堆栈。 我们的以太网驱动程序在同一个 A53 CPU 上运行、因为它还处理向其他 CPU 内核和网络冗余决策的消息分发。  我们仅将以太网的 TI 驱动程序相关部分移至第二个 R5F 内核。

剩余的挑战是如何满足以太网通信的性能要求。  在相同的配置下、TMDS64EVM 比 Raspberry Pi 花费大约200微秒的时间即可每毫秒完成一次处理。  我仍需要验证200微秒是由以太网通信引起的、以及为什么会发生这种情况。

您是否仍在为自己的驱动器寻找 TI 的进一步支持？ 我们目前没有计划基于 A53的裸机以太网驱动程序、因此我们支持 R5驱动程序。

我仍在问、如果我们将 ICSSG 双 MAC 以太网驱动程序移植到 A53、TI 是否愿意提供支持。  这也将包括对 TMDS64EVM 上的 PHY 的支持。  TI 的支持将解答有关 SDK 软件和 AM64x 硬件详细信息的技术问题。  为了实现我们的性能目标、也许有必要将驱动器移植到 A53。  我通过在与第一个 A53 CPU 内核并行的第二个 A53 CPU 内核上进行计算、获得了一些性能改进。

我们可支持 Enet LLD 接口级别 https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/enetlld_top.html (请注意、9.0 SDK 将在明天9月8日更新为基于 ICSSG 的以太网示例)。 将中断路由到 GIC 可能是与 R5的主要区别、UDMA https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/DRIVERS_UDMA_PAGE.html PktDMA 是 ICSSG Enet LLD 使用的、因此应该从那里得到。

除了此级别之外、我还需要一些业务人员来安排额外工作的优先顺序、您是否已经接触过 TI 销售和/或 FAE？ 如果没有、我将通过电子邮件与您联系、以获得一些项目背景。