Furber S.ARM system-on-chip architecture.2000

Abort recovery

Multiplier

Instruction cache

Data cache

Synonyms

It might seem that one of these paths could be avoided if the ALU result were written into the register file in the following stage rather than buffering it and delaying the write to the last stage. The merit of the delayed scheme is that data aborts can occur during the data cache access, perhaps requiring remedial action to recover the base register value (for instance when the base register is overwritten in a load multiple sequence before the fault is generated). This scheme not only allows recovery but supports the cleanest recovery mechanism, leaving the base register value as it was at the start of the instruction and removing the need for the exception handler to undo any auto-indexing.

A feature of particular note is the StrongARM's multiplication unit which, despite the processor's high clock rate, computes at the rate of 12 bits per cycle, giving the product of two 32-bit operands in one to three clock cycles. The high-speed multiplier gives StrongARM considerable potential in applications which require significant digital signal processing performance.

The I-cache holds 16 Kbytes of instructions in 512 lines of eight instructions (32 bytes). The cache is 32-way associative (using a CAM-RAM organization) with a cyclic replacement algorithm and uses the processor's virtual address. The block size is the same as the line size, so whole lines are loaded from memory at a time. Individual areas of memory may be marked as cacheable or uncacheable using the memory management tables, and the cache may be disabled and flushed (in its entirety) under software control.

The data cache uses a similar organization to the instruction cache but with added functions to cope with data stores (instructions are read-only). It has a capacity of 16 Kbytes with 512 32-byte lines arranged as a 32-way virtually addressed associative cache with cyclic replacement. The block size is also 32 bytes. The cache may be disabled by software and individual regions of memory may be made uncacheable. (Making I/O regions uncacheable is usually a good idea.)

The data cache uses a copy-back write strategy, and has two dirty bits per line so that when a line is evicted from the cache all, half or none of it is written to memory. The use of two dirty bits rather than one reduces memory traffic since the 'half dirty' case is quite common. The cache stores a copy of the physical address with each line for use when the line is written back to memory, and evicted lines are placed into the write buffer.

Since the cache uses a copy-back write strategy, it is sometimes necessary to cause all dirty lines to be written back to memory. On StrongARM this is achieved using software to load new data into every line, causing dirty lines to be evicted.

As with any virtually addressed cache, care must be taken to ensure that all cacheable physical memory locations have unique virtual addresses that map to them. When two different virtual addresses map to the same physical location the virtual addresses are synonyms; where synonyms exist, neither virtual address should be cacheable.

Cache consistency

Compiler issues

The write buffer

The separate instruction and data caches create the potential for the two caches to have inconsistent copies of the same physical memory location. Whenever a region of memory is treated as (writeable) data at one time and as executable instructions at another, great care must be taken to avoid inconsistencies.

A common example of this situation is when a program is loaded (or copied from one memory location to another) and then executed. During the load phase the program is treated as data and passes through the data cache. When it is executed it is loaded into the instruction cache (which may have copies of previous instructions from the same addresses). To ensure correct operation:

1.The load phase should be completed.

2.The entire data cache should be 'cleaned' (by loading new data into every line as described above) or, where the addresses of the affected cache lines are known, these lines may be explicitly cleaned and flushed.

3.The instruction cache should be flushed (to remove obsolete instructions).

Alternative solutions might involve making certain regions of memory uncacheable during the load phase.

Note that this is not a problem for literals (data items included in the instruction stream) which are quite common in ARM code. Although a block of memory may be loaded into both caches since it contains a mixture of instructions and literals, so long as individual words (or bytes) are treated consistently as either instructions or data, there will be no problem. It is even acceptable for the program to change the value of a literal (though this is rarely used and is probably bad practice) so long as it does not affect the values of instructions which may be in the instruction cache. It is better practice, however, to avoid literals altogether and to keep data in data areas that are separate from code areas which contain instructions.

The separation of the instruction and data caches should be observed by the compiler, which should pool constants across compiler units rather than placing them at the end of each routine. This minimizes the pollution of the data cache with instructions and of the instruction cache with data.

The write buffer smooths out small peaks in the write data bandwidth, decoupling the processor from stalls caused by the memory bus saturating. A large peak that causes the buffer to fill will stall the processor. Independent writes to the same 16-byte area are merged within the write buffer, though only to the last address written into the buffer. The buffer stores up to eight addresses (each address aligned to a 16-byte boundary), copying the virtual address for use when merging writes and the physical address to address the external memory, and up to 16 bytes of data for each address (so each address can handle a dirty half-line or up to four registers from a single store multiple).

336

ARM920T write buffer

ARM920T MMU

ARM CPU Cores

Figure 12.11 ARM920T organization.

for translation, but of course there is no guarantee that the necessary translation entry is still in the TLB. The whole process can therefore be quite time consuming. The ARM920T avoids this problem by having a second tag store that is used to hold the physical address for each line in the cache. A cache line flush does not then need to involve the MMU and can always proceed without delay to transfer the dirty data to the write buffer.

The ARM920T can force dirty cache lines to be flushed back to main memory (a process known as 'cleaning') using either the cache index or the memory address. It is therefore possible to clean all of the entries corresponding to a particular memory area.

The write buffer will hold up to four addresses and 16 data words.

The MMU implements the memory management architecture described in Section 11.6 on page 302 and is controlled by the system control coprocessor,

Memory protection unit

ARM940T caches

The memory protection unit implements the architecture described in Section 11.4 on page 297. As the ARM940T has separate instruction and data memory ports it has two protection units, one for each of the ports.

This configuration has no virtual to physical address translation mechanism. Many embedded systems do not require address translation, and as a full MMU requires significant silicon area, its omission when it is not required represents a significant cost saving. The AMBA interface and absence of address translation hardware both indicate the expectation that the application will be in embedded systems with other AMBA macrocells on the same chip.

Both instruction and data caches have a size of 4 Kbytes and comprise four 1 Kbyte segments, each of which uses a fully associative CAM-RAM structure. (For an explanation of these cache terms see Section 10.3 on page 272.) They have a quad-word line structure, and always load a complete line on a cache miss if the address is cacheable as indicated by the memory protection unit.