Calculation of Mips for Embedded Software

Question

I recently (and repeatedly) asked clients about MIPS needed to run our software. Usually we could get rid of these issues by explaining to the client that it really depends on the processor / os / hw (our software is very portable) and / or usage (for example, how our software is used).

But I have the latter, not only very stubborn, but also gives good reason to be stubborn. :) He wants to evaluate, because he is not sure that he has enough strength to run our software, so buy software collateral before this assessment is not logical. (We can’t provide a demo / rating, since this particular platform will require significant work).

And now the question arises: does anyone have experience with this task on any part of hw with any software? Any real life example would be really helpful. I have the opportunity to run our software on many operating systems and many hardware. Therefore, if you know any tool for such an assessment on any equipment, there is a chance that I can use it or at least get an idea. For know that I only know how to measure processor load on eCosPro OS .

Edit:

Using a probe is actually a good idea, assuming that I can create a control environment in which only my software works, all that I can calculate is mine, and I assume that the probe has an interface for this. Actually, I have several different hardware debuggers, and if anyone has experience how to do this, it will be really good, I will read the documentation tomorrow and hopefully find something in this direction.

Answer 1

OK, you understand that this is fraught with failures and warnings - processor speeds, memory speeds, cache hits, page flushes of MMU pages, etc. (if it is a powerful embedded system), all factors are significantly in the decision ....

Having said that .... what I would do is. Get a real-time operating system (stay with me), maybe something like FreeRTOS (free, what a surprise) or u / C-OS-II (not free for commercial use, maybe $ 3). These cores allow you to use the code to count the processor’s idle cycles (idle rotation cycle).

Thus, run the entire application (or the client application) as the only (not idle) task on the board that you agree to (for example, the MPC860 card, ARM7 card, etc.). Measure% CPU on the board via RTOS. (for example, "on a Flibber board operating at 60 MHz, our application used 12% of the CPU.")

Without them giving you more, or vice versa, it sounds like a pretty reasonable length to go to them.

It’s good that once you do this, you can reuse the work for other purposes and / or boards, perhaps the numbers will help you increase sales and / or adjust / optimize your software.

Good luck

Answer 2

Do you have a simulator or debugger probe that can give you a command count? You don’t even need to do this for the correct target platform, just do a rough count of the teams.

If all else fails, run it on any platform that you have access to, scale the execution time with the frequency coefficient of your MHz / customer-MHz. This should give you a rough estimate of what the client will experience.

Answer 3

I / S is a weak metric for a system with an operating system.

In nitty-gritty you need to do

• determine the worst-case path and calculate how many cycles are required to execute (this means reading the assembly for this CPU and viewing the processor manual, which indicates the number of cycles).
• Now find out your limitations in real time.
• Then you use # 1 for the worst cycles. Adjust the processor up / down until it meets the real-time constraints.
• Add leaching factor.

Answer 4

The first thing you need to do is come up with some kind of criteria for proper operation. This will greatly depend on the nature of the application - your criteria may include "must execute code x in 3 ms" or "must have a delay below 100 ms." Any criterion that does not relate to quantitative measurement will be difficult because it will be subjective.

Finding your criteria for proper operation will allow you to find critical pieces of code. Keep in mind that they can be found in corner cases, and not in normal operation.

If these critical pieces of code are small, then the counting commands for your target platform will be relatively straightforward. If you have a simulator that could be even easier. (depending on the code, you may need to make a layout to make sure that it runs, but it will probably be even easier than counting instructions if you have a large piece of code for analysis)

If your critical code is large, you may need to do something similar to JesperE's suggestion. If your application is not aimed at an incredibly price-sensitive industry, it is likely that the client will want to accept a slight deviation in the calculations - it’s better to evaluate than when evaluating your processor requirements.

In cases where I would be different from the JesperE proposal, I suggest not focusing on the MHz, but rather on the actual MIPS targets. For example, compile and execute your code on a test platform - if you have a profiler that can be better. Then compile your code for the client’s target and perform a rough comparison of the number of instructions in the resulting executable. You can then incorporate this ratio along with the relative MIPS of the test and target processors in the calculation of the runtime.

Answer 5

You say that your software is very portable, so my suggestion was to run the software on a platform that is closest to the processor architecture, processor instruction set and type of memory / peripheral bus. Measure the longest procedure to be performed in real time, and then evaluate how long it will work in your architecture.

Answer 6

Most modern day debuggers give you the ability to view the instructions given, for example; RVDS. In addition, you can use processor emulators to get a decent idea of ​​the instructions consumed without actually running on the platform (if your code is autonomous, for example, a codec or cryptographic module and does not depend on it) - note that this will give you instructions, not cycles. The cycles will be affected by the details of your board (for example, standby states, memory access, etc.).

Answer 7

On the two processor architectures that I use (MSP430F5X and AVR32), a hardware cycle counter is built into the processor. I usually have a scheme where, when the processor is not busy, it is put into a low-power standby state with the processor core stopped. Then there are two possibilities for calculating the actual processor load. I can either set a breakpoint in the function of the periodic timer, or read the number of processor cycles completed, or I can process certain processes by reading this register at the beginning and at the end of their work. The processor idle time is not displayed in the cycle counter because the CPU is stopped for this time.

You do not specify your processor architecture, but this feature may be present.

Answer 8

RapiTime claims to provide a probabilistic estimate of the worst-case execution time for your purpose. I did not use it personally, but I saw their presentations ...

If your goal is similar enough to your client, you can probably scale it to evaluate WCET on your platform. They can then compare this to the “spare” time that their current system has.