¾ frequenza fissa;

Capitolo 4

LO SPADA EMULATOR

Come già indicato in precedenza, il sistema oggetto del presente lavoro deve generare 60 canali indipendenti ed individualmente programmabili, atti a emulare i segnali provenienti dalla Detection Board sviluppata presso il Politecnico di Milano. Si richiede, inoltre, che vi siano due modalità di ‘testing’:

¾ frequenza fissa;

¾ frequenza pseudocasuale;

La prima, utile in particolar modo alle alte frequenze, consente di verificare che ciascun impulso, generato in seguito al rivelamento di un fotone da parte di un sensore, sia contato correttamente. La seconda introduce una pseudo-aleatorietà nell’istante di arrivo degli impulsi, consentendo così una generazione pseudo- casuale di stimoli per il testing della Processing Board.

E’ stato, di conseguenza, realizzato un sistema che possa produrre stimoli a frequenza fissa o variabile entro una certa banda prevedendo, in quest’ultimo caso, una sorta di gestione adattiva dei parametri di configurazione.

Sono infine delineate le funzioni espletate dal DSP.

4.1 L’architettura implementata sull’ FPGA

La configurazione scelta, per la scheda C6713Compact, nel presente caso, prevede che il

DSP sia master di sistema e l’FPGA slave; in conseguenza di ciò l’FPGA è visto come una

periferica montata nello spazio di memoria del DSP. L’interfaccia preposta al trasferimento

dati tra DSP ed FPGA è l’EMIF, fig.4.1.

Fig.4.1 : Connessioni tra FPGA ed interfaccia EMIF del DSP.

L’FPGA deve quindi decodificare le linee di controllo dell’EMIF per determinare se il DSP vi stia accedendo. L’accesso è possibile solo mediante le linee CE2 e CE3, che individuano gli spazi di memoria riservati all’FPGA; vengono inoltre attivati segnali di abilitazione dei dati e di controllo per effettuare operazioni di lettura o scrittura.

Come anticipato nei precedenti capitoli, l’FPGA riceve il clock dall’EMIF e la frequenza impostata, programmabile a livello del PLL controller del DSP, risulta essere 90 MHz.

La struttura implementata sull’FPGA consta di:

¾ un modulo principale, l’Emulator_core, che provvede alla generazione dei segnali di uscita;

¾ un modulo Clock Manager che riceve il clock dall’EMIF e lo ridistribuisce ai moduli interni;

¾ della glue-logic per la generazione dei segnali di abilitazione a partire dai segnali di

controllo del DSP;

¾ degli I/O Buffer per il collegamento dei segnali di ingresso non utilizzati al fine di non lasciare in alta impedenza i pin di cui non si è fatto uso.

In fig.4.2 è evidenziata parte della connettività tra DSP ed FPGA; per ulteriori dettagli si rimanda alla consultazione dell’appendice A, che contiene il codice VHDL con cui se ne è descritta la struttura

CPU_ECLK_OUT_PAD 0

SYSTEM_CLK

DCM_IS_LOCKED

GSR EMUL_RST

EMUL_CLK

CPU_AREn_PAD CPU_AWEn_PAD

EMUL_RD_STRBn EMUL_WR_STRBn

CPU_A_PAD[20..2] EMUL_ADDR

LED_REDn_PAD LED_GREENn_PAD

19

EMUL_GREENn_LED EMUL_REDn_LED

EMUL_DATA 32

CPU_D_PAD

EMUL_WR

EMUL_RD CPU_CE2n_PAD

CPU_A_PAD21 EMUL_CS

EMUL_SIGNAL

EMULATOR_CORE

CPU_AOEn_PAD

Clock_manager

EMUL_SPADA_SIGNAL 60

ML_PIN_A1:A30_PAD

ML_PIN_C1:C30_PAD

Fig. 4.2: Connettività verso l’Emulator_Core.

Si procede con la descrizione dell’Emulator_Core e dei suoi moduli interni.

4.1.1 L’Emulator_Core

L’Emulator_core è la top entity del sistema ed è costituito essenzialmente da:

¾ una macchina a stati, Write_Valid_State_Machine, che gestisce un protocollo di sincronizzazione dei dati provenienti dal DSP;

¾ 30 sub-module, chiamati ‘Spad’, per la generazione dei segnali di uscita;

¾ un registro di configurazione dei LED riservati all’FPGA;

¾ un registro di abilitazione per i singoli moduli ‘Spad’;

¾ una matrice di 30 registri per il caricamento delle configurazioni d’ingresso dei moduli

‘Spad’;

¾ altri registri di ausilio, necessari per la realizzazione del protocollo di sincronizzazione.

Uno schema di massima del modulo è riportato in fig4.3.

write_valid state_machine

REGISTER READ PROCESS

