MIPS MIPS32 74K Series, Руководство по программированию

Страница: 30 / 156

3.2 Fixed mapping option
Programming the MIPS32® 74K™ Core Family, Revision 02.14 30
3.2 Fixed mapping option
With the fixed mapping option, virtual address ranges are hard-wired to particular physical address windows, and
cacheability options are set through CP0 register fields as summarized in
Table 3.2 :
Even in fixed-mapping mode, the cache parity error status bit Status[ERL] still has the effect (required by the MIPS32
architecture) of taking over the normal mapping of “kuseg”; addresses in that range are used unmapped as physical
addresses, and all accesses are uncached, until
Status[ERL] is cleared again.
3.3 Reads, writes and synchronization
The MIPS architecture permits implementations a fair amount of freedom as to the order in which loads and stores
appear at the CPU interface. Most of the time anything goes: so long as the software behaves correctly, the MIPS
architecture places few constraints on the order of reads and writes seen by some other agent in a system.
3.3.1 Read/write ordering and cache/memory data queues in the 74K
™
core
To understand the timing of loads and stores (and sometimes instruction fetches), we need to say a little more about
the internal construction of the 74K core. In order to maximize performance:
• Loads are non-blocking: execution continues “through” a load instruction, and only stops when the program tries
to use the GPR value it just loaded.
• Writes are “posted”: a write from the core is put aside (the hardware stores both address and data) until the CPU
can get access to the system interface and send it off. Even writes which hit in the cache are posted, occurring
after the instruction graduates.
• Cache refills are handled after the “missing” load has graduated: most of the time the CPU will quite soon get
hung up on an instruction which needs the data from the miss, but this is not necessarily the case. The CPU runs
on after the load instruction, with the memory pipeline logic remembering and handling the load completion.
All of these are implemented with “queues”, called the LDQ, WBB and FSB (for “fill/store buffer” — it’s used both
for writes which hit and for refills after a cache miss) respectively. All the queues handle data first-come, first served.
The WBB and FSB queues need to be snooped - a subsequent store to a location with a load pending had better not be
allowed to go ahead until the original load data has reached the cache, for example. So each queue entry is tagged
with the address of the data it contains.
An LDQ entry is required for every load that misses in the cache. This queue allows the CPU to keep running even
though there are outstanding loads. When the load data is finally returned from the system, the LDQ and the main
core logic act together to write this data into the correct GPR (which will then free up any instructions whose issue is
blocked waiting for this data).
Table 3.2 Fixed memory mapping
Segment Virtual range Physical range Cacheability
Name bits from
kuseg
0x0000.0000-0x7FFF.FFFF 0x4000.0000-0xBFFF.FFFF
Config[KU]
kseg0
0x8000.0000-0x9FFF.FFFF 0x0000.0000-0x1FFF.FFFF
Config[K0]
kseg1
0xA000.0000-0xBFFF.FFFF 0x0000.0000-0x1FFF.FFFF
(uncached)
kseg2/3
0xC000.0000-0xFFFF.FFFF 0xC000.0000-0xFFFF.FFFF
Config[K23]