lunes, 27 de abril de 2009

Módulo FFT (II): Esquemas

Estes son os esquemas (supostamente) definitivos do Módulo FFT.

O esquema global é este:




O esquema da Unidade de cálculo de Módulos do Módulo FFT é o seguinte:



E o esquema da Unidade de Redondeo/Truncado e Saturación, compoñente da unidade de cálculo de Módulos, pode verse a continuación:





Espero que non se fagan demasiado liosos e que axuden as cores. Saúdos!
Hoxe realizamos con éxito a primeira proba sobre hardware real do circuito encargado de calcula-lo módulo da FFT. O material necesario foi unha placa de probas S3 de Digilent, na que se inclúe unha FPGA Spartan 3 XC3S200, visualizadores de 7 segmentos, pulsadores, interruptores e leds; un xerador de funcións analóxico Hameg, do que obtivemos un tono de frecuencia variábel para analizar; e unha placa PMOD-AD1, na que se monta un conversor ADCS7478 de 1MSPS, manufacturado por National Semiconductors, que nos permite realiza-lo mostreo do tono de entrada.

O primeiro paso consisteu en implementa-lo deseño completo do Módulo FFT na FPGA Spartan3, engadindo toda a circuitería extra necesaria para o control dos visualizadores, interruptores, leds e pulsadores da placa S3, así coma do propio Módulo FFT. Logo conectamos adecuadamente o xerador ó conversor, este á placa S3, e a placa S3 a un PC mediante un cable de programación, axustando a frecuencia do sinal de entrada entre 1 e 24KHz, e a súa ampritude a 3V.
Como sucede en moitas ocasións, o primeiro intento non foi fructífero: o circuito ignoraba por completo os sinais procedentes dos botóns da placa, aparentemente todos excepto o Reset... Un comportamento desconcertante, si. Revisando o deseño decatámonos que a asignación a este sinal non era correcta, co que o Sistema Secuencial Síncrono encargado da carga de mostras no Módulo FFT nunca comezaba as súas tarefas...
Unha vez arreglado o despiste o resultado foi todo un éxito: conseguimos calcular múltiples FFT's de 512 puntos e garda-los resultados nunha memoria RAM síncrona, cuxo contido se lía posteriormente e se representaba en hexadecimal nos visualizadores da placa. Neles poidemos observar como aproximadamente os valores coincidían cos calculados nas simulacións, e que a circuitería de 'zoom' funcionaba tal e como se esperaba (a base de miles de clicks no botón correspondente ó avance de dirección na memoria RAM !!de 512 posicións!!). Os resultados non coincidían exactamente cos da simulación porque é realmente difícil conseguir axustar a ampritude de forma exacta á empregada para as simulación; ademais resulta imposíbel inicia-los cálculos xusto cando a fase do tono de entrada é cero, coma no test bench do Módulo FFT.

En breve subiremos as fotos da placa funcionando. O deseño continúa!

sábado, 25 de abril de 2009

Sistema de adquisición de datos

Esta semana me he dedicado a establecer un esquema preliminar de la parte encargada de adquirir los datos que otros bloques del sistema procesarán posteriormente. A falta de un estudio más detallado del CAD y sus señales el esquema del sistema tiene el siguiente diseño preliminar.



EL bus DATO envía los 18 bits del dato que procesará la fft. La señal NDATO avisa al bloque siguiente que tiene un dato disponible y la señal INICIOFFT le indica a la fft que va a empezar a recibir datos para procesarlos. Esta señal por cuestiones de diseño del bloque posterior debe activarse tres ciclos de reloj antes de enviar el primer dato. El circuito de control de la figura se encargará de configurar el CAD y de recoger el bit que nos interesa. Este circuito de control controla también cuando debe empezar a funcionar la unidad de procesado.

En esta figura se representa la unidad de procesado. Este bloque se encarga de recibir los bits procedentes del convertidor analógico digital en serie, los almacena hasta conformar un dato de 18 bits, y cuando lo tiene listo se lo envía al bloque encargado de realizar la fft a través del bus DATO. Para avisar de que ya tiene un dato preparado activa la señal NDATO.




viernes, 24 de abril de 2009

Módulo FFT

O primeiro compoñente do analizador de espectro xa está rematado. Trátase do circuito de cálculo do módulo da FFT:


