How to get the approximate MIPS required

I forgot to say, the application spent most of its time in processing the data, and virtually no time spent on UI or others. Thus I conclude the MIPS required to run at PC might be close to the MIPS required to run at ARM.

Thanks.

Johns> I have developed an application with Visual Studio Team System for

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

Very unlikely. There are many other variables - word size, FPU presence, SIMD instructions, etc. The best way to answer this question is to build your algorithm for the targeted ARM core, and run it in a simulator (or on real hardware, with an oscilloscope strobe to determine how much time is spent in algorithm and how much is idle).

I think you are definitely right, and I should build my algorithm for the targeted ARM core. However, I doubt the oscilliscope can tell me the time spent in each function or line. It sounds like a profiler's job.

Do you or anybody here know if there is any low-cost or free profilers available for ARM? As far as I know, the ARM profilers are pretty expensive. RVDS Pro. will cost about $3800 per license per year. RVDS v4.0 Standard will cost about $6K - $8K per license per year.

Is there any tools under $1K?

Thank you.

Johnson

larwe wrote:

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

expensive.

As long as you are looking at popular embedded cores, and have not committed to ARM9, ARM7, ARMCortex, etc. then there are plenty of simulators available. I agree this is the best approach.

There are free simulators for 8, 16 and 32 bit cores on the Renesas website. They come as part of the compiler. 60 days unlimited use is standard. 64k (some have more) at day 61.

--------------------------------------- Posted through

If you *really* want to know the time spent in a section of code or even a single line, I would use an oscilloscope or better, a logic analyzer. I have used a parallel port on a PC to time and trace code using a logic analyzer. It not only tells you where the code is by the value written, it tells you *exactly* when it happens. A code profiler won't be able to predict how code interacts with the real world. It only lets you see how the code runs under your "ideal" conditions of the simulation. Besides, a simulator can be setup incorrectly. If you are setting up the hardware incorrectly, at least it is consistent with the way you will be running the real code!

Rick

Hi Rick,

I agree with you that either oscilliscope or logic analyzer can provide the execution time of a line or a section of code wand tells me what happened in my device. However, I only need the approximate MIPS or execution time of the section of code, not what happened in the real-time.

So I guess there is possibly an easier solution around. Is it OK for me to compile my software under the targeted hardware, say ARM-9, and count the number of instructions and clock cycles in total for the section of code? It might be time-consuming to count the instruction for any section of code, however, if I only cares about a few "hot zone", it might be OK. Do you think it is feasible and worth the try?

Thanks.

Johnson

rickman wrote:

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

I couldn't say how practical it would be. It certainly depends on which processor you plan to use. The same code can be run on a wide range of processor speeds. From your first post I see you are looking for a MIPS requirement. I'm not even sure of how to measure MIPS. I suppose you can treat it literally and use a profiler to count the instructions executed. Then it would be easy to calculate the MIPS. But then I'm sure you understand that.

I think if I were doing it, I would use your 300 MIPS estimate to pick a processor and buy that eval board. Then I would use a hardware method to measure the execution time. 300 MIPS is a pretty high number for the ARM processors. There are a number of top end devices like the ones used in PDAs that will provide this speed. But the ARM7, ARM9 and CMx processors are all well below this speed rating. So you may not have a problem sizing a processor. What is left are all pretty much above 300 MIPS, IIRC. The TI OMAP3 devices are pretty fast and they have a new line - AM35xx and Marvel took over the Intel StrongARM device line which is the top dog I believe. Who else is up in that rare air of >300 MIPS?

Rick

No, I don't recall any other > 300 MIPS. Basically my choice is pretty limited beyond 300MHz, and I understand that. The system engineer also wants to know which platform we should head to. The way my friend described is very very rough, anyway it is better than nothing.

Thanks.

Johns> >> Hi Rick,

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

You aren't asking that. You are asking how many MIPS are being consumed by the algorithm. All you require is a signal that goes high when you are "in algorithm" and low when you are "out of algorithm" and you can determine DIRECTLY from the duty cycle of that signal, and the known total throughput of the CPU, how many MIPS are being consumed by the algorithm. Very common measurement technique.

Maybe I am missing something. I am suggesting that you get an eval board and *test* your algorithm on it. I certainly would not want to pick a processor for such a computationally intensive task by a SWAG such as your friend's method. Just the fact that it uses a comparison between two different processors based on "MIPS" tells me it can be off by a factor of 2 or more in either direction. Check out the wiki page. MIPS is not anything remotely like a standard and it is essentially useless for comparing different processors.

That is why you need to get an eval board of a potential candidate and test your algorithm.

Rick

Dear Mr. Collins,

On Mon, 1 Feb 2010, rickman posted on news:comp.arch.embedded : |----------------------------------------------------------------------| |"[..] | |[..] A code | |profiler won't be able to predict how code interacts with the real | |world. It only lets you see how the code runs under your "ideal" | |conditions of the simulation. Besides, a simulator can be setup | |incorrectly. If you are setting up the hardware incorrectly, at least| |it is consistent with the way you will be running the real code! | | | |Rick" | |----------------------------------------------------------------------|

Precisely.

I have been speeding up and profiling an unembedded program running on an Intel Core2. I was using a fast intrusive profiler but it is not of much use to me. I later used a very slow non-intrusive profiler which uses inaccurate simulations which do not show how long each instruction takes (for example, it shows no difference between an addition and a division, whose true differences are not documented by Intel for processors released in the second half of this decade), which was useful earlier but soon I will want a better proxy for measuring performance. We are considering paying to acquire a non-intrusive profiler provided with Intel VTune, but I am at liberty to investigate other options. I suspect that Intel VTune's non-intrusive profiler would be faster and less inaccurate than the non-intrusive profiler which I have not yet abandoned, but it would probably still be very slow and its model might still not be perfect.

|---------------------------------------------------------------------| |"If you *really* want to know the time spent in a section of code or | |even a single line, I would use an oscilloscope or better, a logic | |analyzer. I have used a parallel port on a PC to time and trace code| |using a logic analyzer. It not only tells you where the code is by | |the value written, it tells you *exactly* when it happens." | |---------------------------------------------------------------------|

I think this could be extremely difficult for analyzing an Intel Core2 (which I am aware was not what you were describing). I mentioned an idea like this to a company which I would have been interested to pay to develop a physical device to perform non-intrusive profiling of an Intel Core2, but who I spoke to was (quite possibly correctly) convinced that an external device cannot determine anything more internal than a cache of a recent Intel product.

Do you want to take the challenge to disprove this and how much will you charge?

Yours sincerely, Colin Paul Gloster in Portugal, telephone 00 351 239410663