Coprocessor Interface

11.2Coprocessor pipeline

The coprocessor interface achieves loose synchronization between the two pipelines by exchanging tokens from one pipeline to the other. These tokens pass down queues between the pipelines and can carry additional information. In most cases the primary purpose of the queue is to carry information about the instruction being processed, or to inform one pipeline of events occurring in the other.

Tokens are generated whenever a coprocessor instruction passes out of a pipeline stage associated with a queue into the next stage. These tokens are picked up by the partner stage in the other pipeline, and used to enable the corresponding instruction in that stage to move on. The movement of coprocessor instructions down each pipeline is matched exactly by the movement of tokens along the various queues that connect the pipelines.

If a pipeline stage has no associated queue, the instruction contained within it moves on in the normal way. The coprocessor interface is data-driven rather than control-driven.

11.2.1Coprocessor instructions

Each coprocessor might only execute a subset of all possible coprocessor instructions. Coprocessors reject those instructions they cannot handle. Table 11-1 lists all the coprocessor instructions supported by the processor and gives a brief description of each. For more details of coprocessor instructions, see the ARM Architecture Reference Manual.

The coprocessor instructions fall into three groups:

•loads

•stores

•processing instructions.

Coprocessor Interface

The load and store instructions enable information to pass between the core and the coprocessor. Some of them might be vectored. This enables several values to be transferred in a single instruction. This typically involves the transfer of several words of data between a set of registers in the coprocessor and a contiguous set of locations in memory.

Other instructions, for example MCR and MRC, transfer data between core and coprocessor registers. The CDP instruction controls the execution of a specified operation on data already held within the coprocessor, writing the result back into a coprocessor register, or changing the state of the coprocessor in some other way. Opcode fields within the CDP instruction determine the operation that is to be carried out.

The core pipeline handles both core and coprocessor instructions. The coprocessor, on the other hand, only deals with coprocessor instructions, so the coprocessor pipeline is likely to be empty for most of the time.

11.2.2Coprocessor control

The coprocessor communicates with the core using several signals. Most of these signals control the synchronizing queues that connect the coprocessor pipeline to the core pipeline. Table 11-2 lists the signals used for general coprocessor control.

11.2.3Pipeline synchronization

Figure 11-1 on page 11-5 shows an outline of the core and coprocessor pipelines and the synchronizing queues that communicate between them. Each queue is implemented as a very short First In First Out (FIFO) buffer.

No explicit flow control is required for the queues, because the pipeline lengths between the queues limits the number of items any queue can hold at any time. The geometry used means that only three slots are required in each queue.

The only status information required is a flag to indicate when the queue is empty. This is monitored by the receiving end of the queue, and determines if the associated pipeline stage can move on. Any information that the queue carries can also be read and acted on at the same time.

Coprocessor Interface

Figure 11-1 Core and coprocessor pipelines

Figure 11-2 provides a more detailed picture of the pipeline and the queues maintained by the coprocessor.

Figure 11-2 Coprocessor pipeline and queues

The instruction queue incorporates the instruction decoder and returns the length to the Ex1 stage of the core, using the length queue, that is maintained by the core. The coprocessor I stage sends a token to the core Ex2 stage through the accept queue, that is also maintained by the core. This token indicates to the core if the coprocessor is accepting the instruction in its I stage, or bouncing it.

Coprocessor Interface

The core can cancel an instruction currently in the coprocessor Ex1 stage by sending a signal with the token passed down the cancel queue. When a coprocessor instruction reads the Ex6 stage it might retire. How it retires depends on the instruction:

•Load instructions retire when they find load data available in the load data queue, see Loads on page 11-16

•Store instructions retire as soon as they leave the Ex1 stage, and are removed from the pipeline, see Stores on page 11-17

•CDP instructions retire when they read a token passed by the core down the finish queue.

Figure 11-2 on page 11-5 shows how data transfer uses the load data and store data queues, and Data transfer on page 11-15 explains this.

11.2.4Pipeline control

The coprocessor pipeline is very similar to the core pipeline, but lacks the fetch stages. Instructions are passed from the core directly into the Decode stage of the coprocessor pipeline, that takes the form of a FIFO queue.

The Decode stage then decodes the instruction, rejecting non-coprocessor instructions and any coprocessor instructions containing a nonmatching coprocessor number.

The length of any vectored data transfer is also decided at this point and sent back to the core. The decoded instruction then passes into the issue (I) stage. This stage decides if this particular instance of the instruction can be accepted. If it cannot, because it addresses a non-existent register, the instruction is bounced, informing the core that it cannot be accepted.

If the instruction is both valid and executable, it then passes down the execution pipeline, Ex1 to Ex6. At the bottom of the pipeline, in Ex6, the instruction waits for retirement. It can do this when it receives a matching token from another queue fed by the core.

Figure 11-3 on page 11-7 shows the coprocessor pipeline, the main fields within each stage, and the main control signals. Each stage controls the flow of information from the previous stage in the pipeline by passing its Enable signal back. When a pipeline stage is not enabled, it cannot accept information from the previous stage.

Figure 11-3 Coprocessor pipeline

Each pipeline stage contains a decoded instruction, and a tag, plus a few status flags:

Full flag This flag is set whenever the pipeline stage contains an instruction.

Dead flag This flag is set to indicate that the instruction in the stage is a phantom. See

Cancel operations on page 11-19.

Tail flag This flag is set to indicate that the instruction is the tail of an iterated instruction. See Loads on page 11-16.

There might also be other flags associated with the decoding of the instruction. Each stage is controlled not only by its own state, but also by external signals and signals from the following state, as follows:

These signals are combined with the current state of the pipeline to determine if the stage can accept new data, and what the new state of the stage is going to be. Table 11-3 lists how the new state of the pipeline stage is derived.