O circuito está deseñado de acordo coas especificacións: utiliza un IPCore de Xilinx para o cálculo da FFT de 512 puntos do sinal de entrada, e un Sistema Secuencial Síncrono para carga-las mostras deste directamente no propio core (evitando o uso dunha memoria RAM auxiliar, co que se aforran recursos). Para a obtención do módulo das mostras espectrais emprégase o algoritmo Cordic, implementado con outro IPCore, e engadiuse a capacidade de gobernar unha memoria RAM síncrona conectada á saída deste módulo para almacea-lo mostreo espectral calculado.
O seguinte paso é a proba deste compoñente sobre hardware real: unha FPGA Spartan3 de Xilinx montada sobre unha placa S3 de Digilent. Conectando un conversor analóxico dixital ADCS7478 de National Semiconductor e engadindo a debida circuitería de adaptación, poderemos ve-los valores calculados polo módulo FFT nos visualizadores da placa (vamos a necesitar paciencia... son 512 valores e avánzase accionando un pulsador!).
En breve publicaremos un esquema completo coa descomposición en bloques final dos compoñentes do módulo FFT e unha simulación comparativa con resultados de Matlab. Saúdos!

domingo, 19 de abril de 2009



Este es el diagrama de bloques de la parte de nuestro sistema que actuará de interfaz con el monitor VGA. Como vemos, consta de dos bloques básicos, que son los que explicaremos a continuación: un bloque de sincronismo y un controlador RGB. La entrada de DATOS corresponde a la salida de la RAM donde se guardan los resultados de la FFT, y el bloque FMS3818 es, entre otras cosas, un DAC para construir las señales R, G y B analógicas que se envían al monitor.

Comenzaremos por el bloque de sincronismo, concretamente con las señales sinc_hor y sinc_ver. Estas son las señales de sincronismo horizontal y vertical, trenes de pulsos rectangulares ambas, cuyo funcionamiento se explica en el apartado del monitor. Lo que ocurre es que ahora nosotros hemos de calcular las características de esas señales en función del monitor que vamos a utilizar. Nuestro monitor tiene una resolución de 640x480 píxeles. Esto hace pensar que el período de un píxel, y por tanto el de esas dos señales, estará relacionado con esos números. Pues bien, esto es incorrecto. En realidad, la pantalla tiene 800 píxeles en horizontal y 525 líneas. La diferencia de píxeles quedará aclarada a continuación al explicar la forma de las señales.

En primer lugar, si queremos una frecuencia de pantalla de 60 pantallas por segundo (para evitar parpadeo) debemos utilizar una tasa de píxel 800x525x 60, que aproximaremos por 25 MHz.

Partiendo de esa base, esta es la forma de la señal sinc_hor:



Como vemos, la señal consta de la parte activa (durante la cual h_activo está a 1), un pórtico delantero (borde derecho), retorno (el haz de electrones vuelve al lado izquierdo) y pórtico trasero (borde izquierdo). Estas tres últimas partes no corresponden a píxeles visibles de la pantalla, por lo que h_activo está desactivada en ese intervalo. Pues bien, como la tasa de píxel es 25 MHz, su inverso será el período de píxel, y este multiplicado por 800 será la duración del barrido temporal. Multiplicando la duración en píxeles de cada intervalo obtenemos la duración temporal. Así sabremos el tiempo que debemos mantener activa sinc_hor (todos los intervalos menos el retorno) y h_activo (solo el intervalo activo).

Por su parte, la señal de sincronismo vertical, es similar, y tiene la siguiente forma:



Los distintos intervalos se deben a lo mismo, correspondiendo el pórtico delantero al borde inferior y el trasero al superior. La duración de cada intervalo ahora se multiplica por el período de píxel y por el número de píxeles de una línea para obtener la duración temporal de cada intervalo.

Solo queda añadir que la señal activo que sale del bloque será resultado de multiplicar h_activo por v_activo, es decir, solo será activa si lo son las dos a la vez.

Las señales pixel_x y pixel_y se corresponderán obviamente con el píxel y línea actuales, de los que tendremos que llevar cuenta.

Como vemos, la implementación del bloque es sencillísima, lo único que tenemos que hacer es construir un período de cada señal a partir de nuestros cálculos y sacar las cuenta de píxeles y líneas, y la señal resultante de hacer un “and” entre h_activo y v_activo.

