possibili evoluzioni del codesign realizzato nell'esercitazione precedente si possono prefigurare lungo due direzioni ortogonali di sviluppo:

• miglioramento delle prestazioni
• estensioni funzionali

un esempio di combinazione ortogonale delle due direzioni è dato dai seguenti obiettivi per un primo progetto che qui si affronta:

• un sicuro miglioramento delle prestazioni può ottenersi replicando in parallelo l'unità hardware dedicata al calcolo del delay
• d'altra parte, un'estensione funzionale minima di sicuro interesse è l'ampliamento della larghezza dell'input, per l'applicabilità del calcolo del delay a un più ampio dominio di traiettorie

estensioni funzionali più significative sono individuabili dalla considerazione di funzioni, definite sulle traiettorie di Collatz, diverse dal delay ma per il calcolo delle quali è comunque necessaria la generazione delle traiettorie

• qui la sfida starebbe nel progetto di unità hardware di calcolo multifunzione e di un'interfaccia HW/SW più complessa, atta alla selezione delle funzioni di interesse e al relativo trasferimento di dati

una prima alternativa di progetto da considerare per la replica delle unità hardware di calcolo del delay è:

• repliche del componente di calcolo quali istanze distinte sul bus Avalon, o
• costruzione di un componente più complesso, che incorpori più copie del singolo componente di calcolo

la seconda opzione è preferibile in vista di possibili ulteriori estensioni che richiedessero accesso delle diverse istanze a dati condivisi, e.g. definiti come parametri di configurazione

• infatti, in tal caso si evitano così transazioni sul bus a tal fine, inoltre si realizza una gerarchia del controllo che assegna al coprocessore funzioni di controllo locale

altre decisioni di progetto riguardano il numero delle istanze parallele di calcolo, dette core nel seguito, e la dimensione dei dati di I/O del coprocessore

• tenendo conto che il processore Nios II può trasferire sul bus in una singola transazione non più di 32 bit, e che può essere utile disporre di un registro di stato nel coprocessore con un bit per ciascun core, conviene limitare a 32 il numero dei core
• dai dati disponibili nel sito web sul problema 3x+1 curato da Eric Roosendaal, e.g. nella tabella dei Class Records, emerge una dimensione minima di 64 bit per dati di input interessanti, mentre 16 bit bastano per l'output del delay

l'estensione a 64 bit dell'input del singolo core è ottenuta facilmente con ovvia modifica del sorgente Gezel dall'esercitazione precedente e con la stessa correzione all'output VHDL del traduttore fdlvhd

• la descrizione strutturale del coprocessore multicore in VHDL è facilitata dal costrutto iterativo for <identifier> in <range> generate, il cui uso è esemplificato in Zwoliński, 4.5.2, che nel nostro caso permette la generazione delle 2ⁿ = 32 istanze del core, con n = 5

occorre poi dotare il coprocessore multicore di circuiti per il corretto smistamento dei dati di I/O fra l'interfaccia e un core selezionato dal processore:

• un multiplatore a n bit di selezione e porte dati da 16 bit per l'output del delay dal core
• un demultiplatore a n bit di selezione e porte dati da 64 bit per l'input del dato d'inizio al core, nonché uno analogo ma con porte dati da 1 bit per l'input del segnale di start

la descrizione in VHDL della multiplazione è semplice se si collocano gli output dei core in un vettore da 2ⁿ×16 bit, basta infatti usare un operatore di selezione sul vettore

la descrizione in VHDL della demultiplazione, più complessa, è fattibile usando un operatore di scorrimento logico, come esemplificato per un decodificatore generico in Zwoliński, 4.2.3

lo scambio di segnali alle porte di I/O del coprocessore multicore va adattato ai segnali disponibili all'interfaccia Avalon-MM, tenendo conto di alcuni vincoli su questi, quali:

• i segnali di trasferimento dati, writedata e readdata, devono avere la stessa larghezza
• il segnale address individua un registro di I/O nello spazio di memoria assegnato al coprocessore, a partire da 0 e con indirizzamento di parola per default

poiché il processore Nios II può trasferire in una singola transazione non più di 32 bit, si conviene che questa sia la larghezza di parola del coprocessore all'interfaccia Avalon, ovvero la larghezza dei segnali writedata e readdata

