VHDL Lenguaje Estandar de Diseno Electronico

~NGUAJ~~~TÁNDARD~
DI~~ÑO~~CTRÓNICO
SeroHn Olloz
Eugenio Villcir
Yago 'forrojo
Lluis Tores
....., 11. )0.1 tl ::ul lJ.
J "
En lo dirección hHp:/ /www.cnm.es/IMB/UbroVHDLJ del Web se pueden encontrar
uno presentación del libro, ejercicios resueltos, el código completo de los proyectos
utilizados en el libro y algunos secciones complementarias que se irón actualizando
periódicamente.
VHDL
LENGUAJE ESTÁNDAR
DE DISEÑO ELECTRÓNICO
VHDL ,
LENGUAJE
- ESTANDAR
,
DE DISENO ELECTRONICO
Eugenio Villar
Doctor en Ciencias Físicas
Facultad de Ciencias de Cantabria
Profesor titular de Tecnología Electrónica (Universidad de Cantabria)
Lluís Terés
Doctor en Informática (UAB)
Colaborador Científico deIIMB-CNM (CSIC)
Profesor asociado del Dpto. Informático (UAB)
Serafín Olcoz
Doctor en Ciencias Físicas
Universidad de Zaragoza
Jefe del Dpto. de Tecnologías de Diseño (SIDSA)
Yago Torroja
Ingeniero Industrial
Profesor asociado de Tecnología Electrónica
Universidad Politécnica de Madrid
E. T. Superior de Ingenieros Industriales (UPM)
PRESENTACiÓN DE:
CARLOS LÓPEZ BARRIO
Catedrático de Tecnología Electrónica ETSIT-UPM
Director de Innovación de Telefónica I+D
RAFAEL BURRIEL LLUNA

Centro de Investigación y Desarrollo de Alcatel. España
FERNANDO ALDANA MAYOR

Catedrático de Tecnología Electrónica (ETSII-UPM)
McGraw-Hill
MADRID· BUENOS AIRES • CARACAS • GUATEMALA· LISBOA· MÉXICO
NUEVA YORK. PANAMÁ. SAN JUAN. SANTAFÉ DE BOGOTÁ. SANTIAGO· SAO PAULO
AUCKLAND • HAMBURGO • LONDRES • MILÁN • MONTREAL • NUEVA DELHI • PARís
SAN FRANCISCO • SIDNEY • SINGAPUR • STo LOUIS • TOKIO • TORONTO
La información contenida en este trabajo ha sido obtenida
por McGraw-Hill Incorporated procedente de fuentes dig-
nas de crédito. No obstante, ni McGraw-Hill ni los autores
garantizan la exactitud o perfección de la información pu-
blicada.
Ni McGraw-Hill ni los autores serán responsables de
cualquier error, omisión o daño ocasionados por el uso de
esta información. Este trabajo se publica con el reconoci-
miento expreso de que los autores están proporcionando
una información, pero no tratando de prestar ningún tipo de
servicio profesional o técnico. Si tal servicio fuera necesa-
rio, díríjase a un profesional adecuado para tal fin.
VHDL. Lenguaje estándar de diseño electrónico.
No está permitida la reproducción total o parcial de este libro, ni su tratamiento informá-

tico, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecá-
nico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito de
los titulares del Copyright.
DERECHOS RESERVADOS © 1998, respecto a la primera edición en español, por

McGRAW-HILUINTERAMERICANA DE ESPAÑA, S. A. U.
Edificio Valrealty, l." planta
Basauri,17
28023 Aravaca (Madrid)
ISBN: 84-481-1196-6
Depósito legal: M. 42.860-1997
Editor: Antonio García Brage

Cubierta: Juan García
Compuesto en: FER Fotocomposición, S. A.
Impreso en: Impresos y Revistas, S. A. (IMPRESA)
IMPRESO EN ESPAÑA - PRINTED IN SPAIN
Coautores
Eduard Lecha Lluís Terés

Instituto de Microelectrónica de Barcelona, CNM Instituto de Microelectrónica de Barcelona, CNM
(CSIC). Universitat Autónoma de Barcelona (CSIC). Universitat Autónoma de Barcelona
eduard@cnm.es lluis@cnm.es
Manel Moré de Castro Eduardo de la Torre
Instituto de Microelectrónica de Barcelona, CNM Universidad Politécnica de Madrid, ETSII
(CSIC). Universitat Autónoma de Barcelona eduardo@upmdie.upm.es
manel@cnm.es
Yago Torroja
Serafín Olcoz Universidad Politécnica de Madrid, ETSn
SIDSA
yago@upmdie.upm.es
olcoz@sidsa.es
Teresa Riesgo Joan Vidal
Instituto de Microelectrónica de Barcelona, CNM
Universidad Politécnica de Madrid, ETSn
tere@upmdie.upm.es (CSIC). Universitat Autónoma de Barcelona
vidal@cnm.es
Fernando Rincón
Instituto de Microelectrónica de Barcelona, CNM Eugenio Villar
(CSID). Universitat Autónoma de Barcelona Universidad de Cantabria
femando@cnm.es villar@teisa.unican.es
Pablo Sánchez Javier Uceda

Universidad de Cantabria Universidad Politécnica de Madrid, ETSII
sanchez@teisa.unican.es uceda@upmdie.upm.es
Web con la presentación e información complementaria de este libro:

http://www.cnm.es/IBMlLibroVHDU
v
Contenido
PRESENTACIÓN . xv
PRÓLOGO . xxi
1. INTRODUCCIÓN . 1
1.1. EVOLUCIÓN DEL DISEÑO ELECTRÓNICO . 2
1.1.1. Años setenta . 3
1.1.2. Años ochenta . 4
1.1.3. Años noventa . 9
1.2. Los LENGUAJES DE DESCRIPCIÓN DE HARDWARE •••....••••...•••..• 12
1.2.1. Lenguajes de descripción de Hw versus desarrollo de Sw . 13
1.2.2. Reseña histórica de los HDLs . 14
1.2.3. Modelado con HDLs: niveles de abstracción y estilos descrip-
tivos . 16
1.2.4. Aportaciones de los HDLs al proceso de diseño . 19
1.3. METODOLOGíAS y FLUJOS DE DISEÑO . 21
1.3.1. Flujo de diseño ascendente (bottom-up) . 23
1.3.2. Flujo de diseño descendente (top-down) . 25
1.3.2.1. Construcción o diseño descendente . 26
1.3.2.2 .. Información ascendente (bottom-up) . 29
1.3.2.3. Validación funcional multinivel . 30
1.4. BIBLIOGRAFÍA ............................................• 31
vii
viii Contenido
2. PRESENTACIÓN DEL LENGUAJE VHDL . . . . . . . . . . . . . . . . . . . . . . 35
2.1. INTRODUCCIÓN, CONTEXTO y CONCEPTOS BÁSICOS ...............•• 36

2.2. UN MODELO DEL HARDWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.1. Modelo de estructura: componentes y jerarquía. . . . . . . . . . . . 37
2.2.2. Modelo de concurrencia: procesos, señales y eventos. . . . . . . . 38
2.2.3. Modelo de tiempo: ciclo de simulación 40
2.3. UNIDADES BÁSICAS DE DISEÑO 43
2.3.1. Declaración de entidad 44
2.3.2. Arquitectura 46
2.3.2.1. Estilo algorítmico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.2.2. Estilo flujo de datos 47
2.3.2.3. Estilo estructural. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.2.4. Estilo mixto 49
2.3.3. Configuración....................................... 49
2.3.4. Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 50
2.3.5. Bibliotecas 53
2.4. OBJETOS, TIPOS DE DATOS Y OPERACIONES . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.1. Elementos léxicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.1.1. Identificadores 54
2.4.1.2. Palabras reservadas 55
2.4.1.3. Símbolos especiales 56
2.4.1.4. Literales 56
2.4.2. Objetos del VHDL 58
2.4.2.1. Constantes 58
2.4.2.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.4.2.3. Señales 60
2.4.2.4. Ficheros 60
2.4.3. Tipos de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4.3.1. Declaración de tipos de datos. . . . . . . . . . . . . . . . . . . . 62
2.4.3.2. Tipos de datos escalares. . . . . . . . . . . . . . . . . . . . . . . . 63
2.4.3.3. Declaración de subtipos de datos .. . . . . . . . . . . . . . . . 66
2.4.3.4. Tipos de datos compuestos . . . . . . . . . . . . . . . . . . . . . . 67
2.4.3.5. Otros tipos de datos 72
2.4.4. Expresiones y operadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.4.5. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.4.5.1. Atributos de rangos de vectores. . . . . . . . . . . . . . . . . . 78
2.4.5.2. Atributos de tipos de datos. . . . . . . . . . . . . . . . . . . . . . 79
2.4.5.3. Atributos de señales 80
2.4.5.4. Atributos definidos por el usuario 81
2.5. SENTENCIAS SECUENCIALES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.5.1. La sentencia wait 82
2.5.2. Asignación a señal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.5.3. Asignación a variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.5.4. La sentencia if ~. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.5.5. La sentencia case 91
Contenido ix
2.5.6. La sentencia loop ........................ 94

2.5.7. La sentencia exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.5.8. Sentencia next 97
2.5.9. La sentencia assert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.5.10.Llamada secuencial a subprogramas. . . . . . . . . . . . . . . . . . .. 100
2.5.11.La sentencia retum . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 100
2.5.12.La sentencia null 100
2.5.13.Etiquetas en sentencias secuenciales del VHDL-93 . . . . . . . .. 101
2.6. SENTENCIAS CONCURRENTES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 101
2.6.1. La sentencia process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 102
2.6.2. Asignación a señal concurrente. . . . . . . . . . . . . . . . . . . . . . . .. 103
2.6.3. Asignación concurrente condicional 103
2.6.4. Asignación concurrente con selección. . . . . . . . . . . . . . . . . . .. 104
2.6.5. Assert concurrente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 105
2.6.6. Llamada concurrente a subprograma 106
2.6.7. Sentencias estructurales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 107
2.6.7.1. Componentes 107
2.6.7.2. Sentencia generate . . . . . . . . . . . . . . . . . .. 11O
2.6.7.3. Configuración de un diseño. . . . . . . . . . . . . . . . . . . .. 112
2.6.7.4. Genéricos 116
2.6.8. Sentencia block 118
2.7. SUBPROGRAMAS ..........................................• 119
2.7.1. Funciones.......................................... 120
2.7.2. Procedimientos...................................... 122
2.7.3. Sobrecarga de subprogramas. . . . . . . . . . . . . . . . . . . . . . . . . .. 124
2.7.4. Funciones de resolución. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 125
2.8. EJERCICIOS 128
2.9. BIBLIOGRAFÍA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . • . . . .• 133
3. PROCESADO Y MECANISMOS DE SIMULACIÓN DEL LENGUA-

JEVHDL 135
3.1. INTRODUCCIÓN .....•...................................... 136
3.2. SIMULACIÓN POR ORDENADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 137
3.2.1. Descripción del tiempo y/o distintos tipos de simulación 139
3.2.1.1. Simulación dirigida por el paso del tiempo 139
3.2.1.2. Simulación dirigida por eventos discretos. . . . . . . . .. 139
3.2.1.3. Modelos de avance del tiempo. . . . . . . . . . . . . . . . . .. 142
3.2.2. Estructura general de la simulación 143
3.2.3. Aproximación metódica a la simulación 144
3.2.3.1. Modelado 144
3.2.3.2. Prueba...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 145
3.2.3.3. Explotación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 146
3.3. PROCESADO DE UN LENGUAJE DE PROGRAMACIÓN .. . . . . . . . . . . . . . . .. 146
3.3.1. Procesadores de lenguajes. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 146
3.3.2. Compiladores Software, Hardware e híbridos. . . . . . . . . . . . .. 148
X Contenido
3.3.3. Especificación de un lenguaje de programación. . . . . . . . . . .. 150

3.3.3.1. Sintaxis..................................... 150
3.3.3.2. Restricciones de contexto. . . . . . . . . . . . . . . . . . . . . .. 152
3.3.3.3. Semántica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 153
3.3.4. Proceso de compilación de un lenguaje de programación 153
3.4. SIMULACIÓNDE UNAENTIDADDE DISEÑOVHDL 154
3.4.1. Procesado de una descripción VHDL 155
3.4.1.1. Análisis de una unidad de diseño VHDL . . . . . . . . . .. 156
3.4.1.2. Elaboración de una jerarquía de diseño VHDL 158
3.4.1.3. Simulación de una entidad de diseño VHDL . . . . . . .. 163
3.4.1.4. Modelo Temporal &.delay 165
3.4.1.5. Determinismo en VHDL 165
3.4.1.6. Ejecución secuencial o concurrente. . . . . . . . . . . . . .. 167
3.4.2. Simulador VHDL 168
3.5. MODELADOEN VHDL PARASIMULACIÓN.. . . . . . . . . . . . . . . . . . . . . .. 171
3.5.1. Simulación lógica, temporal y de fallos . . . . . . . . . . . . . . . . .. 173
3.6. EJERCICIOS 175
3.7. BIBLIOGRAFÍA............................................. 176
4. SÍNTESIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 179
4.1. INTRODUCCIÓN 180
4.1.1. Proceso de síntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 181
4.1.2. Modelado para simulación frente a modelado para síntesis. .. 190
4.1.3. Objetivos........................................... 192
4.2. APLICACIÓNDE VHDL EN SÍNTESIS 192
4.2.1. Restricciones sintácticas y semánticas. . . . . . . . . . . . . . . . . . .. 193
4.2.2. Discrepancias entre resultados de simulación. . . . . . . . . . . . .. 194
4.3. SíNTESISRT-LÓGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 195
4.3.1. Síntesis lógica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 196
4.3.2. Síntesis RT ".................. 196
4.4. DESCRIPCiÓNVHDL DE CIRCUITOSDIGITALES 199
4.4.1. Descripción del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 199
4.4.2. Modelado de la información 200
4.4.3. Funciones y operadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 201
4.4.4. Paquetes de síntesis P1076.3 201
4.4.4.1. Interpretación hardware de tipos estándar . . . . . . . . .. 202
4.4.4.2. Expresiones de valor inicial y por defecto . . . . . . . . .. 205
4.4.4.3. Detección de la transición activa de la señal de reloj .. 206
4.4.4.4. Paquetes aritméticos . . . . . . . . . . . . . . . . . . . . . . . . . .. 206
4.4.5. Descripción de lógica combinacional 210
4.4.6. Descripción de «latches» . . . . . .. 217
4.4.7. Descripción de la señal de reloj y de registros 218
4.4.8. Registros........................................... 219
4.4.8.1. Registros de desplazamiento 223
4.4.8.2. Contadores 223
Contenido xi
4.4.9. Descripción de FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 226

4.4.10. Descripción de FSMDs 235
4.4.11. Segmentación 236
4.5. RECOMENDACIONES GENERALES 238
4.5.1. Recomendaciones para síntesis 239
4.5.1.1. Descripción de «hardware» 239
4.5.1.2. Limpieza del código. . . . . . . . . . . . . . . . . . . . . . . . . .. 240
4.5.1.3. Correspondencia entre simulación y síntesis 241
4.5.1.4. Conocimiento de la herramienta 241
4.6. EJERCICIOS 242
4.7. BIBLIOGRAFÍA.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 246
5. MODELADO CON VHDL 249

5.1. INTRODUCCIÓN ...•.............••......•...•.••........... 250
5.2. EL MODELADO DE UN SISTEMA A DIFERENTES NIVELES DE DETALLE ..... 251
5.2.1. Tipos de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 251
5.2.2. Expresión del tiempo y paralelismo . . . . . . . . . . . . . . . . . . . . .. 252
5.2.3. Estilos de descripción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 253
5.3. MODELADO FUNCIONAL 254
5.3.1. La máquina rudimentaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 260
5.3.1.1. Arquitectura del procesador a nivel de lenguaje má-
quina 260
5.3.1.2. Modelo funcional de la máquina rudimentaria. . . . . .. 263
5.4. MODELADO ESTRUCTURAL 270
5.4.1. La máquina rudimentaria: interfaz y primer particionado 271
5.4.2. Bancos de pruebas 286
5.4.2.1. Bancos de pruebas como descripciones estructurales
del sistema 287
5.4.2.2. Bancos de pruebas para verificar las especificaciones. 289
5.4.2.3. Análisis de las respuestas. . . . . . . . . . . . . . . . . . . . . .• 290
5.4.3. La máquina rudimentaria: el banco de pruebas 292
5.5. MODELADO DETALLADO 294
5.5.1. Modelado para síntesis vs modelado para simulación 295
5.5.2. El modelado del tiempo 295
5.5.3. La comprobación de errores 301
5.5.4. El modelado detallado de la Máquina Rudimentaria 303
5.5.4.1. La Unidad de Proceso 304
5.5.4.2. La Unidad de Control. . . . . . . . . . . . . . . . . . . . . . . . .. 326
5.5.4.3. La memoria de programas. . . . . . . . . . . . . . . . . . . . . .. 340
5.6. EJERCICIOS 346
5.7. BmLIoGRAFÍA ....•........................................ 348
6. LA GESTIÓN DEL DISEÑO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 349

6.1. INTRODUCCIÓN 350
xii Contenido
6.1.1. Un proceso ideal de diseño en VHDL 351

6.1.2. El proceso real de diseño en VHDL . . . . . . . . . . . . . . . . . . . . .. 352
6.1.3. Orientación y objetivos del capítulo 353
6.2. PLANIFICACIÓN DE UN DISEÑO DESCENDENTE. . . . . . . . . . . . . . . . . . . . .. 354
6.2.1. Elflujo de diseño 355
6.2.2. De los requisitos a las especificaciones . . . . . . . . . . . . . . . . . .. 359
6.2.2.1. Los requisitos ... . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 359
6.2.2.2. Las especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . .. 362
6.2.3. El diseño arquitectural y lógico. . . . . . . . . . . . . . . . . . . . . . . .. 374
6.2.3.1. Desarrollo del diseño arquitectural. . . . . . . . . . . . . . .. 375
6.2.3.2. La revisión del diseño arquitectural. . . . . . . . . . . . . .. 381
6.2.3.3. Desarrollo del diseño lógico. . . . . . . . . . . . . . . . . . . .. 385
6.2.3.4. La revisión del diseño lógico .. . . . . . . . . . . . . . . . . .. 390
6.2.4. El diseñofisico y lafabricación . . . . . . . . . . . . . . . . . . . . . . . .. 391
6.2.5. La validación y caracterización del circuito 392
6.2.6. Documentación, evaluación y seguimiento del proyecto . . . . .. 394
6.3. DESARROLLO y ORGANIZACIÓN DE BmLlOTECAS EN VHDL . . . . . . . . . .. 394
6.3.1. Bibliotecas y componentes de biblioteca 396
6.3.2. La biblioteca de diseño 399
6.3.3. Gestión de bibliotecas. Versiones y configuraciones. . . . . . . .. 401
6.3.3.1. Control de versiones. . . . . . . . . . . . . . . . . . . . . . . . . .. 402
6.3.3.2. Control de configuraciones 403
6.4. DISEÑO PARA REUSABIliDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 405
6.4.1. ¿Por qué hacer diseños reutilizables? .. . . . . . . . . . . . . . . . . .. 406
6.4.2. La comercialización de una biblioteca. . . . . . . . . . . . . . . . . . .. 407
6.5. DISEÑO GENÉRICO .................•........................ 410
6.5.1. Definición de diseño genérico 410
6.5.2. Ventajas e inconvenientes del diseño genérico. . . . . . . . . . . . .. 413
6.5.3. Desarrollo de componentes genéricos. Recomendaciones .... 415
6.5.3.1. Organización del diseño. . . . . . . . . . . . . . . . . . . . . . .. 416
6.5.3.2. Selección de parámetros. . . . . . . . . . . . . . . . . . . . . . .. 419
6.5.3.3. Particionado del diseño 422
6.5.3.4. Estructuras de datos 423
6.5.3.5. Otras recomendaciones sobre la codificación 425
6.6. DISEÑOS CONFIGURABLES 431
6.6.1. Desarrollo de un componente configurable. . . . . . . . . . . . . . .. 432
6.6.1.1. Selección de los parámetros de configuración . . . . . .. 433
6.6.1.2. Aspectos a considerar en la generación de componentes
configurables en VHDL . . . . . . . . . . . . . . . . . . . . . . .. 433
6.6.1.3. Diseño arquitectural. . . . . . . . . . . . . . . . . . . . . . . . . .. 434
6.6.1.4. Método de generación 435
6.6.1.5. Bancos de prueba . . . . . . . . . . . . . . . . . . . . . . . . .. 437
6.7. EJERCICIOS 438
6.8. BmLIOGRAFÍA ' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 440
Contenido xiii
APÉNDICE 1 443
APÉNDICE 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 461
GLOSARIO 487
ÍNDICE 491
Presentación
Fernando Aldana Mayor, Rafael Burriel Lluna y Carlos López Barrio
Uno de los inconvenientes que genera la evolución muy rápida de la tecnología en un

determinado campo, es la gran dificultad que tienen los profesionales del sector para
adaptarse a los cambios en los métodos, procedimientos y herramientas. Como resul-
tado de estos efectos, las empresas dedican cada vez más recursos a sus actividades
de formación continua.
Nuestra sociedad de la información se sustenta sobre el desarrollo microelectró-
nico, que permite diseñar y fabricar a un ritmo vertiginoso sistemas electrónicos cada
vez más complejos a costes muy razonables; pero ese aumento de la complejidad
sobre el que se apoya el desarrollo ha exigido modificar, casi diría revolucionar, los
procedimientos de diseño y fabricación.
Las metodologías de diseño electrónico denominadas "top-down", basadas en el
empleo de lenguajes de descripción de hardware, han transformado los procedimien-
tos de diseño de sistemas electrónicos, muy especialmente de circuitos integrados. El
lenguaje VHDL es su más claro exponente, abriendo enormes posibilidades al per-
mitir la simulación con descripciones de partes del sistema con diferentes niveles de
abstracción. Esto, unido a la posibilidad de realizar la síntesis automática, y a la con-
cepción de bloques reutilizables y reconfigurables en función de las necesidades de
la aplicación, ha permitido dotar al diseñador de enormes recursos que hacen posi-
ble abordar la creciente complejidad con mayores garantías de éxito.
Admitidas las ventajas, ha sido necesario adaptar la formación de los ingenieros
de diseño y test, pasando de un perfil claramente electrónico, orientado a la interco-
nexión de bloques hardware, a un perfil más algorítmico, más informático, conse-
cuencia de los nuevos procedimientos. En el marco de esa demanda de formación
xv
xvi Presentación
aparece este libro, dando satisfacción a una necesidad bien identificada entre los téc-
nicos de habla hispana.
Se trata de una obra que recoge los temas fundamentales vinculados a la utiliza-
ción del lenguaje VHDL, tratando los fundamentos de la sintaxis, describiendo los
mecanismos de simulación, las técnicas de modelado y la síntesis. No es un libro
más que nos describe exhaustivamente la sintaxis del lenguaje, como si se tratara de
un manual de referencia, sino que pretende abordar el problema de forma concep-
tual, destacando los elementos clave en el empleo de la metodología basada en
VHDL.
Es un texto más para ingenieros de diseño que para especialistas en lengua-
jes de sistemas informáticos. Está indicado para estudiantes de ingeniería con una
buena formación de base en electrónica e informática o estudiantes de los últimos
cursos de carrera. Este libro también podría emplearse en actividades de post-
grado, orientadas a la formación de profesionales en la empresa o a un curso de
doctorado.
El enfoque del libro está avalado por la experiencia contrastada de los autores en
su actividad diaria, por la combinación de profesionales de la empresa, profesores
universitarios e investigadores en microelectrónica.
En síntesis, este trabajo supone una aportación valiosa en el proceso de adapta-
ción tecnológica a unas circunstancias cambiantes, que han exigido, exigen yexigi-
rán esfuerzo e imaginación a los profesionales de un sector tan dinámico como es la
microelectrónica.
FERNANOO ALOANA MAYOR

Catedrático de Tecnología Electrónica
ETSll. Universidad Politécnica de Madrid
Agradezco el esfuerzo que este equipo de autores ha dedicado a la formación y

divulgación del VHDL, tanto en el contexto académico como en el industrial. Esta
aportación contribuye indudablemente a la creciente y fructífera relación entre
ambos entornos.
Existe un inevitable proceso del ser humano tendente a eliminar su propia inter-
vención en cualquier actividad que, paradójicamente, comienza él mismo. Esto tam-
bién ha ocurrido en el campo del diseño de Circuitos Integrados de Aplicación Espe-
cífica «ASICs» con la introducción del VHDL.
Los objetivos de este proceso están motivados por el necesario intento de elimi-
nar los errores introducidos por el «escasamente fiable individuo», aumentar sustan-
cialmente su productividad a fin de poder manejar los centenares.demiles de puertas,
¡ya son millones!, dentro de un tiempo industrialmente viable, así como operar de
forma jerarquizada y eficiente con semejante volumen de información de forma que
sea factible su manejo y transferencia. La existencia de una documentación fiable
tanto de una biblioteca de células, de ASICs completos, de su especificación para su
posterior reutilización para una nueva síntesis, constituye también un imprescindi-
ble condicionante económico empresarial.
Presentación xvii
Actualmente, la mayor fuente de errores en la integración procede habitual-

mente de defectos en la especificación del ASIC, que podrían haberse evitado
mediante la utilización de un lenguaje formal, apto para su simulación y posterior
síntesis, capaz de incorporar ficheros tecnológicos y criterios de integración necesa-
rios para eliminar las ambigüedades existentes en la misma; esto obliga a una sólida
coherencia en la fase de especificación. De hecho, empresas relevantes ya han estado
formando a sus ingenieros de marketing en VHDL para mentalizarlos con el posible
lenguaje con el que sus clientes podrían solicitarles futuros productos.
Actualmente ya se dispone, y se continúan desarrollando, de múltiples ayudas
por ordenador que, basándose en estas descripciones VHDL, incorporarán ayudas
complementarias para un posicionado óptimo de bloques, trazados inteligentes, esti-
mación y posterior verificación de caminos críticos, síntesis con optimización inte-
ractiva de área, velocidad y arquitecturas, inserción automática de capacidad de diag-
nóstico, generación automática de patrones de prueba, consumo, etc. y finalmente un
paso que es inevitable para el diseño de ASICs más complejos: el desarrollo de
herramientas y entornos de Co-Diseño HW y SW para la optimización en la distri-
bución de tareas, emulación, simulación y finalmente realización. Realmente el
VHDL se está convirtiendo en el lenguaje universal de la microlectrónica (digital al
menos) aunque no hay que olvidar ni los huecos ni los electrones con sus «capri-
chos», y es necesario no perder el contexto eléctrico y electrónico de la realidad, ni el
objetivo industrial de la integración en cuanto a coste, plazo, consumo, interfaz con
el mundo real, etc.
Así, la introducción del VHDL está eliminando, prácticamente, las tradiciona-
les técnicas de diseño basadas en células de biblioteca, captura de esquemas, etc.,
para los ASICs digitales; el mundo analógico con una mayor componente artística,
artesanal y de intuición todavía se resiste a la disciplina de la formalización VHDL,
que por otra parte aún no está completamente disponible.
El diseño de Circuitos Integrados a la Medida (antiguos circuitos LSI o VLSI, y
posteriormente ASICs) ha adolecido desde sus comienzos a principios de la década
de los setenta de facilidades para que las empresas establezcan un interfaz industrial
adecuado y sólido para migrar un diseño realizado con una determinada biblioteca de
células de un fabricante, a otra de otro fabricante, lo que se denomina «segunda
fuente» y tiene una definida componente estratégica.
Otro aspecto igualmente importante lo constituye la necesaria transferibilidad a
una empresa, de diseños, arquitecturas o desarrollos de ASICs realizados por cen-
tros externos a dicha empresa -por ejemplo a través de Programas Comunitarios-
la cual necesita reutilizarlos total o parcialmente para su posterior incorporación a
integraciones (ASICs) de mayor escala en su propio entorno. La reutilización es un
factor muy importante con una positiva repercusión económica en la industria. En
estos momentos, las herramientas que permiten un interfaz industrial adecuado
entre socios se basan en VHDL, el cual permite una eventual síntesis en otro con-
texto tecnológico.
Así, la incorporación del lenguaje VHDL a la realización de ASICs ha consti-
tuido un hito importante y decisivo para la industria en cuanto a productividad y a
transferibilidad se refiere, ya que ha aumentado la productividad de los diseñadores
de forma sustancial y se ha facilitado la utilización de herramientas industriales de
xviii Presentación
síntesis a las empresas. Su campo de aplicación apenas ha comenzado y permitirá la

integración de los mil millones de puertas, tal como se anuncia, al final de la
siguiente década y ...
RAFAEL BURRIEL LLUNA

Centro de Investigación y Desarrollo de Aleatel España
La evolución de la tecnología microelectrónica ha sido tan rápida y profunda durante

la última década y media que ha posibilitado el que hoy podamos fabricar circuitos
integrados de elevada complejidad. Este hecho, unido a las demandas del mercado
por reducir los ciclos y costes de desarrollo, plantea unos retos importantes en el
campo del diseño y de las herramientas de ayuda y automatización del mismo.
Así, el enfoque con el que se diseñan los circuitos integrados ha tenido que ir
evolucionando a través de varios niveles de abstracción. Del diseño geométrico del
circuito y resolución de las ecuaciones diferenciales, se pasó al diseño con transis-
tores ayudado por simulación eléctrica, para evolucionar posteriormente hacia el
diseño lógico con ayuda de editores de esquemas y simulación lógica y eléctrica,
hasta llegar finalmente a la actual metodología, basada en la descripción del com-
portamiento de los circuitos mediante lenguajes de descripción hardware, simula-
ción a nivel de comportamiento y utilización de herramientas de síntesis lógica.
Esta metodología y herramientas asociadas son, hoy en día, instrumentos básicos y
sería impensable el diseño de circuitos de la complejidad de los actuales sin este
tipo de ayudas. Es por ello que su conocimiento resulta obligado para todos aque-
llos profesionales que están de alguna manera ligados al mundo de los circuitos
integrados.
La correcta realización de las fases de alto nivel es probablemente la tarea más
importante en el diseño de un circuito. Las decisiones de arquitectura son las que tie-
nen un mayor impacto en todos los parámetros de los circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores se tienen que realizar siempre impor-
tantes contribuciones al diseño, es difícil que optimizaciones realizadas en dichas
fases puedan compensar una mala selección de la arquitectura de un circuito.
La c'Orrecta realización de las fases de alto nivel es probablemente la tarea más
importante en el diseño de un circuito. Las decisiones de arquitectura son las que tie-
nen un mayor impacto en todos los parámetros de los circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores se tienen que realizar siempre impor-
tantes contribuciones al diseño, es difícil que optimizaciones realizadas en dichas
fases puedan compensar una mala selección de la arquitectura de un circuito.
El diseño de alto nivel es además el punto de encuentro de los diseñadores de
sistemas y de circuitos. Ambos deben aportar sus contribuciones, bien desde el cono-
cimiento de las aplicaciones bien desde el de la tecnología. Por ello este libro está
dirigido a un amplio grupo de profesionales, desde los diseñadores de sistemas, que
ven la necesidad de incorporar las últimas tecnologías microelectrónicas, hasta los
diseñadores de circuitos, pasando por supuesto por los estudiantes interesados en
estas materias.
Presentación xix
Todo lo anterior tiene como piedra angular la utilización de los ya mencionados

lenguajes de descripción hardware. De todos ellos, el VHDL, definido como un
estándar, ha ido ganando fuerza tanto en el mundo universitario como industrial. De
ahí el interés de este libro concentrado en analizar todos los aspectos de dicho len-
guaje. En esta línea el libro ofrece un planteamiento sencillo y pragmático, presen-
tando no sólo la sintaxis del lenguaje VHDL, sino también gran cantidad de detalles
prácticos y ejemplos que facilitan la compresión de los conceptos. Por otra parte, el
último capítulo incluye una referencia sobre consideraciones prácticas de la gestión
de un diseño que puede resultar de especial relevancia para los diseñadores de siste-
mas que se quieren adentrar en el mundo de la microelectrónica. Muchos de los
aspectos allí reseñados son tristemente olvidados en casi todos los manuales técni-
cos, y deben ser aprendidos con gran esfuerzo a través de la experiencia.
Hemos de felicitamos por esta iniciativa de un amplio grupo de profesionales
de nuestro país, tanto del mundo académico como industrial, por volcar en este texto
la experiencia acumulada a lo largo de años de trabajo docente, de diseño, de inves-
tigación y de cooperación en el marco del Grupo Español de Usuarios de VHDL, así
como por contribuir a disponer de bibliografía microelectrónica en español, la cual,
tristemente, es muy escasa.
Estoy seguro de que este libro servirá como referencia a muchos diseñadores ya
experimentados, pero también constituye un excelente texto para un curso de grado o
postgrado universitario. Espero, por tanto, no sólo que el lector disfrute con su lec-
tura, sino que nos ayude también a difundir los conocimientos básicos sobre las téc-
nicas de diseño microelectrónico.
CARLOS A. LÓPEZ BARRIO

Catedrático de Tecnología Electrónica (ETSIT-UPM) y
Director de Innovación (Telefónica I + D)
Prólogo
La evolución de la microelectrónica desde su nacimiento ha sido impresionante. En

poco más de diez años se pasó del primer dispositivo integrado (jlip-flop con unos po-
cos transistores) a las primeras memorias y procesadores. A los pocos años, el diseño
de circuitos integrados salió de las fábricas y se hizo accesible a los ingenieros de apli-
cación, dando lugar a los ASIC (Application Specific Integrated Circuit). Ya entonces,
mediados de los años ochenta, se puso de manifiesto la necesidad de disponer de un
lenguaje estándar capaz de dar el soporte necesario al proceso completo de diseño de
chips y sistemas electrónicos (desde la idea hasta la implementación y explotación
de un desarrollo) en sus distintas etapas y niveles de abstracción y cuya complejidad,
ya de por sí elevada, se iba a incrementar drásticamente hacia los años noventa.
Estas inquietudes, canalizadas a través del DoD (Dpt. of Defense) de los EEUU,
llevan al nacimiento del VHDL (1987), que, tras ser adoptado como estándar del IE-
EE (Std.-I076-1987), se presenta como el lenguaje estándar por excelencia del dise-
ño electrónico. Ya desde el primer momento se convirtió en la herramienta y el mo-
tor de base que ha facilitado e impulsado los enormes avances de las metodologías,
técnicas y herramientas CAD de diseño electrónico de los últimos diez años. Esta
evolución arrastra al propio Verilog, ahora también convertido en estándar del IEEE
(Std.-1364-1995), que se ha convertido en competidor y compañero de viaje de
VHDL.
En definitiva, y aunque sólo debamos considerar al VHDL como una herra-
mienta de base, la implantación de este lenguaje ha supuesto tal cantidad de cambios
en el diseño electrónico (nuevas metodologías de diseño de alto nivel y flujos des-
cendentes, herramientas CAD de simulación/síntesis de circuitos y sistemas, nuevos
xxi
xxii Prólogo
perfiles de los equipos de diseño, cambios en la organización y desarrollo de proyec-

tos, etc.), que, sin lugar a dudas, se puede hablar de un antes y un después del VHDL.
La idea de desarrollar este libro surge en el seno del Grupo Usuarios de VHDL
de España (GUVE) y se asienta sobre la base de una larga trayectoria de colabora-
ción entre los distintos coautores y sus respectivos centros. Durante los últimos años
esta estrecha relación se ha vehiculado en repetidas ocasiones a través del programa
GAME (Grupo Activador de la Microelectrónica en España) de la Comisión Euro-
pea, y en especial alrededor de uno de sus últimos proyectos: PRENDA (PRoyecto
para la Estandarización y Normalización del Diseño de ASIC's). Así pues, la con-
vergencia de algunos proyectos, la motivación, experiencia y colaboración de los co-
autores y sobre todo el constante estímulo del GUVE para promover y facilitar la di-
fusión e implantación de estas nuevas técnicas de diseño electrónico, son las bases
que han dado lugar a este libro.
El libro que aquí les presentamos se ha concebido, no sólo para presentar y dar
a conocer el lenguaje VHDL, sino que además condensa en unos pocos capítulos las
distintas facetas del mismo y su explotación dentro del proceso de diseño. En este
sentido podemos decir que se trata de una guía aplicada del VIÍDL, siendo a su vez
altamente autocontenido.
Así pues, tras la ubicación de estos lenguajes dentro de la evolución del diseño
electrónico (Capítulo 1), se procede a una presentación del lenguaje VHDL (Capítu-
lo 2) que, sin ser exhaustiva, es muy completa y detallada, basándose en numerosos
ejemplos que facilitan la comprensión íntima del lenguaje.
A continuación en el Capítulo 3 se estudian en detalle el procesado del lenguaje
y los mecanismos de simulación que permitirán al lector extraer criterios de mode-
lado para aplicar de forma eficiente en las descripciones para simulación en VHDL.
Por su parte, la síntesis desde el VHDL es, junto con la simulación, una de las prin-
cipales aplicaciones del lenguaje. El Capítulo 4, tras un análisis general sobre el uso
de estos lenguajes en los procesos de síntesis, se dedica a detallar la utilización del
VHDL a nivel de síntesis RT-lógica en base a los métodos y herramientas CAD ac-
tuales. Ello, junto con un conjunto de recomendaciones de modelado para síntesis,
proporcionará al lector los conocimientos y criterios necesarios para un modelado
eficiente para la síntesis.
En el Capítulo 5 se muestra la utilización del VHDL en distintos aspectos del
modelado de sistemas electrónicos (modelado del diseño y del entorno de test, simu-
lación versus síntesis, etc.). Es una presentación muy aplicada que se apoya en el de-
sarrollo de un ejemplo completo: un pequeño procesador y su entorno. Es un ejemplo
sencillo cuyo recorrido permite consolidar unos conocimientos prácticos muy difíci-
les de asumir exclusivamente desde un plano teórico, que también se presenta. Por
último el Capítulo 6, también muy aplicado, nos enfrenta, desde la perspectiva del
VHDL, a toda una serie de cuestiones relativas a la organización y gestión del diseño
que raramente se comentan en los textos, pero cuyo tratamiento puede, en buena me-
dida, garantizar el éxito y la calidad del diseño si es el adecuado, o ser causa de fra-
caso si no se le considera convenientemente.
Estos seis capítulos se complementan con sus respectivos apartados de ejerci-
cios, dos apéndices y un glosario que ayudan a disponer de un texto más autocon-
tenido y detallado si se requiere, pero sin cargar demasiado la obra central. Así
Prólogo xxiii
mismo, y con el fin de mantener una cierta dinámica viva e interactiva alrededor
de este libro, se han organizado algunas páginas de Internet en la dirección
http://www.cnm.es./IMB/LibroVHDU. donde, además de la presentación del libro,
se pueden encontrar ejercicios resueltos, los códigos VHDL completos de los pro-
yectos utilizados en el libro y algunas secciones complementarias, donde el lec-
tor dispondrá de su propio espacio para comentarios y aportaciones, que se irán
actualizando periódicamente.
Así pues, vemos que se trata de un texto dirigido tanto a los estudiantes y profe-
sores de cualquier titulación que incluya materias de diseño electrónico como a los
profesionales del sector. Todos ellos encontrarán en este libro un punto de referencia,
ya sea para iniciarse en el lenguaje y sus aplicaciones, o para aclarar y consolidar
conceptos y asesorarse en el desarrollo de proyectos basados en el uso de estos len-
guajes, y los métodos y técnicas de diseño que de ellos se derivan.
En cuanto a los coautores de los distintos capítulos, sólo decir que se trata de un
colectivo de expertos en diseño electrónico y en la aplicación de estos lenguajes. La
mayor parte de ellos desarrollan su actividad en el ámbito académico y de investiga-
ción, pero todos poseen además una amplia experiencia en desarrollos industriales.
Forman parte del colectivo de profesionales que, desde el nacimiento de estos len-
guajes, se han esforzado y comprometido en su difusión, uso e implantación tanto a
nivel académico como en el contexto industrial.
Los AUTORES
http://www.cnm.es.nMB/LibroVHDU
Capítulo 1
,
INTRODUCCION
Llnís Terés, Mane) Moré, Eduard Lecha, Fernando Rincón y Joan Vida)
IMB-CNM (CSIC)
Universitat Autónoma de Barcelona
Para avanzar
no es necesario correr,
sólo dar el primer paso
y caminar sin miedo ...
El objetivo de esta breve presentación es mostrar qué son los lengua-

jes de descripción de hardware (HDL, Hardware Description Lan-
guages), cuándo y cómo aparecen dentro de la evolución del diseño
electrónico y cuáles son las principales aportaciones de tales lengua-
jes, así como su incidencia en el propio proceso de diseño.
Además de presentar brevemente la evolución del desarrollo
electrónico, en este capítulo se trata de ubicar el VHDL NHSIC Hard-
ware Description Language; donde VHSIC: Very High Speed Integra-
ted Circuits) en el contexto del diseño electrónico, su origen, evolu-
ción (impacto sobre las técnicas EDA, Electronic Design Automation)
y ámbitos de aplicación (modelado, simulación, síntesis y gestión del
diseño). De hecho el resto del libro tratará de hacer una presentación
más o menos detallada del VHDL (Capítulo 2) y su uso en tales ámbi-
tos de aplicación (Capítulos 3, 4, 5 Y 6). El texto se completa con una
serie de ejercicios para cada capítulo, la sección de bibliografía, el
glosario terminológico y apéndices que dan al libro un carácter más
autocontenido.
1
2 VHDL. Lenguaje estándar de Diseño Electrónico
1.1. EVOLUCiÓN DEL DISEÑO ELECTRÓNICO
El desarrollo electrónico de los últimos tiempos se ha visto fuertemente dominado y

conducido por la impresionante evolución de la microelectrónica desde su naci-
miento en 1959-60. Durante los años setenta, junto con la revolución que suponen
las memorias RAM y procesadores en forma de chip monolítico, se preparan las
condiciones para el gran salto que el diseño microelectrónico dará en los años
ochenta [Que88, Ser94].
El desarrollo de nuevas tecnologías y alternativas de fabricación y diseño de
circuitos integrados, junto con la evolución de las metodologías y herramientas de
diseño asistido por ordenador, han sido las innovaciones más importantes de la déca-
da de los ochenta [IEEE81, JSV82, Rub87, Ter86, PL88, Gaj88, Gia89]. Éstas se
han reflejado tanto en el continuo incremento de la complejidad y prestaciones de
los chips, y por ende de los sistemas electrónicos, como en la gran difusión de las
técnicas, metodologías y herramientas de diseño de circuitos integrados que, junto
con las nuevas alternativas de fabricación, han ampliado el rango de posibilidades de
los ingenieros de aplicación, permitiéndoles diseñar chips específicos (Application
Specific Integrated Circuits, ASICs) [NB88] para los productos que desarrollan.
Todos estos factores han contribuido directamente a la evolución de los recur-
sos de cálculo (procesadores, estaciones de trabajo, ...) quienes a su vez tienen una
< 10 pág.
Niveles:
- Eléctrico
- Bits (disp.prog.FPGA)
- Geométrico (Cls)
FIGURA 1-1. Pirámide de complejidad y niveles de abstracción de las distintas fa-

ses del diseño electrónico.
1. Introducción 3
incidencia decisiva en el desarrollo de nuevas herramientas y entornos integrados de

diseño de sistemas electrónicos. Con el desarrollo y uso de tales herramientas para
crear nuevos componentes se cierra el ciclo del soporte mutuo entre ambas tecnolo-
gías: microelectrónica e informática.
La Figura 1-1 esquematiza cómo a partir de las especificaciones de un circui-
to' y a fin de poder proceder a su fabricación, el proceso de diseño de CIs atraviesa
tres etapas o dominios diferentes: funcional o comportamental (algoritmos y fun-
ciones que indican la relación o comportamiento entrada/salida, E/S, pero no su
implementación), arquitectural (componentes funcionales interconectados que de-
finen la arquitectura/estructura de la implementación sin detallar la realización físi-
ca final) y físico (se detalla una materialización concreta a nivel eléctrico y geomé-
trico para una determinada tecnología). Obsérvese que la complejidad del diseño
en términos de volumen de información a manejar aumenta drásticamente a medi-
da que avanzamos por estas fases, al incrementar la precisión y disminuir el nivel
de abstracción.
En este contexto, las metodologías yherramientas de CAD han seguido una
evolución ascendente (bottom-up), para tratar de implementar procesos de diseño
descendentes (top-down).
En el resto de esta sección sobrevolaremos los años setenta, ochenta y noventa
mencionando el tipo de tecnologías, circuitos, metodologías, CAD (Computer Aided
Design) y plataformas hardware/software que se han ido desarrollando en cada épo-
ca, resumiendo de esta forma la evolución de la microelectrónica.
1.1.1. Años setenta
Durante esta década hay una fuerte evolución de los procesos de fabricación de cir-
cuitos integrados y junto a las tecnologías bipolares surgen las MOS (Metal-Oxide-
Semiconductor). Estas últimas, bajo la forma de NMOS, mantienen una cierta hege-
monía en el desarrollo de circuitos digitales hasta la primera mitad de los años
ochenta; mientras que los circuitos analógicos se basaban mayoritariamente en las
tecnologías bipolares [Que88, Ser94].
Ya fuesen circuitos digitales o analógicos, éstos se desarrollaban con el objeti-
vo de ser componentes estándar para su posterior uso en el diseño de sistemas elec-
trónicos específicos. Tales circuitos integrados se desarrollaban completamente (di-
seño y fabricación) dentro de las propias fábricas (joundries) sin que este nivel de
diseño fuese accesible fuera de dicho contexto.
El esfuerzo de diseño se concentraba en los niveles eléctrico (establecer carac-
terísticas e interconexiones de los componentes básicos a nivel de transistor) y to-
pográfico (dibujar las máscaras, layout, necesarias para la fabricación de los dispo-
sitivos y sus interconexiones). El proceso de diseño era altamente manual y a la
medida de las posibilidades de cada tecnología. No existía prácticamente ninguna
herramienta CAD de ayuda al diseño, a excepción del SPICE [Nag75], simulador
de esquemas eléctricos con modelos personalizables para distintas tecnologías y
que ha sobrevivido al paso del tiempo, pues todavía hoy se utiliza él o sus descen-
dientes directos.
A pesar de estas dificultades surgieron las primeras memorias DRAM de 1

Kbit (1970) y el procesador 4004 de 4 bits (1971). Ambos dispositivos correspon-
den a la entonces recién creada INTEL, que los desarrolló en tecnología PMOS. A
finales de los setenta estos dispositivos ya habían evolucionado hacia memorias de
16 Kbits y procesadores de 16bits (8086), desarrollados ya mediante tecnologías
NMOS. Este tipo de componentes revolucionaron el desarrollo de sistemas elec-
trónicos y plataformas hardware y facilitaron, hacia finales de esta década, el naci-
miento de los miniordenadores, que desbancaron a los grandes ordenadores (main-
frames) de los años setenta [Hay79, Roi86, Ser94].
1.1.2. Años ochenta

A la vez que los procesos tecnológicos se hacían más complejos para poder asumir
mayores densidades de integración se había ido identificando el conjunto básico de
información que se necesita conocer a fin de poder realizar diseños para una deter-
minada tecnología, esto es: parámetros eléctricos de los distintos componentes acti-
vos y pasivos para poder definir esquemas eléctricos y las reglas de diseño geomé-
trico para poder dibujar la topología del circuito. Estas estrategias para independi-
zar el proceso de diseño del proceso de fabricación empiezan a hacerse realidad de
la mano de Hon & Sequin [HS80], Conway & Mead [MC80] a finales de los años
setenta y con ello el diseño de Cls comienza a hacerse accesible fuera del propio
contexto de las fábricas de semiconductores.
En ese momento se constata que hay un desfase enorme entre tecnología y di-
seño. La considerable complejidad de los chips que se pueden fabricar supone unos
riesgos y costes de diseño desmesurados e imposibles de asumir, debido a una ca-
rencia casi absoluta de metodologías y herramientas de diseño y a la inviabilidad
económica de aplicar técnicas de prototipado de circuitos impresos (Printed Circuit
Board, PCB), basadas en el desarrollo de maquetas (breadbording], para el diseño y
depurado de Cls.
A raíz de esta situación se inició una fuerte actividad sobre el desarrollo de me-
todologías y herramientas CAD para el diseño de CIs que ha cambiado drástica-
mente el contexto y los entornos de diseño, no sólo a nivel de Cls, sino también a
nivel de diseño electrónico global (Cls, ASIC, FPGA, PCB, MCMs ....), cubriendo
los distintos niveles de abstracción (funcional, arquitectural y físico) y mantenién-
dose como una de las áreas más activas del sector, tanto en términos de investiga-
ción, como a nivel de productos industriales.
En cuanto a tecnologías se mantienen las bipolares como las más utilizadas pa-
ra desarrollos analógicos o mixtos; mientras que en el diseño digital las CMOS (es-
tructuras complementarias basadas en transistores p y n sobre un mismo substrato)
se imponen claramente a las antiguas NMOS. Hacia finales de los ochenta nacen las
BICMOS, que permiten crear sobre un único substrato dispositivos bipolares y
CMOS facilitando así el desarrollo de circuitos mixtos analógico-digitales.
A nivel de circuitos, obviamente se siguen desarrollando componentes estándar
de mayor complejidad y prestaciones, pero la novedad de esta década son los
ASICs (Application Specific Integrated Circuit) [WE85, NB88, HR91], es decir,
7. Introducción 5
circuitos integrados desarrollados para aplicaciones específicas pudiendo ser dise-

ñados por los propios ingenieros de la aplicación.
Esta ampliación hacia el diseño microelectrónico se concreta en una serie de
nuevas alternativas de desarrollo que surgen durante esta década y que se pueden
agrupar cronológicamente en las cuatro categorías que se citan a continuación:
1. Diseño totalmente a medida (jull-custom). El diseñador se enfrenta a los ni-

veles eléctrico y geométrico que, como se ve en la Figura 1-1, son los de
mayor complejidad. Total libertad de diseño pero el desarrollo requiere de
todas las etapas del proceso de fabricación. Los riesgos y los costes son muy
elevados, sólo justificables para grandes volúmenes o para proyectos con
restricciones (área, velocidad, consumo, ... ) [HS80, MC80, WE85, GD85).
2. Matrices de puertas predifundidas (semi-customlgate-arrays). Existe una es-
tructura regular de dispositivos básicos (transistores) prefabricada que se
puede personalizar mediante un conexionado específico que sólo requiere de
las últimas etapas del proceso tecnológico. El diseño está limitado a las posi-
bilidades de la estructura prefabricada y se realiza en base a una biblioteca
de celdas precaracterizadas para cada familia de dispositivos [NB88, Ho187).
3. Celdas estándar precaracterizadas (semi-customlstandard-cells). No se tra-
baja contra ninguna estructura fija prefabricada, pero sí con bibliotecas de
celdas y módulos precaracterizados y específicos para cada tecnología. Bas-
tante libertad de diseño (en función de las facilidades de la biblioteca) pero
el desarrollo exige un proceso de fabricación completo [NB88, Hei88,
HR91).
4. Lógica programable (FPGA, CPLD). Se trata de dispositivos totalmente fa-
bricados y verificados que se pueden personalizar desde el exterior median-
te diversas técnicas de programación (RAM, fusibles, etc.). El diseño se ba-
sa en bibliotecas y mecanismos específicos de mapeado de funciones, mien-
tras que su implementación tan sólo requiere de una fase de programación
del dispositivo que habitualmente realiza el propio diseñador en unos pocos
segundos [Tri94].
Desde el punto de vista de diseño, las tres últimas alternativas son similares y
se centran en el diseño a nivel estructural en base a las respectivas bibliotecas de
celdas y, por lo tanto, sus flujos de diseño se pueden considerar idénticos, tal como
muestra la Figura 1-2, si tenemos en cuenta que cambian los procesos de diseño fí-
sico y que el test estructural es una parte muy importante del propio proceso de di-
seño de dispositivos full o semi-custom, mientras que no es necesario considerarlo
en el caso de los programables.
Como ya se ha indicado anteriormente, la evolución de los entornos de diseño ha
seguido un proceso ascendente (Bottom-up) que durante los años ochenta llegó a con-
solidar los niveles físico y lógico o de puertas. En primer lugar se abordó el nivel físi-
co y se desarrollaron a la par herramientas dirigidas a dos contextos distintos:
• El diseño eléctrico y geométrico de celdas y bloques básicos utilizando téc-
nicas de diseño a medida. Para ello fue necesario confeccionar entornos co-
mo el que se muestra en la Figura 1-3 [Oht86, Rub87).
ssa;]
Requisitos, restricciones y ,
-c I--
,
...- ..... _,.~
" especificaciones funcionales ,,

Zc
.2 - ............... -.- _- -- _ ... -
,
·Sa;
C"~
~ ::::J
Captura del diseño (esquemáticos) Biblioteca
astí de celdas
~E
.- (/)
CQ)
as...!.
oe
IC ::::J Simulaciones (pre/post-diseño físico):
Q)-
(/)0 Funcional-lógica, temporal, fallos
Ci-Sl
Ubicación y conexionado (layout)
Verificación y análisis
Fabricación
Producción
FIGURA 1-2. Flujo genérico de diseño ascendente (bottom-up) de circuitos semi-

custom: »sic« y FPGAs.
• Procesos de ubicación y conexionado (place&route) de celdas y bloques uti-

lizados dentro del flujo de diseño mostrado en la Figura 1-2 para generar la
topografía de un circuito a partir de su esquema de componentes y sus cone-
xiones (netlist) [PL88].
Asimismo hay procesos de verificación (eléctrica y geométrica) o comparación
de esquemas que están presentes en ambos contextos.
Posteriormente se abordó el nivel de puertas (también conocido en la época
como nivel estructural: componentes y conexiones) introduciendo la captura de es-
quemas, la simulación funcional y de faltas, el análisis de tiempos, la generación
de estructuras y vectores de test y los generadores de bloques regulares. La Figu-
t. Introducción 7
Editor Gráfico
Esquemas Máscaras
~~
~~
Extractor de lista de componentes y conexiones (Netlist)
Esquema (E) Topografía (T)
Estímulos
Condiciones
Modelos
Simulador Analógico (SPICE)
¡ ¡
Resultados (E) ?
FIGURA 1-3. Entorno de diseño a nivel eléctrico y geométrico para el desarrollo de

celdas o módulos fullcustom.
ra 1-2 muestra de forma muy genérica este flujo de diseño ascendente, que se ha
aplicado a partir de medianos de los años ochenta, donde el nivel funcional estaba
muy poco desarrollado y el mayor esfuerzo de diseño se concentraba en el nivel ar-
quitectural y de puertas, mientras que el nivel físico se consideraba altamente auto-
matizado.
La estructura de las herramientas de CAD también varió considerablemente
durante esta década pasando de tener que enfrentarse a distintas herramientas con
sus interfaces específicos para cubrir cada paso de flujo de diseño (Figura 1-4.a), a
poder disponer de entornos integrados de CAD donde bajo una única base de datos
y un único interface de usuario se aglutinaban y encadenaban las distintas herra-
mientas (Figura 1-4.b) [RW91, BHNS92].
V
IdUj
.
H,
BdDj
1
IdUI
H¡
I~.
BdD1
IdUk
~ Hk
BdDk
(a) (b)
IdU
Estándares
Lenguaje de Interface Entorno Informáticos
~e g.~ CAD; Electrónicos
c'C :::re.
:2 5l ... _.
CIlCll Mecánicos
ü):c
al al
0)-0
... P33.
3
_.ceCIl
ale CIl ...
-0._ ::::l III
_0
.'!:
::.:::
.2
~ ~ ~ !ll g:
Leng. de acceso y gestión
BdD
(e) (d)
H: Herramienta, idU: Interfaz de Usuario, BdD: Base de Datos, I/F: Interfaz
FIGURA 1-4. Evolución de las herramientas y entorno de CAD: (a) Herramientas

dispersas, cada una con su propia interfaz de usuario y su base de datos específica;
(b) Entorno integrado de CAD: herramientas compartiendo un único i/f de usuario y
la misma base de datos; (e) Entorno integrado, abierto y flexible de CAD: fácil inclu-
sión de nuevas herramientas y mecanismos de gestión de flujo de diseño; (d) Entor-
nos y herramientas trabajando con formatos estándar (CIF, EDIF, VHDL, SDF, ...) faci-
litan el intercambio de información y la configuración de flujos de diseño específicos
con las herramientas de CAD más adecuadas.
Todos estos avances empujaron y a la vez se apoyaron en la propia evolución

de las plataformas Hw/Sw. Los miniordenadores que fueron las estrellas de la pri-
mera mitad de los ochenta cedieron su terreno a las estaciones de trabajo (work-sta-
tions) durante la segunda mitad para empezar a trabajar a finales de esa década en
entornos de red con una todavía tímida presencia de los ordenadores personales
(personal computers, PC).
1. Introducción 9
1.1.3. Años noventa
A finales de los ochenta se consolidan los niveles estructural y físico, a la vez que
los desarrollos sobre dispositivos programables complejos (FPGAs, CPLDs,
FPLDs) empiezan a crecer en "importancia frente a los ASICs-custom. Con el naci-
miento del VHDL (1987) [IEEE88] se empiezan a desarrollar métodos y herra-
mientas para abordar el diseño a nivel funcional o comportamental, cuya implanta-
ción definitiva se está produciendo durante esta década de los noventa.
En cuanto a tecnologías de los años noventa, la CMOS sigue siendo la más uti-
lizada (75 por 100 del mercado) incluso creciendo. Las bipolareslECL se mantienen
alrededor del 15 por 100. Las BICMOS crecen hasta un 5 por 100. Las NMOS TTL
decrecen considerablemente, junto con las nuevas tecnologías del tipo AsGa y simi-
lares se reparten el 5 por 100 restante.
Por otra parte, durante esta década se están desarrollando nuevas tecnologías
de encapsulado cuyo máximo exponente son los módulos multichip (Multichip Mo-
dules, MCM) [JTB91, SK94, SM94, CL97] que en sus distintas versiones ofrecen la
posibilidad de montar directamente los chips en forma de dados sobre distintos ti-
pos de sustratos (cerámico, laminado o silicio), en los que previamente se habrán
implementado las conexiones entre los distintos chips. Ello permite aumentar las
prestaciones (velocidad, consumo) y reducir el tamaño de los sistemas electrónicos.
En general los MCM podríamos verlos como la evolución natural de los circuitos
híbridos pero con unas posibilidades y una complejidad potencial mucho mayor.
Otras tecnologías que están en fase de desarrollo pre-industrial son todas las re-
lacionadas con los microsistemas, donde junto a la microelectrónica se integrarán
sensores y actuadores de distintos tipos y funciones (químicos, mecánicos, etc.), ba-
sados en los mismos tipos de procesos de miniaturización que la tecnología micro-
electrónica [Ris94, Sze94].
En términos de circuitos se sigue con la misma tónica que al final de los ochen-
ta, con un continuo incremento de la complejidad, especialmente en dispositivos di-
gitales, y un claro aumento de la actividad en el diseño analógico y mixto (analógi-
co/digital) [GAS90, LS94]; basados estos últimos en las nuevas tecnologías BI-
CMOS. Los avances tecnológicos también permiten diseños mixtos (AlDIP) que in-
cluyen dispositivos de potencia [VRM+97].
A nivel de ASICs los desarrollos full y semi-custom han perdido relevancia frente
a las considerables prestaciones y complejidades que los dispositivos programables son
capaces de asumir, de forma que sólo producciones elevadas o requisitos muy especí-
ficos (velocidad, área, consumo, confidencialidad) hacen necesarios los ASIC-custom.
Con el avance que están siguiendo las tecnologías submicrónicas (se están de-
sarrollando procesos CMOS con transistores de longitud de canal inferior a las
0,3 um y capaces de albergar varios millones de dispositivos y conexiones en unos
pocos mm'), una vez más el cuello de botella del desarrollo microelectrónico va a
estar en el diseño más que en la tecnología. Ahora ya empieza a ser posible implan-
tar sistemas completos dentro de un chip de silicio (SOC, systems on chip; SOS,
systems on silicon) y el problema vuelve a ser la carencia de métodos y herramien-
tas para abordar diseños de tal complejidad. Los diseños se basan en macro bloques
funcionales (CPU, DSP, microcontrolador, etc.) desarrollados a nivel soft (código
VHDL sintetizable) u optimizados a nivel hard (layout o topografía específica), cu-

yo grado de desarrollo y madurez dista todavía del ideal pero en el que se está invir-
tiendo gran esfuerzo.
En cuanto a metodologías de diseño, los años noventa se han caracterizado por
una implantación progresiva, en fase de consolidación, de los lenguajes de descrip-
ción de hardware (Verilog y VHDL) que, junto con las herramientas de simulación
y síntesis, promueven el uso de las llamadas metodologías de diseño descendente
(top-down). Se trata de concentrar el esfuerzo en la concepción a nivel funcional-ar-
quitectural, facilitando la evaluación de soluciones alternativas antes de abordar el
diseño detallado y la implementación física, dando lugar así al también llamado di-
seño de alto nivel. El VHDL, aunque podamos o debamos verlo sólo como una he-
rramienta de base, ha sido el motor que ha estimulado esta evolución que pretende
cubrir el diseño electrónico desde el dominio funcional o comportamental, tal como
se muestra en el proyecto PRENDA [CP96].
La Figura 1-5 esquematiza un flujo de diseño centrado en el dominio funcio-
nal y basado en los lenguajes de descripción de hardware y los correspondientes
procesos de simulación mixta-multinivel (funcional, RT, puertas) y síntesis (com-
portamental, RT, lógica). Actualmente la síntesis comportamental, encargada de
convertir una descripción funcional en otra más detallada a nivel de transferencia
de registros (RT), está en fase de desarrollo preindustrial. Por su parte, la síntesis a
nivel de transferencia de registros (RT), así como a nivel lógico y físico, es am-
pliamente conocida y utilizada [(MLD92]. En el apartado 1.3.2 y en la Figura 1-10
se analizan con un poco más de detalle estos flujos de diseño descendentes, que
también se abordan en el Capítulo 6.
Esta misma Figura 1-5 trata de reflejar una orientación descendente (top-down)
y la globalización del flujo de diseño electrónico actual, donde la dependencia de la
implementación final es prácticamente nula a nivel funcional y se va concretando
en las sucesivas fases de diseño, hasta llegar a la realización física de los distintos
componentes (ASICs, FPGAs) y del sistema electrónico final MCM, PCB, SOCo
Esta globalización del diseño electrónico ha supuesto una evolución coordinada
de las distintas técnicas de diseño asistido por ordenador (CAD) en lo que se ha lla-
mado automatización del diseño electrónico (Electronic Design Automation, EDA).
Estas técnicas, pensadas para facilitar la ingenieria concurrente', están en pleno desa-
rrollo con el objetivo de poder automatizar en los próximos años el diseño de siste-
mas complejos que incluyan hardware y software (Hw/Sw Co-Design) [KAJW95 ,
BLR97]. A partir de un módulo que ayudará a realizar la partición del sistema a de-
sarrollar en hardware y software, habrá flujos EDA y CASE (Computer Aided Soft-
ware Engineering) que permitirán el desarrollo concurrente de ambas partes.
Por su parte, el incremento de los diseños analógicos y mixtos ha forzado el de-
sarrollo de entornos de simulación mixtos analógico-digitales (HDL, puertas y dis-
I El objetivo de la ingeniería concurrente es simultanear las tareas de distintos departamentos o

equipos sobre un mismo producto en fase de desarrollo. Para ello se requiere de unos flujos de infor-
mación muy ágiles soportados por entornos' de CAE (Computer Aided Engineering) que interrelacio-
nen las áreas de desarrollo (hardware-software) con el marketing y la producción.
1. Introducción 11
ESpeCif¡aCiOnes
Descripciones
mixtas multi-nivel l"", ,
~s
ra e
e al ~ " , Niveles:
.Q E
u ra
C:t::
~g_
Simulación
Sistemas electrónicos
(mixta multi-nivel)
~
" 1 "
- - - : ;,
- Comportamental
- Arquitectural I RT
.~ §
Zu
,,
" - Lógico I puertas
~ ,
Síntesis a nivel de: ,,
- Comportamiento ~'
- RT-Lógico
- Mapeo tecnológico
~8
ce .¡¡¡
, ,-
-e,;
:::1 Ul
üra FPLDs MCMs
<.
alt::
:t::<D
0":::1
... o.
«,
_o
.~.~
z:Q
Sistema
electrónico ( peS)
J
!
FIGURA 1-5. Esquema de los nuevos flujos de diseño descendente basados en el
modelado, simulación y síntesis con HDLs a nivel funcional o comporta mental.
positivos), así como el desarrollo de nuevas estrategias y técnicas de test como las
basadas en el consumo corriente (Iddq) [Roc95]. También desde el VHDL se está
abordando el diseño analógico y mixto mediante el desarrollo de una nueva exten-
sión del lenguaje, el VHDL-AMS (VHDL-Analog-Mixed-Signal) [VAMS96], cuyas
primeras versiones ya empiezan a estar disponibles a nivel de descripción y simula-
ción. Así mismo, y también relacionado principalmente con los diseños mixtos que
van creciendo en complejidad y prestaciones, son necesarios y están surgiendo he-
rramientas avanzadas para el análisis de integridad de las señales (efecto de línea de
transmisión, acoplas, EMI).
Por su parte, las técnicas actuales de síntesis RT de HDLs, simulación de netlist
y posterior ubicación y conexionado de celdas se basan en los principios de la últi-
ma década donde el retardo de una conexión podía incluso despreciarse frente al re-
tardo de una puerta (en tecnologías superiores a una micra el 80 por 100 del retardo
se debe a las puertas y el 20 por 100 al conexionado), mientras que en las tecnologí-
as submicrónicas avanzadas (0.3 micras) los porcentajes han cambiado: 20 por 100
retardo de puertas y 80 por 100 retardo de conexiones. Esto está forzando el desa-
rrollo de procesos de síntesis que tengan más en cuenta el diseño físico de los CIs a
través de procesos de planificación topográfica (Floorplaning) guiados por presta-
ciones (tiempo, consumo, área) que permitan establecer criterios de diseño conver-
gentes para encontrar una solución que satisfaga la funcionalidad y prestaciones re-
queridas para un determinado circuito, o bien que ayude a demostrar la inviabilidad
del mismo.
En cuanto a los entornos de CAD evolucionaron, ya a finales de los ochenta, ha-
cia entornos integrados pero a la vez abiertos y flexibles al incorporar utilidades (In-
tegration kits) para la integración de nuevas herramientas, así como facilidades (De-
sign jlow management) para la definición, gestión y control del flujo de diseño a se-
guir por un determinado centro o para un proyecto concreto (Figura 1-4.c). Más re-
cientemente la implantación y uso de lenguajes y formatos estándar (electrónicos e
informáticos) está facilitando tanto el intercambio de información entre entornos (Fi-
gura 1-4.d) en las distintas etapas del diseño (modelos HDL, listas de componentes y
conexiones, vectores de test, retardos, etc.), como una mayor diversificación de he-
rramientas al poder configurarse cualquier flujo de diseño con las herramientas más
adecuadas, siempre que éstas se ajusten a los respectivos estándares (iniciativa CFf).
Para finalizar con esta década hablaremos de las plataformas harware-software
sobre las que se ha apoyado el desarrollo electrónico. Las estaciones de trabajo or-
ganizadas en forma de red de recursos distribuidos (cómputo, almacenamiento y ac~
ceso) se han consolidado durante la primera mitad de los años noventa. A su vez los
PCs, también formando parte de esa misma red informática, se van abriendo cami-
no y presionando a las estaciones de trabajo, ya sea como puntos de acceso al entor-
no informático (donde además compiten con los terminales-Xwindows) o como
puntos de proceso y almacenamiento local. Todo ello es posible gracias, una vez
más, a las prestaciones de los nuevos procesadores (Pentium, Power-PC, etc.) y al
uso de los estándares informáticos (windows, NT, X, redes, etc.), desarrollados con
la generación anterior de procesadores, software y entornos de diseño. Si a todo ello
le añadimos las crecientes posibilidades de los sistemas multimedia y las comunica-
ciones (internet, trabajo en grupo a distancia, etc.) podemos decir que estamos asis-
tiendo a una auténtica explosión de medios no siempre fácil de seguir y asumir.
1.2. LOS LENGUAJES DE DESCRIPCiÓN DE HARDWARE

Una vez revisada la evolución histórica del desarrollo electrónico y ubicados en el
tiempo los HDLs, procederemos ahora a presentar sus características genéricas, no
tanto las de los propios lenguajes sino las que hacen referencia o dependen de su uso.
2 La CFI (CAD Framework lnitiative) promueve la creación de un estándar para el desarrollo de

entornos de diseño, de tal forma que se facilite la personalización de distintos flujos de diseño con
aquellas herramientas que respeten las normas y mecanismos establecidos por la OFI.
1. Introducción 13
Para ello nos referiremos en este capítulo a los dos HDLs más conocidos y exten-
didos, el Verilog [OVT9l, SS190, TM9l, IEEE95] y el VHDL [IEEE88, Nav93,
IEEE94, Ash96], con alguna referencia al estandar japonés UDLII [YI89, CU93].
Tras una pequeña analogía con los lenguajes de desarrollo de software, se hace
una breve reseña histórica del Verilog y del VHDL. A continuación se presentan, en
genérico, sus prestaciones para abordar distintos niveles de abstracción y estilos
descriptivos, e inmediatamente se revisan las principales aportaciones de los HDLs
al proceso de diseño [Mer93, Nov95, TML96, DC97].
1.2.1. Lenguajes de descripción de Hw versus desarrollo

deSw
De siempre las distintas herramientas y entornos de CAD han hecho uso de lengua-
jes y formatos para describir y manejar los distintos objetos del diseño electrónico.
Algunos de estos lenguajes eran notaciones explícitas para realizar las descripcio-
nes de entrada a una cierta herramienta; mientras que otros son formatos interme-
dios propios de cada herramienta para agilizar sus procesos y casi siempre trans-
parentes y desconocidos para al usuario. Sin embargo, todos ellos se limitaban al
entorno de CAD que les era propio.
Los HDLs, además del grado de estandarización que supusieron, adoptaron con-
ceptos de la ingeniería del software para la descripción y modelado del hardware.
Desde el punto de vista de la sintaxis, los HDLs son muy similares a los lenguajes de
programación de alto nivel (High Level Languajes, HLL) para el desarrollo de soft·
ware. De hecho, en muchos casos, el HDL se deriva de un HLL. Así, el Verilog tiene
muchas reminiscencias del C; mientras que el VHDL procede del ADA, de quien he-
reda muchos de sus conceptos, propiedades y estructuras. Estas similitudes sintácti-
cas entre ambos tipos de lenguajes, si bien pueden facilitar el aprendizaje inicial y el
desarrollo de modelos de hardware a aquellos ingenieros con experiencia en progra-
mación, también encierran ciertos peligros, pues en aquellos casos en que el modelo
en HDL se realiza para su posterior síntesis e implementación, el diseñador debe
pensar y describir en términos de hardware aunque la sintaxis sea de software (sobre
este punto se incide en el Capítulo 4 al hablar de síntesis y se presentan ejemplos
prácticos en los Capítulos 5 y 6). De hecho, utilizar estrategias de software será
aconsejable cuando el modelo a desarrollar sea exclusivamente para simulación,
pues en ese caso se tratara de optimizar el modelo de cara a la ejecución de las dis-
tintas etapas y procesos de simulación que se detallan en el Capítulo 3 de este texto.
Los lenguajes de descripción de hardware (HDL) son lenguajes de alto nivel,
similares a los de programación (C, PASCAL, ADA, ... ), con una sintaxis y semán-
tica definidas para facilitar el modelado y descripción de circuitos electrónicos, des-
de las celdas de base de un ASIC hasta sistemas completos, pudiéndose realizar es-
tas descripciones a distintos niveles de abstracción, precisión y estilos de modelado,
tal como se muestra en el esquema simplificado de la Figura 1-7.
Los HDL nacen para modelar el comportamiento de un componente de cara a su
simulación, aunque también se utilizan para describir el diseño de un circuito para
su implementación a través de etapas de síntesis validadas vía simulación (Figura 1-6).
Prog.lDescr. independiente
del H/wque lo ejecuta (HLL)
o lo implementa (HOL)
¡ HLL
Programación
en Leng.
Alto Nivel
HOL
Descripción
de alto nivel
de abstracción
(p.e. RTL)
Prog.lDescr. dependiente
del H/wque lo ejecuta (ML)
o lo implementa (HOL)
¡ Programas
a nivel de
Leng. Máquina
Descripción
de bajo nivel
de abstracción
(p.e. puertas y cnx.)
(a) Desarrollo de Software (b) Desarrollo de Hardware
FIGURA 1-6. Desarrollo de software versus hardware: (a) niveles de abstracción y

lenguajes de alto nivel (HLL, HDL) y (b) esquema básico del diseño descendente con
HDL: La síntesis pasa una descripción de un nivel de abstracción a otro inferior;
mientras que la simulación permite la verificación funcional a cada nivel de abstrac-
ción y la validación de coherencia entre distintas descripciones.
Mientras en software se recurre a los lenguajes de alto nivel para implementar

los algoritmos de forma independiente del procesador que los va a ejecutar, en el
caso del hardware son los HDL, quienes permiten descripciones de los circuitos a
alto nivel de abstracción e independientes de la implementación tecnológica final
(Figura 1-6.a). A partir de tales descripciones, los procesos de diseño descendente
(top-down) aplican procedimientos progresivos de síntesis, dando lugar a descrip-
ciones más detalladas de la implementación hasta alcanzar una descripción física
concreta totalmente dependiente de la tecnología seleccionada. La validación de las
distintas descripciones se realiza mediante los correspondientes procesos de simula-
ción y análisis y las iteraciones de corrección resultantes (Figura 1-6.b).
1.2.2. Reseña histórica de los HDLs

Si bien los HDLs, se han integrado recientemente al proceso de diseño (desde el
inicio de los noventa), este tipo de lenguajes se ha venido desarrollando durante los
últimos decenios, siendo los años setenta la época de máxima proliferación (IDL-
IBM, TI-HDL, ZEUS-GE, AHPL, DDL, CDL, ISPS, ...). Sin embargo, estos len-
guajes nunca alcanzaron el nivel de difusión y consolidación necesarios; unos, los
industriales, por ser propiedad de la empresa que los desarrolló y no estar disponi-
bles fuera de ella; y otros, los universitarios, porque, aun pudiendo ser de dominio
público, carecían del soporte y mantenimiento adecuados [Har87].
1. Introducción 15
Comporta mental
o funcional
Abstractos
Arquitectural
RT
ompuestos
Estilos
Lógico-
Bit descriptivos
puertas
Estructu ral Flujo de datos Algorítmico
Figura 1-7. Niveles de abstracción/precisión y estilos de modelado en VHDL.
Durante los años ochenta, tras detectarse la necesidad de un lenguaje para dar
soporte a las distintas etapas y niveles de abstracción del proceso de diseño, se de-
sarrollan y consolidan dos de ellos: Verilog y VHDL. Cabe mencionar que existe el
UDUI, que nace como estándar japonés promovido y desarrollado por una asocia-
ción de empresas niponas y cuya implantación es más que discutible incluso en el
propio Japón.
El VHDL aparece como un proyecto del Departamento de Defensa de EEUU
(1982), con el fin de disponer de una herramienta estándar e independiente para la
especificación (modelado y/o descripción) y documentación de los sistemas elec-
trónicos a lo largo de todo su ciclo de vida. Tras las primeras revisiones del len-
guaje, el IEEE lo adopta y desarrolla corno el HDL estándar (l." versión en 1987 y
la 2: en 1994) [IEEE88, IEEE94].
El Verilog nace como un lenguaje de modelado ligado a un entorno de simula-
ción de la firma Gateway, pasando posteriormente a ser el simulador digital de Ca-
denee Design Systems Ine., llegando a convertirse en un estándar "de facto" a nivel
industrial. Al aparecer el VHDL como estándar IEEE, Verilog se encontró con un
fuerte competidor, y en 1990 Cadence decide ofrecerlo como lenguaje de dominio
público [OVI91] e inicia las gestiones para su estandarización formal, que se logra
en 1995 [IEEE95].
El desarrollo, difusión y estandarización de los lenguajes Verilog y VHDL,

aunque sólo sean herramientas básicas para la descripción de circuitos y sistemas
electrónicos fue, y sigue siendo, un hecho determinante en el desarrollo de las nue-
vas metodologías y herramientas de diseño electrónico.
1.2.3. Modelado con HDLs: niveles de abstracción y

estilos descriptivos
Una de las características más importantes de estos lenguajes es su capacidad para
abordar descripciones a distintos niveles de abstracción (funcional o comportamen-
tal, arquitectural o transferencia de registros, lógico o de puertas) y estilos de mode-
lado (algorítmico, flujo de datos, estructural).
Los niveles de abstracción hacen referencia al grado de detalle en que se en-
cuentra una determinada descripción HDL respecto ala implementación física de la
misma. Puesto que el nivel más bajo que trataremos directamente con los HDL se-
rán listas de componentes y conexiones a nivel de puertas podemos considerar que
desde los HDL no abordamos el nivel físico mostrado en la Figura 1-1, que queda-
ría como el nivel más bajo de abstracción (donde se fijan todos los detalles para la
implementación real del circuito), por encima del cual se sitúa el nivel lógico o de
puertas. Así pues, desde la perspectiva de simulación y síntesis con HDLs, los nive-
les de abstracción pueden quedar reajustados a los tres siguientes:
• Funcional o comportamental, donde se indica el comportamiento del circuito
o sistema como una relación funcional entre las entradas y salidas, pero sin
hacer ninguna referencia a su implementación.
• Arquitectural o de trasferencia de registros (RT). A este nivel se desarrolla
una partición en bloques funcionales y se planifican en el tiempo (ciclos de
reloj) las acciones a realizar. Todavía no se conocen los detalles de la realiza-
ción final de cada bloque.
• Lógico o de puertas. En este caso los componentes del circuito están expre-
sados en términos de ecuaciones lógicas o puertas y elementos de una biblio-
teca, pudiendo ser ésta genérica (independientemente de la tecnología) o es-
pecífica de una tecnología.
Como vemos, estos niveles de abstracción se proponen como una taxonomía
simplificada para poder clasificar los modelos HDL según el grado de detalle y pre-
cisión de sus descripciones. Hay dos factores que caracterizan esta precisión:
1. La precisión en la temporización o relación temporal en el funcionamien-

to del circuito. A nivel de puertas se conocen los retrasos de los distintos
componentes básicos y se pueden estimar o conocer (retroanotación des-
pués de la fase de ubicación y conexionado físico) los retardos introduci-
dos por las conexiones. A nivel arquitectural o RT tendremos acciones
agrupadas en distintos estados que se realizarán bajo el sincronismo de los
ciclos de un reloj, pero no se conocen con detalle los componentes que
van a realizar dichas acciones. A nivel funcional sólo las relaciones causa-
1. Introducción 17
les fijadas por las dependencias entre datos son importantes, pero las dis-
tintas acciones no han sido ni identificadas con detalle ni planificadas res-
pecto a un reloj.
2. Los tipos de datos que pueden ir desde los más abstractos definidos por el
propio usuario hasta el más básico, el bit, para una señal digital, pasando
por los compuestos que agrupan bloques de bits con un significado específi-
co y se representan como enteros con o sin signo.
Además de estos factores determinantes del nivel de abstracción que se reflejan

en la Figura 1-7, otro aspecto o criterio de caracterización de los modelos HDL es
el estilo de descripción que, de forma simplificada, podemos distinguir entre los
tres siguientes:
• Algorítmico: hace referencia a descripciones similares a los programas soft-

ware, que deben reflejar la funcionalidad del módulo, componente o circuito,
en forma de uno o más procesos concurrentes que contienen descripciones
secuenciales del algoritmo o subalgoritrno correspondiente.
• Flujo de datos: descripciones basadas en ecuaciones y expresiones que refle-
jan el flujo de información y las dependencias entre datos y operaciones.
• Estructural: en este estilo se reflejan directamente componentes por referen-
cia y conexiones entre ellos a través de sus puertos de entrada/salida.
Estos estilos descriptivos forman el tercer eje de la Figura 1-7, que es una sim-
plificación del cubo de diseño de Ecker [IECK95], donde los movimientos dentro
de un mismo plano horizontal responden a refinamientos o cambios en el tipo de
datos y/o en el estilo descriptivo; mientras que los movimientos descendentes en un
plano vertical corresponden a los actuales procesos de síntesis (comportamental,
RT, lógico-puertas). Como se puede intuir, normalmente hay una cierta correlación
entre niveles de abstracción y estilos descriptivos. Así pues, las descripciones algo-
rítmicas se usan más a nivel comportamental o funcional, el flujo de datos se rela-
ciona más con el nivel arquitectural o RT y a nivel de puertas el estilo descriptivo
siempre es de tipo estructural.
De todas formas uno de los valores añadidos de estos lenguajes, y en especial
del VHDL, es su capacidad para hacer convivir de forma natural descripciones mix-
tas-multinivel: distintos estilos y niveles de abstracción para las distintas partes de
un diseño. Una cierta descripción estructural puede tener componentes desarrolla-
dos a nivel de puertas, otros a nivel RT en forma de flujo de datos y algunos todavía
en forma de algoritmos a nivel funcional (Figura 1-5). Esta es una situación normal,
que va evolucionando a lo largo de todo el proceso de diseño hasta que, tras los co-
rrespondientes procesos de síntesis manual o automática, todos los componentes del
circuito a implementar están detallados mediante una descripción estructural a nivel
de puertas. Mientras tanto, aquellos componentes que sólo formaban parte del en-
torno de simulación del circuito permanecen descritos al nivel de detalle que se hu-
biese considerado necesario (normalmente funcional o RT). En la Figura 1-8 pue-
den verse algunos ejemplos sencillos e intuitivos sobre la flexibilidad de uso del
Verilog y el VHDL.
om - ~S
Sumador ein~~ Sumador Total ~S
Total
or L..- ---l eout
~: ~
B~
a e I entity sumador_total
porteA, B, Cin : in bit;
Is
S, Cout : out bit);
A
~ ~eout end sumado,._total;
a e
(a) (b)
eln" X=AEDB ein ....-----Ib S

~S
B+ S = XEBCin Sumador Semi- >--~S
A+ Cout = A-B + X·Cin ~eout Total sumador
U1
B ..b s -,
architectura vision_booleana 01 Semi- Y a e
T sumador_total ts signal X : bit; begin
X <= A xor B after 10 ns;
< S <= X xor Cln after 10 ns;
sumador
UO X
Z~
~g¡-~eout
::J: Cout <= (A and B) or (X and Cin) A+ a e
~ aftar 20 ns; l.!:::::==::! ___J
1 end vision_booleana;
are.hitactura vision-;-estructural of sumador_total Is
slgnal X, Y, Z: brt;
T m?dule sumador_booleano (A, B, Cln, S, Cout);
1
Input A, B, Cm; component semisumador
< output S, Cout; porteA, B : In bit;
S, Cout : out bit);
~. wire X;
end component;
eS ::::~~ :~ g ~ :: ~ ~ g¡n; ~ co~~(~~~t :Pi~eb~~_or
1 assign #20 Cout = (A && B) 11 (X && Cln);

endmodule
(e)
o:::>
r'l end component;
begin
S : out bit);
UO : semisumador port map(A, B, X, Y);

U1 : semisumador port map(Y, Cln, Z, S);
U2 : puerta_or port map(X, Z, Cout);
end vision_eslructural;
entfty puerta_or Is
I
porteA, B : in bit;
S: out bit); module sumador_estructura (A, B, Cin, S, Cout);
end puerta_or;
archltecture
begin
funcional 01 puerta_or Is T
~
input A, B, Cin;
~~:~~,~,~~ut;
S <=Aor B; ~ semisumador UO(A, B, X, Y);
end funcional; <0 semisumador U1 (Y, Cin, Z, S);
~
¡;;1j entity semisumador rs
1 or U2(X, Z, Cout);
endmodule
(d)
port ( A, B : in bit;
S, Cout : out bit);
end semisumador;
architecture funcional 01 semisumador ts
T~
module semisumador
input A, B;
output S. Cout;
(A, B, S, Cout);
begin
S <= A xor B;
=
1
assign S = A A B;
Cout <= (A and B);
assign Cout = (A && B);
end funcional;
endmodule
(e)
FIGURA 1-8. Algunos ejemplos sencillos sobre modelos Verilog y VHDL con distin-
tos niveles de abstracción y estilos de descripción: (a) Esquema jerárquico de un su:
mador total de 2 bits (captura de esquemas clásica). (b) Descripción de VHDL del inter-
faz E/S del sumador total (ST). En VHDL para cada módulo se define una entity donde
se detallan las E/S, mientras que las distintas arquitecturas o descripciones alternati-
vas se detallan en distintos módulos architecture, que comparten una misma entity.
En el caso del Verilog, cada módulo define sus E/S. (e) Modelado del ST en HDL a nivel
funcional, en términos de ecuaciones booleanas e incluyendo los retardos previstos.
(d) Una descripción estructural (componentes y conexiones) del mismo STo (e) Defini-
ción funcional de los componentes utilizados en (d). Obsérvese que en Verilog el com-
ponente OR, al ser una primitiva del propio lenguaje, no necesita ser definido.
1. Introducción 19
1.2.4. Aportaciones de los HDLs al proceso de diseño
Tanto el Verilog como el VHDL nacen con una sintaxis (formalizada mediante una
gramática) y una semántica (no formal, matemáticamente hablando) definidas y di-
rigidas hacia el modelado para la simulación de hardware. Sin embargo, rápidamen-
te se abordó su uso como soporte para todas las fases del proceso de diseño, y muy
especialmente para las etapas de síntesis. Pasemos, pues, a comentar las ventajas
más relevantes que pueden suponer el uso de estos lenguajes:
• Estos HDLs son interpretables tanto por las personas como por los ordenado-
res, pudiendo proporcionar soporte tanto a las tareas estrictas de diseño (mo-
delado, simulación, síntesis, verificación) como a las de comunicación e in-
tercambio de modelos entre los distintos equipos de trabajo y, obviamente, a
las de documentación y mantenimiento de los diseños.
• Son lenguajes de disponibilidad pública, no sometidos a ninguna firma ni pa-
tente (especialmente el VHDL). Están definidos, documentados y manteni-
dos por el IEEE, quien garantiza su estabilidad y su soporte.
• Soportan descripciones con múltiples niveles de abstracción, pudiéndose
mezclar desde módulos descritos a nivel funcional hasta módulos a nivel de
puertas. Con el mismo lenguaje se describe el circuito y el entorno de verifi-
cación (banco de pruebas) para su simulación/validación.
• La utilización de un lenguaje único a lo largo de todo el proceso de diseño
simplifica la gestión del mismo (reducción de herramientas y formatos) y la
descripción/simulación mixta multinivel facilita el diseño independiente de.
los diferentes componentes o módulos y, por lo tanto, la distribución de ta-
reas entre distintos equipos coordinados bajo un único entorno de simula-
ción/ verificación.
• Proporcionan independencia de metodología, de herramientas y de tecnolo-
gía. A pesar que el VHDL es uno de los soportes naturales de las metodolo-
gías descendentes, no está sometido a ningún proceso ni mecanismo estricto
de diseño, pudiéndose amoldar a cualquier metodología donde el modelado
de hardware pueda tener sentido (especificación, documentación, simula-
ción, síntesis y/o verificación).
• En el caso de las herramientas CAD, los HDL son lenguajes estándar que de-
finen una sintaxis y una semántica de modelado para simulación. Así pues,
cualquier herramienta que cumpla con el estándar ha de aceptar y ejecutar
(simular) de la misma forma cualquier modelo. Esta portabilidad no es tan
aplicable a la síntesis ni a la verificación formal, ya que la semántica del
VHDL y del Verilog en estas áreas no está definida desde el IEEE, y son los
proveedores de CAD quienes hacen su propia interpretación, dando lugar a
pequeñas divergencias, en general fáciles de salvar, pero que impiden hablar
de un estándar desde el punto de vista de la síntesis. En cambio, el UDUI sí
tiene una semántica definida para la síntesis hardware.
• Los HDL, tanto por su definición y diseño como por los niveles de abstrac-
ción donde habitualmente se usan, son, o pueden ser, totalmente indepen-
dientes de la tecnología final de implementación de los circuitos. La descrip-
ción VHDL de un circuito puede ser totalmente indiferente a la tecnología de

fabricación, pero si se quiere también puede incluir información específica
de la implementación final (retrasos, consumo, ...). En general podemos de-
cir que los ROLs pueden proporcionar al sistemista una cierta independencia
frente a sus suministradores: fabricantes de Cls (un diseño con ROL es más
o menos fácil de resintetizar sobre tecnologías distintas), centros de diseño
(todos pueden aceptar especificaciones en ROL), proveedores de herramien-
tas CAD (los ROL son muchas veces el núcleo de la herramienta y en cual-
quier caso siempre son una vía de acceso) y distribuidores de componentes
(los modelos de simulación en ROL serán compatibles).
• La reutilización del código ROL desarrollado en los proyectos anteriores es
un hecho posible gracias a algunas de las características enunciadas anterior-
mente como ser lenguajes estándar, estables y su independencia metodológi-
ca, tecnológica y del CAD. Una descripción VHDL de un diseño, inicialmen-
te desarrollado para una determinada tecnología (CMOS, BlCMOS, SOl,
etc.) e implementación (ASIC, FPGA, PCB, etc.), puede fácilmente ser reuti-
lizado en diseños o materializaciones posteriores donde la tecnología, la al-
ternativa de implementación y/o el CAD pueden ser distintas. Esto facilita la
evolución del producto, ya sea mejorando o incrementando sus característi-
cas funcionales (modificaciones del modelo ROL y resíntesis), o bien vía re-
novación tecnológica haciendo su reimplementación (síntesis del modelo
ROL) sobre nuevas tecnologías. Así mismo, en el caso del VHDL el propio
lenguaje dispone de mecanismos básicos como los genéricos (generics) y las
configuraciones (configurations), que facilitan la adecuación y reutilización
de los módulos VHDL a las distintas condiciones de contexto de los circuitos
en los que se pueden utilizar estos módulos.
De todas formas, estas posibilidades de reutilización del código ROL serán
más ciertas y eficientes en la medida en que los grupos de trabajo o centros de dise-
ño se definan sus propios procedimientos y la normativa básica para acumular el
know-how resultante de los distintos proyectos de una forma estructurada que facili-
te su uso y actualización (ver Apéndice ll). Este sería el coste añadido para poder
beneficiarse de las ventajas y en especial de la reutilización del código HDL. Mu-
chas de estas aportaciones de los ROL se detallan y ejemplifican para el caso del
VROL en los Capítulos 5 y 6 de este mismo libro.
Como vemos, estos lenguajes pueden aportar ventajas importantes pero no de-
bemos ignorar que también están sujetos a algunas limitaciones:
• Al ser lenguajes definidos por consenso en el seno de una comisión (espe-
cialmente el VHDL) tienden a ser complejos para contemplar la diversidad
de opiniones. Así mismo la evolución del lenguaje mediante revisiones vía
comisión es lenta (5-6 años para el VHDL) y con importantes cambios en ca-
da nueva versión.
• La falta de una semántica formal para síntesis dificulta la potabilidad de los
diseños entre distintos entornos de síntesis (no todas las herramientas inter-
pretan de la misma forma las mismas construcciones del lenguaje) e imposi-
bilita abordar claramente la verificación formal.
7. Introducción 21
• El VHDL, por sus características sintáctico-semánticas, está mejor dotado

para las descripciones a nivel funcional/algorítmico, mientras que sus presta-
ciones se ven más limitadas al trabajar a nivel de puertas. Por su parte el Ve-
ri/og, al basarse en un conjunto de primitivas funcionales básicas (puertas),
tiene buenas prestaciones a nivel estructural/puertas pero claras limitaciones
en los niveles superiores.
• La enorme flexibilidad del VHDL está dificultando la implantación de meca-
nismos estándar para facilitar el intercambio de módulos, reflejar los retar-
dos, la temporización (timíng) y la retroanotación (backannotation) en el
modelado de bibliotecas de celdas o para el desarrollo de entornos de verifi-
cación, entre otros. En este sentido hay iniciativas como VITAL 3 u OMF 4,
que ya empiezan a consolidar algunas extensiones del estandar para dar res-
puesta a algunos de estos problemas.
Los Capítulos 3 y 4 de este libro presentan los detalles y características especí-

ficas de la simulación y síntesis basadas en VHDL.
Actualmente el Verilog y el VHDL están compitiendo y a la vez compartiendo
algunos de sus mecanismos y estrategias para asegurar su mutua evolución y su ca-
da vez más cercana compatibilidad y fácil interoperatividad. En cualquier caso es-
tos lenguajes sólo son herramientas de base a las que se debe arropar con metodo-
logías y CAD para poder aprovechar sus ventajas potenciales y superar sus limita-
ciones actuales.
1.3. METODOLOGÍAS Y FLUJOS DE DISEÑO
Metodologías, flujos y herramientas CAD de diseño electrónico son conceptos muy

interrelacionados y no siempre fáciles de distinguir. La metodología es un concepto
más abstracto que hace referencia a procesos de diseño genéricos que relacionan
entre sí los distintos niveles de complejidad y abstracción (funcional-comportamen-
tal, arquitectural-RT, lógico-puertas y físico, según se detalla en el apartado 1.2.3)
por los que atraviesa el diseño de un circuito o sistema electrónico.
Por su parte los flujos de diseño son una personalización concreta de una cierta
metodología, para un tipo de circuitos o área de aplicación específico, y contando
con el soporte de unas determinadas herramientas de CAD. Distintos flujos de dise-
ño pueden responder a una misma metodología y un mismo flujo se puede implan-
tar con distintas herramientas de CAD.
Los objetivos fundamentales que persigue toda metodología de diseño se pue-
den resumir en:
3 VITAL (VHDL lnitiative Towards ASIC Libraries modeling). Esta iniciativa promueve la estan-
darización de los mecanismos para representar y gestionar los parámetros temporales (retardos de puer-
ta y retroanotación de retardos del conexionado) en el modelado VHDL de las bibliotecas de celdas pa-
ra el diseño de ASICs.
4 OMF (Open Modeling Forum). Promueve la estandarización de una interfaz para la simulación
y otras herramientas relacionadas con el modelado VHDL, Verilog y C.

• Establecer procesos de diseño que permitan reducir costes, tiempo y riesgos

de desarrollo, a la vez que se garantizan las prestaciones requeridas del pro-
ducto final.
• Mantenerse, en la medida de lo posible, independiente de las herramientas
CAD y alternativas tecnológicas disponibles para el desarrollo de un circuito.
Estos dos objetivos se desdoblan en múltiples requisitos y características para
los distintos flujos y herramientas de diseño, que no entraremos a analizar. Sin em-
bargo, para alcanzar estos objetivos, en cada etapa de diseño o nivel de representa-
ción de un circuito se deben aplicar los principios de:
• Abstracción: fijar y definir el nivel de abstracción de cada etapa permite, tan-
to al diseñador de circuitos como al desarrollador de CAD, ignorar en cada
momento detalles ajenos al nivel en el que se esté trabajando.
• Jerarquía y estructuración: permite reducir la complejidad del diseño me-
diante la descomposición jerárquica del mismo hasta alcanzar bloques o mó-
dulos del nivel de abstracción correspondiente.
En general, establecer una metodología o flujo de diseño significa definir las
distintas etapas que recorrerán los diferentes niveles de abstracción y fijar cómo
evolucionaremos a través de ellas utilizando procesos manuales o automáticos de:
• Síntesis: para pasar las descripciones de un determinado nivel de abstracción
a otras de nivel inferior con un mayor grado de detalle (p. ej., de una descrip-
ción RT a puertas, o de puertas a máscaras).
• Análisis: extraer información de una descripción (p. ej., retardos del cone-
xionado) para facilitar una verificación de prestaciones o inyectarla a una
descripción de nivel superior para validar restricciones.
• Verificación/simulación: para validar tanto la corrección de las descripciones
de cada etapa como la equivalencia entre las distintas etapas y niveles de
abstracción.
Estos tres tipos de procesos se concretan en distintas herramientas actuando a
diferentes niveles de abstracción.
Siguiendo estos objetivos, principios y procesos podemos decir que las meto-
dologías siempre han hecho propuestas de refinamiento progresivo (proceso des-
cendente o top-down) desde la idea a la implementación, pasando por distintas eta-
pas o niveles de abstracción. Sin embargo, los flujos reales de diseño se han visto
mucho más sujetos al estado de las herramientas de diseño que ha seguido una evo-
lución ascendente (bottom-up) para ir cubriendo progresivamente las etapas de
mayor nivel de complejidad desde el nivel físico al nivel funcional (ver Figuras 1-1,
1-2,1-3, 1-9 Y 1-10).
Debido a estas limitaciones del CAD durante el proceso evolutivo de los años
ochenta, la metodología y los flujos de diseño implantados en esta época tenían una
fuerte componente de diseño basada en una composición jerárquica ascendente
(bottom-up) de módulos y bloques hasta alcanzar el diseño completo del circuito.
Este método tenía claras limitaciones en términos de eficiencia (sólo hacia el final
del diseño, cuando ya se habían tomado todas las decisiones arquitecturales e inclu-
1. Introducción 23
so tecnológicas, se podía proceder a una validación-simulación completa del mis-

mo) y consecuencias obvias a nivel de costes, tiempo y riesgo de desarrollo. Con la
llegada de los HDLs y con el soporte de las herramientas de descripción, simula-
ción y síntesis se están superando muchas de estas limitaciones y se facilita la im-
plantación de flujos de diseño descendentes (top-down) que permiten abordar dise-
ños más complejos con mayores garantías de éxito.
Sin embargo, la evolución de las tecnologías de semiconductores sigue yendo
por delante de las técnicas de diseño. Ya empiezan a ser factibles chips de tal com-
plejidad que permitan la integración de sistemas completos (Systems on Chip, SoC),
para lo cual serán necesarias metodologías mixtas descendentes-ascendentes donde
ciertas partes del diseño, las más operativas, se basen en la composición ascendente
de módulos preexistentes, mientras que para diseñar las funciones de controlo par-
tes más específicas se seguirán procesos descendentes.
En los próximos apartados tratamos de resumir las ideas básicas sobre estas
metodologías y flujos de diseño.
1.3.1. Flujo de diseño ascendente (bottom-up)

En el proceso de diseño de ASICs implantado a mediados de los ochenta se podían
distinguir dos fases distintas:
1. Una descomposición jerárquica descendente (aproximación top-down sobre
papel y no simulable) del circuito a diseñar en bloques y subbloques hasta
llegar al conjunto de módulos que, aun estando descritos a un nivel funcio-
nal, su diseño lógico fuera abordable desde la tecnología escogida y según
su biblioteca de celdas específica.
2. En la segunda fase se realiza una composición jerárquica ascendente (apro-
ximación bottom-up) de celdas, módulos y bloques hasta conformar la es-
tructura jerárquica establecida en la fase previa.
Tal como muestra la Figura 1-9, la primera fase era un proceso fuertemente
manual basado exclusivamente en la experiencia previa de los diseñadores y, aun-
que las decisiones que se tomaban eran críticas (partición, arquitecturas, bloques) y
con importantes consecuencias para el posterior desarrollo y prestaciones del circui-
to, no se contaba con ningún soporte de herramientas CAD y muy poco apoyo me-
todológico. Ante estas carencias no se le podía dedicar a esta fase ni tiempo ni el
esfuerzo adecuados y se abordaba rápidamente la segunda fase de composición je-
rárquica ascendente que, a pesar de contar con el soporte de flujos y herramientas
de diseño, era muy laboriosa y concentraba la mayor parte de los esfuerzos de dise-
ño, dando así el nombre de ascendente (bottom-up) a la metodología y flujos de di-
seño utilizados.
La Figura 1-2 muestra un esquema genérico de estos flujos ascendentes, donde
se encadenan etapas de captura de esquemas, para detallar el esquema lógico de un
módulo en base a los previamente descritos y/a la biblioteca de celdas específica de
la tecnología seleccionada, y simulación (lógica, temporal, fallos) para validar cada
nuevo módulo. Este proceso captura-simulación se repetía hasta completar toda la
Conjunto de bloques Conjunto de bloques

y módulos básicos f---_I y módulos básicos
(dese. funcional) (dese, estructural)
Flujo de diseño manual Flujo de diseño asistido por ordenador
FIGURA '-9. Esquema de las fases básicas del diseño ascendente (bottom-up}.
estructura jerárquica del circuito (esta fase también se conocía como el "front-end"
del diseño). Después, con los esquemáticos libres de errores y cumpliendo las pres-
taciones requeridas, se abordaba la fase de diseño físico (también llamada "back-
end"), que incluía e incluye básicamente procesos de ubicación y conexionado se-
guidos de verificación a nivel de máscaras (topografía o layout de un circuito), A
continuación se extraen de la topografía los retardos reales derivados del conexio-
nado físico final y se retroanotan en los esquemáticos para poder proceder a repetir
las simulaciones (post-layout) y comparar que se siguen manteniendo las prestacio-
nes funcionales y temporales.
Además de todo ello, durante el diseño a nivel de puertas debe también tenerse
en cuenta la testabilidad y el test del circuito [Tsu87, ABF90). Tema este muy impor-
tante que incide en el propio proceso de diseño, al tener que desarrollar un conjunto
de vectores de test que cubran el mayor número (>96 %) de faltas posibles del Cl,
pues serán los que se utilicen en la fase de test estructural post-fabricación para deter-
minar qué circuitos se dan por válidos y cuáles no. La testabilidad de un Cl es un te-
ma crucial, pues un chip no testable (baja cobertura de faltas de los vectores de test)
se puede considerar inútil a efectos prácticos. Ello ha dado lugar a las llamadas técni-
cas de diseño para test (Design for testability, DFT) que, además de la dificultad aña-
dida, siempre suponen un incremento de la complejidad final del circuito al tener que
incluir estructuras hardware específicas que ayudan a conseguir el nivel de testabili-
dad necesario. Obviamente, todos estos temas relacionados con el test estructural no
son aplicables a los procesos de diseño contra dispositivos programables tipo FPGA.
Todos estos procesos, como la propia Figura 1-2 muestra, se basaban en una bi-
blioteca de celdas especifica de la tecnología con la que se iba a realizar el circuito
y que se escogía antes de iniciar el proceso de diseño propiamente dicho.
1. Introducción 25
A la vista de este flujo de diseño podemos citar como limitaciones más impor-
tantes del mismo las siguientes:
• El particionado inicial, el desarrollo de la arquitectura y su descomposición
jerárquica descendente exigen una gran cantidad de decisiones críticas que
sólo se basaban en la experiencia del diseñador, sin contar con ningún sopor-
te metodológico ni mecanismo alguno para hacer evaluaciones previas.
• La biblioteca de celdas y, por lo tanto, la tecnología de fabricación se selec-
cionaban antes de iniciarse el proceso de diseño ascendente.
• Ningún bloque podía simularse hasta no tener completamente diseñados y si-
mulados todos los componentes que lo integran.
Como consecuencia de todo ello, los errores o imprevistos derivados de la pre-
cariedad con la que se realizaba la fase de análisis y descomposición jerárquica des-
cendente inicial, se detectaban en estadios muy tardíos del proceso de diseño. El es-
fuerzo invertido ya era muy elevado y había que recuperarse aunque fuese inclu-
yendo parches y soluciones atípicas en el diseño. Ello daba lugar a procesos de di-
seño poco claros y bastante complicados de forma que el depurado, las modifica-
ciones y el mantenimiento de un diseño se convertirán en tareas muy complejas, o
incluso imposibles, un cierto tiempo después de finalizado el mismo.
En resumen, esta metod~ogía facilitaba tanto la propagación de problemas des-
de las fases iniciales hasta 1 fases avanzadas del diseño (cuanto más tiempo se tar-
da en detectar un problem más difícil y costosa en su resolución, tanto por el es-
fuerzo acumulado como po la propia dificultad de la solución), como la creación de
estructuras innecesariamente omplejas o poco recomendables que podían dificultar
talmente la evolución y mantenimiento del diseño, que este esfuerzo fuese inviable
y se requiriera un rediseño completo. Todo ello tiene múltiples facetas y todas ellas
acaban suponiendo un incremento de los costes de desarrollo del producto final.
1.3.2. Flujo de diseño descendente (top-down)

La idea básica del diseño descendente frente al ascendente es aportar metodología y
CAD para dar soporte a la parte izquierda del flujo mostrado en la Figura 1-9.
Las técnicas de diseño descendente apuestan por la formalización y normaliza-
ción de las tareas de diseño desde las primeras etapas de concepción (especificacio-
nes descritas en VHDL y, por lo tanto, simulables) y se centran en promover el dise-
ño a nivel comportamental, facilitando la evaluación de soluciones alternativas des-
de ese mismo nivel, dando lugar al llamado "diseño de alto nivel" [MLD92].
El objetivo es facilitar las tareas de diseño de alto nivel que van desde las espe-
cificaciones hasta la descripción a nivel de transferencia de registros, de la arquitec-
tura escogida, cuya síntesis permita obtener una descripción a nivel lógico o de
puertas. A partir de este punto las listas de componentes y conexiones que se obtie-
nen ya pueden entrar a los procesos habituales de diseño físico (ubicación y cone-
xionado, verificación, extracción y retroanotación de parásitos y retardos).
Aplicando el principio de abstracción antes mencionado, se trata también de in-
dependizar el diseño a nivel funcional respecto del arquitectural-RT, y éste en rela-
ción al nivel lógico-puertas, siendo las herramientas de síntesis quienes marcan esta
independencia. Actualmente la síntesis está entre el nivel RT y las puertas; cuando
en un futuro inmediato se estabilice la síntesis comportamental, ahora a nivel prein-
dustrial, serán más independientes entre sí el diseño de nivel funcional y el arqui-
tectural- RT.
Las características y ventajas de los HOL en general (ver punto 1.2.4), y en es-
pecial de VHDL, están facilitando y potenciando el desarrollo e implantación de las
metodologías de diseño descendente que se basan en un uso intensivo de tales len-
guajes (modelado/descripción del circuito y de los bancos de pruebas), convenien-
temente soportados durante todo el proceso de diseño por herramientas de simula-
ción, síntesis y procesos de análisis-verificación.
La Figura 1-10 muestra de forma esquemática y genérica esta metodología que
se basa en un proceso de construcción o diseño descendente apoyado en flujos de
información ascendentes.
1.3.2.1. Construcción o diseño descendente

A partir de la idea o concepto que se desea implementar en forma de sistema o cir-
cuito electrónico se ha de proceder a una primera fase de definición de especifica-
ciones. Hasta ahora esta ha sido la etapa menos formalizada y a la que no se presta
la atención que requiere, a pesar de que los resultados de la misma guían o dirigen
muchas de las decisiones posteriores durante el proceso de diseño. Con la llegada
de los HOLs se estableció la tecnología de base para dar el soporte necesario a la
actividad de concepción a nivel funcional, incluyendo la parte de descripción/simu-
lación de las especificaciones [CP96].
En principio las especificaciones de un diseño no tan sólo han de incluir infor-
mación sobre el propio circuito, sino también del entorno operativo donde éste esta-
rá ubicado. A partir de esta información el proceso de descripción HOL de las espe-
cificaciones ha de dar lugar a dos modelos HDL:
• El que contiene las especificaciones funcionales del circuito objeto del dise-
ño que normalmente estará a un nivel de abstracción comportamental utili-
zando descripciones de tipo algorítmico.
• El modelo HDL del entorno del circuito para validarlo en su contexto (banco
de pruebas, test-bench). Este modelo tiene o puede tener múltiples funciones:
- reproducir el entorno de utilización del circuito,
- facilitar la generación de estímulos hacia el circuito y la recogida de resul-
tados desde el mismo para poder analizar su comportamiento y
- comparación de resultados respecto a un modelo de referencia,
todas ellas dirigidas a facilitar la comprobación del correcto funcionamiento
del circuito bajo test, vía procesos de simulación y análisis de resultados.
Con estos dos modelos ya se podrán hacer simulaciones funcionales que permi-
tan depurar las especificaciones y comenzar a evaluar distintas alternativas de parti-
ción del sistema.
1. Introducción 27
~
Q)
E
~
8.
E
,, .!!!
,, ~c: g>
o "O
I
I
'0 e
I c:
::;,
o
Refinamiento gradual en HDL
I
, u.. $
___ 01I _ Q)
Síntesis del comportamiento I
"O
I
I
I
I
~Q)
I
'5
I
I
e
I
Q)
I a.
I Q)
"'If <, ! "O
~
Q)
::;,
"
" .
I
I
.5
5. Circuito
~ y
8 Módulos
c:
~
:a
1::
Q)
::;,
a.. .!!!
o
6 el
o
'c;, "O
c:
:9 o
sQ)
al "O
o
'c;,
-o
sc:
"O Q)
c: '5
o c:
sc: o
o
Q)
a.
Q)
'0
.~ :~
u..
o
E
.s2
.5
FIGURA 1-10. Esquema genérico de las metodologías y flujos de diseño descen-

dentes (too-aown).
Una vez fijadas las especificaciones, a través del depurado de estos modelos, se
inicia el proceso de refinamiento gradual de la descripción del circuito hasta alcan-
zar un modelo arquitectural-RT que sea sintetizable mediante procesos automáticos
guiados por el diseñador. Este refinamiento también puede afectar el banco de prue-
bas o entorno de test, no para hacerlo sintetizable, sino a fin de ajustar su precisión
a la del modelo del circuito. Un entorno de test cuya temporización se base sólo en
relaciones causales, puede que no sea adecuado para un modelo del circuito que ya
se expresa en términos de ciclos de reloj.
Esta primera fase de refinamiento gradual para pasar de una descripción fun-
cional a una de nivel RT está ahora en vías de automatización y se la conoce como
síntesis comportamental.
A continuación viene la etapa de síntesis RT-lógica que tiene por objeto la ob-
tención de un esquema o lista de componentes y sus interconexiones basado en una
determinada biblioteca de celdas y módulos. El diseño resultante debe realizar la
funcionalidad especificada, respetar las prestaciones requeridas (área, velocidad,
consumo) y garantizar la testabilidad final del circuito. Esto acostumbra a requerir
varias iteraciones de los procesos automáticos de síntesis para la testabilidad dirigi-
da por prestaciones y guiada por el diseñador.
Estas herramientas de síntesis RT-lógica automáticas se implementan mediante
distintos procesos de síntesis encadenados de forma transparente al usuario. Estos
procesos son:
1. Síntesis RT que determina los elementos de memoria y el conjunto de ecua-
ciones lógicas u operadores necesarios, en base a fases de partición, distri-
bución (scheduling) y asignación (allocation) de recursos, bajo las restric-
ciones impuestas por el diseñador.
2. Síntesis lógica que se encarga de optimizar las ecuaciones lógicas para mi-
nimizar el hardware necesario a nivel de puertas y registros utilizando algo-
ritmos de reducción y asignación de estados, minimización lógica, elimina-
ción de redundancias, etc.
3. Mapeo tecnológico que es una fase, muchas veces indistinguible de la sínte-
sis lógica, en la que las puertas y registros se mapean de forma optimizada
sobre los elementos disponibles en la biblioteca de celdas y módulos corres-
pondientes a la tecnología escogida para la implementación física del diseño.
A lo largo de estas fases se ha de incorporar al diseño las estrategias y el hard-
ware necesario para asegurar la posterior testabilidad del circuito. Estos son proce-
sos semiautomáticos, o al menos muy asistidos por el diseñador, que además de
definir la estrategia de test y añadir las estructuras necesarias (scan-paths, multiple-
xores, modos ad-hoc, boundary-scan) se complementan con procesos de genera-
ción y composición de vectores de test que ayudan a obtener un conjunto reducido
y óptimo de tales vectores con una buena cobertura de fallos (>96 %) del circuito.
Dado el estado actual de las herramientas de diseño electrónico, después de la
síntesis RT-lógica siempre hay unas ciertas tareas a nivel de puertas, que se agluti-
nan bajo el nombre de diseño detallado: simulación funcional, temporal y de faltas,
análisis de resultados y optimización de caminos críticos, estructuras y vectores de
test. Un objetivo a perseguir es que las posibles modificaciones resultantes de esta
actividad se reflejen desde los modelos HDL-RT sintetizables para mantener la co-
herencia entre los distintos niveles de descripción del diseño; aunque ello exija nue-
vas iteraciones de síntesis.
Después de esta síntesis RT-lógica y el diseño detallado se obtienen los dos ele-
mentos básicos para poder abordar las fases o etapas de diseño físico: la lista de com-
1. Introducción 29
ponentes y conexiones, las restricciones a cumplir y el conjunto de vectores de test.

Con estas descripciones ya podemos iniciar los procesos de ubicación y conexionado
para generar la topografía y descripciones necesarias para la implementación física del
circuito siguiendo el mismo tipo de mecanismos y flujos (extracción, retroanotación,
simulación post-layout, etc.) enunciados en la fase back-end del diseño ascendente.
1.3.2.2. Información ascendente
En este proceso de refinamiento gradual descendente hay unos flujos de informa-

ción ascendentes que provienen o dependen de las etapas posteriores de diseño y, en
definitiva, de la tecnología final de implementación de cada circuito. Tal como se
muestra en la Figura 1-10, podemos distinguir dos tipos de información ascendente:
• información tecnológica propiamente dicha (parámetros geométricos, eléctri-
cos, retardos, celdas, etc.), que proviene de la tecnología escogida, e
• información que, a través de un proceso de retroanotación, proviene de una
descripción de nivel inferior de abstracción.
La información tecnológica tiene distintos niveles de abstracción, topográfico
(reglas geométricas, área), eléctrico (características de los dispositivos, R-C, con-
sumo), temporal (retrados) o funcional (celdas, módulos, funciones), que le permi-
ten tener una incidencia dinámica directa sobre los distintos procesos y niveles de
construcción y síntesis, y, a través de ellos, sobre las descripciones resultantes. Ac-
tualmente esta información tecnológica empieza a intervenir en las etapas de sínte-
sis lógica y mapeado tecnológico incrementando su incidencia hasta llegar al diseño
físico, que es donde mayor relevancia tiene.
El incremento progresivo del nivel de abstracción de esta información tecno-
lógica permitirá una intervención más temprana en el proceso de diseño y, por lo
tanto, facilitará la evaluación de distintas alternativas tecnológicas y mejores resul-
tados finales dentro de la tecnología escogida. Como contrapartida, a medida que
hagamos un uso detallado de esta información, las descripciones resultantes son ca-
da vez más dependientes de la tecnología y de los procesos de síntesis, que son los
que hacen un uso más o menos inteligente de la información tecnológica.
Por su parte, los procesos de retroanotación se utilizan para inyectar informa-
ción extraída de descripciones de bajo nivel y, por lo tanto, más dependientes de la
implementación final, en descripciones de niveles superiores de abstracción. Un
ejemplo clásico es anotar sobre una netlist los retardos derivados del conexionado
físico del circuito.
En general la retroanotación no requiere de procesos muy elaborados, ya que
sólo transporta y añade información a una cierta descripción. Tiene una incidencia
más bien estática sobre el diseño al no afectar directamente a los procesos de cons-
trucción, aunque sí incida en los criterios de convergencia hacia la solución final a
aplicar en las siguientes iteraciones de síntesis. Otra cosa será cuando la retroanota-
ción se pueda realizar después de una etapa de síntesis RT o comportamental, pues
entonces, además .de extraer y transportar la información, habrá que abstraerla a fin
de anotarla correcta e inteligentemente sobre las descripciones previas a la síntesis.
Otro aspecto a considerar es que no todos los lenguajes HDL tienen estructuras
ni esquemas estándar para facilitar la retroanotación de retardos desde el diseño
físico hasta la netlist HDL correspondiente. El Verilog dispone de mecanismos, ba-
sados en el formato SDF (Standard De/ay Format) [IEEE96], para realizar estos
procesos. Sin embargo, el VHDL no tiene ningún esquema predefinido ni para ex-
presar la temporización (timing) de las celdas y módulos de una biblioteca, ni para
anotar y reflejar los retardos debidos al conexionado en una netlist VHDL. Eso sí,
la flexibilidad del VHDL permite múltiples soluciones para reflejar estas informa-
ciones en los modelos, y ahí es donde reside el problema. Para solucionarlo se están
llevando a cabo distintos proyectos, de los que VITAL puede que sea el más signifi-
cativo por el número de proveedores de CAD y fabricantes de silicio que le dan so-
porte. La idea de VITAL [VITAL94] es adaptar para el VHDL un esquema de tem-
porización y retroanotación, también basado en el SDF y, por lo tanto, altamente
compatible con el utilizado en el contexto del Verilog. Estos procesos de estandari-
zación siempre requieren un compromiso entre flexibilidad del lenguaje (VITAL re-
duce la del VHDL) y eficiencia de los procesos de simulación (VITAL la aumenta
en base al uso de primitivas y estructuras predeterminadas).
Finalmente, y para resumir, vemos (Figura 1-10) que la incidencia de estos flu-
jos de información ascendentes, en las distintas etapas del diseño, marcan un poco el
grado de dependencia tecnológica de las mismas y de las descripciones resultantes.
1.3.2.3. Validación funcional multinivel

La validación funcional multinivel hace referencia a dos tipos de verificaciones o
comprovaciones:
• qué descripciones de un mismo circuito a distintos niveles de abstracción
responden a un mismo comportamiento, o bien,
• qué dos arquitecturas distintas realizan la misma funcionalidad.
Estas tareas se basan fundamentalmente en procesos de simulación y análisis.

En cuanto a las técnicas de verificación formal [BLR97], están todavía en fase de
desarrollo y, aunque en algunos casos pueden ser un buen complemento a la simula-
ción, no las consideraremos de forma explícita en este texto.
Como podemos ver en la Figura 1-10, la validación del proceso de diseño des-
cendente se apoya en la simulación de las distintas versiones y descripciones del
modelo bajo diseño, contra un mismo banco de pruebas y bajo un único entorno de
simulación basado en los HDLs que se estén utilizando.
Bajo el concepto de banco de pruebas (test-bench) tratamos de aglutinar los
distintos tipos de pruebas o validaciones funcionales a realizar sobre un circuito, y
que podemos agrupar en:
• Pruebas globales que tratan de validar la cobertura del documento de especi-
ficaciones por parte del modelo HDL del circuito.
• Pruebas a nivel de sistema para reflejar y validar alguno de los posibles usos
del circuito en su contexto. El entorno de test modelará un prototipo virtual
del sistema proyectado, incluyendo el modelo HDL del circuito.
1. Introducción 31
• Pruebas específicas a nivel de circuito para validar partes concretas del dise-
ño incluyendo varios módulos interconectados y/o distintos modos de opera-
ción.
• Pruebas de test locales y aisladas para distintos módulos y submódulos del
circuito.
• Pruebas de test específicas para la generación del conjunto de vectores de
test (todo o parte) estructural del dispositivo una vez fabricado.
Estos distintos bloques de pruebas que antes (metodologías ascendentes) o no
se desarrollaban o exigían distintos lenguajes y simuladores, ahora se pueden des-
cribir con el mismo HDL con el que se está haciendo el diseño del circuito.
Sea cual sea el tipo de banco de pruebas, éstos acostumbran a tener, dentro de
un equipo o centro de diseño, un esquema más o menos uniforme, pudiendo incluir
distintos módulos con distintos objetivos:
• Modelo del entorno más generación de estímulos hacia el modelo HDL bajo
test.
• Modelo de referencia que proporciona los resultados previstos y esperados.
• Modelo HDL a validar del circuito en fase de diseño.
• Módulo de adquisición, adecuación y comparación de los resultados obteni-
dos del modelo bajo test, respecto a los esperados proporcionados por el mo-
delo de referencia.
• Módulo para la generación de vectores completos (estímulos + respuestas)
para su exportación a otros formatos y entornos de diseño.
Todos estos componentes, u otros que cada equipo de diseño pueda establecer,
conforman el entorno de test del dispositivo en desarrollo y, junto con éste, se des-
criben utilizando el mismo HDL.
Sobre bancos de pruebas hay una presentación genérica de tipo teórico en el
Capítulo 3, que se complementa en los Capítulos 5 y 6 mediante exposiciones más
prácticas y explícitas y con los correspondientes ejemplos de apoyo.
1.4. BIBLIOGRAFíA
[ABF90] MIRON ABRAMOVICI,MELVIN A. BREUER y ARTHUR D. FRIEOMAN:Digital Systems

Testing and Testable Design. Computer Science Press, 1990.
[Asb96] PETER J. ASHENDEN, The Designer's Guide to VHDL. Morgan Kaufmann Publis-
bers, 1996.
[BHNS92] T. J. BARNES, D. HARRISON,A.R. NEwToN Y R. L. SPECKELMIER:Electronic CAD
Frameworks. KIuwer Academic Publisbers, 1992.
[BLR97] JEAN MICHEL BERGÉ, Oz LEVIA & JACQUES ROUILLARO:Hardware/Software Co-
Design & Co- Verification. Current Issues in Electronic Modelling, KIuwer Academic
Publishers, 1997.
[Boi94] Boixareu Editores (varios autores): Microelectrónica: Teoría y Aplicaciones. Mar-
combo S.A. 1984.
[CP96] Comité PRENDA: PRENDA: Metodología para el diseño de ASICs. UPM-ETSII, 1996.
[CU93] Comité UDUI: UDUl Language Reference Manual (V2.0.3). 1993.
[DC97] CARLOS DELGADO KLOOS y EDUARD CERNY (editors), Hardware Description Lan-
guages and their Applications. Specification, modelling, verification and synthesis of
microelectronic systems. IFIP TClO WGI0.5. Chapman&Hall, 1997.
[Eck95] W. ECKER: The design Cube. EuroVHDL Forum, 1995.
[Fab90] E. D. FABRICIUS.Introduction to VLSI Design. McGraw-Hill, 1990.
[Gaj88] DANIELD. GAJSKI(editor). Silicon Compilation. Addison-Wesley, 1988.
[GAS90] R. L. GEIGER, P. E. ALLEN & N. R. STRADER,VLSI Design Techniques for Analog
and Digital Circuits. McGraw-HillI990.
[GD85] LANCE A. GLASSER y DANIEL W. DOBBERPUHL,The Design and Analysis of VLSI
Circuits. Addison-Wesley, VLSI Systems Series, 1985.
[Gia89] J. DI GIANCOMO:VLSI Handbook. McGraw-Hill, 1989.
[Har87] R. W. HARTENSlEIN(editor): Hardware Description Languages. Advances in CAD
for VLSI. Series, Vol. 7. North-Holland, 1987.
[Hay79] JOHN P. RAYES: Computer Architecture and Organization. McGraw-Hill, 1979.
[Hei88] D. V. HEINBUCH: CMOS3 Cell Library. Addison- Wesley, VLSI Systems Series,
1988. .
[HoI87] ERNESTE. HOLLIS: Design of VLSI Gate Array ICs. Prentíce-Hall, 1987.
[HR91] JOHN P. HUBER y MARK W. ROSNECK, Successful ASIC Design the First Time
Through. Van Nostrand Reinhold, 1991.
[HS80] R. W. HON y C. H. SEQUIN:A Guide to LSI Implementation (2nd. edition). SSL-79-
7, Xerox Parco January 1980.
[IEEE81] IEEE: SpecialIssue on Computer Aided Design. Proceedings ofthe IEEE. Oct.-1981.
[IEEE88] IEEE: The IEEE Standard VHDL Language Reference Manual, IEEE-Std-1076-
1987.1988.
[IEEE94] IEEE: The IEEE Standard VHDL Language Reference Manual, ANSIIlEEE-Std-
1076-1993. 1994.
[IEEE95] IEEE: IEEE Standard Verilog Hardware Description Language Reference Ma-
nual. IEEE-Std. 1364-1995.
[lEEE96] IEEE:DASC Standard Delay Format (SDF) Study Group (PAR/497). Vhdl.
org/pub/vilpub/sdf.
[JSV82] PAUL G. JESPERS,CARLO H. SEQUINy FERNANDVAN DE WIELE: Design Methodolo-
gies for VLSI Circuits. NATO ASI Series, Sijthoff & Noordhoff Int. Pub. 1982.
[JTB91] R. W. JOHNSON,ROBERTK.F. TENG & JOHN W. BLADE (editors), Multichip Modules:
Systems Advantages, Major Constructions, and Materials Technologies. IEEE Press, 1991.
[KAJW95] S. KUMAR; J. M. AYLOR; B. B. JOHNSONy W. A. WULF: The Co-Design of Em-
bedded Systems: A Unified Hw/Sw Representation. KIuwer Academic Publishers, 1995.
[LS94]K. R. LAKER & W. M. SANSEN. Design of Analog Integrated Circuits and Systems.
McGraw-HillI994.
[MC80] C. MEAD y L. CONWAY:Introduction to VLSI Systems. Addison- Wesley, VLSI Sys-
tems Series, 1980.
[Mer93] JEAN P. MERMET (editor): Fundamentals and Standards in Hardware Description
Languages. NATO ASI Series, KIuwer Academic Publishers, 1993.
[MLD92] P. MICHEL, U. LAUTHER& P. Duzy (Ed.): The Synthesis Approach to Digital Sys-
tem Design. KIuwer Academic Publishers, 1992.
[Nag75] L. NAGEL: SPICE2: A Computer Program to Simulate Semiconductor Circuits.
ERL Memo. N. ERL-M520. Univ. of California, Berkeley, 1975.
[Nav93] Z. NAVABI:VHDL: Analysis and Modelling of Digital Systems. McGraw-Hill, 1993.
[NB88] P. NAISH y P. BISHOP: Designing ASICs. Ellis Horwood Limited. Chichester, 1988.
1. Introducción 33
[Nov95] NOVATICA(varios autores): «Monografía sobre los lenguajes de diseño de "hardwa-

re"». Revista Novatica (ATI), núms. 112-113, nov, 94-feb. 95.
[Oht86] T. OHTSUKI (editor): Layout Design and Verification. Advances in CAD for VLSI
Series, Volume 4. North-Holland, 1986.
[OVI91] Verilog Hardware Description Language Reference Manual. Open Verilog Intema-
tional. Version 1.0, 1991.
[PL88] BRYANPREAS y MICHAELLORENZETTI(editors): Physical Design Automation of VLSI
Systems. BenjarninlCurnmings Publishing Company, Inc. 1988.
[Que88] HANs QUEISSER:The Conquest of the Microchip. Hardvare University Press, 1988.
[Ris94] L. RISTIC (editor): Sensor Technology and Devices. Artech House, 1994.
[Roc95] ROCHITRAISUMAN:Iddq Testing for CMOS VLS!. Artech House, 1995.
[Roi86] J. ROIG: «Historia de los ordenadores». Revista Informática Test (Haymarket),
núms. 31 a 34, 1986.
[Rub87] STEVENM. RUBIN: Computer Aidsfor VLSI Design. Addison-Wesley, 1987.
[RW91] FRANZ J. RAMMINGY RON WAXMAN(editors): Electronic Design Automation Fra-
meworks. IFIP WG 10.2. North-Holland, 1991.
[Ser94] FRANCESCSERRA 1 MESTRES:Evolució i Límits de la Microelectrónica. Memorias de
la Real Academia de Ciéncias y Artes de Barcelona. Tercera época, núm. 916. Vol.
UII-núm. 1. Barcelona, 1994.
[SK94] M. SRIRAM& S. M. KANG: Physical Design of Multichip Modules. Kluwer Acade-
rnic Publishers, 1994.
[SM94] PETER A. SANDBORN& HÉCTORMORENO: Conceptual Design of Multichip Modules
and Systems. Kluwer Acadernic Publishers, 1994.
[SST90] ELIEZER STERNHEIM,RAIvIR SINGH y YATINTRIvEDI: Digital Design with Verilog
HDL Automata Publishing Company, 1990.
[Sze94] S. M. SZE (editor): Semiconductor Sensors. John Wiley & Sons, 1994.
[Ter86] Luns TERÉS: Generadores automáticos de módulos para circuitos VLS!. Tesis Doc-
toral, Univ. Autónoma de Barcelona, 1986.
[TM91] DONALD E. THOMAS y PHILIP R. MOORBY: The VERILOG Hardware Description
Language. Kluwer Acadernic Publishers, 1991.~,
[TML96] L. TERÉs, M. MORÉ Y E. LECHA: «Los lenguajes de descripción de "hardware" y la
microelectrónica». Revista Fronteras de la Ciencia y la Tecnología (CSIC), núm. 12,
julio-septiembre de 1996.
[Tri94] STEPHEN M. TRIMBERGER(editor): Field-Programmable Gate-array Technology.
Kluwer Academic Publishers, 1994.
[Tsu87] FRANK F. TSUI: LSI/VLSI Testability Design. McGraw-Hill, Inc. 1987.
[Uye88] JOHN P. UYEMURA: Fundamentals of MOS Digital Integrated Circuits. Addison-
Wesley, Electrical and Computer Engineering Series, 1988.
[VITAL94] VITAL INmATIVE: VHDL Initiative Toward ASIC Libraries Model Development
Specification. Version 2.2b. 1994.
[WE85] N. WESTE y K. ESHRAGHIAN:Principies ofCMOS VLSI Design: A Systems Perspec-
tive. Addison-Wesley, VLSI Systems Series, 1985.
[YI89] H. YASUURA & N. ISHIURA: Formal Semantics of UDUI and its Applications to
CAD/DA Tools. IEEE int. Conference on Computer Design: VLSI in Computers and
Processors.1990.
[Zeh94] ALFRED ZEHE (editor): Microelectrónica y diseño de circuitos integrados (ASICs).
Compendio Tecnológico para la Práctica Industrial, volumen 1. Edit. Tecnoplus, 1994.
[WRM+97] J. MEYERS et al.: A CHOS Compatible Smart Power Process with Complete
Dielectric lsolation. 7th European Conference on Power Electronics and Applications,
Brussels, 1997.
Capítulo 2
PRESENTACION
DEL LENGUAJE VHDL
Manel Moré, Joan Vidal, Eduard Lecha, Fernando Rincón y Lluís Terés
IMB-CNM (CSIC)
El secreto de aburrir
a la gente consiste en
decirlo todo.
Voltaire
En este capítulo se realiza una presentación de la sintaxis del lenguaje

VHOL. No se pretende cubrir de forma exhaustiva todas las posibilida-
des del lenguaje (existen muchos libros orientados a una descripción
exhaustiva de su sintaxis, algunos de los cuales se pueden encontrar
en la bibliografía de este capítulo), sino que se intenta cubrir los con-
ceptos del lenguaje, de manera que el lector no iniciado en VHOL pue-
da encontrar en este capítulo la introducción adecuada que le permita
comprender la materia contenida en los siguientes capítulos.
Los contenidos del capítulo se enfocan desde la perspectiva del
VHOL-87, y en los puntos donde las diferencias sean importantes, se
presentan las modificaciones que incorpore el VHOL-93.
El capítulo contiene numerosos ejemplos, destinados a clarificar
cada una de las características del lenguaje. Aparte de estos ejemplos,
al final del capítulo se añaden ejercicios que pueden servir al lector pa-
ra comprobar el grado de madurez adquirida sobre el lenguaje.
35
2.1. INTRODUCCiÓN, CONTEXTO Y CONCEPTOS

BÁSICOS
Tal como indican las siglas de su nombre, VHDL (Very high speed Hardware
Description Language) es un lenguaje orientado a la descripción o modelado de
hardware, pero a pesar de ello hereda muchos conceptos de los lenguajes de pro-
gramación de alto nivel (C, PASCAL, ...) Y especialmente del lenguaje ADA. Por
lo tanto, una buena forma de empezar a conocer algunas de sus principales carac-
terísticas puede ser estableciendo una comparación con dichos lenguajes de pro-
gramación.
VHDL hereda de los lenguajes de programación de alto nivel el concepto de
tipo de datos. A diferencia de muchos otros lenguajes de descripción de hardware
que disponen de un reducido número de tipos de datos (la mayoría de ellos orien-
tados al hardware) y con escasa o nula capacidad de definición de nuevos tipos,
VHDL es un lenguaje que ofrece una enorme flexibilidad para definir nuevos ti-
pos de datos. Existen un reducido número de tipos de datos predefinidos en
VHDL (bit, boolean, integer, etc.), pero incorpora la posibilidad de definir nuevos
tipos, desde tipos discretos o escalares hasta matrices o registros e incluso apunta-
dores. Esta es una característica importante de VHDL, que nos permite describir
sistemas electrónicos a. distintos niveles de abstracción, ya que para cada nivel
de abstracción que queramos abordar, podremos definir el tipo de dato más ade-
cuado.
También hereda de los lenguajes de programación la potencia de control de flu-
jo, incorporando los dos tipos de control de flujo típicos: control de condiciones (if,
case) e iteraciones (jor, while). Estas estructuras de control de flujo, junto con la
capacidad de definición de tipos de datos enunciada en el párrafo anterior, hacen de
VHDL un lenguaje potente para desarrollar algoritmos, que pueden no tener rela-
ción directa con la descripción de hardware.
Incorpora también la capacidad de estructuración del código, pudiendo agrupar
partes del código en subprogramas, ya sean funciones (junction) o procedimientos
(procedures). Esta es otra característica del VHDL heredada de los lenguajes de
programación de alto nivel, y que nos permite afrontar de forma estructurada el de-
sarrollo de algoritmos complejos.
La última característica claramente heredada de los lenguajes de programación
de alto nivel es la posibilidad de desarrollar y utilizar bibliotecas de diseño, de for-
ma que al abordar el desarrollo de cualquier código VHDL dispongamos de un con-
junto de tipos de datos, operadores y funciones ya definidos, indicados para el área
concreta en la que vayamos a trabajar.
Las características descritas hasta aquí presentan VHDL como un lenguaje pa-
recido a los lenguajes típicos de programación de alto nivel. De hecho, aquellas
personas que tengan cierta experiencia en el uso de dichos lenguajes encontrarán
muchas analogías que les facilitará el aprendizaje del VHDL. De todas formas hay
una serie de conceptos incorporados en VHDL específicos para el modelado de
hardware, que normalmente son un poco más difíciles de asimilar para todo aquel
que se enfrente con el aprendizaje de este lenguaje.
2. Presentación del lenguaje VHDL 37
2.2. UN MODELO DEL HARDWARE
Tres son las características principales que incorpora VHDL enfocadas a facilitar o
permitir la descripción de hardware: un modelo de estructura, un modelo de concu-
rrencia y un modelo de tiempo. Estas características junto con la capacidad de des-
cribir funcionalidad que le confieren las propiedades descritas en la sección ante-
rior, hacen de VHDL un lenguaje flexible y potente, que se adapta perfectamente a
la descripción de sistemas electrónicos a cualquier nivel de abstracción.
2.2.1. Modelo de estructura: componentes y jerarquía

De forma natural cualquier sistema electrónico puede dividirse en subsistemas más
pequeños (hasta llegar al nivel de puertas, que serían las primitivas del diseño digi-
tal). Por ello VHDL incorpora el concepto de estructura. Esta característica nos per-
mite realizar el modelo de un sistema digital cualquiera a partir de la referencia a
las distintas partes que lo forman y especificando la conexión entre éstas. Cada una
de las partes, a su vez, pueden estar modeladas de forma estructural a partir de sus
componentes, o bien estar descritts de forma funcional, usando los recursos de des-
cripción algorítmica del lenguaj~. Siempre en el último nivel de jerarquía nos en-
contraremos con modelos funcionales, a partir de los cuales se habrá construido el
sistema completo.
Al describir cualquier dispositivo en VHDL (desde una puerta hasta un sistema
completo) el diseñador debe definir dos elementos principales: la interfaz del dispo-
sitivo con el exterior (la entidad o entity) y la descripción de la funcionalidad que
realiza el dispositivo (la arquitectura o architecture). La interfaz de un dispositivo
tiene por objeto definir qué señales del dispositivo son visibles o accesibles desde el
exterior, lo que se llama los puertos (ports) del dispositivo. En la arquitectura se de-
finirá la funcionalidad que implementa dicho dispositivo, o sea, qué transformacio-
nes se realizarán sobre los datos que entren en los puertos de entrada, para producir
nuevos valores sobre los puertos de salida.
Para poder utilizar elementos ya definidos en VHDL (por el mismo diseñador o
disponibles en bibliotecas de diseño) en descripciones estructurales de un nuevo di-
seño, VHDL incorpora el concepto de componente (component) y de referencia a
un componente. Cualquier elemento modelado con VHDL puede ser usado como
un componente de otro diseño. Para ello solamente es necesario hacer referencia al
elemento a utilizar y conectar los puertos de su interfaz a los puntos necesarios para
realizar el nuevo diseño. La Figura 2-1 ilustra esta idea, el sistema bajo desarrollo
se forma a partir de dos subsistemas que se habrán definido con anterioridad. El di-
señador sólo debe preocuparse de las entradas y salidas de los subsistemas (su inter-
faz) y de la forma adecuada en que debe conectarlas para formar el nuevo sistema,
pero no es necesario conocer cómo está descrito cada uno de los subsistemas.
En el ejemplo de la figura se dispone de dos componentes (una puerta and de
dos entradas y una puerta or de dos entradas) y en el código se hace referencia a
esos dos componentes, tomando una copia o referencia de cada uno de ellos y co-
nectándolos de la forma que se indica en el gráfico. Cada vez que varíe el valor de
U1: AN02 (a, b, e);

U2: OR2 (e, d, e);
a
b ANO
r1_ e
d OR
FIGURA 2-1. Modelo de estructura en VHOL.
alguno de los puertos de entrada de una de las puertas, ésta ejecutará su función,
pudiendo variar el valor de su puerto de salida. Obsérvese que si la puerta and pro-
duce un cambio sobre su puerto de salida e, éste implicará que la puerta or ejecute
su función, pudiendo a su vez forzar un cambio en su puerto de salida e. Este com-
portamiento es el mismo que se observa en el hardware real.
Este mecanismo que incorpora VHDL es análogo al mecanismo de diseño
clásico utilizado en la captura de esquemáticos. Cualquier modelo VHDL puede
abordar el diseño de un nuevo componente, desde una aproximación puramente es-
tructural, referenciando los componentes que lo forman y estableciendo las interco-
nexiones entre ellos. Los componentes pueden ser tan simples como las puertas ló-
gicas del ejemplo, o bien tan complejos como un sistema electrónico completo.
Obsérvese que este mecanismo básico del VHDL de modelado de la estructura
(la copia o referencia a componente) ofrece a su vez la forma de especificar lajerar-
quía de un diseño.
2.2.2. Modelo de concurrencia: procesos, señales

y eventos
El hardware es por definición concurrente, en última instancia cualquier dispositivo

digital está formado de un mar de puertas lógicas, todas ellas funcionando en para-
lelo. El elemento básico que ofrece VHDL para modelar paralelismo es el proceso
(process).
Un proceso puede entenderse como un programa, se compone de sentencias,
puede llamar a subprogramas, puede definir datos locales, etc. En general, un pro-
ceso describe comportamiento (usando las capacidades de descripción funcional de
VHDL) y el código que contiene se ejecuta de forma secuencial. Pero todos los pro-
cesos contenidos en una descripción VHDL se ejecutarán de forma paralela. Desde
este punto de vista un modelo VHDL puede entenderse como un mar de programas
secuenciales ejecutándose de forma paralela. De hecho, cualquier descripción

VHDL (independientemente de las construcciones del lenguaje que utilice) es trans-
formada en un conjunto de procesos concurrentes equivalentes, y este mar de pro-
cesos concurrentes es la información de entrada del simulador.
Estos procesos que se ejecutan concurrentemente deben poder comunicarse
(sincronizarse) entre ellos. El elemento necesario para comunicar dos procesos es la
señal (signal). Cada proceso tiene un conjunto de señales a las que es sensible. Ser
sensible a una señal significa que en cuanto se produzca un cambio en el valor de
dicha señal (un evento en la señal), el proceso se ejecutará hasta que encuentre una
sentencia de suspensión del proceso (wait). Al llegar a esta sentencia, el proceso
quedará suspendido, esta suspensión será por un periodo determinado de tiempo, o
bien hasta que se produzca un nuevo evento en alguna de las señales a las que sea
sensible dicho proceso. Aparte de poder suspender la ejecución de un proceso (sen-
tencia wait), éste es un bucle infinito, o sea, al llegar a su final vuelve a ejecutarse
desde el principio.
Para ilustrar mejor este concepto, la Figura 2-2 define los procesos equivalen-
tes a una puerta and y una puerta or de dos entradas cada una.
El primer proceso (and2) se ejecuta cada vez que se produce un cambio (even-
to) en el valor de la señal a o de la señal b. Cuando se produzca el cambio se ejecu-
ta el proceso y, por tanto, asigna a su salida e el valor de la expresión lógica a and
b. A continuación el proceso se suspende, hasta que se produzca un nuevo evento
sobre a o b. De hecho ésta es la forma como trabaja una puerta lógica real, sola-
mente puede cambiar el valor que asigna a su salida, cuando se produce un cambio
en alguna de sus entradas.
El proceso OR2 funciona de la misma forma. Solamente notar que en este
ejemplo se utiliza la señal e para sincronizar los dos procesos, siempre que se pro-
duzca un evento en la señal e, se ejecutará el proceso OR2.
Por supuesto, y dado el paralelismo en la ejecución de los procesos, si en un
momento de la simulación se producen eventos sobre las señales de la lista de sen-
AND2 : process
begin
e < = aand b;
wait on a, b;
end process AND2;
OR2: process
begin
e <= e or d;
wait on e, d;
end process OR2;
FIGURA 2-2. Modelado de concurrencia en VHDL.

sibilidad de ambos procesos (por ejemplo, en a y en e), los dos se ejecutan en ese
tiempo de simulación.
Sobre las señales sólo diremos de momento que son objetos que pueden ir
variando su valor a lo largo de la simulación (en este aspecto son parecidas a las va-
riables). Su característica principal es que tienen asociada una o varias colas de
eventos (drivers) que define su comportamiento a lo largo del tiempo. La cola de
eventos está formada por conjuntos de pares tiempo/valor, y en las asignaciones a
señal es esta cola de-eventos la que recibe los valores asignados. En las siguientes
secciones veremos cómo el mecanismo de simulación VHDL define en qué mo-
mento los valores asignados a la cola de eventos de una señal pasan a actualizar el
valor de la misma.
2.2.3. Modelo de tiempo: ciclo de simulación
Una de las finalidades del modelado en VHDL del hardware es poder observar su
comportamiento a lo largo del tiempo (simulación). Esto implica que las construc-
ciones del lenguaje tendrán asociada una semántica respecto a la simulación, es de-
cir, influirán en ésta provocando distintos eventos (cambios en las señales que con-
trolan la evolución del sistema) que se sucederán a lo largo del tiempo, y a su vez,
el modo en que se comportan las sentencias dependerá de los eventos que se suce-
dan a lo largo de la simulación. El concepto de tiempo es fundamental para definir
cómo se desarrolla la simulación de una descripción VHDL.
La simulación de un modelo VHDL es una simulación dirigida por eventos.
Esto significa que el simulador mantiene unas listas, de eventos (cambios en las se-
ñales internas del modelo y también de las entradas y salidas) que se han de produ-
cir a lo largo del tiempo de simulación. Como el comportamiento del modelo es es-
table mientras no se produzca un evento, la tarea del simulador consiste en avanzar
el tiempo de simulación hasta el siguiente evento y calcular sus consecuencias so-
bre la lista de eventos futuros (mediante la ejecución de los procesos afectados por
el evento actual).
Normalmente la reacción del modelo a un evento ocasionará otros eventos a
suceder en un tiempo de simulación posterior que se añadirán a la lista. De este mo-
do la simulación finaliza cuando se ha alcanzado el tiempo de simulación especifi-
cado por el usuario o cuando no existen más eventos.
La simulación VHDL abstrae el comportamiento real del hardware, implemen-
tando el mecanismo de estímulo respuesta (componentes funcionales reaccionan a
la actividad en sus entradas produciendo cambios en sus salidas) implementando un
ciclo de simulación de dos etapas (Figura 2-3), basado en los procesos (elementos
funcionales) y las señales (entrada y salidas de estos elementos funcionales; cone-
xiones entre elementos).
En la primera etapa las señales actualizan su valor. Esta etapa finaliza cuando
todas las señales que debían obtener un nuevo valor en el tiempo actual de simula-
ción (tenían un evento programado en su cola de eventos) han sido actualizadas. En
la segunda etapa, los procesos que se activan (aquellos que tengan en su lista de
sensibilidad una señal en la que se haya producido un evento) se ejecutan hasta que
2. Presentación del lenguaje VHOL 41
Inicio simulación
Actualizar señales Ejecutar procesos
Final simulación
FIGURA 2-3. Ciclo de simulación VHDL.
se suspenden (con la ejecución de una sentencia wait). Esta etapa finaliza cuando
todos los procesos que se habían activado se hayan suspendido. Entonces el tiempo
de simulación avanza hasta el siguiente instante de tiempo en el que haya un evento
programado, y se repiten los dos pasos del ciclo de simulación. La simulación ter-
mina cuando no haya más eventos programados o cuando se llegue al tiempo de si-
mulación especificado.
Es importante notar que el modelo de tiempo implementado por el ciclo de si-
mulación VHDL implica que siempre hay un cierto retardo entre el momento en
que un proceso coloca un nuevo valor en la cola de eventos de una señal (el proceso
ejecuta la asignación sobre la señal) y el momento en que esta señal toma el valor
programado en la cola de eventos. Incluso en el caso en que no se especifique un
retardo concreto, se utilizará un retardo delta (delta delay). Un retardo delta no im-
plica actualizar el tiempo de simulación, pero sí que implica ejecutar un nuevo ciclo
de simulación.
El concepto de retardo delta es importante para entender otra diferencia impor-
tante entre variable y señal. Una variable actualiza su contenido en cuanto se ejecu-
ta una asignación sobre ella. En cambio, cuando se ejecuta una asignación sobre
una señal, se proyecta un nuevo evento sobre su cola de eventos y sólo cuando to-
dos los procesos se hayan ejecutado y estén suspendidos, el valor de la señal se ac-
tualizará con el valor proyectado en su cola de eventos.
Este mecanismo del retardo delta se introduce para permitir la simulación de
hardware (paralelo por naturaleza) usando máquinas secuenciales, y es el que per-
mite asegurar el determinismo de la ejecución del código VHDL. Consideremos el
código VHDL de la Figura 2-4, en el aparecen dos elementos secuenciales conecta-
dos en forma de registro de desplazamiento.
El mecanismo del retardo delta permite que, independientemente del orden en
que se ejecuten los dos procesos, el segundo (FF2) siempre reciba el valor correcto
de Q1, ya que aunque se haya ejecutado con anterioridad el primer proceso (FF 1),
FFl : process
D1 01
begin r--
ir CK=' l' then
FF1
Ql <= DI
CK
end ir;
waiton Clk; >
end process FFl~
FF2 : process
begin 02
..._
ir CK=' l' then
Q2 <= Ql FF2
end ir;
CK
wait on Clk;
end process FF2;
>
FIGURA 2-4. Determinismo en la simulación VHDL.
la asignación que éste realiza sobre QI aún no habrá tenido lugar (en todo caso se
habrá proyectado el evento sobre la cola de eventos de QI). De forma que al reali-
zar la asignación de DI sobre Q2 se colocará en la cola de eventos de Q2 el valor
correcto de DI (aún sin actualizar). Sólo en el momento en que ambos procesos se
hayan suspendido, se actualizarán las señales con los valores que contengan sus co-
las de eventos.
Para clarificar el funcionamiento del ciclo de simulación y del retardo delta, en
la Figura 2-5 se muestra cómo se comportaría la simulación VHDL y cómo evolu-
cionarían las señales QI y Q2 (y sus respectivas colas de eventos). Para ello se su-
pone que el reloj CK se ha definido como un reloj de IOns de periodo y que la señal
de entrada DI toma los valores reflejados en la figura. Tomando CK y DI como es-
tímulos se muestra la respuesta del ciclo de simulación. Nótese que en realidad los
valores que toman CK y DI también son consecuencia de.la forma en que el ciclo
de simulación actúa sobre estas señales, pero por simplicidad sólo mostramos la
evolución de QI y Q2.
Obsérvese que si las señales tomasen sus nuevos valores en el instante en que
se realiza la asignación sobre ellas, la ejecución del ejemplo anterior daría como re-
sultado valores distintos sobre las señales QI y Q2, dependiendo del orden en que
se ejecutasen los procesos FFI y FF2.
Estímulos a la simulación
CK
.·,
le
D1 J ··
,
.
10 ns 20 ns 30 ns
Respuesta de la simulación
Tilempo de simulación Acción simulación Valor señales Cola eventos

01 02 01 02
Actualizar señales _____ (-ºJ __ JQL ___--- ...... _-------_.

10 ns --------------------
Ejecutar procesos
1 O
Actualizar señales 1 O
10 ns + o ns -------------------- ------ ... ---------- -_ .. ----- ... _--_ ......
Ejecutar procesos - -
Actualizar señales (1) (01
20 ns -------------------- ----------------- ----------- ...........
Ejecutar procesos 1 1
1 1
20 ns + o ns Actualizar señales
-------------------- ----------------- ----_ .. _---------
Ejecutar procesos - -
(*) valor anterior que ya contenía la señal.
FIGURA 2-5. Ciclo de simulación y retardo delta.
2.3. UNIDADES BÁSICAS DE DISEÑO
Una unidad de diseño es una construcción VHDL que puede ser analizada indepen-
dientemente; en este momento se puede considerar que el análisis de una unidad de
diseño es análogo a la compilación de un programa, más adelante, en el Capítulo 3,
se describirá con detalle el proceso de análisis. Existen cinco tipos diferentes de
unidades de diseño: la declaración de entidad (entity declaration), la arquitectura de
una entidad (architecture J, la configuración (configuration J, la declaración de pa-
quete (package declaration) y el cuerpo del paquete (package body). La declaración
de entidad, la declaración de paquete y la configuración se llaman unidades prima-

rias, mientras que la arquitectura de entidad y el cuerpo de paquete se consideran
unidades secundarias porque dependen de una entidad primaria que debe ser anali-
zada antes de poder ser analizadas ellas mismas.
Un dispositivo se representa en VHDL mediante una entidad, que consta de
una declaración de entidad, donde se da una visión externa del dispositivo definién-
dose la interfaz con su entorno, y una arquitectura, donde se define su funcionali-
dad. Para poder probar diferentes opciones a la hora de modelar un dispositivo,
VHDL permite definir múltiples arquitecturas asociadas a una única entidad. La
configuración es la construcción encargada de seleccionar la arquitectura específica
que se va a utilizar para una entidad.
En VHDL cada objeto debe ser declarado antes de utilizarse. En general, las
declaraciones se realizan en las unidades de diseño donde estos objetos son necesa-
rios, por lo que no serán visibles en las demás unidades. Para declaraciones útiles
para varias unidades de diseño, VHDL proporciona el paquete, que evita la multi-
plicidad de declaraciones comunes. Normalmente el paquete se divide en dos uni-
dades de diseño VHDL: la declaración y el cuerpo del paquete.
En las siguientes secciones de este apartado se van a explicar más detallada-
mente las características más importantes de cada unidad de diseño y de las biblio-
tecas donde estas unidades se almacenan para su futuro uso una vez analizadas.
2.3.1. Declaración de entidad

La declaración de una entidad sirve para definir la visión externa del dispositivo
que dicha entidad representa, es decir, la interfaz con su entorno. VHDL separa esta
visión externa de la implementación concreta del dispositivo para dar la posibilidad
de que ésta quede oculta. De este modo, después de haber analizado la declaración
de una entidad y, por tanto, haberla almacenado en una biblioteca, esta entidad po-
drá ser utilizada por otros diseños que sólo requieren de dicha interfaz para usarla.
La sintaxis VHDL para declarar una entidad es la siguiente:
entity identificador iB
[genéricos)
[puertos)
[declaraciones 1
[begin sentencias)
end [entity) [identificador) ;
El identificador es el nombre que va a recibir la entidad y servirá para poder re-

ferenciarla más tarde. En caso que se repita el identificador al final de la declara-
ción, éste debe ser idéntico al definido en la primera línea o se detectará un error
sintáctico al analizar la declaración.
Excepto la primera y la última línea de la declaración, todas las demás son op-
cionales, por lo que la entidad mínima sería la siguiente:
entity identificador iB
end;
Esta entidad no tiene ninguna comunicación con el exterior, por lo que no pue-
de ser reutilizada en ningún otro diseño. No obstante, entidades de este tipo pueden
utilizarse para describir sistemas completos (ver Capítulo 5).
De entre las partes opcionales de la declaración de una entidad cabe destacar la
declaración de los puertos, que determinan la interfaz del dispositivo con el exte-
rior. Para comprender qué son los puertos de una entidad se puede hacer una com-
paración entre éstos y las patillas de un circuito. Para cada puerto se tendrá que in-
dicar el nombre, el tipo y el modo. El nombre se utilizará para poder referenciarlo,
el tipo definirá la clase de información que se transmitirá por el puerto mientras que
el modo servirá para definir la dirección de la información, en el sentido que los
puertos podrán ser de entrada, de salida o bidireccionales. Opcionalmente también
puede asignarse un valor por defecto que se tendrá en cuenta sólo en caso que el
puerto esté desconectado. Por ejemplo, la declaración de una entidad que imple-
mente un multiplexor de dos bits sería:
entity Mux21 is
port ( a in bit;
b in bit;
ctr l in bit;
z out bit);
endr
En la Figura 2-6 se muestra el diagrama equivalente. Como puede apreciarse

sólo se indica cómo debe comunicarse el dispositivo con su entorno sin dar ningún
detalle de su implementación. En otras palabras, la declaración de cualquier entidad
que tenga tres entradas y una salida de tipo bit, sea cual sea su funcionalidad, será
idéntica a la declaración de este multiplexor, cambiando seguramente los nombres
de la entidad y de los puertos.
Además de los puertos, en la declaración de una entidad se ha visto que hay
otras partes opcionales, concretamente genéricos, declaraciones y sentencias.
Los genéricos son un conjunto de parámetros que permiten modificar la funcio-
nalidad al referenciar la entidad, de esta forma se consiguen descripciones más ge-
nerales. Por ejemplo, al describir un dispositivo que sea un sumador de dos valores
enteros, se pueden introducir como genéricos el número de bits de los operandos.
De esta forma, se podrá usar una única entidad sumador para sumadores de cual-
quier tamaño. Más adelante en este capítulo, cuando se hable de cómo referenciar
MUX21
a bit
b
ctrl
bit
bit .[ lb. z
FIGURA 2-6. Diagrama de la interfaz del multiplexor de dos bits.

componentes desde una descripción estructural se verá con más detalle cómo fun-
cionan los genéricos.
Las declaraciones y las sentencias normalmente no forman parte de la declara-
ción de una entidad, ya que en principio tienen poco que ver con la interfaz del dis-
positivo y mucho con su implementación, por lo que es más natural incluirlas den-
tro de su arquitectura. No obstante, debido a que para una entidad pueden definirse
muchas arquitecturas distintas, a veces se declaran objetos comunes a todas las ar-
quitecturas para no tener que declararlos en cada arquitectura. Por lo que a las sen-
tencias se refiere, pueden incluirse siempre que sean pasivas en el sentido que no
afecten a la funcionalidad del dispositivo. Son típicas las sentencias que hacen com-
probaciones sobre las entradas para detectar, por ejemplo, configuraciones prohibi-
das o violaciones de tiempos.
2.3.2. Arquitectura
La arquitectura sirve para definir la funcionalidad de la entidad que representa.

Describe un conjunto de operaciones sobre las entradas de la entidad que determi-
nan el valor de las salidas en cada momento. Antes de poder ser analizadas es im-
prescindible haber analizado la declaración de la entidad, de modo que cuando ésta
se modifique la arquitectura tendrá que ser reanalizada.
La sintaxis VHDL para definir la arquitectura de una entidad es la siguiente:
architecture identificador of identificador_entidad i8
[declaraciones]
begin
[sentencias concurrentes]
end [architecture] [identificador];
El identificador es el nombre que va a recibir la arquitectura y servirá para refe-

renciarla más tarde. Este identificador puede repetirse al final de la definición de la
arquitectura. Además de dar un nombre para la arquitectura debe indicarse el nom-
bre de la entidad a la que pertenece. La zona destinada a declaraciones sirve para de-
clarar elementos necesarios para la descripción de la arquitectura, dichos elementos
pueden ser, por ejemplo, constantes, tipos de datos o señales internas; en los próxi-
mos apartados de este capítulo se verán con más detalle todas estas cuestiones.
La sección de sentencias concurrentes describe propiamente la funcionalidad
del dispositivo. Existen muchos tipos de sentencias concurrentes, más adelante en
este capítulo se dedica un apartado a describirlas. Dependiendo del tipo de senten-
cias utilizadas se puede modelar una arquitectura siguiendo diferentes estilos:
• Estilo algorítmico: define la funcionalidad del componente mediante un al-
goritmo compuesto por un conjunto de instrucciones que se ejecutan secuen-
cialmente.
• Estilo flujo de datos: modela la arquitectura como un flujo de datos entre dis-
tintos módulos encargados de .implementar funciones u operadores.
• Estilo estructural: define la arquitectura como un conjunto de componentes
interconectados.
En las siguientes secciones de este subapartado se discuten las principales ca-

racterísticas de estos estilos de descripción.
2.3.2.1. Estilo algorítmico
El estilo algorítmico define la funcionalidad del dispositivo mediante un algoritmo

ejecutado secuencialmente, de forma muy parecida a como lo hace cualquier pro-
grama escrito en un lenguaje de programación común, como puede ser e o Pascal.
Por tanto, no se hace ninguna referencia a la estructura que se seguirá para imple-
mentar el algoritmo en hardware.
La arquitectura del multiplexor de dos bits declarado anteriormente utilizando
un estilo de modelado algorítmico sería:
architecture Algoritmico of Mux2l ls

begin
process (a, b, ctrl)
begin
if (ctrl = '0') then
z <= a;
else
z. <= b;
end if;
end process;
end Algoritmico;
Más adelante en este capítulo se verán con detalle las sentencias utilizadas en
el código. En este momento se puede decir que un proceso, definido mediante la pa-
labra clave process, es una sentencia concurrente, en el sentido que todos los proce-
sos se ejecutan simultáneamente, que está formado por una o más instrucciones se-
cuenciales. Por está razón, una arquitectura con un solo proceso es equivalente a un
algoritmo ejecutado secuencialmente.
2.3.2.2. Estilo flujo de datos
Una descripción en estilo de flujo de datos refleja la funcionalidad de un dispositivo

mediante un conjunto de ecuaciones ejecutadas concurrentemente, que determinan
el flujo que van a seguir los datos entre módulos encargados de implementar las
operaciones. En este estilo ya existe una correspondencia directa entre el código y
su implementación hardware. Suele considerarse que este tipo de descripción es
funcional y estructural al mismo tiempo, ya que define tanto el comportamiento de
los módulos como su interconexión con los demás módulos.
El multiplexor de dos bits declarado anteriormente siguiendo un estilo de des-
cripción de flujo de datos sería:
architecture FlujoDatos of MuX2l ls

signal ctrl_n, nl, n2 : bit;
begin
ctrl_n <= not (ctrlJ after 1 ns;

nl <= ctrl_n and a after 2 ns;
n2 <= ctrl and b after 2 ns;
z <= (nl ar n2J after 2 ns;
end FlujoDatos;
En este caso todas las operaciones que se tendrían que llevar a cabo serían de
tipo lógico y se podrían implementar mediante una sola puerta. En general las ope-
raciones pueden ser mucho más complejas siendo necesarios módulos más grandes
para implementarlas, por ejemplo, sumadores, multiplicadores o desplazadores de
varios bits. El ejemplo incorpora tres señales internas para definir la interconexión
de los diferentes operadores y asocia un valor de retardo a cada operación mediante
la cláusula after, que se verá más adelante en este capítulo al hablar de las asigna-
ciones a señales.
2.3.2.3. Estilo estructural
Una arquitectura definida utilizando el estilo estructural consiste en un conjunto de

componentes interconectados mediante señales. Un ejemplo típico de descripción
utilizando este estilo es la representación de un circuito como una lista de compo-
nentes interconectados (netlist) de una biblioteca de celdas estándar de una tecnolo-
gía determinada. La descripción es puramente estructural en el sentido que no in-
cluye ningún tipo de funcionalidad, ésta en todo caso está incluida en la definición
de la arquitectura de los componentes que forman la descripción.
El multiplexor de dos bits declarado anteriormente podría describirse en estilo
estructural como un conjunto de puertas interconectadas de la siguiente manera:
architecture Estructural of Mux21 is

signal ctrl_n, nl , n2 : bit;
component; INV
port ( Y : in bit;
z : out bit);
end c~nent;
c~nent AND2
port (x in bit;
y : in bit;
z : out bit):;
end c~nent;
c~nent OR2
port (x in bit;
y : in bit;
z : out bit)¡
end c~nent;
begin
UO: INV port map (ctrl, ctrl_n);
U1: AND2port map (ctrl_n, a, nI);
U2: AND2port map (ctrl, b, n2);
U3: OR2 port map (nl , n2, z);
end Estructural;
En esta descripción se ve que en primer lugar es necesario declarar los compo-

nentes que se van a utilizar en la arquitectura. Para hacerlo hace falta definir la in-
terfaz de dichos componentes para poder comprobar que se conectan de forma co-
rrecta. A continuación se deben referenciar los componentes y conectar las señales
para conseguir la estructura deseada. Para cada referencia hay que dar un nombre
único para poder diferenciarla de otras referencias al mismo componente. Más ade-
lante en este capítulo se hablará con más detalle de cómo referenciar componentes
dentro de una arquitectura y de las posibilidades que existen para hacerlo.
2.3.2.4. Estilo mixto
Este subapartado sólo sirve para remarcar que aunque se hayan explicado diferentes
estilos para describir una arquitectura VHDL y se hayan dado ejemplos de cada uno
de ellos, todos estos estilos pueden mezclarse en la implementación de una sola ar-
quitectura. De este modo, una arquitectura puede estar formada, por ejemplo, por
varios procesos descritos mediante el estilo funcional, juntamente con un conjunto
de ecuaciones (procesos de una sola línea) que determinen un flujo de los datos y
una serie de referencias a otros componentes de más bajo nivel. Por lo tanto, el gra-
do de flexibilidad que permite VHDL en este sentido es muy importante.
2.3.3. Configuración
La configuración es la construcción VHDL encargada de seleccionar la arquitectura
que se quiere utilizar para una entidad concreta. Como se ha comentado anterior-
mente, VHDL permite definir más de una arquitectura por entidad para facilitar el
estudio de varias posibilidades a la hora de implementarla.
La sintaxis VHDL para definir una configuración es la siguiente:
configuration identificador of identificador_entidad is

for identificador_arquitectura
{ for {ref_componente {, •..} I others I all) :. id....cauponente
use entity id_entidad[(id_arquitectura); I
use configuration id_configuración;]
end for; }
end for;
end [configuration] [identificador];
El identificador es el nombre que va a recibir la configuración y servirá para

poder referenciarla más tarde. En caso que se incluya el identificador al final de la
declaración debe coincidir exactamente con el que se haya incluido en la primera
línea. Aparte de aportar un nombre, es necesario identificar la entidad y la arquitec-
tura relacionados en la configuración mediante sus identificadores respectivos.
Cuando el diseño sea jerárquico, también pueden determinarse las entidades y ar-
quitecturas que se van a utilizar para los componentes de más bajo nivel. En este
caso es necesario relacionar las referencias de los componentes con una entidad y
una arquitectura o bien indicar la configuración que se quiere usar para cada com-
ponente. Como se podría dar el caso de que dos referencias de un mismo compo-
nente utilizaran diferentes arquitecturas (o entidades), se da flexibilidad para confi-
gurar todas las referencias de un componente a la vez o por separado.
La configuración del multiplexor de dos bits utilizado en los subapartados ante-
riores en el caso que se quiera trabajar con la arquitectura llamada FlujoDatos sería:
configuration Mux21_cfg of Mux21 is
for FlujoDatos
end for;
end Mux21_cfg;
Para ver un ejemplo donde se muestre una configuración de un modelo jerár-

quico, se puede considerar que para cada componente usado en la implementación
de la entidad Mux21 a nivel estructural existe una entidad con el mismo nombre y
una arquitectura llamada Algoritmico almacenadas en la biblioteca de trabajo. En
este caso se podría definir la siguiente configuración:
configuration Mux21_cfg of Mux21 is
for Structural
for UO : INV use work.entity INV(Algoritll\ico); end ford;
for all : AND2 use work.entity AND2(Algoritmico); end ford;
for U3 : OR2 use work.entity OR2(Algoritmico); end ford;
end ford;
end Mux21_cfg;
En caso que no se defina ninguna configuración para una entidad y sus arqui-
tecturas asociadas, hay muchas herramientas comerciales que utilizan por defecto la
arquitectura que haya sido analizada en último lugar.
2.3.4. Paquetes
Un paquete permite agrupar un conjunto de declaraciones para que puedan ser usa-
das por varios dispositivos sin ser repetidas en la definición de cada dispositivo. De
esta forma se facilita la reutilización y la actualización del código.
Normalmente en un paquete se suelen declarar constantes, tipos y subtipos de
datos, subprogramas y componentes. Más adelante en este capítulo se verá con más
detalle el significado y la utilización de cada uno de estos elementos del lenguaje.
Un aspecto importante del paquete es que, al igual que pasaba con las entida-
des, se divide en dos unidades de diseño diferenciadas: la declaración y el cuerpo
del paquete. La declaración de paquete aporta la visión externa de los elementos
que se declaran mientras que el cuerpo del paquete define su implementación. De
este modo se pueden ocultar los detalles de implementación a un diseñador que
puede estar interesado en cómo utilizar un elemento pero no necesita saber cómo
está implementado. Por esta razón, en la declaración de un paquete suelen declarar-
se los subprogramas dándoles un nombre y la lista de parámetros necesarios para
llamarlos sin incluir su cuerpo. Respecto a las constantes, se pueden declarar en la
declaración del paquete y darles un valor en el cuerpo del paquete o bien incluir to-
da la información sólo en la declaración del paquete. La declaración de componen-
tes es muy útil, por ejemplo, para bibliotecas de celdas, de este modo los diseños
pueden utilizarlas sin tener que añadir una larga declaración de componentes al ini-
cio de su arquitectura. En este caso sólo es necesario la interfaz de la celda, por lo
que la declaración se pondrá en la declaración del paquete. Por último, al declarar
tipos y subtipos de datos ya se da toda la información, por lo que suelen ponerse só-
lo en la declaración del paquete, mientras que en el cuerpo del paquete pueden apa-
recer declaraciones de tipos y subtipos útiles para el cuerpo de los subprogramas.
La sintaxis VHDL para declarar un paquete es la siguiente:
package identificador
[declaraciones]
end [package] [identificador];
Para el cuerpo del paquete la sintaxis VHDL es:

package boQy identificador is
[declaraciones cuerpo],
end [package boQy] [identificador];
El identificador es el nombre que va a recibir el paquete y va a servir para refe-

renciarlo más tarde. Este identificador puede repetirse al final de la declaración. Co-
mo puede apreciarse, la sintaxis es muy parecida para la declaración y el cuerpo del
paquete, la única diferencia reside en la naturaleza de las declaraciones de las dos uni-
dades. Al analizar el cuerpo de un paquete es imprescindible haber analizado la decla-
ración antes, de forma que si ésta varía se tendrá que reanalizar el cuerpo del paquete.
Por ejemplo, podría utilizarse un paquete para definir el retardo de los operado-
res lógicos not, and y oro Aunque se puede incluir toda la información en la decla-
ración del paquete, en el ejemplo se utiliza el cuerpo del paquete para dar valor a
las constantes:
Package RetardosOp is
constant RetNOT : time;
constant RetAND2 : time;
constant RetOR2 : time;
end RetardosOp;
Package boQy RetardosOp is
constant RetNOT : time := 1 M;
constant RetAND2 : time := 2'ns;
constant RetOR2 : time := 2 ns;
end RetardosOp;
Cuando se analiza un paquete, el resultado del análisis queda almacenado en

una biblioteca para poder ser usado más adelante. La forma de utilizarun elemento
de un paquete desde un dispositivo es identificando el nombre de biblioteca, paque-
te y elemento. Las bibliotecas se explicarán en el próximo subapartado de este capí-
tulo, de momento se puede pensar que el paquete está almacenado en una biblioteca
llamada Biblio. Teniendo esto en cuenta, para utilizar por ejemplo la constante Ret-
NOT declarada en el paquete RetardosOp se tendrá que escribir:
Biblio. RetardosOp. RetNOT
52 VHDL Lenguaje estándar de Diseño Electrónico
El paquete acabado de definir podría utilizarse, por ejemplo, para reescribir la

arquitectura del multiplexor de dos bits en estilo de flujo de datos de la siguiente
manera:
architecture FlujoDatos of MUx21 1s

signal ctrl_n, nI, n2 : bit;
begin
ctrl_n <= not (ctrl) after Biblio.RetardosOp.RetNOT;
·nl <= ctrl_n acd a after Biblio.RetardosQP.RetAND2;
n2 <= ctrl acd b after Biblio.RetardosOp.RetAND2;
z <= (nI ar n2) after Biblio.RetardosOp.Ret0R2;
end FlujoDatos;
Tener que identificar la biblioteca, el paquete y el elemento cada vez que se

quiere usar un elemento del paquete puede resultar muy pesado en caso que se ne-
cesite en múltiples ocasiones. Umi posibilidad para solucionar este problema es
usar la sentencia use al principio de la unidad de diseño donde dicho elemento vaya
a ser utilizado. De este modo, en el código se podrá identificar el elemento simple-
mente con su nombre. Por ejemplo, para indicar que se va a utilizar la constante
RetNOr del paquete RetardosOp se escribiría al inicio del código:
use Biblio.RétardosOp.RetNOT;
En caso que se requiera el uso de más de un elemento del paquete se puede

añadir la sentencia all para hacer visibles al modelo todos los elementos del pa-
quete:
use Biblio.RetardosOp.all;
Haciendo visibles todos los elementos del paquete al dispositivo, la descripción

de la arquitectura en estilo de flujo de datos sería:
use Biblio.RetardosOp.all
architecture FlujoDatos of Mux21 1s
signal ctrl_n, nI, n2 : bit;
begin
ctrl_n <= not (ctrl) after RetNOT;
nI <= ctrl_n and a after RetAND2;
n2 <= ctrl aod b after RetAND2;
z <= (nI ar n2) after RetOR2;
end FlujoDatos;
En VHDL existe un paquete predefinido llamado standard almacenado en una

biblioteca llamada std que contiene tipos de datos básicos como, por ejemplo, los ti-
pos bit y time que se han visto en algún ejemplo de este capítulo. Además los fabri-
cantes suelen aportar otros paquetes con tipos de datos más complejos y operacio-
nes sobre estos tipos para facilitar el trabajo del diseñador.
2.3.5. Bibliotecas
Una biblioteca sirve para almacenar el resultado del análisis de las unidades de di-
seño para su futuro uso. Las bibliotecas son beneficiosas porque facilitan la com-
partición y la reutilización del código en diferentes diseños.
Aunque las unidades de diseño se analicen separadamente, se tiene que respe-
tar un cierto orden ya que algunas unidades dependen de otras. En general, la decla-
ración de una entidad tiene que analizarse antes que su arquitectura y la declaración
de un paquete antes que su cuerpo. Además, cuando una entidad utilice algún ele-
mento de un paquete, las unidades de este paquete tienen que analizarse antes que
las unidades de la entidad, Por último, antes de analizar una configuración tienen
que haberse analizado las arquitecturas seleccionadas en dicha configuración.
En el caso del ejemplo del multiplexor de dos bits que se ha venido utilizando
en todo este apartado de capítulo se podrían analizar las unidades de diseño en el si-
guiente orden:
Declaraci6n del paquete RetardosOp

Cuerpo del paquete RetardosOp .
,Declaraci6n de la entidad Mux21
'Arquitectura FlujoDatos de Mux21
Arquitectura Algoritmico de Mux21
Arquitectura Estructural de Mux21
Configuración Mux21_cfg
De hecho, la declaración de la entidad Mux21 y de las arquitecturas Algoritmi-

ca y Estructural no dependen del paquete RedardosOp, por lo que podrían haber si-
do analizadas antes que el paquete.
La biblioteca work o de trabajo sirve de biblioteca por defecto y es la que se
utiliza siempre que no se especifique otro nombre. De todos modos, el diseñador
puede crear el número de bibliotecas que crea necesario y repartir sus diseños entre
las bibliotecas de la forma que crea más conveniente.
Desde un modelo almacenado en una biblioteca no puede accederse directa-
mente a las unidades de diseño de otras bibliotecas, ya que solamente se tiene visi-
bilidad de la biblioteca donde está almacenado este modelo. Para dar visibilidad a
una biblioteca se utiliza la sentencia library seguida del nombre de la biblioteca.
Por ejemplo, para usar los elementos de un paquete que se llame PaqueteEjemplo
almacenado en la biblioteca BibliotecaEjemplo desde un modelo que se vaya a
guardar en otra biblioteca se tendría que empezar el modelo de esta forma:
library BibliotecaEjemplo;
use BibliotecaEjemplo.PaqueteEjemplo.all;
Las bibliotecas work y std son excepciones en el sentido que siempre son visi-
bles y, por tanto, no requieren la sentencia library.
Finalmente cabe destacar que la definición de biblioteca es una definición lógi-
ca, en el sentido que cada herramienta puede implementarla como quiera sobre el
sistema de ficheros. En algunos casos una biblioteca será un fichero, en otros un di-
rectorio O una estructura jerárquica de directorios. Por esta razón, cada herramienta
debe aportar facilidades para crear bibliotecas y para mapear su estructura lógica a
la posición física en el disco.
2.4. OBJETOS, TIPOS DE DATOS Y OPERADORES
Un objeto VHDL es un elemento del lenguaje que tiene un valor de un tipo de datos
concreto. Este tipo de datos determina el conjunto de valores posibles que el objeto
puede contener así como la clase de operaciones que se le podrán aplicar. En gene-
ral, no será posible realizar operaciones entre dos objetos de distinto tipo si no se
aplica explícitamente una función de conversión de tipo a los operandos. Aunque
esta faceta del VHDL implica más atención por parte del diseñador a la hora de es-
cribir un modelo, permite detectar errores durante el análisis del código sin necesi-
dad de simulación.
En las siguientes secciones de este apartado se van a repasar los elementos lé-
xicos del lenguaje, los objetos disponibles en VHDL, los diferentes tipos de datos
que se pueden asignar a estos objetos y los operadores que se pueden aplicar a estos
tipos de datos.
2.4.1. Elementos léxicos
Antes de empezar a hablar de los objetos del VHDL resulta adecuado introducir los
elementos léxicos del lenguaje, que básicamente son los identificadores, las pala-
bras reservadas, los símbolos especiales y los literales.
2.4.1.1. Identificadores
Los identificadores sirven para dar un nombre a los elementos VHDL, por lo que es
aconsejable elegir un nombre que sea significativo, de este modo se facilitará la
comprensión del código. Existen una serie de reglas a la hora de formar un identifi-
cador:
• Los identificadores no tienen fijada una longitud máxima. Lo más aconseja-
ble es elegir una longitud suficiente para que el identificador tenga significa-
do evitando las longitudes excesivamente largas,
• Un identificador puede contener los caracteres alfabéticos de 'A' a 'Z' y de
'a' a 'z', los caracteres numéricos de 'O' a '9' y el carácter subrayado '_'
(underline). VHDL no establece ninguna diferencia entre mayúsculas y mi-
núsculas, por lo que los identificadores RELOJ, reloj y Rel.al son idénticos.
• Un identificador debe empezar con un carácter alfabético, no puede terminar
con el carácter subrayado ni puede tener dos caracteres de subrayado segui-
dos.
• No puede usarse como identificador una palabra reservada (las palabras re-
servadas se verán a continuación).
Teniendo en cuenta estas reglas, a continuación se muestran ejemplos de iden-

tificadores correctos e incorrectos:
Correctos IncorrectoS
i 3
i_2 i2_
Reloj _i2
RelojAOC Reloj$AOC
Reloj_AOC Reloj_AOC
Interrupcion3_Del_Procesador 3Interrupcion
En VHDL-93, aparte de estos identificadores básicos, se definieron los identifi-

cadores extendidos que pueden contener cualquier secuencia de caracteres. El obje-
tivo de estos nuevos identificadores es el de permitir la comunicación entre herra-
mientas que procesen VHDL y otras herramientas que tengan reglas distintas para
formar sus identificadores. Para definir un identificador extendido se deben ence-
rrar sus caracteres entre '\'. De este modo, se definirían los identificadores extendi-
dos \3\, \i2_\, \_i2\, \Reloj$ADC\, \Reloj_ADC\ y \3Interrupción\. En este caso sí
que se diferencian las mayúsculas de las minúsculas, de modo que los identificado-
res \RELOJ\, 'veloj. y \ReLoJ\. son distintos, a la vez que se diferencian de los iden-
tificadores básicos en el sentido que el identificador reloj es diferente a los tres an-
teriores.
2.4.1.2. Palabras reservadas

Las palabras reservadas son un conjunto de palabras que tienen un significado espe-
cífico en VHDL y que sirven para definir las sentencias que forman un modelo. Por
esta razón estas palabras no pueden utilizarse como identificadores para dar nombre
a elementos del lenguaje.
En VDHL-87 el conjunto de palabras reservadas está formado por las siguien-
tes palabras:
abs else nand return

access elsif new select
after end next severity
alias entity nor signal
all exit not subtype
and file null then
architecture for of to
array function on transport
assert generate open type
attribute generic or units
begin guarded others until
block if out use
body in package variable
buffer inout port wait
bus is procedure when
case label process while
component library range with
configuration linkage record xor

constant loop register
disconnect map rem
downto lOOd report
En VHDL-93 se añadieron nuevas palabras reservadas al lenguaje. El conjunto

de nuevas palabras son las listadas a continuación:
group postponed ror sra
iIrq>ure pure shared srl
inertial reject sla unaffected
literal rol s11 xnor
2.4.1.3. Símbolos especiales

Además de los literales y las palabras reservadas, VHDL aporta un conjunto de
símbolos especiales que tienen diferentes funciones, desde operadores de distintos
tipos hasta símbolos que forman parte de sentencias o símbolos de puntuación.
Los símbolos pueden estar formados por un carácter:
+ - + / ( ) ;&'<>=1#
o por dos caracteres:

=> ** := /= >= <= <> --
Los significados de cada símbolo se verán a lo largo del capítulo cuando se ha-
ble del tema concreto donde se use el símbolo. Por ejemplo, al tratar los operadores
más adelante en este apartado se verá el significado de gran parte de símbolos de
esta lista.
Quizás en este momento cabe destacar el símbolo "--" que sirve para añadir co-
mentarios en el código. Cuando aparezca este símbolo en una línea, el analizador
no tendrá en cuenta el texto comprendido entre este símbolo y el final de la línea.
Al igual que en cualquier programa escrito en un lenguaje de programación común,
resulta muy útil añadir comentarios en el código para mejorar la legibilidad.
Finalmente resaltar que cualquier sentencia del lenguaje VHDL debe terminar
con el símbolo ";",
2.4.1.4. Literales
Un literal es un símbolo cuyo valor se obtiene directamente de su representación.
Existen diferentes tipos de literales dependiendo de la naturaleza de su valor, con-
cretamente los literales se dividen en: números enteros, números en punto flotante,
literales físicos, caracteres, cadenas de caracteres y cadenas de bits.
Los números enteros, los números en punto flotante y los literales físicos sirven
para expresar valores numéricos. Los números enteros se componen simplemente
de una secuencia de dígitos, a diferencia de los valores en punto flotante, que deben
contener un punto y un dígito decimal. Por su parte, los literales físicos son valores
enteros o en punto flotante que tienen una unidad de medida física asignada.
Algunos ejemplos de literales enteros serían:

4 5436 o
En el caso de los literales en punto flotante:
3.1415927 5436.0 0.42
Por último, los literales físicos:

5.23 ns 52 mm 0.4 v
Además de esta representación, VHDL permite describir estos literales numéri-

cos utilizando la notación exponencial. Evidentemente el exponente tendrá que ser
positivo para los valores enteros.
Algunos ejemplos utilizando esta representación serían:
52e2 43.23E+2 2.1E-04 12E2 kohm
También cabe destacar que los literales numéricos se pueden representar utili-
zando cualquier base entre 2 y 16. Para bases mayores que 10 se utilizarán los ca-
racteres desde 'A' a 'P' (o en minúsculas) para representar los dígitos desde ellO al
15. La notación exponencial también se puede representar en cualquier base. Por
ejemplo, el valor 12 se podría representar:
2#1100# 2#11#E2 4#30# 8#14# 10#12# 10iO.12#e+2 16#C#
Como puede verse en el ejemplo, la base y el exponente siempre se representan

en base decimal, de manera que la parte encerrada entre '#' es la que puede estar
descrita en otra base. Evidentemente, aunque el exponente esté en notación decimal
representa una potencia de la base con la que se trabaja.
Por último, referente a los literales numéricos sólo decir que para mejorar la le-
gibilidad de números con muchos dígitos se permite añadir caracteres '_' entre los
dígitos. De esta forma, por ejemplo, se pueden agrupar los dígitos en grupos de tres
para separar los valores numéricos en miles.
Un literal carácter es simplemente un carácter ASCII encerrado entre comillas
simples. A continuación se dan algunos ejemplos de caracteres:
'm' 'M' '3' I I I
r
I
Como se ve, el carácter comilla simple se representa mediante tres comillas

simples seguidas.
Un literal cadena de caracteres está formado por una secuencia de caracteres tal
como su nombre indica y se representa encerrándolo entre comillas dobles.
Algunos ejemplos de cadenas de caracteres serían:
"abcdef' 'a4&3(j" "hola' 'abcde ., fghi'
En el último ejemplo se muestra que para incluir el carácter comillas dobles en

una cadena de caracteres basta con escribirlo dos veces seguidas.
Por último, un literal cadena de bits está formado por una secuencia de caracte-
res de 'O' a '9' y de 'N a 'P' (o en minúsculas) encerrados entre comillas dobles
precedidos de una letra que indica la base. Esta letra puede ser B para binario, O pa-
ra octal o X para hexadecimal. Como en el caso de los literales numéricos se pue-
den incluir caracteres '_' para mejorar la legibilidad en caso de secuencias muy lar-
gas.
A continuación se dan algunos ejemplos de literales de este tipo:
2.4.2. Objetos del VHDL
Un objeto VHDL es un elemento que tiene asignado un valor de un tipo determina-

do. Hay cuatro clases distintas de objetos: las constantes, las variables, las señales y
los ficheros.
Todos los objetos deben declararse antes de poder ser utilizados. La declara-
ción consiste básicamente en asignar un identificador y un tipo al objeto. Opcional-
mente también se le puede dar un valor inicial, de no hacerlo VHDL inicializará el
objeto según unas reglas que se describirán más adelante.
En las siguientes secciones de este subapartado se verán con más detalle cada
una de estas clases de objeto.
2.4.2.1. Constantes
Una constante es un objeto que mantiene siempre su valor inicial, de modo que no
puede ser modificada una vez ha sido creada.
La sintaxis VHDL para declarar una constante es la siguiente:
constant identificador L ... } : tipo [~=expresi6n];
El identificador dará nombre a la constante y servirá para referenciarla más tar-

de, el tipo indica la naturaleza del valor que contiene y la expresión sirve para ini-
cializar la constante. Debido a que el valor de una constante no se puede cambiar,
en general se incluirá la parte de inicialización en la declaración. De todos modos,
la parte de inicialización es opcional. Cuando se explicó el paquete se vio que la de-
claración del paquete es una construcción VHDL que puede contener constantes sin
inicializar.
A continuación se ven algunos ejemplos de declaraciones de constantes:
constant Pi : real;= 3.1415927;

constant BitsPalabra: integer := 8;
constant NúmeroPalabras : integer. := 64;
constant NúmeroBits : inteqer := BitsPalabra * NÚffieroPalabras;
constant Retard0AND2, RetardoOR2 : time := 2 ns;
Cualquier constante podría ser sustituida directamente por un literal con su va-
lor; no obstante, es aconsejable utilizar constantes para mejorar la legibilidad del
código, ya que normalmente el identificador de la constante será más significativo
que su valor. También para facilitar su actualización, de este modo, para cambiar el
valor de una constante sólo se tendrá que modificar la declaración, si no se usan
constantes hará falta realizar tantas modificaciones como veces aparezca el literal
en el código.
2.4.2.2. Variables
A diferencia de las constantes, las variables pueden cambiar su valor una vez han
sido declaradas mediante las sentencias de asignación. Una variable no tiene ningu-
na analogía directa en hardware, normalmente se utilizan en el estilo algorítmico
para almacenar valores intermedios dentro de un proceso.
La sintaxis VHDL para declarar una variable es la siguiente:
variable identificador {, ...} : tipo [:=expresión];
Como se puede ver, a excepción de la palabra reservada que es diferente, la

sintaxis para declarar una variable es idéntica a la que se requería para la declara-
ción de una constante.
A continuación se muestran algunos ejemplos de declaración de variables:
variable Indicel, Indic~, Indice3 : integer := O;

variable Comparacion : boolean;
variable Resultado : real;
Cuando una variable ha sido creada su valor puede ser modificado utilizando
una sentencia de asignación de variable. La sintaxis VHDL de estas sentencias es la
siguiente:
identificador := expresión;
El nuevo valor de la variable será el resultado de evaluar la expresión incluida

en la sentencia. La asignación será inmediata en el sentido que el nuevo valor susti-
tuirá al antiguo inmediatamente después de haberse evaluado la expresión, de modo
que si en la siguiente sentencia se hace referencia a esta variable ya se tendrá en
cuenta el nuevo valor. Normalmente las variables se declaran en la parte declarativa
de los procesos, de forma que solamente son visibles en el proceso donde se van a
utilizar. En caso que una variable fuera visible en más de un proceso, teniendo en
cuenta que la ejecución de los procesos es concurrente, sería impredecible el resul-
tado que se produciría cuando un proceso modificara una variable mientras otro uti-
liza su valor, ya que este resultado depende totalmente del orden en que el simula-
dor ejecute los procesos.
Aunque en principio las variables son internas de un proceso, en VHDL-93 se
contempla el uso de variables globales para comunicar procesos.
2.4.2.3. Señales
Una señal es un objeto que, al igual que una variable, puede modificar su valor den-
tro de los posibles valores de su tipo pero, a diferencia de ésta, tiene una analogía
directa en hardware. ya que se puede considerar como una abstracción de una cone-
xión física o un bus. Por esta razón, no está restringida a un proceso sino que sirve
para interconectar componentes de un circuito y para sincronizar la ejecución y sus-
pensión de procesos.
La sintaxis VHDL para declarar una señal es muy parecida a la sintaxis reque-
rida para declarar constantes y variables:
signal identificador {, ...} : tipo [:=~resi6~1;
A diferencia de las variables, una señal no se declarará en la parte declarativa

de un proceso sino en la de la arquitectura del dispositivo.
Los puertos de una entidad son señales que se utilizan para interconectar el dis-
positivo con otros dispositivos. Su declaración es un poco especial, ya que aparte de
determinar un identificador y un tipo de datos es necesario indicar la dirección de la
señal respecto a la entidad. La sección de declaración de puertos de una entidad tie-
ne la siguiente sintaxis VHDL:
port ({identificador L ...} : dirección tipo {!,=expresiÓl11;})';
En este caso la expresión opcional se utiliza en caso de que el puerto esté des-
conectado.
A continuación se muestran algunos ejemplos de declaración de señales:
signal Reloj: stq_logic := 'O';
signal Comparacion : bit;
signal Resultado: integer range O to 7;
port ( a" b : in integer range O to 7;
c : out integer range O to 7;
d : inout std_logic);
Una señal puede modificar su valor mediante la sentencia de asignación de se-

ñales. A diferencia de las variables, la asignación de una señal no se realiza de in-
mediato sino que antes se acaban de ejecutar los procesos activos. De esta forma se
puede asegurar que, aunque el simulador sea secuencial, el resultado siempre será el
mismo, independientemente del orden en que se ejecuten los procesos. Además, en
la sentencia se puede indicar el retardo con que se quiere realizar la asignación, de
forma que cada señal tiene como mínimo una cola de eventos, en la que cada even-
to es una asignación pendiente formada por el valor y el momento en que esta asig-
nación debe llevarse a cabo. Más adelante en este capítulo se verá con detalle la
asignación de señales.
2.4.2.4. Ficheros
Un fichero es un objeto que permite comunicar un diseño VHDL con un entorno
externo, de manera que un modelo puede escribir datos y leer datos que persisten
cuando la simulación termina. Un uso bastante común de los ficheros es el de alma-

cenar los estímulos de simulación que se quieren aplicar al modelo en un fichero de
entrada y salvar los resultados de simulación en un fichero de salida para su poste-
rior estudio.
Un fichero es de un tipo de datos determinado y sólo puede almacenar datos de
ese tipo. La sintaxis para declarar un fichero es la siguiente:
file identificador {, ...} : tipo_fichero lis dirección "nombre";]
El identificador servirá para referenciar el fichero en el código. El tipo de fi-

chero indica el tipo de datos que contendrá el fichero y debe declararse explícita-
mente antes de declarar el objeto fichero. En el siguiente subapartado de este capí-
tulo se verá cómo declarar tipos de datos y, concretamente, tipos de fichero. La di-
rección indica si el fichero va a ser de lectura o de escritura, mientras que el nombre
de fichero se refiere al nombre físico que va a recibir el fichero dentro del sistema
de ficheros de la computadora. Después de la declaración de un fichero, VHDL au-
tomáticamente abre el fichero para lectura o escritura dependiendo de la dirección
seleccionada.
Algunos ejemplos de declaración de ficheros serían:
file Estimulos : FicheroEnteros is in "datos.in";
file Salida: FicheroEnteros is out "datos.out";
En VHDL-93 la forma de declarar ficheros ha cambiado sensiblemente. La sin-

taxis para declarar un fichero en este caso es:
file identificador {, ...} : tipo [[apen tipo_acceso] is ·nombre";]
La dirección se sustituye por la palabra reservada open más el tipo de acceso

que puede ser read_mode, write_mode o append_mode. Dependiendo de este valor
se abrirá el fichero de un modo u otro, en caso que no se especifique ninguno, por
defecto se abrirá en modo lectura. En VHDL-93 los ejemplos anteriores serían:
file Estimulos : FicheroEnteros qpen reaq_node is "datos. in";
file Salida: FicheroEhteros apen write_mode is ·datos.out";
Cabe destacar que en este caso VHDL-87 no es un subconjunto de VHDL-93,

por lo que un modelo que contenga declaraciones de fichero con las palabras reser-
vadas in y out no se analizará correctamente con un analizador de VHDL-93.
Por último, decir que VHDL aporta un conjunto de subprogramas para leer y
escribir en ficheros de forma secuencial. Además, en la biblioteca llamada standard
existe el paquete textio que define tipos de datos y operaciones de lectura y escritu-
ra útiles para tratar ficheros de texto.
2.4.3. Tipos de datos
El tipo de datos es un concepto fundamental en VHDL, ya que cada objeto de-

be ser de un tipo concreto que determinará el conjunto de valores que puede asumir
y las operaciones que se podrán realizar con este objeto.
VHDL proporciona sentencias específicas para la declaración de nuevos tipos

además de un conjunto de tipos predefinidos básicos de uso común. En las siguien-
tes secciones de este subapartado se verá cómo definir nuevos tipos y se dará una
clasificación de los tipos predefinidos mostrando las características de cada tipo.
2.4.3.1. Declaración de tipos de datos
La declaración de un tipo de datos es la sentencia VHDL utilizada para introducir

un nuevo tipo. Básicamente, la información necesaria para declarar un nuevo tipo
estará formada por un identificador de tipo que servirá para referenciarlo y la des-
cripción del conjunto de valores que forman el tipo de datos. Concretamente, la sin-
taxis VHDL para declarar un tipo será:
type identificador la definición_tipo;
La parte de definición de tipo sirve para indicar el conjunto de valores del tipo.
Puede tener varios formatos, que se verán en detalle a medida que se expliquen los
diferentes tipos predefinidos del lenguaje. A continuación se dan ejemplos de decla-
raciones:
type DiaMes la range 1 to 31;
type PuntosCardinales la (norte, sur, este, oeste);
Una vez definido un nuevo tipo de datos ya se pueden declarar objetos de este
tipo, teniendo en cuenta que los ficheros requieren un tipo especial llamado tipo fi-
chero. Por ejemplo, se podrían declarar los siguientes objetos:
constant DiasEnero : DiaMes := 31;
variable DiaHoy : DiaMes;
signal Direccion : PuntosCardipales;
port (Entrada: in PuntosCardinales;
,Salida: out PuntosCardinales);
Cada tipo es diferente e incompatible con los demás tipos, aun cuando las defi-
niciones sean idénticas. Si por ejemplo se declara el tipo
type De1a31 is range 1 to 31;
no será posible asignar a un objeto de tipo DeJa3J el valor de un objeto de tipo

DiaMes. Para hacerlo será necesario incluir explícitamente una función de conver-
sión de tipo para que la asignación se realice entre operandos del mismo tipo.
Si se declara una variable llamada:
variable Numero : De1a31;
Entonces se le podrá asignar la constante DiasEnero de tipo DiaMes convir-

tiendo el valor de la constante al tipo DeJa3J, con la función DiaMes_DeJa3J (las
funciones se describen más adelante en este capítulo):
Ntunero := DiaMes_Dela31(DiasEnero);
2.4.3.2. Tipos de datos escalares

Los tipos de datos escalares son aquellos cuyos valores están formados por una sola
unidad indivisible. Existen tipos de datos escalares predefinidos de distintas clases,
concretamente tipos enteros, tipos reales, tipos físicos y tipos enumerados. Los ti-
pos reales son continuos en el sentido que dentro de un intervalo existen un número
infinito de valores, por esta razón, como no es posible representar todos los núme-
ros, se tiene que escoger un conjunto de números representables de manera que
cualquier valor se deberá redondear al número representable más próximo produ-
ciéndose cierto error. Por el contrario, los tipos enteros y enumerados se conocen
como tipos discretos. Al declarar un objeto de un tipo escalar, éste se inicializará
por defecto al valor más a la izquierda del tipo. A continuación se detallan las ca-
racterísticas más importantes de cada tipo.
2.4.3.2. 1. Tipos enteros y tipos reales

Los tipos enteros y reales son tipos de datos predefinidos que, como su nombre in-
dica, sirven para representar números enteros y reales respectivamente. El lenguaje
estándar requiere que el tipo entero incluya los valores de -2.147.483.647 a
2.147.483.647 y el tipo real de -l.OE38 a l.OE38 con un mínimo de seis dígitos de-
cimales, aunque alguna implementación VHDL pueda ampliar estos rangos. Como
normalmente no serán necesarios todos los valores de estos tipos predefinidos, se
suelen definir nuevos tipos que determinan el rango de valores que se van a utilizar.
De esta manera,la sintaxis VHDL para declarar un tipo entero o real especificando
un rango es la siguiente:
type identificador is range literal to I downto litera:l;
Dependiendo de si se escriben literales enteros o en punto flotante, el tipo de

datos declarado será de tipo entero o de tipo real. Con las palabras reservadas to y
downto se puede indicar un rango creciente o decreciente respectivamente, de esta
forma se determinará la ordenación que tendrán los valores dentro del tipo. Por de-
fecto, un objeto de tipo entero o real se inicializa al valor más a la izquierda de los
que forman el tipo, que en este caso coincide con el primer literal del rango.
A continuación se dan ejemplos de declaraciones de tipos de datos enteros y reales:
type PrecioProducto is range 1 to ;1..;,OO\l""OOO~
type Puntuacion is range O. o to lO.!};
variable PreciQMesa : PrecioProducto1
variable MiNota : Puntuacion;
2.4.3.2.2. Tipos físicos

Los tipos físicos sirven para representar medidas del mundo real como pueden ser
distancia, tiempo o peso. Por esta razón, además de un literal numérico llevan aso-
ciada una unidad primaria de la medida física que quieren cuantificar. También se
pueden definir unidades secundarias múltiplos de la unidad primaria para poder uti-
lizar, en cada momento, la unidad más adecuada según el valor que se quiera repre-
sentar. La sintaxis VHDL para declarar un tipo físico es la siguiente:
type identificador is ranga literal to I downto literal

units
identificador;
{ identificador = literal_físico:
end units [identificador];
El identificador es el nombre que recibe el tipo físico y sirve para referenciarlo.

El rango determina el valor mínimo y máximo de unidades primarias del tipo físico.
Esta unidad primaria debe ser menor que las unidades secundarias, para las que se
tendrá que indicar el número de unidades primarias que contienen mediante el lite-
ral físico asociado. Este valor puede especificarse directamente en función de la
unidad primaria o mediante una unidad secundaria previamente declarada.
Se puede definir un tipo físico para cualquier medida física que se quiera cuan-
tificar. Probablemente, el tipo físico más común en VHDL es el tipo time (tiempo),
declarado en el paquete standard de la biblioteca std, que sirve para especificar re-
tardos. La declaración del tipo time sería:
type time is ranga O to lE2Q
units
fs;
ps = 1000 fs:
ns = 1000 ps;
llS z:. 1000 ns;
ros = 1000 us:
sec = 1000 ÍIlS;
ritín = 60 sec;
hr = 60 minr
end units;
Internamente VHDL considera los tipos físicos como enteros con una unidad
primaria asociada, por lo que cualquier valor físico que contenga un literal real será
redondeado a un número entero de unidades primarias. Por ejemplo, los tres litera-
les siguientes serán equivalentes:
4.3211 ps 4.321 ps 432'1 fs
En el primer caso se perderá el último dígito decimal al redondear el valor a

femtosegundos, por consiguiente, la conclusión es que cuanta más precisión quiera
obtenerse menor deberá ser la unidad primaria.
Finalmente, aunque se dedicará un subapartado específico para hablar de los
operadores del VHDL, debe destacarse que la aplicación de operadores a los tipos
físicos es bastante especial. La suma y la resta de dos valores de un tipo físico darán
como resultado un valor del mismo tipo. Por otra parte, la multiplicación será dife-
rente, ya que, por ejemplo, al multiplicar dos distancias no se obtiene una distancia
sino un área. VHDL no soporta la multiplicación directa de tipos físicos, lo que se
tendrá que hacer es convertir cada valor a un entero, efectuar la multiplicación y
posteriormente convertir el resultado a un tipo físico llamado área. En cambio, la
multiplicación y la división entre tipos físicos y números reales o enteros estará per-
mitida y el resultado será del tipo físico, o la división de dos valores físicos dará co-
mo resultado un valor entero.
2.4.3.2.3. Tipos enumerados

El último tipo de datos escalar es el tipo enumerado, en el que se define el conjunto
de posibles valores del tipo especificando una lista que contiene todos los valores. Se
llamantipos enumerados porque en la lista se enumeran todos y cada uno de los valo-
res que forman el tipo. La sintaxis para declarar un tipo enumerado es la siguiente:
type identificador is ( identificador r carácter {, ... } );
El primer identificador es el nombre del tipo y servirá para referenciarlo. Entre

paréntesis y separados por comas se especifican todos los valores del tipo. Como
mínimo debe indicarse un valor. A continuación se dan algunos ejemplos de tipos
enumerados:
type Comandosis (izquierda, derecha, arriba, abajo, disparar);
typeTeclas ('a',' 'd', 'w', 'x', ")r
type Mezcla ('a', izquierda, 'd', derecha);
A partir de estos tipos acabados de definir se podrían declarar objetos de estos tipos:
variable ComandoActual : Comandos := abajo;
variable TeclaActual : Teclas := 'a';
Un objeto de tipo enumerado se inicializa por defecto al valor más a la izquier-

da de los que aparecen en la definición del tipo. Por lo tanto, la inicialización del
segundoejemplo es redundante, ya que TeclaActual ya hubiera tomado el valor 'a'.
En el paquete standard de la biblioteca std se definen algunos tipos enumera-
dos de uso bastante común. Concretamente el tipo carácter, el tipo booleano y el ti-
po bit. El tipo carácter no es más que una enumeración de todos los caracteres del
conjuntode caracteres de 8 bits estandarizado por la ISO. Los tipos booleanos y bit
se definen de la siguiente manera:
type boolean is (false, true);
typebitis ('O', '1');
El tipo booleano se utiliza normalmente como resultado de la evaluación de un

operadorrelacional, mientras que el tipo bit se utiliza para el modelado de sistemas
digitales.
De todos modos, el tipo bit suele resultar insuficiente porque no tiene en cuenta
las propiedades eléctricas de las señales. Por esta razón se han definido nuevos ti-
pos que incluyen valores como, por ejemplo, desconocido o no inicializado. IEEE
ha estandarizado un paquete llamado std_logic_1164 que incluye un tipo llamado
std_ulogic que permite modelar las señales de forma más adecuada. Dicho paquete
además define los operadores para trabajar con objetos de este tipo. La definición
del tipo std_ulogic es la siguiente:
type std_ulogic is ( 'U', _ No inicializado
'X', _ Forzando desconocido
'0', _ Forzando cero
'1 " _ Forzando uno
'Z', - Alta i.rrpedanc~

'W', - Desconocido débil
, '·L', '. - Cero débil
.~W~ - Uno .débil
, - , ); - Redundante
El paquete std_logic_1l64 suele estar almacenado en una biblioteca llamada

IEEE y no forma parte del lenguaje VHDL, por esta razón ningún modelo puede
utilizar el tipo de datos std_ulogic directamente. Los modelos que quieran usar este
tipo de datos tendrán que contener las sentencias necesarias para obtener la visibili-
dad a este paquete, concretamente al inicio deberán incluir:
library IEEE;
use IEEE.std_logic_1164.all;
Finalmente destacar que algunos literales forman parte de más de un tipo de

datos enumerado. Por ejemplo, el carácter 'O' está incluido en los tipos de dato ca-
rácter, bit y std_ulogic. Cuando esto ocurre se dice que el literal está sobrecargado.
Normalmente, cuando aparece un literal sobrecargado en un modelo, por el contex-
to puede saberse de qué tipo es. De todos modos, algunas veces es necesario indicar
explícitamente el tipo de datos del literal para evitar confusiones, es lo que se cono-
ce como calificación de tipo:
character+ ('.o'), bit' ('O') , std_ulogic' ('O')
No debe confundirse la calificación de tipos con la conversión de tipos. En el

primer caso sólo se especifica de qué tipo es un literal para evitar confusiones,
mientras que en el segundo se aplica una función para modificar el tipo original del
literal.
2.4.3.3. Declaración de subtipos de datos
Como se ha visto anteriormente, un tipo de datos define un conjunto de posibles va-

lores que puede contener un objeto VHDL. Muchas veces habrá ciertos objetos de
un tipo que solamente tomarán valores de un subconjunto de los valores del tipo,
de modo que nunca contendrán ciertos valores concretos. Para esta situación,
VHDL proporciona el subtipo, que asocia una restricción a un tipo base para obte-
ner un subconjunto de valores del dominio del tipo. A partir de este momento se
pueden declarar objetos de este subtipo que sólo podrán contener valores dentro del
subconjunto acabado de definir. '
La sintaxis VHDL para definir un subtipo a partir de un tipo base es la si-
guiente:
subtype identificador 1s id_tipo [range literal to I downto literal];
El identificador da nombre al subtipo y servirá para referenciarlo más tarde. A

continuación hace falta especificar el tipo base para el que se define el subtipo y la
restricción mediante el comando range. En el siguiente apartado, cuando se hable
de tipos de vectores no restringidos se verá otra forma de especificar subtipos para

definir la longitud del vector. Cabe destacar que la parte de restricción es opcional,
por lo que se puede definir un subtipo que contenga exactamente los mismos ele-
mentos que el tipo base.
VHDL tiene algunos subtipos predefinidos como, por ejemplo, positive y natu-
ral, que son subtipos del tipo base integer y' se utilizan para representar números posi-
tivos y naturales respectivamente. La definición de estos subtipos sería la siguiente:
subtype natural la integer range O to integer'high;

subtype positive la integer range 1 to intleger'high;
En el subapartado 2.4.5 se hablará de los atributos predefinidos de VHDL, en es-

tos momentos se puede decir que integer'higb devolverá el valor entero más grande.
A continuación se dan algunos ejemplos más de declaraciones de subtipos:
subtype DiaMes ia integer range 1 to 31;

subtype Digito la character range '0' to 'gr,
type Decimal ia ('0', '1', '2', '3', '4', '5'.' .'.6",,:. '7', 'S'. ,,~9:.1 i
subtype Octal la Decimal range Or to ' 7 ' ;
t
Se ha visto que dos tipos de datos diferentes no pueden utilizarse como operan-
dos en una misma operación. Un tipo y un subtipo no pueden considerarse tipos di-
ferentes, por lo que se les pueden aplicar las mismas operaciones y pueden mezclar-
se en una operación. De todos modos, en caso que se tenga que asignar el resultado
a un objeto del subtipo, este resultado tendrá que cumplir la restricción asociada al
tipo base, es decir, tendrá que pertenecer al subconjunto de los posibles valores del
subtipo,de no ser así se producirá un error durante la simulación. Por tanto, un sub-
tipo de datos puede ser útil para asegurarse que cada objeto toma valores dentro de
su rango esperado, detectando el error en caso contrario.
Por último decir que se pueden declarar subtipos de datos implícitamente en el
momento de declarar un objeto. Por ejemplo:
variable MesActual : integer range 1 to 12;
La variable llamada MesActual forma parte de un subtipo del tipo de datos en-
tero que no se ha declarado explícitamente.
2.4.3.4. Tipos de datos compuestos
Los tipos de datos compuestos son aquéllos cuyos valores se pueden dividir en uni-
dades atómicas más pequeñas. Existen dos tipos compuestos básicos: los vectores y
los registros. Los primeros están compuestos por unidades atómicas del mismo tipo
mientras que los segundos son heterogéneos en el sentido que están formados por
un conjunto de objetos diferentes. Al declarar un objeto de tipo compuesto, cada
uno de sus elementos se inicializará por defecto según las reglas que correspondan
a su tipo. En este subapartado se van a repasar las características de cada tipo de da-
tos compuestos y las posibilidades que ofrece cada clase.
2.4.3.4. 1. Vectores
Un vector es un conjunto de objetos del mismo tipo ordenados mediante uno o más
índices que indican la posición de cada objeto dentro del vector. El número de Índi-
ces determina la dimensión del vector, para vectores que tengan un solo índice se
hablará de vectores unidimensionales o simplemente vectores, en cambio los vecto-
res con más de un índice serán vectores multidimensionales o matrices.
Para declarar un vector se tendrá que crear un tipo que básicamente determine
el tipo de los objetos que formarán el vector y al rango de los Índices que siempre
será de un tipo discreto, es decir, entero o enumerado. La sintaxis VHDL para de-
clarar un vector es la siguiente:
type idendificador is array (rango {, .•.} ) of tipo_objetos;
El identificador da nombre al vector y sirve para referenciarlo, los rangos pue-

den describirse explícitamente en la declaración o bien se puede dar directamente un
nombre de tipo o subtipo que ya incluya una restricción de rango y finalmente el ti-
po indicará el conjunto de valores posibles que pueden tomar los objetos del vector.
A continuación se dan algunos ejemplos de declaraciones de vectores:
type Byte is array (O to 7) of bit;

type Byte2 i8 array (7 downto O) of bit;
subtype DeOa7 i8 integer range O to 7;
type Byte3 is array (DeOa7) of bit;
subtype Decimal is character range 'O' to '9';
type Byte4 i8 array (Decimal range 'O' to '7') of bit;
type PuntosCardinales is~ (norte, sur, este, oeste);
type Estado is array (PuntosCardinales range norte to este) of integer;
Una vez se ha declarado el tipo que define un vector, se pueden declarar obje-
tos de este tipo, tanto constantes corno variables y señales. Por ejemplo, se podrían
declarar las siguientes variables:
variable Operador1 : Byte;

variable Operador2 : Byte2;
variable Operador3 : ·Byte3;
variable Operador4, Operador5 : Byte4;
variable EstadoActual : Estado;
Las variables acabadas de declarar serán vectores compuestos por un conjunto

de elementos atómicos y será posible operar con todo el vector a la vez o con cada
elemento individualmente identificándolo mediante el índice. Por ejemplo, se po-
drían realizar las siguientes operaciones de asignación:
Operador1(}) .:P= .'.1';
Operador2 := ·10010Q10·;
Operador3 (3 to 6) := ·1000·;
Operador4('5') := '1';
Operador5 := éperador4;
EstadoActual(norte) := 35;
En el tercer ejemplo se muestra la forma de acceder a una parte del vector.

Concretamente Operador3 es de tipo Byte3, por lo que está compuesto por ocho
elementos (del Oal 7) y en cambio se asignan sólo cuatro elementos (del 3 al 7).
De la misma forma que se acaba de ver cómo declarar y utilizar los vectores
unidimensionales, se trabajaría con los vectores multidimensionales. Por ejemplo,
se podría definir una matriz de dos dimensiones para modelar una memoria:
type Melroria i8 array (O to 7, O to 63) of bit;
Una vez declarado el tipo Memoria se pueden declarar objetos de este tipo:
variable RamA, RamB : Memoria;
De nuevo se podrá trabajar con toda la matriz a la vez o acceder a los elemen-
tos por separado, esta vez hará falta especificar el valor de dos Índices en lugar de
uno:
RamA := RamB
RamA(4,7) := '1';
En este ejemplo concreto de una memoria, considerando que está formada por
64 palabras de 8 bits, se podría acceder a una palabra de la siguiente forma:
type Direccion i8 range o to 63;

type Contenido la array (O to 7) of bit;
variable DireccionRamA Direccion;
variable ContenidoRamA : Contenido;
DireccionRamA := 34;
COl'ltenidoRamA := RamA(O to 7, DireccionRamA);
En los ejemplos mostrados se ha visto que se puede acceder tanto a un solo ele-
mento de un vector como a un subconjunto de elementos o a todo el vector. Para
asignar valores a un solo elemento basta con utilizar un literal adecuado al tipo de
datos del elemento. Para asignar valores a un conjunto de elementos, en cambio, se
requiere una nueva construcción que permita asignarlos todos a la vez. Por esta ra-
zón VHDL proporciona el agregado que permite escribir un vector de literales que
se podrán asignar simultáneamente a los elementos de un vector. La sintaxis del
agregado es la siguiente:
( [ posición { I ...} => 1 literal t. "':.. }J
Es decir, se trata de una lista de literales separados por comas y encerrada entre
paréntesis. Existen dos modalidades de agregados, en la primera se indica la posi-
ción de cada literal dentro del vector y en la segunda se omite esta posición, de ma-
nera que el orden viene determinado por la ordenación de literales en la lista.
Por ejemplo, se puede definir un tipo de datos para representar puntos en el es-
pacio:
type Coordenadas is (X, y, Z).;

type Punto 1a array (X to Z) of real;
A continuación se pueden declarar los siguientes objetos:
constant OrigEm : Punto ::;: {O.O, 0.0, 0.0);

variable Punto'tT Punto;
En la declaración de la constante Origen se ha usado un agregado en el que se

ha omitido la posición de cada literal, por lo que el primer literal se ha asignado a
Origen(X), el segundo a Origen(Y) y el tercero y último a Origen(Z). Para dar un
valor a la variable Puntol se podría utilizar cualquiera de las siguientes opciones,
todas ellas serían equivalentes:
Puntol(X) := 2.5; Puntol(Y) := 7.3; Puntol(Z)··:= 2.5;

PwttOl 1= (2.5, 7.3, 2.5J.;
Puntol .- (1 => 2.5,2 => 7.3,3 =>
2.5);
PUntol :=. (2 => 7;3, 3 => 2.5, 1 => 2.5);
Puntol .- (1 I 3 => 2.5, 2 => 7.3);
En caso de que muchas posiciones de un vector tengan asignado el mismo va-

lor, se puede utilizar la palabra reservada others para asignar un valor a todas las
posiciones a las que aún no se les haya dado valor. Por ejemplo:
constant Origen: Punto := (others => 0.0);

Puntol := (2 => 7.3, others => 2.5);
Por tanto, gracias al agregado es posible trabajar con todo el vector a la vez, sin
tener que utilizar bucles que accedan a cada elemento por separado para llevar a ca-
bo cualquier asignación.
Todos los tipos de vectores vistos hasta el momento son restringidos en el sen-
tido que definen muy claramente su rango y, por tanto, queda especificado desde el
principio el número de elementos que tendrá el vector y las características de los Ín-
dices que van a utilizarse. Además de este tipo de vectores, VHDL proporciona los
tipos de vectores no restringidos en los que solamente se indica el tipo de los obje-
tos que va a contener sin especificar ningún rango. En el momento de declarar un
objeto de este tipo será cuando se asignará un rango a este objeto concreto.
La sintaxis VHDL para declarar un tipo de vector no restringido es la siguiente:
type identificador is array ( tipo_índice range <> {, ... } ) of tipo_objeto;
Por ejemplo, se podría declarar el tipo siguiente:

type VectorReales is array ( natural range <> ) of real;
A continuación se podrían declarar subtipos y objetos de este tipo especifican-

do el rango adecuado:
subtype Punto : Vecto:rR~les (O te
2);
constant origen: :PUnto ::!" (0.0, 0.0, 0.:0);
variable Muestras: VectorReales(O to 9);
VHDL proporciona gran cantidad de tipos vector no restringidos a los que se

les da un rango cuando se declara un objeto de dicho' tipo. Cabe destacar el tipo
string para tratar cadenas de caracteres, el tipo bitvector para vectores de bits y el
tipo std_ulogic_vector para vectores del tipo std_ulogic que no forma parte del nú-
cleo de VHDL sino que está definido en el paquete std_logic_1164 de IEEE. La de-
claración de cada uno de estos tipos sería la siguiente:
type string la array (positive range <» of character;
type bit_vector la array (positive range <» of bit;
type stq_ulogic_vector ia array (positive range <» of stq_ulogic;
A continuación se muestra cómo se declararían objetos de estos tipos:
variable Mensaje : string (1 to 50) : = (othera => • ');

variable Operadorl : bit_vector(7 downto O) := ·O:llOt{)ll·,;
variable BusDatos : stq_ulogic_ vector (31 downto O)
:= (othera => 'Z'),;
2.4.3.4.2. Registros
Un registro es un tipo de datos compuesto que a diferencia de los vectores está for-
mado por unidades atómicas de distinto tipo, que reciben el nombre de campos. Por
esta razón, los campos no se referencian mediante un índice como en los vectores
sino que requieren un identificador único dentro del registro para referenciarlo. El
tipo de datos registro no tiene nada que ver con el registro hardware utilizado para
almacenar valores en un circuito. Aunque los nombres coincidan, se trata de con-
ceptos totalmente distintos que no hay que confundir.
La sintaxis VHDL para declarar un tipo registro es la siguiente:
type idendificador la record
identificador {, ... } : tipo;
{ ... }
end record [identificador];
El identificador del tipo da nombre al registro y servirá para referenciarlo más

tarde. A continuación sólo hace falta especificar todos los campos del registro asig-
nándoles un tipo.
Por ejemplo, se podría declarar un tipo para guardar fechas:
type Fecha la record
Dia integer range 1 to 31;
Mes : integer range 1 to 12';
An_o : integer range O to '2tOOJ_
end record; " ,
Una vez declarado el tipo Fecha se pueden declarar objetos de este tipo:
variable Hoy, Ayer : Fecha;
Al igual que pasaba con los vectores, se puede acceder a un solo elemento del
registro o a todo el registro a la vez:
Ayer.Dia := 15; Ayer.Mes := 5; Ayer.AA....o := 1997:

Hoy := Ayer;
Para asignar valores a todo el registro se pueden usar también agregados con la
lista de literales que se quieran asignar. En este caso no tiene sentido indicar la posi-
ción que se quiere actualizar sino el identificador del campo. Por ejemplo:
Hoy := (5, 4, 1997);

Hoy := (Dia => 5, Mes => 4, Al:L.o :::> 1997);
Al tratarse de un registro, normalmente dentro de un mismo agregado aparece-

rán literales de distintos tipos.
2.4.3.5. Otros tipos de datos

En este subapartado del capítulo se van a mostrar un par de tipos de datos que no
han sido explicados en los subapartados anteriores. Concretamente los tipos fichero
y los tipos de acceso.
2.4.3.5.1. TIpos de acceso

Los tipos compuestos sirven cuando se conoce a priori el tamaño del conjunto de
datos que se debe almacenar, ya que este tamaño debe especificarse en la declara-
ción de sus objetos. En algunas aplicaciones este tamaño puede ser desconocido o
dependiente de cada ejecución, por esta razón, al igual que cualquier lenguaje de
programación común, VHDL proporciona apuntadores para crear estructuras de da-
tos dinámicas, estos apuntadores se conocen como tipos de acceso. Estos tipos de
datos no suelen usarse muy a menudo, en todo caso, normalmente se utilizarán
cuando se modele a alto nivel de abstracción.
La sintaxis VHDL para declarar un tipo de acceso es la siguiente:
type identificador is access tipo_datos;
El identificador es el nombre que recibe el tipo de acceso, mientras que el tipo

del final de la declaración indica el tipo de datos al que el tipo de acceso apunta.
Por ejemplo, para declarar un tipo de acceso que apunte a valores enteros se escri-
biría:
type ApuntaEnteros is access integer;
A continuación se podría declarar una variable apuntador a enteros de la si-

guiente manera:
variable Entero_Ap : ApuntaEnteros;
Para crear un nuevo objeto existe la palabra reservada new, a la que se le debe
indicar el tipo del objeto para poder determinar el tamaño de memoria que se re-
quiere:
6ntero...,.AP
:= new integer;
Para acceder al dato apuntado por el objeto de un tipo de acceso se puede utili-
zar la palabra reservada all:
Entero_Ap.all := 34;
Finalmente, para desalojar la memoria ocupada cuando ya no se requiere el ob-

jeto se puede usar el procedimiento implícito deallocate que VHDL crea automáti-
camente cada vez que se declara un tipo de acceso:
deallocate (Entex::.o~!;
Para definir estructuras más complejas, como, por ejemplo, una lista encadena-
da, basta con definir un tipo registro que contenga algún elemento apuntador apun-
tando a un registro del mismo tipo.
2.4.3.5.2. Tipos fichero

Un objeto fichero se utiliza en VHDL para almacenar datos de un tipo determinado.
Antes de poder trabajar con un fichero es necesario declarar un tipo fichero que in-
dique la naturaleza de los objetos que se van a almacenar. La sintaxis VHDL para
declarar un tipo fichero es la siguiente:
type identificador ie file of Üpo_objetos;
El identificador da nombre al tipo de fichero y servirá para referenciarlo más

tarde. Aparte de este identificador sólo hace falta indicar el tipo de los objetos que
se van a almacenar en el fichero. Una vez declarado el tipo, para trabajar con un fi-
chero concreto se tiene que declarar un objeto fichero de este tipo, tal como se vio
en el subapartado que hablaba de los distintos objetos del lenguaje. Por ejemplo,
para declarar un tipo de fichero para almacenar enteros y leer datos de un fichero
llamado datos.in en VHDL-87 se escribiría:
type FicheroEnteros ie file of integer;

file Estimulos : FicheroEnteros ie in "datos. in";
En la biblioteca std se define el paquete textio que proporciona el tipo fichero

de texto y los subprogramas de lectura y escritura para trabajar con este tipo de fi-
cheros. Concretamente define los dos tipos siguientes:
type line ie acceee string;

type text ie file of string;
El tipo text está formado por un conjunto de cadenas de caracteres, mientras

que el tipo Une es un apuntador a una cadena de caracteres. Entonces, gracias a ope-
raciones de lectura y escritura de una línea a fichero y operaciones para añadir y sa-
car datos de la línea sobre objetos de diferentes tipos, se puede trabajar fácilmente
con estos ficheros.
Aunque los procedimientos se verán en el apartado dedicado a subprogramas, a

continuación se introducen los proporcionados por textio para que se comprenda la
forma de trabajar con este tipo de ficheros, por lo que en este momento es impor-
tante fijarse en el concepto más que en la sintaxis. Concretamente para leer y escri-
bir un objeto de tipo línea se puede utilizar:
procedure readline (file f : text; 1: out 1ine)

procedure writeline (file f : text; 1: inout line)
readline volcará la línea actual del fichero sobre una variable de tipo línea y avan-
zará el puntero del fichero sobre la línea siguiente, mientras que writeline grabará la
variable de tipo línea sobre el fichero y inicializará dicha variable.
Para poder trabajar con las variables de tipo línea el paquete textio también
proporciona los siguientes procedimientos:
procedure read (1 : inout line; va1ue: out id_tipo);

procedure write (1 : inout line; value: in id_tipo);
Estos procedimientos pueden leer de variables de tipo línea y escribir en varia-

bles de este tipo respectivamente. El parámetro value puede ser de cualquier tipo
predefinido, de modo que se pueden volcar palabras de una línea sobre variables de
cualquier tipo y también se pueden añadir valores de cualquier tipo a una línea.
Los ficheros de texto se utilizan a menudo para almacenar los estímulos que se
van a aplicar al circuito y para grabar los resultados obtenidos para poder ser anali-
zados después de la simulación.
Ejemplo:
La entidad Sumador recibe operandos enteros en sus dos entradas y devuelve la su-
ma de estos operandos en su salida. La declaración de dicha entidad es la siguiente:
entity Sumadoris
port (OpA : in integer;
OpB in integer;
Suma : out integer);
end;
Se quiere crear una entidad llamada BancoPruebas cuya función sea estimular
el Sumador con los operandos contenidos en un fichero de texto llamado Datos.txt
y grabar los resultados en un fichero de texto que se llame Resultados.txt. El forma-
to del fichero Datos.txt es el siguiente:
53 522
;'34 35
2 -3
Mientras que el fichero Resultados.txt debe tener el siguiente formato:

53 + 522 = 575
..34 + 35 = 1
2 - 3 = -1
La entidad BancoPruebas debe ir leyendo los operandos del fichero Datos.txt,

aplicarlos a la entidad Sumador y almacenar los valores obtenidos a la salida en el
ficheroResultados.txt.
Aunque la arquitectura de BancoPruebas se puede implementar de diferentes
maneras, una posibilidad lógica es pensar que Sumador es un componente de esta
arquitectura. Trabajando de esta manera, BancoPruebas no requerirá ninguna co-
municación con el exterior, por lo que la declaración de la entidad será la siguiente:
entity BancoPruebas is
end;
Por lo que a la arquitectura se refiere, básicamente contendrá la referencia al

sumador y un proceso que se encargará de ir leyendo todos los valores del fichero
Datos.txt y grabará la salida en Resultados.txt. Las sentencias utilizadas dentro de
este proceso se verán en los próximos apartados de este capítulo, por lo que si este
ejemplo no queda claro en este momento, tal vez se comprenda completamente
cuando se acabe de leer el Capítulo 2. La arquitectura final de BancoPruebas sería
la siguiente:
library IEEE;
use std.textio.all;
architecture Funci9nal 9f BáncoPruebas is
signal OpA, OpB, Suma : integer;
component Sumador
port (OpA in integer;
0pB : in integer;
Suma : out integer );
end corrponent;
begin
-- proceso que lee los estímulos y graba los resultados

process
constant Periodo: time := 100 ns;
file Datos : text is in "Datos.'txt·;
variable LineaDatos : line;
file ResultadOs: text is out "Resultados.txt·;
variable LineaResultados : line;
variable OpA_I, OpB_I : integer;
begin
while not endfile(Datos) loop
readline(Datos, LineaDatos);
read(LineaDatos, OpA_I);
read(LineaDatos, OpB_I);
OpA <= OpA_L;
OpB <= OpB_I;
wait for Periodo;
write(LineaResultados, OpA);
if OpB_I ~ O then
write(LineaResultados, string'(M ~ M));
else
write(LineaResultados, string' (M + M));
end if;
write (LipeaResultaQos<, abs tOpB));
write(LineaResultados, string' (M = M));
write_(LiIJ,eaResultados, Suma);
writeline(Resúltados, LineaResultados);
end loop;
wait;
end process;
-- Referencia al sumador
SumadorO: Sumador port map (OpA, OpB, Suma);
end Funcional;
Cabe destacar que el paquete textio, aparte de los tipos fichero de texto y línea
y los procedimientos comentados anteriormente, también define otros procedimien-
tos como la función endfile para detectar el final del fichero. Otra cuestión impor-
tante de la arquitectura de BancoPruebas es la sentencia wait del proceso situada
entre la lectura de los operandos y la escritura de los resultados. Como se comentó
en subapartados anteriores de este capítulo, la asignación a una señal no se produce
inmediatamente sino que primero se requiere la suspensión de todos -los procesos
activos, esto se consigue mediante esta sentencia que suspende el proceso durante
un periodo de tiempo especificado por la constante Periodo. Esta cantidad de tiem-
po debería ser como mínimo el retardo que necesita el componente Sumador para
generar la salida Suma. En principio, a partir de la arquitectura del componente se
puede determinar cuál es este tiempo mínimo, en el ejemplo se ha supuesto que 100 ns
son suficientes.
2.4.4. Expresiones y operadores
Se puede considerar que una expresión es una fórmula que indica la forma como
debe calcularse un valor. Para hacerlo, se dispone de una serie de operadores más
unos elementos que actúan como operandos. Estos elementos suelen ser básicamen-
te literales, identificadores, atributos que determinen un valor, calificaciones y con-
versiones de tipo y paréntesis para especificar un orden de precedencia. Por lo que a
los operadores se refiere, VHDL tiene predefinidos los operadores aritméticos, rela-
cionales, lógicos y de concatenación de cualquier lenguaje de programación común
más los operadores de desplazamiento para vectores unidimensionales que fueron
añadidos en VHDL-93.
En la Tabla 2-1 se muestran todos los operadores predefinidos de VHDL orde-
nados decrecientemente según su grado de precedencia con el tipo de datos que
pueden adoptar sus operandos. Como puede apreciarse, cada operador puede apli-
TABLA 2-1. Operadores predefinidos en VHDL según su precedencia
Op. Descripción Tipo operandos Resultado
** potencia entero op entero entero

real op entero real
abs valor absoluto numérico ídem operando
no! negación bit, booleano, vector bits ídem operando
* multiplicación entero op entero entero
real op real real
físico op entero físico
físico op real físico
entero op físico físico
real op físico físico
división entero op entero entero
real op real real
físico op entero físico
físico op real físico
físico op físico entero
mod módulo entero op entero entero
rem resto entero op entero entero
+ más unario numérico ídem operando
menos unario numérico ídem operando
+ suma numérico op numérico ídem operandos
resta numérico op numérico ídem operandos
& concatenación vector op vector vector
vector op elemento vector
elemento op vector vector
elemento op elemento vector
sil despl. lógico izq. vector bits op entero vector bits
srl despl. lógico der. vector bits op entero vector bits
sla despl. aritoizq. vector bits op entero vector bits
sra despl. aritoder. vector bits op entero vector bits
rol rotación izquierda vector bits op entero vector bits
ror rotación derecha vector bits op entero vector bits
= igual que no fichero op no fichero booleano
1= diferente que no fichero op no fichero booleano
< menor que no fichero op no fichero booleano
> mayor que no fichero op no fichero booleano
<= menor o igual que no fichero op no fichero booleano
>= mayor o igual que no fichero op no fichero booleano
and y lógica bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
or o lógica bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
nand y lógica negada bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
nor o lógica negada bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
xor o exclusiva bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
xnor o exclusiva negada bit, booleano, vector bits op bit, booleano, vector bits ídem operandos
carse sobre un conjunto de tipos de datos diferente, por lo que realmente en VHDL
existen varias definiciones distintas del mismo operador. Esta característica, llama-
da sobrecarga de operadores, resulta muy útil, ya que permite redefinir los operan-
dos predefinidos sobre tipos de datos definidos por el usuario. Por ejemplo, en el
paquete std_logic_1l64 de IEEE se definen muchos de estos operadores para traba-
jar con el tipo de datos std_ulogic_vector. Puede existir un número ilimitado de de-
finiciones de un operador, la única condición que se debe cumplir es que no se repi-
tan los tipos de ios operandos y del resultado en dos definiciones diferentes de un
mismo operador, ya que de ser así, no habría forma de saber a qué operando se está
haciendo referencia.
2.4.5. Atributos
Un atributo es una característica que se puede asociar a cualquier elemento de un

modelo VHDL como puede ser un tipo de datos, un objeto, una entidad o un proce-
dimiento. No se debe confundir un atributo de un objeto con su valor, ya que en un
momento dado cada objeto tiene un único valor mientras que puede tener muchos
atributos asociados. VHDL proporciona una serie de atributos predefinidos además
de permitir la definición de nuevos atributos.
La sintaxis VHDL para utilizar un atributo de un elemento es la siguiente:
identificador_elemento'identificador_atributo
En las siguientes secciones de este apartado se presentarán los atributos prede-

finidos del lenguaje y a continuación se mostrará la forma cómo un diseñador pue-
de definirse sus propios atributos.
2.4.5.1. Atributos de rangos de vectores
En la Tabla 2-2 se muestran los atributos predefinidos sobre los rangos de los vecto-
res restringidos (constrained array). La letra A que se utiliza para denominar este
TABLA 2-2. Atributos predefinidos para rangos de vectores
Atributo Descripción
A'left(n) Valor izquierdo del Índice n de A.

A'right(n) Valor derecho del Índice n de A.
A'low(n) Valor mínimo del Índice n de A.
A'high(n) Valor máximo del Índice n de A.
A 'ascending(n) Verdadero si el rango del Índice n de A es ascendente.
A'range(n) Rango del Índice n de A.
A 'reverse _range(n) Rango del Índice n de A invertido.
A 'length(n) Número de valores del rango n de A.
tipo de atributos proviene de la palabra inglesa array, que significa vector. La inclu-
sión de la dimensión sobre la que se aplica el atributo es opcional, en caso de no es-
pecificarse se usará el primer índice del vector.
Normalmente es recomendable utilizar esta clase de atributos en lugar de litera-
les específicos para cada tipo de datos, ya que se obtienen modelos más generales
que facilitan la actualización del código. Por ejemplo, si se considera el siguiente
código:
type Palabra: bit_vector(O te 7);

signal Dato : PéU~:r;il.i
process (Dato]
begin
for i in O te 7 loop
if Dato(i) - ...
end loop;
end process;
Un cambio en el número de bits por palabra obliga a modificar la declaración

del tipo palabra, así como de cualquier parte del código que haga referencia a este
parámetro, como el bucle del ejemplo (los bucles se verán en el siguiente apartado
de este capítulo). En cambio, este mismo código se podría haber escrito:
type Palabra: bit_vector(O te 7);

signal Dato : Palabra;
process (Dato)
begin
for i in Dato!~ge loop
if Dato(i) - ...
end loop;
end process;
Con lo que un cambio en el rango del tipo Palabra no provoca ninguna modifi-
cación en el bucle que, al utilizar el atributo range, ya refleja este cambio automáti-
camente.
2.4.5.2. Atributos de tipos de datos
En la Tabla 2-3 se muestran los principales atributos aplicados a tipos de datos. La

letra T sirve para indicar que el elemento sobre el que se aplica el atributo es un ti-
po de datos.
Como puede observarse, cada atributo devuelve un valor de un tipo de datos
diferente. Muchas veces el valor devuelto forma parte del conjunto de valores defi-
nidos por el tipo T, aunque esto no tiene por qué ser así, habiendo algunos atributos
que siempre devuelven valores numéricos, booleanos o cadenas de caracteres. Los
atributos pos, val, succ, pred, leftof y rightof se pueden aplicar solamente a tipos
discretos y físicos, ya que, por ejemplo, no tiene mucho sentido determinar el nú-
TABLA 2-3. Atributos predefinidos para tipos de datos
T'base Tipo base de T.

T'left Valor más a la izquierda de T.
T'right Valor más a la derecha de T.
T'low Valor mínimo de T.
T'high Valor máximo de T.
T'ascending Verdadero si T tiene rango ascendente.
T'image(x) Representación textual del valor x de tipo T.
T'value(x) Valor expresado por la cadena de caracteres.
T'pos(x) Posición ocupada por x en T.
T'val(x) Valor de la posición x en T.
T'succ(x) Valor de la posición siguiente a x en T.
T'pred(x) Valor de la posición anterior a x en T.
T'leftof(x) Valor de la posición derecha a x.en T.
T'rightof(x) Valor de la posición izquierda a x en T.
mero siguiente de un valor real. Finalmente, cabe destacar que los atributos aseen-
ding, value e image fueron introducidos en VHDL-93.
2.4.5.3. Atributos de señales
En la Tabla 2-4 se muestran los principales atributos que se pueden aplicar a una se-
ñal. La letra S como prefijo del atributo sirve para especificar que se trata de atribu-
tos aplicados a una señal.
TABLA 2-4. Atributos predefinidos para señales
S 'delayed(t) Señal S retrasada t unidades de tiempo.

S 'stable(t) Señal booleana verdadera si S es estable hace t unidades de tiempo.
S'quiet(t) Señal booleana verdadera si no ha habido ninguna asignación a S en
t unidades de tiempo.
S 'transaction Señal de tipo bit, vale' l' cuando hay asignación a S.
S'event Verdadero si ocurre un evento en S.
S'active Verdadero si ocurre una asignación en S.
S 'last_event Unidades de tiempo desde el último evento.
S 'last_active Unidades de tiempo desde la última asignación a S.
S'last_ value Valor anterior de S.
S'driving Verdadero si el proceso actual "conduce" S.
S 'driving_ value Valor que conduce a S el proceso actual.
Cabe destacar que los atributos delayed, stable, quiet y transaction devuelven
una señal, mientras que los demás atributos siempre devuelven un valor de un tipo
de datos, los más comunes son el tipo físico time y el tipo booleano Por último, cabe
decir que los atributos driving y driving_value fueron incluidos en VHDL-93, por
lo que un analizador de VHDL-87 no los reconocerá.
2.4.5.4. Atributos definidos por el usuario
Aparte de los atributos predefinidos, VHDL permite definir nuevos atributos que se
pueden asociar a cualquier elemento del lenguaje. Para hacerlo, en primer lugar se
debe declarar el atributo asignándole un identificador y el tipo de datos del valor
que devolverá. Una vez declarado, se debe especificar el elemento al que va asocia-
do y su valor. Los atributos definidos por el usuario siempre son estáticos, es decir,
constantes.
La sintaxis VHDL para declarar un atributo es la siguiente:
attribute identificador : tipo_datos;
Mientras que la sintaxis para la especificación del atributo es:

attribute identificador of id_elemento.: clase_elemento is expresión;
El identificador del elemento sirve para determinar el elemento específico al

que se le aplica el atributo, mientras que la clase del elemento determina su natura-
leza; por ejemplo, indica si se trata de una señal, un procedimiento o una entidad.
Finalmente, para utilizar un atributo definido por el usuario se debe proceder
del mismo modo que antes:
identi ficador_elemento' identifididor_atributo
La zona de código donde debe especificarse un atributo dependerá del elemen-

to al que vaya asociado el atributo. Por ejemplo, si el atributo se aplica a un tipo de
datos, a un objeto o a un subprograma se podrá declarar una vez se haya declarado
el tipo, el objeto o el subprograma correspondiente, si se asocia a una entidad, una
arquitectura o un paquete se podrá declarar en la zona destinada a declaraciones de
cada una de estas unidades de diseño. Por otra parte, la única condición que debe
cumplir la declaración de un atributo es que sea anterior a su especificación, por lo
que muchas veces se incluyen todas las declaraciones de atributos en un paquete.
A continuación se dan algunos ejemplos de definición de atributos aplicados a
elementos de diferentes clases. En primer lugar, se podría definir un atributo que in-
dicara el número de pin que se va a utilizar para una determinada señal:
signal Reloj : stQ_logic;
attribute NumeroPin : natural;
attribute NumeroPin of Reloj : signal is 5;
También se podrían definir atributos que almacenaran el retardo desde cada en-
trada a cada salida de una entidad:
entity MUX21 la
port (a, b, ctrl : in bit;
z : out bit);
attribute DeAaZ : time;
attribute DeBaZ :'time;
attribute DeCtr1aZ : time;
attribute DeAaZ af AND2 : entity ia 1.2 na;
attribute DeBaZ af AND2 : entity ia 1.2 ns;
attribute DeCtrlaZ af AND2 : entity ia 1.0 ns;
end entity MUX21.
Como último ejemplo, los literales de un tipo enumerado también podrían tener
un atributo para determinar su codificación:
type PuntosCardinales ia (norte, sur, este, oeste);

attribute CodigoEstados : bit_vector;
attribute CodigoEstados af norte: literal ia "10";
attribute CodigoEstados of sur : literal ia ·00";
attribute CodigoEstados of este: literal la "11";
attribute CodigoEstados af oeste: literal ia '01";
2.5. SENTENCIAS SECUENCIALES
En este apartado se describen todas las sentencias secuenciales que pueden usarse
en el lenguaje VHDL. Las sentencias secuenciales son aquellas que nos permiten
describir o modelar funcionalidad de un componente, y pueden encontrarse en los
procesos o en los cuerpos de los subprogramas.
Las podemos clasificar en sentencias de asignación (a señal y a variable), sen-
tencias condicionales (ij, case), sentencias iterativas (loop, exit, next), otras senten-
cias (wait, assert, null) y llamadas a subprogramas.
2.5.1. La sentencia wait
La sentencia wait indica en qué punto del flujo debe suspenderse la ejecución de
un proceso, al mismo tiempo puede fijar en qué condiciones debe reactivarse di-
cho proceso. Al ejecutar la sentencia wait el proceso se suspende y al mismo tiem-
po se fijan las condiciones para su reactivación. La sintaxis general de la sentencia
wait es:
[etiqueta: 1 wait [en señal (,..•})
[untll expresión_booleana)
[for expresion_tiempo)
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la sección

2.5.13.
Veamos cómo se comporta la sentencia wait para cada una de las posibilidades
que ofrece su sintaxis.
La primera forma en que se puede utilizar la sentencia wait es sin ningún tipo
de condición para despertar al proceso. Esto significa que el proceso en cuestión
ejecutará las sentencias que contenga hasta el wait y entonces se suspenderá, sin
que pueda volver a activarse en toda la simulación. El uso más común de este estilo
de sentencia wait lo encontramos en los bancos de pruebas, que normalmente espe-
cifican una serie de acciones o pruebas a realizar sobre el dispositivo a verificar, y a
continuación se termina la simulación. El esquema habitual de esta estructura se
muestra en el siguiente ejemplo:
proces
begin
sentencfas_secuenciales
wait;
end process;
La segunda forma de usar la sentencia wait establece a qué señales será sensi-
ble el proceso (wait on lista_señales). Por lo tanto, siempre que se produzca un
evento en alguna de las señales indicadas en la sentencia wait el proceso se desper-
tará y ejecutará sus sentencias secuenciales hasta ejecutar otra vez una sentencia
wait. Es usual utilizar esta forma de la sentencia wait para modelar lógica combina-
cional que debe responder a cualquier cambio que se produzca en sus entradas. El
siguiente ejemplo modela una puerta and de dos entradas:
process
begin
e <= a and b;
wait on a, b;
end process;
Este proceso ejecuta la sentencia c<=a and b y luego se suspende. Se reactiva-

rá cuando se produzca un evento en a o en b. '
Al suspender un proceso también puede fijarse una condición para su reactiva-
ción, esta condición se especifica con la forma wait until condición_booleana. En
condición_booleana puede aparecer cualquier expresión que al evaluarse de como re-
sultado TRUE o FALSE. Un ejemplo típico de este uso de la sentencia wait se en-
cuentra en el modelado de elementos sensibles al flanco de un reloj. El siguiente pro-
ceso describe el comportamiento de un biestable sensible al flanco de subida del reloj:
process
begin
q <= d;
wait until Reloj~'l';
end process;
Al ejecutar la sentencia wait el proceso se suspenderá y no se reactivará hasta

que se produzca un evento en Reloj y además Reloj pase a valer' 1'. Si al llegar a
esta sentencia wait, Reloj ya valiese '1', entonces el proceso no se reactivaría, ya
que debe cumplirse que haya un evento en la señal además de cumplirse la condi-
ción booleana.
Por último al suspender un proceso se puede especificar un cierto tiempo antes

de que éste se reactive. Para ello se utiliza la forma wait for; como ejemplo, el si-
guiente proceso utiliza esta opción de la sentencia wait para generar un reloj de un
determinado periodo.
process
begin
Reloj <= not Relój;
wait for 10 na;
end process;
Cada vez que el proceso se suspenda, se fija su reactivación para 10 ns más tar-
de, de modo que lo que se hace es generar un reloj de 20 ns de periodo.
Estas distintas opciones de la sentencia wait pueden mezclarse de forma que se
pueden especificar condiciones de reactivación de un proceso más complejas que
las vistas en los ejemplos anteriores. Por ejemplo, la siguiente sentencia:
wait en a, b until c='l'
Suspende el proceso en que se encuentre hasta que haya un evento en a o en b

y además se cumpla la condición c='] '. El proceso sólo es sensible a las señales a o
b, de forma que un evento sobre la señal e que provoque que el valor de ésta pase a
ser '1' no implica que el proceso deba despertar.
Otro ejemplo de un uso complejo de la sentencia wait puede ser:
wait on a, b, for 10 na;
En este caso el proceso se suspende hasta que haya un evento en a o en b, o

bien hasta que el tiempo de simulación avance 10 ns. Después de este tiempo, y
aunque no se produzca ningún evento en las señales a o b, el proceso será reacti-
vado.
2.5.2. Asignación a señal
La asignación a señal como sentencia secuencial (dentro de un proceso o del cuerpo

de un subprograma) presenta la siguiente sintaxis en su forma más sencilla:
[etiqueta ; 1 nombre_señal <= valor {after expresion_tiempo}

2.5.13.
Recordemos que las señales en VHDL son objetos que consisten en un valor
actual (el que en cada momento pueden leer los procesos que son sensibles a dicha
señal) y un conjunto de pares tiempo valor, que forman la historia futura de la señal
o cola de eventos de la señal. Recordemos también que incluso en el caso de ejecu-
tar una asignación a señal sin especificación alguna de retardo, la asignación del
nuevo valor no se producirá hasta pasado un retardo delta. En definitiva, antes de
pasar a estudiar con más detalle las opciones de la asignación a señal, debe quedar
claro que al ejecutarse una de estas sentencias, no se está modificando el contenido
de la señal, sino que se está modificando el contenido de su cola de eventos, es de-
cir, se está proyectando un pasible cambio del valor futuro de la señal, que algunas
veces puede no llegar a producirse.
Para dejar claro este comportamiento de la asignación a señal (que al principio
parece extraño al compararlo con la asignación a variable), veamos un ejemplo que
nos ayude a entender mejor su funcionamiento. Supongamos que queremos in-
tercambiar el contenido de dos señales, para ello podemos escribir el siguiente pro-
ceso:
process
begin
a <= b;
b <= a;
wait on a, b;
end process;
Estas dos sentencias de asignación consiguen intercambiar el valor de las dos

señales, ya que cuando se ejecuta la segunda (b<==a), el valor de la señal a aún no
refleja la asignación b-cea, ya que ésta sólo ha proyectado un posible cambio en la
cola de eventos de a. No será hasta la suspensión del proceso (ejecución de la sen-
tencia wait) cuando las señales a y b tomen el valor que se ha proyectado en su cola
de eventos.
La forma en que se comporte la asignación a señal dependerá básicamente del
modelo de retardo elegido. VHDL permite escoger entre dos tipos de retardo: el
transporte (transport) y el inercial (inertial). El modelo transporte propaga cual-
quier cambio que se produzca, mientras que el inercial filtra aquellos cambios de
duración inferior a un mínimo. Buscando analogías con el mundo físico, el modelo
de transporte es el que refleja una línea de transmisión ideal, mientras que el mode-
lo inercial es el que rige el comportamiento de una puerta lógica.
Por defecto, VHDL supone que las asignaciones a señal siguen el modelo iner-
cial, para usar el modelo transporte debe especificarse en la asignación, utilizando
la siguiente sintaxis:
nombre_señal <= [transport] valor [after expresion_tiempo]
Veamos algunos ejemplos que nos aclaren las diferencias entre la asignación
con modelo transporte y modelo inercial. En primer lugar veamos el modelo trans-
porte, que es más intuitivo.
Al producirse una asignación a señal con el modelo de transporte, ésta proyecta
nuevos valores en la cola de eventos de la señal, de forma que si los valores se pro-
yectan para tiempos posteriores al último evento que ya tenga proyectada la cola de
eventos, éste nuevo valor se añade a ésta. Por ejemplo, para el siguiente proceso:
process
begin
s <= transport, 'o' after 10 na,
s <= transport '1' after 20 na,
wait;
end process;
Después de la ejecución de las dos asignaciones, la cola eventos de s contendrá

los valores 'O' en el tiempo 10 ns y '1' en el tiempo 20 ns (Figura 2-7-a). Pero si se
invierte el orden en que se ejecutan estas dos asignaciones:
process
begin
s <= transport '1' after 20 na;
s <= transport 'O' after 10 na;
wait;
end process;
En este caso, al ejecutarse la segunda asignación, se eliminará de la cola de

eventos el valor que había proyectado la primera, quedando proyectado en dicha
cola que s debe tomar el valor Oa los 10 ns (Figura 2-7-b). De forma que cuando se
produce una asignación a señal para tiempos anteriores a los que ya se tengan pro-
yectados en la cola de eventos, todos aquellos eventos proyectados para tiempos
posteriores son eliminados de la cola de eventos.
Cuando la asignación usa el modelo inercial (por defecto) su comportamiento
es un poco menos intuitivo, de forma que para asignaciones a tiempos anteriores
a los ya proyectados en la cola de eventos de la señal se comporta igual que el
transporte y elimina los valores proyectados para tiempos posteriores. Pero su
Cola de eventos de s
process t 10 ns
begin ____
~ v 'O'
s <= transport 'O' after 10 ns; ,__-'--_----'
s <= transport '1' after 20 ns;----.... t 10 ns 20 ns
wait;
end process;
v 'O' -r
(a)
process t 20 ns
begin
v '1'
s <= transport '1' after 20 ns; ~
s <= transport 'O' after 10 ns; ~ 10 ns
wait;
'O'
end process;
(b)
FIGURA 2-7. Evolución de la cola de eventos. Modelo de transporte.

comportamiento es distinto para asignaciones en tiempos posteriores a los pro-

yectados, de forma que si el valor asignado es igual al que se haya proyectado
para un tiempo anterior, éste se respeta. Pero si el valor asignado es distinto, se
elimina la asignación proyectada para el tiempo anterior. Repitiendo los dos
ejemplos anteriores para retardo inercial (no se especifica transport en la asigna-
ción) tenemos:
process
begin
s <= 'o' after 10 DS;
S <= '1' after 20 DS;
wait;
end process;
En este caso la asignación de '1' en el tiempo 20 ns elimina de la cola de even-

tos de s la proyección de 'O' en tiempo 10 ns, ya que el nuevo valor proyectado es
distinto al anterior (Figura 2-8-a). Para el segundo ejemplo:
process
begin
s <= '1' after 20 DS;
S <= 'O' after 10 DS;
wait;
end process;
process t 10 ns
begin ___________..
v 'O'
s <= 'O' after 10 ns; L..._--L._ __ .....J
s <= '1' after 20 ns; _

20 ns
wait;
'1'
end process;
(a)
t 20 ns
v '1'
t 10 ns
v
(b)
FIGURA 2-8. Evolución de la cola de eventos. Modelo inercial.

El comportamiento en este caso es el mismo que para el modelo de transporte,

la segunda asignación elimina el valor que la primera había proyectado sobre la co-
la de eventos de la señal (Figura 2-8-b).
Por último destacar que existe una variación de la sentencia de asignación que
permite especificar en una única sentencia un conjunto de pares tiempo/valor que
deben proyectarse sobre la cola de eventos de la señal. La sintaxis de esta varia-
ción es:
señal <= [ transport J {valor [expresion_tiempo 1 , } ;
Por ejemplo, el siguiente proceso:
procesa
begin
Operando <= O after 10 na, 10 after 20 na, 100 after 30 DS;
wait;
end procesa;
Esta asignación genera una serie de cambios sobre la señal Operando. Ésta to-
mará los valores O a los 10 ns, 10 a los 20 ns y 100 a los 30 ns independientemente
del tipo de retardo especificado.
La única diferencia que incorpora VHDL-93 a la asignación a señal secuencial
es que amplía los modelos de retardo. Para ello incluye la palabra reservada reject
(rechaza), que puede usarse como modificador del modelo de retardo inercial (y no
el transporte). Con la opción de rechazar se puede especificar para qué valores de
tiempo (qué anchuras de pulso) se debe rechazar una transición sobre una señal. Pa-
ra más detalles sobre el comportamiento de esta opción, consultar [A95][BFMR93].
2.5.3. Asignación a variable
La asignación a variable reemplaza el valor actual de la variable con el valor espe-

cificado por una expresión. Su sintaxis general es:
[etiqueta : 1 nombre_variable .:.~ expreaion,

2.5.13.
A diferencia de la asignación a señal vista en el apartado anterior, la asignación
a variable no tiene ningún retardo asociado (tampoco el retardo delta), de manera
que al ejecutarse, la variable toma el nuevo valor justo en ese momento, de forma
que las sentencias que se ejecuten a continuación ya pueden ver ese nuevo valor.
Por lo tanto, si ejecutamos el siguiente par de asignaciones:
a := b¡
b := a;
No consigue intercambiar las dos variables, sino que después de ejecutarse am-
bas variables contienen el valor inicial de b. Para intercambiar las variables debe-
mos usar una variable temporal:
'l'q) ,;;: a;
a := b;
b := 'Inp;
Una variable se declara en un proceso o en un subprograma y sólo es visible en

ese proceso o subprograma. Las variables definidas en un proceso existen durante
toda la simulación, o sea, nunca se reinicializan. Las variables definidas en un sub-
programa se reinicializan cada vez que se llama al subprograma. Si la ejecución de
un subprograma se suspende por la ejecución de una sentencia wait, entonces sus
variables mantienen su valor cuando se reactiva, hasta el momento en que se termi-
ne la ejecución del mismo.
VHDL-93 introduce una variación importante en las variables: introduce el
concepto de variable compartida (shared variable). Una variable compartida se de-
clara usando la sintaxis habitual de declaración de variable, añadiendo la palabra
clave shared:
shared variable nombre_variable : tipo_variable;
Esta declaración puede encontrarse en cualquier región declarativa, excepto en

un proceso o en un subprograma, ya que en este caso la variable será local a dicho
proceso o subprograma.
La asignación a variable compartida tiene la misma sintaxis que la asignación a
variable local y la principal diferencia estriba en qué distintos procesos o subpro-
gramas pueden realizar asignaciones sobre la variable. En caso de usar este recurso,
el usuario debe tener en cuenta que el resultado de la simulación ya no es determi-
nista, sino que depende del orden de ejecución de los procesos.
2.5.4. La sentencia if
La sentencia if se utiliza para escoger en función de alguna condición qué senten-
cias deben ejecutarse. En su forma más simple nos permite ejecutar un conjunto de
sentencias en función de una condición, en su forma más general permite decidir
entre varios conjuntos de sentencias a ejecutar, cada uno de ellos en función de dis-
tintas condiciones. La sintaxis general de la sentencia if es la siguiente:
if condicion then sentencias_secuenciales

{elsif condicion then sentencias_secuenciales}
[else sentencias_secuenciales]
end if;
Las condiciones de selección deben ser booleanas, es decir, deben retornar el

valor TRUE o FALSE como resultado de la evaluación de la expresión que consti-
tuye la condición.
La forma más sencilla en la que podemos utilizar la sentencia if es la evalua-

ción de una única condición que permite o no la ejecución de una instrucción (o de
un conjunto de ellas). Como ejemplo veamos el modelo de un biestable por nivel
(Latch) con entrada de datos (Dato) y señal de carga (Carga). Utilizaremos un pro-
ceso con una sentencia if con el propósito de modelar el comportamiento del biesta-
ble:
entity Latch is
port(
Carga, Dato : in bit;
BiestaQle : out bit)¡
end Latch;
architecture Ejerrplo of Latch is
begin .
process
begin
if Carga='l' then
Biestable <= DatO¡
end if¡
wait on Carga, Dato;
end process;
end Ejemplo;
El proceso del ejemplo es sensible a las señales Dato y Carga; por lo tanto, cada
vez que haya un evento en alguna de ellas se ejecuta. En ese caso a la señal Biestable
sólo se le asigna el valor que contenga Dato si la señal de carga vale '1'. En otro ca-
so la asignación no se ejecuta y, por lo tanto, Biestable mantiene su antiguo valor.
Una segunda forma de la sentencia if permite escoger entre dos grupos de sen-
tencias a ejecutar, dependiendo de una condición; en caso que la condición se cum-
pla, se ejecutará el primer grupo, en caso contrario se ejecutará el segundo grupo.
Un ejemplo típico del uso de esta sentencia if se puede encontrar en el modelado de
un buffer triestado. Si la señal de habilitación está activa, el buffer deja pasar a la sa-
lida el valor que tenga en su entrada, en otro caso deja su salida en alta impedancia:
entity Triestate is
port(
Habilitacion, entrada: in std-Ioqícr
Salida: out std~logic);
end Triestate; .
architecture Ejemplo of Triestate is
begin
process
begin
if Habilitacion='l' then
Salida <= Entrada;
else
Salida <= 'Z';
end if;
wait 00 Habilitacion, Entrada;
end process;
end Ejemplo;
Una tercera forma de la sentencia if permite seleccionar entre dos o más con-
juntos de sentencias a ejecutar, cada una de ellas en función de distintas condicio-
nes. Como ejemplo podemos ampliar el biestable anterior, y modelar un biestable
que tenga una señal de inicialización (Iniciar). Dejamos como ejercicio para el lec-
tor la modificación de la entidad correspondiente, a la que debe añadirse un puerto
de entrada.
process
begin
if Iniciar='O' then
Biestable <= 'O';
elsif carga='!' tben
Biestable <= Dato;
end if;
wait on Iniciar, Carga, Dato;
end process;
En este ejemplo podemos observar que.si se cumple la primera condición (Ini-

ciar= 'O') se colocará el valor 'O' sobre la señal Biestable. Sólo si no se cumple la
primera condición se considerará la segunda, y en caso que ésta sea cierta (TRUE)
se asignará Dato a Biestable. Obsérvese que la forma 'en que se ejecuta una senten-
cia if denota prioridad. O sea, el grupo de sentencias que se ejecutan en caso de
cumplirse la primera condición son prioritarias sobre el grupo de sentencias depen-
dientes de la segunda condición, ya que si la primera se cumple, el segundo grupo
no se ejecutará aun cuando su condición de control fuese cierta.
Esta última forma de la sentencia if, que permite escoger entre distintos grupos
de sentencias a ejecutar dependiendo de una condición de ejecución para cada uno
de ellos, puede ampliarse añadiendo un último conjunto de sentencias que se ejecu-
ten en caso que no se cumpla ninguna de las condiciones anteriores.
2.5.5. La sentencia case

La sentencia case se utiliza para escoger qué grupo de sentencias deben ejecutarse
entre un conjunto de posibilidades, basándose en el rango de valores de una deter-
minada expresión de selección. Ésta puede ser de cualquier tipo discreto (enumera-
dos o enteros) o de tipo vector de una dimensión. La forma general de la sentencia
case es:
[etiqueta : 1 case ex¡>resion is

when valor => sentencias':'secuenciales;
{when valor => sentencias_secuenciales;}
end case;

2.5.13.
De forma natural la sentencia case nos permite seleccionar entre un conjunto
de posibilidades. Un ejemplo típico del uso de esta sentencia es el modelado de un
multiplexor. Supongamos que tenenos un multiplexor 4-1 de datos de ocho bits, con
una señal de selección de dos bits:
entity Muxis
port(
Seleccion : in bit_vector(O to 1);
Entrada1, Entrada2, Entrada3, Entrada4 in bit_vector(O to 7);
Salida: wt bit_vector (O to 7));
end Mux;
architecture Ejemplo of Mux is
begin
process
begin
case Seleccian is
when ·00· =>
Salida <= Entrada1¡
wben ·01· =>
Salida <= jntrada2
when "lO· :;:>.
Salida <'7 Entrada3;
when "11···=:>
Salida <= Entrada4¡
end case;
wait on Seleccion, Entrada1, Entrada2, Entrada3, Entrada4;
end process;
end ejemplo;
Aunque en el ejemplo en la parte de sentencias se utiliza una sentencia de asig-

nación simple, en cada opción de la sentencia case puede usarse un grupo de sen-
tencias secuenciales tan grande y complejo como se quiera.
La sentencia case se ejecuta de forma que en cuando se encuentra que alguno
de los rangos de valores especificados coincide con el valor actual de la expresión
de selección, se ejecutan las sentencias que se encuentre en esa sección de la sen-
tencia case y se ignoran las demás.
Los valores especificados para la selección en la sentencia case deben cumplir
dos condiciones. La primera es que nunca puede haber una intersección entre el
rango de valores especificados en dos opciones distintas de la sentencia case. La se-
gunda es que la unión de todos los valores especificados debe cubrir todos los valo-
res posibles que pueda tomar la variable de selección.
Ya que es una sentencia especializada en seleccionar entre un determinado con-
junto de valores, ofrece unas opciones en cuanto a la especificación del rango de di-
chos valores, destinadas a facilitar la selección.
Se puede especificar dos o más valores dentro del rango de posibles valores
que puede tomar la expresión de selección usando la unión lógica, para la cual se
usa el signo "1". De esta forma se puede expresar la unión lógica de distintos valores
del rango con la expresión valor 1 1 valor2 1 ••• I valom. Por ejemplo, si modificamos
el ejemplo anterior, para modelar un multiplexor de tres entradas, en el cual la codi-
ficación "00" y "al" seleccionen la misma salida, podríamos escribir:
process
begin
case Seleccion is
wben "OO' I "01" =>
Salida <= Entrada!;
wben "lO" =>
Salida <= Entrada2;
wben "U· =>
Salida <= Entrada3;
end case;
wait on Seleccion, Entrada!, Entrada2, Entrada3;
end process;
Se puede especificar un rango dentro de los valores posibles de la expresión de

selección que en este caso deben tomar valores discretos (enteros o enumerados).
Para ello se puede usar la partícula to, con lo cual se puede especificar un rango co-
mo valork to valorm. Por ejemplo, volvamos a modificar nuestro multiplexor para
convertirlo en un multiplexor de dos salidas, cuya señal de selección se define de un
tipo enumerado que puede tomar los valores a, b, e, y d. Entonces podemos escribir:
process
begin
case Seleccion ls
when "a" to ·c· =>
Salida <= Entrada!;
wben "dO =>
Salida <= Entrada2;
end case;
wait on Seleccion, Entrada!, Entrada2;
end process;
Por último, se puede especificar como valor de selección la palabra clave

others, cuando en una sentencia case aparece esta opción, debe ser la última, y sig-
nifica que en caso de no escoger ninguno de los rangos especificados en las opcio-
nes anteriores de la sentencia, se ejecutarán las sentencias que se encuentren en di-
cha opción. Como ejemplo podemos modelar el multiplexor de dos entradas de la
siguiente forma:
process
begin
case Seleccion ls
when "aO to "c" =>
Salida <= Entrada!;
when others =>
Salida <= Entrada2;
end case;
wait on Selección, Entrada!, Entrada2;
end process;
Es muy habitual el uso de la cláusula others en la última opción de la senten-

cia case debido a que todos los posibles valores de la señal de selección deben
quedar cubiertos. De hecho, para el primer ejemplo del multiplexor, se ha definido
que la señal de selección (Seleccion) es de tipo bit_vector, de forma que los valo-
res "00", "O1", "10" y "11" cubren todas las posibilidades. Si la señal Seleccion
fuese de tipo std_logic_vector, debería añadirse la cláusula others al final de dicho
ejemplo.
2.5.6. La sentencia loop
La sentencia loop se utiliza para ejecutar un grupo de sentencias secuenciales de

forma repetida. El número de repeticiones puede controlarse en la misma sentencia
usando alguna de las opciones que ésta ofrece. Su sintaxis general es:
{etiqueta]: [while condícíonboolesna I for cont.r6L.iepéticion] loop

sentencias secuenciales
end loop [etiqueta];
Tal como se refleja en su sintaxis, existen diversas fornias de controlar el nú-

mero de repeticiones que producirá la sentencia loop, de forma que vamos a estu-
diar cada una de ellas.
Podemos usar la sentencia loop sin ningún tipo de control sobre el número de
repeticiones del bucle, de forma que se provoca la ejecución infinita del grupo de
sentencias secuenciales especificadas. Aunque en principio pueda parecer no muy
adecuada la definición de un bucle infinito en la descripción de un componente, és-
te puede tener sentido al modelar un dispositivo para el cual queremos fijar unos
valores iniciales, mediante la ejecución de unas sentencias, para luego pasar a eje-
cutar el conjunto de sentencias que lo modelan de forma indefinida. Aunque no sea
el ejemplo idóneo (ya que dada su sencillez se puede modelar de forma más elegan-
te sin recurrir a la sentencia loop), podemos usar este esquema para modelar un
contador de cuatro bits (módulo 16), al que queremos dar un valor inicial:
entity 'Contador_O_15 ls
port(
Reloj : in bit;
Cuenta : out natural);
end Contador_O_15;
archltecture Ejemplo of Contador_O_15 18
signal Contador : natural;
begin
process
begin
Contador <= O;
loop
wait untll Reloj='1';
Contador <= (Contador + 1) mod 16;
end loop;
end process;
Cuenta <= Contador;
end Ejemplo;
Al inicio de la simulación se ejecutará la sentencia de inicialización del conta-

dor, después pasará a ejecutarse de forma indefinida el grupo de sentencias que se
encuentran dentro del loop, en ellas se espera a que se produzca un flanco de subida
del reloj y en ese momento se incrementa el valor del contador en uno. Nótese que
una sentencia loop que no esté limitada por alguna condición de final del bucle de-
be contener alguna sentencia wait en la parte de sentencias secuenciales, de otra
forma nunca sería posible avanzar el tiempo de simulación.
Se puede definir una condición de finalización del bucle con la opción while
condicion booleana. En este caso el grupo de sentencias secuenciales especificadas
en la sentencia loop se ejecutarán mientras la condición sea cierta, cuando la condi-
ción sea falsa se abandonará el bucle para pasar a ejecutar las sentencias que apa-
rezcan a continuación. Como ejemplo podemos modificar el proceso que modela el
contador anterior sin usar la función mod de la siguiente forma:
process
begin
Contador <= Or" . j.
wait until Reloj:'l';

while Contador < 15 loop
Contador <= Contador + 1;
wait until Reloj='l';
end loop;
end process;
El bucle anterior se ejecutará mientras el contador no llegue al valor 15; en

cuanto el contador tome el valor 15, Se cumple la condición de final del bucle y, por
lo tanto, pasa a ejecutarse la primera sentencia que se encuentre después de la sen-
tencia loop, de forma que se carga el contador con el valor o.
Otra forma de controlar el número de iteraciones de la sentencia loop se deriva
del uso de la opciónfor control_repeticion. Ésta nos permite controlar el número de
repeticiones, dependiendo del rango de valores que pueda tomar la expresión de
control del bucle. Usando este mecanismo podemos modificar de nuevo el proceso
que modela el contador de la siguiente forma:
process
begin
Contador <= O;
for 1 in O to 15 loop
wait until Reloj='l';
Contador <='Contador + ·1;
end loop;
end process;
Este bucle se repetirá mientras la expresión de control (1 en este caso) tome el

rango de valores O hasta el 15, en cuanto tome el valor 16 se saldrá del bucle, de
forma que se ejecutará otra vez la inicialización del contador. La variable utilizada
como control de la sentencia loop no necesita ser declarada y puede tomar cualquier
rango de valores de tipo discreto (enumerados o enteros).
2.5.7. La sentencia exit
La sentencia exit está muy relacionada con la sentencia loop, de hecho su única uti-
lidad es ofrecer una forma de terminar la ejecución de un bucle. La sintaxis general
de la sentencia exit es:
[etiqueta :] exit [etiqueta__loop] [when condicion...,booleana]

2.5.13.
La sentencia exit puede ir acompañada de dos opciones. La primera permite
expresar una condición, en caso que ésta se cumpla se finaliza la ejecución de la
sentencia loop y se pasa a ejecutar la primera sentencia que se encuentre a continua-
ción. La segunda opción permite especificar la etiqueta de una sentencia loop con-
creta, de forma que el bucle que finaliza su ejecución como consecuencia de la sen-
tencia exit es aquel que corresponda a la etiqueta especificada. En caso de no indi-
car ninguna etiqueta se sobreentiende que se finaliza el bucle actual. Como ejemplo
de uso de la sentencia exit podemos modificar nuestro contador módulo 16 de for-
ma que tenga una señal de inicialización (Inicio).
entity Contador_O_15 is
port(
Reloj, Inicio : in bit;
Cuenta : out natural);
end Contador_O_15;
architecture Ejemplo,of Contador_O~15 ls
signal Contador. : natural;
begin
process
begin
Contador <= O;
lÓOp
wait until (RSlojíi:'l'and Reloj'event) ar Inicio='O';
exit when inicio='O';
Contador <= (Contador + 1) moa 16;
end loop;
end process;
Cuenta <= Contador;
end Ejenplo;
En este ejemplo, cuando Inicio pase a valer O se saldrá del bucle de la sentencia
loop, de forma que se ejecutará de nuevo la sentencia de inicialización del contador.
Obsérvese que en la sentencia wait se ha especificado explícitamente qué reloj de-
bía ser' l' Ydebía tener un evento. Esto se debe al hecho que al usar la opción until
especificando diversas condiciones, cada señal que aparece en las distintas condi-
ciones pasa a formar parte de la lista de sensibilidad. De forma que podría darse el
caso que un cambio de 'O' a' l' de Inicio coincidiendo con que la señal Reloj valiese
'1' se interpretase como un flanco de reloj por la forma en que se ha codificado el
proceso.
Para ejemplificar el uso de etiquetas podemos modificar de nuevo nuestro con-

tador añadiendo una señal de carga de datos. Dejamos como ejercicio para el lector
la modificación de la entidad del contador, en la que debe añadirse dos nuevos
puertos de entrada (Carga y Datos):
process
begin
Contador <= O;
carga_Datos : loop
Incremento : loop
wait until (Reloj='1' aDd Reloj'event)
ar Carga='1' ar Inicio='O';
exit Carga_Datos when Inicio='O';
exit Incremento when Carga='1';
Contador <= (Contador + 1) mod 16;
end loop Incremento;
wait until Reloj='i';
if Carga='1' then Contádor <= Datos; end if;
end loop Carga_Datos;
end process;
En este proceso se han introducido dos bucles anidados, el bucle interno (In-
cremento) es el que modela el incremento del contador a cada flanco de reloj, mien-
tras que el bucle externo (Carga Datos) es el que se encarga de cargar los datos
cuando hay un flanco de reloj y la señal de carga está activa. La primera sentencia
exit interrumpe la ejecución del bucle externo cuando se activa la señal Inicio (acti-
va a baja), de forma que se ejecuta la sentencia Contador <= O haciéndose efectiva
la inicialización. La segunda sentencia exit termina la ejecución del bucle interno,
de forma que se pasa a esperar el siguiente flanco de reloj y a cargar el contador con
los datos en caso que la señal de carga siga activa.
Obsérvese que por el orden como se han especificado las dos sentencias exit, la
señal de Inicio tiene prioridad sobre la señal de carga de datos, además la inicializa-
ción del contador es asíncrona mientras que la carga de datos es síncrona (debido al
wait until Reloj= '1' del bucle externo).
2.5.8. Sentencia next

La sentencia next está íntimamente ligada a la sentencia loop. Se utiliza para dete-
ner la ejecución de una sentencia loop y pasar a la siguiente iteración de la misma.
Su sintaxis general es:
[etiqueta:] next [etiqueta_loop] [when condicion_booleanaJ

2.5.13.
Tal como se indica en su sintaxis, se puede especificar una condición para la
cual debe pasar a ejecutarse la siguiente iteración de la sentencia loop y también
puede especificarse una etiqueta haciendo referencia a qué sentencia loop debe rea-
lizar ese salto de una iteración. Para ejemplificar el uso de la sentencia next, pode-
mos modificar nuestro contador módulo 16 de forma que no pase por el valor 8.
process
begin
Contador <= O¡
next when i=8¡
Contador <= I¡
wait until Reloj='l'¡
end loop;
end process;
Mientras el valor del índice 1 no toma el valor 8, el contador va tomando los

=
valores de este índice. Para el valor 1 8 no se ejecuta el cuerpo del bucle y pasa a
ejecutarse la siguiente iteración, con lo cual el valor del contador pasa de 7 a 9.
Aunque no quede reflejado en este ejemplo, si antes de la sentencia next hay otras
sentencias secuenciales, éstas se ejecutan aun en el caso de cumplirse la condición
de salto de iteración.
2.5.9. La sentencia assert

La sentencia assert permite reportar mensajes en función de si una determinada
condición se cumple o no, también permite interrumpir la simulación en función de
dicha condición. Su sintaxis general es:
[etiqueta :1 assert expresion,_booleana [report cadena_caracteres]

[expresion_severidad]

2.5.13.
La utilidad principal de esta sentencia estriba en ayudar a depurar un modelo
en tiempo de simulación. Funciona de la siguiente forma, en caso de no cumplirse
la condición, se envía la cadena de caracteres especificada al dispositivo estándar
de salida, y dependiendo del nivel de severidad indicado se puede interrumpir la si-
mulación.
La forma más simple de la sentencia no usa la opción de report ni la opción de
severidad; en este caso, si no se cumple la condición el mensaje enviado a la salida
es "Assertion violation", De todas formas, debido a la escasa información que ofre-
ce este mensaje, lo habitual es añadir la opción de report para dar mensaje más sig-
nificativo.
El valor de la expresión de severidad debe ser del tipo severity_level (definido
en el paquete standard). Este tipo enumerado puede tomar cuatro valores: note,
warning, error, failure. La mayoría de simuladores dejan fijar al usuario para cuál
de estos valores (en caso de no cumplirse la condición de la sentencia assert) debe
interrumpirse la simulación (no se fija en el estándar el valor de interrupción de la
simulación). En caso de no especificar el nivel de severidad, el defecto es error.
Un ejemplo típico del uso de la sentencia assert puede ser la comprobación de

tiempos en el modelado de dispositivos secuenciales. El siguiente proceso modela
un biestable sensible al flanco de subida del reloj, y utiliza una sentencia assert para
comprobar que el tiempo mínimo de anchura de pulso del reloj es de 5 ns. Para este
ejemplo necesitamos usar la función now (definida en el paquete standard) que re-
toma el tiempo actual de simulación.
process
variable IniciQ_Pulso : time;
begin
case Reloj is
when '1' =>
q <= d;
Inicio_Pulso := DOW;
when 'O' =>
assert (now-!nicio__Pulso) >= 5 na
report (·pulso de relo) menor de 5 na")
severity warning;
end case;
wait on Reloj;
end process;
El proceso es sensible a la señal Reloj; por lo tanto, se activa cada vez que se
produce un evento en Reloj. Si se produce un flanco de subida del Reloj, pasa el da-
to de entrada al contenido del biestable (q <= d) y a continuación guarda en la va-
riable Inicio_Pulso el tiempo de simulación en que se ha producido el flanco de su-
bida. Al producirse el flanco de bajada, comprueba que la diferencia de tiempo en-
tre éste (tiempo actual) y el tiempo en que se produjo el flanco de subida. Si este
tiempo es inferior a 5 ns la condición de la sentencia assert no se cumple y, por lo
tanto, se envía el correspondiente mensaje a la salida estándar; para este tipo de vio-
lación se ha escogido warning como nivel de severidad.
VHDL-93 ofrece una variación de la sentencia assert: la sentencia reporto Su
sintaxis es:
report cadena_caracteres {expresión severidad]
La diferencia principal con la sentencia assert consiste en que no necesita com-

probar ninguna condición, al ejecutarse siempre se envía el mensaje al dispositivo
estándar de salida (en este aspecto es equivalente a una sentencia assert con la con-
dición forzada a falso). También varía el nivel de severidad por defecto, que en la
sentencia report es note. Por ejemplo, la siguiente sentencia:
report "paso por aqui ",
Produce el mensaje "paso por aqui" cada vez que se ejecuta, y es equivalente a:
assert FALSE report "paso por aqui" severity note
Por tanto, esta variación aparece con el ánimo de proporcionar una sentencia
que permita reportar mensajes en la simulación de forma más cómoda, en caso que
éstos no dependan de ninguna condición.
2.5.10. Llamada secuencial a subprogramas
Los subprogramas (procedimientos o funciones) que tengamos definidos en alguna

parte del código (tal como se explica en la sección 2.7) pueden ser llamados para su
ejecución en cualquier parte de un código secuencial. La sintaxis de llamada a un
procedimiento (procedure) es:
[etiqueta: 1 nombre_procedimiento [{parametros.} 1;
2.5.13. .
La sintaxis de llamada a una función (function) es:
nombre_funcion [{parametros} 1
La diferencia radica en que una llamada a función forma parte de la expresión

de una asignación o es la asignación en sí misma, mientras que la llamada a proce-
dimiento es una sentencia secuencial por sí sola.
En ambos casos al ejecutarse la llamada a subprograma, éste pasa a ejecutarse
para retornar el control a la siguiente instrucción secuencial en cuanto finalice su
ejecución.
2.5.11. La sentencia return
La sentencia return se utiliza para terminar la ejecución de un subprograma. Su sin-

taxis general es:
[etiqueta :J return [expresion};

2.5.13.
En un procedimiento la única forma posible de usar la sentencia return es sin
expresión alguna, la opción de una expresión acompañando a la sentencia return
está reservada a las funciones.
Al ejecutarse esta sentencia secuencial se retorna el control del programa a la
instrucción siguiente a la que realizó la llamada. Además, en una función esta sen-
tencia se utiliza para retornar el resultado de la ejecución de la función.
2.5.12. La sentencia null
Esta sentencia se usa para indicar que no se debe realizar ninguna acción. Su sinta-
xis general es:
[etiqueta :J null;

2.5.13.
Un ejemplo típico del uso de la sentencianull aparece en las sentencias case.

La sintaxis de la sentencia case obliga a cubrir todo el rango de posibles valores de
la selección, pero en muchos casos no para todo el rango es necesario realizar algu-
na acción. Pongamos por ejemplo una sentencia case que se utiliza para calcular el
módulo 2 de un determinado valor:
case Valor is
when O I 1 => null;
when others => Valor := Valor mod 2;
end case;
En caso que Valor valga O o 1 no debe ejecutarse la función mod, ya que Valor
ya contiene el valor correcto.
2.5.13. Etiquetas en sentencias secuenciales

del VHDL-93
Aparte de algunos cambios puntuales introducidos en VHDL-93 en cuanto a sen-

tencias secuenciales, que ya se han comentado (variables compartidas y sentencia
report), el principal cambio que aporta a las sentencias secuenciales es la posibili-
dad de especificar una etiqueta en cualquiera de ellas (las sentencias loop ya tenían
esta posibilidad en VHDL-87).
Estas etiquetas en las sentencias secuenciales aparecen para permitir definir
atributos sobre dichas sentencias, ya que al definir un atributo sobre la etiqueta, éste
quedará asociado a la sentencia de dicha etiqueta.
Por el momento el uso de atributos (ya sean predefinidos, ya sean definidos
por el usuario) es muy dependiente de implementación, y la mayoría de ellos diri-
gidos a síntesis. Por ejemplo, se puede usar un atributo sobre una sentencia se-
cuencial para especificar que dicha sentencia se realice (se sintetice) con un deter-
minado recurso. En todo caso, este tipo de facilidades van a ser dependientes, de la
herramienta. A efectos de simulación, el uso de etiquetas en sentencias secuencia-
les no aporta ventajas significativas, aparte de permitir mejorar la documentación
en algunos casos.
2.6. SENTENCIAS CONCURRENTES
En los siguientes apartados se presentarán las sentencias concurrentes del VHDL.

La característica común a todas ellas es que se ejecutan en paralelo. Principal-
mente las encontraremos en las arquitecturas de los modelos y no estarán conteni-
das en ningún proceso. Algunas de ellas tienen su equivalente en las sentencias
secuenciales, mientras que otras son propias de las sentencias concurrentes, espe-
cialmente aquellas cuya utilidad principal está en la descripción de la estructura
del diseño.
2.6.1. La sentencia process
Un proceso es una sentencia concurrente que define su comportamiento a través de

sentencias secuenciales. Cualquier sentencia concurrente o secuencial VHDL tiene
su proceso equivalente, de hecho el simulador VHDL sólo trabaja con procesos. La
sintaxis general de un proceso es:
[etiqueta :] process [(nombre_señal (,.••})] [is]

declaraciones
begin
sentencias_secuenciales;
end process [etiqueta];
La etiqueta del proceso es opcional, sirve para identificar al proceso, y puede

ser útil en las tareas de depuración del código. La parte de declaraciones se utiliza
para declarar datos locales al proceso, también puede contener subprogramas loca-
les al proceso. La parte de sentencias secuenciales es la que define el comporta-
miento del proceso a través de un algoritmo. La partícula is es opcional, y aparece
en VHDL-93.
Un proceso es un bucle infinito, al llegar a su final (end process) vuelve a su
primera sentencia secuencial (que aparece después del begin) para continuar su eje-
cución. La ejecución del proceso se detiene (el proceso se suspende) al ejecutar una
sentencia wait, al mismo tiempo la ejecución de la sentencia wait suele fijar las con-
diciones para despertar al proceso y continuar con su ejecución (fijar a qué señales
es sensible el proceso). Nótese que un proceso que no contenga ninguna sentencia
wait entra en un bucle infinito que impide que avance el tiempo de simulación.
Aunque en general un proceso puede contener más de una sentencia wait, exis-
te una sintaxis simplificada, que equivale a definir un proceso con una única senten-
cia wait como última sentencia del mismo. En este caso el proceso no puede conte-
ner ningun:a sentencia wait. Por tanto, el proceso que se escribe a continuación:
process
begin
sentencias secuenciales;
wait en lista de sensibilidad;
end process;
es equivalente al siguiente proceso:
procesB (lista sensibilidad)

begin
sentencias secuenciales;
end process;
Un proceso que no asigna valores a ninguna señal (y, por lo tanto, no puede
despertar a otros procesos, se llama proceso pasivo. Los procesos pasivos pueden
aparecer en la declaración de entidad de un modelo.
2. Presentación del lenguaje VHDL 1 03
2.6.2. Asignación a señal concurrente
La asignación a señal puede darse también en el mundo concurrente. En este caso la

asignación concurrente a señal tiene un proceso equivalente con una asignación se-
cuencial a señal. La forma más sencilla de su sintaxis es:
[etiqueta: 1 nombre_señal <= [transportl forma onda:
La etiqueta es opcional, sirve para identificar al proceso y puede ser útil en las
tareas de depuración del código. La asignación a señal concurrente es una forma
compacta de escribir una asignación a señal secuencial, se comporta de la misma
forma que ésta (sección 2.5.2) y su principal diferencia radica en que se encuentra
en las arquiteturas (architecture), en lugar de encontrarse en procesos o subprogra-
mas.
La asignación concurrente es sensible a las señales que se encuentren a la dere-
cha de la asignación, o sea, que formen parte de la expresión que se asigne. De for-
ma que la siguiente asignación concurrente:
a <= b;
Es equivalente al proceso
process(b)
begin
a <= b;
end process;
Aunque en este ejemplo se ha presentado una asignación muy simple, la asig-

nación concurrente permite algunas opciones potentes que le dan una gran flexibili-
dad y que hacen que pueda tener cierta analogía con las sentencias secuenciales
condicionales. Por ello estas formas compuestas de asignación concurrente se estu-
dian en las siguientes secciones.
La principal diferencia que incorpora VHDL-93 a la asignación a señal concu-
rrente es que amplía los modelos de retardo. Para ello incluye la palabra reservada
reject (rechaza), que puede usarse como modificador del modelo de retardo inercial
(y no el transporte). Con la opción de rechazar se puede especificar para qué valo-
res de tiempo (qué anchuras de pulso) se debe rechazar una transición sobre una se-
ñal. Para más detalles sobre el comportamiento de esta opción consultar
[A95][BFMR93].
2.6.3. Asignación concurrente condicional
La asignación concurrente condicional es una forma compacta de expresar las asig-

naciones a señal usando la sentencia if secuencial. Su sintaxis es:
[etiqueta : 1 nombre_señal <= [transport 1

fforma_onda when expresion_booleana else}
fOIma_onda [when expresion_booleanal;
La etiqueta del proceso es opcional, sirve para identificar al proceso y puede

ser útil en las tareas de depuración del código.
La sentencia funciona de forma que el valor que se asigna a la señal es el que
se especifica en la condición que se cumple. Esta asignación concurrente se ejecuta-
rá cada vez que se produzca un evento en las señales que forman parte de la expre-
sión de asignación (forma_onda) o en las señales que forman parte de la condición
(expresion_booleana).
Como ejemplo típico del uso de una asignación condicional concurrente pode-
mos modelar un multiplexor 2-1:
Salida <= Entradal when Sel='O' else
Entrada2;
Cuyo proceso equivalente es:
process(Sel, Entrada!, Entrada2)

begin
if Sel='O' then
Salida <= Entrada!;
else
Salida <= Entrada2;
end if;
end process;
Las principales diferencias que introduce VHDL-93 en la asignación concu-

rrente condicional son:
• Permite que la última asignación tenga también condición (en VHDL-87 la
sentencia debía acabar con una expresión de asignación sin condición).
• Ofrece la posibilidad de no realizar ninguna asignación en alguna de las op-
ciones, para ello introduce la palabra reservada unnafected.
Por supuesto, además de estas modificaciones, también incorpora la modifica-
ción del modelo de retardo inercial descrito en la sección 2.6.2. Descripciones más
amplias de las variaciones introducidas en VHDL-93 a la asignación a señal pueden
encontrarse en [A95][BFMR93].
2.6.4. Asignación concurrente con selección
La asignación concurrente con selección es una forma compacta de expresar las

asignaciones a señal usando la sentencia case secuencial. Su sintaxis es:
[etiqueta :] with expresion select

nanbre~eñal <= [traDSPOrt ]
{forma_onda when valor.}
forma_onda when valor;
La etiqueta del proceso es opcional, sirve para identificar al proceso y puede

ser útil en las tareas de depuración del código.
La sentencia funciona de forma que la forma de onda que se asigna a la señal

es la que se especifica en la opción correspondiente al valor que toma la expresión
de selección. Esta asignación concurrente se ejecutará cada vez que se produzca un
evento en las señales que forman parte de la expresión de selección (expresion) o en
las señales que forman parte de la expresión de la asignación (forma_onda).
Como ejemplo podemos modelar una unidad aritmética lógica que contiene las
operaciones de sumar, restar, and lógica y or lógica:
with Operacion select

result <= Opl + Op2 when suma,
Opl - Op2 when resta,
Opl lUId Op2 when andl,
Opl or Op2 when orl;
El proceso equivalente para esta asignación es el siguiente:
process (Opl, Op2, Operacion)

begin
case Operacion 1s
when suma =>
Result <= ~1 + Q;>,2;
when resta =>
Result <= Opl - Op2;
when andl =>
Result <= Opl lUId Op2;
when orl =>
Result <= Opl or Op2;
end case;
end process;
La diferencia principal respecto a VHDL-93 consiste en que éste permite usar

la opción unaffected en la asignación que se quiera, de forma que dependiendo del
valor de la expresión no se asigne ningún valor. Además, también incorpora la va-
riación sobre el retardo inercial (reject) descrita en la sección 2.6.2. Para más deta-
lles sobre las diferencias incorporadas en el VHDL-93 consultar [A95][BFMR93].
2.6.5. Assert concurrente

La sentencia assert puede darse también en el mundo concurrente. En este caso tie-
ne un proceso equivalente con una sentencia assert secuencial. La forma más senci-
lla de su sintaxis es:
[etiqueta: 1 assert expresion_booleana
[report expresionl
[expresion_severidadl ;
La etiqueta es opcional, sirve para identificar al proceso y puede ser útil en las
tareas de depuración del código. La sentencia assert concurrente es una forma com-
pacta de escribir una sentencia assert secuencial, se comporta de la misma forma
que ésta (sección 2.5.9) y su principal diferencia radica en que se encuentra en las
arquitecturas (architecture), en lugar de encontrarse en procesos o subprogramas.
El proceso equivalente contiene una sentencia assert con la misma condición
(expresion_booleana) el mismo mensaje en report y el mismo nivel de severidad.
La sentencia se ejecutará cada vez que se produzca un evento en cualquiera de las
señales que aparezcan en la condición. De esta forma la siguiente sentencia assert
concurrente:
assert not (s='1' aDd r='l')

report "uso incorrecto de la báscula RS·;
Es equivalente al proceso
process(r, s)
begin
assert not (s='1' aDd r='l')
report "uso incorrecto de la báscula RS·;
end process;
Nótese que éste es un proceso pasivo, que no realiza asignación alguna a señal
y que, por lo tanto, puede aparecer en la entidad del diseño. Por lo tanto, la senten-
cia assert concurrente también puede aparecer en la entidad del modelo.
La variación de la sentencia assert introducida en VHDL-93 y descrita en la
sección 2.5.9 también puede presentarse como una sentencia concurrente.
2.6.6. Llamada concurrente a subprograma
La llamada a subprograma puede existir por sí sola en una arquitectura, fuera de

cualquier proceso. En este caso es una llamada concurrente a subprograma, que se
ejecutará cada vez que se produzca un evento en alguno de sus parámetros de entra-
da.
La sintaxis de llamada a un procedimiento (procedure) es:
[etiqueta :1 nombre__procedimiento [{parametros,} 1 ;
La etiqueta es opcional y sirve para identificar la sentencia.

La sintaxis de llamada a una función (junction) es:
nombre_funcion [{parametros} 1
Esta sintaxis es igual a la sintaxis para llamadas secuenciales a subprogramas y

la diferencia está que en el caso de llamadas concurrentes la llamada aparece fuera
de un proceso. En el caso de función aparecerá en una asignación a señal concu-
rrente, mientras que en el caso de procedimiento aparecerá como una sentencia con-
currente independiente. Ambos casos tienen una forma secuencial equivalente que
consiste en un proceso que contenga la llamada a subprograma cuya lista de sensi-
bilidad esté formada por los parámetros de entrada al subprograma.
2.6.7. Sentencias estructurales
VHDL proporciona un conjunto de sentencias dedicadas a la descripción de estruc-

tura del hardware. Son también sentencias concurrentes, ya que se ejecutan en para-
lelo con cualquier otra sentencia concurrente de la descripción y aparecen en la ar-
quitectura de un modelo fuera de cualquier proceso.
Además de las sentencias estructurales propiamente dichas, en este apartado
también estudiaremos las posibilidades que ofrece VHDL para configurar un dise-
ño, o sea, cuál de sus posibles arquitecturas se usa en cada caso y las posibilidades
de generalizar un diseño. Estas dos características (configuración y generalización
del diseño) son especialmente útiles y necesarias en las descripciones de estilo es-
tructural en VHDL.
2.6.7.1. Componentes
Para realizar la descripción estructural de un sistema es necesario conocer qué sub-

sistemas o componentes lo forman, indicando las interconexiones entre ellos. Para
este propósito VHDL proporciona el concepto de componente.
Para poder usar un componente VHDL exige que se realicen dos pasos: prime-
ro, debe declararse el componente, después, ya puede hacerse referencia o copia del
componente.
La declaración de un componente puede aparecer en una arquitectura o en un
paquete. Si aparece en la arquitectura, entonces se pueden hacer copias del compo-
nente en dicha arquitectura; si aparece en un paquete, se pueden hacer copias del
componente en todas aquellas arquitecturas que usen ese paquete. La sintaxis de la
declaración de un componente es:
COIIilOnent nombre_COIIilOnente [18]

[generic (lista_generic);]
[port (lista_puertos);]
end ccmponent (nombre_cooponente];
Tanto la partícula is como la repetición del nombre del componente al final de

la declaración del mismo son opcionales y aparecen en VHDL-93.
Habitualmente al declarar un componente se hará referencia a un diseño desa-
rrollado anteriormente y ya compilado en alguna biblioteca. En este caso la declara-
ción de componente coincide con la declaración de la entidad de dicho diseño, es
decir, debe tener los mismos puertos, definidos del mismo tipo y dirección. Pero
VHDL también ofrece la posibilidad de declarar un componente que aún no se ha
desarrollado, en ese caso los puertos que contenga y su tipo quedarán definidos en
la declaración de componente.
Una vez se ha declarado un componente, ya podemos realizar tantas copias o
referencias a él como se quiera. La referencia a componente es una sentencia con-
currente, que puede aparecer en una arquitectura, y que se ejecuta en paralelo con
las demás sentencias concurrentes que pueda contener esa arquitectura. Cada copia
o referencia a un componente se ejecutará cada vez que se produzca un evento en
alguna de las señales conectadas a sus puertos de entrada o de entrada/salida. La

sintaxis de la referencia a componentes es:
etiqueta_referencia: nombre_componente
[generic map (lista_asociaci6n); 1
[port map (list~asociaci6n);J
Al referenciar un componente debemos especificar qué valores queremos dar a

cada uno de sus genéricos y qué señales queremos conectar a cada uno de sus puer-
tos. De esta forma queda completamente especificada la estructura que estamos de-
finiendo, ya que habremos indicado qué componentes la forman y cómo se conec-
tan entre ellos. Como ejemplo del uso de componentes, a continuación modelamos
un sumador completo de un bit a partir de dos semisumadores de un bit y de una
puerta oro
entity SumadorCompleto is
begin
port (X, Y, Cln : in bit;
COUt, Sum : oot bit;);
end SumadorCompleto;
architecture Estructura of SumadorCompleto is
canponent Semi sumador
port(II, 12 : in bit;
COut, Sum : out bit);
end canponent;
camponent PuertaOr
port(1I, 12: in bit;
O : out bit);
end camponent;
signa! A, B, C : bit;
begin
VI : Semi sumador port map (X, Y, A, B);
U2 :'Semi sumador port map (B, crn, C, Sum);
V3 : PuertaOr port map (A, C, COut);
end Estructura;
Esta descripción VHDL refleja exactamente la Figura 2-9:
U1 U3
X
Cln
ss
S SS
U2
I e
8-- co
"'
Sum
FIGURA 2-9. Esquema lógico equivalente a la descripción VHDL.

Existen dos formas de asociar los puertos locales (los que aparecen en la decla-
ración del componente) con los puertos actuales (aquellos que aparecen en cada co-
pia de un componente).
La primera forma es la que se muestra en el ejemplo del sumador completo:
asociación posicional. Se asocia cada puerto local con su puerto actual por la posi-
ción en que aparece. Por ejemplo, la instancia U 1 del semi sumador conecta el puer-
to X del sumador a la entrada Il del semi sumador, ya que aparece en la primera po-
sición en la lista de puertos del componente.
La segunda forma es más explícita y proporciona más información. Se asocia
cada puerto actual con su puerto local especificando los nombres de ambos. Si repe-
timos la referencia U2 del ejemplo anterior con la asociación por nombre tenemos:
U2 : semi sumador port map(Il=>B, 12=>Cln, Cout=>C, SUrn=>Sum);
Usando esta nomenclatura podemos especificar la asociación de puertos de for-

ma independiente al orden que éstos ocupan en la declaración del componente. De
esta forma la siguiente referencia:
U2 : semi sumador port map (COut => C. I1=>B, 12=>Cln, COut=>Cl;
es equivalente a la anterior.
En cualquiera de las dos notaciones existe la posibilidad de dejar puertos de
salida desconectados usando la palabra reservada open en el puerto actual. En
VHDL-87 los únicos objetos que pueden aparecer como puertos actuales son las se-
ñales. VHDL-93 permite usar constantes y también expresiones estáticas como
puertos actuales.
La diferencia más importante en VHDL-93 respecto a los componentes es que
se permite referenciar un componente sin necesidad de haberlo declarado con ante-
rioridad, lasintaxis de referencia a componente en este caso es:
etiqueta_referencia :
entity nombre_entidad !(nombre_:'arqui tectura I1
[generic map (lista generlcos);)
[ port map (lista puerto's) ;]
La arquitectura de nuestro ejemplo del sumador completo puede escribirse de

la siguiente forma:
architecture Estructura of SumadorCampleto is
signal a, b, c : bit;
begin
Ul entity work;Semisumador port map (X, Y. A, Bl;
U2 : entity work.Semisumador port map (B, CIn, C, Suml;
U3 : entity work.PuertaOr port map (A, C, COUtl;
end estructura;
En este caso hacemos referencia a la biblioteca work porque suponemos que es

en ésta donde encontramos compiladas las entidades que referenciamos. Obsérvese
que en este ejemplo no se ha hecho referencia a ninguna arquitectura, por tanto ésta
se especificará vía configuración (configuratíon), si no queremos usar la configura-

ción, VHDL-93 permite especificar la arquitectura a utilizar en la misma referencia
al componente. De esta forma podemos escribir:
U1 entity work.Semisumador(Funcional) port map (X, Y, A, Bl;

02 entity work.Semisumador(Estructural) port map (B. C,In, e, $.Un);
U3 entity work.PuertaOr(Logica) port map (A, C, COut);
En este caso estamos indicando que para el componente Ul debe usarse la ar-
quitectura Funcional, mientras que para U2 debe usarse la arquitectura Estructural.
2.6.7.2. Sentencia genera te
Una forma habitual de describir estructura en el hardware es la realización de múl-

tiples copias de elementos iguales (o parecidos). Estas descripciones estructurales
podrían realizarse con la copia o referencia a componente que se ha descrito en el
apartado anterior, pero VHDL ofrece una forma más cómoda y compacta para reali-
zar descripciones que se basen en la repetición de la misma estructura: la sentencia
generate. La sintaxis básica de la sentencia generate es:
etiqueta_generate : {[for especificacion_for I if condicion]l generate

{sentencias concurrentes}
end generate;
La etiqueta es obligatoria y se usa para identificar la sentencia generate, ésta al

ser concurrente aparecerá en una arquitectura fuera de cualquier proceso o subpro-
grama. La sección de sentencias concurrentes puede contener cualquier sentencia
concurrente VHDL: process, block, assert concurrente, asignación a señal concu-
rrente, llamada concurrente a subprograma, copia de componente e incluso otra
sentencia generate.
La forma más simple de uso de la sentencia generate se presenta al describir
hardware formado por N copias del mismo componente, o sea, el mecanismo de ge-
neración consiste únicamente de la descripción del número de copias a realizar.
Pongamos, por ejemplo, qué queremos describir un registro de N bits formado a
partir de N biestables tipo D, en este caso podríamos usar el siguiente código:
entity Registro is
generic (N : positive);
port(
Reloj : in bit;
Entrada : in bit_vector (O to N-l) i
Salida: out bit_vector (O to N-U);
end Registro;
architecture Estructura of Registro 18
camponent DFF
port (Reloj, D: in bit; Q: out bit);
end cCII¡)Onent;
begin
GeneraEegistro : for 1 in O to N-1 generate

Reg : DFF port map (Reloj, Entrada (1), Salida(l));·
end generate;
end Estructura;
El mecanismo de generación de este ejemplo está formado por un bucle que se

repetirá N veces y, por lo tanto, realizará el mismo número de copias de las senten-
cias concurrentes que contiene; por lo tanto, realizará N copias del biestable DFF
conectadas de forma apropiada. El índice usado en el mecanismo de generación es
local a la sentencia generate y sólo es visible dentro de ella. En este ejemplo se ha
usado el índice para indicar qué bit de las señales entrada y salida deben conectarse
a cada una de las copias del biestable DFF.
Obsérvese que en lugar de especificar el número concreto de bits que tendrá el
registro se ha usado un genérico (generic) con el cual se puede especificar en cada
caso la longitud requerida para el registro. Si por ejemplo queremos un registro de
16 bits, se puede hacer una copia a componente de la siguiente forma:
Registro_16 : Registro generic map (16);

port map (Reloj, Entrada, Salida);
En este caso entrada y salida debe estar declarada como un bit vector de 16
bits.
Tal como se apuntaba en la descripción de la sintaxis de la sentencia, el meca-
nismo de generación además de contener una indicación de repetición puede conte-
ner condiciones. Este esquema es útil para describir elementos que están formados
por componentes distintos. Por ejemplo, podemos describir un registro de desplaza-
miento de N bits, que tendrá ligeras diferencias en los dos componentes de sus ex-
tremos:
entity RegistroDesplazamiento is
generic (N : positive);
port (
Reloj : in bit;
SIn: in bit;
SOut : out bit);
end RegistroDesplazamiento;
architecture Estructura of RegistroDesplazmento is
con¡lOnent DFF
port (Reloj, D: in bit; Q: out bit);
end COllP<)Ile!lt;
signal X : bit_vector(O tO N-7);
begin
GeneraRegistro : for 1 in O €O'N-1 generate
61: if (1=0) generate
CIzq: DFF port map(Reloj, SIn, X(I)); end generate;
62: if ((1>0) and (I<N-1)) generate
CCen: DFF port map(Reloj, X(I-1), X(I)); end generate;
63: if (I~N-1) generate
CDet : DFF port map (ReÜ:j'L'X (I:":1); SOtit); end generate;
end generate;
end Estructura;
En este caso, dependiendo de si se trata de la primera celda, de las celdas inter-

medias o de la última celda del registro de desplazamiento, se realizan las conexio-
nes de una u otra forma. Para determinar en qué tipo de celda nos encontramos, se
fijan unas condiciones sobre el índice de repetición de la sentencia generate exter-
na. Aunque no se refleja en este ejemplo, las distintas opciones condicionales de la
sentencia generate no tienen por qué hacer referencia a los mismos componentes, o
sea, en cada una de las opciones los componentes a replicar pueden ser distintos.
Obsérvese que de forma explícita la sentencia generate no contiene sección
declarativa, por ello en el ejemplo anterior se ha tenido que declarar la señal X para
realizar las conexiones entre celdas del registro de desplazamiento. Una forma más
ordenada o estructurada la ofrece VHDL-93, que permite incluir una parte declara-
tiva en la sentenciagenerate, de forma que su sintaxis es:
etiqueta_generate: {lfar especificacion for I if condicion]l generate

[{parte declarativa} . . .. .~
beginl
end generate;
En la parte declarativa de una sentencia generate puede aparecer cualquier ele-

mento que pueda aparecer en la parte declarativa de una arquitectura (constantes,
tipos, subtipos, subprogramas y señales). Los elementos que se declaren también
serán replicados y existirá una copia para cada grupo de sentencias concurrentes
generadas, a las que serán locales.
2.6.7.3. Configuración de un diseño
Como hemos dicho con anterioridad, un modelo VHDL tiene una única entidad, pe-
ro puede tener tantas arquitecturas como se quiera. Por supuesto, al simular el mo-
delo debemos escoger cuál de las posibles arquitecturas va a ser usada. El mecanismo
que permite relacionar entidad y arquitectura es la configuración (configuration).
La configuración de un diseño puede aparecer en dos entornos distintos: puede
aparecer en una arquitectura, entonces se llama especificación de configuración, o
puede aparecer como una unidad de diseño independiente, entonces se llama decla-
ración de configuración.
Si dentro de la misma arquitectura, en la cual se usa referencia a otros compo-
nentes, se quiere indicar qué arquitectura se quiere utilizar para cada uno de los
componentes referenciados, se puede usar la especificación de configuración. La
sintaxis general para la especificación de configuración es la siguiente:
for (ref_componente {, •.. } I otbers I al1) id...cooponente

use entity id_entidadl (id_arquitectura);
use configuration id...configuración;]
Usando la especificación de configuración, podemos escribir de nuevo el ejem-

plo del sumador completo usado en la sección 2.6.7.1, indicando qué arquitectura
usar para cada uno de los componentes que lo forman:
architecture Estructura of Sl.lIlladorCompleto is
declaraci6n de lo~componentes
for all : Sánisumador use entity work. Semisumador (EStructurál) ;

for U3 : PuertaOr use entity work.PuertaDt(!..ogicCl), .
begin
U1 : Semisumador port map (X, Y, A, B) ;
U2 : Semisumador port map (B,; Cln, e, Suml;
U3 :. I>uertaOr port map (A, e, COIlt);
end E!:ltr\lCt~a;
En el ejemplo se especifica que para todos aquellos componentes (jor all) del
tipo Semisumador se usará la arquitectura Estructural de dicho componente. Tam-
bién se especifica que para el componente U3 del tipo PuertaOr se usará su arqui-
tectura Logica.
La especificación de configuración puede aparecer en la parte declarativa de
una arquitectura o también en la parte declarativa de una sentencia block. Puede ser
tan simple corno la que se ha visto en este ejemplo, en el cual únicamente se especi-
fica qué arquitectura debe usarse para cada componente, o bien puede introducir
cambios en las conexiones de los puertos y en los valores de los genéricos de cada
componente, o sea, puede contener una cláusula generic map y una cláusula port
map. Cómo ejemplo de este uso más genérico podernos escribir de nuevo la arqui-
tectura de nuestro sumador completo, variando su configuración de la siguiente for-
ma:
architecture Estructura of S~dorCampleto is
declaración componente semisuriador
camponent PuertaOr
port(1l, 12 in bit:
O : out bit);
end coo;x>nent;
for all : Semisumador use entity work.Semisumador(esthtctural).;
for all : PuertaOr
use entity Puertas. PUerta0r3 (Logica)
port map(A=>I1, B=>I2, C=>'Q', Y=>O);
begin
Ul Semisumador port map (X, Y, A; Bl;
U2 Semisumador port map (A, Cln, e, Sum);
U3 PuertaOr port map (I1=>A, I2=>O, O=>OOut);
end estructura;
En este ejemplo se especifica que para todos los componentes PuertaOr (puer-
ta or lógica de dos entradas) debe usarse el componente que se encuentra en la bi-
blioteca Puertas que se llama PuertaOr3 (puerta or lógica de tres entradas) y usar
su arquitectura Logica. Ya que el componente elegido difiere en el número de entra-
das, se usa la Cláusula port map en la especificación de configuración para indicar
que la tercera entrada de la puerta or de tres entradas debe estar fijada a 'O', de ma-
nera que sea equivalente a una puerta or de dos entradas. También se indica que dos
de los puertos de la PuertaOr3 (A y B) deben conectarse a las dos entradas del com-
ponente PuertaOr (/1 y 12). Mientras que la salida del componente PuertaOr3 (Y)
debe conectarse a la salida del componente PuertaOr (O). Nótese que en el mapeo
de nuestro ejemplo se ha usado sintaxis VHDL-93, ya que para fijar un puerto al ni-
vellógico 'O' se ha asignado directamente el valor 'O' al puerto. En VHDL-87 de-
bería definirse una señal fijada a este valor lógico y asignar dicha señal al puerto.
En este uso de la configuración se muestra la máxima flexibilidad de este me-
canismo, por analogía con el hardware a veces se ha dicho que el mecanismo de re-
ferencia a un componente equivale a elegir el zócalo de un componente, mientras
que la configuración del componente escoge qué dispositivo se coloca en el zócalo.
Como ya hemos dicho, la configuración puede ser usada como una unidad de
diseño independiente, en ese caso se le llama declaración de configuración y su sin-
taxis es un poco distinta: '
configuration identificador of identificador_entidad is

for identificador_arquitectura
{for (ref_compbnente {, ..•} I others I all) id.._corrponente
use entity id_entidad! (id_arquitectura) ;
use configuration id_configuración;]
end for; )
end for;
end [configuration] [identificador];
El identificador es el nombre que va a recibir la configuración y servirá para

poder referenciarla más tarde. La partícula configuration al final de la configura-
ción es opcional y aparece en VHDL-93.
Para nuestro ejemplo, del sumador completo podemos escribir la siguiente con-
figuración:
configuration Primera of SUmadorCampleto is
for Estructura
fer Ul : Semi sumador use
entity work.Semisumador(Es~~ctural); end for;
for others : Semi sumador
use configuration work.Funcional; end for;
for all : PuertaOr
use entity Puertas.PuertaOr3{Logica);
port map(A=>I1, B=>I2, C=>'Q', 1'=>0); end for;
end for;
end Primera;
En este ejemplo se han usado muchas de las posibilidades de la declaración de

configuración, vamos a ver cada una de ellas. La declaración de configuración debe
contener un identificador de la configuración (en este caso Primera) que sirve para re-
ferenciar a dicha configuración, por ejemplo, desde configuraciones de niveles más
altos de la jerarquía. Debe especificarse qué arquitectura de qué entidad se está confi-
gurando, en este caso se indica que se está configurando la arquitectura Estructura de
la entidad SumadorCompleto y que el nombre de dicha configuración será Primera.
A continuación debe especificarse la configuración deseada para cada uno de

los componentes de la arquitectura. No tienen por qué configurarse todos los com-
ponentes de la arquitectura en la declaración de configuración, quizás alguno de los
componentes ya se configuró en el código de la misma arquitectura, o quizás algu-
no quiera configurarse desde otra declaración de configuración del diseño. En nues-
tro ejemplo sí que se han configurado todos los componentes de la siguiente forma:
Para el componente Ul, que es un Semisumador, se especifica que debe usarse
la entidad Semisumador con la arquitectura Estructural que debe encontrarse com-
pilada en la biblioteca work. Obsérvese que la sintaxis indica que la especificación
de arquitectura es opcional, en caso que ésta se omita la mayoría de herramientas
considerarán la última arquitectura que se haya analizado para la entidad indicada
en la biblioteca indicada. Por lo tanto, si consideramos que para la entidad Semisu-
mador la última arquitectura que se ha analizado es la Estructural, y que ambas se
encuentran en la biblioteca work. Entonces podemos escribir la configuración de la
referencia U1 de semisumador de la siguiente forma:
for Ul : Semisumador use entity work.Semisumador; end for;
Para el resto de referencias a componente Semisumador (others) debe usarse la

configuración llamada funcional, que también se encuentra en la biblioteca work.
En dichaconfiguración se habrá indicado qué arquitectura usar para el componente
Semisumador, por ejemplo esta configuración podría ser de la siguiente forma:
configuration Funcional of Semisumador is

for Corrportamiento
end for;
end Funcional;
La configuración Funcional del Semisumador indica que debe usarse la arqui-

tectura Comportamiento del mismo. Obsérvese que en este caso estamos configu-
rando la jerarquía del diseño a través de distintas declaraciones de configuración, en
lugar de especificar la configuración de todos los componentes del diseño en una
única declaración de configuración. Para cada nivel de jerarquía se especifica su
configuración, y en ésta puede hacerse referencia a configuraciones de niveles de
jerarquía inferiores del diseño. Por claridad y estructuración del código aconseja-
mos usar declaraciones de configuración jerárquicas en lugar de especificar la con-
figuración de todo el diseño en una única declaración de configuración.
Por último, para el componente U3 (puerta or de dos entradas) se indica que
debe usarse un componente PuertaOr3 (puerta or de tres entradas) y se indica que
el puerto C de la misma debe fijarse a 'O' para que se comporte como una puerta or
de dos entradas.
Todas las cuestiones explicadas hasta aquí para configuración de componentes
son innecesarias si se usa la referencia a componente de VHDL-93, en la cual pue-
de hacerse una copia a componente sin haberlo declarado previamente y en la cual
puede especificarse la entidad y arquitectura a usar en la misma referencia copia a
componente. Si escribimos la arquitectura del sumador completo de la sección
2.6.7.1 de la siguiente forma:
architecture Estructura of SumadorCampleto is

signal a, b, c : bit;
begin
Ul entity work.Semisumador (Comportamiento)
port map (X,.Y, a, bl; ....
U2 entity work. Semi sumador (Estructural r .
port map (B, CIn, C, SUm); .
U3 entity Puertas.PuertaOr3(Logical
port map (A=>A, B=>C, c=> '0', Ó=>COutl;
end estructura;
Estamos indicando que para el componente U1 debe usar el Semisumador con

su arquitectura Comportamiento, para el componente U2 debe usar el Semisumador
con su arquitectura Estructural y para el componente U3 debe usar el componente
PuertaOrJ que se encuentra en la biblioteca Puertas, y debe fijar su puerto de en-
trada C al valor 'O' .
Otra diferencia que incorpora VHDL-93 es la posibilidad de configuración in-
cremental de una componente. Mientras en VHDL-87 solamente puede haber una
especificación de configuración o una definición de configuración, en VHDL-93
pueden existir ambas configuraciones para un mismo componente. En ese caso de-
ben observarse ciertas reglas sobre qué puede configurarse en cada parte [A95]
[BFMR9~].
2.6.7.4. Genéricos
Tal como hemos visto en algunos de los ejemplos de apartados anteriores, VHDL
ofrece la posibilidad de generalizar un modelo, añadiendo unos parámetros lla-
mados genéricos (generics) en la definición de la entidad del modelo. Cuando el
modelo es usado como un componente el usuario fija el valor que deben tomar los
genéricos, de forma que adapta el diseño del modelo genérico a sus necesidades
concretas.
Si queremos desarrollar un modelo genérico, debemos incluir en la entidad del
mismo la cláusula generic, en ella se indicarán cuáles son los parámetros genéricos
del modelo.
Como ejemplo vamos a modelar una puerta or con tres parámetros genéricos.
El primero indica el tiempo de propagación intrínseco de la puerta (aquel que no
depende de la carga a la salida de la puerta). El segundo indica el retardo debido a
la carga (la capacidad que ataca la salida de la puerta). El tercero indica la carga a la
salida de la puerta. Además, las entradas de la puerta se modelan con un único
puerto que es un vector no restringido. De forma que el número de entradas que
tenga la puerta se fijará al hacer una copia o referencia al componente, y dependerá
de la dimensión del vector que se conecte a su puerto de entrada.
Con estos genéricos se pretende que podamos modificar los parámetros usados
en el cálculo de retardos de la puerta, dependiendo del número de entradas de ésta y
de la carga que deba atacar la salida de la misma.
entity ORN 1&

generic (Retlner time:= 1 ns;
RetCar time := 0.2 ns;
Carga real := 0.25f;
port ( Entradas in bit_vector; .
Salida: out bit);
end ORN;
architecture Funcional of ORN is
begin
process(Entradas}
variable Resultado: bit := '0';
begin
for i in entradas' range loop
if Entradas(i)='1' then
Resultado :='1';
exit;
end if;
end loop;
Salida <= Resultado after (Retlner + (RetCar * carga));
end procesB;
end Funcional;
Una vez definido este modelo, podemos hacer referencias o copias del mismo
utilizándolo como componente, en cada copia deberemos especificar qué valor con-
creto queremos darle a los parámetros genéricos. Por ejemplo, si en una referencia a
componente escribimos:
PuertaOr : ORN generic map(2 ns, O.4ns, 0.5)

port map (VectEnt, Salida);
estamos configurando nuestra puerta or genérica de forma que sus parámetros de

retardo sean 2 ns y 0.4 ns respectivamente, y la carga a su salida sea de 0.5.
Al dar valores concretos a un módulo con genéricos cuando es usado como
componente, debe usarse la cláusula generic map. Ésta sigue un conjunto de reglas
básicas que enunciamos a continuación:
• Los valores que se asignan a cada genérico deben ser constantes o expresio-
nes.
• Puede usarse asociación posicional o por nombre o una mezcla de ambas
(igual que en las clásulasport map).
• Se puede omitir el valor a asignar a cualquier genérico si éste tiene valor pre-
definido.
• Puede explicitarse que quiere usarse el valor por defecto si se asigna la pala-
bra reservada open.
De esta manera la siguiente referencia a componente:
PuertaOr : ORN generic map(Retlner => 2 ns, RetCar => 0.4 ns, Carga => 0.51
port map (VectEnt, Salida);
es equivalente a la anterior. Siguiendo con nuestro ejemplo de puerta genérica, las

siguientes copias de componentes:
PuertaOr OR_Nport map (VectEnt, Salida);
PuertaOr : OR_Ngeneric map (epen, epen)
port map(VectEnt, Salida};
PuertaOr : OR_Ngeneric map (1 D$,O.2ns, O.25)
port map(VectEnt, Salida);
son todas equivalentes entre ellas e indican que queremos usar una puerta or con
unos parámetros de tiempo de 1 ns y 0.2 ns y con una carga de 0.25, o sea, con los
valores por defecto,
2.6.8. Sentencia block

La sentencia concurrente block es una forma de reunir o agrupar sentencias concu-
rrentes, además permite compartir declaraciones de objetos que serán visibles sola-
mente para las sentencias englobadas en la sentencia block. También permite reali-
zar asignaciones a señal guardadas (guarded signals). La sintaxis de esta sentencia
es la siguiente:
- etiqueta: block lexpres ion guarda] H8)
[generic (lista._genericos); '",,' _,,' _' ,J.,
I
[generie .map (lista_asociaci6ri_:genériép~JAHr

[part (llsta_puertos); . ... , , .
[part map (Lísta asocíecíon puertospr 1)
{parte declarativa} ,_,
begin
end block [etique.ta];
La etiqueta es obligatoria y se utiliza para identificar la sentencia block. La

partícula is es opcional y sólo aparece en VHDL-93. La expresión de guarda sólo
tiene sentido que aparezca si vamos a usar asignaciones guardadas y no si usamos
el bloque con objeto de particionar u organizar el código.
Vamos a analizar por separado cada uno de los tres usos que hemos apuntado
que puede darse a la sentencia block.
Puede usarse para agrupar el código de una arquitectura en diferentes bloques,
para ello ofrece la posibilidad de incluir declaraciones locales a cada grupo. El tipo
de declaraciones que pueden aparecer en la parte declarativa de una sentencia block
son las mismas que pueden aparecer en la parte declarativa de una arquitectura. Por
ejemplo, constantes, tipos, subtipos, señales, declaraciones de subprogramas, etc.
Los objetos declarados en una sentencia block son locales a ésta; si se declara un
bloque dentro de otro bloque, los objetos locales al segundo no serán visibles en el
primero. Sí que es visible en un bloque cualquier objeto declarado en la arquitectura
que contiene a dicho bloque.
Tal como hemos indicado en su sintaxis, la sentencia block puede contener de-
claraciones de puertos y de genéricos, por lo tanto puede usarse para describir jerar-
quía. De hecho, la sentencia block es a la estructuración lo que la sentencia process es

a la simulación. O sea, cualquier otra forma de estructuración que se use en una des-
cripción VHDL es finalmente convertida a las sentencias block equivalentes. En con-
creto, la referencia o copia a componente que es la construcción básica de VHDL
usada para describir jerarquía se convierte en dos sentencias block anidadas [LSU89].
Por último, una sentencia block puede tener una condición de guarda, que debe
ser una expresión booleana que aparezca inmediatamente después de la palabra re-
servada block. Esta expresión crea de forma automática una señal booleana llamada
guard, la cual puede usarse para controlar el comportamiento o ejecución de las
asignaciones a señal contenidas en el bloque. Si en el bloque aparecen asignaciones
a señal que contengan la palabra clave guarded, éstas solamente se realizarán si la
condición de guarda es verdadera (la señal guard es TRUE). Por ejemplo, podemos
modelar un biestable sensible a flanco de reloj de la siguiente forma:
Biestable: block (Reloj='l' and not Reloj'stable)
begin
Q <= guardad D;
end block Biestable;
La asignación de D (dato de entrada) sobre Q (elemento de memoria) sólo se

realizará cuando la condición de guarda sea cierta. Por lo tanto, sólo tendrá lugar
cuando se produzca un flanco de subida de reloj.
De todos los usos de la sentencia block que aquí hemos descrito, el más fre-
cuente es el de las asignaciones guardadas, algunas veces se usa para encapsular có-
digo y raras veces (al menos desde el punto de vista del usuario) se usa para descri-
bir jerarquía.
2.7. SUBPROGRAMAS
Los subprogramas se usan para escribir algoritmos reutilizables. En general un sub-

programa constará de una parte declarativa, en la cual definirá estructuras de datos
locales al subprograma y una parte de sentencias (secuenciales) que describirán las
operaciones que se realicen sobre los datos.
Otra característica de un subprograma es su lista de parámetros, esto es, una
lista que se usa para especificar sobre qué datos externos al subprograma debe im-
plementar su funcionalidad en el momento en que éste se llama para que se ejecute.
Los parámetros que aparecen en la definición de un subprograma se llaman paráme-
tros formales, mientras que los parámetros que aparecen en las llamadas a subpro-
gramas son los parámetros actuales.
Un subprograma se usa para agrupar código, de forma que cada vez que deba
utilizarse podamos especificar sobre qué conjunto de datos ejecuta el algoritmo que
implementa. Aun en el caso que un subprograma se utilizase (llamase) una única
vez en un determinado modelo, podría ser interesante con la intención de obtener
un código estructurado.
Los subprogramas constan de dos partes: la definición del subprograma y la
definición del cuerpo del subprograma. En la definición de un subprograma se defi-
ne el nombre de éste y su lista de parámetros. La definición de un subprograma es

opcional y puede encontrarse en una declaración de paquete, en el cuerpo de un pa-
quete, en una entidad, en una arquitectura, en una sentencia bloque, en un proceso o
en el cuerpo de otro subprograma. La definición del cuerpo del subprograma con-
tiene la definición de las estructuras de datos locales a éste y el algoritmo que reali-
za. La definición del cuerpo de un subprograma es obligatoria y puede encontrarse
en el cuerpo de un paquete, en una entidad, en una arquitectura, en una sentencia
bloque, en un proceso o en el cuerpo de otro subprograma
VHDL ofrece dos tipos de subprogramas que a pesar de tener muchas caracte-
rísticas en común también presentan importantes diferencias, por lo tanto los vamos
a estudiar por separado.
2.7.1. Funciones
Las funciones están orientadas a realizar cálculos, podemos pensar en ellas como en
una generalización de las expresiones, son una forma de definir nuevos operadores
que pueden aparecer en una expresión.
La sintaxis para la definición de una función es:
function nombre_funcipIl. !,(Jista_parametros)] returo tiW.,...r~tqmo
La sintaxis de la definición del cuerpo de una función es:
[pure I impure] function nambre_funcion [(lista_parametros)]

returo tipo_retorno ia
{parte_declarativa}
begin
{sentencias secuenciales}
end [iunction] [nombre_funcion]
La partícula opcional function al final de la definición es propia de VHDL-93

y su único interés es mejorar la legibilidad del código. También las partículas op-
cionales pure/impure son propias de VHDL-93, sirven para explicitar si una fun-
ción es pura o impura. En general, una función pura es aquella que dado un conjun-
to de valores de sus parámetros de entrada siempre retorna el mismo resultado,
mientras que una función impura puede romper esta regla. Una discusión amplia
sobre funciones puras e impuras puede encontrarse en [A95][BFMR93].
Los parámetros formales de una función solamente pueden ser de tipo in (que
es el tipo que toman por defecto) y la clase de objetos que pueden formar parte de
dichos parámetros, por defecto se asume que son constantes.
En la parte declarativa de las funciones se pueden declarar todas aquellas es-
tructuras de datos que se requieran (tipos, subtipos, constantes y variables), pero és-
tas solamente existirán cuando la función esté activa, y se crearán e inicializarán de
nuevo cada vez que ésta sea llamada: Por este motivo no se pueden declarar señales
en la parte declarativa.
La parte declarativa de una función también puede contener definiciones de

subprogramas; éstos, al igual que cualquier tipo de datos que se haya declarado, se-
rán locales a la función y, por lo tanto, invisibles fuera de ella.
En las sentencias secuenciales que se encuentran en la parte de sentencias de
una función siempre debe haber al menos una sentencia retum. Esta sentencia será
la que retomará el único valor que una función puede devolver como resultado de
su ejecución.
En la parte de sentencias de una función no se puede modificar (no se pueden
realizar asignaciones) variables o señales externas a la función, aunque sí puede
usarse para formar parte de expresiones utilizadas en la función. En la parte de sen-
tencias de una función tampoco puede aparecer ninguna sentencia wait,
En el siguiente ejemplo mostramos una función que convierte un dato de tipo
bit_vector sin signo en su natural equivalente. La definición de la función (opcio-
nal) sería la siguiente:
function bv_to_natural (S: bit_vect;ar(O to 7)) return natural.:
La declaración del cuerpo de la función sería:
function bv_to_natural (S: bit_vector{O to 7)) return natural is

variable Resultado: natural := O,
begin
Resultado := Resultado * 2,+ bit'pos(S(i))¡
end loop¡
return Resul.tadoj . '.'.
end function bv_to_¡¡átural¡
Una vez definida esta función puede llamarse desde cualquier parte del modelo
usando bien la llamada a función secuencial o la llamada a función concurrente. En
ambos casos la llamada a función no será en sí misma una sentencia sino que for-
mará parte de una expresión. Por ejemplo:
process
variable Entrada: bit_vector(O'to''1);
variable Salida : natural¡
begin
Salida := bv_to_natural(EQtrada)¡
end process;
En este ejemplo la llamada a función representa la totalidad de la expresión,

pero la llamada a función podría formar parte de una expresión mucho más com-
pleja.
En nuestro ejemplo de llamada a función el paso de los parámetros actuales se
ha hecho por posición, pero puede hacerse también por nombre (de forma análoga a
la copia o referencia a componente). Con lo cual la llamada a función podría expre-
sarse como:
salida : = bv_tO.JJatural (S=>Entrada) i
En este ejemplo no tiene mayor importancia, ya que solamente tenemos un

parámetro de entrada, pero para funciones con mayor número de parámetros
puede aumentar la legibilidad del código el uso del paso de parámetros por nom-
bre.
2.7.2. Procedimientos
Los procedimientos (procedures) están orientados a realizar cambios en los datos

que tratan, ya sean sus parámetros ya sean datos externos a los que pueden acceder.
La sintaxis para la definición de un procedimiento es:
procedure nombre_procedimiento [(lista_parametros)]
La sintaxis de la definición del cuerpo de un procedimiento es:

procedure nombre_procedimiento ~Hlista_parametros)] ia
{parte_declarativa}
begin
{sentencias secuenciales}
end [procedure] [nombre_procedimientol
La partícula opcional procedure al final de la definición es propia de VHDL-

93 y su único interés es mejorar la legibilidad del código.
Los parámetros formales de un procedimiento pueden ser de tres tipos distin-
tos: in, out e inout, por defecto se consideran de tipo in. La clase de objetos que
pueden formar parte de los parámetros formales son constantes, variables y señales.
Por defecto, los parámetros de tipo in se consideran constantes, mientras que los de
tipo out e inout se consideran variables.
Los parámetros de modo entrada (in) se usan para pasar valores al procedi-
miento, que éste puede usar, pero nunca puede variar su valor. Los parámetros de
modo salida (out) son aquellos que el procedimiento sólo puede usar realizando una
asignación sobre ellos, o sea, puede modificar su valor pero no usar o leer su valor.
Por último, los parámetros de modo entrada/salida (inout) son aquellos que pueden
usarse o leerse dentro del procedimiento y que también puede variarse su valor me-
diante una asignación.
Al igual que para las funciones, en la parte declarativa de los procedimientos se
pueden declarar todas aquellas estructuras de datos que se requieran (tipos, subti-
pos, constantes y variables), pero éstas solamente existirán cuando la función esté
activa y se crearán e inicializarán de nuevo cada vez que ésta sea llamada. Por este
motivo no se pueden declarar señales en la parte declarativa
La parte declarativa de un procedimiento también puede contener definiciones
de subprogramas; éstos, al igual que cualquier tipo de datos que se haya declarado,
serán locales al procedimiento y, por lo tanto, invisibles fuera de él.
Un procedimiento retomará el flujo del programa al lugar donde fue llamado al
llegar al final del mismo (a su sentencia end). Como puede haber ocasiones en que
queramos salir de un procedimiento antes de llegar a su final, se puede usar la sen-

tencia return. La sentencia return en un procedimiento se usa sin ir acompañada de
ninguna expresión e indica que debe devolverse el control del programa al punto
de llamada.
La parte de sentencias de un procedimiento puede modificar (realizar asigna-
ciones) a variables o señales externas al procedimiento. En las sentencias de un pro-
cedimiento pueden aparecer sentencias wait.
En el siguiente ejemplo mostramos un procedimiento análogo al ejemplo usado
anteriormente para la función. La definición del procedimiento (opcional) sería la
siguiente:
procedure bv_to_nat1.lrar (S: bit_vector(O to 7);
X: out natural);
La declaración del cuerpo del procedimiento sería:

procedure bv_to_natural(S: bit_vector(O to 7);
" X: out natural} la
variable Resultado: natural := O; .
begin
Resultado := Resultado * 2 + bit'pos(s(i»;
end loop;
x := Resultado;
end procedure bv_to_natural;
Observemos que se han definido dos parámetros, uno de entrada (por defecto)
y otro de salida, que debe explicitarse y que se asume que es de tipo variable.
Una vez definido este procedimiento puede llamarse desde cualquier parte del
modelo usando bien la llamada a procedimiento secuencial o la llamada a procedi-
miento concurrente. Por ejemplo:
process
variable Entrada.:. bit_véctorJO te ?);
variable saHaa): natUraL
begin
bv_to_natural (Entrada, Salida);
end process;
Observemos que a diferencia de la llamada a función, la llamada a procedi-

miento es por sí sola una sentencia.
También al igual que para la llamada a función, en la llamada a procedimiento
la definición de los parámetros actuales puede hacerse por posición o por nombre.
En este caso la llamada a procedimiento se escribe como:
bv_to_natural (S=>Entrada, x=> Salida);
La diferencia en la forma de especificar los parámetros actuales sólo tiene im-

portancia para la legibilidad del código.
2.7.3. Sobrecarga de subprogramas
Dos subprogramas están sobrecargados cuando tienen como nombre el mismo iden-
tificador pero sus perfiles son diferentes, entendiendo que el perfil de un subprogra-
ma está formado por el número, el orden y el tipo de sus parámetros, así como del
tipo del valor devuelto en el caso de las funciones.
La sobrecarga mejora la legibilidad del código al permitir dar el mismo nombre
a dos subprogramas que realizan la misma función sobre datos de tipos diferentes.
De este modo, no es necesario pensar nombres distintos para cada subprograma.
Por ejemplo, se podrían definir funciones que permitieran concatenar dos cadenas
de caracteres o una cadena de caracteres con un carácter utilizando el mismo nom-
bre de función:
function Concatena (a: string¡ b: stringl return string¡
function Concatena (a: character¡ b: string) return string¡
function Concatena (a: string¡ b: character) return string¡
Dada una llamada a un subprograma, el analizador determina el subprograma

concreto que se debe ejecutar relacionando el perfil de la llamada con el de cada
subprograma sobrecargado. Las tres funciones anteriores de concatenación se acce-
derían respectivamente con las siguientes llamadas:
Cadena := Concatena (Mabcde", 'fghij")¡
Cadena := Concatena (Mabcdefghi", 'j'l¡
Cadena := Concatena ('a', "bcdefghij");
En caso de no ser posible determinar el subprograma que se debe ejecutar se

producirá un error de compilación. Por ejemplo, la siguiente llamada fallará porque
la función Concatena no se puede llamar con dos valores de tipo carácter:
Cadena := Concatena ('a', 'b');
También es posible que al realizar una llamada a un subprograma exista más de

un candidato a ser ejecutado, en este caso también se producirá un error de compi-
lación. Por ejemplo, se pueden definir procedimientos que desplacen un vector de
bits un número de posiciones a la derecha, de forma que este número de posiciones
a desplazar pueda especificarse mediante un entero o un vector de bits:
procedure DespDerecha (Vector: inout bit_vector¡
Pos: bit_vector := b"0001");
procedure DespDerecha (Vector: inout bit_vector¡ Pos: integer := 1);
Como se ve en el ejemplo, se pueden asignar valores por defecto a los paráme-

tros de un subprograma para permitir llamadas donde sólo se especifiquen estos pa-
rámetros en caso que difieran del valor que tienen por defecto. De este modo, la si-
guiente llamada al procedimiento
DespDerecha ("11001010");
produciría un error de compilación, ya que los dos procedimientos llamados Desp-

Derecha serían candidatos a ser ejecutados.
También cabe resaltar que otras cuestiones de la declaración de un subprogra-

ma, como el nombre, el modo y la clase de los parámetros, así como su valor por
defecto, no se tienen en cuenta a la hora de considerar la sobrecarga de un subpro-
grama, por lo que la declaración de las siguientes funciones produciría un error al
compilarse por duplicación de una declaración:
function Concatena (a: string; b: string) return string;
function Concatena (e: string; d: string) return string;
Un caso especial de sobrecarga se produce en los operadores, que de hecho son

una clase de funciones que pueden llamarse siguiendo una notación diferente a la
tradicional. La mayoría de operadores predefinidos en el lenguaje están sobrecarga-
dos para poder ser utilizados con diferentes tipos de datos; así, por ejemplo, el ope-
rador "+" puede aplicarse a cualquier tipo numérico entero, real o físico. Además
de la sobrecarga de operadores propia del lenguaje, VHDL permite definir los ope-
radores predefinidos sobre tipos creados por el usuario. Para hacerlo sólo hará falta
indicar que la función que se está definiendo es un operador escribiendo su nombre
entre comillas. De este modo, se podrían redefinir los operadores "+" y and sobre el
tipo MiTipo:
function "+0 (a: MiTipo; b: MiTipo) return MiTipo;
function "andO (a: MiTipo; b: MiTipo) return MiTipo;
Para hacer una llamada a estas funciones se podrá utilizar la notación propia de
los operadores:
Var3 := Varl + Var2;
Var4 := Varl and Var2;
o bien la notación propia de las llamadas a funciones:

Var3 := "+"(Varl, Var2);
Var4 := "andO (Varl, Var21;
2.7.4. Funciones de resolución
Normalmente cada señal tiene una sola fuente que le proporciona el valor en todo
momento; sin embargo, VHDL permite definir señales que pueden tomar su valor
de múltiples fuentes. Este tipo de señales se llaman señales resueltas (resolved sig-
nals) y, como en cada instante una señal tiene un único valor, deben tener una fun-
ción de resolución (resolution function) asociada que determine el valor que deben
contener en todo momento. La posibilidad de disponer de más de una fuente hace a
este tipo de señales muy adecuadas para el modelado de buses.
Una función de resolución es una función que toma como entrada un vector
unidimensional no restringido con los valores de todas las fuentes de la señal re-
suelta y devuelve el valor que debe recibir dicha señal. VHDL llama a esta función
cada vez que se realiza una asignación sobre la señal, en este momento se determi-
na el número de elementos del vector de entrada a la función, que será igual al nú-
mero de fuentes que tenga la señal. Las fuentes de una señal vendrán determinadas
tanto por las sentencias de asignación en diferentes procesos como por las salidas
de componentes conectadas a dicha señal.
Para tratar con señales resueltas se podría definir, por ejemplo, el tipo XOIZ,
que aparte del cero y el uno lógico introduce el desconocido y la alta impedancia.
También se definiría el tipo vector de XOIZ necesario para el parámetro de entrada
de la función de resolución:
type X01Z ls ('X', 'O', '1', ·'Z');

type X01Z_vector is array (natural range <» of X01Z;
Se puede declarar una función de resolución para este tipo de datos de la si-
guiente manera:
function Rescluci.on (Fuentes: X01Z_téctor) return Xd1Z;
A continuación, para introducir una señal resuelta sólo se debe añadir el nom-
bre de la función de resolución al resto de información requerida en la declaración.
De este modo, cada vez que se realice una asignación sobre la señal se llamará a la
función de resolución para que decida el valor que se debe asignar. Por ejemplo, se
podría crear una señal de lectura y escritura de una memoria compartida por varios
procesadores de la siguiente forma:
signal LectEscRAM : Resolucion X01Z,
También pueden introducirse señales resueltas declarando un subtipo de datos

resuelto, es decir, un subtipo al que se le asigna una función de resolución. De este
modo, las señales de este subtipo ya no deberán especificar la función de resolu-
ción. Este segundo método resulta adecuado cuando la misma función debe utilizar-
se para diferentes señales resueltas. La declaración anterior de la señal LectEscRAM
siguiendo este método sería:
subtype X01ZResuelto is Resolucion X01Z;

signal LectEscRAM : X01Z_Resuelto;
Finalmente, el cuerpo de la función de resolución debe decidir qué valor se

asigna a la señal resuelta dependiendo de los valores de todas las fuentes. Por ejem-
plo, para el tipo de datos XOl Z se puede escribir código que asigne Z a la señal
cuando todas las fuentes valgan Z, X cuando dos fuentes tengan valores contradicto-
rios y O o 1 cuando alguna fuente tenga este valor y las demás estén en alta impe-
dancia. El cuerpo de la función de resolución que implementa esta funcionalidad
sería el siguiente:
function Resolu~ (F'1tf3Il;es;.X01Z":vector) return X01Z ia

variable Valor: XOIZ := 'z',;
begin
for Indice in Fuentes'range loop
case Fuentes(Indice) is
when 'O' => if Valor = 'Z' or Valor = '0' then
Valor ~= 'O';
else
Valor := 'X';
exit;
end if;
when '1' => if Valor =
'Z' or Valor = '1' then
Valor .- '1';
else
Valor := 'X' i
exit;
end if;
when 'X' =>
Valor :\= X;
exit
when others => null;
end case;
end loop;
retum Valor;
end Resolucion;
Aunque el uso más común de las señales resueltas se produce en tipos de datos
escalares utilizados para modelar las propiedades eléctricas de conexiones, el con-
cepto de señales resueltas es mucho más amplio y puede aplicarse a otros tipos de
datos más generales, como pueden ser los tipos compuestos, lo único que hace falta
es definir una función de resolución que determine en cada asignación cuál es el va-
lor que debe asignarse a la señal resuelta del tipo compuesto. En particular, se po-
drían utilizar vectores resueltos de señales para modelar buses de varios bits de an-
chura, no obstante esta aproximación conlleva algunos problemas porque obliga a
trabajar con todo el vector a la vez sin permitir el acceso a sólo una parte del vector.
Por esta razón, para el modelado de buses normalmente no se utilizan vectores re-
sueltos de señales sino vectores de señales resueltas, por lo tanto, se resuelve cada
señal del vector independientemente.
Por último, cabe señalar que el paquete std_logic_1164 de IEEE que define los
tipos de datos std_ulogic y std_ulogic_vector también define el tipo std_logic como
subtipo resuelto de std_ulogic y el tipo std_logic_vector como un vector no restrin-
gido de objetos de tipo std_logic. De hecho, la u de std_ulogic significa no resuelto
(unresolved). La definición de estos tipos y subtipos, así como de la función de re-
solución, es la siguiente:
type stCLulogic is ('U', 'X', 'O', '1', 'Z', 'W', 'L', 'H', '-'ji
type stCLulpgic~vector is array (nat:¡p:al range -o- ot std...ulogici
function resolved (s: std_ulogic_vector) retum std_uloiilc;'
subtype std_logic is resolved std_ulogic;
type stCLlogic_vector is array (natural range -o- of std_logici
IEEE recomienda no utilizar los tipos std_ulogic y std_ulogic_vector y usar

siempre std_logic y std_logic_vector, aun cuando las señales tengan una única
fuente. Esta recomendación se hace porque se supone que los simuladores se van a
optimizar para tratar estos tipos de datos. El máximo inconveniente de trabajar
siempre con señales resueltas es que los errores provocados por señales que acci-
dentalmente tienen más de una fuente no se detectan en tiempo de compilación, ha-

.biéndose de detectar en tiempo de simulación cuando una señal tiene un valor des-
conocido en un momento en que no debería tenerlo.
2.8. EJERCICIOS
1. ¿Cuáles de los siguientes identificadores son correctos?

Variable_3
_3Variable
Variable
Variable$3
Este_identificador_es_bastante_largo
3Variable
VARIABLE
vari_able
2. Determine el valor decimal de los siguientes literales numéricos:

-23_11
4.3e2
7i65_21
16#A3#e3
-4.2.:_12E2
2#1110_1001_1000_1010i
16iE9A#e-3.2
3. Defina los siguientes tipos de datos:

a) Un tipo entero que contenga los números comprendidos entre 1 y 31.
b) Un tipo enumerado con los meses del año.
e) El tipo natural.
d) Un tipo registro para almacenar fechas, utilizando los tipos definidos en a),
b) y e) para el día, el mes y el año respectivamente.
e) Un vector de 5 elementos del tipo registro definido en d).
f) El tipo físico peso que incluya el miligramo, el gramo, el kilogramo y la to-
nelada.
g) El tipo enumerado XZOl que incluya los valores de cero y uno lógico, alta
impedancia y valor prohibido.
h) El tipo vector no restringido de elementos del tipo XZ01.
i) El tipo cadena de caracteres (vector no restringido de caracteres).
j) Un tipo matriz tridimensional de dimensión 2 x 3 x 2 que contenga enteros.
4. Para cada uno de los tipos definidos en el ejercicio 3:

a) Declare e inicialice una constante de dicho tipo.
b) Declare una variable de dicho tipo y escriba una sentencia de asignación a

esta variable sin utilizar agregados.
S. Escriba el valor de las siguientes expresiones.

boolean'high
positive'low
natural'l6w
Qit'riqht
boolean'left
character'pos ('c')
boolean'val (l)
character'val(79)
character'pred('e')
character'succ('e')
character ,pred Icharacter , succ ( 'e'))
6. A partir del siguiente tipo de datos:

type Matriz is array (O to 15, 12 downto 3, 2 to 31) of character¡
Escriba el valor de las siguientes expresiones:

Matriz 'left
Matriz ';left en
Matriz'left(2)
Matriz ' d.ght (3f.
Matriz ' low
Matriz'low(2)
Matriz'high(3)
Matriz' range
Matriz'range(2)
Matriz'ascending(3)
Matri:¡¡:'.r~verse_range (2)
Matri"Z'l~\lth(l)·· = Valores'len"qth(2)
Matríz/leÍl~h(3) .
7. Dibuje la cola de eventos de la señal e antes de la ejecución de cada sentencia

wait y muestre la secuencia de valores que toma la señal C.
z <= transport '1' after 10 ns;
wait for 5 ns;
z <= transport 'O' after 7 ns;
wait for 8 ns;
z <= transport '1' after 10 ns;
wait for 2 ns;
z <= transport 'O' after 3 ns;
wait for 1 ns;
8. Dada la declaración del siguiente multiplexor 4-1 de datos de ocho bits:

entity Multiplexor is
port ( Seleccion : in bit_vector(O to 1) ¡
Entrada! in bit_vector (9 to 7);

Entrada2 in bit_vector (O to 7);
Entrada3 in bit_vector (O to 7) r
Entrada4 in bit_vector (O to 7);
Salida out bit_veétor (O to~7r);
end Muitiplexor;
a) Escriba una arquitectura utilizando un proceso con una sentencia case.

b) Escriba una arquitectura utilizando una única asignación a señal concu-
rrente.
9. Dada la declaración del siguiente decrementador:

entity Decrementador 18
port ( Reloj in bit;
Inicializa in bit;
Carga in bit;
Valor in bit vector (7 down,to O) ¡,
Salida out bit_vector(7 dowiito' 'of'),;
end Decrementador;
Cuyas entradas y salidas tienen la siguiente funcionalidad:
Reloj: Reloj que controla la operación del decrementador.
Inicializa: Entrada síncrona que cuando vale 'O' inicializa Salida a "00000000".
Carga: Entrada síncrona que cuando vale 'O' inicializa Salida a Valor.
Valor: Entrada que se carga a Salida cuando Carga vale 'O'.
Salida: A cada pulso de Reloj debe decrementar su valor hasta llegar a
"00000000" .
a) Escriba la arquitectura del decrementador mediante un proceso que se ejecu-
te a cada evento de Reloj.
b) Repita el apartado a) utilizando un proceso que implemente un bucle desde
que Salida vale Valor hasta que vale "00000000". Escriba tres versiones di-
ferentes, usando las sentencias loop, while y Jor respectivamente.
10. Dada la declaración del siguiente sumador completo de un bit:
entity SurnadorCompleto 18
port ( OperadorA: in bit;
OperadorB : in bit;
AcEntrada : in bit;
Resultado : out bit;
AcSalida : out bit);
end SurnadorCompleto;
a) Escriba la arquitectura de dicho sumador utilizando un estilo de descripción

en flujo de datos.
b) Defina la entidad y arquitectura de un sumador de un número genérico de
bits que utilice el sumador anterior de un bit como componente. Para hacer-
lo use la sentencia generate.
11. Escriba una función que reciba como entrada un valor de tipo bit_vector y de-
vuelva dicho valor en el orden inverso. Es decir, si por ejemplo recibe el valor
"00011101" debe devolver "10111000".
12. Repita el ejercicio (11) mediante un procedimiento que reciba un único pará-
metro de tipo inout.
13. Escriba un paquete llamado DistanciaArea donde se definan los tipos físicos
Distancia (micra, milímetro, centímetro, metro y kilómetro) y Area (las mismas
unidades al cuadrado).
a) Dada la siguiente-entidad:
use work.DistanciaArea.all;
entity Multiplicador ls
port ( A : in Distancia;
B : in DiS.taDG-ia;
e : out Area);
end Multiplicador;.
Escriba una arquitectura para dicha entidad en estilo algorítmico donde se

realice la multiplicación de las entradas aplicando las funciones de conver-
sión necesarias para que no se produzca un error de compilación.
b) Añada al paquete DistanciaArea la sobrecarga de los operadores necesarios
para poder realizar las operaciones de suma, resta, multiplicación por entero
y multiplicación por real para los tipos Distancia y Area. Sobrecargue tam-
bién el operador "*" para poder realizar multiplicaciones de dos valores de
tipo Distancia. Una vez modificado el paquete, reescriba la arquitectura del
apartado a) utilizando este paquete.
14. Dados los tipos bit y bit_vector:

type bit ls (' O', '1');
type bit_vector ls array (natural range <» of bit" ..
y de la siguiente señal resuelta de tipo bit:
signal Peticion : ResolucionBit bit;
a) La señal Peticion debe valer '1' cuando alguna de sus fuentes vale '1',
mientras que debe valer 'O' en caso contrario (or lógica). Escriba la función
de resolución ResolucionBit.
b) La señal Peticion debe valer '1' cuando una y sólo una de sus fuentes vale
'1', en caso contrario debe valer 'O'. Escriba la función de resolución Reso-
lucionBit.
e) La señal Peticion debe valer' l' cuando todas sus fuentes valen '1', en caso
contrario debe valer 'O' (and lógica). Escriba la función de resolución Reso-
lucionBit.
15. Considere el siguiente bloque de tres entradas y dos salidas cuya funcionalidad
viene determinada por la tabla de la verdad adjunta:
A bit
B bit
Bloque
y bit
- 1 F 1
e bit
Zbit
. 1 o
1'\-0
o 1
- o o
1 1 1 1
1 1 o
a) Escriba la declaración de entidad de este bloque.

b) Escriba la arquitectura de la entidad utilizando el estilo de descripción es-
tructural. Para hacerlo solamente se puede usar la siguiente entidad como
componente:
entity NAND2 is
port ( a : in bit;
b : in bit;
z : out bit);
end NAND2;
e) Escriba la arquitectura utilizando el estilo de descripción de flujo de datos.

Para hacerlo solamente se pueden usar los operadores lógicos and, or y noto
d) Escriba la arquitectura utilizando el estilo de descripción algorítmico. Hága-
lo usando la sentencia secuencial case.
e) Escriba la arquitectura utilizando el estilo de descripción algorítmico. Hága-
lo usando la sentencia secuencial ij, mediante construcciones del tipo:
if <condición> then
elsif <condición> then
else
end if¡
f) Escriba una configuración que relacione la entidad Bloque con su arquitec-

tura descrita siguiendo el estilo estructural. Suponiendo que existe una ar-
quitectura llamada Funcional para el componente NAND2, indique en la
configuración que debe usarse dicha arquitectura.
g) Suponga que las salidas y y Z son de un tipo llamado XOl que contiene los
valores cero lógico ('O'), uno lógico (' 1') Yvalor prohibido ('X'). Este valor
prohibido debe producirse cuando las entradas A, B Y e tienen el mismo va-
lor. Defina el tipo de datos XOl e inclúyalo en un paquete llamado Paque-
te_XOl. Utilizando el paquete acabado de definir, vuelva a escribir la decla-
ración de entidad y la arquitectura en estilo algorítmico usando la sentencia
case.
2.9. BIBLIOGRAFíA
[A95] P. 1. ASHENDEN:The Designer's Guide to VHDL, Morgan Kaufmann Publishers, Inc.,

1995.
[ABOR90] R. AIRIAU, J. M. BERGÉ, V. OLIVE, J. ROUILLARD:VHDL du langage a la modéli-
sation, Presses Polytechniques et Universitaires Romandes, 1990.
[BFMR92] J. M. BERGÉ, A. FONKOUA,S. MAGINOT, 1. ROUILLARD:VHDL Designer's Refe-
rence, Kluwer Academic Publishers, 199i.
[BFMR93] J .M. BERGÉ, A. FONKOUA,S. MAGINOT, J. ROUILLARD:VHDL '92, Kluwer Aca-
demic Publishers, 1993.
[C89] D. COELHO, The VHDL Handbook, Kluwer Academic Publishers, 1989.
[IEEE88] Institute of Electrical and Electronics Engineers: The IEEE Standard VHDL Lan-
guage Reference Manual, IEEE Std 1076-1987,1988.
[IEEE94] Institute of Electrical and Electronics Engineers: The IEEE Standard VHDL Lan-
guage Reference Manual, ANSI/IEEE Std 1076-1993, 1994.
[LSU89] R. LIPSETT, C. SCHAEFER,C. USSERY: VHDL: Hardware Description and Design,
Kluwer Academic Publishers, 1989.
[ML93] S. MAZOR, P. LANGSTRAAT:A Guide lo VHDL, Kluwer Academic Publishers, 1993.
Capítulo 3
PROCESADO
V MECANISMOS,
DE SIMULACION
DEL LENGUAJE VHDL
Serafín Olcoz (SIDSA)
VHDL, aunque dentro del diseño electrónico, se utiliza para otras ta-
reas, como la síntesis o la verificación, es un lenguaje que nació y se
desarrolló con una semántica explícita para simulación dirigida por
eventos discretos. Tanto es así que en el manual de referencia del len-
guaje (Language Reference Manual, LRM) además de la sintaxis, y jun-
to a la semántica del lenguaje, se detallan los mecanismos básicos del
procesado del lenguaje para la simulación. Por tanto, si bien puede
haber ambigüedades cuando el lenguaje se utiliza para otras tareas, en
simulación éstas no existen y esto es lo que trataremos de dejar claro
en este capítulo, describiendo con detalle el procesado, la semántica y
los mecanismos de simulación de VHDL.
Tras unas nociones básicas sobre la simulación por ordenador que
facilitan la ubicación y comprensión del propio proceso de simulación
de VHDL, se presentan los conceptos fundamentales del procesado de
un lenguaje de programación para poder entender mejor los elemen-
tos y etapas del procesado de VHDL para simulación.
A continuación se abordan los objetivos centrales de este capítulo:
el procesado y el modelado de VHDL para simulación. Tras el procesa-
do de una entidad de diseño VHDL para su simulación dirigida por
eventos discretos donde se detallan las fases de análisis, elaboración y
simulación, se analiza el modelo temporal 8-delay, el determinismo
y la portabilidad de VHDL.
El objetivo no es presentar y analizar técnicas de modelado para si-
mulación, sino estudiar en detalle el procesado y los mecanismos de
simulación que permitan al lector extraer criterios de modelado para
realizar y utilizar de forma eficiente las descripciones de sistemas elec-
trónicos en VHDL.
135
3. 1. INTRODUCCiÓN
VHDL, [1], es un lenguaje de descripción de hardware (Hardware Description

Language, HDL , [2-11]), por ejemplo, un lenguaje de descripción o modelado de
sistemas electrónicos, en particular de sistemas microelectrónicos, que tiene voca-
ción de convertirse en un lenguaje capaz de dar soporte a las diversas etapas que
componen el ciclo de vida de un diseño electrónico. Esta tendencia lleva a extender
su uso más allá del propósito para el que VHDL está definido en el manual de refe-
rencia del lenguaje (Language Reference Manual, LRM), o sea, para describir o
modelar hardware y simular su comportamiento en un ordenador. La extensión de
mayor repercusión es la de la utilización de VHDL como lenguaje de síntesis auto-
mática de hardware.
Dado que VHDL es un lenguaje bastante complejo, suele ser normal que un di-
señador de hardware no utilice adecuadamente toda su capacidad descriptiva. Lo
habitual suele ser que el diseñador adopte unos ciertos hábitos o estilos de descrip-
ción ligados a unos determinados subconjuntos del lenguaje. Esta forma de proce-
der se suele disculpar aludiendo a la enorme capacidad descriptiva que posee
VHDL y que no es necesario aplicar en todos los casos. Sin embargo, lo que se sue-
le esconder detrás de esta excusa es el desconocimiento del procesado y de la se-
mántica del lenguaje VHDL. Situación que se agrava cuando el diseñador utiliza si-
multáneamente el mismo lenguaje, o un determinado subconjunto del mismo, con
dos finalidades o semánticas distintas, por ejemplo, simulación y síntesis. Llegando
a causar equívocos en los posibles usuarios del HDL e incluso hacer que éstos pue-
den llegar a aborrecerlo debido a su pretendida complejidad, cuando en realidad se
trata de mera incompresión. Para evitar esta posible y nefasta consecuencia, en este
capítulo se presenta el lenguaje desde el punto de vista de su procesado y su semán-
tica de simulación dirigida por eventos discretos.
Aunque VHDL, como se describe en los distintos capítulos de este libro, es al-
go más que un lenguaje de simulación dirigida por eventos discretos, su capacidad
para describir y probar el comportamiento de sistemas electrónicos se basa precisa-
mente en su faceta de simulación. Por ello, este capítulo comienza presentando las
nociones básicas de la simulación por ordenador. Nociones que son de gran utilidad
para el diseñador de sistemas electrónicos al permitirle considerar el proceso de di-
seño con VHDL como un caso particular del diseño de un sistema físico por medio
de su modelado y posterior compresión y/o validación por medio de su simulación.
Desde esta perspectiva, la descripción de un sistema electrónico a través de un HDL
con semántica de simulación se puede considerar como la generación de un progra-
ma informático cuya ejecución por un ordenador produce un modelo dinámico que
representa la evolución del sistema físico, ya sea existente (para describir/reflejar) o
proyectado (para sugerir ideales), a través del tiempo.
A continuación se presentan las nociones básicas del procesado de un progra-
ma informático, haciéndose especial énfasis en la compilación software, hardware e
híbrida de un HDL. Este conocimiento es crucial para poder comprender tanto la
generación de modelos software de simulación por ordenador correspondiente a una
descripción HDL, como la generación de modelos para emulación hardware o la
generación de un hardware determinado por medio de la síntesis de dicha descrip-
3. Procesado y mecanismos de simulación del lenguaje VHDL 137
ción HDL. Esta sección también introduce los mecanismos de especificación de un

lenguaje de programación y resalta la estrecha relación existente entre dichos meca-
nismos de especificación y el procesado del lenguaje.
Las dos primeras secciones ofrecen una visión general de todo el conocimiento
que se debe tener previamente a considerar el procesado y la simulación de VHDL.
La tercera sección describe propiamente el objetivo de este capítulo, o sea, la simu-
lación de una entidad VHDL desde el punto de vista del procesado de una entidad
de diseño VHDL y de su simulación dirigida por eventos discretos. Distinguiendo
entre lo que es un simulador VHDL y una simulación VHDL y detallando las fases
de. análisis, elaboración y simulación, sin entrar en cómo se genera el programa eje-
cutable en el ordenador ni en cómo éste se depura (debugging). Aunque si se pre-
sentan las consecuencias que la ejecución y depuración de dicho modelo tiene sobre
el determinismo y la portabilidad de las descripciones VHDL, de modo que el dise-
ñador de VHDL estará en mejores condiciones de realizar y utilizar descripciones
de sistemas electrónicos en VHDL.
A continuación se describe cómo se prepara la tarea de simulación de una enti-
dad de diseño descrita en VHDL (VHDL Design Entity) y en qué se parece y se di-
ferencia del caso de abordar su síntesis (incluyendo implícitamente la manufactura
del dispositivo físico correspondiente) y/o la prueba (test) de dicha entidad. Final-
mente, se hace una referencia a las diferencias existentes entre la simulación lógica,
temporal y de fallos.
3.2. SIMULACIÓN POR ORDENADOR
La simulación es una técnica que consiste en el uso de un modelo para desarrollar

conclusiones acerca del comportamiento de un sistema físico, también denominado
objeto real por contraposición a la posible "virtualidad" del modelo. La simulación
por ordenador (Computer Simulation), como su propio nombre indica, requiere que
el modelo se cree por medio de la programación de un ordenador, [12-13]. Las téc-
nicas de simulación por ordenador ofrecen la posibilidad de emplear un prototipo
virtual, o varios a distintos niveles de abstracción, en lugar de un prototipo real (téc-
nica conocida como breadboarding en el entorno del diseño de sistemas electróni-
cos) con las limitaciones que ello implica.
El uso de un ordenador para, de forma "virtual", reflejar, imitar o simular las
operaciones de un producto o proceso del mundo real requiere el desarrollo de un
modelo en el. que se den un conjunto de supuestos en forma de relaciones lógicas o
matemáticas. La información que ofrece la simulación es la representación del esta-
do del modelo con respecto al tiempo. El flujo de control de un programa de simu-
lación representa la lógica de cambio de estados del sistema con el paso del tiempo.
A diferencia de los programas dedicados a la realización de cálculos científicos, en
los que la estructura de control se puede alterar mientras no se altere el resultado
correcto, para una simulación la lógica de control debe reflejar la realidad y, por
tanto, la corrección no sólo atañe al cálculo sino que también depende de que se lo-
gre dicho reflejo.
La simulación por ordenador puede llegar a ser una técnica de resolución de

problemas complicada y cara, tanto en tiempo de desarrollo del modelo de simula-
ción como en su ejecución o animación. Por tanto, sólo se debe utilizar bajo ciertas
circunstancias, como, por ejemplo, cuando:
1. El sistema real no existe y es demasiado costoso, lleva mucho tiempo, es

peligroso, o simplemente no se puede realizar un prototipo o modelo real y
por ello es mejor realizar un prototipo virtual o modelo programado en un
ordenador.
2. El sistema físico real existe pero su observación y experimentación es cara,
inaccesible, peligrosa o destructiva.
3. Se necesita un modelo que permita predecir el comportamiento en largos
periodos de tiempo de forma compacta.
4. El modelo matemático, también denominado formal, del sistema físico no
tiene solución analítica o numérica que ofrezca resultados prácticos, por lo
que su análisis y/o verificación formal resulta inviable ..
La principal ventaja del uso de la simulación es la reducción del riesgo asocia-

do a la realización de un nuevo sistema, o a su modificación. La simulación por or-
denador permite probar diferentes alternativas y seleccionar la que ofrezca mejores
resultados. Las soluciones propuestas a los problemas descubiertos con la simula-
ción se pueden analizar en menos tiempo que las observaciones realizadas en el
mundo real. Además, la simulación ofrece un mayor y mejor control sobre las con-
diciones experimentales en la que se realizan dichas observaciones. Por otra parte,
..al realizar o programar el modelo se fuerza al diseñador del mismo a que determine
y documente de forma precisa cómo funcionará el sistema en cuestión, labor a la
que habitualmente no se le dedica el esfuerzo y la atención que merece. El propio
proceso de crear las relaciones lógicas, por medio de la programación del modelo,
sirve para sacar a la luz posibles problemas o indeterminaciones relacionadas con la
especificación del sistema.
Sin embargo, debido a que la simulación no es ni un arte ni una ciencia, sino
una mezcla de ambos, también presenta dos desventajas inherentes a su propia natu-
raleza. La primera de ellas se debe a que la simulación es un proceso experimental
que sólo da respuestas aproximadas, ni exactas ni óptimas, que sólo permiten mejo-
rar la confianza en el modelo. En una simulación no se obtiene una solución, mate-
máticamente hablando, sino que se obtiene un mejor conocimiento de las relaciones
entre los componentes del sistema, siempre a partir de un estado inicial determinado.
En la simulación por ordenador se abandona el cálculo predictivo que ofrecería el
uso de una definición completamente rigurosa o formal, por la aplicación de un mé-
todo de prueba y error en el que se pueden observar las distintas estrategias y posibi-
lidades del diseño. Una simulación se puede repetir tantas veces como sea necesario
hasta que se obtenga suficiente confianza en sus predicciones. La detección de erro-
res conduce al rediseño del sistema. Como contrapartida, se suelen requerir menos
suposiciones y abstracciones que en los modelos matemáticos (modelos formales).
La segunda desventaja se debe a que la validación del propio modelo de simu-
lación es la mayor limitación de esta técnica.
3. Procesado y mecanismos de simulación del lenguaje VHOL 139
3.2.1. Descripción del tiempo vIo distintos tipos

de simulación
Para expresar el comportamiento dinámico de los sistemas es necesario poder re-

presentar de alguna forma el tiempo [12-13 ]. El tiempo se podría considerar como
un continuo, pero entonces para poder informatizar su evolución sería necesario el
uso de ordenadores analógicos. El problema que presentan este tipo de ordenadores
es que su precisión es altamente dependiente de las características de los circuitos
electrónicos que los forman. La dificultad de duplicar este tipo de sistemas ha lleva-
do a considerar ordenadores mixtos (analógico-digitales) y finalmente digitales, de-
bido a los avances en electrónica digital y en arquitectura de ordenadores. En la
práctica, esto ha llevado a considerar el tiempo de forma discreta.
Existen dos formas de ejecutar los modelos dinámicos por medio de una repre-
sentación discreta del tiempo, dirigiendo la simulación por el paso del tiempo (time-
driven) o por el acontecimiento de eventos (discrete-event o también denominados
event-driven). En el caso de simuladores dirigidos por tiempo, en cada unidad de
tiempo se evalúan todos los componentes del sistema. Cada componente del siste-
ma se activa en todos los ciclos de simulación, incluso cuando las entradas del com-
ponente no han sufrido modificaciones y, por tanto, el componente no necesita re-
calcular su estado.
3.2.1.1. Simulación dirigida por el paso del tiempo

En un sistema de tiempo discreto el modelo avanza por sucesivas etapas en una se-
rie de saltos que incrementan el tiempo en cantidades fijas, como, por ejemplo, los
ciclos de reloj de un sistema síncrono (simulación también conocida como cycle-
based simulation). Este tipo de avance del tiempo es síncrono, ya que después de
cada salto (tick) o ciclo de reloj el tiempo se incrementa en una constante. El pro-
blema de implementar una simulación con un avance síncrono del tiempo es que no
es posible representar funcionalidad que acontece simultáneamente de forma discri-
minatoria, de modo que se necesitan ciertos mecanismos para poder describir los
estados intermedios por los que pasa un sistema sin que avance el tiempo. La venta-
ja de la simulación basada en ciclos es que, aunque con menor precisión, permite
abordar periodos de simulación mayores en menor tiempo real, ventaja de gran in-
terés cuando, por ejemplo, se presente simular el comportamiento de un sistema
electrónico compuesto de hardware y software.
3.2.1.2. Simulación dirigida por eventos discretos

El paradigma de la simulación dirigida por eventos discretos [14-17] se basa en la
existencia de dos componentes: uno que representa al propio modelo de simulación
en estudio y que además es el generador de los futuros eventos y otro que actualiza
el tiempo y gestiona los eventos para comunicar al modelo los que corresponden al
actual tiempo de simulación. Este segundo componente representa a lo que se suele
denominar kernel o núcleo del simulador.
Kernel de
simulación
Modelo de
simulación
FEs
FIGURA 3-1. Flujo de eventos discretos.
La simulación dirigida por eventos discretos representa un modelo de un siste-

ma dinámico sujeto a una serie de acontecimientos instantáneos, denominados
eventos. En este tipo de simulación, el avance del tiempo es un medio para soslayar
la discontinuidad existente entre el acontecimiento de dos eventos sucesivos, asu-
miendo que durante dicho tiempo no ocurre nada. La discretización del tiempo está
implícita en el sistema, no está explícitamente impuesta por el simulador, como se-
ría el caso en un simulador dirigido por tiempo exclusivamente.
La suposición de que no ocurre nada entre dos eventos, o, de forma más preci-
sa, que el estado de los elementos que componen el modelo permanece constante
entre dichos instantes de tiempo, se satisface por un amplio número de sistemas rea-
les y además se considera el Primer Paradigma de la simulación dirigida por even-
tos discretos. -
En una simulación, los eventos se originan a partir de un conjunto de Futuros
Eventos (FEs) que está bajo control del kernel o núcleo de simulación. Se puede
pensar en un FE como en una cola en la que se insertan pares correspondientes a los
valores de los eventos, junto con los tiempos en los que está previsto que acontezcan
dichos eventos, véase la Figura 3-1. La longitud de las colas y la forma de inserción
de los futuros eventos, depende de cada lenguaje de simulación. Las colas se va ac-
tualizando, de modo que se van eliminando los valores al ser reemplazado el valor
actual por el nuevo. Después de que un evento ha causado su efecto, su FE corres-
pondiente se puede eliminar de la cola de FEs pendientes. El simulador toma los va-
lores actuales de estas colas de acuerdo con el modelo de avance del tiempo. La si-
mulación continúa hasta que se vacía la cola de eventos o hasta que se alcanza una
condición de parada (p. ej., límite de tiempo de simulación, control del simulador).
A menudo, como resultado de la actividad que lleva a cabo el modelo en res-
puesta a un evento, hace que se inserten nuevos FEs en la cola. Esta inserción se
realiza teniendo en cuenta el orden ascendente del tiempo. En algunas ocasiones,
dependiendo del simulador en concreto del que se trate, ciertas FEs se postponen o
incluso se cancelan (modelos de inserción preemptivos = planificación dinámica).
Esencialmente, la planificación de FEs consiste en las siguientes operaciones: la in-
serción de nuevos FEs en las colas de FEs y la extracción de FEs de las colas en un
estricto orden de prioridad con respecto al tiempo. Por tanto, hay dos tareas funda-
mentales asociadas con cada FE: la ocurrencia del tiempo en el que el evento tiene
lugar y las acciones que el modelo debe realizar como consecuencia de la aparición
del evento. La planificación de las operaciones que realiza el modelo se puede con-
siderar como el procesado de los elementos de un conjunto. En dicho conjunto cada
elemento tiene asociado el tiempo en el que cierto evento va a acontecer, de modo
que de acuerdo con esta información el kernel puede llevar a cabo la planificación
de las operaciones del modelo.
La propia naturaleza de la gestión de las colas de eventos limita el potencial
paralelismo de la simulación dirigida por eventos. Se han sugerido algunas técnicas
para la gestión de las colas de eventos y para la simulación en paralelo, aunque el
paralelismo alcanzable es limitado. También existen aceleradores hardware de altas
prestaciones que mantienen múltiples colas de eventos, cada una manejada por sis-
temas independientes aunque con un sistema centralizado (sincronizado) de avance
del tiempo. El paralelismo se puede mejorar si se elimina la necesidad de un tiempo
y unas colas de eventos globales, dando lugar a sistemas distribuidos. Este tipo de
sistemas es muy difícil de controlar adecuadamente, ya que se pueden bloquear
(deadlock). Para solventar estos problemas hay dos soluciones: evitar los bloqueos
o detectarlos y recuperarse de ellos.
Las estructuras de datos que soportan a las colas de FEs deben incluir una refe-
rencia a las acciones que se deben llevar a cabo. La forma de dicha referencia po-
dría ser una dirección, una etiqueta o un índice correspondiente a un vector de su-
brutinas, a menudo dependerá de la estrategia de simulación que se esté empleando.
La elección de esta estrategia afecta a la implementación y al uso del lenguaje de si-
mulación, o sea, a la realización de las herramientas de simulación y al lenguaje con
el que éstas se programan.
3.2.1.2.1. Estrategias de simulación
En la simulación dirigida por eventos discretos sólo hay tres posibles estrategias: la
planificación de eventos, la búsqueda de actividad y finalmente, la basada en la in-
teracción de procesos. La estrategia basada en la interacción de procesos se puede
considerar una combinación de las otras dos, en la que se gana en eficacia de ejecu-
ción y además se obtienen descripciones más concisas.
La estrategia basada en la planificación de eventos (Event Schedulling) es la
más sencilla de todas. El comportamiento del modelo de simulación depende de la
aparición de eventos durante la ejecución dinámica de la simulación. Cuando apare-
ce un evento ocurren dos cosas: (1) se procesa el evento realizándose las operacio-
nes que para tal evento están previstas; (2) se planifican los tiempos en los que po-
drán ocurrir los futuros eventos. De este modo es como se simula el comportamien-
to dinámico del modelo. El inconveniente que presenta esta estrategia es la
dificultad de activación de las operaciones que se deben realizar en el modelo como
consecuencia de la aparición de los eventos. Las decisiones de activación se dejan
en manos del usuario del simulador, quien tiene que hacerse cargo de la actividad
del modelo entre el acontecimiento de dos eventos.
El problema que presenta esta estrategia se soluciona con una estrategia suple-
mentaria basada en la búsqueda de actividad (Activity Scanning). En este caso, co-
mo su nombre indica, la estrategia se basa en la búsqueda de actividad, que se pue-

de definir como el estado ocupado del modelo entre la ocurrencia de dos eventos: el
que provoca la actividad y el que la cesa. La planificación de las operaciones que
debe realizar el modelo como consecuencia de la aparición de un evento la realiza
el propio modelo de forma complementaria. La búsqueda de actividad mejora la
efectividad de la estrategia basada en la simple planificación de eventos, pero puede
llegar a producir resultados poco eficientes.
Por último, la estrategia basada en la interacción de procesos soluciona los pro-
blemas de activación que presenta la estrategia de planificación de eventos al des-
cribir el modelo como una secuencia de actividades. En este caso las actividades se
corresponden con procesos, secuenciales y cíclicos, que interactúan unos con otros
de acuerdo con la aparición de eventos. El gran problema de esta estrategia es la po-
sibilidad de que aparezcan deadlocks en la interacción entre los procesos. Emplean-
do las estrategias basadas en la planificación de eventos y en la búsqueda de activi-
dad, el problema de bloqueo no aparece debido a la naturaleza secuencial de dichas
estrategias y a la suposición de que en dichas estrategias el ac-ceso a los recursos
nunca es compartido por varias partes del modelo.
3.2.1.3. Modelos de avance del tiempo

Hay dos modelos básicos de avanzar el tiempo en una simulación de sistemas elec-
trónicos de tiempo discreto: el modelo basado en la unidad de retraso (Unit-delay) y
el basado en la ausencia absoluta de retraso (Zero-delay). Estos modelos se superpo-
nen a la gestión de eventos en el caso de la simulación dirigida por eventos discretos.
3.2. 1.3. 1. Modelo Unit-delay

El modelo Unit-delay es la base de los simuladores clásicos de sistemas electróni-
cos descritos como transferencias entre registros tRegister Transfer Level, RTL).
Los modelos RTL describen las transformaciones síncronas de los datos entre dos
conjuntos de registros. El tiempo se define con una granularidad no inferior al ciclo
de reloj, de ahí el nombre del modelo (el ciclo de simulación coincide con la unidad
básica de ciclo de reloj). El valor absoluto, cuantitativo, del tiempo sólo es necesa-
rio en la definición de relojes externos. Este modelo de simulación se caracteriza
por evaluar todas las expresiones de las sentencias de asignación antes de efectuar
ninguna de las asignaciones. Este método elimina cualquier posible ambigüedad
que pudiera acarrear el orden en que se realiza la evaluación de las expresiones. Es-
ta es la característica más relevante del modelo.
El diagrama de flujo de la Figura 3-2 muestra la presencia de dos tareas conse-
cutivas para la evaluación y la asignación de las expresiones.
El bucle representa el avance del tiempo de simulación, que normalmente coin-
cide con el siguiente flanco de reloj o cambio de estado del sistema. No hay posibi-
lidad de comunicar datos entre los componentes en tiempo cero, la comunicación
más rápida se produce como mínimo en una unidad de tiempo. Esto no es ningún
problema cuando se modela lógica secuencial pura, pero sí lo es cuando el sistema
tiene partes combinacionales. El modelo de simulación basado en Unit-delay no
siempre es la mejor elección.
Evalúa y actualiza inmediatamente.

Añade nuevos eventos a la cola de eventos.
Añade nuevos eventos a la cola de eventos.
FIGURA 3-2. Modelos de simulación Unii-delayy Zero-delay.
3.2.1.3.2. Modelo Zero-delay

La mayoría de los simuladores dirigidos por eventos emplean una cola de eventos
gestionada en tiempo cero, Zero-delay, La Figura 3-2 muestra su diagrama de flujo.
La principal diferencia entre este diagrama de flujo y el correspondiente al modelo
Unit-delay es que aquí la evaluación y la actualización de las expresiones se reali-
zan en un solo paso. La característica de este modelo es la comunicación en tiempo
cero, que no siempre garantiza el orden (causalidad) en el que se ejecutan los even-
tos.
Las sentencias que siguen a las de asignación usan los valores recién asigna-
dos, ya que los anteriores se pierden. Si no se define explícitamente entonces no es
posible predecir si una expresión, que lee un registro, empleará el valor antiguo o el
nuevo. Este tipo de problemas debidos al orden de ejecución se denominan "carre-
ras" y son un problema añadido a la dificultad del propio modelado del sistema. El
modelo de simulación basado en Zero-delay no siempre es la mejor elección.
3.2.2. Estructura general de la simulación
El proceso de simulación se desarrolla en las tres etapas mostradas en la Figura 3-3:

(a) inicialización, (b) ejecución y (e) terminación.
1. La inicialización. El modelo se instala en el ordenador, esto significa que

el modelo descrito por el diseñador se elabora para producir un formato co-
dificado en un lenguaje de programación de un ordenador digital. La etapa
de inicialización concluye con la inserción de los valores que representan
las condiciones del estado inicial de la simulación.
Inicialización Ejecución Terminación
FIGURA 3-3. Etapas del proceso de simulación.
2. La ejecución. El modelo de simulación se pone en movimiento, esto es, se

le permite mostrar su comportamiento dinámico bajo la acción del mecanis-
mo de avance del tiempo de simulación. Una simulación se puede progra-
mar para llevarse a cabo durante un determinado periodo de tiempo de si-
mulación, o se puede hacer que finalice al satisfacerse ciertas condiciones
dadas previamente al comienzo de la etapa de ejecución o animación.
3. La terminación. Cuando finaliza, de forma normal o anormal, la ejecución
del programa que representa al modelo de simulación, es cuando se puede
proceder a realizar un análisis "post-mortem" de todo lo acontecido. Este
análisis se puede realizar de forma pre-programada, siguiendo un procedi-
miento establecido de antemano tan complejo como se desee, o puede con-
sistir simplemente en el puro examen de los resultados obtenidos. También
se puede realizar el análisis de los resultados de forma interactiva durante la
propia etapa de ejecución, parando la simulación cada vez que se desea lle-
var a cabo dicho análisis.
3.2.3. Aproximación metódica a la simulación
La estructura general de la simulación, descrita anteriormente, se ha realizado desde

el punto de vista de la ejecución del modelo en un ordenador pero sin decir nada
acerca del proceso de modelado (modeling), ni de las pruebas (testing) iterativas
que conllevan a la corrección/depuración (debugging) del modelo hasta que el dise-
ñador está satisfecho con sus resultados. La Figura 3-4 muestra el diagrama de flujo
de los pasos necesarios para realizar una aproximación metódica a la simulación.
3.2.3.1. Modelado
Una vez especificado el modelo del sistema que se desea analizar, es necesario des-
cribirlo de forma que un ordenador lo pueda procesar. Ambas etapas, especificación
y descripción, conforman el paso denominado modelado. El modelo ejecutable por
el ordenador es el punto de partida para poder ejercitar las pruebas que se desean
realizar a dicho modelo.
FIGURA 3-4. Diagrama de flujo de simulación.
3.2.3.2. Prueba
El siguiente paso consiste en probar el comportamiento del modelo bajo ciertas cir-
cunstancias, que forman parte de un plan de pruebas, de modo que se pueda com-
probar que se comporta tal y como se esperaba. El diseñador selecciona una serie
de casos de prueba de forma que su simulación le ofrezca cierta confianza sobre la
verificación del diseño. La precisión de los resultados de simulación y, por tanto, la
cantidad de información obtenida acerca del comportamiento del sistema, varían
dependiendo de la complejidad y el grado de detalle o abstracción de los modelos.
Una ayuda a la simulación es la inclusión de aserciones en la descripción del mode-
lo, que se deben verificar en tiempo de simulación. .
En otras palabras, se trata de ver si la realización del modelo se corresponde
con la idea que se tiene de las especificaciones del sistema en cuestión. En cierto
modo, en este paso se está depurando el modelo a través de un proceso de verifica-
ción. El grado de confianza que el diseñador deposita en los casos de prueba está
directamente relacionado con la calidad del método de diseño o modelado. Todavía
no importa si el modelo representa adecuadamente o no al sistema en cuestión. Por
ahora es suficiente con asegurarse de que la ejecución del modelo en el ordenador
ofrece los resultados esperados, según se describieron en el plan de pruebas.
El modelo debe reflejar el comportamiento del sistema, para lo cual el diseña-
dor establece un compromiso entre su precisión y su capacidad para la posterior
evaluación de las respuestas. La verificación del modelo de simulación recae en la
generación de los estímulos adecuados. El problema de este método de verificación
reside en la imposibilidad práctica de llevar a cabo una simulación exhaustiva, de-
bido a la explosión de casos, de forma que garantice la corrección del diseño.
Una vez realizada la verificación, la simulación del modelo está funcionando a

entera satisfacción del diseñador, quien considera que el modelo representa al siste-
ma descrito en las especificaciones. Sin embargo, esto último no tiene por qué ser
cierto en todos los casos. De hecho, en la mayoría de las ocasiones es necesario rea-
lizar una serie de pruebas para determinar cómo de cercano está el modelo de las
especificaciones del sistema en cuestión. Estas pruebas corresponden al proceso de
validación del modelo, que es una de las partes más difíciles de llevar a cabo.
3.2.3.3. Explotación
Supongamos, de forma optimista, que el diseñador ha conseguido un modelo de si-
mulación ejecutable en el ordenador y que ha validado el modelo demostrando que
su operación es una representación correcta del sistema en cuestión. Finalmente,
antes de llevar a cabo la realización física del modelo, el diseñador debe experimen-
tar o 'jugar" con el modelo de simulación para incrementar su confianza en que el
sistema en cuestión respondería de forma similar a dichos experimentos. Aunque se
haya alcanzado la perfección en el desarrollo y las pruebas de verificación y valida-
ción del modelo de simulación, no se puede estar seguro del todo acerca de los re-
sultados de experimentar fuera de los límites del conocimiento del sistema en cues-
tión. El diseñador debe ser cauto a la hora de confiar en los resultados de la simula-
ción a la hora de experimentar fuera de dichos límites.
3.3. PROCESADO DE UN LENGUAJE DE PROGRAMACiÓN
Un lenguaje de programación es una notación formal que se utiliza para poder ex-
presar algoritmos [18]. Por tanto, un programa es la descripción en un determinado
lenguaje de programación de un algoritmo. Pero no hay que olvidar que los algorit-
mos son conceptos abstractos, que existen independientemente de cualquier posible
notación en la que éstos se pudieran expresar. Sin embargo, sin la utilización de una
notación es imposible expresar de forma precisa o comunicar un algoritmo, o razo-
nar acerca de su corrección.
3.3.1. Procesadores de lenguajes
Un procesador de un lenguaje de programación [19], como su propio nombre indi-

ca, es cualquier sistema o herramienta que procesa, transforma o manipula progra-
mas (conjuntos de sentencias o instrucciones) descritos o expresados en un determi-
nado lenguaje de programación. El procesado de un lenguaje se puede llevar a cabo
por medio de un solo procesador o combinando varios procesadores.
Hay dos tipos de procesadores particularmente interesantes: los traductores y
los intérpretes. Un traductor (Translator) es un determinado tipo de procesador que
acepta como entrada o fuente cualquier texto descrito o expresado en un lenguaje de
programación determinado, denominado lenguaje fuente (Source Language), y que
genera como salida un texto semánticamente equivalente expresado en otro lengua-
je de programación, denominado destino (Target Language}, Un intérprete (lnter-

preter) es otro tipo de procesador que lleva a cabo o ejecuta las acciones correspon-
dientes al algoritmo descrito por medio del programa que está siendo procesado.
Para ello, el programa debe estar descrito en un código o lenguaje directamente eje-
cutable por el intérprete. Dado que inicialmente el intérprete era una máquina im-
plementada con tecnología electrónica hardware, al lenguaje fuente del procesador
se le denominó lenguaje o código de la máquina (Machine Code).
Para que el código máquina no sea el único código interpretable es necesario
combinar ambos tipos de procesadores. De esta forma se puede conseguir que un
lenguaje distinto al código máquina también puede ser interpretado por dicha má-
quina. Los primeros lenguajes de programación distintos al código máquina, deno-
minados lenguajes ensambladores (Assembly Languages), se basaban en la utiliza-
ción de nombres simbólicos para las operaciones y los datos. Ambos tipos de len-
guajes, los de las máquinas y los ensambladores, pertenecen a la categoría de
lenguajes de programación de bajo nivel (Low Level Programming Languages), de-
nominados así por forzar a expresar los algoritmos que se desean procesar en térmi-
nos cercanos a las instrucciones que puede ejecutar directamente la electrónica sub-
yacente al procesador. En contraposición a estos lenguajes de programación de bajo
nivel, actualmente se utilizan los lenguajes de programación de alto nivel (High Le-
vel Programming Languages, HLLs) que permiten la expresión de los algoritmos a
un nivel de abstracción más cercano al lenguaje interpretable por el ser humano que
por el procesador electrónico hardware. Los HDLs son un caso particular de HLLs,
cuyo propósito es la descripción virtual (software) o física (hardware) de un sistema
electrónico. El procesado por ordenador de una descripción HDL es parte de las
ayudas o herramientas que permiten la automatización del diseño de sistemas elec-
trónicos (Electronic Systems Design Automation, ESDA) antiguamente también co-
nocidas como CAD/CAE (Computer Aided DesignlComputer Aided Engineering).
Hasta ahora nada se ha dicho de la tecnología en la que el procesador de un
lenguaje puede estar implementado. Aunque desde una perspectiva histórica se po-
drían tener en cuenta implementaciones mecánicas e incluso electromecánicas, des-
de que se inventó el transistor sólo se consideran procesadores electrónicos hardwa-
re y/o software. Atendiendo a la implementación del procesador, se puede conside-
rar que el sistema electrónico hardware 1 en el que se lleva a cabo la ejecución de un
programa en código máquina es un procesador hardware (Hardware Processor o
Computer Architecture). Por otra parte, un programa también puede ser procesado
por medio de otro programa (Software), que a su vez se está ejecutando en un pro-
cesador hardware, siendo en este caso el procesador del programa un procesador
electrónico software (Software Processor). Por tanto, todo procesador software lle-
va implícitamente asociado un procesador hardware, véase la Figura 3-5.
1 Un ordenador o computadora es un caso de procesador implementado por medio de un sistema

electrónico hardware, este tipo de procesadores se denominan microprocesadores (IlProcesador) cuan-
do se implementan con tecnología microelectrónica.
Programa
Programa
1-
Programa
1- Procesador
Hardware
Procesador
Software Procesador
Hardware
FIGURA 3-5. Procesadores electrónicos Hardware y Software.
3.3.2. Compiladores Software, Hardware e híbridos
Cuando el traductor de un lenguaje cambia el nivel de abstracción entre sus lengua-

jes fuente y destino, entonces el procesador se denomina compilador (Compiler)
[20-23]. Como se presentó en la sección anterior, para ejecutar un programa descri-
to en un lenguaje de mayor nivel que el del intérprete que lo procesa es necesario
traducir el programa al lenguaje del intérprete previamente a su ejecución, lo que
equivale a realizar dos procesos sobre dicho programa: compilación y ejecución.
Hasta ahora sólo se ha considerado la posibilidad de que el resultado de la
compilación puede ser código ejecutable posteriormente por un intérprete o proce-
sador (hardware o software) del lenguaje destino cuya existencia era previa a la
compilación del programa. En particular, cuando el programa está escrito en un
HDL para su simulación por ordenador es necesario procesar la descripción HDL
por medio de un compilador software de dicho HDL. De este modo se puede gene-
rar el programa correspondiente al modelo de simulación que se ejecutará finalmen-
te en el ordenador.
Sin embargo, el resultado de la compilación de un programa (HDL) también
puede corresponder con una descripción de un procesador hardware específico, cu-
ya implementación es capaz de realizar el algoritmo expresado en el lenguaje fuente
que se estaba compilando. A este tipo de compiladores se les denomina compilado-
res o sintetizadores de hardware en contraposición al otro tipo de compiladores que,
siendo más precisos, se les debería llamar compiladores de software, véase la Figu-
ra 3-6.
Dependiendo de la semántica de la descripción HDL, o lo que es lo mismo, del
propósito para el que se ha realizado dicha descripción, su procesado dará lugar a
un modelo software de simulación o a la síntesis del hardware esperado. También
cabe una posibilidad híbrida entre las compilaciones hardware y software, la resul-
tante de la emulación hardware de una descripción HDL. La emulación es una téc-
nica experimental similar a la simulación por ordenador en la que el modelo no es
Programa Programa Intérprete
1-O -1=C Compilador Plataforma

ftw
'"
Software Hardware
Programa
-
Compilador
Plataforma
Hardware
Hardware
FIGURA 3-6. Compiladores Software y Hardware ..
software sino hardware. En este caso la compilación hardware de la descripción

HDL se lleva a cabo programando un hardware provisional cuyo comportamiento
emula al del sistema electrónico que se desea realizar. No hay que confundir la im-
plementación hardware provisional con la que se genera el modelo de emulación
con la generación de un prototipo hardware del sistema que resultaría de una com-
pilación o síntesis hardware pura. Dicho hardware provisional se puede considerar
que está más cercano a un modelo hardware de simulación por ordenador, si se ex-
tendiese la definición de esta técnica para tratar indistintamente con modelos soft-
ware o hardware. Evidentemente, esta extensión de la definición de la simulación
por ordenador sólo es aplicable al dominio de los sistemas electrónicos, ya que para
otros sistemas físicos carece de sentido.
Hasta ahora se ha considerado la utilización de un programa bien para ser eje-
cutado en un ordenador, que lleva implícito un procesador hardware de propósito
general o de propósito específico (caso de los denominados aceleradores de hard-
ware), o bien para generar un hardware específico, provisional o definitivo. Sin em-
bargo, como parte de los nuevos métodos de diseño que están apareciendo para po-
der tratar adecuadamente los sistemas electrónicos empotrados (Embedded Systems)
[24-26], se espera que aparezcan nuevos lenguajes, denominados de especificación
de sistemas electrónicos (hardware y software), que darán lugar a un nuevo tipo de
compiladores: el cosintetizador o compilador concurrente de hardware y de softwa-
re [27-29]. La compilación de este tipo de lenguajes dará lugar a la implementación
del sistema electrónico por medio de la realización de un hardware determinado,
que incluirá un procesador hardware que a su vez tratará la parte del sistema elec-
trónico que como resultado de la cosíntesis se implementará por medio de un soft-
ware determinado.
Este nuevo tipo de compilador o co-sintetizador se puede considerar como per-
teneciente a la misma familia de compiladores híbridos a la que pertenecen los
1 50 VHDL. Lenguaje estándar de Diseño Electrónico
emuladores hardware. Salvando las distancias y considerando dos grandes diferen-

cias: que la descripción que se compila no toda ella se desea implementar en hard-
ware y que la parte hardware que se compila es su implementación definitiva y no
un modelo hardware para experimentación.
3.3.3. Especificación de un lenguaje de programación
Un lenguaje de programación se puede especificar informalmente por medio del

uso de un lenguaje natural como el español o el inglés, corriendo el riesgo de que
dicha especificación pueda dar lugar a malinterpretaciones debido a la presencia de
ambigüedades, inconsistencias o carencia de completitud, o se puede hacer formal-
mente por medio de una notación precisa que permita eliminar las ambigüedades y
ofrecer una especificación completa y consistente que no induzca a malinterpreta-
ciones por parte de sus usuarios. En ambos casos hay tres aspectos del lenguaje [30]
que se deben especificar:
1. La sintaxis (Syntax) del lenguaje.

2. Las restricciones sintácticas impuestas por el contexto (Con textual Cons-
traints), también denominadas semántica estática.
3. La semántica dinámica o simplemente semántica (Semantics).
3.3.3.1. Sintaxis
La sintaxis (Syntax) del lenguaje define los símbolos (tokens) que se usan en los
programas para construir las frases, o sea, los comandos o instrucciones, las expre-
siones, las declaraciones o todo un programa completo. En otras palabras, la sinta-
xis hace referencia a la forma de los programas.
La sintaxis de un lenguaje se puede especificar por medio de una gramática in-
dependiente del contexto (Context-Free Grammar, C-FG). Una gramática C-FG se
define matemáticamente como una 4-tupla (X, N, S, P) , compuesta de los siguien-
tes elementos: (1) X, El alfabeto de símbolos terminales con los que se forman las
cadenas (Strings) que forman los tokens; (2) N, el conjunto de símbolos no termina-
les, donde cada uno de ellos designa una clase particular de frases del lenguaje y
entre los cuales se encuentra uno de particular relevancia denominado; (3) S (Start
Symbolo Goal Symbol), que representa a todas las posibles cadenas o frases del
lenguaje. El conjunto de símbolos terminales y no terminales forma el vocabulario
de la gramática; (4) P, el conjunto de reglas de producción de cadenas del lenguaje
que definen cómo se componen las frases a partir de los símbolos terminales y de
las frases.
A su vez, las gramáticas C-FG se suelen especificar mediante dos formas: (a)
Notación BNF (Backus-Naur Form) o su variante EBNF (notación BNF extendida
con notación específica de expresiones regulares [Regular Expressions] Extended
BNF) introducida por Niklaus Wirth; (b) Diagramas Sintácticos (Syntax Diagrams),
donde las reglas de producción se describen por medio de grafos dirigidos.
Expresión
I
Expresión primaria ExpreSión primaria I

Expresión primaria
I
Nombre de Variable Nombre de Variable
I l I
"j"!j' ¡ti i!j i!j "~ri~

FIGURA 3-7. sr de la expresión "d + 10 * n:".
Cada C-FG genera un lenguaje, que no es otra cosa que un conjunto de cadenas
de símbolos terminales. De este modo, un lenguaje se puede definir como el con-
junto de sentencias compuestas de frases cuya estructura se puede representar por
medio de árboles sintácticos (Syntax Trees, STs). Un ST de una C-FG es un árbol
ordenado donde los nodos terminales están etiquetados por símbolos terminales y
los nodos no terminales lo están por símbolos no terminales a los que están asocia-
das cada una de las reglas de producción. Así, una frase de la gramática C-FG es
una cadena de símbolos terminales que etiqueta a los nodos terminales del ST, to-
mados de izquierda a derecha. Una sentencia de la gramática C-FG es una frase
donde el nodo raíz del ST correspondiente es el símbolo S (Start Symbol).
Debido a su precisa descripción de los detalles sintácticos, la gramática C-FG
descrita anteriormente se dice que se refiere a la sintaxis concreta (Concrete Syntax)
del lenguaje, que es de especial interés para el usuario final del lenguaje, ya que tie-
ne que conocer concretamente cómo se deben escribir programas sintácticamente
correctos.
Sin embargo, no siempre es necesario centrarse en la expresión concreta de un
lenguaje sino que basta con centrarse en el conocimiento de la estructura de sus fra-
ses. En estos casos la gramática CF-G se refiere a la sintaxis abstracta del lenguaje
(Abstraet Syntax) y los árboles sintácticos que se generan se denominan ASTs (Abs-
traet Syntax Trees). En los ASTs cada nodo no terminal se etiqueta con una regla de
producción y le corresponde un único subárbol por cada subfrase, ya que los símbo-
los terminales no juegan un verdadero papel en la sintaxis abstracta. Las sintaxis
abstracta sólo se preocupan de las relaciones jerárquicas existentes entre las frases y
las subfrases. Las sintaxis concretas además se ocupan de los símbolos utilizados
para separar y anidar las frases del lenguaje.
Expresión-Operador-Expresión IEOE)
v v
I I
~ ¿]clJ Ó~
FIGURA 3-8. AST de la expresión "d + 10 * n:",
3.3.3.2. Restricciones de contexto

Las gramáticas C-FG deben su nombre a que se puede determinar la corrección de
las frases que componen dichos lenguajes independientemente del contexto en el
que éstas se encuentren. Sin embargo, en la mayoría de los lenguajes de programa-
ción esto no suele ser así y por ello es necesario considerar otro tipo de gramáticas,
las denominadas sensibles al contexto (Context-Sensitive Grammars, C-SG). Las
restricciones sintácticas impuestas por el contexto (Con textual Constraints), tam-
bién se suelen denominar semántica estática del lenguaje, vienen dadas por las re-
glas de ámbito (Scope rules), que permiten determinar el ámbito de cada declara-
ción para así permitir localizar la declaración de cada una de los identificadores, y
las reglas de los tipos (Type rules), que permiten inferir el tipo de cada expresión
para así asegurar que las operaciones se realizan con los operandos adecuados.
En la práctica las gramáticas C-SG se especifican por medio de gramáticas con
atributos (Attribute Grammar). Este tipo de gramáticas se especifican por medio de
la tripleta (G, V, F), donde G es la 4-tupla correspondiente a la gramática C-FG, V
es el conjunto de atributos que se añaden a los nodos del AST generado por la gra-
mática C-FG para recoger las reglas de ámbito y de tipos y, finalmente, F es el con-
junto de aserciones o predicados que restringen los posibles valores de dichos atri-
butos. Por medio de la adición de V y F a la gramática C-FG se consiguen añadir
las restricciones contextuales que permiten discernir qué frases son correctas para la
gramática C-SG de entre todas aquellas que se podrían generar a partir de la gramá-
tica C-FG.
3.3.3.3. Semántica
La semántica dinámica, o simplemente semántica (Semantics), define el significado

de los programas por medio del comportamiento que dichos programas muestran al
ser procesados. La semántica de los programas cuyo procesado tiene como finali-
dad última su ejecución se suelen especificar por medio de los pasos u operaciones
por medio de las cuales se lleva a cabo su ejecución. Este tipo de especificación se
denomina semántica operacional (Operational Semantics). Una forma de especifi-
cación alternativa es la semántica denotacional (Denotational Semantics), que con-
siste en considerar a un programa como si fuese una función matemática que trans-
formase las entradas en las salidas, centrándose más en qué hace el programa que
en cómo se lleva a cabo.
3.3.4. Proceso de compilación de un lenguaje

de programación
Todo compilador de un lenguaje de programación consta de dos etapas. La primera
de ellas, o fachada (front-end) del compilador, se denomina análisis y se compone
de tres procesadores esenciales: el reconocedor o analizador léxico (scanner), el re-
conocedor o analizador sintáctico (parser) y el analizador de la semántica estática
o también denominado.analizador de la sintaxis restringida por el contexto (contex-
tual constrainer o static semantics analyser).
El trabajo de la etapa de análisis consiste en comprobar si un programa fuente
es correcto de acuerdo a las reglas gramaticales del lenguaje fuente. El scanner
transforma las cadenas de caracteres que componen el texto fuente de un programa
en los tokens correspondientes. Una vez transformado el programa fuente en una
cadena de tokens, el parser se encarga de tratar cada uno de ellos como un símbolo
terminal del lenguaje y suele acabar generando una estructura de datos que repre-
senta la estructura del lenguaje normalmente en forma de AST. La generación ex-
plícita del AST únicamente es necesaria en aquellos compiladores que realizan su
proceso en varias fases, entendiendo por fase cada recorrido completo de la unidad
de compilación del programa o código fuente.
La segunda parte o etapa posterior (back-end) de todo compilador se denomina
síntesis y se dedica a la generación y optimización del software que se genera, pu-
diendo también generar hardware en el caso de estar compilando una descripción
HDL.
Entre cada dos fases de una compilación se genera y se comunica una estructu-
ra de datos de tipo AST, denominada representación o formato intermedio (Inter-
mediate Format, IF), que contiene toda la información que el compilador es capaz
de recoger o inferir durante la fase que la produce. El IF se puede almacenar para
permitir que el procesador correspondiente a la siguiente fase realice su tarea de
forma incremental. Además, la definición de los IFs facilita el mantenimiento y el
desarrollo continuado de los compiladores de los lenguajes de programación y, por
tanto, facilita la propia evolución de ·la definición de los lenguajes (especialmente
aquellos que son standards y que se revisan periódicamente, como es el caso de
VHDL), al ofrecer un alto grado de independencia entre las distintas fases de su

procesado y, por tanto, permitir el aislamiento de los posibles cambios del lenguaje
en cada una de dichas fases.
3.4. SIMULACiÓN DE UNA ENTIDAD DE DISEÑO VHDL
La simulación de una entidad de diseño VHDL consiste en la ejecución monitoriza-

da por medio de un ordenador de su modelo de simulación. Dicho modelo, consis-
tente en una red de procesos VHDL interconectados entre sí, se obtiene como resul-
tado del proceso de elaboración de la jerarquía de diseño con la que se ha descrito
la entidad de diseño que se desea simular [31-33]. El flujo de control de la ejecu-
ción del modelo de simulación es capaz de representar el tiempo y con su evolución
es capaz de representar el comportamiento dinámico del sistema descrito o modela-
do en VHDL. Este comportamiento está asociado con todas y cada una de las es-
tructuras VHDL que componen cada uno de los niveles que forman la jerarquía de
diseño.
La simulación de una entidad de diseño VHDL la realiza un simulador, o mejor
dicho, un entorno de simulación. Dicho entorno se encarga de dos tareas: (1) gene-
rar el modelo de simulación correspondiente a una determinada entidad de diseño
VHDL, (2) suministrar al diseñador de VHDL los resultados de la monitorización
de la ejecución de dicho modelo, interpretando dichos resultados en términos rela-
cionados con el código fuente correspondiente a la descripción VHDL que maneja
el diseñador. Así, un simulador VHDL se puede ver como la composición de:
1. Un procesador de la descripción VHDL encargado de analizar las unidades

de diseño VHDL que describen la entidad de diseño VHDL y de elaborar la
jerarquía de diseño para dar lugar a la red de procesos VHDL que se desea
simular.
2. Un compilador del modelo de simulación VHDL encargado de generar, a
partir de dicha red de procesos VHDL, un programa ejecutable en el orde-
nador.
3. Un depurador (debugger) del programa ejecutable capaz de interpretar los
resultados de la ejecución del programa correspondiente a la red de proce-
sos en términos de la descripción VHDL correspondiente a la entidad de di-
seño en estudio.
Tanto el compilador del modelo de simulación como su depurador se pueden

considerar como dos casos particulares de los compiladores y depuradores de cual-
quier programa descrito en un HLL, respectivamente. Por lo que no merecen espe-
cial atención para poder comprender la tarea de simulación VHDL. Sin embargo,
dado que el procesador de VHDL tiene que hacerse cargo tanto de la sintaxis como
de la semántica estática y dinámica de VHDL, a continuación se va a entrar a des-
cribir en mayor detalle cada una de las fases que componen dicho procesado.
3.4.1. Procesado de una descripción VHDL
El LRM del lenguaje VHDL define, de un modo informal en inglés, la sintaxis y la

semántica operativa del lenguaje, o sea, los pasos a seguir para que una descripción
VHDL se pueda procesar en un ordenador con el propósito de simular su comporta-
miento. De acuerdo con el LRM, como se puede apreciar en la Figura 3-9, antes de
poder simular una descripción VHDL en un ordenador, ésta se debe procesar por
medio de las fases que se describen en los siguientes apartados.
Entre cada una de las fases del procesado de VHDL se genera un AST (Abs-
traet Syntax Tree) [34], véase la Figura 3-10. De esta forma, cada fase se puede ver
como un procesador que transforma el AST de entrada en el correspondiente AST
de salida. El primer AST (VHDL Abstraet Syntax Tree, VAST) resulta del análisis
léxico y sintáctico (Lexieal y Syntax Analysis) de una determinada unidad de diseño
(Design Unit). Cabe resaltar que la descripción BNF de la gramática de VHDL, que
se presenta en el LRM como un anexo, no forma parte de la definición de la norma
(Standard). Esto es una muestra más, añadida a la ambigüedad que puede ofrecer la
descripción en lenguaje natural, de la informalidad que ofrece la actual definición
del standard, por ejemplo, el LRM.
El segundo AST resulta de aplicar las reglas de restricción de tipos y de ámbito
correspondientes al ariálisis de la semántica estática (Statie Semanties Analysis) de
una determinada unidad de diseño VHDL (Design Unit). Este AST, dada su tras-
cendencia, como se verá posteriormente, se suele denominar como la representación
o el formato intermedio de VHDL (VHDL Intermediate Format, VIF) [35-36].
El tercer AST, a diferencia de los dos anteriores, no se corresponde con una
unidad de diseño VHDL, sino que resulta de la composición de los ASTs corres-
pondientes a todas las unidades de diseño VHDL con las que se describe una deter-
[1...
Fuente VHDL Analizador VHDL
...0 Sistemas de
Bibliotecas
Elaborador VHDL Red de procesos VHDL Simulador VHDL
FIGURA 3-9. Análisis, elaboración y simulación de una descripción VHDL.

Análisis Análisis Generación del

Sintáctico Semántico Modelo de Simulación
Estático
Fichero de Diseño VAST

VHDL
FIGURA 3-10. Formatos intermedios de análisis, elaboración y simulación VHDL.
minada entidad de diseño VHDL, después de llevar a cabo el proceso de elabora-

ción de la jerarquía de diseño. Este AST se suele denominar (Elaborated AST,
EAST) por corresponder con la extracción de la heterarquía 2 de procesos VHDL
como resultado de la elaboración estática de una entidad de diseño VHDL. Aunque
este AST se corresponde con el resultado de una fase de compilación propiamente
dicha, no se corresponde con el verdadero resultado de la elaboración estática de
acuerdo con el LRM. Dicha elaboración finaliza realmente con la generación del
modelo de simulación, o sea, con la interconexión de los procesos VHDL resultan-
tes y, por tanto, el AST resultante de esta etapa de procesado debería ser el cuarto
AST, o sea el correspondiente al modelo simulable (Simulatable AST, SAST).
Una vez finalizado el procesado de VHDL para elaborar el modelo de simula-
ción VHDL; todavía es necesario realizar otra compilación para poder generar el
correspondiente programa ejecutable por un ordenador, incluyendo la información
necesaria para su posterior depuración (debugging},
3.4.1.1. Análisis de una unidad de diseño VHDL
La unidad básica de modelado en VHDL es la entidad de diseño (VHDL Design

Entity). Una entidad de diseño se corresponde con cualquier entidad u objeto que
forme parte de un sistema electrónico, pudiendo ser, por ejemplo, una celda (Cell o
Macrocell) que forma parte de un circuito integrado (Integrated Circuit, IC), un IC
o una placa (Printed Circuit Board, PCB) compuesta a su vez de varios ICs.
2 A diferencia de una jerarquía en la que pueden encontrarse objetos dentro de otros objetos, co-
mo, por ejemplo, la jerarquía de funciones anidadas en el lenguaje e, en una heterarquía todos los ob-
jetos se encuentran al mismo nivel. En el casó del resultado de elaborar una jerarquía de diseño VHDL
se obtiene una red de procesos VHDL en los cuales no existen procesos VHDL anidados.
La unidad básica de procesado en VHDL es la unidad de diseño (VHDL Design

Unit). Hay dos tipos de unidades de diseño: primarias (declaraciones de entidad, de
configuración y de paquete) y secundarias (el cuerpo de arquitectura de una entidad
y el de un paquete). No hay que confundir entidad de diseño con unidad de diseño.
Una entidad de diseño se describe por medio de varias unidades de diseño, como
mínimo tiene que existir una declaración de entidad a la que se le puede asociar un
cuerpo de arquitectura directamente o por medio de una declaración de configura-
ción. Cada unidad de diseño puede hacer referencia a otras unidades que han de ser
analizadas previamente. Las declaraciones y los subprogramas comunes se suelen
describir por medio de paquetes a los que otras unidades de diseño pueden hacer re-
ferencia posteriormente.
Una descripción VHDL, véase la Figura 3-11, puede estar compuesta por uno o
varios ficheros textuales en los que están contenidas las descripciones correspon-
dientes a las unidades de diseño. Cada unidad de diseño está precedida por la decla-
ración de su contexto, o sea, de las bibliotecas o de las unidades de biblioteca espe-
cíficas que usa o, dicho de otra forma, de las que depende para su análisis, véase la
Figura 3-11.
Las unidades de diseño que forman parte de un mismo fichero de diseño
VHDL se analizan secuencialmente. Cada unidad de diseño se analiza de forma in-
dependiente y da lugar a una unidad de biblioteca de diseño (VHDL Design Library
Unit). Estas unidades se organizan en un sistema (VHDL Design Library System) de
bibliotecas de diseño VHDL (VHDL Design Libraries). La biblioteca en la que se
almacenan las unidades recién analizadas se denomina biblioteca de trabajo
(WORK) para diferenciarla del resto de bibliotecas, denominadas bibliotecas de re-
cursos (Resources), que componen el sistema. La biblioteca WORK varía en cada
FIGURA 3-11. Una descripción VHDL, compuesta por unidades de diseño almace-
nadas como texto en los ficheros de diseño correspondientes (11.a), el sistema de
unidades de bibliotecas en el que se almacenan los resultados del análisis de las
unidades de diseño (11.b) y una representación alegórica de dicho sistema de unida-
des de biblioteca (11.c).
momento, ya que tan sólo es una biblioteca lógica que en el momento de realizar el
análisis se asocia con una biblioteca física determinada por el diseñador de VHDL.
Los ficheros de diseño VHDL son ficheros de texto que forman parte del siste-
ma de ficheros del sistema operativo sobre el que se trabaja. Sin embargo, las bi-
bliotecas y sus unidades son objetos dependientes de la implementación del sistema
de procesado de VHDL que se esté utilizando.
El Capítulo 11 del LRM describe el proceso y el orden de análisis de las uni-
dades de diseño VHDL. El Capítulo 13 del LRM define los elementos sintácticos
que pueden formar parte de una descripción VHDL. Sin embargo, las reglas sin-
tácticas, las de ámbito y las de tipos se encuentran distribuidas por todo el LRM,
no existiendo una definición de dichas reglas como tal. Estas reglas se pueden ob-
tener por medio de una lectura cuidadosa y cruzada de todos los párrafos que com-
ponen el LRM. Con estas reglas se puede realizar tanto un scanner y un parser pa-
ra realizar el análisis léxico y sintáctico, respectivamente, como el análisis semán-
tico estático de una unidad de diseño VHDL. Por tanto, el análisis de una unidad
de diseño VHDL genera dos ASTs correspondientes a las dos primeras fases de
compilación: VAST y VIF. Aunque el VAST suele desaparecer una vez generado
el VIF.
El resultado final del análisis de una unidad de diseño, o sea el VIF, se almace-
na como una unidad de biblioteca. Si una unidad de biblioteca de diseño se modifi-
ca por algún motivo, entonces todas las unidades de diseño que dependen de ella
quedan declaradas automáticamente como obsoletas y es preciso realizar su análisis
antes de poder ser utilizadas posteriormente.
Cuando finaliza el análisis de una unidad de diseño sólo se puede decir de ella
que su descripción textual estaba escrita en VHDL de forma correcta atendiendo al
LRM, pero nada se puede decir del sistema electrónico, de cuya descripción forma
parte, ni del uso posterior que se va a hacer de ella (p. ej., simulación, síntesis, etc.).
De hecho, el análisis es la única etapa del procesado de VHDL que es común a
cualquier tipo de uso que se vaya a hacer de una unidad de diseño VHDL [37].
El análisis individual de las unidades de diseño es algo único del lenguaje
VHDL, no existe ningún otro HDL con esta característica. Esta particularidad no
sólo afecta al procesado de VHDL, sino que además permite la creación de bibliote-
cas configurables por medio de la capacidad intrínseca de configuración que posee
el lenguaje VHDL. Esta es la base que permite la reutilización del diseño en VHDL
y la posible explotación de los derechos de propiedad (Intellectual Property Rights,
IPRs) de dichos diseños.
3.4.1.2. Elaboración de una jerarquía de diseño VHDL

Una entidad de diseño se describe en VHDL por medio de una declaración de enti-
dad así como de un cuerpo de arquitectura o de la declaración de configuración co-
rrespondiente, junto con todas aquellas unidades de diseño a las que se haga refe-
rencia. El cuerpo de arquitectura de una entidad de diseño y, por tanto, la entidad de
diseño correspondiente, se puede describir por medio de una jerarquía de bloques,
cada uno de los cuales describe una parte de la entidad de diseño. Cada bloque está
compuesto por sentencias concurrentes, de las cuales cabe destacar el proceso, por
3. Procesado V mecanismos de simulación del lenguaje VHDL 159
estar éste, a su vez, compuesto de sentencias secuenciales. Además de considerar

un cuerpo de arquitectura como una jerarquía de bloques, también puede éste hacer
referencia a otras entidades de diseño consideradas como componentes. Desde este
punto de vista también se puede decir que una entidad de diseño se describe por
medio de una jerarquía de entidades de diseño, donde cada una de ellas está descrita
por medio de las unidades de diseño correspondientes.
El Capítulo 12 del LRM describe el proceso de elaboración del modelo de si-
mulación correspondiente a una determinada entidad de diseño. En dicho proceso la
jerarquía de diseño se desmonta para dar lugar a una heterarquía o red plana de pro-
cesos VHDL. Para realizar este proceso es necesario indicar la entidad de diseño
que se desea elaborar por medio del par de unidades de diseño correspondientes a
una declaración de entidad y a uno de sus posibles cuerpos de arquitectura, o por
medio de una unidad de diseño correspondiente a la declaración de configuración
de la entidad de diseño en cuestión.
Todas las unidades de diseño referenciadas por la entidad de diseño, cuya jerar-
quía se desea elaborar, deben ser analizadas previamente. Durante el proceso de ela-
boración, dicha entidad de diseño se considera como el nivel superior de la jerar-
quía de diseño que se desea elaborar y a partir del VIF correspondiente a la declara-
ción de dicha entidad se añade el VIF correspondiente al cuerpo de arquitectura
seleccionado y todos los VIFs correspondientes a todas las entidades de diseño que
aparecen como componentes. A su vez, cada unidad de biblioteca que se procesa
aporta los VIFs correspondientes a las unidades de diseño que forman parte de su
contexto. Lográndose como resultado de la elaboración de una jerarquía de diseño
un nuevo AST (EAST) en el que sólo queda información de los procesos VHDL
junto con las sentencias secuenciales que los componen.
La heterarquía de procesos VHDL resultantes de la elaboración de una entidad
de diseño está compuesta por los procesos VHDL descritos explícitamente en las
unidades de diseño correspondientes, o implícitamente por medio de sentencias
concurrentes que desaparecen durante su correspondiente elaboración.
La Figura 3-12 esquematiza la información correspondiente a una entidad de
diseño cuyo cuerpo de arquitectura contiene un único proceso VHDL explícito y la
instanciación de un componente que a su vez contiene tres procesos VHDL, pu-
diendo formar parte de una jerarquía de bloques y pudiendo ser alguno de ellos el
resultado de elaborar una sentencia (de asignación de señal) concurrente. La asocia-
ción del componente se realiza a través de un puerto (inout) bidireccional (F), o se-
ñal formal, que se une a la señal actual (A). Todas las señales del ejemplo son explí-
citas y escalares, para facilitar su seguimiento.
Como resultado de la primera fase de elaboración de la jerarquía de diseño
VHDL descrita en la Figura 3-12, aparece la heterarquía de procesos VHDL descri-
ta en la Figura 3-13. En esta figura no se hace referencia al nivel jerárquico del que
proviene cada uno de los procesos para hacer mayor énfasis en la heterarquía o es-
tructura plana resultante. Se ha incluido información relacionada con las colas de
los Futuros Eventos (FEs), asociados con cada asignación de señal denominados
drivers en VHDL.
File
Wait. .
Wait .
z= .
F <= .
A<= .
P1
Design Hierarchy
Figura 3-12. Esquema de una entidad de diseño que contiene un proceso e instan-
cia otra entidad que, a su vez, contiene tres procesos.
Hay que recordar que los FEs son los elementos básicos de una simulación diri-
gida por eventos discretos. Por completitud, también se ha incluido en la Figura 3-13
información relacionada con el uso de una variable compartida y de un fichero.
La segunda fase de compilación correspondiente a la elaboración de una jerar-
quía de diseño realiza los enlaces necesarios en el EAST, véase la Figura 3-14, de
modo que la red de procesos VHDL quede lista para su simulación. Dichos enlaces
se realizan teniendo en cuenta las reglas correspondientes a la propagación de los
T~-----1
W,(PlI
Ir.A"',~U~nt;;¡il-:;T:;:ru;:e-;,
3;;;O;l+--~ Wait . File
Wait .
~~I A<~ ...........•.

~_..---1z= .
OP,(AI OP,(FI F <= ......•.....
PI
W,(P'1
I F. Until True, 25 Wait . HF,'IUtn:;¡tili,
Tr.:ru::e:-,
:&4.,..-~ Wait . .SV(ZI
~~OpH21(FI
•• !!I+---l F < •.•.......... ... = (Zl .
... = (Fl .
P2 P4
Figura 3-13. Esquema correspondiente al resultado de la primera fase de la ela-

boración de la entidad de diseño de mayor nivel de la jerarquía de diseño de la Fi-
gura 3-12.
DP,(A)
Dv(F) RF(F)
Figura 3-14. Esquema correspondiente al resultado de la segunda fase de la ela-

boración de la entidad de diseño de mayor nivel de la jerarquía de diseño de la Figu-
ra 3-12.
valores de las señales explícitas e implícitas descritas en el Capítulo 12 del LRM.

La Figura 3-14 muestra los enlaces correspondientes al caso sencillo del ejemplo
esquematizado en la Figura 3-12.
En esta figura se puede observar cómo los valores actuales (Current Value) de
las colas de eventos correspondientes a las sentencias de asignación de la señal es-
calar F de los procesos P2 y P3 se componen, por medio de la función de resolución
asociada a la declaración de la señal correspondiente al puerto F, para así poder
calcular el valor conducido (Driving Value) del puerto F. A dicho valor se le aplica
la función de conversión asociada para poder componerlo, con el valor actual resul-
tante de la sentencia de asignación de la señal A del proceso PI, por medio de la
función de resolución asociada a la declaración de la señal A. De esta forma es co-
mo se calcula el valor conducido de la señal A. Como se puede ver, los valores con-
ducidos de las señales se calculan desde el nivel más bajo de la jerarquía para aca-
bar en el de nivel superior, o sea, de abajo a arriba.
Una vez calculados los valores conducidos de todas las señales ya se puede pa-
sar a realizar el cálculo de los valores efectivos (Effective Value) de las mismas. Di-
chos valores se calculan de arriba a abajo. Para poder calcular el valor efectivo de F
Red de la señal F Red de la señal A
Figura 3-15. Redes de las señales A y F.
es necesario previamente calcular el de A, que se obtiene a partir de su valor condu-

cido. Una vez que se tiene dicho valor, se transforma de acuerdo con la función de
conversión asociada al puerto y así se logra el valor efectivo de F. La Figura 3-15
resalta las redes (Nets) o canales correspondientes a las señales A y F, que comuni-
can a los procesos VHDL de la Figura 3-14.
El valor efectivo de una señal pasa a ser el valor actual (Current Value) que di-
cha señal tendrá en el próximo ciclo de simulación, por ello se dice que sobre dicha
señal se ha producido una transacción (Transaction). Este valor es el que se obten-
drá en el siguiente ciclo de simulación cuando se lleve a cabo la lectura que se hace
de la señal F en el proceso P4. Si al producirse una transacción en una señal, su va-
lor actual cambia con respecto al que tenía anteriormente, entonces se dice que di-
cha transacción ha generado un evento (Event) sobre dicha señal.
La comunicación entre procesos por medio de variables compartidas se realiza
como en cualquier lenguaje de programación, o sea, compartiendo las posiciones de
memoria asociadas a cada variable. La lectura y/o escritura de ficheros se realiza
por medio de las correspondientes llamadas del simulador al sistema operativo.
Como resultado de la segunda fase de elaboración, el EAST se transforma en
SAST y será el tipo de información que se utilizará/almacenará en cada paso de si-
mulación de la entidad de diseño VHDL en cuestión. La elaboración de la jerarquía
de diseño, correspondiente a una determinada entidad de diseño, se puede ver, des-
de el punto de vista de compilación de un lenguaje de programación, como el ver-
dadero final de la etapa de análisis de la descripción ,VHDL correspondiente a dicha
entidad y que se ha realizado de forma incremental en cada una de las unidades de
diseño referenciadas.
Todas las descripciones realizadas en un HDL, e incluso en cualquier HLL, con

semántica de simulación dirigida por eventos discretos y basada en el paradigma de
procesos comunicantes comparten el mismo modelo de información resultante de la
elaboración estática de una jerarquía de diseño VHDL. Se hace énfasis en la carac-
terística estática de la elaboración de VHDL porque hay tres elementos que se ela-
boran en tiempo de ejecución, o sea dinámicamente. Por completitud, estos elemen-
tos son: la creación del parámetro de los bucles (loop) y la comprobación de su ran-
go, la asociación de parámetros formales y actuales de las llamadas a subprogramas
(subprogram), la ejecución de un acceso a través de un puntero (access).
La simulación de la red de procesos VHDL descrita por el SAST todavía tiene
que ser compilada al lenguaje interpretable o ejecutable por el procesador en el que
se desea realizar la simulación. En el primer caso se dice que la simulación es inter-
pretada y en el segundo que es compilada, pudiendo en este caso ser compilada al
código máquina del ordenador y denominarse entonces simulación compilada en
código nativo.
3.4.1.3. Simulación de una entidad de diseño VHOL

La simulación de una entidad de diseño comienza inicializando los valores de todos
los objetos, variables y señales que forman parte de la heterarquía de procesos
VHDL. Ello implica el cálculo de los valores conducidos y efectivos de todas las
señales, la puesta a O de la variable que recoge el tiempo correspondiente al ciclo
actual de simulación, Te, y al próximo ciclo de simulación, Tn, así como la ejecu-
ción de todos los procesos VHDL hasta que se suspenden por ejecutar las corres-
pondientes sentencias de espera (wait statement). Por este motivo, si alguno de los
procesos VHDL careciese de sentencia de espera entonces la fase de inicialización
del modelo de simulación correspondiente no podría acabar nunca y, por tanto, ja-
más se podría llevar a cabo su simulación.
Como resultado de la ejecución de las sentencias de asignación de señal que
aparecen en los procesos VHDL, las colas de los FEs se llenarán con las proyeccio-
nes de los valores que contribuirán al cálculo de los valores de las señales. Estos va-
lores son sólo proyecciones, ya que algunos de ellos nunca alcanzarán a ser el valor
actual de una cola de FEs por ser eliminado por la ejecución de una sentencia de
asignación posterior (preémption}.
La Figura 3-16 muestra el ciclo de simulación. Una vez finalizada la etapa de
inicialización del modelo de simulación, o sea cuando todos los procesos VHDL
han parado su ejecución comunicándoselo al núcleo (kernel) del simulador VHDL,
entonces dicho kernel pone el nuevo valor de la variable correspondiente al tiempo
de simulación actual, Te, al valor de Tn• Si dicho valor se corresponde con el máxi-
mo tiempo de simulación (TIMEHIGH), dado por el diseñador al lanzar la ejecu-
ción de la simulación, y no existen drivers activos, o sea FEs cuyo valor actual haya
cambiado para el nuevo Te, ni procesos listos para reasumir el control de su ejecu-
ción, o sea procesos cuyo tiempo máximo de espera establecido en la sentencia de
espera en la que se pararon no se corresponda con Te, entonces la simulación se da-
ría por finalizada.
FIGURA 3-16. Modelo de simulación VHDL compuesto por una red de procesos
VHDL.
De no darse las condiciones para dar por finalizada la simulación, entonces el

kernel del simulador VHDL actualiza el valor de todas las señales explícitas y a
continuación hace lo mismo con las señales implícitas. Como resultado de dichas
actualizaciones se pueden producir eventos en algunas señales por lo que el kernel
revisará la lista de procesos sensibles a dichas señales y si para alguno de ellos se
cumple la condición de espera o, independientemente, si se ha alcanzado su tiempo
máximo de espera, entonces pasará a formar parte de la lista de procesos cuya eje-
cución se reactivará en el siguiente paso de simulación.
Una vez que ya no quedan procesos por ejecutar sin cambiar el tiempo de si-
mulación, pudiéndose haber generado más de un paso de simulación (correspon-
diente a un incremento temporal de un delta, o) sin por ello haber variado el valor
de Te, los procesos postpuestos (postponed processes) cuyas condiciones se hayan
ido cumpliendo hasta este momento están listos para poder reasumir su control.
Cuando ya no queda ningún proceso pendiente de su ejecución para el tiempo
de simulación Te, entonces el kernel calcula el nuevo valor de T, como el menor va-
lor entre: TIMEHIGH, el próximo tiempo de simulación en el que algún driver es-
tará activo, o el próximo tiempo de simulación en el que se cumpla la condición de
espera temporal de algún proceso.
3.4.1.4. Modelo Temporal <5-delay

Cada repetición en la ejecución del kernel se denomina un ciclo de simulación. Pero
la definición del ciclo de simulación es recursiva, de modo que un ciclo puede invo-
lucrar la ejecución de varios pasos de simulación.
Los pasos de simulación sólo se diferencian del ciclo de simulación en que en
ellos el valor del tiempo físico no varía, sino que se incrementa otra variable que re-
presenta avances infinitesimales de tiempo (8-delay), uno por cada paso de simula-
ción. De este modo VHDL permite la comunicación de datos entre procesos en
tiempo menor que la mínima unidad física (1 fs). Si se utilizan variables comparti-
das entonces se produce la comunicación en tiempo cero, por lo que en VHDL exis-
ten dos modelos temporales el Zero-delay y el 8-delay. Actualmente casi nadie uti-
liza variables compartidas en sus descripciones VHDL, por lo que se puede consi-
derar que el modelo temporal de VHDL es el 8-delay. Además, el modelo
Zero-delay ya fue comentado anteriormente, por lo que el resto de esta sección se
dedica al modelo 8-delay.
El modelo temporal 8-delay se basa en el 'modelo Unit-delay, pero no se puede
decir que sea Unit-delay ya que el paso de simulación se produce en tiempo menor
que la unidad, en un 8-delay, aunque no hay que confundir con la comunicación en
tiempo cero. Esta sub-unidad no tiene significado físico o cuantitativo, el diseñador
no puede generar eventos explícitamente para un determinado paso de simulación.
El concepto de sub-unidad temporal no es una característica única del VHDL,
también lo es de otros HDLs, donde se denomina step. Si una descripción VHDL
sólo emplea 8-delay, entonces el tiempo de simulación no avanza nunca, aunque sí
lo hace la simulación. De este modo sólo se puede representar la relación de causa-
lidad (tiempo cualitativo) entre los eventos que se generan.
En el modelo temporal 8-delay se presenta como compuesto de una jerarquía,
de dos niveles de escalas de tiempo, la macro-escala mide tiempo real o cuantitativo
(físico) y la micro-escala (8-delay) mide tiempo Unit-delay. Esto no es del todo co-
rrecto, ya que la micro escala no tiene sentido cuantitativo, por tanto, no representa
la unidad de tiempo en el sentido estricto de su definición (con el que se emplea en
simuladores RTL). Aunque la macro-escala sí que es puramente Unit-delay, la com-
binación de ambas escalas no es Unit-delay, La Figura 3-17 muestra el modelo tem-
poral de VHDL en dos dimensiones y en su representación unidimensional equiva-
lente en pasos de simulación.
3.4.1.5. Determinismo en VHDL

Un lenguaje de programación se dice que es determinista si su ejecución, para los
mismos datos de entrada, produce los mismos datos de salida. La ejecución concu-
rrente de un HLL puede llevar a una situación de indeterminismo si la ejecución de
una de las tareas concurrentes interfiere en la ejecución de las otras.
En VHDL la única posibilidad de interacción se podría dar si los procesos
VHDL compartiesen variables durante su ejecución, cosa que, por ejemplo, ocurre
en el modelo de gestión de eventos tipo Zero-delay, Entonces la generación de los
futuros eventos podría depender del orden de ejecución y provocar problemas de
carreras (raee eonditions) o bloqueos (deadloeks).
Al
~~IOY
O
1 1 2 3
~
TIempo físico
I
O
I I ~
1 2 3
BI 1,,,,,,,,,,,,1 I I ~
Paso de simulación
FIGURA 3-17. Modelo o-delay. A) Tiempo físico (cuantitativo); B) Paso de simula-

ción (tiempo cualitativo).
Al
Espera a que paren todos los procesos
Bl
FIGURA 3-18. Equivalencia entre la ejecución secuencial y concurrente de los pro-

cesos.
Si no se usan variables compartidas, o sea, si la comunicación entre procesos

VHDL sólo se lleva a cabo por medio de señales VHDL, entonces se puede demos-
trar que el orden de ejecución de los procesos VHDL no influye en el resultado,
independientemente de que éstos se hayan ejecutado de forma secuencial o concu-
rrente, véase la Figura 3-18. Siendo, por tanto, la ejecución del modelo de simula-
ción VHDL un caso de ejecución determinista.
Se puede dar el caso de que el resultado que produce una función de resolución
sea dependiente del orden en que se pasan los valores conducidos de las fuentes co-
mo parámetros de la función, resultando la ejecución dependiente de la implemen-
tación del algoritmo de cálculo de valores conducidos de las señales, impidiendo la
portabilidad de los resultados de simulación. Además, el uso de ficheros desde los
subprogramas no está determinado por el lenguaje y podría ser otra causa de inde-
terminación en el lenguaje. Debido a ello, las herramientas comerciales no suelen
permitir su uso.
3.4.7.6. Ejecución secuencial o concurrente

Si no se usan variables compartidas, la ejecución del programa correspondiente al
modelo de simulación se puede ver como la correspondiente a la ejecución de las
corutinas 3 (Coroutine) correspondientes al código ejecutable de cada proceso
VHDL controladas por una corutina maestra" (Master Coroutine) correspondiente
al código que implementa el algoritmo del kernel. A diferencia del flujo de control
de una subrutina o procedimiento (procedure), véase la Figura 3-19, correspondien-
Comienzo ComienzoA Comienzo B Comienzo C
'n7 Comienzo
S,"',,;"' j
~Fin
Retorno
Fin Fin Fin Fin
(a) (b)
FIGURA 3-19. Diferencia entre la ejecución de las rutinas y las corutinas de un

programa HLL. (a) Subrutina en una jerarquía. (b) Corutinas en una heterarquía.
3 A diferencia de las rutinas, las corutinas no devuelven el control al lugar del código donde se
hizo la llamada, sino a otro distinto establecido previamente.
4 Cuando existe una corutina maestra que controla la ejecución de las demás, al modelo de ejecu-
ción' se le denomina basado en semicorutinas.
te a un código jerarquizado, el flujo de control correspondiente a una ejecución por

corutinas se adapta muy bien al paradigma correspondiente a la heterarquía de pro-
cesos VHDL. Donde, en cada paso de simulación, el flujo de control pasaría de
proceso en proceso hasta llegar al kernel cuando todos se hubiesen parado.
Si intervienen variables compartidas, entonces cualquier implementación se-
cuencial o paralela del programa correspondiente al modelo de simulación va a de-
pender del orden de ejecución de las corutinas o de los procesos respectivamente.
3.4.2. Simulador VHDL
La Figura 3-20 muestra la organización de un simulador VHDL, poniendo en evi-

dencia la interacción entre el programa ejecutable (Target Software, TS) y el entorno
de depuración (Debugger). El simulador de VHDL ejecuta el TS de forma controla-
da, de acuerdo con las indicaciones dadas por el diseñador para su experimentación
o depuración en términos de software. El entorno de depuración observa la ejecu-
ción del TS desde el punto de vista de su estructura estática, tal como se especificó
VHDL Simulator
Procedural & User Interface
Figura 3-20. Organización de un simulador VHDL.

10 20 30 40 50 60 (nsl
Bl I
bl <~ inertial A after 10 ns;
B2
b2 <; transport A alter 10 ns;
b3 <Ce reject 4 ns inertial A alter 10 ns;
B3 I
10 20 30 140 50 60 (ns)
FIGURA 3-21. Cronogramas o formas de onda correspondientes a los modelos de

retraso temporal inercial, con y sin filtrado de pulso, y de transporte.
el código fuente VHDL que compone las unidades de diseño VHDL correspondien-
tes a IDentidad de diseño que se está simulando, y de su actividad dinámica resul-
tante de la interacción de los procesos VHDL al avanzar el tiempo de simulación.
Tanto el análisis estático como el dinámico, del modelo de simulación VHDL,
se realiza en términos correspondientes al fuente VHDL descrito por el diseñador.
Para poder realizar dichos análisis, el entorno de depuración tiene sus propias es-
tructuras de datos y su propia funcionalidad, que es similar a la de un depurador de
software (Software Debugger}. A diferencia de este último, los resultados corres-
pondientes a la ejecución del modelo de simulación no se muestran en términos ab-
solutos, sino relativos al avance del tiempo de simulación. Para ello se suelen em-
plear las representaciones típicas 5 de las formas de ondas o también denominadas
cronogramas, véase la Figura 3-21.
La ejecución secuencial del TS genera un único proceso, por lo que en cual-
quier momento dicho proceso podrá estar en uno de los dos únicos estados posibles:
parado o en ejecución, véase la Figura 3-22. Cada vez que el TS se para, el entorno
de depuración puede mostrar al diseñador de VHDL el resultado de la ejecución del
modelo de simulación.
Sin embargo, en una ejecución concurrente pueden ser varios los procesos que
se generen y cada uno de ellos puede estar, a su vez, en estado de ejecución o para-
do, por lo que la ejecución controlada de estos procesos resulta más complicada.
Esta situación se puede simplificar si se organiza la ejecución de los procesos resul-
tantes en grupos, véase la Figura 3-23. En cualquier caso, el estado del TS se puede
monitorizar derivando el flujo de control de su ejecución. Esta operación se puede
5 Además de corresponder los resultados de simulación con el código fuente, como en cualquier
depurador de software, también se utilizan representaciones de esquemas y cronogramas.
Sequentíal implementation
Kernel Process
Elaborated Procesa
0000
FIGURA 3-22. Estados del proceso generado por la ejecución secuencial del mo-
delo de simulación VHDL.
realizar por medio del uso de puntos de ruptura (breakpoints) temporales o condi-
cionados al valor de uno o de varios objetos, .
La simulación o depuración de un TS concurrente es mucho más complicada
que la de uno secuencial, de hecho, la depuración de programas concurrentes es un
problema de investigación no resuelto todavía. Sin embargo, una primera aproxima-
ción a la depuración de un modelo concurrente consiste en considerar cada proceso
de forma aislada y aplicarles a cada uno de ellos las mismas técnicas de ejecución
controlada y/o monitorización que se aplicarían al proceso correspondiente a una
ejecución secuencial.
Actualmente no hay simuladores VHDL comerciales que permitan la ejecución
paralela de los correspondientes modelos de simulación VHDL y mucho menos su
Parallel implementation
Kernel Process
(~-)
Elaboreted Process
0000
FIGURA 3-23. Estados de los procesos generados por la ejecución concurrente del
modelo de simulación VHDL.
posterior depuración. Finalmente, cabe destacar la posibilidad que ofrecen los simu-
ladores comerciales para comunicar cualquier herramienta externa, tanto con el pro-
grama correspondiente al modelo de simulación VHDL como con el control que el
simulador VHDL ejerce sobre dicho programa. Esta comunicación se realiza por
medio del uso de una biblioteca de rutinas normalmente asequibles en lenguaje C.
Por medio de este interfaz es posible realizar entornos de ce-simulación VHDL pa-
ra sistemas hardware-software o electrónico-mecánicos [39-42].
3.5. MODELADO EN VHDL PARA SIMULACIÓN
Una descripción en VHDL se puede utilizar para simular el comportamiento, sinte-

tizar (incluyendo implícitamente la manufactura del dispositivo físico correspon-
diente) o probar (test) el hardware correspondiente a una determinada entidad de
diseño. Sin embargo, el modelado en VHDL y/o su procesado para cada uno de es-
tos propósitos, aunque es similar, no deja de ser diferente. La Figura 3-24 muestra
el paralelismo existente entre estos tres casos.
VHDL Description VHDL Description

(Stimuli Generator) (Iest Bench)
Modellnput
VHDL
Synthesis Tool
Physical
Modal Generation
Model
Test Bench
Computar Aided VHDL

TastTool Simulation Tool
Modal Testing
FIGURA 3-24. Generación y prueba de modelos descritos en VHDL

1 '12 VHDL. Lenguaje estándar de Diseño ELectrónico
Con una simulación por ordenador, lo que se pretende no es otra cosa que exa-
minar el resultado de poner a prueba el modelo de simulación correspondiente al
sistema que se está estudiando. Para poder llevar a cabo este propósito es necesario
contar con la descripción VHDL de la entidad de diseño correspondiente a dicho
sistema (Unir Under Test, UUT) y con la descripción VHDL de la entidad de diseño
correspondiente al sistema que genera las pruebas iStimuli Generator, SG) que se
desean ejercitar en la simulación. Sin embargo, la disponibilidad de ambas entida-
des de diseño no es suficiente para poder llevar a cabo la tarea de simulación. Ade-
más de contar con ambas entidades de diseño, es necesario contar con la descrip-
ción en VHDL de una tercera entidad de diseño, la correspondiente al entorno (Test
Bench, TE) en el que se van a realizar dichas pruebas y, por supuesto, con el simu-
lador VHDL y el ordenador en el que dicha herramienta se ejecuta.
La entidad de diseño VHDL correspondiente al banco de pruebas carece de
funcionalidad por sí mismo, ya que se trata meramente del artefacto que sustenta a
las entidades de diseño VHDL correspondientes tanto a la UUT como al SG. Sin
embargo, su presencia para poder realizar una simulación VHDL es necesaria, ya
que para ello, por definición, tan sólo se puede seleccionar una única entidad de di-
seño VHDL.
La red de procesos VHDL que componen el modelo abstracto de simulación
contiene tanto los procesos resultantes de la elaboración de la jerarquía de diseño
con la que se ha descrito la UUT como los que resultan de la elaboración de la enti-
dad de diseño SG, sin ningún tipo de distinción o de separación. Así es como se
consigue que la simulación del modelo abstracto de la entidad de diseño VHDL co-
rrespondiente al TE sea equivalente a la realización de las pruebas sobre el modelo
físico correspondiente a la UUT, que se llevarían a cabo en el banco o entorno físi-
co del equipo de pruebas (TE), véase la Figura 3-24. A su vez, dicho TB físico pue-
de ser muy variado, correspondiendo tanto a un entorno real de funcionamiento, por
ejemplo, la tarjeta (PCB) donde se podría probar un circuito integrado de aplicación
específica (Application Specific Integrated Circuit, ASIC), hasta el entorno de prue-
bas conectado a un sistema de pruebas automatizado por ordenador (Automatic Test
Equipment, ATE), por ejemplo, el equipo de pruebas que se utilizaría para probar si
un ASIC se ha fabricado adecuadamente.
La entidad de diseño VHDL de la UUT es tan sólo un componente de la enti-
dad de diseño VHDL correspondiente al TB que se desea simular. Sin embargo,
para poder sintetizar el modelo físico correspondiente a la UUT sólo es necesario
disponer de su correspondiente entidad de diseño VHDL y, por supuesto, de la he-
rramienta de síntesis de VHDL así como del ordenador en el que dicha herramienta
se ejecuta. Esta diferencia pone de manifiesto el hecho de que el proceso de simula-
ción del modelo abstracto correspondiente a una determinada UUT es equivalente a
la combinación de los procesos de síntesis y prueba del modelo físico que se corres-
pondería con dicha UUT, véase la Figura 3-24.
Si el entorno de pruebas automatizado por ordenador también acepta como len-
guaje de descripción de las pruebas VHDL o en un subconjunto del mismo, enton-
ces no hay ninguna diferencia entre las descripciones VHDL correspondientes a la
entidad de diseño generadora de las pruebas (SG) necesarias para poder llevar a ca-
bo la simulación y las pruebas sobre el prototipo físico obtenido cornoresultado del
3, Procesado y mecanismos de simutecián del lenguaje VHDL 173
proceso de síntesis (incluyendo implícitamente la manufactura o fabricación del

dispositivo físico correspondiente), En el caso de la simulación, la entidad de di-
seño generadora de las pruebas (SO) es otro componente de la entidad de diseño
correspondiente al TR Sin embargo, en el caso de las pruebas físicas de la UUT, da-
do que el entorno o banco de pruebas (Test Bench] tiene entidad física, la descripción
VHDL de la entidad de diseño correspondiente a dicho TB es totalmente innecesaria.
Finalmente, otra diferencia entre el modelado en VHDL para realizar una si-
mulación o para llevar a cabo un proceso de síntesis de hardware consiste en que el
modelo de simulación abstracto se genera de una sola vez, aunque pueda llevarse a
cabo en varias fases, mientras que el proceso de síntesis, además de poderse llevar a
cabo también en varias fases, puede ser un proceso iterativo, véase la doble flecha
de la Figura 3-24, En este caso la descripción VHDL resultante de la primera síntesis
correspondería a una descripción VHDL de menor nivel abstracción de la misma
UTT, por ejemplo, el resultado de una-síntesis comportamental (Behavioral Synthe-
sis) sería la entrada de una síntesis a nivel de transferencia de registros (Register
Transfer Level), cuya salida sería a su vez entrada de una síntesis lógica (Logic Synt-
hesis) a partir de la cual las herramientas de manufactura permitirían fabricar el le.
Quizá no es necesario recalcar que el proceso de simulación se puede realizar
para cada una de las descripciones VHDL de la UUT resultantes en cada etapa de
síntesis para verificar que dichas descripciones son correctas de acuerdo con el con-
junto de pruebas que se ha establecido previamente, véase la doble flecha de la Fi-
gura 3-24. Aunque quizá sí vale la pena destacar que la descripción VHDL corres-
pondiente a la entidad de diseño que genera las pruebas (SO) puede necesitar un
cierto refinamiento para ajustarse al nuevo nivel de abstracción en el que se desea
realizar la simulación.
3.5.1. Simulación lógica, temporal y de fallos
Por razones históricas y debido a que durante mucho tiempo el mayor nivel de abs-
tracción al que los sistemas electrónicos se podían modelar, para poder llevar a cabo
su simulación, era el nivel de puertas lógicas (Gate Level), a las simulaciones de es-
te tipo de sistemas se les denominó simulaciones lógicas. Término que se ha mante-
nido hoy en día, aun cuando las descripciones HDL se pueden realizar a distintos
niveles de abstracción, e incluso se pueden realizar modelos multinivel, o sea mo-
delos en las que algunas entidades de diseño HDL están descritas a distinto nivel de
abstracción (Behavioral, Register Transfer; Gate Level).
El adjetivo de simulación lógica se debe al énfasis que se hacía y todavía se ha-
ce al diferenciar el propósito de la mera simulación del comportamiento lógico con
las simulaciones temporal y de fallos. Estas simulaciones se realizan para tener en
cuenta factores propios del entorno de funcionamiento de los ASICs (p. ej., tempe-
ratura, voltaje o layout) o de su manufactura, respectivamente (43), Incluso em-
pleando un HDL, ambos tipos de simulaciones todavía se realizan a nivel de puertas
lógicas, por medio de modelos que describen la lista de puertas que componen la
red {netlist) que describe al sistema electrónico. Para ello sólo se utiliza un subcon-
junto del HDL, en el caso de VHDL dicho subconjunto es el standard VITAL.
Hoy en día las simulaciones HDL que se realizan para formalizar el contrato de
fabricación de un ASIC (Sign-off Simulation) entre el diseñador y el fabricante de
silicio (Silicon. Foundries) se hacen a nivel de puertas lógicas, aunque se intenta que
cada vez el nivel de abstracción sea mayor. La simulación de Sign-off suele corres-
ponder con una simulación lógica cuyo modelo se ha validado por medio de una si-
mulación temporal y cuyas pruebas se han validado por medio de una simulación
de fallos.
La simulación temporal se realiza considerando el modelado en un HDL de las
características temporales de las puertas lógicas que componen un IC no sólo con
valores típicos, sino que también se tienen en cuenta los valores máximos y míni-
mos. Las simulaciones temporales comprueban si la funcionalidad del sistema elec-
trónico sigue siendo válida, sin producir violaciones temporales, cuando se han lle-
vado a cabo todas las combinaciones posibles que cubren el rango completo de las
posibles especificaciones temporales. Para aumentar la precisión con la que se reali-
zan las simulaciones temporales a nivel de puertas lógicas, éstas se retroanotan
(backannotation) con información proveniente de la de la etapa de layout. Por ser
esta etapa posterior a la de la generación de la netlist de puertas, es por lo se dice
que la información que mejora la caracterización temporal de las descripciones
HDL de las puertas se retroanota o que se anota a posteriori. Esta simulación com-
plementada a la simulación puramente lógica se lleva a cabo para evitar los posi-
bles efectos que se pueden producir debido a cambios en el proceso de manufactura
del ASIC o en las condiciones de funcionamiento (p. ej., temperatura o voltaje). La
simulación temporal se puede realizar por medio de un simulador "lógico" con mo-
delos específicos o por medio de un instrumento distinto.. denominado analizador
temporal (Timing Analyzer).
Debido a que una vez que se han fabricado los ICs, éstos sólo se pueden probar
(test) desde el exterior, la posibilidad de acceder a cualquier punto del modelo de si-
mulación para su observación y monitorización se ha perdido . Por e.~te motivo, la
calidad de las pruebas, que en simulación era una de las piezas claves para confiar
en esta técnica experimental, es todavía más crítica, si cabe, cuando se desean utili-
zar para llevar a cabo la comprobación de que el ASIC se ha fabricado adecuada-
mente (Manufacturing Test). La capacidad de que un ASIC se pueda probar en me-
jores condiciones una vez se ha fabricado se puede incrementar si en su diseño se
añade cierta funcionalidad (lógica) que así lo permita. Este tipo de técnica se deno-
mina diseño para "testabilidad" tDesign For Testability, DFT) y se suele solapar
con el proceso de síntesis lógica de la descripción HDL.
Para evaluar, de alguna forma, la calidad de las pruebas de manufactura se sue-
le realizar otro tipo de simulación complementaria a la lógica, denominada simu-
lación de fallos (Fault Simulation) [44]. Al igual que ocurría con la simulación
temporal, la simulación de fallos también se realiza actualmente a nivel de puertas
lógicas. Este tipo de simulación permite evaluar la cobertura que proporcionan las
pruebas, o sea que parte del ASIC se puede probar en base a realizar simulaciones
comparando el comportamiento de cada prueba entre su simulación lógica pura y la
correspondiente simulación en la que se ha introducido un fallo. Dicho fallo consis-
te en modificar el modelo de cada puerta de acuerdo ti, un modelo que representa los
posibles efectos de un fallo de fabricacién. Actualmente, el modelo de fallos que se
3. Procesado V mecanismos de simulación del lenguaje VHDL 175
.utiliza para este propósito es el stuck-at (estancamiento), en el que se considera que

los fallos de fabricación se pueden corresponder con el estancamiento a loa O del
valor que adquieren las puertas lógicas. Hay que recordar que, por ser éste a su vez
un modelo de fallos, incluso si con unas determinadas pruebas se diese una cobertu-
ra del 100 por 100 del circuito, aun así, no querría decir que si el ASIC pasase todas
estas pruebas sería correcto.
Normalmente se requiere una cobertura superior al 95 por 100. Para generar las
pruebas de manufactura de modo que se alcance dicha cobertura, se suele extender
el conjunto de pruebas funcionales o lógicas con aquellas pruebas específicas que
comprueban, valga la redundancia, la testabilidad del circuito. Dichas pruebas se
suelen generar automáticamente por medio de una herramienta denominada Auto-
matic Test Pattern Generator (ATPG) que suele estar integrada con la herramienta
de síntesis. Por ello, en la Figura 3-24 se ha incluido una línea de puntos que intro-
duce las pruebas específicas de manufactura que se van a utilizar posteriormente
tanto en la entrega del diseño, por ejemplo, para Sign-off, como en la demostración
de que el ASIC se ha fabricado adecuadamente probándolo en el ATE.
3.6. EJERCICIOS
1. Describe el significado de realizar una simulación en un ordenador.

2. Describe el mecanismo de simulación dirigido por eventos discretos.
3. ¿Cuál es la diferencia entre el modelo temporal Zero-delay y el Unit-delay't

Deduce a partir de ambos el modelo correspondiente a la simulación VHDL.
4. ¿Qué medios se emplean para especificar la sintaxis y la semántica de los len-

guajes de programación?
5. ¿Qué es un formato intermedio de compilación y qué relación tiene con una es-
tructura de datos de tipo árbol sintáctico abstracto (AST)?
6. ¿En qué se parece y en qué se diferencia un HDL y un HLL?
7. ¿Cuál es la diferencia entre una unidad de diseño y una entidad de diseño

VHDL?
8. ¿Cuáles son las diferencias entre los niveles de abstracción, los estilos de des-
cripción y las jerarquías de un diseño descrito en VHDL?
9. Describe los dos tipos de jerarquías que se pueden encontrar en una descripción
VHDL.
10. ¿Cuál es la etapa común, del procesado de una descripción VHDL, para todos
los propósitos para los que ésta se quiera utilizar (p. ej., simulación, síntesis,
etc.)? y ¿por qué es así?
176 VHDL. Lenguaje estándar de Diseño EJreGtrónico
11. Si se tuviesen que integrar una descripción en VHDL con otra realizada en otro
HDL como. por ejemplo. Verilog HDL, ¿en qué etapa de su procesado se debe-
ría hacer? y ¿por qué sería así?
12. ¿Cuál es la relación existente entre el determinismo de una descripción VHDL,

su portabilidad y la forma en que se realiza la implementación del programa
correspondiente a su modelo de simulación?
13. ¿Qué biblioteca y qué paquetes son visibles para toda unidad de diseño VHDL?
14. Realiza el proceso de elaboración completo de una entidad de diseño similar a

la del esquema que se ha empleado para ejemplificar el proceso de elaboración
en este capítulo. Realiza la inicialización y la simulación de varios pasos simu-
lación haciendo tú mismo de intérprete del modelo elaborado, o sea, sin necesi-
dad de generar un código ejecutable en un ordenador.
lS. ¿En qué se diferencia el modelo temporal &delay del Zero-delay y del Unit-de-
~aYfl?¿Po~ qué en VdHDL ~~y dosdmoldel~s te~poó radies ,cUáldes sOdny .CUál¡ es. ~u , ...
In uencia en e l . etermnnsmo e a ejecuci n e l mo e ol e simu acron 1
VHDL? j
j
16. ¿En qué se diferencia una descripción VHDL de un modelo de simulación y de j
un simulador VHDL? ,
1
17. ¿En qué se parece y en qué se diferencia un simulador VHDL de un depurador

de software (Software Debuggerf!
18. ¿Cuál es la relación existente entre el proceso de generación de mi modelo de

simulación y el de su síntesis?
19. ¿En qué se parece y se diferencia la simulación de una descripción VHDL y el

Test del correspondiente hardware?
20. ¿Cuál es la diferencia entre el Test de manufactura y el funcional? y ¿cuál es su

relación con la simulacién de Sign·Off necesaria para poder fabricar un ASIC?
3.7. BIBLIOGRAFíA
[1] "IEEE Standard VHDL Language Referenee Manual se, 1076-1993", IEEE, Ine., New
York, N, Y., March 1994. .
[2] M. R. BARBACCI, T. UHEARA:"Computer Hardware Descríptíon Languages: Too Bridge
Between Software and Hardware". IEEE Competer Vol. 19, (2). 1985, pp. 6-8.
[3] R. W. HARTES1EIN: "Hardware Description Languages". Advances in CAD for VLSI
Vol. 7, North Holland, 1987.
[4] S. DASGUPTA: "Competer Architectnre a Mooem Synthesis". Vol. 2, JoOOWiley & Sons,
Ine. 1989.
[5] G. J. LIPOVSKY:"Hardware Description Languages: Voices from the Tower of Babel".

IEEE Computer Vol. 10, June 1977, pp. 14-17.
(6) A. DEWEY:"Hardware Description Languages: Move from Academia Projects to Indus-
trial Production Tools". Proc. 15th IEEE Southwestem Symp. System Theory. March
1983, pp. 144-147.
[7J R. PILOTY,M. BARBACCI,D. BORRlONE,D. DrnTMEYER, F. HILLand P. S. KELLY:"CON-
LAN Report", Leeture Notes in Computer Scienee 151, Springer-Verlag 1983.
[8J 1. D. MORISON,N. E. PEELING,T. L. THORP:"The Design Rationale of ELLA, a Hardwa-
re Description Language". Proc. Of Computer Hardware Description Languages. Tok-
yo, August 1985.
[9J Open Verilog Intemational: "Verilog Hardware Deseription Language Reference Ma-
nual". Version 1.0, October 1991.
[10] "IEEE Standard Verilog Hardware Description Language Referenee Manual Std. 1364-
1995", IEEE, Inc., New York, N. Y, 1995.
[11] O. KARATSU: "VLSI Design Language Standardization Effort in Japan". Proc. 26th De-
sign Automation Conferenee, pp. 50-55, 1989.
[12] R. McHANEY:"Computer Simulation: A Practical Perspective". Academic Press, Inc.,
U.K., 1991.
[13] F. NEELAMKAVIL: "Computer Simulation and Modelling". Chichester, U.K: John Wiley,
1987.
[14] M. PIDD: "Computer Modelling for Discrete Simulation". Chiehester, U.K.: John Wiley, .
1989.
[15] R. E. NANCE:"A History of Discrete Event Simulation Programming Languages".
ACM SIGPLAN Notices Vol. 28, No. 3, March 1993, pp. 149-175.
[16] E. R. ULRICH,V. D. AGRAWAL, J. H. ARABIAN:"Concurrent and Comparative Discrete
Event Simulation". KIuwer Academic Press Publishers, 1994.
[17] U. W. POOCH,J. A. WALL:"Discrete Event Simulation: A Practical Approach". CRC
Press, Inc., 1993.
[18J D. HAREL:"Algorithmics: The Spirit of Computing". Addison-Wesley Publishing Com-
pany,1987.
[19] D. A. WATT:"Programming Language Processors". Prentice Hall Intemational Series in
Computer Science, 1993.
[20] A. V. AHO, R. SETHI,1. D. ULLMAN:"Compilers, Principles, Techniques, and Tools".
Addison-Wesley, 1986.
[21] T. PrrrMAN, J. PETERS:"The Art of Compiler Design: Theory and Practice". Prentice
Hall Intemational Editions, 1992.
[22] J. HOLMES:"Object-Oriented Compiler Construction". Prentice Hall International Edi-
tions, 1995.
[23] 1. HOLMES:"Building Your Own Compiler With C++". Prentice Hall Intemational Edi-
tions, 1995.
[24J 1. GOICOLEA,R. GUZMAN,M. A. SALAS,S. OLCOZ,D. NAVARRO, A. Rov: "System De-
signer Approach to the Development of Embedded Systems using VHDL". Proc. of the
Second Asian Pacific Conferenee on Hardware Description Languages, Toyohashi, Ja-
pan, Oetober 1994, pp. 135-138,
[25] D. D. GAJSKI,F. V AHID, S. NARAYAN, J. GONG:"Specification and Design of Embedded
Systems". PTR Prentice Hall, 1994.
[26] 1. P. CALVEZ:"Embedded Real-Time Systems: A Specifieation and Design Methodo-
logy". John-Wiley Professional Computing, 1993.
[27] R. K. GUPTA:"Co-Synthesis of Hardware and Software for Digital Embedded Sys-
tems". Kluwer Aeademic Publishers, 1995.
[28] J. ROZENBUT,K. BUCHENRIEDER: "Codesign: Computer-Aided Software/Hardware En-

gineering". IEEE Press 1995.
[29] D. A. PAITERSON,1. L. HEN'NEsSY:"Competer Organization & Design: The Hardware/
Software Interface". Morgan Kaufmann, 1994.
[30] D. A. WATí: "Programming Language Syntax and Semantics". Prentice Hall Internatio-
nal Series in Computer Science, 1991.
[31) S. OLCOZ,J. M. COLOM:"VHDL Through tbe Looking Glass", VHDL_Forum for CAD
in Europe 1993. Innsbruck, pp. 13-22.
[32) S. OLCOZ,J. M. COLOM:"The Discrete Event Simulation Semantics of VHDL". Proc.
Of Int1. Conf. On Simulation and Hardware Description Languages, San Diego, CA,
1994, pp. 128-134.
[33] S. OLCOZ,J. M. COLOM:"Towards a Formal Semantics of VHDL IEEE Std. 1076-
1987". Proc. EuroDAC with EuroVHDL 1993, Hamburg, September, 1993.
[34) S. OLCOZ,L. AYUDA,A. CASTELLVf, M. GARCÍA,l. IzAGUIRRE, O. PEÑALBA:"Implemen-
ting a VHDL Design Manager: VRBL-lCE". VHDL International Users Forum, Spring
1997 Conference, Santa Clara, CA, pp. 93-102.
[35] IEEE Design Automation Standards Comrnittee (DASC) Working Group, "VIFASG a
VHDL'87 Intermediate Format". 1991.
[36] J. WILLIS, R. NEWSHUTZ, P. WILSEY, D. MARTIN, G. PETERSON, J. HINES, A.
ZAMFIRESCU:"Advanced Intermediate Representation with ExtensibiIity (AIRE)".
VHDL Intemational Users Forum, Fal11996 Conference, Sant Jose, CA, pp. 33-42.
[37] S. OLCOZ,P. MENCHlNl:"HDL Interoperability: A Compiler TechnoIogy Perspective".
VHDL International Users Forum, Fall1996 Conference, Sant Jose, CA, pp. 51-58.
[38] S. OLCOZ,L. ENTRENA,L. BERROJO,1. GoICOLEA:"Reínvented Prototyping on VHDL".
VHDL International Users Forum Spring 1995 Conference, San Diego, 1995, pp. 7-
29/7-39.
[39] S. OLCOZ,L. ENTRENA,L. BERROJO,J. GoICOLEA:"Prototyping: tbe Bottom Line of
VHDL System Simulation", Proc. First Workshop on Libraries, Component Modeling
and Quality Assurance, Nantes, April, 1995, pp. 21-38.
[40) S. OLCOZ,L. ENTRENA,L. BERROJO:"VHDL Virtual Prototyping". 6th IEEE IntI.
Workshop on Rapid System Prototyping, Chapel Hill, NC, June 1995.
[41] S. OLCOZ,L. ENTRENA,L. BERROJO:"A VHDL Virtual Prototyping Technique for Me-
chatronic System Design", Intl. Conference in Recent Advances in Mechatronics, Is-
tambul, August 1995.
[42) S. OLCOZ,L. ENTRENA,L. BERROJO:"An Effective System Development Environment
based on VHDL Prototyping". Proc. EuroDAC witb EuroVHDL 1995, Brighton, Sep-
tember, pp. 502-507.
[43] J. P. HUBER,M. W. ROSNECK:"Successful ASIC Design the First Time Through". Van
Nostrand Reinhold, 1991.
[44] T. RIESGO,S. OLCOZ:"Concurrent Hierarchical FauIt SimuIation using VHDL". VHDL
Intemational Users Forum Fall Meeting, California, October 1993.
Capítulo 4
,
SINTESIS
Eugenio VilIar y Pablo Sánchez

Universidad de Cantabria
En el trabajo no consigues lo que mereces.

Consigues lo que negocias.
J. Karrass
El objetivo principal de este capítulo es introducir la aplicación de

VHDLen síntesis como tecnología fundamental en las metodologías de
diseño descendentes utilizadas industrialmente en la actualidad
[CP96J.La síntesis desde VHDL constituye hoy en día una de las princi-
pales aplicaciones del lenguaje con una gran demanda de uso. Las he-
rramientas de síntesis basadas en el lenguaje permiten incrementar
significativamente la productividad del diseño. Este hecho es particu-
larmente importante en el contexto actual caracterizado por un merca-
do extraordinariamente competitivo en el que resulta imprescindible
acortar simultáneamente el tiempo de acceso al mercado y los costes
de diseño. De hecho, estas herramientas resultan imprescindibles a la
hora de asegurar el mantenimiento de la competitividad en cualquier
empresa con actividad en diseño electrónico [MLD92J.
El objetivo principal de este capítulo es el de describir la utilización
de VHDL en síntesis RT-Iógica, tal y como lo hacen las herramientas co-
merciales de síntesis disponibles en la actualidad. En primer lugar, se
hace un análisis general del uso de un lenguaje como VHDL en aplica-
ciones de síntesis. A continuación se hace una breve introducción a los
modelos de sistema digital utilizados por las herramientas de síntesis y
a los pasos de síntesis que aplican. Posteriormente, se detalla la des-
cripción en VHDL de los componentes fundamentales de un sistema
digital. Este conocimiento es imprescindible a la hora de asegurar que
la implementación propuesta por la herramienta de síntesis es eficien-
te y coincide funcionalmente con la que se desea. Finalmente, se con-
cretan un conjunto de recomendaciones que facilitan al diseñador el
aprovechamiento al máximo de las prestaciones de la herramienta de
síntesis.
179
4. 1. INTRODUCCiÓN
Tal y como se ha comentado en el Capítulo 1, el diseño electrónico asistido por

computador (CAD) ha sufrido un fuerte desarrollo durante las dos últimas décadas
y el interés en el campo es previsible que crezca en los próximos años. Durante este
tiempo han aparecido en el mercado herramientas comerciales que sustentan meto-
dologías de diseño maduras. Estas metodologías resultan imprescindibles en el di-
seño de los circuitos de la complejidad y prestaciones soportadas por la tecnología
microelectrónica actual y se utilizan en un amplio rango de aplicaciones como siste-
mas de cómputo de propósito general, sistemas embebidos, sistemas de telecomuni-
cación, sistemas de control, electrónica aeroespacial, del automóvil y electrónica de
consumo. Las herramientas CAD representan el medio para diseñar estos sistemas
con la fiabilidad y la productividad requeridas.
Las herramientas CAD se pueden clasificar en cuatro grandes grupos depen-
diendo de su papel en el proceso de diseño completo: edición, análisis, síntesis y
optimización. Los editores permiten la captura del comportamiento o la estructura
del diseño. Existen editores especializados en distintas represéntaciones del diseño
como FSMDs, esquemáticos y layout. Las herramientas de análisis permiten extraer
propiedades del diseño. El simulador constituye la herramienta de análisis más im-
portante en la actualidad. La simulación del circuito en las distintas etapas del pro-
ceso de diseño es el medio más frecuente para comprobar su corrección. Otras he-
rramientas de análisis ampliamente utilizadas son el generador de patrones de test y
el analizador temporal. Las herramientas de síntesis realizan automáticamente algu-
no de los pasos del proceso de diseño generando una implementación detallada de
una descripción más abstracta. En íntima relación con la herramienta de síntesis (de
la que en muchas ocasiones no se distingue), la herramienta de optimización permi-
te mejorar la calidad del diseño a un determinado nivel de abstracción en función de
los parámetros definidos por el usuario (coste, velocidad, consumo, etc.).
Las herramientas CAD hacen uso de notaciones de diseño, ya sean explícitas o
transparentes para el usuario. Las notaciones explícitas son aquellas relevantes para
el diseñador. Entre ellas, cabe citar las tablas de verdad y de estado (para minimiza-
ción lógica), la lista de puertas (para simulación lógica) o la lista de componentes
(para simulación analógica, p.e. SPICE). Las notaciones transparentes para el usua-
rio son formatos utilizados por la herramienta a los que el usuario normalmente no
tiene acceso y en muchos casos ni siquiera tiene conocimiento de su uso. Cabe citar
los formatos intermedios utilizados por una herramienta determinada o un conjunto
de ellas en un entorno CAD o las librerías de componentes en alguna tecnología.
Los lenguajes de descripción de hardware (HDLs) representan un medio de descrip-
ción explícito del circuito a diseñar. La novedad aportada por los HDLs reside en la
utilización de conceptos de ingeniería del software a la descripción y modelado de
hardware. Sintácticamente, los lenguajes de descripción de hardware resultan en ge-
neral muy similares a lenguajes de programación. De hecho, en muchos casos, el
lenguaje de descripción de hardware se deriva de un lenguaje de programación. Tal
es el caso de VHDL, lenguaje que procede del ADA [C96] y del que hereda mu-
chos de sus conceptos y propiedades. Esta similitud formal entre los lenguajes de
descripción de hardware y los lenguajes de programación tiene consecuencias en su
4. Síntesis 181
uso, particularmente en síntesis. Como comentaremos posteriormente, el diseñador

no debe de olvidar que, aunque la sintaxis sea similar a la de un lenguaje de progra-
mación, el objetivo del código es la descripción del hardware que se quiere obtener.
Si este hecho no es tenido en cuenta, los resultados obtenidos de la herramienta de
síntesis pueden no ser satisfactorios. De heclio, la herramienta de síntesis no evita el
diseño lógico. Las decisiones de alto nivel respecto a la arquitectura del circuito, su
funcionalidad, componentes e interconexión, comunicación con el exterior, frecuen-
cia de funcionamiento, etc., siguen siendo responsabilidad del diseñador y la cali-
dad del diseño va a seguir dependiendo fundamentalmente de su experiencia [N93]
[OW94) [S96].
4.1. 1. Proceso de síntesis
Los niveles de abstracción más aceptados en diseño hardware son los que se mos-
traron en la Figura 1-7. Aparecen, por tanto, los tres pasos de síntesis que se
muestran en la Figura 4-1. Cada uno de estos pasos está soportado por herramien-
Nivel funcional
Nivel RT
--- Nivel lógico
Retroanotación
Implementación
FIGURA 4-1. Proceso de síntesis.

tas de síntesis específicas, independientemente de que en algún caso un entorno de-

terminado soporte conjuntamente varios de ellos. Las dos herramientas de síntesis
más importantes en la actualidad son la herramienta de síntesis RT-lógica y la herra-
mienta de posicionamiento e interconexión. Aunque tradicionalmente ambas tareas
se han venido realizando. por separado, en la actualidad existe una tendencia a su
conexión particularmente en diseños en los que el aprovechamiento al máximo de
las prestaciones de la tecnología resulta esencial. Sólo en los últimos años han co-
menzado a aparecer en el mercado las primeras herramientas de síntesis de compor-
tamiento. Se trata todavía de una tecnología con muy escasa penetración industrial
y comercialmente inmadura. Esta es la razón por la que queda fuera de los objetivos
del presente libro.
Aunque desde el punto de vista del diseño la descripción inicial es la más im-
portante, 'en cada nivel de abstracción va a ser posible y, en la mayoría de las oca-
siones necesario, describir el circuito mediante el uso de un lenguaje de descrip-
ción. Una de las ventajas que aporta VHDL frente a otros lenguajes reside en su
capacidad de descripción multinivel. De hecho, VHDL puede utilizarse en los tres
niveles de la Figura 4-1, desde el nivel funcional a la implementación final.
Aunque la sintaxis del lenguaje es común a los tres niveles, la interpretación
del código, o semántica, va a ser diferente en cada nivel. Tal y como se propone en
[E95], una descripción VHDL puede caracterizarse en función de tres aspectos: la
temporización, los tipos de datos y el estilo descriptivo:
• La temporización alude al nivel de detalle disponible sobre el funcionamien-

to temporal del circuito. La temporización es la característica principal que
permite identificar un determinado nivel de abstracción. A lo largo del pro-
ceso de diseño se pueden distinguir tres niveles de temporización. En el nivel
inferior o lógico se conocen los retrasos introducidos por los distintos com-
ponentes del circuito. El estilo descriptivo estándar es el definido en VITAL
[IEEE95]. A nivel de circuito lógico, los retrasos considerados son los pro-
pios de cada componente, teniendo en cuenta el retraso adicional introducido
por la carga representada por los componentes a los que se conecta a la sali-
da y, opcionalmente, la estimación del retraso debido a las interconexiones.
Después del posicionamiento y la interconexión, a la misma descripción es
posible retroanotarle los retrasos reales debidos a las interconexiones, lo que
completa el nivel de detalle propio de la implementación final. A nivel RT,
los retrasos de los componentes del circuito no se conocen. Sin embargo, las
acciones (transferencias a registros y asignaciones de salida) en cada estado
están decididas. En diseño síncrono, es la señal de reloj la que provoca el
cambio de estado, con lo que todas las señales del circuito cambian con ella
en sucesivos ciclos-o. La síntesis RT-lógica de circuitos síncronos constituye
la tecnología de síntesis más importante y utilizada en la actualidad. Por ello,
la descripción VHDL a este nivel va a representar el objetivo principal de es-
te capítulo. En diseño asíncrono [LS93], los cambios de estado en cada mó-
dulo lo provocan las señales de requerimiento y reconocimiento. Se trata de
una tecnología de síntesis muy poco madura no soportada en la actualidad
por ninguna herramienta comercial. A nivel funcional, la planificación de las
4. Síntesis 183
distintas acciones todavía no se ha decidido y sólo las relaciones causales de-

terminadas por las dependencias entre datos son relevantes [MLD92][M94].
Ejemplos de este estilo de modelado se muestran en el Capítulo 5.
• El segundo aspecto por el que puede caracterizarse una descripción VHDL
lo representa los tipos de datos manejados. Los más simples son los tipos a
nivel de "bit", ya sea en lógica binaria (bit y boolean) o multivaluada
(std_ulogic). El siguiente nivel estaría representado por tipos de datos
compuestos por agrupación de "bits" (bit_vector, std_logic_vector) y
su correspondiente representación entera sin signo (posi ti ve, na tural,
unsigned) O con signo (integer, signed) en complemento-I, complemen-
to-2, etc. El nivel superior los representan los tipos de datos abstractos (rea-
les, físicos, enumerativos, registro, acceso, etc.).
• El tercer aspecto lo representa el estilo descriptivo, algorítmico, flujo de da-
tos y estructural. En función del estilo utilizado, una descripción VHDL pue-
de situarse en alguno de los puntos del cubo de diseño representado en la Fi-
gura 4-2.
RT
Bits
Compuestos
Lóg ico """"-""'-"''''''-'''''''--''--_~~'--''''''''''''''!!'::.:.c'''_--",=:___
Estructural Flujo de datos Algorítmico
FIGURA 4-2. Cubo de diseño.

Cada movimiento en el cubo se corresponde con un paso de diseño. Así, en el

paso "1" una descripción funcional sobre datos compuestos se planifica en ciclos de
reloj. En el paso "2", la descripción RT algorítmica se descompone en un conjunto
equivalente de asignaciones de señal concurrentes (flujo de datos). En el paso "3",
los tipos compuestos en la descripción RT resultante se codifican en binario y se
descomponen en el conjunto de "bits" equivalente. En el paso "4", se procede a la
minimización lógica e implementación de cada una de las funciones lógicas obteni-
das en el paso anterior sobre una tecnología deternúnada. En el último paso ("5"),
las asignaciones a señal se sustituyen por el conjunto de componentes que las im-
plementan. De todos los movimientos en el cubo, los movimientos verticales son
los que conceptualmente constituyen pasos de síntesis con el consiguiente cambio
en el nivel de abstracción.
Las etapas de síntesis para las que se ha propuesto la utilización de VHDL cu-
bren la síntesis de comportanúento, la síntesis RT y la síntesis lógica. La síntesis de
comportanúento origina la arquitectura a nivel transferencias entre registros desde
una descripción algorítmica del funcionamiento del circuito. La síntesis RT genera
el conjunto de ecuaciones lógicas y deternúna los elementos de memoria de la ar-
quitectura de transferencias entre registros. La síntesis lógica propone una imple-
mentación óptima de las ecuaciones lógicas en puertas y, posteriormente, mapea di-
chas puertas y los elementos de memoria sobre los elementos de biblioteca en la
tecnología escogida.
Ejemplo 4.1. Se desea diseñar un módulo para la multiplicación de números bi-

narios sin signo. El módulo recibe el multiplicando por un "bus" de 32 "bits" en el
ciclo de reloj indicado por la señal "start =
1". En el siguiente ciclo de reloj recibe
el multiplicador. El algoritmo de multiplicación es el de acumulación del multipli-
cando en función de los "bits" del multiplicador y su posterior desplazamiento se-
gún el esquema de la Figura 4-3:
Multiplicador Multiplicando
l 01 10 I 001 .. 011
I 000 .. 000
001 .. 011
001 011
000 000
00 10
Resultado
FIGURA 4-3. Esquema de multiplicación binaria sin signo.

4. Síntesis 185
Finalizada la operación de multiplicación, el módulo pondrá la señal ends a

"1" y proporcionará por la salida los 32 "bits" más significativos del resultado. En
el siguiente ciclo de reloj proporcionará los 32 "bits" menos significativos y queda-
rá a la espera de un nuevo requerimiento de multiplicación. A partir del conoci-
miento de las entradas y salidas del módulo, es posible la declaración de la entidad
correspondiente:
library IEEE;
use IEEE.stQ_logic_1164.all;
use IEEE.numeric_std.all;
entity multiplicador i8
port {databus_in in unsigned (32 downto 1):
databus_out out unsigned (32 downto 1);
start in stQ_u1ogic;
re1oj,reset in stQ_ulogic;
ends out stQ_ulogicl;
end multiplicador;
LISTADO 4-1. Declaración de la entidad multiplicador'.
El punto de partida del proceso de diseño desde el nivel funcional es la descrip-

ción VHDL del algoritmo hardware a implementar. Así, la descripción funcional
del algoritmo de multiplicación es la que se muestra en el Listado 4-2.
Como ya hemos comentado, no todas las herramientas comerciales soportan
este estilo descriptivo ni la síntesis de comportamiento correspondiente. En cual-
quier caso, y tal y como se hará en el ejemplo de modelado del Capítulo 5, la simu-
lación del código funcional del Listado 4-2 permite comprobar que el algoritmo uti-
lizado es correcto en la obtención de los resultados requeridos. En esta descripción,
los recursos hardware finales y la asignación de operaciones a ciclos de reloj no
está todavía decidida. La única información temporal relevante es la dependencia
entre datos establecida en el código. Así, los ciclos de obtención de datos (multipli-
cando y multiplicador) y de salida del resultado están determinados en la propia es-
pecificación. Sin embargo, el número de ciclos para realizar la acumulación del
multiplicando no lo está y constituye la primera decisión importante de diseño. De-
pendiendo del retraso, en número de ciclos de reloj, los requerimientos hardware
van a variar. Los requerimientos hardware van a determinar, por un lado, el coste en
puertas del diseño resultante y, por otro, el consumo.
Si se hiciera una implementación literal del código VHDL realizando las 32
adiciones en un único ciclo de reloj, se requerirían 31 sumadores y 32*32 puertas
"and" en la implementación directa (con localización de operaciones de ciclo fijo)
I En esta descripción es necesario utilizar un puerto de entrada y otro de salida para el "bus" a fin
de evitar problemas de simulación con señales resueltas del tipo inout.

architecture funcional Qf multiplicador is

begin
process
variable MIl: l,lllsignect (32 downto 1);
variable ~: tinsigned (64 downto O);
alias FA: unsigned (32 downto O) is EAMQ(64 downto 32);
alias A: unsigned (32 downto 1) is downto 32) ¡
EAMQ(63
alias MQ: urislgnéd (32 downto 1) is EAMQ (31 downto O);
begin
wait until reloj = ' l ' and start = ' L' ;
MIl : = databus_m;
wait until reloj = ' 1.' ;
MQ := databus_in;
FA := To_unsigned (0,33);
=
if MQ(1) '1' then
FA := FA + MIl;
end if;
EAMQ := EAMQ sr1 1;
end loop;
ends <= '1';
databus_out <= MQ;
wait until reloj = ' 1; ;
ends <= 'O';
databus_out <= A;
end process;
end funcional;
LISTADO 4-2. Algoritmo hardware de multiplicación de números naturales.
del esquema de la Figura 4-3 que se muestra en la Figura 4-4. El número de suma-
dores es de 31, ya que la primera suma con el acumulador a cero no precisa de un
sumador.
En la mayoría de las ocasiones, esta implementación va a tener un coste excesi-
vo en términos de puertas y consumo. Por otro lado, aunque resulta la más rápida
en términos de ciclos de reloj, el camino crítico es elevado, lo que puede imponer
restricciones intolerables a la frecuencia de la señal de reloj. Este último aspecto
podría solucionarse mediante la realización de la multiplicación combinacional co-
mo operación multiciclo [MLD92].
Al objeto de minimizar los recursos hardware requeridos, una alternativa es la
utilización de un único sumador y la realización de las acumulaciones en ciclos de
reloj sucesivos. La arquitectura RT resultante es la de la Figura 4-5. Se trata de una
típica arquitectura a nivel de transferencia entre registros en la que todas las accio-
nes en cada ciclo de reloj están definidas. Consta de dos unidades. La Unidad de
Datos (UD) incluye los recursos hardware en términos de registros, Unidades Ope-
racionales (UOs) e interconexiones, ya sean "buses" o multiplexores. La Unidad de
4. Síntesis 187
FIGURA 4-4. lógica combinacional para multiplicación en un ciclo.
start
ends
FIGURA 4-5. Arquitectura RT para multiplicación secuencial.

Control (VC) es la encargada de decidir las acciones (microoperaciones) a ejecutar

en la VD en cada ciclo de reloj. La VC se implementa usualmente como una máqui-
na de estados finitos (FSM).
A partir de esta arquitectura, la descripción VHDL para síntesis RT es el Lista-
do 4-3.
En esta arquitectura se ha decidido la ejecución secuencial de las 32 sumas en
32 ciclos de reloj mediante la implementación del lazo en la ejecución cíclica de los
estados sum, de suma y shift de desplazamiento del registro EAMQ. El estado idle
es el estado de espera, getMQ es el estado de captura del multiplicador y endl y
end2 son los estados de finalización en los que se proporciona el resultado por el
"bus" y se retorna al estado de espera.
La obtención automática de esta descripción desde el algoritmo hardware del
Listado 4-2 constituye el objetivo de la síntesis de comportamiento. En el cubo de
diseño de la Figura 4-2 se corresponde con el paso número 1. Dependiendo de los
recursos hardware puestos en juego, cabría un conjunto amplio de implementacio-
nes intermedias entre la implementación combinacional directa de la Figura 4-4 y la
implementación secuencial propuesta. El Listado 4-3 constituye el tipo de descrip-
ción de entrada a las herramientas de síntesis RT-lógica comerciales ampliamente
utilizadas en la actualidad. Este es el tipo de descripción cuyo estudio va a consti-
tuir el objetivo principal de este capítulo.
La síntesis RT-lógica conlleva una serie de procesos de minimización y optimi-
zación los más importantes de los cuales serán comentados posteriormente. Así, los
tipos abstractos y numéricos se codifican en binario. Los tipos compuestos se des-
componen en los "bits" correspondientes. De la descripción de comportamiento se
extraen las asignaciones concurrentes de señal identificando las asignaciones sín-
cronas a biestables, por un lado, y las asignaciones combinacionales, por otro. El
resultado de estas transformaciones, correspondiente al paso 2 en el cubo de diseño,
es el código VHDL del Listado 4-4.
A partir de este tipo de información puede comenzar la minimización lógica.
En este paso es imprescindible tener en cuenta los elementos lógicos disponibles en
la tecnología utilizada. El resultado sería la descripción final que se muestra en el
código del Listado 4-5. Se trata de una descripción estructural en la que los distin-
tos componentes de la biblioteca VITAL se referencian e interconectan entre sí.
En esta descripción los componentes incluyen los retrasos concretos de los ele-
mentos de biblioteca correspondientes. En el cubo de diseño los pasos recorridos
hasta este modelo se corresponden con los números 3, 4 y 5. Por retroanotación de
las características de la topografía, el modelo podría incluir los retrasos concretos
introducidos por las interconexiones.
De todas las descripciones propuestas en el Ejemplo 4.1, las únicas que van a
ser relevantes en la mayoría de situaciones de diseño prácticas son la descripción
inicial (Listado 4-2 o Listado 4_3)2 y final (Listado 4-5). El resto van a ser descrip-
ciones correspondientes a representaciones intermedias del diseño que no van a re-
2 Código del Listado 4-2 en el caso de utilizar una herramienta de síntesis de comportamiento o
del Listado 4-3 en caso de utilizar una herramienta de síntesis RT-lógica.
4. Síntesis 189
architecture FSMDof multiplicador is

begin
process (reset, reloj)
variable MD: unsigned (32 downto 1);
variable EAMQ:unsigned (64 downto O);
type states 18 lidle, getMQ, sum, shift, endl, end2);
variable state: states;
variable 1 ia INl'EGER range O to 31;
begin
if reset :; '1' then
state := idle;
elsif reloj = _'1' and reloj'EVENT then
case state is
when idle =>
if start = '1' then
MD := databus_in;
state := getl(!;
end if;
when getMQ =>
EAMQ(31downto O) := databus_in;
EAMQ(64downto 32) .- (others => 'O.'');
1 := O;
state : = sum;
when sum =>
if EAMQ(O)= '1' then
EAMQ(64downto 32) := EAMQ(64downto 32.) + MD;
end if;
state := shift;
wben shift =>
EAMQ := EAMQsrl 1;
if 1 = 31 then
state := end1;
else
1 := 1 .¡. 1;
state := sum;
end if;
when endl =>
ends <= ~1';,
databua.out <= EAMQ
(63 downto 32);
state : = end2;
wben end2 =>.
ends <= 'O';
databus_out <= EAMQ(31downto O);
state := idle;
end case;
end if;
end process;
end FSMD;
LISTADO 4-3. Descripción RT para multiplicación secuencial.

architecture flujo de datos of multiplicador is

signal MIl: unsigned (32 downto 1);
signal EAM;;): unsigned (64 downto O);
signal state: unsigned (2 downto O);
signal 1: unsigned (4 downto O);
begin
state <=
·000" when reset = '1' else
·001" when reloj =. '1' and reloj'EVENT
and state = "000" and start = '1' else
·010" when rell>j= '1' and reloj'EVENT and state = "001" else
"011" when reloj = '1' and reloj'-EVENT and state = "010" else
·100" when reloj = '1' and reloj'EVENT
and state = ·011" and 1 = 31 else
·010" when reloj = '1' and reloj'EVENT
and state = "011" and 1 /= 31 else
·101" when reloj = '1' and reloj 'EVENT and state = "lOO." else
·000" when reloj = '1' and reloj'EVENT and state :: ·101" el se
state;
databus_out <=
EAMQ(63 downto 32) when reloj = '1' and reloj'EVENT
and state. = ·100' else
EAMQ (31 downto O) when reloj = '1' and reloj' EVOO'
and state = "101" else
databus out; ..
MD <= databus_in when rel(>j";·'l ' and reloj' EVENT
and state :: ·000' and st~ 'F '1' else
MIl;
EAMQ <= ...
;
1 <= ...;
ends <= ...
;
eDd flujo de datos;
LISTADO 4-4. Descripción en flujo de datos del multiplicador secuencial.
querir, en general, de su descripción en VHDL y que sólo van a afectar a los forma-
tos internos de representación del diseño utilizados por la herramienta concreta que
se utilice. En cualquier caso, el ejemplo muestra distintos estilos descriptivos en
VHDL que pueden ser utilizados por el diseñador en la descripción para síntesis de
parte o de la totalidad del circuito.
4.1.2. Modelado para simulación frente a modelado

para síntesis
VHDL fue desarrollado como un lenguaje para el modelado y simulación lógica di-
rigida por eventos discretos de sistemas digitales. Se trata de un lenguaje con una
4. Síntesis 191
architecture estructura of multiplicador is

----- Component NA2 -----
camponent NA2
generic(
TimingChecksOn: J3t)0~ := ~f~ltT.iI!l,i.n9ChechsDn;
XGenerationON: !3oQleaÍ! ':= P¿faúltXGeneraÜonOn;
IÍlstancePath: STRiNG := "~';
tpd...]\,_Q: DelayTypeOl .- fO.340 ns. 0.040 ns);
tpUl_Q: DelayTypeOl . - (O.34Ó'Í)l3, 'l).O(O fis)'¡
tipd_}l.: DéléÍyTypeOl . - "(O ,OOO('ruC'O; OÓOris);
_._"C ... __ ,
tipd_B: nelayTypeOl .- (0.000"11S; 0;000 ns~;

port(
A: in STD_IroIC:
B: in STD_LOGIC;
Q: out STDJ,OOIC);
end camponent;
----- Component DF8 ~--.-

camponent DFB
generic(
TimingChecksOn: Bbolean := DefaultTimingChechsOn;
XGenerationON: s061ean := Defaúltimenefati~nOn';
InstancePath: STRIN:; : = ... ;
tpd_C_Q: DelayTypeOl := (1. 800 ns, 1:890 ns); .
tpd_C_QN: Delay'fypeOl:= (1'.440'1'19, 1.300ns)¡
tsetup_D_C_posedge_posedge: \DelayTypeXX : e .O. 700 ns i
tsetup_D_C_negedge_posedge: DelayTypeXX : = 0.700 ns;
tholcl_D_C_posedge_posedge: DelayTypeXX: = 0.000; ns;
thold_D_C_negedge_negedge: DelayTypeXX: = (). 000 ns] .'
tipd_D: DelayTypeOl .- (0.000 ns, 0.000 n8);
tipd_C: DelayTypeOl :",. «(}~,OOO ns, 0.OQOn8»;
port(
D: in STD..,.ILCIC;:,~
C: in s:ro-r..cx;I~hf
Q: out STD_!fl'IC;,,\,
QN: out STD.)lYftcr;
end camponent;
begin
state_2 : DF8 port map( st¡¡.te;;;.2.2,d, reloj,state(2li ~tU6 )i
state_l : DF8 port map( state.,;,l_d, reloj,státe(í), het25 );
8tate_2.,g1 : NA2 port map(state(1), state(2), net 38};
state_2_I34: NA2 port map(I(4L;L(). state"",tJIl)¡
end estructura;
LISTADO 4-5. Implementación del multiplicador secuencial.

sintaxis amplia y flexible que permite el modelado estructural, en flujo de datos y

algorítmico del comportamiento de un sistema digital conocido y el desarrollo de
modelos de simulación exactos.
En síntesis, la situación es diferente, ya que de una especificación de entrada a
un determinado nivel de abstracción se obtiene una implementación más detallada,
menos abstracta. Aunque el lenguaje utilizado sea el mismo, el desarrollo de una
especificación de un circuito o sistema a un determinado nivel de abstracción con el
objetivo de ser sintetizada resulta conceptualmente diferente al desarrollo de un
modelo para simulación de un sistema ya implementado. Las particularidades deri-
vadas del uso de VHDL en aplicaciones de síntesis se describirán a lo largo de este
capítulo. Estas particularidades se refieren tanto a restricciones sintácticas sobre el
código como a la interpretación semántica del mismo. En el Capítulo 3 se ha hecho
un estudio más detallado de las diferencias y similitudes entre el procesado de un
HDL para simulación y síntesis.
La utilización de una herramienta de síntesis asegura la concordancia funcional
entre la implementación obtenida y la descripción de entrada a partir de la interpre-
tación hardware que la herramienta hace de este código. Aunque desde este punto
de vista el diseño resultaría correcto por construcción, la verificación del proceso de
síntesis por comparación entre los resultados de simulación antes y después de sín-
tesis sigue siendo imprescindible por los motivos que se comentan a continuación.
En consecuencia, tanto la descripción de entrada a la síntesis como la resultante de
la misma deben de ser verificadas por simulación. Simulación es, pues, una tarea
horizontal a un determinado nivel de abstracción. Síntesis, por el contrario, es una
tarea vertical entre niveles de abstracción. Esta diferencia se ha mostrado en la Fi-
gura 1-6 del Capítulo 1 y en la Figura 3-23 del Capítulo 3.
4. 1.3. Objetivos
Las herramientas comerciales actuales cubren las etapas de síntesis RT y lógica.

Desde el momento en que ambas tareas se realizan conjuntamente, para el diseña-
dor aparentan un único proceso de síntesis. Sin embargo, en cada una de estas eta-
pas se aplican algoritmos de síntesis distintos cuyo conocimiento es necesario al ob-
jeto de lograr los mejores resultados. El objetivo principal de este capítulo es el de
describir la utilización de VHDL en síntesis RT-lógica tal y como lo hacen las he-
rramientas comerciales de síntesis disponibles en la actualidad.
4.2. APLICACiÓN DE VHDL EN SíNTESIS
Desde el momento en que la aplicación inicial de VHDL fue el modelado de siste-

mas digitales, su utilización en síntesis no es inmediata. La principal razón de este
hecho reside en la carencia de una semántica hardware en la definición del lengua-
je. Este hecho contrasta con la utilización de VHDL para simulación. En este caso,
la semántica del lenguaje está perfectamente definida y los resultados van a ser in-
dependientes del simulador que se emplee.
4. Síntesis 193
La utilización de VHDL en síntesis presenta dos características principales. Por

un lado, las restricciones sintácticas y semánticas que se imponen al lenguaje. Por
otro, las discrepancias que se van a encontrar entre los resultados de simulación an-
tes y después de síntesis. Ambas características van a ser comentadas a continua-
ción.
4.2.1. Restricciones sintácticas y semánticas
Está generalmente aceptado que VHDL contiene muchas construcciones orientadas

a simulación que resultan difíciles de sintetizar como, por ejemplo, tipos acceso y
fichero, muchos de los atributos predefinidos, etc. De hecho, todas las herramientas
de síntesis actualmente en el mercado imponen restricciones sintácticas al código
VHDL utilizado en la descripción de una arquitectura a nivel RT. Sin embargo, la
mayor o menor orientación a simulación de una determinada construcción, en reali-
dad, su mayor o menor sentido hardware, no constituye, en sí misma, la razón para
que dicha construcción sea o no sintetizable. En principio, cualquier construcción
VHDL es sintetizable desde el momento en el que es simulable. Al fin y al cabo, un
simulador en tiempo real (un emulador) sería una implementación hardware del có-
digo. En consecuencia, el problema no es tanto la posibilidad de sintetizar una de-
terminada construcción sino las prestaciones (coste, velocidad, consumo, etc.) de la
implementación correspondiente. Las restricciones sintácticas y semánticas impues-
tas al código por las herramientas de síntesis provienen de la necesidad de asegurar
una eficacia mínima en el proceso de síntesis.
La eficiencia del proceso de síntesis está relacionada con la identificación del
hardware asociado a un determinado comportamiento, lo que requiere añadir se-
mántica hardware a la descripción. Esta es la razón principal de las restricciones
sintácticas impuestas a la descripción de entrada. Las herramientas de síntesis só-
lo son capaces de sintetizar adecuadamente un determinado subconjunto de
VHDL para el que son capaces de identificar hardware y, en consecuencia, obte-
ner implementaciones eficientes. Un ejemplo lo representa el código VHDL de la
Figura 4-6.
A pesar de su simplicidad, no existe ninguna herramienta de síntesis en la
actualidad que acepte este código. La dificultad principal reside en la identifica-
ción del hardware capaz de realizar la funcionalidad correspondiente, una puerta
ando
Al objeto de asegurar una eficiencia suficiente en el proceso de síntesis, las he-
rramientas imponen restricciones sintácticas en la descripción VHDL de entrada. El
problema que se plantea es la carencia de un subconjunto sintáctico estándar acep-
tado por todas las herramientas de tal forma que cada una impone sus propias res-
tricciones al usuario. En este capítulo destacaremos los elementos comunes, aunque
haremos referencia a las particularidades de las principales herramientas comercia-
les. La principal consecuencia de la carencia de un subconjunto común para síntesis
es la dificultad de reutilización de una descripción desarrollada para una herramien-
ta en otra.
process
begin
if xl = 'O' then
z <= 'O' i
wait en xl;
elsif x2 = 'O' then
z <= 'O';
wait en x2;
else
z <= '1';
wait until xl or x2;
end if;
end process;
X1=[)_Z
X2
FIGURA 4-6. Modelo e implementación de una función ando
4.2.2. Discrepancias entre resultados

de simulación
La segunda característica, propia de la utilización de un lenguaje como VHDL en

síntesis, se refiere a las discrepancias entre los resultados de simulación-antes-de-
síntesis, en la que el comportamiento deseado en la descripción de entrada se vali-
da, y los de la simulación-después-de-síntesis, en la que el comportamiento del
hardware resultante se verifica. Estas discrepancias son de dos tipos, discrepancias
temporales y discrepancias de valor.
Las discrepancias temporales se producen como consecuencia de que durante
el proceso de síntesis se deciden los elementos lógicos que van a componer la ar-
quitectura RT inicial. Estos elementos lógicos (puertas, "latches", biestables, etc.)
llevan asociados retrasos que no se conocían antes de la síntesis. La simulación de
la arquitectura RT es una simulación en ciclos de reloj. La simulación lógica es una
simulación basada en los retrasos concretos de los elementos lógicos en la tecno-
logía de destino. A pesar de estas discrepancias temporales, la corrección del pro-
ceso de síntesis estará asegurada si para cualquier señal A la forma de onda WA)
resultante de la simulación-antes-de-síntesis coincide con la forma de onda WAo re-
sultante de la simulación-después-de-síntesis, al menos en aquellos períodos de
tiempo en los que su valor puede afectar al comportamiento del circuito. En diseño
síncrono, dichos períodos corresponden al tiempo en el que las señales son evalua-
das, usualmente, el tiempo de "set-up" de los biestables. En diseño asíncrono, di-
chos períodos de tiempo están deterininados por las señales de requerimiento y re-
conocimiento en el mecanismo de interfase correspondiente (Figura 4-7).
4. Síntesis 195
Forma de onda WA1

(antes de síntesis)
t
i
I
I¡
1' : "
"
::,
::
,
-i--~--------- ---_;_---~-~
Forma de onda WAo + ,

(después de síntesis) nL-__¡__---I¡_-_¡__I--:.-----" __ -+__
: Período de : t
.comcarecícn :
FIGURA 4-7. Discrepancias temporales.
Las discrepancias entre los resultados de simulación-antes-de-síntesis y los de

la simulación-después-de-síntesis pueden afectar también a los valores de las seña-
les. Estas discrepancias de valor se producen por dos motivos. Por un lado, como
consecuencia de la codificación lógica, usualmente std __ulogic o bit de tipos de
datos enumerados y enteros. Por otro, por la interpretación en síntesis de los meta-
valores de los tipos y std_ulogic que se comentará posteriormente. A
pesar de estas discrepancias de valor, la corrección del proceso de síntesis estará
asegurada si para cualquier señal A la forma de onda WAo resultante de la simula-
ción-después-de-síntesis es un caso particular de la forma de onda WA¡ resultante
de la simulación-antes-de-síntesis una vez las discrepancias temporales han sido
consideradas, como en el ejemplo de la Figura 4-8.
En el caso general, estas discrepancias entre el comportamiento esperado y el
resultante son peligrosas y pueden dar lugar a implementaciones erróneas. Es nece-
sario, por ello, establecer una metodología de uso de la herramienta de síntesis
VHDL que se vaya a emplear a partir del conocimiento de la semántica y los algo-
ritmos que utilice en cada etapa de síntesis.
4.3. SíNTESIS RT-LÓG1CA
En este apartado se hace una breve introducción a los modelos de sistema digital utili-
zados por las herramientas de síntesis y a los pasos de síntesis que aplican. Síntesis
RT y síntesis lógica utilizan modelos y algoritmos distintos. Sin embargo, desde el
momento en que ambas tareas se realizan conjuntamente en las herramientas de sínte-
sis actuales, para el diseñador aparentan un único proceso. Al objeto de lograr los me-
jores resultados es importante el conocimiento de los pasos concretos en cada caso.
Forma de onda WA,

(antes de síntesis)
Forma de onda WAo

(después de síntesis) ¡---
,
, Período de: t
: comparación:
FIGURA 4-8. Discrepancias de valor.
4.3.1. Síntesis lógica

El modelo de sistema digital utilizado por las herramientas de síntesis es el modelo
general de máquina secuencial síncrona de Huffman constituido por un bloque de
lógica combinacional y un conjunto de elementos de memoria que almacenan el es-
tado actual de la máquina según el esquema clásico de la Figura 4-9.
El proceso de síntesis lógica se divide usualmente en dos pasos:
• optimización,
• mapeado tecnológico.
En el proceso de optimización, las ecuaciones lógicas son transformadas al ob-
jeto de satisfacer las restricciones de diseño en cuanto a área, velocidad, consumo,
etcétera. En el proceso de mapeado tecnológico los elementos de la biblioteca en la
tecnología utilizada (celdas estándar, mar de puertas, FPGA, PLD, etc.) se seleccio-
nan e interconectan al objeto de satisfacer la funcionalidad y las restricciones de di-
seño. Ambas tareas, optimización lógica y mapeado tecnológico, son realizadas efi-
cientemente por las herramientas de síntesis comerciales disponibles en la actuali-
dad y, de hecho, constituyen el núcleo principal de las mismas.
4.3.2. Síntesis RT
El modelo de sistema digital utilizado por las herramientas de síntesis a nivel RT es
una extensión 3 del modelo de Huffman constituido por dos unidades:
3 Se trata de una extensión en el sentido de que siempre puede obtenerse el modelo de Huffman
equivalente.
4. Síntesis 197
Entradas I i> I
v
Salidas
Lógica
combinacional
1---
~
Señales d e Señales de
estado actu al est ado próximo
Elementos
de
memoria <j
/\
¡
Je, R1...
Reloj
FIGURA 4-9. Máquina secuencial síncrona de Huffman.
• la Unidad de Control (UC), y

• la Unidad de Datos (UD),
según el esquema de la Figura 4-10.
En la Unidad de Datos es donde tienen lugar las distintas operaciones, transfe-
rencias de información y almacenamiento de datos en registros. La UD se constitu-
ye usualmente de unidades operacionales (OPs), buses, multiplexores y elementos
de memoria como latches, registros y módulos RAM y ROM4•
La Unidad de Control es la encargada de decidir en cada ciclo de reloj las
transferencias de información que deben de tener lugar entre registros en la UD así
como el siguiente estado de control a ejecutar. La UC se diseña usualmente como
una máquina de estados finitos (FSM).
El proceso de síntesis RT se divide usualmente en dos pasos:
• síntesis de la UD,
• síntesis de la Ue.
La síntesis de la Unidad de Datos (UD) se divide usualmente en tres pasos:
• optimización aritmética,
• identificación de los elementos de memoria,
• extracción de las funciones lógicas.
4 Los módulos de memoria RAM y ROM son considerados como externos a la descripción RT
por la mayoría de herramientas de síntesis.

Secuencíación
UNIDAD "-
Entradas
de control I
i)
v DE CONTROL I
Salidas
de control
~r
Señales Señales
del status de control
Q
Entradas
de datos I l> UNIDAD
DE DATOS I Salidas
de datos
Cómputo
FIGURA 4-10. Modelo de sistema digital a nivel RT.
Estos pasos dependen fuertemente del estilo descriptivo utilizado. Por lo gene-
ral, la herramienta de síntesis realiza la extracción desde el código VHDL perdien-
do la información de alto nivel de partida. Su recuperación requeriría comenzar de
nuevo el proceso de síntesis desde la descripción VHDL. Este es uno de los moti-
vos por los cuales el estilo descriptivo utilizado en el código VHDL de entrada tie-
ne trascendencia en cuanto a los resultados de la síntesis. Es importante, por ello,
conocer los mecanismos empleados por la herramienta de síntesis que se esté utili-
zando al objeto de asegurar resultados óptimos. Un caso típico lo representan los
operadores aritméticos y las asignaciones indiferentes. Sin embargo, hay herramien-
tas que identifican los operadores aritméticos como componentes durante el proceso
de síntesis. De esta manera, son capaces de conservar parte de la información de al-
to nivel durante el proceso de optimización lógica, permitiendo, por ejemplo, cam-
biar el tipo de implementación del operador. Esta misma situación se presenta con
los elementos de memoria. Una vez inferidos, su repercusión en el diseño no se
puede evitar durante el proceso de síntesis.
La síntesis de la Unidad de Control (UC) consiste fundamentalmente en la
identificación y síntesis del autómata de control y se divide usualmente en tres pa-
sos:
• identificación del autómata de control (estados y transiciones),
• minimización de los estados de control,
• asignación secundaria.
De nuevo, en general, se trata de transformaciones destructivas respecto a la in-
formación de entrada. Sin embargo, algunas herramientas marcan el registro de es-
tados, lo que permite conservar esta información de alto nivel. Tanto los algoritmos
de minimización de estados, sobre todo en el caso de máquinas incompletamente
4. Síntesis 199
especificadas, como, particularmente, los de asignación secundaria, están limitados

en cuanto al tamaño de la Máquina de Estados Finitos (FSM) que son capaces de
manejar y en cuanto a su eficiencia. Siempre que el diseñador sepa de antemano la
implementación óptima en cuanto al número mínimo de estados y su codificación
binaria, debe forzarlas desde la descripción VHDL de entrada.
4.4. DESCRIPCIÓN VHDL DE CIRCUITOS DIGITALES
En este apartado se detalla la descripción en VHDL de los componentes funda-

mentales de un sistema digital. Este conocimiento es imprescindible a la hora de
asegurar que la implementación propuesta por la herramienta de síntesis coincide
funcionalmente con la que se desea. Como ya se ha comentado, la carencia de una
metodología estándar de síntesis desde VHDL impide una descripción general del
uso del lenguaje en síntesis sin hacer referencia a particularidades y excepciones
concretas propias de determinadas herramientas y no de otras. Este apartado pre-
tende ser 10 más general posible, de tal forma que las recomendaciones de diseño
que incluye sean válidas independientemente de la herramienta que se utilice. El
objetivo de este texto es asegurar que el lector, con un mínimo esfuerzo adicional
de conocimiento de la herramienta concreta que utilice, esté en disposición de ob-
tener los mejores resultados de la misma en un tiempo breve.
4.4.1. Descripción del sistema
El sistema digital a sintetizar se va a describir mediante una arquitectura asociada a

una determinada entidad en la que se definen los puertos del sistema. El proceso de
síntesis generará una nueva arquitectura asociada a la misma entidad.
Tal y como se ha visto en el Capítulo 2, la arquitectura VHDL está compuesta
de las siguientes sentencias concurrentes:
• sentencias de aserción concurrente que son ignoradas,
• bloques,
• llamadas concurrentes a procedimientos,
• asignaciones concurrentes de señal,
• referencia a componentes,
• procesos, y
• sentencias de generación que se sustituyen por el código iterativo equiva-
lente.
Salvo en lo que respecta a las sentencias de referencia a componentes, la jerar-
quía se elimina por defecto y todas las asignaciones de señal resultantes y llamadas
a procedimientos se sustituyen por los procesos equivalentes. En algunas herra-
mientas, sin embargo, el usuario puede identificar como componentes de distinto
nivel de jerarquía el código asociado a un proceso, bloque o subprograma. Los ope-
radores aritméticos son tratados como componentes adicionales y optimizados inde-
pendientemente. En algunos casos, la herramienta posee la capacidad de asociar va-

rias operaciones aritméticas a la misma unidad operacional con objeto de minimizar
la lógica resultante (" resource sharing"). Las referencias a componentes hacen re-
lación a otras entidades que, usualmente, se sintetizan conservando o eliminando la
jerarquía mediante directivas de usuario a la herramienta.
4.4.2. Modelado de la información
De las cuatro categorías de tipos definidos en el estándar, sólo los tipos escalares y
compuestos son usualmente soportados. De las cuatro categorías de tipos escalares
definidos en el estándar, sólo los enteros y enumerativos son usualmente soportados
en síntesis. Los tipos físicos y flotantes o son ignorados o no son admitidos.
Los tipos enteros se sintetizan como vectores de bits con la dimensión adecua-
da al rango con que se han definido. Si el rango incluye valores negativos, la con-
versión suele hacerse en complemento a 2, en caso contrario en binario sin signo.
Así, la señal entera Temperature:
signal Terrperature is Integer range - 75 te 120;
se implementaría en un conjunto de 8 bits:

8
Z' t>
con la siguiente codificación:
-75 => 10110101

-74 => 16110110
~:
119 => oiuciu
120 => 01111000
Los tipos enumerativos se sintetizan como vectores de bits con la dimensión

adecuada al número de valores distintos con que se hallan definido. La codificación
suele ser en binario con valores crecientes siguiendo el orden de la declaración.
Aunque normalmente es preferible realizar la asignación secundaria directamente
durante el proceso de síntesis, algunas herramientas permiten al usuario la codifica-
ción del tipo mediante un atributo:
attribute enum_encoding: string;

type color is (RED, GREEN, YELI.Gl, BLUE, VIOÍ..E.'l');
attribute enum_encoding of color: type iB ·OlÓ' 000 on 100 001·;
--RED = ·010·
--GREEN = ·000·
--YELLOW = ·011·
4. Síntesis 201
Un caso especial 10 representan los tipos enumerativos con semántica hardwa-

re. Los más importantes son los tipos std_logic y std_ulogic del paquete estándar
Std_Logic_1l64, soportado por todas las herramientas comerciales. Sin embargo,
cada una de ellas tenía una interpretación diferente de los valores definidos en los
tipos estándar y trataba de forma distinta las asignaciones, comparaciones y senten-
cias condicionales en los que intervienen objetos de este tipo. Esta situación ha
cambiado con la publicación del estándar IEEE P1076.3-1996 "Standard VHDL
Synthesis Packages" [IEEE96] que se comenta a continuación.
Con respecto a los tipos compuestos, la mayoría de las herramientas de síntesis
soportan matrices unidimensionales, usualmente de bits y en algún caso de enteros.
El tipo registro (record) es soportado por muy pocas herramientas.
4.4.3. Funciones y operadores
La mayoría de herramientas comerciales soportan los operadores VHDL estándar

sobre los tipos de datos aceptados por la herramienta, salvo los de multiplicación,
división, resto, módulo y elevación a potencia. En general, estos últimos sólo se
permiten si ambos operadores son constantes. Algunas herramientas soportan la
multiplicación y la división generando el módulo de lógica combinacional corres-
pondiente. Otras herramientas sólo admiten multiplicaciones y divisiones por cons-
tantes potencia de dos implementando la operación como un desplazamiento a iz-
quierda o derecha respectivamente. Algunas herramientas soportan la operación
módulo de una potencia de 2. Como se verá más adelante, esta operación es útil en
la descripción de contadores.
Las funciones de usuario están usualmente permitidas, siempre que no hagan
overloading de funciones predefinidas. Las funciones de resolución de usuario no
están normalmente permitidas y es necesario, usualmente, recurrir a las funciones
predefinidas en la herramienta.
Todas las herramientas de síntesis incluyen paquetes de funciones aritméticas y
lógicas sobre vectores de los tipos bit, std_logic y std_ulogic. Dado que los paque-
tes eran distintos de unas herramientas a otras, ésta ha sido una de las principales
causas de no-portabilidad entre herramientas distintas. Este problema ha sido supe-
rado recientemente con los paquetes aritméticos estándar incluidos en el estándar
IEEE PI076.3-l996.
4.4.4. Paquetes de síntesis P1076.3
Con el objetivo de avanzar en la interoperabilidad entre herramientas de síntesis, se

constituyó el grupo de estandarización IEEE 1076.3 "Standard VHDL Synthesis
Packages". Aprobados en febrero de 1997, los paquetes de síntesis cubren las si-
guientes áreas:
4.4.4.1. Interpretación hardware de tipos estándar

En esta sección se define el modo en el que la herramienta de síntesis debe de inter-
pretar los valores de los tipos lógicos estándar. Los tipos lógicos estándar conside-
rados son los siguientes:
type Bit la ('O', '1');

type Boolean la (False, True);
type StéLUlogic 1s ('U', - Valor no inicializado
'X', - Valor fuerte desconocido
'O', - 0, fuerte
'1', - 1 fuerte
'Z', - Alta inpedancia
'W', - Valor debil desconocido
'L', - O ~debil
'H', - 1 debil
'r", - indiferE!b:te (Odon't care")
);
4.4.4.1.1. Interpretación de los valores lógicos fuertes

('O', '1', false, true)
La herramienta de síntesis debe de interpretar los siguientes valores:
• 'O' del tipo Bit.
• False del tipo Boolean.
• 'O' del tipo Std_Ulogic.
como representación del nivel lógico correspondiente a la tensión de referencia nor-
malmente denominada tierra. Así, por ejemplo, la asignación:
S <; x or 'O';
sería equivalente al circuito de la figura:
x-p-s
La herramienta de síntesis debe de interpretar los siguientes valores:
• '1' del tipo Bit.

• True del tipo Boolean.
• '1' del tipo Std_Ulogic.
como representación del nivel lógico correspondiente a la tensión de alimentación,
denominada usualmente Vce O V DO. Así, por ejemplo, la asignación:
s <= x and '1';

4. Síntesis 203
sería equivalente al circuito de la figura:
x---=O-s
4.4.4.1.2. Interpretación de los valores lógicos
débiles ('L', 'H')
El estándar 1076.3 no especifica ninguna interpretación para los valores lógicos dé-
biles 'L' y 'H' del tipo Std_Ulogic. El hecho es que las herramientas comerciales
actuales, o no soportan estos valores o los tratan de forma idéntica a los valores
fuertes 'O' y '1' respectivamente. Al objeto de no restringir tecnologías futuras en
las que sea relevante diferenciar en síntesis la fuerza asignada al valor de una señal,
se decidió no forzar una interpretación en la actualidad.
4.4.4.1.3. Interpretación de los valores metalógicos débiles

('U', 'W', 'X', '-')
La utilización de los valores metalógicos 'U', 'W' y 'X' carece de sentido en sínte-
sis. Sin embargo, en una descripción VHDL para síntesis cabe la utilización de
estos valores en la simulación del código. Aunque el valor indiferente '-' sí tiene
sentido en síntesis, su interpretación estándar es idéntica a la del resto de valores
metalógicos, salvo en la función Std-Match. La herramienta de síntesis debe de so-
portar la utilización de estos valores con la siguiente interpretación:
• Si uno de los operandos en una igualdad es un valor metalógico estático 5 o
un vector en el que uno de los elementos es un valor metalógico estático, la
herramienta de síntesis debe de interpretar la igualdad como falsa. De esta
forma, para la herramienta de síntesis, el conjunto de sentencias VHDL si-
guiente:
if s = ·0010-01" then
z <= 'O';
else
z <= '1';
end if¡
es equivalente a:
z <= '1';
Este ejemplo puede parecer chocante, ya que la comparación de '-' con cual-
quier otro valor debería evaluarse siempre como cierta. Sin embargo, los
5 Estático significa que el operando es un literal 'U', 'W', 'X' o '-'. Dinámico se utilizaría en el
caso de que el operando fuera una variable o señal que, en tiempo de simulaci6n, tomara uno de los va-
lores metal6gicos.
operadores de comparación definidos en el paquete Std_Logic_1J64 no tra-

tan al valor '-' de esta manera. La misma equivalencia se habría establecido
si en vez del valor metalógico '-' se hubiera utilizado cualquier otro.
• En el caso de tratarse de una desigualdad, ésta se evaluaría como cierta. Así,
para la herramienta de síntesis, el conjunto de sentencias siguiente:
if s /= ·0010X01" then
z <= 'Ol} 'r.
else
z <= '1';
end if;
es equivalente a:
z <= 'o' i
• En el caso de que se utilice un valor metalógico como alternativa o como

elemento en una alternativa en una sentencia secuencial de selección (case),
la herramienta de síntesis debe de considerar que dicha alternativa no puede
ejecutarse nunca. El código sería equivalente a la eliminación de dicha alter-
nativa:
case s is
when ·ooo··,;,~
z <= 'o' i
when '001" =>
z <= '1 '-;
when '0--" =>
z <= xl;
when others =>
z <= x2;
end case;
es equivalente a:
case s is
when '000' =>
z <= 'O';
when '001' =,>
z <= '1';
when others =>
z <= x2;
end case;
• La utilización de valores metalógicos en sentencias de asignación de señal

seleccionada tienen la interpretación que corresponde a la conversión de la
asignación concurrente en la sentencia secuencial de selección equivalente.
• La utilización de valores metalógicos estáticos como operando o elemento de
operando en una operación lógica, aritmética o de desplazamiento en la que
el otro operando no es un valor estático, debe de considerarse como un error.
4. Síntesis 205
• La utilización de un valor metalógico en operaciones de concatenación, con-

versión de tipo y de extensión de signo está permitida en síntesis sin ninguna
interpretación especial.
• La utilización de un valor metalógico como forma de onda o parte de una for-
ma de onda en una sentencia de asignación está permitida. El estándar no espe-
cifica ninguna interpretación particular para el valor metalógico en este caso 6.
4.4.4.1.4. Interpretación del valor de alta impedancia (IZI)

La utilización del valor estático 'Z' en una forma de onda implica la inferencia de
un buffer triestado habilitado por la condición de control de la asignación. La salida
del buffer sería el objeto (señalo variable) destino de la asignación. La entrada al
buffer sería la lógica correspondiente al valor del destino aparte de cualquier asig-
nación a 'Z'. Así, por ejemplo, el siguiente código:
y <= yl&y2;
with y select
z <= xl and x2 when '00",
'Z' when "01",
'Z' when "lO",
xl when "11";
se correspondería con el circuito de la figura:
Cualquier otra ocurrencia de un valor estático de alta impedancia tiene el mis-

mo tratamiento que el de un valor metalógico en la misma situación.
4.4.4.2. Expresiones de valor inicial y por defecto

Las herramientas de síntesis deben de aceptar expresiones de valor inicial en decla-
raciones de variable y de valor de defecto en declaraciones de señal pero no se
requiere ninguna interpretación para este tipo de construcciones. Tal y como
se comentará posteriormente, el diseñador debe de evitar que el comportamiento
del código VHOL dependa de este tipo de expresiones.
6 La mayoría de las herramientas de síntesis interpretan los valores metalógicos como indife-
rentes.
4.4.4.3. Detección de la transición activa de la señal de reloj
Independientemente de las expresiones particulares que la herramienta de síntesis

utilice para representar la transición activa de la señal de reloj, debe también sopor-
tar las funciones Rising_Edge y Falling_Edge para representar las transiciones de
subida y bajada respectivamente. Estas funciones se definen en el paquete Std_Lo-
gic_1164 sobre los tipos std_logic y std_ulogic y en el paquete Numeric_Bit sobre
el tipo bit.
4.4.4.4. Paquetes aritméticos
Uno de los principales motivos de incompatibilidad entre herramientas de síntesis

lo representan los paquetes aritméticos soportados por cada herramienta. Estos pa-
quetes incluyen, principalmente, operadores aritméticos sobre. vectores de Bits o
Std_Logic. Aparte de su utilidad en síntesis, estas funciones permiten acelerar la si-
mulación de la descripción, ya que pueden ser identificadas y sustituidas por fun-
ciones compiladas previamente ("built-in").
Los paquetes aritméticos son dos y utilizan los mismos tipos Signed y Unsig-
ned:
• El paquete Numeric Bit define operaciones sobre vectores de tipo Bit:
type Unsigned i8 array (Natural range <» of Bit;

type Signed i8 array (Natural range <» of Bit;
• El paquete Numeric_Std define operaciones sobre vectores de tipo Std_

Ulogic:
type unsigned La array (Natural range -o- of Std_Logic;

type Signed i8 array (Natural range <» of Std_Logic;
Ambos paquetes interpretan el tipo Unsigned como la representación en bina-

rio de un número natural. El tipo Signed representa en complemento a 2 un número
entero. En particular, un valor de tipo Signed de un único bit representaría los valo-
res numéricos -1 y O. En ambos casos, el bit más significativo es el situado a la iz-
quierda. Los paquetes permiten utilizar en los operadores argumentos izquierdo o
derecho de tipo Unsigned y Natural o de tipo Signed e Integer. Esto hace que cada
función binaria esté repetida seis veces en cada paquete. Al objeto de facilitar el
cambio de un paquete a otro, la mayoría de las funciones definidas en un paquete se
definen también en el otro. Concretamente, las funciones recogidas en las siguien-
tes tablas son comunes:
4. Síntesis 207
Funciones 7
Descripción Operandos Resultado
aritméticas
"abs" valor absoluto Signed Signed

"" cambio de signo Signed Signed
"+" adición Unsigned- Unsigned Unsigned
Signed-Signed Signed
Unsigned-Natural Unsigned
Signed-Integer Signed
"" substracción Unsigned-Unsigned Unsigned
Signed-Integer Signed
"*,, multiplicación Unsigned-Unsigned Unsigned
Signed- Integer Signed
rr división Unsigned- Unsigned Unsigned
(si el segundo Signed-Signed Signed
argumento es nulo, Unsigned-Natural Unsigned
se produce un ERROR) Signed- Interger Signed
"rem" resto Unsigned- Unsigned Unsigned
argumento es nulo, Unsigned-Natural Unsigned
se produce un ERROR) Signed-Integer Signed
"mod" módulo Unsigned-Unsigned Unsigned
argumento es nulo, se Unsigned-Natural Unsigned
produce un ERROR) Signed-Integer Signed
Funciones de
Descripción Operandos 7 Resultado
comparación
">" mayor Unsigned-Unsigned Boolean

Signed-Signed Boolean
Unsigned-Natural Boolean
Signed- Integer Boolean
"<" menor Unsigned-Unsigned Boolean
Signed-Integer Boolean
7 Las funciones son conmutativas respecto del tipo, ya que están definidas también para el orden
opuesto de los tipos de los operandos.

Funciones de
comparación
"<=" menor o igual Unsigned-Unsigned Boolean

">=" mayor o igual Unsigned- Unsigned Boolean
"=" igual Unsigned- Unsigned Boolean
"/=" distinto Unsigned- Unsigned Boolean
Funciones de 8
desplazamiento
Shift_Left desplazamiento Unsigned- Natural Unsigned

a izquierda Signed-Natural Signed
Shift_Right desplazamiento Unsigned-Natural Unsigned
a derecha Signed-Natural Signed
Rotate_Left rotación Unsigned-Natural Unsigned
Rotate_Right rotación Unsigned-Natural Unsigned
"sIl" desplazamiento Unsigned-Natural Unsigned
"srl" desplazamiento Unsigned-Natural Unsigned
"rol" rotación Unsigned-Natural Unsigned
"ror" rotación Unsigned-Natural Unsigned
8 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando

representa el número de desplazamientos a efectuar sobre el primer operando.
4. Síntesis 209
Funciones lógicas Descripción Operandos Resultado
"not" complementación Unsigned Unsigned

Signed Signed
"and" función lógica "y" Unsigned-Unsigned Unsigned
bit a bit Signed-Signed Signed
"or" función lógica "o" Unsigned-Unsigned Unsigned
"nand" función lógica "no-y" Unsigned- Unsigned Unsigned
"nor" función lógica "no-o" Unsigned- Unsigned Unsigned
"xor" función lógica "0- Unsigned- Unsigned Unsigned
exclusiva" bit a bit Signed-Signed Signed
"xnor" función lógica "no-o- Unsigned-Unsigned Unsigned
exclusiva" bit a bit Signed-Signed Signed
Funciones de 9
conversión
Resize re-dimensionado Unsigned-Natural Unsigned

de un vector Signed-Natural Signed
To_Integer conversión Unsigned Natural
a entero Signed Integer
To_Unsigned conversión a Unsigned Natural-Natural Unsigned
To_Signed conversión a Signed Integer-Natural Signed
Adicionalmente a estas funciones, el paquete Numeric_Bit incluye las funcio-

nes Rising_Edge y Falling_Edge para señales de tipo Bit. Las funciones correspon-
dientes sobre el tipo Std_Ulogic son las definidas en el paquete Std_ Logic_1l64.
Por otro lado, el paquete Numeric_Std incluye la función de traslación:
Función de
traslación
To_Ol Conversión a ° o 1 Unsigned-Std_Logic

Signed-Std_Logic
Unsigned
Signed
representa el tamaño del vector resultante.

representa el valor a asignar cuando se detecta una discrepancia (por defecto 'O').
que convierte los valores 'H' en '1' Ylos valores 'L' en 'O'. Cualquier otro valor es
convertido en el valor definido por el segundo argumento de la función ('O' por de-
fecto).
Como ya se ha comentado anteriormente, ni en las funciones de comparación
VHDL estándar ni en las incluidas en el paquete Std_Logic_ll64 en el que se define,
el valor '-' tiene un tratamiento especial como valor indiferente. Al objeto de propor-
cionar un mecanismo de comparación en el que el valor '-' actúe efectivamente co-
mo valor indiferente, el paquete Numeric_Std incluye la función Std_ Match. Así:
Std,_Match (·01W:OL1ZUUH·, ·IlH)-1-1·) = '1.';
Sin embargo:
StQjMatch (·01UXOL1ZUUH·, ·LHU-0-1-1·) = 'O';
Std_Match Comparación Std_ Ulogic-Std_ Ulogic Boolean

con utilización del Std_Logic_ Vector-Std_Logic_ Vector Boolean
valor indiferente Std_Ulogic_ Vector-Std_Ulogic_ Vector Boolean
Unsigned- Unsigned Boolean
4.4.5. Descripción de lógica combinacional
En VHDL, la lógica combinacional puede ser descrita mediante asignaciones con-

currentes de señalo procesos'f. Un conjunto de asignaciones concurrentes de señal
describen lógica combinacional siempre que:
a) La señal destino no interviene en la forma de onda de ninguna asignación.
Así, por ejemplo, la asignación:
a <= b and e when e = 'o' e1se '1';
se corresponde con lógica combinacional. Una posible implementación se-

ría el circuito de la Figura 4-11.
Por el contrario, las asignaciones:
a <= b and e when a = 'o' e1se '1';
a <= b and e when e = 'O' e1se a;
se corresponden con lógica secuencial.
representa el valor a asignar cuando se detecta una discrepancia (por defecto 'O').
12 Como ya hemos comentado anterioimente, para cualquier asignación concurrente existe un
proceso equivalente.
4. Síntesis 211
FIGURA 4-11. Implementación de asignación combinacional.
b) El conjunto de asignaciones concurrentes no contiene lazos combinaciona-

les. Así, el conjunto de asignaciones:
d <= b and C;
a <= d ar e;
constituyen una descripción alternativa de la implementación de la Figu-

ra 4.11. Por el contrario, las asignaciones:
d. <= banda;
a <= d ar e;
no, ya que la señal a se realimenta como entrada del circuito.

Tanto las asignaciones de señal seleccionadas como condicionales son soporta-
das. La asignación de señal seleccionada se corresponde funcionalmente con un
multiplexor en el que la expresión se corresponde con la señal de control. Ésta será
la implementación final, siempre que durante el proceso de optimización no se en-
cuentre una implementación alternativa mejor en términos de coste o velocidad.
Así, por ejemplo, el código siguiente:
y <= y1&y2;
with y select
z <= xl and x2 when "OO·,
xl when "01·,
x2 when "lO",
'1' when "11";
Tendría una implementación directa con el multiplexor 4 x 1 de la Figura 4-12.

Sin embargo, dependiendo de las restricciones de diseño, la implementación de
la Figura 4-13 puede ser preferible en un diseño dado.
La asignación de señal condicional se corresponde funcionalmente con una ca-
dena de multiplexores 2 x 1 en el que las condiciones se corresponden con las seña-
les de control. Ésta será la implementación final, siempre que durante el proceso de
optimización no se encuentre una implementación alternativa mejor en términos de
coste o velocidad. Así, por ejemplo, el código siguiente:
z <= xl and x2 when y1 = 'O' and y2 = 'O' e1se
xl when y1 = 'O' else
x2 when y2 = '0' else
'1' ;
x2-_,_----l
'-------110
'1' --------1
y1 y2
FIGURA 4-12. Implementación directa de asignación seleccionada.
Tendría una implementación directa con la cadena de multiplexores de la Figu-

ra 4-14.
Sin embargo, dependiendo de las restricciones de diseño, la implementación de
la Figura 4-13 puede volver a ser preferible en un diseño dado.
Algunas herramientas soportan el agrupamiento de sentencias concurrentes en
bloques. Como ya se ha comentado, las herramientas eliminan usualmente la jerar-
quía. Los bloques con señal de guarda pueden ser usados en la descripción de buses
en algunas herramientas:
signal z : ... bus; ...
tri: block (en = 'l')
begin
z <= guarded QSIM_STATE_RESOLVED_X_VECTQR (temp);
end block tri;
x1-~---l
x2-+-_"'--l
y1--~---J
y2---4---l
FIGURA 4-13. Implementación alternativa de asignación seleccionada.

4. Síntesis 213
FIGURA 4-14. Implementación directa de asignación condicional.
A partir de los paquetes de síntesis, la utilización del valor std_logic 'Z', impli-
ca la descripción de un buffer triestado:
z <= temp when (en = '1') e1se 'Z';
En algunas herramientas los buses se pueden describir mediante asignaciones

del valor "null":
z <= temp when (en = '1') e1se null;
En este caso, la señal 'z' tiene que ser de clase bus, al igual que ocurría cuando
se utilizaba un bloque guardado. En cualquiera de los anteriores casos, el resultado
es un buffer tri-estado:
en
La segunda forma de describir lógica combinacional es mediante procesos. Un

proceso describe lógica combinacional siempre que:
a) Todas las señales utilizadas en la forma de onda de alguna de las asignaciones

secuenciales de señal o variable se incluyen en la lista de sensibilidad del pro-
ceso. Así, por ejemplo, el proceso siguiente:
process (b, c, e)
variable d: ...;
begin
d := b and e:
a <= dore;
end process;
cumple la condición. En algunas herramientas se admite igualmente el pro-

ceso equivalente al anterior, es decir, un proceso en el que la lista de sensi-
bilidad es reemplazada por una sentencia wait equivalente:
process
variable d: ...;
begin
d := b and C;
a <= d or e;
wait en b, c, e;
end process;
Esta es la única sentencia wait permitida en este tipo deprocesos, En ambos

casos, la lógica descrita podría implementarse con el circuito de la Figura 4-11.
Algunas herramientas de síntesis ignoran la lista de sensibilidad. El proceso se
considera combinacional cuando carece de sentencias de espera y secuencial en ca-
so contrario. Este hecho puede provocar discrepancias entre los resultados de simu-
lación antes y después de síntesis adicionales a las consideradas con anterioridad.
b) Bajo cualquier condición de ejecución del proceso, todas las variables y se-
ñales son asignadas. Así, por ejemplo, el proceso siguiente:
process (b, c, e)
variable d: ...;
begin
if (b = ~1') then
d := C;
else
d := '0';
end if;
a <= dore;
end process;
constituye una descripción alternativa a la implementación de la Figura 4-11.
Por el contrario, en el proceso siguiente la variable "d" no cumple la condición:
process (b, e, e)
variable d: ... ;
begin
if (b = '1') then
d := C; .
end if;
a <= dore;
end process;
LISTADO 4-5. Código secuencial.

4. Síntesis 215
Un caso que es interesante citar aquí lo constituyen los procesos en los que una va-
riable es utilizada antes de ser asignada como en el proceso siguiente:
process (input)
variable var: stQ_ulogic.;
begin
output <= varo
var : = input;
end process;
El resultado de la síntesis de este proceso es idéntico al del proceso siguiente

(una conexión directa entre input y output):
process (input)
variable var: st<t.ulogic;
begin
var : = input;
output <= varo
end process;
Sin embargo, su simulación da resultados completamente distintos. Se trata,

por tanto, de situaciones que conviene evitar. En algunas herramientas este tipo de
situaciones no están permitidas. En otras, la herramienta avisa de la discrepancia
entre simulación y síntesis.
La descripción combinacional mediante procesos es mucho más flexible que me-
diante asignaciones a señal concurrentes. La causa de este hecho reside en la mayor
flexibilidad del código secuencial en VHDL que la del código concurrente. Mientras
la estructura de una asignación a señal seleccionada está fija, su equivalente secuen-
cial, la sentencia case, permite incluir cualquier tipo de código secuencial en cada al-
ternativa. Esta mayor flexibilidad es posible encontrarla también en la sentencia
if...then ... else frente a la sentencia de asignación condicional. En consecuencia, aun-
que también aquí es posible encontrar una relación funcional entre el código y el
hardware, esta relación suele ser menos directa que en el caso concurrente.
Así, por ejemplo, el código:
process .. ..
variable y : BN_vecto~ '(~;~O 2);
begin
y := y1&y2;
case y is
when '00' =>
z <= xl and x2;
when "01" =>
z <= xl;
when "lO' =>
z <= x2;
when "11" =>
z <= '1';
end case;
end process;
tendría como implementación directa el multiplexor 4 x 1 de la Figura 4-12. Sin

embargo, dependiendo de las restricciones de diseño, la implementación de la Figu-
ra 4-13 puede volver a ser preferible. De la misma forma, la implementación direc-
ta del código siguiente sería la cadena de multiplexores de la Figura 4-14. Sin
embargo, dependiendo de las restricciones de diseño, la implementación de la
Figura 4-13 puede volver a ser preferible en la mayoría de los casos. Es importante
destacar que la síntesis asegura la correspondencia funcional entre la descripción de
entrada y la implementación lógica resultante con las discrepancias temporales y de
valor comentadas anteriormente. Sin embargo, la implementación concreta en puertas
va a depender de las restricciones de diseño impuestas y de la tecnología utilizada.
process
begin
if (yl = 'o' and y2 = 'O') then

z <= xl aDd x2;
elaif (yl = 'O') then
z <= xl;
elsif (y2 = 'O') then
z <= x2¡,
else
z <= '1' i
end if;
end process;
Los lazos constituyen una construcción que añade flexibilidad a la descripción

de lógica mediante un proceso. Sin embargo, hay herramientas que no los soportan.
Algunas herramientas soportan los lazos de tipo for siempre que se puedan descom-
poner en una secuencia de sentencias equivalente. Su implementación será la de di-
cha secuencia de sentencias. Los lazos de tipo while son soportados por muy pocas
herramientas con restricciones, ya que, en general, no es posible inferir una canti-
dad fija de lógica.
Tanto en el caso de las asignaciones a señal concurrentes como secuenciales,
las herramientas de síntesis sólo soportan formas de onda simples compuestas por
una expresión y un retraso. El retraso sólo tiene sentido en simulación, ya que en
síntesis se ignora. Esto se debe a que, como se comentó en la introducción, a nivel
RT los retrasos de los componentes del circuito no se conocen. Son las acciones
(transferencias a registros y asignaciones de salida) en cada estado las que se des-
criben. En diseño síncrono, es la señal de reloj la que provoca el cambio de estado
con lo que todas las señales del circuito cambian con ella en sucesivos ciclos-o. En
consecuencia, las siguientes asignaciones:
z <= x and y;
z <= x and y after o ns;
z <= x and y after 50 ns;
son equivalentes desde el punto de vista de síntesis. Es responsabilidad del diseña-
dor asegurar que la funcionalidad del diseño no depende de los retrasos concretos
que cada asignación tenga en la implementación final a nive11ógico.
4. Síntesis 217
4.4.6. Descripción de "Iatches"
La mayoría de las herramientas infieren latches cuando en un proceso se relaja la

condición b). Así, por ejemplo, el código siguiente:
latch: process (D, en)

begin
if (en = '1') then
Q <= D;
end if;
end process latch;
sería la descripción explícita de un latch tipo-D.
D----t I----Q
I
en
FIGURA 4-15. "Lstch" tipo D.
Algunas herramientas permiten inferir elementos de memoria de variables. Así,

por ejemplo, el proceso secuencial del Listado 4-5 se sintetizaría mediante un latch
en la variable "d":
b e
Algunas herramientas infieren "latches" de asignaciones concurrentes de señal

en las que la señal destino participa en la forma de onda. Así, la asignación:
a <= b and e when h ='1' e1se a;
se sintetizaría mediante el siguiente circuito:

Este tipo de inferencia se puede realizar siempre que la herramienta sea capaz
de identificar la señal de habilitación dellatch. Otras herramientas, sin embargo, in-
fieren la lógica asíncrona directa correspondiente advirtiendo al diseñador de esta
situación. Esta implementación no garantiza la ausencia de carreras:
Algunas herramientas permiten utilizar bloques con señal de guarda para des-
cribir latches. La señal de guarda debe de especificar un valor y nunca un evento.
Así, por ejemplo, el código siguiente:
latch: block (en = '1')

begin
Q <= guarded D;
end block;
Sería una descripción alternativa a la de la Figura 4-15 con el mismo resultado

en síntesis.
4.4.7. Descripción de la señal de reloj
Se identifican como señales de reloj aquellas señales de comportamiento correcto

con especificación de evento y flanco. La forma más usual es:
reloj'EVENT and reloj = '1'

4. Síntesis 219
Algunas herramientas soportan también la forma:

not reloj_STABLEand reloj = '1'
Cuando la señal es de tipo std_ulogic, algunas herramientas aconsejan utilizar

la forma:
reloj'EVENT and reloj = '1' and reloj'Last_Value = 'O'
al objeto de asegurar que la transición activa de la señal de reloj se produce entre

los valores 'O' y '1' Yno desde cualquier otro valor.
Tal y como se ha comentado anteriormente, el estándar de síntesis IEEE
1076.3-1996 propone la utilización de las funciones Rising_Edge y Falling_Edge
para la detección de la transición de subida y bajada de la señal de reloj respectiva-
mente.
4.4.8. Registros
Se identifican como registros aquellas señales cuya asignación dependen de una se-
ñal de reloj.
Un bloque con señal de guarda puede ser utilizado para describir la carga sobre
un registro:
ex1:block (reloj 'event and reloj ..: '1')
begin
Q <= guarded D;
end block;
En principio, cualquiera de las formas de detección dela transición activa de la

señal de reloj es igualmente válida:
ex2 : block (not reloj' stable and reloj ~ '1')

begin
Q <= guarded D;
end block;
Un proceso con sentencia de espera puede ser utilizado también para describir
registros como en los ejemplos siguientes:
process
begin
wait until (reloj = '1');
Q <= D;
end process;
process
begin
wait until (reloj'event and reloj = '1');
Q <= D;
end process;
En un proceso con lista de sensibilidad, ésta puede ser utilizada para especifi-
car el evento de la señal de reloj:
process (rel~j~
begin _,
if (reloj'event and reloj = '1') then
Q <= D;
end if;
end process;
Este último estilo admite la inclusión de señales de set y reset, ya sean sín-
cronas:
process (reloj)
begin
if (reloj'event and reloj '1') then
if (reset = '1') then
Q <= '0';
e1se
Q <= D;
end if;
end if;
end process;
o asíncronas:
process (reloj, reset)

begin
Q <= '0';
elsif (reloj'event and reloj = '1') then
Q <= D;
end if;
end process;
Algunas herramientas permiten sustituir la lista de sensibilidad por la sentencia

de espera correspondiente:
process
begin
Q <= '0';
elsif (reloj'event and reloj '1') then
Q <= not D;
end if;
wait on reloj, reset;
end process;
En este caso, la lógica sintetizada sería la siguiente:

4. Síntesis 221
reset
reloj
En el caso de que la sentencia de espera se situara al principio, la lógica sería la

siguiente:
reset
reloj
La diferencia en uno u otro caso proviene del valor inicial de la señal D tras la
primera ejecución del proceso.
Sobre la señal de reloj se imponen usualmente una serie de condiciones de uso
que la caracterizan como una señal de comportamiento correcto. Las más usuales
son las siguientes:
• Generalmente, sólo se admite la especificación de un evento por proceso (o

bloque) lo que se traduce en un único reloj por proceso. La siguiente descrip-
ción sería, por tanto, incorrecta:
process ( ,.. )
if (reloja'event and reloja= '1') then
end H,
if (relojb'event and relojb= '1') then
end ifi
end process ,
• Cuando la señal de reloj se utiliza en una construcción condicional, no se

pueden especificar acciones en la cláusula else. La siguiente descripción se-
ría, por tanto, incorrecta:
if (reloj'event and reloj '1') then

x <= a;
else
x <= b;
end if;
• La especificación de reloj no se puede utilizar como operando. La siguiente

descripción sería, por tanto, incorrecta:
if not (reloj'event and reloj= '1') then ...
Algunas herramientas permiten la obtención de señales de reloj a partir de ope-

raciones lógicas sobre otra señal de reloj. Estas señales de reloj derivadas reciben el
nombre de gated clocks:
reloj_derivado <= reloj and senal_control;

process (reloj_derivado, reset)
begin
Q <= 'O';
elsif Rising_edge(reloj_derivado) then
Q <= D;
end if;
end procesa:
La implementación directa del código anterior sería:
reset
D----I Q
senal_control
reloj
Esta implementación, evidentemente, no está exenta de peligros en la señal re-

loj_derivado si la señal de control se genera combinacionalmente.
4. Síntesis 223
4.4.8.1. Registros de desplazamiento
Los registros de desplazamiento constituyen elementos muy frecuentes en circuitos

digitales. De hecho, en el multiplicador secuencial del Ejemplo 1 (Listado 4.3) el
registro EAMQ era un registro de desplazamiento con carga en paralelo. La utiliza-
ción de los operadores de desplazamiento representa la forma más simple de descri-
bir un registro de desplazamiento:
RD <= Shift_night (RD, 2);
RD <= RD sIl 2;
~
I ~ I ~I I 'O'
La concatenación permite descripciones explícitas:
RD <= RD (N)&RD (N)&RD (N downto 2); _ equivalente a Shift_right (RD, 2);

RD <= RD(N-2 downto 0)&"00"; _ equivalente a 511 2;
Otra alternativa la representan los lazos:
for 1 in N downto o loop _ equivalente a Shift_right (RD, 2);

if (1 = N or 1 = N - 1) then
RD(I) <= RD(N) ;
else
RD(I) <= RD(I + 2);
end if;
end loop;
4.4.8.2. Contadores
Los contadores representan otro elemento muy frecuente en diseño digital. La for-
ma más usual para describirlos en VHDL es mediante operaciones de incrementa-
ción y/o decrementación. Así, la siguiente sería la descripción de un contador cre-
ciente y decreciente de seis bits:

begin
contador <= ·000000";
elsif Falling_Edge(reloj) then

if (inc = '1') then
if (contador <= "111J,¡l") then
contador <= "OOOOOÜ';
else
contador <= contador + 1;
end if;
e1aif (dec = '1') then
if (contador <= '000000") then
contador <= "111111";
else
contador <= contador - 1;
end if;
end if; ;
end if; ;
end process;
En algunas herramientas, las operaciones de comparación para detectar los lí-

mites de cuenta pueden añadir lógica extra. Las herramientas que soportan el opera-
dor módulo evitan este problema con la identificación directa del retomo al valor
inicial. La siguiente sería la descripción de un contador de seis bits, creciente, de-
creciente y con carga en paralelo:

begin
contador <= ·000000";
elsif Falling_Edge(reloj) then
if (carga = '1') then
contador <= dato;
e1se
if (inc = '1') then
contador <= (contador + 1) mod 64;
elsif (dec = '1') than
contador <= (contador - 1) mod 64;
end if;
end if; ;
end if; ;
end process;
Los dos contadores anteriores son síncronos, ya que la carga sobre la señal
contador se realiza en la transición activa de la señal de reloj. La descripción de
contadores asíncronos (ripple counters) requiere de un estilo descriptivo explíci-
to. Así, por ejemplo, la siguiente sería la descripción de un contador asíncrono
módulo 10:
architecture descripcion of contador_mod10 is

signal contador: unsigned (3 downto O);
signal reset: std_Ulogic := '1';
begin
reset <= contador(3) aod contador(1);
4. Síntesis 225
procesa (reset, contador)

begin
contador (3) <= 'O';
elsif Fallin9_Edge(contador(2)) then
contador (3) <= not contador(3);
end if;
end process;
process (reset, contador)
begin
contador (2) <= 'O';
elsif Fall ing_Edge (contador (1}) then
contador (2) <= not contador(2)¡
end if;
end process;
procesa (reset, contador)
begin
contador{l) <= 'O';
1
eloj co ntador(Ol
;> Q
,-- O
a~
I
co ntador(1)
- P. Q
.-- O
al
I
~ co ntador(2)
> Q
r- o a~
I
co ntador(3)
'-----
> Q
,o a~
reset
e1s1f Falling_Edge(contador(O)) then

contador (1) <= DOt contador(l);
end lf;
end process;
begin
contador (O) <= 'O';
e1s1f Falling_Edge(reloj) then
contador (O) <= not contador(O);
end if;
end process;
end descripcion;
4.4.9. Descripción de FSMs
Existen varios estilos de descripción VHDL de FSMs. Cada uno de ellos será el
más apropiado, dependiendo de la herramienta y el tipo de máquina que se quiera
describir. Los resultados de síntesis en cada caso van a ser diferentes.
Los estilos descriptivos para FSMs se pueden agrupar en explícitos e implíci-
tos. En el estilo explícito el, la FSM se describe utilizando un proceso combinacio-
nal para describir la función de próximo estado y las asignaciones de salida y un
proceso secuencial para describir las asignaciones sobre el registro de estados en la
transición activa de la señal de reloj. Este estilo identifica claramente la parte com-
binacional de los elementos de memoria según el modelo general de máquina se-
cuencial de Huffman:
entity FSM is
port (reloj, reset: in std_ulogic; _ señales de reloj y reset
xl , ... xn in std_ulogic¡ _ señales de entrada
zl, ._ zm out std_ulogic); _ señales de salida
end FSM;
architecture el of FSM ls
type estados ls (sO, ...sp);
signa1 estado: estados; _ registro ~ estados
signa1 nxt_estado: es't~dos; _ señal de próximo estado
begin "
SID:process (estado, xl, ...xn)
begin
nxt_estado <= estadO; _ asignación por defecto
case estado ls
when sO => _ estado sO
_ acciones del· estado .sO:
_ asignación de estado próximo
- asignaciones. de sal~da
when sp => - estado, sp

- acciones del estado sp:
- asignación de estado próximo
4. Síntesis 227
_ asIgnaciones de salída
"<,
end case;
end process SIn;
relojd:process (reset, reloj)

begin
if (reset = 'O') then
estado <= sO; _ reset asíncrono
elsif (reloj'event and reléj,~ ,1') then
estado <= ~t_estado; _ transición de estado
end if;
end process relojd;
end el;
El proceso secuencial de carga del registro de estados puede utilizar cualquiera

de los estilos descriptivos comentados anteriormente para registros. El siguiente se-
ría un proceso con una sentencia de espera de la señal de reloj en vez de lista de
sensibilidad:
relojd:process
begin
wait until reloj = '1';
estado <= sO; - reset síncrono
elee
estado <= nxt_estado; _ transición de e$tado
end if;
end process relojd;
En algunas herramientas, esta segunda posibilidad impide la descripción de señales

de reset asíncrono para los elementos de memoria. Debido a su simplicidad y a que
las únicas tareas delegadas a la herramienta de síntesis son las de optimización lógi-
ca y mapeado tecnológico, el estilo descriptivo el es con el que resulta más fácil la
obtención de resultados de síntesis óptimos.
El registro de estados puede identificarse mediante un atributo lo que permite a
la herramienta la identificación de los estados de la máquina y la extracción de las
transiciones entre estados. Esta información facilita los procesos de asignación se-
cundaria y minimización de estados.
Ejemplo 4.2. Dada la máquina definida por el diagrama de estados de la Figu-

ra 4-16.
Su descripción en el modelo explícito el sería la siguiente:
entity FSM i.
port ( reloj, reset : in std_ulogic; _ señales de reloj y reset
x in std_ulogic; _ señal de entrada
228 VHOL. Lenguaje estándar de Diseño Elecrrónico
%, 1/1
1/0 1/1
%
1/0
0/1
FIGURA 4-16. Diagrama de estados.
z out std_ulogic); _ señal de salida

end FSM;
architecture el of FSM is
type estados is (sO, sl, s2, s3);
signa! estado: estados; -,registro de estados
signa1 nxt_estado: estados; - señal de próximo estado
begin
sm: process (estado, x)
begin
nxt_estado <= estado; - asignación por defecto
case estado is
when sO => - estado sO
z <= '0'; _ asignación de salida
if (x = 'O') then _ asignación de estado próximo
nxt_estado <= sl;
else
nxt_estado <= s2;
end if;
when sl => _ estado sl
z <= x; - asignación de salida
nxt_estado <= sO; '- asignación de estado próximo
when s2 => - estado s2
z <= 'DI i - asignación de salida
4. Síntesis 229

nxt_estado <= sl;
elae
nxt_estado <= s3;
end if;
when s3 => _ estado s3
z <= '1'; _ asignación de salida
if (x = '1') then _ asignación de estado próximo
nxt_estado <= sl;
end if;
end case;
end process sm;
relojd: process (reset, reloj)

begin
elsif (reloj'event and rel.Oj = '1') then
estado <= nxt~estado; _ transición de estado
end if; .
end procesa relojd;
end el;
En el estilo explícito e2, la FSM se describe utilizando un único proceso se-

cuencial con una sentencia de espera del reloj. En este estilo descriptivo todas las
acciones tienen lugar en sincronía con la señal de reloj, por 10 que sólo es posible
describir máquinas de Moore. Este hecho es de particular importancia porque todas
las señales asignadas van a inferir biestables y, por ello, este estilo descriptivo sólo
es apropiado cuando se desee este tipo de implementación. En cualquier caso, este
problema se puede evitar extrayendo la función de salida a un proceso combinacio-
nal dependiente del estado actual y las entradas. Dado que, normalmente, las salidas
de la máquina no van a coincidir con el registros de estado, éste puede declararse
como variable:
architecture e2 of FSM is
begin
sm: process
type estados is (SOí _. sp);
variable estado: estados; _ registro de estados
begin
estado := sO; _ reset síncrono
else
case estado is
_ acciones del estado sO:
_ transición de estado y
_ asignaciones de salida
when sp => _ estado sp

- accíones del estado sp:

- transición de estado y
- asignaciones de salida
end case;
end if;
end process SID;
end e2;
Ejemplo 4.3. La descripción VHDL en el estilo explícito e2 de la máquina de la

Figura 4-16 sería el Listado 4-7.
architecture e2 of FSM ls
type estados la (sO, sI, s2, s3);
begin
sm: procesa (estado, xl
variable estado: estados; ce registro de estados
begin
wait untll reloj = '1';
estado := sO; - reset síncrono
else
case estado is
z <= ' O' ; ..:.
asignación a registro de salida
if (x =' 'O') then '- asignación de estado próximo
estado := sI;
else
estado := s2;
end if;
when sI => - estado sI
z <= x; ~ asignación a registro de salida
estado := sO; - asignadi6nde estado próximo
z <= '0'; - asignación de salida
if (x = '0') then - asignación de estado próximo
estado := sI;
elae
estado := s3;
end if;
z <= '1'; - asignación de salida
if (x = '1') then - asignación de estado próximo
estado := sI;
end if;
end case;
end if;
end process sm;
end e2;
LISTADO 4-7. Descripción en estilo e2.

4. Síntesis 231
Aunque, aparentemente, el número de estados no ha variado respecto al ejem-

plo anterior, esta descripción añade 'z' como elemento de memoria, lo que duplica
.él número real de estados de la máquina. Uno de estos estados es redundante, ya
que el diagrama de estados de la máquina Moore equivalente tiene sólo siete esta-
dos tal y como se muestra en la Figura 4-17.
No todas las herramientas de síntesis son capaces de encontrar la máquina de
estados mínima.
Como se concluye del ejemplo, en este estilo la calidad del resultado descansa
en mayor medida sobre la efectividad de los algoritmos de minimización de estados
de la herramienta. Estos algoritmos no tienen la efectividad de los algoritmos de
minimización lógica, lo que reduce la fiabilidad de este estilo descriptivo que, en
consecuencia, hay que utilizar cuando la calidad del resultado esté garantizada.
Otro inconveniente a destacar es la imposibilidad, en la mayoría de las herramien-
tas, de describir capacidad de inicialización asíncrona.
Las principales ventajas del estilo provienen de su simplicidad, desde el mo-
mento en que la máquina queda descrita en un único proceso, y de que todas las sa-
lidas están registradas, lo que asegura la ausencia de peligros. Este hecho puede ser
particularmente interesante cuando se desean generar señales de control limpias (sin
peligros).
En el estilo explícito e3, la FSM se describe utilizando un único proceso se-
cuencial con las señales de reloj, reset, registros de estado y entradas en la lista de
sensibilidad. El código secuencial se divide en cuatro partes diferenciadas de las
que se infiere distinto tipo de lógica:
o
o
o
o
FIGURA 4-17. Diagrama de estados de máquina Moore.

architecture e3 af FSM ls
type estados 18 (sO, ...sp);
signal estado: estados := sO; _ registro.de estados
begin
sm: process (reset, reloj, estado, xl , ... xn)
begin
_ lógica combinacional
•
lf (reset = '0') then
elsif Rising_Edge(reloj) then
case estado ls >

_ acciones·del·estadó sO:
_ transiCi6n de estado y
_ asignaciones a registro de salida
when sp => _ estado sp

_ aC9iones del estado sp:
_ trensícíén de estado y
_ asignaciones a registro de salida
end case;
end if;
_ lógica combinacional
end process sm;

end e3;
Este estilo es el más flexible, ya que permite describir en un único proceso ló-
gica combinacional, lógica secuencial e inicialización síncrona o asíncrona de los
elementos de memoria. De hecho, todas las asignaciones fuera del cuerpo de la sen-
tencia:
lf (reset = ' O') then ...

elsif Rising_Edge (reloj) then ...
end if;
tanto al principio como al final del proceso, van a producir lógica combinacional.
Las asignaciones en el cuerpo de la sentencia:
lf (reset = ' O') then...
van a corresponderse con la inicialización asíncrona. Las asignaciones en el cuerpo

de la sentencia:
elslf Rising_Edge (reloj) then ...
van a corresponderse con la carga síncrona de los elementos de memoria. En esta

sección podría incluirse la inicialización síncrona de los elementos de memoria.
4. Síntesis 233
No todas las herramientas soportan código fuera de la sentencia condicional de

las señales de inicialización y reloj. Las herramientas que lo soportan imponen res-
tricciones en cuanto a las asignaciones de, señal que se pueden hacer en cada parte
(antes y después) en relación con el código secuencial, principalmente en la parte
final.
Ejemplo 4.4. Dada la máquina definida por el diagrama de estados de la Figu-

ra 4-17, la descripción en el estilo explícito e3 sería la siguiente:
architecture e3 of FSM is
type estados i8 (sO, sl, 82, s3);
signal estado: estados := sO; _ registro de estados
begin
sm:process(reset, reloj, estado, x)
begin
case estado is _ lógica combinacional
when sl =>
z <= x;
when s3 =>
z <= '1';
when others =>
z <= '0' i
end case;
estado <= sO; - reset asincrono
elsif Rising_Edge(reloj) then
case estado ls
estado <= sl;
else
estado <= s2;
end lf;
when sl => _ estado sl
estado <= sO; _ asignaci6n de estado próximo
estado <= sl;
else
estado <= 63;
end if;
if (x = '1') then _ asignación de estado próximo
estado <= sl;
end if;
end case;
end if;
end procesa sm:
end el;
En el estilo implícito de descripción, la FSM se describe utilizando un proceso

con varias sentencias de espera de la señal de reloj como en el Listado 4-8. Recibe
el nombre & estilo descriptivo implícito debido a que además de los P estados ex-
plícitos en la declaración del tipo "estados" de la señal de estado 13, la descripción

incluye los N estados introducidos por las sentencias de espera. El número de esta-
dos total de la máquina resulta N*P. Aunque, en ciertos casos, éste pueda ser el esti-
lo descriptivo más cómodo, presenta el peligro del aumento indeseado en el número
de estados. Dado que, como se ha comentado con anterioridad, los algoritmos de
minimización de estados presentan graves limitaciones en las herramientas de sfnte-
sis comerciales en la actualidad, los resultados pueden no ser óptimos. Se trata, por
tanto, de un estilo descriptivo recomendable únicamente cuando se tenga la certeza
que la funcionalidad de la máquina se adapta al mismo y que, por tanto, los resulta-
dos de la síntesis van a ser aceptables. Debido a que todas las asignaciones de señal
se ejecutan en el flanco activo de la señal de reloj, sólo es posible describir máqui-
nas de Moore. Es posible la inicialización asíncrona del registro de estados implíci-
to cuando el código se encierra en el cuerpo de un lazo indefinido y tras cada sen-
tencia wait se incluye la sentencia de salida:
next lazo when (reset = '1');
Se puede incluir la inicialización síncrona de los elementos de memoria del re-
gistro de estados explícito, siempre que el código entre las sentencias de espera se
estructure en una sentencia:
if (reset = '1') then ... end if;
e1se ...
architecture implícita of FSM iB

type estados ia (sO, ...sp);
begin
sm:process
variable estado: estados := sO; - registro de estados ~lícitos
begin
- acciones del estado implícito 1
acciones del estado implícito n

,...
end process;
end implícita; 1
LISTADO 4-8. Estilo implícito.
13 En este estilo descriptivo, el atributo usualmente utilizado para identificar el registro de esta-
dos no está permitido.

4. Síntesis 235
Muy pocas herramientas de síntesis soportan este estilo en el momento presen-

te. De nuevo, dado que, normalmente, las salidas de la máquina no van a coincidir
con el registro de estado, éste puede declararse como variable.
Ejemplo 4.5. El Listado 4-9 sería la descripción VHDL en estilo implícito de la

máquina utilizada en los ejemplos anteriores.
architecture implicita of FSM is

begin
srn:process
variable estado: estados; - I~istro de estg,Qps
begin
wait until reloj = '1'; - estado sO
z <= 'O'; - asignación a registrq de salipa
if (x = '1') then
wait until reloj '1'; - estado s2
z <= 'o' i - asignación a registro de salída
if (x = '1') then
wait until reloj '1'; = - estado s3
2 <= '1'; - asi,gnaci9Ila regil;ltro_
(elesalida
while (x = 'O') locp
wait until reloj '1'; - estaqos3. " " ' _,~'
z <= '1'; - aaíqnací.ón a r~istro de salida
end loop;
end if;
end if;
wait until reloj i l' ; - estado sl
Z <= Xi - asignación a registro de salida
end process smr
end implícita;
LISTADO 4-9. Descripción en estilo implícito.
4.4.10. Descripción de FSMDs
Recibe el nombre de FSMP, o máquina de estados finitos con unidad de datos tam-
bién denominada ASM o máquina de estados algorítmica, a la conjunción de un au-
tómata de control y una unidad de datos según el esquema general de arquitectura a
nivel RT comentada anteriormente y que se mostraba en la Figura 4.10. Cualquiera
de los estilos descriptivos anteriores puede ser utilizado en la descripción VHDL de
FSMDs sin más que incluir en cada estado las acciones a ser realizadas en la unidad
de datos. Los estados explícitos (o implícitos) de la máquina se corresponderán con
los estados de control mientras que los recursos hardware necesarios en la imple-
mentación de las acciones a realizar en los estados de control constituirán la unidad
de datos.
En el caso más general, un sistema digital a nivel RT estará compuesto de una

o varias FSMs y/o FSMDs, módulos de lógica combinacional y registros. La des-
cripción VHDL del multiplicador secuencial del Listado 4-3 constituye un ejemplo
de FSMD.
4.4.11. Segmentación
La descripción en VHDL de circuitos segmentados (pipelined) como el de la fi-

gura:
puede realizarse con cualquiera de los estilos descriptivos para FSMs comentados
con anterioridad. Así, utilizando el estilo explícito el:
SIn:process (X, Regl, Reg2, Reg3)

begin
LC1 <= ...;
LC2 <= ...;
LC3 <= ...;

Z <= Reg3;
end process SIn;
re1ojd:process (Reloj)
begin
if (reloj' event and reloj = '1') then
Reg1 <= LCl; - etapa 1
Reg2 <= LC2; - etapa 2
Reg3 <= LC3; - etapa 3
end if;
end process relojd;
En este circuito, la velocidad máxima de funcionamiento está limitada por el

peor de los retrasos en los bloques de lógica combinacional (suponiendo idénticas
características de tiempo de carga, TH, y retraso, TR, en los registros):
4. Síntesis 237
1
. Fmáx = ----------
TR + máx (TI, T2, T3) + TH
Algunas herramientas permiten optimizar automáticamente el circuito disminu-

yendo el camino crítico mediante la técnica de retemporalización (retiming). Esta
técnica consiste en el movimiento de los registros a través de la lógica combinacio-
nal sin alteración de la funcionalidad global del circuito. Así, por ejemplo, si en el
circuito anterior:
TI = 4 ns
La herramienta desplazaría los registros a través de la lógica intentando que:
En la retemporalización pueden tenerse en cuenta los retrasos asociados a la ló-

gica de entrada y salida. Así, si en el ejemplo anterior el retraso asociado a la entra-
da 'X' es de 4 ns y el retraso asociado a la salida 'Z' es de 5 ns, la herramienta des-
plazaría los registros según el esquema de la figura:
intentando que:
al objeto de que:
La retemporalización puede utilizarse también como un método alternativo a la

asignación secundaria a la hora de minimizar el número de elementos de memoria.
Así, por retemporalización del circuito de la Figura 4-18 a) se podría obtener la im-
plementación b) que puede ser preferible en la mayoría de los casos:
x1 -----1 o Q
x2 o Q
reloj
a)
x1
o Q 1---- z
x2
b) reloj
FIGURA 4-18. Ejemplo de reternporalización.
4.5. RECOMENDACIONES GENERALES
El código VHDL desarrollado como descripción de la arquitectura RT a sintetizar

va a tener, adicionalmente, otras aplicaciones, como verificación funcional por si-
mulación, documentación y mantenimiento, etc. En parte o en todo, el código debe
de ser reutilizable en proyectos futuros al objeto de minimizar el esfuerzo de diseño
necesario.
Dependiendo de la aplicación, caben recomendaciones particulares que permi-
ten optimizar el código a desarrollar. Así, se pueden proponer recomendaciones
4. Síntesis 239
orientadas a minimizar el tiempo de simulación, mejorar la legibilidad del código

que favorezca el mantenimiento del mismo y su uso en la documentación del pro-
yecto o que faciliten su reutilización posterior. Algunas de estas recomendaciones
pueden ser contradictorias, de tal forma que, dependiendo de la aplicación más im-
portante, habrá que establecer una prioridad entre ellas. Respecto a recomendacio-
nes destinadas a optimizar el código VHDL con vistas a la simulación y la docu-
mentación, las directivas incluidas en [S94] cubren perfectamente estos objetivos.
Respecto a la reutilización del código, el Capítulo 6 hace una extensa descripción
de este aspecto de creciente importancia en el diseño de sistemas complejos.
En este capítulo suponemos que la aplicación más importante es síntesis que,
por otro lado, va a constituir de hecho la situación más frecuente en la mayoría de
los casos. En consecuencia, las recomendaciones que hagamos estarán dirigidas a
mejorar los resultados de la herramienta de síntesis que se utilice. Es particularmen-
te interesante que un mismo equipo de trabajo comparta un mismo conjunto de nor-
mas al objeto de asegurar la coherencia en cuanto a los objetivos comunes que se
establezcan.
4.5.1. Recomendaciones para síntesis
Vamos a hacer a continuación una breve descripción de las recomendaciones de ca-

rácter general que hay que tener en cuenta a la hora de asegurar una calidad mínima
en el código VHDL para síntesis que asegure resultados satisfactorios. Recomenda-
ciones más detalladas pueden encontrarse en [S96] y [CP96].
4.5.1.1. Descripción de "hardware"
Las herramientas comerciales actuales cubren las etapas de síntesis RT y lógica

comentadas en el apartado 3. En consecuencia, el diseño arquitectural corresponde
actualmente al diseñador. Así pues, la arquitectura del sistema compuesta por uni-
dades de control y de datos, máquinas de estados finitos, unidades operacionales,
interconexiones, entradas y salidas, etc., deben de decidirse adecuadamente al obje-
to de asegurar con el mayor grado de certidumbre posible que la implementación fi-
nal va a satisfacer los requerimientos de área, velocidad, consumo, etc., de forma
óptima. Únicamente cuando el diseño arquitectural se halla completado cabe gene-
rar el código VHDL correspondiente. Abordar el diseño del sistema directamente
en VHDL no es recomendable.
Aunque VHDL tenga similitudes sintácticas con lenguajes de programación
(particularmente ADA), se trata de un lenguaje de descripción de hardware. La des-
cripción VHDL refleja una arquitectura. Si ésta no ha sido cuidadosamente diseña-
da, los resultados de la síntesis no van a ser óptimos. Código elegante desde un
punto de vista de programación puede ser ineficiente en síntesis. En este sentido, la
utilización de código simple y fuertemente ligado a la implementación [V95] va a
asegurar la obtención de resultados óptimos.
4.5.1.2. Limpieza del código
El código VHDL generado para síntesis debe de ser lo más claro posible al objeto
de asegurar al máximo control sobre el resultado. En este sentido cabe hacer las si-
guientes recomendaciones:
• Utilizar al máximo tipos estándar reconocidos e implementados eficiente-

mente por la herramienta de síntesis. Salvo en el caso de modelar buses, la
utilización de tipos enteros restringidos es recomendable.
Es preferible el uso de señales no resueltas std_ulogic frente a las resuel-
tas std_logic. En el caso de vectores es recomendable la utilización de rangos
decrecientes (N downto O).
• Minimizar, y si es posible eliminar, el uso de caracteres metalógicos ('U',
'X', 'W' y '- '). No realizar nunca comparaciones con dichos caracteres ya
que van a ser interpretadas siempre como falso, cierto o como error depen-
diendo del caso [IEEE96]. No realizar asignaciones que no sean de caracte-
res 'O', '1' o 'Z', salvo en el caso de funciones lógicas o de transición (en el
caso de FSMs) incompletamente especificadas, en cuyo caso se debe de utili-
zar 'X,14.
El uso del carácter 'X' como indiferente está recomendado también para
señales del tipo std_ulogic correspondientes a entradas en un bloque no utili-
zadas.
• No usar variables para modelar registros. Los elementos de memoria consti-
tuyen recursos hardware que deben decidirse antes de la síntesis y declararse
como señales en la descripción VHDL. En este mismo sentido, deben de evi-
tarse aquellas construcciones correspondientes a "latches" implícitos, salvo
que su utilización sea imprescindible en el diseño.
Sin embargo, el uso de variables es recomendable frente al de señales,
por razones de legibilidad y eficiencia en la simulación. Al objeto de que la
variable no genere lógica secuencial, la variable debe de utilizarse en cual-
quier condición de ejecución del proceso en la cual se asigne.
• Tanto por razones de legibilidad del código como de eficiencia en síntesis,
las sentencias case son preferibles al encadenamiento de sentencias
if...then ... else. Utilizar la sentencia elsif en vez de else if. Sin embargo, es
preferible utilizar sentencias limpias del tipo:
if (a = '1') then
else
end if;
14 Podría utilizarse también •-'. Sin embargo, este carácter es más incómodo a la hora de analizar
resultados de simulación.
4. Síntesis 241
que:
ti (a = '1') then
e1sif (a = 'O') then
else
end if;
• Es recomendable .el uso de funciones y procedimientos de usuario para en-

capsular código con una funcionalidad dada. En los subprogramas no se debe
de utilizar señales que no hayan sido pasadas como parámetros.
• Por razones de legibilidad del código, es recomendable dar el mismo nombre
a las referencias de los componentes que los de las entidades con las que se
asocian.
4.5.1.3. Correspondencia entre simulación y síntesis
Al objeto de facilitar la verificación por simulación tanto del código RT como de la

implementación lógica correspondiente, deben de limitarse al mínimo todas aque-
llas construcciones que provocan discrepancias innecesarias entre simulación y sín-
tesis. En este sentido cabe realizar las siguientes recomendaciones:
• Las señales y variables deben de tomar los valores iniciales en la descripción
de tal forma que el resultado de simulación no dependa de los valores por de-
fecto asignados por el simulador,
• En un proceso con parte combinacional, todas las señales utilizadas en la
parte combinacional deben de pertenecer a la lista de sensibilidad del proce-
so.
• Evitar la utilización de variables antes de su asignación. Tal y como se co-
mentó en el apartado 4.5, este tipo de situaciones provoca discrepancias in-
necesarias entre simulación y síntesis.
4.5.1.4. Conocimiento de la herramienta
Al objeto de sacar el máximo partido de una determinada herramienta de síntesis,

es necesario conocer en detalle la metodología de síntesis particular que esta he-
rramienta utiliza. Concretamente, los algoritmos de síntesis que implementa y su
eficacia. Como directivas generales se pueden considerar las comentadas en el
apartado 3.
4.6. EJERCICIOS
1. Dada la siguiente asignación secuencial de señal:
z <= xl + x2 after 25 ns;
¿Es posible determinar el tipo de descripción, funcional, RT o lógica de la que

se trata? Comentar la interpretación temporal del código en cada caso.
2. Un filtro FIR de k etapas se describe por la siguiente ecuación:
k
2:
Y (t) :::: x(t - i)*c(i)
i=O
a) Proponer una descripción VHDLfuncional.

b) Proponer una arquitectura RT con un único multiplicador y la descripción
VHDL algorítmica correspondiente.
e) Situar en el cubo de diseño de la Figura 4-2 las descripciones de entrada y
salida y determinar los pasos de diseño recorridos.
d) Repetir el proceso considerando la siguiente ecuación para el filtro:
o
y(t) ::::2: x(t - i)*c(i)
i=k
e) ¿Cuál de las dos implementaciones ocupa menos área?

f) Repetir el proceso utilizando un multiplicador segmentado por ciclo de reloj
y latencia de dos ciclos.
g) Poner una implementación con mínimo camino crítico (sin restricciones de
uso de operadores y registros).
3. Proponer una descripción VHDL en flujo de datos para la descripción algorít-

mica desarrollada en el problema 2. Situar en el cubo de diseño de la Figu-
ra 4-2 las descripciones de entrada y salida y determinar los pasos de diseño
recorridos.
4. Dada la siguiente descripción VHDL:

procesa
begin
if xl = '1' then
z <= tI};
wait on xl :
elsif x2 = '1' then
z <= 11';
4. Síntesis 243
wait on x2;
el se
z <= 10';
wait until xl ar x2;
end if;
end process;
a) Proponer una implementación mínima.

b) Decidir si se trata de una descripción sintetizable. Justificar la respuesta.
5. Dada la siguiente descripción:

archi tecture ...
signal databus, reg _: std_logic_vector ...
begin ...
process
wait until reloj'f,!vent aJld reloj='l'; .: i~
databus <= (others => 'Z'); --. Bus con múltiples

.
drivers
if ( aCCede_a_reg+st::r?:..:1\ G1J!e then
if ( carga_regIstro =' Úue then
reg <= dataBus ¡,-; -- Rscribe ertel registro
else
databus <,;,~'reg;
end if;
end if;
end process;
a) Proponer una implementación mínima.

b) ¿Es una descripción sintetizable?
e) Describir la secuencia de entradas que muestra cómo no se corresponde la
simulación VHDL de la descripción anterior con el comportamiento espera-
do de la implementación del apartado a).
6. Proponer declaraciones de señal VHDL sintetizables para:

a) Las señales de reloj y "reset" de un circuito.
b) Un "bus" de 32 bits.
e) Datos en el rango O a 255.
d) Coeficientes en el rango -3,96875 a 3,96875.
e) El resultado de la multiplicación de los datos de e) y los coeficientes de d)
sin pérdida de precisión.
f) Los 9 estados SO... S8 de una máquina de estados finitos.
7. Encontrar implementaciones mínimas para las siguientes sentencias:

a) z <= (x ar 'H') and (x ar '0');
b) if (xl /= "0-") then

case x2 is
when "O-" =>
z <= 'D' i
when "lOO' =>
z <= /1' i
when others =>
z <= '_';
end case;
else
z <= /1';
end if;
c) with Y select
z <= xl or x2 when "OO' else
xl when "01" else
'Z' when "10" else
'1' when 1111" ;
8. Se desea sintetizar un circuito combinacional de cuatro entradas y dos salidas

de forma que las salidas representen en binario el número de entradas a '1'.
a) Proponer una descripción en flujo de datos.
b) Proponer una descripción algorítmica.
9. Se desea sintetizar un circuito combinacional que recibe una palabra BCD y

controla un siete segmentos con entradas asertadas a 'O':
~ a
a
b8'
~ b
De
BCD Circuito -c;d
e e f
e f 9
-09
Teniendo en cuenta las entradas indiferentes:

a) Proponer una descripción en flujo de datos.
b) Proponer una descripción algorítmica.
10. Repetir el problema anterior pero haciendo que el circuito muestre la letra de
error 'E' cuando se reciba una palabra fuera del código.
11. Se desea diseñar una Unidad Aritmético-Lógica sobre datos de entrada A y B

del tipo signed (15 downto O). La función a realizar sobre la salida F del ti-
4. Síntesis 245
po signed (16 downto O), dependiendo de la palabra de control 'OP' es la

que se describe en la tabla siguiente:
Entrada de control Salida
OP
natural F (16) F(15 downto O)
O O AorB
1 O AnorB
2 O AandB
3 O AnandB
4 O Axor B
5 O AxnorB
6 A+B
7 A-B
Proponer la descripción VHDL sintetizable.
12. Obtener una implementación mínima para el siguiente código:

process (x, y)
begin
case y is
w'hen "OO' =>
z(l)<" 'O';
when "11" =>
z(l) <= '1';
z(2) <= x(2) and not x(l);
when others =>
z (1) <= x(l);
end case;
end process¡
13. Describir en VHDL para síntesis un contador bidireccional que circule por el
siguiente código "One-Shot":
00000
10000
01000
up='O' UP= '1'
00100
00010
00001
Se recomienda utilizar operaciones de desplazamiento.

14. Proponer descripciones VHDL sintetizables en los tres estilos explícitos (el, e2
y e3) y en estilo implícito para la máquina de estados finitos siguiente:
Estado próximo/salidas (el-e7)
Estado actual x =O x =1
SI S2/1000000 S4/1000000
S2 S3/0100000 Sl/OOOOO10
S3 S2/0010000 Sl/OOOOOI0
S4 S5/0001000 Sl/OOOOOOI
S5 S4/0000100 Sl/OOOOOOl
15. La máquina del problema anterior se corresponde con la unidad de control de

un circuito con dos entradas Xl y X2, dos registros internos A y B y una salida
Z, todos ellos del tipo signed (15 downto O). Proponer la descripción de la
FSMD correspondiente sabiendo que las rnicrooperaciones asociadas a cada
una de las señales de control son las siguientes:
el A:= (others => 'O'), B := (others => 'O')

e2 A:=A+XI
c3 A:=A+X2
c4 B :=B +XI
eS B :=B +X2
c6 Z<=A
e7 Z <= B
4.7. BIBLIOGRAFÍA
[C96] N. H. COHEN:ADA as a second language, McGraw-Hill, 1996.

[CP96] Comité PRENDA: PRENDA: Metodología para el diseño de AS/Cs, Universidad
Politécnica de Madrid, febrero, 1996.
[E95] W. EcKER y M. MOFMEISTER:The design cube - A model for VHDL Desing flow re-
presentation, proc. ofEuroVHDL'92, JEEE, 1992.
[F90] E. D. FABRICIUS:lntroduction to VLSI design, McGraw-Hill, 1990.
[JEEE95] IEEE PI 076.4-1 995: VITAL, JEEE Standards Department, 1995.
[JEEE96] IEEE PI 076. 3-1996: Standard VHDL Synthesis Packages, JEEE Standards De-
partment, 1996.
[LS93] L. LAVAGNOy A. SANGIOVANNI- VINCENTEll.I: Algorithms for synthesis and testing of
asynchronous circuits, Kluwer, 1993.
[LSU89] R. LIPSETI, C. SCHAEFERy C. USSERY: VHDL: Hardware description and design,
Kluwer, 1989.
[M94] G. de MICHELI: Synthesis and optimization of digital circuits, McGraw-Hill, 1994.
4. Síntesis 247
[MLD92] P. MICHEL. U. LAUTHERy P. Duzy (Ed.): The synthesis approach to digital system
designo Kluwer, 1992.
[N93] Z. NAVABI:VHDL: Analysis and modeling of digital systems, McGraw-Hill. 1993.
[OW94] D. E. Orr y T. 1. WILDEROTIER. A designer's guide to VHDL synthesis, Kluwer,
1994.
[S94] P. SINANDER:VHDL modelling guidelines, European Space Agency. September, 1994.
[S96] D. J. SMITH:HDL chip designo Doone Publications, 1996.
[V95] E. VILLAR: Level-O VHDL synthesis syntax and semantics, ESPRIT 8370 ESIP Pro-
ject, December, 1995.
[VS93] E. VILLAR y P. SÁNCHEZ:Synthesis applications ofVHDL. en 1. Mermet (ed.): "Fun-
damentals and standards in hardware description languages", Kluwer, 1993.
Capítulo 5
MODELADO
CON VHDL
Eduard Lecha, Fernando Rincón, Manel Moré, Joan Vidal y Lluís Terés
IMB-CNM (CSIC)
Un niño de cinco años entendería esto.

¡Traedme un niño de cinco años!
Groucho Marx
La principal función de un lenguaje de descripción de hardware es

permitir la realización de un modelo que facilite tanto la especificación
como el diseño y la verificación de sistemas electrónicos. Creemos que
la mejor forma de comprender el objetivo y las peculiaridades de los
distintos estilos de modelado es seguir el desarrollo de un sistema
electrónico desde su concepción hasta su descripción detallada, ade-
cuada para ser aplicada como entrada a las herramientas de síntesis
automática comercializadas actualmente.
Para ello, a lo largo de este capítulo utilizaremos un sistema com-
puesto por un procesador, su memoria de datos y programas y un
árbitro de bus. Se parte de la base de que todos los componentes, a
excepción del procesador, se implementarán utilizando circuitos inte-
grados ya existentes que deberán ser modelados con VHDL para la si-
mulación del sistema. De esta forma se desarrollarán modelos tanto
para el desarrollo de un componente desde su especificación hasta su
implementación como para la simulación de un componente ya imple-
mentado cuyas características son completamente conocidas.
249
5. 1. INTRODUCCiÓN
En este capítulo se presenta, de una manera práctica, el uso del lenguaje VHDL pa-
ra el modelado de sistemas electrónicos. Para ello todo el capítulo se ejemplifica so-
bre un sistema basado en un procesador sencillo ("La máquina rudimentaria"
[SPC97]) y arropado con otros componentes básicos (memoria y árbitro de bus) pa-
ra formar un sistema microprocesador completo.
El procesador es el hilo conductor del capítulo a lo largo del cual se abordan
los problemas del modelado con VHDL en los distintos niveles de abstracción. En
una primera etapa será fundamental poder experimentar con distintos conjuntos de
instrucciones para el procesador en un modelo sencillo que sea fácil de manejar. Pa-
ra esta etapa se desarrollará un modelo funcional. Posteriormente será necesario es-
pecificar con más detalle la interfaz del procesador con su entorno y a partir de este
momento, será posible refinar por separado tanto el modelo del procesador como el
del resto del sistema hasta llegar a un modelo detallado de los componentes del pro-
cesador y a un modelo lo más fiel posible de los circuitos ya existentes utilizados
para el resto del sistema.
Antes de abordar cada tarea en el diseño del sistema ejemplo se plantean los
problemas del modelado en el nivel de abstracción necesario para la tarea junto con
una descripción general de las técnicas que se podrían aplicar y los posibles usos
del VHDL en la solución de la tarea planteada. Posteriormente se aplican al sistema
ejemplo las estrategias y técnicas más adecuadas para nuestro caso.
En el siguiente apartado se da una visión global de los mecanismos disponibles
en VHDL para modelar un sistema a distintos niveles de abstracción. Estos meca-
nismos se tendrán en cuenta en cada descripción del procesador para cumplir con el
objetivo de los distintos modelos.
A continuación se describe el modelado a nivel algorítmico. Este tipo de mode-
los suelen utilizarse en las primeras etapas del diseño como ayuda a la escritura y
validación de las especificaciones del componente a implementar. En muchas oca-
siones es posible escribir un modelo algorítmico de un componente sin especificar
ni siquiera su interfaz con otros componentes.
La evolución del procesador consiste en la definición de su interfaz con los de-
más componentes del sistema y el refinamiento de su arquitectura interna. Para si-
mular esta segunda descripción del procesador es necesario definir un banco de
pruebas. Los bancos de pruebas constituyen un modelo del entorno del componente
a verificar y a lo largo del capítulo se mostrarán distintas opciones en los bancos de
pruebas del procesador a medida que se detalle su entorno.
El particionado del procesador continúa después de la realización del primer
banco de pruebas. Se realiza un modelo detallado del procesador, distinguiéndose
los diferentes componentes de la unidad de proceso y unidad de control, así como
sus distintas implementaciones. El modelado detallado se realiza con el objetivo de
cubrir la mayor variedad posible de técnicas de modelado para la simulación, aun-
que sin perder de vista las necesidades de un modelo para síntesis. Así, en las des-
cripciones a nivel de transferencia de registros, se tienen en cuenta las capacidades
de las herramientas de síntesis actuales, apuntándose en cada caso las estructuras no
sintetizables y las modificaciones necesarias de los modelos para síntesis.
5. Modelado con VHDL 251
Finalmente, debido al gran tamaño de los listados VHDL que aparecen en este
capítulo, se ha optado por simplificar y esquematizar al máximo el código insertado
en el interior del texto, e incluir las descripciones completas en la dirección del Web
http://www.cnm.es/lBM/libroVHDL.
5.2. EL MODELADO DE UN SISTEMA A DIFERENTES

NIVELES DE DETALLE
En una primera etapa del diseño de un sistema electrónico se dispone únicamente

de una vaga idea de qué es lo que se pretende que el sistema realice y mucho más
desconocido es cómo el sistema realizará su función. Sin embargo, ya en esta pri-
mera etapa puede ser útil utilizar un lenguaje como el VHDL. En este contexto, las
descripciones VHDL permitirán simular los primeros esbozos de la arquitectura ex-
presando las características que se considere conveniente resaltar y obviando los
detalles propios de etapas más avanzadas.
Las primeras simulaciones pueden utilizarse para realizar una primera evalua-
ción del rendimiento de los distintos algoritmos o funciones del sistema. Al mismo
tiempo, dichas evaluaciones resultarán en decisiones sobre la implementación que
añadirán información a las descripciones VHDL, de modo que, a medida que éstas
se refinen, se avanzará hacia unas especificaciones del sistema cada vez más deta-
lladas.
No siempre la funcionalidad del sistema se podrá expresar mediante un algorit-
mo. Muchas veces las primeras ideas acerca de la funcionalidad ya implican una
descripción de la estructura hardware. Esto sucede principalmente cuando se trata
de diseños de hardware de propósito generala dispositivos programables, como
procesadores, microcontroladores, coprocesadores, dispositivos de lógica progra-
mable, ... Pero aun en estos casos es posible realizar descripciones del sistema con
diversos grados de detalle.
En las descripciones VHDL disponemos de tres mecanismos mediante los cua-
les podemos variar el grado de detalle: los tipos de datos utilizados, la expresión del
paralelismo mediante distintos procesos y los distintos estilos de descripción que
permiten expresar con mayor o menor detalle la estructura.
5.2.1. Tipos de datos
En un principio, si consideramos los sistemas hardware digitales, los tipos de datos

adecuados para describir la implementación de dichos sistemas deberían modelar
los distintos niveles lógicos que pueden tomar las salidas y entradas de los compo-
nentes del sistema. En este sentido, los tipos STD_LOGIC y STD_LOGIC_ VECTOR
definidos en el paquete estándar del IEEE STD_LOGIC_1164 serían adecuados. Uti-
lizar estos tipos de datos nos permite detallar aspectos como la inicialización de se-
ñales, conflictos en un bus compartido o la determinación de valores redundantes
en algunas funciones.
Sin embargo, si quisiéramos describir el sistema sin preocuparnos por este tipo
de detalles podríamos simplificar considerando que los valores de los nodos de un
sistema digital sólo pueden tomar dos valores: 'O' o '1'. En este caso podríamos uti-
lizar los tipos bi t Y bi t_ vector predefinidos en el lenguaje. Por otra parte, la utili-
zación de estos tipos implica detallar la precisión de los datos numéricos utilizados
en los algoritmos. Por ejemplo, si trabajamos con datos reales, deberíamos determi-
nar un formato de punto fijo o punto flotante y asignar un número de bits a las par-
tes entera y decimal o a la mantisa y exponente.
Por otra parte, trabajar a nivel de bits implica determinar el formato y la codifi-
cación de las variables. Por ejemplo, cuando describimos una máquina de estados
finita nos podría interesar no determinar una codificación de estados, ni siquiera el
número de bits que será necesario para almacenar el estado, ya que más adelante
podríamos decidir cambiar el estilo de codificación y, por ejemplo, en lugar de utili-
zar una codificación basada en códigos de Gray utilizar una codificación con un bit
por cada estado (codificación One-hot).
Por tanto, necesitamos tipos de datos que nos permitan obviar los detalles que
aparecen a nivel de bit y de esta forma simplificar y generalizar las descripciones.
Para ello, en VHDL se pueden usar los tipos integer, real, enumerados y tipos
compuestos basados en éstos. Además, existen paquetes estándar del IEEE donde
se definen operaciones matemáticas sobre el tipo REAL y declaraciones de tipos re-
presentando números complejos no incluidas por defecto en VHDL (IEEE 1076.2).
Con VHDL podemos simular descripciones donde distintos componentes se
modelen con distinto grado de detalle y utilicen distintos tipos de datos. En este ca-
so, para la comunicación entre componentes se deberán usar funciones de conver-
sión de tipo, es decir, funciones que toman como parámetro un valor de un determi-
nado tipo (por ejemplo, integer) y devuelven como resultado de su ejecución el
equivalente en el otro tipo de datos (por ejemplo, bit_vector).
5.2.2. Expresión del tiempo y paralelismo

Una de las características que debe poseer un lenguaje de descripción de hardware
es la de permitir expresar que determinados eventos suceden a lo largo del tiempo.
De hecho, el tiempo de simulación es un elemento implícito en dichos lenguajes ya
que a diferencia de los programas escritos en un lenguaje de programación, las des-
cripciones escritas en un HDL no se ejecutan sino que se simulan. Es decir, el resul-
tado de su ejecución se expresa en función del tiempo de simulación.
De manera parecida a lo que ocurre con los tipos de datos, la descripción del
comportamiento de un sistema a lo largo del tiempo puede variar en grado de deta-
lle en función del nivel de abstracción en el que se considere el sistema. Si se pre-
tende modelar únicamente la función que realiza un algoritmo, entonces la descrip-
ción se parecerá mucho a un programa y no será necesario expresar los cambios de
las señales a lo largo del tiempo sino que se podrá utilizar un único proceso ejecuta-
do secuencialmente sin consumir tiempo de simulación. En este caso no tendrá sen-
tido la utilización de señales (signals) sino que se emplearán únicamente variables.
A medida que se detalle la arquitectura del sistema se podrá modelar el parale-
lismo entre distintos componentes así como los retardos en la realización de funcio-
nes. Para expresar el paralelismo se modelará la arquitectura utilizando distintos

procesos que se comunicarán entre sí mediante señales, puesto que éstas permiten
expresar los cambios en relación con el tiempo de simulación.
En un primer momento puede ser interesante poner de relieve que existen fun-
ciones que se realizan de forma concurrente y asignarles retardos reflejando así las
prestaciones del sistema en las simulaciones. Sin embargo, más adelante interesará
añadir detalle a la descripción y aproximarla más a la implementación. Para ello, el
siguiente paso es la introducción de un reloj que determine ciclos en el funciona-
miento del sistema. Mediante la introducción del reloj en las descripciones expresa-
mos el sistema como una serie de cálculos y asignaciones de señales que se realizan
en los distintos ciclos de reloj. A este nivel de detalle en el que se determinan los ci-
clos de reloj en los que se realizan las operaciones se le llama nivel de transferencia
de registros.
Si se desea describir un sistema ya implementado y caracterizado del cual se
conocen no únicamente el vínculo entre operaciones y ciclos de reloj sino los retar-
dos de las operaciones dentro de un ciclo de reloj se utilizarán sentencias de asigna-
ción con la cláusula after.
5.2.3. Estilos de descripción
El diseño de componentes complejos se aborda normalmente por medio de la técni-

ca de dividir el componente en subcomponentes más sencillos interconectados entre
sí. De esta forma, considerando por separado el diseño de cada uno de los compo-
nentes se reduce la complejidad del diseño inicial.
Del mismo modo, a medida que se añade detalle a la descripción de un sistema
electrónico se distinguen en él los elementos que lo componen. Así, en un primer
modelo a nivel funcional es posible considerar el sistema como un todo sin distin-
guir ningún tipo de estructura en su interior, aunque se puede dotar al algoritmo
descrito de una cierta estructura lógica, distinguiendo en él funciones y procedi-
mientos. Posteriormente, a medida que se avanza en la toma de decisiones, se hará
explícita la existencia de subcomponentes, para los cuales se determinará una fun-
ción a realizar dentro del sistema, y una interfaz para su relación con otros compo-
nentes. El particionado puede repetirse hasta que se llegue a un nivel de compleji-
dad de los componentes adecuado para el objetivo que persigue el modelo.
Un lenguaje de descripción de hardware debe permitir expresar el particionado
de un componente en subcomponentes, incorporando así los conceptos de estructu-
ra y jerarquía. Como se explica en el Capítulo 2, en VHDL podemos realizar des-
cripciones con diferentes estilos (algorítmico, flujo de datos y estructural), cada uno
de los cuales permiten expresar el particionado con distinto grado de detalle. Me-
diante un estilo de descripción algorítmico tan sólo será posible expresar una cierta
estructura en la funcionalidad del modelo mediante el uso de procedimientos y fun-
ciones en los procesos. En el extremo opuesto encontramos el estilo de descripción
estructural que nos obligará a formalizar la interfaz de un componente mediante la
declaración de entidad (entity) y podremos expresar la estructura mediante la decla-
ración y referencia de componentes (component) dentro de una arquitectura.
5.3. MODELADO FUNCIONAL
El modelado funcional de un sistema consiste en expresar la función realizada ob-

viando los detalles relacionados con la estructura y la temporización. Este tipo de
modelos son corrientes en las primeras fases del diseño y se utilizan principalmente
para concretar la especificación de la funcionalidad del sistema, de forma que no
haya equívocos entre los especificadores y las personas que han de llevar a cabo el
diseño.
En algunos casos, la funcionalidad a implementar se expresará fácilmente me-
diante un algoritmo. En otras ocasiones, las especificaciones deberán incluir con-
ceptos hardware de la arquitectura del sistema tal como la vería el usuario. Un
ejemplo lo podemos encontrar en las especificaciones de un procesador donde la
funcionalidad se expresa mediante el conjunto de instrucciones que definen opera-
ciones sobre unos recursos hardware. En ambos tipos de sistema puede ser intere-
sante realizar el modelado funcional tanto para disponer de unas primeras medidas
de las prestaciones del sistema como para disponer de unas especificaciones ejecu-
tables (simulables) más fáciles de consultar y validar. .
El proceso es la unidad de construcción básica para describir la funcionalidad.
Normalmente en las descripciones puramente funcionales, sobre todo cuando la
funcionalidad corresponde a la ejecución de un algoritmo, no es necesario expresar
conceptos como la concurrencia entre las diversas tareas en que se descompone la
funcionalidad del sistema sino que basta con expresar el comportamiento de una
forma secuencial. Para ello basta un único proceso en el cual los datos se almace-
nan en variables y las sentencias ejecutadas secuencialmente dentro del proceso re-
alizan las funciones.
En el caso en que la concurrencia entre distintas tareas forma parte de las especi-
ficaciones funcionales de un sistema, ésta puede expresarse utilizando un proceso
distinto para cada tarea concurrente. Un ejemplo de estos sistemas serían sistemas
productor-consumidor donde existe un recurso compartido en el que se almacena in-
formación de forma que los componentes productores acceden al recurso para escribir
en él, mientras que los componentes consumidores acceden para leer la información.
La forma usual de comunicar dos procesos es mediante señales: un proceso ac-
túa como fuente de la cola de eventos de la señal y le asigna valores a lo largo del
tiempo mediante la sentencia de asignación a señal y otros procesos se muestran
sensibles a los cambios en el valor de la señal mediante la sentencia wait.
Cuando dos o más procesos han de escribir en un recurso compartido, podre-
mos escoger entre tres opciones: representar el recurso compartido mediante una
variable global, utilizar una señal resuelta como recurso compartido donde la fun-
ción de resolución determina el valor final de la señal o encapsular la información
compartida dentro de un proceso cuyo código se encargue de arbitrar el acceso.
En el primer caso, el recurso compartido se representa mediante una variable
global, que todos los procesos pueden leer y escribir. En este caso existe el peligro
de realizar descripciones cuya ejecución produzca distintos resultados, dependiendo
del simulador donde se ejecutan. A estas descripciones se les llama no determinis-
tas y se debe principalmente a que el orden en que se ejecutan los procesos activos
en un mismo ciclo de simulación puede variar de un simulador a otro (ver Capítu-
lo 3). Como las variables se actualizan inmediatamente al ser asignadas dentro de

un proceso, es fácil realizar descripciones no deterministas cuando se utilizan varia-
bles globales.
Como ejemplo de compartición de recursos vamos a considerar que dos proce-
sos comparten el acceso a un dispositivo. El acceso al dispositivo se realiza median-
te llamadas a procedimientos definidos en un paquete. Imaginaremos que es necesa-
rio llamar a los procedimientos AbrirDisposi ti vo y CerrarDisposi ti vo antes
de que otro proceso pueda trabajar con el dispositivo y que además el trabajo con el
dispositivo requiere consumir un tiempo de simulación.
Para evitar que cuando un proceso se encuentre trabajando con el dispositivo
pueda intentar abrir el dispositivo otro proceso, implementaremos un semáforo uti-
lizando una variable compartida.
En el Listado 5-1 vemos cómo utilizarían el semáforo dos procesos que quieren
llamar a los procedimientos relacionados con el dispositivo. Antes de llamar al pro-
cedimiento AbrirDisposi ti va cada proceso debe asegurarse de que el semáforo
se encuentra en el estado LIBRE y debe dejarlo en estado OCUPAro para los demás
procesos. Una vez ha terminado el trabajo con el dispositivo cada proceso debe de-
volver el estado LIBRE al semáforo.
Debe notarse que esta descripción sería no determinista, puesto que si ambos
procesos ejecutaran la zona de código relativa al semáforo (sentencia loop) en el
mismo ciclo de simulación, es decir, si los dos procesos intentasen modificar el va-
lor del semáforo en el mismo ciclo de simulación, entonces podemos asegurar que
tan solo uno de los procesos conseguiría el acceso al dispositivo en ese ciclo pero
no podemos asegurar cuál de ellos sería, ya que esto depende del orden en que se
ejecuten los procesos.
type tAcceso ia (LIB~,;; CX;:UP1\OO);

shared variable Semafoto': 'tAccesó; ,00, :: ~ ,
,::.:::. .. '"
PI: process
begin
-- Tareas propias del proceso PI
-- Espera hasta que el acceso este libre

loop
if Semafo~ ~ .LlB,RE then
semafox:? :~ tlCUPAOO;
exit;
end if;
wait for lO'ns;
end loop;
AbrirDispositi VOl
Trabaja;
CerrarDispositivo;
Semaforo := LIBRE;
end process;
P2: process
begin
-- Tareas. propias del proceso P2
-- Espera hasta que el acceso este libre

loop
if Semaforo = LIBRE then
Semaforo := OCUPADO;
exit;
end if;
wait for lO'ns;
end loop;
AbrirDispositivo;
Trabaja;
CerrarDispositivo;
Semaforo := LIBRE;
end process;
LISTADO 5-1. Ejemplo con variables compartidas.
La segunda opción para conseguir que varios procesos escriban sobre un mis-
mo recurso consiste en utilizar una señal de tipo resuelto. En este caso la simula-
ción será determinista siempre que la función de resolución no dependa del orden
en que le pasen los valores en el vector de valores asignados a la señal. Esta solu-
ción no se emplea normalmente en descripciones de nivel funcional sino que es
muy útil en descripciones más detalladas del hardware para modelar el acceso a bu-
ses compartidos mediante el uso de buffers tristate y se verá un ejemplo de ello
cuando se modele con más detalle el procesador y su interacción con el bus de me-
moria.
En el Listado 5.2 vemos el mismo ejemplo de compartición de un dispositivo
del listado anterior pero con el semáforo implementado mediante una señal de tipo
resuelto en la que escriben dos procesos. La señal Semaforo es del tipo resuelto
tAcceso y puede tomar los valores LIBRE, indicando que ninguno de los dos proce-
sos ha entrado o pide entrar en la zona de trabajo con el dispositivo, PETICIONI,
indicando que el proceso PI solicita trabajar con el dispositivo, PETICION2, indi-
cando que el proceso P2 solicita el dispositivo, OCUPAIXJI, indicando que el proceso
PI está trabajando con el dispositivo y OCUPAIXJ2 que significa que el proceso P2
mantiene ocupado el dispositivo.
Para acceder al dispositivo, los procesos han de asignar a la señal Semaforo su
valor de petición y esperar a que ésta tome el valor de ocupado que les corresponde.
Seguidamente, el proceso que obtiene el permiso, asigna su valor de ocupado a la
type tAccesoNoResuelto ia (LIBRE, PETICIONl, PETICI0N2, OCUPADOI, OCUPAD02);

type tAccesoVector ia array (natural range <» of tAccesoNoResuelto;
function ResuelveAcceso{Peticiones: tAccesoVector)

return tAccesoNoResuelto ia
begin
for 1 in Peticiones'range loop
if Peticiones (1) = OCUPADOl ar Peticiones(I) = OCUPAD02 then
return Peticiones{!);
endif;
end loop;
for 1 in Peticiones'range loop

if Peticiones (1) = PETICIONl then
return OCUPADOI;
elaif Peticiones-tI)·= PF:1'ICION2then
return OCUPAD02;
end if;
end loop;
return LIBRE;
end ResuelveAcceso;
subtype tAcceso ia ResuelveAcceso tAccesoNoResuelto
signal Semaforo : tAcceso;
Pl:process
begin
-~_Tareas proceso. PI
Semaforo <= PETICIONl;

if Semaforo /= ocuPArol then
wait until Semaforo = OCUPADOI;
end if
Semaforo <= OCUPADOl;
AbrirDispositivo;
Trabaja;
CerrarDispositivo;
Semaforo <= LIBRE;
end process;
P2:process
begin
-- Tareas proceso P2
Semaforo <= PETICION2;

if Sernaforo /= ocUPAOO2 then

wait until semaforo = OCUPAOO2 ¡
end if
Semaforo <= OCUPAOO2¡
AbrirDispositi VQ;
Trabaja¡ .
cerrarDispositivo;
Sernaforo <= LIBRE;
end process;
LISTADO 5-2. Ejemplo de compartición de recursos con funciones de resolución.
señal Semaforo para evitar que ésta cambie de valor ante peticiones del otro proce-
so. La función de resolución Resuel veAcceso se encarga de mantener el valor ocu-
pado de la señal si alguno de los procesos está escribiendo su valor de ocupado. De-
be notarse que esta descripción tampoco es determinista, ya que el orden en que los
procesos obtengan el dispositivo en el caso de solicitarlo simultáneamente depende-
rá del orden en que le lleguen los valores a la función de resolución, 10 cual es de-
pendiente del simulador.
Finalmente, en la tercera opción para compartir recursos escritos por varios
procesos, el recurso compartido se encapsula dentro de un proceso donde puede re-
presentarse mediante una variable local y se definen señales para el acceso de cada
proceso que desee leer o escribir información. En el proceso que encapsula el recur-
so se incluirá código para arbitrar la escritura simultánea de información.
En el Listado 5-3 se muestra la implementación del semáforo mediante esta
técnica. El proceso Semaforo contiene la variable Acceso donde se guarda el esta-
do del semáforo. Los procesos PI y P2 acceden a dicha variable mediante las seña-
les PeticionPl, OcupadoPl y PeticionP2 y OcupadoP2, respectivamente.
signal PeticionPl, OcupadoPI : boolean;

signal PeticionP2, OcupadoP2 : boolean;
P1: process
begin
-- Tareas proceso PI
PeticionPI <= TRUE;

wait until OcupadoPI;
AbrirDispositivo¡
Trabaja¡
GerrarDispositivo;
peticionPl <= FAL.')E;
end process;
P2: process
begin
-- Tareas proceso P2
PeticionP2 <= TROÉ;

wait until OcupadoP2;
end process;
Semaforo: process (p~tn:i~fipl;,tf~tlhónP2)

type tAcceso i8 (LIBRE, PI, P2);
variable Acceso :;tÁcceiOY' -; r-
begin
if PeticionPI and not PeticionP2 then
Acceso := PI;
elaif PeticionP2 and not PeticionPI then
Acceso := P2;
elsif p~t¡~ionPI and PeticionP2 and Acceso ~·~¡BREthen
Acceso := PI;
end if.;
if Acceso = PI then
OcupadóEl_ <= TRUE;
elae _
OcupadoPI <= FALSE;
end if;
if Acéés~;'~P2 then
ocupadÓP2 <= TRUE;
elee
OcupadoP2 <=rALSE~
end if;
end process;
LISTADO 5-3. Ejemplo de información compartida encapsulada en un proceso.

A diferencia de los Listados 5-1 y 5-2, la solución empleada en el Listado 5-3 es

determinista, es decir, debe funcionar exactamente igual en todos los simuladores.
En el caso de que los dos procesos activen su señal de petición de forma simultánea,
el acceso se concederá al proceso PI. Esto se deduce de la forma como se comprue-
ban las condiciones en la primera sentencia if del proceso Semaforo.
Los tipos de datos utilizados en las descripciones funcionales suelen ser próxi-
mos a los conceptos que se utilizan en la especificación. Será en este tipo de descrip-
ciones donde se utilizarán con mayor frecuencia los tipos definidos por el usuario.
5.3.1. La máquina rudimentaria
Para ejemplificar el estilo de descripción VHDL que se puede realizar en las prime-
ras etapas de la concepción de un sistema electrónico, en este apartado escribiremos
el modelo funcional del procesador que constituirá el núcleo del ejemplo utilizado
en el resto del capítulo. En primer lugar se especificará la arquitectura del procesa-
dor a nivel de conjunto de instrucciones y posteriormente se comentará la descrip-
ción VHDL que sirve para experimentar y trabajar con dichas especificaciones.
5.3.1.1. Arquitectura del procesador a nivel de lenguaje máquina
El procesador que utilizaremos está basado en la "Máquina Rudimentaria" creada

en el Departamento de Arquitectura de Computadores de la Universitat Politecni-
ca de Catalunya [SPC97]. Se trata de un procesador tipo Von Neuman con los da-
tos y programas almacenados en una misma memoria. Vn primer esquema del
procesador desde el punto de vista del conjunto de instrucciones se detalla en la
Figura 5-1.
Antes de la ejecución de cada instrucción ésta se carga de la dirección de me-
moria contenida en el contador de programas (CP) al registro de instrucción (RI).
Seguidamente, la instrucción cargada se descodifica y se ejecuta, realizando las co-
rrespondientes operaciones en la unidad artimético-lógica (VAL) y modificando los
registros del procesador (banco de registros, CP y los indicadores de cero [C] y ne-
gativo [N]).
Podemos clasificar las instrucciones en tres grupos distintos:
• Instrucciones de acceso a memoria. Realizan las transacciones de datos en-

tre la memoria y el banco de registros del procesador. El registro afectado
por el acceso se determina en un campo de la instrucción (registro destino
[Rd] o registro fuente [Rf] según la instrucción) y la dirección de memoria se
calcula sumando un registro del banco de registros especificado en un campo
de la instrucción (registro índice [Rx]) con la dirección base especificada en
la instrucción (campo DireccionBase). Cuando se carga un valor de la me-
moria al banco de registros se actualizan los indicadores N y C de acuerdo
con el valor cargado.
Registro de instrucción
Banco
de
Contador de programa
Registros
Memoria
-- de
programas
y
datos
FIGURA 5-1. Arquitectura del procesador.
• Instrucciones de salto. El CP se incrementa después de la ejecución de cada

instrucción, excepto para las instrucciones de salto. En éstas se puede cam-
biar el secuenciamiento normal de las instrucciones cargando en el CP una
dirección contenida en la instrucción. La instrucción de salto incondicional
siempre carga su dirección en el CP mientras que las demás instrucciones de
salto comprueban que se cumpla alguna condición sobre los indicadores N y
C antes de cargar su dirección. En caso de que la condición no se cumpla, el
CP se incrementa, no modificándose así la secuencia normal del programa.
• Instrucciones aritmetico-Iógicas. Realizan operaciones aritméticas o lógi-

cas, tomando como datos de entrada valores almacenados en el banco de re-
gistros o en la propia instrucción y almacenando el resultado en el banco de
registros. Los indicadores N y C se actualizan de acuerdo con el resultado de
la operación. Los registros que contienen los datos para la operación y el re-
gistro donde se almacenará el resultado se especifican en campos de la ins-
trucción (Rfl y Rf2 para los registros fuente 1 y 2 Y Rd para el registro desti-
no de la operación). Existen dos instrucciones aritméticas (ADDI y SUBI)
que operan el contenido de un registro con un valor inmediato almacenado
en un campo de la propia instrucción. Todas las instrucciones aritméticas ac-
tualizan los indicadores N y C de acuerdo con el resultado de la operación,
es decir, C se carga a verdadero si el resultado de la operación es cero y a fal-
so en caso contrario y N se carga a verdadero si el resultado de la operación
es negativo y. a falso en caso contrario.
En la Tabla 5-1 se describen las instrucciones.

TABLA 5-1. El repertorio de instrucciones de la máquina rudimentaria
Instrucciones de acceso a memoria
LOAD Carga el contenido de la dirección de memoria indicada por los campos

(Rd, Rx, DireccionBase) DireccionBase y Rx en el registro del banco de registros indicado por el
campo Rd. Los indicadores C y N se actualizan según el valor cargado.
STORE Almacena el contenido del registro del banco de registros indicado por el
(Rf, Rx, DireccionBase) campo Rf en la posición de memoria indicada por los campos Direccion-
Base y Rx.
Instrucciones de salto
BR (Direccion) Salto incondicional. Carga el campo Direccion en el CP.
BEQ (Direccion) Salta si igual. Si C es verdadero carga el campo Direccion en el CP.
BL(Direccion) Salta si más pequeño. Si N es verdadero carga el' campo Dirección en el CP.
BLE(Direccion) Salta si más pequeño o igual. Si N o C son verdaderos carga el campo Di:"
reccion en el CP.
BNE(Direccion) Salta si no igual. Si C es falso carga el campo Direccion en el CP.
BGE(Direccion) Salta si mayor o igual. Si N es falso o C es verdadero carga el campo Di-

recci on en el CP.
BG(Direccion) Salta si más grande. Si N Y C son ambos falso carga el campo Direccion
en el CP.
Instrucciones aritmético-lógicas
ADDI(Rd, Rfl , Numero) Suma el contenido del registro del banco de registros indicado por el cam-
po Rfl con el valor contenido en el campo Numero. El resultado se alma-
cena en el registro indicado por el campo Rd.
SUBI(Rd, Rfl , Numero) Resta el valor contenido en el campo Numero de la instrucción del conte-
nido del registro del banco de registros indicado por el campo Rfl. El re-
sultado se almacena en el registro indicado por el campo Rd.
ADD(Rd, Rf'l , Rf2) Suma el contenido del registro indicado por el campo Rfl al contenido
del registro indicado por el campo Rf2 y el resultado se almacena en el
registro indicado en el campo Rd.
SUB(Rd, RfI, Rf2) Resta el contenido del registro indicado por el campo Rf2 al contenido
del registro indicado por el campo Rfl y el resultado se almacena en el
registro indicado en el campo Rd.
ASR(Rd, Rf2) El contenido del registro indicado por el campo Rf2 se desplaza un bit a
la derecha y el resultado se almacena en el registro especificado en el
campo Rd. El desplazamiento es aritmético, es decir, se conserva el signo.
ANDL(Rd, Rfl , Rf2) Se realiza una operación Y-lógica bit a bit entre el contenido del registro
indicado en el campo Rfl y el contenido del registro indicado en el cam-
po Rf2. El resultado se almacena en el registro indicado en el campo Rd.
5. Modelado con VHOL 263
Debemos aclarar que aunque la estructura hardware del procesador se encuen-

tra mucho mas detallada en [SPC97], por el momento nos limitamos a describir lo
estrictamente necesario para poder experimentar con el conjunto de instrucciones.
Así, detalles como el número de bits de los registros o el formato de instrucción no
son considerados en este apartado.
5.3.1.2. Modelo funcional de la máquina rudimentaria
El objetivo de una descripción funcional de la arquitectura del procesador presenta-

da en el apartado anterior sería disponer de un primer modelo capaz de ejecutar un
programa. Este modelo podría utilizarlo tanto el diseñador, cuyo objetivo es obtener
una implementación del procesador, como el escritor de compiladores, para poder
ejecutar el código generado, y así poder evaluar distintas modificaciones en el con-
junto de instrucciones. Aunque el modelo que vamos a realizar sólo permitirá eje-
cutar pequeños programas y su función es más bien servir de ejemplo y de especifi-
cación del conjunto de instrucciones, que no ser una herramienta de evaluación de
compiladores, al final del capítulo se proponen ejercicios que aumentarían la utili-
dad de esta descripción.
En primer lugar definiremos los tipos de datos que vamos a utilizar en el mode-
lo y las operaciones que necesitaremos realizar con dichos tipos. Para ello, además
de utilizar los tipos de datos y operaciones predefinidos en el lenguaje, declarare-
mos tipos de datos propios y los incluiremos dentro de un paquete que llamaremos
PaqueteMRFuncional.
Los valores numéricos que manejará el procesador serán de tipo entero, de for-
ma que no especificaremos su formato en número de bits. Para los recursos que
agrupan datos de forma indexada, como la memoria de datos y el banco de registros,
definiremos un tipo de datos llamado tVectorDatos como un vector de enteros.
Para las instrucciones tampoco definiremos ningún formato sino que una ins-
trucción se considerará compuesta por un conjunto de cuatro campos: un primer
campo donde se indicará el código de operación y tres campos de tipo natural que
corresponderán a los parámetros de cada instrucción según la Tabla 5.1. En las ins-
trucciones que tengan menos de tres parámetros se utilizarán los primeros campos y
se ignorará el valor de los restantes. El tipo de datos utilizado para las instrucciones
lo llamaremos tInstruccion y utilizaremos un registro (record) para definirlo.
Utilizaremos el tipo enumerado (tCodigoOperacion) para poder nombrar las ins-
trucciones con su mnemónico correspondiente. Al independizar la funcionalidad de
las instrucciones de su formato y definir un tipo de datos para poder representar las
instrucciones a un-alto nivel de abstracción, nos encontraremos con que las varia-
bles que almacenan las instrucciones son de diferente tipo que las variables que al-
macenan los datos. Como consecuencia no podremos almacenar instrucciones y da-
tos en un único vector que representaría una memoria única de datos y programas
sino que nos veremos obligados a definir dos vectores separados para almacenar
instrucciones y datos.
En general, intentaremos realizar un modelo lo más independiente posible de
las características cuantitativas del procesador, como, por ejemplo, el número de bits
de los registros, el tamaño de la memoria y el número de registros en el banco de re-

gistros. Sin embargo, para poder especificar el tamaño de los vectores es necesario
definir algunas de estas cantidades. Por ello, en la declaración de paquete declarare-
mos las constantes cNumInst, cNumDatos y cNumRegistros que corresponderán al
número de direcciones de la memoria de instrucciones, el número de posiciones en
la memoria de datos y el número de registros del banco de registros.
Finalmente deberemos declarar las operaciones para los tipos de datos utiliza-
dos que no estén predefinidas en el lenguaje. En nuestro caso necesitaremos realizar
una operación y lógica bit a bit entre dos datos para ejecutar la instrucción ANO
del procesador. Puesto que los datos son de tipo integer, necesitaremos una fun-
ción que realice la operación Y lógica bit a bit entre dos enteros.
A continuación se muestra el código VHOL correspondiente a la declaración
del paquete PaqueteMRFuncional.
package PaqueteMRFuncional is
type tVectorDatos is array ( natural range <> ) of integer;
type tCodigoOperacion is (ADD, SUB, ASR" ANDL, ADDl, SUBI,

LOAD, S'IPRE, BR, BL, &3,. BEQ, .
BNE, BLE, &3E);
type tlnstruccion is
record
CodigoOperacion : tCodigoOperacion;
Canpol : natural;
Canpo2 : natural;
Campo3 : natural;
end record;
type tVectorlnst is array (natural range <» of tInstruecion;
constant cNurnInst : natural;

constant cNumDatos : natural;
constant cNumRegistros : natural;
function "AND" (A, B: integer) return integer¡
end PaqueteMRFuncional;
LISTADO 5-4. Declaración del paquete PaqueteMRFuncional.
Como podemos observar en la declaración de paquete, faltan por definir tanto

el valor de las constantes como el cuerpo de la función "ANO". Podríamos haber
asignado directamente un valor a las constantes pero por motivos prácticos es con-
veniente hacerlo en la definición del cuerpo del paquete. En el caso de que las cons-
tantes estén definidas en la declaración de paquete, si quisiéramos cambiar su valor
y volver a simular la descripción del procesador sería necesario analizar de nuevo

todas las descripciones que utilizasen el paquete, mientras que si las constantes sólo
se definen en el cuerpo del paquete únicamente es necesario reanalizar éste.
Para realizar la función Y lógica bit a bit de dos enteros deberemos conside-
rar su representación binaria tanto para números positivos como negativos. En
nuestro caso consideraremos que el número de bits de un dato no superará una
cierta cantidad (cMaxNumBi ts) que definiremos como constante y la representa-
ción de los números negativos será en complemento a dos. Además, aprovechare-
mos que existen paquetes estándar (STD_LOGIC_1164) que definen tipos para
lógica multivaluada y vectores de estos tipos (std_logic_vector y signed),
además de otros paquetes que definen funciones de conversión de enteros a su re-
presentación binaria usando el tipo SIGNED, para realizar la función "AND" sobre
los datos convertidos a tipo signed. La función "AND" para estos datos sí está de-
finida en el paquete STD_LOGIC_ARITH.
El cuerpo del paquete sería el siguiente:
library IEEE;
use lEEE.STD_LOGIC_l164.all;
use IEEE.STD_LOGIC_ARITH.all;
package body PaqueteMRFuncional 1&
constant cNumInst ¿: natural := 10;

constant cNumDatos ': natural := 200;
constant cNumRegistros : natural := 8;
constant cMaxNumBits : natural := 128;
function "AND" (A, B: integer) return integer 18
variable M3V : signed(O to cMaxNumBits-l);
variable BBV : signed(O to cMaxNumBits-1);
variable Result : stq_logic_vector(O to cMaxNumBits-l);
begin
ABV := Conv_signed(A, cMaxNumBits);
BBV := Conv_signed(B, cMaxNumBits);
Result := std_logic_vector(ABV) and stq_logic_vector(BBV);
return Conv_integer(signed(Result));
end "AND";
end PaqueteMRFuncional;
LISTADO 5-5. Cuerpo del paquete PaqueteMRFuncional.
De acuerdo con los objetivos de este primer modelo, no describiremos ningún

detalle de la estructura interna del procesador, ni su interfaz con el resto del sistema.
Sin embargo, para poder simular cualquier descripción ha de existir una entidad. En
nuestro caso utilizaremos una entidad vacía:
entlty MaquinaRudimentaria ls
end MaquinaRudimentaria;
La arquitectura del modelo funcional será muy yarecida a un programa escrito

en un lenguaje de programación como e
o Pascal. Unicamente incluirá un proceso,
ya que no pretendemos describir la sincronización entre las distintas tareas, es decir,
cuándo o en qué orden se realizan. El objetivo de esta arquitectura es mostrar qué
funciones realiza el conjunto de instrucciones del procesador.
Dentro del proceso único podemos organizar el código según las tareas a reali-
zar. La ejecución de instrucciones puede dividirse en dos grandes tareas: buscar y
cargar de la memoria la instrucción que se va a ejecutar, y la propia ejecución de la
instrucción cargada. Para cada una de estas tareas escribiremos un procedimiento
dentro del proceso, pero antes vamos a centrarnos en la estructura del proceso sin
considerar el código de los procedimientos.
La arquitectura que llamaremos Funcional se muestra a continuación:
use work.PaqueteMRFuncional.all;
architecture Funcional of MaquinaRudiIDentaria is

begio
Procesador:process
variable CP integer;
variable RI tInstruccion;
variable Programa tVectorlnst(O to cNumInst);
variable MemDatos tvectortatos (O to cNuroDatos);
variable N boolean;
variable C boolean;. ,
variable Registros tVectorDatos(O to cNumRegistros);
alias Rd integer is RI.Carrpol;

alias Rx integer i8 RI. Carrpo2;
alias DirecciOnBase : »ínteqer i8 RI.Carrpo3;
alias Rf integer i8 RI. Carrpol;
alias Rfl integer i8 RI.Carrpo2;
alias Numero integer i8 RI,~arrpo3;
alias Rf2 integer i8 RI.Carrpo3;
alias Direccion integer i8 RI. CaIlIJOl
;
procedure Leerlnstruccion i8
end Leerlnstruccion;
procedure Ejecutarlnsq:uccion ia
end EjecutilrtFtrucc:iolJ;
procedure Inf.ciatizaMemoria i8
begio
Programa (O) .- ( LOAD, 2, O, O );
Programa(l) ,_ ( LOAD, 3, Ó, 1 )i
Programa(2) := ( ADD, 4, 3. 21 l'
Programa(3) ti'i (STORE, ~, O, 2);

MemDat:.:os(O) !.;: le;
MemDatosU) := 20;
eDd InicializaMemoria;
'".; ~'. .... "_ ,00_' _. _', .. _~
begin
-- Inicialización del programa
InicializaMemoria;
CP ,;: O;
Registro?(O) ::;0;
loop -', ..
LeerIhsfruó(:ión;
EjecutarInstruccioh;
wait for 10 ns;
end loop;
end process;
end Funcional;
LISTADO 5-6. Arquitectura funcional de la maquinaria rudimentaria.
En primer lugar observamos la indicación mediante la sentencia use de que a lo

largo de la descripción utilizaremos los objetos definidos anteriormente en el pa-
quete PaqueteMRFuncional. A continuación se define el cuerpo de la arquitectura,
donde únicamente se encuentra el proceso llamado Procesador. Este proceso se
compone de la declaración de variables y procedimientos y el cuerpo del proceso.
Los recursos de almacenamiento del procesador se representarán mediante va-
riables: el contador de programas (variable CP, el registro de instrucciones [RI)), la
memoria de programas (Programa), la memoria de datos (MemDatoS), los indicado-
res (Ny c) y el banco de registros (Registros).
La variable RI es la que presenta mayor complejidad en cuanto a la informa-
ción que se almacena en ella. Aunque el tipo tInstruccion se utilice para todas
las instrucciones, los tres campos numéricos del tipo tienen distinto significado en
cada instrucción. Por ello, sería cómodo poder referirse a cada campo con un nom-
bre de acuerdo al significado que tenga en cada momento. Esto se consigue en
VHDL por medio de la declaración de alias de una variable. En nuestro caso defini-
mos los nombres Rd, Rf Y Direccion para el campo Canpol de la variable RI, Rx Y
Rfl para Canpo2 y DireccionBase, Numero y Rf2 para Canpo3.
El cuerpo del proceso consta de dos partes: una inicialización de las variables y
la ejecución de las instrucciones. En la inicialización de variables se realiza una lla-
mada al procedimiento InicializaMemoria el cual inicializa las variables Pro-
grama y MemDatos introduciendo un pequeño programa que suma el contenido de
las direcciones Oy 1 de la memoria de datos y almacena el resultado en la dirección
2. Para ello utiliza los registros 2 y 3 para los operandos y el 4 para el resultado. El
resto de la inicialización de variables consiste en indicar que el programa empieza
en la dirección O de la memoria de programas asignando O a la variable CP y se in-
troducen los datos necesarios en el banco de registros.
Posteriormente a la inicialización, el proceso entra en un bucle que va cargando

y ejecutando instrucciones, deteniéndose un tiempo arbitrario de 10 ns después de
la ejecución de cada instrucción. Esta espera entre instrucciones evita que todo el
programa se ejecute en el tiempo de simulación O y permite tener una representa-
ción gráfica de la evolución de los contenidos de los registros del procesador y la
memoria en los simuladores que permitan representar variables en forma de diagra-
ma de ondas.
Como ya hemos dicho anteriormente, una descripción de este estilo debe servir
principalmente para detallar y depurar las especificaciones y, por lo tanto, a este ni-
vel se utilizará el simulador de una forma interactiva. modificando y depurando dis-
tintas alternativas y controlando el propio diseñador el final de la simulación. Sin
embargo, mejorando la interfaz con el usuario de la descripción, por ejemplo, alma-
cenando los programas y datos en ficheros, podría servir como herramienta de eva-
luación para el desarrollo de compiladores.
Nos queda por escribir el código correspondiente a los dos procedimientos.
LeerInstruccion copia el contenido de la posición de la memoria de datos apun-
tada por el contador de programas al registro de instrucciones y actualiza el conta-
dor de programas incrementándolo en una unidad.
procedure LeerlnsEruccion ls
begin
RI := Programa(CP);
CP := CP + 1;
eod Leerlnstruccion;
LISTADO 5-7. Procedimiento leerlnstruccion del proceso UControl en la arquitec-

tura Funcional.
Las tareas a realizar para ejecutar una instrucción dependen en gran medida
del tipo de instrucción que se haya cargado en el registro de instrucciones. Por
ello, aunque la ejecución de todas las instrucciones la realiza el procedimiento
EjecutarInstruccion, utilizamos la sentencia case para seleccionar las sentencias
a ejecutar en función de la instrucción de que se trate. Para cada instrucción existe
una cláusula when en la que se actualizan los recursos de almacenamiento del pro-
cesador de acuerdo con su ejecución.
procedure EjecutarInstruccion is
variable DirAbsoluEa :integer;
begin
case RI.CodigoOperacion ls.

when LOAD =>
DirAbsoluta := DireccionBase + Registros(Rx);
Registros (Rd) := MemDato~(OirAbsoluta);

N := (Regist'ros (Rdt < n):
C := (Registros(~) =
O);
wben S'roRE =>
DirAbsoluta : = DireccionBase + Registros (Rx) ;
MemDatos(DirAbsoluta) ~= Registros{Rd);
N := (Registros(Rd) < O);
C := (Registros (Rd) = Q);
wben BR =>
CP := Direccion;
wben Ba;¡ =>
if C then
CP := Direccien;
end if;
when BL =>
if N then
CP := Direccion;
end if;
when BLE =>
if C or N then
CP := Direccion;
end if;
when ENE =>
if not C then
CP := Direccion;
end if;
when BGE =>
if C or (not N) then
CP := Direccion;
end if;
when BG =>
if (not C) or (not N) then
CP := Direccion;
end if;
wben ADDI =>
Registros (Rd) : = Registros (Rfl) + Numero;
e : = Registros (Rd) = O;
N : = Registros (Rd) < O; •
wben SUBl =>
Registros (Rdl :" Registros (Rfl) '"' Numero;
C := Registros(Rd) = O;
N := Re9ist;rosUl41 < O;
wben ADD =>
Regist¡os (Rq) ; ;,=: Regis~ro¡> (R,t:q+ .Reg:i.~t::¡:os(Rf2) ;
';', ~" ",.. _'o .. " ...
C : = Registros títdl = O; . "

N : = ~égistros (ltd) t'd;'
wben SUB =>
Registros (Rd) := R~stros(Rfl) - Registros (Rf2);
e ::: Registros (Rdl e" O;
. N : = Registros (Rd) < O;
when ASR =>

Registros(RdI := Registros(Rf2) /2;
e := Registros(Rd) = O;
N := Registros(Rd) < O;
when ANDL =>
Registros (Fkj) .:= Registros (Rfl) and Registros (Rf2) ;
e := Registros(Rd) = O;
N := Registrps(Rd) <:Q;
en~ ::ase¡
end Ejecutarlnstruccion;
LISTADO 5-8. Procedimiento Ejecutarlnstruccion del proceso UControl en la arqui-

tectura Funcional.
5.4. MODELADO ESTRUCTURAL
En el apartado anterior hemos visto cómo se podía estructurar un proceso defi-

niendo procedimientos y funciones. Esta es una de las distintas formas que exis-
ten en VHDL para estructurar el código. Además de la posibilidad de organizar
las sentencias en procedimientos, existen otros dos modos de particionado de las
descripciones: la distribución de código en diferentes procesos dentro de una ar-
quitectura y la opción de expresar jerarquía particionando la descripción en com-
ponentes.
La división del código en procesos nos ayuda a modelar la concurrencia y sin-
cronización entre tareas,. mientras que el particionado en componentes, además de
permitimos definir la arquitectura de cada componente, cuyos procesos se ejecuta-
rán en paralelo a los de los demás componentes, nos obliga a definir una interfaz
(entidad) para cada componente de forma que su relación con los demás componen-
tes de un sistema quede perfectamente definida.
En la elección de los tipos de datos de los puertos de la entidad deben conside-
rarse dos aspectos: el nivel de abstracción de la descripción y la compatibilidad con
otros componentes del sistema. En cuanto al nivel de abstracción, si todos los com-
ponentes del sistema se describen a nivel funcional y mediante la descripción es-
tructural del sistema únicamente se desea realizar un particionado de la funcionali-
dad, entonces será una buena opción trabajar con tipos de datos que no detallen a
nivel de bits la estructura de los datos, ya sean tipos predefinidos en el lenguaje
(integer, natural, real, character, ...) O tipos definidos por el usuario. En
cambio, si algunos componentes del sistema se encuentran detallados a nivel de bit
o buses de bits, será conveniente utilizar tipos de datos que reflejen este detalle en
el sistema.
Si los distintos componentes de. una descripción estructural no comparten los
mismos tipos de datos en los puertos, será necesario utilizar funciones de conver-
sión para convertir los datos de un tipo a otro.
5.4.1. La máquina rudimentaria: interfaz

y primer particionado
En este apartado vamos a definir con más detalle el procesador, realizando una des-
cripción que se pueda utilizar en la simulación de la descripción estructural de un
sistema. Para ello debemos definir en primer lugar su interfaz con el entorno, es de-
cir, debemos escribir una entidad donde se incluyan todas las entradas y salidas del
procesador. Esta entidad deberá permanecer invariable en los refinamientos sucesi-
vos que se realicen en la arquitectura del procesador, puesto que con ella se preten-
de independizar la descripción del sistema de la descripción del procesador.
En la interfaz del procesador necesitaremos las señales de inicialización (rni-
cializa) y reloj (Reloj) habituales en los sistemas digitales síncronos, además de
las señales necesarias para realizar accesos a la memoria de programas y datos. Su-
pondremos que nuestro procesador no será el único maestro del bus de memoria y,
por lo tanto, deberá pedir acceso al mismo mediante una señal de petición de bus
(PeticionBus). En el sistema habrá un árbitro de bus que notificará al procesador
mediante una señal (BusLibre) cuando puede realizar un acceso a memoria. Final-
mente el procesador necesitará indicar la dirección de memoria a la que desea acce-
der a través de un bus de direcciones (Direccion), señalar si el acceso a memoria
es de lectura o escritura mediante una señal de control (Escribe), indicar a la me-
moria que los datos, direcciones y señales de control son válidos mediante una se-
ñal de habilitación (Habili taMem) y leer o escribir datos a través de un bus de datos
bidireccional (Datos).
Para los tipos de los puertos escogeremos los tipos multivaluados estándar defi-
nidos en el paquete STD_LOOrC_1164. Con ello podemos describir a nivel de bit las
operaciones que se realizan en el procesador y expresar conceptos hardware como
la alta impedancia que se producirá en el bus de datos cuando no se realicen acce-
sos a memoria.
El siguiente listado muestra la definición de entidad para el procesador.
library IEEE;
use IEEE.STD~DOGIC_1164.all;
entity MaquinaRudimentaria is
port (
Inicializa in stq_logic;
Reloj in std,._logic;
BusLibre in std,_logic;
Datos inout std_logic_ vector (15 downto O);
Direccion out si:d..logic_v!!ctor(7 downto O)i
HabilitaMem : out std,_logic;
Escribe out std_logic;
PeticionBus : out std_logic .) ;
end MaquinaRudimentaria;
LISTADO 5-9. Entidad de la máquina rudimentaria.

272 VHDL. Lenguaje estándar de Dlseño Electrónico
Ahora debemos escribir una arquitectura para la entidad definida, de forma que
se reconozcan los estímulos que otros componentes del sistema enviarán al procesa-
dor a través de los puertos de entrada y se proporcionen las respuestas adecuadas en
los puertos de salida. La existencia de esta interfaz nos obliga a respetar ciertas rela-
ciones causa-efecto de las señales. Por ejemplo, el procesador no deberá realizar un
acceso al bus si la entrada BusLibre no está activa, sino que deberá realizar antes
una petición del bus activando PeticionBus. En las Figuras 5-2 y 5-3 se detallan
los accesos a memoria para lectura y escritura, En principio el procesador accederá a
la memoria en un ciclo de su reloj, sin considerar ninguna restricción respecto al or-
den y temporización con que deben activarse las señales Direccion, Datos, Escri
be y Habili taMem. Sin embargo, cuando se componga el sistema con dispositivos
reales, la memoria necesitará que los datos, direcciones y la señal Escribe estén es-
tables un cierto tiempo antes y después de la activación y desactivación de la señal
HabilitaMem. Esto se conseguirá añadiendo la lógica necesaria en el sistema y, por
lo tanto, no nos preocuparemos de ello en el modelo del procesador.
La arquitectura del procesador, aunque no se describa a nivel de transferencia
entre registros, será mucho más cercana al hardware que la descripción meramente
funcional. Ello nos obliga a utilizar tipos de datos capaces de representar los valores
lógicos que toman las conexiones de los circuitos digitales y a definir los formatos a
nivel de bits para las distintas instrucciones.
En cuanto al formato, distinguimos cuatro tipos de instrucciones: instrucción
de lectura de datos de memoria, instrucción de escritura de datos a memoria, ins-
trucciones de salto e instrucciones aritmético-lógicas. Estas últimas tendrán un for-
mato distinto para la suma y la resta con direccionamiento inmediato. Las instruc-
ciones de lectura, escritura, salto y aritmético-lógicas se distinguen entre sí por el
Reloj
PeticíonBus
BusLibre
HabílitaMen
.'
.,
.,
. .,.
,
------i------1- -----: ~
"
Escribe -----:--- -~--

Direccion I¿JIJ///J'lll/b¡J/////W!/I/
Datos 1!íZ1¡7í1711l1lb//)¡ZY/$/I//
: ' : ' ¡ :
FIGURA 5-2. Ciclo de lectura.

I[
t
¡, Reloj
PeticionBus
BusLibre
IL_
HabilitaMen
Escribe -------~-------------r Jil- ----!- - - - - - ~- - - - - - --

Direccion
1/!f!!II7///llq//IlI//J/lI/lJI
Datos lIIipI/flJIl(CJXIIíf/l/ip/lll
FIGURA 5-3. Ciclo de escritura.
valor de los dos bits más significativos de la instrucción, y dentro de las instruccio-
nes aritmético-lógicas se distingue el modo de direccionamiento (inmediato o regis-
tro-registro) según el campo OP de la instrucción. El formato para cada tipo de ins-
trucción se muestra en la Figura 5-4.
---
I I
2
I
00
3
Rd
3
Rx I
8
Dirección Base Formato de la instrucción LOAD
I---
2 3 3 8
I I
01 Rl Rx I Dirección Base Formato de la instrucción STORE
I---
2 3 3 8
Formato de las instrucciones
I I
10 Cond 000 I Dirección de salto
I
--_ ......
2
11 I
3
Rd I
3
Rl1 I Número
5
I
3
OP I
Formato de las instrucciones
de suma y resta de inmediato
I------
2 3 3 3 2 3
Formato del resto de instrucciones
I
11 I Rd Rl1 Rl2 00 I OP I aritméticas y lógicas
FIGURA 5-4. Formato de las instrucciones.

TABLA 5-2. Códigos de operación
OP Instrucción
100 Suma (ADD)
101 Resta (SUB)
110 Desplazamiento aritmético a la derecha (ASR)
111 y lógica (AND)
000 Suma con inmediato (ADDI)
001 Resta con inmediato (SUBI)
Nos queda por determinar la codificación de los campos OP (para las instruc-
ciones aritmético-lógicas) y Cond (para las instrucciones de salio). Aunque la codi-
ficación de dichos campos puede facilitar ciertas implementaciones del procesador
y, por consiguiente, podría ser útil determinar cuál es la mejor codificación una vez
se haya planteado el modelo detallado del procesador, por el momento utilizaremos
la codificación especificada en [SPC97]. Las siguientes tablas muestran la codifica-
ción de estos campos.
La primera partición que podemos hacer del procesador, de forma que refleje la
estructura del hardware que finalmente lo implementará, es distinguir una unidad
de control y una unidad de proceso. La unidad de proceso contendrá los recursos de
cálculo del procesador, mientras que la unidad de control indicará cómo se interco-
nectan y qué operaciones realizan dichos recursos en cada ciclo de reloj.
En la unidad de proceso encontraremos: el registro de instrucción (RI), el con-
tador de programas (CP), el banco de registros, un registro auxiliar (A), un registro
donde se guardará la dirección en los accesos a memoria (Registro de Dirección de
Memoria, RDM) y los registros para los indicadores N y C (N y C).
TABLA 5-3. Códigos de condición
Cond Instrucción
000 Salto incondicional (BR)
001 Saltar si igual (BEQ)
010 Saltar si más pequeño (BL)
011 Saltar si más pequeño o igual (BLE)
101 Saltar si no igual (BNE)
110 Saltar si más grande o igual (BGE)
111 Saltar si más grande (BG)
Para controlar las operaciones en la unidad de proceso necesitamos definir unas

señales de control cuyo valor se determinará en la unidad de control. Estas señales
son:
• Habili taDireccion. Cuando está inactiva, el procesador no fuerza ningún

valor en el bus de direcciones (alta impedancia) y cuando se activa, el valor
contenido en el registro RDM o en el CP se asigna al bus de direcciones.
• HabilitaDatos. Cuando está inactiva, el procesador no fuerza ningún valor
en el bus de datos (alta impedancia) y cuando se activa el valor contenido
en el registro indicado por el campo Rf de la instrucción se asigna al bus de
datos.
• FuenteDireccion. Indica si la dirección a memoria viene indicada por el re-
gistro RDM o por el CP.
• SelRegLectura. Indica qué campo del registro de instrucción contiene el
número del registro del banco de registros que se va a leer.
• EscribeRegistro. Cuando está activa, el resultado de la operación realiza-
da en la VAL o el bus de datos, dependiendo de la señal Opera (descrita
abajo), se escribe en el registro indicado por el campo Rd del registro de ins-
trucción.
• CargaRDM.Cuando está activa, se carga el registro RDM con el resultado de
calcular la dirección indicada en las instrucciones LOAD y STORE.
• CargaRI. Cuando está activa, se carga el registro de instrucción desde el bus
de datos.
• CargaCP.Cuando está activa, el CP se carga con el campo Direccion del RI.
• IncCP. Cuando está activa, se incrementa el CP.
• Opera. Cuando está activa, indica que el contenido a escribir en el banco de
registros es el resultado de la VAL. En caso contrario, el valor a escribir pro-
viene del bus de datos.
• CargaN. Cuando está activa, el registro N se carga con el indicador de nega-
tivo de la VAL.
• CargaC. Cuando está activar el registro C se carga con el indicador de cero
de la VAL.
La unidad de control a su vez necesita conocer el tipo de instrucción que se va

a ejecutar y el valor de los indicadores N y C para poder asignar valores a las seña-
les de control. Así, la unidad de control ha de poder acceder a los dos bits más sig-
nificativos del RI (campo ca) y la unidad de proceso indicará el valor del indicador
seleccionado por el campo Cond del RI a la unidad de control mediante la señal
CondicionSal too La Figura 5-5 muestra de forma esquemática la partición del pro-
cesador y las funciones de las señales de control en la unidad de proceso.
HabilitaDatos
EscribeRegislro
Banco
Opera de
RreLg_iSttros_~~ Opera
- ~~
Unidad selR~
de Datos
control
IncCP
HabilnaDirección
n~
T~
Dirección CondiciónSalto
FIGURA 5-5. Esquema de la primera partición del procesador.
La partición del procesador en unidad de control y proceso puede modelarse en

VHDL usando un proceso para cada unidad. Así, en la arquitectura que vamos a es-
cribir y que llamaremos PrimeraParticion existirán los procesos UControl y
UProceso. Dentro de los procesos el código será parecido al código para la descrip-
ción funcional del procesador en el sentido en que no se mostrarán más detalles de
la estructura de cada unidad.
En cada uno de los procesos se representarán los recursos de almacenamiento
mediante variables y se utilizarán señales para la información que se transmita de
un proceso a otro, como las señales de control y la información sobre los indicado-
res y el tipo de instrucción contenida en el RI.
En el Listado 5-10 se muestra el esqueleto de la arquitectura PrimeraParticion.
En primer lugar se declaran los tipos de datos enumerados para evitar codificar al-
gunas señales de control y aumentar la legibilidad del código. A continuación se
declaran las señales que servirán para comunicar los dos procesos (UControl y
UProceso) y se resuelve la salida hacia el exterior del bus de dirección interno
(Direccion_I) mediante una sentencia concurrente. Para controlar cuándo el
procesador fuerza valores en el bus de direcciones y cuándo se deja éste en alta im-
pedancia, la unidad de control utilizará la señal Habili taDireccion. Asimismo,
también existe una señal que controla el acceso del procesador al bus de datos (Ha-
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE. STD_UlGIC..,.ARITH.
all ;
archltecture PrimeraParticion of Maqui~taria ls
constant cNBitPalabra : natural := 16,
constant cNBitDireccion : natural :=,'8';
constant cCero : std~logic_vect6r(cNBitPalabra-1 downto O)
, := (others => 'O' Ti-
type tSeLRegistro ls (SelRd, Se~Rx, SelRf, SelRf1, SelRf2);
type tFuenteDireccion ls (ContPróg:,'RegDirMern);
type tVectorRegistro ls array (natural ranga <» of
std_logic_vector(cNBitPalabra-1 downto O);
í" ,
signal Hqbil~taI)ireccion ;.~.tPJogic;
signal HabiHtabatos ': 'st(tlrigic;
signal FuenteDireccion : tFuenteDireccion;
signal SelRegLeCtura '';_:''':
"Ese1Registro;
signa1 EscribeRegistro : std_logic;
signal CargaRrM std_lOgic;
signal CargaRI std_logic;
signal CargaCP std_logic;
signal CargaA stcl...logic;
signal IncCP stdJogic;
signal Opera std_logic;
signal Tipolnstruccion : std ..Jogic_vector(l downto O);
signal CondicionSalto : std_logic;
signal Direccion_I std_logic_vector(CNBitDireccion-1 downto O);
signal Datos_I : std_logic~vector(cNBitPalabra-1 downto O);
begin
UControl: process
end process;
UProceso: process
end process;
with HabilitaDireccion select

Direccion <= Direccion_I when '1',
(others => 'Z') when others;
with HabilitaDatos select
Datos <= Datos_I when '1',
(others => 'Z') when others;
end PrimeraParticion;
LISTADO 5 ..10. Arquitectura PrimeraParticion de la máquina rudimentaria.

bilitaDatos) y la salida del bus de datos interno (ratos_I) hacia el exterior se

modela mediante una sentencia concurrente.
Los cambios en las señales que comunican los procesos se realizan de forma
síncrona respecto al reloj. Así, el proceso UControl esperará un flanco positivo de
reloj antes de realizar asignaciones a las señales de control, y el proceso UProceso
esperará un flanco positivo del reloj antes de utilizar el valor almacenado en las se-
ñales de control para modificar el contenido de sus variables.
El proceso UControl no dispone de recursos de almacenamiento representados
mediante variables sino que su tarea se limita a realizar una serie de asignaciones a
las señales de control, en función del tipo de instrucción que se esté ejecutando en
cada momento. Para estructurar la secuencia de órdenes utilizaremos procedimien-
tos que desarrollarán la secuencia adecuada para realizar tareas concretas, como,
por ejemplo, leer una instrucción de memoria, realizar un ciclo de bus, o calcular la
dirección final de memoria indicada por una instrucción STORE. Antes de ver cada
uno de estos procedimientos mostraremos el esquema del proceso en el Listado 5-11.
UControl: process
procedure SolicitaBus is
end SolicitaBus;
procedure LiberaBus ls
end LiberaBus;
procedure Lectura is
end Lectura;
procedure Escritura ls
end Escritura;
procedure Cargalnstruccion ls
end cargaln:>truccion;
procedure CalculaDireccion is
end CalculaDireccion;
procedure Ejecutalnstruccion ls
end Ejecutalnstruccion;
begin
wait until lniciali:z;a= '0';

HabilitaMem <= /67" .,,,
...."
Escribe <= "Z';
5. Modeladocon VHOL 279
PeticionBul3 <;:.' O' L "

EscribeRegistro <= ,'0';
HabilitaDireccion <= '0';
HabilitaDatos <= '0';
Opera "<= '0';
CargaRL'M <= ' O' ;
CargaRI <= '0';
IncCP <= '0';
Cargacp <= • O' ;
CargaA <= 'O'; j
loop ,
wait until Reloj = '1';
CargalnstrueciQJl~ ;,,.~
Ejecutalnstruccion;
end loop;
end process;
LISTADO 5-11. Proceso UControl de la arquitectura PrimeraParticion.
En el cuerpo del proceso vemos una parte del código que se ejecuta tan sólo
una vez y un bucle infinito. La primera parte inicializa las señales de control una
vez la entrada Inicializa ya ha dejado de estar activa. El bucle posterior es el en-
cargado de traer de la memoria y ejecutar instrucciones indefinidamente.
Puede observarse que las reacciones de este proceso a los eventos en la entrada
Inicializa no son las que cabría esperar de una implementación hardware del
procesador. En un circuito real los registros que guardan el estado interno del proce-
sador reaccionarían a una activación de la señal Inicializa de forma inmediata y
asíncrona o como máximo tardarían un ciclo de reloj, independientemente de la ta-
rea que estuviera realizando el procesador en ese momento. En cambio, modelar es-
te tipo de comportamiento en VHDL a un nivel de detalle menor que el de una des-
cripción a nivel de transferencia de registros requiere incluir una gran cantidad de
sentencias de control del flujo para verificar en cada tarea que la señal Inicializa
es inactiva antes de avanzar un ciclo de reloj. Además, cuando el código está es-
tructurado en procedimientos, la parte de código que llama a un procedimiento ha
de controlar si la finalización del mismo ha sido normal o se ha interrumpido a cau-
sa de la señal Inicializa.
A continuación se detalla el cuerpo de cada uno de los procedimientos. Los
procedimientos Solici taBus y LiberaBus se encargan de gestionar el acceso al
bus del procesador. Solici taBus activa la señal PeticionBus y espera hasta que
la señal BusLibre se active. Debe notarse que la sentencia wait que realiza la
espera sólo se ejecuta en el caso de que BusLibre no esté ya activa. Si se ejecuta-
ra la sentencia wait cuando BusLibre tuviera el valor '1', el proceso detendría su
ejecución hasta que un evento en la señal BusLibre volviera a almacenar el valor
'1' en ella, es decir, serían necesarios dos eventos: uno que modificara el valor de
la señal y otro que restableciera el valor '1' para que el proceso continuara su eje-
cución.
procedure SolicitaBus ia
begin
PeticionBus <= '1';
if BusLibre = 'O' then
wait until BusLibre = '1';
end if;
end SolicitaBus¡
procedure LiberaBus ia
begin
PeticionBus <= 'O';
end LiberaBus;
LISTADO 5-12. Procedimientos de control del acceso al bus en el proceso UControl.
Los procedimientos Lectura y Escri tura realizan un ciclo de lectura y escri-

tura a memoria considerando que el registro RDM contiene la dirección a la que se
accede. En ambos casos los datos se almacenan y leen del banco de registros. Estos
procedimientos realizan la ejecución de las instrucciones LOAD y STORE.
procedure Lectura ia
begin
SolicitaBus¡
FuenteDireccion <= RegDirMem;
wait until Reldj;;; '1'; .:
HabilitaDireccion <~ '1';
HabilitaMem <= '·1';
EscribeRegistrQ'<= '.1 '.;
Escribe <= 'O',
HabilitaMem ~~., 'Oi ¡ ,
Escribe <= ,V;
EscribeRegistro )<= 'O';
HabilitaDireccion <= 'O';
LiberaBus;
end Lectura;
procedure Escritura ia
begin
SolicitaBus;
FuenteDireccion <=. RegDirMem;,
wait until Reld) = '1';
HabilitaDireccian <= '1';
Habüifatiitos <= íl';

SelRegLectura <= SelRf;
Escribe <= ' 1 ';
HabilitaMem <= '1';
wait unti1 Reloj = '1';
HabilitaMem <= '0';
HabilitaDireccion <= '~';
HahilitaDatos <= '0';
c
r:scribe <= 'Z';

LiberaBus;
end Escritura; e
LISTADO 5-13. Procedimientos de escritura y lectura a memoria del proceso

UControl.
El procedimiento CargaInstruccion realiza la búsqueda de una instrucción

en memoria. Es muy parecido al procedimiento Lectura con la diferencia de que la
dirección a que se accede se encuentra en el contador de programas y el destino de
los datos es el registro de instrucción. Al final del ciclo de lectura el CP se incre-
menta, dejándolo preparado para la carga de la siguiente instrucción.
procedure CargaInstruccion is
begin
SolicitaBus;
FuenteDireccion <= ContProg;
wait until Reloj '" '1 ';
IncCP <= '1';
HabilitaDireccion <= ' l' ;
Escribe <= '0';
HabilitaMem <= '1';
CargaRI <= '1';
IncCP <= '0';
Habili taMem <= ' O ';
Escribe <= ' Z' ;
CargaR! <= 'O';
LiberaBus;
end CargaInstruccion;
LISTADO 5-14. Procedimiento para la carga de una instrucción en el proceso

UControl.
El procedimiento CalculaDireccion simplemente activa las señales de con-

trol necesarias para cargar la dirección indicada por los campos Rx y DireccionBa-
se de las instrucciones LOAD y STORE en el RDM.
procedure CalculaDireccion 18
beg1n
SelRegLectura <= SelRx:
CargaRDM <= ~l': -,,-
wait until Reloj = '1':
CargaRDM <= 'O':
end CalculaDireccion:
LISTADO 5-15. Procedimiento para el cálculo de la dirección de memoria en el

proceso UControl.
El procedimiento EjecutaInstruccion determina que tipo de instrucción se en-

cuentra en el RI según la señal TipoInstruccion y para cada uno de los cuatro posi-
bles tipos de instrucciones activa las señales de control adecuadas. Para las instruccio-
nes LOAD y STORE basta con llamar a los procedimientos CalculaDireccion y
Lectura o Escritura respectivamente. En los demás tipos .de instrucciones es en
este procedimiento donde directamente se determinan los valores de las señales de
control en los ciclos necesarios para la ejecución de cada tipo de instrucción. Debe
notarse que parte de la decodificación de la instrucción se realiza en la unidad de
proceso como, por ejemplo, determinar la operación de la VAL a partir del campo
OP de las instrucciones aritmético-lógicas.
procedure EjecutaInStruccion 18
begin
case Tipolnstruccion ie
when "00" => - LOAD
CalculaDireccioD:
Lectura:
when ·01" => - STORE
CalculaDireccion:
Escritura:
when "lO" => - Salto
if CondicionSalto = '1' then
CargaCP <= '1':
CargaCP <= 'O':
end if:
when "11" => - arithmetico-logica
SelRegLectura <= 5elRfl:
CargaA <= '~:
CargaA <= 'O':
SelRegLectura <= 5elRf2:
Opera <= '1':
EscribeRegistro <= 'l'r
wait until Reloj = '1' i
Opera <= 'O';

EscribeRegistro <= 'O';
when others =>
null;
end case;
end Ejecutalnstruccion;
LISTADO 5-16. Procedimiento para la ejecución de instrucciones en el proceso

UControl.
En el proceso UProcesose representan mediante variables los recursos de alma-

cenamiento del procesador (RI, banco de registros, indicadores C y N, RDM, regis-
tro A y CP). Puesto que ya conocemos el tamaño de los distintos registros y el
formato de las instrucciones a nivel de bits, el tipo de datos utilizado para dichas va-
riables es el std_logic_vector. Además, para facilitar las referencias a los distin-
tos campos dentro de una instrucción, se definen alias para la variable RI, de modo
que podremos referirnos al campo que indica el tipo de instrucción como ca (bits 15-
14), al campo que indica la operación aritmética como OP (bits 2 a O), a los campos
que indican el registro fuente y destino en las instrucciones LOAD y STORE como
Rd y Rf respectivamente (bits 13 a 11) y al campo que indica el valor inmediato con
el que operar en las operaciones aritméticas como Numero (bits 7 a 3).
El proceso UProcesotampoco realiza un modelado real de los cambios en la se-
ñal Inicializa. Por el contrario, espera a que ésta se desactive para inicializar las
variables que representan los recursos de almacenamiento del procesador y a conti-
nuación entra en.un bucle indefinido ejecutando en cada flanco de subida del reloj
las órdenes que le envía el proceso UControla través de las señales de control.
En el bucle del proceso se actualizan las variables que representan los recursos
(RI, RDM, CP, registro A, banco de registros e indicadores) de acuerdo con las se-
ñales de control recibidas y al final se asignan las señales que comunican este pro-
ceso con el proceso UControl (CondicionSalto, TipoInstruccion) y con los
puertos externos (Datos_I y Direccion_I).
En el siguiente listado se muestra el código correspondiente al proceso.
UProceso: process
variable RI std_logic_vector(l5 downto O);

alias CO std.,._logic_vector(l downto O)
ls RI(15 downto 14);
alias OP std_logic_ vector (2 downto O)
is RI (2 downto O);
alias Rd. std_logic_vector (2 downto O)
ls RI(13 downto 11);
alias Rf std_logic_vector(2 downto O)
is RI (13 downto 11);
alias . Numero std_logic_vector{4 downto O)
ls RI(7 downto 3);
variable BancoRegistros. tVectorRegistro(O to 1);

variable C std,_logic;
variable N std,_logic;
variable RDM std,_logic_vector(7 downto O);
variable A std,_logic_ vector (15 downto O);
variable CP std,_logic_vector(7 downto O);
-- Variable auxiliar "para cálculos "intei:médios

variable iRd : integer;
-- Función que determina el registro a leer en función del contenido de RI

functiOll CalcRegLec;tura (SelRegLectura: tSelRegistro;
!U:std_logic_vector(15 dawnto O)) return natural is
begin
case SelRegLectura ia
when SelRd I SelRf =>
return C<~nv_integer(unsigned(RI (13 downto ll) f};
when SelRx I SelRf1 =>
return conv"...integér(unsignéd(RI(10 downto 8))),;
when SelRf2 =>
return Conv_integer (unsigned (RI (7 downto 5)));
end case;
end CalcRegLectura;
begin
wait until rnícíatíza =
'O'; ,
CP := (others => 'O');
C := 'O';
N := 'O';
for I in O to 7 loop
BancoRegistros(I) .- (others => 'O'.);
end loop;
loop
wait until Reloj i1';
-- Carga del RI
if CargaRI = '1' then
RI := Datos;
end if;
- - Carga del \ID'!

if CargaRIM = '1' then
RDM := unsigned(BancoRegistros(CalcRegLectura(
. Se1RegLectura, RI) )(cNBitDireccion-1 downto O)},
+ unsigned(IUtcNBitDireccion-1 dawnto O));
end if;
-- Logica asociada al CP
if CargaCP = '1' then
CP := RI(cNBitDireccion-1 downto O)_;
end if;
5, Modelado con VHDL 285
tf IncCP = '1' then

CP := unsigned(CP) + 1;
end tf;
-- Carga del registro A

tf CargaA = '1' then
A : = BancoRegistros (CalcRegLectura (SelRegLectura, RI));
end tf;
-- Escritura en el BancoRegistros
tf EscribeRegistro = '1' tben
iRd :::;Conv _integer (unsigned (Rd));
if Opera = '1' then
case OP 18
when "000' => -- ADDI
BancoRegistros(iRd) := signed(Numero) + signed(A);
wben ·001· => -- SUBI
BancoRegistros (iRd) := signed (A) - signed (Numero) ;
when "lOO· => -- ADD .
BancoRegistros(iRd) := signed(A) +
signad (BancoRegistros (
CalcRegLectura(SelRegLectura, RI) n;
when "101' => -- SUB
BancoRegistros(iRd) := signed(A) +
signed{BancoRegistros{
CalcRegLectura{SelRegLectura, RI)));
wben "110· "E.> -- ASR
BancoRegistros(iRd) :=
stQ_logic_vector(SHL{signed(A) ,
unsigned'(·l·)));
when "111' => -- ANO
BancoRegistros(iRd) := A and BancoRegistros(
CalcRegLectura(SelRegLectura, RI));
when others =>
null;
end case;
else
BancoRegistros(iRd) :=·Datos;
end if;
if BancoRegistros(iRd) = cCero then
C ,- '1';
else
e ,- 'O';
end if;
tf BancoRegistros(iRd) (15) = '1' then
N ,- '1';
else
N ,- 'O';
end if;
end if;
-- Asignaciun de Tipolnstruccion y CondicionSalto

Tipolnstruccion <= COI
case RI(13 downto 11) is

when ·000· =>
CondicionSalto <= '1';
when ·001" => -- BEQ
CondicionSalto <= C¡
when '010" =>
CondicionSálto <= Ni
when ·011" :=> -- BLE
Condicionsalto <= C or N¡
when "101" =>
CondicionSalto <= not C;
when *110" => BGE
CondicianSalto-<= C or not N;
when "111" => -- BG
CondicionSalto <= (not C) and (not N);
when othera =>
CondicionSalto <= 'X';
end case;
-- Asignación de Datos_I y Direccion_I

Datos_I <= BancoRegistros (Conv_integer (unsigned (RdU ) ¡
if FuenteOireccion = ContProg then -- --
Direccion_I <~ CP;
else
Direccion_I <= ROM;
end if;
end loop;
end process;
LISTADO 5-17. Proceso UProceso de la arquitectura PrimeraParticion.
5.4.2. Bancos de pruebas

La verificación de los modelos VHDL constituye normalmente una de las etapas
más difíciles, pero ineludibles, del diseño electrónico. La verificación consiste en
comprobar que la funcionalidad del diseño satisface las especificaciones. Para ello
es necesario definir bancos de pruebas con los cuales se estimulará el diseño en el
mayor número posible de casos, con el objetivo de detectar los posibles errores.
En este apartado se considerarán los distintos tipos de bancos de pruebas que
pueden realizarse según lo avanzada y estable que se encuentre la especificación del
sistema donde se incluye el modelo a verificar. Los distintos tipos de bancos de
pruebas se aplicarán al diseño del procesador a medida que éste avance. Así, empe-
zaremos por un banco de pruebas sencillo para la descripción PrimeraParticion
en el siguiente apartado y lo iremos desarrollando a medida que modelemos con
más detalle el sistema. Por otra parte, en el Capítulo 6 se abordarán las cuestiones
de tipo metodológico sobre cómo deben escogerse los estímulos y qué comproba-
ciones se deben incluir en los bancos de pruebas.
Con anterioridad a la aparición de lenguajes de descripción de hardware del es-

tilo del VHDL, la tarea de verificación de los componentes diseñados consistía en
definir unos estímulos mediante un lenguaje proporcionado por el simulador lógico
utilizado y analizar, mediante la visualización de formas de onda, los resultados de
la simulación del componente. Con la aparición de los lenguajes de descripción de
hardware modernos, la escritura de estímulos puede verse desde un punto de vista
distinto a la mera especificación de cambios en las entradas del componente a veri-
ficar y el análisis visual de las salidas. La realización de bancos de pruebas puede
considerarse como un verdadero modelado del entorno del componente a verificar,
es decir, un modelo del resto del sistema en el cual nuestro componente constituye
sólo una parte.
Desde esta perspectiva, cuando se escriben los bancos de prueba deben consi-
derarse cuestiones parecidas a cuando se realiza el modelo de un componente: exis-
tirán siempre distintas alternativas para su realización según el grado de precisión,
prestaciones y nivel de abstracción que se le exija al modelo con sus correspondien-
tes ventajas e inconvenientes.
Sin embargo, por el hecho de ser modelos del entorno con el objetivo de verifi-
car un componente, los bancos de pruebas son descripciones escritas para la simula-
ción y ello implica que no están ligadas a un subconjunto particular del VHDL (co-
mo ocurre con las descripciones para síntesis) y que deben ser optimizadas para que
la simulación sea lo más eficiente posible. Además, normalmente no nos interesarán
los detalles internos de la arquitectura de los componentes que constituyen el entor-
no pero sí que exigiremos que a las entradas del componente a verificar se apliquen
los estímulos con la mayor precisión posible en cuanto a los cambios en el tiempo.
Desde el punto de vista del grado de detalle con el que se describe el entorno
del componente a verificar distinguiremos dos posibles situaciones: en algunos ca-
sos conoceremos con detalle los distintos componentes que constituyen el sistema y
en otros casos dispondremos de las especificaciones del componente a verificar pe-
ro no conoceremos el resto del sistema.
En la primera situación podremos realizar un modelado estructural del entorno
donde cada componente disponga de una entidad propia y una arquitectura que re-
fleje con precisión su comportamiento a lo largo del tiempo.
La segunda situación es propia de dispositivos de propósito general que son
utilizados en una gran variedad de sistemas. En estos casos el banco de pruebas ten-
derá más bien a ser una herramienta para verificar las especificaciones que un mo-
delo detallado del sistema. Normalmente encontraremos las dos posibles situacio-
nes a la vez y seremos capaces de describir con detalle algunas partes del sistema
mientras que otros componentes no estarán definidos.
5.4.2.1. Bancos de pruebas como descripciones estructurales

del sistema
La aproximación más segura para la realización de bancos de pruebas es intentar re-
flejar la estructura del sistema mediante un modelado estructural, es decir, descri-
biendo los componentes del sistema como entidades separadas y describiendo el
sistema como las referencias e interconexión de éstas. Como hemos visto anterior-
mente, cuando se describe la estructura se describen con detalle las interfaces de ca-
da componente además de su interconexión. Esto significa que una descripción de
este estilo implicaría que se dispone de abundante información de cómo es el siste-
ma y qué componentes lo componen.
Los componentes del sistema serán dispositivos comercialmente disponibles,
para los cuales será posible obtener en algunos casos una descripción VHDL pro-
porcionada por su fabricante. Además, aun en el caso de que deban escribirse las
descripciones para cada componente, éstas se escribirán de forma independiente del
componente a verificar, pensando tan sólo en el comportamiento del componente
del sistema que se modela. La independencia de los modelos de los componentes
del sistema reduce la posibilidad de error, ya que el mismo modelo se habrá utiliza-
do y depurado en distintos sistemas y se dificultarán los errores debidos a proble-
mas de interpretación de especificaciones.
Por ejemplo, podríamos decidir que en el sistema donde se ubicará nuestro pro-
cesador utilizaremos una memoria y un árbitro de bus comerciales de los cuales co-
nocemos su comportamiento al disponer de sus hojas de datos. En este caso los mo-
delos de la memoria y el árbitro de bus se realizarían de acuerdo a su hoja de datos
y de forma independiente al modelo del procesador. Los componentes se conecta-
dan tal como se indica en la Figura 5-6, realizándose para ello una descripción es-
tructural.
El principal inconveniente de realizar un banco de pruebas que refleje la es-
tructura del sistema es la pérdida de eficiencia en la simulación. Por una parte, la
mayor cantidad de código y procesos a simular, y por otra la mayor longitud de las
simulaciones, hacen que éstas sean más lentas que si no se hubiera detallado con
tanta precisión la estructura. La mayor longitud de las simulaciones con este tipo de
modelo es debido a que para aplicar determinados estímulos al componente a verifi-
car puede ser necesario llevar el resto de componentes del sistema a un estado de-
Memoria
1i
Controles i Datos t ¡DireCCiones
PeticionBus
Árbitro
Procesador de
BusLibre bus
FIGURA 5-6. Descripción estructural del sistema.

terminado, lo cual puede implicar un gran número de ciclos de simulación. Por

ejemplo, en nuestro sistema debería haber otro componente capaz de escribir en la
memoria el programa y los datos para el procesador, así como leer los resultados y
utilizarlos de algún modo. En el sistema real la memoria no estaría inicializada sino
que durante unos ciclos algún componente estaría escribiendo sus valores iniciales
desde el punto de vista de la simulación del procesador. En cambio, si el modelo del
entorno no contemplara los componentes con tanta rigurosidad sería posible forzar
un estado del sistema con menor número de ciclos.
5.4.2.2. Bancos de pruebas para verificar las especificaciones
En el otro extremo del espacio eficiencia-detalle se encuentra el modelado del en-

torno a nivel estrictamente funcional. En este caso podríamos no considerar los
componentes que constituyen el sistema y centrarnos en cómo se aplican los es-
tímulos al componente a verificar. El banco de pruebas consistiría en una única en-
tidad cuya arquitectura podría contener uno más procesos, dependiendo del grado
ó
de detalle con que sea necesario modelar el paralelismo en el entorno del compo-
nente a verificar para proporcionarle unos estímulos que se aproximen al máximo a
los que le proporcionaría un sistema real.
La estructura de este tipo de banco de pruebas se muestra en la Figura 5-7,
donde diferentes procesos proporcionan estímulos al componente a verificar y reac-
cionan a sus respuestas, además de coordinarse entre ellos mediante señales.
En algunos casos puede ser conveniente dar formato a los estímulos en ciclos,
de forma similar a como se introducen en las máquinas para el test de circuitos inte-
grados. Esto es útil en el caso de que los estímulos de simulación se quieran conver-
tir a vectores para la máquina de test o en el caso de querer realizar una descripción
Banco de pruebas
Componente
a
verificar
FIGURA 5-7. Banco de pruebas funcional.

funcional que, a nivel de ciclos de reloj, proporcione los mismos estímulos que una
descripción estructural pero acelerando la simulación al disminuir el número de
procesos que se ejecutan. En este último caso se realizaría una simulación de la des-
cripción estructural del sistema almacenando en un fichero los estímulos que se
aplican al componente a verificar en cada ciclo. Posteriormente se podría sustituir
el banco de pruebas estructural por un banco de pruebas mucho más sencillo que le-
yera los estímulos de un fichero y los aplicara.
La aplicación de estímulos según ciclos de test o de reloj era normal antes de la
existencia de los HDLs modernos, cuando la descripción de los estímulos se reali-
zaba con el lenguaje propio de cada simulador. El principal inconveniente de esta
técnica es que no se puede realizar un banco de pruebas mínimamente inteligente,
que se adapte a posibles cambios en el componente igual como se adaptaría el en-
torno real. Por ejemplo, cuando definamos una entidad para nuestro procesador y lo
separemos del resto del sistema, la memoria de datos y programas formará parte del
entorno del procesador y será muy útil describir el comportamiento de la memoria
de forma independiente al número de ciclos que el procesador tarde en realizar la
lectura y escritura de datos. De este modo será más práctico realizar un modelo que
tenga en cuenta las relaciones causa-efecto de las señales al interactuar con el pro-
cesador que no uno que se limite a aplicar estímulos en cada ciclo sin tener en cuen-
ta las salidas del procesador.
5.4.2.3. Análisis de las respuestas
La consideración de las respuestas del componente a verificar no sólo puede utili-

zarse para realizar un banco de pruebas que se adapte al comportamiento del com-
ponente a verificar de la misma forma como lo haría el entorno real, sino que ade-
más se pueden realizar comprobaciones sobre dichas respuestas que nos ayuden en
la verificación.
Podemos distinguir dos estrategias en cuanto a la comprobación automática de
las simulaciones: basarse en comparaciones con simulaciones previas cuyos resulta-
dos se han verificado previamente de forma manual (Figura 5-8) o bien incluir en el
banco de pruebas la capacidad para realizar suficientes verificaciones sobre las sali-
das (Figura 5-9).
La primera estrategia es útil cuando se trabaja a nivel de ciclo de test y las
comparaciones se pueden realizar en cada ciclo. Dichas comparaciones sirven pa-
ra validar cambios menores en el componente que no modifican su comporta-
miento en ningún ciclo, pero son difíciles de realizar si se trata de simulaciones
del componente a diferentes niveles de abstracción. La forma de realizar este tipo
de comparaciones en VHDL es escribiendo los valores de las respuestas del com-
ponente a verificar en un fichero y posteriormente comparar dicho fichero con
uno que contenga las respuestas correctas o bien incluir un proceso en el banco
de pruebas que lea las respuestas correctas a cada ciclo y las compare con las ob-
tenidas.
La implementación de la segunda estrategia es en principio mucho más com-
pleja, dependiendo de la complejidad y naturaleza del componente a verificar y
Modelo
Reloj -,--------,--+i de
referencia
Comparación
Aplicación ~----------_'I de OK
de resultados
estímulos (en cada ciclo)
Modelo
a
verificar
FIGURA 5-8. Verificación basada en comparaciones ciclo a ciclo.
también es mucho más difícil asegurar que la verificación es suficientemente ex-

haustiva. Normalmente, en los bancos de pruebas existirán uno o más procesos que
se encargarán de analizar las respuestas de la simulación. Estos análisis pueden ser
de dos tipos:
• Dependientes de los estímulos que aplica el propio banco de pruebas. En este

caso los procesos encargados de realizar el análisis deberán comunicarse con
los procesos que apliquen los estímulos mediante señales para saber en qué
momento deben hacer las comprobaciones.
Análisis
de
respuestas
independiente
del test
Generador Modelo t
de a
estímulos verificar ~
-
Análisis
de
respuestas
dependiente
del test
FIGURA 5-9. Verificación "inteligente".

• Comprobaciones independientes. Casos típicos de este tipo de comproba-

ciones son los chequeos de los ciclos de un bus, donde se comprueba que,
siempre que hay actividad en el bus, el orden y el tiempo de activación de
las señales son correctos, o comprobaciones de que una combinación de de-
terminados valores en las salidas del componente, que indicaría claramente
que se ha llegado a una situación no prevista, no se produce. Muchas veces
es más práctico incluir este tipo de verificaciones dentro del modelo del
componente a verificar, ya que allí se dispone de más información sobre su
estado interno.
5.4.3. La máquina rudimentaria: el banco de pruebas
En este apartado vamos a simular el procesador con su arquitectura PrimeraParti-

cion utilizando la estrategia más simple para modelar un posible entorno del proce-
sador. Por el momento en el modelo del entorno no se incluirán modelos precisos
de los componentes sino que constará de una única entidad y una arquitectura don-
de mediante varios procesos se realizará un modelado funcional de los componen-
tes imprescindibles para el procesador que son: una memoria, un árbitro de bus y un
generador de ciclos de reloj.
Así, el aspecto del sistema será el mostrado en la Figura 5-7, donde la arquitec-
tura correspondiente al sistema contiene únicamente referencias al banco de prue-
bas y al procesador. El banco de pruebas tendrá como entradas las salidas del proce-
sador y como salidas las entradas del procesador. Así, la entidad para el banco de
pruebas será la siguiente:
library IEEE;
entlty BancoPruebas la
port (
Inicializa out std._logic;
Reloj out stQ_logic;
BusLibre out std_logic;
Datos inout stQ_logic~vector(15 downto O);
Direccion in stQ_logic_vector(7 downto O);
HabilitaMem in std_logic;
Escribe in std,_logic;
PeticionBus in std,_logic) ;
end BancoPruebas;
LISTADO 5-18. Entidad para el banco de pruebas funcional.
En la arquitectura del banco de pruebas distinguiremos cuatro partes indepen-

dientes, cada una de las cuales se relacionará con un conjunto distinto de entradas y
salidas del procesador. Una parte se encargará de generar la señal de reloj, otra de
generar la señal Inicializa, otra de la interacción del procesador con la memoria
(proceso Memoria) y la cuarta controlará el acceso al bus del procesador (proceso
Arbi troBus).
La generación de las señales Reloj e Inicializa es suficientemente simple
como para poder utilizar sentencias de asignación concurrentes en lugar de proce-
sos. La única dificultad estriba en que necesitaremos utilizar la señal Reloj a la de-
recha de la asignación y no lo podremos hacer ya que es un puerto de salida. Para
estos casos podemos utilizar una señal interna (Reloj_I) en la cual generaremos el
reloj y posteriormente asignar esta señal al puerto de salida.
El proceso que realizará el papel de la memoria de datos y programas contiene
una inicialización de las posiciones de memoria (variable Man) donde se introducen el
mismo programa y los mismos datos que se utilizaban en la descripción funcional del
procesador. Con posterioridad a esta inicialización, el proceso entra en un bucle para
realizar las funciones habituales de una memoria: cada vez que se activa la señal Ha-
bili taMem, realiza un ciclo de escritura o de lectura según indique la señal
Escribe. En realidad, el proceso no se activa de acuerdo con la señal Habili taMem
sino con una señal homóloga retrasada 10 ns (HabilitaMem'delayed(lO nsJ). De
esta forma es posible asegurar que las señales asignadas por el procesador (Direc-
cion, Escribe y Datos) están estables cuando las lee este proceso.
Finalmente, el proceso Arbi troBus reacciona a las peticiones de bus por parte
del procesador activando la señal BusLibre. En el Listado 5-19 se muestra la arqui-
tectura Funcional del banco de pruebas.
library IEEE;
use IEEE.STD_LOGIC_AR!TH.a1l;
architecture Funcional of BancoPruebas is
signal Reloj_I : stq_logic := 'O';

signal HabilitaMem_I : std.:..:logic;
constant CicloReloj : time := 50 ns;
type tMemoria is array (natural range -o- al stq_logic_vector(15 downto O);
begin
RelóLI <= DOt ReloLI after CiclóReloj!2 i

RelOj <= Reloj_I;
Inicializa <= '1' I ., O' after CicloReloj;
Memoria: process
variable Mero:tMemoria(O to 255);
begin
Mero(O) := "00010000000011510'; -' 101ID(2,b,lOP
ME!ll(J.);;'e. "OOOlJ;QOOOOQOJOll"; c: - LQAD(J,O,lp

ME!ll(2)':; ·üIOooiiói000100"; -r--lIPD(4,3,2), .
Mem(3) :,; ·OlldOO~OOOllOO"; '7 - Sl'OREf4,(U,2)
Mem(() ~:'" "iooooododoOOOóOo'; .; - JMP(O)
Mem(lO) := ·0000000000000011"; -- 3
Mem(ll) :-= "0000000000000100·; - - 4
loop
Datos <= (othera => 'Z');
wait until HabilitaMem'delay.ed(lCtns} = '+,'i
if Escribe = 'l' then ",
Mem(Conv_integer(unsign~(ISirecdoI))l) :,,; Datos;
elae ., .. ,
Datos <= Mern(Canv~integer(unsigned(Direccion)));
wait until HabilitaMem'delayed(lG ns) '" '0';
end if;
end loop;
end procesa;
ArbitroBus: process
begin
BusLibre <= '0';'
wait unUl PeticioriBus = ' l' ;
BusLibre <= '1';
wait until PeticionBus = 'O';
end proceaa;
end Funcional;
LISTADO 5-19. Arquitectura funcional del banco de pruebas.
5.5. MODELADO DETALLADO
Llegados a este punto se dispone de un modelo funcional del procesador, en el que

quedan claramente reflejadas las diferentes operaciones que deberá realizar, así
como su secuenciamiento. Sin embargo, ninguno de estos modelos contiene infor-
mación acerca de cómo deben realizarse tales operaciones, de cuál es el tiempo
más o menos aproximado que requiere cada una de ellas, de cómo detectar posi-
bles situaciones prohibidas y otra serie de cuestiones que para poder ser tratadas
requieren disponer de un mínimo de información relativa a la implementación del
procesador.
Nuestro objetivo será, por tanto, a través de un refinamiento progresivo de los
modelos del sistema, obtener unas descripciones que reflejen claramente todos los
detalles de implementación, o modelen de una forma precisa la realidad. En el pri-
mer caso se tratará de los componentes que realmente pretendemos implementar y
que después de este proceso de refinamiento podrán ser utilizados como entrada a
una herramienta de síntesis, que automáticamente generará el circuito correspon-

diente. En el segundo caso se trata de aquellos componentes que también forman
parte del sistema, pero que únicamente son necesarios para crear el entorno realista
en el que deberá operar nuestro diseño, y que, por tanto, serán diseñados de cara a
su simulación.
5.5.1. Modelado para síntesis vs modelado

para simulación
Hasta el momento, el objetivo que se perseguía con los diferentes modelos funcio-
nales descritos en los apartados anteriores era tratar de describir el funcionamiento
de nuestro sistema electrónico con una doble finalidad:
1. Especificar y documentar las características del sistema.
2. Simular los modelos para verificar la validez del diseño.
Sin embargo, a medida que pasemos a: refinar estos modelos funcionales debe-
mos tener bien claro cuál es el objetivo de dichos modelos:
1. Disponer de una descripción precisa de aquello que se pretende modelar.
2. Escribir una descripción inteligible por las herramientas automáticas de sín-
tesis, que generarán el circuito a partir de dicha descripción.
La razón es bien sencilla. El VHDL, y en general los HDLs, fueron pensados
para facilitar la tarea del diseñador de sistemas electrónicos; por tanto, se puso más
énfasis en tratar de dotarlo de características como la flexibilidad que no en otras
que mejoraran las prestaciones de las herramientas asociadas.
Por lo que respecta a la simulación, esto simplemente significa que, aunque se so-
portan todas las construcciones del lenguaje, algunas, o algunos estilos de modelado,
resultan bastante ineficientes desde el punto de vista del tiempo de simulación.
En el caso de la síntesis, resulta un tanto más crítico, puesto que el grado de
flexibilidad del lenguaje dificulta enormemente el trabajo a las herramientas auto-
máticas. En consecuencia, sólo se permite utilizar un subconjunto de construccio-
nes, perfectamente definido, en los modelos que tienen como objetivo la síntesis
automática. La consecuencia inmediata es que, si bien cualquier modelo para la sín-
tesis puede ser simulado, no todos los modelos simulables son sintetizables.
En resumen, a la hora de escribir modelos sintetizables habrá que ceñirse al
subconjunto de construcciones y estilos recomendados por las herramientas de sín-
tesis, mientras que si sólo se trata de escribir un modelo simulable habrá que tener
en cuenta ciertas recomendaciones que pueden mejorar el rendimiento del simula-
dor, aunque cualquier construcción está soportada.
5.5.2. El modelado del tiempo
A medida que tiene lugar el proceso de refinamiento de las descripciones VHDL,

no sólo se ponen de relieve con mayor detalle las características referentes a la im-
plementación de estos modelos, sino que también se va precisando su comporta-

miento temporal.
La versatilidad del VHDL permite modelar el comportamiento temporal del
hardware a diferentes niveles de abstracción. Así, por ejemplo, en la primera des-
cripción de nuestro procesador, la única caracterización temporal se refiere al
tiempo de ciclo de instrucción, muy poco precisa, pero suficiente para el nivel de
que se trata, y la única posible debido al desconocimiento de los detalles de imple-
mentación. Sin embargo, a medida que avance el capítulo trataremos el modelado
realista de otros componentes, como puede ser una memoria RAM, en los que no
sólo se incluirán todos los parámetros temporales habituales en estos modelos,
sino también el código necesario para realizar la verificación de las restricciones
que se imponen a estos parámetros (tiempos de establecimiento, tiempos de mante-
nimiento, ... ).
El lenguaje VHDL no proporciona un mecanismo estándar para la especifica-
ción de la información temporal de los modelos. La forma de implementarla depen-
de, en gran medida, del grado de precisión del modelo (asignación de un retardo
aproximado o realista), de su reutilización (paso de la información temporal como
parámetros), etc. Así, al diseñador se le ofrecen diferentes alternativas.
1. Si se trabaja en un nivel de abstracción alto, como puede ser la primera des-

cripción de la máquina rudimentaria, puesto que se dispondrá de muy poca
información acerca de la implementación del modelo, se buscará simple-
mente una forma muy aproximada de modelar esta información, que permi-
ta únicamente establecer algún tipo de comparación entre diferentes aproxi-
maciones para poder evaluarlas y compararlas entre sí.
loop
Leerlnstruccion;
Ejecutarlnstruccion;
wait lor 100ns;
end loop;
En el ejemplo al que nos referimos se estableció un tiempo de ciclo de ins-

trucción que puede servir perfectamente para comparar dos repertorios de
instrucciones entre sí, aunque este valor no se corresponda con el resultante
de la implementación definitiva del modelo. El modelado, en este caso, con-
siste sencillamente en asignar un valor de tiempo a la sentencia wait que si-
mula el ciclo de instrucción.
2. Descendamos algún nivel en la jerarquía, y supongamos que disponemos de

un modelo estructural del sistema a diseñar. En este caso puede interesar,
por ejemplo, disponer de un modelo de retardo de pin a pin (pin-to-pin), en
el que sólo nos interesa conocer el tiempo de propagación desde las entradas
hasta las salidas del componente. En tal caso el modelado consistirá en la
utilización de la cláusula after en la sentencia de asignación del valor co-
rrespondiente al puerto de salida.
Ejercicio 5.1
Modelar un multiplexor 2 x 1 que verifique las siguientes características:
E11J-0 ... S
E2 1
FIGURA 5-10. Multiplexor 2 x 1.
TABLA 5-4. Tiempos de retardo
Parámetro . Camino Tiempo

tpl El o E2 hasta S 20 ns
tp e hasta S lOns
Solución
En este caso existen dos tiempos de propagación diferentes, en función de si el
cambio se produce en cualquiera de las entradas de datos o en la entrada de control.
El proceso combinacional mux comprueba en qué señal de entrada se ha producido
el evento, y asigna el valor a la salida con el retardo que corresponda. La función
CalculaDato es la que realmente implementa el comportamiento del multiplexor,
mientras que el cuerpo del proceso únicamente identifica la señal sobre la que se
produjo el evento y asigna el retardo en consecuencia. Note cómo no se ha tenido
en cuenta el caso de que se activen simultáneamente una señal de datos y otra de
control. Esta comprobación está implícita en el código, puesto que como el tiempo
de dato es el mayor de los dos, se verifica en primer lugar.
library IEEE;
use IEEE.STD_LOGIC_ll64.all;
entity Multiplexor ie
port(
El, E2 : in std_logic_vector(l5 downto O);
C : in std_logic;
S : out std_logic_vector(15 downto O));
end Multiplexor;
1 tp: tiempo de propagación.

architecture Funcional of Multiplexor ls
constant TpoDato ;. time :'" 20 flP;

constant TpoConttol ; time !,:;; 10 na;
begin
Mux; process (El, E2, el
functlan ealculaDato(
El, E2 ; in std,_logic_vector(15 downto O);
e ; in std_logicl
return std_logic_vector ls
begin
if (e = '1') then
return E2¡
e1se
return E1¡
end lf¡
end CalculaDato;
begln
if (El' event ar E2' event ) then
S <= ealcu1aDato(E1, E2, e) after TpoDato;
elee
S <= ealculaDatci(El, E2, e) after TpoControl¡
end if¡
end process Mux¡
end Funcional ¡
LISTADO 5-20. Modelado del retardo de pin a pino
3. Supongamos ahora que nos hallamos en el nivel más cercano al hardware,

en el que nuestro circuito está modelado a base de las celdas lógicas que lo
componen. Si pretendemos hacer una simulación realista de nuestro diseño
tendremos que reflejar todas las características de estos componentes, según
se especifican en las hojas de datos (datasheets) de la tecnología que corres-
ponda. Para cada celda existirá no sólo un tiempo de propagación determi-
nado desde las entradas hasta las salidas, sino que además éste variará en
función del número de celdas a las que ésta está conectada lfanout). Incluso
el retardo será diferente en función del tipo de transición (0/1, 1/0,01Z, ... ).
Puesto que el modelo temporal de cada celda dependerá de su posición en el
circuito, no podremos fijar sus características temporales en el código, sino
que se pasarán mediante parámetros.
Ejercicio 5.2
Escribir el modelo correspondiente al circuito de la Figura 5-11, reflejando la infor-
mación temporal incluida en la Tabla 5-5.
Y1
Y2
D-
E-
F------I
FIGURA 5-11. Circuito basado en puertas ando
TABLA 5-5. Retardo de la puerta and
Mínimo Típico Máximo

tplh 2 1,6 ns 2,1 ns 2,5 ns
tphl 1,7 ns 2,0 ns 2,3 ns
dtplh 3 0,3 ns 0,5 ns 0,8 ns
dtphl 0,25 ns 0,4 ns 0,7 ns
Solucián
El primer paso consistirá en obtener la descripción de la puerta and, que posterior-

mente utilizaremos para modelar el resto del circuito. La entidad, además de los
puertos correspondientes a las entradas y salidas de la puerta, incluirá dos paráme-
tros genéricos: los tiempos de propagación tplh y tphl, correspondientes a las transi-
ciones 0-1 y 1-0 en la salida de la puerta. La arquitectura consistirá simplemente en
la siguiente asignación concurrente condicionaL
y <= '1' after tplh when (A = '1' and B = '1') e1se
'o' after tphl when (A = 'O' or B = 'O') e1se
'X' ;
El modelo del circuito consistirá, por tanto, en una copia por referencia de las cinco
puertas ando A cada una de estas puertas se le pasará como parámetro los tiempos
de propagación, que como puede verse dependen de su posición en el circuito. La
fórmula empleada consiste en sumar al tiempo base un retardo adicional, en función
del número de entradas extra a las que la puerta está conectada.
2 tplhltphl: tiempo de propagación de Oa l/de 1 a O,

3 dtplhldtphl: variación del tiempo de propagación (Oa 1/1 a O) respecto al fanout de la celda.
Para tener en cuenta los diferentes casos de simulación: típico, mínimo y máxi-
mo, las constantes de tiempo son vectores de tres tiempos, uno para cada caso de si-
mulación. Según sea este caso de simulación, que se pasa como parámetro a la enti-
dad ejemplo, se elegirá el tiempo correspondiente en el vector.
entity Ejemplo is
generie(
Caso tCaso := tipico);
port(
A, B, C, D, E, F in std._logic;
Y1 oot std_logic;
Y2 oot std._logic;
Y3 oot std._logic);
end Ejemplo;
arehiteeture Estructural of Ejemplo is
type tTiempo i8 array (tCaso ranga mínimo to maxitno) of time;
eonstant AND2tpl~ : tTiempo .- (1.8 ns, 2.1.ns, 2.5 ns);

eonstant AND2tphl ..
tTiempo :::: (1.. 7 os, 2.0 ns, 2.3 ns);
eonstant AND2dtplh : tTiempo ::: (0.3 ns, 0.5 os, 0.8 ns);
eonstant AND2dtphl tTiempo .-
(0;25'ns, 0.4 ns, 0.1 ns);
canponent and2
generie (
tplh time;
tphl time) ;
port (
A, B : in std._logic;
y : out std._logic);
end eCJlll)Onent;
signa! Nodol, Nodo2: std._logic;
begin
AND_l: and2
generie map(AND2tplh(Caso) + AND2dtplh(Caso) .. 1,
AND2tphl(Caso) + AND2dtphl(Caso) .. 1)
port map(B, C, Nodo1);
AND_2: and2
generie map (AND2tplh(caso) + AND2dtpl.!1¡caso) .. 1,
AND2tphl(Caso) + AND2dtpni{caso) .. 1)
port map (D, E, Nodo2);
AND_3: and2
generie map (AND2tplh(Caso), AND2tphl (Caso) )
port map (A, Nodo1, n);
AND_4: and2
generie map(AND2tplh(Caso), AND2tphl{Caso»
port map (Nodo1, Nodo2, Y2);
AND_S: and2
generic map (AND2tplh(casol I AND2tphl (caso))
port map (Nodo2, F, Y3);
end Estructural;
LISTADO 5-21. Modelado del retardo parametrizable.
Como puede suponerse, el grado de precisión de los modelos influye notable-

mente en el rendimiento del simulador. Cuanto mayor sea el número de procesos y
variables temporales a manejar y la precisión de éstas (no es lo mismo operar con
enteros que con números reales), menor será el rendimiento del simulador, que ne-
cesitará más tiempo y mayor cantidad de memoria para completar la simulación.
5.5.3. La comprobación
,
de errores
Una de las ventajas de la utilización de los simuladores es que permiten poner de
relieve fácilmente los errores que se pueden producir, no sólo de codificación, sino
también en la concepción del modelo. Por ejemplo, puede resultar que en un siste-
ma con un DMA se genere una dirección de memoria inexistente. O podemos haber
olvidado desactivar el acceso de un componente a un bus y tener en éste como re-
sultado un valor indeterminado. Para facilitar esta tarea, el diseñador puede incluir
explícitamente en los modelos una serie de condiciones, que en caso de no verifi-
carse generarán mensajes de error durante la simulación.
Ejercicio 5.3
Modelar la siguiente memoria ROM, incluyendo las comprobaciones necesarias
para asegurar que las direcciones son correctas antes de realizar una operación de
lectura y escritura.
Habilita
8 Dato
ROM
8 I
Direccion
FIGURA 5-12. Memoria ROM.
Solución
La función Valido será la encargada de 'comprobar que el valor almacenado en
Direccion es un vector formado únicamente por ceros y unos, es decir, representa
una dirección válida. En caso de que la dirección no sea correcta en el momento de
recibir la señal de habilitación se generará un mensaje de error explicativo.
library IEEE;
use IEEE. STD_LOGIC..}IRITH. all ;
entity ejemplo3 is
port(
Habilita in std.._1ogic;
Direccion in stdJogic_vector (7 downto O);
Dato out std_logic_vector (7 downto al);
end Ejemplo3;
architecture Algoritmica of Ejemplo3 is

type tROM is array (O to 255) of std_logic_vector(7 downto O);
begin
ROM: process
variable Memoria: tROM :=

(("00000000"), ('00000001"), others =>"11111111");
function Valido(Vector: in std_logic_vector) return boolean is

begin
for i in O to Vector'length-1 loop
if (Vector(i) /= '0' and Vector(i) /= '1') then
return FALSE;
end if;
end loop;
return TRlJE;
end Valido;
begin
if (Habil.i,ta= ' 1 ') then

if Valido(Direccion) then
Dato <= Memoria (conv_integer (unsigned(Direccion) ));
else
assert FALSE
report 'Direccion no valida»
severity error;
endif;
end if;
wait on Habilita, Direccion;
end process;
end Algoritmica;
LISTADO 5-22. Modelado de una memoria ROM.

Aunque existen múltiples condiciones en las que el comportamiento del circuito

no será el esperado, podemos tratar de resumirlas en dos: por producirse situaciones
prohibidas (direccionamientos fuera de rango, valores indeterminados, ... ), o por no
respetarse los requisitos temporales. En el primer caso es difícil poder dar alguna re-
comendación al diseñador que no sea otra que identifique los posibles puntos de con-
flicto y coloque los controles adecuados. En el segundo caso, sin embargo, el tipo de
comprobaciones a realizar está mucho más acotado, puesto que siempre se trata
de verificar la estabilidad de las señales, su duración y su dependencia temporal.
En el caso de las verificaciones temporales podemos establecer la siguiente cla-
sificación:
• Verificación de tiempos de establecimiento (setup): tiempo que debe haberse
mantenido estable una señal antes de que ocurra un evento en la señal de re-
ferencia.
• Verificación de tiempos de mantenimiento ihold): tiempo que debe mante-
nerse estable una señal después de que ocurra un evento en la de referencia.
• Verificación de la duración de niveles estables.
• Verificación del periodo de una señal.
5.5.4. El modelado detallado de la Máquina Rudimentaria
Aunque, como el título indica, el propósito de este apartado es el de aplicar los

apartados anteriores sobre la Máquina Rudimentaria, nos servirá de excusa para
realizar un recorrido muy general sobre las diferentes maneras de modelar los com-
ponentes más habitualmente utilizados a la hora de diseñar hardware.
Señal 1
T,: Tiempo de establecimiento de señal 1 respecto a señal 2

T 2: TIempo de mantenimiento de señal 1 respecto a señal 2
T3: Duración mínima del nivel '1'
T4: Duración mínima del nivel 'O'
Ts: TIempo mínimo de ciclo
FIGURA 5·13. Verificación temporal.

Nuestro punto de partida será el modelo funcional descrito en la arquitectura

PrimeraParticion (Listado 5.10), en el que ya se ha realizado una primera divi-
sión: los dos procesos que modelan el control (UControl) y los recursos de cálculo
(UProceso). Parece obvio que el primer paso consistirá en implementar cada uno de
estos procesos en una entidad separada. El proceso que modela el control se conver-
tirá en la Unidad de Control (UControl) de la Máquina Rudimentaria, mientras
que el proceso UProceso pasará a ser la Unidad de Proceso (UPoceso). Además,
el sistema deberá disponer de una memoria RAM, en la que se almacenarán los da-
tos y programas, y que hasta ahora se modelaba como parte del banco de pruebas, y
de un árbitro de bus, puesto que suponemos que pueden existir más dispositivos en
el sistema que también estén conectados al bus del sistema.
5.5.4.1. La Unidad de Proceso

La Unidad de Proceso contiene los recursos de cálculo del procesador, y será la en-
cargada de ejecutar las diferentes instrucciones, según lo indique la Unidad de
Control. Para ello, en nuestro caso, dispondrá de una Unidad Aritmético-Lógica
(UAL), de un banco de registros de propósito general en los que almacenar los re-
sultados procedentes de la UAL y la memoria, de un conjunto de registros para ta-
reas específicas, y de la lógica necesaria para interconectar todos estos recursos
(Figura 5-14).
CargaRDM
CargaCP
CargaRI FuenteDirección
CargaA
CargaN
CargaC
IncCP ..
• HabilitaDirección
d
e
C
SelCampo
o RI'3-11 (Rf_Rd)
n
Salto Evaluación
de la
o Condición
FIGURA 5-14. Unidad de Proceso de la Máquina Rudimentaria.

Para desarrollar el modelo de la Unidad de Proceso trataremos por separado el

modelado de la UAL y el banco de registros, puesto que tienen una problemática
especial. Posteriormente, y a partir de estos dos componentes, se desarrollará el mo-
delo de flujo de datos de la unidad. Este modelo es una mezcla entre un modelo es-
tructural y uno funcional, puesto que podrán identificarse los diferentes componen-
tes de la unidad (Figura 5-14) sobre el modelo, pero sin embargo se describirán sin
especificar su implementación. Además, el resultado final será sintetizable.
5.5.4.1.1. La Unidad Aritmético-lógica

La Unidad Aritmético-lógica (UAL) aglutina los recursos de cálculo necesarios
para realizar las operaciones aritméticas y lógicas, como su propio nombre indica.
En nuestro caso, para hacemos una idea de cuáles deberán ser estos recursos, debe-
mos revisar el repertorio de instrucciones de la Máquina Rudimentaria.
Como puede verse en la Tabla 5-2, existen seis tipos de instrucciones que re-
quieren recursos aritmético-lógicos, 'aunque sólo se utilizan cuatro operaciones bá-
sicas, que son: la suma de dos operandos, la resta de dos operandos, el desplaza-
miento a la derecha de un operando y la and lógica de dos operandos, siendo todos
estos operandos de 16 bits. Estas operaciones, además, modificarán el estado de dos
indicadores: negativo y cero, que se activarán si el resultado de la operación es ne-
gativo o es cero, respectivamente.
La siguiente figura muestra gráficamente la interfaz de la UAL con el resto de
la unidad de proceso.
Opera
Cero Operacion
FIGURA 5·15. Unidad Aritmético-lógica.
La UAL tomará como entradas los dos operandos A y B, el tipo de operación a

realizar (Operacion) y la señal que habilitará dicha operación (Opera). En caso de
que esta señal no esté activada simplemente se producirá un paso transparente del
operando B hacia el Resul tado. Como salidas, además de este resultado, se genera-
rán dos indicadores, que notificarán si el resultado de la operación ha sido cero
(Cero) o negativo (Nega ti vo).
library IEEE;
use IEEE.STD~LOGIC_1164.all;
use work.PaqueteMR.all;
entity UAL ls
port(
A in stQ_logic_vector(cBitsDato-l downto O);
B in std_logic_vector(cBitsDato-l downto O);
Opera in std_logic;
Operacion in stQ_logic_vector(l downto O);
Resultado out stQ_logic_vector(cBitsDato-l downto O);
Negativo out stQ_logic;
Cero out std_logic);
end UAL;
LISTADO 5-23. Entidad de la Unidad Aritmético-lógica.
En primer lugar vamos a desarrollar el modelo funcional de la unidad, por las

siguientes dos razones:
1. Porque proporciona una manera rápida de describir la unidad para verificar
su correcta funcionalidad e integrarla en el resto del sistema.
2. Porque desde el punto de vista de la simulación del sistema será un modelo
mucho más eficiente que uno detallado.
El modelo funcional de la VAL prácticamente consiste en una instrucción case
que, en función de la codificación del vector Operacion, almacena el resultado de
la operación en una variable. A continuación se asigna la variable al puerto de sali-
da y se actualizan convenientemente los indicadores Cero y Negativo.
Se ha introducido una estimación del tiempo de retardo para cada operación,
que más que tratar de reflejar el retardo real de cada operación, simplemente trata
de poner de manifiesto las diferencias temporales relativas entre las operaciones.
Las constantes que modelan estos retardos se encuentran definidas en el paquete
PaqueteMR.
library IEEE;
use IEEE.STD_uoGIC_ARITH.all;
architecture Funcional of UAL is
begin
process(A,B,Opera,Operacion)
variable ResultadoTemp std_logic_vector(cBitsDato-l downto O);
variable Retardo: time;
begin
-- Efectúa una operación aritmética

if (Opera = '1') then
case Operacion is
when "00" => -- suma
ResultadoTemp := A + B;
Retardo := TpoSUma;
wben '01" => -- resta
ResultadoTemp := A - B;
Retardo := TpoResta;
when -io- => -- desplazamiento
ResultadoTemp :,;,B(cBitsDato-l¡ & B(cBitsDato-1 downto 1);
Retardo := TpoDespl;
when "11" => -- y lógica
ResultadoTemp := A and B;
Retardo := TpoYLogica;
when others => -- error
ResultadoTernp := (others => ,'X');
Retardo := ti ris;
assert FALSE
report ·Codigo de operacion de la UAL invalido»
severity error;
end case;
el se '.,..
-- Si no hay operación el. resu;J.tadoes B
ResultadoTemp := B;
Retardo := TpoPaso;
end if;
-- Asignación del resultado

Resultado' <= Resu!tadoTemp after Retardo;
-- Cálculo de los indicadores

Negativo <= ResultadoTemp(cBitsDato-1) after Retardo;
if ResultadoTemp = "O' then
Cero <= '1' after Retardo;
else
Cero <= 'o' after Retardo;
end if;
end process;
end Funcional;
LISTADO 5-24. Modelo funcional de la Unidad Aritmético-lógica.
Dado el estado del arte de las herramientas de síntesis automática que se co-
mercializan actualmente, el modelo anterior es prácticamente sintetizable. La ma-
yor parte de estas herramientas son capaces de reconocer las diferentes operaciones
complejas, tales como sumas, multiplicaciones, etc., de manera que a partir de ellas
se infieren los diferentes recursos de cálculo: sumadores, restadores, multiplicado-

res, etc. Además muchas son también capaces de realizar una síntesis arquitectural,
que permite realizar una planificación de la utilización de recursos compartidos en
el caso de que la operación se realice más de una vez.
Quizá lo único que pueda causar problemas sean las referencias temporales,
puesto que las herramientas de síntesis no las soportan (algunas las ignoran y otras
las indican como erróneas). El resultado obtenido a partir de la síntesis dependerá
no sólo de las restricciones que se impongan a la herramienta, sino también de la
tecnología elegida para la implementación del diseño. Seguramente, por ejemplo, el
sumador y el restador se implementarán mediante un módulo sumador/restador,
y su arquitectura podrá ser de tipo ripple-carry, carry look-ahed, etc., en función
de los requerimientos de área y velocidad que se le especifiquen a la herramienta de
síntesis.
Aunque no sería necesario continuar el refinamiento del modelo de la UAL, pues-
to que ya es directamente sintetizable, y las herramientas automáticas son capaces de
evaluar las diferentes alternativas de implementación, según los parámetros especifi-
cados por el usuario, dado el carácter educativo de este capítulo, realizaremos manual-
mente lo que estas herramientas ya son capaces de resolver de forma automática.
Puesto que existen cuatro operaciones diferentes a realizar, realizaremos cada
una de ellas en un módulo diferente. Esto nos permitirá posteriormente jugar con
varias alternativas de implementación para cada uno de estos módulos. Por supues-
to, existen otras particiones alternativas, puesto que, por ejemplo, es muy habitual
encontrar módulos sumadores/restadores, que realizan ambas operaciones depen-
diendo de una señal de control.
Como puede verse en la Figura 5-16, el modelo estructural de nuestra UAL
constará, por tanto, de un bloque para cara operación (sumador, restador, desplaza-
16 A B
Operar
1-{) '.--f-¡- Operacion
..
Negativo Resultado
FIGURA 5-16. Estructura de la UAL.

dor, operador Y), de un multiplexor, que nos permitirá elegir de qué módulo obte-
ner el resultado final, en función del código de operación a realizar, y la lógica
necesaria para activar los indicadores. En este caso no incluiremos información
acerca de los retardos de las diferentes operaciones, puesto que se hará en cada uno
de los diferentes módulos.
Veamos a continuación cómo el código VHDL correspondiente al modelo es-
tructural refleja fielmente la partición de la figura anterior.
library IEEE;
architecture Estructural of UAL is
constant UnCero stdLJogic := 'O';
signal Suma stq_logic_vector(cBitsDato-l downto O);

signal Resta std_1ogic_vector(cBitsDato-l downto O);
signal Desplazamiento stq_logic_vector(cBitsDato-l downto O);
signal YLogica stq_logic_vector(cBitSDato-l downto 0)1
signal ResultadoTemp stq_logic_vector(cBitsDato-l downto O);
signal SelMux stq_logic_vector(2 downto O);
camponent Sumador
generic (
NumBits: natural);
port( A, B in stq_logic_vector(NumBits-l downto O);
Acarreo : out stq_logic;
Resultado: out stq_logic_vector(NumBits-l downto O)i;
end camponent;
camponent Restador
generic(
NumBits: natural);
port ( A, B in stq_lógic_vector(NumBits-l downto O);
Acarreo out stq_logic;
Resultado out std_logic_vector(NumBits-l downto O));
end camponent;
camponent Desplazador
generic (
NumBits: natural);
port ( A ... in stq_logic_vector(NumBits-l downto O);
Resultado: out stq_logic_vector(NumBits-l downto O));
end camponent;
camponent OperadorY
generic t
NumBits: natural);
port( A,B . in stq_logic~vector(NumBits-l downto O);

Resultado out std_logic~vecto((Num6its-l downto O));
end COII¡)OIlEIIlt;
,'J-~ j,.
cQl'Ii)OnentMultiplexara
generie (
NumBits: natural):
port (
A,B,C,D,E,F,G,H in stq_logic_vector (NumBits-l downto Oh
Control in stq_logic_vector(2 downto O);
y out stá._logic_vector(NumBits-l downto O));:
end cCIIq)Ollent;
begin
-- Operaciones
Sumar: Sumador
generic map (cBitsDato)
port map (A, B, apen, Suma);
Restar: Restador
generic map (cBitsDato)
port map(A, B, apen, Resta);
Desplazar: Desplazador
generic map(cBitsDato)
port map (B, Desplazamiento);
OperarY: OperadorY
generic mep(CBitsri§to)
port map (A, B, 'fL?9~ca);
-- Multiplexor
SelMux <= Opera & Operacion;
Mux8: Multiplexor8
ganerie map(cBitsDato)
port map (B, B, E, B, Suma, Resta, Desplazamiento, YLogica,
SelMux~:;ResultadoTeIlI» ; .' i;
-- Indicadores
Negativo <= ResultadoTemp(cSitsDato-1);
Cero <= '1' wben ResultadoTemp = ·0" else
'O' ;
-- Asignación. al port de salida

Resultado <= ResultadoTemp;
end Estructural;
LISTADO 5-25. Modelo estructural de la Unidad Aritmético-lógica.

Llegados a este punto, el siguiente paso en el proceso de refinamiento consistirá

en definir las arquitecturas de los componentes. Trataremos únicamente la del suma-
dor en este texto, puesto que la del restador es muy similar, y las restantes triviales.
Respecto al sumador, evaluaremos dos posibles alternativas de implementa-
ción. En la primera utilizaremos una arquitectura con cálculo del acarreo en serie
ripple-carry, mientras que la segunda será con cálculo del acarreo anticipado
(carry-lookahead). Trataremos, además, de evaluar aproximadamente cuál puede
ser el coste aproximado de cada implementación en términos de área y número de
puertas. Como en los modelos desarrollados hasta este punto del capítulo, los pará-
metros en los que nos basamos para realizar estas comprobaciones son relativos,
puesto que no están extraídos de datos reales.
5.5.4.1.1.1. El sumador con acarreo de propagación (ripp/e-carry)

El sumador ripple-carry (Figura 5-17) se compone de una serie de sumadores com-
pletos (jull-adders), cada uno de los cuales realiza una suma de dos bits más un aca-
rreo de entrada, generando un bit de resultado y un acarreo de salida. Estos módulos
se encadenan en serie entre sí, de manera que el acarreo de salida de uno sirva co-
mo acarreo de entrada del siguiente.
AcarreoS AcarreoE AcarreoS AcarreoE 'O'
se se
Resultado Resultado
Acarreo Hesultado.¿ Resultado¿
FIGURA 5-17. Sumador con acarreo en serie.
El siguiente listado muestra el código VHDL correspondiente a la función del

sumador completo, descrito mediante un flujo de datos.
libraxy IEEE;
entity SumadorCampleto 1a
port ( A,B in std_logic;
AcarreoE in std,_logic;
Resultado out std....logic
¡
AcarreoS out std_logicl;
end SumadorCompleto;
architecture FlujoDeDatos of SumadorCompleto 1a
signal Ternp: std_logic;
begin
Ternp <= A xor B after TpoXor;

Resultado <= Ternp xor AcarreoE after TpQXor;
AcarreoS <= (A and B) or (Ternp and AcarreoE) after TpoAO¡
end FlujoDeDatos;
LISTADO 5-26. Modelo flujo de datos del sumador completo.
La principal ventaja de este tipo de sumadores, desde el punto de vista de su

implementación, es que son poco costosos en términos de área ocupada. Por con-
tra, suelen ser excesivamente lentos, puesto que, como se puede apreciar en la Figu-
ra 5-17, el cálculo de cada etapa no puede realizarse hasta que haya finalizado la
anterior, debido al conexionado en serie de los bloques.
Puesto que se trata de modelar una estructura regular, utilizaremos en este caso
la instrucción genera te, tal y como muestra el siguiente listado.
library IEEE;
arch1tecture Ripple of Sumador 18
camponent SurnadorCompleto
port(
A,B in std,_logic;
AcarreoE in std,_logic;
Resultado out std_logic;
AcarreoS out std,_logic);
end CCJDpOOeOt;
signal AcarreoTernp: std_logic_vector(Numbits downto O);
beg1n
AcarreoTemp(O) <= 'O';

Acarreo <= AcarreoTernp(NumBits);
Sumador: for i in O to NumBits-l generate

Celda_Sumador: SumadorCompleto
port map(
A => A(i),
B => B(i),
AcarreoE => AcarreoTerrp(il,
Resultado => Resultado(i),
AcarreoS => AcarreoTemp{i+l»;
end generate Sumador;
end Ripple;
LISTADO 5-27. Modelo estructural del sumador con acarreo serie.
Para estudiar el comportanúento temporal del sumador revisemos el Listado 5-26.

Como puede apreciarse se realizan dos tipos de operaciones diferentes, equivalentes
a las puertas lógicas xor y AndOr. A cada una de estas operaciones, por tanto, se le
ha asignado un tiempo equivalente al del retardo de la puerta correspondiente. Así
es fácil comprobar que el camino más crítico corresponde a la señal de acarreo,
puesto que los tiempos de retardo serían los siguientes:
Tiempo(Resultado) = 2 * TpoXor
Tiempo(Acarreo) = TpoXor + 1POAO,
donde TpoAO > 'lPoXor.
A partir de estos cálculos es inmediato deducir que el camino crítico en el su-
mador será el que va desde el acarreo de entrada hasta el de salida, pasando por los
16 sumadores completos. El tiempo total, tanto para el cálculo del Resultado como
del Acarreo, puede expresarse de la siguiente manera:
Tiempo(Acarreo) = TpoXor + 16 * TpoAO

Tiempo(Resultado) = TpoXor + 15 * TpoAO + TpoXor
En el primer caso, puesto que el cálculo de un acarreo depende de la finaliza-

ción de la etapa anterior, el retardo total corresponde a la suma de los retardos de la
función AndOr, más el tiempo de retardo de la operación A xor B, que debe reali-
zarse en primer lugar.
En el segundo caso, el tiempo total es la suma de esta primera operación, más el
retardo de las 15 etapas de cálculo de acarreo, junto con el tiempo de la operación
xor, que calcula el resultado de la última etapa a partir del acarreo de la anterior.
5_5.4.1.1.2. El sumador con acarreo anticipado (carrylook-aheadJ

Como hemos visto, el sumador con acarreo de propagación puede resultar demasia-
do lento, debido a que para calcular el resultado de cada bit debe esperarse la propa-
gación del bit de acarreo a través de todas las etapas anteriores.
Una solución alternativa es la que presenta el sumador con acarreo anticipado.

En este caso se trata de dividir el sumador en bloques más pequeños, de los que se
pueda obtener el acarreo resultante por anticipado, para que de esta manera el si-
guiente bloque pueda comenzar a realizar sus cálculos antes de que el anterior haya
finalizado. Para ello se aprovechará el hecho de que toda ecuación combinacional
puede expresarse como una función de dos niveles, así que pasemos a obtener las
funciones correspondientes a cada bit de acarreo de un bloque.
La Tabla 5-6 refleja las diferentes posibilidades de propagación de acarreo en
la operación de suma de dos bits.
TABLA 5-6. Propagación del acarreo
Aj Bj Cj
O O O
O 1 Cj+1 propagación
1 O Cj+1 propagación
1 1 generación
Como puede apreciarse en la tabla anterior, si A = B = Ono se generará ningún

acarreo a la etapa siguiente, a diferencia del caso A = B = 1, en el que sí lo habrá
(etapa de generación). Sin embargo, en los casos en los que A <> B, puesto que
sólo una de las dos entradas vale '1' habrá acarreo de salida sólo en el caso de que
el de entrada tome el valor '1'. Dicho de otra manera, en este caso se propaga el
acarreo de entrada directamente a la salida (etapa de propagación).
Según la explicación, las ecuaciones booleanas correspondientes a las etapas de
generación (G) y propagación de acarreo (P), extraídas de la tabla anterior, serían
las siguientes:
Gj =Aj and B,
Pj =Aj xor B,
De la misma tabla, también puede concluirse que se obtiene un acarreo de sali-

da siempre que se trate de una etapa de generación, o una de propagación en la que
haya un acarreo de entrada. En forma de ecuación:
Finalmente, podríamos expresar la suma en función de las ecuaciones ante-

riores:
Si en la expresión que calcula el acarreo de salida en función del de entrada

sustituimos este último por su ecuación equivalente obtendremos:
Continuando este proceso, desarrollando las ecuaciones de los diferentes aca-

rreos, obtendríamos una ecuación que dependería únicamente del acarreo de entra-
da al sumador Ca. Además, corno es bien sabido, toda ecuación booleana puede ex-
presarse como una suma de productos (o producto de sumas), cuya implementación
se realiza con dos niveles de puertas.
En nuestro caso, puesto que se trata de un sumador de 16 bits, no podemos pre-
tender calcular el acarreo anticipado para todos ellos, puesto que sería necesario un
gran número de puertas, algunas de las cuales tendrían más de cuatro o cinco entra-
das. La alternativa más habitual consiste en dividir el total de bits en grupos (cuatro
grupos de cuatro bits en nuestro caso) y acelerar el cálculo del acarreo para cada
grupo por separado. Aunque esta opción requiere un tiempo de cálculo mayor, asu-
me un compromiso área/velocidad mucho más razonable. La Figura 5-18 muestra
los diferentes bloques que formarán parte del sumador con acarreo anticipado.
Como se observa, existen tres tipos de bloques bien diferenciados. El bloque
P&G es el encargado de calcular los valores de propagación y generación del aca-
rreo para cada bit. El bloque Suma obtiene el resultado final a partir de la propaga-
ción calculada por el bloque anterior y el acarreo correspondiente, calculado en los
bloques CLA. Finalmente, el bloque CLA debe obtener el valor del acarreo anticipa-
INCRUSTAR
Resultado'5-'2 A'5-'2 8'5-'2 Resultado"_8 A"_8 8"_8 Hesultado., A7_4 87-4 Resultado3-Q A3-Q83-Q
FIGURA 5-18. Sumador con acarreo anticipado.

do, calculado a partir de la ecuación (*). En este caso, cada bloque CIA obtiene los
valores del acarreo de un grupo de cuatro bits, por lo que en total son necesarios
cuatro bloques en un primer nivel (4 bloques*4 bits = 16 bits), más un último CIA,
responsable de calcular por anticipado el acarreo que toma como entrada cada blo-
que del primer nivel.
El Listado 5-28 contiene el código VHDL correspondiente al bloque CIA. El
Listado 5-29 modela el sumador, utilizando el componente CIA anterior. Observe
cómo, por simplicidad del modelo y eficiencia, los bloques P&G y Suma no han
sido implementados tal cual aparecen en la figura. En su lugar, el cálculo de la pro-
pagación y generación de acarreo, y el cálculo de la suma, se efectúa mediante la
operación lógica correspondiente. El código obtenido es absolutamente equivalente.
library IEEE;
entity CLA is
generic(
NumBits : integer := 4);
port(
G in std_logic_vector(NumBits-l downto O);
P in stq_logic_vector(NumBits-l downto O);
AcarreoE in std~logic;
GG out std._lcijic;
AcarreoS out std_ioglc,;"vector(NumBits-l downto O»)';
end CLA;
architecture Funcional of CLA is
begin
CLA: process(G, P)
variable PTenp, GTenp std_logic;
variable AcarreoTenp std_logic;
begin
PTenp := P(O);
GTemp := G"{O);
AcarreoTemp : = AcarreoE;
AcarreoS (O) <= AcarreoE;
for i in 1 to NumBits-l loop
PTenp := PTenp aDd P(i);
GTeI1il := G(i) or (GTeI1ilaDd P(i»;
AcarreoTenp : = G(i -1) or (AcarreoTemp and P (i -l» ;
AcarreoS (i) <:; ,AcarreoTerrq:¡;
end loop;
GC <= GTenp;
GP <= PTenp;
end process CIA;
end Funcional;
~ISTADO 5-28. El bloque CLA.

library IEEE; . ,
arehitecture CLA of Sumador is
eOlli>OnentCIA
generlc (
NumBits : lnteger := 4);
port(
G in stCLlogic_vector (NumBits-l downto O);
P in stCl.logic_vector(NumBits-l downto O);
AcarreoE in stCLlogic; . , ,
GG out stCLlogic;
GP out stCLlogic;
AcarreoS out std.._logic_vector(NumBits-l downto O));
end cClllPOnent;
signal G, P ,. st<l_logic_vector(NumBits-l downto O);
signal GG std_logic_vector(NumBits/4-1 downto O);
signal GP sfd_logic_vector(NumBits/4-1 downto O);
signal GC stCLlogic_vector'(NumBits/4-1 downto O);
signal AcarreoG stCl.logic_vector(NumBits-l downto O);
signal Cero std_logic := 'O';
begin
-- Cálculo de las etapas de generación y propagación
G <= A and B;
P <= :xor B;
-- Cálculo de la suma final

Resultado <= P :xor AcarreoG(NumBits-l downto O);
-- cálculo del acarreo anticipado
CLANivell: for i in O to (NumBits/4-1) generate
CeldaCIA: CIA
generie map(NumBits => 4)
port map(
G => G(i*4 to i*4+)),
P => P(i*4 to i*4+3),
AcarreoE => OC(i),
GG => OO(i),
GP => GP(i),
AcarreoS => AcarreoG(i*4 to i*4+3));
end generate CLANivell;
CIANive12: CIA
generie map(NumBits => 4)
port map(
G => GG.
P => GP,
AcarreoE => Cero,
GG => apeo,
GP => apeo,
AcarreoS => GC);
end CIA;
LISTADO 5-29. Modelo estructural del sumador con acarreo anticipado.

Analicemos ahora cuál puede ser el caso más desfavorable respecto al retardo
de este sumador. Fijémonos para ello en la Figura 5-18. El primer nivel de retar-
do será el introducido por la etapa de cálculo de la generación y propagación (tiem-
poixorj). Puesto que, como se ha mencionado, la función implementada por el blo-
que CIA tendrá dos niveles de puertas, consideraremos su retardo similar al de una
puerta AndOr. Finalmente, el cálculo de la suma consumirá de nuevo el tiempo de
retardo de una puerta Xor. Partiendo de estos supuestos podemos expresar el retar-
do de la siguiente manera:
Tiempo(Resultado) = TpoXor * 2 + TpoCIA *3

Tiempo(Acarreo) =
TpoXor + TpoCIA * 3
El retardo del bloque CIA aparece multiplicado por el valor tres, puesto que
debe pasarse por el primer nivel de bloques para proporcionar al segundo sus entra-
das (1), a su vez éste proporciona los acarreos de entrada a los bloques del primer
nivel (2), y este último los acarreos definitivos para cada bit (3).
Como puede comprobar, si se considera el tiempo de un bloque CIA equiva-
lente al de una puerta AndOr, el retardo de este tipo de sumadores es mucho menor
que los que calculan el acarreo en serie:
Tiempo(Serie) = TpoXor * 2 + 16 * TpoAO

Tiempo(Anticipado)::: TpoXor * 2 + 3 * TpoAO
Por contra, el número de puertas necesario para la implementación de este últi-
mo es mucho menor que para el primero.
5.5.4. 1.2. El banco de registros

El banco de registros contiene los ocho registros de propósito general en los que se
almacenan los datos que se envían y reciben de la memoria, así como los que inter-
vienen en las operaciones ejecutadas por la UAL.
Revisemos la descripción funcional de la Unidad de Proceso, Listado 5-17.
Dentro del proceso UProceso podemos observar lo siguiente:
• El banco de registros se ha modelado como un vector de vectores de bits,
con tantas posiciones como de registros consta el banco.
• Cada vez que se da la orden Inicializa, todos los registros toman el
valor o.
• Para poder escribir en un registro debe activarse la señal EscribeRegistro.
• Durante el funcionamiento normal de la unidad operativa, los cambios en los
registros se realizan en el flanco de subida del Reloj.
• Las señales SelRegLectura y SelRegEscri tura seleccionan el registro en
el que se escribirá el dato de entrada al banco y el que será el dato de salida,
respectivamente.
Ahora sólo tenemos que colocar toda esta funcionalidad dentro de un nuevo
componente, al que denominaremos BancoRegistros, y cuya entidad será la si-
guiente:
librazy IEEE;
use IEEE.STD~LOGIC_1164.all;
use work.PaqueteMR.a11;
entity BancoRegistros is
port(
Reloj in std_logic;
Inicializa in std_logic;
DatoEscritura in std_logic_vector(cBitsDato-1 downto O);
EscribeRegistro in std_logic;
SelRegLectura in std_logic_vector(2 dowoto O);
SelRegEscritura in std_logic_vector(2 downto O);
DatoLectura out std_logic':'_vector(cBitsDato-l downto O)
);
end BancoRegistros;
LISTADO 5-30. Entidad del banco de registros.
Un banco de registros, y en general cualquier tipo de lógica secuencial, puede

modelarse mediante un proceso secuencial (refiérase al apartado 4.7), que suele te-
ner la siguiente estructura:
process (Reloj, Inicializa)

begin
if Inicializa = '1' then
-- ínicfal iza la lógica secuencial
elsif Réloj'évent and Reloj = '1' then
-- cálculo del valor á asignar
end if;
end process;
LISTADO 5-31. Un proceso secuencial.
En este caso la respuesta del modelo a la señal Inicializa será de tipo asín-
crono, puesto que no depende del estado del reloj. Para modelarla como una señal
síncrona sería suficiente con preguntar por su estado dentro de la condición que
comprueba si ha habido un evento en el reloj, en lugar de hacerlo antes, como en el
listado. Utilizando este esqueleto, completemos la arquitectura funcional de nuestro
banco de registros.
librazy IEEE;
use IEEE.STD_LOGIC_1164.a11;
use IEEE. STD_LOGIC_ARITH .aH ;
use work.PaqueteMR.a11;
architecture Funcional of BancoRegistros is

begin
Banco: process(Reloj, Inicializa, SelRegLectura)

variable Registros: tRegistros(O to cNumRegs-lli
begin

for i in O to cNurnRegs-l loop
Registros(i) := (others => '0');
end loop;
elsif EscribeRegistro = '1' then
if Reloj'event aDd Reloj = '1' then
Registros (conv_integer (unsigned (SelRegEscri tura)) l := DatoEscri tura;
end if;
end if;
DatoLectura <= Registros ( conv_integer lunsignedlSelRegLectura) l)

after TpoRegistro;
end process Banco;
end Funcional;
LISTADO 5-32. Descripción funcional del banco de registros.
En nuestro caso la inicialización del banco, que tendrá lugar cuando la señal
Inicializa tome el valor '1', consistirá en un bucle que asignará el valor Oa todos
los registros. Puesto que se trata de un banco de registros, no es necesario realizar
ningún cálculo sobre el valor a almacenar, que directamente será DatoEscritura.
Sin embargo, obsérvese que antes de verificar si se ha producido un evento de reloj,
para almacenar el valor en el registro correspondiente, se comprueba el estado de la
señal EscribeRegistro. La razón es que esta señal es más prioritaria que el reloj,
puesto que no hay asignación si no está activada.
En nuestro modelo aparece además una asignación concurrente, que simple-
mente se encarga de asignar como dato de salida del banco el contenido del regis-
tro, indicado por SelRegLectura. A esta asignación se le ha asociado un retardo
fijo TpoRegistro, que pretende modelar el tiempo empleado en leer el dato del
registro que corresponda.
5.5.4.1.3. Modelado de la Unidad de Proceso

En primer lugar definamos la entidad correspondiente a esta unidad. Como puede
apreciarse claramente en la Figura 5.14, la Unidad de Proceso se comunica, por un
lado, con la Unidad de Control, de la que recibe las diferentes señales de control y
a la que proporciona cierta información de estado, y, por otro, con la memoria de
programas y datos. Concretamente, de la Unidad de Control recibe las siguientes
señales:
• las que controlan la carga de los registros

• la de control de acceso al banco de registros
• la señal de operación de la UAL
• las señales de control de la carga de los registros específicos
• las señales de control de acceso al bus del sistema.
Como información de estado, la Unidad de Proceso indica a la Unidad de Con-
trol:
• el resultado de la evaluación de la condición indicada en la instrucción en
curso
• el código de operación de dicha instrucción, de manera que la Unidad de
Control pueda decidir cuál debe ser su nuevo estado.
El intercambio con la memoria consiste, sencillamente, en enviar una direc-
ción desde la que se leerá o en la que se escribirá un dato, según indique la Uni-
dad de Control.
library IEEE;
use lEEE.STD_LOGIC_1164.all;
entity UProceso 18
port (
Reloj : in std._logic;
Inicializa : in std_logic;
-- Control de carga de los registros específicos

CargaRrM in std_logic;
CargaCP in std._logic;
CargaR! in std_logic;
CargaA in std_logic;
IncCP in std_logic;
CargaN in std-"logic;
CargaC in std_logic;
-- Control de la UAL
Opera : in std_logic;
-- Control del banco de registros

SelC~ in std._logic_vector(l downto O);
EscribeRegistro : in std_logic;
-- Control de acceso al bus

FuenteDireccion in std_logic;
HabilitaDireccion in std._logic;
HabilitaDatos in std_logic;
-- Indicadores
CodigoOp out std_logíc:,:"véctor(l downto O);
Salto e out std_logic;
-- Memoria
Direccion out std...logic,_vector(<;Bit,SDirecqion-1 downto O);
Datos inout std...logic_vectorlcBitsDirecci0I1-1 downto O));
end UProceso;
LISTADO 5-33. Entidad de la Unidad de Proceso.
Puesto que en los subapartados anteriores se ha modelado la UAL y el banco

de registros, disponemos de estos dos componentes para incluirlos por referencia
en el modelo de la Unidad de Proceso. Como indicábamos al comienzo del capí-
tulo, además de estos dos componentes se dispondrá de un conjunto de registros y
cierta lógica adicional, encargada de conectar todos estos recursos, de la manera
indicada en la Figura 5-14. Por tanto, el aspecto general del modelo será el si-
guiente:
architecture FlujoDeDatos of UProceso is
-- Declaración de componentes
CCJll)O!leIlt UAL
end component;
component BancoRegistros
end component;
-- Registros específicos
signal A std...logic_vectorlcBitsDato-1 downto O);
-- Registro Acumulador
-- Señales temporales
signal B : std...logic_vectorlcBitsDato-1 downto O);
-- Campos del Registro de Instrucción IRI) (alias)
begin
Copia por referencia de los componentes UAL y Banco Registros
-- Modelado de los registros específicos
-- Lógica adicional
end FlujoDeDatos;
LISTADO 5-34. Descripción en flujo de datos de la Unidad de Proceso.

La asignación de los alias a los campos del registro de instrucción puede

resumirse en la siguiente tabla.
TABLA 5-7. Codificación de las instrucciones de la Máquina Rudimentaria
Instrucción Bits 15-14 Bits 13-11 Bits 10-8 Bits 7-0

LOAD 00 Rd Ri Dirección Base
STORE DI Rf Ri Dirección Base
Salto ID Condición 000 Dirección
Operación con inmediato II Rd Rfl Número/Operación
Operación aritmética II Rd Rfl Rf2 / DO/Operación
El modelo correspondiente a los registros específicos es prácticamente idéntico

para todos ellos. Todos los registros disponen de una señal de inicialización asíncro-
na (Inicializa) y una señal de habilitación síncrona (Cargaxx). Las únicas par-
ticularidades son las que presentan los registros de Dirección de Memoria (RfM) y el
contador de programas (cP). El primero almacena el resultado de una suma, mien-
tras que el segundo dispone de otra señal de control, además de la de carga, también
síncrona, que cuando se activa incrementa el valor almacenado en el registro.
-- Registro de instrucci6n
rRI: process{Inicializa,Reloj)
begin
if (Inicializa = '1') then
RI <= (others => 'O');
elsif (Re1oj'event and Reloj 'g') then
if (CargaRI = ' 1') then
RI <= Datos;
end if;
end if;
end process rRI;
-- Registro Contador de programas

rCP :process{InicialiZa,RelojJ
begin
CP <= (others => 'O');
elaif (Reloj'event and Reloj = '0') then
if (IncCP = '1') then
CP <= unsigned{CP) + '1';
end if;
if (CargaCP = '1') then
CP <= RI (7 downto O);

end if;
end if;
end process rCP;
-- Registro de dirección
rROM :process(Inicializa,Reloj)
begin
ROM <= (otbers => 'O');
elsif (Reloj'event and Reloj = 'O') then
if (CargaRDM = ' 1') then
ROM <= unsigned(RI (7 downto O)) + unsigned(Rx(7 downto O));
end if;
end if;
end process rRDM;
-- Registro Acumulador
rA :process(Inicializa,Reloj)
begin
A <= (otbers => 'O');
elsif (Reloj'event and Reloj 'O') then
if (CargaA = '1') then
A <= Rx;
end if;
end if;
end process rA;
-- Registro C
rc: process(Inicializa,Reloj)
begin
C <= '0';
elsif (Reloj'event and Reloj '1') then
if (CargaC = '1') then
C <= Cero;
end if;
end if;
end process rC;
-- Registro N
rN: process(Inicializa,Reloj)
begin
N <= 'O';
elsif (Reloj'event and Reloj - '1') then
if (CargaN = '1') then
N <= Negativo;
end if;
endif;
end process rN;
LISTADO 5-35. Modelado de los registros específicos.

El resto de la funcionalidad del circuito corresponde a la lógica combinacional

que interconecta los diferentes recursos modelados hasta el momento. El siguiente lis-
tado corresponde al modelado de los dos multiplexores utilizados para seleccionar la
fuente del segundo operando de la VAL y la fuente del campo registro (Figura 5-14).
Como puede observarse, el primer multiplexor se ha modelado mediante un proceso
combinacional que contiene una instrucción case, para seleccionar en función de la
señal de selección Sel la fuente correspondiente. Sin embargo, el segundo utiliza una
asignación concurrente condicional para realizar la misma operación.
-- Selección de fuente del segundo operando

OpSel: process(Datos,RI,Rx)
variable Sel: std_logic_vector(l downto O);
begin
Sel := RI(14) & RI(2);
case (Sel) is
when "OO' => B <= Datos;
when "01" => B <= Datos;
when -io- => B <= R¡ m & RI (7) & RI(7) &
~(7) &RI(7) &.Iu.i7) &
RI(7) & RI(7) & RI(7) &
RI(7) & RI(7) & RI(7 downto 3);
when "11H => B <= Rx;
when others => B <= (others => 'X');
end case;
end process OpSel;
-- Selección del registro del banco

with SelCampo select
SelRegistro <= Rf_Rd when '00',
Rf1_Rj when "01',
Rf2 when "10',
(others => '-') when "11",
(others => 'X') when others;
-- Selección del registro del banco
with SelCampo select
SelRegistro <= Rf_Rd when "DO",
Rf1_Rj when "01',
Rf2 when "10',
(others => '-') when "11 H,
(others => 'X') when others;
LISTADO 5-36. Modelado de los multiplexores.
La lógica combinacional restante se encargará de la función de evaluación de la

condición de salto y la habilitación de los tri-estado de acceso al bus del sistema.
-- Evaluación de la condición
EvalCond:process(Condicion,Negativo,Cero)
variable Resultado : std_logic;
begin
Resultado := 'O';
case Condicion is
when '000· => Resultado := 'l'L,-'" BR
when '001"1"101" => Resultado := Cero; .;..B~
when '010·1"110· => Resultado := Negativo; -- BL
when '011" => Resultado := Negativo ar Cero; -- BLE
when "101" => Resultado := not Cero; -- BNE
when "110· => Resultado := not Negativo ar Cero; -- 1lOE
when "U1" => Resultado := Negativo and Cero; -- BG
when others => Resultado .- 'X';
end case;
Salto <= Resultado;
end process EvalCond;
-- Selección de la dirección de memoria

Direccion <= ROM when
(FuenteDireccion = '1' and HabilitaDireccion = '1') elBe
CP when
(FuenteDireccion = 'O' and HabilitaDireccion = '1') elBe
(others => 'Z');
-- Habilitación de los datos
Datos <= Rx when HabilitaDatos = '1' elBe
(others => 'Z');
LISTADO 5-37. Modelado de la condición de salto.
5.5.4.2. La Unidad de Control
La Unidad de Control es la encargada de sincronizar todas las tareas que deben rea-
lizarse para ejecutar las instrucciones sobre la unidad operativa. Nos referimos a es-
tas tareas elementales que conforman cada instrucción como microoperaciones, de
manera que la ejecución de una instrucción consistirá simplemente en llevar a cabo
la secuencia de rnicrooperaciones que le corresponda.
En nuestro caso, el control de la ejecución de las diferentes microoperaciones
se realizará mediante una serie de señales de control sobre la unidad de proceso, el
bus del sistema y el árbitro de bus. Además, su secuenciamiento dependerá de la in-
formación de estado proporcionada por la unidad de proceso, en forma de señales
de entrada, tal y como muestra la Figura 5-19.
A partir de la figura anterior puede determinarse el código VHDL correspon-
diente a la entidad de la Unidad de Control (Listado 5-38), y cuya funcionalidad
modelaremos en los siguientes apartados.
CargaRDM
CargaCP
Árbitro de BusLibre CargaRI
Bus PeticionBus CargaA
CargaN
CargaC
Unidad de Unidad de
IncCP
Control proceso
Opera
EscribeRegistro
SelCampo
FuenteDirección
HabilitaDirección
I AWnwri, F Escribe
HabilitaMem
HabilitaDatos
Salto
CodigoOp
FIGURA 5-19. Unidad de Control de la Máquina Rudimentaria.
library IEEE;
entity UControl is
port (
Reloj in std_logic;
Inicializa in std_logic;
-- Estado de la UP
CodigoOp in std_logic_vector(l downto O);
Salto in std_logic;
-- Microoperaciones
CargaRDM out std_logic;
CargaCP out std_logíc;
CargaRI out std_logíc;
CargaA out std_logíc;
IncCP out std_logic;
CargaN out std_logic;
CargaC out std_logic;
Opera out std_logic;
EscribeRegistro out std_logic;

SelCampo out std_logic_vector(l downto O);
FuenteDireccion out std_logic;

HabilitaDireccion out std_logic;
HabilitaDatos out std_logic;
HabilitaMem out std_logic;

Escribe out std_logic;
BusLibre in std_logic;
PeticionBus out std_logicl;
end UControl;
LISTADO 5-38. Entidad de la Unidad de Control.
Existen dos alternativas a la hora de implementar la funcionalidad de una Uni-

dad de Control:
• Cableada: cuando la secuencia de las diferentes microoperaciones se en-

cuentra implementada en el hardware.
• Microprogramada: las microoperaciones se agrupan en microinstrucciones
que se almacenan en una memoria ROM interna a la unidad, que junto con
un secuenciador permiten la ejecución de los diferentes microprogramas que
corresponden a cada instrucción.
En el resto de la sección analizaremos cuáles deben ser las microoperaciones

que la Unidad de Control de la Máquina Rudimentaria debe realizar para ejecutar
cada una de las diferentes instrucciones. Todas aquellas microoperaciones que se
puedan realizar simultáneamente se agruparán en estados, para finalmente obtener
el diagrama de estados total de la Unidad de Control. Por último, estudiaremos las
diferentes alternativas de implementación: cableada y microprogramada.
5.5.4.2. 1. El diagrama de estados de la Unidad de Control

Recordemos que la Máquina Rudimentaria dispone de cinco formatos de instruc-
ción diferentes, resumidos en la Figura 5-4.
La Figura 5-20 muestra el diagrama de estados de la máquina de control que
implementa la Unidad de Control.
El estado inicial del diagrama (Solici taBus 2) es el encargado de solicitar el
bus al árbitro de bus. No debemos olvidar que pueden existir otros componentes en
el sistema que también tomen el control del bus, por lo que antes de acceder a él
hay que realizar una petición y esperar la concesión.
2 Se llega a este estado cada vez que finaliza la ejecución de una instrucción o se produce una
inicialización del sistema.

Bl : BusLíbre
CO : CodigoOp
S : Salto
FIGURA 5-20. Diagrama de estados de la Unidad de Control.
Una vez concedido el bus, la siguiente fase (BuscaInstruccion), de búsqueda

y descodificación de la instrucción, es común a todas las instrucciones. Se encarga
de almacenar en el registro RI la siguiente instrucción a ejecutar. A partir de este es-
tado, yen función del código de operación de la nueva instrucción (CodígoOp) y la
condición de salto (Salto) se decidirá el tipo de operación y, por tanto, cuál debe
ser el siguiente estado.
En el caso de las instrucciones de carga y almacenamiento de la memoria
(LOAD y STORE) será necesario calcular previamente la dirección desde o a la que
se va a realizar la carga o almacenamiento (CalculaDíreccion). Posteriormente,
en función del código de operación se ejecutará dicha carga (CargaDato) o almace-
namiento (AlmacenaDato).
La carga del dato (CargaDato) consiste en acceder a la memoria RAM del sis-
tema para obtener el dato a almacenar en el banco de registros.
Almacenar el dato (AlmacenaDato) significa guardar en la memoria del siste-
ma el contenido del registro especificado.
La instrucción de salto sólo requiere un estado (CargaDireccion), durante el
cual se colocará en el registro contador de programas la nueva dirección de programa.
La ejecución de las operaciones aritmético-lógicas se realiza en dos fases. Pri-

mero, se almacena en el acumulador el primer operando (LeeOperando), que se
halla en un registro del banco de registros. A continuación se obtiene del banco de
registros el segundo operando, se ejecuta la operación y almacena el resultado en el
registro destino (estado Ejecuta).
La Tabla 5-8 muestra detalladamente cuáles son las órdenes de control que de-
ben activarse durante cada estado del diagrama de la Figura 5-20.
TABLA 5-8. Activación de las señales de control en cada estado
1 2 3 4 5 6 7 8
Carga A O O O O O O 1 O
CargaC O O O O O O O 1
CargaCP O O O O O 1 O O
CargaN O O O O O O O 1
CargaRDM O O 1 O O O O O
Carga RI O O O O O O O
IncCP O 1 O O O O O O
EscribeRegistro O O O O O O 1
SelCampo Rd Rfl_Rx Rf2
Opera O 1
HabilitaDatos O O O O 1 O O O
HabilitaDireccion O 1 O 1 1 O O O
Escribe Z Z Z Z 1 Z Z Z
PeticionBus 1 O O O
Consideremos ahora cómo implementar en la práctica el autómata que realiza

todas estas operaciones. Como primera opción trataremos el diseño del circuito a
medida. Es decir, escribiremos el código VHDL correspondiente a este diagrama de
estados, de manera que sea directamente sintetizable, para de esta manera imple-
mentarlo de la misma forma que la Unidad de Proceso. Veamos, pues, cuál debe ser
el estilo de la descripción.
5.5.4.2.2. Implementación cableada de la Unidad de Control

Una implementación cableada consiste simplemente en realizar un circuito a rnedi-
da que, a partir de las señales de entrada y el estado memorizado, genera las corres-
pondientes salidas. Las implementaciones cableadas generalmente son más rápidas
que las microprogramadas, a costa, sin embargo, de un mayor coste y complejidad.
En el caso de la Máquina Rudimentaria, la funcionalidad de la unidad de con-

trol está determinada por la máquina de estados de la Figura 5-20. Para su imple-
mentación podemos optar por varias alternativas. Podríamos utilizar una PLA en la
que se codificaran las ecuaciones booleanas correspondientes a cada salida, junto
con un registro que almacenara el estado actual. Otra opción, que será la que trate-
mos a continuación, consistirá en describir el comportamiento de la unidad median-
te un modelo de VHDL sintetizable, obteniendo así el circuito equivalente.
En general, una buena técnica para modelar en VHDL sintetizable diagramas
de estados como el de la Figura 5-20 consiste en utilizar dos procesos. En uno de
ellos se especifica la parte secuencial, es decir, se almacena el valor del estado. El
otro es puramente secuencial, y en él se generan las salidas correspondientes al es-
tado actual y se calcula cuál será el siguiente, ya que se trata de un diagrama tipo
Moore. De esta manera no sólo se facilita el trabajo a las herramientas de síntesis,
sino que además se obtiene una descripción clara e inteligible. Refiérase al aparta-
do 4.9 para conocer otros estilos de descripción de diagramas de estados. El si-
guiente listado contiene los dos procesos mencionados.
library IEEE;
architecture Funcional of UControl 18
type tEstados is (Buscalnstruccion, CalculaDíteccion, CargaDato,

AlrnacenaDatO',C8rgaDíreccíon, LeeOperando,
Ejecuta,SolicitaBus);
constant ContProg : stq_logic := '0.';
constant RegIJ.I stq_logic := '1';
constant Rd stq_logic_ vector (1 downto 0.) : = "0.0.";
constant Rf1_Rx stq_logíc.;..vector(ldownto 0.) := "0.1";
constant Rf2 std_logic_vector(l downto 0.) := "10.";
signal Estado, Si-guienteEstado : tEstados; = Solicita Bus;:
begin
Combinacional: process(Estado,BusLibre, Salto, Codigaop)

begin
-_ valor por defecto de las señales de control

PeticionBus <= '0.';
CargaRIJ.I <;= ' 0.' ;
CargaCP <= '0.';
CargaRI . 'd: "j o. , :
IncCP <= '0.';
Opera <= '0.';
SelCampo <= Rd;
EscribeRegistro <=' 0.' ;
FuenteDireccion <= ContProg;
~j.litaDireccion <= 'O' ;

HabilitaMem <= 'O'r
Escribe <~ 'Z';
-- Asignación de salida~ y cálculo del sigúü!l'l.te

estado
case Estado ls
when SolicitaBus =>

PeticionBus <= '1';
lf (BusLibre,= '1') then
Siguient:~tado <= Busca.Instruccioo;
end if;
when Buscalnstruccion =>

IncCP <= '1';
CargaRI <= ' i';
HabilitaDireccion d '1"'t
HabilitaMem <= '1';
Escribe <= '(t' ;
PeticionBus <= '1';
if CodigoOp (1) , O' then
SiguienteEstado <= CalculaDireccion;
else
lf CodigoOp(O) = 'O' then
lf Salto = '1' then
SiguienteEstado <= CargaDireccion¡
end if;
else
SiguienteEstado <= LeeOperando;
end lf;
end if;
when CalculaDireccian =>

CargaRIM <=' l' ;
PeticionBus <= '1';
Escribe <= 'Z';
lf CodigoOp(O) = '0' then
SiguienteEstado <= CargaDato;
else
SiguienteEstado <= AlmacenaDato;
end lf;
when LeeOperando =>

CargaA <= '1';
SelCampo <= Rfl_Ri;
SiguienteEstado <= Ejecuta;
when CargaDireccion =>

CargaCP <= '1';
SiguienteEstado <= SolicitaBus;
when carganat;p :;:>

FuenteDirecciQn s=. ~~;
EscribeRegistro· <,;",1 t ;
HabilitaDireccian<d: '1';
HabilitaMem •',;<;; '1';
CargaN <= '1' i
CargaC <'" '1';
SiguienteEstad,o ..
<= SolicitaBus;
when AlínacénaDato =>

FuenteDireccion <= RegIJM;
Escribe <:;: , 1'.•
.HabilitaMan <= '1';
SigUiénteEsta<lÓ.<= .$91~citaBus;
when Ejecuta =>

SelCampo <= Rf2; .
EscribeRegistro <= '1';
CargaN <= '1';
CargaC <= '1';
Opera· <",' ,.;t,;
SiguienteEstado:<= SOUcitaBus;
"
when others =>
SiguienteEstado <= So~git~;
end case;
end process Combinacional;
Secuencial: process(Reloj,Inicializa)
begin
if (Iniciali~ = '1') then
Estado <= SolicitaBus;
e1sif (Reloj'event and Reloj '1') then
Estado <=·SiguienteEstado;
end if;
end process Secuencial;
end Funcional;
LISTADO 5-39. Máquina de estados de la Unidad de Control.
Puede observarse cómo el proceso Secuencial tiene la estructura de un proce-

so secuencial típico. Si la señal Inicializa se activa de forma asíncrona, se colo-
cará la máquina en el estado inicial, exactamente igual que si se tratara de la señal
Inicializa asíncrona de unflip-flop. Durante el funcionamiento normal, el proce-
so será sensible al flanco de subida del reloj, de manera que cada vez que tenga lu-
gar se asignaré como nuevo estado el siguiente, calculado a partir del estado actual
y las entradas a la máquina de estados.
El proceso Combinacional básicamente consiste en una sentencia case, con

una entrada para cada posible estado de la máquina de control. Para cada estado se
especificará cuáles son sus salidas asociadas y se calculará el siguiente, comproban-
do para ello el estado de los bits del código de operación y la condición de salto, en
función de la instrucción de que se trate. Una buena práctica para evitar omisiones
que provoquen un funcionamiento no deseado del circuito consiste en inicializar to-
das las señales de control antes de entrar a la sentencia case, que evaluará el estado
y asignará valores sólo a aquellas señales que intervengan en la operación a realizar.
5.5.4.2.3. Implementación microprogramada

de la Unidad de Control
La microprogramación es una alternativa mucho más extendida frente al uso de uni-
dades de control cableadas. Un microprograma (también denominado firmware), al
igual que un programa, no es más que la implementación de un algoritmo mediante
un conjunto de microinstrucciones. Estas microinstrucciones no son otra cosa que la
agrupación de una serie de microoperaciones que pueden realizarse simultáneamente.
Una de las principales ventajas de este tipo de implementación se debe a la fle-
xibilidad del esquema, puesto que modificar el comportamiento de la unidad es tan
sencillo como cambiar el microprograma que se almacena en la memoria de control.
Aunque existen muchas alternativas a la hora de definir el formato de una mi-
croinstrucción, en nuestro caso, y puesto que no es el objetivo de este texto profun-
dizar en este tema, se ha optado por el más claro y sencillo, el formato horizontal.
Pero antes de describir este formato, y para facilitar su comprensión, veamos cuál
es la arquitectura típica de una Unidad de Control microprogramada.
Como se aprecia en la Figura 5-21, existen varios bloques bien diferenciados
en una Unidad de Control microprogramada. En primer lugar, es necesario disponer
de una memoria de control, en la que se almacenará el conjunto de microinstruccio-
nes que componen los microprogramas del procesador (la Máquina Rudimentaria,
en este caso). Modificar el microprograma correspondiente a cada instrucción es tan
sencillo como reprogramar dicha memoria de control.
Para que la ejecución de una microinstrucción pueda realizarse de forma simul-
tánea a la búsqueda de la siguiente en la memoria de control, será necesario dispo-
ner de un registro (RMIC) que la almacene hasta el siguiente ciclo de reloj. Como
puede deducirse por esto último, se ejecutará una microinstrucción por ciclo.
El resto de los bloques de la unidad están dedicados al control del secuenciamien-
to de los microprogramas. Así, a partir de la propia información proporcionada por la
microinstrucción, y la información de estado de la unidad de proceso, el secuenciador
será el encargado de enviar a la memoria de control la dirección de la siguiente mi-
croinstrucción a ejecutar. Esta dirección puede venir del contador de microprogramas
(CMP) en el caso de la ejecución en secuencia, de un campo de la microinstrucción, si
se trata de una microinstrucción de cambio de secuencia, o del registro de instrucción.
En este último caso se utiliza el código de operación directamente como dirección, de
manera que cuando se ejecuta una nueva instrucción se accede a la posición de su
código de operación, donde se hallará una microinstrucción de salto al lugar de la
memoria donde realmente se encuentra su microprogama asociado.
'O' CargaCMP
Salto
CodigoOp'
'1 '
Memoda de
Control
FIGURA 5-21. Diagrama de estados de la Unidad de Control.
Como se puede apreciar en la Figura 5-19, cada microinstrucción constará de

varios campos que podemos clasificar en dos grupos:
• De secuenciamiento: que decidirán la siguiente microinstrucción a ejecutar
(SelSigDireccion, SelCondicion, SigDireccion).
• Microórdenes: que activarán las señales de control.
Este tipo de formato se denomina horizontal, puesto que existe un bit de la mi-
croinstrucción para cada señal de control, pudiendo simultanear la ejecución de to-
das ellas. En el caso de la Máquina Rudimentaria el formato final de una microins-
trucción será el de la Figura 5-22.
Una vez conocido el formato de la microinstrucción, y a partir de la Tabla 5-8,
que contiene la codificación de las señales de control en función de los diferentes
estados, pasemos a desarrollar el microprograma equivalente (Figura 5-23).
Las cuatro primeras posiciones del microprograma contienen un salto a la di-
rección de comienzo de cada una de las cuatro microinstrucciones. De esta manera,
cada vez que se quiera ejecutar una nueva instrucción, tan sólo hay que indicarle al
secuenciador que seleccione el salto a la dirección indicada por el código de opera-
ción, para que desde ésta salte a la zona correspondiente. Para el resto de los cuatro
fragmentos de código simplemente se ha traducido cada estado de la máquina de
control de la Figura 5-20 en una microinstrucción.
22 21 20 19 15 14 o
SelSigDireccion SelCondícion SigDíreccíon Microordenes
Microórdenes SelSigDireccion
Bit 14: CargaRDM Bit 7 : Opera 0-> SALTAR

Bit 13: CargaCP Bit 6 : EscribeRegistro '1-> CODIGO_OP
Bit 12: CargaRI Bit 5-4: SelCampo
Bit 11: CargaA Bit 3 : FuenteDirección SelCondicion
Bit 10: IncCP Bit 2 : HabilitaDireccíón
Bit 9: CargaN Bit 1 : HabilitaDatos 00 -> 'O'
Bit 8: CargaC Bit O : HabilitaMem 01 -> Salto
Bit 7: Opera 10 -> BusLibre
11 -> '1'
FIGURA 5-22. Formato de microinstrucción de la Máquina Rudimentaria.
Dirección Microinstrucción
00000 O 11 00100 000000000000000

00001 O 11 01000 000000000000000 Decodificación del campo CodigoOp.
00010 O 11 01100 000000000000000 Salto a la instrucción correspondiente
00011 O 11 10001 000000000000000
00100 O 10 00101 000000000000001

00101 O 00 00000 000001100000101
Instrucción de carga
00110 O 00 10000 000010000000001
00111 1 00 00000 000000010000101
01000 O 10 01001 000000000000001

01001 O 00 00000 000001100000101 Instrucción de almacenamiento
01010 O 00 00000 000010000000001
01011 1 00 00000 000000000001111
01100 O 10 01101 000000000000001

01101 O 00 00000 000001100000101
01110 O 01 10000 000000000000001 Instrucción de salto
01111 1 00 00000 000000000000000
10000 1 00 00000 001000000000000
10001 O 10 10011 000000000000001

10010 O 00 00000 000001100000101 Instrucción de operación
10011 O 00 00000 100010000100000 aritmético-lógica
10100 1 00 00000 010100011000000
FIGURA 5-23. Microprograma de la Unidad de Control.

El modelo completo de la Unidad de Control microprogramada es el que se

muestra en el Listado 5-40. Observe cómo el componente ROM acepta como gené-
ricos no sólo el número de bits de datos y direcciones, sino también el contenido de
la memoria. En este ejemplo dicho contenido será nuestro microprograma de con-
trol, que encontrará almacenado en la constante Microprograma.
library IEEE;
use IEEE.STD_LOGIC_1164.a11;
use IEEE. STD_LOGIC_ARITH .all ;
architecture Estructural of UControl is
constant Microprograma : tContROM := (

'01100100000000000000000', -- 00000 Salto al microprograma CARGAR
'01101000000000000000000·, -- 00001 Salto al microprograma ALMACENAR
·01101100000000000000000', -- 00010 salto al microprograma SALTAR
·01110001000000000000000', -- 00011 Salto al microprograma OPERAR
-- Instrucción CARGAR
·01000101000000000000001', -- 00100 Si BusLibre salta a 00101
·00060060000001100000101·, -- 00101 Busca instrucción
·00000000000010000000001', -- 00110 Calcula dirección
·100000000000000100oo10i·, -- 00111 Carga dato
-- Instrucción ALMACENAR
·010'01001000000000000001· , -- 01000 Si BusLibre salta a 01001
'09000000000001100000101', -- 01001 Busca instrucción
'00000000000010000000001·, -- 01010 Calcula dirección
'10000000000000000001111', -- 01011 Almacena dato
-- Instrucción SALm
·01001101000000000000001', -- 01100 Si BusLibre salta a. 01101
'00000000000001100000101', -'-01101 Busca instrucción
'00110000000000000000001·, -- 01110 Evalúa la condición de salto
·10000000000000000000000·, -- 01111 Condición falsa
'10000000001000000000000' , -- 10000 Carga dirección si se da la condición
\-¡
-- Instrucción OPERAR
'01010011000000000000001' , ,..,.:
lilQP1.Si BusLibre salt.a a 10011
'00000000000001100000101',· ~..1001.{)Busca instrucción
'00000000100000000100000', -- 10011. Lee operando
'10000000010100011010000~, -- 10100 Ejecuta operación
others => ·00000000000000000000000');
constant SALTAR 8t~logic .- '0';

constant CODIGO_OP st~logic .- '1';
signal DirSigMicroinSt 8t~logic_vector~cBitsDirROM-l downto O);

signal Microinstruccion stQ_logic_vector{cBitsDatoROM-l downto O);
signal unUno stQ_logic := '1';
-- Registroscde la unidad de €ontrol

signal RMic : stcLlwic_vector(cBj,tsDatoROM-l downto O);
signal CMP :cstcLlogic_vector(cBitsDirROM-1 downto O) i
-- Campos de sectIenciamiento de la microinstrucci6n

alias SelSigDireccion stcLlogic is RMic(22);
alias SelCondicion std_logic_vector(l daNnto O) is RMic(21 downto 20);
alias SigDireccion std_logic_vector(cBitsDirROM-1 downto O)
la RMic(19 downto 151;
component ROM
generie (
BitsDireccion natural;
BitsDato natural;
Contenido tContROM) ;
port(
Habilita in stcLlogic;
Direccion in stcLlogic_vector(BitsDireccion-1 downto O);
Dato out stcLlogic_vector(Bitstlato-1 downto O));
end eaoponent;
begin
ROM_VC: ROM
generie map (
BitsDireccion =>'cBitsDirROM,
BitsDato => cBitsDatoROM,
Contenido => Microprograma)
port map(
Habilita => UnUno,
Direccign => DirSigMicroinst,
Dato c. =:>Microinstruccion)
e i
RegistroRMIC: proceas(Inicializa,Reloj)
begin
RMic <= (others => 'O');
elee
RMic <= Microinstruccion;
end if;
end process RegistroRMic;
ContadorMP: process
subtype tContador is integer ranga O te 2**cBitSDirROM;
constant Tope: integer:= 2**cBitsDirROM;
variable Valor : tContador;
begin
wait until Inicializa = '1';
loop
Valor := O;
end lf;
wait until (Reloj'event and Reloj '1') or (Inicializa = '1');
next when Inicializa = '1':
case Valor ia
when Tope => Valor := O;
when others => Valor := conv_integer(unsignect(DirSigMicroinst)) + ~¡

end case;
end loop;
CMP <= conv_std_logic~vector (Valor ,cBitsDirRCM) ¡
end process ContadorMP¡
-- Secuenciador
Secuenciador: process
begin
case SelSigDireccion ls
when SALTAR',,>
case SelCondicion ls
wben "OO' =>
DirSigMicroinst <= CMP;
wben ·01" =>
lf (salto'= 'r') then
DirSigMicroinst <= SigDireccion¡
else
DirSigMicroinst <= CMP;
end if¡
wben "la" =>
if (BusLibre' = '1') then
DirSigMlcr61nst <= SigDÍreccion¡
else
DirSigMicroinst <= CMP¡
end if¡
wben "11" =>
DirSígMicroinst <= SigDireccion;
when others =>
DírSigMicroinst <= (others => 'X')¡
end case¡
when CODlGO_OP =>
DírSígMicroinst <= "000" & CodigoOp;
when others => "
DirSigMicroinst <= (others => 'X')¡
end case;
end process Secuenciador;
CargaRrM <= RMic{14)¡

CargaCP -ce .~c(13) ¡
Cargélll.I <= RMic (12) ¡
CargaA. <= RMic (11)¡
IncCP .'<= 'RMic (lar:
cargaN <= RKlc <n ;
CargaC <= rutic(8)¡
Opera <= RMic(7) ¡
EscribeRegistro <= OOc(6)¡
selCaI!IlO <= OOc(5 downto 4);
FuenteDireccion <= RMic (3);
HabilitaDireccion <= OOc(2);
HabilitaDatos .<= RMic (¡¡ ;,
HabílitaMem .<= ~k(O)<
end estructural¡
LISTADO 5-40. Unidad de Control microprogramada.

5.5.4.3. La memoria de programas
Para completar nuestro sistema será necesario disponer también un modelo para la
memoria de programas. Sin embargo, puesto que las memorias son un componente
habitual de todo tipo de sistemas electrónicos, realizaremos un esfuerzo extra en
dos direcciones:
• Por un lado, se tratará de que el modelo sea suficientemente general como
para que pueda ser aprovechado sin mayor esfuerzo en otra situación. Para
ello se pasará como parámetros al modelo toda aquella información que pro-
porcione esta generalidad: espacio de direccionamiento, ancho de la palabra
a almacenar, valores temporales, etc.
• Por otro lado, se intentará reflejar con la máxima fidelidad su comportamien-
to real, para lo cual nos basaremos en una hoja de datos de una memoria
RAM típica.
El objeto de este modelo no será el de la fabricación de esta memoria tras una
serie de etapas de refinamiento, puesto que dispositivos generalmente se adquieren
de uno de los múltiples proveedores. Sin embargo, será necesario para poder rea-
lizar una simulación realista del entorno en el que estará integrado nuestro disposi-
tivo (la Máquina Rudimentaria en nuestro caso). Por estas razones, el modelado de
este tipo de componentes estará únicamente enfocado a poder realizar una simula-
ción eficiente.
5.5.4.3.1. Descripción del funcionamiento
En nuestro caso supondremos que existe en el mercado un componente estándar

que se ajusta a nuestras necesidades y cuyas características están descritas en la Fi-
gura 5-24.
En el caso de un acceso para lectura, una vez colocada la dirección correspon-
diente en el bus de direcciones se activará la señal de habilitación de memoria (Ha-
bili taMem),para obtener el resultado sobre el bus de datos.
La escritura funciona de manera similar, pero en este caso antes de colocar la
dirección deberá indicarse que la operación es de escritura (activando a la baja
la señal Escribe). El dato a escribir será el que se encuentre en ese momento en el
bus de datos.
5.5.4.3.2. Definición de la entidad
Puesto que la memoria es un componente que probablemente tendremos oportuni-

dad de utilizar en otra ocasión, podría merecer la pena crear un modelo suficiente-
mente flexible y general como para permitir reutilizar su código (una de las princi-
pales ventajas del modelado VHDL). En tal caso declararemos como valores gené-
ricos no sólo el número de palabras de la memoria, y la anchura en bits de tales pa-
labras, sino también todos los parámetros temporales.
Dir Dirección válida Dirección válida
TEs~blOir TMantOir TEst~blOir TMantDir
HabilitaMem I~---T-P-UJ-S-OL---* TPrecarga

~---T-P-U-'S-O-E--L_
TEstablL! rMantL TEstablE: fMantE
Escribe _y-' l' ir

TAcceso TEstablOato irMantOato
-----V-::-~~ '-----t;=======:::'--~ j
Dato Dato válido
FIGURA 5-24. Cronograma de la memoria RAM.
library IEEE;
entity RAM is
generic (
Palabras integer .- 8; -- Número de palabras
BitsDir integer .- 3; Número de líneas de dirección
BitsPalabra integer .- 8; -- Número de bits por palabra
Fichero string .- "ram.txt"; -- Contenido de la memoria
TEstablDir: time .- O ns; Establecimiento de la dirección
TMantDir: time .- O ns; Mantenimiento de la dirección
TPulsoL: time .- O ns; Pulso mínimo de lectura
TPrecarga: time .- O ns¡ Precarga mínima de la memoria
TPulsoE: time .- O ns; Pulso mínimo de escritura
TEstablL: time .- O ns: Establecimiento de la señal de lectura
TMantL: time .- O ns : -- Mantenimiento de la señal de lectura
TEstablE: time .- O ns; -- Establecimiento de la señal de escritura
TMantE: time .- O ns: -- Mantenimiento de la señal de escritura
TAcceso: time .- O ns; -- Acceso para lectura
TDatoValido: time .- O ns; -- Dato válido
TEstablDato: time .- O ns; -- Establecimiento para escritura
TMantDato: time .- O ns); -- Mantenimiento después de escritura
port(
HabilitaMem in std_logic;
Escribe in std_logic;
Direccion in std_logic_vector(BitsDir - 1 downto O);
Dato inout std_logic_vector(BitsPalabra - 1 downto O)) ;
end RAM;
LISTADO 5-41. Entidad de la memoria RAM.

Como puede observarse en la declaración de la entidad de la memoria RAM,

existe un genérico adicional (Fichero) que tiene además un valor por defecto. La
finalidad de este parámetro es la de poder indicarle al modelo el nombre del fichero
de texto que contendrá el estado inicial de la memoria y que por defecto será siem-
pre ramo txt.
5.5.4.3.3. Modelo funcional de la memoria

La manera más sencilla y más eficiente de modelar el estado interno de una memo-
ria es la de guardar su contenido en una variable de valores naturales (Listado 5-42),
puesto que es la forma más rápida y compacta de almacenar la información. Por su-
puesto, esta aproximación será adecuada en el caso de que sean de pequeño tamaño,
pues de lo contrario la variable ocupará una cantidad de memoria considerable.
type tMemoria is array(natural range o to Words-l) of natural;
Para el modelado del comportamiento de la memoria utilizaremos un único
proceso (Listado 5-42), en el que como se puede ver se han definido dos procedi-
mientos: Inicializa y CargaFichero.Éstos únicamente se ejecutan una vez, al
comienzo de la simulación (cuando la variable Inicializacion toma el valor
TRUE) y se encargan, respectivamente, de colocar toda la memoria a O y leer el
contenido de algunas posiciones de un fichero de texto. Este último es el método
más habitual para colocar la memoria en su estado inicial.
Memoria:process(Escribe,HabilitaMem,Dato)
variable Memoria: tMemoria;

variable Inicializacion: boolean := true;
variable i: natural¡
procedure Inicializa (Memoria: inout tMemoria) is
begin
for i in O to Palabras-l loop
Memoria(i) := O;
end loop;
end Inicializa;
procedure LeeHexadecimal(Fichero: in string; variable Linea: inout line;

Cifras: in natural; variable Valor:
iDout integer) is
variable Caracter character;
begin
Valor := O;
for i in 1 to Cifras loop
read(Linea,Caracter);
if (Caracter >= 'O' and Caracter <= '9') then
Valor := Valór * 16' + character'pos(Caracter) -
character'pos('O');
eleif (Caracter >= 'A' and Character <;::: 'F') then

Valor := Valor • 16 + character'pos (Caracter) -
character'pos('A') + 10;
eleif (Caracter >= ' a ' and CharaC,ter <= 'f') then
Valor := Valor • 16 + character'pos(Caracter) -
character'pos('a') + 10;
else
assert false
report "Error de sintaxí.s en el fichero: " &Fichero
severity error;
end if;
end loop;
end LeeHexadecimal;
procedure CargaFiChero(Memoria: inout tMemoria; NambreFichero: in string) is

file F text ie in Fichero;
variable Linea Une;
variable iDireccion ihteg~r¡
variable Caracter character;
begin
While not endfileIF) loop
iDireccion := 'Ó;
reádl ine W, Linear;
LeeHexadecimaltrich~io, Linea, 2, iDiteccioÍl);
read(Linea,Caracter);
if (Caracter'!:i" ') then
aeeert false
report "Error de sintaxis en el,fichero: • & Fichero
severity failure;
end if;
LeeHexadecimal(Fichero,Linea,4,Memoria(iDireccion»;
end loop,
end CargaFichero; .
begin
if Inicializacion then
Inlcializa(Memoria) ;
CargaFichero(Memoria,Fichero);
Inicializacion := FALSE;
Dato <= (othere => 'Z'),
end if;
if HabilitaMem'event tben
if HabilitaMem = '1' and Escribe = '1' tben
Dato <= conv_std_logic_vector(.Memoria(conv_integer
(unsigned(Direccion)))) BitsPalabra) after TAcceso;
eleif HabilitaMem = 'O' or HabilitaMem = ~Z' then
if Escribe = '1' or Escribe = 'Z' then i
Dato <= (othere => 'Z') after TDatoValido;
elee
Memoria (conv_integer (unsigned(Direccional) » f:
cOIlV_integer(unsigned(Dato» ¡
endif;
endif¡
endif;
end process Memoria¡
LISTADO 5-42. Modelo detallado de la memoria RAM.
Durante el funcionamiento normal de la memoria, el proceso se activará úni-

camente cuando se detecte un evento en la señal Habili taMem. En ese caso, de-
pendiendo del valor de la señal Escribe, se efectuará la operación de lectura o
escritura sobre la variable que modela la memoria (Memoria), siempre que la se-
ñal Habili taMem esté activa.
5.5.4.3.4. Verificación temporal

Una de las maneras más utilizadas para modelar la verificación temporal consiste
en definir un conjunto de procedimientos concurrentes, que supervisan la sincroni-
zación entre las diferentes señales, sin afectar por ello a su funcionamiento. Sin em-
bargo, esta técnica puede resultar costosa en tiempo de simulación, puesto que el
rendimiento disminuye conforme aumenta el número de procesos que pueden eje-
cutarse concurrentemente.
Para facilitar la reutilización de estos procedimientos en otros modelos los
agruparemos en un nuevo paquete (VerificacionTerr¡poral). En el paquete se han
incluido los procedimientos necesarios para verificar:
• el tiempo de establecimiento de una señal respecto a otra (VEstablecinúento)
• el tiempo de mantenimiento de una señal respecto a otra (1I2I1anteninúento)
• las anchuras mínimas de los pulsos de un ciclo (vCiclo).
El siguiente listado muestra solamente el código correspondiente a la primera
función, puesto que las demás son muy similares.
procedure VEstablecimiento(
signal Senyal: in std_logfC ¡
constant NombreSenyal: in string¡
signal SenyalRef: in stCl_logic¡
constant NombreSenyalRef: in string¡
constant Condí.cí.om' in boolean;
constant TiempoEstabl: in time) 18
begin
if SenyalRef'event and Condicion then
assert ((now - Senyal'last_event) >= TiempoEstabl)
report 'Violacion de setuP en • & Nambre6enyal &
"respecto a' & NombreSenyalRef
severity warning;
end if;
end VEstablecimiento;
LISTADO 5-43. Función de verificación del tiempo de establecimiento.
Utilizando las funciones de este paquete, la verificación temporal de nuestra

memoria RAM se realizará mediante los cuatro procesos siguientes:
VCiclos: process(HabilitaMem)
begin
if HabilitaMem'event then
if HabilitaMem " '1' then
VCiclo(HabilitaMem, "HabilitaMem",TPrecarga,O ns);
else '
if (Escribe =
'1') then
VCiclo(HabilitaMem, "HabilitaMem' ,O ns, TPulsoLl ;
elee
VCiclo(HabilitaMem, "HabilitaMem', O ns, TPulsoE);
end if;
end if;
end if;
end process vci~lºs_¡
- Establecimiento y mantenimiento para las direcciones ~L/E)

VDir: process (HabilitaMem, Direccion)
begin
-- Establecimiento
if Direccion' event then
VMantenimiento (Dir~ion, "Direccion' ,liabilitaMern, "liabili taMell\' ,
,' Dí.recci.on
:~.:~p-. j _
..; : '.
' stable, .'IMantDir)-_i
end if;
-_ Mantenimiento
if HabilitaMem'event aIId HabilitaMem = '1' then
~tablecimiento (Direccion, •Direccion • ,HabilitaMem, "HabilitaMem' ,
, D~r~ccion'stal:>le,TEstablDir); .
end if;
end process VDir;
Establecimiento y mmtenimiento para los' datos (E)'

VDatos: proceSS(HabilitaMem,Es~ribe,Dato)
begin
-- MaIÍtenWento
if Dato' eVent aIId sscríbe« 'O' then
VManteniinierito (Dato, "Dato' ,iIabilitaMem, "HabilitaMem' ,Dato' stable,
TM.!lntDatoJ;
end if;
-- Establecimiento
if HabilitaMem'event and Escribe = 'O' then
VEstablecimientoWato, "Dato" ,HabilitaMem, "HabilitaMem",Dato'stable,
TEstablDato) ;
end if;
end process VDatoS,
-- Establecimiento de l~ señal escri~

VEscribe: process (HabilitaMem, EscribE!)
begin
if HabilitaMem'event and HabilitaMem =
'1' then
if EScribe = '1' then
VEstablecimiento(Escribe,"Escribe·,HabilitaMem,"HaQilitaMem",
Escribe'stable,TEstablL);
else
VEstablecimiento(Escribe, "Escribe" , HabilitaMem, "HabilitaMem',
Escribe'stable,TMantDit~;
end if;
end 1f;
if Escribe'event and Escribe =
'0' then
VEstablecimiento (Escribe, ·Escrtbe.", ~ilitaMem, 'HabilitaMem',
. Escri~;stable>Í'EstablE);
end if;
end process VEscribe;
LISTADO 5-44. Modelado de la verificación temporal en la memoria RAM.
5.6. EJERCICIOS
1. En la descripción funcional del procesador no se incluye ninguna información

acerca del tiempo que tarda cada instrucción en ejecutarse. Sin embargo, a
pesar de que no existe una señal de reloj respecto a la cual definir ciclos, podría
almacenarse un hipotético. número de ciclos relacionado con cada código de
operación y, suponiendo un tiempo arbitrario para la duración de un ciclo,
reflejar esta información en el tiempo de espera entre la ejecución de dos ins-
trucciones. Modifique los tipos de datos existentes y añada los necesarios para
poder almacenar la información relativa a los ciclos de cada código de opera-
ción. Posteriormente añada las variables y realice las modificaciones necesarias
en el código para reflejar esta información en la simulación.
2. La descripción funcional del procesador podría haberse realizado suponiendo

que el número de bits de los registros y los datos son conocidos en lugar de uti-
lizar el tipo integer. Añada dicha información en forma de constante en el pa-
quete PaqueteMRFuncional y modifique los tipos de datos que puedan hacer
uso de ella. Modifique la arquitectura del procesador de acuerdo con los nuevos
tipos de datos.
3. El hecho de almacenar el programa y los datos en una variable en la descrip-

ción funcional del procesador nos obliga a reanalizar la arquitectura cada vez
que queremos simular la ejecución de un programa distinto. Esto podría evitar-
se si en la etapa de inicialización de las variables al principio del cuerpo del
proceso se leyera el contenido de las variables Programa y MemDatosde un
fichero. Escriba los procedimientos necesarios para que esto sea posible y utilí-
celos en el cuerpo del proceso para inicializar las variables.
4. Como hemos visto, la arquitectura PrimeraParticion del procesador no mo-

delaba con precisión los cambios en la señal Inicializa que entra al procesa-
dor. Incluya las sentencias de control necesarias para que los procesos respon-
dan a una activación de esta señal en cualquier momento y en no más de un
ciclo de reloj se abandone la ejecución de instrucciones y las variables y seña-
les tomen su valor inicial.
5. La arquitectura Funcional del banco de pruebas en el Listado 5-20 concede de

forma inmediata el bus de memoria al procesador siempre que éste lo solicita
de forma que no se verifica el caso en que el procesador deba esperar varios
ciclos antes de realizar una lectura o escritura. Para hacer un poco más exhaus-
tiva la verificación, modifique el proceso Arbi troBus de dicha arquitectura
para que exista un tiempo de espera entre la petición de bus por parte del proce-
sador y la activación de la señal BusLibre. Además, haga que este tiempo de
espera varíe de un ciclo a otro.
6. Las funciones del procesador que se repiten cíclicamente, como los accesos al
bus de memoria, tienen una relación causa-efecto y un orden en la activación
de las señales que deben cumplirse para todos los ciclos. En estos casos es fácil
escribir un proceso en el banco de pruebas que verifique estas propiedades.
Escriba un proceso pasivo, es decir, que no asigne ninguna señal sino que sólo
las lea, que compruebe los accesos a memoria del procesador.
7. Escriba un proceso similar al del ejercicio anterior pero que verifique que des-
pués de una instrucción de LOAD se realiza una lectura a memoria y que
después de una instrucción de STORE se realiza una escritura. Para ello será
necesario que el proceso observe las instrucciones que pasan por el bus de
datos hacia el procesador y pueda distinguir el tipo de instrucción.
8. Una vez hemos realizado la comprobación de la simulación de forma visual,

podríamos preparar un esquema de comprobación automática para que cuan-
do se realicen modificaciones en el modelo del procesador poder ver que
sigue comportándose de igual forma. Escriba un proceso en el banco de prue-
bas que a cada ciclo de reloj escriba los estímulos que se aplican a las entra-
das del procesador y los valores a las salidas correspondientes a los estímulos
aplicados en el ciclo anterior. Posteriormente podremos verificar la descrip-
ción comparando el fichero de la nueva simulación con el de la simulación ya
verificada.
9. Integre la funcionalidad de los componentes sumador y restador del modelo es-

tructural de la UAL en uno sólo. Sintetice ambas versiones de la unidad opera-
tiva y compare los resultados en términos de área y velocidad de ambas imple-
mentaciones.
10. Sustituya el componente ROM de la implementación cableada de la unidad

de control por una PLA. Para ello obtenga, a partir del diagrama de estados de
dicha unidad, y la Tabla 5-8, las ecuaciones combinacionales correspondientes,
desarrolladas en forma de suma de productos.
11. Modifique el modelo funcional de la memoria RAM de programas, de manera

que, a través del valor de un parámetro adicional, pueda desactivarse la verifi-
cación temporal.
12. Utilice un solo proceso para modelar la memoria RAM de programas, en el que
se incluya tanto la funcionalidad como la verificación temporal. Simule el siste-
ma y compruebe cómo la reducción del número de procesos mejora el rendi-
miento.
5.7. BIBLIOGRAFíA
[AG93] J. R. ARMSTRONGy F. GAIL GRAY: Structured Design with VHDL, Prentice-Hall,

1997.
[AB09O] R. AlRIAU, J. M. BERGÉ,V. OLNE y J. ROUll..LARD:VHDL du langage a la modéli-
sation, Presses polytechniques et universitaires romandes, 1990.
[Ash96] P. ASHENDEN.The Designers Cuide to VHDL, Morgan Kaufmann Publishers, 1996.
[Co93] D. R. COELHO:The VHDL Handbook, K1uwer Academic Publishers, 1993.
[Hay88] J. P. HAYES: Computer Architecture and Organization, McGraw-Hill, 1988.
[STA97] W. STALUNGS:Organización y Arquitectura de Computadores. Diseño para Opti-
mizar Prestaciones, Prentice-Hall, 1997.
[SPC97] F. SÁNcHEZ, E. PASTORY A. M. DELCORRAL(Ed: R. Hermida): Fundamentos de
Computadores (Capítulos 6 y 7 del libro), Síntesis, 1997.
6
Capítulo
LA GESTION
-
DEL DISENO
Y. Torroja, T. Riesgo, E. de la Torre, J. Uceda
Un error conocido
es una victoria ganada.
Anónimo
En los capítulos precedentes se ha mostrado cómo utilizar el VHDL y la

síntesis automática para diseñar un circuito. Hasta el momento, el en-
foque ha sido fundamentalmente técnico. Se han visto los diferentes
elementos del lenguaje VHDL, distintas maneras de describir el funcio-
namiento de un circuito, cómo realizar bancos de prueba, etc. Sin em-
bargo, el proceso de diseño en VHDL requiere un estudio no sólo de
los aspectos técnicos del diseño, sino también de los organizativos.
A menudo el diseñador encuentra que tiene que realizar un buen
número de tareas adicionales a lo que es la mera descripción del cir-
cuito en VHDL. Al enfrentarse a un diseño real, debe resolver proble-
mas relacionados con la planificación del trabajo, la documentación
del diseño, las herramientas que está utilizando, la organización de los
archivos, su relación con el posible cliente, etc.
En el presente capítulo se pretende dar una visión general de cuáles
son estas tareas y qué problemas conllevan. Se presenta el proceso de
diseño de un circuito, desde su concepción hasta su fabricación, mos-
trando cómo obtener el mejor partido de la utilización del VHDL en este
proceso. El objetivo del capítulo es concienciar al lector de que el dise-
ño de un circuito en VHOL no consiste sólo en escribir código, sino que
existen otros muchos aspectos a tener en cuenta, y que sólo una buena
organización del diseño puede garantizar el éxito final del mismo.
349
6. 1. INTRODUCCIÓN
Hasta la aparición de los lenguajes de descripción del hardware y, especialmente,

de las herramientas de síntesis lógica, el proceso de diseño de circuitos integrados
estaba basado fundamentalmente en la utilización de esquemáticos. Las he-
rramientas de diseño disponían (y siguen disponiendo) de potentes editores grá-
ficos con los que realizar un esquema del circuito, bien fuese mediante bloques o
mediante puertas.
El diseño de un circuito con estas herramientas consistía principalmente en un
proceso de diseño ascendente (bottom-up). En este procedimiento, el diseñador de-
bía hacer sobre el papel una partición del circuito en bloques o unidades funciona-
les basándose en su experiencia previa. Cada uno de estos bloques era a su vez divi-
dido en unidades más pequeñas hasta alcanzar una complejidad manejable para rea-
lizar su representación en un esquema.
Así, por ejemplo, un circuito de transmisión/recepción serie podía ser dividido
en el transmisor, el receptor y un bloque de control. Definidas las señales de control
y los datos que habrían de comunicarse entre estos bloques, cada uno de ellos se di-
vidiría en subbloques más pequeños. El transmisor, por ejemplo, podría quedar di-
vidido en un generador del reloj de transmisión, una unidad de control con algunos
registros programables para configurar el modo de transmisión, un bloque de inter-
faz con el exterior con algún registro temporal para el dato a transmitir y un último
bloque que se encargaría de formatear el dato y de hacer la conversión paralelo/se-
rie para su transmisión.
Realizada esta partición comenzaría el diseño de detalle de cada uno de estos
bloques. Mediante un editor de esquemáticos el diseñador iría dibujando el esque-
ma lógico de los bloques, dibujando puertas e interconectándolas y apoyándose se-
guramente en pequeños bloques funcionales previamente diseñados (registros para-
lelos, registros serie, biestables con habilitación, etc.).
Una vez diseñado un bloque, éste podría ser simulado. El diseñador debía en-
tonces utilizar un lenguaje o herramienta específica del entorno de diseño para de-
finir los estímulos (las formas de onda) con las que comprobar el funcionamiento
del bloque recién diseñado. Comprobado este bloque se procedería al diseño de los
demás bloques con el mismo procedimiento. Una vez diseñados todos los bloques
se interconectarían entre sí para formar un bloque mayor (p. ej., el transmisor) y se
procedería a su simulación, repitiendo este proceso hasta completar el circuito
completo.
El problema fundamental de este método de diseño es que no era posible simu-
lar el comportamiento completo de cada uno de los bloques hasta no haber diseñado
los subbloques que lo integran. A menudo el diseñador encontraba que la partición
realizada, las señales de comunicación entre cada uno de los bloques, la especifica-
ción, o su propio entendimiento de lo que debía ser el funcionamiento de un bloque
no eran los adecuados. Esto podía requerir de un rediseño total o parcial de alguno
o varios de los bloques, o incluso de una nueva partición del circuito. Para resolver
estos problemas se incluían a menudo funcionalidades en los bloques que no eran
estrictamente necesarias, se repetía lógica que ya estaba en algún otro bloque. o se
realizaban complicados protocolos de comunicación entre bloques.
6. La gestión del diseño 351
Por tanto, el proceso de diseño resultaba engorroso y las modificaciones, la de-

puración y el mantenimiento del diseño complejos de realizar. Una mala planifica-
ción del diseño podría hacer, por ejemplo, que se repitiesen los bloques de genera-
ción del reloj del transmisor/receptor planteado como ejemplo. Si, por otro lado,
tras el proceso de diseño físico y obtención de la topografía (layout) se detectaban
errores debidos a retardos o problemas de área, las modificaciones resultaban com-
plejas y de difícil solución.
La aparición de los HDLs (Hardware Description Languages, o lenguajes de
descripción del hardware) y de las herramientas de síntesis lógica ha venido a paliar
en gran medida estos problemas. Por una parte, ha liberado al diseñador de la tedio-
sa, y a menudo repleta de errores, tarea de diseño lógico, que queda a cargo de las
herramientas de síntesis. Por otro lado, y éste es quizás el aspecto más importante,
permiten al diseñador utilizar un método de diseño descendente (top-down). Con
este proceso de diseño el diseñador puede simular el comportamiento del circuito
completo antes de realizar la partición y entrar en el detalle del diseño de cada uno
de los bloques. Realizando un modelo funcional sencillo de un bloque, el diseñador
puede comprobar que la integración de éste en el resto del sistema es la adecuada.
La inclusión de nuevas señales de comunicación con los demás bloques, o nueva
funcionalidad, puede realizarse de una manera mucho más sencilla y a menor coste.
El diseñador va definiendo, describiendo y, lo que es más importante, simulando el
comportamiento deseado para cada una de las partes. Posteriormente entra en el de-
talle de cómo realizar, mediante la lógica adecuada, un circuito que se comporte tal
como lo hacen los modelos que ha realizado.
Sin embargo, como veremos, los HDLs en general, y el VHDL en particular,
no son la panacea del diseño. Existe una notable diferencia entre las posibilidades
teóricas y reales que los HDLs y la síntesis automática ofrecen. El diseñador se en-
frenta a nuevos problemas debidos fundamentalmente a la integración de las nuevas
herramientas en los entornos de diseño y al aumento de la complejidad de los cir-
cuitos que estas herramientas permiten realizar.
A continuación se describen brevemente cuáles son los nuevos problemas a
los que el diseñador tiene que enfrentarse, comparando lo que sería un proceso
ideal de diseño basado en VHDL y síntesis automática y la realidad. Posteriormen-
te, el resto del capítulo estará dedicado a proponer procedimientos y métodos que
permitan paliar, en la medida de lo posible, los efectos negativos que estos proble-
mas inducen.
6.1.1. Un proceso ideal de diseño en VHDL
En un proceso de diseño ideal en VHDL el diseñador debería disponer de unas es-

pecificaciones estables. Esto evitaría modificaciones constantes en el proceso de di-
seño que aumentan en gran medida el coste del desarrollo. En el mejor de los casos,
el diseñador podría disponer de un modelo simulable en VHDL del entorno en el
que el circuito va a estar incluido. De esta manera, el diseñador siempre dispondría
de un banco de pruebas realista con el que poder simular su diseño a lo largo del
proceso de desarrollo.
Las herramientas de diseño deberían permitir al diseñador disponer de modelos

VHDL de su diseño a lo largo de todo el proceso. Por ejemplo, tras la síntesis, dis-
pondría de un modelo VHDL estructural del circuito en puertas, que le permitiría
realizar la simulación del circuito con los mismos bancos de prueba que utilizó en
las etapas previas del proceso de diseño, y considerando las características reales de
los componentes (retardos, consumo, etc.). Para ello, las bibliotecas del fabricante
dispondrían de modelos VHDL detallados de todos sus componentes.
Por otro lado, las herramientas de síntesis tendrían en cuenta la biblioteca del
fabricante para seleccionar, en cada caso, el componente más adecuado para rea-
lizar la funcionalidad especificada por el diseñador, teniendo en cuenta el coste
y las prestaciones. Las macroceldas (memorias RAM, ROM, multiplicadores,
PLAs, etc.), se generarían de forma automática cuando fuesen necesarias, y sus mo-
delos VHDL se integrarían bajo el diseño para poder simular, de forma sencilla, el
circuito completo.
Por último, si el diseñador se dedicase a las tareas de diseño físico haría la ubi-
cación y el conexionado (place & route), para obtener la topografía, tras lo cual
realizaría una simulación del circuito final, todo sin salirse del entorno VHDL al
que está acostumbrado. Las modificaciones que, por cualquier razón, el diseñador
realizase sobre el circuito final (un inversor puesto a última hora para corregir la
polaridad de una señal, una modificación de la topografía para corregir retardos, et-
cétera), quedarían retroanotadas en el diseño, de forma que su efecto se viese refle-
jado en los distintos modelos VHDL que se hubieran ido obteniendo según se fue
depurando el diseño.
6.1.2. El proceso real de diseño en VHDL
Aunque la realidad no dista mucho del esquema arriba mostrado, sí lo hace en pun-
tos de vital importancia, que suelen dar al traste con lo que sería un proceso de dise-
ño fluido y sin complicaciones.
Por un lado, las especificaciones nunca son estables. A menudo la idea del di-
seño sufre cambios a lo largo del proceso de desarrollo que obligan a rehacer parte
del diseño. Por otro, no es frecuente que el diseñador disponga de modelos simula-
bles del entorno, lo que le obliga a desarrollarlos, duplicando el trabajo y las fuentes
de errores. Además, la complejidad alcanzada en los diseños actuales hacen ne-
cesaria una importante tarea adicional de gestión global del diseño que hasta ahora
se daba en contadas ocasiones. Los equipos de diseño que es necesario coordinar
suelen ser mayores y, a menudo, formados por personas que trabajan en distintos
centros.
La misma complejidad de los circuitos obliga a hacer unos bancos de prueba
cada vez mas sofisticados. La propia validación de la funcionalidad se vuelve una
tarea compleja debido al gran número de modos de funcionamiento de los circui-
tos y de solicitaciones a los que se les somete. El tiempo de simulación se con-
vierte entonces en uno de los principales problemas para el diseñador, que tiene
que esperar a que terminen largas simulaciones para analizar los resultados. Es
frecuente, como ocurre en el caso del diseño de un microprocesador, que el mode-
lo de simulación del circuito tenga que ejecutar largos programas en un entorno vir-
tual para verificar sus respuestas ante situaciones que de otra manera serían difíciles
de comprobar (p. ej., cómo responde un microprocesador a un sistema operativo
multitarea).
Además, la integración de las herramientas bajo un mismo entorno no sólo deja
que desear, sino que, en muchos casos, está desapareciendo como concepto. Actual-
mente, distintos vendedores de CAD están ofreciendo herramientas que cubren dis-
tintas partes del proceso de diseño; especificaciones, diseño arquitectural, síntesis,
diseño físico, etc. La tendencia actual es que estas diferentes herramientas inter-
cambien información entre ellas a través de un lenguaje común (VHDL o Verilog
en la mayoría de los casos), pero esto es algo que dista mucho de estar completa-
mente resuelto. Generalmente, los subconjuntos del lenguaje que entienden unas y
otras herramientas no son los mismos, teniendo que realizarse tediosas tareas de tra-
ducción para intercambiar información entre ellas. En estos casos, se dificulta aún
más la retroanotación de las modificaciones hechas en una etapa posterior del pro-
ceso de diseño sobre los datos de etapas anteriores.
Por último, puesto que los circuitos electrónicos ya no aportan, de por sí, valor
añadido a un producto, sino que es su funcionalidad la que les da ese valor, el cos-
te de diseño se ha vuelto un factor importante en el coste final del producto, coste
que es necesario reducir. Esto obliga a reutilizar parte de los diseños realizados, lo
que, a su vez, requiere poner un cuidado especial en la manera de diseñar. Los di-
seños deben realizarse de forma que otros diseñadores puedan entenderlos y modi-
ficarlos con poco esfuerzo para adaptarlos a sus necesidades. Esto requiere tam-
bién que se preste una atención especial a la documentación del diseño, que acaba
siendo un porcentaje no despreciable del tiempo dedicado al desarrollo de un dis-
positivo.
6.1.3. Orientación y objetivos del capítulo
En los siguientes apartados se propondrán métodos y procedimientos que ayuden a

paliar los problemas planteados, mostrando los puntos donde aparecen conflictos y
ayudando a extraer las máximas ventajas del proceso de diseño basado en VHDL y
síntesis automática.
En primer lugar, se exponen, con cierto detalle, las diferentes tareas que un di-
señador ha de llevar a cabo para realizar un diseño, desde el planteamiento de la
idea hasta la fabricación del circuito. El proceso de diseño mostrado pretende dar
una idea de los pasos a seguir y los problemas que pueden aparecer, aunque debe
ser entendido como un esquema general. Este esquema debería adaptarse a las ca-
racterísticas del equipo de diseño, tanto desde el punto de vista de las herramientas
disponibles como de la experiencia de los diseñadores y la propia complejidad del
diseño a realizar. Posteriormente se detallan aspectos relativos a la organización,
gestión y desarrollo de las bibliotecas de componentes, donde deben quedar archi-
vados los diferentes elementos que se van realizando durante el diseño. Por último,
se exponen métodos para realizar diseños que sean fácilmente reutilizables. Se deta-
llarán cuáles son los problemas que surgen al reutilizar un componente previamente
diseñado y se explicarán dos procedimientos (diseño genérico y configurable) para

realizar diseños reutilizables. En los ejemplos y explicaciones se ha considerado, en
general, que se están realizando diseños síncronos. La realización de diseños asín-
cronos, aunque conceptualmente similar, presenta particularidades que dificultarían
el seguimiento del texto. Por otro lado, la gran mayoría de los circuitos que se dise-
ñan en la actualidad son síncronos.
Este capítulo está orientado no sólo hacia personas que comienzan a utilizar el
VHDL y la síntesis automática, sino también a aquellos que ya poseen alguna expe-
riencia en diseño. El contenido de este capítulo no es, ni mucho menos, exhaustivo.
Si se desea una información más detallada sobre estos temas puede recurrirse a dis-
tintas referencias de la bibliografía, en especial a la metodología PRENDA para el
diseño de ASICs.
6.2. PLANIFICACIÓN DE UN DISEÑO DESCENDENTE
En el presente apartado se plantea, en primer lugar, lo que podría ser un flujo de di-
seño típico aplicado al desarrollo mediante VHDL y herramientas de síntesis lógica,
describiendo brevemente las tareas a realizar en cada etapa. A continuación se entra
en detalle en cada una de las etapas que componen el proceso de diseño. Se mues-
tran cuáles son los objetivos de cada etapa y cómo llevarlos a cabo, pormenorizan-
do los problemas que a menudo aparecen durante el diseño. Se presta especial aten-
ción a los procedimientos para controlar que en cada etapa se realicen las tareas
adecuadas y que no se omitan pasos que luego pudieran obligar a una vuelta atrás.
Como se ha explicado en la introducción al capítulo, la documentación del diseño
es un aspecto crucial en el desarrollo de cualquier proyecto, por lo que es tratada
con cierta profundidad.
Se ha procurado mostrar, mediante ejemplos concretos, cómo aplicar las re-
comendaciones dadas al desarrollo de un circuito, especialmente cuando estas reco-
mendaciones afectan a la escritura del código VHDL o a su síntesis. Los ejemplos
mostrados se han llevado a cabo utilizando herramientas de simulación y síntesis
comerciales, y podrían no ser aplicables en todos los casos. De cualquier manera,
éstos deben servir como guía para que el lector adquiera una visión general de los
problemas y de cómo solucionarlos; la adaptación de estos ejemplos a sus herra-
mientas concretas no debe suponer un gran esfuerzo.
Conviene tener en cuenta que la aplicación de un flujo de diseño requiere un
esfuerzo adicional al puramente técnico. Es necesario valorar la complejidad del
circuito antes de considerar la aplicación de los procedimientos que se muestran en
este apartado. El diseño de un circuito pequeño (2.000 o 3.000 puertas), realizado
por un solo diseñador, puede no requerir este tipo de procedimientos, aunque siem-
pre es conveniente llevar un cierto control sobre el proceso. En un diseño algo más
grande (10.000 a 20.000 puertas), generalmente llevado a cabo por más de un dise-
ñador, la aplicación de estos mecanismos suele aportar más ventajas que inconve-
nientes. Por último, en diseños mayores o críticos, donde el número de participantes
y complejidad aumenta, el seguimiento detallado de un flujo de diseño es la única
manera de llevar a buen término el desarrollo.
De cualquier manera, siempre resulta interesante conocer los problemas que

suelen surgir durante el desarrollo de un circuito integrado, con objeto de identifi-
carlos a tiempo y aplicar las acciones correctivas que sean necesarias.
6.2.1. El flujo de diseño
El desarrollo de un circuito integrado, como el de cualquier otro producto, requiere

que se vayan realizando diferentes tareas. Desde la concepción de la idea hasta su
materialización final, el circuito va pasando por diferentes fases en las que se van
definiendo, cada vez con más detalle, los diferentes componentes del circuito. Al
principio se parte de una idea muy general de lo que se quiere hacer y esta idea se
va depurando a lo largo del proyecto hasta conseguir el resultado deseado.
El flujo de diseño establece las etapas que se deben cubrir y las tareas a realizar
en cada etapa, así como las herramientas y métodos para llevar a cabo cada tarea.
Aunque en muchas ocasiones uno no es consciente, todos los proyectos que lleva-
mos a cabo, desde hacer una tortilla (si es que se le puede dar la categoría de pro-
yecto) hasta diseñar un superordenador, siguen un proceso de desarrollo más o me-
nos complejo. No es posible, por ejemplo, que hagamos una tortilla si antes no
hemos batido los huevos, para lo que previamente tendremos que haberlos roto con
cuidado. Tampoco nos quedará muy apetecible si, al freírla, el aceite no está sufi-
cientemente caliente, o si hay demasiado aceite. Siempre podremos calentar el acei-
te después de batir los huevos, pero ahorraremos tiempo si lo hacemos al mismo
tiempo. El flujo de diseño en este caso es sencillo; abrir la nevera, coger un huevo,
poner a calentar el aceite, batir el huevo (no olvidarse de la sal), freír la tortilla (ha-
biendo previsto un plato donde dejarla cuando esté hecha), sacarla cuando esté a
nuestro gusto, apagar el fuego y finalmente degustarla. Del grado de detalle con el
que se siga este procedimiento y de la habilidad del diseñador (en este caso el coci-
nero) dependen el éxito del proyecto y el tiempo empleado en llevarlo a cabo.
Diseñar un circuito integrado no es, evidentemente, como la tarea de hacer una
tortilla (aunque a algunos nos puede resultar más difícil este proyecto), pero com-
parte con ella muchas características; las tareas deben estar correctamente secuen-
ciadas, muchas de ellas pueden realizarse en paralelo y a menudo cada etapa requie-
re un proceso de evaluación tras el que se decide si el resultado es o no correcto
(freímos la tortilla hasta que está suficientemente hecha). Algunas etapas son irre-
versibles (la tortilla nos quedó demasiado hecha) y otras tienen arreglo (si nos que-
damos cortos de sal siempre podemos echar más al final). Un buen proceso de dise-
ño debe considerar todos estos casos para dar la mejor solución, evitando que se
produzcan situaciones irreversibles.
Existe un gran número de flujos de diseño que tienen en cuenta las características
particulares de cada proyecto. Algunos realizan una gran cantidad de tareas en parale-
lo, otros permiten saltar de una etapa posterior a una previa en cualquier momento (es-
to no ocurre con la tortilla, ya que no es posible batirla una vez hecha), mientras que
en otras ocasiones es necesario cerrar completamente una etapa antes de comenzar la
siguiente. En el caso del desarrollo de un circuito integrado, un flujo de diseño como
el mostrado en la Figura 6-1 da buenos resultados en la mayoría de las ocasiones.
:"" - -- -- -- _. -.¡¡..t
··
FIGURA 6-1. Flujo de diseño de un circuito integrado,
• Etapa de requisitos: esta es la primera etapa del proyecto. En ella, la idea

inicial de lo que se quiere realizar se convierte en un documento preliminar
que sirve de base para evaluar la viabilidad técnica y económica del mismo.
Esta es una etapa de arranque. A menudo es realizada conjuntamente por el
cliente (quien encarga el desarrollo de un circuito) y el diseñador.
• Etapa de especificaciones: analizada la viabilidad de la idea, tanto desde

su punto de vista técnico como económico, y determinada con más o menos
detalle la funcionalidad inicial del circuito, se pasa a la etapa de especifica-
ciones. El objetivo de esta etapa es identificar con detalle, y documentar
convenientemente, todas las funciones que debe realizar el circuito. Se de-
terminan el número de entradas/salidas, la tensión de alimentación, los blo-
ques que componen el circuito y su funcionalidad, etc. En algunos casos se
desarrollan u obtienen durante esta etapa modelos VHDL del entorno don-
de va a trabajar el circuito .. En proyectos de cierta envergadura se define
además el método de trabajo, las herramientas a utilizar, la partición del tra-
bajo, etc.
• Etapa de diseño arquitectural: esta es normalmente la primera etapa de di-

seño en VHDL. Tras llevar a cabo la partición del circuito en bloques funcio-
nales manejables, el diseñador los describe en VHDL y los simula. Durante
esta etapa se desarrollan otros elementos fundamentales del diseño: los ban-
cos de prueba. Éstos serán utilizados repetidamente en todas las etapas poste-
riores del desarrollo. La etapa de diseño arquitectural es, generalmente, la
etapa más crítica del proyecto, por lo que a menudo también es la más larga
y la que más esfuerzo requiere.
• Etapa de diseño lógico o detallado: esta etapa está orientada fundamental-
mente a la síntesis del circuito. Para ello puede ser necesario realizar modifi-
caciones en el código VHDL desarrollado, con objeto de adaptarlo a las
herramientas de síntesis disponibles o de corregir soluciones del diseño
arquitectural que sean inadecuadas en cuanto a área o retardos. A menudo es
necesario que exista cierta interacción entre la etapa de diseño arquitectural y
lógico, de manera que los resultados de la síntesis ayuden a tomar decisiones
en cuanto al diseño arquitectural del circuito. Durante esta etapa también se
generan los estímulos para realizar el test de fabricación, si es que éste es ne-
cesario.
• Etapa de diseño físico: finalizadas las tareas de diseño lógico, se procede al
diseño físico del circuito. En esta fase se lleva a cabo la ubicación y conexio-
nado del circuito, se extraen sus características reales (capacidades parásitas
debidas a las puertas y pistas de interconexión) y se simula el circuito com-
pleto con estos datos. Esto permite obtener resultados realistas en cuanto a
cómo se va a comportar el circuito.
• Etapa de fabricación: el circuito es fabricado o grabado (si se trata de un
dispositivo programable tipo FPGA o PLD) para obtener unos prototipos. Se
realiza el test de fabricación para comprobar que ésta ha sido correcta.
• Etapa de validación: con los prototipos del circuito se realiza la validación
final del diseño, comprobando que su funcionamiento es el adecuado una vez
instalado en el sistema final. De ser así, se puede pasar a la producción en se-
rie del diseño. También se realiza en esta etapa la caracterización del circui-
to, para poder así elaborar las hojas de características del mismo.
Este es un flujo de diseño lineal. Cada etapa requiere un proceso de revisión,

tras el cual se decide si se pasa o no a la etapa siguiente. Si el resultado no se consi-
dera satisfactorio, habrá que volver a entrar en la etapa para hacer las modificacio-
nes necesarias hasta que el resultado sea el deseado. Este flujo de diseño resulta, sin
embargo, demasiado rígido para la mayoría de los diseños de circuitos. A menudo
es necesario conocer características del diseño que no se sabrán con detalle hasta
etapas posteriores. El coste final del circuito podría ser, por ejemplo, el factor fun-
damental de un proyecto, pudiendo llegarse a eliminar o añadir más lógica al circui-
to en función de esto, pero el coste final no se conoce con detalle hasta que se reali-
za el diseño físico. Esto implicaría un proceso cíclico en el que hay que terminar el
diseño antes de saber lo que finalmente va a incluir el circuito. Recorrer formalmen-
te todas las etapas, entrando y saliendo de cada una de ellas tras un proceso de revi-
sión, implicaría en este caso un coste excesivo, por lo que es necesario plantearse
un flujo de diseño algo más flexible que permita entrar en una etapa sin haber ter-
minado la anterior. Así, podríamos empezar con el diseño físico de alguna parte del
circuito sin haber siquiera completado la etapa de diseño arquitectural (o incluso
antes). De esta manera podríamos hacernos una idea del coste final del circuito,
ajustando la funcionalidad a la vista de los resultados.
La Figura 6-2 muestra gráficamente esta idea. El grado de solapamiento y la
duración de las etapas varía según cada proyecto. También puede apreciarse una ta-
rea global de gestión, que discurre a lo largo de todo el proyecto, y que no estaba
explícita en el flujo de diseño de la Figura 6-1. Disponer de un flujo de diseño flexi-
ble facilita la resolución de estos problemas, aunque debe existir un cierto compro-
miso entre flexibilidad y control del proceso de diseño.
Un último aspecto importante del flujo de diseño es que permite, cuando se de-
sarrollan circuitos de forma habitual, detectar dónde están los problemas y corregir-
los en futuros proyectos. Al realizar siempre las mismas etapas y tareas, se pueden
ir identificando aquellos procedimientos que no dan buenos resultados y modificar-
los para corregir sus defectos. Lo importante, entonces, de un proceso de diseño no
es tanto lo bueno que resulte, sino que pueda reproducirse y corregirse en aquellos
puntos donde no funcione -.
Por último cabe destacar que, en todo flujo de diseño, es necesario buscar los
procedimientos para automatizar, en el mayor grado posible, las tareas a realizar.
Como se ha visto, la mayoría de las tareas que se llevan a cabo son cíclicas; se repi-
ten una y otra vez hasta alcanzar el resultado deseado. Este proceso cíclico es mu-
cho más acusado durante las etapas de diseño arquitectural, lógico y físico. En estos
casos es especialmente importante disponer de mecauismos de automatización de
las tareas. Durante la etapa de diseño arquitectural, por ejemplo, es muy convenien-
te tener métodos para realizar la compilación del código VHDL, su simulación y
D~se~oarquitectural
¡ Fabricación I
I Validación
Gestión del proyecto
FIGURA 6~2. Ejemplo de distribución temporal de las etapas de diseño de un cir-

cuito integrado.
comparación de los resultados de forma automática. Durante la etapa de diseño ló-

gico, es además interesante automatizar los procedimientos de síntesis, que a menu-
do requieren un elevado número de pasos y condiciones que fijar (retardos máxi-
mos permisibles, área que se quiere conseguir, etc.).
La automatización de las tareas en cada etapa del diseño no sólo permite aho-
rrar tiempo al diseñador, sino que además supone una garantía de que no se olvida
ningún paso en el proceso. Por otro lado, los ficheros que a menudo hay que utilizar
para automatizar las tareas sirven posteriormente como documentación de lo que se
ha hecho. Esto, a su vez, permitirá detectar posibles errores o, si no los hubiera, val-
drá como ejemplo para posteriores proyectos.
A lo largo de los siguientes apartados hablaremos a menudo del cliente y del di-
señador. Consideraremos como cliente aquella persona o empresa que desea realizar
un circuito. Es él quien decide cuál es la funcionalidad final que debe incluir el cir-
cuito, decide quién debe diseñarlo, si el coste es adecuado, quién lo fabricará, etc. El
diseñador será la persona o equipo de personas encargados de llevar a cabo el desa-
rrollo, escribir el código VHDL, realizar las simulaciones, el diseño físico, etc.
Cliente y diseñador podrían ser la misma persona o la misma compañía; lo impor-
tante no es quién realiza estas tareas, sino tener claro las tareas que hay que realizar.
A menudo, por ejemplo, el cliente se ayuda del diseñador para escoger al fabricante
o la tecnología de los circuitos, decidir la funcionalidad que incluirá, calcular el cos-
te, etc. En la mayoría de los casos, el número de participantes en el proceso de dise-
ño de un circuito es mayor. Tenemos al fabricante, los proveedores, los vendedores
de herramientas de CAD, subcontratistas, etc. Sin embargo, para el propósito del ca-
pítulo es suficiente, y más sencillo, considerar sólo las figuras de cliente y diseñador.
Puede consultarse la bibliografía para obtener información más extensa sobre estos
aspectos.
6.2.2. De los requisitos a las especificaciones
El objetivo de las etapas de requisitos y especificaciones es la definición de lo que

debe ser el circuito a desarrollar. Esta definición debe convertir la idea original en
un documento donde se detallen las señales que requiere el circuito y su comporta-
miento, tanto desde el punto de vista funcional como desde el punto de vista físico
(retardos, consumos, frecuencias, etc.).
6.2.2.1. Los requisitos
El desarrollo de los requisitos es, generalmente, una tarea poco formalizada. Depen-
diendo del tipo de proyecto, las características del circuito pueden estar muy poco
definidas o, por el contrario, pueden conocerse con bastante detalle.
El primer caso responde, normalmente, al desarrollo de un producto nuevo. El
circuito formará parte de un sistema que aún está poco definido y que, por tanto, '
puede' modificarse según sea necesario. Un caso típico podría ser el circuito para
controlar el expendedor de latas de refresco del ejemplo mostrado en el Apéndice 1.
Las funciones que realice el circuito dependerán no sólo de las necesidades funcio-
nales, sino también de coste final y la facilidad de desarrollo. Así, por ejemplo, po-
dríamos pensar que el expendedor de refrescos pudiese incluir una pantalla de visua-
lización donde mostrar los precios más o menos compleja, aceptar más o menos ti-
pos de monedas o que pudiera expedir más de un tipo de producto en una sola opera-
ción (jsi se ha introducido suficiente dinero, claro está!). Escoger una solución u otra
depende de multitud de factores, y generalmente requiere un análisis de viabilidad
técnica y económica complicado para encontrar la mejor solución. Este análisis no
sólo incluirá los aspectos relacionados con el circuito a desarrollar, sino también los
relacionados con el coste de los demás elementos del sistema, la facilidad de fabri-
cación, la funcionalidad de nuestra máquina respecto a otras que existan en el merca-
do, etc. El desarrollo de los requisitos consistirá entonces en un proceso cíclico en
donde la idea inicial se va depurando en función de los análisis que se vayan reali-
zando. El principal objetivo en este caso es identificar, a grandes rasgos, cuál es la
funcionalidad básica que debe realizar el circuito y plasmarla en un documento ini-
cial de trabajo que pueda servir de base para el desarrollo de las especificaciones.
Más sencillo resulta el desarrollo de los requisitos en el caso de un circuito cu-
yas condiciones de contorno estén más definidas. Volviendo al ejemplo del expen-
dedor de refrescos, podríamos querer desarrollar un circuito para controlar una má-
quina que admitiese cinco tipos de monedas (25, 50, 100,200 y 500 pesetas), cuatro
tipos de refrescos (cola, tónica, naranja y cerveza), cuyos precios pudiesen fijarse
mediante cuatro pulsadores exteriores (evidentemente sólo accesibles por el dueño
de la máquina) en unidades de 25 pesetas y que admitiese hasta un máximo de 50
latas por producto. Los precios podrían mostrarse mediante un visualizador de tres
dígitos de siete segmentos y los clientes dispondrían de cuatro pulsadores para se-
leccionar el producto y un pulsador para la devolución de monedas. En estos casos
el desarrollo de los requisitos requiere un análisis menos detallado, puesto que la
funcionalidad básica está definida.
En cualquier caso, los requisitos deben plasmar en un documento no sólo la fun-
cionalidad del circuito, sino también el coste estimado del circuito a desarrollar, el
tiempo de desarrollo, su tamaño y características tecnológicas, como son la tensión
de alimentación, consumo, temperaturas máximas y mínimas que debe soportar, etc.
Todos estos aspectos quedan recogidos en el Documento de Requisitos, que ac-
túa como texto base para iniciar el proyecto. Si la empresa que va a realizar el pro-
ducto (la máquina de refrescos) no dispone de centro de diseño, este documento se-
rá distribuido entre varios centros de diseño para que hagan una evaluación técnica
y económica del circuito a desarrollar y oferten un presupuesto a través de una Pro-
puesta de Desarrollo. Esta propuesta incluye normalmente un plan para el desarro-
llo del circuito, una descripción de la funcionalidad de la propuesta presentada, una
estimación del tiempo de diseño y del coste del desarrollo, estimaciones sobre el
coste final del producto, posibles modificaciones a los requisitos del cliente, etc. En
función de esta propuesta el cliente escogerá el centro de diseño que más le satisfa-
ga para llevar a cabo el desarrollo.
La Tabla 6-1 muestra los aspectos fundamentales que deben quedar definidos
en el Documento de Requisitos, mientras que la Tabla 6-210 hace para la Propuesta
de Desarrollo.
TABLA 6-1. Esquema básico del documento de requisitos
Documento de requisitos
Presentación del cliente

Presentación de la aplicación
Descripción de la aplicación
Mercado
Justificación de la necesidad del ASIC
Posibilidad de reutilización del diseño
Descripción del entorno del ASIC
Descripción de la funcionalidad del ASIC
Restricciones del ASIC
Documentación aplicable
A menudo no es necesario seguir un procedimiento tan formalizado para ela-

borar los requisitos. El hacerlo o no depende de la complejidad del proyecto, el ti-
po de cliente, de la concreción de la idea original y de la experiencia, tanto del
cliente como del diseñador, en este tipo de desarrollos. En cualquier caso, un docu-
mento inicial de trabajo siempre resulta interesante, ya que el desarrollo de la si-
guiente etapa (las especificaciones) es una tarea costosa, y los olvidos y malenten-
didos pueden encarecerla. Como ejemplo, en el Apéndice 1 se muestra 10 que
podría ser un Documento de Requisitos sencillo para la máquina de refrescos del
ejemplo. Para simplificar la exposición, supondremos que cliente y diseñador son
el mismo departamento de una empresa, por 10 que no se ha elaborado una Pro-
puesta de Desarrollo.
Como se muestra en el ejemplo, muchos aspectos del diseño pueden no estar
aún definidos (de hecho, esta será la situación más habitual). En estos casos, con-
viene dejar claramente explícitos los puntos no definidos, de forma que posterior-
mente pueda comprobarse que se ha dado respuesta a todos los interrogantes que
inicialmente tenía el proyecto.
TABLA 6-2. Esquema básico de la propuesta de desarrollo
Propuesta de desarrollo
Descripción de la propuesta y cumplimiento de requisitos

Plan de desarrollo preliminar
Cumplimiento de plazos
Métodos de control y verificación
Coste del diseño y/o fabricación del ASIC
Alternativas o sugerencias del diseñador
La etapa de requisitos, como cualquier otra etapa, tiene un proceso de revisión

final donde se aprueban los requisitos. Sin embargo, la revisión de esta etapa no re-
sulta un proceso tan formal como lo serán las revisiones de las etapas posteriores
del proyecto. Habitualmente, esta revisión consiste en un contrato o acuerdo de co-
laboración entre el cliente y el diseñador, y en un análisis conjunto del trabajo reali-
zado para limar los últimos detalles. Esta revisión suele llevarse a cabo mediante
una reunión que, por otro lado, marca el inicio del proyecto.
De cualquier manera, debe verificarse que tras la etapa de requisitos se han de-
finido y analizado, al menos, los siguientes puntos:
• Aspectos técnicos: funciones básicas que debe realizar el circuito, estima-

ción del consumo, frecuencia máxima de funcionamiento y tamaño.
• Aspectos económicos: estimación del coste objetivo del producto, coste de
los prototipos y coste del desarrollo.
• Aspectos organizativos: planificación preliminar del proyecto, tiempo de
desarrollo y responsabilidades de los participantes.
6.2.2.2. Las especificaciones
El objetivo de las especificaciones es obtener una descripción detallada del circuito

a diseñar, tanto desde el punto de vista funcional (lo que debe hacer, patillaje, etc.),
como desde el punto de vista tecnológico (tecnología a utilizar, tensión de alimenta-
ción, consumo, etc.). Esta es una de las etapas críticas del proyecto; de la precisión
de las especificaciones y de lo completo de su contenido depende en gran medida el
éxito del desarrollo. Normalmente, las especificaciones se recogen en el Documento
de Especificaciones. Su redacción suele quedar a cargo del director del equipo de
diseño, al ser éste habitualmente el componente más experto del equipo de diseño.
Las especificaciones deben ser completas, claras, concisas y sin ambigüeda-
des. Los problemas con las especificaciones surgen, precisamente, debido a impre-
cisiones, falta o redundancia en la información, datos incorrectos o descripciones
ambiguas o difíciles de interpretar. La utilización de lenguajes de descripción de
hardware, yen concreto del VHDL, puede ayudar en algunos casos a evitar estas
situaciones. Sin embargo, como se verá, su uso durante esta etapa no resulta senci-
llo, por lo que es necesario disponer de otros métodos que resuelvan los problemas
planteados.
Unas especificaciones ideales deberían permitir al diseñador trabajar indepen-
dientemente del cliente. En la práctica esto nunca es cierto, y tampoco es conve-
niente; una buena comunicación entre cliente y diseñador, tanto a nivel técnico co-
mo empresarial, es la mejor garantía para evitar problemas durante el desarrollo. De
cualquier manera, el tiempo y el esfuerzo invertido en desarrollar unas buenas espe-
cificaciones generalmente revierte en un proceso de diseño más libre de problemas.
En los siguientes apartados se comparará lo que serían unas especificaciones idea-
les con lo que suelen ser unas especificaciones reales. Con ello se pretende resaltar
cuáles son las fuentes de problemas y cómo se pueden limitar sus consecuencias.
6.2.2.2. 1. Unas especificaciones ideales

Los circuitos electrónicos son elementos que, sometidos a ciertas solicitaciones ex-
ternas (cambios en sus señales de entrada), reaccionan realizando ciertas acciones
(cambios en las señales de salida). Visto de esta manera, la especificación de un cir-
cuito puede entenderse como una descripción de cuál es la secuencia de cambios
que se debe producir en las señales de salida del circuito ante ciertos cambios en las
entradas. En este sentido, una especificación podría consistir en una serie de vecto-
res aplicados (conjuntos de unos y ceros) a las entradas y los correspondientes valo-
res esperados a las salidas. Evidentemente, una especificación de este estilo sería
inutilizable, ya que, aparte de ser ilegible, requeriría de infinidad de páginas para
incluir todos los posibles casos.
Utilizando VHDL, sin embargo, es posible especificar casi completamente el
funcionamiento y características de un circuito. Supongamos, por ejemplo, que de-
seamos especificar un circuito para llevar la cuenta de una serie de eventos (que se
detectan por un pulso positivo en una entrada al circuito). Una manera de hacerlo
sería realizando una descripción VHDL del mismo, tal y como se muestra en el có-
digo del Listado 6-1. En este caso, lo que se especifica es la funcionalidad del cir-
cuito de "patillas adentro", y no cómo debe responder ante una serie de estímulos
de entrada.
library ACME;
use ACME.TiposBasicos.all;
entity mi_circuito is
port (
Evento in bit;
Inicia in bit;
Reloj in bit;
Salida out inteqer
)¡
-- Los siguientes atributo&'~f~ algunos aspectos ~ecnológicos:

attribute tecno¡~ia of mi.,..circuito : entity is "CMOS-O.Su·;
attribute tens~6nVdd of mi'"rcif~~ito : entity is 3.3 ¡ ,:
--ií ~igUiéht'e proceso sé'uthik ~ra verÜiéar1a' ú&ueri~i~

-- del reloj del circuito . . i .
process pruebaReloj{Clock : in bit) ls

variable UltimoCambio : time := O ns;
begin
assert UltimoCambio - now ~ 100 ns report
"Error: La frecuencia de reloj debe ser 10 MHz'
severity WARNING;
if Reloj'event and Reloj = '1' then
.ultimoCambio := now;
end if;
end PruebaReloj ¡
begin
Pruebareloj(Reloj)¡
ead mi_circuito¡
architecture ESPECIFICACION of mi_circuito is

signa! AuxCuenta : integer¡
begin
Cu¡mta <= AuxCuenta¡
Cuenta : process
begin
wait until Evento = '1' ar Inicia = 'O'¡
if Inicia = '0' tben
AuxCuenta <= O ¡
end if¡
wait until Evento = 'O' ar Inicia = 'O'¡
if Inicia /= 'O' tben
if AuxCuenta < 16 tben
AuxcUenta <= AuxCuenta + 1¡
else
AuxCuenta <= O ¡
end if¡
endif;
end process;
end ESPECIFICACION¡
LISTADO 6-1. Especificación de un circuito mediante descripción VHDL. Compor-

tamiento interno.
En la descripción mostrada es posible leer, con un poco de práctica, cómo debe

funcionar el circuito que se desea realizar. Esta es además una descripción simula-
ble, lo que implica que el diseñador puede utilizarla para comparar los resultados de
su diseño con los de la especificación. La descripción no hace explícito cómo debe
diseñarse el circuito (eso es una tarea a realizar durante el diseño arquitectural). De
hecho, se especifica que debe haber un reloj de entrada de 10 MHz, pero no se deta-
lla cómo se utiliza en el circuito.
Se podría también especificar el funcionamiento del circuito de "patillas afue-
ra", es decir, mostrando cómo son las salidas que debe dar en función de una serie
de entradas. Un ejemplo de este método se muestra en el Listado 6-2.
entity mi_especificacion is
ead mi_especificacion¡
architecture PATILLAS_AFUERA of mi_especificacion is

camponet mi_circuito
port (
Evento in bit;
Inicia in bit;
Reloj in bit;
Salida out integer
);
end camponent;
signal Reloj: bit := '0';

signal EVento: bit := '0';
signal Cuenta, NumEventos: integer;
signal Inicia: bit := '1';
begin
Reloj <= not Reloj after 100 ns;
Inicia<= '1',
'O' after 111 ns,
'1' after 50 ns;
Generador : process
begin
wait fer 122+. nsr
Evento <= '1';
wait fer 200 ns
Evento <= 'O';
end process;
Verifica : process
begin
wait en Inicia, Evento;
if Inicia = 'O' then
wait for .20 ns:
assert CUenta ~ O report
"Error : el circuito no se resetea'
severity ERROR; .
NumEventos <= O;
else
if Evento = '1' then
PulsoEmpezado := true;
end if;
if Evento = ' O' then
if PulsoEmpezado then
if NumEventos < 16 then
NumEventos <= NumEventos + 1;
else ,..
NumEventos <=·n;
end if;
wait for 20 nsj
assert CUenta = NumEventos report

"Error : El circuito no cuenta bien"
severiry ERROR¡
end if¡
end if;
end if;
end process;
Circuito : mi_circuito
port map (
Evento => Evento,
Inicia => inicia,
Reloj => RelQj,
Salida => Cuenta
)¡
end PATILLAS_AFUERA¡
LISTADO 6-2. Especificación de un circuito mediante VHDL. Comportamiento vis-

to desde el exterior.
En el ejemplo se han descrito una serie de señales y procedimientos que permi-

ten generar los eventos y verificar si la respuesta del circuito diseñado es la adecua-
da. En realidad se está describiendo un banco de pruebas para el circuito que verifi-
ca, de forma automática, si los resultados son correctos. Desde otro punto de vista,
se está modelando o especificando el entorno del circuito, el sistema en el que va a
estar funcionando.
Realizar las especificaciones en VHDL tiene como ventaja el que éstas resultan
simulables. Al mismo tiempo, las especificaciones son legibles por el diseñador,
que puede interpretar, ayudado por las simulaciones, el código VHDL. Sin embar-
go, tal y como puede desprenderse del código, aunque puedan resultar unas especi-
ficaciones completas y sin ambigüedades, su interpretación no es sencilla. Esto
contradice una de las características fundamentales que deben cumplir las especifi-
caciones; que sean claras. Podemos imaginar, como caso extremo, que las especifi-
caciones de un microprocesador vinieran dadas mediante un código VHDL que
simulara la respuesta del microprocesador ante una serie de programas tipo. El dise-
ñador podría comprobar si su diseño es o no correcto pero, con toda seguridad, sería
incapaz de realizar un circuito que se comportase de esa manera, ya que le resulta-
ría prácticamente imposible identificar la funcionalidad con la lectura del código o
el análisis de las simulaciones. Por otro lado, las especificaciones en VHDL no pue-
den cubrir todos los aspectos del diseño (especialmente en cuanto a la especifica-
ción de las características tecnológicas) y, en la mayoría de los casos, su desarrollo
resulta extremadamente complejo.
Unas buenas especificaciones deben contener, sobre todo, una descripción cla-
ra y completa de 10 que se desea diseñar. Para ello son de gran utilidad los gráficos,
cronogramas, diagramas de estados y, principalmente, una buena descripción tex-
tual. En este sentido, debe intentarse que ésta sea 10 más escueta posible, evitando
redundancias, sin que por ello se omita información. Además, las especificaciones
deben estar cenadas, ya que los cambios en las especificaciones producen rediseños
constantes y son causa habitual de malentendidos. Las especificaciones deberían es-
tar escritas de forma que pueda comprobarse que se cumplen todas las condiciones
y funcionalidades incluidas en el documento.
Las especificaciones ideales serían aquellas que se mantuviesen estables a lo
largo del proceso de diseño. Su contenido sería suficiente para que el diseñador tra-
baje sin necesidad de consultar al cliente. Aparte de la descripción textual de la fun-
cionalidad y aspectos tecnológicos, contendrían un modelo VHDL del entorno del
circuito. Este modelo no sólo emularía las señales de entrada al circuito a diseñar,
sino que además respondería adecuadamente a las respuestas del circuito. De esta
manera, el diseñador podría realizar las simulaciones del sistema completo sin tener
que desarrollar los bancos de prueba. Con ello se evitaría un problema relativamen-
te frecuente, como es que se cancelen errores debido a que la misma persona realice
el modelado del circuito y del entorno (podemos pensar, por ejemplo, en el diseño
de un contador de (} a 15; el diseñador podría realizarlo para que contase de O a 14,
y hacer los bancos de prueba que comprueban esta cuenta; evidentemente, no sería
consciente del error),
6.2.2.2.2. Las especificaciones reales

En la práctica, las especificaciones adolecen de multitud de defectos. En primer lu-
gar, las especificaciones nunca (o casi nunca) son estables. La falta de información
inicial, los imprevistos del desarrollo, los cambios en el sistema, etc., obligan a me-
nudo a realizar modificaciones para adaptarse a las nuevas condiciones de contorno.
Por otro lado, unas especificaciones demasiado cerradas no permiten adaptarse a
cambios que podrían ser beneficiosos para el diseño (se dice que el diseño está so-
breespecificado) . Como ejemplo podríamos fijarnos en el circuito de la Figura 6-3
(vl.0), que se corresponde con la especificación inicial del expendedor de refrescos
del Apéndice 1 (ver la especificación completa en el apéndice). El circuito dispone,
Clk
ResN
BotProd1 TrampProd Clk TrampProd
BotProd2 NoHayP1 ResN NoHayP1
BotProd3 NoHayP2 BotProd1 NoHayP2
BotProd4 ColaMatic NoHayP3 BotProd2 NoHayP3
PrecProd1 NoHayP4 BotProd3 NoHayP4
v1.0 NoHayCambio BotProd4 NoHayCambio
PrecProd2
PrecProd3 MoneLleno BotDevuelve MoneLleno
PrecProd4 MonedaOut BotPVPlncre MonedaOut
BotDevuelve DispUnidad BotPVDecre DíspUnidad
BotPVPlncre DispDecena InteModo DlspDecena
BotPVDecre DispCentena Monedalnt DispCentena
Monedalnt
FIGURA 6-3. Diferentes versiones con la misma funcionalidad.

entre otras, de cuatro señales de entrada para fijar el precio de cada producto (Prec-
Prodx) y otras cuatro señales para la selección del producto (BotProdx). En un aná-
lisis posterior se podría llegar a la conclusión de que mientras se está fijando el pre-
cio de cada refresco no se están expediendo refrescos. Podrían entonces utilizarse
las mismas señales de selección para fijar el precio del producto, existiendo una se-
ñal inteModo que cambiaría entre operación normal y operación de cambio de pre-
cio (v2.0). De esta manera ahorraríamos tres entradas al circuito, pudiéndose redu-
cir el coste del encapsulado. Encontrar el punto justo entre unas especificaciones
completas, sin que por ello estemos sobreespecificando, es el objetivo de una buena
etapa de especificaciones.
En otras ocasiones, el contenido de las especificaciones es incompleto. A me-
nudo existen aspectos no conocidos o que requieren un análisis más detallado o que
son función de resultados posteriores del proyecto. En estos casos es corriente en-
contrar que en las especificaciones aparecen notas como por definir, por confirmar
o por consultar. El diseño del circuito puede comenzarse y fijar esos detalles más
adelante. En otras ocasiones las especificaciones resultan incompletas simplemente
porque se olvidan algunos detalles.
Por otro lado, aparecen a menudo contradicciones o ambigüedades que son di-
fíciles de detectar en las etapas iniciales del proyecto. Estas ambigüedades pueden
ser debidas a errores de redacción, imprecisiones o conocimiento poco detallado de
lo que posteriormente será el circuito. En nuestro sencillo ejemplo podría ocurrir
que, puesto que el importe de los productos se especifica en unidades de 25 pesetas,
no se hubiese previsto la devolución de monedas de 5 pesetas. Se estaría suponien-
do con ello que el usuario de la máquina no va a introducir, por ejemplo, 155 pese-
tas para pedir un refresco que cuesta 125. Pero dicha situación, aunque poco proba-
ble, es posible, y podría dar al traste con el diseño.
Por último, la redacción de las especificaciones no es siempre lo clara que sería
deseable. Debe prestarse una especial atención a este aspecto, intentando evitar fra-
ses largas y de difícil comprensión. La inclusión de gráficos y diagramas puede
ayudar en gran medida a conseguir este objetivo. Sin embargo, debe tenerse en
cuenta que la interpretación del texto, diagramas y gráficos puede ser diferente se-
gún quien los lea. Esta fue precisamente una de las razones por las que el DoD pro-
puso la creación de un lenguaje estándar para la descripción de circuitos integrados,
el VHDL.
El contenido y organización del Documento de Especificaciones puede variar
notablemente dependiendo del tipo de circuito y aplicación que se esté consideran-
do. Sin embargo, existen una serie de puntos que siempre aparecerán. La Tabla 6-3
muestra un esquema típico de un documento de especificaciones.
El Documento de Especificaciones debe entenderse como un documento vivo.
Los cambios, aunque no deseables, son relativamente frecuentes. En este sentido
deben plantearse métodos para que estos cambios no repercutan de forma negativa
en el proyecto. Estos métodos van desde el control de versiones y cambios, que per-
mite a todos los participantes en el proyecto estar al día de las últimas modificacio-
nes, hasta los procedimientos de diseño genérico, que facilitan los cambios de últi-
ma hora de forma rápida y con poco esfuerzo. Estos procedimientos serán expuestos
en posteriores apartados de este capítulo.
TABLA 6-3. Esquema del documento de especificaciones
ESQUEMA DEL DOCUMENTO DE ESPECIFICACIONES

Introducción
Discrepancias con el documento de requisitos
Terminología usada
Estándares usados
Especificaciones globales
Breve descripción y objetivos del ASIC
Diagrama de E/S y diagrama de bloques funcionales
Modos de operación y condiciones de paso de un modo a otro
Registros programables y cometido
Definición de E/S
Especificación de los bloques funcionales
Descripción del bloque .
Diagrama de E/S
Modos de operación y condiciones de paso
Estado tras la inicialización y terminación
Registros programables y cometido
Especificaciones operacionales
Formato y rango de los datos
Protocolos y algoritmos de las operaciones
Dirección. modo de funcionamiento y formato de los registros programables
Estado de los registros tras la inicialización o terminación de operaciones
Especificaciones tecnológicas
Especificaciones eléctricas
Especificaciones temporales
Especificaciones tecnológicas globales
Parámetros eléctricos
Tensión de alimentación
Consumo estático y dinámico
Características de las E/S
Tensiones máxima y mínima
Corrientes
Margen de temperaturas
Frecuencia de funcionamiento
Encapsulado
Otras especificaciones
6.2.2.2.3. Elaboración de las especificaciones

El desarrollo de las especificaciones es una tarea fundamentalmente técnica. Aun-
que el cliente. participa habitualmente en su preparación. la mayoría de las veces la
responsabilidad de su elaboración recae sobre el diseñador (lo que no evita que sea
el cliente quien debe dar la aprobación última). Su elaboración requiere un conoci-
miento profundo del diseño de circuitos electrónicos y de la aplicación a la que va

dedicada el circuito.
Durante la etapa de especificaciones se realiza la primera partición en bloques
funcionales del circuito. Esta partición no tiene por qué coincidir con la partición
que se realice finalmente. Su objetivo es dividir el circuito en unidades que puedan
especificarse de forma más o menos independiente, de manera que se facilite la es-
pecificación y permita un reparto de tareas entre varios diseñadores.
Para cada uno de los bloques funcionales se identificarán y especificarán sus
entradas y salidas, su funcionalidad detallada, sus modos de operación, sus restric-
ciones temporales, el estado tras la inicialización, registros de datos, registros pro-
gramables, restricciones temporales, etc.
Finalizada la especificación de cada bloque se procede a la especificación tec-
nológica global del circuito. Ésta incluirá aspectos como la tensión de alimentación,
consumo máximo, condiciones de funcionamiento, encapsulado y patillaje (inclui-
das patillas de masa, alimentación y señales para el test), etc.
Las especificaciones deben contener además una descripción global del circui-
to, su funcionalidad, sus entradas y salidas, modos de operación y registros princi-
pales. Esta descripción servirá para hacerse una idea rápida de la funcionalidad del
circuito y su cometido. El contenido básico es el mismo que el del documento de
requisitos, pero bastante más detallado (ya se conocen más detalles sobre el diseño).
Esta descripción se incluirá al principio del documento.
Hay que tener en cuenta que el Documento de Especificaciones es un docu-
mento de trabajo. Es el documento base de diseño y será continuamente consultado
por los diseñadores. En este sentido debe hacerse un esfuerzo especial para que ten-
ga una organización adecuada y sea de fácil manejo. Los índices, tablas de conteni-
dos y figuras, las referencias a otras partes del documento, etc., son de inestimable
utilidad para conseguirlo.
Como ejemplo, en el Apéndice 1 se muestra la especificación de la máquina de re-
frescos. Conviene destacar que ésta es una especificación sencilla. Aunque deben evitar-
se las especificaciones voluminosas, a menudo resultan documentos de cierta extensión.
Como se ha comentado previamente, el uso del VHDL en las especificaciones
puede ser de gran ayuda tanto para completar la documentación como para disponer
de modelos simulables que faciliten una interpretación de la especificación. Sin em-
bargo, el código VHDL nunca debe reemplazar la especificación en lenguaje natu-
ral, sino servir de apoyo a la misma. En ocasiones, el cliente puede aportar modelos
en VHDL que valdrán como referencia para validar el diseño. En estos casos, los
modelos VHDL son utilizados para aprobar formalmente la revisión del diseño en
sus diferentes etapas.
6.2.2.2.4. El plan de desarrollo y el plan de pruebas

Aparte de la elaboración del documento de especificaciones, existen dos importan-
tes tareas organizativas que se deben desarrollar durante esta etapa; la elaboración
del plan de desarrollo y el plan de pruebas.
El objetivo del plan de desarrollo es definir, al principio del proyecto, cuáles
son las responsabilidades de cada participante en el proceso de diseño, cómo se van
a llevar a cabo las tareas, cómo se va a controlar el avance del diseño y cuál va a ser
la programación temporal del mismo. Todos estos aspectos quedarán recogidos en
un documento, denominado Plan de Desarrollo, que debe ser aprobado por el clien-
te y el diseñador. El plan de desarrollo no es más que una planificación detallada
del proyecto en sus aspectos organizativos. Cuando el diseño es pequeño o poco
crítico, el plan de desarrollo, aunque interesante, puede no ser necesario. Para dise-
ños grandes o críticos, que deben ser coordinados con el desarrollo del resto del sis-
tema, su elaboración resulta imprescindible. A menudo surgen problemas debido a
la falta de definición inicial de las responsabilidades y los procedimientos de con-
trol del proyecto. Podríamos encontrar, por ejemplo, que un cliente poco experto en
diseño no se sienta capacitado para analizar las simulaciones de los modelos VHDL
tras el diseño arquitectural. El diseñador, por su parte, podría no querer admitir la
responsabilidad de validar el diseño sin que el cliente verifique por su cuenta el de-
sarrollo. Si el cliente dispone de modelos VHDL con los que validar el diseño, el
problema queda resuelto; si no, habrá que encontrar el procedimiento (prototipos,
revisiones más prolongadas, formación del cliente en el diseño, etc.) para solventar
el problema. En otras ocasiones, el cliente podría exigir unos métodos y herramien-
tas de trabajo para los que el diseñador no está preparado (por falta de formación o
de equipo). Anticiparse a estos problemas y resolverlos antes de que el proyecto es-
té realmente en marcha evitará sorpresas desagradables.
Por otro lado, el plan de desarrollo puede incluir los procedimientos que se
van a seguir para realizar el diseño. La Figura 6-4 muestra un flujograma de los pa-
sos a seguir para realizar un diseño con unas determinadas herramientas. Este flujo-
grama, aunque complejo, sirve para resaltar el gran número de programas (en gris
claro), acciones (en gris oscuro) y revisiones que deben realizarse en ocasiones. Co-
mo se puede imaginar, no es difícil olvidarse algún paso o cometer algún error. El
tener estos procedimientos documentados ayuda no sólo a evitar errores sino tam-
bién a facilitar la tarea a los diseñadores menos expertos en el flujo de diseño.
El contenido del Plan de Desarrollo es muy variable, aunque existen una serie
de puntos que deben incluirse en la mayoría de los casos. La Tabla 6-4 muestra un
esquema de lo que puede ser el esqueleto del documento. Es importante hacer notar
que, aunque no se considere necesaria la elaboración de dicho documento, sí con-
viene plantearse estos puntos al principio del proyecto para garantizar que no surjan
problemas más adelante.
Otro aspecto importante a cubrir durante la etapa de especificaciones es la ela-
boración del plan de pruebas. El objetivo del Plan de Pruebas es definir cómo se va
a realizar la validación del diseño. Las simulaciones son el procedimiento habitual
de validación, pero no son adecuadas en todos los casos. En ocasiones será necesa-
rio realizar un prototipo del circuito completo o de parte del mismo. En otros casos
puede necesitarse algún otro programa para validar los resultados de las simulacio-
nes. Como ejemplo podemos pensar en el diseño de un filtro digital. Para compro-
bar que los resultados son correctos podríamos seguir un procedimiento como el
mostrado en la Figura 6-5.
En este procedimiento, los datos de entrada son generados por un programa es-
pecífico para generar unas formas de onda con unas determinadas características.
Los mismos datos son pasados al modelo VHDL del circuito y a un programa de
FIGURA 6-4. Ejemplo de flujo de diseño aplicado a herramientas comerciales con-

cretas.
análisis matemático que incluye funciones de filtrado digital (con lo que evitamos
que el diseñador desarrolle al mismo tiempo el circuito y los bancos de prueba, dis-
minuyendo el riesgo de cancelación de errores). Los resultados son mostrados me-
diante funciones gráficas del programa de análisis matemático y se calculan los
errores relativos (del circuito respecto al programa).
De nuevo, definir al principio del proyecto cómo se van a realizar las pruebas,
obliga a plantearse posibles fuentes de problemas y a realizar una mejor planifica-
ción del trabajo. Todo ello redundará en un proceso de diseño más fluido y un resul-
tado de mayor calidad.
6.2.2.2.5. El equipo de diseño

La organización del equipo de diseño es un aspecto clave para la correcta consecución
de lID diseño, especialmente cuando el equipo es numeroso. El equipo estará com-
TABLA 6·4. Plan de desarrollo.
ESQUEMA DEL PLAN DE DESARROLLO

Planificación del diseño
Flujo de diseño y verificación
Revisiones del diseño
Fabricante y biblioteca
Herramientas utilizadas
Pormato de intercambio de información
Estrategia de test y cobertura
Convenios sobre numeración y nombres
Documentación del diseño y listas de distribución
Organizaci6n del equipo de diseño
Planificación temporal considerando las dependencias de los bloques
Definición de responsabilidades y partición del trabajo
Organización de la biblioteca
Flujo de diseño y verificación
puesto básicamente por el Director, responsable del proyecto, y los diseñadores. Ha-
bitualmente es necesario contar con un experto en la aplicación donde va a integrarse
el diseño. Este experto puede formar parte del equipo de diseño o ser parte del equipo
del cliente. En cualquier caso, lo consideraremos integrante del equipo de diseño.
Las principales cuestiones que deben resolverse desde el punto de vista del
equipo de diseño son la asignación de tareas y la coordinación del equipo de diseño
durante el desarrollo .
•
Programa Mat~
~ - -_
Resultados
•-
Modelo Funcional
Ficheros Dal~
- Resultados
Modelo VHDL del Modelo ASIC
ASIC
Resultados
Patrón
FIGURA 6-5. Ejemplo de validación de los resultados de la simulación de un cir-

en VHDl.
cuito descrito
En la asignación de tareas debe reflejarse la experiencia de cada diseñador tan-

to en la aplicación como en las herramientas utilizadas para el diseño. Los dise-
ñadores más expertos en la aplicación deberán estar a cargo de las etapas de más
alto nivel, como son las especificaciones y el diseño arquitectural. Por otro lado, los
diseñadores más expertos en las herramientas (VHDL, herramientas de diseño físi-
co, etc.) estarán más indicados para las tareas de diseño lógico y diseño físico.
Existen dos tareas adicionales que a menudo requieren un perfil muy específico
por parte de los diseñadores: el modelado del entorno y la elaboración del programa
de test. Para el modelado del entorno se necesita un diseñador especialmente exper-
to en VHDL, ya que debe realizar un modelo lo más fiel posible, y que al mismo
tiempo consuma pocos recursos a la hora de simularlo. Por otro lado, debe ser ca-
paz de abstraer cuáles son las características del entorno que influyen sobre el dise-
ño y que, por tanto, deben modelarse con precisión. En cuanto a la elaboración del
programa de test, éste requiere un diseñador especialmente experto en el diseño de
bajo nivel y que al mismo tiempo conozca con detalle el circuito que se está dise-
ñando. Sin embargo, en este caso no es necesario que sea un experto en VHDL.
A menudo no se dispone de diseñadores con el perfil ideal para cada tarea, por
lo que será necesario una coordinación adecuada para sacar el máximo provecho al
equipo de diseño y minimizar el tiempo empleado en el desarrollo.
La coordinación del equipo de diseño debe establecerse a diferentes niveles. En
primer lugar, deben fijarse reuniones periódicas que permitan evaluar el estado del
proyecto y aplicar medidas correctivas cuando sea necesario. En segundo lugar,
deben establecerse normas internas y reglas de diseño que faciliten la futura inter-
conexión de los bloques. En el Apéndice 11(sobre Normas de codificación y mode-
lado) se muestra un ejemplo de este tipo de normas. Seguir este tipo de reglas no
sólo va a permitir una integración fácil de los diferentes módulos que componen el
diseño, sino que además permitirán un posible cambio en la asignación de tareas, ya
que todos los diseñadores trabajarán con un estilo homogéneo. Por último, los dise-
ñadores deben elaborar una documentación adecuada de su trabajo, que sea fácil-
mente integrable en los documentos finales del proyecto.
Una última cuestión a la que debe estar atento el director del equipo de diseño
es la formación de los diseñadores. La constante evolución de las herramientas y
técnicas de diseño obliga a mantener un esfuerzo continuado de actualización de
conocimientos. Esto debe ser tenido en cuenta para que no repercuta negativamente
sobre los diseños.
Como en cualquier otro proyecto, la coordinación del equipo de diseño requie-
re un esfuerzo importante por parte del director. El conocimiento profundo del pro-
ceso de diseño y la utilización de técnicas clásicas como la realización de gráficos
tipo GANTT o PERT pueden facilitar en gran medida esta tarea.
6.2.3. El diseño arquitectural y lógico
En el proceso de diseño basado en VHDL y síntesis automática el diseño se realiza

fundamentalmente durante las etapas de diseño arquitectural y lógico. Estas son
normalmente las etapas que requieren un mayor esfuerzo y tiempo.
6.2.3.1. Desarrollo del diseño arquitectural
La etapa de diseño arquitectural puede ser entendida como una etapa de transición
entre las especificaciones y el diseño lógico del circuito. El objetivo fundamental
de la etapa de diseño arquitectural es obtener una jerarquía de módulos en la que
los bloques funcionales estén definidos de manera que sean compatibles a nivel de
ciclos de reloj (en el caso de diseños síncronos) con el diseño final. El diseño así
dividido deberá cumplir con las restricciones planteadas en la etapa de especifica-
ciones y ser óptimo en cuanto a los parámetros del diseño (temporales, de área y
consumo). Para ello deben investigarse distintas alternativas de diseño y escogerse
la más adecuada. Durante esta etapa se desarrollarán también unos bancos de prue-
ba del circuito completo que puedan ser utilizados en posteriores etapas del desa-
rrollo.
El resultado fundamental de la etapa de diseño arquitectural es el modelo
VHDL del circuito. Este modelo habrá permitido simular el comportamiento del
circuito frente al resto del sistema y analizar las posibles alternativas para su reali-
zación. El modelo VHDL contendrá una descripción a nivel de transferencia de
registros (nivel RT) del circuito. Su comportamiento será casi real. Aunque no in-
cluya los retardos reales de las puertas y del interconexionado, la evolución de las
señales en cada ciclo de reloj será igual a la del circuito una vez fabricado (siempre
que se sigan unas normas de diseño síncrono y se garantice en la fase de síntesis
que las entradas a los registros cambien antes de la llegada de un nuevo flanco de
reloj).
6.2.3. 1. 1. Modelos sintetizables o no sintetizables
Para la realización del modelo arquitectural en VHDL cualquier estilo de descrip-

ción es válido. Sin embargo, deben tenerse en cuenta que existen dos objetivos
contrapuestos que es necesario armonizar. Por un lado, la elaboración de los mo-
delos VHDL debería ser lo más rápida y sencilla posible. De esta manera el dise-
ñador se concentrará más en la funcionalidad y no en la manera de codificarla en
VHDL. Por otro lado, los modelos deben estar hechos de manera que su transfor-
mación en modelos sintetizables (recuérdese que no todos los estilos son acepta-
bles por las herramientas de síntesis) durante la etapa de diseño lógico sea también
sencilla.
Para conseguir esto se considera habitualmente que tras la etapa de diseño ar-
quitectural debe haberse obtenido una descripción sintetizable del circuito, aunque
los resultados de la síntesis no sean óptimos. Sin embargo, no siempre es sencillo
realizar una descripción sintetizable del circuito. Los subconjuntos del VHDL que
aceptan las herramientas de síntesis son, en ocasiones, muy limitados, e imponen un
estilo de descripción que resulta engorroso durante esta etapa. Como ejemplo puede
considerarse la descripción mostrada en el Listado 6-3. El código refleja el modelo
de un banco de registros en el que se puede escribir o leer un determinado registro
activando adecuadamente la señales de lectura/escritura.
entity BANCO_REGS la
generic(
gNumBits integer ;= 8;
gNumRegs integer := 4;
);
port(
Reloj in std....logic;
InicioN in std•..logic;
LeeEscrN in std._logic;
Registro in irtteget range O te gNtunRegs - 1;
Entrada in std_logic_vector(gNumBits - 1 downto O);
Salida out std_logic_vector(gNumBit!t - 1 downto Ó)
);
end BANCO_REGS;
architecture COMPORTAMENI'AL of BANCO_REG la
type RegType ls std_logic_vector(gNUmBits - 1 downto O);

type BancoRegsType is array(gNtunRegs - 1 downto O) of RegType;
begin
Banco: process (Reloj, Inicjo)

variable BancoRegs : BancoRegsType;
begin
if InicioN = 'O' then
BancoRegs := (others => (others => 'O'));
elslf Reloj'event and Reloj = '1' then
lf LeeEscrN = 'O' tben
BancoReg(Registro) := Entrada;
else
Salida <= BancoReg(registro);
end if;
endif;
end process;
end COMPORTAMENTAL;
LISTADO 6-3. Banco de registros descrito en VHDL, no sintetizable.
En esta descripción, a nivel RT, se ha utilizado un estilo de descripción que po-

dríamos llamar algorítmico. El banco de registros es un vector bidimensional al que
se accede a través de un Índice. Como se observa, la descripción es fácil de realizar
y comprender. Esta descripción, sin embargo, no es sintetizable por muchas herra-
mientas de síntesis actuales. Para ello podríamos habemos visto obligados a realizar
una descripción como la mostrada en el Listado 6-4.
entity BANCO_REGS
is
port(
Reloj in std_logic;
Inicic1l in st<Llogic;
LeeEscrN in std,_logic;
Regis;ro in integer ranga O to 3;
.Entrada in std,_logic_vector(7 downto O);
salida out std,_logic_v~ctor(7 downto O)
);
end BANCO_REGS;
architecture of BANOD_REG
COMPORTAMENTAL 1s
OOgin
Banco: process (Reloj, ~cio)

variable BancoRegsO stst_log.ic_vector(7 downto O);
variable BancoRegsl "Std_logic_vector (7 downto O);
variable BancoRegs2 std_logic_vector (7 downto O):
variable BancoRegs3 std,_logic_vector(7 downto O):
begin
if InicieN = 'o' then
BancoRegsO .- '00000000";
BancoRegs1 .- "00000000";
BancoRegs2 ._ ·0,0.0000007;
BancoRegs3 .-;- "00000000"1
e1s1f Réloj'event and Reloj '1' then
if LeeEscrN· = 'O' then
case Registro 1s
when 0-'=> BancoRegO := Entrada;
when 1 => BancoRegl :,,;. Entrada;
when 2 => BancóReg2 ~:= Entrada;
when 3 => BancoReg3 := Entrada;
end case;
else
case Registro 1s
when O => Entrada <= BancoRegO;
when 1 => Entrada <= BancoRegl;
when 2 => Eqt~ f= ~SOReg2;
when 3 => Entrada <= BancoReg3;
end case;
end if¡
end if¡
end process;
end COMPORTAMENTAL;
LISTADO 6-4. Banco de registros descrito en VHDL. Sintetizable.

En el segundo caso la herramienta no permitiría el uso de vectores bidimensio-

nales, por lo que habría que describirlos explícitamente. Evidentemente, esta des-
cripción es más difícil de realizar y de interpretar.
Este tipo de situaciones se dan a menudo durante la etapa de diseño arquitectu-
ral. Realizar una descripción utilizando toda la potencia que nos ofrece el VHDL
facilita y acelera el trabajo. Por tanto, se intentará hacer la descripción a nivel RT
sin que eso obligue a que sea sintetizable, y aprovechando las facilidades que nos
da el VHDL. Sin embargo, hay que evitar que aparezcan problemas durante el paso
del modelo a uno sintetizable. Como ejemplo, obsérvese el segmento de código del
siguiente listado.
if Reloj' event and LeeEscrN = ' l' then

Registro := Entrada;
else
Salida := Registro;
end process;
LISTADO 6-5. Descripción VHDL no sintetizable.
En esta descripción, Registro cargaría datos tanto en el flanco de subida como

en el de bajada de la señal Reloj (podríamos encontrarlo interesante para nuestro
diseño). Cuando intentásemos hacer una descripción sintetizable del circuito nos
encontraríamos con la desagradable sorpresa de que no es posible. Esta limitación
no es debida a las herramientas de síntesis, sino a que no existen normalmente bies-
tables que funcionen de tal modo. Eso obligaría a cambiar el diseño arquitectural,
haciendo que el circuito sólo funcione en flanco de subida o de bajada.
La conclusión es que deben hacerse descripciones de circuitos que sean sinteti-
zables en un sentido físico, es decir, que debe existir alguna circuitería que se com-
porte como el modelo realizado. Esto es una constante en todo diseño VHDL orien-
tado a síntesis; debemos utilizar el VHDL para describir un circuito que ya sabemos
cómo realizar físicamente. El VHDL no es más que un método para acelerar el pro-
ceso de diseño, una forma mejor que los esquemáticos para describir un circuito,
pero no evita que el diseñador tenga que elaborar en su cabeza el esquema básico
del circuito a realizar.
6.2.3. 1.2. La biblioteca del fabricante

Un aspecto que se debe tener especialmente en cuenta durante la etapa de diseño ar-
quitectural es la tecnología escogida para el diseño. De la tecnología va a depender
fundamentalmente la biblioteca de la que dispongamos, y de ésta, la facilidad con
que diseñemos unas u otras partes del circuito. Un determinado fabricante podría dis-
poner de una biblioteca en la que hubiese tanto componentes digitales como analógi-
cos, podría disponer de generadores de macroceldas (RAM, ROM, PAL, etc.), ge-
neradores optimizados de estructuras más complejas (multiplicadores, data-path,
etc.) e incluso celdas de gran complejidad (controladores, filtros, etc.). El tener
acceso a estos elementos de biblioteca puede ser indispensable en algunos casos para
poder realizar el diseño. En otros, simplemente facilita su desarrollo. Sea como fue-
se, es conveniente saber de qué elementos disponemos para no desarrollar algo que
ya está hecho, o para considerar el coste de su utilización (los fabricantes suelen
facturar una cierta cantidad por el uso de su biblioteca, o por el uso de algunos
componentes de ésta).
6.2.3. 1.3. Los bancos de prueba

Uno de los resultados fundamentales de la etapa de diseño arquitectural, además
del diseño preliminar del propio circuito, son los bancos de prueba. En este caso,
el objetivo fundamental es conseguir unos bancos de prueba que sean válidos a lo
largo de las posteriores etapas de refinamiento del diseño. La elaboración de los
bancos de prueba es, de hecho, una 'de las tareas más críticas dentro del proyecto.
Un diseño con unos bancos de prueba inadecuados es un diseño poco comproba-
do y, por lo tanto, un diseño no válido. Cuanto más exhaustivo sea el plan de
pruebas, existirán mayores garantías de que no quede algún error de diseño sin
detectar.
Si es posible, el banco de pruebas deberá ser elaborado por un diseñador dife-
rente al que ha realizado el diseño. De esta manera se evita la cancelación de posi-
bles errores de interpretación de las especificaciones.
Podríamos plantear dos métodos básicos para afrontar la elaboración de los
bancos de prueba: los bancos de prueba orientados al modo de funcionamiento y los
orientados a la señal.
En el primer caso debe establecerse un procedimiento donde, para cada modo
de funcionamiento del módulo que se esté comprobando, se elabore un banco de
prueba (o varios) que verifique que cada señal de salida del módulo responde
de forma adecuada.
En el caso de los bancos de prueba orientados a la señal, debe establecerse un
procedimiento donde, para cada señal de salida del módulo que se esté comproban-
do, se elabore un banco de prueba (o varios) que verifique que la señal responde de
forma adecuada ante cada modo de funcionamiento.
En general, los bancos de prueba orientados a la señal son más sistemáticos y
exhaustivos. Además, puesto que normalmente el diseñador plantea el desarrollo de
un determinado módulo pensando en los modos de funcionamiento, el utilizar un
procedimiento orientado a las señales asegura una comprobación cruzada. Por otro
lado, es un procedimiento más sencillo de automatizar, aunque en algunos casos
puede ser excesivamente costoso. Escoger un método u otro dependerá de las prefe-
rencias de los diseñadores.
Al elaborar un banco de pruebas debe verificarse que se ha comprobado el fun-
cionamiento del diseño ante todas las posibles situaciones bajo las que el circuito va
a funcionar. Aunque cada circuito es diferente, existen una serie de situaciones co-
munes que hay que verificar. Los siguientes puntos describen estos casos:
• Inicializaciones: es necesario verificar que el circuito se comporta correcta-

mente después de una inicialización. Hay que comprobar especialmente que
los registros y las señales se inicializan adecuadamente bajo cualquier condi-
ción de partida. Por ello es necesario que los bancos de prueba incluyan ini-
cializaciones no sólo al principio de las simulaciones, sino también en cual-
quier situación de funcionamiento.
• Terminaciones: la mayoría de los circuitos funcionan de forma cíclica; los
módulos que lo integran presentan una funcionalidad que es iniciada al cum-
plirse una serie de condiciones y/o activarse una serie de señales, y que es
terminada de forma autónoma o externa. Tras la terminación del ciclo, las se-
ñales y registros deben quedar con los valores adecuados para poder comen-
zar un nuevo ciclo. Podríamos pensar, por ejemplo, en un transmisor serie.
La transmisión comienza al activar una determinada señal y termina automá-
ticamente cuando el dato ha sido enviado. Tras la transmisión, el circuito de-
be quedarse en la misma situación que cuando empezó, preparado para trans-
mitir un nuevo dato. Es, por tanto, necesario verificar que las señales y regis-
tros internos del módulo quedan con los valores adecuados.
• Funcionamiento no considerado: aunque el circuito esté integrado en un
sistema perfectamente conocido, puede que se produzcan situaciones no con-
templadas (podría estropearse alguno de los sistemas con los que interactúa).
Por ello, es necesario realizar un esfuerzo de comprobación para considerar
los casos no previstos en las especificaciones y que puedan dar paso a com-
portamientos no deseados. Casos típicos son inicializaciones en medio de un
ciclo de funcionamiento, asincronismo en algunas señales, relanzamiento de
un ciclo (p. ej., intentar enviar un dato en un transmisor serie cuando aún es-
tá enviando el anterior), etc.
• Valores no considerados: el funcionamiento de un circuito o módulo puede
ser erróneo si aparece en sus entradas alguna combinación de señales no pre-
vista, tanto en señales de configuración como en datos internos o en valores
de las señales de entrada (lo que probablemente daría funcionamientos no
considerados).
6.2.3. 1.4. Resultados del diseño arquitectural

Como se ha indicado al principio de este apartado, el objetivo del diseño arquitectu-
ral es obtener una descripción del circuito que esté a mitad de camino entre el dise-
ño final y las especificaciones. Trabajando de esta manera podremos verificar que
el funcionamiento del circuito es el deseado, sin dedicar un gran esfuerzo a los de-
talles del diseño lógico. Al mismo tiempo, la descripción debe ser lo suficientemen-
te cercana al diseño final como para que no surjan sorpresas durante el diseño lógi-
co que impliquen un cambio de la filosofía del diseño.
Desde un punto de vista técnico, tras el diseño arquitectural debemos obtener
los modelos RT del circuito y los modelos (de cualquier forma) de los bancos de
prueba que utilizaremos a partir de entonces.
6. La gestíón del díseño 381
Sin embargo, estos modelos no son el único resultado que se debe obtener de
esta etapa. Como en cualquier fase del diseño, el diseño arquitectural debe quedar
correctamente documentado para poder utilizar el trabajo en posteriores etapas.
Para ello deberemos redactar el Documento de Diseño Arquitectural. Al igual que
se hizo en la etapa de especificaciones, el objetivo del documento es describir, en
lenguaje natural y con la ayuda de gráficos y cronogramas, el funcionamiento del
circuito (el modelo) y los bancos de prueba. El contenido y extensión del docu-
mento dependen, de nuevo, del tipo de proyecto en el que se esté trabajando. Si se
trabaja en proyectos de cierta complejidad, donde a menudo colaboran varios dise-
ñadores, el Documento de Diseño Arquitectural adquiere una gran importancia. Su
redacción, como la del Documento de Especificaciones, debe ser especialmente
cuidada. Este documento, junto con el código VHDL, servirá de referencia para las
posteriores etapas. Si se ha redactado correctamente, facilitará en gran medida el
trabajo. En proyectos de baja complejidad, o cuando el diseñador es el mismo du-
rante las etapas de diseño arquitectural y detallado, el Documento de Diseño Ar-
…itectural es menos crítico. Sin embargo, su redacción presenta dos grandes ven-
tajas. En primer lugar, facilita el trabajo posterior. En segundo lugar, sirve como
documento base para elaborar la documentación final del diseño (las hojas de ca-
racterísticas y la descripción del circuito), por lo que siempre es un trabajo que se
aprovechará.
El Documento de Diseño Arquitectural, aunque específico de cada circuito,
responde casi siempre a un mismo esquema. La Tabla 6-5 muestra un índice genéri-
co de un documento típico de diseño arquitectural.
En el Apéndice 1puede encontrarse el Documento de Diseño Arquitectural pa-
ra la máquina de refrescos de nuestro ejemplo. Aunque en este caso su extensión se
ha reducido para incluirla en el texto, puede valer como ejemplo del aspecto que
presenta un documento de este tipo.
Obsérvese que en el documento se ha incluido también una descripción de los
bancos de prueba y su funcionalidad. Aunque en sí los bancos de prueba no forman
parte del circuito, su descripción facilitará la comprensión de los mismos por parte
de los participantes en las siguientes etapas del diseño. Además, permitirá verificar
que los bancos de prueba responden a las especificaciones (simulan el entorno del
circuito).
6.2.3.2. La revisión del diseño arquitectural
Terminada la etapa de diseño arquitectural deben revisarse los resultados obtenidos

hasta el momento. La revisión de esta etapa es especialmente importante, ya que a
partir de este momento las modificaciones al diseño tendrán un coste cada vez más
alto.
La revisión del diseño arquitectural cumple dos cometidos; uno técnico (revisar
la funcionalidad del diseño) y otro organizativo o metodológico (revisar cómo se ha
hecho el diseño y 10 ajustado que está al plan de desarrollo).
Desde el punto de vista técnico, la revisión del diseño arquitectural supone una
nueva comprobación del trabajo realizado por los diseñadores. Se debe verificar que
TABLA 6-5. Esquema del documento de diseño arquitectural
ESQUEMA DEL DOCUMENTO DE DISEÑO ARQUITECTURAL
Introducción
Documentos aplicables y de referencia
Discrepancias con el documento de especificaciones
Glosario
Terminología usada
Descripción arquitectural
Particionado del diseño y justificación
Identificación de bloques de la biblioteca aptos para ser utilizados
Identificación de bloques susceptibles de ser incluidos en la biblioteca
Diagrama de bloques actualizado y de E/S del diseño
Interacción entre bloques
Caracterización de señales internas
Estrategia de test global
Descripción detallada (para cada bloque funcional)

Descripción general del bloque
Diagrama de E/S del bloque
Funcionalidad detallada del bloque
Diagramas y codificación de estados
Formato de los datos y protocolos de comunicación internos
Codificación de registros internos
Codificación de los datos internos
Breve descripción del modelo VHDL
Estrategia de test del bloque
Descripción del test funcional

Simulaciones realizadas y resultados
Matriz de cumplimiento de las especificaciones
APÉNDICE: Códigos VHDL del circuito y bancos de prueba
lo realizado cumple con las especificaciones, y si no es así, justificar las diferencias

y la nueva solución. Normalmente este trabajo ya habrá sido realizado por el diseña-
dor e incluido en el Documento de Diseño Arquitectural, por lo que no debería
requerir demasiado esfuerzo. En la revisión del diseño arquitectural deberían partici-
par tanto el diseñador como el cliente. Es precisamente el cliente quien debe asegu-
rarse de que el diseño satisface totalmente sus requisitos y debe dar el visto bueno al
diseño.
Desde el punto de vista organizativo y metodológico, la revisión debe verificar
que el diseño ha sido realizado de forma adecuada y que los plazos fijados siguen
siendo válidos. Hay que comprobar que el código VHDL ha sido escrito de forma
correcta; es decir, que se ha elaborado un código de calidad. Esta revisión implica
comprobar los siguientes puntos:
• Estilo de codificación y nomenclatura: aunque la forma de nombrar las

señales y escribir el código no tiene por qué influir en la funcionalidad del
diseño, utilizar un mal estilo de codificación hace perder muchas de las venta-
jas del VHDL. Podemos comparar las descripciones del Listado 6-6. Eviden-
temente, la segunda descripción es mucho más clara. La primera descripción
difícilmente podrá ser utilizada por un diseñador distinto al que la realizó (o
por quien la diseñó, al cabo de tres meses).
process uno (a, b)

begio
if b = 'o' then
c <= (others => 'O');
else _7
c <= (others => 'O');
fer i in O te 7 loop
if a = i then
c (i) <= '1';
end if;
end loop;
end if;
end process;
process de!nux(seleccion, habiH~): .:

begio
if habilita = 'o' then
salida ~= (others => 'O;);
else
salida <= (others => 'O');
fer i in O te NumSalidas - 1 loop
if selección = i then
salida(i) <= '1';
end if;
end loop;
end if;
end process;
LISTADO 6-6. Estilos de nomenclatura.
• Estilo de descripción: normalmente se considera que las descripciones

VHDL deben ser comportamentales o estructurales, pero no una mezcla de
las dos. Hacerlo así facilita la escritura del código y su depuración.
• Utilización de puertos, señales, variables y genéricos: como resultado del
proceso de diseño, a menudo se definen señales, variables, etc., que son utili-
zadas durante un cierto tiempo y luego son desechadas al encontrase una so-
lución mejor o más elegante. Conviene revisar que en el código no quedan
estos objetos definidos y no utilizados. Si bien no suponen un error en el di-
seño, sí dificultan la lectura y depuración del código. Un diseñador ajeno al

diseño encontraría señales definidas que no sabe para qué se utilizan. Por
otro lado, esta revisión permite identificar posibles olvidos u omisiones y da
como resultado un código de mayor calidad.
• Comprobación de valores constantes en el código: en todo diseño apare-
cen valores constantes que reflejan alguna característica del circuito que se
está realizando. Estos valores responden a aspectos como el ancho de un bus,
la cuenta final de un contador, el número de registros de un banco de regis-
tros, etc. Conviene revisar que estos valores no aparecen reflejados como
números en el código, sino como constantes que habrán sido definidas previa-
mente. Esto responde a dos objetivos; por un lado, facilita la lectura del códi-
go; por otro, facilita las modificaciones posteriores, ya que el valor sólo es
corregido en un sitio. En el apartado sobre diseño genérico se discutirá este
tema más a fondo.
• Comprobación de las listas de sensibilidad: en los diseños realizados en
VHDL, una fuente frecuente de problemas son las listas de sensibilidad de
los procesos. Como se ha visto en capítulos previos, los procesos en VHDL
que poseen listas de sensibilidad sólo son evaluados cuando se produce un
evento en alguna de las señales de la lista. Esto puede producir diferencias
entre lo simulado y lo sintetizado, ya que los sintetizadores generan un hard-
ware que responde a todas las señales que se lean en el proceso, ignorando lo
que aparezca en la lista de sensibilidad. El Listado 6-7 presenta un ejemplo.
La descripción VHDL, una vez sintetizada, producirá un circuito que no se
comportará igual que el de la simulación. Los sintetizadores avisan de este
riesgo, pero a menudo estos avisos no son tenidos en cuenta (aunque no es
correcto, uno acaba por no mirar la cantidad de información que le devuel-
ven las herramientas de síntesis). Es necesario entonces revisar que las listas
de sensibilidad son correctas para evitar problemas posteriores.
process MuxErroneo(Seleccion)
begin
if Seleccion = '1' then
salida <= Entrada_1;
else
salida <= Entradq_O;
end if;
end process;
LISTADO 6-7. Lista de sensibilidad errónea.
Ejercicio 6.1-
Dibujar el circuito resultante de la síntesis del código del Listado 6-7 Y las formas
de onda resultantes de la simulación.
Selección .....1 L
Entrada_O Entrada_O ___fl___f"L___J
Salidas
Entrada_1~
Entrada_1
salidassíntesis~
Salidas simuladas ---------_
La revisión de estos aspectos suele ser llevada a cabo por los diseñadores (nor-
malmente por el director del equipo de diseño). Como se observa, su objetivo final
es facilitar las tareas posteriores y la reutilización del diseño. Un código VHDL
bien escrito es un código fácil de leer y de depurar. Las modificaciones posteriores
implicarán poco trabajo y el riesgo de errores disminuirá.
Los últimos aspectos del diseño arquitectural a revisar son los relacionados con
la organización del proyecto, siendo el más importante el referente al cumplimiento
de plazos. En este punto del diseño se tendrá una idea mucho más precisa de la
complejidad del proyecto y su evolución. Se deberán aplicar las medidas necesarias
para cumplir el plan de trabajo planteado inicialmente y, si fuese necesario, se rea-
justarán las tareas y plazos para solucionar posibles problemas. En este sentido, es
el cliente quien debe tomar las decisiones finales sobre cualquier modificación a la
planificación del proyecto.
6.2.3.3. Desarrollo del diseño lógico
El objetivo del diseño lógico es obtener una descripción del circuito lo suficiente-
mente detallada como para servir de entrada a las herramientas de diseño físico. El
trabajo fundamental de esta etapa consistirá en la síntesis de las descripciones
VHDL y la optimización de la lógica para conseguir las prestaciones deseadas. La
optimización de la lógica se hará a dos niveles: previamente a la síntesis (modifi-
cando el código VHDL) y tras la síntesis (imponiendo restricciones temporales, de
área o consumo). La ejecución de esta etapa requiere la selección del fabricante y la
tecnología en la que se implementará el circuito.
6.2.3.3. 1. La selección de la tecnología

Desde un punto de vista teórico, la selección de la tecnología podría retrasarse hasta
esta etapa. Hasta este momento el diseño ha sido independiente de la tecnología; los
modelos arquitecturales no poseen normalmente información respecto a una biblio-
teca particular de componentes, sino que describen el comportamiento del circuito
en términos de registros y operaciones lógicas. Sin embargo, retrasar la selección de
la tecnología hasta esta etapa puede acarrear ciertos inconvenientes. En primer lu-
gar, puede ocurrir que la tecnología escogida no satisfaga los criterios de área, fre-
cuencia de funcionamiento o consumo requeridos. Si la tecnología se ha selecciona-
do con antelación, se podrán realizar algunas pruebas de aquellas partes que se con-
sideren más críticas con objeto de estimar si van o no a cumplir con las restriccio-
nes. Estas pruebas podrán realizarse durante la etapa de diseño arquitectural, o
incluso durante la etapa de especificaciones, previendo posibles problemas y
actuando en consecuencia.
Por otro lado, desconocer la tecnología objetivo puede hacer que desarrollemos
celdas o componentes de forma inadecuada. Como ejemplo podemos fijarnos en el
desarrollo de un banco de registros de un microprocesador sencillo. Si disponemos
de una biblioteca que contenga generadores de memorias bipuerto es posible que
podamos implementar el banco de registros mediante este tipo de memorias con
unos buenos resultados en cuanto al área final del circuito. Si dichas celdas no están
disponibles en la biblioteca, o desconocemos su existencia, no quedará otro reme-
dio que implementar el banco de registros mediante biestables, lo que resultará en
un coste elevado de área. De igual manera podría ocurrir que nos dedicásemos a de-
sarrollar celdas (puertos paralelo, transmisores/receptores serie, multiplicadores, fil-
tros, etc.) que ya estuviesen disponibles en la biblioteca, o que fuesen accesibles a
un coste razonable como macroceldas ya desarrolladas.
En cualquier caso, es importante asegurarse de que los componentes de biblio-
teca que se vayan a utilizar posean modelos VHDL que nos permitan su integración
y simulación sin problemas en nuestro diseño.
6.2.3.3.2. La optimización del código

Normalmente, el código desarrollado durante la etapa de diseño arquitectural habrá
sido escrito sin considerar en detalle el diseño lógico (de hecho, éste es su objetivo).
Por tanto, habrá que modificar las descripciones para obtener un buen resultado tras la
síntesis lógica. En primer lugar, puede ocurrir que alguna de las descripciones realiza-
das no sea sintetizable con la herramienta de la que se disponga. Por otro lado, aunque
las descripciones sean sintetizables, puede que los resultados de la síntesis no sean los
más adecuados. Como ejemplo podemos fijarnos en el código del Listado 6-8.
process Contador (Reloj, Inicio)

variable auXCuenta : integer range O to cMaXCuenta;
begin
if Inicio = 'O' tben
auxCuenta := O;
e1sif Reloj'event and Relój ': '1' then
auxCuenta := auxCuenta + 1;
if awd::uenta = c:MaxCuénta tben
auxCuenta := O;
end if;
Cuenta <=·auxCuenta¡
end if;
end process;
LISTADO 6-8. Contador con registros redundantes.

El código refleja un contador síncrono implementado mediante un proceso en

el que la cuenta se lleva mediante la variable auxCuenta. La cuenta puede ser utili-
zada fuera del proceso al ser asignada a la señal Cuenta. Si sintetizamos esta des-
cripción se generarán dos registros, uno para almacenar la variable auxCuenta y
otro para la señal Cuenta. Aunque la descripción y el resultado tras la síntesis son
funcionalmente correctos, ambos registros contendrán la misma información, por lo
que serán redundantes. Esta descripción debería ser optimizada para eliminar uno
de los registros.
Ejercicio 6.2
Modificar el código del Listado 6-8 para que no genere registros redundantes.
Los registros en auxCuenta y Cuenta se generarán debido a que es necesario
mantener el valor de ambos objetos entre dos ciclos consecutivos del reloj. Si en ca-
da ciclo de reloj asignamos un nuevo valor a auxCuenta no será necesario mante-
ner el valor anterior, por lo que no se sintetizará un registro.
process Contador (ReYoj, Inicio)

variable auxCuenta : ipteger range O to cMaxCuenta¡
begin
if Inicio h ¡O' then
CUenta<= O;
elaif ,Reloj ':event aqd Re~9j",= '1' then '
auxCuenta .':= CUenta; ''-''''-al comenzar el ciclo daIrios
':_'tIíT huevo valor a partir de Cuenta
auxCuentat : =_é1~~~é1.+ 1;
if auxCuenta = cMaxCuenta then
aUXCuenta := Or
end if;
Cuenta" <= auxCuenta¡ :-- al
termi,Il?I el. ciclo asignamos el
-- nuevo valor calculado a CUenta
end if;
end process;
LISTADO 6-9. Modificación propuesta para el Listado 6·8.
Otro caso típico es la compartición de recursos. Como ejemplo podemos fijar-

nos en el código del Listado 6-10. En este caso el código refleja parte de una unidad
aritmética de un procesador.
process (Reloj, Inicio, ... )
begin
if Inicio = 'O' then
elsif Reloj' event and Reloj :: ¡ l' then

if Operacion·~ COD_OPDC then

A <= Dato,..?:.
+ Dato_C;
elsif OPe+'!-cion = COD_OPIR
B <= Dató_t + Dato_R;
end if;
end if;
end process;
LISTADO 6-10. Utilización de dos sumadores.
En el código, los registros A y B guardan el resultado de la suma de otras señales

del sistema. Si sintetizamos esta descripción encontraremos que se generan dos su-
madores, uno para calcular A y otro para calcular B. Pero si prestamos atención a la
descripción veremos que nunca se utilizan los dos sumadores al mismo tiempo (los
códigos de operación son excluytentes), sino que en función de una señal de selec-
ción se calcula A o B. Por lo tanto, es posible utilizar un mismo sumador para realizar
ambas operaciones (algunos sintetizadores pueden hacer esto automáticamente).
Ejercicio 6.3
Modificar el ejemplo del Listado 6-10 para que al sintetizarlo se utilice un solo su-
mador.
Una posible solución consiste en utilizar variables intermedias a la que se les
asigna el valor de los operandos en función del código de operación.
process (Reloj, Inicio ... )
variable OpI, Op2 : -- Definidas igual. que los Datos

variable Suma .••• -- Definida igúai que-oí.;13·
begin
Op_1 := Dato_D;
Op_2 := Dato_e;
if Operation = COD_OPIR then
Op_1 := Dato_I;
Op_2 : = nato_R;
end if;
Suma : = Op_1 + Op_2;
if Operación = COD_OPDC then
A <= Suma;
elsif Operaci~n = COD_OPIR then
B <= Suma;
end if;
end process;
LISTADO 6-11. Modificación propuesta para el Listado 6.10.

6.2.3.3.3. La repercusión de los cambios
En ocasiones las restricciones temporales o de consumo pueden implicar cambios

en el diseño arquitectural. Tomemos, por ejemplo, un diseño que debe funcionar a
una frecuencia elevada. Tras la síntesis podríamos descubrir que no satisface las es-
pecificaciones de velocidad. Esto podría implicar la necesidad de introducir seg-
mentación en las partes más críticas del diseño, lo que supone una modificación a
nivel arquitectural. A estas alturas del diseño, los costes de dichas modificaciones
son importantes, ya que se deben rediseñar los bancos de prueba, volver a realizar
las simulaciones, etc.
Para evitar este tipo de imprevistos es muy conveniente haber realizado algu-
nas pruebas previas que nos permitan llevar a cabo un diseño arquitectural ade-
cuado. La utilización de técnicas como el diseño genérico puede ayudar a paliar
los efectos de dichos cambios (permitiendo, por ejemplo, cambiar rápidamente el
número de estapas de segmentación necesarias, los ciclos de espera a un evento
lento, etc.).
Otra de las razones fundamentales por las que se realizan modificaciones en el
código es la introducción de lógica para test. Este es un aspecto difícil de conside-
rar durante la etapa de diseño arquitectural, ya que el test aplicable al circuito
depende en gran medida de la lógica utilizada para implementar cada función. La
inserción de lógica de test y obtención de los vectores de test puede hacerse de for-
ma automática con algunas herramientas (utilizando técnicas de test estructura-
das). Si no se dispone de dichas herramientas, habrá que resolver el problema del
test de forma manual. Este es un problema difícil, y bastante dependiente de la
aplicación.
6.2.3.3.4. Los resultados del diseño lógico
Como se ha indicado previamente, el objetivo del diseño lógico es obtener una des-
cripción lo suficientemente detallada como para servir de entrada a las herramientas
de diseño físico. Como hemos visto, este proceso consiste en modificar el código
(para eliminar lógica redundante, compartir recursos o satisfacer ciertas restriccio-
nes) y sintetizarlo con una determinada biblioteca suministrada por un fabricante.
Tras el proceso de síntesis (o en paralelo con éste), las herramientas permiten reali-
zar una optimización lógica que permita satisfacer los requisitos en cuanto a consu-
mo, área o frecuencia de funcionamiento. El proceso de síntesis habrá sustituido la
lógica descrita a nivel RT por un conjunto de puertas, biestables, y celdas básicas
que poseen la misma funcionalidad.
Tras el proceso de síntesis obtendremos una descripción estructural del circui-
to, que consistirá en una lista de celdas (pertenecientes a la biblioteca del fabrican-
te) e interconexiones (netlist). Esta descripción será la entrada a las herramientas de
ubicación y conexionado.
Durante toda esta etapa se habrán realizado modificaciones sobre el diseño (op-
timización del código). Será, por tanto, necesario realizar simulaciones que nos ase-
guren que la funcionalidad no ha cambiado. Para ello podemos utilizar los mismos
bancos de prueba que hemos desarrollado durante el diseño arquitectural. Tras la

síntesis, también es conveniente realizar estas simulaciones. Aunque normalmente
no hay problemas, puede ocurrir que el proceso de síntesis ofrezca resultados inco-
rrectos, por lo que conviene verificar, mediante simulación, que los resultados son
satisfactorios. Para realizar estas simulaciones será necesario obtener una descrip-
ción VHDL estructural del circuito sintetizado (casi todas las herramientas de sínte-
sis lo permiten) y disponer de los modelos VHDL de los componentes de la biblio-
teca del fabricante.
Las simulaciones que se realizan en esta etapa pueden incluir los retardos esti-
mados para la lógica del circuito. Aunque éstos no serán los retardos reales (falta
incluir los retardos debidos a las interconexiones), sí nos permitirán una simulación
más precisa del comportamiento temporal del circuito.
Como se ha venido comentando en los apartados previos, los resultados de ca-
da etapa deben ser convenientemente documentados. En el caso de la etapa de dise-
ño lógico, el documento debe incluir fundamentalmente las modificaciones realiza-
das a los códigos VHDL, la descripción del método utilizado para realizar el test de
fabricación y recomendaciones para la etapa de diseño físico. Todo esto quedará
recogido en el Documento de Diseño Lógico. La Tabla 6-6 muestra un posible
esquema del contenido de dicho documento.
6.2.3.4. La revisión del diseño lógico
Terminada la etapa de diseño lógico deben revisarse los resultados obtenidos hasta
el momento. La revisión del diseño lógico debe cubrir tres aspectos fundamentales:
revisar que la funcionalidad sigue siendo correcta, comprobar que se satisfacen los
requisitos en cuanto a prestaciones y verificar el test de fabricación. Además, al
igual que se hizo en la revisión del diseño arquitectural, deben verificarse los aspec-
tos organizativos del proyecto (cómo se ha hecho el diseño lógico y lo ajustado que
está al plan de desarrollo).
Para revisar la funcionalidad se habrán realizado simulaciones comparativas
entre los resultados del diseño arquitectural y el diseño lógico. Pero además, puesto
que ya se dispone de una estimación de los retardos de la lógica, se verificará que el
circuito sigue comportándose adecuadamente en las simulaciones en peor y mejor
caso (retardos máximos y mínimos), especialmente en los puntos que se consideren
más críticos.
En cuanto al test de fabricación, el proceso de revisión consiste en un análi-
sis de las partes del circuito que no han quedado suficientemente cubiertas por
el test de fabricación. La decisión sobre una posible mejora del test de fabrica-
ción depende en gran medida del tipo de aplicación a la que vaya dedicado el
circuito y de los recursos y tiempo necesarios para su modificación. Esta deci-
sión debe ser valorada convenientemente por el cliente y el Director del equipo
de diseño.
En cuanto a los aspectos organizativos y metodológicos del diseño, son apli-
cables los mismos comentarios que se hicieron para la etapa de diseño arquitec-
tural.
TABLA 6-6. Esquema del documento de diseño lógico
ESQUEMA DEL DOCUMENTO DE DISEÑO LÓGICO

Introducción
Documentos aplicables y de referencia
Discrepancias con el documento de diseño arquitectural y especificaciones
Glosario
Terminología usada
Descripciones globales
Biblioteca utilizada
Relación de PADs utilizados
Patillaje cuasi-definitivo
Encapsulado
Descripción de cada bloque del diseño arquitectural
Descripción general del bloque y E/S
Particionado, diagrama estructural y funcionalidad de los subbloques
Descripción de la circuitería de test'
Breve descripción del modelo VHDL
Restricciones utilizadas en síntesis
Descripción de los componentes de biblioteca utilizados
Descripción general del bloque y E/S
Restricciones y parámetros utilizados en síntesis
Verificación del test funcional
Simulaciones realizadas y resultados
Matriz de cumplimiento respecto al diseño arquitectural
Descripción del test de fabricación
Descripción del programa de test
Resultados de la simulación de fallos (cobertura y movilidad)
Test paramétricos a realizar
Análisis de resultados tras la síntesis (recomendaciones al diseño físico)
Máxima frecuencia de funcionamiento
Análisis estático de tiempos
Distribución y desfase del reloj
Problemas de Jan-out
APÉNDICE 1: Códigos VHDL del circuito
APÉNDICE 11: Programa y vectores de test (de fabricación)
APÉNDICE 111: Relación de advertencias obtenidas y justificación
6.2.4. El diseño físico y la fabricación

La etapa de diseño físico consistirá fundamentalmente en la ubicación y conexiona-
do de la lógica sintetizada durante el diseño lógico. Los datos de entrada a esta eta-
pa son básicamente la lista de componentes e interconexiones, la biblioteca del fa-
bricante y las recomendaciones para el diseño físico contenidas en el Documento de
Diseño Lógico. El trabajo de esta etapa suele estar bastante automatizado y no de-
bería plantear problemas para la mayoría de los circuitos. Sin embargo, cuando el
circuito trabaja a altas frecuencias de funcionamiento el tamaño de la lógica está li-
mitado (como en las FPGAs o matrices de puertas), o el consumo debe ser reduci-
do, pueden no conseguirse las prestaciones deseadas. Por otro lado, aunque las tare-
as a realizar durante el diseño físico están bastante automatizadas, a menudo existe
un salto brusco entre las herramientas utilizadas hasta el momento (simuladores y
sintetizadores) y las que se utilizarán en esta etapa. En ocasiones es necesario reali-
zar conversiones de formato, utilizar simuladores específicos del fabricante y resol-
ver todo tipo de problemas de interfaz entre herramientas. Como se ha comentado
previamente, realizar algunas pruebas durante las etapas de diseño arquitectural o
diseño lógico puede evitar sorpresas de última hora.
Tras la realización del diseño físico, será necesario realizar simulaciones del
circuito con los retardos debidos a las interconexiones. Estas simulaciones refleja-
rán con gran precisión el comportamiento real del circuito. Deben realizarse simula-
ciones en peor y mejor caso y verificar los puntos críticos.
El proceso de fabricación depende de la tecnología escogida. Si el circuito se va a
implementar mediante lógica programable (EPLDs, FPGAs), la programación se hará
normalmente en el centro de diseño. Si el circuito va a ser fabricado como un ASIC
(circuito integrado de aplicación específica), requerirá de unos prototipos iniciales an-
tes de pasar a producción. Esto debe tenerse en cuenta en la planificación del proyec-
to, ya que normalmente implica un retardo adicional de al menos uno o dos meses.
6.2.5. La validación y caracterización del circuito
Una vez fabricado el circuito, debe comprobarse su funcionamiento en el sistema

final. Las pruebas a realizar dependen de cada aplicación. Para sistemas sencillos,
puede no ser necesario realizar pruebas especiales, sino que será suficiente con ins-
talar el circuito en el sistema final y validar su funcionamiento con aplicaciones re-
ales. Sin embargo, en sistemas complejos, la validación puede requerir planes de
prueba específicos que, en muchos casos, no responderán a modos de funciona-
miento reales del sistema. Un ejemplo claro lo podemos ver en un microprocesador.
En este caso, ejecutar un programa real sobre el micro puede no darnos una total
garantía de que el sistema vaya a funcionar en todos los casos. Para ello deben rea-
lizarse programas especiales que vayan ejercitando cada parte de la lógica y del sis-
tema. En algunos casos será incluso necesario realizar tarjetas o circuitería adicio-
nal para comprobar fácilmente el funcionamiento.
La elaboración de estas pruebas debe tenerse en cuenta para no demorar la fi-
nalización del proyecto. Normalmente, estas pruebas pueden planificarse y diseñar-
se durante las etapas de diseño físico y fabricación. En estas etapas, el diseño va a
estar completamente definido y raramente se producirán modificaciones, por lo que
el trabajo dedicado a la elaboración de las pruebas finales no se verá afectado (sal-
vo, quizás, el patillaje definitivo).
Una de las últimas tareas a realizar sobre el diseño es su caracterización. Este
proceso, aunque no siempre se realiza, permite verificar que el comportamiento del
circuito responde a lo simulado. Los resultados de la caracterización nos permitirán

completar la documentación sobre el diseño y facilitarán la reutilización del compo-
nente en otros proyectos. Por otro lado, podremos utilizar los resultados de la carac-
terización para obtener un modelo en VHDL del componente. En la mayoría de los
casos será suficiente con introducir los retardos reales del componente sobre el mo-
delo RT que obtuvimos tras la etapa de diseño arquitectural. El siguiente listado
muestra un ejemplo sencillo de cómo hacerlo.
entity DEMUX is
port (
Sel in bit;
Ent in bit;
Sal_O out bit;
Sa1_l out bit
);
end DEMUX;
architecture NORMAL .of DEMUX is

begin
DM : process (Sel, Ent)
if Sel = 'o' then
Sal_O <= Ent;
Sal_l .::;:Q~';
I
else te"
Sal_l <'" Ent¡
Sal_O <= 'O' ¡
end if;
end process;
end NORMAL;
architecture RETARDOS of DEMUX is

-- Definimos Ia.funcjonakidad con senyales auxí.Lixares
signal auxSel : bit;
signal auxEnt : bit;
signal auxsai~o~ auXsal_l : bit;
begin
DM : process (auxSel, auxEnt)
end process;
auxEnt <= Ent;

auxSel <= Sel;
Sal_O <= auxSal_O after tHL_DS when Sel '" '1' else
auxSal_O after tp_DS when Sel "'_'O';
..1 <= au1cSal_l after
Sal.. tHL_DS when Se! = '1' else
auxSal_l after tp_DS when Sel = 'O';
end RETARDOS;
LISTADO 6-12. Introducción de retardos en la descripción VHDL.

El ejemplo mostrado es un caso muy sencillo en el que las señales tienen retar-
dos diferentes en función de la señal de selección. En la mayoría de los casos, la
descripción debe complicarse para modelar correctamente todos los tipos de re-
tardos.
De cualquier forma, hay que tener en cuenta que un modelo obtenido de esta
manera refleja sólo aproximadamente las características reales del circuito; puede
ser un modelo válido para unas simulaciones estimativas sobre el comportamiento
del sistema, pero no resultará adecuado si se quieren realizar unas simulaciones pre-
cisas. Aún así, suelen ser modelos muy útiles durante las etapas iniciales de un pro-
yecto (hasta la etapa de diseño arquitectural).
6.2.6. Documentación, evaluación y seguimiento

del proyecto
Como se ha podido observar en los anteriores apartados, el proceso de diseño de un

circuito requiere cubrir una gran cantidad de aspectos además de lo que es la codifi-
cación del diseño en VHDL y su posterior síntesis. Aspectos como la documenta-
ción, las reuniones periódicas, el seguimiento y solución de los posibles problemas,
etcétera, requieren un esfuerzo considerable por parte del cliente y de los integran-
tes del equipo de diseño.
Conviene, por tanto, valorar el grado de formalismo con el que se siguen las re-
comendaciones que se han dado en los anteriores apartados. La documentación, por
ejemplo, es un factor clave en todo proyecto. Una buena documentación de una eta-
pa facilita enormemente el trabajo de la siguiente. Sin embargo, el esfuerzo dedica-
do a elaborar una buena documentación puede ser elevado. Los documentos más
importantes de un diseño, y cuyo contenido debe ser más cuidado, son el Documen-
to de Especificaciones y el Documento de Diseño Arquitectural. Si el diseño es pe-
queño, la realización de los demás documentos puede reducirse en gran medida, e
incluso no realizarse en algunos casos. Si el diseño es complejo, el número de parti-
cipantes es grande, o se prevé una reutilización o depuración futura del diseño, una
buena documentación de cada etapa va a ser imprescindible. De igual manera, la
realización de reuniones periódicas, la elaboración de planificaciones detalladas, los
informes periódicos de seguimiento, etc., deben hacerse de acuerdo a la magnitud
del proyecto. Si el proyecto es pequeño, estos aspectos pueden ejercer un efecto
negativo sobre el desarrollo, en vez de agilizarlo. En cualquier caso, debe ser el
director del equipo de diseño quien valore el grado de detalle que deben seguir estas
recomendaciones.
6.3. DESARROLLO Y ORGANIZACIÓN DE BIBLIOTECAS

ENVHDL
En un diseño real desarrollado en VHDL se generan normalmente una gran canti-

dad de ficheros de código, unidadesde diseño (entidades, arquitecturas, etc.), fiche-
ros de datos y documentación que es necesario gestionar. No es extraño encontrarse
al final del diseño con decenas de ficheros y versiones distintas de los componentes
diseñados. Además, los objetivos de estas versiones pueden ser diferentes, estando
unas pensadas para síntesis, otras para simulación, etc.
La Pigura 6-6 muestra un ejemplo simplificado de las diferentes versiones o
ficheros que podrían ir apareciendo durante el proceso de diseño. En la figura pode-
mos ver cómo un determinado módulo del diseño (módulo A) va pasando por dife-
rentes versiones hasta llegar a su versión definitiva.
Inicialmente disponemos de un modelo comportamental, posiblemente desarro-
llado durante la etapa de especificaciones. Durante el diseño arquitectural, el mismo
módulo es rediseñado (descrito de forma diferente) para obtener un modelo RT. Du-
rante este proceso se han podido generar diferentes versiones hasta llegar a la solu-
ción funcionalmente conecta o más adecuada. Posteriormente pasaríamos al diseño
lógico, donde todo este proceso de rediseño se repite. Podríamos pensar que las ver-
siones antiguas no son importantes, ya que la versión que finalmente nos interesa es la
última, pero esto no es cierto. El proceso de diseño en VHDL nos permite comparar
fácilmente (incluso de forma automática) una versión con otra. Así, finalizado el dise-
ño lógico, podemos realizar una simulación comparativa entre el modelo que se obtu-
vo durante el diseño arquitectural y el que se ha obtenido durante el diseño lógico. Lo
mismo podríamos hacer entre el modelo de las especificaciones y el arquitectural.
FPGA Modelo
prototipo simulación
Synopsys + Xilinx Synopsys
Cadence
FIGURA 6-6. Versiones o ficheros generados a lo largo de un diseño.

El problema se complica aún más si tenemos en cuenta que los modelos obteni-
dos pueden tener distintas orientaciones. Podríamos, por ejemplo, realizar un diseño
lógico con objeto de hacer un prototipo inicial del circuito en una FPGA. Este mo-
delo sería seguramente diferente del que utilizásemos para la fabricación en silicio,
ya que los estilos de descripción podrían ser diferentes (para adaptarse a la bibliote-
ca de cada fabricante y obtener un mejor resultado en la síntesis). También podría-
mos necesitar modelos diferentes orientados hacia la simulación. Estos modelos es-
tarían optimizados para reducir el tiempo que se emplea en una simulación, que en
ocasiones puede ser realmente largo (incluso de varios días).
Esta cantidad de versiones distintas, con diferentes orientaciones y en dife-
rentes etapas de desarrollo, deben ser gestionadas correctamente para evitar pro-
blemas.
6.3.1. Bibliotecas y componentes de biblioteca
En primer lugar conviene destacar qué entendemos por un componente de bibliote-

ca. Una biblioteca de componentes es, habitualmente, un conjunto de archivos con
información referente a diferentes módulos o componentes. Cada entrada a la
biblioteca, que reúne información respecto a un componente en particular es un
componente de biblioteca. Cada componente de biblioteca puede disponer de varias
vistas, que se corresponderían con diferentes informaciones o aspectos del compo-
nente. Así, el componente de biblioteca podría disponer de modelos VHDL para
simulación, modelos para síntesis, documentación, modelos físicos, etc. En general,
hablaremos indistintamente de componentes, módulos o elementos de biblioteca.
La Figura 6-7 presenta un esquema de una biblioteca de componentes con diferen-
tes vistas para un componente en particular.
Además, las bibliotecas pueden contener componentes con distintos objetivos.
En primer lugar se dispone normalmente de bibliotecas de recursos; éstas son bi-
Docurnentación
(para usuario) =-~
1" ij
=- Modelo
VHOL
i ~
§/ •
(para simulación)
Modelo
temporal " Topografía
(para análisis MUX (para diseño físico)
de tiempos) '-.........
~/ ~Símbolo
netlíst ~ U (para esquemas)
FIGURA 6-7. Diferentes vistas del mismo componente dentro de una biblioteca.
-
CPU. iQ DEC
=
-
·-MEM
Ni I
14~~_~.oo_p,"."~ I
FIGURA 6-8. Relación de jerarquía entre las bibliotecas generadas o usadas en un

diseño.
bliotecas que contienen elementos básicos utilizados en todos los diseños. Entre
ellas podemos encontrar las bibliotecas STD y IEEE que normalmente son utiliza-
das en todas las descripciones VHDL.
En segundo lugar se dispone de bibliotecas de componentes; éstas son biblio-
tecas que contienen elementos de distinta complejidad que serán incluidos dentro
de algún diseño. Podríamos tener, por ejemplo, una biblioteca de módulos periféri-
cos típicos (módulos de transmisión/recepción serie asíncrona, puertos de EIS para-
lela, etc.), de la que seleccionamos alguno para nuestro diseño. También están in-
cluidas en esta categoría las bibliotecas de puertas típicas de los fabricantes.
Finalmente tenemos la biblioteca de diseño; en ella se incluyen todos los ele-
mentos que forman parte de nuestro diseño. Esta biblioteca hará referencia a ele-
mentos de la biblioteca de recursos y de las bibliotecas de componentes. Los com-
ponentes de estas bibliotecas normalmente serán componentes de cierta comple-
jidad.
La Figura 6-8 muestra la jerarquía existente entre estos tres tipos de biblio-
tecas.
La complejidad de los componentes de biblioteca varía desde puertas hasta mi-
croprocesadores. Las necesidades de gestión de la biblioteca dependen en gran me-
dida del tipo de componente considerado. Los componentes de biblioteca se pueden
clasificar atendiendo a varias de sus características, las cuales no son necesariamen-
te exclusivas.
En primer lugar se pueden clasificar los componentes atendiendo a su comple-
jidad funcional. Así, podríamos hablar de:
• Baja complejidad: como puertas, decodificadores, multiplexores o incluso

memorias, sumadores, multiplicadores, etc.
• Complejidad media: como interfaces, puertos de E/S paralela, circuitos de
transmisión/recepción y otros dispositivos periféricos típicos.
• Alta complejidad: como núcleos de microprocesadores, microcontroladores,
procesadores digitales de señal, coprocesadores, etc.
Aparte de esta primera división, los componentes pueden clasificarse atendien-

do a las características de sus modelos de simulación o a la forma en que son imple-
mentados en silicio. En cuanto a sus modelos de simulación, pueden dividirse en:
• Precisos: éstos son componentes que contienen información detallada sobre

su comportamiento, de forma que podemos realizar simulaciones con carac-
terísticas reales (retardos, consumo, área ... ).
• Compatibles: son componentes que contienen información completa respec-
to a su funcionalidad pero sin características reales (típicamente modelos
RT). Cuando se simulan, estos modelos se comportan igual que el circuito
real en una simulación basada en ciclos de reloj.
• Algorítmicos: estos modelos contienen sólo la información funcional básica.
Son útiles en aquellas simulaciones que consumen mucho tiempo de CPU.
Podemos pensar, por ejemplo, en la simulación de un programa complejo en
un microprocesador, o la simulación de un filtro digital, etc.
En cuanto al método de implementación en silicio, los componentes se pueden

clasificar en :
• Bloques fijos (Hard Blocks): éstos son componentes ya implementados que

poseen una descripción física completa (layout) y que pueden ser caracteri-
zados con detalle en cuanto a su área, retardos o consumo. Estos bloques son
dependientes de la tecnología.
• Listas de puertas e interconexiones (netlists): estos componentes respon-
den a una descripción estructural del circuito con referencias a celdas preca-
racterizadas del fabricante (puertas, memorias, etc.). Los detalles finales de
la implementación (retardos de la interconexiones, etc.) no son aún conoci-
dos. Estos bloques son dependientes de la tecnología.
• Bloques HDL (Soft Blocks): éstos son componentes descritos en un leguaje
de descripción hardware que serán sintetizados con una biblioteca determi-
nada. En este caso, aún no se conoce con detalle la lógica final que se gene-
rará. Estos bloques son independientes de la tecnología.
Por último, atendiendo a la configurabilidad del componente, éstos pueden ser

divididos en:
• Componentes cerrados: cuya funcionalidad es fija, independientemente del

modelo de simulación o la técnica de implementación utilizada. Como ejem-
plo, podríamos pensar en un contador de O a 13, con inicialización asíncrona.
• Genéricos: son componentes que poseen algunos parámetros cuantitativos
que no cambian la funcionalidad básica del componente. Como ejemplo, po-
dríamos pensar en el mismo contador de antes, pero con la cuenta final para-
metrizable.
• Configurables: son componentes que poseen algún parámetro cualitativo
que sí modifica la funcionalidad básica. Por ejemplo, en el caso del contador,
podría tener un parámetro que hiciese que contase hacia arriba, abajo o que
contase hacia arriba o abajo en función de una señal, que tuviese o no inicia-
lización asíncrona, etc.
6.3.2. La biblioteca de diseño
En el caso de los diseños realizados en VHOL, la biblioteca de diseño consiste, fun-

damentalmente, en un conjunto de ficheros de texto. Estos ficheros contienen la
descripción VHOL de los componentes que forman el diseño y de los bancos de
prueba utilizados.
Cuando el diseño adquiere una cierta complejidad, o existe m~1>de un diseña-
dor en el equipo, es necesario establecer mecanismos para que todos los diseñado-
res accedan a la información correcta. Supongamos que en nuestro equipo de dise-
ño (el que está diseñando la máquina de refrescos) trabajan dos personas. Uno
podría estar dedicado a la circuitería encargada de la gestión del cobro y devolución
de monedas mientras el otro podría estar a cargo de la parte relacionada con la pro-
gramación de los precios. Es probable que uno necesite trabajar con los resultados
del otro. Si no se establecen los mecanismos adecuados puede ocurrir que se trabaje
con versiones erróneas, obsoletas, o que los dos diseñadores realicen modificacio-
nes sobre un componente al mismo tiempo. Es, por tanto, necesario organizar la bi-
blioteca de forma adecuada para evitar estos problemas.
Existen herramientas comerciales que nos facilitan esta tarea, aunque no siem-
pre están disponibles. Por ello, a continuación se muestra un procedimiento básico
que puede valer como idea sobre cómo organizar la biblioteca de diseño.
La Figura 6-9 muestra el caso de un diseño en el que existen dos diseñadores.
Cada diseñador dispone de un directorio de trabajo en el que desarrolla el compo-
nente que le ha sido asignado. Por otro lado, existe un directorio general (la biblio-
teca de diseño) donde se van dejando los resultados de cada módulo una vez que se
cree terminado. La biblioteca de diseño dispone además de un fichero con la infor-
mación referente a los módulos incluidos, quién los diseñó, versión, etc. El director
del equipo de diseño será el encargado de gestionar la biblioteca. Existen tres pro-
cedimientos básicos de actuación sobre la biblioteca; inserción, extracción y actua-
lización.
Cuando un elemento del diseño ha sido terminado se inserta en la biblioteca
global, quedando a partir de ese momento accesible al resto de los diseñadores. Si
Mod_1,beld
Nombre: VmeTypes.vhd
E\ _ Versión: 3.1
Fecha: 13/02195
Autor: J. Sánchez, y. Torroja
Descripción: Tipos básicos del diseño
Módulo 1 ~-- ~ Pararn.vhd Dependencias:--
.--U "<, - Funcs.vhd
_
¡ ~
Types.vhd I
I ~
Nombre: VmeFuncs.vhd
Versión: 3.2~
vmeOttier.vhdE ...... E-~ . ~= ->
_______
MasterTB.vhd Master.vhd
-;- -
-~
I
~ Master.vhd
~ 8 lE Design.bdd
[i\: : ~-~
M: N.belda : / \ ~
MóduloN
~
/T.~ /.~~.
~ .••••• ~ I
!,~E
Funcs.vhd
·~lhd
lZJ ~ ~_. ~ .
Inter.vhdSlave.vhd Types.vhd
(copia)
Base de datos
(directorio)
E
Fichero
local
Fichero
global
Procedimiento
de gestión
(modificable) (no modificable) de la BDD
FIGURA 6-9. Organización de una biblioteca de diseño.
un diseñador necesita trabajar con un módulo de la biblioteca no tendrá más que re-
ferenciarlo dentro del módulo que está realizando. Si un diseñador necesita realizar
alguna modificación sobre un módulo que ya está incluido en la biblioteca, deberá
primero extraerlo sobre su directorio de trabajo, realizar las modificaciones necesa-
rias y una vez que ha sido comprobado actualizarlo. Este procedimiento de actuali-
zación posiblemente requerirá que el resto de los diseñadores realicen cambios
sobre sus módulos, por lo que este tipo de modificación debe minimizarse en la me-
dida de lo posible. Los flujogramas de la Figura 6-10 muestran, de forma esquemá-
tica, los pasos a realizar en cada una de las acciones de gestión de la biblioteca de
diseño.
Los procedimientos de gestión de la biblioteca, como cualquier procedimiento
de gestión, deben adaptarse a la complejidad del diseño. En diseños pequeños, o
con pocos diseñadores, pueden no ser absolutamente necesarios e incluso introducir
demasiada carga de trabajo. Por el contrario, si el diseño es grande o el número de
diseñadores es elevado, no utilizar estos procedimientos puede hacer impracticable
el desarrollo del proyecto.
oc => Componente del diseño

TB =o> Banco de pruebas
BDD => Base de datos (directorio)
BDG => Base de datos global (biblioteca)
BOL => Base de datos local (componente)
.vhd =o> Fichero de código VHOL
.bdd => Fichero de información de la BDD
FIGURA 6-10. Operaciones básicas en la gestión de una biblioteca de diseño.
6.3.3. Gestión de bibliotecas. Versiones y configuraciones
El número de modificaciones que se realizan a lo largo del diseño de un módulo en

VHDL puede ser realmente elevado. No es difícil encontrar que un determinado
componente ha sufrido un centenar de cambios desde su concepción inicial a su
versión final, Durante este proceso de creación la funcionalidad del componente es
modificada, y no siempre con buenos resultados. A menudo nos encontramos que la
última modificación introducida no da los resultados esperados y que la anterior
versión del diseño funcionaba mejor. No hay experiencia más frustrante que no po-
der recuperar la anterior versión de un diseño porque no recordamos dónde y cómo
exactamente hemos introducido los cambios. Se hace, por tanto, imprescindible un
cierto mantenimiento o control de versiones y configuraciones, Llevar un control de
versiones nos permite trabajar con la seguridad de que las versiones anteriores del
diseño están correctamente archivadas, y de que siempre son recuperables. De esta
manera, cualquier modificación que no sea satisfactoria puede ser anulada y la ver-
sión correcta recuperada.
6.3.3.1. Control de versiones
Consideramos una versión como cada uno de los estados por los que va evolucio-
nando una vista de un componente. En nuestra máquina de refrescos, por ejemplo,
el modelo arquitectural puede haber sufrido múltiples modificaciones (que teórica-
mente daban resultados correctos) hasta llegar a la versión final. Cada uno de esos
diseños intermedios es una versión. Si de un determinado componente obtuviéra-
mos una descripción para síntesis y otra para simulación, consideraríamos que son
vistas diferentes del mismo componente, y no distintas versiones. Tendrían, por tan-
to, distinto nombre, aunque podrían tener las mismas versiones (por ejemplo, podría
haber una versión 1.35 de ambos modelos).
Existen infinidad de métodos para mantener un cierto control sobre las diferen-
tes versiones del diseño que se han ido generando. Algunos de estos procedimientos
son rudimentarios. Podemos, por ejemplo, realizar una copia de todos los archivos
VHDL que hemos generado cada vez que creemos que tenemos una versión defini-
tiva, o cuando la magnitud de los cambios a introducir nos hacen pensar que la
vuelta atrás va a ser complicada. Este procedimiento, sin embargo, presenta multi-
tud de inconvenientes y a menudo se vuelve inútil cuando el número de modifica-
ciones que se realizan sobre el diseño es elevado, o el número de personas trabajan-
do sobre el diseño es grande.
Para realizar un control de versiones, lo primero que hay que definir es cuáles
son los ficheros que se mantienen bajo el control de versiones. Mantener todos los
ficheros que se utilizan durante el diseño sería un gasto inútil, ya que muchos de
ellos pueden generarse a partir de otros mediante programas. Mantener un conjunto
mínimo tampoco es una buena idea, ya que la generación de algunos ficheros es un
proceso costoso y a veces lento. Por ello, debemos distinguir, en primer lugar, la di-
ferencia entre ficheros fuente y ficheros objeto. Un fichero fuente es aquel que no
puede obtenerse de forma automática a partir de otro fichero. Un ejemplo claro de
ficheros fuente son la mayoría de las descripciones VHDL; éstas son fruto de la
creatividad del diseñador. Por el contrario, los ficheros objeto son aquellos que pue-
den obtenerse de forma automática a partir de un fichero fuente. Un ejemplo claro
podrían ser los resultados de un proceso de síntesis automática.
Todos los ficheros fuente deberían estar bajo el control de versiones. Los ficheros
objeto pueden no estar bajo control, aunque sí puede ser conveniente si el proceso de
generación de los ficheros objeto es largo o complejo (un proceso de síntesis y optimi-
zación hasta obtener resultados satisfactorios puede durar varias horas). En general, se
considera que deben estar bajo control de versiones los siguientes tipos de archivos:
• Fuentes en VHDL: deben mantenerse todos los ficheros fuente VHDL de

cada uno de los bloques diseñados.
• Bancos de prueba: al igual que los ficheros fuente de los bloques, los ban-
cos de prueba, tanto de los bloques como del circuito completo, deben estar
controlados.
• Ficheros de comandos: normalmente, durante el proceso de diseño es nece-
sario repetir la misma acción varias veces (podemos pensar en el procedi-
miento de análisis de los ficheros VHDL y su simulación posterior). Para

ello, lo habitual es utilizar ficheros de comandos, donde se detallan los pasos
a realizar de forma automática. Guardar estos ficheros no sólo permite repe-
tir los pasos realizados, sino que además sirve como documentación de cómo
se han realizado las diferentes tareas del diseño.
Además de estos archivos fuente es conveniente mantener bajo control algunos

archivos objeto:
• Vectores de simulación: aunque estos ficheros pueden generarse de forma

automática, es interesante poder acceder a ellos de forma directa. De esta
manera se ahorra tiempo, ya que estos ficheros se utilizan continuamente en
las simulaciones.
• Listas de componentes e interconexiones (netlists): por la misma razón, es
interesante mantener estos ficheros. Por otro lado, estos ficheros son el resul-
tado de un proceso de síntesis, que a menudo resulta costoso y difícil.
• Topografia: este es el resultado final del diseño y, por tanto, debe ser conve-
nientemente archivado. Sin embargo, no debe mantenerse todas las versiones
que se hayan generado, ya que son ficheros muy grandes.
Además de los ficheros descritos, es necesario mantener un control de versio-

nes de la documentación que se va generando durante el proyecto. Normalmente, el
procedimiento de control de la documentación es diferente al de los ficheros fuente
y objeto, por los que será tratado en otro apartado.
Existen multitud de herramientas para el control de versiones. Si trabajamos
bajo un sistema UNIX, habitualmente dispondremos de herramientas básicas para
realizar el mantenimiento de versiones con distintas prestaciones (como son sees,
ReS, evs, etc.). En otros sistemas operativos será necesario conseguir alguna he-
rramienta para llevar el control. Casi todas las herramientas existentes están pensa-
das para el mantenimiento de ficheros de texto. Pueden valer para mantener fiche-
ros binarios, pero en este caso los sistemas de compresión utilizados hacen que el
archivo de las diferentes versiones sea menos compacto.
Las versiones suelen identificarse mediante dos números; el número de versión
y el numero de edición. Los cambios en el número de edición implican correcciones
menores, reparación de problemas, etc., pero no cambios en la funcionalidad o la
interfaz de un bloque. Si hablamos de documentos, los cambios en la edición supo-
nen correcciones ortográficas o mejoras en la redacción de algunos puntos. Por el
contrario, los cambios de versión suponen cambios mayores, tanto en funcionali-
dad, interfaz de un bloque o, si hablamos de documentos, introducción de nuevos
párrafos o modificaciones importantes de los existentes.
6.3.3.2. Control de configuraciones

Consideramos una configuración como un conjunto de versiones que forman una
unidad operativa. Podemos pensar, por ejemplo, en el conjunto de ficheros VHDL,
bancos de prueba, procedimientos de comandos, etc., que existían en un determina-

do momento de la historia del diseño. La Figura 6-11 muestra gráficamente el con-
cepto de configuración comparado con el concepto de versión.
Como se ve, un determinado componente puede ir evolucionando a través de
distintas versiones. Al principio del proyecto, en la figura, el diseño (asic.vhd
v1.0) es comprobado mediante un determinado banco de pruebas (tb.vhd v l.O). En
un determinado instante se decide que el banco de pruebas no es cómodo para rea-
lizar la validación funcional y se implementa un modelo de una CPU (cpu.vhd
v1.0) que ejecuta un determinado programa (prog.cpu v1.0). Posteriormente se
mejora la CPU, posiblemente introduciendo o cambiando los códigos de opera-
ción, con lo que se han de modificar también los programas. Como se puede obser-
var, no todas las versiones de los componentes son compatibles entre sí. Si intentá-
semos que la CPU vl.O ejecutase el programa PROG v1.2 nos encontraríamos con
que no es posible. Tampoco podríamos, por ejemplo, recuperar la primera versión
del ASIC y simularla con la CPU. En un determinado instante de tiempo existe un
conjunto de versiones (Cl, C2, ... en la figura) que forman una unidad operativa
(simulable, sintetizable, etc.). Este conjunto puede estar formado por ficheros
VHDL, ficheros de comandos y cualquier otro tipo de ficheros que sean necesarios
para trabajar con el diseño. Cuando se recupera una determinada versión de un
componente deberían recuperarse también todas las versiones necesarias para su
operación.
01
ASIC
diseño
05 Banco de Pruebas
FIGURA 6-11. Configuraciones y versiones en la gestión del diseño.

01
ASIC
diseño
Banco de Pruebas
FIGURA 6-12. Ajuste ficticio de versiones para el mantenimiento de configura-

ciones.
No existen demasiadas herramientas que trabajen con versiones y configuracio-

nes. De cualquier manera, esta consideración debe ser tenida en cuenta para no per-
der las ventajas que aporta el mantenimiento de versiones. Si no se dispone de
herramientas para el mantenimiento de configuraciones, una posible solución es
mantener versiones ficticias de los ficheros que configuran un diseño. La Figura 6-12
muestra cómo se aplicaría esto al ejemplo anterior.
En la figura, los rectángulos en color claro reflejan diferentes versiones de un
fichero. Los rectángulos en color oscuro reflejan versiones ficticias (se ha generado
una nueva versión, aunque no ha habido modificación alguna en el fichero). Como
se observa, se han ido creando versiones adicionales de todos los componentes, in-
cluso si éstos no han sido modificados. De esta manera, recuperar una determinada
configuración del diseño consiste en recuperar la misma versión de todos los fiche-
ros del diseño. Este método, aunque válido, oculta en cierta medida la historia del
componente (un determinado módulo tiene muchas más versiones de las que real-
mente se han producido).
6.4. DISEÑO PARA REUSABILIDAD
El término reusabilidad pretende reflejar la facilidad con la que un diseño previa-

mente realizado puede ser utilizado de nuevo, probablemente para otra aplicación,
con otra tecnología y por diferente equipo de diseño.
6.4.1. ¿Por qué hacer diseños reutilizables?
El coste de desarrollo de los diseños y componentes actuales, así como la disponibi-

lidad de herramientas de síntesis y la tendencia actual a crear mercados abiertos, ha-
cen cada vez más atractiva la idea de la reutilización de componentes previamente
diseñados. Estos componentes pueden haber sido diseñados como parte de un pro-
yecto y reutilizados posteriormente, o generados de forma explícita como compo-
nentes de biblioteca para su posterior reutilización. En ambos casos, la reutilización
de estos componentes presenta una serie de requisitos y problemas que es necesario
resolver.
La reutilización de los componentes presenta ventajas claras en multitud de as-
pectos. Por un lado, reduce los costes de diseño de un componente al utilizarlo (y,
por lo tanto, amortizarlo) en varios proyectos. Esto es ventajoso tanto para quien di-
señó el componente como para el usuario final del mismo. Al primero le permite
abaratar los costes de desarrollo, haciendo más atractivos sus productos. Al usuario
final le permite acceder a una tecnología más barata. Por otro lado, los componen-
tes previamente diseñados (y previamente utilizados) tienen mayores garantías en
cuanto a su funcionamiento, ya que han sido comprobados y depurados en anterio-
res proyectos. De nuevo esto supone una ventaja tanto para el usuario, que corre
menos riesgos, como para el diseñador, que ofrece productos de mayor calidad, au-
mentando su clientela.
Pero no sólo es importante la reducción del coste del desarrollo. La gran com-
petencia del mercado electrónico hace que el tiempo de desarrollo sea un factor cru-
cial en el éxito final del producto y su rentabilidad. Un producto que no llega a
tiempo al mercado es un producto que pierde gran parte de su cuota de mercado, y
no sólo porque otros productos de la competencia le arrebaten parte del mismo, sino
porque la rápida evolución de las tecnologías y las prestaciones de los circuitos in-
tegrados puede hacer que un circuito, que cuando se especificó era competitivo, re-
sulte mediocre u obsoleto si se ha tardado demasiado en su desarrollo. Utilizar com-
ponentes de biblioteca previamente desarrollados puede reducir en gran medida el
tiempo de diseño y evitar este tipo de problemas.
Sin embargo, no debe pensarse sólo en los componentes reutilizables como
módulos diseñados con la idea de ser comercializados e incluidos en otros diseños.
Utilizar ciertas técnicas de diseño que faciliten la reutilización de un componente
puede aportar grandes ventajas en el desarrollo de un circuito incluso si no se está
pensando en su posterior reutilización. La experiencia muestra que, en la mayoría
de los diseños, aparecen imprevistos que obligan a modificar el diseño en mayor o
menor medida. A menudo, las especificaciones de un circuito no son completas, o
hay aspectos que antes de comenzar el desarrollo son difíciles de cuantificar o pre-
ver. Esto obliga a mantener ciertos parámetros del diseño abiertos hasta que un aná-
lisis más detallado permita definirlos. Un ejemplo típico podría ser el número de
bits necesarios para codificar los datos o los coeficientes en un filtro digital. Aspec-
tos como el área, el consumo, o la máxima frecuencia de funcionamiento pueden
obligar a cambiar algunas de las características que se habían fijado inicialmente
para el diseño. Algunas de las técnicas que se exponen en los siguientes apartados
pueden ayudar a que estos cambios y modificaciones a lo largo del ciclo de diseño
repercutan lo menos posible en el tiempo de desarrollo y en la calidad y fiabilidad

del circuito diseñado.
Si, por el contrario, el objetivo de un diseño es que éste pase a formar parte de
una biblioteca de componentes reutilizables, habrá que considerar algunos aspec-
tos adicionales a los puramente técnicos. En este caso hay que tener en cuenta que
para que un diseño sea reutilizable no sólo es necesario que sea correcto en los as-
pectos funcionales, sino que además debe satisfacer una serie de requisitos en
cuanto a su documentación, su portabilidad entre herramientas, su facilidad de
mantenimiento, etc. Estos aspectos también serán tratados a continuación.
6.4.2. La comercialización de una biblioteca
Los requisitos que un componente de biblioteca debe satisfacer dependen de quién

los utilice y cómo los utilice. Si, por ejemplo, nos fijamos en el punto de vista del
usuario, es decir, la persona que va a utilizar el componente en su circuito, su ma-
yor preocupación será posiblemente la integración sin problemas del componente
en su flujo de diseño. Esto implicará que el componente esté disponible para sus he-
rramientas, que exista una buena documentación, etc. Si atendemos al punto de vis-
ta del diseñador, es decir, la persona que desarrolla el componente para su posterior
comercialización, su mayor preocupación será encontrar métodos para proteger y
comercializar su biblioteca, métodos para facilitar el mantenimiento y depuración
de errores, etc. Si pensamos en la fabricación del circuito, estaremos más interesa-
dos en el test de fabricación y, por tanto, en la existencia de vectores de test para el
componente y métodos para aplicarlos cómodamente. Por último, si nos fijamos en
el punto de vista del comercial, es decir, la persona que va a vender el componente,
seguramente estará más preocupado en la fiabilidad del componente, el soporte téc-
nico, cómo ha resultado su utilización en otros diseños, etc.
Teniendo en cuenta todos estos aspectos, podemos elaborar una lista de requisi-
tos que todo componente debería satisfacer para que resulte industrialmente reutili-
zable.
• Interoperabilidad: el componente debería estar disponible para diferentes

herramientas, ya que cada usuario dispone de sus propias herramientas, y no
todas trabajan con el mismo subconjunto de VHDL (tanto en síntesis como
en simulación).
• Documentación: una de las claves de la reusabilidad es disponer de una
buena documentación, consistente en:
- Documento de diseño: es el documento más importante para el diseñador
y/o la persona encargada del mantenimiento y depuración del componente;
contiene toda la documentación relativa a cómo se ha desarrollado el com-
ponente, explicación de la arquitectura, código VHDL, etc.
- Guía de referencia: algunos componentes de biblioteca pueden ser extre-
madamente complejos. Si estos componentes son configurables, su utiliza-
ción puede requerir la selección correcta de diferentes parámetros por parte
del usuario. En estos casos puede ser necesaria una guía donde se describa
cómo configurar, simular y sintetizar correctamente el componente.
- Hoja de catálogo: al igual que ocurre con los componentes discretos, dis-
poner de una hoja de catálogo facilita la consulta y selección del compo-
nente por parte del usuario. Esta hoja debería contener toda la información
necesaria para la selección y operación del componente.
- Notas de aplicación: los ejemplos son una ayuda ideal a la hora de utilizar
un componente. Debería haber notas de aplicación disponibles tanto para el
uso del componente de biblioteca (especialmente si éste es configurable)
como para su operación.
- Problemas y soluciones: las descripciones VHDL se encuentran a mitad
de camino entre el software y el hardware. Si el componente es complejo,
podría tener algunos errores que, aunque no impidiesen su utilización, es
necesario conocer y plantear alternativas para su solución.
• Soporte técnico y mantenimiento: como en cualquier otro producto, estos
factores son críticos para la comercialización del componente.
• Estimadores: cuando los componentes son genéricos o configurables, el di-
señador necesita encontrar la mejor combinación de parámetros que satisfaga
sus requisitos. En estos casos no resulta factible sintetizar el componente ba-
jo cada posible combinación de parámetros, ya que el tiempo empleado en la
síntesis puede ser elevado. Resulta, por tanto, muy útil disponer de estimado-
res fiables de área, retardos o consumo.
• Herramientas de configuración: en diseños configurables complejos pue-
den necesitarse herramientas que ayuden al usuario a configurar el compo-
nente de acuerdo a sus requisitos.
• Herramientas de validación: en componentes de mediana o alta compleji-
dad pueden hacerse necesarias funciones que faciliten al usuario la simula-
ción del circuito o del sistema completo. Podríamos imaginar, por ejemplo,
un usuario que está utilizando un transmisor/receptor síncrono de una deter-
minada biblioteca de componentes. Para comprobar que el componente fun-
ciona o es operado correctamente, le sería muy útil disponer de funciones en
VHDL que le permitiesen transmitir mensajes hacia el componente correcta-
mente formateados (con la velocidad de transmisión adecuada, el CRC aña-
dido, etc.). En otros casos, cuando la complejidad del componente de biblio-
teca hace poco recomendable la simulación a nivel RT, sería conveniente
disponer de modelos algorítmicos o de alto nivel de la celda.
• Soporte para la detección de errores: los componentes de biblioteca van a
estar normalmente inmersos en diseños más complejos, y estarán controlados
por otros componentes o partes de la lógica del circuito. Al igual que en los
componentes más simples (biestables, puertas) existen métodos para detectar
situaciones peligrosas, como violaciones en los tiempos de establecimiento
(set-up time) y mantenimiento (hold time), los componentes de biblioteca
complejos deben contar con métodos para detectar operaciones erróneas por
parte de la lógica que lo opera (por ejemplo, una secuencia incorrecta de se-
ñales, valores no controlados en buses, etc.).
• Soporte para el test de fabricación: cada componente debería disponer de

un conjunto de vectores de test, o una circuitería de autotest, para realizar el
test de fabricación. Esto es especialmente importante en el caso de los com-
ponentes configurables, donde el conjunto de vectores de test puede depen-
der en gran medida de la configuración escogida.
La interoperabilidad, documentación o soporte técnico son requisitos que pue-

den ser satisfechos con mayor o menor esfuerzo. Sin embargo, hoy por hoy, el resto
de los requisitos son más difíciles de cumplir.
A la hora de desarrollar una biblioteca de componentes para su comercializa-
ción, deben valorarse con cuidado estos factores. Satisfacer estos requisitos puede
implicar un esfuerzo considerable, lo que en algunos casos puede hacer económica-
mente inviable el desarrollo. .
De cualquier manera, la complejidad de los diseños actuales hace cada vez más
atractiva la idea de su reutilización y comercialización. En este sentido, cada día se
dedica un esfuerzo mayor al diseño de lo que se conoce como celdas IP (Intellec-
tual Properties), es decir, componentes de biblioteca de elevada complejidad, sumi-
nistrados por una determinada casa comercial, a partir de los cuales se realiza el
diseño. Estos componentes no suelen ser genéricos o configurables, sino que res-
ponden a un esquema de componente cerrado (funcionalidad fija) con modelos de
simulación precisos o compatibles, y en muchos casos ofertados como bloques fijos
(hard blocks).
Hoy en día es posible acceder a estas celdas IP con dos objetivos fundamenta-
les: disponer de modelos para simulación y de modelos para fabricación.
Los modelos para simulación nos permitirán analizar el comportamiento de
un sistema que incluye este tipo de celdas o circuitos. Por ejemplo, si vamos a di-
señar un circuito que interactúa con un microprocesador SPARC®, o Pentium®,
nos será de gran utilidad disponer de los modelos VHDL de los microprocesado-
res, para así simular el comportamiento del sistema completo. Existen un gran nú-
mero de casas que ofrecen modelos para simulación en VHDL de diferentes com-
ponentes (microprocesadores, microcontroladores, circuitos periféricos, lógica
discreta, etc.).
Los modelos para fabricación nos permitirán no sólo simular el comportamien-
to del sistema sino también fabricar el circuito una vez diseñado. En este caso, el
número de casas que distribuyen este tipo de componentes es más limitado, ya que
requiere el soporte de un fabricante que será el que finalmente producirá el circuito
que diseñemos con la celda IP inmersa en él. Esto obliga a que el diseño se realice
con un determinado fabricante, lo que en algunos casos dificulta el diseño (por
ejemplo, podríamos querer diseñar el circuito en tecnología ECL, pero sólo dispo-
ner de las celdas IP que deseamos en tecnología CMOS).
Una tercera posibilidad es acceder a modelos sintetizables. En este caso, el
usuario no está atado a un fabricante determinado, ya que puede sintetizar el circui-
to, con la correspondiente celda IP, utilizando cualquier tecnología. Sin embargo, en
el caso de celdas IP complejas, la síntesis automática no resulta económicamente

viable en la mayoría de los casos. Las celdas ofertadas como bloques fijos (hard
blocks) están normalmente implementadas de forma muy optimizada (mediante es-
tructuras tipo data-path, generadores de estructuras regulares, e incluso técnicas de
diseño totalmente a medida ofull-custom), con lo que resultan mucho más rentables
que las que se obtendrían mediante una síntesis automática.
La utilización de celdas IP está generando una nueva corriente de diseño que se
aleja del diseño actual a la medida, volviendo a un diseño similar al que se realizaba
mediante componentes discretos. No debe pensarse, sin embargo, que esto es un
paso atrás. La tendencia actual es utilizar el mayor número posible de celdas IP, ya
diseñadas, y diseñar la lógica imprescindible para unir las celdas IP o incluir la
funcionalidad no disponible. La diferencia fundamental con el proceso de diseño
basado en componentes discretos es que ahora, gracias a los lenguajes de descrip-
ción de hardware, es posible simular el sistema completo antes de proceder a su
fabricación.
La utilización de celdas IP, que a menudo contienen decenas e incluso cientos
de miles de puertas, está imponiendo nuevos desafíos al proceso de diseño. La difi-
cultad para simular un circuito que contenga varias de estas celdas (un sistema inte-
grado o System On Silicon) obliga a disponer de modelos de alto nivel (algorítmi-
cos, de juego de instrucciones, etc.) de los componentes. Con estos modelos se
podrá realizar la simulación del sistema completo a un coste razonable.
6.5. DISEÑO GENÉRICO
Una de las ventajas fundamentales de los HDLs es que permiten, de forma sencilla,
generalizar el diseño. Así, cuando se diseña un componente, ciertos valores pueden
quedar como parámetros que se concretarán más adelante en el proceso de diseño.
Ejemplos típicos son el final de cuenta de un contador, el ancho del bus de un regis-
tro paralelo, el número de bits de una ALU, etc.
Esta facilidad para dejar ciertos datos como parámetros permite la reutilización
del componente en diseños posteriores. Además, permite que parte de las especifi-
caciones del diseño queden abiertas, 10 que facilita la toma de ciertas decisiones
que, en otro caso, podrían restringir el desarrollo.
Pero para aprovechar al máximo estas posibilidades es necesario considerar
ciertos aspectos y mantener unos procedimientos de trabajo que garanticen que el
esfuerzo invertido en realizar el diseño genérico va a ser aprovechable posterior-
mente.
En este apartado se dan una serie de recomendaciones sobre cómo realizar un
diseño genérico y cuáles son sus ventajas e inconvenientes.
6.5.1. Definición de diseño genérico
En primer lugar, conviene acotar qué entendemos por diseño genérico, ya que exis-
ten diferentes interpretaciones de este concepto.
A lo largo del apartado se entenderá que un diseño genérico es aquel en el que

se pueden variar ciertos parámetros del diseño «sin variar la funcionalidad a nivel
RT» del mismo. Paralelamente se puede hablar de diseños configurables, en donde
la variación de ciertos parámetros afecta de forma que el diseño sí cambia su fun-
cionalidad a nivel RT.
El siguiente ejemplo puede clarificar estos conceptos. El código del Listado 6-13
muestra un contador síncrono ascendente/descendente.
entity AscDescContador le
generlc(gMaxBits : integer := 4);
port(
~eloj in std_logic;
InicioN in std_logic;
AscDesc in std_logic;
CUenta out stq_logic_vector(gMaxBíts - 1 downto O)
);
end AscDescContador;
architecture SÍllple of As9DeScContador ls

constant cUltimoYalor tstq_logic_vector(gMaxBits'~ 1 downto O)
: = (others => '1');
constant cPrirnerValor : std_logic_vector(gMaxBits - 1 downto O)
:= (others => 'O');
signal Int.Cuenta u stq_logic",vector(gMaxBíts -1 downto O);
begin
CUenta <= IntCUenta;

ppral : procese (ReloJ,' InicieN)
begin
if InicieN = 'O' then
IntCUenta <= (others => 'O');
elsif Reloj' event and Reloj = '1' then
if AscDesc = '1' tben
if IntCUenta = cUltimoValor then
IntCUenta <= (otbers => 'O');
else
IntCuenta <., IntCUenta·+ '1';
end U;
else
if IntCUenta = '~PrirnerValor then
IntCuenta <= IntCUenta - '1';
else
IntCUenta <= (others => '1').;
end U;
end if;
end if;
end process;
end Simple;
LISTADO 6-13. Código de contador ascendente/descendente.

En el contador, la máxima cuenta es un parámetro (gMaxBits) cuyo valor se fi-

jará con posterioridad. En este caso, el valor del parámetro no afecta al esquema
funcional a nivel RT y sólo cambia el número de bits del contador.
Sin embargo, en el siguiente ejemplo se muestra el mismo contador con un pa-
rámetro adicional (gTipo) en función del cual se generará un contador ascendente,
descendente o ascendente/descendente.
entity ContadorGenérico is
generie (
gTipo : integer := O;
_ O significa contador ascendente
_ 1 significa contador descendente
_ resto: significa contador ascendente/descendente
gMaxBits integer:= 4);
port(
Reloj in std_logic;
IniciaN in std,_logic;
AseDasc in std_logic; _ solo usada en el contador, Up/J:)own
Cuenta out std_logic_vector(gMaxBits - 1 downto O)
);
end ContadorGenérico;
architecture Simple of ContadorGenérico ia

constant cUltimoValor std,_logic_vector(gMaxBits - 1 downto O)
:= (othara => '1');
constant cPrirnerValor std,_logic_vector{gMaxBits - 1 downto O)
:= (othara => 'O');
signal IntCuenta : std,_logic_vectór(gMaxBits -1 downto O);
begin
Cuenta <= IntCuenta¡
ppral : proceaa(Reloj, InicioN)

begin
if IniciaN = 'O' then
IntCuenta <= (others => 'O');
elaif Reloj'event and Reloj = '1' then
caae gTipo is
when O =>
if IntCúenta = cUltirnoValor then
tntcuenta <= (others => 'O');
elae
IntCuenta <= IntCuenta + '1';
end if;
when 1 =>
if IntCuenta = cPrimerValor then
rntcuenta <= IntCuenta - '1';
elae
IntCuenta <= (othera => '1');
end if;
when othara =>
if AscDe~ = '1' then

if Int~~ta = cUltimoValor then
tntcuenta <= (othere => ' O' );
elee
rntcuentá' <= IntCUenta + "r';
end if;
else
if IntCuenta = cPrimerValor then
IntCUenta <= IntCUenta - '1';
elee
IntCUenta <= (others => '1');
end if;
endif;
end case;
end if;
end process;
end Sirrple;
LISTADO 6-14. Código de contador genérico.
En este caso, la funcionalidad del componente cambia al cambiar el parámetro.

Este sería el caso de un componente configurable frente al componente genérico
del ejemplo anterior.
6.5.2. Ventajas e inconvenientes del diseño genérico
Los códigos mostrados en el apartado anterior son un ejemplo de diseño genérico o

configurable. Sin embargo, no muestran las ventajas ni los inconvenientes que se
obtienen al escribir código de esta manera.
Antes de describir estas ventajas e inconvenientes es necesario diferenciar en-
tre dos tipos de diseños genéricos; aquellos diseños en los que sólo son genéricos
alguno de los parámetros (parcialmente genéricos) y aquellos (totalmente genéri-
cos) en los que se parametrizan todos los valores que admitirían un valor genérico.
A lo largo del apartado hablaremos de diseños totalmente genéricos, mientras
no se especifique 10 contrario.
Las ventajas fundamentales del diseño genérico son:
• Permite mantener las especificaciones abiertas. Puesto que los valores que
aparecen en el diseño son variables, es posible esperar a etapas más tardías
del diseño para decidir su valor final. Sin embargo, debe considerarse que es-
ta «facilidad» no implica que no se hayan tenido que definir dichos valores
durante la especificación. Un excesivo número de grados de libertad o deci-
siones retardadas puede acarrear más inconvenientes que ventajas.
• Evaluación de alternativas. Al poder modificar los parámetros del diseño,
es posible evaluar alternativas que, en principio, podrían no haber sido con si-
deradas. Este aspecto tiene especial relevancia cuando en las últimas etapas
del diseño surgen restricciones (área, tiempo, cambio de tecnología) que
obligan a tomar soluciones de compromiso. En general, estas restricciones
no son consideradas en las primeras etapas del diseño. Realizar un diseño ge-
nérico lleva implícita su consideración.
• Análisis exhaustivo del diseño. Realizar un diseño genérico implica que el
componente a diseñar debe funcionar bajo todos los valores posibles de sus
parámetros. Esto requiere por parte del diseñador un análisis del problema
mucho más exhaustivo que cuando se diseña el mismo componente para
unos valores fijos de sus parámetros. Además, el diseño genérico impone
unas pruebas funcionales que no sólo verifican la funcionalidad del compo-
nente sino también el comportamiento del mismo al variar los parámetros.
Todo esto redunda en una verificación mucho más exhaustiva del componen-
te y unos bancos de prueba más depurados.
• Organización del diseño. De igual manera que el diseño genérico exige al
diseñador un análisis más profundo del componente que está diseñando, tam-
bién requiere del equipo de diseño una mejor organización de los ficheros, ti-
pos de datos, constantes del diseño, etc. Esta mejor organización redunda en
un ahorro importante de tiempo, especialmente si 'el equipo de diseño está
formado por varias personas.
• Mejora del mantenimiento. Uno de los aspectos claves para hacer un dise-
ño reutilizable es que disponga de una buena documentación. Parte de la do-
cumentación del diseño la constituye el propio código HDL. Cuanto más le-
gible sea el código, más fácil resultará su interpretación y modificación. El
realizar un diseño genérico implica que los valores constantes que normal-
mente aparecen en el código son sustituidos por nombres de parámetros,
expresiones, etc. Si estos nombres y expresiones son escogidos bajo ciertas
reglas, su lectura e interpretación será sencilla, facilitando así la consulta y
mantenimiento del código por personas distintas a las que lo realizaron.
• Simplificación del cambio de tecnología (retargeting). La utilización de
HDLs permite, en teoría, realizar diseños independientes de la tecnología en
la que finalmente se implementará el circuito. En la práctica, esto no siem-
pre es cierto. Factores como la velocidad, el consumo, la biblioteca o la ca-
pacidad de integración, obligan a rediseñar muchas de las partes de un
circuito al cambiar de tecnología. Es necesario, por tanto, escoger la tecno-
logía objetivo lo antes posible en el proceso de diseño. Sin embargo, la ex-
periencia muestra que, en muchos casos, es necesario cambiar la tecnología
objetivo (bien sea por factores tecnológicos, económicos o políticos) cuan-
do se está bastante avanzado en el proceso de diseño. De nuevo, el diseño
genérico permite reducir los efectos negativos de estos cambios al permitir
el redimensionamiento sencillo de ciertos aspectos del diseño. Conviene in-
sistir, sin embargo, en que los cambios de tecnología pueden suponer modi-
ficaciones muy importantes en el diseño y que deben evitarse en la medida
de lo posible.
El diseño genérico presenta, por otro lado, una serie de inconvenientes que es
necesario valorar:
• Complejidad del código. En algunas ocasiones, el realizar un componente

genérico implica que en el código se han de utilizar construcciones un tanto
artificiosas y difíciles de seguir para el no iniciado. En este caso deben valo-
rarse con cuidado las ventajas del diseño genérico frente a la legibilidad del
código. En cualquier caso, una buena documentación y un código bien co-
mentado ayudan mucho a su comprensión.
• Dificultad en las pruebas. Realizar un diseño genérico implica que han de
realizarse pruebas funcionales para los diferentes valores que puedan tomar
los parámetros. Esto implica, a su vez, que los bancos de prueba deben ser
también genéricos, lo que supone una dificultad adicional y una nueva fuente
de errores. Si bien esto redunda en un análisis más profundo del diseño, pue-
de suponer un freno excesivo en algunos casos. Por otro lado, el número de
pruebas a realizar puede dispararse. Es necesario valorar con detalle estos
aspectos con objeto de llegar a una solución de compromiso entre el coste de
desarrollo y los beneficios esperados.
• Tiempo de desarrollo. En general, éste es el aspecto más difícil de valorar.
En un principio, el diseño genérico implica un tiempo mayor de desarrollo.
Sin embargo, esta inversión de tiempo en las fases iniciales del diseño va a
suponer un ahorro importante en las etapas finales, especialmente si surgen
problemas no contemplados inicialmente. Aspectos como la capacidad de los
diseñadores, la tradición del equipo de diseño en esta filosofía de trabajo, la
complejidad del diseño, etc., deben ser considerados para valorar la viabili-
dad de este enfoque. La experiencia del equipo en algún diseño de estas ca-
racterísticas puede ayudar en gran medida.
• Prestaciones del resultado. En algunos casos, la generalidad en el diseño va
a requerir un compromiso respecto a las prestaciones del mismo. Si el diseño
se encuentra muy al límite de la tecnología, las soluciones a cada problema
serán demasiado particulares como para permitir un diseño genérico.
Como conclusión cabe decir que el diseño genérico puede paliar en gran medida
los problemas inesperados que se presentan en las etapas finales del proceso de dise-
ño. Su realización supone un coste adicional en tiempo de desarrollo. La experiencia
muestra, sin embargo, que este tiempo invertido es claramente recuperado por las ven-
tajas que aporta este tipo de diseño. Sólo si el diseño está absolutamente cerrado en
las especificaciones, puede tener sentido no realizar el diseño con esta aproximación.
6.5.3. Desarrollo de componentes genéricos.

Recomendaciones
Las recomendaciones y ejemplos que a continuación se exponen han sido proba-

das con un determinado sintetizador y/o simulador. En un principio, estas reco-
mendaciones podrían no ser aplicables para otras herramientas. Sin embargo, sí

pueden dar una idea del objetivo que se pretende conseguir realizando diseños ge-
néricos.
6.5.3.1. Organización del diseño
Existen muchas maneras diferentes de realizar un diseño genérico. En general, con-

viene diferenciar dos casos que requieren un planteamiento diferente: el diseño de
un componente y el diseño de un circuito o dispositivo completo.
• Diseño de un componente aislado. En este caso el objetivo del diseño gené-

rico será realizar un componente reutilizable. El procedimiento más cómodo
en este caso es utilizar genéricos (generic) del VHDL como procedimiento
para pasar parámetros.
En estos casos debe tenerse en cuenta que el interfaz con el exterior se
hará a través de tipos estándar (std_logic o std_logic_vector), ya que se des-
conoce el entorno donde va a utilizarse el componente. Este es el procedi-
miento normal de parametrización de componentes. Sin embargo, el diseño
genérico presenta más ventajas en el caso de diseños completos.
• Diseño de un circuito o dispositivo completo. En este caso el planteamien-
to debe ser más riguroso, aunque los beneficios también son mayores.
Se organizará el diseño de forma que exista un fichero donde se definan todos

los tipos básicos y constantes utilizados en el diseño. El control y modificaciones de
este fichero son responsabilidad del jefe del equipo de diseño.
El siguiente código muestra un paquete de este tipo.
package TiposBasicos is
=============================~=====;:================~====--====
...~-----",,----'-_._....
-~-------~-,--':"".-:"",--.--------------:,---~-~--..; _~-
-- ,<;qn&~1*> definj,dap para el manejo de Jos ,.datos en 9en~al
constant ~BitsDatos : natural .- '9;
constant cBitscoef , : riatUfil : =' 6;
constant cBitsNorma : natural x» 5;
constant cBitsMaxlnterval : natural'::= ,1;

constant cMaxlnterVal : integer := 2i
L2*'*cBitsMaxlnterval;
constant cNumDetectores : natural',':::: 2;
6. La gestión del diseño 41 7
------------------------ ...------------------------_-----~,...-."1 ..:_-.-~

_.:.Constantes definidas para la cceunícecíén con el
-- microprocesador
constant cAnchoBusCPU natural :=- 9;

constant cAnchoBusDatos natural .. -: cAnchoBusCPU ;
constant cAnchoBusDirecs natural -:= 7;
constant cBitsContrRegs natural ::: 4;
constant cNumErrores natural := 2;

constant cNumInterrps natural .- ,
cNumErrores +
2 + cNumDetectores;
-- Constantes definidas para el manejo de los accesos

-- a memoria
-------------------------------- ....------~-------~--_ ....-"'!" .....-.--~~ ...._-
constant cBitsBusDirecc~ : natural := 15;

ESTE DATO DEBE SER, AL MEKJS, LA SUMA DE:
cBitsMaxNumSensor +
cBitsMaxNumMuestras +
c&itsMaxNumAccesos - 2
;--Constantes definidas para el manejo de los filtros

, -- FIRl Y FIR2 '
------------------------_~:.,.;.~"I'""--~ \--.--~ ..':'OO;,..--....,¡..--"""- .....----.---
.... ...--~_~-
-- General
constant cBits~sor natural ::'- 3';
constant cBitsNumBloqsMem natural.- 2;
constant cBitsMaxNumMuestras natural:e 12;
-- Filtro 1
constant cBitsMaxNumEtapas1 natural j« 4;
constant cBitsMaxNumAccesos1 natural .- cBitsMaxNumEtapas1 - 2;
constant cPa1abrasPorAccesol natural.- 4;
constant cMaxNumEtapas1 : natural .- 2**cBitsMaxNumEtapas1;

constant cMaxNUmAccesos1 : natur~l .- 2**cBitsMaxNumAccesosl¡
-- Filtro 2
constant cBitsMaxNumEtapas2 natural:= 4;
constant cBitsMaXNumAccesos2 natural :.;;:0- cBitsMaxNumEtapas2 -
cBitsNumBloqsMem;
constant cPalabraSPorAcceso2 natural := 3;

-~ 2**cBitsNumBloqsMem;
constant cMaxNumEtapas2 natural :" 12;
-- ~BitsMaxNumEtapas2;
constant cMaxNumAcces0s2 natura1:= 2**cBitsMaxNumAccesos2;
--------------_:_--------------- ......... ..... ~-------_ _---------
--..;.-----_ ...
-- Constantes definidas para el manejo de retardos de los
.. bloques de la interfaz
-----------;,,;.--------~------------~-~----~---------------------
constant cRet.ardo :: natural := 1:

================:,==========-==================:::=========:=====
-- TIFOS
===============================================================:::
-----------------------------:------ ... --.--~.-... --------------_ .... _--
-- Tipos definidos para el manejo.de los filtros (FIRl y FIR2)
---------~~---- -~.-
... ... _-------------...;------~~----------: .... -- ....... ~.--,.;.--
subtype tCoefPiÍliibra 1s stq_logic_vector
(cBitsCoef - 1 downto O):
type tCóefsVector 1s array (integér range <»
af tCoefPalabra;
subtype tDatoPalabra 1s std_logic_vector
(cBitsDatos - 1 dow.nto O):
type tDatosVector 1s array (integer range -o-
of tDatoPalabra;
subtype tNo:nnaPalabra 1s std_logic_vector
(cBitsNo:nna - 1 downto O):
type tAcceso2 is array(O to cPalabrasPorAccés02 - 1)
of tDatoPalabra;
type tAcceso2Vector is array (integer ranga -o-
of tAcceso2;
type tAccesolDatos is array (O to cPaJ_abrasPorAcceso1 - 1)

of tDatoPalabra:
type tAcceso1VectorDatos ia array(integer range -o-
of tAcceso1Datos;
type tAcceso1Coefs ia array(O to cPalabrasPorAcceso1 - 1)
of tCoefPalabra;
type tAcceso1Vectorcoefs is array(integer ranga <»
af tAcceso1Coefs;
-- Tipos definidos para la interf~ con la CPU.

-----------------~------.-~------------'....:------_._-_ ..._--- .....--_ .....__ __,;.;...
subtype tDireccCPU 1s
std_logic_vector(cAnchoBusDirecs - 1 dow.nto O)i
subtype tDatosCPU 1s
std_logic_vector.(cAnchoBusDatbs - 1 downto Ol:
aubtype tBusCPU is
std_logic_vector(cAnchoBuSCPU - 1 downto O);
-- Tipos definido$ para el manejo del. <letector de máximo
subtype tElemIntervalo 1s
stQ_logic_vector(cBitsMaxNumMuestras - 1 dow.nto O):
type tIntervalo 1s array (1 dow.nto O)
of tElemlntervalo;
type tBancoDeIntervalos i8 array (O to ~Intwal. ~ Jl
of tIntervalo¡ "
type tBancoDeMáximos i8 array (O to cMaxlnterval - 1)
of tDatoPalabra:
type tBancoDePosiciones La array (O to eMaxInterval - l}
of tElemIntervalo:
type tBancoDatosDet is array (1 te cNun1Detectores)

af tDatosCPU¡
subtype tEl~er;vsDet iB
stcl.log.t'c...;vector (CBitsMaxI~tervq.J,. - 1 downta Q);.
type tVectorlntervsDet iB array (1 te cNuffibetectores) c, ,
. .. af tElemInterv,sDet;
type tVectorCtrlnet' La array (1 te cNumDetectores)
af std_logic;
=!:::===========~=:z===::*=c:::::=============.:==::=:::::,:!::r:-=:;:;:,_;: ..~*c:==
..- FUNCI~
================;=====:===========:========:====================
--"~--:'-::;;'';'':'";::-::-----------------::-''_--------:,:.:
...
-:.'''_''::~,
..-~~-:t.r:r--------
-- Calcula el. logaritmo en base 2 del parámetro
----------------------------------------------------_'--;.. .. ~_,.~:"l'"
functiOl1 log~ (Etapas : integer) retuzn integer;
constant cAnchoAculIIl : integer := caítstatos +

cBitsCoet +
lqg2 (cMaxNumEtapas1) i
constant cAnchPAcum2 integer:= eBitsDatos +
cSltsCoef +
t6g2 (cMaxNuínEtapas2) ¡
end TiposBasicos;
LISTADO 6-15. Código del paquete de definición de constantes y tipos básicos.
Nótese que en el fichero, además de incluir constantes y definiciones de tipos,

se incluyen también funciones que permiten generar, a partir de las constantes,
otros valores o estructuras de datos que facilitarán la posterior descripción de los
módulos. En algunos casos, como se explicará posteriormente, será necesario defi-
nir tipos de forma local en los ficheros que definen cada unidad funcional. Con
objeto de facilitar el mantenimiento de este fichero, y puesto que en un diseño de
mediana complejidad se generará un gran número de constantes y tipos, conviene
definir una nomenclatura clara para los mismos. En los siguientes apartados se dan
algunas recomendaciones en este sentido.
6.5.3.2. Selección de parámetros

Uno de los aspectos críticos al realizar un diseño genérico es la selección de los pa-
rámetros que pueden ser variables en el diseño y que, por tanto, serán incluidos en
el fichero de tipos básicos y constantes. Como criterio general se puede decir que
deberían definirse como valores genéricos todas las constantes que aparecen en el
código. En un principio, este planteamiento podría parecer exagerado, ya que posi-
blemente existan algunos valores que, con toda seguridad, no van a cambiar. En
cualquier caso, estos valores siempre pueden dejarse constantes, y es más interesan-
te que aparezcan en el código como nombres, que no como un número cuyo valor
puede no comprenderse.
El código del siguiente listado muestra un ejemplo de la definición de la enti-

dad de un filtro digital en el que se han incluido como parámetros todo lo que
podría ser variable (el significado de las constantes y su valor está definido en
el fichero de constantes y tipos básicos, Listado 6-15).
1ibrary IEEE;
use IEEE. st<LlogiG_1164. al1;
use IEEE.st<Llogic_arith.al1;
use IEEE.std_logic_signed. al1;
use WORK.BasicTypes.al1;
use STD.textio.al1;
entity FIRl is
ganarie (
gBitsDatos : natural. :,;: cBitsDatos¡
gBitsCoef :. natl,l.ráf:;, cBitsCoef¡
gBitsNoIIDa :- nat%~::= éBitSNorm¡¡,i
gMaxNumEtapas : ruiturlií'·: = hlaxNumEtapas1 ¡
gMaxNumAccesos natural .:= cMaxNumAccesos1¡
gPalabrasPorAccesc natural .: = cPalabrasPorAcceso1
J;
port(
RelojFIR in st<Llo~'ic;.
InicioN in std_logic¡·
_ Interfaz de Configuración
Accesos in integer range O to gMaxNumAccesoll·--: 1;
CargaCoet in std_logic;
NunCoef in integer range O to gMaxN1.mlEtapas- l;
CoefIn in tCoefPalabra;
Norntapal' in tNoIIDal'alabra;
_ Interfaz de Operacióri
NuevoSensorlZi in stq).ogic;_
NuevaMuestraIn in std_logic;
DatoIn in tDatoPalabra¡
DatoOut out tDatoPa1abra¡
NuevaMuestraOut out st<Llogic¡
NuevoSensorOut out st<L1ogic¡
Error out boolean
J;
end FIRl¡
architecture FUNCIONAL
af FIRl is
begin
end FUNCIONAL;
LISTADO 6-16. Ejemplo de entidad genérica de un filtro digital.

Si no se quieren variar los valores de los parámetros en ningún caso, este pro-
cedimiento simplemente aporta una mejor organización del diseño y una mayor le-
gibilidad del código.
Si se desea que el componente funcione para diferentes valores de los paráme-
tros, habrá que escribir el código en consecuencia. Esto requiere analizar qué valo-
res son aceptables, dependencias entre los parámetros, etc. En la mayoría de los
casos, esto no presenta problemas, especialmente si se ha diseñado una buena
estructura de datos. Sin embargo, existen algunos casos donde la generalización
resulta un tanto engorrosa. El siguiente código muestra un ejemplo típico.
-,..._------.... _----~:_---------------_.-----------------_ ... ----_----_ .. _-----------

.-- El registro interno es mayor que el de datos del micro.
-- Leo parte alta y .baja
-----------------------.----_-- ....
'""~--_:_-~----~~---------------------of------ _
COOD1: if gBitsMaxNumMuestrqs"> gAnchoBu~tos generate
LECI'URA1: process (Sefecclon, teerParteAlta, BancoMuestras, NumIntervePul
begin
DatoOut <= (others => 'O ' ) ;
if LeerParteAlta = 'O' then
DatoOut <= BanCOMuestras(NumIntervCPU)
{gAnchoBuspa.tos - 1 datmto O).;
else . "_'. .. . .. :.. , '.... ".
DatoOut(gBitsMaxNumMuestras - gAnchoBusDatos - 1 downto O)
<~ BancdMUestras(NumIntervCPU}'
. (gBitsMaxNumMl.1estras - 1 datmto
gAnchoBusDatos);
end if:
end if;
end process LECTURA1;
end generate:
---------------------...,.--------- ...---'--,...-----_..._ .._-.-.!--;..¡,--- ....-,---~--~---------

-- El l:wI de :muestras es menor que' .el de datos. deLmicro.
-- Sólo hay parte baja
COND2: if gBitsMaxNurnMuestras<= g/Il.).ChO~SDatosgenerate

LECTURA2 : process (Seréccion,' LÉiérParteAlta, BancoMuestras; NuInIntervCpur
begin . _,
DatoOut <= (others => 'O');

DatoOut{9BitsMaxNumMuestras - 1 downto. O)
<= BancoMuest~as(NumlntervCPUI;
end if;
end process L~;
end generate;
LISTADO 6-17. Diferentes tamaños en buses.

En este componente existen unos registros internos que pueden ser leídos por
una CPU. El tamaño de los registros es parametrizable y su ancho no guarda rela-
ción con el ancho del bus de la CPU. Esto obliga a distinguir dos casos, el caso en
el que el ancho del bus de la CPU sea menor que el de los registros o el caso en el
que sea mayor o igual (ver código Listado 6-17). Incluso en el caso en el que el bus
de la CPU sea menor que el ancho de los registros, cabría plantearse que los regis-
tros fuesen de un tamaño tal que el acceso por parte de la CPU tuviese que hacerse
en tres o cuatro ciclos. Esto obligaría a considerar nuevos casos en la escritura del
código.
Al elegir los parámetros conviene, por tanto, imponer restricciones realistas a
los valores que pueden tomar los parámetros, de forma que exista un equilibrio en-
tre el coste del desarrollo y los beneficios previsibles.
Una posible regla para seleccionar qué parámetros incluir sería entonces con-
siderar todas las constantes que aparecen en el diseño, para escoger con cuidado
los márgenes de variación de los parámetros cuando éstos modifiquen la funcio-
nalidad (en el ejemplo mostrado se consideró que era conveniente mantener la
posibilidad de que el ancho de los registros fuese mayor o menor que el del bus
de la CPU).
6.5.3.3. Particionado del diseño
El particionado del diseño puede influir, desde el punto de vista del diseño genéri-
co, en dos aspectos fundamentales. Por un lado, va a influir en las estructuras de
datos (los tipos de las señales) que sean necesarios en el diseño, ya que la partición
influye en el número y tipo de señales que se comunican entre bloques. Por otro
lado, el cómo se realice la partición y se distribuyan las unidades funcionales en
los bloques va a determinar la facilidad o dificultad con la que se realicen modifi-
caciones al diseño. Es decir, la facilidad con la que podrá hacerse que los paráme-
tros puedan cambiar su valor y, por tanto, que el diseño genérico resulte realmente
útil.
El particionado óptimo depende en gran medida de la aplicación que se esté
considerando, aunque pueden darse una serie de recomendaciones útiles.
La mayoría de los bloques funcionales disponen de unidades operacionales
(ALUs, multiplicadores, etc.), registros programables y señales típicas de control
para la carga o lectura de los registros y para la sincronización de las operaciones.
Una partición que da buenos resultados consiste en establecer una jerarquía donde
las unidades operacionales están separadas de los registros y de un posible interfaz
con el resto del sistema.
La ventaja de un particionado de este tipo es que las posibles modificaciones
estructurales afectan a un número pequeño de bloques. Sin embargo, estas solucio-
nes no son siempre válidas o fácilmente aplicables. En cualquier caso, conviene que
el número de bloques no sea excesivo (tres o cuatro es un buen número).
El particionado puede influir en la ubicación y conexionado (place and route)
y, por tanto, en las prestaciones en cuanto a velocidad. Este aspecto debe ser tenido
en cuenta para no hacer que el diseño genérico comprometa las prestaciones.
6.5.3.4. Estructuras de datos
Cuando se realiza un diseño genérico se debe prestar gran atención a la definición

de la interfaz (port) en las entidades. Las ventajas del diseño genérico se pierden si
al modificar el valor de algún parámetro cambia la interfaz de un componente y, por
tanto, se tienen que editar los ficheros en donde intervienen.
En la medida de lo posible debe lograrse que cualquier modificación de los
parámetros, dentro de sus valores permitidos, sólo implique una recompilación del
código, pero nunca una reedición del mismo (salvo, claro está, el fichero de tipos
básicos y constantes).
Para conseguir este objetivo deben generarse estructuras de datos de forma
adecuada. En este sentido, puede ser interesante hacer uso de estructuras tipo vector
de vectores o estructuras tipo registro (record) . Sin embargo, aunque la herra-
mienta de simulación y síntesis pudiera trabajar adecuadamente con estas estructu-
ras (no es posible en muchas de las herramientas actuales), es necesario comprobar
que el interfaz con las herramientas de back-end (básicamente herramientas de dise-
ño físico y simulación a nivel de puertas) se realiza de forma adecuada.
En el código que sigue se muestra un banco de coeficientes de un filtro digital
que opera en varios ciclos de reloj. Esto requiere acceder a diferentes partes del
banco en cada momento, por lo que resulta idónea una estructura matricial. El nú-
mero de ciclos que tarda en ejecutarse la operación, así como el tamaño final del
banco de coeficientes y el número de bits de éstos, estarán definidos en el paquete
de tipos básicos y constantes (ver Listado 6-15) y podrán determinarse posterior-
mente.
library IEEE;
use IEEE.std_logic_1164.all;
use WORK.BasicTypes.all;
entity FIR1_REDS i8
generle(
gBitsDatos : natural := cBitsDatos;
gMaxNumEtapas r natural := cMa:XNumEtapásl;
gMaxNUmAccesos natural := cMaxNumAccesosl;
gPalabrasPorAcceso : natural := cPalabrasPorAccesol
);
port(
RelojFIR in std_logic;
InicioN in std,,_logic;
NuevoSensorln in stc(logic;
CargaRegs in std_logic;
Datoln in tDatoPalabra;
RegsOUt out tAccesolVectorDatos(Q to gMaxNumAccesos - II
);
end FIR1_REGS;
arehitecture of FIR1_REGS Is
FUNCIONAL
----------------------~----------~-------~---~-----:~~.----:------------..,-
-- Banco de registros del filtro
signa! BancoReg:s tDa,tosv~,~9r(O to gMaxNumEtapas -:J.). ¡
begin
FOR1 for i in O to gMaxNwnAccesos - 1 generate

FOR2 for j in O to gPalabrasPorAcceso - 1 generate
RegsOUt(i) (j) ~= BancoRegs(i*gPalabrasPorAcceso + j)¡
end generate;
end generate;
-~~-----------------------------------------------~------------------
-- Carga serie de los datos
----------------------'!""--------------------------,...~,~----- ....
------- ........
--
LOAD : process(RelojFIR, IniciON)
begin
if IniciaN = '0' tban
for i in O to gMaxNurnEtapas - 1 loop
BancoRegs(i} <= (others => '0');
end loop;
elsif RelojFIR' event and Reloj FIR =",
i: then
if CargaRegs = '1' then
BancoRegs (1 te gMaxNumEtapas - 1) <=
BancoRegs (O to gMaxNumE~ - A) ¡
BancoRegs (O) <= Da,toln;
end if; .
if NuevoSensorln = '1' then
for i in 1 to gMaxNurnEtapas - 1 loop
BancoRegs (i) <= (others =>. 'O') ;
end loop;
end if;
endif;
end proceSB;
end FUNCIONAL;
LISTADO 6-18. Utilización de tipos complejos.
El siguiente ejemplo muestra un bloque decodificador para el acceso por parte

de una CPU a diferentes registros de un circuito.
-- Esta definición está en el paquete

-- de tipos básicos y constantes
type DecosSelRecord i8 record
CargaRegsFir std_logic;
CargaRegsConf std_logic;
CargaRegIntr std_logic;
CargaRegsCoef std_logic;
LectBancoMuestras std_logic¡
end record;
entity Decod la
port(
DirecCPU in std_logic_V'eCtorlg-BitsDirecCPU - 1 downto O} ¡
EscrN in std_logic;
Seleccion out DecodSelRecord
};
endDecod¡
LISTADO 6-19. Utilización de estructuras tipo registro.
En este caso, las señales de selección se han incluido en una estructura tipo regis-
tro (record). De esta forma, una posible inclusión futura de una señal de selección no
modifica la interfaz, reduciendo el riesgo deerrores. La definición de las señales que
contiene la estructura record se realiza en el paquete de tipos básicos y constantes.
El objetivo de estas estructuras de datos es que sean lo suficientemente flexi-
bles como para permitir cómodamente la variación de los parámetros. Al mismo
tiempo deben facilitar el que posibles modificaciones afecten al menor número
posible de ficheros o entidades. "
6.5.3.5. Otras recomendaciones sobre la codificación

La codificación en VHDL de componentes genéricos presenta algunos problemas
de tipo práctico que es necesario solucionar. En los siguientes apartados se dan
algunas soluciones a problemas típicos que aparecen al realizar diseños genéricos.
6.5.3.5.1. Problemas con los buses

Al hacer genéricas las dimensiones de los buses aparecen, en algunos casos, proble-
mas de compatibilidad entre señales. En el siguiente ejemplo se muestra un caso típi-
co donde se asignan dos señales de dimensiones diferentes e independientes entre sí.
LECTURA2: process (Sélecci6n~ BaricóMuestras," NumIn.tétvePu)

:begin
DatoOut <= (otbers => 'O')¡
if Seleccion = '1' then .
DatoOut (gBitsMaxNumMuestra§ - 1 downto O)
<= BancOMuesfras (NurnlntervCPu) ;
end if¡
LISTADO 6-20. Asignación de buses con diferentes tamaños. Puede dar lugar a
errores.
Si el tamaño de la señal BancoMuestras (que viene determinado por la cons-

tante gAnchOBusDatos), es menor que el tamaño de la señal DatoQut (determinado
por la constante gBitsMaxNumMuestras), la asignación será correcta. Sin embargo,
si el tamaño de BancoMuestras es mayor que el tamaño de DatoOut ocurrirá un
error al intentar simular o sintetizar el diseño.
En este caso es necesario considerar las distintas posibilidades y generar códi-
go en consecuencia (o bien limitar los márgenes de variación de los parámetros
gBitsMaxNumMuestras y gAnchoBusDatos).
El método más sencillo para hacer esto es utilizar sentencias tipo genera te. El
siguiente segmento de código muestra el mismo ejemplo corregido para aceptar
diferentes tamaños de las señales.
-- E]_ registro iritemo es iriáyor-que;erde datos .de! mero'

-- Leo parte 'alta y baja
------------------_._------.-....;------.-....;~--,.;..- ....
_.,..-------.--------.;...-.--~--+-- ....-...-- ...
COND1: if gBitsMaxNumMuestras > gAnchoBusDatos generate
LECTURA1: process(Se1eccion, LeerParteAlta,
begin ....
BancoMuestras, Numlnte~U) .

if LeerParteAlta = 'o' then
DatoOut <= BancoMuestras(NurnlntervCPU)
(gAnchoBusDatos - 1 downto O);..
else
DatoOut.(gBit!lMaxNumMuestras - \J,&lchoBusDatos - 1 downto O)
<= BarlcoMUéstras(NumlntervCPüj
. (gBitsMaxNumMuéstras - 1 downto
gAnchoBusDatos);
end if;
end if;
end process LECTURAl;
end generate;
r-:- :E;:¡' bJs de ~~~tras. ~)llel}pr_ CW~ ~l.~ ,~tos ~l mi.cro.

. -- Solo hay parte fuaja
COND2: if gBitsMaxNuffiMuestras <= gAnchoBusDatos generate

LECTURA2 : process (Seleccion, BancoMUestras, NumlntervCPU)
begin
DatoOut(g~it~uestras - 1 downto Ol
<= BancoMuestras (NumlntervCPU) ;
end if;
end generate;
LISTADO 6-21. Utilización de sentencias generate para evitar errores de ancho de

bus.
Es necesario hacer notar que una solución alternativa mediante if condition

then dentro de un proceso no será válida. Si lo hiciésemos así, el error antes
comentado no quedaría solucionado, ya que la valoración de la condición ir se
realiza en tiempo de simulación y, por lo tanto, durante la elaboración se podría
producir error si la dimensión de BancoMuestras es mayor que la de DatoOut.
6.5.3.5.2. Problemas de definición de los tipos

Para simplificar la escritura del código se hace interesante, en muchas ocasiones, la
definición de tipos estructurados (vectores, registros, etc.). Cuando estos tipos
dependen de algún parámetro puede ocurrir que su definición dé lugar a errores. En
el siguiente código se muestra un ejemplo de este tipo.
-- Esta definición esta en el paquete de tipos básicos

type tBancoMUestrPrevias la array (O to cMaxInterval - 2)
of tDatoPalabra¡
,
--------- ....
----- ....
:--::r""~'!""Í,--~---------~-------- ...-----~,~,::"'-::~.i,rt~-:~-:.---:~.
aigIlal MuestraPrevia: tBaric~estrPréviasi
LOA_2 : process (R~l(.)jFI~ +ni9,i;p~( ..C~~, ~j.mo, NlJmInt~l)et)-

begin
if InicioN =
'0' then
MuestraPrevia <= (others => (others => ' O' 1) ¡. .
BancoMuestras <= (others => (others => ' O' )) ¡ ... ~
elalf RelojFIR'event and RelojFIR = '1' then
lf CPUReq= ' r
then
for i in O to gMaxInterval - 2 loop
BancoMuestras (í). <=
MuestraPrevia (i) ¡
end loop¡
BancoMuestrast~ntervDet) <= Maximo¡
end if¡
end if;
end process;
LISTADO 6-22. Problemas con la definición de tipos.
En el Listado 6-22 la definición del tipo tBancoMuestrPrevias depende de

la constante cMaxInterval que podría valer 1. Si esto ocurriese, la definición
sería incorrecta, puesto que la dirección de los índices del vector no es correcta (de
hecho el tipo tBancoMuestrPrevias no debería generarse en dicho caso). Para
solventar este problema debe definirse el tipo dentro de una estructura block. En
el siguiente segmento de código se muestra un ejemplo de cómo se ha resuelto el
problema.
GENER2 : if gMaxlnterval > 1 generate

B: BWCK
type tBancoMuestr!'revias is array (O.to ~~~qt - ~k.
of tDatoPalabra; .... >. ,.. •
signal MuestraPrevia ! tBancoMuestrPrevias;

begin
LOA_2 : procesa (RelojFIR, IniciON)
begin
if InicioN = '0' then
MuestraPrevia <= (others => (others => '0'-));
BancoMuestras <= (others => (others => 'O'));
elsif RelojFIR'event and Re10jFIR = '1' then
if CPUReq = ' l' then
for i in O to gMaxlnterval - 2 loop
BancoMuestras(i) <= MuestraPrevia(i);
end loop;
BancoMuestras(NumIntervDet) <= Maximo;
end if;
end if;
end process;
end BLOCK B;
end generate;
LISTADO 6-23. Solución utilizando tipos locales dentro de sentencias block.
6.5.3.5.3. Síntesis y optimización

En los diseños genéricos existen unidades funcionales o segmentos de código que
deben generar hardware en unos casos y en otros no. Normalmente esto se llevará a
cabo mediante sentencias de tipo if condición generate o mediante sentencia if
condición then donde la condición a evaluar es una constante. El siguiente código
muestra un ejemplo de ambos casos.
GENl : if cImplDetMax generate

MAX_DET : DetectMaxirnos
port map (
Reloj => Reloj; ,;.c
IniciON => lIii.cioij;
...
SelRegsMax => seíeccíoii,SelRegsMax;
DatoOut => BUSCPU;
end generate;
PPRAL : process (Reloj, IniciON).

begin
if IniciON = '0' then
elsif Eeloj'event and Reloj = '1' then

if cCheqBancoGen then
-- Código generado si cCheqBancoGen '"true
else
-- Código generado en caso contrario
end if;
end if;
end process;
LISTADO 6-24. Generación condicional de unidades funcionales.
En el primer caso (sentencia genera te) el segmento de código no es sinte-

tizado si la condición de la sentencia generate no se satisface. Si se utilizan
construcciones del tipo if cond g~nerate, el proceso de síntesis, al resultar los
valores constantes, elimina la lógica que, en un principio, surgiría del modelo RT
sintetizado.
Debe tenerse en cuenta que, en ambos casos, es necesario que los datos a eva-
luar sean declarados como constantes. En el siguiente ejemplo uno de los datos es
declarado como variable inicializada a un valor constante mediante una función
(que devuelve cierto o falso en función de una estructura de entrada donde se defi-
nen las diferentes configuraciones del diseño).
PPRAL : procesa (Reloj, InicioN)

variable vCheqBancoGen : boolean :.= cObtenOpclIlplemt (gOpci9I_l~SJi
begin
if InicieN = 'O' then
elsif Reloj 'event and Reloj = '1' then
if vCheqBancoGen then
- Código generado si c~soGen ~ trye
else
- Código generado en ;ca.Socontrario
end if;
endif;
end process;
LISTADO 6-25. Generación condicional errónea de unidades funcionales.
Los sintetizadores no consideran normalmente la inicialización en las variables

y las señales y, por tanto, les asigna inicialmente un valor por defecto. Al sintetizar el
código nunca se generaría el código correspondiente a la condición vCheqBancoGen
= true ya que esta variable toma siempre su valor por defecto (false).
6.5.3.5.4. Funciones de inicialización

En algunos casos puede ser interesante utilizar funciones para inicializar parámetros
utilizados en el diseño. En el siguiente ejemplo, la función cObtenlnicIntervalos() ge-
nera una estructura con valores de inicialización para una serie de registros.
type tMinMax ls array(O to 1) of lnteger;
type tInicIntervalos ls array (O to gMaxIntezya). - 1) of tMinMax;
architecture FUNCIONAL of. ~~s ls

constant ValorInic : tInicÍntervalos .-
gObtenIni~te+v;~¡Q'l'ip,p~q),,;
, ,,-,~. , -:-Sl'l':!.PoInic::c üPO_Qe j¡ni~alizaci6n
signal BancOInterváIüS :" tBartcbDel:ntérvai6lt;

begin
PPRAL : process (Reloj, InicioN)

begin
lf InicioN = 'O' than .
for i in O to gMaxIntervai~:- 1) loop
BancoIntervalos(i) <='Wlorlnic(i);
end loop; ,
elsif Reloj'event and Reloj = '1';
end if;
end process;
end FUCIONAL;
LISTADO 6-26. Utilización de funciones para generación de constantes.
De esta manera, el código puede resultar más legible y se tiene más libertad
a la hora de calcular los valores de inicialización al no tener que ser la función sin-
tetizable. Sin embargo, hay que resaltar que, aunque la función no vaya a generar
hardware, en algunos sintetizadores debe escribirse con construcciones sintetiza-
bles. Esto supone no utilizar cierto tipo de sentencias, como son:
• Sentencias while cond loop. Deben ser sustituidas por sentencias for rango
loop junto con sentencias if not cond then exi t.
• No inicializar las variables en la parte declarativa de las funciones. En su ca-

so, inicializar las variables en el cuerpo de las funciones.
• No utilizar ciertos atributos no soportados por la herramienta de síntesis
(ej. 'POS). En su lugar utilizar otros procedimientos.
De cualquier manera, antes de realizar este tipo de funciones debe comprobarse

que el sintetizador las acepta e interpreta correctamente. En caso contrario deberán
buscarse otros procedimientos para inicializar los parámetros.
6.5.3.5.5. Nomenclatura
Cuando se realizan diseños genéricos, se generan una gran cantidad de constantes y
tipos. Es necesario establecer un criterio claro para nombrar estos tipos y datos, ya
que, de lo contrario, es fácil perderse en el significado de cada nombre. Esto se hace
más importante cuando el equipo de diseño está formado por varios diseñadores.
A continuación se dan algunos ejemplos de este tipo de reglas.
• Nombres de genéricos: llevarán el prefijo g. Ejemplo: gMaxMemBloques.
• Nombres de constantes: llevarán el prefijo c. Ejemplo: cBitsBusCPU.
• Ancho de buses: cBitsNombreBus.
• Máximo valor de datos: cMaxNombreDato.
• Número de bits para codificar datos: cBitsMaxNombreDato.
• Último valor de un dato: cUltimoNombreDato.
• Declaración de tipo: utilizar el prefijo t. Ejemplo: tBusCPU.
En el Listado 6-15 se muestra un paquete de definición de tipos básicos y cons-
tantes utilizando estas reglas. Conviene hacer un análisis detallado al principio del
proyecto de los datos y estructuras a utilizar con objeto de generar unas normas cla-
ras y sencillas en este sentido.
6.6. DISEÑOS CONFIGURABLES
Entendemos por diseño configurable aquel que posee ciertos parámetros que, al va-
riarlos, modifican la funcionalidad a nivel RT del componente. En este sentido, el
diseño configurable implica un grado mayor de flexibilidad que el diseño genérico.
Como ejemplo podemos fijarnos en la Tabla 6-7. Esta tabla recoge los paráme-
tros de configuración de un diseño configurable de un transmisor/receptor serie
asíncrono. Como puede verse en la tabla, existen una gran variedad de parámetros
que permiten múltiples configuraciones con muy distintas características. Seleccio-
nando los parámetros adecuados podríamos configurar un transmisor, receptor o
transmisor/receptor, con frecuencias de funcionamiento fijas o programables, con
longitudes de palabra fijas o programables, etc.
Como resultado, en una tarde, un diseñador podría estudiar varias alternativas,
analizar su coste y escoger la solución más adecuada a su diseño.
Los diseños configurables poseen ventajas parecidas, e incluso mayores, que el
diseño genérico en cuanto a la evaluación de alternativas, análisis y organización
del diseño, simplificación del cambio de tecnología, etc. Pero de igual manera que
comparte las ventajas, también comparte con el diseño genérico los mismos proble-
mas, acentuados además en algunos casos. La complejidad del código es mucho
mayor en los diseños configurables que en los diseños genéricos. Asimismo, la difi-
cultad de las pruebas y el tiempo de desarrollo crecen de forma exponencial con la
TABLA 6-7. Parámetros de configuración de un transmisor/receptor asíncrono
Parámetros del TRANSMISORlRECEPTOR

Codificación de la señal NRZ, NRZI o programable
Paridad Odd, Even o programable
Longitud del dato 5, 6, 7, 8 o programable
Bits de parada 1, 1,5,2 o programable
Frecuencia base 4,9152,6,8, 10, 16,20,25,32,40 MHz
Preescalado del reloj Programable o no programable
Frecuencias TxIRx Con preescalado ° modo tabla
Fuente de reloj Interna, externa o programable
Frecuencia de muestreo '2, 4, 8, 16 muestras/bit programable ¿
Parámetros del TRANSMISOR
Buffer de transmisión Sí o no
Tamaño FlFO (O-N), N = natural
Modos de interrupción Ninguno, al escribir, al final, ambos
Parámetros del RECEPTOR
Buffer de recepción Sí o no
Tamaño FlFO 0-10
Errores detectados Ninguno, sobreescritura, error de formato, error de paridad, todos
Modos de interrupción .Ninguno, error, dato recibido, ambos
Modo Wake-Up No, sí o programable
Dirección Receptor Programable o no programable
Ciclos por bit 1,2,4,8, 16 o programable
configurabilidad del componente. Por otro lado, las prestaciones alcanzables con
los diseños configurables pueden ser menores que las que se alcanzan con los dise-
ños genéricos, ya que deben buscarse más soluciones de compromiso.
6.6.1. Desarrollo de un componente configurable
Al contrario que los diseños genéricos, los diseños configurables no son nunca un
resultado colateral de un proyecto, sino que son el resultado de un proyecto concre-
to de realización de un componente de biblioteca.
6.6.1.1. Selección de los parámetros de configuración
Uno de los problemas fundamentales en el desarrollo de un componente configura-

ble es su especificación. La especificación de un componente configurable requiere
no sólo la especificación de la funcionalidad (o funcionalidades del componente),
sino también de la especificación de las opciones de configuración. Es necesario
decidir qué características del diseño serán configurables y cuáles no, y para cada
una de esas características hay que especificar qué posibles valores pueden tomar
los parámetros.
Estas decisiones requieren un conocimiento profundo de las aplicaciones a las
que va a estar dedicado el componente, y de la complejidad del desarrollo del com-
ponente en función de sus parámetros. Como ejemplo podemos fijarnos en los pará-
metros del transmisor/receptor serie asíncrono mostrados en la Tabla 6-7. Como ve-
mos, existe la posibilidad de configurar el componente con 1, 1,5 Y2 bits de parada.
Con esta posibilidad se cubren prácticamente todos los modos de funcionamiento
(en cuanto a bits de parada) de los transmisores/receptores existentes en el mercado.
Con ello tendremos un componente que se puede adaptar a cualquier requerimiento
de un potencial usuario. Sin embargo, un análisis detallado de los componentes
existentes en el mercado nos indicará que el número de transmisores/receptores con
1,5 bits de parada es relativamente pequeño comparado con los que sólo poseen 1 o
2 bits de parada. Por otro lado, el hardware necesario para introducir 1,5 bits de
parada supone un incremento considerable de lógica y complejidad respecto al
necesario para implementar sólo 1 o 2 bits de parada. Como resultado podríamos
concluir que es económicamente más viable realizar un componente configurable
que no incluyese la posibilidad de implementar 1,5 bits de parada.
Este tipo de análisis, que debe ser realizado para todos los parámetros del dise-
ño, supone una de las mayores dificultades de los diseños genéricos; si el compo-
nente no es 10 suficientemente flexible, puede resultar inútil para algunas aplicacio-
nes; si el componente es demasiado configurable, su coste de desarrollo puede
hacerlo prohibitivo. El riesgo principal de esta selección es la sobreespecificación
de los parámetros (seleccionamos más parámetros de los necesarios). Seleccionados
los parámetros y los posibles valores para cada parámetro, la especificación debe
incluir la funcionalidad que debe cumplir el componente en cada configuración.
6.6.1.2. Aspectos a considerar en la generación de componentes

configurables en VHOL
Existen una serie de consideraciones que es necesario plantearse a la hora de desa-
rrollar un componente configurable en VHDL.
• Diseño: como consideración más importante, es necesario tener en cuenta

que, en general, no es posible hacer un sistema configurable y óptimo al mis-
motiempo, El precio a pagar por la flexibilidad y el ahorro en tiempo de di-
seño suele ser un diseño menos óptimo (al igual que ocurre con los diseños
asíncronos y síncronos).
• Pruebas: los diseños configurables son diffciles, de comprobar exhaustiva-

mente mediante simulación. El número de configuraciones posibles suele ser
muy elevado y la verificación de todas las posibilidades se hace prohibitiva.
Como se verá, un particionado adecuado puede reducir este problema.
• Legibilidad: las descripciones de los componentes configurables son bastan-
te complejas. El código extra que hay que añadir para permitir las configura-
ciones y el particionado que es necesario realizar para facilitar el diseño con-
figurable dificultan mucho la extracción de la funcionalidad a partir de la
lectura del código. Una buena documentación y buenos comentarios en el
código reducen algo este problema.
• Mantenimiento: para que la inversión en el desarrollo de la biblioteca no
sea inútil, es necesario facilitar la tarea de añadir o quitar funcionalidad al
componente (actualización, corrección de errores, etc.). Esto supone tener que
prestar especial atención a la estructuración del código.
• Tecnologías destino: en general, es necesario desarrollar la biblioteca consi-
derando una determinada tecnología sobre la que sintetizar. Si las tecnolo-
gías sobre las que se va a sintetizar el componente dependen también de
algún parámetro, el problema se complicaría aún más.
6.6.1.3. Diseño arquitectural
Con objeto de simplificar el desarrollo de los componentes, especialmente si el nú-

mero de parámetros que poseen es elevado, es necesario estudiar a fondo cómo se
va a partir el diseño.
Como norma general, se debe hacer el diseño de los módulos partiéndolos en
bloques (ver como ejemplo la Figura 6-13) de manera que cada bloque se vea afecta-
do por un solo parámetro (o dos como máximo). Así se simplifica el proceso de veri-
ficación, ya que no es necesario comprobar todas las configuraciones posibles del
diseño sino las configuraciones posibles de cada bloque (una configuración es un
implementación particular donde los parámetros toman unos determinados valores).
Para realizar la partición, es necesario realizar un estudio exhaustivo de las
posibilidades de configuración. De tal análisis debe extraerse, por un lado, cómo
afectan los parámetros, identificando aquella funcionalidad común a todas las
configuraciones y, por otro, aislar las funciones afectadas por cada parámetro.
Además debe definirse un modo de comunicación entre procesos, identificando el
mínimo número de señales necesarias y definiendo un protocolo para la comuni-
cación entre bloques. Los bloques deberían resultar lo más independientes entre sí
como sea posible.
Este enfoque simplifica el proceso de verificación, ya que los bloques funcio-
nan independientemente de la configuración elegida. Además, puede simplificar el
diseño, ya que se pueden aislar los problemas (en general sólo afectarán a un blo-
que). Por último, este modo de diseño facilita el mantenimiento y la modificación
del código al resultar las descripciones menos intrincadas.
Captura de Control principal

interrupciones
(BCLRON o BCLROFF)
(PR o RR) (TRUE/FALSE)
cGenintStatus, cirqDtack
FIGURA 6-13. Ejemplo de partición de un diseño configurable.
El inconveniente principal, aparte de que una partición de este tipo no siempre es

posible, es la pérdida de prestaciones en el diseño. Para simplificar la comunica-
ción entre bloques es necesario en muchos casos definir un protocolo de comunicación
tipo handshake, lo que obliga a perder ciclos de reloj. Por otro lado, en algunas oca-
siones conviene repetir parte de la lógica que ya existe en un bloque, en otro bloque
diferente. De esta manera los bloques resultan más independientes entre sí, pero se
puede duplicar la lógica y, por lo tanto, aumentar el área del componente.
6.6.1.4. Método de generación
Otro aspecto que debe ser considerado al realizar un componente configurable es el

método de generación. El componente configurable debe contener una funcionali-
dad diferente según sean los valores escogidos para sus parámetros.
El método de parametrización debe definir dos aspectos. Por un lado, cómo se
le pasarán los valores de los parámetros al diseño; por otro lado, cómo se tratarán
esos valores internamente para generar la funcionalidad adecuada.
Para pasar parámetros al diseño, el VHDL aporta los genéricos. Sin embargo,
la utilización de genéricos no resulta un método adecuado en la mayoría de los dise-
ños configurables. Hoy por hoy, hay pocas herramientas de síntesis que admitan ge-
néricos, y las que los admiten, sólo admiten genéricos de tipo entero. Sin embargo,
los parámetros de un diseño configurable pueden admitir multitud de valores de dis-
tintos tipos. Siempre será posible asignar un valor entero a cada uno de los posibles
valores de un parámetro, pero eso dificulta la legibilidad del código.
En cuanto a su utilización interna, el VHDL aporta las sentencias tipo if con-
dicion generate, for rango generate, así como sentencias if condicion tben y
for rango loop en procesos concurrentes. Estas sentencias pueden ser utilizadas
con relativa comodidad para realizar la lógica configurable.
En líneas generales, podemos plantearnos tres métodos para realizar la parame-

trización del componente, lo que da lugar a tres tipos de bibliotecas de componentes
configurables:
• Biblioteca cerrada: estarían formadas por un conjunto de componentes ce-

rrados de funcionalidad parecida, pero con ciertas características de imple-
mentación que los harían distintos. La generación de bibliotecas de este tipo
tendría justificación sólo cuando el número de posibles configuraciones del
componente es pequeño, es decir, depende de pocos parámetros. Esta forma
de generar bibliotecas de componentes es característica de situaciones en las
que no se ha previsto ningún tipo de planificación. La Figura 6-14 presenta
un esquema de este procedimiento de generación.
En este caso, el componente no es realmente configurable, sino que se
dispone de un procedimiento cómodo de selección para escoger entre una
serie de componentes cerrados.
• Biblioteca generada por programa: en este caso, el código VHDL asocia-

do al componente sería generado por un programa realizado en un determi-
nado lenguaje de programación (C o Pascal, por ejemplo). En función de los
parámetros introducidos por el usuario de la biblioteca se generaría un mode-
lo VHDL u otro (ver Figura 6-15). El modo de selección de los parámetros
podría realizarse a través de un entorno gráfico, o de forma textual a través
de cadenas de caracteres (mnemónicos).
Este método presenta la ventaja de su facilidad de programación y la
flexibilidad en cuanto a la selección de parámetros. Por otro lado, al poder
realizar entornos gráficos para la configuración del componente resulta más
cómodo para el usuario. El inconveniente fundamental es la necesidad, por
parte del siseñador de la biblioteca, de manejar dos entornos de trabajo: el
del VHDL y el del lenguaje de programación que se utilice para realizar
el programa.
.vhd .vhd .vhd
--- Sintetizador
--- 8
.vhd .vhd .vhd
FIGURA 6-14. Biblioteca de componentes cerrados.

config. mod.vhd
-8
FIGURA 6-15. Componente configurable generado por programa.
• Biblioteca realizada en VHDL: la generación de la biblioteca se realizaría

íntegramente en VHDL. La parametrización del sistema se llevaría a cabo
mediante unas funciones especiales (funciones de extracción de parámetros),
desarrolladas íntegramente en VHDL. Estas funciones estarían encargadas de
traducir las cadenas de parámetros introducidas por el usuario a un conjunto
de constantes VHDL, que son las que posteriormente se utilizarían en las
descripciones del componente (ver Figura 6-16).
La ventaja de este procedimiento es que se trabaja sólo dentro de un en-
torno; el diseñador sólo necesita conocer VHDL, y sólo depura y elabora un
código fuente. Sin embargo, puesto que la mayoría de las herramientas de
síntesis no soportan genéricos, es un método aplicable en pocos casos.
6.6.1.5. Bancos de prueba
Uno de los aspectos que más tiempo consume en el desarrollo de las bibliotecas
(como en el de cualquier diseño) es la elaboración de los bancos de prueba. En un
principio seda necesario desarrollar bancos de prueba para cada una de las configu-
raciones posibles del componente, pero en general eso supone un esfuerzo prohibi-
-8
~
config.vhd ~
mod.vhd
FIGURA 6-16. Componente configurable generado en VHDL.

Verificador de señal 1(st)
...
SetPattern(señal ...
SetPattern(señal wait unlil slrobe = '1 ';
CheckPattern( ...)
vectores
...
SetPattern(señal 1) Verificador de señal 2(s2)
SetPattern(señal 2)
wail unlil strobe = '1 ';
vectores CheckPattern( ...) Señal de control (c2)
...
wait unlil slrobe ='1 ';
CheckPattern( ...}
FIGURA 6-17. Comprobación automática de resultados en los bancos de prueba.
tivo. Si el componente se ha partido en bloques adecuadamente, los bancos de prue-

ba sólo deben probar cada una de las configuraciones de cada bloque por separado.
En cualquier caso, el número de yerificaciones que hay que realizar es elevado
y la comprobación resulta tediosa (lo que induce más posibilidades de «saltarse» un
error). Para reducir este problema pueden elaborarse bancos de prueba que verifi-
quen automáticamente si el resultado de las señales tras la simulación es correcto.
Esto implica que los bancos de pruebas también deben hacerse configurables,
aplicándose diferentes vectores funcionales según la configuración. Asimismo, las
salidas esperadas deben estar parametrizadas (en función de un parámetro se esco-
gen unas u otras salidas). En la Figura 6-17 se muestra un método que puede seguir-
se en este caso (UUT es el circuito bajo prueba). El procedimiento SetPattern() se
encargaría de poner los valores esperados mediante una cadena de caracteres. Dicha
cadena se puede obtener a través de una función que depende de los parámetros de
la configuración. El procedimiento CheckPattern() se encargaría de verificar los re-
sultados en base a un funcionamiento síncrono del circuito.
6.7. EJERCICIOS
1. Realizar, mediante VHDL, las especificaciones de un circuito convertidor de có-

digo BCD a 7 segmentos.
2. Realizar, mediante VHDL, la especificación del bloque ProgPrecio de la máqui-

na expendedora de refrescos del Apéndice 1 (se recomienda leer los documentos
de requisitos, especificaciones y diseño arquitectural incluidos en el apéndice).
3. El siguiente código VHDL corresponde a las especificaciones de un módulo de

un determinado diseño. ¿Cuál es la funcionalidad del bloque? ¿Cuál es el méto-
do de operación?
entity CALC_SENO is
port
a in real; -- Mt.r~ 0.0 Y 1..0
a2 in real; --: cuadrado de a.
start in std_lOgic; .
x out real r
);
eDd CALC_SENO;
architecture ALGORITMO of CALC~SENO 18

begin
CALe: process
variable k, y, z: real:
variable n: ),nteger;
constant 1: integer := 3;
begin
walt until start = '1 ';, '
k := 1; y := a; z :~ O;'n :~ O;
while n < 1 loop .
z := z + y/k; ¡h -,.s. U:O:.'L.
k := k * (k + 1) * (k + 2);
y := - a2 * y;
n := n + 1;
end loop;
x <= z;
end process;
end ALGORITMO;
4. Realizar el diseño arquitectural del circuito especificado en el problema 3. Supo-

ner que el sintetizador será capaz de sintetizar módulos divisores y multiplicado-
res. Para el diseño se recomienda realizar la operación en varios ciclos de reloj.
Se recomienda utilizar un formato de datos binario en coma fija, en complemen-
to a dos.
5. Suponiendo que disponemos de un sintetizador que no es capaz de sintetizar

multiplicadores ni divisores, pero que disponemos de tales elementos en la
biblioteca del fabricante (se dispone de sus modelos VHDL), realizar el diseño
lógico del circuito del problema 4.
6. Al final del Apéndice 11(apartado 11.6) se encuentra la descripción en VHDL de

un transmisor serie síncrono. Diseñar un banco de pruebas que verifique el com-
ponente teniendo en cuenta las inicializaciones, terminaciones, funcionamientos
y valores no considerados. Diseñar el banco de pruebas tanto mediante un pro-
cedimiento orientado a la señal como mediante un procedimiento orientado al
modo de funcionamiento.
440 VHDL. Lenguaje estándar de Díseño Electróníco
7. Realizar un diseño genérico de un contador BCD cuyo número de dígitos sea pa-
rametrizable entre 1 y 4.
8. El siguiente código VHDL se corresponde con un banco de registros de un siste-

ma de búsqueda indexada de información (parte de la palabra buscada es el índi-
ce, mientras que el resto es la información buscada). Modificar el diseño de for-
ma que sea parametrizable el número de bits de cada palabra, el tamaño del ban-
co de registros y el número de bits correspondiente al índice.
entity BANCO_INDEX i8
port (
Clk in std_logic.;
Busca in std_logic;
Indice in std_logic_vector(7 downto O);
Salida out std_logic_vector(31 downto O)
);
end BANCO_INDEX;
architecture FIJA of BANCO_INDEX iI

type RegIndex i8 std_logic_vector(7 downto O);
type RegDatos i8 std_logic_ vector (31 downto O);
signal BancoIndex i8 array(20 downto O) of RegIndex;
signal BancoDatos i8 array(20 downto O) of RegDatos;
begin .
REGS: process(Clk)
begin
if clk'event and clk = '1' then
for i in o to 20 loop
if Indice = BancoIndex(i) then
if Busca = '1' tben
Salida.<: RegDatos(i);
end if;
end if;
end loop;
end if;
end procesa;
end FIJA;
9. Realizar un diseño configurable de un contador BCD de l, 2 o 3 dígitos, que ad-

mita cuenta ascendente, descendente o ascendente/descendente, con o sin carga
paralela y con señal de borrado síncrono activa por nivel bajo o alto. Los pará-
metros del diseño serán pasados mediante genéricos de tipo entero.
6.8. BIBLIOGRAFíA
[BLUM92] M. BLÜML,B. KIERDOFF,M. LENZEN,A. PAWLAK: «A Methodology for the De-

velopment of High Quality Standard - Cell Models in VHDL», VHDL Forum
Spring'92, Santander, abril 1992.
[HAGEN] K. TENHAGEN,H. MEYR:«Generic Design: Its Importance, Implementations and

Limitations» .
[PREN96] PRENDA: Metodología de diseño de ASICs, Proyecto PRENDA, febrero 1996.
[OMI95] OMI: «OMI 326: VHDL Coding Standard», OMI Standards (ESPRIT no. 7267)
Julio 1995.
ESAlESTEC: «VHDL Modelling Guidelines», ESAlESTEC, September 1995.
BERNCOHEN:«VHDL Coding Styles and Methodologies», Kluwer Academic Publishers,
1995.
P. CAMURATI, P;PRlNErro: «Formal Verification of Hardware Correctness: Introduction and
Survey of Current Research», IEEE Computer, pp. 8-19, July 1988.
[ALC92] Alcatel Espace: «ESA CPTP ASIC Programme. C160 ASIC Design Manual», Al-
catel Espace, 1992.
[BERG] JANICKBERGERON:«Guidelines for writing VHDL Models in a Team Environ-
ment». Disponible vía ftp a «vhdl.org» en «/vilmisclModelingGuidelines.paper.ps».
[ENGS93] R. ENGSTRAND, L. ERIKSSON,G. VICENTI:«From Conceptual to Implementational
Model, A Top-down Design Method Based on VHDL». First Asian Pacific Conference
on Hardware Description Languages, Standards & Applications, 1993.
[GIAC89] 1. DI GIACOMO:«VLSI Handbook». McGraw-Hill Publishing Company, 1989.
[HARR91] R. E. HARRand A. G. STANCULESCU, Editors: «Applications of VHDL to Circuit
Design», Kluwer Academic Publishers, 1991
[HUBROS91] J. P. HUBER,M. W. ROSNECK:«Successful ASIC Design the First Time
Through». Van Nostrand Reinhold, 1991.
[lEEE94] «IEEE Standard VHDL Language Reference Manual». IEEE, Inc., New York,
N. Y., June 1994.
[KLEIN94] S. KLEINFELDT, M. GUINEY,J. K. MILLER,M. BARNES:«Design Methodology
Management». Proceedings of the IEEE, Vol.82, No. 2, February 1994.
[MICH92] P. MICHEL,U. LAUTHER,P. Duzv, Editors: «The Synthesis Approach To Digital
System Design». Kluwer Academic Publishers, 1992.
[MMS93] Matra Marconi Space: «ESTEC CPTP ASIC Programme. C150-ASIC Life Cycle.
Final Report». Matra Marconi, 1993.
[NAGA92] V. NAGASAMY, N. BERRY,C. DANGELO:«Specification, Planning, and Synthesis
in a VHDL Design Environment». IEEE Design and Test of Computers, June 1992.
[NAIBIS88] P. NAISH,P. BISHOP:«Designing ASICs». Ellis Horwood Limited, 1988.
[NAV93] Z. NAVABI:«VHDL. Analysis and Modeling of Digital Systems». McGraw-Hill,
1993.
[PREN94b] PRENDA: «Métodos de especificación y control». v3.1, julio 1994.
[PREN94c] PRENDA: «Métodos de diseño y alternativas tecnológicas». v2.1, julio 1994.
[RAMM91] F. J. RAMMIG,R. WAXMAN:«Electronic Design Automation Frameworks». El-
sevier Science Publishers B.V., 1991.
[THOM90] D. E. THOMAS,E. D. LAGNESE,R. A. WALKER,J. A. NESTOR,J. V. RAJAN,R. L.
BLACKBURN: «Algorithmic and Register- Transfer Level Synthesis: The System Archi-
tect's Workbench». Kluwer Academic Publishers, 1990.
[TORR97] Y. TORROJA,T. RIEsGO,E. DELATORRE,J. UCEDA:«Design for Rensabilty: Ge-
neric and Configurable Desings», VUFE'97, Toledo, Spain, abril 1997.
[VERI91] Open Verilog International: «Verilog Hardware Description Language Reference
Manual». Version LO, October 1991.
[VITAL94] «VHDL Initiative Toward ASIC Libraries- Model Development Specification».
Version v2.2b. March 1994.
Apéndice I
SISTEMA
COLAMATIC
DOCUMENTO DE REOUISITOS
Presentación del cliente
El sistema Colamatic se va a desarrollar por petición de la empresa XXX al Centro

de diseño de YYY. La empresa XXX tiene una larga tradición en el desarrollo y la
explotación de máquinas expendedoras de distintos tipos. Con este proyecto se pre-
tende dar un gran salto a las nuevas tecnologías microelectrónicas que permitirá una
mejora de las prestaciones de las máquinas y una importante reducción de su coste.
Descripción de la aplicación
El primer demostrador se va a realizar para uno de los productos de más difusión en

el mercado de la empresa XXX, que son las máquinas expendedoras de bebidas.
Éstas suponen un 70 por 100 de las ventas de la empresa y el desarrollo de un ASIC
está justificado, ya que la producción anual prevista inicialmente y tan sólo para
consumo interno es de 10.000 unidades/año.
El diseño deberá ser realizado de forma que pueda ser adaptado a nuevas apli-
caciones: dentro de la línea productiva de XXX: otros tipos de máquinas, mayor
cantidad de productos, etc.
443
En particular, y para esta aplicación concreta, se pretende desarrollar un circui-

to integrado que sustituya la mayor parte de la lógica de control de una máquina
expendedora de bebidas frías, que disponga de la posibilidad de vender hasta cuatro
productos diferentes, cuyos precios puedan ser programados para cada producto
individualmente. El diseño deberá contar con la posibilidad de ser adaptado fácil-
mente a un mayor número de productos. Los requisitos precisos de la aplicación se
detallan en un apartado posterior de este documento.
Descripción del entorno del ASIC
El ASIC Colamatic estará encargado del control de la máquina expendedora. Su en-

torno estará compuesto por elementos sensores, botones e interruptores, que estarán
conectados con las entradas del sistema, y elementos actuadores y visualizadores
sobre los que el ASIC ejercerá el control.
En particular, el entorno del ASIC se puede dividir en los siguientes elemen-
tos:
Entradas
Sensores: Sensor de entrada de las monedas, que detectará el tipo de moneda que
se ha echado. Los tipos de moneda previstos inicialmente son seis (duro, cinco
duros, diez duros, veinte duros, doscientas pesetas y quinientas pesetas).
Botones: Botones de producto, que servirán para seleccionar el producto que se
quiere comprar y también para seleccionar el producto cuyo precio se quiere
programar. En principio está previsto un número de cuatro productos.
Botón de devolución de monedas, que servirá para que el usuario pueda
recuperar su dinero. También se podrá utilizar este botón para indicar el fin de
la programación del precio de un producto determinado.
Botones de programación de precio, serán dos botenes para programar el
precio deseado para cada producto. Un botón incrementará y otro decrementará
el precio por cada pulsación. El intervalo de incremento se dejará abierto en
esta etapa del diseño, definiéndose más claramente en etapas posteriores.
Interruptores: Interruptor de cambio de modo de funcionamiento, este interruptor
seleccionará entre los dos posibles modos de funcionamiento: funcionamiento
normal y modo de programación de precios.
Salidas
Actuadores: Apertura de las trampillas de los productos, el ASIC deberá abrir,
cuando se cumplan las condiciones necesarias para ello, las trampillas de cada
uno de los productos. En principio deberá actuar sobre cada trampilla de pro-
ducto.
Apertura de las trampillas de las monedas, dispondrá de tantos actuadores
como tipos de monedas para devolver el cambio. En principio habrá cinco
trampillas para la devolución del cambio.
Apéndice l. Sistema Colamatic 445
Apertura de la trampilla a la caja de recaudación, esta trampilla se abrirá

cuando se detecte que los carriles internos de las monedas se han llenado.
Visualizadores: Display externo (3 dígitos), serán tres visualizadores de 7 segmen-

tos, que indicarán al usuario el precio del producto seleccionado, el dinero que
lleva echado, el cambio que se le va a devolver, según el estado del sistema.
Cuando se están programando los precios, en estos visualizadores se mostrará
el precio que se programa.
Indicador de falta de cambio, que será un LEO que indique que no se dis-
pone de cambio en la máquina.
Indicadores de falta de producto, que serán tantos LEOs como tipos de pro-
ductos haya, que indicarán al exterior que el producto en cuestión se ha termi-
nado.
Descripción de la funcionalidad del ASle
El ASIC Colamatic, como se ha explicado anteriormente, deberá realizar todas las

funciones de control de la máquina expendedora de bebidas en la que se incluirá.
Las funciones principales del ASIC son las siguientes:
Control de apertura de las trampillas de los productos: deberá conocer el dinero

que se ha introducido en la máquina y el producto que se quiere adquirir. Una
vez que el usuario ha introducido el dinero suficiente, deberá apretar el botón
del producto que quiere adquirir y se abrirá la trampilla correspondiente. En el
caso de que no se introduzca el precio exacto y no haya cambio, no se abrirá la
trampilla y se devolverá el dinero introducido.
Control de la devolución del cambio: deberá calcular el cambio que hay que
devolver al usuario, teniendo como criterio principal el devolver el mínimo
número de monedas posible (monedas de máximo valor) siempre que estén
disponibles. Además, deberá conocer el número de monedas de cada tipo dis-
ponibles en el interior de la máquina y actualizarlos a medida que se vaya
introduciendo dinero. Se supondrá que cada vez que se abre la máquina se
rellenan los cajetines de las monedas con un número de monedas que se
determinará más adelante. Cada uno de los carriles de monedas tendrá una
trampilla independiente.
Devolución de las monedas: el dinero que ha echado un usuario se devolverá ínte-

gro si se pulsa el botón de devolución de monedas o no hay cambio y no se ha
introducido el importe exacto. Las monedas devueltas deberán ser del mismo
tipo que las introducidas por el usuario.
Control de llenado de los monederos: cuando se detecte que alguno de los almace-
nes de monedas se ha llenado, se abrirá una trampilla que hará que las monedas
introducidas caigan en la caja de recaudación.
Control de la presencia de productos: el sistema deberá saber cuántos productos

quedan de cada tipo para informar al exterior de que no hay producto en caso
de que se terminen. Se supondrá que cuando se abre la máquina se rellenan los
carriles de todos los productos hasta el máximo (30).
Programación de los precios: deberá controlar la programación de los precios cuan-

do el interruptor de modo está en la posición adecuada. Para programar los pre-
cios se irán pulsando los botones de incremento o decremento de precio hasta
alcanzar el importe deseado y después se seleccionará el producto cuyo precio
se quiere programar. Para almacenar el nuevo precio en el sistema se deberá
pulsar el botón de devolución, que en este modo de funcionamiento servirá
para almacenar el nuevo precio. También se puede programar el precio se-
leccionando primero el producto y después seleccionando el precio. En este
modo de funcionamiento se iluminará el LED correspondiente al producto
seleccionado y en el display aparecerá el precio que se va seleccionando.
Control de los visualizadores externos: los visualizadores de 7 segmentos mostra-

rán diferente información, dependiendo del estado del sistema: si se oprime el
botón de producto antes de introducir monedas, se mostrará el precio del pro-
ducto pulsado; si se empieza a introducir monedas en el display, aparecerá el
importe introducido; si se ha introducido una cantidad menor que el precio del
producto y se pulsa el botón de algún producto, se mostrará el importe que falta
por introducir; si hay que devolver cambio, se mostrará el dinero que falta por
devolver; si se está programando el precio, se mostrará el precio que se va
programando con los botones de incremento o decremento de precio; en cual-
quier otro caso el display permanecerá a cero (000).
Los LEDs de falta de producto se iluminarán cuando se detecte que falta algún
producto, en modo de funcionamiento normal, y cuando se selecciona un producto
para programar su precio, en modo de programación de precios.
Restricciones del ASIC
El ASIC deberá funcionar en las condiciones anteriormente descritas y sus restric-

ciones funcionales se irán definiendo a medida que se avance en la especificación
final y en el diseño del mismo. Estas restricciones no podrán afectar en ningún caso
al funcionamiento anteriormente descrito y deberán ser aprobadas por el grupo de
diseño y el cliente.
DOC-l PRENDA: Metodología para el diseño de ASICs UPM-DIE, 1996.

DOCUMENTO DE ESPECIFICACIONES
Introducción
En este documento se presentan las especificaciones detalladas del ASIC

Colamatic. Este documento servirá como base para el desarollo de las fases poste-
riores del diseño del ASIC.
Para formalizar la especificación del sistema se ha realizado una descripción
del mismo en VHDL. Esta descripción se ha realizado en un estilo puramente fun-
cional para definir claramente el comportamiento del sistema.
DOC-l PRENDA: Metodología para el diseño de ASICs. UPM-DIE, 1996.

DOC-2 Sistema Colamatic. Documentos de requisitos. XXX-YYY, 1997.
Discrepancias con el documento de requisitos
Ninguna conocida.
Terminología usada
Los nombres de las señales de entrada y salida, así como los nombres de los
bloques funcionales, intentan facilitar la comprensión de su funcionalidad al má-
ximo.
Especificación funcional del ASIC
Especificaciones globales
Se pretende desarrollar un circuito integrado que sustituya la mayor parte de la lógi-

ca de control de una máquina expendedora de bebidas frías, que disponga de la
posibilidad de vender hasta cuatro productos diferentes, cuyos precios puedan ser
programados para cada producto individualmente. El diseño deberá contar con la
posibilidad de ser adaptado fácilmente a un mayor número de productos.
En la siguiente tabla se muestran las entradas y salidas del sistema Colamatic y
una breve descripción de su funcionalidad:
Nombre Descripción
ENTRADAS
Clk Reloj principal del sistema (frecuencia por determinar)
ResN Señal de inicialización global del sistema (activa por nivel bajo)
BotProdl Botón de selección del producto 1
BotProd2 Botón de selección del producto 2
BotDevuelve Botón de devolución del importe introducido
BotPVP/ncre Botón para incrementar el precio en modo de programación
BotPVPDecre Botón para decrementar el precio en modo de programación
/nteModo Interruptor de modo (= 'O' en modo normal; = '1' en modo de

programación de precios)
Moneda/nt Monedas introducidas desde el exterior. Se codificarán en tres bits
SALIDAS
TrampProd Señales que controlan la apertura de las trampillas de los productos
NoHayPl Señal que controla el LED correspondiente al producto 1
NoHayP2 Señal que controla el LED correspondiente al producto 2
NoHayCambio Señal que controla el LED que indica que no hay cambio
MoneUeno Señal que controla la apertura de la trampilla a la caja de recaudación
MonedaOut Señales que controlan la apertura de las trampillas de la devolución
DispUnidad Señales para controlar el visualizador de 7 segmentos (unidades)
DispDecena Señales para controlar el visualizador de 7 segmentos (decenas)
DispCentena Señales para controlar el visualizador de 7 segmentos (centenas)
En la tabla siguiente se muestra la partición en bloques cuya funcionalidad de-

tallada se presentará en el apartado siguiente:
Nombre Entradas Salidas Funcionalidad
AIExterior InteModo NoHayProd Este bloque es el encargado de

PrecioProd DispUnidad generar las salidas a los visuali-
Producto DispDecena zadores y los LEDs externos.
LineaVacia DispCentena
DineroInt
Monedero InteModo NoHayCambio Bloque principal de control que

BotDevuelve MonedaOut calcula el dinero que se ha echa-
Producto TrampProd do, abre las trampillas, calcula el
MonedaInt MoneLleno cambio, etc.
LineaVacia Dineolnt
Precios V
ProgPrecio Producto PrecioProd Bloque para programar el precio.

InteModo SelRegPVP Los precios de cada producto se
BotDevuelve almacenarán en el bloque Reg-
BotPVPlncre Precio.
BotPVPDecre
RegPrecio SelRegPVP Precios V Bloque para almacenar los pre-

PrecioProd cios de todos Jos productos.
Sirve Cola TrampProd LineaVacia Bloque para controlar la disponi-

Producto bilidad de productos.
PrecioProd precioProd--r-:==l__
ProgPrecio SelRegPVP SelRegpVp~ Precios V
AIExterior
SirveCola Linea Vacía Dinero/nt

Especificaciones de los bloques funcionales
Bloque A1Exterior. Este bloque se encargará de generar las señales para la visua-
lización externa a través de los visualizadores de 7 segmentos y de los LEDs.
En modo de funcionamiento normal (InteModo = 'O'), se iluminarán los LEDs
correspondientes a aquellas líneas de producto que estén vacías. El visualizador
mostrará diferentes valores, dependiendo de las acciones del usuario:
• Mientras va echando dinero en la máquina el display mostrará la cantidad de

dinero echada.
• Si se pulsa algún botón de selección de producto sin haber echado dinero su-
ficiente para dicho producto, el display mostrará el dinero que falta para la
adquisición de dicho producto.
• Si se echa más dinero del necesario y se debe devolver cambio, el display
mostrará el cambio que queda por devolver.
En modo de funcionamiento de programación (InteModo = 'O'), se iluminará el

LED correspondiente al producto cuyo precio se está programando. El display irá
mostrando el precio que se está programando para dicho producto.
Bloque Monedero. Este será el bloque principal de control de la máquina. Se rea-

lizarán las siguientes funciones:
• Cálculo del dinero.

• Cálculo del cambio y control de los monederos internos de la máquina. El
cambio se devolverá utilizando las monedas de más valor que sea posible. Se
supone que los monederos se llenan con 30 monedas cada uno cuando se ini-
cializa el sistema. Cuando los monederos se llenan (tienen más de 50 mone-
das) el dinero echado pasará a la caja de recaudación.
• Devolución de las monedas echadas al pulsar el botón BotDevuelve. Se de-
volverán las mismas monedas que se han echado.
• Apertura de la trampilla, que se indicará al bloque Sirve Cola que se encarga-
rá de comprobar la disponibilidad del producto seleccionado. '
Bloque ProgPrecio. Este bloque es el encargado de realizar la programación de

los precios. Para programar un precio, el interruptor InteModo deberá estar a 'O'. El
usuario seleccionará un producto y después podrá hacer aumentar o disminuir el
precio pulsando los botones BotPVPlncre y BotPVPDecre, respectivamente. Al pul-
sar una vez uno de estos botones, el precio variará en 25 pesetas. Este parámetro
podría cambiarse si se prevé necesario durante la etapa de desarrollo. Una vez con-
seguido el precio deseado, que se irá mostrando en el display externo, se programa
el precio mediante la pulsación del botón BotDevuelve.
Este bloque generará las señales de entrada a los registros de los precios (blo-
que RegPrecio). Generará unas señales que actuarán como habilitación de cada uno
de los registros de precio de los productos (SelRegPVP) y otra en la que se encon-
trará el precio a almacenar (PrecioProd).
Bloque RegPrecio. En este bloque se almacenarán los precios programados para

cada uno de los productos. Como salida tendrá unas señales que indicarán los pre-
cios de cada uno de dichos productos.
Bloque Sirve Cola. Este bloque es el encargado del control de la trampilla de los
productos y de detectar la disponibilidad de productos. Generará las señales que
indiquen que no hay producto.
Especificaciones operacionales.
Formato y rango de los datos
A continuación se describen cada una de las señales del sistema Colamatic,

especificando sus rangos, su origen y destino, atendiendo a los bloques funcionales
anteriormente descritos:
_\Nombre Origen Destino Codificación
Clk Exterior Todos los bloques 1 bit

r
ResN Exterior Todos los bloques 1 bit
BotProdl Exterior AIExterior; Monedero; ProgPrecio 1 bit

E
N BotProd2 Exterior AIExterior; Monedero; ProgPrecio 1 bit
T
BotProd3 Exterior AIExterior; Monedero; ProgPrecio 1 bit
R
A BotProd4 Exterior AIExterior; Monedero; ProgPrecio 1 bit
D
BotDevuelve Exterior Monedero; ProgPrecio 1 bit
A
S BotPVPlncre Exterior ProgPrecio 1 bit
BotPVPDecre Exterior Progñrecio 1 bit
InteModo Exterior AIExterior; Monedero; ProgPrecio 1 bit
Monedalnt Exterior Monedero 3 bits

Nombre Origen Destino Codificación

':":;,.' : :-",'
TrampProd Monedero Exterior; SirveCóla 4 bits
NoHayPl AIExterior Exterior 1 bit
NoHayP2 AIExterior Exterior 1 bit

i
i -.~;
S NoHayP3 AIExterior Exterior 1 bit

A
NoHayP4 A1Exterior Exterior 1 bit
L
1 NoHayCambio Monedero Exterior 1 bit
D
MoneUeno Monedero Exterior 1 bit
A - .,.:~.''¡~>
S MonedaOut Monedero Exterior 3 bits
DispUnidad A1Exterior Exterior 7 bits
DispDecena AIExterior Exterior 7 bits
DispCentena AIExterior Exterior 7 bits

1 PrecioProd ProgPrecio AIExterior, RegPrecio 10 bits
N
-J
T LineaVacia SirveCola AIExterior, ProgPrecio, Monedero 4 bits
E
R Precios V RegPrecio Monedero 4 X 10 bits
N
A
SelRegPVP ProgPrecio RegPrecio 4 bits
S
Especificaciones tecnológicas globales
Parámetros eléctricos
Tensión de alimentación = 5 V ± 0,5 V.
Consumo estático y dinámico: el consumo no será un parámetro crítico en este
diseño (TBD).
Características de las E/S

Tensiones máxima y mínima: las entradas y salidas del circuito serán compatibles
CMOS en sus niveles de tensión.
Corrientes: la corriente en las salidas del sistema deberá ser de 2 mA. Se defi-
nirá de manera más precisa en las fases posteriores del diseño.
Margen de temperaturas
El margen de temperaturas para el que se debe probar el circuito es el industrial (de

-55 oC a +125 oC).
Frecuencia de funcionamiento
El circuito no tiene unos parámetros críticos en cuanto a la frecuencia de funciona-

miento. La frecuencia mínima a la que debe funcionar el circuito es de 1 MHz.
Encapsulado
El circuito tiene un total de 47 señales de entrada y salida. A esto hay que añadir las
necesarias para alimentación y masa y la posibilidad de tener que añadir alguna
señal externa adicional para test. Esto se definirá en las etapas posteriores del diseño.
El encapsulado final del circuito no está definido, aunque se prevé necesario un
PLCC de 68 pines.
DOCUMENTO DE DISEÑO ARQUITECTURAL
Introducción
Este documento contiene la información de diseño generada durante el diseño de la

arquitectura del Sistema Colomatic. El desarrollo de la arquitectura de este sistema
se ha realizado en VHDL, siendo el resultado de esta etapa una descripción VHDL
compatible con el sistema final a nivel de ciclos de reloj, aunque no necesariamente
sintetizable.
Para el desarrollo de esta fase se ha seguido la misma partición en bloques fun-
cionales definida en el documento de especificaciones y la funcionalidad de las
señales de interconexión entre los mismos.
Documentos aplicables
DOC-l PRENDA: Metodología para el diseño de ASICs. UPM-DIE, 1996.

DOC-2 Sistema Colomatic. Documento de requisitos. XXX-YYY, 1997.
DOC- 2 Sistema Colomatic. Documento de especificaciones. XXX -YYY, 1997.
DOC-3 VHDL-Language Reference Manual. IEEE, 1993.
Discrepancias con el documento de especificaciones
Ninguna conocida.
Descripción arquitectural
Partición del diseño
La partición del diseño se ha tomado del documento de especificaciones (DOC-2),

ya que ésta se realizó basándose en la funcionalidad que debe cubrir el sistema y
se ha preferido mantenerla. El diagrama de bloques del sistema con las señales de
entrada y salida de cada bloque se encuentra en la figura siguiente. En DOC-3
encontrará más detalles sobre la funcionalidad de cada una de estas señales y blo-
ques.
PrecioProd PrecioProd ~
ProgPrecio
SelRegPVP SelRegPVP ~ PrecíosV
AIExteríor
SirveCola
Monedero
PreciosV-'-- --l
Descripción detallada de los bloques funcionales
Bloque AIExterior
Este bloque se encargará de generar las señales para la visualización externa a

través de los visualizadores de 7 elementos y de los LEDs. En modo de funciona-
miento normal (InteModo == 'O'), se iluminarán los LEDs correspondientes a aque-
llas líneas de producto que estén vacías. El visualizador mostrará diferentes valores,
dependiendo de las acciones del usuario, datos que serán enviados por el bloque
Monedero a través de la señal Dinerolnt.
En modo de funcionamiento de programación (lnteModo = 'O'), se iluminará el

LED correspondiente al producto cuyo precio se está programando. El visualizador
irá mostrando el precio que se está programando para dicho producto.
La figura siguiente muestra un diagrama de entradas y salidas del bloque, así
como un esquema de la funcionalidad interna del mismo.
l/nteMod~
PrecioProd -
-1 NoHayProd
A/Exterior
-i DispUnidad
IProduct9>-
UneaVacia-
-1 DispDecena
H DispCentena
<,
PrecioProd-
Convertidor -------rl DispUnidad>
entero- MUX H DispDecena>
7 segmentos
Dinero/nt-
_---- rl DispCentena>
l/nteModo >---
"-.......
I Producto
MUX H NoHayProd>
LineaVacia l
\. L-------- ..J
Se trata de un bloque combinacional, en el que se realiza la interfaz con el

exterior. Por una parte, se convierten los datos que se mostrarán en el visualizador y
por otra se generan las señales de los LEDs.
Las entradas PrecioProd y Dinero/nt se codificarán como enteros variando entre
Oy 995 y las demás señales del bloque serán de tipo std_logic y std_logic_vector. La
elección de los tipos enteros para las señales PrecioProd y Dinerolnt facilita el tra-
tamiento de dichos datos.
Bloque ProgPrecio
Este bloque es el encargado de realizar la programación de los precios. Para progra-

mar un precio, el interruptor /nteModo deberá estar a 'O'. El usuario seleccionará un
producto y después podrá hacer aumentar o disminuir el precio pulsando los boto-
nes BotPVP/ncre y BotPVPDecre, respectivamente. Al pulsar una vez uno de estos
botones el precio variará en 25 pesetas. Una vez conseguido el precio deseado, que
se irá mostrando en el visualizador externo, se programa el precio mediante la pul-
sación del botón BotDevuelve.
Este bloque generará las señales de entrada a los registros de los precios (blo-
que RegPrecio). Generará unas señales que actuarán como habilitación de cada uno
de los registros de precio de los productos (SeIRegPVP) y otra en la que se encon-
trará el precio a almacenar (PrecioProd).
PrecíoProd
ProgPrecio
SelRegPVP
El bloque ProgPrecio contiene un contador que se incrementa o decrementa en

25 unidades cada vez que se pulsan los botones BotPVPlncre y BotPVPDecre, res-
pectivamente. Asimismo, tiene un registro para guardar la información sobre el pro-
ducto que se ha seleccionado al comienzo de la operación. El bloque entero estará
inhabilitado cuando el sistema esté en modo de funcionamiento normal.
Para probar la funcionalidad de este bloque se comprobará que:
• En modo de funcionamiento normal no funciona.
• Al pulsar el botón BotPVPlncre 40 veces el valor del precio vuelve a cero.

Igual con el botón BotPVPDecre.
• Se generan correctamente las señales SelRegPVP al pulsar el botón Botl)e-

vuelve. Estas señales tendrán una duracción de un ciclo de reloj, en el que el
valor a cargar en el registro está en PrecioProd.
• La selección del producto cuyo precio se quiere programar se puede hacer

al comenzar la operación, durante la misma o al final, justo antes de pulsar
BotDevuelve.
Bloque RegPrecio
En este bloque se almacenarán los precios programados para cada uno de los pro-
ductos. Como salída tendrá unas señales (Precios V) que indicarán los precios de
cada uno de dichos productos.
Este bloque contiene cuatro registros en los que se almacenarán los precios
programados para cada producto, con las señales generadas por el bloque anterior-
mente descrito. Los precios se codifican con valores enteros que Valían entre O
y 975.
Apéndice l. Sistema Co/amatíc 457
PrecioProd -r:==L_
se/RegpVp~ . Precios V
PrecioProd o Qf-- PreciosV(O)

SeIRegPVP(O) en
G/k
O Q,-----
PreciosV(1 )
Se/RegPVP(1) en
O QI-- PreciosV(2)
SeIRegPVP(2) en
O Qf-- PreciosV(3)
SeIRegPVP(3) en
Bloque Sirve Cola
Este bloque es el encargado del control de la trampilla de los productos y de detec-

tar la disponibilidad de productos. Generará las señales que indican que no hay pro-
ducto (LineaVacia).
SirveGola Linea Vacía
Este bloque es muy sencillo, ya que simplemente lleva la cuenta de los produc-
tos que quedan en cada línea, Inicialmente se considera que la línea está llena con
30 productos,
Internamente contiene un contador que se decrementa cada vez que se abre la
trampilla del producto correspondiente (TrampProd(i) = '} ').
Bloque Monedero
Este bloque es el encargado del control general de la máquina. Las funciones prin-
cipales que se realizan en él son:
• Cálculo del dinero que se ha echado.

• Cálculo del cambio y control de los monederos internos de la máquina. El

cambio se devolverá utilizando las monedas de más valor que sea posible. Se
supone que los monederos se llenan con 30 monedas cada uno cuando se ini-
cializa el sistema. Cuando los monederos se llenan (tienen más de 50 mone-
das) el dinero echado pasará a la caja de recaudación.
• Devolución de las monedas echadas al pulsar el botón BotDevuelve. Se de-
volverán las mismas monedas que se han echado (monedas del mismo tipo).
• Apertura de la trampilla, que se indicará al bloque SirveCola que se encarga-
rá de comprobar la disponibilidad del producto seleccionado.
Este bloque se ha realizado mediante una máquina de estados, cuyo diagrama

se muestra a continuación.
HayCa
Los estados anteriormente mostrados tienen asociados un conjunto de funcio-

nes, que son:
• Estado inicial: en este estado la máquina se encuentra en reposo, ya que no

se ha comenzado ninguna operación por parte del usuario.
• Estado más-mon: en este estado se incrementa el número de monedas que se
han echado de un cierto tipo. Si se supera la capacidad de los monederos,
se abrirá la trampilla a la caja de recaudación (MoneLleno(i) = '1 ').
• Estado reposo: este estado es similar al inicial, aunque la máquina se en-

cuentra dentro de un ciclo de compra de producto.
• Estado sel-prod: una vez se ha seleccionado el producto, en este estado se

comprueba si se ha echado el dinero justo para comprar el producto, caso en
el que pasará al estado abre para abrir la trampilla del mismo, si se ha echado
dinero de más, caso en el que se pasa a calcular el cambio, o no se ha echa-
do dinero suficiente, caso en el que se pasa al estado de reposo, hasta que se
haya echado dinero suficiente.
• Estado cambio: en este estado se realiza el cálculo del cambio que hay que
devolver, comprobándose si hay cambio suficiente en los monederos.
• Estado devuelve: se entra en este estado cada vez que se pulsa el botón de
devolución de monedas (BotDevuelve). En él se abren las trampillas de las
monedas correpondientes.
• Estado abre: en este estado se realiza la apertura de la trampilla del producto

seleccionado.
Para la comprobación de este bloque se probarán diversas posibilidades de in-

troducción de monedas, selección de cada uno de los productos, comprobación del
cálculo del cambio y de la devolución de las monedas.
Descripción del test funcional
Para la realización del test funcional del sistema se realizarán un conjunto de simu-
laciones de los bloques por separado y una simulación general de todo el sistema.
La estrategia que se seguirá será comprobar de forma exhaustiva cada uno de los
requisitos del sistema, poniéndolo en situación límite en algunos casos. Asimismo, se
comprobarán los cambios de modo del sistema (inicialización ~ ... modo de pro-
gramación de precios ~ ... modo de funcionamiento normal).
Requisitos ¿Qué se debe comprobar?
Inicialización Comprobación del estado de los registros internos. (Mone-

deros y filas de productos llenos; resto de los registros a '0').
Programación de precios Comprobación de que se programan correctamente los pre-

cios de todos los productos. Comprobación de que el precio
máximo es de 975 pesetas. Comprobación de las salidas por
visualizador.
Requisitos ¿Qué se ha comprobado?
Inserción de monedas Comprobación del control de los monederos. Comprobación

del llenado de los monederos. Comprobación de la máxima
cantidad de dinero que se puede echar l. Comprobación de la
salida por display.
Cálculo del cambio Comprobación del cálculo del cambio para distintas circuns-
tancias (cuando hay todo tipo de monedas, cuando sólo que-
dan monedas pequeñas, etc.). Comprobación del caso en el
que no hay cambio. Comprobación de la salida por los vi-
sualizadores.
Devolución de monedas Comprobación de la devolución del cambio. Comprobación

de la devolución de monedas al pulsar BotDevuelve. Com-
probación de la devolución de monedas al superar el máxi-
mo admitido l.
Compra de producto Comprobación de la apertura de las trampillas de producto.

Comprobación de la "no apertura" cuando no se ha echado
dinero suficiente. Comprobación de la ausencia de productos
en alguna línea vacía.
I Este requisito no se encontraba explícito en las especificaciones. Si se echa más dinero del máxi-
mo permitido (> 1.000 pesetas), las monedas introducidas en la máquina se devolverán.
En la tabla anterior se muestran los principales parámetros que se deben com-

probar en las simulaciones funcionales del sistema. La comprobación funcional del
sistema se realizará por inspección visual de los resultados de las simulaciones
tanto en las salidas del circuito como en algunas señales internas del mismo (estado
de los monederos, de las líneas de productos, de los precios programados, etc.).
CONCLUSIÓN
En este documento se han expuesto las principales características de la arquitectura

del sistema Colamatic. El código VHDL resultante de esta etapa del diseño servirá
de entrada a la siguiente fase del diseño, en la cual se llegará a descripción sinteti-
zable del mismo y se optimizará para su posterior síntesis. Las simulaciones funcio-
nales del sistema podrán ser utilizadas asimismo para la simulación del sistema a
nivel lógico.
Apéndice 11
NORMAS
DE CODIFICACION
y MODELADO EN VHDL
En el presente apéndice se muestran una serie de reglas de codificación y modela-

do. Este tipo de reglas deberían ser implantadas en todos los equipos de diseño que
pretendan realizar diseños industrialmente. Las reglas mostradas son desde ideas
muy sencillas (uso ordenado de mayúsculas y minúsculas, espaciado en las distintas
secciones del texto, etc.) hasta aspectos más relacionados con la naturaleza del
VHDL (uso de unas sentencias en lugar de otras, organización de los ficheros, etc.).
Estas reglas nunca se deben considerar como una imposición, sino simplemen-
te como una serie de ideas que puedan ayudar a tomar determinadas decisiones a la
hora de organizar un equipo de diseño.
Corno el VHDL es un lenguaje formal (como el C o el Pascal), muchas de las
reglas, en cuanto a estilo se refiere, están inspiradas en las que usan los programado-
res. Asimismo, al ser el VHDL un lenguaje que es usado para la simulación de hard-
ware o incluso para la síntesis del mismo, estas reglas se verán afectadas por ello.
11.1. ADVERTENCIA
Las reglas que aparecen en el texto no son más que recomendaciones (su utilización
está pensada para una herramienta comercial específica y pueden no ser aplicables
para otras). En ningún momento han de convertirse en una obligación si el uso de
las mismas va en detrimento de la productividad. El director del equipo de diseño
461
tiene la responsabilidad de valorar las recomendaciones presentadas y elegir las

más convenientes para su equipo de diseño.
Lo que siempre es recomendable es que estas reglas sean, en la medida de lo
posible, fijas y que no vayan cambiando de proyecto en proyecto. El centro de dise-
ño debería publicar sus propias reglas de modelado VHDL que todos deberían
conocer y utilizar. En el caso en el que las descripciones VHDL fuesen leídas por
personas ajenas al centro de diseño, se deberían acompañar por las reglas de mode-
lado que se han seguido para realizar esas descripciones.
Las recomendaciones se dividen en cuatro partes:
l. Definición del formato del fichero VHDL.
2. Convenios sobre utilización de bibliotecas.
3. Nombre y ubicación de ficheros.
4. Modelos para síntesis.
Al final del apéndice se muestra un ejemplo correspondiente a un transmisorl
receptor serie síncrono sintetizable por una herramienta comercial.
11.2. DEFINICiÓN DEL FORMATO DEL FICHERO VHDL
A la hora de escribir un fichero fuente de VHDL se recomienda seguir una serie de

reglas para que todos los ficheros que se usen, sea quien sea el autor, tengan el mis-
mo aspecto.
11.2.1. Aspecto general del texto

El código debe usar de un modo coherente las mayúsculas y minúsculas, es decir,
las palabras reservadas del VHDL deberán estar todas en mayúsculas o en minúscu-
las. Se recomienda que los identificadores (nombres de variables, de señales, proce-
dimientos, etc.) utilicen mayúsculas y minúsculas.
Usar solamente 80 caracteres por línea, y solamente una instrucción por línea.
No usar tabuladores. En su lugar usar dos espacios en cada nivel de indentación.
Agrupar las instrucciones si realizan una función común. Estos grupos deberán
separarse convenientemente (con una línea en blanco o con guiones).
Alinear los comentarios, identificadores, etc., verticalmente para favorecer la
lectura del código.
11.2.2. Identificadores
Para facilitar la lectura de las descripciones, es muy útil usar mayúsculas y minús-
culas en los nombres de cualquier objeto del VHDL. Por ejemplo, en lugar de escri-
bir una función con el nombre detectordeflancopositivo, es mejor escribir el nombre
como DetectorDeFlancoPositivo. Esto es preferible a usar el carácter '_', que esta-
ría reservado para otros cometidos.
Apéndice 11.Normas de codificación y modelado en VHDL 463
Usar una longitud máxima de los identificadores de 25 caracteres.

Si una señal o variable es activa por nivel bajo, indicarlo mediante el uso de un
sufijo adecuado (N, n, z, b, etc.).
En algunos casos puede ser aconsejable utilizar un prefijo en el nombre de las
variables, señales y funciones que determine el tipo de dato que representan. Existe
una serie de prefijos de uso común, pero en el caso que por las necesidades del mo-
delo sea necesario usar un prefijo nuevo, se especificará mediante un comentario al
definir el tipo o subtipo al que pertenece ese prefijo. Los prefijos más usuales son
los siguientes:
• i:integer.
• s:std_logic.
• b:bit.
• l:boo1ean.
• u:std_u10gic.
• t:Declaración de tipos.
• e:Declaración de constantes ..
Si va acompañado con una 'v' ('sv', 'xv', ... ) indica que se trata de un vector.
Si va acompañado con una 'e' ('se', 'xve', ... ) indica que se trata de una constante.
De esta manera la función DevuelveUnEntero quedaría iDevuelveUnEntero,
resultando explícito el tipo.
11.2.3. Comentarios
El objetivo de los comentarios es facilitar que el código pueda ser entendido por
otra persona distinta a la que 10 ha escrito.
Los comentarios deberían estar en un único idioma (inglés si va a ser leído por
personas de distintas nacionalidades).
Su contenido debe ser 10 más descriptivo posible y no una mera repetición o
traducción del código VHDL, al que complementa.
Deben situarse próximos a las partes del código que describen; no es aceptable
una cabecera que explique todo el código que aparezca a continuación.
Los comentarios deberán alinearse y estar justificados para facilitar su lectura.
Cada fichero debería incluir una cabecera que contenga, como mínimo, la
siguiente información:
• Nombre de las unidades en el fichero.

• Nombre del fichero.
• Descripción del hardware modelado (si procede).
• Limitaciones del modelo, errores conocidos y cualesquiera restricciones im-
puestas.
• Lista de dependencias (si procede).
• Autor(es), incluida dirección de contacto.
• Simu1ador(es) (incluida versiones) usados.
• Lista de versiones, autores de las modificaciones y fechas de las mismas, así
como una lista de las modificaciones realizadas.
Cada declaración de un subprograma, proceso, bloque, etc., debería estar pre-

cedido por una descripción de su función, así como las limitaciones y restricciones
impuestas. En los subprogramas es conveniente comentar además los parámetros y
resultados.
En la declaración de puertos y genéricos es útil incluir comentarios describien-
do cada señal y parámetro. No se recomienda agrupar los comentarios por una parte
y las declaraciones por otro, ya que se pueden producir errores en el caso de modifi-
caciones.
11.2.4. Tipos
Es recomendable que el bit situado a la izquierda de un vector sea siempre el más
significativo, independientemente del orden de los bits. Por ejemplo, en VectorDe-
Bits(O to 15), el bit O es el bit más significativo (MSB), mientras que en' Vector-
DeBits (15 downto O), el bit Oes el bit menos significativo (LSB).
De este modo se recomienda que a la hora de declarar tipos, el orden, en el
caso en el que el índice sea un entero (caso típico de buses), sea descendente, es
decir, VectorDeBits(7 downto O). Esto facilitará la lectura del contenido de los bits
en las simulaciones.
Se recomienda escribir el código de manera que se pueda modificar el tipo de
una señal o variable sin modificar el resultado de las simulaciones. Esto implica:
• Evitar el depender de la inicialización por defecto de las variables o señales a

no ser que una política de reset asegure que el modelo es explícitamente ini-
cializado.
• Evitar depender del número de valores de un tipo determinado.
• Evitar depender del orden en el que se han declarado los valores del tipo.
11.2.5. Señales y puertos

Siempre que sea posible se usará el mismo nombre para una señal a lo largo de la
jerarquía del diseño. En el caso en el que no se pueda usar exactamente el mismo
nombre se usará un nombre derivado del primero.
La ordenación de los índices debería ser la misma a lo largo de la jerarquía, sea
ésta ascendente (usando to) o descendente (usando downto). Se recomienda usar la
misma política de indexado en todo el modelo (todos los índices ascendentes o des-
cendentes). En el caso en el que se produzca una inversión en los índices, se deberá
advertir claramente.
No es recomendable utilizar el modo buffer en la entidad de más alto nivel del
diseño.
La declaración de entradas/salidas debería realizarse en un orden lógico:
• Se recomienda poner primero las entradas, luego las señales bidireccionales
y por último las salidas.
• Alternativamente se pueden agrupar atendiendo a su función.
Apéndice 11. Normas de codificación y modelado en VHDL 465
Opción 1: Entradas/salidas Opción 2: Por funcionalidad

port ( port (
sHab in std_logic; sHab : in std_logic;
SC1k in "Std_logic; SVCUenta : out
SReset_n in std_logic; std_logic_vector(3 downto O)
-- funcien .
SFinCuenta out std_logic; sFinCuenta out std_logic;
SvCuenta out
std_logic_vector(3 downto O~ SClk in std_logic;
--funcion SReset_n in std_logic;
); );
En cualquier caso, las señales estarán comentadas, una a una, como se ha dicho
anteriormente.
En las referencias a los componentes no se usará la asignación por posición, a
no ser que los nombres de las señales sean 10 suficientemente representativos (mis-
mo nombre o derivado). Lo mismo se aplicará a los parámetros genéricos. Por
ejemplo:
architecture Funcional of COI;ltadorBCD is
camponent CampContador1
generic (
tSubida TIME; -- Tiempo de subida de las salidas
tBajada TIME); , '-- Tiempo de bajada de las salidas
port (
sEnab1e in std_logic; -- Hebi1itaci6n de cuenta
sClk in std;:._1ogic; -- Reloj del sistema
sReset_n in std_logic; -- Reset general (nivel bajo)
sFinCuenta out std_logic; -- Fin de cuenta (activo nivel alto)
-- (activo·un solo ciclo de sC1k)
svCuenta out std_logic_vector(3 downto O)); -- Valor del contador
end camponent;
signal ssl, ss2, ss3, ss4 : std_logic;

signa1 svb1 : std_logic_vector(3 downto O);
begin
Contador1 : CompContador1
gEmeric 1Il@(
tSubida := 2 ns,
. tBajada:= 2 ns)
. poit map(
sEnab1e => ssl,
sC1k => ss2,
sReset_n => ss3,
SFinCuenta => ss4,
svCuenta => svb1);
end Funcional;
Todos los procesos contarán con una etiqueta descriptiva. Lo mismo se aplica a
cualquier sentencia concurrente siempre que esto mejore la legibilidad. De este
modo es más fácil referirse a ellos en las simulaciones interactivas.
RegistrQ1 process ( ... )

begin
end process Registro1;

Principal: process( •.. )
begin
end process Princi.¡;lal;
Los procesos con una sola sentencia wait (típico en procesos sintetizables)
deberán usar en su lugar una lista de sensibilidad en lugar de la sentencia wait, ya
que esto mejora la legibilidad.
La lista de sensibilidad de un proceso deberá incluir TODAS las señales que
estén en la parte izquierda de una asignación, así como las que vayan a ser usadas
en construcciones condicionales (if, case, etc.). Esto es especialmente importante en
aquellas descripciones orientadas a la síntesis. Por ejemplo:
BIEN MAL
P1 : process (bClk, iAddress, bRequest) Pl : p~ess (.bClk).

begin begin
if bClk' event and bClk = '
l' then if bClk' event and bClk = ' l' then
if bRequest = ' l' then if bRequest = ' l' then
bvSalida <= bvMemoria(iAddress) ; bvSalida <= bvMemoria(iAddress) ;
end if; end if;
end if; end if;
end process P1; end process P1;
Se deben evitar los procesos que modifiquen variables o señales no incluidas

como parámetros en la llamada a la misma.
La entidad de más alto nivel deberá tener el mismo nombre que el dispositivo o
hardware modelado.
Utilizar siempre los mismos nombres para las distintas arquitecturas de una
misma entidad. Se recomiendan los siguientes nombres:
• Funcional.
• Comportamiento.
• Síntesis.
La arquitectura Funcional sería cualquiera que no esté pensada para su síntesis

posterior. La arquitectura Síntesis sería cualquiera pensada para síntesis (bien sea
descripción RTL, estructural o algorítmica). Si hay varias arquitecturas, se puede
incluir un número al final del nombre (Funcionall, FuncionaI2 ... ).
11.2.6. Paquetes (packagesJ

Es preferible usar siempre los packages aprobados por la IEEE en lugar de cons-
truir packages de funcionalidad similar (por el momento el único aprobado es el IE-
EE.std_logic_l164). Cualquier otro package deberá ser suministrado en la misma
biblioteca de diseño que el propio modelo.
No se debe usar un número exagerado de packages a no ser que claramente
mejore la legibilidad.
No se deberán usar package s vacíos o casi vacíos. Se recomienda colocar el
código VHDL de la misma funcionalidad en packages distintos (parámetros de
timing por una parte, procedimientos y funciones relacionados con el timing por
otra, etc.). No habrá un package para cada entidad en el que se definan constantes,
etc., para esa entidad, a no ser que su uso mejore la legibilidad de la descripción.
Las declaraciones en el package body aparecerán en el mismo orden que en la
declaración del package.
La declaración del package contendrá una documentación completa sobre los
tipos declarados, constantes, subprogramas, etc.
11.3. CREACiÓN y UTILIZACiÓN DE BIBLIOTECAS VHDL
Para evitar problemas de incompatibilidades entre los modelos descritos en VHDL,

hay una serie de recomendaciones en cuanto al uso y generación de bibliotecas. Es-
tas recomendaciones se dividen en dos partes. En primer lugar, hay unos consejos
para la correcta utilización de los tipos y componentes disponibles en las bibliote-
cas. Por otra parte, se explica un mecanismo, que se aconseja seguir, que permitirá
llevar un control de las revisiones de los componentes, procedimientos y funciones
que se vayan creando. La utilización de esta recomendación no dificulta en absoluto
la generación de código y simplificará enormemente el mantenimiento de bibliote-
cas, especialmente en diseños grandes.
11.3.1. Utilización de tipos, componentes y funciones

Usar solamente tipos básicos y la lógica MVL9 (IEEE 1164), que está definida en
el paquete std_logic_1l64.
Hacer que los componentes básicos lleven una referencia a la biblioteca a la
que se refieren. No es necesario que los componentes específicos de una aplicación
lleven dicha referencia.
Dentro de las arquitecturas se recomienda trabajar con tipos 'O1', 'XOl' Y

'XOIZ'. Esto acelera la simulación y facilita la especificación. De todas maneras,
los interfaces entre distintos bloques o componentes deberían usar siempre MVL9.
Limitar siempre el rango de las variables enteras (si éste se conoce). Esto es
especialmente necesario si la descripción está pensada para síntesis.
11.4. NOMBRE y UBICACIÓN DE ARCHIVOS
Se recomienda que en cada fichero que corresponda a un diseño se incluya:

• Entidad.
• Arquitectura (1 arquitectura por fichero en el caso de síntesis).
• Configuración.
Cada fichero será nombrado de acuerdo con la unidad de diseño que contiene,
es decir:
Entidad, Arquitectura & Configuración: nombreEntidad. vhd
Entidad, Arquitectura & Configuración: nombreEntidad-nombreArq. vhd
Package & Package Body: nombrePackage-pack.vhd
Los archivos se encontrarán en un solo subdirectorio, sin jerarquía explícita. Se
recomienda, sin embargo, documentar convenientemente la jerarquía en un fichero
de texto.
11.5. MODELOS PARA SíNTESIS
Las siguientes recomendaciones han sido generadas para la elaboración de modelos

VHDL orientados a la síntesis. Estas recomendaciones tienen validez para una
determinada herramienta de síntesis y pueden no ser válidas para las herramientas
de las que disponga el lector. En cualquier caso, en cualquier equipo de diseño es
útil disponer de este tipo de recomendaciones.
11.5.1. Recomendaciones generales

La manera de realizar las descripciones en VHDL orientadas a síntesis determinan
en gran medida la calidad del diseño sintetizado. Es por eso que hay que tener en
cuenta una serie de reglas fruto de la experiencia que evitan, no que el diseño no
sea adecuado funcionalmente, sino que el hardware generado no sea todo 10 óptimo
que sería deseable.
11.5.2. Variables y señales

• Usar señales siempre que vayan a tener visibilidad fuera del proceso en el
que su valor sea modificado.
Apéndice 11.Normas de codificación y modelado en VHOL 469
-- Proceso que representa un contador con la. señal cuenta visible

, -- desde el exterior.
----------------------------~~-------------~~---~~-~-----------~~
signal cuenta: natural range._Oto 10;.
CONTAOOR : process (reset_N, clk, cuenta)

begin
it reset_N '" '0' then
cuenta <= O;
elsif clk' event and clk = ' l' then
if cuenta < 10 then
cuenta <= cuenta + 1;
else
cuenta = O;
end if;
end if;
en process CONTAOOR;
salida <= ' l' whencuenta = 7 else

~O' ;
• Usar variables siempre que no vayan a tener visibilidad juera del proceso en
el que son declaradas y usadas.
-- Proceso en el que s610 nos interesa la señal salida.

: --La variable cuenta queda dentro del proceso.
----------------------------------~~-------------------
CONTADOR : process(reset_N, clk)
variable cuenta: natural range O to 10;
begin
if reset_N = '0' then
cuenta := O;
salida <= '0';
elsif clk'event and clk O '1' then
salida <= '0';
if cuenta < 10 then
cuenta : = cudnta + 1;
salida <= '1';
else
cuenta .- O;
end if;
end if;
end process CONTAOOR;
• Para que una variable no genere un elemento de memoria es imprescindible

que se le asigne un valor en cada time-step (cada vez que se ejecute el pro-
ceso).
• No depender nunca de los valores por defecto de las variables y señales.
-- Las siguientes inicializaciones son válidas para SIMULACIÓN, NO para

-- síntesis.
------------------_ .... _---_ ..._-------------------------..... ......... ---~.-.~- ..
"'~.'...~....~..... -
signal sl : stQ_logic; -- toma por defecto el valor 'U'
signal s2 bit: -- toma por defecto el valor 'O'
signal s3 : integer; -- toma por defecto el valor -2147483648
• No usar nunca la inicialización de variables y/o señales en la declaración de

las mismas: en síntesis son ignoradas.
Las señales o variables cuyos valores sean asignados en bloques combinacio-
nales (bien procesos, bien asignaciones concurrentes), tomarán un valor siempre
que las señales de las que dependan lo tengan. Las señales y/o variables que proce-
dan de bloques secuenciales deberán contar con una inicialización, bien secuencial,
bien combinacional.
-- Inicializaciones para síntesis
-- Asignación concurrentes la señal 'sl' ~t:!;¡;:á

int.c:ializada
-- correctamente si las señales 'el', 'e2', 'e3' están
-- inicializadas:
sl <= '1' when el = '1' and e2 = 'O' else

'O' when e3 = '1' and e2 = '1' else
'Z' ;
-- Procesos: la señal s2 será inicializada correctamente gracias a

-- las señales 'reset_N' o 'clear_N':
P1 : process(clk, reset_Jl, clear':'_N, dín)

I;legin
if reset_N = 'O' then
s2 <= 'O'; -- Inicialización asíncrona
elsif clk' event and clk = '1' then
if clearjN = 'O' then
s2 <= 'O'; -- Inicialización síncrona
else
dout <= din;
end if;
end if;
end process PI;
11.5.3. Lógica combinacional
• Hacer los bloques combinacionales con construcciones concurrentes, o bien

con proceso en los que no aparezca el reloj.
Esto hace que la herramienta de síntesis produzca un hardware más eficiente
en cuanto a área se refiere. En particular, esta regla se puede aplicar a las señales de
selección de registros:
entity pl is
port ( sell, sel2 in bit;
IW in bit;
reset~N in bit;
c1k in bit;
datoin in bit;
datoout out bit);

end pl;
architecture a2 of pl is
signal datol, dato2, readl , read2,. Wl;"ite1, write2 bit)
begin .
-- Parte combinacional
readl <= IW and sell; -- Senal de lectura de dato1

read2 <= IW and sel2; -- Senal de Iectura de dato2
write1 <= not (IW) and sa11; -- Señal de escritura de dato1
write2 <= not(IW) and sel2; -- Señal de escritura de datQ2
-- Salida combinacional
datoout <= dato1 when readl = ' l' else

dato2 when read2 = ' l' else
'O' ;
-- Parte secuencial
principal : proceSS(resét_N,··Sel1; Sé12, IW, datóín, clkT

begin
if reset_N. = '0' then
dato! <= '0';
dato2 <= 'O';
elsif clk'event and clk = '1' then
if write1 = '1' then
dato1 <= datoin;
end inf;
if write =. '1' then

dato2 <= dato in;
end if;
end if;
end process principal;
end a2; .
• Tener cuidado con el uso de sentencias if-then-elsif: no hacer nunca exclu-

yentes bloques combinacionales independientes, ya que el hardware resul-
tante es más complejo.
En el ejemplo anterior se tiene el siguiente código:
-- CORRECTO

dato1 <= datoín.
end if¡

dato2 <= datoín:
end if¡
Pero se podría haber escrito (incorrectamente):
-- INCORREX:'l'O: Tal y como se ha hecho la descripción, nunca se puede

-- producir el caso en el que write1 y write2 estén activos a la vez.

dato1 <= datoín.
elsif write2 = '1' then
dato2 <= datoínr
end if¡
• Para permitir que la herramienta de síntesis optimice bloques combinacio-

nales, se puede utilizar el valor '-' del tipo std_logic.
-- Asignación combinacional
salida <= ·000· when entrada = ·00· else.

·001· when entrada = ·01· el se
·101· when entrada = ·01· el se
M ••
,
• En procesos que describen lógica combinacional, asegurar que las salidas

toman un valor, sea cual sea el camino de control.
En muchos casos, la manera más conveniente de hacer esto es hacer, al prin-

cipio del proceso secuencial, una asignación de valores por defecto de todas las
salidas:
-- Se quiere que salida sea 0090 cuando no sea ninguna opción

-- válida '
salida <= (others => 'O');
if opcion = "lO· then

salida <= ·1010·;
end if; _
if opcion '" ·01" then

'salida <::; "010V;
end if;
En otros casos se puede usar la sentencia else, siempre que haya decisiones
excluyentes con if-then-elsif:
-- Es inQiferente el valor que tome salida si no vale ,pinguna,

-- opción.
if primeraQpcion = "lO· then
salida <= ·1010·;
elsif segundaOpcion = ·01" then
salida <= ·0101";
else
salida <= (óthers => '-');
end if;
11.5.4. Procesos secuenciales
• Hacer los bloques secuenciales con la construcción if clk'event and clk 'L' =
(o 'O'), no pudiendo aparecer ninguna otra condición en dicha construc-
ción. En casos muy especiales se pueden usar otras construcciones (ver
apartado //.5.10).
-- CORROCTO:
Biestable con enable
-----_ .....
-..;...---------....
_------:--~~;.¡.~
....
pl : process (reset_N., d, e, 'clk}
begin
,1 <= 'O'¡
elsif clk' event and clk = '1' then
if e = 'O' then
q <= d¡
end if¡
end if¡
end process pI;
• La mayoría de las herramientas sólo permiten el uso de un reloj en cada

proceso secuencial. En el caso de tener varios relojes en el sistema, o los dos
flancos de un mismo reloj, utilizar procesos distintos para cada reloj. Si
es necesaria la comunicación, implementarla como se describe en el aparta-
do /1.5.7.
p1 : process(reset_N., datolnt, clk1)

begin
if reset_N =
~O' then
,datolot <= 'O';
elsif clk1'event and clk1 =' '1' then
datolnt <= datolnt;
end if;
end process p1;
p2 : process(reset_N, datoInt,clk2)
begin "
if. reset_N = 'O' then
datoOut <= ' O' ;
elsif clk2' event and clk2 = '1' then
datoOut <= datolnt;
end if.;
end process p2;
• No escribir el código de manera que la construcción if clk'event and clk =

'L' (o 'O') esté englobada en otra construcción if-then-else o en un buclefor.
Sí se pueden usar, sin embargo, bucles while (ver apartado /1.5.10).
-- INCORRECro:
la línea donde se usa el reloj está dentro de un bucle
-----------~~--~--~~._---~------------~-------------------~~~-~--~-~~
for i in O to 1 loop
if reset_N '0' then=
if b(i) =
'1' and c(i) = '0' then
dato (i) <= TU",;
el.se
dato(i) <= '1';
end'if;
··tflli:recctonc~reaaraddtess, mascara, muéstra) tñén
dato(i) <= datoin(i);
end ifl
end if;
end loop;
-- CORRECl'ó: lá"linea donde se usa el reloj está fuera del bucle

________ :......_~.:. ...Ü~:...:..._:.:...;;., ......'~_ ..._~ .... .. ;•.;U.li..:..: ... _':.. ...~ __ ~-~ _
if reset.)il = ' O' then

if b(i) :; '1' and c(i) '0' then
dato(il <= '0';
else
dato(i) <= '1';
end if;
elsif clk'event and clk '1' then =
if DireccionCorrecta(address, mascara, muestra) then
dato(i) <= datoin(i);
end if;
end loop;
end if;
• Usar funciones para reducir la complejidad del código (ver apartado 1/.5.5).
En algunas descripciones puede ser necesaria una gran cantidad de decisiones
antes de realizar una acción determinada. El englobar esto en una función o proce-
dimiento permite que el código sea más fácil de leer y hace que la herramienta de
síntesis cuente con un particionado que le facilita la optimización. Un ejemplo es el
siguiente:
if reset.)il =
iO' then
dato <:; (others => '0');
elsH c:lk'event-imd clk = ¡li then

if DireccionCorrecta(address, mascara, muestra) then
date <= datoin;
end if;
end if;
• No introducir código que pueda generar lógica combinacional en procesos

secuenciales a no ser que se usen variables (ver apartado //.5.5).
-- Incorrecto: 'parte canbinacional dentro del proceso
process(reset..)l', clk, din, dato~anterior)

-J:ieijin - - ...'
H reset_.N = '9' then
dato_anúdar <= ..'-0';
elsif clk'evérit and clk = ,p then
dato_anterior <= dín;
end if; .
if din = '1' and dato_anterior = ' O' then

--dóUt <; '1';-
else
dout <= '0';
end if;
end process;
•• Correcto: parte cOOlbinacionalfuera del proceso
-- Parte secuencial
procesa lreset'"..:.1t,"''ctk; din)
bégin
-tf reSetJ{ ¡;n (), then
dato anterior <= '0';
~lsif '¿lx'I ~t ;aRd d_k -it, '1: then
dato_arlteiíor •.<= _.din;
end if;
end process;
-- Parte combinacional
dout <= i l'----when dato_anteri« -= ' (}' and din ~-, l' else
'O' i
• No incluir en el mismo proceso operaciones secuenciales que se deben hacer

en paralelo o no tengan funcionalidad común. Si tienen señales en común,
implementar una comunicación entre procesos como la descrita en el apar-
tado l/.S.7.
11.5.5. Procesos mixtos

• Reducir al mínimo el uso de procesos mixtos. Sólo es conveniente cuando se
usen variables que no vayan a tener visibilidad externa (juera del proceso).
11.5.6. Uso de subprogramas I
• Agrupar en subprogramas todo el código relacionado con una misma fun-

cionalidad. Esto es una pista para que el sintetizador pueda hacer una opti-
mización más eficiente.
• No usar llamadas recursivas afunciones.
-- Esta función se llama a si misma

funCtion RestaUno(arg : integer) return integer is
begin
if arg > O then
return RestªUno(arg)¡
end if¡
return áI'g¡
end RestaUno¡
• No usar atributos de señales dentro de funciones.

Sí se pueden usar atributos de tipo y de array.
• No usar dentro de subprogramas señales o variables que no hayan sido
pasadas como parámetros en la llamada al subprograma.
-- INCORRECro: la señal Sa:).idano es pasada como parámetro

procedure EnviaCdato.: std...,logi.c.)....Is,.... .
begin
-- Salida está definida en la entidad.
Salida <= dato¡
end Envia¡
I Por subprogramas se entiende funciones (functions) y procedimientos (procedures).

-- C()RRECTO:la señal ~li&

es e¡:¡viada como parámetro
procedure Envia(dato : std_logic; signal out : Salida) is
begin
Salida <= dato;
end Envia;
• Se pueden usar subprogramas concurrentes para generar bloques combina-

cionales.
architecture Sintetizable of Bloquel is

~;t
function BCDa7Segrnentos( codBcd: in std_logic_vector(3 downto O))

return std_l:ogic_veétor(7 downto TI) \is
variable: LEOs : std_logic_vector{7 downto O);
begin
case codBcd is
when "0000" => LEOs .- "1111110";
when ".oGG1" => LEOs := "lHlGGOO";
when "OUO" => LEDs .- "OUUU" ;

when "0111" :> LEOs .- "11Q0010";
when "1000" => LEOs .- "m.UU·;
when "1001" => LEOs .- ·U10111" ;
when others => LEOs .- "0000000·;
end case;
return LEOs;
end BCDa7Segrnentos;
signal cuenta: std_logic_vectorO doento O);
begin
,-- Q.J.enta procede, por eje!li>lo, de un contador síncrono de 4; bits;

-- LEO es una salida Gel cí.rcuíno;
LEO <= BCDa7Segrnentos (Cuenta) ;
end Sintetizable;
11.5.7. Comunicación entre procesos
• A la hora de comunicar varios procesos, no presuponer nunca un orden de

ejecución de dichos procesos. Se usará un sistema de comunicación adecua-
do, bien un handshake explícito, si los procesos funcionan a distinta veloci-

dad, bien un sistema de comunicación mediante señales de habilitación de
procesos.
• No mezclar nunca distintos sistemas de comunicación entre procesos dentro
de un mismo bloque.
11.5.8. Máquinas de estados

• Tanto para las máquinas de Moore como las de Mealy, conviene separar la
parte secuencial de la combinacional. Hacer las asignaciones de las salidas
con sentencias de asignación concurrente; la asignación del siguiente estado
con un proceso y una sentencia case; construir los registros en otro proceso
separado.
• Representar los estados en las máquinas de estados con los valores de un tipo
específico para cada máquina de estados. Estos valores serán nombres repre-
sentativos.
type tipoEstados 'ís (OOCIO, DEm:CT_l, ABORT, DETa:T_2, FIN);
COMBINACIONAL : process (estado, entrada1, entradaz , entrada3 )

begin
case estado is
when INICIO =>
if entrada1 ='1' then
sigEstado <= AB0RT;
elsif entrada2 = 'O' and entrada3 = '1' then
sigEstado <= DETECT_2;
else
sigEstado <= INICIO;
end if¡ .,.......
when DETECl'_1 =>
if entrada1 = '1' then
sigEstado <= FIN;
else
sigEstado <= DETECl' ....l;
end if;
when ABORT =>
if entrada2 ..,"",/1: then
sigÉstado' <~~riEm:T..);
else
sigEstado <= DETECT ...J;
end if;
when DETECT_2=>
if entrada2 = '1' then
sigEstado <= FIN;
else
's~gESj;:ado <= AOORT¡
end if¡ .
when FIN =>
if enl::i:c1dal = 'O' and'entrada2 = .'{}, and entrada3 = 'Oí tlien .'
sigEstado <= INICIO¡
else
sigEstado <= FIN;
end if¡
end case¡
end process C()ffilNACI~¡
SFX::UEOCIAL ': processtclk, reset_N; sigEstado)

begin
if reset...N = .' O' then
estado <= INICIO¡
elsi; cW ev~t and C;llt,,:¡;, 'F.¡H~rn
estado, <=_ sigEstado¡ . .,
ertd ffi ". ... , .
end process SECUENCIAL¡
-- 'Generación de salidas
-- Si salidas =
flestado actual, entradas) Máquina de Mealy
-- Si salidas = f(estado actual) Máquina de Moore
-- En este caso es una máquina de Moore
salida1 .<= '1' when estado = INICIO el se
'1' when estado =
DE'lEl'_3 else
'Ol¡
salida2 <= '1' when estado = ABORTelse

'1' when estado = FIN else
'0' ;
11.5.9. Compartición de recursos

Las herramientas de síntesis suelen hacer, cuando pueden, compartición de recursos
que claramente no coinciden en el tiempo. En determinados casos se les puede
'ayudar'.
• En el caso de contadores que se quieran compartir y estén dentro de una
descripción funcional, se puede usar la misma señal en los dos casos.
11.5.10. Sistemas "muy secuenciales" (procesos

con múltiples waits)
• Hay que tener en cuenta que estos procesos no recomienzan hasta que haya
acabado el ciclo anterior. Es por ello que sólo se usarán en aquellos casos
en los que se desea realizar una función "indivisible" y "autónoma".
• Todos los waits tienen que usar el reloj del sistema.
Apéndice 1/. Normas de codificación y modelado en VHDL 481
11.5.11. Uso de tipos
• Las entradas y salidas de los bloques de más alto nivel deberían ser de tipo
std_ulogic o std_logic. Para asegurarse de que no se están haciendo cone-
xiones de señales no deseadas, se pueden usar tipos no resueltos (en este
caso, std_ulogic).
• En bloques de menor jerarquía se pueden usar tipos no estándar, ya que
éstos permiten una rápida ampliación de la funcionalidad y son más fáciles
de mantener y entender por el equipo de diseño.
• Cuando se necesiten varios resultados de una función, se podrán usar varia-
bles tipo registro. Estas variables tienen que tener los campos relacionados
para evitar confusiones.
11.5.12. Descripciones estructurales
• Por limitaciones de algunas herramientas de Síntesis, las referencias a com-

ponentes tienen el mismo nombre que los bloques a los que se corresponden.
• Las señales de entrada a un bloque que no vayan a ser usadas dentro de ese
bloque se pondrán a un valor fijo (para la optimización plena, ponerlo a
valor '-' de std_logic).
• Las señales de salida de un bloque que no vayan a ser usadas se dejarán sin
conectar. La herramienta de síntesis eliminará el hardware que no sea nece-
sario.
• Poner un nombre significativo a todas las señales que conecten bloques en
una descripción estructural.
11.5.13. Uso de los parámetros
/1.5.13.1. Introducción
En síntesis, como mucho, sólo permite que los genéricos sean enteros, o bien tipos
enumerados que puedan asimilarse a enteros. Es por ello que para hacer una para-
metrización eficaz, no es suficiente con el uso de genéricos.
La solución que aquí se propone es el uso combinado de genéricos y constantes
definidas en un package. El uso de estas constantes permite controlar el proceso de
síntesis, de modo que se puede:
1. Modificar la funcionalidad: se puede cambiar el modo de funcionamiento.

Por ejemplo, el límite de cuenta de un contador o los niveles activos de las
señales de e/s de una entidad.
2. Modificar la estructura: se pueden eliminar determinados componentes o

funciones del bloque completo.
3. Elegir componentes individualmente para optimizar los resultados.
11.5.13.2. Modificación de la funcionalidad
• Los genéricos y las constantes se pueden usar siempre que representen valo-
res escalares sin ningún problema:
entity Contador is
Generic( maxCuenta natural:= 10;
valActivo natural:= 7);
Port( ... ) ;
end Contador;
signal cuenta : natural range O to maxCuenta;
CONTADOR: process(reset-N, clk, cuenta)

begin
if ;reseCN = 'O, then
cuenta <= O;
els,if clk'event and c1k = '1' then
if cuenta < maxCuentathen
cuenta <= cuenta + 1;
else
cuenta <= O;
end if;
end if;
end process CONrAOOR;
salida, <= '1' when cuenta = valActi va . ei~e

'O' ;
• Los genéricos y constantes también se pueden usar como si fuesen valores

booleanos:
constant cSincrono : boolean := true;
-- ID siguiente depende de una constante, 'por lo que al sintetizar, la

-- salida de este bloque será, bien combinacional, bien secuencial.
Apéndice 1/. Normas de codificación y modelado en VHDL 483
if cSincrono = true then

_:: PaIte ··Éféct.iElftcial
(opcional)
.Sa,lida <:;: '.1';
Salida <= Entrada;
end if;
else
__ Parte combinacional (opcional)
Salida <= Entrada;
end if;
11.5.13.3. Modificación de la estructura
• Para sustituir bloques combinacionales representados mediante asignacio-

nes concurrentes se usará la sentencia generate.
constant TipoContador : tCounter := 2_Opts;
if TipoContador = 2_Opts generate

fincuenta <= 14 when delay'Iype = 1 else
23;
end generate;
if TipoContador = l_Opts generate

fincuenta <= 65;
end generate;
if TipoContador = 3_Opts generate

fincuenta <= 34 when delayType = 1 else
32 when delay'Iype = 2 else
31 when delay'Iype = 3 else
67;
end generate;
• Para sustituir bloques combinacionales representados mediante procesos, se

pueden usar genéricos o constantes.
• En descripciones estructurales, la sustitución de componentes se hará me-
diante la sentencia generate.
1/.6. EJEMPLOS
123 4 5 678
--34567890123456789Clf23·456789012345678901234567890123456789012j45678~0Í234567890
--------------------------------------------_._ ....... '--_.--..;,:._ .... _._--'
........ _--_.:.. .....-_ ..... ... __ .... _._-,._-
..;.\-
-- TRANSMISOR (Entidad, ArqUitectura y Configuración)
-- Fichero transmisor.vhd
-- Descripción Transmisor serie de dato de longitud configurable

Orden de transmisión: MSB a LSB
Bit de start: 1 bit a cero.
Bit de stop: .1 bit a uno.
-- Limitaciones: Carga directamente sobre el registro de desplazamiento

Es síncrono con el reloj del sistema. La velocidad de
transmisión la·da CLK'l'R( ~~j r~tagj.ón 9~~)'fLlC.~:
CLK _1 1_1 1_1 1_1 1_1 1_1 1_

~ \-~
CLKTR _1 I~
No ea.aíntet.íaahle porque usa .procedimientos para agrupar

acciones (procedimientos Carga y Envia).
___________
~ ~i
__ _~,~¿_;;;._;i~-~~::L_:...;-_;;-.:..j__
:.....;__-_~:_;_.:-_
.....
~...
..;;;:..~-_
... ....·.;..-:..-;..,-
...-
-- Autores: Yago Torroja
Jose Sanchez
-- Fecha: 18/05/94
---------------------_ .... __ .... _ .... _---------------------------,-------:-~--------------
UPM-DIE
-----------~_... ------------------------------------------------------------------
library IEEE;
use IEEE.stq_logic_116~.all¡
use IEEE;stCLlogicJlÚsc:all¡
use IEEE. stq_logic_ari th. all;
entity Transmisor is
Generic( n integer:= 8 ); -- NUmero de bits
Port( Clk in std_logic¡ -- Reloj del sistema

ClkTr in std...J.ogic;; .. . ~.' .,_".Frecuenci .. -de transm.
Data in unsigned(n-1 downto o); '"- Dato de entrada
LoaQ. in .s.tq_~OQ'~~¡, \\};~~ ,qe -!=¡¡.rga.,t,cH=+o a 1.II,lO)
Resetn : in stq_logic¡ --••Señal deres~t (ni~l l:la),8J.
Busy : out ·std....

logic; ~- Seflal de ocupádb (a uno): .
Tx : out std-Iogic ); -- salida serie .i:
end Transmisor;
architecture Comportamiento of Tr~smisor is

signal tempor unsignedIN..,l dorímtct O)i -- Buffer temporal
signal redDesp unsigned(N 'downtó aJ; -- Registro de desplazamiento
signal temporLl~ bc;lqlean; -- Buffer temporal lleno (a uno)
signal enviando boolean; -- Señal de envj.ando (a l.IlIO)
-signal contador integer range O to N+2; -- Contador de bits
begin
-- Generación de la señal de pcupado
busy <= '1' when temporLleno el se 'a';
PRINCIPAL
process(clk, resetn, tempor, regDesp, temporLleno, enviando, "contador)
-------------------------------------------------------~---------------------- :
-- PROCEDIMIENl'O CARGA:
-- Si se está enviando y llega un nuevo dato" se almacena sobre \ln buffer
-- auxiliar siempre y cuando esté vacío.
-- El dato se pierde si no eS almacenado.
-- Este procedimiento actúa sobre señales definidas en la arquitectura y que
-- no son enviadas como parámetros.
procedure Carga is
if not temporLleno then
temporLleno <= true;
tempor <= data;
If not enviando then
temporLleno <= false;
enviando <= true;
regDe¡Sp <=< 'o' &data;
end if;
end if;
end Carga;
;.~-;-------------------.- .... ,"'!' ... ...;--:--~,_ ....... _---_ .... - ........ -------------------------~~ ... --~ ... -
-- PROCEDIMIENl'O ENVIA:
-- Se encarga de enviáf'íos datos del registro ~ desplazamiento a través de
';;-lil señal tx. .
-- Se envía un solo bit cad.;¡ vez que'se llama el procedimiento: se desplaza
r: el registro y se Incrarenta el contador de bits.
'..i_ Ctíándó acaba la transmi~i6n 'COl11Pruebasi hay algún dato pendiente en el
-'- buffer. Si lo hay, pasa auahSliUtir el nuevo dato.
-- Este procedimiento actúa sobre señales. definidas en la arquitectura y que
-- no son enviadas como parámet:r;os." ,. .
procedure Envia(signal tx : out std.._ui<Sgic) is
begin
-- SÓlo entra cuando está transmitiendo. La señal 'enviando' se activa en
-- el proceso PRINCIPAL(se pone a true)
if enviando then
if contador <= N then
-- Transmisión de un bit
tx <= regDesp(N)¡
-- Desplazamiento
.¡;egOellP!N down.to 'll~:;_ J;egIlesp (N-l downto. O)¡ "
regDesp(a) <= '1';
"-- Incremento del contador

contador <= contador ¡"l;
else
--'Ya ha acabado de transmitir: se indica con enviando = false
enviando <= false;
-- Se borra el contador para la siguiente transmisión

contador <= O; -'A
-- Si hay un dato esperando, se prepara para ser enviado

if tenqx>rLleno then
tenqx>rLleno<= false;
RegDesp <= 'o' &tenqx>r
;
enviando <= true:
end if;
end if;
end if;
end Envia;
----------------------------------- ...- ...- ... -·':":,...~:·T"!'-"':' ...~ ... ~...-~7-tt:" .. -~~-,~.,..~~-,~-'7','7--:'-,,":";~--.....

-- COI!liEm,Zo,
del proces() PRINCIPAL ' '-, ,,", '"'' .', ,""
begin '
-- Inicialización
if resetn = 'O' then
enviando <= false;
tempdrLleno <= false;
tenqx>r <= (others => 'O');
regDesp <= (others => '1');
-- Funcionamiento síncrono
if load = '1' then
carga;
end if;
--, Sólo se transmite un nuevo, bit si clkT¡-!= .'1' •

if clld'r = '1' then
Envia(1:xl;
end if;
end if;
end process PRINCIPAL;

end Ccmportamiento;
-- COnfigllraci6n
conf.iqurat.ion CFG_TRANSMISOR_COMPORTAMIENTO of TRANSMISOR is '

for COMPORTAMIENTO
end for;
end CFG_TRANSMISOR_COMPORTAMIENTO
Glosario
ALU Arithmetic Logic Unit

Unidad Aritmético-lógica
ASIC Application Specific Integrated Circuit
Circuito integrado de aplicación específica
ATE Automatic Test Equipment
Equipo de test automático
ATPG Automatic Test Pattern Generation
Generación automática de vectores de test
BiCMOS Bipolar CMOS
CMOS Bipolar
CAD Computer Aided Design
Diseño asistido por ordenador
CAE Computer Aided Engineering
Ingeniería asistida por ordenador
CASE Computer Aided Software Engineering
Ingeniería del software asistida por ordenador
CFI CAD Framework Initiative
Iniciativa para la estandarización de entornos de CAD
CMOS Complementary Metal-Oxide Semiconductor
MOS complementaria
487
488 Glosario
CPLD Complex Programmable Logic Device

Dispositivo lógico programable complejo
CPU Central Processing Unit
Unidad central de proceso
DFf Design For Testability
Diseño para la testabilidad
DRC Des ign Rule Check
Verificación de las reglas de diseño
ECL Emitter Coupled Logic
Lógica acoplada por emisor
EDA Electronic Design Automation
Automatización del diseño electrónico
EMI Electromagnetic Interference
Interferencia Electromagnética
ERC Electrical Rule Check
Verificación de reglas eléctricas
ESDA Electronic System Design Automation
Automatización del diseño de sistemas electrónicos
FPGA Field-Programmable Gate Array
Matriz de puertas programable
FPLD Field-Programmable Logic Device
Dispositivo lógico programable
FSM Finite State Machine
Máquina de estados finita
FSMD Finite State Machine with Data
Máquina de estados finita con datos
HDL Hardware Description Language
Lenguaje de descripción de hardware
HLL High Level Language
Lenguaje de programación de alto nivel
HLS High Level Synthesis
Síntesis de alto nivel
IC Integrated Circuit
Circuito integrado
IEEE Institute of Electronics and Electrical Engineers
Instituto de ingenieros electrónicos y eléctricos
LSI Large Scale Integration
Integración a gran escala
Glosario 489
MCM MultiChip Module

Módulo multichip
MOS Metal-Oxide-Semiconductor
Metal-Óxido-Semiconductor
NMOS MOS tipo N
OMF Open Modeling Forum
Promueve la creación de un interfaz estándar para la simulación
de distintos modelos
PAL Programmable Array Logic
Matriz lógica programable
PCB Printed Circuit Board
Tarjeta de circuito impreso
PLA Programmable Logic Array
Matriz lógica"programable
PLD Programmable Logic Device
Dispositivo lógico programable
PMOS MOS tipo P
PRENDA PRoyecto para la Especificación y Normalización en el Diseño
de ASICs
RTL Register Transfer Level
Nivel de transferencia de registros
SDF Standard Delay Format
Formato estándar para el retardo
SOI-MOS Silicon on Insulator MOS
MOS de silicio sobre aislante
SoC System on Chip
Sistema en un circuito integrado
SoG Sea ofGates
Mar de puertas
VIF VHDL Intermediate Format
Formato intermedio para el VHDL
VITAL VHDL Initiative Toward ASIC Libraries
Iniciativa para la creación de bibliotecas de celdas VHDL para
el diseño de ASICS
VHDL-AMS VHDL Analog-Mixed Signal
Extensión del VHDL para el caso analógico y mixto
VLSI· Very Large Scale Integration
Integración a muy gran escala
,
Indice
Acceso, tipo, 72 rango de vectores, 78

Aceleradores hardware, 149 señales, 80
ADA, 13, 180 tipos de datos, 79
Agregados, 69 Automatización del diseño electrónico
Alias, sentencia, 267, 283 (Eleetronie Design Automation, EDA), 4,
Algoritmo, 146, 254 8, 10, 147, 180
Analizador de
léxico,153
Baekannotation (véase Retroanotación)
semántica estática, 153
Bancos de pruebas (Test-beneh), 26, 30, 286,
sintaxis, 153
366,379,402
Apuntador, 72
configurables, 483
Árboles sintácticos abstractos (Abstraet
Biblioteca de
Syntax Trees), 151
componentes, 397
Arquitectura, 46, 199
diseño, 53, 157,397,399
ASIC, 4
recursos, 397
celdas estándar precaracterizadas (semi-
Biblioteca, tipos, 397
eustomlstandard-eells), 5
Block, sentencia, 118, 212, 218
lógica programable (CPLD, FPGA,
Bloqueo (Deadloek), 141
FPLD),5
Buffer tri-estado, 212, 325
matrices de puertas predifundidas (semi-
Buses, 125
custom/gate-arrays), 5
Búsqueda de actividad, 141
totalmente a medida (jull-eustom), 5
Assert, sentencia, 98, 105
Atributos, 78 CAD (véase Herramientas CAD)
definición, 81 CAD Framework Initiative, CFI, 12
491
492 índice
Case, sentencia, 91, 215, 268 Depurado (Debugging), 144

Causalidad, 143 Detección de errores, 301,408
Ciclo de simulación, 40, 139-143 Determinismo, 254
Ciclos de acceso a memoria, 272 Director, 374
Circuitos, evolución, 3, 5, 9 Diseñador, 359
Cliente, 359 Diseño. (véase también Etapas y Flujos de
Co-diseño de hardware y software (Hw/Sw diseño)
Co-Design), 10 arquitectural, 2, 375
Cola de eventos, 40, 140 ascendente (bottom-up), 6, 23, 350
Compartición de recursos, 387 configurable, 431
Compilador, 148 de alto nivel, 10
Complejidad funcional, 398 descendente (top-down), 11,25,351,354
Componentes (Component), 37, 48,107 físico, 2, 394
declaración, 107 genérico, 368, 389,410
referencia, 107 lógico, 2, 375, 385
Componentes de biblioteca, 378 organización del, 414, 416
Comprobación de reusable, 405
diseño no considerado, 380 Diseño arquitectural, 375
estilo de codificación y nomenclatura, documento de, 381
383 revisión del, 380, 383
estilo de descripción, 383 Diseño configurable,
inicializaciones, 380 desarrollo, 432
listas de sensibilidad, 384 legibilidad, 434
terminaciones, 380 mantenimiento, 434
uso de puertos, señales, variables y nivel arquitectural, 434
genéricos, 383 pruebas, 434
valores constantes en el código, 384 selección de parámetros, 419
valores no considerados, 380 Diseño lógico, 375
Concurrencia, 254 documento de, 390
Configurabilidad, 398 revisión del, 390
Configurable, diseño (véase Diseño Dispositivos programables, 5
configurable) Documentación, 394
Configuración (Configuration), 49, 112 diseño, 407
definición, 114 diseño arquitectural, 381
especificación, 112 diseño lógico, 390
Configuración, herramientas de, 404, 408 especificaciones, 362, 369
Constantes, 58 guía de referencia, 407
Control de problemas y soluciones, 408
configuraciones, 404 propuesta de desarrollo, 361
versiones y cambios, 368 requisitos, 361
versiones y configuraciones, 401
Conversión de formato, 392
Co-rutinas, 167 EDA (véase Automatización del diseño
Co-simulación, 171 electrónico)
Co-síntesis, 149 Ejecución, 144
Cronogramas, 169 monitorizada, 154
Elementos léxicos, 54
Embedded Systems. (véase Sistemas
Derechos de propiedad intelectual, 158,410 empotrados)
Descripción en HDL (véase Modelado) Emulación, 148
índice 493
Ensamblador, 147 Flujo de control, 137

Entero, tipo, 63, 200 Flujo de diseño, 21, 354
Entidad, 44, 156 ascendente (Bottom-up), 5, 23, 354
entidad vacía, 265 descendente (Top-down), 10,25,354
Entorno del circuito (véase Bancos de Formato intermedio, 153, 180
pruebas) FSM, FSMD (véase Máquinas de estados
Entorno virtual, 352 finitos)
Equipo de diseño, 20, 372 Funcionalidad, 251
ESDA, Electronic System Design funcionamiento no considerado, 380
Automation (véase Automatización del Funciones
diseño electrónico) de conversión de tipo, 62, 252, 265
Especificaciones, 26, 254, 286 (véase de resolución, 125,256
también Etapas de diseño) declaración, 120
abiertas, 413 definición, 120
documento de, 369 llamada concurrente, 106
en HDL, 26, 367 llamada secuencial, 100
tecnológicas, 370
Estado del modelo, 137
Estilo de codificación y nomenclatura, Generate, sentencia, 110, 199
Estilo descriptivo, 16,46, 183,253,375 Genéricos, parámetros, 111, 116
algorítmico, 47, Grado de detalle, 16, 251
estructural, 48 temporización, 16, 182
flujo de datos, 47 tipos de datos, 17
mixto, 49 Gramática
Estimadores, 408 con atributos, 152
Estímulos, 287, 289 independiente del contexto, 150
Etapas de Guía de referencia, 407
análisis de viabilidad, 357
diseño arquitectural, 357
diseño físico, 357 HDL (véase Lenguajes de descripción de
diseño lógico o detallado, 357 hardware)
especificaciones, 356 descripción mixta-multinivel, 11, 17,25
fabricación y test, 357 independencia de CAD, metodología y
requisitos, 356 tecnología, 14, 19,27
Evaluación de alternativas, 374 niveles de abstracción, 16, 182
Event -driven, 139 reusabilidad, 19, 405
Exit, sentencia, 96 Herramientas CAD, 3-12, 180
Expresiones, 76 nivel de puertas, 6, 23, 28
nivel físico, 3, 7
simulación mixta-multinivel, 11, 17,25,30
Fabricación, fabricante, 378, 392 simulador SPICE, 3, 180
Fichero, tipo, 73, 402 síntesis, 10, 14, 17, 22, 26, 180
Fichero, objeto, 60 Heterarquía de procesos, 156,159
Ficheros, Hoja de catálogo (data-sheet), 408
de comandos, 402
fuente, 402
objeto, 402 Identificadores, 54
FPGA, FPW (véase Dispositivos If, sentencia, 89,216
programables) Indeterminismo, 165,254
Físico, tipo, 63, 200 Ingeniería concurrente, 10
494 índice
Inicialización, 143,205,380 Memoria,

Instrucciones ROM,301
aritmético-lógicas, 261 RAM,340
de acceso a memoria, 260 Metodología de diseño, 21, 353 (véase
de salto, 261 también Flujo de diseño)
Intelectual Property Rights, IPRs (véase Microoperaciones, 328, 334
Derechos de propiedad intelectual) Microinstrucciones, 328, 334
Interacción de procesos, 142 Microprogramas, 328, 334
Interfaz, 253, 270 Microsistemas, 9
Interoperabilidad, 407 Modelado, 144
Intérprete, 147 arquitectural-RT, 27, 182
detallado, 28, 290, 303
funcional-comportamental,26, 182,
Jerarquía, 22 254
de bloques, 159,270 Hw versus Sw, 13
de entidades de diseño, 159 multiplexores, 211
síntesis versus simulación, 13, 17, 30,
295,37
Kernel,134 Temporal, 295
Realista, 296
Modelo
Latch,217 de inserción preemptiva, 140
Layout (véase Topografía de un circuito) de simulación, 398, 409
Lazos, 216 matemático, 138
Lenguajes de descripción de hardware, para fabricación, 409
HDL, 10,12-21,26-31,136, 180, 192 Modelos-HDL (véase Modelado)
Lenguajes de Programación de alto nivel Modulos Multichip (Multichip Modules,
(High Level Languajes, HLL), 13, 146, MCM),9
147 Multiplexor, 297, 325
Listas
de componentes, 403
de sensibilidad, 112 Next, sentencia, 97
Literales, 56 Niveles de abstracción; 2,15-18
Lógica arquitectural-RT, 182,253
asíncrona, 218 físico, 2, 16
combinacional, 210 funcional-comportamental, 182
síncrona, 218 lógico-puertas, 182
Loop, sentencia, 94, 255, 279 Normas de codificación y modelado, 374
Notas de aplicación, 408
Null, sentencia, 100
Macroceldas, 352, 378 Número
Mantenimiento, 414 de edición, 403
Máquinas de estados finitos, 226 de versión, 403
con datos (FSMD), 235
estilos explícitos, 226
estilos implícitos, 233 Objetos, 58
Mealy, 226, 231 Open Modeling Forum, OMF, 21
Moore, 229, 233 Operadores, 76, 201, 207
Máscaras (véase Topografía de un circuito) Optimización de código, 386
Matriz, tipo, 68 Ordenadores mixtos, 139
índice 495
Palabras reservadas, 55 Registro (Record), tipo, 71, 200, 423

Paquete (Package) Registros, 219
cuerpo, 50 de desplazamiento, 223
declaración, 50 Report, sentencia, 98, 105
Paralelismo, 252 Requisitos
Parametrización, método de, 435 documento de, 361
Particionado, 370, 422 etapa de, 356, 359
Plan Restador, 308
de desarrollo, 370 Restricciones, 385
de pruebas, 370 sintácticas, 150
Planificación de eventos, 141 Retardo, 216
Plataformas hardware, 4,8, 12 cero, 143
Portabilidad, 167, 406 delta (?-delay), 41, 165
Prestaciones, 390 inercial, 85
Problemas y soluciones, 408 transporte, 85
Procedimientos (Procedure), 122 unidad, 142
declaración, 122 Retardo de pin a pin, 296
definición, 122 Retemporización, 237
llamada concurrente, 106, 199 Retroanotación, 6, 24, 29, 182
llamada secuencial, 106 Retum, sentencia, 100, 120, 122
Reusabilidad, 19, 158,405
Procesador
Revisión del diseño, 381, 390
4004,8086,4
máquina rudimentaria, MR, 260
Procesador hardware, 147
Segmentación, 236, 389
Procesador MR, 260
Semáforo, 255
árbitro de bus, 271
Semántica, 150
arquitectura, 261
denotacional, 153
banco de registros, 318,
operacional, 153
ciclo de acceso a memoria, 272, 280 Sentencias
conjunto de instrucciones, 260 concurrentes, 101, 210
diagrama de estados, 328, 333 estructurales, 107
estructura, 276 secuenciales, 82, 215
formato de instrucción, 336 Señales, 39
indicadores, 306 asignación concurrente, 103,210
instrucciones, 323 asignación concurrente con selección,
señales de control, 330 104,211
unidad aritmético lógica (VAL), 308 asignación concurrente condicional, 103,
unidad de control, 274, 326 211
cableada, 328, 330 asignación secuencial, 84, 215
microprogramada, 328, 334 de control, 198,231
microprograma 336 reloj, 218
unidad de proceso, 274, 304, 320 resueltas, 125
Procesador software, 147 Símbolos, 56
Proceso, 38, 213 Simulación,
Procesos postpuestos, 164 de fallos, 174
Process, sentencia, 102 de sign-off, 174
lógica, 173
peor y mejor caso, 390
Real, tipo, 63, 200 por ordenador, 137
Refinamiento progresivo, 16,27,294 temporal, 174
496 índice
Símulación Tiempo,
comparativa, 395 de simulación, 252
realista, 298 de propagación, 297, 298, 299
Simulador lógico, 287 Time-driven, 139
Sintaxis, 150 Tipos de datos, 61,251
Síntesis, 22, 28 abstractos, 183
comportamental, 184 bit, 65,183
física, 181 compuestos, 67
lógica, 181, 196 declaración, 62
mapeo tecnológico, 181 enumerado, 65, 200, 276
transferencia de registros (RT), 181, escalares, 63, 200
196 estructurados, 427
Sistemas embebidos o empotrados resueltos, 126,256
(Embedded Systems), 149 Topografía de un circuito, 3, 6, 24, 403
Sistemas en chip (Systems on chip, Traductor, 146
SOCo Systems on silicon, SOS), 9, 23,
410
Ubicación y conexionado, 6, 24, 27
Situaciones prohibidas, 303
UDL/I, 13,19
Sobrecarga
Unidad
operadores, 76, 125,201
de control, 197
subprogramas, 124
de datos, 197
Sobre-especificación, 367
de diseño, 155
Standard Delay Format, SDF, 30
Unit De/ay, 142
Subprogramas, 119
llamada concurrente, 106
llamada secuencial, 100 Validación, 138,392,408
Subtipos de datos, declaración, 66 Valor
Sumador, 18 actual, 161
completo, 311 conducido, 161
con acarreo anticipado, 313 efectivo, 161
con acarreo de propagación , 311 Variables, 59
asignación, 59, 88
globales, 254
Tareas Vector, tipo, 68
asignación, 374 Vectores
coordinación, 374 de simulación, 403
Tecnologías, 3,9,378,385 de test, 289
Temporización, Verificación, 286
funcional,182 automática, 290
lógica, 182 temporal, 303, 344
RT,182 Verilog, 10, 13, 15, 18
Terminación, 144 VHDL, 9,13-21
Test, 24, 30, 144 VHDL-AMS,l1
cobertura de faltas, 24 VIF, 155
de fabricación, 390, 409 VITAL, 21, 30,188
diseño para testabilidad (Design for
testability, DFT), 24
Wait, sentencia, 82, 214, 219, 279
máquina de, 289
testabilidad, 24
vectores de test, 289 Zero Delay, 143

VHDL Lenguaje Estandar de Diseno Electronico

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

VHDL Lenguaje Estandar de Diseno Electronico

Cargado por

Copyright:

Formatos disponibles

~NGUAJ~~~TÁNDARD~

....., 11. )0.1 tl ::ul lJ.

RAFAEL BURRIEL LLUNA

FERNANDO ALDANA MAYOR

VHDL. Lenguaje estándar de diseño electrónico.

No está permitida la reproducción total o parcial de este libro, ni su tratamiento informá-

DERECHOS RESERVADOS © 1998, respecto a la primera edición en español, por

Editor: Antonio García Brage

Eduard Lecha Lluís Terés

Pablo Sánchez Javier Uceda

Web con la presentación e información complementaria de este libro:

2. PRESENTACIÓN DEL LENGUAJE VHDL . . . . . . . . . . . . . . . . . . . . . . 35

2.1. INTRODUCCIÓN, CONTEXTO y CONCEPTOS BÁSICOS ...............•• 36

2.5.6. La sentencia loop ........................ 94

3. PROCESADO Y MECANISMOS DE SIMULACIÓN DEL LENGUA-

3.3.3. Especificación de un lenguaje de programación. . . . . . . . . . .. 150

4.4.9. Descripción de FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 226

5. MODELADO CON VHDL 249

6. LA GESTIÓN DEL DISEÑO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 349

6.1.1. Un proceso ideal de diseño en VHDL 351

Fernando Aldana Mayor, Rafael Burriel Lluna y Carlos López Barrio

Uno de los inconvenientes que genera la evolución muy rápida de la tecnología en un

FERNANOO ALOANA MAYOR

Agradezco el esfuerzo que este equipo de autores ha dedicado a la formación y

Actualmente, la mayor fuente de errores en la integración procede habitual-

síntesis a las empresas. Su campo de aplicación apenas ha comenzado y permitirá la

RAFAEL BURRIEL LLUNA

La evolución de la tecnología microelectrónica ha sido tan rápida y profunda durante

Todo lo anterior tiene como piedra angular la utilización de los ya mencionados

CARLOS A. LÓPEZ BARRIO

La evolución de la microelectrónica desde su nacimiento ha sido impresionante. En

perfiles de los equipos de diseño, cambios en la organización y desarrollo de proyec-

El objetivo de esta breve presentación es mostrar qué son los lengua-

1.1. EVOLUCiÓN DEL DISEÑO ELECTRÓNICO

El desarrollo electrónico de los últimos tiempos se ha visto fuertemente dominado y

FIGURA 1-1. Pirámide de complejidad y niveles de abstracción de las distintas fa-

incidencia decisiva en el desarrollo de nuevas herramientas y entornos integrados de

1.1.1. Años setenta

A pesar de estas dificultades surgieron las primeras memorias DRAM de 1

1.1.2. Años ochenta

circuitos integrados desarrollados para aplicaciones específicas pudiendo ser dise-

1. Diseño totalmente a medida (jull-custom). El diseñador se enfrenta a los ni-

" especificaciones funcionales ,,

Ubicación y conexionado (layout)

FIGURA 1-2. Flujo genérico de diseño ascendente (bottom-up) de circuitos semi-

• Procesos de ubicación y conexionado (place&route) de celdas y bloques uti-

Extractor de lista de componentes y conexiones (Netlist)

Esquema (E) Topografía (T)

Simulador Analógico (SPICE)

FIGURA 1-3. Entorno de diseño a nivel eléctrico y geométrico para el desarrollo de

H: Herramienta, idU: Interfaz de Usuario, BdD: Base de Datos, I/F: Interfaz

FIGURA 1-4. Evolución de las herramientas y entorno de CAD: (a) Herramientas

Todos estos avances empujaron y a la vez se apoyaron en la propia evolución

1.1.3. Años noventa

VHDL sintetizable) u optimizados a nivel hard (layout o topografía específica), cu-

I El objetivo de la ingeniería concurrente es simultanear las tareas de distintos departamentos o

1.2. LOS LENGUAJES DE DESCRIPCiÓN DE HARDWARE

2 La CFI (CAD Framework lnitiative) promueve la creación de un estándar para el desarrollo de

1.2.1. Lenguajes de descripción de Hw versus desarrollo

(a) Desarrollo de Software (b) Desarrollo de Hardware

FIGURA 1-6. Desarrollo de software versus hardware: (a) niveles de abstracción y

Mientras en software se recurre a los lenguajes de alto nivel para implementar

1.2.2. Reseña histórica de los HDLs

Actualizar señales _ (-ºJ JQL _--- ...... _-------_.