Vamos ahora con el segundo bloque. No entraremos en mucho detalle por ahora, ya que se trata de una primera aproximación. Digamos que a este bloque entra un dato de 9 bits (entre 0 y 511, pero saturado a 460), y las posiciones de píxel y línea actuales, y la indicación de si el píxel actual es activo.

Pues bien, disponemos de 480 bits para 460 niveles en vertical. Dejando 4 para representar los ejes nos quedan 16 sobrantes, 8 de los cuales quedarán en blanco por arriba de la gráfica, y 8 por debajo. Lo mismo en horizontal: 512 valores a representar en 640 puntos. Dejando 4 para los ejes nos quedan 68, así que dejaremos 34 a cada lado. Pues bien, este bloque debe tomar las siguientes decisiones en función de las entradas. Cuando nos aproximemos al primer píxel representable de cada línea (eliminando de los activos los que dejamos en blanco) solicitaremos el primer dato a la RAM. Si el dato es mayor o igual que la línea en la que nos encontramos, dentro de las representables, pintaremos el píxel en blanco (las tres salidas totalmente a uno) y pediremos el siguiente dato a la RAM (el tiempo de lectura es mucho menor que el período de píxel, así que no habrá problema). Esto se repite durante toda la línea, y en todas las líneas, teniendo en cuenta que hay que eliminar líneas activas también.

Una posible opción sería utilizar un registro de 512 bits para indicar que componentes de la FFT ya son representables en la línea actual (si en una línea la representamos, en todas las líneas por debajo deberemos hacerlo) para no tener que efectuar siempre comprobaciones. Sin embargo, parece mucho más sencilla la otra opción de codificación, que además no conlleva el uso del registro, aunque tenga que estar tomando decisiones continuamente, estas siguen siempre la misma estructura, luego lo que se haga para una línea vale para la siguiente y no ocupa más recursos.

Esta es una primera aproximación al interfaz del monitor. Como vemos, valdrá solo para representar las señales en B/N. Cuando esto funcione, refinaremos el diseño para incluir colores, quizá letras en los ejes y demás matices añadidos. Por ahora nos centraremos en que los bloques funcionen correctamente. También en un segundo lugar nos ocuparemos del bloque FMS3818, cuyo funcionamiento es bastante sencillo.

En principio, nuestra intención es finalizar la semana del 24 de abril el bloque de sincronización y haber comenzado ya el de control de RGB, cuyo funcionamiento básico debe estar terminado a mediados de la semana siguiente, para poder meternos después en el manejo del FMS3818 y los matices gráficos.

jueves, 16 de abril de 2009

El monitor de tubo de rayos catódicos

Un monitor de rayos catódicos, como el que vamos a utilizar en nuestro proyecto, tiene la siguiente estructura:



Se trata de un tubo de vacío que termina en una pantalla recubierta de fósforo. Al inicio de dicho tubo se encuentra un proyector de electrones. Cuando trabajamos en B/N, este proyector recibe una única señal de entrada, correspondiente a la luminancia que se quiere representar (mayor nivel de dicha señal, más próximo al blanco, y para menor nivel más próximo al negro). En función de esta señal, el proyector “disparará” un haz de electrones hacia la pantalla de fósforo, más intenso cuanto mayor sea el nivel de la señal de entrada. Al impactar en la pantalla de fósforo, los electrones hacen que esta se ilumine en el punto de impacto, tanto más cuanto más intenso sea el haz.

Para ir barriendo todos los puntos de la pantalla, disponemos de bobinas de deflexión. Las de deflexión horizontal están en la parte superior e inferior del tubo, generando un campo eléctrico horizontal y las de deflexión vertical a los lados, generando un campo eléctrico vertical. Estos campos van desplazando el haz para barrer todos los puntos de la pantalla.

El control de las bobinas se consigue mediante dos señales de sincronismo, ambas trenes de pulsos rectangulares. La de sincronismo horizontal tiene un período menor que la de sincronismo horizontal, pues en un solo barrido vertical se hacen varios barridos horizontales. Ambas señales pasan por un oscilador que genera a partir del tren de pulsos una señal en dientes de sierra, de modo que la intensidad de los campos generados por las bobinas va aumentando poco a poco, consiguiendo que el haz de electrones se desplace poco a poco por todos los puntos de la pantalla.