• da ciò consegue che l'output del delay va esteso con zeri, mentre l'input del dato d'inizio traiettoria va acquisito in due cicli di bus

lo spazio degli indirizzi di registro del coprocessore è dunque l'intervallo [0, 3×2ⁿ], tenendo conto di un indirizzo per il registro di stato, dunque address è largo n+2 bit

• un'opportuna gestione degli indirizzi di registro permette una rapida identificazione del core (o del registro di stato) dal valore dell'input address, per esempio:
  decode(address[n,1]) se address[n+1] = 0
  decode(address[n-1,0]) se address[n+1,n] = 10
  registro di stato se address[n+1,n] = 11

fasi principali di sviluppo:

• descrizione in VHDL e simulazione del coprocessore multicore
• descrizione in VHDL e simulazione del coprocessore multicore con interfaccia Avalon MM
• costruzione Qsys di un sistema Nios II con coprocessore e performance counter, mapping del sistema su FPGA e compilazione
• stesura del driver software e di script TCL per la sua generazione in HAL
• stesura dell'applicazione software per test e misura della prestazione, in due versioni:
  • sequenziale : esecuzione senza lettura del registro di stato del coprocessore
  • status-tested : esecuzione con lettura del registro di stato del coprocessore
• compilazione ed esecuzione dell'applicazione mediante Monitor Program, per due varianti di ciascuna versione: una con valore di default del livello di ottimizzazione, l'altra con livello O3
• salvataggio dei performance report e archiviazione del progetto

produzione della descrizione VHDL del coprocessore multicore in due passi:

• coprocessore 1-core con input a 64 bit
• coprocessore 2ⁿ-core con output di stato a 2ⁿ bit

i rispettivi sorgenti delay_collatz.vhd e multicore_delay_collatz.vhd sono disponibili nella cartella vhdl dell'archivio allegato

• il coprocessore 1-core è ottenuto in modo analogo a quello della precedente esercitazione, con ovvia modifica del sorgente Gezel e analoga correzione dell'output del traduttore fdlvhd

il coprocessore è dotato dell'input core_select a n bit che codifica il core a cui smistare l'operazione di I/O, mentre gli output done dei core individuali sono esposti quale stato globale in una porta parallela di output a 2ⁿ bit

• le porte dati x0 e delay dei core individuali sono disposte su segnali interni paralleli, rispettivamente da 64*2ⁿ bit e 16*2ⁿ bit, da cui la decodifica di core_select seleziona la parte di interesse all'operazione di I/O

le cartelle delay_collatz, mc_delay_collatz e mc_interface sono intese ospitare progetti di compilazione e simulazione dei suddetti sorgenti e di quello descritto appresso; cartelle omonime in tests forniscono rispettivi file di input per le simulazioni

un'istanza del componente coprocessore multicore è incorporata nell'interfaccia Avalon memory-mapped descritta dal sorgente multicore_delay_collatz_avalon_interface.vhd e accede ai seguenti segnali del bus Avalon:

• clock, resetn, read, write, chipselect, address, waitrequest, writedata, readdata

• il segnale address ha larghezza n+2 bit e codifica l'indirizzo di registro del coprocessore (v. prossima pagina)
• i segnali writedata, readdata hanno larghezza 32 bit ciascuno, per il trasferimento di un dato con il processore Nios II in un solo ciclo

l'acquisizione dell'input a 64 bit per il coprocessore avviene dunque in due cicli di bus, perciò l'interfaccia deve memorizzare il dato ricevuto nel primo ciclo per poi concatenarlo a quello ricevuto nel secondo ciclo; ne consegue la classica struttura a due processi della descrizione:

• uno per l'aggiornamento di un registro con il dato del primo ciclo,
• l'altro per la rete combinatoria

d'altra parte, l'output a 32 bit del dato a 16 bit prodotto da un core del coprocessore ne richiede l'estensione con zeri, realizzata dall'interfaccia

la consultazione del sorgente multicore_delay_collatz_interface.vhd mostra le relazioni tra i segnali di I/O del componente di calcolo e i segnali all'interfaccia Avalon

la costruzione con Qsys del sistema Nios II con il componente coprocessore, simile a quella dell'esercitazione precedente, assegna al coprocessore un indirizzo base e, a partire da questo, un'area di memoria per i suoi registri di I/O

