嵌入式软件中的Mips计算

Question

我最近（并且反复）被客户问及运行我们软件所需的MIPS。通常，我们可以通过向客户解释这取决于CPU/OS/HW（我们的软件高度可移植）和/或用例（即如何使用我们的软件）来摆脱这些问题。

但是，有一个客户非常固执，并且提供了充分的理由来支持他的固执。 :) 他想要一个估计值，因为他不确定他是否拥有足够的功率来运行我们的软件，因此在获得此估计之前购买该软件是不合逻辑的。（我们无法提供演示/评估，因为它将需要大量工作才能在此特定平台上运行。）

现在的问题是：有人有任何硬件上的任何软件任务的经验吗？任何真实的生活例子都将非常有帮助。我有在许多操作系统和许多硬件上运行我们的软件的选项。因此，如果您知道任何硬件上的这种估计工具，则有机会我可以使用它或至少获得一个想法。目前我只知道如何在eCosPro OS上测量CPU负载。

使用探针实际上是一个不错的想法，假设我可以创建一个控制环境，在这个环境中只有我的软件运行，所有指令都是我的，我猜测探针有一个接口可以做到这一点。实际上我有几个不同的硬件调试器，如果有人有经验怎么做这个将会非常好，无论如何，明天我打算阅读一些文档，希望能在这个方向上找到一些东西。

- Ilya

Answer 1

好的，你意识到这里充满了免责声明和警告 - CPU 速度、内存速度、缓存命中率、MMU 页面表刷新、总线争用等等（如果是重型嵌入式系统）都对决策产生重大影响。

话虽如此...我会这样做。获取一个实时操作系统（请跟紧我），比如 FreeRTOS（免费，惊喜吧）或 u/C-OS-II（商业使用不免费，可能需要3K美元）。这些内核允许你对代码进行仪表化处理以计算空闲 CPU 周期（空闲任务自旋循环）。

因此，在你们商定的板上（例如MPC860板、ARM7板等）运行整个应用程序（或客户的应用程序）作为唯一的（非空闲）任务。通过实时操作系统测量板上的% CPU（例如，“在60 MHz运行的 Flibber 板上，我们的应用程序使用了12％的CPU。”）

如果没有更多信息或反之亦然，这听起来就像是为他们付出相当合理的努力。

好处是，一旦你做到了这一点，你可以为其他目标和/或板复用这项工作，也许这些数字将帮助你增加销售和/或调整/优化你的软件。

祝你好运！

- Dan

---

这似乎是一个合理的近似值。 - Paul Nathan

这是我计划在阅读JesperE的帖子之前要采取的方法。尽管CPU使用率对我来说似乎更相关，但客户需要MIPS，我将尝试从ICE中获取MIPS信息。 - Ilya

Ilya - 抱歉，我没有完全“闭合循环” - 假设在60 MHz下，你的CPU提供了大约50 MIPS...所以如果你的程序使用了CPU的10％（90％处于空闲状态），那么它大约使用了50 MIPS的10％= 5 MIPS。 - Dan

当然，我理解这个。对我来说，探测方法似乎更通用，例如，如果我能找到从Lauterbach获取MIPS信息的方法，那么在任何具有ICE接口的平台上，我都可以获取MIPS信息，而无需在每个操作系统上进行额外的编码（而且我们支持大量的操作系统）。 - Ilya

Answer 2

您是否有可以提供指令数量的模拟器或调试探针？甚至不需要在正确的目标平台上执行，只需大致计算指令数量即可。

如果其他方法都失败了，请在您可以访问的任何平台上运行它，并使用您-MHz/客户-MHz商的比例来缩放运行时间。这应该可以给您一个非常粗略的估计客户将体验到的运行时间。

- JesperE

---

很棒的想法，你知道有没有任何探针可以实现它吗？在我的平台上进行估算将会满足客户的需求。 - Ilya

很不幸，我没有使用不同的调试器探针的太多经验，只有大致了解它们可以做什么。 - JesperE

无论如何，谢谢你。我会在得到结果后在这里发布 :) - Ilya

