VHDL

VHDL
Lenguaje para descripcion y modelado de circuitos
Ingeniera Informatica
Fernando Pardo Carpio
c Fernando Pardo Carpio, 14 de octubre de 1997

Prologo
Los apuntes que se contienen en las proximas paginas corresponden a parte primera de
la asignatura de Tecnologa Informatica que se imparte en el segundo curso de la carrera
de Ingeniera Informatica de la Universidad de Valencia. Se trata de una asignatura
optativa y cuatrimestral con un total de 4.5 creditos teoricos y 1.5 practicos.
El objetivo de la asignatura es familiarizar al alumno con el ujo de dise~no de
circuitos electronicos, desde su especicacion hasta su realizacion. Este ujo comienza
con la explicacion de las principales herramientas y metodologas para la descripcion
del dise~no. Se pasa por explicar algunos conceptos de simulacion tanto digital como
electrica, y se termina por presentar dos formas en que pueden acabar los dise~nos
electronicos: circuitos integrados y circuitos impresos. Para cubrir estos objetivos el
curso se ha dividido en cuatro materias si bien las dos ultimas vienen unidas en una
unica parte que es la de realizacion. Estas cuatro materias son:
Lenguajes de descripcion hardware En esta materia, que corresponde a la parte
de descripcion de circuitos, se analizan las diferentes formas de denir y describir
circuitos. El tema principal de esta materia es el lenguaje VHDL.
Simulacion Esta materia cubre los conceptos basicos de simulacion y comprobacion
de circuitos tanto digitales como analogicos.
Microelectronica Ya en la parte de realizacion la primera materia es la de micro-
electronica donde se explican los procesos de fabricacion de circuitos integrados
prestando especial atencion al proceso CMOS.
Circuitos Impresos Por ultimo se explica el proceso de fabricacion de circuitos im-
presos o PCBs (Printed Circuit Boards) revisando las diferentes posibilidades
tecnologicas tanto de encapsulados como de tolerancia al ruido, etc.
Los objetivos del curso, es decir, recorrer todo el ujo de dise~no desde la denicion
del problema hasta su realizacion practica, son extremadamente extensos por lo que
en el curso se da prioridad a unos temas dejando otros para ser explicados en otras
asignaturas dentro del programa general de la carrera de Ingeniera Informatica, y mas
particularmente de la lnea de optatividad del area de arquitectura y tecnologa de los
computadores.
Considerando los contenidos de otras asignaturas dentro de la carrera, y tambien las
actuales tendencias y demandas de la industria y el dise~no hardware, se ha optado por
hacer hincapie en los lenguajes de descripcion hardware. Es por estas razones que una
gran parte del curso esta dedicada al lenguaje VHDL como lenguaje de especicacion de
circuitos tanto para sntesis como para la realizacion de modelos de simulacion, siendo
esta parte la que se recoge en estos apuntes.
Fernando Pardo, en Valencia, Octubre de 1997
i
ii Prologo
Ingeniera Informatica Universidad de Valencia

Indice General
1 Metodologa de dise~no 1
1.1 Concepto de herramientas CAD-EDA . . . . . . . . . . . . . . . . . . . 1
1.2 Dise~no Bottom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Dise~no Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Ventajas del dise~no Top-Down . . . . . . . . . . . . . . . . . . . 5
1.4 Ingeniera concurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Descripcion del dise~no 9
2.1 Captura de esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Generacion de smbolos . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Dise~no modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Dise~no jerarquico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 El netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 El formato EDIF . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2 Otros formatos de Netlist . . . . . . . . . . . . . . . . . . . . . 14
2.5.3 Ejemplo de diferentes Netlist . . . . . . . . . . . . . . . . . . . . 15
3 Introduccion al lenguaje VHDL 21
3.1 El lenguaje VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1 VHDL describe estructura y comportamiento . . . . . . . . . . 23
3.2 Ejemplo basico de descripcion VHDL . . . . . . . . . . . . . . . . . . . 23
4 Elementos sintacticos del VHDL 27
4.1 Operadores y expresiones . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Tipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 Tipos escalares . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Tipos compuestos . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3 Subtipos de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Declaracion de constantes, variables y se~nales . . . . . . . . . . . . . . 32
4.5 Declaracion de entidad y arquitectura . . . . . . . . . . . . . . . . . . . 34
5 Ejecucion concurrente 39
5.1 Ejecucion concurrente y ejecucion serie . . . . . . . . . . . . . . . . . . 39
5.2 Descripcion comportamental RTL . . . . . . . . . . . . . . . . . . . . . 40
5.3 Estructuras de la ejecucion concurrente RTL . . . . . . . . . . . . . . . 41
6 Descripcion serie comportamental abstracta 45
6.1 Diferencias entre variable y se~nal . . . . . . . . . . . . . . . . . . . . . 47
6.2 Estructuras de la ejecucion serie . . . . . . . . . . . . . . . . . . . . . . 49
7 Poniendo orden: subprogramas, paquetes y libreras 57
7.1 Subprogramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1.1 Declaracion de procedimientos y funciones . . . . . . . . . . . . 58
iii
iv Indice General
7.1.2 Llamadas a subprogramas . . . . . . . . . . . . . . . . . . . . . 59
7.1.3 Sobrecarga de operadores . . . . . . . . . . . . . . . . . . . . . 60
7.2 Libreras, paquetes y unidades . . . . . . . . . . . . . . . . . . . . . . . 61
7.2.1 Paquetes: PACKAGE y PACKAGE BODY . . . . . . . . . . . . . . . . 64
7.2.2 Conguracion: CONFIGURATION . . . . . . . . . . . . . . . . . . 65
8 VHDL para simulacion 67
8.1 Los retrasos y la simulacion . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1.1 Retrasos inerciales y transportados . . . . . . . . . . . . . . . . 70
8.2 Descripcion de un banco de pruebas . . . . . . . . . . . . . . . . . . . . 71
8.3 Noticacion de sucesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.3.1 Procesos pasivos . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9 VHDL para sntesis 75
9.1 Restricciones en la descripcion . . . . . . . . . . . . . . . . . . . . . . . 76
9.2 Construcciones basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
9.2.1 Descripcion de logica combinacional . . . . . . . . . . . . . . . . 78
9.2.2 Descripcion de logica secuencial . . . . . . . . . . . . . . . . . . 79
10 Conceptos avanzados en VHDL 81
10.1 Buses y resolucion de se~nales . . . . . . . . . . . . . . . . . . . . . . . . 81
10.2 Descripcion de maquinas de estados . . . . . . . . . . . . . . . . . . . . 84
11 Utilizacion del lenguaje VHDL 89
11.1 Errores mas comunes usando VHDL . . . . . . . . . . . . . . . . . . . . 89
11.2 Ejemplos para simulacion y sntesis . . . . . . . . . . . . . . . . . . . . 91
11.2.1 El boton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.2.2 Los semaforos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
11.2.3 El ascensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.2.4 La memoria ROM . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11.2.5 El microprocesador . . . . . . . . . . . . . . . . . . . . . . . . . 98
11.2.6 La lavadora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
11.2.7 El concurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
11.2.8 El pin-ball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
11.3 Ejercicios propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Bibliografa 115
Indice de Materias 117

Indice de Figuras
1.1 Flujo de dise~no para sistemas electronicos y digitales . . . . . . . . . . 2
1.2 Metodologa de dise~no Bottom-Up . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metodologa de dise~no Top-Down . . . . . . . . . . . . . . . . . . . . . 5
2.1 Ejemplo de esquema para su descripcion Netlist . . . . . . . . . . . . . 15
3.1 Esquema del ejemplo basico en VHDL . . . . . . . . . . . . . . . . . . . 24
7.1 Las libreras y las unidades que la componen . . . . . . . . . . . . . . . 62
8.1 Flujo de simulacion por eventos en VHDL . . . . . . . . . . . . . . . . 69
8.2 Retrasos inerciales y transportados . . . . . . . . . . . . . . . . . . . . 70
11.1 Figura del ejercicio de la lavadora . . . . . . . . . . . . . . . . . . . . . 101
11.2 Figura del ejercicio del microondas . . . . . . . . . . . . . . . . . . . . 112
11.3 Figura del ejercicio de la maquina de cafe . . . . . . . . . . . . . . . . 113
v
vi Indice de Figuras

Captulo 1
Metodologa de dise~no
1.1 Concepto de herramientas CAD-EDA

En su sentido mas moderno, CAD (dise~no asistido por ordenador, del ingles Computer
Aided Design) signica proceso de dise~no que emplea sosticadas tecnicas gracas de
ordenador, apoyadas en paquetes de software para ayuda en los problemas analticos,
de desarrollo, de coste y ergonomicos asociados con el trabajo de dise~no.
En principio, el CAD es un termino asociado al dibujo como parte principal del
proceso de dise~no, sin embargo, dado que el dise~no incluye otras fases, el termino CAD
se emplea tanto como para el dibujo, o dise~no graco, como para el resto de herramientas
que ayudan al dise~no (como la comprobacion de funcionamiento, analisis de costes, etc.)
El impacto de las herramientas de CAD sobre el proceso de dise~no de circuitos
electronicos y sistemas procesadores es fundamental. No solo por la adicion de interfaces
gracas para facilitar la descripcion de esquemas, sino por la inclusion de herramientas,
como los simuladores, que facilitan el proceso de dise~no y la conclusion con exito de los
proyectos.
EDA (Electronic Design Automation) es el nombre que se le da a todas las he-
rramientas (tanto hardware como software) para la ayuda al dise~no de sistemas elec-
tronicos. Dentro del EDA, las herramientas de CAD juegan un importante papel, sin
embargo, no solo el software es importante, workstations cada da mas veloces, elemen-
tos de entrada de dise~no cada vez mas sosticados, etc. son tambien elementos que
ayudan a facilitar el dise~no de circuitos electronicos.
El dise~no hardware tiene un problema fundamental, que no existe, por ejemplo, en
la produccion del software. Este problema es el alto coste del ciclo dise~no-prototipacion-
testeo-vuelta a empezar, ya que el coste del prototipo suele ser, en general, bastante
elevado. Se impone la necesidad de reducir este ciclo de dise~no para no incluir la fase
de prototipacion mas que al nal del proceso, evitando as la repeticion de varios pro-
totipos que es lo que encarece el ciclo. Para ello se introduce la fase de simulacion y
comprobacion de circuitos utilizando herramientas de CAD, de forma que no es nece-
sario realizar fsicamente un prototipo para comprobar el funcionamiento del circuito,
economizando as el ciclo de dise~no. Este ciclo de dise~no hardware se muestra en detalle
en la gura 1.1.
1
2 Metodologa de dise~no
no
descripcion testeo sintesis extraccion de

si
idea correcto? mapeado
modelado simulacion tecnologico propiedades
no no
si testeo si producto
simulacion correcto? fabricacion funciona?
depurado acabado
Figura 1.1: Flujo de dise~no para sistemas electronicos y digitales
En el ciclo de dise~no hardware las herramientas de CAD estan presentes en todos

los pasos. En primer lugar en la fase de descripcion de la idea, que sera un esquema
electrico, un diagrama de bloques, etc. En segundo lugar en la fase de simulacion y com-
probacion de circuitos, donde diferentes herramientas permiten realizar simulaciones de
eventos, funcional, digital o electrica de un circuito atendiendo al nivel de simulacion
requerido. Por ultimo existen las herramientas de CAD orientadas a la fabricacion.
En el caso de dise~no hardware estas herramientas sirven para la realizacion de PCBs
(Printed Circuit Boards o placas de circuito impreso), y tambien para la realizacion
de ASICs (Application Specic Integrated Circuits) herramientas estas que nos permi-
ten la realizacion de microchips as como la realizacion y programacion de dispositivos
programables.
Herramientas CAD para el dise~no hardware:
Lenguajes de descripcion de circuitos. Son lenguajes mediante los cuales es po-
sible describir un circuito electrico o digital. La descripcion puede ser de blo-
ques, donde se muestra la arquitectura del dise~no, o de comportamiento, donde
se describe el comportamiento del circuito en vez de los elementos de los que
esta compuesto.
Captura de esquemas. Es la forma clasica de describir un dise~no electronico y la mas
extendida ya que era la unica usada antes de la aparicion de las herramientas de
CAD. La descripcion esta basada en un diagrama donde se muestran los diferentes
componentes de un circuito.
Grafos y diagramas de ujo. Es posible describir un circuito o sistema mediante
diagramas de ujo, redes de Petri, maquinas de estados, etc. En este caso sera una
descripcion graca pero, al contrario que la captura de esquemas, la descripcion
sera comportamental en vez de una descripcion de componentes.
Simulacion de sistemas. Estas herramientas se usan sobre todo para la simulacion
de sistemas. Los componentes de la simulacion son elementos de alto nivel como
discos duros, buses de comunicaciones, etc. Se aplica la teora de colas para la
simulacion.
Simulacion funcional. Bajando al nivel de circuitos digitales se puede realizar una
simulacion funcional. Este tipo de simulacion comprueba el funcionamiento de
circuitos digitales de forma funcional, es decir, a partir del comportamiento logico
de sus elementos (sin tener en cuenta problemas electricos como retrasos, etc.) se
1.2 Dise~no Bottom-Up 3
genera el comportamiento del circuito frente a unos estmulos dados.
Simulacion digital. Esta simulacion, tambien exclusiva de los circuitos digitales, es
como la anterior con la diferencia de que se tienen en cuenta retrasos en la propa-
gacion de las se~nales digitales. Es una simulacion muy cercana al comportamiento
real del circuito y practicamente garantiza el funcionamiento correcto del circuito
a realizar.
Simulacion electrica. Es la simulacion de mas bajo nivel donde las respuestas se ela-
boran a nivel del transistor. Sirven tanto para circuitos analogicos como digitales
y su respuesta es practicamente identica a la realidad.
Realizacion de PCBs. Con estas herramientas es posible realizar el trazado de pistas
para la posterior fabricacion de una placa de circuito impreso.
Realizacion de circuitos integrados. Son herramientas de CAD que sirven para la
realizacion de circuitos integrados. Las capacidades gracas de estas herramientas
permiten la realizacion de las diferentes mascaras que intervienen en la realizacion
de circuitos integrados.
Realizacion de dispositivos programables. Con estas herramientas se facilita la
programacion de este tipo de dispositivos, desde las simples PALs (Programmable
And Logic) hasta las mas complejas FPGAs (Field Programmable Gate Arrays),
pasando por las PLDs (Programmable Logic Devices)
1.2 Dise~no Bottom-Up

El termino Dise~no Bottom-Up (dise~no de abajo hacia arriba) se aplica al metodo de
dise~no mediante el cual se realiza la descripcion del circuito o sistema que se pretende
realizar, empezando por describir los componentes mas peque~nos del sistemas para, mas
tarde, agruparlos en diferentes modulos, y estos a su vez en otros modulos hasta llegar
a uno solo que representa el sistema completo que se pretende realizar. En la gura 1.2
se muestra esta metodologa de dise~no.
Esta metodologa de dise~no no implica una estructuracion jerarquica de los elementos
del sistema. Esta estructuracion, al contrario de lo que ocurre en el dise~no top-down
que se vera despues, se realiza una vez realizada la descripcion del circuito, y por tanto
no resulta necesaria.
En un dise~no bottom-up se empieza por crear una descripcion, con esquemas por
ejemplo, de los componentes del circuito. Estos componentes pertenecen normalmente
a una librera que contiene chips, resistencias, condensadores, y otros elementos que re-
presentan unidades funcionales con signicado propio dentro del dise~no. Estas unidades
se las puede conocer por el nombre de primitivas puesto que no es necesario disponer
de elementos de mas bajo nivel para describir el circuito que se pretende realizar.
En general, esta forma de dise~nar no es muy buena, ya que es un ujo de dise~no
bastante ineciente. Para dise~nos muy grandes, como los actuales, no se puede esperar
unir miles de componentes a bajo nivel y pretender que el dise~no funcione adecuada-
mente. El hecho de unir un numero elevado de componentes entre si sin una estructura
mas elevada que permita separarlos en bloques hace que sea complejo el analisis del
circuito, lo que provoca dicultades a la hora de detectar fallos en el circuito, anomalas
de funcionamiento, etc. Con esto, la probabilidad de cometer errores de dise~no se hace
mas elevada. Para poder encontrar errores de dise~no, o saber si el circuito realizara la
sistema
Figura 1.2: Metodologa de dise~no Bottom-Up
funcion para la que ha sido dise~nado, es necesario perder mucho mas tiempo en lo
que es la denicion, dise~no y analisis en alto nivel para ver entonces si funciona como
deseamos.
1.3 Dise~no Top-Down

El dise~no Top-Down es, en su mas pura forma, el proceso de capturar una idea en
un alto nivel de abstraccion, e implementar esa idea primero en un muy alto nivel, y
despues ir hacia abajo incrementando el nivel de detalle, segun sea necesario. Esta
forma de dise~nar se muestra gracamente en la gura 1.3 donde el sistema inicial se ha
dividido en diferentes modulos, cada uno de los cuales se encuentra a su vez subdividido
hasta llegar a los elementos primarios de la descripcion.
Los a~nos 80 trajeron una revolucion en las herramientas para el dise~no por ordena-
dor. Aunque esto no modico la forma de dise~nar s que mejoro la facilidad de hacerlo.
As, mediante el software disponible por ordenador, se podan dise~nar circuitos mas
complejos en, comparativamente, cortos periodos de tiempo (aunque se siguiera utili-
zando el dise~no bottom-up).
Pero hoy en da, nos encontramos en un marco en que es necesario hacer dise~nos
mas y mas complicados en menos tiempo. As, se puede descubrir que el ujo de dise~no
bottom-up es bastante ineciente. El problema basico del dise~no bottom-up es que no
permite acometer con exito dise~nos que contengan muchos elementos puesto que es facil
conectarlos de forma erronea. No se puede esperar unir miles de componentes de bajo
nivel, o primitivas, y conar en que el dise~no funcione adecuadamente.
Para esto existe la metodologa Top-down que sigue un poco el lema de \divide
1.3 Dise~no Top-Down 5
nivel alto
(Top)
nivel bajo
(Down)
Figura 1.3: Metodologa de dise~no Top-Down
y venceras", de manera que un problema, en principio muy complejo, es dividido en

varios subproblemas que a su vez pueden ser divididos en otros problemas mucho mas
sencillos de tratar. En el caso de un circuito esto se traducira en la division del sistema
completo en modulos, cada uno de los cuales con una funcionalidad determinada. A su
vez, estos modulos, dependiendo siempre de la complejidad del circuito inicial o de los
modulos, se pueden dividir en otros modulos hasta llegar a los componentes basicos del
circuito o primitivas.
1.3.1 Ventajas del dise~no Top-Down

Incrementa la productividad del dise~no. Este ujo de dise~no permite especicar
funcionalmente en un nivel alto de abstraccion sin tener que considerar la imple-
mentacion del mismo a nivel de puertas logicas. Por ejemplo se puede especicar
un dise~no en VHDL y el software utilizado generara el nivel de puertas directa-
mente. Esto minimiza la cantidad de tiempo utilizado en un dise~no.
Incrementa la reutilizacion del dise~no. En el proceso de dise~no se utilizan tec-
nologas genericas. Esto es, que no se ja la tecnologa a utilizar hasta pasos
posteriores en el proceso. Esto permite reutilizar los datos del dise~no unicamente
cambiando la tecnologa de implementacion. As es posible crear un nuevo dise~no
de uno ya existente.
Rapida deteccion de errores. Como se dedica mas tiempo a la denicion y al di-
se~no, se encuentran muchos errores pronto en el proceso de descripcion del circuito.
1.4 Ingeniera concurrente
En los a~nos ochenta, los suministradores de productos EDA se preocuparon sobre todo
de realizar herramientas mas veloces y workstations mas rapidas especialmente pensan-
do en un entorno de dise~no donde un producto es dise~nado en serie. La competencia
entre las diversas compa~nas se basaba en lo rapido que cada paso de la cadena de
dise~no poda realizarse.
En los noventa, la competencia se encuentra, no en lo rapido en que se puedan
completar los diferentes pasos de un dise~no, sino en que se pueda realizar ingeniera
concurrente. La ingeniera concurrente permite que se puedan utilizar datos de un paso
en el proceso de dise~no antes de que el paso previo haya sido completado. Esto implica
la existencia de monitores dentro del sistema de dise~no para comunicar adecuadamente
la actividad de dise~no hacia todos los pasos del proceso.
La forma mas sencilla de obtener un sistema concurrente es que todos los pasos
del proceso de dise~no compartan la misma base de datos. De esta manera, diferentes
herramientas correspondientes a diferentes pasos en el proceso de dise~no, comparten los
mismos datos. Un cambio realizado con una herramienta tiene efectos inmediatos sobre
la ejecucion de otra herramienta.
En general hay dos tipos diferentes de ingeniera concurrente:
Ingeniera concurrente personal. Viene referida a la posibilidad de realizar cambios
en el dise~no (esquema) sin tener que abandonar el analisis o simulacion, o las
herramientas de dise~no de circuitos impresos, por ejemplo.
Ingeniera concurrente de grupo. Este tipo permite, a los diferentes equipos de
expertos que trabajan en un dise~no, el solapar la creacion, analisis, y trazado de
un dise~no. Por ejemplo, un equipo puede estar simulando un circuito que otro
equipo acaba de modicar, etc.
En general, el elemento mas importante de un sistema EDA que permita dise~no
concurrente, es la base de datos. En esta base de datos, cada elemento es comun a
todas las herramientas que componen el sistema. Las diferencias entre una herramienta
y otra vendran de lo que la herramienta ve del elemento. As, cada elemento de la base
de datos estara compuesto por distintas vistas cada una asociada generalmente a una
herramienta del sistema.
En una herramienta de CAD, donde se incluyan diferentes fases del proceso de
dise~no como captura de esquemas, simulacion, etc, existe siempre la operacion por
la cual las herramientas posteriores del ujo de dise~no (como simulacion o dise~no de
PCBs) conocen los resultados de los pasos previos (como la captura de esquemas). A
esta operacion se le conoce con el nombre de preanotacion o forwardannotation y
consiste en que las herramientas anteriores dentro del ujo de dise~no, informan a las
herramientas posteriores de los cambios realizados en el dise~no.
En el caso de herramientas con capacidad para ingeniera concurrente se debe per-
mitir una operacion adicional. Esta operacion, muy importante dentro de la ingeniera
concurrente, es la retroanotacion o backannotation. Uno de los objetivos de la inge-
niera concurrente es la posibilidad de trabajar en fases del proceso de dise~no sin haber
completado previamente las fases anteriores. Para conseguir esto, no es unicamente ne-
cesario disponer de una base de datos unica, sino tambien, disponer de los mecanismos
necesarios para que, herramientas asociadas a fases anteriores del proceso de dise~no,
puedan saber de los cambios realizados por herramientas posteriores e incorporarlos
1.4 Ingeniera concurrente 7
a su vision especial del dise~no. Para esto existe el mecanismo de backannotation que
simplemente sirve para que herramientas pertenecientes a fases nales del proceso de
dise~no puedan anotar cambios a las fases iniciales del dise~no.
Por ejemplo, en un esquema podemos especicar el encapsulado de un chip, pero
puede que en la fase inicial del dise~no no se sepa todava. Es posible que en el proceso
de dise~no de las pistas de un circuito impreso, que sera una fase posterior, ya se
conozca dicho encapsulado. En este caso, la herramienta que realiza el dise~no del
circuito impreso puede backanotar la informacion del encapsulado a la herramienta de
captura de esquemas.


Captulo 2
Descripcion del dise~no
La primera tarea a realizar dentro del ujo de dise~no electronico, despues de concebir
la idea, es realizar una descripcion de lo que se pretende hacer. Los ordenadores ofrecen
hoy da herramientas especiales para la creacion y vericacion de dise~nos. Con dichas
herramientas es posible describir tanto un sencillo circuito, que represente una simple
puerta logica, como un complejo dise~no electronico.
En un principio, las herramientas de CAD se limitaban a servir de meros instru-
mentos de dibujo para poder realizar el dise~no; el dise~nador de circuitos realizaba la
descripcion a bajo nivel sobre un papel, utilizando smbolos y componentes basicos,
que luego trasladaba al computador para obtener una representacion mas ordenada.
Con la incorporacion de herramientas de fabricacion de PCBs, o circuitos integrados, o
simuladores, etc. la descripcion del circuito empezaba a jugar un papel mas importante
ya que serva como entrada de informacion a las herramientas posteriores en el ujo de
dise~no. E sto, unido a la metodologa Top-down de dise~no de circuitos, llevo a la apa-
ricion de herramientas de descripcion que permitieran al dise~nador denir el problema
de una forma abstracta de manera que fuera el ordenador quien se ocupara de realizar
la concretizacion de la idea.
Teniendo en cuenta esta evolucion, las herramientas de CAD actuales permiten las
siguientes posibilidades de abordar la descripcion de una idea o dise~no electronico:
Descripcion estructural. Consiste en enumerar los componentes de un circuito y sus
interconexiones. Dependiendo de la herramienta que se utilice hay dos formas de
hacerlo:
Esquemas. Es la forma tradicional en que los circuitos han sido dise~nados desde
que la electronica existe. Consiste en la descripcion graca de los compo-
nentes de un circuito.
Lenguaje. Se realiza una enumeracion de los componentes de un circuito as co-
mo su conexionado.
Descripcion comportamental. Es posible describir un circuito electronico (general-
mente digital) simplemente describiendo como se comporta. Para este tipos de
descripcion tambien se utiliza un lenguaje de descripcion hardware especco.
9
10 Descripcion del dise~no
2.1 Captura de esquemas
Con captura de esquemas se entiende el proceso de descripcion, mediante un dibujo, de
un circuito electrico. El dibujo del esquema puede incluir mas que un simple diagrama
de lneas. Puede incluir tambien informacion sobre tiempos, instancias, cables, conec-
tores, notas, y muchas otras propiedades importantes y valores necesarios por el resto
de aplicaciones para la interpretacion del mismo.
Un esquema viene especicado en la base de datos por dos partes fundamentales: las
hojas y los smbolos. En principio, un esquema puede estar formado por varias hojas
que es donde se dibujan los diversos componentes o smbolos que forman el circuito. En
las hojas se especican tambien las interconexiones as como informaciones adicionales
para el uso posterior del esquema en otras aplicaciones.
Los smbolos son cajas que se interconectan unas con otras en la hoja de dise~no.
Un smbolo es un objeto que contiene un conjunto de modelos usados para describir los
aspectos funcionales, gracos, temporales, y tecnologicos del dise~no electronico.
Hay dos tipos de smbolos. El primer tipo esta formado por los smbolos que repre-
sentan componentes basicos, o primitivas. Estos componentes denen un elemento que
se encuentra en el nivel mas bajo de la jerarqua de dise~no. As, este tipo de componen-
tes seran las resistencias, condensadores, transistores, puertas logicas, procesadores,
chips de memoria, etc.
Un segundo tipo de smbolos son aquellos que especican, no un elemento simple,
sino otro circuito completo, compuesto a su vez por smbolos, etc. Es decir, este segundo
tipo de smbolos son elementos que estan por encima de los smbolos basicos dentro
de la jerarqua. Normalmente este tipo de smbolos suelen tener asociados una hoja
que es la que describe sus componentes, aunque, con la aparicion de las descripciones
mediante lenguaje, es posible encontrar que dentro del smbolo en un esquema tenemos
una descripcion mediante lenguaje en vez de una hoja que sera lo esperable. Las
posibilidades de las herramientas de descripcion actuales son tales que permiten, sin
demasiados problemas, juntar en un mismo dise~no descripciones mediante gracos y
descripciones mediante lenguaje.
El metodo clasico para la interconexion de los distintos smbolos de una hoja son los
hilos o nets. Un hilo en el esquema tiene una correspondiente inmediata con el circuito
real, se trata de un cable fsico que conecta un pin de un chip con un pin de otro.
Sin embargo, dado que un esquema puede representar un nivel de abstraccion elevado
dentro de una jerarqua, un cable puede representar una conexion con un sentido mas
amplio, como por ejemplo una lnea telefonica, o un enlace de microondas a traves de
satelite.
Un cable en un esquema es un elemento que indica conexion, y en principio, puede
ser tanto un hilo de cobre, como una pista en un circuito impreso, como un conjunto de
hilos, como un cable de una interface serie, etc. Sin embargo, en los comienzos del dise~no
electronico, donde los esquemas correspondan en la mayora de los casos al nivel mas
bajo de una jerarqua, los cables eran siempre hilos conductores, y para representar
un conjunto de hilos conductores se introdujo otro elemento adicional, el bus. Un
bus es una conexion que une dos componentes al igual que un cable, sin embargo se
caracteriza por representar, no un unico hilo, sino multiples. La introduccion de este
elemento fue inmediata a partir del desarrollo de circuitos digitales, donde la conexion
entre procesadores, memorias, etc. era facilmente agrupable.
2.2 Generacion de smbolos 11
Actualmente, dada la gran complejidad de los dise~nos electronicos, con miles de
conexiones en una misma hoja, se hace necesario el uso de otras tecnicas de interco-
nexion de componentes. Una posibilidad que ofrecen la mayora de herramientas de
CAD es la utilizacion de etiquetas. Es posible poner etiquetas a los pines o a los cables,
de manera que dos pines o cables con la misma etiqueta o nombre estan fsicamente
interconectados. Esto evita el tener que trazar multiples conexiones entre componentes
evitando as una aglomeracion de hilos que haran ilegible cualquier esquema.
Otro elemento importante dentro de una hoja o esquema son los puertos. Los
puertos son conexiones al exterior de la hoja, y realizan la labor de interface del circuito
con el mundo exterior. En general, un esquema se puede ver como una caja negra donde
los puertos son la unica informacion visible. Esta caja negra, junto con sus puertos,
forma un componente que puede ser usado en otra hoja, que a su vez es un componente
que puede formar parte de otra hoja y as sucesivamente. Los puertos pueden ser de
entrada, de salida, o de entrada/salida, dependiendo de la direccion del ujo de la
informacion.
2.2 Generacion de smbolos

Como se ha comentado anteriormente, el concepto de smbolo tiene un sentido amplio;
puede representar tanto un componente fsico, como un transistor o un chip, o puede
representar un elemento abstracto, como un sistema, etc. que a su vez se encuentra
formado por distintos elementos o smbolos.
Los smbolos suelen estar formados por dos elementos fundamentales, el cuerpo y los
puertos. El cuerpo es simplemente un dibujo que en su forma mas generica puede ser
una simple caja. Los puertos son los elementos que realmente denen el componente
ya que indican la comunicacion con el exterior. Un componente puede no tener cuerpo
(aunque en principio resulta difcil trabajar con un elemento que no se ve) mientras se
pueda interconexionar con otros elementos, no se necesita nada mas.
Los smbolos mas simples, que corresponden a un elemento fsico, se encuentran
normalmente agrupados en libreras de smbolos. Para ser usados unicamente se necesita
copiarlos de la librera y meterlos en el dise~no. Hay otros elementos que no representan
primitivas, sino que representan otros esquemas en un nivel mas bajo de la jerarqua;
en estos casos, los smbolos no suelen estar agrupados en libreras sino que forman parte
de la base de datos que contiene el dise~no completo.
Las herramientas que soportan la metodologa de dise~no bottom-up o top-down, de-
ben proveer algun mecanismo para convertir las hojas en smbolos, es decir, coger un
esquema, con unas entradas y salidas, y generar una caja con las mismas entradas y
salidas que pueda ser usado como un smbolo mas en otras partes del dise~no. En princi-
pio, es muy sencillo generar un smbolo a partir de un esquema, siempre y cuando en el
esquema se especiquen adecuadamente los puertos de interconexion. Estos smbolos,
generados a partir de esquemas, sirven para la realizacion de dise~nos jerarquicos ya que
pueden ser usados en otros esquemas y as sucesivamente.
Aunque un smbolo solo necesita los puertos y un cuerpo, hay otra serie de elemen-
tos que resultan de mucha utilidad. Un elemento muy importante es el nombre, ya es
una forma de identicar el smbolo y resulta de utilidad para leer un esquema. Depen-
diendo de la utilizacion del smbolo puede ser interesante la adicion de otros elementos
o propiedades, as, para smbolos que representen chips, es muy interesante a~nadirles
informacion sobre el encapsulado del chip, una referencia para identicar individual-
mente a cada componente dentro del circuito, etc. Para otros componentes, dedicados
a simulacion por ejemplo, puede ser interesante a~nadirles propiedades sobre el retraso
de la se~nal, etc.
Un mismo smbolo puede representar varias cosas dentro de un dise~no. Lo que un
smbolo representa depende de la herramienta particular que se este utilizando. Su-
pongamos el caso muy simple de un contador. El smbolo del contador sera una caja
cuadrada, con una serie de entradas y salidas, pero >que representa realmente? Si por
ejemplo se esta realizando un circuito impreso, este smbolo del contador representa
el encapsulado con sus diferentes patillas, y las partes de cobre asociadas. Si por el
contrario, queremos realizar una simulacion para ver el comportamiento del contador,
en realidad el smbolo estara haciendo referencia a una descripcion del comportamiento
del circuito. Y aun pueden haber mas representaciones, el mismo smbolo del contador
puede representar a su vez una descripcion estructural (realizada con un lenguaje de
descripcion hardware como VHDL) o incluso otro esquema formado por smbolos mas
simples como puertas logicas o incluso transistores. El mismo smbolo representa mu-
chas cosas que conviven de forma concurrente en la misma base de datos. Lo que se
ve del smbolo dependera de la tarea que se realice en cada momento, as como de la
herramienta que se este utilizando.
2.3 Dise~no modular

El ujo de dise~no top-down, ofrece una ventaja adicional, y es que la informacion
se estructura de forma modular. El hecho de empezar la realizacion de un dise~no a
partir del concepto de sistema, hace que las subdivisiones se realicen de forma que los
diferentes modulos generados sean disjuntos entre s y no se solapen. De esta forma,
el dise~no modular sera la realizacion de dise~nos realizando divisiones funcionalmente
complementarias de los diversos componentes del sistema, permitiendo de esta manera
una subdivision clara y no solapada de las diferentes tareas dentro del dise~no.
El dise~no bottom-up, no ofrece tanta facilidad para la division del dise~no en partes
funcionalmente independientes. Al partir de los elementos basicos de los que se compone
el sistema, no resulta tan sencillo agruparlos de forma coherente. Esta es otra de las
desventajas del ujo de dise~no bottom-up, el resultado nal puede resultar bastante
confuso al no estar modularmente dividido.
2.4 Dise~no jerarquico

Un complejo dise~no electronico puede necesitar cientos de miles de componentes logicos
para describir correctamente su funcionamiento. Estos dise~nos necesitan que sean or-
ganizados de una forma que sea facil su comprension. Una forma de organizar el dise~no
es la creacion de un dise~no modular jerarquico tal y como se ha venido viendo cuando
se explicaba el ujo de dise~no top-down.
Una jerarqua consiste en construir un nivel de descripcion funcional de dise~no de-
bajo de otro de forma que cada nuevo nivel posee una descripcion mas detallada del
sistema. La construccion de dise~nos jerarquicos es la consecuencia inmediata de aplicar
el ujo de dise~no top-down.
2.5 El netlist 13
En la creacion de dise~nos jerarquicos es muy util la realizacion de bloques funcionales
o modulos. Un bloque funcional es un smbolo que representa un grupo de elementos en
alto nivel. Se puede pensar que un bloque funcional son particiones del dise~no original
con descripciones asociadas a las peque~nas unidades.
2.5 El netlist
El netlist es la primera forma de describir un circuito mediante un lenguaje, y consiste
en dar una lista de componentes, sus interconexiones y las entradas y salidas. No es
un lenguaje de alto nivel por lo que no describe como funciona el circuito sino que
simplemente se limita a describir los componentes que posee y las conexiones entre
ellos.
2.5.1 El formato EDIF

