This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] [参考译文] [FAQ] Sitara 多核系统设计:如何确保在设定的周期时间内进行计算?

Guru**** 633810 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1085663/faq-sitara-multicore-system-design-how-to-ensure-computations-occur-within-a-set-cycle-time

部件号:AM6442
“线程:测试”中讨论的其它部件

我正在设计带有 Sitara 多核设备的系统(例如,AM24x,AM64x,AM65x)。 处理器需要在设定的周期内完成某些活动。 如何设计系统以确保我可以满足该周期时间?

“周期时间” 是系统接收输入,执行某些处理和提供输出的最大允许时间。 例如,电动机控制应用程序可能有10微秒的周期时间来测量电动机的角度和速度,进行一些数学运算,然后更新控制电动机的 PWM 输出。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    简介

    讨论内容是对基本概念的一般性介绍。 TI 无法提供系统设计方面的全面培训。 您是使用案例的专家。 如有疑问,请尝试在互联网上搜索更多信息。

    不同的系统可以针对不同的使用情况进行优化:数据吞吐量,最坏情况下的延迟和平均延迟都是需要考虑的因素。 需要高吞吐量数据的用例可能不关心最坏情况的延迟等。

    本次讨论的重点是需要短周期时间(即10秒到100秒微秒(美国))的使用酶。 这意味着需要对系统进行优化以减少最坏情况的延迟。

    什么因素会导致循环时间?

    如果单个处理器内核可以完成所有工作,那么完成计算周期所需的时间就会出现
    输入到达处理器-->检测输入的时间--> 处理发生-->输出从芯片发送到目的地的时间

    如果控制环路中有多个内核,则还必须考虑处理器间通信(IPC)延迟。 在上述流程中,“处理发生”可能会扩展到类似的内容
    酷睿1处理-->至酷睿2的 IPC 延迟-->酷睿2处理-->至酷睿1的 IPC 延迟-->等等

    短周期时间反过来又需要低延迟 IPC。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    RTOS /裸机内核

    实时操作系统(RTOS)以“实时”(实际上意味着“已知,确定性时间”)执行任务。 周期较短的设计通常希望使用运行 RTOS 或裸机(即无操作系统)的内核。

    AM24x R5F,M4F
    AM64x R5F,M4F,A53

    截至 SDK 8.2,AM64x MCU+ SDK 将 A53 FreeRTOS 和 A53 NORTOS 列为实验功能。 这意味着 TI 不支持 AM64x A53上的 FreeRTOS 和 NORTOS (https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_28/exports/docs/api_guide_am64x/RELEASE_NOTES_08_02_00_PAGE.html#autotoc_md37 )。 因此,本次讨论将重点关注其他核心。

    AM24x,AM642x,AM644x 设备上存在 R5F 内核。

    M4F 内核存在于所有 AM24x 和 AM64x 设备上。 从 SDK 8.1开始,TI 支持 M4F 内核的通用开发,并支持从 Linux 加载 M4F 内核。 使用 IPC Notify (https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_01_00_36/exports/docs/api_guide_am64x/DRIVERS_IPC_NOTIFY_PAGE.html )时,从任何 R5F/M4F 到任何其他 R5F/M4F 的平均单向延迟小于2us。

    AM65x R5F,A53

    R5F 和 A53均支持 AM65x RTOS SDK。

    AM24x PRU_ICSSG
    AM64x PRU_ICSSG
    AM65x PRU_ICSSG

    ICSSG 内核运行裸机软件,并且物理上接近 PRU GPI / GPO 引脚。 这使得 ICSSG 核心成为快速进出处理器的信号收发的理想选择。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Linux 内核

    Linux 是 一个高级操作系统(HLOS)。 它比 RTOS 更复杂。 虽然 Linux 是许多用户(例如,人机交互(HMI))的理想设计选择,但操作系统的复杂性意味着完成任务所需的时间可能比 RTOS 长。 此外,Linux 完成任务所需的时间可能会有所不同(即,Linux 不是确定性的)。

    通常,我们不建议在处理链中使用 Linux 内核来控制周期较短的循环。 例如,AM64x 电机控制应用程序可能只在电机控制环路中使用 PRU_ICSSG 和 R5F 内核,然后使用 Linux 在控制环路外更新 HMI。 这是因为如果电机控制计算延迟,导致系统错过周期时间, 则可能会发生故障。 相比之下,如果用户的触摸屏延迟0.5毫秒更新,则不会出现任何问题。

    但是,如果设计绝对需要 Linux 内核进入控制循环,该怎么办?

    使用 RT Linux  

    如果 Linux 核心必须处于控制循环中,请使用 RT Linux 代替常规 Linux。 RT Linux 已被修改为比常规 Linux 更实时。 但是,RT Linux 不是真正的 RTOS! 完成流程所需的时间比预期的要长,但边缘案例可能仍然存在,边缘案例将会减少。 RT Linux 无法保证时间安排得到满足。

    客户需要严格测试 RT Linux,以确保它在长期测试中满足他们的使用要求。 这些测试可以证明边缘案例在统计上不可能发生。 但是,观察 RT Linux 不太可能错过时间并不等同于保证它永远不会错过时间。

    了解 系统的中断响应时间  

    在大多数情况下,当 Linux 参与控制循环时,我们需要注意中断响应时间。

    当我们了解向 Linux 核心发送邮箱或中断的延迟时,情况如下:
    RTOS/裸机内核写入邮箱或中断-->邮箱或中断通过处理器传输的信号延迟--> >中断响应时间(Linux 接收中断,到达当前任务的停止点,上下文切换以存储当前任务的数据,并切换至中断处理程序)

    即使 Linux 内核定期轮询更新而不是等待中断,中断响应时间也会影响系统。 假设我们有一个高优先级的 Linux 应用程序,每250个用户就会对远程核心数据进行轮询。 (例如 ,https://www.ti.com/tool/TIDA-01555。 Linux 代码位于 https://git.ti.com/cgit/apps/tida01555/tree/ARM_User_Space_App/arm_user_space_app.c)。 两轮投票之间的时间实际上略多于250人。 这是因为计时受到中断响应时间的影响:
    nanosleep 启动后台计时器,应用程序休眠--> Linux 切换到另一个线程--> 250 us 后计时器中断关闭-->中断响应时间--> Linux 返回到用户空间应用程序

    好的,因此中断响应时间 会导致 IPC 延迟。 您的系统需要计划哪种中断响应时间?

    Linux 非常复杂,无法创建预测中断响应时间的理论模型。 确定系统中断响应时间的最佳方法是生成一个与您的设计类似的 Linux 版本,然后运行测试以试验性地确定预期的延迟。 Cyclictest 提供了一个良好的起点。 例如,AM64x SDK 8.1的开箱即用周期测试结果如下: https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_01_00_39/exports/docs/devices/AM64X/RT_Linux_Performance_Guide.html#maximum-latency-under-different-use-cases 。

    对于 AM64x Linux SDK 8.1,观察到的 RT Linux 核心最坏情况中断响应时间为72 us。 如果我正在对系统进行原型设计,并将其作为最坏的结果,那么我的控制环路设计需要考虑这一中断响应时间。

    关于自行车测试的其他注意事项:
    * SDK 编号的延迟以微秒为单位(美国)
    *性能指南测试使用 create_cgroup 将尽可能多的任务从 RT 核心移到非 RT 核心。 但是,有些 Linux 任务不会从一个核心转移到另一个核心。 这些任务可以在最坏情况下的最晚延迟中继续发挥作用
    *您可以在 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1033771/am6442-latency-in-linux-rt-is-well-above-expected-values/3835092#3835092上找到有关运行周期测试的其他讨论 
    *不同的 Linux 版本具有不同的线程,这些线程会导致不同的最大延迟。 一种选择是从最小版本开始(例如,在 AM64x Linux SDK 的 filesystem/下找到的小文件系统),查看周期测试结果,然后了解当您在系统中添加其他所需的 Linux 功能时,延迟的变化情况。 设计需要在实时任务的需求与   更广泛的系统所需的系统呼叫和服务之间找到折中方案。

    我可以绕过中断响应时间吗?

    以下想法是假设性的。 TI 尚未对其进行测试,我们不一定会推荐它们。 这只是为了帮助客户考虑他们的选择。

    如果 A53内核不断从内存位置读取,则没有中断响应时间。 从 R5F 内核通知 Linux 内核的总延迟降至

    R5F 写入内存位置--> A53 Linux 从内存位置读取延迟

    有可能吗?

    一种方法是执行两阶段通知:使用中断,RPMsg 或更长的轮询时间告知 Linux 内核何时需要开始监视低延迟消息。 一旦 Linux 知道即将出现低延迟消息,Linux 就会不断读取内存位置,而不允许任何其他线程在 Linux 内核上运行,直到 R5F 写入发生。

    AM64x A53内核为双核。 因此,另一个选项是隔离 A53内核,并将一个内核专用于读取内存位置,直至收到消息。 此选项的缺点是,所有其他 Linux 应用程序的计算能力将减半。  

    但是,系统设计人员需要记住其他一些挑战。 对于两阶段通知选项,恒定内存读取需要有超时机制,以确保 Linux 不会启动所有其他线程。 如果线程在低延迟通知发生前超时,该怎么办? 然后,Linux 内核可能会在 Linux 内核未及时响应 R5F 内核通知的情况下发生边缘情况。

    即使我们将核心专用于读取共享内存位置,也会出现问题。 如果您将线程优先级设置得足够高,则可以阻止大多数其他线程在 Linux 内核上运行...除了射计时器(在我们有限的实验中)。 当射计时器控制时,用户空间应用程序的读取时间不是很长,中断响应时间需要-->射计时器应用程序-->上下文切换回用户空间应用程序。 如果在射线计时器处于控制状态时发送通知,则这是另一种边缘情况,系统可能无法满足周期时间要求。