ARM Cortex-A8 instruction timings

For various reasons, I have been investigating instruction scheduling on ARM's new-ish Cortex-A8 processor. The main public source of information on this is the Cortex-A8 TRM - at the time of writing, the latest release is r3p2, dated 07 May 2010. As previously established on the comp.sys.arm newsgroup (thread 1) (thread 2), the TRM description appears to be not only lacking much important information, but also to be quite wrong about much that it does describe.

I resolved to try to work out the correct timing tables experimentally, using the TI OMAP3530 ES3.0 chip on my revision B7 beagleboard as a reference. Because I'm a generous soul, I've decided to publish these for others to refer to. Needless to say, this is not official information from ARM, may contain errors, and ARM is free to change the chip's behaviour at any time - but hopefully it's useful anyway. Just don't hold your breath waiting for me to test all the VFP instructions as well!

In the tables below, opcodes are divided into timing classes, described using a modified regexp syntax which matches all opcodes in the class (as well as sometimes some nonexistent ones). Optional matches are indicated by {}. For these purposes, do not use UAL's inferred-Rd notation (e.g. ADD r0,r1 instead of ADD r0,r0,r1).

Registers are listed in the order in which they appear in the class description - note this differs from the Cortex-A8 TRM, so for example Rd will normally be listed first. I find this easier to follow, and I don't have to keep checking whether Rm comes before or after Rn for each particular instruction.

Notation for timings is based on ARM's syntax:

• [] on a source means it is needed if the instruction is conditional
• [] on a result means it is output if the instruction is a flag-setting variant
• () on a result means it is output if the instruction uses writeback

Where a register is only present in some instructions in a given class (e.g. accumulator variants of multiplies, or registers which may be substituted with an immediate constant), I list timings for all possible registers. Which columns of the table are not applicable for particular instructions from that class should be unambiguous from the opcode class description, so I haven't used {} here where ARM do.

Processor flags (NZCV and GE[3:0]) act as a single item, and are listed under the "flags" column. The Q flag appears to be handled separately, and is never responsible for stalls.

As in the TRM, source timings are given relative to the first cycle of an instruction, and (apart from LDM and STM) result timings are relative to the last cycle.

When PC is used as a source and/or destination register, you can treat it as though it is always required and/or produced in E1 (or any other fixed number), overriding the timings below.

Scheduling is done statically - that is, allowing sufficient time to be be able to handle each input register and flag having any possible value.

To reiterate and expand upon the TRM's description of the hazards:

• Load/store resource hazard: only one load/store can be performed per cycle, though it can be in either pipeline. This applies to CLREX, LDM, LDR, PLD, STM and STR, but not SWP.
• Multiply resource hazard: multiplies (including the single-cycle ones and USAD) cannot be issued to pipeline 1.
• Branch resource hazard: this is a special case of the data source hazard, when you consider that the branch instructions have PC as an input and output.
• Data output hazard: instructions with the same output register(s) cannot be issued in the same cycle. As a special case, this does not apply to the flags, so two flag-setting instructions can be dual-issued.
• Data source hazard: sufficient stalls will be inserted before an instruction in order that by the time it reaches the pipeline stage at which it requires a given register, the preceding instruction that output to that same register has progressed beyond the pipeline stage at which it output it.
• Multi-cycle instruction hazard: if an instruction takes more than one cycle, it cannot be issued to pipeline 1. Pipeline 1 cannot be used again until the last cycle of the instruction, and in some rare cases described below, not until the cycle after.

I have dropped the "E" prefixes from pipeline stages in the tables. This is because in multi-cycle instructions, it is impossible to distinguish empirically between (say) whether a register is needed by E2 in the first cycle or by E1 in the second cycle - nor is this an important distinction for scheduling. By breaking the direct link to pipeline stage, I can refer to numbers outside the range 1-5, which is useful sometimes.

"shift" is a shorthand for (LSL|LSR|ASR|ROR).