Dada la gran proliferacion de lenguajes para la comunicacion de descripciones del dise~no
entre herramientas, fue necesario crear un formato que fuera estandar y que todas las
herramientas pudieran entender. As es como aparecio el formato EDIF.
El formato EDIF (Electronic Design Interchange Format) es un estandar industrial
para facilitar el intercambio de datos de dise~no electronico entre sistemas EDA (Elec-
tronic Design Automation). Este formato de intercambio esta dise~nado para tener en
cuenta cualquier tipo de informacion electrica, incluyendo dise~no de esquemas, trazado
de pistas (fsicas y simbolicas), conectividad, e informacion de texto, como por ejemplo
las propiedades de los objetos de un dise~no.
El formato EDIF fue originalmente propuesto como estandar por Mentor Graphics,
Motorola, National Semiconductor, Texas Instruments, Daisy Systems, Tektronix, y la
Universidad de California en Berkeley, todos ellos embarcados cooperativamente en su
desarrollo. Desde entonces, el EDIF ha sido aceptado por mas y mas compa~nas. Fue
aprobado como estandar por la Electronic Industries Association (EIA) en 1987, y por
el American National Standards Institute (ANSI) en 1988.
La sintaxis de EDIF es bastante simple y comprensible, sin embargo, no se pretende
que sea exactamente un lenguaje de descripcion de hardware con el cual los dise~nadores
puedan denir sus circuitos, aunque hay algunos que lo utilizan directamente como
lenguaje de descripcion. La losofa del formato EDIF es mas la de un lenguaje de
descripcion para el intercambio de informacion entre herramientas de dise~no que un
formato para intercambio de informacion entre dise~nadores. En cualquier caso, siempre
es posible describir circuitos utilizando este lenguaje.
Un ejemplo de como sera el chero EDIF que describira un smbolo, de nombre
\pruotro", con una entrada llamada \in" y una salida llamada \out", se puede ver a
continuacion:
(edif EDIFFILENAME (edifVersion 2 0 0)
(edifLevel 0)
(keywordMap (keywordLevel 0))
(status
(written
(timeStamp 1995 2 20 18 2 40)
(author "Mentor Graphics Corporation")

(program "ENWRITE" (version "v8.4_2.1"))
)
)
(library (rename &_fasst_pardo_mentor "/fasst/pardo/mentor")
(edifLevel 0)
(technology
(numberDefinition
(scale 1 (e 1 -6) (unit distance)))
)
(cell pruotro (cellType generic)
(view pruotro (viewType netlist)
(interface
(port in (direction INPUT)
(property pin (string "in"))
(property pintype (string "in"))
)
(port out (direction OUTPUT)
(property pin (string "out"))
(property pintype (string "out"))
)
)
)
)
)
(design pruotro (cellRef pruotro (libraryRef &_fasst_pardo_mentor)))
)
Una de las caractersticas de este formato es la gran cantidad de informacion que