Ahora solo nos queda explicar la diferencia entre el caso B/N y el caso en color. En la mayoría de los monitores se utiliza el sistema RGB, es decir, todos los colores se representan como combinación de tres componentes básicos, rojo (R), verde (G) y azul (B). Según se de más o menos intensidad a cada componente, se van obteniendo distintos colores. En la siguiente tabla se muestran algunas combinaciones sencillas para colores básicos (0 representa mínima intensidad de esa componente y 1 intensidad máxima):



Entonces, nuestro tubo tendrá ahora tres proyectores de electrones, cada uno controlado por la señal de intensidad de uno de los componentes. Cada punto de la pantalla puede ser iluminado únicamente por un haz, de forma que existen máscaras para evitar que se interfieran entre sí. Los puntos se van iluminando alternativamente con las tres señales (cada tres puntos le toca a la misma señal), de forma que para un punto de un monitor B/N necesitamos tres de RGB (un tercio de resolución para el mismo tamaño de pantalla). El ojo no verá los tres puntos diferenciados, sino una combinación lineal de todos, obteniendo el color deseado.

Como en nuestro caso utilizaremos un monitor a color, el interfaz que debemos implementar tendrá como entradas los datos de la FFT y como salida 5 señales, las tres de los componentes RGB y las de sincronismo horizontal y vertical, que debemos generar con los períodos adecuados.

sábado, 4 de abril de 2009

Core FFT: detalles da implementación e primeiras probas


Antes de comezar co deseño queda resolve-la elección do modo de cálculo do Core FFT: aritmética escalada ou sen escalar. Para decidirnos por unha ou por outra debemos olla-las vantaxes e os inconvenientes de cada un dos modos de operación:

· A aritmética sen escalado evita os desbordamentos nos cálculos no Core basándose no aumento do número de bits no peor dos casos: traballando con n bits para as partes real e imaxinaria de x[n] obteremos X[k] sempre correctamente empregando n + 1 + log2(N), o que neste caso, segundo as especificacións, resulta en 28 bits. Polo tanto, logo do producto das partes real e imaxinaria de X[k] por si mesmas e da suma, suporía un resultado |X[k]| de 56 bits, tendo en conta que o resultado do producto é sempre positivo, polo que podemos ignora-lo bit de signo (tanto re{x[n]}, im{x[n]} como re{x[k]} e im{X[k]} veñen expresadas en Ca2). Por último habería que truncar ou redondear adecuadamente cada un dos resultados e satura-la saída de 9 bits antes de introducila na RAM.

Polo que acabamos de ver, a gran vantaxe da aritmética sen escalado é a evitación de desbordamentos nos cálculos de |X[k]|: se se produce nunha mostra k0, o máis probábel é que |X[k0]| non teña nin o máis mínimo parecido co verdadeiro valor do espectro na frecuencia k0. Pero o grandísimo invonveniente é o soberano desperdicio de recursos que supón. Dado que o monitor non ofrece unha gran precisión na representación dos valores de |X[k]|, parece moito máis sensato experimentar co modo de operación basado na aritmética con escalado, que ademais permite un uso eficiente dos multiplicadores, como vamos a ver.


·A aritmética con escalado implica un certo desprazamento binario á dereita dos resultados de cada mariposa durante o cálculo da FFT. O desprazamento é arbitrario, e pode elixirse entre 0, 1, 2, ou 3 bits. Isto supón polo tanto que os valores calculados neste modo de operación non se correspondan con mostras do espectro dun sinal x[n], senón cunha versión escalada das mesmas: 1/s*X[k], onde s é 2^b, se b coincide co número de bits desprazados en total (cada desprazamento binario supón unha división á metade).

A gran ventaxa da aritmética escalada é que, elixindo o factor adecuadamente, pódese evita-lo desbordamento no cálculo da FFT empregando moitos menos recursos. Concretamente, as saídas (partes real e imaxinaria de X[k]) teñen neste caso n bits, se n é o número de bits da entrada. As nosas especificacións establecen entradas x[n] de 18 bits, co que as saídas tamén terán o mesmo ancho. Por outra banda, os multiplicadores adicados das FPGA’s de Xilinx adoitan ser de 18x18 bits, permitindo resultados de 36; afortunadamente, a FPGA Virtex2 Pro dispón exactamente de multiplicadores con estas características, co que os circuitos que elevan ó cadrado ambos datos de saída do Core FFT poden implementarse de forma moi eficiente, aproveitando ó máximo a circuitería específica.