• la memoria è indirizzabile a byte e gli indirizzi dei registri di I/O sono allineati a parole da 4 byte, tuttavia il modello di programmazione dei driver software di un componente sul bus Avalon prevede per default che il registro sia individuato da un indice di parola, detto register offset, che coincide con l'input address della sua interfaccia Avalon

la seguente mappa dei registri indica anche i segnali del componente coprocessore individuati dai corrispondenti offset di registro, indicizzati dal valore di core_select in parentesi, dove k = 2ⁿ è il numero di core paralleli, e con la legenda :

• ro: register offset
  ao: memory address offset (rispetto all'indirizzo base)

le successive fasi di sviluppo sono simili a quelle dell'esercitazione precedente:

• costruzione del componente Qsys coprocessore
• costruzione del sistema Nios II con coprocessore e Performance Counter
• mapping su FPGA e compilazione

la costruzione Qsys del sistema Nios II è più celere se effettuata come modifica del sistema Qsys dell'esercitazione precedente, dal quale si rimuove il componente delay_collatz_avalon_interface e gli si aggiunge un'istanza del nuovo componente multicore_delay_collatz_avalon_interface

• avvertenza : fare attenzione a salvare il sistema modificato nella directory del progetto corrente, non in quella del progetto del sistema da modificare

gli script TCL per la generazione del driver software nel BSP del progetto, forniti nella cartella codesign/ip/multicore_delay_collatz_avalon_interface dell'archivio allegato, sono simili a quelli dell'esercitazione precedente

i sorgenti C del driver software, forniti nella cartella HAL allo stesso percorso, differiscono da quelli dell'esercitazione precedente nei seguenti aspetti:

• definizione della costante MDC_N_CORES = 32, il numero di core nel coprocessore
• per il lancio del calcolo di un core su una traiettoria di dato inizio si fornisce la funzione mdc_start che effettua due operazioni di scrittura sul bus (per la lunghezza di parola doppia del dato d'inizio), invece della macro che ne effettua una sola nel caso precedente
• in aggiunta alla funzione delay, di lettura del risultato calcolato da un dato core, si fornisce la funzione status, di lettura del registro di stato del coprocessore

i programmi di test e misura delle prestazioni forniti nelle cartelle codesign/amp* dell'archivio allegato calcolano il delay per 2M punti d'inizio a partire da X_BASE = 1128784494896128

• N.B.: X_BASE+14 è il class record della classe 1746

in entrambe le versioni del test, il programma assegna al core j il calcolo del delay per i punti di inizio nella classe di congruenza j mod MDC_N_CORES, dunque per 2M/32 = 64K traiettorie (in media nella seconda versione); la differenza fra le versioni in codesign/amp_s* e quelle in codesign/amp_t* è la seguente:

• nel primo caso, detto sequenziale, si eseguono 64K iterazioni del ciclo di lettura di 32 risultati e rilancio dei core, senza lettura del registro di stato (dunque il processore resta in attesa quando richiede la lettura di un risultato non ancora disponibile)
• nel secondo caso, detto status-tested, il processore effettua la lettura del registro di stato e ne elabora il contenuto bit dopo bit, richiedendo la lettura dei risultati solo ai core che hanno completato il calcolo

i parametri di creazione dei progetti nel Monitor Program sono indicati nel file allegato MonitorNotes.txt

la compilazione, caricamento sulla FPGA ed esecuzione del programma sequential_multicore_delay_collatz_timing, nei due progetti codesign/amp_s e codesign/amp_s_o3 produce i Performance Counter Report in figura

• come nella precedente esercitazione, la più marcata riduzione del tempo di esecuzione delle operazioni di lettura del delay nella seconda variante può spiegarsi con l'inlining della funzione nella compilazione O3

seguono infine i Performance Counter Report dell'esecuzione del programma statustest_multicore_delay_collatz_timing, nei due progetti codesign/amp_t e codesign/amp_t_o3

materiali utili per l'esperienza di laboratorio proposta:

• archivio con file sorgenti per la riproduzione del progetto
• documenti Intel Corp. indicati nell'esercitazione precedente
• Zwoliński, Ch. 4, Sect. 4.2.3, 4.5.2