3.8.2.3 Fetching Past an Unconditional Branch
When
an
unconditional branch is
in
DCD
in
the instruction queue, the fetcher recognizes that the
sequential instructions following the branch are unnecessary. These sequential addresses are not
accessed. Addresses at the branch target are accessed instead.
Therefore,
placing an unconditional branch just before the start of a sensitive address space (for
example, at the "end" of a memory area that borders an liD device) guarantees that addresses
in
the
sensitive area
will not be speculatively fetched.
3.8.2.4 Suggested Locations
of
Memory-Mapped Hardware
The preferred method of protecting memory-mapped hardware from inadvertent access is to use
address
translation, with hardware isolated to guarded pages (the G storage attribute
in
the
associated TLB entry is set to 1.) The pages can be as
small as 1
KB.
Code should never be stored in
such pages.
If address translation is disabled, the preferred protection method is to isolate memory-mapped
hardware into regions guarded using the
SGR. Code should never be stored
in
such regions. The
disadvantage of this method, compared to the preferred method, is that each region guarded by the
SGR cons'umes 128MB of the address space.
Table 3-19 shows two address regions of the PPC405GP. Suppose a system designer can map all
liD devices and all ROM and SRAM devices into any location
in
either region. The choices made by
the designer can prevent
speculative accesses to the memory-mapped liD devices.
Table 3-19.
Example
Memory
Mapping
Ox7800 0000 - Ox7FFF FFFF (SGR bit
1S)
128MB Region 2
Ox7000 0000 - Ox77FF FFFF (SGR bit 14) 128MB Region 1
A simple way to avoid the problem of speculative reads to peripherals is to map all storage containing
code into Region
2,
and all liD devices into Region 1. Thus, accesses to Region 2 would only be for
code and program data.
Speculative fetches occuring
in
Region 2 would never access addresses in
Region
1.
Note that this hardware organization eliminates the need to use of the G storage attribute
to
protect Region
1.
However, Region 1 could be set as guarded with no performance penalty, because
there
is
no code to execute
or
variable data to access
in
Region
1.
The use of these regions could be reversed (code
in
Region 1 and I/O devices in Region 2), if Region
2 is set as guarded. Prefetching from the highest addresses of Region 1
could cause an attempt to
speculatively access the bottom of Region
2,
but guarding prevents this from occurring. The
performance
penalty is slight, under the assumption that code infrequently executes the instructions
in
the highest addresses of Region
1.
3-40 PPC40SGP User's Manual
Preliminary