Por outra banda, os grandes inconvenientes da aritmética escalada son, por unha parte, a perda de precisión que se produce nos desprazamentos, e por outra, a búsqueda dun factor de escala 1/s tal que evite desbordamentos nos cálculos e non agrave excesivamente o problema da precisión.

Para tentar resolver esta difícil cuestión votaremos man do contorno Matlab® da compañía The Mathworks, Inc. O script que se amosa a continuación calcula a FFT de 512 puntos dun tono puro, o peor caso en canto a ampritude espectral, xa que a súa transformada de Fourier sería unha delta convolucionada cunha sinc (debido ó enventanado do sinal x[n]). Cabe destacar que se considera o dato de entrada x[n] como un valor enteiro en Ca2, co que pode tomar valores entre -2^17 e 2^17 – 1.



N = 512;

A = 2^17 - 1;

n = 0 : N - 1;

Ts = 1/48000;

w1 = 2*pi*1000;

x = A*cos(w1*n*Ts);

X = fft(x, N);

figure(1);

stem(2*pi/N*n, real(X));

figure(2);

stem(2*pi/N*n, imag(X));

figure(3);

stem(2*pi/N*n, abs(X));



Con isto ollamos que no peor caso a parte imaxinaria tomará valores de 24.3e6, aproximadamente. Polo tanto, a representación de 2^(-n)*24.3e6 en 18 bits en Ca2 é posíbel se n >= 8. Por seguridade, e dado que non sabemos como se realizan os cálculos dentro do Core, poderiamos empregar como factor s o valor 2^(-9).

Para a proba final xeramos o IPCore FFT de Xilinx na ferramenta ISE, e modelamos en VHDL un compoñente que lle introduza os mesmos 512 valores xerados en matlab, cuantificados con 18 bits en Ca2. Co programa Modelsim XE Starter Edition levamos a cabo unha simulación funcional do compoñente e obtemos o seguinte:



Por outra banda, os resultados obtidos en Matlab son:



Disto séguense os seguintes resultados:

· O Core FFT ofrece unha precisión máis ca suficiente para esta aplicación traballando con aritmética escalada (s = 2^9), e evítase o desbordamento para unha entrada sinusoidal.

· Os valores obtidos como resultados son tales que, se se considera que a entrada é un número enteiro I18 (18 bits en Ca2), a saída será I18, é dicir, a posición da coma non varía (nas follas de características de Xilinx isto non está moi claro, pero nas probas comprobamos que é así).

· O tempo de cálculo da FFT é de 92us cun reloxo de 50MHz, moito menos do esperado nun principio.

A introducción do factor de escala 1/s non supón ningún problema no noso caso: a súa corrección pode efectuarse mediante o calibrado adecuado unha vez rematado o deseño.


Con todo o visto ata agora podemos concluir que a mellor idea é o uso de aritmética escalada, coa que obtemos unha precisión suficiente para esta aplicación, e un aforro de recursos moi considerábel e que nos favorece no uso eficiente dos mesmos. O funcionamento do Core FFT está comprobado e esclarecido, co que o deseño segue adiante!



Deseño final do Analizador Espectral

