BCM1250/BCM1125/BCM1125H
User Manual
10/21/02
B r o a d c o m C o r p o r a t i o n
Page
16
Section 3: System Overview
Document
1250_1125-UM100CB-R
CPU S
PECULATIVE
E
XECUTION
The SB-1 CPU can speculatively execute cacheable loads (i.e. a read is issued to the ZBbus to get the data
before the load is guaranteed to graduate), this only happens if the load is canceled because of an exception
on an earlier instruction (branches are always resolved before the load is committed). This is normally not a
problem since cacheable reads do not have side effects. However, the MIPS kernel address map includes
areas where the cacheability attribute is supplied by the address rather than the TLB (kseg0 and xkphys). If a
register contains one of these addresses that forces the cacheable attribute then a speculative load may be
made to a peripheral address. To protect against this the internal peripherals check the cacheability of reads,
and will prevent cacheable reads from having side effects. The generic bus has a mechanism to block
cacheable reads which can be enabled for external peripherals that have read side effects (but should normally
be disabled for memories). The only space where speculation can cause a problem is therefore the xkphys
aliases for PCI and HyperTransport peripherals.
In the absence of program error (i.e. the register just contains the wrong value) there are two reasonable
instruction sequences that could cause this behavior if at the start of the sequence the register happens to hold
a kseg0 or xkphys cacheable alias of a peripheral. In both cases an exception is used to fix the address for the
load.
These two sequences can be fixed by adding two superscalar no-ops (
ssnop
) instructions before the loads to
ensure the load is not speculatively executed before the exception triggers.
A similar situation arises if the
ld
is replaced with an indirect jump (
jr r1
), which can put a junk value into
the jump register cache and cause a subsequent speculative instruction fetch to issue a cacheable read from
a peripheral address. Again inserting two
ssnop
instructions will prevent the problem.
The CPU (
break)
instruction has a special issue rule, so does not suffer from this problem. It is safe for a
debugger to use (
break)
to insert breakpoints in the normal way.
; at this point r1 contains junk
syscall 73 ; returns address in r1
ld r2, 0(r1)
; This code intends to check r1 before the load
tle r1, r2 ; trap if r1 is out of range