memory-mapped interfaces are the most general type of HW/SW interface

• in programming they are supported through the use of pointers, e.g.:
• volatile unsigned int *MMRegister = (unsigned int *) 0x8000;
  // write the value ’0xFF’ into the register
  *MMRegister = 0xFF;
  // read the register
  int value = *MMRegister;

Schaumont, Figure 11.1 - A memory-mapped register

why must the pointer be a volatile pointer?

• generally, the value stored at an int * can appear in three different locations in the memory hierarchy: in main memory, in the cache memory, and in a processor register
• by defining the pointer as a volatile int *, the compiler will avoid maintaining a copy of the memory-mapped register in the processor registers

simple extension of a memory-mapped register with a handshake mechanism, whereby the communicating parties signal the register state to each other

Schaumont, Figure 11.3 - A mailbox register between hardware and software

the protocol shown in the figure has two synchronization points, viz. just after req and ack taking the same value

• this means that it should be quite easy to double the throughput of this protocol... how?

two main disadvantages of this protocol:

• tight coupling, because of interlocked write/read operations
• high overhead in terms of bus transfers, to check the mailbox status

the use of a FIFO queue compensates temporary imbalances between the read and write throughputs

instead of controlling access to a single register, a single handshake can also be used to control access to a region of memory

Schaumont, Figure 11.6 - A double-buffered shared memory with a memory-mapped request/acknowledge handshake

in one phase of the protocol in figure, changes are allowed to region 1 of the memory, while in the other phase of the protocol, changes are allowed in region 2 of the memory

• this scheme implements the pipelining of read/write operations, which, for applications that require data-reorganization in between processing stages, may lead to substantial performance improvements

both the coprocessor instruction set and the specific coprocessor interface depend on the type of processor—not all processors have a coprocessor interface

• the decision of using a specific coprocessor interface locks the custom hardware module into a particular processor, thus it limits the reusability of that custom hardware module to systems that also use the same processor

main advantages of a coprocessor interface over an on-chip bus:

• higher throughput : because not constrained by the wordlength of the bus on chip, nor by the load/store transfer mechanism
• fixed latency : a coprocessor bus is a dedicated, point-to-point connection with stable, predictable timing

the Nios-II softcore processor has a coprocessor interface whereby custom instructions may be defined and hardware modules may be attached to

Schaumont, Figure 11.15 - Nios-II custom-instruction interface timing

the interface supports variable-length execution of custom instructions through a two-way handshake

the clk_en input is used to mask off the clock to the custom hardware when the instruction is inactive

• in software, the custom instruction is executed through the instruction custom, e.g.:
  • custom 0x5, r2, r3, r5
  assigns the value 0x5 to n and associates the dataa, datab, result ports with registers r2, r3, r5, respectively—use of n: to multiplex different custom instructions in the hardware module

the use of a local register file in the custom hardware module is also supported