L’hardware
Capitolo 2
L’hardware
Per realizzare il CF-P/R abbiamo utilizzato una scheda già progettata e realizzata dalla Seed. Di questa scheda non era però mai stato verificato il funzionamento, quindi una parte molto rilevante di questo progetto di tesi è stata la verifica del corretto funzionamento e interfacciamento tra le parti, ovvero il “debug” dell’hardware, facendo varie prove con piccole parti di codice scritte ad hoc in modo da fare una analisi che “isolasse” i componenti hardware della scheda che si stavano analizzando in quel momento, come per esempio una verifica del corretto settaggio del codec (che in fase di boot deve essere programmato dal DSP tramite una opportuna sequenza di dati che gli vengono forniti, in modo da svolgere quelle funzioni che a noi servono) oppure una verifica del corretto interfacciamento del DSP con la sua memoria locale SRAM, o altro. Ma di come abbiamo operato il debug della scheda parleremo più avanti nel capitolo, riferendoci di volta in volta al componente hardware che avevamo preso in esame nel proseguire con l’analisi. Questo lavoro è stato necessario perché in fase di progetto hardware può capitare di non interpretare in modo “ottimo” i data-sheet di alcuni dispositivi complessi quali i DSP, dovendo successivamente, una volta verificato l’effettivo comportamento e potenziale del dispositivo, “ripensare” alcune scelte progettuali alla luce delle sperimentazioni sul campo del componente stesso.
Pur dunque non commettendo errori progettuali, che comunque sempre possono esservi, è sempre necessaria, ai fini di ottimizzare il progetto, una verifica sperimentale dello stesso, prima di poter decretare la definitiva “forma” del progetto.
La possibilità, inoltre, della sperimentazione “sul campo” delle soluzioni progettuali, consente di utilizzare il potente strumento del “debugging Sw”, che per dispositivi di nuova generazione permette l’utilizzo di strumenti Sw esterni per poter analizzare il comportamento dell’Hw progettato grazie alla possibilità dell’“On Chip Emulation”. Lo sviluppo del software (cioè del codice che poi gira nel DSP) è quindi andato di pari passo con l’analisi dell’hardware.
Come già accennato nel capitolo introduttivo riportiamo qui (questa volta con i nomi dei componenti effettivamente utilizzati) i vari elementi che si trovano a bordo del sistema:
1. DSP TMS320VC5401PG prodotto dalla Texas Instruments 2. Codec UDA1345TS prodotto dalla Philips
3. SRAM GLT6100L16LL 4. EPROM AT27LV512A
5. Registro di otto Flip Flop D- Edge Triggered 74LV574 6. Octal buffer/line driver (3-State) 74LV244
7. Due 74LV32 che hanno al loro interno quattro porte logiche OR
8. Un 74LV132 che ha al suo interno quattro porte logiche NAND triggerate 9. Tre stabilizzatori di tensione: un LM317, LM1117-3.3 e un LM117-1.8 10. Resistori e condensatori vari
Vediamo ora di presentare brevemente ciascuno di questi componenti, descrivendo anche il processo “debug” operato relativamente a quel componente.
L’hardware
memory bus) e ben tre bus dati (data memory bus). Questo processore ha dentro di sé un’unità aritmetico logica (ALU) con alto grado di parallelismo, logica hardware specifica per le più disparate operazioni, memoria sul chip e periferiche addizionali anch’esse sul chip stesso. Il segreto dell’elevata flessibilità e velocità di tale DSP risiede in un instruction set altamente specializzato.
Spazi di memoria dati separati dalla memoria programma permettono un accesso simultaneo ai dati ed alle istruzioni del programma, implementando l’alto grado di parallelismo. Due operazioni di lettura ed una di scrittura possono essere eseguite contemporaneamente nello stesso ciclo di istruzione. Istruzioni con memorizzazioni parallele ed istruzioni per applicazioni specifiche possono pienamente sfruttare tale architettura. Inoltre i dati possono essere trasferiti tra spazi di memoria dati e spazi di memoria programma, ovvero esistono delle istruzioni che permettono di scrivere dati nello spazio di memoria programma. Questo ha permesso la gestione della selezione che governa l’attivazione della flash card e della SRAM tramite una logica molto semplice, come verrà spiegato nei paragrafi successivi.
Tale parallelismo supporta un potente set di operazioni aritmetiche, logiche e di manipolazione dei bit, operazioni queste che possono essere eseguite in un unico ciclo macchina. Inoltre il ‘5401 include un meccanismo di gestione degli interrupt, di gestione di operazioni ripetute più volte e di chiamate a funzione.
2.1.1 Schema a blocchi del TMS320VC5401
Figura 1: Schema a blocchi del DSP
Vediamo ora di descrivere alcuni dei blocchi principali, dai quali derivano anche delle scelte di progetto.
Memoria
Il ‘5401 ha a bordo sia una memoria ROM che una memoria RAM per facilitare l’integrazione dell’intero sistema su un unico chip (cosa che come vedremo non sarà possibile nel nostro progetto e quindi ricorreremo all’uso di una SRAM e di una EPROM esterna).
L’hardware
nell’istante di reset hardware, l’esecuzione comincia alla locazione 0FF80h della ROM a bordo del chip. Questa locazione contiene un’istruzione di salto (branch) all’inizio del programma bootloader. Noi abbiamo usato questa opzione infatti, eseguendo il boot da EPROM esterna. Questa scelta è stata l’unica possibile in quanto la ROM interna del DSP non è una EPROM ma una ROM vera e propria e quindi questa, per essere caricata con il codice, dovrebbe uscire mascherata con il codice già a livello di fonderia. Questa scelta senz’altro più costosa nella produzione di poche migliaia di pezzi potrebbe rivelarsi vantaggiosa in previsione della vendita di centinaia di migliaia di pezzi, sia per il fatto che verrebbero maggiormente ammortizzati i costi fissi della fonderia e quindi il singolo pezzo potrebbe venire a costare meno di un tale DSP non mascherato sommato ad una EPROM esterna, sia per una maggiore possibilità di integrazione all’interno di sistemi portatili (non s ha lo spazio in più occupato dalla EPROM).
Ad ogni modo, per impostare il DSP in modo che all’avviamento attivi il suo bootloader, basta portare il pin MP/MC a massa, ovvero Vss:
Quindi si ricade nel caso in cui tale pin è basso nell’istante di reset hardware e si attiva l’utilizzo del bootloader.
In fase di caricamento del codice sono stati riscontrati dei problemi non previsti nell’utilizzo del bootloader della ROM interna che non riusciva a caricare il codice nella RAM interna per poter essere eseguito. Tale problema, già noto alla Seed prima della realizzazione di questo progetto fu superato operando nel modo seguente:
1. Utilizzo del bootloader presente nelle ROM per andare a caricare un codice molto semplice immagazzinato nelle prime locazioni della EPROM. Tale codice non è altro che un bootloader riscritto, però in questo caso funzionante.
2. Dopo avere caricato il bootloader riscritto nella RAM interna questo viene usato per andare a ricercare nella EPROM il codice del programma vero e proprio, in modo da caricarlo correttamente nella RAM interna per mandarlo in esecuzione.
L’hardware
Tramite il programma bootloader riscritto si va a caricare il codice dalla sorgente scelta, in questo caso la EPROM.
Il bootloader standard del 5401 di per sé permetterebbe diversi modi per scaricare il codice, questo per soddisfare le svariate possibili richieste del sistema:
• Parallelo da EPROM in modalità a 8 o 16 b • Parallelo dallo spazio di I/O in modalità a 8 o 16 b • Boot seriale da porte seriali in modalità a 8 o 16 b • Boot dall’interfaccia dell’Host-port
Dal momento che, ovviamente, nel CF-P/R non si utilizza la ROM interna del DSP per contenere il codice del programma ma si usa una EPROM esterna, si usa la prima delle quattro soluzioni proposte per il caricamento del codice. Del resto le porte seriali sono impegnate in quanto collegate col codec perché la trasmissione dei campioni tra codec e DSP è fatta serialmente, secondo le specifiche del codec della Philips. Inoltre anche anche l’Host-port è impegnata in quanto tramite tale interfaccia si gestiscono i comandi esterni (quelli che permettono di controllare la registrazione, la riproduzione, la frequenza di campionamento, ecc., ma di questo parleremo più approfonditamente nel quinto capitolo dedicato alla gestione comandi).
RAM a bordo
Il ‘5401 contiene una memoria RAM ad accesso duale (DARAM) delle dimensioni di 8k 16× b. La DARAM è composta da due blocchi da 4 kword ciascuno. Ogni blocco della DARAM può supportare fino a due letture in un ciclo, oppure una lettura e una scrittura in un ciclo. Questo permette che il codice sia estratto da un blocco mentre sono letti i valori di due dati dall’altro blocco, il tutto senza incorrere in perdite di cicli. La presenza di tale RAM interna nel DSP fa sorgere l’interrogativo sul perché si sia inserita nella scheda
buffer per la flash card e si è visto che serve un buffer più grosso come dimensioni e quindi la RAM interna al DSP da 8 kB (si considera solo un blocco perché essendo i due blocchi non consecutivi nello spazio di memoria l’uso di entrambi i blocchi di memoria come buffer sarebbe stato troppo difficoltoso) non sarebbe stata sufficiente. Gli esperimenti fatti che hanno portato a formulare tale scelta di progetto saranno spiegati meglio più avanti in questo capitolo quando si parlerà della SRAM esterna.
Periferiche a bordo del chip necessarie al nostro progetto Tra le periferiche presenti nel chip ricordiamo:
• Una Host-port interface a 8 b (HPI8)
• Due porte seriali multicanale bufferate (McBSPs)
• Un generatore di clock con un anello ad aggancio di fase (PLL) • Due timer hardware
• Un generatore di stati di attesa programmabile via software con un bank-switching programmabile
• Un controllore di accesso diretto alla memoria (DMA)
Delle prime due periferiche abbiamo già parlato e ricordiamo che la prima la abbiamo utilizzata per gestire i comandi dall’esterno, mentre la seconda serve per scambiare i dati serialmente con il codec e gestirne la temporizzazione.
L’hardware
impostiamo, tramite il codice, il registro CLKMD in modo da moltiplicare internamente tale frequenza per cinque. Si ha quindi che la CPU interna del DSP lavora, dopo una prima fase di inizializzazioni, con una frequenza di 50 MHz. Il quarzo dovrebbe lavorare alla sua frequenza fondamentale, e risonante parallelo, con una effettiva resistenza serie di 30 Ω e potenza dissipata di 1 mW. La connessione del circuito richiesto, che consiste nel quarzo e in due capacità di carico, è mostrata nella seguente figura 4. Le due capacità di carico, C1 e C2,
dovrebbero essere scelte in modo tale da soddisfare la seguente equazione. CL
nell’equazione è il carico specifico per il quarzo scelto.
2 1 2 1 C C C C CL + ⋅ =
La frequenza di clock generata in questo modo, cioè con il PLL interno, non può essere maggiore di 20 MHz o minore di 10 MHz, secondo le specifiche del DSP 5401. Il collegamento col DSP è il seguente:
Figura 4: Generazione del clock
Figura 5: Collegamento del quarzo al DSP
Si vede che il clock generato dall’oscillatore del DSP va al piedino sysclk; questo è il clock del sistema, infatti viene mandato anche al connettore del JTAG tramite il quale si è gestita tutta la fase di debug e realizzazione codice, grazie al sistema di sviluppo Code Composer della Texas Instruments.
Vediamo ora le funzioni del generatore di stati di attesa programmabile:
Software-Programmable Wait-State Generator
Il generatore di stati di attesa programmabile del ‘5401 può allungare la durata del tempo di accesso al bus esterno fino a quattordici cicli macchina. I dispositivi che richiedono più di quattordici stati di attesa possono essere interfacciati gestendo opportunamente la linea hardware del READY. Quando tutti gli accessi esterni sono configurati in modo da non richiedere alcuno stato di attesa, i segnali di clock mandati internamente al Wait-State Generator sono
L’hardware
di attesa (da 0 a 7) da inserire per accessi alla memoria esterna in cinque diversi range di indirizzi. Questo permette un differente numero di stati di attesa per ognuno dei cinque range di indirizzi. In più il bit chiamato Software Wait-State Multiplier (SWSM), che sta nel Wait-State Control Register (SWCR), definisce un fattore di moltiplicazione di uno o due per il numero degli stati d’attesa. Al reset il Wait-State Generator è inizializzato in modo da utilizzare sette stati di attesa per tutti gli accessi alla memoria esterna. I campi del registro SWWSR sono mostrati nella seguente figura:
Figura 6: SWWSR
Le parti di memoria alle quali corrispondono i campi di tale registro sono definite nella figura seguente:
Nel capitolo dedicato al codice si vedrà come settare questo registro.
Delle altre periferiche presenti sul DSP, ovvero i due timer hardware ed il controllore di accesso diretto alla memoria (DMA), non si parlerà in quanto non sono state utilizzate nel nostro progetto.
2.1.2 Specifiche elettriche e alimentazioni
Naturalmente perché tutto il progetto funzioni correttamente devono essere rispettati i valori delle alimentazioni, ovvero stare in un certo range intorno al valore ottimale, e non superare i valori massimi consentiti. Stesso discorso vale per il range di variabilità delle tensioni di ingresso e di uscita. Si devono quindi rispettare le seguenti specifiche:
L’hardware
Figura 9: Specifiche alimentazioni e tensioni di ingresso/uscita del DSP (parte 2)
Si vede bene che sono presenti due diverse alimentazioni (valori riportati rispetto alla VSS): una a 3.3V per la parte relativa alle logiche esterne low voltage, alla SRAM, alla
EPROM, alla flash card e alle periferiche del DSP, e una a 1.8V per il core del DSP. Dallo schema relativo alle alimentazioni si vede che tali tensioni vengono ottenute tramite una sequenza di stabilizzatori di alimentazione che di volta in volta riducono la tensione al valore necessario. Infatti dalla figura 10 si vede che la
Figura 10: Circuito di alimentazione
tensione di alimentazione del sistema (che da specifiche di progetto posso considerare variabile da circa 8 V a 12 V, valori approssimativi) viene stabilizzata da un primo
stadio con LM317 che fornisce 5 V che in realtà non servono a nessun dispositivo presente sulla scheda. Tale stabilizzatore è stato messo per non sovraccaricare di lavoro gli stadi di stabilizzazione successivi. Da 5 V si passa a 3.3 V tramite un LM1117-3, e con tale tensione si va ad alimentare praticamente ogni componente della scheda tranne il core del DSP. Infine da 3.3 V si passa, tramite un LM1117-1.8, a 1.8 V, appunto per il core. La figura seguente riporta i massimi valori consentiti sia di tensioni di alimentazione, che di tensioni di ingresso e uscita, che di temperatura. La catena di stabilizzatori vista poc’anzi dovrebbe premunirci dal superare tali range di tensione, proteggendo il circuito da eventuali sovratensioni (grazie anche a un primo stadio con LM317), mentre il range di temperature è sufficientemente ampio da non rappresentare un problema.
Figura 11: Valori assoluti massimi consentiti
2.1.3 Prima fase di debug: le alimentazioni e il clock
L’hardware
Figura 12: Vista dall’alto del DSP
Una delle prime cose fondamentali nel debug della scheda è stata la verifica, tramite l’utilizzo di un semplice tester utilizzato come rivelatore di cortocircuiti, delle connessioni delle due alimentazioni e della massa ai rispettivi piedini del DSP. Le alimentazioni sono infatti due, come visto poc’anzi, ovvero una per le periferiche (DVDD) a 3.3V e una per il core (CVDD) a 1.8V. La massa, cioè la GND del nostro
sistema è rappresentata dal pin VSS. Si partì da un’ispezione delle connessioni delle
alimentazioni perché, una volta constatato che la scheda in sé non funzionava, bisognava operare un’indagine seguendo una certa logica, per non compiere più volte le
stesse operazioni e per non tralasciare nulla che possa risultare significativo. Secondo quindi un metodo di indagine più che ragionevole la prima cosa da fare è assicurarsi che le alimentazioni arrivino correttamente al sistema in esame, in questo caso al DSP. Dall’indagine risultò che il DSP era correttamente alimentato.
Il secondo passo fu quello di verificare che il clock arrivasse correttamente al processore, ovvero che l’oscillatore interno effettivamente funzionasse come tale, senza anomalie. Per procedere a questa prova si utilizzò l’oscilloscopio e si andò a vedere il segnale sul pin sysclk. Anche qui si ottenne un risultato positivo, il clock funzionava.
2.2 Interfacciamento tra DSP e codec
Il clock (che ricordiamo nel nostro caso è generato con un quarzo da 10 MHz) viene internamente moltiplicato, grazie a un PLL, per un fattore di moltiplicazione programmabile, che come già detto vale cinque per il CF-P/R e quindi la circuiteria interna del DSP lavora con una frequenza di 50 MHz; ovvero il tempo impiegato a compiere un’istruzione (che impiega un colpo di clock) è di 20 ns.
Lo stesso clock da 50 MHz viene poi diviso, tramite una circuiteria apposita, per generare i segnali che andranno a pilotare il codec. Tale circuiteria fa parte delle Multichannel Buffered Serial Port (McBSP), ovvero delle porte seriali potenziate presenti su tale famiglia di DSP TMS54XX, che permettono la generazione di clock programmabili tramite circuiti che dividono un clock in ingresso che può provenire dall’esterno o dalla CPU.
Il circuito in questione è il Sample rate generator schematizzato nella figura 13 sottostante:
L’hardware
Figura 13: Sample rate generator
Di questi circuiti ce n’è uno per ognuna delle due porte seriali dedicate alla generazione delle cadenze (BCLKX0 e BCLKX1 sono le uscite CLKG per le porte 0 e 1, BFSX0 e BFSX1 sono le uscite FSG per le porte 0 e 1), mentre altre due porte seriali sono dedicate alla trasmissione e ricezione dei bit che compongono i campioni (BDX0 e BDX1 sono le uscite sulle quali si trasmettono i dati per le porte 0 e 1, BDR0 e BDR1 sono gli ingressi sui quali si ricevono i dati per le porte 0 e 1).
Secondo quanto impostato da codice, attraverso il multiplexer arriva al primo divisore programmabile il clock interno della CPU, nel nostro caso 50 MHz; questo vale per entrambe i circuiti sample rate generator di entrambe le porte seriali dedicate. Quindi il circuito semplificato utilizzato per generare i segnali che servono a sincronizzare il codec col DSP risulta essere:
Figura 14: Generazione dei segnali per il pilotaggio del codec
Nel capitolo dedicato al codice vedremo come saranno programmati tali divisori in modo da fornire al codec dei segnali coerenti al protocollo di trasferimento dati.
Questi segnali sono necessari alla corretta temporizzazione e sono: l’MCK1, il BCLKX0 (collegato al piedino BCK dell’UDA) e il WS.
L’hardware
Figura 15: Collegamenti tra il DSP e il codec
1. L’MCK1 che, come si vede dalla figura 16, è direttamente collegato con il sysclk del codec, fornisce naturalmente il clock per il codec. Questa non è la frequenza di campionamento come si potrebbe pensare. Infatti, come vedremo parlando dell’UDA1345TS, tale componente implementa anche della logica che permette di fare filtraggi, controllo volume, funzioni mute, ecc. e quindi è un vero e proprio circuito digitale, all’interno del quale il segnale che entra nel pin sysclk viene opportunamente diviso per ricavare la frequenza di campionamento.
2. Il BCK fornisce il clock per il sincronismo di bit. Si ricorda infatti che la trasmissione dati tra DSP e codec è seriale e quindi si ha bisogno di un segnale che sincronizzi e cadenzi il trasferimento di ogni singolo bit.
Figura 17: BCK e WS
3. Il WS fornisce il sincronismo di parola. I dati vengono campionati a 16 b; si hanno quindi due dati da 16 b per ogni periodo di campionamento (visto che si gestisce un segnale stereo). C’è quindi bisogno di un segnale (la cui informazione questa volta non sta nella transizione ma bensì nel livello) che dica quando si è finito di ricevere l’ultimo bit di una parola relativa ad un canale, ovvero l’ultimo bit del campione prelevato su quel canale (per es. il sinistro), e si comincia a ricevere il primo bit della parola relativa all’altro canale (per es. il destro). Per fare ciò si va a testare il pin di ingresso BIO del DSP (esiste un’istruzione che permette di fare salti condizionati in dipendenza del livello logico sull’ingresso di tale pin) che si usa proprio a tal fine, per distinguere i livelli. È necessario infatti utilizzare questo semplice meccanismo hardware esterno al DSP per poter rilevare la corretta informazione relativa al WS, informazione che non è altrimenti rilevabile tramite il solo DSP, essendo tale WS un clock generato via hardware indipendente dall’esecuzione del codice, e che quindi si può solo rilevare via hardware. Si verifica dunque lo stato del segnale WS che si rileva direttamente sul pin BIO per sapere se in ingresso al
L’hardware
Figura 18: Collegamento tra WS e BIO
2.3 Il codec scelto per il progetto - UDA1345TS - Philips
L’UDA1345TS racchiude dentro di sé due convertitori analogico/digitale e due convertitori digitale/analogico, in quanto può lavorare su due canali contemporaneamente (è un codec stereo). Ha funzioni di processamento audio in digitale (filtri high pass per togliere l’offset in continua sul segnale in ingresso, ecc.) ed impiega tecniche di conversione di bitstream di dati, ovvero riceve e manda dati in maniera seriale; anche gli stessi campioni acquisiti e quantizzati vengono inviati al DSP in modo seriale, come del resto il DSP reinvia serialmente i dati al codec nel quale vengono ricostruiti in campioni da 16 b e riconvertiti in analogico. Nella figura seguente si presenta lo schematico del codec inserito nel CF-P/R:
L’hardware
Inoltre l’UDA1345TS ha vari tipi di formati di dati e di lunghezza di parole, fino a 24 b. Richiede basse tensioni di alimentazione ed ha bassi consumi, quindi può essere tranquillamente usato nella nostra applicazione dove è richiesta un’elevata portabilità. A tale dispositivo va fornita un’alimentazione che può variare da 2.4 V a 3.6 V. In particolare noi forniamo, tramite la catena di stabilizzatori precedentemente analizzata nel paragrafo dedicato al DSP, una tensione di 3.3 V. Anche l’SNR (Signal to Noise Ratio) è sufficientemente elavato da garantire una qualità sonora tipo CD, si hanno infatti tipicamente 96db per l’ADC e 100db per il DAC, ad una frequenza di campionamento di 39,062 kHz (cioè quella usata nel nostro progetto). Riportiamo qui di seguito le caratteristiche dell’UDA:
Per inserire tale codec nella schedina del CF/PR è stato utilizzato lo schema consigliato sul data-sheet stesso, senza apportare variazioni di rilievo. Si riporta quindi lo schema mostrato sul data-sheet:
L’hardware
2.3.1 La fase di debug dell’UDA1345TS
Un metodo molto semplice per testare il corretto funzionamento del codec e per vedere se la sua procedura di inizializzazione è andata a buon fine, è quello di fare un processo di Input/Output (I/O) senza avere nel mezzo nessuna elaborazione che, a priori, potrebbe contenere intrinseci problemi a giustificare una non corretta “uscita” del codec, rischio che non si corre nel momento in cui si rimanda all’uscita semplicemente quanto acquisito in ingresso. Il codice per tale processo corrisponde a:
Left_Out = Left_In Right_Out = Right_In
cioè nell’assegnazione della variabile di ingresso alla variabile di uscita. Nella variabile di ingresso viene precedentemente copiato il dato che viene ricevuto dalla seriale, cioè il campione convertito dal codec, mentre la variabile di uscita viene mandata alla seriale che porta il dato al codec per essere convertito in analogico. Tale processo quindi non pesa a livello computazionale ed è un ottimo stratagemma per vedere se il codec lavora correttamente. Ciò avviene quando si vede in uscita quello che viene mandato in ingresso. Le prime prove si fecero usando un generatore di segnale sinusoidale e l’uscita (si vide) seguiva l’ingresso molto fedelmente. La prova diede esito positivo e quindi il codec funzionava correttamente.
2.4 Utilizzo di SRAM esterna - SRAM GLT6100L16LL
Notiamo innanzitutto che la SRAM viene mappata nello spazio di memoria programma come detto già precedente e come verrà illustrato nel paragrafo dedicato al circuito per la generazione dei select per la flash card e per la SRAM, nel paragrafo dedicato alla “glue logic”. Lo schematico per la SRAM nel nostro circuito è il seguente:
Figura 22: SRAM
Tramite il solo segnale /RW proveniente direttamente dal DSP, che discrimina i cicli di lettura da quelli di scrittura secondo le seguenti specifiche:
L’hardware
durante la lettura della SRAM, cioè quando R/W è alto (ecco perché l’/OE si ottiene semplicemente negando l’R/W, visto che l’/OE è attivo basso).
Tale SRAM svolge la funzione di buffer per la flash in quanto, come si vedrà meglio nel capitolo 3, riceve dal DSP i campioni che arrivano in ingesso dal codec e li mette in indirizzi di memoria della SRAM consecutivi, che si incrementano via via. Da tale buffer i campioni verranno trasferiti alla flash sotto forma di burst non appena la flash sarà pronta, in modo tale che tutta l’operazione non infici (impegnando il DSP per troppo tempo) la ricezione del campione successivo. Questo è quello che avviene in fase di registrazione. In riproduzione avviene naturalmente il processo inverso: dalla memoria flash vengono trasferiti i campioni in blocco alla SRAM, dalla quale vengono prelevati con una tempistica scandita dalla frequenza di campionamento e trasferiti tramite il DSP al codec per essere convertiti nel segnale analogico di partenza. È quindi evidente che la SRAM serve solo da buffer. Verrebbe però da chiedersi come mai usare una SRAM esterna (e quindi aumentare i costi di tutto il progetto, sia per la SRAM stessa, che per lo spazio sul PCB, che per l’uso di logica esterna atta a gestirne la selezione) quando, come visto prima, il DSP ha a bordo una SRAM che non viene neanche impegnata più di tanto, in quanto le procedure portano solo alla memorizzazione di un dato in una memoria esterna (non sono computazionalmente pesanti). Inoltre la flash card medesima ha al suo interno un buffer che è gestito da un controllore, che potrebbe teoricamente svolgere la funzione realizzata dalla SRAM esterna.
2.4.1 La fase di debug: è necessaria una SRAM esterna?
Ma allora se è presente una cache all'interno della flash card perché nel progetto si è usata una SRAM (tra l'altro esterna, e quindi più costosa rispetto a quella interna al DSP)? Questo è dovuto al fatto che la flash card non è abbastanza veloce nel trasferire i dati dal buffer interno, una volta riempito completamente, alla parte fisica della memoria. Ricordiamo che per non perdere i campioni tra una acquisizione e l'altra la
card può impegnare il DSP (e quindi rispondere attivando il READY in tempo utile) al massimo per un tempo pari a metà del periodo di campionamento che corrisponde a
Hz 5 . 39062 2 1
⋅ , ovvero 12.8 µs. Questo è il periodo di campionamento se si lavora con
segnali stereo e banda massima, se no se si lavora con segnali mono allora il periodo nel quale il DSP può compiere le sue operazioni raddoppia, diventa 25.4 µs perché sparisce il due al denominatore della formula precedente. Del resto se si rinuncia alla banda massima e si accetta di lavorare a 24414.06 Hz di frequenza di campionamento i tempi precedentemente indicati raddoppiano (naturalmente sia nel caso stereo che mono). Questi tempi sono troppo brevi per le flash, le quali dovrebbero scaricare il loro buffer interno completamente in questi intervalli temporali tra un campione e l'altro.
Ciò si è evinto dal fatto che si è visto, in fase di progetto, che il segnale audio, che veniva inviato al sistema per registrarlo nella flash, veniva riprodotto non fedelmente ma con delle microinterruzioni, dei piccoli click (riprodotto perché si è sviluppato il codice in modo tale che il campione acquisito in fase di registrazione andasse sia nella SRAM per poi essere memorizzato direttamente nella flash, sia di nuovo verso il codec per essere riconvertito audio e mandato verso l'esterno). Questi click sono proprio i campioni persi durante la registrazione, perché nel momento in cui la flash scarica il buffer, il READY (segnale che esce dalla flash card che segnala quando quest’ultima è pronta a fare un trasferimento) è disattivato (cioè la flash è occupata) e quindi non è pronta per ricevere altri campioni da mettere nel proprio buffer interno e quindi il sistema, facendo inevitabilmente un polling (gestione a controllo di programma) sul READY della flash card, non può far altro che perdere il nuovo campione che arriva perché la flash card non è in grado di asserire il READY in tempo utile.
Questo problema si è risolto con l'utilizzo di una SRAM esterna alla flash card come buffer, infatti così facendo quando si copia una serie di campioni dal buffer di SRAM
L’hardware
8 ) (byte SRAM Buffer Dimensioni TCAMPIONAMENTO ⋅dove l’otto al denominatore dipende dal fatto che stiamo trattando un segnale stereo con i campioni a 16 b e quindi a ogni periodo di campionamento si immagazzinano quattro byte. L’ulteriore divisione per due dipende dal fatto che viene trasferito dalla SRAM alla flash card solo metà buffer per volta, perché nell’altra metà buffer si continua il processo di immagazzinamento dei dati provenienti dal codec. Tale meccanismo verrà illustrato meglio nel capitolo dedicato al codice.
L’utilizzo di tale SRAM esterna non sarebbe stato teoricamente necessario servendosi di una compact flash card con presente al suo interno un buffer di memoria dual-ported, perché permettendo quest’ultimo degli accessi contemporanei in lettura e in scrittura non avremmo avuto il problema del READY tenuto disattivo durante tutto il trasferimento dati dal buffer interno alla parte di memoria di massa della flash card. Si è optato comunque per la scelta di una memoria esterna per due fondamentali motivi:
• Non tutte le compact flash card esistenti in commercio hanno un buffer di memoria interno dual-ported e quindi non usando una memoria esterna non avremmo reso il nostro progetto compatibile a una parte (anche se piccola) delle compact flash esistenti, soprattutto le più vecchie.
• In fase di debug si è sperimentato che alcune flash card davano problemi pur avendo un buffer di memoria interna dual-ported, si sentiva cioè in riproduzione quel “click” che era il segnale della perdita di campioni. Non diedero invece alcun problema le compact flash card con buffer interno dual-ported con caching capability
Quindi, avendo deciso di usare una SRAM esterna alla flash card, perché non usare quella interna DSP?
Non si poté usare la SRAM interna al DSP perché questa non ha dimensioni sufficienti a garantire il trasferimento nei tempi consentiti. Difatti la SRAM utilizzabile (un blocco solo come buffer) presente nel TMS320VC5401 è di 8 kB mentre la nostra SRAM
esterna è di 64 kword, anche se non viene utilizzata interamente come buffer ma si decide con una variabile da codice quanta parte utilizzarne.
Si sono fatte delle prove e si è visto che riducendo anche solo di poco le dimensioni del buffer per la flash, tramite la variabile di cui sopra che si chiama “Dim_Buffer_Sram”, i trasferimenti dal buffer di SRAM alla flash card diventavano troppo frequenti e non venivano più rispettati i tempi della flash card che non riusciva più ad essere pronta abbastanza velocemente. Questo perché con un buffer di SRAM più corto i trasferimenti durano di meno ma sono più fitti. Il problema di risposta della flash card dipende proprio da quanto sono fitti questi trasferimenti, ovvero quanto tempo ha a disposizione la flash card per compiere le sue operazioni. Sappiamo da prima che è di:
8 ) (byte SRAM Buffer Dimensioni TCAMPIONAMENTO ⋅
Quindi nel nostro caso se decidessimo di sfruttare tutta la SRAM che abbiamo a disposizione, ovvero 128 kB (che corrispondono a 64 kword), si avrebbe un tempo intercorrente tra due trasferimenti dati consecutivi tra SRAM e flash card pari a:
ms s s s 12.8 16384 209715.2 209.7 8 1024 128 8 . 12 µ ⋅ ⋅ = µ ⋅ = µ ≅ essendo TCAMPIONAMENTO = 12,8 µs
che si è visto sperimentalmente essere un tempo più che sufficiente per le flash card, anche per quelle più lente.
Viceversa volendo usare la SRAM da 8 kB del DSP si otterrebbe un tempo intercorrente tra due trasferimenti dati consecutivi tra SRAM e flash card pari a:
L’hardware
Che si sono rivelati insufficienti alla nostra applicazione, causando il solito problema di perdita dei campioni.
Per vedere come variava la risposta del sistema in base a questo parametro (ovvero la lunghezza del buffer di SRAM) è stato sufficiente assegnare alla variabile Dim_Buffer_Sram diversi valori, visto che il codice è stato concepito per autoregolarsi in funzione di questo parametro. Attualmente a tale variabile è assegnato da codice il valore di 0x4000, ovvero 16384 (16 kword). Il comando è:
asm("Dim_Buffer_Sram .set 04000h");//Max Dim Sram Buffer=4000h
Cioè è stato impostato il buffer di SRAM esterno affinché valga 32 kB (i trasferimenti sono sempre a 16 b), che corrisponde ad un tempo intercorrente tra due trasferimenti dati consecutivi tra SRAM e flash card pari a:
ms s s s 12.8 4096 52428.8 52.4 8 1024 32 8 . 12 µ ⋅ ⋅ = µ ⋅ = µ ≅
Così impostato il sistema funziona correttamente. Provando a ridurre le dimensioni del buffer ritorna il problema della perdita dei campioni.
Del resto si è deciso che le dimensioni del buffer possano essere esclusivamente pari a una potenza di due. Questa scelta dipende dal fatto che la variabile Dim_Buffer_Sram viene usata per fare un test ad ogni ciclo per capire quando si è arrivati in fondo al buffer ed eventualmente reinizializzare il puntatore che scorre le locazioni della SRAM all’inizio del buffer stesso. Se le dimensioni di tale buffer non fossero corrispondenti ad una potenza di due quando si arriva in fondo al buffer si troverebbe che il contatore che viene usato per contare le locazioni di memoria scorse nel buffer ha assunto un valore che non è una potenza di due. Fare un test su un dato così fatto è più impegnativo che su un dato che è una potenza di due perché nel secondo caso basta un semplice AND, mentre nel primo c’è bisogno di logica più complessa, pienamente gestibile dalla macchina ma computazionalmente più pesante; del resto in fase di progetto è meglio cercare di elaborare già da subito un codice il meno pesante possibile, non sapendo
ancora con precisione quale potrebbe essere l’esatto comportamento della macchina. Questa è una norma generale sempre valida per il progettista.
Ciò detto serve per spiegare come mai il valore successivo che il buffer avrebbe potuto assumere nelle prove di riduzione delle sue dimensioni non sarebbe potuto essere altro che 16 kB (essendo 32 kB la dimensione attuale), che poi corrisponde al doppio delle dimensioni della SRAM del DSP utilizzabile come buffer. Dalle prove effettuate si è visto che già un buffer di 16 kB non è sufficiente per evitare il fenomeno detto e quindi la SRAM interna al DSP non può essere utilizzata.
Tali considerazioni si fecero a fine progetto, quando ormai tutto il funzionamento globale era stato testato, ma non si poteva del resto sapere in sede di progetto hardware che sarebbe stata necessaria una ulteriore memoria SRAM. È stata comunque inserita nella scheda perché, come si è già detto, tale scheda è stata progettata per più applicazioni e perché, comunque, rappresentava il primo step non ottimizzato, sul quale effettuare i test di ottimizzazione da approntare alla eventuale release definitiva di progetto.
2.5 Gestione dell’EPROM - EPROM AT27LV512A
Secondo le specifiche fornite dal manuale del DSP l’EPROM va mappata nello spazio di memoria dati esterna, anche se questo sembrerebbe un controsenso visto che contiene del codice programma. Ciò del resto non impedisce di mappare l’effettiva memoria dati esterna (ovvero la SRAM da 64 kword che si usa come buffer per la flash card, nonché la flash card stessa) anch’essa nello spazio di memoria dati, che potrebbe contenerle tranquillamente, avendo il bus di indirizzo per i dati ben 20 pin di indirizzo, riuscendo
L’hardware
Figura 24: EPROM
Il fatto che l’EPROM venga vista come una memoria dati si nota anche dal fatto che essa viene attivata tramite il Data Select (/DS), il quale è collegato sia all’Output Enable (/OE) sia al Chip Enable (/CE) dell’EPROM, che sono entrambe attivi bassi, come del resto anche il Data Select.
Vediamo che l’EPROM esterna è collegata, oltre naturalmente al bus di indirizzo A[0..15], anche al bus dati D[0..7], cioè è collegata solo agli 8 b meno significativi del bus dati in quanto l’EPROM ha solo 8 b di dati in uscita, usando quindi la modalità di trasferimento a 8 b (si veda il paragrafo dedicato alla ROM a bordo del DSP).
Si vede, dalle modifiche apportate all’hardware, che solo tramite il /DS si attiva l’EPROM per farle presentare in uscita i dati memorizzati. Il funzionamento del /DS è descritto nelle seguenti specifiche estratte dal manuale:
Figura 25: Specifiche sulla gestione del /DS da manuale
Per la lettura da una memoria esterna in fase di boot basta quindi solo collegare l’Output Enable (/OE) e il Chip Enable (/CE) dell’EPROM al /DS del DSP. Vediamo la temporizzazione dal manuale del DSP per la lettura da una memoria esterna:
L’hardware
Basta quindi impostare sul DSP i tempi di delay in modo da rispettare la temporizzazione dell’EPROM, per leggere i dati correttamente. Ovvero: vedendo che il /DS e il /MSTRB hanno la stessa temporizzazione basta impostare il DSP in modo tale che il ta(MSTRBL) sia almeno il tempo necessario all’EPROM per presentare dati stabili in uscita da quando va basso il /CE e l’/OE (va preso a riferimento il tempo massimo tra questi due).
I tempi di lettura per l’EPROM e la seguente temporizzazione richiesta sono riportati nelle due seguenti figure:
Figura 27: Tempi di lettura dell’EPROM
Come si è detto nell’EPROM va a finire il codice che viene poi fatto girare nel DSP a run time.
Si sono già visti anche i motivi che hanno portato alla scelta di mappare l’EPROM nello spazio di memoria dati esterna con il conseguente utilizzo del solo segnale /DS per abilitare l’uscita e per selezionare il chip.
Durante la fase di sviluppo, quando la scheda veniva connessa con il PC e quindi con l’emulatore tramite il JTAG, tale EPROM non serviva perché ogni operazione veniva gestita tramite l’emulatore del sistema di sviluppo Code Composer della Texas Instruments. Alla fine della fase di progetto però il codice deve poter essere caricato e reso utilizzabile dal DSP indipendentemente dalla connessione con l’emulatore. Ecco perché quindi il codice si carica su tale EPROM, non essendo sensato un sistema portatile che può funzionare solo collegato a un PC nel quale è installato un emulatore. Per caricare il programma basta inserire nell’EPROM il file *.out che viene dal risultato della compilazione e linkaggio del codice.
L’hardware
Questo registro di otto Flip Flop D-Edge Triggered 74LV574 viene usato per mantenere i dati verso i dispositivi ai quali è collegato svincolando il bus dati del DSP D[0..7] dal compiere tale operazione e quindi dando la possibilità al DSP (che lavora con un clock molto elavato, molto di più rispetto a quello del codec e rispetto ai tempi di risposta della flash card) di compiere i suoi calcoli rilasciando il bus dati.
Tale registro viene “clockato” dall’ OR fatto tra i segnali /IOS e /RW che provengono direttamente da piedini del DSP:
Figura 30: Collegamenti dell’/IOSTRB e del R/W al DSP
Nella figura seguente sono riportate le specifiche per l’/IOSTRB e l’R/W prese direttamente dal data-sheet del DSP:
Figura 31: Specifiche di andamento dell’/IOSTRB e del R/W da manuale
Si vede che tale registro viene quindi selezionato quando sia /IOS che R/W sono attivi, cioè sono al livello basso. E dalle specifiche del DSP si legge che R/W diventa basso ogni volta che si va a scrivere su un dispositivo, e quindi mandiamo il dato che vogliamo scrivere sul bus dati, mentre /IOS si attiva quando accediamo ad un dispositivo mappato nello spazio di I/O. Con il comando relativo di scrittura siamo andati ad indirizzare lo spazio di I/O (il comando in questione è il portw, si vedrà nel capitolo del codice).
Figura 32: Temporizzazione dell’accesso in scrittura allo spazio di I/O
Tale registro serve per mandare e mantenere i segnali MP2, MP3, MP4 verso il codec. Questi sono piedini multipurpose dell’UDA che vengono utilizzati nella fase di inizializzazione del codec per ricevere la sequenza di segnali corretta per la programmazione secondo le specifiche proprietarie; inoltre consentono di gestire in tempo reale funzioni di mute, deenfasi, power mode della parte ADC, dinamica di ingresso (se 1V rms o 2V rms) nonché un fattore di moltiplicazione della frequenza di campionamento rispetto a quella del master clock e altro. Tutte queste funzioni run time non sono utilizzate nel nostro progetto in quanto non sono necessarie, mentre rimane la necessità di avere questi piedini collegati per la programmazione. Inoltre tramite questo registro vengono mantenuti il _card_reset alla flash card e i segnali GPO0, GPO1,
L’hardware
influisce sui dati memorizzati nella memoria di massa interna. Viene usato in fase di inizializzazione quando si accende la macchina, per evitare che magari la flash possa partire da uno stato in cui non è pronta, non dare attivo il suo READY (che è hardware) e bloccare tutto il sistema. Questo problema si è incontrato infatti durante la fase di debug ed è probabilmente attribuibile ad una non corretta sequenza di fornitura delle alimentazioni alle varie componenti della scheda.
GPO0, GPO1, GPO2, GPO3 sono quattro pin che “avanzavano” nel registro degli otto flip flop e quindi vennero previsti general purpose qualora fosse stato necessario utilizzarli in fase di debug, facendo qualche modifica all’hardware, oppure qualora fossero serviti per altri progetti che sarebbero potuti essere implementati su tale scheda che ricordiamo essere molto generica e quindi potrebbe venire sfruttata per molteplici applicazioni.
In effetti GPO0 e GPO1 sono stati poi utilizzati nel progetto, come spiegato nel paragrafo successivo.
2.6.1 Fase di Debug: assegnazione del GPO0 e del GPO1
Nel processo di debug si è passati da una prima release del codice in cui l’accesso alla flash card era 8 b a una successiva release in cui l’accesso alla flash card era a 16 b, sia per quanto riguarda i registri interni che per quanto riguarda i dati. Ciò ha comportato una differente gestione dei segnali /CE1 e /CE2 che comandano rispettivamente l’accesso alla parte bassa ed alta del bus dati, modificando i collegamenti anche sulla scheda stessa e facendo un uso diverso della glue logic. Per questo motivo il GPO0 viene mandato in OR con il segnale /CEFLASH, generato da della logica di supporto che ha come ingressi /PS e A16, per andare a creare il /CE2. Inoltre anche il GPO1 viene mandato in OR con il segnale /CEFLASH, andando a creare questa volta il /CE1.
Figura 33: Circuito per la generazione di /CE1 e /CE2
Inizialmente questi due pin, /CE1 e /CE2, vennero messi in corto nello zoccolo della flash card perché non si pensava fosse necessario comandarli indipendentemente, e vennero collegati entrambe al /CEFLASH. Quando si vide che era necessario distinguerli vennero sfruttati i piedini general purpose a disposizione presenti nel registro 74LV574.
L’hardware
Questo Octal buffer/line driver (3-State) 74LV244 viene usato per far passare sul bus, al fine di essere letti, alcuni segnali provenienti dalla flash card: il Card detect, il Ready/Busy, il Writprot e il Voltsens. Tali segnali sono importantissimi perché sono gli unici attraverso i quali si può realizzare un corretto handshake tra flash card e processore, infatti è tramite questi segnali che ci si accorge quando la flash è pronta per una lettura o scrittura oppure si deve attendere e sospendere momentaneamente l’esecuzione del programma perché la flash è momentaneamente impegnata e non può rispondere alle richieste di trasferimento dati da parte del DSP. Vediamo nel dettaglio quali sono i segnali che si vanno a testare:
• Card detect
Si vede che tale segnale proviene direttamente dall’OR tra i piedini 25 e 26 della flash card. Dal manuale dello standard delle flash tali pin corrispondono ai segnali CD1 e CD2:
Figura 35: I segnali Card Detect 1 e 2
Come si vede dalla descrizione nel manuale della flash questi due piedini sono internamente connessi a massa nella flash card, tramite le vie dell’alimentazione. Quindi se la flash card è correttamente inserita nel suo zoccolo questi due segnali sono a livello basso, e quindi anche il Card detect è a livello basso. Si testa (via software) tale segnale per vedere se la flash card è correttamente inserita nel suo alloggio, viceversa il sistema si blocca, o meglio rimane in polling su tale controllo (si vedrà meglio nel capitolo dedicato al software).
• Ready/Busy
Tale segnale proviene dal pin 37 della flash card, come si vede dalla seguente figura estratta dallo schematico:
Figura 36: Il Readybusy dallo zoccolo della Flash Card
Si vede sul manuale dello standard delle flash che tale pin corrisponde al segnale RDY/-BSY:
L’hardware
livello basso. Non si testa tale segnale in quanto si è scelto, durante la stesura del codice, di verificare se la flash card è pronta o meno ad effettuare un trasferimento dati tramite il test su un registro di stato nel quale si tiene conto dello stesso segnale Ready/Busy tramite un bit. Il bit in questione del registro di stato è la copia del livello logico presente sul pin hardware.
Se il test su tale bit dà esito negativo, ovvero la flash card non è pronta, il sistema si blocca, o meglio rimane in polling su tale controllo (si vedrà meglio nel capitolo dedicato al software).
Nel manuale della flash poi è indicato che il sistema dovrebbe prevedere una resistenza di pull up su tale pin. In fase di progettazione hardware tale particolare era sfuggito e non si mise inizialmente tale resistenza di pull up. Durante la fase di debug però si osservò il problema che all’accensione del sistema, a flash card inserita, tale segnale READY rimaneva a livello basso e quindi era come se la flash fosse occupata. Ciò creava il problema di bloccare l’esecuzione del codice, visto che veniva testato in polling (non proprio questo segnale ma il suo equivalente nel registro di stato, come detto prima). Il problema si “risolveva” togliendo la flash card dal suo socket e reinserendola; infatti così facendo si rilevava, a card una volta reinserita, un READY a livello alto. Per cercare di risolvere la situazione allora si inserì la resistenza di pull up, modificando l’hardware, per vedere se ciò potesse risolvere il problema. Del resto quando si indaga su un problema è bene mettere ogni dispositivo nella sua condizione di funzionamento ottimale, in modo da restringere il più possibile il numero di variabili che possono portare ad un malfunzionamento. Tale accorgimento non diede del resto esito positivo e il problema del READY che restava basso rimase anche una volta inserita la resistenza di pull up.
Figura 38: Pull up sul pin Readybusy della flash card
Tale problema si è risolto sequenzializzando diversamente le alimentazioni, ovvero fornendo in ultimo l’alimentazione alla flash card che quindi vede già alimentato tutto il resto del sistema. Si fa in pratica quello che si faceva disinserendo e reinserendo la flash card nel suo zoccolo.
• Write Protect
Tale segnale proviene dal pin 24 della flash card, come si vede dalla seguente figura estratta dallo schematico:
Figura 39: Il Write Protect dallo zoccolo della flash card
L’hardware
Figura 40: Il segnale Write Protect secondo le specifiche da manuale
Come si vede dalla descrizione nel manuale della flash questo piedino indica quando la flash ha finito la fase di reset iniziale, all’accensione del sistema. In questa fase infatti non si dovrebbero effettuare scritture verso la flash e quindi sarebbe necessario un sistema di protezione dalla scrittura. Tale sistema non è implementato e quindi la fine della fase di inizializzazione viene segnalata soltanto mandando basso il WP. Tale segnale in realtà non si testa, benché il piedino sia stato collegato al 74LV244, perché si è visto che il sistema funziona correttamente anche senza eseguire controlli su tale segnale.
• Voltsens
Tale segnale proviene dal pin 33 della flash card, come si vede dalla seguente figura estratta dallo schematico:
Si vede sul manuale dello standard delle flash che tale pin corrisponde al segnale VS1:
Figura 42: Il Voltsens secondo le specifiche da manuale
Come si vede dalla descrizione nel manuale della flash questo piedino indica quando la flash può essere letta con una tensione di alimentazione di 3.3V. Se questo piedino non fosse letto a livello basso le letture con una Vcc = 3.3V non potrebbero essere considerate affidabili. Tale segnale in realtà non si testa, benché il piedino sia stato collegato al 74LV244, perché si è visto che il sistema funziona correttamente anche senza eseguire controlli su tale segnale.
Tale registro di otto Octal buffer/line driver (3-State) 74LV244 è in “trasparenza” quando ha un livello basso sul suo piedino G (19) mentre porta le uscite in alta impedenza (e quindi rilascia il bus) per un livello alto su G, come si vede nella figura seguente ricavata dal manuale:
L’hardware
Figura 43: Funzionalità 74LV244
Il segnale di abilitazione delle uscite che va a pilotare i piedini 1 e 19 del 74LV244 lo ottiene dall’OR fatto tra i segnali /IOS e /RD, dove l’/IOS proviene direttamente da un piedino del DSP mentre l’/RD viene generato nel modo mostrato nella figura seguente:
Figura 44: La generazione del /RD
Viene generato dallo stesso sistema sia l’Output Enable per la SRAM che il Read (/RD) che va nell’OR insieme all’/IOS, che ricordiamo si attiva (cioè va a livello basso) quando si indirizza un dispositivo mappato nello spazio di I/O tramite i comandi apposta. Quindi quando si fa una lettura si ha che se viene indirizzato lo spazio di memoria riservato alla SRAM (spazio di memoria programma) allora sul bus dati vanno a finire i dati presenti in SRAM all’indirizzo considerato. Se invece si compie una lettura indirizzando lo spazio di I/O (questi due spazi si distinguono perché ci sono dei comandi diversi a livello di codice) sul bus D[0:7] vanno i dati che si ricavano proprio da questo buffer nel momento in cui viene attivato, cioè posto in trasparenza.
L’hardware
2.8 Glue Logic – il collegamento tra le varie componenti
La logica utilizzata per gestire il circuito di reset del DSP, il clock, i collegamenti che permettono di selezionare la SRAM, l’EPROM, i due registri, e il /CE1 e il /CE2 della flash card è composta da due 74LV32 (integrato con quattro porte OR a due ingressi) e da un 74LV132 (integrato con quattro porte NAND a due ingressi con trigger di Schmitt).
2.8.1 Circuito di reset del DSP
Due AND triggerati vengono utilizzati anche per mantenere attivo all’accensione il reset (/RS) al DSP per un certo periodo di tempo legato alla costante di tempo formata da R4 e C6. Qui di seguito si vede il circuito di reset per il DSP:
Figura 45: Il circuito di reset per il DSP e il rigeneratore del clock
Le specifiche per quanto riguarda il pin di reset del DSP sono riportate qui di seguito:
Figura 46: Specifiche del segnale /RS del DSP da manuale
Poiché l’esecuzione ricomincia, dopo che il reset viene riportato a livello alto, dall’indirizzo 0FF80h della ROM e qui si trova l’istruzione di salto al programma bootloader (si veda il paragrafo precedente dedicato alla descrizione della ROM a bordo del DSP), allora il programma ricomincia, come all’accensione, caricando il codice presente nell’EPROM e facendo partire poi l’esecuzione di quest’ultimo.
Il piedino del reset viene portato all’esterno tramite il connettore che porta le alimentazioni oltre che gli ingressi analogici, le uscite analogiche e i comandi esterni, come mostrato nella seguente figura:
L’hardware
Dall’accensione al rilascio dell’/RS, considerando che il circuito RC ha costante di tempo: ms C R4× 6=1500×1⋅10 6 =1,5 = − τ
ed essendo le soglie del NAND triggerato corrispondenti a:
Figura 48: Soglie del NAND triggerato
si ha che passa un tempo pari a T, dove T si ricava dall’espressione seguente (supponendo il segnale di reset esterno non pilotato e quindi a livello alto per via del pull up):
(
)
⋅ ⋅ = ⇒ − = ⋅ ⇒ = − ⋅ ⇒ = − ⋅ − − ⋅ − − ⋅ − − 3 , 1 3 , 3 ln 10 5 , 1 2 3 , 3 3 , 3 2 1 3 , 3 1 3 , 3 1,5103 1,5103 3 T e e V e T T IH RC T quindi T = 1,397 msNOTA: VIH è stato preso pari a 2 V essendo la tensione di alimentazione di tali porte
2.8.2 Rigenerazione del clock
L’OR U5A che appartiene al 74LV32 viene utilizzato per rigenerare il clock generato dal circuito oscillatore interno al DSP; clock che di per sé non avrebbe i livelli ben definiti. L’OR con gli ingressi in corto funziona quindi come buffer digitale, ovvero rigeneratore di livelli. Il circuito è quello presentato nella figura 45 (sopra).
2.8.3 Generazione del CEDSPRAM, del /CE1 e del /CE2
Il circuito per la generazione di questi segnali si avvale della logica poc’anzi presentata oltre che dei piedini general purpose GPO0 e GPO1 disponibili nel 74LV574. Il circuito, dopo aver apportato le modifiche viste in fase di debug, risulta essere:
Figura 49: Circuito di generazione del CEDSPRAM, /CE1 e /CE2
L’hardware
Figura 50: Modifica apportata allo zoccolo della flash card per separare /CE1 da /CE2
Si vede dal circuito di figura 49 (sopra) che il NAND triggerato U4D funziona come inverter. Da ciò si ha che i segnali visti sono generati con la seguente tabella di verità: CEDSPRAM = /PS + A16
CEFLASH = /PS + /(A16)
/CE1 = CEFLASH + GPO1 = /PS + /(A16) + GPO1 /CE2 = CEFLASH + GPO0 = /PS + /(A16) + GPO0
Vediamo quindi ora l’andamento dei segnali A16 e /PS per capire come cambiano le temporizzazioni del CEDSPRAM che seleziona la RAM statica usata come buffer, nonché del /CE1 e del /CE2 che vanno direttamente ai piedini della Compact Flash Card.
Figura 51: Specifiche A16 da manuale
Si vede che i pin di indirizzo A[16..19] sono utilizzati solo per l’accesso agli spazi memoria programma esterni.
Per quanto riguarda il /PS invece si ha:
Figura: Specifiche /PS da manuale
Si vede che il /PS si attiva (cioè va a livello basso) solo quando si accede ad uno spazio di memoria programma esterno.
Il fatto che il /PS venga usato (tramite un OR) per attivare sia la memoria SRAM esterna, sia la flash card, significa, come già annunciato precedentemente, che entrambe i dispositivi sono mappati nella memoria programma. Questa è una diretta conseguenza del fatto che, secondo le specifiche da manuale, è stato necessario mappare l’EPROM, contenente il codice programma, nello spazio di memoria dati.
Tale scelta architetturale è stata permessa dal fatto che l’instruction set contiene istruzioni che permettono di andare a scrivere nello spazio di memoria programma. Ma perché non utilizzare comunque lo spazio di memoria dati per la gestione di quelle che in effetti sono memorie dati, ovvero la flash card e la SRAM esterna?
L’hardware
logiche in questione avrebbero avuto molti ingressi (tanti quanti gli indirizzi). Operando invece come fatto la distinzione tra memoria programma e memoria dati viene fatta direttamente tramite il /PS e il /DS. Quindi in fase di boot si attiva il /DS e quindi la sola EPROM; il codice passa sul bus e viene caricato nella SRAM del DSP. Durante l’esecuzione invece, quando si accede alla memoria programma tramite gli appositi comandi, si attiva solo il /PS e quindi non viene selezionata la EPROM che giustamente rimane inattiva.
Rimane il problema di distinguere negli accessi in lettura e scrittura la flash card dalla SRAM esterna. Questa funzione è realizzata proprio dalla logica oggetto di questo paragrafo. Poiché la SRAM esterna è, come si legge dal manuale, da 64 kword, allora vuol dire che sono necessari 16 pin di indirizzo per scorrere tutte le sue locazioni di memoria (16 b per il bus dati), essendo:
kword 64 65536 64 1024 216 = ⋅ = =
Infatti i piedini del bus di indirizzi A[0:15] sono collegati ai sedici pin di indirizzo della SRAM esterna. Quindi i primi 64 kword dello spazio di memoria programma esterna sono dedicati alla SRAM esterna. Come si fa dunque per indirizzare la flash card? Basta indirizzare nello spazio di memoria programma esterna una locazione che ha un indirizzo superiore a 0xFFFF, perché così facendo si attiva il segnale A16 del bus indirizzi che va ad 1 logico e quindi, considerando la tabella di verità scritta precedentemente, si ha la disselezione della SRAM esterna visto che il CEDSPRAM torna a 1 logico, e la contemporanea selezione della flash card visto che si manda il /CEFLASH a 0 logico. Se non si fossero apportate le modifiche viste, con tale /CEFLASH portato a livello basso si sarebbe già attivata la flash card e si sarebbero potuti gestire i trasferimenti a 16 b, visto che inizialmente /CEFLASH era collegato con gli ingressi della flash card /CE1 e /CE2 messi in corto. Avendo invece messo in OR il /CEFLASH con GPO1 per fare il /CE1 e con GPO0 per fare il /CE2 invece si vede che si comandano le selezioni della flash (trasferimenti sulla parte bassa del bus dati per /CE1 e trasferimenti sulla parte alta del bus dati per /CE2) tramite il byte di status del 74LV574 che si imposta a livello di codice.
Questa modifica è stata fatta perché in fase di sviluppo, e quindi di contemporaneo apprendimento delle caratteristiche della flash card, non si sapeva come gestire il trasferimento a 16 b da e verso la flash card; questo sia per quanto riguarda i dati stessi che per quanto riguarda la lettura di registri di stato. Si è visto infatti che l’acceso ai registri di stato non dà problemi, anche effettuato a 16 b, se vengono indirizzati gli indirizzi pari dei registri. Quindi col tempo si è imparato a gestire il trasferimento dati a 16 b, e in ultimo, come avviene per l’ultima release del software, anche la lettura e scrittura dei registri di stato è stata gestita a 16 b. Le modifiche fatte all’hardware sono state lasciate comunque perché in fin dei conti non disturbano l’effettivo funzionamento a trasferimenti di 16 b per volta; inoltre tale elettronica, che è stata studiata per gestire dispositivi con accesso a 8 b, potrebbe essere utilizzata anche con altri dispositivi diversi dalla flash card dove l’accesso a 8 b sia magari obbligato e non opzionale.
