Table of Contents
Advertisement
4.2.6
Instruction Fetch Latency
The instruction fetch latency is dependent on the core to memory frequency ratio, system bus
bandwidth, system memory, etc., which are all particular to each ASSP. So, refer to the Intel
®
XScale
details on instruction fetch latency.
4.2.7
Instruction Cache Coherency
The instruction cache does not detect modification to program memory by loads, stores or actions
of other bus masters. Several situations may require program memory modification, such as
uploading code from disk.
The application program is responsible for synchronizing code modification and invalidating the
cache. In general, software must ensure that modified code space is not accessed until modification
and invalidating are completed.
To achieve cache coherence, instruction cache contents can be invalidated after code modification
in external memory is complete. Refer to
page 4-53
If the instruction cache is not enabled, or code is being written to a non-cacheable region, software
must still invalidate the instruction cache before using the newly-written code. This precaution
ensures that state associated with the new code is not buffered elsewhere in the processor, such as
the fetch buffers or the BTB.
Naturally, when writing code as data, care must be taken to force it completely out of the processor
into external memory before attempting to execute it. If writing into a non-cacheable region,
flushing the write buffers is sufficient precaution (see
operation). If writing to a cacheable region, then the data cache should be submitted to a
Clean/Invalidate operation (see
Developer's Manual
core implementation option section of the ASSP architecture specification for exact
for the proper procedure in invalidating the instruction cache.
Section
January, 2004
Intel XScale® Core Developer's Manual
Section 4.3.3, "Invalidating the Instruction Cache" on
Section 7.2.8
6.3.3.1) to ensure coherency.
Instruction Cache
for a description of this
51
Advertisement
Table of Contents
