There are a number of special issues to consider when benchmarking the SA-110. These are clock speed, clock switching, cache configuration, and cycle types.

For the SA-110, the speed of the core and (related) memory speed are set with entries in the file 'armul.cnf' in the SDT \bin directory. Any 'Clock Speed' value entered in ADW (under Options->Configure Debugger) is currently ignored by the StrongARMulator (we intend to improve this in a future release).

Look for references to 'CCCFG' (core clock config) and 'MCCFG' (memory clock config) in armul.cnf.  There is another parameter in 'armul.cnf' called 'Time_Scale_Factor'. To obtain meaningful profiling results within a reasonable time, the StrongARMulator allows you to divide what would be the real core clock frequency by a factor. This 'slows down' StrongARM to get more emulated time per real time.

Example for 200MHz core clock and 50MHz memory clock, time scaled by 1000:

CCCFG=9
MCCFG=2
Time_Scale_Factor=1000

Remember that to get realistic figures for the SA-110, you must also enable the cache and enable clock switching. See  and Application Note 51, ARMulator Cache Models in the ARM Application Notes.

When ARMulating the SA-110, the results you will get from $statistics show the activity for each cycle type on the bus interface between the SA-110 and external memory. Note that these are CYCLE TYPES, not MEMORY ACCESSES. The number of 'non-sequential memory accesses' (between the StrongARM core and the cache) is not visible, therefore, even though the code may contain branches, the number of non-sequential cycles shown is zero.

Page 32 of the SA-110 Technical Reference Manual explains:

"There are two cycle types performed by the SA-110. These are idle cycles and sequential cycles. Idle and sequential cycles are combined to form memory accesses.... There are two types of memory access. These are sequential and non-sequential.... Non-sequential accesses consist of an idle cycle followed by a sequential cycle. Sequential accesses consist simply of a sequential cycle."

Alternatively, if you want information about the memory accesses between the StrongARM core and the cache, configure the ARMulator for StrongARM. However, for the StrongARM core, the headings 'S, N, I & C' for cycle counts take on different meanings than for other ARM processors. For the StrongARM model:

• S means both Instruction and Data cache accesses (within the same cycle)
• N means Instructions cache access (only)
• I means Idle cycles
• C means Data cache access (only)
• F means Fast clock cycles (but these are not counted by pre-SDT 2.50 ARMulator)