REGISTER WRITE PROCESS WRSTRBn_I

EMUL_WR_STRBn

ADDR EMUL_ADDR

WR_I EMUL_WR

EMUL_DATA_I DATA_I

WRITE_VALID_DFF

RDSTRBn_I RD_I DATA_O EMUL_RD_STRBn

EMUL_RD EMUL_DATA_O

32

19

LOAD_REG PROCESS

CFG_REG_FF CFG_REG_SEL_FF CFG_REG_EN_FF

CFG_REG_MATRIX_FF

CFG_REG_LOAD

32 WR_VAL_DFF_RST

32

2

32 30X32

SPAD(0)

SPAD(1)

SPAD(i)

SPAD(29)

EMUL_SIGNAL(0);(30)

EMUL_SIGNAL(1);(31)

EMUL_SIGNAL(i);(30+i)

EMUL_SIGNAL(29);(59)

EMUL_GREEN_LEDn

EMUL_RED_LEDn

FIG. 4.3 : Schema semplificato del modulo Emulator_core.

Prima di descrivere il funzionamento del modulo occorre precisare che si è scelto di

indirizzarlo nello spazio di memoria CE2 (indirizzo 0xA0000000) a partire dall’offset

0x00200000. Questa scelta trova giustificazione nel fatto che, di default, CE2 è configurato per

operazioni a 32bit, anche se sarebbe stato possibile configurare l’EMIF diversamente affinché

anche CE3, che di default prevede trasferimenti a 16 bit, potesse gestire operazioni a 32 bit. I

registri utilizzati ed il loro contenuto sono evidenziati in Tab.4.1.

ADDRESS REG_TYPE 0xA0200000 REG_CONFIG_LED 0xA0200004 WORD_CFG_SPAD_0 0xA0200008 WORD_CFG_SPAD_1 0xA020000C WORD_CFG_SPAD_2

……… ………..

……… ………..

0xA0200070 WORD_CFG_SPAD_28 0xA0200078 WORD_CFG_SPAD_29 0xA020007C CFG_REG_ENABLE_SPAD 0xA0200080 CFG_REG_SEL

Tab. 4.1 : Indirizzo dei registri e loro contenuto.

Tutti i registri sono accessibili sia in scrittura che in lettura.

Un ulteriore registro all’indirizzo 0xA02000F4 contiene un bit di validità dei dati presenti su tutti gli altri, posto ad ‘1’ dal DSP alla fine di ogni accesso in scrittura, e resettato opportunamente dalla macchina a stati Write_Valid, come si vedrà più in dettaglio nella sua descrizione, a conclusione della fase di sincronizzazione.

La temporizzazione di una scrittura è riportata in fig.4.4. In essa le linee /CE2 ed /AOE sono direttamente filate con il DSP (CPU_CE2n_PAD e CPU_AOEn_PAD, rispettivamente); le altre sono ottenute da queste e, con opportune operazioni di mascheraggio effettuate dalla glue-logic, portate in ingresso direttamente all’Emulator_Core. In un accesso in scrittura si nota come il WR_I rimanga attivo alto per tutto il tempo, mentre il WRSTRB_n si attivi alla sola presenza di dati ed indirizzi stabili.

Un processo di sincronizzazione con il clock di sistema prevede il caricamento del contenuto di questi registri su un banco di registri ausiliari, secondo il protocollo gestito dalla macchina a stati, pronti per essere caricati dai sub-module ‘Spad’.

Infine i segnali generati dai moduli ‘Spad’ sono resi disponibili in uscita sul connettore

micro-line, sui pin A1:A30;C1:C30.

CLK

/CE2

ADDRESS

DATA

/AOE

RDSTRB_n

WRSTRB_n

WR_I

RD_I

Fig. 4.4: Temporizzazione di una scrittura sui registri dell’FPGA.

4.1.1.1 La Write_Valide_Machine

Un grafo di flusso della Write_Valid_Machine è riportato in fig. 4.5.

Partendo da uno stato di idle, WV_VALID, in cui tutte le uscite sono a ‘0’, aspetta che il bit di validità sia ad ‘1’ a notifica del fatto che un accesso in scrittura è stato effettuato dal DSP.

WV_VALID WV_VALID2 WV_VALID3

ENABLE_DATA

WV_VALID_BIT=1 WV_VALID_BIT=1

WV_VALID_BIT=1

WV_CLEAR_VALID_BIT=0

WV_DATA_ENABLE=0 WV_CLEAR_VALID_BIT=0

WV_DATA_ENABLE=0

WV_CLEAR_VALID_BIT=0 WV_DATA_ENABLE=0

WV_CLEAR_VALID_BIT=1 WV_DATA_ENABLE=1

WV_VALID_BIT=0

WV_VALID_BIT=0 WV_VALID_BIT=0

OTHERS

