Images

Análisis del código VHDL del proyecto LEDA_blog (IV): Estructuración del código (típica en VHDL).

En las últimas entradas he metido mucha “literatura” en esta iremos más “al grano”.


Los programas de VHDL suelen estructurarse como sigue (y en el caso que nos ocupa, el código VHDL de LEDA_blog es como se hace):

--------------------------------------------------------------------------------------------------------------------------

Nota:
En el anterior esquema se podría haber incluido al inicio un bloque (prescindible), llamado cabecera dónde el programador da datos (en forma de comentarios antecedidos por dos guiones medios --) sobre su nombre o el de la empresa u organización, la versión del software, el nombre del código, una breve descripción de la función del programa…etc.

En nuestro código existe esa cabecera, pero como ya expliqué es ilegible porque está escrito en caracteres que mi PC no reconoce.

--------------------------------------------------------------------------------------------------------------------------


En el caso de nuestro programa la anterior estructura se implementa como sigue:


Ahora iremos explicando de forma breve cada una de estas partes del sistema.

Cabecera del programa:

Como ya comentamos esta parte son comentarios previos sobre el código hechos por el programador para describirlo. No es imprescindible, esta parte no se va a sintetizar (el equivalente a compilar en otros lenguajes de programación), ni se implementará en el hardware.

Llamadas a librerías y bloques de estas:



Las librerías están organizadas en bloques que la componen, que a su vez contienen fragmentos de código que pueden ser muy útiles en muchos casos. Al llamarlas podemos invocar esos códigos que nos facilitará mucho la vida. En nuestro caso llamamos a la librería IEEE y dentro de ella a los bloques: IEEE.STD_LOGIC1161 e IEEE.std_logic_unsigned. Gracias a estas llamadas, podemos hacer uso de los tipos de datos std_logic o std_logic_vector por ejemplo. Y así nos ahorramos tener que definirlos de forma manual.

Entidad (entity):


En la entidad lo que fundamentalmente se define es las entradas y salidas del sistema, no como se procesan las entradas para obtener las salidas esperadas.

Se podría comparar la entidad con una caja negra en la que sólo ves lo que se conecta con el exterior, es por decirlo de alguna manera, "la carcasa" del programa.

En nuestro caso sería:



Sobre las salidas LCD_N y LCD_P solo podría hacer conjeturas de porque están ahí y cuál puede ser su utilidad, lo que si tengo claro es que no son imprescindibles, y si elimináramos todas las instrucción que las usan el comportamiento obtenido (los LEDs encendiéndose secuencialmente), sería exactamente el mismo.

Arquitectura (architecture):



Aquí es donde realmente se implementa la forma en que se gestiona las entradas para obtener las salidas que deseamos (la secuencia de encendido de los LEDs).

En programación no suele haber una y sólo una forma de implementar un logaritmo que funcione y obtenga los resultados que queremos, hay varias, más o menos elegantes, más o menos óptimas, pero se puede tener el mismo resultado con códigos diferentes.

En VHDL, además también depende de la forma en que describas el sistema digital, que puede ser: por flujo de datos, funcional (o también he leído que le llaman algorítmica) y estructural.

En este caso el programador eligió la funcional, y más concretamente implementando las partes del algoritmo mediante procesos. En estos casos, el esquema de la arquitectura suele ser (de forma muy simplificada):

Aquí tenemos que considerar dos cosas, dentro de los procesos la ejecución de instrucciones es secuencial, pero los procesos se pueden ejecutar de forma concurrente. Que los procesos se puedan ejecutar de forma concurrente no significa que necesariamente se ejecuten a la vez. Cada proceso se ejecuta cuando se da una condición que puede ser que se modifique algún parámetro de su lista de sensibilidad, recordemos: 

O bien que se cumpla una condición de tipo  wait, algo con lo que no entraremos en esta ocasión.

Por tanto:

Pero a la vez:


En el código con el que estamos trabajando esta forma de programar mediante procesos se muestra en la siguiente figura. 

El porqué de que el segundo proceso que nos encontramos en el código esté notado como P3 y el siguiente como P2 es algo que se me escapa, en cualquier caso es una cuestión de notación sin importancia.

En la siguiente entrada ya estudiamos el algoritmo implementado por el programa con las nociones básicas que necesitábamos, a fin de cuentas entenderlo bien es el objetivo de este tutorial que forman estas últimas entradas. 

0 comentarios: