Posted on October 11, 2012 at 17:19 At least it should mention instruction timing is available from ARM.
Kind of think that's the obvious place to start, but I've been doing this too long to be objective.
At least several versions of the reference manuals do refer to ''Related documents'' in the preface that direct you to ARM, some other to ST specific representations
RM0008, Rev 6
Available from
www.arm.com: ■ Cortex™-M3 Technical Reference Manual
RM0008, Rev 14
For information on the ARM Cortex™-M3 core, please refer to the STM32F10xxx Cortex™-
M3 programming manual (PM0056).
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/PROGRAMMING_MANUAL/CD00228pdf
RM0090 Rev 1
Available from
www.arm.com: ■ Cortex™-M4F Technical Reference Manual, available from:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0439c/DDI0439C_cortex_m4_r0p1_trm.pdf Your far bigger problem however is accurately modeling the surrounding behaviour of things like the write buffers, caches/ART, branch predictions, prefetch, and interactions with AHB and APB at disparate clocks. Instructions like LDM, STM, MUL and DIV will also impact you, the latter being dependent on the data being processed. Static analysis will give you some useful numbers, but I wouldn't rely on them.
A far better strategy would be to benchmark actual code, under realistic conditions, and to use the core cycle counter in the trace unit of most STM32 devices. This would give a much better feel for the internal interactions, and a lot cheaper than having a timing accurate model of the chip.
https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=20293&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Run code in SRAM in ASM
