VHDL Lenguaje Estandar de Diseno Electronico PDF

~NGUAJ~~~TNDARD~
DI~~O~~CTRNICO
SeroHn Olloz
Eugenio Villcir
Yago 'forrojo
Lluis Tores
....., 11. )0.1 tl ::ul lJ.
J "
En lo direccin hHp:/ /www.cnm.es/IMB/UbroVHDLJ del Web se pueden encontrar
uno presentacin del libro, ejercicios resueltos, el cdigo completo de los proyectos
utilizados en el libro y algunos secciones complementarias que se irn actualizando
peridicamente.
VHDL
LENGUAJE ESTNDAR
DE DISEO ELECTRNICO
VHDL ,
LENGUAJE
- ESTANDAR
,
DE DISENO ELECTRONICO
Eugenio Villar
Doctor en Ciencias Fsicas
Facultad de Ciencias de Cantabria
Profesor titular de Tecnologa Electrnica (Universidad de Cantabria)
Llus Ters
Doctor en Informtica (UAB)
Colaborador Cientfico deIIMB-CNM (CSIC)
Profesor asociado del Dpto. Informtico (UAB)
Serafn Olcoz
Doctor en Ciencias Fsicas
Universidad de Zaragoza
Jefe del Dpto. de Tecnologas de Diseo (SIDSA)
Yago Torroja
Ingeniero Industrial
Profesor asociado de Tecnologa Electrnica
Universidad Politcnica de Madrid
E. T. Superior de Ingenieros Industriales (UPM)
PRESENTACiN DE:
CARLOS LPEZ BARRIO
Catedrtico de Tecnologa Electrnica ETSIT-UPM
Director de Innovacin de Telefnica I+D
RAFAEL BURRIEL LLUNA

Centro de Investigacin y Desarrollo de Alcatel. Espaa
FERNANDO ALDANA MAYOR

Catedrtico de Tecnologa Electrnica (ETSII-UPM)
McGraw-Hill
MADRID BUENOS AIRES CARACAS GUATEMALA LISBOA MXICO
NUEVA YORK. PANAM. SAN JUAN. SANTAF DE BOGOT. SANTIAGO SAO PAULO
AUCKLAND HAMBURGO LONDRES MILN MONTREAL NUEVA DELHI PARs
SAN FRANCISCO SIDNEY SINGAPUR STo LOUIS TOKIO TORONTO
La informacin contenida en este trabajo ha sido obtenida
por McGraw-Hill Incorporated procedente de fuentes dig-
nas de crdito. No obstante, ni McGraw-Hill ni los autores
garantizan la exactitud o perfeccin de la informacin pu-
blicada.
Ni McGraw-Hill ni los autores sern responsables de
cualquier error, omisin o dao ocasionados por el uso de
esta informacin. Este trabajo se publica con el reconoci-
miento expreso de que los autores estn proporcionando
una informacin, pero no tratando de prestar ningn tipo de
servicio profesional o tcnico. Si tal servicio fuera necesa-
rio, drjase a un profesional adecuado para tal fin.
VHDL. Lenguaje estndar de diseo electrnico.
No est permitida la reproduccin total o parcial de este libro, ni su tratamiento inform-

tico, ni la transmisin de ninguna forma o por cualquier medio, ya sea electrnico, mec-
nico, por fotocopia, por registro u otros mtodos, sin el permiso previo y por escrito de
los titulares del Copyright.
DERECHOS RESERVADOS 1998, respecto a la primera edicin en espaol, por

McGRAW-HILUINTERAMERICANA DE ESPAA, S. A. U.
Edificio Valrealty, l." planta
Basauri,17
28023 Aravaca (Madrid)
ISBN: 84-481-1196-6
Depsito legal: M. 42.860-1997
Editor: Antonio Garca Brage

Cubierta: Juan Garca
Compuesto en: FER Fotocomposicin, S. A.
Impreso en: Impresos y Revistas, S. A. (IMPRESA)
IMPRESO EN ESPAA - PRINTED IN SPAIN
Coautores
Eduard Lecha Llus Ters

Instituto de Microelectrnica de Barcelona, CNM Instituto de Microelectrnica de Barcelona, CNM
(CSIC). Universitat Autnoma de Barcelona (CSIC). Universitat Autnoma de Barcelona
eduard@cnm.es lluis@cnm.es
Manel Mor de Castro Eduardo de la Torre
Instituto de Microelectrnica de Barcelona, CNM Universidad Politcnica de Madrid, ETSII
(CSIC). Universitat Autnoma de Barcelona eduardo@upmdie.upm.es
manel@cnm.es
Yago Torroja
Serafn Olcoz Universidad Politcnica de Madrid, ETSn
SIDSA
yago@upmdie.upm.es
olcoz@sidsa.es
Teresa Riesgo Joan Vidal
Instituto de Microelectrnica de Barcelona, CNM
Universidad Politcnica de Madrid, ETSn
tere@upmdie.upm.es (CSIC). Universitat Autnoma de Barcelona
vidal@cnm.es
Fernando Rincn
Instituto de Microelectrnica de Barcelona, CNM Eugenio Villar
(CSID). Universitat Autnoma de Barcelona Universidad de Cantabria
femando@cnm.es villar@teisa.unican.es
Pablo Snchez Javier Uceda

Universidad de Cantabria Universidad Politcnica de Madrid, ETSII
sanchez@teisa.unican.es uceda@upmdie.upm.es
Web con la presentacin e informacin complementaria de este libro:

http://www.cnm.es/IBMlLibroVHDU
v
Contenido
PRESENTACIN . xv
PRLOGO . xxi
1. INTRODUCCIN . 1
1.1. EVOLUCIN DEL DISEO ELECTRNICO . 2
1.1.1. Aos setenta . 3
1.1.2. Aos ochenta . 4
1.1.3. Aos noventa . 9
1.2. Los LENGUAJES DE DESCRIPCIN DE HARDWARE ......... 12
1.2.1. Lenguajes de descripcin de Hw versus desarrollo de Sw . 13
1.2.2. Resea histrica de los HDLs . 14
1.2.3. Modelado con HDLs: niveles de abstraccin y estilos descrip-
tivos . 16
1.2.4. Aportaciones de los HDLs al proceso de diseo . 19
1.3. METODOLOGAS y FLUJOS DE DISEO . 21
1.3.1. Flujo de diseo ascendente (bottom-up) . 23
1.3.2. Flujo de diseo descendente (top-down) . 25
1.3.2.1. Construccin o diseo descendente . 26
1.3.2.2 .. Informacin ascendente (bottom-up) . 29
1.3.2.3. Validacin funcional multinivel . 30
1.4. BIBLIOGRAFA ............................................ 31
vii
viii Contenido
2. PRESENTACIN DEL LENGUAJE VHDL . . . . . . . . . . . . . . . . . . . . . . 35
2.1. INTRODUCCIN, CONTEXTO y CONCEPTOS BSICOS ............... 36

2.2. UN MODELO DEL HARDWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.1. Modelo de estructura: componentes y jerarqua. . . . . . . . . . . . 37
2.2.2. Modelo de concurrencia: procesos, seales y eventos. . . . . . . . 38
2.2.3. Modelo de tiempo: ciclo de simulacin 40
2.3. UNIDADES BSICAS DE DISEO 43
2.3.1. Declaracin de entidad 44
2.3.2. Arquitectura 46
2.3.2.1. Estilo algortmico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Configuracin....................................... 49
2.3.4. Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 50
2.3.5. Bibliotecas 53
2.4. OBJETOS, TIPOS DE DATOS Y OPERACIONES . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.1. Elementos lxicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.4.1.1. Identificadores 54
2.4.1.2. Palabras reservadas 55
2.4.1.3. Smbolos 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. Seales 60
2.4.2.4. Ficheros 60
2.4.3. Tipos de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4.3.1. Declaracin de tipos de datos. . . . . . . . . . . . . . . . . . . . 62
2.4.3.2. Tipos de datos escalares. . . . . . . . . . . . . . . . . . . . . . . . 63
2.4.3.3. Declaracin 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 seales 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. Asignacin a seal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.5.3. Asignacin 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. Asignacin a seal concurrente. . . . . . . . . . . . . . . . . . . . . . . .. 103
2.6.3. Asignacin concurrente condicional 103
2.6.4. Asignacin concurrente con seleccin. . . . . . . . . . . . . . . . . . .. 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. Configuracin de un diseo. . . . . . . . . . . . . . . . . . . .. 112
2.6.7.4. Genricos 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 resolucin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 125
2.8. EJERCICIOS 128
2.9. BIBLIOGRAFA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3. PROCESADO Y MECANISMOS DE SIMULACIN DEL LENGUA-

JEVHDL 135
3.1. INTRODUCCIN ........................................... 136
3.2. SIMULACIN POR ORDENADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 137
3.2.1. Descripcin del tiempo y/o distintos tipos de simulacin 139
3.2.1.1. Simulacin dirigida por el paso del tiempo 139
3.2.1.2. Simulacin dirigida por eventos discretos. . . . . . . . .. 139
3.2.1.3. Modelos de avance del tiempo. . . . . . . . . . . . . . . . . .. 142
3.2.2. Estructura general de la simulacin 143
3.2.3. Aproximacin metdica a la simulacin 144
3.2.3.1. Modelado 144
3.2.3.2. Prueba...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 145
3.2.3.3. Explotacin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 146
3.3. PROCESADO DE UN LENGUAJE DE PROGRAMACIN .. . . . . . . . . . . . . . . .. 146
3.3.1. Procesadores de lenguajes. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 146
3.3.2. Compiladores Software, Hardware e hbridos. . . . . . . . . . . . .. 148
X Contenido
3.3.3. Especificacin de un lenguaje de programacin. . . . . . . . . . .. 150

3.3.3.1. Sintaxis..................................... 150
3.3.3.2. Restricciones de contexto. . . . . . . . . . . . . . . . . . . . . .. 152
3.3.3.3. Semntica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 153
3.3.4. Proceso de compilacin de un lenguaje de programacin 153
3.4. SIMULACINDE UNAENTIDADDE DISEOVHDL 154
3.4.1. Procesado de una descripcin VHDL 155
3.4.1.1. Anlisis de una unidad de diseo VHDL . . . . . . . . . .. 156
3.4.1.2. Elaboracin de una jerarqua de diseo VHDL 158
3.4.1.3. Simulacin de una entidad de diseo VHDL . . . . . . .. 163
3.4.1.4. Modelo Temporal &.delay 165
3.4.1.5. Determinismo en VHDL 165
3.4.1.6. Ejecucin secuencial o concurrente. . . . . . . . . . . . . .. 167
3.4.2. Simulador VHDL 168
3.5. MODELADOEN VHDL PARASIMULACIN.. . . . . . . . . . . . . . . . . . . . . .. 171
3.5.1. Simulacin lgica, temporal y de fallos . . . . . . . . . . . . . . . . .. 173
3.6. EJERCICIOS 175
3.7. BIBLIOGRAFA............................................. 176
4. SNTESIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 179
4.1. INTRODUCCIN 180
4.1.1. Proceso de sntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 181
4.1.2. Modelado para simulacin frente a modelado para sntesis. .. 190
4.1.3. Objetivos........................................... 192
4.2. APLICACINDE VHDL EN SNTESIS 192
4.2.1. Restricciones sintcticas y semnticas. . . . . . . . . . . . . . . . . . .. 193
4.2.2. Discrepancias entre resultados de simulacin. . . . . . . . . . . . .. 194
4.3. SNTESISRT-LGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 195
4.3.1. Sntesis lgica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 196
4.3.2. Sntesis RT ".................. 196
4.4. DESCRIPCiNVHDL DE CIRCUITOSDIGITALES 199
4.4.1. Descripcin del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 199
4.4.2. Modelado de la informacin 200
4.4.3. Funciones y operadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 201
4.4.4. Paquetes de sntesis P1076.3 201
4.4.4.1. Interpretacin hardware de tipos estndar . . . . . . . . .. 202
4.4.4.2. Expresiones de valor inicial y por defecto . . . . . . . . .. 205
4.4.4.3. Deteccin de la transicin activa de la seal de reloj .. 206
4.4.4.4. Paquetes aritmticos . . . . . . . . . . . . . . . . . . . . . . . . . .. 206
4.4.5. Descripcin de lgica combinacional 210
4.4.6. Descripcin de latches . . . . . .. 217
4.4.7. Descripcin de la seal 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. Descripcin de FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 226

4.4.10. Descripcin de FSMDs 235
4.4.11. Segmentacin 236
4.5. RECOMENDACIONES GENERALES 238
4.5.1. Recomendaciones para sntesis 239
4.5.1.1. Descripcin de hardware 239
4.5.1.2. Limpieza del cdigo. . . . . . . . . . . . . . . . . . . . . . . . . .. 240
4.5.1.3. Correspondencia entre simulacin y sntesis 241
4.5.1.4. Conocimiento de la herramienta 241
4.6. EJERCICIOS 242
4.7. BIBLIOGRAFA.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 246
5. MODELADO CON VHDL 249

5.1. INTRODUCCIN ..................................... 250
5.2. EL MODELADO DE UN SISTEMA A DIFERENTES NIVELES DE DETALLE ..... 251
5.2.1. Tipos de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 251
5.2.2. Expresin del tiempo y paralelismo . . . . . . . . . . . . . . . . . . . . .. 252
5.2.3. Estilos de descripcin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 253
5.3. MODELADO FUNCIONAL 254
5.3.1. La mquina rudimentaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 260
5.3.1.1. Arquitectura del procesador a nivel de lenguaje m-
quina 260
5.3.1.2. Modelo funcional de la mquina rudimentaria. . . . . .. 263
5.4. MODELADO ESTRUCTURAL 270
5.4.1. La mquina 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. Anlisis de las respuestas. . . . . . . . . . . . . . . . . . . . . . 290
5.4.3. La mquina rudimentaria: el banco de pruebas 292
5.5. MODELADO DETALLADO 294
5.5.1. Modelado para sntesis vs modelado para simulacin 295
5.5.2. El modelado del tiempo 295
5.5.3. La comprobacin de errores 301
5.5.4. El modelado detallado de la Mquina 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. BmLIoGRAFA ............................................ 348
6. LA GESTIN DEL DISEO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 349

6.1. INTRODUCCIN 350
xii Contenido
6.1.1. Un proceso ideal de diseo en VHDL 351

6.1.2. El proceso real de diseo en VHDL . . . . . . . . . . . . . . . . . . . . .. 352
6.1.3. Orientacin y objetivos del captulo 353
6.2. PLANIFICACIN DE UN DISEO DESCENDENTE. . . . . . . . . . . . . . . . . . . . .. 354
6.2.1. Elflujo de diseo 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 diseo arquitectural y lgico. . . . . . . . . . . . . . . . . . . . . . . .. 374
6.2.3.1. Desarrollo del diseo arquitectural. . . . . . . . . . . . . . .. 375
6.2.3.2. La revisin del diseo arquitectural. . . . . . . . . . . . . .. 381
6.2.3.3. Desarrollo del diseo lgico. . . . . . . . . . . . . . . . . . . .. 385
6.2.3.4. La revisin del diseo lgico .. . . . . . . . . . . . . . . . . .. 390
6.2.4. El diseofisico y lafabricacin . . . . . . . . . . . . . . . . . . . . . . . .. 391
6.2.5. La validacin y caracterizacin del circuito 392
6.2.6. Documentacin, evaluacin y seguimiento del proyecto . . . . .. 394
6.3. DESARROLLO y ORGANIZACIN DE BmLlOTECAS EN VHDL . . . . . . . . . .. 394
6.3.1. Bibliotecas y componentes de biblioteca 396
6.3.2. La biblioteca de diseo 399
6.3.3. Gestin de bibliotecas. Versiones y configuraciones. . . . . . . .. 401
6.3.3.1. Control de versiones. . . . . . . . . . . . . . . . . . . . . . . . . .. 402
6.3.3.2. Control de configuraciones 403
6.4. DISEO PARA REUSABIliDAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 405
6.4.1. Por qu hacer diseos reutilizables? .. . . . . . . . . . . . . . . . . .. 406
6.4.2. La comercializacin de una biblioteca. . . . . . . . . . . . . . . . . . .. 407
6.5. DISEO GENRICO ......................................... 410
6.5.1. Definicin de diseo genrico 410
6.5.2. Ventajas e inconvenientes del diseo genrico. . . . . . . . . . . . .. 413
6.5.3. Desarrollo de componentes genricos. Recomendaciones .... 415
6.5.3.1. Organizacin del diseo. . . . . . . . . . . . . . . . . . . . . . .. 416
6.5.3.2. Seleccin de parmetros. . . . . . . . . . . . . . . . . . . . . . .. 419
6.5.3.3. Particionado del diseo 422
6.5.3.4. Estructuras de datos 423
6.5.3.5. Otras recomendaciones sobre la codificacin 425
6.6. DISEOS CONFIGURABLES 431
6.6.1. Desarrollo de un componente configurable. . . . . . . . . . . . . . .. 432
6.6.1.1. Seleccin de los parmetros de configuracin . . . . . .. 433
6.6.1.2. Aspectos a considerar en la generacin de componentes
configurables en VHDL . . . . . . . . . . . . . . . . . . . . . . .. 433
6.6.1.3. Diseo arquitectural. . . . . . . . . . . . . . . . . . . . . . . . . .. 434
6.6.1.4. Mtodo de generacin 435
6.6.1.5. Bancos de prueba . . . . . . . . . . . . . . . . . . . . . . . . .. 437
6.7. EJERCICIOS 438
6.8. BmLIOGRAFA ' . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 440
Contenido xiii
APNDICE 1 443
APNDICE 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 461
GLOSARIO 487
NDICE 491
Presentacin
Fernando Aldana Mayor, Rafael Burriel Lluna y Carlos Lpez Barrio
Uno de los inconvenientes que genera la evolucin muy rpida de la tecnologa en un

determinado campo, es la gran dificultad que tienen los profesionales del sector para
adaptarse a los cambios en los mtodos, procedimientos y herramientas. Como resul-
tado de estos efectos, las empresas dedican cada vez ms recursos a sus actividades
de formacin continua.
Nuestra sociedad de la informacin se sustenta sobre el desarrollo microelectr-
nico, que permite disear y fabricar a un ritmo vertiginoso sistemas electrnicos cada
vez ms complejos a costes muy razonables; pero ese aumento de la complejidad
sobre el que se apoya el desarrollo ha exigido modificar, casi dira revolucionar, los
procedimientos de diseo y fabricacin.
Las metodologas de diseo electrnico denominadas "top-down", basadas en el
empleo de lenguajes de descripcin de hardware, han transformado los procedimien-
tos de diseo de sistemas electrnicos, muy especialmente de circuitos integrados. El
lenguaje VHDL es su ms claro exponente, abriendo enormes posibilidades al per-
mitir la simulacin con descripciones de partes del sistema con diferentes niveles de
abstraccin. Esto, unido a la posibilidad de realizar la sntesis automtica, y a la con-
cepcin de bloques reutilizables y reconfigurables en funcin de las necesidades de
la aplicacin, ha permitido dotar al diseador de enormes recursos que hacen posi-
ble abordar la creciente complejidad con mayores garantas de xito.
Admitidas las ventajas, ha sido necesario adaptar la formacin de los ingenieros
de diseo y test, pasando de un perfil claramente electrnico, orientado a la interco-
nexin de bloques hardware, a un perfil ms algortmico, ms informtico, conse-
cuencia de los nuevos procedimientos. En el marco de esa demanda de formacin
xv
xvi Presentacin
aparece este libro, dando satisfaccin a una necesidad bien identificada entre los tc-
nicos de habla hispana.
Se trata de una obra que recoge los temas fundamentales vinculados a la utiliza-
cin del lenguaje VHDL, tratando los fundamentos de la sintaxis, describiendo los
mecanismos de simulacin, las tcnicas de modelado y la sntesis. No es un libro
ms 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 metodologa basada en
VHDL.
Es un texto ms para ingenieros de diseo que para especialistas en lengua-
jes de sistemas informticos. Est indicado para estudiantes de ingeniera con una
buena formacin de base en electrnica e informtica o estudiantes de los ltimos
cursos de carrera. Este libro tambin podra emplearse en actividades de post-
grado, orientadas a la formacin 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 combinacin de profesionales de la empresa, profesores
universitarios e investigadores en microelectrnica.
En sntesis, este trabajo supone una aportacin valiosa en el proceso de adapta-
cin tecnolgica a unas circunstancias cambiantes, que han exigido, exigen yexigi-
rn esfuerzo e imaginacin a los profesionales de un sector tan dinmico como es la
microelectrnica.
FERNANOO ALOANA MAYOR

Catedrtico de Tecnologa Electrnica
ETSll. Universidad Politcnica de Madrid
Agradezco el esfuerzo que este equipo de autores ha dedicado a la formacin y

divulgacin del VHDL, tanto en el contexto acadmico como en el industrial. Esta
aportacin contribuye indudablemente a la creciente y fructfera relacin entre
ambos entornos.
Existe un inevitable proceso del ser humano tendente a eliminar su propia inter-
vencin en cualquier actividad que, paradjicamente, comienza l mismo. Esto tam-
bin ha ocurrido en el campo del diseo de Circuitos Integrados de Aplicacin Espe-
cfica ASICs con la introduccin del VHDL.
Los objetivos de este proceso estn 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 informacin de forma que
sea factible su manejo y transferencia. La existencia de una documentacin fiable
tanto de una biblioteca de clulas, de ASICs completos, de su especificacin para su
posterior reutilizacin para una nueva sntesis, constituye tambin un imprescindi-
ble condicionante econmico empresarial.
Presentacin xvii
Actualmente, la mayor fuente de errores en la integracin procede habitual-

mente de defectos en la especificacin del ASIC, que podran haberse evitado
mediante la utilizacin de un lenguaje formal, apto para su simulacin y posterior
sntesis, capaz de incorporar ficheros tecnolgicos y criterios de integracin necesa-
rios para eliminar las ambigedades existentes en la misma; esto obliga a una slida
coherencia en la fase de especificacin. 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 podran solicitarles futuros productos.
Actualmente ya se dispone, y se continan desarrollando, de mltiples ayudas
por ordenador que, basndose en estas descripciones VHDL, incorporarn ayudas
complementarias para un posicionado ptimo de bloques, trazados inteligentes, esti-
macin y posterior verificacin de caminos crticos, sntesis con optimizacin inte-
ractiva de rea, velocidad y arquitecturas, insercin automtica de capacidad de diag-
nstico, generacin automtica de patrones de prueba, consumo, etc. y finalmente un
paso que es inevitable para el diseo de ASICs ms complejos: el desarrollo de
herramientas y entornos de Co-Diseo HW y SW para la optimizacin en la distri-
bucin de tareas, emulacin, simulacin y finalmente realizacin. Realmente el
VHDL se est convirtiendo en el lenguaje universal de la microlectrnica (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 elctrico y electrnico de la realidad, ni el
objetivo industrial de la integracin en cuanto a coste, plazo, consumo, interfaz con
el mundo real, etc.
As, la introduccin del VHDL est eliminando, prcticamente, las tradiciona-
les tcnicas de diseo basadas en clulas de biblioteca, captura de esquemas, etc.,
para los ASICs digitales; el mundo analgico con una mayor componente artstica,
artesanal y de intuicin todava se resiste a la disciplina de la formalizacin VHDL,
que por otra parte an no est completamente disponible.
El diseo de Circuitos Integrados a la Medida (antiguos circuitos LSI o VLSI, y
posteriormente ASICs) ha adolecido desde sus comienzos a principios de la dcada
de los setenta de facilidades para que las empresas establezcan un interfaz industrial
adecuado y slido para migrar un diseo realizado con una determinada biblioteca de
clulas de un fabricante, a otra de otro fabricante, lo que se denomina segunda
fuente y tiene una definida componente estratgica.
Otro aspecto igualmente importante lo constituye la necesaria transferibilidad a
una empresa, de diseos, arquitecturas o desarrollos de ASICs realizados por cen-
tros externos a dicha empresa -por ejemplo a travs de Programas Comunitarios-
la cual necesita reutilizarlos total o parcialmente para su posterior incorporacin a
integraciones (ASICs) de mayor escala en su propio entorno. La reutilizacin es un
factor muy importante con una positiva repercusin econmica 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 sntesis en otro con-
texto tecnolgico.
As, la incorporacin del lenguaje VHDL a la realizacin 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 diseadores
de forma sustancial y se ha facilitado la utilizacin de herramientas industriales de
xviii Presentacin
sntesis a las empresas. Su campo de aplicacin apenas ha comenzado y permitir la

integracin de los mil millones de puertas, tal como se anuncia, al final de la
siguiente dcada y ...
RAFAEL BURRIEL LLUNA

Centro de Investigacin y Desarrollo de Aleatel Espaa
La evolucin de la tecnologa microelectrnica ha sido tan rpida y profunda durante

la ltima dcada 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 diseo y de las herramientas de ayuda y automatizacin del mismo.
As, el enfoque con el que se disean los circuitos integrados ha tenido que ir
evolucionando a travs de varios niveles de abstraccin. Del diseo geomtrico del
circuito y resolucin de las ecuaciones diferenciales, se pas al diseo con transis-
tores ayudado por simulacin elctrica, para evolucionar posteriormente hacia el
diseo lgico con ayuda de editores de esquemas y simulacin lgica y elctrica,
hasta llegar finalmente a la actual metodologa, basada en la descripcin del com-
portamiento de los circuitos mediante lenguajes de descripcin hardware, simula-
cin a nivel de comportamiento y utilizacin de herramientas de sntesis lgica.
Esta metodologa y herramientas asociadas son, hoy en da, instrumentos bsicos y
sera impensable el diseo 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 estn de alguna manera ligados al mundo de los circuitos
integrados.
La correcta realizacin de las fases de alto nivel es probablemente la tarea ms
importante en el diseo de un circuito. Las decisiones de arquitectura son las que tie-
nen un mayor impacto en todos los parmetros de los circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores se tienen que realizar siempre impor-
tantes contribuciones al diseo, es difcil que optimizaciones realizadas en dichas
fases puedan compensar una mala seleccin de la arquitectura de un circuito.
La c'Orrecta realizacin de las fases de alto nivel es probablemente la tarea ms
importante en el diseo de un circuito. Las decisiones de arquitectura son las que tie-
nen un mayor impacto en todos los parmetros de los circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores se tienen que realizar siempre impor-
tantes contribuciones al diseo, es difcil que optimizaciones realizadas en dichas
fases puedan compensar una mala seleccin de la arquitectura de un circuito.
El diseo de alto nivel es adems el punto de encuentro de los diseadores de
sistemas y de circuitos. Ambos deben aportar sus contribuciones, bien desde el cono-
cimiento de las aplicaciones bien desde el de la tecnologa. Por ello este libro est
dirigido a un amplio grupo de profesionales, desde los diseadores de sistemas, que
ven la necesidad de incorporar las ltimas tecnologas microelectrnicas, hasta los
diseadores de circuitos, pasando por supuesto por los estudiantes interesados en
estas materias.
Presentacin xix
Todo lo anterior tiene como piedra angular la utilizacin de los ya mencionados

lenguajes de descripcin hardware. De todos ellos, el VHDL, definido como un
estndar, ha ido ganando fuerza tanto en el mundo universitario como industrial. De
ah el inters de este libro concentrado en analizar todos los aspectos de dicho len-
guaje. En esta lnea el libro ofrece un planteamiento sencillo y pragmtico, presen-
tando no slo la sintaxis del lenguaje VHDL, sino tambin gran cantidad de detalles
prcticos y ejemplos que facilitan la compresin de los conceptos. Por otra parte, el
ltimo captulo incluye una referencia sobre consideraciones prcticas de la gestin
de un diseo que puede resultar de especial relevancia para los diseadores de siste-
mas que se quieren adentrar en el mundo de la microelectrnica. Muchos de los
aspectos all reseados son tristemente olvidados en casi todos los manuales tcni-
cos, y deben ser aprendidos con gran esfuerzo a travs de la experiencia.
Hemos de felicitamos por esta iniciativa de un amplio grupo de profesionales
de nuestro pas, tanto del mundo acadmico como industrial, por volcar en este texto
la experiencia acumulada a lo largo de aos de trabajo docente, de diseo, de inves-
tigacin y de cooperacin en el marco del Grupo Espaol de Usuarios de VHDL, as
como por contribuir a disponer de bibliografa microelectrnica en espaol, la cual,
tristemente, es muy escasa.
Estoy seguro de que este libro servir como referencia a muchos diseadores ya
experimentados, pero tambin constituye un excelente texto para un curso de grado o
postgrado universitario. Espero, por tanto, no slo que el lector disfrute con su lec-
tura, sino que nos ayude tambin a difundir los conocimientos bsicos sobre las tc-
nicas de diseo microelectrnico.
CARLOS A. LPEZ BARRIO

Catedrtico de Tecnologa Electrnica (ETSIT-UPM) y
Director de Innovacin (Telefnica I + D)
Prlogo
La evolucin de la microelectrnica desde su nacimiento ha sido impresionante. En

poco ms de diez aos se pas del primer dispositivo integrado (jlip-flop con unos po-
cos transistores) a las primeras memorias y procesadores. A los pocos aos, el diseo
de circuitos integrados sali de las fbricas y se hizo accesible a los ingenieros de apli-
cacin, dando lugar a los ASIC (Application Specific Integrated Circuit). Ya entonces,
mediados de los aos ochenta, se puso de manifiesto la necesidad de disponer de un
lenguaje estndar capaz de dar el soporte necesario al proceso completo de diseo de
chips y sistemas electrnicos (desde la idea hasta la implementacin y explotacin
de un desarrollo) en sus distintas etapas y niveles de abstraccin y cuya complejidad,
ya de por s elevada, se iba a incrementar drsticamente hacia los aos noventa.
Estas inquietudes, canalizadas a travs del DoD (Dpt. of Defense) de los EEUU,
llevan al nacimiento del VHDL (1987), que, tras ser adoptado como estndar del IE-
EE (Std.-I076-1987), se presenta como el lenguaje estndar por excelencia del dise-
o electrnico. 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 metodologas,
tcnicas y herramientas CAD de diseo electrnico de los ltimos diez aos. Esta
evolucin arrastra al propio Verilog, ahora tambin convertido en estndar del IEEE
(Std.-1364-1995), que se ha convertido en competidor y compaero de viaje de
VHDL.
En definitiva, y aunque slo debamos considerar al VHDL como una herra-
mienta de base, la implantacin de este lenguaje ha supuesto tal cantidad de cambios
en el diseo electrnico (nuevas metodologas de diseo de alto nivel y flujos des-
cendentes, herramientas CAD de simulacin/sntesis de circuitos y sistemas, nuevos
xxi
xxii Prlogo
perfiles de los equipos de diseo, cambios en la organizacin y desarrollo de proyec-

tos, etc.), que, sin lugar a dudas, se puede hablar de un antes y un despus del VHDL.
La idea de desarrollar este libro surge en el seno del Grupo Usuarios de VHDL
de Espaa (GUVE) y se asienta sobre la base de una larga trayectoria de colabora-
cin entre los distintos coautores y sus respectivos centros. Durante los ltimos aos
esta estrecha relacin se ha vehiculado en repetidas ocasiones a travs del programa
GAME (Grupo Activador de la Microelectrnica en Espaa) de la Comisin Euro-
pea, y en especial alrededor de uno de sus ltimos proyectos: PRENDA (PRoyecto
para la Estandarizacin y Normalizacin del Diseo de ASIC's). As pues, la con-
vergencia de algunos proyectos, la motivacin, experiencia y colaboracin de los co-
autores y sobre todo el constante estmulo del GUVE para promover y facilitar la di-
fusin e implantacin de estas nuevas tcnicas de diseo electrnico, son las bases
que han dado lugar a este libro.
El libro que aqu les presentamos se ha concebido, no slo para presentar y dar
a conocer el lenguaje VHDL, sino que adems condensa en unos pocos captulos las
distintas facetas del mismo y su explotacin dentro del proceso de diseo. En este
sentido podemos decir que se trata de una gua aplicada del VIDL, siendo a su vez
altamente autocontenido.
As pues, tras la ubicacin de estos lenguajes dentro de la evolucin del diseo
electrnico (Captulo 1), se procede a una presentacin del lenguaje VHDL (Captu-
lo 2) que, sin ser exhaustiva, es muy completa y detallada, basndose en numerosos
ejemplos que facilitan la comprensin ntima del lenguaje.
A continuacin en el Captulo 3 se estudian en detalle el procesado del lenguaje
y los mecanismos de simulacin que permitirn al lector extraer criterios de mode-
lado para aplicar de forma eficiente en las descripciones para simulacin en VHDL.
Por su parte, la sntesis desde el VHDL es, junto con la simulacin, una de las prin-
cipales aplicaciones del lenguaje. El Captulo 4, tras un anlisis general sobre el uso
de estos lenguajes en los procesos de sntesis, se dedica a detallar la utilizacin del
VHDL a nivel de sntesis RT-lgica en base a los mtodos y herramientas CAD ac-
tuales. Ello, junto con un conjunto de recomendaciones de modelado para sntesis,
proporcionar al lector los conocimientos y criterios necesarios para un modelado
eficiente para la sntesis.
En el Captulo 5 se muestra la utilizacin del VHDL en distintos aspectos del
modelado de sistemas electrnicos (modelado del diseo y del entorno de test, simu-
lacin versus sntesis, etc.). Es una presentacin muy aplicada que se apoya en el de-
sarrollo de un ejemplo completo: un pequeo procesador y su entorno. Es un ejemplo
sencillo cuyo recorrido permite consolidar unos conocimientos prcticos muy difci-
les de asumir exclusivamente desde un plano terico, que tambin se presenta. Por
ltimo el Captulo 6, tambin muy aplicado, nos enfrenta, desde la perspectiva del
VHDL, a toda una serie de cuestiones relativas a la organizacin y gestin del diseo
que raramente se comentan en los textos, pero cuyo tratamiento puede, en buena me-
dida, garantizar el xito y la calidad del diseo si es el adecuado, o ser causa de fra-
caso si no se le considera convenientemente.
Estos seis captulos se complementan con sus respectivos apartados de ejerci-
cios, dos apndices y un glosario que ayudan a disponer de un texto ms autocon-
tenido y detallado si se requiere, pero sin cargar demasiado la obra central. As
Prlogo xxiii
mismo, y con el fin de mantener una cierta dinmica viva e interactiva alrededor
de este libro, se han organizado algunas pginas de Internet en la direccin
http://www.cnm.es./IMB/LibroVHDU. donde, adems de la presentacin del libro,
se pueden encontrar ejercicios resueltos, los cdigos 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 irn
actualizando peridicamente.
As pues, vemos que se trata de un texto dirigido tanto a los estudiantes y profe-
sores de cualquier titulacin que incluya materias de diseo electrnico como a los
profesionales del sector. Todos ellos encontrarn 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 mtodos y tcnicas de diseo que de ellos se derivan.
En cuanto a los coautores de los distintos captulos, slo decir que se trata de un
colectivo de expertos en diseo electrnico y en la aplicacin de estos lenguajes. La
mayor parte de ellos desarrollan su actividad en el mbito acadmico y de investiga-
cin, pero todos poseen adems 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 difusin, uso e implantacin tanto a
nivel acadmico como en el contexto industrial.
Los AUTORES
http://www.cnm.es.nMB/LibroVHDU
Captulo 1
,
INTRODUCCION
Llns Ters, Mane) Mor, Eduard Lecha, Fernando Rincn y Joan Vida)
IMB-CNM (CSIC)
Universitat Autnoma de Barcelona
Para avanzar
no es necesario correr,
slo dar el primer paso
y caminar sin miedo ...
El objetivo de esta breve presentacin es mostrar qu son los lengua-

jes de descripcin de hardware (HDL, Hardware Description Lan-
guages), cundo y cmo aparecen dentro de la evolucin del diseo
electrnico y cules son las principales aportaciones de tales lengua-
jes, as como su incidencia en el propio proceso de diseo.
Adems de presentar brevemente la evolucin del desarrollo
electrnico, en este captulo se trata de ubicar el VHDL NHSIC Hard-
ware Description Language; donde VHSIC: Very High Speed Integra-
ted Circuits) en el contexto del diseo electrnico, su origen, evolu-
cin (impacto sobre las tcnicas EDA, Electronic Design Automation)
y mbitos de aplicacin (modelado, simulacin, sntesis y gestin del
diseo). De hecho el resto del libro tratar de hacer una presentacin
ms o menos detallada del VHDL (Captulo 2) y su uso en tales mbi-
tos de aplicacin (Captulos 3, 4, 5 Y 6). El texto se completa con una
serie de ejercicios para cada captulo, la seccin de bibliografa, el
glosario terminolgico y apndices que dan al libro un carcter ms
autocontenido.
1
2 VHDL. Lenguaje estndar de Diseo Electrnico
1.1. EVOLUCiN DEL DISEO ELECTRNICO
El desarrollo electrnico de los ltimos tiempos se ha visto fuertemente dominado y

conducido por la impresionante evolucin de la microelectrnica desde su naci-
miento en 1959-60. Durante los aos setenta, junto con la revolucin que suponen
las memorias RAM y procesadores en forma de chip monoltico, se preparan las
condiciones para el gran salto que el diseo microelectrnico dar en los aos
ochenta [Que88, Ser94].
El desarrollo de nuevas tecnologas y alternativas de fabricacin y diseo de
circuitos integrados, junto con la evolucin de las metodologas y herramientas de
diseo asistido por ordenador, han sido las innovaciones ms importantes de la dca-
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 electrnicos, como en la gran difusin de las
tcnicas, metodologas y herramientas de diseo de circuitos integrados que, junto
con las nuevas alternativas de fabricacin, han ampliado el rango de posibilidades de
los ingenieros de aplicacin, permitindoles disear chips especficos (Application
Specific Integrated Circuits, ASICs) [NB88] para los productos que desarrollan.
Todos estos factores han contribuido directamente a la evolucin de los recur-
sos de clculo (procesadores, estaciones de trabajo, ...) quienes a su vez tienen una
< 10 pg.
Niveles:
- Elctrico
- Bits (disp.prog.FPGA)
- Geomtrico (Cls)
FIGURA 1-1. Pirmide de complejidad y niveles de abstraccin de las distintas fa-

ses del diseo electrnico.
1. Introduccin 3
incidencia decisiva en el desarrollo de nuevas herramientas y entornos integrados de

diseo de sistemas electrnicos. Con el desarrollo y uso de tales herramientas para
crear nuevos componentes se cierra el ciclo del soporte mutuo entre ambas tecnolo-
gas: microelectrnica e informtica.
La Figura 1-1 esquematiza cmo a partir de las especificaciones de un circui-
to' y a fin de poder proceder a su fabricacin, el proceso de diseo de CIs atraviesa
tres etapas o dominios diferentes: funcional o comportamental (algoritmos y fun-
ciones que indican la relacin o comportamiento entrada/salida, E/S, pero no su
implementacin), arquitectural (componentes funcionales interconectados que de-
finen la arquitectura/estructura de la implementacin sin detallar la realizacin fsi-
ca final) y fsico (se detalla una materializacin concreta a nivel elctrico y geom-
trico para una determinada tecnologa). Obsrvese que la complejidad del diseo
en trminos de volumen de informacin a manejar aumenta drsticamente a medi-
da que avanzamos por estas fases, al incrementar la precisin y disminuir el nivel
de abstraccin.
En este contexto, las metodologas yherramientas de CAD han seguido una
evolucin ascendente (bottom-up), para tratar de implementar procesos de diseo
descendentes (top-down).
En el resto de esta seccin sobrevolaremos los aos setenta, ochenta y noventa
mencionando el tipo de tecnologas, circuitos, metodologas, CAD (Computer Aided
Design) y plataformas hardware/software que se han ido desarrollando en cada po-
ca, resumiendo de esta forma la evolucin de la microelectrnica.
1.1.1. Aos setenta
Durante esta dcada hay una fuerte evolucin de los procesos de fabricacin de cir-
cuitos integrados y junto a las tecnologas bipolares surgen las MOS (Metal-Oxide-
Semiconductor). Estas ltimas, bajo la forma de NMOS, mantienen una cierta hege-
mona en el desarrollo de circuitos digitales hasta la primera mitad de los aos
ochenta; mientras que los circuitos analgicos se basaban mayoritariamente en las
tecnologas bipolares [Que88, Ser94].
Ya fuesen circuitos digitales o analgicos, stos se desarrollaban con el objeti-
vo de ser componentes estndar para su posterior uso en el diseo de sistemas elec-
trnicos especficos. Tales circuitos integrados se desarrollaban completamente (di-
seo y fabricacin) dentro de las propias fbricas (joundries) sin que este nivel de
diseo fuese accesible fuera de dicho contexto.
El esfuerzo de diseo se concentraba en los niveles elctrico (establecer carac-
tersticas e interconexiones de los componentes bsicos a nivel de transistor) y to-
pogrfico (dibujar las mscaras, layout, necesarias para la fabricacin de los dispo-
sitivos y sus interconexiones). El proceso de diseo era altamente manual y a la
medida de las posibilidades de cada tecnologa. No exista prcticamente ninguna
herramienta CAD de ayuda al diseo, a excepcin del SPICE [Nag75], simulador
de esquemas elctricos con modelos personalizables para distintas tecnologas y
que ha sobrevivido al paso del tiempo, pues todava 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 recin creada INTEL, que los desarroll en tecnologa PMOS. A
finales de los setenta estos dispositivos ya haban evolucionado hacia memorias de
16 Kbits y procesadores de 16bits (8086), desarrollados ya mediante tecnologas
NMOS. Este tipo de componentes revolucionaron el desarrollo de sistemas elec-
trnicos y plataformas hardware y facilitaron, hacia finales de esta dcada, el naci-
miento de los miniordenadores, que desbancaron a los grandes ordenadores (main-
frames) de los aos setenta [Hay79, Roi86, Ser94].
1.1.2. Aos ochenta

A la vez que los procesos tecnolgicos se hacan ms complejos para poder asumir
mayores densidades de integracin se haba ido identificando el conjunto bsico de
informacin que se necesita conocer a fin de poder realizar diseos para una deter-
minada tecnologa, esto es: parmetros elctricos de los distintos componentes acti-
vos y pasivos para poder definir esquemas elctricos y las reglas de diseo geom-
trico para poder dibujar la topologa del circuito. Estas estrategias para independi-
zar el proceso de diseo del proceso de fabricacin empiezan a hacerse realidad de
la mano de Hon & Sequin [HS80], Conway & Mead [MC80] a finales de los aos
setenta y con ello el diseo de Cls comienza a hacerse accesible fuera del propio
contexto de las fbricas de semiconductores.
En ese momento se constata que hay un desfase enorme entre tecnologa y di-
seo. La considerable complejidad de los chips que se pueden fabricar supone unos
riesgos y costes de diseo desmesurados e imposibles de asumir, debido a una ca-
rencia casi absoluta de metodologas y herramientas de diseo y a la inviabilidad
econmica de aplicar tcnicas de prototipado de circuitos impresos (Printed Circuit
Board, PCB), basadas en el desarrollo de maquetas (breadbording], para el diseo y
depurado de Cls.
A raz de esta situacin se inici una fuerte actividad sobre el desarrollo de me-
todologas y herramientas CAD para el diseo de CIs que ha cambiado drstica-
mente el contexto y los entornos de diseo, no slo a nivel de Cls, sino tambin a
nivel de diseo electrnico global (Cls, ASIC, FPGA, PCB, MCMs ....), cubriendo
los distintos niveles de abstraccin (funcional, arquitectural y fsico) y mantenin-
dose como una de las reas ms activas del sector, tanto en trminos de investiga-
cin, como a nivel de productos industriales.
En cuanto a tecnologas se mantienen las bipolares como las ms utilizadas pa-
ra desarrollos analgicos o mixtos; mientras que en el diseo 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 analgico-digitales.
A nivel de circuitos, obviamente se siguen desarrollando componentes estndar
de mayor complejidad y prestaciones, pero la novedad de esta dcada son los
ASICs (Application Specific Integrated Circuit) [WE85, NB88, HR91], es decir,
7. Introduccin 5
circuitos integrados desarrollados para aplicaciones especficas pudiendo ser dise-

ados por los propios ingenieros de la aplicacin.
Esta ampliacin hacia el diseo microelectrnico se concreta en una serie de
nuevas alternativas de desarrollo que surgen durante esta dcada y que se pueden
agrupar cronolgicamente en las cuatro categoras que se citan a continuacin:
1. Diseo totalmente a medida (jull-custom). El diseador se enfrenta a los ni-

veles elctrico y geomtrico que, como se ve en la Figura 1-1, son los de
mayor complejidad. Total libertad de diseo pero el desarrollo requiere de
todas las etapas del proceso de fabricacin. Los riesgos y los costes son muy
elevados, slo justificables para grandes volmenes 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 bsicos (transistores) prefabricada que se
puede personalizar mediante un conexionado especfico que slo requiere de
las ltimas etapas del proceso tecnolgico. El diseo 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 estndar precaracterizadas (semi-customlstandard-cells). No se tra-
baja contra ninguna estructura fija prefabricada, pero s con bibliotecas de
celdas y mdulos precaracterizados y especficos para cada tecnologa. Bas-
tante libertad de diseo (en funcin de las facilidades de la biblioteca) pero
el desarrollo exige un proceso de fabricacin completo [NB88, Hei88,
HR91).
4. Lgica programable (FPGA, CPLD). Se trata de dispositivos totalmente fa-
bricados y verificados que se pueden personalizar desde el exterior median-
te diversas tcnicas de programacin (RAM, fusibles, etc.). El diseo se ba-
sa en bibliotecas y mecanismos especficos de mapeado de funciones, mien-
tras que su implementacin tan slo requiere de una fase de programacin
del dispositivo que habitualmente realiza el propio diseador en unos pocos
segundos [Tri94].
Desde el punto de vista de diseo, las tres ltimas alternativas son similares y
se centran en el diseo a nivel estructural en base a las respectivas bibliotecas de
celdas y, por lo tanto, sus flujos de diseo se pueden considerar idnticos, tal como
muestra la Figura 1-2, si tenemos en cuenta que cambian los procesos de diseo f-
sico y que el test estructural es una parte muy importante del propio proceso de di-
seo 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 evolucin de los entornos de diseo ha
seguido un proceso ascendente (Bottom-up) que durante los aos ochenta lleg a con-
solidar los niveles fsico y lgico o de puertas. En primer lugar se abord el nivel fsi-
co y se desarrollaron a la par herramientas dirigidas a dos contextos distintos:
El diseo elctrico y geomtrico de celdas y bloques bsicos utilizando tc-
nicas de diseo 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 diseo (esquemticos) Biblioteca
ast de celdas
~E
.- (/)
CQ)
as...!.
oe
IC ::::J Simulaciones (pre/post-diseo fsico):
Q)-
(/)0 Funcional-lgica, temporal, fallos
Ci-Sl
Ubicacin y conexionado (layout)
Verificacin y anlisis
Fabricacin
Produccin
FIGURA 1-2. Flujo genrico de diseo ascendente (bottom-up) de circuitos semi-

custom: sic y FPGAs.
Procesos de ubicacin y conexionado (place&route) de celdas y bloques uti-

lizados dentro del flujo de diseo mostrado en la Figura 1-2 para generar la
topografa de un circuito a partir de su esquema de componentes y sus cone-
xiones (netlist) [PL88].
Asimismo hay procesos de verificacin (elctrica y geomtrica) o comparacin
de esquemas que estn presentes en ambos contextos.
Posteriormente se abord el nivel de puertas (tambin conocido en la poca
como nivel estructural: componentes y conexiones) introduciendo la captura de es-
quemas, la simulacin funcional y de faltas, el anlisis de tiempos, la generacin
de estructuras y vectores de test y los generadores de bloques regulares. La Figu-
t. Introduccin 7
Editor Grfico
Esquemas Mscaras
~~
~~
Extractor de lista de componentes y conexiones (Netlist)
Esquema (E) Topografa (T)
Estmulos
Condiciones
Modelos
Simulador Analgico (SPICE)

Resultados (E) ?
FIGURA 1-3. Entorno de diseo a nivel elctrico y geomtrico para el desarrollo de

celdas o mdulos fullcustom.
ra 1-2 muestra de forma muy genrica este flujo de diseo ascendente, que se ha
aplicado a partir de medianos de los aos ochenta, donde el nivel funcional estaba
muy poco desarrollado y el mayor esfuerzo de diseo se concentraba en el nivel ar-
quitectural y de puertas, mientras que el nivel fsico se consideraba altamente auto-
matizado.
La estructura de las herramientas de CAD tambin vari considerablemente
durante esta dcada pasando de tener que enfrentarse a distintas herramientas con
sus interfaces especficos para cubrir cada paso de flujo de diseo (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
Estndares
Lenguaje de Interface Entorno Informticos
~e g.~ CAD; Electrnicos
c'C :::re.
:2 5l ... _.
CIlCll Mecnicos
):c
al al
0)-0
... P33.
3
_.ceCIl
ale CIl ...
-0._ ::::l III
_0
.'!:
::.:::
.2
~ ~ ~ !ll g:
Leng. de acceso y gestin
BdD
(e) (d)
H: Herramienta, idU: Interfaz de Usuario, BdD: Base de Datos, I/F: Interfaz
FIGURA 1-4. Evolucin de las herramientas y entorno de CAD: (a) Herramientas

dispersas, cada una con su propia interfaz de usuario y su base de datos especfica;
(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: fcil inclu-
sin de nuevas herramientas y mecanismos de gestin de flujo de diseo; (d) Entor-
nos y herramientas trabajando con formatos estndar (CIF, EDIF, VHDL, SDF, ...) faci-
litan el intercambio de informacin y la configuracin de flujos de diseo especficos
con las herramientas de CAD ms adecuadas.
Todos estos avances empujaron y a la vez se apoyaron en la propia evolucin

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 dcada en
entornos de red con una todava tmida presencia de los ordenadores personales
(personal computers, PC).
1. Introduccin 9
1.1.3. Aos noventa
A finales de los ochenta se consolidan los niveles estructural y fsico, 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 mtodos y herra-
mientas para abordar el diseo a nivel funcional o comportamental, cuya implanta-
cin definitiva se est produciendo durante esta dcada de los noventa.
En cuanto a tecnologas de los aos noventa, la CMOS sigue siendo la ms 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 tecnologas del tipo AsGa y simi-
lares se reparten el 5 por 100 restante.
Por otra parte, durante esta dcada se estn desarrollando nuevas tecnologas
de encapsulado cuyo mximo exponente son los mdulos 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 (cermico, laminado o silicio), en los que previamente se habrn
implementado las conexiones entre los distintos chips. Ello permite aumentar las
prestaciones (velocidad, consumo) y reducir el tamao de los sistemas electrnicos.
En general los MCM podramos verlos como la evolucin natural de los circuitos
hbridos pero con unas posibilidades y una complejidad potencial mucho mayor.
Otras tecnologas que estn en fase de desarrollo pre-industrial son todas las re-
lacionadas con los microsistemas, donde junto a la microelectrnica se integrarn
sensores y actuadores de distintos tipos y funciones (qumicos, mecnicos, etc.), ba-
sados en los mismos tipos de procesos de miniaturizacin que la tecnologa micro-
electrnica [Ris94, Sze94].
En trminos de circuitos se sigue con la misma tnica 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 diseo analgico y mixto (analgi-
co/digital) [GAS90, LS94]; basados estos ltimos en las nuevas tecnologas BI-
CMOS. Los avances tecnolgicos tambin permiten diseos 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 slo producciones elevadas o requisitos muy espec-
ficos (velocidad, rea, consumo, confidencialidad) hacen necesarios los ASIC-custom.
Con el avance que estn siguiendo las tecnologas submicrnicas (se estn 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 ms el cuello de botella del desarrollo microelectrnico va a
estar en el diseo ms que en la tecnologa. 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 mtodos y herramien-
tas para abordar diseos de tal complejidad. Los diseos se basan en macro bloques
funcionales (CPU, DSP, microcontrolador, etc.) desarrollados a nivel soft (cdigo
VHDL sintetizable) u optimizados a nivel hard (layout o topografa especfica), cu-

yo grado de desarrollo y madurez dista todava del ideal pero en el que se est invir-
tiendo gran esfuerzo.
En cuanto a metodologas de diseo, los aos noventa se han caracterizado por
una implantacin progresiva, en fase de consolidacin, de los lenguajes de descrip-
cin de hardware (Verilog y VHDL) que, junto con las herramientas de simulacin
y sntesis, promueven el uso de las llamadas metodologas de diseo descendente
(top-down). Se trata de concentrar el esfuerzo en la concepcin a nivel funcional-ar-
quitectural, facilitando la evaluacin de soluciones alternativas antes de abordar el
diseo detallado y la implementacin fsica, dando lugar as al tambin llamado di-
seo de alto nivel. El VHDL, aunque podamos o debamos verlo slo como una he-
rramienta de base, ha sido el motor que ha estimulado esta evolucin que pretende
cubrir el diseo electrnico desde el dominio funcional o comportamental, tal como
se muestra en el proyecto PRENDA [CP96].
La Figura 1-5 esquematiza un flujo de diseo centrado en el dominio funcio-
nal y basado en los lenguajes de descripcin de hardware y los correspondientes
procesos de simulacin mixta-multinivel (funcional, RT, puertas) y sntesis (com-
portamental, RT, lgica). Actualmente la sntesis comportamental, encargada de
convertir una descripcin funcional en otra ms detallada a nivel de transferencia
de registros (RT), est en fase de desarrollo preindustrial. Por su parte, la sntesis a
nivel de transferencia de registros (RT), as como a nivel lgico y fsico, es am-
pliamente conocida y utilizada [(MLD92]. En el apartado 1.3.2 y en la Figura 1-10
se analizan con un poco ms de detalle estos flujos de diseo descendentes, que
tambin se abordan en el Captulo 6.
Esta misma Figura 1-5 trata de reflejar una orientacin descendente (top-down)
y la globalizacin del flujo de diseo electrnico actual, donde la dependencia de la
implementacin final es prcticamente nula a nivel funcional y se va concretando
en las sucesivas fases de diseo, hasta llegar a la realizacin fsica de los distintos
componentes (ASICs, FPGAs) y del sistema electrnico final MCM, PCB, SOCo
Esta globalizacin del diseo electrnico ha supuesto una evolucin coordinada
de las distintas tcnicas de diseo asistido por ordenador (CAD) en lo que se ha lla-
mado automatizacin del diseo electrnico (Electronic Design Automation, EDA).
Estas tcnicas, pensadas para facilitar la ingenieria concurrente', estn en pleno desa-
rrollo con el objetivo de poder automatizar en los prximos aos el diseo de siste-
mas complejos que incluyan hardware y software (Hw/Sw Co-Design) [KAJW95 ,
BLR97]. A partir de un mdulo que ayudar a realizar la particin del sistema a de-
sarrollar en hardware y software, habr flujos EDA y CASE (Computer Aided Soft-
ware Engineering) que permitirn el desarrollo concurrente de ambas partes.
Por su parte, el incremento de los diseos analgicos y mixtos ha forzado el de-
sarrollo de entornos de simulacin mixtos analgico-digitales (HDL, puertas y dis-
I El objetivo de la ingeniera 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-
macin muy giles soportados por entornos' de CAE (Computer Aided Engineering) que interrelacio-
nen las reas de desarrollo (hardware-software) con el marketing y la produccin.
1. Introduccin 11
ESpeCifaCiOnes
Descripciones
mixtas multi-nivel l"", ,
~s
ra e
e al ~ " , Niveles:
.Q E
u ra
C:t::
~g_
Simulacin
Sistemas electrnicos
(mixta multi-nivel)
~
" 1 "
- - - : ;,
- Comportamental
- Arquitectural I RT
.~
Zu
,,
" - Lgico I puertas
~ ,
Sntesis a nivel de: ,,
- Comportamiento ~'
- RT-Lgico
- Mapeo tecnolgico
~8
ce .
, ,-
-e,;
:::1 Ul
ra FPLDs MCMs
<.
alt::
:t::<D
0":::1
... o.
,
_o
.~.~
z:Q
Sistema
electrnico ( peS)
J
!
FIGURA 1-5. Esquema de los nuevos flujos de diseo descendente basados en el
modelado, simulacin y sntesis con HDLs a nivel funcional o comporta mental.
positivos), as como el desarrollo de nuevas estrategias y tcnicas de test como las

basadas en el consumo corriente (Iddq) [Roc95]. Tambin desde el VHDL se est
abordando el diseo analgico y mixto mediante el desarrollo de una nueva exten-
sin del lenguaje, el VHDL-AMS (VHDL-Analog-Mixed-Signal) [VAMS96], cuyas
primeras versiones ya empiezan a estar disponibles a nivel de descripcin y simula-
cin. As mismo, y tambin relacionado principalmente con los diseos mixtos que
van creciendo en complejidad y prestaciones, son necesarios y estn surgiendo he-
rramientas avanzadas para el anlisis de integridad de las seales (efecto de lnea de
transmisin, acoplas, EMI).
Por su parte, las tcnicas actuales de sntesis RT de HDLs, simulacin de netlist
y posterior ubicacin y conexionado de celdas se basan en los principios de la lti-
ma dcada donde el retardo de una conexin poda incluso despreciarse frente al re-
tardo de una puerta (en tecnologas 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 submicrnicas 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 sntesis que tengan ms en cuenta el diseo fsico de los CIs a
travs de procesos de planificacin topogrfica (Floorplaning) guiados por presta-
ciones (tiempo, consumo, rea) que permitan establecer criterios de diseo conver-
gentes para encontrar una solucin 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 integracin de nuevas herramientas, as como facilidades (De-
sign jlow management) para la definicin, gestin y control del flujo de diseo a se-
guir por un determinado centro o para un proyecto concreto (Figura 1-4.c). Ms re-
cientemente la implantacin y uso de lenguajes y formatos estndar (electrnicos e
informticos) est facilitando tanto el intercambio de informacin entre entornos (Fi-
gura 1-4.d) en las distintas etapas del diseo (modelos HDL, listas de componentes y
conexiones, vectores de test, retardos, etc.), como una mayor diversificacin de he-
rramientas al poder configurarse cualquier flujo de diseo con las herramientas ms
adecuadas, siempre que stas se ajusten a los respectivos estndares (iniciativa CFf).
Para finalizar con esta dcada hablaremos de las plataformas harware-software
sobre las que se ha apoyado el desarrollo electrnico. Las estaciones de trabajo or-
ganizadas en forma de red de recursos distribuidos (cmputo, almacenamiento y ac~
ceso) se han consolidado durante la primera mitad de los aos noventa. A su vez los
PCs, tambin formando parte de esa misma red informtica, se van abriendo cami-
no y presionando a las estaciones de trabajo, ya sea como puntos de acceso al entor-
no informtico (donde adems compiten con los terminales-Xwindows) o como
puntos de proceso y almacenamiento local. Todo ello es posible gracias, una vez
ms, a las prestaciones de los nuevos procesadores (Pentium, Power-PC, etc.) y al
uso de los estndares informticos (windows, NT, X, redes, etc.), desarrollados con
la generacin anterior de procesadores, software y entornos de diseo. Si a todo ello
le aadimos 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 autntica explosin de medios no siempre fcil de seguir y asumir.
1.2. LOS LENGUAJES DE DESCRIPCiN DE HARDWARE

Una vez revisada la evolucin histrica del desarrollo electrnico y ubicados en el
tiempo los HDLs, procederemos ahora a presentar sus caractersticas genricas, 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 creacin de un estndar para el desarrollo de

entornos de diseo, de tal forma que se facilite la personalizacin de distintos flujos de diseo con
aquellas herramientas que respeten las normas y mecanismos establecidos por la OFI.
1. Introduccin 13
Para ello nos referiremos en este captulo a los dos HDLs ms conocidos y exten-
didos, el Verilog [OVT9l, SS190, TM9l, IEEE95] y el VHDL [IEEE88, Nav93,
IEEE94, Ash96], con alguna referencia al estandar japons UDLII [YI89, CU93].
Tras una pequea analoga con los lenguajes de desarrollo de software, se hace
una breve resea histrica del Verilog y del VHDL. A continuacin se presentan, en
genrico, sus prestaciones para abordar distintos niveles de abstraccin y estilos
descriptivos, e inmediatamente se revisan las principales aportaciones de los HDLs
al proceso de diseo [Mer93, Nov95, TML96, DC97].
1.2.1. Lenguajes de descripcin 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 diseo electrnico.
Algunos de estos lenguajes eran notaciones explcitas 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, adems del grado de estandarizacin que supusieron, adoptaron con-
ceptos de la ingeniera del software para la descripcin y modelado del hardware.
Desde el punto de vista de la sintaxis, los HDLs son muy similares a los lenguajes de
programacin 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 sintcti-
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-
macin, tambin encierran ciertos peligros, pues en aquellos casos en que el modelo
en HDL se realiza para su posterior sntesis e implementacin, el diseador debe
pensar y describir en trminos de hardware aunque la sintaxis sea de software (sobre
este punto se incide en el Captulo 4 al hablar de sntesis y se presentan ejemplos
prcticos en los Captulos 5 y 6). De hecho, utilizar estrategias de software ser
aconsejable cuando el modelo a desarrollar sea exclusivamente para simulacin,
pues en ese caso se tratara de optimizar el modelo de cara a la ejecucin de las dis-
tintas etapas y procesos de simulacin que se detallan en el Captulo 3 de este texto.
Los lenguajes de descripcin de hardware (HDL) son lenguajes de alto nivel,
similares a los de programacin (C, PASCAL, ADA, ... ), con una sintaxis y semn-
tica definidas para facilitar el modelado y descripcin de circuitos electrnicos, des-
de las celdas de base de un ASIC hasta sistemas completos, pudindose realizar es-
tas descripciones a distintos niveles de abstraccin, precisin 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
simulacin, aunque tambin se utilizan para describir el diseo de un circuito para
su implementacin a travs de etapas de sntesis validadas va simulacin (Figura 1-6).
Prog.lDescr. independiente
del H/wque lo ejecuta (HLL)
o lo implementa (HOL)
HLL
Programacin
en Leng.
Alto Nivel
HOL
Descripcin
de alto nivel
de abstraccin
(p.e. RTL)
Prog.lDescr. dependiente
del H/wque lo ejecuta (ML)
o lo implementa (HOL)
Programas
a nivel de
Leng. Mquina
Descripcin
de bajo nivel
de abstraccin
(p.e. puertas y cnx.)
(a) Desarrollo de Software (b) Desarrollo de Hardware
FIGURA 1-6. Desarrollo de software versus hardware: (a) niveles de abstraccin y

lenguajes de alto nivel (HLL, HDL) y (b) esquema bsico del diseo descendente con
HDL: La sntesis pasa una descripcin de un nivel de abstraccin a otro inferior;
mientras que la simulacin permite la verificacin funcional a cada nivel de abstrac-
cin y la validacin 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 abstraccin e independientes de la implementacin tecnolgica final
(Figura 1-6.a). A partir de tales descripciones, los procesos de diseo descendente
(top-down) aplican procedimientos progresivos de sntesis, dando lugar a descrip-
ciones ms detalladas de la implementacin hasta alcanzar una descripcin fsica
concreta totalmente dependiente de la tecnologa seleccionada. La validacin de las
distintas descripciones se realiza mediante los correspondientes procesos de simula-
cin y anlisis y las iteraciones de correccin resultantes (Figura 1-6.b).
1.2.2. Resea histrica de los HDLs

Si bien los HDLs, se han integrado recientemente al proceso de diseo (desde el
inicio de los noventa), este tipo de lenguajes se ha venido desarrollando durante los
ltimos decenios, siendo los aos setenta la poca de mxima proliferacin (IDL-
IBM, TI-HDL, ZEUS-GE, AHPL, DDL, CDL, ISPS, ...). Sin embargo, estos len-
guajes nunca alcanzaron el nivel de difusin y consolidacin 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
pblico, carecan del soporte y mantenimiento adecuados [Har87].
1. Introduccin 15
Comporta mental
o funcional
Abstractos
Arquitectural
RT
ompuestos
Estilos
Lgico-
Bit descriptivos
puertas
Estructu ral Flujo de datos Algortmico
Figura 1-7. Niveles de abstraccin/precisin y estilos de modelado en VHDL.
Durante los aos ochenta, tras detectarse la necesidad de un lenguaje para dar
soporte a las distintas etapas y niveles de abstraccin del proceso de diseo, se de-
sarrollan y consolidan dos de ellos: Verilog y VHDL. Cabe mencionar que existe el
UDUI, que nace como estndar japons promovido y desarrollado por una asocia-
cin de empresas niponas y cuya implantacin es ms que discutible incluso en el
propio Japn.
El VHDL aparece como un proyecto del Departamento de Defensa de EEUU
(1982), con el fin de disponer de una herramienta estndar e independiente para la
especificacin (modelado y/o descripcin) y documentacin de los sistemas elec-
trnicos 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 estndar (l." versin en 1987 y
la 2: en 1994) [IEEE88, IEEE94].
El Verilog nace como un lenguaje de modelado ligado a un entorno de simula-
cin de la firma Gateway, pasando posteriormente a ser el simulador digital de Ca-
denee Design Systems Ine., llegando a convertirse en un estndar "de facto" a nivel
industrial. Al aparecer el VHDL como estndar IEEE, Verilog se encontr con un
fuerte competidor, y en 1990 Cadence decide ofrecerlo como lenguaje de dominio
pblico [OVI91] e inicia las gestiones para su estandarizacin formal, que se logra
en 1995 [IEEE95].
El desarrollo, difusin y estandarizacin de los lenguajes Verilog y VHDL,

aunque slo sean herramientas bsicas para la descripcin de circuitos y sistemas
electrnicos fue, y sigue siendo, un hecho determinante en el desarrollo de las nue-
vas metodologas y herramientas de diseo electrnico.
1.2.3. Modelado con HDLs: niveles de abstraccin y

estilos descriptivos
Una de las caractersticas ms importantes de estos lenguajes es su capacidad para
abordar descripciones a distintos niveles de abstraccin (funcional o comportamen-
tal, arquitectural o transferencia de registros, lgico o de puertas) y estilos de mode-
lado (algortmico, flujo de datos, estructural).
Los niveles de abstraccin hacen referencia al grado de detalle en que se en-
cuentra una determinada descripcin HDL respecto ala implementacin fsica de la
misma. Puesto que el nivel ms bajo que trataremos directamente con los HDL se-
rn listas de componentes y conexiones a nivel de puertas podemos considerar que
desde los HDL no abordamos el nivel fsico mostrado en la Figura 1-1, que queda-
ra como el nivel ms bajo de abstraccin (donde se fijan todos los detalles para la
implementacin real del circuito), por encima del cual se sita el nivel lgico o de
puertas. As pues, desde la perspectiva de simulacin y sntesis con HDLs, los nive-
les de abstraccin pueden quedar reajustados a los tres siguientes:
Funcional o comportamental, donde se indica el comportamiento del circuito
o sistema como una relacin funcional entre las entradas y salidas, pero sin
hacer ninguna referencia a su implementacin.
Arquitectural o de trasferencia de registros (RT). A este nivel se desarrolla
una particin en bloques funcionales y se planifican en el tiempo (ciclos de
reloj) las acciones a realizar. Todava no se conocen los detalles de la realiza-
cin final de cada bloque.
Lgico o de puertas. En este caso los componentes del circuito estn expre-
sados en trminos de ecuaciones lgicas o puertas y elementos de una biblio-
teca, pudiendo ser sta genrica (independientemente de la tecnologa) o es-
pecfica de una tecnologa.
Como vemos, estos niveles de abstraccin se proponen como una taxonoma
simplificada para poder clasificar los modelos HDL segn el grado de detalle y pre-
cisin de sus descripciones. Hay dos factores que caracterizan esta precisin:
1. La precisin en la temporizacin o relacin temporal en el funcionamien-

to del circuito. A nivel de puertas se conocen los retrasos de los distintos
componentes bsicos y se pueden estimar o conocer (retroanotacin des-
pus de la fase de ubicacin y conexionado fsico) los retardos introduci-
dos por las conexiones. A nivel arquitectural o RT tendremos acciones
agrupadas en distintos estados que se realizarn 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 slo las relaciones causa-
1. Introduccin 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 ms abstractos definidos por el
propio usuario hasta el ms bsico, el bit, para una seal digital, pasando
por los compuestos que agrupan bloques de bits con un significado especfi-
co y se representan como enteros con o sin signo.
Adems de estos factores determinantes del nivel de abstraccin que se reflejan

en la Figura 1-7, otro aspecto o criterio de caracterizacin de los modelos HDL es
el estilo de descripcin que, de forma simplificada, podemos distinguir entre los
tres siguientes:
Algortmico: hace referencia a descripciones similares a los programas soft-

ware, que deben reflejar la funcionalidad del mdulo, componente o circuito,
en forma de uno o ms 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 informacin y las dependencias entre datos y operaciones.
Estructural: en este estilo se reflejan directamente componentes por referen-
cia y conexiones entre ellos a travs de sus puertos de entrada/salida.
Estos estilos descriptivos forman el tercer eje de la Figura 1-7, que es una sim-
plificacin del cubo de diseo 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 sntesis (comportamental,
RT, lgico-puertas). Como se puede intuir, normalmente hay una cierta correlacin
entre niveles de abstraccin y estilos descriptivos. As pues, las descripciones algo-
rtmicas se usan ms a nivel comportamental o funcional, el flujo de datos se rela-
ciona ms 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 aadidos 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 abstraccin para las distintas partes de
un diseo. Una cierta descripcin estructural puede tener componentes desarrolla-
dos a nivel de puertas, otros a nivel RT en forma de flujo de datos y algunos todava
en forma de algoritmos a nivel funcional (Figura 1-5). Esta es una situacin normal,
que va evolucionando a lo largo de todo el proceso de diseo hasta que, tras los co-
rrespondientes procesos de sntesis manual o automtica, todos los componentes del
circuito a implementar estn detallados mediante una descripcin estructural a nivel
de puertas. Mientras tanto, aquellos componentes que slo formaban parte del en-
torno de simulacin 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 + XCin ~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 ~ :: ~ ~ gn; ~ 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 abstraccin y estilos de descripcin: (a) Esquema jerrquico de un su:
mador total de 2 bits (captura de esquemas clsica). (b) Descripcin de VHDL del inter-
faz E/S del sumador total (ST). En VHDL para cada mdulo se define una entity donde
se detallan las E/S, mientras que las distintas arquitecturas o descripciones alternati-
vas se detallan en distintos mdulos architecture, que comparten una misma entity.
En el caso del Verilog, cada mdulo define sus E/S. (e) Modelado del ST en HDL a nivel
funcional, en trminos de ecuaciones booleanas e incluyendo los retardos previstos.
(d) Una descripcin estructural (componentes y conexiones) del mismo STo (e) Defini-
cin funcional de los componentes utilizados en (d). Obsrvese que en Verilog el com-
ponente OR, al ser una primitiva del propio lenguaje, no necesita ser definido.
1. Introduccin 19
1.2.4. Aportaciones de los HDLs al proceso de diseo
Tanto el Verilog como el VHDL nacen con una sintaxis (formalizada mediante una
gramtica) y una semntica (no formal, matemticamente hablando) definidas y di-
rigidas hacia el modelado para la simulacin de hardware. Sin embargo, rpidamen-
te se abord su uso como soporte para todas las fases del proceso de diseo, y muy
especialmente para las etapas de sntesis. Pasemos, pues, a comentar las ventajas
ms 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 diseo (mo-
delado, simulacin, sntesis, verificacin) como a las de comunicacin e in-
tercambio de modelos entre los distintos equipos de trabajo y, obviamente, a
las de documentacin y mantenimiento de los diseos.
Son lenguajes de disponibilidad pblica, no sometidos a ninguna firma ni pa-
tente (especialmente el VHDL). Estn definidos, documentados y manteni-
dos por el IEEE, quien garantiza su estabilidad y su soporte.
Soportan descripciones con mltiples niveles de abstraccin, pudindose
mezclar desde mdulos descritos a nivel funcional hasta mdulos a nivel de
puertas. Con el mismo lenguaje se describe el circuito y el entorno de verifi-
cacin (banco de pruebas) para su simulacin/validacin.
La utilizacin de un lenguaje nico a lo largo de todo el proceso de diseo
simplifica la gestin del mismo (reduccin de herramientas y formatos) y la
descripcin/simulacin mixta multinivel facilita el diseo independiente de.
los diferentes componentes o mdulos y, por lo tanto, la distribucin de ta-
reas entre distintos equipos coordinados bajo un nico entorno de simula-
cin/ verificacin.
Proporcionan independencia de metodologa, de herramientas y de tecnolo-
ga. A pesar que el VHDL es uno de los soportes naturales de las metodolo-
gas descendentes, no est sometido a ningn proceso ni mecanismo estricto
de diseo, pudindose amoldar a cualquier metodologa donde el modelado
de hardware pueda tener sentido (especificacin, documentacin, simula-
cin, sntesis y/o verificacin).
En el caso de las herramientas CAD, los HDL son lenguajes estndar que de-
finen una sintaxis y una semntica de modelado para simulacin. As pues,
cualquier herramienta que cumpla con el estndar ha de aceptar y ejecutar
(simular) de la misma forma cualquier modelo. Esta portabilidad no es tan
aplicable a la sntesis ni a la verificacin formal, ya que la semntica del
VHDL y del Verilog en estas reas no est definida desde el IEEE, y son los
proveedores de CAD quienes hacen su propia interpretacin, dando lugar a
pequeas divergencias, en general fciles de salvar, pero que impiden hablar
de un estndar desde el punto de vista de la sntesis. En cambio, el UDUI s
tiene una semntica definida para la sntesis hardware.
Los HDL, tanto por su definicin y diseo como por los niveles de abstrac-
cin donde habitualmente se usan, son, o pueden ser, totalmente indepen-
dientes de la tecnologa final de implementacin de los circuitos. La descrip-
cin VHDL de un circuito puede ser totalmente indiferente a la tecnologa de

fabricacin, pero si se quiere tambin puede incluir informacin especfica
de la implementacin 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 diseo con ROL es ms
o menos fcil de resintetizar sobre tecnologas distintas), centros de diseo
(todos pueden aceptar especificaciones en ROL), proveedores de herramien-
tas CAD (los ROL son muchas veces el ncleo de la herramienta y en cual-
quier caso siempre son una va de acceso) y distribuidores de componentes
(los modelos de simulacin en ROL sern compatibles).
La reutilizacin del cdigo ROL desarrollado en los proyectos anteriores es
un hecho posible gracias a algunas de las caractersticas enunciadas anterior-
mente como ser lenguajes estndar, estables y su independencia metodolgi-
ca, tecnolgica y del CAD. Una descripcin VHDL de un diseo, inicialmen-
te desarrollado para una determinada tecnologa (CMOS, BlCMOS, SOl,
etc.) e implementacin (ASIC, FPGA, PCB, etc.), puede fcilmente ser reuti-
lizado en diseos o materializaciones posteriores donde la tecnologa, la al-
ternativa de implementacin y/o el CAD pueden ser distintas. Esto facilita la
evolucin del producto, ya sea mejorando o incrementando sus caractersti-
cas funcionales (modificaciones del modelo ROL y resntesis), o bien va re-
novacin tecnolgica haciendo su reimplementacin (sntesis del modelo
ROL) sobre nuevas tecnologas. As mismo, en el caso del VHDL el propio
lenguaje dispone de mecanismos bsicos como los genricos (generics) y las
configuraciones (configurations), que facilitan la adecuacin y reutilizacin
de los mdulos VHDL a las distintas condiciones de contexto de los circuitos
en los que se pueden utilizar estos mdulos.
De todas formas, estas posibilidades de reutilizacin del cdigo ROL sern
ms 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 bsica para acumular el
know-how resultante de los distintos proyectos de una forma estructurada que facili-
te su uso y actualizacin (ver Apndice ll). Este sera el coste aadido para poder
beneficiarse de las ventajas y en especial de la reutilizacin del cdigo HDL. Mu-
chas de estas aportaciones de los ROL se detallan y ejemplifican para el caso del
VROL en los Captulos 5 y 6 de este mismo libro.
Como vemos, estos lenguajes pueden aportar ventajas importantes pero no de-
bemos ignorar que tambin estn sujetos a algunas limitaciones:
Al ser lenguajes definidos por consenso en el seno de una comisin (espe-
cialmente el VHDL) tienden a ser complejos para contemplar la diversidad
de opiniones. As mismo la evolucin del lenguaje mediante revisiones va
comisin es lenta (5-6 aos para el VHDL) y con importantes cambios en ca-
da nueva versin.
La falta de una semntica formal para sntesis dificulta la potabilidad de los
diseos entre distintos entornos de sntesis (no todas las herramientas inter-
pretan de la misma forma las mismas construcciones del lenguaje) e imposi-
bilita abordar claramente la verificacin formal.
7. Introduccin 21
El VHDL, por sus caractersticas sintctico-semnticas, est mejor dotado

para las descripciones a nivel funcional/algortmico, mientras que sus presta-
ciones se ven ms limitadas al trabajar a nivel de puertas. Por su parte el Ve-
ri/og, al basarse en un conjunto de primitivas funcionales bsicas (puertas),
tiene buenas prestaciones a nivel estructural/puertas pero claras limitaciones
en los niveles superiores.
La enorme flexibilidad del VHDL est dificultando la implantacin de meca-
nismos estndar para facilitar el intercambio de mdulos, reflejar los retar-
dos, la temporizacin (timng) y la retroanotacin (backannotation) en el
modelado de bibliotecas de celdas o para el desarrollo de entornos de verifi-
cacin, 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 Captulos 3 y 4 de este libro presentan los detalles y caractersticas espec-

ficas de la simulacin y sntesis basadas en VHDL.
Actualmente el Verilog y el VHDL estn compitiendo y a la vez compartiendo
algunos de sus mecanismos y estrategias para asegurar su mutua evolucin y su ca-
da vez ms cercana compatibilidad y fcil interoperatividad. En cualquier caso es-
tos lenguajes slo son herramientas de base a las que se debe arropar con metodo-
logas y CAD para poder aprovechar sus ventajas potenciales y superar sus limita-
ciones actuales.
1.3. METODOLOGAS Y FLUJOS DE DISEO
Metodologas, flujos y herramientas CAD de diseo electrnico son conceptos muy

interrelacionados y no siempre fciles de distinguir. La metodologa es un concepto
ms abstracto que hace referencia a procesos de diseo genricos que relacionan
entre s los distintos niveles de complejidad y abstraccin (funcional-comportamen-
tal, arquitectural-RT, lgico-puertas y fsico, segn se detalla en el apartado 1.2.3)
por los que atraviesa el diseo de un circuito o sistema electrnico.
Por su parte los flujos de diseo son una personalizacin concreta de una cierta
metodologa, para un tipo de circuitos o rea de aplicacin especfico, y contando
con el soporte de unas determinadas herramientas de CAD. Distintos flujos de dise-
o pueden responder a una misma metodologa y un mismo flujo se puede implan-
tar con distintas herramientas de CAD.
Los objetivos fundamentales que persigue toda metodologa de diseo se pue-
den resumir en:
3 VITAL (VHDL lnitiative Towards ASIC Libraries modeling). Esta iniciativa promueve la estan-
darizacin de los mecanismos para representar y gestionar los parmetros temporales (retardos de puer-
ta y retroanotacin de retardos del conexionado) en el modelado VHDL de las bibliotecas de celdas pa-
ra el diseo de ASICs.
4 OMF (Open Modeling Forum). Promueve la estandarizacin de una interfaz para la simulacin
y otras herramientas relacionadas con el modelado VHDL, Verilog y C.

Establecer procesos de diseo 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 tecnolgicas disponibles para el desarrollo de un circuito.
Estos dos objetivos se desdoblan en mltiples requisitos y caractersticas para
los distintos flujos y herramientas de diseo, que no entraremos a analizar. Sin em-
bargo, para alcanzar estos objetivos, en cada etapa de diseo o nivel de representa-
cin de un circuito se deben aplicar los principios de:
Abstraccin: fijar y definir el nivel de abstraccin de cada etapa permite, tan-
to al diseador de circuitos como al desarrollador de CAD, ignorar en cada
momento detalles ajenos al nivel en el que se est trabajando.
Jerarqua y estructuracin: permite reducir la complejidad del diseo me-
diante la descomposicin jerrquica del mismo hasta alcanzar bloques o m-
dulos del nivel de abstraccin correspondiente.
En general, establecer una metodologa o flujo de diseo significa definir las
distintas etapas que recorrern los diferentes niveles de abstraccin y fijar cmo
evolucionaremos a travs de ellas utilizando procesos manuales o automticos de:
Sntesis: para pasar las descripciones de un determinado nivel de abstraccin
a otras de nivel inferior con un mayor grado de detalle (p. ej., de una descrip-
cin RT a puertas, o de puertas a mscaras).
Anlisis: extraer informacin de una descripcin (p. ej., retardos del cone-
xionado) para facilitar una verificacin de prestaciones o inyectarla a una
descripcin de nivel superior para validar restricciones.
Verificacin/simulacin: para validar tanto la correccin de las descripciones
de cada etapa como la equivalencia entre las distintas etapas y niveles de
abstraccin.
Estos tres tipos de procesos se concretan en distintas herramientas actuando a
diferentes niveles de abstraccin.
Siguiendo estos objetivos, principios y procesos podemos decir que las meto-
dologas siempre han hecho propuestas de refinamiento progresivo (proceso des-
cendente o top-down) desde la idea a la implementacin, pasando por distintas eta-
pas o niveles de abstraccin. Sin embargo, los flujos reales de diseo se han visto
mucho ms sujetos al estado de las herramientas de diseo que ha seguido una evo-
lucin ascendente (bottom-up) para ir cubriendo progresivamente las etapas de
mayor nivel de complejidad desde el nivel fsico 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 aos
ochenta, la metodologa y los flujos de diseo implantados en esta poca tenan una
fuerte componente de diseo basada en una composicin jerrquica ascendente
(bottom-up) de mdulos y bloques hasta alcanzar el diseo completo del circuito.
Este mtodo tena claras limitaciones en trminos de eficiencia (slo hacia el final
del diseo, cuando ya se haban tomado todas las decisiones arquitecturales e inclu-
1. Introduccin 23
so tecnolgicas, se poda proceder a una validacin-simulacin 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 descripcin, simula-
cin y sntesis se estn superando muchas de estas limitaciones y se facilita la im-
plantacin de flujos de diseo descendentes (top-down) que permiten abordar dise-
os ms complejos con mayores garantas de xito.
Sin embargo, la evolucin de las tecnologas de semiconductores sigue yendo
por delante de las tcnicas de diseo. Ya empiezan a ser factibles chips de tal com-
plejidad que permitan la integracin de sistemas completos (Systems on Chip, SoC),
para lo cual sern necesarias metodologas mixtas descendentes-ascendentes donde
ciertas partes del diseo, las ms operativas, se basen en la composicin ascendente
de mdulos preexistentes, mientras que para disear las funciones de controlo par-
tes ms especficas se seguirn procesos descendentes.
En los prximos apartados tratamos de resumir las ideas bsicas sobre estas
metodologas y flujos de diseo.
1.3.1. Flujo de diseo ascendente (bottom-up)

En el proceso de diseo de ASICs implantado a mediados de los ochenta se podan
distinguir dos fases distintas:
1. Una descomposicin jerrquica descendente (aproximacin top-down sobre
papel y no simulable) del circuito a disear en bloques y subbloques hasta
llegar al conjunto de mdulos que, aun estando descritos a un nivel funcio-
nal, su diseo lgico fuera abordable desde la tecnologa escogida y segn
su biblioteca de celdas especfica.
2. En la segunda fase se realiza una composicin jerrquica ascendente (apro-
ximacin bottom-up) de celdas, mdulos y bloques hasta conformar la es-
tructura jerrquica 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 diseadores y, aun-
que las decisiones que se tomaban eran crticas (particin, arquitecturas, bloques) y
con importantes consecuencias para el posterior desarrollo y prestaciones del circui-
to, no se contaba con ningn soporte de herramientas CAD y muy poco apoyo me-
todolgico. Ante estas carencias no se le poda dedicar a esta fase ni tiempo ni el
esfuerzo adecuados y se abordaba rpidamente la segunda fase de composicin je-
rrquica ascendente que, a pesar de contar con el soporte de flujos y herramientas
de diseo, era muy laboriosa y concentraba la mayor parte de los esfuerzos de dise-
o, dando as el nombre de ascendente (bottom-up) a la metodologa y flujos de di-
seo utilizados.
La Figura 1-2 muestra un esquema genrico de estos flujos ascendentes, donde
se encadenan etapas de captura de esquemas, para detallar el esquema lgico de un
mdulo en base a los previamente descritos y/a la biblioteca de celdas especfica de
la tecnologa seleccionada, y simulacin (lgica, temporal, fallos) para validar cada
nuevo mdulo. Este proceso captura-simulacin se repeta hasta completar toda la
Conjunto de bloques Conjunto de bloques

y mdulos bsicos f---_I y mdulos bsicos
(dese. funcional) (dese, estructural)
Flujo de diseo manual Flujo de diseo asistido por ordenador
FIGURA '-9. Esquema de las fases bsicas del diseo ascendente (bottom-up}.
estructura jerrquica del circuito (esta fase tambin se conoca como el "front-end"
del diseo). Despus, con los esquemticos libres de errores y cumpliendo las pres-
taciones requeridas, se abordaba la fase de diseo fsico (tambin llamada "back-
end"), que inclua e incluye bsicamente procesos de ubicacin y conexionado se-
guidos de verificacin a nivel de mscaras (topografa o layout de un circuito), A
continuacin se extraen de la topografa los retardos reales derivados del conexio-
nado fsico final y se retroanotan en los esquemticos para poder proceder a repetir
las simulaciones (post-layout) y comparar que se siguen manteniendo las prestacio-
nes funcionales y temporales.
Adems de todo ello, durante el diseo a nivel de puertas debe tambin tenerse
en cuenta la testabilidad y el test del circuito [Tsu87, ABF90). Tema este muy impor-
tante que incide en el propio proceso de diseo, al tener que desarrollar un conjunto
de vectores de test que cubran el mayor nmero (>96 %) de faltas posibles del Cl,
pues sern los que se utilicen en la fase de test estructural post-fabricacin para deter-
minar qu circuitos se dan por vlidos y cules 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 intil a efectos prcticos. Ello ha dado lugar a las llamadas tcni-
cas de diseo para test (Design for testability, DFT) que, adems de la dificultad aa-
dida, siempre suponen un incremento de la complejidad final del circuito al tener que
incluir estructuras hardware especficas 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 diseo 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 tecnologa con la que se iba a realizar el circuito
y que se escoga antes de iniciar el proceso de diseo propiamente dicho.
1. Introduccin 25
A la vista de este flujo de diseo podemos citar como limitaciones ms impor-

tantes del mismo las siguientes:
El particionado inicial, el desarrollo de la arquitectura y su descomposicin
jerrquica descendente exigen una gran cantidad de decisiones crticas que
slo se basaban en la experiencia del diseador, sin contar con ningn sopor-
te metodolgico ni mecanismo alguno para hacer evaluaciones previas.
La biblioteca de celdas y, por lo tanto, la tecnologa de fabricacin se selec-
cionaban antes de iniciarse el proceso de diseo ascendente.
Ningn bloque poda simularse hasta no tener completamente diseados 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 anlisis y descomposicin jerrquica des-
cendente inicial, se detectaban en estadios muy tardos del proceso de diseo. El es-
fuerzo invertido ya era muy elevado y haba que recuperarse aunque fuese inclu-
yendo parches y soluciones atpicas en el diseo. Ello daba lugar a procesos de di-
seo poco claros y bastante complicados de forma que el depurado, las modifica-
ciones y el mantenimiento de un diseo se convertirn en tareas muy complejas, o
incluso imposibles, un cierto tiempo despus de finalizado el mismo.
En resumen, esta metod~oga facilitaba tanto la propagacin de problemas des-
de las fases iniciales hasta 1 fases avanzadas del diseo (cuanto ms tiempo se tar-
da en detectar un problem ms difcil y costosa en su resolucin, tanto por el es-
fuerzo acumulado como po la propia dificultad de la solucin), como la creacin de
estructuras innecesariamente omplejas o poco recomendables que podan dificultar
talmente la evolucin y mantenimiento del diseo, que este esfuerzo fuese inviable
y se requiriera un rediseo completo. Todo ello tiene mltiples facetas y todas ellas
acaban suponiendo un incremento de los costes de desarrollo del producto final.
1.3.2. Flujo de diseo descendente (top-down)

La idea bsica del diseo descendente frente al ascendente es aportar metodologa y
CAD para dar soporte a la parte izquierda del flujo mostrado en la Figura 1-9.
Las tcnicas de diseo descendente apuestan por la formalizacin y normaliza-
cin de las tareas de diseo desde las primeras etapas de concepcin (especificacio-
nes descritas en VHDL y, por lo tanto, simulables) y se centran en promover el dise-
o a nivel comportamental, facilitando la evaluacin de soluciones alternativas des-
de ese mismo nivel, dando lugar al llamado "diseo de alto nivel" [MLD92].
El objetivo es facilitar las tareas de diseo de alto nivel que van desde las espe-
cificaciones hasta la descripcin a nivel de transferencia de registros, de la arquitec-
tura escogida, cuya sntesis permita obtener una descripcin a nivel lgico 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 diseo fsico (ubicacin y cone-
xionado, verificacin, extraccin y retroanotacin de parsitos y retardos).
Aplicando el principio de abstraccin antes mencionado, se trata tambin de in-
dependizar el diseo a nivel funcional respecto del arquitectural-RT, y ste en rela-
cin al nivel lgico-puertas, siendo las herramientas de sntesis quienes marcan esta
independencia. Actualmente la sntesis est entre el nivel RT y las puertas; cuando
en un futuro inmediato se estabilice la sntesis comportamental, ahora a nivel prein-
dustrial, sern ms independientes entre s el diseo de nivel funcional y el arqui-
tectural- RT.
Las caractersticas y ventajas de los HOL en general (ver punto 1.2.4), y en es-
pecial de VHDL, estn facilitando y potenciando el desarrollo e implantacin de las
metodologas de diseo descendente que se basan en un uso intensivo de tales len-
guajes (modelado/descripcin del circuito y de los bancos de pruebas), convenien-
temente soportados durante todo el proceso de diseo por herramientas de simula-
cin, sntesis y procesos de anlisis-verificacin.
La Figura 1-10 muestra de forma esquemtica y genrica esta metodologa que
se basa en un proceso de construccin o diseo descendente apoyado en flujos de
informacin ascendentes.
1.3.2.1. Construccin o diseo descendente

A partir de la idea o concepto que se desea implementar en forma de sistema o cir-
cuito electrnico se ha de proceder a una primera fase de definicin de especifica-
ciones. Hasta ahora esta ha sido la etapa menos formalizada y a la que no se presta
la atencin que requiere, a pesar de que los resultados de la misma guan o dirigen
muchas de las decisiones posteriores durante el proceso de diseo. Con la llegada
de los HOLs se estableci la tecnologa de base para dar el soporte necesario a la
actividad de concepcin a nivel funcional, incluyendo la parte de descripcin/simu-
lacin de las especificaciones [CP96].
En principio las especificaciones de un diseo no tan slo han de incluir infor-
macin sobre el propio circuito, sino tambin del entorno operativo donde ste esta-
r ubicado. A partir de esta informacin el proceso de descripcin 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 abstraccin comportamental utili-
zando descripciones de tipo algortmico.
El modelo HDL del entorno del circuito para validarlo en su contexto (banco
de pruebas, test-bench). Este modelo tiene o puede tener mltiples funciones:
- reproducir el entorno de utilizacin del circuito,
- facilitar la generacin de estmulos hacia el circuito y la recogida de resul-
tados desde el mismo para poder analizar su comportamiento y
- comparacin de resultados respecto a un modelo de referencia,
todas ellas dirigidas a facilitar la comprobacin del correcto funcionamiento
del circuito bajo test, va procesos de simulacin y anlisis de resultados.
Con estos dos modelos ya se podrn hacer simulaciones funcionales que permi-
tan depurar las especificaciones y comenzar a evaluar distintas alternativas de parti-
cin del sistema.
1. Introduccin 27
~
Q)
E
~
8.
E
,, .!!!
,, ~c: g>
o "O
I
I
'0 e
I c:
::;,
o
Refinamiento gradual en HDL
I
, u.. $
___ 01I _ Q)
Sntesis 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 Mdulos
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 genrico de las metodologas y flujos de diseo descen-

dentes (too-aown).
Una vez fijadas las especificaciones, a travs del depurado de estos modelos, se
inicia el proceso de refinamiento gradual de la descripcin del circuito hasta alcan-
zar un modelo arquitectural-RT que sea sintetizable mediante procesos automticos
guiados por el diseador. Este refinamiento tambin puede afectar el banco de prue-
bas o entorno de test, no para hacerlo sintetizable, sino a fin de ajustar su precisin
a la del modelo del circuito. Un entorno de test cuya temporizacin se base slo en
relaciones causales, puede que no sea adecuado para un modelo del circuito que ya
se expresa en trminos de ciclos de reloj.
Esta primera fase de refinamiento gradual para pasar de una descripcin fun-
cional a una de nivel RT est ahora en vas de automatizacin y se la conoce como
sntesis comportamental.
A continuacin viene la etapa de sntesis RT-lgica que tiene por objeto la ob-
tencin de un esquema o lista de componentes y sus interconexiones basado en una
determinada biblioteca de celdas y mdulos. El diseo 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 automticos de sntesis para la testabilidad dirigi-
da por prestaciones y guiada por el diseador.
Estas herramientas de sntesis RT-lgica automticas se implementan mediante
distintos procesos de sntesis encadenados de forma transparente al usuario. Estos
procesos son:
1. Sntesis RT que determina los elementos de memoria y el conjunto de ecua-
ciones lgicas u operadores necesarios, en base a fases de particin, distri-
bucin (scheduling) y asignacin (allocation) de recursos, bajo las restric-
ciones impuestas por el diseador.
2. Sntesis lgica que se encarga de optimizar las ecuaciones lgicas para mi-
nimizar el hardware necesario a nivel de puertas y registros utilizando algo-
ritmos de reduccin y asignacin de estados, minimizacin lgica, elimina-
cin de redundancias, etc.
3. Mapeo tecnolgico que es una fase, muchas veces indistinguible de la snte-
sis lgica, en la que las puertas y registros se mapean de forma optimizada
sobre los elementos disponibles en la biblioteca de celdas y mdulos corres-
pondientes a la tecnologa escogida para la implementacin fsica del diseo.
A lo largo de estas fases se ha de incorporar al diseo las estrategias y el hard-
ware necesario para asegurar la posterior testabilidad del circuito. Estos son proce-
sos semiautomticos, o al menos muy asistidos por el diseador, que adems de
definir la estrategia de test y aadir las estructuras necesarias (scan-paths, multiple-
xores, modos ad-hoc, boundary-scan) se complementan con procesos de genera-
cin y composicin 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 diseo electrnico, despus de la
sntesis RT-lgica siempre hay unas ciertas tareas a nivel de puertas, que se agluti-
nan bajo el nombre de diseo detallado: simulacin funcional, temporal y de faltas,
anlisis de resultados y optimizacin de caminos crticos, 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 descripcin del diseo; aunque ello exija nue-
vas iteraciones de sntesis.
Despus de esta sntesis RT-lgica y el diseo detallado se obtienen los dos ele-
mentos bsicos para poder abordar las fases o etapas de diseo fsico: la lista de com-
1. Introduccin 29
ponentes y conexiones, las restricciones a cumplir y el conjunto de vectores de test.

Con estas descripciones ya podemos iniciar los procesos de ubicacin y conexionado
para generar la topografa y descripciones necesarias para la implementacin fsica del
circuito siguiendo el mismo tipo de mecanismos y flujos (extraccin, retroanotacin,
simulacin post-layout, etc.) enunciados en la fase back-end del diseo ascendente.
1.3.2.2. Informacin ascendente
En este proceso de refinamiento gradual descendente hay unos flujos de informa-

cin ascendentes que provienen o dependen de las etapas posteriores de diseo y, en
definitiva, de la tecnologa final de implementacin de cada circuito. Tal como se
muestra en la Figura 1-10, podemos distinguir dos tipos de informacin ascendente:
informacin tecnolgica propiamente dicha (parmetros geomtricos, elctri-
cos, retardos, celdas, etc.), que proviene de la tecnologa escogida, e
informacin que, a travs de un proceso de retroanotacin, proviene de una
descripcin de nivel inferior de abstraccin.
La informacin tecnolgica tiene distintos niveles de abstraccin, topogrfico
(reglas geomtricas, rea), elctrico (caractersticas de los dispositivos, R-C, con-
sumo), temporal (retrados) o funcional (celdas, mdulos, funciones), que le permi-
ten tener una incidencia dinmica directa sobre los distintos procesos y niveles de
construccin y sntesis, y, a travs de ellos, sobre las descripciones resultantes. Ac-
tualmente esta informacin tecnolgica empieza a intervenir en las etapas de snte-
sis lgica y mapeado tecnolgico incrementando su incidencia hasta llegar al diseo
fsico, que es donde mayor relevancia tiene.
El incremento progresivo del nivel de abstraccin de esta informacin tecno-
lgica permitir una intervencin ms temprana en el proceso de diseo y, por lo
tanto, facilitar la evaluacin de distintas alternativas tecnolgicas y mejores resul-
tados finales dentro de la tecnologa escogida. Como contrapartida, a medida que
hagamos un uso detallado de esta informacin, las descripciones resultantes son ca-
da vez ms dependientes de la tecnologa y de los procesos de sntesis, que son los
que hacen un uso ms o menos inteligente de la informacin tecnolgica.
Por su parte, los procesos de retroanotacin se utilizan para inyectar informa-
cin extrada de descripciones de bajo nivel y, por lo tanto, ms dependientes de la
implementacin final, en descripciones de niveles superiores de abstraccin. Un
ejemplo clsico es anotar sobre una netlist los retardos derivados del conexionado
fsico del circuito.
En general la retroanotacin no requiere de procesos muy elaborados, ya que
slo transporta y aade informacin a una cierta descripcin. Tiene una incidencia
ms bien esttica sobre el diseo al no afectar directamente a los procesos de cons-
truccin, aunque s incida en los criterios de convergencia hacia la solucin final a
aplicar en las siguientes iteraciones de sntesis. Otra cosa ser cuando la retroanota-
cin se pueda realizar despus de una etapa de sntesis RT o comportamental, pues
entonces, adems .de extraer y transportar la informacin, habr que abstraerla a fin
de anotarla correcta e inteligentemente sobre las descripciones previas a la sntesis.
Otro aspecto a considerar es que no todos los lenguajes HDL tienen estructuras
ni esquemas estndar para facilitar la retroanotacin de retardos desde el diseo
fsico 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 ningn esquema predefinido ni para ex-
presar la temporizacin (timing) de las celdas y mdulos de una biblioteca, ni para
anotar y reflejar los retardos debidos al conexionado en una netlist VHDL. Eso s,
la flexibilidad del VHDL permite mltiples soluciones para reflejar estas informa-
ciones en los modelos, y ah es donde reside el problema. Para solucionarlo se estn
llevando a cabo distintos proyectos, de los que VITAL puede que sea el ms signifi-
cativo por el nmero 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-
porizacin y retroanotacin, tambin basado en el SDF y, por lo tanto, altamente
compatible con el utilizado en el contexto del Verilog. Estos procesos de estandari-
zacin siempre requieren un compromiso entre flexibilidad del lenguaje (VITAL re-
duce la del VHDL) y eficiencia de los procesos de simulacin (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 informacin ascendentes, en las distintas etapas del diseo, marcan un poco el
grado de dependencia tecnolgica de las mismas y de las descripciones resultantes.
1.3.2.3. Validacin funcional multinivel

La validacin funcional multinivel hace referencia a dos tipos de verificaciones o
comprovaciones:
qu descripciones de un mismo circuito a distintos niveles de abstraccin
responden a un mismo comportamiento, o bien,
qu dos arquitecturas distintas realizan la misma funcionalidad.
Estas tareas se basan fundamentalmente en procesos de simulacin y anlisis.

En cuanto a las tcnicas de verificacin formal [BLR97], estn todava en fase de
desarrollo y, aunque en algunos casos pueden ser un buen complemento a la simula-
cin, no las consideraremos de forma explcita en este texto.
Como podemos ver en la Figura 1-10, la validacin del proceso de diseo des-
cendente se apoya en la simulacin de las distintas versiones y descripciones del
modelo bajo diseo, contra un mismo banco de pruebas y bajo un nico entorno de
simulacin basado en los HDLs que se estn 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. Introduccin 31
Pruebas especficas a nivel de circuito para validar partes concretas del dise-
o incluyendo varios mdulos interconectados y/o distintos modos de opera-
cin.
Pruebas de test locales y aisladas para distintos mdulos y submdulos del
circuito.
Pruebas de test especficas para la generacin del conjunto de vectores de
test (todo o parte) estructural del dispositivo una vez fabricado.
Estos distintos bloques de pruebas que antes (metodologas ascendentes) o no
se desarrollaban o exigan distintos lenguajes y simuladores, ahora se pueden des-
cribir con el mismo HDL con el que se est haciendo el diseo del circuito.
Sea cual sea el tipo de banco de pruebas, stos acostumbran a tener, dentro de
un equipo o centro de diseo, un esquema ms o menos uniforme, pudiendo incluir
distintos mdulos con distintos objetivos:
Modelo del entorno ms generacin de estmulos 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 diseo.
Mdulo de adquisicin, adecuacin y comparacin de los resultados obteni-
dos del modelo bajo test, respecto a los esperados proporcionados por el mo-
delo de referencia.
Mdulo para la generacin de vectores completos (estmulos + respuestas)
para su exportacin a otros formatos y entornos de diseo.
Todos estos componentes, u otros que cada equipo de diseo 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 presentacin genrica de tipo terico en el
Captulo 3, que se complementa en los Captulos 5 y 6 mediante exposiciones ms
prcticas y explcitas y con los correspondientes ejemplos de apoyo.
1.4. BIBLIOGRAFA
[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): Microelectrnica: Teora y Aplicaciones. Mar-
combo S.A. 1984.
[CP96] Comit PRENDA: PRENDA: Metodologa para el diseo 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. Prentce-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. Introduccin 33
[Nov95] NOVATICA(varios autores): Monografa sobre los lenguajes de diseo de "hardwa-

re". Revista Novatica (ATI), nms. 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 Informtica Test (Haymarket),
nms. 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 Lmits de la Microelectrnica. Memorias de
la Real Academia de Cincias y Artes de Barcelona. Tercera poca, nm. 916. Vol.
UII-nm. 1. Barcelona, 1994.
[SK94] M. SRIRAM& S. M. KANG: Physical Design of Multichip Modules. Kluwer Acade-
rnic Publishers, 1994.
[SM94] PETER A. SANDBORN& HCTORMORENO: 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 TERS: Generadores automticos de mdulos para circuitos VLS!. Tesis Doc-
toral, Univ. Autnoma de Barcelona, 1986.
[TM91] DONALD E. THOMAS y PHILIP R. MOORBY: The VERILOG Hardware Description
Language. Kluwer Acadernic Publishers, 1991.~,
[TML96] L. TERs, M. MOR Y E. LECHA: Los lenguajes de descripcin de "hardware" y la
microelectrnica. Revista Fronteras de la Ciencia y la Tecnologa (CSIC), nm. 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): Microelectrnica y diseo de circuitos integrados (ASICs).
Compendio Tecnolgico para la Prctica 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.
Captulo 2
PRESENTACION
DEL LENGUAJE VHDL
Manel Mor, Joan Vidal, Eduard Lecha, Fernando Rincn y Llus Ters
IMB-CNM (CSIC)
El secreto de aburrir
a la gente consiste en
decirlo todo.
Voltaire
En este captulo se realiza una presentacin 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 descripcin
exhaustiva de su sintaxis, algunos de los cuales se pueden encontrar
en la bibliografa de este captulo), sino que se intenta cubrir los con-
ceptos del lenguaje, de manera que el lector no iniciado en VHOL pue-
da encontrar en este captulo la introduccin adecuada que le permita
comprender la materia contenida en los siguientes captulos.
Los contenidos del captulo 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 captulo contiene numerosos ejemplos, destinados a clarificar
cada una de las caractersticas del lenguaje. Aparte de estos ejemplos,
al final del captulo se aaden ejercicios que pueden servir al lector pa-
ra comprobar el grado de madurez adquirida sobre el lenguaje.
35
2.1. INTRODUCCiN, CONTEXTO Y CONCEPTOS

BSICOS
Tal como indican las siglas de su nombre, VHDL (Very high speed Hardware
Description Language) es un lenguaje orientado a la descripcin o modelado de
hardware, pero a pesar de ello hereda muchos conceptos de los lenguajes de pro-
gramacin 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-
tersticas puede ser estableciendo una comparacin con dichos lenguajes de pro-
gramacin.
VHDL hereda de los lenguajes de programacin de alto nivel el concepto de
tipo de datos. A diferencia de muchos otros lenguajes de descripcin de hardware
que disponen de un reducido nmero de tipos de datos (la mayora de ellos orien-
tados al hardware) y con escasa o nula capacidad de definicin de nuevos tipos,
VHDL es un lenguaje que ofrece una enorme flexibilidad para definir nuevos ti-
pos de datos. Existen un reducido nmero 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 caracterstica importante de VHDL, que nos permite describir
sistemas electrnicos a. distintos niveles de abstraccin, ya que para cada nivel
de abstraccin que queramos abordar, podremos definir el tipo de dato ms ade-
cuado.
Tambin hereda de los lenguajes de programacin la potencia de control de flu-
jo, incorporando los dos tipos de control de flujo tpicos: control de condiciones (if,
case) e iteraciones (jor, while). Estas estructuras de control de flujo, junto con la
capacidad de definicin de tipos de datos enunciada en el prrafo anterior, hacen de
VHDL un lenguaje potente para desarrollar algoritmos, que pueden no tener rela-
cin directa con la descripcin de hardware.
Incorpora tambin la capacidad de estructuracin del cdigo, pudiendo agrupar
partes del cdigo en subprogramas, ya sean funciones (junction) o procedimientos
(procedures). Esta es otra caracterstica del VHDL heredada de los lenguajes de
programacin de alto nivel, y que nos permite afrontar de forma estructurada el de-
sarrollo de algoritmos complejos.
La ltima caracterstica claramente heredada de los lenguajes de programacin
de alto nivel es la posibilidad de desarrollar y utilizar bibliotecas de diseo, de for-
ma que al abordar el desarrollo de cualquier cdigo 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 caractersticas descritas hasta aqu presentan VHDL como un lenguaje pa-
recido a los lenguajes tpicos de programacin de alto nivel. De hecho, aquellas
personas que tengan cierta experiencia en el uso de dichos lenguajes encontrarn
muchas analogas que les facilitar el aprendizaje del VHDL. De todas formas hay
una serie de conceptos incorporados en VHDL especficos para el modelado de
hardware, que normalmente son un poco ms difciles de asimilar para todo aquel
que se enfrente con el aprendizaje de este lenguaje.
2. Presentacin del lenguaje VHDL 37
2.2. UN MODELO DEL HARDWARE
Tres son las caractersticas principales que incorpora VHDL enfocadas a facilitar o
permitir la descripcin de hardware: un modelo de estructura, un modelo de concu-
rrencia y un modelo de tiempo. Estas caractersticas junto con la capacidad de des-
cribir funcionalidad que le confieren las propiedades descritas en la seccin ante-
rior, hacen de VHDL un lenguaje flexible y potente, que se adapta perfectamente a
la descripcin de sistemas electrnicos a cualquier nivel de abstraccin.
2.2.1. Modelo de estructura: componentes y jerarqua

De forma natural cualquier sistema electrnico puede dividirse en subsistemas ms
pequeos (hasta llegar al nivel de puertas, que seran las primitivas del diseo digi-
tal). Por ello VHDL incorpora el concepto de estructura. Esta caracterstica 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 conexin 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-
cripcin algortmica del lenguaj~. Siempre en el ltimo nivel de jerarqua 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 diseador debe definir dos elementos principales: la interfaz del dispo-
sitivo con el exterior (la entidad o entity) y la descripcin de la funcionalidad que
realiza el dispositivo (la arquitectura o architecture). La interfaz de un dispositivo
tiene por objeto definir qu seales 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 realizarn 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 diseador o
disponibles en bibliotecas de diseo) en descripciones estructurales de un nuevo di-
seo, 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 diseo. 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 diseo. La Figura 2-1 ilustra esta idea, el sistema bajo desarrollo
se forma a partir de dos subsistemas que se habrn definido con anterioridad. El di-
seador slo 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 cmo 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 cdigo se hace referencia a
esos dos componentes, tomando una copia o referencia de cada uno de ellos y co-
nectndolos de la forma que se indica en el grfico. Cada vez que vare 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 funcin,
pudiendo variar el valor de su puerto de salida. Obsrvese que si la puerta and pro-
duce un cambio sobre su puerto de salida e, ste implicar que la puerta or ejecute
su funcin, 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 anlogo al mecanismo de diseo
clsico utilizado en la captura de esquemticos. Cualquier modelo VHDL puede
abordar el diseo de un nuevo componente, desde una aproximacin 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 electrnico completo.
Obsrvese que este mecanismo bsico del VHDL de modelado de la estructura
(la copia o referencia a componente) ofrece a su vez la forma de especificar lajerar-
qua de un diseo.
2.2.2. Modelo de concurrencia: procesos, seales

y eventos
El hardware es por definicin concurrente, en ltima instancia cualquier dispositivo

digital est formado de un mar de puertas lgicas, todas ellas funcionando en para-
lelo. El elemento bsico 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 descripcin funcional de
VHDL) y el cdigo que contiene se ejecuta de forma secuencial. Pero todos los pro-
cesos contenidos en una descripcin VHDL se ejecutarn de forma paralela. Desde
este punto de vista un modelo VHDL puede entenderse como un mar de programas
secuenciales ejecutndose de forma paralela. De hecho, cualquier descripcin

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 informacin 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
seal (signal). Cada proceso tiene un conjunto de seales a las que es sensible. Ser
sensible a una seal significa que en cuanto se produzca un cambio en el valor de
dicha seal (un evento en la seal), el proceso se ejecutar hasta que encuentre una
sentencia de suspensin del proceso (wait). Al llegar a esta sentencia, el proceso
quedar suspendido, esta suspensin ser por un periodo determinado de tiempo, o
bien hasta que se produzca un nuevo evento en alguna de las seales a las que sea
sensible dicho proceso. Aparte de poder suspender la ejecucin 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 seal a o de la seal b. Cuando se produzca el cambio se ejecu-
ta el proceso y, por tanto, asigna a su salida e el valor de la expresin lgica a and
b. A continuacin 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 lgica 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 seal e para sincronizar los dos procesos, siempre que se pro-
duzca un evento en la seal e, se ejecutar el proceso OR2.
Por supuesto, y dado el paralelismo en la ejecucin de los procesos, si en un
momento de la simulacin se producen eventos sobre las seales 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 simulacin.
Sobre las seales slo diremos de momento que son objetos que pueden ir
variando su valor a lo largo de la simulacin (en este aspecto son parecidas a las va-
riables). Su caracterstica 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
seal es esta cola de-eventos la que recibe los valores asignados. En las siguientes
secciones veremos cmo el mecanismo de simulacin VHDL define en qu mo-
mento los valores asignados a la cola de eventos de una seal pasan a actualizar el
valor de la misma.
2.2.3. Modelo de tiempo: ciclo de simulacin
Una de las finalidades del modelado en VHDL del hardware es poder observar su
comportamiento a lo largo del tiempo (simulacin). Esto implica que las construc-
ciones del lenguaje tendrn asociada una semntica respecto a la simulacin, es de-
cir, influirn en sta provocando distintos eventos (cambios en las seales que con-
trolan la evolucin del sistema) que se sucedern 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 simulacin. El concepto de tiempo es fundamental para definir
cmo se desarrolla la simulacin de una descripcin VHDL.
La simulacin de un modelo VHDL es una simulacin dirigida por eventos.
Esto significa que el simulador mantiene unas listas, de eventos (cambios en las se-
ales internas del modelo y tambin de las entradas y salidas) que se han de produ-
cir a lo largo del tiempo de simulacin. Como el comportamiento del modelo es es-
table mientras no se produzca un evento, la tarea del simulador consiste en avanzar
el tiempo de simulacin hasta el siguiente evento y calcular sus consecuencias so-
bre la lista de eventos futuros (mediante la ejecucin de los procesos afectados por
el evento actual).
Normalmente la reaccin del modelo a un evento ocasionar otros eventos a
suceder en un tiempo de simulacin posterior que se aadirn a la lista. De este mo-
do la simulacin finaliza cuando se ha alcanzado el tiempo de simulacin especifi-
cado por el usuario o cuando no existen ms eventos.
La simulacin VHDL abstrae el comportamiento real del hardware, implemen-
tando el mecanismo de estmulo respuesta (componentes funcionales reaccionan a
la actividad en sus entradas produciendo cambios en sus salidas) implementando un
ciclo de simulacin de dos etapas (Figura 2-3), basado en los procesos (elementos
funcionales) y las seales (entrada y salidas de estos elementos funcionales; cone-
xiones entre elementos).
En la primera etapa las seales actualizan su valor. Esta etapa finaliza cuando
todas las seales que deban obtener un nuevo valor en el tiempo actual de simula-
cin (tenan 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 seal en la que se haya producido un evento) se ejecutan hasta que
2. Presentacin del lenguaje VHOL 41
Inicio simulacin
Actualizar seales Ejecutar procesos
Final simulacin
FIGURA 2-3. Ciclo de simulacin VHDL.
se suspenden (con la ejecucin de una sentencia wait). Esta etapa finaliza cuando
todos los procesos que se haban activado se hayan suspendido. Entonces el tiempo
de simulacin avanza hasta el siguiente instante de tiempo en el que haya un evento
programado, y se repiten los dos pasos del ciclo de simulacin. La simulacin ter-
mina cuando no haya ms eventos programados o cuando se llegue al tiempo de si-
mulacin especificado.
Es importante notar que el modelo de tiempo implementado por el ciclo de si-
mulacin 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 seal (el proceso
ejecuta la asignacin sobre la seal) y el momento en que esta seal 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 simulacin, pero s que implica ejecutar un nuevo ciclo
de simulacin.
El concepto de retardo delta es importante para entender otra diferencia impor-
tante entre variable y seal. Una variable actualiza su contenido en cuanto se ejecu-
ta una asignacin sobre ella. En cambio, cuando se ejecuta una asignacin sobre
una seal, se proyecta un nuevo evento sobre su cola de eventos y slo cuando to-
dos los procesos se hayan ejecutado y estn suspendidos, el valor de la seal se ac-
tualizar con el valor proyectado en su cola de eventos.
Este mecanismo del retardo delta se introduce para permitir la simulacin de
hardware (paralelo por naturaleza) usando mquinas secuenciales, y es el que per-
mite asegurar el determinismo de la ejecucin del cdigo VHDL. Consideremos el
cdigo 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 simulacin VHDL.
la asignacin que ste realiza sobre QI an 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 asignacin de DI sobre Q2 se colocar en la cola de eventos de Q2 el valor
correcto de DI (an sin actualizar). Slo en el momento en que ambos procesos se
hayan suspendido, se actualizarn las seales con los valores que contengan sus co-
las de eventos.
Para clarificar el funcionamiento del ciclo de simulacin y del retardo delta, en
la Figura 2-5 se muestra cmo se comportara la simulacin VHDL y cmo evolu-
cionaran las seales 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 seal
de entrada DI toma los valores reflejados en la figura. Tomando CK y DI como es-
tmulos se muestra la respuesta del ciclo de simulacin. Ntese que en realidad los
valores que toman CK y DI tambin son consecuencia de.la forma en que el ciclo
de simulacin acta sobre estas seales, pero por simplicidad slo mostramos la
evolucin de QI y Q2.
Obsrvese que si las seales tomasen sus nuevos valores en el instante en que
se realiza la asignacin sobre ellas, la ejecucin del ejemplo anterior dara como re-
sultado valores distintos sobre las seales QI y Q2, dependiendo del orden en que
se ejecutasen los procesos FFI y FF2.
Estmulos a la simulacin
CK
.,
le
D1 J
,
.
10 ns 20 ns 30 ns
Respuesta de la simulacin
Tilempo de simulacin Accin simulacin Valor seales Cola eventos

01 02 01 02
Actualizar seales _____ (-J __ JQL ___--- ...... _-------_.

10 ns --------------------
Ejecutar procesos
1 O
Actualizar seales 1 O
10 ns + o ns -------------------- ------ ... ---------- -_ .. ----- ... _--_ ......
Ejecutar procesos - -
Actualizar seales (1) (01
20 ns -------------------- ----------------- ----------- ...........
Ejecutar procesos 1 1
1 1
20 ns + o ns Actualizar seales
-------------------- ----------------- ----_ .. _---------
Ejecutar procesos - -
(*) valor anterior que ya contena la seal.
FIGURA 2-5. Ciclo de simulacin y retardo delta.
2.3. UNIDADES BSICAS DE DISEO
Una unidad de diseo es una construccin VHDL que puede ser analizada indepen-
dientemente; en este momento se puede considerar que el anlisis de una unidad de
diseo es anlogo a la compilacin de un programa, ms adelante, en el Captulo 3,
se describir con detalle el proceso de anlisis. Existen cinco tipos diferentes de
unidades de diseo: la declaracin de entidad (entity declaration), la arquitectura de
una entidad (architecture J, la configuracin (configuration J, la declaracin de pa-
quete (package declaration) y el cuerpo del paquete (package body). La declaracin
de entidad, la declaracin de paquete y la configuracin 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 declaracin de entidad, donde se da una visin externa del dispositivo definin-
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 mltiples arquitecturas asociadas a una nica entidad. La
configuracin es la construccin encargada de seleccionar la arquitectura especfica
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 diseo donde estos objetos son necesa-
rios, por lo que no sern visibles en las dems unidades. Para declaraciones tiles
para varias unidades de diseo, VHDL proporciona el paquete, que evita la multi-
plicidad de declaraciones comunes. Normalmente el paquete se divide en dos uni-
dades de diseo VHDL: la declaracin y el cuerpo del paquete.
En las siguientes secciones de este apartado se van a explicar ms detallada-
mente las caractersticas ms importantes de cada unidad de diseo y de las biblio-
tecas donde estas unidades se almacenan para su futuro uso una vez analizadas.
2.3.1. Declaracin de entidad

La declaracin de una entidad sirve para definir la visin externa del dispositivo
que dicha entidad representa, es decir, la interfaz con su entorno. VHDL separa esta
visin externa de la implementacin concreta del dispositivo para dar la posibilidad
de que sta quede oculta. De este modo, despus de haber analizado la declaracin
de una entidad y, por tanto, haberla almacenado en una biblioteca, esta entidad po-
dr ser utilizada por otros diseos que slo requieren de dicha interfaz para usarla.
La sintaxis VHDL para declarar una entidad es la siguiente:
entity identificador iB
[genricos)
[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 ms tarde. En caso que se repita el identificador al final de la declara-
cin, ste debe ser idntico al definido en la primera lnea o se detectar un error
sintctico al analizar la declaracin.
Excepto la primera y la ltima lnea de la declaracin, todas las dems son op-
cionales, por lo que la entidad mnima sera la siguiente:
entity identificador iB
end;
Esta entidad no tiene ninguna comunicacin con el exterior, por lo que no pue-
de ser reutilizada en ningn otro diseo. No obstante, entidades de este tipo pueden
utilizarse para describir sistemas completos (ver Captulo 5).
De entre las partes opcionales de la declaracin de una entidad cabe destacar la
declaracin 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-
paracin 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 informacin que se transmitir por el puerto mientras que
el modo servir para definir la direccin de la informacin, en el sentido que los
puertos podrn ser de entrada, de salida o bidireccionales. Opcionalmente tambin
puede asignarse un valor por defecto que se tendr en cuenta slo en caso que el
puerto est desconectado. Por ejemplo, la declaracin de una entidad que imple-
mente un multiplexor de dos bits sera:
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

slo se indica cmo debe comunicarse el dispositivo con su entorno sin dar ningn
detalle de su implementacin. En otras palabras, la declaracin de cualquier entidad
que tenga tres entradas y una salida de tipo bit, sea cual sea su funcionalidad, ser
idntica a la declaracin de este multiplexor, cambiando seguramente los nombres
de la entidad y de los puertos.
Adems de los puertos, en la declaracin de una entidad se ha visto que hay
otras partes opcionales, concretamente genricos, declaraciones y sentencias.
Los genricos son un conjunto de parmetros que permiten modificar la funcio-
nalidad al referenciar la entidad, de esta forma se consiguen descripciones ms ge-
nerales. Por ejemplo, al describir un dispositivo que sea un sumador de dos valores
enteros, se pueden introducir como genricos el nmero de bits de los operandos.
De esta forma, se podr usar una nica entidad sumador para sumadores de cual-
quier tamao. Ms adelante en este captulo, cuando se hable de cmo 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 descripcin estructural se ver con ms detalle cmo fun-
cionan los genricos.
Las declaraciones y las sentencias normalmente no forman parte de la declara-
cin de una entidad, ya que en principio tienen poco que ver con la interfaz del dis-
positivo y mucho con su implementacin, por lo que es ms 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 tpicas 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 declaracin 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 ms tarde. Este identificador puede repetirse al final de la definicin de la
arquitectura. Adems 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 descripcin de la arquitectura, dichos elementos
pueden ser, por ejemplo, constantes, tipos de datos o seales internas; en los prxi-
mos apartados de este captulo se vern con ms detalle todas estas cuestiones.
La seccin de sentencias concurrentes describe propiamente la funcionalidad
del dispositivo. Existen muchos tipos de sentencias concurrentes, ms adelante en
este captulo se dedica un apartado a describirlas. Dependiendo del tipo de senten-
cias utilizadas se puede modelar una arquitectura siguiendo diferentes estilos:
Estilo algortmico: 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 mdulos 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-

ractersticas de estos estilos de descripcin.
2.3.2.1. Estilo algortmico
El estilo algortmico 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 programacin comn, 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 algortmico sera:
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;
Ms adelante en este captulo se vern con detalle las sentencias utilizadas en

el cdigo. 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 simultneamente, que est formado por una o ms instrucciones se-
cuenciales. Por est razn, una arquitectura con un solo proceso es equivalente a un
algoritmo ejecutado secuencialmente.
2.3.2.2. Estilo flujo de datos
Una descripcin 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 mdulos encargados de implementar las
operaciones. En este estilo ya existe una correspondencia directa entre el cdigo y
su implementacin hardware. Suele considerarse que este tipo de descripcin es
funcional y estructural al mismo tiempo, ya que define tanto el comportamiento de
los mdulos como su interconexin con los dems mdulos.
El multiplexor de dos bits declarado anteriormente siguiendo un estilo de des-
cripcin de flujo de datos sera:
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 tendran que llevar a cabo seran de
tipo lgico y se podran implementar mediante una sola puerta. En general las ope-
raciones pueden ser mucho ms complejas siendo necesarios mdulos ms grandes
para implementarlas, por ejemplo, sumadores, multiplicadores o desplazadores de
varios bits. El ejemplo incorpora tres seales internas para definir la interconexin
de los diferentes operadores y asocia un valor de retardo a cada operacin mediante
la clusula after, que se ver ms adelante en este captulo al hablar de las asigna-
ciones a seales.
2.3.2.3. Estilo estructural
Una arquitectura definida utilizando el estilo estructural consiste en un conjunto de

componentes interconectados mediante seales. Un ejemplo tpico de descripcin
utilizando este estilo es la representacin de un circuito como una lista de compo-
nentes interconectados (netlist) de una biblioteca de celdas estndar de una tecnolo-
ga determinada. La descripcin es puramente estructural en el sentido que no in-
cluye ningn tipo de funcionalidad, sta en todo caso est incluida en la definicin
de la arquitectura de los componentes que forman la descripcin.
El multiplexor de dos bits declarado anteriormente podra 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 descripcin 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 continuacin se deben referenciar los componentes y conectar las seales
para conseguir la estructura deseada. Para cada referencia hay que dar un nombre
nico para poder diferenciarla de otras referencias al mismo componente. Ms ade-
lante en este captulo se hablar con ms detalle de cmo referenciar componentes
dentro de una arquitectura y de las posibilidades que existen para hacerlo.
2.3.2.4. Estilo mixto
Este subapartado slo 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 implementacin 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 lnea) que determinen un flujo de los datos y
una serie de referencias a otros componentes de ms bajo nivel. Por lo tanto, el gra-
do de flexibilidad que permite VHDL en este sentido es muy importante.
2.3.3. Configuracin
La configuracin es la construccin VHDL encargada de seleccionar la arquitectura
que se quiere utilizar para una entidad concreta. Como se ha comentado anterior-
mente, VHDL permite definir ms de una arquitectura por entidad para facilitar el
estudio de varias posibilidades a la hora de implementarla.
La sintaxis VHDL para definir una configuracin 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_configuracin;]
end for; }
end for;
end [configuration] [identificador];
El identificador es el nombre que va a recibir la configuracin y servir para

poder referenciarla ms tarde. En caso que se incluya el identificador al final de la
declaracin debe coincidir exactamente con el que se haya incluido en la primera
lnea. Aparte de aportar un nombre, es necesario identificar la entidad y la arquitec-
tura relacionados en la configuracin mediante sus identificadores respectivos.
Cuando el diseo sea jerrquico, tambin pueden determinarse las entidades y ar-
quitecturas que se van a utilizar para los componentes de ms bajo nivel. En este
caso es necesario relacionar las referencias de los componentes con una entidad y
una arquitectura o bien indicar la configuracin que se quiere usar para cada com-
ponente. Como se podra 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 configuracin del multiplexor de dos bits utilizado en los subapartados ante-
riores en el caso que se quiera trabajar con la arquitectura llamada FlujoDatos sera:
configuration Mux21_cfg of Mux21 is
for FlujoDatos
end for;
end Mux21_cfg;
Para ver un ejemplo donde se muestre una configuracin de un modelo jerr-

quico, se puede considerar que para cada componente usado en la implementacin
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 podra definir la siguiente configuracin:
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 configuracin 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 definicin de cada dispositivo. De
esta forma se facilita la reutilizacin y la actualizacin del cdigo.
Normalmente en un paquete se suelen declarar constantes, tipos y subtipos de
datos, subprogramas y componentes. Ms adelante en este captulo se ver con ms
detalle el significado y la utilizacin 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 diseo diferenciadas: la declaracin y el cuerpo
del paquete. La declaracin de paquete aporta la visin externa de los elementos
que se declaran mientras que el cuerpo del paquete define su implementacin. De
este modo se pueden ocultar los detalles de implementacin a un diseador que
puede estar interesado en cmo utilizar un elemento pero no necesita saber cmo
est implementado. Por esta razn, en la declaracin de un paquete suelen declarar-
se los subprogramas dndoles un nombre y la lista de parmetros necesarios para
llamarlos sin incluir su cuerpo. Respecto a las constantes, se pueden declarar en la
declaracin del paquete y darles un valor en el cuerpo del paquete o bien incluir to-
da la informacin slo en la declaracin del paquete. La declaracin de componen-
tes es muy til, por ejemplo, para bibliotecas de celdas, de este modo los diseos
pueden utilizarlas sin tener que aadir una larga declaracin de componentes al ini-
cio de su arquitectura. En este caso slo es necesario la interfaz de la celda, por lo
que la declaracin se pondr en la declaracin del paquete. Por ltimo, al declarar
tipos y subtipos de datos ya se da toda la informacin, por lo que suelen ponerse s-
lo en la declaracin 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 ms tarde. Este identificador puede repetirse al final de la declaracin. Co-
mo puede apreciarse, la sintaxis es muy parecida para la declaracin 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-
racin antes, de forma que si sta vara se tendr que reanalizar el cuerpo del paquete.
Por ejemplo, podra utilizarse un paquete para definir el retardo de los operado-
res lgicos not, and y oro Aunque se puede incluir toda la informacin en la decla-
racin 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 anlisis queda almacenado en

una biblioteca para poder ser usado ms 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 explicarn en el prximo 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 estndar de Diseo Electrnico
El paquete acabado de definir podra 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 mltiples ocasiones. Umi posibilidad para solucionar este problema es
usar la sentencia use al principio de la unidad de diseo donde dicho elemento vaya
a ser utilizado. De este modo, en el cdigo 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 escribira al inicio del cdigo:
use Biblio.RtardosOp.RetNOT;
En caso que se requiera el uso de ms de un elemento del paquete se puede

aadir 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 descripcin

de la arquitectura en estilo de flujo de datos sera:
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 bsicos como, por ejemplo, los ti-
pos bit y time que se han visto en algn ejemplo de este captulo. Adems los fabri-
cantes suelen aportar otros paquetes con tipos de datos ms complejos y operacio-
nes sobre estos tipos para facilitar el trabajo del diseador.
2.3.5. Bibliotecas
Una biblioteca sirve para almacenar el resultado del anlisis de las unidades de di-
seo para su futuro uso. Las bibliotecas son beneficiosas porque facilitan la com-
particin y la reutilizacin del cdigo en diferentes diseos.
Aunque las unidades de diseo se analicen separadamente, se tiene que respe-
tar un cierto orden ya que algunas unidades dependen de otras. En general, la decla-
racin de una entidad tiene que analizarse antes que su arquitectura y la declaracin
de un paquete antes que su cuerpo. Adems, cuando una entidad utilice algn 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 configuracin tienen
que haberse analizado las arquitecturas seleccionadas en dicha configuracin.
En el caso del ejemplo del multiplexor de dos bits que se ha venido utilizando
en todo este apartado de captulo se podran analizar las unidades de diseo 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
Configuracin Mux21_cfg
De hecho, la declaracin de la entidad Mux21 y de las arquitecturas Algoritmi-

ca y Estructural no dependen del paquete RedardosOp, por lo que podran 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 diseador
puede crear el nmero de bibliotecas que crea necesario y repartir sus diseos entre
las bibliotecas de la forma que crea ms conveniente.
Desde un modelo almacenado en una biblioteca no puede accederse directa-
mente a las unidades de diseo 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 tendra 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 definicin de biblioteca es una definicin lgi-
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 jerrquica de directorios. Por esta razn, cada herramienta
debe aportar facilidades para crear bibliotecas y para mapear su estructura lgica a
la posicin fsica 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 podrn aplicar. En gene-
ral, no ser posible realizar operaciones entre dos objetos de distinto tipo si no se
aplica explcitamente una funcin de conversin de tipo a los operandos. Aunque
esta faceta del VHDL implica ms atencin por parte del diseador a la hora de es-
cribir un modelo, permite detectar errores durante el anlisis del cdigo sin necesi-
dad de simulacin.
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 lxicos
Antes de empezar a hablar de los objetos del VHDL resulta adecuado introducir los
elementos lxicos del lenguaje, que bsicamente son los identificadores, las pala-
bras reservadas, los smbolos 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
comprensin del cdigo. Existen una serie de reglas a la hora de formar un identifi-
cador:
Los identificadores no tienen fijada una longitud mxima. Lo ms 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 alfabticos de 'A' a 'Z' y de
'a' a 'z', los caracteres numricos de 'O' a '9' y el carcter subrayado '_'
(underline). VHDL no establece ninguna diferencia entre maysculas y mi-
nsculas, por lo que los identificadores RELOJ, reloj y Rel.al son idnticos.
Un identificador debe empezar con un carcter alfabtico, no puede terminar
con el carcter subrayado ni puede tener dos caracteres de subrayado segui-
dos.
No puede usarse como identificador una palabra reservada (las palabras re-
servadas se vern a continuacin).
Teniendo en cuenta estas reglas, a continuacin 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 bsicos, 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 comunicacin 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 definiran los identificadores extendi-
dos \3\, \i2_\, \_i2\, \Reloj$ADC\, \Reloj_ADC\ y \3Interrupcin\. En este caso s
que se diferencian las maysculas de las minsculas, de modo que los identificado-
res \RELOJ\, 'veloj. y \ReLoJ\. son distintos, a la vez que se diferencian de los iden-
tificadores bsicos 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-
cfico en VHDL y que sirven para definir las sentencias que forman un modelo. Por
esta razn 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 aadieron nuevas palabras reservadas al lenguaje. El conjunto

de nuevas palabras son las listadas a continuacin:
group postponed ror sra
iIrq>ure pure shared srl
inertial reject sla unaffected
literal rol s11 xnor
2.4.1.3. Smbolos especiales

Adems de los literales y las palabras reservadas, VHDL aporta un conjunto de
smbolos especiales que tienen diferentes funciones, desde operadores de distintos
tipos hasta smbolos que forman parte de sentencias o smbolos de puntuacin.
Los smbolos pueden estar formados por un carcter:
+ - + / ( ) ;&'<>=1#
o por dos caracteres:

=> ** := /= >= <= <> --
Los significados de cada smbolo se vern a lo largo del captulo cuando se ha-
ble del tema concreto donde se use el smbolo. Por ejemplo, al tratar los operadores
ms adelante en este apartado se ver el significado de gran parte de smbolos de
esta lista.
Quizs en este momento cabe destacar el smbolo "--" que sirve para aadir co-
mentarios en el cdigo. Cuando aparezca este smbolo en una lnea, el analizador
no tendr en cuenta el texto comprendido entre este smbolo y el final de la lnea.
Al igual que en cualquier programa escrito en un lenguaje de programacin comn,
resulta muy til aadir comentarios en el cdigo para mejorar la legibilidad.
Finalmente resaltar que cualquier sentencia del lenguaje VHDL debe terminar
con el smbolo ";",
2.4.1.4. Literales
Un literal es un smbolo cuyo valor se obtiene directamente de su representacin.
Existen diferentes tipos de literales dependiendo de la naturaleza de su valor, con-
cretamente los literales se dividen en: nmeros enteros, nmeros en punto flotante,
literales fsicos, caracteres, cadenas de caracteres y cadenas de bits.
Los nmeros enteros, los nmeros en punto flotante y los literales fsicos sirven
para expresar valores numricos. Los nmeros enteros se componen simplemente
de una secuencia de dgitos, a diferencia de los valores en punto flotante, que deben
contener un punto y un dgito decimal. Por su parte, los literales fsicos son valores
enteros o en punto flotante que tienen una unidad de medida fsica asignada.
Algunos ejemplos de literales enteros seran:

4 5436 o
En el caso de los literales en punto flotante:
3.1415927 5436.0 0.42
Por ltimo, los literales fsicos:

5.23 ns 52 mm 0.4 v
Adems de esta representacin, VHDL permite describir estos literales numri-

cos utilizando la notacin exponencial. Evidentemente el exponente tendr que ser
positivo para los valores enteros.
Algunos ejemplos utilizando esta representacin seran:
52e2 43.23E+2 2.1E-04 12E2 kohm
Tambin cabe destacar que los literales numricos se pueden representar utili-
zando cualquier base entre 2 y 16. Para bases mayores que 10 se utilizarn los ca-
racteres desde 'A' a 'P' (o en minsculas) para representar los dgitos desde ellO al
15. La notacin exponencial tambin se puede representar en cualquier base. Por
ejemplo, el valor 12 se podra 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 notacin decimal
representa una potencia de la base con la que se trabaja.
Por ltimo, referente a los literales numricos slo decir que para mejorar la le-
gibilidad de nmeros con muchos dgitos se permite aadir caracteres '_' entre los
dgitos. De esta forma, por ejemplo, se pueden agrupar los dgitos en grupos de tres
para separar los valores numricos en miles.
Un literal carcter es simplemente un carcter ASCII encerrado entre comillas
simples. A continuacin se dan algunos ejemplos de caracteres:
'm' 'M' '3' I I I
r
I
Como se ve, el carcter 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 encerrndolo entre comillas dobles.
Algunos ejemplos de cadenas de caracteres seran:
"abcdef' 'a4&3(j" "hola' 'abcde ., fghi'
En el ltimo ejemplo se muestra que para incluir el carcter 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 minsculas) 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 numricos se pue-
den incluir caracteres '_' para mejorar la legibilidad en caso de secuencias muy lar-
gas.
A continuacin 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 seales y
los ficheros.
Todos los objetos deben declararse antes de poder ser utilizados. La declara-
cin consiste bsicamente en asignar un identificador y un tipo al objeto. Opcional-
mente tambin se le puede dar un valor inicial, de no hacerlo VHDL inicializar el
objeto segn unas reglas que se describirn ms adelante.
En las siguientes secciones de este subapartado se vern con ms 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 ms tar-

de, el tipo indica la naturaleza del valor que contiene y la expresin 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 inicializacin en la declaracin. De todos modos,
la parte de inicializacin es opcional. Cuando se explic el paquete se vio que la de-
claracin del paquete es una construccin VHDL que puede contener constantes sin
inicializar.
A continuacin se ven algunos ejemplos de declaraciones de constantes:
constant Pi : real;= 3.1415927;

constant BitsPalabra: integer := 8;
constant NmeroPalabras : integer. := 64;
constant NmeroBits : inteqer := BitsPalabra * NffieroPalabras;
constant Retard0AND2, RetardoOR2 : time := 2 ns;
Cualquier constante podra ser sustituida directamente por un literal con su va-
lor; no obstante, es aconsejable utilizar constantes para mejorar la legibilidad del
cdigo, ya que normalmente el identificador de la constante ser ms significativo
que su valor. Tambin para facilitar su actualizacin, de este modo, para cambiar el
valor de una constante slo se tendr que modificar la declaracin, si no se usan
constantes har falta realizar tantas modificaciones como veces aparezca el literal
en el cdigo.
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 asignacin. Una variable no tiene ningu-
na analoga directa en hardware, normalmente se utilizan en el estilo algortmico
para almacenar valores intermedios dentro de un proceso.
La sintaxis VHDL para declarar una variable es la siguiente:
variable identificador {, ...} : tipo [:=expresin];
Como se puede ver, a excepcin de la palabra reservada que es diferente, la

sintaxis para declarar una variable es idntica a la que se requera para la declara-
cin de una constante.
A continuacin se muestran algunos ejemplos de declaracin 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 asignacin de variable. La sintaxis VHDL de estas sentencias es la
siguiente:
identificador := expresin;
El nuevo valor de la variable ser el resultado de evaluar la expresin incluida

en la sentencia. La asignacin ser inmediata en el sentido que el nuevo valor susti-
tuir al antiguo inmediatamente despus de haberse evaluado la expresin, 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 ms de un proceso, teniendo en
cuenta que la ejecucin de los procesos es concurrente, sera impredecible el resul-
tado que se producira 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. Seales
Una seal 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 analoga
directa en hardware. ya que se puede considerar como una abstraccin de una cone-
xin fsica o un bus. Por esta razn, no est restringida a un proceso sino que sirve
para interconectar componentes de un circuito y para sincronizar la ejecucin y sus-
pensin de procesos.
La sintaxis VHDL para declarar una seal es muy parecida a la sintaxis reque-
rida para declarar constantes y variables:
signal identificador {, ...} : tipo [:=~resi6~1;
A diferencia de las variables, una seal no se declarar en la parte declarativa

de un proceso sino en la de la arquitectura del dispositivo.
Los puertos de una entidad son seales que se utilizan para interconectar el dis-
positivo con otros dispositivos. Su declaracin es un poco especial, ya que aparte de
determinar un identificador y un tipo de datos es necesario indicar la direccin de la
seal respecto a la entidad. La seccin de declaracin de puertos de una entidad tie-
ne la siguiente sintaxis VHDL:
port ({identificador L ...} : direccin tipo {!,=expresil11;})';
En este caso la expresin opcional se utiliza en caso de que el puerto est des-
conectado.
A continuacin se muestran algunos ejemplos de declaracin de seales:
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 seal puede modificar su valor mediante la sentencia de asignacin de se-

ales. A diferencia de las variables, la asignacin de una seal 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. Adems, en
la sentencia se puede indicar el retardo con que se quiere realizar la asignacin, de
forma que cada seal tiene como mnimo una cola de eventos, en la que cada even-
to es una asignacin pendiente formada por el valor y el momento en que esta asig-
nacin debe llevarse a cabo. Ms adelante en este captulo se ver con detalle la
asignacin de seales.
2.4.2.4. Ficheros
Un fichero es un objeto que permite comunicar un diseo VHDL con un entorno
externo, de manera que un modelo puede escribir datos y leer datos que persisten
cuando la simulacin termina. Un uso bastante comn de los ficheros es el de alma-

cenar los estmulos de simulacin que se quieren aplicar al modelo en un fichero de
entrada y salvar los resultados de simulacin en un fichero de salida para su poste-
rior estudio.
Un fichero es de un tipo de datos determinado y slo puede almacenar datos de
ese tipo. La sintaxis para declarar un fichero es la siguiente:
file identificador {, ...} : tipo_fichero lis direccin "nombre";]
El identificador servir para referenciar el fichero en el cdigo. El tipo de fi-

chero indica el tipo de datos que contendr el fichero y debe declararse explcita-
mente antes de declarar el objeto fichero. En el siguiente subapartado de este cap-
tulo se ver cmo declarar tipos de datos y, concretamente, tipos de fichero. La di-
reccin indica si el fichero va a ser de lectura o de escritura, mientras que el nombre
de fichero se refiere al nombre fsico que va a recibir el fichero dentro del sistema
de ficheros de la computadora. Despus de la declaracin de un fichero, VHDL au-
tomticamente abre el fichero para lectura o escritura dependiendo de la direccin
seleccionada.
Algunos ejemplos de declaracin de ficheros seran:
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 direccin se sustituye por la palabra reservada open ms 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 seran:
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. Adems, 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 podrn realizar con este objeto.
VHDL proporciona sentencias especficas para la declaracin de nuevos tipos

adems de un conjunto de tipos predefinidos bsicos de uso comn. En las siguien-
tes secciones de este subapartado se ver cmo definir nuevos tipos y se dar una
clasificacin de los tipos predefinidos mostrando las caractersticas de cada tipo.
2.4.3.1. Declaracin de tipos de datos
La declaracin de un tipo de datos es la sentencia VHDL utilizada para introducir

un nuevo tipo. Bsicamente, la informacin necesaria para declarar un nuevo tipo
estar formada por un identificador de tipo que servir para referenciarlo y la des-
cripcin del conjunto de valores que forman el tipo de datos. Concretamente, la sin-
taxis VHDL para declarar un tipo ser:
type identificador la definicin_tipo;
La parte de definicin de tipo sirve para indicar el conjunto de valores del tipo.
Puede tener varios formatos, que se vern en detalle a medida que se expliquen los
diferentes tipos predefinidos del lenguaje. A continuacin 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 podran 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 dems tipos, aun cuando las defi-
niciones sean idnticas. 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 explcitamente una funcin de conver-
sin de tipo para que la asignacin 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 funcin DiaMes_DeJa3J (las
funciones se describen ms adelante en este captulo):
Ntunero := DiaMes_Dela31(DiasEnero);
2.4.3.2. Tipos de datos escalares

Los tipos de datos escalares son aquellos cuyos valores estn formados por una sola
unidad indivisible. Existen tipos de datos escalares predefinidos de distintas clases,
concretamente tipos enteros, tipos reales, tipos fsicos y tipos enumerados. Los ti-
pos reales son continuos en el sentido que dentro de un intervalo existen un nmero
infinito de valores, por esta razn, como no es posible representar todos los nme-
ros, se tiene que escoger un conjunto de nmeros representables de manera que
cualquier valor se deber redondear al nmero representable ms prximo produ-
cindose 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 ms a la izquierda del tipo. A continuacin se detallan las ca-
ractersticas ms 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 nmeros enteros y reales respectivamente. El lenguaje
estndar 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 mnimo de seis dgitos de-
cimales, aunque alguna implementacin VHDL pueda ampliar estos rangos. Como
normalmente no sern 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 ordenacin que tendrn los valores dentro del tipo. Por de-
fecto, un objeto de tipo entero o real se inicializa al valor ms a la izquierda de los
que forman el tipo, que en este caso coincide con el primer literal del rango.
A continuacin 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 fsicos

Los tipos fsicos sirven para representar medidas del mundo real como pueden ser
distancia, tiempo o peso. Por esta razn, adems de un literal numrico llevan aso-
ciada una unidad primaria de la medida fsica que quieren cuantificar. Tambin se
pueden definir unidades secundarias mltiplos de la unidad primaria para poder uti-
lizar, en cada momento, la unidad ms adecuada segn el valor que se quiera repre-
sentar. La sintaxis VHDL para declarar un tipo fsico es la siguiente:
type identificador is ranga literal to I downto literal

units
identificador;
{ identificador = literal_fsico:
end units [identificador];
El identificador es el nombre que recibe el tipo fsico y sirve para referenciarlo.

El rango determina el valor mnimo y mximo de unidades primarias del tipo fsico.
Esta unidad primaria debe ser menor que las unidades secundarias, para las que se
tendr que indicar el nmero de unidades primarias que contienen mediante el lite-
ral fsico asociado. Este valor puede especificarse directamente en funcin de la
unidad primaria o mediante una unidad secundaria previamente declarada.
Se puede definir un tipo fsico para cualquier medida fsica que se quiera cuan-
tificar. Probablemente, el tipo fsico ms comn en VHDL es el tipo time (tiempo),
declarado en el paquete standard de la biblioteca std, que sirve para especificar re-
tardos. La declaracin del tipo time sera:
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;
ritn = 60 sec;
hr = 60 minr
end units;
Internamente VHDL considera los tipos fsicos como enteros con una unidad
primaria asociada, por lo que cualquier valor fsico que contenga un literal real ser
redondeado a un nmero entero de unidades primarias. Por ejemplo, los tres litera-
les siguientes sern equivalentes:
4.3211 ps 4.321 ps 432'1 fs
En el primer caso se perder el ltimo dgito decimal al redondear el valor a

femtosegundos, por consiguiente, la conclusin es que cuanta ms precisin quiera
obtenerse menor deber ser la unidad primaria.
Finalmente, aunque se dedicar un subapartado especfico para hablar de los
operadores del VHDL, debe destacarse que la aplicacin de operadores a los tipos
fsicos es bastante especial. La suma y la resta de dos valores de un tipo fsico darn
como resultado un valor del mismo tipo. Por otra parte, la multiplicacin ser dife-
rente, ya que, por ejemplo, al multiplicar dos distancias no se obtiene una distancia
sino un rea. VHDL no soporta la multiplicacin directa de tipos fsicos, lo que se
tendr que hacer es convertir cada valor a un entero, efectuar la multiplicacin y
posteriormente convertir el resultado a un tipo fsico llamado rea. En cambio, la
multiplicacin y la divisin entre tipos fsicos y nmeros reales o enteros estar per-
mitida y el resultado ser del tipo fsico, o la divisin de dos valores fsicos 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 carcter {, ... } );
El primer identificador es el nombre del tipo y servir para referenciarlo. Entre

parntesis y separados por comas se especifican todos los valores del tipo. Como
mnimo debe indicarse un valor. A continuacin 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 podran declarar objetos de estos tipos:
variable ComandoActual : Comandos := abajo;
variable TeclaActual : Teclas := 'a';
Un objeto de tipo enumerado se inicializa por defecto al valor ms a la izquier-

da de los que aparecen en la definicin del tipo. Por lo tanto, la inicializacin 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 comn. Concretamente el tipo carcter, el tipo booleano y el ti-
po bit. El tipo carcter no es ms que una enumeracin 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 evaluacin 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 elctricas de las seales. Por esta razn 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 seales de forma ms adecuada. Dicho paquete
adems define los operadores para trabajar con objetos de este tipo. La definicin
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 dbil
, 'L', '. - Cero dbil
.~W~ - Uno .dbil
, - , ); - Redundante
El paquete std_logic_1l64 suele estar almacenado en una biblioteca llamada

IEEE y no forma parte del lenguaje VHDL, por esta razn ningn modelo puede
utilizar el tipo de datos std_ulogic directamente. Los modelos que quieran usar este
tipo de datos tendrn que contener las sentencias necesarias para obtener la visibili-
dad a este paquete, concretamente al inicio debern incluir:
library IEEE;
use IEEE.std_logic_1164.all;
Finalmente destacar que algunos literales forman parte de ms de un tipo de

datos enumerado. Por ejemplo, el carcter 'O' est incluido en los tipos de dato ca-
rcter, 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
explcitamente el tipo de datos del literal para evitar confusiones, es lo que se cono-
ce como calificacin de tipo:
character+ ('.o'), bit' ('O') , std_ulogic' ('O')
No debe confundirse la calificacin de tipos con la conversin de tipos. En el

primer caso slo se especifica de qu tipo es un literal para evitar confusiones,
mientras que en el segundo se aplica una funcin para modificar el tipo original del
literal.
2.4.3.3. Declaracin 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 tomarn valores de un subconjunto de los valores del tipo,
de modo que nunca contendrn ciertos valores concretos. Para esta situacin,
VHDL proporciona el subtipo, que asocia una restriccin 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 slo podrn 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 ms tarde. A

continuacin hace falta especificar el tipo base para el que se define el subtipo y la
restriccin 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 restriccin 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 nmeros posi-
tivos y naturales respectivamente. La definicin de estos subtipos sera 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 ms grande.
A continuacin se dan algunos ejemplos ms 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 operacin. 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 operacin. De todos modos, en caso que se tenga que asignar el resultado
a un objeto del subtipo, este resultado tendr que cumplir la restriccin 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 simulacin. 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 implcitamente 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 explcitamente.
2.4.3.4. Tipos de datos compuestos
Los tipos de datos compuestos son aqullos cuyos valores se pueden dividir en uni-
dades atmicas ms pequeas. Existen dos tipos compuestos bsicos: los vectores y
los registros. Los primeros estn compuestos por unidades atmicas del mismo tipo
mientras que los segundos son heterogneos en el sentido que estn formados por
un conjunto de objetos diferentes. Al declarar un objeto de tipo compuesto, cada
uno de sus elementos se inicializar por defecto segn las reglas que correspondan
a su tipo. En este subapartado se van a repasar las caractersticas 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 ms
ndices que indican la posicin de cada objeto dentro del vector. El nmero de ndi-
ces determina la dimensin del vector, para vectores que tengan un solo ndice se
hablar de vectores unidimensionales o simplemente vectores, en cambio los vecto-
res con ms de un ndice sern vectores multidimensionales o matrices.
Para declarar un vector se tendr que crear un tipo que bsicamente determine
el tipo de los objetos que formarn 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 explcitamente en la declaracin o bien se puede dar directamente un
nombre de tipo o subtipo que ya incluya una restriccin de rango y finalmente el ti-
po indicar el conjunto de valores posibles que pueden tomar los objetos del vector.
A continuacin 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 seales. Por ejemplo, se podran
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 sern vectores compuestos por un conjunto

de elementos atmicos y ser posible operar con todo el vector a la vez o con cada
elemento individualmente identificndolo mediante el ndice. Por ejemplo, se po-
dran realizar las siguientes operaciones de asignacin:
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 slo cuatro elementos (del 3 al 7).
De la misma forma que se acaba de ver cmo declarar y utilizar los vectores
unidimensionales, se trabajara con los vectores multidimensionales. Por ejemplo,
se podra 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 podra 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 construccin que permita asignarlos todos a la vez. Por esta ra-
zn VHDL proporciona el agregado que permite escribir un vector de literales que
se podrn asignar simultneamente a los elementos de un vector. La sintaxis del
agregado es la siguiente:
( [ posicin { I ...} => 1 literal t. "':.. }J
Es decir, se trata de una lista de literales separados por comas y encerrada entre
parntesis. Existen dos modalidades de agregados, en la primera se indica la posi-
cin de cada literal dentro del vector y en la segunda se omite esta posicin, de ma-
nera que el orden viene determinado por la ordenacin 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 continuacin se pueden declarar los siguientes objetos:
constant OrigEm : Punto ::;: {O.O, 0.0, 0.0);

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

ha omitido la posicin 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 podra utilizar cualquiera de las siguientes opciones,
todas ellas seran 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 an 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 asignacin.
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 nmero de elementos que tendr el vector y las caractersticas de los n-
dices que van a utilizarse. Adems 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 ningn 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 podra declarar el tipo siguiente:

type VectorReales is array ( natural range <> ) of real;
A continuacin se podran 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-
claracin de cada uno de estos tipos sera 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 continuacin se muestra cmo se declararan 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 atmicas de distinto tipo, que reciben el nombre de campos. Por
esta razn, 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 ms

tarde. A continuacin slo hace falta especificar todos los campos del registro asig-
nndoles un tipo.
Por ejemplo, se podra 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 tambin agregados con la
lista de literales que se quieran asignar. En este caso no tiene sentido indicar la posi-
cin 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-

rn literales de distintos tipos.
2.4.3.5. Otros tipos de datos

En este subapartado del captulo 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 tamao del conjunto de
datos que se debe almacenar, ya que este tamao debe especificarse en la declara-
cin de sus objetos. En algunas aplicaciones este tamao puede ser desconocido o
dependiente de cada ejecucin, por esta razn, al igual que cualquier lenguaje de
programacin comn, VHDL proporciona apuntadores para crear estructuras de da-
tos dinmicas, estos apuntadores se conocen como tipos de acceso. Estos tipos de
datos no suelen usarse muy a menudo, en todo caso, normalmente se utilizarn
cuando se modele a alto nivel de abstraccin.
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 declaracin 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-
bira:
type ApuntaEnteros is access integer;
A continuacin se podra 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 tamao 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 implcito deallocate que VHDL crea automti-
camente cada vez que se declara un tipo de acceso:
deallocate (Entex::.o~!;
Para definir estructuras ms complejas, como, por ejemplo, una lista encadena-
da, basta con definir un tipo registro que contenga algn 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 ms

tarde. Aparte de este identificador slo 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 escribira:
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 lnea a fichero y operaciones para aadir y sa-
car datos de la lnea sobre objetos de diferentes tipos, se puede trabajar fcilmente
con estos ficheros.
Aunque los procedimientos se vern en el apartado dedicado a subprogramas, a

continuacin 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 ms que en la sintaxis. Concretamente para leer y escri-
bir un objeto de tipo lnea se puede utilizar:
procedure readline (file f : text; 1: out 1ine)

procedure writeline (file f : text; 1: inout line)
readline volcar la lnea actual del fichero sobre una variable de tipo lnea y avan-
zar el puntero del fichero sobre la lnea siguiente, mientras que writeline grabar la
variable de tipo lnea sobre el fichero y inicializar dicha variable.
Para poder trabajar con las variables de tipo lnea el paquete textio tambin
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 lnea y escribir en varia-

bles de este tipo respectivamente. El parmetro value puede ser de cualquier tipo
predefinido, de modo que se pueden volcar palabras de una lnea sobre variables de
cualquier tipo y tambin se pueden aadir valores de cualquier tipo a una lnea.
Los ficheros de texto se utilizan a menudo para almacenar los estmulos que se
van a aplicar al circuito y para grabar los resultados obtenidos para poder ser anali-
zados despus de la simulacin.
Ejemplo:
La entidad Sumador recibe operandos enteros en sus dos entradas y devuelve la su-
ma de estos operandos en su salida. La declaracin 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 funcin 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 lgica es pensar que Sumador es un componente de esta
arquitectura. Trabajando de esta manera, BancoPruebas no requerir ninguna co-
municacin con el exterior, por lo que la declaracin de la entidad ser la siguiente:
entity BancoPruebas is
end;
Por lo que a la arquitectura se refiere, bsicamente 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 vern en los prximos apartados de este captulo, por lo que si este
ejemplo no queda claro en este momento, tal vez se comprenda completamente
cuando se acabe de leer el Captulo 2. La arquitectura final de BancoPruebas sera
la siguiente:
library IEEE;
use std.textio.all;
architecture Funci9nal 9f BncoPruebas 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 estmulos 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(Resltados, 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 lnea
y los procedimientos comentados anteriormente, tambin define otros procedimien-
tos como la funcin endfile para detectar el final del fichero. Otra cuestin 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 captulo, la asignacin a una seal no se produce
inmediatamente sino que primero se requiere la suspensin 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 debera ser como mnimo el retardo que necesita el componente Sumador para
generar la salida Suma. En principio, a partir de la arquitectura del componente se
puede determinar cul es este tiempo mnimo, en el ejemplo se ha supuesto que 100 ns
son suficientes.
2.4.4. Expresiones y operadores
Se puede considerar que una expresin es una frmula que indica la forma como
debe calcularse un valor. Para hacerlo, se dispone de una serie de operadores ms
unos elementos que actan como operandos. Estos elementos suelen ser bsicamen-
te literales, identificadores, atributos que determinen un valor, calificaciones y con-
versiones de tipo y parntesis para especificar un orden de precedencia. Por lo que a
los operadores se refiere, VHDL tiene predefinidos los operadores aritmticos, rela-
cionales, lgicos y de concatenacin de cualquier lenguaje de programacin comn
ms los operadores de desplazamiento para vectores unidimensionales que fueron
aadidos en VHDL-93.
En la Tabla 2-1 se muestran todos los operadores predefinidos de VHDL orde-
nados decrecientemente segn 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 segn su precedencia
Op. Descripcin Tipo operandos Resultado
** potencia entero op entero entero

real op entero real
abs valor absoluto numrico dem operando
no! negacin bit, booleano, vector bits dem operando
* multiplicacin entero op entero entero
real op real real
fsico op entero fsico
fsico op real fsico
entero op fsico fsico
real op fsico fsico
divisin entero op entero entero
real op real real
fsico op entero fsico
fsico op real fsico
fsico op fsico entero
mod mdulo entero op entero entero
rem resto entero op entero entero
+ ms unario numrico dem operando
menos unario numrico dem operando
+ suma numrico op numrico dem operandos
resta numrico op numrico dem operandos
& concatenacin vector op vector vector
vector op elemento vector
elemento op vector vector
elemento op elemento vector
sil despl. lgico izq. vector bits op entero vector bits
srl despl. lgico 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 rotacin izquierda vector bits op entero vector bits
ror rotacin 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 lgica bit, booleano, vector bits op bit, booleano, vector bits dem operandos
or o lgica bit, booleano, vector bits op bit, booleano, vector bits dem operandos
nand y lgica negada bit, booleano, vector bits op bit, booleano, vector bits dem operandos
nor o lgica 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 caracterstica, 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 nmero ilimitado de de-
finiciones de un operador, la nica condicin 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 habra forma de saber a qu operando se est
haciendo referencia.
2.4.5. Atributos
Un atributo es una caracterstica 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 adems
de permitir la definicin 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 presentarn los atributos prede-

finidos del lenguaje y a continuacin se mostrar la forma cmo un diseador 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 Descripcin
A'left(n) Valor izquierdo del ndice n de A.

A'right(n) Valor derecho del ndice n de A.
A'low(n) Valor mnimo del ndice n de A.
A'high(n) Valor mximo 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) Nmero de valores del rango n de A.
tipo de atributos proviene de la palabra inglesa array, que significa vector. La inclu-
sin de la dimensin 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 especficos para cada tipo de datos, ya que se obtienen modelos ms generales
que facilitan la actualizacin del cdigo. Por ejemplo, si se considera el siguiente
cdigo:
type Palabra: bit_vector(O te 7);

signal Dato : PU~:r;il.i
process (Dato]
begin
for i in O te 7 loop
if Dato(i) - ...
end loop;
end process;
Un cambio en el nmero de bits por palabra obliga a modificar la declaracin

del tipo palabra, as como de cualquier parte del cdigo que haga referencia a este
parmetro, como el bucle del ejemplo (los bucles se vern en el siguiente apartado
de este captulo). En cambio, este mismo cdigo se podra 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-
cacin en el bucle que, al utilizar el atributo range, ya refleja este cambio automti-
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 numricos, booleanos o cadenas de caracteres. Los
atributos pos, val, succ, pred, leftof y rightof se pueden aplicar solamente a tipos
discretos y fsicos, ya que, por ejemplo, no tiene mucho sentido determinar el n-
TABLA 2-3. Atributos predefinidos para tipos de datos
Atributo Descripcin
T'base Tipo base de T.

T'left Valor ms a la izquierda de T.
T'right Valor ms a la derecha de T.
T'low Valor mnimo de T.
T'high Valor mximo de T.
T'ascending Verdadero si T tiene rango ascendente.
T'image(x) Representacin textual del valor x de tipo T.
T'value(x) Valor expresado por la cadena de caracteres.
T'pos(x) Posicin ocupada por x en T.
T'val(x) Valor de la posicin x en T.
T'succ(x) Valor de la posicin siguiente a x en T.
T'pred(x) Valor de la posicin anterior a x en T.
T'leftof(x) Valor de la posicin derecha a x.en T.
T'rightof(x) Valor de la posicin 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 seales
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 seal.
TABLA 2-4. Atributos predefinidos para seales
Atributo Descripcin
S 'delayed(t) Seal S retrasada t unidades de tiempo.

S 'stable(t) Seal booleana verdadera si S es estable hace t unidades de tiempo.
S'quiet(t) Seal booleana verdadera si no ha habido ninguna asignacin a S en
t unidades de tiempo.
S 'transaction Seal de tipo bit, vale' l' cuando hay asignacin a S.
S'event Verdadero si ocurre un evento en S.
S'active Verdadero si ocurre una asignacin en S.
S 'last_event Unidades de tiempo desde el ltimo evento.
S 'last_active Unidades de tiempo desde la ltima asignacin 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 seal, mientras que los dems atributos siempre devuelven un valor de un tipo
de datos, los ms comunes son el tipo fsico 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 asignndole 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 estticos, es decir,
constantes.
La sintaxis VHDL para declarar un atributo es la siguiente:
attribute identificador : tipo_datos;
Mientras que la sintaxis para la especificacin del atributo es:

attribute identificador of id_elemento.: clase_elemento is expresin;
El identificador del elemento sirve para determinar el elemento especfico 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 seal, 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 cdigo 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 diseo. Por otra parte, la nica condicin que debe
cumplir la declaracin de un atributo es que sea anterior a su especificacin, por lo
que muchas veces se incluyen todas las declaraciones de atributos en un paquete.
A continuacin se dan algunos ejemplos de definicin de atributos aplicados a
elementos de diferentes clases. En primer lugar, se podra definir un atributo que in-
dicara el nmero de pin que se va a utilizar para una determinada seal:
signal Reloj : stQ_logic;
attribute NumeroPin : natural;
attribute NumeroPin of Reloj : signal is 5;
Tambin se podran 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 tambin podran tener
un atributo para determinar su codificacin:
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 asignacin (a seal 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 ejecucin 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 reactivacin. La sintaxis general de la sentencia
wait es:
[etiqueta: 1 wait [en seal (,..})
[untll expresin_booleana)
[for expresion_tiempo)
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin

2.5.13.
Veamos cmo 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 ningn tipo
de condicin para despertar al proceso. Esto significa que el proceso en cuestin
ejecutar las sentencias que contenga hasta el wait y entonces se suspender, sin
que pueda volver a activarse en toda la simulacin. El uso ms comn 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
continuacin se termina la simulacin. 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 seales ser sensi-

ble el proceso (wait on lista_seales). Por lo tanto, siempre que se produzca un
evento en alguna de las seales 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 lgica 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 tambin puede fijarse una condicin para su reactiva-
cin, esta condicin se especifica con la forma wait until condicin_booleana. En
condicin_booleana puede aparecer cualquier expresin que al evaluarse de como re-
sultado TRUE o FALSE. Un ejemplo tpico 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 adems Reloj pase a valer' 1'. Si al llegar a
esta sentencia wait, Reloj ya valiese '1', entonces el proceso no se reactivara, ya
que debe cumplirse que haya un evento en la seal adems de cumplirse la condi-
cin 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 opcin de la sentencia wait para generar un reloj de un
determinado periodo.
process
begin
Reloj <= not Relj;
wait for 10 na;
end process;
Cada vez que el proceso se suspenda, se fija su reactivacin para 10 ns ms 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 reactivacin de un proceso ms 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 adems se cumpla la condicin c='] '. El proceso slo es sensible a las seales a o
b, de forma que un evento sobre la seal 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 simulacin avance 10 ns. Despus de este tiempo, y
aunque no se produzca ningn evento en las seales a o b, el proceso ser reacti-
vado.
2.5.2. Asignacin a seal
La asignacin a seal como sentencia secuencial (dentro de un proceso o del cuerpo

de un subprograma) presenta la siguiente sintaxis en su forma ms sencilla:
[etiqueta ; 1 nombre_seal <= valor {after expresion_tiempo}

2.5.13.
Recordemos que las seales en VHDL son objetos que consisten en un valor
actual (el que en cada momento pueden leer los procesos que son sensibles a dicha
seal) y un conjunto de pares tiempo valor, que forman la historia futura de la seal
o cola de eventos de la seal. Recordemos tambin que incluso en el caso de ejecu-
tar una asignacin a seal sin especificacin alguna de retardo, la asignacin del
nuevo valor no se producir hasta pasado un retardo delta. En definitiva, antes de
pasar a estudiar con ms detalle las opciones de la asignacin a seal, debe quedar
claro que al ejecutarse una de estas sentencias, no se est modificando el contenido
de la seal, 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 seal, que algunas
veces puede no llegar a producirse.
Para dejar claro este comportamiento de la asignacin a seal (que al principio
parece extrao al compararlo con la asignacin a variable), veamos un ejemplo que
nos ayude a entender mejor su funcionamiento. Supongamos que queremos in-
tercambiar el contenido de dos seales, para ello podemos escribir el siguiente pro-
ceso:
process
begin
a <= b;
b <= a;
wait on a, b;
end process;
Estas dos sentencias de asignacin consiguen intercambiar el valor de las dos

seales, ya que cuando se ejecuta la segunda (b<==a), el valor de la seal a an no
refleja la asignacin b-cea, ya que sta slo ha proyectado un posible cambio en la
cola de eventos de a. No ser hasta la suspensin del proceso (ejecucin de la sen-
tencia wait) cuando las seales a y b tomen el valor que se ha proyectado en su cola
de eventos.
La forma en que se comporte la asignacin a seal depender bsicamente 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
duracin inferior a un mnimo. Buscando analogas con el mundo fsico, el modelo
de transporte es el que refleja una lnea de transmisin ideal, mientras que el mode-
lo inercial es el que rige el comportamiento de una puerta lgica.
Por defecto, VHDL supone que las asignaciones a seal siguen el modelo iner-
cial, para usar el modelo transporte debe especificarse en la asignacin, utilizando
la siguiente sintaxis:
nombre_seal <= [transport] valor [after expresion_tiempo]
Veamos algunos ejemplos que nos aclaren las diferencias entre la asignacin
con modelo transporte y modelo inercial. En primer lugar veamos el modelo trans-
porte, que es ms intuitivo.
Al producirse una asignacin a seal con el modelo de transporte, sta proyecta
nuevos valores en la cola de eventos de la seal, 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 aade 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;
Despus de la ejecucin 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 asignacin, se eliminar de la cola de

eventos el valor que haba 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 asignacin a seal 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 asignacin 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 seal 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. Evolucin 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 asignacin proyectada para el tiempo anterior. Repitiendo los dos
ejemplos anteriores para retardo inercial (no se especifica transport en la asigna-
cin) tenemos:
process
begin
s <= 'o' after 10 DS;
S <= '1' after 20 DS;
wait;
end process;
En este caso la asignacin de '1' en el tiempo 20 ns elimina de la cola de even-

tos de s la proyeccin 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. Evolucin de la cola de eventos. Modelo inercial.

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

la segunda asignacin elimina el valor que la primera haba proyectado sobre la co-
la de eventos de la seal (Figura 2-8-b).
Por ltimo destacar que existe una variacin de la sentencia de asignacin que
permite especificar en una nica sentencia un conjunto de pares tiempo/valor que
deben proyectarse sobre la cola de eventos de la seal. La sintaxis de esta varia-
cin es:
seal <= [ 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 asignacin genera una serie de cambios sobre la seal 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 asignacin a seal secuencial
es que ampla 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 opcin de rechazar se puede especificar para qu valores de
tiempo (qu anchuras de pulso) se debe rechazar una transicin sobre una seal. Pa-
ra ms detalles sobre el comportamiento de esta opcin, consultar [A95][BFMR93].
2.5.3. Asignacin a variable
La asignacin a variable reemplaza el valor actual de la variable con el valor espe-

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

2.5.13.
A diferencia de la asignacin a seal vista en el apartado anterior, la asignacin
a variable no tiene ningn 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 continuacin 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 despus 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 slo es visible en

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

un proceso o en un subprograma, ya que en este caso la variable ser local a dicho
proceso o subprograma.
La asignacin a variable compartida tiene la misma sintaxis que la asignacin 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 simulacin ya no es determi-
nista, sino que depende del orden de ejecucin de los procesos.
2.5.4. La sentencia if
La sentencia if se utiliza para escoger en funcin de alguna condicin qu senten-
cias deben ejecutarse. En su forma ms simple nos permite ejecutar un conjunto de
sentencias en funcin de una condicin, en su forma ms general permite decidir
entre varios conjuntos de sentencias a ejecutar, cada uno de ellos en funcin 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 seleccin deben ser booleanas, es decir, deben retornar el

valor TRUE o FALSE como resultado de la evaluacin de la expresin que consti-
tuye la condicin.
La forma ms sencilla en la que podemos utilizar la sentencia if es la evalua-

cin de una nica condicin que permite o no la ejecucin de una instruccin (o de
un conjunto de ellas). Como ejemplo veamos el modelo de un biestable por nivel
(Latch) con entrada de datos (Dato) y seal de carga (Carga). Utilizaremos un pro-
ceso con una sentencia if con el propsito 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 seales Dato y Carga; por lo tanto, cada
vez que haya un evento en alguna de ellas se ejecuta. En ese caso a la seal Biestable
slo se le asigna el valor que contenga Dato si la seal de carga vale '1'. En otro ca-
so la asignacin 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 condicin; en caso que la condicin se cum-
pla, se ejecutar el primer grupo, en caso contrario se ejecutar el segundo grupo.
Un ejemplo tpico del uso de esta sentencia if se puede encontrar en el modelado de
un buffer triestado. Si la seal de habilitacin 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-Ioqcr
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 ms con-

juntos de sentencias a ejecutar, cada una de ellas en funcin de distintas condicio-
nes. Como ejemplo podemos ampliar el biestable anterior, y modelar un biestable
que tenga una seal de inicializacin (Iniciar). Dejamos como ejercicio para el lec-
tor la modificacin de la entidad correspondiente, a la que debe aadirse 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 condicin (Ini-

ciar= 'O') se colocar el valor 'O' sobre la seal Biestable. Slo si no se cumple la
primera condicin se considerar la segunda, y en caso que sta sea cierta (TRUE)
se asignar Dato a Biestable. Obsrvese 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 condicin son prioritarias sobre el grupo de sentencias depen-
dientes de la segunda condicin, ya que si la primera se cumple, el segundo grupo
no se ejecutar aun cuando su condicin de control fuese cierta.
Esta ltima forma de la sentencia if, que permite escoger entre distintos grupos
de sentencias a ejecutar dependiendo de una condicin de ejecucin para cada uno
de ellos, puede ampliarse aadiendo 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, basndose en el rango de valores de una deter-
minada expresin de seleccin. sta puede ser de cualquier tipo discreto (enumera-
dos o enteros) o de tipo vector de una dimensin. 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 tpico 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 seal de seleccin 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-

nacin simple, en cada opcin 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 expresin
de seleccin, se ejecutan las sentencias que se encuentre en esa seccin de la sen-
tencia case y se ignoran las dems.
Los valores especificados para la seleccin en la sentencia case deben cumplir
dos condiciones. La primera es que nunca puede haber una interseccin entre el
rango de valores especificados en dos opciones distintas de la sentencia case. La se-
gunda es que la unin de todos los valores especificados debe cubrir todos los valo-
res posibles que pueda tomar la variable de seleccin.
Ya que es una sentencia especializada en seleccionar entre un determinado con-
junto de valores, ofrece unas opciones en cuanto a la especificacin del rango de di-
chos valores, destinadas a facilitar la seleccin.
Se puede especificar dos o ms valores dentro del rango de posibles valores
que puede tomar la expresin de seleccin usando la unin lgica, para la cual se
usa el signo "1". De esta forma se puede expresar la unin lgica de distintos valores
del rango con la expresin 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-
ficacin "00" y "al" seleccionen la misma salida, podramos 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 expresin de

seleccin que en este caso deben tomar valores discretos (enteros o enumerados).
Para ello se puede usar la partcula 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 seal de seleccin 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 seleccin la palabra clave

others, cuando en una sentencia case aparece esta opcin, 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 ejecutarn las sentencias que se encuentren en di-
cha opcin. 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 Seleccin, Entrada!, Entrada2;
end process;
Es muy habitual el uso de la clusula others en la ltima opcin de la senten-

cia case debido a que todos los posibles valores de la seal de seleccin deben
quedar cubiertos. De hecho, para el primer ejemplo del multiplexor, se ha definido
que la seal de seleccin (Seleccion) es de tipo bit_vector, de forma que los valo-
res "00", "O1", "10" y "11" cubren todas las posibilidades. Si la seal Seleccion
fuese de tipo std_logic_vector, debera aadirse la clusula 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 nmero de repeticiones puede controlarse en la misma sentencia
usando alguna de las opciones que sta ofrece. Su sintaxis general es:
{etiqueta]: [while condconboolesna I for cont.r6L.iepticion] 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 ningn tipo de control sobre el nmero de
repeticiones del bucle, de forma que se provoca la ejecucin infinita del grupo de
sentencias secuenciales especificadas. Aunque en principio pueda parecer no muy
adecuada la definicin de un bucle infinito en la descripcin de un componente, s-
te puede tener sentido al modelar un dispositivo para el cual queremos fijar unos
valores iniciales, mediante la ejecucin de unas sentencias, para luego pasar a eje-
cutar el conjunto de sentencias que lo modelan de forma indefinida. Aunque no sea
el ejemplo idneo (ya que dada su sencillez se puede modelar de forma ms elegan-
te sin recurrir a la sentencia loop), podemos usar este esquema para modelar un
contador de cuatro bits (mdulo 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 simulacin se ejecutar la sentencia de inicializacin del conta-

dor, despus 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. Ntese que
una sentencia loop que no est limitada por alguna condicin de final del bucle de-
be contener alguna sentencia wait en la parte de sentencias secuenciales, de otra
forma nunca sera posible avanzar el tiempo de simulacin.
Se puede definir una condicin de finalizacin del bucle con la opcin while
condicion booleana. En este caso el grupo de sentencias secuenciales especificadas
en la sentencia loop se ejecutarn mientras la condicin sea cierta, cuando la condi-
cin sea falsa se abandonar el bucle para pasar a ejecutar las sentencias que apa-
rezcan a continuacin. Como ejemplo podemos modificar el proceso que modela el
contador anterior sin usar la funcin 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 condicin de final del bucle y, por
lo tanto, pasa a ejecutarse la primera sentencia que se encuentre despus de la sen-
tencia loop, de forma que se carga el contador con el valor o.
Otra forma de controlar el nmero de iteraciones de la sentencia loop se deriva
del uso de la opcinfor control_repeticion. sta nos permite controlar el nmero de
repeticiones, dependiendo del rango de valores que pueda tomar la expresin 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 expresin 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 inicializacin 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 ejecucin 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 acompaada de dos opciones. La primera permite
expresar una condicin, en caso que sta se cumpla se finaliza la ejecucin de la
sentencia loop y se pasa a ejecutar la primera sentencia que se encuentre a continua-
cin. La segunda opcin permite especificar la etiqueta de una sentencia loop con-
creta, de forma que el bucle que finaliza su ejecucin 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 mdulo 16 de for-
ma que tenga una seal de inicializacin (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;
lOp
wait until (RSloji:'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 inicializacin del contador.
Obsrvese que en la sentencia wait se ha especificado explcitamente qu reloj de-
ba ser' l' Ydeba tener un evento. Esto se debe al hecho que al usar la opcin until
especificando diversas condiciones, cada seal que aparece en las distintas condi-
ciones pasa a formar parte de la lista de sensibilidad. De forma que podra darse el
caso que un cambio de 'O' a' l' de Inicio coincidiendo con que la seal 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 aadiendo una seal de carga de datos. Dejamos como ejercicio para el lector
la modificacin de la entidad del contador, en la que debe aadirse 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 Contdor <= 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 seal de carga est activa. La primera sentencia
exit interrumpe la ejecucin del bucle externo cuando se activa la seal Inicio (acti-
va a baja), de forma que se ejecuta la sentencia Contador <= O hacindose efectiva
la inicializacin. La segunda sentencia exit termina la ejecucin 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 seal de carga siga activa.
Obsrvese que por el orden como se han especificado las dos sentencias exit, la
seal de Inicio tiene prioridad sobre la seal de carga de datos, adems la inicializa-
cin del contador es asncrona mientras que la carga de datos es sncrona (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 ejecucin de una sentencia loop y pasar a la siguiente iteracin 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 condicin para la
cual debe pasar a ejecutarse la siguiente iteracin de la sentencia loop y tambin
puede especificarse una etiqueta haciendo referencia a qu sentencia loop debe rea-
lizar ese salto de una iteracin. Para ejemplificar el uso de la sentencia next, pode-
mos modificar nuestro contador mdulo 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 iteracin, 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 condicin
de salto de iteracin.
2.5.9. La sentencia assert

La sentencia assert permite reportar mensajes en funcin de si una determinada
condicin se cumple o no, tambin permite interrumpir la simulacin en funcin de
dicha condicin. 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 simulacin. Funciona de la siguiente forma, en caso de no cumplirse
la condicin, se enva la cadena de caracteres especificada al dispositivo estndar
de salida, y dependiendo del nivel de severidad indicado se puede interrumpir la si-
mulacin.
La forma ms simple de la sentencia no usa la opcin de report ni la opcin de
severidad; en este caso, si no se cumple la condicin el mensaje enviado a la salida
es "Assertion violation", De todas formas, debido a la escasa informacin que ofre-
ce este mensaje, lo habitual es aadir la opcin de report para dar mensaje ms sig-
nificativo.
El valor de la expresin 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 mayora de simuladores dejan fijar al usuario para cul
de estos valores (en caso de no cumplirse la condicin de la sentencia assert) debe
interrumpirse la simulacin (no se fija en el estndar el valor de interrupcin de la
simulacin). En caso de no especificar el nivel de severidad, el defecto es error.
Un ejemplo tpico del uso de la sentencia assert puede ser la comprobacin 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 mnimo de anchura de pulso del reloj es de 5 ns. Para este
ejemplo necesitamos usar la funcin now (definida en el paquete standard) que re-
toma el tiempo actual de simulacin.
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 seal 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 continuacin guarda en la va-
riable Inicio_Pulso el tiempo de simulacin 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 condicin de la sentencia assert no se cumple y, por lo
tanto, se enva el correspondiente mensaje a la salida estndar; para este tipo de vio-
lacin se ha escogido warning como nivel de severidad.
VHDL-93 ofrece una variacin de la sentencia assert: la sentencia reporto Su
sintaxis es:
report cadena_caracteres {expresin severidad]
La diferencia principal con la sentencia assert consiste en que no necesita com-

probar ninguna condicin, al ejecutarse siempre se enva el mensaje al dispositivo
estndar de salida (en este aspecto es equivalente a una sentencia assert con la con-
dicin forzada a falso). Tambin vara 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 variacin aparece con el nimo de proporcionar una sentencia
que permita reportar mensajes en la simulacin de forma ms cmoda, en caso que
stos no dependan de ninguna condicin.
2.5.10. Llamada secuencial a subprogramas
Los subprogramas (procedimientos o funciones) que tengamos definidos en alguna

parte del cdigo (tal como se explica en la seccin 2.7) pueden ser llamados para su
ejecucin en cualquier parte de un cdigo 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 funcin (function) es:
nombre_funcion [{parametros} 1
La diferencia radica en que una llamada a funcin forma parte de la expresin

de una asignacin o es la asignacin 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 instruccin secuencial en cuanto finalice su
ejecucin.
2.5.11. La sentencia return
La sentencia return se utiliza para terminar la ejecucin 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
expresin alguna, la opcin de una expresin acompaando a la sentencia return
est reservada a las funciones.
Al ejecutarse esta sentencia secuencial se retorna el control del programa a la
instruccin siguiente a la que realiz la llamada. Adems, en una funcin esta sen-
tencia se utiliza para retornar el resultado de la ejecucin de la funcin.
2.5.12. La sentencia null
Esta sentencia se usa para indicar que no se debe realizar ninguna accin. Su sinta-
xis general es:
[etiqueta :J null;

2.5.13.
Un ejemplo tpico 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 seleccin, pero en muchos casos no para todo el rango es necesario realizar algu-
na accin. Pongamos por ejemplo una sentencia case que se utiliza para calcular el
mdulo 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 funcin 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 tenan
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 implementacin, y la mayora de ellos diri-
gidos a sntesis. 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 simulacin, el uso de etiquetas en sentencias secuencia-
les no aporta ventajas significativas, aparte de permitir mejorar la documentacin
en algunos casos.
2.6. SENTENCIAS CONCURRENTES
En los siguientes apartados se presentarn las sentencias concurrentes del VHDL.

La caracterstica comn a todas ellas es que se ejecutan en paralelo. Principal-
mente las encontraremos en las arquitecturas de los modelos y no estarn conteni-
das en ningn 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 descripcin de la estructura
del diseo.
2.6.1. La sentencia process
Un proceso es una sentencia concurrente que define su comportamiento a travs de

sentencias secuenciales. Cualquier sentencia concurrente o secuencial VHDL tiene
su proceso equivalente, de hecho el simulador VHDL slo trabaja con procesos. La
sintaxis general de un proceso es:
[etiqueta :] process [(nombre_seal (,.})] [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 depuracin del cdigo. La parte de declaraciones se utiliza
para declarar datos locales al proceso, tambin puede contener subprogramas loca-
les al proceso. La parte de sentencias secuenciales es la que define el comporta-
miento del proceso a travs de un algoritmo. La partcula 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 despus del begin) para continuar su eje-
cucin. La ejecucin del proceso se detiene (el proceso se suspende) al ejecutar una
sentencia wait, al mismo tiempo la ejecucin de la sentencia wait suele fijar las con-
diciones para despertar al proceso y continuar con su ejecucin (fijar a qu seales
es sensible el proceso). Ntese que un proceso que no contenga ninguna sentencia
wait entra en un bucle infinito que impide que avance el tiempo de simulacin.
Aunque en general un proceso puede contener ms 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 continuacin:
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 seal (y, por lo tanto, no puede
despertar a otros procesos, se llama proceso pasivo. Los procesos pasivos pueden
aparecer en la declaracin de entidad de un modelo.
2. Presentacin del lenguaje VHDL 1 03
2.6.2. Asignacin a seal concurrente
La asignacin a seal puede darse tambin en el mundo concurrente. En este caso la

asignacin concurrente a seal tiene un proceso equivalente con una asignacin se-
cuencial a seal. La forma ms sencilla de su sintaxis es:
[etiqueta: 1 nombre_seal <= [transportl forma onda:
La etiqueta es opcional, sirve para identificar al proceso y puede ser til en las
tareas de depuracin del cdigo. La asignacin a seal concurrente es una forma
compacta de escribir una asignacin a seal secuencial, se comporta de la misma
forma que sta (seccin 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 asignacin concurrente es sensible a las seales que se encuentren a la dere-
cha de la asignacin, o sea, que formen parte de la expresin que se asigne. De for-
ma que la siguiente asignacin concurrente:
a <= b;
Es equivalente al proceso
process(b)
begin
a <= b;
end process;
Aunque en este ejemplo se ha presentado una asignacin muy simple, la asig-

nacin concurrente permite algunas opciones potentes que le dan una gran flexibili-
dad y que hacen que pueda tener cierta analoga con las sentencias secuenciales
condicionales. Por ello estas formas compuestas de asignacin concurrente se estu-
dian en las siguientes secciones.
La principal diferencia que incorpora VHDL-93 a la asignacin a seal concu-
rrente es que ampla 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 opcin de rechazar se puede especificar para qu valo-
res de tiempo (qu anchuras de pulso) se debe rechazar una transicin sobre una se-
al. Para ms detalles sobre el comportamiento de esta opcin consultar
[A95][BFMR93].
2.6.3. Asignacin concurrente condicional
La asignacin concurrente condicional es una forma compacta de expresar las asig-

naciones a seal usando la sentencia if secuencial. Su sintaxis es:
[etiqueta : 1 nombre_seal <= [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 depuracin del cdigo.
La sentencia funciona de forma que el valor que se asigna a la seal es el que
se especifica en la condicin que se cumple. Esta asignacin concurrente se ejecuta-
r cada vez que se produzca un evento en las seales que forman parte de la expre-
sin de asignacin (forma_onda) o en las seales que forman parte de la condicin
(expresion_booleana).
Como ejemplo tpico del uso de una asignacin 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 asignacin concu-

rrente condicional son:
Permite que la ltima asignacin tenga tambin condicin (en VHDL-87 la
sentencia deba acabar con una expresin de asignacin sin condicin).
Ofrece la posibilidad de no realizar ninguna asignacin en alguna de las op-
ciones, para ello introduce la palabra reservada unnafected.
Por supuesto, adems de estas modificaciones, tambin incorpora la modifica-
cin del modelo de retardo inercial descrito en la seccin 2.6.2. Descripciones ms
amplias de las variaciones introducidas en VHDL-93 a la asignacin a seal pueden
encontrarse en [A95][BFMR93].
2.6.4. Asignacin concurrente con seleccin
La asignacin concurrente con seleccin es una forma compacta de expresar las

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

nanbre~eal <= [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 depuracin del cdigo.
La sentencia funciona de forma que la forma de onda que se asigna a la seal

es la que se especifica en la opcin correspondiente al valor que toma la expresin
de seleccin. Esta asignacin concurrente se ejecutar cada vez que se produzca un
evento en las seales que forman parte de la expresin de seleccin (expresion) o en
las seales que forman parte de la expresin de la asignacin (forma_onda).
Como ejemplo podemos modelar una unidad aritmtica lgica que contiene las
operaciones de sumar, restar, and lgica y or lgica:
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 asignacin 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 opcin unaffected en la asignacin que se quiera, de forma que dependiendo del
valor de la expresin no se asigne ningn valor. Adems, tambin incorpora la va-
riacin sobre el retardo inercial (reject) descrita en la seccin 2.6.2. Para ms deta-
lles sobre las diferencias incorporadas en el VHDL-93 consultar [A95][BFMR93].
2.6.5. Assert concurrente

La sentencia assert puede darse tambin en el mundo concurrente. En este caso tie-
ne un proceso equivalente con una sentencia assert secuencial. La forma ms 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 depuracin del cdigo. La sentencia assert concurrente es una forma com-
pacta de escribir una sentencia assert secuencial, se comporta de la misma forma
que sta (seccin 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 condicin
(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
seales que aparezcan en la condicin. De esta forma la siguiente sentencia assert
concurrente:
assert not (s='1' aDd r='l')

report "uso incorrecto de la bscula RS;
Es equivalente al proceso
process(r, s)
begin
assert not (s='1' aDd r='l')
report "uso incorrecto de la bscula RS;
end process;
Ntese que ste es un proceso pasivo, que no realiza asignacin alguna a seal
y que, por lo tanto, puede aparecer en la entidad del diseo. Por lo tanto, la senten-
cia assert concurrente tambin puede aparecer en la entidad del modelo.
La variacin de la sentencia assert introducida en VHDL-93 y descrita en la
seccin 2.5.9 tambin 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 parmetros 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 funcin (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 funcin aparecer en una asignacin a seal 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 parmetros de entrada al subprograma.
2.6.7. Sentencias estructurales
VHDL proporciona un conjunto de sentencias dedicadas a la descripcin de estruc-

tura del hardware. Son tambin sentencias concurrentes, ya que se ejecutan en para-
lelo con cualquier otra sentencia concurrente de la descripcin y aparecen en la ar-
quitectura de un modelo fuera de cualquier proceso.
Adems de las sentencias estructurales propiamente dichas, en este apartado
tambin estudiaremos las posibilidades que ofrece VHDL para configurar un dise-
o, o sea, cul de sus posibles arquitecturas se usa en cada caso y las posibilidades
de generalizar un diseo. Estas dos caractersticas (configuracin y generalizacin
del diseo) son especialmente tiles y necesarias en las descripciones de estilo es-
tructural en VHDL.
2.6.7.1. Componentes
Para realizar la descripcin estructural de un sistema es necesario conocer qu sub-

sistemas o componentes lo forman, indicando las interconexiones entre ellos. Para
este propsito VHDL proporciona el concepto de componente.
Para poder usar un componente VHDL exige que se realicen dos pasos: prime-
ro, debe declararse el componente, despus, ya puede hacerse referencia o copia del
componente.
La declaracin 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
declaracin de un componente es:
COIIilOnent nombre_COIIilOnente [18]

[generic (lista_generic);]
[port (lista_puertos);]
end ccmponent (nombre_cooponente];
Tanto la partcula is como la repeticin del nombre del componente al final de

la declaracin del mismo son opcionales y aparecen en VHDL-93.
Habitualmente al declarar un componente se har referencia a un diseo desa-
rrollado anteriormente y ya compilado en alguna biblioteca. En este caso la declara-
cin de componente coincide con la declaracin de la entidad de dicho diseo, es
decir, debe tener los mismos puertos, definidos del mismo tipo y direccin. Pero
VHDL tambin ofrece la posibilidad de declarar un componente que an no se ha
desarrollado, en ese caso los puertos que contenga y su tipo quedarn definidos en
la declaracin 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 dems 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 seales 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 genricos y qu seales 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 cmo se conec-
tan entre ellos. Como ejemplo del uso de componentes, a continuacin 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 descripcin VHDL refleja exactamente la Figura 2-9:
U1 U3
X
Cln
ss
S SS
U2
I e
8-- co
"'
Sum
FIGURA 2-9. Esquema lgico equivalente a la descripcin VHDL.

Existen dos formas de asociar los puertos locales (los que aparecen en la decla-
racin 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:
asociacin posicional. Se asocia cada puerto local con su puerto actual por la posi-
cin 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-
sicin en la lista de puertos del componente.
La segunda forma es ms explcita y proporciona ms informacin. 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 asociacin por nombre tenemos:
U2 : semi sumador port map(Il=>B, 12=>Cln, Cout=>C, SUrn=>Sum);
Usando esta nomenclatura podemos especificar la asociacin de puertos de for-

ma independiente al orden que stos ocupan en la declaracin 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 tambin expresiones estticas como
puertos actuales.
La diferencia ms 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. Obsrvese
que en este ejemplo no se ha hecho referencia a ninguna arquitectura, por tanto sta
se especificar va configuracin (configuraton), si no queremos usar la configura-

cin, 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 realizacin de ml-

tiples copias de elementos iguales (o parecidos). Estas descripciones estructurales
podran realizarse con la copia o referencia a componente que se ha descrito en el
apartado anterior, pero VHDL ofrece una forma ms cmoda y compacta para reali-
zar descripciones que se basen en la repeticin de la misma estructura: la sentencia
generate. La sintaxis bsica 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 seccin de sentencias concurrentes puede contener cualquier sentencia
concurrente VHDL: process, block, assert concurrente, asignacin a seal concu-
rrente, llamada concurrente a subprograma, copia de componente e incluso otra
sentencia generate.
La forma ms 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-
neracin consiste nicamente de la descripcin del nmero 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 podramos usar el siguiente cdigo:
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 generacin de este ejemplo est formado por un bucle que se

repetir N veces y, por lo tanto, realizar el mismo nmero 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 generacin es
local a la sentencia generate y slo es visible dentro de ella. En este ejemplo se ha
usado el ndice para indicar qu bit de las seales entrada y salida deben conectarse
a cada una de las copias del biestable DFF.
Obsrvese que en lugar de especificar el nmero concreto de bits que tendr el
registro se ha usado un genrico (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 descripcin de la sintaxis de la sentencia, el meca-
nismo de generacin adems de contener una indicacin de repeticin puede conte-
ner condiciones. Este esquema es til para describir elementos que estn 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
conlOnent 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 repeticin 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.
Obsrvese que de forma explcita la sentencia generate no contiene seccin
declarativa, por ello en el ejemplo anterior se ha tenido que declarar la seal X para
realizar las conexiones entre celdas del registro de desplazamiento. Una forma ms
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 seales). Los elementos que se declaren tambin
sern replicados y existir una copia para cada grupo de sentencias concurrentes
generadas, a las que sern locales.
2.6.7.3. Configuracin de un diseo
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 cul de las posibles arquitecturas va a ser usada. El mecanismo
que permite relacionar entidad y arquitectura es la configuracin (configuration).
La configuracin de un diseo puede aparecer en dos entornos distintos: puede
aparecer en una arquitectura, entonces se llama especificacin de configuracin, o
puede aparecer como una unidad de diseo independiente, entonces se llama decla-
racin de configuracin.
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 especificacin de configuracin. La
sintaxis general para la especificacin de configuracin es la siguiente:
for (ref_componente {, .. } I otbers I al1) id...cooponente

use entity id_entidadl (id_arquitectura);
use configuration id...configuracin;]
Usando la especificacin de configuracin, podemos escribir de nuevo el ejem-

plo del sumador completo usado en la seccin 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 : Snisumador use entity work. Semisumador (EStructurl) ;

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-
bin se especifica que para el componente U3 del tipo PuertaOr se usar su arqui-
tectura Logica.
La especificacin de configuracin puede aparecer en la parte declarativa de
una arquitectura o tambin 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 genricos de cada
componente, o sea, puede contener una clusula generic map y una clusula port
map. Cmo ejemplo de este uso ms genrico podernos escribir de nuevo la arqui-
tectura de nuestro sumador completo, variando su configuracin de la siguiente for-
ma:
architecture Estructura of S~dorCampleto is
declaracin 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 lgica de dos entradas) debe usarse el componente que se encuentra en la bi-
blioteca Puertas que se llama PuertaOr3 (puerta or lgica de tres entradas) y usar
su arquitectura Logica. Ya que el componente elegido difiere en el nmero de entra-
das, se usa la Clusula port map en la especificacin de configuracin 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. Tambin 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). Ntese que en el mapeo
de nuestro ejemplo se ha usado sintaxis VHDL-93, ya que para fijar un puerto al ni-
vellgico 'O' se ha asignado directamente el valor 'O' al puerto. En VHDL-87 de-
bera definirse una seal fijada a este valor lgico y asignar dicha seal al puerto.
En este uso de la configuracin se muestra la mxima flexibilidad de este me-
canismo, por analoga con el hardware a veces se ha dicho que el mecanismo de re-
ferencia a un componente equivale a elegir el zcalo de un componente, mientras
que la configuracin del componente escoge qu dispositivo se coloca en el zcalo.
Como ya hemos dicho, la configuracin puede ser usada como una unidad de
diseo independiente, en ese caso se le llama declaracin de configuracin 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_configuracin;]
end for; )
end for;
end [configuration] [identificador];
El identificador es el nombre que va a recibir la configuracin y servir para

poder referenciarla ms tarde. La partcula configuration al final de la configura-
cin es opcional y aparece en VHDL-93.
Para nuestro ejemplo, del sumador completo podemos escribir la siguiente con-
figuracin:
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 declaracin de

configuracin, vamos a ver cada una de ellas. La declaracin de configuracin debe
contener un identificador de la configuracin (en este caso Primera) que sirve para re-
ferenciar a dicha configuracin, por ejemplo, desde configuraciones de niveles ms
altos de la jerarqua. 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 configuracin ser Primera.
A continuacin debe especificarse la configuracin deseada para cada uno de

los componentes de la arquitectura. No tienen por qu configurarse todos los com-
ponentes de la arquitectura en la declaracin de configuracin, quizs alguno de los
componentes ya se configur en el cdigo de la misma arquitectura, o quizs algu-
no quiera configurarse desde otra declaracin de configuracin del diseo. 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. Obsrvese que la sintaxis indica que la especificacin
de arquitectura es opcional, en caso que sta se omita la mayora de herramientas
considerarn 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 configuracin 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

configuracin llamada funcional, que tambin se encuentra en la biblioteca work.
En dichaconfiguracin se habr indicado qu arquitectura usar para el componente
Semisumador, por ejemplo esta configuracin podra ser de la siguiente forma:
configuration Funcional of Semisumador is

for Corrportamiento
end for;
end Funcional;
La configuracin Funcional del Semisumador indica que debe usarse la arqui-

tectura Comportamiento del mismo. Obsrvese que en este caso estamos configu-
rando la jerarqua del diseo a travs de distintas declaraciones de configuracin, en
lugar de especificar la configuracin de todos los componentes del diseo en una
nica declaracin de configuracin. Para cada nivel de jerarqua se especifica su
configuracin, y en sta puede hacerse referencia a configuraciones de niveles de
jerarqua inferiores del diseo. Por claridad y estructuracin del cdigo aconseja-
mos usar declaraciones de configuracin jerrquicas en lugar de especificar la con-
figuracin de todo el diseo en una nica declaracin de configuracin.
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 configuracin 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 seccin
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 configuracin in-
cremental de una componente. Mientras en VHDL-87 solamente puede haber una
especificacin de configuracin o una definicin de configuracin, 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. Genricos
Tal como hemos visto en algunos de los ejemplos de apartados anteriores, VHDL
ofrece la posibilidad de generalizar un modelo, aadiendo unos parmetros lla-
mados genricos (generics) en la definicin de la entidad del modelo. Cuando el
modelo es usado como un componente el usuario fija el valor que deben tomar los
genricos, de forma que adapta el diseo del modelo genrico a sus necesidades
concretas.
Si queremos desarrollar un modelo genrico, debemos incluir en la entidad del
mismo la clusula generic, en ella se indicarn cules son los parmetros genricos
del modelo.
Como ejemplo vamos a modelar una puerta or con tres parmetros genricos.
El primero indica el tiempo de propagacin intrnseco 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. Adems, las entradas de la puerta se modelan con un nico
puerto que es un vector no restringido. De forma que el nmero de entradas que
tenga la puerta se fijar al hacer una copia o referencia al componente, y depender
de la dimensin del vector que se conecte a su puerto de entrada.
Con estos genricos se pretende que podamos modificar los parmetros usados
en el clculo de retardos de la puerta, dependiendo del nmero 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
utilizndolo como componente, en cada copia deberemos especificar qu valor con-
creto queremos darle a los parmetros genricos. 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 genrica de forma que sus parmetros 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 mdulo con genricos cuando es usado como
componente, debe usarse la clusula generic map. sta sigue un conjunto de reglas
bsicas que enunciamos a continuacin:
Los valores que se asignan a cada genrico deben ser constantes o expresio-
nes.
Puede usarse asociacin posicional o por nombre o una mezcla de ambas
(igual que en las clsulasport map).
Se puede omitir el valor a asignar a cualquier genrico 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 genrica, 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 parmetros 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, adems permite compartir declaraciones de objetos que sern visibles sola-
mente para las sentencias englobadas en la sentencia block. Tambin permite reali-
zar asignaciones a seal 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_:genrip~JAHr

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

partcula is es opcional y slo aparece en VHDL-93. La expresin de guarda slo
tiene sentido que aparezca si vamos a usar asignaciones guardadas y no si usamos
el bloque con objeto de particionar u organizar el cdigo.
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 cdigo 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, seales, 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 sern 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 genricos, por lo tanto puede usarse para describir jerar-
qua. De hecho, la sentencia block es a la estructuracin lo que la sentencia process es

a la simulacin. O sea, cualquier otra forma de estructuracin que se use en una des-
cripcin VHDL es finalmente convertida a las sentencias block equivalentes. En con-
creto, la referencia o copia a componente que es la construccin bsica de VHDL
usada para describir jerarqua se convierte en dos sentencias block anidadas [LSU89].
Por ltimo, una sentencia block puede tener una condicin de guarda, que debe
ser una expresin booleana que aparezca inmediatamente despus de la palabra re-
servada block. Esta expresin crea de forma automtica una seal booleana llamada
guard, la cual puede usarse para controlar el comportamiento o ejecucin de las
asignaciones a seal contenidas en el bloque. Si en el bloque aparecen asignaciones
a seal que contengan la palabra clave guarded, stas solamente se realizarn si la
condicin de guarda es verdadera (la seal 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 asignacin de D (dato de entrada) sobre Q (elemento de memoria) slo se

realizar cuando la condicin de guarda sea cierta. Por lo tanto, slo tendr lugar
cuando se produzca un flanco de subida de reloj.
De todos los usos de la sentencia block que aqu hemos descrito, el ms 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 jerarqua.
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 describirn las
operaciones que se realicen sobre los datos.
Otra caracterstica de un subprograma es su lista de parmetros, 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 parmetros que aparecen en la definicin de un subprograma se llaman parme-
tros formales, mientras que los parmetros que aparecen en las llamadas a subpro-
gramas son los parmetros actuales.
Un subprograma se usa para agrupar cdigo, 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, podra ser interesante con la intencin de obtener
un cdigo estructurado.
Los subprogramas constan de dos partes: la definicin del subprograma y la
definicin del cuerpo del subprograma. En la definicin de un subprograma se defi-
ne el nombre de ste y su lista de parmetros. La definicin de un subprograma es

opcional y puede encontrarse en una declaracin 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 definicin del cuerpo del subprograma con-
tiene la definicin de las estructuras de datos locales a ste y el algoritmo que reali-
za. La definicin 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-
rsticas en comn tambin presentan importantes diferencias, por lo tanto los vamos
a estudiar por separado.
2.7.1. Funciones
Las funciones estn orientadas a realizar clculos, podemos pensar en ellas como en
una generalizacin de las expresiones, son una forma de definir nuevos operadores
que pueden aparecer en una expresin.
La sintaxis para la definicin de una funcin es:
function nombre_funcipIl. !,(Jista_parametros)] returo tiW.,...r~tqmo
La sintaxis de la definicin del cuerpo de una funcin es:
[pure I impure] function nambre_funcion [(lista_parametros)]

returo tipo_retorno ia
{parte_declarativa}
begin
{sentencias secuenciales}
end [iunction] [nombre_funcion]
La partcula opcional function al final de la definicin es propia de VHDL-93

y su nico inters es mejorar la legibilidad del cdigo. Tambin las partculas op-
cionales pure/impure son propias de VHDL-93, sirven para explicitar si una fun-
cin es pura o impura. En general, una funcin pura es aquella que dado un conjun-
to de valores de sus parmetros de entrada siempre retorna el mismo resultado,
mientras que una funcin impura puede romper esta regla. Una discusin amplia
sobre funciones puras e impuras puede encontrarse en [A95][BFMR93].
Los parmetros formales de una funcin 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 parmetros, 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 existirn cuando la funcin est activa, y se crearn e inicializarn de
nuevo cada vez que sta sea llamada: Por este motivo no se pueden declarar seales
en la parte declarativa.
La parte declarativa de una funcin tambin puede contener definiciones de

subprogramas; stos, al igual que cualquier tipo de datos que se haya declarado, se-
rn locales a la funcin y, por lo tanto, invisibles fuera de ella.
En las sentencias secuenciales que se encuentran en la parte de sentencias de
una funcin siempre debe haber al menos una sentencia retum. Esta sentencia ser
la que retomar el nico valor que una funcin puede devolver como resultado de
su ejecucin.
En la parte de sentencias de una funcin no se puede modificar (no se pueden
realizar asignaciones) variables o seales externas a la funcin, aunque s puede
usarse para formar parte de expresiones utilizadas en la funcin. En la parte de sen-
tencias de una funcin tampoco puede aparecer ninguna sentencia wait,
En el siguiente ejemplo mostramos una funcin que convierte un dato de tipo
bit_vector sin signo en su natural equivalente. La definicin de la funcin (opcio-
nal) sera la siguiente:
function bv_to_natural (S: bit_vect;ar(O to 7)) return natural.:
La declaracin del cuerpo de la funcin sera:
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 funcin puede llamarse desde cualquier parte del modelo
usando bien la llamada a funcin secuencial o la llamada a funcin concurrente. En
ambos casos la llamada a funcin no ser en s misma una sentencia sino que for-
mar parte de una expresin. 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 funcin representa la totalidad de la expresin,

pero la llamada a funcin podra formar parte de una expresin mucho ms com-
pleja.
En nuestro ejemplo de llamada a funcin el paso de los parmetros actuales se
ha hecho por posicin, pero puede hacerse tambin por nombre (de forma anloga a
la copia o referencia a componente). Con lo cual la llamada a funcin podra expre-
sarse como:
salida : = bv_tO.JJatural (S=>Entrada) i
En este ejemplo no tiene mayor importancia, ya que solamente tenemos un

parmetro de entrada, pero para funciones con mayor nmero de parmetros
puede aumentar la legibilidad del cdigo el uso del paso de parmetros por nom-
bre.
2.7.2. Procedimientos
Los procedimientos (procedures) estn orientados a realizar cambios en los datos

que tratan, ya sean sus parmetros ya sean datos externos a los que pueden acceder.
La sintaxis para la definicin de un procedimiento es:
procedure nombre_procedimiento [(lista_parametros)]
La sintaxis de la definicin del cuerpo de un procedimiento es:

procedure nombre_procedimiento ~Hlista_parametros)] ia
{parte_declarativa}
begin
{sentencias secuenciales}
end [procedure] [nombre_procedimientol
La partcula opcional procedure al final de la definicin es propia de VHDL-

93 y su nico inters es mejorar la legibilidad del cdigo.
Los parmetros 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 parmetros formales son constantes, variables y seales.
Por defecto, los parmetros de tipo in se consideran constantes, mientras que los de
tipo out e inout se consideran variables.
Los parmetros de modo entrada (in) se usan para pasar valores al procedi-
miento, que ste puede usar, pero nunca puede variar su valor. Los parmetros de
modo salida (out) son aquellos que el procedimiento slo puede usar realizando una
asignacin sobre ellos, o sea, puede modificar su valor pero no usar o leer su valor.
Por ltimo, los parmetros de modo entrada/salida (inout) son aquellos que pueden
usarse o leerse dentro del procedimiento y que tambin puede variarse su valor me-
diante una asignacin.
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 existirn cuando la funcin est
activa y se crearn e inicializarn de nuevo cada vez que sta sea llamada. Por este
motivo no se pueden declarar seales en la parte declarativa
La parte declarativa de un procedimiento tambin puede contener definiciones
de subprogramas; stos, al igual que cualquier tipo de datos que se haya declarado,
sern 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 acompaada de
ninguna expresin 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 seales externas al procedimiento. En las sentencias de un pro-
cedimiento pueden aparecer sentencias wait.
En el siguiente ejemplo mostramos un procedimiento anlogo al ejemplo usado
anteriormente para la funcin. La definicin del procedimiento (opcional) sera la
siguiente:
procedure bv_to_nat1.lrar (S: bit_vector(O to 7);
X: out natural);
La declaracin del cuerpo del procedimiento sera:

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 parmetros, 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_vctorJO te ?);
variable saHaa): natUraL
begin
bv_to_natural (Entrada, Salida);
end process;
Observemos que a diferencia de la llamada a funcin, la llamada a procedi-

miento es por s sola una sentencia.
Tambin al igual que para la llamada a funcin, en la llamada a procedimiento
la definicin de los parmetros actuales puede hacerse por posicin 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 parmetros actuales slo tiene im-

portancia para la legibilidad del cdigo.
2.7.3. Sobrecarga de subprogramas
Dos subprogramas estn 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 nmero, el orden y el tipo de sus parmetros, as como del
tipo del valor devuelto en el caso de las funciones.
La sobrecarga mejora la legibilidad del cdigo al permitir dar el mismo nombre
a dos subprogramas que realizan la misma funcin sobre datos de tipos diferentes.
De este modo, no es necesario pensar nombres distintos para cada subprograma.
Por ejemplo, se podran definir funciones que permitieran concatenar dos cadenas
de caracteres o una cadena de caracteres con un carcter utilizando el mismo nom-
bre de funcin:
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 concatenacin se acce-
deran 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 compilacin. Por ejemplo, la siguiente llamada fallar porque
la funcin Concatena no se puede llamar con dos valores de tipo carcter:
Cadena := Concatena ('a', 'b');
Tambin es posible que al realizar una llamada a un subprograma exista ms de

un candidato a ser ejecutado, en este caso tambin se producir un error de compi-
lacin. Por ejemplo, se pueden definir procedimientos que desplacen un vector de
bits un nmero de posiciones a la derecha, de forma que este nmero 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 parme-

tros de un subprograma para permitir llamadas donde slo se especifiquen estos pa-
rmetros en caso que difieran del valor que tienen por defecto. De este modo, la si-
guiente llamada al procedimiento
DespDerecha ("11001010");
producira un error de compilacin, ya que los dos procedimientos llamados Desp-

Derecha seran candidatos a ser ejecutados.
Tambin cabe resaltar que otras cuestiones de la declaracin de un subprogra-

ma, como el nombre, el modo y la clase de los parmetros, 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 declaracin de las siguientes funciones producira un error al
compilarse por duplicacin de una declaracin:
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 notacin diferente a la
tradicional. La mayora de operadores predefinidos en el lenguaje estn sobrecarga-
dos para poder ser utilizados con diferentes tipos de datos; as, por ejemplo, el ope-
rador "+" puede aplicarse a cualquier tipo numrico entero, real o fsico. Adems
de la sobrecarga de operadores propia del lenguaje, VHDL permite definir los ope-
radores predefinidos sobre tipos creados por el usuario. Para hacerlo slo har falta
indicar que la funcin que se est definiendo es un operador escribiendo su nombre
entre comillas. De este modo, se podran 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 notacin propia de
los operadores:
Var3 := Varl + Var2;
Var4 := Varl and Var2;
o bien la notacin propia de las llamadas a funciones:

Var3 := "+"(Varl, Var2);
Var4 := "andO (Varl, Var21;
2.7.4. Funciones de resolucin
Normalmente cada seal tiene una sola fuente que le proporciona el valor en todo
momento; sin embargo, VHDL permite definir seales que pueden tomar su valor
de mltiples fuentes. Este tipo de seales se llaman seales resueltas (resolved sig-
nals) y, como en cada instante una seal tiene un nico valor, deben tener una fun-
cin de resolucin (resolution function) asociada que determine el valor que deben
contener en todo momento. La posibilidad de disponer de ms de una fuente hace a
este tipo de seales muy adecuadas para el modelado de buses.
Una funcin de resolucin es una funcin que toma como entrada un vector
unidimensional no restringido con los valores de todas las fuentes de la seal re-
suelta y devuelve el valor que debe recibir dicha seal. VHDL llama a esta funcin
cada vez que se realiza una asignacin sobre la seal, en este momento se determi-
na el nmero de elementos del vector de entrada a la funcin, que ser igual al n-
mero de fuentes que tenga la seal. Las fuentes de una seal vendrn determinadas
tanto por las sentencias de asignacin en diferentes procesos como por las salidas
de componentes conectadas a dicha seal.
Para tratar con seales resueltas se podra definir, por ejemplo, el tipo XOIZ,
que aparte del cero y el uno lgico introduce el desconocido y la alta impedancia.
Tambin se definira el tipo vector de XOIZ necesario para el parmetro de entrada
de la funcin de resolucin:
type X01Z ls ('X', 'O', '1', 'Z');

type X01Z_vector is array (natural range < of X01Z;
Se puede declarar una funcin de resolucin para este tipo de datos de la si-
guiente manera:
function Rescluci.on (Fuentes: X01Z_tctor) return Xd1Z;
A continuacin, para introducir una seal resuelta slo se debe aadir el nom-
bre de la funcin de resolucin al resto de informacin requerida en la declaracin.
De este modo, cada vez que se realice una asignacin sobre la seal se llamar a la
funcin de resolucin para que decida el valor que se debe asignar. Por ejemplo, se
podra crear una seal de lectura y escritura de una memoria compartida por varios
procesadores de la siguiente forma:
signal LectEscRAM : Resolucion X01Z,
Tambin pueden introducirse seales resueltas declarando un subtipo de datos

resuelto, es decir, un subtipo al que se le asigna una funcin de resolucin. De este
modo, las seales de este subtipo ya no debern especificar la funcin de resolu-
cin. Este segundo mtodo resulta adecuado cuando la misma funcin debe utilizar-
se para diferentes seales resueltas. La declaracin anterior de la seal LectEscRAM
siguiendo este mtodo sera:
subtype X01ZResuelto is Resolucion X01Z;

signal LectEscRAM : X01Z_Resuelto;
Finalmente, el cuerpo de la funcin de resolucin debe decidir qu valor se

asigna a la seal resuelta dependiendo de los valores de todas las fuentes. Por ejem-
plo, para el tipo de datos XOl Z se puede escribir cdigo que asigne Z a la seal
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 dems estn en alta impe-
dancia. El cuerpo de la funcin de resolucin que implementa esta funcionalidad
sera 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 ms comn de las seales resueltas se produce en tipos de datos

escalares utilizados para modelar las propiedades elctricas de conexiones, el con-
cepto de seales resueltas es mucho ms amplio y puede aplicarse a otros tipos de
datos ms generales, como pueden ser los tipos compuestos, lo nico que hace falta
es definir una funcin de resolucin que determine en cada asignacin cul es el va-
lor que debe asignarse a la seal resuelta del tipo compuesto. En particular, se po-
dran utilizar vectores resueltos de seales para modelar buses de varios bits de an-
chura, no obstante esta aproximacin conlleva algunos problemas porque obliga a
trabajar con todo el vector a la vez sin permitir el acceso a slo una parte del vector.
Por esta razn, para el modelado de buses normalmente no se utilizan vectores re-
sueltos de seales sino vectores de seales resueltas, por lo tanto, se resuelve cada
seal del vector independientemente.
Por ltimo, cabe sealar que el paquete std_logic_1164 de IEEE que define los
tipos de datos std_ulogic y std_ulogic_vector tambin 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 definicin de estos tipos y subtipos, as como de la funcin de re-
solucin, 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 seales tengan una nica
fuente. Esta recomendacin se hace porque se supone que los simuladores se van a
optimizar para tratar estos tipos de datos. El mximo inconveniente de trabajar
siempre con seales resueltas es que los errores provocados por seales que acci-
dentalmente tienen ms de una fuente no se detectan en tiempo de compilacin, ha-

.bindose de detectar en tiempo de simulacin cuando una seal tiene un valor des-
conocido en un momento en que no debera tenerlo.
2.8. EJERCICIOS
1. Cules 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 numricos:

-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 nmeros comprendidos entre 1 y 31.
b) Un tipo enumerado con los meses del ao.
e) El tipo natural.
d) Un tipo registro para almacenar fechas, utilizando los tipos definidos en a),
b) y e) para el da, el mes y el ao respectivamente.
e) Un vector de 5 elementos del tipo registro definido en d).
f) El tipo fsico 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 lgico, 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 dimensin 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 asignacin 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)
Matrz/lel~h(3) .
7. Dibuje la cola de eventos de la seal e antes de la ejecucin de cada sentencia

wait y muestre la secuencia de valores que toma la seal 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 declaracin 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_vetor (O to~7r);
end Muitiplexor;
a) Escriba una arquitectura utilizando un proceso con una sentencia case.

b) Escriba una arquitectura utilizando una nica asignacin a seal concu-
rrente.
9. Dada la declaracin 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 operacin del decrementador.
Inicializa: Entrada sncrona que cuando vale 'O' inicializa Salida a "00000000".
Carga: Entrada sncrona 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 declaracin 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 descripcin

en flujo de datos.
b) Defina la entidad y arquitectura de un sumador de un nmero genrico de
bits que utilice el sumador anterior de un bit como componente. Para hacer-
lo use la sentencia generate.
11. Escriba una funcin 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 fsicos
Distancia (micra, milmetro, centmetro, metro y kilmetro) 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 algortmico donde se

realice la multiplicacin de las entradas aplicando las funciones de conver-
sin necesarias para que no se produzca un error de compilacin.
b) Aada al paquete DistanciaArea la sobrecarga de los operadores necesarios
para poder realizar las operaciones de suma, resta, multiplicacin por entero
y multiplicacin por real para los tipos Distancia y Area. Sobrecargue tam-
bin 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 seal resuelta de tipo bit:
signal Peticion : ResolucionBit bit;
a) La seal Peticion debe valer '1' cuando alguna de sus fuentes vale '1',
mientras que debe valer 'O' en caso contrario (or lgica). Escriba la funcin
de resolucin ResolucionBit.
b) La seal Peticion debe valer '1' cuando una y slo una de sus fuentes vale
'1', en caso contrario debe valer 'O'. Escriba la funcin de resolucin Reso-
lucionBit.
e) La seal Peticion debe valer' l' cuando todas sus fuentes valen '1', en caso
contrario debe valer 'O' (and lgica). Escriba la funcin de resolucin 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 declaracin de entidad de este bloque.

b) Escriba la arquitectura de la entidad utilizando el estilo de descripcin 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 descripcin de flujo de datos.

Para hacerlo solamente se pueden usar los operadores lgicos and, or y noto
d) Escriba la arquitectura utilizando el estilo de descripcin algortmico. Hga-
lo usando la sentencia secuencial case.
e) Escriba la arquitectura utilizando el estilo de descripcin algortmico. Hga-
lo usando la sentencia secuencial ij, mediante construcciones del tipo:
if <condicin> then
elsif <condicin> then
else
end if
f) Escriba una configuracin 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
configuracin que debe usarse dicha arquitectura.
g) Suponga que las salidas y y Z son de un tipo llamado XOl que contiene los
valores cero lgico ('O'), uno lgico (' 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 inclyalo en un paquete llamado Paque-
te_XOl. Utilizando el paquete acabado de definir, vuelva a escribir la decla-
racin de entidad y la arquitectura en estilo algortmico usando la sentencia
case.
2.9. BIBLIOGRAFA
[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 modli-
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.
Captulo 3
PROCESADO
V MECANISMOS,
DE SIMULACION
DEL LENGUAJE VHDL
Serafn Olcoz (SIDSA)
VHDL, aunque dentro del diseo electrnico, se utiliza para otras ta-
reas, como la sntesis o la verificacin, es un lenguaje que naci y se
desarroll con una semntica explcita para simulacin dirigida por
eventos discretos. Tanto es as que en el manual de referencia del len-
guaje (Language Reference Manual, LRM) adems de la sintaxis, y jun-
to a la semntica del lenguaje, se detallan los mecanismos bsicos del
procesado del lenguaje para la simulacin. Por tanto, si bien puede
haber ambigedades cuando el lenguaje se utiliza para otras tareas, en
simulacin stas no existen y esto es lo que trataremos de dejar claro
en este captulo, describiendo con detalle el procesado, la semntica y
los mecanismos de simulacin de VHDL.
Tras unas nociones bsicas sobre la simulacin por ordenador que
facilitan la ubicacin y comprensin del propio proceso de simulacin
de VHDL, se presentan los conceptos fundamentales del procesado de
un lenguaje de programacin para poder entender mejor los elemen-
tos y etapas del procesado de VHDL para simulacin.
A continuacin se abordan los objetivos centrales de este captulo:
el procesado y el modelado de VHDL para simulacin. Tras el procesa-
do de una entidad de diseo VHDL para su simulacin dirigida por
eventos discretos donde se detallan las fases de anlisis, elaboracin y
simulacin, se analiza el modelo temporal 8-delay, el determinismo
y la portabilidad de VHDL.
El objetivo no es presentar y analizar tcnicas de modelado para si-
mulacin, sino estudiar en detalle el procesado y los mecanismos de
simulacin que permitan al lector extraer criterios de modelado para
realizar y utilizar de forma eficiente las descripciones de sistemas elec-
trnicos en VHDL.
135
3. 1. INTRODUCCiN
VHDL, [1], es un lenguaje de descripcin de hardware (Hardware Description

Language, HDL , [2-11]), por ejemplo, un lenguaje de descripcin o modelado de
sistemas electrnicos, en particular de sistemas microelectrnicos, que tiene voca-
cin de convertirse en un lenguaje capaz de dar soporte a las diversas etapas que
componen el ciclo de vida de un diseo electrnico. Esta tendencia lleva a extender
su uso ms all del propsito 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 extensin de
mayor repercusin es la de la utilizacin de VHDL como lenguaje de sntesis auto-
mtica de hardware.
Dado que VHDL es un lenguaje bastante complejo, suele ser normal que un di-
seador de hardware no utilice adecuadamente toda su capacidad descriptiva. Lo
habitual suele ser que el diseador adopte unos ciertos hbitos o estilos de descrip-
cin 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 detrs de esta excusa es el desconocimiento del procesado y de la se-
mntica del lenguaje VHDL. Situacin que se agrava cuando el diseador utiliza si-
multneamente el mismo lenguaje, o un determinado subconjunto del mismo, con
dos finalidades o semnticas distintas, por ejemplo, simulacin y sntesis. Llegando
a causar equvocos 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 incompresin. Para evitar esta posible y nefasta consecuencia, en este
captulo se presenta el lenguaje desde el punto de vista de su procesado y su semn-
tica de simulacin dirigida por eventos discretos.
Aunque VHDL, como se describe en los distintos captulos de este libro, es al-
go ms que un lenguaje de simulacin dirigida por eventos discretos, su capacidad
para describir y probar el comportamiento de sistemas electrnicos se basa precisa-
mente en su faceta de simulacin. Por ello, este captulo comienza presentando las
nociones bsicas de la simulacin por ordenador. Nociones que son de gran utilidad
para el diseador de sistemas electrnicos al permitirle considerar el proceso de di-
seo con VHDL como un caso particular del diseo de un sistema fsico por medio
de su modelado y posterior compresin y/o validacin por medio de su simulacin.
Desde esta perspectiva, la descripcin de un sistema electrnico a travs de un HDL
con semntica de simulacin se puede considerar como la generacin de un progra-
ma informtico cuya ejecucin por un ordenador produce un modelo dinmico que
representa la evolucin del sistema fsico, ya sea existente (para describir/reflejar) o
proyectado (para sugerir ideales), a travs del tiempo.
A continuacin se presentan las nociones bsicas del procesado de un progra-
ma informtico, hacindose especial nfasis en la compilacin software, hardware e
hbrida de un HDL. Este conocimiento es crucial para poder comprender tanto la
generacin de modelos software de simulacin por ordenador correspondiente a una
descripcin HDL, como la generacin de modelos para emulacin hardware o la
generacin de un hardware determinado por medio de la sntesis de dicha descrip-
3. Procesado y mecanismos de simulacin del lenguaje VHDL 137
cin HDL. Esta seccin tambin introduce los mecanismos de especificacin de un

lenguaje de programacin y resalta la estrecha relacin existente entre dichos meca-
nismos de especificacin y el procesado del lenguaje.
Las dos primeras secciones ofrecen una visin general de todo el conocimiento
que se debe tener previamente a considerar el procesado y la simulacin de VHDL.
La tercera seccin describe propiamente el objetivo de este captulo, o sea, la simu-
lacin de una entidad VHDL desde el punto de vista del procesado de una entidad
de diseo VHDL y de su simulacin dirigida por eventos discretos. Distinguiendo
entre lo que es un simulador VHDL y una simulacin VHDL y detallando las fases
de. anlisis, elaboracin y simulacin, sin entrar en cmo se genera el programa eje-
cutable en el ordenador ni en cmo ste se depura (debugging). Aunque si se pre-
sentan las consecuencias que la ejecucin y depuracin 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 electrnicos en VHDL.
A continuacin se describe cmo se prepara la tarea de simulacin de una enti-
dad de diseo descrita en VHDL (VHDL Design Entity) y en qu se parece y se di-
ferencia del caso de abordar su sntesis (incluyendo implcitamente la manufactura
del dispositivo fsico correspondiente) y/o la prueba (test) de dicha entidad. Final-
mente, se hace una referencia a las diferencias existentes entre la simulacin lgica,
temporal y de fallos.
3.2. SIMULACIN POR ORDENADOR
La simulacin es una tcnica que consiste en el uso de un modelo para desarrollar

conclusiones acerca del comportamiento de un sistema fsico, tambin denominado
objeto real por contraposicin a la posible "virtualidad" del modelo. La simulacin
por ordenador (Computer Simulation), como su propio nombre indica, requiere que
el modelo se cree por medio de la programacin de un ordenador, [12-13]. Las tc-
nicas de simulacin por ordenador ofrecen la posibilidad de emplear un prototipo
virtual, o varios a distintos niveles de abstraccin, en lugar de un prototipo real (tc-
nica conocida como breadboarding en el entorno del diseo de sistemas electrni-
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 lgicas o
matemticas. La informacin que ofrece la simulacin es la representacin del esta-
do del modelo con respecto al tiempo. El flujo de control de un programa de simu-
lacin representa la lgica de cambio de estados del sistema con el paso del tiempo.
A diferencia de los programas dedicados a la realizacin de clculos cientficos, en
los que la estructura de control se puede alterar mientras no se altere el resultado
correcto, para una simulacin la lgica de control debe reflejar la realidad y, por
tanto, la correccin no slo atae al clculo sino que tambin depende de que se lo-
gre dicho reflejo.
La simulacin por ordenador puede llegar a ser una tcnica de resolucin de

problemas complicada y cara, tanto en tiempo de desarrollo del modelo de simula-
cin como en su ejecucin o animacin. Por tanto, slo 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 fsico real existe pero su observacin y experimentacin 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 matemtico, tambin denominado formal, del sistema fsico no
tiene solucin analtica o numrica que ofrezca resultados prcticos, por lo
que su anlisis y/o verificacin formal resulta inviable ..
La principal ventaja del uso de la simulacin es la reduccin del riesgo asocia-

do a la realizacin de un nuevo sistema, o a su modificacin. La simulacin por or-
denador permite probar diferentes alternativas y seleccionar la que ofrezca mejores
resultados. Las soluciones propuestas a los problemas descubiertos con la simula-
cin se pueden analizar en menos tiempo que las observaciones realizadas en el
mundo real. Adems, la simulacin 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 diseador del mismo a que determine
y documente de forma precisa cmo funcionar el sistema en cuestin, labor a la
que habitualmente no se le dedica el esfuerzo y la atencin que merece. El propio
proceso de crear las relaciones lgicas, por medio de la programacin del modelo,
sirve para sacar a la luz posibles problemas o indeterminaciones relacionadas con la
especificacin del sistema.
Sin embargo, debido a que la simulacin no es ni un arte ni una ciencia, sino
una mezcla de ambos, tambin presenta dos desventajas inherentes a su propia natu-
raleza. La primera de ellas se debe a que la simulacin es un proceso experimental
que slo da respuestas aproximadas, ni exactas ni ptimas, que slo permiten mejo-
rar la confianza en el modelo. En una simulacin no se obtiene una solucin, mate-
mticamente 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 simulacin por ordenador se abandona el clculo predictivo que ofrecera el
uso de una definicin completamente rigurosa o formal, por la aplicacin de un m-
todo de prueba y error en el que se pueden observar las distintas estrategias y posibi-
lidades del diseo. Una simulacin se puede repetir tantas veces como sea necesario
hasta que se obtenga suficiente confianza en sus predicciones. La deteccin de erro-
res conduce al rediseo del sistema. Como contrapartida, se suelen requerir menos
suposiciones y abstracciones que en los modelos matemticos (modelos formales).
La segunda desventaja se debe a que la validacin del propio modelo de simu-
lacin es la mayor limitacin de esta tcnica.
3. Procesado y mecanismos de simulacin del lenguaje VHOL 139
3.2.1. Descripcin del tiempo vIo distintos tipos

de simulacin
Para expresar el comportamiento dinmico de los sistemas es necesario poder re-

presentar de alguna forma el tiempo [12-13 ]. El tiempo se podra considerar como
un continuo, pero entonces para poder informatizar su evolucin sera necesario el
uso de ordenadores analgicos. El problema que presentan este tipo de ordenadores
es que su precisin es altamente dependiente de las caractersticas de los circuitos
electrnicos que los forman. La dificultad de duplicar este tipo de sistemas ha lleva-
do a considerar ordenadores mixtos (analgico-digitales) y finalmente digitales, de-
bido a los avances en electrnica digital y en arquitectura de ordenadores. En la
prctica, esto ha llevado a considerar el tiempo de forma discreta.
Existen dos formas de ejecutar los modelos dinmicos por medio de una repre-
sentacin discreta del tiempo, dirigiendo la simulacin por el paso del tiempo (time-
driven) o por el acontecimiento de eventos (discrete-event o tambin denominados
event-driven). En el caso de simuladores dirigidos por tiempo, en cada unidad de
tiempo se evalan todos los componentes del sistema. Cada componente del siste-
ma se activa en todos los ciclos de simulacin, 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. Simulacin 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 sncrono (simulacin tambin conocida como cycle-
based simulation). Este tipo de avance del tiempo es sncrono, ya que despus de
cada salto (tick) o ciclo de reloj el tiempo se incrementa en una constante. El pro-
blema de implementar una simulacin con un avance sncrono del tiempo es que no
es posible representar funcionalidad que acontece simultneamente 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 simulacin basada en ciclos es que, aunque con menor precisin, permite
abordar periodos de simulacin mayores en menor tiempo real, ventaja de gran in-
ters cuando, por ejemplo, se presente simular el comportamiento de un sistema
electrnico compuesto de hardware y software.
3.2.1.2. Simulacin dirigida por eventos discretos

El paradigma de la simulacin dirigida por eventos discretos [14-17] se basa en la
existencia de dos componentes: uno que representa al propio modelo de simulacin
en estudio y que adems 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 simulacin. Este segundo componente representa a lo que se suele
denominar kernel o ncleo del simulador.
Kernel de
simulacin
Modelo de
simulacin
FEs
FIGURA 3-1. Flujo de eventos discretos.
La simulacin dirigida por eventos discretos representa un modelo de un siste-

ma dinmico sujeto a una serie de acontecimientos instantneos, denominados
eventos. En este tipo de simulacin, 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 discretizacin del tiempo est
implcita en el sistema, no est explcitamente impuesta por el simulador, como se-
ra el caso en un simulador dirigido por tiempo exclusivamente.
La suposicin de que no ocurre nada entre dos eventos, o, de forma ms preci-
sa, que el estado de los elementos que componen el modelo permanece constante
entre dichos instantes de tiempo, se satisface por un amplio nmero de sistemas rea-
les y adems se considera el Primer Paradigma de la simulacin dirigida por even-
tos discretos. -
En una simulacin, los eventos se originan a partir de un conjunto de Futuros
Eventos (FEs) que est bajo control del kernel o ncleo de simulacin. 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, vase la Figura 3-1. La longitud de las colas y la forma de insercin
de los futuros eventos, depende de cada lenguaje de simulacin. Las colas se va ac-
tualizando, de modo que se van eliminando los valores al ser reemplazado el valor
actual por el nuevo. Despus 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-
mulacin contina hasta que se vaca la cola de eventos o hasta que se alcanza una
condicin de parada (p. ej., lmite de tiempo de simulacin, 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 insercin 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 insercin preemptivos = planificacin dinmica).
Esencialmente, la planificacin de FEs consiste en las siguientes operaciones: la in-
sercin de nuevos FEs en las colas de FEs y la extraccin 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 aparicin
del evento. La planificacin 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 informacin el kernel puede llevar a cabo la planificacin
de las operaciones del modelo.
La propia naturaleza de la gestin de las colas de eventos limita el potencial
paralelismo de la simulacin dirigida por eventos. Se han sugerido algunas tcnicas
para la gestin de las colas de eventos y para la simulacin en paralelo, aunque el
paralelismo alcanzable es limitado. Tambin existen aceleradores hardware de altas
prestaciones que mantienen mltiples 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 difcil 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-
dra ser una direccin, una etiqueta o un ndice correspondiente a un vector de su-
brutinas, a menudo depender de la estrategia de simulacin que se est empleando.
La eleccin de esta estrategia afecta a la implementacin y al uso del lenguaje de si-
mulacin, o sea, a la realizacin de las herramientas de simulacin y al lenguaje con
el que stas se programan.
3.2.1.2.1. Estrategias de simulacin
En la simulacin dirigida por eventos discretos slo hay tres posibles estrategias: la
planificacin de eventos, la bsqueda de actividad y finalmente, la basada en la in-
teraccin de procesos. La estrategia basada en la interaccin de procesos se puede
considerar una combinacin de las otras dos, en la que se gana en eficacia de ejecu-
cin y adems se obtienen descripciones ms concisas.
La estrategia basada en la planificacin de eventos (Event Schedulling) es la
ms sencilla de todas. El comportamiento del modelo de simulacin depende de la
aparicin de eventos durante la ejecucin dinmica de la simulacin. Cuando apare-
ce un evento ocurren dos cosas: (1) se procesa el evento realizndose las operacio-
nes que para tal evento estn previstas; (2) se planifican los tiempos en los que po-
drn ocurrir los futuros eventos. De este modo es como se simula el comportamien-
to dinmico del modelo. El inconveniente que presenta esta estrategia es la
dificultad de activacin de las operaciones que se deben realizar en el modelo como
consecuencia de la aparicin de los eventos. Las decisiones de activacin 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 bsqueda de actividad (Activity Scanning). En este caso, co-
mo su nombre indica, la estrategia se basa en la bsqueda 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 planificacin de las operaciones que
debe realizar el modelo como consecuencia de la aparicin de un evento la realiza
el propio modelo de forma complementaria. La bsqueda de actividad mejora la
efectividad de la estrategia basada en la simple planificacin de eventos, pero puede
llegar a producir resultados poco eficientes.
Por ltimo, la estrategia basada en la interaccin de procesos soluciona los pro-
blemas de activacin que presenta la estrategia de planificacin de eventos al des-
cribir el modelo como una secuencia de actividades. En este caso las actividades se
corresponden con procesos, secuenciales y cclicos, que interactan unos con otros
de acuerdo con la aparicin de eventos. El gran problema de esta estrategia es la po-
sibilidad de que aparezcan deadlocks en la interaccin entre los procesos. Emplean-
do las estrategias basadas en la planificacin de eventos y en la bsqueda de activi-
dad, el problema de bloqueo no aparece debido a la naturaleza secuencial de dichas
estrategias y a la suposicin 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 bsicos de avanzar el tiempo en una simulacin de sistemas elec-
trnicos 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 gestin de eventos en el caso de la simulacin dirigida por eventos discretos.
3.2. 1.3. 1. Modelo Unit-delay

El modelo Unit-delay es la base de los simuladores clsicos de sistemas electrni-
cos descritos como transferencias entre registros tRegister Transfer Level, RTL).
Los modelos RTL describen las transformaciones sncronas 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 simulacin coincide con la unidad
bsica de ciclo de reloj). El valor absoluto, cuantitativo, del tiempo slo es necesa-
rio en la definicin de relojes externos. Este modelo de simulacin se caracteriza
por evaluar todas las expresiones de las sentencias de asignacin antes de efectuar
ninguna de las asignaciones. Este mtodo elimina cualquier posible ambigedad
que pudiera acarrear el orden en que se realiza la evaluacin de las expresiones. Es-
ta es la caracterstica ms relevante del modelo.
El diagrama de flujo de la Figura 3-2 muestra la presencia de dos tareas conse-
cutivas para la evaluacin y la asignacin de las expresiones.
El bucle representa el avance del tiempo de simulacin, 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 comunicacin
ms rpida se produce como mnimo en una unidad de tiempo. Esto no es ningn
problema cuando se modela lgica secuencial pura, pero s lo es cuando el sistema
tiene partes combinacionales. El modelo de simulacin basado en Unit-delay no
siempre es la mejor eleccin.
Evala y actualiza inmediatamente.

Aade nuevos eventos a la cola de eventos.
Aade nuevos eventos a la cola de eventos.
FIGURA 3-2. Modelos de simulacin Unii-delayy Zero-delay.
3.2.1.3.2. Modelo Zero-delay

La mayora 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 evaluacin y la actualizacin de las expresiones se reali-
zan en un solo paso. La caracterstica de este modelo es la comunicacin 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 asignacin usan los valores recin asigna-
dos, ya que los anteriores se pierden. Si no se define explcitamente entonces no es
posible predecir si una expresin, que lee un registro, emplear el valor antiguo o el
nuevo. Este tipo de problemas debidos al orden de ejecucin se denominan "carre-
ras" y son un problema aadido a la dificultad del propio modelado del sistema. El
modelo de simulacin basado en Zero-delay no siempre es la mejor eleccin.
3.2.2. Estructura general de la simulacin
El proceso de simulacin se desarrolla en las tres etapas mostradas en la Figura 3-3:

(a) inicializacin, (b) ejecucin y (e) terminacin.
1. La inicializacin. El modelo se instala en el ordenador, esto significa que

el modelo descrito por el diseador se elabora para producir un formato co-
dificado en un lenguaje de programacin de un ordenador digital. La etapa
de inicializacin concluye con la insercin de los valores que representan
las condiciones del estado inicial de la simulacin.
Inicializacin Ejecucin Terminacin
FIGURA 3-3. Etapas del proceso de simulacin.
2. La ejecucin. El modelo de simulacin se pone en movimiento, esto es, se

le permite mostrar su comportamiento dinmico bajo la accin del mecanis-
mo de avance del tiempo de simulacin. Una simulacin se puede progra-
mar para llevarse a cabo durante un determinado periodo de tiempo de si-
mulacin, o se puede hacer que finalice al satisfacerse ciertas condiciones
dadas previamente al comienzo de la etapa de ejecucin o animacin.
3. La terminacin. Cuando finaliza, de forma normal o anormal, la ejecucin
del programa que representa al modelo de simulacin, es cuando se puede
proceder a realizar un anlisis "post-mortem" de todo lo acontecido. Este
anlisis 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. Tambin
se puede realizar el anlisis de los resultados de forma interactiva durante la
propia etapa de ejecucin, parando la simulacin cada vez que se desea lle-
var a cabo dicho anlisis.
3.2.3. Aproximacin metdica a la simulacin
La estructura general de la simulacin, descrita anteriormente, se ha realizado desde

el punto de vista de la ejecucin 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 correccin/depuracin (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 aproximacin metdica a la simulacin.
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, especificacin
y descripcin, 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 simulacin.
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 diseador selecciona una serie
de casos de prueba de forma que su simulacin le ofrezca cierta confianza sobre la
verificacin del diseo. La precisin de los resultados de simulacin y, por tanto, la
cantidad de informacin obtenida acerca del comportamiento del sistema, varan
dependiendo de la complejidad y el grado de detalle o abstraccin de los modelos.
Una ayuda a la simulacin es la inclusin de aserciones en la descripcin del mode-
lo, que se deben verificar en tiempo de simulacin. .
En otras palabras, se trata de ver si la realizacin del modelo se corresponde
con la idea que se tiene de las especificaciones del sistema en cuestin. En cierto
modo, en este paso se est depurando el modelo a travs de un proceso de verifica-
cin. El grado de confianza que el diseador deposita en los casos de prueba est
directamente relacionado con la calidad del mtodo de diseo o modelado. Todava
no importa si el modelo representa adecuadamente o no al sistema en cuestin. Por
ahora es suficiente con asegurarse de que la ejecucin del modelo en el ordenador
ofrece los resultados esperados, segn se describieron en el plan de pruebas.
El modelo debe reflejar el comportamiento del sistema, para lo cual el disea-
dor establece un compromiso entre su precisin y su capacidad para la posterior
evaluacin de las respuestas. La verificacin del modelo de simulacin recae en la
generacin de los estmulos adecuados. El problema de este mtodo de verificacin
reside en la imposibilidad prctica de llevar a cabo una simulacin exhaustiva, de-
bido a la explosin de casos, de forma que garantice la correccin del diseo.
Una vez realizada la verificacin, la simulacin del modelo est funcionando a

entera satisfaccin del diseador, 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 mayora de las ocasiones es necesario rea-
lizar una serie de pruebas para determinar cmo de cercano est el modelo de las
especificaciones del sistema en cuestin. Estas pruebas corresponden al proceso de
validacin del modelo, que es una de las partes ms difciles de llevar a cabo.
3.2.3.3. Explotacin
Supongamos, de forma optimista, que el diseador ha conseguido un modelo de si-
mulacin ejecutable en el ordenador y que ha validado el modelo demostrando que
su operacin es una representacin correcta del sistema en cuestin. Finalmente,
antes de llevar a cabo la realizacin fsica del modelo, el diseador debe experimen-
tar o 'jugar" con el modelo de simulacin para incrementar su confianza en que el
sistema en cuestin respondera de forma similar a dichos experimentos. Aunque se
haya alcanzado la perfeccin en el desarrollo y las pruebas de verificacin y valida-
cin del modelo de simulacin, no se puede estar seguro del todo acerca de los re-
sultados de experimentar fuera de los lmites del conocimiento del sistema en cues-
tin. El diseador debe ser cauto a la hora de confiar en los resultados de la simula-
cin a la hora de experimentar fuera de dichos lmites.
3.3. PROCESADO DE UN LENGUAJE DE PROGRAMACiN
Un lenguaje de programacin es una notacin formal que se utiliza para poder ex-
presar algoritmos [18]. Por tanto, un programa es la descripcin en un determinado
lenguaje de programacin de un algoritmo. Pero no hay que olvidar que los algorit-
mos son conceptos abstractos, que existen independientemente de cualquier posible
notacin en la que stos se pudieran expresar. Sin embargo, sin la utilizacin de una
notacin es imposible expresar de forma precisa o comunicar un algoritmo, o razo-
nar acerca de su correccin.
3.3.1. Procesadores de lenguajes
Un procesador de un lenguaje de programacin [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 programacin. 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 intrpretes. Un traductor (Translator) es un determinado tipo de procesador que
acepta como entrada o fuente cualquier texto descrito o expresado en un lenguaje de
programacin determinado, denominado lenguaje fuente (Source Language), y que
genera como salida un texto semnticamente equivalente expresado en otro lengua-
je de programacin, denominado destino (Target Language}, Un intrprete (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 cdigo o lenguaje directamente eje-
cutable por el intrprete. Dado que inicialmente el intrprete era una mquina im-
plementada con tecnologa electrnica hardware, al lenguaje fuente del procesador
se le denomin lenguaje o cdigo de la mquina (Machine Code).
Para que el cdigo mquina no sea el nico cdigo interpretable es necesario
combinar ambos tipos de procesadores. De esta forma se puede conseguir que un
lenguaje distinto al cdigo mquina tambin puede ser interpretado por dicha m-
quina. Los primeros lenguajes de programacin distintos al cdigo mquina, deno-
minados lenguajes ensambladores (Assembly Languages), se basaban en la utiliza-
cin de nombres simblicos para las operaciones y los datos. Ambos tipos de len-
guajes, los de las mquinas y los ensambladores, pertenecen a la categora de
lenguajes de programacin de bajo nivel (Low Level Programming Languages), de-
nominados as por forzar a expresar los algoritmos que se desean procesar en trmi-
nos cercanos a las instrucciones que puede ejecutar directamente la electrnica sub-
yacente al procesador. En contraposicin a estos lenguajes de programacin de bajo
nivel, actualmente se utilizan los lenguajes de programacin de alto nivel (High Le-
vel Programming Languages, HLLs) que permiten la expresin de los algoritmos a
un nivel de abstraccin ms cercano al lenguaje interpretable por el ser humano que
por el procesador electrnico hardware. Los HDLs son un caso particular de HLLs,
cuyo propsito es la descripcin virtual (software) o fsica (hardware) de un sistema
electrnico. El procesado por ordenador de una descripcin HDL es parte de las
ayudas o herramientas que permiten la automatizacin del diseo de sistemas elec-
trnicos (Electronic Systems Design Automation, ESDA) antiguamente tambin co-
nocidas como CAD/CAE (Computer Aided DesignlComputer Aided Engineering).
Hasta ahora nada se ha dicho de la tecnologa en la que el procesador de un
lenguaje puede estar implementado. Aunque desde una perspectiva histrica se po-
dran tener en cuenta implementaciones mecnicas e incluso electromecnicas, des-
de que se invent el transistor slo se consideran procesadores electrnicos hardwa-
re y/o software. Atendiendo a la implementacin del procesador, se puede conside-
rar que el sistema electrnico hardware 1 en el que se lleva a cabo la ejecucin de un
programa en cdigo mquina es un procesador hardware (Hardware Processor o
Computer Architecture). Por otra parte, un programa tambin 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
electrnico software (Software Processor). Por tanto, todo procesador software lle-
va implcitamente asociado un procesador hardware, vase la Figura 3-5.
1 Un ordenador o computadora es un caso de procesador implementado por medio de un sistema

electrnico hardware, este tipo de procesadores se denominan microprocesadores (IlProcesador) cuan-
do se implementan con tecnologa microelectrnica.
Programa
Programa
1-
Programa
1- Procesador
Hardware
Procesador
Software Procesador
Hardware
FIGURA 3-5. Procesadores electrnicos Hardware y Software.
3.3.2. Compiladores Software, Hardware e hbridos
Cuando el traductor de un lenguaje cambia el nivel de abstraccin entre sus lengua-

jes fuente y destino, entonces el procesador se denomina compilador (Compiler)
[20-23]. Como se present en la seccin anterior, para ejecutar un programa descri-
to en un lenguaje de mayor nivel que el del intrprete que lo procesa es necesario
traducir el programa al lenguaje del intrprete previamente a su ejecucin, lo que
equivale a realizar dos procesos sobre dicho programa: compilacin y ejecucin.
Hasta ahora slo se ha considerado la posibilidad de que el resultado de la
compilacin puede ser cdigo ejecutable posteriormente por un intrprete o proce-
sador (hardware o software) del lenguaje destino cuya existencia era previa a la
compilacin del programa. En particular, cuando el programa est escrito en un
HDL para su simulacin por ordenador es necesario procesar la descripcin HDL
por medio de un compilador software de dicho HDL. De este modo se puede gene-
rar el programa correspondiente al modelo de simulacin que se ejecutar finalmen-
te en el ordenador.
Sin embargo, el resultado de la compilacin de un programa (HDL) tambin
puede corresponder con una descripcin de un procesador hardware especfico, cu-
ya implementacin 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 contraposicin al otro tipo de compiladores que,
siendo ms precisos, se les debera llamar compiladores de software, vase la Figu-
ra 3-6.
Dependiendo de la semntica de la descripcin HDL, o lo que es lo mismo, del
propsito para el que se ha realizado dicha descripcin, su procesado dar lugar a
un modelo software de simulacin o a la sntesis del hardware esperado. Tambin
cabe una posibilidad hbrida entre las compilaciones hardware y software, la resul-
tante de la emulacin hardware de una descripcin HDL. La emulacin es una tc-
nica experimental similar a la simulacin por ordenador en la que el modelo no es
Programa Programa Intrprete
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 compilacin hardware de la descripcin

HDL se lleva a cabo programando un hardware provisional cuyo comportamiento
emula al del sistema electrnico que se desea realizar. No hay que confundir la im-
plementacin hardware provisional con la que se genera el modelo de emulacin
con la generacin de un prototipo hardware del sistema que resultara de una com-
pilacin o sntesis hardware pura. Dicho hardware provisional se puede considerar
que est ms cercano a un modelo hardware de simulacin por ordenador, si se ex-
tendiese la definicin de esta tcnica para tratar indistintamente con modelos soft-
ware o hardware. Evidentemente, esta extensin de la definicin de la simulacin
por ordenador slo es aplicable al dominio de los sistemas electrnicos, ya que para
otros sistemas fsicos carece de sentido.
Hasta ahora se ha considerado la utilizacin de un programa bien para ser eje-
cutado en un ordenador, que lleva implcito un procesador hardware de propsito
general o de propsito especfico (caso de los denominados aceleradores de hard-
ware), o bien para generar un hardware especfico, provisional o definitivo. Sin em-
bargo, como parte de los nuevos mtodos de diseo que estn apareciendo para po-
der tratar adecuadamente los sistemas electrnicos empotrados (Embedded Systems)
[24-26], se espera que aparezcan nuevos lenguajes, denominados de especificacin
de sistemas electrnicos (hardware y software), que darn lugar a un nuevo tipo de
compiladores: el cosintetizador o compilador concurrente de hardware y de softwa-
re [27-29]. La compilacin de este tipo de lenguajes dar lugar a la implementacin
del sistema electrnico por medio de la realizacin de un hardware determinado,
que incluir un procesador hardware que a su vez tratar la parte del sistema elec-
trnico que como resultado de la cosntesis 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 hbridos a la que pertenecen los
1 50 VHDL. Lenguaje estndar de Diseo Electrnico
emuladores hardware. Salvando las distancias y considerando dos grandes diferen-

cias: que la descripcin que se compila no toda ella se desea implementar en hard-
ware y que la parte hardware que se compila es su implementacin definitiva y no
un modelo hardware para experimentacin.
3.3.3. Especificacin de un lenguaje de programacin
Un lenguaje de programacin se puede especificar informalmente por medio del

uso de un lenguaje natural como el espaol o el ingls, corriendo el riesgo de que
dicha especificacin pueda dar lugar a malinterpretaciones debido a la presencia de
ambigedades, inconsistencias o carencia de completitud, o se puede hacer formal-
mente por medio de una notacin precisa que permita eliminar las ambigedades y
ofrecer una especificacin 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 sintcticas impuestas por el contexto (Con textual Cons-
traints), tambin denominadas semntica esttica.
3. La semntica dinmica o simplemente semntica (Semantics).
3.3.3.1. Sintaxis
La sintaxis (Syntax) del lenguaje define los smbolos (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 gramtica in-
dependiente del contexto (Context-Free Grammar, C-FG). Una gramtica C-FG se
define matemticamente como una 4-tupla (X, N, S, P) , compuesta de los siguien-
tes elementos: (1) X, El alfabeto de smbolos terminales con los que se forman las
cadenas (Strings) que forman los tokens; (2) N, el conjunto de smbolos 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 smbolos terminales y no terminales forma el vocabulario
de la gramtica; (4) P, el conjunto de reglas de produccin de cadenas del lenguaje
que definen cmo se componen las frases a partir de los smbolos terminales y de
las frases.
A su vez, las gramticas C-FG se suelen especificar mediante dos formas: (a)
Notacin BNF (Backus-Naur Form) o su variante EBNF (notacin BNF extendida
con notacin especfica de expresiones regulares [Regular Expressions] Extended
BNF) introducida por Niklaus Wirth; (b) Diagramas Sintcticos (Syntax Diagrams),
donde las reglas de produccin se describen por medio de grafos dirigidos.
Expresin
I
Expresin primaria ExpreSin primaria I

Expresin 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 expresin "d + 10 * n:".
Cada C-FG genera un lenguaje, que no es otra cosa que un conjunto de cadenas
de smbolos 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 sintcticos (Syntax Trees, STs). Un ST de una C-FG es un rbol
ordenado donde los nodos terminales estn etiquetados por smbolos terminales y
los nodos no terminales lo estn por smbolos no terminales a los que estn asocia-
das cada una de las reglas de produccin. As, una frase de la gramtica C-FG es
una cadena de smbolos terminales que etiqueta a los nodos terminales del ST, to-
mados de izquierda a derecha. Una sentencia de la gramtica C-FG es una frase
donde el nodo raz del ST correspondiente es el smbolo S (Start Symbol).
Debido a su precisa descripcin de los detalles sintcticos, la gramtica C-FG
descrita anteriormente se dice que se refiere a la sintaxis concreta (Concrete Syntax)
del lenguaje, que es de especial inters para el usuario final del lenguaje, ya que tie-
ne que conocer concretamente cmo se deben escribir programas sintcticamente
correctos.
Sin embargo, no siempre es necesario centrarse en la expresin concreta de un
lenguaje sino que basta con centrarse en el conocimiento de la estructura de sus fra-
ses. En estos casos la gramtica CF-G se refiere a la sintaxis abstracta del lenguaje
(Abstraet Syntax) y los rboles sintcticos que se generan se denominan ASTs (Abs-
traet Syntax Trees). En los ASTs cada nodo no terminal se etiqueta con una regla de
produccin y le corresponde un nico subrbol por cada subfrase, ya que los smbo-
los terminales no juegan un verdadero papel en la sintaxis abstracta. Las sintaxis
abstracta slo se preocupan de las relaciones jerrquicas existentes entre las frases y
las subfrases. Las sintaxis concretas adems se ocupan de los smbolos utilizados
para separar y anidar las frases del lenguaje.
Expresin-Operador-Expresin IEOE)
v v
I I
~ ]clJ ~
FIGURA 3-8. AST de la expresin "d + 10 * n:",
3.3.3.2. Restricciones de contexto

Las gramticas C-FG deben su nombre a que se puede determinar la correccin de
las frases que componen dichos lenguajes independientemente del contexto en el
que stas se encuentren. Sin embargo, en la mayora de los lenguajes de programa-
cin esto no suele ser as y por ello es necesario considerar otro tipo de gramticas,
las denominadas sensibles al contexto (Context-Sensitive Grammars, C-SG). Las
restricciones sintcticas impuestas por el contexto (Con textual Constraints), tam-
bin se suelen denominar semntica esttica del lenguaje, vienen dadas por las re-
glas de mbito (Scope rules), que permiten determinar el mbito de cada declara-
cin para as permitir localizar la declaracin de cada una de los identificadores, y
las reglas de los tipos (Type rules), que permiten inferir el tipo de cada expresin
para as asegurar que las operaciones se realizan con los operandos adecuados.
En la prctica las gramticas C-SG se especifican por medio de gramticas con
atributos (Attribute Grammar). Este tipo de gramticas se especifican por medio de
la tripleta (G, V, F), donde G es la 4-tupla correspondiente a la gramtica C-FG, V
es el conjunto de atributos que se aaden a los nodos del AST generado por la gra-
mtica 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 adicin de V y F a la gramtica C-FG se consiguen aadir
las restricciones contextuales que permiten discernir qu frases son correctas para la
gramtica C-SG de entre todas aquellas que se podran generar a partir de la gram-
tica C-FG.
3.3.3.3. Semntica
La semntica dinmica, o simplemente semntica (Semantics), define el significado

de los programas por medio del comportamiento que dichos programas muestran al
ser procesados. La semntica de los programas cuyo procesado tiene como finali-
dad ltima su ejecucin se suelen especificar por medio de los pasos u operaciones
por medio de las cuales se lleva a cabo su ejecucin. Este tipo de especificacin se
denomina semntica operacional (Operational Semantics). Una forma de especifi-
cacin alternativa es la semntica denotacional (Denotational Semantics), que con-
siste en considerar a un programa como si fuese una funcin matemtica que trans-
formase las entradas en las salidas, centrndose ms en qu hace el programa que
en cmo se lleva a cabo.
3.3.4. Proceso de compilacin de un lenguaje

de programacin
Todo compilador de un lenguaje de programacin consta de dos etapas. La primera
de ellas, o fachada (front-end) del compilador, se denomina anlisis y se compone
de tres procesadores esenciales: el reconocedor o analizador lxico (scanner), el re-
conocedor o analizador sintctico (parser) y el analizador de la semntica esttica
o tambin denominado.analizador de la sintaxis restringida por el contexto (contex-
tual constrainer o static semantics analyser).
El trabajo de la etapa de anlisis 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 smbolo
terminal del lenguaje y suele acabar generando una estructura de datos que repre-
senta la estructura del lenguaje normalmente en forma de AST. La generacin ex-
plcita 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 compilacin del programa o cdigo fuente.
La segunda parte o etapa posterior (back-end) de todo compilador se denomina
sntesis y se dedica a la generacin y optimizacin del software que se genera, pu-
diendo tambin generar hardware en el caso de estar compilando una descripcin
HDL.
Entre cada dos fases de una compilacin se genera y se comunica una estructu-
ra de datos de tipo AST, denominada representacin o formato intermedio (Inter-
mediate Format, IF), que contiene toda la informacin 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. Adems, la definicin de los IFs facilita el mantenimiento y el
desarrollo continuado de los compiladores de los lenguajes de programacin y, por
tanto, facilita la propia evolucin de la definicin de los lenguajes (especialmente
aquellos que son standards y que se revisan peridicamente, 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. SIMULACiN DE UNA ENTIDAD DE DISEO VHDL
La simulacin de una entidad de diseo VHDL consiste en la ejecucin monitoriza-

da por medio de un ordenador de su modelo de simulacin. Dicho modelo, consis-
tente en una red de procesos VHDL interconectados entre s, se obtiene como resul-
tado del proceso de elaboracin de la jerarqua de diseo con la que se ha descrito
la entidad de diseo que se desea simular [31-33]. El flujo de control de la ejecu-
cin del modelo de simulacin es capaz de representar el tiempo y con su evolucin
es capaz de representar el comportamiento dinmico 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 jerarqua de
diseo.
La simulacin de una entidad de diseo VHDL la realiza un simulador, o mejor
dicho, un entorno de simulacin. Dicho entorno se encarga de dos tareas: (1) gene-
rar el modelo de simulacin correspondiente a una determinada entidad de diseo
VHDL, (2) suministrar al diseador de VHDL los resultados de la monitorizacin
de la ejecucin de dicho modelo, interpretando dichos resultados en trminos rela-
cionados con el cdigo fuente correspondiente a la descripcin VHDL que maneja
el diseador. As, un simulador VHDL se puede ver como la composicin de:
1. Un procesador de la descripcin VHDL encargado de analizar las unidades

de diseo VHDL que describen la entidad de diseo VHDL y de elaborar la
jerarqua de diseo para dar lugar a la red de procesos VHDL que se desea
simular.
2. Un compilador del modelo de simulacin 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 ejecucin del programa correspondiente a la red de proce-
sos en trminos de la descripcin VHDL correspondiente a la entidad de di-
seo en estudio.
Tanto el compilador del modelo de simulacin 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 atencin para poder comprender la tarea de simulacin VHDL. Sin embargo,
dado que el procesador de VHDL tiene que hacerse cargo tanto de la sintaxis como
de la semntica esttica y dinmica de VHDL, a continuacin 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 descripcin VHDL
El LRM del lenguaje VHDL define, de un modo informal en ingls, la sintaxis y la

semntica operativa del lenguaje, o sea, los pasos a seguir para que una descripcin
VHDL se pueda procesar en un ordenador con el propsito de simular su comporta-
miento. De acuerdo con el LRM, como se puede apreciar en la Figura 3-9, antes de
poder simular una descripcin 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], vase 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 anlisis
lxico y sintctico (Lexieal y Syntax Analysis) de una determinada unidad de diseo
(Design Unit). Cabe resaltar que la descripcin BNF de la gramtica de VHDL, que
se presenta en el LRM como un anexo, no forma parte de la definicin de la norma
(Standard). Esto es una muestra ms, aadida a la ambigedad que puede ofrecer la
descripcin en lenguaje natural, de la informalidad que ofrece la actual definicin
del standard, por ejemplo, el LRM.
El segundo AST resulta de aplicar las reglas de restriccin de tipos y de mbito
correspondientes al arilisis de la semntica esttica (Statie Semanties Analysis) de
una determinada unidad de diseo VHDL (Design Unit). Este AST, dada su tras-
cendencia, como se ver posteriormente, se suele denominar como la representacin
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 diseo VHDL, sino que resulta de la composicin de los ASTs corres-
pondientes a todas las unidades de diseo 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. Anlisis, elaboracin y simulacin de una descripcin VHDL.

Anlisis Anlisis Generacin del

Sintctico Semntico Modelo de Simulacin
Esttico
Fichero de Diseo VAST

VHDL
FIGURA 3-10. Formatos intermedios de anlisis, elaboracin y simulacin VHDL.
minada entidad de diseo VHDL, despus de llevar a cabo el proceso de elabora-

cin de la jerarqua de diseo. Este AST se suele denominar (Elaborated AST,
EAST) por corresponder con la extraccin de la heterarqua 2 de procesos VHDL
como resultado de la elaboracin esttica de una entidad de diseo VHDL. Aunque
este AST se corresponde con el resultado de una fase de compilacin propiamente
dicha, no se corresponde con el verdadero resultado de la elaboracin esttica de
acuerdo con el LRM. Dicha elaboracin finaliza realmente con la generacin del
modelo de simulacin, o sea, con la interconexin de los procesos VHDL resultan-
tes y, por tanto, el AST resultante de esta etapa de procesado debera 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-
cin VHDL; todava es necesario realizar otra compilacin para poder generar el
correspondiente programa ejecutable por un ordenador, incluyendo la informacin
necesaria para su posterior depuracin (debugging},
3.4.1.1. Anlisis de una unidad de diseo VHDL
La unidad bsica de modelado en VHDL es la entidad de diseo (VHDL Design

Entity). Una entidad de diseo se corresponde con cualquier entidad u objeto que
forme parte de un sistema electrnico, 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 jerarqua en la que pueden encontrarse objetos dentro de otros objetos, co-
mo, por ejemplo, la jerarqua de funciones anidadas en el lenguaje e, en una heterarqua todos los ob-
jetos se encuentran al mismo nivel. En el cas del resultado de elaborar una jerarqua de diseo VHDL
se obtiene una red de procesos VHDL en los cuales no existen procesos VHDL anidados.
La unidad bsica de procesado en VHDL es la unidad de diseo (VHDL Design

Unit). Hay dos tipos de unidades de diseo: primarias (declaraciones de entidad, de
configuracin y de paquete) y secundarias (el cuerpo de arquitectura de una entidad
y el de un paquete). No hay que confundir entidad de diseo con unidad de diseo.
Una entidad de diseo se describe por medio de varias unidades de diseo, como
mnimo tiene que existir una declaracin de entidad a la que se le puede asociar un
cuerpo de arquitectura directamente o por medio de una declaracin de configura-
cin. Cada unidad de diseo 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 diseo pueden hacer re-
ferencia posteriormente.
Una descripcin VHDL, vase la Figura 3-11, puede estar compuesta por uno o
varios ficheros textuales en los que estn contenidas las descripciones correspon-
dientes a las unidades de diseo. Cada unidad de diseo est precedida por la decla-
racin de su contexto, o sea, de las bibliotecas o de las unidades de biblioteca espe-
cficas que usa o, dicho de otra forma, de las que depende para su anlisis, vase la
Figura 3-11.
Las unidades de diseo que forman parte de un mismo fichero de diseo
VHDL se analizan secuencialmente. Cada unidad de diseo se analiza de forma in-
dependiente y da lugar a una unidad de biblioteca de diseo (VHDL Design Library
Unit). Estas unidades se organizan en un sistema (VHDL Design Library System) de
bibliotecas de diseo VHDL (VHDL Design Libraries). La biblioteca en la que se
almacenan las unidades recin 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 vara en cada
FIGURA 3-11. Una descripcin VHDL, compuesta por unidades de diseo almace-
nadas como texto en los ficheros de diseo correspondientes (11.a), el sistema de
unidades de bibliotecas en el que se almacenan los resultados del anlisis de las
unidades de diseo (11.b) y una representacin alegrica de dicho sistema de unida-
des de biblioteca (11.c).
momento, ya que tan slo es una biblioteca lgica que en el momento de realizar el
anlisis se asocia con una biblioteca fsica determinada por el diseador de VHDL.
Los ficheros de diseo 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 implementacin del sistema
de procesado de VHDL que se est utilizando.
El Captulo 11 del LRM describe el proceso y el orden de anlisis de las uni-
dades de diseo VHDL. El Captulo 13 del LRM define los elementos sintcticos
que pueden formar parte de una descripcin VHDL. Sin embargo, las reglas sin-
tcticas, las de mbito y las de tipos se encuentran distribuidas por todo el LRM,
no existiendo una definicin de dichas reglas como tal. Estas reglas se pueden ob-
tener por medio de una lectura cuidadosa y cruzada de todos los prrafos que com-
ponen el LRM. Con estas reglas se puede realizar tanto un scanner y un parser pa-
ra realizar el anlisis lxico y sintctico, respectivamente, como el anlisis semn-
tico esttico de una unidad de diseo VHDL. Por tanto, el anlisis de una unidad
de diseo VHDL genera dos ASTs correspondientes a las dos primeras fases de
compilacin: VAST y VIF. Aunque el VAST suele desaparecer una vez generado
el VIF.
El resultado final del anlisis de una unidad de diseo, o sea el VIF, se almace-
na como una unidad de biblioteca. Si una unidad de biblioteca de diseo se modifi-
ca por algn motivo, entonces todas las unidades de diseo que dependen de ella
quedan declaradas automticamente como obsoletas y es preciso realizar su anlisis
antes de poder ser utilizadas posteriormente.
Cuando finaliza el anlisis de una unidad de diseo slo se puede decir de ella
que su descripcin textual estaba escrita en VHDL de forma correcta atendiendo al
LRM, pero nada se puede decir del sistema electrnico, de cuya descripcin forma
parte, ni del uso posterior que se va a hacer de ella (p. ej., simulacin, sntesis, etc.).
De hecho, el anlisis es la nica etapa del procesado de VHDL que es comn a
cualquier tipo de uso que se vaya a hacer de una unidad de diseo VHDL [37].
El anlisis individual de las unidades de diseo es algo nico del lenguaje
VHDL, no existe ningn otro HDL con esta caracterstica. Esta particularidad no
slo afecta al procesado de VHDL, sino que adems permite la creacin de bibliote-
cas configurables por medio de la capacidad intrnseca de configuracin que posee
el lenguaje VHDL. Esta es la base que permite la reutilizacin del diseo en VHDL
y la posible explotacin de los derechos de propiedad (Intellectual Property Rights,
IPRs) de dichos diseos.
3.4.1.2. Elaboracin de una jerarqua de diseo VHDL

Una entidad de diseo se describe en VHDL por medio de una declaracin de enti-
dad as como de un cuerpo de arquitectura o de la declaracin de configuracin co-
rrespondiente, junto con todas aquellas unidades de diseo a las que se haga refe-
rencia. El cuerpo de arquitectura de una entidad de diseo y, por tanto, la entidad de
diseo correspondiente, se puede describir por medio de una jerarqua de bloques,
cada uno de los cuales describe una parte de la entidad de diseo. Cada bloque est
compuesto por sentencias concurrentes, de las cuales cabe destacar el proceso, por
3. Procesado V mecanismos de simulacin del lenguaje VHDL 159
estar ste, a su vez, compuesto de sentencias secuenciales. Adems de considerar

un cuerpo de arquitectura como una jerarqua de bloques, tambin puede ste hacer
referencia a otras entidades de diseo consideradas como componentes. Desde este
punto de vista tambin se puede decir que una entidad de diseo se describe por
medio de una jerarqua de entidades de diseo, donde cada una de ellas est descrita
por medio de las unidades de diseo correspondientes.
El Captulo 12 del LRM describe el proceso de elaboracin del modelo de si-
mulacin correspondiente a una determinada entidad de diseo. En dicho proceso la
jerarqua de diseo se desmonta para dar lugar a una heterarqua o red plana de pro-
cesos VHDL. Para realizar este proceso es necesario indicar la entidad de diseo
que se desea elaborar por medio del par de unidades de diseo correspondientes a
una declaracin de entidad y a uno de sus posibles cuerpos de arquitectura, o por
medio de una unidad de diseo correspondiente a la declaracin de configuracin
de la entidad de diseo en cuestin.
Todas las unidades de diseo referenciadas por la entidad de diseo, cuya jerar-
qua se desea elaborar, deben ser analizadas previamente. Durante el proceso de ela-
boracin, dicha entidad de diseo se considera como el nivel superior de la jerar-
qua de diseo que se desea elaborar y a partir del VIF correspondiente a la declara-
cin de dicha entidad se aade el VIF correspondiente al cuerpo de arquitectura
seleccionado y todos los VIFs correspondientes a todas las entidades de diseo que
aparecen como componentes. A su vez, cada unidad de biblioteca que se procesa
aporta los VIFs correspondientes a las unidades de diseo que forman parte de su
contexto. Logrndose como resultado de la elaboracin de una jerarqua de diseo
un nuevo AST (EAST) en el que slo queda informacin de los procesos VHDL
junto con las sentencias secuenciales que los componen.
La heterarqua de procesos VHDL resultantes de la elaboracin de una entidad
de diseo est compuesta por los procesos VHDL descritos explcitamente en las
unidades de diseo correspondientes, o implcitamente por medio de sentencias
concurrentes que desaparecen durante su correspondiente elaboracin.
La Figura 3-12 esquematiza la informacin correspondiente a una entidad de
diseo cuyo cuerpo de arquitectura contiene un nico proceso VHDL explcito y la
instanciacin de un componente que a su vez contiene tres procesos VHDL, pu-
diendo formar parte de una jerarqua de bloques y pudiendo ser alguno de ellos el
resultado de elaborar una sentencia (de asignacin de seal) concurrente. La asocia-
cin del componente se realiza a travs de un puerto (inout) bidireccional (F), o se-
al formal, que se une a la seal actual (A). Todas las seales del ejemplo son expl-
citas y escalares, para facilitar su seguimiento.
Como resultado de la primera fase de elaboracin de la jerarqua de diseo
VHDL descrita en la Figura 3-12, aparece la heterarqua de procesos VHDL descri-
ta en la Figura 3-13. En esta figura no se hace referencia al nivel jerrquico del que
proviene cada uno de los procesos para hacer mayor nfasis en la heterarqua o es-
tructura plana resultante. Se ha incluido informacin relacionada con las colas de
los Futuros Eventos (FEs), asociados con cada asignacin de seal denominados
drivers en VHDL.
File
Wait. .
Wait .
z= .
F <= .
A<= .
P1
Design Hierarchy
Figura 3-12. Esquema de una entidad de diseo 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 bsicos de una simulacin diri-
gida por eventos discretos. Por completitud, tambin se ha incluido en la Figura 3-13
informacin relacionada con el uso de una variable compartida y de un fichero.
La segunda fase de compilacin correspondiente a la elaboracin de una jerar-
qua de diseo realiza los enlaces necesarios en el EAST, vase la Figura 3-14, de
modo que la red de procesos VHDL quede lista para su simulacin. Dichos enlaces
se realizan teniendo en cuenta las reglas correspondientes a la propagacin 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-

boracin de la entidad de diseo de mayor nivel de la jerarqua de diseo 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-

boracin de la entidad de diseo de mayor nivel de la jerarqua de diseo de la Figu-
ra 3-12.
valores de las seales explcitas e implcitas descritas en el Captulo 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 cmo los valores actuales (Current Value) de
las colas de eventos correspondientes a las sentencias de asignacin de la seal es-
calar F de los procesos P2 y P3 se componen, por medio de la funcin de resolucin
asociada a la declaracin de la seal correspondiente al puerto F, para as poder
calcular el valor conducido (Driving Value) del puerto F. A dicho valor se le aplica
la funcin de conversin asociada para poder componerlo, con el valor actual resul-
tante de la sentencia de asignacin de la seal A del proceso PI, por medio de la
funcin de resolucin asociada a la declaracin de la seal A. De esta forma es co-
mo se calcula el valor conducido de la seal A. Como se puede ver, los valores con-
ducidos de las seales se calculan desde el nivel ms bajo de la jerarqua para aca-
bar en el de nivel superior, o sea, de abajo a arriba.
Una vez calculados los valores conducidos de todas las seales ya se puede pa-
sar a realizar el clculo 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 seal F Red de la seal A
Figura 3-15. Redes de las seales 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 funcin de
conversin 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 seales A y F, que comuni-
can a los procesos VHDL de la Figura 3-14.
El valor efectivo de una seal pasa a ser el valor actual (Current Value) que di-
cha seal tendr en el prximo ciclo de simulacin, por ello se dice que sobre dicha
seal se ha producido una transaccin (Transaction). Este valor es el que se obten-
dr en el siguiente ciclo de simulacin cuando se lleve a cabo la lectura que se hace
de la seal F en el proceso P4. Si al producirse una transaccin en una seal, su va-
lor actual cambia con respecto al que tena anteriormente, entonces se dice que di-
cha transaccin ha generado un evento (Event) sobre dicha seal.
La comunicacin entre procesos por medio de variables compartidas se realiza
como en cualquier lenguaje de programacin, 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 elaboracin, el EAST se transforma en
SAST y ser el tipo de informacin que se utilizar/almacenar en cada paso de si-
mulacin de la entidad de diseo VHDL en cuestin. La elaboracin de la jerarqua
de diseo, correspondiente a una determinada entidad de diseo, se puede ver, des-
de el punto de vista de compilacin de un lenguaje de programacin, como el ver-
dadero final de la etapa de anlisis de la descripcin ,VHDL correspondiente a dicha
entidad y que se ha realizado de forma incremental en cada una de las unidades de
diseo referenciadas.
Todas las descripciones realizadas en un HDL, e incluso en cualquier HLL, con

semntica de simulacin dirigida por eventos discretos y basada en el paradigma de
procesos comunicantes comparten el mismo modelo de informacin resultante de la
elaboracin esttica de una jerarqua de diseo VHDL. Se hace nfasis en la carac-
terstica esttica de la elaboracin de VHDL porque hay tres elementos que se ela-
boran en tiempo de ejecucin, o sea dinmicamente. Por completitud, estos elemen-
tos son: la creacin del parmetro de los bucles (loop) y la comprobacin de su ran-
go, la asociacin de parmetros formales y actuales de las llamadas a subprogramas
(subprogram), la ejecucin de un acceso a travs de un puntero (access).
La simulacin de la red de procesos VHDL descrita por el SAST todava tiene
que ser compilada al lenguaje interpretable o ejecutable por el procesador en el que
se desea realizar la simulacin. En el primer caso se dice que la simulacin es inter-
pretada y en el segundo que es compilada, pudiendo en este caso ser compilada al
cdigo mquina del ordenador y denominarse entonces simulacin compilada en
cdigo nativo.
3.4.1.3. Simulacin de una entidad de diseo VHOL

La simulacin de una entidad de diseo comienza inicializando los valores de todos
los objetos, variables y seales que forman parte de la heterarqua de procesos
VHDL. Ello implica el clculo de los valores conducidos y efectivos de todas las
seales, la puesta a O de la variable que recoge el tiempo correspondiente al ciclo
actual de simulacin, Te, y al prximo ciclo de simulacin, Tn, as como la ejecu-
cin 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 inicializacin
del modelo de simulacin correspondiente no podra acabar nunca y, por tanto, ja-
ms se podra llevar a cabo su simulacin.
Como resultado de la ejecucin de las sentencias de asignacin de seal que
aparecen en los procesos VHDL, las colas de los FEs se llenarn con las proyeccio-
nes de los valores que contribuirn al clculo de los valores de las seales. Estos va-
lores son slo proyecciones, ya que algunos de ellos nunca alcanzarn a ser el valor
actual de una cola de FEs por ser eliminado por la ejecucin de una sentencia de
asignacin posterior (premption}.
La Figura 3-16 muestra el ciclo de simulacin. Una vez finalizada la etapa de
inicializacin del modelo de simulacin, o sea cuando todos los procesos VHDL
han parado su ejecucin comunicndoselo al ncleo (kernel) del simulador VHDL,
entonces dicho kernel pone el nuevo valor de la variable correspondiente al tiempo
de simulacin actual, Te, al valor de Tn Si dicho valor se corresponde con el mxi-
mo tiempo de simulacin (TIMEHIGH), dado por el diseador al lanzar la ejecu-
cin de la simulacin, 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-
cin, o sea procesos cuyo tiempo mximo de espera establecido en la sentencia de
espera en la que se pararon no se corresponda con Te, entonces la simulacin se da-
ra por finalizada.
FIGURA 3-16. Modelo de simulacin VHDL compuesto por una red de procesos
VHDL.
De no darse las condiciones para dar por finalizada la simulacin, entonces el

kernel del simulador VHDL actualiza el valor de todas las seales explcitas y a
continuacin hace lo mismo con las seales implcitas. Como resultado de dichas
actualizaciones se pueden producir eventos en algunas seales por lo que el kernel
revisar la lista de procesos sensibles a dichas seales y si para alguno de ellos se
cumple la condicin de espera o, independientemente, si se ha alcanzado su tiempo
mximo de espera, entonces pasar a formar parte de la lista de procesos cuya eje-
cucin se reactivar en el siguiente paso de simulacin.
Una vez que ya no quedan procesos por ejecutar sin cambiar el tiempo de si-
mulacin, pudindose haber generado ms de un paso de simulacin (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 estn listos para poder reasumir su control.
Cuando ya no queda ningn proceso pendiente de su ejecucin para el tiempo
de simulacin Te, entonces el kernel calcula el nuevo valor de T, como el menor va-
lor entre: TIMEHIGH, el prximo tiempo de simulacin en el que algn driver es-
tar activo, o el prximo tiempo de simulacin en el que se cumpla la condicin de
espera temporal de algn proceso.
3.4.1.4. Modelo Temporal <5-delay

Cada repeticin en la ejecucin del kernel se denomina un ciclo de simulacin. Pero
la definicin del ciclo de simulacin es recursiva, de modo que un ciclo puede invo-
lucrar la ejecucin de varios pasos de simulacin.
Los pasos de simulacin slo se diferencian del ciclo de simulacin en que en
ellos el valor del tiempo fsico no vara, sino que se incrementa otra variable que re-
presenta avances infinitesimales de tiempo (8-delay), uno por cada paso de simula-
cin. De este modo VHDL permite la comunicacin de datos entre procesos en
tiempo menor que la mnima unidad fsica (1 fs). Si se utilizan variables comparti-
das entonces se produce la comunicacin 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. Adems, el modelo
Zero-delay ya fue comentado anteriormente, por lo que el resto de esta seccin 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 simulacin se produce en tiempo menor
que la unidad, en un 8-delay, aunque no hay que confundir con la comunicacin en
tiempo cero. Esta sub-unidad no tiene significado fsico o cuantitativo, el diseador
no puede generar eventos explcitamente para un determinado paso de simulacin.
El concepto de sub-unidad temporal no es una caracterstica nica del VHDL,
tambin lo es de otros HDLs, donde se denomina step. Si una descripcin VHDL
slo emplea 8-delay, entonces el tiempo de simulacin no avanza nunca, aunque s
lo hace la simulacin. De este modo slo se puede representar la relacin de causa-
lidad (tiempo cualitativo) entre los eventos que se generan.
En el modelo temporal 8-delay se presenta como compuesto de una jerarqua,
de dos niveles de escalas de tiempo, la macro-escala mide tiempo real o cuantitativo
(fsico) 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 definicin (con el que se emplea en
simuladores RTL). Aunque la macro-escala s que es puramente Unit-delay, la com-
binacin de ambas escalas no es Unit-delay, La Figura 3-17 muestra el modelo tem-
poral de VHDL en dos dimensiones y en su representacin unidimensional equiva-
lente en pasos de simulacin.
3.4.1.5. Determinismo en VHDL

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

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

cesos.
Si no se usan variables compartidas, o sea, si la comunicacin entre procesos

VHDL slo se lleva a cabo por medio de seales VHDL, entonces se puede demos-
trar que el orden de ejecucin de los procesos VHDL no influye en el resultado,
independientemente de que stos se hayan ejecutado de forma secuencial o concu-
rrente, vase la Figura 3-18. Siendo, por tanto, la ejecucin del modelo de simula-
cin VHDL un caso de ejecucin determinista.
Se puede dar el caso de que el resultado que produce una funcin de resolucin
sea dependiente del orden en que se pasan los valores conducidos de las fuentes co-
mo parmetros de la funcin, resultando la ejecucin dependiente de la implemen-
tacin del algoritmo de clculo de valores conducidos de las seales, impidiendo la
portabilidad de los resultados de simulacin. Adems, el uso de ficheros desde los
subprogramas no est determinado por el lenguaje y podra ser otra causa de inde-
terminacin en el lenguaje. Debido a ello, las herramientas comerciales no suelen
permitir su uso.
3.4.7.6. Ejecucin secuencial o concurrente

Si no se usan variables compartidas, la ejecucin del programa correspondiente al
modelo de simulacin se puede ver como la correspondiente a la ejecucin de las
corutinas 3 (Coroutine) correspondientes al cdigo ejecutable de cada proceso
VHDL controladas por una corutina maestra" (Master Coroutine) correspondiente
al cdigo que implementa el algoritmo del kernel. A diferencia del flujo de control
de una subrutina o procedimiento (procedure), vase 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 ejecucin de las rutinas y las corutinas de un

programa HLL. (a) Subrutina en una jerarqua. (b) Corutinas en una heterarqua.
3 A diferencia de las rutinas, las corutinas no devuelven el control al lugar del cdigo donde se
hizo la llamada, sino a otro distinto establecido previamente.
4 Cuando existe una corutina maestra que controla la ejecucin de las dems, al modelo de ejecu-
cin' se le denomina basado en semicorutinas.
te a un cdigo jerarquizado, el flujo de control correspondiente a una ejecucin por

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

dencia la interaccin entre el programa ejecutable (Target Software, TS) y el entorno
de depuracin (Debugger). El simulador de VHDL ejecuta el TS de forma controla-
da, de acuerdo con las indicaciones dadas por el diseador para su experimentacin
o depuracin en trminos de software. El entorno de depuracin observa la ejecu-
cin del TS desde el punto de vista de su estructura esttica, tal como se especific
VHDL Simulator
Procedural & User Interface
Figura 3-20. Organizacin 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 cdigo fuente VHDL que compone las unidades de diseo VHDL correspondien-
tes a IDentidad de diseo que se est simulando, y de su actividad dinmica resul-
tante de la interaccin de los procesos VHDL al avanzar el tiempo de simulacin.
Tanto el anlisis esttico como el dinmico, del modelo de simulacin VHDL,
se realiza en trminos correspondientes al fuente VHDL descrito por el diseador.
Para poder realizar dichos anlisis, el entorno de depuracin 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 ejecucin del modelo de simulacin no se muestran en trminos ab-
solutos, sino relativos al avance del tiempo de simulacin. Para ello se suelen em-
plear las representaciones tpicas 5 de las formas de ondas o tambin denominadas
cronogramas, vase la Figura 3-21.
La ejecucin 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 ejecucin, vase la Figura 3-22. Cada vez que el TS se para, el entorno
de depuracin puede mostrar al diseador de VHDL el resultado de la ejecucin del
modelo de simulacin.
Sin embargo, en una ejecucin concurrente pueden ser varios los procesos que
se generen y cada uno de ellos puede estar, a su vez, en estado de ejecucin o para-
do, por lo que la ejecucin controlada de estos procesos resulta ms complicada.
Esta situacin se puede simplificar si se organiza la ejecucin de los procesos resul-
tantes en grupos, vase la Figura 3-23. En cualquier caso, el estado del TS se puede
monitorizar derivando el flujo de control de su ejecucin. Esta operacin se puede
5 Adems de corresponder los resultados de simulacin con el cdigo fuente, como en cualquier
depurador de software, tambin se utilizan representaciones de esquemas y cronogramas.
Sequental implementation
Kernel Process
Elaborated Procesa
0000
FIGURA 3-22. Estados del proceso generado por la ejecucin secuencial del mo-
delo de simulacin VHDL.
realizar por medio del uso de puntos de ruptura (breakpoints) temporales o condi-
cionados al valor de uno o de varios objetos, .
La simulacin o depuracin de un TS concurrente es mucho ms complicada
que la de uno secuencial, de hecho, la depuracin de programas concurrentes es un
problema de investigacin no resuelto todava. Sin embargo, una primera aproxima-
cin a la depuracin de un modelo concurrente consiste en considerar cada proceso
de forma aislada y aplicarles a cada uno de ellos las mismas tcnicas de ejecucin
controlada y/o monitorizacin que se aplicaran al proceso correspondiente a una
ejecucin secuencial.
Actualmente no hay simuladores VHDL comerciales que permitan la ejecucin
paralela de los correspondientes modelos de simulacin VHDL y mucho menos su
Parallel implementation
Kernel Process
(~-)
Elaboreted Process
0000
FIGURA 3-23. Estados de los procesos generados por la ejecucin concurrente del
modelo de simulacin VHDL.
posterior depuracin. 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 simulacin VHDL como con el control que el
simulador VHDL ejerce sobre dicho programa. Esta comunicacin 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-simulacin VHDL pa-
ra sistemas hardware-software o electrnico-mecnicos [39-42].
3.5. MODELADO EN VHDL PARA SIMULACIN
Una descripcin en VHDL se puede utilizar para simular el comportamiento, sinte-

tizar (incluyendo implcitamente la manufactura del dispositivo fsico correspon-
diente) o probar (test) el hardware correspondiente a una determinada entidad de
diseo. Sin embargo, el modelado en VHDL y/o su procesado para cada uno de es-
tos propsitos, 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. Generacin y prueba de modelos descritos en VHDL

1 '12 VHDL. Lenguaje estndar de Diseo ELectrnico
Con una simulacin por ordenador, lo que se pretende no es otra cosa que exa-
minar el resultado de poner a prueba el modelo de simulacin correspondiente al
sistema que se est estudiando. Para poder llevar a cabo este propsito es necesario
contar con la descripcin VHDL de la entidad de diseo correspondiente a dicho
sistema (Unir Under Test, UUT) y con la descripcin VHDL de la entidad de diseo
correspondiente al sistema que genera las pruebas iStimuli Generator, SG) que se
desean ejercitar en la simulacin. Sin embargo, la disponibilidad de ambas entida-
des de diseo no es suficiente para poder llevar a cabo la tarea de simulacin. Ade-
ms de contar con ambas entidades de diseo, es necesario contar con la descrip-
cin en VHDL de una tercera entidad de diseo, 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 diseo 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 diseo VHDL correspondientes tanto a la UUT como al SG. Sin
embargo, su presencia para poder realizar una simulacin VHDL es necesaria, ya
que para ello, por definicin, tan slo se puede seleccionar una nica entidad de di-
seo VHDL.
La red de procesos VHDL que componen el modelo abstracto de simulacin
contiene tanto los procesos resultantes de la elaboracin de la jerarqua de diseo
con la que se ha descrito la UUT como los que resultan de la elaboracin de la enti-
dad de diseo SG, sin ningn tipo de distincin o de separacin. As es como se
consigue que la simulacin del modelo abstracto de la entidad de diseo VHDL co-
rrespondiente al TE sea equivalente a la realizacin de las pruebas sobre el modelo
fsico correspondiente a la UUT, que se llevaran a cabo en el banco o entorno fsi-
co del equipo de pruebas (TE), vase la Figura 3-24. A su vez, dicho TB fsico pue-
de ser muy variado, correspondiendo tanto a un entorno real de funcionamiento, por
ejemplo, la tarjeta (PCB) donde se podra probar un circuito integrado de aplicacin
especfica (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 utilizara para probar si
un ASIC se ha fabricado adecuadamente.
La entidad de diseo VHDL de la UUT es tan slo un componente de la enti-
dad de diseo VHDL correspondiente al TB que se desea simular. Sin embargo,
para poder sintetizar el modelo fsico correspondiente a la UUT slo es necesario
disponer de su correspondiente entidad de diseo VHDL y, por supuesto, de la he-
rramienta de sntesis 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-
cin del modelo abstracto correspondiente a una determinada UUT es equivalente a
la combinacin de los procesos de sntesis y prueba del modelo fsico que se corres-
pondera con dicha UUT, vase la Figura 3-24.
Si el entorno de pruebas automatizado por ordenador tambin acepta como len-
guaje de descripcin 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 diseo generadora de las pruebas (SG) necesarias para poder llevar a ca-
bo la simulacin y las pruebas sobre el prototipo fsico obtenido cornoresultado del
3, Procesado y mecanismos de simutecin del lenguaje VHDL 173
proceso de sntesis (incluyendo implcitamente la manufactura o fabricacin del

dispositivo fsico correspondiente), En el caso de la simulacin, la entidad de di-
seo generadora de las pruebas (SO) es otro componente de la entidad de diseo
correspondiente al TR Sin embargo, en el caso de las pruebas fsicas de la UUT, da-
do que el entorno o banco de pruebas (Test Bench] tiene entidad fsica, la descripcin
VHDL de la entidad de diseo correspondiente a dicho TB es totalmente innecesaria.
Finalmente, otra diferencia entre el modelado en VHDL para realizar una si-
mulacin o para llevar a cabo un proceso de sntesis de hardware consiste en que el
modelo de simulacin abstracto se genera de una sola vez, aunque pueda llevarse a
cabo en varias fases, mientras que el proceso de sntesis, adems de poderse llevar a
cabo tambin en varias fases, puede ser un proceso iterativo, vase la doble flecha
de la Figura 3-24, En este caso la descripcin VHDL resultante de la primera sntesis
correspondera a una descripcin VHDL de menor nivel abstraccin de la misma
UTT, por ejemplo, el resultado de una-sntesis comportamental (Behavioral Synthe-
sis) sera la entrada de una sntesis a nivel de transferencia de registros (Register
Transfer Level), cuya salida sera a su vez entrada de una sntesis lgica (Logic Synt-
hesis) a partir de la cual las herramientas de manufactura permitiran fabricar el le.
Quiz no es necesario recalcar que el proceso de simulacin se puede realizar
para cada una de las descripciones VHDL de la UUT resultantes en cada etapa de
sntesis para verificar que dichas descripciones son correctas de acuerdo con el con-
junto de pruebas que se ha establecido previamente, vase la doble flecha de la Fi-
gura 3-24. Aunque quiz s vale la pena destacar que la descripcin VHDL corres-
pondiente a la entidad de diseo que genera las pruebas (SO) puede necesitar un
cierto refinamiento para ajustarse al nuevo nivel de abstraccin en el que se desea
realizar la simulacin.
3.5.1. Simulacin lgica, temporal y de fallos
Por razones histricas y debido a que durante mucho tiempo el mayor nivel de abs-
traccin al que los sistemas electrnicos se podan modelar, para poder llevar a cabo
su simulacin, era el nivel de puertas lgicas (Gate Level), a las simulaciones de es-
te tipo de sistemas se les denomin simulaciones lgicas. Trmino que se ha mante-
nido hoy en da, aun cuando las descripciones HDL se pueden realizar a distintos
niveles de abstraccin, e incluso se pueden realizar modelos multinivel, o sea mo-
delos en las que algunas entidades de diseo HDL estn descritas a distinto nivel de
abstraccin (Behavioral, Register Transfer; Gate Level).
El adjetivo de simulacin lgica se debe al nfasis que se haca y todava se ha-
ce al diferenciar el propsito de la mera simulacin del comportamiento lgico 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 todava se realizan a nivel de puertas
lgicas, por medio de modelos que describen la lista de puertas que componen la
red {netlist) que describe al sistema electrnico. Para ello slo se utiliza un subcon-
junto del HDL, en el caso de VHDL dicho subconjunto es el standard VITAL.
Hoy en da las simulaciones HDL que se realizan para formalizar el contrato de

fabricacin de un ASIC (Sign-off Simulation) entre el diseador y el fabricante de
silicio (Silicon. Foundries) se hacen a nivel de puertas lgicas, aunque se intenta que
cada vez el nivel de abstraccin sea mayor. La simulacin de Sign-off suele corres-
ponder con una simulacin lgica cuyo modelo se ha validado por medio de una si-
mulacin temporal y cuyas pruebas se han validado por medio de una simulacin
de fallos.
La simulacin temporal se realiza considerando el modelado en un HDL de las
caractersticas temporales de las puertas lgicas que componen un IC no slo con
valores tpicos, sino que tambin se tienen en cuenta los valores mximos y mni-
mos. Las simulaciones temporales comprueban si la funcionalidad del sistema elec-
trnico sigue siendo vlida, 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 precisin con la que se reali-
zan las simulaciones temporales a nivel de puertas lgicas, stas se retroanotan
(backannotation) con informacin proveniente de la de la etapa de layout. Por ser
esta etapa posterior a la de la generacin de la netlist de puertas, es por lo se dice
que la informacin que mejora la caracterizacin temporal de las descripciones
HDL de las puertas se retroanota o que se anota a posteriori. Esta simulacin com-
plementada a la simulacin puramente lgica 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
simulacin temporal se puede realizar por medio de un simulador "lgico" con mo-
delos especficos o por medio de un instrumento distinto.. denominado analizador
temporal (Timing Analyzer).
Debido a que una vez que se han fabricado los ICs, stos slo se pueden probar
(test) desde el exterior, la posibilidad de acceder a cualquier punto del modelo de si-
mulacin para su observacin y monitorizacin se ha perdido . Por e.~te motivo, la
calidad de las pruebas, que en simulacin era una de las piezas claves para confiar
en esta tcnica experimental, es todava ms crtica, si cabe, cuando se desean utili-
zar para llevar a cabo la comprobacin 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 diseo se
aade cierta funcionalidad (lgica) que as lo permita. Este tipo de tcnica se deno-
mina diseo para "testabilidad" tDesign For Testability, DFT) y se suele solapar
con el proceso de sntesis lgica de la descripcin HDL.
Para evaluar, de alguna forma, la calidad de las pruebas de manufactura se sue-
le realizar otro tipo de simulacin complementaria a la lgica, denominada simu-
lacin de fallos (Fault Simulation) [44]. Al igual que ocurra con la simulacin
temporal, la simulacin de fallos tambin se realiza actualmente a nivel de puertas
lgicas. Este tipo de simulacin 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 simulacin lgica pura y la
correspondiente simulacin 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 fabricacin. Actualmente, el modelo de fallos que se
3. Procesado V mecanismos de simulacin del lenguaje VHDL 175
.utiliza para este propsito es el stuck-at (estancamiento), en el que se considera que

los fallos de fabricacin se pueden corresponder con el estancamiento a loa O del
valor que adquieren las puertas lgicas. 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 querra decir que si el ASIC pasase todas
estas pruebas sera 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 lgicas con aquellas pruebas especficas que
comprueban, valga la redundancia, la testabilidad del circuito. Dichas pruebas se
suelen generar automticamente por medio de una herramienta denominada Auto-
matic Test Pattern Generator (ATPG) que suele estar integrada con la herramienta
de sntesis. Por ello, en la Figura 3-24 se ha incluido una lnea de puntos que intro-
duce las pruebas especficas de manufactura que se van a utilizar posteriormente
tanto en la entrega del diseo, por ejemplo, para Sign-off, como en la demostracin
de que el ASIC se ha fabricado adecuadamente probndolo en el ATE.
3.6. EJERCICIOS
1. Describe el significado de realizar una simulacin en un ordenador.

2. Describe el mecanismo de simulacin dirigido por eventos discretos.
3. Cul es la diferencia entre el modelo temporal Zero-delay y el Unit-delay't

Deduce a partir de ambos el modelo correspondiente a la simulacin VHDL.
4. Qu medios se emplean para especificar la sintaxis y la semntica de los len-

guajes de programacin?
5. Qu es un formato intermedio de compilacin y qu relacin tiene con una es-

tructura de datos de tipo rbol sintctico abstracto (AST)?
6. En qu se parece y en qu se diferencia un HDL y un HLL?
7. Cul es la diferencia entre una unidad de diseo y una entidad de diseo

VHDL?
8. Cules son las diferencias entre los niveles de abstraccin, los estilos de des-
cripcin y las jerarquas de un diseo descrito en VHDL?
9. Describe los dos tipos de jerarquas que se pueden encontrar en una descripcin
VHDL.
10. Cul es la etapa comn, del procesado de una descripcin VHDL, para todos
los propsitos para los que sta se quiera utilizar (p. ej., simulacin, sntesis,
etc.)? y por qu es as?
176 VHDL. Lenguaje estndar de Diseo EJreGtrnico
11. Si se tuviesen que integrar una descripcin en VHDL con otra realizada en otro
HDL como. por ejemplo. Verilog HDL, en qu etapa de su procesado se debe-
ra hacer? y por qu sera as?
12. Cul es la relacin existente entre el determinismo de una descripcin VHDL,

su portabilidad y la forma en que se realiza la implementacin del programa
correspondiente a su modelo de simulacin?
13. Qu biblioteca y qu paquetes son visibles para toda unidad de diseo VHDL?
14. Realiza el proceso de elaboracin completo de una entidad de diseo similar a

la del esquema que se ha empleado para ejemplificar el proceso de elaboracin
en este captulo. Realiza la inicializacin y la simulacin de varios pasos simu-
lacin haciendo t mismo de intrprete del modelo elaborado, o sea, sin necesi-
dad de generar un cdigo 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 ,cUldes sOdny .CUl 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 descripcin VHDL de un modelo de simulacin 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. Cul es la relacin existente entre el proceso de generacin de mi modelo de

simulacin y el de su sntesis?
19. En qu se parece y se diferencia la simulacin de una descripcin VHDL y el

Test del correspondiente hardware?
20. Cul es la diferencia entre el Test de manufactura y el funcional? y cul es su

relacin con la simulacin de SignOff necesaria para poder fabricar un ASIC?
3.7. BIBLIOGRAFA
[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 Descrpton 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. GARCA,l. IzAGUIRRE, O. PEALBA:"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:"Renvented 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.
Captulo 4
,
SINTESIS
Eugenio VilIar y Pablo Snchez

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

Consigues lo que negocias.
J. Karrass
El objetivo principal de este captulo es introducir la aplicacin de

VHDLen sntesis como tecnologa fundamental en las metodologas de
diseo descendentes utilizadas industrialmente en la actualidad
[CP96J.La sntesis desde VHDL constituye hoy en da una de las princi-
pales aplicaciones del lenguaje con una gran demanda de uso. Las he-
rramientas de sntesis basadas en el lenguaje permiten incrementar
significativamente la productividad del diseo. Este hecho es particu-
larmente importante en el contexto actual caracterizado por un merca-
do extraordinariamente competitivo en el que resulta imprescindible
acortar simultneamente el tiempo de acceso al mercado y los costes
de diseo. De hecho, estas herramientas resultan imprescindibles a la
hora de asegurar el mantenimiento de la competitividad en cualquier
empresa con actividad en diseo electrnico [MLD92J.
El objetivo principal de este captulo es el de describir la utilizacin
de VHDL en sntesis RT-Igica, tal y como lo hacen las herramientas co-
merciales de sntesis disponibles en la actualidad. En primer lugar, se
hace un anlisis general del uso de un lenguaje como VHDL en aplica-
ciones de sntesis. A continuacin se hace una breve introduccin a los
modelos de sistema digital utilizados por las herramientas de sntesis y
a los pasos de sntesis que aplican. Posteriormente, se detalla la des-
cripcin en VHDL de los componentes fundamentales de un sistema
digital. Este conocimiento es imprescindible a la hora de asegurar que
la implementacin propuesta por la herramienta de sntesis es eficien-
te y coincide funcionalmente con la que se desea. Finalmente, se con-
cretan un conjunto de recomendaciones que facilitan al diseador el
aprovechamiento al mximo de las prestaciones de la herramienta de
sntesis.
179
4. 1. INTRODUCCiN
Tal y como se ha comentado en el Captulo 1, el diseo electrnico asistido por

computador (CAD) ha sufrido un fuerte desarrollo durante las dos ltimas dcadas
y el inters en el campo es previsible que crezca en los prximos aos. Durante este
tiempo han aparecido en el mercado herramientas comerciales que sustentan meto-
dologas de diseo maduras. Estas metodologas resultan imprescindibles en el di-
seo de los circuitos de la complejidad y prestaciones soportadas por la tecnologa
microelectrnica actual y se utilizan en un amplio rango de aplicaciones como siste-
mas de cmputo de propsito general, sistemas embebidos, sistemas de telecomuni-
cacin, sistemas de control, electrnica aeroespacial, del automvil y electrnica de
consumo. Las herramientas CAD representan el medio para disear 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 diseo completo: edicin, anlisis, sntesis y
optimizacin. Los editores permiten la captura del comportamiento o la estructura
del diseo. Existen editores especializados en distintas represntaciones del diseo
como FSMDs, esquemticos y layout. Las herramientas de anlisis permiten extraer
propiedades del diseo. El simulador constituye la herramienta de anlisis ms im-
portante en la actualidad. La simulacin del circuito en las distintas etapas del pro-
ceso de diseo es el medio ms frecuente para comprobar su correccin. Otras he-
rramientas de anlisis ampliamente utilizadas son el generador de patrones de test y
el analizador temporal. Las herramientas de sntesis realizan automticamente algu-
no de los pasos del proceso de diseo generando una implementacin detallada de
una descripcin ms abstracta. En ntima relacin con la herramienta de sntesis (de
la que en muchas ocasiones no se distingue), la herramienta de optimizacin permi-
te mejorar la calidad del diseo a un determinado nivel de abstraccin en funcin de
los parmetros definidos por el usuario (coste, velocidad, consumo, etc.).
Las herramientas CAD hacen uso de notaciones de diseo, ya sean explcitas o
transparentes para el usuario. Las notaciones explcitas son aquellas relevantes para
el diseador. Entre ellas, cabe citar las tablas de verdad y de estado (para minimiza-
cin lgica), la lista de puertas (para simulacin lgica) o la lista de componentes
(para simulacin analgica, 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 libreras de componentes en alguna tecnologa.
Los lenguajes de descripcin de hardware (HDLs) representan un medio de descrip-
cin explcito del circuito a disear. La novedad aportada por los HDLs reside en la
utilizacin de conceptos de ingeniera del software a la descripcin y modelado de
hardware. Sintcticamente, los lenguajes de descripcin de hardware resultan en ge-
neral muy similares a lenguajes de programacin. De hecho, en muchos casos, el
lenguaje de descripcin de hardware se deriva de un lenguaje de programacin. 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
descripcin de hardware y los lenguajes de programacin tiene consecuencias en su
4. Sntesis 181
uso, particularmente en sntesis. Como comentaremos posteriormente, el diseador

no debe de olvidar que, aunque la sintaxis sea similar a la de un lenguaje de progra-
macin, el objetivo del cdigo es la descripcin del hardware que se quiere obtener.
Si este hecho no es tenido en cuenta, los resultados obtenidos de la herramienta de
sntesis pueden no ser satisfactorios. De heclio, la herramienta de sntesis no evita el
diseo lgico. Las decisiones de alto nivel respecto a la arquitectura del circuito, su
funcionalidad, componentes e interconexin, comunicacin con el exterior, frecuen-
cia de funcionamiento, etc., siguen siendo responsabilidad del diseador y la cali-
dad del diseo va a seguir dependiendo fundamentalmente de su experiencia [N93]
[OW94) [S96].
4.1. 1. Proceso de sntesis
Los niveles de abstraccin ms aceptados en diseo hardware son los que se mos-
traron en la Figura 1-7. Aparecen, por tanto, los tres pasos de sntesis que se
muestran en la Figura 4-1. Cada uno de estos pasos est soportado por herramien-
Nivel funcional
Nivel RT
--- Nivel lgico
Retroanotacin
Implementacin
FIGURA 4-1. Proceso de sntesis.

tas de sntesis especficas, independientemente de que en algn caso un entorno de-

terminado soporte conjuntamente varios de ellos. Las dos herramientas de sntesis
ms importantes en la actualidad son la herramienta de sntesis RT-lgica y la herra-
mienta de posicionamiento e interconexin. Aunque tradicionalmente ambas tareas
se han venido realizando. por separado, en la actualidad existe una tendencia a su
conexin particularmente en diseos en los que el aprovechamiento al mximo de
las prestaciones de la tecnologa resulta esencial. Slo en los ltimos aos han co-
menzado a aparecer en el mercado las primeras herramientas de sntesis de compor-
tamiento. Se trata todava de una tecnologa con muy escasa penetracin industrial
y comercialmente inmadura. Esta es la razn por la que queda fuera de los objetivos
del presente libro.
Aunque desde el punto de vista del diseo la descripcin inicial es la ms im-
portante, 'en cada nivel de abstraccin va a ser posible y, en la mayora de las oca-
siones necesario, describir el circuito mediante el uso de un lenguaje de descrip-
cin. Una de las ventajas que aporta VHDL frente a otros lenguajes reside en su
capacidad de descripcin multinivel. De hecho, VHDL puede utilizarse en los tres
niveles de la Figura 4-1, desde el nivel funcional a la implementacin final.
Aunque la sintaxis del lenguaje es comn a los tres niveles, la interpretacin
del cdigo, o semntica, va a ser diferente en cada nivel. Tal y como se propone en
[E95], una descripcin VHDL puede caracterizarse en funcin de tres aspectos: la
temporizacin, los tipos de datos y el estilo descriptivo:
La temporizacin alude al nivel de detalle disponible sobre el funcionamien-

to temporal del circuito. La temporizacin es la caracterstica principal que
permite identificar un determinado nivel de abstraccin. A lo largo del pro-
ceso de diseo se pueden distinguir tres niveles de temporizacin. En el nivel
inferior o lgico se conocen los retrasos introducidos por los distintos com-
ponentes del circuito. El estilo descriptivo estndar es el definido en VITAL
[IEEE95]. A nivel de circuito lgico, 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 estimacin del retraso debido a las interconexiones.
Despus del posicionamiento y la interconexin, a la misma descripcin es
posible retroanotarle los retrasos reales debidos a las interconexiones, lo que
completa el nivel de detalle propio de la implementacin 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
estn decididas. En diseo sncrono, es la seal de reloj la que provoca el
cambio de estado, con lo que todas las seales del circuito cambian con ella
en sucesivos ciclos-o. La sntesis RT-lgica de circuitos sncronos constituye
la tecnologa de sntesis ms importante y utilizada en la actualidad. Por ello,
la descripcin VHDL a este nivel va a representar el objetivo principal de es-
te captulo. En diseo asncrono [LS93], los cambios de estado en cada m-
dulo lo provocan las seales de requerimiento y reconocimiento. Se trata de
una tecnologa de sntesis muy poco madura no soportada en la actualidad
por ninguna herramienta comercial. A nivel funcional, la planificacin de las
4. Sntesis 183
distintas acciones todava no se ha decidido y slo las relaciones causales de-

terminadas por las dependencias entre datos son relevantes [MLD92][M94].
Ejemplos de este estilo de modelado se muestran en el Captulo 5.
El segundo aspecto por el que puede caracterizarse una descripcin VHDL
lo representa los tipos de datos manejados. Los ms simples son los tipos a
nivel de "bit", ya sea en lgica binaria (bit y boolean) o multivaluada
(std_ulogic). El siguiente nivel estara representado por tipos de datos
compuestos por agrupacin de "bits" (bit_vector, std_logic_vector) y
su correspondiente representacin 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, fsicos, enumerativos, registro, acceso, etc.).
El tercer aspecto lo representa el estilo descriptivo, algortmico, flujo de da-
tos y estructural. En funcin del estilo utilizado, una descripcin VHDL pue-
de situarse en alguno de los puntos del cubo de diseo representado en la Fi-
gura 4-2.
RT
Bits
Compuestos
Lg ico """"-""'-"''''''-'''''''--''--_~~'--''''''''''''''!!'::.:.c'''_--",=:___
Estructural Flujo de datos Algortmico
FIGURA 4-2. Cubo de diseo.

Cada movimiento en el cubo se corresponde con un paso de diseo. As, en el

paso "1" una descripcin funcional sobre datos compuestos se planifica en ciclos de
reloj. En el paso "2", la descripcin RT algortmica se descompone en un conjunto
equivalente de asignaciones de seal concurrentes (flujo de datos). En el paso "3",
los tipos compuestos en la descripcin RT resultante se codifican en binario y se
descomponen en el conjunto de "bits" equivalente. En el paso "4", se procede a la
minimizacin lgica e implementacin de cada una de las funciones lgicas obteni-
das en el paso anterior sobre una tecnologa deternnada. En el ltimo paso ("5"),
las asignaciones a seal 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 sntesis con el consiguiente cambio
en el nivel de abstraccin.
Las etapas de sntesis para las que se ha propuesto la utilizacin de VHDL cu-
bren la sntesis de comportanento, la sntesis RT y la sntesis lgica. La sntesis de
comportanento origina la arquitectura a nivel transferencias entre registros desde
una descripcin algortmica del funcionamiento del circuito. La sntesis RT genera
el conjunto de ecuaciones lgicas y deternna los elementos de memoria de la ar-
quitectura de transferencias entre registros. La sntesis lgica propone una imple-
mentacin ptima de las ecuaciones lgicas en puertas y, posteriormente, mapea di-
chas puertas y los elementos de memoria sobre los elementos de biblioteca en la
tecnologa escogida.
Ejemplo 4.1. Se desea disear un mdulo para la multiplicacin de nmeros bi-

narios sin signo. El mdulo recibe el multiplicando por un "bus" de 32 "bits" en el
ciclo de reloj indicado por la seal "start =
1". En el siguiente ciclo de reloj recibe
el multiplicador. El algoritmo de multiplicacin es el de acumulacin del multipli-
cando en funcin de los "bits" del multiplicador y su posterior desplazamiento se-
gn 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 multiplicacin binaria sin signo.

4. Sntesis 185
Finalizada la operacin de multiplicacin, el mdulo pondr la seal ends a

"1" y proporcionar por la salida los 32 "bits" ms 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 multiplicacin. A partir del conoci-
miento de las entradas y salidas del mdulo, es posible la declaracin 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. Declaracin de la entidad multiplicador'.
El punto de partida del proceso de diseo desde el nivel funcional es la descrip-

cin VHDL del algoritmo hardware a implementar. As, la descripcin funcional
del algoritmo de multiplicacin 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 sntesis de comportamiento correspondiente. En cual-
quier caso, y tal y como se har en el ejemplo de modelado del Captulo 5, la simu-
lacin del cdigo funcional del Listado 4-2 permite comprobar que el algoritmo uti-
lizado es correcto en la obtencin de los resultados requeridos. En esta descripcin,
los recursos hardware finales y la asignacin de operaciones a ciclos de reloj no
est todava decidida. La nica informacin temporal relevante es la dependencia
entre datos establecida en el cdigo. As, los ciclos de obtencin de datos (multipli-
cando y multiplicador) y de salida del resultado estn determinados en la propia es-
pecificacin. Sin embargo, el nmero de ciclos para realizar la acumulacin del
multiplicando no lo est y constituye la primera decisin importante de diseo. De-
pendiendo del retraso, en nmero de ciclos de reloj, los requerimientos hardware
van a variar. Los requerimientos hardware van a determinar, por un lado, el coste en
puertas del diseo resultante y, por otro, el consumo.
Si se hiciera una implementacin literal del cdigo VHDL realizando las 32
adiciones en un nico ciclo de reloj, se requeriran 31 sumadores y 32*32 puertas
"and" en la implementacin directa (con localizacin de operaciones de ciclo fijo)
I En esta descripcin es necesario utilizar un puerto de entrada y otro de salida para el "bus" a fin
de evitar problemas de simulacin con seales 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: urislgnd (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 multiplicacin de nmeros naturales.
del esquema de la Figura 4-3 que se muestra en la Figura 4-4. El nmero de suma-
dores es de 31, ya que la primera suma con el acumulador a cero no precisa de un
sumador.
En la mayora de las ocasiones, esta implementacin va a tener un coste excesi-
vo en trminos de puertas y consumo. Por otro lado, aunque resulta la ms rpida
en trminos de ciclos de reloj, el camino crtico es elevado, lo que puede imponer
restricciones intolerables a la frecuencia de la seal de reloj. Este ltimo aspecto
podra solucionarse mediante la realizacin de la multiplicacin combinacional co-
mo operacin multiciclo [MLD92].
Al objeto de minimizar los recursos hardware requeridos, una alternativa es la
utilizacin de un nico sumador y la realizacin de las acumulaciones en ciclos de
reloj sucesivos. La arquitectura RT resultante es la de la Figura 4-5. Se trata de una
tpica arquitectura a nivel de transferencia entre registros en la que todas las accio-
nes en cada ciclo de reloj estn definidas. Consta de dos unidades. La Unidad de
Datos (UD) incluye los recursos hardware en trminos de registros, Unidades Ope-
racionales (UOs) e interconexiones, ya sean "buses" o multiplexores. La Unidad de
4. Sntesis 187
FIGURA 4-4. lgica combinacional para multiplicacin en un ciclo.
start
ends
FIGURA 4-5. Arquitectura RT para multiplicacin 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 mqui-
na de estados finitos (FSM).
A partir de esta arquitectura, la descripcin VHDL para sntesis RT es el Lista-
do 4-3.
En esta arquitectura se ha decidido la ejecucin secuencial de las 32 sumas en
32 ciclos de reloj mediante la implementacin del lazo en la ejecucin cclica 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 finalizacin en los que se proporciona el resultado por el
"bus" y se retorna al estado de espera.
La obtencin automtica de esta descripcin desde el algoritmo hardware del
Listado 4-2 constituye el objetivo de la sntesis de comportamiento. En el cubo de
diseo de la Figura 4-2 se corresponde con el paso nmero 1. Dependiendo de los
recursos hardware puestos en juego, cabra un conjunto amplio de implementacio-
nes intermedias entre la implementacin combinacional directa de la Figura 4-4 y la
implementacin secuencial propuesta. El Listado 4-3 constituye el tipo de descrip-
cin de entrada a las herramientas de sntesis RT-lgica comerciales ampliamente
utilizadas en la actualidad. Este es el tipo de descripcin cuyo estudio va a consti-
tuir el objetivo principal de este captulo.
La sntesis RT-lgica conlleva una serie de procesos de minimizacin y optimi-
zacin los ms importantes de los cuales sern comentados posteriormente. As, los
tipos abstractos y numricos se codifican en binario. Los tipos compuestos se des-
componen en los "bits" correspondientes. De la descripcin de comportamiento se
extraen las asignaciones concurrentes de seal identificando las asignaciones sn-
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 diseo,
es el cdigo VHDL del Listado 4-4.
A partir de este tipo de informacin puede comenzar la minimizacin lgica.
En este paso es imprescindible tener en cuenta los elementos lgicos disponibles en
la tecnologa utilizada. El resultado sera la descripcin final que se muestra en el
cdigo del Listado 4-5. Se trata de una descripcin estructural en la que los distin-
tos componentes de la biblioteca VITAL se referencian e interconectan entre s.
En esta descripcin los componentes incluyen los retrasos concretos de los ele-
mentos de biblioteca correspondientes. En el cubo de diseo los pasos recorridos
hasta este modelo se corresponden con los nmeros 3, 4 y 5. Por retroanotacin de
las caractersticas de la topografa, el modelo podra 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 mayora de situaciones de diseo prcticas son la descripcin
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 diseo que no van a re-
2 Cdigo del Listado 4-2 en el caso de utilizar una herramienta de sntesis de comportamiento o
del Listado 4-3 en caso de utilizar una herramienta de sntesis RT-lgica.
4. Sntesis 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. Descripcin RT para multiplicacin 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. Descripcin en flujo de datos del multiplicador secuencial.
querir, en general, de su descripcin en VHDL y que slo van a afectar a los forma-
tos internos de representacin del diseo 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 diseador en la descripcin para sntesis de
parte o de la totalidad del circuito.
4.1.2. Modelado para simulacin frente a modelado

para sntesis
VHDL fue desarrollado como un lenguaje para el modelado y simulacin lgica di-
rigida por eventos discretos de sistemas digitales. Se trata de un lenguaje con una
4. Sntesis 191
architecture estructura of multiplicador is

----- Component NA2 -----
camponent NA2
generic(
TimingChecksOn: J3t)0~ := ~f~ltT.iI!l,i.n9ChechsDn;
XGenerationON: !3oQlea! ':= PfaltXGeneraonOn;
IlstancePath: STRiNG := "~';
tpd...]\,_Q: DelayTypeOl .- fO.340 ns. 0.040 ns);
tpUl_Q: DelayTypeOl . - (O.34')l3, 'l).O(O fis)'
tipd_}l.: DlyTypeOl . - "(O ,OOO('ruC'O; OOris);
_._"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 := Defaltimenefati~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,stte(), 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. Implementacin del multiplicador secuencial.

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

algortmico del comportamiento de un sistema digital conocido y el desarrollo de
modelos de simulacin exactos.
En sntesis, la situacin es diferente, ya que de una especificacin de entrada a
un determinado nivel de abstraccin se obtiene una implementacin ms detallada,
menos abstracta. Aunque el lenguaje utilizado sea el mismo, el desarrollo de una
especificacin de un circuito o sistema a un determinado nivel de abstraccin con el
objetivo de ser sintetizada resulta conceptualmente diferente al desarrollo de un
modelo para simulacin de un sistema ya implementado. Las particularidades deri-
vadas del uso de VHDL en aplicaciones de sntesis se describirn a lo largo de este
captulo. Estas particularidades se refieren tanto a restricciones sintcticas sobre el
cdigo como a la interpretacin semntica del mismo. En el Captulo 3 se ha hecho
un estudio ms detallado de las diferencias y similitudes entre el procesado de un
HDL para simulacin y sntesis.
La utilizacin de una herramienta de sntesis asegura la concordancia funcional
entre la implementacin obtenida y la descripcin de entrada a partir de la interpre-
tacin hardware que la herramienta hace de este cdigo. Aunque desde este punto
de vista el diseo resultara correcto por construccin, la verificacin del proceso de
sntesis por comparacin entre los resultados de simulacin antes y despus de sn-
tesis sigue siendo imprescindible por los motivos que se comentan a continuacin.
En consecuencia, tanto la descripcin de entrada a la sntesis como la resultante de
la misma deben de ser verificadas por simulacin. Simulacin es, pues, una tarea
horizontal a un determinado nivel de abstraccin. Sntesis, por el contrario, es una
tarea vertical entre niveles de abstraccin. Esta diferencia se ha mostrado en la Fi-
gura 1-6 del Captulo 1 y en la Figura 3-23 del Captulo 3.
4. 1.3. Objetivos
Las herramientas comerciales actuales cubren las etapas de sntesis RT y lgica.

Desde el momento en que ambas tareas se realizan conjuntamente, para el disea-
dor aparentan un nico proceso de sntesis. Sin embargo, en cada una de estas eta-
pas se aplican algoritmos de sntesis distintos cuyo conocimiento es necesario al ob-
jeto de lograr los mejores resultados. El objetivo principal de este captulo es el de
describir la utilizacin de VHDL en sntesis RT-lgica tal y como lo hacen las he-
rramientas comerciales de sntesis disponibles en la actualidad.
4.2. APLICACiN DE VHDL EN SNTESIS
Desde el momento en que la aplicacin inicial de VHDL fue el modelado de siste-

mas digitales, su utilizacin en sntesis no es inmediata. La principal razn de este
hecho reside en la carencia de una semntica hardware en la definicin del lengua-
je. Este hecho contrasta con la utilizacin de VHDL para simulacin. En este caso,
la semntica del lenguaje est perfectamente definida y los resultados van a ser in-
dependientes del simulador que se emplee.
4. Sntesis 193
La utilizacin de VHDL en sntesis presenta dos caractersticas principales. Por

un lado, las restricciones sintcticas y semnticas que se imponen al lenguaje. Por
otro, las discrepancias que se van a encontrar entre los resultados de simulacin an-
tes y despus de sntesis. Ambas caractersticas van a ser comentadas a continua-
cin.
4.2.1. Restricciones sintcticas y semnticas
Est generalmente aceptado que VHDL contiene muchas construcciones orientadas

a simulacin que resultan difciles de sintetizar como, por ejemplo, tipos acceso y
fichero, muchos de los atributos predefinidos, etc. De hecho, todas las herramientas
de sntesis actualmente en el mercado imponen restricciones sintcticas al cdigo
VHDL utilizado en la descripcin de una arquitectura a nivel RT. Sin embargo, la
mayor o menor orientacin a simulacin de una determinada construccin, en reali-
dad, su mayor o menor sentido hardware, no constituye, en s misma, la razn para
que dicha construccin sea o no sintetizable. En principio, cualquier construccin
VHDL es sintetizable desde el momento en el que es simulable. Al fin y al cabo, un
simulador en tiempo real (un emulador) sera una implementacin hardware del c-
digo. En consecuencia, el problema no es tanto la posibilidad de sintetizar una de-
terminada construccin sino las prestaciones (coste, velocidad, consumo, etc.) de la
implementacin correspondiente. Las restricciones sintcticas y semnticas impues-
tas al cdigo por las herramientas de sntesis provienen de la necesidad de asegurar
una eficacia mnima en el proceso de sntesis.
La eficiencia del proceso de sntesis est relacionada con la identificacin del
hardware asociado a un determinado comportamiento, lo que requiere aadir se-
mntica hardware a la descripcin. Esta es la razn principal de las restricciones
sintcticas impuestas a la descripcin de entrada. Las herramientas de sntesis 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 cdigo VHDL de la
Figura 4-6.
A pesar de su simplicidad, no existe ninguna herramienta de sntesis en la
actualidad que acepte este cdigo. La dificultad principal reside en la identifica-
cin del hardware capaz de realizar la funcionalidad correspondiente, una puerta
ando
Al objeto de asegurar una eficiencia suficiente en el proceso de sntesis, las he-
rramientas imponen restricciones sintcticas en la descripcin VHDL de entrada. El
problema que se plantea es la carencia de un subconjunto sintctico estndar acep-
tado por todas las herramientas de tal forma que cada una impone sus propias res-
tricciones al usuario. En este captulo 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 comn para sntesis
es la dificultad de reutilizacin de una descripcin 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 implementacin de una funcin ando
4.2.2. Discrepancias entre resultados

de simulacin
La segunda caracterstica, propia de la utilizacin de un lenguaje como VHDL en

sntesis, se refiere a las discrepancias entre los resultados de simulacin-antes-de-
sntesis, en la que el comportamiento deseado en la descripcin de entrada se vali-
da, y los de la simulacin-despus-de-sntesis, 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 sntesis se deciden los elementos lgicos que van a componer la ar-
quitectura RT inicial. Estos elementos lgicos (puertas, "latches", biestables, etc.)
llevan asociados retrasos que no se conocan antes de la sntesis. La simulacin de
la arquitectura RT es una simulacin en ciclos de reloj. La simulacin lgica es una
simulacin basada en los retrasos concretos de los elementos lgicos en la tecno-
loga de destino. A pesar de estas discrepancias temporales, la correccin del pro-
ceso de sntesis estar asegurada si para cualquier seal A la forma de onda WA)
resultante de la simulacin-antes-de-sntesis coincide con la forma de onda WAo re-
sultante de la simulacin-despus-de-sntesis, al menos en aquellos perodos de
tiempo en los que su valor puede afectar al comportamiento del circuito. En diseo
sncrono, dichos perodos corresponden al tiempo en el que las seales son evalua-
das, usualmente, el tiempo de "set-up" de los biestables. En diseo asncrono, di-
chos perodos de tiempo estn deterininados por las seales de requerimiento y re-
conocimiento en el mecanismo de interfase correspondiente (Figura 4-7).
4. Sntesis 195
Forma de onda WA1

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

(despus de sntesis) nL-____---I_-___I--:.-----" __ -+__
: Perodo de : t
.comcareccn :
FIGURA 4-7. Discrepancias temporales.
Las discrepancias entre los resultados de simulacin-antes-de-sntesis y los de

la simulacin-despus-de-sntesis pueden afectar tambin a los valores de las sea-
les. Estas discrepancias de valor se producen por dos motivos. Por un lado, como
consecuencia de la codificacin lgica, usualmente std __ulogic o bit de tipos de
datos enumerados y enteros. Por otro, por la interpretacin en sntesis de los meta-
valores de los tipos y std_ulogic que se comentar posteriormente. A
pesar de estas discrepancias de valor, la correccin del proceso de sntesis estar
asegurada si para cualquier seal A la forma de onda WAo resultante de la simula-
cin-despus-de-sntesis es un caso particular de la forma de onda WA resultante
de la simulacin-antes-de-sntesis 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 errneas. Es nece-
sario, por ello, establecer una metodologa de uso de la herramienta de sntesis
VHDL que se vaya a emplear a partir del conocimiento de la semntica y los algo-
ritmos que utilice en cada etapa de sntesis.
4.3. SNTESIS RT-LG1CA
En este apartado se hace una breve introduccin a los modelos de sistema digital utili-
zados por las herramientas de sntesis y a los pasos de sntesis que aplican. Sntesis
RT y sntesis lgica utilizan modelos y algoritmos distintos. Sin embargo, desde el
momento en que ambas tareas se realizan conjuntamente en las herramientas de snte-
sis actuales, para el diseador 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 sntesis)
Forma de onda WAo

(despus de sntesis) ---
,
, Perodo de: t
: comparacin:
FIGURA 4-8. Discrepancias de valor.
4.3.1. Sntesis lgica

El modelo de sistema digital utilizado por las herramientas de sntesis es el modelo
general de mquina secuencial sncrona de Huffman constituido por un bloque de
lgica combinacional y un conjunto de elementos de memoria que almacenan el es-
tado actual de la mquina segn el esquema clsico de la Figura 4-9.
El proceso de sntesis lgica se divide usualmente en dos pasos:
optimizacin,
mapeado tecnolgico.
En el proceso de optimizacin, las ecuaciones lgicas son transformadas al ob-
jeto de satisfacer las restricciones de diseo en cuanto a rea, velocidad, consumo,
etctera. En el proceso de mapeado tecnolgico los elementos de la biblioteca en la
tecnologa utilizada (celdas estndar, mar de puertas, FPGA, PLD, etc.) se seleccio-
nan e interconectan al objeto de satisfacer la funcionalidad y las restricciones de di-
seo. Ambas tareas, optimizacin lgica y mapeado tecnolgico, son realizadas efi-
cientemente por las herramientas de sntesis comerciales disponibles en la actuali-
dad y, de hecho, constituyen el ncleo principal de las mismas.
4.3.2. Sntesis RT
El modelo de sistema digital utilizado por las herramientas de sntesis a nivel RT es
una extensin 3 del modelo de Huffman constituido por dos unidades:
3 Se trata de una extensin en el sentido de que siempre puede obtenerse el modelo de Huffman
equivalente.
4. Sntesis 197
Entradas I i> I
v
Salidas
Lgica
combinacional
1---
~
Seales d e Seales de
estado actu al est ado prximo
Elementos
de
memoria <j
/\

Je, R1...
Reloj
FIGURA 4-9. Mquina secuencial sncrona de Huffman.
la Unidad de Control (UC), y

la Unidad de Datos (UD),
segn el esquema de la Figura 4-10.
En la Unidad de Datos es donde tienen lugar las distintas operaciones, transfe-
rencias de informacin 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 mdulos RAM y ROM4
La Unidad de Control es la encargada de decidir en cada ciclo de reloj las
transferencias de informacin que deben de tener lugar entre registros en la UD as
como el siguiente estado de control a ejecutar. La UC se disea usualmente como
una mquina de estados finitos (FSM).
El proceso de sntesis RT se divide usualmente en dos pasos:
sntesis de la UD,
sntesis de la Ue.
La sntesis de la Unidad de Datos (UD) se divide usualmente en tres pasos:
optimizacin aritmtica,
identificacin de los elementos de memoria,
extraccin de las funciones lgicas.
4 Los mdulos de memoria RAM y ROM son considerados como externos a la descripcin RT
por la mayora de herramientas de sntesis.

Secuencacin
UNIDAD "-
Entradas
de control I
i)
v DE CONTROL I
Salidas
de control
~r
Seales Seales
del status de control
Q
Entradas
de datos I l> UNIDAD
DE DATOS I Salidas
de datos
Cmputo
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 sntesis realiza la extraccin desde el cdigo VHDL perdien-
do la informacin de alto nivel de partida. Su recuperacin requerira comenzar de
nuevo el proceso de sntesis desde la descripcin VHDL. Este es uno de los moti-
vos por los cuales el estilo descriptivo utilizado en el cdigo VHDL de entrada tie-
ne trascendencia en cuanto a los resultados de la sntesis. Es importante, por ello,
conocer los mecanismos empleados por la herramienta de sntesis que se est utili-
zando al objeto de asegurar resultados ptimos. Un caso tpico lo representan los
operadores aritmticos y las asignaciones indiferentes. Sin embargo, hay herramien-
tas que identifican los operadores aritmticos como componentes durante el proceso
de sntesis. De esta manera, son capaces de conservar parte de la informacin de al-
to nivel durante el proceso de optimizacin lgica, permitiendo, por ejemplo, cam-
biar el tipo de implementacin del operador. Esta misma situacin se presenta con
los elementos de memoria. Una vez inferidos, su repercusin en el diseo no se
puede evitar durante el proceso de sntesis.
La sntesis de la Unidad de Control (UC) consiste fundamentalmente en la
identificacin y sntesis del autmata de control y se divide usualmente en tres pa-
sos:
identificacin del autmata de control (estados y transiciones),
minimizacin de los estados de control,
asignacin secundaria.
De nuevo, en general, se trata de transformaciones destructivas respecto a la in-
formacin de entrada. Sin embargo, algunas herramientas marcan el registro de es-
tados, lo que permite conservar esta informacin de alto nivel. Tanto los algoritmos
de minimizacin de estados, sobre todo en el caso de mquinas incompletamente
4. Sntesis 199
especificadas, como, particularmente, los de asignacin secundaria, estn limitados

en cuanto al tamao de la Mquina de Estados Finitos (FSM) que son capaces de
manejar y en cuanto a su eficiencia. Siempre que el diseador sepa de antemano la
implementacin ptima en cuanto al nmero mnimo de estados y su codificacin
binaria, debe forzarlas desde la descripcin VHDL de entrada.
4.4. DESCRIPCIN VHDL DE CIRCUITOS DIGITALES
En este apartado se detalla la descripcin en VHDL de los componentes funda-

mentales de un sistema digital. Este conocimiento es imprescindible a la hora de
asegurar que la implementacin propuesta por la herramienta de sntesis coincide
funcionalmente con la que se desea. Como ya se ha comentado, la carencia de una
metodologa estndar de sntesis desde VHDL impide una descripcin general del
uso del lenguaje en sntesis sin hacer referencia a particularidades y excepciones
concretas propias de determinadas herramientas y no de otras. Este apartado pre-
tende ser 10 ms general posible, de tal forma que las recomendaciones de diseo
que incluye sean vlidas independientemente de la herramienta que se utilice. El
objetivo de este texto es asegurar que el lector, con un mnimo esfuerzo adicional
de conocimiento de la herramienta concreta que utilice, est en disposicin de ob-
tener los mejores resultados de la misma en un tiempo breve.
4.4.1. Descripcin 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
sntesis generar una nueva arquitectura asociada a la misma entidad.
Tal y como se ha visto en el Captulo 2, la arquitectura VHDL est compuesta
de las siguientes sentencias concurrentes:
sentencias de asercin concurrente que son ignoradas,
bloques,
llamadas concurrentes a procedimientos,
asignaciones concurrentes de seal,
referencia a componentes,
procesos, y
sentencias de generacin que se sustituyen por el cdigo iterativo equiva-
lente.
Salvo en lo que respecta a las sentencias de referencia a componentes, la jerar-
qua se elimina por defecto y todas las asignaciones de seal 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 jerarqua el cdigo asociado a un proceso, bloque o subprograma. Los ope-
radores aritmticos son tratados como componentes adicionales y optimizados inde-
pendientemente. En algunos casos, la herramienta posee la capacidad de asociar va-

rias operaciones aritmticas a la misma unidad operacional con objeto de minimizar
la lgica resultante (" resource sharing"). Las referencias a componentes hacen re-
lacin a otras entidades que, usualmente, se sintetizan conservando o eliminando la
jerarqua mediante directivas de usuario a la herramienta.
4.4.2. Modelado de la informacin
De las cuatro categoras de tipos definidos en el estndar, slo los tipos escalares y
compuestos son usualmente soportados. De las cuatro categoras de tipos escalares
definidos en el estndar, slo los enteros y enumerativos son usualmente soportados
en sntesis. Los tipos fsicos y flotantes o son ignorados o no son admitidos.
Los tipos enteros se sintetizan como vectores de bits con la dimensin adecua-
da al rango con que se han definido. Si el rango incluye valores negativos, la con-
versin suele hacerse en complemento a 2, en caso contrario en binario sin signo.
As, la seal entera Temperature:
signal Terrperature is Integer range - 75 te 120;
se implementara en un conjunto de 8 bits:

8
Z' t>
con la siguiente codificacin:
-75 => 10110101

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

adecuada al nmero de valores distintos con que se hallan definido. La codificacin
suele ser en binario con valores crecientes siguiendo el orden de la declaracin.
Aunque normalmente es preferible realizar la asignacin secundaria directamente
durante el proceso de sntesis, algunas herramientas permiten al usuario la codifica-
cin 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. Sntesis 201
Un caso especial 10 representan los tipos enumerativos con semntica hardwa-

re. Los ms importantes son los tipos std_logic y std_ulogic del paquete estndar
Std_Logic_1l64, soportado por todas las herramientas comerciales. Sin embargo,
cada una de ellas tena una interpretacin diferente de los valores definidos en los
tipos estndar y trataba de forma distinta las asignaciones, comparaciones y senten-
cias condicionales en los que intervienen objetos de este tipo. Esta situacin ha
cambiado con la publicacin del estndar IEEE P1076.3-1996 "Standard VHDL
Synthesis Packages" [IEEE96] que se comenta a continuacin.
Con respecto a los tipos compuestos, la mayora de las herramientas de sntesis
soportan matrices unidimensionales, usualmente de bits y en algn caso de enteros.
El tipo registro (record) es soportado por muy pocas herramientas.
4.4.3. Funciones y operadores
La mayora de herramientas comerciales soportan los operadores VHDL estndar

sobre los tipos de datos aceptados por la herramienta, salvo los de multiplicacin,
divisin, resto, mdulo y elevacin a potencia. En general, estos ltimos slo se
permiten si ambos operadores son constantes. Algunas herramientas soportan la
multiplicacin y la divisin generando el mdulo de lgica combinacional corres-
pondiente. Otras herramientas slo admiten multiplicaciones y divisiones por cons-
tantes potencia de dos implementando la operacin como un desplazamiento a iz-
quierda o derecha respectivamente. Algunas herramientas soportan la operacin
mdulo de una potencia de 2. Como se ver ms adelante, esta operacin es til en
la descripcin de contadores.
Las funciones de usuario estn usualmente permitidas, siempre que no hagan
overloading de funciones predefinidas. Las funciones de resolucin de usuario no
estn normalmente permitidas y es necesario, usualmente, recurrir a las funciones
predefinidas en la herramienta.
Todas las herramientas de sntesis incluyen paquetes de funciones aritmticas y
lgicas 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 aritmticos estndar incluidos en el estndar
IEEE PI076.3-l996.
4.4.4. Paquetes de sntesis P1076.3
Con el objetivo de avanzar en la interoperabilidad entre herramientas de sntesis, se

constituy el grupo de estandarizacin IEEE 1076.3 "Standard VHDL Synthesis
Packages". Aprobados en febrero de 1997, los paquetes de sntesis cubren las si-
guientes reas:
4.4.4.1. Interpretacin hardware de tipos estndar

En esta seccin se define el modo en el que la herramienta de sntesis debe de inter-
pretar los valores de los tipos lgicos estndar. Los tipos lgicos estndar conside-
rados son los siguientes:
type Bit la ('O', '1');

type Boolean la (False, True);
type StLUlogic 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. Interpretacin de los valores lgicos fuertes

('O', '1', false, true)
La herramienta de sntesis debe de interpretar los siguientes valores:
'O' del tipo Bit.
False del tipo Boolean.
'O' del tipo Std_Ulogic.
como representacin del nivel lgico correspondiente a la tensin de referencia nor-
malmente denominada tierra. As, por ejemplo, la asignacin:
S <; x or 'O';
sera equivalente al circuito de la figura:
x-p-s
La herramienta de sntesis debe de interpretar los siguientes valores:
'1' del tipo Bit.

True del tipo Boolean.
'1' del tipo Std_Ulogic.
como representacin del nivel lgico correspondiente a la tensin de alimentacin,
denominada usualmente Vce O V DO. As, por ejemplo, la asignacin:
s <= x and '1';

4. Sntesis 203
sera equivalente al circuito de la figura:
x---=O-s
4.4.4.1.2. Interpretacin de los valores lgicos
dbiles ('L', 'H')
El estndar 1076.3 no especifica ninguna interpretacin para los valores lgicos 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 idntica a los valores
fuertes 'O' y '1' respectivamente. Al objeto de no restringir tecnologas futuras en
las que sea relevante diferenciar en sntesis la fuerza asignada al valor de una seal,
se decidi no forzar una interpretacin en la actualidad.
4.4.4.1.3. Interpretacin de los valores metalgicos dbiles

('U', 'W', 'X', '-')
La utilizacin de los valores metalgicos 'U', 'W' y 'X' carece de sentido en snte-
sis. Sin embargo, en una descripcin VHDL para sntesis cabe la utilizacin de
estos valores en la simulacin del cdigo. Aunque el valor indiferente '-' s tiene
sentido en sntesis, su interpretacin estndar es idntica a la del resto de valores
metalgicos, salvo en la funcin Std-Match. La herramienta de sntesis debe de so-
portar la utilizacin de estos valores con la siguiente interpretacin:
Si uno de los operandos en una igualdad es un valor metalgico esttico 5 o
un vector en el que uno de los elementos es un valor metalgico esttico, la
herramienta de sntesis debe de interpretar la igualdad como falsa. De esta
forma, para la herramienta de sntesis, 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 comparacin de '-' con cual-
quier otro valor debera evaluarse siempre como cierta. Sin embargo, los
5 Esttico significa que el operando es un literal 'U', 'W', 'X' o '-'. Dinmico se utilizara en el
caso de que el operando fuera una variable o seal que, en tiempo de simulaci6n, tomara uno de los va-
lores metal6gicos.
operadores de comparacin definidos en el paquete Std_Logic_1J64 no tra-

tan al valor '-' de esta manera. La misma equivalencia se habra establecido
si en vez del valor metalgico '-' se hubiera utilizado cualquier otro.
En el caso de tratarse de una desigualdad, sta se evaluara como cierta. As,
para la herramienta de sntesis, 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 metalgico como alternativa o como

elemento en una alternativa en una sentencia secuencial de seleccin (case),
la herramienta de sntesis debe de considerar que dicha alternativa no puede
ejecutarse nunca. El cdigo sera equivalente a la eliminacin 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 utilizacin de valores metalgicos en sentencias de asignacin de seal

seleccionada tienen la interpretacin que corresponde a la conversin de la
asignacin concurrente en la sentencia secuencial de seleccin equivalente.
La utilizacin de valores metalgicos estticos como operando o elemento de
operando en una operacin lgica, aritmtica o de desplazamiento en la que
el otro operando no es un valor esttico, debe de considerarse como un error.
4. Sntesis 205
La utilizacin de un valor metalgico en operaciones de concatenacin, con-

versin de tipo y de extensin de signo est permitida en sntesis sin ninguna
interpretacin especial.
La utilizacin de un valor metalgico como forma de onda o parte de una for-
ma de onda en una sentencia de asignacin est permitida. El estndar no espe-
cifica ninguna interpretacin particular para el valor metalgico en este caso 6.
4.4.4.1.4. Interpretacin del valor de alta impedancia (IZI)

La utilizacin del valor esttico 'Z' en una forma de onda implica la inferencia de
un buffer triestado habilitado por la condicin de control de la asignacin. La salida
del buffer sera el objeto (sealo variable) destino de la asignacin. La entrada al
buffer sera la lgica correspondiente al valor del destino aparte de cualquier asig-
nacin a 'Z'. As, por ejemplo, el siguiente cdigo:
y <= yl&y2;
with y select
z <= xl and x2 when '00",
'Z' when "01",
'Z' when "lO",
xl when "11";
se correspondera con el circuito de la figura:
Cualquier otra ocurrencia de un valor esttico de alta impedancia tiene el mis-

mo tratamiento que el de un valor metalgico en la misma situacin.
4.4.4.2. Expresiones de valor inicial y por defecto

Las herramientas de sntesis deben de aceptar expresiones de valor inicial en decla-
raciones de variable y de valor de defecto en declaraciones de seal pero no se
requiere ninguna interpretacin para este tipo de construcciones. Tal y como
se comentar posteriormente, el diseador debe de evitar que el comportamiento
del cdigo VHOL dependa de este tipo de expresiones.
6 La mayora de las herramientas de sntesis interpretan los valores metalgicos como indife-
rentes.
4.4.4.3. Deteccin de la transicin activa de la seal de reloj
Independientemente de las expresiones particulares que la herramienta de sntesis

utilice para representar la transicin activa de la seal de reloj, debe tambin 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 aritmticos
Uno de los principales motivos de incompatibilidad entre herramientas de sntesis

lo representan los paquetes aritmticos soportados por cada herramienta. Estos pa-
quetes incluyen, principalmente, operadores aritmticos sobre. vectores de Bits o
Std_Logic. Aparte de su utilidad en sntesis, estas funciones permiten acelerar la si-
mulacin de la descripcin, ya que pueden ser identificadas y sustituidas por fun-
ciones compiladas previamente ("built-in").
Los paquetes aritmticos 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 representacin en bina-

rio de un nmero natural. El tipo Signed representa en complemento a 2 un nmero
entero. En particular, un valor de tipo Signed de un nico bit representara los valo-
res numricos -1 y O. En ambos casos, el bit ms 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
funcin binaria est repetida seis veces en cada paquete. Al objeto de facilitar el
cambio de un paquete a otro, la mayora de las funciones definidas en un paquete se
definen tambin en el otro. Concretamente, las funciones recogidas en las siguien-
tes tablas son comunes:
4. Sntesis 207
Funciones 7
Descripcin Operandos Resultado
aritmticas
"abs" valor absoluto Signed Signed

"" cambio de signo Signed Signed
"+" adicin Unsigned- Unsigned Unsigned
Signed-Signed Signed
Unsigned-Natural Unsigned
Signed-Integer Signed
"" substraccin Unsigned-Unsigned Unsigned
Signed-Integer Signed
"*,, multiplicacin Unsigned-Unsigned Unsigned
Signed- Integer Signed
rr divisin 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" mdulo Unsigned-Unsigned Unsigned
argumento es nulo, se Unsigned-Natural Unsigned
produce un ERROR) Signed-Integer Signed
Funciones de
Descripcin Operandos 7 Resultado
comparacin
">" 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 estn definidas tambin para el orden
opuesto de los tipos de los operandos.

Funciones de
comparacin
"<=" 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 rotacin Unsigned-Natural Unsigned
Rotate_Right rotacin Unsigned-Natural Unsigned
"sIl" desplazamiento Unsigned-Natural Unsigned
"srl" desplazamiento Unsigned-Natural Unsigned
"rol" rotacin Unsigned-Natural Unsigned
"ror" rotacin Unsigned-Natural Unsigned
8 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando

representa el nmero de desplazamientos a efectuar sobre el primer operando.
4. Sntesis 209
Funciones lgicas Descripcin Operandos Resultado
"not" complementacin Unsigned Unsigned

Signed Signed
"and" funcin lgica "y" Unsigned-Unsigned Unsigned
bit a bit Signed-Signed Signed
"or" funcin lgica "o" Unsigned-Unsigned Unsigned
"nand" funcin lgica "no-y" Unsigned- Unsigned Unsigned
"nor" funcin lgica "no-o" Unsigned- Unsigned Unsigned
"xor" funcin lgica "0- Unsigned- Unsigned Unsigned
exclusiva" bit a bit Signed-Signed Signed
"xnor" funcin lgica "no-o- Unsigned-Unsigned Unsigned
exclusiva" bit a bit Signed-Signed Signed
Funciones de 9
conversin
Resize re-dimensionado Unsigned-Natural Unsigned

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

nes Rising_Edge y Falling_Edge para seales 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 funcin de traslacin:
Funcin de
traslacin
To_Ol Conversin a o 1 Unsigned-Std_Logic

Signed-Std_Logic
Unsigned
Signed
representa el tamao 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 funcin ('O' por de-
fecto).
Como ya se ha comentado anteriormente, ni en las funciones de comparacin
VHDL estndar 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 comparacin en el que el valor '-' acte efectivamente co-
mo valor indiferente, el paquete Numeric_Std incluye la funcin Std_ Match. As:
Std,_Match (01W:OL1ZUUH, IlH)-1-1) = '1.';
Sin embargo:
StQjMatch (01UXOL1ZUUH, LHU-0-1-1) = 'O';
Std_Match Comparacin Std_ Ulogic-Std_ Ulogic Boolean

con utilizacin del Std_Logic_ Vector-Std_Logic_ Vector Boolean
valor indiferente Std_Ulogic_ Vector-Std_Ulogic_ Vector Boolean
Unsigned- Unsigned Boolean
4.4.5. Descripcin de lgica combinacional
En VHDL, la lgica combinacional puede ser descrita mediante asignaciones con-

currentes de sealo procesos'f. Un conjunto de asignaciones concurrentes de seal
describen lgica combinacional siempre que:
a) La seal destino no interviene en la forma de onda de ninguna asignacin.
As, por ejemplo, la asignacin:
a <= b and e when e = 'o' e1se '1';
se corresponde con lgica combinacional. Una posible implementacin se-

ra 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 lgica secuencial.
representa el valor a asignar cuando se detecta una discrepancia (por defecto 'O').
12 Como ya hemos comentado anterioimente, para cualquier asignacin concurrente existe un
proceso equivalente.
4. Sntesis 211
FIGURA 4-11. Implementacin de asignacin 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 descripcin alternativa de la implementacin de la Figu-

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

Tanto las asignaciones de seal seleccionadas como condicionales son soporta-
das. La asignacin de seal seleccionada se corresponde funcionalmente con un
multiplexor en el que la expresin se corresponde con la seal de control. sta ser
la implementacin final, siempre que durante el proceso de optimizacin no se en-
cuentre una implementacin alternativa mejor en trminos de coste o velocidad.
As, por ejemplo, el cdigo siguiente:
y <= y1&y2;
with y select
z <= xl and x2 when "OO,
xl when "01,
x2 when "lO",
'1' when "11";
Tendra una implementacin directa con el multiplexor 4 x 1 de la Figura 4-12.

Sin embargo, dependiendo de las restricciones de diseo, la implementacin de
la Figura 4-13 puede ser preferible en un diseo dado.
La asignacin de seal condicional se corresponde funcionalmente con una ca-
dena de multiplexores 2 x 1 en el que las condiciones se corresponden con las sea-
les de control. sta ser la implementacin final, siempre que durante el proceso de
optimizacin no se encuentre una implementacin alternativa mejor en trminos de
coste o velocidad. As, por ejemplo, el cdigo 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. Implementacin directa de asignacin seleccionada.
Tendra una implementacin directa con la cadena de multiplexores de la Figu-

ra 4-14.
Sin embargo, dependiendo de las restricciones de diseo, la implementacin de
la Figura 4-13 puede volver a ser preferible en un diseo dado.
Algunas herramientas soportan el agrupamiento de sentencias concurrentes en
bloques. Como ya se ha comentado, las herramientas eliminan usualmente la jerar-
qua. Los bloques con seal de guarda pueden ser usados en la descripcin 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. Implementacin alternativa de asignacin seleccionada.

4. Sntesis 213
FIGURA 4-14. Implementacin directa de asignacin condicional.
A partir de los paquetes de sntesis, la utilizacin del valor std_logic 'Z', impli-
ca la descripcin 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 seal 'z' tiene que ser de clase bus, al igual que ocurra 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 lgica combinacional es mediante procesos. Un

proceso describe lgica combinacional siempre que:
a) Todas las seales utilizadas en la forma de onda de alguna de las asignaciones

secuenciales de seal 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 condicin. 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 lgica descrita podra implementarse con el circuito de la Figura 4-11.
Algunas herramientas de sntesis 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-
lacin antes y despus de sntesis adicionales a las consideradas con anterioridad.
b) Bajo cualquier condicin de ejecucin 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 descripcin alternativa a la implementacin de la Figura 4-11.
Por el contrario, en el proceso siguiente la variable "d" no cumple la condicin:
process (b, e, e)
variable d: ... ;
begin
if (b = '1') then
d := C; .
end if;
a <= dore;
end process;
LISTADO 4-5. Cdigo secuencial.

4. Sntesis 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 sntesis de este proceso es idntico al del proceso siguiente

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

por tanto, de situaciones que conviene evitar. En algunas herramientas este tipo de
situaciones no estn permitidas. En otras, la herramienta avisa de la discrepancia
entre simulacin y sntesis.
La descripcin combinacional mediante procesos es mucho ms flexible que me-
diante asignaciones a seal concurrentes. La causa de este hecho reside en la mayor
flexibilidad del cdigo secuencial en VHDL que la del cdigo concurrente. Mientras
la estructura de una asignacin a seal seleccionada est fija, su equivalente secuen-
cial, la sentencia case, permite incluir cualquier tipo de cdigo secuencial en cada al-
ternativa. Esta mayor flexibilidad es posible encontrarla tambin en la sentencia
if...then ... else frente a la sentencia de asignacin condicional. En consecuencia, aun-
que tambin aqu es posible encontrar una relacin funcional entre el cdigo y el
hardware, esta relacin suele ser menos directa que en el caso concurrente.
As, por ejemplo, el cdigo:
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;
tendra como implementacin directa el multiplexor 4 x 1 de la Figura 4-12. Sin

embargo, dependiendo de las restricciones de diseo, la implementacin de la Figu-
ra 4-13 puede volver a ser preferible. De la misma forma, la implementacin direc-
ta del cdigo siguiente sera la cadena de multiplexores de la Figura 4-14. Sin
embargo, dependiendo de las restricciones de diseo, la implementacin de la
Figura 4-13 puede volver a ser preferible en la mayora de los casos. Es importante
destacar que la sntesis asegura la correspondencia funcional entre la descripcin de
entrada y la implementacin lgica resultante con las discrepancias temporales y de
valor comentadas anteriormente. Sin embargo, la implementacin concreta en puertas
va a depender de las restricciones de diseo impuestas y de la tecnologa 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 construccin que aade flexibilidad a la descripcin

de lgica 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 implementacin 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 lgica.
Tanto en el caso de las asignaciones a seal concurrentes como secuenciales,
las herramientas de sntesis slo soportan formas de onda simples compuestas por
una expresin y un retraso. El retraso slo tiene sentido en simulacin, ya que en
sntesis se ignora. Esto se debe a que, como se coment en la introduccin, 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 diseo sncrono, es la seal de reloj la que provoca el cambio de estado
con lo que todas las seales 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 sntesis. Es responsabilidad del disea-
dor asegurar que la funcionalidad del diseo no depende de los retrasos concretos
que cada asignacin tenga en la implementacin final a nive11gico.
4. Sntesis 217
4.4.6. Descripcin de "Iatches"
La mayora de las herramientas infieren latches cuando en un proceso se relaja la

condicin b). As, por ejemplo, el cdigo siguiente:
latch: process (D, en)

begin
if (en = '1') then
Q <= D;
end if;
end process latch;
sera la descripcin explcita 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 sintetizara mediante un latch
en la variable "d":
b e
Algunas herramientas infieren "latches" de asignaciones concurrentes de seal

en las que la seal destino participa en la forma de onda. As, la asignacin:
a <= b and e when h ='1' e1se a;
se sintetizara mediante el siguiente circuito:

Este tipo de inferencia se puede realizar siempre que la herramienta sea capaz
de identificar la seal de habilitacin dellatch. Otras herramientas, sin embargo, in-
fieren la lgica asncrona directa correspondiente advirtiendo al diseador de esta
situacin. Esta implementacin no garantiza la ausencia de carreras:
Algunas herramientas permiten utilizar bloques con seal de guarda para des-
cribir latches. La seal de guarda debe de especificar un valor y nunca un evento.
As, por ejemplo, el cdigo siguiente:
latch: block (en = '1')

begin
Q <= guarded D;
end block;
Sera una descripcin alternativa a la de la Figura 4-15 con el mismo resultado

en sntesis.
4.4.7. Descripcin de la seal de reloj
Se identifican como seales de reloj aquellas seales de comportamiento correcto

con especificacin de evento y flanco. La forma ms usual es:
reloj'EVENT and reloj = '1'

4. Sntesis 219
Algunas herramientas soportan tambin la forma:

not reloj_STABLEand reloj = '1'
Cuando la seal 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 transicin activa de la seal de reloj se produce entre

los valores 'O' y '1' Yno desde cualquier otro valor.
Tal y como se ha comentado anteriormente, el estndar de sntesis IEEE
1076.3-1996 propone la utilizacin de las funciones Rising_Edge y Falling_Edge
para la deteccin de la transicin de subida y bajada de la seal de reloj respectiva-
mente.
4.4.8. Registros
Se identifican como registros aquellas seales cuya asignacin dependen de una se-
al de reloj.
Un bloque con seal 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 deteccin dela transicin activa de la

seal de reloj es igualmente vlida:
ex2 : block (not reloj' stable and reloj ~ '1')

begin
Q <= guarded D;
end block;
Un proceso con sentencia de espera puede ser utilizado tambin 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 seal de reloj:
process (rel~j~
begin _,
if (reloj'event and reloj = '1') then
Q <= D;
end if;
end process;
Este ltimo estilo admite la inclusin de seales de set y reset, ya sean sn-
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 asncronas:
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 lgica sintetizada sera la siguiente:

4. Sntesis 221
reset
reloj
En el caso de que la sentencia de espera se situara al principio, la lgica sera la

siguiente:
reset
reloj
La diferencia en uno u otro caso proviene del valor inicial de la seal D tras la
primera ejecucin del proceso.
Sobre la seal de reloj se imponen usualmente una serie de condiciones de uso
que la caracterizan como una seal de comportamiento correcto. Las ms usuales
son las siguientes:
Generalmente, slo se admite la especificacin de un evento por proceso (o

bloque) lo que se traduce en un nico reloj por proceso. La siguiente descrip-
cin sera, 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 seal de reloj se utiliza en una construccin condicional, no se

pueden especificar acciones en la clusula else. La siguiente descripcin se-
ra, por tanto, incorrecta:
if (reloj'event and reloj '1') then

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

descripcin sera, por tanto, incorrecta:
if not (reloj'event and reloj= '1') then ...
Algunas herramientas permiten la obtencin de seales de reloj a partir de ope-

raciones lgicas sobre otra seal de reloj. Estas seales 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 implementacin directa del cdigo anterior sera:
reset
D----I Q
senal_control
reloj
Esta implementacin, evidentemente, no est exenta de peligros en la seal re-

loj_derivado si la seal de control se genera combinacionalmente.
4. Sntesis 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-
cin de los operadores de desplazamiento representa la forma ms simple de descri-
bir un registro de desplazamiento:
RD <= Shift_night (RD, 2);
RD <= RD sIl 2;
~
I ~ I ~I I 'O'
La concatenacin permite descripciones explcitas:
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 diseo digital. La for-
ma ms usual para describirlos en VHDL es mediante operaciones de incrementa-
cin y/o decrementacin. As, la siguiente sera la descripcin 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 comparacin para detectar los l-

mites de cuenta pueden aadir lgica extra. Las herramientas que soportan el opera-
dor mdulo evitan este problema con la identificacin directa del retomo al valor
inicial. La siguiente sera la descripcin 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 sncronos, ya que la carga sobre la seal
contador se realiza en la transicin activa de la seal de reloj. La descripcin de
contadores asncronos (ripple counters) requiere de un estilo descriptivo explci-
to. As, por ejemplo, la siguiente sera la descripcin de un contador asncrono
mdulo 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. Sntesis 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. Descripcin de FSMs
Existen varios estilos de descripcin VHDL de FSMs. Cada uno de ellos ser el
ms apropiado, dependiendo de la herramienta y el tipo de mquina que se quiera
describir. Los resultados de sntesis en cada caso van a ser diferentes.
Los estilos descriptivos para FSMs se pueden agrupar en explcitos e implci-
tos. En el estilo explcito el, la FSM se describe utilizando un proceso combinacio-
nal para describir la funcin de prximo estado y las asignaciones de salida y un
proceso secuencial para describir las asignaciones sobre el registro de estados en la
transicin activa de la seal de reloj. Este estilo identifica claramente la parte com-
binacional de los elementos de memoria segn el modelo general de mquina se-
cuencial de Huffman:
entity FSM is
port (reloj, reset: in std_ulogic; _ seales de reloj y reset
xl , ... xn in std_ulogic _ seales de entrada
zl, ._ zm out std_ulogic); _ seales 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; _ seal de prximo estado
begin "
SID:process (estado, xl, ...xn)
begin
nxt_estado <= estadO; _ asignacin por defecto
case estado ls
when sO => _ estado sO
_ acciones del estado .sO:
_ asignacin de estado prximo
- asignaciones. de sal~da
when sp => - estado, sp

- acciones del estado sp:
- asignacin de estado prximo
4. Sntesis 227
_ asIgnaciones de salda
"<,
end case;
end process SIn;
relojd:process (reset, reloj)

begin
if (reset = 'O') then
estado <= sO; _ reset asncrono
elsif (reloj'event and relj,~ ,1') then
estado <= ~t_estado; _ transicin 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-
ra un proceso con una sentencia de espera de la seal de reloj en vez de lista de
sensibilidad:
relojd:process
begin
wait until reloj = '1';
estado <= sO; - reset sncrono
elee
estado <= nxt_estado; _ transicin de e$tado
end if;
end process relojd;
En algunas herramientas, esta segunda posibilidad impide la descripcin de seales

de reset asncrono para los elementos de memoria. Debido a su simplicidad y a que
las nicas tareas delegadas a la herramienta de sntesis son las de optimizacin lgi-
ca y mapeado tecnolgico, el estilo descriptivo el es con el que resulta ms fcil la
obtencin de resultados de sntesis ptimos.
El registro de estados puede identificarse mediante un atributo lo que permite a
la herramienta la identificacin de los estados de la mquina y la extraccin de las
transiciones entre estados. Esta informacin facilita los procesos de asignacin se-
cundaria y minimizacin de estados.
Ejemplo 4.2. Dada la mquina definida por el diagrama de estados de la Figu-

ra 4-16.
Su descripcin en el modelo explcito el sera la siguiente:
entity FSM i.
port ( reloj, reset : in std_ulogic; _ seales de reloj y reset
x in std_ulogic; _ seal de entrada
228 VHOL. Lenguaje estndar de Diseo Elecrrnico
%, 1/1
1/0 1/1
%
1/0
0/1
FIGURA 4-16. Diagrama de estados.
z out std_ulogic); _ seal 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; - seal de prximo estado
begin
sm: process (estado, x)
begin
nxt_estado <= estado; - asignacin por defecto
case estado is
when sO => - estado sO
z <= '0'; _ asignacin de salida
if (x = 'O') then _ asignacin de estado prximo
nxt_estado <= sl;
else
nxt_estado <= s2;
end if;
when sl => _ estado sl
z <= x; - asignacin de salida
nxt_estado <= sO; '- asignacin de estado prximo
when s2 => - estado s2
z <= 'DI i - asignacin de salida
4. Sntesis 229

nxt_estado <= sl;
elae
nxt_estado <= s3;
end if;
when s3 => _ estado s3
z <= '1'; _ asignacin de salida
if (x = '1') then _ asignacin de estado prximo
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; _ transicin de estado
end if; .
end procesa relojd;
end el;
En el estilo explcito 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 sincrona con la seal de reloj, por 10 que slo es posible
describir mquinas de Moore. Este hecho es de particular importancia porque todas
las seales asignadas van a inferir biestables y, por ello, este estilo descriptivo slo
es apropiado cuando se desee este tipo de implementacin. En cualquier caso, este
problema se puede evitar extrayendo la funcin de salida a un proceso combinacio-
nal dependiente del estado actual y las entradas. Dado que, normalmente, las salidas
de la mquina 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 sncrono
else
case estado is
_ acciones del estado sO:
_ transicin de estado y
_ asignaciones de salida
when sp => _ estado sp

- accones del estado sp:

- transicin de estado y
- asignaciones de salida
end case;
end if;
end process SID;
end e2;
Ejemplo 4.3. La descripcin VHDL en el estilo explcito e2 de la mquina de la

Figura 4-16 sera 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 sncrono
else
case estado is
z <= ' O' ; ..:.
asignacin a registro de salida
if (x =' 'O') then '- asignacin de estado prximo
estado := sI;
else
estado := s2;
end if;
when sI => - estado sI
z <= x; ~ asignacin a registro de salida
estado := sO; - asignadi6nde estado prximo
z <= '0'; - asignacin de salida
if (x = '0') then - asignacin de estado prximo
estado := sI;
elae
estado := s3;
end if;
z <= '1'; - asignacin de salida
if (x = '1') then - asignacin de estado prximo
estado := sI;
end if;
end case;
end if;
end process sm;
end e2;
LISTADO 4-7. Descripcin en estilo e2.

4. Sntesis 231
Aunque, aparentemente, el nmero de estados no ha variado respecto al ejem-

plo anterior, esta descripcin aade 'z' como elemento de memoria, lo que duplica
.l nmero real de estados de la mquina. Uno de estos estados es redundante, ya
que el diagrama de estados de la mquina Moore equivalente tiene slo siete esta-
dos tal y como se muestra en la Figura 4-17.
No todas las herramientas de sntesis son capaces de encontrar la mquina de
estados mnima.
Como se concluye del ejemplo, en este estilo la calidad del resultado descansa
en mayor medida sobre la efectividad de los algoritmos de minimizacin de estados
de la herramienta. Estos algoritmos no tienen la efectividad de los algoritmos de
minimizacin lgica, 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 mayora de las herramien-
tas, de describir capacidad de inicializacin asncrona.
Las principales ventajas del estilo provienen de su simplicidad, desde el mo-
mento en que la mquina queda descrita en un nico proceso, y de que todas las sa-
lidas estn registradas, lo que asegura la ausencia de peligros. Este hecho puede ser
particularmente interesante cuando se desean generar seales de control limpias (sin
peligros).
En el estilo explcito e3, la FSM se describe utilizando un nico proceso se-
cuencial con las seales de reloj, reset, registros de estado y entradas en la lista de
sensibilidad. El cdigo secuencial se divide en cuatro partes diferenciadas de las
que se infiere distinto tipo de lgica:
o
o
o
o
FIGURA 4-17. Diagrama de estados de mquina 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
_ lgica combinacional

lf (reset = '0') then
elsif Rising_Edge(reloj) then
case estado ls >

_ accionesdelestad sO:
_ transiCi6n de estado y
_ asignaciones a registro de salida
when sp => _ estado sp

_ aC9iones del estado sp:
_ trenscn de estado y
_ asignaciones a registro de salida
end case;
end if;
_ lgica combinacional
end process sm;

end e3;
Este estilo es el ms flexible, ya que permite describir en un nico proceso l-

gica combinacional, lgica secuencial e inicializacin sncrona o asncrona 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 lgica combinacional.
Las asignaciones en el cuerpo de la sentencia:
lf (reset = ' O') then...
van a corresponderse con la inicializacin asncrona. Las asignaciones en el cuerpo

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

seccin podra incluirse la inicializacin sncrona de los elementos de memoria.
4. Sntesis 233
No todas las herramientas soportan cdigo fuera de la sentencia condicional de

las seales de inicializacin y reloj. Las herramientas que lo soportan imponen res-
tricciones en cuanto a las asignaciones de, seal que se pueden hacer en cada parte
(antes y despus) en relacin con el cdigo secuencial, principalmente en la parte
final.
Ejemplo 4.4. Dada la mquina definida por el diagrama de estados de la Figu-

ra 4-17, la descripcin en el estilo explcito e3 sera 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 _ lgica 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 prximo
estado <= sl;
else
estado <= 63;
end if;
if (x = '1') then _ asignacin de estado prximo
estado <= sl;
end if;
end case;
end if;
end procesa sm:
end el;
En el estilo implcito de descripcin, la FSM se describe utilizando un proceso

con varias sentencias de espera de la seal de reloj como en el Listado 4-8. Recibe
el nombre & estilo descriptivo implcito debido a que adems de los P estados ex-
plcitos en la declaracin del tipo "estados" de la seal de estado 13, la descripcin

incluye los N estados introducidos por las sentencias de espera. El nmero de esta-
dos total de la mquina resulta N*P. Aunque, en ciertos casos, ste pueda ser el esti-
lo descriptivo ms cmodo, presenta el peligro del aumento indeseado en el nmero
de estados. Dado que, como se ha comentado con anterioridad, los algoritmos de
minimizacin 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 mquina se adapta al mismo y que, por tanto, los resulta-
dos de la sntesis van a ser aceptables. Debido a que todas las asignaciones de seal
se ejecutan en el flanco activo de la seal de reloj, slo es posible describir mqui-
nas de Moore. Es posible la inicializacin asncrona del registro de estados implci-
to cuando el cdigo 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 inicializacin sncrona de los elementos de memoria del re-
gistro de estados explcito, siempre que el cdigo entre las sentencias de espera se
estructure en una sentencia:
if (reset = '1') then ... end if;
e1se ...
architecture implcita of FSM iB

type estados ia (sO, ...sp);
begin
sm:process
variable estado: estados := sO; - registro de estados ~lcitos
begin
- acciones del estado implcito 1
acciones del estado implcito n

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

4. Sntesis 235
Muy pocas herramientas de sntesis soportan este estilo en el momento presen-

te. De nuevo, dado que, normalmente, las salidas de la mquina no van a coincidir
con el registro de estado, ste puede declararse como variable.
Ejemplo 4.5. El Listado 4-9 sera la descripcin VHDL en estilo implcito de la

mquina 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'; - asignacin a registrq de salipa
if (x = '1') then
wait until reloj '1'; - estado s2
z <= 'o' i - asignacin a registro de salda
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'; - aaqnac.n a r~istro de salida
end loop;
end if;
end if;
wait until reloj i l' ; - estado sl
Z <= Xi - asignacin a registro de salida
end process smr
end implcita;
LISTADO 4-9. Descripcin en estilo implcito.
4.4.10. Descripcin de FSMDs
Recibe el nombre de FSMP, o mquina de estados finitos con unidad de datos tam-
bin denominada ASM o mquina de estados algortmica, a la conjuncin de un au-
tmata de control y una unidad de datos segn 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 descripcin VHDL de
FSMDs sin ms que incluir en cada estado las acciones a ser realizadas en la unidad
de datos. Los estados explcitos (o implcitos) de la mquina se correspondern con
los estados de control mientras que los recursos hardware necesarios en la imple-
mentacin de las acciones a realizar en los estados de control constituirn la unidad
de datos.
En el caso ms general, un sistema digital a nivel RT estar compuesto de una

o varias FSMs y/o FSMDs, mdulos de lgica combinacional y registros. La des-
cripcin VHDL del multiplicador secuencial del Listado 4-3 constituye un ejemplo
de FSMD.
4.4.11. Segmentacin
La descripcin 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 explcito 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 mxima de funcionamiento est limitada por el

peor de los retrasos en los bloques de lgica combinacional (suponiendo idnticas
caractersticas de tiempo de carga, TH, y retraso, TR, en los registros):
4. Sntesis 237
1
. Fmx = ----------
TR + mx (TI, T2, T3) + TH
Algunas herramientas permiten optimizar automticamente el circuito disminu-

yendo el camino crtico mediante la tcnica de retemporalizacin (retiming). Esta
tcnica consiste en el movimiento de los registros a travs de la lgica combinacio-
nal sin alteracin de la funcionalidad global del circuito. As, por ejemplo, si en el
circuito anterior:
TI = 4 ns
La herramienta desplazara los registros a travs de la lgica intentando que:
En la retemporalizacin 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-
plazara los registros segn el esquema de la figura:
intentando que:
al objeto de que:
La retemporalizacin puede utilizarse tambin como un mtodo alternativo a la

asignacin secundaria a la hora de minimizar el nmero de elementos de memoria.
As, por retemporalizacin del circuito de la Figura 4-18 a) se podra obtener la im-
plementacin b) que puede ser preferible en la mayora 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 reternporalizacin.
4.5. RECOMENDACIONES GENERALES
El cdigo VHDL desarrollado como descripcin de la arquitectura RT a sintetizar

va a tener, adicionalmente, otras aplicaciones, como verificacin funcional por si-
mulacin, documentacin y mantenimiento, etc. En parte o en todo, el cdigo debe
de ser reutilizable en proyectos futuros al objeto de minimizar el esfuerzo de diseo
necesario.
Dependiendo de la aplicacin, caben recomendaciones particulares que permi-
ten optimizar el cdigo a desarrollar. As, se pueden proponer recomendaciones
4. Sntesis 239
orientadas a minimizar el tiempo de simulacin, mejorar la legibilidad del cdigo

que favorezca el mantenimiento del mismo y su uso en la documentacin del pro-
yecto o que faciliten su reutilizacin posterior. Algunas de estas recomendaciones
pueden ser contradictorias, de tal forma que, dependiendo de la aplicacin ms im-
portante, habr que establecer una prioridad entre ellas. Respecto a recomendacio-
nes destinadas a optimizar el cdigo VHDL con vistas a la simulacin y la docu-
mentacin, las directivas incluidas en [S94] cubren perfectamente estos objetivos.
Respecto a la reutilizacin del cdigo, el Captulo 6 hace una extensa descripcin
de este aspecto de creciente importancia en el diseo de sistemas complejos.
En este captulo suponemos que la aplicacin ms importante es sntesis que,
por otro lado, va a constituir de hecho la situacin ms frecuente en la mayora de
los casos. En consecuencia, las recomendaciones que hagamos estarn dirigidas a
mejorar los resultados de la herramienta de sntesis 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 sntesis
Vamos a hacer a continuacin una breve descripcin de las recomendaciones de ca-

rcter general que hay que tener en cuenta a la hora de asegurar una calidad mnima
en el cdigo VHDL para sntesis que asegure resultados satisfactorios. Recomenda-
ciones ms detalladas pueden encontrarse en [S96] y [CP96].
4.5.1.1. Descripcin de "hardware"
Las herramientas comerciales actuales cubren las etapas de sntesis RT y lgica

comentadas en el apartado 3. En consecuencia, el diseo arquitectural corresponde
actualmente al diseador. As pues, la arquitectura del sistema compuesta por uni-
dades de control y de datos, mquinas 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 implementacin fi-
nal va a satisfacer los requerimientos de rea, velocidad, consumo, etc., de forma
ptima. nicamente cuando el diseo arquitectural se halla completado cabe gene-
rar el cdigo VHDL correspondiente. Abordar el diseo del sistema directamente
en VHDL no es recomendable.
Aunque VHDL tenga similitudes sintcticas con lenguajes de programacin
(particularmente ADA), se trata de un lenguaje de descripcin de hardware. La des-
cripcin VHDL refleja una arquitectura. Si sta no ha sido cuidadosamente disea-
da, los resultados de la sntesis no van a ser ptimos. Cdigo elegante desde un
punto de vista de programacin puede ser ineficiente en sntesis. En este sentido, la
utilizacin de cdigo simple y fuertemente ligado a la implementacin [V95] va a
asegurar la obtencin de resultados ptimos.
4.5.1.2. Limpieza del cdigo
El cdigo VHDL generado para sntesis debe de ser lo ms claro posible al objeto
de asegurar al mximo control sobre el resultado. En este sentido cabe hacer las si-
guientes recomendaciones:
Utilizar al mximo tipos estndar reconocidos e implementados eficiente-

mente por la herramienta de sntesis. Salvo en el caso de modelar buses, la
utilizacin de tipos enteros restringidos es recomendable.
Es preferible el uso de seales no resueltas std_ulogic frente a las resuel-
tas std_logic. En el caso de vectores es recomendable la utilizacin de rangos
decrecientes (N downto O).
Minimizar, y si es posible eliminar, el uso de caracteres metalgicos ('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 lgicas o de transicin (en el
caso de FSMs) incompletamente especificadas, en cuyo caso se debe de utili-
zar 'X,14.
El uso del carcter 'X' como indiferente est recomendado tambin para
seales 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 sntesis y declararse
como seales en la descripcin VHDL. En este mismo sentido, deben de evi-
tarse aquellas construcciones correspondientes a "latches" implcitos, salvo
que su utilizacin sea imprescindible en el diseo.
Sin embargo, el uso de variables es recomendable frente al de seales,
por razones de legibilidad y eficiencia en la simulacin. Al objeto de que la
variable no genere lgica secuencial, la variable debe de utilizarse en cual-
quier condicin de ejecucin del proceso en la cual se asigne.
Tanto por razones de legibilidad del cdigo como de eficiencia en sntesis,
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 Podra utilizarse tambin -'. Sin embargo, este carcter es ms incmodo a la hora de analizar
resultados de simulacin.
4. Sntesis 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 cdigo con una funcionalidad dada. En los subprogramas no se debe
de utilizar seales que no hayan sido pasadas como parmetros.
Por razones de legibilidad del cdigo, 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 simulacin y sntesis
Al objeto de facilitar la verificacin por simulacin tanto del cdigo RT como de la

implementacin lgica correspondiente, deben de limitarse al mnimo todas aque-
llas construcciones que provocan discrepancias innecesarias entre simulacin y sn-
tesis. En este sentido cabe realizar las siguientes recomendaciones:
Las seales y variables deben de tomar los valores iniciales en la descripcin
de tal forma que el resultado de simulacin no dependa de los valores por de-
fecto asignados por el simulador,
En un proceso con parte combinacional, todas las seales utilizadas en la
parte combinacional deben de pertenecer a la lista de sensibilidad del proce-
so.
Evitar la utilizacin de variables antes de su asignacin. Tal y como se co-
ment en el apartado 4.5, este tipo de situaciones provoca discrepancias in-
necesarias entre simulacin y sntesis.
4.5.1.4. Conocimiento de la herramienta
Al objeto de sacar el mximo partido de una determinada herramienta de sntesis,

es necesario conocer en detalle la metodologa de sntesis particular que esta he-
rramienta utiliza. Concretamente, los algoritmos de sntesis que implementa y su
eficacia. Como directivas generales se pueden considerar las comentadas en el
apartado 3.
4.6. EJERCICIOS
1. Dada la siguiente asignacin secuencial de seal:
z <= xl + x2 after 25 ns;
Es posible determinar el tipo de descripcin, funcional, RT o lgica de la que

se trata? Comentar la interpretacin temporal del cdigo en cada caso.
2. Un filtro FIR de k etapas se describe por la siguiente ecuacin:
k
2:
Y (t) :::: x(t - i)*c(i)
i=O
a) Proponer una descripcin VHDLfuncional.

b) Proponer una arquitectura RT con un nico multiplicador y la descripcin
VHDL algortmica correspondiente.
e) Situar en el cubo de diseo de la Figura 4-2 las descripciones de entrada y
salida y determinar los pasos de diseo recorridos.
d) Repetir el proceso considerando la siguiente ecuacin para el filtro:
o
y(t) ::::2: x(t - i)*c(i)
i=k
e) Cul 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 implementacin con mnimo camino crtico (sin restricciones de
uso de operadores y registros).
3. Proponer una descripcin VHDL en flujo de datos para la descripcin algort-

mica desarrollada en el problema 2. Situar en el cubo de diseo de la Figu-
ra 4-2 las descripciones de entrada y salida y determinar los pasos de diseo
recorridos.
4. Dada la siguiente descripcin VHDL:

procesa
begin
if xl = '1' then
z <= tI};
wait on xl :
elsif x2 = '1' then
z <= 11';
4. Sntesis 243
wait on x2;
el se
z <= 10';
wait until xl ar x2;
end if;
end process;
a) Proponer una implementacin mnima.

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

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

.
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 implementacin mnima.

b) Es una descripcin sintetizable?
e) Describir la secuencia de entradas que muestra cmo no se corresponde la
simulacin VHDL de la descripcin anterior con el comportamiento espera-
do de la implementacin del apartado a).
6. Proponer declaraciones de seal VHDL sintetizables para:

a) Las seales 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 multiplicacin de los datos de e) y los coeficientes de d)
sin prdida de precisin.
f) Los 9 estados SO... S8 de una mquina de estados finitos.
7. Encontrar implementaciones mnimas 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 nmero de entradas a '1'.
a) Proponer una descripcin en flujo de datos.
b) Proponer una descripcin algortmica.
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 descripcin en flujo de datos.
b) Proponer una descripcin algortmica.
10. Repetir el problema anterior pero haciendo que el circuito muestre la letra de
error 'E' cuando se reciba una palabra fuera del cdigo.
11. Se desea disear una Unidad Aritmtico-Lgica sobre datos de entrada A y B

del tipo signed (15 downto O). La funcin a realizar sobre la salida F del ti-
4. Sntesis 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 descripcin VHDL sintetizable.
12. Obtener una implementacin mnima para el siguiente cdigo:

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 sntesis un contador bidireccional que circule por el
siguiente cdigo "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 explcitos (el, e2
y e3) y en estilo implcito para la mquina de estados finitos siguiente:
Estado prximo/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 mquina 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 descripcin de la
FSMD correspondiente sabiendo que las rnicrooperaciones asociadas a cada
una de las seales 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. BIBLIOGRAFA
[C96] N. H. COHEN:ADA as a second language, McGraw-Hill, 1996.

[CP96] Comit PRENDA: PRENDA: Metodologa para el diseo de AS/Cs, Universidad
Politcnica 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. Sntesis 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. SNCHEZ:Synthesis applications ofVHDL. en 1. Mermet (ed.): "Fun-
damentals and standards in hardware description languages", Kluwer, 1993.
Captulo 5
MODELADO
CON VHDL
Eduard Lecha, Fernando Rincn, Manel Mor, Joan Vidal y Llus Ters
IMB-CNM (CSIC)
Un nio de cinco aos entendera esto.

Traedme un nio de cinco aos!
Groucho Marx
La principal funcin de un lenguaje de descripcin de hardware es

permitir la realizacin de un modelo que facilite tanto la especificacin
como el diseo y la verificacin de sistemas electrnicos. 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
electrnico desde su concepcin hasta su descripcin detallada, ade-
cuada para ser aplicada como entrada a las herramientas de sntesis
automtica comercializadas actualmente.
Para ello, a lo largo de este captulo 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
excepcin del procesador, se implementarn utilizando circuitos inte-
grados ya existentes que debern ser modelados con VHDL para la si-
mulacin del sistema. De esta forma se desarrollarn modelos tanto
para el desarrollo de un componente desde su especificacin hasta su
implementacin como para la simulacin de un componente ya imple-
mentado cuyas caractersticas son completamente conocidas.
249
5. 1. INTRODUCCiN
En este captulo se presenta, de una manera prctica, el uso del lenguaje VHDL pa-
ra el modelado de sistemas electrnicos. Para ello todo el captulo se ejemplifica so-
bre un sistema basado en un procesador sencillo ("La mquina rudimentaria"
[SPC97]) y arropado con otros componentes bsicos (memoria y rbitro de bus) pa-
ra formar un sistema microprocesador completo.
El procesador es el hilo conductor del captulo a lo largo del cual se abordan
los problemas del modelado con VHDL en los distintos niveles de abstraccin. En
una primera etapa ser fundamental poder experimentar con distintos conjuntos de
instrucciones para el procesador en un modelo sencillo que sea fcil de manejar. Pa-
ra esta etapa se desarrollar un modelo funcional. Posteriormente ser necesario es-
pecificar con ms 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 ms fiel posible de los circuitos ya existentes utilizados
para el resto del sistema.
Antes de abordar cada tarea en el diseo del sistema ejemplo se plantean los
problemas del modelado en el nivel de abstraccin necesario para la tarea junto con
una descripcin general de las tcnicas que se podran aplicar y los posibles usos
del VHDL en la solucin de la tarea planteada. Posteriormente se aplican al sistema
ejemplo las estrategias y tcnicas ms adecuadas para nuestro caso.
En el siguiente apartado se da una visin global de los mecanismos disponibles
en VHDL para modelar un sistema a distintos niveles de abstraccin. Estos meca-
nismos se tendrn en cuenta en cada descripcin del procesador para cumplir con el
objetivo de los distintos modelos.
A continuacin se describe el modelado a nivel algortmico. Este tipo de mode-
los suelen utilizarse en las primeras etapas del diseo como ayuda a la escritura y
validacin de las especificaciones del componente a implementar. En muchas oca-
siones es posible escribir un modelo algortmico de un componente sin especificar
ni siquiera su interfaz con otros componentes.
La evolucin del procesador consiste en la definicin de su interfaz con los de-
ms componentes del sistema y el refinamiento de su arquitectura interna. Para si-
mular esta segunda descripcin 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 captulo se mostrarn distintas opciones en los bancos de
pruebas del procesador a medida que se detalle su entorno.
El particionado del procesador contina despus de la realizacin del primer
banco de pruebas. Se realiza un modelo detallado del procesador, distinguindose
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 tcnicas de modelado para la simulacin, aun-
que sin perder de vista las necesidades de un modelo para sntesis. As, en las des-
cripciones a nivel de transferencia de registros, se tienen en cuenta las capacidades
de las herramientas de sntesis actuales, apuntndose en cada caso las estructuras no
sintetizables y las modificaciones necesarias de los modelos para sntesis.
5. Modelado con VHDL 251
Finalmente, debido al gran tamao de los listados VHDL que aparecen en este
captulo, se ha optado por simplificar y esquematizar al mximo el cdigo insertado
en el interior del texto, e incluir las descripciones completas en la direccin 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 diseo de un sistema electrnico se dispone nicamente

de una vaga idea de qu es lo que se pretende que el sistema realice y mucho ms
desconocido es cmo el sistema realizar su funcin. Sin embargo, ya en esta pri-
mera etapa puede ser til utilizar un lenguaje como el VHDL. En este contexto, las
descripciones VHDL permitirn simular los primeros esbozos de la arquitectura ex-
presando las caractersticas que se considere conveniente resaltar y obviando los
detalles propios de etapas ms avanzadas.
Las primeras simulaciones pueden utilizarse para realizar una primera evalua-
cin del rendimiento de los distintos algoritmos o funciones del sistema. Al mismo
tiempo, dichas evaluaciones resultarn en decisiones sobre la implementacin que
aadirn informacin a las descripciones VHDL, de modo que, a medida que stas
se refinen, se avanzar hacia unas especificaciones del sistema cada vez ms 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
descripcin de la estructura hardware. Esto sucede principalmente cuando se trata
de diseos de hardware de propsito generala dispositivos programables, como
procesadores, microcontroladores, coprocesadores, dispositivos de lgica 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 expresin del
paralelismo mediante distintos procesos y los distintos estilos de descripcin 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 implementacin de dichos sistemas deberan modelar
los distintos niveles lgicos 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 estndar del IEEE STD_LOGIC_1164 seran adecuados. Uti-
lizar estos tipos de datos nos permite detallar aspectos como la inicializacin de se-
ales, conflictos en un bus compartido o la determinacin de valores redundantes
en algunas funciones.
Sin embargo, si quisiramos describir el sistema sin preocuparnos por este tipo
de detalles podramos simplificar considerando que los valores de los nodos de un
sistema digital slo pueden tomar dos valores: 'O' o '1'. En este caso podramos uti-
lizar los tipos bi t Y bi t_ vector predefinidos en el lenguaje. Por otra parte, la utili-
zacin de estos tipos implica detallar la precisin de los datos numricos utilizados
en los algoritmos. Por ejemplo, si trabajamos con datos reales, deberamos determi-
nar un formato de punto fijo o punto flotante y asignar un nmero 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-
cacin de las variables. Por ejemplo, cuando describimos una mquina de estados
finita nos podra interesar no determinar una codificacin de estados, ni siquiera el
nmero de bits que ser necesario para almacenar el estado, ya que ms adelante
podramos decidir cambiar el estilo de codificacin y, por ejemplo, en lugar de utili-
zar una codificacin basada en cdigos de Gray utilizar una codificacin con un bit
por cada estado (codificacin 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. Adems, existen paquetes estndar del IEEE donde
se definen operaciones matemticas sobre el tipo REAL y declaraciones de tipos re-
presentando nmeros 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 comunicacin entre componentes se debern usar funciones de conver-
sin de tipo, es decir, funciones que toman como parmetro un valor de un determi-
nado tipo (por ejemplo, integer) y devuelven como resultado de su ejecucin el
equivalente en el otro tipo de datos (por ejemplo, bit_vector).
5.2.2. Expresin del tiempo y paralelismo

Una de las caractersticas que debe poseer un lenguaje de descripcin de hardware
es la de permitir expresar que determinados eventos suceden a lo largo del tiempo.
De hecho, el tiempo de simulacin es un elemento implcito en dichos lenguajes ya
que a diferencia de los programas escritos en un lenguaje de programacin, las des-
cripciones escritas en un HDL no se ejecutan sino que se simulan. Es decir, el resul-
tado de su ejecucin se expresa en funcin del tiempo de simulacin.
De manera parecida a lo que ocurre con los tipos de datos, la descripcin del
comportamiento de un sistema a lo largo del tiempo puede variar en grado de deta-
lle en funcin del nivel de abstraccin en el que se considere el sistema. Si se pre-
tende modelar nicamente la funcin que realiza un algoritmo, entonces la descrip-
cin se parecer mucho a un programa y no ser necesario expresar los cambios de
las seales a lo largo del tiempo sino que se podr utilizar un nico proceso ejecuta-
do secuencialmente sin consumir tiempo de simulacin. En este caso no tendr sen-
tido la utilizacin de seales (signals) sino que se emplearn 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 realizacin de funcio-
nes. Para expresar el paralelismo se modelar la arquitectura utilizando distintos

procesos que se comunicarn entre s mediante seales, puesto que stas permiten
expresar los cambios en relacin con el tiempo de simulacin.
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, ms adelante interesar
aadir detalle a la descripcin y aproximarla ms a la implementacin. Para ello, el
siguiente paso es la introduccin de un reloj que determine ciclos en el funciona-
miento del sistema. Mediante la introduccin del reloj en las descripciones expresa-
mos el sistema como una serie de clculos y asignaciones de seales 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 vnculo entre operaciones y ciclos de reloj sino los retar-
dos de las operaciones dentro de un ciclo de reloj se utilizarn sentencias de asigna-
cin con la clusula after.
5.2.3. Estilos de descripcin
El diseo de componentes complejos se aborda normalmente por medio de la tcni-

ca de dividir el componente en subcomponentes ms sencillos interconectados entre
s. De esta forma, considerando por separado el diseo de cada uno de los compo-
nentes se reduce la complejidad del diseo inicial.
Del mismo modo, a medida que se aade detalle a la descripcin de un sistema
electrnico 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 ningn tipo de estructura en su interior, aunque se puede dotar al algoritmo
descrito de una cierta estructura lgica, distinguiendo en l funciones y procedi-
mientos. Posteriormente, a medida que se avanza en la toma de decisiones, se har
explcita la existencia de subcomponentes, para los cuales se determinar una fun-
cin a realizar dentro del sistema, y una interfaz para su relacin 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 descripcin de hardware debe permitir expresar el particionado
de un componente en subcomponentes, incorporando as los conceptos de estructu-
ra y jerarqua. Como se explica en el Captulo 2, en VHDL podemos realizar des-
cripciones con diferentes estilos (algortmico, flujo de datos y estructural), cada uno
de los cuales permiten expresar el particionado con distinto grado de detalle. Me-
diante un estilo de descripcin algortmico tan slo 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 descripcin
estructural que nos obligar a formalizar la interfaz de un componente mediante la
declaracin de entidad (entity) y podremos expresar la estructura mediante la decla-
racin y referencia de componentes (component) dentro de una arquitectura.
5.3. MODELADO FUNCIONAL
El modelado funcional de un sistema consiste en expresar la funcin realizada ob-

viando los detalles relacionados con la estructura y la temporizacin. Este tipo de
modelos son corrientes en las primeras fases del diseo y se utilizan principalmente
para concretar la especificacin de la funcionalidad del sistema, de forma que no
haya equvocos entre los especificadores y las personas que han de llevar a cabo el
diseo.
En algunos casos, la funcionalidad a implementar se expresar fcilmente me-
diante un algoritmo. En otras ocasiones, las especificaciones debern incluir con-
ceptos hardware de la arquitectura del sistema tal como la vera 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) ms fciles de consultar y validar. .
El proceso es la unidad de construccin bsica para describir la funcionalidad.
Normalmente en las descripciones puramente funcionales, sobre todo cuando la
funcionalidad corresponde a la ejecucin 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 seran sistemas
productor-consumidor donde existe un recurso compartido en el que se almacena in-
formacin de forma que los componentes productores acceden al recurso para escribir
en l, mientras que los componentes consumidores acceden para leer la informacin.
La forma usual de comunicar dos procesos es mediante seales: un proceso ac-
ta como fuente de la cola de eventos de la seal y le asigna valores a lo largo del
tiempo mediante la sentencia de asignacin a seal y otros procesos se muestran
sensibles a los cambios en el valor de la seal mediante la sentencia wait.
Cuando dos o ms procesos han de escribir en un recurso compartido, podre-
mos escoger entre tres opciones: representar el recurso compartido mediante una
variable global, utilizar una seal resuelta como recurso compartido donde la fun-
cin de resolucin determina el valor final de la seal o encapsular la informacin
compartida dentro de un proceso cuyo cdigo 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 ejecucin 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 simulacin puede variar de un simulador a otro (ver Captu-
lo 3). Como las variables se actualizan inmediatamente al ser asignadas dentro de

un proceso, es fcil realizar descripciones no deterministas cuando se utilizan varia-
bles globales.
Como ejemplo de comparticin 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 adems el trabajo con el
dispositivo requiere consumir un tiempo de simulacin.
Para evitar que cuando un proceso se encuentre trabajando con el dispositivo
pueda intentar abrir el dispositivo otro proceso, implementaremos un semforo uti-
lizando una variable compartida.
En el Listado 5-1 vemos cmo utilizaran el semforo 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 semforo
se encuentra en el estado LIBRE y debe dejarlo en estado OCUPAro para los dems
procesos. Una vez ha terminado el trabajo con el dispositivo cada proceso debe de-
volver el estado LIBRE al semforo.
Debe notarse que esta descripcin sera no determinista, puesto que si ambos
procesos ejecutaran la zona de cdigo relativa al semforo (sentencia loop) en el
mismo ciclo de simulacin, es decir, si los dos procesos intentasen modificar el va-
lor del semforo en el mismo ciclo de simulacin, entonces podemos asegurar que
tan solo uno de los procesos conseguira el acceso al dispositivo en ese ciclo pero
no podemos asegurar cul de ellos sera, 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 opcin para conseguir que varios procesos escriban sobre un mis-
mo recurso consiste en utilizar una seal de tipo resuelto. En este caso la simula-
cin ser determinista siempre que la funcin de resolucin no dependa del orden
en que le pasen los valores en el vector de valores asignados a la seal. Esta solu-
cin no se emplea normalmente en descripciones de nivel funcional sino que es
muy til en descripciones ms 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 ms detalle el procesador y su interaccin con el bus de me-
moria.
En el Listado 5.2 vemos el mismo ejemplo de comparticin de un dispositivo
del listado anterior pero con el semforo implementado mediante una seal de tipo
resuelto en la que escriben dos procesos. La seal 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 seal Semaforo su
valor de peticin 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 comparticin de recursos con funciones de resolucin.
seal Semaforo para evitar que sta cambie de valor ante peticiones del otro proce-
so. La funcin de resolucin Resuel veAcceso se encarga de mantener el valor ocu-
pado de la seal si alguno de los procesos est escribiendo su valor de ocupado. De-
be notarse que esta descripcin tampoco es determinista, ya que el orden en que los
procesos obtengan el dispositivo en el caso de solicitarlo simultneamente depende-
r del orden en que le lleguen los valores a la funcin de resolucin, 10 cual es de-
pendiente del simulador.
Finalmente, en la tercera opcin 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 seales para el acceso de cada
proceso que desee leer o escribir informacin. En el proceso que encapsula el recur-
so se incluir cdigo para arbitrar la escritura simultnea de informacin.
En el Listado 5-3 se muestra la implementacin del semforo mediante esta
tcnica. El proceso Semaforo contiene la variable Acceso donde se guarda el esta-
do del semforo. Los procesos PI y P2 acceden a dicha variable mediante las sea-
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~tlhnP2)

type tAcceso i8 (LIBRE, PI, P2);
variable Acceso :;tcceiOY' -; 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
OcupadEl_ <= TRUE;
elae _
OcupadoPI <= FALSE;
end if;
if Acs~;'~P2 then
ocupadP2 <= TRUE;
elee
OcupadoP2 <=rALSE~
end if;
end process;
LISTADO 5-3. Ejemplo de informacin compartida encapsulada en un proceso.

A diferencia de los Listados 5-1 y 5-2, la solucin 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 seal de peticin de forma simultnea,
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 prxi-
mos a los conceptos que se utilizan en la especificacin. Ser en este tipo de descrip-
ciones donde se utilizarn con mayor frecuencia los tipos definidos por el usuario.
5.3.1. La mquina rudimentaria
Para ejemplificar el estilo de descripcin VHDL que se puede realizar en las prime-
ras etapas de la concepcin de un sistema electrnico, en este apartado escribiremos
el modelo funcional del procesador que constituir el ncleo del ejemplo utilizado
en el resto del captulo. En primer lugar se especificar la arquitectura del procesa-
dor a nivel de conjunto de instrucciones y posteriormente se comentar la descrip-
cin VHDL que sirve para experimentar y trabajar con dichas especificaciones.
5.3.1.1. Arquitectura del procesador a nivel de lenguaje mquina
El procesador que utilizaremos est basado en la "Mquina 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 ejecucin de cada instruccin sta se carga de la direccin de me-
moria contenida en el contador de programas (CP) al registro de instruccin (RI).
Seguidamente, la instruccin cargada se descodifica y se ejecuta, realizando las co-
rrespondientes operaciones en la unidad artimtico-lgica (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 instruccin (registro destino
[Rd] o registro fuente [Rf] segn la instruccin) y la direccin de memoria se
calcula sumando un registro del banco de registros especificado en un campo
de la instruccin (registro ndice [Rx]) con la direccin base especificada en
la instruccin (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 instruccin
Banco
de
Contador de programa
Registros
Memoria
-- de
programas
y
datos
FIGURA 5-1. Arquitectura del procesador.
Instrucciones de salto. El CP se incrementa despus de la ejecucin de cada

instruccin, excepto para las instrucciones de salto. En stas se puede cam-
biar el secuenciamiento normal de las instrucciones cargando en el CP una
direccin contenida en la instruccin. La instruccin de salto incondicional
siempre carga su direccin en el CP mientras que las dems instrucciones de
salto comprueban que se cumpla alguna condicin sobre los indicadores N y
C antes de cargar su direccin. En caso de que la condicin no se cumpla, el
CP se incrementa, no modificndose as la secuencia normal del programa.
Instrucciones aritmetico-Igicas. Realizan operaciones aritmticas o lgi-

cas, tomando como datos de entrada valores almacenados en el banco de re-
gistros o en la propia instruccin y almacenando el resultado en el banco de
registros. Los indicadores N y C se actualizan de acuerdo con el resultado de
la operacin. Los registros que contienen los datos para la operacin y el re-
gistro donde se almacenar el resultado se especifican en campos de la ins-
truccin (Rfl y Rf2 para los registros fuente 1 y 2 Y Rd para el registro desti-
no de la operacin). Existen dos instrucciones aritmticas (ADDI y SUBI)
que operan el contenido de un registro con un valor inmediato almacenado
en un campo de la propia instruccin. Todas las instrucciones aritmticas ac-
tualizan los indicadores N y C de acuerdo con el resultado de la operacin,
es decir, C se carga a verdadero si el resultado de la operacin es cero y a fal-
so en caso contrario y N se carga a verdadero si el resultado de la operacin
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 mquina rudimentaria
Instrucciones de acceso a memoria
LOAD Carga el contenido de la direccin 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 segn el valor cargado.
STORE Almacena el contenido del registro del banco de registros indicado por el
(Rf, Rx, DireccionBase) campo Rf en la posicin 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 ms pequeo. Si N es verdadero carga el' campo Direccin en el CP.
BLE(Direccion) Salta si ms pequeo 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 ms grande. Si N Y C son ambos falso carga el campo Direccion

en el CP.
Instrucciones aritmtico-lgicas
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 instruccin 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 aritmtico, es decir, se conserva el signo.
ANDL(Rd, Rfl , Rf2) Se realiza una operacin Y-lgica 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 nmero de bits de los registros o el formato de instruccin no
son considerados en este apartado.
5.3.1.2. Modelo funcional de la mquina rudimentaria
El objetivo de una descripcin funcional de la arquitectura del procesador presenta-

da en el apartado anterior sera disponer de un primer modelo capaz de ejecutar un
programa. Este modelo podra utilizarlo tanto el diseador, cuyo objetivo es obtener
una implementacin del procesador, como el escritor de compiladores, para poder
ejecutar el cdigo generado, y as poder evaluar distintas modificaciones en el con-
junto de instrucciones. Aunque el modelo que vamos a realizar slo permitir eje-
cutar pequeos programas y su funcin es ms bien servir de ejemplo y de especifi-
cacin del conjunto de instrucciones, que no ser una herramienta de evaluacin de
compiladores, al final del captulo se proponen ejercicios que aumentaran la utili-
dad de esta descripcin.
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, adems
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 numricos que manejar el procesador sern de tipo entero, de for-
ma que no especificaremos su formato en nmero 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 ningn formato sino que una ins-
truccin se considerar compuesta por un conjunto de cuatro campos: un primer
campo donde se indicar el cdigo de operacin y tres campos de tipo natural que
correspondern a los parmetros de cada instruccin segn la Tabla 5.1. En las ins-
trucciones que tengan menos de tres parmetros se utilizarn 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 mnemnico 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 abstraccin, 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 representara 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 ms independiente posible de
las caractersticas cuantitativas del procesador, como, por ejemplo, el nmero de bits
de los registros, el tamao de la memoria y el nmero de registros en el banco de re-

gistros. Sin embargo, para poder especificar el tamao de los vectores es necesario
definir algunas de estas cantidades. Por ello, en la declaracin de paquete declarare-
mos las constantes cNumInst, cNumDatos y cNumRegistros que correspondern al
nmero de direcciones de la memoria de instrucciones, el nmero de posiciones en
la memoria de datos y el nmero de registros del banco de registros.
Finalmente deberemos declarar las operaciones para los tipos de datos utiliza-
dos que no estn predefinidas en el lenguaje. En nuestro caso necesitaremos realizar
una operacin y lgica bit a bit entre dos datos para ejecutar la instruccin ANO
del procesador. Puesto que los datos son de tipo integer, necesitaremos una fun-
cin que realice la operacin Y lgica bit a bit entre dos enteros.
A continuacin se muestra el cdigo VHOL correspondiente a la declaracin
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. Declaracin del paquete PaqueteMRFuncional.
Como podemos observar en la declaracin de paquete, faltan por definir tanto

el valor de las constantes como el cuerpo de la funcin "ANO". Podramos haber
asignado directamente un valor a las constantes pero por motivos prcticos es con-
veniente hacerlo en la definicin del cuerpo del paquete. En el caso de que las cons-
tantes estn definidas en la declaracin de paquete, si quisiramos cambiar su valor
y volver a simular la descripcin del procesador sera necesario analizar de nuevo

todas las descripciones que utilizasen el paquete, mientras que si las constantes slo
se definen en el cuerpo del paquete nicamente es necesario reanalizar ste.
Para realizar la funcin Y lgica bit a bit de dos enteros deberemos conside-
rar su representacin binaria tanto para nmeros positivos como negativos. En
nuestro caso consideraremos que el nmero de bits de un dato no superar una
cierta cantidad (cMaxNumBi ts) que definiremos como constante y la representa-
cin de los nmeros negativos ser en complemento a dos. Adems, aprovechare-
mos que existen paquetes estndar (STD_LOGIC_1164) que definen tipos para
lgica multivaluada y vectores de estos tipos (std_logic_vector y signed),
adems de otros paquetes que definen funciones de conversin de enteros a su re-
presentacin binaria usando el tipo SIGNED, para realizar la funcin "AND" sobre
los datos convertidos a tipo signed. La funcin "AND" para estos datos s est de-
finida en el paquete STD_LOGIC_ARITH.
El cuerpo del paquete sera 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 ningn

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

en un lenguaje de programacin como e
o Pascal. Unicamente incluir un proceso,
ya que no pretendemos describir la sincronizacin entre las distintas tareas, es decir,
cundo 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 cdigo segn las tareas a reali-
zar. La ejecucin de instrucciones puede dividirse en dos grandes tareas: buscar y
cargar de la memoria la instruccin que se va a ejecutar, y la propia ejecucin de la
instruccin 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 cdigo de los procedimientos.
La arquitectura que llamaremos Funcional se muestra a continuacin:
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
-- Inicializacin del programa
InicializaMemoria;
CP ,;: O;
Registro?(O) ::;0;
loop -', ..
LeerIhsfru(:in;
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 indicacin mediante la sentencia use de que a lo

largo de la descripcin utilizaremos los objetos definidos anteriormente en el pa-
quete PaqueteMRFuncional. A continuacin se define el cuerpo de la arquitectura,
donde nicamente se encuentra el proceso llamado Procesador. Este proceso se
compone de la declaracin de variables y procedimientos y el cuerpo del proceso.
Los recursos de almacenamiento del procesador se representarn 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-
cin que se almacena en ella. Aunque el tipo tInstruccion se utilice para todas
las instrucciones, los tres campos numricos del tipo tienen distinto significado en
cada instruccin. Por ello, sera cmodo 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 declaracin 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 inicializacin de las variables y
la ejecucin de las instrucciones. En la inicializacin de variables se realiza una lla-
mada al procedimiento InicializaMemoria el cual inicializa las variables Pro-
grama y MemDatos introduciendo un pequeo programa que suma el contenido de
las direcciones Oy 1 de la memoria de datos y almacena el resultado en la direccin
2. Para ello utiliza los registros 2 y 3 para los operandos y el 4 para el resultado. El
resto de la inicializacin de variables consiste en indicar que el programa empieza
en la direccin 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 inicializacin, el proceso entra en un bucle que va cargando

y ejecutando instrucciones, detenindose un tiempo arbitrario de 10 ns despus de
la ejecucin de cada instruccin. Esta espera entre instrucciones evita que todo el
programa se ejecute en el tiempo de simulacin O y permite tener una representa-
cin grfica de la evolucin 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 descripcin 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 diseador el final de la simulacin. Sin
embargo, mejorando la interfaz con el usuario de la descripcin, por ejemplo, alma-
cenando los programas y datos en ficheros, podra servir como herramienta de eva-
luacin para el desarrollo de compiladores.
Nos queda por escribir el cdigo correspondiente a los dos procedimientos.
LeerInstruccion copia el contenido de la posicin de la memoria de datos apun-
tada por el contador de programas al registro de instrucciones y actualiza el conta-
dor de programas incrementndolo 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 instruccin dependen en gran medida
del tipo de instruccin que se haya cargado en el registro de instrucciones. Por
ello, aunque la ejecucin de todas las instrucciones la realiza el procedimiento
EjecutarInstruccion, utilizamos la sentencia case para seleccionar las sentencias
a ejecutar en funcin de la instruccin de que se trate. Para cada instruccin existe
una clusula when en la que se actualizan los recursos de almacenamiento del pro-
cesador de acuerdo con su ejecucin.
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 =>
Registos (Rq) ; ;,=: Regis~ro> (R,t:q+ .Reg:i.~t:::os(Rf2) ;
';', ~" ",.. _'o .. " ...
C : = Registros ttdl = 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 cmo se poda estructurar un proceso defi-

niendo procedimientos y funciones. Esta es una de las distintas formas que exis-
ten en VHDL para estructurar el cdigo. Adems de la posibilidad de organizar
las sentencias en procedimientos, existen otros dos modos de particionado de las
descripciones: la distribucin de cdigo en diferentes procesos dentro de una ar-
quitectura y la opcin de expresar jerarqua particionando la descripcin en com-
ponentes.
La divisin del cdigo en procesos nos ayuda a modelar la concurrencia y sin-
cronizacin entre tareas,. mientras que el particionado en componentes, adems de
permitimos definir la arquitectura de cada componente, cuyos procesos se ejecuta-
rn en paralelo a los de los dems componentes, nos obliga a definir una interfaz
(entidad) para cada componente de forma que su relacin con los dems componen-
tes de un sistema quede perfectamente definida.
En la eleccin de los tipos de datos de los puertos de la entidad deben conside-
rarse dos aspectos: el nivel de abstraccin de la descripcin y la compatibilidad con
otros componentes del sistema. En cuanto al nivel de abstraccin, si todos los com-
ponentes del sistema se describen a nivel funcional y mediante la descripcin es-
tructural del sistema nicamente se desea realizar un particionado de la funcionali-
dad, entonces ser una buena opcin 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 descripcin estructural no comparten los
mismos tipos de datos en los puertos, ser necesario utilizar funciones de conver-
sin para convertir los datos de un tipo a otro.
5.4.1. La mquina rudimentaria: interfaz

y primer particionado
En este apartado vamos a definir con ms detalle el procesador, realizando una des-
cripcin que se pueda utilizar en la simulacin de la descripcin 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 descripcin del sistema de la descripcin del procesador.
En la interfaz del procesador necesitaremos las seales de inicializacin (rni-
cializa) y reloj (Reloj) habituales en los sistemas digitales sncronos, adems de
las seales 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 seal de peticin de bus
(PeticionBus). En el sistema habr un rbitro de bus que notificar al procesador
mediante una seal (BusLibre) cuando puede realizar un acceso a memoria. Final-
mente el procesador necesitar indicar la direccin de memoria a la que desea acce-
der a travs de un bus de direcciones (Direccion), sealar si el acceso a memoria
es de lectura o escritura mediante una seal de control (Escribe), indicar a la me-
moria que los datos, direcciones y seales de control son vlidos mediante una se-
al de habilitacin (Habili taMem) y leer o escribir datos a travs de un bus de datos
bidireccional (Datos).
Para los tipos de los puertos escogeremos los tipos multivaluados estndar 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 definicin 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 mquina rudimentaria.

272 VHDL. Lenguaje estndar de Dlseo Electrnico
Ahora debemos escribir una arquitectura para la entidad definida, de forma que
se reconozcan los estmulos que otros componentes del sistema enviarn al procesa-
dor a travs 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 seales. Por ejemplo, el procesador no deber realizar un
acceso al bus si la entrada BusLibre no est activa, sino que deber realizar antes
una peticin 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 restriccin respecto al or-
den y temporizacin con que deben activarse las seales 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 seal Escribe estn es-
tables un cierto tiempo antes y despus de la activacin y desactivacin de la seal
HabilitaMem. Esto se conseguir aadiendo la lgica 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 ms cercana al hardware que la descripcin meramente
funcional. Ello nos obliga a utilizar tipos de datos capaces de representar los valores
lgicos 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: instruccin
de lectura de datos de memoria, instruccin de escritura de datos a memoria, ins-
trucciones de salto e instrucciones aritmtico-lgicas. Estas ltimas tendrn un for-
mato distinto para la suma y la resta con direccionamiento inmediato. Las instruc-
ciones de lectura, escritura, salto y aritmtico-lgicas se distinguen entre s por el
Reloj
PeticonBus
BusLibre
HablitaMen
.'
.,
.,
. .,.
,
------i------1- -----: ~
"
Escribe -----:--- -~--

Direccion IJIJ///J'lll/bJ/////W!/I/
Datos 1!Z171711l1lb//)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(CJXIIf/l/ip/lll
FIGURA 5-3. Ciclo de escritura.
valor de los dos bits ms significativos de la instruccin, y dentro de las instruccio-

nes aritmtico-lgicas se distingue el modo de direccionamiento (inmediato o regis-
tro-registro) segn el campo OP de la instruccin. El formato para cada tipo de ins-
truccin se muestra en la Figura 5-4.
---
I I
2
I
00
3
Rd
3
Rx I
8
Direccin Base Formato de la instruccin LOAD
I---
2 3 3 8
I I
01 Rl Rx I Direccin Base Formato de la instruccin STORE
I---
2 3 3 8
Formato de las instrucciones
I I
10 Cond 000 I Direccin de salto
I
--_ ......
2
11 I
3
Rd I
3
Rl1 I Nmero
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 aritmticas y lgicas
FIGURA 5-4. Formato de las instrucciones.

TABLA 5-2. Cdigos de operacin
OP Instruccin
100 Suma (ADD)
101 Resta (SUB)
110 Desplazamiento aritmtico a la derecha (ASR)
111 y lgica (AND)
000 Suma con inmediato (ADDI)
001 Resta con inmediato (SUBI)
Nos queda por determinar la codificacin de los campos OP (para las instruc-
ciones aritmtico-lgicas) y Cond (para las instrucciones de salio). Aunque la codi-
ficacin de dichos campos puede facilitar ciertas implementaciones del procesador
y, por consiguiente, podra ser til determinar cul es la mejor codificacin una vez
se haya planteado el modelo detallado del procesador, por el momento utilizaremos
la codificacin especificada en [SPC97]. Las siguientes tablas muestran la codifica-
cin de estos campos.
La primera particin 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
clculo del procesador, mientras que la unidad de control indicar cmo se interco-
nectan y qu operaciones realizan dichos recursos en cada ciclo de reloj.
En la unidad de proceso encontraremos: el registro de instruccin (RI), el con-
tador de programas (CP), el banco de registros, un registro auxiliar (A), un registro
donde se guardar la direccin en los accesos a memoria (Registro de Direccin de
Memoria, RDM) y los registros para los indicadores N y C (N y C).
TABLA 5-3. Cdigos de condicin
Cond Instruccin
000 Salto incondicional (BR)
001 Saltar si igual (BEQ)
010 Saltar si ms pequeo (BL)
011 Saltar si ms pequeo o igual (BLE)
101 Saltar si no igual (BNE)
110 Saltar si ms grande o igual (BGE)
111 Saltar si ms grande (BG)
Para controlar las operaciones en la unidad de proceso necesitamos definir unas

seales de control cuyo valor se determinar en la unidad de control. Estas seales
son:
Habili taDireccion. Cuando est inactiva, el procesador no fuerza ningn

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 ningn 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 instruccin se asigna al bus de
datos.
FuenteDireccion. Indica si la direccin a memoria viene indicada por el re-
gistro RDM o por el CP.
SelRegLectura. Indica qu campo del registro de instruccin contiene el
nmero del registro del banco de registros que se va a leer.
EscribeRegistro. Cuando est activa, el resultado de la operacin realiza-
da en la VAL o el bus de datos, dependiendo de la seal Opera (descrita
abajo), se escribe en el registro indicado por el campo Rd del registro de ins-
truccin.
CargaRDM.Cuando est activa, se carga el registro RDM con el resultado de
calcular la direccin indicada en las instrucciones LOAD y STORE.
CargaRI. Cuando est activa, se carga el registro de instruccin 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 instruccin que se va

a ejecutar y el valor de los indicadores N y C para poder asignar valores a las sea-
les de control. As, la unidad de control ha de poder acceder a los dos bits ms 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 seal
CondicionSal too La Figura 5-5 muestra de forma esquemtica la particin del pro-
cesador y las funciones de las seales de control en la unidad de proceso.
HabilitaDatos
EscribeRegislro
Banco
Opera de
RreLg_iSttros_~~ Opera
- ~~
Unidad selR~
de Datos
control
IncCP
HabilnaDireccin
n~
T~
Direccin CondicinSalto
FIGURA 5-5. Esquema de la primera particin del procesador.
La particin 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 existirn los procesos UControl y
UProceso. Dentro de los procesos el cdigo ser parecido al cdigo para la descrip-
cin funcional del procesador en el sentido en que no se mostrarn ms detalles de
la estructura de cada unidad.
En cada uno de los procesos se representarn los recursos de almacenamiento
mediante variables y se utilizarn seales para la informacin que se transmita de
un proceso a otro, como las seales de control y la informacin sobre los indicado-
res y el tipo de instruccin 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 seales de control y aumentar la legibilidad del cdigo. A continuacin se
declaran las seales que servirn para comunicar los dos procesos (UControl y
UProceso) y se resuelve la salida hacia el exterior del bus de direccin interno
(Direccion_I) mediante una sentencia concurrente. Para controlar cundo el
procesador fuerza valores en el bus de direcciones y cundo se deja ste en alta im-
pedancia, la unidad de control utilizar la seal Habili taDireccion. Asimismo,
tambin existe una seal 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 (ContPrg:,'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 mquina 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 seales que comunican los procesos se realizan de forma
sncrona respecto al reloj. As, el proceso UControl esperar un flanco positivo de
reloj antes de realizar asignaciones a las seales 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 seales de control, en funcin del tipo de instruccin que se est ejecutando en
cada momento. Para estructurar la secuencia de rdenes utilizaremos procedimien-
tos que desarrollarn la secuencia adecuada para realizar tareas concretas, como,
por ejemplo, leer una instruccin de memoria, realizar un ciclo de bus, o calcular la
direccin final de memoria indicada por una instruccin 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 cdigo que se ejecuta tan slo
una vez y un bucle infinito. La primera parte inicializa las seales 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 cabra esperar de una implementacin hardware del
procesador. En un circuito real los registros que guardan el estado interno del proce-
sador reaccionaran a una activacin de la seal Inicializa de forma inmediata y
asncrona o como mximo tardaran 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-
cripcin a nivel de transferencia de registros requiere incluir una gran cantidad de
sentencias de control del flujo para verificar en cada tarea que la seal Inicializa
es inactiva antes de avanzar un ciclo de reloj. Adems, cuando el cdigo est es-
tructurado en procedimientos, la parte de cdigo que llama a un procedimiento ha
de controlar si la finalizacin del mismo ha sido normal o se ha interrumpido a cau-
sa de la seal Inicializa.
A continuacin 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 seal PeticionBus y espera hasta que
la seal BusLibre se active. Debe notarse que la sentencia wait que realiza la
espera slo 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 detendra su
ejecucin hasta que un evento en la seal BusLibre volviera a almacenar el valor
'1' en ella, es decir, seran necesarios dos eventos: uno que modificara el valor de
la seal y otro que restableciera el valor '1' para que el proceso continuara su eje-
cucin.
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 direccin a la que se
accede. En ambos casos los datos se almacenan y leen del banco de registros. Estos
procedimientos realizan la ejecucin 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';
Habifatiitos <= 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 bsqueda de una instruccin

en memoria. Es muy parecido al procedimiento Lectura con la diferencia de que la
direccin a que se accede se encuentra en el contador de programas y el destino de
los datos es el registro de instruccin. Al final del ciclo de lectura el CP se incre-
menta, dejndolo preparado para la carga de la siguiente instruccin.
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 instruccin en el proceso

UControl.
El procedimiento CalculaDireccion simplemente activa las seales de con-

trol necesarias para cargar la direccin 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 clculo de la direccin de memoria en el

proceso UControl.
El procedimiento EjecutaInstruccion determina que tipo de instruccin se en-

cuentra en el RI segn la seal TipoInstruccion y para cada uno de los cuatro posi-
bles tipos de instrucciones activa las seales de control adecuadas. Para las instruccio-
nes LOAD y STORE basta con llamar a los procedimientos CalculaDireccion y
Lectura o Escritura respectivamente. En los dems tipos .de instrucciones es en
este procedimiento donde directamente se determinan los valores de las seales de
control en los ciclos necesarios para la ejecucin de cada tipo de instruccin. Debe
notarse que parte de la decodificacin de la instruccin se realiza en la unidad de
proceso como, por ejemplo, determinar la operacin de la VAL a partir del campo
OP de las instrucciones aritmtico-lgicas.
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 ejecucin 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 tamao 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. Adems, para facilitar las referencias a los distin-
tos campos dentro de una instruccin, se definen alias para la variable RI, de modo
que podremos referirnos al campo que indica el tipo de instruccin como ca (bits 15-
14), al campo que indica la operacin aritmtica 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 aritmticas 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-
nuacin entra en.un bucle indefinido ejecutando en cada flanco de subida del reloj
las rdenes que le enva el proceso UControla travs de las seales 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 seales 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 cdigo 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 clculos "intei:mdios

variable iRd : integer;
-- Funcin que determina el registro a leer en funcin 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"...integr(unsignd(RI(10 downto 8))),;
when SelRf2 =>
return Conv_integer (unsigned (RI (7 downto 5)));
end case;
end CalcRegLectura;
begin
wait until rncatza =
'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" =>
CondicionSlto <= 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;
-- Asignacin 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 verificacin de los modelos VHDL constituye normalmente una de las etapas
ms difciles, pero ineludibles, del diseo electrnico. La verificacin consiste en
comprobar que la funcionalidad del diseo satisface las especificaciones. Para ello
es necesario definir bancos de pruebas con los cuales se estimular el diseo en el
mayor nmero posible de casos, con el objetivo de detectar los posibles errores.
En este apartado se considerarn los distintos tipos de bancos de pruebas que
pueden realizarse segn lo avanzada y estable que se encuentre la especificacin del
sistema donde se incluye el modelo a verificar. Los distintos tipos de bancos de
pruebas se aplicarn al diseo del procesador a medida que ste avance. As, empe-
zaremos por un banco de pruebas sencillo para la descripcin PrimeraParticion
en el siguiente apartado y lo iremos desarrollando a medida que modelemos con
ms detalle el sistema. Por otra parte, en el Captulo 6 se abordarn las cuestiones
de tipo metodolgico sobre cmo deben escogerse los estmulos y qu comproba-
ciones se deben incluir en los bancos de pruebas.
Con anterioridad a la aparicin de lenguajes de descripcin de hardware del es-

tilo del VHDL, la tarea de verificacin de los componentes diseados consista en
definir unos estmulos mediante un lenguaje proporcionado por el simulador lgico
utilizado y analizar, mediante la visualizacin de formas de onda, los resultados de
la simulacin del componente. Con la aparicin de los lenguajes de descripcin de
hardware modernos, la escritura de estmulos puede verse desde un punto de vista
distinto a la mera especificacin de cambios en las entradas del componente a veri-
ficar y el anlisis visual de las salidas. La realizacin 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
slo 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-
tirn siempre distintas alternativas para su realizacin segn el grado de precisin,
prestaciones y nivel de abstraccin 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-
cin y ello implica que no estn ligadas a un subconjunto particular del VHDL (co-
mo ocurre con las descripciones para sntesis) y que deben ser optimizadas para que
la simulacin sea lo ms eficiente posible. Adems, normalmente no nos interesarn
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 estmulos con la mayor precisin 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 situacin podremos realizar un modelado estructural del entorno
donde cada componente disponga de una entidad propia y una arquitectura que re-
fleje con precisin su comportamiento a lo largo del tiempo.
La segunda situacin es propia de dispositivos de propsito general que son
utilizados en una gran variedad de sistemas. En estos casos el banco de pruebas ten-
der ms 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 estarn definidos.
5.4.2.1. Bancos de pruebas como descripciones estructurales

del sistema
La aproximacin ms segura para la realizacin 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 interconexin de stas. Como hemos visto anterior-
mente, cuando se describe la estructura se describen con detalle las interfaces de ca-
da componente adems de su interconexin. Esto significa que una descripcin de
este estilo implicara que se dispone de abundante informacin de cmo es el siste-
ma y qu componentes lo componen.
Los componentes del sistema sern dispositivos comercialmente disponibles,
para los cuales ser posible obtener en algunos casos una descripcin VHDL pro-
porcionada por su fabricante. Adems, aun en el caso de que deban escribirse las
descripciones para cada componente, stas se escribirn de forma independiente del
componente a verificar, pensando tan slo 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 dificultarn los errores debidos a proble-
mas de interpretacin de especificaciones.
Por ejemplo, podramos 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 realizaran 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, realizndose para ello una descripcin es-
tructural.
El principal inconveniente de realizar un banco de pruebas que refleje la es-
tructura del sistema es la prdida de eficiencia en la simulacin. Por una parte, la
mayor cantidad de cdigo y procesos a simular, y por otra la mayor longitud de las
simulaciones, hacen que stas sean ms lentas que si no se hubiera detallado con
tanta precisin la estructura. La mayor longitud de las simulaciones con este tipo de
modelo es debido a que para aplicar determinados estmulos 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. Descripcin estructural del sistema.

terminado, lo cual puede implicar un gran nmero de ciclos de simulacin. Por

ejemplo, en nuestro sistema debera 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 algn modo. En el sistema real la memoria no estara inicializada sino
que durante unos ciclos algn componente estara escribiendo sus valores iniciales
desde el punto de vista de la simulacin del procesador. En cambio, si el modelo del
entorno no contemplara los componentes con tanta rigurosidad sera posible forzar
un estado del sistema con menor nmero 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 podramos no considerar los
componentes que constituyen el sistema y centrarnos en cmo se aplican los es-
tmulos al componente a verificar. El banco de pruebas consistira en una nica en-
tidad cuya arquitectura podra contener uno ms procesos, dependiendo del grado

de detalle con que sea necesario modelar el paralelismo en el entorno del compo-
nente a verificar para proporcionarle unos estmulos que se aproximen al mximo a
los que le proporcionara un sistema real.
La estructura de este tipo de banco de pruebas se muestra en la Figura 5-7,
donde diferentes procesos proporcionan estmulos al componente a verificar y reac-
cionan a sus respuestas, adems de coordinarse entre ellos mediante seales.
En algunos casos puede ser conveniente dar formato a los estmulos en ciclos,
de forma similar a como se introducen en las mquinas para el test de circuitos inte-
grados. Esto es til en el caso de que los estmulos de simulacin se quieran conver-
tir a vectores para la mquina de test o en el caso de querer realizar una descripcin
Banco de pruebas
Componente
a
verificar
FIGURA 5-7. Banco de pruebas funcional.

funcional que, a nivel de ciclos de reloj, proporcione los mismos estmulos que una
descripcin estructural pero acelerando la simulacin al disminuir el nmero de
procesos que se ejecutan. En este ltimo caso se realizara una simulacin de la des-
cripcin estructural del sistema almacenando en un fichero los estmulos que se
aplican al componente a verificar en cada ciclo. Posteriormente se podra sustituir
el banco de pruebas estructural por un banco de pruebas mucho ms sencillo que le-
yera los estmulos de un fichero y los aplicara.
La aplicacin de estmulos segn ciclos de test o de reloj era normal antes de la
existencia de los HDLs modernos, cuando la descripcin de los estmulos se reali-
zaba con el lenguaje propio de cada simulador. El principal inconveniente de esta
tcnica es que no se puede realizar un banco de pruebas mnimamente inteligente,
que se adapte a posibles cambios en el componente igual como se adaptara 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 nmero de ciclos que el procesador tarde en realizar la
lectura y escritura de datos. De este modo ser ms prctico realizar un modelo que
tenga en cuenta las relaciones causa-efecto de las seales al interactuar con el pro-
cesador que no uno que se limite a aplicar estmulos en cada ciclo sin tener en cuen-
ta las salidas del procesador.
5.4.2.3. Anlisis de las respuestas
La consideracin de las respuestas del componente a verificar no slo 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 hara el entorno real, sino que ade-
ms se pueden realizar comprobaciones sobre dichas respuestas que nos ayuden en
la verificacin.
Podemos distinguir dos estrategias en cuanto a la comprobacin automtica 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 ningn ciclo, pero son difciles de realizar si se trata de simulaciones
del componente a diferentes niveles de abstraccin. 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 implementacin de la segunda estrategia es en principio mucho ms com-
pleja, dependiendo de la complejidad y naturaleza del componente a verificar y
Modelo
Reloj -,--------,--+i de
referencia
Comparacin
Aplicacin ~----------_'I de OK
de resultados
estmulos (en cada ciclo)
Modelo
a
verificar
FIGURA 5-8. Verificacin basada en comparaciones ciclo a ciclo.
tambin es mucho ms difcil asegurar que la verificacin es suficientemente ex-

haustiva. Normalmente, en los bancos de pruebas existirn uno o ms procesos que
se encargarn de analizar las respuestas de la simulacin. Estos anlisis pueden ser
de dos tipos:
Dependientes de los estmulos que aplica el propio banco de pruebas. En este

caso los procesos encargados de realizar el anlisis debern comunicarse con
los procesos que apliquen los estmulos mediante seales para saber en qu
momento deben hacer las comprobaciones.
Anlisis
de
respuestas
independiente
del test
Generador Modelo t
de a
estmulos verificar ~
-
Anlisis
de
respuestas
dependiente
del test
FIGURA 5-9. Verificacin "inteligente".

Comprobaciones independientes. Casos tpicos 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 activacin de
las seales son correctos, o comprobaciones de que una combinacin de de-
terminados valores en las salidas del componente, que indicara claramente
que se ha llegado a una situacin no prevista, no se produce. Muchas veces
es ms prctico incluir este tipo de verificaciones dentro del modelo del
componente a verificar, ya que all se dispone de ms informacin sobre su
estado interno.
5.4.3. La mquina rudimentaria: el banco de pruebas
En este apartado vamos a simular el procesador con su arquitectura PrimeraParti-

cion utilizando la estrategia ms simple para modelar un posible entorno del proce-
sador. Por el momento en el modelo del entorno no se incluirn 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 seal de reloj, otra de
generar la seal Inicializa, otra de la interaccin del procesador con la memoria
(proceso Memoria) y la cuarta controlar el acceso al bus del procesador (proceso
Arbi troBus).
La generacin de las seales Reloj e Inicializa es suficientemente simple
como para poder utilizar sentencias de asignacin concurrentes en lugar de proce-
sos. La nica dificultad estriba en que necesitaremos utilizar la seal Reloj a la de-
recha de la asignacin y no lo podremos hacer ya que es un puerto de salida. Para
estos casos podemos utilizar una seal interna (Reloj_I) en la cual generaremos el
reloj y posteriormente asignar esta seal al puerto de salida.
El proceso que realizar el papel de la memoria de datos y programas contiene
una inicializacin de las posiciones de memoria (variable Man) donde se introducen el
mismo programa y los mismos datos que se utilizaban en la descripcin funcional del
procesador. Con posterioridad a esta inicializacin, el proceso entra en un bucle para
realizar las funciones habituales de una memoria: cada vez que se activa la seal Ha-
bili taMem, realiza un ciclo de escritura o de lectura segn indique la seal
Escribe. En realidad, el proceso no se activa de acuerdo con la seal Habili taMem
sino con una seal homloga retrasada 10 ns (HabilitaMem'delayed(lO nsJ). De
esta forma es posible asegurar que las seales asignadas por el procesador (Direc-
cion, Escribe y Datos) estn estables cuando las lee este proceso.
Finalmente, el proceso Arbi troBus reacciona a las peticiones de bus por parte
del procesador activando la seal 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
RelLI <= DOt ReloLI after CiclReloj!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)':; IOooiii000100"; -r--lIPD(4,3,2), .
Mem(3) :,; OlldOO~OOOllOO"; '7 - Sl'OREf4,(U,2)
Mem(() ~:'" "iooooododoOOOOo'; .; - 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-
macin acerca de cmo deben realizarse tales operaciones, de cul es el tiempo
ms o menos aproximado que requiere cada una de ellas, de cmo detectar posi-
bles situaciones prohibidas y otra serie de cuestiones que para poder ser tratadas
requieren disponer de un mnimo de informacin relativa a la implementacin del
procesador.
Nuestro objetivo ser, por tanto, a travs de un refinamiento progresivo de los
modelos del sistema, obtener unas descripciones que reflejen claramente todos los
detalles de implementacin, o modelen de una forma precisa la realidad. En el pri-
mer caso se tratar de los componentes que realmente pretendemos implementar y
que despus de este proceso de refinamiento podrn ser utilizados como entrada a
una herramienta de sntesis, que automticamente generar el circuito correspon-

diente. En el segundo caso se trata de aquellos componentes que tambin forman
parte del sistema, pero que nicamente son necesarios para crear el entorno realista
en el que deber operar nuestro diseo, y que, por tanto, sern diseados de cara a
su simulacin.
5.5.1. Modelado para sntesis vs modelado

para simulacin
Hasta el momento, el objetivo que se persegua con los diferentes modelos funcio-
nales descritos en los apartados anteriores era tratar de describir el funcionamiento
de nuestro sistema electrnico con una doble finalidad:
1. Especificar y documentar las caractersticas del sistema.
2. Simular los modelos para verificar la validez del diseo.
Sin embargo, a medida que pasemos a: refinar estos modelos funcionales debe-
mos tener bien claro cul es el objetivo de dichos modelos:
1. Disponer de una descripcin precisa de aquello que se pretende modelar.
2. Escribir una descripcin inteligible por las herramientas automticas de sn-
tesis, que generarn el circuito a partir de dicha descripcin.
La razn es bien sencilla. El VHDL, y en general los HDLs, fueron pensados
para facilitar la tarea del diseador de sistemas electrnicos; por tanto, se puso ms
nfasis en tratar de dotarlo de caractersticas como la flexibilidad que no en otras
que mejoraran las prestaciones de las herramientas asociadas.
Por lo que respecta a la simulacin, 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 simulacin.
En el caso de la sntesis, resulta un tanto ms crtico, puesto que el grado de
flexibilidad del lenguaje dificulta enormemente el trabajo a las herramientas auto-
mticas. En consecuencia, slo se permite utilizar un subconjunto de construccio-
nes, perfectamente definido, en los modelos que tienen como objetivo la sntesis
automtica. La consecuencia inmediata es que, si bien cualquier modelo para la sn-
tesis puede ser simulado, no todos los modelos simulables son sintetizables.
En resumen, a la hora de escribir modelos sintetizables habr que ceirse al
subconjunto de construcciones y estilos recomendados por las herramientas de sn-
tesis, mientras que si slo se trata de escribir un modelo simulable habr que tener
en cuenta ciertas recomendaciones que pueden mejorar el rendimiento del simula-
dor, aunque cualquier construccin est soportada.
5.5.2. El modelado del tiempo
A medida que tiene lugar el proceso de refinamiento de las descripciones VHDL,

no slo se ponen de relieve con mayor detalle las caractersticas referentes a la im-
plementacin de estos modelos, sino que tambin se va precisando su comporta-

miento temporal.
La versatilidad del VHDL permite modelar el comportamiento temporal del
hardware a diferentes niveles de abstraccin. As, por ejemplo, en la primera des-
cripcin de nuestro procesador, la nica caracterizacin temporal se refiere al
tiempo de ciclo de instruccin, muy poco precisa, pero suficiente para el nivel de
que se trata, y la nica posible debido al desconocimiento de los detalles de imple-
mentacin. Sin embargo, a medida que avance el captulo trataremos el modelado
realista de otros componentes, como puede ser una memoria RAM, en los que no
slo se incluirn todos los parmetros temporales habituales en estos modelos,
sino tambin el cdigo necesario para realizar la verificacin de las restricciones
que se imponen a estos parmetros (tiempos de establecimiento, tiempos de mante-
nimiento, ... ).
El lenguaje VHDL no proporciona un mecanismo estndar para la especifica-
cin de la informacin temporal de los modelos. La forma de implementarla depen-
de, en gran medida, del grado de precisin del modelo (asignacin de un retardo
aproximado o realista), de su reutilizacin (paso de la informacin temporal como
parmetros), etc. As, al diseador se le ofrecen diferentes alternativas.
1. Si se trabaja en un nivel de abstraccin alto, como puede ser la primera des-

cripcin de la mquina rudimentaria, puesto que se dispondr de muy poca
informacin acerca de la implementacin del modelo, se buscar simple-
mente una forma muy aproximada de modelar esta informacin, que permi-
ta nicamente establecer algn tipo de comparacin 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-

truccin que puede servir perfectamente para comparar dos repertorios de
instrucciones entre s, aunque este valor no se corresponda con el resultante
de la implementacin 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 instruccin.
2. Descendamos algn nivel en la jerarqua, y supongamos que disponemos de

un modelo estructural del sistema a disear. En este caso puede interesar,
por ejemplo, disponer de un modelo de retardo de pin a pin (pin-to-pin), en
el que slo nos interesa conocer el tiempo de propagacin desde las entradas
hasta las salidas del componente. En tal caso el modelado consistir en la
utilizacin de la clusula after en la sentencia de asignacin del valor co-
rrespondiente al puerto de salida.
Ejercicio 5.1
Modelar un multiplexor 2 x 1 que verifique las siguientes caractersticas:
E11J-0 ... S
E2 1
FIGURA 5-10. Multiplexor 2 x 1.
TABLA 5-4. Tiempos de retardo
Parmetro . Camino Tiempo

tpl El o E2 hasta S 20 ns
tp e hasta S lOns
Solucin
En este caso existen dos tiempos de propagacin diferentes, en funcin 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 seal de entrada se ha producido
el evento, y asigna el valor a la salida con el retardo que corresponda. La funcin
CalculaDato es la que realmente implementa el comportamiento del multiplexor,
mientras que el cuerpo del proceso nicamente identifica la seal sobre la que se
produjo el evento y asigna el retardo en consecuencia. Note cmo no se ha tenido
en cuenta el caso de que se activen simultneamente una seal de datos y otra de
control. Esta comprobacin est implcita en el cdigo, 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 propagacin.

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 ms cercano al hardware,

en el que nuestro circuito est modelado a base de las celdas lgicas que lo
componen. Si pretendemos hacer una simulacin realista de nuestro diseo
tendremos que reflejar todas las caractersticas de estos componentes, segn
se especifican en las hojas de datos (datasheets) de la tecnologa que corres-
ponda. Para cada celda existir no slo un tiempo de propagacin determi-
nado desde las entradas hasta las salidas, sino que adems ste variar en
funcin del nmero de celdas a las que sta est conectada lfanout). Incluso
el retardo ser diferente en funcin del tipo de transicin (0/1, 1/0,01Z, ... ).
Puesto que el modelo temporal de cada celda depender de su posicin en el
circuito, no podremos fijar sus caractersticas temporales en el cdigo, sino
que se pasarn mediante parmetros.
Ejercicio 5.2
Escribir el modelo correspondiente al circuito de la Figura 5-11, reflejando la infor-
macin 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
Mnimo Tpico Mximo

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
Solucin
El primer paso consistir en obtener la descripcin de la puerta and, que posterior-

mente utilizaremos para modelar el resto del circuito. La entidad, adems de los
puertos correspondientes a las entradas y salidas de la puerta, incluir dos parme-
tros genricos: los tiempos de propagacin 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 asignacin 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 parmetro los tiempos
de propagacin, que como puede verse dependen de su posicin en el circuito. La
frmula empleada consiste en sumar al tiempo base un retardo adicional, en funcin
del nmero de entradas extra a las que la puerta est conectada.
2 tplhltphl: tiempo de propagacin de Oa l/de 1 a O,

3 dtplhldtphl: variacin del tiempo de propagacin (Oa 1/1 a O) respecto al fanout de la celda.
Para tener en cuenta los diferentes casos de simulacin: tpico, mnimo y mxi-
mo, las constantes de tiempo son vectores de tres tiempos, uno para cada caso de si-
mulacin. Segn sea este caso de simulacin, que se pasa como parmetro 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 mnimo 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.!1caso) .. 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 precisin de los modelos influye notable-

mente en el rendimiento del simulador. Cuanto mayor sea el nmero de procesos y
variables temporales a manejar y la precisin de stas (no es lo mismo operar con
enteros que con nmeros reales), menor ser el rendimiento del simulador, que ne-
cesitar ms tiempo y mayor cantidad de memoria para completar la simulacin.
5.5.3. La comprobacin
,
de errores
Una de las ventajas de la utilizacin de los simuladores es que permiten poner de
relieve fcilmente los errores que se pueden producir, no slo de codificacin, sino
tambin en la concepcin del modelo. Por ejemplo, puede resultar que en un siste-
ma con un DMA se genere una direccin 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 diseador puede incluir
explcitamente en los modelos una serie de condiciones, que en caso de no verifi-
carse generarn mensajes de error durante la simulacin.
Ejercicio 5.3
Modelar la siguiente memoria ROM, incluyendo las comprobaciones necesarias
para asegurar que las direcciones son correctas antes de realizar una operacin de
lectura y escritura.
Habilita
8 Dato
ROM
8 I
Direccion
FIGURA 5-12. Memoria ROM.
Solucin
La funcin 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 direccin vlida. En caso de que la direccin no sea correcta en el momento de
recibir la seal de habilitacin 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 mltiples 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 difcil poder dar alguna re-
comendacin al diseador 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 ms acotado, puesto que siempre se trata
de verificar la estabilidad de las seales, su duracin y su dependencia temporal.
En el caso de las verificaciones temporales podemos establecer la siguiente cla-
sificacin:
Verificacin de tiempos de establecimiento (setup): tiempo que debe haberse
mantenido estable una seal antes de que ocurra un evento en la seal de re-
ferencia.
Verificacin de tiempos de mantenimiento ihold): tiempo que debe mante-
nerse estable una seal despus de que ocurra un evento en la de referencia.
Verificacin de la duracin de niveles estables.
Verificacin del periodo de una seal.
5.5.4. El modelado detallado de la Mquina Rudimentaria
Aunque, como el ttulo indica, el propsito de este apartado es el de aplicar los

apartados anteriores sobre la Mquina Rudimentaria, nos servir de excusa para
realizar un recorrido muy general sobre las diferentes maneras de modelar los com-
ponentes ms habitualmente utilizados a la hora de disear hardware.
Seal 1
T,: Tiempo de establecimiento de seal 1 respecto a seal 2

T 2: TIempo de mantenimiento de seal 1 respecto a seal 2
T3: Duracin mnima del nivel '1'
T4: Duracin mnima del nivel 'O'
Ts: TIempo mnimo de ciclo
FIGURA 513. Verificacin 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-
sin: los dos procesos que modelan el control (UControl) y los recursos de clculo
(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 Mquina Rudimentaria, mientras
que el proceso UProceso pasar a ser la Unidad de Proceso (UPoceso). Adems,
el sistema deber disponer de una memoria RAM, en la que se almacenarn 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 ms dispositivos en
el sistema que tambin estn conectados al bus del sistema.
5.5.4.1. La Unidad de Proceso

La Unidad de Proceso contiene los recursos de clculo del procesador, y ser la en-
cargada de ejecutar las diferentes instrucciones, segn lo indique la Unidad de
Control. Para ello, en nuestro caso, dispondr de una Unidad Aritmtico-Lgica
(UAL), de un banco de registros de propsito general en los que almacenar los re-
sultados procedentes de la UAL y la memoria, de un conjunto de registros para ta-
reas especficas, y de la lgica necesaria para interconectar todos estos recursos
(Figura 5-14).
CargaRDM
CargaCP
CargaRI FuenteDireccin
CargaA
CargaN
CargaC
IncCP ..
HabilitaDireccin
d
e
C
SelCampo
o RI'3-11 (Rf_Rd)
n
Salto Evaluacin
de la
o Condicin
FIGURA 5-14. Unidad de Proceso de la Mquina 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 problemtica
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 podrn identificarse los diferentes componen-
tes de la unidad (Figura 5-14) sobre el modelo, pero sin embargo se describirn sin
especificar su implementacin. Adems, el resultado final ser sintetizable.
5.5.4.1.1. La Unidad Aritmtico-lgica

La Unidad Aritmtico-lgica (UAL) aglutina los recursos de clculo necesarios
para realizar las operaciones aritmticas y lgicas, como su propio nombre indica.
En nuestro caso, para hacemos una idea de cules debern ser estos recursos, debe-
mos revisar el repertorio de instrucciones de la Mquina Rudimentaria.
Como puede verse en la Tabla 5-2, existen seis tipos de instrucciones que re-
quieren recursos aritmtico-lgicos, 'aunque slo 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 lgica de dos operandos, siendo todos
estos operandos de 16 bits. Estas operaciones, adems, modificarn el estado de dos
indicadores: negativo y cero, que se activarn si el resultado de la operacin es ne-
gativo o es cero, respectivamente.
La siguiente figura muestra grficamente la interfaz de la UAL con el resto de
la unidad de proceso.
Opera
Cero Operacion
FIGURA 515. Unidad Aritmtico-lgica.
La UAL tomar como entradas los dos operandos A y B, el tipo de operacin a

realizar (Operacion) y la seal que habilitar dicha operacin (Opera). En caso de
que esta seal no est activada simplemente se producir un paso transparente del
operando B hacia el Resul tado. Como salidas, adems de este resultado, se genera-
rn dos indicadores, que notificarn si el resultado de la operacin 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 Aritmtico-lgica.
En primer lugar vamos a desarrollar el modelo funcional de la unidad, por las

siguientes dos razones:
1. Porque proporciona una manera rpida 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 simulacin del sistema ser un modelo
mucho ms eficiente que uno detallado.
El modelo funcional de la VAL prcticamente consiste en una instruccin case
que, en funcin de la codificacin del vector Operacion, almacena el resultado de
la operacin en una variable. A continuacin se asigna la variable al puerto de sali-
da y se actualizan convenientemente los indicadores Cero y Negativo.
Se ha introducido una estimacin del tiempo de retardo para cada operacin,
que ms que tratar de reflejar el retardo real de cada operacin, 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
-- Efecta una operacin aritmtica

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 lgica
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 operacin el. resu;J.tadoes B
ResultadoTemp := B;
Retardo := TpoPaso;
end if;
-- Asignacin del resultado

Resultado' <= Resu!tadoTemp after Retardo;
-- Clculo 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 Aritmtico-lgica.
Dado el estado del arte de las herramientas de sntesis automtica que se co-
mercializan actualmente, el modelo anterior es prcticamente 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 clculo: sumadores, restadores, multiplicado-

res, etc. Adems muchas son tambin capaces de realizar una sntesis arquitectural,
que permite realizar una planificacin de la utilizacin de recursos compartidos en
el caso de que la operacin se realice ms de una vez.
Quiz lo nico que pueda causar problemas sean las referencias temporales,
puesto que las herramientas de sntesis no las soportan (algunas las ignoran y otras
las indican como errneas). El resultado obtenido a partir de la sntesis depender
no slo de las restricciones que se impongan a la herramienta, sino tambin de la
tecnologa elegida para la implementacin del diseo. Seguramente, por ejemplo, el
sumador y el restador se implementarn mediante un mdulo sumador/restador,
y su arquitectura podr ser de tipo ripple-carry, carry look-ahed, etc., en funcin
de los requerimientos de rea y velocidad que se le especifiquen a la herramienta de
sntesis.
Aunque no sera necesario continuar el refinamiento del modelo de la UAL, pues-
to que ya es directamente sintetizable, y las herramientas automticas son capaces de
evaluar las diferentes alternativas de implementacin, segn los parmetros especifi-
cados por el usuario, dado el carcter educativo de este captulo, realizaremos manual-
mente lo que estas herramientas ya son capaces de resolver de forma automtica.
Puesto que existen cuatro operaciones diferentes a realizar, realizaremos cada
una de ellas en un mdulo diferente. Esto nos permitir posteriormente jugar con
varias alternativas de implementacin para cada uno de estos mdulos. Por supues-
to, existen otras particiones alternativas, puesto que, por ejemplo, es muy habitual
encontrar mdulos sumadores/restadores, que realizan ambas operaciones depen-
diendo de una seal de control.
Como puede verse en la Figura 5-16, el modelo estructural de nuestra UAL
constar, por tanto, de un bloque para cara operacin (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 mdulo obte-
ner el resultado final, en funcin del cdigo de operacin a realizar, y la lgica
necesaria para activar los indicadores. En este caso no incluiremos informacin
acerca de los retardos de las diferentes operaciones, puesto que se har en cada uno
de los diferentes mdulos.
Veamos a continuacin cmo el cdigo VHDL correspondiente al modelo es-
tructural refleja fielmente la particin 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_lgic_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(CBitsrito)
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' ;
-- Asignacin. al port de salida

Resultado <= ResultadoTemp;
end Estructural;
LISTADO 5-25. Modelo estructural de la Unidad Aritmtico-lgica.

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-
cin. En la primera utilizaremos una arquitectura con clculo del acarreo en serie
ripple-carry, mientras que la segunda ser con clculo del acarreo anticipado
(carry-lookahead). Trataremos, adems, de evaluar aproximadamente cul puede
ser el coste aproximado de cada implementacin en trminos de rea y nmero de
puertas. Como en los modelos desarrollados hasta este punto del captulo, los par-
metros en los que nos basamos para realizar estas comprobaciones son relativos,
puesto que no estn extrados de datos reales.
5.5.4.1.1.1. El sumador con acarreo de propagacin (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 ms un aca-
rreo de entrada, generando un bit de resultado y un acarreo de salida. Estos mdulos
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 cdigo VHDL correspondiente a la funcin 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

implementacin, es que son poco costosos en trminos de rea ocupada. Por con-
tra, suelen ser excesivamente lentos, puesto que, como se puede apreciar en la Figu-
ra 5-17, el clculo 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 instruccin 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 comportanento temporal del sumador revisemos el Listado 5-26.

Como puede apreciarse se realizan dos tipos de operaciones diferentes, equivalentes
a las puertas lgicas 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 fcil comprobar que el camino ms crtico corresponde a la seal de acarreo,
puesto que los tiempos de retardo seran los siguientes:
Tiempo(Resultado) = 2 * TpoXor
Tiempo(Acarreo) = TpoXor + 1POAO,
donde TpoAO > 'lPoXor.
A partir de estos clculos es inmediato deducir que el camino crtico 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 clculo 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 clculo de un acarreo depende de la finaliza-

cin de la etapa anterior, el retardo total corresponde a la suma de los retardos de la
funcin AndOr, ms el tiempo de retardo de la operacin A xor B, que debe reali-
zarse en primer lugar.
En el segundo caso, el tiempo total es la suma de esta primera operacin, ms el
retardo de las 15 etapas de clculo de acarreo, junto con el tiempo de la operacin
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 propagacin puede resultar demasia-
do lento, debido a que para calcular el resultado de cada bit debe esperarse la propa-
gacin del bit de acarreo a travs de todas las etapas anteriores.
Una solucin alternativa es la que presenta el sumador con acarreo anticipado.

En este caso se trata de dividir el sumador en bloques ms pequeos, 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 clculos antes de que el anterior haya
finalizado. Para ello se aprovechar el hecho de que toda ecuacin combinacional
puede expresarse como una funcin 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 propagacin de acarreo en
la operacin de suma de dos bits.
TABLA 5-6. Propagacin del acarreo
Aj Bj Cj
O O O
O 1 Cj+1 propagacin
1 O Cj+1 propagacin
1 1 generacin
Como puede apreciarse en la tabla anterior, si A = B = Ono se generar ningn

acarreo a la etapa siguiente, a diferencia del caso A = B = 1, en el que s lo habr
(etapa de generacin). Sin embargo, en los casos en los que A <> B, puesto que
slo una de las dos entradas vale '1' habr acarreo de salida slo 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 propagacin).
Segn la explicacin, las ecuaciones booleanas correspondientes a las etapas de
generacin (G) y propagacin de acarreo (P), extradas de la tabla anterior, seran
las siguientes:
Gj =Aj and B,
Pj =Aj xor B,
De la misma tabla, tambin puede concluirse que se obtiene un acarreo de sali-

da siempre que se trate de una etapa de generacin, o una de propagacin en la que
haya un acarreo de entrada. En forma de ecuacin:
Finalmente, podramos expresar la suma en funcin de las ecuaciones ante-

riores:
Si en la expresin que calcula el acarreo de salida en funcin del de entrada

sustituimos este ltimo por su ecuacin equivalente obtendremos:
Continuando este proceso, desarrollando las ecuaciones de los diferentes aca-

rreos, obtendramos una ecuacin que dependera nicamente del acarreo de entra-
da al sumador Ca. Adems, corno es bien sabido, toda ecuacin booleana puede ex-
presarse como una suma de productos (o producto de sumas), cuya implementacin
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 sera necesario un
gran nmero de puertas, algunas de las cuales tendran ms de cuatro o cinco entra-
das. La alternativa ms habitual consiste en dividir el total de bits en grupos (cuatro
grupos de cuatro bits en nuestro caso) y acelerar el clculo del acarreo para cada
grupo por separado. Aunque esta opcin requiere un tiempo de clculo mayor, asu-
me un compromiso rea/velocidad mucho ms razonable. La Figura 5-18 muestra
los diferentes bloques que formarn 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 propagacin y generacin del aca-
rreo para cada bit. El bloque Suma obtiene el resultado final a partir de la propaga-
cin 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 ecuacin (*). 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), ms 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 cdigo VHDL correspondiente al bloque CIA. El
Listado 5-29 modela el sumador, utilizando el componente CIA anterior. Observe
cmo, 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 clculo de la pro-
pagacin y generacin de acarreo, y el clculo de la suma, se efecta mediante la
operacin lgica correspondiente. El cdigo 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
-- Clculo de las etapas de generacin y propagacin
G <= A and B;
P <= :xor B;
-- Clculo de la suma final

Resultado <= P :xor AcarreoG(NumBits-l downto O);
-- clculo 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 cul puede ser el caso ms desfavorable respecto al retardo

de este sumador. Fijmonos para ello en la Figura 5-18. El primer nivel de retar-
do ser el introducido por la etapa de clculo de la generacin y propagacin (tiem-
poixorj). Puesto que, como se ha mencionado, la funcin implementada por el blo-
que CIA tendr dos niveles de puertas, consideraremos su retardo similar al de una
puerta AndOr. Finalmente, el clculo 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 nmero de puertas necesario para la implementacin 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 propsito general en los que se
almacenan los datos que se envan y reciben de la memoria, as como los que inter-
vienen en las operaciones ejecutadas por la UAL.
Revisemos la descripcin 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 seal EscribeRegistro.
Durante el funcionamiento normal de la unidad operativa, los cambios en los
registros se realizan en el flanco de subida del Reloj.
Las seales 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 slo 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 lgica secuencial, puede

modelarse mediante un proceso secuencial (refirase al apartado 4.7), que suele te-
ner la siguiente estructura:
process (Reloj, Inicializa)

begin
if Inicializa = '1' then
-- nicfal iza la lgica secuencial
elsif Rloj'vent and Reloj = '1' then
-- clculo del valor asignar
end if;
end process;
LISTADO 5-31. Un proceso secuencial.
En este caso la respuesta del modelo a la seal Inicializa ser de tipo asn-
crono, puesto que no depende del estado del reloj. Para modelarla como una seal
sncrona sera suficiente con preguntar por su estado dentro de la condicin 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. Descripcin funcional del banco de registros.
En nuestro caso la inicializacin del banco, que tendr lugar cuando la seal
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
ningn clculo sobre el valor a almacenar, que directamente ser DatoEscritura.
Sin embargo, obsrvese 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
seal EscribeRegistro. La razn es que esta seal es ms prioritaria que el reloj,
puesto que no hay asignacin si no est activada.
En nuestro modelo aparece adems una asignacin concurrente, que simple-
mente se encarga de asignar como dato de salida del banco el contenido del regis-
tro, indicado por SelRegLectura. A esta asignacin 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 seales de control y
a la que proporciona cierta informacin de estado, y, por otro, con la memoria de
programas y datos. Concretamente, de la Unidad de Control recibe las siguientes
seales:
las que controlan la carga de los registros

la de control de acceso al banco de registros
la seal de operacin de la UAL
las seales de control de la carga de los registros especficos
las seales de control de acceso al bus del sistema.
Como informacin de estado, la Unidad de Proceso indica a la Unidad de Con-
trol:
el resultado de la evaluacin de la condicin indicada en la instruccin en
curso
el cdigo de operacin de dicha instruccin, de manera que la Unidad de
Control pueda decidir cul debe ser su nuevo estado.
El intercambio con la memoria consiste, sencillamente, en enviar una direc-
cin desde la que se leer o en la que se escribir un dato, segn 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 especficos

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_logc:,:"vctor(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 indicbamos al comienzo del cap-
tulo, adems de estos dos componentes se dispondr de un conjunto de registros y
cierta lgica 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
-- Declaracin de componentes
CCJll)O!leIlt UAL
end component;
component BancoRegistros
end component;
-- Registros especficos
signal A std...logic_vectorlcBitsDato-1 downto O);
-- Registro Acumulador
-- Seales temporales
signal B : std...logic_vectorlcBitsDato-1 downto O);
-- Campos del Registro de Instruccin IRI) (alias)
begin
Copia por referencia de los componentes UAL y Banco Registros
-- Modelado de los registros especficos
-- Lgica adicional
end FlujoDeDatos;
LISTADO 5-34. Descripcin en flujo de datos de la Unidad de Proceso.

La asignacin de los alias a los campos del registro de instruccin puede

resumirse en la siguiente tabla.
TABLA 5-7. Codificacin de las instrucciones de la Mquina Rudimentaria
Instruccin Bits 15-14 Bits 13-11 Bits 10-8 Bits 7-0

LOAD 00 Rd Ri Direccin Base
STORE DI Rf Ri Direccin Base
Salto ID Condicin 000 Direccin
Operacin con inmediato II Rd Rfl Nmero/Operacin
Operacin aritmtica II Rd Rfl Rf2 / DO/Operacin
El modelo correspondiente a los registros especficos es prcticamente idntico

para todos ellos. Todos los registros disponen de una seal de inicializacin asncro-
na (Inicializa) y una seal de habilitacin sncrona (Cargaxx). Las nicas par-
ticularidades son las que presentan los registros de Direccin 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 seal de control, adems de la de carga, tambin
sncrona, 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 direccin
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 especficos.

El resto de la funcionalidad del circuito corresponde a la lgica 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 instruccin case, para seleccionar en funcin de la
seal de seleccin Sel la fuente correspondiente. Sin embargo, el segundo utiliza una
asignacin concurrente condicional para realizar la misma operacin.
-- Seleccin 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;
-- Seleccin 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;
-- Seleccin 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 lgica combinacional restante se encargar de la funcin de evaluacin de la

condicin de salto y la habilitacin de los tri-estado de acceso al bus del sistema.
-- Evaluacin de la condicin
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 '0101"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;
-- Seleccin de la direccin de memoria

Direccion <= ROM when
(FuenteDireccion = '1' and HabilitaDireccion = '1') elBe
CP when
(FuenteDireccion = 'O' and HabilitaDireccion = '1') elBe
(others => 'Z');
-- Habilitacin de los datos
Datos <= Rx when HabilitaDatos = '1' elBe
(others => 'Z');
LISTADO 5-37. Modelado de la condicin 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 instruccin como microoperaciones, de
manera que la ejecucin de una instruccin consistir simplemente en llevar a cabo
la secuencia de rnicrooperaciones que le corresponda.
En nuestro caso, el control de la ejecucin de las diferentes microoperaciones
se realizar mediante una serie de seales de control sobre la unidad de proceso, el
bus del sistema y el rbitro de bus. Adems, su secuenciamiento depender de la in-
formacin de estado proporcionada por la unidad de proceso, en forma de seales
de entrada, tal y como muestra la Figura 5-19.
A partir de la figura anterior puede determinarse el cdigo 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
FuenteDireccin
HabilitaDireccin
I AWnwri, F Escribe
HabilitaMem
HabilitaDatos
Salto
CodigoOp
FIGURA 5-19. Unidad de Control de la Mquina 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_logc;
CargaRI out std_logc;
CargaA out std_logc;
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 ejecucin de los diferentes microprogramas que
corresponden a cada instruccin.
En el resto de la seccin analizaremos cules deben ser las microoperaciones

que la Unidad de Control de la Mquina Rudimentaria debe realizar para ejecutar
cada una de las diferentes instrucciones. Todas aquellas microoperaciones que se
puedan realizar simultneamente se agruparn en estados, para finalmente obtener
el diagrama de estados total de la Unidad de Control. Por ltimo, estudiaremos las
diferentes alternativas de implementacin: cableada y microprogramada.
5.5.4.2. 1. El diagrama de estados de la Unidad de Control

Recordemos que la Mquina Rudimentaria dispone de cinco formatos de instruc-
cin diferentes, resumidos en la Figura 5-4.
La Figura 5-20 muestra el diagrama de estados de la mquina 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 tambin tomen el control del bus, por lo que antes de acceder a l
hay que realizar una peticin y esperar la concesin.
2 Se llega a este estado cada vez que finaliza la ejecucin de una instruccin o se produce una
inicializacin del sistema.

Bl : BusLbre
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 bsqueda

y descodificacin de la instruccin, es comn a todas las instrucciones. Se encarga
de almacenar en el registro RI la siguiente instruccin a ejecutar. A partir de este es-
tado, yen funcin del cdigo de operacin de la nueva instruccin (CodgoOp) y la
condicin de salto (Salto) se decidir el tipo de operacin y, por tanto, cul 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 direccin desde o a la que
se va a realizar la carga o almacenamiento (CalculaDreccion). Posteriormente,
en funcin del cdigo de operacin 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 instruccin de salto slo requiere un estado (CargaDireccion), durante el
cual se colocar en el registro contador de programas la nueva direccin de programa.
La ejecucin de las operaciones aritmtico-lgicas 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 continuacin se obtiene del banco de
registros el segundo operando, se ejecuta la operacin y almacena el resultado en el
registro destino (estado Ejecuta).
La Tabla 5-8 muestra detalladamente cules son las rdenes de control que de-
ben activarse durante cada estado del diagrama de la Figura 5-20.
TABLA 5-8. Activacin de las seales 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 cmo implementar en la prctica el autmata que realiza

todas estas operaciones. Como primera opcin trataremos el diseo del circuito a
medida. Es decir, escribiremos el cdigo 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, cul debe ser
el estilo de la descripcin.
5.5.4.2.2. Implementacin cableada de la Unidad de Control

Una implementacin cableada consiste simplemente en realizar un circuito a rnedi-
da que, a partir de las seales de entrada y el estado memorizado, genera las corres-
pondientes salidas. Las implementaciones cableadas generalmente son ms rpidas
que las microprogramadas, a costa, sin embargo, de un mayor coste y complejidad.
En el caso de la Mquina Rudimentaria, la funcionalidad de la unidad de con-

trol est determinada por la mquina de estados de la Figura 5-20. Para su imple-
mentacin podemos optar por varias alternativas. Podramos 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 opcin, que ser la que trate-
mos a continuacin, consistir en describir el comportamiento de la unidad median-
te un modelo de VHDL sintetizable, obteniendo as el circuito equivalente.
En general, una buena tcnica 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 cul ser el siguiente, ya que se trata de un diagrama tipo
Moore. De esta manera no slo se facilita el trabajo a las herramientas de sntesis,
sino que adems se obtiene una descripcin clara e inteligible. Refirase al aparta-
do 4.9 para conocer otros estilos de descripcin de diagramas de estados. El si-
guiente listado contiene los dos procesos mencionados.
library IEEE;
architecture Funcional of UControl 18
type tEstados is (Buscalnstruccion, CalculaDteccion, CargaDato,

AlrnacenaDatO',C8rgaDreccon, 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_logc.;..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 seales 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';
-- Asignacin de salida~ y clculo 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 AlnacnaDato =>

FuenteDireccion <= RegIJM;
Escribe <:;: , 1'.
.HabilitaMan <= '1';
SigUinteEsta<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. Mquina de estados de la Unidad de Control.
Puede observarse cmo el proceso Secuencial tiene la estructura de un proce-

so secuencial tpico. Si la seal Inicializa se activa de forma asncrona, se colo-
car la mquina en el estado inicial, exactamente igual que si se tratara de la seal
Inicializa asncrona 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 mquina de estados.
El proceso Combinacional bsicamente consiste en una sentencia case, con

una entrada para cada posible estado de la mquina de control. Para cada estado se
especificar cules son sus salidas asociadas y se calcular el siguiente, comproban-
do para ello el estado de los bits del cdigo de operacin y la condicin de salto, en
funcin de la instruccin de que se trate. Una buena prctica para evitar omisiones
que provoquen un funcionamiento no deseado del circuito consiste en inicializar to-
das las seales de control antes de entrar a la sentencia case, que evaluar el estado
y asignar valores slo a aquellas seales que intervengan en la operacin a realizar.
5.5.4.2.3. Implementacin microprogramada

de la Unidad de Control
La microprogramacin es una alternativa mucho ms extendida frente al uso de uni-
dades de control cableadas. Un microprograma (tambin denominado firmware), al
igual que un programa, no es ms que la implementacin de un algoritmo mediante
un conjunto de microinstrucciones. Estas microinstrucciones no son otra cosa que la
agrupacin de una serie de microoperaciones que pueden realizarse simultneamente.
Una de las principales ventajas de este tipo de implementacin 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-
croinstruccin, en nuestro caso, y puesto que no es el objetivo de este texto profun-
dizar en este tema, se ha optado por el ms claro y sencillo, el formato horizontal.
Pero antes de describir este formato, y para facilitar su comprensin, veamos cul
es la arquitectura tpica 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 Mquina Rudimentaria,
en este caso). Modificar el microprograma correspondiente a cada instruccin es tan
sencillo como reprogramar dicha memoria de control.
Para que la ejecucin de una microinstruccin pueda realizarse de forma simul-
tnea a la bsqueda 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 microinstruccin por ciclo.
El resto de los bloques de la unidad estn dedicados al control del secuenciamien-
to de los microprogramas. As, a partir de la propia informacin proporcionada por la
microinstruccin, y la informacin de estado de la unidad de proceso, el secuenciador
ser el encargado de enviar a la memoria de control la direccin de la siguiente mi-
croinstruccin a ejecutar. Esta direccin puede venir del contador de microprogramas
(CMP) en el caso de la ejecucin en secuencia, de un campo de la microinstruccin, si
se trata de una microinstruccin de cambio de secuencia, o del registro de instruccin.
En este ltimo caso se utiliza el cdigo de operacin directamente como direccin, de
manera que cuando se ejecuta una nueva instruccin se accede a la posicin de su
cdigo de operacin, donde se hallar una microinstruccin 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 microinstruccin constar de

varios campos que podemos clasificar en dos grupos:
De secuenciamiento: que decidirn la siguiente microinstruccin a ejecutar
(SelSigDireccion, SelCondicion, SigDireccion).
Micrordenes: que activarn las seales de control.
Este tipo de formato se denomina horizontal, puesto que existe un bit de la mi-
croinstruccin para cada seal de control, pudiendo simultanear la ejecucin de to-
das ellas. En el caso de la Mquina Rudimentaria el formato final de una microins-
truccin ser el de la Figura 5-22.
Una vez conocido el formato de la microinstruccin, y a partir de la Tabla 5-8,
que contiene la codificacin de las seales de control en funcin 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-
reccin de comienzo de cada una de las cuatro microinstrucciones. De esta manera,
cada vez que se quiera ejecutar una nueva instruccin, tan slo hay que indicarle al
secuenciador que seleccione el salto a la direccin indicada por el cdigo de opera-
cin, para que desde sta salte a la zona correspondiente. Para el resto de los cuatro
fragmentos de cdigo simplemente se ha traducido cada estado de la mquina de
control de la Figura 5-20 en una microinstruccin.
22 21 20 19 15 14 o
SelSigDireccion SelCondcion SigDreccon Microordenes
Micrordenes 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 : FuenteDireccin SelCondicion
Bit 10: IncCP Bit 2 : HabilitaDireccn
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 microinstruccin de la Mquina Rudimentaria.
Direccin Microinstruccin
00000 O 11 00100 000000000000000

00001 O 11 01000 000000000000000 Decodificacin del campo CodigoOp.
00010 O 11 01100 000000000000000 Salto a la instruccin correspondiente
00011 O 11 10001 000000000000000
00100 O 10 00101 000000000000001

00101 O 00 00000 000001100000101
Instruccin de carga
00110 O 00 10000 000010000000001
00111 1 00 00000 000000010000101
01000 O 10 01001 000000000000001

01001 O 00 00000 000001100000101 Instruccin 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 Instruccin de salto
01111 1 00 00000 000000000000000
10000 1 00 00000 001000000000000
10001 O 10 10011 000000000000001

10010 O 00 00000 000001100000101 Instruccin de operacin
10011 O 00 00000 100010000100000 aritmtico-lgica
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 cmo el componente ROM acepta como gen-
ricos no slo el nmero de bits de datos y direcciones, sino tambin 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
-- Instruccin CARGAR
01000101000000000000001', -- 00100 Si BusLibre salta a 00101
00060060000001100000101, -- 00101 Busca instruccin
00000000000010000000001', -- 00110 Calcula direccin
100000000000000100oo10i, -- 00111 Carga dato
-- Instruccin ALMACENAR
010'01001000000000000001 , -- 01000 Si BusLibre salta a 01001
'09000000000001100000101', -- 01001 Busca instruccin
'00000000000010000000001, -- 01010 Calcula direccin
'10000000000000000001111', -- 01011 Almacena dato
-- Instruccin SALm
01001101000000000000001', -- 01100 Si BusLibre salta a. 01101
'00000000000001100000101', -'-01101 Busca instruccin
'00110000000000000000001, -- 01110 Evala la condicin de salto
10000000000000000000000, -- 01111 Condicin falsa
'10000000001000000000000' , -- 10000 Carga direccin si se da la condicin
\-
-- Instruccin OPERAR
'01010011000000000000001' , ,..,.:
lilQP1.Si BusLibre salt.a a 10011
'00000000000001100000101', ~..1001.{)Busca instruccin
'00000000100000000100000', -- 10011. Lee operando
'10000000010100011010000~, -- 10100 Ejecuta operacin
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 <= SigDreccion
else
DirSigMicroinst <= CMP
end if
wben "11" =>
DirSgMicroinst <= SigDireccion;
when others =>
DrSigMicroinst <= (others => 'X')
end case
when CODlGO_OP =>
DrSgMicroinst <= "000" & CodigoOp;
when others => "
DirSigMicroinst <= (others => 'X')
end case;
end process Secuenciador;
CargaRrM <= RMic{14)

CargaCP -ce .~c(13)
Carglll.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 ( ;,
HablitaMem .<= ~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 tambin un modelo para la
memoria de programas. Sin embargo, puesto que las memorias son un componente
habitual de todo tipo de sistemas electrnicos, 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 situacin. Para
ello se pasar como parmetros al modelo toda aquella informacin 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 mxima fidelidad su comportamien-
to real, para lo cual nos basaremos en una hoja de datos de una memoria
RAM tpica.
El objeto de este modelo no ser el de la fabricacin de esta memoria tras una
serie de etapas de refinamiento, puesto que dispositivos generalmente se adquieren
de uno de los mltiples proveedores. Sin embargo, ser necesario para poder rea-
lizar una simulacin realista del entorno en el que estar integrado nuestro disposi-
tivo (la Mquina Rudimentaria en nuestro caso). Por estas razones, el modelado de
este tipo de componentes estar nicamente enfocado a poder realizar una simula-
cin eficiente.
5.5.4.3.1. Descripcin del funcionamiento
En nuestro caso supondremos que existe en el mercado un componente estndar

que se ajusta a nuestras necesidades y cuyas caractersticas estn descritas en la Fi-
gura 5-24.
En el caso de un acceso para lectura, una vez colocada la direccin correspon-
diente en el bus de direcciones se activar la seal de habilitacin 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
direccin deber indicarse que la operacin es de escritura (activando a la baja
la seal Escribe). El dato a escribir ser el que se encuentre en ese momento en el
bus de datos.
5.5.4.3.2. Definicin de la entidad
Puesto que la memoria es un componente que probablemente tendremos oportuni-

dad de utilizar en otra ocasin, podra merecer la pena crear un modelo suficiente-
mente flexible y general como para permitir reutilizar su cdigo (una de las princi-
pales ventajas del modelado VHDL). En tal caso declararemos como valores gen-
ricos no slo el nmero de palabras de la memoria, y la anchura en bits de tales pa-
labras, sino tambin todos los parmetros temporales.
Dir Direccin vlida Direccin vlida
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 vlido
FIGURA 5-24. Cronograma de la memoria RAM.
library IEEE;
entity RAM is
generic (
Palabras integer .- 8; -- Nmero de palabras
BitsDir integer .- 3; Nmero de lneas de direccin
BitsPalabra integer .- 8; -- Nmero de bits por palabra
Fichero string .- "ram.txt"; -- Contenido de la memoria
TEstablDir: time .- O ns; Establecimiento de la direccin
TMantDir: time .- O ns; Mantenimiento de la direccin
TPulsoL: time .- O ns; Pulso mnimo de lectura
TPrecarga: time .- O ns Precarga mnima de la memoria
TPulsoE: time .- O ns; Pulso mnimo de escritura
TEstablL: time .- O ns: Establecimiento de la seal de lectura
TMantL: time .- O ns : -- Mantenimiento de la seal de lectura
TEstablE: time .- O ns; -- Establecimiento de la seal de escritura
TMantE: time .- O ns: -- Mantenimiento de la seal de escritura
TAcceso: time .- O ns; -- Acceso para lectura
TDatoValido: time .- O ns; -- Dato vlido
TEstablDato: time .- O ns; -- Establecimiento para escritura
TMantDato: time .- O ns); -- Mantenimiento despus 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 declaracin de la entidad de la memoria RAM,

existe un genrico adicional (Fichero) que tiene adems un valor por defecto. La
finalidad de este parmetro 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 ms sencilla y ms 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 ms rpida y compacta de almacenar la informacin. Por su-
puesto, esta aproximacin ser adecuada en el caso de que sean de pequeo tamao,
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 simulacin (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 mtodo
ms 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 := Valr * 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 := ';
redl ine W, Linear;
LeeHexadecimaltrich~io, Linea, 2, iDitecciol);
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 seal Habili taMem. En ese caso, de-
pendiendo del valor de la seal Escribe, se efectuar la operacin 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. Verificacin temporal

Una de las maneras ms utilizadas para modelar la verificacin temporal consiste
en definir un conjunto de procedimientos concurrentes, que supervisan la sincroni-
zacin entre las diferentes seales, sin afectar por ello a su funcionamiento. Sin em-
bargo, esta tcnica puede resultar costosa en tiempo de simulacin, puesto que el
rendimiento disminuye conforme aumenta el nmero de procesos que pueden eje-
cutarse concurrentemente.
Para facilitar la reutilizacin de estos procedimientos en otros modelos los
agruparemos en un nuevo paquete (VerificacionTerrporal). En el paquete se han
incluido los procedimientos necesarios para verificar:
el tiempo de establecimiento de una seal respecto a otra (VEstablecinento)
el tiempo de mantenimiento de una seal respecto a otra (1I2I1anteninento)
las anchuras mnimas de los pulsos de un ciclo (vCiclo).
El siguiente listado muestra solamente el cdigo correspondiente a la primera
funcin, puesto que las dems 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. Funcin de verificacin del tiempo de establecimiento.
Utilizando las funciones de este paquete, la verificacin 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~ls_
- 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
-- MaItenWento
if Dato' eVent aIId sscrbe '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~ seal 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 verificacin temporal en la memoria RAM.
5.6. EJERCICIOS
1. En la descripcin funcional del procesador no se incluye ninguna informacin

acerca del tiempo que tarda cada instruccin en ejecutarse. Sin embargo, a
pesar de que no existe una seal de reloj respecto a la cual definir ciclos, podra
almacenarse un hipottico. nmero de ciclos relacionado con cada cdigo de
operacin y, suponiendo un tiempo arbitrario para la duracin de un ciclo,
reflejar esta informacin en el tiempo de espera entre la ejecucin de dos ins-
trucciones. Modifique los tipos de datos existentes y aada los necesarios para
poder almacenar la informacin relativa a los ciclos de cada cdigo de opera-
cin. Posteriormente aada las variables y realice las modificaciones necesarias
en el cdigo para reflejar esta informacin en la simulacin.
2. La descripcin funcional del procesador podra haberse realizado suponiendo

que el nmero de bits de los registros y los datos son conocidos en lugar de uti-
lizar el tipo integer. Aada dicha informacin 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-

cin funcional del procesador nos obliga a reanalizar la arquitectura cada vez
que queremos simular la ejecucin de un programa distinto. Esto podra evitar-
se si en la etapa de inicializacin 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 precisin los cambios en la seal Inicializa que entra al procesa-
dor. Incluya las sentencias de control necesarias para que los procesos respon-
dan a una activacin de esta seal en cualquier momento y en no ms de un
ciclo de reloj se abandone la ejecucin de instrucciones y las variables y sea-
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 ms exhaus-
tiva la verificacin, modifique el proceso Arbi troBus de dicha arquitectura
para que exista un tiempo de espera entre la peticin de bus por parte del proce-
sador y la activacin de la seal BusLibre. Adems, haga que este tiempo de
espera vare de un ciclo a otro.
6. Las funciones del procesador que se repiten cclicamente, como los accesos al
bus de memoria, tienen una relacin causa-efecto y un orden en la activacin
de las seales que deben cumplirse para todos los ciclos. En estos casos es fcil
escribir un proceso en el banco de pruebas que verifique estas propiedades.
Escriba un proceso pasivo, es decir, que no asigne ninguna seal sino que slo
las lea, que compruebe los accesos a memoria del procesador.
7. Escriba un proceso similar al del ejercicio anterior pero que verifique que des-
pus de una instruccin de LOAD se realiza una lectura a memoria y que
despus de una instruccin 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 instruccin.
8. Una vez hemos realizado la comprobacin de la simulacin de forma visual,

podramos preparar un esquema de comprobacin automtica para que cuan-
do se realicen modificaciones en el modelo del procesador poder ver que
sigue comportndose de igual forma. Escriba un proceso en el banco de prue-
bas que a cada ciclo de reloj escriba los estmulos que se aplican a las entra-
das del procesador y los valores a las salidas correspondientes a los estmulos
aplicados en el ciclo anterior. Posteriormente podremos verificar la descrip-
cin comparando el fichero de la nueva simulacin con el de la simulacin ya
verificada.
9. Integre la funcionalidad de los componentes sumador y restador del modelo es-

tructural de la UAL en uno slo. Sintetice ambas versiones de la unidad opera-
tiva y compare los resultados en trminos de rea y velocidad de ambas imple-
mentaciones.
10. Sustituya el componente ROM de la implementacin 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 travs del valor de un parmetro adicional, pueda desactivarse la verifi-
cacin temporal.
12. Utilice un solo proceso para modelar la memoria RAM de programas, en el que
se incluya tanto la funcionalidad como la verificacin temporal. Simule el siste-
ma y compruebe cmo la reduccin del nmero de procesos mejora el rendi-
miento.
5.7. BIBLIOGRAFA
[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 modli-
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:Organizacin y Arquitectura de Computadores. Diseo para Opti-
mizar Prestaciones, Prentice-Hall, 1997.
[SPC97] F. SNcHEZ, E. PASTORY A. M. DELCORRAL(Ed: R. Hermida): Fundamentos de
Computadores (Captulos 6 y 7 del libro), Sntesis, 1997.
6
Captulo
LA GESTION
-
DEL DISENO
Y. Torroja, T. Riesgo, E. de la Torre, J. Uceda
Un error conocido
es una victoria ganada.
Annimo
En los captulos precedentes se ha mostrado cmo utilizar el VHDL y la

sntesis automtica para disear un circuito. Hasta el momento, el en-
foque ha sido fundamentalmente tcnico. Se han visto los diferentes
elementos del lenguaje VHDL, distintas maneras de describir el funcio-
namiento de un circuito, cmo realizar bancos de prueba, etc. Sin em-
bargo, el proceso de diseo en VHDL requiere un estudio no slo de
los aspectos tcnicos del diseo, sino tambin de los organizativos.
A menudo el diseador encuentra que tiene que realizar un buen
nmero de tareas adicionales a lo que es la mera descripcin del cir-
cuito en VHDL. Al enfrentarse a un diseo real, debe resolver proble-
mas relacionados con la planificacin del trabajo, la documentacin
del diseo, las herramientas que est utilizando, la organizacin de los
archivos, su relacin con el posible cliente, etc.
En el presente captulo se pretende dar una visin general de cules
son estas tareas y qu problemas conllevan. Se presenta el proceso de
diseo de un circuito, desde su concepcin hasta su fabricacin, mos-
trando cmo obtener el mejor partido de la utilizacin del VHDL en este
proceso. El objetivo del captulo es concienciar al lector de que el dise-
o de un circuito en VHOL no consiste slo en escribir cdigo, sino que
existen otros muchos aspectos a tener en cuenta, y que slo una buena
organizacin del diseo puede garantizar el xito final del mismo.
349
6. 1. INTRODUCCIN
Hasta la aparicin de los lenguajes de descripcin del hardware y, especialmente,

de las herramientas de sntesis lgica, el proceso de diseo de circuitos integrados
estaba basado fundamentalmente en la utilizacin de esquemticos. Las he-
rramientas de diseo disponan (y siguen disponiendo) de potentes editores gr-
ficos con los que realizar un esquema del circuito, bien fuese mediante bloques o
mediante puertas.
El diseo de un circuito con estas herramientas consista principalmente en un
proceso de diseo ascendente (bottom-up). En este procedimiento, el diseador de-
ba hacer sobre el papel una particin del circuito en bloques o unidades funciona-
les basndose en su experiencia previa. Cada uno de estos bloques era a su vez divi-
dido en unidades ms pequeas hasta alcanzar una complejidad manejable para rea-
lizar su representacin en un esquema.
As, por ejemplo, un circuito de transmisin/recepcin serie poda ser dividido
en el transmisor, el receptor y un bloque de control. Definidas las seales de control
y los datos que habran de comunicarse entre estos bloques, cada uno de ellos se di-
vidira en subbloques ms pequeos. El transmisor, por ejemplo, podra quedar di-
vidido en un generador del reloj de transmisin, una unidad de control con algunos
registros programables para configurar el modo de transmisin, un bloque de inter-
faz con el exterior con algn registro temporal para el dato a transmitir y un ltimo
bloque que se encargara de formatear el dato y de hacer la conversin paralelo/se-
rie para su transmisin.
Realizada esta particin comenzara el diseo de detalle de cada uno de estos
bloques. Mediante un editor de esquemticos el diseador ira dibujando el esque-
ma lgico de los bloques, dibujando puertas e interconectndolas y apoyndose se-
guramente en pequeos bloques funcionales previamente diseados (registros para-
lelos, registros serie, biestables con habilitacin, etc.).
Una vez diseado un bloque, ste podra ser simulado. El diseador deba en-
tonces utilizar un lenguaje o herramienta especfica del entorno de diseo para de-
finir los estmulos (las formas de onda) con las que comprobar el funcionamiento
del bloque recin diseado. Comprobado este bloque se procedera al diseo de los
dems bloques con el mismo procedimiento. Una vez diseados todos los bloques
se interconectaran entre s para formar un bloque mayor (p. ej., el transmisor) y se
procedera a su simulacin, repitiendo este proceso hasta completar el circuito
completo.
El problema fundamental de este mtodo de diseo es que no era posible simu-
lar el comportamiento completo de cada uno de los bloques hasta no haber diseado
los subbloques que lo integran. A menudo el diseador encontraba que la particin
realizada, las seales de comunicacin entre cada uno de los bloques, la especifica-
cin, o su propio entendimiento de lo que deba ser el funcionamiento de un bloque
no eran los adecuados. Esto poda requerir de un rediseo total o parcial de alguno
o varios de los bloques, o incluso de una nueva particin del circuito. Para resolver
estos problemas se incluan a menudo funcionalidades en los bloques que no eran
estrictamente necesarias, se repeta lgica que ya estaba en algn otro bloque. o se
realizaban complicados protocolos de comunicacin entre bloques.
6. La gestin del diseo 351
Por tanto, el proceso de diseo resultaba engorroso y las modificaciones, la de-

puracin y el mantenimiento del diseo complejos de realizar. Una mala planifica-
cin del diseo podra hacer, por ejemplo, que se repitiesen los bloques de genera-
cin del reloj del transmisor/receptor planteado como ejemplo. Si, por otro lado,
tras el proceso de diseo fsico y obtencin de la topografa (layout) se detectaban
errores debidos a retardos o problemas de rea, las modificaciones resultaban com-
plejas y de difcil solucin.
La aparicin de los HDLs (Hardware Description Languages, o lenguajes de
descripcin del hardware) y de las herramientas de sntesis lgica ha venido a paliar
en gran medida estos problemas. Por una parte, ha liberado al diseador de la tedio-
sa, y a menudo repleta de errores, tarea de diseo lgico, que queda a cargo de las
herramientas de sntesis. Por otro lado, y ste es quizs el aspecto ms importante,
permiten al diseador utilizar un mtodo de diseo descendente (top-down). Con
este proceso de diseo el diseador puede simular el comportamiento del circuito
completo antes de realizar la particin y entrar en el detalle del diseo de cada uno
de los bloques. Realizando un modelo funcional sencillo de un bloque, el diseador
puede comprobar que la integracin de ste en el resto del sistema es la adecuada.
La inclusin de nuevas seales de comunicacin con los dems bloques, o nueva
funcionalidad, puede realizarse de una manera mucho ms sencilla y a menor coste.
El diseador va definiendo, describiendo y, lo que es ms importante, simulando el
comportamiento deseado para cada una de las partes. Posteriormente entra en el de-
talle de cmo realizar, mediante la lgica 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 diseo. Existe una notable diferencia entre las posibilidades
tericas y reales que los HDLs y la sntesis automtica ofrecen. El diseador se en-
frenta a nuevos problemas debidos fundamentalmente a la integracin de las nuevas
herramientas en los entornos de diseo y al aumento de la complejidad de los cir-
cuitos que estas herramientas permiten realizar.
A continuacin se describen brevemente cules son los nuevos problemas a
los que el diseador tiene que enfrentarse, comparando lo que sera un proceso
ideal de diseo basado en VHDL y sntesis automtica y la realidad. Posteriormen-
te, el resto del captulo estar dedicado a proponer procedimientos y mtodos que
permitan paliar, en la medida de lo posible, los efectos negativos que estos proble-
mas inducen.
6.1.1. Un proceso ideal de diseo en VHDL
En un proceso de diseo ideal en VHDL el diseador debera disponer de unas es-

pecificaciones estables. Esto evitara modificaciones constantes en el proceso de di-
seo que aumentan en gran medida el coste del desarrollo. En el mejor de los casos,
el diseador podra disponer de un modelo simulable en VHDL del entorno en el
que el circuito va a estar incluido. De esta manera, el diseador siempre dispondra
de un banco de pruebas realista con el que poder simular su diseo a lo largo del
proceso de desarrollo.
Las herramientas de diseo deberan permitir al diseador disponer de modelos

VHDL de su diseo a lo largo de todo el proceso. Por ejemplo, tras la sntesis, dis-
pondra de un modelo VHDL estructural del circuito en puertas, que le permitira
realizar la simulacin del circuito con los mismos bancos de prueba que utiliz en
las etapas previas del proceso de diseo, y considerando las caractersticas reales de
los componentes (retardos, consumo, etc.). Para ello, las bibliotecas del fabricante
dispondran de modelos VHDL detallados de todos sus componentes.
Por otro lado, las herramientas de sntesis tendran en cuenta la biblioteca del
fabricante para seleccionar, en cada caso, el componente ms adecuado para rea-
lizar la funcionalidad especificada por el diseador, teniendo en cuenta el coste
y las prestaciones. Las macroceldas (memorias RAM, ROM, multiplicadores,
PLAs, etc.), se generaran de forma automtica cuando fuesen necesarias, y sus mo-
delos VHDL se integraran bajo el diseo para poder simular, de forma sencilla, el
circuito completo.
Por ltimo, si el diseador se dedicase a las tareas de diseo fsico hara la ubi-
cacin y el conexionado (place & route), para obtener la topografa, tras lo cual
realizara una simulacin del circuito final, todo sin salirse del entorno VHDL al
que est acostumbrado. Las modificaciones que, por cualquier razn, el diseador
realizase sobre el circuito final (un inversor puesto a ltima hora para corregir la
polaridad de una seal, una modificacin de la topografa para corregir retardos, et-
ctera), quedaran retroanotadas en el diseo, de forma que su efecto se viese refle-
jado en los distintos modelos VHDL que se hubieran ido obteniendo segn se fue
depurando el diseo.
6.1.2. El proceso real de diseo 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 sera un proceso de dise-
o fluido y sin complicaciones.
Por un lado, las especificaciones nunca son estables. A menudo la idea del di-
seo sufre cambios a lo largo del proceso de desarrollo que obligan a rehacer parte
del diseo. Por otro, no es frecuente que el diseador disponga de modelos simula-
bles del entorno, lo que le obliga a desarrollarlos, duplicando el trabajo y las fuentes
de errores. Adems, la complejidad alcanzada en los diseos actuales hacen ne-
cesaria una importante tarea adicional de gestin global del diseo que hasta ahora
se daba en contadas ocasiones. Los equipos de diseo 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 validacin de la funcionalidad se vuelve una
tarea compleja debido al gran nmero de modos de funcionamiento de los circui-
tos y de solicitaciones a los que se les somete. El tiempo de simulacin se con-
vierte entonces en uno de los principales problemas para el diseador, que tiene
que esperar a que terminen largas simulaciones para analizar los resultados. Es
frecuente, como ocurre en el caso del diseo de un microprocesador, que el mode-
lo de simulacin del circuito tenga que ejecutar largos programas en un entorno vir-
tual para verificar sus respuestas ante situaciones que de otra manera seran difciles
de comprobar (p. ej., cmo responde un microprocesador a un sistema operativo
multitarea).
Adems, la integracin de las herramientas bajo un mismo entorno no slo deja
que desear, sino que, en muchos casos, est desapareciendo como concepto. Actual-
mente, distintos vendedores de CAD estn ofreciendo herramientas que cubren dis-
tintas partes del proceso de diseo; especificaciones, diseo arquitectural, sntesis,
diseo fsico, etc. La tendencia actual es que estas diferentes herramientas inter-
cambien informacin entre ellas a travs de un lenguaje comn (VHDL o Verilog
en la mayora 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-
duccin para intercambiar informacin entre ellas. En estos casos, se dificulta an
ms la retroanotacin de las modificaciones hechas en una etapa posterior del pro-
ceso de diseo sobre los datos de etapas anteriores.
Por ltimo, puesto que los circuitos electrnicos ya no aportan, de por s, valor
aadido a un producto, sino que es su funcionalidad la que les da ese valor, el cos-
te de diseo se ha vuelto un factor importante en el coste final del producto, coste
que es necesario reducir. Esto obliga a reutilizar parte de los diseos realizados, lo
que, a su vez, requiere poner un cuidado especial en la manera de disear. Los di-
seos deben realizarse de forma que otros diseadores puedan entenderlos y modi-
ficarlos con poco esfuerzo para adaptarlos a sus necesidades. Esto requiere tam-
bin que se preste una atencin especial a la documentacin del diseo, que acaba
siendo un porcentaje no despreciable del tiempo dedicado al desarrollo de un dis-
positivo.
6.1.3. Orientacin y objetivos del captulo
En los siguientes apartados se propondrn mtodos y procedimientos que ayuden a

paliar los problemas planteados, mostrando los puntos donde aparecen conflictos y
ayudando a extraer las mximas ventajas del proceso de diseo basado en VHDL y
sntesis automtica.
En primer lugar, se exponen, con cierto detalle, las diferentes tareas que un di-
seador ha de llevar a cabo para realizar un diseo, desde el planteamiento de la
idea hasta la fabricacin del circuito. El proceso de diseo 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 debera adaptarse a las ca-
ractersticas del equipo de diseo, tanto desde el punto de vista de las herramientas
disponibles como de la experiencia de los diseadores y la propia complejidad del
diseo a realizar. Posteriormente se detallan aspectos relativos a la organizacin,
gestin y desarrollo de las bibliotecas de componentes, donde deben quedar archi-
vados los diferentes elementos que se van realizando durante el diseo. Por ltimo,
se exponen mtodos para realizar diseos que sean fcilmente reutilizables. Se deta-
llarn cules son los problemas que surgen al reutilizar un componente previamente
diseado y se explicarn dos procedimientos (diseo genrico y configurable) para

realizar diseos reutilizables. En los ejemplos y explicaciones se ha considerado, en
general, que se estn realizando diseos sncronos. La realizacin de diseos asn-
cronos, aunque conceptualmente similar, presenta particularidades que dificultaran
el seguimiento del texto. Por otro lado, la gran mayora de los circuitos que se dise-
an en la actualidad son sncronos.
Este captulo est orientado no slo hacia personas que comienzan a utilizar el
VHDL y la sntesis automtica, sino tambin a aquellos que ya poseen alguna expe-
riencia en diseo. El contenido de este captulo no es, ni mucho menos, exhaustivo.
Si se desea una informacin ms detallada sobre estos temas puede recurrirse a dis-
tintas referencias de la bibliografa, en especial a la metodologa PRENDA para el
diseo de ASICs.
6.2. PLANIFICACIN DE UN DISEO DESCENDENTE
En el presente apartado se plantea, en primer lugar, lo que podra ser un flujo de di-
seo tpico aplicado al desarrollo mediante VHDL y herramientas de sntesis lgica,
describiendo brevemente las tareas a realizar en cada etapa. A continuacin se entra
en detalle en cada una de las etapas que componen el proceso de diseo. Se mues-
tran cules son los objetivos de cada etapa y cmo llevarlos a cabo, pormenorizan-
do los problemas que a menudo aparecen durante el diseo. Se presta especial aten-
cin 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 atrs.
Como se ha explicado en la introduccin al captulo, la documentacin del diseo
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, cmo aplicar las re-
comendaciones dadas al desarrollo de un circuito, especialmente cuando estas reco-
mendaciones afectan a la escritura del cdigo VHDL o a su sntesis. Los ejemplos
mostrados se han llevado a cabo utilizando herramientas de simulacin y sntesis
comerciales, y podran no ser aplicables en todos los casos. De cualquier manera,
stos deben servir como gua para que el lector adquiera una visin general de los
problemas y de cmo solucionarlos; la adaptacin de estos ejemplos a sus herra-
mientas concretas no debe suponer un gran esfuerzo.
Conviene tener en cuenta que la aplicacin de un flujo de diseo requiere un
esfuerzo adicional al puramente tcnico. Es necesario valorar la complejidad del
circuito antes de considerar la aplicacin de los procedimientos que se muestran en
este apartado. El diseo de un circuito pequeo (2.000 o 3.000 puertas), realizado
por un solo diseador, puede no requerir este tipo de procedimientos, aunque siem-
pre es conveniente llevar un cierto control sobre el proceso. En un diseo algo ms
grande (10.000 a 20.000 puertas), generalmente llevado a cabo por ms de un dise-
ador, la aplicacin de estos mecanismos suele aportar ms ventajas que inconve-
nientes. Por ltimo, en diseos mayores o crticos, donde el nmero de participantes
y complejidad aumenta, el seguimiento detallado de un flujo de diseo es la nica
manera de llevar a buen trmino 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 diseo
El desarrollo de un circuito integrado, como el de cualquier otro producto, requiere

que se vayan realizando diferentes tareas. Desde la concepcin de la idea hasta su
materializacin final, el circuito va pasando por diferentes fases en las que se van
definiendo, cada vez con ms 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 diseo establece las etapas que se deben cubrir y las tareas a realizar
en cada etapa, as como las herramientas y mtodos 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 categora de pro-
yecto) hasta disear un superordenador, siguen un proceso de desarrollo ms 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 frerla, el aceite no est sufi-
cientemente caliente, o si hay demasiado aceite. Siempre podremos calentar el acei-
te despus de batir los huevos, pero ahorraremos tiempo si lo hacemos al mismo
tiempo. El flujo de diseo en este caso es sencillo; abrir la nevera, coger un huevo,
poner a calentar el aceite, batir el huevo (no olvidarse de la sal), frer 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 diseador (en este caso el coci-
nero) dependen el xito del proyecto y el tiempo empleado en llevarlo a cabo.
Disear un circuito integrado no es, evidentemente, como la tarea de hacer una
tortilla (aunque a algunos nos puede resultar ms difcil este proyecto), pero com-
parte con ella muchas caractersticas; las tareas deben estar correctamente secuen-
ciadas, muchas de ellas pueden realizarse en paralelo y a menudo cada etapa requie-
re un proceso de evaluacin tras el que se decide si el resultado es o no correcto
(fremos 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 ms al final). Un buen proceso de dise-
o debe considerar todos estos casos para dar la mejor solucin, evitando que se
produzcan situaciones irreversibles.
Existe un gran nmero de flujos de diseo que tienen en cuenta las caractersticas
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 diseo como
el mostrado en la Figura 6-1 da buenos resultados en la mayora de las ocasiones.
:"" - -- -- -- _. -...t
FIGURA 6-1. Flujo de diseo 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 tcnica y econmica 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 diseador.
Etapa de especificaciones: analizada la viabilidad de la idea, tanto desde

su punto de vista tcnico como econmico, y determinada con ms 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 nmero de entradas/salidas, la tensin de alimentacin, 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
adems el mtodo de trabajo, las herramientas a utilizar, la particin del tra-
bajo, etc.
Etapa de diseo arquitectural: esta es normalmente la primera etapa de di-

seo en VHDL. Tras llevar a cabo la particin del circuito en bloques funcio-
nales manejables, el diseador los describe en VHDL y los simula. Durante
esta etapa se desarrollan otros elementos fundamentales del diseo: los ban-
cos de prueba. stos sern utilizados repetidamente en todas las etapas poste-
riores del desarrollo. La etapa de diseo arquitectural es, generalmente, la
etapa ms crtica del proyecto, por lo que a menudo tambin es la ms larga
y la que ms esfuerzo requiere.
Etapa de diseo lgico o detallado: esta etapa est orientada fundamental-
mente a la sntesis del circuito. Para ello puede ser necesario realizar modifi-
caciones en el cdigo VHDL desarrollado, con objeto de adaptarlo a las
herramientas de sntesis disponibles o de corregir soluciones del diseo
arquitectural que sean inadecuadas en cuanto a rea o retardos. A menudo es
necesario que exista cierta interaccin entre la etapa de diseo arquitectural y
lgico, de manera que los resultados de la sntesis ayuden a tomar decisiones
en cuanto al diseo arquitectural del circuito. Durante esta etapa tambin se
generan los estmulos para realizar el test de fabricacin, si es que ste es ne-
cesario.
Etapa de diseo fsico: finalizadas las tareas de diseo lgico, se procede al
diseo fsico del circuito. En esta fase se lleva a cabo la ubicacin y conexio-
nado del circuito, se extraen sus caractersticas reales (capacidades parsitas
debidas a las puertas y pistas de interconexin) y se simula el circuito com-
pleto con estos datos. Esto permite obtener resultados realistas en cuanto a
cmo se va a comportar el circuito.
Etapa de fabricacin: 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 fabricacin para comprobar que sta ha sido correcta.
Etapa de validacin: con los prototipos del circuito se realiza la validacin
final del diseo, comprobando que su funcionamiento es el adecuado una vez
instalado en el sistema final. De ser as, se puede pasar a la produccin en se-
rie del diseo. Tambin se realiza en esta etapa la caracterizacin del circui-
to, para poder as elaborar las hojas de caractersticas del mismo.
Este es un flujo de diseo lineal. Cada etapa requiere un proceso de revisin,

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 diseo resulta, sin
embargo, demasiado rgido para la mayora de los diseos de circuitos. A menudo
es necesario conocer caractersticas del diseo que no se sabrn con detalle hasta
etapas posteriores. El coste final del circuito podra ser, por ejemplo, el factor fun-
damental de un proyecto, pudiendo llegarse a eliminar o aadir ms lgica al circui-
to en funcin de esto, pero el coste final no se conoce con detalle hasta que se reali-
za el diseo fsico. Esto implicara un proceso cclico en el que hay que terminar el
diseo 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-
sin, implicara en este caso un coste excesivo, por lo que es necesario plantearse
un flujo de diseo algo ms flexible que permita entrar en una etapa sin haber ter-
minado la anterior. As, podramos empezar con el diseo fsico de alguna parte del
circuito sin haber siquiera completado la etapa de diseo arquitectural (o incluso
antes). De esta manera podramos hacernos una idea del coste final del circuito,
ajustando la funcionalidad a la vista de los resultados.
La Figura 6-2 muestra grficamente esta idea. El grado de solapamiento y la
duracin de las etapas vara segn cada proyecto. Tambin puede apreciarse una ta-
rea global de gestin, que discurre a lo largo de todo el proyecto, y que no estaba
explcita en el flujo de diseo de la Figura 6-1. Disponer de un flujo de diseo flexi-
ble facilita la resolucin de estos problemas, aunque debe existir un cierto compro-
miso entre flexibilidad y control del proceso de diseo.
Un ltimo aspecto importante del flujo de diseo es que permite, cuando se de-
sarrollan circuitos de forma habitual, detectar dnde estn 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 diseo 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 diseo, es necesario buscar los
procedimientos para automatizar, en el mayor grado posible, las tareas a realizar.
Como se ha visto, la mayora de las tareas que se llevan a cabo son cclicas; se repi-
ten una y otra vez hasta alcanzar el resultado deseado. Este proceso cclico es mu-
cho ms acusado durante las etapas de diseo arquitectural, lgico y fsico. En estos
casos es especialmente importante disponer de mecauismos de automatizacin de
las tareas. Durante la etapa de diseo arquitectural, por ejemplo, es muy convenien-
te tener mtodos para realizar la compilacin del cdigo VHDL, su simulacin y
D~se~oarquitectural
Fabricacin I
I Validacin
Gestin del proyecto
FIGURA 6~2. Ejemplo de distribucin temporal de las etapas de diseo de un cir-

cuito integrado.
comparacin de los resultados de forma automtica. Durante la etapa de diseo l-

gico, es adems interesante automatizar los procedimientos de sntesis, que a menu-
do requieren un elevado nmero de pasos y condiciones que fijar (retardos mxi-
mos permisibles, rea que se quiere conseguir, etc.).
La automatizacin de las tareas en cada etapa del diseo no slo permite aho-
rrar tiempo al diseador, sino que adems supone una garanta de que no se olvida
ningn paso en el proceso. Por otro lado, los ficheros que a menudo hay que utilizar
para automatizar las tareas sirven posteriormente como documentacin 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-
seador. Consideraremos como cliente aquella persona o empresa que desea realizar
un circuito. Es l quien decide cul es la funcionalidad final que debe incluir el cir-
cuito, decide quin debe disearlo, si el coste es adecuado, quin lo fabricar, etc. El
diseador ser la persona o equipo de personas encargados de llevar a cabo el desa-
rrollo, escribir el cdigo VHDL, realizar las simulaciones, el diseo fsico, etc.
Cliente y diseador podran ser la misma persona o la misma compaa; lo impor-
tante no es quin realiza estas tareas, sino tener claro las tareas que hay que realizar.
A menudo, por ejemplo, el cliente se ayuda del diseador para escoger al fabricante
o la tecnologa de los circuitos, decidir la funcionalidad que incluir, calcular el cos-
te, etc. En la mayora de los casos, el nmero 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 propsito del ca-
ptulo es suficiente, y ms sencillo, considerar slo las figuras de cliente y diseador.
Puede consultarse la bibliografa para obtener informacin ms extensa sobre estos
aspectos.
6.2.2. De los requisitos a las especificaciones
El objetivo de las etapas de requisitos y especificaciones es la definicin de lo que

debe ser el circuito a desarrollar. Esta definicin debe convertir la idea original en
un documento donde se detallen las seales que requiere el circuito y su comporta-
miento, tanto desde el punto de vista funcional como desde el punto de vista fsico
(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 caractersticas 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 an est poco definido y que, por tanto, '
puede' modificarse segn sea necesario. Un caso tpico podra ser el circuito para
controlar el expendedor de latas de refresco del ejemplo mostrado en el Apndice 1.
Las funciones que realice el circuito dependern no slo de las necesidades funcio-
nales, sino tambin de coste final y la facilidad de desarrollo. As, por ejemplo, po-
dramos pensar que el expendedor de refrescos pudiese incluir una pantalla de visua-
lizacin donde mostrar los precios ms o menos compleja, aceptar ms o menos ti-
pos de monedas o que pudiera expedir ms de un tipo de producto en una sola opera-
cin (jsi se ha introducido suficiente dinero, claro est!). Escoger una solucin u otra
depende de multitud de factores, y generalmente requiere un anlisis de viabilidad
tcnica y econmica complicado para encontrar la mejor solucin. Este anlisis no
slo incluir los aspectos relacionados con el circuito a desarrollar, sino tambin los
relacionados con el coste de los dems elementos del sistema, la facilidad de fabri-
cacin, la funcionalidad de nuestra mquina respecto a otras que existan en el merca-
do, etc. El desarrollo de los requisitos consistir entonces en un proceso cclico en
donde la idea inicial se va depurando en funcin de los anlisis que se vayan reali-
zando. El principal objetivo en este caso es identificar, a grandes rasgos, cul es la
funcionalidad bsica 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.
Ms sencillo resulta el desarrollo de los requisitos en el caso de un circuito cu-
yas condiciones de contorno estn ms definidas. Volviendo al ejemplo del expen-
dedor de refrescos, podramos 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, tnica, naranja y cerveza), cuyos precios pudiesen fijarse
mediante cuatro pulsadores exteriores (evidentemente slo accesibles por el dueo
de la mquina) en unidades de 25 pesetas y que admitiese hasta un mximo de 50
latas por producto. Los precios podran mostrarse mediante un visualizador de tres
dgitos de siete segmentos y los clientes dispondran de cuatro pulsadores para se-
leccionar el producto y un pulsador para la devolucin de monedas. En estos casos
el desarrollo de los requisitos requiere un anlisis menos detallado, puesto que la
funcionalidad bsica est definida.
En cualquier caso, los requisitos deben plasmar en un documento no slo la fun-
cionalidad del circuito, sino tambin el coste estimado del circuito a desarrollar, el
tiempo de desarrollo, su tamao y caractersticas tecnolgicas, como son la tensin
de alimentacin, consumo, temperaturas mximas y mnimas que debe soportar, etc.
Todos estos aspectos quedan recogidos en el Documento de Requisitos, que ac-
ta como texto base para iniciar el proyecto. Si la empresa que va a realizar el pro-
ducto (la mquina de refrescos) no dispone de centro de diseo, este documento se-
r distribuido entre varios centros de diseo para que hagan una evaluacin tcnica
y econmica del circuito a desarrollar y oferten un presupuesto a travs de una Pro-
puesta de Desarrollo. Esta propuesta incluye normalmente un plan para el desarro-
llo del circuito, una descripcin de la funcionalidad de la propuesta presentada, una
estimacin del tiempo de diseo y del coste del desarrollo, estimaciones sobre el
coste final del producto, posibles modificaciones a los requisitos del cliente, etc. En
funcin de esta propuesta el cliente escoger el centro de diseo que ms 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 bsico del documento de requisitos
Documento de requisitos
Presentacin del cliente

Presentacin de la aplicacin
Descripcin de la aplicacin
Mercado
Justificacin de la necesidad del ASIC
Posibilidad de reutilizacin del diseo
Descripcin del entorno del ASIC
Descripcin de la funcionalidad del ASIC
Restricciones del ASIC
Documentacin 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 concrecin de la idea original y de la experiencia, tanto del
cliente como del diseador, 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 Apndice 1 se muestra 10 que
podra ser un Documento de Requisitos sencillo para la mquina de refrescos del
ejemplo. Para simplificar la exposicin, supondremos que cliente y diseador 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 diseo pueden no estar
an definidos (de hecho, esta ser la situacin ms habitual). En estos casos, con-
viene dejar claramente explcitos los puntos no definidos, de forma que posterior-
mente pueda comprobarse que se ha dado respuesta a todos los interrogantes que
inicialmente tena el proyecto.
TABLA 6-2. Esquema bsico de la propuesta de desarrollo
Propuesta de desarrollo
Descripcin de la propuesta y cumplimiento de requisitos

Plan de desarrollo preliminar
Cumplimiento de plazos
Mtodos de control y verificacin
Coste del diseo y/o fabricacin del ASIC
Alternativas o sugerencias del diseador
La etapa de requisitos, como cualquier otra etapa, tiene un proceso de revisin

final donde se aprueban los requisitos. Sin embargo, la revisin de esta etapa no re-
sulta un proceso tan formal como lo sern las revisiones de las etapas posteriores
del proyecto. Habitualmente, esta revisin consiste en un contrato o acuerdo de co-
laboracin entre el cliente y el diseador, y en un anlisis conjunto del trabajo reali-
zado para limar los ltimos detalles. Esta revisin suele llevarse a cabo mediante
una reunin 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 tcnicos: funciones bsicas que debe realizar el circuito, estima-

cin del consumo, frecuencia mxima de funcionamiento y tamao.
Aspectos econmicos: estimacin del coste objetivo del producto, coste de
los prototipos y coste del desarrollo.
Aspectos organizativos: planificacin 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 descripcin detallada del circuito

a disear, tanto desde el punto de vista funcional (lo que debe hacer, patillaje, etc.),
como desde el punto de vista tecnolgico (tecnologa a utilizar, tensin de alimenta-
cin, consumo, etc.). Esta es una de las etapas crticas del proyecto; de la precisin
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 redaccin suele quedar a cargo del director del equipo de
diseo, al ser ste habitualmente el componente ms experto del equipo de diseo.
Las especificaciones deben ser completas, claras, concisas y sin ambigeda-
des. Los problemas con las especificaciones surgen, precisamente, debido a impre-
cisiones, falta o redundancia en la informacin, datos incorrectos o descripciones
ambiguas o difciles de interpretar. La utilizacin de lenguajes de descripcin 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 mtodos que resuelvan los problemas
planteados.
Unas especificaciones ideales deberan permitir al diseador trabajar indepen-
dientemente del cliente. En la prctica esto nunca es cierto, y tampoco es conve-
niente; una buena comunicacin entre cliente y diseador, tanto a nivel tcnico co-
mo empresarial, es la mejor garanta 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 diseo ms libre de problemas.
En los siguientes apartados se comparar lo que seran unas especificaciones idea-
les con lo que suelen ser unas especificaciones reales. Con ello se pretende resaltar
cules son las fuentes de problemas y cmo se pueden limitar sus consecuencias.
6.2.2.2. 1. Unas especificaciones ideales

Los circuitos electrnicos son elementos que, sometidos a ciertas solicitaciones ex-
ternas (cambios en sus seales de entrada), reaccionan realizando ciertas acciones
(cambios en las seales de salida). Visto de esta manera, la especificacin de un cir-
cuito puede entenderse como una descripcin de cul es la secuencia de cambios
que se debe producir en las seales de salida del circuito ante ciertos cambios en las
entradas. En este sentido, una especificacin podra 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 especificacin de este estilo sera
inutilizable, ya que, aparte de ser ilegible, requerira de infinidad de pginas para
incluir todos los posibles casos.
Utilizando VHDL, sin embargo, es posible especificar casi completamente el
funcionamiento y caractersticas 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
sera realizando una descripcin 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 cmo debe responder ante una serie de estmulos
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 ~ecnolgicos:

attribute tecno~ia of mi.,..circuito : entity is "CMOS-O.Su;
attribute tens~6nVdd of mi'"rcif~~ito : entity is 3.3 ,:
--i ~igUiht'e proceso s'uthik ~ra veriar1a' &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
Cumta <= 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. Especificacin de un circuito mediante descripcin VHDL. Compor-

tamiento interno.
En la descripcin mostrada es posible leer, con un poco de prctica, cmo debe

funcionar el circuito que se desea realizar. Esta es adems una descripcin simula-
ble, lo que implica que el diseador puede utilizarla para comparar los resultados de
su diseo con los de la especificacin. La descripcin no hace explcito cmo debe
disearse el circuito (eso es una tarea a realizar durante el diseo arquitectural). De
hecho, se especifica que debe haber un reloj de entrada de 10 MHz, pero no se deta-
lla cmo se utiliza en el circuito.
Se podra tambin especificar el funcionamiento del circuito de "patillas afue-
ra", es decir, mostrando cmo son las salidas que debe dar en funcin de una serie
de entradas. Un ejemplo de este mtodo 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. Especificacin de un circuito mediante VHDL. Comportamiento vis-

to desde el exterior.
En el ejemplo se han descrito una serie de seales y procedimientos que permi-

ten generar los eventos y verificar si la respuesta del circuito diseado es la adecua-
da. En realidad se est describiendo un banco de pruebas para el circuito que verifi-
ca, de forma automtica, 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 diseador,
que puede interpretar, ayudado por las simulaciones, el cdigo VHDL. Sin embar-
go, tal y como puede desprenderse del cdigo, aunque puedan resultar unas especi-
ficaciones completas y sin ambigedades, su interpretacin no es sencilla. Esto
contradice una de las caractersticas 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 cdigo VHDL que
simulara la respuesta del microprocesador ante una serie de programas tipo. El dise-
ador podra comprobar si su diseo es o no correcto pero, con toda seguridad, sera
incapaz de realizar un circuito que se comportase de esa manera, ya que le resulta-
ra prcticamente imposible identificar la funcionalidad con la lectura del cdigo o
el anlisis de las simulaciones. Por otro lado, las especificaciones en VHDL no pue-
den cubrir todos los aspectos del diseo (especialmente en cuanto a la especifica-
cin de las caractersticas tecnolgicas) y, en la mayora de los casos, su desarrollo
resulta extremadamente complejo.
Unas buenas especificaciones deben contener, sobre todo, una descripcin cla-
ra y completa de 10 que se desea disear. Para ello son de gran utilidad los grficos,
cronogramas, diagramas de estados y, principalmente, una buena descripcin tex-
tual. En este sentido, debe intentarse que sta sea 10 ms escueta posible, evitando
redundancias, sin que por ello se omita informacin. Adems, las especificaciones
deben estar cenadas, ya que los cambios en las especificaciones producen rediseos
constantes y son causa habitual de malentendidos. Las especificaciones deberan es-
tar escritas de forma que pueda comprobarse que se cumplen todas las condiciones
y funcionalidades incluidas en el documento.
Las especificaciones ideales seran aquellas que se mantuviesen estables a lo
largo del proceso de diseo. Su contenido sera suficiente para que el diseador tra-
baje sin necesidad de consultar al cliente. Aparte de la descripcin textual de la fun-
cionalidad y aspectos tecnolgicos, contendran un modelo VHDL del entorno del
circuito. Este modelo no slo emulara las seales de entrada al circuito a disear,
sino que adems respondera adecuadamente a las respuestas del circuito. De esta
manera, el diseador podra realizar las simulaciones del sistema completo sin tener
que desarrollar los bancos de prueba. Con ello se evitara 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 diseo
de un contador de (} a 15; el diseador podra realizarlo para que contase de O a 14,
y hacer los bancos de prueba que comprueban esta cuenta; evidentemente, no sera
consciente del error),
6.2.2.2.2. Las especificaciones reales

En la prctica, las especificaciones adolecen de multitud de defectos. En primer lu-
gar, las especificaciones nunca (o casi nunca) son estables. La falta de informacin
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 podran ser beneficiosos para el diseo (se dice que el diseo est so-
breespecificado) . Como ejemplo podramos fijarnos en el circuito de la Figura 6-3
(vl.0), que se corresponde con la especificacin inicial del expendedor de refrescos
del Apndice 1 (ver la especificacin completa en el apndice). 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 DspUnidad
BotPVPlncre DispDecena InteModo DlspDecena
BotPVDecre DispCentena Monedalnt DispCentena
Monedalnt
FIGURA 6-3. Diferentes versiones con la misma funcionalidad.

entre otras, de cuatro seales de entrada para fijar el precio de cada producto (Prec-
Prodx) y otras cuatro seales para la seleccin del producto (BotProdx). En un an-
lisis posterior se podra llegar a la conclusin de que mientras se est fijando el pre-
cio de cada refresco no se estn expediendo refrescos. Podran entonces utilizarse
las mismas seales de seleccin para fijar el precio del producto, existiendo una se-
al inteModo que cambiara entre operacin normal y operacin de cambio de pre-
cio (v2.0). De esta manera ahorraramos tres entradas al circuito, pudindose 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 anlisis ms detallado o que
son funcin 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 diseo del circuito puede comenzarse y fijar esos detalles ms
adelante. En otras ocasiones las especificaciones resultan incompletas simplemente
porque se olvidan algunos detalles.
Por otro lado, aparecen a menudo contradicciones o ambigedades que son di-
fciles de detectar en las etapas iniciales del proyecto. Estas ambigedades pueden
ser debidas a errores de redaccin, imprecisiones o conocimiento poco detallado de
lo que posteriormente ser el circuito. En nuestro sencillo ejemplo podra ocurrir
que, puesto que el importe de los productos se especifica en unidades de 25 pesetas,
no se hubiese previsto la devolucin de monedas de 5 pesetas. Se estara suponien-
do con ello que el usuario de la mquina no va a introducir, por ejemplo, 155 pese-
tas para pedir un refresco que cuesta 125. Pero dicha situacin, aunque poco proba-
ble, es posible, y podra dar al traste con el diseo.
Por ltimo, la redaccin de las especificaciones no es siempre lo clara que sera
deseable. Debe prestarse una especial atencin a este aspecto, intentando evitar fra-
ses largas y de difcil comprensin. La inclusin de grficos y diagramas puede
ayudar en gran medida a conseguir este objetivo. Sin embargo, debe tenerse en
cuenta que la interpretacin del texto, diagramas y grficos puede ser diferente se-
gn quien los lea. Esta fue precisamente una de las razones por las que el DoD pro-
puso la creacin de un lenguaje estndar para la descripcin de circuitos integrados,
el VHDL.
El contenido y organizacin del Documento de Especificaciones puede variar
notablemente dependiendo del tipo de circuito y aplicacin que se est consideran-
do. Sin embargo, existen una serie de puntos que siempre aparecern. La Tabla 6-3
muestra un esquema tpico 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 mtodos para que estos cambios no repercutan de forma negativa
en el proyecto. Estos mtodos van desde el control de versiones y cambios, que per-
mite a todos los participantes en el proyecto estar al da de las ltimas modificacio-
nes, hasta los procedimientos de diseo genrico, que facilitan los cambios de lti-
ma hora de forma rpida y con poco esfuerzo. Estos procedimientos sern expuestos
en posteriores apartados de este captulo.
TABLA 6-3. Esquema del documento de especificaciones
ESQUEMA DEL DOCUMENTO DE ESPECIFICACIONES

Introduccin
Discrepancias con el documento de requisitos
Terminologa usada
Estndares usados
Especificaciones globales
Breve descripcin y objetivos del ASIC
Diagrama de E/S y diagrama de bloques funcionales
Modos de operacin y condiciones de paso de un modo a otro
Registros programables y cometido
Definicin de E/S
Especificacin de los bloques funcionales
Descripcin del bloque .
Diagrama de E/S
Modos de operacin y condiciones de paso
Estado tras la inicializacin y terminacin
Registros programables y cometido
Especificaciones operacionales
Formato y rango de los datos
Protocolos y algoritmos de las operaciones
Direccin. modo de funcionamiento y formato de los registros programables
Estado de los registros tras la inicializacin o terminacin de operaciones
Especificaciones tecnolgicas
Especificaciones elctricas
Especificaciones temporales
Especificaciones tecnolgicas globales
Parmetros elctricos
Tensin de alimentacin
Consumo esttico y dinmico
Caractersticas de las E/S
Tensiones mxima y mnima
Corrientes
Margen de temperaturas
Frecuencia de funcionamiento
Encapsulado
Otras especificaciones
6.2.2.2.3. Elaboracin de las especificaciones

El desarrollo de las especificaciones es una tarea fundamentalmente tcnica. Aun-
que el cliente. participa habitualmente en su preparacin. la mayora de las veces la
responsabilidad de su elaboracin recae sobre el diseador (lo que no evita que sea
el cliente quien debe dar la aprobacin ltima). Su elaboracin requiere un conoci-
miento profundo del diseo de circuitos electrnicos y de la aplicacin a la que va

dedicada el circuito.
Durante la etapa de especificaciones se realiza la primera particin en bloques
funcionales del circuito. Esta particin no tiene por qu coincidir con la particin
que se realice finalmente. Su objetivo es dividir el circuito en unidades que puedan
especificarse de forma ms o menos independiente, de manera que se facilite la es-
pecificacin y permita un reparto de tareas entre varios diseadores.
Para cada uno de los bloques funcionales se identificarn y especificarn sus
entradas y salidas, su funcionalidad detallada, sus modos de operacin, sus restric-
ciones temporales, el estado tras la inicializacin, registros de datos, registros pro-
gramables, restricciones temporales, etc.
Finalizada la especificacin de cada bloque se procede a la especificacin tec-
nolgica global del circuito. sta incluir aspectos como la tensin de alimentacin,
consumo mximo, condiciones de funcionamiento, encapsulado y patillaje (inclui-
das patillas de masa, alimentacin y seales para el test), etc.
Las especificaciones deben contener adems una descripcin global del circui-
to, su funcionalidad, sus entradas y salidas, modos de operacin y registros princi-
pales. Esta descripcin servir para hacerse una idea rpida de la funcionalidad del
circuito y su cometido. El contenido bsico es el mismo que el del documento de
requisitos, pero bastante ms detallado (ya se conocen ms detalles sobre el diseo).
Esta descripcin 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 diseo y ser continuamente consultado
por los diseadores. En este sentido debe hacerse un esfuerzo especial para que ten-
ga una organizacin adecuada y sea de fcil 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 Apndice 1 se muestra la especificacin de la mquina de re-
frescos. Conviene destacar que sta es una especificacin sencilla. Aunque deben evitar-
se las especificaciones voluminosas, a menudo resultan documentos de cierta extensin.
Como se ha comentado previamente, el uso del VHDL en las especificaciones
puede ser de gran ayuda tanto para completar la documentacin como para disponer
de modelos simulables que faciliten una interpretacin de la especificacin. Sin em-
bargo, el cdigo VHDL nunca debe reemplazar la especificacin en lenguaje natu-
ral, sino servir de apoyo a la misma. En ocasiones, el cliente puede aportar modelos
en VHDL que valdrn como referencia para validar el diseo. En estos casos, los
modelos VHDL son utilizados para aprobar formalmente la revisin del diseo en
sus diferentes etapas.
6.2.2.2.4. El plan de desarrollo y el plan de pruebas

Aparte de la elaboracin del documento de especificaciones, existen dos importan-
tes tareas organizativas que se deben desarrollar durante esta etapa; la elaboracin
del plan de desarrollo y el plan de pruebas.
El objetivo del plan de desarrollo es definir, al principio del proyecto, cules
son las responsabilidades de cada participante en el proceso de diseo, cmo se van
a llevar a cabo las tareas, cmo se va a controlar el avance del diseo y cul va a ser
la programacin temporal del mismo. Todos estos aspectos quedarn recogidos en
un documento, denominado Plan de Desarrollo, que debe ser aprobado por el clien-
te y el diseador. El plan de desarrollo no es ms que una planificacin detallada
del proyecto en sus aspectos organizativos. Cuando el diseo es pequeo o poco
crtico, el plan de desarrollo, aunque interesante, puede no ser necesario. Para dise-
os grandes o crticos, que deben ser coordinados con el desarrollo del resto del sis-
tema, su elaboracin resulta imprescindible. A menudo surgen problemas debido a
la falta de definicin inicial de las responsabilidades y los procedimientos de con-
trol del proyecto. Podramos encontrar, por ejemplo, que un cliente poco experto en
diseo no se sienta capacitado para analizar las simulaciones de los modelos VHDL
tras el diseo arquitectural. El diseador, por su parte, podra no querer admitir la
responsabilidad de validar el diseo sin que el cliente verifique por su cuenta el de-
sarrollo. Si el cliente dispone de modelos VHDL con los que validar el diseo, el
problema queda resuelto; si no, habr que encontrar el procedimiento (prototipos,
revisiones ms prolongadas, formacin del cliente en el diseo, etc.) para solventar
el problema. En otras ocasiones, el cliente podra exigir unos mtodos y herramien-
tas de trabajo para los que el diseador no est preparado (por falta de formacin 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 diseo. La Figura 6-4 muestra un flujograma de los pa-
sos a seguir para realizar un diseo con unas determinadas herramientas. Este flujo-
grama, aunque complejo, sirve para resaltar el gran nmero de programas (en gris
claro), acciones (en gris oscuro) y revisiones que deben realizarse en ocasiones. Co-
mo se puede imaginar, no es difcil olvidarse algn paso o cometer algn error. El
tener estos procedimientos documentados ayuda no slo a evitar errores sino tam-
bin a facilitar la tarea a los diseadores menos expertos en el flujo de diseo.
El contenido del Plan de Desarrollo es muy variable, aunque existen una serie
de puntos que deben incluirse en la mayora 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 elaboracin de dicho documento, s con-
viene plantearse estos puntos al principio del proyecto para garantizar que no surjan
problemas ms adelante.
Otro aspecto importante a cubrir durante la etapa de especificaciones es la ela-
boracin del plan de pruebas. El objetivo del Plan de Pruebas es definir cmo se va
a realizar la validacin del diseo. Las simulaciones son el procedimiento habitual
de validacin, 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 algn otro programa para validar los resultados de las simulacio-
nes. Como ejemplo podemos pensar en el diseo de un filtro digital. Para compro-
bar que los resultados son correctos podramos seguir un procedimiento como el
mostrado en la Figura 6-5.
En este procedimiento, los datos de entrada son generados por un programa es-
pecfico para generar unas formas de onda con unas determinadas caractersticas.
Los mismos datos son pasados al modelo VHDL del circuito y a un programa de
FIGURA 6-4. Ejemplo de flujo de diseo aplicado a herramientas comerciales con-

cretas.
anlisis matemtico que incluye funciones de filtrado digital (con lo que evitamos
que el diseador desarrolle al mismo tiempo el circuito y los bancos de prueba, dis-
minuyendo el riesgo de cancelacin de errores). Los resultados son mostrados me-
diante funciones grficas del programa de anlisis matemtico y se calculan los
errores relativos (del circuito respecto al programa).
De nuevo, definir al principio del proyecto cmo se van a realizar las pruebas,
obliga a plantearse posibles fuentes de problemas y a realizar una mejor planifica-
cin del trabajo. Todo ello redundar en un proceso de diseo ms fluido y un resul-
tado de mayor calidad.
6.2.2.2.5. El equipo de diseo

La organizacin del equipo de diseo es un aspecto clave para la correcta consecucin
de lID diseo, especialmente cuando el equipo es numeroso. El equipo estar com-
TABLA 64. Plan de desarrollo.
ESQUEMA DEL PLAN DE DESARROLLO

Planificacin del diseo
Flujo de diseo y verificacin
Revisiones del diseo
Fabricante y biblioteca
Herramientas utilizadas
Pormato de intercambio de informacin
Estrategia de test y cobertura
Convenios sobre numeracin y nombres
Documentacin del diseo y listas de distribucin
Organizaci6n del equipo de diseo
Planificacin temporal considerando las dependencias de los bloques
Definicin de responsabilidades y particin del trabajo
Organizacin de la biblioteca
Flujo de diseo y verificacin
puesto bsicamente por el Director, responsable del proyecto, y los diseadores. Ha-
bitualmente es necesario contar con un experto en la aplicacin donde va a integrarse
el diseo. Este experto puede formar parte del equipo de diseo o ser parte del equipo
del cliente. En cualquier caso, lo consideraremos integrante del equipo de diseo.
Las principales cuestiones que deben resolverse desde el punto de vista del
equipo de diseo son la asignacin de tareas y la coordinacin del equipo de diseo
durante el desarrollo .

Programa Mat~
~ - -_
Resultados
-
Modelo Funcional
Ficheros Dal~
- Resultados
Modelo VHDL del Modelo ASIC
ASIC
Resultados
Patrn
FIGURA 6-5. Ejemplo de validacin de los resultados de la simulacin de un cir-

en VHDl.
cuito descrito
En la asignacin de tareas debe reflejarse la experiencia de cada diseador tan-

to en la aplicacin como en las herramientas utilizadas para el diseo. Los dise-
adores ms expertos en la aplicacin debern estar a cargo de las etapas de ms
alto nivel, como son las especificaciones y el diseo arquitectural. Por otro lado, los
diseadores ms expertos en las herramientas (VHDL, herramientas de diseo fsi-
co, etc.) estarn ms indicados para las tareas de diseo lgico y diseo fsico.
Existen dos tareas adicionales que a menudo requieren un perfil muy especfico
por parte de los diseadores: el modelado del entorno y la elaboracin del programa
de test. Para el modelado del entorno se necesita un diseador especialmente exper-
to en VHDL, ya que debe realizar un modelo lo ms fiel posible, y que al mismo
tiempo consuma pocos recursos a la hora de simularlo. Por otro lado, debe ser ca-
paz de abstraer cules son las caractersticas del entorno que influyen sobre el dise-
o y que, por tanto, deben modelarse con precisin. En cuanto a la elaboracin del
programa de test, ste requiere un diseador especialmente experto en el diseo 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 diseadores con el perfil ideal para cada tarea, por
lo que ser necesario una coordinacin adecuada para sacar el mximo provecho al
equipo de diseo y minimizar el tiempo empleado en el desarrollo.
La coordinacin del equipo de diseo debe establecerse a diferentes niveles. En
primer lugar, deben fijarse reuniones peridicas que permitan evaluar el estado del
proyecto y aplicar medidas correctivas cuando sea necesario. En segundo lugar,
deben establecerse normas internas y reglas de diseo que faciliten la futura inter-
conexin de los bloques. En el Apndice 11(sobre Normas de codificacin y mode-
lado) se muestra un ejemplo de este tipo de normas. Seguir este tipo de reglas no
slo va a permitir una integracin fcil de los diferentes mdulos que componen el
diseo, sino que adems permitirn un posible cambio en la asignacin de tareas, ya
que todos los diseadores trabajarn con un estilo homogneo. Por ltimo, los dise-
adores deben elaborar una documentacin adecuada de su trabajo, que sea fcil-
mente integrable en los documentos finales del proyecto.
Una ltima cuestin a la que debe estar atento el director del equipo de diseo
es la formacin de los diseadores. La constante evolucin de las herramientas y
tcnicas de diseo obliga a mantener un esfuerzo continuado de actualizacin de
conocimientos. Esto debe ser tenido en cuenta para que no repercuta negativamente
sobre los diseos.
Como en cualquier otro proyecto, la coordinacin del equipo de diseo requie-
re un esfuerzo importante por parte del director. El conocimiento profundo del pro-
ceso de diseo y la utilizacin de tcnicas clsicas como la realizacin de grficos
tipo GANTT o PERT pueden facilitar en gran medida esta tarea.
6.2.3. El diseo arquitectural y lgico
En el proceso de diseo basado en VHDL y sntesis automtica el diseo se realiza

fundamentalmente durante las etapas de diseo arquitectural y lgico. Estas son
normalmente las etapas que requieren un mayor esfuerzo y tiempo.
6.2.3.1. Desarrollo del diseo arquitectural
La etapa de diseo arquitectural puede ser entendida como una etapa de transicin
entre las especificaciones y el diseo lgico del circuito. El objetivo fundamental
de la etapa de diseo arquitectural es obtener una jerarqua de mdulos en la que
los bloques funcionales estn definidos de manera que sean compatibles a nivel de
ciclos de reloj (en el caso de diseos sncronos) con el diseo final. El diseo as
dividido deber cumplir con las restricciones planteadas en la etapa de especifica-
ciones y ser ptimo en cuanto a los parmetros del diseo (temporales, de rea y
consumo). Para ello deben investigarse distintas alternativas de diseo y escogerse
la ms adecuada. Durante esta etapa se desarrollarn tambin 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 diseo 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-
zacin. El modelo VHDL contendr una descripcin 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 evolucin de las
seales en cada ciclo de reloj ser igual a la del circuito una vez fabricado (siempre
que se sigan unas normas de diseo sncrono y se garantice en la fase de sntesis
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 realizacin del modelo arquitectural en VHDL cualquier estilo de descrip-

cin es vlido. Sin embargo, deben tenerse en cuenta que existen dos objetivos
contrapuestos que es necesario armonizar. Por un lado, la elaboracin de los mo-
delos VHDL debera ser lo ms rpida y sencilla posible. De esta manera el dise-
ador se concentrar ms 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-
macin en modelos sintetizables (recurdese que no todos los estilos son acepta-
bles por las herramientas de sntesis) durante la etapa de diseo lgico sea tambin
sencilla.
Para conseguir esto se considera habitualmente que tras la etapa de diseo ar-
quitectural debe haberse obtenido una descripcin sintetizable del circuito, aunque
los resultados de la sntesis no sean ptimos. Sin embargo, no siempre es sencillo
realizar una descripcin sintetizable del circuito. Los subconjuntos del VHDL que
aceptan las herramientas de sntesis son, en ocasiones, muy limitados, e imponen un
estilo de descripcin que resulta engorroso durante esta etapa. Como ejemplo puede
considerarse la descripcin mostrada en el Listado 6-3. El cdigo refleja el modelo
de un banco de registros en el que se puede escribir o leer un determinado registro
activando adecuadamente la seales 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 descripcin, a nivel RT, se ha utilizado un estilo de descripcin que po-

dramos llamar algortmico. El banco de registros es un vector bidimensional al que
se accede a travs de un ndice. Como se observa, la descripcin es fcil de realizar
y comprender. Esta descripcin, sin embargo, no es sintetizable por muchas herra-
mientas de sntesis actuales. Para ello podramos habemos visto obligados a realizar
una descripcin 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 Rloj'event and Reloj '1' then
if LeeEscrN = 'O' then
case Registro 1s
when 0-'=> BancoRegO := Entrada;
when 1 => BancoRegl :,,;. Entrada;
when 2 => BancReg2 ~:= 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 permitira el uso de vectores bidimensio-

nales, por lo que habra que describirlos explcitamente. Evidentemente, esta des-
cripcin es ms difcil de realizar y de interpretar.
Este tipo de situaciones se dan a menudo durante la etapa de diseo arquitectu-
ral. Realizar una descripcin utilizando toda la potencia que nos ofrece el VHDL
facilita y acelera el trabajo. Por tanto, se intentar hacer la descripcin 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, obsrvese el segmento de cdigo del
siguiente listado.
if Reloj' event and LeeEscrN = ' l' then

Registro := Entrada;
else
Salida := Registro;
end process;
LISTADO 6-5. Descripcin VHDL no sintetizable.
En esta descripcin, Registro cargara datos tanto en el flanco de subida como

en el de bajada de la seal Reloj (podramos encontrarlo interesante para nuestro
diseo). Cuando intentsemos hacer una descripcin sintetizable del circuito nos
encontraramos con la desagradable sorpresa de que no es posible. Esta limitacin
no es debida a las herramientas de sntesis, sino a que no existen normalmente bies-
tables que funcionen de tal modo. Eso obligara a cambiar el diseo arquitectural,
haciendo que el circuito slo funcione en flanco de subida o de bajada.
La conclusin es que deben hacerse descripciones de circuitos que sean sinteti-
zables en un sentido fsico, es decir, que debe existir alguna circuitera que se com-
porte como el modelo realizado. Esto es una constante en todo diseo VHDL orien-
tado a sntesis; debemos utilizar el VHDL para describir un circuito que ya sabemos
cmo realizar fsicamente. El VHDL no es ms que un mtodo para acelerar el pro-
ceso de diseo, una forma mejor que los esquemticos para describir un circuito,
pero no evita que el diseador tenga que elaborar en su cabeza el esquema bsico
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 diseo ar-
quitectural es la tecnologa escogida para el diseo. De la tecnologa va a depender
fundamentalmente la biblioteca de la que dispongamos, y de sta, la facilidad con
que diseemos unas u otras partes del circuito. Un determinado fabricante podra dis-
poner de una biblioteca en la que hubiese tanto componentes digitales como analgi-
cos, podra disponer de generadores de macroceldas (RAM, ROM, PAL, etc.), ge-
neradores optimizados de estructuras ms 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 diseo. 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 utilizacin (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 diseo arquitectural, adems
del diseo preliminar del propio circuito, son los bancos de prueba. En este caso,
el objetivo fundamental es conseguir unos bancos de prueba que sean vlidos a lo
largo de las posteriores etapas de refinamiento del diseo. La elaboracin de los
bancos de prueba es, de hecho, una 'de las tareas ms crticas dentro del proyecto.
Un diseo con unos bancos de prueba inadecuados es un diseo poco comproba-
do y, por lo tanto, un diseo no vlido. Cuanto ms exhaustivo sea el plan de
pruebas, existirn mayores garantas de que no quede algn error de diseo sin
detectar.
Si es posible, el banco de pruebas deber ser elaborado por un diseador dife-
rente al que ha realizado el diseo. De esta manera se evita la cancelacin de posi-
bles errores de interpretacin de las especificaciones.
Podramos plantear dos mtodos bsicos para afrontar la elaboracin de los
bancos de prueba: los bancos de prueba orientados al modo de funcionamiento y los
orientados a la seal.
En el primer caso debe establecerse un procedimiento donde, para cada modo
de funcionamiento del mdulo que se est comprobando, se elabore un banco de
prueba (o varios) que verifique que cada seal de salida del mdulo responde
de forma adecuada.
En el caso de los bancos de prueba orientados a la seal, debe establecerse un
procedimiento donde, para cada seal de salida del mdulo que se est comproban-
do, se elabore un banco de prueba (o varios) que verifique que la seal responde de
forma adecuada ante cada modo de funcionamiento.
En general, los bancos de prueba orientados a la seal son ms sistemticos y
exhaustivos. Adems, puesto que normalmente el diseador plantea el desarrollo de
un determinado mdulo pensando en los modos de funcionamiento, el utilizar un
procedimiento orientado a las seales asegura una comprobacin cruzada. Por otro
lado, es un procedimiento ms sencillo de automatizar, aunque en algunos casos
puede ser excesivamente costoso. Escoger un mtodo u otro depender de las prefe-
rencias de los diseadores.
Al elaborar un banco de pruebas debe verificarse que se ha comprobado el fun-
cionamiento del diseo 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 despus de una inicializacin. Hay que comprobar especialmente que
los registros y las seales se inicializan adecuadamente bajo cualquier condi-
cin de partida. Por ello es necesario que los bancos de prueba incluyan ini-
cializaciones no slo al principio de las simulaciones, sino tambin en cual-
quier situacin de funcionamiento.
Terminaciones: la mayora de los circuitos funcionan de forma cclica; los
mdulos que lo integran presentan una funcionalidad que es iniciada al cum-
plirse una serie de condiciones y/o activarse una serie de seales, y que es
terminada de forma autnoma o externa. Tras la terminacin del ciclo, las se-
ales y registros deben quedar con los valores adecuados para poder comen-
zar un nuevo ciclo. Podramos pensar, por ejemplo, en un transmisor serie.
La transmisin comienza al activar una determinada seal y termina autom-
ticamente cuando el dato ha sido enviado. Tras la transmisin, el circuito de-
be quedarse en la misma situacin que cuando empez, preparado para trans-
mitir un nuevo dato. Es, por tanto, necesario verificar que las seales y regis-
tros internos del mdulo 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 (podra estropearse alguno de los sistemas con los que interacta).
Por ello, es necesario realizar un esfuerzo de comprobacin para considerar
los casos no previstos en las especificaciones y que puedan dar paso a com-
portamientos no deseados. Casos tpicos son inicializaciones en medio de un
ciclo de funcionamiento, asincronismo en algunas seales, relanzamiento de
un ciclo (p. ej., intentar enviar un dato en un transmisor serie cuando an es-
t enviando el anterior), etc.
Valores no considerados: el funcionamiento de un circuito o mdulo puede
ser errneo si aparece en sus entradas alguna combinacin de seales no pre-
vista, tanto en seales de configuracin como en datos internos o en valores
de las seales de entrada (lo que probablemente dara funcionamientos no
considerados).
6.2.3. 1.4. Resultados del diseo arquitectural

Como se ha indicado al principio de este apartado, el objetivo del diseo arquitectu-
ral es obtener una descripcin 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 diseo lgico. Al mismo tiempo, la descripcin debe ser lo suficientemen-
te cercana al diseo final como para que no surjan sorpresas durante el diseo lgi-
co que impliquen un cambio de la filosofa del diseo.
Desde un punto de vista tcnico, tras el diseo 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 gestn del dseo 381
Sin embargo, estos modelos no son el nico resultado que se debe obtener de
esta etapa. Como en cualquier fase del diseo, el diseo arquitectural debe quedar
correctamente documentado para poder utilizar el trabajo en posteriores etapas.
Para ello deberemos redactar el Documento de Diseo 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 grficos y cronogramas, el funcionamiento del
circuito (el modelo) y los bancos de prueba. El contenido y extensin 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 Diseo Arquitectural adquiere una gran importancia. Su
redaccin, como la del Documento de Especificaciones, debe ser especialmente
cuidada. Este documento, junto con el cdigo 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 diseador es el mismo du-
rante las etapas de diseo arquitectural y detallado, el Documento de Diseo Ar-
itectural es menos crtico. Sin embargo, su redaccin presenta dos grandes ven-
tajas. En primer lugar, facilita el trabajo posterior. En segundo lugar, sirve como
documento base para elaborar la documentacin final del diseo (las hojas de ca-
ractersticas y la descripcin del circuito), por lo que siempre es un trabajo que se
aprovechar.
El Documento de Diseo Arquitectural, aunque especfico de cada circuito,
responde casi siempre a un mismo esquema. La Tabla 6-5 muestra un ndice genri-
co de un documento tpico de diseo arquitectural.
En el Apndice 1puede encontrarse el Documento de Diseo Arquitectural pa-
ra la mquina de refrescos de nuestro ejemplo. Aunque en este caso su extensin se
ha reducido para incluirla en el texto, puede valer como ejemplo del aspecto que
presenta un documento de este tipo.
Obsrvese que en el documento se ha incluido tambin una descripcin de los
bancos de prueba y su funcionalidad. Aunque en s los bancos de prueba no forman
parte del circuito, su descripcin facilitar la comprensin de los mismos por parte
de los participantes en las siguientes etapas del diseo. Adems, permitir verificar
que los bancos de prueba responden a las especificaciones (simulan el entorno del
circuito).
6.2.3.2. La revisin del diseo arquitectural
Terminada la etapa de diseo arquitectural deben revisarse los resultados obtenidos

hasta el momento. La revisin de esta etapa es especialmente importante, ya que a
partir de este momento las modificaciones al diseo tendrn un coste cada vez ms
alto.
La revisin del diseo arquitectural cumple dos cometidos; uno tcnico (revisar
la funcionalidad del diseo) y otro organizativo o metodolgico (revisar cmo se ha
hecho el diseo y 10 ajustado que est al plan de desarrollo).
Desde el punto de vista tcnico, la revisin del diseo arquitectural supone una
nueva comprobacin del trabajo realizado por los diseadores. Se debe verificar que
TABLA 6-5. Esquema del documento de diseo arquitectural
ESQUEMA DEL DOCUMENTO DE DISEO ARQUITECTURAL
Introduccin
Documentos aplicables y de referencia
Discrepancias con el documento de especificaciones
Glosario
Terminologa usada
Descripcin arquitectural
Particionado del diseo y justificacin
Identificacin de bloques de la biblioteca aptos para ser utilizados
Identificacin de bloques susceptibles de ser incluidos en la biblioteca
Diagrama de bloques actualizado y de E/S del diseo
Interaccin entre bloques
Caracterizacin de seales internas
Estrategia de test global
Descripcin detallada (para cada bloque funcional)

Descripcin general del bloque
Diagrama de E/S del bloque
Funcionalidad detallada del bloque
Diagramas y codificacin de estados
Formato de los datos y protocolos de comunicacin internos
Codificacin de registros internos
Codificacin de los datos internos
Breve descripcin del modelo VHDL
Estrategia de test del bloque
Descripcin del test funcional

Simulaciones realizadas y resultados
Matriz de cumplimiento de las especificaciones
APNDICE: Cdigos VHDL del circuito y bancos de prueba
lo realizado cumple con las especificaciones, y si no es as, justificar las diferencias

y la nueva solucin. Normalmente este trabajo ya habr sido realizado por el disea-
dor e incluido en el Documento de Diseo Arquitectural, por lo que no debera
requerir demasiado esfuerzo. En la revisin del diseo arquitectural deberan partici-
par tanto el diseador como el cliente. Es precisamente el cliente quien debe asegu-
rarse de que el diseo satisface totalmente sus requisitos y debe dar el visto bueno al
diseo.
Desde el punto de vista organizativo y metodolgico, la revisin debe verificar
que el diseo ha sido realizado de forma adecuada y que los plazos fijados siguen
siendo vlidos. Hay que comprobar que el cdigo VHDL ha sido escrito de forma
correcta; es decir, que se ha elaborado un cdigo de calidad. Esta revisin implica
comprobar los siguientes puntos:
Estilo de codificacin y nomenclatura: aunque la forma de nombrar las

seales y escribir el cdigo no tiene por qu influir en la funcionalidad del
diseo, utilizar un mal estilo de codificacin hace perder muchas de las venta-
jas del VHDL. Podemos comparar las descripciones del Listado 6-6. Eviden-
temente, la segunda descripcin es mucho ms clara. La primera descripcin
difcilmente podr ser utilizada por un diseador 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 seleccin = i then
salida(i) <= '1';
end if;
end loop;
end if;
end process;
LISTADO 6-6. Estilos de nomenclatura.
Estilo de descripcin: 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 cdigo y su depuracin.
Utilizacin de puertos, seales, variables y genricos: como resultado del
proceso de diseo, a menudo se definen seales, variables, etc., que son utili-
zadas durante un cierto tiempo y luego son desechadas al encontrase una so-
lucin mejor o ms elegante. Conviene revisar que en el cdigo no quedan
estos objetos definidos y no utilizados. Si bien no suponen un error en el di-
seo, s dificultan la lectura y depuracin del cdigo. Un diseador ajeno al

diseo encontrara seales definidas que no sabe para qu se utilizan. Por
otro lado, esta revisin permite identificar posibles olvidos u omisiones y da
como resultado un cdigo de mayor calidad.
Comprobacin de valores constantes en el cdigo: en todo diseo apare-
cen valores constantes que reflejan alguna caracterstica del circuito que se
est realizando. Estos valores responden a aspectos como el ancho de un bus,
la cuenta final de un contador, el nmero de registros de un banco de regis-
tros, etc. Conviene revisar que estos valores no aparecen reflejados como
nmeros en el cdigo, sino como constantes que habrn sido definidas previa-
mente. Esto responde a dos objetivos; por un lado, facilita la lectura del cdi-
go; por otro, facilita las modificaciones posteriores, ya que el valor slo es
corregido en un sitio. En el apartado sobre diseo genrico se discutir este
tema ms a fondo.
Comprobacin de las listas de sensibilidad: en los diseos realizados en
VHDL, una fuente frecuente de problemas son las listas de sensibilidad de
los procesos. Como se ha visto en captulos previos, los procesos en VHDL
que poseen listas de sensibilidad slo son evaluados cuando se produce un
evento en alguna de las seales 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 seales que se lean en el proceso, ignorando lo
que aparezca en la lista de sensibilidad. El Listado 6-7 presenta un ejemplo.
La descripcin VHDL, una vez sintetizada, producir un circuito que no se
comportar igual que el de la simulacin. 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 informacin que le devuel-
ven las herramientas de sntesis). 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 errnea.
Ejercicio 6.1-
Dibujar el circuito resultante de la sntesis del cdigo del Listado 6-7 Y las formas
de onda resultantes de la simulacin.
Seleccin .....1 L
Entrada_O Entrada_O ___fl___f"L___J
Salidas
Entrada_1~
Entrada_1
salidassntesis~
Salidas simuladas ---------_
La revisin de estos aspectos suele ser llevada a cabo por los diseadores (nor-
malmente por el director del equipo de diseo). Como se observa, su objetivo final
es facilitar las tareas posteriores y la reutilizacin del diseo. Un cdigo VHDL
bien escrito es un cdigo fcil de leer y de depurar. Las modificaciones posteriores
implicarn poco trabajo y el riesgo de errores disminuir.
Los ltimos aspectos del diseo arquitectural a revisar son los relacionados con
la organizacin del proyecto, siendo el ms importante el referente al cumplimiento
de plazos. En este punto del diseo se tendr una idea mucho ms precisa de la
complejidad del proyecto y su evolucin. Se debern aplicar las medidas necesarias
para cumplir el plan de trabajo planteado inicialmente y, si fuese necesario, se rea-
justarn las tareas y plazos para solucionar posibles problemas. En este sentido, es
el cliente quien debe tomar las decisiones finales sobre cualquier modificacin a la
planificacin del proyecto.
6.2.3.3. Desarrollo del diseo lgico
El objetivo del diseo lgico es obtener una descripcin del circuito lo suficiente-
mente detallada como para servir de entrada a las herramientas de diseo fsico. El
trabajo fundamental de esta etapa consistir en la sntesis de las descripciones
VHDL y la optimizacin de la lgica para conseguir las prestaciones deseadas. La
optimizacin de la lgica se har a dos niveles: previamente a la sntesis (modifi-
cando el cdigo VHDL) y tras la sntesis (imponiendo restricciones temporales, de
rea o consumo). La ejecucin de esta etapa requiere la seleccin del fabricante y la
tecnologa en la que se implementar el circuito.
6.2.3.3. 1. La seleccin de la tecnologa

Desde un punto de vista terico, la seleccin de la tecnologa podra retrasarse hasta
esta etapa. Hasta este momento el diseo ha sido independiente de la tecnologa; los
modelos arquitecturales no poseen normalmente informacin respecto a una biblio-
teca particular de componentes, sino que describen el comportamiento del circuito
en trminos de registros y operaciones lgicas. Sin embargo, retrasar la seleccin de
la tecnologa hasta esta etapa puede acarrear ciertos inconvenientes. En primer lu-
gar, puede ocurrir que la tecnologa escogida no satisfaga los criterios de rea, fre-
cuencia de funcionamiento o consumo requeridos. Si la tecnologa se ha selecciona-
do con antelacin, se podrn realizar algunas pruebas de aquellas partes que se con-
sideren ms crticas con objeto de estimar si van o no a cumplir con las restriccio-
nes. Estas pruebas podrn realizarse durante la etapa de diseo arquitectural, o
incluso durante la etapa de especificaciones, previendo posibles problemas y
actuando en consecuencia.
Por otro lado, desconocer la tecnologa 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 estn
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 podra ocurrir que nos dedicsemos 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 integracin
y simulacin sin problemas en nuestro diseo.
6.2.3.3.2. La optimizacin del cdigo

Normalmente, el cdigo desarrollado durante la etapa de diseo arquitectural habr
sido escrito sin considerar en detalle el diseo lgico (de hecho, ste es su objetivo).
Por tanto, habr que modificar las descripciones para obtener un buen resultado tras la
sntesis lgica. 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 sntesis no sean los
ms adecuados. Como ejemplo podemos fijarnos en el cdigo 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 Relj ': '1' then
auxCuenta := auxCuenta + 1;
if awd::uenta = c:MaxCunta tben
auxCuenta := O;
end if;
Cuenta <=auxCuenta
end if;
end process;
LISTADO 6-8. Contador con registros redundantes.

El cdigo refleja un contador sncrono 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 seal Cuenta. Si sintetizamos esta des-
cripcin se generarn dos registros, uno para almacenar la variable auxCuenta y
otro para la seal Cuenta. Aunque la descripcin y el resultado tras la sntesis son
funcionalmente correctos, ambos registros contendrn la misma informacin, por lo
que sern redundantes. Esta descripcin debera ser optimizada para eliminar uno
de los registros.
Ejercicio 6.2
Modificar el cdigo del Listado 6-8 para que no genere registros redundantes.
Los registros en auxCuenta y Cuenta se generarn 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
':_'tIT 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. Modificacin propuesta para el Listado 68.
Otro caso tpico es la comparticin de recursos. Como ejemplo podemos fijar-

nos en el cdigo del Listado 6-10. En este caso el cdigo refleja parte de una unidad
aritmtica 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. Utilizacin de dos sumadores.
En el cdigo, los registros A y B guardan el resultado de la suma de otras seales

del sistema. Si sintetizamos esta descripcin encontraremos que se generan dos su-
madores, uno para calcular A y otro para calcular B. Pero si prestamos atencin a la
descripcin veremos que nunca se utilizan los dos sumadores al mismo tiempo (los
cdigos de operacin son excluytentes), sino que en funcin de una seal de selec-
cin se calcula A o B. Por lo tanto, es posible utilizar un mismo sumador para realizar
ambas operaciones (algunos sintetizadores pueden hacer esto automticamente).
Ejercicio 6.3
Modificar el ejemplo del Listado 6-10 para que al sintetizarlo se utilice un solo su-
mador.
Una posible solucin consiste en utilizar variables intermedias a la que se les
asigna el valor de los operandos en funcin del cdigo de operacin.
process (Reloj, Inicio ... )
variable OpI, Op2 : -- Definidas igual. que los Datos

variable Suma . -- Definida igai 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 Operacin = COD_OPDC then
A <= Suma;
elsif Operaci~n = COD_OPIR then
B <= Suma;
end if;
end process;
LISTADO 6-11. Modificacin propuesta para el Listado 6.10.

6.2.3.3.3. La repercusin de los cambios
En ocasiones las restricciones temporales o de consumo pueden implicar cambios

en el diseo arquitectural. Tomemos, por ejemplo, un diseo que debe funcionar a
una frecuencia elevada. Tras la sntesis podramos descubrir que no satisface las es-
pecificaciones de velocidad. Esto podra implicar la necesidad de introducir seg-
mentacin en las partes ms crticas del diseo, lo que supone una modificacin a
nivel arquitectural. A estas alturas del diseo, los costes de dichas modificaciones
son importantes, ya que se deben redisear 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 diseo arquitectural ade-
cuado. La utilizacin de tcnicas como el diseo genrico puede ayudar a paliar
los efectos de dichos cambios (permitiendo, por ejemplo, cambiar rpidamente el
nmero de estapas de segmentacin necesarias, los ciclos de espera a un evento
lento, etc.).
Otra de las razones fundamentales por las que se realizan modificaciones en el
cdigo es la introduccin de lgica para test. Este es un aspecto difcil de conside-
rar durante la etapa de diseo arquitectural, ya que el test aplicable al circuito
depende en gran medida de la lgica utilizada para implementar cada funcin. La
insercin de lgica de test y obtencin de los vectores de test puede hacerse de for-
ma automtica con algunas herramientas (utilizando tcnicas 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 difcil, y bastante dependiente de la
aplicacin.
6.2.3.3.4. Los resultados del diseo lgico
Como se ha indicado previamente, el objetivo del diseo lgico es obtener una des-
cripcin lo suficientemente detallada como para servir de entrada a las herramientas
de diseo fsico. Como hemos visto, este proceso consiste en modificar el cdigo
(para eliminar lgica redundante, compartir recursos o satisfacer ciertas restriccio-
nes) y sintetizarlo con una determinada biblioteca suministrada por un fabricante.
Tras el proceso de sntesis (o en paralelo con ste), las herramientas permiten reali-
zar una optimizacin lgica que permita satisfacer los requisitos en cuanto a consu-
mo, rea o frecuencia de funcionamiento. El proceso de sntesis habr sustituido la
lgica descrita a nivel RT por un conjunto de puertas, biestables, y celdas bsicas
que poseen la misma funcionalidad.
Tras el proceso de sntesis obtendremos una descripcin estructural del circui-
to, que consistir en una lista de celdas (pertenecientes a la biblioteca del fabrican-
te) e interconexiones (netlist). Esta descripcin ser la entrada a las herramientas de
ubicacin y conexionado.
Durante toda esta etapa se habrn realizado modificaciones sobre el diseo (op-
timizacin del cdigo). 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 diseo arquitectural. Tras la

sntesis, tambin es conveniente realizar estas simulaciones. Aunque normalmente
no hay problemas, puede ocurrir que el proceso de sntesis ofrezca resultados inco-
rrectos, por lo que conviene verificar, mediante simulacin, que los resultados son
satisfactorios. Para realizar estas simulaciones ser necesario obtener una descrip-
cin VHDL estructural del circuito sintetizado (casi todas las herramientas de snte-
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 lgica del circuito. Aunque stos no sern los retardos reales (falta
incluir los retardos debidos a las interconexiones), s nos permitirn una simulacin
ms 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 lgico, el documento debe incluir fundamentalmente las modificaciones realiza-
das a los cdigos VHDL, la descripcin del mtodo utilizado para realizar el test de
fabricacin y recomendaciones para la etapa de diseo fsico. Todo esto quedar
recogido en el Documento de Diseo Lgico. La Tabla 6-6 muestra un posible
esquema del contenido de dicho documento.
6.2.3.4. La revisin del diseo lgico
Terminada la etapa de diseo lgico deben revisarse los resultados obtenidos hasta
el momento. La revisin del diseo lgico 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 fabricacin. Adems, al
igual que se hizo en la revisin del diseo arquitectural, deben verificarse los aspec-
tos organizativos del proyecto (cmo se ha hecho el diseo lgico y lo ajustado que
est al plan de desarrollo).
Para revisar la funcionalidad se habrn realizado simulaciones comparativas
entre los resultados del diseo arquitectural y el diseo lgico. Pero adems, puesto
que ya se dispone de una estimacin de los retardos de la lgica, se verificar que el
circuito sigue comportndose adecuadamente en las simulaciones en peor y mejor
caso (retardos mximos y mnimos), especialmente en los puntos que se consideren
ms crticos.
En cuanto al test de fabricacin, el proceso de revisin consiste en un anli-
sis de las partes del circuito que no han quedado suficientemente cubiertas por
el test de fabricacin. La decisin sobre una posible mejora del test de fabrica-
cin depende en gran medida del tipo de aplicacin a la que vaya dedicado el
circuito y de los recursos y tiempo necesarios para su modificacin. Esta deci-
sin debe ser valorada convenientemente por el cliente y el Director del equipo
de diseo.
En cuanto a los aspectos organizativos y metodolgicos del diseo, son apli-
cables los mismos comentarios que se hicieron para la etapa de diseo arquitec-
tural.
TABLA 6-6. Esquema del documento de diseo lgico
ESQUEMA DEL DOCUMENTO DE DISEO LGICO

Introduccin
Documentos aplicables y de referencia
Discrepancias con el documento de diseo arquitectural y especificaciones
Glosario
Terminologa usada
Descripciones globales
Biblioteca utilizada
Relacin de PADs utilizados
Patillaje cuasi-definitivo
Encapsulado
Descripcin de cada bloque del diseo arquitectural
Descripcin general del bloque y E/S
Particionado, diagrama estructural y funcionalidad de los subbloques
Descripcin de la circuitera de test'
Breve descripcin del modelo VHDL
Restricciones utilizadas en sntesis
Descripcin de los componentes de biblioteca utilizados
Descripcin general del bloque y E/S
Restricciones y parmetros utilizados en sntesis
Verificacin del test funcional
Simulaciones realizadas y resultados
Matriz de cumplimiento respecto al diseo arquitectural
Descripcin del test de fabricacin
Descripcin del programa de test
Resultados de la simulacin de fallos (cobertura y movilidad)
Test paramtricos a realizar
Anlisis de resultados tras la sntesis (recomendaciones al diseo fsico)
Mxima frecuencia de funcionamiento
Anlisis esttico de tiempos
Distribucin y desfase del reloj
Problemas de Jan-out
APNDICE 1: Cdigos VHDL del circuito
APNDICE 11: Programa y vectores de test (de fabricacin)
APNDICE 111: Relacin de advertencias obtenidas y justificacin
6.2.4. El diseo fsico y la fabricacin

La etapa de diseo fsico consistir fundamentalmente en la ubicacin y conexiona-
do de la lgica sintetizada durante el diseo lgico. Los datos de entrada a esta eta-
pa son bsicamente la lista de componentes e interconexiones, la biblioteca del fa-
bricante y las recomendaciones para el diseo fsico contenidas en el Documento de
Diseo Lgico. El trabajo de esta etapa suele estar bastante automatizado y no de-
bera plantear problemas para la mayora de los circuitos. Sin embargo, cuando el
circuito trabaja a altas frecuencias de funcionamiento el tamao de la lgica 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 diseo fsico estn bastante automatizadas, a menudo existe
un salto brusco entre las herramientas utilizadas hasta el momento (simuladores y
sintetizadores) y las que se utilizarn en esta etapa. En ocasiones es necesario reali-
zar conversiones de formato, utilizar simuladores especficos 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 diseo arquitectural o
diseo lgico puede evitar sorpresas de ltima hora.
Tras la realizacin del diseo fsico, ser necesario realizar simulaciones del
circuito con los retardos debidos a las interconexiones. Estas simulaciones refleja-
rn con gran precisin el comportamiento real del circuito. Deben realizarse simula-
ciones en peor y mejor caso y verificar los puntos crticos.
El proceso de fabricacin depende de la tecnologa escogida. Si el circuito se va a
implementar mediante lgica programable (EPLDs, FPGAs), la programacin se har
normalmente en el centro de diseo. Si el circuito va a ser fabricado como un ASIC
(circuito integrado de aplicacin especfica), requerir de unos prototipos iniciales an-
tes de pasar a produccin. Esto debe tenerse en cuenta en la planificacin del proyec-
to, ya que normalmente implica un retardo adicional de al menos uno o dos meses.
6.2.5. La validacin y caracterizacin del circuito
Una vez fabricado el circuito, debe comprobarse su funcionamiento en el sistema

final. Las pruebas a realizar dependen de cada aplicacin. 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 validacin puede requerir planes de
prueba especficos que, en muchos casos, no respondern 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
garanta 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 lgica y del sis-
tema. En algunos casos ser incluso necesario realizar tarjetas o circuitera adicio-
nal para comprobar fcilmente el funcionamiento.
La elaboracin de estas pruebas debe tenerse en cuenta para no demorar la fi-
nalizacin del proyecto. Normalmente, estas pruebas pueden planificarse y disear-
se durante las etapas de diseo fsico y fabricacin. En estas etapas, el diseo va a
estar completamente definido y raramente se producirn modificaciones, por lo que
el trabajo dedicado a la elaboracin de las pruebas finales no se ver afectado (sal-
vo, quizs, el patillaje definitivo).
Una de las ltimas tareas a realizar sobre el diseo es su caracterizacin. Este
proceso, aunque no siempre se realiza, permite verificar que el comportamiento del
circuito responde a lo simulado. Los resultados de la caracterizacin nos permitirn

completar la documentacin sobre el diseo y facilitarn la reutilizacin del compo-
nente en otros proyectos. Por otro lado, podremos utilizar los resultados de la carac-
terizacin para obtener un modelo en VHDL del componente. En la mayora de los
casos ser suficiente con introducir los retardos reales del componente sobre el mo-
delo RT que obtuvimos tras la etapa de diseo arquitectural. El siguiente listado
muestra un ejemplo sencillo de cmo 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. Introduccin de retardos en la descripcin VHDL.

El ejemplo mostrado es un caso muy sencillo en el que las seales tienen retar-
dos diferentes en funcin de la seal de seleccin. En la mayora de los casos, la
descripcin 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 slo aproximadamente las caractersticas reales del circuito; puede
ser un modelo vlido para unas simulaciones estimativas sobre el comportamiento
del sistema, pero no resultar adecuado si se quieren realizar unas simulaciones pre-
cisas. An as, suelen ser modelos muy tiles durante las etapas iniciales de un pro-
yecto (hasta la etapa de diseo arquitectural).
6.2.6. Documentacin, evaluacin y seguimiento

del proyecto
Como se ha podido observar en los anteriores apartados, el proceso de diseo de un

circuito requiere cubrir una gran cantidad de aspectos adems de lo que es la codifi-
cacin del diseo en VHDL y su posterior sntesis. Aspectos como la documenta-
cin, las reuniones peridicas, el seguimiento y solucin de los posibles problemas,
etctera, requieren un esfuerzo considerable por parte del cliente y de los integran-
tes del equipo de diseo.
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 documentacin, por
ejemplo, es un factor clave en todo proyecto. Una buena documentacin de una eta-
pa facilita enormemente el trabajo de la siguiente. Sin embargo, el esfuerzo dedica-
do a elaborar una buena documentacin puede ser elevado. Los documentos ms
importantes de un diseo, y cuyo contenido debe ser ms cuidado, son el Documen-
to de Especificaciones y el Documento de Diseo Arquitectural. Si el diseo es pe-
queo, la realizacin de los dems documentos puede reducirse en gran medida, e
incluso no realizarse en algunos casos. Si el diseo es complejo, el nmero de parti-
cipantes es grande, o se prev una reutilizacin o depuracin futura del diseo, una
buena documentacin de cada etapa va a ser imprescindible. De igual manera, la
realizacin de reuniones peridicas, la elaboracin de planificaciones detalladas, los
informes peridicos de seguimiento, etc., deben hacerse de acuerdo a la magnitud
del proyecto. Si el proyecto es pequeo, estos aspectos pueden ejercer un efecto
negativo sobre el desarrollo, en vez de agilizarlo. En cualquier caso, debe ser el
director del equipo de diseo quien valore el grado de detalle que deben seguir estas
recomendaciones.
6.3. DESARROLLO Y ORGANIZACIN DE BIBLIOTECAS

ENVHDL
En un diseo real desarrollado en VHDL se generan normalmente una gran canti-

dad de ficheros de cdigo, unidadesde diseo (entidades, arquitecturas, etc.), fiche-
ros de datos y documentacin que es necesario gestionar. No es extrao encontrarse
al final del diseo con decenas de ficheros y versiones distintas de los componentes
diseados. Adems, los objetivos de estas versiones pueden ser diferentes, estando
unas pensadas para sntesis, otras para simulacin, etc.
La Pigura 6-6 muestra un ejemplo simplificado de las diferentes versiones o
ficheros que podran ir apareciendo durante el proceso de diseo. En la figura pode-
mos ver cmo un determinado mdulo del diseo (mdulo A) va pasando por dife-
rentes versiones hasta llegar a su versin definitiva.
Inicialmente disponemos de un modelo comportamental, posiblemente desarro-
llado durante la etapa de especificaciones. Durante el diseo arquitectural, el mismo
mdulo es rediseado (descrito de forma diferente) para obtener un modelo RT. Du-
rante este proceso se han podido generar diferentes versiones hasta llegar a la solu-
cin funcionalmente conecta o ms adecuada. Posteriormente pasaramos al diseo
lgico, donde todo este proceso de rediseo se repite. Podramos pensar que las ver-
siones antiguas no son importantes, ya que la versin que finalmente nos interesa es la
ltima, pero esto no es cierto. El proceso de diseo en VHDL nos permite comparar
fcilmente (incluso de forma automtica) una versin con otra. As, finalizado el dise-
o lgico, podemos realizar una simulacin comparativa entre el modelo que se obtu-
vo durante el diseo arquitectural y el que se ha obtenido durante el diseo lgico. Lo
mismo podramos hacer entre el modelo de las especificaciones y el arquitectural.
FPGA Modelo
prototipo simulacin
Synopsys + Xilinx Synopsys
Cadence
FIGURA 6-6. Versiones o ficheros generados a lo largo de un diseo.

El problema se complica an ms si tenemos en cuenta que los modelos obteni-

dos pueden tener distintas orientaciones. Podramos, por ejemplo, realizar un diseo
lgico con objeto de hacer un prototipo inicial del circuito en una FPGA. Este mo-
delo sera seguramente diferente del que utilizsemos para la fabricacin en silicio,
ya que los estilos de descripcin podran ser diferentes (para adaptarse a la bibliote-
ca de cada fabricante y obtener un mejor resultado en la sntesis). Tambin podra-
mos necesitar modelos diferentes orientados hacia la simulacin. Estos modelos es-
taran optimizados para reducir el tiempo que se emplea en una simulacin, que en
ocasiones puede ser realmente largo (incluso de varios das).
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
informacin referente a diferentes mdulos o componentes. Cada entrada a la
biblioteca, que rene informacin respecto a un componente en particular es un
componente de biblioteca. Cada componente de biblioteca puede disponer de varias
vistas, que se corresponderan con diferentes informaciones o aspectos del compo-
nente. As, el componente de biblioteca podra disponer de modelos VHDL para
simulacin, modelos para sntesis, documentacin, modelos fsicos, etc. En general,
hablaremos indistintamente de componentes, mdulos 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.
Adems, las bibliotecas pueden contener componentes con distintos objetivos.
En primer lugar se dispone normalmente de bibliotecas de recursos; stas son bi-
Docurnentacin
(para usuario) =-~
1" ij
=- Modelo
VHOL
i ~
/
(para simulacin)
Modelo
temporal " Topografa
(para anlisis MUX (para diseo fsico)
de tiempos) '-.........
~/ ~Smbolo
netlst ~ 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. Relacin de jerarqua entre las bibliotecas generadas o usadas en un

diseo.
bliotecas que contienen elementos bsicos utilizados en todos los diseos. 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 sern incluidos dentro
de algn diseo. Podramos tener, por ejemplo, una biblioteca de mdulos perifri-
cos tpicos (mdulos de transmisin/recepcin serie asncrona, puertos de EIS para-
lela, etc.), de la que seleccionamos alguno para nuestro diseo. Tambin estn in-
cluidas en esta categora las bibliotecas de puertas tpicas de los fabricantes.
Finalmente tenemos la biblioteca de diseo; en ella se incluyen todos los ele-
mentos que forman parte de nuestro diseo. 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 sern componentes de cierta comple-
jidad.
La Figura 6-8 muestra la jerarqua existente entre estos tres tipos de biblio-
tecas.
La complejidad de los componentes de biblioteca vara desde puertas hasta mi-
croprocesadores. Las necesidades de gestin 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 caractersticas, las cuales no son necesariamen-
te exclusivas.
En primer lugar se pueden clasificar los componentes atendiendo a su comple-
jidad funcional. As, podramos 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
transmisin/recepcin y otros dispositivos perifricos tpicos.
Alta complejidad: como ncleos de microprocesadores, microcontroladores,
procesadores digitales de seal, coprocesadores, etc.
Aparte de esta primera divisin, los componentes pueden clasificarse atendien-

do a las caractersticas de sus modelos de simulacin o a la forma en que son imple-
mentados en silicio. En cuanto a sus modelos de simulacin, pueden dividirse en:
Precisos: stos son componentes que contienen informacin detallada sobre

su comportamiento, de forma que podemos realizar simulaciones con carac-
tersticas reales (retardos, consumo, rea ... ).
Compatibles: son componentes que contienen informacin completa respec-
to a su funcionalidad pero sin caractersticas reales (tpicamente modelos
RT). Cuando se simulan, estos modelos se comportan igual que el circuito
real en una simulacin basada en ciclos de reloj.
Algortmicos: estos modelos contienen slo la informacin funcional bsica.
Son tiles en aquellas simulaciones que consumen mucho tiempo de CPU.
Podemos pensar, por ejemplo, en la simulacin de un programa complejo en
un microprocesador, o la simulacin de un filtro digital, etc.
En cuanto al mtodo de implementacin en silicio, los componentes se pueden

clasificar en :
Bloques fijos (Hard Blocks): stos son componentes ya implementados que

poseen una descripcin fsica completa (layout) y que pueden ser caracteri-
zados con detalle en cuanto a su rea, retardos o consumo. Estos bloques son
dependientes de la tecnologa.
Listas de puertas e interconexiones (netlists): estos componentes respon-
den a una descripcin estructural del circuito con referencias a celdas preca-
racterizadas del fabricante (puertas, memorias, etc.). Los detalles finales de
la implementacin (retardos de la interconexiones, etc.) no son an conoci-
dos. Estos bloques son dependientes de la tecnologa.
Bloques HDL (Soft Blocks): stos son componentes descritos en un leguaje
de descripcin hardware que sern sintetizados con una biblioteca determi-
nada. En este caso, an no se conoce con detalle la lgica final que se gene-
rar. Estos bloques son independientes de la tecnologa.
Por ltimo, atendiendo a la configurabilidad del componente, stos pueden ser

divididos en:
Componentes cerrados: cuya funcionalidad es fija, independientemente del

modelo de simulacin o la tcnica de implementacin utilizada. Como ejem-
plo, podramos pensar en un contador de O a 13, con inicializacin asncrona.
Genricos: son componentes que poseen algunos parmetros cuantitativos
que no cambian la funcionalidad bsica del componente. Como ejemplo, po-
dramos pensar en el mismo contador de antes, pero con la cuenta final para-
metrizable.
Configurables: son componentes que poseen algn parmetro cualitativo
que s modifica la funcionalidad bsica. Por ejemplo, en el caso del contador,
podra tener un parmetro que hiciese que contase hacia arriba, abajo o que
contase hacia arriba o abajo en funcin de una seal, que tuviese o no inicia-
lizacin asncrona, etc.
6.3.2. La biblioteca de diseo
En el caso de los diseos realizados en VHOL, la biblioteca de diseo consiste, fun-

damentalmente, en un conjunto de ficheros de texto. Estos ficheros contienen la
descripcin VHOL de los componentes que forman el diseo y de los bancos de
prueba utilizados.
Cuando el diseo adquiere una cierta complejidad, o existe m~1>de un disea-
dor en el equipo, es necesario establecer mecanismos para que todos los diseado-
res accedan a la informacin correcta. Supongamos que en nuestro equipo de dise-
o (el que est diseando la mquina de refrescos) trabajan dos personas. Uno
podra estar dedicado a la circuitera encargada de la gestin del cobro y devolucin
de monedas mientras el otro podra estar a cargo de la parte relacionada con la pro-
gramacin 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 errneas, obsoletas, o que los dos diseadores 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 estn disponibles. Por ello, a continuacin se muestra un procedimiento bsico
que puede valer como idea sobre cmo organizar la biblioteca de diseo.
La Figura 6-9 muestra el caso de un diseo en el que existen dos diseadores.
Cada diseador 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 diseo) donde se van dejando los resultados de cada mdulo una vez que se
cree terminado. La biblioteca de diseo dispone adems de un fichero con la infor-
macin referente a los mdulos incluidos, quin los dise, versin, etc. El director
del equipo de diseo ser el encargado de gestionar la biblioteca. Existen tres pro-
cedimientos bsicos de actuacin sobre la biblioteca; insercin, extraccin y actua-
lizacin.
Cuando un elemento del diseo ha sido terminado se inserta en la biblioteca
global, quedando a partir de ese momento accesible al resto de los diseadores. Si
Mod_1,beld
Nombre: VmeTypes.vhd
E\ _ Versin: 3.1
Fecha: 13/02195
Autor: J. Snchez, y. Torroja
Descripcin: Tipos bsicos del diseo
Mdulo 1 ~-- ~ Pararn.vhd Dependencias:--
.--U "<, - Funcs.vhd
_
~
Types.vhd I
I ~
Nombre: VmeFuncs.vhd
Versin: 3.2~
vmeOttier.vhdE ...... E-~ . ~= ->
_______
MasterTB.vhd Master.vhd
-;- -
-~
I
~ Master.vhd
~ 8 lE Design.bdd
[i\: : ~-~
M: N.belda : / \ ~
MduloN
~
/T.~ /.~~.
~ . ~ I
!,~E
Funcs.vhd
~lhd
lZJ ~ ~_. ~ .
Inter.vhdSlave.vhd Types.vhd
(copia)
Base de datos
(directorio)
E
Fichero
local
Fichero
global
Procedimiento
de gestin
(modificable) (no modificable) de la BDD
FIGURA 6-9. Organizacin de una biblioteca de diseo.
un diseador necesita trabajar con un mdulo de la biblioteca no tendr ms que re-

ferenciarlo dentro del mdulo que est realizando. Si un diseador necesita realizar
alguna modificacin sobre un mdulo 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-
zacin posiblemente requerir que el resto de los diseadores realicen cambios
sobre sus mdulos, por lo que este tipo de modificacin 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 gestin de la biblioteca de
diseo.
Los procedimientos de gestin de la biblioteca, como cualquier procedimiento
de gestin, deben adaptarse a la complejidad del diseo. En diseos pequeos, o
con pocos diseadores, pueden no ser absolutamente necesarios e incluso introducir
demasiada carga de trabajo. Por el contrario, si el diseo es grande o el nmero de
diseadores es elevado, no utilizar estos procedimientos puede hacer impracticable
el desarrollo del proyecto.
oc => Componente del diseo

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 cdigo VHOL
.bdd => Fichero de informacin de la BDD
FIGURA 6-10. Operaciones bsicas en la gestin de una biblioteca de diseo.
6.3.3. Gestin de bibliotecas. Versiones y configuraciones
El nmero de modificaciones que se realizan a lo largo del diseo de un mdulo en

VHDL puede ser realmente elevado. No es difcil encontrar que un determinado
componente ha sufrido un centenar de cambios desde su concepcin inicial a su
versin final, Durante este proceso de creacin la funcionalidad del componente es
modificada, y no siempre con buenos resultados. A menudo nos encontramos que la
ltima modificacin introducida no da los resultados esperados y que la anterior
versin del diseo funcionaba mejor. No hay experiencia ms frustrante que no po-
der recuperar la anterior versin de un diseo porque no recordamos dnde y cmo
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
diseo estn correctamente archivadas, y de que siempre son recuperables. De esta
manera, cualquier modificacin que no sea satisfactoria puede ser anulada y la ver-
sin correcta recuperada.
6.3.3.1. Control de versiones
Consideramos una versin como cada uno de los estados por los que va evolucio-
nando una vista de un componente. En nuestra mquina de refrescos, por ejemplo,
el modelo arquitectural puede haber sufrido mltiples modificaciones (que terica-
mente daban resultados correctos) hasta llegar a la versin final. Cada uno de esos
diseos intermedios es una versin. Si de un determinado componente obtuvira-
mos una descripcin para sntesis y otra para simulacin, consideraramos que son
vistas diferentes del mismo componente, y no distintas versiones. Tendran, por tan-
to, distinto nombre, aunque podran tener las mismas versiones (por ejemplo, podra
haber una versin 1.35 de ambos modelos).
Existen infinidad de mtodos para mantener un cierto control sobre las diferen-
tes versiones del diseo 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 versin defini-
tiva, o cuando la magnitud de los cambios a introducir nos hacen pensar que la
vuelta atrs va a ser complicada. Este procedimiento, sin embargo, presenta multi-
tud de inconvenientes y a menudo se vuelve intil cuando el nmero de modifica-
ciones que se realizan sobre el diseo es elevado, o el nmero de personas trabajan-
do sobre el diseo es grande.
Para realizar un control de versiones, lo primero que hay que definir es cules
son los ficheros que se mantienen bajo el control de versiones. Mantener todos los
ficheros que se utilizan durante el diseo sera un gasto intil, ya que muchos de
ellos pueden generarse a partir de otros mediante programas. Mantener un conjunto
mnimo tampoco es una buena idea, ya que la generacin 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 automtica a partir de otro fichero. Un ejemplo claro de
ficheros fuente son la mayora de las descripciones VHDL; stas son fruto de la
creatividad del diseador. Por el contrario, los ficheros objeto son aquellos que pue-
den obtenerse de forma automtica a partir de un fichero fuente. Un ejemplo claro
podran ser los resultados de un proceso de sntesis automtica.
Todos los ficheros fuente deberan estar bajo el control de versiones. Los ficheros
objeto pueden no estar bajo control, aunque s puede ser conveniente si el proceso de
generacin de los ficheros objeto es largo o complejo (un proceso de sntesis y optimi-
zacin 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 diseados.
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 diseo es nece-
sario repetir la misma accin varias veces (podemos pensar en el procedi-
miento de anlisis de los ficheros VHDL y su simulacin posterior). Para

ello, lo habitual es utilizar ficheros de comandos, donde se detallan los pasos
a realizar de forma automtica. Guardar estos ficheros no slo permite repe-
tir los pasos realizados, sino que adems sirve como documentacin de cmo
se han realizado las diferentes tareas del diseo.
Adems de estos archivos fuente es conveniente mantener bajo control algunos

archivos objeto:
Vectores de simulacin: aunque estos ficheros pueden generarse de forma

automtica, 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 razn, es
interesante mantener estos ficheros. Por otro lado, estos ficheros son el resul-
tado de un proceso de sntesis, que a menudo resulta costoso y difcil.
Topografia: este es el resultado final del diseo 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.
Adems de los ficheros descritos, es necesario mantener un control de versio-

nes de la documentacin que se va generando durante el proyecto. Normalmente, el
procedimiento de control de la documentacin 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 bsicas 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 estn pensa-
das para el mantenimiento de ficheros de texto. Pueden valer para mantener fiche-
ros binarios, pero en este caso los sistemas de compresin utilizados hacen que el
archivo de las diferentes versiones sea menos compacto.
Las versiones suelen identificarse mediante dos nmeros; el nmero de versin
y el numero de edicin. Los cambios en el nmero de edicin implican correcciones
menores, reparacin de problemas, etc., pero no cambios en la funcionalidad o la
interfaz de un bloque. Si hablamos de documentos, los cambios en la edicin supo-
nen correcciones ortogrficas o mejoras en la redaccin de algunos puntos. Por el
contrario, los cambios de versin suponen cambios mayores, tanto en funcionali-
dad, interfaz de un bloque o, si hablamos de documentos, introduccin de nuevos
prrafos o modificaciones importantes de los existentes.
6.3.3.2. Control de configuraciones

Consideramos una configuracin 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 existan en un determina-

do momento de la historia del diseo. La Figura 6-11 muestra grficamente el con-
cepto de configuracin comparado con el concepto de versin.
Como se ve, un determinado componente puede ir evolucionando a travs de
distintas versiones. Al principio del proyecto, en la figura, el diseo (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 cmodo para rea-
lizar la validacin 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 cdigos de opera-
cin, con lo que se han de modificar tambin 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 encontraramos con
que no es posible. Tampoco podramos, por ejemplo, recuperar la primera versin
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 diseo. Cuando se recupera una determinada versin de un
componente deberan recuperarse tambin todas las versiones necesarias para su
operacin.
01
ASIC
diseo
05 Banco de Pruebas
FIGURA 6-11. Configuraciones y versiones en la gestin del diseo.

01
ASIC
diseo
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 consideracin 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 solucin es
mantener versiones ficticias de los ficheros que configuran un diseo. La Figura 6-12
muestra cmo se aplicara esto al ejemplo anterior.
En la figura, los rectngulos en color claro reflejan diferentes versiones de un
fichero. Los rectngulos en color oscuro reflejan versiones ficticias (se ha generado
una nueva versin, aunque no ha habido modificacin 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
configuracin del diseo consiste en recuperar la misma versin de todos los fiche-
ros del diseo. Este mtodo, aunque vlido, oculta en cierta medida la historia del
componente (un determinado mdulo tiene muchas ms versiones de las que real-
mente se han producido).
6.4. DISEO PARA REUSABILIDAD
El trmino reusabilidad pretende reflejar la facilidad con la que un diseo previa-

mente realizado puede ser utilizado de nuevo, probablemente para otra aplicacin,
con otra tecnologa y por diferente equipo de diseo.
6.4.1. Por qu hacer diseos reutilizables?
El coste de desarrollo de los diseos y componentes actuales, as como la disponibi-

lidad de herramientas de sntesis y la tendencia actual a crear mercados abiertos, ha-
cen cada vez ms atractiva la idea de la reutilizacin de componentes previamente
diseados. Estos componentes pueden haber sido diseados como parte de un pro-
yecto y reutilizados posteriormente, o generados de forma explcita como compo-
nentes de biblioteca para su posterior reutilizacin. En ambos casos, la reutilizacin
de estos componentes presenta una serie de requisitos y problemas que es necesario
resolver.
La reutilizacin de los componentes presenta ventajas claras en multitud de as-
pectos. Por un lado, reduce los costes de diseo 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 ms atractivos sus productos. Al usuario
final le permite acceder a una tecnologa ms barata. Por otro lado, los componen-
tes previamente diseados (y previamente utilizados) tienen mayores garantas 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 diseador, que ofrece productos de mayor calidad, au-
mentando su clientela.
Pero no slo es importante la reduccin del coste del desarrollo. La gran com-
petencia del mercado electrnico 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 slo porque otros productos de la competencia le arrebaten parte del mismo, sino
porque la rpida evolucin de las tecnologas 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 diseo y evitar este tipo de problemas.
Sin embargo, no debe pensarse slo en los componentes reutilizables como
mdulos diseados con la idea de ser comercializados e incluidos en otros diseos.
Utilizar ciertas tcnicas de diseo que faciliten la reutilizacin de un componente
puede aportar grandes ventajas en el desarrollo de un circuito incluso si no se est
pensando en su posterior reutilizacin. La experiencia muestra que, en la mayora
de los diseos, aparecen imprevistos que obligan a modificar el diseo 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 difciles de cuantificar o pre-
ver. Esto obliga a mantener ciertos parmetros del diseo abiertos hasta que un an-
lisis ms detallado permita definirlos. Un ejemplo tpico podra ser el nmero de
bits necesarios para codificar los datos o los coeficientes en un filtro digital. Aspec-
tos como el rea, el consumo, o la mxima frecuencia de funcionamiento pueden
obligar a cambiar algunas de las caractersticas que se haban fijado inicialmente
para el diseo. Algunas de las tcnicas que se exponen en los siguientes apartados
pueden ayudar a que estos cambios y modificaciones a lo largo del ciclo de diseo
repercutan lo menos posible en el tiempo de desarrollo y en la calidad y fiabilidad

del circuito diseado.
Si, por el contrario, el objetivo de un diseo es que ste pase a formar parte de
una biblioteca de componentes reutilizables, habr que considerar algunos aspec-
tos adicionales a los puramente tcnicos. En este caso hay que tener en cuenta que
para que un diseo sea reutilizable no slo es necesario que sea correcto en los as-
pectos funcionales, sino que adems debe satisfacer una serie de requisitos en
cuanto a su documentacin, su portabilidad entre herramientas, su facilidad de
mantenimiento, etc. Estos aspectos tambin sern tratados a continuacin.
6.4.2. La comercializacin de una biblioteca
Los requisitos que un componente de biblioteca debe satisfacer dependen de quin

los utilice y cmo 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 preocupacin ser posiblemente la integracin sin problemas del componente
en su flujo de diseo. Esto implicar que el componente est disponible para sus he-
rramientas, que exista una buena documentacin, etc. Si atendemos al punto de vis-
ta del diseador, es decir, la persona que desarrolla el componente para su posterior
comercializacin, su mayor preocupacin ser encontrar mtodos para proteger y
comercializar su biblioteca, mtodos para facilitar el mantenimiento y depuracin
de errores, etc. Si pensamos en la fabricacin del circuito, estaremos ms interesa-
dos en el test de fabricacin y, por tanto, en la existencia de vectores de test para el
componente y mtodos para aplicarlos cmodamente. Por ltimo, si nos fijamos en
el punto de vista del comercial, es decir, la persona que va a vender el componente,
seguramente estar ms preocupado en la fiabilidad del componente, el soporte tc-
nico, cmo ha resultado su utilizacin en otros diseos, etc.
Teniendo en cuenta todos estos aspectos, podemos elaborar una lista de requisi-
tos que todo componente debera satisfacer para que resulte industrialmente reutili-
zable.
Interoperabilidad: el componente debera 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 sntesis como
en simulacin).
Documentacin: una de las claves de la reusabilidad es disponer de una
buena documentacin, consistente en:
- Documento de diseo: es el documento ms importante para el diseador
y/o la persona encargada del mantenimiento y depuracin del componente;
contiene toda la documentacin relativa a cmo se ha desarrollado el com-
ponente, explicacin de la arquitectura, cdigo VHDL, etc.
- Gua de referencia: algunos componentes de biblioteca pueden ser extre-
madamente complejos. Si estos componentes son configurables, su utiliza-
cin puede requerir la seleccin correcta de diferentes parmetros por parte
del usuario. En estos casos puede ser necesaria una gua donde se describa
cmo configurar, simular y sintetizar correctamente el componente.
- Hoja de catlogo: al igual que ocurre con los componentes discretos, dis-
poner de una hoja de catlogo facilita la consulta y seleccin del compo-
nente por parte del usuario. Esta hoja debera contener toda la informacin
necesaria para la seleccin y operacin del componente.
- Notas de aplicacin: los ejemplos son una ayuda ideal a la hora de utilizar
un componente. Debera haber notas de aplicacin disponibles tanto para el
uso del componente de biblioteca (especialmente si ste es configurable)
como para su operacin.
- Problemas y soluciones: las descripciones VHDL se encuentran a mitad
de camino entre el software y el hardware. Si el componente es complejo,
podra tener algunos errores que, aunque no impidiesen su utilizacin, es
necesario conocer y plantear alternativas para su solucin.
Soporte tcnico y mantenimiento: como en cualquier otro producto, estos
factores son crticos para la comercializacin del componente.
Estimadores: cuando los componentes son genricos o configurables, el di-
seador necesita encontrar la mejor combinacin de parmetros que satisfaga
sus requisitos. En estos casos no resulta factible sintetizar el componente ba-
jo cada posible combinacin de parmetros, ya que el tiempo empleado en la
sntesis puede ser elevado. Resulta, por tanto, muy til disponer de estimado-
res fiables de rea, retardos o consumo.
Herramientas de configuracin: en diseos configurables complejos pue-
den necesitarse herramientas que ayuden al usuario a configurar el compo-
nente de acuerdo a sus requisitos.
Herramientas de validacin: en componentes de mediana o alta compleji-
dad pueden hacerse necesarias funciones que faciliten al usuario la simula-
cin del circuito o del sistema completo. Podramos imaginar, por ejemplo,
un usuario que est utilizando un transmisor/receptor sncrono de una deter-
minada biblioteca de componentes. Para comprobar que el componente fun-
ciona o es operado correctamente, le sera muy til disponer de funciones en
VHDL que le permitiesen transmitir mensajes hacia el componente correcta-
mente formateados (con la velocidad de transmisin adecuada, el CRC aa-
dido, etc.). En otros casos, cuando la complejidad del componente de biblio-
teca hace poco recomendable la simulacin a nivel RT, sera conveniente
disponer de modelos algortmicos o de alto nivel de la celda.
Soporte para la deteccin de errores: los componentes de biblioteca van a
estar normalmente inmersos en diseos ms complejos, y estarn controlados
por otros componentes o partes de la lgica del circuito. Al igual que en los
componentes ms simples (biestables, puertas) existen mtodos 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 mtodos para detectar operaciones errneas por
parte de la lgica que lo opera (por ejemplo, una secuencia incorrecta de se-
ales, valores no controlados en buses, etc.).
Soporte para el test de fabricacin: cada componente debera disponer de

un conjunto de vectores de test, o una circuitera de autotest, para realizar el
test de fabricacin. 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 configuracin escogida.
La interoperabilidad, documentacin o soporte tcnico son requisitos que pue-

den ser satisfechos con mayor o menor esfuerzo. Sin embargo, hoy por hoy, el resto
de los requisitos son ms difciles de cumplir.
A la hora de desarrollar una biblioteca de componentes para su comercializa-
cin, deben valorarse con cuidado estos factores. Satisfacer estos requisitos puede
implicar un esfuerzo considerable, lo que en algunos casos puede hacer econmica-
mente inviable el desarrollo. .
De cualquier manera, la complejidad de los diseos actuales hace cada vez ms
atractiva la idea de su reutilizacin y comercializacin. En este sentido, cada da se
dedica un esfuerzo mayor al diseo 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
diseo. Estos componentes no suelen ser genricos o configurables, sino que res-
ponden a un esquema de componente cerrado (funcionalidad fija) con modelos de
simulacin precisos o compatibles, y en muchos casos ofertados como bloques fijos
(hard blocks).
Hoy en da es posible acceder a estas celdas IP con dos objetivos fundamenta-
les: disponer de modelos para simulacin y de modelos para fabricacin.
Los modelos para simulacin nos permitirn analizar el comportamiento de
un sistema que incluye este tipo de celdas o circuitos. Por ejemplo, si vamos a di-
sear un circuito que interacta 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 simulacin en VHDL de diferentes com-
ponentes (microprocesadores, microcontroladores, circuitos perifricos, lgica
discreta, etc.).
Los modelos para fabricacin nos permitirn no slo simular el comportamien-
to del sistema sino tambin fabricar el circuito una vez diseado. En este caso, el
nmero de casas que distribuyen este tipo de componentes es ms limitado, ya que
requiere el soporte de un fabricante que ser el que finalmente producir el circuito
que diseemos con la celda IP inmersa en l. Esto obliga a que el diseo se realice
con un determinado fabricante, lo que en algunos casos dificulta el diseo (por
ejemplo, podramos querer disear el circuito en tecnologa ECL, pero slo dispo-
ner de las celdas IP que deseamos en tecnologa 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 tecnologa. Sin embargo, en
el caso de celdas IP complejas, la sntesis automtica no resulta econmicamente

viable en la mayora de los casos. Las celdas ofertadas como bloques fijos (hard
blocks) estn normalmente implementadas de forma muy optimizada (mediante es-
tructuras tipo data-path, generadores de estructuras regulares, e incluso tcnicas de
diseo totalmente a medida ofull-custom), con lo que resultan mucho ms rentables
que las que se obtendran mediante una sntesis automtica.
La utilizacin de celdas IP est generando una nueva corriente de diseo que se
aleja del diseo actual a la medida, volviendo a un diseo similar al que se realizaba
mediante componentes discretos. No debe pensarse, sin embargo, que esto es un
paso atrs. La tendencia actual es utilizar el mayor nmero posible de celdas IP, ya
diseadas, y disear la lgica imprescindible para unir las celdas IP o incluir la
funcionalidad no disponible. La diferencia fundamental con el proceso de diseo
basado en componentes discretos es que ahora, gracias a los lenguajes de descrip-
cin de hardware, es posible simular el sistema completo antes de proceder a su
fabricacin.
La utilizacin de celdas IP, que a menudo contienen decenas e incluso cientos
de miles de puertas, est imponiendo nuevos desafos al proceso de diseo. 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 (algortmi-
cos, de juego de instrucciones, etc.) de los componentes. Con estos modelos se
podr realizar la simulacin del sistema completo a un coste razonable.
6.5. DISEO GENRICO
Una de las ventajas fundamentales de los HDLs es que permiten, de forma sencilla,
generalizar el diseo. As, cuando se disea un componente, ciertos valores pueden
quedar como parmetros que se concretarn ms adelante en el proceso de diseo.
Ejemplos tpicos son el final de cuenta de un contador, el ancho del bus de un regis-
tro paralelo, el nmero de bits de una ALU, etc.
Esta facilidad para dejar ciertos datos como parmetros permite la reutilizacin
del componente en diseos posteriores. Adems, permite que parte de las especifi-
caciones del diseo queden abiertas, 10 que facilita la toma de ciertas decisiones
que, en otro caso, podran restringir el desarrollo.
Pero para aprovechar al mximo estas posibilidades es necesario considerar
ciertos aspectos y mantener unos procedimientos de trabajo que garanticen que el
esfuerzo invertido en realizar el diseo genrico va a ser aprovechable posterior-
mente.
En este apartado se dan una serie de recomendaciones sobre cmo realizar un
diseo genrico y cules son sus ventajas e inconvenientes.
6.5.1. Definicin de diseo genrico
En primer lugar, conviene acotar qu entendemos por diseo genrico, ya que exis-
ten diferentes interpretaciones de este concepto.
A lo largo del apartado se entender que un diseo genrico es aquel en el que

se pueden variar ciertos parmetros del diseo sin variar la funcionalidad a nivel
RT del mismo. Paralelamente se puede hablar de diseos configurables, en donde
la variacin de ciertos parmetros afecta de forma que el diseo s cambia su fun-
cionalidad a nivel RT.
El siguiente ejemplo puede clarificar estos conceptos. El cdigo del Listado 6-13
muestra un contador sncrono 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(gMaxBts - 1 downto O)
);
end AscDescContador;
architecture Sllple 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(gMaxBts -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. Cdigo de contador ascendente/descendente.

En el contador, la mxima cuenta es un parmetro (gMaxBits) cuyo valor se fi-

jar con posterioridad. En este caso, el valor del parmetro no afecta al esquema
funcional a nivel RT y slo cambia el nmero de bits del contador.
Sin embargo, en el siguiente ejemplo se muestra el mismo contador con un pa-
rmetro adicional (gTipo) en funcin del cual se generar un contador ascendente,
descendente o ascendente/descendente.
entity ContadorGenrico 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 ContadorGenrico;
architecture Simple of ContadorGenrico 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_vectr(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 IntCenta = 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. Cdigo de contador genrico.
En este caso, la funcionalidad del componente cambia al cambiar el parmetro.

Este sera el caso de un componente configurable frente al componente genrico
del ejemplo anterior.
6.5.2. Ventajas e inconvenientes del diseo genrico
Los cdigos mostrados en el apartado anterior son un ejemplo de diseo genrico o

configurable. Sin embargo, no muestran las ventajas ni los inconvenientes que se
obtienen al escribir cdigo de esta manera.
Antes de describir estas ventajas e inconvenientes es necesario diferenciar en-
tre dos tipos de diseos genricos; aquellos diseos en los que slo son genricos
alguno de los parmetros (parcialmente genricos) y aquellos (totalmente genri-
cos) en los que se parametrizan todos los valores que admitiran un valor genrico.
A lo largo del apartado hablaremos de diseos totalmente genricos, mientras
no se especifique 10 contrario.
Las ventajas fundamentales del diseo genrico son:
Permite mantener las especificaciones abiertas. Puesto que los valores que
aparecen en el diseo son variables, es posible esperar a etapas ms tardas
del diseo 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 especificacin. Un excesivo nmero de grados de libertad o deci-
siones retardadas puede acarrear ms inconvenientes que ventajas.
Evaluacin de alternativas. Al poder modificar los parmetros del diseo,
es posible evaluar alternativas que, en principio, podran no haber sido con si-
deradas. Este aspecto tiene especial relevancia cuando en las ltimas etapas
del diseo surgen restricciones (rea, tiempo, cambio de tecnologa) que
obligan a tomar soluciones de compromiso. En general, estas restricciones
no son consideradas en las primeras etapas del diseo. Realizar un diseo ge-
nrico lleva implcita su consideracin.
Anlisis exhaustivo del diseo. Realizar un diseo genrico implica que el
componente a disear debe funcionar bajo todos los valores posibles de sus
parmetros. Esto requiere por parte del diseador un anlisis del problema
mucho ms exhaustivo que cuando se disea el mismo componente para
unos valores fijos de sus parmetros. Adems, el diseo genrico impone
unas pruebas funcionales que no slo verifican la funcionalidad del compo-
nente sino tambin el comportamiento del mismo al variar los parmetros.
Todo esto redunda en una verificacin mucho ms exhaustiva del componen-
te y unos bancos de prueba ms depurados.
Organizacin del diseo. De igual manera que el diseo genrico exige al
diseador un anlisis ms profundo del componente que est diseando, tam-
bin requiere del equipo de diseo una mejor organizacin de los ficheros, ti-
pos de datos, constantes del diseo, etc. Esta mejor organizacin redunda en
un ahorro importante de tiempo, especialmente si 'el equipo de diseo 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 documentacin. Parte de la do-
cumentacin del diseo la constituye el propio cdigo HDL. Cuanto ms le-
gible sea el cdigo, ms fcil resultar su interpretacin y modificacin. El
realizar un diseo genrico implica que los valores constantes que normal-
mente aparecen en el cdigo son sustituidos por nombres de parmetros,
expresiones, etc. Si estos nombres y expresiones son escogidos bajo ciertas
reglas, su lectura e interpretacin ser sencilla, facilitando as la consulta y
mantenimiento del cdigo por personas distintas a las que lo realizaron.
Simplificacin del cambio de tecnologa (retargeting). La utilizacin de
HDLs permite, en teora, realizar diseos independientes de la tecnologa en
la que finalmente se implementar el circuito. En la prctica, esto no siem-
pre es cierto. Factores como la velocidad, el consumo, la biblioteca o la ca-
pacidad de integracin, obligan a redisear muchas de las partes de un
circuito al cambiar de tecnologa. Es necesario, por tanto, escoger la tecno-
loga objetivo lo antes posible en el proceso de diseo. Sin embargo, la ex-
periencia muestra que, en muchos casos, es necesario cambiar la tecnologa
objetivo (bien sea por factores tecnolgicos, econmicos o polticos) cuan-
do se est bastante avanzado en el proceso de diseo. De nuevo, el diseo
genrico permite reducir los efectos negativos de estos cambios al permitir
el redimensionamiento sencillo de ciertos aspectos del diseo. Conviene in-
sistir, sin embargo, en que los cambios de tecnologa pueden suponer modi-
ficaciones muy importantes en el diseo y que deben evitarse en la medida
de lo posible.
El diseo genrico presenta, por otro lado, una serie de inconvenientes que es
necesario valorar:
Complejidad del cdigo. En algunas ocasiones, el realizar un componente

genrico implica que en el cdigo se han de utilizar construcciones un tanto
artificiosas y difciles de seguir para el no iniciado. En este caso deben valo-
rarse con cuidado las ventajas del diseo genrico frente a la legibilidad del
cdigo. En cualquier caso, una buena documentacin y un cdigo bien co-
mentado ayudan mucho a su comprensin.
Dificultad en las pruebas. Realizar un diseo genrico implica que han de
realizarse pruebas funcionales para los diferentes valores que puedan tomar
los parmetros. Esto implica, a su vez, que los bancos de prueba deben ser
tambin genricos, lo que supone una dificultad adicional y una nueva fuente
de errores. Si bien esto redunda en un anlisis ms profundo del diseo, pue-
de suponer un freno excesivo en algunos casos. Por otro lado, el nmero de
pruebas a realizar puede dispararse. Es necesario valorar con detalle estos
aspectos con objeto de llegar a una solucin de compromiso entre el coste de
desarrollo y los beneficios esperados.
Tiempo de desarrollo. En general, ste es el aspecto ms difcil de valorar.
En un principio, el diseo genrico implica un tiempo mayor de desarrollo.
Sin embargo, esta inversin de tiempo en las fases iniciales del diseo va a
suponer un ahorro importante en las etapas finales, especialmente si surgen
problemas no contemplados inicialmente. Aspectos como la capacidad de los
diseadores, la tradicin del equipo de diseo en esta filosofa de trabajo, la
complejidad del diseo, etc., deben ser considerados para valorar la viabili-
dad de este enfoque. La experiencia del equipo en algn diseo de estas ca-
ractersticas puede ayudar en gran medida.
Prestaciones del resultado. En algunos casos, la generalidad en el diseo va
a requerir un compromiso respecto a las prestaciones del mismo. Si el diseo
se encuentra muy al lmite de la tecnologa, las soluciones a cada problema
sern demasiado particulares como para permitir un diseo genrico.
Como conclusin cabe decir que el diseo genrico puede paliar en gran medida
los problemas inesperados que se presentan en las etapas finales del proceso de dise-
o. Su realizacin 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 diseo. Slo si el diseo est absolutamente cerrado en
las especificaciones, puede tener sentido no realizar el diseo con esta aproximacin.
6.5.3. Desarrollo de componentes genricos.

Recomendaciones
Las recomendaciones y ejemplos que a continuacin se exponen han sido proba-

das con un determinado sintetizador y/o simulador. En un principio, estas reco-
mendaciones podran no ser aplicables para otras herramientas. Sin embargo, s

pueden dar una idea del objetivo que se pretende conseguir realizando diseos ge-
nricos.
6.5.3.1. Organizacin del diseo
Existen muchas maneras diferentes de realizar un diseo genrico. En general, con-

viene diferenciar dos casos que requieren un planteamiento diferente: el diseo de
un componente y el diseo de un circuito o dispositivo completo.
Diseo de un componente aislado. En este caso el objetivo del diseo gen-

rico ser realizar un componente reutilizable. El procedimiento ms cmodo
en este caso es utilizar genricos (generic) del VHDL como procedimiento
para pasar parmetros.
En estos casos debe tenerse en cuenta que el interfaz con el exterior se
har a travs de tipos estndar (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 parametrizacin de componentes. Sin embargo, el diseo
genrico presenta ms ventajas en el caso de diseos completos.
Diseo de un circuito o dispositivo completo. En este caso el planteamien-
to debe ser ms riguroso, aunque los beneficios tambin son mayores.
Se organizar el diseo de forma que exista un fichero donde se definan todos

los tipos bsicos y constantes utilizados en el diseo. El control y modificaciones de
este fichero son responsabilidad del jefe del equipo de diseo.
El siguiente cdigo 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 gestin del diseo 41 7
------------------------ ...------------------------_-----~,...-."1 ..:_-.-~

_.:.Constantes definidas para la cceuncecn 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 tCoefPiliibra 1s stq_logic_vector
(cBitsCoef - 1 downto O):
type tCefsVector 1s array (integr 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 cPalabrasPorAccs02 - 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 mximo
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 tBancoDeMximos 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 parmetro
----------------------------------------------------_'--;.. .. ~_,.~:"l'"
functiOl1 log~ (Etapas : integer) retuzn integer;
constant cAnchoAculIIl : integer := catstatos +

cBitsCoet +
lqg2 (cMaxNumEtapas1) i
constant cAnchPAcum2 integer:= eBitsDatos +
cSltsCoef +
t6g2 (cMaxNunEtapas2)
end TiposBasicos;
LISTADO 6-15. Cdigo del paquete de definicin de constantes y tipos bsicos.
Ntese que en el fichero, adems de incluir constantes y definiciones de tipos,

se incluyen tambin funciones que permiten generar, a partir de las constantes,
otros valores o estructuras de datos que facilitarn la posterior descripcin de los
mdulos. 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 diseo de
mediana complejidad se generar un gran nmero 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. Seleccin de parmetros

Uno de los aspectos crticos al realizar un diseo genrico es la seleccin de los pa-
rmetros que pueden ser variables en el diseo y que, por tanto, sern incluidos en
el fichero de tipos bsicos y constantes. Como criterio general se puede decir que
deberan definirse como valores genricos todas las constantes que aparecen en el
cdigo. En un principio, este planteamiento podra 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 ms interesan-
te que aparezcan en el cdigo como nombres, que no como un nmero cuyo valor
puede no comprenderse.
El cdigo del siguiente listado muestra un ejemplo de la definicin de la enti-

dad de un filtro digital en el que se han incluido como parmetros todo lo que
podra ser variable (el significado de las constantes y su valor est definido en
el fichero de constantes y tipos bsicos, 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.rf:;, 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 Configuracin
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 Operaciri
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 genrica de un filtro digital.

Si no se quieren variar los valores de los parmetros en ningn caso, este pro-
cedimiento simplemente aporta una mejor organizacin del diseo y una mayor le-
gibilidad del cdigo.
Si se desea que el componente funcione para diferentes valores de los parme-
tros, habr que escribir el cdigo en consecuencia. Esto requiere analizar qu valo-
res son aceptables, dependencias entre los parmetros, etc. En la mayora de los
casos, esto no presenta problemas, especialmente si se ha diseado una buena
estructura de datos. Sin embargo, existen algunos casos donde la generalizacin
resulta un tanto engorrosa. El siguiente cdigo muestra un ejemplo tpico.
-,..._------.... _----~:_---------------_.-----------------_ ... ----_----_ .. _-----------

.-- 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.
-- Slo hay parte baja
COND2: if gBitsMaxNurnMuestras<= g/Il.).ChO~SDatosgenerate

LECTURA2 : process (Serccion,' LirParteAlta, 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 tamaos en buses.

En este componente existen unos registros internos que pueden ser ledos por
una CPU. El tamao de los registros es parametrizable y su ancho no guarda rela-
cin 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 cdigo Listado 6-17). Incluso en el caso en el que el bus
de la CPU sea menor que el ancho de los registros, cabra plantearse que los regis-
tros fuesen de un tamao tal que el acceso por parte de la CPU tuviese que hacerse
en tres o cuatro ciclos. Esto obligara a considerar nuevos casos en la escritura del
cdigo.
Al elegir los parmetros conviene, por tanto, imponer restricciones realistas a
los valores que pueden tomar los parmetros, de forma que exista un equilibrio en-
tre el coste del desarrollo y los beneficios previsibles.
Una posible regla para seleccionar qu parmetros incluir sera entonces con-
siderar todas las constantes que aparecen en el diseo, para escoger con cuidado
los mrgenes de variacin de los parmetros 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 diseo
El particionado del diseo puede influir, desde el punto de vista del diseo genri-
co, en dos aspectos fundamentales. Por un lado, va a influir en las estructuras de
datos (los tipos de las seales) que sean necesarios en el diseo, ya que la particin
influye en el nmero y tipo de seales que se comunican entre bloques. Por otro
lado, el cmo se realice la particin y se distribuyan las unidades funcionales en
los bloques va a determinar la facilidad o dificultad con la que se realicen modifi-
caciones al diseo. Es decir, la facilidad con la que podr hacerse que los parme-
tros puedan cambiar su valor y, por tanto, que el diseo genrico resulte realmente
til.
El particionado ptimo depende en gran medida de la aplicacin que se est
considerando, aunque pueden darse una serie de recomendaciones tiles.
La mayora de los bloques funcionales disponen de unidades operacionales
(ALUs, multiplicadores, etc.), registros programables y seales tpicas de control
para la carga o lectura de los registros y para la sincronizacin de las operaciones.
Una particin que da buenos resultados consiste en establecer una jerarqua donde
las unidades operacionales estn 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 nmero pequeo de bloques. Sin embargo, estas solucio-
nes no son siempre vlidas o fcilmente aplicables. En cualquier caso, conviene que
el nmero de bloques no sea excesivo (tres o cuatro es un buen nmero).
El particionado puede influir en la ubicacin 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 diseo genrico comprometa las prestaciones.
6.5.3.4. Estructuras de datos
Cuando se realiza un diseo genrico se debe prestar gran atencin a la definicin

de la interfaz (port) en las entidades. Las ventajas del diseo genrico se pierden si
al modificar el valor de algn parmetro 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 modificacin de los
parmetros, dentro de sus valores permitidos, slo implique una recompilacin del
cdigo, pero nunca una reedicin del mismo (salvo, claro est, el fichero de tipos
bsicos 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 simulacin y sntesis 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 (bsicamente herramientas de dise-
o fsico y simulacin a nivel de puertas) se realiza de forma adecuada.
En el cdigo 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 idnea una estructura matricial. El n-
mero de ciclos que tarda en ejecutarse la operacin, as como el tamao final del
banco de coeficientes y el nmero de bits de stos, estarn definidos en el paquete
de tipos bsicos y constantes (ver Listado 6-15) y podrn 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:XNumEtapsl;
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. Utilizacin 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 definicin est en el paquete

-- de tipos bsicos 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. Utilizacin de estructuras tipo registro.
En este caso, las seales de seleccin se han incluido en una estructura tipo regis-
tro (record). De esta forma, una posible inclusin futura de una seal de seleccin no
modifica la interfaz, reduciendo el riesgo deerrores. La definicin de las seales que
contiene la estructura record se realiza en el paquete de tipos bsicos y constantes.
El objetivo de estas estructuras de datos es que sean lo suficientemente flexi-
bles como para permitir cmodamente la variacin de los parmetros. Al mismo
tiempo deben facilitar el que posibles modificaciones afecten al menor nmero
posible de ficheros o entidades. "
6.5.3.5. Otras recomendaciones sobre la codificacin

La codificacin en VHDL de componentes genricos presenta algunos problemas
de tipo prctico que es necesario solucionar. En los siguientes apartados se dan
algunas soluciones a problemas tpicos que aparecen al realizar diseos genricos.
6.5.3.5.1. Problemas con los buses

Al hacer genricas las dimensiones de los buses aparecen, en algunos casos, proble-
mas de compatibilidad entre seales. En el siguiente ejemplo se muestra un caso tpi-
co donde se asignan dos seales de dimensiones diferentes e independientes entre s.
LECTURA2: process (Slecci6n~ BaricMuestras," NumIn.ttvePu)

:begin
DatoOut <= (otbers => 'O')
if Seleccion = '1' then .
DatoOut (gBitsMaxNumMuestra - 1 downto O)
<= BancOMuesfras (NurnlntervCPu) ;
end if
LISTADO 6-20. Asignacin de buses con diferentes tamaos. Puede dar lugar a
errores.
Si el tamao de la seal BancoMuestras (que viene determinado por la cons-

tante gAnchOBusDatos), es menor que el tamao de la seal DatoQut (determinado
por la constante gBitsMaxNumMuestras), la asignacin ser correcta. Sin embargo,
si el tamao de BancoMuestras es mayor que el tamao de DatoOut ocurrir un
error al intentar simular o sintetizar el diseo.
En este caso es necesario considerar las distintas posibilidades y generar cdi-
go en consecuencia (o bien limitar los mrgenes de variacin de los parmetros
gBitsMaxNumMuestras y gAnchoBusDatos).
El mtodo ms sencillo para hacer esto es utilizar sentencias tipo genera te. El
siguiente segmento de cdigo muestra el mismo ejemplo corregido para aceptar
diferentes tamaos de las seales.
-- E]_ registro iritemo es iriyor-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)
<= BarlcoMUstras(NumlntervCPj
. (gBitsMaxNumMustras - 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. Utilizacin de sentencias generate para evitar errores de ancho de

bus.
Es necesario hacer notar que una solucin alternativa mediante if condition

then dentro de un proceso no ser vlida. Si lo hicisemos as, el error antes
comentado no quedara solucionado, ya que la valoracin de la condicin ir se
realiza en tiempo de simulacin y, por lo tanto, durante la elaboracin se podra
producir error si la dimensin de BancoMuestras es mayor que la de DatoOut.
6.5.3.5.2. Problemas de definicin de los tipos

Para simplificar la escritura del cdigo se hace interesante, en muchas ocasiones, la
definicin de tipos estructurados (vectores, registros, etc.). Cuando estos tipos
dependen de algn parmetro puede ocurrir que su definicin d lugar a errores. En
el siguiente cdigo se muestra un ejemplo de este tipo.
-- Esta definicin esta en el paquete de tipos bsicos

type tBancoMUestrPrevias la array (O to cMaxInterval - 2)
of tDatoPalabra
,
--------- ....
----- ....
:--::r""~'!"",--~---------~-------- ...-----~,~,::"'-::~.i,rt~-:~-:.---:~.
aigIlal MuestraPrevia: tBaric~estrPrviasi
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 definicin de tipos.
En el Listado 6-22 la definicin del tipo tBancoMuestrPrevias depende de

la constante cMaxInterval que podra valer 1. Si esto ocurriese, la definicin
sera incorrecta, puesto que la direccin de los ndices del vector no es correcta (de
hecho el tipo tBancoMuestrPrevias no debera generarse en dicho caso). Para
solventar este problema debe definirse el tipo dentro de una estructura block. En
el siguiente segmento de cdigo se muestra un ejemplo de cmo 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. Solucin utilizando tipos locales dentro de sentencias block.
6.5.3.5.3. Sntesis y optimizacin

En los diseos genricos existen unidades funcionales o segmentos de cdigo que
deben generar hardware en unos casos y en otros no. Normalmente esto se llevar a
cabo mediante sentencias de tipo if condicin generate o mediante sentencia if
condicin then donde la condicin a evaluar es una constante. El siguiente cdigo
muestra un ejemplo de ambos casos.
GENl : if cImplDetMax generate

MAX_DET : DetectMaxirnos
port map (
Reloj => Reloj; ,;.c
IniciON => lIii.cioij;
...
SelRegsMax => seeccoii,SelRegsMax;
DatoOut => BUSCPU;
end generate;
PPRAL : process (Reloj, IniciON).

begin
if IniciON = '0' then
elsif Eeloj'event and Reloj = '1' then

if cCheqBancoGen then
-- Cdigo generado si cCheqBancoGen '"true
else
-- Cdigo generado en caso contrario
end if;
end if;
end process;
LISTADO 6-24. Generacin condicional de unidades funcionales.
En el primer caso (sentencia genera te) el segmento de cdigo no es sinte-

tizado si la condicin de la sentencia generate no se satisface. Si se utilizan
construcciones del tipo if cond g~nerate, el proceso de sntesis, al resultar los
valores constantes, elimina la lgica que, en un principio, surgira 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 funcin
(que devuelve cierto o falso en funcin de una estructura de entrada donde se defi-
nen las diferentes configuraciones del diseo).
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
- Cdigo generado si c~soGen ~ trye
else
- Cdigo generado en ;ca.Socontrario
end if;
endif;
end process;
LISTADO 6-25. Generacin condicional errnea de unidades funcionales.
Los sintetizadores no consideran normalmente la inicializacin en las variables

y las seales y, por tanto, les asigna inicialmente un valor por defecto. Al sintetizar el
cdigo nunca se generara el cdigo correspondiente a la condicin vCheqBancoGen
= true ya que esta variable toma siempre su valor por defecto (false).
6.5.3.5.4. Funciones de inicializacin

En algunos casos puede ser interesante utilizar funciones para inicializar parmetros
utilizados en el diseo. En el siguiente ejemplo, la funcin cObtenlnicIntervalos() ge-
nera una estructura con valores de inicializacin 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 : tInicntervalos .-
gObtenIni~te+v;~Q'l'ip,p~q),,;
, ,,-,~. , -:-Sl'l':!.PoInic::c PO_Qe jni~alizaci6n
signal BancOIntervIS :" tBartcbDel:ntrvai6lt;

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. Utilizacin de funciones para generacin de constantes.
De esta manera, el cdigo puede resultar ms legible y se tiene ms libertad

a la hora de calcular los valores de inicializacin al no tener que ser la funcin sin-
tetizable. Sin embargo, hay que resaltar que, aunque la funcin 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 sntesis
(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 debern
buscarse otros procedimientos para inicializar los parmetros.
6.5.3.5.5. Nomenclatura
Cuando se realizan diseos genricos, 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 fcil perderse en el significado de cada nombre. Esto se hace
ms importante cuando el equipo de diseo est formado por varios diseadores.
A continuacin se dan algunos ejemplos de este tipo de reglas.
Nombres de genricos: llevarn el prefijo g. Ejemplo: gMaxMemBloques.
Nombres de constantes: llevarn el prefijo c. Ejemplo: cBitsBusCPU.
Ancho de buses: cBitsNombreBus.
Mximo valor de datos: cMaxNombreDato.
Nmero de bits para codificar datos: cBitsMaxNombreDato.
ltimo valor de un dato: cUltimoNombreDato.
Declaracin de tipo: utilizar el prefijo t. Ejemplo: tBusCPU.
En el Listado 6-15 se muestra un paquete de definicin de tipos bsicos y cons-
tantes utilizando estas reglas. Conviene hacer un anlisis 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. DISEOS CONFIGURABLES
Entendemos por diseo configurable aquel que posee ciertos parmetros que, al va-
riarlos, modifican la funcionalidad a nivel RT del componente. En este sentido, el
diseo configurable implica un grado mayor de flexibilidad que el diseo genrico.
Como ejemplo podemos fijarnos en la Tabla 6-7. Esta tabla recoge los parme-
tros de configuracin de un diseo configurable de un transmisor/receptor serie
asncrono. Como puede verse en la tabla, existen una gran variedad de parmetros
que permiten mltiples configuraciones con muy distintas caractersticas. Seleccio-
nando los parmetros adecuados podramos 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 diseador podra estudiar varias alternativas,
analizar su coste y escoger la solucin ms adecuada a su diseo.
Los diseos configurables poseen ventajas parecidas, e incluso mayores, que el
diseo genrico en cuanto a la evaluacin de alternativas, anlisis y organizacin
del diseo, simplificacin del cambio de tecnologa, etc. Pero de igual manera que
comparte las ventajas, tambin comparte con el diseo genrico los mismos proble-
mas, acentuados adems en algunos casos. La complejidad del cdigo es mucho
mayor en los diseos configurables que en los diseos genricos. Asimismo, la difi-
cultad de las pruebas y el tiempo de desarrollo crecen de forma exponencial con la
TABLA 6-7. Parmetros de configuracin de un transmisor/receptor asncrono
Parmetros del TRANSMISORlRECEPTOR

Codificacin de la seal 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
Parmetros del TRANSMISOR
Buffer de transmisin S o no
Tamao FlFO (O-N), N = natural
Modos de interrupcin Ninguno, al escribir, al final, ambos
Parmetros del RECEPTOR
Buffer de recepcin S o no
Tamao FlFO 0-10
Errores detectados Ninguno, sobreescritura, error de formato, error de paridad, todos
Modos de interrupcin .Ninguno, error, dato recibido, ambos
Modo Wake-Up No, s o programable
Direccin 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 diseos configurables pueden ser menores que las que se alcanzan con los dise-
os genricos, ya que deben buscarse ms soluciones de compromiso.
6.6.1. Desarrollo de un componente configurable
Al contrario que los diseos genricos, los diseos configurables no son nunca un
resultado colateral de un proyecto, sino que son el resultado de un proyecto concre-
to de realizacin de un componente de biblioteca.
6.6.1.1. Seleccin de los parmetros de configuracin
Uno de los problemas fundamentales en el desarrollo de un componente configura-

ble es su especificacin. La especificacin de un componente configurable requiere
no slo la especificacin de la funcionalidad (o funcionalidades del componente),
sino tambin de la especificacin de las opciones de configuracin. Es necesario
decidir qu caractersticas del diseo sern configurables y cules no, y para cada
una de esas caractersticas hay que especificar qu posibles valores pueden tomar
los parmetros.
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 funcin de sus parmetros. Como ejemplo podemos fijarnos en los par-
metros del transmisor/receptor serie asncrono 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 prcticamente 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 anlisis detallado de los componentes
existentes en el mercado nos indicar que el nmero de transmisores/receptores con
1,5 bits de parada es relativamente pequeo comparado con los que slo 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 lgica y complejidad respecto al
necesario para implementar slo 1 o 2 bits de parada. Como resultado podramos
concluir que es econmicamente ms viable realizar un componente configurable
que no incluyese la posibilidad de implementar 1,5 bits de parada.
Este tipo de anlisis, que debe ser realizado para todos los parmetros del dise-
o, supone una de las mayores dificultades de los diseos genricos; si el compo-
nente no es 10 suficientemente flexible, puede resultar intil para algunas aplicacio-
nes; si el componente es demasiado configurable, su coste de desarrollo puede
hacerlo prohibitivo. El riesgo principal de esta seleccin es la sobreespecificacin
de los parmetros (seleccionamos ms parmetros de los necesarios). Seleccionados
los parmetros y los posibles valores para cada parmetro, la especificacin debe
incluir la funcionalidad que debe cumplir el componente en cada configuracin.
6.6.1.2. Aspectos a considerar en la generacin 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.
Diseo: como consideracin ms 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-
seo suele ser un diseo menos ptimo (al igual que ocurre con los diseos
asncronos y sncronos).
Pruebas: los diseos configurables son diffciles, de comprobar exhaustiva-

mente mediante simulacin. El nmero de configuraciones posibles suele ser
muy elevado y la verificacin 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 cdigo extra que hay que aadir para permitir las configura-
ciones y el particionado que es necesario realizar para facilitar el diseo con-
figurable dificultan mucho la extraccin de la funcionalidad a partir de la
lectura del cdigo. Una buena documentacin y buenos comentarios en el
cdigo reducen algo este problema.
Mantenimiento: para que la inversin en el desarrollo de la biblioteca no
sea intil, es necesario facilitar la tarea de aadir o quitar funcionalidad al
componente (actualizacin, correccin de errores, etc.). Esto supone tener que
prestar especial atencin a la estructuracin del cdigo.
Tecnologas destino: en general, es necesario desarrollar la biblioteca consi-
derando una determinada tecnologa sobre la que sintetizar. Si las tecnolo-
gas sobre las que se va a sintetizar el componente dependen tambin de
algn parmetro, el problema se complicara an ms.
6.6.1.3. Diseo arquitectural
Con objeto de simplificar el desarrollo de los componentes, especialmente si el n-

mero de parmetros que poseen es elevado, es necesario estudiar a fondo cmo se
va a partir el diseo.
Como norma general, se debe hacer el diseo de los mdulos partindolos en
bloques (ver como ejemplo la Figura 6-13) de manera que cada bloque se vea afecta-
do por un solo parmetro (o dos como mximo). As se simplifica el proceso de veri-
ficacin, ya que no es necesario comprobar todas las configuraciones posibles del
diseo sino las configuraciones posibles de cada bloque (una configuracin es un
implementacin particular donde los parmetros toman unos determinados valores).
Para realizar la particin, es necesario realizar un estudio exhaustivo de las
posibilidades de configuracin. De tal anlisis debe extraerse, por un lado, cmo
afectan los parmetros, identificando aquella funcionalidad comn a todas las
configuraciones y, por otro, aislar las funciones afectadas por cada parmetro.
Adems debe definirse un modo de comunicacin entre procesos, identificando el
mnimo nmero de seales necesarias y definiendo un protocolo para la comuni-
cacin entre bloques. Los bloques deberan resultar lo ms independientes entre s
como sea posible.
Este enfoque simplifica el proceso de verificacin, ya que los bloques funcio-
nan independientemente de la configuracin elegida. Adems, puede simplificar el
diseo, ya que se pueden aislar los problemas (en general slo afectarn a un blo-
que). Por ltimo, este modo de diseo facilita el mantenimiento y la modificacin
del cdigo 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 particin de un diseo configurable.
El inconveniente principal, aparte de que una particin de este tipo no siempre es

posible, es la prdida de prestaciones en el diseo. Para simplificar la comunica-
cin entre bloques es necesario en muchos casos definir un protocolo de comunicacin
tipo handshake, lo que obliga a perder ciclos de reloj. Por otro lado, en algunas oca-
siones conviene repetir parte de la lgica que ya existe en un bloque, en otro bloque
diferente. De esta manera los bloques resultan ms independientes entre s, pero se
puede duplicar la lgica y, por lo tanto, aumentar el rea del componente.
6.6.1.4. Mtodo de generacin
Otro aspecto que debe ser considerado al realizar un componente configurable es el

mtodo de generacin. El componente configurable debe contener una funcionali-
dad diferente segn sean los valores escogidos para sus parmetros.
El mtodo de parametrizacin debe definir dos aspectos. Por un lado, cmo se
le pasarn los valores de los parmetros al diseo; por otro lado, cmo se tratarn
esos valores internamente para generar la funcionalidad adecuada.
Para pasar parmetros al diseo, el VHDL aporta los genricos. Sin embargo,
la utilizacin de genricos no resulta un mtodo adecuado en la mayora de los dise-
os configurables. Hoy por hoy, hay pocas herramientas de sntesis que admitan ge-
nricos, y las que los admiten, slo admiten genricos de tipo entero. Sin embargo,
los parmetros de un diseo 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 parmetro, pero eso dificulta la legibilidad del cdigo.
En cuanto a su utilizacin 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 lgica configurable.
En lneas generales, podemos plantearnos tres mtodos para realizar la parame-

trizacin del componente, lo que da lugar a tres tipos de bibliotecas de componentes
configurables:
Biblioteca cerrada: estaran formadas por un conjunto de componentes ce-

rrados de funcionalidad parecida, pero con ciertas caractersticas de imple-
mentacin que los haran distintos. La generacin de bibliotecas de este tipo
tendra justificacin slo cuando el nmero de posibles configuraciones del
componente es pequeo, es decir, depende de pocos parmetros. Esta forma
de generar bibliotecas de componentes es caracterstica de situaciones en las
que no se ha previsto ningn tipo de planificacin. La Figura 6-14 presenta
un esquema de este procedimiento de generacin.
En este caso, el componente no es realmente configurable, sino que se
dispone de un procedimiento cmodo de seleccin para escoger entre una
serie de componentes cerrados.
Biblioteca generada por programa: en este caso, el cdigo VHDL asocia-

do al componente sera generado por un programa realizado en un determi-
nado lenguaje de programacin (C o Pascal, por ejemplo). En funcin de los
parmetros introducidos por el usuario de la biblioteca se generara un mode-
lo VHDL u otro (ver Figura 6-15). El modo de seleccin de los parmetros
podra realizarse a travs de un entorno grfico, o de forma textual a travs
de cadenas de caracteres (mnemnicos).
Este mtodo presenta la ventaja de su facilidad de programacin y la
flexibilidad en cuanto a la seleccin de parmetros. Por otro lado, al poder
realizar entornos grficos para la configuracin del componente resulta ms
cmodo para el usuario. El inconveniente fundamental es la necesidad, por
parte del siseador de la biblioteca, de manejar dos entornos de trabajo: el
del VHDL y el del lenguaje de programacin 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 generacin de la biblioteca se realizara

ntegramente en VHDL. La parametrizacin del sistema se llevara a cabo
mediante unas funciones especiales (funciones de extraccin de parmetros),
desarrolladas ntegramente en VHDL. Estas funciones estaran encargadas de
traducir las cadenas de parmetros introducidas por el usuario a un conjunto
de constantes VHDL, que son las que posteriormente se utilizaran en las
descripciones del componente (ver Figura 6-16).
La ventaja de este procedimiento es que se trabaja slo dentro de un en-
torno; el diseador slo necesita conocer VHDL, y slo depura y elabora un
cdigo fuente. Sin embargo, puesto que la mayora de las herramientas de
sntesis no soportan genricos, es un mtodo aplicable en pocos casos.
6.6.1.5. Bancos de prueba
Uno de los aspectos que ms tiempo consume en el desarrollo de las bibliotecas

(como en el de cualquier diseo) es la elaboracin 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 seal 1(st)
...
SetPattern(seal ...
SetPattern(seal wait unlil slrobe = '1 ';
CheckPattern( ...)
vectores
...
SetPattern(seal 1) Verificador de seal 2(s2)
SetPattern(seal 2)
wail unlil strobe = '1 ';
vectores CheckPattern( ...) Seal de control (c2)
...
wait unlil slrobe ='1 ';
CheckPattern( ...}
FIGURA 6-17. Comprobacin automtica de resultados en los bancos de prueba.
tivo. Si el componente se ha partido en bloques adecuadamente, los bancos de prue-

ba slo deben probar cada una de las configuraciones de cada bloque por separado.
En cualquier caso, el nmero de yerificaciones que hay que realizar es elevado
y la comprobacin resulta tediosa (lo que induce ms posibilidades de saltarse un
error). Para reducir este problema pueden elaborarse bancos de prueba que verifi-
quen automticamente si el resultado de las seales tras la simulacin es correcto.
Esto implica que los bancos de pruebas tambin deben hacerse configurables,
aplicndose diferentes vectores funcionales segn la configuracin. Asimismo, las
salidas esperadas deben estar parametrizadas (en funcin de un parmetro se esco-
gen unas u otras salidas). En la Figura 6-17 se muestra un mtodo que puede seguir-
se en este caso (UUT es el circuito bajo prueba). El procedimiento SetPattern() se
encargara de poner los valores esperados mediante una cadena de caracteres. Dicha
cadena se puede obtener a travs de una funcin que depende de los parmetros de
la configuracin. El procedimiento CheckPattern() se encargara de verificar los re-
sultados en base a un funcionamiento sncrono 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 especificacin del bloque ProgPrecio de la mqui-

na expendedora de refrescos del Apndice 1 (se recomienda leer los documentos
de requisitos, especificaciones y diseo arquitectural incluidos en el apndice).
3. El siguiente cdigo VHDL corresponde a las especificaciones de un mdulo de

un determinado diseo. Cul es la funcionalidad del bloque? Cul es el mto-
do de operacin?
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 diseo arquitectural del circuito especificado en el problema 3. Supo-

ner que el sintetizador ser capaz de sintetizar mdulos divisores y multiplicado-
res. Para el diseo se recomienda realizar la operacin 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 diseo
lgico del circuito del problema 4.
6. Al final del Apndice 11(apartado 11.6) se encuentra la descripcin en VHDL de

un transmisor serie sncrono. Disear un banco de pruebas que verifique el com-
ponente teniendo en cuenta las inicializaciones, terminaciones, funcionamientos
y valores no considerados. Disear el banco de pruebas tanto mediante un pro-
cedimiento orientado a la seal como mediante un procedimiento orientado al
modo de funcionamiento.
440 VHDL. Lenguaje estndar de Dseo Electrnco
7. Realizar un diseo genrico de un contador BCD cuyo nmero de dgitos sea pa-
rametrizable entre 1 y 4.
8. El siguiente cdigo VHDL se corresponde con un banco de registros de un siste-

ma de bsqueda indexada de informacin (parte de la palabra buscada es el ndi-
ce, mientras que el resto es la informacin buscada). Modificar el diseo de for-
ma que sea parametrizable el nmero de bits de cada palabra, el tamao del ban-
co de registros y el nmero 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 diseo configurable de un contador BCD de l, 2 o 3 dgitos, que ad-

mita cuenta ascendente, descendente o ascendente/descendente, con o sin carga
paralela y con seal de borrado sncrono activa por nivel bajo o alto. Los par-
metros del diseo sern pasados mediante genricos de tipo entero.
6.8. BIBLIOGRAFA
[BLUM92] M. BLML,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: Metodologa de diseo 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 va 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: Mtodos de especificacin y control. v3.1, julio 1994.
[PREN94c] PRENDA: Mtodos de diseo y alternativas tecnolgicas. 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.
Apndice I
SISTEMA
COLAMATIC
DOCUMENTO DE REOUISITOS
Presentacin del cliente
El sistema Colamatic se va a desarrollar por peticin de la empresa XXX al Centro

de diseo de YYY. La empresa XXX tiene una larga tradicin en el desarrollo y la
explotacin de mquinas expendedoras de distintos tipos. Con este proyecto se pre-
tende dar un gran salto a las nuevas tecnologas microelectrnicas que permitir una
mejora de las prestaciones de las mquinas y una importante reduccin de su coste.
Descripcin de la aplicacin
El primer demostrador se va a realizar para uno de los productos de ms difusin en

el mercado de la empresa XXX, que son las mquinas 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 produccin anual prevista inicialmente y tan slo para
consumo interno es de 10.000 unidades/ao.
El diseo deber ser realizado de forma que pueda ser adaptado a nuevas apli-
caciones: dentro de la lnea productiva de XXX: otros tipos de mquinas, mayor
cantidad de productos, etc.
443
En particular, y para esta aplicacin concreta, se pretende desarrollar un circui-

to integrado que sustituya la mayor parte de la lgica de control de una mquina
expendedora de bebidas fras, que disponga de la posibilidad de vender hasta cuatro
productos diferentes, cuyos precios puedan ser programados para cada producto
individualmente. El diseo deber contar con la posibilidad de ser adaptado fcil-
mente a un mayor nmero de productos. Los requisitos precisos de la aplicacin se
detallan en un apartado posterior de este documento.
Descripcin del entorno del ASIC
El ASIC Colamatic estar encargado del control de la mquina expendedora. Su en-

torno estar compuesto por elementos sensores, botones e interruptores, que estarn
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 servirn para seleccionar el producto que se
quiere comprar y tambin para seleccionar el producto cuyo precio se quiere
programar. En principio est previsto un nmero de cuatro productos.
Botn de devolucin de monedas, que servir para que el usuario pueda
recuperar su dinero. Tambin se podr utilizar este botn para indicar el fin de
la programacin del precio de un producto determinado.
Botones de programacin de precio, sern dos botenes para programar el
precio deseado para cada producto. Un botn incrementar y otro decrementar
el precio por cada pulsacin. El intervalo de incremento se dejar abierto en
esta etapa del diseo, definindose ms 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 programacin 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 devolucin del cambio.
Apndice l. Sistema Colamatic 445
Apertura de la trampilla a la caja de recaudacin, esta trampilla se abrir

cuando se detecte que los carriles internos de las monedas se han llenado.
Visualizadores: Display externo (3 dgitos), sern tres visualizadores de 7 segmen-

tos, que indicarn al usuario el precio del producto seleccionado, el dinero que
lleva echado, el cambio que se le va a devolver, segn el estado del sistema.
Cuando se estn 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 mquina.
Indicadores de falta de producto, que sern tantos LEOs como tipos de pro-
ductos haya, que indicarn al exterior que el producto en cuestin se ha termi-
nado.
Descripcin de la funcionalidad del ASle
El ASIC Colamatic, como se ha explicado anteriormente, deber realizar todas las

funciones de control de la mquina 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 mquina y el producto que se quiere adquirir. Una
vez que el usuario ha introducido el dinero suficiente, deber apretar el botn
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 devolucin del cambio: deber calcular el cambio que hay que
devolver al usuario, teniendo como criterio principal el devolver el mnimo
nmero de monedas posible (monedas de mximo valor) siempre que estn
disponibles. Adems, deber conocer el nmero de monedas de cada tipo dis-
ponibles en el interior de la mquina y actualizarlos a medida que se vaya
introduciendo dinero. Se supondr que cada vez que se abre la mquina se
rellenan los cajetines de las monedas con un nmero de monedas que se
determinar ms adelante. Cada uno de los carriles de monedas tendr una
trampilla independiente.
Devolucin de las monedas: el dinero que ha echado un usuario se devolver nte-

gro si se pulsa el botn de devolucin de monedas o no hay cambio y no se ha
introducido el importe exacto. Las monedas devueltas debern 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 recaudacin.
Control de la presencia de productos: el sistema deber saber cuntos 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 mquina se rellenan los
carriles de todos los productos hasta el mximo (30).
Programacin de los precios: deber controlar la programacin de los precios cuan-

do el interruptor de modo est en la posicin adecuada. Para programar los pre-
cios se irn pulsando los botones de incremento o decremento de precio hasta
alcanzar el importe deseado y despus se seleccionar el producto cuyo precio
se quiere programar. Para almacenar el nuevo precio en el sistema se deber
pulsar el botn de devolucin, que en este modo de funcionamiento servir
para almacenar el nuevo precio. Tambin se puede programar el precio se-
leccionando primero el producto y despus 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-

rn diferente informacin, dependiendo del estado del sistema: si se oprime el
botn 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 botn de algn 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 iluminarn cuando se detecte que falta algn
producto, en modo de funcionamiento normal, y cuando se selecciona un producto
para programar su precio, en modo de programacin de precios.
Restricciones del ASIC
El ASIC deber funcionar en las condiciones anteriormente descritas y sus restric-

ciones funcionales se irn definiendo a medida que se avance en la especificacin
final y en el diseo del mismo. Estas restricciones no podrn afectar en ningn caso
al funcionamiento anteriormente descrito y debern ser aprobadas por el grupo de
diseo y el cliente.
DOC-l PRENDA: Metodologa para el diseo de ASICs UPM-DIE, 1996.

DOCUMENTO DE ESPECIFICACIONES
Introduccin
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 diseo del ASIC.
Para formalizar la especificacin del sistema se ha realizado una descripcin
del mismo en VHDL. Esta descripcin se ha realizado en un estilo puramente fun-
cional para definir claramente el comportamiento del sistema.
DOC-l PRENDA: Metodologa para el diseo de ASICs. UPM-DIE, 1996.

DOC-2 Sistema Colamatic. Documentos de requisitos. XXX-YYY, 1997.
Discrepancias con el documento de requisitos
Ninguna conocida.
Terminologa usada
Los nombres de las seales de entrada y salida, as como los nombres de los
bloques funcionales, intentan facilitar la comprensin de su funcionalidad al m-
ximo.
Especificacin funcional del ASIC
Especificaciones globales
Se pretende desarrollar un circuito integrado que sustituya la mayor parte de la lgi-

ca de control de una mquina expendedora de bebidas fras, que disponga de la
posibilidad de vender hasta cuatro productos diferentes, cuyos precios puedan ser
programados para cada producto individualmente. El diseo deber contar con la
posibilidad de ser adaptado fcilmente a un mayor nmero de productos.
En la siguiente tabla se muestran las entradas y salidas del sistema Colamatic y
una breve descripcin de su funcionalidad:
Nombre Descripcin
ENTRADAS
Clk Reloj principal del sistema (frecuencia por determinar)
ResN Seal de inicializacin global del sistema (activa por nivel bajo)
BotProdl Botn de seleccin del producto 1
BotProd2 Botn de seleccin del producto 2
BotDevuelve Botn de devolucin del importe introducido
BotPVP/ncre Botn para incrementar el precio en modo de programacin
BotPVPDecre Botn para decrementar el precio en modo de programacin
/nteModo Interruptor de modo (= 'O' en modo normal; = '1' en modo de

programacin de precios)
Moneda/nt Monedas introducidas desde el exterior. Se codificarn en tres bits
SALIDAS
TrampProd Seales que controlan la apertura de las trampillas de los productos
NoHayPl Seal que controla el LED correspondiente al producto 1
NoHayP2 Seal que controla el LED correspondiente al producto 2
NoHayCambio Seal que controla el LED que indica que no hay cambio
MoneUeno Seal que controla la apertura de la trampilla a la caja de recaudacin
MonedaOut Seales que controlan la apertura de las trampillas de la devolucin
DispUnidad Seales para controlar el visualizador de 7 segmentos (unidades)
DispDecena Seales para controlar el visualizador de 7 segmentos (decenas)
DispCentena Seales para controlar el visualizador de 7 segmentos (centenas)
En la tabla siguiente se muestra la particin 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 almacenarn 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 Vaca Dinero/nt

Especificaciones de los bloques funcionales
Bloque A1Exterior. Este bloque se encargar de generar las seales para la visua-
lizacin externa a travs de los visualizadores de 7 segmentos y de los LEDs.
En modo de funcionamiento normal (InteModo = 'O'), se iluminarn los LEDs
correspondientes a aquellas lneas de producto que estn vacas. El visualizador
mostrar diferentes valores, dependiendo de las acciones del usuario:
Mientras va echando dinero en la mquina el display mostrar la cantidad de

dinero echada.
Si se pulsa algn botn de seleccin de producto sin haber echado dinero su-
ficiente para dicho producto, el display mostrar el dinero que falta para la
adquisicin de dicho producto.
Si se echa ms dinero del necesario y se debe devolver cambio, el display
mostrar el cambio que queda por devolver.
En modo de funcionamiento de programacin (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 mquina. Se rea-

lizarn las siguientes funciones:
Clculo del dinero.

Clculo del cambio y control de los monederos internos de la mquina. El
cambio se devolver utilizando las monedas de ms 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 ms de 50 mone-
das) el dinero echado pasar a la caja de recaudacin.
Devolucin de las monedas echadas al pulsar el botn BotDevuelve. Se de-
volvern 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 programacin de

los precios. Para programar un precio, el interruptor InteModo deber estar a 'O'. El
usuario seleccionar un producto y despus 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 parmetro
podra 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 pulsacin del botn BotDevuelve.
Este bloque generar las seales de entrada a los registros de los precios (blo-
que RegPrecio). Generar unas seales que actuarn como habilitacin 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 almacenarn los precios programados para

cada uno de los productos. Como salida tendr unas seales que indicarn 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 seales que
indiquen que no hay producto.
Especificaciones operacionales.
Formato y rango de los datos
A continuacin se describen cada una de las seales del sistema Colamatic,

especificando sus rangos, su origen y destino, atendiendo a los bloques funcionales
anteriormente descritos:
_\Nombre Origen Destino Codificacin
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 Progrecio 1 bit
InteModo Exterior AIExterior; Monedero; ProgPrecio 1 bit
Monedalnt Exterior Monedero 3 bits

Nombre Origen Destino Codificacin

':":;,.' : :-",'
TrampProd Monedero Exterior; SirveCla 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 tecnolgicas globales
Parmetros elctricos
Tensin de alimentacin = 5 V 0,5 V.
Consumo esttico y dinmico: el consumo no ser un parmetro crtico en este
diseo (TBD).
Caractersticas de las E/S

Tensiones mxima y mnima: las entradas y salidas del circuito sern compatibles
CMOS en sus niveles de tensin.
Corrientes: la corriente en las salidas del sistema deber ser de 2 mA. Se defi-
nir de manera ms precisa en las fases posteriores del diseo.
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 parmetros crticos en cuanto a la frecuencia de funciona-

miento. La frecuencia mnima a la que debe funcionar el circuito es de 1 MHz.
Encapsulado
El circuito tiene un total de 47 seales de entrada y salida. A esto hay que aadir las
necesarias para alimentacin y masa y la posibilidad de tener que aadir alguna
seal externa adicional para test. Esto se definir en las etapas posteriores del diseo.
El encapsulado final del circuito no est definido, aunque se prev necesario un
PLCC de 68 pines.
DOCUMENTO DE DISEO ARQUITECTURAL
Introduccin
Este documento contiene la informacin de diseo generada durante el diseo 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 descripcin 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 particin en bloques fun-
cionales definida en el documento de especificaciones y la funcionalidad de las
seales de interconexin entre los mismos.
Documentos aplicables
DOC-l PRENDA: Metodologa para el diseo 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.
Descripcin arquitectural
Particin del diseo
La particin del diseo se ha tomado del documento de especificaciones (DOC-2),

ya que sta se realiz basndose en la funcionalidad que debe cubrir el sistema y
se ha preferido mantenerla. El diagrama de bloques del sistema con las seales de
entrada y salida de cada bloque se encuentra en la figura siguiente. En DOC-3
encontrar ms detalles sobre la funcionalidad de cada una de estas seales y blo-
ques.
PrecioProd PrecioProd ~
ProgPrecio
SelRegPVP SelRegPVP ~ PrecosV
AIExteror
SirveCola
Monedero
PreciosV-'-- --l
Descripcin detallada de los bloques funcionales
Bloque AIExterior
Este bloque se encargar de generar las seales para la visualizacin externa a

travs de los visualizadores de 7 elementos y de los LEDs. En modo de funciona-
miento normal (InteModo == 'O'), se iluminarn los LEDs correspondientes a aque-
llas lneas de producto que estn vacas. El visualizador mostrar diferentes valores,
dependiendo de las acciones del usuario, datos que sern enviados por el bloque
Monedero a travs de la seal Dinerolnt.
En modo de funcionamiento de programacin (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 mostrarn en el visualizador y
por otra se generan las seales de los LEDs.
Las entradas PrecioProd y Dinero/nt se codificarn como enteros variando entre
Oy 995 y las dems seales del bloque sern de tipo std_logic y std_logic_vector. La
eleccin de los tipos enteros para las seales PrecioProd y Dinerolnt facilita el tra-
tamiento de dichos datos.
Bloque ProgPrecio
Este bloque es el encargado de realizar la programacin de los precios. Para progra-

mar un precio, el interruptor /nteModo deber estar a 'O'. El usuario seleccionar un
producto y despus 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-
sacin del botn BotDevuelve.
Este bloque generar las seales de entrada a los registros de los precios (blo-
que RegPrecio). Generar unas seales que actuarn como habilitacin 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).
PrecoProd
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 informacin sobre el pro-
ducto que se ha seleccionado al comienzo de la operacin. 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 botn BotPVPlncre 40 veces el valor del precio vuelve a cero.

Igual con el botn BotPVPDecre.
Se generan correctamente las seales SelRegPVP al pulsar el botn Botl)e-

vuelve. Estas seales tendrn una duraccin de un ciclo de reloj, en el que el
valor a cargar en el registro est en PrecioProd.
La seleccin del producto cuyo precio se quiere programar se puede hacer

al comenzar la operacin, durante la misma o al final, justo antes de pulsar
BotDevuelve.
Bloque RegPrecio
En este bloque se almacenarn los precios programados para cada uno de los pro-
ductos. Como salda tendr unas seales (Precios V) que indicarn los precios de
cada uno de dichos productos.
Este bloque contiene cuatro registros en los que se almacenarn los precios
programados para cada producto, con las seales generadas por el bloque anterior-
mente descrito. Los precios se codifican con valores enteros que Valan entre O
y 975.
Apndice l. Sistema Co/amatc 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 seales que indican que no hay pro-
ducto (LineaVacia).
SirveGola Linea Vaca
Este bloque es muy sencillo, ya que simplemente lleva la cuenta de los produc-
tos que quedan en cada lnea, Inicialmente se considera que la lnea 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 mquina. Las funciones prin-
cipales que se realizan en l son:
Clculo del dinero que se ha echado.

Clculo del cambio y control de los monederos internos de la mquina. El

cambio se devolver utilizando las monedas de ms 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 ms de 50 mone-
das) el dinero echado pasar a la caja de recaudacin.
Devolucin de las monedas echadas al pulsar el botn BotDevuelve. Se de-
volvern 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 mquina de estados, cuyo diagrama

se muestra a continuacin.
HayCa
Los estados anteriormente mostrados tienen asociados un conjunto de funcio-

nes, que son:
Estado inicial: en este estado la mquina se encuentra en reposo, ya que no

se ha comenzado ninguna operacin por parte del usuario.
Estado ms-mon: en este estado se incrementa el nmero 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 recaudacin (MoneLleno(i) = '1 ').
Estado reposo: este estado es similar al inicial, aunque la mquina 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 ms, 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 clculo del cambio que hay que
devolver, comprobndose si hay cambio suficiente en los monederos.
Estado devuelve: se entra en este estado cada vez que se pulsa el botn de
devolucin 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 comprobacin de este bloque se probarn diversas posibilidades de in-

troduccin de monedas, seleccin de cada uno de los productos, comprobacin del
clculo del cambio y de la devolucin de las monedas.
Descripcin del test funcional
Para la realizacin del test funcional del sistema se realizarn un conjunto de simu-
laciones de los bloques por separado y una simulacin general de todo el sistema.
La estrategia que se seguir ser comprobar de forma exhaustiva cada uno de los
requisitos del sistema, ponindolo en situacin lmite en algunos casos. Asimismo, se
comprobarn los cambios de modo del sistema (inicializacin ~ ... modo de pro-
gramacin de precios ~ ... modo de funcionamiento normal).
Requisitos Qu se debe comprobar?
Inicializacin Comprobacin del estado de los registros internos. (Mone-

deros y filas de productos llenos; resto de los registros a '0').
Programacin de precios Comprobacin de que se programan correctamente los pre-

cios de todos los productos. Comprobacin de que el precio
mximo es de 975 pesetas. Comprobacin de las salidas por
visualizador.
Requisitos Qu se ha comprobado?
Insercin de monedas Comprobacin del control de los monederos. Comprobacin

del llenado de los monederos. Comprobacin de la mxima
cantidad de dinero que se puede echar l. Comprobacin de la
salida por display.
Clculo del cambio Comprobacin del clculo del cambio para distintas circuns-
tancias (cuando hay todo tipo de monedas, cuando slo que-
dan monedas pequeas, etc.). Comprobacin del caso en el
que no hay cambio. Comprobacin de la salida por los vi-
sualizadores.
Devolucin de monedas Comprobacin de la devolucin del cambio. Comprobacin

de la devolucin de monedas al pulsar BotDevuelve. Com-
probacin de la devolucin de monedas al superar el mxi-
mo admitido l.
Compra de producto Comprobacin de la apertura de las trampillas de producto.

Comprobacin de la "no apertura" cuando no se ha echado
dinero suficiente. Comprobacin de la ausencia de productos
en alguna lnea vaca.
I Este requisito no se encontraba explcito en las especificaciones. Si se echa ms dinero del mxi-
mo permitido (> 1.000 pesetas), las monedas introducidas en la mquina se devolvern.
En la tabla anterior se muestran los principales parmetros que se deben com-

probar en las simulaciones funcionales del sistema. La comprobacin funcional del
sistema se realizar por inspeccin visual de los resultados de las simulaciones
tanto en las salidas del circuito como en algunas seales internas del mismo (estado
de los monederos, de las lneas de productos, de los precios programados, etc.).
CONCLUSIN
En este documento se han expuesto las principales caractersticas de la arquitectura

del sistema Colamatic. El cdigo VHDL resultante de esta etapa del diseo servir
de entrada a la siguiente fase del diseo, en la cual se llegar a descripcin sinteti-
zable del mismo y se optimizar para su posterior sntesis. Las simulaciones funcio-
nales del sistema podrn ser utilizadas asimismo para la simulacin del sistema a
nivel lgico.
Apndice 11
NORMAS
DE CODIFICACION
y MODELADO EN VHDL
En el presente apndice se muestran una serie de reglas de codificacin y modela-

do. Este tipo de reglas deberan ser implantadas en todos los equipos de diseo que
pretendan realizar diseos industrialmente. Las reglas mostradas son desde ideas
muy sencillas (uso ordenado de maysculas y minsculas, espaciado en las distintas
secciones del texto, etc.) hasta aspectos ms relacionados con la naturaleza del
VHDL (uso de unas sentencias en lugar de otras, organizacin de los ficheros, etc.).
Estas reglas nunca se deben considerar como una imposicin, sino simplemen-
te como una serie de ideas que puedan ayudar a tomar determinadas decisiones a la
hora de organizar un equipo de diseo.
Corno el VHDL es un lenguaje formal (como el C o el Pascal), muchas de las
reglas, en cuanto a estilo se refiere, estn inspiradas en las que usan los programado-
res. Asimismo, al ser el VHDL un lenguaje que es usado para la simulacin de hard-
ware o incluso para la sntesis del mismo, estas reglas se vern afectadas por ello.
11.1. ADVERTENCIA
Las reglas que aparecen en el texto no son ms que recomendaciones (su utilizacin
est pensada para una herramienta comercial especfica y pueden no ser aplicables
para otras). En ningn momento han de convertirse en una obligacin si el uso de
las mismas va en detrimento de la productividad. El director del equipo de diseo
461
tiene la responsabilidad de valorar las recomendaciones presentadas y elegir las

ms convenientes para su equipo de diseo.
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 debera publicar sus propias reglas de modelado VHDL que todos deberan
conocer y utilizar. En el caso en el que las descripciones VHDL fuesen ledas por
personas ajenas al centro de diseo, se deberan acompaar por las reglas de mode-
lado que se han seguido para realizar esas descripciones.
Las recomendaciones se dividen en cuatro partes:
l. Definicin del formato del fichero VHDL.
2. Convenios sobre utilizacin de bibliotecas.
3. Nombre y ubicacin de ficheros.
4. Modelos para sntesis.
Al final del apndice se muestra un ejemplo correspondiente a un transmisorl
receptor serie sncrono sintetizable por una herramienta comercial.
11.2. DEFINICiN 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 cdigo debe usar de un modo coherente las maysculas y minsculas, es decir,
las palabras reservadas del VHDL debern estar todas en maysculas o en minscu-
las. Se recomienda que los identificadores (nombres de variables, de seales, proce-
dimientos, etc.) utilicen maysculas y minsculas.
Usar solamente 80 caracteres por lnea, y solamente una instruccin por lnea.
No usar tabuladores. En su lugar usar dos espacios en cada nivel de indentacin.
Agrupar las instrucciones si realizan una funcin comn. Estos grupos debern
separarse convenientemente (con una lnea en blanco o con guiones).
Alinear los comentarios, identificadores, etc., verticalmente para favorecer la
lectura del cdigo.
11.2.2. Identificadores
Para facilitar la lectura de las descripciones, es muy til usar maysculas y mins-
culas en los nombres de cualquier objeto del VHDL. Por ejemplo, en lugar de escri-
bir una funcin con el nombre detectordeflancopositivo, es mejor escribir el nombre
como DetectorDeFlancoPositivo. Esto es preferible a usar el carcter '_', que esta-
ra reservado para otros cometidos.
Apndice 11.Normas de codificacin y modelado en VHDL 463
Usar una longitud mxima de los identificadores de 25 caracteres.

Si una seal 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, seales y funciones que determine el tipo de dato que representan. Existe
una serie de prefijos de uso comn, 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 ms usuales son
los siguientes:
i:integer.
s:std_logic.
b:bit.
l:boo1ean.
u:std_u10gic.
t:Declaracin de tipos.
e:Declaracin de constantes ..
Si va acompaado con una 'v' ('sv', 'xv', ... ) indica que se trata de un vector.
Si va acompaado con una 'e' ('se', 'xve', ... ) indica que se trata de una constante.
De esta manera la funcin DevuelveUnEntero quedara iDevuelveUnEntero,
resultando explcito el tipo.
11.2.3. Comentarios
El objetivo de los comentarios es facilitar que el cdigo pueda ser entendido por
otra persona distinta a la que 10 ha escrito.
Los comentarios deberan estar en un nico idioma (ingls si va a ser ledo por
personas de distintas nacionalidades).
Su contenido debe ser 10 ms descriptivo posible y no una mera repeticin o
traduccin del cdigo VHDL, al que complementa.
Deben situarse prximos a las partes del cdigo que describen; no es aceptable
una cabecera que explique todo el cdigo que aparezca a continuacin.
Los comentarios debern alinearse y estar justificados para facilitar su lectura.
Cada fichero debera incluir una cabecera que contenga, como mnimo, la
siguiente informacin:
Nombre de las unidades en el fichero.

Nombre del fichero.
Descripcin del hardware modelado (si procede).
Limitaciones del modelo, errores conocidos y cualesquiera restricciones im-
puestas.
Lista de dependencias (si procede).
Autor(es), incluida direccin 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 declaracin de un subprograma, proceso, bloque, etc., debera estar pre-

cedido por una descripcin de su funcin, as como las limitaciones y restricciones
impuestas. En los subprogramas es conveniente comentar adems los parmetros y
resultados.
En la declaracin de puertos y genricos es til incluir comentarios describien-
do cada seal y parmetro. 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 ms
significativo, independientemente del orden de los bits. Por ejemplo, en VectorDe-
Bits(O to 15), el bit O es el bit ms 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 tpico 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 cdigo de manera que se pueda modificar el tipo de
una seal o variable sin modificar el resultado de las simulaciones. Esto implica:
Evitar el depender de la inicializacin por defecto de las variables o seales a

no ser que una poltica de reset asegure que el modelo es explcitamente ini-
cializado.
Evitar depender del nmero de valores de un tipo determinado.
Evitar depender del orden en el que se han declarado los valores del tipo.
11.2.5. Seales y puertos

Siempre que sea posible se usar el mismo nombre para una seal a lo largo de la
jerarqua del diseo. En el caso en el que no se pueda usar exactamente el mismo
nombre se usar un nombre derivado del primero.
La ordenacin de los ndices debera ser la misma a lo largo de la jerarqua, sea
sta ascendente (usando to) o descendente (usando downto). Se recomienda usar la
misma poltica de indexado en todo el modelo (todos los ndices ascendentes o des-
cendentes). En el caso en el que se produzca una inversin en los ndices, se deber
advertir claramente.
No es recomendable utilizar el modo buffer en la entidad de ms alto nivel del
diseo.
La declaracin de entradas/salidas debera realizarse en un orden lgico:
Se recomienda poner primero las entradas, luego las seales bidireccionales
y por ltimo las salidas.
Alternativamente se pueden agrupar atendiendo a su funcin.
Apndice 11. Normas de codificacin y modelado en VHDL 465
Opcin 1: Entradas/salidas Opcin 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 seales estarn comentadas, una a una, como se ha dicho
anteriormente.
En las referencias a los componentes no se usar la asignacin por posicin, a
no ser que los nombres de las seales sean 10 suficientemente representativos (mis-
mo nombre o derivado). Lo mismo se aplicar a los parmetros genricos. 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)
-- (activoun 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 contarn con una etiqueta descriptiva. Lo mismo se aplica a
cualquier sentencia concurrente siempre que esto mejore la legibilidad. De este
modo es ms fcil 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 (tpico en procesos sintetizables)
debern 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 seales que
estn en la parte izquierda de una asignacin, as como las que vayan a ser usadas
en construcciones condicionales (if, case, etc.). Esto es especialmente importante en
aquellas descripciones orientadas a la sntesis. 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 seales no incluidas

como parmetros en la llamada a la misma.
La entidad de ms 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.
Sntesis.
La arquitectura Funcional sera cualquiera que no est pensada para su sntesis

posterior. La arquitectura Sntesis sera cualquiera pensada para sntesis (bien sea
descripcin RTL, estructural o algortmica). Si hay varias arquitecturas, se puede
incluir un nmero 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 diseo que el propio modelo.
No se debe usar un nmero exagerado de packages a no ser que claramente
mejore la legibilidad.
No se debern usar package s vacos o casi vacos. Se recomienda colocar el
cdigo VHDL de la misma funcionalidad en packages distintos (parmetros 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 descripcin.
Las declaraciones en el package body aparecern en el mismo orden que en la
declaracin del package.
La declaracin del package contendr una documentacin completa sobre los
tipos declarados, constantes, subprogramas, etc.
11.3. CREACiN y UTILIZACiN DE BIBLIOTECAS VHDL
Para evitar problemas de incompatibilidades entre los modelos descritos en VHDL,

hay una serie de recomendaciones en cuanto al uso y generacin de bibliotecas. Es-
tas recomendaciones se dividen en dos partes. En primer lugar, hay unos consejos
para la correcta utilizacin 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 utilizacin de esta recomendacin no dificulta en absoluto
la generacin de cdigo y simplificar enormemente el mantenimiento de bibliote-
cas, especialmente en diseos grandes.
11.3.1. Utilizacin de tipos, componentes y funciones

Usar solamente tipos bsicos y la lgica MVL9 (IEEE 1164), que est definida en
el paquete std_logic_1l64.
Hacer que los componentes bsicos lleven una referencia a la biblioteca a la
que se refieren. No es necesario que los componentes especficos de una aplicacin
lleven dicha referencia.
Dentro de las arquitecturas se recomienda trabajar con tipos 'O1', 'XOl' Y

'XOIZ'. Esto acelera la simulacin y facilita la especificacin. De todas maneras,
los interfaces entre distintos bloques o componentes deberan usar siempre MVL9.
Limitar siempre el rango de las variables enteras (si ste se conoce). Esto es
especialmente necesario si la descripcin est pensada para sntesis.
11.4. NOMBRE y UBICACIN DE ARCHIVOS
Se recomienda que en cada fichero que corresponda a un diseo se incluya:

Entidad.
Arquitectura (1 arquitectura por fichero en el caso de sntesis).
Configuracin.
Cada fichero ser nombrado de acuerdo con la unidad de diseo que contiene,
es decir:
Entidad, Arquitectura & Configuracin: nombreEntidad. vhd
Entidad, Arquitectura & Configuracin: nombreEntidad-nombreArq. vhd
Package & Package Body: nombrePackage-pack.vhd
Los archivos se encontrarn en un solo subdirectorio, sin jerarqua explcita. Se
recomienda, sin embargo, documentar convenientemente la jerarqua en un fichero
de texto.
11.5. MODELOS PARA SNTESIS
Las siguientes recomendaciones han sido generadas para la elaboracin de modelos

VHDL orientados a la sntesis. Estas recomendaciones tienen validez para una
determinada herramienta de sntesis y pueden no ser vlidas para las herramientas
de las que disponga el lector. En cualquier caso, en cualquier equipo de diseo es
til disponer de este tipo de recomendaciones.
11.5.1. Recomendaciones generales

La manera de realizar las descripciones en VHDL orientadas a sntesis determinan
en gran medida la calidad del diseo sintetizado. Es por eso que hay que tener en
cuenta una serie de reglas fruto de la experiencia que evitan, no que el diseo no
sea adecuado funcionalmente, sino que el hardware generado no sea todo 10 ptimo
que sera deseable.
11.5.2. Variables y seales

Usar seales siempre que vayan a tener visibilidad fuera del proceso en el
que su valor sea modificado.
Apndice 11.Normas de codificacin y modelado en VHOL 469
-- Proceso que representa un contador con la. seal 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 seal 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 seales.
-- Las siguientes inicializaciones son vlidas para SIMULACIN, NO para

-- sntesis.
------------------_ .... _---_ ..._-------------------------..... ......... ---~.-.~- ..
"'~.'...~....~..... -
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 inicializacin de variables y/o seales en la declaracin de

las mismas: en sntesis son ignoradas.
Las seales o variables cuyos valores sean asignados en bloques combinacio-
nales (bien procesos, bien asignaciones concurrentes), tomarn un valor siempre
que las seales de las que dependan lo tengan. Las seales y/o variables que proce-
dan de bloques secuenciales debern contar con una inicializacin, bien secuencial,
bien combinacional.
-- Inicializaciones para sntesis
-- Asignacin concurrentes la seal 'sl' ~t:!;;:

int.c:ializada
-- correctamente si las seales 'el', 'e2', 'e3' estn
-- inicializadas:
sl <= '1' when el = '1' and e2 = 'O' else

'O' when e3 = '1' and e2 = '1' else
'Z' ;
-- Procesos: la seal s2 ser inicializada correctamente gracias a

-- las seales 'reset_N' o 'clear_N':
P1 : process(clk, reset_Jl, clear':'_N, dn)

I;legin
if reset_N = 'O' then
s2 <= 'O'; -- Inicializacin asncrona
elsif clk' event and clk = '1' then
if clearjN = 'O' then
s2 <= 'O'; -- Inicializacin sncrona
else
dout <= din;
end if;
end if;
end process PI;
11.5.3. Lgica 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 sntesis produzca un hardware ms eficiente
en cuanto a rea se refiere. En particular, esta regla se puede aplicar a las seales de
seleccin 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; -- Seal de escritura de dato1
write2 <= not(IW) and sel2; -- Seal de escritura de datQ2
-- Salida combinacional
datoout <= dato1 when readl = ' l' else

dato2 when read2 = ' l' else
'O' ;
-- Parte secuencial
principal : proceSS(rest_N,Sel1; S12, IW, datn, 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 ms complejo.
En el ejemplo anterior se tiene el siguiente cdigo:
-- CORRECTO

dato1 <= daton.
end if

dato2 <= daton:
end if
Pero se podra haber escrito (incorrectamente):
-- INCORREX:'l'O: Tal y como se ha hecho la descripcin, nunca se puede

-- producir el caso en el que write1 y write2 estn activos a la vez.

dato1 <= daton.
elsif write2 = '1' then
dato2 <= datonr
end if
Para permitir que la herramienta de sntesis optimice bloques combinacio-

nales, se puede utilizar el valor '-' del tipo std_logic.
-- Asignacin combinacional
salida <= 000 when entrada = 00 else.

001 when entrada = 01 el se
101 when entrada = 01 el se
M
,
En procesos que describen lgica combinacional, asegurar que las salidas

toman un valor, sea cual sea el camino de control.
En muchos casos, la manera ms conveniente de hacer esto es hacer, al prin-

cipio del proceso secuencial, una asignacin de valores por defecto de todas las
salidas:
-- Se quiere que salida sea 0090 cuando no sea ninguna opcin

-- vlida '
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,

-- opcin.
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 construccin if clk'event and clk 'L' =
(o 'O'), no pudiendo aparecer ninguna otra condicin en dicha construc-
cin. 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 mayora de las herramientas slo 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 comunicacin, 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 cdigo de manera que la construccin if clk'event and clk =

'L' (o 'O') est englobada en otra construccin if-then-else o en un buclefor.
S se pueden usar, sin embargo, bucles while (ver apartado /1.5.10).
-- INCORRECro:
la lnea 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, mustra) tn
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 cdigo (ver apartado 1/.5.5).
En algunas descripciones puede ser necesaria una gran cantidad de decisiones
antes de realizar una accin determinada. El englobar esto en una funcin o proce-
dimiento permite que el cdigo sea ms fcil de leer y hace que la herramienta de
sntesis cuente con un particionado que le facilita la optimizacin. 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 cdigo que pueda generar lgica 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_andar <= ..'-0';
elsif clk'evrit and clk = ,p then
dato_anterior <= dn;
end if; .
if din = '1' and dato_anterior = ' O' then

--dUt <; '1';-
else
dout <= '0';
end if;
end process;
Correcto: parte cOOlbinacionalfuera del proceso
-- Parte secuencial
procesa lreset'"..:.1t,"''ctk; din)
bgin
-tf reSetJ{ ;n (), then
dato anterior <= '0';
~lsif 'lx'I ~t ;aRd d_k -it, '1: then
dato_arlteior .<= _.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 comn. Si tienen seales en comn,
implementar una comunicacin entre procesos como la descrita en el apar-
tado l/.S.7.
11.5.5. Procesos mixtos

Reducir al mnimo el uso de procesos mixtos. Slo 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 cdigo relacionado con una misma fun-

cionalidad. Esto es una pista para que el sintetizador pueda hacer una opti-
mizacin ms eficiente.
No usar llamadas recursivas afunciones.
-- Esta funcin se llama a si misma

funCtion RestaUno(arg : integer) return integer is
begin
if arg > O then
return RestUno(arg)
end if
return I'g
end RestaUno
No usar atributos de seales dentro de funciones.

S se pueden usar atributos de tipo y de array.
No usar dentro de subprogramas seales o variables que no hayan sido
pasadas como parmetros en la llamada al subprograma.
-- INCORRECro: la seal Sa:).idano es pasada como parmetro

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 seal ~li&

es e:viada como parmetro
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_vetor(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 sncrono de 4; bits;

-- LEO es una salida Gel c.rcuno;
LEO <= BCDa7Segrnentos (Cuenta) ;
end Sintetizable;
11.5.7. Comunicacin entre procesos
A la hora de comunicar varios procesos, no presuponer nunca un orden de

ejecucin de dichos procesos. Se usar un sistema de comunicacin adecua-
do, bien un handshake explcito, si los procesos funcionan a distinta veloci-

dad, bien un sistema de comunicacin mediante seales de habilitacin de
procesos.
No mezclar nunca distintos sistemas de comunicacin entre procesos dentro
de un mismo bloque.
11.5.8. Mquinas de estados

Tanto para las mquinas de Moore como las de Mealy, conviene separar la
parte secuencial de la combinacional. Hacer las asignaciones de las salidas
con sentencias de asignacin concurrente; la asignacin del siguiente estado
con un proceso y una sentencia case; construir los registros en otro proceso
separado.
Representar los estados en las mquinas de estados con los valores de un tipo
especfico para cada mquina de estados. Estos valores sern 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
sigstado' <~~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
-- 'Generacin de salidas
-- Si salidas =
flestado actual, entradas) Mquina de Mealy
-- Si salidas = f(estado actual) Mquina de Moore
-- En este caso es una mquina 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. Comparticin de recursos

Las herramientas de sntesis suelen hacer, cuando pueden, comparticin 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 estn dentro de una
descripcin funcional, se puede usar la misma seal en los dos casos.
11.5.10. Sistemas "muy secuenciales" (procesos

con mltiples waits)
Hay que tener en cuenta que estos procesos no recomienzan hasta que haya
acabado el ciclo anterior. Es por ello que slo se usarn en aquellos casos
en los que se desea realizar una funcin "indivisible" y "autnoma".
Todos los waits tienen que usar el reloj del sistema.
Apndice 1/. Normas de codificacin y modelado en VHDL 481
11.5.11. Uso de tipos
Las entradas y salidas de los bloques de ms alto nivel deberan ser de tipo
std_ulogic o std_logic. Para asegurarse de que no se estn haciendo cone-
xiones de seales no deseadas, se pueden usar tipos no resueltos (en este
caso, std_ulogic).
En bloques de menor jerarqua se pueden usar tipos no estndar, ya que
stos permiten una rpida ampliacin de la funcionalidad y son ms fciles
de mantener y entender por el equipo de diseo.
Cuando se necesiten varios resultados de una funcin, se podrn 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 Sntesis, las referencias a com-

ponentes tienen el mismo nombre que los bloques a los que se corresponden.
Las seales de entrada a un bloque que no vayan a ser usadas dentro de ese
bloque se pondrn a un valor fijo (para la optimizacin plena, ponerlo a
valor '-' de std_logic).
Las seales de salida de un bloque que no vayan a ser usadas se dejarn sin
conectar. La herramienta de sntesis eliminar el hardware que no sea nece-
sario.
Poner un nombre significativo a todas las seales que conecten bloques en
una descripcin estructural.
11.5.13. Uso de los parmetros
/1.5.13.1. Introduccin
En sntesis, como mucho, slo permite que los genricos sean enteros, o bien tipos
enumerados que puedan asimilarse a enteros. Es por ello que para hacer una para-
metrizacin eficaz, no es suficiente con el uso de genricos.
La solucin que aqu se propone es el uso combinado de genricos y constantes
definidas en un package. El uso de estas constantes permite controlar el proceso de
sntesis, de modo que se puede:
1. Modificar la funcionalidad: se puede cambiar el modo de funcionamiento.

Por ejemplo, el lmite de cuenta de un contador o los niveles activos de las
seales 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. Modificacin de la funcionalidad
Los genricos y las constantes se pueden usar siempre que representen valo-
res escalares sin ningn 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 genricos y constantes tambin 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.
Apndice 1/. Normas de codificacin y modelado en VHDL 483
if cSincrono = true then

_:: PaIte fct.iElftcial
(opcional)
.Sa,lida <:;: '.1';
Salida <= Entrada;
end if;
else
__ Parte combinacional (opcional)
Salida <= Entrada;
end if;
11.5.13.3. Modificacin 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 genricos o constantes.
En descripciones estructurales, la sustitucin de componentes se har me-
diante la sentencia generate.
1/.6. EJEMPLOS
123 4 5 678
--34567890123456789Clf23456789012345678901234567890123456789012j45678~0234567890
--------------------------------------------_._ ....... '--_.--..;,:._ .... _._--'
........ _--_.:.. .....-_ ..... ... __ .... _._-,._-
..;.\-
-- TRANSMISOR (Entidad, ArqUitectura y Configuracin)
-- Fichero transmisor.vhd
-- Descripcin Transmisor serie de dato de longitud configurable

Orden de transmisin: 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 sncrono con el reloj del sistema. La velocidad de
transmisin lada 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.antet.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;stCLlogicJlsc: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 --Seal deres~t (ni~l l:la),8J.
Busy : out std....

logic; ~- Seflal de ocupdb (a uno): .
Tx : out std-Iogic ); -- salida serie .i:
end Transmisor;
architecture Comportamiento of Tr~smisor is

signal tempor unsignedIN..,l dormtct 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; -- Seal de envj.ando (a l.IlIO)
-signal contador integer range O to N+2; -- Contador de bits
begin
-- Generacin de la seal 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 vaco.
-- El dato se pierde si no eS almacenado.
-- Este procedimiento acta sobre seales definidas en la arquitectura y que
-- no son enviadas como parmetros.
procedure Carga is
if not temporLleno then
temporLleno <= true;
tempor <= data;
If not enviando then
temporLleno <= false;
enviando <= true;
regDeSp <=< 'o' &data;
end if;
end if;
end Carga;
;.~-;-------------------.- .... ,"'!' ... ...;--:--~,_ ....... _---_ .... - ........ -------------------------~~ ... --~ ... -
-- PROCEDIMIENl'O ENVIA:
-- Se encarga de envif'os datos del registro ~ desplazamiento a travs de
';;-lil seal tx. .
-- Se enva un solo bit cad.; vez que'se llama el procedimiento: se desplaza
r: el registro y se Incrarenta el contador de bits.
'..i_ Ctnd acaba la transmi~i6n 'COl11Pruebasi hay algn dato pendiente en el
-'- buffer. Si lo hay, pasa auahSliUtir el nuevo dato.
-- Este procedimiento acta sobre seales. definidas en la arquitectura y que
-- no son enviadas como parmet:r;os." ,. .
procedure Envia(signal tx : out std.._ui<Sgic) is
begin
-- Slo entra cuando est transmitiendo. La seal 'enviando' se activa en
-- el proceso PRINCIPAL(se pone a true)
if enviando then
if contador <= N then
-- Transmisin 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 transmisin

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 '
-- Inicializacin
if resetn = 'O' then
enviando <= false;
tempdrLleno <= false;
tenqx>r <= (others => 'O');
regDesp <= (others => '1');
-- Funcionamiento sncrono
if load = '1' then
carga;
end if;
--, Slo 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 Aritmtico-lgica
ASIC Application Specific Integrated Circuit
Circuito integrado de aplicacin especfica
ATE Automatic Test Equipment
Equipo de test automtico
ATPG Automatic Test Pattern Generation
Generacin automtica de vectores de test
BiCMOS Bipolar CMOS
CMOS Bipolar
CAD Computer Aided Design
Diseo asistido por ordenador
CAE Computer Aided Engineering
Ingeniera asistida por ordenador
CASE Computer Aided Software Engineering
Ingeniera del software asistida por ordenador
CFI CAD Framework Initiative
Iniciativa para la estandarizacin de entornos de CAD
CMOS Complementary Metal-Oxide Semiconductor
MOS complementaria
487
488 Glosario
CPLD Complex Programmable Logic Device

Dispositivo lgico programable complejo
CPU Central Processing Unit
Unidad central de proceso
DFf Design For Testability
Diseo para la testabilidad
DRC Des ign Rule Check
Verificacin de las reglas de diseo
ECL Emitter Coupled Logic
Lgica acoplada por emisor
EDA Electronic Design Automation
Automatizacin del diseo electrnico
EMI Electromagnetic Interference
Interferencia Electromagntica
ERC Electrical Rule Check
Verificacin de reglas elctricas
ESDA Electronic System Design Automation
Automatizacin del diseo de sistemas electrnicos
FPGA Field-Programmable Gate Array
Matriz de puertas programable
FPLD Field-Programmable Logic Device
Dispositivo lgico programable
FSM Finite State Machine
Mquina de estados finita
FSMD Finite State Machine with Data
Mquina de estados finita con datos
HDL Hardware Description Language
Lenguaje de descripcin de hardware
HLL High Level Language
Lenguaje de programacin de alto nivel
HLS High Level Synthesis
Sntesis de alto nivel
IC Integrated Circuit
Circuito integrado
IEEE Institute of Electronics and Electrical Engineers
Instituto de ingenieros electrnicos y elctricos
LSI Large Scale Integration
Integracin a gran escala
Glosario 489
MCM MultiChip Module

Mdulo multichip
MOS Metal-Oxide-Semiconductor
Metal-xido-Semiconductor
NMOS MOS tipo N
OMF Open Modeling Forum
Promueve la creacin de un interfaz estndar para la simulacin
de distintos modelos
PAL Programmable Array Logic
Matriz lgica programable
PCB Printed Circuit Board
Tarjeta de circuito impreso
PLA Programmable Logic Array
Matriz lgica"programable
PLD Programmable Logic Device
Dispositivo lgico programable
PMOS MOS tipo P
PRENDA PRoyecto para la Especificacin y Normalizacin en el Diseo
de ASICs
RTL Register Transfer Level
Nivel de transferencia de registros
SDF Standard Delay Format
Formato estndar 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 creacin de bibliotecas de celdas VHDL para
el diseo de ASICS
VHDL-AMS VHDL Analog-Mixed Signal
Extensin del VHDL para el caso analgico y mixto
VLSI Very Large Scale Integration
Integracin a muy gran escala
,
Indice
Acceso, tipo, 72 rango de vectores, 78

Aceleradores hardware, 149 seales, 80
ADA, 13, 180 tipos de datos, 79
Agregados, 69 Automatizacin del diseo electrnico
Alias, sentencia, 267, 283 (Eleetronie Design Automation, EDA), 4,
Algoritmo, 146, 254 8, 10, 147, 180
Analizador de
lxico,153
Baekannotation (vase Retroanotacin)
semntica esttica, 153
Bancos de pruebas (Test-beneh), 26, 30, 286,
sintaxis, 153
366,379,402
Apuntador, 72
configurables, 483
rboles sintcticos abstractos (Abstraet
Biblioteca de
Syntax Trees), 151
componentes, 397
Arquitectura, 46, 199
diseo, 53, 157,397,399
ASIC, 4
recursos, 397
celdas estndar precaracterizadas (semi-
Biblioteca, tipos, 397
eustomlstandard-eells), 5
Block, sentencia, 118, 212, 218
lgica programable (CPLD, FPGA,
Bloqueo (Deadloek), 141
FPLD),5
Buffer tri-estado, 212, 325
matrices de puertas predifundidas (semi-
Buses, 125
custom/gate-arrays), 5
Bsqueda de actividad, 141
totalmente a medida (jull-eustom), 5
Assert, sentencia, 98, 105
Atributos, 78 CAD (vase Herramientas CAD)
definicin, 81 CAD Framework Initiative, CFI, 12
491
492 ndice
Case, sentencia, 91, 215, 268 Depurado (Debugging), 144

Causalidad, 143 Deteccin de errores, 301,408
Ciclo de simulacin, 40, 139-143 Determinismo, 254
Ciclos de acceso a memoria, 272 Director, 374
Circuitos, evolucin, 3, 5, 9 Diseador, 359
Cliente, 359 Diseo. (vase tambin Etapas y Flujos de
Co-diseo de hardware y software (Hw/Sw diseo)
Co-Design), 10 arquitectural, 2, 375
Cola de eventos, 40, 140 ascendente (bottom-up), 6, 23, 350
Comparticin 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 fsico, 2, 394
declaracin, 107 genrico, 368, 389,410
referencia, 107 lgico, 2, 375, 385
Componentes de biblioteca, 378 organizacin del, 414, 416
Comprobacin de reusable, 405
diseo no considerado, 380 Diseo arquitectural, 375
estilo de codificacin y nomenclatura, documento de, 381
383 revisin del, 380, 383
estilo de descripcin, 383 Diseo configurable,
inicializaciones, 380 desarrollo, 432
listas de sensibilidad, 384 legibilidad, 434
terminaciones, 380 mantenimiento, 434
uso de puertos, seales, variables y nivel arquitectural, 434
genricos, 383 pruebas, 434
valores constantes en el cdigo, 384 seleccin de parmetros, 419
valores no considerados, 380 Diseo lgico, 375
Concurrencia, 254 documento de, 390
Configurabilidad, 398 revisin del, 390
Configurable, diseo (vase Diseo Dispositivos programables, 5
configurable) Documentacin, 394
Configuracin (Configuration), 49, 112 diseo, 407
definicin, 114 diseo arquitectural, 381
especificacin, 112 diseo lgico, 390
Configuracin, herramientas de, 404, 408 especificaciones, 362, 369
Constantes, 58 gua 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
Conversin de formato, 392
Co-rutinas, 167 EDA (vase Automatizacin del diseo
Co-simulacin, 171 electrnico)
Co-sntesis, 149 Ejecucin, 144
Cronogramas, 169 monitorizada, 154
Elementos lxicos, 54
Embedded Systems. (vase Sistemas
Derechos de propiedad intelectual, 158,410 empotrados)
Descripcin en HDL (vase Modelado) Emulacin, 148
ndice 493
Ensamblador, 147 Flujo de control, 137

Entero, tipo, 63, 200 Flujo de diseo, 21, 354
Entidad, 44, 156 ascendente (Bottom-up), 5, 23, 354
entidad vaca, 265 descendente (Top-down), 10,25,354
Entorno del circuito (vase Bancos de Formato intermedio, 153, 180
pruebas) FSM, FSMD (vase Mquinas de estados
Entorno virtual, 352 finitos)
Equipo de diseo, 20, 372 Funcionalidad, 251
ESDA, Electronic System Design funcionamiento no considerado, 380
Automation (vase Automatizacin del Funciones
diseo electrnico) de conversin de tipo, 62, 252, 265
Especificaciones, 26, 254, 286 (vase de resolucin, 125,256
tambin Etapas de diseo) declaracin, 120
abiertas, 413 definicin, 120
documento de, 369 llamada concurrente, 106
en HDL, 26, 367 llamada secuencial, 100
tecnolgicas, 370
Estado del modelo, 137
Estilo de codificacin y nomenclatura, Generate, sentencia, 110, 199
Estilo descriptivo, 16,46, 183,253,375 Genricos, parmetros, 111, 116
algortmico, 47, Grado de detalle, 16, 251
estructural, 48 temporizacin, 16, 182
flujo de datos, 47 tipos de datos, 17
mixto, 49 Gramtica
Estimadores, 408 con atributos, 152
Estmulos, 287, 289 independiente del contexto, 150
Etapas de Gua de referencia, 407
anlisis de viabilidad, 357
diseo arquitectural, 357
diseo fsico, 357 HDL (vase Lenguajes de descripcin de
diseo lgico o detallado, 357 hardware)
especificaciones, 356 descripcin mixta-multinivel, 11, 17,25
fabricacin y test, 357 independencia de CAD, metodologa y
requisitos, 356 tecnologa, 14, 19,27
Evaluacin de alternativas, 374 niveles de abstraccin, 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 fsico, 3, 7
simulacin mixta-multinivel, 11, 17,25,30
Fabricacin, fabricante, 378, 392 simulador SPICE, 3, 180
Fichero, tipo, 73, 402 sntesis, 10, 14, 17, 22, 26, 180
Fichero, objeto, 60 Heterarqua de procesos, 156,159
Ficheros, Hoja de catlogo (data-sheet), 408
de comandos, 402
fuente, 402
objeto, 402 Identificadores, 54
FPGA, FPW (vase Dispositivos If, sentencia, 89,216
programables) Indeterminismo, 165,254
Fsico, tipo, 63, 200 Ingeniera concurrente, 10
494 ndice
Inicializacin, 143,205,380 Memoria,

Instrucciones ROM,301
aritmtico-lgicas, 261 RAM,340
de acceso a memoria, 260 Metodologa de diseo, 21, 353 (vase
de salto, 261 tambin Flujo de diseo)
Intelectual Property Rights, IPRs (vase Microoperaciones, 328, 334
Derechos de propiedad intelectual) Microinstrucciones, 328, 334
Interaccin de procesos, 142 Microprogramas, 328, 334
Interfaz, 253, 270 Microsistemas, 9
Interoperabilidad, 407 Modelado, 144
Intrprete, 147 arquitectural-RT, 27, 182
detallado, 28, 290, 303
funcional-comportamental,26, 182,
Jerarqua, 22 254
de bloques, 159,270 Hw versus Sw, 13
de entidades de diseo, 159 multiplexores, 211
sntesis versus simulacin, 13, 17, 30,
295,37
Kernel,134 Temporal, 295
Realista, 296
Modelo
Latch,217 de insercin preemptiva, 140
Layout (vase Topografa de un circuito) de simulacin, 398, 409
Lazos, 216 matemtico, 138
Lenguajes de descripcin de hardware, para fabricacin, 409
HDL, 10,12-21,26-31,136, 180, 192 Modelos-HDL (vase Modelado)
Lenguajes de Programacin 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 abstraccin; 2,15-18
Lgica arquitectural-RT, 182,253
asncrona, 218 fsico, 2, 16
combinacional, 210 funcional-comportamental, 182
sncrona, 218 lgico-puertas, 182
Loop, sentencia, 94, 255, 279 Normas de codificacin y modelado, 374
Notas de aplicacin, 408
Null, sentencia, 100
Macroceldas, 352, 378 Nmero
Mantenimiento, 414 de edicin, 403
Mquinas de estados finitos, 226 de versin, 403
con datos (FSMD), 235
estilos explcitos, 226
estilos implcitos, 233 Objetos, 58
Mealy, 226, 231 Open Modeling Forum, OMF, 21
Moore, 229, 233 Operadores, 76, 201, 207
Mscaras (vase Topografa de un circuito) Optimizacin de cdigo, 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
declaracin, 50 Report, sentencia, 98, 105
Paralelismo, 252 Requisitos
Parametrizacin, mtodo de, 435 documento de, 361
Particionado, 370, 422 etapa de, 356, 359
Plan Restador, 308
de desarrollo, 370 Restricciones, 385
de pruebas, 370 sintcticas, 150
Planificacin 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
declaracin, 122 Retardo de pin a pin, 296
definicin, 122 Retemporizacin, 237
llamada concurrente, 106, 199 Retroanotacin, 6, 24, 29, 182
llamada secuencial, 106 Retum, sentencia, 100, 120, 122
Reusabilidad, 19, 158,405
Procesador
Revisin del diseo, 381, 390
4004,8086,4
mquina rudimentaria, MR, 260
Procesador hardware, 147
Segmentacin, 236, 389
Procesador MR, 260
Semforo, 255
rbitro de bus, 271
Semntica, 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 instruccin, 336 Seales, 39
indicadores, 306 asignacin concurrente, 103,210
instrucciones, 323 asignacin concurrente con seleccin,
seales de control, 330 104,211
unidad aritmtico lgica (VAL), 308 asignacin concurrente condicional, 103,
unidad de control, 274, 326 211
cableada, 328, 330 asignacin 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 Smbolos, 56
Proceso, 38, 213 Simulacin,
Procesos postpuestos, 164 de fallos, 174
Process, sentencia, 102 de sign-off, 174
lgica, 173
peor y mejor caso, 390
Real, tipo, 63, 200 por ordenador, 137
Refinamiento progresivo, 16,27,294 temporal, 174
496 ndice
Smulacin Tiempo,
comparativa, 395 de simulacin, 252
realista, 298 de propagacin, 297, 298, 299
Simulador lgico, 287 Time-driven, 139
Sintaxis, 150 Tipos de datos, 61,251
Sntesis, 22, 28 abstractos, 183
comportamental, 184 bit, 65,183
fsica, 181 compuestos, 67
lgica, 181, 196 declaracin, 62
mapeo tecnolgico, 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 Topografa de un circuito, 3, 6, 24, 403
Sistemas en chip (Systems on chip, Traductor, 146
SOCo Systems on silicon, SOS), 9, 23,
410
Ubicacin 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-especificacin, 367
de diseo, 155
Standard Delay Format, SDF, 30
Unit De/ay, 142
Subprogramas, 119
llamada concurrente, 106
llamada secuencial, 100 Validacin, 138,392,408
Subtipos de datos, declaracin, 66 Valor
Sumador, 18 actual, 161
completo, 311 conducido, 161
con acarreo anticipado, 313 efectivo, 161
con acarreo de propagacin , 311 Variables, 59
asignacin, 59, 88
globales, 254
Tareas Vector, tipo, 68
asignacin, 374 Vectores
coordinacin, 374 de simulacin, 403
Tecnologas, 3,9,378,385 de test, 289
Temporizacin, Verificacin, 286
funcional,182 automtica, 290
lgica, 182 temporal, 303, 344
RT,182 Verilog, 10, 13, 15, 18
Terminacin, 144 VHDL, 9,13-21
Test, 24, 30, 144 VHDL-AMS,l1
cobertura de faltas, 24 VIF, 155
de fabricacin, 390, 409 VITAL, 21, 30,188
diseo para testabilidad (Design for
testability, DFT), 24
Wait, sentencia, 82, 214, 219, 279
mquina de, 289
testabilidad, 24
vectores de test, 289 Zero Delay, 143

VHDL Lenguaje Estandar de Diseno Electronico PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VHDL Lenguaje Estandar de Diseno Electronico PDF

Uploaded by

Copyright:

Available Formats

~NGUAJ~~~TNDARD~

....., 11. )0.1 tl ::ul lJ.

RAFAEL BURRIEL LLUNA

FERNANDO ALDANA MAYOR

VHDL. Lenguaje estndar de diseo electrnico.

No est permitida la reproduccin total o parcial de este libro, ni su tratamiento inform-

DERECHOS RESERVADOS 1998, respecto a la primera edicin en espaol, por

Editor: Antonio Garca Brage

Eduard Lecha Llus Ters

Pablo Snchez Javier Uceda

Web con la presentacin e informacin complementaria de este libro:

2. PRESENTACIN DEL LENGUAJE VHDL . . . . . . . . . . . . . . . . . . . . . . 35

2.1. INTRODUCCIN, CONTEXTO y CONCEPTOS BSICOS ............... 36

2.5.6. La sentencia loop ........................ 94

3. PROCESADO Y MECANISMOS DE SIMULACIN DEL LENGUA-

3.3.3. Especificacin de un lenguaje de programacin. . . . . . . . . . .. 150

4.4.9. Descripcin de FSMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 226

5. MODELADO CON VHDL 249

6. LA GESTIN DEL DISEO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 349

6.1.1. Un proceso ideal de diseo en VHDL 351

Fernando Aldana Mayor, Rafael Burriel Lluna y Carlos Lpez Barrio

Uno de los inconvenientes que genera la evolucin muy rpida de la tecnologa en un

FERNANOO ALOANA MAYOR

Agradezco el esfuerzo que este equipo de autores ha dedicado a la formacin y

Actualmente, la mayor fuente de errores en la integracin procede habitual-

sntesis a las empresas. Su campo de aplicacin apenas ha comenzado y permitir la

RAFAEL BURRIEL LLUNA

La evolucin de la tecnologa microelectrnica ha sido tan rpida y profunda durante

Todo lo anterior tiene como piedra angular la utilizacin de los ya mencionados

CARLOS A. LPEZ BARRIO

La evolucin de la microelectrnica desde su nacimiento ha sido impresionante. En

perfiles de los equipos de diseo, cambios en la organizacin y desarrollo de proyec-

El objetivo de esta breve presentacin es mostrar qu son los lengua-

1.1. EVOLUCiN DEL DISEO ELECTRNICO

El desarrollo electrnico de los ltimos tiempos se ha visto fuertemente dominado y

FIGURA 1-1. Pirmide de complejidad y niveles de abstraccin de las distintas fa-

incidencia decisiva en el desarrollo de nuevas herramientas y entornos integrados de

1.1.1. Aos setenta

A pesar de estas dificultades surgieron las primeras memorias DRAM de 1

1.1.2. Aos ochenta

circuitos integrados desarrollados para aplicaciones especficas pudiendo ser dise-

1. Diseo totalmente a medida (jull-custom). El diseador se enfrenta a los ni-

" especificaciones funcionales ,,

Ubicacin y conexionado (layout)

FIGURA 1-2. Flujo genrico de diseo ascendente (bottom-up) de circuitos semi-

Procesos de ubicacin y conexionado (place&route) de celdas y bloques uti-

Extractor de lista de componentes y conexiones (Netlist)

Esquema (E) Topografa (T)

Simulador Analgico (SPICE)

FIGURA 1-3. Entorno de diseo a nivel elctrico y geomtrico para el desarrollo de

H: Herramienta, idU: Interfaz de Usuario, BdD: Base de Datos, I/F: Interfaz

FIGURA 1-4. Evolucin de las herramientas y entorno de CAD: (a) Herramientas

Todos estos avances empujaron y a la vez se apoyaron en la propia evolucin

1.1.3. Aos noventa

VHDL sintetizable) u optimizados a nivel hard (layout o topografa especfica), cu-

I El objetivo de la ingeniera concurrente es simultanear las tareas de distintos departamentos o

positivos), as como el desarrollo de nuevas estrategias y tcnicas de test como las

1.2. LOS LENGUAJES DE DESCRIPCiN DE HARDWARE

2 La CFI (CAD Framework lnitiative) promueve la creacin de un estndar para el desarrollo de

1.2.1. Lenguajes de descripcin de Hw versus desarrollo

(a) Desarrollo de Software (b) Desarrollo de Hardware

FIGURA 1-6. Desarrollo de software versus hardware: (a) niveles de abstraccin y

Mientras en software se recurre a los lenguajes de alto nivel para implementar

Actualizar seales _ (-J JQL _--- ...... _-------_.