P60ARM-B/IG/GP1N Zarlink Semiconductor, Inc., P60ARM-B/IG/GP1N Datasheet - Page 76

• Manufacturer Part Number: P60ARM-B/IG/GP1N
• Description: A Low Power, General Purpose 32 Bit RISC Microprocessor
• Manufacturer: Zarlink Semiconductor, Inc.

P60ARM-B
6.2 Data transfer cycles
Once the coprocessor has gone not-busy in a data transfer instruction, it must supply or accept data at the
ARM60 bus rate (defined by MCLK and nWAIT ). It can deduce the direction of transfer by inspection of
the L bit in the instruction, but must only drive the bus when permitted to by DBE being HIGH. The
coprocessor is responsible for determining the number of words to be transferred; ARM60 will continue to
increment the address by one word per transfer until the coprocessor tells it to stop. The termination
condition is indicated by the coprocessor driving CPA and CPB HIGH.
There is no limit in principle to the number of words which one coprocessor data transfer can move, but by
convention no coprocessor should allow more than 16 words in one instruction. More than this would
worsen the worst case ARM60 interrupt latency, as the instruction is not interruptible once the transfers
have commenced. At 16 words, this instruction is comparable with a block transfer of 16 registers, and
therefore does not affect the worst case latency.
6.3 Register transfer cycle
The coprocessor register transfer cycle is the one case when ARM60 requires the data bus without requiring
the memory to be active. The memory system is informed that the bus is required by ARM60 taking both
nMREQ and SEQ HIGH. When the bus is free, DBE should be taken HIGH to allow ARM60 or the
coprocessor to drive the bus.
6.4 Privileged instructions
The coprocessor may restrict certain instructions for use in privileged modes only. To do this, the
coprocessor will have to track the nTRANS output.
As an example of the use of this facility, consider the case of a floating point coprocessor (FPU) in a multi-
tasking system. The operating system could save all the floating point registers on every task switch, but
this is inefficient in a typical system where only one or two tasks will use floating point operations. Instead,
there could be a privileged instruction which turns the FPU on or off. When a task switch happens, the
operating system can turn the FPU off without saving its registers. If the new task attempts an FPU
operation, the FPU will appear to be absent, causing an undefined instruction trap. The operating system
will then realise that the new task requires the FPU, so it will re-enable it and save FPU registers. The task
can then use the FPU as normal. If, however, the new task never attempts an FPU operation (as will be the
case for most tasks), the state saving overhead will have been avoided.
6.5 Idempotency
A consequence of the implementation of the coprocessor interface, with the interruptible busy-wait state, is
that all instructions may be interrupted at any point up to the time when the coprocessor goes not-busy. If
so interrupted, the instruction will normally be restarted from the beginning after the interrupt has been
processed. It is therefore essential that any action taken by the coprocessor before it goes not-busy must be
idempotent, ie must be repeatable with identical results.
For example, consider a FIX operation in a floating point coprocessor which returns the integer result to an
ARM60 register. The coprocessor must stay busy while it performs the floating point to fixed point
conversion, as ARM60 will expect to receive the integer value on the cycle immediately following that
72