Logo de revisar toda a documentación dispoñíbel de Xilinx sobre os seus IPCores, as follas de características da placa XUP Virtex2 de Digilent e dos seus compoñentes, e tras un longo proceso de análise de posibilidades acadamos un deseño estructural para o analizador que nos propuxemos construir. Está basado nos esbozos que podemos ver na entrada anterior, sobre os que incluimos unha serie de compoñentes adicionais que agora explicaremos. Tódalas decisións que tomamos en canto ó procesado de mostras e á arquitectura do Core FFT se manteñen.
Primeiramente decatámonos de que o Core FFT de Xilinx segue un protocolo para a captura de mostras tal que por cada ciclo de reloxo carga un valor da entrada x[n]. O deseño deste Core está orientado ó uso dunha memoria RAM como buffer de mostras de entrada, o que permite unha carga de datos moi rápida, pero como non temos restriccións temporais fortes e a memoria RAM suporía unha cantidade de recursos considerábel, decidimos empregar un Sistema Secuencial Síncrono para o control da carga de datos. O funcionamento é o seguinte: o Core FFT dispón dun terminal de habilitación de reloxo; como as mostras só se presentan cada 1/48000 s, o SSS deshabilitará o reloxo tra-la captura de cada dato ata a chegada do seguinte. Deste xeito conseguimos unha reducción considerábel de recursos empregados.
Este Core tamén dá pé ó uso dunha RAM como buffer para as mostras X[k] de saída co protocolo de descarga que implementa. Seguindo a mesma filosofía, o noso deseño non precisa tal rapidez: buscamos a reducción de recursos empregados, polo que nos decantamos por outro SSS que controle a descarga de mostras, deshabilitando o circuito FFT cando sexa necesario.
Unha vez que xa decidimos como obte-las mostras X[k] da FFT, debemos adaptalas para a representación na pantalla. Xa que cada un dos X[k] é un valor complexo en xeral, e dado que do Core obtemos a súa parte real como a súa parte imaxinaria, precisamos un bloque que calcule o módulo de cada unha das mostras do espectro. Inicialmente propuxémonos calculalo en unidades logarítmicas, pero Xilinx non ofrece ningún IPCore capaz de computa-lo logaritmo dun número enteiro (poderíase emprega-lo algoritmo Cordic para isto, pero a súa implementación sería probábelmente tan difícil como o analizador enteiro e non moito mellor ca algunhas xa existentes). No lugar de empregar unha táboa de consulta en memoria, a expensas dun incremento de recursos empregados, conformámonos co cálculo de |X[k]| en unidades naturais.
Para iso primeiramente elevamos a parte real e imaxinaria ó cadrado multiplicándoas por si mesmas, e logo sumamos os resultados para obter |X[k]|^2. Xilinx si que ofrece un IPCore para o cálculo da raíz cadrada dun número enteiro basado no algoritmo Cordic (Core Cordic v3.0), co que o cálculo do módulo simplifícase enormemente.
Unha vez que obtemos cada unha das mostras |X[k]|, deben ser almaceadas nunha RAM de dobre porto, á que accederá tamén o circuito controlador do monitor VGA para a representación final.
Pero volvendo ás especificacións do monitor VGA, decidimos unha representación cunha resolución de 640x480 píxeles, co que cada |X[k]|, independentemente do seu valor numérico, debe ser expresado cun máximo de 9 bits (512 niveis), xa que non se pode iluminar a medias un píxel. Isto implica que, antes do almaceamento na RAM de dobre porto, cada unha das mostras |X[k]| debe atravesar un circuito de redondeo/truncado e saturación: neste compoñente cada |X[k]| é adecuadamente redondeada ou truncada, e se o resultado excede dun valor máximo, a saída do circuito satúrase (quedan tódolos bits activados) evitando un resultado erróneo debido ó desbordamento.
Para a captura de datos empregamos un conversor AD LM4550, que envía cada un dos resultados da conversión en serie, polo que como no Core FFT de Xilinx os valores de cada mostra se capturan en paralelo, precisamos un circuito de conversión Serie-Paralelo (S-P). Este circuito debe recibir a trama serie do CAD, extrae-lo valor da mostra, e unha vez feito isto, activar un sinal de nova mostra que lle indique ó SSS de carga a presenza dun novo dato.
Por último, débese empregar un SSS máis que controle o inicio da captura de datos para cada FFT de modo que se consigan unhas 50 por segundo (aínda non decidimos a frecuencia de cálculo, hai tempo en tódolos sentidos), a configuración do CAD LM4550 inicial segundo as especificacións, e outros aspectos que vaian xurdindo.

En resumo, o analizador lóxico funcionará da seguinte maneira: inicialmente un SSS principal configurará o CAD para unha conversión a 48KHz con cuantificación de 18 bits por mostra. Cada 20ms aproximadamente, este SSS ordeará o comezo do cálculo dunha FFT para actualiza-la RAM de mostras |X[k]|, co que o SSS de carga introducirá 512 mostras no Core FFT. A introducción de cada mostra faise cada 1/48000 s, isto é, cando estea dispoñíbel á saída do conversor S-P. Mentres non haxa novas mostras manterá o reloxo do Core FFT deshabilitado. Unha vez que se cargan tódolos datos de entrada e se computen as |X[k]|, o SSS de saída comezará a descarga de datos, controlando o proceso de cálculo do módulo e almaceando cada un dos datos |X[k]| válidos na RAM de saída. Cando todos e cada un dos datos queden almaceados na RAM, o conxunto de circuitos esperará a que o SSS principal ordee un novo cálculo. Por outra banda, en paralelo o circuito controlador VGA irá lendo datos da RAM de saída e amosaráos na pantalla.