execute (): TRS rules to expressions

Para probar la reconfiguración, la idea era crear dos arquitecturas, cada

una de ellas con el bmpramda (visualizador de imágenes), el cargador y tres

filtros distintos. Con esto, podríamos pedir mediante un dipswitch la

reconfiguración total de la placa, y con otro controlar cuál de las dos

arquitecturas se cargarían, dependiendo del filtro que quisiéramos usar.

En cualquier caso, en la reconfiguración se empezó a trabajar mientras

aún no se habían terminado estas arquitecturas, así que para las pruebas se

usaron el contador.vhd (que muestra un patrón de rayas verticales) y una

modificación de este (que las muestra horizontales).

6.2 Desarrollo

En un primer momento se intentó crear totalmente por nosotros el

archivo de configuración de la Flash, a partir del vhd que controla la

configuración del CPLD de la Virtex proporcionado por XESS [

VDBO

01].

En este primer intento, se crearon una serie de estados que se detallan

en la fig. 19 y se añadió un contador de 100ms, para eliminar los rebotes que

generaban los dipswitches al código mencionado antes.

fig. 19 - Diagrama de estados de la reconfiguración

S0 Elimina Rebote 1 Elimina Rebote 2 S3 comienza=HI finEspera=LO finEspera=HI v_done=HI poweron_reset=LO comienza=LO BajaDip switch finEspera =LO finEspera=HI v_done=LO S2 S1 finEspera300us=LO finEspera=HI

Explicación de los estados:

• S0 : Estado inicial. Seguiremos en este estado hasta que llegue una

subida del dipswitch que activa la reconfiguración y además hayan

pasado 20 milisegundos desde que se encendió la placa (tiempo que

necesita la FPGA para estar lista para reconfigurarse después del

encendido).En este estado mantenemos la señal reconf y programb a

low para que no se reconfigure la FPGA.

Al salir de este estado, activamos un contador de 100 milisg. para

eliminar rebotes del dipswitch.

• EliminaRebotes1 : Nos quedamos en este estado hasta que sube la

señal fin_espera_100ms. De aquí pasamos a BajaDipswitch.

• BajaDipSwitch : Necesitamos esperar a que baje el dipswitch que activa

la reconfiguración, porque si no después de terminar la reconfiguración

volveríamos a empezarla de nuevo porque el dipswitch seguiría arriba, y

así seguiríamos reconfigurando hasta que se bajara el dipswitch, con lo

que se harían muchas configuraciones seguidas innecesariamente. Una

vez que se detecta la bajada del dipswitch se pasa a un nuevo estado de

eliminación de rebotes.

• EliminaRebotes2 : De nuevo nos quedamos en este estado hasta que

sube la señal fin_espera_100ms. De aquí pasamos a S1.

• S1 : comenzamos la reconfiguración de la FPGA subiendo la señal

programb, lo que hace que se borre. También reseteamos un contador

de 300 nanosegundos, tiempo necesario para que se complete el

borrado de la FPGA. Pasamos automáticamente al estado S2.

• S2 : me mantengo en este estado, con la señal programb en alta (y por

tanto borrando la FPGA), durante 300 nanosg., después de lo cual nos

vamos al estado S3.

• S3 : bajamos programb para que se deje de borrar la FPGA y subimos

reconf para pedir a la FPGA que se empiece a reconfigurar. La FPGA

nos avisará de que ha terminado su reconfiguración cuando eleve la

señal V_done, después de lo cual pasaremos a S0 y estaremos listos

para una nueva reconfiguración cuando el usuario lo solicite subiendo de

nuevo el dipswitch.

Para elegir cuál de las dos configuraciones almacenadas en la FlashRam se

carga en la FPGA, en algunas pruebas se tomaba el valor de otro dipswitch

para elegirlo. Esto se hacía en el proceso que aumenta la dirección o la

inicializa a ceros variando el valor de addr(20), que conincide con el dipswitch

8. El código explicado aquí se puede encontrar en el apéndice D, archivo

flashCon.vhd .

Con este código llegamos a conseguir que la placa reconfigurara a petición

del usuario con el dipswitch, y no únicamente cuando se encendía. A pesar de

esto, no conseguíamos que en tiempo de ejecución se pudiera elegir cuál de

los dos códigos almacenados en la FlashRam se debía cargar, por lo que

optamos por partir del código realizado en años anteriores por otro proyecto de

Sistemas Informáticos [

DEHD

02].

Se modificó este para que esperara a que se bajara el dipswitch antes de

seguir (por lo ya comentado antes) y entonces sí se consiguió que

reconfigurara a petición del usuario y además este podía elegir qué

configuración se cargaría.

Lamentablemente, la placa en la que se estaba trabajando tuvo algún

problema con su CPLD que impedía que pudiera cambiarse su configuración

(la del CPLD). Hay ciertos pines que controlan la configuración de la CPLD y

que no deben cambiarse de sentido (si son de entrada deben permanecer

siempre de entrada y viceversa). Si se cambiara su sentido impediría cargar

cualquier nueva configuración en la placa. Pero estos pines se comprobaron

(en el código, por si se habían cambiado inadvertidamente, y en la misma

placa, con un osciloscopio) y estaban bien. Así pues, no conocemos la razón

de que el CPLD no pueda ser cambiado de configuración.

De este modo, el CPLD, cargado siempre con la misma configuración y sin

posibilidad de cambiarla, inhabilitaba completamente a la placa entera. Al

quedar sólo una placa, no podíamos arriesgarnos a seguir trabajando en la

reconfiguración hasta no tener reparada la placa dañada, por temor a perder la

única placa que nos quedaba, por lo que el trabajo en esta parte del proyecto

se interrumpió.

7. MÓDULOS SOFTWARE DE CARGA Y

In document Correct low power design transformations for hardware systems (Page 107-112)