User`s manual
PPC405CR – AMCC PowerPC 32-bit RISC Processor
Word-0 Word-1
31 24 23 16 15 8 7 0 31 24 23 16 15 8 7 0
Half-0 Half-1 Half-2 Half-3
15 8 7 0 15 8 7 0 15 8 7 0 15 8 7 0
Byte-0 Byte-1 Byte-2 Byte-3 Byte-4 Byte-5 Byte-6 Byte-7
7 0 7 0 7 0 7 0 7 0 7 0 7 0 7 0
Figure 7. Organization of data types for the PPC405CR (Big Endian).
Physical Interface to Memory and Peripherals
The PPC405CR's physical interface to the outside world is always 32 bits wide. Since the addressing has a byte-level resolution,
this means that up to four "packets" of data (bytes) can be loaded or stored during a single memory access. To accommodate
this requirement all memory accesses (8-bit, 16-bit and 32-bit) are handled in a specific way.
Each 32-bit read and write can be considered as a read or write through four "byte-lanes". These byte-lanes are marked as valid
by the corresponding bits in the PER_WEB[3..0] and subsequent SEL_O[3..0] signal of the relevant Wishbone interface
(External Memory or Peripheral I/O). Each of these bits will be active if the byte data in that lane is valid. This allows a single
byte to be written to 32-bit wide memory without needing to use a slower read-modify-write cycle.
The instructions of the PPC405CR require that all 32-bit load/store operations be aligned on 4-byte boundaries and all 16-bit
load/store operations be aligned on 2-byte boundaries. Byte operations (8-bit) can be to any address.
To complete a byte load or store, the PPC405CR will position the byte data in the correct byte-lane and set the
PER_WEB/SEL_O signal for that lane active. The memory hardware must then only enable writing on the relevant 8-bits of data
from the 32-bit word.
When reading, the PPC405CR will put the relevant 8- or 16-bit value into the LSB's of the 32-bit word. What happens with the
remaining bits depends on the operation:
• for an unsigned read, the processor will pad-out the remaining 24 or 16 bits respectively with zeroes
• for a byte load/store, the processor will sign-extend from bit 8
• for a half-word load/store, the processor will sign-extend from bit 16.
Peripheral I/O
For memory I/O the process described happens transparently, because memory devices are always seen by the processor as
32 bits wide. Even when connecting to small 8- or 16-bit physical memories, the interfacing Memory Controller device will, as far
as the processor is concerned, make the memory look like it is 32 bits wide.
For peripheral devices, the process is not so simple. 32-bit wide peripheral devices behave like memory devices, although they
may or may not support individual byte-lanes. These devices should therefore be accessed using the 32-bit LW and SW
instructions. For C-code, this means declaring the interface to the device as 32 bits wide, for example:
#define Port32 (*(volatile unsigned int*) Port32_Address)
This will result in the software using LW and SW instructions to access the device.
If the 32-bit peripheral does support byte-lanes (i.e. it has a SEL_I[3..0] input), then smaller accesses can be performed using
the 8-bit LBU and SB or 16-bit LHU and SH instructions.
For smaller devices, there needs to be translation of the 8- or 16-bit values into the relevant byte-lanes in the processor. This is
automatically handled by the Wishbone Interconnect device if it is used to access slave peripheral I/O devices. There is,
however, some hardware penalty for this since it requires an extra 4:1 8-bit multiplexer for 8-bit devices or a 2:1 16-bit
multiplexer for 16-bit devices.
16-bit peripheral devices should be accessed using the 16-bit LHU and SH instructions. For C-code, this means declaring the
interface to the device as 16 bits wide, for example:
#define Port16 (*(volatile unsigned short*) Port16_Address)
This will result in the software using LHU and SH instructions to access the device.
CR0161 (v2.0) March 11, 2008 15