Fig. 4.5 : Grafo di flusso della Write_Valid_Machine.

A questo punto, la macchina aspetta due cicli di clock, durante i quali il bit di validità deve

permanere ad ‘1’ ad indicare l’effettiva presenza di dati disponibili, scongiurando eventuali

errori aleatori, altrimenti ritorna nello stato di idle. Quando si arriva nello stato Enable_Data i dati sono dichiarati validi e il bit di validità è resettato tramite il Clear_Valid_Bit attivo; i nuovi dati, a questo punto, possono essere caricati sul banco di registri ausiliari. Infine si rientra nello stato di idle.

4.1.1.2 Il modulo ‘Spad’

Il modulo Spad, la cui architettura è visibile in fig. 4.6 , è costituito da tre sub-module:

¾ un contatore, dotato internamente di un piedino per il caricamento sincrono di una parola di configurazione;

¾ un modulo per la gestione della configurazione d’ingresso;

¾ un monostabile per produrre in uscita, a partire dal ripple carry output del contatore, un impulso di durata opportuna;

MONOSTABLE SINGLE_COUNT

MODUL_1 SEL

SP_WORD_IN

WORD

ENA

0 PULSE

WAVE EN

CLK

RST SEL

EN(i) CFG_REG_MATRIX_FF(i)

SPADA_SIGNAL(i) CLK

RST

ENA

SEL

2 2

2 32

24 32

Fig. 4.6 : Schema semplificato del modulo ‘Spad’.

Si osserva che dei segnali di clock e reset in fig. 4.6 non sono state evidenziate le connettività per non ‘appesantire’ la struttura, ma qui e nel seguito, si considerano trasparenti a tutti i sub-module; si sottolinea, inoltre, che il reset è asincrono per tutti i moduli, e che la tecnica utilizzata per l’implementazione dell’intero sistema è quella di progetto sincrono statico.

I due bit di selezione contenuti nel registro CFG_REG_SEL dell’Emulator_core(Tab. 4.1) sono trasparenti a tutti i moduli, vale a dire che la modalità prevista, Tab. 4.2 , è applicata contemporaneamente a tutti i moduli Spad.

SEL MODE

“00” FIXED_FREQUENCY_MODE

“01” LOAD_NEW_DATA

“10” PSEUDO_RANDOM_MODE

“11” ---

Tab. 4.2: Modalità di funzionamento dei moduli ‘Spad’.

Il bit di abilitazione (per lo Spad(i) è l’i-imo bit di CFG_REG_ENABLE_SPAD in Tab.4.1) è invece indipendente per ciascun modulo. La presenza di questo bit non è stata prevista in una fase iniziale del progetto, in quanto il fatto che comunque i sensori avrebbero prodotto in uscita degli impulsi, i dark-counts, anche in assenza di illuminazione aveva indotto la decisione di rendere tutti i moduli sempre attivi; infatti il caso di sensore ‘spento’ che genera conteggi di buio sarebbe stato emulato prevedendo di far contare comunque i contatori interni ma in modo che generassero una frequenza inferiore ai 10 KHz, proprio come da specifica sui dark-counts dei sensori. In una seconda fase, invece, si è ritenuto che la presenza delle abilitazioni fosse necessaria al fine di rendere agevoli operazioni di debugging della DPB e per, eventualmente, valutare la rilevanza di eventuali fenomeni di cross-talk tra i canali. Qualora un modulo ‘Spad’ non sia abilitato la forma d’onda in uscita dal contatore è ignorata, e passa il livello logico ‘0’.

Per quanto riguarda la WORD di configurazione, a 32 bit, dell’i-imo modulo ‘Spad’ essa è

contenuta nell’i_imo registro della matrice CFG_REG_MATRIX_FF ed è portata in ingresso

al suo modulo interno Modul_1.

L’impulso generato in uscita dal contatore, oltre a passare dal monostabile per essere infine prodotto in uscita, entra anch’esso nel modulo MODUL_1 (segnale ENA, fig.4.6) in quanto avrà un ruolo nel generare le abilitazioni dei registri ad esso interni.

All’interno dell’Emulator_core, questa struttura è replicata per 30 volte; infatti, nonostante le notevoli dimensioni dell’FPGA, non è stato possibile generare, come desiderato, 60 canali indipendenti, bensì 30. Si è deciso, di conseguenza, di replicare questi ultimi al fine di ottenere i 30 restanti canali; pertanto sul connettore micro-line sui pin A1:A30 e C1:C30 sono portati i medesimi segnali.

4.1.1.2.1 Il modulo Single_count

Questo modulo realizza un contatore a 24 bit dotato di piedino per il caricamento sincrono di una parola di configurazione dall’esterno, fig. 4.7.

24_BIT_COUNTER

SEL SEL_IN

CLK

