• data transfer: read/write operations on the on-chip bus, or handshakes on a coprocessor bus, or even optimized high-throughput or bursty data transfers, e.g. using a DMA controller
• wordlength conversion: data operands of the custom-hardware module can be arbitrary in size and number, whereas data suitable for on-chip bus communication are limited in both respects
• operand storage: local storage for arguments and parameters of the custom hardware: arguments are updated every time the module executes; parameter updates may be infrequent
• instruction set: the custom instruction set is a key feature of the hardware interface, its design defines the software view of the custom hardware component
• local control: implementation of local control interactions with the custom hardware module, such as sequencing a series of microoperations in response to a single software command

from the perspective of the custom hardware module, it is common to partition the collection of ports into data input/output ports and control/status ports

• note that, in fig. 12.2, control signals and data signals are orthogonal: control flows vertically, and data flows horizontally

the separation of control and data is an important design aspect, for, in a coprocessor design, the granularity of interaction between data and control is chosen by the designer

• both data-design and control-design are going to be discussed next

features of a coprocessor data port: wordlength, direction and update rate

• extremes for the update rate are: parameter, only set upon module reset, and function argument, which changes value upon each execution of the hardware module

to make a good mapping of actual hardware ports to custom interface ports, it is convenient to start from the features of the actual hardware ports

• e.g., a coprocessor for the GCD function, specified as int gcd(int m, int n), would have two input ports and one output port, all 32-bit wide, with frequent update rate

when this module is implemented as a memory-mapped coprocessor, the ports of the hardware interface will be implemented as memory-mapped registers

• a straightforward approach is to map each actual hardware port to a distinct memory-mapped register, as this makes each port of the hardware module independently addressable from software

however, it may not always be possible to allocate an arbitrary number of memory-mapped ports in the hardware interface—in that case, one needs to multiplex the custom-hardware module ports over the hardware interface ports

• besides shortage of interface ports, another reason for multiplexing may be the infrequent update rate of some ports of the custom hardware module, so that it is inefficient to allocate a separate interface port for each of them

figure 12.6 shows the architecture of a coprocessor that can achieve communication/computation overlap, as illustrated in figure 12.7

the command interpreter analyzes each command from software and splits it up into a combination of commands for the lower-level FSMs

• e.g., for a coprocessor which has an addressable register set in the input or output buffer, the register address may be embedded into the command coming from software

to effectively achieve execution overlap, a pipelining of the FSM actions is to be organized, where the command interpreter should adapt to the individual schedules of the lower-level FSMs

programmer’s model = control design + data design

• the programmer’s model, that is the software view of a hardware module, includes a collection of the memory areas used by the custom hardware module, and a definition of the commands (or instructions) understood by the module

the address map reflects the organization of software-readable and software-writable storage elements of the hardware module; its design should consider the viewpoint of the software designer rather than the hardware designer, thus:

• a given memory-mapped address should always affect the same hardware register, regardless of whether the operation on it is a read or a write
• by default all memory-mapped registers should be read/write; in some cases, read-only registers are justified, such as for example to implement registers that reflect hardware status information or sampled-data signals; however, there are very few cases that justify a write-only register
• the address map should respect the alignment of the processor; e.g., extracting bits number 5–12 out of a 32-bit word is more complicated than extracting the second byte of the same word

the design of a good instruction set is a hard problem, that requires the codesigner to make a proper trade-off between flexibility and efficiency

• it strongly depends on the function of the custom-hardware module

here are a few generic design guidelines:

• one can distinguish three classes of instructions: one-time commands, on-off commands, and configurations; their mix affects the general behavior of the hardware module, it should be aimed at minimizing the amount of control interaction between the software driver and the hardware module
• design the synchronization between software and hardware at multiple levels of abstraction, that is, not just at the data transfer level but also at the algorithmic level
• another synchronization problem occurs when multiple software users share a single hardware module; this may be solved either by serializing coprocessor usage or by implementing a context switch in the hardware module
• finally, reset design must be carefully considered; an example of flawed reset design is when a hardware module can only be initialized by means of full system reset—it makes sense to define one or several instructions for the hardware module to handle module initialization and reset