Register Transfer Cycle

The coprocessor register transfer cycle is the one case when ARM7TDMI requires the data bus without requiring the memory to be active. The memory system is informed that the bus is required by ARM7TDMI taking both nMREQ and SEQ HIGH. When the bus is free, DBE should be taken HIGH to allow ARM7TDMI or the coprocessor to drive the bus, and an MCLK cycle times the transfer.

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 reenable 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.

Coprocessor

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 ARM7TDMI register. The coprocessor must stay busy while it performs the floating point to fixed point conversion, as ARM7TDMI will expect to receive the integer value on the cycle immediately following that where it goes not-busy. The coprocessor must therefore preserve the original floating point value and not corrupt it during the conversion, because it will be required again if an interrupt arises during the busy period.

The coprocessor data operation class of instruction is not generally subject to idempotency considerations, as the processing activity can take place after the coprocessor goes not-busy. There is no need for ARM7TDMI to be held up until the result is generated, because the result is confined to stay within the coprocessor.

Undefined Instructions

Undefined instructions are treated by ARM7TDMI as coprocessor instructions. All coprocessors must be absent (ie CPA and CPB must be HIGH) when an undefined instruction is presented. ARM7TDMI will then take the undefined instruction trap. Note that the coprocessor need only look at bit 27 of the instruction to differentiate undefined instructions (which all have 0 in bit 27) from coprocessor instructions (which all have 1 in bit 27)

Note that when in THUMB state, coprocessor instructions are not supported but undefined instructions are. Thus, all coprocessors must monitor the state of the TBIT output from ARM7TDMI. When ARM7TDMI is in THUMB state, coprocessors must appear absent (ie they must drive CPA and CPB HIGH) and the instructions seen on the data bus must be ignored. In this way, coprocessors will not erroneously execute THUMB instructions, and all undefined instructions will be handled correctly.

137

138 Coprocessor

This chapter describes the ARM7TDMI advanced debug interface.

Overview

The ARM7TDMI debug interface is based on IEEE Std. 1149.1- 1990, “Standard Test Access Port and Boundary-Scan Architecture”. Please refer to this standard for an explanation of the terms used in this chapter and for a description of the TAP controller states.

ARM7TDMI contains hardware extensions for advanced debugging features. These are intended to ease the user’s development of application software, operating systems, and the hardware itself.

The debug extensions allow the core to be stopped either on a given instruction fetch (breakpoint) or data access (watchpoint), or asynchronously by a debug-request. When this happens, ARM7TDMI is said to be in debug state. At this point, the core’s internal state and the system’s external state may be examined. Once examination is complete, the core and system state may be restored and program execution resumed.

ARM7TDMI is forced into debug state either by a request on one of the external debug interface signals, or by an internal functional unit known as ICEBreaker. Once in debug state, the core isolates itself from the memory system. The core can then be examined while all other system activity continues as normal.

ARM7TDMI’s internal state is examined via a JTAG-style serial interface, which allows instructions to be serially inserted into the core’s pipeline without using the external data bus. Thus, when in debug state, a store-multiple (STM) could be inserted into the instruction pipeline and this would dump the contents of ARM7TDMI’s registers. This data can be serially shifted out without affecting the rest of the system.

Debug Interface

139

Debug Systems

The ARM7TDMI forms one component of a debug system that interfaces from the high-level debugging performed by the user to the lowlevel interface supported by ARM7TDMI. Such a system typically has three parts:

1.The Debug Host

This is a computer, for example a PC, running a software debugger such as ARMSD. The debug host allows the user to issue high level commands such as “set breakpoint at location XX”, or “examine the contents of memory from 0x0 to 0x100”.

2.The Protocol Converter

The Debug Host will be connected to the ARM7TDMI development system via an interface (an RS232, for example). The messages broadcast over this connection must be converted to the interface signals of the ARM7TDMI, and this function is performed by the protocol converter.

3.ARM7TDMI

ARM7TDMI, with hardware extensions to ease debugging, is the lowest level of the system. The debug extensions allow the user to stall the core from program execution, examine its internal state and the state of the memory system, and then resume program execution.

Figure 75. Typical Debug System

Debug	Host computer running ARMSD
Host

Protocol

Converter

Debug Development System

Target Containing

ARM7TDMI

The anatomy of ARM7TDMI is shown in Figure 77. The major blocks are:

ARM7TDMI This is the CPU core, with hardware support for debug.

ICEBreaker This is a set of registers and comparators used to generate debug exceptions (eg breakpoints). This unit is described in ICEBreaker Module on page 163.

TAP controller This controls the action of the scan chains via a JTAG serial interface.

The Debug Host and the Protocol Converter are system dependent. The rest of this chapter describes the ARM7TDMI’s hardware debug extensions.

140	Debug