Gabriele Svelto (gabriele.svelto@gmail.com) on 9/26/09 wrote:
---------------------------
>Skimming through the information available on the Cortex A9 I have noticed that
>there are quite a bit of peculiarities in the design. Here's a quick run-down to fuel discussion:
>
>- Out-of-order completion is mentioned though there is very little information
>about it. The only other mention I found was that an instructions 'releases the
>resources it is consuming early'. Maybe it means that an instruction can write-back
>its result and free the renamed register before completion if it safe to do so?

You can write the result to the register file as soon as it has been computed. It's a big advantage over in-order as you don't have to have to pipeline (and forward) every result to the final writeback stage. This is what you could call OoO completion. If the instruction was not speculated then you could release resources used by that instruction early as you know that it will complete once it starts.

>- It seems that the LSU is skewed as they mention a single-cycle load-to-use penalty
>(same as on the Cortex A8). A hardware prefetcher is also mentioned but there is no information about it.

Single cycle load-use sounds like a special forwarding case. OoO pipelines typically aren't skewed - it doesn't make sense to issue an instruction and do nothing for 1 or 2 cycles when you could issue an independent intruction instead. Unlike in-order, you don't gain anything at all.

>- Some sort of load-store forwarding mechanism is mentioned in the white paper
>though it is not described how it works or what it does exactly. Maybe back-to-back
>load/store couples have a lower latency because the data is allowed to bypass some
>stages and go directly to the store queue?

Historically ldr-str latency has been zero on most ARMs - even mul-str is usually zero latency. The paper suggests ldr-str forwarding happens within the L1. That likely means zero latency and a power saving.

>- The L1s in Cortex A8 were PIPT, I believe this still holds true for the A9. This
>means that the TLB must be fairly small, a potentially significant disadvantage
>in more desktop-oriented workloads. I wonder if there is a second-level TLB in there.

The A8 uses 32-entry fully associative TLB's, but a TLB miss means 2 expensive L2 accesses. The A9 pipeline diagram mentions micro-TLB's, which means they are small (likely 8 to 16 entries) and on a miss use a larger main TLB (like ARM11). I hope the main TLB has at least 128 entries and ideally 256.

>- When configured with an L2 cache, the L2 is exclusive (yay for K7!), certainly
>a good thing for the smaller incarnations of the A9.
>
>- The A9 has fast loop mode for lower-power operation but in the diagrams available
>it is depicted as being before the decode stage. This is similar to Conroe/Penryn
>cores which is strange because it comes after the pre-decode stage, something that
>the A9 shouldn't have. I would have expected it after the decode stage (like on
>Nehalem) so I was wondering if its sole purpose is to shut off the L1 I-cache for power savings.

Doing it after decode would need a lot more area as decoded instructions can be significantly wider than 32 bits. Loops with branches are likely harder to deal with as well. Caching fetched data is easier and works well on Thumb-2 where an average instruction is just 21 bits. L1 fetch is one of the largest power consumers (27% on StrongARM), so avoiding it in most loops helps a lot.

>- Finally it seems that they put a lot of effort into making I/O operations as
>well as thread-related operations very fast. The ACP for example is absolutely brilliant:
>on current consoles it is normal practice to lock part of the L2 to and write the
>GPU command buffer into it, then send it over using DMA to save an unnecessary read-write-read
>copy. Having this done transparently is simply excellent. It seems to me that they've
>done quite some work to make operations which usually disrupt an OoOE actually run
>very fast (peripheral I/O, TLS access and cache-to-cache transfers). On this topic
>I'd like to know more about the GIQ too because interrupt handling is an area which
>is often underestimated from a performance POV.

The ARM11 MPCore TRM may give some insights as to what the A9 will do. MPCore supports global distribution of interrupts as well as handling a specific interrupt on a particular core. You can even send a software interrupt to another core.

Wilco