Intel® IXP42X product line and IXC1100 control plane processors—Intel XScale® Processor
Intel® IXP42X Product Line of Network Processors and IXC1100 Control Plane Processor
DM September 2006
68 Order Number: 252480-006US
The line-allocate operation does not require physical memory to exist at the virtual
address specified by the instruction, since it does not generate a load/fill request to
external memory. Also, the line-allocate operation does not set the 32 bytes of data
associated with the line to any known value. Reading this data will produce
unpredictable results.
The line-allocate command will not operate on the mini Data Cache, so system software
must clean this cache by reading 2 Kbytes of contiguous unused data into it. This data
must be unused and reserved for this purpose so that it will not already be in the
cache. It must reside in a page that is marked as mini Data Cache cacheable (see “New
Page Attributes” on page 152).
The time it takes to execute a global clean operation depends on the number of dirty
lines in cache.
3.4.3 Reconfiguring the Data Cache as Data RAM
Software has the ability to lock tags associated with 32-byte lines in the data cache,
thus creating the appearance of data RAM. Any subsequent access to this line will
always hit the cache unless it is invalidated. Once a line is locked into the data cache it
is no longer available for cache allocation on a line fill. Up to 28 lines in each set can be
reconfigured as data RAM, such that the maximum data RAM size is 28 Kbytes for the
32-Kbyte cache and 12 Kbytes for the 16-Kbyte cache.
Hardware does not support locking lines into the mini-data cache; any attempt to do
this will produce unpredictable results.
There are two methods for locking tags into the data cache; the method of choice
depends on the application. One method is used to lock data that resides in external
memory into the data cache and the other method is used to re-configure lines in the
data cache as data RAM. Locking data from external memory into the data cache is
useful for lookup tables, constants, and any other data that is frequently accessed. Re-
configuring a portion of the data cache as data RAM is useful when an application needs
scratch memory (bigger than the register file can provide) for frequently used
variables. These variables may be strewn across memory, making it advantageous for
software to pack them into data RAM memory.
Code examples for these two applications are shown in Example 10 on page 69 and
Example 11 on page 70. The difference between these two routines is that Example 10
on page 69 actually requests the entire line of data from external memory and
Example 11 on page 70 uses the line-allocate operation to lock the tag into the cache.
No external memory request is made, which means software can map any unallocated
area of memory as data RAM. However, the line-allocate operation does validate the
target address with the MMU, so system software must ensure that the memory has a
valid descriptor in the page table.
Another item to note in Example 11 on page 70 is that the 32 bytes of data located in a
newly allocated line in the cache must be initialized by software before it can be read.
The line allocate operation does not initialize the 32 bytes and therefore reading from
that line will produce unpredictable results.
In both examples, the code drains the pending loads before and after locking data. This
step ensures that outstanding loads do not end up in the wrong place -- either
unintentionally locked into the cache or mistakenly left out in the proverbial cold. Note
also that a drain operation has been placed after the operation that locks the tag into
the cache. This drains ensures predictable results if a programmer tries to lock more
than 28 lines in a set; the tag will get allocated in this case but not locked into the
cache.