Coprocessor Interface
ARM DDI 0301H Copyright © 2004-2009 ARM Limited. All rights reserved. 11-19
ID012310 Non-Confidential, Unrestricted Access
11.6 Operations
This section describes the various operations that can be performed and events that can take
place.
11.6.1 Normal operation
In normal operation the core passes all instructions across to the coprocessor, and then
increments the tag if the instruction was a coprocessor instruction. The coprocessor decodes the
instruction and throws it away if it is not a coprocessor instruction or if it contains the wrong
coprocessor number.
Each coprocessor instruction then passes down the pipeline, sending a token down the length
queue as it moves into the issue stage. The instruction then moves into the Ex1 stage, sending a
token down the accept queue, and remains there until it has received a token from the cancel
queue.
If the cancel token does not request that the instruction is cancelled, and is not a Store
instruction, it moves on to the Ex2 stage. The instruction then moves down the pipeline until it
reaches the Ex6 stage. At this point, it waits to receive a token from the finish queue, that enables
it to retire, unless it is either:
• a store instruction, where it requires no token from the finish queue
• a load instruction, where it must wait until load data are available.
Store instruction are removed from the pipeline as soon as they leave the Ex1 stage.
11.6.2 Cancel operations
When the coprocessor instruction reaches the Ex1 stage it looks for a token in the cancel queue.
If the token indicates that the instruction is to be cancelled, it is removed from the pipeline and
does not pass to Ex2. Any tail instruction in the I stage is also removed.
11.6.3 Bounce operations
The coprocessor can reject an instruction by bouncing it when it reaches the issue stage. This
can happen to an instruction that has been accepted as a valid coprocessor instruction by the
decoder, but that is found to be unexecutable by the issue stage, perhaps because it refers to a
non-existent register or operation.
When the bounced instruction leaves the issue stage to move into Ex1, the token sent down the
accept queue has its bounce bit set. This causes the instruction to be removed from the core
pipeline.
When the instruction moves into Ex1 it has its dead bit set, turning it into a phantom. This
enables the instruction to remain in the pipeline to match tokens in the cancel queue.
The core posts a token for the bounced instruction before the coprocessor can bounce it, so the
phantom is required to pick up the token for the bounced instruction. The instruction is
otherwise inert, and has no other effect. The core might already have decided to cancel the
instruction being bounced. In this case, the cancel token causes the phantom to be removed from
the pipeline. If the core does not cancel the phantom it continues to the bottom of the pipeline.
11.6.4 Flush operations
A flush can be triggered by the core in any stage from issue to WBls inclusive. When this
happens a broadcast signal is received by the coprocessor, passing it the tag associated with the
instruction triggering the flush.
To Next Page
Loading...
Need help?
General
