OMAP3530 memory bus clock verification

I don't have any comments right now about the numbers you have posted.

I was curious to understand from you what your expectations were.  You mentioned the numbers blew through your expectations, but you didn't indicate what those were.
It would be beneficial to understand that as well.  Thank you.

Hi Brandon,

For testMem (10 single loads) I expected 20*10^6 cycles; for every load-operation I expected one instruction fetch and one data fetch.

For testMem2 ('load multiple' of 10 datasets) I originally expected 11*10^6 cycles; one instruction fetch + 10 data fetches for every bus/cpu-tick.

I actually forgot to mention that I execute every loop 10^6 times.

Anyone any comments/ideas?

thanks!

jhoff

I believe the root of this is stemming from the Cortex A8 internal memory architecture, so your answer is likely in ARM documentation as opposed to the OMAP3 TRM. I suspect that this is just a byproduct of the device being designed entirely around having the internal L1 cache enabled, there are significant latencies for accesing L2 cache (minimum 8 cycles) let alone going across the L3 memory interface to another on chip memory like the OCM_RAM. I am not sure how much latency if any is mitigated by disabling the caching, but it seems at least that you have proved one should have the data cache enabled to maintain reasonable performance.

If you want to measure the speed of the OCM_RAM you may be able to do so by using DMA transfers, though I am not sure how this would help if you are going to be dependent on the CPU accessing the data anyway. What is your end goal in this testing, do you have concerns about the OMAP3 meeting your intended system's bandwidth requirements?

Hi Bernie,

thanks for your reply!

Let me explain what the goal behind this exercise is.

Our software has a relative large data exchange with the memory. So the cpu/bus-clock has a relatively big effect on the speed our code runs in the end (next to Cache-sizes).

So I'm setting the bus-clock ... and I wanted to verify that this is correct (That the bus-clock actually ticks at the speed I think it does ...).

How do you determine if the bus-clock is correct, if you can't measure it directly?

That's why I tried to verify the bus-clock in relation the CPU-clock using the assembler commands above, which lead me the results I could not really explain.

jhoff

jhoff said:

How do you determine if the bus-clock is correct, if you can't measure it directly?

Unfortunately I do not know of a way to directly measure the bus clock, you can calculate what it should be based on your input clock and the register values within the device which is what I would typically suggest, though this is not truly proof of the speed. You could run benchmark code like you were trying to do while changing the bus clock to try to perceive the changes to confirm if your clock changes are actually affecting performance, but this would not give an real measurement of the clock, just that it is there.

In the case of using the Linux drivers to modify the system frequency you can measure the voltage that the part is at to determine what the clock frequencies should be, since the driver adjusts both the clock and voltage levels in a series of operating points OPP which are discussed in chapter 10 of the PSP user's guide.

Hi Bernie,

thanks for putting more thought into that.

I calculated the bus clock based on the input clock and register settings (that's how the number in my first post came to life). And I was able to see a dependency of the clock-cycles of the code above, when changing the clock speed.

You can even see a dependency in my very first post. In the examples p3 and p4 I just change the clock-setting and you can see a change in clock-cycles.

Therefore I started trusting my settings :-)

Yet, the question of this large "offset" to the expected values puzzled me.

I don't have a Linux installed at this point in time, since for my profiling purposes "bare-metal" is better.

jhoff