Furber S.ARM system-on-chip architecture.2000

Execute

Data memory interface

Reorder buffer

Register write

allows some elasticity in its operation, and there is a separate Thumb decode stage that effectively collapses when ARM code is running.

The register read and forwarding stage collects operands from the register file and searches the reorder buffer for newer values, supplying the correct up-to-date value to the execution unit. If the correct value is not yet available the forwarding process will stall until it becomes available.

Following the insights of the StrongARM designers, the AMULETS register file has three read ports. This allows nearly all instructions to be issued in a single cycle.

The execution stage includes the adder, shifter and multiplier, and the PSRs also fit logically into this stage. The multiplier computes 8 bits of product in a cycle, but cycles much faster than the typical processor cycle time so it computes a 32 x 32 product in around 20 ns. The adder uses the carry arbitration scheme also used in the ARM9TDMI (see 'Carry arbitration adder' on page 91).

The data memory interface operates as a separate pipeline stage in load and store instructions but is bypassed by other types of instruction. A load that addresses a slow memory location will therefore not hold up other instructions in the pipeline, provided that they do not use the loaded value.

The reorder buffer accepts results from the execution unit and the data memory interface in the order that they become available and stores them until they can be written back to the register file in program order. Once a result is in the reorder buffer it is available for forwarding to any instruction that needs it.

The structure used to achieve this functionality is illustrated in Figure 14.11 on page 390. The buffer has four 'slots', and a slot is allocated to each result produced by an instruction when that instruction is issued. (Slots are also allocated to 'store' instructions so that memory faults can be handled correctly.) As soon as the result is available it is moved into its slot.

Forwarding from the reorder buffer requires a search of the buffer contents. Conditional ARM instructions may or may not return valid results to the buffer; multiple instructions may use the same destination register. Identifying the most up-to-date value for a particular register potentially requires waiting for a result to become available in a slot, seeing that it is invalid, and then (worst case) searching all the other slots in series. This case is rare, though, and is easily accommodated by the asynchronous timing framework.

The write-back stream delivered by the reorder buffer is in program order, so this stage of the pipeline simply delivers values to the register file, checking each one for validity and looking for any memory faults. If a fault is detected an exception is raised and subsequent results are discarded unti\ the exception handling, mechanism has activated.

Rationale for self-timing

DRACO functions

The decision to employ a self-timed processing subsystem in the DRACO chip was influenced primarily by the electromagnetic compatibility (EMC) advantages of self-timed logic. The radio interference generated by high-speed clocked systems can compromise the performance of the DECT radio communication; a harmonic of the clock is likely to fall within one of the DECT channel frequency bands, possibly rendering that channel unusable.

The logical conclusion might be to make all of the chip operate in self-timed logic. However, many of the telecommunications interfaces are intrinsically highly synchronous and are much easier to design using synchronous synthesis tools.

The synchronous peripheral subsystem should not compromise the EMC advantages offered by the self-timed processing subsystem since the characteristic frequencies of the peripherals are all much lower than the processing rate. All the high-speed processing and the heavily loaded external memory bus operate asynchro-nously, giving most of the advantages of a fully self-timed system without incurring the design cost of developing self-timed telecommunications peripherals.

The DRACO chip includes the following functions in the synchronous peripheral subsystem:

•an ISDN controller with a 16 Kbit/s HDLC controller and transformerless ana logue ISDN interfaces;

•a DECT radio interface baseband controller and analogue interface to the DECT radio subsystem;

•a DECT encryption engine;

•a four-channel full-duplex ADPCM/PCM conversion signal processor;

•8 Kbytes of shared RAM used for buffer space by the DECT controller;

•a telecommunications codec with an analogue front-end for speech input and output which could alternatively be used for an analogue telecommunications port;

•two high-speed UARTs with an IrDA interface that can be used by either UART;

•an interrupt controller;

•counter-timers and a watchdog timer;

•a 2 Mbit/s IOM2 highway controller with programmable switching functionality;

•an I2C interface;

•an analogue-to-digital converter (ADC) interface;

•65 flexible I/O ports including an 8-bit parallel port with handshake capability;

•2 general-purpose pulse-width modulation controllers;

•an on-chip clock oscillator produces 38.864 MHz, and on-chip phase-locked loops produce the 12.288 MHz master clock required by the ISDN interface and the 13.824 MHz master clock required by the DECT controller;

394

Test interface controller

The AMULET Asynchronous ARM Processors

Figure 14.13 AMULET3H memory organization.

unimpeded by the other; when they happen to conflict on the same block, one access will suffer a delay while it waits for the other to complete.

Conflicts (and average memory access times) are further reduced by including separate quad-word instruction and data buffers in each RAM block. Each access to a block first checks to see whether the required data is in the buffer. Only if it is not must the RAM be interrogated, with a risk of conflict. Simulations suggest that about 60% of instruction fetches may be satisfied from within these buffers and many short, time-critical loops will run entirely from them.

These buffers, in effect, form simple 128-byte first-level caches in front of the RAM blocks. This is a particularly apt analogy when it is observed that the avoidance of the RAM array results in a faster read cycle, an occurrence which is accepted automatically by the asynchronous pipeline.

AMULET3H is being developed for commercial use and must therefore be testable in production. There are many features in the design to ensure that this is possible, the most visible of which is the test interface controller (see Figure 14.12 on page 393). This extension to the external memory interface logic follows the example set by AMBA (see "Test interface" on page 219) in enabling the external memory interface, which in normal operation is a MARBLE slave, to become a MARBLE master for test purposes. In test mode production test equipment can become a MARBLE master, allowing it to read on-chip ROM and to read and write on-chip RAM, and to access the many other test facilities built into the AMULET3H system, all of which are controlled via test registers connected to the MARBLE bus.