RST

LOAD

RCO EN_COUNT

CLK

RST

WORD

ENA SEL_IN(0)

2 2

24 24

Fig. 4.7 : Il modulo ‘Single_count’.

Allo scopo di generare gli impulsi d’uscita si è scelto di sfruttare il ripple carry output

(RCO) del contatore. Quest’ultimo incrementa il suo contenuto ad ogni ciclo di clock e, al

raggiungimento dell’overflow, il segnale di RCO è attivato, consentendo il caricamento di una parola (WORD) da cui iniziare il conteggio al ciclo successivo. Ne segue che la frequenza d’uscita dell’RCO risulta:

K f f

n clk

= −

2 (4.1)

dove N è il numero di bit, 24 nel presente caso, e K la parola caricata, dalla quale ha inizio il conteggio.

La dimensione N=24 del contatore è stata dettata dalla necessità di produrre come frequenza minima in uscita 10 Hz. Infatti, considerando la più piccola word di configurazione, ovvero K=0, invertendo la (4.1) si ricava:

24 Hz )

10 MHz ( 90

log₂ ⎥⎥⎤=

⎢⎢⎡ +

= K

N

Avendo preso la parte intera superiore dell’espressione la frequenza minima risulta essere f

=5,36 Hz.

In fig.4.7 è evidenziata la presenza di un bit necessario per abilitare il contatore. Ciò per consentire il conteggio esclusivamente quando si è in modalità fixed_frequency o pseudo_random, lasciandolo disabilitato in fase di caricamento delle nuove configurazioni, fig.4.8. Al fine di ottenere prontamente un impulso in uscita, quando la modalità di funzionamento è stata scelta, si è deciso di far partire il conteggio, successivamente all’applicazione di un reset, dal valore 0x”FFFFF0” (esadecimale) anziché da 0x”000000”, di default.

Fig. 4.8 : Abilitazione al conteggio del modulo Single_count

Dalla tabella di verità Tab. 4.3 si comprende la scelta di utilizzare il bit di selezione meno

significativo per la generazione del segnale di abilitazione al conteggio.

SEL /EN_COUNT

“00” ‘0’

“01” ‘1’

“10” ‘0’

“11” ‘1’

Tab. 4.3 : Abilitazione del contatore; il segnale è attivo basso.

Dalla (4.1) si deduce l’algoritmo utilizzato per la generazione delle opportune parole di configurazione a seconda della frequenza desiderata in uscita; questo sarà implementato a livello software, come illustrato nel capitolo 5.

4.1.1.2.2 Il modulo ‘monostable’

Il presente modulo svolge la sola funzione di raddoppiare la durata dell’impulso in uscita dal ‘Single_count’. Utilizzando l’RCO stesso del contatore l’impulso prodotto in uscita avrebbe avuto la durata di un periodo di clock (11 ns); la scelta di inserire il monostabile al fine di aumentare la durata dell’impulso è stata effettuata per emulare il tempo di hold-off dei sensori SPAD. Ciò comporta una riduzione della frequenza massima ottenibile, comunque perfettamente compatibile con le specifiche di sistema che richiedono una massima frequenza di 20 MHz. Infatti in corrispondenza della massima parola di configurazione K 0x”FFFFFE”, la frequenza degli overflow del contatore è di 45 MHz, ma in tal caso il monostabile, la cui uscita è wave in fig. 4.9, non può commutare.

Fig.4.9 : La word di configurazione K= 0x”FFFFFE” produce un’uscita costante, anziché una forma d’onda impulsata.

Fig.4.10 : Massima frequenza ottenibile in uscita, corrispondente alla word di configurazione K=0x”FFFFFC”.

Si è quindi pensato di prevedere, a livello dell’interfaccia software, che la massima parola di caricamento sia 0x”FFFFFC”, cui corrisponde una frequenza massima di 22,7 MHz, fig.4.10, che, come già osservato, risponde pienamente alle presenti esigenze di collaudo.

4.1.1.2.3 Il modulo Modul_1

E’ il modulo che consente il corretto pilotaggio del contatore, tramite una opportuna gestione dei parametri di configurazione, fig. 4.11.

32

2

8

24 WORD_IN

SEL_IN

EN_INT

EN_LOAD

EN_PRBS

DATA_OUT

CLK RST

REG_SELECTOR EN_GENERATOR

24 CFG_REG

WORD_CFG_REG

WORD

24 CLK

RST SP_WORD_IN

SEL

ENA 32

2

Fig. 4.11 : Il modulo che gestisce i parametri di configurazione: Modul_1.

In particolare il suo modulo interno, Reg_Selector

, la cui architettura di massima

è

1 Nell’Appendice A contenente il codice VHDL il presente modulo è riferito con il nome shift_reg2, invece il generatore di enable è riferito con il nome en_assign.

2 Sono evidenziati i registri e le connettività principali; per ulteriori dettagli si rimanda all’Appendice A

presentata in fig. 4.12, è l’elemento chiave del sistema di emulazione. Si osserva, che il registro LFSR al suo interno è stato realizzato utilizzando l’implementazione di Fibonacci, che pur essendo meno veloce di quella proposta da Galois, richiede un numero inferiore di porte XOR. Si vedrà come la velocità di aggiornamento di questo registro non sia un parametro critico per l’intero sistema. Inoltre al fine di scongiurare un eventuale stato di lock dell’LFSR è stato previsto che all’attivazione del segnale di reset i bit in esso contenuti siano posti tutti ad

‘1’; in un secondo momento questa configurazione, al reset, è stata scelta anche per tutti i registri di configurazione interni all’Emulator_core, per evitare il caricamento indesiderato di configurazioni di lock qualora dopo il reset non sia effettuata una nuova scrittura dei parametri da parte del DSP. Il set di tap portati in ingresso alla porta XOR è un m-sequence-feedback- tap-set (cfr. capitolo 2) ovvero un set che consente di ottenere una sequenza di massima lunghezza. Se ne deduce che, trattandosi di un registro a 24 bit, la sequenza d’uscita avrà periodo ( 2

- 1 ).

Prima di descrivere il funzionamento del modulo Reg_Selector, si introduce il generatore di enable, che fornisce segnali utili anche al primo. Come si intuisce dal raffronto tra le fig. 4.6 e 4.11, in cui sono stati evidenziati i segnali di scambio tra i vari moduli, ENA è il ripple carry output del contatore. In Tab. 4.4 è riportata la modalità di generazione dei segnali di enable in uscita; il blocco, si nota, altro non è che un multiplexer con a valle un flip-flop, dotato di reset, affinché le sue uscite siano sincrone con il clock ed il pilotaggio dell’LFSR sia corretto.

…….

23 22 1

0 2

TAP23

TAP22

TAP19 TAP20 LFSR_TAP

EN_PRBS

ARRAY DI MULTIPLEXER LFSR REG_WORD

EN_LOAD EN_LOAD

24 24

24 8

CFG_REG

24 24

24

8 32

24 WORD_IN

0 1 23

DATA_OUT SEL

2

Fig. 4.12: Schema semplificato del modulo Reg_Selector

SEL EN_LOAD EN_PRBS

“00” ‘0’ ‘0’

“01” ‘1’ ‘0’

“10” ‘0’ ENA

“11” - -

Tab. 4.4 : Generazione dei segnali di enable per l’LFSR.

Nella modalità di caricamento (cfr. Tab.4.2), l’attivazione di En_load produce un aggiornamento dei registri di configurazione interni al Reg_Selector, altrimenti questo segnale rimane sempre a livello logico basso, fig. 4.13. Diversamente, l’attivazione di En_Prbs, che avviene quando si è in modalità pseudo-random ed è stato generato un overflow del contatore, fig.4.13, provoca l’aggiornamento del contenuto del solo LFSR interno al Reg_Selector.

Fig. 4.13: Generazione dei segnali di enable destinati al modulo REG_SELECTOR.

Per quanto riguarda il funzionamento del modulo Reg-Selector si osserva che, se la relazione (4.1) è di evidente applicazione nella modalità fixed-frequency lo stesso non si può dire per la seconda modalità, quella di pseudo-random frequency che realizza una pseudo- casualità della frequenza degli impulsi in uscita.

Nella fase di caricamento, il generatore di enable attiva il piedino En_Load, ed il contenuto di tutti i registri, REG_WORD, LFSR e CFG_REG, è aggiornato. Ai primi due sono portati i 24 bit meno significativi della WORD_IN, gli 8 più significativi sono mandati al CFG_REG.

Quest’ultimo contiene l’informazione relativa al numero di bit da cambiare qualora la modalità prevista sia quella di pseudo-random frequency. Gli altri contengono la parola di caricamento K del contatore, determinabile invertendo la (4.1), che imposta la frequenza desiderata.

Qualora la modalità prevista sia quella di fixed-frequency, il contenuto di CFG_REG è

modificato e posto a 0x”00” (esadecimale), fig. 4.14. Gli altri due registri conservano la loro informazione. L’Array di multiplexer, pilotato dal CFG_REG, ignora il contenuto dell’LFSR e porta in uscita quello di REG_WORD.

Ne segue che ad ogni raggiungimento dell’overflow del contatore, quest’ultimo carica la medesima parola, fig.4.15, la frequenza degli impulsi d’uscita risulta fissa e pari a quella calcolabile tramite la relazione (4.1). In fig. 4.16 è evidenziato il caso di modalità fixed_frequency (SEL=”00” binario) nel caso di frequenza f= 18,2 MHz, cui corrisponde la parola di configurazione K=0x”FFFFFB” (esadecimale).

Fig. 4.14 : Modifica del contenuto di CFG_REG nel caso di modalità fixed_frequency.

Fig. 4.15: Modalità fixed frequency: in ingresso al contatore, ad ogni raggiungimento dell’overflow, è caricata la medesima parola.

Fig. 4.16 : Modalità di testing fixed frequency: gli impulsi generati hanno periodo costante, pari a 55 ns.

Al fine di comprendere il funzionamento del presente modulo nella seconda modalità si evidenzia che esso realizza una sorta di sistema adattivo per la generazione delle parole di caricamento del contatore. Nella fig.4.17 la frequenza centrale F

è quella impostata esternamente dal computer remoto; ad essa corrisponde una parola K

di caricamento del contatore determinabile dalla (4.1). Si sceglie di far variare la frequenza entro una certa banda attorno alla frequenza centrale

, e si stabiliscono le frequenze limite di tale banda: f

ed f

; ad esse corrisponderanno, quindi, altrettante parole di caricamento K

e K

. Per far variare la frequenza nell’intervallo fissato, ad ogni raggiungimento dell’overflow da parte del contatore, si caricherà una parola K diversa tale che: K

≤ K ≤ K

. La frequenza degli impulsi d’uscita risulterà, conseguentemente, variabile nel range stabilito.

Fig. 4.17: Frequenza di riferimento F* e banda di variabilità nella modalità pseudo-random frequency.

Si supponga, infatti, che l’interfaccia software abbia dimensionato ∆f, e di conseguenza l’intervallo K

÷K

, e determinato che esso possa essere ‘spazzato’ facendo variare i quattro bit meno significativi del registro di configurazione del contatore.

In tal caso il registro CFG_REG conterrà 0x”04”, e questa informazione verrà interpretata nel seguente modo: si prelevano 4 bit dell’LFSR (poiché si estrae una sub-sequenza non è rilevante a che livello del registro: la presente struttura prevede che si estraggano i bit meno significativi di questo), e li si concatenano con i restanti più significativi del REG_WORD. Il contenuto di quest’ultimo rimane congelato, al fine di mantenere il riferimento di frequenza F

in fig. 4.18.

3 La determinazione di tale banda è demandata all’interfaccia software.

REG_WORD

MSB LSB

LFSR

WORD_IN

23 ………. 0

Fig. 4.18 : Modalità di generazione della word di caricamento in pseudo-random frequency mode.

Il contenuto dell’LFSR è, invece, aggiornato ad ogni clock successivo all’attivazione dell’rco del contatore (si ricorda che quest’ultimo, in modalità pseudo-random è cortocircuitato con l’En_prbs). Ciò conferma quanto detto in precedenza riguardo l’implementazione scelta per l’LFSR: il ramo di retroazione avrà tutto il tempo per fornire il nuovo tap d’ingresso dell’LFSR, fig.4.19.

Fig. .4.19 : Il contenuto dell’LFSR (reg_new) è aggiornato all’overflow del contatore successivo alla generazione del nuovo bit di rientro.

Infatti, dopo che la variabile lfsr_tap, che costituisce il bit di rientro dello shift-register, è resa disponibile, solo alla generazione successiva dell’overflow il contenuto dell’LFSR è aggiornato.

Il risultato di questa modalità di costruzione della parola K è che, ad ogni attivazione del

segnale ripple carry output, il contatore caricherà un contenuto diverso, word_in in fig. 4.20, e

gli impulsi prodotti in uscita, wave in fig. 4.21, avranno un periodo variabile. Nel caso di

fig.4.21, si è scelto per CFG_REG il valore 0x”02” e per REG_WORD il valore 0x”FFFFFB”

affinché nella finestra temporale fossero evidenti più impulsi consecutivi.

Fig. 4.20: Al raggiungimento dell’overflow da parte del contatore, è caricata una parola diversa.

Fig. 4.21: Impulsi generati in modalità pseudo-random frequency: si noti la variabilità del periodo.

Se dalla fig. 4.20 potrebbe sembrare che la word destinata all’ingresso al contatore vari ad ogni raggiungimento dell’overflow, ( e quindi ad ogni modifica del contenuto dell’LFSR) dalla fig.4.22 si nota come ciò non sia sempre vero.

Fig. 4.22 : Effetto indesiderato sulla generazione delle word variabili di caricamento del contatore.

Questo fatto si giustifica nel seguente modo: poiché, come evidenziato in fig.4.18,

dell’LFSR si preleva una sub-sequenza, non è detto che ciascuna di queste sia diversa dalle

precedenti anche se presa all’interno di una m-sequence (sequenza di massima lunghezza).

Il risultato di questa constatazione è il seguente: seppure il contenuto dell’LFSR sia aggiornato ad ogni attivazione dell’RCO, il sottoinsieme prelevato potrebbe rimanere uguale a quello preso precedentemente, causando il caricamento nel contatore della stessa parola per più volte, word_in in fig.4.22. E’ questa la motivazione per cui, nel seguito, non ci si riferirà alla frequenza centrale F

come a quella media; infatti non è detto che la densità di probabilità di presentazione di ciascuna frequenza nell’intervallo ∆f sia uniformemente distribuita.

A questo proposito si rende necessaria una digressione. Per la realizzazione del sistema adattivo, si è detto, è sorta la necessità di far variare un certo numero di bit nella parola di caricamento destinata al contatore. Il numero di bit da far variare, determinato a livello software, varia a seconda della frequenza impostata dall’esterno, F* in fig. 4.15: sarà minore in caso di frequenze alte, al limite pari ad uno, e maggiore a frequenze basse

; si arriva ad un massimo di 21 bit per la frequenza più bassa realizzabile. L’ultima constatazione ha, in una prima fase dello sviluppo, evidenziato un problema: la necessità di realizzare, per ciascun modulo ‘Spad’, 21 LFSR a numero di stadi crescente, fig. 4.23, attivandoli in maniera esclusiva a seconda del contenuto di CFG_REG.

………….

3_stages

4_stages

5_stages

21_stages

i

j

k

m 8

CFG_REG

Fig. 4.23 : Architettura ad LFSR multipli per ciascun modulo ‘Spad’.

4 Questo è dovuto al fatto che caratteristica intrinseca del contatore è quella di avere una risoluzione variabile con la frequenza, ovvero le frequenze in uscita non sono equidistanziate

Il notevole dispendio di risorse che una tale architettura avrebbe comportato, ha portato alla scelta di realizzare un unico LFSR per modulo e, di esso, prelevare il numero di bit desiderato, concatenandolo opportunamente con i restanti bit più significativi che impostano la frequenza centrale, fig. 4.15. L’architettura ad LFSR multipli avrebbe reso lecita l’affermazione di equivalenza tra frequenza media e frequenza centrale, in quanto ogni parola generata dall’LFSR avrebbe avuto probabilità di presentazione uguale alle altre e, di conseguenza, ciascuna frequenza interna a ∆f sarebbe stata generata con uguale probabilità.

Diversamente l’architettura realizzata, ad un solo LFSR, non consente una tale affermazione.

4.2 Funzioni espletate dal DSP

Come già anticipato, al DSP sono richiesti, per lo sviluppo del presente progetto:

¾ l’inizializzazione dei registri delle interfacce e delle periferiche;

¾ il caricamento del codice sull’FPGA;

¾ la gestione delle interruzioni di programma;

¾ la gestione dei trasferimenti mediante la porta seriale RS-232;

¾ il passaggio dei parametri di configurazione all’FPGA.

4.2.1 Inizializzazione dell’hardware

La fase di inizializzazione del sistema è realizzata mediante l’uso di una funzione di libreria C6xCptInit che configura l’intero hardware effettuando:

¾ una inizializzazione dei registri del PLD, in particolare:

o Frame Set Register (FSR), per il caricamento dei boot loader nella memoria Flash.

o Fpga control register (FCR) usato dalle applicazioni per caricare il codice

FPGA.

o LED control register.

o Module control register.

o I2C bus register.

o I/O flags register.

o UART clock control.

o DSP EXT_INT6 e EXT_INT7 enable/status register.

¾ una inizializzazione dei registri EMIF;

o Global control register che configura i parametri comuni a tutti gli spazi di memoria CE.

o I quattro registri CE space control register (CECTL). Ognuno corrisponde al relativo spazio di memoria CE supportato dalla EMIF.

o Lo SDRAM control register (SDCTL) che controlla i parametri SDRAM per tutti gli spazi CE e ne specifica il tipo e la quantità di memoria, fig. 4.24.

o Lo SDRAM timing register (SDTIM) che controlla il periodo di refresh in termini di cicli dell’EMIF clock.

Fig. 4.24 : Dimensioni ed indirizzi dei quattro spazi EMIF di memoria.

¾ una inizializzazione dei due registri core: CSR (Control Status Register) per il settaggio delle interruzioni, e ISTP (Interrupt Service Table Pointer Register) per l’identificazione dell’indirizzo delle routine di servizio collegate alle interruzioni di programma.

4.2.2 Interruzione di programma

Un interrupt consente l’interruzione del programma corrente del DSP ed il ‘salto’ alla

relativa routine di servizio.

Per la gestione delle interruzioni di programma sono previste delle funzioni di libreria che consentono il settaggio opportuno dei bit contenuti nei registri del DSP. Tra questi:

¾ Control Status Register (CSR): contiene informazioni sull’abilitazione delle interruzioni mascherabili; queste possono essere abilitate con la funzione di libreria C6xGlobalIntEnable e disabilitate tramite C6xGlobalIntDisable;

¾ Interrupt Enable Register (IER): serve per abilitare o disabilitare i singoli interrupt; la routine di servizio relativa ad un’interruzione sarà avviata solo se il corrispondente bit nell’IER è settato; a questo scopo si utilizzano le funzioni di libreria C6xIntEnable e C6xIntDisable per l’abilitazione e la disabilitazione rispettivamente;

¾ Interrupt Flag Register (IFR): contiene lo stato delle richieste di interrupt;

¾ Interrupt Clear and Set Register (ICR e ISR): consente di settare o resettare via software I flag del registro IFR; funzioni di libreria: C6xIntClear e C6xIntSet ;

¾ Interrupt Return Pointer: è utilizzato in caso di annidamento di interruzioni.

Nel presente progetto, si è previsto di abilitare le interruzioni mascherabili (C6xGlobalIntEnable) ed in particolare nell’IER è stato settato il bit relativo alla EXT_INT_7 (C6xIntEnable (C6xInt7)), gestita dalla seriale in condivisione con altre periferiche, fig.4.25 e 4.26.

Il DSP ha tre tipi di interruzioni; in ordine decrescente di priorità sono:

¾ di reset (attivo basso);

¾ non mascherabile (NMI);

¾ mascherabile;

Di quest’ultimo tipo ne sono disponibili quattro esterne: due collegate direttamente

all’FPGA e due, per la gestione di periferiche esterne, provenienti dal PLD, fig. 4.25 e 4.26.

Fig. 4.25 : Possibili fonti di interruzione provenienti dal PLD.

Delle prime non si è fatto uso, in quanto non necessarie. Per quanto riguarda la EXT_INT_7, si è previsto che questa sia gestita esclusivamente dalla seriale.

Fig. 4.26 : Routing delle interruzioni verso il DSP.

4.2.3 Interfaccia UART

Anche per la UART sono presenti dei registri, mappati nello spazio di memoria CE1, fig.4.27, la cui gestione consente il trasferimento dei dati ed il settaggio del tipo dell’interruzione.

L’accesso ai registri avviene a mezzo di funzioni di libreria che eseguono anche molte delle

funzioni elementari di trasferimento.

Fig. 4.27 : Registri di controllo della UART.

In particolare la funzione DebugInit provvede alla inizializzazione della porta seriale impostandone:

¾ Baudrate : setta la velocità di trasmissione in baud.

¾ TxIntEnable : abilita l’interruzione in trasmissione.

¾ RxIntEnable : abilita l’interruzione in ricezione.

¾ RTSEnable : abilita l’handshake RTS.

¾ CTSEnable : abilita l’handshake CTS.

Come già anticipato l’interruzione relativa all’UART, disponibile tramite il PLD, è la EXT_INT_7; tuttavia questa risulta in condivisione con l’LLC (Link Layer Controller), l’FPGA ed altre periferiche. Al fine di abilitare solo l’UART sulla EXT_INT_7, è necessario scrivere sull’opportuno bit del registro di controllo del PLD con la funzione C6713CPT_EINT7_EN = 0x80.

4.2.4 Trasferimento dei parametri all’FPGA

Il flusso di programma sviluppato su DSP, prevede che quest’ultimo organizzi i dati provenienti da seriale in double-word e li trasferisca all’FPGA effettuando degli accessi in scrittura nel relativo spazio di memoria (cfr. temporizzazione fig. 4.4). Durante un primo accesso il DSP scrive 33 double su registri posti ad indirizzi consecutivi, Tab.4.1:

¾ le prime 30 rappresentano le parole di caricamento dei contatori interni

all’Emulator_Core (WORD_CFG_SPAD_i) ;

¾ la successiva contiene le abilitazioni dei moduli ‘Spad’ interni all’Emulator_Core (CFG_REG_ENABLE_SPAD);

¾ la 32-ima, destinata al registro che contiene la modalità di funzionamento dei moduli

‘Spad’ (CFG_REG_SEL), prevede il caricamento in essi delle nuove configurazioni;

¾ l’ultima costituisce il bit di validità dei dati: WV_VALID_BIT;

Segue un accesso multiplo in scrittura al registro REG_CFG_LED per consentire un lampeggiamento dei LED, utile in fase di Debug.

Un ulteriore accesso al registro CFG_REG_SEL, seguito nuovamente dalla validazione del bit WV_VALID_BIT, determina la scrittura della modalità di testing richiesta dall’utente tramite l’interfaccia software (fixed o pseudo-random frequency)

.

5 Per ulteriori dettagli si rimanda alla consultazione dell’Appendice B.