Unha vez que xa explicamos aspectos básicos dos analizadores espectrais, imos pasar ás especificacións. Lóxicamente, aquí imos describir o funcionamento xeral do sistema e certos parámetros específicos que imos utilizar, non definitivos, nin moito menos, pero tódalas modificacións que vaimos realizando sobre estas irémolas indicando.
Dado que a FPGA que imos utilizar para a implementación (V2PRO) ten moitos recursos á nosa disposición, partiremos de que esta non nos vai limitar en ningún momento en canto a recursos se refire, por tanto (e partindo de que o traballo que nos supoña tampouco o consideramos unha limitación), o noso obxectivo principal no deseño será conseguir o mellor producto que poidamos implementar.
O desafío consiste nun analizador que sexa quen de amosar o espectro dun sinal obtido dun micrófono ou dun xerador en tempo real, isto é, debería calcular a FFT de tódalas mostras que vai tomando do sinal coa maior precisión e co maior ancho de banda posible e amosar os resultados nun monitor VGA.
Isto vainos dar unha idea dos bloques que teremos que implementar: un convertidor analóxico/dixital, un bloque que realice a FFT do sinal (que terá un sistema de memorias e unha implementación en mariposa), unha memoria ROM que almacene os resultados antes de presentalos no VGA, o interfaz que procesa os datos antes de envialos ó monitor, e o monitor en sí.
Para saber os parámetros nos nosos bloques, necesitamos saber cómo é o sinal e os recursos dos que dispoñemos para facer números. Deste xeito, iremos describindo cada un dos bloques como cremos que son máis axeitados.
Buscamos o maior ancho de banda posible para o analizador, polo que debemos empregar a maior frecuencia de mostreo que permita o CAD do circuito integrado de procesado de son que posúe a nosa FPGA (AC97). Ollando as follas de características, a frecuencia de muestreo debería ser de 48KHz, (a máxima) o que permite calcula-la FFT de sinais cun ancho de banda de
Ademais, os CAD’s do chip de procesado de son permítennos elixir o número de bits cos que se cuantificarán as mostras. Segundo os nosos obxectivos, poderíamos usar o maior número deles posible: 18 bits por mostra.
Agora observemos a saída do analizador: supoñamos que empregamos un monitor VGA de resolución 640x480 (que é o que tiñamos pensado dende un principio). Logo o número de puntos da FFT xa ten unha cota superior: nunca poderemos representar máis de 512, pois con 1024 caerían varias mostras espectrais X[k] no mesmo píxel.
Entón, volvendo recordar que buscamos o mellor producto posible, pensemos en cal sería a mellor elección para o modo de traballo do Core da FFT que nos ofrece Xilinx:
Cun modo pipeline / streaming obteriamos un fluxo contínuo de datos de saída a partir do fluxo continuo de mostras da entrada que obtemos do CAD (logo do circuito conversor serie->paralelo). Isto, teoricamente, permitirianos aproveitar tódalas mostras e conseguir representa-la FFT de tódolos bloques da entrada. O problema desta elección reside precisamente na rapidez do Core neste modo de traballo: segundo a figura do cronogramas que nos proporcionan as follas de características (páxina 27), cada mostra de entrada cárgase en cada un dos flancos positivos de reloxo; pero resulta que nós só dispoñemos dunha mostra cada 1/48e3 s, logo teriamos que forzar a traballar ó Core cun reloxo de 48KHz para que cada mostra se cargase cando estivese dispoñible. Isto vai resultar difícil xa non só pola sincronización que fai falta, retardos, etc, senón que o cálculo tardaría demasiado e peor, o Core non traballa a menos de 1MHz de reloxo.
Unha posíbel solución sería almacear 512 mostras nun buffer de entrada co sinal de reloxo do Core inhibido e logo, cando se completara o buffer, proceder ó cálculo pasando as mostras unha por unha en cada flanco, pero iso sería un desperdicio de recursos: estariamos empregando o Core só unha fracción mínima de tempo, e ademais precísase o buffer e a súa xestión.
O que consideramos máis apropiado, chegado este punto é empregar algún modo burst (a ráfagas) e ir tomando bloques de 512 mostras cada certo tempo, de maneira que conseguimos efectuar un número suficiente de fft’s por segundo para que non se aprecien cambios bruscos nas fft’s calculadas. Por exemplo, unha opción sería realizar unhas 50 fft’s por segundo cun procesado por bloques no Core, tomando 512 mostras, transformándoas, calculando o módulo e o 10log(), e almaceando o resultado nunha memoria de dobre porto pola que o controlador VGA poidese ler simultaneamente os resultados.
As desventaxas desta forma de proceder son, basicamente, que non observaremos a fft de tódolos bloques de mostras do sinal de entrada. Pero, de todos xeitos, se o pensamos ben tampouco parece tanto problema: supoñamos que procesamos todos e cada un dos bloques de 512 mostras da entrada e que barremos o monitor mostrando tódalas fft’s; tendo en conta que cada bloque máis ou menos formaría unha porción de 11ms de sinal, cada 11ms cambiaría a imaxe do monitor. Pero de todas esas fft’s que se calcularían, con cantas se quedaría o ser humano medio? Seguramente non se percibiría moita diferencia se só amosásemos 50 ou 60 fft’s por segundo.
Para determinar se esta solución é válida temos que verificar dúas cousas:
· Que os recursos da FPGA sexan suficientes para a implementación (especialmente a memoria da que dispoñemos) e
· Que o Core da FFT non sexa demasiado lento calculando FFT’s.
Supoñamos que desexamos unhas 50 fft’s por segundo, unha frecuencia suficiente para que non se note o cambio entre un espectro e o seguinte. Isto deixaría un tempo de 20ms para:
1.- Tomar 512 mostras de sinal: a 48KHz tárdase 10.67ms en ter un bloque completo. As mostras irianse convertindo de serie a paralelo a medida que a trama sae do CAD sen penalización de tempo e iríanse introducindo no Core da FFT directamente sen malgastar recursos en memoria intermedia.
2.- Cando se completa o bloque inhibiríase o CAD e arrancaríase o cálculo da FFT.
3.- Finalmente descargaríanse as mostras do core e realizaríanse os cálculos matemáticos necesarios, para almacear o resultado na RAM de dobre porto que faga de ponte entre a circuitería do controlador VGA e o Core. En principio os cálculos matemáticos máis simples son o producto das partes real e imaxinaria consigo mesmo e a suma dos resultados (así conseguimos o módulo ó cadrado de X[k]).
Para os dous últimos pasos dispoñemos de 10ms. Ollando as follas de características do core FFT podemos comprobar que a latencia do cálculo dunha fft de 1024 puntos é da orde de 50us cando se emprega o sinal de reloxo de maior frecuencia posible no modo Radix 2 Lite. Ou ben da orde de 20000 ciclos de reloxo, o que, a 50MHz, supón 400 us. Nas follas de características dise que “The latency is from asserting the START input to the last sample of output data coming out of the core, assuming that the UNLOAD input is asserted as soon as possible if present”. Logo o deseño parece viable en canto ós límites temporais para os cálculos.
Vexamos agora que ocorre cos recursos da FPGA e a memoria ocupada:
Primeiro está claro que precisaremos almacear a información do que se amosa en cada píxel da pantalla nalgunha parte. Para defini-la cor de cada píxel precísanse 3*8 bits/pixel. Iso fai 3*8*640*480 bits de memoria de video. Realmente, poderíase simplificar enormemente se amosaramos unha gráfica monocroma: empregando só unha cor fixa e coñecida para os píxeles coloreados e a cor negra para o resto só precisamos 640*480 bits. Iso fan 300K bits (K = 1024), unha parte non despreciable (pero asumible) da memoria da FPGA, que dispón de 428K de memoria distribuida e 2448K de memoria de bloque.
Ademais necesitaremos unha RAM de dobre porto que garde o resultado de cada FFT. Para calcular de canto podería ser o seu tamaño consideremos o seguinte:
Se traballasemos con 18 bits de entrada, o porto real do Core terá eses mesmos bits. Supoñamos que non aplicamos escalado (xa que a Core nos proporciona esa opción): entón as partes real e imaxinaria terán 18 + log2(512) + 1 bits = 28 bits (o por que está nas follas de caracterísiticas da Core). Calculando o producto das partes por si mesmas farían falta 28*2 = 56bits por parte para que non haxa desbordamentos, e ó sumalas ó final precisariamos un bit máis polo mesmo motivo. En total, os datos á saída terían 57 bits, con 17 de parte fraccionaria (iso sae tamén nas follas de carácterísticas do Core). A RAM ocuparía en total 512*57 = 28.5K bits. E iso se se traballase coa precisión completa en punto fixo; se se aplicase algún tipo de escalado só teriamos 18 bits nas partes real e imaxinaria, igual cá entrada, e polo tanto uns resultados 5 veces máis pequenos pero con menos precisión. Será no momento da implementación (pois aínda non sabemos cómo de complicado pode resultar) cando decidamos se utilizar ese escaldado ou non, pois é necesario votar unhas contas a maiores.
Por outra parte, a implementación do Core da FFT require, aproximadamente, en torno a 1000 LUT’s e uns 5 block RAM’s (isto está nas táboas das follas de características do Core), pero como a FPGA coa que traballaremos posúe 26000 LUTs e 136 BlockRAMs sería máis ca suficiente.
En canto ó monitor VGA, é necesario comentar que a resolución coa que contamos é de 640x480, por tanto, necesitamos unhas 60 pantallas por segundo (tras realizar algunhas contas) para non percibir a sensación de parpadeo.
Para o monitor necesitamos varios circuitos de control que nos proporcionarán os sinais para os barridos de liñas da pantalla. Imos necesitar dous circuitos de control. O primeiro nos proporcionará: dous sinais cuxa duración indicarán o tempo de barrido horizontal e vertical (que se calculan a partir da resolución da pantalla, e que poderíamos facelos variable en función dese parámetro), un sinal que nos indicará cándo os pixeles están activos (un determinado número de píxeles da liña non están activos, é dicir, son negros), as coordenadas do píxel que imos representar. Os tres últimos sinais son entrada do segundo bloq1ue.
Pola outra banda, o segundo é o encargado de transformar os datos da súa entrada (que serían, no noso caso os cálcuos da FFT que están almacenados na RAM de dobre porto), convertíndoos nun píxel (é dicir, un sinal de 3 bits: un para o vermello, outro para o verde e o último para o azul), o píxel que vai ser representado na pantalla.
Estos sinais dixitais, temos que convertilos en analóxicos para mandallos á pantalla, e para iso imos utilizar o un dispositivo específico: o Triple Video D/A Converter FMS3818. O que fai facer esta compoñente é recibir 3 sinais de 8 bits (por tanto, entrada en paralelo, que vai provir, directamente da RAM de dobre porto), unha para cada cor, e tranformalo en tres sinais distintas analóxicas que se enviarán directamente ó VGA. A tasa de conversión é de 180 mostras/s, polo que é suficientemente rápido como para que inflúa no retardo da representación por pantalla.
As follas de características do FMS3818 pódense atopar na seguinte dirección web: http://courses.ece.illinois.edu/ece412/References/XUP/FMS3818KRC.pdf.
Para rematar, a proposta de especificacións, como xa se comentou non é definitiva, pois de seguro nos surxirán problemas durante a implementación; pero, para comezar consideramos que estas especificacións non presentan ningún problema en canto a recursos e retardos temporais se refire.
Presentamos un diagrama de bloques moi básico (só para ver qué grandes bloques temos que implementar, sen entrar en detalles):
Un saúdiño, e ata pronto!!!
Por tanto, ya hemos dado otro paso más: tenemos una expresión discreta del espectro de una señal, también discreta en tiempo. Esto nos permite utilizar procesado digital en ambos dominios, lo cual tiene infinitas ventajas: sencillez, rapidez, facilidad de comprensión, ahorro de costes, etc.