This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RVDS3.1 page table option for profiling

RaghavendraPrasad RaghavendraPrasad over 12 years ago

Note: This was originally posted on 29th July 2009 at http://forums.arm.com

Hi all,
I'm using Realview3.1 Debugger connected to ARM1176JZFS core. I want to know the total no of cycles for my code. when I 'm connectiong the debugger with "Default page table" option enabled, the cycles that I got from cycle count register is less than the cycle count that I got without enabling the "Default page table" option. I don't know whether to enable thr option for calculating the total cycles. Can any one help in this regard. Thanks in advance.

Thanks & Regards,
M. Raghavendra

RaghavendraPrasad RaghavendraPrasad over 12 years ago

Note: This was originally posted on 30th July 2009 at http://forums.arm.com

The default page table option starts the simulator with the MMU (or MPU) pre-enabled. It saves you writing your own MMU/MPU initialization code, which is useful for quick tests. It is the MMU/MPU which controls what is cacheable, so having these pre-enabled can have a big impact on performance.

Thanks for ur reply. But I want to know whether which cycle count need to be taken(enabled or not enabled). When I'm taking the cycle count with the option enabled I get less no of cycles than the option disabled. Which cycle count I need to consider.

Thanks & Regards,
Raghavendra
Cancel
Vote up 0 Vote down

Cancel
Peter Harris over 12 years ago

Note: This was originally posted on 30th July 2009 at http://forums.arm.com

You might also want to look at enabling branch prediction - which can be configured in the CP15 control registers - it is disabled by default.
Cancel
Vote up 0 Vote down

Cancel
Martin Weidmann over 12 years ago

Note: This was originally posted on 30th July 2009 at http://forums.arm.com

The default page table option starts the simulator with the MMU (or MPU) pre-enabled. It saves you writing your own MMU/MPU initialization code, which is useful for quick tests. It is the MMU/MPU which controls what is cacheable, so having these pre-enabled can have a big impact on performance.
Cancel
Vote up 0 Vote down

Cancel
Martin Weidmann over 12 years ago

Note: This was originally posted on 30th July 2009 at http://forums.arm.com

Well that would depend on whether you want the cached or uncached performance of the code. For an 1176 I would expect that caches enabled is the more normal case.
Cancel
Vote up 0 Vote down

Cancel