ARM720T_LH79520 – Sharp LH79520 SoC with ARM720T 32-bit RISC Processor
• 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.
8-bit peripheral devices should be accessed using the 8-bit LBU and SB instructions. For C-code, this means declaring the
interface to the device as 8 bits wide, for example:
#define Port8 (*(volatile unsigned char*) Port8_Address)
This will result in the software using LBU and SB instructions to access the device.
There are some trade-offs that may need to be considered when deciding whether to use 8-, 16- or 32-bit wide devices. It may
require significantly less hardware to implement a single 32-bit wide I/O port than it would to implement four separate 8-bit ports.
If however, the natural format of the data packets is 8-bits and hardware size is not a constraint, then it may be better to use 8-
bit ports since there will be no need to use software to break up a 32-bit value into smaller components.
If you are only accessing 8-bits at any one time, then software may also execute faster when using 8-bit wide peripherals, since
there is need for extra instructions to extract the 8-bit values from the 32-bit values.