Está en la página 1de 520

~ N G U A J ~~ ~ T N D A R D ~

D I ~~ O~~C T R N I C O
SeroHnOlloz
Eugenio Villcir
Yago 'forrojo
Lluis T ores
....., 11. ) 0 . 1 tl : : u l lJ.
J "
Enlo direccin h Hp : / /w w w .c n m .es /IM B /Ub r o VHDL J del W eb 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
LENGUAJ E 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
J efe 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 SToLOUIS TOKIO TORONTO
La informacin contenida en este trabajo ha sido obtenida
por McGraw-Hill Incorporated procedente de fuentes dig-
nas decrdito. No obstante, ni McGraw-Hill ni los autores
garantizan laexactitud 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 sepublica con el reconoci-
miento expreso de que los autores estn proporcionando
una informacin, pero no tratando deprestar ningn tipo de
servicio profesional o tcnico. Si tal servicio fuera necesa-
rio, drjase aun profesional adecuado para tal fin.
No est permitida lareproduccin total o parcial deeste libro, ni su tratamiento inform-
tico, ni latransmisin de ninguna forma o por cualquier medio, yaseaelectrnico, mec-
nico, por fotocopia, por registro u otros mtodos, sin el permiso previo y por escrito de
los titulares del Copyright.
ISBN: 84-481-1196-6
Depsito legal: M. 42.860-1997
Editor: Antonio Garca Brage
Cubierta: J uan Garca
Compuesto en: FER Fotocomposicin, S. A.
Impreso en: Impresos y Revistas, S. A. (IMPRESA)
IMPRESO EN ESPAA - PRINTED IN SPAIN
DERECHOS RESERVADOS 1998, respecto ala primera edicin en espaol, por
McGRAW-HILUINTERAMERICANA DE ESPAA, S. A. U.
Edificio Valrealty, l." planta
Basauri,17
28023 Aravaca (Madrid)
VHDL. Lenguaje estndar de diseo electrnico.
Coautores
Eduard Lecha
Instituto deMicroelectrnica deBarcelona, CNM
(CSIC). Universitat Autnoma de Barcelona
eduard@cnm.es
Manel Mor de Castro
Instituto deMicroelectrnica deBarcelona, CNM
(CSIC). Universitat Autnoma deBarcelona
manel@cnm.es
Serafn Olcoz
SIDSA
olcoz@sidsa.es
Teresa Riesgo
Universidad Politcnica deMadrid, ETSn
tere@upmdie.upm.es
Fernando Rincn
Instituto deMicroelectrnica deBarcelona, CNM
(CSID). Universitat Autnoma deBarcelona
femando@cnm.es
Pablo Snchez
Universidad deCantabria
sanchez@teisa.unican.es
Llus Ters
Instituto deMicroelectrnica deBarcelona, CNM
(CSIC). Universitat Autnoma de Barcelona
lluis@cnm.es
Eduardo de la Torre
Universidad Politcnica deMadrid, ETSII
eduardo@upmdie.upm.es
Yago Torroja
Universidad Politcnica deMadrid, ETSn
yago@upmdie.upm.es
Joan Vidal
Instituto deMicroelectrnica deBarcelona, CNM
(CSIC). Universitat Autnoma de Barcelona
vidal@cnm.es
Eugenio Villar
Universidad deCantabria
villar@teisa.unican.es
Javier Uceda
Universidad Politcnica deMadrid, ETSII
uceda@upmdie.upm.es
Web con lapresentacin einformacin complementaria deeste libro:
http://www.cnm.es/IBMlLibroVHDU
v
Contenido
PRESENTACIN .
PRLOGO .
1. INTRODUCCIN .
1.1. EVOLUCIN DEL DISEO ELECTRNICO .
1.1.1. Aos setenta .
1.1.2. Aos ochenta .
1.1.3. Aos noventa .
1.2. Los LENGUAJ ES DE DESCRIPCIN DE HARDWARE .........
1.2.1. Lenguajes de descripcin de Hw versus desarrollo de Sw .
1.2.2. Resea histrica de los HDLs .
1.2.3. Modelado con HDLs: niveles de abstraccin y estilos descrip-
tivos .
1.2.4. Aportaciones de los HDLs al proceso de diseo .
1.3. METODOLOGAS yFLUJ OS DE DISEO .
1.3.1. Flujo de diseo ascendente (bottom-up) .
1.3.2. Flujo de diseo descendente (top-down) .
1.3.2.1. Construccin odiseo descendente .
1.3.2.2.. Informacin ascendente (bottom-up) .
1.3.2.3. Validacin funcional multinivel .
1.4. BIBLIOGRAFA ............................................
xv
xxi
1
2
3
4
9
12
13
14
16
19
21
23
25
26
29
30
31
vii
viii Contenido
2. PRESENTACIN DEL LENGUAJE VHDL . . . . . . . . . . . . . . . . . . . . . . 35
2.1. INTRODUCCIN, CONTEXTO yCONCEPTOS 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 dedatos 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. OBJ ETOS, 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 detipos dedatos. . . . . . . . . . . . . . . . . . . . 62
2.4.3.2. Tipos dedatos escalares. . . . . . . . . . . . . . . . . . . . . . . . 63
2.4.3.3. Declaracin desubtipos dedatos .. . . . . . . . . . . . . . . . 66
2.4.3.4. Tipos dedatos compuestos . . . . . . . . . . . . . . . . . . . . . . 67
2.4.3.5. Otros tipos dedatos 72
2.4.4. Expresiones y operadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.4.5. Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.4.5.1. Atributos derangos devectores. . . . . . . . . . . . . . . . . . 78
2.4.5.2. Atributos detipos dedatos. . . . . . . . . . . . . . . . . . . . . . 79
2.4.5.3. Atributos deseales 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 deundiseo. . . . . . . . . . . . . . . . . . . .. 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. EJ ERCICIOS 128
2.9. BIBLIOGRAFA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3. PROCESADO Y MECANISMOS DE SIMULACIN DEL LENGUA-
J EVHDL 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 deavance 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 LENGUAJ E 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 UNAENTIDADDEDISEOVHDL 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. MODELADOENVHDL PARASIMULACIN.. . . . . . . . . . . . . . . . . . . . . .. 171
3.5.1. Simulacin lgica, temporal y de fallos . . . . . . . . . . . . . . . . .. 173
3.6. EJ ERCICIOS 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 ENSNTESIS 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 DECIRCUITOSDIGITALES 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 dehardware 239
4.5.1.2. Limpieza del cdigo. . . . . . . . . . . . . . . . . . . . . . . . . .. 240
4.5.1.3. Correspondencia entre simulacin y sntesis 241
4.5.1.4. Conocimiento delaherramienta 241
4.6. EJ ERCICIOS 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 anivel de lenguaje m-
quina 260
5.3.1.2. Modelo funcional delamquina 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 depruebas para verificar las especificaciones. 289
5.4.2.3. Anlisis delas 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. LaUnidad deProceso 304
5.5.4.2. LaUnidad deControl. . . . . . . . . . . . . . . . . . . . . . . . .. 326
5.5.4.3. La memoria deprogramas. . . . . . . . . . . . . . . . . . . . . .. 340
5.6. EJ ERCICIOS 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. Larevisin del diseo arquitectural. . . . . . . . . . . . . .. 381
6.2.3.3. Desarrollo del diseo lgico. . . . . . . . . . . . . . . . . . . .. 385
6.2.3.4. Larevisin 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 deversiones. . . . . . . . . . . . . . . . . . . . . . . . . .. 402
6.3.3.2. Control deconfiguraciones 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 deparmetros. . . . . . . . . . . . . . . . . . . . . . .. 419
6.5.3.3. Particionado del diseo 422
6.5.3.4. Estructuras dedatos 423
6.5.3.5. Otras recomendaciones sobre lacodificacin 425
6.6. DISEOS CONFIGURABLES 431
6.6.1. Desarrollo de un componente configurable. . . . . . . . . . . . . . .. 432
6.6.1.1. Seleccin delos parmetros deconfiguracin . . . . . .. 433
6.6.1.2. Aspectos aconsiderar enlageneracin decomponentes
configurables en VHDL . . . . . . . . . . . . . . . . . . . . . . .. 433
6.6.1.3. Diseo arquitectural. . . . . . . . . . . . . . . . . . . . . . . . . .. 434
6.6.1.4. Mtodo degeneracin 435
6.6.1.5. Bancos deprueba . . . . . . . . . . . . . . . . . . . . . . . . .. 437
6.7. EJ ERCICIOS 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 delos inconvenientes quegenera laevolucin muy rpida delatecnologa enun
determinado campo, es lagran dificultad que tienen los profesionales del sector para
adaptarse alos cambios enlos mtodos, procedimientos yherramientas. Como resul-
tado deestos efectos, las empresas dedican cada vez ms recursos asus actividades
deformacin continua.
Nuestra sociedad delainformacin sesustenta sobreel desarrollo microelectr-
nico, quepermite disear yfabricar aunritmo vertiginoso sistemas electrnicos cada
vez ms complejos acostes muy razonables; pero ese aumento de la complejidad
sobre el que seapoya el desarrollo haexigido modificar, casi dira revolucionar, los
procedimientos dediseo y fabricacin.
Las metodologas dediseo electrnico denominadas "top-down", basadas enel
empleo delenguajes dedescripcin dehardware, han transformado los procedimien-
tos dediseo desistemas electrnicos, muy especialmente decircuitos integrados. El
lenguaje VHDL es su ms claro exponente, abriendo enormes posibilidades al per-
mitir lasimulacin con descripciones departes del sistema con diferentes niveles de
abstraccin. Esto, unido alaposibilidad derealizar lasntesis automtica, y alacon-
cepcin debloques reutilizables y reconfigurables en funcin delas necesidades de
la aplicacin, hapermitido dotar al diseador deenormes recursos que hacen posi-
ble abordar lacreciente complejidad con mayores garantas dexito.
Admitidas las ventajas, hasido necesario adaptar laformacin delos ingenieros
dediseo y test, pasando deun perfil claramente electrnico, orientado alainterco-
nexin debloques hardware, aun perfil ms algortmico, ms informtico, conse-
cuencia de los nuevos procedimientos. En el marco de esa demanda de formacin
xv
xvi Presentacin
aparece estelibro, dando satisfaccin auna necesidad bien identificada entre los tc-
nicos dehabla hispana.
Setrata deuna obra que recoge los temas fundamentales vinculados alautiliza-
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 lasintaxis del lenguaje, como si setratara de
un manual dereferencia, 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 deingeniera con una
buena formacin debase en electrnica einformtica oestudiantes de los ltimos
cursos de carrera. Este libro tambin podra emplearse en actividades de post-
grado, orientadas ala formacin de profesionales en la empresa o aun curso de
doctorado.
El enfoque del libro estavalado por laexperiencia contrastada delos autores en
su actividad diaria, por la combinacin deprofesionales de laempresa, profesores
universitarios einvestigadores en microelectrnica.
En sntesis, este trabajo supone una aportacin valiosa en el proceso deadapta-
cin tecnolgica aunas circunstancias cambiantes, que han exigido, exigen yexigi-
rn esfuerzo eimaginacin alos profesionales deun sector tan dinmico como es la
microelectrnica.
FERNANOO ALOANA MAYOR
Catedrtico deTecnologa Electrnica
ETSll. Universidad Politcnica deMadrid
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 uninevitable proceso del ser humano tendente aeliminar supropia inter-
vencin en cualquier actividad que, paradjicamente, comienza l mismo. Esto tam-
bin haocurrido enel campo del diseo deCircuitos Integrados deAplicacin Espe-
cfica ASICs con laintroduccin del VHDL.
Los objetivos deeste proceso estn motivados por el necesario intento deelimi-
nar los errores introducidos por el escasamente fiable individuo, aumentar sustan-
cialmente suproductividad afindepoder manejar los centenares.demiles depuertas,
ya son millones!, dentro de un tiempo industrialmente viable, as como operar de
formajerarquizada y eficiente con semejante volumen deinformacin deforma que
sea factible su manejo y transferencia. La existencia de una documentacin fiable
tanto deuna biblioteca declulas, deASICs completos, desuespecificacin 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 deun lenguaje formal, apto para su simulacin y posterior
sntesis, capaz deincorporar ficheros tecnolgicos y criterios deintegracin necesa-
rios para eliminar las ambigedades existentes en lamisma; esto obliga auna slida
coherencia enlafasedeespecificacin. Dehecho, empresas relevantes yahan estado
formando asus ingenieros demarketing en VHDL para mentalizarlos con el posible
lenguaje con el que sus clientes podran solicitarles futuros productos.
Actualmente ya sedispone, y secontinan desarrollando, demltiples ayudas
por ordenador que, basndose en estas descripciones VHDL, incorporarn ayudas
complementarias para unposicionado ptimo debloques, trazados inteligentes, esti-
macin y posterior verificacin decaminos crticos, sntesis con optimizacin inte-
ractiva derea, velocidad yarquitecturas, insercin automtica decapacidad dediag-
nstico, generacin automtica depatrones deprueba, consumo, etc. yfinalmente un
paso que es inevitable para el diseo de ASICs ms complejos: el desarrollo de
herramientas y entornos deCo-Diseo HW y SW para laoptimizacin en ladistri-
bucin de tareas, emulacin, simulacin y finalmente realizacin. Realmente el
VHDL seest convirtiendo en el lenguaje universal delamicrolectrnica (digital al
menos) aunque no hay que olvidar ni los huecos ni los electrones con sus capri-
chos, yes necesario no perder el contexto elctrico yelectrnico delarealidad, ni el
objetivo industrial delaintegracin en cuanto acoste, plazo, consumo, interfaz con
el mundo real, etc.
As, laintroduccin 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 deintuicin todava seresiste aladisciplina delaformalizacin VHDL,
quepor otraparte an no est completamente disponible.
El diseo deCircuitos Integrados alaMedida (antiguos circuitos LSI o VLSI, y
posteriormente ASICs) ha adolecido desde sus comienzos aprincipios deladcada
delos setenta defacilidades para que las empresas establezcan un interfaz industrial
adecuado y slido para migrar undiseo realizado con unadeterminada 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 lanecesaria transferibilidad a
una empresa, de diseos, arquitecturas o desarrollos deASICs realizados por cen-
tros externos adicha empresa -por ejemplo atravs deProgramas Comunitarios-
lacual necesita reutilizarlos total o parcialmente para suposterior incorporacin a
integraciones (ASICs) demayor escala en supropio 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 sebasan en VHDL, el cual permite una eventual sntesis en otro con-
texto tecnolgico.
As, laincorporacin del lenguaje VHDL alarealizacin deASICs haconsti-
tuido un hito importante y decisivo para laindustria en cuanto aproductividad y a
transferibilidad serefiere, yaque ha aumentado laproductividad delos diseadores
deforma sustancial y sehafacilitado lautilizacin deherramientas industriales de
xviii Presentacin
sntesis alas empresas. Sucampo deaplicacin apenas hacomenzado 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 deInvestigacin y Desarrollo deAleatel Espaa
Laevolucin delatecnologa microelectrnica hasido tanrpida yprofunda durante
laltima dcada y media que haposibilitado el que hoy podamos fabricar circuitos
integrados de elevada complejidad. Este hecho, unido alas demandas del mercado
por reducir los ciclos y costes de desarrollo, plantea unos retos importantes en el
campo del diseo y delas herramientas deayuda y automatizacin del mismo.
As, el enfoque con el que sedisean los circuitos integrados ha tenido que ir
evolucionando atravs de varios niveles deabstraccin. Del diseo geomtrico del
circuito y resolucin de las ecuaciones diferenciales, sepas 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 ala 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 delas fases dealto nivel es probablemente latarea ms
importante enel diseo deuncircuito. Las decisiones dearquitectura sonlas quetie-
nen unmayor impacto en todos los parmetros delos circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores setienen que realizar siempre impor-
tantes contribuciones al diseo, es difcil que optimizaciones realizadas en dichas
fases puedan compensar una mala seleccin delaarquitectura deuncircuito.
La c'Orrectarealizacin delas fases de alto nivel es probablemente latarea ms
importante en el diseo deuncircuito. Las decisiones dearquitectura sonlas quetie-
nen unmayor impacto en todos los parmetros delos circuitos: complejidad, veloci-
dad y consumo. Aunque en fases posteriores setienen que realizar siempre impor-
tantes contribuciones al diseo, es difcil que optimizaciones realizadas en dichas
fases puedan compensar una mala seleccin delaarquitectura deuncircuito.
El diseo de alto nivel es adems el punto de encuentro de los diseadores de
sistemas ydecircuitos. Ambos deben aportar suscontribuciones, bien desde el cono-
cimiento de las aplicaciones bien desde el dela tecnologa. Por ello este libro est
dirigido aun amplio grupo deprofesionales, desde los diseadores desistemas, 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 lautilizacin delos yamencionados
lenguajes de descripcin hardware. De todos ellos, el VHDL, definido como un
estndar, haido ganando fuerza tanto en el mundo universitario como industrial. De
ah el inters deeste 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 lasintaxis del lenguaje VHDL, sino tambin gran cantidad dedetalles
prcticos y ejemplos que facilitan lacompresin delos conceptos. Por otra parte, el
ltimo captulo incluye una referencia sobre consideraciones prcticas delagestin
deundiseo que puede resultar deespecial 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 atravs delaexperiencia.
Hemos de felicitamos por esta iniciativa deun amplio grupo deprofesionales
denuestro pas, tanto del mundo acadmico como industrial, por volcar eneste texto
laexperiencia acumulada alo largo deaos detrabajo docente, dediseo, deinves-
tigacin ydecooperacin en el marco del Grupo Espaol deUsuarios deVHDL, as
como por contribuir adisponer debibliografa microelectrnica en espaol, lacual,
tristemente, es muy escasa.
Estoy seguro deque estelibro servir como referencia amuchos diseadores ya
experimentados, pero tambin constituye unexcelente texto parauncurso degrado o
postgrado universitario. Espero, por tanto, no slo que el lector disfrute con su lec-
tura, sino que nos ayude tambin adifundir los conocimientos bsicos sobre las tc-
nicas dediseo microelectrnico.
CARLOS A. LPEZ BARRIO
Catedrtico deTecnologa Electrnica (ETSIT-UPM) y
Director deInnovacin (Telefnica I +D)
Prlogo
Laevolucin delamicroelectrnica desde sunacimiento ha sido impresionante. En
poco ms dediez aos sepas del primer dispositivo integrado (jlip-flop conunos po-
cos transistores) alas primeras memorias y procesadores. A los pocos aos, el diseo
decircuitos integrados salidelasfbricas y sehizo accesible alosingenieros deapli-
cacin, dando lugar alosASIC (Application Specific Integrated Circuit). Yaentonces,
mediados delos aos ochenta, sepuso demanifiesto lanecesidad dedisponer deun
lenguaje estndar capaz dedar el soporte necesario al proceso completo dediseo de
chips y sistemas electrnicos (desde la idea hasta la implementacin y explotacin
deundesarrollo) en sus distintas etapas y niveles deabstraccin y cuya complejidad,
yadepor s elevada, seibaaincrementar drsticamente hacia los aos noventa.
Estas inquietudes, canalizadas atravs del DoD (Dpt. of Defense) delos EEUU,
llevan al nacimiento del VHDL (1987), que, tras ser adoptado como estndar del IE-
EE (Std.-I076-1987), sepresenta como el lenguaje estndar por excelencia del dise-
o electrnico. Yadesde el primer momento seconvirti en laherramienta y el mo-
tor debase que ha facilitado eimpulsado los enormes avances delas 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 debase, laimplantacin deestelenguaje hasupuesto tal cantidad decambios
en el diseo electrnico (nuevas metodologas dediseo dealto nivel y flujos des-
cendentes, herramientas CAD desimulacin/sntesis decircuitos y sistemas, nuevos
xxi
xxii Prlogo
perfiles delos equipos dediseo, cambios en laorganizacin y desarrollo deproyec-
tos, etc.), que, sinlugar adudas, sepuede hablar deunantes yundespus del VHDL.
La idea dedesarrollar este libro surgeen el seno del Grupo Usuarios deVHDL
deEspaa (GUVE) y seasienta sobre labase deuna larga trayectoria decolabora-
cin entre los distintos coautores y sus respectivos centros. Durante los ltimos aos
esta estrecha relacin seha vehiculado en repetidas ocasiones atravs del programa
GAME (Grupo Activador delaMicroelectrnica en Espaa) delaComisin Euro-
pea, y en especial alrededor deuno de sus ltimos proyectos: PRENDA (PRoyecto
para laEstandarizacin y Normalizacin del Diseo de ASIC's). As pues, lacon-
vergencia dealgunos proyectos, lamotivacin, experiencia ycolaboracin delos co-
autores y sobretodo el constante estmulo del GUVE para promover y facilitar ladi-
fusin eimplantacin deestas nuevas tcnicas dediseo electrnico, son las bases
quehan dado lugar aeste libro.
El libro que aqu les presentamos sehaconcebido, no slo para presentar y dar
aconocer el lenguaje VHDL, sino que adems condensa enunos pocos captulos las
distintas facetas del mismo y su explotacin dentro del proceso de diseo. En este
sentido podemos decir que setrata deuna gua aplicada del VIDL, siendo asu vez
altamente autocontenido.
As pues, tras laubicacin deestos lenguajes dentro delaevolucin del diseo
electrnico (Captulo 1), seprocede aunapresentacin del lenguaje VHDL (Captu-
lo 2) que, sin ser exhaustiva, es muy completa y detallada, basndose en numerosos
ejemplos que facilitan lacomprensin ntima del lenguaje.
A continuacin enel Captulo 3seestudian endetalle el procesado del lenguaje
y los mecanismos de simulacin que permitirn al lector extraer criterios demode-
lado para aplicar deforma eficiente en las descripciones para simulacin en VHDL.
Por suparte, la sntesis desde el VHDL es, junto con lasimulacin, una delas prin-
cipales aplicaciones del lenguaje. El Captulo 4, tras un anlisis general sobre el uso
deestos lenguajes en los procesos de sntesis, sededica adetallar lautilizacin del
VHDL anivel de sntesis RT-lgica en base alos mtodos y herramientas CAD ac-
tuales. Ello, junto con un conjunto derecomendaciones demodelado para sntesis,
proporcionar al lector los conocimientos y criterios necesarios para un modelado
eficiente para lasntesis.
En el Captulo 5 semuestra la utilizacin del VHDL en distintos aspectos del
modelado desistemas electrnicos (modelado del diseo ydel entorno detest, simu-
lacin versus sntesis, etc.). Es unapresentacin muy aplicada que seapoya enel de-
sarrollo deunejemplo completo: unpequeo procesador y suentorno. Es unejemplo
sencillo cuyo recorrido permite consolidar unos conocimientos prcticos muy difci-
les deasumir exclusivamente desde un plano terico, que tambin sepresenta. Por
ltimo el Captulo 6, tambin muy aplicado, nos enfrenta, desde laperspectiva del
VHDL, atodauna seriedecuestiones relativas alaorganizacin ygestin del diseo
queraramente secomentan en los textos, pero cuyo tratamiento puede, enbuena me-
dida, garantizar el xito y lacalidad del diseo si es el adecuado, o ser causa defra-
caso si no seleconsidera convenientemente.
Estos seis captulos secomplementan con sus respectivos apartados deejerci-
cios, dos apndices y un glosario que ayudan adisponer deun 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 einteractiva alrededor
de este libro, se han organizado algunas pginas de Internet en la direccin
http://www.cnm.es./IMB/LibroVHDU. donde, adems delapresentacin del libro,
sepueden encontrar ejercicios resueltos, los cdigos VHDL completos delos 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 setrata deuntexto dirigido tanto alos estudiantes y profe-
sores decualquier titulacin que incluya materias dediseo electrnico como alos
profesionales del sector. Todos ellos encontrarn enestelibro unpunto dereferencia,
ya sea para iniciarse en el lenguaje y sus aplicaciones, o para aclarar y consolidar
conceptos y asesorarse en el desarrollo deproyectos basados en el uso deestos len-
guajes, y los mtodos y tcnicas dediseo que deellos sederivan.
En cuanto alos coautores delos distintos captulos, slo decir que setrata deun
colectivo deexpertos en diseo electrnico y en laaplicacin deestos lenguajes. La
mayor parte deellos desarrollan suactividad enel mbito acadmico y deinvestiga-
cin, pero todos poseen adems una amplia experiencia en desarrollos industriales.
Forman parte del colectivo deprofesionales que, desde el nacimiento de estos len-
guajes, sehan esforzado y comprometido en sudifusin, uso eimplantacin 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 yJ oan Vida)
IMB-CNM (CSIC)
Universitat Autnoma deBarcelona
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, 5Y6). 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 delos ltimos tiempos sehavisto 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 deladca-
da de los ochenta [IEEE81, J SV82, 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 defabricacin, han ampliado el rango deposibilidades de
los ingenieros de aplicacin, permitindoles disear chips especficos (Application
Specific Integrated Circuits, ASICs) [NB88] para los productos quedesarrollan.
Todos estos factores han contribuido directamente ala evolucin de los recur-
sos de clculo (procesadores, estaciones de trabajo, ...) quienes a su vez tienen una
<10pg.
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 denuevas herramientas y entornos integrados de
diseo de sistemas electrnicos. Con el desarrollo y uso de tales herramientas para
crear nuevos componentes secierra el ciclo del soporte mutuo entre ambas tecnolo-
gas: microelectrnica einformtica.
La Figura 1-1esquematiza cmo apartir de las especificaciones de un circui-
to' y afin depoder proceder asu fabricacin, el proceso dediseo deCIs 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 laarquitectura/estructura delaimplementacin sin detallar larealizacin fsi-
ca final) y fsico (sedetalla una materializacin concreta anivel elctrico y geom-
trico para una determinada tecnologa). Obsrvese que la complejidad del diseo
en trminos de volumen de informacin amanejar aumenta drsticamente amedi-
da que avanzamos por estas fases, al incrementar la precisin y disminuir el nivel
deabstraccin.
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 deesta seccin sobrevolaremos los aos setenta, ochenta y noventa
mencionando el tipo detecnologas, circuitos, metodologas, CAD (Computer Aided
Design) y plataformas hardware/software que sehan ido desarrollando en cada po-
ca, resumiendo deesta forma laevolucin delamicroelectrnica.
1.1.1. Aossetenta
Durante esta dcada hay una fuerte evolucin delos procesos defabricacin decir-
cuitos integrados yjunto alas tecnologas bipolares surgen las MOS (Metal-Oxide-
Semiconductor). Estas ltimas, bajo laforma deNMOS, 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].
Yafuesen 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 sedesarrollaban completamente (di-
seo y fabricacin) dentro de las propias fbricas (joundries) sin que este nivel de
diseo fuese accesible fuera dedicho contexto.
El esfuerzo dediseo seconcentraba en los niveles elctrico (establecer carac-
tersticas e interconexiones de los componentes bsicos anivel de transistor) y to-
pogrfico (dibujar las mscaras, layout, necesarias para lafabricacin delos 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, aexcepcin del SPICE [Nag75], simulador
de esquemas elctricos con modelos personalizables para distintas tecnologas y
que ha sobrevivido al paso del tiempo, pues todava hoy seutiliza l o sus descen-
dientes directos.
4 VHDL. Lenguaje estndar de Diseo Electrnico
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 alaentonces recin creada INTEL, que los desarroll en tecnologa PMOS. A
finales de los setenta estos dispositivos yahaban 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 yplataformas hardware y facilitaron, hacia finales deesta dcada, el naci-
miento de los miniordenadores, que desbancaron alos grandes ordenadores (main-
frames) delos aos setenta [Hay79, Roi86, Ser94].
1.1.2. Aos ochenta
A la vez que los procesos tecnolgicos sehacan ms complejos para poder asumir
mayores densidades deintegracin sehaba ido identificando el conjunto bsico de
informacin que senecesita conocer afin depoder realizar diseos para una deter-
minada tecnologa, esto es: parmetros elctricos delos distintos componentes acti-
vos y pasivos para poder definir esquemas elctricos y las reglas dediseo geom-
trico para poder dibujar la topologa del circuito. Estas estrategias para independi-
zar el proceso dediseo del proceso de fabricacin empiezan ahacerse realidad de
la mano de Hon &Sequin [HS80], Conway &Mead [MC80] afinales de los aos
setenta y con ello el diseo de Cls comienza a hacerse accesible fuera del propio
contexto delas fbricas de semiconductores.
En ese momento seconstata que hay un desfase enorme entre tecnologa y di-
seo. La considerable complejidad delos chips que sepueden fabricar supone unos
riesgos y costes de diseo desmesurados e imposibles de asumir, debido auna ca-
rencia casi absoluta de metodologas y herramientas de diseo y a la inviabilidad
econmica de aplicar tcnicas deprototipado decircuitos impresos (Printed Circuit
Board, PCB), basadas en el desarrollo demaquetas (breadbording], para el diseo y
depurado deCls.
A raz deesta situacin seinici una fuerte actividad sobre el desarrollo deme-
todologas y herramientas CAD para el diseo de CIs que ha cambiado drstica-
mente el contexto y los entornos de diseo, no slo anivel 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 anivel deproductos industriales.
En cuanto atecnologas semantienen las bipolares como las ms utilizadas pa-
radesarrollos analgicos o mixtos; mientras que en el diseo digital las CMOS (es-
tructuras complementarias basadas en transistores p y n sobre un mismo substrato)
seimponen claramente alas antiguas NMOS. Hacia finales delos ochenta nacen las
BICMOS, que permiten crear sobre un nico substrato dispositivos bipolares y
CMOS facilitando as el desarrollo decircuitos mixtos analgico-digitales.
A nivel decircuitos, obviamente sesiguen 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 delaaplicacin.
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 secitan acontinuacin:
1. Diseo totalmente amedida (jull-custom). El diseador seenfrenta alos 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 defabricacin. 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 depuertas 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 alas posi-
bilidades de la estructura prefabricada y se realiza en base auna biblioteca
deceldas precaracterizadas para cada familia dedispositivos [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 labiblioteca) 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 sepueden personalizar desde el exterior median-
te diversas tcnicas deprogramacin (RAM, fusibles, etc.). El diseo seba-
saen bibliotecas y mecanismos especficos demapeado defunciones, 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 sepueden 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 delos programables.
Como yasehaindicado anteriormente, laevolucin delos entornos de diseo ha
seguido unproceso ascendente (Bottom-up) quedurante los aos ochenta lleg acon-
solidar los niveles fsico y lgico odepuertas. En primer lugar seabord el nivel fsi-
co y sedesarrollaron alapar herramientas dirigidas ados contextos distintos:
El diseo elctrico y geomtrico deceldas y bloques bsicos utilizando tc-
nicas dediseo amedida. Para ello fuenecesario confeccionar entornos co-
mo el que semuestra en laFigura 1-3[Oht86, Rub87).
6 VHDL. Lenguaje estndar de Diseo Electrnico
a ; ]
-c
ss
Zc
.2
,
S a ;
C"~
~ : : : : J
a st
~E
.- (/)
CQ)
a s...!.
o e
IC : : : : J
Q)-
(/)0
Ci - S l
I-- ...- ..... _,.~
, "
Requisitos, restricciones y
especificaciones funcionales
,
,
,
- . . . . . . . . . . . . . . . - . - _ - -- _ . . . -
Captura del diseo (esquemticos) Biblioteca
de celdas
Simulaciones (pre/post-diseo fsico):
Funcional-lgica, temporal, fallos
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 deubi ca ci n y conexi ona do (place&route) decel da s y bl oques uti -
l i za dos dentro del fl ujo dedi seo mostra do en l a Fi gura 1- 2pa ra genera r l a
topogra f a deunci rcui to a pa rti r desuesquema decomponentes y sus cone-
xi ones (netlist) [PL88] .
Asi mi smo ha y procesos deveri fi ca ci n (el ctri ca y geomtri ca ) ocompa ra ci n
deesquema s que estn presentes en a mbos contextos.
Posteri ormente se a bord el ni vel de puerta s (ta mbi n conoci do en l a poca
como ni vel estructura l : componentes y conexi ones) i ntroduci endo l a ca ptura dees-
quema s, l a si mul a ci n funci ona l y de fa l ta s, el a nl i si s de ti empos, l a genera ci n
de estructura s y vectores de test y l os genera dores de bl oques regul a res. La Fi gu-
t. Introduccin 7
Editor Grfico
Esquemas
Mscaras
~~
~~
Esquema (E) Topografa (T)
Extractor de lista de componentes y conexiones (Netlist)
?
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 apartir de medianos de los aos ochenta, donde el nivel funcional estaba
muy poco desarrollado y el mayor esfuerzo dediseo seconcentraba en el nivel ar-
quitectural y depuertas, mientras que el nivel fsico seconsideraba 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 deentornos integrados deCAD 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].
8 VHDL. Lenguaje estndar de Diseo Electrnico
IdU
j
VH,
.
BdD
j
IdUI
1 I~.
H
BdD1
~
IdUk
Hk
BdDk
(a) (b)
IdU
Lenguaje de Interface
~e
~ ~ ~
g.~
c
' C
:::re.
:2 5 l
CIl Cl l
):c
. . . _ .
P 3 3 .
al al
. . .
3CIl
0)-0
_ .ce
al e
CIl . . .
-0._ ::::l III
.'!: .2
_ 0
::.:::
!l l g:
Leng. de acceso y gestin
BdD
Estndares
Informticos
El ectrnicos
Mecnicos
Entorno
CAD;
(e) (d)
H: Herramienta, idU: Interfaz de Usuario, BdD: Base de Datos, I/F: Interfaz
FIGURA 1-4. Evol ucin de l as 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
l a misma base de datos; (e) Entorno integrado, abierto y fl exibl e de CAD: fcil incl u-
sin de nuevas herramientas y mecanismos de gestin de fl ujo de diseo; (d) Entor-
nos y herramientas trabajando con formatos estndar (CIF, EDIF, VHDL, SDF, . . . ) faci-
l itan el intercambio de informacin y l a configuracin de fl ujos de diseo especficos
con l as 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 delos ochenta cedieron suterreno alas estaciones detrabajo (work-sta-
tions) durante la segunda mitad para empezar atrabajar afinales 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, ala vez que
los desarrollos sobre dispositivos programables complejos (FPGAs, CPLDs,
FPLDs) empiezan acrecer 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 anivel funcional o comportamental, cuya implanta-
cindefinitiva seestproduciendo durante esta dcada delos noventa.
Encuanto atecnologas delos aos noventa, laCMOS sigue siendo lams uti-
lizada(75por 100del mercado) incluso creciendo. Las bipolareslECL semantienen
alrededor del 15por 100. Las BICMOS crecen hasta un 5por 100. Las NMOS TTL
decrecen considerablemente, junto con las nuevas tecnologas del tipo AsGa y simi-
lares sereparten el 5por 100restante.
Por otra parte, durante esta dcada se estn desarrollando nuevas tecnologas
deencapsulado cuyo mximo exponente son los mdulos multichip (Multichip Mo-
dules, MCM) [J TB91, 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 delos 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 dedesarrollo pre-industrial son todas las re-
lacionadas con los microsistemas, donde junto a la microelectrnica se integrarn
sensores y actuadores dedistintos 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 decircuitos sesigue con lamisma tnica que al final delos ochen-
ta, con un continuo incremento de lacomplejidad, 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 depotencia [VRM+97].
A nivel deASICs los desarrollosfull y semi-custom hanperdido relevancia frente
alasconsiderables prestaciones ycomplejidades quelosdispositivos programables son
capaces de asumir, deformaque sloproducciones elevadas orequisitos muy espec-
ficos (velocidad, rea, consumo, confidencialidad) hacen necesarios losASIC-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 umy 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 latecnologa. Ahora yaempieza aser posible implan-
tar sistemas completos dentro de un chip de silicio (SOC, systems on chip; SOS,
systems on silicon) y el problema vuelve aser la carencia de mtodos y herramien-
tas para abordar diseos detal complejidad. Los diseos sebasan en macro bloques
funcionales (CPU, DSP, microcontrolador, etc.) desarrollados a nivel soft (cdigo
10 VHDL. Lenguaje estndar de Diseo Electrnico
VHDL sintetizable) uoptimizados anivel hard (layout o topografa especfica), cu-
yo grado dedesarrollo y madurez dista todava del ideal pero en el que seest invir-
tiendo gran esfuerzo.
En cuanto ametodologas dediseo, los aos noventa sehan 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). Setrata deconcentrar el esfuerzo en laconcepcin anivel 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
semuestra 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
deregistros (RT), est en fase dedesarrollo 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 laFigura 1-10
se analizan con un poco ms de detalle estos flujos de diseo descendentes, que
tambin seabordan en el Captulo 6.
Esta misma Figura 1-5trata dereflejar una orientacin descendente (top-down)
y laglobalizacin del flujo dediseo electrnico actual, donde ladependencia dela
implementacin final es prcticamente nula a nivel funcional y se va concretando
en las sucesivas fases de diseo, hasta llegar ala 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
delas distintas tcnicas dediseo asistido por ordenador (CAD) en lo que seha lla-
mado automatizacin del diseo electrnico (Electronic Design Automation, EDA).
Estas tcnicas, pensadas para facilitar laingenieria concurrente', estn enpleno 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) [KAJ W95,
BLR97]. A partir deun mdulo que ayudar arealizar laparticin del sistema ade-
sarrollar en hardware y software, habr flujos EDA y CASE (Computer Aided Soft-
ware Engineering) quepermitirn el desarrollo concurrente deambas partes.
Por suparte, el incremento delos diseos analgicos y mixtos haforzado 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 dedesarrollo (hardware-software) con el marketing y laproduccin.
1. Introduccin 11
~s
ra e
e al
.Q E
ura
C:t::
~g_
.~
Zu
FPLDs
<.
Sistema
electrnico ( peS)
ESpeCifaCiOnes
Descripciones
mixtas multi-nivel
~
Simulacin
Sistemas electrnicos
(mixta multi-nivel)
~
Sntesis a nivel de:
- Comportamiento
- RT-Lgico
- Mapeo tecnolgico
l"",
,
" 1
" Niveles:
,
" - Comportamental
~ - - - : ;, - Arquitectural I RT
" - Lgico I puertas
,
,
,
,
,
~'
~8
ce .
, ,-
-e,;
:::1 Ul
ra
alt::
: t : : < D
0":::1
... o.
,
_o
.~.~
z:Q
!
MCMs
J
FIGURA 1 -5. Esquema de los nuevos flujos de diseo descendente basados en el
modelado, simulacin y sntesis con HDLs anivel 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-
sindel 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 suparte, 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-
12 VHDL. Lenguaje estndar de Diseo Electrnico
tardo deuna puerta (en tecnologas superiores auna micra el 80por 100del retardo
sedebe alas puertas y el 20por 100al 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 100retardo de conexiones. Esto est forzando el desa-
rrollo deprocesos 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 lafuncionalidad y prestaciones re-
queridas para un determinado circuito, o bien que ayude ademostrar lainviabilidad
del mismo.
En cuanto alos entornos de CAD evolucionaron, yaafinales delos ochenta, ha-
ciaentornos integrados pero alavez abiertos y flexibles al incorporar utilidades (In-
tegration kits) para laintegracin denuevas herramientas, as como facilidades (De-
sign jlow management) para ladefinicin, gestin y control del flujo dediseo ase-
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 deinformacin entreentornos (Fi-
gura 1-4.d) en las distintas etapas del diseo (modelos HDL, listas decomponentes 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 questas seajusten alos respectivos estndares (iniciativa CFf).
Para finalizar con esta dcada hablaremos delasplataformas harware-software
sobre las que seha apoyado el desarrollo electrnico. Las estaciones de trabajo or-
ganizadas en forma dered derecursos distribuidos (cmputo, almacenamiento y ac~
ceso) sehan consolidado durante laprimera mitad delos aos noventa. A suvez los
PCs, tambin formando parte de esa misma red informtica, se van abriendo cami-
no y presionando alas estaciones detrabajo, yaseacomo puntos deacceso 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
lageneracin anterior deprocesadores, software y entornos dediseo. Si atodo ello
leaadimos las crecientes posibilidades delos sistemas multimedia y las comunica-
ciones (internet, trabajo en grupo adistancia, etc.) podemos decir que estamos asis-
tiendo auna autntica explosin demedios no siempre fcil deseguir 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 delos propios lenguajes sino las quehacen referencia odependen desuuso.
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 laOFI.
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).
14 VHDL. Lenguaje estndar de Diseo Electrnico
Prog.lDescr. independiente
del H/wque lo ejecuta (HLL)
o lo implementa (HOL)
HLL
Programacin
en Leng.
Alto Nivel
Prog.lDescr. dependiente
del H/wque lo ejecuta (ML)
o lo implementa (HOL)
Programas
a nivel de
Leng. Mquina
(a) Desarrollo de Software
HOL
(b) Desarrollo de Hardware
Descripcin
de alto nivel
de abstraccin
(p.e. RTL)
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 serecurre alos 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 delatecnologa seleccionada. La validacin de las
distintas descripciones serealiza mediante los correspondientes procesos de simula-
cin yanlisis ylas iteraciones decorreccin resultantes (Figura 1-6.b).
Descripcin
de bajo nivel
de abstraccin
(p.e. puertas y cnx.)
1.2.2. Resea histrica de los HDLs
Si bien los HDLs, se han integrado recientemente al proceso de diseo (desde el
inicio delos noventa), este tipo delenguajes seha 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 ymantenimiento adecuados [Har87].
1. Introduccin 15
Arquitectural
RT
Abstractos
Comporta mental
o funcional
ompuestos
Lgico-
puertas
Bit
Estilos
descriptivos
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 alas distintas etapas y niveles de abstraccin del proceso de diseo, sede-
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 J apn.
El VHDL aparece como un proyecto del Departamento de Defensa de EEUU
(1982), con el fin de disponer de una herramienta estndar eindependiente 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
la2: en 1994) [IEEE88, IEEE94].
El Verilog nace como un lenguaje de modelado ligado aun entorno de simula-
cin de lafirma Gateway, pasando posteriormente a ser el simulador digital de Ca-
denee Design Systems Ine., llegando aconvertirse en un estndar "de facto" anivel
industrial. Al aparecer el VHDL como estndar IEEE, Verilog se encontr conun
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].
16 VHDL. Lenguaje estndar de Diseo Electrnico
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 delas nue-
vas metodologas y herramientas dediseo 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 adistintos niveles de abstraccin (funcional o comportamen-
tal, arquitectural o transferencia deregistros, lgico odepuertas) y estilos demode-
lado (algortmico, flujo dedatos, estructural).
Los niveles de abstraccin hacen referencia al grado de detalle en que se en-
cuentra una determinada descripcin HDL respecto ala implementacin fsica dela
misma. Puesto que el nivel ms bajo que trataremos directamente con los HDL se-
rn listas de componentes y conexiones anivel depuertas 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 sefijan todos los detalles para la
implementacin real del circuito), por encima del cual se sita el nivel lgico o de
puertas. As pues, desde laperspectiva de simulacin y sntesis con HDLs, los nive-
les deabstraccin pueden quedar reajustados alos tres siguientes:
Funcional o comportamental, donde seindica el comportamiento del circuito
o sistema como una relacin funcional entre las entradas y salidas, pero sin
hacer ninguna referencia asuimplementacin.
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 arealizar. Todava no seconocen los detalles delarealiza-
cin final decada bloque.
Lgico o de puertas. En este caso los componentes del circuito estn expre-
sados en trminos deecuaciones lgicas opuertas y elementos deuna biblio-
teca, pudiendo ser sta genrica (independientemente de la tecnologa) o es-
pecfica deuna tecnologa.
Como vemos, estos niveles de abstraccin se proponen como una taxonoma
simplificada para poder clasificar los modelos HDL segn el grado dedetalle y pre-
cisin desus 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 serealizarn bajo el sincronismo de los
ciclos de un reloj, pero no se conocen con detalle los componentes que
van arealizar 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 aun 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 debits con un significado especfi-
co y serepresentan como enteros con o sinsigno.
Adems deestos factores determinantes del nivel deabstraccin que sereflejan
en laFigura 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 adescripciones similares alos programas soft-
ware, que deben reflejar lafuncionalidad 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 deinformacin y las dependencias entre datos y operaciones.
Estructural: en este estilo sereflejan directamente componentes por referen-
ciay conexiones entre ellos atravs desus puertos deentrada/salida.
Estos estilos descriptivos forman el tercer eje de laFigura 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 sepuede intuir, normalmente hay una cierta correlacin
entreniveles de abstraccin y estilos descriptivos. As pues, las descripciones algo-
rtmicas seusan ms anivel comportamental o funcional, el flujo de datos serela-
ciona ms con el nivel arquitectural o RT y a nivel de puertas el estilo descriptivo
siemprees detipo estructural.
De todas formas uno de los valores aadidos de estos lenguajes, y en especial
del VHDL, es sucapacidad para hacer convivir deforma 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 anivel depuertas, otros anivel RT en forma deflujo dedatos y algunos todava
enforma dealgoritmos anivel funcional (Figura 1-5). Esta es una situacin normal,
quevaevolucionando alo largo detodo el proceso dediseo hasta que, tras los co-
rrespondientes procesos desntesis manual o automtica, todos los componentes del
circuito aimplementar estn detallados mediante una descripcin estructural anivel
depuertas. Mientras tanto, aquellos componentes que slo formaban parte del en-
torno de simulacin del circuito permanecen descritos al nivel de detalle que sehu-
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
Verilogy el VHDL.
18 VHDL. Lenguaje estndar de Diseo Electrnico
om
~
-~S
Sumador
Total
B~
~:
or
a e
I
A
~
~eout
a
e
(a)
eln"
X=AEDB
~S
B+
S=XEBCin
~eout
A+ Cout=A-B+XCin
ein~~ ~ Sumador Total S
L..- ---l eout
entity sumador_total Is
porteA, B, Cin: in bit;
S, Cout : out bit);
end sumado,._total;
(b)
T
architectura vision_booleana 01
sumador_total ts signal X: bit; begin
X<=Axor Bafter 10 ns;
<S <=Xxor Clnafter 10ns;
::J: Cout <=(Aand B) or (Xand Cin)
~ aftar 20ns;
1end vision_booleana;
T
m?dule sumador_booleano (A, B, Cln, S, Cout);
Input A,B,Cm;
<output S,Cout;
~. wire X;
eS ::::~~ :~g~:: ~~g n;
1
assign #20 Cout =(A&&B) 11(X&&Cln);
endmodule
(e)
I
entfty puerta_or Is
porteA, B: inbit;
S: out bit);
end puerta_or;
archltecture funcional 01puerta_or Is
begin
S <=Aor B;
end funcional;
~
;;1j entity semisumador rs
port ( A, B: in bit;
S, Cout : out bit);
end semisumador;
architecture funcional 01semisumador ts
begin
S <=Axor B;
Cout <=(Aand B);
end funcional;
ein....-----Ib S
Sumador Semi- >--~S
Total sumador
U1
b s -,
Semi- Y a e
sumador Z~
UOX ~g -~eout
a e
B. .
A+
l.!:::::==::! ___J
1
are.hitactura vision-;-estructural of sumador_total Is
slgnal X, Y, Z: brt;
component semisumador
porteA, B : Inbit;
S, Cout : out bit);
end component;
~ co~~(~~~t :Pi~eb~~_or
o:::> S:out bit);
r ' l end component;
begin
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;
T
module sumador_estructura (A, B,Cin, S,Cout);
input A, B,Cin;
~ ~~:~~,~,~~ut;
~ semisumador UO(A, B, X, Y);
<0
1
semisumador U1(Y, Cin, Z, S);
or U2(X, Z, Cout);
endmodule
(d)
FIGURA1-8. Algunos ejemplos sencillos sobre modelos Verilog y VHDL condistin-
tos niveles de abstraccin y estilos de descripcin: (a) Esquema jerrquico de unsu:
mador total de2bits (captura deesquemas clsica). (b) Descripcin deVHDL del inter-
faz E/S del sumador total (ST). EnVHDL para cada mdulo sedefine una entity donde
sedetallan las E/S, mientras que las distintas arquitecturas o descripciones alternati-
vas se detallan endistintos mdulos architecture, que comparten una misma entity.
Enel caso del Verilog, cada mdulo define sus E/S. (e) Modelado del STenHDLanivel
funcional, entrminos de ecuaciones booleanas e incluyendo los retardos previstos.
(d) Una descripcin estructural (componentes y conexiones) del mismo STo(e) Defini-
cinfuncional de los componentes utilizados en(d). Obsrvese que enVerilog el com-
ponente OR, al ser una primitiva del propio lenguaje, no necesita ser definido.
T
module semisumador (A, B, S, Cout);
input A, B;
~ output S.Cout;
=
1
assign S =AA B;
assign Cout =(A&&B);
endmodule
(e)
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 lasimulacin dehardware. Sinembargo, rpidamen-
teseabord suuso como soporte para todas las fases del proceso dediseo, y muy
especialmente para las etapas de sntesis. Pasemos, pues, a comentar las ventajas
msrelevantes que pueden suponer el uso deestos lenguajes:
Estos HDLs son interpretables tanto por las personas como por los ordenado-
res, pudiendo proporcionar soporte tanto alas 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 dedocumentacin y mantenimiento delos diseos.
Son lenguajes dedisponibilidad pblica, no sometidos aninguna firma ni pa-
tente (especialmente el VHDL). Estn definidos, documentados y manteni-
dos por el IEEE, quien garantiza suestabilidad y susoporte.
Soportan descripciones con mltiples niveles de abstraccin, pudindose
mezclar desde mdulos descritos anivel funcional hasta mdulos anivel de
puertas. Con el mismo lenguaje sedescribe el circuito y el entorno de verifi-
cacin (banco depruebas) para susimulacin/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 aningn proceso ni mecanismo estricto
de diseo, pudindose amoldar acualquier metodologa donde el modelado
de hardware pueda tener sentido (especificacin, documentacin, simula-
cin, sntesis y/o verificacin).
En el caso delas 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 lasntesis 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 latecnologa final deimplementacin delos circuitos. La descrip-
20 VHDL. Lenguaje estndar de Diseo Electrnico
cin VHDL deun circuito puede ser totalmente indiferente alatecnologa 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 asus 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 deherramien-
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 desimulacin en ROL sern compatibles).
La reutilizacin del cdigo ROL desarrollado en los proyectos anteriores es
un hecho posible gracias aalgunas delas caractersticas enunciadas anterior-
mente como ser lenguajes estndar, estables y su independencia metodolgi-
ca, tecnolgica y del CAD. Una descripcin VHDL deun diseo, inicialmen-
te desarrollado para una determinada tecnologa (CMOS, BlCMOS, SOl,
etc.) eimplementacin (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 vare-
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
delos mdulos VHDL alas distintas condiciones decontexto delos circuitos
en los que sepueden utilizar estos mdulos.
De todas formas, estas posibilidades de reutilizacin del cdigo ROL sern
ms ciertas y eficientes en lamedida en que los grupos detrabajo ocentros dedise-
o se definan sus propios procedimientos y la normativa bsica para acumular el
know-how resultante delos distintos proyectos deuna 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 5y 6deeste mismo libro.
Como vemos, estos lenguajes pueden aportar ventajas importantes pero no de-
bemos ignorar que tambin estn sujetos aalgunas 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-
danueva 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) eimposi-
bilita abordar claramente laverificacin formal.
7. Introduccin 21
El VHDL, por sus caractersticas sintctico-semnticas, est mejor dotado
para las descripciones anivel funcional/algortmico, mientras que sus presta-
ciones seven ms limitadas al trabajar anivel depuertas. Por su parte el Ve-
ri/og, al basarse en un conjunto de primitivas funcionales bsicas (puertas),
tiene buenas prestaciones anivel estructural/puertas pero claras limitaciones
en los niveles superiores.
Laenorme flexibilidad del VHDL est dificultando laimplantacin demeca-
nismos estndar para facilitar el intercambio de mdulos, reflejar los retar-
dos, la temporizacin (timng) y la retroanotacin (backannotation) en el
modelado debibliotecas 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 aconsolidar algunas extensiones del estandar para dar res-
puesta aalgunos deestos problemas.
Los Captulos 3y 4 deeste libro presentan los detalles y caractersticas espec-
ficasdelasimulacin y sntesis basadas en VHDL.
Actualmente el Verilog y el VHDL estn compitiendo y ala vez compartiendo
algunos de sus mecanismos y estrategias para asegurar su mutua evolucin y su ca-
davez ms cercana compatibilidad y fcil interoperatividad. En cualquier caso es-
tos lenguajes slo son herramientas de base alas que sedebe 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 dediseo electrnico son conceptos muy
interrelacionados y no siempre fciles dedistinguir. La metodologa es un concepto
ms abstracto que hace referencia a procesos de diseo genricos que relacionan
entres los distintos niveles decomplejidad 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 deuncircuito o sistema electrnico.
Por suparte los flujos dediseo son una personalizacin concreta deuna cierta
metodologa, para un tipo de circuitos o rea de aplicacin especfico, y contando
conel soporte deunas determinadas herramientas deCAD. Distintos flujos dedise-
o pueden responder auna misma metodologa y un mismo flujo sepuede implan-
tar con distintas herramientas deCAD.
Los objetivos fundamentales que persigue toda metodologa de diseo sepue-
denresumir en:
3 VITAL (VHDL lnitiative Towards ASIC Libraries modeling). Esta iniciativa promueve laestan-
darizacin de los mecanismos para representar y gestionar los parmetros temporales (retardos depuer-
tay retroanotacin deretardos del conexionado) en el modelado VHDL de las bibliotecas deceldas pa-
rael diseo deASICs.
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.
22 VHDL. Lenguaje estndar de Diseo Electrnico
Establecer procesos de diseo que permitan reducir costes, tiempo y riesgos
de desarrollo, ala 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 deuncircuito.
Estos dos objetivos se desdoblan en mltiples requisitos y caractersticas para
los distintos flujos y herramientas dediseo, que no entraremos aanalizar. Sin em-
bargo, para alcanzar estos objetivos, en cada etapa de diseo o nivel derepresenta-
cin deun circuito sedeben aplicar los principios de:
Abstraccin: fijar y definir el nivel deabstraccin decada etapa permite, tan-
to al diseador de circuitos como al desarrollador de CAD, ignorar en cada
momento detalles ajenos al nivel en el que seest trabajando.
J erarqua y estructuracin: permite reducir la complejidad del diseo me-
diante ladescomposicin jerrquica del mismo hasta alcanzar bloques o m-
dulos del nivel deabstraccin 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 atravs deellas utilizando procesos manuales o automticos de:
Sntesis: para pasar las descripciones deun determinado nivel de abstraccin
aotras denivel inferior con un mayor grado dedetalle (p. ej., deuna descrip-
cin RT apuertas, odepuertas amscaras).
Anlisis: extraer informacin de una descripcin (p. ej., retardos del cone-
xionado) para facilitar una verificacin de prestaciones o inyectarla a una
descripcin denivel superior para validar restricciones.
Verificacin/simulacin: para validar tanto lacorreccin delas 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 deabstraccin.
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 laidea alaimplementacin, pasando por distintas eta-
pas o niveles de abstraccin. Sin embargo, los flujos reales de diseo se han visto
mucho ms sujetos al estado delas herramientas dediseo que ha seguido una evo-
lucin ascendente (bottom-up) para ir cubriendo progresivamente las etapas de
mayor nivel decomplejidad desde el nivel fsico al nivel funcional (ver Figuras 1-1,
1-2,1-3, 1-9Y 1-10).
Debido aestas limitaciones del CAD durante el proceso evolutivo de los aos
ochenta, lametodologa y los flujos dediseo 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 yasehaban tomado todas las decisiones arquitecturales einclu-
1. Introduccin 23
so tecnolgicas, se poda proceder a una validacin-simulacin completa del mis-
mo) y consecuencias obvias anivel decostes, tiempo y riesgo dedesarrollo. 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 dexito.
Sin embargo, la evolucin de las tecnologas de semiconductores sigue yendo
por delante delas tcnicas dediseo. Yaempiezan aser factibles chips detal com-
plejidad que permitan laintegracin desistemas completos (Systems on Chip, SoC),
para lo cual sern necesarias metodologas mixtas descendentes-ascendentes donde
ciertas partes del diseo, las ms operativas, sebasen en lacomposicin ascendente
demdulos preexistentes, mientras que para disear las funciones decontrolo par-
tesms especficas seseguirn procesos descendentes.
En los prximos apartados tratamos de resumir las ideas bsicas sobre estas
metodologas y flujos dediseo.
1.3.1. Flujo de diseo ascendente (bottom-up)
En el proceso de diseo deASICs implantado amediados de los ochenta sepodan
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 aun nivel funcio-
nal, su diseo lgico fuera abordable desde la tecnologa escogida y segn
subiblioteca deceldas especfica.
2. En la segunda fase serealiza una composicin jerrquica ascendente (apro-
ximacin bottom-up) de celdas, mdulos y bloques hasta conformar la es-
tructura jerrquica establecida en lafase 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 setomaban eran crticas (particin, arquitecturas, bloques) y
conimportantes consecuencias para el posterior desarrollo y prestaciones del circui-
to, no se contaba con ningn soporte deherramientas 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, apesar de contar con el soporte de flujos y herramientas
dediseo, era muy laboriosa y concentraba lamayor parte delos esfuerzos dedise-
o, dando as el nombre de ascendente (bottom-up) alametodologa y flujos dedi-
seo utilizados.
La Figura 1-2muestra un esquema genrico deestos flujos ascendentes, donde
seencadenan etapas de captura de esquemas, para detallar el esquema lgico deun
mdulo en base alos previamente descritos y/a labiblioteca deceldas especfica de
latecnologa seleccionada, y simulacin (lgica, temporal, fallos) para validar cada
nuevo mdulo. Este proceso captura-simulacin se repeta hasta completar toda la
24 VHDL. Lenguaje estndar de Diseo Electrnico
Conjunto de bloques
y mdulos bsicos
(dese, estructural)
Conjunto de bloques
y mdulos bsicos f---_I
(dese. funcional)
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 alos 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 lavista 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 sebasaban en laexperiencia del diseador, sin contar con ningn sopor-
temetodolgico ni mecanismo alguno para hacer evaluaciones previas.
La biblioteca de celdas y, por lo tanto, la tecnologa de fabricacin se selec-
cionaban antes deiniciarse el proceso dediseo 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 lapre-
cariedad con laque serealizaba lafase deanlisis y descomposicin jerrquica des-
cendente inicial, sedetectaban en estadios muy tardos del proceso dediseo. 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 aprocesos 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, uncierto tiempo despus definalizado el mismo.
En resumen, esta metod~oga facilitaba tanto lapropagacin deproblemas des-
delas fases iniciales hasta 1 fases avanzadas del diseo (cuanto ms tiempo setar-
da en detectar un problem ms difcil y costosa en su resolucin, tanto por el es-
fuerzo acumulado como po lapropia dificultad delasolucin), como lacreacin de
estructuras innecesariamente omplejas o poco recomendables que podan dificultar
talmente la evolucin y mantenimiento del diseo, que este esfuerzo fuese inviable
y serequiriera un rediseo completo. Todo ello tiene mltiples facetas y todas ellas
acaban suponiendo unincremento delos costes dedesarrollo del producto final.
1.3.2. Flujo de diseo descendente (top-down)
Laidea bsica del diseo descendente frente al ascendente es aportar metodologa y
CAD para dar soporte alaparte izquierda del flujo mostrado en laFigura 1-9.
Las tcnicas de diseo descendente apuestan por la formalizacin y normaliza-
cin delas tareas dediseo desde las primeras etapas deconcepcin (especificacio-
nes descritas en VHDL y, por lo tanto, simulables) y secentran en promover el dise-
o anivel comportamental, facilitando laevaluacin de soluciones alternativas des-
deese mismo nivel, dando lugar al llamado "diseo dealto nivel" [MLD92].
El objetivo es facilitar las tareas dediseo dealto nivel que van desde las espe-
cificaciones hasta ladescripcin anivel detransferencia deregistros, delaarquitec-
tura escogida, cuya sntesis permita obtener una descripcin a nivel lgico o de
puertas. A partir deeste punto las listas decomponentes y conexiones que seobtie-
nen ya pueden entrar alos procesos habituales de diseo fsico (ubicacin y cone-
xionado, verificacin, extraccin yretroanotacin deparsitos y retardos).
Aplicando el principio deabstraccin antes mencionado, setrata tambin dein-
dependizar el diseo anivel funcional respecto del arquitectural-RT, y ste en rela-
26 VHDL. Lenguaje estndar de Diseo Electrnico
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 seestabilice la sntesis comportamental, ahora anivel prein-
dustrial, sern ms independientes entre s el diseo de nivel funcional y el arqui-
tectural- RT.
Las caractersticas y ventajas delos HOL en general (ver punto 1.2.4), y en es-
pecial de VHDL, estn facilitando y potenciando el desarrollo eimplantacin delas
metodologas de diseo descendente que sebasan 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 deanlisis-verificacin.
La Figura 1-10muestra deforma 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 sedesea implementar en forma de sistema o cir-
cuito electrnico se ha de proceder auna primera fase de definicin de especifica-
ciones. Hasta ahora esta ha sido laetapa menos formalizada y ala que no sepresta
la atencin que requiere, apesar 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 deconcepcin anivel funcional, incluyendo laparte dedescripcin/simu-
lacin delas especificaciones [CP96].
En principio las especificaciones de un diseo no tan slo han deincluir infor-
macin sobre el propio circuito, sino tambin del entorno operativo donde ste esta-
rubicado. A partir deesta informacin el proceso dedescripcin HOL delas espe-
cificaciones hadedar lugar ados 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 detipo algortmico.
El modelo HDL del entorno del circuito para validarlo en sucontexto (banco
depruebas, test-bench). Este modelo tiene opuede tener mltiples funciones:
- reproducir el entorno deutilizacin del circuito,
- facilitar lageneracin deestmulos hacia el circuito y larecogida deresul-
tados desde el mismo para poder analizar sucomportamiento y
- comparacin deresultados respecto aun modelo dereferencia,
todas ellas dirigidas afacilitar la comprobacin del correcto funcionamiento
del circuito bajo test, vaprocesos desimulacin y anlisis deresultados.
Con estos dos modelos yasepodrn hacer simulaciones funcionales que permi-
tan depurar las especificaciones y comenzar aevaluar distintas alternativas departi-
cin del sistema.
1. Introduccin 27
: a
1: :
Q)
::;,
a..
.!!!
6
el
o o
'c;, "O
: 9
c:
o
s
a l
Q)
o
"O
'c;,
s
-o c:
"O
Q)
c: '5
o c:
s
o
Q)
a.
c: o Q)
'0
: ~
o
.~
u..
E
.s2
.5
Refina miento gra dua l en HDL
Sntesis del comporta miento
,
,
,
,
I
I
I
I
,
I
___ 01 _
I
I
I
I
I
I
I
I
I
I
I
" ' I f <, !
" I
"
.
I
~
Q)
E
~
8.
E
~
c:
o
'0
c:
::;,
u..
.!!!
g>
"O
e
o
$
Q)
"O
~
Q)
'5
e
Q)
a.
Q)
"O
.5
~
Q)
: : ;,
5. Circuito
~ y
8 Mdulos
c:
~
FIGURA 1-10. E squema genrico de la s metodologa s y flujos de diseo descen-
dentes (too-aown).
Una vez fijadaslasespecificaciones, a travsdel depuradodeestosmodelos, se
inicia el procesoderefinamiento gradual dela descripcin del circuitohasta alcan-
zar un modeloarquitectural-RT quesea sintetizablemedianteprocesos automticos
guiadospor el diseador. Esterefinamiento tambin puedeafectar el bancodeprue-
basoentornodetest, nopara hacerlosintetizable, sinoa fin deajustar su precisin
28 VHDL. Lenguaje estndar de Diseo Electrnico
aladel modelo del circuito. Un entorno detest cuya temporizacin sebase slo en
relaciones causales, puede que no sea adecuado para un modelo del circuito que ya
seexpresa en trminos deciclos dereloj.
Esta primera fase de refinamiento gradual para pasar de una descripcin fun-
cional auna de nivel RT est ahora en vas de automatizacin y selaconoce como
sntesis comportamental.
A continuacin viene la etapa de sntesis RT-lgica que tiene por objeto laob-
tencin de un esquema o lista decomponentes 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 arequerir
varias iteraciones de los procesos automticos de sntesis para latestabilidad dirigi-
dapor prestaciones y guiada por el diseador.
Estas herramientas de sntesis RT-lgica automticas seimplementan mediante
distintos procesos de sntesis encadenados de forma transparente al usuario. Estos
procesos son:
1. Sntesis RT que determina los elementos dememoria y el conjunto deecua-
ciones lgicas u operadores necesarios, en base afases 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 anivel depuertas y registros utilizando algo-
ritmos de reduccin y asignacin de estados, minimizacin lgica, elimina-
cin deredundancias, etc.
3. Mapeo tecnolgico que es una fase, muchas veces indistinguible dela snte-
sis lgica, en la que las puertas y registros se mapean de forma optimizada
sobre los elementos disponibles en labiblioteca deceldas y mdulos corres-
pondientes alatecnologa escogida para laimplementacin fsica del diseo.
A lo largo de estas fases seha de incorporar al diseo las estrategias y el hard-
ware necesario para asegurar laposterior testabilidad del circuito. Estos son proce-
sos semiautomticos, o al menos muy asistidos por el diseador, que adems de
definir laestrategia detest 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 aobtener un conjunto reducido
y ptimo detales vectores con una buena cobertura defallos (>96 %) del circuito.
Dado el estado actual de las herramientas de diseo electrnico, despus de la
sntesis RT-lgica siempre hay unas ciertas tareas anivel de puertas, que se agluti-
nan bajo el nombre de diseo detallado: simulacin funcional, temporal y defaltas,
anlisis de resultados y optimizacin de caminos crticos, estructuras y vectores de
test. Un objetivo aperseguir es que las posibles modificaciones resultantes de esta
actividad sereflejen desde los modelos HDL-RT sintetizables para mantener la co-
herencia entre los distintos niveles dedescripcin del diseo; aunque ello exija nue-
vas iteraciones desntesis.
Despus de esta sntesis RT-lgicay el diseo detallado seobtienen los dos ele-
mentos bsicos para poder abordar las fases o etapas dediseo fsico: lalistadecom-
1. Introduccin 29
ponentes y conexiones, las restricciones a cumplir y el conjunto de vectores de test.
Conestas descripciones yapodemos iniciar los procesos deubicacin y conexionado
paragenerar latopografa y descripciones necesarias paralaimplementacin fsicadel
circuito siguiendo el mismo tipo de mecanismos y flujos (extraccin, retroanotacin,
simulacinpost-layout, etc.) enunciados enlafaseback-end del diseo ascendente.
1.3.2.2. Informacin ascendente
En este proceso de refinamiento gradual descendente hay unos flujos de informa-
cinascendentes que provienen odependen delas etapas posteriores dediseo y, en
definitiva, de la tecnologa final de implementacin de cada circuito. Tal como se
muestra en laFigura 1-10, podemos distinguir dos tipos deinformacin ascendente:
informacin tecnolgica propiamente dicha (parmetros geomtricos, elctri-
cos, retardos, celdas, etc.), que proviene delatecnologa escogida, e
informacin que, atravs de un proceso de retroanotacin, proviene de una
descripcin denivel inferior deabstraccin.
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, atravs de ellos, sobre las descripciones resultantes. Ac-
tualmente esta informacin tecnolgica empieza aintervenir en las etapas de snte-
sislgica y mapeado tecnolgico incrementando suincidencia 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 deesta informacin, las descripciones resultantes son ca-
davez ms dependientes dela tecnologa y de los procesos de sntesis, que son los
quehacen unuso ms omenos inteligente delainformacin 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 auna cierta descripcin. Tiene una incidencia
ms bien esttica sobre el diseo al no afectar directamente alos procesos decons-
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 laretroanota-
cin sepueda realizar despus de una etapa de sntesis RT o comportamental, pues
entonces, adems .deextraer y transportar la informacin, habr que abstraerla afin
deanotarla correcta einteligentemente sobre las descripciones previas alasntesis.
30 VHDL. Lenguaje estndar de Diseo Electrnico
Otro aspecto aconsiderar es que no todos los lenguajes HDL tienen estructuras
ni esquemas estndar para facilitar la retroanotacin de retardos desde el diseo
fsico hasta lanetlist 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 seestn
llevando acabo distintos proyectos, delos que VITAL puede que seael ms signifi-
cativo por el nmero deproveedores deCAD y fabricantes de silicio que ledan so-
porte. La idea deVITAL [VITAL94] es adaptar para el VHDL un esquema detem-
porizacin y retroanotacin, tambin basado en el SDF y, por lo tanto, altamente
compatible con el utilizado en el contexto del Verilog. Estos procesos deestandari-
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
enbase al uso deprimitivas y estructuras predeterminadas).
Finalmente, y para resumir, vemos (Figura 1-10) que la incidencia deestos flu-
jos deinformacin ascendentes, en las distintas etapas del diseo, marcan un poco el
grado dedependencia tecnolgica delas mismas y delasdescripciones 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 aunmismo comportamiento, obien,
qu dos arquitecturas distintas realizan lamisma 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 unbuen complemento ala simula-
cin, no las consideraremos deforma explcita en este texto.
Como podemos ver en laFigura 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 depruebas y bajo un nico entorno de
simulacin basado en los HDLs que seestn utilizando.
Bajo el concepto de banco de pruebas (test-bench) tratamos de aglutinar los
distintos tipos de pruebas o validaciones funcionales arealizar sobre un circuito, y
que podemos agrupar en:
Pruebas globales que tratan devalidar lacobertura del documento deespeci-
ficaciones por parte del modelo HDL del circuito.
Pruebas anivel de sistema para reflejar y validar alguno delos 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 anivel decircuito para validar partes concretas del dise-
o incluyendo varios mdulos interconectados y/o distintos modos deopera-
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 oparte) estructural del dispositivo una vez fabricado.
Estos distintos bloques de pruebas que antes (metodologas ascendentes) o no
sedesarrollaban o exigan distintos lenguajes y simuladores, ahora se pueden des-
cribir con el mismo HDL con el que seest haciendo el diseo del circuito.
Sea cual sea el tipo de banco de pruebas, stos acostumbran atener, dentro de
unequipo o centro dediseo, 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 dereferencia que proporciona los resultados previstos y esperados.
Modelo HDL avalidar del circuito enfase dediseo.
Mdulo de adquisicin, adecuacin y comparacin de los resultados obteni-
dos del modelo bajo test, respecto alos esperados proporcionados por el mo-
delo dereferencia.
Mdulo para la generacin de vectores completos (estmulos +respuestas)
para suexportacin aotros formatos y entornos dediseo.
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, sedes-
criben utilizando el mismo HDL.
Sobre bancos de pruebas hay una presentacin genrica de tipo terico en el
Captulo 3, que secomplementa en los Captulos 5 y 6 mediante exposiciones ms
prcticas y explcitas ycon los correspondientes ejemplos deapoyo.
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] J EAN MICHEL BERG, Oz LEVIA & J ACQUESROUILLARO: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.
32 VHDL. Lenguaje estndar de Diseo Electrnico
[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] CARLOSDELGADOKLOOS y EDUARDCERNY (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. GAJ SKI (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. GLASSERy 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] J OHNP. 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] J OHN 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 J anuary 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.
[J SV82] PAUL G. J ESPERS,CARLOH. SEQUINy FERNANDVAN DE WIELE: Design Methodolo-
gies for VLSI Circuits. NATO ASI Series, Sijthoff & Noordhoff Int. Pub. 1982.
[J TB91] R. W. J OHNSON,ROBERTK.F. TENG & J OHNW. BLADE (editors), Multichip Modules:
Systems Advantages, Major Constructions, and Materials Technologies. IEEE Press, 1991.
[KAJ W95] S. KUMAR; J . M. AYLOR; B. B. J OHNSONy 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] J EAN 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] BRYANPREASy 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] FRANZJ . RAMMINGY RON WAXMAN(editors): Electronic Design Automation Fra-
meworks. IFIP WG 10.2. North-Holland, 1991.
[Ser94] FRANCESCSERRA 1MESTRES: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] PETERA. 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. J ohn Wiley & Sons, 1994.
[Ter86] Luns TERS: Generadores automticos de mdulos para circuitos VLS!. Tesis Doc-
toral, Univ. Autnoma de Barcelona, 1986.
[TM91] DONALDE. THOMASy 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] J OHN 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] ALFREDZEHE (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. 7
th
European Conference on Power Electronics and Applications,
Brussels, 1997.
Captulo 2
PRESENTACION
DEL LENGUAJE VHDL
Manel Mor, J oan Vidal, Eduard Lecha, Fernando Rincn y Llus Ters
IMB-CNM (CSIC)
Universitat Autnoma deBarcelona
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 VHOLpue-
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
36 VHDL. Lenguaje estndar de Diseo Electrnico
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 apesar 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 aconocer 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 dedescripcin dehardware
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 dedefinir nuevos
tipos, desde tipos discretos o escalares hasta matrices o registros eincluso 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 delos lenguajes deprogramacin lapotencia decontrol deflu-
jo, incorporando los dos tipos decontrol deflujo tpicos: control decondiciones (if,
case) e iteraciones (jor, while). Estas estructuras de control de flujo, junto con la
capacidad dedefinicin detipos dedatos enunciada en el prrafo anterior, hacen de
VHDL un lenguaje potente para desarrollar algoritmos, que pueden no tener rela-
cin directa con ladescripcin dehardware.
Incorpora tambin lacapacidad deestructuracin 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 dealgoritmos complejos.
La ltima caracterstica claramente heredada de los lenguajes deprogramacin
de alto nivel es laposibilidad de desarrollar y utilizar bibliotecas de diseo, de for-
ma que al abordar el desarrollo decualquier cdigo VHDL dispongamos deun con-
junto detipos dedatos, operadores y funciones ya definidos, indicados para el rea
concreta enlaque vayamos atrabajar.
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 seenfrente con el aprendizaje deeste lenguaje.
2. Presentacin del lenguaje VHDL 37
2.2. UN MODELO DEL HARDWARE
Tres son las caractersticas principales que incorpora VHDL enfocadas afacilitar o
permitir ladescripcin dehardware: un modelo deestructura, un modelo deconcu-
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
ladescripcin desistemas electrnicos acualquier nivel deabstraccin.
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 depuertas, que seran las primitivas del diseo digi-
tal). Por ello VHDL incorpora el concepto deestructura. 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 laconexin entre stas. Cada una
delas partes, a su vez, pueden estar modeladas de forma estructural a partir de sus
componentes, o bien estar descritts deforma funcional, usando los recursos dedes-
cripcin algortmica del lenguaj~. Siempre en el ltimo nivel dejerarqua nos en-
contraremos con modelos funcionales, apartir 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: lainterfaz 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 oaccesibles desde el
exterior, lo que sellama los puertos (ports) del dispositivo. En laarquitectura sede-
finir la funcionalidad que implementa dicho dispositivo, o sea, qu transformacio-
nes serealizarn sobre los datos que entren en los puertos deentrada, para producir
nuevos valores sobre los puertos desalida.
Para poder utilizar elementos yadefinidos enVHDL (por el mismo diseador o
disponibles en bibliotecas dediseo) en descripciones estructurales deun 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 autilizar y conectar los puertos desuinterfaz alos puntos necesarios para
realizar el nuevo diseo. La Figura 2-1 ilustra esta idea, el sistema bajo desarrollo
seforma apartir dedos subsistemas que sehabrn definido con anterioridad. El di-
seador slo debe preocuparse delas entradas y salidas delos 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 delos 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 seindica en el grfico. Cada vez que vare el valor de
38 VHDL. Lenguaje estndar de Diseo Electrnico
U1: AN02 (a, b, e);
U2: OR2 (e, d, e);
a
b ANO
r 1_
e
d
OR
FIGURA 2-1. Modelo de estructura en VHOL.
alguno de los puer tos de entr ada de una de las puer tas, sta ejecutar su funcin,
pudiendo var iar el valor desu puer to desalida. Obsr vese que si lapuer ta and pr o-
duce un cambio sobr e su puer to desalida e, ste implicar que lapuer ta or ejecute
su funcin, pudiendo asu vez for zar un cambio en su puer to desalida e. Este com-
por tamiento es el mismo queseobser va enel hardware r eal.
Este mecanismo que incor por a VHDL es anlogo al mecanismo de diseo
clsico utilizado en la captur a de esquemticos. Cualquier modelo VHDL puede
abor dar el diseo deun nuevo componente, desde unaapr oximacin pur amente es-
tr uctur al, r efer enciando los componentes quelo for man y estableciendo las inter co-
nexiones entr e ellos. Los componentes pueden ser tan simples como las puer tas l-
gicas del ejemplo, obien tan complejos como un sistema electr nico completo.
Obsr vese queestemecanismo bsico del VHDL demodelado delaestr uctur a
(lacopiaor efer encia acomponente) ofr ece asuvez lafor madeespecificar lajer ar -
quadeundiseo.
2.2.2. Modelo de concurrencia: procesos, seales
y eventos
El hardware es por definicin concur r ente, en ltima instancia cualquier dispositivo
digital est for mado deun mar depuer tas lgicas, todas ellas funcionando en par a-
lelo. El elemento bsico que ofr ece VHDL par a modelar par alelismo es el pr oceso
(process).
Un pr oceso puede entender se como un pr ogr ama, se compone de sentencias,
puede llamar asubpr ogr amas, puede definir datos locales, etc. En gener al, un pr o-
ceso descr ibe compor tamiento (usando las capacidades dedescr ipcin funcional de
VHDL) y el cdigo quecontiene seejecuta defor ma secuencial. Per o todos los pr o-
cesos contenidos en unadescr ipcin VHDL seejecutar n defor ma par alela. Desde
estepunto devista un modelo VHDL puede entender se como un mar depr ogr amas
2. Presentacin del lenguaje VHDL 39
secuenciales ejecutndose de forma paralela. De hecho, cualquier descripcin
VHDL (independientemente delas construcciones del lenguaje que utilice) es trans-
formada en un conjunto de procesos concurrentes equivalentes, y este mar de pro-
cesosconcurrentes es lainformacin deentrada 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 alas que es sensible. Ser
sensible auna seal significa que en cuanto se produzca un cambio en el valor de
dichaseal (un evento en la seal), el proceso seejecutar 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 seproduzca un nuevo evento en alguna de las seales alas que sea
sensibledicho proceso. Aparte de poder suspender laejecucin deun proceso (sen-
tenciawait), ste es un bucle infinito, o sea, al llegar a su final vuelve aejecutarse
desdeel principio.
Para ilustrar mejor este concepto, la Figura 2-2 define los procesos equivalen-
tesaunapuerta and y una puerta or dedos entradas cada una.
El primer proceso (and2) seejecuta cada vez que seproduce un cambio (even-
to) enel valor dela seal a o dela seal b. Cuando seproduzca el cambio seejecu-
tael proceso y, por tanto, asigna asu salida eel valor de la expresin lgica aand
b. A continuacin el proceso se suspende, hasta que se produzca un nuevo evento
sobrea o b. De hecho sta es la forma como trabaja una puerta lgica real, sola-
mentepuede cambiar el valor que asigna asu salida, cuando seproduce un cambio
enalgunadesus entradas.
El proceso OR2 funciona de la misma forma. Solamente notar que en este
ejemplo seutiliza la seal epara sincronizar los dos procesos, siempre que se pro-
duzcaunevento en laseal e, seejecutar el proceso OR2.
Por supuesto, y dado el paralelismo en la ejecucin de los procesos, si en un
momento de la simulacin seproducen 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<=eor d;
wait on e, d;
end process OR2;
FIGURA 2-2. Modelado de concurrencia en VHDL.
40 VHDL. Lenguaje estndar de Diseo Electrnico
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
Ejecutar procesos Actualizar seales
Final simulacin
FIGURA 2-3. Ciclo de simulacin VHDL.
sesuspenden (con la ejecucin de una sentencia wait). Esta etapa finaliza cuando
todoslos procesos que sehaban activado sehayan suspendido. Entonces el tiempo
desimulacin avanza hasta el siguiente instante detiempo en el que haya un evento
programado, y serepiten los dos pasos del ciclo de simulacin. La simulacin ter-
minacuando no haya ms eventos programados o cuando sellegue al tiempo de si-
mulacinespecificado.
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
queunproceso coloca un nuevo valor en lacola deeventos deuna seal (el proceso
ejecutala 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
retardoconcreto, seutilizar un retardo delta (delta delay). Un retardo delta no im-
plicaactualizar el tiempo de simulacin, pero s que implica ejecutar un nuevo ciclo
desimulacin.
El concepto deretardo delta es importante para entender otra diferencia impor-
tanteentrevariable y seal. Una variable actualiza su contenido en cuanto seejecu-
ta una asignacin sobre ella. En cambio, cuando se ejecuta una asignacin sobre
unaseal, seproyecta un nuevo evento sobre su cola de eventos y slo cuando to-
dos los procesos sehayan ejecutado y estn suspendidos, el valor de la seal seac-
tualizarcon el valor proyectado en sucola deeventos.
Este mecanismo del retardo delta se introduce para permitir la simulacin de
hardware (paralelo por naturaleza) usando mquinas secuenciales, y es el que per-
miteasegurar el determinismo de la ejecucin del cdigo VHDL. Consideremos el
cdigoVHDL delaFigura 2-4, en el aparecen dos elementos secuenciales conecta-
dosenforma deregistro dedesplazamiento.
El mecanismo del retardo delta permite que, independientemente del orden en
queseejecuten los dos procesos, el segundo (FF2) siempre reciba el valor correcto
deQ1, ya que aunque sehaya ejecutado con anterioridad el primer proceso (FF 1),
42 VHDL. Lenguaje estndar de Diseo Electrnico
FFl : process
begin
ir CK=' l' then
Ql <=DI
end ir;
waiton Clk;
end process FFl~
FF2 : process
begin
ir CK=' l' then
Q2 <=Ql
end ir;
wait on Clk;
end process FF2;
D1 01
r--
FF1
CK
>
02
..._
FF2
CK
>
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 deDI (an sin actualizar). Slo en el momento en que ambos procesos se
hayan suspendido, seactualizarn las seales con los valores que contengan sus co-
las deeventos.
Para clarificar el funcionamiento del ciclo de simulacin y del retardo delta, en
la Figura 2-5 semuestra cmo secomportara 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 sehadefinido como un reloj de IOnsdeperiodo y que laseal
deentrada DI toma los valores reflejados en lafigura. Tomando CK y DI como es-
tmulos semuestra 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 deQI y Q2.
Obsrvese que si las seales tomasen sus nuevos valores en el instante en que
serealiza laasignacin sobre ellas, laejecucin del ejemplo anterior dara como re-
sultado valores distintos sobre las seales QI y Q2, dependiendo del orden en que
seejecutasen los procesos FFI y FF2.
2. Presentacin del lenguaje VHDL 43
Estmulos a la simulacin
CK
le

J
.
, .

D1
,

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 _ _ J QL _ _ _
10 ns - - - - - - - - - - - - - - - - - - - -
--- . . . . . . _ - - - - - - - _ .
Ejecutar procesos
1 O
10 ns +o ns
Actualizar seales 1 O
- - - - - - - - - - - - - - - - - - - - ------ . . . - - - - - - - - - -
-_ . . ----- . . . _ - - _ . . . . . .
Ejecutar procesos
- -
20 ns
Actualizar seales
(1) (01
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - . . . . . . . . . . .
Ejecutar procesos
1 1
20 ns +o ns
Actualizar seales
1 1
- - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - _ . . _ - - - - - - - - -
Ejecutar procesos
- -
(*) valor anterior que ya contena la seal.
FIGURA 2-5. Ciclo de simulacin y retardo delta.
2.3. UNIDADES BSICAS DE DISEO
Unaunidad dediseo es una construccin VHDL quepuedeser analizada indepen-
dientemente; en estemomento sepuedeconsiderar queel anlisis deuna unidad de
diseo es anlogo alacompilacin deun programa, ms adelante, en el Captulo 3,
sedescribir con detalleel proceso deanlisis. Existen cinco tipos diferentes de
unidadesdediseo: ladeclaracin deentidad (entity declaration), laarquitectura de
unaentidad (architecture J , la configuracin (configuration J , la declaracin depa-
quete(package declaration) y el cuerpo del paquete(package body). Ladeclaracin
44 VHDL. Lenguaje estndar de Diseo Electrnico
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 autilizar 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:
e n t i t y i d e n t i f i c a d o r i B
[ g e n r i c o s )
[ p u e r t o s )
[ d e c l a r a c i o n e s 1
[ b e g i n s e n t e n c i a s )
end [ e n t i t y ) [ i d e n t i f i c a d o r ) ;
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:
e n t i t y i d e n t i f i c a d o r i B
end;
2. Presentacin del lenguaje VHDL 45
Estaentidad no tiene ninguna comunicacin con el exterior, por lo que no pue-
deser reutilizada en ningn otro diseo. No obstante, entidades deeste tipo pueden
utilizarseparadescribir sistemas completos (ver Captulo 5).
Deentre las partes opcionales deladeclaracin deuna entidad cabe destacar la
declaracin de los puertos, que determinan la interfaz del dispositivo con el exte-
rior. Paracomprender qu son los puertos de una entidad sepuede hacer una com-
paracin entre stos y las patillas de un circuito. Para cada puerto setendr que in-
dicar el nombre, el tipo y el modo. El nombre seutilizar para poder referenciarlo,
el tipodefinir laclase deinformacin que setransmitir 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-
menteunmultiplexor dedos bits sera:
entity Mux21 is
port ( a inbit;
b inbit;
ctrl inbit;
z out bit);
endr
En la Figura 2-6 se muestra el diagrama equivalente. Como puede apreciarse
sloseindica cmo debe comunicarse el dispositivo con su entorno sin dar ningn
detalledesuimplementacin. En otras palabras, ladeclaracin decualquier entidad
quetenga tres entradas y una salida de tipo bit, sea cual sea su funcionalidad, ser
idnticaa la declaracin de este multiplexor, cambiando seguramente los nombres
delaentidad y delos puertos.
Adems de los puertos, en la declaracin de una entidad se ha visto que hay
otraspartes opcionales, concretamente genricos, declaraciones y sentencias.
Los genricos sonun conjunto deparmetros que permiten modificar lafuncio-
nalidadal referenciar la entidad, de esta forma seconsiguen descripciones ms ge-
nerales. Por ejemplo, al describir un dispositivo que seaun sumador dedos valores
enteros, se pueden introducir como genricos el nmero de bits de los operandos.
Deesta 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
. [
l b.
b bit
z
ctrl bit
FIGURA 2-6. Diagrama de l a interfaz del mul tipl exor de dos bits.
46 VHDL. Lenguaje estndar de Diseo Electrnico
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 ladeclara-
cin deuna entidad, yaque en principio tienen poco que ver con lainterfaz del dis-
positivo y mucho con su implementacin, por lo que es ms natural incluirlas den-
tro de su arquitectura. No obstante, debido aque para una entidad pueden definirse
muchas arquitecturas distintas, aveces se declaran objetos comunes atodas las ar-
quitecturas para no tener que declararlos en cada arquitectura. Por lo que alas sen-
tencias se refiere, pueden incluirse siempre que sean pasivas en el sentido que no
afecten alafuncionalidad del dispositivo. Son tpicas las sentencias que hacen com-
probaciones sobre las entradas para detectar, por ejemplo, configuraciones prohibi-
das o violaciones detiempos.
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 ladeclaracin de laentidad, de modo que cuando sta
semodifique laarquitectura tendr que ser reanalizada.
La sintaxis VHDL para definir laarquitectura deuna entidad es lasiguiente:
architecture identificador of identificador_entidad i 8
[declaraciones]
begi n
[sentencias concurrentes]
end [architecture] [identificador];
El identificador es el nombre que vaarecibir laarquitectura 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-
bredelaentidad alaquepertenece. Lazona destinada adeclaraciones sirveparade-
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 adescribirlas. Dependiendo del tipo de senten-
cias utilizadas sepuede modelar una arquitectura siguiendo diferentes estilos:
Estilo algortmico: define la funcionalidad del componente mediante un al-
goritmo compuesto por un conjunto deinstrucciones que seejecutan secuen-
cialmente.
Estilo flujo dedatos: modela laarquitectura como un flujo dedatos entre dis-
tintos mdulos encargados de.implementar funciones uoperadores.
Estilo estructural: define la arquitectura como un conjunto de componentes
interconectados.
2. Presentacin del lenguaje VHDL 47
En las siguientes secciones de este subapartado se discuten las principales ca-
ractersticas deestos estilos dedescripcin.
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-
gramaescrito en un lenguaje de programacin comn, como puede ser eo Pascal.
Por tanto, no se hace ninguna referencia ala estructura que se seguir para imple-
mentar el algoritmo en hardware.
La arquitectura del multiplexor de dos bits declarado anteriormente utilizando
unestilo demodelado algortmico sera:
a r c hi t e c t ur e Al go r i t mi c o o f Mux 2l l s
be gi n
pr o c e s s ( a , b, c t r l )
be gi n
i f ( c t r l = ' 0' ) t he n
z <= a ;
e l s e
z. <= b;
end if;
end pr o c e s s ;
end Al go r i t mi c o ;
Ms adelante en este captulo se vern con detalle las sentencias utilizadas en
el cdigo. En este momento sepuede decir que unproceso, definido mediante lapa-
labraclaveprocess, es una sentencia concurrente, en el sentido que todos los proce-
sosseejecutan simultneamente, que est formado por una o ms instrucciones se-
cuenciales. Por est razn, una arquitectura con un solo proceso es equivalente aun
algoritmo ejecutado secuencialmente.
2.3.2.2. Estilo flujo de datos
Unadescripcin en estilo deflujo dedatos refleja lafuncionalidad deun 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
losmdulos como suinterconexin con los dems mdulos.
El multiplexor de dos bits declarado anteriormente siguiendo un estilo de des-
cripcin deflujo dedatos sera:
a r c hi t e c t ur e F l uj o Da t o s o f MuX2l l s
s i gna l c t r l _ n, nl , n2 : bi t ;
be gi n
48 VHDL. Lenguaje estndar de Diseo Electrnico
ctrl_n <= not (ctrlJ after 1ns ;
nl <= ctrl_n and a after 2ns;
n2<= ctrl and b after 2ns;
z <= (nl ar n2J after 2ns ;
end FlujoDatos;
Enestecaso todas las operaciones quesetendran quellevar acabo seran de
tipo lgico y sepodran implementar mediante unasolapuerta. Engeneral lasope-
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 paradefinir lainterconexin
delosdiferentes operadores y asociaunvalor deretardo acadaoperacin mediante
laclusula after, quesever ms adelante enestecaptulo al hablar delas asigna-
ciones aseales.
2.3.2.3. Estilo estructural
Unaarquitectura definida utilizando el estilo estructural consiste enunconjunto de
componentes interconectados mediante seales. Un ejemplo tpico de descripcin
utilizando esteestilo es larepresentacin deuncircuito como unalistadecompo-
nentes interconectados (netlist) deunabiblioteca deceldas estndar deunatecnolo-
gadeterminada. Ladescripcin es puramente estructural en el sentido que no in-
cluye ningn tipo defuncionalidad, staentodo caso est incluida enladefinicin
delaarquitectura deloscomponentes queforman ladescripcin.
El multiplexor dedos bits declarado anteriormente podra describirse enestilo
estructural como unconjunto depuertas interconectadas delasiguientemanera:
architecture Estructural o f Mux 21 is
signal ctrl_n, nl , n2 : bit;
component; I NV
port ( Y : inbit;
z : out bit);
end c~nent;
c~nent AND2
port (x inbit;
y : inbit;
z : out bit):;
end c~nent;
c~nent OR2
port (x inbit;
y : inbit;
z : out bit)
end c~nent;
begin
UO: I NV 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;
2. Presentacin del lenguaje VHDL 49
En esta descripcin seveque en primer lugar es necesario declarar los compo-
nentes que sevan autilizar 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
paraconseguir la estructura deseada. Para cada referencia hay que dar un nombre
nicopara poder diferenciarla deotras referencias al mismo componente. Ms ade-
lanteen este captulo sehablar con ms detalle de cmo referenciar componentes
dentrodeuna arquitectura y delas posibilidades que existen para hacerlo.
2.3.2.4. Estilo mixto
Estesubapartado slo sirve para remarcar que aunque sehayan explicado diferentes
estilospara describir una arquitectura VHDL y sehayan dado ejemplos decada uno
deellos, todos estos estilos pueden mezclarse en laimplementacin 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
deecuaciones (procesos de una sola lnea) que determinen un flujo de los datos y
unaseriedereferencias aotros componentes dems bajo nivel. Por lo tanto, el gra-
dodeflexibilidad que permite VHDL en este sentido es muy importante.
2.3.3. Configuracin
Laconfiguracin es laconstruccin VHDL encargada de seleccionar laarquitectura
quesequiere utilizar para una entidad concreta. Como se ha comentado anterior-
mente, VHDL permite definir ms de una arquitectura por entidad para facilitar el
estudiodevarias posibilidades alahora deimplementarla.
Lasintaxis VHDL para definir una configuracin es lasiguiente:
c o n f i g u r a t i o n i d e n t i f i c a d o r of i d e n t i f i c a d o r _ e n t i d a d is
f o r i d e n t i f i c a d o r _ a r q u i t e c t u r a
{ f o r { r e f _ c o mp o n e n t e { , . . } I o t h e r s I all) :.i d . . . . c a u p o n e n t e
u s e e n t i t y i d _ e n t i d a d [ ( i d _ a r q u i t e c t u r a ) ; I
u s e c o n f i g u r a t i o n i d _ c o n f i g u r a c i n ; ]
e n d f o r ; }
end f o r ;
end [ c o n f i g u r a t i o n ] [ i d e n t i f i c a d o r ] ;
El identificador es el nombre que va a recibir la configuracin y servir para
poder referenciarla ms tarde. En caso que seincluya el identificador al final de la
declaracin debe coincidir exactamente con el que se haya incluido en la primera
lnea. Aparte deaportar un nombre, es necesario identificar laentidad y laarquitec-
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
unaarquitectura o bien indicar la configuracin que se quiere usar para cada com-
50 VHDL. Lenguaje estndar de Diseo Electrnico
ponente. Como se podra dar el caso de que dos referencias de un mismo compo-
nenteutilizaran diferentes arquitecturas (o entidades), seda flexibilidad para confi-
gurar todas las referencias deuncomponente alavez opor separado.
Laconfiguracin del multiplexor dedos bits utilizado en los subapartados ante-
rioresenel caso que sequiera trabajar con laarquitectura llamada FlujoDatos sera:
c o nf i gur a t i o n Mux 21_ c f g o f Mux 21 i s
f o r F l uj o Da t o s
end f o r ;
end Mux 21_ c f g;
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
dela entidad Mux21 anivel estructural existe una entidad con el mismo nombre y
una arquitectura llamada Algoritmico almacenadas en la biblioteca de trabajo. En
estecaso sepodra definir lasiguiente configuracin:
c o nf i gur a t i o n Mux 21_ c f g o f Mux 21 i s
f o r St r uc t ur a l
f o r UO : I NV use wo r k . e nt i t y I NV( Al go r i t l l \ i c o ) ; end f o r d;
f o r a l l : AND2 us e wo r k . e nt i t y AND2( Al go r i t mi c o ) ; end f o r d;
f o r U3 : OR2 us e wo r k . e nt i t y OR2( Al go r i t mi c o ) ; e nd f o r d;
end f o r d;
end Mux 21_ c f g;
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 ladefinicin decada dispositivo. De
esta forma sefacilita lareutilizacin y laactualizacin del cdigo.
Normalmente en un paquete se suelen declarar constantes, tipos y subtipos de
datos, subprogramas y componentes. Ms adelante en este captulo sever con ms
detalle el significado y lautilizacin decada uno deestos 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 ladeclaracin deun paquete suelen declarar-
se los subprogramas dndoles un nombre y la lista de parmetros necesarios para
llamarlos sin incluir su cuerpo. Respecto alas 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 ladeclaracin del paquete. La declaracin de componen-
2. Presentacin del lenguaje VHDL 51
tes es muy til, por ejemplo, para bibliotecas de celdas, de este modo los diseos
pueden utilizarlas sin tener que aadir una larga declaracin decomponentes al ini-
ciode su arquitectura. En este caso slo es necesario la interfaz de la celda, por lo
quela declaracin se pondr en la declaracin del paquete. Por ltimo, al declarar
tiposy subtipos dedatos yasedatoda lainformacin, por lo que suelen ponerse s-
loenladeclaracin del paquete, mientras que en el cuerpo del paquete pueden apa-
recer declaraciones detipos y subtipos tiles para el cuerpo delos subprogramas.
Lasintaxis VHDL para declarar unpaquete es lasiguiente:
pa c k a ge i de nt i f i c a do r
[ de c l a r a c i o ne s ]
end [ pa c k a ge ] [ i de nt i f i c a do r ] ;
Parael cuerpo del paquete lasintaxis VHDL es:
pa c k a ge boQy i de nt i f i c a do r i s
[ de c l a r a c i o ne s c ue r po ] ,
end [ pa c k a ge boQy] [ i de nt i f i c a do r ] ;
El identificador es el nombre que va arecibir el paquete y va aservir para refe-
renciarloms tarde. Este identificador puede repetirse al final de la declaracin. Co-
mopuede apreciarse, la sintaxis es muy parecida para ladeclaracin y el cuerpo del
paquete, lanica diferencia resideenlanaturaleza delas declaraciones delas dos uni-
dades. Al analizar el cuerpo deunpaquete es imprescindible haber analizado ladecla-
racinantes, deformaque si sta varasetendr quereanalizar el cuerpo del paquete.
Por ejemplo, podra utilizarse un paquete para definir el retardo delos operado-
reslgicos not, and y oro Aunque sepuede incluir toda la informacin en la decla-
racin del paquete, en el ejemplo se utiliza el cuerpo del paquete para dar valor a
lasconstantes:
P a c k a ge Re t a r do s Op i s
c o ns t a nt Re t NOT : t i me ;
c o ns t a nt Re t AND2 : t i me ;
c o ns t a nt Re t OR2 : t i me ;
end Re t a r do s Op;
P a c k a ge boQy Re t a r do s Op i s
c o ns t a nt Re t NOT : t i me :=1 M;
c o ns t a nt Re t AND2 : t i me : = 2' ns ;
c o ns t a nt Re t OR2 : t i me : = 2 ns ;
end Re t a r do s Op;
Cuando se analiza un paquete, el resultado del anlisis queda almacenado en
unabiblioteca para poder ser usado ms adelante. La forma deutilizarun elemento
deunpaquete desde un dispositivo es identificando el nombre debiblioteca, paque-
teyelemento. Las bibliotecas seexplicarn en el prximo subapartado deeste cap-
tulo, demomento sepuede pensar que el paquete est almacenado en una biblioteca
llamadaBiblio. Teniendo esto en cuenta, para utilizar por ejemplo laconstante Ret-
NOT declarada en el paquete RetardosOp setendr que escribir:
Bi bl i o . Re t a r do s Op. Re t NOT
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:
a r c h i t e c t u r e F l u j o Da t o s o f MUx 2 1 1 s
s i g n a l c t r l _ n , n I , n 2 : b i t ;
b e g i n
c t r l _ n <= not ( c t r l ) a f t e r Bi b l i o . Re t a r d o s Op . Re t NOT ;
n l <= c t r l _ n acd a a f t e r Bi b l i o . Re t a r d o s QP . Re t AND2 ;
n 2 <= c t r l acd b a f t e r Bi b l i o . Re t a r d o s Op . Re t AND2 ;
z <= ( n I a r n 2 ) a f t e r Bi b l i o . Re t a r d o s Op . Re t 0 R2 ;
end F l u j o Da t o s ;
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 sene-
cesite en mltiples ocasiones. Umi posibilidad para solucionar este problema es
usar la sentencia use al principio delaunidad dediseo donde dicho elemento vaya
aser utilizado. De este modo, en el cdigo sepodr identificar el elemento simple-
mente con su nombre. Por ejemplo, para indicar que se va a utilizar la constante
RetNOr del paquete RetardosOp seescribira al inicio del cdigo:
u s e Bi b l i o . R t a r d o s Op . Re t NOT ;
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:
u s e Bi b l i o . Re t a r d o s Op . a l l ;
Haciendo visibles todos los elementos del paquete al dispositivo, ladescripcin
delaarquitectura en estilo deflujo dedatos sera:
u s e Bi b l i o . Re t a r d o s Op . a l l
a r c h i t e c t u r e F l u j o Da t o s o f Mu x 2 1 1 s
s i g n a l c t r l _ n , n I , n2 : b i t ;
b e g i n
c t r l _ n <= not ( c t r l ) a f t e r Re t NOT ;
n I <= c t r l _ n a n d a a f t e r Re t AND2 ;
n2 <= c t r l aod b a f t e r Re t AND2 ;
z <= ( n I a r n 2 ) a f t e r Re t OR2 ;
end F l u j o Da t o s ;
En VHDL existe un paquete predefinido llamado standard almacenado en una
biblioteca llamada std que contiene tipos dedatos bsicos como, por ejemplo, los ti-
pos bit y time que sehan visto en algn ejemplo deeste captulo. Adems los fabri-
cantes suelen aportar otros paquetes con tipos de datos ms complejos y operacio-
nes sobreestos tipos para facilitar el trabajo del diseador.
2. Presentacin del lenguaje VHDL 53
2.3.5. Bibliotecas
Unabiblioteca sirve para almacenar el resultado del anlisis de las unidades de di-
seopara su futuro uso. Las bibliotecas son beneficiosas porque facilitan la com-
particinylareutilizacin del cdigo endiferentes diseos.
Aunque las unidades de diseo se analicen separadamente, se tiene que respe-
tar uncierto orden yaque algunas unidades dependen deotras. En general, ladecla-
racindeuna entidad tiene que analizarse antes que su arquitectura y ladeclaracin
deunpaquete antes que su cuerpo. Adems, cuando una entidad utilice algn ele-
mentodeun paquete, las unidades de este paquete tienen que analizarse antes que
lasunidades de la entidad, Por ltimo, antes de analizar una configuracin tienen
quehaberseanalizado las arquitecturas seleccionadas en dicha configuracin.
Enel caso del ejemplo del multiplexor dedos bits que seha venido utilizando
entodoesteapartado decaptulo sepodran analizar las unidades dediseo en el si-
guienteorden:
De c l a r a c i 6 n d e l p a q u e t e Re t a r d o s Op
Cu e r p o d e l p a q u e t e Re t a r d o s Op .
, De c l a r a c i 6 n d e l a e n t i d a d Mu x 2 1
' Ar q u i t e c t u r a F l u j o Da t o s d e Mu x 2 1
Ar q u i t e c t u r a Al g o r i t mi c o d e Mu x 2 1
Ar q u i t e c t u r a E s t r u c t u r a l d e Mu x 2 1
Co n f i g u r a c i n Mu x 2 1 _ c f g
Dehecho, la declaracin dela entidad Mux21 y de las arquitecturas Algoritmi-
ca yEstructural no dependen del paquete RedardosOp, por lo que podran haber si-
doanalizadas antes que el paquete.
Labiblioteca work o de trabajo sirve de biblioteca por defecto y es la que se
utilizasiempre que no se especifique otro nombre. De todos modos, el diseador
puedecrear el nmero debibliotecas que crea necesario y repartir sus diseos entre
lasbibliotecas delaforma que crea ms conveniente.
Desde un modelo almacenado en una biblioteca no puede accederse directa-
mentealas unidades de diseo de otras bibliotecas, ya que solamente setiene visi-
bilidadde la biblioteca donde est almacenado este modelo. Para dar visibilidad a
unabiblioteca 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
guardarenotra biblioteca setendra que empezar el modelo deesta forma:
l i b r a r y Bi b l i o t e c a E j e mp l o ;
u s e Bi b l i o t e c a E j e mp l o . P a q u e t e E j e mp l o . a l l ;
Las bibliotecas work y std son excepciones en el sentido que siempre son visi-
blesy, por tanto, no requieren lasentencia library.
Finalmente cabe destacar que ladefinicin debiblioteca es una definicin lgi-
ca, en el sentido que cada herramienta puede implementarla como quiera sobre el
sistemadeficheros. En algunos casos una biblioteca ser un fichero, en otros un di-
54 VHDL. Lenguaje estndar de Diseo Electrnico
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
laposicin fsica en el disco.
2.4. OBJETOS, TIPOS DE DATOS Y OPERADORES
Unobjeto VHDL es un elemento del lenguaje que tiene unvalor deuntipo dedatos
concreto. Este tipo de datos determina el conjunto de valores posibles que el objeto
puede contener as como laclase de operaciones que se lepodrn 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 alahora dees-
cribir un modelo, permite detectar errores durante el anlisis del cdigo sin necesi-
dad desimulacin.
En las siguientes secciones de este apartado se van arepasar los elementos l-
xicos del lenguaje, los objetos disponibles en VHDL, los diferentes tipos de datos
que sepueden asignar aestos objetos y los operadores que sepueden aplicar aestos
tipos dedatos.
2.4.1. Elementos lxicos
Antes deempezar ahablar delos 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 alos 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 dereglas alahora 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 severn acontinuacin).
2. Presentacin del lenguaje VHDL 55
Teniendo en cuenta estas reglas, acontinuacin se muestran ejemplos de iden-
tificadores correctos eincorrectos:
Cor r ec t os
i
i_2
Rel oj
Rel oj AOC
Rel oj _ AOC
I nc or r ec t oS
3
i2_
_i2
Rel oj $AOC
Rel oj _ AOC
I nt er r upc i on3_ Del _ P r oc es ador 3I nt er r upc i on
EnVHDL-93, aparte deestos identificadores bsicos, sedefinieron los identifi-
cadoresextendidos que pueden contener cualquier secuencia de caracteres. El obje-
tivodeestos nuevos identificadores es el de permitir la comunicacin entre herra-
mientasque procesen VHDL y otras herramientas que tengan reglas distintas para
formar sus identificadores. Para definir un identificador extendido se deben ence-
rrar suscaracteres entre '\'. De este modo, sedefiniran los identificadores extendi-
dos\3\, \i2_\, \_i2\, \Reloj$ADC\, \Reloj_ADC\ y \3Interrupcin\. En este caso s
quesediferencian las maysculas delas minsculas, de modo que los identificado-
res\RELOJ\, 'veloj. y\ReLoJ\. son distintos, ala vez que sediferencian delos iden-
tificadores bsicos en el sentido que el identificador reloj es diferente alos tres an-
teriores.
2.4.1.2. Palabras reservadas
Laspalabras reservadas sonun conjunto depalabras que tienen un significado espe-
cficoen VHDL y que sirven para definir las sentencias que forman un modelo. Por
estarazn estas palabras no pueden utilizarse como identificadores para dar nombre
aelementos del lenguaje.
En VDHL-87 el conjunto de palabras reservadas est formado por las siguien-
tespalabras:
abs el s e nand r et ur n
ac c es s el s i f new s el ec t
af t er end nex t s ev er i t y
al i as ent i t y nor s i gnal
al l ex i t not s ubt y pe
and f i l e nul l t hen
ar c hi t ec t ur e f or of t o
ar r ay f unc t i on on t r ans por t
as s er t gener at e open t y pe
at t r i but e gener i c or uni t s
begi n guar ded ot her s unt i l
bl oc k if out us e
body i n pac k age v ar i abl e
buf f er i nout por t wai t
bus i s pr oc edur e when
c as e l abel pr oc es s whi l e
c omponent l i br ar y r ange wi t h
56 VHDL. Lenguaje estndar de Diseo Electrnico
c o nf i gur a t i o n l i nk a ge r e c o r d x o r
c o ns t a nt l o o p r e gi s t e r
di s c o nne c t ma p r e m
do wnt o l OOd r e po r t
En VHDL-93 seaadieron nuevas pal abras reservadas al l enguaje. El conjunto
denuevas pal abras son l as l istadas acontinuacin:
gr o up
i I r q>ur e
i ne r t i a l
l i t e r a l
po s t po ne d
pur e
r e j e c t
r o l
r o r
s ha r e d
s l a
s 11
s r a
s r l
una f f e c t e d
x no r
2.4.1.3. Smbolos especiales
Adems de l os l iteral es y l as pal abras reservadas, VHDL aporta un conjunto de
smbol os especial es que tienen diferentes funciones, desde operadores de distintos
tipos hasta smbol os que forman parte desentencias o smbol os depuntuacin.
Los smbol os pueden estar formados por un carcter:
+ - + / ( ) ; &' <>=1#
opor dos caracteres:
=> ** : = / = >= <= <> - -
Los significados decada smbol o severn al o l argo del captul o cuando seha-
bl e del tema concreto donde seuseel smbol o. Por ejempl o, al tratar l os operadores
ms adel ante en este apartado se ver el significado de gran parte de smbol os de
esta l ista.
Quizs en este momento cabe destacar el smbol o "--" que sirve para aadir co-
mentarios en el cdigo. Cuando aparezca este smbol o en una l nea, el anal izador
no tendr en cuenta el texto comprendido entre este smbol o y el final de l a l nea.
Al igual que en cual quier programa escrito en un l enguaje deprogramacin comn,
resul ta muy til aadir comentarios en el cdigo para mejorar l al egibil idad.
Final mente resal tar que cual quier sentencia del l enguaje VHDL debe terminar
con el smbol o ";",
2.4.1.4. Literales
Un l iteral es un smbol o cuyo val or se obtiene directamente de su representacin.
Existen diferentes tipos de l iteral es dependiendo de l a natural eza de su val or, con-
cretamente l os l iteral es se dividen en: nmeros enteros, nmeros en punto fl otante,
l iteral es fsicos, caracteres, cadenas decaracteres y cadenas debits.
Los nmeros enteros, l os nmeros enpunto fl otante y l os l iteral es fsicos sirven
para expresar val ores numricos. Los nmeros enteros se componen simpl emente
deuna secuencia dedgitos, adiferencia del os val ores en punto fl otante, que deben
contener un punto y un dgito decimal . Por suparte, l os l iteral es fsicos son val ores
enteros o enpunto fl otante que tienen unaunidad demedida fsica asignada.
2. Presentacin del lenguaje VHDL 57
Algunos ejemplos deliterales enteros seran:
4 5436 o
Enel caso delos literales en punto flotante:
3. 1415927 5436. 0 0. 42
Por ltimo, los literales fsicos:
5. 23 ns 52 mm 0. 4 v
Adems deesta representacin, VHDL permite describir estos literales numri-
cosutilizando la notacin exponencial. Evidentemente el exponente tendr que ser
positivoparalos valores enteros.
Algunos ejemplos utilizando esta representacin seran:
52e2 43. 23E+2 2. 1E- 04 12E2 ko hm
Tambin cabe destacar que los literales numricos se pueden representar utili-
zandocualquier base entre 2 y 16. Para bases mayores que 10se utilizarn los ca-
racteresdesde 'A' a 'P' (oen minsculas) para representar los dgitos desde ellO al
15. La notacin exponencial tambin se puede representar en cualquier base. Por
ejemplo, el valor 12sepodra representar:
2#1100# 2#11#E2 4#30# 8#14# 10#12# 10i O. 12#e+2 16#C#
Como puede verse en el ejemplo, labase y el exponente siempre serepresentan
enbase decimal, de manera que la parte encerrada entre '#' es la que puede estar
descritaen otra base. Evidentemente, aunque el exponente est en notacin decimal
representauna potencia delabase con laque setrabaja.
Por ltimo, referente alos literales numricos slo decir que para mejorar lale-
gibilidadde nmeros con muchos dgitos sepermite aadir caracteres '_' entre los
dgitos. De esta forma, por ejemplo, sepueden agrupar los dgitos en grupos detres
paraseparar los valores numricos en miles.
Un literal carcter es simplemente un carcter ASCII encerrado entre comillas
simples. A continuacin sedan algunos ejemplos decaracteres:
'm' 'M' '3'
I I I I
r
Como se ve, el carcter comilla simple se representa mediante tres comillas
simplesseguidas.
Unliteral cadena decaracteres est formado por una secuencia decaracteres tal
comosunombre indica y serepresenta encerrndolo entre comillas dobles.
Algunos ejemplos decadenas decaracteres seran:
" abc def ' ' a4&3( j " " ho l a' ' abc de . , f ghi '
En el ltimo ejemplo semuestra que para incluir el carcter comillas dobles en
unacadena decaracteres basta con escribirlo dos veces seguidas.
58 VHDL. Lenguaje estndar de Diseo Electrnico
Por ltimo, un literal cadena debits est formado por una secuencia decaracte-
res de 'O' a '9' y de 'N a 'P' (o en minsculas) encerrados entre comillas dobles
precedidos deuna letra que indica labase. Esta letra puede ser B para binario, O pa-
ra octal o X para hexadecimal. Como en el caso de los literales numricos sepue-
den incluir caracteres '_' para mejorar lalegibilidad en caso de secuencias muy lar-
gas.
A continuacin sedan algunos ejemplos deliterales deestetipo:
2.4.2. Objetos del VHDL
Un objeto VHDL es un elemento que tiene asignado un valor deun tipo determina-
do. Hay cuatro clases distintas deobjetos: 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 sele puede dar un valor inicial, de no hacerlo VHDL inicializar el
objeto segn unas reglas que sedescribirn ms adelante.
En las siguientes secciones de este subapartado se vern con ms detalle cada
una deestas clases deobjeto.
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 hasido creada.
La sintaxis VHDL para declarar una constante es lasiguiente:
c o n s t a n t i d e n t i f i c a d o r L ...}: t i p o [ ~=e x p r e s i 6 n ] ;
El identificador dar nombre alaconstante 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 seincluir la parte de inicializacin en la declaracin. De todos modos,
laparte deinicializacin es opcional. Cuando seexplic el paquete sevio que lade-
claracin del paquete es una construccin VHDL que puede contener constantes sin
inicializar.
A continuacin seven algunos ejemplos dedeclaraciones deconstantes:
c o n s t a n t P i : r e a l ; = 3 . 1 4 1 5 9 2 7 ;
c o n s t a n t Bi t s P a l a b r a : i n t e g e r :=8 ;
c o n s t a n t N me r o P a l a b r a s : i n t e g e r . : = 64;
c o n s t a n t N me r o Bi t s : i n t e q e r :=Bi t s P a l a b r a * Nf f i e r o P a l a b r a s ;
c o n s t a n t Re t a r d 0 AND2 , Re t a r d o OR2 : t i me :=2 n s ;
2. Presentacin del lenguaje VHDL 59
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, yaque normalmente el identificador de la constante ser ms significativo
quesuvalor. Tambin para facilitar su actualizacin, deeste 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
enel cdigo.
2.4.2.2. Variables
A diferencia de las constantes, las variables pueden cambiar su valor una vez han
sidodeclaradas mediante las sentencias deasignacin. Una variable no tiene ningu-
naanaloga directa en hardware, normalmente se utilizan en el estilo algortmico
paraalmacenar valores intermedios dentro deunproceso.
Lasintaxis VHDL para declarar una variable es lasiguiente:
v a r i a b l e i d e n t i f i c a d o r { , . . . } : t i p o [ : =e x p r e s i n ] ;
Como se puede ver, a excepcin de la palabra reservada que es diferente, la
sintaxispara declarar una variable es idntica a la que se requera para la declara-
cindeunaconstante.
A continuacin semuestran algunos ejemplos dedeclaracin devariables:
v a r i a b l e I n d i c e l , Indic~, I n d i c e 3 : i n t e g e r : = O;
v a r i a b l e Co mp a r a c i o n : b o o l e a n ;
v a r i a b l e Re s u l t a d o : r e a l ;
Cuando una variable ha sido creada su valor puede ser modificado utilizando
unasentenciadeasignacin de variable. La sintaxis VHDL deestas sentencias es la
siguiente:
i d e n t i f i c a d o r : = e x p r e s i n ;
El nuevo valor de la variable ser el resultado de evaluar la expresin incluida
enlasentencia. La asignacin ser inmediata en el sentido que el nuevo valor susti-
tuiral antiguo inmediatamente despus dehaberse evaluado laexpresin, demodo
quesi en la siguiente sentencia se hace referencia a esta variable ya se tendr en
cuentael nuevo valor. Normalmente las variables sedeclaran en laparte declarativa
delosprocesos, 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
cuentaque la ejecucin de los procesos es concurrente, sera impredecible el resul-
tadoqueseproducira cuando unproceso modificara una variable mientras otro uti-
lizasuvalor, ya que este resultado depende totalmente del orden en que el simula-
dorejecutelos procesos.
Aunque en principio las variables son internas de un proceso, en VHDL-93 se
contemplael uso devariables globales para comunicar procesos.
60 VHDL. Lenguaje estndar de Diseo Electrnico
2.4.2.3. Seales
Una seal es unobjeto que, al igual que una variable, puede modificar suvalor den-
tro de los posibles valores de su tipo pero, a diferencia de sta, tiene una analoga
directa en hardware. yaque sepuede considerar como una abstraccin deuna cone-
xin fsica o un bus. Por esta razn, no est restringida aun proceso sino que sirve
para interconectar componentes deun circuito y para sincronizar laejecucin y sus-
pensin deprocesos.
La sintaxis VHDL para declarar una seal es muy parecida ala sintaxis reque-
rida para declarar constantes y variables:
s i gna l i de nt i f i c a do r {, . . . } : t i po [ : =~r e s i 6~1;
A diferencia de las variables, una seal no se declarar en la parte declarativa
deun proceso sino en ladelaarquitectura del dispositivo.
Los puertos deuna entidad son seales que seutilizan para interconectar el dis-
positivo con otros dispositivos. Sudeclaracin es unpoco especial, yaque aparte de
determinar un identificador y un tipo dedatos es necesario indicar ladireccin dela
seal respecto alaentidad. La seccin dedeclaracin depuertos deuna entidad tie-
nelasiguiente sintaxis VHDL:
port ( {i de nt i f i c a do r L . . . } : di r e c c i n t i po {! , =e x pr e s i l 11; } ) ' ;
En este caso la expresin opcional seutiliza en caso de que el puerto est des-
conectado.
A continuacin semuestran algunos ejemplos dedeclaracin deseales:
s i gna l Re l o j : s t q_ l o gi c : = ' O' ;
s i gna l Co mpa r a c i o n : bi t ;
s i gna l Re s ul t a do : i nt e ge r r a nge O to 7;
port ( a " b : in i nt e ge r r a nge O to 7;
c : o ut i nt e ge r r a nge O t o 7;
d : i no ut s t d_ l o gi c ) ;
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 serealiza de in-
mediato sino que antes seacaban deejecutar los procesos activos. De esta forma se
puede asegurar que, aunque el simulador sea secuencial, el resultado siempre serel
mismo, independientemente del orden en que seejecuten los procesos. Adems, en
la sentencia sepuede indicar el retardo con que se quiere realizar la asignacin, de
forma que cada seal tiene como mnimo una cola deeventos, en laque 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 deseales.
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
2. Presentacin del lenguaje VHDL 61
cuando lasimulacin termina. Un uso bastante comn delos ficheros es el dealma-
cenar los estmulos desimulacin que sequieren aplicar al modelo en un fichero de
entraday salvar los resultados de simulacin en un fichero de salida para su poste-
rior estudio.
Unfichero es deun tipo dedatos determinado y slo puede almacenar datos de
esetipo. Lasintaxis para declarar un fichero es lasiguiente:
f i l e i d e n t i f i c a d o r { , . . . } : t i p o _ f i c h e r o l i s d i r e c c i n " n o mb r e " ; ]
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-
menteantes de declarar el objeto fichero. En el siguiente subapartado de este cap-
tulosever cmo declarar tipos de datos y, concretamente, tipos de fichero. La di-
reccinindica si el fichero vaaser delectura odeescritura, mientras que el nombre
defichero serefiere al nombre fsico que va arecibir el fichero dentro del sistema
deficheros delacomputadora. Despus deladeclaracin deun fichero, VHDL au-
tomticamente abre el fichero para lectura o escritura dependiendo de la direccin
seleccionada.
Algunos ejemplos dedeclaracin deficheros seran:
f i l e E s t i mu l o s : F i c h e r o E n t e r o s i s in" d a t o s . i n " ;
f i l e S a l i d a : F i c h e r o E n t e r o s i s o u t " d a t o s . o u t " ;
EnVHDL-93 laforma dedeclarar ficheros hacambiado sensiblemente. La sin-
taxisparadeclarar un fichero en este caso es:
f i l e i d e n t i f i c a d o r { , . . . } : t i p o [[apen t i p o _ a c c e s o ] i s n o mb r e " ; ]
La direccin se sustituye por la palabra reservada open ms el tipo de acceso
quepuede ser read_mode, write_mode o append_mode. Dependiendo de este valor
seabrir el fichero de un modo u otro, en caso que no seespecifique ninguno, por
defecto seabrir en modo lectura. En VHDL-93 los ejemplos anteriores seran:
f i l e E s t i mu l o s : F i c h e r o E n t e r o s qpen r e a q _ n o d e i s " d a t o s . i n " ;
f i l e S a l i d a : F i c h e r o E h t e r o s apenwr i t e _ mo d e i s d a t o s . o u t " ;
Cabe destacar que en este caso VHDL-87 no es un subconjunto de VHDL-93,
por lo que un modelo que contenga declaraciones defichero con las palabras reser-
vadasin yout no seanalizar correctamente con un analizador deVHDL-93.
Por ltimo, decir que VHDL aporta un conjunto de subprogramas para leer y
escribir en ficheros deforma secuencial. Adems, en labiblioteca llamada standard
existeel paquete textio que define tipos dedatos y operaciones de lectura y escritu-
ratiles para tratar ficheros detexto.
2.4.3. Tipos de datos
El tipo dedatos es un concepto fundamental en VHDL, yaque cada objeto de-
be ser deun tipo concreto que determinar el conjunto devalores que puede asumir
ylasoperaciones que sepodrn realizar con este objeto.
62 VHDL. Lenguaje estndar de Diseo Electrnico
VHDL proporciona sentencias especficas para la declaracin de nuevos tipos
adems deun conjunto detipos predefinidos bsicos deuso comn. En las siguien-
tes secciones de este subapartado se ver cmo definir nuevos tipos y se dar una
clasificacin delos tipos predefinidos mostrando las caractersticas decada 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 devalores que forman el tipo dedatos. Concretamente, la sin-
taxis VHDL para declarar un tipo ser:
type identificador la definicin_tipo;
Laparte dedefinicin detipo sirve para indicar el conjunto devalores del tipo.
Puede tener varios formatos, que severn en detalle amedida que seexpliquen los
diferentes tipos predefinidos del lenguaje. A continuacin sedan ejemplos dedecla-
raciones:
type DiaMes la range 1 to 31;
type PuntosCardinales la (norte, sur, este, oeste);
Una vez definido un nuevo tipo de datos ya sepueden declarar objetos de este
tipo, teniendo en cuenta que los ficheros requieren un tipo especial llamado tipo fi-
chero. Por ejemplo, sepodran 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 eincompatible con los dems tipos, aun cuando las defi-
niciones sean idnticas. Si por ejemplo sedeclara el tipo
type De1a31is 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 detipo para que laasignacin serealice entre operandos del mismo tipo.
Si sedeclara 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 sedescriben ms adelante en este captulo):
Ntunero :=DiaMes_Dela31(DiasEnero);
2. Presentacin del lenguaje VHDL 63
2.4.3.2. Tipos de datos escalares
Lostipos dedatos 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-
posreales son continuos en el sentido que dentro deun 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 decada tipo.
2.4.3.2. 1. Tipos enteros y tipos reales
Lostipos 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
suelendefinir nuevos tipos que determinan el rango devalores que sevan autilizar.
Deestamanera,la sintaxis VHDL para declarar un tipo entero o real especificando
unrangoes lasiguiente:
type identificador is range literal to I downto litera:l;
Dependiendo de si se escriben literales enteros o en punto flotante, el tipo de
datosdeclarado ser de tipo entero o de tipo real. Con las palabras reservadas to y
downto sepuede indicar un rango creciente o decreciente respectivamente, de esta
formasedeterminar la ordenacin que tendrn los valores dentro del tipo. Por de-
fecto, un objeto de tipo entero o real seinicializa al valor ms ala izquierda de los
queforman el tipo, que en este caso coincide con el primer literal del rango.
A continuacin sedanejemplos dedeclaraciones detipos dedatos enteros yreales:
type PrecioProducto is range 1to ;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
Lostipos 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-
ciadauna unidad primaria de la medida fsica que quieren cuantificar. Tambin se
puedendefinir unidades secundarias mltiplos delaunidad primaria para poder uti-
lizar, encada momento, launidad ms adecuada segn el valor que sequiera repre-
sentar.Lasintaxis VHDL para declarar un tipo fsico es lasiguiente:
64 VHDL. Lenguaje estndar de Diseo Electrnico
t y p e i d e n t i f i c a d o r i s r a n g a l i t e r a l to I d o wn t o l i t e r a l
un i t s
i d e n t i f i c a d o r ;
{ i d e n t i f i c a d o r = l i t e r a l _ f s i c o :
end un i t s [ i d e n t i f i c a d o r ] ;
El identificador es el nombre que recibe el tipofsicoy sirve para referenciarlo.
El rangodetermina el valor mnimoy mximodeunidades primarias del tipofsico.
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 omediante unaunidad secundaria previamente declarada.
Sepuede definir un tipofsicopara cualquier medida fsica que sequiera cuan-
tificar. Probablemente, el tipofsicoms comn en VHDL es el tipotime (tiempo),
declarado en el paquete standard de la biblioteca std, que sirve para especificar re-
tardos. Ladeclaracin del tipotime sera:
t y p e t i me i s r a n g a O t o l E 2 Q
un i t s
f s ;
p s = 1000 f s :
n s = 1000 p s ;
llS z : . 1000 n s ;
ros = 1000 us:
s e c = 1000 IlS;
ritn = 60 sec;
hr = 60 minr
end un i t s ;
Internamente VHDL considera los tipos fsicos como enteros con una unidad
primaria asociada, por loque cualquier valor fsicoque contenga un literal real ser
redondeado aun nmero entero de unidades primarias. Por ejemplo, los tres litera-
les siguientes sern equivalentes:
4 . 3 2 11 p s 4 . 3 2 1 p s 4 3 2 ' 1 f s
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 launidad 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 laresta dedos valores deuntipofsicodarn
comoresultado un valor del mismo tipo. Por otra parte, la multiplicacin ser dife-
rente, ya que, por ejemplo, al multiplicar dos distancias noseobtiene una distancia
sinoun rea. VHDL nosoporta la multiplicacin directa de tipos fsicos, loque 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 ladivisin entre tipos fsicos y nmeros reales oenteros estar per-
mitida y el resultado ser del tipofsico, oladivisin dedos valores fsicos dar co-
moresultado un valor entero.
2. Presentacin del lenguaje VHDL 65
2.4.3.2.3. Tipos enumerados
El ltimotipo dedatos escalar es el tipo enumerado, en el que sedefine el conjunto
deposiblesvalores del tipo especificando una listaque contiene todos los valores. Se
llamantiposenumerados porque enlalistaseenumeran todos ycadauno delos valo-
resqueformanel tipo. Lasintaxis paradeclarar untipo enumerado es lasiguiente:
type identificador is ( identificador r carcter {, ... } );
El primer identificador es el nombre del tipo y servir para referenciarlo. Entre
parntesisy separados por comas se especifican todos los valores del tipo. Como
mnimodebe 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);
Apartirdeestostiposacabadosdedefinir sepodrandeclarar objetosdeestostipos:
v a r i a b l e ComandoActual : Comandos:=abajo;
v a r i a b l e TeclaActual : Teclas :='a';
Unobjeto detipo enumerado seinicializa por defecto al valor ms alaizquier-
dadelos que aparecen en la definicin del tipo. Por lo tanto, la inicializacin del
segundoejemplo es redundante, yaque TeclaActual yahubiera tomado el valor 'a'.
Enel paquete standard de la biblioteca std se definen algunos tipos enumera-
dosdeusobastante comn. Concretamente el tipo carcter, el tipo booleano y el ti-
pobit. El tipo carcter no es ms que una enumeracin de todos los caracteres del
conjuntodecaracteres de 8bits estandarizado por laISO. Los tipos booleanos y bit
sedefinendelasiguiente manera:
type boolean is (false, true);
typebitis ('O', '1');
El tipo booleano seutiliza normalmente como resultado delaevaluacin de un
operadorrelacional, mientras que el tipo bit seutiliza para el modelado de sistemas
digitales.
Detodos modos, el tipo bit sueleresultar insuficiente porque no tiene en cuenta
laspropiedades elctricas de las seales. Por esta razn se han definido nuevos ti-
posqueincluyen valores como, por ejemplo, desconocido o no inicializado. IEEE
haestandarizado un paquete llamado std_logic_1164 que incluye un tipo llamado
std_ulogic que permite modelar las seales de forma ms adecuada. Dicho paquete
ademsdefine los operadores para trabajar con objetos de este tipo. La definicin
del tipostd_ulogic es lasiguiente:
type std_ulogic is ( 'U', _ No inicializado
'X', _ Forzando desconocido
'0', _ Forzando cero
'1" _ Forzando uno
66 VHDL. Lenguaje estndar de Diseo Electrnico
'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 dedatos std_ulogic directamente. Los modelos quequieran usar este
tipo dedatos tendrn quecontener las sentencias necesarias paraobtener lavisibili-
dadaestepaquete, concretamente al inicio debern incluir:
library IEEE;
use IEEE.std_logic_1164.all;
Finalmente destacar que algunos literales forman parte de ms deun tipo de
datos enumerado. Por ejemplo, el carcter 'O' est incluido enlos tipos dedato ca-
rcter, bit y std_ulogic. Cuando esto ocurre sedicequeel literal est sobrecargado.
Normalmente, cuando aparece unliteral sobrecargado enunmodelo, por el contex-
to puede sabersedequ tipo es. Detodos modos, algunas veces es necesario indicar
explcitamente el tipo dedatos del literal paraevitar confusiones, es lo quesecono-
cecomo calificacin detipo:
character+('.o'), bit' ('O') , std_ulogic' ('O')
No debe confundirse lacalificacin detipos con laconversin detipos. Enel
primer caso slo seespecifica de qu tipo es un literal para evitar confusiones,
mientras queenel segundo seaplicaunafuncin paramodificar el tipo original del
literal.
2.4.3.3. Declaracin de subtipos de datos
Como sehavisto anteriormente, untipo dedatos defineunconjunto deposibles va-
lores quepuede contener unobjeto VHDL. Muchas veces habr ciertos objetos de
un tipo que solamente tomarn valores deun subconjunto delos valores del tipo,
de modo que nunca contendrn ciertos valores concretos. Para esta situacin,
VHDL proporciona el subtipo, queasocia unarestriccin auntipo basepara obte-
ner un subconjunto de valores del dominio del tipo. A partir deeste momento se
pueden declarar objetos deestesubtipo queslo podrn contener valores dentro del
subconjunto acabado dedefinir. '
La sintaxis VHDL para definir un subtipo apartir de un tipo base es la si-
guiente:
subtype identificador 1s id_tipo [range literal to I downto literal];
El identificador danombre al subtipo y servir parareferenciarlo ms tarde. A
continuacin hacefaltaespecificar el tipo baseparael quesedefine el subtipo y la
restriccin mediante el comando range. En el siguiente apartado, cuando sehable
2. Presentacin del lenguaje VHDL 67
detipos devectores no restringidos se ver otra forma de especificar subtipos para
definir lalongitud del vector. Cabe destacar que la parte derestriccin es opcional,
por lo que se puede definir un subtipo que contenga exactamente los mismos ele-
mentosqueel tipo base.
VHDL tiene algunos subtipos predefinidos como, por ejemplo, positive y natu-
ral, quesonsubtipos del tipo base integer y'seutilizan pararepresentar nmeros posi-
tivosynaturales respectivamente. La definicin deestos subtipos sera la siguiente:
subtype natural la integer range O to integer'high;
subtype positive la integer range 1to intleger'high;
Enel subapartado 2.4.5 sehablar delos atributos predefinidos deVHDL, en es-
tosmomentos sepuede decir que integer'higb devolver el valor entero ms grande.
A continuacin sedan algunos ejemplos ms dedeclaraciones desubtipos:
subtype DiaMesia integer range 1to 31;
subtype Digito la character range ' 0 ' to ' g r ,
type Decimal ia ('0', '1', '2', '3', '4', '5'.' .'.6",,:. '7', 'S'. ,,~9:.1i
subtype Octal la Decimal range t Or to '7 ' ;
Sehavisto que dos tipos dedatos diferentes no pueden utilizarse como operan-
dosenunamisma operacin. Un tipo y un subtipo no pueden considerarse tipos di-
ferentes,por lo que seles pueden aplicar las mismas operaciones y pueden mezclar-
seenunaoperacin. De todos modos, en caso que setenga que asignar el resultado
aunobjeto del subtipo, este resultado tendr que cumplir la restriccin asociada al
tipobase, es decir, tendr que pertenecer al subconjunto de los posibles valores del
subtipo,deno ser as seproducir un error durante la simulacin. Por tanto, un sub-
tipodedatos puede ser til para asegurarse que cada objeto toma valores dentro de
surangoesperado, detectando el error en caso contrario.
Por ltimo decir que sepueden declarar subtipos dedatos implcitamente en el
momentodedeclarar un objeto. Por ejemplo:
variable MesActual : integer range 1to 12;
Lavariable llamada MesActual forma parte deun subtipo del tipo de datos en-
teroqueno sehadeclarado explcitamente.
2.4.3.4. Tipos de datos compuestos
Lostiposdedatos compuestos son aqullos cuyos valores sepueden dividir en uni-
dadesatmicas ms pequeas. Existen dos tipos compuestos bsicos: los vectores y
losregistros. Los primeros estn compuestos por unidades atmicas del mismo tipo
mientras que los segundos son heterogneos en el sentido que estn formados por
unconjunto de objetos diferentes. Al declarar un objeto de tipo compuesto, cada
unodesus elementos seinicializar por defecto segn las reglas que correspondan
asutipo. En este subapartado sevan arepasar las caractersticas decada tipo deda-
toscompuestos y las posibilidades que ofrece cada clase.
68 VHDL. Lenguaje estndar de Diseo Electrnico
2.4.3.4. 1. Vectores
Un vector es un conjunto de objetos del mismo tipo ordenados mediante uno o ms
ndices que indican laposicin decada objeto dentro del vector. El nmero dendi-
ces determina la dimensin del vector, para vectores que tengan un solo ndice se
hablar devectores unidimensionales o simplemente vectores, en cambio los vecto-
res con ms deun ndice sern vectores multidimensionales omatrices.
Para declarar un vector setendr 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 lasiguiente:
t y pe i de ndi f i c a do r i s a r r a y ( r a ngo {, . . } ) of t i po _ o bj e t o s ;
El identificador da nombre al vector y sirve para referenciarlo, los rangos pue-
den describirse explcitamente en ladeclaracin obien sepuede dar directamente un
nombre detipo o subtipo que yaincluya una restriccin derango y finalmente el ti-
po indicar el conjunto devalores posibles quepueden tomar los objetos del vector.
A continuacin sedan algunos ejemplos dedeclaraciones devectores:
t y pe By t e i s a r r a y ( O to 7) o f bi t ;
t y pe By t e 2 i 8 a r r a y ( 7 do wnt o O) o f bi t ;
s ubt y pe De Oa 7 i 8 i nt e ge r r a nge O to 7;
t y pe By t e 3 i s a r r a y ( De Oa 7) o f bi t ;
s ubt y pe De c i ma l i s c ha r a c t e r r a nge ' O' to ' 9' ;
t y pe By t e 4 i 8 a r r a y ( De c i ma l r a nge ' O' to ' 7' ) of bi t ;
t y pe P unt o s Ca r di na l e s i s ~ ( no r t e , s ur , e s t e , o e s t e ) ;
t y pe E s t a do i s a r r a y ( P unt o s Ca r di na l e s r a nge no r t e to e s t e ) of i nt e ge r ;
Una vez seha declarado el tipo que define un vector, sepueden declarar obje-
tos de este tipo, tanto constantes corno variables y seales. Por ejemplo, sepodran
declarar las siguientes variables:
v a r i a bl e Ope r a do r 1 : By t e ;
v a r i a bl e Ope r a do r 2 : By t e 2;
v a r i a bl e Ope r a do r 3 : By t e 3;
v a r i a bl e Ope r a do r 4, Ope r a do r 5 : By t e 4;
v a r i a bl e E s t a do Ac t ua l : E s t a do ;
Las variables acabadas de declarar sern vectores compuestos por un conjunto
de elementos atmicos y ser posible operar con todo el vector ala vez o con cada
elemento individualmente identificndolo mediante el ndice. Por ejemplo, se po-
dran realizar las siguientes operaciones deasignacin:
Ope r a do r 1( }) .:P= . ' . 1' ;
Ope r a do r 2 := 10010Q10 ;
Ope r a do r 3 ( 3 t o 6) := 1000 ;
Ope r a do r 4( ' 5' ) :=' 1' ;
Ope r a do r 5 := pe r a do r 4;
E s t a do Ac t ua l ( no r t e ) :=35;
2. Presentacin del lenguaje VHOL 69
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 seasignan slo cuatro elementos (del 3al 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,
sepodra definir una matriz dedos dimensiones para modelar una memoria:
type Me l r o r i a i8 array (Oto 7, Oto 63) o f b i t ;
Unavez declarado el tipo Memoria sepueden declarar objetos deeste tipo:
variable Ra mA, RamB : Me mo r i a ;
Denuevo sepodr trabajar con toda la matriz ala vez o acceder alos elemen-
tos por separado, esta vez har falta especificar el valor de dos ndices en lugar de
uno:
R amA :=RamB
Ra mA( 4, 7) := ' 1' ;
En este ejemplo concreto de una memoria, considerando que est formada por
64palabras de 8bits, sepodra acceder auna palabra delasiguiente forma:
type Di r e c c i o n i8 range o to 63;
type Co n t e n i d o la array (Oto 7) of b i t ;
variable Di r e c c i o n Ra mA Di r e c c i o n ;
variable Co n t e n i d o Ra mA : Co n t e n i d o ;
Di r e c c i o n Ra mA :=34;
COl ' l t e n i d o Ra mA :=R amA(O to 7, Di r e c c i o n Ra mA) ;
En los ejemplos mostrados sehavisto que sepuede acceder tanto aun solo ele-
mento de un vector como a un subconjunto de elementos o a todo el vector. Para
asignar valores aun solo elemento basta con utilizar un literal adecuado al tipo de
datos del elemento. Para asignar valores aun conjunto deelementos, en cambio, se
requiere una nueva construccin que permita asignarlos todos ala vez. Por esta ra-
znVHDL proporciona el agregado que permite escribir un vector de literales que
sepodrn asignar simultneamente a los elementos de un vector. La sintaxis del
agregado es lasiguiente:
( [ p o s i c i n { I . . . } => 1 literal t. "':.. }J
Es decir, setrata deuna lista deliterales separados por comas y encerrada entre
parntesis. Existen dos modalidades de agregados, en la primera se indica la posi-
cindecada literal dentro del vector y en lasegunda seomite esta posicin, dema-
neraqueel orden viene determinado por laordenacin deliterales en lalista.
Por ejemplo, sepuede definir un tipo dedatos para representar puntos en el es-
pacio:
70 VHDL. Lenguaje estndar de Diseo Electrnico
type Coordenadas is (X, y, Z).;
type Punto 1a array (Xto Z) of real;
A continuacin sepueden declarar los siguientes objetos:
constant OrigEm: Punto ::;: {O.O, 0.0, 0.0);
variable Punto'tT Punto;
En ladeclaracin delaconstante Origen sehausado un agregado en el que se
haomitido laposicin decada literal, por lo que el primer literal seha asignado a
Origen(X), el segundo a Origen(Y) y el tercero y ltimo aOrigen(Z). Para dar un
valor ala variable Puntol sepodra 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 deque muchas posiciones deun vector tengan asignado el mismo va-
lor, sepuede utilizar la palabra reservada others para asignar un valor atodas las
posiciones alas quean no seles hayadado valor. Por ejemplo:
constant Origen: Punto := (others =>0.0);
Puntol := (2 =>7.3, others =>2.5);
Por tanto, gracias al agregado esposible trabajar contodo el vector alavez, sin
tener queutilizar bucles que accedan acadaelemento por separado parallevar aca-
bo cualquier asignacin.
Todos los tipos devectores vistos hasta el momento sonrestringidos en el sen-
tido que definen muy claramente surango y, por tanto, queda especificado desde el
principio el nmero deelementos quetendr el vector y las caractersticas delos n-
dices que van autilizarse. Adems deeste tipo devectores, VHDL proporciona los
tipos devectores no restringidos en los que solamente seindica el tipo delos obje-
tos que vaacontener sin especificar ningn rango. En el momento dedeclarar un
objeto deestetipo sercuando seasignar unrango aesteobjeto concreto.
Lasintaxis VHDL paradeclarar untipo devector norestringido eslasiguiente:
type identificador is array ( tipo_ndice range <>{, ... } ) of tipo_objeto;
Por ejemplo, sepodra declarar el tipo siguiente:
type VectorReales is array ( natural range <>) of real;
A continuacin sepodran declarar subtipos y objetos deeste tipo especifican-
doel rango adecuado:
subtype Punto : Vecto:rR~les (Ote 2);
constant origen: :PUnto ::!" (0.0, 0.0, 0.:0);
variable Muestras: VectorReales(O to 9);
2. Presentacin del lenguaje VHDL 71
VHDL proporciona gran cantidad de tipos vector no restringidos a los que se
les daun rango cuando se declara un objeto de dicho' tipo. Cabe destacar el tipo
string paratratar cadenas de caracteres, el tipo bitvector para vectores de bits y el
tipostd_ulogic_vector para vectores del tipo std_ulogic que no forma parte del n-
cleodeVHDL sino que est definido en el paquete std_logic_1164 deIEEE. La de-
claracindecada uno deestos tipos sera lasiguiente:
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 semuestra cmo sedeclararan objetos deestos 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
Unregistro es un tipo dedatos compuesto que adiferencia delos vectores est for-
madopor unidades atmicas dedistinto tipo, que reciben el nombre decampos. Por
estarazn, los campos no se referencian mediante un ndice como en los vectores
sinoque requieren un identificador nico dentro del registro para referenciarlo. El
tipodedatos 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-
ceptostotalmente distintos que no hay que confundir.
Lasintaxis 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-
nndolesun tipo.
Por ejemplo, sepodra declarar untipo para guardar fechas:
type Fecha la record
Dia integer range 1 to 31;
Mes : integer range 1 to 12';
An_o : integer range Oto '2
t
OOJ _
end record; " ,
Unavez declarado el tipo Fecha sepueden declarar objetos deeste tipo:
variable Hoy, Ayer : Fecha;
Al igual que pasaba con los vectores, sepuede acceder aun solo elemento del
registro oatodo el registro alavez:
72 VHDL. Lenguaje estndar de Diseo Electrnico
Ayer.Dia :=15; Ayer.Mes :=5; Ayer.AA....o:=1997:
Ho y :=Ayer;
Para asignar valores atodo el registro sepueden usar tambin agregados con la
listadeliterales que sequieran asignar. En este caso no tiene sentido indicar laposi-
cin que sequiere actualizar sino el identificador del campo. Por ejemplo:
Hoy :=(5, 4, 1997);
Ho y := (Dia => 5, Mes => 4, Al:L.o: : : > 1997) ;
Al tratarse de un registro, normalmente dentro de un mismo agregado aparece-
rn literales dedistintos 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 deacceso.
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 deda-
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 semodele aalto nivel deabstraccin.
La sintaxis VHDL para declarar untipo deacceso es lasiguiente:
t y pe i dent i f i c a do r i s a c c es s t i po _ da t o s ;
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 avalores enteros seescri-
bira:
t y pe Apunt a Ent er o s i s a c c es s i nt eger ;
A continuacin se podra declarar una variable apuntador a enteros de la si-
guiente manera:
v a r i a bl e Ent er o _ Ap : Apunt a Ent er o s ;
Para crear un nuevo objeto existe la palabra reservada new, alaque seledebe
indicar el tipo del objeto para poder determinar el tamao de memoria que se re-
quiere:
2. Presentacin del lenguaje VHDL 73
6 n t e r o . . . , . AP : = new i n t e g e r ;
Paraacceder al dato apuntado por el objeto deun tipo de acceso sepuede utili-
zarlapalabra reservada all:
E n t e r o _ Ap . a l l := 3 4 ;
Finalmente, para desalojar lamemoria ocupada cuando yano serequiere el ob-
jeto sepuede usar el procedimiento implcito deallocate que VHDL crea automti-
camentecada vez que sedeclara untipo deacceso:
d e a l l o c a t e ( E n t e x : : . o ~! ;
Paradefinir estructuras ms complejas, como, por ejemplo, una lista encadena-
da, bastacon definir un tipo registro que contenga algn elemento apuntador apun-
tandoaunregistro del mismo tipo.
2.4.3.5.2. Tipos fichero
Unobjetofichero seutiliza en VHDL para almacenar datos deun tipo determinado.
Antesdepoder trabajar con un fichero es necesario declarar un tipo fichero que in-
diquelanaturaleza de los objetos que se van a almacenar. La sintaxis VHDL para
declarar untipo fichero es lasiguiente:
t y p e i d e n t i f i c a d o r i e f i l e o f p o _ o b j e t o s ;
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
sevanaalmacenar en el fichero. Una vez declarado el tipo, para trabajar con un fi-
cheroconcreto se tiene que declarar un objeto fichero de este tipo, tal como se vio
enel subapartado que hablaba de los distintos objetos del lenguaje. Por ejemplo,
paradeclarar un tipo de fichero para almacenar enteros y leer datos de un fichero
llamadodatos.in en VHDL-87 seescribira:
t y p e F i c h e r o E n t e r o s i e f i l e o f i n t e g e r ;
f i l e E s t i mu l o s : F i c h e r o E n t e r o s i e in " d a t o s . i n " ;
En la biblioteca std se define el paquete textio que proporciona el tipo fichero
detexto y los subprogramas de lectura y escritura para trabajar con este tipo de fi-
cheros. Concretamente define los dos tipos siguientes:
t y p e l i n e i e a c c e e e s t r i n g ;
t y p e t e x t i e f i l e o f s t r i n g ;
El tipo text est formado por un conjunto de cadenas de caracteres, mientras
queel tipo Une es un apuntador auna cadena decaracteres. Entonces, gracias aope-
raciones delectura y escritura deuna lnea afichero y operaciones para aadir y sa-
car datos de la lnea sobre objetos de diferentes tipos, sepuede trabajar fcilmente
conestos ficheros.
74 VHDL. Lenguaje estndar de Diseo Electrnico
Aunque los procedimientos severn en el apartado dedicado asubprogramas, a
continuacin seintroducen los proporcionados por textio para que secomprenda 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 unobjeto detipo lnea sepuede 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 lalnea siguiente, mientras que writeline grabar la
variable detipo 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: inid_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, demodo que sepueden volcar palabras deuna lnea sobre variables de
cualquier tipo y tambin sepueden aadir valores decualquier tipo auna lnea.
Los ficheros detexto seutilizan amenudo para almacenar los estmulos que se
van aaplicar al circuito y para grabar los resultados obtenidos para poder ser anali-
zados despus delasimulacin.
Ejemplo:
La entidad Sumador recibe operandos enteros en sus dos entradas y devuelve la su-
ma deestos operandos en su salida. La declaracin dedicha entidad es la siguiente:
entity Sumadoris
port (OpA : ininteger;
OpB in integer;
Suma : out integer);
end;
Sequiere 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 detexto que sellame Resultados.txt. El forma-
to del fichero Datos.txt es el siguiente:
5 3 5 2 2
; ' 3 4 3 5
2 -3
Mientras que el fichero Resultados.txt debe tener el siguiente formato:
2. Presentacin del lenguaje VHOL 75
53 + 522 = 575
. .34 + 35 = 1
2 - 3 = - 1
Laentidad BancoPruebas debe ir leyendo los operandos del fichero Datos.txt,
aplicarlosala entidad Sumador y almacenar los valores obtenidos ala 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-
municacincon el exterior, por lo que ladeclaracin delaentidad ser la siguiente:
e n t i t y Ba n c o P r u e b a s i s
end;
Por lo que a la arquitectura se refiere, bsicamente contendr la referencia al
sumadory 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
esteproceso severn en los prximos apartados de este captulo, por lo que si este
ejemplo no queda claro en este momento, tal vez se comprenda completamente
cuandoseacabe de leer el Captulo 2. La arquitectura final de BancoPruebas sera
lasiguiente:
library IEEE;
u s e s t d . t e x t i o . a l l ;
a r c h i t e c t u r e F u n c i 9 n a l 9f B n c o P r u e b a s i s
s i g n a l Op A, Op B, S u ma : i n t e g e r ;
c o mp o n e n t S u ma d o r
port ( Op A ini n t e g e r ;
0pB : ini n t e g e r ;
S u ma : o u t i n t e g e r ) ;
end c o r r p o n e n t ;
b e g i n
- - p r o c e s o q u e l e e l o s e s t mu l o s y g r a b a l o s r e s u l t a d o s
p r o c e s s
c o n s t a n t P e r i o d o : t i me := 100 n s ;
f i l e Da t o s : t e x t i s i n " Da t o s . ' t x t ;
v a r i a b l e L i n e a Da t o s : l i n e ;
f i l e Re s u l t a d Os : t e x t i s o u t " Re s u l t a d o s . t x t ;
v a r i a b l e L i n e a Re s u l t a d o s : l i n e ;
v a r i a b l e Op A_ I , Op B_ I : i n t e g e r ;
b e g i n
wh i l e n o t e n d f i l e ( Da t o s ) l o o p
r e a d l i n e ( Da t o s , L i n e a Da t o s ) ;
r e a d ( L i n e a Da t o s , Op A_ I ) ;
r e a d ( L i n e a Da t o s , Op B_ I ) ;
Op A <= Op A_ L ;
Op B <= Op B_ I ;
wa i t f o r P e r i o d o ;
76 VHDL. Lenguaje estndar de Diseo Electrnico
write(LineaResultados, OpA) ;
i f OpB_ I ~ O t he n
write(LineaResultados, string'(M ~M ) ) ;
e l s e
write(LineaResultados, string' ( M + M ) ) ;
end i f ;
write (LipeaResultaQos<, abs tOpB));
write(LineaResultados, string' ( M = M ) ) ;
write_(LiIJ,eaResultados, Suma);
writeline(Resltados, LineaResultados);
end loop;
wait;
end pr o c e s s ;
-- Referencia al sumador
SumadorO: Sumador port map (OpA, OpB, Suma);
end Funcional;
Cabe destacar que el paquete textio, aparte delos tipos fichero detexto 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 lalectura de los operandos y laescritura de los resultados. Como secoment
en subapartados anteriores deestecaptulo, laasignacin auna seal no seproduce
inmediatamente sino que primero se requiere la suspensin de todos-los procesos
activos, esto seconsigue mediante esta sentencia que suspende el proceso durante
un periodo detiempo especificado por laconstante Periodo. Esta cantidad detiem-
po debera ser como mnimo el retardo que necesita el componente Sumador para
generar la salida Suma. En principio, apartir de laarquitectura del componente se
puededeterminar cul esestetiempo mnimo, enel ejemplo sehasupuestoque 100ns
sonsuficientes.
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, sedispone de una serie de operadores ms
unos elementos queactan como operandos. Estos elementos suelen ser bsicamen-
teliterales, identificadores, atributos que determinen un valor, calificaciones y con-
versiones detipo y parntesis paraespecificar unorden deprecedencia. Por loquea
los operadores serefiere, VHDL tiene predefinidos los operadores aritmticos, rela-
cionales, lgicos y deconcatenacin decualquier lenguaje deprogramacin comn
ms los operadores de desplazamiento para vectores unidimensionales que fueron
aadidos enVHDL-93.
En laTabla2-1 semuestran todos los operadores predefinidos deVHDL 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-
2. Presentacin del lenguaje VHDL 77
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 demoperando
no! negacin bit, booleano, vector bits demoperando
*
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
+
msunario numrico demoperando
menos unario numrico dem operando
+ suma numrico op numrico demoperandos
resta numrico op numrico demoperandos
& 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 bitsop entero vector bits
ror rotacin derecha vector bits op entero vector bits
= igual que nofichero op nofichero booleano
1= diferenteque nofichero op nofichero booleano
< menor que no fichero op nofichero booleano
> mayor que nofichero op nofichero booleano
<=
menor oigual que nofichero op nofichero booleano
>= mayor oigual que nofichero op nofichero booleano
and y lgica bit, booleano, vector bits op bit, booleano, vector bits dem operandos
or olgica bit, booleano, vector bits op bit, booleano, vector bits demoperandos
nand y lgicanegada bit, booleano, vector bits op bit, booleano, vector bits dem operandos
nor olgicanegada bit, booleano, vector bits op bit, booleano, vector bits dem operandos
xor oexclusiva bit, booleano, vector bits op bit, booleano, vector bits dem operandos
xnor oexclusiva negada bit, booleano, vector bits op bit, booleano, vector bits demoperandos
78 VHDL. Lenguaje estndar de Diseo Electrnico
carse sobre un conjunto de tipos dedatos 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 deIEEE sedefinen muchos deestos operadores para traba-
jar con el tipo dedatos std_ulogic_vector. Puede existir un nmero ilimitado dede-
finiciones deun operador, lanica condicin que sedebe cumplir es que no serepi-
tan los tipos de ios operandos y del resultado en dos definiciones diferentes de un
mismo operador, yaque de ser as, no habra forma de saber aqu operando seest
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 dedatos, un objeto, una entidad o un proce-
dimiento. No sedebe confundir un atributo deun objeto con su valor, yaque 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
depermitir ladefinicin denuevos atributos.
La sintaxis VHDL para utilizar un atributo deun elemento es lasiguiente:
i d e n t i f i c a d o r _ e l e me n t o ' i d e n t i f i c a d o r _ a t r i b u t o
En las siguientes secciones de este apartado sepresentarn los atributos prede-
finidos del lenguaje y acontinuacin semostrar la forma cmo un diseador pue-
dedefinirse sus propios atributos.
2.4.5.1. Atributos de rangos de vectores
En laTabla 2-2 semuestran los atributos predefinidos sobre los rangos delos vecto-
res restringidos (constrained array). La letra A que se utiliza para denominar este
TABLA 2-2. Atributos predefinidos pararangos devectores
Atributo Descripcin
A'left(n)
A'right(n)
A'low(n)
A'high(n)
A'ascending(n)
A'range(n)
A'reverse_range(n)
A'length(n)
Valor izquierdo del ndice nde A.
Valor derecho del ndice ndeA.
Valor mnimo del ndice ndeA.
Valor mximo del ndice ndeA.
Verdadero si el rango del ndice ndeA es ascendente.
Rango del ndice ndeA.
Rango del ndice ndeA invertido.
Nmero de valores del rango ndeA.
2. Presentacin del lenguaje VHDL 79
tipodeatributos proviene delapalabra inglesa array, que significa vector. La inclu-
sindeladimensin sobre laque seaplica el atributo es opcional, en caso deno es-
pecificarseseusar el primer ndice del vector.
Normalmente es recomendable utilizar estaclase deatributos enlugar delitera-
lesespecficos para cada tipo de datos, ya que se obtienen modelos ms generales
quefacilitan la actualizacin del cdigo. Por ejemplo, si se considera el siguiente
cdigo:
t y pe P a l a br a : bi t _ v e c t o r ( O te 7) ;
s i gna l Da t o : P U~: r ; i l . i
process (Dato]
be gi n
f o r iin O te 7 loop
ifDa t o ( i ) - . . .
e nd l o o p;
end process;
Uncambio en el nmero de bits por palabra obliga a modificar la declaracin
del tipopalabra, as como de cualquier parte del cdigo que haga referencia aeste
parmetro, como el bucle del ejemplo (los bucles se vern en el siguiente apartado
deestecaptulo). En cambio, este mismo cdigo sepodra haber escrito:
t y pe P a l a br a : bi t _ v e c t o r ( O te 7) ;
s i gna l Da t o : P a l a br a ;
process ( Da t o )
be gi n
f o r iin Da t o ! ~ge l o o p
i f Da t o ( i ) - . . .
e nd l o o p;
end process;
Conlo que un cambio en el rango del tipo Palabra no provoca ninguna modifi-
cacinenel bucle que, al utilizar el atributo range, yarefleja este cambio automti-
camente.
2.4.5.2. Atributos de tipos de datos
EnlaTabla2-3 se muestran los principales atributos aplicados atipos de datos. La
letraT sirve para indicar que el elemento sobre el que se aplica el atributo es un ti-
podedatos.
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-
nidospor el tipo T, aunque esto no tiene por qu ser as, habiendo algunos atributos
quesiempre 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-
80 VHDL. Lenguaje estndar de Diseo Electrnico
Atributo
TABLA 2-3. Atributos predefinidos para tipos de datos
Descripcin
T'base
T'left
T'right
T'low
T'high
T'ascending
T'image(x)
T'value(x)
T'pos(x)
T'val(x)
T'succ(x)
T'pred(x)
T'leftof(x)
T'rightof(x)
Tipo base deT.
Valor ms alaizquierda deT.
Valor ms aladerecha deT.
Valor mnimo deT.
Valor mximo deT.
Verdadero si T tiene rango ascendente.
Representacin textual del valor x detipo T.
Valor expresado por lacadena decaracteres.
Posicin ocupada por x en T.
Valor delaposicin x enT.
Valor delaposicin siguiente ax en T.
Valor delaposicin anterior ax en T.
Valor de laposicin derecha ax.en T.
Valor de laposicin izquierda ax en T.
mero siguiente de un valor real. Finalmente, cabe destacar que los atributos aseen-
ding, value eimage fueron introducidos en VHDL-93.
2.4.5.3. Atributos de seales
En laTabla 2-4 semuestran los principales atributos que sepueden aplicar auna se-
al. La letra S como prefijo del atributo sirve para especificar que setrata deatribu-
tos aplicados auna seal.
Atributo
TABLA 2-4. Atributos predefinidos para seales
Descripcin
S'delayed(t)
S'stable(t)
S'quiet(t)
S'transaction
S'event
S'active
S'last_event
S'last_active
S'last_ value
S'driving
S'driving_ value
Seal S retrasada t unidades detiempo.
Seal booleana verdadera si S es estable hace t unidades de tiempo.
Seal booleana verdadera si no hahabido ninguna asignacin aS en
t unidades detiempo.
Seal detipo bit, vale' l' cuando hay asignacin aS.
Verdadero si ocurre un evento en S.
Verdadero si ocurre una asignacin en S.
Unidades detiempo desde el ltimo evento.
Unidades detiempo desde laltima asignacin aS.
Valor anterior de S.
Verdadero si el proceso actual "conduce" S.
Valor que conduce aS el proceso actual.
2. Presentacin del lenguaje VHOL 81
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
dedatos, 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
loqueun analizador deVHDL-87 no los reconocer.
2.4.5.4. Atributos definidos por el usuario
Apartedelos atributos predefinidos, VHDL permite definir nuevos atributos que se
pueden asociar acualquier elemento del lenguaje. Para hacerlo, en primer lugar se
debe declarar el atributo asignndole un identificador y el tipo de datos del valor
quedevolver. Una vez declarado, sedebe especificar el elemento al que vaasocia-
do y su valor. Los atributos definidos por el usuario siempre son estticos, es decir,
constantes.
Lasintaxis VHDL para declarar un atributo es lasiguiente:
a t t r i b u t e i d e n t i f i c a d o r : t i p o _ d a t o s ;
Mientras que lasintaxis para laespecificacin del atributo es:
a t t r i b u t e i d e n t i f i c a d o r of i d _ e l e me n t o . : c l a s e _ e l e me n t o i s e x p r e s i n ;
El identificador del elemento sirve para determinar el elemento especfico al
quesele aplica el atributo, mientras que laclase del elemento determina su natura-
leza; por ejemplo, indica si setrata deuna seal, unprocedimiento ouna entidad.
Finalmente, para utilizar un atributo definido por el usuario se debe proceder
del mismo modo que antes:
i d e n t i f i c a d o r _ e l e me n t o ' i d e n t i f i d i d o r _ a t r i b u t o
Lazona de cdigo donde debe especificarse un atributo depender del elemen-
to al que vaya asociado el atributo. Por ejemplo, si el atributo seaplica aun tipo de
datos, aun objeto o aun subprograma sepodr declarar una vez sehaya declarado
el tipo, el objeto o el subprograma correspondiente, si se asocia auna entidad, una
arquitectura o un paquete sepodr declarar en la zona destinada adeclaraciones de
cada una de estas unidades de diseo. Por otra parte, la nica condicin que debe
cumplir ladeclaracin de un atributo es que sea anterior asu especificacin, por lo
quemuchas veces seincluyen todas las declaraciones deatributos enun paquete.
A continuacin sedan algunos ejemplos de definicin de atributos aplicados a
elementos dediferentes clases. En primer lugar, sepodra definir un atributo que in-
dicarael nmero depin que sevaautilizar para una determinada seal:
s i g n a l Re l o j : s t Q_ l o g i c ;
a t t r i b u t e Nu me r o P i n : n a t u r a l ;
a t t r i b u t e Nu me r o P i n o f Re l o j : s i g n a l i s 5 ;
Tambin sepodran definir atributos que almacenaran el retardo desde cada en-
tradaacada salida deuna entidad:
82 VHDL. Lenguaje estndar de Diseo Electrnico
e nt i t y MUX21 l a
po r t ( a , b, c t r l : inbi t ;
z : o ut bi t ) ;
a t t r i but e De Aa Z : t i me ;
a t t r i but e De Ba Z : 'time;
a t t r i but e De Ct r 1a Z : t i me ;
a t t r i but e De Aa Z a f AND2 : e nt i t y i a 1. 2 na ;
a t t r i but e De Ba Z a f AND2 : e nt i t y i a 1. 2 ns ;
a t t r i but e De Ct r l a Z a f AND2 : e nt i t y i a 1. 0 ns ;
e nd e nt i t y MUX21.
Como ltimo ejemplo, los literales deun tipo enumerado tambin podran tener
un atributo para determinar sucodificacin:
t y pe P unt o s Ca r di na l e s ia ( no r t e , s ur , e s t e , o e s t e ) ;
a t t r i but e Co di go Es t a do s : bi t _ v e c t o r ;
a t t r i but e Co di go Es t a do s a f no r t e : l i t e r a l i a " 10" ;
a t t r i but e Co di go Es t a do s o f s ur : l i t e r a l i a 00" ;
a t t r i but e Co di go Es t a do s o f e s t e : l i t e r a l l a " 11" ;
a t t r i but e Co di go Es t a do s a f o e s t e : l i t e r a l i a ' 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 delos subprogramas.
Las podemos clasificar en sentencias de asignacin (a seal y avariable), sen-
tencias condicionales (ij, case), sentencias iterativas (loop, exit, next), otras senten-
cias (wait, assert, null) y llamadas asubprogramas.
2.5.1. Lasentencia 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 sesuspende y al mismo tiem-
po sefijan las condiciones para su reactivacin. La sintaxis general dela sentencia
wait es:
[ e t i que t a : 1 wa i t [ e n s e a l ( , . . })
[ unt l l e x pr e s i n_ bo o l e a na )
[ f o r e x pr e s i o n_ t i e mpo )
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
2.5.13.
Veamos cmo secomporta la sentencia wait para cada una delas posibilidades
que ofrece su sintaxis.
2. Presentacin del lenguaje VHDL 83
La primera forma en que sepuede 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
quepueda volver aactivarse en toda lasimulacin. El uso ms comn deeste estilo
desentencia wait lo encontramos en los bancos depruebas, que normalmente espe-
cifican una serie deacciones opruebas arealizar sobre el dispositivo averificar, y a
continuacin se termina la simulacin. El esquema habitual de esta estructura se
muestra en el siguiente ejemplo:
pr o c e s
be gi n
s e nt e nc f a s _ s e c ue nc i a l e s
wa i t ;
e nd pr o c e s s ;
La segunda forma de usar la sentencia wait establece aqu 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 enla sentencia wait el proceso sedesper-
tar y ejecutar sus sentencias secuenciales hasta ejecutar otra vez una sentencia
wait. Es usual utilizar esta forma dela sentencia wait para modelar lgica combina-
cional que debe responder acualquier cambio que se produzca en sus entradas. El
siguiente ejemplo modela una puerta and dedos entradas:
pr o c e s s
be gi n
e <= a and b;
wa i t o n a, b;
e nd pr o c e s s ;
Este proceso ejecuta la sentencia c<=a and b y luego se suspende. Sereactiva-
rcuando seproduzca un evento ena oen 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 decomo re-
sultado TRUE o FALSE. Un ejemplo tpico de este uso de la sentencia wait se en-
cuentraen el modelado deelementos sensibles al flanco deunreloj. El siguiente pro-
cesodescribe el comportamiento deunbiestable sensible al flanco desubidadel reloj:
pr o c e s s
be gi n
q<= d;
wa i t unt i l Re l o j ~' l ' ;
e nd pr o c e s s ;
Al ejecutar la sentencia wait el proceso se suspender y no sereactivar 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-
cinbooleana.
84 VHDL. Lenguaje estndar de Diseo Electrnico
Por ltimo al suspender un proceso sepuede especificar un cierto tiempo antes
de que ste sereactive. 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.
pr o c e s s
begin
Reloj <= not Relj;
wa i t f o r 10 na ;
e nd pr o c e s s ;
Cada vez que el proceso sesuspenda, sefija sureactivacin para 10ns ms tar-
de, demodo que lo que sehace es generar unreloj de20ns deperiodo.
Estas distintas opciones de la sentencia wait pueden mezclarse deforma que se
pueden especificar condiciones de reactivacin de un proceso ms complejas que
las vistas en los ejemplos anteriores. Por ejemplo, lasiguiente sentencia:
wa i t e n a , bunt i l c =' l '
Suspende el proceso en que se encuentre hasta que haya un evento en a o en b
y adems secumpla lacondicin c='] '. El proceso slo es sensible alas seales a o
b, deforma que un evento sobre la seal eque provoque que el valor desta pase a
ser '1' no implica que el proceso deba despertar.
Otro ejemplo deun uso complejo delasentencia wait puede ser:
wa i t o n a , b, f o r 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 aseal como sentencia secuencial (dentro deunproceso odel cuerpo
deun subprograma) presenta lasiguiente sintaxis en suforma ms sencilla:
[etiqueta ;1 nombre_seal <= valor {after expresion_tiempo}
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
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 adicha
seal) y un conjunto depares tiempo valor, que forman lahistoria futura delaseal
o cola deeventos dela seal. Recordemos tambin que incluso en el caso deejecu-
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
2. Presentacin del lenguaje VHDL 85
pasar aestudiar con ms detalle las opciones dela asignacin a seal, debe quedar
claro que al ejecutarse una deestas sentencias, no seest modificando el contenido
delaseal, sino que seest modificando el contenido de su cola deeventos, es de-
cir, seest proyectando un pasible cambio del valor futuro de la seal, que algunas
vecespuede no llegar aproducirse.
Para dejar claro este comportamiento de la asignacin aseal (que al principio
pareceextrao al compararlo con laasignacin avariable), veamos un ejemplo que
nos ayude a entender mejor su funcionamiento. Supongamos que queremos in-
tercambiar el contenido dedos seales, para ello podemos escribir el siguiente pro-
ceso:
process
begin
a <= b;
b <= a;
wait on a, b;
endprocess;
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
coladeeventos de a. No ser hasta la suspensin del proceso (ejecucin de la sen-
tenciawait) cuando las seales a y b tomen el valor que sehaproyectado en sucola
deeventos.
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 aun mnimo. Buscando analogas con el mundo fsico, el modelo
detransporte es el que refleja una lnea detransmisin ideal, mientras que el mode-
loinercial es el que rige el comportamiento deuna puerta lgica.
Por defecto, VHDL supone que las asignaciones aseal siguen el modelo iner-
cial, para usar el modelo transporte debe especificarse en la asignacin, utilizando
lasiguiente sintaxis:
nombre_seal <= [transport] valor [after expresion_tiempo]
Veamos algunos ejemplos que nos aclaren las diferencias entre la asignacin
conmodelo transporte y modelo inercial. En primer lugar veamos el modelo trans-
porte, que es ms intuitivo.
Al producirse una asignacin aseal con el modelo detransporte, sta proyecta
nuevos valores en lacola deeventos dela seal, deforma que si los valores sepro-
yectanpara tiempos posteriores al ltimo evento que yatenga proyectada lacola de
eventos, ste nuevo valor seaade asta. Por ejemplo, para el siguiente proceso:
process
begin
s <= transport, 'o' after 10na,
s <= transport '1' after 20na,
86 VHDL. Lenguaje estndar de Diseo Electrnico
wait;
endprocess;
Despus delaejecucin delasdosasignaciones, lacolaeventos des contendr
losvalores 'O' enel tiempo 10nsy '1' enel tiempo 20 ns(Figura 2-7-a). Pero si se
invierteel ordenenqueseejecutan estas dosasignaciones:
process
begi n
s <= transport '1' after 20 na;
s <= transport 'O' after 10 na;
wait;
end process;
En este caso, al ejecutarse la segunda asignacin, seeliminar de lacola de
eventos el valor que haba proyectado laprimera, quedando proyectado en dicha
colaques debetomar el valor Oalos 10ns(Figura2-7-b). Deformaquecuando se
produce unaasignacin aseal paratiempos anteriores alos queyasetengan pro-
yectados en lacola de eventos, todos aquellos eventos proyectados para tiempos
posteriores soneliminados delacoladeeventos.
Cuando laasignacin usael modelo inercial (por defecto) su comportamiento
es unpoco menos intuitivo, deforma que para asignaciones atiempos anteriores
alos ya proyectados en lacola de eventos de la seal secomporta 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 10ns; ,__-'--_----'
s<=transport '1' after 20ns;----....
wait;
end process;
t 10 ns 20 ns
v 'O' -r
(a)
Cola de eventos de s
process
begin
s<=transport '1' after 20ns;~
s<=transport 'O' after 10ns; ~
wait;
t 20 ns
v '1'
end process;
10 ns
(b)
'O'
FIGURA 2-7. Evolucin de la cola de eventos. Modelo de transporte.
2. Presentacin del lenguaje VHDL 87
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
be gi n
s <= 'o' af t e r 10 DS;
S <= ' 1' af t e r 20 DS;
wait;
end process;
Eneste caso laasignacin de '1' en el tiempo 20 ns elimina delacola deeven-
tos des laproyeccin de 'O' en tiempo 10ns, yaque el nuevo valor proyectado es
distinto al anterior (Figura 2-8-a). Para el segundo ejemplo:
process
be gi n
s <= ' 1' af t e r 20 DS;
S <= ' O' af t e r 10 DS;
wait;
end process;
Cola de eventos de s
process t 10ns
begin ___________..
v 'O'
s<='O' after 10ns; L..._--L._ __ .....J
s<='1' after 20ns; _
wait;
end process;
(a)
'1'
20 ns
Cola de eventos de s
t 20 ns
v '1'
t 10ns
v
(b)
FIGURA 2-8. Evolucin de la cola de eventos. Modelo inercial.
88 VHDL. Lenguaje estndar de Diseo Electrnico
El comportamiento en este caso es el mismo que para el modelo de transporte,
la segunda asignacin elimina el valor que laprimera haba proyectado sobre laco-
ladeeventos delaseal (Figura 2-8-b).
Por ltimo destacar que existe una variacin dela 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
Ope r a ndo <= O a f t e r 10 na , 10 a f t e r 20 na , 100 a f t e r 30 DS;
wa i t ;
end procesa;
Esta asignacin genera una serie de cambios sobre la seal Operando. sta to-
mar los valores Oalos 10ns, 10alos 20 ns y 100alos 30 ns independientemente
del tipo deretardo especificado.
La nica diferencia que incorpora VHDL-93 ala asignacin aseal secuencial
es que ampla los modelos de retardo. Para ello incluye la palabra reservada reject
(rechaza), que puede usarse como modificador del modelo deretardo inercial (y no
el transporte). Con la opcin de rechazar se puede especificar para qu valores de
tiempo (qu anchuras depulso) sedebe rechazar una transicin sobre una seal. Pa-
rams detalles sobre el comportamiento deesta opcin, consultar [A95][BFMR93].
2.5.3. Asignacin avariable
La asignacin avariable reemplaza el valor actual de la variable con el valor espe-
cificado por una expresin. Su sintaxis general es:
[etiqueta :1 nombre_variable .:.~expreaion,
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
2.5.13.
A diferencia delaasignacin aseal vista en el apartado anterior, laasignacin
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 deasignaciones:
a :=b
b :=a;
2. Presentacin del lenguaje VHDL 89
No consigue intercambiar las dos variables, sino que despus deejecutarse am-
bas variables contienen el valor inicial de b. Para intercambiar las variables debe-
mosusar una variable temporal:
'l'q) ,;;: a;
a :=b;
b :='Inp;
Una variable sedeclara en unproceso oen un subprograma y slo es visible en
eseproceso o subprograma. Las variables definidas en un proceso existen durante
todala simulacin, o sea, nunca sereinicializan. Las variables definidas en un sub-
programa sereinicializan cada vez que sellama al subprograma. Si laejecucin de
un subprograma se suspende por la ejecucin de una sentencia wait, entonces sus
variables mantienen su valor cuando sereactiva, hasta el momento en que setermi-
nelaejecucin del mismo.
VHDL-93 introduce una variacin importante en las variables: introduce el
concepto de variable compartida (shared variable). Una variable compartida sede-
clara usando la sintaxis habitual de declaracin de variable, aadiendo la palabra
claveshared:
s h a r e d v a r i a bl e n o mbr e _ v a r i a bl e : t i p o _ v a r i a bl e ;
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 adicho
proceso o subprograma.
La asignacin avariable compartida tiene lamisma sintaxis que laasignacin a
variable local y la principal diferencia estriba en qu distintos procesos o subpro-
gramas pueden realizar asignaciones sobre lavariable. En caso deusar este recurso,
el usuario debe tener en cuenta que el resultado de la simulacin ya no es determi-
nista, sino que depende del orden deejecucin delos procesos.
2.5.4. Lasentencia 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
entrevarios conjuntos de sentencias aejecutar, cada uno deellos en funcin de dis-
tintas condiciones. La sintaxis general delasentencia if es lasiguiente:
i f c o n d i c i o n then s e n t e n c i a s _ s e c u e n c i a l e s
{ e l s i f c o n d i c i o n then s e n t e n c i a s _ s e c u e n c i a l e s }
[ e l s e s e n t e n c i a s _ s e c u e n c i a l e s ]
end i f ;
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-
tuyelacondicin.
90 VHDL. Lenguaje estndar de Diseo Electrnico
La forma ms sencilla en la que podemos utilizar la sentencia if es la evalua-
cin deuna nica condicin que permite o no la ejecucin deuna 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 decarga (Carga). Utilizaremos un pro-
ceso con una sentencia if con el propsito demodelar el comportamiento del biesta-
ble:
e nt i t y L a t c h is
port(
Ca r ga , Da t o : inbi t ;
Bi e s t a Ql e : o ut bi t )
end L a t c h;
a r c hi t e c t ur e Ej e r r pl o o f L a t c h i s
be gi n .
pr o c e s s
be gi n
i f Ca r ga =' l ' then
Bi e s t a bl e <= Da t O
e nd i f
wa i t o n Ca r ga , Da t o ;
e nd pr o c e s s ;
end Ej e mpl o ;
El proceso del ejemplo es sensible alas seales Dato y Carga; por lo tanto, cada
vez quehaya unevento en alguna deellas seejecuta. En esecaso alaseal Biestable
slo seleasigna el valor que contenga Dato si laseal decarga vale '1'. En otro ca-
solaasignacin no seejecuta y, por lo tanto, Biestable mantiene suantiguo valor.
Una segunda forma de la sentencia if permite escoger entre dos grupos de sen-
tencias aejecutar, dependiendo de una condicin; en caso que la condicin secum-
pla, se ejecutar el primer grupo, en caso contrario se ejecutar el segundo grupo.
Un ejemplo tpico del uso deesta sentencia if sepuede encontrar en el modelado de
un buffer triestado. Si laseal dehabilitacin est activa, el buffer dejapasar alasa-
lidael valor que tenga en su entrada, en otro caso deja su salida en alta impedancia:
e nt i t y T r i e s t a t e is
port(
Ha bi l i t a c i o n, e nt r a da : instd-Ioqcr
Sa l i da : out s t d~l o gi c ) ;
end T r i e s t a t e ; .
a r c hi t e c t ur e Ej e mpl o o f T r i e s t a t e i s
be gi n
pr o c e s s
be gi n
i f Ha bi l i t a c i o n=' l ' t he n
Sa l i da <= Ent r a da ;
e l s e
Sa l i da <= ' Z' ;
end i f ;
wa i t 00Ha bi l i t a c i o n, Ent r a da ;
end pr o c e s s ;
e nd Ej e mpl o ;
2. Presentacin del lenguaje VHDL 91
Una tercera forma de la sentencia if permite seleccionar entre dos o ms con-
juntos de sentencias aejecutar, cada una de ellas en funcin de distintas condicio-
nes. Como ejemplo podemos ampliar el biestable anterior, y modelar un biestable
quetenga una seal deinicializacin (Iniciar). Dejamos como ejercicio para el lec-
tor la modificacin de la entidad correspondiente, ala que debe aadirse un puerto
deentrada.
process
begin
if Iniciar='O' then
Biestable <= ' O' ;
elsif carga='!' t be n
Biestable <= Dato;
end if;
wait on Iniciar, Carga, Dato;
end process;
En este ejemplo podemos observar que.si secumple la primera condicin (Ini-
ciar= 'O') se colocar el valor 'O' sobre la seal Biestable. Slo si no se cumple la
primera condicin seconsiderar la segunda, y en caso que sta sea cierta (TRUE)
seasignar Dato aBiestable. Obsrvese que laforma'enque seejecuta 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
noseejecutar aun cuando sucondicin decontrol fuese cierta.
Esta ltima forma delasentencia if, que permite escoger entre distintos grupos
desentencias aejecutar dependiendo de una condicin de ejecucin para cada uno
deellos, puede ampliarse aadiendo un ltimo conjunto de sentencias que seejecu-
tenencaso que no secumpla ninguna delas condiciones anteriores.
2.5.5. Lasentencia case
La sentencia case seutiliza 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 decualquier tipo discreto (enumera-
dos o enteros) o de tipo vector de una dimensin. La forma general de la sentencia
case es:
[etiqueta :1case ex>resion is
when valor => sentencias':'secuenciales;
{when valor => sentencias_secuenciales;}
end case;
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
2.5.13.
De forma natural la sentencia case nos permite seleccionar entre un conjunto
deposibilidades. Un ejemplo tpico del uso de esta sentencia es el modelado de un
92 VHDL. Lenguaje estndar de Diseo Electrnico
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 : inbit_vector(O to 1);
Entrada1, Entrada2, Entrada3, Entrada4 inbit_vector(O to 7);
Salida: wt bit_vector (Oto 7));
end Mux;
architecture Ejemplo o f 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:
2. Presentacin del lenguaje VHDL 93
p r o c e s s
be gi n
c a s e S e l e c c i o n is
wben " OO' I " 0 1 " = >
S a l i d a <= E nt r a d a ! ;
wben " l O" =>
S a l i d a <= E nt r a d a 2 ;
wben "U =>
S a l i d a <= E nt r a d a 3 ;
e nd c a s e ;
wait o n S e l e c c i o n, E nt r a d a ! , E nt r a d a 2 , E nt r a d a 3 ;
e nd p r o c e s s ;
Sepuede especificar un rango dentro delos valores posibles delaexpresin de
seleccin que en este caso deben tomar valores discretos (enteros o enumerados).
Paraello sepuede usar lapartcula to, con lo cual sepuede especificar un rango co-
mo valork to valorm. Por ejemplo, volvamos amodificar nuestro multiplexor para
convertirlo enun multiplexor dedos salidas, cuyaseal deseleccin sedefine deun
tipoenumerado que puede tomar los valores a, b, e, y d. Entonces podemos escribir:
p r o c e s s
be gi n
c a s e S e l e c c i o n l s
when "a"to c =>
S a l i d a <= E nt r a d a ! ;
wben "dO =>
S a l i d a <= E nt r a d a 2 ;
e nd c a s e ;
wait on S e l e c c i o n, E nt r a d a ! , E nt r a d a 2 ;
e nd p r o c e s s ;
Por ltimo, se puede especificar como valor de seleccin la palabra clave
others, cuando en unasentencia case aparece estaopcin, debe ser laltima, y sig-
nificaque en caso de no escoger ninguno de los rangos especificados en las opcio-
nes anteriores de lasentencia, seejecutarn las sentencias que seencuentren en di-
chaopcin. Como ejemplo podemos modelar el multiplexor de dos entradas de la
siguiente forma:
p r o c e s s
be gi n
c a s e S e l e c c i o n l s
when " a O to " c " =>
S a l i d a <= E nt r a d a ! ;
whe n o t he r s =>
S a l i d a <= E nt r a d a 2 ;
e nd c a s e ;
wait o n S e l e c c i n, E nt r a d a ! , E nt r a d a 2 ;
e nd p r o c e s s ;
Es muy habitual el uso de laclusula others en laltima opcin de lasenten-
ciacase debido aque todos los posibles valores de la seal de seleccin deben
quedar cubiertos. Dehecho, para el primer ejemplo del multiplexor, sehadefinido
94 VHDL. Lenguaje estndar de Diseo Electrnico
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 detipo std_logic_vector, debera aadirse laclusula others al final dedicho
ejemplo.
2.5.6. Lasentencialoop
La sentencia loop se utiliza para ejecutar un grupo de sentencias secuenciales de
forma repetida. El nmero derepeticiones puede controlarse en la misma sentencia
usando alguna delas opciones que sta ofrece. Su sintaxis general es:
{ e t i q u e t a ] : [ wh i l e c o n d c o n b o o l e s n a I f o r c o n t . r 6 L . i e p t i c i o n ] l o o p
s e n t e n c i a s s e c u e n c i a l e s
end l o o p [ e t i q u e t a ] ;
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 deellas.
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 enprincipio pueda parecer no muy
adecuada ladefinicin deun bucle infinito en la descripcin deun 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 aeje-
cutar el conjunto de sentencias que lo modelan deforma indefinida. Aunque no sea
el ejemplo idneo (yaque dada su sencillez sepuede modelar deforma ms elegan-
te sin recurrir a la sentencia loop), podemos usar este esquema para modelar un
contador decuatro bits (mdulo 16), al que queremos dar un valor inicial:
e n t i t y ' Co n t a d o r _ O_ 1 5 l s
port(
Re l o j : inb i t ;
Cu e n t a : o u t n a t u r a l ) ;
end Co n t a d o r _ O_ 1 5 ;
a r c h l t e c t u r e E j e mp l o of Co n t a d o r _ O_ 1 5 1 8
s i g n a l Co n t a d o r : n a t u r a l ;
b e g i n
p r o c e s s
b e g i n
Co n t a d o r <= O;
l o o p
wa i t u n t l l Re l o j =' 1 ' ;
Co n t a d o r <= ( Co n t a d o r + 1 ) mod 1 6 ;
end loop;
end p r o c e s s ;
Cu e n t a <= Co n t a d o r ;
e n d E j e mp l o ;
2. Presentacin del lenguaje VHDL 95
Al inicio de la simulacin seejecutar 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 seespera aque seproduzca un flanco desubida
del reloj y en ese momento seincrementa 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
formanunca seraposible avanzar el tiempo desimulacin.
Se puede definir una condicin de finalizacin del bucle con la opcin while
condicion booleana. En este caso el grupo desentencias secuenciales especificadas
enla sentencia loop seejecutarn mientras lacondicin seacierta, cuando lacondi-
cin sea falsa se abandonar el bucle para pasar a ejecutar las sentencias que apa-
rezcan acontinuacin. Como ejemplo podemos modificar el proceso que modela el
contador anterior sinusar lafuncin mod delasiguiente forma:
pr o c e s s
be gi n
Co nt a do r <= O r" . j.
wa i t unt i l Re l o j : ' l ' ;
whi l e Co nt a do r < 15 l o o p
Co nt a do r <= Co nt a do r + 1;
wa i t unt i l Re l o j =' l ' ;
e nd l o o p;
e nd pr o c e s s ;
El bucle anterior se ejecutar mientras el contador no llegue al valor 15; en
cuanto el contador tome el valor 15, Secumple lacondicin definal del bucle y, por
lo tanto, pasa aejecutarse la primera sentencia que seencuentre despus de la sen-
tencialoop, deforma que secarga el contador con el valor o.
O tra forma decontrolar el nmero deiteraciones de lasentencia loop sederiva
del uso delaopcinfor 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
quemodela el contador delasiguiente forma:
pr o c e s s
be gi n
Co nt a do r <= O;
f o r 1 inO to 15 l o o p
wa i t unt i l Re l o j =' l ' ;
Co nt a do r <=' Co nt a do r + 1;
end l o o p;
end pr o c e s s ;
Este bucle serepetir mientras la expresin de control (1en 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 dela sentencia loop no necesita ser declarada y puede tomar cualquier
rango devalores detipo discreto (enumerados oenteros).
96 VHDL. Lenguaje estndar de Diseo Electrnico
2.5.7. Lasentencia exit
La sentencia exit est muy relacionada con la sentencia loop, dehecho sunica uti-
lidad es ofrecer una forma determinar laejecucin de un bucle. La sintaxis general
dela sentencia exit es:
[ e t i q u e t a : ] e x i t [ e t i q u e t a _ _ l o o p ] [when c o n d i c i o n . . . , b o o l e a n a ]
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
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 sepasa aejecutar laprimera sentencia que seencuentre acontinua-
cin. La segunda opcin permite especificar la etiqueta de una sentencia loop con-
creta, deforma que el bucle que finaliza su ejecucin como consecuencia dela sen-
tencia exit es aquel que corresponda ala etiqueta especificada. En caso de no indi-
car ninguna etiqueta sesobreentiende que sefinaliza el bucle actual. Como ejemplo
de uso de la sentencia exit podemos modificar nuestro contador mdulo 16de for-
maque tenga una seal deinicializacin (Inicio).
e n t i t y Co n t a d o r _ O_ 1 5 i s
port(
Re l o j , I n i c i o : inb i t ;
Cu e n t a : o u t n a t u r a l ) ;
end Co n t a d o r _ O_ 1 5 ;
a r c h i t e c t u r e E j e mp l o , o f Co n t a d o r _ O~1 5 l s
s i g n a l Co n t a d o r . : n a t u r a l ;
b e g i n
p r o c e s s
b e g i n
Co n t a d o r <= O;
lOp
wa i t u n t i l ( RS l o j i : ' l ' and Re l o j ' e v e n t ) a r I n i c i o =' O' ;
e x i t wh e n i n i c i o =' O' ;
Co n t a d o r <= ( Co n t a d o r + 1 ) m oa 1 6;
end l o o p ;
end p r o c e s s ;
Cu e n t a <= Co n t a d o r ;
end E j e n p l o ;
En este ejemplo, cuando Inicio pase avaler O sesaldr del bucle delasentencia
loop, deforma que seejecutar denuevo lasentencia deinicializacin del contador.
Obsrvese que en la sentencia wait seha especificado explcitamente qu reloj de-
ba ser' l' Y deba tener un evento. Esto sedebe al hecho que al usar laopcin until
especificando diversas condiciones, cada seal que aparece en las distintas condi-
ciones pasa aformar parte de la lista de sensibilidad. De forma que podra darse el
caso que un cambio de 'O' a' l' deInicio coincidiendo con que laseal Reloj valiese
'1' se interpretase como un flanco de reloj por la forma en que seha codificado el
proceso.
2. Presentacin del lenguaje VHDL 97
Para ejemplificar el uso de etiquetas podemos modificar denuevo nuestro con-
tador aadiendo una seal de carga dedatos. Dejamos como ejercicio para el lector
la modificacin de la entidad del contador, en la que debe aadirse dos nuevos
puertos deentrada (Carga yDatos):
process
be gi n
Co nt a do r <= O;
c a r ga _ Da t o s : l o o p
I nc r e me nt o : l o o p
wa i t unt i l ( Re l o j =' 1' aDd Re l o j ' e v e nt )
a r Ca r ga =' 1' a r I ni c i o =' O' ;
e x i t Ca r ga _ Da t o s when I ni c i o =' O' ;
e x i t I nc r e me nt o when Ca r ga =' 1' ;
Co nt a do r <= ( Co nt a do r + 1) mod 16;
e nd l o o p I nc r e me nt o ;
wa i t unt i l Re l o j =' i ' ;
i f Ca r ga =' 1' t he n Co nt do r <= Da t o s ; e nd i f ;
e nd l o o p Ca r ga _ Da t o s ;
e nd process;
En este proceso se han introducido dos bucles anidados, el bucle interno (In-
cremento) es el que modela el incremento del contador acada flanco dereloj, 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 laejecucin del bucle externo cuando seactiva la seal Inicio (acti-
vaabaja), de forma que seejecuta la sentencia Contador <=Ohacindose efectiva
la inicializacin. La segunda sentencia exit termina la ejecucin del bucle interno,
deforma que sepasa aesperar el siguiente flanco dereloj y acargar el contador con
losdatos en caso que laseal decarga siga activa.
Obsrvese que por el orden como sehan especificado las dos sentencias exit, la
seal deInicio tiene prioridad sobre laseal decarga dedatos, adems lainicializa-
cin del contador es asncrona mientras que lacarga dedatos es sncrona (debido al
wait until Reloj= '1' del bucle externo).
2.5.8. Sentencianext
La sentencia next est ntimamente ligada ala sentencia loop. Seutiliza para dete-
ner laejecucin deuna sentencia loop y pasar ala siguiente iteracin de la misma.
Susintaxis general es:
[ e t i que t a : ] ne x t [ e t i que t a _ l o o p] [ whe n c o ndi c i o n_ bo o l e a na J
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
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 aqu sentencia loop debe rea-
98 VHDL. Lenguaje estndar de Diseo Electrnico
lizar ese salto de una iteracin. Para ejemplificar el uso de la sentencia next, pode-
mos modificar nuestro contador mdulo 16deforma que no pase por el valor 8.
process
be gi n
Co nt a d o r <= O
f o r 1 i n O to 1 5 l o o p
next when i =8
Co nt a d o r <= I
wa i t unt i l Re l o j =' l '
e nd l o o p ;
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 seejecuta 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
desalto deiteracin.
2.5.9. Lasentenciaassert
La sentencia assert permite reportar mensajes en funcin de si una determinada
condicin secumple o no, tambin permite interrumpir la simulacin en funcin de
dicha condicin. Su sintaxis general es:
[ e t i q ue t a : 1 assert e x p r e s i o n, _ bo o l e a na [ r e p o r t c a d e na _ c a r a c t e r e s ]
[ e x p r e s i o n_ s e v e r i d a d ]
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
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 sepuede interrumpir la si-
mulacin.
La forma ms simple dela sentencia no usa laopcin dereport ni laopcin de
severidad; en este caso, si no secumple lacondicin el mensaje enviado ala salida
es "Assertion violation", Detodas formas, debido alaescasa informacin que ofre-
ceeste mensaje, lo habitual es aadir laopcin dereport 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 deno especificar el nivel deseveridad, el defecto es error.
2. Presentacin del lenguaje VHDL 99
Un ejemplo tpico del uso de la sentencia assert puede ser lacomprobacin de
tiempos en el modelado de dispositivos secuenciales. El siguiente proceso modela
unbiestable sensible al flanco desubida del reloj, y utiliza una sentencia assert para
comprobar que el tiempo mnimo deanchura depulso del reloj es de5 ns. Para este
ejemplo necesitamos usar la funcin now (definida en el paquete standard) que re-
toma el tiempo actual desimulacin.
pr o c e s s
v a r i a bl e I ni c i Q_ P ul s o : t i me ;
be gi n
c a s e Re l o j is
when '1' =>
q <= d;
I ni c i o _ P ul s o := DOW;
when ' O' =>
a s s e r t ( no w- ! ni c i o _ _P ul s o ) >= 5 na
r e po r t ( pul s o de r e lo) me no r de 5 na")
s e v e r i t y wa r ni ng;
e nd c a s e ;
wa i t o n Re l o j ;
e nd pr o c e s s ;
El proceso es sensible a la seal Reloj; por lo tanto, se activa cada vez que se
produce un evento enReloj. Si seproduce un flanco de subida del Reloj, pasa el da-
to deentrada al contenido del biestable (q <=d) y acontinuacin guarda en la va-
riableInicio_Pulso el tiempo de simulacin en que sehaproducido el flanco de su-
bida. Al producirse el flanco de bajada, comprueba que ladiferencia de tiempo en-
treste (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, seenva el correspondiente mensaje ala salida estndar; para este tipo devio-
lacinsehaescogido warning como nivel deseveridad.
VHDL-93 ofrece una variacin de la sentencia assert: la sentencia reporto Su
sintaxis es:
r e po r t c a de na _ c a r a c t e r e s {e x pr e s i n s e v e r i da d]
Ladiferencia principal con lasentencia 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 auna sentencia assert con lacon-
dicin forzada afalso). Tambin vara el nivel de severidad por defecto, que en la
sentenciareport es note. Por ejemplo, lasiguiente sentencia:
r e po r t " pa s o po r a qui " ,
Produce el mensaje "paso por aqui" cada vez que seejecuta, y es equivalente a:
a s s e r t F AL SE r e po r t " pa s o po r a qui " s e v e r i t y no t e
Por tanto, esta variacin aparece con el nimo de proporcionar una sentencia
quepermita reportar mensajes en la simulacin deforma ms cmoda, en caso que
stos no dependan deninguna condicin.
100 VHDL. Lenguaje estndar de Diseo Electrnico
2.5.10. Llamadasecuencial a subprogramas
Los subprogramas (procedimientos o funciones) que tengamos definidos en alguna
parte del cdigo (tal como seexplica en laseccin 2.7) pueden ser llamados para su
ejecucin en cualquier parte de un cdigo secuencial. La sintaxis de llamada aun
procedimiento (procedure) es:
[etiqueta: 1 nombre_procedimiento [{parametros.} 1;
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
2.5.13. .
La sintaxis dellamada auna funcin (function) es:
nombre_funcion [{parametros} 1
La diferencia radica en que una llamada afuncin forma parte de la expresin
deuna asignacin o es la asignacin en s misma, mientras que la llamada aproce-
dimiento es una sentencia secuencial por s sola.
En ambos casos al ejecutarse la llamada a subprograma, ste pasa aejecutarse
para retornar el control a la siguiente instruccin secuencial en cuanto finalice su
ejecucin.
2.5.11. Lasentencia return
La sentencia return seutiliza para terminar laejecucin deun subprograma. Su sin-
taxis general es:
[etiqueta :J return [expresion};
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
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
estreservada alas funciones.
Al ejecutarse esta sentencia secuencial se retorna el control del programa ala
instruccin siguiente ala que realiz la llamada. Adems, en una funcin esta sen-
tencia seutiliza para retornar el resultado delaejecucin delafuncin.
2.5.12. Lasentencia null
Esta sentencia seusa para indicar que no sedebe realizar ninguna accin. Su sinta-
xis general es:
[etiqueta :J null;
La etiqueta opcional aparece en VHDL-93 y su uso se discute en la seccin
2.5.13.
2. Presentacin del lenguaje VHDL 101
Un ejemplo tpico del uso de la sentencianull aparece en las sentencias case.
Lasintaxis dela sentencia case obliga acubrir todo el rango deposibles valores de
laseleccin, pero en muchos casos no para todo el rango es necesario realizar algu-
naaccin. Pongamos por ejemplo una sentencia case que seutiliza para calcular el
mdulo 2deun determinado valor:
c a s e Va l o r i s
when O I 1=> null;
whe n o t he r s => Va l o r := Va l o r mod 2;
e nd c a s e ;
En caso que Valor valga Oo 1no debe ejecutarse lafuncin mod, yaque Valor
yacontiene 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 alas sentencias secuenciales es la posibili-
daddeespecificar una etiqueta en cualquiera de ellas (las sentencias loop ya tenan
estaposibilidad en VHDL-87).
Estas etiquetas en las sentencias secuenciales aparecen para permitir definir
atributos sobre dichas sentencias, yaque al definir un atributo sobre laetiqueta, ste
quedar asociado alasentencia dedicha 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 serealice (se sintetice) con un deter-
minado recurso. En todo caso, este tipo defacilidades van aser dependientes, dela
herramienta. A efectos de simulacin, el uso de etiquetas en sentencias secuencia-
les no aporta ventajas significativas, aparte de permitir mejorar la documentacin
enalgunos casos.
2.6. SENTENCIAS CONCURRENTES
En los siguientes apartados sepresentarn 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.
102 VHDL. Lenguaje estndar de Diseo Electrnico
2.6.1. Lasentenciaprocess
Un proceso es una sentencia concurrente que define su comportamiento atravs de
sentencias secuenciales. Cualquier sentencia concurrente o secuencial VHDL tiene
su proceso equivalente, dehecho el simulador VHDL slo trabaja con procesos. La
sintaxis general deunproceso es:
[ e t i q u e t a : ] p r o c e s s [ ( n o mb r e _ s e a l ( , . } ) ] [ i s ]
d e c l a r a c i o n e s
begin
s e n t e n c i a s _ s e c u e n c i a l e s ;
end p r o c e s s [ e t i q u e t a ] ;
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 seutiliza
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 atravs 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 sueje-
cucin. La ejecucin del proceso sedetiene (el proceso sesuspende) al ejecutar una
sentencia wait, al mismo tiempo laejecucin delasentencia wait suele fijar las con-
diciones para despertar al proceso y continuar con su ejecucin (fijar aqu seales
es sensible el proceso). Ntese que un proceso que no contenga ninguna sentencia
wait entra en unbucle infinito que impide que avance el tiempo desimulacin.
Aunque en general un proceso puede contener ms deuna sentencia wait, exis-
teuna sintaxis simplificada, que equivale adefinir unproceso con una nica senten-
cia wait como ltima sentencia del mismo. En este caso el proceso no puede conte-
ner ningun:asentencia wait. Por tanto, el proceso que seescribe acontinuacin:
p r o c e s s
begin
s e n t e n c i a s s e c u e n c i a l e s ;
wa i t e n l i s t a d e s e n s i b i l i d a d ;
e n d p r o c e s s ;
es equivalente al siguiente proceso:
p r o c e s B ( l i s t a s e n s i b i l i d a d )
begin
s e n t e n c i a s s e c u e n c i a l e s ;
end p r o c e s s ;
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 ladeclaracin deentidad deunmodelo.
2. Presentacin del lenguaje VHDL 103
2.6.2. Asignacin a seal concurrente
Laasignacin aseal puede darse tambin en el mundo concurrente. En este caso la
asignacin concurrente aseal tiene un proceso equivalente con una asignacin se-
cuencial aseal. Laforma ms sencilla desusintaxis es:
[etiqueta: 1 nombre_seal <= [transportl formaonda:
Laetiqueta 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
formaque sta (seccin 2.5.2) y su principal diferencia radica en que se encuentra
enlas arquiteturas (architecture), en lugar de encontrarse en procesos o subprogra-
mas.
Laasignacin concurrente es sensible alas seales que seencuentren aladere-
chadelaasignacin, o sea, que formen parte delaexpresin que seasigne. De for-
maquelasiguiente asignacin concurrente:
a <= b;
Es equivalente al proceso
process(b)
be gi n
a <= b;
end process;
Aunque en este ejemplo se ha presentado una asignacin muy simple, la asig-
nacin concurrente permite algunas opciones potentes que ledan 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 seestu-
dianenlas siguientes secciones.
La principal diferencia que incorpora VHDL-93 ala asignacin aseal concu-
rrente es que ampla los modelos de retardo. Para ello incluye la palabra reservada
reject (rechaza), que puede usarse como modificador del modelo deretardo inercial
(y no el transporte). Con la opcin de rechazar sepuede especificar para qu valo-
res detiempo (qu anchuras depulso) sedebe 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
Laasignacin concurrente condicional es una forma compacta de expresar las asig-
naciones aseal usando lasentencia if secuencial. Susintaxis es:
[etiqueta :1 nombre_seal <= [transport 1
fforma_onda when expresion_booleana else}
fOIma_onda [when expresion_booleanal;
104 VHDL. Lenguaje estndar de Diseo Electrnico
La etiqueta del proceso es opcional, sirve para identificar al proceso y puede
ser til en las tareas dedepuracin del cdigo.
La sentencia funciona de forma que el valor que se asigna ala seal es el que
seespecifica en lacondicin que secumple. Esta asignacin concurrente seejecuta-
r cada vez que seproduzca un evento en las seales que forman parte de laexpre-
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 unmultiplexor 2-1:
Sa l i da <= E nt r a da l when Se l =' O' e l s e
E nt r a da 2;
Cuyo proceso equivalente es:
pr o c e s s ( Se l , E nt r a da ! , E nt r a da 2)
be gi n
i f Se l =' O' then
Sa l i da <= E nt r a da ! ;
e l s e
Sa l i da <= E nt r a da 2;
end i f ;
e nd pr o c e s s ;
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 deasignacin sincondicin).
Ofrece la posibilidad de no realizar ninguna asignacin en alguna de las op-
ciones, para ello introduce lapalabra 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 delas variaciones introducidas en VHDL-93 alaasignacin aseal 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 aseal usando lasentencia case secuencial. Su sintaxis es:
[ e t i que t a : ] wi t h e x pr e s i o n s e l e c t
na nbr e ~e a l <= [ t r a DSP Or t ]
{f o r ma _ o nda when v a l o r . }
f o r ma _ o nda whe n v a l o r ;
La etiqueta del proceso es opcional, sirve para identificar al proceso y puede
ser til en las tareas dedepuracin del cdigo.
2. Presentacin del lenguaje VHDL 105
La sentencia funciona de forma que la forma de onda que se asigna ala seal
eslaque seespecifica en la opcin correspondiente al valor que toma la expresin
deseleccin. Esta asignacin concurrente seejecutar cada vez que seproduzca un
eventoenlas seales que forman parte delaexpresin deseleccin (expresion) oen
lasseales que forman parte delaexpresin delaasignacin (forma_onda).
Como ejemplo podemos modelar una unidad aritmtica lgica que contiene las
operaciones desumar, restar, and lgica y or lgica:
wi t h Operacion select
result <= Opl + Op2 when suma,
Opl - Op2 when resta,
Opl lUI d Op2 when andl,
Opl or Op2when orl;
El proceso equivalente para esta asignacin es el siguiente:
process (Opl, Op2, Operacion)
be gi n
case Operacion 1s
when suma =>
Result <= ~1 + Q;>,2;
when resta =>
Result <= Opl - Op2;
when andl =>
Result <= Opl lUI d Op2;
when orl =>
Result <= Opl or Op2;
end case;
end process;
La diferencia principal respecto a VHDL-93 consiste en que ste permite usar
laopcin unaffected en la asignacin que sequiera, 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 sobrelas diferencias incorporadas enel VHDL-93 consultar [A95][BFMR93].
2.6.5. Assert concurrente
Lasentencia assert puede darse tambin en el mundo concurrente. En este caso tie-
neunproceso equivalente con una sentencia assert secuencial. La forma ms senci-
lladesu 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 dedepuracin del cdigo. La sentencia assert concurrente es una forma com-
pacta de escribir una sentencia assert secuencial, se comporta de la misma forma
106 VHDL. Lenguaje estndar de Diseo Electrnico
que sta (seccin 2.5.9) y su principal diferencia radica en que se encuentra en las
arquitecturas (architecture), en lugar deencontrarse enprocesos 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 delas
seales que aparezcan en la condicin. De esta forma la siguiente sentencia assert
concurrente:
a s s e r t no t ( s =' 1' aDd r =' l ' )
r e po r t " us o i nc o r r e c t o de l a b s c ul a RS ;
Es equivalente al proceso
pr o c e s s ( r , s )
be gi n
a s s e r t no t ( s =' 1' aDd r =' l ' )
r e po r t " us o i nc o r r e c t o de l a b s c ul a RS ;
e nd pr o c e s s ;
Ntese que ste es un proceso pasivo, que no realiza asignacin alguna aseal
y que, por lo tanto, puede aparecer en laentidad del diseo. Por lo tanto, la senten-
ciaassert concurrente tambin puede aparecer en laentidad 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 seproduzca un evento en alguno desus parmetros deentra-
da.
La sintaxis dellamada aun procedimiento (procedure) es:
[ e t i que t a : 1 no mbr e _ _ pr o c e di mi e nt o [ {pa r a me t r o s , } 1 ;
Laetiqueta es opcional y sirve para identificar lasentencia.
La sintaxis dellamada auna funcin (junction) es:
no mbr e _ f unc i o n [ {pa r a me t r o s } 1
Esta sintaxis es igual ala sintaxis para llamadas secuenciales asubprogramas 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 deprocedimiento 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 deentrada al subprograma.
2. Presentacin del lenguaje VHDL 107
2.6.7. Sentencias estructurales
VHDL proporciona un conjunto de sentencias dedicadas ala descripcin deestruc-
turadel hardware. Son tambin sentencias concurrentes, yaque seejecutan en para-
lelo con cualquier otra sentencia concurrente de la descripcin y aparecen en la ar-
quitectura deun modelo fuera decualquier 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 seusa en cada caso y las posibilidades
degeneralizar 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
Pararealizar ladescripcin estructural deun sistema es necesario conocer qu sub-
sistemas o componentes lo forman, indicando las interconexiones entre ellos. Para
estepropsito VHDL proporciona el concepto decomponente.
Para poder usar un componente VHDL exige que serealicen dos pasos: prime-
ro, debe declararse el componente, despus, yapuede 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 sepueden 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 deun componente es:
COIIilOnentnombre_COIIilOnente [18]
[generic (lista_generic);]
[ p o r t (lista_puertos);]
end ccmponent (nombre_cooponente];
Tanto la partcula is como la repeticin del nombre del componente al final de
ladeclaracin del mismo son opcionales y aparecen enVHDL-93.
Habitualmente al declarar un componente sehar referencia aun diseo desa-
rrollado anteriormente y yacompilado en alguna biblioteca. En este caso ladeclara-
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
ladeclaracin decomponente.
Una vez se ha declarado un componente, ya podemos realizar tantas copias o
referencias al como se quiera. La referencia acomponente 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 aun componente se ejecutar cada vez que se produzca un evento en
108 VHDL. Lenguaje estndar de Diseo Electrnico
alguna de las seales conectadas a sus puertos de entrada o de entrada/salida. La
sintaxis delareferencia acomponentes es:
e t i que t a _ r e f e r e nc i a : no mbr e _ c o mpo ne nt e
[ ge ne r i c map ( l i s t a _ a s o c i a c i 6n) ; 1
[ po r t ma p ( l i s t ~a s o c i a c i 6n) ; J
Al referenciar un componente debemos especificar qu valores queremos dar a
cada uno de sus genricos y qu seales queremos conectar acada uno de sus puer-
tos. Deesta forma queda completamente especificada laestructura que estamos de-
finiendo, ya que habremos indicado qu componentes la forman y cmo seconec-
tan entre ellos. Como ejemplo del uso de componentes, acontinuacin modelamos
un sumador completo de un bit a partir de dos semisumadores de un bit y de una
puerta o r o
e nt i t y Suma do r Co mpl e t o i s
be gi n
po r t ( X, Y , Cl n : inbi t ;
COUt , Sum : oot bi t ; ) ;
end Suma do r Co mpl e t o ;
a r c hi t e c t ur e E s t r uc t ur a o f Suma do r Co mpl e t o i s
canponent Se mi s uma do r
po r t ( I I , 12 : inbi t ;
COut , Sum : o ut bi t ) ;
e nd c a npo ne nt ;
camponent P ue r t a Or
po r t ( 1I , 12: inbi t ;
O : out bi t ) ;
e nd camponent;
s i gna ! A, B, C : bi t ;
be gi n
VI : Se mi s uma do r po r t ma p ( X, Y , A, B) ;
U2 : ' Se mi s uma do r po r t ma p ( B, crn, C, Sum);
V3 : P ue r t a Or po r t ma p ( A, C, COut ) ;
end E s t r uc t ur a ;
Esta descripcin VHDL refleja exactamente laFigura 2-9:
U1
U3
X
S
8--
co
"'
y
ss
I e
S S
Cln
S um
U2
FIGURA 2-9. Esquema lgico equivalente a la descripcin VHDL.
2. Presentacin del lenguaje VHOL 109
Existen dos formas deasociar los puertos locales (los que aparecen en ladecla-
racin del componente) con los puertos actuales (aquellos que aparecen en cada co-
piadeuncomponente).
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 laposi-
cinenque aparece. Por ejemplo, lainstancia U 1 del semi sumador conecta el puer-
toX del sumador alaentrada Il del semi sumador, yaque aparece en laprimera po-
sicinen lalistadepuertos del componente.
La segunda forma es ms explcita y proporciona ms informacin. Se asocia
cadapuerto actual con supuerto local especificando los nombres deambos. Si repe-
timos lareferencia U2 del ejemplo anterior con laasociacin por nombre tenemos:
U2 : semi sumador port map(Il=>B, 12=>Cln, Cout=>C, SUrn=>Sum);
Usando esta nomenclatura podemos especificar laasociacin depuertos defor-
maindependiente al orden que stos ocupan en la declaracin del componente. De
estaforma lasiguiente referencia:
U2 : semi sumador port map(COut =>C. I1=>B, 12=>Cln, COut=>Cl;
esequivalente alaanterior.
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 alos componentes es que
sepermite referenciar un componente sin necesidad dehaberlo declarado con ante-
rioridad, lasintaxis dereferencia acomponente en este caso es:
etiqueta_referencia :
entity nombre_entidad !(nombre_:'arqui tectura I 1
[generic map (lista generlcos);)
[ port map (lista puerto's) ;]
La arquitectura de nuestro ejemplo del sumador completo puede escribirse de
lasiguiente forma:
architecture Estructura of SumadorCampleto is
signal a, b, c : b i t ;
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 alabiblioteca work porque suponemos que es
ensta donde encontramos compiladas las entidades que referenciamos. Obsrvese
queen este ejemplo no sehahecho referencia aninguna arquitectura, por tanto sta
110 VHDL. Lenguaje estndar de Diseo Electrnico
seespecificar va configuracin (configuraton), si no queremos usar laconfigura-
cin, VHDL-93 permite especificar laarquitectura autilizar en la misma referencia
al componente. Deesta forma podemos escribir:
U1 e nt i t y wo r k . Se mi s uma do r ( F unc i o na l ) port ma p ( X, Y , A, Bl ;
02 e nt i t y wo r k . Se mi s uma do r ( Es t r uc t ur a l ) port ma p (B. C, I n, e, $.Un);
U3 e nt i t y wo r k . P ue r t a Or ( L o gi c a ) port ma p (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 generate
Una forma habitual dedescribir estructura en el hardware es larealizacin deml-
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 sebasen en larepeticin de la misma estructura: la sentencia
generate. La sintaxis bsica delasentencia generate es:
e t i que t a _ ge ne r a t e : {[ f o r e s pe c i f i c a c i o n_ f o r I i f c o ndi c i o n] l ge ne r a t e
{s e nt e nc i a s c o nc ur r e nt e s }
end ge ne r a t e ;
La etiqueta es obligatoria y seusa 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 Ncopias del mismo componente, o sea, el mecanismo dege-
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 deNbiestables tipo D, en este caso podramos usar el siguiente cdigo:
e nt i t y Re gi s t r o is
ge ne r i c ( N : po s i t i v e ) ;
port(
Re l o j : in bi t ;
Ent r a da : in bi t _ v e c t o r ( O t o N- l ) i
Sa l i da : o ut bi t _ v e c t o r ( O t o N-U);
end Re gi s t r o ;
a r c hi t e c t ur e Es t r uc t ur a o f Re gi s t r o 18
c a mpo ne nt DF F
port ( Re l o j , D: in bi t ; Q: o ut bi t ) ;
e nd c CI I ) One nt ;
be gi n
2. Presentacin del lenguaje VHDL 111
Ge ne r a Ee gi s t r o : f o r 1 inO toN- 1 ge ne r a t e
Re g : DF F po r t ma p ( Re l o j , Ent r a da ( 1) , Sa l i da ( l ) ) ;
end ge ne r a t e ;
end Es t r uc t ur a ;
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
acada 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
16bits, se puede hacer una copia a componente de la siguiente forma:
Re gi s t r o _ 16 : Re gi s t r o ge ne r i c ma p ( 16) ;
po r t ma p ( Re l o j , Ent r a da , Sa l i da ) ;
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:
e nt i t y Re gi s t r o De s pl a z a mi e nt o i s
ge ne r i c ( N : po s i t i v e ) ;
po r t (
Re l o j : inbi t ;
SI n: inbi t ;
SOut : o ut bi t ) ;
end Re gi s t r o De s pl a z a mi e nt o ;
a r c hi t e c t ur e Es t r uc t ur a of Re gi s t r o De s pl a z me nt o i s
c o n l One nt DFF
po r t ( Re l o j , D: inbi t ; Q: o ut bi t ) ;
e nd COl l P <) I l e ! l t ;
s i gna l X : bi t _ v e c t o r ( O t O N- 7) ;
be gi n
Ge ne r a Re gi s t r o : f o r 1 inO O' N- 1 ge ne r a t e
61: i f ( 1=0) ge ne r a t e
CI z q: DF F po r t ma p( Re l o j , SI n, X( I ) ) ; e nd ge ne r a t e ;
62: i f ( ( 1>0) and ( I <N- 1) ) ge ne r a t e
CCe n: DF F po r t ma p( Re l o j , X( I - 1) , X( I ) ) ; e nd ge ne r a t e ;
63: i f ( I ~N- 1) ge ne r a t e
CDe t : DF F po r t ma p ( Re : j ' L ' X (I:":1); SOt i t ) ; e nd ge ne r a t e ;
end ge ne r a t e ;
end Es t r uc t ur a ;
112 VHDL. Lenguaje estndar de Diseo Electrnico
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:
e t i q u e t a _ g e n e r a t e : { l f a r e s p e c i f i c a c i o n f o r I i f c o n d i c i o n ] l g e n e r a t e
[ { p a r t e d e c l a r a t i v a } . . . . . ~
beginl
{ s e n t e n c i a s c o n c u r r e n t e s }
e n d g e n e r a t e ;
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:
f o r ( r e f _ c o mp o n e n t e { , . . } I o t b e r s I al1) i d . . . c o o p o n e n t e
u s e e n t i t y i d _ e n t i d a d l ( i d _ a r q u i t e c t u r a ) ;
u s e c o n f i g u r a t i o n i d . . . c o n f i g u r a c i n ; ]
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:
2. Presentacin del lenguaje VHOL 113
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 por t 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 seespecifica que para el componente U3 del tipo PuertaOr se usar su arqui-
tecturaLogica.
La especificacin de configuracin puede aparecer en la parte declarativa de
unaarquitectura otambin en laparte declarativa deuna sentencia block. Puede ser
tansimple corno laque sehavisto en este ejemplo, en el cual nicamente seespeci-
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 denuestro sumador completo, variando su configuracin dela siguiente for-
ma:
architecture Estructura of S~dorCampleto is
declaracin componente semisuriador
camponent PuertaOr
por t ( 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
U2
U3
Semisumador port map (X, Y , A; Bl;
Semisumador port map (A, Cln, e, Sum);
PuertaOr port map (I1=>A, I2=>O, O=>OOut);
end estructura;
En este ejemplo seespecifica que para todos los componentes PuertaOr (puer-
taor lgica de dos entradas) debe usarse el componente que seencuentra en la bi-
blioteca Puertas que se llama PuertaOr3 (puerta or lgica de tres entradas) y usar
suarquitectura Logica. Y aque el componente elegido difiere en el nmero deentra-
das, se usa la Clusulaport map en la especificacin de configuracin para indicar
que latercera entrada delapuerta or detres entradas debe estar fijada a 'O', dema-
114 VHDL. Lenguaje estndar de Diseo Electrnico
nera que seaequivalente auna puerta or dedos entradas. Tambin seindica quedos
delos puertos delaPuertaOr3 (A yB) deben conectarse alas dos entradas del com-
ponente PuertaOr (/1y 12). Mientras que la salida del componente PuertaOr3 (Y )
debe conectarse ala salida del componente PuertaOr (O). Ntese que en el mapeo
denuestro ejemplo sehausado sintaxis VHDL-93, yaque para fijar unpuerto al ni-
vellgico 'O' seha asignado directamente el valor 'O' al puerto. En VHDL-87 de-
bera definirse una seal fijada aeste 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 aveces sehadicho que el mecanismo dere-
ferencia a un componente equivale a elegir el zcalo de un componente, mientras
que laconfiguracin del componente escoge qu dispositivo secoloca en el zcalo.
Como ya hemos dicho, la configuracin puede ser usada como una unidad de
diseo independiente, en ese caso selellama declaracin deconfiguracin y su sin-
taxis es unpoco distinta: '
c o n f i g u r a t i o n i d e n t i f i c a d o r of i d e n t i f i c a d o r _ e n t i d a d i s
f o r i d e n t i f i c a d o r _ a r q u i t e c t u r a
{ f o r ( r e f _ c o mp b n e n t e { , . . } I o t h e r s I all) i d . . _ c o r r p o n e n t e
u s e e n t i t y i d _ e n t i d a d ! ( i d _ a r q u i t e c t u r a ) ;
u s e c o n f i g u r a t i o n i d _ c o n f i g u r a c i n ; ]
e n d f o r ; )
e n d f o r ;
end [ c o n f i g u r a t i o n ] [ i d e n t i f i c a d o r ] ;
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 lasiguiente con-
figuracin:
c o n f i g u r a t i o n P r i me r a of S Uma d o r Ca mp l e t o i s
f o r E s t r u c t u r a
f e r Ul : S e mi s u ma d o r u s e
e n t i t y wo r k . S e mi s u ma d o r ( E s ~~c t u r a l ) ; e n d f o r ;
f o r o t h e r s : S e mi s u ma d o r
u s e c o n f i g u r a t i o n wo r k . F u n c i o n a l ; end f o r ;
f o r a l l : P u e r t a Or
u s e e n t i t y P u e r t a s . P u e r t a Or 3 { L o g i c a ) ;
port map(A=>I1, B=>I2, C=>'Q', 1'=>0); e n d f o r ;
end f o r ;
end P r i me r a ;
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 unidentificador delaconfiguracin (enestecaso Primera) quesirveparare-
ferenciar a dicha configuracin, por ejemplo, desde configuraciones de niveles ms
altos delajerarqua. Debe especificarse qu arquitectura dequentidad seestconfi-
gurando, enestecaso seindica que seestconfigurando laarquitectura Estructura de
laentidad SumadorCompleto y que el nombre dedicha configuracin serPrimera.
2. Presentacin del lenguaje VHDL 115
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 delaarquitectura en ladeclaracin deconfiguracin, quizs alguno delos
componentes ya seconfigur en el cdigo de la misma arquitectura, o quizs algu-
noquiera configurarse desde otra declaracin deconfiguracin del diseo. En nues-
tro ejemplo s que sehan configurado todos los componentes de lasiguiente forma:
Para el componente Ul, que es un Semisumador, seespecifica que debe usarse
laentidad 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 labiblioteca indicada. Por lo tanto, si consideramos que para la entidad Semisu-
mador la ltima arquitectura que seha analizado es la Estructural, y que ambas se
encuentran en la biblioteca work. Entonces podemos escribir laconfiguracin de la
referencia U1 desemisumador delasiguiente forma:
for Ul : Semisumador use entity work.Semisumador; end for;
Para el resto dereferencias acomponente Semisumador (others) debe usarse la
configuracin llamada funcional, que tambin se encuentra en la biblioteca work.
En dichaconfiguracin sehabr indicado qu arquitectura usar para el componente
Semisumador, por ejemplo esta configuracin podra ser delasiguiente 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 lajerarqua del diseo atravs dedistintas declaraciones deconfiguracin, 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 detodo el diseo en una nica declaracin deconfiguracin.
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 delamisma debe fijarse a 'O' para que secomporte como una puerta or
dedos entradas.
Todas las cuestiones explicadas hasta aqu para configuracin de componentes
son innecesarias si seusa lareferencia acomponente deVHDL-93, en la cual pue-
dehacerse una copia acomponente sin haberlo declarado previamente y en la cual
puede especificarse la entidad y arquitectura ausar en la misma referencia copia a
componente. Si escribimos la arquitectura del sumador completo de la seccin
2.6.7.1 delasiguiente forma:
116 VHDL. Lenguaje estndar de Diseo Electrnico
a r c hi t e c t ur e E s t r uc t ur a of Suma do r Ca mpl e t o i s
s i gna l a, b, c : bi t ;
begin
Ul e nt i t y wo r k . Se mi s uma do r ( Co mpo r t a mi e nt o )
port map (X,.Y, a, bl; ....
U2 e nt i t y wo r k . Se mi s uma do r ( E s t r uc t ur a l r .
port m ap (B, CIn, C, SUm); .
U3 e nt i t y P ue r t a s . P ue r t a Or 3( L o gi c a l
port m ap (A=>A, B=>C, c=> '0', =>COut l ;
end e s t r uc t ur a ;
Estamos indicando que parael componente U1 debe usar el Semisumador con
su arquitectura Comportamiento, parael componente U2 debe usar el Semisumador
con su arquitectura Estructural y parael componente U3 debe usar el componente
PuertaOrJ que seencuentra en labiblioteca Puertas, y debe fijar su puerto de en-
tradaC al valor 'O' .
Otradiferencia que incorpora VHDL-93 es laposibilidad deconfiguracin in-
cremental de una componente. Mientras en VHDL-87 solamente puede haber una
especificacin de configuracin ouna definicin de configuracin, en VHDL-93
pueden existir ambas configuraciones paraun mismo componente. En ese casode-
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 laposibilidad de generalizar un modelo, aadiendo unos parmetros lla-
mados genricos (generics) en ladefinicin de laentidad del modelo. Cuando el
modelo es usado como un componente el usuario fijael valor que deben tomar los
genricos, de forma que adapta el diseo del modelo genrico asus necesidades
concretas.
Si queremos desarrollar un modelo genrico, debemos incluir en laentidad del
mismo laclusulageneric, enellaseindicarn cules sonlos parmetros genricos
del modelo.
Como ejemplo vamos amodelar unapuerta or con tres parmetros genricos.
El primero indica el tiempo de propagacin intrnseco de lapuerta (aquel que no
depende de lacargaalasalidade lapuerta). El segundo indica el retardo debido a
lacarga(lacapacidad queatacalasalidadelapuerta). El terceroindicalacargaala
salida de lapuerta. Adems, las entradas de lapuerta se modelan con un nico
puerto que es un vector norestringido. De forma que el nmero de entradas que
tengalapuerta sefijar al hacer unacopiaoreferencia al componente, y depender
deladimensin del vector queseconecte asupuertodeentrada.
Con estos genricos sepretende quepodamos modificar los parmetros usados
enel clculo deretardos delapuerta, dependiendo del nmero deentradas destay
delacargaquedebaatacar lasalidadelamisma.
2. Presentacin del lenguaje VHDL 117
e n t i t y ORN 1&
g e n e r i c ( Re t l n e r t i me : = 1 ns;
Re t Ca r t i me : = 0 . 2 n s ;
Ca r g a r e a l : = 0 . 2 5 f ;
port ( E n t r a d a s inb i t _ v e c t o r ; .
S a l i d a : o u t b i t ) ;
end ORN;
a r c h i t e c t u r e F u n c i o n a l o f ORN i s
b e g i n
p r o c e s s ( E n t r a d a s }
v a r i a b l e Re s u l t a d o : b i t : = '0';
b e g i n
f o r i ine n t r a d a s ' r a n g e l o o p
i f E n t r a d a s ( i ) =' 1 ' t h e n
Re s u l t a d o : =' 1 ' ;
exit;
end i f ;
end loop;
S a l i d a <= Re s u l t a d o a f t e r ( Re t l n e r +( Re t Ca r * c a r g a ) ) ;
end p r o c e s B;
end F u n c i o n a l ;
Una vez definido este modelo, podemos hacer referencias ocopias del mismo
utilizndolo comocomponente, encada copia deberemos especificar qu valor con-
cretoqueremos darle alos parmetros genricos. Por ejemplo, si enuna referencia a
componente escribimos:
P u e r t a Or : ORN g e n e r i c ma p ( 2 ns, O. 4 n s , 0.5)
p o r t ma p ( Ve c t E n t , S a l i d a ) ;
estamos configurando nuestra puerta or genrica de forma que sus parmetros de
retardosean2nsy 0.4 nsrespectivamente, y lacarga asu salida seade0.5.
Al dar valores concretos a un mdulo con genricos cuando es usado como
componente, debe usarse laclusula generic map. sta sigue unconjunto dereglas
bsicas que enunciamos acontinuacin:
Los valores que se asignan acada genrico deben ser constantes oexpresio-
nes.
Puede usarse asociacin posicional opor nombre ouna mezcla de ambas
(igual que enlasclsulasport map).
Sepuede omitir el valor aasignar acualquier genrico si ste tiene valor pre-
definido.
Puede explicitarse que quiere usarse el valor por defecto si seasigna lapala-
bra reservada open.
Deesta manera lasiguiente referencia acomponente:
P u e r t a Or : ORN g e n e r i c ma p ( Re t l n e r => 2 n s , Re t Ca r => 0.4 n s , Ca r g a => 0.51
p o r t ma p ( Ve c t E n t , S a l i d a ) ;
118 VHDL. Lenguaje estndar de Diseo Electrnico
es equivalente ala anterior. Siguiendo con nuestro ejemplo de puerta genrica, las
siguientes copias decomponentes:
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 detiempo de 1ns 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 lasiguiente:
- etiqueta: block lexpres ionguarda] H8)
[generic (lista._genericos); '",,' _,,' _' I ,J.,
[generie .map (lista_asociaci6ri_:genrip~JAHr
[part (llsta_puertos); . ... , , .
[part map (Lsta asocecon puertospr1)
{parte declarativa} ,_,
begi n
{sentencias concurrentes}
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 ausar asignaciones guardadas y no si usamos
el bloque con objeto departicionar uorganizar el cdigo.
Vamos a analizar por separado cada uno de los tres usos que hemos apuntado
que puede darse alasentencia block.
Puede usarse para agrupar el cdigo de una arquitectura en diferentes bloques,
para ello ofrece laposibilidad deincluir declaraciones locales acada grupo. El tipo
dedeclaraciones que pueden aparecer en laparte declarativa deuna sentencia block
son las mismas que pueden aparecer en laparte declarativa deuna 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 unbloque cualquier objeto declarado en laarquitectura
que contiene adicho bloque.
Tal como hemos indicado en su sintaxis, la sentencia block puede contener de-
claraciones depuertos y de genricos, por lo tanto puede usarse para describir jerar-
2. Presentacin del lenguaje VHDL 119
qua. Dehecho, lasentenciablock es alaestructuracin loque lasentenciaprocess es
alasimulacin. O sea, cualquier otra forma deestructuracin que seuse en una des-
cripcinVHDL es finalmente convertida alas sentencias block equivalentes. En con-
creto, la referencia o copia a componente que es la construccin bsica de VHDL
usadaparadescribir jerarqua seconvierte endos sentencias block anidadas [LSU89].
Por ltimo, una sentencia block puede tener una condicin deguarda, que debe
ser una expresin booleana que aparezca inmediatamente despus de la palabra re-
servadablock. Esta expresin crea deforma automtica una seal booleana llamada
guard, la cual puede usarse para controlar el comportamiento o ejecucin de las
asignaciones aseal contenidas en el bloque. Si en el bloque aparecen asignaciones
aseal que contengan la palabra clave guarded, stas solamente se realizarn si la
condicin deguarda es verdadera (la seal guard es TRUE). Por ejemplo, podemos
modelar unbiestable sensible aflanco dereloj delasiguiente forma:
Bi e s t a bl e : bl o c k ( Re l o j =' l ' a nd no t Re l o j ' s t a bl e )
be gi n
Q <= guardad D;
end bl o c k Bi e s t a bl e ;
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 seproduzca un flanco desubida dereloj.
De todos los usos de la sentencia block que aqu hemos descrito, el ms fre-
cuentees el delas asignaciones guardadas, algunas veces seusapara encapsular c-
digoy raras veces (al menos desde el punto devista del usuario) seusa para descri-
birjerarqua.
2.7. SUBPROGRAMAS
Los subprogramas seusan 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 serealicen sobre los datos.
Otra caracterstica de un subprograma es su lista de parmetros, esto es, una
listaque seusa para especificar sobre qu datos externos al subprograma debe im-
plementar sufuncionalidad en el momento en que ste sellama para que seejecute.
Losparmetros que aparecen en ladefinicin deun subprograma sellaman parme-
tros formales, mientras que los parmetros que aparecen en las llamadas a subpro-
gramas sonlos parmetros actuales.
Un subprograma se usa para agrupar cdigo, de forma que cada vez que deba
utilizarse podamos especificar sobre qu conjunto dedatos 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
uncdigo estructurado.
Los subprogramas constan de dos partes: la definicin del subprograma y la
definicin del cuerpo del subprograma. En ladefinicin deun subprograma sedefi-
120 VHDL. Lenguaje estndar de Diseo Electrnico
ne el nombre de ste y su lista de parmetros. La definicin de un subprograma es
opcional y puede encontrarse en una declaracin depaquete, en el cuerpo deunpa-
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 ladefinicin delas estructuras dedatos locales aste 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 unproceso oen el cuerpo deotro subprograma
VHDL ofrece dos tipos de subprogramas que apesar de tener muchas caracte-
rsticas en comn tambin presentan importantes diferencias, por lo tanto los vamos
aestudiar por separado.
2.7.1. Funciones
Las funciones estn orientadas arealizar 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 ladefinicin deuna funcin es:
f u n c t i o n n o mb r e _ f u n c i p I l . ! , ( J i s t a _ p a r a me t r o s ) ] r e t u r o t i W. , . . . r ~t q mo
La sintaxis deladefinicin del cuerpo deuna funcin es:
[pure I i mp u r e ] f u n c t i o n n a mb r e _ f u n c i o n [ ( l i s t a _ p a r a me t r o s ) ]
r e t u r o t i p o _ r e t o r n o i a
{ p a r t e _ d e c l a r a t i v a }
b e gi n
{ s e n t e n c i a s s e c u e n c i a l e s }
end [ i u n c t i o n ] [ n o mb r e _ f u n c i o n ]
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 eimpuras 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 seasume que sonconstantes.
En la parte declarativa de las funciones se pueden declarar todas aquellas es-
tructuras dedatos que serequieran (tipos, subtipos, constantes y variables), pero s-
tas solamente existirn cuando la funcin est activa, y secrearn einicializarn de
nuevo cada vez que sta sea llamada: Por este motivo no sepueden declarar seales
en laparte declarativa.
2. Presentacin del lenguaje VHDL 121
La parte declarativa de una funcin tambin puede contener definiciones de
subprogramas; stos, al igual que cualquier tipo dedatos que sehaya declarado, se-
rnlocales alafuncin y, por lo tanto, invisibles fuera deella.
En las sentencias secuenciales que se encuentran en la parte de sentencias de
unafuncin siempre debe haber al menos una sentencia retum. Esta sentencia ser
laque retomar el nico valor que una funcin puede devolver como resultado de
suejecucin.
En la parte de sentencias de una funcin no sepuede modificar (no se pueden
realizar asignaciones) variables o seales externas a la funcin, aunque s puede
usarsepara formar parte deexpresiones utilizadas en lafuncin. En laparte de sen-
tencias deuna 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) seralasiguiente:
function bv_to_natural (S: bit_vect;ar(O to 7)) return natural.:
Ladeclaracin del cuerpo delafuncin sera:
function bv_to_natural (S: bit_vector{O to 7)) return natural is
variable Resultado: natural :=O,
begi n
for 1 in O to 7 loop
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 lallamada afuncin secuencial o lallamada afuncin concurrente. En
ambos casos la llamada a funcin no ser en s misma una sentencia sino que for-
marparte deuna expresin. Por ejemplo:
process
variable Entrada: bit_vector(O'to''1);
variable Salida : natural
begi n
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 afuncin el paso delos parmetros actuales se
hahecho por posicin, pero puede hacerse tambin por nombre (deforma anloga a
lacopia oreferencia acomponente). Con lo cual lallamada afuncin podra expre-
sarsecomo:
122 VHDL. Lenguaje estndar de Diseo Electrnico
salida :=bv_tO.J J atural (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 alos que pueden acceder.
La sintaxis para ladefinicin deunprocedimiento es:
pr o c e dur e no mbr e _ pr o c e di mi e nt o [ ( l i s t a _ pa r a me t r o s ) ]
La sintaxis deladefinicin del cuerpo deunprocedimiento es:
pr o c e dur e no mbr e _ pr o c e di mi e nt o ~Hl i s t a _ pa r a me t r o s ) ] i a
{pa r t e _ de c l a r a t i v a }
be gi n
{s e nt e nc i a s s e c ue nc i a l e s }
end [ pr o c e dur e ] [ no mbr e _ pr o c e di mi e nt o l
La partcula opcional procedure al final de la definicin es propia de VHDL-
93y sunico inters es mejorar lalegibilidad 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 delos parmetros formales son constantes, variables y seales.
Por defecto, los parmetros detipo in seconsideran constantes, mientras que los de
tipo out einout seconsideran 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 laparte declarativa delos 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 secrearn einicializarn de nuevo cada vez que sta sea llamada. Por este
motivo no sepueden declarar seales en laparte declarativa
La parte declarativa de un procedimiento tambin puede contener definiciones
de subprogramas; stos, al igual que cualquier tipo de datos que sehaya declarado,
sern locales al procedimiento y, por lo tanto, invisibles fuera del.
Un procedimiento retomar el flujo del programa al lugar donde fue llamado al
llegar al final del mismo (asu sentencia end). Como puede haber ocasiones en que
2. Presentacin del lenguaje VHDL 123
queramos salir deun procedimiento antes de llegar asu final, sepuede usar la sen-
tenciareturn. La sentencia return en unprocedimiento seusa sinir acompaada de
ninguna expresin e indica que debe devolverse el control del programa al punto
dellamada.
La parte de sentencias de un procedimiento puede modificar (realizar asigna-
ciones) avariables o seales externas al procedimiento. En las sentencias deunpro-
cedimiento pueden aparecer sentencias wait.
En el siguiente ejemplo mostramos unprocedimiento 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);
Ladeclaracin del cuerpo del procedimiento sera:
procedure bv_to_natural(S: bit_vector(O to 7) ;
" X: out natural} la
variable Resultado: natural :=O; .
begi n
for 1 inOto 7 loop
Resultado :=Resultado * 2 + bit'pos(s(i;
end loop;
x :=Resultado;
end procedure bv_to_natural;
Observemos que sehan definido dos parmetros, uno de entrada (por defecto)
y otro desalida, que debe explicitarse y que seasume que es detipo variable.
Una vez definido este procedimiento puede llamarse desde cualquier parte del
modelo usando bien la llamada aprocedimiento secuencial o la llamada aprocedi-
miento concurrente. Por ejemplo:
process
variable Entrada.:. bit_vctorJO te ?);
variable saHaa): natUraL
begi n
bv_to_natural (Entrada, Salida);
end process;
Observemos que a diferencia de la llamada a funcin, la llamada a procedi-
miento es por s solauna sentencia.
Tambin al igual que para la llamada afuncin, en la llamada aprocedimiento
la definicin de los parmetros actuales puede hacerse por posicin o por nombre.
Eneste caso lallamada aprocedimiento seescribe como:
bv_to_natural (S=>Entrada, x=>Salida);
La diferencia en la forma de especificar los parmetros actuales slo tiene im-
portancia para lalegibilidad del cdigo.
124 VHDL. Lenguaje estndar de Diseo Electrnico
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 deun 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 delas funciones.
La sobrecarga mejora lalegibilidad del cdigo al permitir dar el mismo nombre
ados 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-
bredefuncin:
f unc t i o n Co nc a t e na ( a : s t r i ng b: s t r i ngl r e t ur n s t r i ng
f unc t i o n Co nc a t e na ( a : c ha r a c t e r b: s t r i ng) r e t ur n s t r i ng
f unc t i o n Co nc a t e na ( a : s t r i ng b: c ha r a c t e r ) r e t ur n s t r i ng
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 deconcatenacin seacce-
deran respectivamente con las siguientes llamadas:
Ca de na :=Co nc a t e na ( Ma bc de " , ' f ghi j " )
Ca de na :=Co nc a t e na ( Ma bc de f ghi " , ' j ' l
Ca de na :=Co nc a t e na ( ' a ' , " bc de f ghi j " ) ;
En caso de no ser posible determinar el subprograma que se debe ejecutar se
producir un error decompilacin. Por ejemplo, la siguiente llamada fallar porque
lafuncin Concatena no sepuede llamar con dos valores detipo carcter:
Ca de na :=Co nc a t e na ( ' a ' , ' b' ) ;
Tambin es posible que al realizar una llamada aun subprograma exista ms de
un candidato aser ejecutado, en este caso tambin seproducir un error de compi-
lacin. Por ejemplo, se pueden definir procedimientos que desplacen un vector de
bits un nmero deposiciones aladerecha, deforma que este nmero deposiciones
adesplazar pueda especificarse mediante unentero oun vector debits:
pr o c e dur e De s pDe r e c ha ( Ve c t o r : i no ut bi t _ v e c t o r
P o s : bi t _ v e c t o r :=b" 0001" ) ;
pr o c e dur e De s pDe r e c ha ( Ve c t o r : i no ut bi t _ v e c t o r P o s : i nt e ge r :=1) ;
Como seveen el ejemplo, sepueden asignar valores por defecto alos parme-
tros deun subprograma para permitir llamadas donde slo seespecifiquen estos pa-
rmetros en caso que difieran del valor que tienen por defecto. De este modo, la si-
guiente llamada al procedimiento
De s pDe r e c ha ( " 11001010" ) ;
producira un error de compilacin, ya que los dos procedimientos llamados Desp-
Derecha seran candidatos aser ejecutados.
2. Presentacin del lenguaje VHOL 125
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 setienen en cuenta ala 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 deuna declaracin:
f u n c t i o n Co n c a t e n a ( a : s t r i n g ; b : s t r i n g ) r e t u r n s t r i n g ;
f u n c t i o n Co n c a t e n a ( e : s t r i n g ; d : s t r i n g ) r e t u r n s t r i n g ;
Un caso especial desobrecarga seproduce en los operadores, que dehecho son
una clase de funciones que pueden llamarse siguiendo una notacin diferente a la
tradicional. La mayora deoperadores predefinidos en el lenguaje estn sobrecarga-
dospara poder ser utilizados con diferentes tipos dedatos; as, por ejemplo, el ope-
rador "+" puede aplicarse a cualquier tipo numrico entero, real o fsico. Adems
delasobrecarga 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 lafuncin que seest definiendo es un operador escribiendo su nombre
entrecomillas. Deeste modo, sepodran redefinir los operadores "+"yand sobre el
tipoMiTipo:
f u n c t i o n " +0 ( a : Mi T i p o ; b : Mi T i p o ) r e t u r n Mi T i p o ;
f u n c t i o n "andO ( a : Mi T i p o ; b : Mi T i p o ) r e t u r n Mi T i p o ;
Para hacer una llamada aestas funciones sepodr utilizar lanotacin propia de
losoperadores:
Va r 3 :=Va r l + Va r 2 ;
Va r 4 :=Va r l and Va r 2 ;
obien lanotacin propia delas llamadas afunciones:
Va r 3 :=" +" ( Va r l , Va r 2 ) ;
Va r 4 :="andO ( Va r l , Va r 2 1 ;
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
demltiples 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 deresolucin (resolution function) asociada que determine el valor que deben
contener en todo momento. La posibilidad dedisponer dems deuna fuente hace a
estetipo deseales muy adecuadas para el modelado debuses.
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 aesta funcin
cada vez que serealiza una asignacin sobre la seal, en este momento sedetermi-
nael nmero de elementos del vector de entrada a la funcin, que ser igual al n-
mero defuentes que tenga la seal. Las fuentes deuna seal vendrn determinadas
126 VHDL. Lenguaje estndar de Diseo Electrnico
tanto por las sentencias de asignacin en diferentes procesos como por las salidas
decomponentes conectadas adicha 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 sedefinira el tipo vector deXOIZ necesario para el parmetro de entrada
delafuncin deresolucin:
type X01Zls ('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 deresolucin al resto de informacin requerida en ladeclaracin.
De este modo, cada vez que serealice una asignacin sobre la seal sellamar ala
funcin de resolucin para que decida el valor que sedebe asignar. Por ejemplo, se
podra crear una seal de lectura y escritura de una memoria compartida por varios
procesadores delasiguiente forma:
signal LectEscRAM: Resolucion X01Z,
Tambin pueden introducirse seales resueltas declarando un subtipo de datos
resuelto, es decir, un subtipo al que sele 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 lamisma funcin debe utilizar-
separa diferentes seales resueltas. La declaracin anterior delaseal LectEscRAM
siguiendo este mtodo sera:
subtype X01ZResuelto isResolucion X01Z;
signal LectEscRAM: X01Z_Resuelto;
Finalmente, el cuerpo de la funcin de resolucin debe decidir qu valor se
asigna ala seal resuelta dependiendo delos valores detodas 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
serael siguiente:
function Resolu~ (F'1tf3Il;es;.X01Z":vector) return X01Zia
variable Valor: XOIZ:='z',;
begi n
for Indice inFuentes'range loop
case Fuentes(Indice) is
when 'O' => i f Valor ='Z' or Valor ='0' then
Valor ~='O';
2. Presentacin del lenguaje VHOL 127
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
whenothers => null;
end case;
end loop;
retum Valor;
end Resolucion;
Aunque el uso ms comn de las seales resueltas seproduce 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 aotros 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 ala 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 alavez sin permitir el acceso aslo 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 isresolved 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 sehace 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-
128 VHDL. Lenguaje estndar de Diseo Electrnico
dentalmente tienen ms deuna fuente no sedetectan en tiempo decompilacin, ha-
.bindose de detectar en tiempo de simulacin cuando una seal tiene un valor des-
conocido enun momento en que no debera tenerlo.
2.8. EJERCICIOS
1. Cules delos siguientes identificadores son correctos?
Va r i a b l e _ 3
_ 3 Va r i a b l e
Va r i a b l e
Va r i a b l e $ 3
E s t e _ i d e n t i f i c a d o r _ e s _ b a s t a n t e _ l a r g o
3 Va r i a b l e
V A RI A BL E
v a r i _ a b l e
2. Determine el valor decimal delos siguientes literales numricos:
- 2 3 _ 1 1
4 . 3 e 2
7 i 6 5 _ 2 1
1 6 #A3 #e 3
- 4 . 2 . : _ 1 2 E 2
2 #1 1 1 0 _ 1 0 0 1 _ 1 0 0 0 _ 1 0 1 0 i
1 6 i E 9 A#e - 3 . 2
3. Defina los siguientes tipos dedatos:
a) Un tipo entero que contenga los nmeros comprendidos entre 1y 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 de5elementos del tipo registro definido en d).
f) El tipo fsico peso que incluya el miligramo, el gramo, el kilogramo y lato-
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 deelementos del tipo XZ01.
i) El tipo cadena decaracteres (vector no restringido decaracteres).
j) Un tipo matriz tridimensional dedimensin 2x 3x 2que contenga enteros.
4. Para cada uno delos tipos definidos enel ejercicio 3:
a) Declare einicialice una constante dedicho tipo.
2. Presentacin del lenguaje VHDL 129
b) Declare una variable de dicho tipo y escriba una sentencia de asignacin a
esta variable sinutilizar agregados.
S. Escriba el valor delas 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 dedatos:
type Matriz is array (Oto 15, 12 downto 3, 2 to 31) of character
Escriba el valor delas 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 eantes de la ejecucin de cada sentencia
wait y muestre lasecuencia devalores que toma laseal C.
z <= transport '1' after 10 ns;
wait for 5 ns;
z <= transport 'O' after 7ns;
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 ladeclaracin del siguiente multiplexor 4-1 dedatos deocho bits:
entity Multiplexor is
port ( Seleccion : inbit_vector(O to 1)
130 VHDL. Lenguaje estndar de Diseo Electrnico
Entrada!
Entrada2
Entrada3
Entrada4
Salida
end Muitiplexor;
in bit_vector (9 to 7);
in bit_vector ( O to 7) ;
in bit_vector (O to 7) r
in bit_vector (O to 7);
out bit_vetor (O to~7r);
a) Escriba unaarquitectura utilizando unproceso conunasentencia case.
b) Escriba una arquitectura utilizando una nica asignacin a seal concu-
rrente.
9. Dadaladeclaracin del siguiente decrementador:
entity Decrementador 18
port ( Reloj
Inicializa
Carga
Valor
Salida
in bit;
in bit;
in bit;
in bit vector (7 down,toO),
out bit_vector(7 dowiito''of'),;
end Decrementador;
Cuyas entradas y salidas tienen lasiguiente funcionalidad:
Reloj: Reloj quecontrola laoperacin del decrementador.
Inicializa: Entrada sncrona quecuando vale 'O' inicializa Salida a "00000000".
Carga: Entrada sncrona quecuando vale 'O' inicializa Salida aValor.
Valor: Entrada que secarga aSalida cuando Carga vale 'O'.
Salida: A cada pulso de Reloj debe decrementar su valor hasta llegar a
"00000000" .
a) Escriba laarquitectura del decrementador mediante unproceso queseejecu-
teacadaevento deReloj.
b) Repita el apartado a) utilizando un proceso que implemente un bucle desde
queSalida vale Valor hasta que vale "00000000". Escriba tres versiones di-
ferentes, usando las sentencias loop, while yJor respectivamente.
10. Dada ladeclaracin del siguiente sumador completo deunbit:
entity SurnadorCompleto 18
port ( OperadorA: in bit;
OperadorB : in bit;
AcEntrada : in bit;
Resultado : out bit;
AcSalida : out bit);
end SurnadorCompleto;
a) Escriba laarquitectura dedicho sumador utilizando un estilo dedescripcin
enflujo dedatos.
b) Defina la entidad y arquitectura de un sumador de un nmero genrico de
bits queutilice el sumador anterior deun bit como componente. Parahacer-
louselasentencia generate.
2. Presentacin del lenguaje VHOL 131
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 detipo 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 lasiguiente-entidad:
use work.DistanciaArea.all;
entity Multiplicador ls
port ( A : inDistancia;
B : inDiS.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 seproduzca unerror decompilacin.
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"..
ydelasiguiente seal resuelta detipo 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 lafuncin
deresolucin 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 deresolucin Reso-
lucionBit.
e) La seal Peticion debe valer' l' cuando todas sus fuentes valen '1', en caso
contrario debe valer 'O' (and lgica). Escriba lafuncin deresolucin Reso-
lucionBit.
132 VHDL. Lenguaje estndar de Diseo Electrnico
15. Considere el siguiente bloque detres entradas y dos salidas cuya funcionalidad
viene determinada por latabla delaverdad adjunta:
A bit
ybit
B bit
Bloque
-
1 F1
Zbit
ebit
.
1o o 1
1'\ - 0 - o
o
11 11
11 o
a) Escriba ladeclaracin deentidad deestebloque.
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:
e n t i t y NAND2 i s
port ( a : inb i t ;
b : inb i t ;
z : out b i t ) ;
end NAND2 ;
e) Escriba la arquitectura utilizando el estilo de descripcin de flujo de datos.
Para hacerlo solamente sepueden usar los operadores lgicos and, or ynoto
d) Escriba laarquitectura utilizando el estilo dedescripcin algortmico. Hga-
lo usando lasentencia secuencial case.
e) Escriba laarquitectura utilizando el estilo dedescripcin algortmico. Hga-
lo usando lasentencia secuencial ij, mediante construcciones del tipo:
i f <c o n d i c i n > then
s e n t e n c i a s s e c u e n c i a l e s
e l s i f <c o n d i c i n > then
s e n t e n c i a s s e c u e n c i a l e s
e l s e
s e n t e n c i a s s e c u e n c i a l e s
end i f
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.
2. Presentacin del lenguaje VHOL 133
g) Suponga que las salidas y y Z son de un tipo llamado XOl que contiene los
valores cero lgico ('O'), uno lgico (' 1') Y valor prohibido ('X'). Este valor
prohibido debe producirse cuando las entradas A, B Y etienen el mismo va-
lor. Defina el tipo de datos XOl e inclyalo en un paquete llamado Paque-
te_XOl. Utilizando el paquete acabado dedefinir, vuelva aescribir ladecla-
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 VHDLpara simulacin.
A continuacin se abordan los objetivos centrales de este captulo:
el procesado y el modelado de VHDLpara 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
136 VHDL. Lenguaje estndar de Diseo Electrnico
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 devida deun diseo electrnico. Esta tendencia lleva aextender
suuso ms all del propsito para el que VHDL est definido en el manual derefe-
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 lautilizacin deVHDL como lenguaje de sntesis auto-
mtica dehardware.
Dado que VHDL es un lenguaje bastante complejo, suele ser normal que undi-
seador de hardware no utilice adecuadamente toda su capacidad descriptiva. Lo
habitual suele ser que el diseador adopte unos ciertos hbitos o estilos dedescrip-
cin ligados aunos 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. Sinembargo, lo que sesue-
le esconder detrs de esta excusa es el desconocimiento del procesado y de la se-
mntica del lenguaje VHDL. Situacin que seagrava 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
acausar equvocos en los posibles usuarios del HDL eincluso hacer que stos pue-
den llegar aaborrecerlo debido a su pretendida complejidad, cuando en realidad se
trata de mera incompresin. Para evitar esta posible y nefasta consecuencia, en este
captulo sepresenta el lenguaje desde el punto devista de suprocesado y su semn-
ticadesimulacin dirigida por eventos discretos.
Aunque VHDL, como sedescribe 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 sebasa precisa-
mente en su faceta de simulacin. Por ello, este captulo comienza presentando las
nociones bsicas dela simulacin por ordenador. Nociones que son degran utilidad
para el diseador de sistemas electrnicos al permitirle considerar el proceso dedi-
seo con VHDL como un caso particular del diseo deun sistema fsico por medio
de su modelado y posterior compresin y/o validacin por medio de su simulacin.
Desde estaperspectiva, ladescripcin deun sistema electrnico atravs deun HDL
con semntica de simulacin sepuede considerar como la generacin deun progra-
ma informtico cuya ejecucin por un ordenador produce un modelo dinmico que
representa laevolucin del sistema fsico, yaseaexistente (para describir/reflejar) o
proyectado (para sugerir ideales), atravs del tiempo.
A continuacin se presentan las nociones bsicas del procesado de un progra-
ma informtico, hacindose especial nfasis en lacompilacin software, hardware e
hbrida de un HDL. Este conocimiento es crucial para poder comprender tanto la
generacin demodelos software desimulacin por ordenador correspondiente auna
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.
138 VHDL. Lenguaje estndar de Diseo Electrnico
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 sedebe 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 sepuede 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 odestructiva.
3. Se necesita un modelo que permita predecir el comportamiento en largos
periodos detiempo deforma compacta.
4. El modelo matemtico, tambin denominado formal, del sistema fsico no
tiene solucin analtica o numrica que ofrezca resultados prcticos, por lo
que suanlisis y/o verificacin formal resulta inviable..
La principal ventaja del uso de la simulacin es la reduccin del riesgo asocia-
do alarealizacin deun nuevo sistema, o asu modificacin. La simulacin por or-
denador permite probar diferentes alternativas y seleccionar laque 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 oprogramar el modelo sefuerza al diseador del mismo aque 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 alaluz 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 deambos, tambin presenta dos desventajas inherentes asupropia natu-
raleza. La primera de ellas se debe a que la simulacin es un proceso experimental
que slo darespuestas aproximadas, ni exactas ni ptimas, que slo permiten mejo-
rar laconfianza en el modelo. En una simulacin no seobtiene una solucin, mate-
mticamente hablando, sino que seobtiene un mejor conocimiento de las relaciones
entre los componentes del sistema, siempre apartir deunestado inicial determinado.
En la simulacin por ordenador se abandona el clculo predictivo que ofrecera el
uso deuna definicin completamente rigurosa o formal, por la aplicacin deun m-
todo deprueba y error en el que sepueden observar las distintas estrategias y posibi-
lidades del diseo. Una simulacin sepuede repetir tantas veces como sea necesario
hasta que seobtenga suficiente confianza en sus predicciones. La deteccin deerro-
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 sedebe aque la validacin del propio modelo de simu-
lacin es lamayor limitacin deesta 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 sepodra considerar como
un continuo, pero entonces para poder informatizar su evolucin sera necesario el
uso deordenadores analgicos. El problema que presentan este tipo deordenadores
es que su precisin es altamente dependiente de las caractersticas de los circuitos
electrnicos que los forman. Ladificultad deduplicar este tipo desistemas halleva-
do aconsiderar ordenadores mixtos (analgico-digitales) y finalmente digitales, de-
bido a los avances en electrnica digital y en arquitectura de ordenadores. En la
prctica, esto hallevado aconsiderar el tiempo deforma discreta.
Existen dos formas de ejecutar los modelos dinmicos por medio deuna repre-
sentacin discreta del tiempo, dirigiendo lasimulacin 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-
maseactiva en todos los ciclos desimulacin, incluso cuando las entradas del com-
ponente no han sufrido modificaciones y, por tanto, el componente no necesita re-
calcular suestado.
3.2.1.1. Simulacin dirigida por el paso del tiempo
Enun sistema detiempo discreto el modelo avanza por sucesivas etapas en una se-
riede 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
cadasalto (tick) o ciclo de reloj el tiempo se incrementa en una constante. El pro-
blema deimplementar una simulacin con un avance sncrono del tiempo es que no
esposible representar funcionalidad que acontece simultneamente deforma discri-
minatoria, de modo que se necesitan ciertos mecanismos para poder describir los
estados intermedios por los que pasa un sistema sinque 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 dehardware y software.
3.2.1.2. Simulacin dirigida por eventos discretos
El paradigma de la simulacin dirigida por eventos discretos [14-17] sebasa en la
existencia de dos componentes: uno que representa al propio modelo de simulacin
en estudio y que adems es el generador delos 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 alo que sesuele
denominar kernel oncleo del simulador.
140 VHDL. Lenguaje estndar de Diseo Electrnico
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-
rael caso enun simulador dirigido por tiempo exclusivamente.
La suposicin de que no ocurre nada entre dos eventos, o, deforma ms preci-
sa, que el estado de los elementos que componen el modelo permanece constante
entre dichos instantes detiempo, sesatisface por un amplio nmero desistemas rea-
les y adems seconsidera el Primer Paradigma dela 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 laque seinsertan pares correspondientes alos
valores delos eventos, junto con los tiempos en los que estprevisto que acontezcan
dichos eventos, vase laFigura 3-1. La longitud delas colas y laforma deinsercin
de los futuros eventos, depende de cada lenguaje de simulacin. Las colas sevaac-
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 sepuede eliminar delacola deFEs 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 deparada (p. ej., lmite detiempo de simulacin, control del simulador).
A menudo, como resultado de la actividad que lleva acabo 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 setrate, ciertas FEs sepostponen o
incluso se cancelan (modelos de insercin preemptivos = planificacin dinmica).
Esencialmente, laplanificacin deFEs consiste en las siguientes operaciones: lain-
sercin denuevos FEs en las colas deFEs y laextraccin deFEs delas colas en un
estricto orden de prioridad con respecto al tiempo. Por tanto, hay dos tareas funda-
3. Procesado y mecanismos de simulacin del lenguaje VHDL 141
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 laaparicin
del evento. La planificacin delas operaciones que realiza el modelo sepuede con-
siderar como el procesado delos elementos deun conjunto. Endicho conjunto cada
elemento tiene asociado el tiempo en el que cierto evento va aacontecer, de modo
que de acuerdo con esta informacin el kernel puede llevar acabo la planificacin
delas operaciones del modelo.
La propia naturaleza de la gestin de las colas de eventos limita el potencial
paralelismo dela simulacin dirigida por eventos. Sehan 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 dealtas
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 sepuede mejorar si seelimina lanecesidad deun 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
odetectarlos y recuperarse deellos.
Las estructuras dedatos que soportan alas colas deFEs 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 aun vector de su-
brutinas, amenudo depender delaestrategia desimulacin que seest empleando.
Laeleccin deesta estrategia afecta alaimplementacin y al uso del lenguaje de si-
mulacin, o sea, alarealizacin delas herramientas desimulacin y al lenguaje con
el que stas seprograman.
3.2.1.2.1. Estrategias desimulacin
En lasimulacin dirigida por eventos discretos slo hay tres posibles estrategias: la
planificacin de eventos, la bsqueda de actividad y finalmente, la basada en lain-
teraccin de procesos. La estrategia basada en la interaccin de procesos se puede
considerar una combinacin delas otras dos, en laque segana en eficacia deejecu-
cin y adems seobtienen 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 deeventos durante laejecucin dinmica dela simulacin. Cuando apare-
ceun evento ocurren dos cosas: (1) seprocesa el evento realizndose las operacio-
nes que para tal evento estn previstas; (2) seplanifican los tiempos en los que po-
drn ocurrir los futuros eventos. Deeste modo es como sesimula el comportamien-
to dinmico del modelo. El inconveniente que presenta esta estrategia es la
dificultad deactivacin delas operaciones que sedeben 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 dedos 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-
142 VHDL. Lenguaje estndar de Diseo Electrnico
mo sunombre indica, laestrategia sebasa en labsqueda deactividad, que sepue-
dedefinir como el estado ocupado del modelo entre laocurrencia dedos 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 delaestrategia basada enlasimple planificacin deeventos, pero puede
llegar aproducir resultados poco eficientes.
Por ltimo, laestrategia basada en lainteraccin deprocesos 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
deacuerdo con laaparicin deeventos. El gran problema deesta estrategia es lapo-
sibilidad deque aparezcan deadlocks en lainteraccin entre los procesos. Emplean-
do las estrategias basadas en laplanificacin deeventos y en labsqueda deactivi-
dad, el problema de bloqueo no aparece debido alanaturaleza secuencial dedichas
estrategias y a la suposicin de que en dichas estrategias el ac-cesoa 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 launidad deretraso (Unit-delay) y
el basado en la ausencia absoluta deretraso (Zero-delay). Estos modelos sesuperpo-
nen alagestin deeventos en el caso delasimulacin 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 deregistros. El tiempo sedefine con una granularidad no inferior al ciclo
dereloj, deah el nombre del modelo (el ciclo de simulacin coincide con launidad
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 serealiza laevaluacin delas expresiones. Es-
taes lacaracterstica ms relevante del modelo.
El diagrama deflujo delaFigura 3-2 muestra lapresencia dedos tareas conse-
cutivas para laevaluacin y laasignacin delas expresiones.
El bucle representa el avance del tiempo desimulacin, que normalmente coin-
cide con el siguiente flanco dereloj o cambio deestado 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 lamejor eleccin.
3. Procesado y mecanismos de simulacin del lenguaje VHOL 143
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 sudiagrama deflujo.
Laprincipal diferencia entre este diagrama de flujo y el correspondiente al modelo
Unit-delay es que aqu la evaluacin y la actualizacin de las expresiones sereali-
zanen un solo paso. La caracterstica deeste modelo es lacomunicacin en tiempo
cero, que no siempre garantiza el orden (causalidad) en el que seejecutan los even-
tos.
Las sentencias que siguen a las de asignacin usan los valores recin asigna-
dos, yaque los anteriores sepierden. Si no sedefine explcitamente entonces no es
posible predecir si una expresin, que leeun registro, emplear el valor antiguo o el
nuevo. Este tipo deproblemas debidos al orden de ejecucin se denominan "carre-
ras" y son un problema aadido ala dificultad del propio modelado del sistema. El
modelo desimulacin basado enZero-delay no siempre es lamejor eleccin.
3.2.2. Estructura general de la simulacin
El proceso de simulacin sedesarrolla en las tres etapas mostradas en laFigura 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 seelabora 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 delasimulacin.
144 VHDL. Lenguaje estndar deDiseo Electrnico
Inicializacin Ejecucin Terminacin
FIGURA 3-3. Etapas del proceso de simulacin.
2. La ejecucin. El modelo desimulacin seponeen movimiento, esto es, se
lepermite mostrar sucomportamiento dinmico bajo la accin del mecanis-
mo de avance del tiempo de simulacin. Una simulacin sepuede progra-
mar para llevarse a cabo durante un determinado periodo detiempo de si-
mulacin, o sepuede hacer que finalice al satisfacerse ciertas condiciones
dadas previamente al comienzo delaetapa deejecucin o animacin.
3. La terminacin. Cuando finaliza, deforma normal o anormal, la ejecucin
del programa querepresenta al modelo desimulacin, es cuando sepuede
proceder a realizar un anlisis "post-mortem" de todo lo acontecido. Este
anlisis sepuede realizar de forma pre-programada, siguiendo un procedi-
miento establecido deantemano tan complejo como sedesee, o puede con-
sistir simplemente en el puro examen delos resultados obtenidos. Tambin
sepuede realizar el anlisis delos resultados deforma interactiva durante la
propia etapa deejecucin, parando la simulacin cada vez quesedesea lle-
var acabo dicho anlisis.
3.2.3. Aproximacin metdica a la simulacin
Laestructura general dela simulacin, descrita anteriormente, seharealizado desde
el punto devista de la ejecucin del modelo en un ordenador pero sin decir nada
acerca del proceso de modelado (modeling), ni de las pruebas (testing) iterativas
queconllevan alacorreccin/depuracin (debugging) del modelo hasta queel dise-
ador est satisfecho con sus resultados. LaFigura 3-4 muestra el diagrama deflujo
delos pasos necesarios para realizar una aproximacin metdica alasimulacin.
3.2.3.1. Modelado
Una vez especificado el modelo del sistema quesedesea analizar, es necesario des-
cribirlo deforma queun ordenador lo pueda procesar. Ambas etapas, especificacin
y descripcin, conforman el paso denominado modelado. El modelo ejecutable por
el ordenador es el punto departida para poder ejercitar las pruebas que sedesean
realizar adicho modelo.
3. Procesado y mecanismos de simulacin del lenguaje VHOL 145
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
decasos de prueba de forma que su simulacin le ofrezca cierta confianza sobre la
verificacin del diseo. La precisin delos 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.
Unaayuda alasimulacin es lainclusin deaserciones en ladescripcin del mode-
lo, que sedeben verificar en tiempo desimulacin. .
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 seest depurando el modelo atravs deun proceso de verifica-
cin. El grado de confianza que el diseador deposita en los casos de prueba est
directamente relacionado con lacalidad del mtodo dediseo 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 sedescribieron enel plan depruebas.
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 delos estmulos adecuados. El problema deeste mtodo deverificacin
reside en la imposibilidad prctica de llevar acabo una simulacin exhaustiva, de-
bido alaexplosin decasos, deforma que garantice lacorreccin del diseo.
146 VHDL. Lenguaje estndar de Diseo Electrnico
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. Dehecho, en lamayora delas 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 delas partes ms difciles dellevar acabo.
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 dellevar acabo larealizacin 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 deforma similar adichos experimentos. Aunque se
haya alcanzado laperfeccin en el desarrollo y las pruebas deverificacin y valida-
cin del modelo de simulacin, no sepuede estar seguro del todo acerca de los re-
sultados deexperimentar fuera de los lmites del conocimiento del sistema en cues-
tin. El diseador debe ser cauto alahora deconfiar en los resultados dela simula-
cin alahora deexperimentar fuera dedichos 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 ladescripcin en un determinado
lenguaje deprogramacin deun algoritmo. Pero no hay que olvidar que los algorit-
mos son conceptos abstractos, que existen independientemente decualquier posible
notacin en laque stos sepudieran expresar. Sin embargo, sinlautilizacin deuna
notacin es imposible expresar deforma precisa o comunicar un algoritmo, o razo-
nar acerca desucorreccin.
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 desentencias o instrucciones) descritos o expresados en un determi-
nado lenguaje deprogramacin. El procesado deun lenguaje sepuede llevar acabo
por medio deun solo procesador ocombinando varios procesadores.
Hay dos tipos de procesadores particularmente interesantes: los traductores y
los intrpretes. Un traductor (Translator) es un determinado tipo deprocesador que
acepta como entrada ofuente cualquier texto descrito o expresado en unlenguaje de
programacin determinado, denominado lenguaje fuente (Source Language), y que
genera como salida un texto semnticamente equivalente expresado en otro lengua-
3. Procesado y mecanismos de simulacin del lenguaje VHDL 147
je de programacin, denominado destino (Target Language}, Un intrprete (lnter-
preter) es otro tipo deprocesador que lleva acabo o ejecuta las acciones correspon-
dientes al algoritmo descrito por medio del programa que est siendo procesado.
Paraello, el programa debe estar descrito en un cdigo olenguaje 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
seledenomin lenguaje ocdigo delamquina (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 deprogramacin 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 deprogramacin debajo nivel (Low Level Programming Languages), de-
nominados as por forzar aexpresar los algoritmos que sedesean procesar en trmi-
nos cercanos alas instrucciones que puede ejecutar directamente laelectrnica sub-
yacente al procesador. En contraposicin aestos lenguajes deprogramacin debajo
nivel, actualmente seutilizan los lenguajes deprogramacin dealto nivel (High Le-
vel Programming Languages, HLLs) que permiten laexpresin de los algoritmos a
unnivel deabstraccin ms cercano al lenguaje interpretable por el ser humano que
por el procesador electrnico hardware. Los HDLs son un caso particular deHLLs,
cuyo propsito es ladescripcin virtual (software) ofsica (hardware) deun 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 sepo-
dran tener en cuenta implementaciones mecnicas eincluso electromecnicas, des-
deque seinvent el transistor slo seconsideran procesadores electrnicos hardwa-
re y/o software. Atendiendo ala implementacin del procesador, sepuede conside-
rar que el sistema electrnico hardware 1 en el que selleva acabo laejecucin deun
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 asu vez seest 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-
vaimplcitamente asociado unprocesador hardware, vase laFigura 3-5.
1 Un ordenador o computadora es un caso de procesador implementado por medio de un sistema
electrnico hardware, este tipo de procesadores sedenominan microprocesadores (IlProcesador) cuan-
do seimplementan con tecnologa microelectrnica.
148 VHDL. Lenguaje estndar de Diseo Electrnico
Procesador
Hardware
Programa
1-
Procesador
Software Procesador
Hardware
Programa
1-
Programa
FIGURA 3-5. Procesadores electrnicos Hardware ySoftware.
3.3.2. Compiladores Software, Hardware e hbridos
Cuando el traductor deun lenguaje cambia el nivel deabstraccin entre sus lengua-
jes fuente y destino, entonces el procesador se denomina compilador (Compiler)
[20-23]. Como sepresent 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 arealizar 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 dedicho HDL. De este modo sepuede gene-
rar el programa correspondiente al modelo desimulacin que seejecutar finalmen-
teen el ordenador.
Sin embargo, el resultado de la compilacin de un programa (HDL) tambin
puede corresponder con una descripcin deun procesador hardware especfico, cu-
yaimplementacin es capaz derealizar el algoritmo expresado enel lenguaje fuente
que seestaba compilando. A este tipo decompiladores seles denomina compilado-
res o sintetizadores dehardware en contraposicin al otro tipo decompiladores que,
siendo ms precisos, seles debera llamar compiladores desoftware, vase laFigu-
ra3-6.
Dependiendo dela semntica deladescripcin 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, laresul-
tante delaemulacin hardware deuna descripcin HDL. La emulacin es una tc-
nica experimental similar ala simulacin por ordenador en la que el modelo no es
3. Procesado y mecanismos de simulacin del lenguaje VHDL 149
Programa Programa Intrprete
1-O-1=C
ftw
'"
Programa
C ompilador
Software
Plataforma
Hardware
-
C ompilador
Hardware
Plataforma
Hardware
FIGURA 3-6. C ompiladores 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 sedesea 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 sepuede considerar
queest ms cercano aun modelo hardware de simulacin por ordenador, si seex-
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 delos sistemas electrnicos, yaque para
otros sistemas fsicos carece desentido.
Hasta ahora seha 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), obien para generar un hardware especfico, provisional odefinitivo. Sinem-
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], seespera que aparezcan nuevos lenguajes, denominados de especificacin
desistemas electrnicos (hardware y software), que darn lugar aun nuevo tipo de
compiladores: el cosintetizador o compilador concurrente dehardware y desoftwa-
re [27-29]. La compilacin deeste tipo delenguajes dar lugar alaimplementacin
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 decompilador oco-sintetizador sepuede considerar como per-
teneciente a la misma familia de compiladores hbridos a la que pertenecen los
150 VHDL. Lenguaje estndar de Diseo Electrnico
emuladores hardware. Salvando las distancias y considerando dos grandes diferen-
cias: que la descripcin que secompila no toda ella sedesea implementar en hard-
ware y que la parte hardware que secompila 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 amalinterpretaciones debido alapresencia de
ambigedades, inconsistencias o carencia de completitud, o sepuede 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 desus usuarios. En ambos casos hay tres aspectos del lenguaje [30]
que sedeben 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 alaforma delos programas.
La sintaxis deun lenguaje sepuede especificar por medio deuna 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 seencuentra 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 apartir 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 deproduccin sedescriben por medio degrafos dirigidos.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 151
Expresin
I
Expresin primaria
I
Nombre de Variable
I
ExpreSin
l
primaria Expresin Iprimaria
Nombre de Variable
I
"j"!j' ti i!j i!j " ~r i~
FIGURA 3-7. sr de la expresin "d +10*n:".
Cada C-FG gener a unlenguaje, que no esotr a cosa que un conjunto decadenas
de smbolos ter minales. De este modo, un lenguaje se puede definir como el con-
junto de sentencias compuestas de fr ases cuya estr uctur a se puede r epr esentar por
medio de r boles sintcticos (Syntax Trees, STs). Un ST de una C-FG es un r bol
or denado donde los nodos ter minales estn etiquetados por smbolos ter minales y
los nodos no ter minales lo estn por smbolos no ter minales alos que estn asocia-
das cada una de las r eglas de pr oduccin. As, una fr ase de la gr amtica C-FG es
una cadena de smbolos ter minales que etiqueta a los nodos ter minales del ST, to-
mados de izquier da a der echa. Una sentencia de la gr amtica C-FG es una fr ase
donde el nodo r az del ST cor r espondiente esel smbolo S (Start Symbol).
Debido a su pr ecisa descr ipcin de los detalles sintcticos, la gr amtica C-FG
descr ita anter ior mente sedice que ser efier e ala sintaxis concr eta (Concrete Syntax)
del lenguaje, que esdeespecial inter s par a el usuar io final del lenguaje, yaque tie-
ne que conocer concr etamente cmo se deben escr ibir pr ogr amas sintcticamente
cor r ectos.
Sin embar go, no siempr e es necesar io centr ar se en la expr esin concr eta de un
lenguaje sino que basta con centr ar se en el conocimiento delaestr uctur a de susfr a-
ses. En estos casos la gr amtica CF-G ser efier e ala sintaxis abstr acta del lenguaje
(Abstraet Syntax) y los r boles sintcticos que segener an sedenominan ASTs (Abs-
traet Syntax Trees). En los ASTscada nodo no ter minal seetiqueta con una r egla de
pr oduccin y lecor r esponde un nico subr bol por cada subfr ase, yaque los smbo-
los ter minales no juegan un ver dader o papel en la sintaxis abstr acta. Las sintaxis
abstr acta slo sepr eocupan delasr elaciones jer r quicas existentes entr e lasfr ases y
las subfr ases. Las sintaxis concr etas adems se ocupan de los smbolos utilizados
par a separ ar y anidar lasfr ases del lenguaje.
152 VHDL. Lenguaje estndar de Diseo Electrnico
Expresin-Operador-Expresin IEOE)
I
v v
I I
~ ] c l J ~
FIGURA 3-8. AST de l a expresin "d +10* n:",
3.3.3.2. Restricciones de contexto
Las gramticas C-FG deben su nombre aque sepuede determinar la correccin de
las frases que componen dichos lenguajes independientemente del contexto en el
que stas seencuentren. 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 serealizan con los operandos adecuados.
En laprctica las gramticas C-SG seespecifican por medio degramticas con
atributos (Attribute Grammar). Este tipo degramticas seespecifican por medio de
latripleta (G, V, F), donde G es la4-tupla correspondiente ala gramtica C-FG, V
es el conjunto de atributos que seaaden alos nodos del AST generado por la gra-
mtica C-FG para recoger las reglas dembito y detipos 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 deentre todas aquellas que sepodran generar apartir delagram-
tica C-FG.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 153
3.3.3.3. Semntica
La semntica dinmica, o simplemente semntica (Semantics), define el significado
delos 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 delos pasos u operaciones
por medio de las cuales selleva acabo 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-
sisteen considerar aun programa como si fuese una funcin matemtica que trans-
formase las entradas en las salidas, centrndose ms en qu hace el programa que
encmo selleva acabo.
3.3.4. Proceso de compilacin de un lenguaje
de programacin
Todo compilador deun lenguaje deprogramacin consta de dos etapas. La primera
de ellas, o fachada (front-end) del compilador, se denomina anlisis y se compone
detres procesadores esenciales: el reconocedor o analizador lxico (scanner), el re-
conocedor o analizador sintctico (parser) y el analizador de la semntica esttica
otambin denominado.analizador dela sintaxis restringida por el contexto (contex-
tual constrainer ostatic 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 decaracteres que componen el texto fuente deun programa
en los tokens correspondientes. Una vez transformado el programa fuente en una
cadena de tokens, el parser seencarga detratar cada uno deellos 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
decompilacin del programa ocdigo fuente.
La segunda parte o etapa posterior (back-end) detodo compilador sedenomina
sntesis y se dedica ala 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 deuna compilacin segenera y secomunica 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 dela definicin de los lenguajes (especialmente
aquellos que son standards y que se revisan peridicamente, como es el caso de
154 VHDL. Lenguaje estndar de Diseo Electrnico
VHDL), al ofrecer un alto grado de independencia entre las distintas fases de su
procesado y, por tanto, permitir el aislamiento delos posibles cambios del lenguaje
en cada unadedichas fases.
3.4. SIMULACiN DE UNA ENTIDAD DE DISEO VHDL
La simulacin deuna entidad dediseo VHDL consiste en laejecucin monitoriza-
da por medio de un ordenador de su modelo de simulacin. Dicho modelo, consis-
tente en una red deprocesos VHDL interconectados entre s, seobtiene como resul-
tado del proceso de elaboracin de lajerarqua 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 derepresentar el tiempo y con suevolucin
es capaz derepresentar 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 lajerarqua de
diseo.
La simulacin deuna entidad dediseo VHDL larealiza un simulador, omejor
dicho, un entorno de simulacin. Dicho entorno seencarga dedos 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 sepuede ver como lacomposicin de:
1. Un procesador de la descripcin VHDL encargado de analizar las unidades
dediseo VHDL que describen laentidad dediseo VHDL y deelaborar la
jerarqua de diseo para dar lugar a lared 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 dela descripcin VHDL correspondiente alaentidad dedi-
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 deVHDL tiene que hacerse cargo tanto de la sintaxis como
de la semntica esttica y dinmica de VHDL, acontinuacin se va aentrar ades-
cribir en mayor detalle cada una delas fases que componen dicho procesado.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 155
3.4.1. Procesado de una descripcin VHDL
El LRM del lenguaje VHDL define, deun modo informal en ingls, la sintaxis y la
semntica operativa del lenguaje, o sea, los pasos aseguir para que una descripcin
VHDL sepueda procesar en unordenador con el propsito de simular sucomporta-
miento. De acuerdo con el LRM, como sepuede apreciar en laFigura 3-9, antes de
poder simular una descripcin VHDL en un ordenador, sta se debe procesar por
medio delas fases que sedescriben enlos siguientes apartados.
Entre cada una de las fases del procesado de VHDL se genera un AST (Abs-
traet Syntax Tree) [34], vase laFigura 3-10. De esta forma, cada fase sepuede 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) deuna determinada unidad dediseo
(Design Unit). Cabe resaltar que ladescripcin BNF delagramtica deVHDL, que
sepresenta en el LRM como un anexo, no forma parte de ladefinicin de lanorma
(Standard). Esto es una muestra ms, aadida ala 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 deaplicar las reglas derestriccin detipos y dembito
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 sever posteriormente, sesuele denominar como larepresentacin
oel formato intermedio deVHDL (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 atodas las unidades dediseo VHDL con las que sedescribe una deter-
[1...
... 0
Fuente VHDL Analizador VHDL
Sistemas de
Bibliotecas
Elaborador VHDL Redde procesos VHDL Simulador VHDL
FIGURA 3-9. Anlisis, elaboracin y simulacin de una descripcin VHDL.
156 VHDL. Lenguaje estndar de Diseo Electrnico
Anlisis
Sintctico
Anlisis
Semntico
Esttico
Generacin del
Modelo de Simulacin
Fichero de Diseo
VHDL
VAST
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 dela elaboracin esttica de una entidad dediseo 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 seael 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 suposterior 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 deun sistema electrnico, pudiendo ser, por ejemplo, una celda (Cell o
Macrocell) que forma parte deun circuito integrado (Integrated Circuit, IC), un IC
ouna placa (Printed Circuit Board, PCB) compuesta asuvez devarios ICs.
2 A diferencia de unajerarqua en la que pueden encontrarse objetos dentro de otros objetos, co-
mo, por ejemplo, lajerarqua de funciones anidadas en el lenguaje e, en una heterarqua todos los ob-
jetos seencuentran al mismo nivel. En el cas del resultado deelaborar unajerarqua de diseo VHDL
seobtiene una red de procesos VHDL en los cuales no existen procesos VHDL anidados.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 157
La unidad bsica deprocesado en VHDL es launidad dediseo (VHDL Design
Unit). Hay dos tipos deunidades dediseo: primarias (declaraciones de entidad, de
configuracin y depaquete) y secundarias (el cuerpo dearquitectura deuna entidad
y el de un paquete). No hay que confundir entidad de diseo con unidad dediseo.
Una entidad de diseo se describe por medio de varias unidades de diseo, como
mnimo tiene que existir una declaracin de entidad ala que selepuede asociar un
cuerpo de arquitectura directamente o por medio de una declaracin de configura-
cin. Cada unidad dediseo puede hacer referencia aotras unidades que han de ser
analizadas previamente. Las declaraciones y los subprogramas comunes se suelen
describir por medio depaquetes alos que otras unidades dediseo pueden hacer re-
ferencia posteriormente.
Una descripcin VHDL, vase laFigura 3-11, puede estar compuesta por uno o
varios ficheros textuales en los que estn contenidas las descripciones correspon-
dientes alas unidades dediseo. Cada unidad dediseo est precedida por ladecla-
racin de su contexto, o sea, delas bibliotecas o delas unidades debiblioteca espe-
cficas que usa o, dicho deotra 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 seanalizan secuencialmente. Cada unidad de diseo seanaliza de forma in-
dependiente y dalugar auna unidad debiblioteca dediseo (VHDL Design Library
Unit). Estas unidades seorganizan 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 dere-
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) yuna representacin alegrica de dicho sistema de unida-
des de biblioteca (11.c).
158 VHDL. Lenguaje estndar de Diseo Electrnico
momento, yaque tan slo es una biblioteca lgica que en el momento derealizar el
anlisis se asocia con una biblioteca fsica determinada por el diseador deVHDL.
Los ficheros dediseo VHDL son ficheros detexto 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 delaimplementacin del sistema
deprocesado deVHDL que seestutilizando.
El Captulo 11del LRM describe el proceso y el orden de anlisis de las uni-
dades de diseo VHDL. El Captulo 13del 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 sepueden ob-
tener por medio deuna lectura cuidadosa y cruzada detodos los prrafos que com-
ponen el LRM. Con estas reglas sepuede realizar tanto un scanner y unparser 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 deuna unidad dediseo, o seael VIF, sealmace-
nacomo una unidad de biblioteca. Si una unidad debiblioteca dediseo semodifi-
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 depoder ser utilizadas posteriormente.
Cuando finaliza el anlisis deuna unidad de diseo slo sepuede decir deella
que su descripcin textual estaba escrita en VHDL de forma correcta atendiendo al
LRM, pero nada sepuede decir del sistema electrnico, de cuya descripcin forma
parte, ni del uso posterior que sevaahacer deella (p. ej., simulacin, sntesis, etc.).
De hecho, el anlisis es la nica etapa del procesado de VHDL que es comn a
cualquier tipo deuso que sevaya ahacer deuna unidad dediseo 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 deVHDL, sino que adems permite lacreacin debibliote-
cas configurables por medio de la capacidad intrnseca de configuracin que posee
el lenguaje VHDL. Esta es labase que permite lareutilizacin del diseo en VHDL
y laposible explotacin de los derechos depropiedad (Intellectual Property Rights,
IPRs) dedichos diseos.
3.4.1.2. Elaboracin de una jerarqua de diseo VHDL
Una entidad de diseo sedescribe en VHDL por medio deuna declaracin deenti-
dad as como deun cuerpo de arquitectura o de ladeclaracin deconfiguracin co-
rrespondiente, junto con todas aquellas unidades de diseo a las que se haga refe-
rencia. El cuerpo dearquitectura deuna entidad dediseo y, por tanto, laentidad de
diseo correspondiente, se puede describir por medio de unajerarqua de bloques,
cada uno de los cuales describe una parte de laentidad dediseo. 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
uncuerpo de arquitectura como unajerarqua debloques, tambin puede ste hacer
referencia aotras entidades de diseo consideradas como componentes. Desde este
punto de vista tambin se puede decir que una entidad de diseo se describe por
medio deunajerarqua deentidades dediseo, donde cada una deellas est descrita
por medio delas unidades dediseo correspondientes.
El Captulo 12del LRM describe el proceso de elaboracin del modelo de si-
mulacin correspondiente auna determinada entidad dediseo. En dicho proceso la
jerarqua dediseo sedesmonta para dar lugar auna heterarqua ored plana depro-
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
delaentidad dediseo en cuestin.
Todas las unidades dediseo referenciadas por laentidad dediseo, cuyajerar-
qua sedesea elaborar, deben ser analizadas previamente. Durante el proceso deela-
boracin, dicha entidad de diseo se considera como el nivel superior de lajerar-
quadediseo que sedesea elaborar y apartir del VIF correspondiente aladeclara-
cin de dicha entidad se aade el VIF correspondiente al cuerpo de arquitectura
seleccionado y todos los VIFs correspondientes atodas 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 deprocesos VHDL resultantes de laelaboracin deuna 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 sucorrespondiente 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 deelaborar una sentencia (deasignacin deseal) concurrente. La asocia-
cin del componente serealiza atravs deun puerto (inout) bidireccional (F), o se-
al formal, que seune alaseal actual (A). Todas las seales del ejemplo son expl-
citas y escalares, para facilitar suseguimiento.
Como resultado de la primera fase de elaboracin de lajerarqua de diseo
VHDL descrita en laFigura 3-12, aparece laheterarqua deprocesos VHDL descri-
taen laFigura 3-13. En esta figura no sehace 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.
160 VHDL. Lenguaje estndar de Diseo Electrnico
Wait .
File
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 querecordar que los FEs son los elementos bsicos deuna simulacin diri-
gidapor eventos discretos. Por completitud, tambin sehaincluido en laFigura 3-13
informacin relacionada con el uso deuna variable compartida y deunfichero.
La segunda fase de compilacin correspondiente ala elaboracin deunajerar-
qua de diseo realiza los enlaces necesarios en el EAST, vase la Figura 3-14, de
modo que lared deprocesos VHDL quede lista para su simulacin. Dichos enlaces
se realizan teniendo en cuenta las reglas correspondientes a la propagacin de los
W,(PlI
Ir.A"',~U~nt;;il-:;T:;:ru;:e-;, 3;;;O;l+--~ Wait .
~~I T~-----1A<~............
OP,(AI
File
Wait .
~_..---1z= .
OP,(FI F <=...........
.SV(ZI
PI
Wait .
W,(P'1
HF,'IUtn:;tili, Tr.:ru::e:-, :&4 .,..-~ Wait .
I F. Until True, 25
~~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.
3. Procesado y mecanismos de simulacin del lenguaje VHOL 161
Dv(F) RF(F)
DP,(A)
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 12del LRM.
La Figura 3-14 muestra los enlaces correspondientes al caso sencillo del ejemplo
esquematizado en laFigura 3-12.
En esta figura sepuede observar cmo los valores actuales (Current Value) de
las colas de eventos correspondientes alas sentencias de asignacin de la seal es-
calar F delos procesos P2 y P3 secomponen, por medio delafuncin deresolucin
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 sele aplica
lafuncin deconversin 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 ala declaracin de la seal A. De esta forma es co-
mo secalcula el valor conducido dela seal A. Como sepuede ver, los valores con-
ducidos de las seales secalculan desde el nivel ms bajo de lajerarqua para aca-
bar en el denivel superior, o sea, deabajo aarriba.
Una vez calculados los valores conducidos detodas las seales yasepuede pa-
sar arealizar el clculo de los valores efectivos (Effective Value) de las mismas. Di-
chos valores secalculan dearriba aabajo. Para poder calcular el valor efectivo deF
162 VHDL. Lenguaje estndar de Diseo Electrnico
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 deA, que seobtiene apartir desuvalor condu-
cido. Una vez que setiene dicho valor, setransforma deacuerdo 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 alas seales A y F, que comuni-
can alos procesos VHDL dela Figura 3-14.
El valor efectivo deuna seal pasa aser el valor actual (Current Value) que di-
cha seal tendr en el prximo ciclo desimulacin, por ello sedice que sobre dicha
seal se ha producido una transaccin (Transaction). Este valor es el que seobten-
dr en el siguiente ciclo de simulacin cuando selleve acabo lalectura que sehace
dela seal F en el proceso P4. Si al producirse una transaccin en una seal, suva-
lor actual cambia con respecto al que tena anteriormente, entonces se dice que di-
chatransaccin hagenerado un evento (Event) sobre dicha seal.
La comunicacin entre procesos por medio de variables compartidas serealiza
como en cualquier lenguaje deprogramacin, o sea, compartiendo las posiciones de
memoria asociadas a cada variable. La lectura y/o escritura de ficheros se realiza
por medio delas 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 seutilizar/almacenar en cada paso de si-
mulacin delaentidad dediseo VHDL en cuestin. Laelaboracin delajerarqua
dediseo, correspondiente auna determinada entidad de diseo, sepuede ver, des-
de el punto de vista de compilacin de un lenguaje de programacin, como el ver-
dadero final delaetapa deanlisis deladescripcin ,VHDL correspondiente adicha
entidad y que seha realizado de forma incremental en cada una de las unidades de
diseo referenciadas.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 163
Todas las descripciones realizadas en un HDL, eincluso en cualquier HLL, con
semntica de simulacin dirigida por eventos discretos y basada en el paradigma de
procesos comunicantes comparten el mismo modelo deinformacin resultante dela
elaboracin esttica de unajerarqua de diseo VHDL. Se hace nfasis en lacarac-
terstica esttica de la elaboracin de VHDL porque hay tres elementos que seela-
boran en tiempo deejecucin, o seadinmicamente. Por completitud, estos elemen-
tos son: lacreacin del parmetro delos bucles (loop) y lacomprobacin de suran-
go, laasociacin deparmetros formales y actuales de las llamadas asubprogramas
(subprogram), laejecucin deun acceso atravs deun puntero (access).
La simulacin de lared deprocesos VHDL descrita por el SAST todava tiene
que ser compilada al lenguaje interpretable o ejecutable por el procesador en el que
sedesea realizar lasimulacin. En el primer caso sedice 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
Lasimulacin deuna entidad dediseo comienza inicializando los valores detodos
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 aOde la variable que recoge el tiempo correspondiente al ciclo
actual de simulacin, Te, y al prximo ciclo de simulacin, T
n
, 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 sepodra llevar acabo susimulacin.
Como resultado de la ejecucin de las sentencias de asignacin de seal que
aparecen en los procesos VHDL, las colas delos FEs sellenarn con las proyeccio-
nes delos valores que contribuirn al clculo delos valores de las seales. Estos va-
lores son slo proyecciones, yaque algunos deellos nunca alcanzarn aser 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 lavariable correspondiente al tiempo
de simulacin actual, Te, al valor de T
n
Si dicho valor secorresponde con el mxi-
mo tiempo de simulacin (TIMEHIGH), dado por el diseador al lanzar la ejecu-
cin delasimulacin, y no existen drivers activos, o seaFEs 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 laque separaron no secorresponda con Te, entonces la simulacin seda-
rapor finalizada.
164 VHDL. Lenguaje estndar de Diseo Electrnico
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 sepueden producir eventos en algunas seales por lo que el kernel
revisar la lista de procesos sensibles adichas seales y si para alguno de ellos se
cumple la condicin deespera o, independientemente, si seha alcanzado su tiempo
mximo de espera, entonces pasar aformar parte de la lista de procesos cuya eje-
cucin sereactivar en el siguiente paso desimulacin.
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 aun 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 sucontrol.
Cuando ya no queda ningn proceso pendiente de su ejecucin para el tiempo
desimulacin Te, entonces el kernel calcula el nuevo valor deT, 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 secumpla lacondicin de
espera temporal dealgn proceso.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 165
3.4.1.4. Modelo Temporal <5-delay
Cadarepeticin en laejecucin del kernel sedenomina unciclo desimulacin. Pero
ladefinicin del ciclo desimulacin es recursiva, demodo que un ciclo puede invo-
lucrar laejecucin devarios pasos desimulacin.
Los pasos de simulacin slo se diferencian del ciclo de simulacin en que en
ellos el valor del tiempo fsico no vara, sino que seincrementa 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 seutilizan variables comparti-
das entonces seproduce lacomunicacin 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 sebasa en el 'modelo Unit-delay, pero no sepuede
decir que sea Unit-delay ya que el paso de simulacin seproduce en tiempo menor
que launidad, en un 8-delay, aunque no hay que confundir con lacomunicacin 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 sepuede representar larelacin decausa-
lidad (tiempo cualitativo) entre los eventos que segeneran.
En el modelo temporal 8-delay se presenta como compuesto de unajerarqua,
dedos niveles deescalas detiempo, lamacro-escala mide tiempo real ocuantitativo
(fsico) y lamicro-escala (8-delay) mide tiempo Unit-delay. Esto no es del todo co-
rrecto, ya que lamicro escala no tiene sentido cuantitativo, por tanto, no representa
launidad detiempo en el sentido estricto de su definicin (con el que seemplea en
simuladores RTL). Aunque lamacro-escala s que es puramente Unit-delay, lacom-
binacin deambas escalas no es Unit-delay, LaFigura 3-17 muestra el modelo tem-
poral deVHDL en dos dimensiones y en su representacin unidimensional equiva-
lente enpasos desimulacin.
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 deun HLL puede llevar auna situacin deindeterminismo si laejecucin de
unadelas tareas concurrentes interfiere en laejecucin delas 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) obloqueos (deadloeks).
166 VHDL. Lenguaje estndar de Diseo Electrnico
Al
~~IOY
1 1
~
O
2 3
I
I
I
TIempo fsico
~
O
1 2
3
B I
1 , , , , , , , , , , , , 1 I I
~
Pasode 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
B l
FIGURA 3-18. Equivalencia entre la ejecucin secuencial yconcurrente de los pro-
cesos.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 167
Si no se usan variables compartidas, o sea, si la comunicacin entre procesos
VHDL slo selleva acabo por medio deseales VHDL, entonces sepuede 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-
cinVHDL uncaso deejecucin determinista.
Sepuede dar el caso deque el resultado queproduce una funcin deresolucin
seadependiente del orden en que sepasan los valores conducidos delas fuentes co-
mo parmetros de la funcin, resultando la ejecucin dependiente de la implemen-
tacin del algoritmo de clculo de valores conducidos delas 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 suuso.
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
deuna subrutina oprocedimiento (procedure), vase laFigura 3-19, correspondien-
'n7 Comienzo
S,"',,;"' j
~Fin
Comienzo ComienzoA
ComienzoB ComienzoC
Retorno
Fin Fin
Fin Fin
(a) (b)
FIGURA 3-19. Diferencia entre la ej ecucin de las rutinas y las corutinas de un
programa HLL. (a) Subrutina en una j erarqua. (b) Corutinas en una heterarqua.
3 A diferencia de las rutinas, las corutinas no devuelven el control al lugar del cdigo donde se
hizo lallamada, sino aotro distinto establecido previamente.
4 Cuando existe una corutina maestra que controla laejecucin delas dems, al modelo deejecu-
cin' seledenomina basado en semicorutinas.
168 VHDL. Lenguaje estndar de Diseo Electrnico
te aun cdigo jerarquizado, el flujo decontrol correspondiente auna ejecucin por
corutinas seadapta muy bien al paradigma correspondiente alaheterarqua depro-
cesos VHDL. Donde, en cada paso de simulacin, el flujo de control pasara de
proceso en proceso hasta llegar al kernel cuando todos sehubiesen parado.
Si intervienen variables compartidas, entonces cualquier implementacin se-
cuencial o paralela del programa correspondiente al modelo de simulacin va ade-
pender del orden deejecucin delas corutinas odelos procesos respectivamente.
3.4.2. Simulador VHDL
La Figura 3-20 muestra la organizacin de un simulador VHDL, poniendo en evi-
dencia lainteraccin entre el programa ejecutable (Target Software, TS) y el entorno
dedepuracin (Debugger). El simulador deVHDL ejecuta el TS deforma 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 seespecific
VHDL Simulator
Procedural & User Interface
Figura 3-20. Organizacin de un simulador VHDL.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 169
10 20 30 40 50 60 (nsl
Bl I
bl <~inertial A after 10ns;
B2
b2<;transport A alter 10ns;
b3<Ce reject 4 ns inertial A alter 10ns;
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 dediseo 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,
serealiza en trminos correspondientes al fuente VHDL descrito por el diseador.
Para poder realizar dichos anlisis, el entorno de depuracin tiene sus propias es-
tructuras dedatos y su propia funcionalidad, que es similar alade un depurador de
software (Software Debugger}. A diferencia de este ltimo, los resultados corres-
pondientes alaejecucin del modelo de simulacin no semuestran en trminos ab-
solutos, sino relativos al avance del tiempo de simulacin. Para ello se suelen em-
plear las representaciones tpicas5 de las formas de ondas o tambin denominadas
cronogramas, vase laFigura 3-21.
La ejecucin secuencial del TS genera un nico proceso, por lo que en cual-
quier momento dicho proceso podr estar en uno delos dos nicos estados posibles:
parado o en ejecucin, vase la Figura 3-22. Cada vez que el TS separa, el entorno
dedepuracin puede mostrar al diseador deVHDL el resultado delaejecucin del
modelo desimulacin.
Sin embargo, en una ejecucin concurrente pueden ser varios los procesos que
segeneren y cada uno deellos puede estar, asu vez, en estado deejecucin o para-
do, por lo que la ejecucin controlada de estos procesos resulta ms complicada.
Esta situacin sepuede simplificar si seorganiza laejecucin delos procesos resul-
tantes en grupos, vase laFigura 3-23. En cualquier caso, el estado del TS sepuede
monitorizar derivando el flujo de control de su ejecucin. Esta operacin sepuede
5 Adems de corresponder los resultados de simulacin con el cdigo fuente, como en cualquier
depurador de software, tambin seutilizan representaciones deesquemas y cronogramas.
170 VHDL. Lenguaje estndar de Diseo Electrnico
Sequental implementation
Kernel Process
Elaborated Procesa
0 0 0 0
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 deuno odevarios objetos, .
La simulacin o depuracin de un TS concurrente es mucho ms complicada
que la de uno secuencial, dehecho, la depuracin deprogramas concurrentes es un
problema deinvestigacin no resuelto todava. Sinembargo, unaprimera aproxima-
cin ala depuracin de un modelo concurrente consiste en considerar cada proceso
de forma aislada y aplicarles acada 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 laejecucin
paralela de los correspondientes modelos de simulacin VHDL y mucho menos su
Kernel Process
Parallel implementation
(~-)
Elaboreted Process
0 0 0 0
FIGURA 3-23. Estados de los procesos generados por la ejecucin concurrente del
modelo de simulacin VHDL.
3. Procesado y mecanismos de simulacin del lenguaje VHDL 171
posterior depuracin. Finalmente, cabe destacar laposibilidad 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 deeste interfaz es posible realizar entornos dece-simulacin VHDL pa-
rasistemas hardware-software oelectrnico-mecnicos [39-42].
3.5. MODELADO EN VHDL PARA SIMULACIN
Una descripcin en VHDL sepuede 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.
Modellnput
VHDL Description
(Stimuli Generator)
VHDL Description
(Iest Bench)
Model
Modal Generation
VHDL
Synthesis Tool
Physical
Test Bench
Computar Aided
TastTool
VHDL
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 sepretende no es otra cosa que exa-
minar el resultado de poner a prueba el modelo de simulacin correspondiente al
sistema que seest estudiando. Para poder llevar acabo este propsito es necesario
contar con la descripcin VHDL de la entidad de diseo correspondiente a dicho
sistema (Unir Under Test, UUT) y con ladescripcin VHDL delaentidad dediseo
correspondiente al sistema que genera las pruebas iStimuli Generator, SG) que se
desean ejercitar en la simulacin. Sin embargo, ladisponibilidad de ambas entida-
des dediseo no es suficiente para poder llevar acabo la tarea de simulacin. Ade-
ms de contar con ambas entidades de diseo, es necesario contar con la descrip-
cin en VHDL deunatercera entidad dediseo, lacorrespondiente al entorno (Test
Bench, TE) en el que sevan arealizar dichas pruebas y, por supuesto, con el simu-
lador VHDL y el ordenador en el que dicha herramienta seejecuta.
La entidad de diseo VHDL correspondiente al banco de pruebas carece de
funcionalidad por s mismo, ya que setrata 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 sepuede seleccionar una nica entidad dedi-
seo VHDL.
La red de procesos VHDL que componen el modelo abstracto de simulacin
contiene tanto los procesos resultantes de la elaboracin de lajerarqua de diseo
con laque sehadescrito laUUT como los que resultan delaelaboracin delaenti-
dad de diseo SG, sin ningn tipo de distincin o de separacin. As es como se
consigue que la simulacin del modelo abstracto dela entidad dediseo VHDL co-
rrespondiente al TE sea equivalente ala realizacin delas pruebas sobre el modelo
fsico correspondiente ala UUT, que sellevaran acabo en el banco o entorno fsi-
co del equipo depruebas (TE), vase laFigura 3-24. A suvez, dicho TB fsico pue-
deser muy variado, correspondiendo tanto aun entorno real defuncionamiento, por
ejemplo, latarjeta (PCB) donde sepodra probar un circuito integrado deaplicacin
especfica (Application Specific Integrated Circuit, ASIC), hasta el entorno deprue-
bas conectado aun sistema depruebas automatizado por ordenador (Automatic Test
Equipment, ATE), por ejemplo, el equipo depruebas que seutilizara para probar si
unASIC sehafabricado 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 desntesis deVHDL as como del ordenador en el que dicha herramienta
seejecuta. Esta diferencia pone de manifiesto el hecho deque el proceso desimula-
cin del modelo abstracto correspondiente auna determinada UUT es equivalente a
lacombinacin delos procesos desntesis y prueba del modelo fsico que secorres-
pondera con dicha UUT, vase laFigura 3-24.
Si el entorno depruebas automatizado por ordenador tambin acepta como len-
guaje de descripcin delas pruebas VHDL o en un subconjunto del mismo, enton-
ces no hay ninguna diferencia entre las descripciones VHDL correspondientes ala
entidad de diseo generadora delas pruebas (SG) necesarias para poder llevar aca-
bo lasimulacin 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 Sinembargo, en el caso delas pruebas fsicas delaUUT, da-
doqueel entorno o banco depruebas (Test Bench] tieneentidad fsica, ladescripcin
VHDL delaentidad dediseo correspondiente adicho TB es totalmente innecesaria.
Finalmente, otra diferencia entre el modelado en VHDL para realizar una si-
mulacin opara llevar acabo un proceso de sntesis dehardware 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 depoderse llevar a
cabo tambin en varias fases, puede ser un proceso iterativo, vase la doble flecha
delaFigura 3-24, En estecaso ladescripcin VHDL resultante delaprimera 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 asuvez entrada deuna sntesis lgica (Logic Synt-
hesis) apartir dela 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 seha establecido previamente, vase la doble flecha de la Fi-
gura 3-24. Aunque quiz s vale lapena destacar que ladescripcin 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 lasimulacin.
3.5.1. Simulacin lgica, temporal y de fallos
Por razones histricas y debido aque durante mucho tiempo el mayor nivel de abs-
traccin al que los sistemas electrnicos sepodan modelar, para poder llevar acabo
susimulacin, erael nivel depuertas lgicas (Gate Level), alas simulaciones dees-
tetipo desistemas seles denomin simulaciones lgicas. Trmino que sehamante-
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 dediseo HDL estn descritas adistinto nivel de
abstraccin (Behavioral, Register Transfer; Gate Level).
El adjetivo desimulacin lgica sedebe al nfasis que sehaca y todava seha-
ceal diferenciar el propsito dela mera simulacin del comportamiento lgico con
las simulaciones temporal y de fallos. Estas simulaciones serealizan 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 desimulaciones todava serealizan anivel depuertas
lgicas, por medio de modelos que describen la lista de puertas que componen la
red {netlist) que describe al sistema electrnico. Para ello slo seutiliza un subcon-
junto del HDL, en el caso deVHDL dicho subconjunto es el standard VITAL.
174 VHDL. Lenguaje estndar de Diseo Electrnico
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 delas
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.~temotivo, 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). Lacapacidad 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 laque 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
.utilizapara este propsito es el stuck-at (estancamiento), en el que seconsidera que
los fallos defabricacin sepueden corresponder con el estancamiento a loa Odel
valor que adquieren las puertas lgicas. Hay que recordar que, por ser ste asu vez
unmodelo defallos, incluso si con unas determinadas pruebas sediese una cobertu-
radel 100por 100del circuito, aun as, no querra decir que si el ASIC pasase todas
estaspruebas sera correcto.
Normalmente serequiere una cobertura superior al 95por 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
desntesis. Por ello, en laFigura 3-24 sehaincluido 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
dequeel ASIC sehafabricado adecuadamente probndolo en el ATE.
3.6. EJERCICIOS
1. Describe el significado derealizar una simulacin en unordenador.
2. Describe el mecanismo desimulacin dirigido por eventos discretos.
3. Cul es la diferencia entre el modelo temporal Zero-delay y el Unit-delay't
Deduce apartir deambos el modelo correspondiente alasimulacin VHDL.
4. Qu medios se emplean para especificar la sintaxis y la semntica de los len-
guajes deprogramacin?
5. Qu es un formato intermedio decompilacin y qu relacin tiene con una es-
tructura dedatos detipo rbol sintctico abstracto (AST)?
6. En qu separece y en qu sediferencia un HDL y unHLL?
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 lasjerarquas deundiseo descrito enVHDL?
9. Describe los dos tipos dejerarquas que sepueden 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 larelacin existente entre el determinismo de una descripcin VHDL,
su portabilidad y la forma en que se realiza la implementacin del programa
correspondiente asu modelo desimulacin?
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 lainicializacin 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
l
VdHDL ~~y dosdmoldel~s te~poradies
l
,cUldes
l
sOd
n
y .CUl es. ~u ,...
Inuencia en e .etermnnsmo e a ejecuci n e mo e o e simu acron 1
VHDL? j
j
j
1
,
16. En qu se diferencia una descripcin VHDL de un modelo desimulacin y de
un simulador VHDL?
17. En qu se parece y en qu se diferencia un simulador VHDL de undepurador
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 demanufactura 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
Y ork, N, Y ., March 1994. .
[2] M. R. BARBACCI, T. UHEARA:"Computer Hardware Descrpton Languages: Too Bridge
Between Software andHardware". 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 aMooem Synthesis". Vol. 2, J oOOWiley & Sons,
Ine. 1989.
3. Procesado y mecanismos de simulacin del lenguaje VHOL 177
[5] G. J . LIPOVSKY: "Hardware Description Languages: Voices from the Tower of Babel".
IEEE Computer Vol. 10, J une 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 inComputer Scienee 151, Springer-Verlag 1983.
[8J 1. D. MORISON, N. E. PEELING, T. L. THORP:"The Design Rationale of ELLA, aHardwa-
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 J apan". 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: J ohn Wiley,
1987.
[14] M. PIDD: "Computer Modelling for Discrete Simulation". Chiehester, U.K.: J ohn 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, J a-
pan, Oetober 1994, pp. 135-138,
[25] D. D. GAJ SKI,F. VAHID, 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". J ohn-Wiley Professional Computing, 1993.
[27] R. K. GUPTA:"Co-Synthesis of Hardware and Software for Digital Embedded Sys-
tems". Kluwer Aeademic Publishers, 1995.
178 VHDL. Lenguaje estndar de Diseo Electrnico
[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 inComputer Science, 1991.
[31) S. OLCOZ,J . M. COLOM:"VHDL Through tbe Looking Glass", VHDL_Forum for CAD
inEurope 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 aVHDL Design Manager: VRBL-lCE". VHDL International Users Forum, Spring
1997Conference, 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 J ose, CA, pp. 33-42.
[37] S. OLCOZ,P. MENCHlNl:"HDL Interoperability: A Compiler TechnoIogy Perspective".
VHDL International Users Forum, Fall1996 Conference, Sant J ose, CA, pp. 51-58.
[38] S. OLCOZ,L. ENTRENA, L. BERROJ O, 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. BERROJ O, 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. BERROJ O:"VHDL Virtual Prototyping". 6th IEEE IntI.
Workshop onRapid SystemPrototyping, Chapel Hill, NC, J une 1995.
[41] S. OLCOZ,L. ENTRENA, L. BERROJ O: "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. BERROJ O: "AnEffective 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 deCantabria
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 VHDLconstituye 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 VHDLen 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 VHDLen 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
180 VHDL. Lenguaje estndar de Diseo Electrnico
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 seutilizan en un amplio rango deaplicaciones como siste-
mas decmputo depropsito general, sistemas embebidos, sistemas detelecomuni-
cacin, sistemas decontrol, electrnica aeroespacial, del automvil y electrnica de
consumo. Las herramientas CAD representan el medio para disear estos sistemas
con lafiabilidad y laproductividad 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 deanlisis 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 depatrones detest 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 laherramienta de sntesis (de
laque en muchas ocasiones no sedistingue), laherramienta deoptimizacin permi-
temejorar lacalidad del diseo aun determinado nivel deabstraccin en funcin de
los parmetros definidos por el usuario (coste, velocidad, consumo, etc.).
Las herramientas CAD hacen uso denotaciones dediseo, ya sean explcitas o
transparentes para el usuario. Las notaciones explcitas son aquellas relevantes para
el diseador. Entre ellas, cabe citar las tablas deverdad y deestado (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 alos que el usuario normalmente no
tiene acceso y en muchos casos ni siquiera tiene conocimiento desuuso. 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 dedescripcin dehardware (HDLs) representan un medio dedescrip-
cin explcito del circuito adisear. La novedad aportada por los HDLs reside en la
utilizacin de conceptos de ingeniera del software ala descripcin y modelado de
hardware. Sintcticamente, los lenguajes dedescripcin dehardware resultan en ge-
neral muy similares a lenguajes de programacin. De hecho, en muchos casos, el
lenguaje dedescripcin dehardware sederiva deun lenguaje deprogramacin. 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 dehardware y los lenguajes deprogramacin tiene consecuencias en su
4. Sntesis 181
uso, particularmente en sntesis. Como comentaremos posteriormente, el diseador
no debedeolvidar que, aunque lasintaxis sea similar aladeun lenguaje deprogra-
macin, el objetivo del cdigo es ladescripcin del hardware que sequiere obtener.
Si este hecho no es tenido en cuenta, los resultados obtenidos de la herramienta de
sntesis pueden no ser satisfactorios. Deheclio, laherramienta desntesis no evita el
diseo lgico. Las decisiones dealto nivel respecto alaarquitectura del circuito, su
funcionalidad, componentes einterconexin, comunicacin con el exterior, frecuen-
cia de funcionamiento, etc., siguen siendo responsabilidad del diseador y la cali-
dad del diseo va aseguir 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
Implementacin
Retroanotacin
FIGURA 4-1. Proceso de sntesis.
182 VHDL. Lenguaje estndar de Diseo Electrnico
tas de sntesis especficas, independientemente deque en algn caso un entorno de-
terminado soporte conjuntamente varios de ellos. Las dos herramientas de sntesis
ms importantes en laactualidad son laherramienta desntesis RT-lgica y laherra-
mienta de posicionamiento einterconexin. 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 aaparecer en el mercado las primeras herramientas de sntesis decompor-
tamiento. Se trata todava de una tecnologa con muy escasa penetracin industrial
y comercialmente inmadura. Esta es larazn por laque queda fuera delos 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 delaFigura 4-1, desde el nivel funcional alaimplementacin final.
Aunque la sintaxis del lenguaje es comn a los tres niveles, la interpretacin
del cdigo, o semntica, va aser diferente en cada nivel. Tal y como sepropone en
[E95], una descripcin VHDL puede caracterizarse en funcin de tres aspectos: la
temporizacin, los tipos dedatos 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 dediseo sepueden distinguir tres niveles detemporizacin. 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 decada componente, teniendo en cuenta el retraso adicional introducido
por la carga representada por los componentes alos que seconecta ala 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 alas interconexiones, lo que
completa el nivel de detalle propio de la implementacin final. A nivel RT,
los retrasos de los componentes del circuito no seconocen. Sin embargo, las
acciones (transferencias aregistros 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 decircuitos sncronos constituye
latecnologa de sntesis ms importante y utilizada en laactualidad. Por ello,
ladescripcin VHDL aeste nivel vaarepresentar el objetivo principal dees-
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, laplanificacin delas
4. Sntesis 183
distintas acciones todava no sehadecidido y slo las relaciones causales de-
terminadas por las dependencias entre datos son relevantes [MLD92][M94].
Ejemplos deeste estilo demodelado semuestran 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, natural,
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-
desituarse en alguno delos puntos del cubo dediseo representado en laFi-
gura4-2.
RT
Bits
Compuestos
Lgico """"-""'-"''''''-'''''''--''--_~~'--''''''''''''''!!'::.:.c'''_--",=:___
Estructural Flujo de datos Algortmico
FIGURA 4-2. Cubo de diseo.
184 VHDL. Lenguaje estndar de Diseo Electrnico
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
I
001 .. 011
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 dereloj 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:
l i br a r y I EEE;
us e I EEE. s t Q_ l o gi c _ 1164. a l l ;
us e I EEE. nume r i c _ s t d. a l l ;
e nt i t y mul t i pl i c a do r i 8
port {da t a bus _ i n in uns i gne d ( 32 do wnt o 1) :
da t a bus _ o ut o ut uns i gne d ( 32 do wnt o 1) ;
s t a r t in s t Q_ u1o gi c ;
r e 1o j , r e s e t in s t Q_ ul o gi c ;
ends o ut s t Q_ ul o gi c l ;
end mul t i pl i c a do r ;
LISTADO 4-1. Declaracin de laentidad multiplicador'.
El punto departida del proceso dediseo desde el nivel funcional es ladescrip-
cin VHDL del algoritmo hardware a implementar. As, la descripcin funcional
del algoritmo demultiplicacin es laque semuestra 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 sehar en el ejemplo demodelado del Captulo 5, la simu-
lacin del cdigo funcional del Listado 4-2 permite comprobar que el algoritmo uti-
lizado es correcto en laobtencin 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 deobtencin dedatos (multipli-
cando y multiplicador) y de salida del resultado estn determinados en lapropia es-
pecificacin. Sin embargo, el nmero de ciclos para realizar la acumulacin del
multiplicando no lo est y constituye laprimera decisin importante de diseo. De-
pendiendo del retraso, en nmero de ciclos de reloj, los requerimientos hardware
van avariar. Los requerimientos hardware van adeterminar, 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)
IEn esta descripcin es necesario utilizar un puerto deentrada y otro de salida para el "bus" afin
deevitar problemas de simulacin con seales resueltas del tipo inout.
186 VHDL. Lenguaje estndar de Diseo Electrnico
architecture funcional Qf multiplicador is
begi n
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 EAMQ(63 downto 32)
alias MQ: urislgnd (32 downto 1) is EAMQ (31 downto O);
begi n
wait until reloj = ' l 'and start = ' L' ;
MIl : = da t a bus _ m;
wait until reloj = '1.' ;
MQ := da t a bus _ i n;
FA := To_unsigned (0,33);
for 1 in Oto 31 loop
if MQ(1) = '1' then
FA := FA+ MIl;
end if;
EAMQ := EAMQ sr1 1;
end loop;
ends <= '1';
da t a bus _ o ut <= MQ;
wait until reloj = '1; ;
ends <= 'O';
da t a bus _ o ut <= A;
end process;
end funcional;
LISTADO 4-2. Algoritmo hardware de multiplicacin de nmeros naturales.
del esquema delaFigura 4-3 que semuestra enlaFigura 4-4. El nmero desuma-
dores es de31, yaque laprimera suma con el acumulador acero no precisa deun
sumador.
Enlamayora delas ocasiones, estaimplementacin vaatener uncoste excesi-
vo en trminos de puertas y consumo. Por otro lado, aunque resulta lams rpida
en trminos deciclos dereloj, 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 larealizacin delamultiplicacin combinacional co-
mooperacin multiciclo [MLD92].
Al objeto deminimizar los recursos hardware requeridos, una alternativa es la
utilizacin deun nico sumador y larealizacin delas acumulaciones enciclos de
reloj sucesivos. Laarquitectura RT resultante es ladelaFigura 4-5. Setrata deuna
tpica arquitectura anivel detransferencia entre registros en laquetodas las accio-
nes en cada ciclo de reloj estn definidas. Consta de dos unidades. La Unidad de
Datos (UD) incluye los recursos hardware entrminos deregistros, Unidades Ope-
racionales (UOs) einterconexiones, yasean "buses" omultiplexores. LaUnidad de
4. Sntesis 187
FIGURA 4-4. lgica combinacional para multiplicacin en un ciclo.
start
ends
FIGURA 4-5. Arquitectura RT para multiplicacin secuencial.
188 VHDL. Lenguaje estndar de Diseo Electrnico
Control (VC) es la encargada de decidir las acciones (microoperaciones) aejecutar
en laVD en cada ciclo dereloj. LaVCseimplementa usualmente como una mqui-
nadeestados finitos (FSM).
A partir deesta arquitectura, ladescripcin VHDL para sntesis RT es el Lista-
do 4-3.
En esta arquitectura se ha decidido la ejecucin secuencial de las 32 sumas en
32ciclos dereloj mediante laimplementacin del lazo en laejecucin cclica delos
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 seretorna al estado deespera.
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 laimplementacin combinacional directa delaFigura 4-4 yla
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 aconsti-
tuir el objetivo principal deeste captulo.
La sntesis RT-lgica conlleva una serie deprocesos deminimizacin 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 sedes-
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 deestas transformaciones, correspondiente al paso 2en el cubo dediseo,
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 delos ele-
mentos de biblioteca correspondientes. En el cubo de diseo los pasos recorridos
hasta este modelo secorresponden 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)2y final (Listado 4-5). El resto van aser descrip-
ciones correspondientes arepresentaciones intermedias del diseo que no van are-
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 desntesis RT-lgica.
4. Sntesis 189
architecture FSMDof multiplicador i s
begi n
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 I Nl'EGER range Oto 31;
begi n
ifreset :; '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.
190 VHDL. Lenguaje estndar de Diseo Electrnico
a r c h i t e c t u r e f l u j o d e d a t o s o f mu l t i p l i c a d o r i s
s i g n a l MI l : u n s i g n e d ( 3 2 d o wn t o 1 ) ;
s i g n a l EAM;;): u n s i g n e d ( 6 4 d o wn t o O) ;
s i g n a l s t a t e : u n s i g n e d (2 d o wn t o O);
s i g n a l 1: u n s i g n e d (4 d o wn t o O);
b e g i n
s t a t e <=
0 0 0 " when r e s e t = ' 1 ' e l s e
0 0 1 " when r e l o j =. ' 1 ' and r e l o j ' E VE NT
and s t a t e = " 0 0 0 " a n d s t a r t = ' 1 ' e l s e
0 1 0 " when r e l l >j = '1' a n d r e l o j ' E VE NT a n d s t a t e = " 0 0 1 " e l s e
"011" when r e l o j = '1' a n d r e l o j ' - E VE NT and s t a t e = " 0 1 0 " e l s e
1 0 0 " when r e l o j = '1' a n d r e l o j ' E VE NT
a n d s t a t e = 0 1 1 " a n d 1= 3 1 e l s e
0 1 0 " when r e l o j = '1' and r e l o j ' E VE NT
a n d s t a t e = " 0 1 1 " a n d 1 /= 3 1 e l s e
1 0 1 " when r e l o j = '1' a n d r e l o j ' E VE NT a n d s t a t e = " l OO. " e l s e
0 0 0 " when r e l o j = '1' and r e l o j ' E VE NT and s t a t e : : 1 0 1 " e l s e
s t a t e ;
d a t a b u s _ o u t <=
E AMQ( 6 3 d o wn t o 3 2 ) when r e l o j = ' 1 ' a n d r e l o j ' E VE NT
a n d s t a t e . = 100' e l s e
E A M Q ( 3 1 d o wn t o O) when r e l o j = ' 1 ' a n d r e l o j ' EVOO'
a n d s t a t e = " 1 0 1 " e l s e
d a t a b u s o u t ; . .
M D <= d a t a b u s _ i n when r e l ( >j " ; ' l ' and r e l o j ' EVEN T
a n d s t a t e : : 000' and s t ~ 'F '1' e l s e
MI l ;
E A M Q <= . . . ;
1<= . . . ;
ends <= . . . ;
e Dd f l u j o d e d a t o s ;
LISTADO 4-4. Descripcin en flujo de datos del multiplicador secuencial.
querir, en general , de sudescripcin en VHD L y que sl o van aafectar al os forma-
tos internos derepresentacin del diseo util izados por l aherramienta concreta que
se util ice. E n cual quier caso, el ejempl o muestra distintos estil os descriptivos en
VHD L que pueden ser util izados por el diseador en l adescripcin para sntesis de
parte odel atotal idad del circuito.
4.1.2. Modelado para simulacin frente a modelado
para sntesis
VHD L fue desarrol l ado como un l enguaje para el model ado y simul acin l gica di-
rigida por eventos discretos de sistemas digital es. Se trata de un l enguaje con una
4. Sntesis 191
architecture estructura of multiplicador is
----- Component NA2 -----
camponent NA2
generic(
TimingChecksOn: J 3t)0~ :=~f~ltT.iI!l,i.n9ChechsDn;
XGenerationON: !3oQlea! ':=PfaltXGeneraonOn;
S TR iNG :="~'; IlstancePath:
tpd...]\,_Q:
tpUl_Q:
tipd_}l.:
tipd_B:
port(
DelayTypeOl .- fO.340 ns. 0.040 ns);
DelayTypeOl .- (O.34')l3, 'l).O(O fis)'
DlyTypeOl .- " (O,OOO('ruC'O; OOris);
_._" C ... __ ,
nelayTypeOl .- (0.000" 11S ; 0;000 ns~;
A: in S TD_IroIC:
B: in S TD_LOGIC;
Q: out S TDJ ,OOIC);
end camponent;
----- Component DF 8 ~--.-
camponent DFB
generic(
TimingChecksOn:
XGenerationON:
InstancePath:
tpd_C_Q:
tpd_C_QN:
Bbolean :=DefaultTimingChechsOn;
s061ean :=Defaltimenefati~nOn';
S TR IN:; : = ... ;
DelayTypeOl :=(1. 800 ns, 1:890 ns); .
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,
tipd_C: DelayTypeOl :" ,. (}~,OOO ns,
0.000 n8);
0.OQOn8;
port(
D: in S TD..,.ILCIC;:,~
C: in s:ro-r..cx;I~hf
Q: out S TD_!fl'IC;,,\,
QN: out S TD.)lYftcr;
end camponent;
begin
state_2 : DF8port map( st.te;;;.2.2,d,reloj,state(2li ~tU6 )i
state_l : DF8port 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" " ,tJ Il)
end estructura;
LISTADO 4-5. Implementacin del multiplicador secuencial.
192 VHDL. Lenguaje estndar de Diseo Electrnico
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 desimulacin 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 deun circuito o sistema aun determinado nivel deabstraccin 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 deVHDL en aplicaciones de sntesis sedescribirn alo largo deeste
captulo. Estas particularidades se refieren tanto arestricciones sintcticas sobre el
cdigo como alainterpretacin semntica del mismo. En el Captulo 3sehahecho
un estudio ms detallado de las diferencias y similitudes entre el procesado de un
HDL para simulacin y sntesis.
Lautilizacin deuna herramienta desntesis asegura laconcordancia funcional
entre laimplementacin obtenida y ladescripcin deentrada apartir de lainterpre-
tacin hardware que la herramienta hace de este cdigo. Aunque desde este punto
devista el diseo resultara correcto por construccin, laverificacin 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 acontinuacin.
En consecuencia, tanto ladescripcin de entrada ala sntesis como laresultante de
la misma deben de ser verificadas por simulacin. Simulacin es, pues, una tarea
horizontal aun determinado nivel de abstraccin. Sntesis, por el contrario, es una
tarea vertical entre niveles de abstraccin. Esta diferencia seha mostrado en la Fi-
gura 1-6del Captulo 1y en laFigura 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 seaplican algoritmos desntesis 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 desntesis disponibles en laactualidad.
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 lacarencia deuna semntica hardware en la definicin del lengua-
je. Este hecho contrasta con la utilizacin deVHDL para simulacin. En este caso,
la semntica del lenguaje est perfectamente definida y los resultados van a ser in-
dependientes del simulador que seemplee.
4. Sntesis 193
La utilizacin deVHDL en sntesis presenta dos caractersticas principales. Por
un lado, las restricciones sintcticas y semnticas que se imponen al lenguaje. Por
otro, las discrepancias que sevan aencontrar 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 delos atributos predefinidos, etc. Dehecho, 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 asimulacin deuna determinada construccin, en reali-
dad, su mayor o menor sentido hardware, no constituye, en s misma, larazn 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) serauna 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.) dela
implementacin correspondiente. Las restricciones sintcticas y semnticas impues-
tas al cdigo por las herramientas de sntesis provienen dela necesidad de asegurar
una eficacia mnima en el proceso desntesis.
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 ala 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 deasegurar una eficiencia suficiente en el proceso de sntesis, las he-
rramientas imponen restricciones sintcticas en ladescripcin VHDL deentrada. El
problema que seplantea 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 alas particularidades de las principales herramientas comercia-
les. La principal consecuencia delacarencia deun subconjunto comn para sntesis
es ladificultad dereutilizacin deuna descripcin desarrollada para una herramien-
taen otra.
194 VHDL. Lenguaje estndar de Diseo Electrnico
pr oc es s
begi n
i f x l = ' O' t hen
z <= ' O ' i
wait en x l ;
el s i f x 2 = ' O' t hen
z <= 'O';
wait en x2;
el s e
z <= '1';
wait until x l or x2;
end i f ;
end pr oc es s ;
X1=[)_Z
X2
FIGURA 4-6. Modelo e implementacin de una funcin ando
4.2.2. Discrepancias entre resultados
de simulacin
Lasegunda caracterstica, propia delautilizacin deun lenguaje como VHDL en
sntesis, serefiere alas discrepancias entre los resultados de simulacin-antes-de-
sntesis, enlaqueel comportamiento deseado enladescripcin deentrada sevali-
da, y los de la simulacin-despus-de-sntesis, en laque el comportamiento del
hardware resultante severifica. Estas discrepancias sondedos tipos, discrepancias
temporales y discrepancias devalor.
Las discrepancias temporales seproducen como consecuencia dequedurante
el proceso desntesis sedeciden los elementos lgicos quevan acomponer laar-
quitectura RT inicial. Estos elementos lgicos (puertas, "latches", biestables, etc.)
llevan asociados retrasos queno seconocan antes delasntesis. Lasimulacin de
laarquitectura RT es unasimulacin enciclos dereloj. Lasimulacin lgicaes una
simulacin basada enlos retrasos concretos delos elementos lgicos enlatecno-
loga dedestino. A pesar deestas discrepancias temporales, lacorreccin del pro-
ceso desntesis estar asegurada si para cualquier seal A laforma deondaWA)
resultante delasimulacin-antes-de-sntesis coincide conlaformadeondaWA
o
re-
sultante de la simulacin-despus-de-sntesis, al menos en aquellos perodos de
tiempo enlos quesuvalor puede afectar al comportamiento del circuito. Endiseo
sncrono, dichos perodos corresponden al tiempo enel quelas seales sonevalua-
das, usualmente, el tiempo de"set-up" delos biestables. En diseo asncrono, di-
chos perodos detiempo estn deterininados por las seales derequerimiento y re-
conocimiento enel mecanismo deinterfase correspondiente (Figura4-7).
4. Sntesis 195
Forma de onda WA
1
t "
(antes de sntesis) i 1' :
I "
I
::
, ,
::
-i--~--------- ---_;_---~-~
Forma de onda WA
o
+ ,
(despus de sntesis) n L -__ __---I _-_ __I --: . -----" __ -+ __
: Perodo de : t
.comcareccn :
FIGURA 4-7. Discrepancias temporales.
L as discrepan cias en tre los resultados de simulacin -an tes-de-sn tesis y los de
la simulacin -despus-de-sn tesis pueden afectar tambin alos valores de las sea-
les. Estas discrepan cias de valor se producen por dos motivos. Por un lado, como
con secuen cia de la codificacin lgica, usualmen te std__ulogic o bit de tipos de
datos en umerados y en teros. Por otro, por la in terpretacin en sn tesis de los meta-
valores delos tipos y std_ulogic que secomen tar posteriormen te. A
pesar de estas discrepan cias de valor, la correccin del proceso de sn tesis estar
asegurada si para cualquier seal A la forma de on da WA
o
resultan te de la simula-
cin -despus-de-sn tesis es un caso particular de la forma de on da WA resultan te
de la simulacin -an tes-de-sn tesis un a vez las discrepan cias temporales han sido
con sideradas, como en el ejemplo delaFigura 4-8.
En el caso gen eral, estas discrepan cias en tre el comportamien to esperado y el
resultan te son peligrosas y pueden dar lugar aimplemen tacion es errn eas. Es n ece-
sario, por ello, establecer un a metodologa de uso de la herramien ta de sn tesis
VHDL que sevaya aemplear apartir del con ocimien to dela semn tica y los algo-
ritmos que utilice en cada etapa desn tesis.
4.3. SNTESIS RT-LG1CA
En esteapartado sehace un abreve in troduccin alos modelos desistemadigital utili-
zados por las herramien tas de sn tesis y a los pasos de sn tesis que aplican . Sn tesis
RT y sn tesis lgica utilizan modelos y algoritmos distin tos. Sin embargo, desde el
momen to en queambas tareas serealizan con jun tamen te en lasherramien tas desn te-
sis actuales, parael diseador aparen tan un n ico proceso. Al objeto delograr los me-
jores resultados es importan te el con ocimien to delos pasos con cretos en cada caso.
196 VHDL. Lenguaje estndar de Diseo Electrnico
Forma de onda WA,
(antes de sntesis)
Forma de onda WA
o
(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 deelementos dememoria que almacenan el es-
tado actual delamquina segn el esquema clsico delaFigura 4-9.
El proceso desntesis lgica sedivide 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 demapeado tecnolgico los elementos delabiblioteca en la
tecnologa utilizada (celdas estndar, mar depuertas, FPGA, PLD, etc.) seseleccio-
nan einterconectan al objeto de satisfacer lafuncionalidad y las restricciones dedi-
seo. Ambas tareas, optimizacin lgica y mapeado tecnolgico, son realizadas efi-
cientemente por las herramientas de sntesis comerciales disponibles en la actuali-
dad y, dehecho, constituyen el ncleo principal delas mismas.
4.3.2. Sntesis RT
El modelo de sistema digital utilizado por las herramientas desntesis anivel RT es
unaextensin 3del modelo deHuffman 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
Lgica
combinacional
~
1---
e
al
est
Elementos
<j
de
memoria
/\
Salidas
Seales d
estado actu
Seales de
ado prximo
J e , R 1 . . .
R eloj
FIGURA 4-9. Mquina secuencial sncrona de Huffman.
laUni dad de Control (UC), y
laUni dad de Datos (UD),
se gn e l e sque ma de laFi gura 4-10.
En laUni dad de Datos e s donde ti e ne n lugar las di sti ntas ope raci one s, transfe -
re nci as de i nformaci n y almace nami e nto de datos e n re gi stros. La UD se consti tu-
ye usualme nte de uni dade s ope raci onale s (OPs), buse s, multi ple xore s y e le me ntos
de me mori a como latches, re gi stros y mdulos RAM y ROM
4

La Uni dad de Control e s la e ncargada de de ci di r e n cada ci clo de re loj las


transfe re nci as de i nformaci n que de be n de te ne r lugar e ntre re gi stros e n laUD as
como e l si gui e nte e stado de control a e je cutar. La UC se di se a usualme nte como
una mqui na de e stados fi ni tos (FSM).
El proce so de snte si s RT se di vi de usualme nte e ndos pasos:
snte si s de laUD,
snte si s de laUe .
La snte si s de laUni dad de Datos (UD) se di vi de usualme nte e n tre s pasos:
opti mi zaci n ari tmti ca,
i de nti fi caci n de los e le me ntos de me mori a,
e xtracci n de las funci one s lgi cas.
4 Los mdulos de me mori a RAM y ROM son consi de rados como e xte rnos a la de scri pci n RT
por lamayora de he rrami e ntas de snte si s.
198 VHDL Lenguaje estndar de Diseo Electrnico
Secuencacin
Entradas
de control
i)
UNIDAD
"-
I
DE CONTROL
I
v
~r
Seales
Seales
del status
de control
Q
l >
UNIDAD
I
I
DE DATOS
Salidas
de datos
Salidas
de control
Entradas
de datos
Cmputo
FIGURA 4-10. Modelo de sistema digital a nivel RT.
Estos pasos dependen fuertemente del estil o descriptivo util izado. Por l o gene-
ral , l a herramienta de sntesis real iza l a extraccin desde el cdigo VHDL perdien-
do l a informacin de al to nivel de partida. Su recuperacin requerira comenzar de
nuevo el proceso de sntesis desde l a descripcin VHDL. Este es uno de l os moti-
vos por l os cual es el estil o descriptivo util izado en el cdigo VHDL deentrada tie-
ne trascendencia en cuanto a l os resul tados de l a sntesis. Es importante, por el l o,
conocer l os mecanismos empl eados por l a herramienta de sntesis que seest util i-
zando al objeto de asegurar resul tados ptimos. Un caso tpico l o representan l os
operadores aritmticos y l as asignaciones indiferentes. Sinembargo, hay herramien-
tasque identifican l os operadores aritmticos como componentes durante el proceso
de sntesis. De esta manera, son capaces deconservar parte de l ainformacin deal -
to nivel durante el proceso de optimizacin l gica, permitiendo, por ejempl o, cam-
biar el tipo de impl ementacin del operador. Esta misma situacin se presenta con
l os el ementos de memoria. Una vez inferidos, su repercusin en el diseo no se
puede evitar durante el proceso desntesis.
La sntesis de l a Unidad de Control (UC) consiste fundamental mente en l a
identificacin y sntesis del autmata de control y se divide usual mente en tres pa-
sos:
identificacin del autmata decontrol (estados y transiciones),
minimizacin del os estados decontrol ,
asignacin secundaria.
Denuevo, en general , setrata detransformaciones destructivas respecto al ain-
formacin de entrada. Sin embargo, al gunas herramientas marcan el registro de es-
tados, l o que permite conservar esta informacin de al to nivel . Tanto l os al goritmos
de minimizacin de estados, sobre todo en el caso de mquinas incompl etamente
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 asu 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 ladescripcin VHDL deentrada.
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 sedesea. Como ya seha comentado, lacarencia 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
deconocimiento de la herramienta concreta que utilice, est en disposicin de ob-
tener los mejores resultados delamisma en un tiempo breve.
4.4.1. Descripcin del sistema
El sistema digital asintetizar sevaadescribir mediante una arquitectura asociada a
una determinada entidad en la que sedefinen los puertos del sistema. El proceso de
sntesis generar una nueva arquitectura asociada alamisma entidad.
Tal y como seha visto en el Captulo 2, la arquitectura VHDL est compuesta
delas siguientes sentencias concurrentes:
sentencias deasercin concurrente que son ignoradas,
bloques,
llamadas concurrentes aprocedimientos,
asignaciones concurrentes deseal,
referencia acomponentes,
procesos, y
sentencias de generacin que se sustituyen por el cdigo iterativo equiva-
lente.
Salvo en lo que respecta alas sentencias dereferencia acomponentes, lajerar-
qua seelimina 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 dejerarqua el cdigo asociado aun proceso, bloque o subprograma. Los ope-
radores aritmticos sontratados como componentes adicionales y optimizados inde-
200 VHDL. Lenguaje estndar de Diseo Electrnico
pendientemente. En algunos casos, laherramienta posee lacapacidad de asociar va-
rias operaciones aritmticas alamisma unidad operacional con objeto deminimizar
la lgica resultante (" resource sharing"). Las referencias acomponentes hacen re-
lacin aotras entidades que, usualmente, sesintetizan conservando o eliminando la
jerarqua mediante directivas deusuario alaherramienta.
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. Delas cuatro categoras de tipos escalares
definidos en el estndar, slo los enteros y enumerativos sonusualmente soportados
en sntesis. Los tipos fsicos y flotantes o son ignorados ono son admitidos.
Los tipos enteros se sintetizan como vectores de bits con ladimensin 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, laseal entera Temperature:
s i gna l T e r r pe r a t ur e isI nt e ge r r a nge - 75 te 120;
seimplementara en un conjunto de8bits:
8
Z' t>
con lasiguiente codificacin:
- 75 => 10110101
- 74 => 16110110
~:
119 => oiuciu
120
=> 01111000
Los tipos enumerativos se sintetizan como vectores de bits con la dimensin
adecuada al nmero devalores distintos con que sehallan 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 lacodifica-
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 ;
- - RE D = 010
- - GRE E N = 000
- - YE L L OW = 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 secomenta acontinuacin.
Con respecto alos tipos compuestos, lamayora delas herramientas de sntesis
soportan matrices unidimensionales, usualmente debits y en algn caso deenteros.
El tipo registro (record) es soportado por muy pocas herramientas.
4.4.3. Funcionesy 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 deuna potencia de 2. Como sever ms adelante, esta operacin es til en
ladescripcin decontadores.
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 laherramienta.
Todas las herramientas de sntesis incluyen paquetes defunciones 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:
202 VHDL. Lenguaje estndar de Diseo Electrnico
4.4.4.1. Interpretacin hardware de tipos estndar
En esta seccin sedefine el modo en el que laherramienta desntesis debe deinter-
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', - 1fuerte
'Z', - Alta inpedancia
'W', - Valor debil desconocido
'L', - O~debil
'H', - 1debil
'r", - indiferE!b:te (Odon't care")
);
4.4.4.1.1. Interpretacin de los valores lgicos fuertes
('O', '1', false, true)
Laherramienta desntesis debe deinterpretar los siguientes valores:
'O' del tipo Bit.
False del tipo Boolean.
'O' del tipo Std_Ulogic.
como representacin del nivel lgico correspondiente alatensin dereferencia nor-
malmente denominada tierra. As, por ejemplo, laasignacin:
S <; x or ' O' ;
seraequivalente al circuito delafigura:
x-p-s
Laherramienta desntesis debe deinterpretar los siguientes valores:
'1' del tipo Bit.
Truedel tipo Boolean.
'1' del tipo Std_Ulogic.
como representacin del nivel lgico correspondiente ala tensin de alimentacin,
denominada usualmente VceO VDO. As, por ejemplo, laasignacin:
s <= x and '1';
4. Sntesis 203
seraequivalente al circuito delafigura:
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
lasque searelevante diferenciar en sntesis lafuerza asignada al valor deuna seal,
sedecidi no forzar una interpretacin en laactualidad.
4.4.4.1.3. Interpretacin de los valores metalgicos dbiles
('U', 'W', 'X', '-')
Lautilizacin delos 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 lafuncin Std- Match. Laherramienta desntesis debe de so-
portar lautilizacin deestos valores con lasiguiente 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:
i f s = 0010- 01" t hen
z <= 'O ';
el s e
z <= '1';
end i f
es equivalente a:
z <= '1';
Este ejemplo puede parecer chocante, yaque lacomparacin 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 deque el operando fuera una variable o seal que, en tiempo de simulaci6n, tomara uno de los va-
lores metal6gicos.
204 VHDL. Lenguaje estndar de Diseo Electrnico
operadores de comparacin definidos en el paquete Std_Logic_1J64 no tra-
tan al valor '-' de esta manera. La misma equivalencia sehabra establecido
si en vez del valor metalgico '-' sehubiera utilizado cualquier otro.
En el caso detratarse deuna desigualdad, sta seevaluara como cierta. As,
para laherramienta desntesis, el conjunto desentencias siguiente:
if s /= 0010X01" t hen
z <= 'Ol} 'r.
el se
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 alaeliminacin dedicha 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 lasentencia secuencial deseleccin equivalente.
Lautilizacin devalores 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 deconsiderarse como un error.
4. Sntesis 205
La utilizacin de un valor metalgico en operaciones deconcatenacin, con-
versin detipo y deextensin de signo est permitida en sntesis sin ninguna
interpretacin especial.
Lautilizacin deun valor metalgico como forma deonda o parte deuna for-
madeondaenuna sentencia deasignacin estpermitida. El estndar no espe-
cifica ninguna interpretacin particular para el valor metalgico en este caso6.
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
unbuffer triestado habilitado por lacondicin decontrol delaasignacin. 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 <= x l a nd x 2 whe n ' 00" ,
' Z' whe n " 01" ,
' Z' whe n " l O" ,
x l whe n " 11" ;
secorrespondera con el circuito delafigura:
z
Cualquier otra ocurrencia de un valor esttico de alta impedancia tiene el mis-
mo tratamiento que el deunvalor metalgico en lamisma 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
secomentar posteriormente, el diseador debe de evitar que el comportamiento
del cdigo VHOL dependa deeste tipo deexpresiones.
6 La mayora de las herramientas de sntesis interpretan los valores metalgicos como indife-
rentes.
206 VHDL. Lenguaje estndar de Diseo Electrnico
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 latransicin activa dela seal dereloj, 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 suutilidad en sntesis, estas funciones permiten acelerar lasi-
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 detipo Bit:
type Unsigned i 8 array (Natural range < of Bit;
type Signed i 8 array (Natural range < of Bit;
El paquete Numeric_Std define operaciones sobre vectores de tipo Std_
Ulogic:
type unsigned Laarray (Natural range -o- of Std_Logic;
type Signed i 8 array (Natural range < of Std_Logic;
Ambos paquetes interpretan el tipo Unsigned como la representacin en bina-
rio deun nmero natural. El tipo Signed representa en complemento a2un nmero
entero. En particular, un valor detipo Signed deun nico bit representara los valo-
res numricos -1y O.En ambos casos, el bit ms significativo es el situado ala iz-
quierda. Los paquetes permiten utilizar en los operadores argumentos izquierdo o
derecho de tipo Unsigned y Natural o de tipo Signed eInteger. Esto hace que cada
funcin binaria est repetida seis veces en cada paquete. Al objeto de facilitar el
cambio deun paquete aotro, lamayora delas 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
Descripcin Operandos
7
Resultado
aritmticas
"abs" valor absoluto Signed Signed
"" cambio designo Signed Signed
" +" adicin Unsigned- Unsigned Unsigned
Signed-Signed Signed
Unsigned-Natural Unsigned
Signed-Integer Signed
"" substraccin Unsigned-Unsigned Unsigned
Signed-Signed Signed
Unsigned-Natural Unsigned
Signed-Integer Signed
"*,,
multiplicacin Unsigned-Unsigned Unsigned
Signed-Signed Signed
Unsigned-Natural Unsigned
Signed- Integer Signed
rr
divisin Unsigned- Unsigned Unsigned
(si el segundo Signed-Signed Signed
argumento es nulo, Unsigned-Natural Unsigned
seproduce un ERROR) Signed- Interger Signed
"rem" resto Unsigned- Unsigned Unsigned
(si el segundo Signed-Signed Signed
argumento es nulo, Unsigned-Natural Unsigned
seproduce un ERROR) Signed-Integer Signed
"mod" mdulo Unsigned-Unsigned Unsigned
(si el segundo Signed-Signed Signed
argumento es nulo, se Unsigned-Natural Unsigned
produce un ERROR) Signed-Integer Signed
Funciones de
comparacin
Descripcin Operandos 7 Resultado
" >" Unsigned-Unsigned
Signed-Signed
Unsigned-Natural
Signed- Integer
Unsigned-Unsigned
Signed-Signed
Unsigned-Natural
Signed-Integer
mayor
" <" menor
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
Boolean
7 Las funciones son conmutativas respecto del tipo, ya que estn definidas tambin para el orden
opuesto delos tipos delos operandos.
208 VHDL. Lenguaje estndar de Diseo Electrnico
Funciones de
comparacin
" =" igual
Operandos 7 Resultado
Unsigned-Unsigned Boolean
Signed-Signed Boolean
Unsigned-Natural Boolean
Signed- Integer Boolean
Unsigned- Unsigned Boolean
Signed-Signed Boolean
Unsigned-Natural Boolean
Signed- Integer Boolean
Unsigned- Unsigned Boolean
Signed-Signed Boolean
Unsigned-Natural Boolean
Signed-Integer Boolean
Unsigned- Unsigned Boolean
Signed-Signed Boolean
Unsigned-Natural Boolean
Signed-Integer Boolean
Descripcin
" <=" menor o igual
" >=" mayor o igual
" /=" distinto
Funciones de
Descripcin Operandos
8
Resultado
desplazamiento
Shift_Left desplazamiento Unsigned- Natural Unsigned
aizquierda Signed-Natural Signed
Shift_Right desplazamiento Unsigned-Natural Unsigned
aderecha Signed-Natural Signed
Rotate_Left rotacin Unsigned-Natural Unsigned
aizquierda Signed-Natural Signed
Rotate_Right rotacin Unsigned-Natural Unsigned
aderecha Signed-Natural Signed
"sIl" desplazamiento Unsigned-Natural Unsigned
aizquierda Signed-Natural Signed
"srl" desplazamiento Unsigned-Natural Unsigned
aderecha Signed-Natural Signed
"rol" rotacin Unsigned-Natural Unsigned
aizquierda Signed-Natural Signed
"ror" rotacin Unsigned-Natural Unsigned
aderecha Signed-Natural Signed
8 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando
representa el nmero dedesplazamientos aefectuar 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 abit Signed-Signed Signed
" or" funcin lgica "o" Unsigned-Unsigned Unsigned
bit abit Signed-Signed Signed
"nand" funcin lgica "no-y" Unsigned- Unsigned Unsigned
bit abit Signed-Signed Signed
" nor" funcin lgica "no-o" Unsigned- Unsigned Unsigned
bit abit Signed-Signed Signed
"xor" funcin lgica "0- Unsigned- Unsigned Unsigned
exclusiva" bit abit Signed-Signed Signed
"xnor" funcin lgica "no-o- Unsigned-Unsigned Unsigned
exclusiva" bit abit Signed-Signed Signed
Funciones de
Descripcin Operandos
9
Resultado
conversin
Resize re-dimensionado Unsigned-Natural Unsigned
deun vector Signed-Natural Signed
To_Integer conversin Unsigned Natural
aentero Signed Integer
To_Unsigned conversin aUnsigned Natural-Natural Unsigned
To_Signed conversin aSigned Integer-Natural Signed
Adicionalmente a estas funciones, el paquete Numeric_Bit incluye las funcio-
nes Rising_Edge y Falling_Edge para seales detipo Bit. Las funciones correspon-
dientes sobre el tipo Std_Ulogic sonlas definidas en el paquete Std_ Logic_1l64.
Por otro lado, el paquete Numeric_Std incluye la funcin de traslacin:
Funcin de
traslacin
Descripcin Operandos 10 Resultado
To_Ol Conversin a o 1
Unsigned-Std_Logic
Signed-Std_Logic
Unsigned
Signed
9 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando
representa el tamao del vector resultante.
10 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando
representa el valor aasignar cuando sedetecta una discrepancia (por defecto 'O').
210 VHDL. Lenguaje estndar de Diseo Electrnico
que convierte los valores 'H' en '1' Y los valores 'L' en 'O'. Cualquier otro valor es
convertido en el valor definido por el segundo argumento de lafuncin ('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 sedefine,
el valor '-' tiene untratamiento especial como valor indiferente. Al objeto depropor-
cionar un mecanismo de comparacin en el que el valor '-' acte efectivamente co-
mo valor indiferente, el paquete Numeric_Std incluye lafuncin Std_ Match. As:
St d, _ Ma t c h ( 01W: OL 1ZUUH , I l H) - 1- 1 ) = ' 1. ' ;
Sinembargo:
St Qj Ma t c h ( 01UXOL 1ZUUH , L HU- 0- 1- 1 ) = ' O' ;
Descripcin Operandos 11 Resultado
Std_Match Comparacin
con utilizacin del
valor indiferente
Std_Ulogic-Std_ Ulogic
Std_Logic_ Vector-Std_Logic_ Vector
Std_Ulogic_ Vector-Std_Ulogic_ Vector
Unsigned- Unsigned
Signed-Signed
Boolean
Boolean
Boolean
Boolean
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, laasignacin:
a < = b a nd e when e = 'o' e 1s e ' 1' ;
se corresponde con lgica combinacional. Una posible implementacin se-
rael circuito delaFigura 4-11.
Por el contrario, las asignaciones:
a < = b and e when a = 'o' e 1s e ' 1' ;
a < = b and e when e = ' O' e 1s e a ;
secorresponden con lgica secuencial.
11 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando
representa el valor aasignar cuando sedetecta una discrepancia (por defecto 'O').
12 Como ya hemos comentado anterioimente, para cualquier asignacin concurrente existe un
proceso equivalente.
4. Sntesis 211
a
FIGURA 4-11. Implementacin de asignacin combinacional.
b) El conjunto de asignaciones concurrentes no contiene lazos combinaciona-
les. As, el conjunto deasignaciones:
d <= b a nd C;
a <= d ar e;
constituyen una descripcin alternativa de la implementacin de la Figu-
ra4.11. Por el contrario, las asignaciones:
d. <= banda;
a <= d ar e;
no, yaque laseal a serealimenta 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 laexpresin secorresponde con laseal 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 <= y 1 & y 2 ;
with y s e l e c t
z <= x l a nd x 2 whe n " OO ,
x l whe n " 01 ,
x 2 when " l O" ,
' 1' when " 11" ;
Tendra una implementacin directa con el multiplexor 4 x 1de laFigura 4-12.
Sin embargo, dependiendo delas restricciones dediseo, laimplementacin de
laFigura 4-13 puede ser preferible en undiseo dado.
La asignacin de seal condicional secorresponde funcionalmente con una ca-
dena demultiplexores 2x 1en el que las condiciones secorresponden con las sea-
les de control. sta ser laimplementacin final, siempre que durante el proceso de
optimizacin no seencuentre una implementacin alternativa mejor en trminos de
coste o velocidad. As, por ejemplo, el cdigo siguiente:
z <= x l a nd x 2 when y 1 = ' O' a nd y 2 = ' O' e 1s e
x l when y 1 = ' O' e l s e
x 2 when y 2 = ' 0' e l s e
'1';
212 VHDL. Lenguaje estndar de Diseo Electrnico
x2-_,_----l
'-------110
'1' --------1
y1y2
FIGURA 4-12. Implementacin directa de asignacin seleccionada.
Tendra una implementacin directa con lacadena demultiplexores delaFigu-
ra4-14.
Sin embargo, dependiendo delas restricciones dediseo, la implementacin de
laFigura 4-13 puede volver aser preferible en un diseo dado.
Algunas herramientas soportan el agrupamiento de sentencias concurrentes en
bloques. Como ya seha comentado, las herramientas eliminan usualmente lajerar-
qua. Los bloques con seal deguarda pueden ser usados en ladescripcin debuses
en algunas herramientas:
signal z : ... bus; ...
t r i : b l o c k ( e n = ' l ' )
begin
z <= guarded QSIM_STATE_RESOLVED_X_VECTQR (temp);
e n d b l o c k t r i ;
x1-~---l
x2-+-_"'--l
y1--~---J
y2---4---l
FIGURA 4-13. Implementacin alternativa de asignacin seleccionada.
4. Sntesis 213
z
FIGURA 4-14. Implementacin directa de asignacin condicional.
A partir delos paquetes de sntesis, lautilizacin del valor std_logic 'Z', impli-
caladescripcin deunbuffer triestado:
z <= t emp when ( en = ' 1' ) e1s e ' Z' ;
En algunas herramientas los buses se pueden describir mediante asignaciones
del valor "null":
z <= t emp when ( en = ' 1' ) e1s e nul l ;
En este caso, la seal 'z' tiene que ser declase bus, al igual que ocurra cuando
seutilizaba un bloque guardado. En cualquiera de los anteriores casos, el resultado
es unbuffer tri-estado:
en
La segunda forma dedescribir 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:
214 VHDL. Lenguaje estndar de Diseo Electrnico
pr o c e s s ( b, c , e )
variable d: ...;
begin
d :=band e:
a<=dore;
end pr o c e s s ;
cumplelacondicin. En algunas herramientas seadmiteigualmente el pro-
ceso equivalente al anterior, es decir, unproceso enel quelalistadesensi-
bilidades reemplazada por unasentenciawait equivalente:
pr o c e s s
variable d: ...;
begin
d : = b a nd C;
a<=do r e ;
wa i t e n b, c , e ;
endpr o c e s s ;
Estaes lanicasentencia wait permitida en estetipo deprocesos, En ambos
casos, lalgicadescrita podra implementarse con el circuito delaFigura4-11.
Algunas herramientas desntesis ignoran lalistadesensibilidad. El proceso se
consideracombinacional cuando carecedesentencias deesperay secuencial enca-
socontrario. Estehecho puedeprovocar discrepancias entrelos resultados desimu-
lacin antes y despus desntesis adicionales alas consideradas conanterioridad.
b) Bajocualquier condicin deejecucin del proceso, todas las variables y se-
ales sonasignadas. As, por ejemplo, el proceso siguiente:
pr o c e s s ( b, c , e )
variable d: ...;
begin
i f ( b = ~1' ) t he n
d :=C;
e l s e
d :='0
'
;
endi f ;
a<=dore;
end pr o c e s s ;
constituyeunadescripcin alternativaalaimplementacin delaFigura4-11.
Porel contrario, enel procesosiguientelavariable"d" nocumplelacondicin:
pr o c e s s ( b, e , e )
variable d: ... ;
begin
i f ( b = ' 1' ) t he n
d :=C; .
end i f ;
a<=dore;
end pr o c e s s ;
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 deser asignada como enel proceso siguiente:
process (input)
variable var: stQ_ulogic.;
begi n
output <= varo
var := input;
end process;
El resultado de la sntesis de este proceso es idntico al del proceso siguiente
(unaconexin directa entre input y output):
process (input)
variable var: st<t.ulogic;
begi n
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.
Ladescripcin 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 ladel cdigo concurrente. Mientras
laestructura de una asignacin a seal seleccionada est fija, su equivalente secuen-
cial, lasentencia case, permite incluir cualquier tipo decdigo secuencial en cada al-
ternativa. Esta mayor flexibilidad es posible encontrarla tambin en la sentencia
if. ..then ... else frente ala sentencia de asignacin condicional. En consecuencia, aun-
que tambin aqu es posible encontrar una relacin funcional entre el cdigo y el
hardware, estarelacin sueleser menos directa queenel caso concurrente.
As, por ejemplo, el cdigo:
process .. ..
variable y : BN_vecto~'(~;~O 2);
begi n
y := y1&y2;
c as e y is
when ' 00' =>
z <= x l and x2;
when " 01" =>
z <= x l ;
when " l O' =>
z <= x 2;
when "11" =>
z <= '1';
end c as e;
end process;
216 VHDL. Lenguaje estndar de Diseo Electrnico
tendra como implementacin directa el multiplexor 4 x 1 de la Figura 4-12. Sin
embargo, dependiendo de las restricciones dediseo, la implementacin de laFigu-
ra4-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. Sinembargo, laimplementacin concreta enpuertas
vaadepender delas restricciones dediseo impuestas ydelatecnologa utilizada.
pr o c e s s
be gi n
i f ( yl = ' o ' a nd y2 = ' O' ) t he n
z <= xl aDd x2;
e l a i f ( yl = ' O' ) t he n
z <= xl ;
e l s i f ( y2 = ' O' ) t he n
z <= x2,
e l s e
z <= '1' i
end i f ;
end pr o c e s s ;
Los lazos constituyen una construccin que aade flexibilidad ala descripcin
delgica mediante un proceso. Sin embargo, hay herramientas que no los soportan.
Algunas herramientas soportan los lazos detipofor siempre que sepuedan descom-
poner en una secuencia de sentencias equivalente. Su implementacin ser ladedi-
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 fijadelgica.
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 seignora. Esto sedebe aque, como secoment en la introduccin, anivel
RT los retrasos de los componentes del circuito no se conocen. Son las acciones
(transferencias aregistros 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 a f t e r o ns ;
z <= x and y a f t e r 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 laimplementacin final anive11gico.
4. Sntesis 217
4.4.6. Descripcinde "Iatches"
La mayora de las herramientas infieren latches cuando en un proceso se relaja la
condicin b). As, por ejemplo, el cdigo siguiente:
l a t c h: pr o c e s s ( D, e n)
be gi n
i f ( e n = ' 1' ) then
Q <= D;
end i f ;
end pr o c e s s l a t c h;
seraladescripcin explcita deun latch tipo-D.
D----t
I
I ----Q
e n
FIGURA 4-15. "Lstch" tipo D.
Algunas herramientas permiten inferir elementos dememoria devariables. As,
por ejemplo, el proceso secuencial del Listado 4-5 sesintetizara mediante un latch
enlavariable "d":
a
b e
Algunas herramientas infieren "latches" deasignaciones concurrentes de seal
enlas que laseal destino participa en laforma deonda. As, laasignacin:
a <= b a nd e whe n h =' 1' e 1s e a ;
sesintetizara mediante el siguiente circuito:
218 VHDL. Lenguaje estndar de Diseo Electrnico
h
Este tipo de inferencia sepuede realizar siempre que la herramienta sea capaz
deidentificar laseal dehabilitacin dellatch. Otras herramientas, sinembargo, in-
fieren la lgica asncrona directa correspondiente advirtiendo al diseador de esta
situacin. Esta implementacin no garantiza laausencia decarreras:
h
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:
l at ch: bl ock ( en = ' 1' )
begi n
Q <= guarded D;
end bl ock;
Sera una descripcin alternativa alade laFigura 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 deevento y flanco. Laforma ms usual es:
r el oj ' EVENT and r el oj = ' 1'
4. Sntesis 219
Algunas herramientas soportan tambin laforma:
not reloj_STABLEa nd reloj = '1'
Cuando la seal es de tipo std_ulogic, algunas herramientas aconsejan utilizar
laforma:
reloj'EVENTa nd reloj = '1' a nd 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' Y no 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 ladeteccin dela transicin de subida y bajada dela seal dereloj respectiva-
mente.
4.4.8. Registros
Seidentifican como registros aquellas seales cuya asignacin dependen deuna se-
al dereloj.
Un bloque con seal deguarda puede ser utilizado para describir lacarga sobre
unregistro:
ex1:block (reloj 'event a nd reloj ..: '1')
be gi n
Q <= guarded D;
end block;
En principio, cualquiera delas formas dedeteccin dela transicin activa dela
seal dereloj es igualmente vlida:
ex2 : block (not reloj' stable a nd reloj ~'1')
be gi n
Q <= guarded D;
end block;
Un proceso con sentencia de espera puede ser utilizado tambin para describir
registros como en los ejemplos siguientes:
pr o c e s s
be gi n
wait until (reloj = '1');
Q <= D;
end pr o c e s s ;
pr o c e s s
be gi n
wait until (reloj'event a nd reloj = '1');
Q <= D;
end pr o c e s s ;
220 VHDL. Lenguaje estndar de Diseo Electrnico
En un proceso con lista de sensibilidad, sta puede ser utilizada para especifi-
car el evento delaseal dereloj:
pr o c e s s ( r e l ~j ~
begin _,
i f ( r e l o j ' e v e nt and r e l o j = ' 1' ) t he n
Q <= D;
end i f ;
end pr o c e s s ;
Este ltimo estilo admite la inclusin de seales de set y reset, ya sean sn-
cronas:
pr o c e s s ( r e l o j )
begin
i f ( r e l o j ' e v e nt and r e l o j ' 1' ) t he n
i f ( r e s e t = ' 1' ) t he n
Q <= '0';
e 1s e
Q <= D;
end i f ;
e nd if;
end pr o c e s s ;
oasncronas:
pr o c e s s ( r e l o j , r e s e t )
begin
i f ( r e s e t = ' 1' ) t he n
Q <= '0';
e l s i f ( r e l o j ' e v e nt and r e l o j = ' 1' ) t he n
Q <= D;
end i f ;
end pr o c e s s ;
Algunas herramientas permiten sustituir lalista desensibilidad por la sentencia
deespera correspondiente:
pr o c e s s
begin
i f ( r e s e t = ' 1' ) t he n
Q <= '0';
e l s i f ( r e l o j ' e v e nt and r e l o j ' 1' ) t he n
Q <= not D;
end i f ;
wa i t o n r e l o j , r e s e t ;
end pr o c e s s ;
En este caso, lalgica sintetizada sera lasiguiente:
4. Sntesis 221
reset
reloj
En el caso deque lasentencia de espera sesituara al principio, lalgica sera la
siguiente:
reset
Q
reloj
La diferencia en uno uotro caso proviene del valor inicial de la seal D tras la
primera ejecucin del proceso.
Sobre la seal dereloj seimponen usualmente una serie decondiciones deuso
que la caracterizan como una seal de comportamiento correcto. Las ms usuales
sonlas siguientes:
Generalmente, slo se admite la especificacin de un evento por proceso (o
bloque) lo que setraduce en un nico reloj por proceso. La siguiente descrip-
cin sera, por tanto, incorrecta:
process ( ,.. )
i f ( r e l o j a ' e v e nt and r e l o j a = ' 1' ) t he n
end H,
i f ( r e l o j b' e v e nt and r e l o j b= ' 1' ) t he n
e nd ifi
e nd pr o c e s s ,
i f ( r el oj ' event and r el oj
x <= a;
el s e
x <= b;
end if;
'1') then
222 VHDL. Lenguaje estndar de Diseo Electrnico
Cuando laseal dereloj seutiliza en una construccin condicional, no se
pueden especificar acciones enlaclusula else. Lasiguientedescripcin se-
ra, por tanto, incorrecta:
Laespecificacin dereloj no sepuedeutilizar como operando. Lasiguiente
descripcin sera, por tanto, incorrecta:
i f not ( r el oj ' event and r el oj = ' 1' ) t hen . . .
Algunas herramientas permiten laobtencin deseales dereloj apartir deope-
raciones lgicas sobreotraseal dereloj. Estas seales dereloj derivadas reciben el
nombredegated clocks:
r el oj _ der i vado <= r el oj and s enal _ c ont r ol ;
pr oc es s ( r el oj _ der i vado, r es et )
begi n
i f ( r es et = ' 1' ) t hen
Q <= 'O';
el s i f Ri s i ng_ edge( r el oj _ der i vado) t hen
Q <= D;
end i f ;
end pr oc es a:
Laimplementacin directadel cdigo anterior sera:
reset
Q D----I
senal_control
reloj
Estaimplementacin, evidentemente, no est exenta depeligros enlaseal re-
loj_derivado si laseal decontrol segeneracombinacionalmente.
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 unregistro dedesplazamiento con carga en paralelo. La utiliza-
cin delos operadores dedesplazamiento representa laforma ms simple dedescri-
bir unregistro dedesplazamiento:
RD <= Shi f t _ni ght ( RD, 2) ;
RD <= RD s I l 2;
I ~ I ~ I I
~
'O'
Laconcatenacin permite descripciones explcitas:
RD <= RD( N)&RD ( N) &RD ( N downt o 2) ;
RD <= RD( N- 2 downt o 0) &" 00" ;
_ e qui v a l e nt e a Shi f t _r i ght ( RD, 2) ;
_ e qui v a l e nt e a 511 2;
Otra alternativa larepresentan los lazos:
f or 1 inN downt o o l oop
if(1 = N or 1 = N - 1) then
RD( I ) <= RD( N) ;
e l s e
RD( I ) <= RD( I + 2) ;
end if;
end l oop;
_ e qui v a l e nt e a Shi f t _r i ght ( RD, 2) ;
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 deseis bits:
pr oc e s s ( r e s e t , r e l oj )
begin
i f ( r e s e t = ' 1' ) t he n
c ont a dor <= 000000" ;
224 VHDL. Lenguaje estndar de Diseo Electrnico
e l s i f F a l l i ng_ E dge ( r e l o j ) then
i f ( i nc = ' 1' ) t he n
i f ( c o nt a do r <= " 111J , l " ) t he n
c o nt a do r <= " OOOOO' ;
e l s e
c o nt a do r <= c o nt a do r + 1;
end i f ;
e 1a i f ( de c = ' 1' ) then
i f ( c o nt a do r <= ' 000000" ) t he n
c o nt a do r <= " 111111" ;
e l s e
c o nt a do r <= c o nt a do r - 1;
end i f ;
end if;;
end if; ;
end pr o c e s s ;
En algunas herramientas, las operaciones decomparacin para detectar los l-
mites decuenta 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 deun contador de seis bits, creciente, de-
creciente y concarga enparalelo:
pr o c e s s ( r e s e t , r e l o j )
be gi n
i f ( r e s e t = ' 1' ) then
c o nt a do r <= 000000" ;
e l s i f F a l l i ng_ E dge ( r e l o j ) t he n
i f ( c a r ga = ' 1' ) then
c o nt a do r <= da t o ;
e 1s e
i f ( i nc = ' 1' ) then
c o nt a do r <= ( c o nt a do r + 1) mod 64;
e l s i f ( de c = ' 1' ) than
c o nt a do r <= ( c o nt a do r - 1) mod 64;
end i f ;
end if;;
e nd if;;
end pr o c e s s ;
Los dos contadores anteriores son sncronos, ya que la carga sobre la seal
contador serealiza 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:
a r c hi t e c t ur e de s c r i pc i o n ofc o nt a do r _ mo d10 i s
s i gna l c o nt a do r : uns i gne d ( 3 do wnt o O) ;
s i gna l r e s e t : s t d_ Ul o gi c : = ' 1' ;
be gi n
r e s e t <= c o nt a do r ( 3) aod c o nt a do r ( 1) ;
p r o c e s a ( r e s e t , c o n t a d o r )
be gi n
i f ( r e s e t = ' 1 ' ) t h e n
c o n t a d o r ( 3) <= ' O' ;
e l s i f F a l l i n 9 _ E d ge ( c o n t a d o r ( 2 ) ) t h e n
c o n t a d o r ( 3) <= not c o n t a d o r ( 3) ;
e n d if;
e n d p r o c e s s ;
p r o c e s s ( r e s e t , c o n t a d o r )
be gi n
i f ( r e s e t = ' 1 ' ) t h e n
c o n t a d o r ( 2 ) <= ' O' ;
e l s i f F a l l i n g_ E d ge ( c o n t a d o r ( 1}) then
c o n t a d o r ( 2 ) <= n o t c o n t a d o r ( 2 )
e n d if;
e n d p r o c e s s ;
p r o c e s a ( r e s e t , c o n t a d o r )
be gi n
i f ( r e s e t = ' 1 ' ) t h e n
c o n t a d o r { l ) <= 'O';
1
eloj
Q
co
;>
,--
O
a~
I
-
P.
Q
co
.--
O
al
I
~
>
Q
co
r- o
a~
I
'-----
>
Q
co
, o
a~
ntador(Ol
ntador(1)
ntador(2)
ntador(3)
reset
4. Sntesis 225
226 VHDL. Lenguaje estndar de Diseo Electrnico
e 1 s 1 f F a l l i n g _ E d g e ( c o n t a d o r ( O) ) t h e n
c o n t a d o r ( 1 ) <= DOt c o n t a d o r ( l ) ;
end l f ;
e n d p r o c e s s ;
p r o c e s s ( r e s e t , r e l o j )
b e g i n
i f ( r e s e t = ' 1 ' ) t h e n
c o n t a d o r ( O) <= ' O' ;
e 1 s 1 f F a l l i n g _ E d g e ( r e l o j ) t h e n
c o n t a d o r ( O) <= not c o n t a d o r ( O) ;
end i f ;
end p r o c e s s ;
end d e s c r i p c i o n ;
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 desntesis encada caso vanaser diferentes.
Los estilos descriptivos para FSMs se pueden agrupar en explcitos e implci-
tos. Enel estilo explcito el, laFSM sedescribe utilizando unproceso 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 enla
transicin activa de la seal dereloj. Este estilo identifica claramente laparte com-
binacional de los elementos de memoria segn el modelo general de mquina se-
cuencial deHuffman:
e n t i t y F S M is
port ( r e l o j , r e s e t : in s t d _ u l o g i c ;
xl , ... xn in s t d _ u l o g i c
z l , . _ zm o u t s t d _ u l o g i c ) ;
end F S M;
a r c h i t e c t u r e e l of F S M l s
t y p e e s t a d o s l s ( s O, . . .s p ) ;
s i g n a 1 e s t a d o : e s t a d o s ;
s i g n a 1 n x t _ e s t a d o : e s ' t ~d o s ;
b e g i n
S I D: p r o c e s s ( e s t a d o , x l , . . .xn)
b e g i n
_ s e a l e s de r e l o j y r e s e t
_ s e a l e s d e e n t r a d a
_ s e a l e s d e salida
_ r e g i s t r o ~ e s t a d o s
_ s e a l d e p r x i mo e s t a d o
"
n x t _ e s t a d o <= e s t a d O; _ a s i g n a c i n p o r d e f e c t o
c a s e e s t a d o l s
when s O => _ e s t a d o s O
_ a c c i o n e s d e l e s t a d o . s O:
_ a s i g n a c i n d e e s t a d o p r x i mo
- a s i g n a c i o n e s . d e s a l ~d a
wh e n s p => - e s t a d o , s p
- a c c i o n e s d e l e s t a d o s p :
- a s i g n a c i n d e e s t a d o p r x i mo
4. Sntesis 227
_ a s I gna c i o ne s de s a l da
"<,
end c a s e ;
end pr o c e s s SIn;
r e l o j d: pr o c e s s ( r e s e t , r e l o j )
be gi n
i f ( r e s e t = ' O' ) t he n
e s t a do <= s O; _ r e s e t a s nc r o no
e l s i f ( r e l o j ' e v e nt and r e l j , ~ , 1 ' ) t he n
e s t a do <= ~t _ e s t a do ; _ t r a ns i c i n de e s t a do
end i f ;
end pr o c e s s r e l o j d;
end e l ;
El proceso secuencial decarga del registro deestados puede utilizar cualquiera
delos 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:
r e l o j d: pr o c e s s
be gi n
wa i t unt i l r e l o j = '1';
i f ( r e s e t = ' 0' ) t he n
e s t a do <= s O;
e l e e
e s t a do <= nx t _ e s t a do ;
end i f ;
e nd pr o c e s s r e l o j d;
- r e s e t s nc r o no
_ t r a ns i c i n de e $t a do
En algunas herramientas, esta segunda posibilidad impide ladescripcin de seales
de reset asncrono para los elementos de memoria. Debido asu simplicidad y aque
las nicas tareas delegadas alaherramienta desntesis son las deoptimizacin lgi-
ca y mapeado tecnolgico, el estilo descriptivo el es con el que resulta ms fcil la
obtencin deresultados desntesis ptimos.
El registro deestados 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 deestados.
Ejemplo 4.2. Dada lamquina definida por el diagrama de estados de laFigu-
ra4-16.
Su descripcin en el modelo explcito el sera lasiguiente:
e nt i t y F SM i .
port ( r e l o j , r e s e t : in s t d_ ul o gi c ;
x in s t d_ ul o gi c ;
_ s e a l e s de r e l o j y r e s e t
_ s e a l de e nt r a da
228
%, 1/1
VHOL. Lenguaje estndar de Diseo Elecrrnico
1/0
%
1/1
%
0/1
1/0
FIGURA 4-16. Diagrama de estados.
a r c h i t e c t u r e e l o f F S M i s
t y p e e s t a d o s i s ( s O, s l , s 2 , s 3 ) ;
s i g n a ! e s t a d o : e s t a d o s ;
s i g n a 1 n x t _ e s t a d o : e s t a d o s ;
begin
s m: p r o c e s s ( e s t a d o , x )
begin
n x t _ e s t a d o <= e s t a d o ;
case e s t a d o i s
when s O =>
z
end F S M;
o u t s t d _ u l o g i c ) ;
z <= '0';
i f (x = ' O' ) then
n x t _ e s t a d o <= s l ;
e l s e
n x t _ e s t a d o <= s 2 ;
end i f ;
when s l =>
z <= x ;
n x t _ e s t a d o <= s O;
when s 2 =>
z <= ' D I i
_ s e a l d e s a l i d a
- , r e g i s t r o d e e s t a d o s
- s e a l d e p r x i mo e s t a d o
- a s i g n a c i n p o r d e f e c t o
- e s t a d o s O
_ a s i g n a c i n d e s a l i d a
_ a s i g n a c i n d e e s t a d o p r x i mo
_ e s t a d o s l
- a s i g n a c i n d e s a l i d a
' - a s i g n a c i n d e e s t a d o p r x i mo
- e s t a d o s 2
- a s i g n a c i n d e s a l i d a
i f ( x = ' O' ) t he n
nx t _ e s t a d o <= s l ;
e l a e
nx t _ e s t a d o <= s 3 ;
e nd if;
when s 3 =>
z <= '1';
i f ( x = ' 1' ) t he n
nx t _ e s t a d o <= s l ;
e nd i f ;
e nd c a s e ;
end p r o c e s s sm;
4. Sntesis 229
_ a s i g na c i n d e e s t a d o p r x i mo
_ e s t a d o s 3
_ a s i g na c i n d e s a l i d a
_ a s i g na c i n d e e s t a d o p r x i mo
r e l o j d : p r o c e s s ( r e s e t , r e l o j )
be g i n
i f ( r e s e t = ' O' ) t he n
e s t a d o <= s O; _ r e s e t a s nc r o no
e l s i f ( r e l o j ' e v e nt and r e l . Oj = '1') then
e s t a d o <= nx t ~e s t a d o ; _ t r a ns i c i n d e e s t a d o
end i f ; .
e nd p r o c e s a r e l o j d ;
e nd e l ;
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 dereloj, por 10 que slo es posible
describir mquinas deMoore. Estehecho es departicular importancia porque todas
las seales asignadas van ainferir biestables y, por ello, este estilo descriptivo slo
es apropiado cuando sedesee este tipo deimplementacin. En cualquier caso, este
problema sepuede evitar extrayendo lafuncin desalida aunproceso 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:
a r c hi t e c t u r e e 2 of F SM i s
be g i n
s m: p r o c e s s
t y p e e s t a d o s i s (SO _. s p ) ;
v a r i a bl e e s t a d o : e s t a d o s ;
be g i n
wa i t u nt i l r e l o j = '1';
i f ( r e s e t = ' O' ) t he n
e s t a d o := s O;
e l s e
c a s e e s t a d o i s
when s O =>
when sp =>
_ r e g i s t r o d e e s t a d o s
_ r e s e t s nc r o no
_ e s t a d o s O
_ a c c i o ne s d e l e s t a d o s O:
_ t r a ns i c i n de e s t a d o y
_ a s i g na c i o ne s d e s a l i d a
_ e s t a d o s p
230 VHDL. Lenguaje estndar de Diseo Electrnico
end c a s e ;
end if;
end p r o c e s s SID;
end e 2 ;
- accones del e s t a d o s p :
- t r a n s i c i n d e e s t a d o y
- a s i g n a c i o n e s d e s a l i d a
Ejemplo 4.3. Ladescripcin VHDL enel estilo explcito e2 delamquina dela
Figura 4-16 serael Listado 4-7.
a r c h i t e c t u r e e 2 o f F S M l s
t y p e e s t a d o s l a ( s O, s I , s 2 , s 3 ) ;
b e g i n
s m: p r o c e s a ( e s t a d o , x l
v a r i a b l e e s t a d o : e s t a d o s ; ce r e g i s t r o de e s t a d o s
b e g i n
wa i t u n t l l r e l o j = '1';
i f ( r e s e t = ' 0' ) then
e s t a d o :=s O; - r e s e t s n c r o n o
e l s e
c a s e e s t a d o i s
when s O => - e s t a d o s O
z <= ' O' ; . . : . a s i g n a c i n a r e g i s t r o d e s a l i d a
i f (x =' 'O ') then '- a s i g n a c i n d e e s t a d o p r x i mo
e s t a d o :=s I ;
e l s e
e s t a d o :=s 2 ;
end i f ;
when s I =>
z <=x ;
e s t a d o : = s O;
when s 2 =>
z <='0';
if(x = '0') then
e s t a d o :=s I ;
e l a e
e s t a d o : = s 3 ;
end i f ;
when s 3 =>
z <='1';
i f ( x = ' 1' ) t h e n
e s t a d o :=s I ;
end i f ;
e n d c a s e ;
end if;
end p r o c e s s s m;
end e 2 ;
- e s t a d o s I
~ a s i g n a c i n a r e g i s t r o d e s a l i d a
- a s i g n a d i 6 n d e e s t a d o p r x i mo
- e s t a d o s 2
- a s i g n a c i n de s a l i d a
- a s i g n a c i n d e e s t a d o p r x i mo
- e s t a d o s 3
- a s i g n a c i n d e s a l i d a
- a s i g n a c i n d e e s t a d o p r x i mo
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
queel diagrama de estados de la mquina Moore equivalente tiene slo siete esta-
dostal ycomo semuestra en laFigura 4-17.
No todas las herramientas de sntesis son capaces de encontrar la mquina de
estados mnima.
Como seconcluye del ejemplo, en este estilo la calidad del resultado descansa
enmayor medida sobre laefectividad delos algoritmos deminimizacin deestados
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 adestacar es la imposibilidad, en la mayora de las herramien-
tas, dedescribir capacidad deinicializacin asncrona.
Las principales ventajas del estilo provienen de su simplicidad, desde el mo-
mento en que lamquina queda descrita en unnico proceso, y deque todas las sa-
lidas estn registradas, lo que asegura la ausencia depeligros. Este hecho puede ser
particularmente interesante cuando sedesean generar seales decontrol 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
queseinfiere distinto tipo delgica:
o
o
o
o
o
o
FIGURA 4-17. Diagrama de estados de mquina Moore.
232 VHDL. Lenguaje estndar de Diseo Electrnico
a r c h i t e c t u r e e 3 a f F S M l s
t y p e e s t a d o s 18 ( s O, . . .s p ) ;
s i g n a l e s t a d o : e s t a d o s :=s O;
begin
_ r e g i s t r o . d e e s t a d o s
sm: p r o c e s s ( r e s e t , r e l o j , e s t a d o , xl , ... xn)
begin
_ l g i c a c o mb i n a c i o n a l

l f ( r e s e t = ' 0' ) t h e n
e s t a d o <=s O;
e l s i f Ri s i n g _ E d g e ( r e l o j ) then
c a s e e s t a d o l s >
_ r e s e t a s n c r o n o
wh e n s O => _ e s t a d o s O
_ a c c i o n e s d e l e s t a d s O:
_ t r a n s i Ci 6 n de e s t a d o y
_ a s i g n a c i o n e s a r e g i s t r o d e s a l i d a
when s p =>
_ e s t a d o s p
_ a C9 i o n e s d e l e s t a d o s p :
_ trenscn de estado y
_ a s i g n a c i o n e s a r e g i s t r o d e s a l i d a
e n d c a s e ;
end if;
_ l g i c a c o mb i n a c i o n a l
end p r o c e s s sm;
end e 3 ;
Este estilo es el ms flexible, yaquepermite describir enunnico proceso l-
gica combinacional, lgica secuencial einicializacin sncrona o asncrona de los
elementos dememoria. Dehecho, todas las asignaciones fueradel cuerpo delasen-
tencia:
l f ( r e s e t = ' O' ) t h e n . . . e l s i f Ri s i n g _ E d g e ( r e l o j ) t h e n . . . end if;
tanto al principio como al final del proceso, van aproducir lgica combinacional.
Las asignaciones enel cuerpo delasentencia:
l f ( r e s e t = ' O' ) then...
van acorresponderse con lainicializacin asncrona. Las asignaciones enel cuerpo
delasentencia:
e l s l f Ri s i n g _ E d g e ( r e l o j ) t h e n . . .
van acorresponderse con lacarga sncrona de los elementos de memoria. En esta
seccin podraincluirse lainicializacin sncronadelos elementos dememoria.
4. Sntesis 233
No todas las herramientas soportan cdigo fuera dela sentencia condicional de
las seales deinicializacin y reloj. Las herramientas que lo soportan imponen res-
tricciones en cuanto alas asignaciones de, seal que sepueden 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 laFigu-
ra4-17, ladescripcin en el estilo explcito e3 sera lasiguiente:
a r c h i t e c t u r e e 3 o f F S M is
t y p e e s t a d o s i 8 ( s O, s l , 8 2 , s 3 ) ;
s i g n a l e s t a d o : e s t a d o s :=s O; _ r e g i s t r o de e s t a d o s
begin
s m: p r o c e s s ( r e s e t , r e l o j , e s t a d o , x )
begin
c a s e e s t a d o i s _ l g i c a c o mb i n a c i o n a l
when s l =>
z <= x ;
when s 3 =>
z <= '1';
when o t h e r s =>
z <= '0' i
end c a s e ;
i f ( r e s e t = ' O' ) t h e n
e s t a d o <= s O;
e l s i f Ri s i n g _ E d g e ( r e l o j )
c a s e e s t a d o l s
when s O =>
i f (x = 'O') t h e n
e s t a d o <= s l ;
e l s e
e s t a d o <= s 2 ;
end l f ;
when s l =>
e s t a d o <= s O;
when s 2 =>
i f ( x = ' O' ) t h e n
e s t a d o <= s l ;
e l s e
e s t a d o <= 6 3 ;
end i f ;
when s 3 =>
- r e s e t a s i n c r o n o
t h e n
- e s t a d o s O
_ a s i g n a c i n d e e s t a d o p r x i mo
_ e s t a d o s l
_ a s i g n a c i 6 n d e e s t a d o p r x i mo
_ e s t a d o s 2
_ a s i g n a c i n d e e s t a d o p r x i mo
_ e s t a d o s 3
_ a s i g n a c i n d e e s t a d o p r x i mo i f ( x = ' 1' ) t h e n
e s t a d o <= s l ;
end if;
e n d c a s e ;
end i f ;
end p r o c e s a sm:
end e l ;
En el estilo implcito dedescripcin, laFSM sedescribe utilizando un proceso
con varias sentencias de espera de la seal dereloj como en el Listado 4-8. Recibe
el nombre &estilo descriptivo implcito debido aque adems de los P estados ex-
234 VHDL. Lenguaje estndar de Diseo Electrnico
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 deesta-
dos total delamquina resulta N*P. Aunque, en ciertos casos, stepueda 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 deestados presentan graves limitaciones en las herramientas desfnte-
sis comerciales en la actualidad, los resultados pueden no ser ptimos. Setrata, por
tanto, deun estilo descriptivo recomendable nicamente cuando setenga la certeza
que lafuncionalidad delamquina seadapta al mismo y que, por tanto, los resulta-
dos dela sntesis van aser aceptables. Debido aque todas las asignaciones de seal
seejecutan en el flanco activo de la seal dereloj, slo es posible describir mqui-
nas deMoore. Es posible lainicializacin asncrona del registro deestados implci-
to cuando el cdigo se encierra en el cuerpo de un lazo indefinido y tras cada sen-
tencia wait seincluye lasentencia desalida:
ne x t l a z o whe n ( r e s e t = ' 1' ) ;
Sepuede incluir lainicializacin 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:
i f ( r e s e t = ' 1' ) t he n . . . e 1s e . . . e nd if;
a r c hi t e c t ur e i mpl c i t a of F SM i B
t y pe e s t a do s ia ( s O, . . .s p) ;
be gi n
s m: pr o c e s s
v a r i a bl e e s t a do : e s t a do s : = s O;
be gi n
- r e gi s t r o de e s t a do s ~l c i t o s
- a c c i o ne s de l e s t a do i mpl c i t o 1
wa i t unt i l r e l o j = '1';
wa i t unt i l r e l o j = '1';
, . . . a c c i o ne s de l e s t a do i mpl c i t o n
end pr o c e s s ;
end i mpl c i t a ; 1
LISTADO 4-8. Estiloimplcito.
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 acoincidir
conel registro deestado, stepuede declararse como variable.
Ejemplo 4.5. El Listado 4-9 sera ladescripcin VHDL en estilo implcito dela
mquina utilizada en los ejemplos anteriores.
a r c hi t e c t ur e i mp l i c i t a o f F SM i s
begin
s r n: p r o c e s s
v a r i a bl e e s t a d o : e s t a d o s ;
begin
wa i t until r e l o j = ' 1 ' ;
z <= 'O';
i f ( x = ' 1 ' ) then
wait until r e l o j ' 1 ' ;
z <= 'o' i
i f ( x = ' 1 ' ) then
wait until r e l o j = ' 1 ' ;
2 <= '1';
whi l e ( x = ' O' ) l o c p
wait until r e l o j ' 1 ' ;
z <= '1';
end loop;
end if;
end if;
wait until r e l o j il ' ;
Z <= Xi
end p r o c e s s smr
end i mp l c i t a ;
- I ~i s t r o d e e s t g , Qp s
- e s t a d o s O
- a s i g na c i n a r e g i s t r q d e s a l i p a
- e s t a d o s 2
- a s i g na c i n a r e g i s t r o de s a l d a
- e s t a d o s 3
- a s i , g na c i 9 I l a r e g i l ; l t r o _ ( e l es a l i d a
- e s t a q o s 3 . " " ' _ , ~'
- a a q na c . n a r ~i s t r o d e s a l i d a
- e s t a d o s l
- a s i g na c i n a r e g i s t r o de s a l i d a
LISTADO 4-9. Descripcin en estilo implcito.
4.4.10. Descripcin de FSMDs
Recibe el nombre deFSMP, o mquina deestados finitos con unidad dedatos tam-
bin denominada ASM o mquina deestados algortmica, alaconjuncin deun au-
tmata decontrol y una unidad dedatos segn el esquema general dearquitectura a
nivel RT comentada anteriormente y que semostraba en laFigura 4.10. Cualquiera
delos estilos descriptivos anteriores puede ser utilizado en ladescripcin VHDL de
FSMDs sin ms que incluir en cada estado las acciones aser realizadas enlaunidad
dedatos. Los estados explcitos (o implcitos) delamquina secorrespondern con
los estados de control mientras que los recursos hardware necesarios en la imple-
mentacin delas acciones arealizar en los estados decontrol constituirn launidad
dedatos.
236 VHDL. Lenguaje estndar de Diseo Electrnico
En el caso ms general, un sistema digital anivel 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
deFSMD.
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)
be gi n
LC1<= ...;
LC2<= ...;
LC3<= ...;
Z <= Reg3;
end process SIn;
re1ojd:process (Reloj)
be gi n
if(reloj' event and reloj
Reg1 <= LCl;
Reg2 <= LC2;
Reg3 <= LC3;
end if;
end process relojd;
= '1') then
- etapa 1
- etapa 2
- etapa 3
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 detiempo decarga, T
H
, y retraso, T
R
, en los registros):
4. Sntesis 237
1
. Fmx =----------
T
R
+mx (TI, T
2
, T
3
) +T
H
Algunas herramientas permiten optimizar automticamente el circuito disminu-
yendo el camino crtico mediante la tcnica de retemporalizacin (retiming). Esta
tcnica consiste en el movimiento delos registros atravs delalgica combinacio-
nal sin alteracin de la funcionalidad global del circuito. As, por ejemplo, si en el
circuito anterior:
TI =4ns
Laherramienta desplazara los registros atravs delalgica intentando que:
En laretemporalizacin pueden tenerse en cuenta los retrasos asociados alal-
gicadeentrada y salida. As, si en el ejemplo anterior el retraso asociado alaentra-
da 'X' es de4ns y el retraso asociado ala salida 'Z' es de5ns, laherramienta des-
plazara los registros segn el esquema delafigura:
intentando que:
al objeto deque:
La retemporalizacin puede utilizarse tambin como un mtodo alternativo ala
asignacin secundaria ala hora de minimizar el nmero de elementos de memoria.
As, por retemporalizacin del circuito delaFigura 4-18 a) sepodra obtener laim-
plementacin b) quepuede ser preferible en lamayora delos casos:
238 VHDL. Lenguaje estndar de Diseo Electrnico
x1 -----1
x2
x1
o Q
z
o Q
reloj
a)
x2
z
o
Q 1----
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
deser reutilizable en proyectos futuros al objeto deminimizar el esfuerzo dediseo
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
quefavorezca 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 dela aplicacin ms im-
portante, habr que establecer una prioridad entre ellas. Respecto arecomendacio-
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
deesteaspecto decreciente importancia en el diseo desistemas complejos.
En este captulo suponemos que la aplicacin ms importante es sntesis que,
por otro lado, va aconstituir de hecho la situacin ms frecuente en la mayora de
los casos. En consecuencia, las recomendaciones que hagamos estarn dirigidas a
mejorar los resultados delaherramienta desntesis que seutilice. Es particularmen-
teinteresante que un mismo equipo detrabajo comparta un mismo conjunto denor-
mas al objeto de asegurar la coherencia en cuanto a los objetivos comunes que se
establezcan.
4.5.1. Recomendaciones para sntesis
Vamosahacer acontinuacin una breve descripcin delas recomendaciones deca-
rcter general que hay que tener en cuenta alahora deasegurar una calidad mnima
enel 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 dedecidirse adecuadamente al obje-
todeasegurar con el mayor grado decertidumbre posible que laimplementacin fi-
nal va a satisfacer los requerimientos de rea, velocidad, consumo, etc., de forma
ptima. nicamente cuando el diseo arquitectural sehalla completado cabe gene-
rar el cdigo VHDL correspondiente. Abordar el diseo del sistema directamente
enVHDL no es recomendable.
Aunque VHDL tenga similitudes sintcticas con lenguajes de programacin
(particularmente ADA), setrata deun lenguaje dedescripcin dehardware. 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 devista deprogramacin puede ser ineficiente en sntesis. En este sentido, la
utilizacin de cdigo simple y fuertemente ligado a la implementacin [V95] va a
asegurar laobtencin deresultados ptimos.
240 VHDL. Lenguaje estndar de Diseo Electrnico
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 detipos enteros restringidos es recomendable.
Es preferible el uso de seales no resueltas std_ulogic frente alas resuel-
tas std_logic. En el caso devectores es recomendable lautilizacin derangos
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 defunciones lgicas o detransicin (en el
caso deFSMs) incompletamente especificadas, encuyo caso sedebe deutili-
zar 'X,14.
El uso del carcter 'X' como indiferente est recomendado tambin para
seales del tipo std_ulogic correspondientes aentradas enun bloque no utili-
zadas.
No usar variables para modelar registros. Los elementos de memoria consti-
tuyen recursos hardware que deben decidirse antes dela sntesis y declararse
como seales en ladescripcin VHDL. En este mismo sentido, deben deevi-
tarse aquellas construcciones correspondientes a "latches" implcitos, salvo
que suutilizacin seaimprescindible 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 deejecucin del proceso enlacual seasigne.
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:
i f (a = '1') then
e l s e
end i f ;
14 Podra utilizarse tambin -'. Sin embargo, este carcter es ms incmodo alahora de analizar
resultados de simulacin.
4. Sntesis 241
que:
ti(a = '1') then
e1s i f ( a = ' O' ) t hen
el s e
end if;
Es recomendable .el uso de funciones y procedimientos de usuario para en-
capsular cdigo conuna funcionalidad dada. Enlos subprogramas no sedebe
deutilizar seales que no hayansido pasadas como parmetros.
Por razones de legibilidad del cdigo, es recomendable dar el mismo nombre
alas referencias de los componentes que los de las entidades conlas que se
asocian.
4.5.1.3. Correspondencia entre simulacin y sntesis
Al objeto defacilitar laverificacin 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. Eneste sentido cabe realizar las siguientes recomendaciones:
Las seales y variables debendetomar los valores iniciales enladescripcin
detal forma que el resultado desimulacinno dependa delos valores por de-
fecto asignados por el simulador,
Enunproceso con parte combinacional, todas las seales utilizadas enla
parte combinacional debende pertenecer ala lista de sensibilidad del proce-
so.
Evitar la utilizacin de variables antes de su asignacin. Tal y como se co-
ment enel apartado 4.5, este tipo de situaciones provoca discrepancias in-
necesarias entre simulaciny 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 endetalle 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 enel
apartado 3.
242 VHDL Lenguaje estndar de Diseo Electrnico
4.6. EJERCICIOS
1. Dada la siguiente asignacin secuencial de seal:
z <= x l + x2 a f t e r 2 5 n s ;
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
Y (t) ::::2: 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:
p r o c e s a
be gi n
i f x l = ' 1 ' t h e n
z <= tI};
wa i t o n x l :
e l s i f x 2 = ' 1 ' t h e n
z <= 11';
4. Sntesis 243
wait on x2;
el se
z <= 10';
wait until xl ar x2;
end if;
end process;
a) Proponer unaimplementacin mnima.
b) Decidir si setratadeunadescripcin sintetizable. J ustificar larespuesta.
5. Dadalasiguiente descripcin:
archi tecture ...
signal databus, reg _: std_logic_vector ...
begin ...
process
wait until reloj'f,!vent aJ ld reloj='l';
databus <=(others =>' Z' ) ;
if(aCCede_a_reg+st::r?:..:1 \ G1 J !e then
if ( carga_regIstro ='ue then
reg <=dataBus,-;
else
databus <,;,~'reg;
end if;
end if;
end process;
.: i~
-- Bus con mltiples drivers
. .
-- Rscribe ertel registro
a) Proponer unaimplementacin mnima.
b) Esunadescripcin sintetizable?
e) Describir lasecuencia deentradas que muestra cmo no secorresponde la
simulacin VHDL deladescripcin anterior conel comportamiento espera-
dodelaimplementacin del apartado a).
6. Proponer declaraciones deseal VHDL sintetizables para:
a) Las seales dereloj y "reset" deuncircuito.
b) Un"bus" de32bits.
e) Datos enel rango Oa255.
d) Coeficientes enel rango -3,96875 a3,96875.
e) El resultado delamultiplicacin delos datos dee) y los coeficientes ded)
sinprdida deprecisin.
f) Los 9estados SO... S8deunamquina deestados finitos.
7. Encontrar implementaciones mnimas paralassiguientes sentencias:
a) z <=(x ar 'H') and (x ar '0');
244 VHDL. Lenguaje estndar de Diseo Electrnico
b) if ( x l / = " 0- " ) t he n
c a s e x2 i s
whe n "O-" =>
z <= 'D' i
whe n " l OO' =>
z <= /1' i
when o t he r s =>
z <= '_';
end case;
e l s e
z <= /1';
end if;
c) wi t h Y s e l e c t
z <= xl or x2 when " OO' e l s e
xl when " 01" e l s e
'Z' whe n " 10" e l s e
'1' when
1 1 1 1 " ;
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':
BCD
~ a
~ b
a
De
b8 '
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 dela palabra decontrol 'OP' esla
quesedescribeenlatabla siguiente:
Entrada decontrol Salida
OP
nat ur al F ( 16) F( 15 downt o 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 ladescripcin VHDL sintetizable.
12. Obtener una implementacin mnima para el siguientecdigo:
process (x, y)
begi n
c as e y i s
w' h en " O O ' =>
z(l) <" 'O';
when "11" =>
z(l) <= '1';
z ( 2) <= x ( 2) and not x ( l ) ;
when others =>
z (1) <= x(l);
end c as e;
end process
13. Describir enVHDL para sntesis uncontador bidireccional quecircule por el
siguientecdigo"One-Shot":
up='O' UP='1'
00000
10000
01000
00100
00010
00001
Serecomienda utilizar operaciones dedesplazamiento.
246 VHDL Lenguaje estndar de Diseo Electrnico
14. Proponer descripciones VHDL sintetizables en los tres estilos explcitos (el, e2
y e3) y en estilo implcito para lamquina deestados 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
uncircuito 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 dela
FSMD correspondiente sabiendo que las rnicrooperaciones asociadas a cada
una delas seales decontrol 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, J EEE, 1992.
[F90] E. D. FABRICIUS:lntroduction to VLSI design, McGraw-Hill, 1990.
[J EEE95] IEEE PI 076.4-1 995: VITAL, J EEE Standards Department, 1995.
[J EEE96] IEEE PI 076. 3-1996: Standard VHDL Synthesis Packages, J EEE 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. VILLARy 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, J oan Vidal y Llus Ters
IMB-CNM (CSIC)
Universitat Autnoma de Barcelona
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 VHDLpara 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
250 VHDL. Lenguaje estndar de Diseo Electrnico
5. 1. INTRODUCCiN
En este captulo sepresenta, deuna manera prctica, el uso del lenguaje VHDL pa-
rael modelado desistemas electrnicos. Para ello todo el captulo seejemplifica so-
bre un sistema basado en un procesador sencillo ("La mquina rudimentaria"
[SPC97]) y arropado con otros componentes bsicos (memoria y rbitro debus) pa-
raformar 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 seafcil demanejar. Pa-
raesta etapa sedesarrollar un modelo funcional. Posteriormente ser necesario es-
pecificar con ms detalle lainterfaz del procesador con suentorno y apartir deeste
momento, ser posible refinar por separado tanto el modelo del procesador como el
del resto del sistema hasta llegar aun modelo detallado delos 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 latareajunto con
una descripcin general de las tcnicas que se podran aplicar y los posibles usos
del VHDL en la solucin de latarea planteada. Posteriormente seaplican al sistema
ejemplo las estrategias y tcnicas ms adecuadas para nuestro caso.
En el siguiente apartado sedauna visin global delos mecanismos disponibles
en VHDL para modelar un sistema adistintos niveles de abstraccin. Estos meca-
nismos setendrn en cuenta en cada descripcin del procesador para cumplir con el
objetivo delos distintos modelos.
A continuacin sedescribe el modelado anivel algortmico. Este tipo demode-
los suelen utilizarse en las primeras etapas del diseo como ayuda a la escritura y
validacin de las especificaciones del componente aimplementar. En muchas oca-
siones es posible escribir un modelo algortmico de un componente sin especificar
ni siquiera suinterfaz con otros componentes.
La evolucin del procesador consiste en ladefinicin 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 depruebas constituyen un modelo del entorno del componente
averificar y alo largo del captulo semostrarn distintas opciones en los bancos de
pruebas del procesador amedida que sedetalle suentorno.
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 serealiza 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 anivel de transferencia de registros, se tienen en cuenta las capacidades
delas herramientas de sntesis actuales, apuntndose en cada caso las estructuras no
sintetizables y las modificaciones necesarias delos 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.
252 VHDL. Lenguaje estndar de Diseo Electrnico
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, lautili-
zacin de estos tipos implica detallar laprecisin de los datos numricos utilizados
en los algoritmos. Por ejemplo, si trabajamos con datos reales, deberamos determi-
nar un formato depunto fijo o punto flotante y asignar un nmero debits alas par-
tes entera y decimal oalamantisa y exponente.
Por otra parte, trabajar anivel debits implica determinar el formato y lacodifi-
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 decodificacin y, por ejemplo, en lugar deutili-
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 anivel 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
sedefinen operaciones matemticas sobre el tipo REAL y declaraciones detipos 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 dedatos. En este ca-
so, para la comunicacin entre componentes se debern usar funciones de conver-
sin detipo, es decir, funciones que toman como parmetro un valor deun determi-
nado tipo (por ejemplo, integer) y devuelven como resultado de su ejecucin el
equivalente enel otro tipo dedatos (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 lade permitir expresar que determinados eventos suceden alo largo del tiempo.
De hecho, el tiempo de simulacin es un elemento implcito en dichos lenguajes ya
que adiferencia delos programas escritos en un lenguaje deprogramacin, las des-
cripciones escritas en un HDL no seejecutan sino que sesimulan. Es decir, el resul-
tado desuejecucin seexpresa en funcin del tiempo desimulacin.
De manera parecida a lo que ocurre con los tipos de datos, la descripcin del
comportamiento deun sistema alo largo del tiempo puede variar en grado dedeta-
lle en funcin del nivel de abstraccin en el que seconsidere el sistema. Si sepre-
tende modelar nicamente la funcin que realiza un algoritmo, entonces ladescrip-
cin separecer mucho aun programa y no ser necesario expresar los cambios de
las seales alo largo del tiempo sino que sepodr utilizar unnico proceso ejecuta-
do secuencialmente sinconsumir tiempo de simulacin. En este caso no tendr sen-
tido la utilizacin de seales (signals) sino que seemplearn nicamente variables.
A medida que sedetalle laarquitectura del sistema sepodr modelar el parale-
lismo entre distintos componentes as como los retardos en larealizacin defuncio-
5. Modelado con VHDL 253
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 desimulacin.
En un primer momento puede ser interesante poner derelieve que existen fun-
ciones que serealizan de forma concurrente y asignarles retardos reflejando as las
prestaciones del sistema en las simulaciones. Sin embargo, ms adelante interesar
aadir detalle ala descripcin y aproximarla ms ala implementacin. Para ello, el
siguiente paso es la introduccin de un reloj que determine ciclos en el funciona-
miento del sistema. Mediante laintroduccin del reloj en las descripciones expresa-
mos el sistema como una serie declculos y asignaciones de seales que serealizan
enlos distintos ciclos dereloj. A este nivel dedetalle en el que sedeterminan los ci-
clos dereloj en los que serealizan las operaciones selellama nivel detransferencia
deregistros.
Si se desea describir un sistema ya implementado y caracterizado del cual se
conocen no nicamente el vnculo entre operaciones y ciclos dereloj sino los retar-
dos delas operaciones dentro deun ciclo dereloj seutilizarn sentencias deasigna-
cincon laclusula after.
5.2.3. Estilos de descripcin
El diseo decomponentes complejos seaborda normalmente por medio delatcni-
cadedividir el componente en subcomponentes ms sencillos interconectados entre
s. De esta forma, considerando por separado el diseo de cada uno de los compo-
nentes sereduce lacomplejidad del diseo inicial.
Del mismo modo, amedida que seaade detalle aladescripcin deun sistema
electrnico se distinguen en l los elementos que lo componen. As, en un primer
modelo anivel 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, amedida que se avanza en la toma de decisiones, sehar
explcita la existencia de subcomponentes, para los cuales se determinar una fun-
cin arealizar dentro del sistema, y una interfaz para su relacin con otros compo-
nentes. El particionado puede repetirse hasta que se llegue aun nivel de compleji-
dad delos componentes adecuado para el objetivo que persigue el modelo.
Un lenguaje dedescripcin dehardware debe permitir expresar el particionado
deun 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 dedatos 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 lafuncionalidad del modelo mediante el uso deprocedimientos y fun-
ciones en los procesos. En el extremo opuesto encontramos el estilo de descripcin
estructural que nos obligar aformalizar la interfaz de un componente mediante la
declaracin deentidad (entity) y podremos expresar laestructura mediante ladecla-
racin yreferencia decomponentes (component) dentro deuna arquitectura.
254 VHDL. Lenguaje estndar de Diseo Electrnico
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 seutilizan principalmente
para concretar la especificacin de la funcionalidad del sistema, de forma que no
haya equvocos entre los especificadores y las personas que han dellevar acabo el
diseo.
En algunos casos, la funcionalidad aimplementar 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 deconsultar 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 alaejecucin 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 enquelaconcurrencia entredistintas tareas formapartedelas 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 sealmacena in-
formacin deforma quelos componentes productores acceden al recurso paraescribir
en l, mientras que los componentes consumidores acceden para leer lainformacin.
La forma usual decomunicar dos procesos es mediante seales: un proceso ac-
ta como fuente de la cola de eventos de la seal y le asigna valores alo largo del
tiempo mediante la sentencia de asignacin a seal y otros procesos se muestran
sensibles alos cambios en el valor delaseal mediante lasentencia 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 deun proceso cuyo cdigo seencargue dearbitrar 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
derealizar descripciones cuya ejecucin produzca distintos resultados, dependiendo
del simulador donde se ejecutan. A estas descripciones se les llama no determinis-
tas y sedebe principalmente aque el orden en que seejecutan los procesos activos
en un mismo ciclo de simulacin puede variar de un simulador aotro (ver Captu-
5. Modelado con VHDL 255
lo 3). Como las variables se actualizan inmediatamente al ser asignadas dentro de
unproceso, es fcil realizar descripciones no deterministas cuando seutilizan varia-
bles globales.
Como ejemplo decomparticin derecursos vamos aconsiderar que dos proce-
soscomparten el acceso aundispositivo. El acceso al dispositivo serealiza median-
tellamadas aprocedimientos definidos en unpaquete. Imaginaremos que es necesa-
rio llamar a los procedimientos AbrirDisposi ti vo y CerrarDisposi ti vo antes
deque otro proceso pueda trabajar con el dispositivo y que adems el trabajo con el
dispositivo requiere consumir un tiempo desimulacin.
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.
Enel Listado 5-1 vemos cmo utilizaran el semforo dos procesos que quieren
llamar alos procedimientos relacionados con el dispositivo. Antes dellamar al pro-
cedimiento AbrirDisposi ti va cada proceso debe asegurarse de que el semforo
seencuentra en el estado LIBRE y debe dejarlo en estado OCUPAro para los dems
procesos. Una vez haterminado 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\ O O );
shared variable Semafoto': 'tAcces;
,00, : : ~ ,
, : : . : : : . . . '"
PI: process
begin
-- Tareas propias del proceso PI
-- Espera hasta que el acceso este libre
loop
if Semafo~ ~.LlB,REt hen
semafox: ? : ~ tlCUPAO O ;
exit;
end if;
wait for lO 'ns;
end loop;
AbrirDispositi VO l
Trabaja;
CerrarDispositivo;
256 VHDL. Lenguaje estndar de Diseo Electrnico
S e ma f o r o :=L I BRE ;
e nd pr o c e s s ;
P2: pr o c e s s
be gi n
- - T a r e a s . pr o pi a s de l pr o c e s o P2
- - E s pe r a h a s t a q u e e l a c c e s o e s t e l i br e
loop
i f S e ma f o r o =L I BRE then
S e ma f o r o :=OCUPADO;
e x i t ;
end if;
wa i t f o r l O' ns ;
e nd l o o p;
Abr i r Di s po s i t i v o ;
Trabaja;
Ce r r a r Di s po s i t i v o ;
S e ma f o r o :=L I BRE ;
e nd pr o c e s s ;
LISTADO 5-1. Ejemplo con variables compartidas.
Lasegunda opcin paraconseguir quevarios procesos escriban sobreunmis-
mo recurso consiste enutilizar una seal detipo resuelto. En estecaso lasimula-
cin ser determinista siempre quelafuncin deresolucin no dependa del orden
enquelepasen los valores enel vector devalores asignados alaseal. Esta solu-
cin no seemplea normalmente en descripciones de nivel funcional sino que es
muy til endescripciones ms detalladas del hardware paramodelar el acceso abu-
ses compartidos mediante el uso de buffers tristate y sever un ejemplo de ello
cuando semodele conms detalle el procesador y su interaccin conel bus deme-
moria.
Enel Listado 5.2 vemos el mismo ejemplo decomparticin deundispositivo
del listado anterior pero conel semforo implementado mediante unaseal detipo
resuelto en laque escriben dos procesos. La seal Semaforo es del tipo resuelto
tAcceso y puedetomar los valores LIBRE, indicando queninguno delos dos proce-
sos haentrado o pide entrar en lazona detrabajo con el dispositivo, PETICIONI,
indicando que el proceso PI solicita trabajar con el dispositivo, PETICION2, indi-
cando queel proceso P2 solicita el dispositivo, OCUPAIXJI, indicando queel proceso
PI est trabajando con el dispositivo y OCUPAIXJ2 que significa que el proceso P2
mantiene ocupado el dispositivo.
Paraacceder al dispositivo, los procesos handeasignar alaseal Semaforo su
valor depeticin y esperar aquestatomeel valor deocupado queles corresponde.
Seguidamente, el proceso que obtiene el permiso, asigna su valor deocupado ala
5. Modelado con VHDL 257
t y p e t Ac c e s o No Re s u e l t o i a ( L I BRE , P E T I CI ONl , P E T I CI 0 N2 , OCUP ADOI , OCUP AD0 2 ) ;
t y p e t Ac c e s o Ve c t o r i a a r r a y ( n a t u r a l r a n ge < of t Ac c e s o No Re s u e l t o ;
f u n c t i o n Re s u e l v e Ac c e s o { P e t i c i o n e s : t Ac c e s o Ve c t o r )
r e t u r n t Ac c e s o No Re s u e l t o i a
begin
f o r 1in P e t i c i o n e s ' r a n ge l o o p
i f P e t i c i o n e s ( 1) = OCUP ADOl ar P e t i c i o n e s ( I ) = OCUP AD0 2 t h e n
r e t u r n P e t i c i o n e s { ! ) ;
e n d i f ;
e n d l o o p ;
f o r 1in P e t i c i o n e s ' r a n ge l o o p
i f P e t i c i o n e s ( 1) = P E T I CI ONl t h e n
r e t u r n OCUP ADOI ;
e l a i f P e t i c i o n e s - t I ) = P F : 1' I CI ON2t h e n
r e t u r n OCUP AD0 2 ;
end i f ;
e n d l o o p ;
r e t u r n L I BRE ;
end Re s u e l v e Ac c e s o ;
s u b t y p e t Ac c e s o i a Re s u e l v e Ac c e s o t Ac c e s o No Re s u e l t o
s i gn a l S e ma f o r o : t Ac c e s o ;
P l : p r o c e s s
begin
- ~_ T a r e a s p r o c e s o . P I
S e ma f o r o <= P E T I CI ONl ;
i f S e ma f o r o /= ocuPArol then
wa i t u n t i l S e ma f o r o = OCUP ADOI ;
end i f
S e ma f o r o <= OCUP ADOl ;
Ab r i r Di s p o s i t i v o ;
Trabaja;
Ce r r a r Di s p o s i t i v o ;
S e ma f o r o <= L I BRE ;
e n d p r o c e s s ;
P 2 : p r o c e s s
begin
- - T a r e a s p r o c e s o P 2
S e ma f o r o <= P E T I CI ON2 ;
258 VHDL. Lenguaje estndar de Diseo Electrnico
ifS e r n af o r o /= o c UP AOO2 then
wa i t u n t i l s e ma f o r o = OCUP AOO2
end i f
S e ma f o r o <=OCUP AOO2
Ab r i r Di s p o s i t i VQ;
Trabaja .
c e r r a r Di s p o s i t i v o ;
S e r n af o r o <= L I BRE;
e n d p r o c e s s ;
LISTADO 5-2. Ejemplo de comparticin de recursos con funciones de resolucin.
seal Semaforo paraevitar que stacambie de valor ante peticiones del otro proce-
so. L afuncin deresolucin Resuel veAcceso seencarga demantener el valor ocu-
pado delaseal si alguno delos procesos est escribiendo suvalor deocupado. De-
benotarse que estadescripcin tampoco es determinista, yaque el orden en que los
procesos obtengan el dispositivo en el caso desolicitarlo simultneamente depende-
r del orden en que le lleguen los valores alafuncin de resolucin, 10 cual es de-
pendiente del simulador.
Finalmente, en la tercera opcin para compartir recursos escritos por varios
procesos, el recurso compartido seencapsula dentro deun proceso donde puede re-
presentarse mediante una variable local y sedefinen seales para el acceso de cada
proceso que desee leer oescribir informacin. En el proceso que encapsula el recur-
so seincluir cdigo paraarbitrar laescritura simultnea deinformacin.
En el L istado 5-3 se muestra la implementacin del semforo mediante esta
tcnica. El proceso Semaforo contiene lavariable Acceso donde se guarda el esta-
do del semforo. L os procesos PI y P2 acceden adicha variable mediante las sea-
les PeticionPl, OcupadoPl yPeticionP2 y OcupadoP2, respectivamente.
s i g n a l P e t i c i o n P l , Oc u p a do P I : b o o l e a n ;
s i g n a l P e t i c i o n P 2 , Oc u p a do P 2 : b o o l e a n ;
P 1 : p r o c e s s
b e g i n
- - T a r e a s p r o c e s o P I
P e t i c i o n P I <= T RUE ;
wa i t u n t i l Oc u p a do P I ;
Ab r i r Di s p o s i t i v o
Trabaja
5. Modelado con VHDL 259
Ge r r a r Di s p o s i t i v o ;
p e t i c i o n P l <= F AL . ' ) E ;
e n d p r o c e s s ;
P 2 : p r o c e s s
begin
- - T a r e a s p r o c e s o P2
P e t i c i o n P 2 <= T RO;
wa i t u n t i l Oc u p a do P 2 ;
end p r o c e s s ;
Se ma f o r o : p r o c e s s ( p ~t n : i ~f i p l ; , tf~tl hnP2)
t y p e t Ac c e s o i 8 ( L I BRE , P I , P 2 ) ;
v a r i a b l e Ac c e s o : ; t c c e i OY ' - ; r-
begin
i f P e t i c i o n P I a n d n o t P e t i c i o n P 2 t h e n
Ac c e s o := P I ;
e l a i f P e t i c i o n P 2 a n d n o t P e t i c i o n P I t h e n
Ac c e s o := P 2 ;
e l s i f p ~t ~i o n P I and P e t i c i o n P 2 a n d Ac c e s o ~ ~ BREt h e n
Ac c e s o :=P I ;
end if.;
if Ac c e s o = P I then
Oc u p a d E l _ <= TRUE;
e l a e _
Oc u p a do P I <= F AL SE ;
end i f ;
if Ac s ~; ' ~P 2 t h e n
o c u p a dP 2 <= TRUE;
e l e e
Oc u p a do P 2 <=r AL SE ~
end i f ;
e n d p r o c e s s ;
LISTADO 5- 3. Ejemplo de informacin compartida encapsulada en un proceso.
260 VHDL. Lenguaje estndar de Diseo Electrnico
A diferencia delos Listados 5-1 y 5-2, lasolucin empleada en el Listado 5-3es
determinista, es decir, debe funcionar exactamente igual en todos los simuladores.
En el caso deque los dos procesos activen su seal depeticin deforma simultnea,
el acceso seconceder al proceso PI. Esto sededuce dela forma como secomprue-
ban las condiciones en laprimera sentencia if del proceso Semaforo.
Los tipos de datos utilizados en las descripciones funcionales suelen ser prxi-
mos alos conceptos que seutilizan en laespecificacin. Seren estetipo dedescrip-
ciones donde seutilizarn con mayor frecuencia los tipos definidos por el usuario.
5.3.1. Lamquina rudimentaria
Para ejemplificar el estilo dedescripcin VHDL que sepuede realizar en las prime-
ras etapas delaconcepcin deun 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 seespecificar la arquitectura del procesa-
dor anivel 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 VonNeuman 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 sedescodifica y seejecuta, realizando las co-
rrespondientes operaciones en launidad artimtico-lgica (VAL) y modificando los
registros del procesador (banco deregistros, CP y los indicadores de cero [C] y ne-
gativo [N]).
Podemos clasificar las instrucciones en tres grupos distintos:
Instrucciones de acceso amemoria. Realizan las transacciones dedatos 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] oregistro fuente [Rf] segn lainstruccin) y ladireccin dememoria se
calcula sumando unregistro del banco deregistros 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.
5. Modelado con VHDL 261
Registro de instruccin
Banco
de
Registros
Contador de programa
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 1y 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.
262 VHDL. Lenguaje estndar de Diseo Electrnico
TABLA 5-1. El repertorio de instrucciones de la mquina rudimentaria
Instrucciones de acceso a memoria
LOAD
(Rd, Rx, DireccionBase)
Carga el contenido de la direccin de memoria indicada por los campos
DireccionBase y Rx en el registro del banco deregistros indicado por el
campo Rd. Los indicadores C y N seactualizan segn el valor cargado.
STORE
(Rf, Rx, DireccionBase)
Almacena el contenido del registro del banco de registros indicado por el
campo Rf en laposicin dememoria 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.
Salta si ms pequeo. Si N es verdadero carga el'campo Direccin enel CP. BL(Direccion)
Salta si ms pequeo o igual. Si N oC son verdaderos carga el campo Di:"
reccion en el CP.
BLE(Direccion)
Salta si no igual. Si C es falso carga el campo Direccion en el CP. BNE(Direccion)
Salta si mayor oigual. Si N es falso o C es verdadero carga el campo Di-
recci on en el CP.
BGE(Direccion)
Salta si ms grande. Si N Y C son ambos falso carga el campo Direccion
en el CP.
BG(Direccion)
Instrucciones aritmtico-lgicas
ADDI(Rd, Rfl , Numero) Suma el contenido del registro del banco deregistros indicado por el cam-
po Rfl con el valor contenido en el campo Numero. El resultado sealma-
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 sealmacena 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, seconserva 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 sealmacena en el registro indicado en el campo Rd.
5. Modelado con VHOL 263
Debemos aclarar que aunque la estructura hardware del procesador seencuen-
tramucho mas detallada en [SPC97], por el momento nos limitamos adescribir lo
estrictamente necesario para poder experimentar con el conjunto de instrucciones.
As, detalles como el nmero debits de los registros o el formato deinstruccin no
sonconsiderados en este apartado.
5.3.1.2. Modelo funcional de la mquina rudimentaria
El objetivo deuna descripcin funcional dela arquitectura del procesador presenta-
daen 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 arealizar slo permitir eje-
cutar pequeos programas y sufuncin es ms bien servir deejemplo y deespecifi-
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-
daddeesta descripcin.
En primer lugar definiremos los tipos dedatos que vamos autilizar 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 detipo entero, de for-
ma que no especificaremos su formato en nmero de bits. Para los recursos que
agrupan datos deforma indexada, como lamemoria dedatos y el banco deregistros,
definiremos untipo dedatos llamado tVectorDatos como unvector deenteros.
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 seindicar el cdigo deoperacin y tres campos detipo natural que
correspondern alos parmetros de cada instruccin segn laTabla 5.1. En las ins-
trucciones que tengan menos detres parmetros seutilizarn los primeros campos y
seignorar el valor delos restantes. El tipo dedatos 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 lafuncionalidad 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 debits
264 VHDL. Lenguaje estndar de Diseo Electrnico
delos registros, el tamao delamemoria y el nmero deregistros en el banco dere-
gistros. Sin embargo, para poder especificar el tamao de los vectores es necesario
definir algunas deestas cantidades. Por ello, en ladeclaracin depaquete declarare-
mos las constantes cNumInst, cNumDatos y cNumRegistros que correspondern al
nmero de direcciones de la memoria de instrucciones, el nmero de posiciones en
lamemoria dedatos y el nmero deregistros del banco deregistros.
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 laoperacin Y lgica bit abit 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 alas constantes pero por motivos prcticos es con-
veniente hacerlo en ladefinicin del cuerpo del paquete. En el caso deque las cons-
tantes estn definidas en ladeclaracin depaquete, si quisiramos cambiar su valor
5. Modelado con VHDL 265
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
sedefinen en el cuerpo del paquete nicamente es necesario reanalizar ste.
Para realizar la funcin Y lgica bit abit 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 ados. 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 asu re-
presentacin binaria usando el tipo SIGNED, para realizar la funcin "AND" sobre
los datos convertidos atipo signed. La funcin "AND" para estos datos s est de-
finida en el paquete STD_LOGIC_ARITH.
El cuerpo del paquete serael siguiente:
library I E E E ;
us e l E E E . ST D_ L OGI C_ l 164. a l l ;
us e I E E E . ST D_ L OGI C_ ARI T H. a l l ;
package body P a que t e MRF unc i o na l 1&
c o ns t a nt c NumI ns t : na t ur a l :=10;
c o ns t a nt c NumDa t o s ' : na t ur a l : = 200;
c o ns t a nt c NumRe gi s t r o s : na t ur a l :=8;
c o ns t a nt c Ma x NumBi t s : na t ur a l :=128;
f unc t i o n "AND" ( A, B: i nt e ge r ) r e t ur n i nt e ge r 18
v a r i a bl e M 3V : s i gne d( O to c Ma x NumBi t s - l ) ;
v a r i a bl e BBV : s i gne d( O to c Ma x NumBi t s - 1) ;
v a r i a bl e Re s ul t : s t q_ l o gi c _ v e c t o r ( O to c Ma x NumBi t s - l ) ;
be gi n
ABV :=Co nv _ s i gne d( A, c Ma x NumBi t s ) ;
BBV :=Co nv _ s i gne d( B, c Ma x NumBi t s ) ;
Re s ul t :=s t d_ l o gi c _ v e c t o r ( ABV) and s t q_ l o gi c _ v e c t o r ( BBV) ;
r e t ur n Co nv _ i nt e ge r ( s i gne d( Re s ul t ) ) ;
end "AND";
end P a que t e MRF unc i o na l ;
LISTADO 5-5. Cuerpo del paquete PaqueteMRFuncional.
De acuerdo con los objetivos de este primer modelo, no describiremos ningn
detalle delaestructura interna del procesador, ni suinterfaz con el resto del sistema.
Sinembargo, para poder simular cualquier descripcin hadeexistir una entidad. En
nuestro caso utilizaremos una entidad vaca:
e nt l t y Ma qui na Rudi me nt a r i a l s
end Ma qui na Rudi me nt a r i a ;
266 VHDL. Lenguaje estndar de Diseo Electrnico
La arquitectura del modelo funcional ser muy yarecida a un programa escrito
en un lenguaje de programacin como eo 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:
u s e wo r k . P a q u e t e MRF u n c i o n a l . a l l ;
a r c h i t e c t u r e F u n c i o n a l of Ma q u i n a Ru d i I De n t a r i a i s
b e g i o
P r o c e s a d o r : p r o c e s s
v a r i a b l e CP
v a r i a b l e RI
v a r i a b l e P r o g r a ma
v a r i a b l e Me mDa t o s
v a r i a b l e N
v a r i a b l e C
v a r i a b l e Re g i s t r o s
i n t e g e r ;
t I n s t r u c c i o n ;
t Ve c t o r l n s t ( O to c Nu mI n s t ) ;
t v e c t o r t a t o s (O to c Nu r o Da t o s ) ;
b o o l e a n ;
b o o l e a n ; . ,
t Ve c t o r Da t o s ( O to c Nu mRe g i s t r o s ) ;
a l i a s Rd i n t e g e r isRI . Ca r r p o l ;
a l i a s Rx i n t e g e r i8RI . Ca r r p o 2;
a l i a s Di r e c c i On Ba s e :nteqer i8RI . Ca r r p o 3;
a l i a s Rf i n t e g e r i8RI . Ca r r p o l ;
a l i a s Rf l i n t e g e r i8RI . Ca r r p o 2 ;
a l i a s Nu me r o i n t e g e r i8RI , ~a r r p o 3 ;
a l i a s Rf 2 i n t e g e r i8RI . Ca r r p o 3 ;
a l i a s Di r e c c i o n i n t e g e r i8RI . Ca I l I J Ol ;
p r o c e d u r e L e e r l n s t r u c c i o n i8
end L e e r l n s t r u c c i o n ;
p r o c e d u r e E j e c u t a r l n s q : u c c i o n ia
end E j e c u t i l r t F t r u c c : i o l J ;
p r o c e d u r e I n f . c i a t i z a Me mo r i a i8
b e g i o
P r o g r a ma ( O) . - ( L OAD, 2 , O, O ) ;
P r o g r a ma ( l ) , _ ( L OAD, 3 , , 1 ) i
P r o g r a ma ( 2 ) := ( ADD, 4 , 3 . 21 l '
5. Modelado con VHDL 267
Programa(3) ti'i (STORE, ~, O, 2);
MemDat:.:os(O) !.;: le;
MemDatosU) :=20;
eDd InicializaMemoria;
'".; ~'. .... "_ ,00_' _. _', .. _~
begi n
-- Inicializacin del programa
I ni c i a l i z a Memo r i a ;
CP ,;: O;
Registro?(O) : : ; 0;
loop -', ..
L eer I h s f r u ( : i n;
E j ec u t a r I ns t r u c c i o h ;
wait for 10ns;
end loop;
end pr o c es s ;
end F u nc i o na l ;
LISTADO 5-6. Arquitectura funcional de la maquinaria rudimentaria.
En primer lugar observamos laindicacin mediantelasentencia use dequealo
largo dela descripcin utilizaremos los objetos definidos anteriormenteen el pa-
quetePaqueteMRFuncional. A continuacin sedefineel cuerpo dela arquitectura,
dondenicamente seencuentra el proceso llamado Procesador. Esteproceso se
componedeladeclaracin devariables y procedimientos y el cuerpo del proceso.
Los recursos dealmacenamiento del procesador serepresentarn medianteva-
riables: el contador deprogramas (variableCP, el registro deinstrucciones [RI)), la
memoria deprogramas (Programa), lamemoria dedatos (MemDatoS), los indicado-
res (Ny c) y el banco deregistros (Registros).
La variableRI es la quepresenta mayor complejidad en cuanto a la informa-
cin quesealmacena en ella. Aunqueel tipo tInstruccion seutilicepara todas
las instrucciones, los tres campos numricos del tipo tienen distinto significado en
cada instruccin. Por ello, sera cmodo poder referirseacada campo con un nom-
bredeacuerdo al significado quetenga en cada momento. Esto seconsigue en
VHDL por medio deladeclaracin dealias deuna variable. En nuestro caso defini-
mos los nombres Rd, Rf Y Direccion para el campo Canpol dela variableRI, RxY
Rfl para Canpo2 y DireccionBase, Numero y Rf2 para Canpo3.
El cuerpo del proceso consta dedos partes: una inicializacin delas variables y
laejecucin delas instrucciones. En lainicializacin devariables serealiza una lla-
mada al procedimiento InicializaMemoria el cual inicializa las variables Pro-
grama y MemDatos introduciendo un pequeo programa quesuma el contenido de
las direcciones Oy 1delamemoria dedatos y almacena el resultado en ladireccin
2.Para ello utiliza los registros 2 y 3para los operandos y el 4 para el resultado. El
resto dela inicializacin devariables consisteen indicar queel programa empieza
en la direccin Odela memoria deprogramas asignando Oala variableCPy sein-
troducen los datos necesarios en el banco deregistros.
268 VHDL. Lenguaje estndar de Diseo Electrnico
Posteriormente alainicializacin, el proceso entra en unbucle que vacargando
y ejecutando instrucciones, detenindose un tiempo arbitrario de 10ns despus de
la ejecucin de cada instruccin. Esta espera entre instrucciones evita que todo el
programa se ejecute en el tiempo de simulacin Oy 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 dediagra-
madeondas.
Como yahemos dicho anteriormente, una descripcin deeste estilo debe servir
principalmente para detallar y depurar las especificaciones y, por lo tanto, aeste ni-
vel seutilizar el simulador deuna forma interactiva. modificando y depurando dis-
tintas alternativas y controlando el propio diseador el final de la simulacin. Sin
embargo, mejorando lainterfaz con el usuario deladescripcin, por ejemplo, alma-
cenando los programas y datos en ficheros, podra servir como herramienta deeva-
luacin para el desarrollo decompiladores.
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 deprogramas incrementndolo en una unidad.
p r o c e d u r e L e e r l n s E r u c c i o n l s
be gi n
RI :=P r o gr a ma ( CP ) ;
CP :=CP + 1;
e o d L e e r l n s t r u c c i o n ;
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 lasentencia case para seleccionar las sentencias
aejecutar en funcin de la instruccin de que setrate. Para cada instruccin existe
una clusula when en la que seactualizan los recursos de almacenamiento del pro-
cesador deacuerdo con suejecucin.
p r o c e d u r e E j e c u t a r I n s t r u c c i o n is
v a r i a bl e Di r Abs o l u E a : i n t e ge r ;
be gi n
c a s e RI . Co d i go Op e r a c i o n l s .
when LOAD =>
Di r Abs o l u t a :=Di r e c c i o n Ba s e + Re gi s t r o s ( Rx ) ;
5. Modelado con VHDL 269
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; =>
ifC then
CP :=Direccien;
end i f ;
when BL =>
if N then
CP : = Direccion;
end i f ;
when BL E =>
if C or N then
CP :=Direccion;
end i f ;
when ENE =>
if not C then
CP :=Direccion;
end i f ;
when BGE =>
if C or (not N) then
CP :=Direccion;
end i f ;
when BG =>
if (not C) or (not N) then
CP :=Direccion;
end i f ;
wben ADDI =>
Registros (Rd) := Registros (Rfl)
e := Registros (Rd) = O;
N :=Registros (Rd) <O;
wben SUBl =>
Registros (Rdl :" Registros (Rfl)
C :=Registros(Rd) = O;
N :=Re9ist;rosUl41 < O;
wben ADD =>
Registos (Rq) ;;, =: Regis~ro>(R, t:q
C := Registros t tdl = O; . "
N :=~gistros (ltd) t'd;'
wben SUB =>
Registros (Rd) :=R~stros(Rfl)
e ::: Registros (Rdl e" O;
. N :=Registros (Rd) < O;
+ Numero;
'"' Numero;
+.Reg:i.~t:::os(Rf2) ;
';', ~" ", .. _'o .. " ...
- Registros (Rf2);
270 VHDL. Lenguaje estndar de Diseo Electrnico
when A SR =>
Re g i s t r o s ( Rd I := Re g i s t r o s ( Rf 2 ) / 2 ;
e := Re g i s t r o s ( Rd ) = O;
N := Re g i s t r o s ( Rd ) < O;
when A N DL =>
Re g i s t r o s (Fkj) .:= Re g i s t r o s (Rfl) and Re g i s t r o s ( Rf 2 ) ;
e := Re g i s t r o s ( Rd ) = O;
N := Re g i s t r p s ( Rd ) < : Q ;
en~ ::ase
end E j e c u t a r l n s t r u c c i o n ;
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. A dems 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.
L a divisin del cdigo en procesos nos ayuda amodelar 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 deforma que surelacin con los dems componen-
tes deun sistema quede perfectamente definida.
En laeleccin de los tipos de datos de los puertos delaentidad deben conside-
rarse dos aspectos: el nivel deabstraccin deladescripcin y lacompatibilidad 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 sedesea 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 seencuentran detallados anivel debit
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 deuntipo aotro.
5. Modelado con VHOL 271
5.4.1. Lamquina rudimentaria: interfaz
y primer particionado
Eneste apartado vamos adefinir 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 suinterfaz con el entorno, es de-
cir, debemos escribir una entidad donde seincluyan todas las entradas y salidas del
procesador. Esta entidad deber permanecer invariable en los refinamientos sucesi-
vos que serealicen en la arquitectura del procesador, puesto que con ella sepreten-
deindependizar ladescripcin del sistema deladescripcin 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 alamemoria deprogramas 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 amemoria. Final-
mente el procesador necesitar indicar ladireccin dememoria alaque desea acce-
der atravs de un bus dedirecciones (Direccion), sealar si el acceso amemoria
es de lectura o escritura mediante una seal de control (Escribe), indicar ala me-
moria que los datos, direcciones y seales de control son vlidos mediante una se-
al dehabilitacin (Habili taMem)y leer oescribir datos atravs deun bus dedatos
bidireccional (Datos).
Para los tipos delos puertos escogeremos los tipos multivaluados estndar defi-
nidos en el paquete STD_LOOrC_1164. Con ello podemos describir anivel debit 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 amemoria.
El siguiente listado muestra ladefinicin deentidad 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, deforma que
sereconozcan los estmulos que otros componentes del sistema enviarn al procesa-
dor atravs delos puertos deentrada y seproporcionen las respuestas adecuadas en
los puertos desalida. Laexistencia deesta interfaz nos obliga arespetar 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 amemoria para lectura y escritura, En principio el procesador acceder a
lamemoria en un ciclo desureloj, 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, lamemoria necesitar que los datos, direcciones y laseal Escribe estn es-
tables un cierto tiempo antes y despus de la activacin y desactivacin de la seal
HabilitaMem. Esto seconseguir aadiendo lalgica necesaria en el sistema y, por
lotanto, no nos preocuparemos deello enel modelo del procesador.
La arquitectura del procesador, aunque no se describa a nivel de transferencia
entre registros, ser mucho ms cercana al hardware que ladescripcin meramente
funcional. Ello nos obliga autilizar tipos dedatos capaces derepresentar los valores
lgicos que toman las conexiones delos circuitos digitales y adefinir los formatos a
nivel debits 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 einstrucciones 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
Escribe
.' , ., ,
., .
. " .
------i------1 - - -- - -: ~ - - -- -:--- -~--
IJIJ///J'lll/bJ/////W!/I/
1!Z171711l1lb//)ZY/$/I//
: ' : ' :
Direccion
Datos
FIGURA 5-2. Ciclode lectura.
I
t
[

,
5. Modelado con VHDL 273
Reloj
PeticionBus
I L_
BusLibre
HabilitaMen
Escribe - - - - - - - ~- - - - - - - - - - - - - r Jil-----! ------~--------
1/!f!!II7///llq//IlI//J/lI/lJI
lIIipI/flJIl(CJXIIf/l/ip/lll
Direccion
Datos
FIGURA 5-3. Ciclo de escritura.
valor delos dos bits ms significativos delainstruccin, y dentro delas instruccio-
nes aritmtico-lgicas sedistingue elmodo dedireccionamiento (inmediato oregis-
tro-registro) segn elcampo OP delainstruccin. Elformato para cada tipo deins-
truccin semuestra en laFigura 5-4.
2 3 3 8
---
I 00 I Rd I Rx I Direccin Base
Formato de la instruccin LOAD
2 3 3 8
---
I 01 I Rl I Rx I Direccin Base Formato de la instruccin STORE
2 3 3 8
Direccin
Formato de las instrucciones
de salto
I 10 I Cond I 000 I
---
2 3 3 5 3
Formato de las instrucciones
de suma y resta de inmediato
--_. . . . . .
I 11 I Rd I Rl1 I Nmero I OP I
2 3 3 3 2 3
Formato del resto de instrucciones
aritmticas y lgicas
------
I 11 Rd I Rl1 Rl2 I 00 I OP I
FIGURA 5-4. Formato de las instrucciones.
274 VHDL. Lenguaje estndar de Diseo Electrnico
TABLA 5-2. Cdigosdeoperacin
OP Instruccin
100 Suma (ADD)
101 Resta (SUB)
110 Desplazamiento aritmtico a la derecha (ASR)
111 ylgica (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) yCond (para las instrucciones de salio). Aunque lacodi-
ficacin de dichos campos puede facilitar ciertas implementaciones del procesador
y, por consiguiente, podra ser til determinar cul es lamejor codificacin una vez
sehaya planteado el modelo detallado del procesador, por el momento utilizaremos
lacodificacin especificada en [SPC97]. Las siguientes tablas muestran lacodifica-
cin deestos campos.
Laprimera particin que podemos hacer del procesador, deforma que refleje la
estructura del hardware que finalmente lo implementar, es distinguir una unidad
decontrol yuna unidad deproceso. Launidad deproceso contendr los recursos de
clculo del procesador, mientras que la unidad de control indicar cmo seinterco-
nectan yqu operaciones realizan dichos recursos en cada ciclo dereloj.
En la unidad deproceso encontraremos: el registro de instruccin (RI), el con-
tador deprogramas (CP), el banco deregistros, un registro auxiliar (A), un registro
donde seguardar la direccin en los accesos amemoria (Registro deDireccin de
Memoria, RDM) ylos registros para los indicadores N yC (N yC).
TABLA 5-3. Cdigosdecondicin
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)
5. Modelado con VHDL 275
Para controlar las operaciones en launidad deproceso necesitamos definir unas
seales de control cuyo valor sedeterminar en launidad 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 oenel CP seasigna al bus dedirecciones.
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 ladireccin amemoria viene indicada por el re-
gistro RDM opor el CP.
SelRegLectura. Indica qu campo del registro de instruccin contiene el
nmero del registro del banco deregistros que sevaaleer.
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), seescribe en el registro indicado por el campo Rd del registro deins-
truccin.
CargaRDM.Cuando est activa, secarga el registro RDM con el resultado de
calcular ladireccin indicada en las instrucciones LOAD y STORE.
CargaRI. Cuando est activa, secarga el registro deinstruccin desde el bus
dedatos.
CargaCP.Cuando est activa, el CP secarga con el campo Direccion del RI.
IncCP. Cuando est activa, seincrementa el CP.
Opera. Cuando est activa, indica que el contenido aescribir en el banco de
registros es el resultado delaVAL. En caso contrario, el valor aescribir pro-
viene del bus dedatos.
CargaN. Cuando est activa, el registro Nsecarga con el indicador de nega-
tivo delaVAL.
CargaC. Cuando est activar el registro C se carga con el indicador de cero
delaVAL.
La unidad decontrol asu vez necesita conocer el tipo de instruccin que seva
aejecutar y el valor delos indicadores N y C para poder asignar valores alas sea-
les decontrol. As, launidad de control ha depoder acceder alos dos bits ms sig-
nificativos del RI (campo ca) y launidad deproceso indicar el valor del indicador
seleccionado por el campo Cond del RI a la unidad de control mediante la seal
CondicionSal tooLaFigura 5-5 muestra deforma esquemtica laparticin del pro-
cesador y las funciones delas seales decontrol en launidad deproceso.
276 VHDL. Lenguaje estndar de Diseo Electrnico
Banco
Opera de
selR~
RreLg_iSttros_~~ Opera
- ~~
Datos
HabilitaDatos
EscribeRegislro
Unidad
n~
T~
CondicinSalto
de
control
IncCP
HabilnaDireccin
Direccin
FIGURA 5-5. Esquema de la primera particin del procesador.
Laparticin del procesador en unidad decontrol y proceso puede modelarse en
VHDL usando un proceso para cada unidad. As, en laarquitectura que vamos aes-
cribir y que llamaremos PrimeraParticion existirn los procesos UControl y
UProceso. Dentro delos procesos el cdigo ser parecido al cdigo para ladescrip-
cin funcional del procesador en el sentido en que no se mostrarn ms detalles de
laestructura decada unidad.
En cada uno de los procesos serepresentarn los recursos de almacenamiento
mediante variables y se utilizarn seales para la informacin que se transmita de
un proceso aotro, como las seales de control y la informacin sobre los indicado-
res y el tipo deinstruccin contenida en el RI.
En el Listado 5-10 semuestra el esqueleto delaarquitectura 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 sedeja 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 dedatos (Ha-
5. Modelado con VHDL 277
library IEEE;
u s e I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
u s e I E E E . S T D_ Ul GI C. . , . ARI T H. a l l ;
a r c h l t e c t u r e P r i me r a P a r t i c i o n of Ma q u i ~t a r i a l s
c o n s t a n t c NBi t P a l a b r a : n a t u r a l :=1 6 ,
c o n s t a n t c NBi t Di r e c c i o n : n a t u r a l :=,'8';
c o n s t a n t c Ce r o : s t d ~l o g i c _ v e c t 6 r ( c NBi t P a l a b r a - 1 d o wn t o O)
, := ( o t h e r s => 'O' T i-
t y p e t S e L Re g i s t r o l s ( S e l Rd , S e ~Rx , S e l Rf , S e l Rf 1 , S e l Rf 2 ) ;
t y p e t F u e n t e Di r e c c i o n l s ( Co n t P r g : , 'Re g Di r Me r n ) ;
t y p e t Ve c t o r Re g i s t r o l s array ( n a t u r a l r a n g a < of
s t d _ l o g i c _ v e c t o r ( c NBi t P a l a b r a - 1 d o wn t o O) ;
" ,
s i g n a l Hq b i l ~t a I ) i r e c c i o n ; . ~. t P J o g i c ;
s i g n a l Ha b i Ht a b a t o s ' : ' s t ( t l r i g i c ;
s i g n a l F u e n t e Di r e c c i o n : t F u e n t e Di r e c c i o n ;
s i g n a l S e l Re g L e Ct u r a ' ' ; _ : ' ' ' : " E s e 1 Re g i s t r o ;
s i g n a 1 E s c r i b e Re g i s t r o : s t d _ l o g i c ;
s i g n a l Ca r g a Rr M
s i g n a l Ca r g a RI
s i g n a l Ca r g a CP
s i g n a l Ca r g a A
s i g n a l I n c CP
s i g n a l Op e r a
s t d _ l Og i c ;
s t d _ l o g i c ;
s t d _ l o g i c ;
s t c l . . . l o g i c ;
s t d J o g i c ;
s t d _ l o g i c ;
s i g n a l T i p o l n s t r u c c i o n : std .. J o g i c _ v e c t o r ( l d o wn t o O);
s i g n a l Co n d i c i o n S a l t o : s t d _ l o g i c ;
s i g n a l Di r e c c i o n _ I
s i g n a l Da t o s _ I
s t d _ l o g i c _ v e c t o r ( CNBi t Di r e c c i o n - 1 d o wn t o O);
: s t d _ l o g i c ~v e c t o r ( c NBi t P a l a b r a - 1 d o wn t o O) ;
b e g i n
UCo n t r o l : p r o c e s s
end p r o c e s s ;
UP r o c e s o : p r o c e s s
end p r o c e s s ;
wi t h Ha b i l i t a Di r e c c i o n s e l e c t
Di r e c c i o n <=Di r e c c i o n _ I wh e n ' 1 ' ,
( o t h e r s => ' Z' ) wh e n o t h e r s ;
wi t h Ha b i l i t a Da t o s s e l e c t
Da t o s <=Da t o s _ I wh e n ' 1 ' ,
( o t h e r s => ' Z' ) wh e n o t h e r s ;
end P r i me r a P a r t i c i o n ;
LISTADO 5..10. Arquitectura PrimeraParticion de lamquina rudimentaria.
278 VHDL. Lenguaje estndar de Diseo Electrnico
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.
UCo n t r o l : p r o c e s s
p r o c e d u r e S o l i c i t a Bu s i s
end S o l i c i t a Bu s ;
p r o c e d u r e L i b e r a Bu s l s
end L i b e r a Bu s ;
p r o c e d u r e L e c t u r a i s
end L e c t u r a ;
p r o c e d u r e E s c r i t u r a l s
end E s c r i t u r a ;
p r o c e d u r e Ca r g a l n s t r u c c i o n l s
end c a r g a l n : >t r u c c i o n ;
p r o c e d u r e Ca l c u l a Di r e c c i o n i s
end Ca l c u l a Di r e c c i o n ;
p r o c e d u r e E j e c u t a l n s t r u c c i o n l s
end E j e c u t a l n s t r u c c i o n ;
b e g i n
wait until l n i c i a l i : z ; a = '0';
Ha b i l i t a Me m <= /67 " . , , , . . . ."
E s c r i b e <= "Z';
5. Modeladocon VHOL 279
P e t i c i o n Bu l 3 <;:.' O' L "
E s c r i b e Re g i s t r o <= ,'0';
Ha b i l i t a Di r e c c i o n <= ' 0 ' ;
Ha b i l i t a Da t o s <= ' 0 ' ;
Opera "<= '0';
Ca r g a RL ' M <= ' O' ;
Ca r g a RI <= ' 0 ' ;
IncCP <= '0';
Cargacp <= O' ;
Ca r g a A <= ' O' ; j
loop ,
wa i t u n t i l Re l o j = '1';
Ca r g a l n s t r u e c i QJ l ~ ; , , . ~
wa i t u n t i l Re l o j = ' 1 ' ;
E j e c u t a l n s t r u c c i o n ;
end loop;
e n d p r o c e s s ;
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-
cargadode 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 uncircuito real los registros que guardan el estado interno del proce-
sador reaccionaran a una activacin de la seal Inicializa de forma inmediata y
asncrona ocomo mximo tardaran un ciclo de reloj, independientemente de la ta-
rea que estuviera realizando el procesador en ese momento. En cambio, modelar es-
te tipode 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 flujopara 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 sidonormal ose 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 slose ejecuta en el caso de que BusLibre noest 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: unoque modificara el valor de
280 VHDL. Lenguaje estndar de Diseo Electrnico
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' ,
wait until R e l o j =' 1 ' ;
HabilitaMem ~~.,'Oi ,
Escribe <=,V;
EscribeRegistro )<='O';
HabilitaDireccion <='O';
LiberaBus;
end Lectura;
procedure Escritura ia
begin
SolicitaBus;
FuenteDireccion <=.RegDirMem; ,
wait until Reld) = '1';
HabilitaDireccian <='1';
5. Modelado con VHDL 281
Ha b i f a t i i t o s <= l';
S e l Re g L e c t u r a <= S e l Rf ;
E s c r i b e <= ' 1 ' ;
Ha b i l i t a Me m <= '1';
wa i t u n t i 1 Re l o j = ' 1 ' ;
Ha b i l i t a Me m <= ' 0' ;
Ha b i l i t a Di r e c c i o n <= '~';
Ha h i l i t a Da t o s
c
<= ' 0' ;
r : s c r i b e <= ' Z' ;
L i b e r a Bu s ;
end E s c r i t u r a ; e
LISTADO 5-13. Procedimientos de escritura y lectura a memoria del proceso
UControl.
El procedimiento CargaInstruccion realiza la bsqueda de una instruccin
enmemoria. Es muy parecido al procedimiento Lectura con ladiferencia deque la
direccin aque se accede seencuentra en el contador deprogramas 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 lacarga delasiguiente instruccin.
p r o c e d u r e Ca r g a I n s t r u c c i o n i s
begin
S o l i c i t a Bu s ;
F u e n t e Di r e c c i o n <= Co n t P r o g ;
wa i t u n t i l Re l o j ' " ' 1 ' ;
I n c CP <= ' 1 ' ;
Ha b i l i t a Di r e c c i o n <= ' l ' ;
E s c r i b e <= ' 0' ;
Ha b i l i t a Me m <= ' 1 ' ;
Ca r g a RI <= ' 1 ' ;
wa i t u n t i l Re l o j = '1';
I n c CP <= ' 0' ;
Ha b i l i t a Me m <= ' O ' ;
E s c r i b e <= ' Z' ;
CargaR! <= 'O';
Ha b i l i t a Di r e c c i o n <= ' 0' ;
L i b e r a Bu s ;
end Ca r g a I n s t r u c c i o n ;
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 ladireccin indicada por los campos Rx y DireccionBa-
se delas instrucciones LOAD y STORE en el RDM.
282 VHDL. Lenguaje estndar de Diseo Electrnico
p r o c e d u r e Ca l c u l a Di r e c c i o n 1 8
beg1n
S e l Re g L e c t u r a <= S e l Rx :
Ca r g a RDM <= ~l':-,,-
wait until Re l o j = '1':
Ca r g a RDM <= ' O' :
end Ca l c u l a Di r e c c i o n :
LISTADO 5-15. Procedimiento para el clculo de la direccin de memoria en el
proceso UControl.
Elprocedimiento EjecutaInstruccion determinaquetipo deinstruccin seen-
cuentraenelRI segn laseal TipoInstruccion y paracadauno delos cuatro posi-
bles tipos deinstrucciones activalas seales decontrol adecuadas. Paralasinstruccio-
nes LOAD y STORE bastacon llamar alos procedimientos CalculaDireccion y
Lectura o Escritura respectivamente. En los dems tipos .deinstrucciones es en
este procedimiento donde directamente se determinan los valores de las seales de
control en los ciclos necesarios paralaejecucin de cadatipo de instruccin. Debe
notarse que parte de ladecodificacin de lainstruccin se realiza en launidad de
proceso como, por ejemplo, determinar laoperacin de laVAL apartir del campo
OP delas instrucciones aritmtico-lgicas.
p r o c e d u r e E j e c u t a I n S t r u c c i o n 1 8
be g i n
c a s e T i p o l n s t r u c c i o n ie
whe n "00" => - LOAD
Ca l c u l a Di r e c c i o D:
L e c t u r a :
whe n 01" => - STORE
Ca l c u l a Di r e c c i o n :
E s c r i t u r a :
whe n " l O" => - S a l t o
i f Co n d i c i o n S a l t o = ' 1 ' t he n
Ca r g a CP <= '1':
wait until Re l o j = '1':
Ca r g a CP <= ' O' :
end i f :
whe n " 1 1 " => - a r i t hme t i c o - l o g i c a
S e l Re g L e c t u r a <= 5 e l Rf l :
Ca r g a A <= '~:
wait until Re l o j = ' 1 ' :
Ca r g a A <= ' O' :
S e l Re g L e c t u r a <= 5 e l Rf 2 :
Opera <= '1':
E s c r i be Re g i s t r o <= 'l'r
wait until Re l o j = ' 1 ' i
5. Modelado con VHDL 283
Opera <= 'O';
EscribeRegistro <= ' O' ;
when others =>
null;
e nd c a s e ;
end Ejecutalnstruccion;
LISTADO 5-16. Procedimiento para la ejecucin de instrucciones en el proceso
UControl.
Enel proceso UProcesoserepresentanmediante variables los recursos dealma-
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 delas instrucciones anivel debits, el tipo dedatos utilizado para dichas va-
riables es el std_logic_vector. Adems, para facilitar las referencias alos distin-
tos campos dentro deuna instruccin, sedefinenalias para la variable RI, de modo
quepodremos referirnos al campo queindica el tipo deinstruccincomo ca (bits 15-
14), al campo que indica la operacinaritmtica como OP (bits 2 aO), alos campos
que indicanel registro fuente y destino enlas instrucciones LOAD y STORE como
Rd y Rf respectivamente (bits 13a 11) y al campo que indica el valor inmediato con
el queoperar enlas operaciones aritmticas como Numero(bits 7a3).
El proceso UProcesotampoco realiza unmodelado real delos cambios enlase-
al Inicializa. Por el contrario, espera aque sta sedesactive para inicializar las
variables que representan los recursos de almacenamiento del procesador y aconti-
nuacinentra en.unbucle indefinido ejecutando encada flanco de subida del reloj
las rdenes queleenva el proceso UControlatravs delas seales decontrol.
Enel bucle del proceso seactualizanlas variables que representan los recursos
(RI, RDM, CP, registro A, banco de registros eindicadores) de acuerdo conlas se-
ales de control recibidas y al final se asignanlas seales que comunican este pro-
ceso conel proceso UControl (CondicionSalto, TipoInstruccion) y conlos
puertos externos (Datos_I y Direccion_I).
Enel siguiente listado semuestra el cdigo correspondiente al proceso.
UProceso: pr o c e s s
a l i a s Rf
std_logic_vector(l5 downto O);
std.,._logic_vector(l downto O)
ls RI(15 downto 14);
std_logic_ vector (2 downto O)
is RI (2 downto O);
std_logic_vector (2 downto O)
ls RI(13 downto 11);
std_logic_vector(2 downto O)
is RI (13downto 11);
std_logic_vector{4 downto O)
ls RI(7 downto 3);
va r i a bl e RI
alias CO
alias OP
alias Rd.
alias .Numero
284 VHDL. Lenguaje estndar de Diseo Electrnico
variable BancoRegistros.
variable C
variable N
variable R DM
variable A
variable CP
tVectorRegistro(O to 1) ;
std,_logic;
std,_logic;
std,_logic_vector(7 downto O ) ;
std,_logic_ vector (15 downto O);
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
begi n
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;
begi n
wait until rncatza = 'O'; ,
CP : = (others => ' O' ) ;
C := 'O';
N := 'O';
for I inO 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, R I) )(cNBitDireccion-1 downto O)},
+ unsigned(IUtcNBitDireccion-1 dawnto O));
end if;
-- Logica asociada al CP
ifCargaCP = '1' then
CP := RI(cNBitDireccion-1 downto O)_;
end if;
5, Modelado con VHDL 285
t f I n c CP = '1' t h e n
CP : = u n s i g n e d ( CP ) + 1;
e n d t f ;
- - Ca r g a d e l r e g i s t r o A
t f Ca r g a A = ' 1' then
A : = Ba n c o Re g i s t r o s ( Ca l c Re g L e c t u r a ( S e l Re g L e c t u r a , RI ) ) ;
e n d t f ;
- - E s c r i t u r a en e l Ba n c o Re g i s t r o s
t f E s c r i b e Re g i s t r o = '1' t b e n
i Rd : : : ; Co n v _ i n t e g e r ( u n s i g n e d ( Rd ) ) ;
ifOp e r a = '1' then
case OP 18
wh e n " 000' => - - ADDI
Ba n c o Re g i s t r o s ( i Rd ) : = s i g n e d ( Nu me r o ) + s i g n e d ( A) ;
wben 001 => - - S UBI
Ba n c o Re g i s t r o s ( i Rd ) : = s i g n e d ( A) - s i g n e d ( Nu me r o ) ;
when "lOO => - - ADD .
Ba n c o Re g i s t r o s ( i Rd ) : = s i g n e d ( A) +
s i g n a d ( Ba n c o Re g i s t r o s (
Ca l c Re g L e c t u r a ( S e l Re g L e c t u r a , RI ) n;
wh e n "101' => - - S UB
Ba n c o Re g i s t r o s ( i Rd ) : = s i g n e d ( A) +
s i g n e d { Ba n c o Re g i s t r o s {
Ca l c Re g L e c t u r a { S e l Re g L e c t u r a , RI)));
wben "110 "E . > - - ASR
Ba n c o Re g i s t r o s ( i Rd ) : =
s t Q_ l o g i c _ v e c t o r ( S HL { s i g n e d ( A) ,
u n s i g n e d ' ( l ) ) ) ;
when " 111' => -- ANO
Ba n c o Re g i s t r o s ( i Rd ) : = A and Ba n c o Re g i s t r o s (
Ca l c Re g L e c t u r a ( S e l Re g L e c t u r a , RI ) ) ;
wh e n o t h e r s =>
n u l l ;
end c a s e ;
e l s e
Ba n c o Re g i s t r o s ( i Rd ) : = Da t o s ;
e n d if;
i f Ba n c o Re g i s t r o s ( i Rd ) = c Ce r o t h e n
C ,- '1';
e l s e
e ,- 'O';
e n d i f ;
t f Ba n c o Re g i s t r o s ( i Rd ) ( 15 ) = ' 1' t h e n
N,- '1';
e l s e
N ,- 'O';
end i f ;
end if;
- - As i g n a c i u n d e T i p o l n s t r u c c i o n yCo n d i c i o n S a l t o
T i p o l n s t r u c c i o n <= COI
286 VHDL. Lenguaje estndar de Diseo Electrnico
c a s e RI ( 1 3 d o wn t o 1 1 ) i s
whe n 000 =>
Co n d i c i o n S a l t o <= '1';
whe n 001 " =>
Co n d i c i o n S a l t o <= C
when ' 01 0" =>
Co n d i c i o n S l t o <= Ni
when 01 1 " :=>
Co n d i c i o n s a l t o <= C or N
when " 1 01 " =>
Co n d i c i o n S a l t o <= not C;
when * 1 1 0" =>
Co n d i c i a n S a l t o - <= C o r n o t N;
when " 1 1 1 " =>
Co n d i c i o n S a l t o <= (not C) and (not N);
-- BEQ
-- BL E
BGE
-- BG
when othera =>
Co n d i c i o n S a l t o <= ' X' ;
end c a s e ;
- - As i g n a c i n d e Da t o s _ I y Di r e c c i o n _ I
Da t o s _ I <= Ba n c o Re g i s t r o s ( Co n v _ i n t e g e r (unsigned (RdU )
if F u e n t e Oi r e c c i o n = ContProg then - - --
Di r e c c i o n _ I <~ CP ;
e l s e
Di r e c c i o n _ I <= ROM;
end i f ;
e n d l o o p ;
e n d p r o c e s s ;
LISTADO 5-17. Proceso UProceso de la arquitectura PrimeraParticion.
5.4.2. Bancos de pruebas
L a verificacin de los modelos VHDL constituye normalmente una de las etapas
ms difciles, pero ineludibles, del diseo electrnico. L a 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 decasos, con el objetivo dedetectar losposibles errores.
En este apartado se considerarn los distintos tipos de bancos de pruebas que
pueden realizarse segn loavanzada yestable que seencuentre laespecificacin del
sistema donde se incluye el modelo a verificar. L os distintos tipos de bancos de
pruebas seaplicarn al diseo del procesador amedida 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 sedeben incluir en losbancos depruebas.
5. Modelado con VHOL 287
Con anterioridad alaaparicin delenguajes dedescripcin dehardware 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 ala mera especificacin de cambios en las entradas del componente averi-
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 unaparte.
Desde esta perspectiva, cuando se escriben los bancos de prueba deben consi-
derarse cuestiones parecidas acuando serealiza el modelo deun componente: exis-
tirn siempre distintas alternativas para su realizacin segn el grado de precisin,
prestaciones y nivel deabstraccin que seleexija al modelo con sus correspondien-
tes ventajas einconvenientes.
Sin embargo, por el hecho deser modelos del entorno con el objetivo deverifi-
car un componente, los bancos depruebas son descripciones escritas para lasimula-
cin y ello implica que no estn ligadas aun subconjunto particular del VHDL (co-
mo ocurre con las descripciones para sntesis) y que deben ser optimizadas para que
lasimulacin sealo ms eficiente posible. Adems, normalmente no nos interesarn
los detalles internos de laarquitectura de los componentes que constituyen el entor-
no pero s que exigiremos que alas entradas del componente averificar seapliquen
los estmulos con la mayor precisin posible en cuanto alos cambios en el tiempo.
Desde el punto de vista del grado de detalle con el que se describe el entorno
del componente averificar distinguiremos dos posibles situaciones: en algunos ca-
sos conoceremos con detalle los distintos componentes que constituyen el sistema y
en otros casos dispondremos delas especificaciones del componente averificar 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 sucomportamiento alo 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 depruebas ten-
der ms bien aser 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
Laaproximacin ms segura para larealizacin debancos depruebas 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
288 VHDL. Lenguaje estndar de Diseo Electrnico
sistema como las referencias einterconexin destas. Como hemos visto anterior-
mente, cuando sedescribe laestructura sedescriben con detalle las interfaces deca-
da componente adems de su interconexin. Esto significa que una descripcin de
este estilo implicara que sedispone de abundante informacin decmo es el siste-
may 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 seescribirn deforma 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 laposibilidad deerror, yaque el mismo modelo sehabr utiliza-
do y depurado en distintos sistemas y se dificultarn los errores debidos aproble-
mas deinterpretacin deespecificaciones.
Por ejemplo, podramos decidir que en el sistema donde seubicar nuestro pro-
cesador utilizaremos una memoria y un rbitro debus comerciales delos cuales co-
nocemos su comportamiento al disponer desus hojas dedatos. En este caso los mo-
delos dela memoria y el rbitro debus serealizaran deacuerdo asu hoja dedatos
y de forma independiente al modelo del procesador. Los componentes seconecta-
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 asimular, y por otra lamayor longitud delas
simulaciones, hacen que stas sean ms lentas que si no se hubiera detallado con
tanta precisin laestructura. La mayor longitud delas simulaciones con este tipo de
modelo es debido aquepara aplicar determinados estmulos al componente averifi-
car puede ser necesario llevar el resto de componentes del sistema aun estado de-
Memoria
1 i
Controles i Datos t DireCCiones
PeticionBus
rbitro
Procesador de
BusLibre
bus
FIGURA 5-6. Descripcin estructural del sistema.
5. Modelado con VHDL 289
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 dealgn modo. En el sistema real lamemoria no estara inicializada sino
que durante unos ciclos algn componente estara escribiendo sus valores iniciales
desdeel punto devista delasimulacin del procesador. En cambio, si el modelo del
entorno no contemplara los componentes con tanta rigurosidad sera posible forzar
unestado del sistema con menor nmero deciclos.
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 averificar. El banco depruebas 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 averificar para proporcionarle unos estmulos que seaproximen al mximo a
los queleproporcionara unsistema real.
La estructura de este tipo de banco de pruebas se muestra en la Figura 5-7,
donde diferentes procesos proporcionan estmulos al componente averificar y reac-
cionan asus respuestas, adems decoordinarse entre ellos mediante seales.
En algunos casos puede ser conveniente dar formato alos estmulos en ciclos,
deforma similar acomo seintroducen en las mquinas para el test decircuitos inte-
grados. Esto es til en el caso deque los estmulos desimulacin sequieran conver-
tir avectores para lamquina detest o en el caso dequerer realizar una descripcin
Banco de pruebas
Componente
a
verificar
FIGURA 5-7. Banco de pruebas funcional.
290 VHDL. Lenguaje estndar de Diseo Electrnico
funcional que, anivel deciclos dereloj, proporcione los mismos estmulos que una
descripcin estructural pero acelerando la simulacin al disminuir el nmero de
procesos que seejecutan. En este ltimo caso serealizara una simulacin delades-
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 depruebas estructural por un banco depruebas mucho ms sencillo que le-
yera los estmulos deun fichero y los aplicara.
La aplicacin deestmulos segn ciclos detest odereloj era normal antes dela
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 aposibles 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, lamemoria dedatos 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 dedatos. 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 selimite aaplicar estmulos encada ciclo sintener en cuen-
talas 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 averificar de la misma forma como lo hara el entorno real, sino que ade-
ms sepueden realizar comprobaciones sobre dichas respuestas que nos ayuden en
laverificacin.
Podemos distinguir dos estrategias en cuanto alacomprobacin automtica de
las simulaciones: basarse en comparaciones con simulaciones previas cuyos resulta-
dos sehan verificado previamente deforma manual (Figura 5-8) obien incluir en el
banco depruebas lacapacidad 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 sepueden 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 adiferentes niveles de abstraccin. La forma derealizar este tipo
decomparaciones 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
depruebas que lea las respuestas correctas acada 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
5. Modelado con VHDL 291
Reloj -,--------,--+i
Modelo
de
referencia
OK
Aplicacin
de
estmulos
Comparacin
~----------_'I de
resultados
(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 depruebas existirn uno oms procesos que
seencargarn de analizar las respuestas de la simulacin. Estos anlisis pueden ser
dedos tipos:
Dependientes delos estmulos que aplica el propio banco depruebas. En este
caso los procesos encargados derealizar 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".
292 VHDL. Lenguaje estndar de Diseo Electrnico
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 dede-
terminados valores en las salidas del componente, que indicara claramente
que se ha llegado auna situacin no prevista, no seproduce. Muchas veces
es ms prctico incluir este tipo de verificaciones dentro del modelo del
componente averificar, ya que all sedispone de ms informacin sobre su
estado interno.
5.4.3. La mquina rudimentaria: el banco de pruebas
En este apartado vamos asimular el procesador con su arquitectura PrimeraParti-
cion utilizando laestrategia 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 deuna 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 debus y un
generador deciclos dereloj.
As, el aspecto del sistema ser el mostrado en laFigura 5-7, donde laarquitec-
tura correspondiente al sistema contiene nicamente referencias al banco de prue-
bas y al procesador. El banco depruebas tendr como entradas las salidas del proce-
sador y como salidas las entradas del procesador. As, la entidad para el banco de
pruebas serlasiguiente:
l i b r a r y I E E E ;
u s e I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
e n t l t y Ba n c o P r u e b a s l a
port (
P e t i c i o n Bu s
o u t s t d . _ l o g i c ;
o u t s t Q_ l o g i c ;
o u t s t d _ l o g i c ;
i n o u t s t Q_ l o g i c ~v e c t o r ( 1 5 d o wn t o O) ;
in s t Q_ l o g i c _ v e c t o r ( 7 d o wn t o O);
in s t d _ l o g i c ;
in s t d , _ l o g i c ;
in s t d , _ l o g i c ) ;
I n i c i a l i z a
Re l o j
Bu s L i b r e
Da t o s
Di r e c c i o n
Ha b i l i t a Me m
E s c r i b e
end Ba n c o P r u e b a s ;
LISTADO 5-18. Entidad para el banco de pruebas funcional.
En la arquitectura del banco de pruebas distinguiremos cuatro partes indepen-
dientes, cada una delas cuales serelacionar con un conjunto distinto deentradas y
5. Modelado con VHOL 293
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 alade-
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 lacual generaremos el
reloj y posteriormente asignar esta seal al puerto desalida.
El proceso que realizar el papel de la memoria de datos y programas contiene
unainicializacin delas posiciones dememoria (variable Man) donde seintroducen el
mismo programa y los mismos datos que seutilizaban en ladescripcin funcional del
procesador. Con posterioridad aesta inicializacin, el proceso entra en un bucle para
realizar las funciones habituales deuna memoria: cada vez que seactiva laseal Ha-
bili taMem, realiza un ciclo de escritura o de lectura segn indique la seal
Escribe. Enrealidad, el proceso no seactivadeacuerdo con laseal Habili taMem
sino con una seal homloga retrasada 10ns (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 lasleeesteproceso.
Finalmente, el proceso Arbi troBus reacciona alas peticiones debus por parte
del procesador activando laseal BusLibre. En el Listado 5-19 semuestra laarqui-
tectura Funcional del banco depruebas.
library IEEE;
use I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
u s e I E E E . S T D_ L OGI C_ AR! T H. a 1 l ;
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
294 VHDL. Lenguaje estndar de Diseo Electrnico
ME!ll(J .);;'e. "OOOlJ ;QOOOOQOJ Oll"; c: - L QAD(J ,O,lp
ME!ll(2)': ; IOooiii000100"; -r- - lIPD(4,3,2), .
Mem(3) : ,; OlldOO~OOOllOO"; '7- Sl'OREf4,(U,2)
Mem(() ~: '" "iooooododoOOOOo'; .; - J MP(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
begi n
BusL ibre <= ' 0 ' ; '
wait unUl PeticioriBus = ' l';
BusL ibre <= ' 1' ;
wait until PeticionBus ='O';
end proceaa;
end Funcional;
LISTADO 5-19. Arquitectura funcional del banco de pruebas.
5.5. MODELADO DETALLADO
L legados aestepunto sedispone deun modelo funcional del procesador, en el que
quedan claramente reflejadas las diferentes operaciones que deber realizar, as
como su secuenciamiento. Sin embargo, ninguno deestos modelos contiene infor-
macin acerca de cmo deben realizarse tales operaciones, de cul es el tiempo
ms o menos aproximado que requiere cada una deellas, decmo detectar posi-
bles situaciones prohibidas y otra serie decuestiones que para poder ser tratadas
requieren disponer deun mnimo deinformacin relativa ala implementacin del
procesador.
Nuestro objetivo ser, por tanto, atravs deun refinamiento progresivo delos
modelos del sistema, obtener unas descripciones quereflejen claramente todos los
detalles deimplementacin, o modelen deuna forma precisa la realidad. En el pri-
mer caso setratar delos componentes querealmente pretendemos implementar y
quedespus deesteproceso derefinamiento podrn ser utilizados como entrada a
5. Modelado con VHDL 295
una herramienta de sntesis, que automticamente generar el circuito correspon-
diente. En el segundo caso se trata de aquellos componentes que tambin forman
partedel sistema, pero que nicamente son necesarios para crear el entorno realista
enel que deber operar nuestro diseo, y que, por tanto, sern diseados de cara a
susimulacin.
5.5.1. Modelado para sntesis vs modelado
para simulacin
Hasta el momento, el objetivo que sepersegua con los diferentes modelos funcio-
nales descritos en los apartados anteriores era tratar de describir el funcionamiento
denuestro sistema electrnico con una doble finalidad:
1. Especificar y documentar las caractersticas del sistema.
2. Simular los modelos para verificar lavalidez del diseo.
Sin embargo, amedida que pasemos a: refinar estos modelos funcionales debe-
mos tener bien claro cul es el objetivo dedichos modelos:
1. Disponer deuna descripcin precisa deaquello que sepretende modelar.
2. Escribir una descripcin inteligible por las herramientas automticas de sn-
tesis, que generarn el circuito apartir dedicha descripcin.
La razn es bien sencilla. El VHDL, y en general los HDLs, fueron pensados
para facilitar latarea del diseador de sistemas electrnicos; por tanto, sepuso ms
nfasis en tratar de dotarlo de caractersticas como la flexibilidad que no en otras
quemejoraran las prestaciones delas herramientas asociadas.
Por loquerespecta alasimulacin, esto simplemente significaque, aunque seso-
portan todas las construcciones del lenguaje, algunas, o algunos estilos de modelado,
resultanbastanteineficientes desdeel punto devistadel tiempo desimulacin.
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. Laconsecuencia inmediata es que, si bien cualquier modelo para lasn-
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 seponen derelieve con mayor detalle las caractersticas referentes alaim-
296 VHDL. Lenguaje estndar de Diseo Electrnico
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 adiferentes 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 setrata, y lanica posible debido al desconocimiento delos 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 seimponen aestos parmetros (tiempos deestablecimiento, tiempos demante-
nimiento, ... ).
El lenguaje VHDL no proporciona un mecanismo estndar para la especifica-
cin delainformacin temporal delos modelos. La forma deimplementarla 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 seleofrecen diferentes alternativas.
1. Si setrabaja en un nivel deabstraccin alto, como puede ser laprimera 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 decomparacin entre diferentes aproxi-
maciones para poder evaluarlas y compararlas entre s.
loop
L e e r l n s t r u c c i o n ;
E j e c u t a r l n s t r u c c i o n ;
wait lor 100ns;
end loop;
En el ejemplo al que nos referimos seestableci un tiempo de ciclo de ins-
truccin que puede servir perfectamente para comparar dos repertorios de
instrucciones entre s, aunque este valor no secorresponda con el resultante
delaimplementacin definitiva del modelo. El modelado, en este caso, con-
siste sencillamente en asignar un valor de tiempo ala sentencia wait que si-
mula el ciclo deinstruccin.
2. Descendamos algn nivel en lajerarqua, y supongamos que disponemos de
un modelo estructural del sistema a disear. En este caso puede interesar,
por ejemplo, disponer de un modelo deretardo depin apin (pin-to-pin), en
el que slo nos interesa conocer el tiempo depropagacin 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 desalida.
5. Modelado con VHDL 297
Ejercicio 5.1
Modelar un multiplexor 2x 1que verifique las siguientes caractersticas:
E 11J - 0 . . . S
E2 1
e
FIGURA 5-10. Multiplexor 2x 1.
TABLA 5-4. Tiemposderetardo
Parmetro
.Camino
Tiempo
tpl
E l oE 2 hasta S 20 ns
tp ehasta S lOns
Solucin
E n este caso existen dos tiempos de propagacin diferentes, en funcin de si el
cambio seproduce en cualquiera delas entradas dedatos o en laentrada decontrol.
E l proceso combinacional mux comprueba en qu seal de entrada seha 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. E sta comprobacin est implcita en el cdigo, puesto que como el tiempo
dedato es el mayor delos dos, severifica enprimer lugar.
l i br a r y I E E E ;
us e I E E E . ST D_ L OGI C_ l l 64. a l l ;
e nt i t y Mul t i pl e x o r i e
port(
E l , E 2 : in s t d_ l o gi c _ v e c t o r ( l 5 do wnt o O) ;
C : in s t d_ l o gi c ;
S : o ut s t d_ l o gi c _ v e c t o r ( 15 do wnt o O) ) ;
end Mul t i pl e x o r ;
1 tp: tiempo depropagacin.
298 VHDL. Lenguaje estndar de Diseo Electrnico
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 ; instd,_logic_vector(15 downto O);
e ; instd_logicl
return std_logic_vector ls
begin
if ( e = ' 1' ) t hen
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 enel nivel ms cercano al hardware,
enel quenuestro circuito est modelado abasedelas celdas lgicas quelo
componen. Si pretendemos hacer una simulacin realista denuestro diseo
tendremos quereflejar todas lascaractersticas deestos componentes, segn
seespecifican enlashojas dedatos (datasheets) delatecnologa quecorres-
ponda. Para cada celda existir no slo un tiempo depropagacin determi-
nado desde las entradas hasta las salidas, sino que adems ste variar en
funcin del nmero deceldas alasquestaest conectada lfanout). Incluso
el retardo ser diferente enfuncin del tipo detransicin (0/1, 1/0,01Z, ... ).
Puesto queel modelo temporal decadaceldadepender desuposicin enel
circuito, nopodremos fijar sus caractersticas temporales enel cdigo, sino
quesepasarn mediante parmetros.
Ejercicio 5.2
Escribir el modelo correspondiente al circuito delaFigura 5-11, reflejando lainfor-
macin temporal incluida enlaTabla5-5.
5. Modelado con VHDL 299
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
tplh2
1,6ns 2,1 ns 2,5 ns
tphl 1,7ns 2,0ns 2,3ns
dtplh3 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 dela puerta and, que posterior-
mente utilizaremos para modelar el resto del circuito. La entidad, adems de los
puertos correspondientes alas entradas y salidas de la puerta, incluir dos parme-
tros genricos: los tiempos depropagacin tplh y tphl, correspondientes alas transi-
ciones 0-1 y 1-0en la salida delapuerta. La arquitectura consistir simplemente en
lasiguiente asignacin concurrente condicionaL
y <= ' 1' a f t e r t pl h whe n ( A = ' 1' a nd B = ' 1' ) e 1s e
'o' a f t e r t phl whe n ( A = ' O' o r B = ' O' ) e 1s e
'X' ;
El modelo del circuito consistir, por tanto, en una copia por referencia delas 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 unretardo adicional, en funcin
del nmero deentradas extra alas que lapuerta est conectada.
2 tplhltphl: tiempo depropagacin deOa l/de 1aO,
3 dtplhldtphl: variacin del tiempo depropagacin (Oa 1/1aO)respecto al fanout de lacelda.
300 VHDL. Lenguaje estndar de Diseo Electrnico
Para tener en cuenta los diferentes casos de simulacin: tpico, mnimo y mxi-
mo, las constantes detiempo son vectores detres tiempos, uno para cada caso desi-
mulacin. Segn seaeste caso de simulacin, que sepasa como parmetro alaenti-
dad ejemplo, seelegir el tiempo correspondiente en el vector.
entity Ejemplo is
generie(
Caso
port(
A, B, C, D, E , F
Y1
Y2
Y3
end Ejemplo;
tCaso :=tipico);
in std._logic;
oot std_logic;
oot std._logic;
oot std._logic);
arehiteeture Estructural of Ejemplo is
type tTiempo i8 array (tCaso ranga mnimo to maxitno) of time;
eonstant AND2tpl~ :tTiempo
.-
eonstant AND2tphl . . tTiempo : : : :
eonstant AND2dtplh : tTiempo : : :
eonstant AND2dtphl tTiempo
. -
( 1. 8 ns, 2.1.ns, 2.5 ns);
(1.. 7 os, 2.0 ns, 2.3 ns);
(0.3 ns, 0.5 os, 0. 8 ns);
(0;25'ns, 0.4 ns, 0.1 ns);
canponent and2
generie (
tplh
tphl
port (
time;
time) ;
A, B : in std._logic;
y : out std._logic);
end eCJ lll)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);
5. Modelado con VHDL 301
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 gradode 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 (noes lomismo operar con
enteros que con nmeros reales), menor ser el rendimiento del simulador, que ne-
cesitar ms tiempoy mayor cantidad dememoria para completar lasimulacin.
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 sepueden producir, noslode codificacin, sino
tambin en la concepcin del modelo. Por ejemplo, puede resultar que en un siste-
macon un DMA segenere una direccin dememoria inexistente. Opodemos haber
olvidado desactivar el accesode un componente aun bus y tener en ste como re-
sultadoun valor indeterminado. Para facilitar esta tarea, el diseador puede incluir
explcitamente en los modelos una serie de condiciones, que en casode noverifi-
carse generarn mensajes deerror durante lasimulacin.
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
ROM
8 Dato
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 casodeque la direccin nosea correcta en el momento de
recibir laseal dehabilitacin segenerar un mensaje deerror explicativo.
302 VHDL. Lenguaje estndar de Diseo Electrnico
l i br a r y I E E E ;
us e I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
use I E E E . S T D_ L OGI C. . } I RI T H. a l l ;
e nt i t y e j e mpl o 3 i s
po r t (
Ha bi l i t a
Di r e c c i o n
Da t o
end E j e mpl o 3;
in s t d. . _ 1 o gi c ;
in s t dJ o gi c _ v e c t o r ( 7 do wnt o O);
o ut s t d_ l o gi c _ v e c t o r (7 do wnt o al);
a r c hi t e c t ur e Al go r i t mi c a of E j e mpl o 3 i s
t y pe t ROM i s array (O to 255) of s t d_ l o gi c _ v e c t o r ( 7 do wnt o O);
be gi n
ROM: pr o c e s s
v a r i a bl e Me mo r i a : t ROM :=
( ( " 0 0 0 0 0 0 0 0 " ) , ( ' 0 0 0 0 0 0 0 1 " ) , o t he r s =>" 1 1 1 1 1 1 1 1 " ) ;
f unc t i o n Va l i do ( Ve c t o r : ins t d_ l o gi c _ v e c t o r ) r e t ur n bo o l e a n i s
be gi n
f o r i inO to Ve c t o r ' l e ngt h- 1 l o o p
i f ( Ve c t o r ( i ) /= ' 0 ' and Ve c t o r ( i ) /=' 1 ' ) t he n
r e t ur n FALSE;
end i f ;
end l o o p;
r e t ur n TRlJ E;
end Va l i do ;
be gi n
i f ( Ha bi l . i , t a= ' 1 ' ) then
i f Va l i do ( Di r e c c i o n) then
Da t o <=Me mo r i a ( c o nv _ i nt e ge r ( uns i gne d( Di r e c c i o n) ) ) ;
e l s e
a s s e r t FALSE
r e po r t ' Di r e c c i o n no v a l i da
s e v e r i t y e r r o r ;
e ndi f ;
e nd i f ;
wa i t o n Ha bi l i t a , Di r e c c i o n;
end pr o c e s s ;
end Al go r i t mi c a ;
LISTADO 5-22. Modelado de una memoria ROM.
5. Modelado con VHDL 303
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 derango, valores indeterminados, ... ), o por no
respetarse los requisitos temporales. En el primer caso es difcil poder dar alguna re-
comendacin al diseador que no seaotraque identifique los posibles puntos decon-
flicto y coloque los controles adecuados. En el segundo caso, sinembargo, el tipo de
comprobaciones a realizar est mucho ms acotado, puesto que siempre se trata
deverificar laestabilidad delas seales, suduracin y sudependencia temporal.
En el caso delas verificaciones temporales podemos establecer lasiguiente cla-
sificacin:
Verificacin de tiempos deestablecimiento (setup): tiempo que debe haberse
mantenido estable una seal antes de que ocurra un evento en la seal dere-
ferencia.
Verificacin de tiempos de mantenimiento ihold): tiempo que debe mante-
nerse estable una seal despus deque ocurra un evento en la dereferencia.
Verificacin deladuracin deniveles estables.
Verificacin del periodo deuna 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 unrecorrido muy general sobre las diferentes maneras demodelar los com-
ponentes ms habitualmente utilizados alahora dedisear hardware.
Seal 1
T,: Tiempo de establecimiento de seal 1 respecto a seal 2
T2: TIempo de mantenimiento de seal 1 respecto a seal 2
T
3
: Duracin mnima del nivel '1'
T
4
: Duracin mnima del nivel 'O'
T
s
: TIempo mnimo de ciclo
FIGURA 513. Verificacin temporal.
304 VHDL. Lenguaje estndar de Diseo Electrnico
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 declculo
(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 seconver-
tir en la Unidad de Control (UControl) de la Mquina Rudimentaria, mientras
que el proceso UProceso pasar aser la Unidad de Proceso (UPoceso). Adems,
el sistema deber disponer deuna memoria RAM, en la que sealmacenarn los da-
tos y programas, y que hasta ahora semodelaba como parte del banco depruebas, y
deun rbitro debus, 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
LaUnidad deProceso contiene los recursos declculo del procesador, y ser laen-
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 deregistros 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
CargaA
CargaN
CargaC
IncCP
FuenteDireccin
HabilitaDireccin
..
d
e
o
n
SelCampo
RI'3-11 (Rf_Rd)
C
Salto Evaluacin
de la
Condicin
o
FIGURA 5-14. Unidad de Proceso de la Mquina Rudimentaria.
5. Modelado con VHDL 305
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 Bhacia 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 tivo).
306 VHDL. Lenguaje estndar de Diseo Electrnico
library IEEE;
us e I EEE. ST D~L OGI C_ 1164. a l l ;
us e wo r k . P a que t e MR. a l l ;
e nt i t y UAL l s
port(
A
B
Ope r a
Ope r a c i o n
Re s ul t a do
Ne ga t i v o
Ce r o
end UAL ;
in s t Q_ l o gi c _ v e c t o r ( c Bi t s Da t o - l do wnt o O);
in s t d_ l o gi c _ v e c t o r ( c Bi t s Da t o - l do wnt o O);
in s t d_ l o gi c ;
in s t Q_ l o gi c _ v e c t o r ( l do wnt o O);
o ut s t Q_ l o gi c _ v e c t o r ( c Bi t s Da t o - l do wnt o O) ;
o ut s t Q_ l o gi c ;
o ut s t d_ l o gi c ) ;
LISTADO 5-23. Entidad de la Unidad Aritmtico-lgica.
En primer lugar vamos adesarrollar el modelo funcional de launidad, por las
siguientes dos razones:
1. Porque proporciona unamanera rpida de describir launidad paraverificar
sucorrecta funcionalidad eintegrarla en el restodel sistema.
2. Porque desde el punto de vistadelasimulacin del sistema ser un modelo
mucho ms eficiente queunodetallado.
El modelo funcional de laVAL prcticamente consiste en unainstruccin case
que, en funcin de lacodificacin del vector Operacion, almacena el resultado de
laoperacin en unavariable. A continuacin seasigna lavariable al puerto de sali-
day seactualizan convenientemente los indicadores Cero y Negativo.
Se haintroducido 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;
us e I EEE. ST D_ L OGI C_ 1164. a l l ;
us e I EEE. ST D_ uo GI C_ ARI T H. a l l ;
us e wo r k . P a que t e MR. a l l ;
a r c hi t e c t ur e F unc i o na l of UAL i s
be gi n
pr o c e s s ( A, B, Ope r a , Ope r a c i o n)
v a r i a bl e Re s ul t a do T e mp s t d_ l o gi c _ v e c t o r ( c Bi t s Da t o - l do wnt o O) ;
v a r i a bl e Re t a r do : t i me ;
5. Modelado con VHDL 307
b e g i n
- - E f e c t a u n a o p e r a c i n a r i t m t i c a
i f ( Op e r a = ' 1' ) then
c a s e Op e r a c i o n i s
when " 00" => -- s u ma
Re s u l t a d o T e mp := A + B;
Re t a r d o := T p o S Uma ;
wben ' 01" => -- r e s t a
Re s u l t a d o T e mp :=A - B;
Re t a r d o := T p o Re s t a ;
when -io- => -- d e s p l a z a mi e n t o
Re s u l t a d o T e mp : , ; , B( c Bi t s Da t o - l & B( c Bi t s Da t o - 1 d o wn t o 1) ;
Re t a r d o := T p o De s p l ;
when " 11" => -- y l g i c a
Re s u l t a d o T e mp := A and B;
Re t a r d o := T p o Y L o g i c a ;
when o t h e r s => -- e r r o r
Re s u l t a d o T e r n p := ( o t h e r s => , ' X ' ) ;
Re t a r d o := ti r i s ;
a s s e r t F AL S E
r e p o r t Co d i g o d e o p e r a c i o n d e l a U A L i n v a l i d o
s e v e r i t y e r r o r ;
e n d c a s e ;
e l s e ' . , . .
- - S i n o h a y o p e r a c i n e l . r e s u ; J . t a d o e s B
Re s u l t a d o T e mp := B;
Re t a r d o := T p o P a s o ;
end i f ;
- - As i g n a c i n d e l r e s u l t a d o
Re s u l t a d o ' <= Re s u ! t a d o T e mp a f t e r Re t a r d o ;
- - C l c u l o d e l o s i n d i c a d o r e s
Ne g a t i v o <= Re s u l t a d o T e mp ( c Bi t s Da t o - 1) a f t e r Re t a r d o ;
i f Re s u l t a d o T e mp = "O' then
Ce r o <= ' 1' a f t e r Re t a r d o ;
e l s e
Ce r o <= 'o' a f t e r Re t a r d o ;
end i f ;
end p r o c e s s ;
end F u n c i o n a l ;
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. L a ma-
yor parte deestas herramientas son capaces dereconocer las diferentes operaciones
complejas, tales como sumas, multiplicaciones, etc., demanera que apartir deellas
308 VHDL. Lenguaje estndar de Diseo Electrnico
se infieren los diferentes recursos de clculo: sumadores, restadores, multiplicado-
res, etc. Adems muchas son tambin capaces derealizar una sntesis arquitectural,
que permite realizar una planificacin de la utilizacin derecursos compartidos en
el caso deque laoperacin serealice ms deuna 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 apartir de la sntesis depender
no slo de las restricciones que se impongan a la herramienta, sino tambin de la
tecnologa elegida para laimplementacin 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
delos requerimientos derea y velocidad que sele especifiquen alaherramienta de
sntesis.
Aunque no seranecesario continuar el refinamiento del modelo delaUAL, pues-
to que yaes 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 deestecaptulo, realizaremos manual-
menteloqueestas herramientas yasoncapaces deresolver deforma automtica.
Puesto que existen cuatro operaciones diferentes arealizar, 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 deuna seal decontrol.
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.
5. Modelado con VHDL 309
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 delos retardos de las diferentes operaciones, puesto que sehar en cada uno
delos diferentes mdulos.
Veamos a continuacin cmo el cdigo VHDL correspondiente al modelo es-
tructural refleja fielmente laparticin delafigura anterior.
l i b r a r y I E E E ;
use I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
u s e wo r k . P a q u e t e MR. a l l ;
a r c h i t e c t u r e E s t r u c t u r a l o f UAL i s
c o n s t a n t Un Ce r o s t d L J o g i c := ' O' ;
s i g n a l S u ma
s i g n a l Re s t a
s i g n a l De s p l a z a mi e n t o
s i g n a l Y L o g i c a
s i g n a l Re s u l t a d o T e mp
s i g n a l S e l Mu x
s t q _ l o g i c _ v e c t o r ( c Bi t s Da t o - l d o wn t o O) ;
s t d _ 1 o g i c _ v e c t o r ( c Bi t s Da t o - l d o wn t o O) ;
s t q _ l o g i c _ v e c t o r ( c Bi t s Da t o - l d o wn t o O) ;
s t q _ l o g i c _ v e c t o r ( c Bi t S Da t o - l d o wn t o 0)1
s t q _ l o g i c _ v e c t o r ( c Bi t s Da t o - l d o wn t o O) ;
s t q _ l o g i c _ v e c t o r ( 2 d o wn t o O) ;
c a mp o n e n t S u ma d o r
g e n e r i c (
Nu mBi t s : n a t u r a l ) ;
port( A, B in s t q _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O);
Ac a r r e o : o u t s t q _ l o g i c ;
Re s u l t a d o : o u t s t q _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) i ;
e n d c a mp o n e n t ;
c a mp o n e n t Re s t a d o r
g e n e r i c (
Nu mBi t s : n a t u r a l ) ;
port ( A, B in s t q _ l g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ;
Ac a r r e o o u t s t q _ l o g i c ;
Re s u l t a d o o u t s t d _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ) ;
e n d c a mp o n e n t ;
c a mp o n e n t De s p l a z a d o r
g e n e r i c (
Nu mBi t s : n a t u r a l ) ;
port ( A . . . in s t q _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ;
Re s u l t a d o : o u t s t q _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ) ;
e n d c a mp o n e n t ;
c a mp o n e n t Op e r a d o r Y
g e n e r i c t
Nu mBi t s : n a t u r a l ) ;
310 VHDL. Lenguaje estndar de Diseo Electrnico
p o r t ( A, B .
Re s u l t a d o
e n d COI I ) OI l E I I l t ;
in s t q _ l o g i c ~v e c t o r ( Nu mBi t s - l d o wn t o O) ;
o u t s t d _ l o g i c ~v e c t o ( ( Nu m6 i t s - l d o wn t o O) ) ;
,'J-~ j,.
c Ql ' I i ) On e n t Mu l t i p l e x a r a
g e n e r i e (
Nu mBi t s : n a t u r a l ) :
port (
A, B, C, D, E , F , G, H
Co n t r o l
y
end c CI I q ) Ol l e n t ;
in s t q _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o Oh
in s t q _ l o g i c _ v e c t o r ( 2 d o wn t o O) ;
o u t s t . _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O));:
b e g i n
- - Op e r a c i o n e s
S u ma r : S u ma d o r
g e n e r i c map ( c Bi t s Da t o )
p o r t ma p ( A, B, apen, S u ma ) ;
Re s t a r : Re s t a d o r
g e n e r i c map ( c Bi t s Da t o )
p o r t ma p ( A, B, apen, Re s t a ) ;
De s p l a z a r : De s p l a z a d o r
g e n e r i c ma p ( c Bi t s Da t o )
p o r t ma p ( B, De s p l a z a mi e n t o ) ;
Op e r a r Y : Op e r a d o r Y
g e n e r i c me p ( CBi t s r i t o )
p o r t ma p ( A, B, ' f L ? 9 ~c a ) ;
- - Mu l t i p l e x o r
S e l Mu x <= Op e r a &Op e r a c i o n ;
Mu x 8 : Mu l t i p l e x o r 8
g a n e r i e ma p ( c Bi t s Da t o )
p o r t ma p ( B, B, E, B, Suma, Re s t a , De s p l a z a mi e n t o , Y L o g i c a ,
SelMux~:;ResultadoTeIlI ; .' i;
- - I n d i c a d o r e s
Ne g a t i v o <= Re s u l t a d o T e mp ( c S i t s Da t o - 1 ) ;
Ce r o <= ' 1 ' wben Re s u l t a d o T e mp = 0 " e l s e
' O ' ;
- - As i g n a c i n . a l port d e s a l i d a
Re s u l t a d o <= Re s u l t a d o T e mp ;
end E s t r u c t u r a l ;
LISTADO 5-25. Modelo estructural de la Unidad Aritmtico-lgica.
5. Modelado con VHDL 311
Llegados aestepunto, el siguiente paso en el proceso derefinamiento consistir
endefinir las arquitecturas delos componentes. Trataremos nicamente ladel 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 dedatos reales.
5.5.4.1.1.1. El sumador con acarreo de propagacin (ripp/e-carry)
El sumador ripple-carry (Figura 5-17) secompone deuna serie desumadores com-
pletos (jull-adders), cada uno delos cuales realiza una suma dedos bits ms un aca-
rreo deentrada, generando unbit deresultado y un acarreo desalida. Estos mdulos
seencadenan en serie entre s, de manera que el acarreo de salida de uno sirva co-
mo acarreo deentrada del siguiente.
se
AcarreoS AcarreoE
Resultado
AcarreoS AcarreoE
se
'O'
Resultado
Acarreo Hesultado. Resultado
FIGURA 5-17. Sumador con acarreo en serie.
El siguiente listado muestra el cdigo VHDL correspondiente ala funcin del
sumador completo, descrito mediante unflujo dedatos.
l i br a x y I EEE;
us e I EEE. ST D_ L OGI C_ 1164. a l l ;
us e wo r k . P a que t e MR. a l l ;
312 VHDL. Lenguaje estndar de Diseo Electrnico
e n t i t y S u ma d o r Ca mp l e t o 1 a
port( A, B in s t d _ l o g i c ;
Ac a r r e o E in s t d , _ l o g i c ;
Re s u l t a d o o u t s t d . . . . l o g i c
Ac a r r e o S o u t s t d _ l o g i c l ;
end S u ma d o r Co mp l e t o ;
a r c h i t e c t u r e F l u j o De Da t o s o f S u ma d o r Co mp l e t o 1 a
s i g n a l T e r n p : s t d _ l o g i c ;
be g i n
T e r n p <= A xor B a f t e r T p o Xo r ;
Re s u l t a d o <= T e r n p xor Ac a r r e o E a f t e r T p QXo r ;
Ac a r r e o S <= ( A and B) or ( T e r n p and Ac a r r e o E ) a f t e r T p o AO
end F l u j o De Da t o s ;
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 sonpoco costosos entrminos de rea ocupada. Por con-
tra, suelenserexcesivamente lentos, puestoque, comosepuede apreciar enlaFigu-
ra 5-17, el clculo de cada etapa nopuede realizarse hasta que haya finalizado la
anterior, debidoal conexionado enserie delos bloques.
Puestoque setrata demodelar una estructura regular, utilizaremos eneste caso
lainstruccin genera te, tal y comomuestra el siguiente listado.
l i br a r y IEEE;
u s e I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
a r c h 1 t e c t u r e Ri p p l e o f S u ma d o r 1 8
c a mp o n e n t S u r n a d o r Co mp l e t o
port(
A, B
Ac a r r e o E
Re s u l t a d o
Ac a r r e o S
end CCJ DpOOeOt;
in s t d , _ l o g i c ;
in s t d , _ l o g i c ;
o u t s t d _ l o g i c ;
o u t s t d , _ l o g i c ) ;
s i g n a l Ac a r r e o T e r n p : s t d _ l o g i c _ v e c t o r ( Nu mbi t s d o wn t o O) ;
be g 1 n
Ac a r r e o T e mp ( O) <= ' O' ;
Ac a r r e o <= Ac a r r e o T e r n p ( Nu mBi t s ) ;
5. Modelado con VHDL 313
Suma do r : f o r i inO toNumBi t s - l ge ne r a t e
Ce l da _ Suma do r : Suma do r Co mpl e t o
port map(
A => A( i ) ,
B => B(i),
AcarreoE => AcarreoTerrp(il,
Re s ul t a do => Re s ul t a do ( i ) ,
Ac a r r e o S => Ac a r r e o T e mp{i +l ;
e nd ge ne r a t e Suma do r ;
end Ri ppl e ;
LISTADO 5-27. Modelo estructural del sumador conacarreo serie.
Paraestudiar el comportanento temporal del sumador revisemos el Listado5-26.
Comopuede apreciarse serealizan dos tipos deoperaciones diferentes, equivalentes
alas puertas lgicas xor y AndOr. A cada una de estas operaciones, por tanto, sele
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,
puestoque los tiempos deretardo 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 vadesde el acarreo deentrada hasta el de salida, pasando por los
16sumadores completos. El tiempo total, tantopara el clculo del Resultado como
del Acarreo, puede expresarse delasiguiente 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 delaetapa anterior, el retardo total corresponde alasuma delos retardos dela
funcin AndOr, ms el tiempo de retardo de la operacin A xor B, que debe reali-
zarseenprimer lugar.
En el segundo caso, el tiempototal es lasuma deesta primera operacin, ms el
retardo de las 15etapas de clculo de acarreo, junto con el tiempo de la operacin
xor, quecalcula el resultado delaltima etapa apartir del acarreodelaanterior.
5_5.4.1.1.2. El sumador con acarreo anticipado (carrylook-aheadJ
Comohemos visto, el sumador con acarreo depropagacin puede resultar demasia-
dolento, debido aque para calcular el resultado decada bit debe esperarse lapropa-
gacin del bit deacarreo atravs detodas las etapas anteriores.
314 VHDL. Lenguaje estndar de Diseo Electrnico
Una solucin alternativa es la que presenta el sumador con acarreo anticipado.
En este caso setrata 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 arealizar sus clculos antes deque 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 acada bit deacarreo deunbloque.
La Tabla 5-6 refleja las diferentes posibilidades de propagacin de acarreo en
laoperacin desuma dedos 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 latabla anterior, si A = B = O no segenerar 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 deque
el de entrada tome el valor '1'. Dicho de otra manera, en este caso se propaga el
acarreo deentrada directamente alasalida (etapa depropagacin).
Segn laexplicacin, las ecuaciones booleanas correspondientes alas 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 lamisma tabla, tambin puede concluirse que seobtiene un acarreo de sali-
da siempre que setrate deuna etapa de generacin, o una depropagacin en laque
haya un acarreo deentrada. En forma deecuacin:
Finalmente, podramos expresar la suma en funcin de las ecuaciones ante-
riores:
5. Modelado con VHOL 315
Si en la expresin que calcula el acarreo de salida en funcin del de entrada
sustituimos este ltimo por suecuacin 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 deproductos (oproducto desumas), cuya implementacin
serealiza con dos niveles depuertas.
En nuestro caso, puesto que setrata deun sumador de 16bits, no podemos pre-
tender calcular el acarreo anticipado para todos ellos, puesto que sera necesario un
grannmero depuertas, algunas delas cuales tendran ms decuatro 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 declculo 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 apartir de lapropaga-
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., A
7
_
4
8
7
-4 Resultado
3
-Q A3-Q83-Q
~
FIGURA 5-18. Sumador con acarreo anticipado.
316 VHDL. Lenguaje estndar de Diseo Electrnico
do, calculado apartir de laecuacin (*). 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 (4bloques*4 bits = 16bits), ms un ltimo CIA,
responsable de calcular por anticipado el acarreo que toma como entrada cada blo-
quedel 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 lapro-
pagacin y generacin de acarreo, y el clculo de la suma, se efecta mediante la
operacin lgica correspondiente. El cdigo obtenido es absolutamente equivalente.
l i br a r y I E E E ;
use I E E E . ST D_ L OGI C_ 1164. a l l ;
entity CLAis
generic(
NumBits : integer :=4) ;
port(
G in std_logic_vector(NumBits-l downto O);
in stq_logic_vector(NumBits-l downto O);
in std~logic;
out std._lcijic;
out std_ioglc,;"vector(NumBits-l downto O)';
P
AcarreoE
G G
AcarreoS
end CLA;
architecture Funcional of CLA is
begin
CLA: process(G , P)
variable PTenp, G Tenp
variable AcarreoTenp
begin
PTenp :=P(O);
G Temp:=G "{O);
AcarreoTemp :=AcarreoE;
AcarreoS (O) <=AcarreoE;
for i in 1 to NumBits-l loop
PTenp :=PTenp aDd P(i);
G TeI1il :=G (i) or (G TeI1ilaDd P(i;
AcarreoTenp := G (i -1) or (AcarreoTemp and P(i -l ;
AcarreoS (i) <:; ,AcarreoTerrq:;
end loop;
G C <=G Tenp;
G P <=PTenp;
end process CI A;
std_logic;
std_logic;
end Funcional;
~ISTADO 5-28. El bloque CLA.
5. Modelado con VHDL 317
l i b r a r y I E E E ; . ,
u s e I E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
a r e h i t e c t u r e CL A o f S u ma d o r i s
e Ol l i >On e n t CI A
g e n e r l c (
Nu mBi t s : l n t e g e r :=4);
port(
G
P
Ac a r r e o E
GG
GP
Ac a r r e o S
e n d cClllPOnent;
s i g n a l G, P
s i g n a l GG
s i g n a l GP
s i g n a l GC
s i g n a l Ac a r r e o G
s i g n a l Ce r o
b e g i n
- - C l c u l o d e l a s e t a p a s d e g e n e r a c i n y p r o p a g a c i n
G <=A and B;
out
out
in s t CL l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O);
in s t Cl . l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ;
in s t CL l o g i c ; . , ,
s t CL l o g i c ;
s t CL l o g i c ;
s t d . . _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O) ) ; out
, . s t <l _ l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O);
s t d _ l o g i c _ v e c t o r ( Nu mBi t s / 4 - 1 d o wn t o O);
s f d _ l o g i c _ v e c t o r ( Nu mBi t s / 4 - 1 d o wn t o O) ;
s t CL l o g i c _ v e c t o r ' ( Nu mBi t s / 4 - 1 d o wn t o O);
s t Cl . l o g i c _ v e c t o r ( Nu mBi t s - l d o wn t o O);
s t d _ l o g i c :=' O' ;
P <=:xor B;
- - C l c u l o d e l a s u ma f i n a l
Re s u l t a d o <=P :xor Ac a r r e o G( Nu mBi t s - l d o wn t o O) ;
- - c l c u l o d e l a c a r r e o a n t i c i p a d o
CL ANi v e l l : f o r i in O t o ( Nu mBi t s / 4 - 1 ) g e n e r a t e
Ce l d a CI A: CI A
g e n e r i e ma p ( Nu mBi t s => 4 )
port map(
G => G ( i * 4 t o i * 4 + ) ) ,
P => P ( i * 4 t o i * 4 +3 ) ,
Ac a r r e o E = > OC(i),
GG => OO(i),
GP => GP ( i ) ,
Ac a r r e o S => Ac a r r e o G( i * 4 t o i * 4 + 3 ) ) ;
end g e n e r a t e CL ANi v e l l ;
CI ANi v e 1 2 : CI A
g e n e r i e ma p ( Nu mBi t s => 4 )
port map(
G => GG.
P => GP,
Ac a r r e o E => Ce r o ,
GG => apeo,
GP => apeo,
Ac a r r e o S => GC);
end CI A;
LISTADO 5-29. Modelo estructural del sumador con acarreo anticipado.
318 VHDL. Lenguaje estndar de Diseo Electrnico
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 laetapa declculo delageneracin y propagacin (tiem-
poixorj). Puesto que, como seha mencionado, la funcin implementada por el blo-
que CIA tendr dos niveles de puertas, consideraremos suretardo similar al deuna
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 delasiguiente 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 debloques para proporcionar al segundo sus entra-
das (1), a su vez ste proporciona los acarreos de entrada alos 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 deuna 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 depuertas necesario para laimplementacin deeste lti-
mo es mucho menor que para el primero.
5.5.4. 1.2. El banco de registros
El banco deregistros contiene los ocho registros depropsito general en los que se
almacenan los datos que seenvan y reciben delamemoria, as como los que inter-
vienen en las operaciones ejecutadas por laUAL.
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 deregistros 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 delaunidad operativa, los cambios en los
registros serealizan en el flanco desubida del Reloj.
Las seales SelRegLectura y SelRegEscri tura seleccionan el registro en
el que seescribir 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:
5. Modelado con VHOL 319
librazy IEEE;
u s e I E E E . S T D~L OGI C_ 1 1 6 4 . a l l ;
u s e wo r k . P a q u e t e MR. a 1 1 ;
e n t i t y Ba n c o Re g i s t r o s i s
port(
Re l o j
I n i c i a l i z a
Da t o E s c r i t u r a
E s c r i b e Re g i s t r o
S e l Re g L e c t u r a
S e l Re g E s c r i t u r a
Da t o L e c t u r a
);
end Ba n c o Re g i s t r o s ;
in s t d _ l o g i c ;
in s t d _ l o g i c ;
in s t d _ l o g i c _ v e c t o r ( c Bi t s Da t o - 1 d o wn t o O) ;
in s t d _ l o g i c ;
in s t d _ l o g i c _ v e c t o r ( 2 d o wo t o O) ;
in s t d _ l o g i c _ v e c t o r ( 2 d o wn t o O) ;
o u t s t d _ l o g i c ' : ' _ v e c t o r ( c Bi t s Da t o - l d o wn t o O)
LISTADO 5-30. Entidad del bancode 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 lasiguiente estructura:
p r o c e s s ( Re l o j , I n i c i a l i z a )
b e g i n
i f I n i c i a l i z a = ' 1 ' then
- - n i c f a l i z a l a l g i c a s e c u e n c i a l
e l s i f R l o j ' v e n t and Re l o j = ' 1 ' t h e n
- - c l c u l o d e l v a l o r a s i g n a r
end if;
e n d p r o c e s s ;
LISTADO 5-31. Un proceso secuencial.
En este caso la respuesta del modelo ala 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 laarquitectura funcional de nuestro
banco de registros.
librazy IEEE;
u s e I E E E . S T D_ L OGI C_ 1 1 6 4 . a 1 1 ;
u s e I E E E . S T D_ L OGI C_ ARI T H . a H ;
u s e wo r k . P a q u e t e MR. a 1 1 ;
320 VHDL. Lenguaje estndar de Diseo Electrnico
a r c h i t e c t u r e F u n c i o n a l of Ba n c o Re g i s t r o s i s
b e g i n
Ba n c o : p r o c e s s ( Re l o j , I n i c i a l i z a , S e l Re g L e c t u r a )
v a r i a b l e Re g i s t r o s : t Re g i s t r o s ( O to c Nu mRe g s - l l i
b e g i n
i f I n i c i a l i z a = ' 1 ' then
f o r i in O to c Nu r n Re g s - l l o o p
Re g i s t r o s ( i ) := ( o t h e r s => ' 0' ) ;
end l o o p ;
e l s i f E s c r i b e Re g i s t r o = '1' then
i f Re l o j ' e v e n t aDd Re l o j = '1' then
Re g i s t r o s ( c o n v _ i n t e g e r ( u n s i g n e d ( S e l Re g E s c r i t u r a ) ) l : = Da t o E s c r i t u r a ;
end i f ;
e n d i f ;
Da t o L e c t u r a <= Re g i s t r o s ( c o n v _ i n t e g e r l u n s i g n e d l S e l Re g L e c t u r a ) l )
a f t e r T p o Re g i s t r o ;
e n d p r o c e s s Ba n c o ;
end F u n c i o n a l ;
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 enunbucle que asignar el valor Oatodos
los registros. Puesto que se trata de un banco de registros, noes necesario realizar
ningn clculo sobre el valor a almacenar, que directamente ser DatoEscritura.
Sin embargo, obsrvese que antes deverificar si sehaproducido un eventodereloj,
para almacenar el valor en el registro correspondiente, secomprueba el estadode la
seal EscribeRegistro. La razn es que esta seal es ms prioritaria que el reloj,
puestoque nohay asignacin si noest activada.
En nuestro modelo aparece adems una asignacin concurrente, que simple-
mente se encarga de asignar como datode 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 aesta unidad. Como puede
apreciarse claramente en laFigura 5.14, la Unidad de Proceso secomunica, por un
lado, con laUnidad de Control, de laque recibe las diferentes seales decontrol 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:
5. Modelado con VHDL 321
las que controlan lacarga delos registros
ladecontrol deacceso al banco deregistros
laseal deoperacin delaUAL
las seales decontrol delacarga delos registros especficos
las seales decontrol deacceso al bus del sistema.
Como informacin deestado, laUnidad deProceso indica alaUnidad deCon-
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 sunuevo 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.
l i b r a r y I E E E ;
us e l E E E . S T D_ L OGI C_ 1 1 6 4 . a l l ;
entity UProceso 18
port (
Reloj
Inicializa
: instd._logic;
: instd_logic;
-- Control de carga de los registros especficos
CargaRrM in std_logic;
CargaCP in std._logic;
CargaR! instd_logic;
CargaA instd_logic;
IncCP in std_logic;
CargaN in std-"logic;
CargaC instd_logic;
-- Control de la UAL
Opera : instd_logic;
-- Control del banco de registros
SelC~ in std._logic_vector(l downto O);
EscribeRegistro : instd_logic;
-- Control de acceso al b us
FuenteDireccion in std_logic;
HabilitaDireccion instd._logic;
HabilitaDatos instd_logic;
-- Indicadores
Co d i g o Op
Salto e
out std_logc:,:"vctor(l downto O);
out std_logic;
322 VHDL. Lenguaje estndar de Diseo Electrnico
- - Me mo r i a
Di r e c c i o n
Da t o s
end UP r o c e s o ;
o u t s t d . . . l o g i c , _ v e c t o r ( <; Bi t , S Di r e c q i o n- 1 d o wn t o O) ;
i n o u t s t d . . . l o g i c _ v e c t o r l c Bi t s Di r e c c i 0
I 1
- 1 d o wn t o O));
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 sedispondr deun conjunto deregistros 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:
a r c h i t e c t u r e F l u j o De Da t o s of UP r o c e s o i s
- - De c l a r a c i n d e c o mp o n e n t e s
CCJ ll)O!leIlt UAL
e n d c o mp o n e n t ;
c o mp o n e n t Ba n c o Re g i s t r o s
e n d c o mp o n e n t ;
- - Re g i s t r o s e s p e c f i c o s
s i g n a l A s t d . . . l o g i c _ v e c t o r l c Bi t s Da t o - 1 d o wn t o O) ;
- - Re g i s t r o Ac u mu l a d o r
- - S e a l e s t e mp o r a l e s
s i g n a l B : s t d . . . l o g i c _ v e c t o r l c Bi t s Da t o - 1 d o wn t o O) ;
- - Ca mp o s d e l Re g i s t r o de I n s t r u c c i n I RI ) ( a l i a s )
b e g i n
Co p i a p o r r e f e r e n c i a de l o s c o mp o n e n t e s UAL y Ba n c o Re g i s t r o s
- - Mo d e l a d o de l o s r e g i s t r o s e s p e c f i c o s
- - L g i c a a d i c i o n a l
end F l u j o De Da t o s ;
LISTADO 5-34. Descripcin en flujo de datos de la Unidad de Proceso.
5. Modelado con VHDL 323
La asignacin de los alias a los campos del registro de instruccin puede
resumirse en lasiguiente 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 alos registros especficos es prcticamente idntico
paratodos ellos. Todos los registros disponen deuna seal deinicializacin asncro-
na (Inicializa) y una seal de habilitacin sncrona (Cargaxx). Las nicas par-
ticularidades son las que presentan los registros deDireccin deMemoria (RfM) y el
contador de programas (cP). El primero almacena el resultado de una suma, mien-
tras que el segundo dispone deotra seal decontrol, adems deladecarga, tambin
sncrona, que cuando seactiva incrementa el valor almacenado en el registro.
- - Re g i s t r o de i n s t r u c c i 6 n
r RI : p r o c e s s { I n i c i a l i z a , Re l o j )
be g i n
i f ( I n i c i a l i z a = ' 1 ' ) t h e n
RI <= ( o t h e r s => ' O' ) ;
e l s i f ( Re 1 o j ' e v e n t and Re l o j ' g ' ) t h e n
if( Ca r g a RI = ' 1') t h e n
RI <= Da t o s ;
end i f ;
end i f ;
e n d p r o c e s s r RI ;
- - Re g i s t r o Co n t a d o r d e p r o g r a ma s
r CP : p r o c e s s { I n i c i a l i Za , Re l o j J
be g i n
i f ( I n i c i a l i z a = ' 1 ' ) t h e n
CP <= ( o t h e r s => ' O' ) ;
e l a i f ( Re l o j ' e v e n t and Re l o j = ' 0 ' ) t h e n
i f ( I n c CP = ' 1 ' ) t h e n
CP <= u n s i g n e d { CP ) + '1';
end i f ;
i f ( Ca r g a CP = ' 1 ' ) t h e n
324 VHDL. Lenguaje estndar de Diseo Electrnico
CP <= RI ( 7 do wnt o O) ;
end i f ;
end i f ;
end pr o c es s r CP ;
- - Regi s t r o de di r ec c i n
r ROM : pr o c es s ( I ni c i a l i z a , Rel o j )
begi n
i f ( I ni c i a l i z a = ' 1' ) then
ROM <= ( o t ber s => ' O' ) ;
el s i f ( Rel o j ' ev ent and Rel o j = ' O' ) t hen
i f ( Ca r ga RDM = ' 1') then
ROM <= uns i gned( RI ( 7 do wnt o O)) + uns i gned( Rx ( 7 do wnt o O));
end i f ;
end if;
end pr o c es s r RDM;
- - Regi s t r o Ac umul a do r
r A : pr o c es s ( I ni c i a l i z a , Rel o j )
begi n
i f ( I ni c i a l i z a = ' 1' ) then
A <= (otbers => ' O' ) ;
el s i f ( Rel o j ' ev ent and Rel o j ' O' ) t hen
i f ( Ca r ga A = '1') then
A <= Rx;
end if;
end if;
end pr o c es s r A;
- - Regi s t r o C
r c : pr o c es s ( I ni c i a l i z a , Rel o j )
begi n
i f ( I ni c i a l i z a = ' 1' ) t hen
C <= '0';
el s i f ( Rel o j ' ev ent and Rel o j ' 1' ) t hen
i f ( Ca r ga C = ' 1' ) t hen
C <= Cer o ;
end i f ;
end if;
end pr o c es s r C;
- - Regi s t r o N
r N: pr o c es s ( I ni c i a l i z a , Rel o j )
begi n
i f ( I ni c i a l i z a = ' 1' ) t hen
N <= 'O';
el s i f ( Rel o j ' ev ent and Rel o j - ' 1' ) t hen
i f ( Ca r ga N = ' 1' ) t hen
N <= Nega t i v o ;
end i f ;
endi f ;
end pr o c es s r N;
LISTADO 5-35. Modelado de los registros especficos.
5. Modelado con VHDL 325
El resto de la funcionalidad del circuito corresponde a la lgica combinacional
queinterconecta los diferentes recursos modelados hastael momento. El siguiente lis-
tado corresponde al modelado de los dos multiplexores utilizados para seleccionar la
fuentedel segundo operando delaVAL y lafuente del campo registro (Figura 5-14).
Como puede observarse, el primer multiplexor seha modelado mediante un proceso
combinacional que contiene una instruccin case, para seleccionar en funcin de la
seal deseleccin Sel lafuente correspondiente. Sinembargo, el segundo utiliza una
asignacinconcurrente condicional pararealizar lamisma operacin.
- - Se l e c c i n de f ue nt e de l s e gundo o pe r a ndo
OpSe l : pr o c e s s ( Da t o s , RI , Rx )
v a r i a bl e Se l : s t d_ l o gi c _ v e c t o r ( l do wnt o O) ;
be gi n
Se l : = RI ( 14) &RI ( 2) ;
c a s e ( Se l ) is
whe n " OO' => B <= Da t o s ;
whe n " 01" => B <= Da t o s ;
whe n -io- => B <= Rm & RI ( 7) & RI ( 7) &
~(7) &RI(7) &.Iu.i7) &
RI ( 7) &RI ( 7) &RI ( 7) &
RI ( 7) &RI ( 7) &RI ( 7 do wnt o 3) ;
whe n " 11 H => B <= Rx ;
whe n o t he r s => B <= ( o t he r s => ' X' ) ;
e nd c a s e ;
end pr o c e s s OpSe l ;
- - Se l e c c i n de l r e gi s t r o de l ba nc o
with Se l Ca mpo s e l e c t
Se l Re gi s t r o <= Rf _ Rd when ' 00' ,
Rf 1_ Rj when " 01' ,
Rf 2 whe n " 10' ,
( o t he r s => '-') when " 11" ,
( o t he r s => 'X') whe n o t he r s ;
- - Se l e c c i n de l r e gi s t r o de l ba nc o
with Se l Ca mpo s e l e c t
Se l Re gi s t r o <= Rf _ Rd when " DO" ,
Rf 1_ Rj whe n " 01' ,
Rf 2 when " 10' ,
( o t he r s => '-') whe n " 11 H,
( o t he r s => ' X' ) whe n o t he r s ;
LISTADO 5-36. Modelado de losmultiplexores.
La lgica combinacional restante seencargar delafuncin deevaluacin dela
condicin desalto y lahabilitacin delos tri-estado deacceso al bus del sistema.
326 VHDL. Lenguaje estndar de Diseo Electrnico
- - E v a l ua c i n de l a c o ndi c i n
E v a l Co nd: pr o c e s s ( Co ndi c i o n, Ne ga t i v o , Ce r o )
v a r i a bl e Re s ul t a do : s t d_ l o gi c ;
be gi n
Re s ul t a do :=' O' ;
c a s e Co ndi c i o n i s
whe n ' 000 => Re s ul t a do : = 'l'L,-'" BR
whe n ' 001" 1" 101" => Re s ul t a do : = Ce r o ; . ; . . B~
whe n ' 010 1" 110 => Re s ul t a do : = Ne ga t i v o ; - - BL
whe n '011" => Re s ul t a do : = Ne ga t i v o a r Ce r o ; - - BL E
when " 101" => Re s ul t a do : = no t Ce r o ; - - BNE
whe n " 110
whe n " U1"
whe n o t he r s
=> Re s ul t a do : = no t Ne ga t i v o a r Ce r o ; - - 1l OE
=> Re s ul t a do : = Ne ga t i v o and Ce r o ; - - BG
=> Re s ul t a do . - ' X' ;
e nd c a s e ;
Sa l t o <=Re s ul t a do ;
end pr o c e s s E v a l Co nd;
- - Se l e c c i n de l a di r e c c i n de me mo r i a
Di r e c c i o n <=ROM when
( F ue nt e Di r e c c i o n = ' 1' and Ha bi l i t a Di r e c c i o n =' 1' ) e l Be
CP when
( F ue nt e Di r e c c i o n = ' O' and Ha bi l i t a Di r e c c i o n = ' 1' ) e l Be
( o t he r s => ' Z' ) ;
- - Ha bi l i t a c i n de l o s da t o s
Da t o s <=Rx when Ha bi l i t a Da t o s = ' 1' e l Be
( o t he r s => ' Z' ) ;
LISTADO 5-37. Modelado de la condicin de salto.
5.5.4.2. La Unidad de Control
La Unidad deControl es laencargada de sincronizar todas las tareas que deben rea-
lizarse para ejecutar las instrucciones sobre launidad operativa. Nos referimos aes-
tas tareas elementales que conforman cada instruccin como microoperaciones, de
manera que laejecucin deuna instruccin consistir simplemente en llevar acabo
lasecuencia dernicrooperaciones que lecorresponda.
En nuestro caso, el control de la ejecucin de las diferentes microoperaciones
serealizar mediante una serie de seales de control sobre la unidad deproceso, el
bus del sistema y el rbitro debus. Adems, su secuenciamiento depender delain-
formacin de estado proporcionada por la unidad de proceso, en forma de seales
deentrada, tal y como muestra laFigura 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.
5. Modelado con VHOL 327
CargaRDM
CargaCP
rbitro de BusLibre CargaRI
Bus
PeticionBus CargaA
CargaN
CargaC
Unidad de
IncCP
Unidad de
Control proceso
Opera
EscribeRegistro
SelCampo
FuenteDireccin
HabilitaDireccin
I AWnwri, F
HabilitaDatos
Escribe
Salto
HabilitaMem
CodigoOp
FIGURA 5-19. Unidad de Control de la Mquina Rudimentaria.
l i br ar y I EEE;
us e I EEE. STD_ L OGI C_ 1164. al l ;
ent i t y UCont r ol i s
port (
Rel oj
I ni c i al i z a
in s t d_ l ogi c ;
in s t d_ l ogi c ;
- - Es t ado de l a UP
Codi goOp in s t d_ l ogi c _ v ec t or ( l downt o O) ;
Sal t o in s t d_ l ogi c ;
- - Mi c r ooper ac i ones
Car gaRDM out s t d_ l ogi c ;
Car gaCP out s t d_ l og c ;
Car gaRI out s t d_ l og c ;
Car gaA out s t d_ l og c ;
I nc CP out s t d_ l ogi c ;
Car gaN out s t d_ l ogi c ;
Car gaC out s t d_ l ogi c ;
Oper a out s t d_ l ogi c ;
Es c r i beRegi s t r o out s t d_ l ogi c ;
Sel Campo out s t d_ l ogi c _ v ec t or ( l downt o O) ;
328 VHDL. Lenguaje estndar de Diseo Electrnico
F u e n t e Di r e c c i o n
Ha b i l i t a Di r e c c i o n
Ha b i l i t a Da t o s
out std_logic;
out std_logic;
out std_logic;
Ha b i l i t a Me m
Escribe
BusLibre
PeticionBus
out std_logic;
out std_logic;
in std_logic;
out std_logicl;
end UControl;
LISTADO 5-38. Entidad de la Unidad de Control.
Existen dos alternativas alahora deimplementar la funcionalidad deuna Uni-
daddeControl:
Cableada: cuando la secuencia de las diferentes microoperaciones seen-
cuentra implementada enel hardware.
Microprogramada: las microoperaciones seagrupan enmicroinstrucciones
que sealmacenan enuna memoria ROM interna a la unidad, quejunto con
unsecuenciador permiten laejecucin delosdiferentes microprogramas que
corresponden acada instruccin.
En el resto dela seccin analizaremos cules deben ser las microoperaciones
que la Unidad deControl dela Mquina Rudimentaria debe realizar para ejecutar
cada una de las diferentes instrucciones. Todas aquellas microoperaciones que se
puedan realizar simultneamente seagruparn en estados, para finalmente obtener
el diagrama deestados total dela Unidad deControl. Por ltimo, estudiaremos las
diferentes alternativas deimplementacin: cableada y microprogramada.
5.5.4.2. 1. El diagrama de estados de la Unidad de Control
Recordemos que la Mquina Rudimentaria dispone decinco formatos deinstruc-
cindiferentes, resumidos enlaFigura 5-4.
La Figura 5-20 muestra el diagrama deestados dela mquina decontrol que
implementa laUnidad deControl.
El estado inicial del diagrama (Solici taBus 2) es el encargado desolicitar el
bus al rbitro debus. Nodebemos olvidar quepueden existir otros componentes en
el sistema que tambin tomen el control del bus, por lo que antes deacceder a l
hay querealizar una peticin y esperar laconcesin.
2 Sellega a este estado cada vez que finaliza la ejecucin deuna instruccin o seproduce una
inicializacin del sistema.
5. Modelado con VHDL 329
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), debsqueda
y descodificacin de la instruccin, es comn atodas las instrucciones. Se encarga
dealmacenar en el registro RI lasiguiente instruccin aejecutar. A partir deeste es-
tado, yen funcin del cdigo deoperacin de lanueva 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 ladireccin desde o alaque
se va a realizar la carga o almacenamiento (CalculaDreccion). Posteriormente,
en funcin del cdigo deoperacin seejecutar dicha carga (CargaDato) o almace-
namiento (AlmacenaDato).
La carga del dato (CargaDato) consiste en acceder alamemoria RAM del sis-
temapara obtener el dato aalmacenar en el banco deregistros.
Almacenar el dato (AlmacenaDato) significa guardar en la memoria del siste-
mael contenido del registro especificado.
La instruccin de salto slo requiere un estado (CargaDireccion), durante el
cual secolocar enel registro contador deprogramas lanuevadireccin deprograma.
330 VHDL. Lenguaje estndar de Diseo Electrnico
La ejecucin de las operaciones aritmtico-lgicas serealiza 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, seejecuta laoperacin y almacena el resultado en el
registro destino (estado Ejecuta).
La Tabla 5-8 muestra detalladamente cules son las rdenes decontrol que de-
ben activarse durante cada estado del diagrama delaFigura 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 aeste diagrama de
estados, de manera que sea directamente sintetizable, para de esta manera imple-
mentarlo delamisma forma que laUnidad deProceso. Veamos, pues, cul debe ser
el estilo deladescripcin.
5 . 5 . 4 . 2 . 2 . Implementacin cableada de la Unidad de Control
Una implementacin cableada consiste simplemente en realizar un circuito arnedi-
daque, apartir delas seales deentrada y el estado memorizado, genera las corres-
pondientes salidas. Las implementaciones cableadas generalmente son ms rpidas
que las microprogramadas, acosta, sin embargo, deun mayor coste y complejidad.
5. Modelado con VHDL 331
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 acontinuacin, consistir en describir el comportamiento delaunidad median-
teunmodelo deVHDL sintetizable, obteniendo as el circuito equivalente.
En general, una buena tcnica para modelar en VHDL sintetizable diagramas
deestados 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 segeneran 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.
l i br a r y I E E E ;
use I E E E . ST D_ L OGI C_ 1164. a l l ;
a r c hi t e c t ur e F unc i o na l o f UCo nt r o l 18
t y pe t E s t a do s is ( Bus c a l ns t r uc c i o n, Ca l c ul a D t e c c i o n, Ca r ga Da t o ,
Al r na c e na Da t O' , C8r ga D r e c c o n, L e e Ope r a ndo ,
E j e c ut a , So l i c i t a Bus ) ;
c o ns t a nt Co nt P r o g : s t q_ l o gi c := '0.';
c o ns t a nt Re gI J . I s t q_ l o gi c : ='1';
c o ns t a nt Rd s t q_ l o gi c _ v e c t o r (1 do wnt o 0.) : = "0.0.";
c o ns t a nt Rf 1_ Rx s t q_ l o g c . ; . . v e c t o r ( ldo wnt o 0.) :="0.1";
c o ns t a nt Rf 2 s t d_ l o gi c _ v e c t o r ( l do wnt o 0.) :="10.";
s i gna l E s t a do , Si - gui e nt e E s t a do : t E s t a do s ; = So l i c i t a Bus;:
be gi n
Co mbi na c i o na l : pr o c e s s ( E s t a do , Bus L i br e , Sa l t o , Co di ga o p)
be gi n
- _ v a l o r po r de f e c t o de l a s s e a l e s de c o nt r o l
P e t i c i o nBus <= '0.';
Ca r ga RI J . I <;= ' 0.' ;
Ca r ga CP <= '0.';
Ca r ga RI . 'd: "j o . , :
I nc CP <= '0.';
Ope r a <= '0.';
Se l Ca mpo <=Rd;
E s c r i be Re gi s t r o <=' 0.' ;
F ue nt e Di r e c c i o n <=Co nt P r o g;
332 VHDL. Lenguaje estndar de Diseo Electrnico
~j . l i t a Di r e c c i o n <= ' O' ;
Ha bi l i t a Da t o s <= ' 0' ;
Ha bi l i t a Me m <= ' O' r
Es c r i be <~ 'Z';
- - As i gna c i n de s a l i da ~ yc l c ul o del s i g! l ' l . t e e s t a do
c a s e Es t a do l s
when So l i c i t a Bus =>
P e t i c i o nBus <= '1';
l f ( Bus L i br e , = ' 1' ) then
Si gui e nt : ~t a do <= Bus c a . I ns t r uc c i o o ;
end i f ;
when Bus c a l ns t r uc c i o n =>
I nc CP <= '1';
Ca r ga RI <= ' i';
Ha bi l i t a Di r e c c i o n d'1"'t
Ha bi l i t a Me m <= '1';
Es c r i be <= ' (t' ;
P e t i c i o nBus <= '1';
ifCo di go Op (1) , O' then
Si gui e nt e Es t a do <= Ca l c ul a Di r e c c i o n;
e l s e
l f Co di go Op( O) = ' O' t he n
l f Sa l t o = '1' then
Si gui e nt e Es t a do <= Ca r ga Di r e c c i o n
end i f ;
e l s e
Si gui e nt e Es t a do <= L e e Ope r a ndo ;
end l f ;
end i f ;
whe n Ca l c ul a Di r e c c i a n =>
Ca r ga RI M <=' l';
P e t i c i o nBus <= '1';
Es c r i be <= ' Z' ;
l f Co di go Op( O) = ' 0' then
Si gui e nt e Es t a do <= Ca r ga Da t o ;
e l s e
Si gui e nt e Es t a do <= Al ma c e na Da t o ;
end l f ;
when L e e Ope r a ndo =>
Ca r ga A <= ' 1' ;
Se l Ca mpo <= Rf l _ Ri ;
Si gui e nt e Es t a do <= Ej e c ut a ;
whe n Ca r ga Di r e c c i o n =>
Ca r ga CP <= ' 1' ;
Si gui e nt e Es t a do <= So l i c i t a Bus ;
5. Modelado con VHDL 333
when carganat;p :;:>
F u e n t e Di r e c c i Qn s =. ~~;
E s c r i b e Re g i s t r o <, ; ", 1 t ;
Ha b i l i t a Di r e c c i a n <d : '1';
Ha b i l i t a Me m ' , ; <; ; '1';
CargaN <= '1' i
CargaC <'" '1';
S i g u i e n t e E s t a d , o . . <= S o l i c i t a Bu s ;
when Al n a c n a Da t o =>
F u e n t e Di r e c c i o n <= Re g I J M;
E s c r i b e <:;: , 1'.
Ha b i l i t a Di r e c c i o n <= '1';
Ha b i l i t a Da t o s <= '1';
. Ha b i l i t a Ma n <= '1';
S i g Ui n t e E s t a <l . <= . $ 9 1 ~c i t a Bu s ;
when E j e c u t a =>
S e l Ca mp o <= Rf 2 ; .
E s c r i b e Re g i s t r o <= ' 1 ' ;
CargaN <= '1';
CargaC <= '1';
Op e r a <",' ,.;t,;
S i g u i e n t e E s t a d o : <= S OUc i t a Bu s ;
"
when o t h e r s =>
S i g u i e n t e E s t a d o <= S o ~g i t ~;
e n d c a s e ;
end p r o c e s s Co mb i n a c i o n a l ;
S e c u e n c i a l : p r o c e s s ( Re l o j , I n i c i a l i z a )
b e g i n
i f ( I n i c i a l i ~ = '1') then
E s t a d o <= S o l i c i t a Bu s ;
e 1 s i f ( Re l o j ' e v e n t and Re l o j ' 1 ' ) t h e n
E s t a d o <= S i g u i e n t e E s t a d o ;
end i f ;
end p r o c e s s S e c u e n c i a l ;
end F u n c i o n a l ;
LISTADO 5-39. Mquina de es tados de la Unidad de Control.
Puede observarse cmo el proceso Secuencialtiene laestructura deun proce-
so secuencial tpico. Si la seal Inicializa seactiva de forma asncrona, secolo-
car la mquina en el estado inicial, exactamente igual que si se tratara de la seal
Inicializa asncrona deunflip-flop. Durante el funcionamiento normal, el proce-
so ser sensible al flanco de subida del reloj, demanera que cada vez que tenga lu-
gar se asignar como nuevo estado el siguiente, calculado apartir del estado actual
y las entradas alamquina deestados.
334 VHDL. Lenguaje estndar de Diseo Electrnico
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 microp