se puede recoger en un unico texto. En realidad, en el ejemplo anterior se mostraba
el EDIF de un unico smbolo con un pin de entrada y otro de salida. Todas las sen-
tencias iniciales son para la denicion de libreras, mientras que solo las ultimas sirven
para describir el smbolo. Esta descripcion empieza con la sentencia (cell pruotro
(cellType generic) donde se indica que se va a describir una c elula llamada inter-
namente pruotro. A continuacion vendra la seccion de interface donde se indican las
entradas y salidas. Estas entradas y salidas se indican mediante la sentencia port don-
de se indica ademas si el puerto es de entrada o salida. En cada descripcion de puerto
vienen ademas sentencias indicando propiedades del port. Por ejemplo el primer pin
tiene dos propiedades, una que indica el nombre, llamada pin y otra que indica el tipo
llamada pintype. Tanto el nombre de las propiedades como su valor son denibles
por el usuario. Estas propiedades son importantes ya que sirven para que otras herra-
mientas de dise~no puedan extraer informacion adicional sobre el circuito. Por ejemplo,
en la misma descripcion de puerto se podra haber incluido otra propiedad que fuera
retraso, de manera que esta informaci on pudiera ser utilizada por una herramienta de
simulacion por ejemplo.
2.5.2 Otros formatos de Netlist

Aunque el EDIF es el formato de intercambio estandar, dada su complejidad se utilizan
a veces otros lenguajes de Netlist mucho mas sencillos. Esto lo suelen hacer as los
fabricantes ya que les resulta mas sencillo interpretar una descripcion especialmente
pensada para sus herramientas que el formato EDIF que es tan generico que no es
sencillo tener una interface. Lo que suelen hacer los fabricantes es utilizar un lenguaje
propio y proveer los programas necesarios para pasar de su lenguaje al EDIF y viceversa,
de esta manera se aseguran la compatibilidad con el resto de herramientas del mundo,
y las suyas propias son mas sencillas de realizar.
2.5 El netlist 15
Un ejemplo de lenguaje de descripcion lo tenemos en el Tango, cuyo lenguaje de
netlist es muy simple y contempla muchas posibles descripciones, incluida la inclusion
de propiedades. Tango es un entorno de trabajo para PC que incluye herramientas de
descripcion y dise~no de PCBs. Mas adelante se vera un ejemplo de esta descripcion.
Otro formato de netlist, este muy usado directamente y no a partir de esquemas,
es el formato de descripcion de Spice. Spice es un simulador electrico, es decir, simula
transistores, resistencias, etc. aunque tambien permite la simulacion electrica de circui-
tos digitales. Este lenguaje es utilizado por el simulador para saber exactamente como
es el circuito a simular. Esta solamente indicado para ser utilizado con este programa
por lo que esta limitado su uso para otros propositos. Como ejemplo de las limitaciones
que presenta se puede decir que no permite la inclusion de propiedades en el dise~no.
2.5.3 Ejemplo de diferentes Netlist

Se presenta a continuacion un circuito y su descripcion usando los tres formatos que
se acaban de comentar. El circuito que se pretende describir aparece en la gura 2.1 y
se trata de un esquema que ha sido generado a partir de la herramienta de captura de
esquemas de Tango.
U1:A
S 1 U1:B
3 4
2 6 Q
5
7400
7400
ENA
U1:C
U1:D 9
12 8 Q*
11 10
R 13
7400
7400
Figura 2.1: Ejemplo de esquema para su descripcion Netlist

En primer lugar se presenta la descripcion EDIF de este simple circuito:
(edif TI
(edifVersion 2 0 0) (edifLevel 0) (keywordMap (keywordLevel 0))
(status
(written
(timeStamp 1996 2 22 19 40 43)
(dataOrigin "TANGO Schematic" (Version "1.30"))
(comment "Copyright (C) 1990 ACCEL Technologies Inc.")
)
)
(Design ROOT
(CellRef TI
(LibraryRef TI_LIB))
)
(Library TI_LIB (EdifLevel 0)
(technology (numberDefinition (scale 1 (E 254 -7) (unit DISTANCE))))
(cell U1 (cellType GENERIC)
(property Type (string "7400"))

(view S (viewType SCHEMATIC)
(interface
(Port A (Designator "1")
(Direction INPUT )
)
(Port B (Designator "2")
(Direction INPUT )
)
(Port Y (Designator "3")
(Direction OUTPUT )
)
(Direction INPUT )
)
(Direction INPUT )
)
(Direction OUTPUT )
)
(Port GND (Designator "7")
(property ElecType (string "Power") )
)
(Direction OUTPUT )
)
(Direction INPUT )
)
(Direction INPUT )
)
(Direction OUTPUT )
)
(Direction INPUT )
)
(Direction INPUT )
)
(Port VCC (Designator "14")
(property ElecType (string "Power") )
)
)
)
)
(cell TI (cellType GENERIC)
(view N
(viewType NETLIST)
(interface)
(Contents
(net ENA
(joined (portRef &B (viewRef S (cellRef U1)))
(portRef &A (viewRef S (cellRef U1)))
)
)
(net GND
(joined (portRef &GND (viewRef S (cellRef U1)))
)
)
(net NET_002
(portRef &Y (viewRef S (cellRef U1)))
)
)
(net NET_004
(joined (portRef &Y (viewRef S (cellRef U1)))

2.5 El netlist 17
)
)
(net Q
(joined (portRef &Y (viewRef S (cellRef U1)))
)
)
(net Q*
(portRef &Y (viewRef S (cellRef U1)))
)
)
(net R
)
)
(net S
(joined (portRef &A (viewRef S (cellRef U1)))
)
)
(net VCC
(joined (portRef &VCC (viewRef S (cellRef U1)))
)
)
)
)
)
)
)
Se ve que es una descripcion bastante larga para lo peque~no del circuito, pero esto es
necesario si se pretende una completa compatibilidad con el resto de herramientas que
existen. La primera parte es el encabezamiento y contiene basicamente comentarios. A
continuacion viene la parte de librera donde se denen los componentes que aparecen.
En este caso hay un unico componente, representado por cuatro smbolos, que corres-
ponde al 7400 de Texas Instruments y que contiene 4 puertas NAND. El componente
viene denido por sus puertos, cada uno con un nombre diferente y una direccion de
entrada o salida. Ademas, en este caso, cada puerto contiene un designator que sirve
para indicar la posicion del pin dentro del encapsulado que es un DIP14 en este caso.
Hay que destacar que aunque en el esquema no aparecen las tensiones de alimentacion,
s que aparecen en cambio en el Netlist. Esto es debido a que muchas veces estas ten-
siones, tanto VCC como GND, aparecen ocultas en los smbolos del esquema, pero son
necesarias en el Netlist ya que este debe contener absolutamente toda la informacion,
incluida la alimentacion del circuito.
Despues de la denicion del componente viene la denicion del interconexionado. El
emplazamiento del componente se realiza mediante la instruccion cell. Las intercone-
xiones se realizan en el bloque indicado por la palabra clave Contents. Cada conexion
se indica en un bloque net donde se indica el nombre y que cosas conecta mediante
el bloque joined. Por ejemplo, la primera conexion (ENA) conecta los puertos A y
B del chip U1 que es el 7400 especicado en la librera. Y as se van conectando los
diferentes elementos. Hay conexiones que no tienen nombre en el esquema, pero todas
las conexiones en un Netlist deben tener un nombre, as que lo que hace la herramienta
en estos casos es inventarse nombres. Este es precisamente el caso de las conexiones
NET 002 y NET 004 que son los nombres que la herramienta se ha inventado.
El listado que viene a continuacion corresponde a la descripcion del mismo circuito
pero utilizando un netlist propio de Tango:
[ GND ) R
U1 U1-7 ( U1-13
DIP14 ) Q )
7400 ( U1-6 (
] NET_002 U1-12 S
U1-10 ) U1-1
( U1-11 ( )
ENA ) Q* (
U1-5 ( U1-2 VCC
U1-9 NET_004 U1-8 U1-14
) U1-3 ) )
( U1-4 (
Se observa que esta descripcion es mucho mas simple y facil de entender que la
anterior. Ello es debido a que este Netlist no necesita ser estandar ni ser exportado a
ninguna otra herramienta, sino que debe servir unicamente para el entorno de Tango,
por lo que es posible simplicar mucho mas su descripcion.
En la cabecera, las primeras lneas encerradas entre corchetes, se encuentra la parte
de denicion de los elementos. Simplemente viene el nombre del chip (7400), su refe-
rencia dentro del esquema (U1) y una propiedad adicional que en el formato EDIF no
se encontraba, y es la propiedad que indica el tipo de encapsulado del smbolos; en este
caso, el valor de la propiedad de encapsulado es DIP14 que indica un encapsulado Dual
Inline Package de catorce pines. Esto es necesario en Tango puesto que este netlist va a
ser ledo tal cual por la herramienta de dise~no de PCBs por lo que es interesante saber
de antemano el encapsulado.
Despues de la denicion de los elementos que componen el esquema vienen las
interconexiones. E stas estan agrupadas entre parentesis. La primera conexion, net,
cable, etc, es ENA y se conoce porque es el primer nombre despues de abrir el parentesis.
A continuacion del nombre vienen todos los nodos a los que esta conectado. En el caso
de ENA se ve claramente que esta conectado a U1-5 y U1-9, es decir, ENA es una conexion
que conecta los pines 5 y 9 del chip U1 que es el unico en el esquema. Y el resto de
interconexiones se realizan de la misma manera.
El ultimo ejemplo corresponde a la descripcion para Spice del mismo circuito. Como
vamos a ver es la descripcion mas simple de todas ya que solo tiene un objetivo, y es la
de ser utilizada como entrada para un programa en concreto, el simulador Spice:
* TI CIRCUIT FILE
U1 S Q* 4 4 ENA Q 0 Q* ENA 2 2 Q R VCC 7400
.END
Toda la informacion del circuito se encuentra en la lnea segunda, con lo que todava
es mas simple de lo que parece. La primera es un comentario que ademas hace de ttulo
del netlist. En la segunda se encuentra la descripcion, y la ultima indica que se acabo la
descripcion.
La sintaxis es bien simple (lnea segunda). La primera palabra indica el nombre,
U1, y como empieza por la letra U, Spice ya sabe que se trata de un chip o componente.
Ademas sabe que todos los nombres que siguen corresponden a nombres de nodos o
conexiones y se corresponden con las entradas del chip. Solo el ultimo nombre indica
de que chip se trata, en este caso el 7400. En Spice dos nodos con el mismo nombre estan
conectados, as es facil ver que la conexion ENA conecta los pines 5 y 9 del componente
porque las posiciones quinta y novena del chip estan marcadas como ENA.
2.5 El netlist 19
Se han mostrado en esta seccion diversos tipos de Netlist y se han sacado algunas
conclusiones. La mas importante es que el netlist es un formato de intercambio de infor-
macion a nivel de herramientas cuya descripcion se basa en enumerar los componentes
del circuito y sus interconexiones. Otra conclusion importante es que existe un formato
estandar que sirve casi para cualquier herramienta, como es el formato EDIF. Otra cosa
que se ha visto es que la complejidad en la sintaxis depende de la generalidad del len-
guaje utilizado. As, el formato EDIF es el mas complejo puesto que es el mas generico
que existe. El resto de lenguajes, especcos para cada herramienta, pueden ser mucho
mas simples, pero se pierde generalidad, ya que con la simplicacion se esta eliminando
mucha informacion que puede ser util para determinado tipo de herramientas.


Captulo 3
Introduccion al lenguaje VHDL
Se vio en el captulo anterior, que la forma mas comun de describir un circuito era
mediante la utilizacion de esquemas que son una representacion graca de lo que se
pretende realizar. Con la aparicion de herramientas de EDA cada vez mas complejas,
que integran en el mismo marco de trabajo tanto las herramientas de descripcion,
sntesis y realizacion, aparecio tambien la necesidad de disponer de una descripcion del
circuito que permitiera el intercambio de informacion entre las diferentes herramientas
que componen la herramienta de trabajo.
En principio se utilizo un lenguaje de descripcion que permita, mediante sentencias
simples, describir completamente un circuito. A estos lenguajes se les llamo Netlist
puesto que eran simplemente eso, un conjunto de instrucciones que indicaban el inter-
conexionado entre los componentes de un dise~no, es decir, se trataba de una lista de
conexiones.
A partir de estos lenguajes simples, que ya eran autenticos lenguajes de descripcion
hardware, se descubrio el interes que podra tener el describir los circuitos directamente
utilizando un lenguaje en vez de usar esquemas. Sin embargo, se siguieron utilizando
esquemas puesto que desde el punto de vista del ser humano son mucho mas sencillos
de entender, aunque un lenguaje siempre permite una edicion mas sencilla y rapida.
Con una mayor sosticacion de las herramientas de dise~no, y con la puesta al alcance
de todos de la posibilidad de fabricacion de circuitos integrados y de circuitos con logica
programable, fue apareciendo la necesidad de poder describir los circuitos con un alto
grado de abstraccion, no desde el punto de vista estructural, sino desde el punto de
vista funcional. Exista la necesidad de poder describir un circuito pero no desde el
punto de vista de sus componentes, sino desde el punto de vista de como funcionaba.
Este nivel de abstraccion se haba alcanzado ya con las herramientas de simulacion.
Para poder simular partes de un circuito era necesario disponer de un modelo que des-
cribiera el funcionamiento de ese circuito, o componente. Estos lenguajes estaban sobre
todo orientados a la simulacion, por lo que poco importaba que el nivel de abstraccion
fuera tan alto que no fuera sencillo una realizacion o sntesis a partir de dicho modelo.
Con la aparicion de tecnicas para la sntesis de circuitos a partir de un lenguaje
de alto nivel, se utilizaron como lenguajes de descripcion precisamente estos lenguajes
de simulacion, que si bien alcanzan un altsimo nivel de abstraccion, su orientacion
es basicamente la de simular, por lo que los resultados de una sntesis a partir de
descripciones con estos lenguajes no es siempre la mas optima. En estos momentos no
21
22 Introduccion al lenguaje VHDL
parece que exista un lenguaje de alto nivel de abstraccion cuya orientacion o nalidad
sea la de la sntesis automatica de circuitos, por lo que todava, de hecho se empieza
ahora, se utilizan estos lenguajes orientados a la simulacion tambien para la sntesis de
circuitos.
3.1 El lenguaje VHDL

VHDL, viene de VHSIC (Very High Speed Integrated Circuit) Hardware Description
Language. VHDL es un lenguaje de descripcion y modelado dise~nado para describir (en
una forma que los humanos y las maquinas puedan leer y entender) la funcionalidad y
la organizacion de sistemas hardware digitales, placas de circuitos, y componentes.
VHDL fue desarrollado como un lenguaje para el modelado y simulacion logica di-
rigida por eventos de sistemas digitales, y actualmente se lo utiliza tambien para la
sntesis automatica de circuitos. El VHDL fue desarrollado de forma muy parecida al
ADA debido a que el ADA fue tambien propuesto como un lenguaje puro pero que tu-
viera estructuras y elementos sintacticos que permitieran la programacion de cualquier
sistema hardware sin limitacion de la arquitectura. El ADA tena una orientacion hacia
sistemas en tiempo real y al hardware en general, por lo que se lo escogio como modelo
para desarrollar el VHDL.
VHDL es un lenguaje con una sintaxis amplia y exible que permite el modelado
estructural, en ujo de datos y de comportamiento hardware. VHDL permite el mode-
lado preciso, en distintos estilos, del comportamiento de un sistema digital conocido y
el desarrollo de modelos de simulacion.
Uno de los objetivos del lenguaje VHDL es el modelado. Modelado es el desarrollo
de un modelo para simulacion de un circuito o sistema previamente implementado cuyo
comportamiento, por tanto, se conoce. El objetivo del modelado es la simulacion.
Otro de los usos de este lenguaje es la sntesis automatica de circuitos. En el
proceso de sntesis, se parte de una especicacion de entrada con un determinado nivel
de abstraccion, y se llega a una implementacion mas detallada, menos abstracta. Por
tanto, la sntesis es una tarea vertical entre niveles de abstraccion, del nivel mas alto
en la jerarqua de dise~no se va hacia el mas bajo nivel de la jerarqua.
El VHDL es un lenguaje que fue dise~nado inicialmente para ser usado en el modelado
de sistemas digitales. Es por esta razon que su utilizacion en sntesis no es inmediata,
aunque lo cierto es que la sosticacion de las actuales herramientas de sntesis es tal
que permiten implementar dise~nos especicados en un alto nivel de abstraccion.
La sntesis a partir de VHDL constituye hoy en da una de las principales aplicaciones
del lenguaje con una gran demanda de uso. Las herramientas de sntesis basadas en
el lenguaje permiten en la actualidad ganancias importantes en la productividad de
dise~no.
Algunas ventajas del uso de VHDL para la descripcion hardware son:
VHDL permite dise~nar, modelar, y comprobar un sistema desde un alto nivel de
abstraccion bajando hasta el nivel de denicion estructural de puertas.
Circuitos descritos utilizando VHDL, siguiendo unas guas para sntesis, pueden ser
utilizados por herramientas de sntesis para crear implementaciones de dise~nos a
nivel de puertas.
3.2 Ejemplo basico de descripcion VHDL 23
Al estar basado en un estandar (IEEE Std 1076-1987) los ingenieros de toda la in-
dustria de dise~no pueden usar este lenguaje para minimizar errores de comunicacion
y problemas de compatibilidad.
VHDL permite dise~no Top-Down, esto es, permite describir (modelado) el com-
portamiento de los bloques de alto nivel, analizandolos (simulacion), y renar la
funcionalidad de alto nivel requerida antes de llegar a niveles mas bajos de abstrac-
cion de la implementacion del dise~no.
Modularidad: VHDL permite dividir o descomponer un dise~no hardware y su des-
cripcion VHDL en unidades mas peque~nas.
3.1.1 VHDL describe estructura y comportamiento

Existen dos formas de describir un circuito. Por un lado se puede describir un circuito
indicando los diferentes componentes que lo forman y su interconexion, de esta manera
tenemos especicado un circuito y sabemos como funciona; esta es la forma habitual
en que se han venido describiendo circuitos y las herramientas utilizadas para ello han
sido las de captura de esquemas y las descripciones netlist.
La segunda forma consiste en describir un circuito indicando lo que hace o como
funciona, es decir, describiendo su comportamiento. Naturalmente esta forma de des-
cribir un circuito es mucho mejor para un dise~nador puesto que lo que realmente lo que
interesa es el funcionamiento del circuito mas que sus componentes. Por otro lado, al
encontrarse lejos de lo que un circuito es realmente puede plantear algunos problemas
a la hora de realizar un circuito a partir de la descripcion de su comportamiento.
El VHDL va a ser interesante puesto que va a permitir los dos tipos de descripciones:
Estructura: VHDL puede ser usado como un lenguaje de Netlist normal y corriente
donde se especican por un lado los componentes del sistema y por otro sus
interconexiones.
Comportamiento: VHDL tambien se puede utilizar para la descripcion comporta-
mental o funcional de un circuito. Esto es lo que lo distingue de un lenguaje de
Netlist. Sin necesidad de conocer la estructura interna de un circuito es posible
describirlo explicando su funcionalidad. Esto es especialmente util en simulacion
ya que permite simular un sistema sin conocer su estructura interna, pero este
tipo de descripcion se esta volviendo cada da mas importante porque las actuales
herramientas de sntesis permiten la creacion automatica de circuitos a partir de
una descripcion de su funcionamiento.
3.2 Ejemplo basico de descripcion VHDL

Ejemplo 3.1 Describir en VHDL un circuito que multiplexe dos lneas (a y b) de un
bit, a una sola lnea (salida) tambien de un bit; la se~nal selec sirve para indicar que
a la salida se tiene la lnea a (selec='0') o b (selec='1').
En la gura 3.1 se muestra el circuito implementado con puertas logicas que realiza
la funcion de multiplexacion.
Lo que se va a realizar a continuacion es la descripcion comportamental del circuito
de la gura 3.1, y luego se realizara la descripcion estructural para ver las diferen-
u0 u1
selec nosel
ax
u3
a salida
u2
b bx
Figura 3.1: Esquema del ejemplo basico en VHDL
cias. Mas adelante se vera que hay dos tipos de descripcion comportamental, pero de
momento, el presente ejemplo unicamente pretende introducir el lenguaje VHDL y su
estructura.
La sintaxis del VHDL no es sensible a mayusculas o minusculas por lo que se puede
escribir como se preera. A lo largo de las explicaciones se intentara poner siempre las
palabras claves del lenguaje en mayusculas para distinguirlas de las variables y otros
elementos.
En primer lugar, sea el tipo de descripcion que sea, hay que denir el smbolo o
entidad del circuito. En efecto, lo primero es denir las entradas y salidas del circuito,
es decir, la caja negra que lo dene. Se le llama entidad porque en la sintaxis de VHDL
esta parte se declara con la palabra clave ENTITY. Esta denicion de entidad, que suele
ser la primera parte de toda descripcion VHDL, se expone a continuacion:
-- Los comentarios empiezan por dos guiones
ENTITY mux IS
PORT ( a: IN bit;
b: IN bit;
selec: IN bit;
salida: OUT bit);
END mux;
Esta porcion del lenguaje indica que la entidad mux (que es el nombre que se le ha
dado al circuito) tiene tres entradas de tipo bit, y una salida tambien del tipo bit. Los
tipos de las entradas y salidas se veran mas adelante. El tipo bit simplemente indica
una lnea que puede tomar los valores '0' y '1'.
La entidad de un circuito es unica, sin embargo, se mostro que un mismo smbolo, en
este caso entidad, poda tener varias vistas o en el caso de VHDL arquitecturas. Cada
bloque de arquitectura, que es donde se describe el circuito, puede ser una representacion
diferente del mismo circuito. Por ejemplo, puede haber una descripcion estructural y
otra comportamental, ambas son descripciones diferentes, pero ambas descripciones
corresponden al mismo circuito, smbolo, o entidad. Veamos entonces la descripcion
comportamental:
ARCHITECTURE comportamental OF mux IS
BEGIN
PROCESS(a,b,selec)
BEGIN
IF (selec='0') THEN
salida<=a;

3.2 Ejemplo basico de descripcion VHDL 25
ELSE
salida<=b;
END IF;
END PROCESS;
END comportamental;
Mas adelante se vera lo que hace un bloque PROCESS, de momento, y como primera
aproximacion, se considerara que es una especie de subrutina cuyas instrucciones se
ejecutan secuencialmente cada vez que algunas de las se~nales de la lista sensible cambia.
Esta lista sensible es una lista de se~nales que se suele poner junto a la palabra clave
PROCESS, y en el caso del ejemplo es (a,b,selec).
Esta descripcion comportamental es muy sencilla de entender ya que sigue una
estructura parecida a los lenguajes de programacion convencionales. Lo que se esta in-
dicando es simplemente que si la se~nal selec es cero, entonces la salida es la entrada a, y
si selec es uno, entonces la salida es la entrada b. Esta forma tan sencilla de describir el
circuito permite a ciertas herramientas sintetizar un circuito a partir de una descripcion
comportamental como esta. La diferencia con un Netlist es directa: en una descripcion
comportamental no se estan indicando ni los componentes ni sus interconexiones, sino
simplemente lo que hace, es decir, su comportamiento o funcionamiento.
La descripcion anterior era puramente comportamental, de manera que con una
secuencia sencilla de instrucciones podamos denir el circuito. Naturalmente, a veces
resulta mas interesante describir el circuito de forma que este mas cercano a una posible
realizacion fsica del mismo. En ese sentido VHDL posee una forma de describir circuitos
que ademas permite la paralelizacion de instrucciones1 y que se encuentra mas cercana
a una descripcion estructural del mismo. A continuacion se muestran dos ejemplos de
una descripcion concurrente o tambien llamada de transferencia entre registros:
ARCHITECTURE transferencia OF mux IS ARCHITECTURE transferencia OF mux IS
SIGNAL nosel,ax,bx: bit; BEGIN
BEGIN salida<=a WHEN selec='0' ELSE b;
nosel<=NOT selec; END transferencia;
ax<=a AND nosel;
bx<=b AND selec;
salida<=ax OR bx;
END transferencia;
En la descripcion de la izquierda hay varias instrucciones todas ellas concurrentes,

es decir, se ejecutan cada vez que cambia alguna de las se~nales que intervienen en
la asignacion. Este primer caso es casi una descripcion estructural ya que de alguna
manera se estan deniendo las se~nales (cables) y los componentes que la denen, aunque
no es comportamental ya que en realidad se trata de asignaciones a se~nales y no una
descripcion de componentes y conexiones. El segundo caso (derecha) es tambien una
descripcion de transferencia aunque basta una unica instruccion de asignacion para
denir el circuito.
Aunque no es la caracterstica mas interesante del VHDL, tambien permite ser usado
como Netlist o lenguaje de descripcion de estructura. En este caso, esta estructura
tambien estara indicada dentro de un bloque de arquitectura, aunque la sintaxis interna
es completamente diferente:
ARCHITECTURE estructura OF mux IS
1Un lenguaje que describa hardware debe permitir ejecucion paralela o lo que es lo mismo instruc-
ciones concurrentes

COMPONENT and2
PORT(e1,e2: IN bit; y: OUT bit);
END COMPONENT;
COMPONENT or2
PORT(e1,e2: IN bit; y: OUT bit);
END COMPONENT;
COMPONENT inv
PORT(e: IN bit; y: OUT bit);
END COMPONENT;
SIGNAL ax,bx,nosel: bit;
BEGIN
u0: inv PORT MAP(e=>selec,y=>nosel);
u1: and2 PORT MAP(e1=>a,e2=>nosel,y=>ax);
u2: and2 PORT MAP(e1=>b,e2=>sel,y=>bx);
u3: or2 PORT MAP(e1=>ax,e2=>bx,y=>salida);
END estructura;
Se observa facilmente que esta descripcion es mas larga y encima menos clara que
las anteriores. Dentro de la arquitectura se denen en primer lugar los componentes que
se van a utilizar. Esto se realiza mediante la palabra clave COMPONENT, donde se indican
ademas las entradas y salidas mediante la clausula PORT. Estos componentes deben
tener una entidad y arquitectura propia indicando su comportamiento. Normalmente
estas entidades se suelen poner en una librera separada. De momento declararemos
estos componentes de esta manera y supondremos que la entidad se encuentra en algun
sitio que por ahora no nos preocupa mucho.
Al igual que ocurre en cualquier netlist, las se~nales o conexiones deben tener un
nombre. En el esquema se le han puesto nombres a las lneas de conexion internas al
circuito. Estas lneas hay que declararlas como SIGNAL en el cuerpo de la arquitectura
y delante del BEGIN. Una vez declarados los componentes y las se~nales que intervienen
se procede a conectarlos entre si. Para ello la sintaxis es muy simple. Lo primero
es identicar cada componente, es lo que comunmente se conoce como instanciacion,
es decir, asignarle a cada componente concreto un smbolo. En este ejemplo se le
ha llamado u a cada componente y se le ha a~nadido un numero para distinguirlos,
en principio el nombre puede ser cualquier cosa y la unica condicion es que no haya
dos nombres iguales. A continuacion del nombre viene el tipo de componente que es,
en nuestro caso puede ser una and2, una or2, o una puerta inversora inv. Despues
se realizan las conexiones poniendo cada se~nal en su lugar correspondiente con las
palabras PORT MAP. As, los dos primeros argumentos en el caso de la puerta and2 son
las entradas, y el ultimo es la salida. De esta forma tan simple se va creando el netlist
o denicion de la estructura.

Captulo 4
Elementos sintacticos del VHDL
El lenguaje VHDL es verdaderamente un lenguaje, por lo que tiene sus elementos
sintacticos, sus tipos de datos, y sus estructuras como cualquier otro tipo de lenguaje.
El hecho de que sirva para la descripcion hardware lo hace un poco diferente de un
lenguaje convencional. Una de estas diferencias es probablemente la posibilidad de
ejecutar instrucciones a la vez de forma concurrente.
Algunos de estos elementos sintacticos se muestran a continuacion:
Comentarios: Cualquier lnea que empieza por dos guiones \,," es un comentario.
Identicadores: Son cualquier cosa que sirve para identicar variables, se~nales, nom-
bres de rutina, etc. Puede ser cualquier nombre compuesto por letras incluyendo
el smbolo de subrayado \ ". Las mayusculas y minusculas son consideradas igua-
les, as que JOSE y jose representan el mismo elemento. No puede haber ningun
identicador que coincida con alguna de las palabras clave del VHDL.
Numeros: Cualquier numero se considera que se encuentra en base 10. Se admite
la notacion cientca convencional para numeros en coma otante. Es posible
poner numeros en otras bases utilizando el smbolo del sostenido \#". Ejemplo:
2#11000100# y 16#C4# representan el entero 196.
Caracteres: Es cualquier letra o caracter entre comillas simples: 'l','3','t'.
Cadenas: Son un conjunto de caracteres englobados por comillas dobles: "Esto es
una cadena".
Cadenas de bits: Los tipos bit y bit vector son en realidad de tipo caracter y
matriz de caracteres respectivamente. En VHDL se tiene una forma elegante de
denir numeros con estos tipos y es mediante la cadena de bits. Dependiendo de
la base en que se especique el numero se puede poner un prejo B (binario), O
(octal), o X (hexadecimal). Ejemplo: B"11101001", O"126", X"FE".
4.1 Operadores y expresiones

Las expresiones en VHDL son practicamente iguales a como pudieran ser en otros len-
guajes de programacion o descripcion, por lo que se expondran brevemente los existentes
en VHDL y su utilizacion.
27
28 Elementos sintacticos del VHDL
Operadores varios
& (concatenacion) Concatena matrices de manera que la dimension de la matriz re-
sultante es la suma de las dimensiones de las matrices sobre las que opera:
punto<=x&y mete en la matriz punto la matriz x en las primeras posiciones,
y la matriz y en las ultimas.
Operadores aritmeticos
** (exponencial) Sirve para elevar un numero a una potencia: 4**2 es 42. El operador
de la izquierda puede ser entero o real, pero el de la derecha solo puede ser entero.
ABS() (valor absoluto) Como su propio nombre indica esta funcion devuelve el valor
absoluto de su argumento que puede ser de cualquier tipo numerico.
* (multiplicacion) Sirve para multiplicar dos numeros de cualquier tipo (los tipos bit
o bit vector no son numericos).
/ (division) Tambien funciona con cualquier dato de tipo numerico.
MOD (modulo) Calcula en modulo de dos numeros. Exactamente se dene el modulo
como la operacion que cumple: a=b*N+(a MOD b) donde N es un entero. Los
operandos solo pueden ser enteros. El resultado toma el signo de b.
REM (resto) Calcula el resto de la division entera y se dene como el operador que
cumple: a=(a/b)*b+(a REM b), siendo la division entera. Los operandos solo
pueden ser enteros. El resultado toma el signo de a.
+ (suma y signo positivo) Este operador sirve para indicar suma, si va entre dos ope-
randos, o signo, si va al principio de una expresion. La precedencia es diferente
en cada caso. Opera sobre valores numericos de cualquier tipo.
, (resta y signo negativo) Cuando va entre dos operandos se realiza la operacion de
sustraccion, y si va delante de una expresion le cambia el signo. Los operandos
pueden ser numericos de cualquier tipo.
Operadores de desplazamiento
SLL, SRL (desplazamiento logico a izquierda y a derecha) Desplaza un vector un
numero de bits a izquierda (SLL) o derecha (SRL) rellenando con ceros los huecos
libres. Se utiliza en notacion inja de manera que la se~nal a la izquierda del
operador es el vector que se quiere desplazar y el de la derecha es un valor que
indica el numero de bits a desplazar. Por ejemplo dato SLL 2 desplaza a izquierda
el vector dato, es decir, lo multiplica por 4.
SLA, SRA (desplazamiento aritmetico a izquierda y derecha)
ROL, ROR (rotacion a izquierda y a derecha) Es como el de desplazamiento pero los
huecos son ocupados por los bits que van quedando fuera.
Operadores relacionales
Devuelven siempre un valor de tipo booleano (TRUE o FALSE). Los tipos con los que
pueden operar dependen de la operacion:
=, /= (igualdad) El primero devuelve TRUE si los operandos son iguales y FALSE en
caso contrario. El segundo indica desigualdad, as que funciona justo al reves.
4.2 Tipos de datos 29
Los operandos pueden ser de cualquier tipo con la condicion de que sean ambos
del mismo tipo.
<,<=,>,>= (menor mayor) Tienen el signicado habitual. La diferencia con los ante-
riores es que los tipos de datos que pueden manejar son siempre de tipo escalar o
matrices de una sola dimension de tipos discretos.
Operadores logicos
Son NOT, AND, NAND, OR, NOR y XOR. El funcionamiento es el habitual para este tipo
de operadores. Actuan sobre los tipos bit, bit vector y boolean. En el caso de
realizarse estas operaciones sobre un vector, la operacion se realiza bit a bit, incluyendo
la operacion NOT.
Precedencia de operadores y sobrecarga

La precedencia de operadores se presenta en la siguiente tabla:
** ABS NOT Maxima precedencia
* / MOD REM
+(signo) -(signo)
+ - &
= /= < <= > >=
AND OR NAND NOR XOR Minima precedencia
Se ha visto que, por ejemplo, los operadores logicos solo operaban sobre unos tipos
de datos determinados. Existe en VHDL la posibilidad de sobrecargar operadores y
funciones, como se vera mas adelante, de manera que es posible extender la aplicacion
de estos operadores para que trabajen con otros tipos aparte de los predenidos. As,
se podran redenir los operadores logicos para que pudieran trabajar sobre enteros.
4.2 Tipos de datos

Como en cualquier lenguaje, VHDL tiene dos grupos de tipos de datos. Por un lado
estan los escalares, con los que se pueden formar el otro grupo que son los compuestos.
4.2.1 Tipos escalares

Son tipos simples que contienen algun tipo de magnitud. Veamos a continuacion los
tipos escalares presentes en VHDL:
Enteros: Son datos cuyo contenido es un valor numerico entero. La forma es que se
denen estos datos es mediante la palabra clave RANGE, es decir, no se dice que un
dato es de tipo entero, sino que se dice que un dato esta comprendido en cierto
intervalo especicando los lmites del intervalo con valores enteros.
Ejemplos:
TYPE byte IS RANGE 0 TO 255;
TYPE index IS RANGE 7 DOWNTO 1;
TYPE integer IS -2147483647 TO 2147483647; -- Predefinido en el lenguaje

Este ultimo tipo viene ya predenido en el lenguaje aunque no es muy conveniente
su utilizacion, especialmente pensando en la posterior sntesis del circuito.
Fsicos: Como su propio nombre indica se trata de datos que se corresponden con
magnitudes fsicas, es decir, tienen un valor y unas unidades.
Ejemplo:
TYPE longitud IS RANGE 0 TO 1.0e9
UNITS
um;
mm=1000 um;
m=1000 mm;
in=25.4 mm;
END UNITS;
Hay un tipo fsico predenido en VHDL que es time. Este tipo se utiliza para
indicar retrasos y tiene todos los submultiplos, desde fs (femtosegundos), hasta
hr (horas). Cualquier dato fsico se escribe siempre con su valor seguido de la
unidad: 10 mm, 1 in, 23 ns.
Reales: Conocidos tambien como coma otante, son los tipos que denen un numero
real. Al igual que los enteros se denen mediante la palabra clave RANGE, con la
diferencia de que los lmites son numeros reales.
Ejemplos:
TYPE nivel IS RANGE 0.0 TO 5.0;
TYPE real IS RANGE -1e38 TO 1e38; -- Predefinido en el lenguaje
Enumerados: Son datos que pueden tomar cualquier valor especicado en un conjunto
nito o lista. Este conjunto se indica mediante una lista encerrada entre parentesis
de elementos separados por comas.
Ejemplos:
TYPE nivel_logico IS (nose,alto,bajo,Z);
TYPE bit IS ('0','1'); -- Predefinido en el lenguaje
Hay varios tipos enumerados que se encuentran predenidos en VHDL. Estos tipos
son: severity level, boolean, bit y character.
4.2.2 Tipos compuestos

Son tipos de datos que estan compuestos por los tipos de datos escalares vistos ante-
riormente.
Matrices: Son una coleccion de elementos del mismo tipo a los que se accede mediante
un ndice. Su signicado y uso no diere mucho de la misma estructura presente
en casi todos los lenguajes de programacion. Los hay monodimensionales (un
ndice) o multidimensionales (varios ndices). A diferencia de otros lenguajes, las
matrices en VHDL pueden estar enmarcadas en un rango, o el ndice puede ser
libre teniendo la matriz una dimension teorica innita.
Ejemplos:
TYPE word IS ARRAY(31 DOWNTO 0) OF bit;
TYPE transformada IS ARRAY(1 TO 4, 1 TO 4) OF real;
TYPE positivo IS ARRAY(byte RANGE 0 TO 127) OF integer;
TYPE string IS ARRAY(positive RANGE <>) OF character; -- Predefinido en VHDL
TYPE bit_vector IS ARRAY(natural RANGE <>) OF bit; -- Predefinido en VHDL
TYPE vector IS ARRAY(integer RANGE <>) OF real;
Este ultimo ejemplo, y los dos anteriores, muestran una matriz cuyo ndice no
tiene rango sino que sirve cualquier entero. Mas tarde, en la declaracion del dato,
4.2 Tipos de datos 31
se podra poner los lmites de la matriz: SIGNAL cosa: vector(1 TO 20);
Los elementos de una matriz se acceden mediante el ndice. As dato(3) es
el elemento 3 del dato. De la misma manera se puede acceder a un rango:
datobyte<=datoword(2 TO 9). Tambi en pueden utilizar en las asignaciones lo
que se conoce como agregados o conjuntos (aggregate) que no es mas que una lista
separada por comas de manera que al primer elemento de la matriz se le asigna
el primer elemento de la lista, y as sucesivamente. Veamos algunos ejemplos:
semaforo<=(apagado,encendido,apagado);
dato<=(datohigh,datolow);
bus<=(OTHERS=>'Z');
Quiza el que se entiende menos es el ultimo donde se ha empleado la palabra
OTHERS para poner todos los bits del bus a 'Z', de esta forma ponemos un ventor
a un valor sin necesidad de saber cuantos bits tiene la se~nal.
Registros: Es equivalente al tipo registro o record de otros lenguajes.
Ejemplo:
TYPE trabajador IS
RECORD
nombre: string;
edad: integer;
END RECORD;
Para referirse a un elemento dentro del registro se utiliza la misma nomenclatura
que en Pascal, es decir, se usa un punto entre el nombre del registro y el nombre
del campo: persona.nombre="Jose"
4.2.3 Subtipos de datos

VHDL permite la denicion de subtipos que son restricciones o subconjuntos de tipos
existentes. Hay dos tipos. El primero son subtipos obtenidos a partir de la restriccion
de un tipo escalar a un rango. Ejemplos:
SUBTYPE raro IS integer RANGE 4 TO 7;
SUBTYPE digitos IS character RANGE '0' TO '9';
SUBTYPE natural IS integer RANGE 0 TO entero_mas_alto; -- Predefinido en VHDL
SUBTYPE positive IS integer RANGE 1 TO entero_mas_alto; -- Predefinido en VHDL
El segundo tipo de subtipos son aquellos que restringen el rango de una matriz:
SUBTYPE id IS string(1 TO 20);
SUBTYPE word IS bit_vector(31 DOWNTO 0);
Los subtipos sirven ademas para crear tipos resueltos que es es una clase especial de
tipos que se explicara en detalle en la seccion 10.1.
La ventaja de utilizar un subtipo es que las mismas operaciones que servan para el
tipo sirven igual de bien para el subtipo. Esto tiene especial importancia por ejemplo
cuando se describe un circuito para ser sintetizado, ya que si utilizamos integer sin
mas, esto se interpretara como un bus de 32 lneas (puede cambiar dependiendo de la
plataforma) y lo mas probable es que en realidad necesitemos muchas menos. Otro caso
se da cuando tenemos una lista de cosas y les queremos asignar un entero a cada una,
dependiendo de las operaciones que queramos hacer puede resultar mas conveniente
denirse un subtipo a partir de integer que crear un tipo enumerado.
4.3 Atributos
Los elementos en VHDL, como se~nales, variables, etc, pueden tener informacion adicio-
nal llamada atributos. Estos atributos estan asociados a estos elementos del lenguaje y
se manejan en VHDL mediante la comilla simple \ ' ". Por ejemplo, t'LEFT indica el
atributo 'LEFT de t que debe ser un tipo escalar (este atributo indica el lmite izquierdo
del rango).
Hay algunos de estos atributos que estan predenidos en el lenguaje y a continuacion
se muestran los mas interesantes. Suponiendo que t es un tipo escalar tenemos los
siguientes atributos:
t'LEFT Lmite izquierdo del tipo t.
t'RIGHT Lmite derecho del tipo t.
t'LOW Lmite inferior del tipo t.
t'HIGH Lmite superior del tipo t.
Para tipos t, x miembro de este tipo, y N un entero, se pueden utilizar los siguientes
atributos:
t'POS(x) Posici on de x dentro del tipo t.
t'VAL(N) Elemento N del tipo t.
t'LEFTOF(x) Elemento que est a a la izquierda de x en t.
t'RIGHTOF(x) Elemento que est a a la derecha de x en t.
t'PRED(x) Elemento que est a delante de x en t.
t'SUCC(x) Elemento que est a detras de x en t.
Para a siendo un tipo u elemento de tipo matriz, y N un entero de 1 a al numero de
dimensiones de la matriz, se pueden usar los siguientes atributos:
a'LEFT(N) Lmite izquierdo del rango de dimensi on N de a.
a'RIGHT(N) Lmite derecho del rango de dimensi on N de a.
a'LOW(N) Lmite inferior del rango de dimensi on N de a.
a'HIGH(N) Lmite superior del rango de dimensi on N de a.
a'RANGE(N) Rango del ndice de dimensi on N de a.
a'LENGTH(N) Longitud del ndice de dimensi on N de a.
Suponiendo que s es una se~nal, se pueden utilizar los siguientes atributos (se han
cogido los mas interesantes):
s'EVENT Indica si se ha producido un cambio en la se~nal.
s'STABLE(t) Indica si la se~nal estuvo estable durante el ultimo periodo t.
El atributo 'EVENT es especialmente util en la denicion de circuitos secuenciales para
detectar el anco de subida o bajada de la se~nal de reloj. Es por esto que es probable-
mente el atributo mas utilizado en VHDL.
4.4 Declaracion de constantes, variables y se~nales

Un elemento en VHDL contiene un valor de un tipo especicado. Hay tres tipos de
elementos en VHDL, estan las variables, las se~nales y las constantes. Las variables y
4.4 Declaracion de constantes, variables y se~nales 33
constantes son una cosa muy parecida a las variables y constantes que se encuentran en
cualquier lenguaje. Las se~nales, en cambio, son elementos cuyo signicado es bastante
diferente y es consecuencia directa de que aunque VHDL es un lenguaje muy parecido
a los convencionales, no deja en ningun momento de ser un lenguaje de descripcion
hardware, por lo que cabe esperar algunas diferencias.
Constantes
Una constante es un elemento que se inicializa a un determinado valor y no puede ser
cambiado una vez inicializado, conservando para siempre su valor. Ejemplos:
CONSTANT e: real := 2.71828;

CONSTANT retraso: time := 10 ns;
CONSTANT max_size: natural;
En la ultima sentencia, la constante max size no tiene ningun valor asociado. Esto
se permite siempre y cuando el valor sea declarado en algun otro sitio. Esto se hace
as para las declaraciones en packages que se veran mas adelante.
Variables
Una variable es lo mismo que una constante con la diferencia de que su valor puede ser
alterado en cualquier instante. A las variables tambien se les puede asignar un valor
inicial.
VARIABLE contador: natural := 0;

VARIABLE aux: bit_vector(31 DOWNTO 0);
Es posible, dado un elemento previamente denido, cambiarle el nombre o ponerle

nombre a una parte. Esto se realiza mediante la instruccion ALIAS que resulta muchas
veces muy util. Ejemplo:
VARIABLE instruccion: bit_vector(31 DOWNTO 0);

ALIAS codigo_op: bitvector(7 DOWNTO 0) IS instruccion(31 DOWNTO 24);
Se~nales
Las se~nales se declaran igual que las constantes y variables con la diferencia de que las
se~nales pueden ademas ser de varios tipos que son normal, register y bus. Por defecto
son de tipo normal. Al igual que en variables y constantes, a las se~nales se les puede
dar un valor inicial si se quiere. Ejemplos:
SIGNAL selec: bit := '0';

SIGNAL datos: bit_vector(7 DOWNTO 0) BUS := B"00000000";

Constantes, se~nales y variables
Constantes, se~nales y variables son cosas diferentes. Las variables, por ejemplo, solo
tienen sentido dentro de un proceso (PROCESS) o un subprograma, es decir, solo tie-
nen sentido en entornos de programacion donde las sentencias son ejecutadas en serie,
por tanto las variables solo se declaran en los procesos o subprogramas. Las se~nales
pueden ser declaradas unicamente en las arquitecturas, paquetes (PACKAGE), o en los
bloques concurrentes (BLOCK). Las constantes pueden ser habitualmente declaradas en
los mismos sitios que las variables y se~nales.
Mientras que las variables son elementos abstractos con poco signicado fsico, las
se~nales tienen un signicado fsico inmediato y es el de representar conexiones reales en
el circuito. La se~nales pueden ser usadas en cualquier parte del programa o descripcion
y son declaradas siempre en la parte de arquitectura antes del BEGIN. Esto indica que
las se~nales son visibles por todos los procesos y bloques dentro de una arquitectura, por
lo que en realidad representan interconexiones entre bloques dentro de la arquitectura.
Desde un punto de vista software, las se~nales representan el mecanismo que va a per-
mitir ejecutar en paralelo las instrucciones concurrentes, es decir, VHDL implementa el
mecanismo de sincronizacion de procesos por monitorizacion para la ejecucion paralela
de instrucciones.
En un dise~no, las conexiones fsicas entre unos elementos y otros son habitualmente
declaradas como se~nales. Las entradas y salidas, denidas en la entidad, son, por lo
tanto, consideradas se~nales. Aunque estas entradas y salidas son en realidad se~nales,
hay algunas diferencias; por ejemplo las salidas no se pueden leer, es decir, no pueden
formar parte del argumento de una asignacion. De la misma manera, a una entrada no
se le puede asignar un valor en la descripcion.
La diferencia principal entre variables y se~nales es que una asignacion a una variable
se realiza de forma inmediata, es decir, la variable toma el valor que se le asigna en
el mismo momento de la asignacion. La se~nal, en cambio, no recibe el valor que se
le esta asignando hasta el siguiente paso de simulacion, es decir, cuando el proceso
se acaba al encontrar una sentencia WAIT dentro de un proceso o al nal de este si
no tiene sentencias de espera. Esta forma extra~na en que se les asignan valores a las
se~nales se entendera mejor cuando se explique el signicado de los procesos, la ejecucion
concurrente y secuencial, y los pasos de simulacion.
4.5 Declaracion de entidad y arquitectura

Ya se ha visto, en anteriores ejemplos, como se declaran tanto las entidades como las
arquitecturas. Veremos a continuacion que en la declaracion de estas estructuras se
pueden incluir otros elementos, aunque en la mayora de los casos tanto la entidad
como la estructura se declaran de las formas vistas hasta el momento.
Declaracion de entidad
La entidad es la parte del programa que dene el modulo. Es decir, dene las entradas
y salidas del circuito. Ademas, la entidad es la estructura que permite en VHDL
realizar dise~nos jerarquicos, ya que un dise~no jerarquico es generalmente una coleccion
4.5 Declaracion de entidad y arquitectura 35
de modulos interconectados entre s. En VHDL estos modulos se denen mediante la
palabra clave ENTITY:
id_instr:
ENTITY nombre IS
GENERIC(lista de propiedades);
PORT(lista de puertos);
declaraciones
BEGIN
sentencias
END nombre;
Se observa facilmente que la declaracion de entidad es una cosa algo mas compleja de
lo que se haba visto. La primera cosa que destaca es la palabra id instr, seguida por
dos puntos, delante de ENTITY. Esto es algo comun a todas las instrucciones en VHDL,
siempre se puede poner un nombre para identicar unas instrucciones de otras. Este
nombre es opcional, se puede poner casi en cualquier instruccion, y permite realizar
un mejor seguimiento de la ejecucion de un programa durante la simulacion. Esta
informacion extra esta especialmente indicada para estructuras de tipo PROCESS que de
por s no tienen ningun nombre asignado, pero se puede usar en casi cualquier otro tipo
de estructura.
Las partes GENERIC y PORT son las mas usadas en la entidad. La instruccion GENERIC
sirve para denir y declarar propiedades o constantes del modulo que esta siendo decla-
rado en la entidad. Las constantes declaradas aqu tienen el mismo signicado que las
constantes declaradas como parametros en las funciones y procedimientos que se veran
mas adelante. Es decir, a la entidad se le pueden pasar como parametros las constantes
denidas en GENERIC, si se pasan valores entonces la constante tomara el valor que se
le pasa, y sino se le pasa ningun valor, la constante tomara el valor que se asigne en
GENERIC.
Con la palabra clave PORT, tambien opcional como el resto de partes de la entidad,
se denen las entradas y salidas del modulo que esta siendo denido. Esta forma de
declarar estas entradas y salidas ya se ha visto, y simplemente consiste en un nombre,
seguido por el tipo de conexion, y seguido por el tipo de datos de la lnea. Habamos
visto dos tipos de conexiones que eran IN, para indicar entrada, y OUT para indicar
salida.
La diferencia entre IN y OUT es importante: las se~nales de entrada se pueden leer
pero no pueden asignarseles ningun valor, es decir, no se puede cambiar su valor
en el programa, y vienen a ser como constantes. Las se~nales de salida pueden cambiar
y se les pueden asignar valores, pero no pueden leerse, es decir, no pueden ser usadas
como argumentos en la asignacion de cualquier elemento del VHDL.
Junto a los tipos IN y OUT existen otros que tambien pueden ser usados. Estos otros
tipos son el INOUT que sirve tanto de entrada como de salida por lo que pueden ser
usados en el programa como de lectura y escritura. Hay que tener un poco de cuidado
con este tipo, ya que su signicado hardware nunca hay que olvidarlo de manera que
pueden producirse contenciones en la misma lnea, cuestion que a nivel de programa
importa poco, pero que a nivel de hardware puede destruir un chip. Otro tipo que
existe es el BUFFER que es equivalente al INOUT visto con anterioridad, con la diferencia
de que solo una fuente puede escribir sobre el. El ultimo tipo, muy poco usado, es el
LINKAGE que es como el INOUT tambi en pero que solo puede ser usado con elementos
de tipo LINKAGE. Si no se especica el tipo de puerto se supone el tipo IN por defecto.
Por ultimo, la parte de declaraciones es opcional, como todo lo que va dentro de la
entidad, y sirve para realizar algunas declaraciones de constantes, etc. A continuacion
le sigue un bloque BEGIN, tambien opcional, donde se pueden incluir sentencias. Esta
parte no se suele usar casi nunca. El tipo de sentencias que se pueden usar en esta parte
son muy restringidas y se limitan a sentencias de indicacion de errores o comprobacion
de alguna cosa. Ejemplos de declaracion de entidad:
ENTITY rom IS
GENERIC(tamano, ancho: positive);
PORT(enable : IN bit;
address : IN bit_vector(tamano-1 DOWNTO 0);
data: OUT bit_vector(ancho-1 DOWNTO 0));
END rom;
ENTITY procesador IS
GENERIC(max_freq: frequency := 30 MHz);
PORT(clk: IN bit;
address: OUT integer;
data: INOUT word_32;
control: OUT proc_control;
ready: IN bit);
END procesador;
Declaracion de arquitectura
En la arquitectura es donde se dene el funcionamiento del modulo denido en la
entidad. Una arquitectura siempre esta referida a una entidad concreta por lo que no
tiene sentido hacer declaraciones de arquitectura sin especicar la entidad. Una misma
entidad puede tener diferentes arquitecturas, es en el momento de la simulacion o la
sntesis cuando se especica que arquitectura concreta se quiere simular o sintetizar.
La declaracion de la arquitectura se realiza mediante la palabra clave ARCHITECTURE
y su sintaxis completa es:
id_instr:
ARCHITECTURE nombre OF la_entidad IS
declaraciones
BEGIN
Instrucciones
END nombre;
La estructura de esta declaracion es parecida a la que ya se haba visto en los

ejemplos.
Antes de denir la funcionalidad en el bloque BEGIN...END, hay una parte declara-
tiva donde se denen los subprogramas (funciones, procedimientos, etc), declaraciones
de tipo, declaraciones de constantes, declaraciones de se~nales, declaraciones de alias,
declaraciones de componentes, etc. Es importante destacar que las se~nales solo pueden
ser declaradas dentro de la parte declarativa de una arquitectura.
A continuacion vienen, despues del BEGIN, todas las instrucciones que denen el
comportamiento, estructura y funcionalidad del circuito. Hay que destacar que dentro
de la arquitectura las instrucciones son de dos tipos, o concurrentes, o de instanciacion
que es en realidad tambien una construccion concurrente. En el caso de denir estruc-
tura las instrucciones seran de instanciacion, es decir, de colocacion de componentes
y las conexiones entre ellos. En el caso de querer una descripcion mas abstracta se
4.5 Declaracion de entidad y arquitectura 37
pueden utilizar las asignaciones concurrentes RTL que se veran a continuacion. Hay
que rese~nar que una de estas instrucciones concurrentes es el bloque PROCESS dentro
del cual la ejecucion puede ser secuencial.


Captulo 5
Ejecucion concurrente
Se vio en el ejemplo 3.1, en el captulo 3, que el lenguaje VHDL no solo serva para
la descripcion estructural de un circuito sino tambien para su descripcion funcional.
En VHDL existen dos aproximaciones a la descripcion comportamental de un cir-
cuito. Por un lado se pueden especicar las ecuaciones de transferencia entre diferentes
objetos en VHDL. A esta posibilidad de descripcion de un circuito se le llama descrip-
cion de ujo de datos, o tambien, reriendose al nivel de abstraccion descripcion a nivel
de transferencia entre registros, conocido por las siglas RTL (Register Transfer Level).
Existe otra forma de describir circuitos en un nivel de abstraccion todava mas elevado.
A este nivel se le conoce como descripcion comportamental propiamente dicha. Esta
segunda posibilidad incluye a la primera y permite al dise~nador de circuitos describir
la funcionalidad en un nivel de abstraccion alto.
La diferencia mas importante entre un estilo de descripcion y el otro es que la
ejecucion, o interpretacion de sentencias en el nivel RTL es concurrente, es decir, las
sentencias, mas que mandatos o comandos, indican conexiones o leyes que se cumplen,
por tanto, es como si se ejecutaran continuamente. En la descripcion comportamental
abstracta es posible describir partes con instrucciones que se ejecutan en serie de la
misma manera que se ejecutan los comandos en un lenguaje como el C o Pascal.
A nivel de sntesis siempre es mas sencillo sintetizar un circuito descrito al nivel
RTL que otro descrito en un nivel mas abstracto. Esto es debido a que la mayora de
estructuras de la descripcion RTL tienen una correspondencia casi directa con su imple-
mentacion hardware correspondiente. En un nivel mas abstracto, la sntesis automatica
del circuito es mas compleja, especialmente debido a la ejecucion en serie de las instruc-
ciones que tienen mucho sentido en la ejecucion de programas, pero cuyo signicado
hardware es algo mas difuso.
5.1 Ejecucion concurrente y ejecucion serie

En lenguajes como el C, Pascal, Fortran, etc. la ejecucion de las sentencias es en serie.
Esto signica que las sentencias son ejecutadas una tras otra por el microprocesador.
Naturalmente esta ejecucion es unicamente valida para arquitecturas basadas en un
unico procesador con memoria principal. Naturalmente este es un caso particular de
sistema, muy utilizado por otra parte, pero que no se trata del caso general. En general,
cualquier sistema hardware esta compuesto por numerosas unidades procesadoras con
39
40 Ejecucion concurrente
unidades de almacenamiento distribuidos. En estos sistemas se puede hacer una progra-
macion en serie, pero resulta poco efectiva puesto que no se explota el paralelismo que
una arquitectura as puede proveer. Para especicar la funcionalidad de un sistema que
permita paralelismo, es necesario utilizar un lenguaje que permita una especicacion
concurrente, paralela, de sus instrucciones siendo la ejecucion serie un caso particular
de la ejecucion concurrente.
Un sistema digital peque~no, por ejemplo un sumador o multiplicador, se puede ver
como un sistema compuesto por multiples unidades procesadoras (puertas NAND y
NOR) y por tanto se puede decir que se trata de un sistema multiprocesador, si bien
no es lo que comunmente se entiende como tal. En este caso, cada procesador es una
unidad muy simple, una puerta logica, pero no por ello deja de ser un sistema con
multiples unidades funcionales; por lo tanto, la descripcion de tal sistema, aun siendo
tan simple, debe ser concurrente. Es por esto que cualquier lenguaje que pretenda
describir hardware debe ser como mnimo concurrente, es decir, sus sentencias no se
ejecutan cuando les llega el turno sino que son como aseveraciones que se deben cumplir
siempre.
La arquitectura tpica monoprocesadora es un circuito hardware y por tanto inter-
namente tendra muchas unidades funcionales que funcionan en paralelo, sin embargo,
desde el punto de vista del programador del sistema solo existe un procesador que es el
que ejecuta el programa que se le introduce. Es por esto que solo existe una instruccion
concurrente, que es precisamente el programa serie que se esta ejecutando.
Es conocida la facilidad algortmica de una ejecucion serie, y es por esto por lo que
resulta tan sencillo programar un sistema monoprocesador. Esto es debido en parte al
nivel de abstraccion que se consigue con una descripcion algortmica serie al encontrarse
cercano a la forma en que los seres humanos abordamos los problemas. Por lo tanto, se
puede decir que la ejecucion serie se encuentra en un nivel alto de abstraccion, o mas
cercano al pensamiento humano, que la concurrente. Es por esto que en un alto nivel
de abstraccion de un circuito deba poderse incluir una descripcion serie de lo que se
quiere describir.
Lenguajes como el VHDL o el ADA, pensados para programar y describir sistemas
(ADA), o circuitos (VHDL), deben ser en primer lugar de ejecucion concurrente, y te-
ner, como caso particular de sentencia concurrente, la posibilidad de ejecucion serie de
alguna parte de codigo. En el caso del VHDL, cuyo objetivo es mas la descripcion de
los circuitos poco complejos de nivel medio, es bastante comun que toda la descripcion
sea a base de sentencias concurrentes. A una descripcion de este tipo, muy cercana al
hardware fsico, se le llama descripcion de transferencia entre registros. Si ademas la
descripcion incluye sentencias que se ejecutan en serie, entonces el nivel de abstraccion
con el que se esta describiendo el circuito es mas alto y se considera que la descripcion
es puramente comportamental. La descripcion de transferencia de registros se encon-
trara por tanto a mitad de camino entre una descripcion puramente estructural y la
puramente comportamental.
5.2 Descripcion comportamental RTL

Este estilo de descripcion se encuentra a mitad de camino entre una descripcion es-
tructural del circuito y una descripcion completamente abstracta del mismo. En cierto
sentido es parecido a un netlist, pero en este caso las interconexiones son entre obje-
5.3 Estructuras de la ejecucion concurrente RTL 41
tos abstractos del lenguaje en vez de entre componentes fsicos. Ademas, se permiten
estructuras de tipo condicional que facilitan la abstraccion de ciertos comportamientos.
A esta descripcion se le llama tambien de ujo de datos puesto que las instrucciones
son todas de asignacion, siendo precisamente los datos los que gobiernan el ujo de
ejecucion de las instrucciones.
En el ejemplo 3.1 se mostro la descripcion de un multiplexor sencillo. Entonces se
presentaron tres posibles descripciones, la primera, que era completamente estructural,
y las otras dos comportamentales, una de ellas con ejecucion serie y la otra, de la que
se dieron dos ejemplos, RTL.
De los dos ejemplos de descripcion RTL, haba uno con una unica instruccion, y otro
con tres mas cercano al hardware. Es facil comprobar que la descripcion con una unica
instruccion es incluso mas simple que la vista en aquel ejemplo donde haban, ademas,
otras sentencias y bloques como el PROCESS cuyo signicado se entendera mejor mas
adelante cuando se explique el estilo de descripcion completamente comportamental o
abstracto.
Se observa que la ejecucion en estas descripciones RTL no es serie, es decir, no se
ejecuta instruccion por instruccion, sino que la unica instruccion que hay se ejecuta
continuamente, o sea, como si siempre estuviera activa. A esta forma de ejecutarse las
instrucciones se la conoce como ejecucion concurrente y es propia de las descripciones
RTL. Veremos a continuacion un ejemplo de esta ejecucion concurrente.
Ejemplo 5.1 Realizar una descripcion RTL, transferencia entre registros, de un com-
parador de dos buses (a y b) de 11 bits. El comparador tendra tres salidas activas a
nivel alto. Una se activara si a=b, otra si a>b, y la ultima si a<b.
ENTITY comp IS
PORT(a,b: IN bit_vector(10 DOWNTO 0);
amayb,aeqb,amenb: OUT bit);
END comp;
ARCHITECTURE flujo OF comp IS

BEGIN
amayb<='1' WHEN a>b ELSE '0';
aeqb <='1' WHEN a=b ELSE '0';
amenb<='1' WHEN a<b ELSE '0';
END flujo;
En esta ocasion se tienen tres instrucciones en vez de una. Estas instrucciones no se

ejecutan en serie, sino de forma concurrente. Es decir, cuando se simula este circuito, se
leen estas instrucciones de manera que si alguna de las se~nales que intervienen cambia
(a o b) entonces se ejecutan las instrucciones que se vean afectadas por este cambio, en
este caso todas.
5.3 Estructuras de la ejecucion concurrente RTL

La instruccion basica de la ejecucion concurrente es la asignacion entre se~nales que
viene gobernada por el operador <=. Para facilitar la tarea de realizar asignaciones algo
complejas, VHDL introduce algunos elementos de alto nivel como son instrucciones
condicionales, de seleccion, etc. En los ejemplos anteriores ya se han mostrado algunas
de estas instrucciones como la instruccion condicional basica que se haca mediante
la construccion WHEN..ELSE. Veremos a continuacion otras estructuras propias de la
ejecucion concurrente o descripcion RTL.
Asignacion condicional: WHEN...ELSE
Ya se ha visto anteriormente y su utilizacion es muy sencilla. Es importante, en toda

expresion condicional que describa hardware de forma concurrente, incluir todas las
opciones posibles y contemplar todos los casos posibles de variacion de una variable.
En este sentido es obligatorio siempre acabar esta expresion condicional con un ELSE.
Se pueden anidar varias condiciones en una misma asignacion. Ejemplo:
s<='1' WHEN a=b ELSE
'0' WHEN a>b ELSE
'X';
Asignacion con seleccion: WITH...SELECT...WHEN
Es una ampliacion del condicional y es similar a las construcciones case o switch del
Pascal o C. La asignacion se hace segun el contenido de cierto objeto o resultado de
cierta expresion. Ejemplo:
WITH estado SELECT
semaforo<="rojo" WHEN "01",
"verde" WHEN "10",
"amarillo" WHEN "11",
"no funciona" WHEN OTHERS;
Es obligatorio, al igual que ocurra con la asignacion condicional, incluir todos los
posibles valores que pueda tomar la expresion. Por lo tanto, si no se especican todos
los valores en las clausulas WHEN entonces hay que incluir la clausula WHEN OTHERS. Esto
es as ya que de lo contrario la expresion podra tomar valores frente a los cuales no se
sabe que respuesta dar.
Bloque concurrente: BLOCK
En muchas ocasiones es interesante agrupar sentencias de ejecucion concurrente en

bloques. Estos bloques son el mecanismo que tiene VHDL para la realizacion de dise~nos
modulares, de alguna manera tienen cierta equivalencia con las hojas de la captura de
esquemas. Estos bloques van a permitir ademas subdividir un mismo programa en
una jerarqua de modulos ya que estos bloques o modulos pueden estar unos dentro de
otros. Estos bloques estan denidos dentro de la arquitectura en entornos de ejecucion
concurrente y de alguna manera son equivalentes a entidades ya que se les puede denir
entradas y salidas, aunque quiza su uso mas normal es el agrupamiento de instrucciones
para separar el dise~no en modulos.
La estructura general de la declaracion de bloque se muestra a continuacion:
block_id:
BLOCK(expresion de guardia)

5.3 Estructuras de la ejecucion concurrente RTL 43
cabecera
declaraciones
BEGIN
sentencias concurrentes
END BLOCK block_id;
El nombre block id es opcional y su uso sirve para nombrar a diferentes bloques en

un mismo dise~no y as ayudar en la depuracion, simulacion y sobre todo en la legibilidad
del programa.
La cabecera puede tener clausulas de tipo generico, declaraciones de puertos de
entrada salida, etc, es decir, es equivalente a la declaracion de entidad y su alcance es
el del bloque. El hecho de poder declararse puertos de entrada y salida en un bloque, y
as conectarlos con un nivel superior dentro del programa, es especialmente interesante
ya que va a permitir el uso de un bloque, que por ejemplo tenamos en otro dise~no, e
incorporarlo al nuevo sin necesidad de cambiar todas las se~nales internas del bloque.
Por ejemplo, supongamos que tenemos una memoria ROM denida como bloque con
entradas direccion y enable, y salida dato; entonces estas se~nales se denen con
PORT como la entidad, y la conexi on entre estas se~nales y todo lo de fuera, que vamos a
suponer que son las se~nales rom dir, rom ena y rom dato, mediante PORT MAP, es decir:
rom: BLOCK
PORT(direccion: IN bit_vector(15 DOWNTO 0);
enable: IN bit;
dato: OUT bit_vector(7 DOWNTO 0));
PORT MAP(direccion=>rom_dir,enable=>rom_ena,dato=>rom_dato);
BEGIN
...
END BLOCK rom;
En la parte de declaracion se puede incluir desde subprogramas a se~nales al igual

que al principio de la arquitectura, siendo la visibilidad local al bloque lo que permite
la modularidad y portabilidad del codigo.
La expresion de guardia es opcional, y permite la habilitacion o deshabilitacion de la
asignacion de determinadas se~nales dentro del bloque, en concreto, aquellas que empleen
la palabra clave GUARDED (vigilado) en su asignacion. La expresion de guardia es de
tipo booleano, de manera que si es cierta la condicion se realizan todas las asignaciones,
y si es falsa se realizaran todas menos las vigiladas. Un ejemplo sencillo, aunque no es
lo habitual, es denirse un registro activo por nivel alto del reloj, osea:
latch: BLOCK(clk='1')
BEGIN
q<=GUARDED d;
END BLOCK latch;
Solo cuando clk sea uno, la entrada pasara a la salida, en caso contrario la salida
no cambia por mucho que cambie la entrada, por tanto, se trata efectivamente de un
cerrojo activo por nivel alto.
Por ultimo, encerrados entre el BEGIN...END se encuentran las instrucciones concu-
rrentes a ejecutar, por lo que se pueden incluir otros bloques dentro de un bloque, dando
como resultado un dise~no jerarquico. A continuacion se da un ejemplo de descripcion
de ujo de datos tpica.
Ejemplo 5.2 Realizar la descripcion RTL de un circuito que desplace a derecha o
izquierda un bus de entrada de 4 bits. El circuito esta controlado por una se~nal de dos
bits de manera que cuando esta se~nal es \00" no desplaza. Si es \01" el desplazamiento
es a izquierdas. Si es \10" el desplazamiento es a derechas, y si es \11" se produce una
rotacion a derechas. En el caso de desplazamientos se introduce un cero en el hueco
que quede libre. Realizar una descripcion con la estructura WHEN...ELSE y otra con la
WITH...SELECT.
ENTITY shifter IS
PORT( shftin: IN bit_vector(0 TO 3);
shftout: OUT bit_vector(0 TO 3);
shftctl: IN bit_vector(0 TO 1));
END shifter;
ARCHITECTURE flujo1 OF shifter IS

BEGIN
shftout<=shftin WHEN shftctl="00" ELSE
shftin(1 TO 3)&'0' WHEN shftctl="01" ELSE
'0'&shftin(0 TO 2) WHEN shftctl="10" ELSE
shftin(3)&shftin(0 TO 2);
END flujo1;
ARCHITECTURE flujo2 OF shifter IS

BEGIN
WITH shftctl SELECT
shftout<=shftin WHEN "00",
shftin(1 TO 3)&'0' WHEN "01",
'0'&shftin(0 TO 2) WHEN "10",
shftin(3)&shftin(0 TO 2) WHEN "11";
END flujo2;

Captulo 6
Descripcion serie comportamental
abstracta
La descripcion RTL es una descripcion bastante cercana al hardware real. Las
estructuras condicionales vistas para esta ejecucion concurrente le dan al programador
un cierto nivel de abstraccion bastante mas elevado que el que se puede alcanzar con un
Netlist o una descripcion estructural pura de un circuito. Sin embargo, para sistemas
mucho mas complejos que los ejemplos que se estan mostrando aqu, se hace necesario
un grado de abstraccion todava mas elevado.
Los lenguajes de programacion software son un ejemplo claro de lenguajes de des-
cripcion comportamental de alto nivel, si bien el objetivo es bastante diferente. La
diferencia fundamental entre el lenguaje VHDL que se ha visto hasta ahora, y estos
lenguajes de soft, es el modo de ejecucion. Mientras el VHDL, hasta ahora, se ejecu-
taba de forma concurrente, los lenguajes software se ejecutan en serie, lo que permite
la utilizacion de estructuras como bucles que no son posibles, de forma directa, en
una ejecucion concurrente. En realidad, no todos los lenguajes de programacion son
en serie, un ejemplo de lenguaje de programacion cuya ejecucion es concurrente es el
Prolog. En este lenguaje se declaran reglas que se ejecutan cuando cambian algunos de
los argumentos de estas reglas. La ejecucion concurrente en VHDL funciona igual que
en Prolog, es decir, lo que se hace es declarar reglas o leyes que en el caso del VHDL
son leyes electricas que se traducen casi directamente en conexiones; cuando cambian
algunos de los argumentos de la asignacion, entonces se ejecuta la instruccion.
Como la programacion concurrente no es siempre la mas comoda para la descripcion
de ideas, VHDL tambien permite una programacion en serie. En VHDL esta progra-
macion serie se dene dentro de bloques indicados con la palabra clave PROCESS. Por
tanto, siempre que en VHDL se precise de una descripcion en serie, se debera utilizar
un bloque de tipo PROCESS.
En un mismo programa pueden haber multiples bloques PROCESS. En el caso de
haber varios de estos bloques, cada uno de ellos equivale a una instruccion concurrente.
Es decir, internamente a los PROCESS la ejecucion de las instrucciones es serie, pero entre
los propios bloques PROCESS, que pueden convivir con otras instrucciones concurrentes,
la ejecucion es concurrente.
Se plantea una cuestion de forma inmediata, y es que si un bloque PROCESS es en
realidad una instruccion concurrente >como se activa esta instruccion? es decir, >cuando
se ejecuta? En la ejecucion concurrente se haba visto que una instruccion se activaba o
45
46 Descripcion serie comportamental abstracta
ejecutaba cuando alguno de los argumentos que intervenan en la asignacion cambiaba.
En el caso de un bloque PROCESS esto es mucho mas complejo ya que dentro de un bloque
de este tipo pueden haber muchas instrucciones, asignaciones, condiciones, bucles, y no
parece que tenga que existir un convenio para la ejecucion. Para poder indicarle al
programa cuando activar o ejecutar un bloque PROCESS existen dos procedimientos.
Lo normal es utilizar una lista sensible, es decir, una lista de se~nales, de manera que
cuando se produzca un cambio en alguna de las se~nales, entonces se ejecuta el PROCESS.
La otra opcion consiste en utilizar una sentencia WAIT en algun lugar dentro del bloque
PROCESS. M as adelante se explicaran con mayor detalle estos mecanismos.
Ejemplo 6.1 Realizar la descripcion comportamental serie del comparador del ejemplo
5.1.
ARCHITECTURE abstracta OF comp IS
BEGIN
PROCESS(a,b) -- se ejecuta cuando a o b cambian
BEGIN
IF a>b THEN
amayb<='1';
aeqb <='0';
amenb<='0';
ELSIF a<b THEN
amayb<='0';
aeqb <='0';
amenb<='1';
ELSE
amayb<='0';
aeqb <='1';
amenb<='0';
END IF;
END PROCESS;
END abstracta;
Esta descripcion del ejemplo es correcta, pero no hay que olvidar que dentro de un
PROCESS la ejecucion es serie, por tanto este mismo ejemplo se puede describir de forma
algo mas sencilla como:
ARCHITECTURE abstracta OF comp IS
BEGIN
PROCESS(a,b) -- se ejecuta cuando a o b cambian
BEGIN
amayb<='0';
aeqb <='0';
amenb<='0';
IF a>b THEN
amayb<='1';
ELSIF a<b THEN
amenb<='1';
ELSE
aeqb <='1';
END IF;
END PROCESS;
END abstracta;
Aunque sintacticamente es correcto, y una simulacion de este ejemplo dara los

resultados que se esperan, lo mas probable es que una herramienta de sntesis no nos
dejara usar una descripcion as. El problema es que los algoritmos de sntesis tienen
problemas cuando a una se~nal se le asignan varias cosas en un mismo proceso, aunque
sea una detras de otra.
6.1 Diferencias entre variable y se~nal 47
6.1 Diferencias entre variable y se~nal
Una de las cosas que mas chocan al programador experimentado con otros lenguajes,
y que se enfrenta por primera vez a algun lenguaje de descripcion hardware, y mas
concretamente al VHDL, es la diferencia entre se~nal y variable.
Hasta ahora, en la ejecucion concurrente, las variables no existan y solo se dispona
de las se~nales. En la ejecucion concurrente no hay mucha diferencia entre lo que es una
se~nal y lo que es una variable normal y corriente en cualquier otro lenguaje. Aparen-
temente, cuando en la ejecucion concurrente una se~nal recibe un valor, la se~nal toma
inmediatamente este valor. Cuando se explique mas adelante el VHDL para simula-
cion, se vera que este inmediatamente es en realidad un paso de simulacion, que si no
se especica ningun retraso, implicara que la se~nal toma ese valor en el momento de la
asignacion.
En realidad, lo que ocurre en la asignacion de una se~nal es que en el momento actual,
o en el paso de simulacion actual indicamos que se quiere que, en el proximo paso de
simulacion (o mas tarde si se especica un retraso), la se~nal adquiera el valor que se le
esta asignando en este momento. En una asignacion concurrente esto equivale a que la
asignacion se realice de forma instantanea, pero eso es debido a que cuando se acaba
de ejecutar una instruccion concurrente, se pasa inmediatamente al siguiente paso de
simulacion.
Un bloque de tipo PROCESS es equivalente a una unica instruccion concurrente for-
mada por numerosas instrucciones en serie. Como se trata de una unica instruccion
concurrente, todas las instrucciones serie internas ocurren en el mismo paso de simu-
lacion, y no se pasa al siguiente paso de simulacion hasta que se haya completado la
ejecucion del PROCESS. Esto quiere decir que dentro de un bloque PROCESS, las se~nales
conservan su valor y no cambian hasta que el bloque termina de ejecutarse, momento
en el cual, ya tienen el valor que se les haya asignado durante la ejecucion del proceso
debido a que se encontrara en el siguiente paso de simulacion.
Para verlo un poco mas claro se puede decir que una se~nal es como una caja con
dos secciones. Una, que es la seccion que se suele ver, y que es la que contiene el valor
actual, y otra, separada, que contiene el valor futuro. Cuando leemos una se~nal estamos
echando mano de la seccion donde se guarda el valor actual. Cuando se le asigna algo
a una se~nal estamos escribiendo en la seccion dedicada al valor futuro. Solo cuando se
acaba la ejecucion de la instruccion concurrente, lo que se encuentra en la seccion de
valor futuro pasa a la seccion de valor actual.
De ahora en adelante, a la seccion del valor futuro, donde se escriben siempre los
valores, lo llamaremos driver de la se~nal, y a la seccion de valor actual lo llamaremos
simplemente se~nal. En realidad, y se vera mejor en el apartado de simulacion, hay un
unico valor actual, sin embargo, pueden haber varios valores futuros ya que se puede
hacer una lista de los valores que tomara la se~nal en el futuro. E sto, que ahora no tiene
mucho sentido puesto que las se~nales toman su valor inmediatamente en la ejecucion
concurrente, sera muy util cuando se expliquen los retrasos en la simulacion.
Las variables son algo diferente ya que tienen exactamente el mismo signicado
que las variables en cualquier otro lenguaje. Para empezar, solo pueden ser usadas
en entornos serie, por lo que solamente se las puede denir dentro de procesos o en
subprogramas. Para continuar, y esta es la diferencia mas importante, las variables
toman inmediatamente su valor en el momento de la asignacion. Es decir, son iguales
que las variables de cualquier otro lenguaje.
Estas diferencias entre variable y se~nal se ven mucho mejor en el siguiente ejemplo:
-- Uso incorrecto de las senyales -- Uso correcto de las variables
ARCHITECTURE ejemp1 OF cosa IS ARCHITECTURE ejemp1 OF cosa IS
SIGNAL a,b,c,x,y: integer; SIGNAL a,b,x,y: integer;
BEGIN BEGIN
p1: PROCESS(a,b,c) p1: PROCESS(a,b)
BEGIN VARIABLE c: integer;
c<=a; -- Se ignora BEGIN
x<=c+2; c:=a; -- Inmediato
c<=b; -- Se mantiene x<=c+2;
y<=c+2; c:=b; -- Inmediato
END PROCESS p1; y<=c+2;
END ejemp1; END PROCESS p1;
END ejemp1;
En el ejemplo de la izquierda solo se utilizan se~nales y la ejecucion tiene lugar de

la siguiente manera: En primer lugar se hace el driver de c igual a a, lo cual solo
esta indicando que tomara ese valor en el proximo paso de simulacion, pero no en el
presente. A continuacion se hace lo mismo con x asignandosele a su driver el valor de la
expresion c+2, es decir, el valor que contuviera c antes de empezar la ejecucion, porque
el valor que se le asigno en el paso anterior todava no esta presente. Luego se hace
c<=b, es decir, que se est a sustituyendo el valor del driver de c, que era a, por la se~nal
b. Esto quiere decir que el valor futuro de c ya no ser a a como estaba previsto sino
b. A continuaci on se hace y<=c+2 de manera que a y se le asigna el valor c+2, pero
cogiendo como c el valor de la se~nal antes de empezar el proceso.
En denitiva, supongamos que antes de iniciarse la ejecucion c=2, a=4 y b=6 por
ejemplo. Entonces, al nal de la ejecucion de este PROCESS, tenemos que c=b=6, x=4 y
y=4. De todas formas la ejecuci on no ha terminado todava puesto que c ha cambiado,
y como esta en la lista sensible se volvera a ejecutar. De manera que se repiten de
nuevo las operaciones, es decir, primero se hace el driver de c igual a a, luego se hace
x<=c+2, con lo que x=8, luego se mete b en c, y por u ltimo se hace y<=c+2 con lo que
y=8. Vemos que c conserva su valor puesto que sigue siendo c=b=6, por lo tanto la
ejecucion se detiene.
Se ha visto que la instruccion segunda (c<=a) se ha ignorado completamente en
toda la ejecucion. Esto es debido a que la instruccion tercera (c<=b), al venir despues,
sobreescribe el driver de c, por lo que en realidad c nunca puede tomar el valor a. En
el ejemplo de la derecha, se puede ver como hacer para que c tome valores instantaneos
y que la ejecucion sea como en un principio se espera.
En el programa de la derecha del ejemplo anterior, primero se dene c como una
variable en vez de como se~nal. Esta denicion se hace dentro del PROCESS puesto que
solo dentro de la ejecucion serie las variables tienen sentido. Tambien c desaparece de
la lista sensible puesto que las variables son internas a los PROCESS y nunca pueden
formar parte de las listas sensibles.
La ejecucion es bien simple. Primero c toma el valor de a, y como es una variable
toma este valor de forma inmediata, es decir, c toma el valor 4 justo en este momento.
A continuacion se hace el driver de x igual a c+2, como c vale 4, entonces x tomara el
valor 6 en el proximo paso de ejecucion. A continuacion se hace c:=b de manera que
ahora c vale 8. Despues viene y<=c+2, por lo que y valdra, cuando se acabe la ejecucion,
8. Al nal del PROCESS por tanto, ocurrir a que x=6 y y=8. No se volvera a ejecutar
puesto que ni a ni b han cambiado.
6.2 Estructuras de la ejecucion serie 49
6.2 Estructuras de la ejecucion serie
A continuacion se veran las estructuras mas comunes de la ejecucion serie y se veran
algunas caractersticas tpicas de este tipo de ejecucion que es sin duda la mas utilizada
en VHDL por permitir un alto grado de abstraccion y encontrase mas cerca del lenguaje
natural.
El bloque de ejecucion serie: PROCESS
La forma de entrar en la ejecucion serie dentro de un programa en VHDL es mediante

la denicion de un bloque PROCESS. Su estructura y funcionamiento se han visto ya
pero se comentaran a continuacion con un poco mas de detalle. La declaracion es como
sigue:
proc_id:
PROCESS(lista sensible)
declaraciones
BEGIN
instrucciones serie
END PROCESS proc_id;
El proc id es simplemente una etiqueta opcional y que puede servir para ponerle
nombre a los diferentes procesos de una descripcion. La (lista sensible) es tambien
opcional y contiene una lista de se~nales separadas por comas. La ejecucion del PROCESS
se activa cuando se produce un evento, o cambio, en alguna de las se~nales de la lista
sensible. En el caso de no existir lista sensible, la ejecucion se controla mediante el
uso de sentencias WAIT dentro del PROCESS. Esta sentencia WAIT se vera mas adelante.
En cualquier caso debe existir o una lista sensible, o una o mas sentencias WAIT de lo
contrario se ejecutara el proceso una y otra vez entrando la simulacion en un bucle
innito del que no se puede salir.
La parte de declaracion es parecida a la de otras estructuras, de forma que se pueden
denir aqu variable, tipos, subprogramas, atributos, etc. pero en ningun caso se~nales.
En interesante destacar que este es el unico lugar, aparte de en los subprogramas,
donde se pueden denir las variables, cosa que no se puede hacer en otros tipos de
estructura como entidades, bloques, arquitecturas o paquetes. A continuacion, y entre
el BEGIN...END, vienen todas las instrucciones serie, que, como veremos, presentan sus
propios elementos sintacticos, siendo la asignacion simple el unico elemento comun con
la ejecucion concurrente.
Sentencia de espera: WAIT
La ejecucion de un bloque PROCESS, sino se indica nada mas, se realiza de forma con-
tinuada como si de un bucle se tratara. Es decir, se ejecutan todas las instrucciones y
se vuelve a empezar. Esto no tiene mucho sentido en simulacion puesto que nunca se
podra salir de un proceso y la simulacion no acabara nunca. Por lo tanto, debe existir
un mecanismo que permita detener la ejecucion del bloque serie. Una de las formas de
detener la ejecucion es mediante la inclusion de la lista sensible. La inclusion de esta
lista equivale a la adicion de una sentencia de espera al nal del proceso que detenga
la ejecucion del PROCESS hasta que alguna de las se~nales de la lista sensible cambie.
Aunque la utilizacion de la lista sensible es suciente para la mayora de procesos en
un programa, en realidad existe una posibilidad mas compleja de detener la ejecucion
del bloque serie resultando la lista sensible un caso particular de esta operacion mas
compleja. La forma generica de detener la ejecucion en un proceso se realiza mediante
la palabra clave WAIT que suspende la ejecucion hasta que se cumple una condicion o
evento especicada en la propia sentencia. La sintaxis es como sigue:
WAIT ON lista_sensible UNTIL condicion FOR timeout;
La lista sensible es simplemente una lista de se~nales separadas por comas. La

condicion es una condici on que cuando se cumple sigue la ejecucion. El timeout
indica un tiempo durante el cual la ejecucion esta detenida, cuando ese tiempo se
acaba sigue la ejecucion. Estas tres posibilidades, es decir, la de la lista sensible, la
condicion y el timeout, son opcionales y pueden especicarse una, dos o las tres en una
misma sentencia WAIT. Cualquiera que ocurra primero provocara que se continue con
la ejecucion del proceso. Ejemplos:
WAIT ON pulso;
WAIT UNTIL counter>7;
WAIT FOR 1 ns;
WAIT ON interrupcion FOR 25 ns;
WAIT ON clk,sensor UNTIL counter=3 FOR 100 ns;
Hay varias cosas a tener en cuenta con el uso de la sentencia WAIT. Un proceso
debe tener una lista sensible o al menos una sentencia WAIT, de lo contrario, el proceso
se ejecuta indenidamente una y otra vez. Si el proceso ya tiene una lista sensible
entonces no se puede utilizar la sentencia WAIT en el interior de ese proceso, ni siquiera
en algun subprograma que se pudiera llamar desde ese proceso. En un mismo proceso
pueden haber varias sentencias WAIT con varias condiciones diferentes. A continuacion
se muestra un ejemplo donde ambos procesos son equivalentes:
-- Con lista sensible -- Con WAIT
p1: PROCESS(b,a) p2: PROCESS
BEGIN BEGIN
a<=b+a+2; a<=b+a+2;
END PROCESS p1; WAIT ON a,b;
END PROCESS p1;
Un ejemplo algo mas elaborado se puede realizar intentando la descripcion de alguna

funcion logica mediante sentencias WAIT como el ejemplo que sigue:
Ejemplo 6.2 Realizar un proceso que describa el comportamiento de una puerta OR
utilizando sentencias de espera WAIT.
-- Puerta OR complicada
PROCESS
BEGIN
s<='0';
WAIT UNTIL (a='1' OR b='1');
s<='1';
WAIT UNTIL (a='0' AND b='0');
END PROCESS;

Sentencia condicional: IF..THEN..ELSE
Es la estructura tpica para realizar una accion u otra segun una expresion booleana,
siendo equivalente en signicado a estructuras del mismo tipo en otros lenguajes. La
forma general es:
IF condicion THEN
sentencias
ELSIF condicion THEN
sentencias
...
ELSE
sentencias
END IF;
Se observa que esta estructura tiene la posibilidad de anidar IFs consecutivos me-
diante la palabra ELSIF, de esta manera se evita tener que poner al nal de cada nuevo
IF un END IF, ganando el programa en legibilidad.
Tanto el ELSE como el ELSIF son opcionales, aunque conviene siempre poner un ELSE
al nal de manera que todos los posibles casos de la bifurcacion esten contemplados. En
programacion software esto puede tener poca importancia, pero pensando en la sntesis
posterior del circuito, es mucho mejor poner todos los casos posibles para ayudar a las
herramientas de sntesis en su labor, no es que no pudieran ser capaces de sintetizar
algo sin que esten todos los casos contemplados, pero es posible que el resultado de la
sntesis este mas optimizado.
Esta sentencia, cuando se trata de asignaciones, tiene su equivalente en la ejecucion
concurrente. De hecho, cualquier instruccion concurrente se puede poner de forma serie
mediante un proceso. Ejemplo:
-- Ejecucion serie -- Ejecucion concurrente
PROCESS(a,b,c) p<=2 WHEN a>b ELSE
BEGIN 3 WHEN a>c ELSE
IF a>b THEN 4 WHEN (a=c AND c=b) ELSE
p<=2; 5;
ELSIF a>c THEN
p<=3;
ELSIF (a=c AND c=b) THEN
p<=4;
ELSE p<=5;
END IF;
END PROCESS;
Para estos casos particulares resulta mas simple la ejecucion concurrente, pero es
evidente que esta ejecucion esta limitada a ser usada con asignaciones. Es importante,
a n de que ambas estructuras sean equivalentes, que el PROCESS contenga todas las
se~nales que intervienen en las asignaciones en su lista sensible, de otra manera, ambas
instrucciones vistas anteriormente no seran equivalentes.
Sentencia de seleccion: CASE
Es la estructura tpica que permite ejecutar una cosa u otra dependiendo del resultado
de una expresion. Su forma sintactica es la siguiente:
CASE expresion IS
WHEN caso1 =>
instrucciones
WHEN caso2 =>
instrucciones
...
WHEN OTHERS =>
instrucciones
END CASE;
La expresion de seleccion tiene que ser o bien de tipo discreto o una matriz monodi-
mensional de caracteres. Dependiendo de la expresion se ejecutaran unas instrucciones
u otras. No pueden haber dos casos duplicados ya que dara error. Tambien, todas
los posibles casos de valores de la expresion deben estar contemplados en los diferentes
WHEN. Es por esto conveniente el uso de la palabra OTHERS, para indicar que se ejecuten
ese conjunto de instrucciones si la expresion toma un valor que no se contempla en
ninguno de los casos.
Los casos se pueden especicar o bien con un valor simple, o bien con un rango
de valores mediante las palabras TO o DOWNTO, o una lista de valores separados por el
smbolo \|". La otra posibilidad explicada anteriormente es poner OTHERS. Veamos a
continuacion un ejemplo simple de esta estructura:
CASE puntuacion OF
WHEN 9 TO 10 => acta<="Sobresaliente";
WHEN 7 TO 8 => acta<="Notable";
WHEN 5 | 6 => acta<="Aprobado";
WHEN 0 => acta<="No presentado";
WHEN OTHERS => acta<="Suspenso";
END CASE;
Naturalmente en este ejemplo se supone que la puntuacion es un entero, ya que

el tipo de la expresion a evaluar siempre tiene que ser un tipo discreto, o una matriz
monodimensional.
Sentencias de bucles: FOR y WHILE LOOPs

En VHDL existen las dos posibilidades tpicas para bucles, es decir, los de tipo WHILE
y FOR. La parte repetitiva del bucle siempre viene especicado por la palabra clave
LOOP...END LOOP y ser a lo que vaya delante de este bucle lo que indique si es de tipo
for o while. La sintaxis general se da a continuacion:
bucle_id:
tipo_de_iteracion LOOP
instrucciones
END LOOP:
El tipo de iteracion indicara si es un WHILE o FOR. Es opcional, por lo que se

podra denir un bucle sin salida, de manera que las sentencias en ese bucle se repetiran
siempre.
Las construcciones de los bucles FOR y WHILE se dan a continuacion:

bucle_id: bucle_id:
FOR identificador IN rango LOOP WHILE condicion LOOP
instrucciones instrucciones
END LOOP; END LOOP;
En el caso de la sentencia FOR, el bucle se repite para cada valor del identicador
especicado en el rango. Esto quiere decir que el tipo del identicador debe ser discreto,
es decir, o un entero o un enumerado.
El bucle en la instruccion WHILE se repite mientras la condicion sea cierta, si no lo
es deja de repetirse.
Junto a estas instrucciones hay dos mas que permiten interrumpir el ujo normal de
ejecucion. Estas sentencias son NEXT y EXIT. La primera permite detener la ejecucion de
la iteracion actual y pasar a la siguiente. La segunda detiene la ejecucion en ese instante
y se sale del bucle. En el caso de tener varios bucles anidados, la salida se realiza del
bucle donde se encuentre la instruccion, o del bucle indicado por la etiqueta despues de
la instruccion, si es que se especica. Estas instrucciones aceptan opcionalmente una
condicion, de manera que si se cumple la condicion se interrumpe el lazo, y si no, no.
La sintaxis general de estas dos instrucciones es la siguiente:
NEXT bucle_id WHEN condicion;
EXIT bucle_id WHEN condicion;
A continuacion se muestra un ejemplo, donde se ven dos lazos, uno FOR y el otro
WHILE, que realizan exactamente la misma operaci
on:
-- Lazo FOR -- Lazo WHILE
FOR cuenta IN 5 DOWNTO 0 LOOP cuenta:=5;
tabla(cuenta)<=cuenta*2; WHILE cuenta>=0 LOOP
END LOOP; tabla(cuenta)<=cuenta*2;
cuenta:=cuenta-1;
END LOOP;
En el siguiente ejemplo se muestran dos lazos anidados y el uso de una de las

operaciones de interrupcion de lazo:
fuera:
WHILE a<10 LOOP
-- varias sentencias
dentro:
FOR i IN 0 TO 10 LOOP
-- varias sentencias
NEXT fuera WHEN i=a; -- Interrumpe el FOR y sigue en el WHILE
END LOOP dentro;
END LOOP fuera;
Para terminar este captulo se ha introducido un peque~no ejemplo. Este mismo

ejemplo se encuentra tambien en el de ejemplos (Ej. 11.1) aunque en esa ocasion
se resolvera de forma diferente. Se vera entonces que la descripcion que se da en este
momento es mucho mas sencilla e incluso mas adecuada si se desea sintetizar el circuito.
Ejemplo 6.3 Un motor electrico viene controlado por un boton. Cada vez que se pulsa
el boton cambia de encendido a apagado.
Este problema se resuelve sencillamente mediante un ip- op tipo D activo por
anco de subida y un inversor con el boton haciendo de reloj. Si se sabe como se describe
esto en VHDL entonces el problema esta resuelto. Si se desea una aproximacion mas
abstracta se puede decir que lo que queremos es que la salida cambie justo cuando
pulsamos el boton, es decir, cuando la entrada pasa de cero a uno. En ambos casos la
descripcion coincide y se podra poner as:
ENTITY conmutador IS
PORT(boton: IN bit; motor: OUT bit);
END conmutador;
ARCHITECTURE serie OF conmutador IS

SIGNAL motoraux: bit:='0';
BEGIN
PROCESS(boton)
BEGIN
IF boton='1' THEN motoraux<=NOT motoraux; END IF;
END PROCESS;
motor<=motoraux;
END serie;
Como la se~nal que activa todo es boton pues es la unica que se puesto en la lista
sensible. Como es la unica, el proceso solo se ejecutara si la se~nal del boton cambia, esto
permite el ahorro de la comprobacion de anco (que se realiza con el atributo 'EVENT)
que tendra que ponerse en el IF si la lista sensible hubiera contenido varias se~nales.
La se~nal auxiliar motoraux es necesaria ya que motor es una salida y por lo tanto
no se puede leer, es decir, no se puede usar en la parte derecha de ninguna asignacion.
Siempre que se tienen que manejar valores de salida se hace lo mismo, es decir, se pone
una instruccion que a la salida se le asigna la se~nal auxiliar, y en el resto del programa
se usa unicamente la se~nal auxiliar. Es interesante darle un valor inicial a estas se~nales
ya que luego a la hora de sintetizar o simular sirven para que el sistema se encuentre en
un estado inicial conocido, aqu se ha inicializado a cero para que el motor este parado
cuando empiece la simulacion o se encienda el circuito.
Esta misma descripcion se podra haber realizado totalmente concurrente y el re-
sultado sera:
ARCHITECTURE concurrente OF conmutador IS
SIGNAL motoraux: bit:='0';
BEGIN
motoraux<=NOT motoraux WHEN boton='1' AND boton'EVENT
ELSE motoraux;
motor<=motoraux;
END concurrente;
Lo unico que se ha hecho es poner el proceso anterior, que era un IF en la forma

concurrente equivalente del IF que es el WHEN. Al contrario que en el proceso, aqu es
necesario poner que hacer para todas las posibilidades de la condicion, como si el boton
esta a cero no queremos que haga nada, pues le asignamos a la se~nal el valor que ya tiene
y as se queda como esta. Conviene destacar que el uso de boton'EVENT que detecta
que la se~nal del boton ha cambiado, es necesario ya que de lo contrario la instruccion
podra entrar en un bucle innito en este caso concreto; por ejemplo, supongamos que
motoraux est a a cero y que de pronto se pulsa el boton, entonces la se~nal motoraux pasa
a valer '1' y como cambia pues entonces se vuelve a ejecutar otra vez la instruccion,
cambiando de nuevo y as sucesivamente. Si se sintetiza el circuito entonces mientras
se pulsara el boton la salida cambiara de 0 a 1 con un periodo impuesto por el retraso
en el inversor y el registro. En simulacion sera peor ya que el tiempo nunca avanzara
y entrara en un bucle innito (a no ser que se pusiera una clausula AFTER en cuyo caso
pasara como en sntesis).


Captulo 7
Poniendo orden: subprogramas,
paquetes y libreras
En descripciones complejas de un circuito o programa, se hace necesaria una orga-
nizacion que permita al dise~nador trabajar con grandes cantidades de informacion. Ya
se han visto los bloques como forma de estructurar una descripcion en forma modular
permitiendo establecer una jerarqua. Hay otras formas de organizar la informacion y
es la introduccion de funciones y procedimientos, que llamaremos subprogramas, que
hacen mas legibles los programas. Por otro lado, y a un nivel mas elevado, se pueden
agrupar subprogramas, deniciones de tipos, bloques, etc. en estructuras por encima
de la propia descripcion; esto es lo que formaran los paquetes que a su vez, junto con
otros elementos de conguracion, etc. formaran las libreras. De todos estos elementos
es de los que trata este captulo.
7.1 Subprogramas
Al igual que ocurre en la mayora de los lenguajes de programacion, tambien el VHDL
se puede estructurar mediante el uso de subprogramas. Un subprograma no es mas que
una funcion o procedimiento que contiene una porcion de codigo.
Las funciones y procedimientos en VHDL son estructuras muy parecidas entre s aun-
que existen algunas peque~nas diferencias. Estas diferencias se sumarizan a continuacion:
Una funcion siempre devuelve un valor, mientras que un procedimiento solo puede
devolver valores a traves de los parametros que se le pasen.
Los argumentos de una funcion son siempre de entrada, por lo que solo se pueden
leer dentro de la funcion. En el procedimiento pueden ser de entrada, de salida o de
entrada y salida con lo que se pueden modicar.
Las funciones, como devuelven un valor, se usan en expresiones mientras que los
procedimientos se llaman como una sentencia secuencial o concurrente.
La funcion debe contener la palabra clave RETURN seguida de una expresion puesto
que siempre devuelve un valor, mientras que en el procedimiento no es necesario.
Una funcion no tiene efectos colaterales, pero un procedimiento s, es decir, puede
provocar cambios en objetos externos a el debido a que se pueden cambiar las se~nales
aunque no se hubieran especicado en el argumento. Es decir, en los procedimientos
57
58 Poniendo orden: subprogramas, paquetes y libreras
se permite realizar asignaciones sobre se~nales declaradas en la arquitectura y por
tanto externas al procedimiento.
7.1.1 Declaracion de procedimientos y funciones

Las declaraciones de procedimiento y funcion se encuentran a continuacion:
-- Procedimientos: -- Funciones:
PROCEDURE nombre(parametros) IS FUNCTION nombre(parametros) RETURN tipo IS
declaraciones declaraciones
BEGIN BEGIN
instrucciones instrucciones -- incluye RETURN
END nombre; END nombre;
La lista de parametros es opcional y si no hay parametros tampoco es necesario usar

los parentesis. Su signicado es el mismo en procedimientos que en funciones. Esta lista
no es mas que el conjunto de parametros que se le pasan al subprograma, y se declaran
de forma muy parecida a como se declaraban los puertos en una entidad; primero se
pone el tipo de objeto que es, es decir, una se~nal, una variable o una constante, a
continuacion se pone el nombre del objeto, y despues dos puntos seguidos por el tipo
de puerto, que sera IN, OUT o INOUT. Al igual que en la entidad, el tipo IN solo se puede
leer, el tipo OUT solo se puede escribir, y el tipo INOUT se puede escribir y leer. Por
ultimo se pone el tipo de objeto que es.
En la declaracion de los parametros hay cosas que se pueden omitir. Si por ejemplo
el puerto es de tipo IN entonces no hace falta poner la palabra CONSTANT delante puesto
que se sobreentendera que es una constante, de hecho, y si no se pone nada mas, se
entendera que los objetos son de tipo IN. Para el resto de tipos, y si no se especica
otra cosa, se entendera que son de tipo VARIABLE.
En los procedimientos se pueden utilizar los tres tipos de objetos (constantes, va-
riables y se~nales), y los tres tipos de puerto (IN, OUT e INOUT). Sin embargo, en las
funciones solo se admiten los objetos de clase constante o se~nal, y como tipo de puerto
solo se admite el IN ya que los parametros no pueden ser modicados en una funcion.
En la funcion no se admite la variable puesto que la clase constante ya juega el mismo
papel. No es aconsejable el uso de se~nales como parametros puesto que pueden llevar
a confusion dada la especial forma en que estos objetos se asignan, sin embargo su uso
es posible y hay que tener especial cuidado en el uso de los atributos ya que algunos
atributos no estan permitidos en el interior de funciones; este es precisamente el caso
de 'STABLE, 'QUIET, 'TRANSACTION y 'DELAYED.
En el caso de las funciones se debe especicar, ademas, el tipo del objeto que de-
vuelve la funcion. Como las funciones siempre devuelven algo, esto implica ademas, que
debe existir una instruccion RETURN en el interior del cuerpo de la funcion, y ademas
esta instruccion debe estar seguida por una expresion que es precisamente lo que se
devuelve. El uso del RETURN en procedimientos es posible pero no debe llevar una ex-
presion puesto que los procedimientos no devuelven nada. Si se usa en procedimientos
simplemente interrumpe la ejecucion del procedimiento y vuelve.
Las declaraciones dentro de una funcion o procedimiento pueden incluir las mismas
que incluira un PROCESS ya que se trata tambien de bloques de ejecucion serie. Por lo
tanto, y al igual que sucede en un proceso, no se pueden declarar se~nales en una funcion
o procedimiento. Naturalmente, todo lo que se declara en esta parte solo es visible en
7.1 Subprogramas 59
el cuerpo de la funcion.
Aunque la ejecucion dentro de los subprogramas es siempre serie como en un pro-
ceso, estos pueden ser llamados tanto en entornos serie (procesos) como en entornos
concurrentes. En el caso de ser invocados en entornos concurrentes, los subprogramas
se ejecutan igual que un proceso cuya lista sensible estuviera compuesta por aquellos
argumentos del subprograma que fueran de tipo IN o INOUT. Si no existen argumentos
en el procedimiento y la llamada se produce en un entorno concurrente, sera necesa-
rio incluir una sentencia de espera (WAIT) dentro del procedimiento, de lo contrario se
entrara en un bucle innito.
En muchas ocasiones puede resultar util declarar la funcion antes de especicar su
cuerpo por motivos de visibilidad, etc. En estos casos la declaracion se hace igual que
se ha visto pero al llegar a la palabra IS, se pone un punto y coma y se termina la
declaracion. Es decir:
PROCEDURE nombre(parametros);
FUNCTION nombre(parametros) RETURN tipo;
A continuacion se presenta un ejemplo donde se dene un procedimiento que calcula

los valores maximo y mnimo de los numeros contenidos en una matriz cuyo rango ha
sido denido en algun sitio como tipo matriz.
-- mas corto: PROCEDURE extremos(conjunto: matriz; min,max: INOUT integer) IS
PROCEDURE extremos(CONSTANT conjunto: IN matriz; VARIABLE min,max: OUT integer) IS
VARIABLE ind: integer;
BEGIN
min:=conjunto(conjunto'left); -- valores iniciales de min y max
max:=conjunto(conjunto'right);
FOR ind IN conjunto'range LOOP
IF min>conjunto(ind) THEN min:=conjunto(ind); END IF;
IF max<conjunto(ind) THEN max:=conjunto(ind); END IF;
END LOOP;
END extremos;
En este ejemplo se muestra el encabezamiento completo y, comentado, otro encabe-

zamiento que tambien es valido por tomar los valores por defecto. El funcionamiento es
muy simple. Por un lado utiliza la variable de entrada conjunto y no la modica puesto
que es de entrada. Como devuelve dos resultados, min y max, no se puede utilizar una
funcion ya que la funcion solo puede devolver un resultado, por lo que se debe utilizar
un procedimiento de manera que se le pasen dos parametros que se puedan modicar.
7.1.2 Llamadas a subprogramas

La forma de invocar un subprograma es bien simple, se pone el nombre seguido por los
argumentos entre parentesis, si los tiene, y eso es todo. A las funciones solo se las puede
invocar como parte de una expresion, mientras que los procedimientos se ejecutan como
si fueran una sentencia, secuencial o concurrente.
Hay tres formas de pasar parametros a un subprograma. La primera es poniendo
los parametros en el mismo orden en que se declaran. Esta es la forma normal en que
suelen funcionar los lenguajes de programacion, pero VHDL permite dos mas: una es
mediante la asociacion explcita, que permite poner los parametros en cualquier orden, y
la otra permite dejarse parametros por especicar de manera que se cogen unos valores
por defecto. Aparte de estas, existe otra forma para el caso de los operadores con
notacion inja, pero esto se vera mas adelante cuando se explique la sobrecarga de
operadores. Diferentes posibles llamadas al procedimiento del ejemplo anterior, junto
con otro procedimiento que no tiene parametros, sera:
extremos(conj(4 TO 20),valmin,valmax);
reset; -- llamada a un procedimiento sin argumentos
extremos(min=>valmin,max=>valmax,conjunto=>conj(4 TO 20));
Los procedimientos se pueden llamar, bien desde entornos concurrentes o bien desde
entornos secuenciales. Llamar a un procedimiento desde un entorno secuencial es bien
simple, se llama como se ha visto anteriormente y ya esta. Solo hay que tener cuidado
de no incluir ninguna instruccion WAIT si es que en el proceso que llamo al procedimiento
existe una lista sensible.
La ejecucion de un procedimiento en entornos concurrentes tambien es posible. En
este sentido, un procedimiento se comporta exactamente igual que un bloque PROCESS de
manera que la ejecucion externamente es concurrente, pero internamente la ejecucion
es en serie. Como en el PROCESS es necesario incluir algo que permita suspender la
ejecucion del procedimiento, de otra manera se ejecutara indenidamente. Por defecto
se consideran todas los argumentos de tipo IN o INOUT que se le pasan al procedimiento
como la lista sensible. Si no hay argumentos de este tipo, o sencillamente no hay
argumentos, entonces el procedimiento debe incluir al menos una sentencia de espera
WAIT.
7.1.3 Sobrecarga de operadores

La sobrecarga de funciones permite que puedan existir funciones con el mismo nombre,
siendo la diferencia el tipo de datos que devuelven o el tipo de datos de sus argumentos.
Esto es especialmente util cuando se desea ampliar la cobertura de algunos operado-
res predenidos. En principio no es necesario indicar que se esta sobrecargando una
funcion, en tiempo de ejecucion, el interprete del programa elegira una funcion u otra
dependiendo de los tipos de datos que se esten utilizando en ese momento.
Lo normal es que la sobrecarga se emplee en operadores. Los operadores, a dife-
rencia de las funciones normales, siguen una notacion inja que ademas no necesita de
parentesis. En VHDL se pueden denir tambien este tipo de operadores de la misma
manera que una funcion normal, pero poniendo el nombre de la funcion entre comillas
dobles. A continuacion se vera un ejemplo donde se sobrecarga la operacion suma para
que funcione tambien sobre bit vector de 8 bits denidos como un tipo byte. (se
supondra que se han declarado en otros sitios unas funciones que pasan de bit vector
a integer y viceversa):
FUNCTION "+"(a,b: byte) RETURN byte IS
BEGIN
RETURN inttobyte(bytetoint(a)+bytetoint(b));
END "+";
En este ejemplo se ha redenido la operacion suma y convive con la funcion suma
anterior que solo serva para enteros. De hecho, se ha utilizado la operacion suma
7.2 Libreras, paquetes y unidades 61
anterior para denir esta nueva. No hay confusion posible puesto que los tipos de datos
son diferentes, as que se realizara una u otra segun el tipo de datos.
Tal y como se ha denido la funcion, su nombre real, es en realidad "+" por lo que
en realidad se puede usar como una funcion normal utilizando su nombre completo. De
estas manera, las expresiones X"FF"+X"80" y "+"(X"FF",X"80") son equivalentes.
Ejemplo 7.1 Se dene el tipo enumerado logico como ('X','0','1','Z'), es decir,
como el tipo bit pero a~nadiendo los valores 'X' (desconocido) y 'Z' (alta impedancia).
Sobrecargar el operador AND para que se pueda usar esta operacion con este nuevo tipo.
FUNCTION "and"(a,b: logico) RETURN logico IS
BEGIN
CASE a&b IS
WHEN "00" => RETURN '0';
WHEN OTHERS => RETURN 'X';
END CASE;
END "and";
7.2 Libreras, paquetes y unidades

Hasta ahora se han mostrado las diferentes estructuras del lenguaje VHDL para la
descripcion de circuitos. En esta seccion se vera como se juntan todos los elementos
anteriores para formar una descripcion completa de un sistema digital.
Los elementos que se han visto hasta ahora eran las entidades y las arquitecturas,
la entidad serva para denir el interface de un modulo o sistema, mientras que la
arquitectura describa el comportamiento del circuito. A este tipo de estructuras se las
conoce como unidades, y a continuacion veremos que hay algunas mas que las que se
han visto hasta ahora.
Al realizar una descripcion en VHDL, estas unidades se suelen introducir en un
mismo chero, o en varios. Cada uno de estos cheros es lo que se llama un chero de
dise~no. Normalmente, antes de simular o sintetizar un circuito descrito con VHDL, estos
cheros de dise~no se compilan previamente. El resultado de la compilacion, aparte de
realizarse la correspondiente comprobacion de sintaxis, es lo que se llama una librera de
dise~no. Es decir, lo que inicialmente es uno o varios cheros de dise~no con la descripcion
hardware, pasa a ser una unica librera de dise~no despues de la compilacion, de manera
que esta librera contiene todas las descripciones de todos los elementos que componen
el circuito. Posteriormente la simulacion o sntesis del circuito se realizara sobre esta
librera de dise~no. A esta librera, donde se guardan los elementos de la descripcion
despues de la compilacion se le llama work.
Los elementos que componen una librera es lo que se llaman unidades. Ya se han
visto dos unidades hasta ahora, la entidad y la arquitectura, pero veremos que hay
tres mas que son los paquetes, los cuerpos de los paquetes, y las conguraciones. A
las unidades de tipo declarativo, esto incluira a la entidad, paquete y conguracion, se
las conoce como unidades primarias. Al resto de unidades que son de tipo ejecutivo,
que son las arquitecturas y cuerpo de los paquetes, se las llama unidades secundarias.
LIBRARY (Librera)
ENTITY PACKAGE CONFIGURATION Unidades

(Entidad) (Paquete) (Conguracion) Primarias
...........................................................
ARCHITECTURE PACKAGE BODY Unidades
(Arquitectura) (Cuerpo del paquete) Secundarias
Figura 7.1: Las libreras y las unidades que la componen
Una unidad secundaria tiene siempre asociada una unidad primaria, por lo que deben
ser evaluadas las primarias en primer lugar, esta es la razon por la que tambien se
suelen poner al principio de una descripcion las unidades primarias, a excepcion de las
conguraciones que hacen referencia a las arquitecturas. En la gura 7.1 se muestra de
forma esquematica como se ordenan las unidades dentro de la librera.
Se ha visto que la librera es donde se guardan las unidades de una descripcion de
un circuito a partir de un chero. La forma que tiene el chero de dise~no es siempre la
misma ya que se trata de un chero texto con los comandos de VHDL, sin embargo, la
forma que puede tomar la librera correspondiente puede ser muy diversa dependiendo
de la herramienta de compilacion utilizada y del sistema operativo. Esto quiere decir
que no existe un mecanismo estandar en VHDL para la creacion de libreras, siendo
esta una tarea de la herramienta que se este utilizando.
S que existe, sin embargo, un mecanismo para incorporar elementos de otras li-
breras a nuestro propio dise~no. Este mecanismo es mediante la inclusion al inicio del
chero de dise~no de una clausula LIBRARY. A continuacion de esta sentencia se pone
la lista de libreras que se desea que sean visibles. Estas libreras se referencian me-
diante un nombre logico, de manera que la herramienta traduce este nombre logico al
correspondiente sistema de almacenamiento que la herramienta tenga; puede ser que
la librera sea un chero, o un directorio, o que todas las libreras esten en un unico
chero, etc. esto es algo que depende de la herramienta.
Junto a la clausula de librera pueden haber tambien clausulas que permitan hacer
visibles los elementos internos a los paquetes. La sentencia que permite hacer esto se
llama USE. Seguido del USE se pone el paquete y a continuacion la unidad o elemento que
se quiere referenciar dentro del paquete precedido por un punto. Si se quieren referenciar
todos los elementos de un paquete se puede utilizar la palabra ALL. Ejemplos:
LIBRARY componentes; -- Hace visible una libreria con componentes
USE componentes.logic.and2; -- Hace visible la puerta "and2" del paquete
-- "logic" al resto del programa.
USE componentes.arith.ALL; -- Hace visibles todos los elementos del
-- paquete "arith".
En cualquier sistema basado en VHDL siempre existen dos libreras que no necesitan
ser invocadas puesto que son cargadas por defecto. Una de estas libreras es work, es
decir, la que contiene las unidades del dise~no que se esta compilando. La otra librera
es la std que contiene dos paquetes, el standard y el textio. El paquete standard
dentro de esta librera contiene todas las deniciones de tipos y constantes vistos hasta
ahora, como por ejemplo los tipos bit y bit vector. El paquete textio contiene tipos
y funciones para el acceso a cheros de texto.
Junto a estas libreras suele venir en las herramientas de simulacion y sntesis, otra
librera que se usan tanto que practicamente tambien es estandar. Esta librera se llama
IEEE y contiene algunos tipos y funciones que completan los que vienen incorporados
por defecto. Dentro de esta librera hay inicialmente un paquete, el std logic 1164
que contiene la denicion de tipos y funciones para trabajar con un sistema de nueve
niveles logicos que incluyen los de tipo bit con sus fuerzas correspondientes, as como
los de desconocido, alta impedancia, etc. El nombre de este tipo es el std ulogic, y
en el mismo paquete viene otro tipo, el std logic que es exactamente como el anterior
solo que este tiene asociada una funcion de resolucion (ver la seccion 10.1). Junto
con este paquete existe otro que no es mas que una extension del anterior y se llama
std logic 1164 ext. Este paquete es como el anterior pero incorpora alguna funci on
de resolucion mas, as como operaciones aritmeticas y relacionales.
A n de claricar como vienen denidos estos tipos, se presenta a continuacion el
comienzo de la parte declarativa del paquete std logic 1164 de la librera del IEEE,
donde se pueden ver los diferentes niveles logicos disponibles:
PACKAGE std_logic_1164 IS
-------------------------------------------------------------------
-- logic state system (unresolved)
-------------------------------------------------------------------
TYPE std_ulogic IS ( 'U', -- Uninitialized
'X', -- Forcing Unknown
'0', -- Forcing 0
'1', -- Forcing 1
'Z', -- High Impedance
'W', -- Weak Unknown
'L', -- Weak 0
'H', -- Weak 1
'-' -- Don't care
);
-------------------------------------------------------------------
-- unconstrained array of std_ulogic for use with the resolution function
-------------------------------------------------------------------
TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;
-------------------------------------------------------------------
-- resolution function
-------------------------------------------------------------------
FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic;
-------------------------------------------------------------------
-- *** industry standard logic type ***
-------------------------------------------------------------------
SUBTYPE std_logic IS resolved std_ulogic;
-------------------------------------------------------------------
-- unconstrained array of std_logic for use in declaring signal arrays
-------------------------------------------------------------------
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;
Posteriormente a estas deniciones vendra la sobrecarga de operadores, y otras

deniciones.
Como la librera IEEE es la empleada mayoritariamente en la industria, a partir de
este momento se utilizaran indistintamente estos tipos y los denidos en la librera std.
En todos los ejemplos que siguen se supondra por tanto que la librera IEEE ha sido
cargada y que los paquetes std logic 1164 y std logic 1164 ext son visibles.
7.2.1 Paquetes: PACKAGE y PACKAGE BODY
Un paquete es una coleccion de declaraciones de tipo, constantes, subprogramas, etc,
normalmente con la intencion de implementar algun servicio en particular o aislar un
grupo de elementos relacionados. De esta manera se pueden hacer visibles las interfaces
de algunos elementos como funciones o procedimientos estando ocultos las descripciones
de estos elementos.
Los paquetes estan separados en dos partes, una es la parte de declaraciones y la otra
es la de cuerpo. La parte de cuerpo, donde estaran por ejemplo algunas deniciones
de funciones y procedimientos, puede ser omitida si no hay ninguno de estos elementos.
A continuacion se muestra la declaracion de paquetes y de cuerpos de los paquetes:
-- Declaracion de paquete -- Declaracion del cuerpo
PACKAGE nombre IS PACKAGE BODY nombre IS
declaraciones declaraciones, instrucciones, etc.
END nombre; END nombre;
Naturalmente el nombre del PACKAGE y del cuerpo deben coincidir. A continuacion

se muestra un ejemplo de este tipo de declaraciones, donde al principio se declaran unos
tipos y cabeceras de funcion, y a continuacion se denen las funciones en un PACKAGE
BODY:
PACKAGE tipos_mios IS
SUBTYPE direcc IS bit_vector(23 DOWNTO 1);
SUBTYPE dato IS bit_vector(15 DOWNTO 0);
CONSTANT inicio: direcc; -- Habra que definirlo en el BODY
FUNCTION datotoint(valor: dato) RETURN integer;
FUNCTION inttodato(valor: integer) RETURN dato;
END tipos_mios;
Como la constante y las funciones no han sido denidas se debe hacer esto en el
cuerpo del paquete:
PACKAGE BODY tipos_mios IS
CONSTANT inicio: direcc:=X"FFFF00";
FUNCTION datotoint(valor: dato) RETURN integer IS
el cuerpo de la funcion datotoint
END datotoint;
FUNCTION inttodato(valor: integer) RETURN dato IS
el cuerpo de la funcion inttodat
END inttodato;
END tipos_mios;
Una vez se han declarado los paquetes de esta manera. los elementos de los que
esta compuesto se les puede referenciar con el nombre del paquete y del elemento
separados por un punto. Por ejemplo, para hacer visibles la constante o los tipos
del ejemplo anterior se hara simplemente:
VARIABLE pc: tipos_mios.direcc;
pila:=tipos_mios.inicio+X"FF";
desp:=tipos_mios.datotoint(registro);
Aunque esto era una forma posible de referenciar los elementos de un paquete, no
es la forma usual de referenciarlos. Lo que se suele hacer es hacer visible el paquete
de manera que se puedan referenciar algunos o todos sus elementos sin necesidad del
punto. Los elementos de un paquete se pueden hacer visibles para el chero de dise~no
actual mediante el comando USE tal y como se haba mostrado anteriormente. De esta
manera, el ejemplo anterior se puede simplicar empleando un USE en la cabecera del
programa:
USE tipos_mios.ALL
VARIABLE pc: direcc;
pila:=inicio+X"FF";
desp:=datotoint(registro);
7.2.2 Conguracion: CONFIGURATION

En el ejemplo 3.1, al principio de este captulo, se mostro un ejemplo de descripcion
estructural de un circuito utilizando VHDL. En aquella descripcion estructural se de-
clararon unos componentes mediante la declaracion COMPONENT, y luego se instanciaron
en el interior de la descripcion. Un componente, tal y como estaba denido en aquel
ejemplo, no es mas que una referencia a una arquitectura y una entidad. Es evidente
que este lazo entre el componente y su entidad y correspondiente arquitectura o arqui-
tecturas debe existir ya que de otra forma no se podra saber a que objeto corresponde
el componente y, por tanto, no se podra simular el circuito.
La forma en que a cada componente se le asocia una entidad se especica en una
unidad especial del lenguaje que se llama conguracion. La forma en la cual se dene
este bloque es mediante la palabra clave CONFIGURATION:
CONFIGURATION nombre OF la_entidad IS
declaraciones
configuracion
END nombre;
En las declaraciones lo normal es utilizar clausulas de tipo USE para denir tipos
y demas, aunque se pueden denir directamente.
En la parte de configuracion se especican las constantes genericas para bloques
y componentes, aparte de otros elementos pertenecientes a bloques y elementos. La
forma es que se especican las caractersticas de estos elementos en una conguracion
es mediante el uso de FOR, y es un poquito diferente segun sea bloque o componente:
-- bloques -- bloques
FOR nombre_bloque FOR nombre_componente
clausula use USE objeto union
elementos definicion bloque
END FOR; END FOR;
El nombre bloque es el nombre de una arquitectura o el nombre de la etiqueta de un

bloque. En el caso de componentes, el nombre componente el nombre de la instancia
concreta seguido por el nombre del componente y separados por dos puntos. Como
instancias se pueden usar las palabras clave ALL, todas las instancias, u OTHERS, para
indicar el resto de instancias. Las instancias se pueden separar por comas.
La clausula USE en el caso del componente sirve para indicar la entidad o la congu-
racion que se desea asociar. Con objeto decimos si hacemos referencia a una ENTITY
o CONFIGURATION. En el caso de la entidad se pone el nombre, y opcionalmente la ar-
quitectura entre parentesis. En el caso de la conguracion se pone el nombre de esta
sin mas. Es interesante asociar una arquitectura a un componente puesto que enti-
dad solo hay una, pero arquitecturas puede haber varias, y dependiendo de lo que se
este haciendo en cada momento puede interesar una arquitectura u otra.
Ejemplo 7.2 A~nadir las unidades de entidad, arquitectura y conguracion necesarias
para completar el ejemplo 3.1.
ENTITY inv IS PORT (e: IN bit; y: OUT bit); END inv;
ENTITY and2 IS PORT (e1,e2: IN bit; y: OUT bit); END and2;
ENTITY or2 IS PORT (e1,e2: IN bit; y: OUT bit); END or2;
ARCHITECTURE rtl OF inv IS BEGIN y<=NOT e; END rtl;

ARCHITECTURE rtl OF or2 IS BEGIN y<=e1 OR e2; END rtl;
ARCHITECTURE rtla OF and2 IS BEGIN y<=e1 AND e2; END rtla;
ARCHITECTURE rtlb OF and2 IS -- dos arquitecturas diferentes
BEGIN
y<='0' WHEN (e1='0' OR e2='0') ELSE '1';
END rtlb;
CONFIGURATION estru OF mux IS

-- poniendo USE work.ALL aqui, no haria falta poner work cada vez.
FOR estructura
FOR ALL: inv USE ENTITY work.inv;
FOR u1: and2 USE ENTITY work.and2(rtla);
FOR OTHERS: and2 USE ENTITY work.and2(rtlb);
FOR ALL: or2 USE ENTITY work.or2;
END FOR;
END estru;

Captulo 8
VHDL para simulacion
El lenguaje VHDL sirve tanto para sntesis automatica de circuitos como para des-
cripcion de modelos para simulacion. Es evidente que la losofa de descripcion en uno
y otro caso son diferentes. Por un lado la simulacion de un programa en VHDL no tiene
demasiadas restricciones, lo unico que se necesita es un interprete de los comandos e
instrucciones VHDL. La sntesis, en cambio, tiene muchas mas restricciones puesto que
al nal se debe obtener un circuito real que realice la misma funcion que lo que viene
descrito en el programa. Si el nivel de abstraccion es muy alto, la sntesis sera muy
difcil llegando a la posibilidad de que sea imposible sintetizar un circuito a partir de
la especicacion.
En simulacion, aparte de que el nivel de abstraccion importa poco, habra una serie
de elementos que solo tienen signicado en un entorno de simulacion. Estos elementos
son retrasos, se~nalizacion de errores, etc. en sntesis, estos elementos, especialmente los
retrasos, no tienen ningun sentido y se deben evitar.
8.1 Los retrasos y la simulacion

En simulacion existe un elemento importantsimo que no se ha visto hasta ahora, y es el
retraso de las lneas. En todo circuito digital, aparte de la funcionalidad que se pueda
implementar, existe siempre un retraso entre que se producen los estmulos de entrada
y la salida cambia.
Para poder poner en practica este funcionamiento a base de retrasos, los lenguajes
de descripcion de modelos, suelen utilizar lo que se llaman drivers. El concepto de
driver es algo que ya aparecio cuando se explicaron las asignaciones a se~nales y las
diferencias entre se~nal y variable en la ejecucion secuencial.
La forma en que funciona la asignacion de una se~nal es como sigue: cuando se
le asigna un valor a una se~nal, no se le asigna este valor a la se~nal, sino que se le
asigna a su driver. La informacion del driver pasa a la se~nal cuando se llega al tiempo
especicado en la asignacion. Hasta ahora nunca se ha especicado ningun tiempo en
las asignaciones, en estos casos se considera que el tiempo, o retraso, es nulo y por tanto
la asignacion debe producirse de forma inmediata. Esta asignacion inmediata signica
en realidad que se realice la asignacion al nal del presente paso de simulacion, siendo
un paso de la simulacion la ejecucion de una instruccion concurrente.
67
68 VHDL para simulacion
Vamos a ver a continuacion que en la asignacion de una se~nal se puede especicar
ademas un retraso. Este retraso va a indicar que se le asigne el valor dado a una
se~nal pero cuando haya transcurrido el tiempo especicado en el retraso. Esto quiere
decir que la informacion va a permanecer en el driver hasta que haya pasado el tiempo
especicado por lo que la se~nal no sera actualizada hasta despues de transcurrido este
tiempo.
Para indicar este retraso en las asignaciones se emplea la palabra AFTER como en el
siguiente ejemplo:
senal<='0' AFTER 15 ns;
Esto quiere decir que cuando hayan pasado 15 ns desde la asignacion entonces la
se~nal tomara el valor '0', y hasta entonces conservara el que tenga en ese momento.
Es interesante hacer notar que cuando se simula un circuito descrito en VHDL
aparece el concepto de tiempo de simulacion. Este tiempo transcurre gracias a la
sucesion de eventos. En la instruccion anterior, donde se asignaba un '0' a senal
despues de 15 ns, en realidad estabamos produciendo un evento que tendra lugar dentro
de 15 ns. El simulador de VHDL guarda una lista de todos los eventos que se generen y
los ordena segun el momento en que tengan que procesarse. La simulacion tiene lugar
por el procesado en serie de los diferentes eventos, es decir, despues de que el simulador
procesa el evento actual, pasa al evento siguiente, este evento siguiente tendra asociado
un tiempo que si no coincide con el actual provocara que el tiempo de simulacion se
incremente. Cuando se procese ese nuevo evento, se produciran nuevos eventos que se
colocaran al nal de la lista, y as sucesivamente se simula el circuito y el tiempo va
transcurriendo.
Una descripcion del ujo que suele seguir un simulador en VHDL se muestra en
la gura 8.1 donde es un paso de simulacion donde el tiempo no corre, y T es
un paso donde el tiempo corre realmente. Este ujo corresponde a lo que se conoce
como simulacion guiada por eventos. Los simuladores digitales suelen emplear otra que
practicamente es parecida aunque el tiempo, en vez de incrementarse por el proximo
evento que vaya a ocurrir, se incrementa un tiempo jo cada vez de manera que si hay
algun evento en ese intervalo de tiempo se procesa.
Gracias al concepto de evento es facil entender que en una asignacion se pueden
programar varios eventos o sucesos que tendran lugar en el futuro. En el ejemplo
siguiente se muestra como realizar varias asignaciones a una misma se~nal:
senal<='1' AFTER 4 ns, '0' AFTER 20 ns;
Cuando se produce la ejecucion de esta instruccion, se estan utilizando dos drivers
en realidad, en uno se mete un '1' y en el otro un '0'. En principio no hay con icto
puesto que tienen lugar en tiempos diferentes. Con esta asignacion la se~nal tomara el
valor '1' a los 4 nanosegundos de su ejecucion, y 16 nanosegundos despues tomara el
valor '0'.
Ejemplo 8.1 Realizar el modelo de simulacion de un registro tipo D, activo por anco
de subida, que tiene un retraso de 10 nanosegundos, desde el anco de subida del reloj
hasta que la salida cambia, y un tiempo de establecimiento set-up de 5 ns. (Para el
tiempo de establecimiento supondremos que si se produce una violacion se coge el valor
anterior de la se~nal de entrada y no el que haya en el momento del anco).
Este es un ejemplo tpico donde se especica el retraso en una se~nal de salida, para
8.1 Los retrasos y la simulacion 69
Inicialización
Ejecución
Instrucción concurrente
Actualiza drivers
Genera nuevos eventos
∆δ
sí
¿Evento activo?
no
∆T
(fijado por el próximo evento)
no
¿Fin tiempo?
sí
Fin
Figura 8.1: Flujo de simulacion por eventos en VHDL
el retraso respecto del reloj, y un retraso en una se~nal de entrada, para realizar el
tiempo de establecimiento que se pide. Para los tiempos de establecimiento lo que se
suele hacer es retrasar la se~nal de entrada justo el tiempo de establecimiento, y usar
esta se~nal interna retrasada como si no hubiera tiempo de establecimiento. Veamos la
descripcion como quedara:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL
ENTITY ff IS
PORT(d,clk: IN std_logic;
q: OUT std_logic);
END ff;
ARCHITECTURE ejemplo OF ff IS
SIGNAL daux: std_logic;
BEGIN
PROCESS(clk)
BEGIN
IF clk='1' THEN
q<=daux AFTER 10 ns; -- Retraso respecto del reloj
END IF;
END PROCESS;
daux<=d AFTER 5 ns; -- Tiempo de establecimiento (set-up)
END ejemplo;

8.1.1 Retrasos inerciales y transportados
Se ha visto que en la asignacion de una se~nal en realidad lo que se hace es poner en una
lista sus valores futuros ordenados por tiempo. En cada asignacion que se hacen los
eventos se van a~nadiendo a la lista ordenandolos segun les vaya a tocar, es decir, segun
el retraso asociado. No obstante, el momento en que se ejecuta la asignacion, es decir,
el tiempo en el que se introducen nuevos eventos juega un papel importante de manera
que se pueden denir dos formas de introducir los eventos en la lista, cada forma con
un signicado fsico concreto tal y como se muestra a continuacion.
Supongamos una puerta logica. Esta puerta tendra un retraso asociado, de manera
que la salida cambiara un momento despues de que haya cambiado la entrada, por
ejemplo, 50 ns despues. Esta puerta logica, un inversor por ejemplo, se realizara de la
siguiente forma:
sal<=NOT ent AFTER 50 ns;
Al principio de la simulacion, y cada vez que la entrada ent cambia, se ejecuta esa
instruccion, es decir, se introduce en la lista de eventos de la salida la entrada invertida
con un retraso de 50 ns. Supongamos ahora que la salida cambia en menos de 50 ns
(imaginar por ejemplo un pulso en la entrada de 30 ns). Como la salida ha cambiado
antes de que el cambio anterior se haya producido, ese evento anterior se pierde. Para
verlo un poco mas claro seguiremos la simulacion que aparece en la gura 8.2, donde la
columna de la izquierda supone un pulso de entrada de 30 ns y la de la derecha uno de
60 ns; en ambos casos se representa la salida segun se considere un retraso inercial, que
es el caso que se discute ahora, o transportado, que se vera mas adelante. Supongamos
que al inicio esta todo estabilizado y que por tanto para la entrada cero la salida es
uno. Despues de 10 ns ponemos la entrada a uno, es el comienzo del pulso. Esto quiere
decir que se introduce el evento \poner a cero la salida despues de 50 ns", o lo que es lo
mismo \poner a cero la salida a los 60 ns de tiempo absoluto". Este evento se introduce
en la lista de drivers de la se~nal de salida. Supongamos que esperamos otros 30 ns mas
(duracion del pulso) y cambiamos la entrada pasandola a cero otra vez. Entonces se
esta produciendo un nuevo evento que es \poner a uno la salida despues de 50 n". Lo
que uno espera normalmente es que se ponga en la lista, detras del evento anterior, y
conforme vayan llegando el momento de ejecutarse los eventos se ejecutan y ya esta.
Esto no ocurre as, al menos deniendo los retrasos como se ha hecho hasta ahora. Lo
que va a ocurrir es que este ultimo evento va a sustituir al anterior, por lo que el primer
evento desaparece y no se procesa nunca y la se~nal de salida nunca pasara a cero a
pesar de que la entrada ha sido uno durante 30 ns.
ent
sal
(inercial)
sal
(transportado)
20 40 60 80 100 t(ns) 20 40 60 80 100 120 t(ns)
Figura 8.2: Retrasos inerciales y transportados

8.2 Descripcion de un banco de pruebas 71
A esta forma de gestionar los eventos en la lista y de generar los retrasos se le llama
retraso inercial, y es el retraso por defecto en VHDL. En el ejemplo anterior, cualquier
pulso de entrada menor de 50 ns no tendra ningun efecto sobre la salida puesto que
siempre se producira un evento antes de que se pueda ejecutar el primero. Esto tiene
un gran signicado fsico puesto que es lo que suele pasar en algunas puertas logicas que
cuando se les mete un pulso, si no tiene la duracion adecuada, nunca llega a modicarse
la salida.
Naturalmente hay sistemas donde este ltraje no es adecuado. Si pensamos por
ejemplo en una lnea de trasmision, no importa la duracion del pulso que se pueda
introducir o el retraso que pueda tener la lnea, a la salida siempre se obtiene el pulso de
entrada tal cual. En este caso al retraso se le llama retraso transportado, puesto que
en realidad la se~nal de entrada se transporta a la salida sin modicarla para nada. En
cuanto al tratamiento de la lista de eventos o drivers, lo que se hace es que simplemente
se introduce el evento en la lista, en el lugar que le corresponde segun el retraso, y
cuando le toca procesarse se procesa.
En VHDL hay que indicar explcitamente este tipo de retraso transportado puesto
que no es el que hay por defecto. Esta indicacion se realiza mediante la palabra clave
TRANSPORT. As, si en el ejemplo anterior quisi eramos que los pulsos menores que el
retraso pasaran al otro lado pondramos:
sal<=TRANSPORT NOT ent AFTER 50 ns;
En el caso de asignaciones multiples, solo la primera es inercial, mientras que las
siguientes se consideran transportadas. Es evidente que si esto no fuera as, solo la
ultima asignacion sera valida y el resto seran ignoradas, lo cual no tiene mucho sentido.
8.2 Descripcion de un banco de pruebas

El objetivo del lenguaje VHDL es la descripcion de circuitos digitales, esta descripcion
podra ser usada como un modelo para simulacion o como descripcion de un circuito
para ser sintetizado. En ambos casos interesa simular la descripcion que se ha hecho
para ver si realmente funciona como se pretende. El problema de la simulacion de
este modelo se puede abordar de varias formas, probablemente las mas rapida sea la
de coger la herramienta de simulacion y empezar a introducir cambios en las entradas
para ver como varan las salidas. Este procedimiento puede servir para simular cosas
simples, pero para simulaciones mas complejas y exhaustivas es mejor denirse lo que
se denomina un banco de pruebas (test bench).
Este banco de pruebas no es mas que la denicion de unas cuantas entradas llamadas
patrones de test con las que comprobar el circuito o modelo. Normalmente las herra-
mientas de simulacion ofrecen alguna manera de denirse estos vectores de entrada,
bien mediante gracos, o cheros de vectores, etc. En el caso del VHDL estos vectores
se pueden denir con el propio lenguaje, de manera que se puede crear un banco de
pruebas que es independiente del simulador.
Este banco de pruebas no es mas que una entidad, sin entradas ni salidas en su
caso mas simple, cuya arquitectura, de tipo estructural, tiene como se~nales internas las
entradas y salidas del circuito y como unico componente el correspondiente a la entidad
que se desea simular. Esto se ve mucho mas claro en el siguiente ejemplo donde se va
a realizar el banco de pruebas para una puerta and2 de dos entradas y una salida. Se
supone que tanto la entidad como la arquitectura estan denidas en algun sitio de la
librera de trabajo o son visibles:
ENTITY test IS -- no tiene entradas ni salidas
END test;
ARCHITECTURE estimulos OF test IS

SIGNAL a,b,s: bit
COMPONENT and2 PORT(a,b: IN bit; s: OUT bit); END COMPONENT;
FOR puerta: and2 USE ENTITY work.and2;
BEGIN
puerta: and2 PORT MAP(a,b,s);
a<='0', '1' AFTER 200 ns;
b<='0', '1' AFTER 100 ns, '0' AFTER 200 ns, '1' AFTER 300 ns;
END estimulos;
8.3 Noticacion de sucesos

Durante la simulacion de un circuito descrito en VHDL es muchas veces interesante
la noticacion de ciertos sucesos. Por ejemplo puede ser util sacar un mensaje por
pantalla indicando que cierta se~nal se ha activado. Estos mecanismos de noticacion
son especialmente utiles en la deteccion de violaciones de los tiempos de setup y hold
en registros y latches.
La forma en que se pueden noticar estos sucesos es mediante la utilizacion de la
palabra clave ASSERT que tendra como elemento de activacion una condicion:
ASSERT condicion REPORT mensaje SEVERITY nivel gravedad;
Si no se cumple la condicion especicada en condicion entonces se saca el mensaje
especicado por pantalla y se da ademas un nivel de gravedad. Tanto el mensaje como el
nivel de gravedad son opcionales. Si no se especica ningun mensaje aparece la cadena
"Assertion Violation". El nivel de gravedad es el tipo predenido severity level.
Los niveles de gravedad que hay son: NOTE, WARNING, ERROR y FAILURE, y si no se
especica nada el valor por defecto es ERROR. En el momento se produce una violacion
de cualquier tipo, el simulador puede detener la ejecucion o no dependiendo del nivel
de gravedad del error.
Esta instruccion puede ser usada tanto en entornos concurrentes como en serie. En
entornos concurrentes se ejecutara cada vez que cambien algunas de las se~nales que
intervienen en la condicion. En el entorno serie se ejecuta cuando le toque el turno en
el proceso normal de ejecucion. A continuacion se dan tres ejemplos de utilizacion de
estos mensajes:
-- Violacion de setup:
ASSERT NOT(clk'EVENT AND clk='1' AND NOT(d'stable(20 ns)))
REPORT "Violacion del tiempo de setup"
SEVERITY WARNING;
-- Violacion de la anchura de un pulso:

ASSERT (preset'delayed='1' AND preset='0' AND preset'delayed'last_event>=25 ns)
REPORT "Anchura de pulso demasiado pequenya";

8.3 Noticacion de sucesos 73
-- Para depurar programas:
ASSERT FALSE
REPORT "La ejecucion paso por aqui"
SEVERITY NOTE;
8.3.1 Procesos pasivos

Un uso interesante de las instrucciones de aviso ASSERT, es la inclusion de estas senten-
cias en lo que se llaman procesos pasivos. Cuando se explico la declaracion de entidad,
se dijo que era posible denirse sentencias concurrentes e incluso procesos en el propio
cuerpo de la entidad. A estos procesos, denidos dentro de una entidad y que por tanto
no describen funcionalidad, se les llama procesos pasivos.
Lo unico que pueden hacer los procesos pasivos es realizar comprobaciones y, median-
te sentencias ASSERT avisar de violaciones dentro de la ejecucion. Resulta interesante
colocarlos en la entidad ya que as sirven para cualquier arquitectura que se pueda de-
nir. A continuacion veremos un ejemplo de utilizacion de un proceso pasivo para la
comprobacion del tiempo de establecimiento (set-up).
Ejemplo 8.2 A~nadir un proceso pasivo en la entidad del registro del ejemplo 8.1 que
detecte la violacion del tiempo de establecimiento y emita un mensaje.
En principio la arquitectura quedara igual por lo que no habra que modicarla,
solamente la entidad incluira, entre un BEGIN y un END el ASSERT visto en los tres
ejemplos anteriores. Pero supongamos que no se dispone de dichos atributos para la
se~nal de entrada y queremos hacerlo \a pelo", entonces una posible solucion, donde
ademas se muestra como se maneja el tiempo de simulacion, se da a continuacion:
ENTITY ff IS
PORT(d,clk: IN std_logic;
q: OUT std_logic);
BEGIN
PROCESS(clk,d)
VARIABLE tiempo_d_cambio: TIME := 0 ns;
VARIABLE clk_ultimo, d_ultimo: std_logic := 'X';
BEGIN
IF d/=d_ultimo THEN
tiempo_d_cambio:=NOW;
d_ultimo:=d;
END IF;
IF clk/=clk_ultimo THEN
IF clk='1' THEN
ASSERT (NOW-tiempo_d_cambio>=5 ns)
REPORT "Error en el tiempo de establecimiento"
SEVERITY WARNING;
END IF;
clk_ultimo:=clk;
END IF;
END PROCESS;
END ff;
Naturalmente aqu se ha supuesto que ni siquiera se tiene el atributo 'EVENT, lo cual

solo se justica considerando que este ejemplo es mas pedagogico que otra cosa. En el
caso de haber utilizado este atributo, bastara conservar el IF mas interior a~nadiendole
AND clk'EVENT en la condici on; con esto, la condicion y la variable de reloj sobran.
Tambien se ha introducido la funcion predenida NOW que da el tiempo de simulacion
en el momento en que se ejecuta la instruccion.

Captulo 9
VHDL para sntesis
La sntesis de un circuito a partir de VHDL consiste en reducir el nivel de abs-
traccion de la descripcion de un circuito hasta convertirlo en una denicion puramente
estructural cuyos componentes son los elementos de una determinada librera de com-
ponentes, que dependera del circuito que se quiera realizar, la herramienta de sntesis,
etc. Al nal del proceso de sntesis se debe obtener un circuito que funcionalmente se
comporta igual que la descripcion que de el se ha hecho.
En un principio, cualquier descripcion en VHDL es sintetizable, no importa el nivel
de abstraccion que la descripcion pueda tener. Esto, que en principio puede parecer
sorprendente no lo es en absoluto ya que cualquier descripcion en VHDL se puede
simular, y si se puede simular, el propio simulador (en general un ordenador ejecutando
un programa) es un circuito que funcionalmente se comporta tal y como se ha descrito,
por lo tanto es una sntesis del circuito que se ha descrito. Es evidente que no sera el
circuito mas optimizado para realizar la tarea que se pretende, ni lo hara a la velocidad
que se requiere, pero seguro que funcionalmente se comporta tal y como se ha descrito.
La complejidad del circuito resultante, y tambien incluso la posibilidad o no de
realizar el circuito, va a depender sobre todo del nivel de abstraccion inicial que la des-
cripcion tenga. En primera aproximacion se puede coger un ordenador que ejecute la
simulacion, y ya tengo la sntesis. A partir de esta primera aproximacion hay que ir op-
timizando el circuito. En realidad las herramientas de sntesis siguen una aproximacion
distinta, ya que de otra manera, el circuito sera algo parecido a un microprocesador
cuando quiza solo se pretende implementar una puerta logica.
La aproximacion de las herramientas de sntesis consiste en, partiendo de la des-
cripcion original, reducir el nivel de abstraccion hasta llegar a un nivel de descripcion
estructural. La sntesis es por tanto una tarea vertical entre los niveles de abstraccion
de un circuito. As, una herramienta de sntesis comenzara por la descripcion com-
portamental abstracta y secuencial e intentara traducirla a un nivel de transferencia
entre registros descrita con ecuaciones de conmutacion. A partir de esta descripcion se
intentara transformarla a una descripcion estructural donde se realiza ademas lo que
se llama el mapeado tecnologico, es decir, la descripcion con los componentes de una
librera especial que depende de la tecnologa con la cual se quiera realizar el circuito.
Las herramientas de sntesis actuales cubren a la perfeccion la sntesis a partir de
descripciones RTL y estructurales, pero no estan tan avanzadas si el dise~no se encuentra
descrito en un nivel de abstraccion mas alto. No es que no se pueda sintetizar a partir
de un nivel alto de abstraccion, lo que ocurre es que la sntesis obtenida no es quiza la
75
76 VHDL para sntesis
mas optima para el circuito que se pretende realizar.
9.1 Restricciones en la descripcion

No se va a explicar en esta seccion el funcionamiento interno de las herramientas de
sntesis, pero s que conviene dar algunas nociones de como una herramienta de sntesis
interpreta algunas de las instrucciones en VHDL. E sto es interesante porque muchas
veces es mas sencillo para el dise~nador simplicar ciertas cosas que dejar esta tarea
a una maquina que lo puede hacer mal. Ademas, puede ocurrir que un sintetizador
de una interpretacion algo diferente de cierta estructura, por lo tanto conviene aclara
tambien si un circuito es combinacional, secuencial, sncrono, etc.
Todas estas consideraciones van a imponer unas restricciones a lo que es el lengua-
je, por lo tanto, cualquiera que pretenda usar el VHDL para sntesis de circuitos debe
conocerlas. Estas restricciones dependen de cada herramienta de sntesis, ya que depen-
diendo de la calidad de la herramienta pueden interpretar mas estructuras del lenguaje
o menos. El fabricante de estas herramientas suele dar el subconjunto del lenguaje que
el sintetizador es capaz de interpretar, as como las interpretaciones que hace de deter-
minadas estructuras que dejan de ser estandar pero que facilitan el dise~no y su posterior
sntesis. No obstante, hay determinadas recomendaciones que suelen ser comunes a la
mayora de las herramientas de sntesis. Veamos a continuacion unas cuantas:
Evitar las clausulas temporales Normalmente los simuladores prohiben expresa-
mente el uso de asignaciones con retraso en las se~nales, en otras simplemente
los ignoran, pero lo que esta claro es que el sintetizador intentara implementar el
circuito funcionalmente, por lo que estos retrasos no tienen sentido para el sinte-
tizador. Aparte de esto, no se permiten las asignaciones multiples, en una unica
sentencia, a una se~nal por la misma razon.
Identicar cada puerta con claridad Las puertas logicas y otros elementos tienen
generalmente una estructura clara e incluso se pueden utilizar comandos directos
que realizan estas funciones. Desde luego no es nada conveniente denirse una
puerta tal y como se hizo en el ejemplo 6.2.
Evitar las sentencias de espera En algunos sintetizadores quiza sea posible utilizar
sentencias de espera WAIT dentro de los procesos, pero no es nada aconsejable
puesto que la herramienta puede tener dicultades en interpretar estas sentencias.
Es aconsejable en cambio el uso de listas sensibles, y en muchos sintetizadores es
casi la unica posibilidad. El uso del WAIT esta bastante restringido, as, si se usa,
algunas herramientas exigen que sea la primera instruccion del PROCESS, y solo se
permite una condicion.
Cuidado con las listas sensibles La mayora de sintetizadores admiten la lista sen-
sible o una sentencia WAIT al principio, pero no siempre la interpretan como lo
hara un simulador ya que en determinadas ocasiones el proceso se ejecutara cuan-
do cambia una se~nal que se encuentra en el proceso pero no en la lista sensible o
en el WAIT.
Permitir discrepancia Normalmente es facil sintetizar algo simple como s<=NOT s
ya que no es mas que una puerta inversora conectada sobre si misma que puede
servir muy bien para generar una se~nal de reloj con periodo el doble que el retraso
que la puerta presente. Si se intenta simular algo como la instruccion anterior, se
comprobara que la simulacion se queda colgada en esa instruccion puesto que no
9.2 Construcciones basicas 77
hay retrasos y se llama a s misma una y otra vez. Por lo tanto, en estos casos,
aunque la simulacion es incorrecta, la sntesis lo es.
Se~nales de reloj Normalmente solo se permite una se~nal de reloj por proceso, y
ademas debe especicarse claramente el anco de subida del reloj mediante la
condicion clk='1' AND clk'EVENT. En general solo puede ponerse esta condi-
cion una vez por proceso y en ningun caso se puede poner ELSE en el IF en el que
se uso la condicion.
Asignaciones unicas Aunque en simulacion es bastante corriente que a una se~nal se
le asignen varios valores a lo largo de un mismo proceso, en sntesis esto resulta
difcil de interpretar y no debe usarse (normalmente no se permite).
Evitar IFs anidados Normalmente las herramientas tienden a no sintetizar de ma-
nera optima varios condicionales anidados entre s. Los condicionales es mejor
utilizarlos a solas.
Utilizar CASE mejor que varios IFs Las estructuras CASE tienen para los sintetiza-
dores un modelo optimizado de sntesis, generalmente mejor que lo mismo descrito
mediante IFs.
Utilizar el estilo indicado para las maquinas de estado Muchos de los proble-
mas digitales se pueden resolver de forma sencilla mediante una maquina de es-
tados. En VHDL hay muchos estilos diferentes para poder describir maquinas de
estados, entonces a veces ocurre que el sintetizador no se da cuenta de que lo que
tiene delante es una maquina de estados y no optimiza bien el circuito resultante.
En los manuales de los sintetizadores suelen venir ejemplos de lo que la herra-
mienta entendera que es una maquina de estados, entonces es mejor utilizar ese
estilo aunque no nos resulte comodo, el resultado nal sera bastante mas optimo.
Especicar la arquitectura Es posible que se creen varias descripciones para un
mismo circuito. Normalmente el sintetizador cogera la primera que le parezca,
por lo que conviene especicar cual de todas las arquitecturas se desea sintetizar
mediante un bloque de conguracion CONFIGURATION.
Con estas restricciones ahora expuestas, y hay algunas mas que dependeran del
sintetizador, ya nos damos cuenta de que no basta con describir algo en VHDL y ver
que funciona para poderlo sintetizar, hay que ademas conocer bien la herramienta de
sntesis, saber que cosas no se pueden describir, y ademas hacer la descripcion lo mas
optimizada posible. Para ello es bueno, que se conozcan como se sintetizan algunas de
las estructuras basicas del VHDL, o por lo menos conocer si lo que se esta describiendo
es logica combinacional, o secuencial.
9.2 Construcciones basicas

El primer paso es ver si un circuito describe logica combinacional o secuencial. Un
circuito describe logica combinacional si la salida depende unicamente de la entrada en
ese instante y no de la entrada que hubiera en un pasado, es decir, ante una entrada
dada la salida es siempre la misma. Un circuito describe logica secuencial cuando la
salida depende de la entrada actual y de las entradas anteriores, o dicho de otra forma, la
salida depende de la entrada y del estado del sistema. Esto introduce un nuevo elemento
dentro del sistema que sera la memoria, por tanto, cualquier sistema que tenga al menos
una se~nal que ante el cambio de unas se~nales cambie, pero que pueda ocurrir que ante
el cambio de las mismas se~nales conserve su valor, entonces se tratara de un sistema
secuencial ya que dicha se~nal es un elemento de memoria. Esto nos da una pista de si
un circuito sera secuencial y se realizara por tanto a partir de elementos de memoria
como puedan ser cerrojos o registros.
9.2.1 Descripcion de logica combinacional

La idea basica es que si en la estructura del lenguaje no introducimos \elementos de
memoria" entonces estaremos delante de una descripcion combinacional. Vamos a ver
entonces como evitar que aparezcan elementos de memoria y que por tanto el circuito
se realice solo con puertas logicas. Los requisitos para conseguir esto seran entonces:
Si la ejecucion es concurrente se dene logica combinacional cuando:
{ La se~nal que esta siendo asignada no interviene en la asignacion. Ejemplos:
a<=b WHEN h='1' ELSE c; -- combinacional
a<=b WHEN h='1' ELSE a; -- secuencial
a<=b WHEN a='1' ELSE c; -- secuencial
Si la se~nal interviniera en la asignacion entonces habra casos para los cuales se
conserva su valor, y por tanto sera un elemento de memoria.
{ No hay lazos combinacionales (en realidad esta es una extension de la anterior).
Ejemplos:
-- Secuencial -- Combinacional
d<=b AND a; d<=b AND c;
a<=d OR e; a<=d OR e;
Si la ejecucion es serie (proceso) se sintetiza logica combinacional cuando:

{ La lista sensible de un proceso incluye todas las se~nales implicadas en las asig-
naciones. Es claro que si alguna se~nal no esta en la lista sensible, cuando se
produzca un cambio en esta se~nal, el proceso no se ejecutara y no habra cambios
en las se~nales internas del proceso que por tanto conservan su valor, por lo que
se tratara de un circuito secuencial.
{ Se asignan todas las variables y se~nales que intervienen. Normalmente esto se
aplica a instrucciones condicionales. Si hay una condicion para la cual la se~nal
no se asigna, es decir, se queda igual, esto indica la presencia de un latch. La
explicacion es la misma, si para una determinada condicion no se realiza la
asignacion, entonces la se~nal no asignada conserva su valor y por tanto es un
elemento de memoria. Ejemplo:
-- Combinacional -- Secuencial
PROCESS(b,c,e,d) PROCESS(b,c,e,d)
BEGIN BEGIN
IF b='1' THEN d<=c; IF b='1' THEN d<=c;
ELSE d<=0; END IF;
END IF; a<=d OR e;
a<=d OR e; END PROCESS;
END PROCESS;
c d
c Latch
Mux d a
0 a e
e
b
b

9.2 Construcciones basicas 79
9.2.2 Descripcion de logica secuencial
Un circuito es secuencial si su salida puede depender del estado del sistema. Desde
el punto de vista del VHDL, las reglas que hemos visto para la descripcion de logica
combinacional nos sirven aqu para decir que si cualquiera de las reglas anteriores no se
cumple, entonces el circuito describe logica secuencial. En este sentido, en vez de repetir
las mismas reglas pero poniendolas en negado, vamos a ver como describir algunos de
los elementos basicos de un circuito secuencial como latches, registros, relojes, etc.
Descripcion de latches Un latch o cerrojo es un circuito que mantiene la salida a un
valor cuando una se~nal de control esta inactiva, y la salida es igual a la entrada
cuando dicha se~nal de control esta activa. Normalmente la se~nal esta activa si
esta a nivel alto o '1' e inactiva si esta a nivel bajo o '0', pero puede ser al reves,
por eso mejor usar activo-inactivo. Veamos como se describe esto de forma serie
(proceso) y concurrente:
Serie Hay varias posibilidades:
Cuando en un proceso no se consideran todas las posibles asignaciones
se pone un latch en esa se~nal:
-- biestable tipo D:
PROCESS(d,en)
BEGIN
IF (en='1') THEN q<=d;
END IF;
END PROCESS;
Cuando no se especican todas las se~nales en la lista sensible:
PROCESS(b)
BEGIN
a<=d OR b; -- d esta "latcheado" por b
END PROCESS;
Esta segunda forma no es la mas adecuada en un caso real de sntesis ya
que muchos sintetizadores no lo interpretan bien, de hecho, supondran
en la mayora de los casos que d forma parte de la lista sensible y lo
anterior se realizara como si fuera logica combinacional.
Concurrente Suele ponerse un latch cuando la se~nal que esta siendo asignada
interviene en la asignacion:
a<=b AND c WHEN h='1' ELSE a;}
En este caso la se~nal a se encuentra latcheada por la se~nal h. En realidad esta
expresion puede interpretarse tambien como logica combinacional donde se
da una realimentacion, pero precisamente esta realimentacion es la base para
la realizacion de cerrojos y logica secuencial (por ejemplo, los ip- op estan
realizados internamente mediante puertas). Lo que s que puede ocurrir es
que dependiendo de la herramienta que estemos utilizando, lo anterior se
realice mediante puertas o mediante un elemento de la librera que sea un
cerrojo o latch, siendo esta segunda opcion la mas comun y optima en general.
Descripcion de se~nales de reloj La se~nal de reloj se dene mediante la deteccion
del anco de subida o bajada de una se~nal. Normalmente se utiliza una condicional
de manera que se detecte la siguiente condicion:
clk'EVENT AND clk='1' -- Flanco de subida
clk'EVENT AND clk='0' -- Flanco de bajada
En VHDL no hay problema en denirse un reloj que fuera activo en ambos ancos,
pero eso no es sencillo de sintetizar por lo que si hay un reloj se debe utilizar uno
solo de los ancos. Ademas, y como se dijo al principio de este captulo, en la
mayora de los casos se permite una unica se~nal de reloj por proceso.
Descripcion de registros Los registros son como los latches pero la entrada pasa a
la salida cuando se produce un anco de la se~nal de reloj:
PROCESS(clk,reset) PROCESS(clk)
BEGIN BEGIN
IF reset='1' THEN q<='0'; IF clk='1' THEN q<=d;
ELSIF clk'EVENT AND clk='1' THEN q<=d; END IF;
END IF; END PROCESS;
END PROCESS;
En el ejemplo de la derecha se observa que en realidad no hace falta especicar

la condicion de evento ya que al estar la se~nal de reloj sola en la lista sensible,
solo se ejecuta el proceso si se produjo un evento en la se~nal. Ambos ejemplos son
equivalentes y sintetizan casi lo mismo, un biestable master-slave tipo D, pero el
de la izquierda incorpora una se~nal de reset que pone a cero el registro. En el
de la izquierda es necesaria la deteccion de anco completa puesto que al haber
dos se~nales en la lista sensible no se sabe cual es la que provoco la ejecucion del
proceso.
Consideraciones sobre la se~nal de reloj Para que un circuito secuencial sea sinte-
tizado con exito, se deben tener en cuenta algunas directrices que ata~nen sobre
todo a la se~nal de reloj. Algunas ya se vieron en las recomendaciones iniciales,
pero no viene mal recordarlas aqu, veamos algunas:
Solo debe permitirse una deteccion de anco por cada proceso, es decir, de-
be haber un unico reloj por proceso. En realidad el problema viene de que
una misma circuitera es difcil de sintetizar si esta sincronizada mediante dos
relojes diferentes. Normalmente cada proceso en una descripcion en VHDL
corresponde con una salida o se~nal interna del sistema, si se pusieran dos relo-
jes en un mismo proceso signicara que esa se~nal viene sincronizada por dos
se~nales diferentes, lo que implica realizar logica sobre la se~nal de reloj, que
aunque es posible no es nada aconsejable. De esta manera se deja en manos
del dise~nador generar una unica se~nal de reloj que pueda ser funcion de otras
se~nales.
Cuando en un IF se comprueba el anco del reloj, no debe seguir un ELSE. Se
podra poner pero desde un punto de vista de realizacion fsica del circuito no
tendra ningun sentido.
El reloj, cuando se especica con anco, no debe ser usado como operando.
As la instruccion IF NOT (clk'EVENT AND clk='1') THEN... sera inco-
rrecta.
Como complemento a este captulo resulta muy interesante el dedicado a conceptos
avanzados donde se vera la descripcion de maquinas de estados, as como el captulo
de ejemplos donde se han incluido numerosas descripciones de funciones de la vida
cotidiana.

Captulo 10
Conceptos avanzados en VHDL
Hasta este momento, se ha intentado dar una vision general de lo que es el lenguaje
VHDL y se han dado algunas notas sobre su uso para sntesis y modelado de circuitos.
Las explicaciones vistas cubren buena parte de las posibilidades del lenguaje, pero
todava quedan muchas cosas por contar. No es que en esta seccion se vayan a cubrir el
resto de caractersticas del lenguaje, pero s que se expondran algunas cosas importantes
que quedaron por explicar. Como parte del lenguaje en s se explicara la utilizacion de
buses y funciones de resolucion, y como ejemplos de descripciones se vera la forma en
que se pueden describir maquinas de estados mediante VHDL.
10.1 Buses y resolucion de se~nales

Normalmente un bus es un conjunto de hilos que se agrupan juntos por poseer un
signicado comun, como por ejemplo un bus de datos, de direcciones, etc. Se ha visto
que estos buses podan denirse de forma sencilla mediante la denicion de matrices, o
vectores en este caso, en VHDL. Por lo tanto, no es sobre la creacion de buses sobre lo
que trata esta seccion.
Muchas veces en un bus real, y se puede dar tambien en una se~nal unica, se da la
circunstancia de que hay varios elementos conectados a la misma lnea. Pensemos por
ejemplo en el bus de datos de un ordenador. En ese bus de datos pueden escribir tanto
el procesador, como la memoria, como elementos perifericos, etc. Resulta evidente que
si varios dispositivos escriben al mismo tiempo sobre el bus, aparte de que no se sabe
que valor logico resulta, se pueden destruir, o como poco calentar mucho, los circuitos de
salida de los dispositivos que escriben sobre el bus. Cuando varios dispositivos escriben
al mismo tiempo sobre una misma se~nal, a eso se le llama contencion, o lo que es lo
mismo, que hay una lucha o contienda por el bus.
Para evitar que las contenciones, o luchas, en el bus acaben con los dispositivos que
escriben sobre el, estos escriben en el bus a traves de buers que, dependiendo del tipo
que sean (triestado, colector abierto, etc), administraran la contencion de una forma
u otra. En el caso de procesadores y memorias, se suele utilizar el buer triestado
que tiene una se~nal de habilitacion de manera que cuando esta se~nal esta activa el
buer puede escribir sobre el bus, y cuando esta inactiva tambien escribe pero lo que
se llama un valor de alta impedancia (en el tipo std logic es el valor 'Z') que tiene
una fuerza en el bus muy debil, de manera que si algun otro dispositivo escribe un '1'
81
82 Conceptos avanzados en VHDL
o un '0', este sera el valor que se tome ya que el '1' o el '0' son valores mas fuertes
que el 'Z'. La precaucion, a la hora de realizar el circuito, es cuidar de que solo haya
un dispositivo a un tiempo que escribe el valor fuerte, mientras que el resto estan en
alta impedancia. Otros buses, normalmente los dedicados al arbitraje, suelen utilizar
salidas en colector abierto de manera que varios dispositivos pueden escribir a la vez, y
no pasa nada porque uno escriba un '0' y otro un '1' al mismo tiempo ya que el cero
siempre gana. Es una forma, ademas, de realizar lo que se llama una AND cableada,
ya que simplemente conectando juntas varias se~nales en colector abierto el resultado en
el bus sera una AND logica sobre todas las se~nales que escriben en el bus.
Hasta ahora, en todos los ejemplos que se han visto, solo se asignaba un valor a una
se~nal. De hecho, es imposible en VHDL asignar dos veces una misma se~nal (de tipo no
resuelto) en dos instrucciones concurrentes. Dicho de otra manera, solo un driver puede
escribir sobre una se~nal (en el caso de poner retrasos, en una multiasignacion, son varios
driver consecutivos, pero solo hay uno que escribe sobre la se~nal). Como corolario de
este principio que acabamos de dar, se puede decir que no se puede asignar dos
veces un valor a una se~nal en procesos diferentes, y conviene recalcarlo tanto ya
que es un error muy comun a la hora de describir circuitos usando VHDL.
Para solucionar el problema de los buses en VHDL se han creado los tipos resueltos
que van a ser un tipo de se~nales que tienen asociada una funcion de resolucion que es
precisamente la que resuelve el con icto que se da cuando varios drivers escriben sobre
una misma se~nal y decide que valor asignarle.
Un tipo resuelto se dene con la declaracion de subtipo a~nadiendo el nombre de
la funcion. Para ver esto mas claro veamos una aplicacion evidente. Supongamos
que tenemos una logica con tres niveles que son el uno '1', el cero '0', y el de alta
impedancia 'Z'. Supongamos que se tienen se~nales sobre las que se pueden dar accesos
multiples a un tiempo (ej. un bus de datos). Con estas consideraciones vamos a ver
como se describira un bus de este tipo para que soportara multiples drivers en una
misma se~nal. Para empezar habra que denir estos tipos:
TYPE logico IS ('0','1','Z');
TYPE vector_logico IS ARRAY (integer range <>) OF logico;
Para continuar hay que denirse una funcion de resolucion que calcule el valor del
driver en funcion de todas las asignaciones que se estan haciendo. En nuestro ejemplo
cualquier se~nal que contenga 'Z' no interviene, y para el resto, sera cero si al menos hay
uno que es cero (wire AND logic). Con estas consideraciones, la funcion de resolucion
sera:
FUNCTION resolver(senales: IN vector_logico) RETURN logico IS
VARIABLE index: integer;
VARIABLE escribe: boolean:=FALSE;
BEGIN
FOR index IN senales'range LOOP
IF senales(index)='0' THEN RETURN '0';
END IF;
IF senales(index)='1' THEN escribe:=TRUE;
END IF;
END LOOP;
IF escribe RETURN '1';
END IF;
RETURN 'Z';
END resolver;

10.1 Buses y resolucion de se~nales 83
A continuacion se debe declarar un subtipo para que todas las se~nales que se declaren
con ese subtipo puedan ser usadas como descripcion de un bus:
SUBTYPE logico_resuelto IS resolver logico;
La forma en que se usa este nuevo tipo resuelto es exactamente igual que el no
resuelto. Es decir, la declaracion de se~nales se hace de la misma manera que siempre.
Tambien se admite, en la declaracion de la se~nal, la funcion de resolucion que se desea
utilizar, as las siguientes instrucciones son equivalentes:
SIGNAL linea: logico_resuelto;
SIGNAL linea: resolver logico;
Como un ejemplo de la utilizacion de los tipos resueltos, aplicaremos el tipo anterior

(logico resuelto) para solucionar el problema de la contencion en el bus. Supongamos
que tenemos un bus de datos compartido por una memoria y un microprocesador que
se llama datos, que el bus de datos del micro se llama micro datos y el de la memoria
mem datos y que ambos son las entradas internas a sendos buers triestado que tienen
como se~nales de habilitacion micro ena y mem ena. Por ultimo vamos a suponer que es
el procesador el que lo controla todo a partir de su se~nal de read. La parte de codigo
referida al bus quedara:
-- triestado del microprocesador:
datos<=micro_datos WHEN micro_ena='1' ELSE (OTHERS => 'Z');
-- triestado de la memoria:
datos<=memo_datos WHEN memo_ena='1' ELSE (OTHERS => 'Z');
-- Control con la senyal de read:

micro_ena<=NOT read;
memo_ena<=read;
Cuando el microprocesador lee de la memoria su buer esta deshabilitado ya que es

la memoria la que escribe por el bus. Cuando el micro escribe ocurre al reves. De esta
manera nunca hay dos se~nales que escriben valores fuertes sobre el bus, ya que siempre
una de las dos estara en alta impedancia. Las instrucciones concurrentes anteriores, que
se podan haber puesto como procesos, no seran posibles si la se~nal datos no fuera de
tipo resuelto, ya que tendramos dos instrucciones concurrentes que escriben al mismo
tiempo sobre la misma se~nal.
Como anecdota nal, aunque ya se vio en las asignaciones a matrices (captulo 4),
comentar que la clausula (OTHERS => 'Z') es una agregado o conjunto (aggregate) que
signica que se le asigna 'Z' a todos los bits que tenga la se~nal datos, si suponemos un
bus de 8 bits, la clausula anterior sera equivalente a poner "ZZZZZZZZ", con la ventaja
de que la misma descripcion sirve para cualquier tama~no de bus.
En el paquete standard de la librera std se denan los tipos bit y bit vector
como no resueltos, es decir, no tienen funcion de resolucion y por tanto no se los puede
usar en buses de datos ni se~nales donde varios procesos escriban a un tiempo. Para
evitar esto estan los tipos std logic y std logic vector que ademas de poseer un
numero mas realista de niveles logicos (ver el captulo 7), posee funciones de resolucion.
Estos tipos venan denidos en el paquete std logic 1164 de la librera ieee que
incluye ademas los tipos std ulogic y std ulogic vector que son los tipos no resueltos
equivalentes.
10.2 Descripcion de maquinas de estados
Es muy normal, a la hora de denir hardware, realizar la descripcion siguiendo la
denicion de una maquina de estados. Una maquina de estados esta denida por dos
funciones, una calcula el estado siguiente en que se encontrara el sistema, y la otra
calcula la salida. El estado siguiente se calcula, en general, en funcion de las entradas
y del estado presente. La salida se calcula como una funcion del estado presente y las
entradas.
Normalmente hay dos tipos de maquinas de estados, unas son las de Mealy y las
otras son las de Moore. Las de Mealy son mas generales y se caracterizan porque la
salida depende del estado y la entrada. Las maquinas de Moore son un caso particular
de las anteriores y se caracterizan porque la salida solo depende del estado en que se
encuentra el sistema.
En VHDL se pueden describir tanto maquinas de Mealy como de Moore y la estruc-
tura es ambas es bastante simple. Veamos a continuacion la forma general que tendra
una posible, que no la unica, descripcion de una maquina de Moore donde la salida solo
depende del estado del sistema. Para ello supondremos que entrada y salida son las
entradas y salidas, y que (est1,est2,...,estK) son los estados del sistema. Con esto, la
descripcion sera:
ENTITY maquina IS
PORT (entrada: IN tipoin; salida: OUT tipout);
END maquina;
ARCHITECTURE moore OF maquina IS

TYPE estado IS (est1,est2,...,estN);
SIGNAL presente: estado:=est1; -- especificar un estado inicial
SIGNAL siguiente: estado; -- en realidad basta con una se'nal
BEGIN
PROCESS(entrada,presente)
BEGIN
CASE presente IS
WHEN est1=>
salida<=valor1;
siguiente<=f1(entrada);
WHEN est2=>
salida<=valor2;
siguiente<=f2(entrada);
.
.
WHEN estN=>
salida<=valorN;
siguiente<=fN(entrada);
END CASE;
END PROCESS;
presente<=siguiente;
END moore;
En este caso los valores valor1, valor2, etc. son valores concretos que se le asignan
a la salida. Las funciones f1, f2, etc. son en realidad expresiones que dependen de
la entrada, y no signica que existan como tales funciones, simplemente signica una
expresion en la que pueden intervenir las entradas.
Para llevar el estado del sistema se han denido dos se~nales, por un lado presente
para indicar el estado actual, y por otro la se~nal siguiente para indicar el estado
siguiente. En realidad basta una sola se~nal para indicar el estado, lo cual es bastante
sencillo de entender puesto que cuando se sintetice solo va a existir un latch o registro
10.2 Descripcion de maquinas de estados 85
que indique el estado, y no dos como aparentemente aparece en la descripcion. Si se
ha a~nadido la se~nal siguiente es por claridad, pero es evidente que es la misma cosa
que presente debido a la instruccion concurrente presente<=siguiente. De ahora en
adelante se utilizara la se~nal de presente para indicar tanto el siguiente como el actual.
La maquina descrita anteriormente es un ejemplo tpico de descripcion de sistema
secuencia. Sin embargo en la practica tiene un problema. Para empezar, a pesar de
ser un circuito secuencial, sera implementado con puertas logicas o cerrojos activos
por nivel, lo cual puede presentar problemas de metaestabilidad. En efecto, aqu las
transiciones entre estados vienen provocadas por los cambios en las entradas y por lo
cambios en los estados. Si el cambio de estado no ocurre de forma instantanea en todos
los bits que lo denan (lo cual no es difcil) o se producen picos o transiciones en las
entradas (que tampoco es raro) el sistema puede acabar en un estado que no es el que
le toca.
Por esta razon, las maquinas de estados en circuitos reales, suelen venir sincronizadas
por una se~nal de reloj, de manera que la transicion entre estados se da en uno de los
ancos de la se~nal de reloj. Si le ponemos una se~nal de reloj, que llamaremos clk, a la
maquina anterior, la descripcion quedara:
ENTITY maquina IS
PORT (entrada: IN tipoin; clk: IN bit; salida: OUT tipout);
END maquina;
ARCHITECTURE moore_sincrono OF maquina IS

SIGNAL presente: estado:=est1; -- el inicial
BEGIN
estados:
PROCESS(clk)
BEGIN
IF clk='1' THEN
CASE presente IS
WHEN est1=>
presente<=f1(entrada);
WHEN est2=>
.
.
WHEN estN=>
presente<=fN(entrada);
END CASE;
END IF;
END PROCESS estados;
salida:
PROCESS(presente)
BEGIN
CASE presente IS
WHEN est1=>
salida<=valor1;
WHEN est2=>
salida<=valor2;
.
.
WHEN estN=>
salida<=valorN;
END CASE;
END IF;
END PROCESS salida;
END moore_sincrono;

Hemos visto que se ha separado la parte secuencial (proceso estados) de la combi-
nacional (proceso salida). Esto es especialmente util cuando se trabaja con maquinas
de estados sncronas. La parte secuencial se encarga de calcular el estado siguiente, y
la parte combinatorial pura calcula la salida en funcion del estado y la entrada. Cada
una de estas partes se puede describir mediante dos procesos separados. Normalmente,
ademas, las maquinas de estados suelen necesitar una se~nal de reset que lleve a la
maquina a un estado conocido de partida.
Veamos a continuacion como sera la estructura de una maquina generica que incor-
pora reset, reloj, y es de tipo Mealy (la salida depende tambien de la entrada):
ENTITY maquina IS
PORT (entrada: IN tipoin; clk,reset: IN bit; salida: OUT tipout);
END maquina;
ARCHITECTURE mealy OF maquina IS

SIGNAL presente: estado:=est1; -- el inicial
BEGIN
--Bloque secuencial:
estados:
PROCESS(clk,reset) -- reset asincrono
BEGIN
IF reset='1' THEN
presente<=est1; -- estado inicial
ELSIF clk='1' AND clk'EVENT THEN
CASE presente IS
WHEN est1=>
WHEN est2=>
.
.
WHEN estN=>
presente<=fN(entrada);
END CASE;
END IF;
END PROCESS estados;
-- Bloque combinacional:
salida:
PROCESS(entrada,presente)
CASE presente IS
WHEN est1=>
salida<=g1(entrada);
WHEN est2=>
salida<=g2(entrada);
.
.
WHEN estN=>
salida<=gN(entrada);
END CASE;
END PROCESS salida;
END mealy;
En la descripcion anterior el proceso salida no depende del reset puesto que -

jando un estado cuando esta activa la se~nal de reset, jamos tambien la salida. En el
caso de necesitar una salida especial para cuando el reset esta activo se especicara
en este proceso, pero esto en general no es necesario ya que se suele elegir el estado
correspondiente al reset para que su salida sea la que se desea.
10.2 Descripcion de maquinas de estados 87
El reset anterior era asncrono por encontrarse dentro de la lista sensible. Si se desea
un reset sncrono, hay que quitarlo de la lista sensible e incorporarlo a la maquina como
si fuera una entrada mas.


Captulo 11
Utilizacion del lenguaje VHDL
En esta seccion se muestran unos cuantos ejemplos de utilizacion del VHDL para
simulacion y sntesis. Cuando se explica un lenguaje de programacion, y con los de
descripcion de circuitos pasa igual, resulta difcil explicar como resolver un problema
mediante el lenguaje. Parece que la mejor forma sigue siendo dar unos cuantos ejemplos
de como resolver determinados problemas y a partir de ah poder coger conanza y
soltura con el lenguaje.
11.1 Errores mas comunes usando VHDL

Antes de empezar con los ejemplos resulta interesante dar algunas recomendaciones,
aparte de las que se han dado ya, para as evitar el tropezar varias veces en el mismo
problema o error de dise~no. A continuacion se recogen una serie de errores que se suelen
cometer al empezar a programar o describir circuitos con VHDL.
El error mas comun es probablemente la asignacion de una misma variable en pro-
cesos diferentes, o lo que es lo mismo, asignacion de una misma se~nal en ins-
trucciones concurrentes diferentes. Este error viene de que a veces se divide el
problema atendiendo a las entradas en vez de a las salidas, con lo que se pone un
proceso para cada entrada o grupo de entradas, con lo que las salidas, que depen-
deran en general de varias entradas, aparecen en varios procesos al mismo tiempo.
La solucion consiste en dividir el problema por las salidas y no por las entradas,
de manera que en cada proceso se integre toda la logica referida a una salida o a
un grupo de salidas relacionadas. Naturalmente, utilizar tipos resueltos no es una
solucion ya que el problema, que hasta ahora era unicamente de compilacion se con-
vierte en un problema de dise~no mucho mas difcil de depurar. El tipo resuelto debe
utilizarse unicamente en buses donde se conectan varios dispositivos.
Otra causa de este problema se da en lo contadores. Normalmente tenemos un
proceso que se encarga de incrementar el contador, y en otro proceso, normalmente
el de la maquina de estados, queremos ponerlo a cero en determinados estados. En
este caso no se puede poner a cero en el otro proceso, sino que hay que utilizar
una se~nal auxiliar para poder comunicar ambos procesos entre s, de manera que si
un proceso quiere poner a cero el contador lo que tiene que hacer es activar esta
se~nal para que el proceso que tiene el contador se de por enterado y ponga a cero la
cuenta.
89
90 Utilizacion del lenguaje VHDL
Otro error bastante comun es pensar que las se~nales se comportan como variables
dentro de los procesos. As, si tenemos un contador por ejemplo, en un proceso, y
poco despues de incrementarlo, comparamos a ver si ha llegado a cierto valor en el
mismo proceso, probablemente no funcionara bien puesto que la se~nal no habra sido
actualizada. Colocando la se~nal de contador en la lista sensible probablemente
solucionara el problema en algunos casos, pero lo normal es que la funcionalidad
del proceso cambiara, especialmente si viene sincronizado por una se~nal de reloj que
es el caso mas comun.
En el caso de estar describiendo botones y cosas as, es decir, pulsos de entrada con
duracion impredecible, a veces se olvida que el boton se mantiene pulsado durante
algun tiempo que normalmente es mucho mayor que la frecuencia del reloj y por
supuesto muchsimo mayor que los tiempos de respuesta de los circuitos. Esto
signica que cuando un boton produce un cambio de estado, sigue estando pulsado en
ese estado nuevo que entra y que por lo tanto se debe tener en cuenta, bien a~nadiendo
estados auxiliares o bien, y esto funcionara bien en cualquier caso, deniendo una
se~nal que se activara al activarse el boton y que se desactivara al entrar en el estado
siguiente. Sincronizar con un reloj tambien ayuda a solucionar el problema.
Del mismo estilo del anterior es el problema que surge cuando se pulsa un boton
y se suelta enseguida. Hay maquinas que si se describen mal estan suponiendo
que el boton esta continuamente pulsado, y esto no tiene por que ser as, sera el
caso contrario al anterior. En estas situaciones, lo que hay que hacer es capturar
la pulsacion de un boton a traves de un registro, y volverlo a desactivar cuando se
llegue a un estado inicial.
Ya menos frecuentemente a veces ocurre que se nos olvidan cosas por asignar. En
el caso de las maquinas de estados es importante que al menos el estado inicial o de
reset contenga todas las se~nales de salida con unos valores jos.
Solo muy al principio, cuando no se tiene muy clara la diferencia entre el entorno
concurrente y el serie, se suele considerar que en el entorno concurrente las instruc-
ciones tambien se ejecutan una detras de otra, y no es raro ver como se \inicializan"
unas se~nales a cero y luego se les da otro valor, etc.
A veces crea confusion la diferencia entre variable y se~nal hasta el punto que se
declaran variable o se~nales en lugares que no les corresponden. Como norma general,
que sirve para 99% de los casos y que casi conviene para no armarse mucho lo sobre
todo al principio, podemos decir que las se~nales solo se pueden declarar en la parte
declarativa de la arquitectura, y que las variables solo se pueden declarar en las
partes declarativas de procesos, funciones y procedimientos. Las se~nales tambien se
pueden declarar en los bloques concurrentes, pero como esta estructura se usa poco
al principio casi conviene no saberlo hasta que de verdad se empiezan a usar.
Como corolario de lo anterior tambien se da el problema de usar variables en entornos
concurrentes, lo cual no es posible ya que ni siquiera se pueden declarar ah.
De los errores mas comunes, lo que realmente se dan con frecuencia y son mas faciles
de cometer son los dos primeros. Veamos a continuacion como resolver algunos de los
problemas de dise~no que se pueden plantear en VHDL.

11.2 Ejemplos para simulacion y sntesis 91
11.2 Ejemplos para simulacion y sntesis
El estilo de realizacion de modelos (simulacion) es bastante diferente del estilo empleado
para la sntesis de circuitos. Para empezar, en el modelado no hay restricciones de
ningun tipo y ademas los modelos suelen incluir informacion referente a los retrasos.
Aqu veremos algunos ejemplos en los cuales son modelos puesto que incluyen retrasos,
y otros, que por la forma de estar descritos no son sintetizados correctamente. Veremos
las diferencias, cuando las haya entre lo que se sintetiza y lo que se simulara, y veremos
que muchas veces no coincide.
11.2.1 El boton
Ejemplo 11.1 Un motor electrico viene controlado por un unico boton. Cuando se
pulsa el motor cambia de encendido a apagado. Sintetizar el circuito que controla el
motor mediante una maquina de estados en VHDL.
La solucion a este problema es bastante simple tal y como ya se mostro en el ejemplo
6.3 donde con un simple biestable se solucionaba el problema. Desde un punto de vista
algo mas abstracto se puede pensar en una maquina de estados con dos estados, de
manera que se pasa de uno a otro cada vez que se pulsa el boton. Esto en principio
se puede hacer, pero tiene un problema y es que cuando se pasa de un estado a otro
el boton sigue pulsado, por lo que en realidad se produce una transicion muy rapida
entre estados; solo cuando se suelte el boton se parara, pero es imposible predecir si se
parara en el estado encendido o en el apagado. Para evitar esto lo normal es pensar
en dos estados mas que detengan esta transicion rapida entre estados. La salida solo
dependera del estado del sistema por tanto no es mas que una maquina de Moore:
ENTITY conmutador IS
PORT (boton: IN bit; motor: OUT bit);
END conmutador;
ARCHITECTURE moore OF conmutador IS

TYPE estado IS (apagado1,apagado2,encendido1,encendido2);
SIGNAL presente: estado:=apagado1;
BEGIN
PROCESS(boton,presente)
BEGIN
CASE presente IS
WHEN apagado1 =>
motor<='0';
IF boton='1' THEN presente<=encendido2;
END IF;
WHEN encendido2 =>
motor<='1';
IF boton='0' THEN presente<=encendido1;
END IF;
WHEN encendido1 =>
motor<='1';
IF boton='1' THEN presente<=apagado2;
END IF;
WHEN apagado2 =>
motor<='0';
IF boton='0' THEN presente<=apagado1;
END IF;
END CASE;
END PROCESS;
END moore;

Se puede hacer algo con menos estados tal y como se muestra a continuacion, pero
no es cierto que hayan menos estados, aparentemente hay menos porque el sintetizador
del circuito introducira latches extra. Ademas, la descripcion que sigue, aunque pudiera
parecer que tiene la estructura de una maquina de estados, no lo es exactamente porque
en la lista sensible no se ha introducido la se~nal que contiene el estado, y esto signi-
cara que se realiza logica secuencial que no aparece explcitamente en la descripcion.
En realidad el truco esta en que la maquina anterior se realizara con biestables activos
por nivel, mientras que la viene a continuacion, como no tiene presente en la lista sen-
sible se activara por anco por lo que se utilizara un unico biestable maestro-esclavo,
pero para obtener un biestable maestro-esclavo hacen falta precisamente dos biestables
activos por nivel:
ARCHITECTURE pseudomaquina OF conmutador IS
TYPE estado IS (apagado,encendido);
SIGNAL presente: estado:=apagado;
BEGIN
PROCESS(boton)
BEGIN
CASE presente IS
WHEN apagado =>
motor<='0';
IF boton='1' THEN
presente<=encendido;
motor<='1'; -- Esto es salida futura, por tanto, opuesta.
END IF;
WHEN encendido =>
motor<='1';
IF boton='1' THEN
presente<=apagado;
motor<='0'; -- Lo mismo, salida futura.
END IF;
END CASE;
END PROCESS;
END pseudomaquina;
Este segundo caso no se sintetizara bien puesto que a las herramientas de dise~no hay
que especicarles que cosas son activas por anco de forma explcita, generalmente con el
atributo 'EVENT. Si se metiera esta descripcion en un sintetizador, y luego simularamos
lo sintetizado, descubriramos que efectivamente tiene dos estados pero al pulsar el
boton cambia entre estados de forma rapida tal y como se predijo al principio. En
cambio, si se simula la descripcion tal y como esta, funcionara bien. Aparte de todo
esto, el ejemplo anterior no es precisamente un buen modelo de maquina de estados ya
que la se~nal de sincronizacion, en este caso el boton, se encuentra en cada uno de los
estados, y por otro lado hay algo que no se debera hacer nunca y es cambiar la salida
al tiempo que cambia el estado para que as el estado siguiente tenga la salida que se
le ha especicado; en general, cada estado debera tener especicadas sus salidas. Para
que un sintetizador hubiera interpretado la descripcion anterior como lo que realmente
pone, habra que haberlo hecho as:
ARCHITECTURE para_sintesis OF conmutador IS
TYPE estado IS (apagado,encendido);
SIGNAL presente: estado:=apagado;
BEGIN
PROCESS(boton)
BEGIN
IF boton='1' -- o boton='1' AND boton'EVENT
CASE presente IS
WHEN apagado =>

motor<='0';
presente<=encendido;
END IF;
WHEN encendido =>
motor<='1';
presente<=apagado;
END CASE;
END IF;
END PROCESS;
END para_sintesis;
Si repasamos la descripcion anterior y la intentamos simular a mano con todo lo que

sabemos, veremos que cuando el estado es apagado motor el vale uno, y viceversa, es
decir, lo contrario de lo que parece. Si esto nos causa mucha confusion, podemos dividir
el problema en dos procesos, uno que interpreta el estado y otro el cambio de estado:
maquina: salida:
PROCESS(boton) PROCESS(presente)
BEGIN BEGIN
IF boton='1' THEN CASE presente IS
CASE presente IS WHEN apagado=>
WHEN apagado=> motor<='0';
presente<=encendido; WHEN encendido=>
WHEN encendido=> motor<='1';
presente<=apagado; END CASE;
END CASE; END PROCESS salida;
END IF;
END PROCESS maquina;
Esta descripcion es mas interesante ya que en este caso esta mas claro lo que quere-
mos decir y tanto la simulacion como la sntesis coinciden. Quiza alguien podra pensar
que una posible solucion sera poner presente en la lista sensible, pero esto, aunque la
simulacion estara bien, sintetizara otro circuito diferente. O sea, que es aconsejable
seguir un unico modelo para la maquina de estados, que funcione bien para sntesis, y
no salirse de ah.
11.2.2 Los semaforos

Ejemplo 11.2 Realizar el circuito de control de unos semaforos que controlan un cruce
entre un camino rural y una carretera. En principio, el semaforo del camino rural
siempre esta en rojo y el de la carretera en verde. Una celula en el camino rural
detecta la presencia de un coche, momento en el cual el semaforo de la carretera pasa
de verde a rojo pasando por el ambar, al tiempo que el semaforo del camino se pone en
verde. El semaforo del camino permanece en verde unos 10 segundos, momento en el
cual empieza la secuencia de puesta a rojo, al tiempo que el semaforo de la carretera
empieza la secuencia de cambio hacia el verde. El semaforo del camino no debe ponerse
en verde otra vez hasta transcurridos 30 segundos por lo menos. El circuito tiene una
entrada de reloj de 1 segundo de periodo y las se~nales de entrada y salida sucientes
para el control del semaforo.
Como se da una se~nal de reloj como entrada, es interesante realizar la maquina de

estados de manera que sea sncrona con este reloj, de esta manera se evitan proble-
mas de metaestabilidad con las entradas, ademas de que las herramientas de sntesis
interpretaran mejor que el circuito es una maquina de estados y el resultado sera mas
optimo. Junto con la maquina de estados habra otros procesos que controlen los tiempos
de espera mediante contadores.
La entrada al sistema sera una se~nal de reset asncrona, que es lo habitual, y las
fotocelulas del camino, que indicaran un '1' cuando detecten un coche. Las salidas
seran un total de 6, 3 para cada semaforo, indicando cada una de estas tres el color
rojo, ambar y verde. Con estas consideraciones la entidad y arquitectura quedaran:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
ENTITY semaforo IS
PORT (sensor,reset,clk: IN std_logic;
semcamin,semcarr: OUT std_logic_vector(0 TO 2));
END semaforo;
ARCHITECTURE descripcion OF semaforo IS

TYPE estado IS (inicial,carramarillo,caminverde,caminamarillo,espera);
CONSTANT verde: std_logic_vector(0 TO 2):="001";
CONSTANT amarillo: std_logic_vector(0 TO 2):="010";
CONSTANT rojo: std_logic_vector(0 TO 2):="100";
SIGNAL presente: estado:=inicial;
SIGNAL rescont: boolean:=false; -- Pone a cero la cuenta
SIGNAL fin_largo,fin_corto: boolean; -- Indica fin de cuenta
SIGNAL cuenta: integer RANGE 0 TO 63;
BEGIN
-- Lo primero es definirse la maquina de estados:

maquina:
PROCESS(clk,reset)
BEGIN
IF reset='1' THEN
presente<=inicial;
CASE presente IS
WHEN inicial=>
IF sensor='1' THEN
presente<=carramarillo;
END IF;
WHEN carramarillo=>
presente<=caminverde;
WHEN caminverde=>
IF fin_corto THEN
presente<=caminamarillo;
END IF;
WHEN caminamarillo=>
presente<=espera;
WHEN espera=>
IF fin_largo THEN
presente<=inicial;
END IF;
END CASE;
END IF;
salida:
PROCESS(presente)
BEGIN
CASE presente IS
WHEN inicial=>
semcarr<=verde;
semcamin<=rojo;
rescont<=true;
WHEN carramarillo=>
semcarr<=amarillo;
semcamin<=rojo;

rescont<=true;
WHEN caminverde=>
semcarr<=rojo;
semcamin<=verde;
rescont<=false;
WHEN caminamarillo=>
semcarr<=rojo;
semcamin<=amarillo;
rescont<=true;
WHEN espera=>
semcarr<=verde;
semcamin<=rojo;
rescont<=false;
END CASE;
END PROCESS salida;
-- El siguiente proceso define el contador:

contador:
PROCESS(clk)
BEGIN
IF clk='1' THEN
IF rescont THEN cuenta<=0;
ELSE cuenta<=cuenta+1;
END IF;
END IF;
END PROCESS contador;
-- Queda la deteccion de los tiempos largos y cortos:

fin_largo<=true WHEN cuenta=29 ELSE false;
fin_corto<=true WHEN cuenta=9 ELSE false;
END descripcion;
11.2.3 El ascensor
Ejemplo 11.3 Describir el controlador de un ascensor unico en una vivienda de 4
pisos. Las entradas al circuito seran, por un lado, el piso al que el usuario desea
ir mediante 4 botones, y el piso en el que se encuentra el ascensor en un momento
dado. Por otro, habra una celula que detecte la presencia de algun obstaculo en la
puerta, si hay un obstaculo la puerta no debe cerrarse. La salida sera por un lado el
motor (mediante dos bits), y la puerta (un bit). El funcionamiento es bien simple: el
ascensor debe ir al piso indicado por los botones, cuando llegue abrira las puertas que
permaneceran as hasta que se reciba otra llamada. El ascensor no tiene memoria por
lo que si se pulsan los botones mientras el ascensor se mueve, no hara caso.
ENTITY ascensor IS
PORT(boton: IN bit_vector(0 TO 3);
piso: IN bit_vector(1 DOWNTO 0);
clk,reset,celula: IN bit;
motor: OUT bit_vector(0 TO 1);
puerta: OUT bit);
END ascensor;
ARCHITECTURE mover OF ascensor IS

TYPE estado IS (inicial,cerrar,voy);
SUBTYPE vector IS bit_vector(2 DOWNTO 0);
SIGNAL bot: bit_vector(2 DOWNTO 0);
FUNCTION codifica(pulso: bit_vector(0 TO 3)) RETURN vector IS

BEGIN
CASE pulso IS

WHEN "0001"=>RETURN "000";
WHEN "0010"=>RETURN "001";
WHEN "0100"=>RETURN "010";
WHEN "1000"=>RETURN "011";
WHEN OTHERS=>RETURN "100";
END CASE;
END codifica;
BEGIN
fsm:
PROCESS(reset,clk)
BEGIN
IF reset='1' THEN presente<=inicial;
CASE presente IS
WHEN inicial=>
IF bot/="100" THEN presente<=cerrar;
END IF;
WHEN cerrar=>
IF celula='0' THEN presente<=voy; -- Sin obtaculos
END IF;
WHEN voy=>
IF bot(1 DOWNTO 0)=piso THEN presente<=inicial;
END IF;
END CASE;
END IF;
END PROCESS fsm;
salida:
PROCESS(presente,boton)
BEGIN
CASE presente IS
WHEN inicial=>
motor<="00"; -- Parado
puerta<='1'; -- Abierta
bot<=codifica(boton);
WHEN cerrar=>
motor<="00";
puerta<='1';
WHEN voy=>
puerta<='0'; -- Cerrada
IF bot(2 DOWNTO 0)>piso THEN
motor<="10"; -- Subir
ELSE motor<="01"; -- Bajar
END IF;
END CASE;
END PROCESS salida;
END mover;
El funcionamiento no es muy complejo. Si nadie pulsa nada se mantiene en el estado

inicial, si alguien pulsa entonces se cierran las puertas y el motor se pone en marcha en
direccion al piso que se llamo. Cuando llega se abren las puertas y se queda a esperar
una nueva llamada.
La funcion codifica se ha puesto para mostrar la inclusion de una funcion en una
descripcion. Realmente el programa funciona exactamente igual de bien, con peque~nas
modicaciones, si se utiliza bot como una se~nal de 4 bits. Esta se~nal sigue siendo
necesaria puesto que se encarga de capturar la pulsacion del boton.
El ejemplo del ascensor que se acaba de mostrar no es demasiado realista, por un
lado las puertas se cierran de golpe, y por otro, la parada y puesta en marcha del
ascensor es tambien muy brusca. De todas formas pone de maniesto la capacidad de
funcionamiento del VHDL para la descripcion de hardware. Como ejercicio adicional se
puede hacer el ejemplo anterior pero a~nadiendole caractersticas mas realistas como la
deteccion de obstaculos durante el cierre de puertas, o la posibilidad de gestionar mas
de un boton pulsado.
11.2.4 La memoria ROM

Ejemplo 11.4 Realizar el modelo de simulacion de una memoria ROM simple. La
ROM tiene una entrada de seleccion activa a nivel bajo, de manera que cuando esta ac-
tiva, la salida es el contenido de la posicion indicada por la direccion de entrada, sino
esta activa, la salida es alta impedancia. El tiempo que pasa entre que cambia la selec-
cion y la salida es de 60 ns. El tiempo que pasa entre que la direccion cambia y cambia
la salida es de 100 ns. En el caso de cambio en la direccion, la salida mantiene su valor
anterior durante 10 ns y luego pasa a desconocido.
LIBRARY ieee;
ENTITY rom IS
PORT( cen: IN std_logic;
direcc: IN std_logic_vector(1 DOWNTO 0);
dato: OUT std_logic_vector(7 DOWNTO 0));
END rom;
ARCHITECTURE modelo OF rom IS

SIGNAL salida: std_logic_vector(7 DOWNTO 0);
SIGNAL cenr: std_logic:
BEGIN
PROCESS(direcc)
BEGIN
salida<="XXXXXXXX" AFTER 10 ns;
CASE direcc IS
WHEN "00"=>salida<=TRANSPORT "00000000" AFTER 100 ns;
WHEN OTHERS=> NULL;
END CASE;
END PROCESS;
dato<=salida WHEN cenr='0' ELSE

(OTHERS 'Z') WHEN cenr='1' ELSE
(OTHERS 'X');
cenr<=cen AFTER 60 ns;
END modelo;
El modelo no requiere demasiadas explicaciones. Quiza sea interesante resaltar

que para el caso del retraso de 100 ns de la salida se ha empleado el retraso de tipo
transportado en vez del inercial, la razon es que este evento se asigna al mismo tiempo
que de 10 ns, de manera que si no fuese transportado quitara el otro evento de la lista
de eventos y no se ejecutara nunca.
11.2.5 El microprocesador
Ejemplo 11.5 Realizar un microprocesador sencillo. El procesador tiene un bus de
datos bidireccional de 8 bits. Un bus de direcciones de salida de 8 bits. Una se~nal de
lectura escritura (a uno indica lectura y a cero escritura). Una se~nal de reloj y una
de reset. Internamente debe haber un acumulador de 8 bits, el registro de instruccion
de 3 bits, y el programa counter de 8 bits. El micro cuenta con 8 instrucciones. Las
instrucciones estan formadas por dos bytes, en el primero se pone el codigo, y en el
segundo el operando, salvo en la ultima que solo tiene un byte. A continuacion se
muestran las instrucciones junto con su codicacion:
ld a,(xx) Carga el acumulador con lo que haya en la posicion de memoria indicada
por el operando. (000)
ld (xx),a Carga en la posicion xx el contenido del acumulador. (001)
and a,(xx) Realiza la operacion and entre el acumulador y lo que haya en la posicion
xx. El resultado se guarda en el acumulador. (010)
add a,(xx) Lo mismo que la anterior pero la operacion es la suma. (011)
sub a,(xx) Al acumulador se le resta lo que haya en la posicion xx. El resultado se
guarda en el acumulador. (100)
jz xx Salta a la posicion xx si el acumulador es cero. (101)
jmp xx Salta a la posicion xx. (110)
nop No hace nada. (111)
Realizar un procesador es relativamente sencillo en VHDL. Ademas tienen todos una
estructura parecida por lo que resulta facil a~nadir instrucciones y hacer el procesador lo
complicado que se desee. En el caso simple del procesador propuesto, se puede abordar
el problema con una simple maquina de estados, en la cual hay un estado inicial de
reset al que le sigue el de busqueda de instruccion. Dependiendo de la instruccion se
lee el siguiente operando y se actua en consecuencia.
Uno de los paquetes de la librera ieee es el std arith que sobrecarga los operadores
aritmeticos para que se pueda, por ejemplo, sumar un entero a un std logic vector.
Veamos la descripcion:
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_arith.all;
ENTITY procesador IS
PORT(clk,rst: IN std_logic;
r_w: OUT std_logic;
dir: OUT std_logic_vector(7 DOWNTO 0);
dat: INOUT std_logic_vector(7 DOWNTO 0));
END procesador;
ARCHITECTURE descripcion OF procesador IS

TYPE estado IS (inicial,busqueda,ejec,ldxxa,ldaxx,anda,adda,suba);
SIGNAL a,pc,ir: std_logic_vector(7 DOWNTO 0);
SIGNAL rdat_in,dat_in,dat_out: std_logic_vector(7 DOWNTO 0);
SIGNAL rwaux,seldir: std_logic;
BEGIN
fsm:
PROCESS(clk)
BEGIN

IF clk='1' THEN
CASE presente IS
WHEN inicial =>
seldir<='1'; -- dir<=pc
pc<=(OTHERS=>'0');
rwaux<='1';
ir<=(OTHERS=>'0');
a<=(OTHERS=>'0');
presente<=busqueda;
WHEN busqueda=>
ir<=dat_in;
pc<=pc+1;
IF dat_in(2 DOWNTO 0)="111" THEN presente<=busqueda;
ELSE presente<=ejec;
END IF;
WHEN ejec =>
seldir<='0'; -- dir<=dat_in
pc<=pc+1;
presente<=busqueda;
CASE ir(2 DOWNTO 0) IS
WHEN "000" =>
presente<=ldaxx;
WHEN "001" =>
dat_out<=a;
rwaux<='0'; -- Escribir
presente<=ldxxa;
WHEN "010" =>
presente<=anda;
WHEN "011" =>
presente<=adda;
WHEN "100" =>
presente<=suba;
WHEN "101" =>
seldir<='1';
IF a=0 THEN
pc<=dat_in;
END IF;
WHEN "110" =>
seldir<='1';
pc<=dat_in;
WHEN OTHERS => NULL;
END CASE;
WHEN ldaxx =>
a<=dat_in;
seldir<='1';
presente<=busqueda;
WHEN ldxxa =>
rwaux<='1';
seldir<='1';
presente<=busqueda;
WHEN anda =>
a<=a AND dat_in;
seldir<='1';
presente<=busqueda;
WHEN adda =>
a<=a+dat_in;
seldir<='1';
presente<=busqueda;
WHEN suba =>
a<=a-dat_in;
seldir<='1';
presente<=busqueda;
END CASE;
IF rst='1' THEN presente<=inicial;
END IF;
END IF;
END PROCESS fsm;

latch_in: -- Registro en la entrada del bus de datos
PROCESS(clk)
BEGIN
IF clk='1' THEN rdat_in<=dat_in;
END IF;
END PROCESS latch_in;
dir<=pc WHEN seldir='1' ELSE rdat_in; -- Multiplexor de las direcciones

r_w<=rwaux;
dat<=dat_out WHEN rwaux='0' ELSE (OTHERS=>'Z'); -- Buffer de Salida
dat_in<=dat;
END descripcion;
11.2.6 La lavadora
Ejemplo 11.6 Se pretende sintetizar el chip que controla una lavadora domestica cti-
cia. La lavadora, junto con las entradas y salidas del chip que la controla, se muestran
en la gura 11.1. El funcionamiento se explica a continuacion junto con las entradas y
salidas:
Entradas:
color: Al pulsarse esta tecla se cambia un estado interno de la maquina que indica si
el ciclo de lavado es de ropa de color o no. Inicialmente se supone que no es de
color (estado a cero).
centrifuga: Cada vez que se pulsa cambia un estado interno que indica si se debe
centrifugar o no. Inicialmente se supone que no (estado a cero).
start: Cuando se pulsa se inicia el lavado, una vez en marcha este boton no hace nada.
jabon listo: Indica que el jabon ya se ha introducido en el lavado.
vacio: Indica que el tambor esta vaco de agua.
lleno: Indica que el tambor ya esta lleno de agua.
clk: Reloj para sincronizar de frecuencia 100 Hz.
Salidas:
jabon: Al ponerla a uno coge el jabon del cajetn y lo mete en el tambor en el ciclo de
lavado.
llenar: A uno abre las valvulas del agua para llenar el tambor, se debe monitorizar la
se~nal lleno para saber cuando ponerla a cero para que no entre mas agua.
vaciar: A uno abre las valvulas de salida del agua para desaguar el tambor. La se~nal
de entrada vacio indicara el momento en que no hay mas agua en el tambor.
lento: Un uno en esta se~nal hace que el motor gire, en la direccion indicada por la
se~nal direccion, con un ritmo lento. Esta velocidad se usa en todos los ciclos
menos en el centrifugado.
rapido: Lo mismo que lento pero la velocidad es la de centrifugado, o sea, mas rapida.
Si las se~nales anteriores estan las dos a cero entonces el motor esta parado, si
estan a uno las dos entonces se quema la maquina de lavar.
direccion: a uno indica que el tambor se movera a izquierdas y a cero a derechas. El
tambor debe moverse alternativamente a derecha e izquierda en todos los ciclos
menos en el de centrifugado que se mueve siempre en la misma direccion.
Ciclos de lavado:
Inicial: es el estado inicial de la maquina y esta esperando a que se pulse start.
Lavado: en este ciclo se coge el jabon, se llena de agua el tambor y se pone en marcha
el motor alternativamente a izquierda y derecha. La duracion es de 10 minutos si
la ropa es de color y 20 minutos si la ropa es blanca o resistente. Cuando acaba
se vaca el agua del tambor.
Aclarado: Se llena el tambor de agua otra vez pero sin jabon. El tambor tambien se
mueve. Dura 5 minutos y hay que vaciar el agua al acabar.
Centrifugado: Si la opcion de centrifugado esta seleccionada entonces entrara en este
ciclo, sino volvera al inicial. Este ciclo consiste en mover el tambor a velocidad
rapida en un unico sentido de giro durante 10 minutos. Al acabar se vuelve al
estado inicial.
color jabon
centrifuga
start llenar
vaciar
jabon_listo
vacio lento
lleno rapido
direccion
clk
Figura 11.1: Figura del ejercicio de la lavadora
Si se pretende sintetizar el circuito es siempre preferible sincronizar la maquina de

estados con la se~nal de reloj. Se van a presentar dos posibles descripciones para la
maquina de estados, y se podran de maniesto las diferencias que se pueden dar a la
hora de sintetizar segun el tipo de maquina de estados que se realice. Hay que destacar
que tanto la simulacion de una como de otra coinciden.
En la primera descripcion ponemos las salidas en el mismo proceso donde colocamos
la transicion de estados. Lo que producira esto es que la salida cambiara un ciclo de
reloj despues de que cambie el estado, pero esto da igual ya que la frecuencia de reloj
es muy alta.
LIBRARY ieee;
ENTITY lavadora IS
PORT (color,centrifuga,start,jabon_listo,vacio,lleno,clk: IN std_logic;
jabon,llenar,vaciar,rapido,lento,direccion: OUT std_logic);
END lavadora;
ARCHITECTURE sincrona OF lavadora IS

CONSTANT diezsec: integer:=1000; -- Estos tiempos han sido
CONSTANT cincomin: integer:=30000; -- calculados suponiendo una frecuencia
CONSTANT diezmin: integer:=60000; -- de reloj de 100 Hz.
CONSTANT veintemin: integer:=120000;
TYPE estados IS (inicial,lavado,vacia1,aclarado,vacia2,centrifugado);
SIGNAL presente: estados:=inicial;
SIGNAL coloraux,centriaux,diraux: std_logic:='0';

SIGNAL tiempo: integer RANGE 0 TO 16#1FFFF# :=0;
SIGNAL subtiempo: integer RANGE 0 TO 1023 :=0;
BEGIN
maquina:
PROCESS(clk)
BEGIN
IF clk='1' THEN
CASE presente IS
WHEN inicial=>
IF start='1' THEN presente<=lavado; END IF;
jabon<='0'; llenar<='0'; vaciar<='1';
lento<='0'; rapido<='0'; diraux<='0';
tiempo<=0;
subtiempo<=0;
WHEN lavado=>
vaciar<='0';
IF jabon_listo='0' THEN jabon<='1';
ELSE jabon<='0';
END IF;
IF lleno='0' THEN
llenar<='1';
ELSE
llenar<='0';
lento<='1';
IF subtiempo=diezsec THEN
diraux<=NOT diraux;
subtiempo<=0;
ELSE
subtiempo<=subtiempo+1;
END IF;
tiempo<=tiempo+1;
IF coloraux='1' AND tiempo=diezmin THEN presente<=vacia1;
ELSIF tiempo=veintemin THEN presente<=vacia1;
END IF;
END IF;
WHEN vacia1=>
vaciar<='1';
lento<='0';
IF vacio='1' THEN presente<=aclarado;
END IF;
subtiempo<=0;
tiempo<=0;
WHEN aclarado=>
vaciar<='0';
IF lleno='0' THEN
llenar<='1';
ELSE
llenar<='0';
lento<='1';
diraux<=NOT diraux;
subtiempo<=0;
ELSE
END IF;
tiempo<=tiempo+1;
IF tiempo=cincomin THEN presente<=vacia2;
END IF;
END IF;
WHEN vacia2=>
vaciar<='1';
lento<='0';
IF vacio='1' THEN
IF centriaux='1' THEN presente<=centrifugado;
ELSE presente<=inicial;
END IF;
END IF;
tiempo<=0;

WHEN centrifugado=>
rapido<='1';
tiempo<=tiempo+1;
IF tiempo=diezmin THEN presente<=inicial; END IF;
END CASE;
END IF;
PROCESS(centrifuga)
BEGIN
IF centrifuga='1' THEN centriaux<=NOT centriaux; END IF;
END PROCESS;
PROCESS(color)
BEGIN
IF color='1' THEN coloraux<=NOT coloraux; END IF;
END PROCESS;
direccion<=diraux;
END sincrona;
Normalmente es buena practica poner el contador de tiempo fuera de la descripcion

de la maquina de estados, especialmente por claridad, pero en este caso hemos visto
que tambien es posible incluirla dentro. La sntesis de este circuito requiere unos 105
registros para su realizacion. El hecho de que se hayan puesto las salidas en la propia
descripcion de la maquina signica que vienen sincronizadas por la se~nal de reloj, y esto
signica que habra un registro asociado con cada una de las se~nales que haya en este
proceso.
A continuacion veremos la otra posibilidad que consiste en poner las se~nales de
salida en un proceso aparte que sera completamente combinacional, que por lo tanto
no necesitara registros adicionales, y que ademas hara que las salidas cambien a la vez
que el estado.
LIBRARY ieee;
ENTITY lavadora2 IS
PORT (color,centrifuga,start,jabon_listo,vacio,lleno,clk: IN std_logic;
jabon,llenar,vaciar,rapido,lento,direccion: OUT std_logic);
END lavadora2;
ARCHITECTURE sincrona2 OF lavadora2 IS

CONSTANT diezsec: integer:=1000; -- Estos tiempos han sido
CONSTANT cincomin: integer:=30000; -- calculados suponiendo una frecuencia
CONSTANT diezmin: integer:=60000; -- de reloj de 100 Hz.
CONSTANT veintemin: integer:=120000;
TYPE estados IS (inicial,lavado,vacia1,aclarado,vacia2,centrifugado);
SIGNAL presente: estados:=inicial;
SIGNAL coloraux,centriaux,dirauxd,diraux: std_logic:='0';
SIGNAL tiempo: integer RANGE 0 TO 16#1FFFF# :=0;
SIGNAL subtiempo: integer RANGE 0 TO 1023 :=0;
SIGNAL subtiempores, tiempores: boolean :=TRUE;
BEGIN
maquina:
PROCESS(clk)
BEGIN
IF clk='1' THEN
CASE presente IS
WHEN inicial=>
IF start='1' THEN presente<=lavado; END IF;
WHEN lavado=>

IF coloraux='1' AND tiempo=diezmin THEN presente<=vacia1;
ELSIF tiempo=veintemin THEN presente<=vacia1;
END IF;
WHEN vacia1=>
IF vacio='1' THEN presente<=aclarado;
END IF;
WHEN aclarado=>
IF tiempo=cincomin THEN presente<=vacia2;
END IF;
WHEN vacia2=>
IF vacio='1' THEN
IF centriaux='1' THEN presente<=centrifugado;
ELSE presente<=inicial;
END IF;
END IF;
WHEN centrifugado=>
IF tiempo=diezmin THEN presente<=inicial; END IF;
END CASE;
END IF;
salida:
PROCESS(presente)
BEGIN
CASE presente IS
WHEN inicial=>
jabon<='0'; llenar<='0'; vaciar<='1';
lento<='0'; rapido<='0'; dirauxd<='0';
tiempores<=TRUE; subtiempores<=TRUE;
WHEN lavado=>
vaciar<='0';
rapido<='0';
IF jabon_listo='0' THEN jabon<='1';
ELSE jabon<='0';
END IF;
IF lleno='0' THEN
llenar<='1';
lento<='0';
tiempores<=TRUE;
ELSE
llenar<='0';
lento<='1';
jabon<='0';
tiempores<=FALSE;
END IF;
dirauxd<=NOT diraux;
subtiempores<=TRUE;
ELSE
subtiempores<=FALSE;
END IF;
WHEN vacia1=>
jabon<='0';
vaciar<='1';
lento<='0';
rapido<='0';
subtiempores<=TRUE;
tiempores<=TRUE;
llenar<='0';
dirauxd<='0';
WHEN aclarado=>
jabon<='0';
vaciar<='0';
rapido<='0';
IF lleno='0' THEN
llenar<='1';
lento<='0';
tiempores<=TRUE;

ELSE
llenar<='0';
lento<='1';
tiempores<=FALSE;
END IF;
dirauxd<=NOT diraux;
subtiempores<=TRUE;
ELSE
subtiempores<=FALSE;
END IF;
WHEN vacia2=>
jabon<='0';
dirauxd<='0';
vaciar<='1';
lento<='0';
rapido<='0';
llenar<='0';
subtiempores<=TRUE;
tiempores<=TRUE;
WHEN centrifugado=>
jabon<='0';
dirauxd<='0';
llenar<='0';
vaciar<='1';
rapido<='1';
lento<='0';
subtiempores<=TRUE;
tiempores<=FALSE;
END CASE;
END PROCESS salida;
contador:
PROCESS(clk)
BEGIN
IF clk='1' THEN
IF subtiempores THEN
subtiempo<=0;
ELSE
END IF;
IF tiempores THEN
tiempo<=0;
ELSE
tiempo<=tiempo+1;
END IF;
END IF;
PROCESS(centrifuga)
BEGIN
IF centrifuga='1' THEN centriaux<=NOT centriaux; END IF;
END PROCESS;
PROCESS(color)
BEGIN
IF color='1' THEN coloraux<=NOT coloraux; END IF;
END PROCESS;
PROCESS(clk)
BEGIN
IF clk='1' THEN diraux<=dirauxd;
END IF;
END PROCESS;
direccion<=diraux;
END sincrona2;

Hay que apreciar que no solo se han sacado las se~nales de salida sino que ademas
han sido necesarios mas cambios. Por una lado se ha creado un nuevo proceso para el
contador de tiempo, con lo que han sido necesarias a~nadir unas se~nales para comunicar
la maquina de estados con este proceso. Luego se han puesto todas las se~nales de salida
en cada una de las posibilidades del CASE, de esta manera ese proceso es totalmente
combinacional y ahorramos registros. Con todo esto, esa descripcion, que era equiva-
lente a la anterior, ocupa unos 70 registros, que es un numero sensiblemente inferior al
anterior.
Esto ejemplo nos ha demostrado que dos descripciones que resuelven aparentemente
el mismo problema, se pueden sintetizar de dos formas muy diferentes.
11.2.7 El concurso
Ejemplo 11.7 Se pretende realizar el modelo de un chip que controla el funcionamiento
de un programa concurso de television entre tres concursantes. La prueba que tienen que
pasar los tres concursantes es la de contestar a unas preguntas eligiendo una de las tres
respuestas que se le dan, para ello dispone de tres pulsadores cada uno. Hay un operador
humano detras del escenario que controla la maquina. Tiene tres interruptores donde
programa la respuesta correcta (correcto), un pulsador que le sirve para iniciar el juego
(start), otro pulsador que le sirve para indicar otra pregunta (nueva) y un boton de
reset para inicializarlo todo. Una vez presionado start los concursantes deben pulsar
el boton correspondiente a la pregunta que crean correcta. En el momento alguien pulse
se pasa a evaluar su respuesta (como los circuitos van a tener un retraso muy peque~no,
se supone que es imposible que dos jugadores pulsen a la vez). Si el jugador acerto la
respuesta se le sumaran 10 puntos en su marcador, pero si fallo entonces se le restaran
5 puntos. Si ningun jugador contesta en 5 segundos entonces se le restaran 5 puntos al
que tenga mayor puntuacion en ese momento (si hay varios se les resta a todos ellos).
El circuito sabra si la respuesta ha sido correcta comparandola con la que el operador
haya programado en los interruptores correcto antes de iniciar cada pregunta y que
cambiara entre pregunta y pregunta antes de pulsar nueva. Cuando algun jugador llegue
a 100 puntos o mas entonces habra ganado y el juego se parara activandose la salida
correspondiente al jugador que ha ganado. Los marcadores del resto de jugadores se
ponen a cero salvo el del que gano que conserva su valor. As se queda todo en este
estado hasta que el operador le de al reset.
La frecuencia de reloj es ja y vale 1024 Hz. En caso de pregunta acertada, fallada,
o que pasaron los 5 segundos, el operador siempre debera pulsar nueva para hacer otra
pregunta. Los interruptores se ponen y se quedan a uno o a cero hasta que se los cambie
otra vez. Los botones estan a uno mientras se pulsen, el resto del tiempo estan a cero.
En este caso se da una descripcion mas para modelado y simulacion que para sntesis,
ya que si se intenta sintetizar no sale lo que en principio debera ser. La razon es que
cuando se describe una maquina de estados sin sincrona con un reloj, el sintetizador
no lo optimiza por no reconocerlo como maquina de estados, y por otro lado esta el
problema de la interpretacion que hace el sintetizador de la lista sensible; si nos jamos
en el proceso salida, la lista sensible no es mas que la se~nal presente, lo cual signica
que todas las se~nales de este proceso vienen sincronizadas por el cambio de estado, esto
quiere decir que instrucciones como la de sumas 10 puntos, etc, solo tienen lugar una
vez durante el cambio de estado. Si esta descripcion se sintetiza se observa que esto
no ocurre as, sino que lo que realmente sucede es que la instruccion que suma 10, por
ejemplo, se repite indenidamente con el retraso propio de las puertas mientras el pulso
esta en alto. Esto es as porque el sintetizador supone que todas las se~nales del proceso
estan en la lista sensible y lo sintetiza como logica combinatorial y no funciona bien.
ENTITY ajugar IS
PORT (
-- Reloj de frecuencia fija 1024 Hz;
clk: IN BIT;
-- Diferentes pulsadores o botones del operador:
reset,start,nueva: IN BIT;
-- Contiene la respuesta correcta:
correcto: IN BIT_VECTOR(1 TO 3);
-- Pulsadores de los jugadores A,B,C respectivamente:
pulsaA, pulsaB, pulsaC: IN BIT_VECTOR(1 TO 3);
-- Marcadores de cada jugador A, B y C:
marcaA, marcaB, marcaC: OUT INTEGER RANGE 0 TO 255;
-- Lineas para indicar quien de todos gano:
ganaA, ganaB, ganaC: OUT BIT);
END ajugar;
ARCHITECTURE una_solucion OF ajugar IS

TYPE estado IS (inicial,responde,evalua,tiempo,final);
SIGNAL cuenta: INTEGER RANGE 0 TO 8191;
SIGNAL marcauxA,marcauxB,marcauxC: INTEGER RANGE 0 TO 255;
SIGNAL timeout: BOOLEAN; -- Para indicar paso de 5 segundos.
SIGNAL pulsaron: BOOLEAN; -- Para saber si alguien pulso.
SIGNAL fin: BOOLEAN; -- Para saber cuando se llega al final.
SIGNAL rescont: BOOLEAN; -- Pone a cero la cuenta.
SIGNAL presente: estado;
BEGIN
marcaA<=marcauxA; -- Senyales auxiliares para poder
marcaB<=marcauxB; -- leer la salida
marcaC<=marcauxC;
contador:
PROCESS(clk)
BEGIN
IF clk='1' THEN
IF rescont THEN cuenta<=0; -- Para inicializar la cuenta
ELSE cuenta<=cuenta+1;
END IF;
END IF;
timeout<=true WHEN cuenta=5120 ELSE false; -- pasaron 5 segundos

pulsaron<=true WHEN (pulsaA/="000" OR pulsaB/="000" OR pulsaC/="000")
ELSE false;
fin<=true WHEN (marcauxA>=100 OR marcauxB>=100 OR marcauxC>=100)
ELSE false;
maquina:
PROCESS(reset,start,nueva,pulsaron,timeout,fin) -- senyales que cambian
BEGIN -- el estado presente.
IF reset='1' THEN presente<=inicial;
ELSE
CASE presente IS
WHEN inicial=>
IF start='1' THEN presente<=responde; END IF;
WHEN responde=>
IF pulsaron THEN presente<=evalua;
ELSIF timeout THEN presente<=tiempo;
END IF;
WHEN evalua=>
IF fin THEN presente<=final;
ELSIF nueva='1' THEN presente<=responde;

END IF;
WHEN tiempo=>
IF nueva='1' THEN presente<=responde; END IF;
WHEN final=>
NULL;
END CASE;
END IF;
salida:
PROCESS(presente)
BEGIN
CASE presente IS
WHEN inicial=>
marcauxA<=0;
marcauxB<=0;
marcauxC<=0;
ganaA<='0';
ganaB<='0';
ganaC<='0';
rescont<=true;
WHEN responde=>
rescont<=false;
WHEN evalua=>
rescont<=true;
IF pulsaA/="000" THEN
IF pulsaA=correcto THEN marcauxA<=marcauxA+10;
ELSIF marcauxA>=5 THEN marcauxA<=marcauxA-5;
END IF;
END IF;
IF pulsaB/="000" THEN
IF pulsaB=correcto THEN marcauxB<=marcauxB+10;
ELSIF marcauxB>=5 THEN marcauxB<=marcauxB-5;
END IF;
END IF;
IF pulsaC/="000" THEN
IF pulsaC=correcto THEN marcauxC<=marcauxC+10;
ELSIF marcauxC>=5 THEN marcauxC<=marcauxC-5;
END IF;
END IF;
WHEN tiempo=>
rescont<=true;
IF marcauxA>=5 AND marcauxA>=marcauxB AND marcauxA>=marcauxC THEN
marcauxA<=marcauxA-5;
END IF;
IF marcauxB>=5 AND marcauxB>=marcauxA AND marcauxB>=marcauxC THEN
marcauxB<=marcauxB-5;
END IF;
IF marcauxC>=5 AND marcauxC>=marcauxB AND marcauxC>=marcauxA THEN
marcauxC<=marcauxC-5;
END IF;
WHEN final=>
IF marcauxA>=100 THEN
marcauxB<=0;
marcauxC<=0;
ganaA<='1';
END IF;
IF marcauxB>=100 THEN
marcauxA<=0;
marcauxC<=0;
ganaB<='1';
END IF;
IF marcauxC>=100 THEN
marcauxB<=0;
marcauxA<=0;
ganaC<='1';
END IF;
END CASE;

END PROCESS salida;
END una_solucion;
Aparte de que la maquina de estados no es sncrona con un reloj, hay otra diferencia
con otras descripciones que hemos visto, y es que el contador del tiempo esta situado
en un proceso aparte, que no es raro, y se han utilizado unas se~nales para indicar los
nales de cuenta.
11.2.8 El pin-ball
Ejemplo 11.8 Realizar la descripcion en VHDL del controlador de una maquina de
pin-ball. La maquina tiene un marcador que se incrementa segun donde toque la bola,
tiene dos pivotes de manera que segun de la bola en uno u otro se suman 5 o 10 puntos
respectivamente. Cada 100 puntos se obtiene una bola nueva. Tambien tiene dos tacos
que son los de darle a la bola y otro que sirve para lanzar la bola al principio. Ademas
esta la ranura por donde se mete la moneda.
Para controlar la maquina se necesitan las siguientes entradas:
p uno, p dos: se ponen a '1' cuando la bola choca contra el pivote uno o dos. Van a
servir para saber que valor hay que sumar al marcador; si le da al pivote p uno
se suman 5 y al otro 10.
falta: esta se~nal se pone a '1' cuando se empuja bruscamente la maquina para hacer
trampa. Cuando esta se~nal se pone a uno, los tacos deben paralizarse y quedarse
as hasta que la bola se pierda por el agujero.
nueva: sirve para indicar que se ha introducido una moneda y que empieza la partida
(por simplicidad no se considera el caso en el que se introducen varias monedas
para tener mas partidas.)
pierde: sirve para indicar que se ha perdido la bola por el agujero y que por tanto hay
que restar una bola a las que quedan. Cuando no quedan mas bolas se detiene el
juego.
clk: se~nal de reloj para sincronizar el circuito. Su frecuencia se supone mucho mas alta
que el tiempo que estan activas las se~nales de p uno, p dos, nueva y pierde.
A partir de dichas entradas el circuito debe producir las siguientes salidas:
marcador: Es un bus de 12 lneas que se conecta al marcador electronico de la maquina
y que contiene la cuenta de puntos.
bloqueo: mientras esta a '1' los tacos no funcionan. Debe estar a '1' mientras no se
juega o desde que se movio la maquina bruscamente (falta) hasta que sale una
nueva bola.
n: Cuando se acaban las bolas esta se~nal se pone a '1' para encender un gran panel
luminoso que pone 'Fin de juego. Inserte moneda'.
Tener en cuenta que el marcador no debe ponerse a cero al acabar el juego, sino que
debe hacerlo en el momento de empezar a jugar despues de insertar la moneda.
Como es habitual, el problema se puede solucionar mediante una maquina de estados
que hacemos sncrona para que resulte sencilla la sntesis del circuito.
Se ha utilizado una maquina de estados con un unico proceso, esto en principio no
nos supone ningun problema ya que importa poco que las se~nales de salida esten un
ciclo de reloj retrasadas respecto del cambio de estado, debido a que la se~nal de reloj
se supone de una frecuencia elevada.
Como aspecto novedoso en este ejemplo se puede ver el tratamiento que se ha
seguido con los pulsos producidos por los pivotes y el pulso producido cuando se pierde
la bola (pierde). Ya se comento al inicio del captulo que un error comun se daba en
el tratamiento de pulsos mas largos que la se~nal reloj, que provocaba que una misma
operacion se repitiera una y otra vez mientras dura el pulso. En este caso se ha evitado
creando un pulso auxiliar que tiene la duracion de un pulso de reloj y que por tanto
solo se procesa una vez. Estos pulsos se han creado al nal en los procesos d pierde,
d p uno y d p dos. Por lo dem as el programa sigue las reglas basicas para sntesis vistas
en el resto de ejemplos.
LIBRARY ieee;
ENTITY pinball IS
PORT (p_uno,p_dos,falta,nueva,pierde,clk : IN std_logic;
marcador: OUT integer RANGE 0 TO 4095; -- 12 bits
bloqueo,fin: OUT std_logic);
END pinball;
ARCHITECTURE sincrono OF pinball IS

TYPE estado IS (insertar,inicia,juega,suma_cinco,suma_diez,trampa,resta);
SIGNAL marcaux: integer RANGE 0 TO 4095 :=0; -- Auxiliar para leer la salida
SIGNAL cien: integer RANGE 0 TO 127 :=0; -- Servira para las bolas extras
SIGNAL bolas: integer RANGE 0 TO 31 :=0; -- Almacena el numero de bolas
SIGNAL d_p_uno,d_p_dos,d_pierde: std_logic; -- Auxiliares para esas entradas
SIGNAL presente: estado:=insertar;
BEGIN
maquina:
PROCESS(clk)
BEGIN
IF clk='1' THEN
CASE presente IS
WHEN insertar=>
IF nueva='1' THEN presente<=inicia;
END IF;
fin<='1';
bloqueo<='1';
WHEN inicia=>
presente<=juega;
fin<='0';
marcaux<=0;
cien<=0;
bloqueo<='0';
bolas<=5;
WHEN juega=>
IF d_pierde='1' THEN presente<=resta; END IF;
IF falta='1' THEN presente<=trampa; END IF;
IF bolas=0 THEN presente<=insertar; END IF;
IF d_p_uno='1' THEN presente<=suma_cinco; END IF;
IF d_p_dos='1' THEN presente<=suma_diez; END IF;
IF cien>=100 THEN
cien<=0;
bolas<=bolas+1;
END IF;
IF bolas=0 THEN presente<=insertar; END IF;
bloqueo<='0';
WHEN suma_cinco=>
presente<=juega;
marcaux<=marcaux+5;
cien<=cien+5;
WHEN suma_diez=>
presente<=juega;

11.3 Ejercicios propuestos 111
marcaux<=marcaux+10;
cien<=cien+10;
WHEN resta=>
bolas<=bolas-1;
presente<=juega;
WHEN trampa=>
IF d_pierde='1' THEN presente<=resta; END IF;
bloqueo<='1';
END CASE;
END IF;
-- Como estos pulsos de entrada son mucho mas largos que el periodo del reloj
-- se crean estas senyales que son lo mismo pero duran un 'unico pulso.
d_pierde:
PROCESS(pierde,presente)
BEGIN
IF presente=resta OR presente=inicia THEN d_pierde<='0';
ELSIF pierde='1' AND pierde'EVENT THEN d_pierde<='1';
END IF;
END PROCESS;
d_p_uno:
PROCESS(p_uno,presente)
BEGIN
IF presente=suma_cinco OR presente=inicia THEN d_p_uno<='0';
ELSIF p_uno='1' AND p_uno'EVENT THEN d_p_uno<='1';
END IF;
END PROCESS;
d_p_dos:
PROCESS(p_dos,presente)
BEGIN
IF presente=suma_diez OR presente=inicia THEN d_p_dos<='0';
ELSIF p_dos='1' AND p_dos'EVENT THEN d_p_dos<='1';
END IF;
END PROCESS;
-- Finalmente se pone el marcador igual a su auxiliar.

marcador<=marcaux;
END sincrono;
11.3 Ejercicios propuestos

Ejemplo 11.9 Realizar la descripcion del circuito de control de un microondas. Las
entradas al sistema son:
Minuto Es un boton que incrementa el contador del tiempo de coccion en 60 segundos.
Marcha Cuando se pulsa se inicia la marcha del horno, y no se parara hasta que se
abra la puerta o la cuenta llegue al nal o se pulse la tecla de stop reset.
Stop Reset Es un boton que si se pulsa con el horno en marcha lo detiene, pero la
cuenta conserva su valor. Si se pulsa con el horno parado la cuenta se pone a
cero.
Puerta Es una entrada que cuando esta a uno indica que la puerta esta abierta, y a
cero indica que esta cerrada.
clk Es el reloj de entrada con un periodo de 125 ms.
Las salidas del circuito a realizar seran:
Segundos(9..0) Estas 10 lneas le indican a una pantalla el numero de segundos de
la cuenta. La codicacion es binaria por lo que se pueden programar hasta 1023
segundos.
Calentar Cuando esta a uno el horno calienta, y si esta a cero no hace nada.
Luz A uno enciende la luz interna del horno. Esta luz debe estar encendida mientras
la puerta este abierta y mientras el horno este calentando.
Alarma A uno suena. Debe sonar durante 3 segundos cuando la cuenta ha llegado a
cero despues de que el horno ha estado calentando.
En la gura 11.2 se muestra el chip del cual se quiere hacer la descripcion junto con
sus entradas y salidas.
Segundos
10
Minuto
Controlador Calentar
Marcha
de
Microondas Luz
Stop
Reset
Alarma
Clk
Puerta
Figura 11.2: Figura del ejercicio del microondas
Ejemplo 11.10 Describir con VHDL el circuito que controla una maquina de cafe.
Las entradas y salidas del circuito se muestran en la gura 11.3. Las entradas son:
moneda clk El anco de subida de esta se~nal indica que se ha introducido una moneda
en la maquina.
moneda(7..0) Indica el valor de la moneda introducida.
tecla(6..1) Son los seis botones que permiten elegir entre los seis diferentes cafes que
prepara la maquina.
no azucar Pulsando esta tecla al mismo tiempo que la de seleccion, la maquina no le
pondra azucar al cafe.
listo La parte de la maquina que hace el cafe pone a uno esta se~nal durante unos
instantes para indicar que el cafe esta listo y puede preparar otro.
Las salidas del circuito deberan ser:
error Es una luz que se enciende cuando se realiza una seleccion y no hay dinero
suciente.
cambio(7..0) Es la diferencia entre el dinero introducido y lo que cuesta el cafe. Le
sirve al bloque de cambio para devolver el cambio.
cambio clk Cuando esta se~nal pasa de cero a uno el bloque de cambio debe leer la
informacion de cambio(7..0) y devolver esa cantidad. Como no es este el circuito
que se debe sintetizar se supondra que funciona correctamente.
tipo(2..0) Estos tres bits indican el tipo de cafe, el 1, el 2, etc. Si no se ha seleccionado
11.3 Ejercicios propuestos 113
nada el tipo es el cero. La parte que hace cafe empieza en el momento en que
detecte un cambio en estas lneas.
azucar A uno le indicara a la parte que hace el cafe que le ponga azucar.
Debe tenerse en cuenta que hay precios diferentes segun el cafe. As, el cafe tipo 1
vale 40 pts, el tipo 2 vale 50, y el resto valen 60 pts.
100-50-25-5
Falta dinero
CHIP a sintetizar
error
moneda_clk
moneda total(7:0)
Tecla(6:1) cambio_clk
1 2
sin_azucar cambio(7:0)
3 4 tipo(2:0)
listo
azucar Cambio
5 6
Teclado Sin azucar
Hace cafe
Figura 11.3: Figura del ejercicio de la maquina de cafe


Bibliografa
[1] Barry Hawkes. CADCAM. Paraninfo, 1989.
[2] Roger Lipsett, Carl Schaefer, and Cary Ussery. VHDL: Hardware Description and
Design. Kluwer Academic Publishers, 1991.
[3] Douglas L. Perry. VHDL. McGraw-Hill, 2 edition, 1993.
[4] Kevin Skahill. VHDL for programmable logic. Addison-Wesley, 1996.
[5] Peter J. Ashenden. The VHDL Cookbook. 1990.
[6] Mentor Graphics Introduction to VHDL, 1994.
[7] Mentor Graphics VHDL Reference Manual, 1994.
[8] Altera VHDL, 1996.
[9] WARP VHDL Synthesis Reference, 1994.
115
116 Bibliografa

Indice de Materias
AFTER, 68 EDA, 1, 6, 21
Aggregate, vease Agregado EDIF, 13, 14
Agregado, 31, 83 ejemplo, 13
ALIAS, 33 Ejecucion
ALL, 62 concurrente, 27, 41, 45
ARCHITECTURE, 36 serie, 45, 49
ARRAY, 30 ELSE, 42, 51
ASIC, 2 ELSIF, 51
ASSERT, 72 Entero, 29
Atributos, 32 Entidad
declaracion, 34, 73
Backannotation, 6 ENTITY, 35
Banco de pruebas, 71{72 Esquemas, 2
Bases, 27 EVENT, 32
Bit, 63 Evento, 68, 71
Bit vector, 63 EXIT, 53
BLOCK, 34, 42 Expresion de guardia, 43
Expresion de guardia, 43
Bottom-Up, 3, 11, 12 FOR, 52{53
BUFFER, 35 en conguracion, 65
BUS, 33 Forwardannotation, 6
FPGA, 3
CAD, 1 Funcion de resolucion, 63, 82
herramientas, 2 FUNCTION, 57{59
Cadenas, 27 de resolucion, 82
CASE, 51{52 Declaracion, 58
CI
herramientas, 3 GENERIC, 35
Circuitos integrados, vease CI HDL, 2, 21
Comentarios, 27
COMPONENT, 26, 65 Identicadores, 27
Concatenacion, 28 IF..THEN..ELSE, 51
CONFIGURATION, 65 IN, 35
CONSTANT, 33 Ingeniera concurrente, 6
DELAYED, 58 de grupo, 6
Descripcion personal, 6
comportamental, 25, 39, 45 INOUT, 35
Dise~no Integer, 29
Bottom-Up, vease Bottom-Up LIBRARY, 62
concurrente, 6 Librera, vease VHDL Librera
ujo, 1, 9 ieee, 83
jerarquico, 12 LINKAGE, 35
VHDL, 42 Lista sensible, 49
modular, 12 LOOP, 52{53
Top-Down, vease Top-Down
Driver, 48, 67 Maquinas de estados, 84{87
117
118 Indice de Materias
Matrices, 30, vease Vectores ROM, 97
Microprocesador ROR, 28
ejemplo, 98 RTL, 39, 40
Modelado, 21, 22, 67 Ejemplo, 44
Numeros, 27 Sntesis, 22, 75
Netlist, 13{15, 21, 23, 25 logica combinatorial, 78
ejemplos, 15 logica secuencial, 79
NEXT, 53 Se~nal
NOW, 73 diferencias, 47
SELECT, 42
Operadores SEVERITY, 72
aritmeticos, 28 SIGNAL, 33
desplazamiento, 28 Simulacion
logicos, 29 de sistemas, 2
relacionales, 28 digital, 3
OTHERS, 31, 42, 52, 83 electrica, 3
OUT, 35 funcional, 2
Overloading, 29, 60 SLL, 28
PACKAGE, 64 Spice, 15, 18
BODY, 64 SRL, 28
declaraciones en, 34 STABLE, 58
Package, 33 Std arith, 98
PACKAGE BODY, 64 Std logic, 63, 83
PAL, 3 Std logic 1164, 63, 83
Paquete, vease VHDL Paquete Subprogramas
PCB, 2 Declaracion, 58
herramientas, 3 Subtipos, 31
PLD, 3 SUBTYPE, 31
PORT, 35 Tango, 15, 17
PORT MAP, 26 Test bench, vease Banco de pruebas
PROCEDURE, 57{59 Time, 30
Declaracion, 58 Tipos, 29{31
Proceso pasivo, 73 compuestos, 30
PROCESS, 49 enumerados, 30
Ejecucion serie, 45, 46 escalares, 29
en subprogramas, 58 fsicos, 30
QUIET, 58 resueltos, 31, 82
Top-Down, 4, 9, 11, 12
RANGE, 29{31 Top-down
Real, 30 ventajas, 5
RECORD, 31 TRANSACTION, 58
Registro, 31 Transferencia entre registros, 25
REPORT, 72 TRANSPORT, 71
Retraso Ejemplo, 97
inercial, 70{71, 97 TYPE, 29
transportado, 70{71, 97 USE, 62, 65
Retroanotacion, vease Backannotation en conguracion, 65
RETURN, 57, 58
ROL, 28 VARIABLE, 33
Indice de Materias 119
Variable
diferencias, 47
Vectores, 30
VHDL
Arquitectura, 36, 61
Atributos, 32
Buses, 81
Conguracion, 65
Constantes, 33
ejemplos, 23, 89
Entidad, 34, 61
Introduccion, 22
Librera
de dise~no, 61
IEEE, 63
ieee, 83
std, 62
work, 61, 62
Operadores, 27
Paquete, 64
standard, 62, 83
std logic 1164, 63
textio, 62
Se~nales, 33
sintaxis, 27
Subprogramas, 57{61
llamadas a, 59
Tipos de datos, 29
Subtipos, 31
Unidades, 61
Variables, 33
ventajas, 22
WAIT, 34, 49{50
en subprogramas, 60
WHEN, 42, 52
WHILE, 52{53
WITH, 42

VHDL

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

VHDL

Încărcat de

Drepturi de autor:

Formate disponibile

VHDL

Lenguaje para descripcion y modelado de circuitos

Fernando Pardo Carpio

c Fernando Pardo Carpio, 14 de octubre de 1997

Fernando Pardo, en Valencia, Octubre de 1997

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

1.1 Concepto de herramientas CAD-EDA

descripcion testeo sintesis extraccion de

Figura 1.1: Flujo de dise~no para sistemas electronicos y digitales

En el ciclo de dise~no hardware las herramientas de CAD estan presentes en todos

1.2 Dise~no Bottom-Up

Figura 1.2: Metodologa de dise~no Bottom-Up

1.3 Dise~no Top-Down

Figura 1.3: Metodologa de dise~no Top-Down

y venceras", de manera que un problema, en principio muy complejo, es dividido en

1.3.1 Ventajas del dise~no Top-Down

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

2.2 Generacion de smbolos

2.3 Dise~no modular

2.4 Dise~no jerarquico

2.5.1 El formato EDIF

Ingeniera Informatica Universidad de Valencia

Una de las caractersticas de este formato es la gran cantidad de informacion que

2.5.2 Otros formatos de Netlist

2.5.3 Ejemplo de diferentes Netlist

Figura 2.1: Ejemplo de esquema para su descripcion Netlist

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

3.1 El lenguaje VHDL

3.1.1 VHDL describe estructura y comportamiento

3.2 Ejemplo basico de descripcion VHDL

Figura 3.1: Esquema del ejemplo basico en VHDL

Ingeniera Informatica Universidad de Valencia

En la descripcion de la izquierda hay varias instrucciones todas ellas concurrentes,

Ingeniera Informatica Universidad de Valencia

SIGNAL ax,bx,nosel: bit;

Ingeniera Informatica Universidad de Valencia

4.1 Operadores y expresiones

Precedencia de operadores y sobrecarga

4.2 Tipos de datos

4.2.1 Tipos escalares

Ingeniera Informatica Universidad de Valencia

4.2.2 Tipos compuestos

4.2.3 Subtipos de datos

4.4 Declaracion de constantes, variables y se~nales

CONSTANT e: real := 2.71828;

VARIABLE contador: natural := 0;

Es posible, dado un elemento previamente de nido, cambiarle el nombre o ponerle

VARIABLE instruccion: bit_vector(31 DOWNTO 0);

SIGNAL selec: bit := '0';

Ingeniera Informatica Universidad de Valencia

4.5 Declaracion de entidad y arquitectura

La estructura de esta declaracion es parecida a la que ya se haba visto en los

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

5.1 Ejecucion concurrente y ejecucion serie

5.2 Descripcion comportamental RTL

ARCHITECTURE flujo OF comp IS

Lenguaje para descripcion y modelado de circuitos

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Figura 1.1: Flujo de dise~no para sistemas electronicos y digitales

En el ciclo de dise~no hardware las herramientas de CAD estan presentes en todos

Figura 1.2: Metodologa de dise~no Bottom-Up

Figura 1.3: Metodologa de dise~no Top-Down

y venceras", de manera que un problema, en principio muy complejo, es dividido en

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

2.2 Generacion de smbolos

2.4 Dise~no jerarquico

Ingeniera Informatica Universidad de Valencia

Una de las caractersticas de este formato es la gran cantidad de informacion que

Figura 2.1: Ejemplo de esquema para su descripcion Netlist

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

3.2 Ejemplo basico de descripcion VHDL

Figura 3.1: Esquema del ejemplo basico en VHDL

Ingeniera Informatica Universidad de Valencia

En la descripcion de la izquierda hay varias instrucciones todas ellas concurrentes,

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

4.4 Declaracion de constantes, variables y se~nales

Es posible, dado un elemento previamente denido, cambiarle el nombre o ponerle

Ingeniera Informatica Universidad de Valencia

4.5 Declaracion de entidad y arquitectura

La estructura de esta declaracion es parecida a la que ya se haba visto en los

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

5.1 Ejecucion concurrente y ejecucion serie

5.2 Descripcion comportamental RTL

En esta ocasion se tienen tres instrucciones en vez de una. Estas instrucciones no se

5.3 Estructuras de la ejecucion concurrente RTL

Asignacion condicional: WHEN...ELSE

Ya se ha visto anteriormente y su utilizacion es muy sencilla. Es importante, en toda

Asignacion con seleccion: WITH...SELECT...WHEN

En muchas ocasiones es interesante agrupar sentencias de ejecucion concurrente en

Ingeniera Informatica Universidad de Valencia

En la parte de declaracion se puede incluir desde subprogramas a se~nales al igual

Ingeniera Informatica Universidad de Valencia

Aunque sintacticamente es correcto, y una simulacion de este ejemplo dara los

En el ejemplo de la izquierda solo se utilizan se~nales y la ejecucion tiene lugar de

El bloque de ejecucion serie: PROCESS

La forma de entrar en la ejecucion serie dentro de un programa en VHDL es mediante

Un ejemplo algo mas elaborado se puede realizar intentando la descripcion de alguna

Ingeniera Informatica Universidad de Valencia

Sentencia de seleccion: CASE

Naturalmente en este ejemplo se supone que la puntuacion es un entero, ya que

El tipo de iteracion indicara si es un WHILE o FOR. Es opcional, por lo que se

Ingeniera Informatica Universidad de Valencia

Para terminar este captulo se ha introducido un peque~no ejemplo. Este mismo

Lo unico que se ha hecho es poner el proceso anterior, que era un IF en la forma

Ingeniera Informatica Universidad de Valencia

Ingeniera Informatica Universidad de Valencia

7.1.1 Declaracion de procedimientos y funciones

La lista de parametros es opcional y si no hay parametros tampoco es necesario usar

A continuacion se presenta un ejemplo donde se dene un procedimiento que calcula

7.2 Libreras, paquetes y unidades

Figura 7.1: Las libreras y las unidades que la componen

Posteriormente a estas deniciones vendra la sobrecarga de operadores, y otras

Naturalmente el nombre del PACKAGE y del cuerpo deben coincidir. A continuacion

7.2.2 Conguracion: CONFIGURATION

Ingeniera Informatica Universidad de Valencia

8.1 Los retrasos y la simulacion

Figura 8.1: Flujo de simulacion por eventos en VHDL

Ingeniera Informatica Universidad de Valencia

8.2 Descripcion de un banco de pruebas

8.3 Noticacion de sucesos

Ingeniera Informatica Universidad de Valencia

Naturalmente aqu se ha supuesto que ni siquiera se tiene el atributo 'EVENT, lo cual

Ingeniera Informatica Universidad de Valencia

9.1 Restricciones en la descripcion

9.2 Construcciones basicas

9.2.1 Descripcion de logica combinacional

Si la ejecucion es serie (proceso) se sintetiza logica combinacional cuando: