Capitolo 5
L’interfaccia software
Come anticipato nei precedenti capitoli, la gestione dell’emulatore da computer remoto avviene tramite un’interfaccia sviluppata con l’applicativo Labview, prodotto dalla National Instruments.
Sono di seguito descritte le caratteristiche principali del programma realizzato ed è illustrata l’interfaccia utente tramite la quale è possibile impostare i parametri di configurazione destinati all’Emulatore e selezionare la modalità di testing desiderata.
Infine si illustrano i risultati ottenuti con strumentazioni di laboratorio.
5.1 Il programma realizzato con Labview
La programmazione con Labview è condotta in modalità grafica tramite diagrammi a blocchi (Block Diagram), realizzando una struttura modulare gerarchica nella quale ciascun modulo VI (Virtual Instrument) può essere utilizzato come subroutine all’interno di VI più complesse.
Una visione della struttura gerarchica del programma realizzato è data in fig. 5.1; in essa sono evidenziate le sub-VI utilizzate all’interno della VI principale.
In essa si evidenziano la VI principale, Emulator_Controller, che gestisce la comunicazione con la porta seriale, ed una sua sub-VI, Emulator_Panel, che realizza l’interfaccia utente vera e propria.
Fig. 5.1 : Visione gerarchica del programma realizzato con Labview.
5.1.1
L’interfaccia utente
L’interfaccia utente si presenta come il pannello frontale di uno strumento virtuale in cui controlli ed indicatori consentono rispettivamente di impostare i parametri desiderati e di visualizzare i risultati dei processi di elaborazione, fig. 5.2.
In particolare essa è costituita da:
¾ un selettore per la modalità di testing, MODE;
¾ 30 interruttori con led di feedback; ciascuno di essi è inoltre dotato, fig. 5.3, di tre indicatori:
o uno per la frequenza, espressa in kHz;
o uno per l’eventuale jitter, espresso in percentuale; o uno per l’identificazione del canale;
¾ un interruttore per la selezione di tutti i canali, ed uno per la loro contemporanea disattivazione, SELECT_ALL e TURN_OFF rispettivamente;
¾ un interruttore per la trasmissione dei dati via seriale, SET;
un selettore per l’impostazione della modalità di visualizzazione dei canali, utile nelle operazioni di testing, MASK_FOR_DEBUG.
Fig. 5.2 : Il pannello di controllo dell’Emulatore.
Inizialmente è necessario stabilire la modalità di testing, fixed-frequency o pseudo-random frequency, in quanto la determinazione dei parametri, destinati all’Emulatore, è diversa nei due casi.
In un secondo momento è possibile selezionare i canali dei quali si desidera impostare la frequenza, tramite degli interruttori la cui commutazione ad On provoca l’accensione dei corrispondenti led. Il selettore di frequenza risponde ai soli canali attivati, i cui indicatori digitali consentono di visualizzare la frequenza ottenibile più vicina a quella richiesta e l’eventuale jitter, se si è in modalità frequenza pseudo-variabile. Infine è possibile trasmettere i dati all’Emulatore via seriale tramite il relativo controllo.
Fig. 5.3 : Zoom dei controlli e degli indicatori digitali
5.1.1.1 La determinazione dei parametri di configurazione
dell’Emulatore
Al fine di consentire un corretto pilotaggio dell’Emulatore, è necessario specificare inizialmente la modalità di testing che si desidera effettuare. Questo perché:
¾ a livello hardware, l’architettura presentata prevede che tutti i canali siano sottoposti alla stessa modalità di funzionamento;
¾ a livello software, gli algoritmi tramite i quali si definiscono i parametri sono diversi nei due casi previsti.
In entrambe le modalità, all’interno del programma sono definiti degli array contenenti: ¾ le frequenze impostate dall’utente, Frequency ;
¾ le frequenze ottenibili con l’architettura presentata nel cap.4, Frequency_Array; ¾ l’eventuale jitter, se si è in modalità pseudo-random, Jitter_Array;
¾ le relative parole di caricamento dei contatori, Word_Cfg;
¾ il numero di bit che occorre cambiare all’interno delle precedenti, N_bit_to_be_changed;
¾ la configurazione finale destinata a ciascun canale, Final_Cfg;
Nella modalità fixed-frequency, la definizione dei parametri avviene per mezzo del modulo ‘freq_calc’, che riceve in ingresso la frequenza impostata dall’utente, e determina la parola K, che costituirà l’i-imo elemento dell’array Word_Cfg, di caricamento del contatore che realizza la frequenza più vicina a quella richiesta, fig. 5.4.
Fig. 5.4 : Determinazione della parola di caricameno di un contatore e della relativa frequenza ottenuta.
L’algoritmo implementato a questo scopo, si basa sull’utilizzo della relazione (5.1), nella quale f è la frequenza programmata dall’esterno, fclk è la frequenza operativa del sistema di emulazione e 224 è il numero di parole rappresentabili su 24 bit (compresa quella costituita da
tutti i bit a ‘0’):
f f
K~ =224− clk (5.1)
Fig. 5.5 : Schematizzazione dell’algoritmo utilizzato per la determinazione della parola di caricamento in modalità fixed-frequency.
Il K~ ottenuto dalla (5.1) è un reale; al fine di ottenere la migliore approssimazione della frequenza richiesta, nella conversione ad intero di questo valore se ne considerano sia la parte intera superiore, K’, che quella inferiore, K”.
Da questi si calcolano le corrispondenti frequenze ottenibili, invertendo la (5.1), f ’ ed f ” e si sceglie tra esse la più vicina alla frequenza f impostata, fig. 5.5. Questa operazione è ripetuta per tutti i canali selezionati, fig. 5.6, e consente la costruzione degli array Word_Cfg, Jitter, e Frequency_Array; il contenuto degli ultimi due è reso visualizzabile dai relativi indicatori digitali posti nelle immediate vicinanze di ciascun interruttore, fig.5.7. Il contenuto di Word_Cfg, che contiene le parole K a 24 bit, deve essere ulteriormente elaborato. In particolare i numeri contenuti in esso devono essere convertiti in stringhe, e queste ultime concatenate con quelle contenenti l’informazione sul numero di bit da cambiare.
Fig. 5.6 : Costruzione degli array Word_Cfg, Frequency_Array e Jitter_Array, in modalità frequency-fixed.
Nella modalità in discussione, quella di fixed-frequency, queste ultime contengono tutti ‘0’, ad indicare che la parola di caricamento dei contatori non deve essere fatta variare. A questo proposito è stato comunque previsto, a livello hardware, un meccanismo di tutela da eventuali errori di pilotaggio dell’Emulatore, che porterebbero a modi di funzionamento non previsti; in
modalità fixed-frequency il contenuto di CFG_REG (cfr. cap.4) interno al modulo ‘Modul_1’ è modificato con tutti bit a ‘0’.
Fig.5.7 : Funzionamento in modalità fixed-frequency: si noti lo scostamento tra la frequenza ottenuta e quella richiesta, e l’indicatore del jitter a 0%.
L’ultimo passo, prima della trasmissione dei dati su seriale, è la creazione di un array contenente tutti i parametri di configurazione, Final_Cfg, come illustrato più nel dettaglio nel paragrafo seguente.
L’algoritmo implementato per la determinazione dei parametri nella seconda modalità, pseudo-random frequency, risulta un po’ più complesso.
In particolare, riprendendo alcune considerazioni introdotte nel cap.4, è necessario definire la banda di variabilità della frequenza ∆f, fig. 5.8 cui corrisponde un intervallo Kmin÷KMax di
variazione delle parole di caricamento.
Si è dimensionato ∆f in modo tale che fosse di ampiezza pari al 10% della frequenza impostata dall’utente.
Il modulo che realizza l’algoritmo proposto è N_BIT_CALC, fig. 5.9.
Fig. 5.9 : Determinazione degli elementi dell’array N_bit_to_be_changed.
In tal caso il primo passo è quello di determinare, a seconda della frequenza selezionata dall’esterno, la banda di variazione desiderata, le relative parole di caricamento Kmin e KMax, e il
numero di bit che occorre cambiare per spazzare l’intervallo considerato.
E’ necessario, a questo punto, osservare che l’architettura realizzata sull’FPGA ponga dei vincoli sullo ‘spazzamento’ dell’intervallo Kmin÷KMax relativo a ∆f, da cui derivano uno
spostamento della finestra frequenziale, da quella desiderata a quella effettiva, ed una sua eventuale contrazione o dilatazione rispetto alla banda fissata, fig. 5.10.
Infatti una volta determinati i valori Kmin e KMax, è fissato il numero di bit da cambiare, tre
nell’esempio in fig. 5.11, dove si è supposto che i restanti bit più significativi siano uguali per entrambe le parole.
Fig. 5.10 : Spostamento della finestra e sua eventuale contrazione/dilatazione dovuta a condizioni di pratica realizzabilità.
In realtà, a livello hardware, l’architettura implementata, produrrà uno ‘spazzamento’ del nuovo intervallo Kmin* e KMax*, facendo variare i tre bit meno significativi, dal valore ‘000’ al
valore ‘111’.
Fig. 5.11 : Esempio di variazione dell’intervallo Kmin÷KMax dovuto ai vincoli posti dall’architettura implementata su FPGA.
Questo effetto è considerato nella determinazione dei parametri di configurazione e l’algoritmo è completato in due frame successivi, sempre interni al modulo N_bit_to_calc, che consentono di determinare la reale finestra di variazione della frequenza realizzabile con l’architettura proposta, e la frequenza centrale di tale banda, fig. 5.12. Un ulteriore frame consente la determinazione del jitter ottenuto.
Fig. 5.12: Determinazione della reale banda di variazione della frequenza in modalità pseudo-random frequency.
Come per la precedente modalità, di fixed-frequency, l’operazione descritta è ripetuta per tutti i canali attivati, e porta alla costruzione degli array: Word_Cfg, Frequency_Array, Jitter_Array, ed N_bit_to_be_changed, fig. 5.13. Il contenuto degli elementi di Frequency_Array e Jitter_Array è reso visualizzabile sul pannello frontale dell’interfaccia, fig.5.14.
Fig. 5.13: Costruzione degli array Word_cfg, Frequency_Array, Jitter_Array ed N_bit_to_be_changed inmodalità pseudo-random frequency.
Dopo aver determinato i parametri di configurazione contenuti negli array Word_Cfg ed N_bit_to_change, segue, come già introdotto per la modalità fixed-frequency, la loro elaborazione al fine di ottenere la configurazione finale destinata alla trasmissione via seriale.
5.1.1.2 La trasmissione dei dati
Il DSP sulla scheda C6713Compact aspetta che i dati siano trasmessi secondo un ben fissato protocollo, Tab.4.1:
¾ le prime 30 stringhe, contenenti i parametri di configurazione destinati ai moduli ‘Spad’ interni all’FPGA, WORD_CFG_SPAD_i;
¾ la 31-ima contenente le abilitazioni dei singoli canali, CFG_REG_ENABLE_SPAD; ¾ le ultime due contenenti le configurazioni per il registro di selezione, CFG_REG_SEL.
Di conseguenza la configurazione finale è un array di 33 stringhe, ciascuna delle quali è costituita da 8 caratteri in esadecimale.
La creazione delle prime trenta stringhe avviene in due fasi successive con l’ausilio delle sub-VI : CONV_TO_STRING ed ARRAY_CREATE, fig. 5.15.
Fig. 5.15 : Determinazione della configurazione finale da trasmettere via seriale, modalità pseudo-random frequency.
La prima preleva il contenuto degli array Word_Cfg ed N_bit_to_change e lo converte in due array di stringhe, Word_Cfg_string ed N_bit_to_change_string, fig.5.16.
Word_Cfg_string con una substringa estratta da N_bit_to_change_string, fig.5.17.
Fig. 5.16 : Creazione degli array di stringhe a partire dagli array di interi Word_Cfg e N_bit_to_be_changed(K_array).
Fig. 5.18 : Schematizzazione dell’algoritmo realizzato per la creazionedelle stringhe finali di configurazione.
Ciò allo scopo di concatenare le configurazioni contenute in Word_Cfg_string e N_bit_to_change_string, ed ottenere un’unica parola di configurazione per ciascun canale, fig.5.18.
In fig. 5.15 è evidenziato un’ulteriore sub-VI: EN_STRING. Quest’ultima genera la stringa delle abilitazioni dei singoli canali: è creata scorrendo l’array delle frequenze impostate dall’utente, e qualora su un canale non vi sia alcuna impostazione (il corrispondente indicatore visualizza in tal caso f =0 Hz) quel canale è considerato disabilitato, fig. 5.19, 5.20.
Fig. 5.20 : Conversione dell’array contenente le abilitazioni dei canali in stringa di abilitazione.
Infine la stringa relativa alla modalità di testing programmata dall’utente è inserita nell’array Final_Cfg, fig. 5.15, e la configurazione così ottenuta è trasmessa via seriale.
5.1.1.3 Le maschere per il debug
Come precedentemente accennato, le maschere per il debug hanno lo scopo di ausilio nelle funzioni di debug.
L’assemblaggio finale del sistema, di cui è data una rapida illustrazione nel capitolo successivo, prevede, infatti, che sia il sistema di testing che quello da testare siano inseriti all’interno di due ‘rack’ insieme a delle schede ausiliarie, tra cui un back plane che funge da bus, per consentirne la comunicazione attraverso due cavi SCSI a 68 pin.
In fase di debug è, di conseguenza, risultato utile identificare il percorso di ciascun canale su:
¾ pin del connettore micro-line; ¾ piste del back-plane;
¾ pin del connettore SCSI.
Infine è determinata la corrispondenza con i pixel dell’immagine grafica prodotta dall’interfaccia che pilota la scheda DPB; anche quest’ultima è brevemente illustrata nel capitolo 6.
5.2 Risultati ottenuti
Prima di essere utilizzato al fine di collaudare la DPB, si è verificato, con l’ausilio di un oscilloscopio, il corretto funzionamento dell’Emulatore. Di seguito si riportano alcune immagini, acquisite in questa fase di prova, delle forme d’onda generate nelle due modalità di funzionamento.
Le fig. 5.21 e 5.22 illustrano le forme d’onda generate in seguito all’impostazione dell’utente delle due diverse modalità di testing ma in corrispondenza della stessa frequenza richiesta. In particolare in fig. 5.22 la presenza di picchi ravvicinati rende ragione della variabilità del periodo in modalità pseudo-random. Il numero di variazioni del periodo, infatti, dipende dal numero di bit della parola che si fanno cambiare, tre nel presente esperimento; ne segue che, in questo caso, tali variazioni saranno in numero di 23 = 8.
Fig.5.21 : Forma d’onda generata in modalità fixed-frequency; la frequenza, comeatteso, risulta stabile.
Si osserva come l’indicazione della frequenza sia diversa nei due casi. Ciò è motivato dal fatto che nella fig. 5.22, il suo valore dipende dall’istante di cattura dell’immagine; infatti data la variabilità della frequenza il valore visualizzato dall’oscilloscopio risulta fortemente instabile nella modalità pseudo-random. Per quanto riguarda la visualizzazione della frequenza ottenuta e del jitter può risultare interessante confrontare la diversa visualizzazione dei dati sul pannello di controllo nei due esperimenti presentati, fig. 5.23, 5.24.
Fig. 5.22 : Modalità pseudo-random: si noti la variabilità del periodo.
Fig. 5.23: Visualizzazione della frequenza realizzata e del jitter nella modalità fixed-frequency. Il jitter, come atteso, è nullo, ad indicare che la frequenza è stabile; un confronto con l’immagine acquisita tramite oscilloscopio, relativa all’esperimento condotto, fig. 5.21, dimostra la corretta visualizzazione dei dati.
Fig. 5.24: Visualizzazione della frequenza e del jitter nella modalità di pseudo-random testing; operando un confronto con i dati visualizzati tramite oscilloscopio, fig.5.22, si verifica il corretto funzionamento dell’emulatore.
Il visualizzatore di frequenza fornisce una diversa indicazione in quanto, come già anticipato, nella modalità fixed-frequency indica la frequenza ottenibile più vicina a quella richiesta, e nel presente caso l’architettura implementata consente di ottenerla con precisione; nella modalità pseudo-random frequency lo stesso indicatore visualizza la frequenza centrale della banda spazzata. Il jitter visualizzato è nullo nella prima modalità, ad indicare la generazione di impulsi a frequenza stabile, è invece pari al 9,59% nella seconda modalità, ad indicare che la banda di variazione è ampia quasi il 20% della frequenza centrale; è questo un tipico caso di dilatazione della banda dovuta ai vincoli imposti dall’architettura implementata sull’FPGA.
Sempre con l’ausilio dell’oscilloscopio, con la determinazione del periodo massimo e di quello minimo, è stata verificata la corretta visualizzazione del jitter, relativo ai canali indagati, sul pannello di controllo dell’Emulatore.
Numerose verifiche, effettuate variando la frequenza e la modalità di funzionamento, hanno dimostrato l’affidabilità dello strumento di testing.
Si riporta un’ulteriore immagine prodotta in modalità pseudo-random, fig. 5.25, in cui è evidenziato che il sistema risulta adattivo; il numero di periodi variabili è in questo caso inferiore, poiché il numero di bit che cambiano è due; ne segue un numero di variazioni del
periodo quantificabile come: 22 = 4. Il risultato è consistente con le aspettative di progetto in
quanto la frequenza in esame è superiore a quella dell’esperimento precedente; infatti, come già introdotto nel capitolo 4, il numero di bit che occorre far cambiare nella parola di caricamento del contatore, in modalità pseudo-random, aumenta al diminuire della frequenza impostata.
Fig. 5.25 : Modalità pseudo-random applicata a frequenze superiori; il numero di bit che si prevede di far cambiare all’interno della parola di caricamento del contatore è inferiore al caso precedente di fig. 5.11.
Riassumendo l’estensiva fase di verifica dell’Emulatore ha dimostrato che il sistema progettato è in grado di produrre una collezione di canali, la cui frequenza può essere programmata in modo individuale dall’utente attraverso una semplice interfaccia realizzata mediante l’applicativo Labview. Inoltre, è stata verficata la corretta generazione del segnale a frequenza variabile in modo pseudo-random. In particolare, l’interfaccia di controllo adatta correttamente il numero di bit della parola di controllo della frequenza che vengono modificati in modo pseudo-casuale, in modo tale da garantire, almeno finché ciò è possibile, che il jitter massimo relativo sia indipendente dalla frequenza impostata.
L’Emulatore di sensori SPAD progettato permette quindi di generare in modo efficace e controllabile un ampio insieme di condizioni di testing per il sistema di acquisizione ed elaborazione.