Answer 3

RapiTime声称可以为您的目标提供最坏情况执行时间的概率估计。我个人没有使用过它，但见过他们的演示……

如果您的目标与客户的目标足够相似，您可能可以将其扩展到估算其平台上的WCET。然后，他们可以将其与当前系统的“备用”时间进行比较。

- Martin Thompson

Answer 4

I/S是一个对于带有操作系统的系统来说比较“弱”的度量标准。

在具体实施中，你需要：

1. 找出最坏情况下的指令路径，并计算执行所需的周期数（这意味着需要阅读该CPU的汇编代码并查看CPU手册以获取周期数）。
2. 现在确定你的实时约束条件。
3. 然后使用#1作为最坏情况下的周期数。将CPU向上/向下调整，直到符合实时约束条件。
4. 添加一个调整因素。

- Paul Nathan

---

这是一条非常漫长的路... :) 这个软件相当庞大且复杂。 - Ilya

Answer 5

你需要做的第一件事是制定某种正确操作标准。这将在很大程度上取决于应用程序的性质——你的标准可能包括“必须在3ms内执行代码x”或“延迟必须低于100ms”。任何与量化测量无关的标准都会很难，因为它们是主观的。

找到正确操作的标准将允许您找到关键部分的代码。请记住，这些关键代码可能出现在边缘情况而不是正常操作中。

如果这些关键代码很少，则针对目标平台计数指令将相对容易。如果你有一个模拟器，那可能会更容易。（根据代码的不同，你可能需要进行模拟以确保其得到执行，但如果你有大量要分析的代码，这仍然比计算指令要容易）

如果你的关键代码很多，则可能需要采用类似JesperE建议的方法。除非你的应用程序面向极端注重价格的行业，否则客户很可能愿意在计算上接受一点松懈——所以最好高估而不是低估你的CPU需求。

我与JesperE的建议不同之处在于，建议不要集中关注MHz，而是关注目标的实际MIPS。例如，在测试平台上编译和执行代码-如果您有分析器，那可能更好。然后将您的代码编译为客户端的目标，并粗略比较结果可执行文件中指令的数量。然后，您可以将此比率与测试和目标处理器的相对MIPS一起纳入执行时间计算中。

- Andrew Edgecombe

Answer 6

你说你的软件高度可移植，所以我的建议是在处理器架构、处理器指令集和内存/外设总线类型最接近的平台上运行软件。测量最长的实时例程，然后估计它在他们的体系结构上运行的时间。

- geometrikal

---

问题是如何衡量...测量的想法突然闪过我的脑海 :) - Ilya

1. 当您进入和退出关键例程时，切换引脚。使用引脚上的作用域来测量时间。
2. 将编译器设置为输出汇编文件，并计算每个例程的代码行数，以粗略猜测指令数量。

- geometrikal

这并不是一件容易的事情，我的代码库比平均嵌入式操作系统的代码库还要大。仅仅找到最长的例程是不够的，更恰当的做法是找到最长的执行路径，但从技术上讲这有点困难。 - Ilya

Answer 7

大多数现代调试器都可以让你查看已使用的指令，例如RVDS。此外，您可以使用处理器仿真器来获得有关指令使用情况的良好想法，而无需在平台上实际运行（如果您的代码是独立的，例如编解码器或加密模块，并且不依赖于板子）-请注意，这将为您提供指令，而不是周期。周期将受到您的板子详细信息的影响（例如等待状态、内存访问等）。

- axe

Answer 8

在我使用的两种处理器架构（MSP430F5X和AVR32）中，处理器内置了硬件周期计数寄存器。通常情况下，当处理器不忙时，我会将其置于低功耗空闲状态，并停止处理器核心。然后有两种选项来计算实际的处理器负载。我可以在定期计时器函数中设置断点并读取执行的处理器周期数，或者通过在操作开始和结束时读取此寄存器来检测特定进程。由于CPU在处理器空闲时间时处于停止状态，因此处理器空闲时间不会出现在周期计数中。

您没有指定处理器架构，但这种功能可能存在。

- uɐɪ