le inerfacce mappate in memoria sono il tipo più generale di interfaccia HW/SW

• nei programmi il supporto è dato dall'uso di puntatori, 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

perché il puntatore deve essere volatile?

• in generale, il valore di un int * può trovarsi in tre tipi distinti di locazione nella gerarchia di memoria: memoria principale, memoria cache, registro del processore
• qualificare il puntatore come volatile fa sì che il compilatore eviti di collocare fra i registri del processore il registro mappato in memoria

semplice estensione del registro mappato in memoria con un meccanismo di handshake, con cui le parti comunicanti si segnalano reciprocamente lo stato del registro

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

il protocollo mostrato in figura ha due punti di sincronizzazione, subito dopo che req e ack assumono lo stesso valore

• dovrebbe essere abbastanza semplice raddoppiare il throughput di questo protocollo... come?

i due svantaggi principali di questo protocollo:

• accoppiamento stretto, per l'alternanza delle operazioni di scrittura/lettura
• elevato sovraccarico di trasferimenti sul bus, per controllare lo stato della mailbox

l'uso di una coda FIFO compensa squilibri temporanei fra il throughput di scrittura e quello di lettura

invece di controllare l'accesso a un solo registro, un handshake può essere usato anche per il controllo di accesso a una regione di memoria

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

in una fase del protocollo in figura, è permessa la modifica della regione 1 della memoria, mentre nell'altra fase è permessa la modifica della regione 2

• questo schema realizza il pipelining delle operazioni di lettura/scrittura, il che, per applicazioni che alternano riorganizzazione dei dati a stadi di elaborazione, può produrre miglioramenti sostanziali della prestazione

sia l'insieme di istruzioni di coprocessore che la specifica interfaccia di coprocessore dipendono dal tipo di processore; non tutti i processori hanno un'interfaccia di coprocessore

• la decisione di usare una specifica interfaccia di coprocessore lega il modulo hardware custom a un particolare processore, dunque limita la riusabilità del modulo ai sistemi che usano lo stesso processore

vantaggi principali di un'interfaccia di coprocessore rispetto al bus su chip:

• throughput più alto : perché non vincolato dalla larghezza del bus su chip, né dal meccanismo di trasferimento load/store
• latenza fissa : un bus di coprocessore è una connessione dedicata punto-punto con temporizzazione stabile e predicibile

il processore softcore Nios-II ha un'interfaccia di coprocessore su cui si possono definire istruzioni custom e collegare moduli hardware

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

l'interfaccia supporta l'esecuzione a durata variabile di istruzioni custom mediante doppio handshake

l'input clk_en si usa per disabilitare l'hardware custom quando l'istruzione è inattiva

• nel software si esegue l'istruzione custom mediante l'istruzione custom, e.g.:
  • custom 0x5, r2, r3, r5
  assegna il valore 0x5 a n e associa le porte dataa, datab, result ai registri r2, r3, r5, nell'ordine; uso di n: multiplazione di diverse istruzioni custom nel modulo hardware

è supportato anche l'uso di un banco di registri locale nel modulo hardware custom