VHDL Lenguaje Estándar de Diseño Electrónico

~ 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
(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
(CSID). Universitat Autnoma deBarcelona
femando@cnm.es
Pablo Snchez
Universidad deCantabria
sanchez@teisa.unican.es
Llus Ters
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
vidal@cnm.es
Eugenio Villar
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.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.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.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.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.
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).
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].
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
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-
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).
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].
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.
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-
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.
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
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-
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
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.
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.
[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
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
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
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.
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),
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.
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
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;
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.
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.
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
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;
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-
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-
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.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-
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).
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
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.
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.
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 ;
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.
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
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.
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.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:
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.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
'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
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.
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;
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:
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);
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:
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:
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.
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:
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 ;
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-
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
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.
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-
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.
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:
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.
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.
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}
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
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,
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)
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.
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;
process t 10ns
begin ___________..
v 'O'
s<='O' after 10ns; L..._--L._ __ .....J
s<='1' after 20ns; _
wait;
end process;
(a)
'1'
20 ns
t 20 ns
v '1'
t 10ns
v
(b)
FIGURA 2-8. Evolucin de la cola de eventos. Modelo inercial.
El comportamiento en este caso es el mismo que para el modelo de transporte,
la segunda asignacin elimina el valor que 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,
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;
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.
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 ;
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;
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
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:
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 =>
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 =>
wben "dO =>
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 ;
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 " =>
whe n o t he r s =>
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 ;
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
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 ;
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).
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 ]
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.
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
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-
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 ]
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.
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.
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;
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};
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;
2.5.13.
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.
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.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;
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.
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
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.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
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.
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
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
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 ;
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:
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-
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.
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:
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.
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 ) ;
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-
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-
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.
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:
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
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.
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.
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
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';
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-
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.
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)
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.
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.
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
e l s i f <c o n d i c i n > then
e l s e
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.
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
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.
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.
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-
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-
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.
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.
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.
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-
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.
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
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
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.
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.
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.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
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.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.
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.
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).
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.
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.
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
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.
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.
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.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).
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.
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.
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.
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.
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.
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.
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.
[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.
[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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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-
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:
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.
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.
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-Integer Signed
"*,,
multiplicacin Unsigned-Unsigned Unsigned
Signed- Integer Signed
rr
divisin Unsigned- Unsigned Unsigned
(si el segundo Signed-Signed Signed
argumento es nulo, Unsigned-Natural Unsigned
seproduce un ERROR) Signed- Interger Signed
"rem" resto Unsigned- Unsigned Unsigned
argumento es nulo, Unsigned-Natural Unsigned
seproduce un ERROR) Signed-Integer Signed
"mod" mdulo Unsigned-Unsigned Unsigned
argumento es nulo, se Unsigned-Natural Unsigned
produce un ERROR) Signed-Integer Signed
Funciones de
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.
Funciones de
comparacin
" =" igual
Operandos 7 Resultado
Unsigned-Unsigned Boolean
Signed-Signed Boolean
Unsigned-Natural Boolean
Signed- Integer Boolean
Unsigned- Unsigned Boolean
Signed- Integer Boolean
Signed-Integer Boolean
Signed-Integer Boolean
Descripcin
" <=" menor o igual
" >=" mayor o igual
" /=" distinto
Funciones de
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
Rotate_Right rotacin Unsigned-Natural Unsigned
"sIl" desplazamiento Unsigned-Natural Unsigned
"srl" desplazamiento Unsigned-Natural Unsigned
"rol" rotacin Unsigned-Natural Unsigned
"ror" rotacin Unsigned-Natural Unsigned
8 En estas funciones el tipo de los operandos no es intercambiable, ya que el segundo operando
representa el nmero 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
"nand" funcin lgica "no-y" Unsigned- Unsigned Unsigned
" nor" funcin lgica "no-o" Unsigned- Unsigned Unsigned
"xor" funcin lgica "0- Unsigned- Unsigned Unsigned
exclusiva" bit abit Signed-Signed Signed
"xnor" funcin lgica "no-o- Unsigned-Unsigned Unsigned
exclusiva" bit abit Signed-Signed Signed
Funciones de
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
To_Ol Conversin a o 1
Unsigned-Std_Logic
Signed-Std_Logic
Unsigned
Signed
representa el tamao del vector resultante.
representa el valor aasignar cuando sedetecta una discrepancia (por defecto 'O').
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' ;
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.
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';
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:
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;
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:
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 ;
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
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" ;
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;
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;
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
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 ;
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
_ 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
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
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
- e s t a d o s 3
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.
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 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
_ 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
_ 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
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-
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
, . . . 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.
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:
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.
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.
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');
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.
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
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.
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-
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.
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-
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;
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
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 ;
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 ;
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;
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
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 ;
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 ;
LISTADO 5- 3. Ejemplo de informacin compartida encapsulada en un proceso.
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.
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.
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
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
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 ;
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 '
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.
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 ) ;
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);
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.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
[
,
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.
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)
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.
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-
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.
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;
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
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';
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.
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
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
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
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 ;
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.
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
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.
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.
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
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".
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 ;
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
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
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
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-
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.
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.
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.
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.
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);
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.
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.
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.
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.
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).
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 ;
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 ;
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
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 ;
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
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.
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.
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 0)1
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 (
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) ) ;
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 (
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) ) ;
c a mp o n e n t Op e r a d o r Y
g e n e r i c t
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.
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;
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;
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;
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 ) ;
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.
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:
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.
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.
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.
l i b r a r y I E E E ; . ,
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.
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:
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 _ 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 _ 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;
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 ;
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 ;
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:
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.
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;
- - 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.
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
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.
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.
- - 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.
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) ;
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.
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.
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.
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.
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;
~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' ;
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';
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 ;
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 ;
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.
El proceso Combinacional bsicamente consiste en una sentencia case, con
una entrada para cada posible estado de la mquina de control. Para cada estado se
especificar cules son sus salidas asociadas y se calcular el siguiente, comproban-
do para ello el estado de los bits del cdigo de operacin y la condicin de salto, en
funcin de la instruccin de que se trate. Una buena prctica para evitar omisiones
que provoquen un funcionamiento no deseado del circuito consiste en inicializar to-
das las seales de control antes de entrar a la sentencia case, que evaluar el estado
y asignar valores slo a aquellas seales que intervengan en la operacin a realizar.
5.5.4.2.3. Implementacin microprogramada
de la Unidad de Control
La microprogramacin es una alternativa mucho ms extendida frente al uso de uni-
dades de control cableadas. Un microprograma (tambin denominado firmware), al
igual que un programa, no es ms que la implementacin de un algoritmo mediante
un conjunto de microinstrucciones. Estas microinstrucciones no son otra cosa que la
agrupacin de una serie de microoperaciones que pueden realizarse simultneamente.
Una de las principales ventajas de este tipo de implementacin se debe a la fle-
xibilidad del esquema, puesto que modificar el comportamiento de la unidad es tan
sencillo como cambiar el microprograma que se almacena en la memoria de control.
Aunque existen muchas alternativas a la hora de definir el formato de una mi-
croinstruccin, en nuestro caso, y puesto que no es el objetivo de este texto profun-
dizar en este tema, se ha optado por el ms claro y sencillo, el formato horizontal.
Pero antes de describir este formato, y para facilitar su comprensin, veamos cul
es la arquitectura tpica de una Unidad de Control microprogramada.
Como se aprecia en la Figura 5-21, existen varios bloques bien diferenciados
en una Unidad de Control microprogramada. En primer lugar, es necesario disponer
de una memoria de control, en la que se almacenar el conjunto de microinstruccio-
nes que componen los microprogramas del procesador (la Mquina Rudimentaria,
en este caso). Modificar el microprograma correspondiente a cada instruccin es tan
sencillo como reprogramar dicha memoria de control.
Para que la ejecucin de una microinstruccin pueda realizarse de forma simul-
tnea a la bsqueda de la siguiente en la memoria de control, ser necesario dispo-
ner de un registro (RMIC) que la almacene hasta el siguiente ciclo de reloj. Como
puede deducirse por esto ltimo, se ejecutar una microinstruccin por ciclo.
El resto de los bloques de la unidad estn dedicados al control del secuenciamien-
to de los microprogramas. As, a partir de la propia informacin proporcionada por la
microinstruccin, y la informacin de estado de la unidad de proceso, el secuenciador
ser el encargado de enviar a la memoria de control la direccin de la siguiente mi-
croinstruccin a ejecutar. Esta direccin puede venir del contador de microprogramas
(CMP) en el caso de la ejecucin en secuencia, de un campo de la microinstruccin, si
se trata de una microinstruccin de cambio de secuencia, o del registro de instruccin.
En este ltimo caso se utiliza el cdigo de operacin directamente como direccin, de
manera que cuando se ejecuta una nueva instruccin se accede a la posicin de su
cdigo de operacin, donde se hallar una microinstruccin de salto al lugar de la
memoria donde realmente se encuentra su microprogama asociado.
'O'
Salto
CodigoOp'
'1'
CargaCMP
Memoda de
Control
FIGURA 5-21. Diagrama de estados de la Unidad de Control.
Como se puede apreciar en la Figura 5-19, cada microinstruccin constar de
varios campos que podemos clasificar en dos grupos:
De secuenciamiento: que decidirn la siguiente microinstruccin a ejecutar
(SelSigDireccion, SelCondicion, SigDireccion).
Micrordenes: que activarn las seales decontrol.
Este tipo deformato sedenomina horizontal, puesto que existe un bit dela mi-
croinstruccin para cada seal de control, pudiendo simultanear la ejecucin de to-
das ellas. En el caso delaMquina Rudimentaria el formato final deuna microins-
truccin ser el delaFigura 5-22.
Una vez conocido el formato dela microinstruccin, y apartir de laTabla 5-8,
que contiene la codificacin de las seales de control en funcin de los diferentes
estados, pasemos adesarrollar el microprograma equivalente (Figura 5-23).
Las cuatro primeras posiciones del microprograma contienen un salto a la di-
reccin decomienzo decada una delas cuatro microinstrucciones. De esta manera,
cada vez que sequiera ejecutar una nueva instruccin, tan slo hay que indicarle al
secuenciador que seleccione el salto ala direccin indicada por el cdigo de opera-
cin, para que desde sta salte alazona correspondiente. Para el resto delos cuatro
fragmentos de cdigo simplemente se ha traducido cada estado de la mquina de
control delaFigura 5-20 enuna microinstruccin.
22 o 21 20 19 15 14
SelSigDireccion
Micrordenes
Bit 14: CargaRDM
Bit 13: CargaCP
Bit 12: CargaRI
Bit 11: CargaA
Bit 10: IncCP
Bit 9: CargaN
Bit 8: CargaC
Bit 7: Opera
SigDreccon SelCondcion Microordenes
SelSigDireccion
0-> SALTAR
'1-> CODIGO_OP
SelCondicion
00 ->'O'
01 ->Salto
10 ->BusLibre
11 ->'1'
Bit 7 : Opera
Bit 6 : EscribeRegistro
Bit 5-4: SelCampo
Bit 3 : FuenteDireccin
Bit 2 : HabilitaDireccn
Bit 1 : HabilitaDatos
Bit O : HabilitaMem
FIGURA 5-22. Formato de microinstruccin de la Mquina Rudimentaria.
Direccin Microinstruccin
00000 O 11 00100 000000000000000
00001 O 11 01000 000000000000000
00010 O 11 01100 000000000000000
00011 O 11 10001 000000000000000
00100 O 10 00101 000000000000001
00101 O 00 00000 000001100000101
00110 O 00 10000 000010000000001
00111 1 00 00000 000000010000101
01000 O 10 01001 000000000000001
01001 O 00 00000 000001100000101
01010 O 00 00000 000010000000001
01011 1 00 00000 000000000001111
01100 O 10 01101 000000000000001
01101 O 00 00000 000001100000101
01110 O 01 10000 000000000000001
01111 1 00 00000 000000000000000
10000 1 00 00000 001000000000000
10001 O 10 10011 000000000000001
10010 O 00 00000 000001100000101
10011 O 00 00000 100010000100000
10100 1 00 00000 010100011000000
Decodificacin del campo CodigoOp.
Salto a la instruccin correspondiente
Instruccin de carga
Instruccin de almacenamiento
Instruccin de salto
Instruccin de operacin
aritmtico-lgica
FIGURA 5-23. Microprograma de la Unidad de Control.
El modelo completo de la Unidad de Control microprogramada es el que se
muestra en el Listado 5-40. Observe cmo el componente ROM acepta como gen-
ricos no slo el nmero debits dedatos y direcciones, sino tambin el contenido de
lamemoria. En este ejemplo dicho contenido ser nuestro microprograma de con-
trol, queencontrar almacenado en laconstante Microprograma.
us e I E E E . ST D_ L OGI C_ 1164. a 11;
us e I E E E . ST D_ L OGI C_ ARI T H . a l l ;
a r c hi t e c t ur e E s t r uc t ur a l o f UCo nt r o l is
c o ns t a nt Mi c r o pr o gr a ma : t Co nt ROM : = (
' 01100100000000000000000' , - - 00000 Sa l t o al mi c r o pr o gr a ma CARGAR
' 01101000000000000000000 , - - 00001 Sa l t o a l mi c r o pr o gr a ma AL MACE NAR
01101100000000000000000' , - - 00010 s a l t o a l mi c r o pr o gr a ma SAL T AR
01110001000000000000000' , - - 00011 Sa l t o a l mi c r o pr o gr a ma OP E RAR
- - I ns t r uc c i n CARGAR
01000101000000000000001' , - - 00100 Si Bus L i br e s a l t a a 00101
00060060000001100000101 , - - 00101 Bus c a i ns t r uc c i n
00000000000010000000001' , - - 00110 Ca l c ul a di r e c c i n
100000000000000100o o 10i , - - 00111 Ca r ga da t o
- - I ns t r uc c i n AL MACE NAR
010' 01001000000000000001 ,
' 09000000000001100000101' ,
' 00000000000010000000001 ,
' 10000000000000000001111' ,
- - I ns t r uc c i n SA Lm
01001101000000000000001' ,
' 00000000000001100000101' ,
' 00110000000000000000001 ,
10000000000000000000000 ,
' 10000000001000000000000' ,
- - 01000 Si Bus L i br e s a l t a a 01001
- - 01001 Bus c a i ns t r uc c i n
- - 01010 Ca l c ul a di r e c c i n
- - 01011 Al ma c e na da t o
- - 01100 Si Bus L i br e s a l t a a. 01101
- ' - 01101 Bus c a i ns t r uc c i n
- - 01110 E v a l a l a c o ndi c i n de s a l t o
- - 01111 Co ndi c i n f a l s a
- - I ns t r uc c i n OP E RAR
' 01010011000000000000001' , , . . , . : l i l QP 1. Si Bus L i br e s a l t . a a 10011
' 00000000000001100000101' , ~. . 1001. {)Bus c a i ns t r uc c i n
' 00000000100000000100000' , - - 10011. Lee o pe r a ndo
' 10000000010100011010000~, - - 10100 E j e c ut a o pe r a c i n
o t he r s => 00000000000000000000000' ) ;
- - 10000 Ca r ga di r e c c i n s i s e da l a c o ndi c i n
\-
c o ns t a nt SAL T AR
c o ns t a nt CODI GO_ OP
8t ~l o gi c . - ' 0' ;
s t ~l o gi c . - ' 1' ;
s i gna l Di r Si gMi c r o i nSt
s i gna l Mi c r o i ns t r uc c i o n
s i gna l unUno
8t ~l o gi c _ v e c t o r ~c Bi t s Di r ROM- l do wnt o O) ;
s t Q_ l o gi c _ v e c t o r {c Bi t s Da t o ROM- l do wnt o O) ;
s t Q_ l o gi c := ' 1' ;
- - Re gi s t r o s c de l a uni da d de o nt r o l
s i gna l RMi c : s t c L l wi c _ v e c t o r ( c Bj , t s Da t o ROM- l do wnt o O) ;
s i gna l C MP : c s t c L l o gi c _ v e c t o r ( c Bi t s Di r ROM- 1 do wnt o O) i
- - Ca mpo s de s e c t I e nc i a mi e nt o de l a mi c r o i ns t r uc c i 6n
a l i a s Se l Si gDi r e c c i o n s t c L l o gi c isRMi c ( 22) ;
a l i a s Se l Co ndi c i o n s t d_ l o gi c _ v e c t o r ( l da Nnt o O) i s RMi c ( 21 do wnt o 20) ;
a l i a s Si gDi r e c c i o n s t d_ l o gi c _ v e c t o r ( c Bi t s Di r ROM- 1 do wnt o O)
l a RMi c ( 19 do wnt o 151;
c o mpo ne nt ROM
ge ne r i e (
Bi t s Di r e c c i o n
Bi t s Da t o
Co nt e ni do
port(
Ha bi l i t a
na t ur a l ;
na t ur a l ;
t Co nt ROM) ;
Di r e c c i o n
Da t o
end e a o po ne nt ;
i n s t c L l o gi c ;
in s t c L l o gi c _ v e c t o r ( Bi t s Di r e c c i o n- 1 do wnt o O) ;
o ut s t c L l o gi c _ v e c t o r ( Bi t s t l a t o - 1 do wnt o O));
be gi n
ROM_VC: ROM
ge ne r i e map(
Bi t s Di r e c c i o n =>' c Bi t s Di r ROM,
Bi t s Da t o => c Bi t s Da t o ROM,
Co nt e ni do => Mi c r o pr o gr a ma )
port map(
Ha bi l i t a => UnUno ,
Di r e c c i gn => Di r Si gMi c r o i ns t ,
Da t o c .e =: >Mi c r o i ns t r uc c i o n) i
Re gi s t r o RMI C: pr o c e a s ( I ni c i a l i z a , Re l o j )
be gi n
i f I ni c i a l i z a = ' 1' t he n
RMi c <= ( o t he r s => ' O' ) ;
e l e e
RMi c <= Mi c r o i ns t r uc c i o n;
end i f ;
end pr o c e s s Re gi s t r o RMi c ;
Co nt a do r MP : pr o c e s s
s ubt y pe t Co nt a do r i s i nt e ge r r a nga O te 2* * c Bi t SDi r ROM;
c o ns t a nt T o pe : i nt e ge r : = 2* * c Bi t s Di r ROM;
v a r i a bl e Va l o r : t Co nt a do r ;
be gi n
wa i t unt i l I ni c i a l i z a = ' 1' ;
loop
i f I ni c i a l i z a = '1' t he n
Va l o r : = O;
end l f ;
wa i t unt i l ( Re l o j ' e v e nt a nd Re l o j ' 1' ) o r ( I ni c i a l i z a = ' 1' ) ;
ne x t when I ni c i a l i z a = '1':
c a s e Va l o r i a
when T o pe => Va l o r : = O;
when o t h e r s =>Va l o r :=c o n v _ i n t e g e r ( u n s i g n e c t ( Di r S i g Mi c r o i n s t ) ) + ~
end c a s e ;
end loop;
CMP <=c o n v _ s t d _ l o g i c ~v e c t o r ( Va l o r , c Bi t s Di r RCM)
end p r o c e s s Co n t a d o r MP
- - S e c u e n c i a d o r
S e c u e n c i a d o r : p r o c e s s
be g i n
c a s e S e l S i g Di r e c c i o n l s
when SALTAR',,>
c a s e S e l Co n d i c i o n l s
wben " OO' =>
Di r S i g Mi c r o i n s t <=CMP ;
wben 01" =>
lf ( s a l t o ' = 'r') then
Di r S i g Mi c r o i n s t <=S i g Di r e c c i o n
e l s e
Di r S i g Mi c r o i n s t <=CMP ;
end if
wben " l a " =>
if ( Bu s L i br e ' = '1') then
Di r S i g Ml c r 6 1n s t <=S i g D r e c c i o n
e l s e
Di r S i g Mi c r o i n s t <=CMP
end if
wben " 11" =>
Di r S g Mi c r o i n s t <=S i g Di r e c c i o n ;
when others =>
D r S i g Mi c r o i n s t <= ( o t h e r s => ' X' )
end c a s e
when CODl GO_ OP =>
D r S g Mi c r o i n s t <=" 000" &Co d i g o Op ;
when o t h e r s => "
Di r S i g Mi c r o i n s t <= ( o t h e r s => ' X' )
end c a s e ;
end p r o c e s s S e c u e n c i a d o r ;
Ca r g a Rr M <=RMi c { 14 )
Ca r g a CP -ce . ~c ( 13 )
Ca r g l l l . I <=RMi c ( 12 )
Ca r g a A. <=RMi c ( 11)
I n c CP . '<='RMic (lar:
cargaN <=RKlc <n;
Ca r g a C <=r u t i c ( 8 )
Op e r a <=RMi c ( 7 )
E s c r i be Re g i s t r o <=OOc ( 6 )
s e l Ca I ! I l O <=OOc ( 5 d o wn t o 4 ) ;
F u e n t e Di r e c c i o n <=RMi c ( 3 ) ;
Ha bi l i t a Di r e c c i o n <=OOc ( 2 ) ;
Ha bi l i t a Da t o s . <=RMic (;,
Ha b l i t a Me m . <=~k(O)<
end e s t r u c t u r a l
LISTADO 5-40. Unidad de Control microprogramada.
5.5.4.3. La memoria de programas
Para completar nuestro sistema ser necesario disponer tambin un modelo para la
memoria deprogramas. Sin embargo, puesto que las memorias son un componente
habitual de todo tipo de sistemas electrnicos, realizaremos un esfuerzo extra en
dos direcciones:
Por un lado, se tratar de que el modelo sea suficientemente general como
para que pueda ser aprovechado sin mayor esfuerzo en otra situacin. Para
ello sepasar como parmetros al modelo toda aquella informacin que pro-
porcione esta generalidad: espacio de direccionamiento, ancho de la palabra
aalmacenar, valores temporales, etc.
Por otro lado, seintentar reflejar con lamxima fidelidad sucomportamien-
to real, para lo cual nos basaremos en una hoja de datos de una memoria
RAM tpica.
El objeto de este modelo no ser el de la fabricacin de esta memoria tras una
serie de etapas de refinamiento, puesto que dispositivos generalmente se adquieren
de uno de los mltiples proveedores. Sin embargo, ser necesario para poder rea-
lizar una simulacin realista del entorno en el que estar integrado nuestro disposi-
tivo (laMquina Rudimentaria en nuestro caso). Por estas razones, el modelado de
este tipo de componentes estar nicamente enfocado a poder realizar una simula-
cin eficiente.
5.5.4.3.1. Descripcin del funcionamiento
En nuestro caso supondremos que existe en el mercado un componente estndar
que seajusta anuestras necesidades y cuyas caractersticas estn descritas en la Fi-
gura 5-24.
En el caso de un acceso para lectura, una vez colocada la direccin correspon-
diente en el bus dedirecciones seactivar la seal dehabilitacin dememoria (Ha-
bili taMem),para obtener el resultado sobre el bus dedatos.
La escritura funciona de manera similar, pero en este caso antes de colocar la
direccin deber indicarse que la operacin es de escritura (activando a la baja
laseal Escribe). El dato aescribir ser el que seencuentre en ese momento en el
bus dedatos.
5.5.4.3.2. Definicin de la entidad
Puesto que la memoria es un componente que probablemente tendremos oportuni-
dad de utilizar en otra ocasin, podra merecer la pena crear un modelo suficiente-
mente flexible y general como para permitir reutilizar su cdigo (una de las princi-
pales ventajas del modelado VHDL). En tal caso declararemos como valores gen-
ricos no slo el nmero depalabras dela memoria, y la anchura en bits detales pa-
labras, sino tambin todos los parmetros temporales.
Dir Direccin vlida Direccin vlida
TEs~blOir TMantOir TEst~blOir TMantDir
HabilitaMem I~---T-P-UJ-S-OL---* TPrecarga ~---T-P-U-'S-O-E--L_
TEstablL! rMantL TEstablE: fMantE
Escribe _y-' l' ir
irMantOato
-----V-::-~~ '-----t;=======:::'--~ j
Dato vlido Dato
TAcceso TEstablOato
FIGURA 5-24. Cronograma de la memoria RAM.
l i br a r y I EEE;
e nt i t y RAM i s
ge ne r i c (
P a l a br a s
Bi t s Di r
Bi t s P a l a br a
F i c he r o
T Es t a bl Di r :
T Ma nt Di r :
T P ul s o L :
T P r e c a r ga :
T P ul s o E:
T Es t a bl L :
T Ma nt L :
T Es t a bl E:
T Ma nt E:
T Ac c e s o :
T Da t o Va l i do :
T Es t a bl Da t o :
T Ma nt Da t o :
port(
Ha bi l i t a Me m
Es c r i be
Di r e c c i o n
Da t o
e nd RAM;
i nt e ge r
i nt e ge r
i nt e ge r
s t r i ng
t i me . -
. - 8; - - Nme r o de pa l a br a s
. - 3; Nme r o de l ne a s de di r e c c i n
. - 8; - - Nme r o de bi t s po r pa l a br a
. - " r a m. t x t " ; - - Co nt e ni do de l a me mo r i a
O ns ; Es t a bl e c i mi e nt o de l a di r e c c i n
t i me .-O ns ; Ma nt e ni mi e nt o de l a di r e c c i n
t i me .-O ns; P ul s o m ni mo de l e c t ur a
t i me .-O ns P r e c a r ga m ni ma de l a me mo r i a
t i me .-O ns ; P ul s o m ni mo de e s c r i t ur a
t i me .-O ns: Es t a bl e c i mi e nt o de l a s e a l de l e c t ur a
t i me .-O ns : - - Ma nt e ni mi e nt o de l a s e a l de l e c t ur a
t i me .-O ns; - - Es t a bl e c i mi e nt o de l a s e a l de e s c r i t ur a
t i me .-O ns: - - Ma nt e ni mi e nt o de l a s e a l de e s c r i t ur a
t i me .-O ns ; - - Ac c e s o pa r a l e c t ur a
t i me .-O ns ; - - Da t o v l i do
t i me .-O ns ; - - Es t a bl e c i mi e nt o pa r a e s c r i t ur a
t i me .-O ns ) ; - - Ma nt e ni mi e nt o de s pu s de e s c r i t ur a
i n s t d_ l o gi c ;
i n s t d_ l o gi c _ v e c t o r ( Bi t s Di r - 1 do wnt o O) ;
i no ut s t d_ l o gi c _ v e c t o r ( Bi t s P a l a br a - 1 do wnt o O)) ;
LISTADO 5-41. Entidad de la memoria RAM.
Como puede observarse en la declaracin de la entidad de la memoria RAM,
existe un genrico adicional (Fichero) que tiene adems un valor por defecto. La
finalidad de este parmetro es la de poder indicarle al modelo el nombre del fichero
de texto que contendr el estado inicial de la memoria y que por defecto ser siem-
pre ramo txt.
5.5.4.3.3. Modelo funcional de la memoria
La manera ms sencilla y ms eficiente de modelar el estado interno de una memo-
ria es la de guardar su contenido en una variable de valores naturales (Listado 5-42),
puesto que es la forma ms rpida y compacta de almacenar la informacin. Por su-
puesto, esta aproximacin ser adecuada en el caso de que sean de pequeo tamao,
pues de lo contrario la variable ocupar una cantidad de memoria considerable.
t y pe t Me mo r i a i s a r r a y ( na t ur a l r a nge o t o Wo r ds - l ) o f na t ur a l ;
Para el modelado del comportamiento de la memoria utilizaremos un nico
proceso (Listado 5-42), en el que como se puede ver se han definido dos procedi-
mientos: Inicializa y CargaFichero.stos nicamente se ejecutan una vez, al
comienzo de la simulacin (cuando la variable Inicializacion toma el valor
TRUE) y se encargan, respectivamente, de colocar toda la memoria a O y leer el
contenido de algunas posiciones de un fichero de texto. Este ltimo es el mtodo
ms habitual para colocar la memoria en su estado inicial.
Me mo r i a : pr o c e s s ( E s c r i be , Ha bi l i t a Me m, Da t o )
v a r i a bl e Me mo r i a : t Me mo r i a ;
v a r i a bl e I ni c i a l i z a c i o n: bo o l e a n : = t r ue ;
v a r i a bl e i : na t ur a l
pr o c e dur e I ni c i a l i z a ( Me mo r i a : i no ut t Me mo r i a ) i s
be gi n
f o r i inO t o P a l a br a s - l l o o p
Me mo r i a ( i ) :=O;
end l o o p;
end I ni c i a l i z a ;
pr o c e dur e L e e He x a de c i ma l ( F i c he r o : ins t r i ng; v a r i a bl e L i ne a : i no ut l i ne ;
Ci f r a s : in na t ur a l ; v a r i a bl e Va l o r :
i Do ut i nt e ge r ) i s
v a r i a bl e Ca r a c t e r c ha r a c t e r ;
be gi n
Va l o r :=O;
f o r i in1 t o Ci f r a s l o o p
r e a d( L i ne a , Ca r a c t e r ) ;
i f ( Ca r a c t e r >= ' O' and Ca r a c t e r <= ' 9' ) t he n
Va l o r :=Va l r * 16 ' + c ha r a c t e r ' po s ( Ca r a c t e r ) -
c ha r a c t e r ' po s ( ' O' ) ;
e l e i f ( Ca r a c t e r >= ' A' and Ch a r a c t e r <; : : : ' F ' ) then
Va l o r := Va l o r 1 6 + c h a r a c t e r ' p o s ( Ca r a c t e r ) -
c h a r a c t e r ' p o s ( ' A' ) + 10;
e l e i f ( Ca r a c t e r >= ' a ' and Ch a r a C, t e r <= ' f ' ) then
Va l o r := Va l o r 1 6 + c h a r a c t e r ' p o s ( Ca r a c t e r ) -
c h a r a c t e r ' p o s ( ' a ' ) + 10;
e l s e
a s s e r t f a l s e
r e p o r t " E r r o r de sintax.s en e l f i c h e r o : " &F i c h e r o
e n d i f ;
e nd l o o p ;
end L e e He x a d e c i ma l ;
p r o c e d u r e Ca r g a F i Ch e r o ( Me mo r i a : i n o u t t Me mo r i a ; Na mb r e F i c h e r o : in s t r i n g ) is
f i l e F t e x t i e i n F i c h e r o ;
v a r i a b l e L i n e a
v a r i a b l e i Di r e c c i o n
v a r i a b l e Ca r a c t e r
Un e ;
i h t e g ~r
c h a r a c t e r ;
b e g i n
Wh i l e n o t e n d f i l e I F ) l o o p
i Di r e c c i o n :=';
redl i n e W, L i n e a r ;
L e e He x a d e c i ma l t r i c h ~i o , L i n e a , 2, i Di t e c c i o l ) ;
r e a d ( L i n e a , Ca r a c t e r ) ;
i f ( Ca r a c t e r ' ! : i " ' ) then
a e e e r t f a l s e
r e p o r t " E r r o r d e s i n t a x i s en e l , f i c h e r o : & F i c h e r o
s e v e r i t y f a i l u r e ;
end i f ;
L e e He x a d e c i ma l ( F i c h e r o , L i n e a , 4 , Me mo r i a ( i Di r e c c i o n ;
e nd l o o p ,
end Ca r g a F i c h e r o ; .
b e g i n
i f I n i c i a l i z a c i o n then
I n l c i a l i z a ( Me mo r i a ) ;
Ca r g a F i c h e r o ( Me mo r i a , F i c h e r o ) ;
I n i c i a l i z a c i o n := F AL S E ;
Da t o <= ( o t h e r e => 'Z'),
e nd i f ;
i f Ha b i l i t a Me m' e v e n t t b e n
ifHa b i l i t a Me m = ' 1 ' and E s c r i b e = ' 1 ' t b e n
Da t o <= c o n v _ s t d _ l o g i c _ v e c t o r ( . Me mo r i a ( c o n v _ i n t e g e r
( u n s i g n e d ( Di r e c c i o n ) ) ) ) Bi t s P a l a b r a ) a f t e r T Ac c e s o ;
e l e i f Ha b i l i t a Me m = ' O' o r Ha b i l i t a Me m = ~Z' then
i f E s c r i b e = ' 1 ' o r E s c r i b e = ' Z ' then i
Da t o <= ( o t h e r e => ' Z' ) a f t e r T Da t o Va l i d o ;
e l e e
Me mo r i a ( c o nv _ i nt e ge r ( uns i gne d( Di r e c c i o na l ) f:
c OI l V_ i nt e ge r ( uns i gne d( Da t o
e ndi f ;
e ndi f
e ndi f ;
e nd pr o c e s s Me mo r i a
LISTADO 5-42. Modelo detallado de la memoria RAM.
Durante el funcionamiento normal de la memoria, el proceso se activar ni-
camente cuando se detecte un evento en la seal Habili taMem. En ese caso, de-
pendiendo del valor de la seal Escribe, se efectuar la operacin de lectura o
escritura sobre la variable que modela la memoria (Memoria), siempre que la se-
al Habili taMemest activa.
5.5.4.3.4. Verificacin temporal
Una de las maneras ms utilizadas para modelar la verificacin temporal consiste
en definir un conjunto de procedimientos concurrentes, que supervisan la sincroni-
zacin entre las diferentes seales, sin afectar por ello asufuncionamiento. Sinem-
bargo, esta tcnica puede resultar costosa en tiempo de simulacin, puesto que el
rendimiento disminuye conforme aumenta el nmero de procesos que pueden eje-
cutarse concurrentemente.
Para facilitar la reutilizacin de estos procedimientos en otros modelos los
agruparemos en un nuevo paquete (VerificacionTerrporal). En el paquete sehan
incluido los procedimientos necesarios para verificar:
el tiempo deestablecimiento deuna seal respecto aotra(VEstablecinento)
el tiempo demantenimiento deuna seal respecto aotra (1I2I1anteninento)
las anchuras mnimas delos pulsos deun ciclo (vCiclo).
El siguiente listado muestra solamente el cdigo correspondiente a la primera
funcin, puesto que las dems son muy similares.
pr o c e dur e VE s t a bl e c i mi e nt o (
s i gna l Se ny a l :
c o ns t a nt No mbr e Se ny a l :
s i gna l Se ny a l Re f :
c o ns t a nt No mbr e Se ny a l Re f :
c o ns t a nt Co nd . c . o m'
c o ns t a nt T i e mpo E s t a bl :
be gi n
i f Se ny a l Re f ' e v e nt and Co ndi c i o n then
a s s e r t ( ( no w - Se ny a l ' l a s t _ e v e nt ) >= T i e mpo E s t a bl )
r e po r t ' Vi o l a c i o n de s e t uP e n &Na mbr e 6e ny a l &
" r e s pe c t o a ' &No mbr e Se ny a l Re f
ins t d_ l o gf C
in s t r i ng
in s t Cl _ l o gi c
in s t r i ng
in bo o l e a n;
in time) 18
severity warning;
end if;
end VEstablecimiento;
LISTADO 5-43. Funcin de verificacin del tiempo de establecimiento.
Utilizando las funciones de este paquete, la verificacin temporal de nuestra
memoria RAM serealizar mediante los cuatro procesos siguientes:
VCiclos: process(HabilitaMem)
begin
if HabilitaMem'event then
if HabilitaMem " '1' then
VCiclo(HabilitaMem, "HabilitaMem",TPrecarga,O ns);
else '
if (Escribe = '1') then
VCiclo(HabilitaMem, "HabilitaMem' ,O ns, TPulsoLl ;
elee
VCiclo(HabilitaMem, "HabilitaMem', O ns, TPulsoE);
end if;
end if;
end if;
end process vci~ls_
- Establecimiento y mantenimiento para las direcciones ~L/E)
VDir: process (HabilitaMem, Direccion)
begin
-- Establecimiento
if Direccion' event then
VMantenimiento (Dir~ion, "Direccion' ,liabilitaMern, "liabili taMell\' ,
, ' D.recci.on' stable, 'IMantDir) i
:~.:~p-. j_..;:'. . -_
end if;
-_ Mantenimiento
if HabilitaMem'event aIId HabilitaMem = '1' then
~tablecimiento (Direccion, Direccion ,HabilitaMem, "HabilitaMem' ,
, D~r~ccion'stal:>le,TEstablDir); .
end if;
end process VDir;
Establecimiento y mmtenimiento para los' datos (E)'
VDatos: proceSS(HabilitaMem,Es~ribe,Dato)
begin
-- MaItenWento
if Dato' eVent aIId sscrbe 'O' then
VManteniinierito (Dato, "Dato' ,iIabilitaMem, "HabilitaMem' ,Dato' stable,
TM.!lntDatoJ ;
end if;
-- Establecimiento
i f HabilitaMem'event and Escribe = 'O' then
VEstablecimientoWato, "Dato" ,HabilitaMem, "HabilitaMem",Dato'stable,
TEstablDato) ;
end i f ;
end process VDatoS,
-- Establecimiento de l~seal escri~
VEscribe: process (HabilitaMem, EscribE!)
begi n
i f HabilitaMem'event and HabilitaMem = '1' then
i f EScribe = '1' then
VEstablecimiento(Escribe,"Escribe,HabilitaMem,"HaQilitaMem",
Escribe'stable,TEstablL);
else
VEstablecimiento(Escribe, "Escribe" ,HabilitaMem, "HabilitaMem',
Escribe'stable,TMantDit~;
end i f ;
end 1f;
i f Escribe'event and Escribe = '0' then
VEstablecimiento (Escribe, Escrtbe.", ~ilitaMem, 'HabilitaMem',
. Escri~;stable>'EstablE);
end i f ;
end process VEscribe;
LISTADO 5-44. Modelado de la verificacin temporal en la memoria RAM.
5.6. EJERCICIOS
1. En ladescripcin funcional del procesador no seincluye ninguna informacin
acerca del tiempo que tarda cada instruccin en ejecutarse. Sin embargo, a
pesar dequenoexiste una seal dereloj respecto alacual definir ciclos, podra
almacenarse un hipottico. nmero de ciclos relacionado con cada cdigo de
operacin y, suponiendo un tiempo arbitrario para la duracin de un ciclo,
reflejar esta informacin en el tiempo de espera entre laejecucin de dos ins-
trucciones. Modifique los tipos de datos existentes y aada los necesarios para
poder almacenar lainformacin relativa alos ciclos de cada cdigo de opera-
cin. Posteriormente aada las variables y realice las modificaciones necesarias
enel cdigo parareflejar estainformacin enlasimulacin.
2. La descripcin funcional del procesador podra haberse realizado suponiendo
queel nmero debits delos registros y los datos sonconocidos enlugar deuti-
lizar el tipo integer. Aada dicha informacin enforma deconstante enel pa-
quete PaqueteMRFuncional y modifique los tipos de datos que puedan hacer
uso deella. Modifique laarquitectura del procesador deacuerdo conlos nuevos
tipos dedatos.
3. El hecho de almacenar el programa y los datos en una variable en la descrip-
cin funcional del procesador nos obliga a reanalizar la arquitectura cada vez
que queremos simular laejecucin deun programa distinto. Esto podra evitar-
se si en la etapa de inicializacin de las variables al principio del cuerpo del
proceso se leyera el contenido de las variables Programay MemDatosde un
fichero. Escriba los procedimientos necesarios para que esto sea posible y util-
celos en el cuerpo del proceso para inicializar las variables.
4. Como hemos visto, la arquitectura PrimeraParticion del procesador no mo-
delaba con precisin los cambios en la seal Inicializa que entra al procesa-
dor. Incluya las sentencias de control necesarias para que los procesos respon-
dan a una activacin de esta seal en cualquier momento y en no ms de un
ciclo de reloj se abandone la ejecucin de instrucciones y las variables y sea-
les tomen suvalor inicial.
5. La arquitectura Funcional del banco depruebas en el Listado 5-20 concede de
forma inmediata el bus de memoria al procesador siempre que ste lo solicita
de forma que no se verifica el caso en que el procesador deba esperar varios
ciclos antes derealizar una lectura o escritura. Para hacer un poco ms exhaus-
tiva la verificacin, modifique el proceso Arbi troBus de dicha arquitectura
para que exista untiempo deespera entre lapeticin debus por parte del proce-
sador y la activacin de la seal BusLibre. Adems, haga que este tiempo de
espera vare deunciclo aotro.
6. Las funciones del procesador que se repiten cclicamente, como los accesos al
bus de memoria, tienen una relacin causa-efecto y un orden en la activacin
delas seales que deben cumplirse para todos los ciclos. En estos casos es fcil
escribir un proceso en el banco de pruebas que verifique estas propiedades.
Escriba un proceso pasivo, es decir, que no asigne ninguna seal sino que slo
las lea, que compruebe los accesos amemoria del procesador.
7. Escriba un proceso similar al del ejercicio anterior pero que verifique que des-
pus de una instruccin de LOAD se realiza una lectura a memoria y que
despus de una instruccin de STORE se realiza una escritura. Para ello ser
necesario que el proceso observe las instrucciones que pasan por el bus de
datos hacia el procesador y pueda distinguir el tipo deinstruccin.
8. Una vez hemos realizado la comprobacin de la simulacin de forma visual,
podramos preparar un esquema de comprobacin automtica para que cuan-
do se realicen modificaciones en el modelo del procesador poder ver que
sigue comportndose de igual forma. Escriba un proceso en el banco deprue-
bas que acada ciclo de reloj escriba los estmulos que se aplican alas entra-
das del procesador y los valores alas salidas correspondientes alos estmulos
aplicados en el ciclo anterior. Posteriormente podremos verificar la descrip-
cin comparando el fichero de lanueva simulacin con el de la simulacin ya
verificada.
9. Integre lafuncionalidad delos componentes sumador y restador del modelo es-
tructural dela UAL en uno slo. Sintetice ambas versiones delaunidad opera-
tiva y compare los resultados en trminos de rea y velocidad de ambas imple-
mentaciones.
10. Sustituya el componente ROM de la implementacin cableada de la unidad
decontrol por una PLA. Para ello obtenga, apartir del diagrama de estados de
dicha unidad, y laTabla 5-8, las ecuaciones combinacionales correspondientes,
desarrolladas en forma desuma deproductos.
11. Modifique el modelo funcional de la memoria RAM de programas, de manera
que, atravs del valor de un parmetro adicional, pueda desactivarse la verifi-
cacin temporal.
12. Utilice un solo proceso para modelar lamemoria RAM deprogramas, en el que
seincluya tanto lafuncionalidad como laverificacin temporal. Simule el siste-
ma y compruebe cmo la reduccin del nmero de procesos mejora el rendi-
miento.
5.7. BIBLIOGRAFA
[AG93] J . R. ARMSTRONGy F. GAIL GRAY:Structured Design with VHDL, Prentice-Hall,
1997.
[AB09O] R. AlRIAU, J . M. BERG,V. OLNE y J . ROUll..LARD:VHDL du langage a la modli-
sation, Presses polytechniques et universitaires romandes, 1990.
[Ash96] P. ASHENDEN.The Designers Cuide to VHDL, Morgan Kaufmann Publishers, 1996.
[Co93] D. R. COELHO:The VHDL Handbook, K1uwer Academic Publishers, 1993.
[Hay88] J . P. HAYES: Computer Architecture and Organization, McGraw-Hill, 1988.
[STA97] W. STALUNGS:Organizacin y Arquitectura de Computadores. Diseo para Opti-
mizar Prestaciones, Prentice-Hall, 1997.
[SPC97] F. SNcHEZ, E. PASTORY A. M. DELCORRAL(Ed: R. Hermida): Fundamentos de
Computadores (Captulos 6 y 7 del libro), Sntesis, 1997.
Captulo
LA GESTION
-
DEL DISENO
6
Y. Torroja, T. Riesgo, E. de la Torre, J. Uceda
Un error conocido
es una victoria ganada.
Annimo
En los captulos precedentes se ha mostrado cmo utilizar el VHDL y la
sntesis automtica para disear un circuito. Hasta el momento, el en-
foque ha sido fundamentalmente tcnico. Se han visto los diferentes
elementos del lenguaje VHDL, distintas maneras de describir el funcio-
namiento de un circuito, cmo realizar bancos de prueba, etc. Sin em-
bargo, el proceso de diseo en VHDL requiere un estudio no slo de
los aspectos tcnicos del diseo, sino tambin de los organizativos.
A menudo el diseador encuentra que tiene que realizar un buen
nmero de tareas adicionales a lo que es la mera descripcin del cir-
cuito en VHDL. Al enfrentarse a un diseo real, debe resolver proble-
mas relacionados con la planificacin del trabajo, la documentacin
del diseo, las herramientas que est utilizando, la organizacin de los
archivos, surelacin con el posible cliente, etc.
En el presente captulo se pretende dar una visin general de cules
son estas tareas y qu problemas conllevan. Se presenta el proceso de
diseo de un circuito, desde su concepcin hasta su fabricacin, mos-
trando cmo obtener el mejor partido de la utilizacin del VHDLen este
proceso. El objetivo del captulo es concienciar al lector de que el dise-
o de un circuito en VHOLno consiste slo en escribir cdigo, sino que
existen otros muchos aspectos a tener en cuenta, y que slo una buena
organizacin del diseo puede garantizar el xito final del mismo.
349
350 VHDL. Lenguaje estndar deDiseo Electrnico
6. 1. INTRODUCCIN
Hasta la aparicin delos lenguajes dedescripcin del hardware y, especialmente,
delas herramientas desntesis lgica, el proceso dediseo decircuitos integrados
estaba basado fundamentalmente en la utilizacin de esquemticos. Las he-
rramientas dediseo disponan (y siguen disponiendo) depotentes editores gr-
ficos con los querealizar un esquema del circuito, bien fuesemediante bloques o
mediante puertas.
El diseo deun circuito con estas herramientas consista principalmente en un
proceso dediseo ascendente (bottom-up). En esteprocedimiento, el diseador de-
ba hacer sobreel papel una particin del circuito en bloques o unidades funciona-
les basndose en suexperiencia previa. Cada uno deestos bloques era asuvez divi-
dido en unidades ms pequeas hasta alcanzar una complejidad manejablepara rea-
lizar surepresentacin en un esquema.
As, por ejemplo, un circuito detransmisin/recepcin seriepoda ser dividido
en el transmisor, el receptor y un bloquedecontrol. Definidas las seales decontrol
y los datos quehabran decomunicarse entreestos bloques, cada uno deellos sedi-
vidira en subbloques ms pequeos. El transmisor, por ejemplo, podra quedar di-
vidido en un generador del reloj detransmisin, una unidaddecontrol con algunos
registros programables para configurar el modo detransmisin, un bloquedeinter-
faz con el exterior con algn registro temporal para el dato atransmitir y un ltimo
bloquequeseencargara deformatear el dato y dehacer la conversin paralelo/se-
riepara sutransmisin.
Realizada esta particin comenzara el diseo dedetalle decada uno deestos
bloques. Mediante un editor deesquemticos el diseador ira dibujando el esque-
ma lgico delos bloques, dibujando puertas einterconectndolas y apoyndose se-
guramente en pequeos bloques funcionales previamente diseados (registros para-
lelos, registros serie, biestables con habilitacin, etc.).
Una vez diseado un bloque, stepodra ser simulado. El diseador deba en-
tonces utilizar un lenguaje o herramienta especfica del entorno dediseo para de-
finir los estmulos (las formas deonda) con las quecomprobar el funcionamiento
del bloquerecin diseado. Comprobado estebloque seprocedera al diseo delos
dems bloques con el mismo procedimiento. Una vez diseados todos los bloques
seinterconectaran entres para formar un bloque mayor (p. ej., el transmisor) y se
procedera a su simulacin, repitiendo este proceso hasta completar el circuito
completo.
El problema fundamental deestemtodo dediseo es queno era posiblesimu-
lar el comportamiento completo decada uno delos bloques hasta no haber diseado
los subbloques quelo integran. A menudo el diseador encontraba quela particin
realizada, las seales decomunicacin entrecada uno delos bloques, la especifica-
cin, o supropio entendimiento delo quedeba ser el funcionamiento deun bloque
no eran los adecuados. Esto poda requerir deun rediseo total o parcial dealguno
o varios delos bloques, o incluso deuna nueva particin del circuito. Para resolver
estos problemas seincluan a menudo funcionalidades en los bloques queno eran
estrictamente necesarias, serepeta lgica queya estaba en algn otro bloque. o se
realizaban complicados protocolos decomunicacin entrebloques.
6. La gestin del diseo 351
Por tanto, el proceso de diseo resultaba engorroso y las modificaciones, la de-
puracin y el mantenimiento del diseo complejos de realizar. Una mala planifica-
cin del diseo podra hacer, por ejemplo, que se repitiesen los bloques de genera-
cin del reloj del transmisor/receptor planteado como ejemplo. Si, por otro lado,
tras el proceso de diseo fsico y obtencin de la topografa (layout) se detectaban
errores debidos a retardos o problemas de rea, las modificaciones resultaban com-
plejas y de difcil solucin.
La aparicin de los HDLs (Hardware Description Languages, o lenguajes de
descripcin del hardware) y de las herramientas de sntesis lgica ha venido a paliar
en gran medida estos problemas. Por una parte, ha liberado al diseador de la tedio-
sa, y a menudo repleta de errores, tarea de diseo lgico, que queda a cargo de las
herramientas de sntesis. Por otro lado, y ste es quizs el aspecto ms importante,
permiten al diseador utilizar un mtodo de diseo descendente (top-down). Con
este proceso de diseo el diseador puede simular el comportamiento del circuito
completo antes de realizar la particin y entrar en el detalle del diseo de cada uno
de los bloques. Realizando un modelo funcional sencillo de un bloque, el diseador
puede comprobar que la integracin de ste en el resto del sistema es la adecuada.
La inclusin de nuevas seales de comunicacin con los dems bloques, o nueva
funcionalidad, puede realizarse de una manera mucho ms sencilla y a menor coste.
El diseador va definiendo, describiendo y, lo que es ms importante, simulando el
comportamiento deseado para cada una de las partes. Posteriormente entra en el de-
talle de cmo realizar, mediante la lgica adecuada, un circuito que se comporte tal
como lo hacen los modelos que ha realizado.
Sin embargo, como veremos, los HDLs en general, y el VHDL en particular,
no son la panacea del diseo. Existe una notable diferencia entre las posibilidades
tericas y reales que los HDLs y la sntesis automtica ofrecen. El diseador se en-
frenta a nuevos problemas debidos fundamentalmente a la integracin de las nuevas
herramientas en los entornos de diseo y al aumento de la complejidad de los cir-
cuitos que estas herramientas permiten realizar.
A continuacin se describen brevemente cules son los nuevos problemas a
los que el diseador tiene que enfrentarse, comparando lo que sera un proceso
ideal de diseo basado en VHDL y sntesis automtica y la realidad. Posteriormen-
te, el resto del captulo estar dedicado a proponer procedimientos y mtodos que
permitan paliar, en la medida de lo posible, los efectos negativos que estos proble-
mas inducen.
6.1.1. Un proceso ideal de diseo en VHDL
En un proceso de diseo ideal en VHDL el diseador debera disponer de unas es-
pecificaciones estables. Esto evitara modificaciones constantes en el proceso de di-
seo que aumentan en gran medida el coste del desarrollo. En el mejor de los casos,
el diseador podra disponer de un modelo simulable en VHDL del entorno en el
que el circuito va a estar incluido. De esta manera, el diseador siempre dispondra
de un banco de pruebas realista con el que poder simular su diseo a lo largo del
proceso de desarrollo.
Las herramientas dediseo deberan permitir al diseador disponer demodelos
VHDL de su diseo alo largo de todo el proceso. Por ejemplo, tras la sntesis, dis-
pondra de un modelo VHDL estructural del circuito en puertas, que le permitira
realizar la simulacin del circuito con los mismos bancos de prueba que utiliz en
las etapas previas del proceso dediseo, y considerando las caractersticas reales de
los componentes (retardos, consumo, etc.). Para ello, las bibliotecas del fabricante
dispondran demodelos VHDL detallados detodos sus componentes.
Por otro lado, las herramientas de sntesis tendran en cuenta la biblioteca del
fabricante para seleccionar, en cada caso, el componente ms adecuado para rea-
lizar la funcionalidad especificada por el diseador, teniendo en cuenta el coste
y las prestaciones. Las macroceldas (memorias RAM, ROM, multiplicadores,
PLAs, etc.), segeneraran deforma automtica cuando fuesen necesarias, y sus mo-
delos VHDL se integraran bajo el diseo para poder simular, de forma sencilla, el
circuito completo.
Por ltimo, si el diseador sededicase alas tareas dediseo fsico hara laubi-
cacin y el conexionado (place &route), para obtener la topografa, tras lo cual
realizara una simulacin del circuito final, todo sin salirse del entorno VHDL al
que est acostumbrado. Las modificaciones que, por cualquier razn, el diseador
realizase sobre el circuito final (un inversor puesto a ltima hora para corregir la
polaridad deuna seal, una modificacin delatopografa para corregir retardos, et-
ctera), quedaran retroanotadas en el diseo, deforma que su efecto seviese refle-
jado en los distintos modelos VHDL que se hubieran ido obteniendo segn se fue
depurando el diseo.
6.1.2. El proceso real de diseo en VHDL
Aunque larealidad no dista mucho del esquema arriba mostrado, s lo hace en pun-
tos devital importancia, que suelen dar al traste con lo que seraun proceso dedise-
o fluido y sincomplicaciones.
Por un lado, las especificaciones nunca son estables. A menudo la idea del di-
seo sufre cambios alo largo del proceso de desarrollo que obligan arehacer parte
del diseo. Por otro, no es frecuente que el diseador disponga de modelos simula-
bles del entorno, lo que leobliga adesarrollarlos, duplicando el trabajo y las fuentes
de errores. Adems, la complejidad alcanzada en los diseos actuales hacen ne-
cesaria una importante tarea adicional de gestin global del diseo que hasta ahora
se daba en contadas ocasiones. Los equipos de diseo que es necesario coordinar
suelen ser mayores y, a menudo, formados por personas que trabajan en distintos
centros.
La misma complejidad de los circuitos obliga ahacer unos bancos de prueba
cada vez mas sofisticados. La propia validacin de la funcionalidad sevuelve una
tarea compleja debido al gran nmero de modos de funcionamiento de los circui-
tos y de solicitaciones a los que se les somete. El tiempo de simulacin se con-
vierte entonces en uno de los principales problemas para el diseador, que tiene
que esperar a que terminen largas simulaciones para analizar los resultados. Es
frecuente, como ocurre en el caso del diseo deun microprocesador, que el mode-
lo desimulacin del circuito tenga que ejecutar largos programas en un entorno vir-
tual para verificar sus respuestas ante situaciones que deotra manera seran difciles
de comprobar (p. ej., cmo responde un microprocesador a un sistema operativo
multitarea).
Adems, laintegracin delas herramientas bajo un mismo entorno no slo deja
quedesear, sino que, en muchos casos, est desapareciendo como concepto. Actual-
mente, distintos vendedores deCAD estn ofreciendo herramientas que cubren dis-
tintas partes del proceso de diseo; especificaciones, diseo arquitectural, sntesis,
diseo fsico, etc. La tendencia actual es que estas diferentes herramientas inter-
cambien informacin entre ellas a travs de un lenguaje comn (VHDL o Verilog
en la mayora de los casos), pero esto es algo que dista mucho de estar completa-
mente resuelto. Generalmente, los subconjuntos del lenguaje que entienden unas y
otras herramientas no son los mismos, teniendo querealizarse tediosas tareas detra-
duccin para intercambiar informacin entre ellas. En estos casos, se dificulta an
ms la retroanotacin de las modificaciones hechas en una etapa posterior del pro-
ceso dediseo sobre los datos deetapas anteriores.
Por ltimo, puesto que los circuitos electrnicos yano aportan, depor s, valor
aadido aun producto, sino que es su funcionalidad laque les daese valor, el cos-
tede diseo seha vuelto un factor importante en el coste final del producto, coste
que es necesario reducir. Esto obliga areutilizar parte de los diseos realizados, lo
que, a su vez, requiere poner un cuidado especial en la manera de disear. Los di-
seos deben realizarse de forma que otros diseadores puedan entenderlos y modi-
ficarlos con poco esfuerzo para adaptarlos a sus necesidades. Esto requiere tam-
bin que sepreste una atencin especial ala documentacin del diseo, que acaba
siendo un porcentaje no despreciable del tiempo dedicado al desarrollo de un dis-
positivo.
6.1.3. Orientacin y objetivos del captulo
En los siguientes apartados sepropondrn mtodos y procedimientos que ayuden a
paliar los problemas planteados, mostrando los puntos donde aparecen conflictos y
ayudando aextraer las mximas ventajas del proceso dediseo basado en VHDL y
sntesis automtica.
En primer lugar, seexponen, con cierto detalle, las diferentes tareas que un di-
seador ha de llevar a cabo para realizar un diseo, desde el planteamiento de la
idea hasta la fabricacin del circuito. El proceso de diseo mostrado pretende dar
una idea de los pasos a seguir y los problemas que pueden aparecer, aunque debe
ser entendido como un esquema general. Este esquema debera adaptarse a las ca-
ractersticas del equipo de diseo, tanto desde el punto de vista de las herramientas
disponibles como de la experiencia de los diseadores y la propia complejidad del
diseo a realizar. Posteriormente se detallan aspectos relativos a la organizacin,
gestin y desarrollo de las bibliotecas de componentes, donde deben quedar archi-
vados los diferentes elementos que sevan realizando durante el diseo. Por ltimo,
seexponen mtodos para realizar diseos que sean fcilmente reutilizables. Sedeta-
llarn cules son los problemas que surgen al reutilizar un componente previamente
diseado y seexplicarn dos procedimientos (diseo genrico y configurable) para
realizar diseos reutilizables. En los ejemplos y explicaciones sehaconsiderado, en
general, que se estn realizando diseos sncronos. La realizacin de diseos asn-
cronos, aunque conceptualmente similar, presenta particularidades que dificultaran
el seguimiento del texto. Por otro lado, lagran mayora delos circuitos que sedise-
an en laactualidad son sncronos.
Este captulo est orientado no slo hacia personas que comienzan autilizar el
VHDL y lasntesis automtica, sino tambin aaquellos que yaposeen alguna expe-
riencia en diseo. El contenido deeste captulo no es, ni mucho menos, exhaustivo.
Si sedesea una informacin ms detallada sobre estos temas puede recurrirse adis-
tintas referencias de la bibliografa, en especial ala metodologa PRENDA para el
diseo deASICs.
6.2. PLANIFICACIN DE UN DISEO DESCENDENTE
En el presente apartado seplantea, en primer lugar, lo que podra ser un flujo dedi-
seo tpico aplicado al desarrollo mediante VHDL yherramientas desntesis lgica,
describiendo brevemente las tareas arealizar en cada etapa. A continuacin seentra
en detalle en cada una de las etapas que componen el proceso de diseo. Se mues-
tran cules son los objetivos de cada etapa y cmo llevarlos acabo, pormenorizan-
do los problemas que amenudo aparecen durante el diseo. Sepresta especial aten-
cin a los procedimientos para controlar que en cada etapa se realicen las tareas
adecuadas y que no se omitan pasos que luego pudieran obligar auna vuelta atrs.
Como se ha explicado en la introduccin al captulo, la documentacin del diseo
es un aspecto crucial en el desarrollo de cualquier proyecto, por lo que es tratada
con cierta profundidad.
Se ha procurado mostrar, mediante ejemplos concretos, cmo aplicar las re-
comendaciones dadas al desarrollo de uncircuito, especialmente cuando estas reco-
mendaciones afectan ala escritura del cdigo VHDL o a su sntesis. Los ejemplos
mostrados se han llevado a cabo utilizando herramientas de simulacin y sntesis
comerciales, y podran no ser aplicables en todos los casos. De cualquier manera,
stos deben servir como gua para que el lector adquiera una visin general de los
problemas y de cmo solucionarlos; la adaptacin de estos ejemplos a sus herra-
mientas concretas no debe suponer ungran esfuerzo.
Conviene tener en cuenta que la aplicacin de un flujo de diseo requiere un
esfuerzo adicional al puramente tcnico. Es necesario valorar la complejidad del
circuito antes de considerar la aplicacin delos procedimientos que semuestran en
este apartado. El diseo de un circuito pequeo (2.000 o 3.000 puertas), realizado
por un solo diseador, puede no requerir este tipo deprocedimientos, aunque siem-
pre es conveniente llevar un cierto control sobre el proceso. En un diseo algo ms
grande (10.000 a20.000 puertas), generalmente llevado acabo por ms de un dise-
ador, la aplicacin de estos mecanismos suele aportar ms ventajas que inconve-
nientes. Por ltimo, en diseos mayores ocrticos, donde el nmero departicipantes
y complejidad aumenta, el seguimiento detallado de un flujo de diseo es la nica
manera dellevar abuen trmino el desarrollo.
De cualquier manera, siempre resulta interesante conocer los problemas que
suelen surgir durante el desarrollo de un circuito integrado, con objeto de identifi-
carlosatiempo y aplicar las acciones correctivas que sean necesarias.
6.2.1. El flujo de diseo
El desarrollo de un circuito integrado, como el decualquier otro producto, requiere
que se vayan realizando diferentes tareas. Desde la concepcin de la idea hasta su
materializacin final, el circuito va pasando por diferentes fases en las que se van
definiendo, cada vez con ms detalle, los diferentes componentes del circuito. Al
principio separte de una idea muy general de lo que sequiere hacer y esta idea se
vadepurando alo largo del proyecto hasta conseguir el resultado deseado.
El flujo dediseo establece las etapas que sedeben cubrir y las tareas arealizar
en cada etapa, as como las herramientas y mtodos para llevar a cabo cada tarea.
Aunque en muchas ocasiones uno no es consciente, todos los proyectos que lleva-
mos acabo, desde hacer una tortilla (si es que se le puede dar la categora de pro-
yecto) hasta disear un superordenador, siguen un proceso de desarrollo ms o me-
nos complejo. No es posible, por ejemplo, que hagamos una tortilla si antes no
hemos batido los huevos, para lo que previamente tendremos que haberlos roto con
cuidado. Tampoco nos quedar muy apetecible si, al frerla, el aceite no est sufi-
cientemente caliente, o si hay demasiado aceite. Siempre podremos calentar el acei-
te despus de batir los huevos, pero ahorraremos tiempo si lo hacemos al mismo
tiempo. El flujo de diseo en este caso es sencillo; abrir lanevera, coger un huevo,
poner acalentar el aceite, batir el huevo (no olvidarse dela sal), frer latortilla (ha-
biendo previsto un plato donde dejarla cuando est hecha), sacarla cuando est a
nuestro gusto, apagar el fuego y finalmente degustarla. Del grado de detalle con el
que sesiga este procedimiento y de lahabilidad del diseador (en este caso el coci-
nero) dependen el xito del proyecto y el tiempo empleado en llevarlo acabo.
Disear un circuito integrado no es, evidentemente, como latarea dehacer una
tortilla (aunque a algunos nos puede resultar ms difcil este proyecto), pero com-
parte con ella muchas caractersticas; las tareas deben estar correctamente secuen-
ciadas, muchas deellas pueden realizarse enparalelo y amenudo cada etapa requie-
re un proceso de evaluacin tras el que se decide si el resultado es o no correcto
(fremos la tortilla hasta que est suficientemente hecha). Algunas etapas son irre-
versibles (latortilla nos qued demasiado hecha) y otras tienen arreglo (si nos que-
damos cortos de sal siempre podemos echar ms al final). Un buen proceso dedise-
o debe considerar todos estos casos para dar la mejor solucin, evitando que se
produzcan situaciones irreversibles.
Existe un gran nmero deflujos dediseo quetienen en cuenta las caractersticas
particulares decadaproyecto. Algunos realizan una gran cantidad detareas en parale-
lo, otros permiten saltar deunaetapaposterior aunapreviaencualquier momento (es-
to no ocurre con latortilla, yaque no es posible batirla una vez hecha), mientras que
en otras ocasiones es necesario cerrar completamente una etapa antes decomenzar la
siguiente. En el caso del desarrollo deun circuito integrado, un flujo dediseo como
el mostrado enlaFigura6-1dabuenos resultados enlamayoradelasocasiones.
: " " - - - - - - - _ . - . . . t
FIGURA 6-1. Flujodediseodeuncircuito integrado,

Et apa de requisit os: est a es la primera et apa del proyect o. En ella, la idea
inicial de lo que se quiere realizar se conviert e en un document o preliminar
que sirve de base para evaluar la viabilidad t cnica y econmica del mismo.
Est a es una et apa de arranque. A menudo es realizada conjunt ament e por el
client e (quien encarga el desarrollo de un circuit o) y el diseador.
Et apa de especificaciones: analizada la viabilidad de la idea, t ant o desde
su punt o de vist a t cnico como econmico, y det erminada con ms o menos
det alle la funcionalidad inicial del circuit o, se pasa a la et apa de especifica-
ciones. El objet ivo de est a et apa es ident ificar con det alle, y document ar
convenient ement e, t odas las funciones que debe realizar el circuit o. Se de-
t erminan el nmero de ent radas/salidas, la t ensin de aliment acin, los blo-
ques que componen el circuit o y su funcionalidad, et c. En algunos casos se
desarrollan u obt ienen durant e est a et apa modelos VHDL del ent orno don-
de va a t rabajar el circuit o . . En proyect os de ciert a envergadura se define
adems el mt odo de t rabajo, las herramient as a ut ilizar, la part icin del t ra-
bajo, et c.
Etapa de diseo arquitectural: esta es normalmente laprimera etapa dedi-
seo enVHDL. Tras llevar acabo laparticin del circuito en bloques funcio-
nales manejables, el diseador los describe en VHDL y los simula. Durante
esta etapa sedesarrollan otros elementos fundamentales del diseo: los ban-
cos deprueba. stos sern utilizados repetidamente en todas las etapas poste-
riores del desarrollo. La etapa de diseo arquitectural es, generalmente, la
etapa ms crtica del proyecto, por lo que amenudo tambin es la ms larga
y laque ms esfuerzo requiere.
Etapa de diseo lgico o detallado: esta etapa est orientada fundamental-
mente ala sntesis del circuito. Para ello puede ser necesario realizar modifi-
caciones en el cdigo VHDL desarrollado, con objeto de adaptarlo a las
herramientas de sntesis disponibles o de corregir soluciones del diseo
arquitectural que sean inadecuadas en cuanto area o retardos. A menudo es
necesario que exista cierta interaccin entre laetapa dediseo arquitectural y
lgico, demanera que los resultados dela sntesis ayuden atomar decisiones
en cuanto al diseo arquitectural del circuito. Durante esta etapa tambin se
generan los estmulos para realizar el test defabricacin, si es que ste es ne-
cesario.
Etapa de diseo fsico: finalizadas las tareas dediseo lgico, seprocede al
diseo fsico del circuito. En esta fase selleva acabo laubicacin y conexio-
nado del circuito, se extraen sus caractersticas reales (capacidades parsitas
debidas alas puertas y pistas de interconexin) y se simula el circuito com-
pleto con estos datos. Esto permite obtener resultados realistas en cuanto a
cmo sevaacomportar el circuito.
Etapa de fabricacin: el circuito es fabricado o grabado (si se trata de un
dispositivo programable tipo FPGA o PLD) para obtener unos prototipos. Se
realiza el test defabricacin para comprobar que stahasido correcta.
Etapa de validacin: con los prototipos del circuito serealiza la validacin
final del diseo, comprobando que sufuncionamiento es el adecuado una vez
instalado en el sistema final. De ser as, sepuede pasar alaproduccin en se-
rie del diseo. Tambin serealiza en esta etapa la caracterizacin del circui-
to, para poder as elaborar las hojas decaractersticas del mismo.
Este es un flujo de diseo lineal. Cada etapa requiere un proceso de revisin,
tras el cual sedecide si sepasa o no alaetapa siguiente. Si el resultado no seconsi-
dera satisfactorio, habr que volver aentrar en la etapa para hacer las modificacio-
nes necesarias hasta que el resultado seael deseado. Este flujo dediseo resulta, sin
embargo, demasiado rgido para la mayora de los diseos de circuitos. A menudo
es necesario conocer caractersticas del diseo que no se sabrn con detalle hasta
etapas posteriores. El coste final del circuito podra ser, por ejemplo, el factor fun-
damental deun proyecto, pudiendo llegarse aeliminar o aadir ms lgica al circui-
to en funcin deesto, pero el coste final no seconoce con detalle hasta que sereali-
zael diseo fsico. Esto implicara un proceso cclico en el que hay que terminar el
diseo antes desaber lo que finalmente vaaincluir el circuito. Recorrer formalmen-
tetodas las etapas, entrando y saliendo decada una deellas tras un proceso derevi-
sin, implicara en este caso un coste excesivo, por lo que es necesario plantearse
un flujo de diseo algo ms flexible que permita entrar en una etapa sin haber ter-
minado la anterior. As, podramos empezar con el diseo fsico dealguna parte del
circuito sin haber siquiera completado la etapa de diseo arquitectural (o incluso
antes). De esta manera podramos hacernos una idea del coste final del circuito,
ajustando lafuncionalidad alavista delos resultados.
La Figura 6-2 muestra grficamente esta idea. El grado de solapamiento y la
duracin delas etapas vara segn cada proyecto. Tambin puede apreciarse una ta-
rea global de gestin, que discurre a lo largo de todo el proyecto, y que no estaba
explcita en el flujo dediseo delaFigura 6-1. Disponer deun flujo dediseo flexi-
ble facilita laresolucin de estos problemas, aunque debe existir un cierto compro-
miso entre flexibilidad y control del proceso dediseo.
Un ltimo aspecto importante del flujo dediseo es que permite, cuando sede-
sarrollan circuitos deforma habitual, detectar dnde estn los problemas y corregir-
los en futuros proyectos. Al realizar siempre las mismas etapas y tareas, sepueden
ir identificando aquellos procedimientos que no dan buenos resultados y modificar-
los para corregir sus defectos. Lo importante, entonces, deun proceso de diseo no
es tanto lo bueno que resulte, sino que pueda reproducirse y corregirse en aquellos
puntos donde no funcione-.
Por ltimo cabe destacar que, en todo flujo de diseo, es necesario buscar los
procedimientos para automatizar, en el mayor grado posible, las tareas a realizar.
Como sehavisto, lamayora delas tareas que sellevan acabo son cclicas; serepi-
ten una y otra vez hasta alcanzar el resultado deseado. Este proceso cclico es mu-
cho ms acusado durante las etapas dediseo arquitectural, lgico y fsico. En estos
casos es especialmente importante disponer de mecauismos de automatizacin de
las tareas. Durante laetapa dediseo arquitectural, por ejemplo, es muy convenien-
te tener mtodos para realizar la compilacin del cdigo VHDL, su simulacin y
D~se~oarquitectural
Fabricacin I
I Validacin
Gestin del proyecto
FI GURA 6~2. Ejemplo de distribucin temporal de las etapasde diseo de uncir-
cuito integrado.
comparacin de los resultados de forma automtica. Durante la etapa de diseo l-
gico, es adems interesante automatizar los procedimientos desntesis, que amenu-
do requieren un elevado nmero de pasos y condiciones que fijar (retardos mxi-
mospermisibles, rea que sequiere conseguir, etc.).
La automatizacin de las tareas en cada etapa del diseo no slo permite aho-
rrar tiempo al diseador, sino que adems supone una garanta de que no seolvida
ningn paso en el proceso. Por otro lado, los ficheros que amenudo hay que utilizar
paraautomatizar las tareas sirven posteriormente como documentacin de lo que se
hahecho. Esto, asuvez, permitir detectar posibles errores o, si no los hubiera, val-
drcomo ejemplo para posteriores proyectos.
A lo largo delos siguientes apartados hablaremos amenudo del cliente y del di-
seador. Consideraremos como cliente aquella persona o empresa que desea realizar
uncircuito. Es l quien decide cul es lafuncionalidad final que debe incluir el cir-
cuito, decide quin debe disearlo, si el coste es adecuado, quin lo fabricar, etc. El
diseador ser lapersona o equipo depersonas encargados de llevar acabo el desa-
rrollo, escribir el cdigo VHDL, realizar las simulaciones, el diseo fsico, etc.
Cliente y diseador podran ser la misma persona o la misma compaa; lo impor-
tanteno es quin realiza estas tareas, sino tener claro las tareas que hay que realizar.
A menudo, por ejemplo, el cliente seayuda del diseador para escoger al fabricante
olatecnologa delos circuitos, decidir lafuncionalidad que incluir, calcular el cos-
te, etc. En lamayora delos casos, el nmero departicipantes en el proceso dedise-
o de un circuito es mayor. Tenemos al fabricante, los proveedores, los vendedores
deherramientas deCAD, subcontratistas, etc. Sinembargo, para el propsito del ca-
ptulo es suficiente, y ms sencillo, considerar slo las figuras decliente y diseador.
Puede consultarse la bibliografa para obtener informacin ms extensa sobre estos
aspectos.
6.2.2. De los requisitos a las especificaciones
El objetivo de las etapas de requisitos y especificaciones es la definicin de lo que
debe ser el circuito a desarrollar. Esta definicin debe convertir la idea original en
undocumento donde sedetallen las seales que requiere el circuito y su comporta-
miento, tanto desde el punto de vista funcional como desde el punto de vista fsico
(retardos, consumos, frecuencias, etc.).
6.2.2.1. Los requisitos
El desarrollo delos requisitos es, generalmente, una tarea poco formalizada. Depen-
diendo del tipo de proyecto, las caractersticas del circuito pueden estar muy poco
definidas o, por el contrario, pueden conocerse con bastante detalle.
El primer caso responde, normalmente, al desarrollo de un producto nuevo. El
circuito formar parte de un sistema que an est poco definido y que, por tanto, '
puede' modificarse segn sea necesario. Un caso tpico podra ser el circuito para
controlar el expendedor delatas derefresco del ejemplo mostrado en el Apndice 1.
Las funciones que realice el circuito dependern no slo de las necesidades funcio-
nales, sino tambin de coste final y la facilidad de desarrollo. As, por ejemplo, po-
dramos pensar que el expendedor derefrescos pudiese incluir unapantalla devisua-
lizacin donde mostrar los precios ms o menos compleja, aceptar ms o menos ti-
pos demonedas oquepudiera expedir ms deuntipo deproducto enuna solaopera-
cin (jsi sehaintroducido suficiente dinero, claro est!). Escoger una solucin uotra
depende de multitud de factores, y generalmente requiere un anlisis de viabilidad
tcnica y econmica complicado para encontrar la mejor solucin. Este anlisis no
slo incluir los aspectos relacionados con el circuito adesarrollar, sino tambin los
relacionados con el coste de los dems elementos del sistema, la facilidad de fabri-
cacin, lafuncionalidad denuestra mquina respecto aotras queexistan enel merca-
do, etc. El desarrollo de los requisitos consistir entonces en un proceso cclico en
donde la idea inicial se va depurando en funcin de los anlisis que se vayan reali-
zando. El principal objetivo en este caso es identificar, a grandes rasgos, cul es la
funcionalidad bsica que debe realizar el circuito y plasmarla en un documento ini-
cial de trabajo que pueda servir de base para el desarrollo de las especificaciones.
Ms sencillo resulta el desarrollo de los requisitos en el caso deun circuito cu-
yas condiciones de contorno estn ms definidas. Volviendo al ejemplo del expen-
dedor derefrescos, podramos querer desarrollar un circuito para controlar una m-
quina que admitiese cinco tipos demonedas (25, 50, 100,200 y 500 pesetas), cuatro
tipos de refrescos (cola, tnica, naranja y cerveza), cuyos precios pudiesen fijarse
mediante cuatro pulsadores exteriores (evidentemente slo accesibles por el dueo
de la mquina) en unidades de 25 pesetas y que admitiese hasta un mximo de 50
latas por producto. Los precios podran mostrarse mediante un visualizador de tres
dgitos de siete segmentos y los clientes dispondran de cuatro pulsadores para se-
leccionar el producto y un pulsador para la devolucin de monedas. En estos casos
el desarrollo de los requisitos requiere un anlisis menos detallado, puesto que la
funcionalidad bsica est definida.
En cualquier caso, los requisitos deben plasmar enun documento no slo lafun-
cionalidad del circuito, sino tambin el coste estimado del circuito a desarrollar, el
tiempo de desarrollo, su tamao y caractersticas tecnolgicas, como son la tensin
dealimentacin, consumo, temperaturas mximas y mnimas que debe soportar, etc.
Todos estos aspectos quedan recogidos en el Documento de Requisitos, que ac-
ta como texto base para iniciar el proyecto. Si laempresa que va arealizar el pro-
ducto (lamquina derefrescos) no dispone decentro dediseo, este documento se-
rdistribuido entre varios centros de diseo para que hagan una evaluacin tcnica
y econmica del circuito adesarrollar y oferten un presupuesto atravs deuna Pro-
puesta de Desarrollo. Esta propuesta incluye normalmente un plan para el desarro-
llo del circuito, una descripcin delafuncionalidad de lapropuesta presentada, una
estimacin del tiempo de diseo y del coste del desarrollo, estimaciones sobre el
coste final del producto, posibles modificaciones alos requisitos del cliente, etc. En
funcin deesta propuesta el cliente escoger el centro dediseo que ms le satisfa-
gapara llevar acabo el desarrollo.
La Tabla 6-1 muestra los aspectos fundamentales que deben quedar definidos
en el Documento de Requisitos, mientras que laTabla 6-210 hace para laPropuesta
de Desarrollo.
TABLA 6-1. Esquema bsico del documento de requisitos
Documento de requisitos
Presentacin del cliente
Presentacin delaaplicacin
Descripcin delaaplicacin
Mercado
J ustificacin de lanecesidad del ASIC
Posibilidad dereutilizacin del diseo
Descripcin del entorno del ASIC
Descripcin delafuncionalidad del ASIC
Restricciones del ASIC
Documentacin aplicable
A menudo no es necesario seguir un procedimiento tan formalizado para ela-
borar los requisitos. El hacerlo o no depende de la complejidad del proyecto, el ti-
po de cliente, de la concrecin de la idea original y de la experiencia, tanto del
cliente como del diseador, en este tipo dedesarrollos. En cualquier caso, un docu-
mento inicial de trabajo siempre resulta interesante, ya que el desarrollo de la si-
guiente etapa (las especificaciones) es una tarea costosa, y los olvidos y malenten-
didos pueden encarecerla. Como ejemplo, en el Apndice 1se muestra 10 que
podra ser un Documento de Requisitos sencillo para la mquina de refrescos del
ejemplo. Para simplificar la exposicin, supondremos que cliente y diseador son
el mismo departamento de una empresa, por 10 que no se ha elaborado una Pro-
puesta de Desarrollo.
Como se muestra en el ejemplo, muchos aspectos del diseo pueden no estar
an definidos (de hecho, esta ser la situacin ms habitual). En estos casos, con-
viene dejar claramente explcitos los puntos no definidos, de forma que posterior-
mente pueda comprobarse que se ha dado respuesta a todos los interrogantes que
inicialmente tena el proyecto.
TABLA 6-2. Esquema bsico de la propuesta de desarrollo
Propuesta de desarrollo
Descripcin delapropuesta y cumplimiento derequisitos
Plan dedesarrollo preliminar
Cumplimiento deplazos
Mtodos decontrol y verificacin
Coste del diseo y/o fabricacin del ASIC
Alternativas o sugerencias del diseador
La etapa derequisitos, como cualquier otra etapa, tiene un proceso de revisin
final donde seaprueban los requisitos. Sin embargo, larevisin deesta etapa no re-
sulta un proceso tan formal como lo sern las revisiones de las etapas posteriores
del proyecto. Habitualmente, esta revisin consiste en un contrato o acuerdo deco-
laboracin entre el cliente y el diseador, y en un anlisis conjunto del trabajo reali-
zado para limar los ltimos detalles. Esta revisin suele llevarse a cabo mediante
una reunin que, por otro lado, marca el inicio del proyecto.
De cualquier manera, debe verificarse que tras laetapa derequisitos sehan de-
finido y analizado, al menos, los siguientes puntos:
Aspectos tcnicos: funciones bsicas que debe realizar el circuito, estima-
cin del consumo, frecuencia mxima defuncionamiento ytamao.
Aspectos econmicos: estimacin del coste objetivo del producto, coste de
los prototipos y coste del desarrollo.
Aspectos organizativos: planificacin preliminar del proyecto, tiempo de
desarrollo y responsabilidades delos participantes.
6.2.2.2. Las especificaciones
El objetivo delas especificaciones es obtener una descripcin detallada del circuito
adisear, tanto desde el punto de vista funcional (lo que debe hacer, patillaje, etc.),
como desde el punto devista tecnolgico (tecnologa autilizar, tensin dealimenta-
cin, consumo, etc.). Esta es una delas etapas crticas del proyecto; dela precisin
delas especificaciones y delo completo de sucontenido depende en gran medida el
xito del desarrollo. Normalmente, las especificaciones serecogen en el Documento
de Especificaciones. Su redaccin suele quedar a cargo del director del equipo de
diseo, al ser ste habitualmente el componente ms experto del equipo de diseo.
Las especificaciones deben ser completas, claras, concisas y sin ambigeda-
des. Los problemas con las especificaciones surgen, precisamente, debido aimpre-
cisiones, falta o redundancia en la informacin, datos incorrectos o descripciones
ambiguas o difciles de interpretar. La utilizacin de lenguajes de descripcin de
hardware, yen concreto del VHDL, puede ayudar en algunos casos a evitar estas
situaciones. Sin embargo, como se ver, su uso durante esta etapa no resulta senci-
llo, por lo que es necesario disponer de otros mtodos que resuelvan los problemas
planteados.
Unas especificaciones ideales deberan permitir al diseador trabajar indepen-
dientemente del cliente. En la prctica esto nunca es cierto, y tampoco es conve-
niente; una buena comunicacin entre cliente y diseador, tanto anivel tcnico co-
mo empresarial, es lamejor garanta para evitar problemas durante el desarrollo. De
cualquier manera, el tiempo y el esfuerzo invertido en desarrollar unas buenas espe-
cificaciones generalmente revierte en un proceso dediseo ms libre deproblemas.
En los siguientes apartados se comparar lo que seran unas especificaciones idea-
les con lo que suelen ser unas especificaciones reales. Con ello sepretende resaltar
cules son las fuentes de problemas y cmo se pueden limitar sus consecuencias.
6.2.2.2. 1. Unas especificaciones ideales
Los circuitos electrnicos son elementos que, sometidos aciertas solicitaciones ex-
ternas (cambios en sus seales de entrada), reaccionan realizando ciertas acciones
(cambios en las seales desalida). Visto deesta manera, laespecificacin deun cir-
cuito puede entenderse como una descripcin de cul es la secuencia de cambios
quesedebe producir en las seales desalida del circuito ante ciertos cambios en las
entradas. En este sentido, una especificacin podra consistir en una serie de vecto-
res aplicados (conjuntos deunos y ceros) alas entradas y los correspondientes valo-
res esperados a las salidas. Evidentemente, una especificacin de este estilo sera
inutilizable, ya que, aparte de ser ilegible, requerira de infinidad de pginas para
incluir todos los posibles casos.
Utilizando VHDL, sin embargo, es posible especificar casi completamente el
funcionamiento y caractersticas de un circuito. Supongamos, por ejemplo, que de-
seamos especificar un circuito para llevar la cuenta deuna serie de eventos (que se
detectan por un pulso positivo en una entrada al circuito). Una manera de hacerlo
serarealizando una descripcin VHDL del mismo, tal y como semuestra en el c-
digo del Listado 6-1. En este caso, lo que seespecifica es la funcionalidad del cir-
cuito de "patillas adentro", y no cmo debe responder ante una serie de estmulos
deentrada.
library ACME;
use ACME.TiposBasicos.all;
entity mi_circuito is
port (
Evento
Inicia
Reloj
Salida
inbit;
inbit;
inbit;
out inteqer
)
-- Los siguientes atributo&'~f~ algunos aspectos ~ecnolgicos:
attribute tecno~ia of mi.,..circuito : entity is "CMOS-O.Su;
attribute tens~6nVdd of mi'"rcif~~ito : entity is 3.3 ,:
--i ~igUiht'e proceso s'uthik ~ra veriar1a' &ueri~i~
-- del reloj del circuito . . i .
process pruebaReloj{Clock : inbit) ls
variable UltimoCambio : time :=O ns;
begin
assert UltimoCambio - no w ~ 100ns report
"Error: La frecuencia de reloj debe ser 10MHz'
severity WARNING;
if Reloj'event and Reloj = '1' then
.ultimoCambio :=now;
end if;
end PruebaReloj
begi n
P r u eba r el o j ( Rel o j )
ead mi _ c i r c u i t o
a r c h i t ec t u r e E S P E CI F I CACI ON o f mi _ c i r c u i t o i s
s i gna ! Au x Cu ent a : i nt eger
begi n
Cu mt a <= Au x Cu ent a
Cu ent a : p r o c es s
begi n
wa i t u nt i l E v ent o = ' 1 ' ar I ni c i a = ' O'
i f I ni c i a = ' 0 ' t ben
Au x Cu ent a <= O
end i f
wa i t u nt i l E v ent o = ' O' ar I ni c i a = ' O'
i f I ni c i a /= ' O' t ben
i f Au x Cu ent a < 16 t ben
Au x c Uent a <= Au x Cu ent a + 1
el s e
Au x Cu ent a <= O
end i f
endi f ;
end p r o c es s ;
end E S P E CI F I CACI ON
LISTADO 6-1. Especificacin de un circuito mediante descripcin VHDL. Compor-
tamiento interno.
En ladescripcin mostrada es posible leer, con un poco deprctica, cmo debe
funcionar el circuito que se desea realizar. Esta es adems una descripcin simula-
ble, lo que implica que el diseador puede utilizarla para comparar los resultados de
su diseo con los de laespecificacin. La descripcin no hace explcito cmo debe
disearse el circuito (eso es una tarea arealizar durante el diseo arquitectural). De
hecho, seespecifica que debe haber unreloj deentrada de 10MHz, pero no sedeta-
llacmo seutiliza en el circuito.
Se podra tambin especificar el funcionamiento del circuito de "patillas afue-
ra", es decir, mostrando cmo son las salidas que debe dar en funcin de una serie
deentradas. Un ejemplo deeste mtodo semuestra en el Listado 6-2.
ent i t y mi _ es p ec i f i c a c i o n i s
ead mi _ es p ec i f i c a c i o n
a r c h i t ec t u r e P AT I L L AS _ AF UE RA o f mi _ es p ec i f i c a c i o n i s
c a mpo ne t mi _ c i r c ui t o
po r t (
inbi t ;
inbi t ;
inbi t ;
o ut i nt e ge r
Ev e nt o
I ni c i a
Re l o j
S a l i d a
);
e nd c a mpo ne nt ;
s i gna l Re l o j : bi t := '0';
s i gna l EVe nt o : bi t :='0';
s i gna l Cue nt a , NumEv e nt o s : i nt e ge r ;
s i gna l I ni c i a : bi t :='1';
be gi n
Re l o j <=not Re l o j a f t e r 100 ns ;
Inicia<= '1',
' O' a f t e r 1 1 1 ns ,
' 1 ' a f t e r 50 ns ;
Ge ne r a d o r : pr o c e s s
be gi n
wa i t f e r 1 2 2 +. nsr
Ev e nt o <='1';
wa i t f e r 200 ns
Ev e nt o <=' O' ;
end pr o c e s s ;
Ve r i f i c a : pr o c e s s
be gi n
wa i t en I ni c i a , Ev e nt o ;
i f I ni c i a = 'O' then
wa i t f o r .20 ns:
a s s e r t CUe nt a ~ O r e po r t
" Er r o r : e l c i r c ui t o no s e r e s e t e a '
s e v e r i t y ERROR; .
NumEv e nt o s <= O;
e l s e
i f Ev e nt o = '1' then
P ul s o Empe z a d o : = t r ue ;
end i f ;
i f Ev e nt o = ' O' then
i f P ul s o Empe z a d o t he n
i f NumEv e nt o s < 16 then
NumEv e nt o s <=NumEv e nt o s + 1;
e l s e , . .
NumEv e nt o s <=n;
end i f ;
wa i t f o r 20 nsj
a s s e r t CUe n t a = Nu mE v e n t o s report
" E r r o r : E l c i r c u i t o n o c u e n t a b i e n "
s e v e r i r y E RROR
end i f
end if;
e n d if;
end p r o c e s s ;
Ci r c u i t o : mi _ c i r c u i t o
port map (
E v e n t o => E v e n t o ,
I n i c i a => i n i c i a ,
Re l o j => Re l Qj ,
Salida => Cuenta
)
end PA TI L L A S_A FUERA
LISTADO 6-2. Especificacin de un circuito mediante VHDL. Comportamiento vis-
to desde el exterior.
Enel ejemplo sehandescrito unaseriedeseales y procedimientos quepermi-
tengenerar los eventos y verificar si larespuesta del circuito diseado es laadecua-
da. Enrealidad seest describiendo unbanco depruebas parael circuito queverifi-
ca, deforma automtica, si los resultados soncorrectos. Desdeotropunto devista,
seest modelando oespecificando el entorno del circuito, el sistema enel quevaa
estar funcionando.
Realizar las especificaciones enVHDL tienecomoventaja el questas resultan
simulables. A l mismo tiempo, las especificaciones son legibles por el diseador,
quepuedeinterpretar, ayudado por las simulaciones, el cdigo VHDL . Sin embar-
go, tal y como puededesprenderse del cdigo, aunquepuedan resultar unas especi-
ficaciones completas y sin ambigedades, su interpretacin no es sencilla. Esto
contradice una delas caractersticas fundamentales quedeben cumplir las especifi-
caciones; queseanclaras. Podemos imaginar, comocasoextremo, quelas especifi-
caciones deun microprocesador vinieran dadas mediante un cdigo VHDL que
simulara larespuesta del microprocesador anteunaseriedeprogramas tipo. El dise-
ador podracomprobar si sudiseo es onocorrecto pero, contodaseguridad, sera
incapaz derealizar un circuito quesecomportase deesamanera, yaqueleresulta-
raprcticamente imposible identificar lafuncionalidad con lalectura del cdigo o
el anlisis delas simulaciones. Por otrolado, las especificaciones enVHDL nopue-
den cubrir todos los aspectos del diseo (especialmente en cuanto ala especifica-
cin delas caractersticas tecnolgicas) y, enlamayora delos casos, su desarrollo
resulta extremadamente complejo.
Unas buenas especificaciones deben contener, sobretodo, unadescripcin cla-
ray completa de10 quesedesea disear. Paraellosondegranutilidad los grficos,
cronogramas, diagramas deestados y, principalmente, una buena descripcin tex-
tual. En estesentido, debeintentarse questa sea10 ms escueta posible, evitando
redundancias, sin que por ello se omita informacin. Adems, las especificaciones
deben estar cenadas, ya que los cambios en las especificaciones producen rediseos
constantes y son causa habitual de malentendidos. Las especificaciones deberan es-
tar escritas de forma que pueda comprobarse que se cumplen todas las condiciones
y funcionalidades incluidas en el documento.
Las especificaciones ideales seran aquellas que se mantuviesen estables a lo
largo del proceso de diseo. Su contenido sera suficiente para que el diseador tra-
baje sin necesidad de consultar al cliente. Aparte de la descripcin textual de la fun-
cionalidad y aspectos tecnolgicos, contendran un modelo VHDL del entorno del
circuito. Este modelo no slo emulara las seales de entrada al circuito a disear,
sino que adems respondera adecuadamente a las respuestas del circuito. De esta
manera, el diseador podra realizar las simulaciones del sistema completo sin tener
que desarrollar los bancos de prueba. Con ello se evitara un problema relativamen-
te frecuente, como es que se cancelen errores debido a que la misma persona realice
el modelado del circuito y del entorno (podemos pensar, por ejemplo, en el diseo
de un contador de (}a 15; el diseador podra realizarlo para que contase de Oa 14,
y hacer los bancos de prueba que comprueban esta cuenta; evidentemente, no sera
consciente del error),
6.2.2.2.2. Las especificaciones reales
En la prctica, las especificaciones adolecen de multitud de defectos. En primer lu-
gar, las especificaciones nunca (o casi nunca) son estables. La falta de informacin
inicial, los imprevistos del desarrollo, los cambios en el sistema, etc., obligan a me-
nudo a realizar modificaciones para adaptarse a las nuevas condiciones de contorno.
Por otro lado, unas especificaciones demasiado cerradas no permiten adaptarse a
cambios que podran ser beneficiosos para el diseo (se dice que el diseo est so-
breespecificado) . Como ejemplo podramos fijarnos en el circuito de la Figura 6-3
(vl.0), que se corresponde con la especificacin inicial del expendedor de refrescos
del Apndice 1(ver la especificacin completa en el apndice). El circuito dispone,
Clk
ResN
BotProd1
BotProd2
BotProd3
BotProd4
PrecProd1
PrecProd2
PrecProd3
PrecProd4
BotDevuelve
BotPVPlncre
BotPVDecre
Monedalnt
ColaMatic
v1.0
TrampProd
NoHayP1
NoHayP2
NoHayP3
NoHayP4
NoHayCambio
MoneLleno
MonedaOut
DispUnidad
DispDecena
DispCentena
Clk
ResN
BotProd1
BotProd2
BotProd3
BotProd4
BotDevuelve
BotPVPlncre
BotPVDecre
InteModo
Monedalnt
TrampProd
NoHayP1
NoHayP2
NoHayP3
NoHayP4
NoHayCambio
MoneLleno
MonedaOut
DspUnidad
DlspDecena
DispCentena
FIGURA 6-3. Diferentes versiones con la misma funcionalidad.
entre otras, decuatro seales deentrada para fijar el precio decada producto (Prec-
Prodx) y otras cuatro seales para la seleccin del producto (BotProdx). En un an-
lisis posterior sepodra llegar alaconclusin deque mientras seest fijando el pre-
cio de cada refresco no se estn expediendo refrescos. Podran entonces utilizarse
las mismas seales de seleccin para fijar el precio del producto, existiendo una se-
al inteModo que cambiara entre operacin normal y operacin de cambio de pre-
cio (v2.0). De esta manera ahorraramos tres entradas al circuito, pudindose redu-
cir el coste del encapsulado. Encontrar el punto justo entre unas especificaciones
completas, sinque por ello estemos sobreespecificando, es el objetivo deuna buena
etapa deespecificaciones.
En otras ocasiones, el contenido de las especificaciones es incompleto. A me-
nudo existen aspectos no conocidos o que requieren un anlisis ms detallado o que
son funcin de resultados posteriores del proyecto. En estos casos es corriente en-
contrar que en las especificaciones aparecen notas como por definir, por confirmar
opor consultar. El diseo del circuito puede comenzarse y fijar esos detalles ms
adelante. En otras ocasiones las especificaciones resultan incompletas simplemente
porque seolvidan algunos detalles.
Por otro lado, aparecen amenudo contradicciones o ambigedades que son di-
fciles de detectar en las etapas iniciales del proyecto. Estas ambigedades pueden
ser debidas aerrores deredaccin, imprecisiones o conocimiento poco detallado de
lo que posteriormente ser el circuito. En nuestro sencillo ejemplo podra ocurrir
que, puesto que el importe delos productos seespecifica en unidades de25pesetas,
no sehubiese previsto la devolucin demonedas de 5pesetas. Seestara suponien-
do con ello que el usuario de lamquina no va aintroducir, por ejemplo, 155pese-
tas para pedir un refresco que cuesta 125. Pero dicha situacin, aunque poco proba-
ble, es posible, y podra dar al traste con el diseo.
Por ltimo, laredaccin delas especificaciones no es siempre lo clara que sera
deseable. Debe prestarse una especial atencin aeste aspecto, intentando evitar fra-
ses largas y de difcil comprensin. La inclusin de grficos y diagramas puede
ayudar en gran medida a conseguir este objetivo. Sin embargo, debe tenerse en
cuenta que la interpretacin del texto, diagramas y grficos puede ser diferente se-
gn quien los lea. Esta fueprecisamente una delas razones por las que el DoD pro-
puso lacreacin deun lenguaje estndar para ladescripcin decircuitos integrados,
el VHDL.
El contenido y organizacin del Documento de Especificaciones puede variar
notablemente dependiendo del tipo de circuito y aplicacin que seest consideran-
do. Sin embargo, existen una serie depuntos que siempre aparecern. La Tabla 6-3
muestra unesquema tpico deun documento deespecificaciones.
El Documento de Especificaciones debe entenderse como un documento vivo.
Los cambios, aunque no deseables, son relativamente frecuentes. En este sentido
deben plantearse mtodos para que estos cambios no repercutan de forma negativa
en el proyecto. Estos mtodos van desde el control deversiones y cambios, que per-
mite atodos los participantes en el proyecto estar al da delas ltimas modificacio-
nes, hasta los procedimientos de diseo genrico, que facilitan los cambios de lti-
mahora deforma rpida y con poco esfuerzo. Estos procedimientos sern expuestos
enposteriores apartados deeste captulo.
TABLA 6-3. Esquema del documento de especificaciones
ESQUEMA DEL DOCUMENTO DE ESPECIFICACIONES
Introduccin
Discrepancias con el documento derequisitos
Terminologa usada
Estndares usados
Especificaciones globales
Breve descripcin y objetivos del ASIC
Diagrama deE/S y diagrama debloques funcionales
Modos deoperacin y condiciones depaso deun modo aotro
Registros programables y cometido
Definicin deE/S
Especificacin de los bloques funcionales
Descripcin del bloque .
Diagrama deE/S
Modos deoperacin y condiciones depaso
Estado tras lainicializacin y terminacin
Registros programables y cometido
Especificaciones operacionales
Formato y rango delos datos
Protocolos y algoritmos de las operaciones
Direccin. modo defuncionamiento y formato delos registros programables
Estado delos registros tras lainicializacin o terminacin deoperaciones
Especificaciones tecnolgicas
Especificaciones elctricas
Especificaciones temporales
Especificaciones tecnolgicas globales
Parmetros elctricos
Tensin de alimentacin
Consumo esttico y dinmico
Caractersticas delas E/S
Tensiones mxima y mnima
Corrientes
Margen detemperaturas
Frecuencia defuncionamiento
Encapsulado
Otras especificaciones
6.2.2.2.3. Elaboracin de las especificaciones
El desarrollo de las especificaciones es una tarea fundamentalmente tcnica. Aun-
que el cliente. participa habitualmente en su preparacin. lamayora de las veces la
responsabilidad de su elaboracin recae sobre el diseador (lo que no evita que sea
el cliente quien debe dar la aprobacin ltima). Su elaboracin requiere un conoci-
miento profundo del diseo de circuitos electrnicos y de la aplicacin ala que va
dedicada el circuito.
Durante la etapa de especificaciones serealiza laprimera particin en bloques
funcionales del circuito. Esta particin no tiene por qu coincidir con la particin
que serealice finalmente. Su objetivo es dividir el circuito en unidades que puedan
especificarse de forma ms o menos independiente, de manera que sefacilite laes-
pecificacin y permita unreparto detareas entre varios diseadores.
Para cada uno de los bloques funcionales se identificarn y especificarn sus
entradas y salidas, su funcionalidad detallada, sus modos de operacin, sus restric-
ciones temporales, el estado tras la inicializacin, registros de datos, registros pro-
gramables, restricciones temporales, etc.
Finalizada la especificacin de cada bloque seprocede ala especificacin tec-
nolgica global del circuito. sta incluir aspectos como latensin dealimentacin,
consumo mximo, condiciones de funcionamiento, encapsulado y patillaje (inclui-
das patillas demasa, alimentacin y seales para el test), etc.
Las especificaciones deben contener adems una descripcin global del circui-
to, su funcionalidad, sus entradas y salidas, modos de operacin y registros princi-
pales. Esta descripcin servir para hacerse una idea rpida de la funcionalidad del
circuito y su cometido. El contenido bsico es el mismo que el del documento de
requisitos, pero bastante ms detallado (ya seconocen ms detalles sobre el diseo).
Esta descripcin seincluir al principio del documento.
Hay que tener en cuenta que el Documento de Especificaciones es un docu-
mento detrabajo. Es el documento base dediseo y ser continuamente consultado
por los diseadores. En este sentido debe hacerse un esfuerzo especial para que ten-
gauna organizacin adecuada y sea defcil manejo. Los ndices, tablas deconteni-
dos y figuras, las referencias aotras partes del documento, etc., son de inestimable
utilidad para conseguirlo.
Como ejemplo, en el Apndice 1semuestralaespecificacin delamquinadere-
frescos. Convienedestacar questaesunaespecificacin sencilla. Aunquedebenevitar-
selasespecificaciones voluminosas, amenudo resultandocumentos deciertaextensin.
Como seha comentado previamente, el uso del VHDL en las especificaciones
puede ser degran ayuda tanto para completar ladocumentacin como para disponer
demodelos simulables que faciliten una interpretacin delaespecificacin. Sinem-
bargo, el cdigo VHDL nunca debe reemplazar la especificacin en lenguaje natu-
ral, sino servir deapoyo alamisma. En ocasiones, el cliente puede aportar modelos
en VHDL que valdrn como referencia para validar el diseo. En estos casos, los
modelos VHDL son utilizados para aprobar formalmente la revisin del diseo en
sus diferentes etapas.
6.2.2.2.4. El plan de desarrollo y el plan de pruebas
Aparte de la elaboracin del documento de especificaciones, existen dos importan-
tes tareas organizativas que se deben desarrollar durante esta etapa; la elaboracin
del plan dedesarrollo y el plan depruebas.
El objetivo del plan de desarrollo es definir, al principio del proyecto, cules
son las responsabilidades decada participante en el proceso dediseo, cmo sevan
allevar acabo las tareas, cmo sevaacontrolar el avance del diseo y cul vaaser
laprogramacin temporal del mismo. Todos estos aspectos quedarn recogidos en
undocumento, denominado Plan de Desarrollo, que debe ser aprobado por el clien-
te y el diseador. El plan de desarrollo no es ms que una planificacin detallada
del proyecto en sus aspectos organizativos. Cuando el diseo es pequeo o poco
crtico, el plan de desarrollo, aunque interesante, puede no ser necesario. Para dise-
os grandes o crticos, que deben ser coordinados con el desarrollo del resto del sis-
tema, su elaboracin resulta imprescindible. A menudo surgen problemas debido a
la falta de definicin inicial de las responsabilidades y los procedimientos de con-
trol del proyecto. Podramos encontrar, por ejemplo, que un cliente poco experto en
diseo no sesienta capacitado para analizar las simulaciones delos modelos VHDL
tras el diseo arquitectural. El diseador, por su parte, podra no querer admitir la
responsabilidad devalidar el diseo sin que el cliente verifique por su cuenta el de-
sarrollo. Si el cliente dispone de modelos VHDL con los que validar el diseo, el
problema queda resuelto; si no, habr que encontrar el procedimiento (prototipos,
revisiones ms prolongadas, formacin del cliente en el diseo, etc.) para solventar
el problema. En otras ocasiones, el cliente podra exigir unos mtodos y herramien-
tas de trabajo para los que el diseador no est preparado (por falta de formacin o
deequipo). Anticiparse aestos problemas y resolverlos antes deque el proyecto es-
trealmente en marcha evitar sorpresas desagradables.
Por otro lado, el plan de desarrollo puede incluir los procedimientos que se
van aseguir para realizar el diseo. LaFigura 6-4 muestra un flujograma delos pa-
sos aseguir para realizar un diseo con unas determinadas herramientas. Este flujo-
grama, aunque complejo, sirve para resaltar el gran nmero de programas (en gris
claro), acciones (en gris oscuro) y revisiones que deben realizarse en ocasiones. Co-
mo sepuede imaginar, no es difcil olvidarse algn paso o cometer algn error. El
tener estos procedimientos documentados ayuda no slo a evitar errores sino tam-
bin afacilitar latarea alos diseadores menos expertos en el flujo dediseo.
El contenido del Plan de Desarrollo es muy variable, aunque existen una serie
depuntos que deben incluirse en la mayora de los casos. La Tabla 6-4 muestra un
esquema delo que puede ser el esqueleto del documento. Es importante hacer notar
que, aunque no se considere necesaria la elaboracin de dicho documento, s con-
viene plantearse estos puntos al principio del proyecto para garantizar que no surjan
problemas ms adelante.
Otro aspecto importante acubrir durante la etapa de especificaciones es la ela-
boracin del plan depruebas. El objetivo del Plan de Pruebas es definir cmo seva
arealizar la validacin del diseo. Las simulaciones son el procedimiento habitual
devalidacin, pero no son adecuadas en todos los casos. En ocasiones ser necesa-
rio realizar un prototipo del circuito completo o departe del mismo. En otros casos
puede necesitarse algn otro programa para validar los resultados de las simulacio-
nes. Como ejemplo podemos pensar en el diseo de un filtro digital. Para compro-
bar que los resultados son correctos podramos seguir un procedimiento como el
mostrado en laFigura 6-5.
En este procedimiento, los datos deentrada son generados por un programa es-
pecfico para generar unas formas de onda con unas determinadas caractersticas.
Los mismos datos son pasados al modelo VHDL del circuito y a un programa de
FIGURA 6-4. Ejemplo de flujo de diseo aplicado a herramientas comerciales con-
cretas.
anlisis matemtico que incluye funciones de filtrado digital (con lo que evitamos
que el diseador desarrolle al mismo tiempo el circuito y los bancos de prueba, dis-
minuyendo el riesgo de cancelacin de errores). Los resultados son mostrados me-
diante funciones grficas del programa de anlisis matemtico y se calculan los
errores relativos (del circuito respecto al programa).
De nuevo, definir al principio del proyecto cmo sevan arealizar las pruebas,
obliga aplantearse posibles fuentes de problemas y arealizar una mejor planifica-
cin del trabajo. Todo ello redundar enunproceso dediseo ms fluido y unresul-
tado demayor calidad.
6.2.2.2.5. El equipo de diseo
Laorganizacin del equipo dediseo esunaspecto claveparalacorrecta consecucin
de lID diseo, especialmente cuando el equipo es numeroso. El equipo estar com-
TABLA 64. Plan de desarrollo.
ESQUEMA DEL PLAN DE DESARROLLO
Planificacin del diseo
Flujo de diseo y verificacin
Revisiones del diseo
Fabricante y biblioteca
Herramientas utilizadas
Pormato deintercambio deinformacin
Estrategia detest y cobertura
Convenios sobre numeracin y nombres
Documentacin del diseo y listas dedistribucin
Organizaci6n del equipo de diseo
Planificacin temporal considerando las dependencias delos bloques
Definicin deresponsabilidades y particin del trabajo
Organizacin delabiblioteca
Flujo dediseo y verificacin
puesto bsicamente por el Director, responsable del proyecto, y los diseadores. Ha-
bitualmente es necesario contar con un experto enlaaplicacin donde vaaintegrarse
el diseo. Esteexperto puedeformar partedel equipo dediseo o ser partedel equipo
del cliente. Encualquier caso, loconsideraremos integrante del equipo dediseo.
Las principales cuestiones que deben resolverse desde el punto de vista del
equipo dediseo son laasignacin detareas y lacoordinacin del equipo dediseo
durante el desarrollo .
~
ProgramaMat~
Ficheros Dal~
-
-_
Resultados
Modelo Funcional
- -
Modelo VHDL del
ASIC
Resultados
Modelo ASIC
Resultados
Patrn
FIGURA 6-5. Ejemplo de validacin de los resultados de la simulacin de un cir-
cuito descrito enVHDl.
En laasignacin de tareas debe reflejarse laexperiencia decada diseador tan-
to en la aplicacin como en las herramientas utilizadas para el diseo. Los dise-
adores ms expertos en la aplicacin debern estar a cargo de las etapas de ms
alto nivel, como son las especificaciones y el diseo arquitectural. Por otro lado, los
diseadores ms expertos en las herramientas (VHDL, herramientas de diseo fsi-
co, etc.) estarn ms indicados para las tareas dediseo lgico y diseo fsico.
Existen dos tareas adicionales que amenudo requieren unperfil muy especfico
por parte delos diseadores: el modelado del entorno y laelaboracin del programa
detest. Para el modelado del entorno senecesita un diseador especialmente exper-
to en VHDL, ya que debe realizar un modelo lo ms fiel posible, y que al mismo
tiempo consuma pocos recursos a la hora de simularlo. Por otro lado, debe ser ca-
paz deabstraer cules son las caractersticas del entorno que influyen sobre el dise-
o y que, por tanto, deben modelarse con precisin. En cuanto ala elaboracin del
programa de test, ste requiere un diseador especialmente experto en el diseo de
bajo nivel y que al mismo tiempo conozca con detalle el circuito que se est dise-
ando. Sinembargo, en este caso no es necesario que seaunexperto en VHDL.
A menudo no sedispone de diseadores con el perfil ideal para cada tarea, por
lo que ser necesario una coordinacin adecuada para sacar el mximo provecho al
equipo dediseo y minimizar el tiempo empleado enel desarrollo.
Lacoordinacin del equipo dediseo debe establecerse adiferentes niveles. En
primer lugar, deben fijarse reuniones peridicas que permitan evaluar el estado del
proyecto y aplicar medidas correctivas cuando sea necesario. En segundo lugar,
deben establecerse normas internas y reglas de diseo que faciliten la futura inter-
conexin de los bloques. En el Apndice 11(sobre Normas de codificacin y mode-
lado) se muestra un ejemplo de este tipo de normas. Seguir este tipo de reglas no
slo va apermitir una integracin fcil de los diferentes mdulos que componen el
diseo, sino que adems permitirn un posible cambio en laasignacin detareas, ya
que todos los diseadores trabajarn con un estilo homogneo. Por ltimo, los dise-
adores deben elaborar una documentacin adecuada de su trabajo, que sea fcil-
mente integrable en los documentos finales del proyecto.
Una ltima cuestin ala que debe estar atento el director del equipo de diseo
es la formacin de los diseadores. La constante evolucin de las herramientas y
tcnicas de diseo obliga a mantener un esfuerzo continuado de actualizacin de
conocimientos. Esto debe ser tenido en cuenta para que no repercuta negativamente
sobre los diseos.
Como en cualquier otro proyecto, lacoordinacin del equipo dediseo requie-
reun esfuerzo importante por parte del director. El conocimiento profundo del pro-
ceso de diseo y la utilizacin de tcnicas clsicas como la realizacin de grficos
tipo GANTT o PERT pueden facilitar en gran medida esta tarea.
6.2.3. El diseo arquitectural y lgico
En el proceso dediseo basado en VHDL y sntesis automtica el diseo serealiza
fundamentalmente durante las etapas de diseo arquitectural y lgico. Estas son
normalmente las etapas que requieren un mayor esfuerzo y tiempo.
6.2.3.1. Desarrollo del diseo arquitectural
La etapa de diseo arquitectural puede ser entendida como una etapa de transicin
entre las especificaciones y el diseo lgico del circuito. El objetivo fundamental
de la etapa de diseo arquitectural es obtener una jerarqua de mdulos en la que
los bloques funcionales estn definidos de manera que sean compatibles anivel de
ciclos de reloj (en el caso de diseos sncronos) con el diseo final. El diseo as
dividido deber cumplir con las restricciones planteadas en la etapa de especifica-
ciones y ser ptimo en cuanto a los parmetros del diseo (temporales, de rea y
consumo). Para ello deben investigarse distintas alternativas dediseo y escogerse
lams adecuada. Durante esta etapa sedesarrollarn tambin unos bancos deprue-
ba del circuito completo que puedan ser utilizados en posteriores etapas del desa-
rrollo.
El resultado fundamental de la etapa de diseo arquitectural es el modelo
VHDL del circuito. Este modelo habr permitido simular el comportamiento del
circuito frente al resto del sistema y analizar las posibles alternativas para su reali-
zacin. El modelo VHDL contendr una descripcin a nivel de transferencia de
registros (nivel RT) del circuito. Su comportamiento ser casi real. Aunque no in-
cluya los retardos reales de las puertas y del interconexionado, la evolucin de las
seales en cada ciclo dereloj ser igual aladel circuito una vez fabricado (siempre
que se sigan unas normas de diseo sncrono y se garantice en la fase de sntesis
que las entradas alos registros cambien antes de la llegada de un nuevo flanco de
reloj).
6.2.3. 1. 1. Modelos sintetizables o no sintetizables
Para la realizacin del modelo arquitectural en VHDL cualquier estilo de descrip-
cin es vlido. Sin embargo, deben tenerse en cuenta que existen dos objetivos
contrapuestos que es necesario armonizar. Por un lado, la elaboracin de los mo-
delos VHDL debera ser lo ms rpida y sencilla posible. De esta manera el dise-
ador se concentrar ms en la funcionalidad y no en la manera de codificarla en
VHDL. Por otro lado, los modelos deben estar hechos de manera que su transfor-
macin en modelos sintetizables (recurdese que no todos los estilos son acepta-
bles por las herramientas de sntesis) durante laetapa dediseo lgico sea tambin
sencilla.
Para conseguir esto se considera habitualmente que tras la etapa de diseo ar-
quitectural debe haberse obtenido una descripcin sintetizable del circuito, aunque
los resultados de la sntesis no sean ptimos. Sin embargo, no siempre es sencillo
realizar una descripcin sintetizable del circuito. Los subconjuntos del VHDL que
aceptan las herramientas desntesis son, en ocasiones, muy limitados, eimponen un
estilo dedescripcin que resulta engorroso durante esta etapa. Como ejemplo puede
considerarse la descripcin mostrada en el Listado 6-3. El cdigo refleja el modelo
de un banco de registros en el que sepuede escribir o leer un determinado registro
activando adecuadamente laseales delectura/escritura.
e n t i t y BANCO_ RE GS l a
g e n e r i c (
g Nu mBi t s
g Nu mRe g s
i n t e g e r ; = 8 ;
i n t e g e r : = 4;
);
port(
Re l o j
I n i c i o N
L e e E s c r N
Re g i s t r o
E n t r a d a
S a l i d a
ins t d . . . . l o g i c ;
ins t d . . l o g i c ;
ins t d . _ l o g i c ;
ini r t t e g e t range O teg Nt u n Re g s - 1;
ins t d _ l o g i c _ v e c t o r ( g Nu mBi t s - 1 d o wn t o O) ;
o u t s t d _ l o g i c _ v e c t o r ( g Nu mBi t ! t - 1d o wn t o )
);
end BANCO_ RE GS ;
a r c h i t e c t u r e COMP ORT AME NI ' AL o f BANCO_ RE G l a
t y p e Re g T y p e l s s t d _ l o g i c _ v e c t o r ( g NUmBi t s - 1 d o wn t o O) ;
t y p e Ba n c o Re g s T y p e i s a r r a y ( g Nt u n Re g s - 1 d o wn t o O) of Re g T y p e ;
be g i n
Ba n c o : p r o c e s s ( Re l o j , I n i c j o )
v a r i a bl e Ba n c o Re g s : Ba n c o Re g s T y p e ;
be g i n
i f I n i c i o N = ' O' t h e n
Ba n c o Re g s : = ( o t h e r s => ( o t h e r s => ' O' ) ) ;
e l s l f Re l o j ' e v e n t and Re l o j = ' 1 ' t h e n
l f L e e E s c r N = ' O' tben
Ba n c o Re g ( Re g i s t r o ) := E n t r a d a ;
e l s e
S a l i d a <= Ba n c o Re g ( r e g i s t r o ) ;
end if;
endif;
end process;
end COMP ORT AME NT AL ;
LISTADO 6-3. Bancode registros descrito enVHDL, nosintetizable.
En esta descripcin, anivel RT, sehautilizado un estilo dedescripcin quepo-
dramos llamar algortmico. El banco deregistros esun vector bidimensional al que
seaccedeatravs deun ndice. Como seobserva, ladescripcin esfcil derealizar
y comprender. Esta descripcin, sin embargo, no es sintetizable por muchas herra-
mientas desntesis actuales. Para ello podramos habemos visto obligados arealizar
una descripcin como lamostrada en el Listado 6-4.
entity BANCO_REGS is
port(
Reloj
Inicic1l
LeeEscrN
Regis;ro
.Entrada
salida
instd_logic;
inst<Llogic;
instd,_logic;
ininteger ranga O to 3;
instd,_logic_vector(7 downto O) ;
out std,_logic_v~ctor(7 downto O)
);
end BANCO_REGS;
architecture COMPORTAMENTAL o f BANOD_REG1s
OOgin
Banco: process (Reloj, ~cio)
variable BancoRegsO stst_log.ic_vector(7 downto O);
variable BancoRegsl "Std_logic_vector (7 downto O);
variable BancoRegs2 std_logic_vector (7 downto O):
variable BancoRegs3 std,_logic_vector(7 downto O):
begin
if InicieN = 'o' then
BancoRegsO .- ' 0 0 0 0 0 0 0 0 " ;
BancoRegs1 .- " 0 0 0 0 0 0 0 0 " ;
BancoRegs2 ._ 0 , 0 . 0 0 0 0 0 0 7 ;
BancoRegs3 .-;- " 0 0 0 0 0 0 0 0 " 1
e1s1f Rloj'event and Reloj '1' then
if LeeEscrN = ' O' then
case Registro 1s
when 0-'=> BancoRegO := Entrada;
when 1=> BancoRegl :,,;.Entrada;
when 2 => BancReg2 ~:=Entrada;
when 3 => BancoReg3 := Entrada;
end case;
else
case Registro 1s
when O => Entrada <= BancoRegO;
when 1=> Entrada <= BancoRegl;
when 2 => Eqt~ f= ~SOReg2;
when 3 => Entrada <= BancoReg3;
end case;
end if
end if
end process;
end COMPORTAMENTAL;
LISTADO 6-4. Banco de registros descrito enVHDL. Sintetizable.
En el segundo caso laherramienta no permitira el uso devectores bidimensio-
nales, por lo que habra que describirlos explcitamente. Evidentemente, esta des-
cripcin es ms difcil derealizar y deinterpretar.
Este tipo de situaciones sedan amenudo durante laetapa dediseo arquitectu-
ral. Realizar una descripcin utilizando toda la potencia que nos ofrece el VHDL
facilita y acelera el trabajo. Por tanto, se intentar hacer la descripcin a nivel RT
sin que eso obligue a que sea sintetizable, y aprovechando las facilidades que nos
dael VHDL. Sin embargo, hay que evitar que aparezcan problemas durante el paso
del modelo auno sintetizable. Como ejemplo, obsrvese el segmento decdigo del
siguiente listado.
ifReloj' event and LeeEscrN = ' l' then
Registro :=Entrada;
e l s e
Salida :=Registro;
end pr o c e s s ;
LISTADO 6-5. Descripcin VHDL no sintetizable.
En esta descripcin, Registro cargara datos tanto en el flanco desubida como
en el de bajada de la seal Reloj (podramos encontrarlo interesante para nuestro
diseo). Cuando intentsemos hacer una descripcin sintetizable del circuito nos
encontraramos con la desagradable sorpresa de que no es posible. Esta limitacin
no es debida alas herramientas de sntesis, sino aque no existen normalmente bies-
tables que funcionen de tal modo. Eso obligara a cambiar el diseo arquitectural,
haciendo que el circuito slo funcione en flanco desubida odebajada.
La conclusin es que deben hacerse descripciones decircuitos que sean sinteti-
zables en un sentido fsico, es decir, que debe existir alguna circuitera que secom-
porte como el modelo realizado. Esto es una constante en todo diseo VHDL orien-
tado asntesis; debemos utilizar el VHDL para describir un circuito queya sabemos
cmo realizar fsicamente. El VHDL no es ms que un mtodo para acelerar el pro-
ceso de diseo, una forma mejor que los esquemticos para describir un circuito,
pero no evita que el diseador tenga que elaborar en su cabeza el esquema bsico
del circuito arealizar.
6.2.3. 1.2. La biblioteca del fabricante
Un aspecto que sedebe tener especialmente en cuenta durante laetapa de diseo ar-
quitectural es la tecnologa escogida para el diseo. De la tecnologa va a depender
fundamentalmente la biblioteca de la que dispongamos, y de sta, la facilidad con
que diseemos unas uotras partes del circuito. Un determinado fabricante podra dis-
poner deuna biblioteca en laque hubiese tanto componentes digitales como analgi-
cos, podra disponer de generadores de macroceldas (RAM, ROM, PAL, etc.), ge-
neradores optimizados de estructuras ms complejas (multiplicadores, data-path,
etc.) e incluso celdas de gran complejidad (controladores, filtros, etc.). El tener
acceso aestos elementos debiblioteca puede ser indispensable en algunos casos para
poder realizar el diseo. En otros, simplemente facilita sudesarrollo. Seacomo fue-
se, es conveniente saber dequ elementos disponemos para no desarrollar algo que
ya est hecho, o para considerar el coste de su utilizacin (los fabricantes suelen
facturar una cierta cantidad por el uso de su biblioteca, o por el uso de algunos
componentes desta).
6.2.3. 1.3. Los bancos de prueba
Uno de los resultados fundamentales de la etapa de diseo arquitectural, adems
del diseo preliminar del propio circuito, son los bancos de prueba. En este caso,
el objetivo fundamental es conseguir unos bancos de prueba que sean vlidos alo
largo de las posteriores etapas de refinamiento del diseo. La elaboracin de los
bancos de prueba es, de hecho, una'de las tareas ms crticas dentro del proyecto.
Un diseo con unos bancos de prueba inadecuados es un diseo poco comproba-
do y, por lo tanto, un diseo no vlido. Cuanto ms exhaustivo sea el plan de
pruebas, existirn mayores garantas de que no quede algn error de diseo sin
detectar.
Si es posible, el banco de pruebas deber ser elaborado por un diseador dife-
rente al que harealizado el diseo. De esta manera seevita la cancelacin de posi-
bles errores deinterpretacin delas especificaciones.
Podramos plantear dos mtodos bsicos para afrontar la elaboracin de los
bancos deprueba: los bancos deprueba orientados al modo defuncionamiento y los
orientados alaseal.
En el primer caso debe establecerse un procedimiento donde, para cada modo
de funcionamiento del mdulo que se est comprobando, se elabore un banco de
prueba (o varios) que verifique que cada seal de salida del mdulo responde
deforma adecuada.
En el caso de los bancos de prueba orientados ala seal, debe establecerse un
procedimiento donde, para cada seal de salida del mdulo que seest comproban-
do, seelabore un banco deprueba (o varios) que verifique que la seal responde de
forma adecuada antecada modo defuncionamiento.
En general, los bancos de prueba orientados ala seal son ms sistemticos y
exhaustivos. Adems, puesto que normalmente el diseador plantea el desarrollo de
un determinado mdulo pensando en los modos de funcionamiento, el utilizar un
procedimiento orientado alas seales asegura una comprobacin cruzada. Por otro
lado, es un procedimiento ms sencillo de automatizar, aunque en algunos casos
puede ser excesivamente costoso. Escoger un mtodo uotro depender delas prefe-
rencias delos diseadores.
Al elaborar un banco depruebas debe verificarse que sehacomprobado el fun-
cionamiento del diseo ante todas las posibles situaciones bajo las que el circuito va
afuncionar. Aunque cada circuito es diferente, existen una serie de situaciones co-
munes que hay que verificar. Los siguientes puntos describen estos casos:
Inicializaciones: es necesario verificar que el circuito secomporta correcta-
mente despus de una inicializacin. Hay que comprobar especialmente que
los registros y las seales seinicializan adecuadamente bajo cualquier condi-
cin de partida. Por ello es necesario que los bancos deprueba incluyan ini-
cializaciones no slo al principio de las simulaciones, sino tambin en cual-
quier situacin defuncionamiento.
Terminaciones: la mayora de los circuitos funcionan de forma cclica; los
mdulos que lo integran presentan una funcionalidad que es iniciada al cum-
plirse una serie de condiciones y/o activarse una serie de seales, y que es
terminada deforma autnoma oexterna. Tras laterminacin del ciclo, las se-
ales y registros deben quedar con los valores adecuados para poder comen-
zar un nuevo ciclo. Podramos pensar, por ejemplo, en un transmisor serie.
La transmisin comienza al activar una determinada seal y termina autom-
ticamente cuando el dato hasido enviado. Tras latransmisin, el circuito de-
bequedarse en lamisma situacin que cuando empez, preparado para trans-
mitir un nuevo dato. Es, por tanto, necesario verificar que las seales y regis-
tros internos del mdulo quedan con los valores adecuados.
Funcionamiento no considerado: aunque el circuito est integrado en un
sistema perfectamente conocido, puede que seproduzcan situaciones no con-
templadas (podra estropearse alguno delos sistemas con los que interacta).
Por ello, es necesario realizar un esfuerzo de comprobacin para considerar
los casos no previstos en las especificaciones y que puedan dar paso acom-
portamientos no deseados. Casos tpicos son inicializaciones en medio deun
ciclo de funcionamiento, asincronismo en algunas seales, relanzamiento de
un ciclo (p. ej., intentar enviar un dato en un transmisor serie cuando an es-
tenviando el anterior), etc.
Valores no considerados: el funcionamiento de un circuito o mdulo puede
ser errneo si aparece en sus entradas alguna combinacin deseales no pre-
vista, tanto en seales de configuracin como en datos internos o en valores
de las seales de entrada (lo que probablemente dara funcionamientos no
considerados).
6.2.3. 1.4. Resultados del diseo arquitectural
Como sehaindicado al principio deeste apartado, el objetivo del diseo arquitectu-
ral es obtener una descripcin del circuito que est amitad de camino entre el dise-
o final y las especificaciones. Trabajando de esta manera podremos verificar que
el funcionamiento del circuito es el deseado, sin dedicar un gran esfuerzo alos de-
talles del diseo lgico. Al mismo tiempo, ladescripcin debe ser lo suficientemen-
tecercana al diseo final como para que no surjan sorpresas durante el diseo lgi-
co que impliquen un cambio delafilosofa del diseo.
Desde un punto de vista tcnico, tras el diseo arquitectural debemos obtener
los modelos RT del circuito y los modelos (de cualquier forma) de los bancos de
prueba que utilizaremos apartir deentonces.
6. La gestn del dseo 381
Sin embargo, estos modelos no son el nico resultado que se debe obtener de
esta etapa. Como en cualquier fase del diseo, el diseo arquitectural debe quedar
correctamente documentado para poder utilizar el trabajo en posteriores etapas.
Para ello deberemos redactar el Documento de Diseo Arquitectural. Al igual que
sehizo en la etapa de especificaciones, el objetivo del documento es describir, en
lenguaje natural y con la ayuda de grficos y cronogramas, el funcionamiento del
circuito (el modelo) y los bancos de prueba. El contenido y extensin del docu-
mento dependen, de nuevo, del tipo de proyecto en el que seest trabajando. Si se
trabaja en proyectos de cierta complejidad, donde amenudo colaboran varios dise-
adores, el Documento de Diseo Arquitectural adquiere una gran importancia. Su
redaccin, como la del Documento de Especificaciones, debe ser especialmente
cuidada. Este documento, junto con el cdigo VHDL, servir dereferencia para las
posteriores etapas. Si se ha redactado correctamente, facilitar en gran medida el
trabajo. En proyectos de baja complejidad, o cuando el diseador es el mismo du-
rante las etapas de diseo arquitectural y detallado, el Documento de Diseo Ar-
itectural es menos crtico. Sin embargo, su redaccin presenta dos grandes ven-
tajas. En primer lugar, facilita el trabajo posterior. En segundo lugar, sirve como
documento base para elaborar la documentacin final del diseo (las hojas de ca-
ractersticas y la descripcin del circuito), por lo que siempre es un trabajo que se
aprovechar.
El Documento de Diseo Arquitectural, aunque especfico de cada circuito,
responde casi siempre aun mismo esquema. LaTabla 6-5 muestra un ndice genri-
co deun documento tpico dediseo arquitectural.
En el Apndice 1puede encontrarse el Documento de Diseo Arquitectural pa-
ralamquina derefrescos de nuestro ejemplo. Aunque en este caso su extensin se
ha reducido para incluirla en el texto, puede valer como ejemplo del aspecto que
presenta un documento deeste tipo.
Obsrvese que en el documento seha incluido tambin una descripcin de los
bancos deprueba y sufuncionalidad. Aunque en s los bancos deprueba no forman
parte del circuito, su descripcin facilitar la comprensin de los mismos por parte
delos participantes en las siguientes etapas del diseo. Adems, permitir verificar
que los bancos de prueba responden a las especificaciones (simulan el entorno del
circuito).
6.2.3.2. Larevisin del diseo arquitectural
Terminada laetapa de diseo arquitectural deben revisarse los resultados obtenidos
hasta el momento. La revisin de esta etapa es especialmente importante, ya que a
partir de este momento las modificaciones al diseo tendrn un coste cada vez ms
alto.
Larevisin del diseo arquitectural cumple dos cometidos; uno tcnico (revisar
lafuncionalidad del diseo) y otro organizativo o metodolgico (revisar cmo seha
hecho el diseo y 10 ajustado que est al plan dedesarrollo).
Desde el punto de vista tcnico, larevisin del diseo arquitectural supone una
nueva comprobacin del trabajo realizado por los diseadores. Sedebe verificar que
TABLA 6-5. Esquema del documento de diseo arquitectural
ESQUEMA DEL DOCUMENTO DE DISEO ARQUITECTURAL
Introduccin
Documentos aplicables y dereferencia
Discrepancias con el documento deespecificaciones
Glosario
Terminologa usada
Descripcin arquitectural
Particionado del diseo y justificacin
Identificacin debloques de labiblioteca aptos para ser utilizados
Identificacin debloques susceptibles de ser incluidos en labiblioteca
Diagrama debloques actualizado y deE/S del diseo
Interaccin entre bloques
Caracterizacin de seales internas
Estrategia detest global
Descripcin detallada (para cada bloque funcional)
Descripcin general del bloque
Diagrama deE/S del bloque
Funcionalidad detallada del bloque
Diagramas y codificacin deestados
Formato delos datos y protocolos decomunicacin internos
Codificacin deregistros internos
Codificacin de los datos internos
Breve descripcin del modelo VHDL
Estrategia detest del bloque
Descripcin del test funcional
Simulaciones realizadas y resultados
Matriz decumplimiento delas especificaciones
APNDICE: Cdigos VHDL del circuito y bancos de prueba
lo realizado cumple con las especificaciones, y si no es as, justificar las diferencias
y lanueva solucin. Normalmente este trabajo yahabr sido realizado por el disea-
dor e incluido en el Documento de Diseo Arquitectural, por lo que no debera
requerir demasiado esfuerzo. En larevisin del diseo arquitectural deberan partici-
par tanto el diseador como el cliente. Es precisamente el cliente quien debe asegu-
rarse deque el diseo satisface totalmente sus requisitos y debe dar el visto bueno al
diseo.
Desde el punto de vista organizativo y metodolgico, larevisin debe verificar
que el diseo ha sido realizado de forma adecuada y que los plazos fijados siguen
siendo vlidos. Hay que comprobar que el cdigo VHDL ha sido escrito de forma
correcta; es decir, que se ha elaborado un cdigo de calidad. Esta revisin implica
comprobar los siguientes puntos:
Estilo de codificacin y nomenclatura: aunque la forma de nombrar las
seales y escribir el cdigo no tiene por qu influir en la funcionalidad del
diseo, utilizar un mal estilo decodificacin haceperder muchas delas venta-
jas del VHDL. Podemos comparar las descripciones del Listado 6-6. Eviden-
temente, la segunda descripcin es mucho ms clara. La primera descripcin
difcilmente podr ser utilizada por un diseador distinto al que la realiz (o
por quien ladise, al cabo detres meses).
pr o c e s s uno ( a , b)
be gi o
i f b = 'o' t he n
c <= ( o t he r s = > ' O' ) ;
e l s e _7
c <= ( o t he r s = > ' O' ) ;
fer iinO te 7 l o o p
i f a = ithen
c (i) <= '1';
e nd i f ;
e nd l o o p;
e nd if;
e nd pr o c e s s ;
pr o c e s s de ! nux ( s e l e c c i o n, habiH~): .:
be gi o
i f ha bi l i t a = 'o' then
s a l i da ~= ( o t he r s = > 'O ;);
e l s e
s a l i da <= ( o t he r s = > ' O' ) ;
fer i inO te NumSa l i da s - 1 l o o p
i f s e l e c c i n = i then
s a l i da ( i ) <= ' 1' ;
e nd i f ;
e nd l o o p;
end if;
e nd pr o c e s s ;
LISTADO 6-6. Estilosdenomenclatura.
Estilo de descripcin: normalmente se considera que las descripciones
VHDL deben ser comportamentales o estructurales, pero no una mezcla de
las dos. Hacerlo as facilita laescritura del cdigo y sudepuracin.
Utilizacin de puertos, seales, variables y genricos: como resultado del
proceso dediseo, amenudo sedefinen seales, variables, etc., que son utili-
zadas durante un cierto tiempo y luego son desechadas al encontrase una so-
lucin mejor o ms elegante. Conviene revisar que en el cdigo no quedan
estos objetos definidos y no utilizados. Si bien no suponen un error en el di-
seo, s dificultan la lectura y depuracin del cdigo. Un diseador ajeno al
diseo encontrara seales definidas que no sabe para qu se utilizan. Por
otro lado, esta revisin permite identificar posibles olvidos u omisiones y da
como resultado un cdigo demayor calidad.
Comprobacin de valores constantes en el cdigo: en todo diseo apare-
cen valores constantes que reflejan alguna caracterstica del circuito que se
est realizando. Estos valores responden aaspectos como el ancho deunbus,
la cuenta final de un contador, el nmero de registros de un banco de regis-
tros, etc. Conviene revisar que estos valores no aparecen reflejados como
nmeros en el cdigo, sino como constantes que habrn sido definidas previa-
mente. Esto responde ados objetivos; por un lado, facilita lalectura del cdi-
go; por otro, facilita las modificaciones posteriores, ya que el valor slo es
corregido en un sitio. En el apartado sobre diseo genrico se discutir este
tema ms afondo.
Comprobacin de las listas de sensibilidad: en los diseos realizados en
VHDL, una fuente frecuente de problemas son las listas de sensibilidad de
los procesos. Como se ha visto en captulos previos, los procesos en VHDL
que poseen listas de sensibilidad slo son evaluados cuando se produce un
evento en alguna de las seales de la lista. Esto puede producir diferencias
entre lo simulado y lo sintetizado, yaque los sintetizadores generan un hard-
ware que responde atodas las seales que selean en el proceso, ignorando lo
que aparezca en la lista de sensibilidad. El Listado 6-7 presenta un ejemplo.
La descripcin VHDL, una vez sintetizada, producir un circuito que no se
comportar igual que el de la simulacin. Los sintetizadores avisan de este
riesgo, pero a menudo estos avisos no son tenidos en cuenta (aunque no es
correcto, uno acaba por no mirar la cantidad de informacin que le devuel-
ven las herramientas de sntesis). Es necesario entonces revisar que las listas
desensibilidad son correctas para evitar problemas posteriores.
pr o c e s s Mux E r r o ne o ( Se l e c c i o n)
be gi n
i f Se l e c c i o n = ' 1' then
salida <= Entrada_1;
e l s e
salida <= Entradq_O;
end i f ;
e nd pr o c e s s ;
LISTADO 6-7. Lista de sensibilidad errnea.
Ejercicio 6.1-
Dibujar el circuito resultante de la sntesis del cdigo del Listado 6-7 Y las formas
deonda resultantes delasimulacin.
L
Seleccin .....1
Entrada_O
Salidas
Entrada_O ___fl___f"L___J
Entrada_1~
Entrada_1
salidassntesis~
Salidas simuladas ---------_
La revisin deestos aspectos suele ser llevada acabo por los diseadores (nor-
malmente por el director del equipo de diseo). Como seobserva, su objetivo final
es facilitar las tareas posteriores y la reutilizacin del diseo. Un cdigo VHDL
bien escrito es un cdigo fcil de leer y de depurar. Las modificaciones posteriores
implicarn poco trabajo y el riesgo deerrores disminuir.
Los ltimos aspectos del diseo arquitectural arevisar son los relacionados con
laorganizacin del proyecto, siendo el ms importante el referente al cumplimiento
de plazos. En este punto del diseo se tendr una idea mucho ms precisa de la
complejidad del proyecto y su evolucin. Sedebern aplicar las medidas necesarias
para cumplir el plan de trabajo planteado inicialmente y, si fuese necesario, serea-
justarn las tareas y plazos para solucionar posibles problemas. En este sentido, es
el cliente quien debe tomar las decisiones finales sobre cualquier modificacin ala
planificacin del proyecto.
6.2.3.3. Desarrollo del diseo lgico
El objetivo del diseo lgico es obtener una descripcin del circuito lo suficiente-
mente detallada como para servir de entrada alas herramientas de diseo fsico. El
trabajo fundamental de esta etapa consistir en la sntesis de las descripciones
VHDL y la optimizacin de la lgica para conseguir las prestaciones deseadas. La
optimizacin de la lgica se har a dos niveles: previamente a la sntesis (modifi-
cando el cdigo VHDL) y tras la sntesis (imponiendo restricciones temporales, de
rea o consumo). La ejecucin deesta etapa requiere laseleccin del fabricante y la
tecnologa en laque seimplementar el circuito.
6.2.3.3. 1. La seleccin de la tecnologa
Desde unpunto devista terico, laseleccin delatecnologa podra retrasarse hasta
esta etapa. Hasta este momento el diseo hasido independiente delatecnologa; los
modelos arquitecturales no poseen normalmente informacin respecto auna biblio-
teca particular de componentes, sino que describen el comportamiento del circuito
en trminos deregistros y operaciones lgicas. Sinembargo, retrasar laseleccin de
la tecnologa hasta esta etapa puede acarrear ciertos inconvenientes. En primer lu-
gar, puede ocurrir que la tecnologa escogida no satisfaga los criterios de rea, fre-
cuencia defuncionamiento oconsumo requeridos. Si latecnologa sehaselecciona-
do con antelacin, sepodrn realizar algunas pruebas deaquellas partes que secon-
sideren ms crticas con objeto de estimar si van o no acumplir con las restriccio-
nes. Estas pruebas podrn realizarse durante la etapa de diseo arquitectural, o
incluso durante la etapa de especificaciones, previendo posibles problemas y
actuando en consecuencia.
Por otro lado, desconocer latecnologa objetivo puede hacer que desarrollemos
celdas o componentes de forma inadecuada. Como ejemplo podemos fijarnos en el
desarrollo de un banco de registros deun microprocesador sencillo. Si disponemos
de una biblioteca que contenga generadores de memorias bipuerto es posible que
podamos implementar el banco de registros mediante este tipo de memorias con
unos buenos resultados en cuanto al rea final del circuito. Si dichas celdas no estn
disponibles en la biblioteca, o desconocemos su existencia, no quedar otro reme-
dio que implementar el banco de registros mediante biestables, lo que resultar en
uncoste elevado derea. De igual manera podra ocurrir que nos dedicsemos ade-
sarrollar celdas (puertos paralelo, transmisores/receptores serie, multiplicadores, fil-
tros, etc.) que ya estuviesen disponibles en la biblioteca, o que fuesen accesibles a
un coste razonable como macroceldas yadesarrolladas.
En cualquier caso, es importante asegurarse de que los componentes debiblio-
teca que sevayan autilizar posean modelos VHDL que nos permitan suintegracin
y simulacin sinproblemas en nuestro diseo.
6.2.3.3.2. Laoptimizacin del cdigo
Normalmente, el cdigo desarrollado durante la etapa de diseo arquitectural habr
sido escrito sin considerar en detalle el diseo lgico (dehecho, ste es su objetivo).
Por tanto, habrquemodificar las descripciones paraobtener unbuen resultado tras la
sntesis lgica. Enprimer lugar, puede ocurrir quealguna delasdescripciones realiza-
das no seasintetizable con laherramienta delaquesedisponga. Por otro lado, aunque
lasdescripciones sean sintetizables, puedeque los resultados delasntesis no seanlos
ms adecuados. Como ejemplo podemos fijarnos en el cdigo del Listado 6-8.
p r o c e s s Co n t a d o r ( Re l o j , I n i c i o )
v a r i a b l e a u XCu e n t a : i n t e g e r r a n g e O to c Ma XCu e n t a ;
begin
i f I n i c i o = ' O' tben
a u x Cu e n t a : = O;
e 1 s i f Re l o j ' e v e n t and Re l j ' : ' 1 ' t h e n
a u x Cu e n t a : = a u x Cu e n t a + 1 ;
i f a wd : : u e n t a = c : Ma x Cu n t a tben
a u x Cu e n t a : = O;
end i f ;
Cu e n t a <= a u x Cu e n t a
end if;
LISTADO 6-8. Contador con registros redundantes.
El cdigo refleja un contador sncrono implementado mediante un proceso en
el que la cuenta se lleva mediante la variable auxCuenta. La cuenta puede ser utili-
zada fuera del proceso al ser asignada a la seal Cuenta. Si sintetizamos esta des-
cripcin se generarn dos registros, uno para almacenar la variable auxCuenta y
otro para la seal Cuenta. Aunque la descripcin y el resultado tras la sntesis son
funcionalmente correctos, ambos registros contendrn la misma informacin, por lo
que sern redundantes. Esta descripcin debera ser optimizada para eliminar uno
de los registros.
Ejercicio 6.2
Modificar el cdigo del Listado 6-8 para que no genere registros redundantes.
Los registros en auxCuenta y Cuenta se generarn debido a que es necesario
mantener el valor de ambos objetos entre dos ciclos consecutivos del reloj. Si en ca-
da ciclo de reloj asignamos un nuevo valor a auxCuenta no ser necesario mante-
ner el valor anterior, por lo que no se sintetizar un registro.
process Contador (ReYoj, Inicio)
variable auxCuenta : ipteger range Oto cMaxCuenta
begin
if Inicio h O' then
CUenta<= O ;
elaif ,Reloj ':event aqd Re~9j",= '1' then '
auxCuenta .':=CUenta; ''-''''-al comenzar el ciclo daIrios
':_'tIT huevo valor a partir de Cuenta
auxCuentat :=_1~~~1.+ 1;
if auxCuenta =cMaxCuenta then
aUXCuenta :=Or
end if;
Cuenta" <=auxCuenta :-- al termi,Il?I el. ciclo asignamos el
-- nuevo valor calculado a CUenta
end if;
end process;
LISTADO 6-9. Modificacin propuesta para el Listado 68.
Otro caso tpico es la comparticin de recursos. Como ejemplo podemos fijar-
nos en el cdigo del Listado 6-10. En este caso el cdigo refleja parte de una unidad
aritmtica de un procesador.
process (Reloj, Inicio, ... )
begin
if Inicio = 'O' then
elsif Reloj' event and Reloj :: l' then
i f Op e r a c i o n ~ COD_ OP DC t he n
A <= Da t o , . . ? : . + Da t o _ C;
e l s i f OP e +' ! - c i o n = COD_ OP I R
B <= Da t _ t + Da t o _ R;
end if;
end i f ;
LISTADO 6-10. Utilizacin de dos sumadores.
En el cdigo, los registros A y B guardan el resultado delasuma deotras seales
del sistema. Si sintetizamos esta descripcin encontraremos que se generan dos su-
madores, uno para calcular A y otro para calcular B. Pero si prestamos atencin ala
descripcin veremos que nunca seutilizan los dos sumadores al mismo tiempo (los
cdigos de operacin son excluytentes), sino que en funcin de una seal de selec-
cin secalcula A o B. Por lotanto, es posible utilizar unmismo sumador para realizar
ambas operaciones (algunos sintetizadores pueden hacer esto automticamente).
Ejercicio 6.3
Modificar el ejemplo del Listado 6-10 para que al sintetizarlo seutilice un solo su-
mador.
Una posible solucin consiste en utilizar variables intermedias a la que se les
asigna el valor delos operandos en funcin del cdigo deoperacin.
p r o c e s s ( Re l o j , I n i c i o . . . )
v a r i a b l e OpI, Op2 :
v a r i a b l e Suma .
b e g i n
- - De f i n i d a s i g u a l . q u e l o s Da t o s
- - De f i n i d a igai q u e - o . ;13
Op_1 :=Da t o _ D;
Op_2 :=Da t o _ e ;
i f Op e r a t i o n = COD_ OP I R t he n
Op_1 :=Da t o _ I ;
Op_2 : = n a t o _ R;
end if;
Suma : = Op_1 + Op_2;
i f Op e r a c i n = COD_ OP DC then
A <= Suma;
e l s i f Op e r a c i ~n = COD_ OP I R t he n
B <= Suma;
end i f ;
LISTADO 6-11. Modificacin propuesta para el Listado 6.10.
6.2.3.3.3. La repercusin de los cambios
En ocasiones las restricciones temporales o de consumo pueden implicar cambios
en el diseo arquitectural. Tomemos, por ejemplo, un diseo que debe funcionar a
una frecuencia elevada. Tras la sntesis podramos descubrir que no satisface las es-
pecificaciones de velocidad. Esto podra implicar la necesidad de introducir seg-
mentacin en las partes ms crticas del diseo, lo que supone una modificacin a
nivel arquitectural. A estas alturas del diseo, los costes de dichas modificaciones
son importantes, ya que se deben redisear los bancos de prueba, volver arealizar
las simulaciones, etc.
Para evitar este tipo de imprevistos es muy conveniente haber realizado algu-
nas pruebas previas que nos permitan llevar a cabo un diseo arquitectural ade-
cuado. La utilizacin de tcnicas como el diseo genrico puede ayudar a paliar
los efectos de dichos cambios (permitiendo, por ejemplo, cambiar rpidamente el
nmero de estapas de segmentacin necesarias, los ciclos de espera a un evento
lento, etc.).
Otra delas razones fundamentales por las que serealizan modificaciones en el
cdigo es la introduccin de lgica para test. Este es un aspecto difcil deconside-
rar durante la etapa de diseo arquitectural, ya que el test aplicable al circuito
depende en gran medida de la lgica utilizada para implementar cada funcin. La
insercin delgica detest y obtencin delos vectores detest puede hacerse defor-
ma automtica con algunas herramientas (utilizando tcnicas de test estructura-
das). Si no se dispone de dichas herramientas, habr que resolver el problema del
test de forma manual. Este es un problema difcil, y bastante dependiente de la
aplicacin.
6.2.3.3.4. Los resultados del diseo lgico
Como sehaindicado previamente, el objetivo del diseo lgico es obtener una des-
cripcin lo suficientemente detallada como para servir deentrada alas herramientas
de diseo fsico. Como hemos visto, este proceso consiste en modificar el cdigo
(para eliminar lgica redundante, compartir recursos o satisfacer ciertas restriccio-
nes) y sintetizarlo con una determinada biblioteca suministrada por un fabricante.
Tras el proceso de sntesis (o en paralelo con ste), las herramientas permiten reali-
zar una optimizacin lgica que permita satisfacer los requisitos en cuanto aconsu-
mo, rea o frecuencia de funcionamiento. El proceso de sntesis habr sustituido la
lgica descrita a nivel RT por un conjunto de puertas, biestables, y celdas bsicas
queposeen lamisma funcionalidad.
Tras el proceso de sntesis obtendremos una descripcin estructural del circui-
to, que consistir en una lista de celdas (pertenecientes alabiblioteca del fabrican-
te) einterconexiones (netlist). Esta descripcin ser laentrada alas herramientas de
ubicacin y conexionado.
Durante toda estaetapa sehabrn realizado modificaciones sobre el diseo (op-
timizacin del cdigo). Ser, por tanto, necesario realizar simulaciones que nos ase-
guren que la funcionalidad no ha cambiado. Para ello podemos utilizar los mismos
bancos de prueba que hemos desarrollado durante el diseo arquitectural. Tras la
sntesis, tambin es conveniente realizar estas simulaciones. Aunque normalmente
no hay problemas, puede ocurrir que el proceso de sntesis ofrezca resultados inco-
rrectos, por lo que conviene verificar, mediante simulacin, que los resultados son
satisfactorios. Para realizar estas simulaciones ser necesario obtener una descrip-
cin VHDL estructural del circuito sintetizado (casi todas las herramientas desnte-
sis lo permiten) y disponer de los modelos VHDL delos componentes de labiblio-
teca del fabricante.
Las simulaciones que serealizan en esta etapa pueden incluir los retardos esti-
mados para la lgica del circuito. Aunque stos no sern los retardos reales (falta
incluir los retardos debidos alas interconexiones), s nos permitirn una simulacin
ms precisa del comportamiento temporal del circuito.
Como seha venido comentando en los apartados previos, los resultados deca-
daetapa deben ser convenientemente documentados. En el caso delaetapa dedise-
o lgico, el documento debe incluir fundamentalmente las modificaciones realiza-
das alos cdigos VHDL, ladescripcin del mtodo utilizado para realizar el test de
fabricacin y recomendaciones para la etapa de diseo fsico. Todo esto quedar
recogido en el Documento de Diseo Lgico. La Tabla 6-6 muestra un posible
esquema del contenido dedicho documento.
6.2.3.4. La revisin del diseo lgico
Terminada la etapa de diseo lgico deben revisarse los resultados obtenidos hasta
el momento. La revisin del diseo lgico debe cubrir tres aspectos fundamentales:
revisar que la funcionalidad sigue siendo correcta, comprobar que se satisfacen los
requisitos en cuanto a prestaciones y verificar el test de fabricacin. Adems, al
igual que sehizo en larevisin del diseo arquitectural, deben verificarse los aspec-
tos organizativos del proyecto (cmo sehahecho el diseo lgico y lo ajustado que
est al plan dedesarrollo).
Para revisar la funcionalidad se habrn realizado simulaciones comparativas
entre los resultados del diseo arquitectural y el diseo lgico. Pero adems, puesto
que yasedispone deuna estimacin delos retardos delalgica, severificar que el
circuito sigue comportndose adecuadamente en las simulaciones en peor y mejor
caso (retardos mximos y mnimos), especialmente en los puntos que seconsideren
ms crticos.
En cuanto al test de fabricacin, el proceso de revisin consiste en un anli-
sis de las partes del circuito que no han quedado suficientemente cubiertas por
el test de fabricacin. La decisin sobre una posible mejora del test de fabrica-
cin depende en gran medida del tipo de aplicacin a la que vaya dedicado el
circuito y de los recursos y tiempo necesarios para su modificacin. Esta deci-
sin debe ser valorada convenientemente por el cliente y el Director del equipo
de diseo.
En cuanto a los aspectos organizativos y metodolgicos del diseo, son apli-
cables los mismos comentarios que se hicieron para la etapa de diseo arquitec-
tural.
TABLA 6-6. Esquema del documento de diseo lgico
ESQUEMA DEL DOCUMENTO DE DISEO LGICO
Introduccin
Documentos aplicables y dereferencia
Discrepancias con el documento dediseo arquitectural y especificaciones
Glosario
Terminologa usada
Descripciones globales
Biblioteca utilizada
Relacin dePADs utilizados
Patillaje cuasi-definitivo
Encapsulado
Descripcin de cada bloque del diseo arquitectural
Descripcin general del bloque y E/S
Particionado, diagrama estructural y funcionalidad delos subbloques
Descripcin delacircuitera detest'
Breve descripcin del modelo VHDL
Restricciones utilizadas en sntesis
Descripcin de los componentes de biblioteca utilizados
Descripcin general del bloque y E/S
Restricciones y parmetros utilizados en sntesis
Verificacin del test funcional
Simulaciones realizadas y resultados
Matriz decumplimiento respecto al diseo arquitectural
Descripcin del test de fabricacin
Descripcin del programa detest
Resultados delasimulacin defallos (cobertura y movilidad)
Test paramtricos arealizar
Anlisis de resultados tras la sntesis (recomendaciones al diseo fsico)
Mxima frecuencia defuncionamiento
Anlisis esttico detiempos
Distribucin y desfase del reloj
Problemas deJan-out
APNDICE 1: Cdigos VHDL del circuito
APNDICE 11: Programa y vectores de test (de fabricacin)
APNDICE 111:Relacin de advertencias obtenidas yjustificacin
6.2.4. El diseo fsico y la fabricacin
La etapa de diseo fsico consistir fundamentalmente en la ubicacin y conexiona-
do de la lgica sintetizada durante el diseo lgico. Los datos de entrada a esta eta-
pa son bsicamente la lista de componentes e interconexiones, la biblioteca del fa-
bricante y las recomendaciones para el diseo fsico contenidas en el Documento de
Diseo Lgico. El trabajo de esta etapa suele estar bastante automatizado y no de-
bera plantear problemas para la mayora de los circuitos. Sin embargo, cuando el
circuito trabaja aaltas frecuencias defuncionamiento el tamao delalgica est li-
mitado (como en las FPGAs o matrices de puertas), o el consumo debe ser reduci-
do, pueden no conseguirse las prestaciones deseadas. Por otro lado, aunque las tare-
as arealizar durante el diseo fsico estn bastante automatizadas, amenudo existe
un salto brusco entre las herramientas utilizadas hasta el momento (simuladores y
sintetizadores) y las que seutilizarn en esta etapa. En ocasiones es necesario reali-
zar conversiones deformato, utilizar simuladores especficos del fabricante y resol-
ver todo tipo de problemas de interfaz entre herramientas. Como se ha comentado
previamente, realizar algunas pruebas durante las etapas de diseo arquitectural o
diseo lgico puede evitar sorpresas deltima hora.
Tras la realizacin del diseo fsico, ser necesario realizar simulaciones del
circuito con los retardos debidos a las interconexiones. Estas simulaciones refleja-
rn con gran precisin el comportamiento real del circuito. Deben realizarse simula-
ciones enpeor y mejor caso y verificar los puntos crticos.
El proceso defabricacin depende delatecnologa escogida. Si el circuito sevaa
implementar mediante lgica programable (EPLDs, FPGAs), laprogramacin sehar
normalmente en el centro de diseo. Si el circuito va a ser fabricado como un ASIC
(circuito integrado deaplicacin especfica), requerir deunos prototipos iniciales an-
tes depasar aproduccin. Esto debe tenerse en cuenta en laplanificacin del proyec-
to, ya que normalmente implica un retardo adicional de al menos uno o dos meses.
6.2.5. Lavalidacin y caracterizacin del circuito
Una vez fabricado el circuito, debe comprobarse su funcionamiento en el sistema
final. Las pruebas arealizar dependen de cada aplicacin. Para sistemas sencillos,
puede no ser necesario realizar pruebas especiales, sino que ser suficiente con ins-
talar el circuito en el sistema final y validar su funcionamiento con aplicaciones re-
ales. Sin embargo, en sistemas complejos, la validacin puede requerir planes de
prueba especficos que, en muchos casos, no respondern a modos de funciona-
miento reales del sistema. Un ejemplo claro lo podemos ver en un microprocesador.
En este caso, ejecutar un programa real sobre el micro puede no darnos una total
garanta de que el sistema vaya afuncionar en todos los casos. Para ello deben rea-
lizarse programas especiales que vayan ejercitando cada parte delalgica y del sis-
tema. En algunos casos ser incluso necesario realizar tarjetas o circuitera adicio-
nal para comprobar fcilmente el funcionamiento.
La elaboracin de estas pruebas debe tenerse en cuenta para no demorar la fi-
nalizacin del proyecto. Normalmente, estas pruebas pueden planificarse y disear-
se durante las etapas de diseo fsico y fabricacin. En estas etapas, el diseo va a
estar completamente definido y raramente seproducirn modificaciones, por lo que
el trabajo dedicado ala elaboracin de las pruebas finales no se ver afectado (sal-
vo, quizs, el patillaje definitivo).
Una de las ltimas tareas arealizar sobre el diseo es su caracterizacin. Este
proceso, aunque no siempre serealiza, permite verificar que el comportamiento del
circuito responde alo simulado. Los resultados delacaracterizacin nos permitirn
completar ladocumentacin sobre el diseo y facilitarn lareutilizacin del compo-
nente en otros proyectos. Por otro lado, podremos utilizar los resultados delacarac-
terizacin para obtener un modelo en VHDL del componente. En lamayora de los
casos ser suficiente con introducir los retardos reales del componente sobre el mo-
delo RT que obtuvimos tras la etapa de diseo arquitectural. El siguiente listado
muestra un ejemplo sencillo decmo hacerlo.
e nt i t y DE MUX i s
port (
Se l
E nt
Sa l _ O
Sa 1_ l
);
end DE MUX;
in bi t ;
in bi t ;
o ut bi t ;
o ut bi t
a r c hi t e c t ur e NORMAL .of DE MUX i s
begin
DM : pr o c e s s ( Se l , E nt )
i f Se l = 'o' then
Sa l _ O <= E nt ;
Sa l _ l . : : ; : IQ~';
e l s e te"
Sa l _ l <'" E nt
Sa l _ O <= 'O'
end if;
end pr o c e s s ;
end NORMAL ;
a r c hi t e c t ur e RE T ARDOS of DE MUX i s
- - De f i ni mo s I a . f unc j o na k i da d c o n s e ny a l e s a ux . L i x a r e s
s i gna l a ux Se l : bi t ;
s i gna l a ux E nt : bit;
s i gna l a ux s a i ~o ~ a uXs a l _ l : bi t ;
begin
DM : pr o c e s s ( a ux Se l , a ux E nt )
end pr o c e s s ;
a ux E nt <= Ent;
a ux Se l <= Se l ;
Sa l _ O <= a ux Sa l _ O a f t e r t HL _ DS when Se l ' " ' 1' e l s e
a ux Sa l _ O a f t e r t p_ DS when Se l " ' _' O' ;
Sa l . . ..1 <= a u1c Sa l _ l a f t e r t HL _ DS when Se! = ' 1' e l s e
a ux Sa l _ l a f t e r t p_ DS whe n Se l = ' O' ;
end RE T ARDOS;
LISTADO 6-1 2. Introduccin de retardos en la descripcin VHDL.
El ejemplo mostrado es un caso muy sencillo en el que las seales tienen retar-
dos diferentes en funcin de la seal de seleccin. En la mayora de los casos, la
descripcin debe complicarse para modelar correctamente todos los tipos de re-
tardos.
De cualquier forma, hay que tener en cuenta que un modelo obtenido de esta
manera refleja slo aproximadamente las caractersticas reales del circuito; puede
ser un modelo vlido para unas simulaciones estimativas sobre el comportamiento
del sistema, pero no resultar adecuado si sequieren realizar unas simulaciones pre-
cisas. An as, suelen ser modelos muy tiles durante las etapas iniciales deun pro-
yecto (hasta laetapa dediseo arquitectural).
6.2.6. Documentacin, evaluacin y seguimiento
del proyecto
Como sehapodido observar en los anteriores apartados, el proceso dediseo deun
circuito requiere cubrir una gran cantidad deaspectos adems delo que es lacodifi-
cacin del diseo en VHDL y su posterior sntesis. Aspectos como la documenta-
cin, las reuniones peridicas, el seguimiento y solucin de los posibles problemas,
etctera, requieren un esfuerzo considerable por parte del cliente y de los integran-
tes del equipo dediseo.
Conviene, por tanto, valorar el grado deformalismo con el que sesiguen las re-
comendaciones que sehan dado en los anteriores apartados. Ladocumentacin, por
ejemplo, es un factor clave en todo proyecto. Una buena documentacin deuna eta-
pa facilita enormemente el trabajo dela siguiente. Sin embargo, el esfuerzo dedica-
do a elaborar una buena documentacin puede ser elevado. Los documentos ms
importantes deun diseo, y cuyo contenido debe ser ms cuidado, son el Documen-
to de Especificaciones y el Documento de Diseo Arquitectural. Si el diseo es pe-
queo, la realizacin de los dems documentos puede reducirse en gran medida, e
incluso no realizarse en algunos casos. Si el diseo es complejo, el nmero departi-
cipantes es grande, o seprev una reutilizacin o depuracin futura del diseo, una
buena documentacin de cada etapa va a ser imprescindible. De igual manera, la
realizacin dereuniones peridicas, laelaboracin deplanificaciones detalladas, los
informes peridicos de seguimiento, etc., deben hacerse de acuerdo a la magnitud
del proyecto. Si el proyecto es pequeo, estos aspectos pueden ejercer un efecto
negativo sobre el desarrollo, en vez de agilizarlo. En cualquier caso, debe ser el
director del equipo dediseo quien valore el grado dedetalle que deben seguir estas
recomendaciones.
6.3. DESARROLLO Y ORGANIZACIN DE BIBLIOTECAS
ENVHDL
En un diseo real desarrollado en VHDL se generan normalmente una gran canti-
dad deficheros decdigo, unidadesde diseo (entidades, arquitecturas, etc.), fiche-
ros dedatos y documentacin que es necesario gestionar. No es extrao encontrarse
al final del diseo con decenas deficheros y versiones distintas delos componentes
diseados. Adems, los objetivos de estas versiones pueden ser diferentes, estando
unas pensadas para sntesis, otras para simulacin, etc.
La Pigura 6-6 muestra un ejemplo simplificado de las diferentes versiones o
ficheros que podran irapareciendo durante el proceso dediseo. En lafigura pode-
mos ver cmo un determinado mdulo del diseo (mdulo A) vapasando por dife-
rentes versiones hasta llegar asuversin definitiva.
Inicialmente disponemos de un modelo comportamental, posiblemente desarro-
llado durante la etapa deespecificaciones. Durante el diseo arquitectural, el mismo
mdulo es rediseado (descrito de forma diferente) para obtener un modelo RT. Du-
rante este proceso se han podido generar diferentes versiones hasta llegar ala solu-
cin funcionalmente conecta o ms adecuada. Posteriormente pasaramos al diseo
lgico, donde todo este proceso de rediseo serepite. Podramos pensar que las ver-
siones antiguas no sonimportantes, yaquelaversin quefinalmente nos interesa es la
ltima, pero esto no es cierto. El proceso dediseo en VHDL nos permite comparar
fcilmente (incluso deforma automtica) unaversin conotra. As, finalizado el dise-
olgico, podemos realizar una simulacin comparativa entreel modelo que seobtu-
vodurante el diseo arquitectural yel que sehaobtenido durante el diseo lgico. Lo
mismo podramos hacer entreel modelo delas especificaciones y el arquitectural.
FPGA Modelo
Synopsys +
Cadence
prototipo
Xilinx
simulacin
Synopsys
FIGURA 6-6. Versiones o ficheros generados a lo largo de un diseo.
El problema se complica an ms si tenemos en cuenta que los modelos obteni-
dos pueden tener distintas orientaciones. Podramos, por ejemplo, realizar un diseo
lgico con objeto de hacer un prototipo inicial del circuito en una FPGA. Este mo-
delo sera seguramente diferente del que utilizsemos para la fabricacin en silicio,
ya que los estilos de descripcin podran ser diferentes (para adaptarse a la bibliote-
ca de cada fabricante y obtener un mejor resultado en la sntesis). Tambin podra-
mos necesitar modelos diferentes orientados hacia la simulacin. Estos modelos es-
taran optimizados para reducir el tiempo que se emplea en una simulacin, que en
ocasiones puede ser realmente largo (incluso de varios das).
Esta cantidad de versiones distintas, con diferentes orientaciones y en dife-
rentes etapas de desarrollo, deben ser gestionadas correctamente para evitar pro-
blemas.
6.3.1. Bibliotecas y componentes de biblioteca
En primer lugar conviene destacar qu entendemos por un componente de bibliote-
ca. Una biblioteca de componentes es, habitualmente, un conjunto de archivos con
informacin referente a diferentes mdulos o componentes. Cada entrada a la
biblioteca, que rene informacin respecto a un componente en particular es un
componente de biblioteca. Cada componente de biblioteca puede disponer de varias
vistas, que se corresponderan con diferentes informaciones o aspectos del compo-
nente. As, el componente de biblioteca podra disponer de modelos VHDL para
simulacin, modelos para sntesis, documentacin, modelos fsicos, etc. En general,
hablaremos indistintamente de componentes, mdulos o elementos de biblioteca.
La Figura 6-7 presenta un esquema de una biblioteca de componentes con diferen-
tes vistas para un componente en particular.
Adems, las bibliotecas pueden contener componentes con distintos objetivos.
En primer lugar se dispone normalmente de bibliotecas de recursos; stas son bi-
Docurnentacin 1 " ~ ijModelo
(para usuario) =- =- VHOL
(para simulacin)
Modelo i ~/
temporal " Topografa
(para anlisis MUX (para diseo fsico)
de tiempos) '-.........
~ / ~ Smbolo
netlst ~ U(para esquemas)
FIGURA 6-7. Diferentes vistas del mismo componente dentro de una biblioteca.
iQ
-
DEC -
CPU. =-MEM
Ni I
1 4 ~~_ ~. o o _ p , " . " ~ I
FIGURA 6-8. Relacin de jerarqua entre las bibliotecas generadas o usadas en un
diseo.
blio tecas que co ntienen elemento s bsico s utilizado s en to do s lo s diseo s. Entre
ellas p o demo s enco ntrar las biblio tecas STD y IEEE que no rmalmente so n utiliza-
das en to das las descrip cio nes VHDL.
En segundo lugar se disp o ne de bibliotecas de componentes; stas so n biblio -
tecas que co ntienen elemento s de distinta co mp lejidad que sern incluido s dentro
de algn diseo . Po dramo s tener, p o r ejemp lo , una biblio teca de mdulo s p erifri-
co s tp ico s (mdulo s detransmisin/recep cin serie asncro na, p uerto s deEIS p ara-
lela, etc. ), de la que seleccio namo s alguno p ara nuestro diseo . Tambin estn in-
cluidas en esta catego ra las biblio tecas dep uertas tp icas delo s fabricantes.
Finalmente tenemo s la biblioteca de diseo; en ella se incluyen to do s lo s ele-
mento s que fo rman p arte de nuestro diseo . Esta biblio teca har referencia a ele-
mento s de la biblio teca derecurso s y de las biblio tecas de co mp o nentes. Lo s co m-
p o nentes de estas biblio tecas no rmalmente sern co mp o nentes de cierta co mp le-
jidad.
La Figura 6-8 muestra la jerarqua existente entre esto s tres tip o s de biblio -
tecas.
La co mp lejidad delo s co mp o nentes debiblio teca vara desde p uertas hasta mi-
cro p ro cesado res. Las necesidades de gestin de labiblio teca dep enden en gran me-
dida del tip o deco mp o nente co nsiderado . Lo s co mp o nentes debiblio teca sep ueden
clasificar atendiendo avarias de sus caractersticas, las cuales no so n necesariamen-
teexclusivas.
En p rimer lugar sep ueden clasificar lo s co mp o nentes atendiendo asu co mp le-
jidad funcio nal. As, p o dramo s hablar de:
Baja complejidad: como puertas, decodificadores, multiplexores o incluso
memorias, sumadores, multiplicadores, etc.
Complejidad media: como interfaces, puertos de E/S paralela, circuitos de
transmisin/recepcin y otros dispositivos perifricos tpicos.
Alta complejidad: como ncleos demicroprocesadores, microcontroladores,
procesadores digitales deseal, coprocesadores, etc.
Aparte deesta primera divisin, los componentes pueden clasificarse atendien-
do alas caractersticas de sus modelos desimulacin o alaforma en que son imple-
mentados en silicio. En cuanto a sus modelos de simulacin, pueden dividirse en:
Precisos: stos son componentes que contienen informacin detallada sobre
su comportamiento, de forma que podemos realizar simulaciones con carac-
tersticas reales (retardos, consumo, rea... ).
Compatibles: son componentes que contienen informacin completa respec-
to a su funcionalidad pero sin caractersticas reales (tpicamente modelos
RT). Cuando se simulan, estos modelos se comportan igual que el circuito
real en una simulacin basada enciclos dereloj.
Algortmicos: estos modelos contienen slo lainformacin funcional bsica.
Son tiles en aquellas simulaciones que consumen mucho tiempo de CPU.
Podemos pensar, por ejemplo, en la simulacin deun programa complejo en
un microprocesador, olasimulacin deun filtro digital, etc.
En cuanto al mtodo deimplementacin en silicio, los componentes sepueden
clasificar en :
Bloques fijos (Hard Blocks): stos son componentes ya implementados que
poseen una descripcin fsica completa (layout) y que pueden ser caracteri-
zados con detalle en cuanto asu rea, retardos o consumo. Estos bloques son
dependientes delatecnologa.
Listas de puertas e interconexiones (netlists): estos componentes respon-
den auna descripcin estructural del circuito con referencias aceldas preca-
racterizadas del fabricante (puertas, memorias, etc.). Los detalles finales de
la implementacin (retardos de la interconexiones, etc.) no son an conoci-
dos. Estos bloques sondependientes delatecnologa.
Bloques HDL (Soft Blocks): stos son componentes descritos en un leguaje
de descripcin hardware que sern sintetizados con una biblioteca determi-
nada. En este caso, an no seconoce con detalle la lgica final que segene-
rar. Estos bloques son independientes delatecnologa.
Por ltimo, atendiendo ala configurabilidad del componente, stos pueden ser
divididos en:
Componentes cerrados: cuya funcionalidad es fija, independientemente del
modelo de simulacin o latcnica de implementacin utilizada. Como ejem-
plo, podramos pensar en un contador deO a 13, con inicializacin asncrona.
Genricos: son componentes que poseen algunos parmetros cuantitativos
que no cambian lafuncionalidad bsica del componente. Como ejemplo, po-
dramos pensar en el mismo contador deantes, pero con la cuenta final para-
metrizable.
Configurables: son componentes que poseen algn parmetro cualitativo
que s modifica lafuncionalidad bsica. Por ejemplo, en el caso del contador,
podra tener un parmetro que hiciese que contase hacia arriba, abajo o que
contase hacia arriba o abajo en funcin deuna seal, que tuviese o no inicia-
lizacin asncrona, etc.
6.3.2. La biblioteca de diseo
En el caso delos diseos realizados en VHO L, labiblioteca dediseo consiste, fun-
damentalmente, en un conjunto de ficheros de texto. Estos ficheros contienen la
descripcin VHO L de los componentes que forman el diseo y de los bancos de
prueba utilizados.
Cuando el diseo adquiere una cierta complejidad, o existe m~1>de un disea-
dor en el equipo, es necesario establecer mecanismos para que todos los diseado-
res accedan ala informacin correcta. Supongamos que en nuestro equipo de dise-
o (el que est diseando la mquina de refrescos) trabajan dos personas. Uno
podra estar dedicado alacircuitera encargada delagestin del cobro y devolucin
demonedas mientras el otro podra estar acargo delaparte relacionada con lapro-
gramacin de los precios. Es probable que uno necesite trabajar con los resultados
del otro. Si no seestablecen los mecanismos adecuados puede ocurrir que setrabaje
con versiones errneas, obsoletas, oque los dos diseadores realicen modificacio-
nes sobre un componente al mismo tiempo. Es, por tanto, necesario organizar labi-
blioteca deforma adecuada para evitar estos problemas.
Existen herramientas comerciales que nos facilitan esta tarea, aunque no siem-
pre estn disponibles. Por ello, acontinuacin se muestra un procedimiento bsico
que puede valer como idea sobrecmo organizar labiblioteca dediseo.
La Figura 6-9 muestra el caso de un diseo en el que existen dos diseadores.
Cada diseador dispone de un directorio de trabajo en el que desarrolla el compo-
nente que leha sido asignado. Por otro lado, existe un directorio general (la biblio-
teca de diseo) donde sevan dejando los resultados decada mdulo una vez que se
cree terminado. La biblioteca de diseo dispone adems de un fichero con la infor-
macin referente alos mdulos incluidos, quin los dise, versin, etc. El director
del equipo de diseo ser el encargado de gestionar la biblioteca. Existen tres pro-
cedimientos bsicos de actuacin sobre labiblioteca; insercin, extraccin y actua-
lizacin.
Cuando un elemento del diseo ha sido terminado se inserta en la biblioteca
global, quedando apartir de ese momento accesible al resto de los diseadores. Si
Mod_1,beld
E\ _
Mdulo 1 ~-- ~ Pararn.vhd
.--U - Funcs.vhd
"<, Types.vhd I Nombre:VmeFuncs.vhd

_ ~ I ~ Versin: 3.2~
vmeOttier.vhdE ...... E-~ . ~= ->
MasterTB.vhd Master.vhd -~ ~ Master.vhd lE
_______ -;- - I ~ 8Design.bdd
[i\: : ~-~
M: N.belda : / \ ~
MduloN /T.~ /.~~. !,~E ~l h d
~ ~ . ~ I Funcs.vhd
l ZJ ~ ~_. ~ .
Inter.vhdSlave.vhd Types.vhd
(copia)
Nombre:VmeTypes.vhd
Versin:3.1
Fecha: 13/02195
Autor: J . Snchez, y. Torroja
Descripcin:Tipos bsicos del diseo
Dependencias:--
E
Base de datos Fichero Fichero Procedimiento
(directorio) local global de gestin
(modificable) (no modificable) de la BDD
FIGURA 6-9. Organizacin de una biblioteca de diseo.
un d isead or necesita trabajar con un md ul o d el abibl ioteca no tend r ms que re-
ferenciarl o d entro d el md ul o que est real izand o. Si un d isead or necesita real izar
al guna mod ificacin sobre un md ul o que ya est incl uid o en l a bibl ioteca, d eber
primero extraerlo sobre sud irectorio d etrabajo, real izar l as mod ificaciones necesa-
rias y una vez que h a sid o comprobad o actualizarlo. Este proced imiento d e actual i-
zacin posibl emente requerir que el resto d e l os d isead ores real icen cambios
sobre sus md ul os, por l o que este tipo d emod ificacin d ebe minimizarse en l ame-
d id a d el o posibl e. Los fl ujogramas d e l aFigura 6-10 muestran, d eforma esquem-
tica, l os pasos areal izar en cad a una d e l as acciones d e gestin d e l a bibl ioteca d e
d iseo.
Los proced imientos d e gestin d e l a bibl ioteca, como cual quier proced imiento
d e gestin, d eben ad aptarse a l a compl ejid ad d el d iseo. En d iseos pequeos, o
con pocos d isead ores, pued en no ser absol utamente necesarios eincl uso introd ucir
d emasiad a carga d e trabajo. Por el contrario, si el d iseo es grand e o el nmero d e
d isead ores es el evad o, no util izar estos proced imientos pued e h acer impracticabl e
el d esarrol l o d el proyecto.
oc =>Componente del diseo
TB =o> Banco de pruebas
BDD =>Base de datos (directorio)
BDG =>Base de datos global (biblioteca)
BOL =>Base de datos local (componente)
.vhd =o> Fichero de cdigo VHOL
.bdd =>Fichero de informacin de la BDD
FIGURA 6-10. Operaciones bsicas en la gestin de una biblioteca de diseo.
6.3.3. Gestin de bibliotecas. Versiones y configuraciones
El nmero demodificaciones que serealizan alo largo del diseo deun mdulo en
VHDL puede ser realmente elevado. No es difcil encontrar que un determinado
componente ha sufrido un centenar de cambios desde su concepcin inicial a su
versin final, Durante este proceso de creacin la funcionalidad del componente es
modificada, y no siempre con buenos resultados. A menudo nos encontramos que la
ltima modificacin introducida no da los resultados esperados y que la anterior
versin del diseo funcionaba mejor. No hay experiencia ms frustrante que no po-
der recuperar la anterior versin deun diseo porque no recordamos dnde y cmo
exactamente hemos introducido los cambios. Sehace, por tanto, imprescindible un
cierto mantenimiento o control de versiones y configuraciones, Llevar un control de
versiones nos permite trabajar con la seguridad de que las versiones anteriores del
diseo estn correctamente archivadas, y de que siempre son recuperables. De esta
manera, cualquier modificacin que no sea satisfactoria puede ser anulada y la ver-
sin correcta recuperada.
6.3.3.1. Control de versiones
Consideramos una versin como cada uno de los estados por los que va evolucio-
nando una vista de un componente. En nuestra mquina de refrescos, por ejemplo,
el modelo arquitectural puede haber sufrido mltiples modificaciones (que terica-
mente daban resultados correctos) hasta llegar ala versin final. Cada uno de esos
diseos intermedios es una versin. Si de un determinado componente obtuvira-
mos una descripcin para sntesis y otra para simulacin, consideraramos que son
vistas diferentes del mismo componente, y no distintas versiones. Tendran, por tan-
to, distinto nombre, aunque podran tener las mismas versiones (por ejemplo, podra
haber una versin 1.35deambos modelos).
Existen infinidad demtodos para mantener un cierto control sobre las diferen-
tes versiones del diseo que sehan ido generando. Algunos deestos procedimientos
son rudimentarios. Podemos, por ejemplo, realizar una copia de todos los archivos
VHDL que hemos generado cada vez que creemos que tenemos una versin defini-
tiva, o cuando la magnitud de los cambios a introducir nos hacen pensar que la
vuelta atrs va a ser complicada. Este procedimiento, sin embargo, presenta multi-
tud de inconvenientes y a menudo se vuelve intil cuando el nmero de modifica-
ciones que serealizan sobre el diseo es elevado, oel nmero depersonas trabajan-
do sobre el diseo es grande.
Para realizar un control de versiones, lo primero que hay que definir es cules
son los ficheros que se mantienen bajo el control de versiones. Mantener todos los
ficheros que se utilizan durante el diseo sera un gasto intil, ya que muchos de
ellos pueden generarse apartir de otros mediante programas. Mantener un conjunto
mnimo tampoco es una buena idea, yaque lageneracin de algunos ficheros es un
proceso costoso y aveces lento. Por ello, debemos distinguir, en primer lugar, ladi-
ferencia entreficheros fuente yficheros objeto. Un fichero fuente es aquel que no
puede obtenerse de forma automtica apartir de otro fichero. Un ejemplo claro de
ficheros fuente son la mayora de las descripciones VHDL; stas son fruto de la
creatividad del diseador. Por el contrario, los ficheros objeto son aquellos que pue-
den obtenerse de forma automtica apartir de un fichero fuente. Un ejemplo claro
podran ser los resultados deunproceso desntesis automtica.
Todos los ficheros fuente deberan estar bajo el control deversiones. Los ficheros
objeto pueden no estar bajo control, aunque s puede ser conveniente si el proceso de
generacin delos ficheros objeto es largo ocomplejo (unproceso desntesis yoptimi-
zacin hastaobtener resultados satisfactorios puede durar varias horas). En general, se
considera que deben estar bajo control de versiones los siguientes tipos de archivos:
Fuentes en VHDL: deben mantenerse todos los ficheros fuente VHDL de
cada uno delos bloques diseados.
Bancos de prueba: al igual que los ficheros fuente de los bloques, los ban-
cos de prueba, tanto de los bloques como del circuito completo, deben estar
controlados.
Ficheros de comandos: normalmente, durante el proceso de diseo es nece-
sario repetir la misma accin varias veces (podemos pensar en el procedi-
miento de anlisis de los ficheros VHDL y su simulacin posterior). Para
ello, lo habitual es utilizar ficheros decomandos, donde sedetallan los pasos
arealizar de forma automtica. Guardar estos ficheros no slo permite repe-
tir los pasos realizados, sino que adems sirve como documentacin decmo
sehan realizado las diferentes tareas del diseo.
Adems deestos archivos fuente es conveniente mantener bajo control algunos
archivos objeto:
Vectores de simulacin: aunque estos ficheros pueden generarse de forma
automtica, es interesante poder acceder a ellos de forma directa. De esta
manera se ahorra tiempo, ya que estos ficheros seutilizan continuamente en
las simulaciones.
Listas de componentes einterconexiones (netlists): por la misma razn, es
interesante mantener estos ficheros. Por otro lado, estos ficheros son el resul-
tado deun proceso desntesis, que amenudo resulta costoso y difcil.
Topografia: este es el resultado final del diseo y, por tanto, debe ser conve-
nientemente archivado. Sin embargo, no debe mantenerse todas las versiones
que sehayan generado, yaqueson ficheros muy grandes.
Adems de los ficheros descritos, es necesario mantener un control de versio-
nes deladocumentacin que sevagenerando durante el proyecto. Normalmente, el
procedimiento decontrol dela documentacin es diferente al de los ficheros fuente
y objeto, por los que sertratado en otro apartado.
Existen multitud de herramientas para el control de versiones. Si trabajamos
bajo un sistema UNIX, habitualmente dispondremos de herramientas bsicas para
realizar el mantenimiento de versiones con distintas prestaciones (como son sees,
ReS, evs, etc.). En otros sistemas operativos ser necesario conseguir alguna he-
rramienta para llevar el control. Casi todas las herramientas existentes estn pensa-
das para el mantenimiento de ficheros de texto. Pueden valer para mantener fiche-
ros binarios, pero en este caso los sistemas de compresin utilizados hacen que el
archivo delas diferentes versiones seamenos compacto.
Las versiones suelen identificarse mediante dos nmeros; el nmero deversin
y el numero deedicin. Los cambios en el nmero deedicin implican correcciones
menores, reparacin de problemas, etc., pero no cambios en la funcionalidad o la
interfaz de un bloque. Si hablamos dedocumentos, los cambios en la edicin supo-
nen correcciones ortogrficas o mejoras en la redaccin de algunos puntos. Por el
contrario, los cambios de versin suponen cambios mayores, tanto en funcionali-
dad, interfaz de un bloque o, si hablamos de documentos, introduccin de nuevos
prrafos o modificaciones importantes delos existentes.
6.3.3.2. Control de configuraciones
Consideramos una configuracin como un conjunto de versiones que forman una
unidad operativa. Podemos pensar, por ejemplo, en el conjunto de ficheros VHDL,
bancos deprueba, procedimientos decomandos, etc., que existan en un determina-
do momento dela historia del diseo. LaFigura 6-11 muestra grficamente el con-
cepto deconfiguracin comparado con el concepto deversin.
Como se ve, un determinado componente puede ir evolucionando atravs de
distintas versiones. Al principio del proyecto, en la figura, el diseo (asic.vhd
v1.0) es comprobado mediante un determinado banco depruebas (tb.vhd vl.O). En
un determinado instante se decide que el banco depruebas no es cmodo para rea-
lizar la validacin funcional y se implementa un modelo de una CPU (cpu.vhd
v1.0) que ejecuta un determinado programa (prog.cpu v1.0). Posteriormente se
mejora la CPU, posiblemente introduciendo o cambiando los cdigos de opera-
cin, con lo que sehan demodificar tambin los programas. Como sepuede obser-
var, no todas las versiones delos componentes son compatibles entre s. Si intent-
semos que la CPU vl.O ejecutase el programa PROG v1.2 nos encontraramos con
que no es posible. Tampoco podramos, por ejemplo, recuperar la primera versin
del ASIC y simularla con la CPU. En un determinado instante detiempo existe un
conjunto de versiones (Cl, C2, ... en la figura) que forman una unidad operativa
(simulable, sintetizable, etc.). Este conjunto puede estar formado por ficheros
VHDL, ficheros decomandos y cualquier otro tipo deficheros que sean necesarios
para trabajar con el diseo. Cuando se recupera una determinada versin de un
componente deberan recuperarse tambin todas las versiones necesarias para su
operacin.
01
ASIC
diseo
05 Banco de Pruebas
FIGURA 6-11. Configuraciones y versiones en la gestin del diseo.
ASIC
diseo
01
Banco de Pruebas
FIGURA 6-12. Ajuste ficticio de versiones para el mantenimiento de configura-
ciones.
No existen demasiadas herramientas que trabajen con versiones y configuracio-
nes. Decualquier manera, esta consideracin debe ser tenida en cuenta para no per-
der las ventajas que aporta el mantenimiento de versiones. Si no se dispone de
herramientas para el mantenimiento de configuraciones, una posible solucin es
mantener versiones ficticias delos ficheros queconfiguran undiseo. LaFigura 6-12
muestra cmo seaplicara esto al ejemplo anterior.
En la figura, los rectngulos en color claro reflejan diferentes versiones de un
fichero. Los rectngulos en color oscuro reflejan versiones ficticias (seha generado
una nueva versin, aunque no hahabido modificacin alguna en el fichero). Como
seobserva, se han ido creando versiones adicionales de todos los componentes, in-
cluso si stos no han sido modificados. De esta manera, recuperar una determinada
configuracin del diseo consiste en recuperar la misma versin de todos los fiche-
ros del diseo. Este mtodo, aunque vlido, oculta en cierta medida la historia del
componente (un determinado mdulo tiene muchas ms versiones de las que real-
mente sehan producido).
6.4. DISEO PARA REUSABILIDAD
El trmino reusabilidad pretende reflejar la facilidad con la que un diseo previa-
mente realizado puede ser utilizado de nuevo, probablemente para otra aplicacin,
con otra tecnologa y por diferente equipo dediseo.
6.4.1. Por qu hacer diseos reutilizables?
El coste dedesarrollo delos diseos y componentes actuales, as como ladisponibi-
lidad deherramientas desntesis y latendencia actual acrear mercados abiertos, ha-
cen cada vez ms atractiva la idea de la reutilizacin de componentes previamente
diseados. Estos componentes pueden haber sido diseados como parte de un pro-
yecto y reutilizados posteriormente, o generados de forma explcita como compo-
nentes debiblioteca para suposterior reutilizacin. En ambos casos, lareutilizacin
deestos componentes presenta una serie derequisitos y problemas que es necesario
resolver.
La reutilizacin delos componentes presenta ventajas claras en multitud de as-
pectos. Por un lado, reduce los costes de diseo de un componente al utilizarlo (y,
por lo tanto, amortizarlo) en varios proyectos. Esto es ventajoso tanto para quien di-
se el componente como para el usuario final del mismo. Al primero le permite
abaratar los costes dedesarrollo, haciendo ms atractivos sus productos. Al usuario
final le permite acceder auna tecnologa ms barata. Por otro lado, los componen-
tes previamente diseados (y previamente utilizados) tienen mayores garantas en
cuanto asu funcionamiento, ya que han sido comprobados y depurados en anterio-
res proyectos. De nuevo esto supone una ventaja tanto para el usuario, que corre
menos riesgos, como para el diseador, que ofrece productos demayor calidad, au-
mentando suclientela.
Pero no slo es importante lareduccin del coste del desarrollo. La gran com-
petencia del mercado electrnico hace que el tiempo dedesarrollo seaun factor cru-
cial en el xito final del producto y su rentabilidad. Un producto que no llega a
tiempo al mercado es un producto que pierde gran parte de su cuota de mercado, y
no slo porque otros productos delacompetencia learrebaten parte del mismo, sino
porque larpida evolucin de las tecnologas y las prestaciones de los circuitos in-
tegrados puede hacer que un circuito, que cuando seespecific era competitivo, re-
sultemediocre uobsoleto si sehatardado demasiado en sudesarrollo. Utilizar com-
ponentes de biblioteca previamente desarrollados puede reducir en gran medida el
tiempo dediseo y evitar este tipo deproblemas.
Sin embargo, no debe pensarse slo en los componentes reutilizables como
mdulos diseados con la idea de ser comercializados eincluidos en otros diseos.
Utilizar ciertas tcnicas de diseo que faciliten la reutilizacin de un componente
puede aportar grandes ventajas en el desarrollo de un circuito incluso si no se est
pensando en su posterior reutilizacin. La experiencia muestra que, en la mayora
de los diseos, aparecen imprevistos que obligan amodificar el diseo en mayor o
menor medida. A menudo, las especificaciones de un circuito no son completas, o
hay aspectos que antes de comenzar el desarrollo son difciles decuantificar o pre-
ver. Esto obliga amantener ciertos parmetros del diseo abiertos hasta que un an-
lisis ms detallado permita definirlos. Un ejemplo tpico podra ser el nmero de
bits necesarios para codificar los datos o los coeficientes en un filtro digital. Aspec-
tos como el rea, el consumo, o la mxima frecuencia de funcionamiento pueden
obligar a cambiar algunas de las caractersticas que se haban fijado inicialmente
para el diseo. Algunas de las tcnicas que se exponen en los siguientes apartados
pueden ayudar aque estos cambios y modificaciones alo largo del ciclo de diseo
repercutan lo menos posible en el tiempo de desarrollo y en la calidad y fiabilidad
del circuito diseado.
Si, por el contrario, el objetivo deun diseo es que ste pase aformar parte de
una biblioteca de componentes reutilizables, habr que considerar algunos aspec-
tos adicionales alos puramente tcnicos. En este caso hay que tener en cuenta que
para que un diseo sea reutilizable no slo es necesario que sea correcto en los as-
pectos funcionales, sino que adems debe satisfacer una serie de requisitos en
cuanto a su documentacin, su portabilidad entre herramientas, su facilidad de
mantenimiento, etc. Estos aspectos tambin sern tratados acontinuacin.
6.4.2. La comercializacin de una biblioteca
Los requisitos que un componente de biblioteca debe satisfacer dependen de quin
los utilice y cmo los utilice. Si, por ejemplo, nos fijamos en el punto de vista del
usuario, es decir, la persona que va autilizar el componente en su circuito, su ma-
yor preocupacin ser posiblemente la integracin sin problemas del componente
en suflujo dediseo. Esto implicar que el componente est disponible para sus he-
rramientas, que exista una buena documentacin, etc. Si atendemos al punto devis-
tadel diseador, es decir, lapersona que desarrolla el componente para suposterior
comercializacin, su mayor preocupacin ser encontrar mtodos para proteger y
comercializar su biblioteca, mtodos para facilitar el mantenimiento y depuracin
de errores, etc. Si pensamos en la fabricacin del circuito, estaremos ms interesa-
dos en el test defabricacin y, por tanto, en laexistencia devectores de test para el
componente y mtodos para aplicarlos cmodamente. Por ltimo, si nos fijamos en
el punto de vista del comercial, es decir, lapersona que vaavender el componente,
seguramente estar ms preocupado en lafiabilidad del componente, el soporte tc-
nico, cmo haresultado suutilizacin en otros diseos, etc.
Teniendo en cuenta todos estos aspectos, podemos elaborar una lista derequisi-
tos que todo componente debera satisfacer para que resulte industrialmente reutili-
zable.
Interoperabilidad: el componente debera estar disponible para diferentes
herramientas, ya que cada usuario dispone de sus propias herramientas, y no
todas trabajan con el mismo subconjunto de VHDL (tanto en sntesis como
en simulacin).
Documentacin: una de las claves de la reusabilidad es disponer de una
buena documentacin, consistente en:
- Documento de diseo: es el documento ms importante para el diseador
y/o lapersona encargada del mantenimiento y depuracin del componente;
contiene toda la documentacin relativa acmo sehadesarrollado el com-
ponente, explicacin delaarquitectura, cdigo VHDL, etc.
- Gua de referencia: algunos componentes de biblioteca pueden ser extre-
madamente complejos. Si estos componentes son configurables, su utiliza-
cin puede requerir laseleccin correcta dediferentes parmetros por parte
del usuario. En estos casos puede ser necesaria una gua donde se describa
cmo configurar, simular y sintetizar correctamente el componente.
- Hoja de catlogo: al igual que ocurre con los componentes discretos, dis-
poner de una hoja de catlogo facilita la consulta y seleccin del compo-
nente por parte del usuario. Esta hoja debera contener toda la informacin
necesaria para la seleccin y operacin del componente.
- Notas de aplicacin: los ejemplos son una ayuda ideal a la hora de utilizar
un componente. Debera haber notas de aplicacin disponibles tanto para el
uso del componente de biblioteca (especialmente si ste es configurable)
como para su operacin.
- Problemas y soluciones: las descripciones VHDL se encuentran a mitad
de camino entre el software y el hardware. Si el componente es complejo,
podra tener algunos errores que, aunque no impidiesen su utilizacin, es
necesario conocer y plantear alternativas para su solucin.
Soporte tcnico y mantenimiento: como en cualquier otro producto, estos
factores son crticos para la comercializacin del componente.
Estimadores: cuando los componentes son genricos o configurables, el di-
seador necesita encontrar la mejor combinacin de parmetros que satisfaga
sus requisitos. En estos casos no resulta factible sintetizar el componente ba-
jo cada posible combinacin de parmetros, ya que el tiempo empleado en la
sntesis puede ser elevado. Resulta, por tanto, muy til disponer de estimado-
res fiables de rea, retardos o consumo.
Herramientas de configuracin: en diseos configurables complejos pue-
den necesitarse herramientas que ayuden al usuario a configurar el compo-
nente de acuerdo a sus requisitos.
Herramientas de validacin: en componentes de mediana o alta compleji-
dad pueden hacerse necesarias funciones que faciliten al usuario la simula-
cin del circuito o del sistema completo. Podramos imaginar, por ejemplo,
un usuario que est utilizando un transmisor/receptor sncrono de una deter-
minada biblioteca de componentes. Para comprobar que el componente fun-
ciona o es operado correctamente, le sera muy til disponer de funciones en
VHDL que le permitiesen transmitir mensajes hacia el componente correcta-
mente formateados (con la velocidad de transmisin adecuada, el CRC aa-
dido, etc.). En otros casos, cuando la complejidad del componente de biblio-
teca hace poco recomendable la simulacin a nivel RT, sera conveniente
disponer de modelos algortmicos o de alto nivel de la celda.
Soporte para la deteccin de errores: los componentes de biblioteca van a
estar normalmente inmersos en diseos ms complejos, y estarn controlados
por otros componentes o partes de la lgica del circuito. Al igual que en los
componentes ms simples (biestables, puertas) existen mtodos para detectar
situaciones peligrosas, como violaciones en los tiempos de establecimiento
(set-up time) y mantenimiento (hold time), los componentes de biblioteca
complejos deben contar con mtodos para detectar operaciones errneas por
parte de lalgica que lo opera (por ejemplo, una secuencia incorrecta de se-
ales, valores no controlados enbuses, etc.).
Soporte para el test de fabricacin: cada componente debera disponer de
un conjunto de vectores de test, o una circuitera de autotest, para realizar el
test de fabricacin. Esto es especialmente importante en el caso de los com-
ponentes configurables, donde el conjunto de vectores de test puede depen-
der en gran medida delaconfiguracin escogida.
La interoperabilidad, documentacin o soporte tcnico son requisitos que pue-
den ser satisfechos con mayor o menor esfuerzo. Sin embargo, hoy por hoy, el resto
delos requisitos son ms difciles decumplir.
A la hora de desarrollar una biblioteca de componentes para su comercializa-
cin, deben valorarse con cuidado estos factores. Satisfacer estos requisitos puede
implicar un esfuerzo considerable, lo que en algunos casos puede hacer econmica-
mente inviable el desarrollo. .
Decualquier manera, lacomplejidad delos diseos actuales hace cada vez ms
atractiva la idea de su reutilizacin y comercializacin. En este sentido, cada da se
dedica un esfuerzo mayor al diseo de lo que se conoce como celdas IP (Intellec-
tual Properties), es decir, componentes debiblioteca deelevada complejidad, sumi-
nistrados por una determinada casa comercial, a partir de los cuales se realiza el
diseo. Estos componentes no suelen ser genricos o configurables, sino que res-
ponden a un esquema de componente cerrado (funcionalidad fija) con modelos de
simulacin precisos ocompatibles, y en muchos casos ofertados como bloques fijos
(hard blocks).
Hoy en da es posible acceder aestas celdas IP con dos objetivos fundamenta-
les: disponer demodelos para simulacin y demodelos para fabricacin.
Los modelos para simulacin nos permitirn analizar el comportamiento de
un sistema que incluye este tipo deceldas o circuitos. Por ejemplo, si vamos adi-
sear un circuito que interacta con un microprocesador SPARC, o Pentium,
nos ser de gran utilidad disponer de los modelos VHDL de los microprocesado-
res, para as simular el comportamiento del sistema completo. Existen un gran n-
mero de casas que ofrecen modelos para simulacin en VHDL de diferentes com-
ponentes (microprocesadores, microcontroladores, circuitos perifricos, lgica
discreta, etc.).
Los modelos para fabricacin nos permitirn no slo simular el comportamien-
to del sistema sino tambin fabricar el circuito una vez diseado. En este caso, el
nmero de casas que distribuyen este tipo de componentes es ms limitado, yaque
requiere el soporte de un fabricante que ser el que finalmente producir el circuito
que diseemos con la celda IP inmersa en l. Esto obliga aque el diseo serealice
con un determinado fabricante, lo que en algunos casos dificulta el diseo (por
ejemplo, podramos querer disear el circuito en tecnologa ECL, pero slo dispo-
ner delas celdas IP que deseamos en tecnologa CMOS).
Una tercera posibilidad es acceder a modelos sintetizables. En este caso, el
usuario no est atado aun fabricante determinado, yaque puede sintetizar el circui-
to, con lacorrespondiente celda IP, utilizando cualquier tecnologa. Sinembargo, en
el caso de celdas IP complejas, la sntesis automtica no resulta econmicamente
viable en la mayora de los casos. Las celdas ofertadas como bloques fijos (hard
blocks) estn normalmente implementadas de forma muy optimizada (mediante es-
tructuras tipo data-path, generadores de estructuras regulares, eincluso tcnicas de
diseo totalmente amedida ofull-custom), con lo que resultan mucho ms rentables
que las que seobtendran mediante una sntesis automtica.
Lautilizacin deceldas IP est generando una nueva corriente dediseo que se
aleja del diseo actual alamedida, volviendo aun diseo similar al que serealizaba
mediante componentes discretos. No debe pensarse, sin embargo, que esto es un
paso atrs. La tendencia actual es utilizar el mayor nmero posible de celdas IP, ya
diseadas, y disear la lgica imprescindible para unir las celdas IP o incluir la
funcionalidad no disponible. La diferencia fundamental con el proceso de diseo
basado en componentes discretos es que ahora, gracias a los lenguajes de descrip-
cin de hardware, es posible simular el sistema completo antes de proceder a su
fabricacin.
La utilizacin de celdas IP, que a menudo contienen decenas e incluso cientos
demiles depuertas, est imponiendo nuevos desafos al proceso dediseo. La difi-
cultad para simular un circuito que contenga varias deestas celdas (un sistema inte-
grado o System On Silicon) obliga a disponer de modelos de alto nivel (algortmi-
cos, de juego de instrucciones, etc.) de los componentes. Con estos modelos se
podr realizar lasimulacin del sistema completo aun coste razonable.
6.5. DISEO GENRICO
Una de las ventajas fundamentales delos HDLs es que permiten, deforma sencilla,
generalizar el diseo. As, cuando sedisea un componente, ciertos valores pueden
quedar como parmetros que se concretarn ms adelante en el proceso de diseo.
Ejemplos tpicos son el final decuenta deun contador, el ancho del bus deunregis-
tro paralelo, el nmero debits deuna ALU, etc.
Esta facilidad para dejar ciertos datos como parmetros permite lareutilizacin
del componente en diseos posteriores. Adems, permite que parte de las especifi-
caciones del diseo queden abiertas, 10 que facilita la toma de ciertas decisiones
que, en otro caso, podran restringir el desarrollo.
Pero para aprovechar al mximo estas posibilidades es necesario considerar
ciertos aspectos y mantener unos procedimientos de trabajo que garanticen que el
esfuerzo invertido en realizar el diseo genrico va a ser aprovechable posterior-
mente.
En este apartado se dan una serie de recomendaciones sobre cmo realizar un
diseo genrico y cules son sus ventajas einconvenientes.
6.5.1. Definicin de diseo genrico
En primer lugar, conviene acotar qu entendemos por diseo genrico, yaque exis-
ten diferentes interpretaciones deeste concepto.
A lo largo del apartado seentender que un diseo genrico es aquel en el que
sepueden variar ciertos parmetros del diseo sin variar la funcionalidad a nivel
RT del mismo. Paralelamente sepuede hablar de diseos configurables, en donde
la variacin de ciertos parmetros afecta de forma que el diseo s cambia su fun-
cionalidad anivel RT.
El siguiente ejemplo puede clarificar estos conceptos. El cdigo del Listado 6-13
muestra uncontador sncrono ascendente/descendente.
e nt i t y As c De s c Co nt a do r l e
ge ne r l c ( gMa x Bi t s : i nt e ge r :=4) ;
port(
~e l o j ins t d_ l o gi c ;
I ni c i o N in s t d_ l o gi c ;
As c De s c ins t d_ l o gi c ;
CUe nt a o ut s t q_ l o gi c _ v e c t o r ( gMa x B t s - 1 do wnt o O)
);
end As c De s c Co nt a do r ;
a r c hi t e c t ur e S l l pl e of As 9De Sc Co nt a do r l s
c o ns t a nt c Ul t i mo Y a l o r t s t q_ l o gi c _ v e c t o r ( gMa x Bi t s ' ~ 1 do wnt o O)
:= (others => '1');
c o ns t a nt c P r i r ne r Va l o r : s t d_ l o gi c _ v e c t o r ( gMa x Bi t s - 1 do wnt o O)
:= ( o t he r s => ' O' ) ;
s i gna l Int.Cuenta u s t q_ l o gi c " , v e c t o r ( gMa x B t s -1 do wnt o O);
begin
CUe nt a <=I nt CUe nt a ;
ppr a l : pr o c e s e (ReloJ,' I ni c i e N)
begin
i f I ni c i e N = ' O' t he n
I nt CUe nt a <= ( o t he r s => ' O' ) ;
e l s i f Re l o j ' e v e nt and Re l o j = '1' t he n
i f As c De s c = '1' t be n
i f I nt CUe nt a = c Ul t i mo Va l o r t he n
I nt CUe nt a <= ( o t be r s => ' O' ) ;
e l s e
I nt Cue nt a <., I nt CUe nt a + '1';
end U;
e l s e
i f I nt CUe nt a =' ~P r i r ne r Va l o r t he n
I nt Cue nt a <=I nt CUe nt a - '1';
e l s e
I nt CUe nt a <= ( o t he r s => '1').;
end U;
e nd if;
end if;
end pr o c e s s ;
end Si mpl e ;
LISTADO 6-13. Cdigo de contador ascendente/descendente.
En el contador, lamxima cuenta es un parmetro (gMaxBits) cuyo valor sefi-
jar con posterioridad. En este caso, el valor del parmetro no afecta al esquema
funcional anivel RT y slo cambia el nmero debits del contador.
Sin embargo, en el siguiente ejemplo semuestra el mismo contador con un pa-
rmetro adicional (gTipo) en funcin del cual se generar un contador ascendente,
descendente o ascendente/descendente.
e n t i t y Co n t a d o r Ge n r i c o i s
g e n e r i e (
g T i p o : i n t e g e r : = O;
_ O s i g n i f i c a c o n t a d o r a s c e n d e n t e
_1s i g n i f i c a c o n t a d o r d e s c e n d e n t e
_ r e s t o : s i g n i f i c a c o n t a d o r ascendente/descendente
g Ma x Bi t s i n t e g e r : = 4) ;
port(
Re l o j
I n i c i a N
As e Da s c
Cu e n t a
in s t d _ l o g i c ; _ s o l o u s a d a e n e l c o n t a d o r , Up/J :)own
o u t s t d _ l o g i c _ v e c t o r ( g Ma x Bi t s - 1 d o wn t o O)
);
end Co n t a d o r Ge n r i c o ;
a r c h i t e c t u r e S i mp l e o f Co n t a d o r Ge n r i c o i a
c o n s t a n t c Ul t i mo Va l o r s t d , _ l o g i c _ v e c t o r ( g Ma x Bi t s - 1 d o wn t o O )
: = ( o t h a r a => ' 1' ) ;
c o n s t a n t c P r i r n e r Va l o r s t d , _ l o g i c _ v e c t o r { g Ma x Bi t s - 1 d o wn t o O)
: = ( o t h a r a => ' O' ) ;
s i g n a l I n t Cu e n t a : s t d , _ l o g i c _ v e c t r ( g Ma x Bi t s -1 d o wn t o O );
begin
Cu e n t a <= I n t Cu e n t a
p p r a l : p r o c e a a ( Re l o j , I n i c i o N)
begin
i f I n i c i a N = ' O' t h e n
I n t Cu e n t a <= ( 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 = ' 1' t h e n
c a a e g T i p o is
wh e n O =>
i f I n t C e n t a = c Ul t i r n o Va l o r t h e n
tntcuenta <= (others => 'O');
e l a e
I n t Cu e n t a <= I n t Cu e n t a + '1';
end i f ;
wh e n 1=>
i f I n t Cu e n t a = c P r i me r Va l o r t h e n
rntcuenta <= I n t Cu e n t a - '1';
e l a e
I n t Cu e n t a <= ( o t h e r a => ' 1' ) ;
end i f ;
wh e n o t h a r a =>
i f AscDe~ = '1' then
ifI nt ~~t a = c Ul t i mo Va l o r then
t nt c ue nt a <= ( o t he r e => ' O' ) ;
e l e e
rntcuent' <= I nt CUe nt a + "r';
end i f ;
e l s e
i f I nt Cue nt a = c P r i me r Va l o r then
I nt CUe nt a <= I nt CUe nt a - '1';
e l e e
I nt CUe nt a <= ( o t he r s => ' 1' ) ;
end i f ;
e ndi f ;
e nd c a s e ;
e nd if;
end pr o c e s s ;
end Si r r pl e ;
LISTADO 6-14. Cdigo de contador genrico.
Enestecaso, lafuncionalidad del componente cambia al cambiar el parmetro.
Este sera el caso deun componente configurable frente al componente genrico
del ejemplo anterior.
6.5.2. Ventajas e inconvenientes del diseo genrico
Los cdigos mostrados enel apartado anterior sonunejemplo dediseo genrico o
configurable. Sin embargo, no muestran las ventajas nilos inconvenientes que se
obtienen al escribir cdigo deesta manera.
Antes dedescribir estas ventajas einconvenientes es necesario diferenciar en-
tredos tipos dediseos genricos; aquellos diseos en los que slo son genricos
alguno de los parmetros (parcialmente genricos) y aquellos (totalmente genri-
cos) enlos queseparametrizan todos los valores queadmitiran unvalor genrico.
A lo largo del apartado hablaremos dediseos totalmente genricos, mientras
no seespecifique 10 contrario.
Las ventajas fundamentales del diseo genrico son:
Permite mantener las especificaciones abiertas. Puesto quelos valores que
aparecen en el diseo son variables, es posible esperar aetapas ms tardas
del diseo para decidir suvalor final. Sinembargo, debeconsiderarse quees-
ta facilidad no implica que no sehayan tenido quedefinir dichos valores
durante la especificacin. Unexcesivo nmero degrados delibertad o deci-
siones retardadas puedeacarrear ms inconvenientes queventajas.
Evaluacin de alternativas. Al poder modificar los parmetros del diseo,
es posible evaluar alternativas que, enprincipio, podran no haber sido consi-
deradas. Este aspecto tiene especial relevancia cuando en las ltimas etapas
del diseo surgen restricciones (rea, tiempo, cambio de tecnologa) que
obligan a tomar soluciones de compromiso. En general, estas restricciones
no son consideradas en las primeras etapas del diseo. Realizar undiseo ge-
nrico lleva implcita suconsideracin.
Anlisis exhaustivo del diseo. Realizar un diseo genrico implica que el
componente a disear debe funcionar bajo todos los valores posibles de sus
parmetros. Esto requiere por parte del diseador un anlisis del problema
mucho ms exhaustivo que cuando se disea el mismo componente para
unos valores fijos de sus parmetros. Adems, el diseo genrico impone
unas pruebas funcionales que no slo verifican la funcionalidad del compo-
nente sino tambin el comportamiento del mismo al variar los parmetros.
Todo esto redunda en una verificacin mucho ms exhaustiva del componen-
teyunos bancos deprueba ms depurados.
Organizacin del diseo. De igual manera que el diseo genrico exige al
diseador unanlisis ms profundo del componente que est diseando, tam-
bin requiere del equipo dediseo una mejor organizacin delos ficheros, ti-
pos de datos, constantes del diseo, etc. Esta mejor organizacin redunda en
un ahorro importante de tiempo, especialmente si 'el equipo de diseo est
formado por varias personas.
Mejora del mantenimiento. Uno de los aspectos claves para hacer un dise-
o reutilizable es que disponga deuna buena documentacin. Parte delado-
cumentacin del diseo la constituye el propio cdigo HDL. Cuanto ms le-
gible sea el cdigo, ms fcil resultar su interpretacin y modificacin. El
realizar un diseo genrico implica que los valores constantes que normal-
mente aparecen en el cdigo son sustituidos por nombres de parmetros,
expresiones, etc. Si estos nombres y expresiones son escogidos bajo ciertas
reglas, su lectura e interpretacin ser sencilla, facilitando as la consulta y
mantenimiento del cdigo por personas distintas alas quelo realizaron.
Simplificacin del cambio de tecnologa (retargeting). La utilizacin de
HDLs permite, en teora, realizar diseos independientes delatecnologa en
la que finalmente se implementar el circuito. En la prctica, esto no siem-
pre es cierto. Factores como la velocidad, el consumo, la biblioteca o la ca-
pacidad de integracin, obligan a redisear muchas de las partes de un
circuito al cambiar de tecnologa. Es necesario, por tanto, escoger la tecno-
loga objetivo lo antes posible en el proceso de diseo. Sin embargo, la ex-
periencia muestra que, en muchos casos, es necesario cambiar la tecnologa
objetivo (bien sea por factores tecnolgicos, econmicos o polticos) cuan-
do se est bastante avanzado en el proceso de diseo. De nuevo, el diseo
genrico permite reducir los efectos negativos de estos cambios al permitir
el redimensionamiento sencillo de ciertos aspectos del diseo. Conviene in-
sistir, sin embargo, en que los cambios de tecnologa pueden suponer modi-
ficaciones muy importantes en el diseo y que deben evitarse en la medida
delo posible.
El diseo genrico presenta, por otro lado, una serie de inconvenientes que es
necesario valorar:
Complejidad del cdigo. En algunas ocasiones, el realizar un componente
genrico implica que en el cdigo se han de utilizar construcciones un tanto
artificiosas y difciles de seguir para el no iniciado. En este caso deben valo-
rarse con cuidado las ventajas del diseo genrico frente a la legibilidad del
cdigo. En cualquier caso, una buena documentacin y un cdigo bien co-
mentado ayudan mucho asucomprensin.
Dificultad en las pruebas. Realizar un diseo genrico implica que han de
realizarse pruebas funcionales para los diferentes valores que puedan tomar
los parmetros. Esto implica, a su vez, que los bancos de prueba deben ser
tambin genricos, lo que supone una dificultad adicional y una nueva fuente
deerrores. Si bien esto redunda en un anlisis ms profundo del diseo, pue-
de suponer un freno excesivo en algunos casos. Por otro lado, el nmero de
pruebas a realizar puede dispararse. Es necesario valorar con detalle estos
aspectos con objeto de llegar auna solucin decompromiso entre el coste de
desarrollo y los beneficios esperados.
Tiempo de desarrollo. En general, ste es el aspecto ms difcil de valorar.
En un principio, el diseo genrico implica un tiempo mayor de desarrollo.
Sin embargo, esta inversin de tiempo en las fases iniciales del diseo va a
suponer un ahorro importante en las etapas finales, especialmente si surgen
problemas no contemplados inicialmente. Aspectos como lacapacidad delos
diseadores, la tradicin del equipo de diseo en esta filosofa de trabajo, la
complejidad del diseo, etc., deben ser considerados para valorar la viabili-
dad de este enfoque. La experiencia del equipo en algn diseo de estas ca-
ractersticas puede ayudar en gran medida.
Prestaciones del resultado. En algunos casos, lageneralidad en el diseo va
arequerir un compromiso respecto alas prestaciones del mismo. Si el diseo
se encuentra muy al lmite de la tecnologa, las soluciones a cada problema
sern demasiado particulares como para permitir undiseo genrico.
Como conclusin cabedecir que el diseo genrico puede paliar en gran medida
los problemas inesperados que sepresentan en las etapas finales del proceso de dise-
o. Su realizacin supone un coste adicional en tiempo de desarrollo. La experiencia
muestra, sinembargo, queestetiempo invertido es claramente recuperado por lasven-
tajas que aporta este tipo de diseo. Slo si el diseo est absolutamente cerrado en
las especificaciones, puede tener sentido no realizar el diseo con esta aproximacin.
6.5.3. Desarrollo decomponentes genricos.
Recomendaciones
Las recomendaciones y ejemplos que acontinuacin se exponen han sido proba-
das con un determinado sintetizador y/o simulador. En un principio, estas reco-
mendaciones podran no ser aplicables para otras herramientas. Sin embargo, s
pueden dar una idea del objetivo que sepretende conseguir realizando diseos ge-
nricos.
6.5.3.1. Organizacin del diseo
Existen muchas maneras diferentes derealizar un diseo genrico. En general, con-
viene diferenciar dos casos que requieren un planteamiento diferente: el diseo de
un componente y el diseo deun circuito odispositivo completo.
Diseo de un componente aislado. En este caso el objetivo del diseo gen-
rico ser realizar un componente reutilizable. El procedimiento ms cmodo
en este caso es utilizar genricos (generic) del VHDL como procedimiento
para pasar parmetros.
En estos casos debe tenerse en cuenta que el interfaz con el exterior se
har atravs de tipos estndar (std_logic o std_logic_vector), yaque sedes-
conoce el entorno donde va a utilizarse el componente. Este es el procedi-
miento normal de parametrizacin de componentes. Sin embargo, el diseo
genrico presenta ms ventajas en el caso dediseos completos.
Diseo de un circuito o dispositivo completo. En este caso el planteamien-
to debe ser ms riguroso, aunque los beneficios tambin son mayores.
Se organizar el diseo de forma que exista un fichero donde se definan todos
los tipos bsicos y constantes utilizados en el diseo. El control y modificaciones de
este fichero sonresponsabilidad del jefe del equipo dediseo.
El siguiente cdigo muestra unpaquete deeste tipo.
package TiposBasicos is
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = ~ = = = = = ; : = = = = = = = = = = = = = = = = ~ = = = = - - = = = =
-~-------~-,--':"".-:"",--.--------------:,---~-~--..; ...~-----",,----'-_ ._.... _ ~-
-- ,<;qn&~1*> definj,dap para el manejo deJ os ,.datos en 9en~al
constant ~BitsDatos
constant cBitscoef
constant cBitsNorma
: natural .- ' 9 ;
, : riatUfil :=' 6;
: natural x 5;
constant cBitsMaxlnterval : natural'::= ,1;
constant cMaxlnterVal : integer := 2i
L2*'*cBitsMaxlnterval;
constant cNumDetectores : natural',':::: 2;
6. La gestin del diseo 41 7
------------------------ ...------------------------_-----~,...-."1 .. :_-.-~
_ . : .Co ns t a nt e s de f i ni da s pa r a l a c c e un c e c n c o n e l
- - mi c r o pr o c e s a do r
c o ns t a nt c Anc ho Bus CP U na t ur a l :=- 9;
c o ns t a nt c Anc ho Bus Da t o s na t ur a l . . -: c Anc ho Bus CP U ;
c o ns t a nt c Anc ho Bus Di r e c s na t ur a l -:= 7;
c o ns t a nt c Bi t s Co nt r Re gs na t ur a l ::: 4;
c o ns t a nt c NumE r r o r e s na t ur a l := 2;
c o ns t a nt c NumI nt e r r ps na t ur a l .- , c NumE r r o r e s +
2 + c NumDe t e c t o r e s ;
- - Co ns t a nt e s de f i ni da s para e l ma ne j o de l o s a c c e s o s
- - a me mo r i a
-------------------------------- ....------~-------~--_ ....-"'!" .....-.--~~ ...._-
c o ns t a nt c Bi t s Bus Di r e c c ~ : na t ur a l := 15;
ESTE DATO DEBE SER, AL MEKJ S, LA SUMA DE:
c Bi t s Ma x NumSe ns o r +
c Bi t s Ma x NumMue s t r a s +
c &i t s Ma x NumAc c e s o s - 2
; - - Co ns t a nt e s de f i ni da s pa r a e l ma ne j o de l o s f i l t r o s
, -- FIRl Y FIR2 '
------------------------_~:.,.;.~"I'""--~ .... \--.--~ ..':'OO; ,..--...., ..--" " " - .....----.--- ...--~_ ~-
- - Ge ne r a l
c o ns t a nt c Bi t s ~s o r
c o ns t a nt c Bi t s NumBl o qs Me m
c o ns t a nt c Bi t s Ma x NumMue s t r a s
- - F i l t r o 1
c o ns t a nt c Bi t s Ma x NumE t a pa s 1
c o ns t a nt c Bi t s Ma x NumAc c e s o s 1
c o ns t a nt c P a 1a br a s P o r Ac c e s o l
c o ns t a nt c Ma x NumE t a pa s 1
c o ns t a nt c Ma x NUmAc c e s o s 1
- - F i l t r o 2
c o ns t a nt c Bi t s Ma x NumE t a pa s 2
c o ns t a nt c Bi t s Ma XNumAc c e s o s 2
c o ns t a nt c P a l a br a SP o r Ac c e s o 2
c o ns t a nt c Ma x NumE t a pa s 2
c o ns t a nt c Ma x NumAc c e s 0s 2
na t ur a l : : ' - 3' ;
na t ur a l . - 2;
na t ur a l : e 12;
natural j 4;
na t ur a l . - c Bi t s Ma x NumE t a pa s 1 - 2;
na t ur a l . - 4;
: na t ur a l . - 2* * c Bi t s Ma x NumE t a pa s 1;
: na t ur ~l . - 2* * c Bi t s Ma x NumAc c e s o s l
na t ur a l : = 4;
na t ur a l :.; ; :0 - c Bi t s Ma x NumE t a pa s 2 -
c Bi t s NumBl o qs Me m;
na t ur a l : = 3;
- ~ 2* * c Bi t s NumBl o qs Me m;
na t ur a l : " 12;
- - ~Bi t s Ma x NumE t a pa s 2;
na t ur a 1: = 2* * c Bi t s Ma x NumAc c e s o s 2;
--------------_ :_ --------------- ......... ~-------_..... _ ---------- - . . ; . - - - - - _ . . .
- - Co ns t a nt e s de f i ni da s para e l ma ne j o de r e t a r do s de l o s
. . bl o que s de l a i nt e r f a z
- - - - - - - - - - - ; , , ; . - - - - - - - - ~- - - - - - - - - - - - ~- ~- - - - ~- - - - - - - - - - - - - - - - - - - - -
- - T I F OS
c o ns t a nt cRet.ardo :: na t ur a l := 1:
= = = = = = = = = = = = = = = = : , = = = = = = = = = = - = = = = = = = = = = = = = = = = = = : : : = = = = = = = = = : = = = = =
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = : : :
-----------------------------:------ ...--.--~.- ...--------------_ .... _--
s ubt y pe t Co e f P i l i i br a
- - T i po s de f i ni do s pa r a e l ma ne j o . de l o s f i l t r o s ( F I Rl y F I R2)
---------~~---- ... -~.- ..._-------------...;------~~----------:....--....... ~.--,.;.--
t y pe t C e f s Ve c t o r
s ubt y pe t Da t o P a l a br a
t y pe t Da t o s Ve c t o r
s ubt y pe t No : nna P a l a br a
t y pe t Ac c e s o 2
t y pe t Ac c e s o 2Ve c t o r
1s s t q_ l o gi c _ v e c t o r
( c Bi t s Co e f - 1 do wnt o O) :
1s a r r a y ( i nt e g r r a nge <
af t Co e f P a l a br a ;
1s s t d_ l o gi c _ v e c t o r
( c Bi t s Da t o s - 1 do w. nt o O) :
1s a r r a y ( i nt e ge r r a nge -o-
o f t Da t o P a l a br a ;
1s s t d_ l o gi c _ v e c t o r
( c Bi t s No : nna - 1 do wnt o O) :
i s a r r a y ( O to c P a l a br a s P o r Ac c s 02 - 1)
o f t Da t o P a l a br a ;
i s a r r a y ( i nt e ge r ranga -o-
o f t Ac c e s o 2;
t y pe t Ac c e s o l Da t o s i s a r r a y ( O t o c P a J _ a br a s P o r Ac c e s o 1 - 1)
o f t Da t o P a l a br a :
t y pe t Ac c e s o 1Ve c t o r Da t o s i a a r r a y ( i nt e ge r r a nge -o-
o f t Ac c e s o 1Da t o s ;
t y pe t Ac c e s o 1Co e f s i a a r r a y ( O to c P a l a br a s P o r Ac c e s o 1 - 1)
o f t Co e f P a l a br a ;
t y pe t Ac c e s o 1Ve c t o r c o e f s i s a r r a y ( i nt e ge r r a nga <
af t Ac c e s o 1Co e f s ;
- - T i po s de f i ni do s pa r a l a i nt e r f ~ c o n l a CP U.
-----------------~------.-~------------'....:------_._-_ ..._--- .....--_ .....__ __,;.;...
s ubt y pe t Di r e c c CP U 1s
s t d_ l o gi c _ v e c t o r ( c Anc ho Bus Di r e c s - 1 do w. nt o O) i
s ubt y pe t Da t o s CP U 1s
s t d_ l o gi c _ v e c t o r . ( c Anc ho Bus Da t bs - 1 do wnt o Ol :
a ubt y pe t Bus CP U is
s t d_ l o gi c _ v e c t o r ( c Anc ho BuSCP U - 1 do wnt o O) ;
- - T i po s de f i ni do $ pa r a e l ma ne j o de l . <l e t e c t o r de m x i mo
s ubt y pe t El e mI nt e r v a l o 1s
s t Q_ l o gi c _ v e c t o r ( c Bi t s Ma x NumMue s t r a s - 1 do w. nt o O) :
t y pe t I nt e r v a l o 1s a r r a y ( 1 do w. nt o O)
o f t El e ml nt e r v a l o ;
t y pe t Ba nc o De I nt e r v a l o s i 8 a r r a y ( O to ~I nt wa l . ~ J l
o f t I nt e r v a l o "
t y pe t Ba nc o De M x i mo s i 8 a r r a y ( O to c Ma x l nt e r v a l - 1)
o f t Da t o P a l a br a :
t y pe t Ba nc o De P o s i c i o ne s L a a r r a y ( O to e Ma x I nt e r v a l - l}
o f t El e mI nt e r v a l o :
type tBancoDatosDet is array (1 te cNun1Detectores)
af tDatosCPU
subtype tEl~er;vsDet iB
stcl.log.t'c...;vector (CBitsMaxI~tervq.J ,. - 1 downta Q);.
type tVectorlntervsDet iB array (1 te cNuffibetectores) c,,
. .. af tElemInterv,sDet;
type tVectorCtrlnet' La array (1 te cNumDetectores)
af std_logic;
= ! : : : = = = = = = = = = = = ~ = : z = = = : : * = c : : : : : = = = = = = = = = = = = = . : = = : : = : : : : : , : ! : : r : - = : ; : ; : , _ ; : . . ~*c:==
..- FUNCI~
================;=====:===========:========:====================
--"~--:'-::;;'';'':'";::-::-----------------::-''_--------:,:.: ... -:.'''_''::~, ..-~~-:t.r:r--------
-- Calcula el. logaritmo en base 2 del parmetro
----------------------------------------------------_'--;.. .. ~_,.~:"l'"
functiOl1 log~ (Etapas : integer) retuzn integer;
constant cAnchoAculIIl : integer := catstatos +
cBitsCoet +
lqg2 (cMaxNumEtapas1) i
constant cAnchPAcum2 integer:= eBitsDatos +
cSltsCoef +
t6g2 (cMaxNunEtapas2)
end TiposBasicos;
LISTADO 6-15. Cdigo del paquete de definicin de constantes y tipos bsicos.
Ntese que en el fichero, adems de incluir constantes y definiciones de tipos,
se incluyen tambin funciones que permiten generar, a partir de las constantes,
otros valores o estructuras de datos que facilitarn la posterior descripcin de los
mdulos. En algunos casos, como seexplicar posteriormente, ser necesario defi-
nir tipos de forma local en los ficheros que definen cada unidad funcional. Con
objeto de facilitar el mantenimiento de este fichero, y puesto que en un diseo de
mediana complejidad se generar un gran nmero de constantes y tipos, conviene
definir una nomenclatura clara para los mismos. En los siguientes apartados sedan
algunas recomendaciones en este sentido.
6.5.3.2 . Seleccin de parmetros
Uno delos aspectos crticos al realizar un diseo genrico es la seleccin delos pa-
rmetros que pueden ser variables en el diseo y que, por tanto, sern incluidos en
el fichero de tipos bsicos y constantes. Como criterio general se puede decir que
deberan definirse como valores genricos todas las constantes que aparecen en el
cdigo. En un principio, este planteamiento podra parecer exagerado, yaque posi-
blemente existan algunos valores que, con toda seguridad, no van a cambiar. En
cualquier caso, estos valores siempre pueden dejarse constantes, y es ms interesan-
te que aparezcan en el cdigo como nombres, que no como un nmero cuyo valor
puede no comprenderse.
El cdigo del siguiente listado muestra un ejemplo de la definicin de la enti-
dad de un filtro digital en el que se han incluido como parmetros todo lo que
podra ser variable (el significado de las constantes y su valor est definido en
el fichero deconstantes y tipos bsicos, Listado 6-15).
1ibrary IEEE;
use IEEE. st<LlogiG_1164. al1;
use IEEE.st<Llogic_arith.al1;
use IEEE.std_logic_signed. al1;
use WORK.BasicTypes.al1;
use STD.textio.al1;
entity FIRl is
ganarie (
gBitsDatos
gBitsCoef
gBitsNoIIDa
gMaxNumEtapas
gMaxNumAccesos
gPalabrasPorAccesc
: natural. :,;: cBitsDatos
:. natl,l.rf:;, cBitsCoef
:- nat%~::= BitSNorm,i
: ruiturli': = hlaxNumEtapas1
natural .:= cMaxNumAccesos1
natural .:= cPalabrasPorAcceso1
J ;
port(
RelojFIR
InicioN
inst<Llo~'ic;.
instd_logic
_ Interfaz de Configuracin
Accesos ininteger range Oto gMaxNumAccesoll--: 1;
CargaCoet instd_logic;
NunCoef ininteger range Oto gMaxN1.mlEtapas- l;
CoefIn intCoefPalabra;
Norntapal' intNoIIDal'alabra;
_ Interfaz de Operaciri
NuevoSensorlZi in stq).ogic;_
NuevaMuestraIn in std_logic;
DatoIn in tDatoPalabra
DatoOut out tDatoPa1abra
NuevaMuestraOut out st<Llogic
NuevoSensorOut out st<L1ogic
Error out boolean
J ;
end FIRl
architecture FUNCIONALaf FIRl is
begi n
end FUNCIONAL;
LISTADO 6-16. Ejemplo de entidad genrica de unfiltro digital.
Si no sequieren variar los valores de los parmetros en ningn caso, este pro-
cedimiento simplemente aporta una mejor organizacin del diseo y una mayor le-
gibilidad del cdigo.
Si sedesea que el componente funcione para diferentes valores de los parme-
tros, habr que escribir el cdigo en consecuencia. Esto requiere analizar qu valo-
res son aceptables, dependencias entre los parmetros, etc. En la mayora de los
casos, esto no presenta problemas, especialmente si se ha diseado una buena
estructura de datos. Sin embargo, existen algunos casos donde la generalizacin
resulta untanto engorrosa. El siguiente cdigo muestra unejemplo tpico.
-,..._ ------ . . . . _ ----~:_ ---------------_ .-----------------_ ...----_----_ . . _-----------
. - - E l r e g i s t r o i n t e r n o es ma y o r que e l de d a t o s d e l mi c r o .
-- Leo parte a l t a y . baja
-----------------------. ----_-- . . . . '""~--_:_-~----~~---------------------of------ _
COOD1 : ifg Bi t s Ma x Nu mMu e s t r q s " > g An c h o Bu ~t o s g e n e r a t e
L E CI ' UR A1 : process ( S e f e c c l o n , t e e r P a r t e Al t a , Ba n c o Mu e s t r a s , Nu mI n t e r v e P u l
begin
Da t o Ou t <= ( o t h e r s => ' O ' ) ;
i f S e l e c c i o n = '1' then
i f L e e r P a r t e Al t a = ' O' then
Da t o Ou t <= Ba n COMu e s t r a s ( Nu mI n t e r v CP U)
{ g An c h o Bu s p a . t o s - 1 d a t mt o O). ;
e l s e . " _ ' . . . . . . : . . , ' . . . . " .
Da t o Ou t ( g Bi t s Ma x Nu mMu e s t r a s - g An c h o Bu s Da t o s - 1 d o wn t o O)
<~Ba n c d MUe s t r a s ( Nu mI n t e r v CP U} '
. ( g Bi t s Ma x Nu mMl . 1 e s t r a s - 1d a t mt o
g An c h o Bu s Da t o s ) ;
e n d i f :
e n d if;
e n d p r o c e s s L E CT UR A1 ;
end g e n e r a t e :
---------------------. . . ,. --------- . . . ---'--,. . . -----_. . . _ . ._-. -. !--; .. ,--- .... -,---~--~---------
- - E l l:wI de :muestras es menor que' .el de d a t o s . d e L mi c r o .
- - S l o hay p a r t e b a j a
COND2 : i f g Bi t s Ma x Nu r n Mu e s t r a s <= g / I l . ) . Ch O~S Da t o sg e n e r a t e
L ECT U RA 2 : process ( S e r c c i o n , ' L i r P a r t e Al t a , Ba n c o Mu e s t r a s ; Nu I n I n t e r v Cp u r
begin . _ ,
Da t o Ou t <= ( o t h e r s => ' O' ) ;
i f S e l e c c i o n = '1' then
Da t o Ou t { 9 Bi t s Ma x Nu mMu e s t r a s - 1 d o wn t o . O)
<= Ba n c o Mu e s t ~a s ( Nu ml n t e r v CP UI ;
e n d if;
e n d p r o c e s s L ~;
LISTADO 6-17. Diferentes tamaos en buses.
En este componente existen unos registros internos que pueden ser ledos por
una CPU. El tamao de los registros es parametrizable y su ancho no guarda rela-
cin con el ancho del bus de la CPU. Esto obliga a distinguir dos casos, el caso en
el que el ancho del bus de la CPU sea menor que el de los registros o el caso en el
que sea mayor o igual (ver cdigo Listado 6-17). Incluso en el caso en el que el bus
de la CPU sea menor que el ancho de los registros, cabra plantearse que los regis-
tros fuesen de un tamao tal que el acceso por parte de laCPU tuviese que hacerse
en tres o cuatro ciclos. Esto obligara aconsiderar nuevos casos en la escritura del
cdigo.
Al elegir los parmetros conviene, por tanto, imponer restricciones realistas a
los valores que pueden tomar los parmetros, de forma que exista un equilibrio en-
treel coste del desarrollo y los beneficios previsibles.
Una posible regla para seleccionar qu parmetros incluir sera entonces con-
siderar todas las constantes que aparecen en el diseo, para escoger con cuidado
los mrgenes de variacin de los parmetros cuando stos modifiquen la funcio-
nalidad (en el ejemplo mostrado se consider que era conveniente mantener la
posibilidad de que el ancho de los registros fuese mayor o menor que el del bus
delaCPU).
6.5.3.3. Particionado del diseo
El particionado del diseo puede influir, desde el punto de vista del diseo genri-
co, en dos aspectos fundamentales. Por un lado, va a influir en las estructuras de
datos (los tipos delas seales) que sean necesarios en el diseo, yaque laparticin
influye en el nmero y tipo de seales que se comunican entre bloques. Por otro
lado, el cmo se realice la particin y se distribuyan las unidades funcionales en
los bloques va adeterminar la facilidad o dificultad con la que serealicen modifi-
caciones al diseo. Es decir, la facilidad con laque podr hacerse que los parme-
tros puedan cambiar su valor y, por tanto, que el diseo genrico resulte realmente
til.
El particionado ptimo depende en gran medida de la aplicacin que se est
considerando, aunque pueden darse una serie derecomendaciones tiles.
La mayora de los bloques funcionales disponen de unidades operacionales
(ALUs, multiplicadores, etc.), registros programables y seales tpicas de control
para la carga o lectura de los registros y para la sincronizacin de las operaciones.
Una particin que da buenos resultados consiste en establecer una jerarqua donde
las unidades operacionales estn separadas de los registros y de un posible interfaz
con el resto del sistema.
La ventaja de un particionado de este tipo es que las posibles modificaciones
estructurales afectan aun nmero pequeo de bloques. Sin embargo, estas solucio-
nes no son siempre vlidas ofcilmente aplicables. En cualquier caso, conviene que
el nmero debloques no seaexcesivo (tres ocuatro es unbuen nmero).
El particionado puede influir en la ubicacin y conexionado (place and route)
y, por tanto, en las prestaciones en cuanto avelocidad. Este aspecto debe ser tenido
en cuenta para no hacer que el diseo genrico comprometa las prestaciones.
6.5.3.4. Estructuras de datos
Cuando se realiza un diseo genrico se debe prestar gran atencin ala definicin
delainterfaz (port) en las entidades. Las ventajas del diseo genrico sepierden si
al modificar el valor dealgn parmetro cambia lainterfaz deun componente y, por
tanto, setienen que editar los ficheros en donde intervienen.
En la medida de lo posible debe lograrse que cualquier modificacin de los
parmetros, dentro de sus valores permitidos, slo implique una recompilacin del
cdigo, pero nunca una reedicin del mismo (salvo, claro est, el fichero de tipos
bsicos y constantes).
Para conseguir este objetivo deben generarse estructuras de datos de forma
adecuada. En este sentido, puede ser interesante hacer uso deestructuras tipo vector
de vectores o estructuras tipo registro (record) . Sin embargo, aunque la herra-
mienta de simulacin y sntesis pudiera trabajar adecuadamente con estas estructu-
ras (no es posible en muchas de las herramientas actuales), es necesario comprobar
que el interfaz con las herramientas deback-end (bsicamente herramientas dedise-
o fsico y simulacin anivel depuertas) serealiza deforma adecuada.
En el cdigo que sigue semuestra un banco de coeficientes de un filtro digital
que opera en varios ciclos de reloj. Esto requiere acceder a diferentes partes del
banco en cada momento, por lo que resulta idnea una estructura matricial. El n-
mero de ciclos que tarda en ejecutarse la operacin, as como el tamao final del
banco de coeficientes y el nmero de bits de stos, estarn definidos en el paquete
de tipos bsicos y constantes (ver Listado 6-15) y podrn determinarse posterior-
mente.
library IEEE;
u s e I E E E . s t d _ l o g i c _ 1 1 6 4 . a l l ;
use WORK. Ba s i c T y p e s . a l l ;
entity FIR1_REDSi8
generle(
g Bi t s Da t o s
g Ma x Nu mE t a p a s
: n a t u r a l :=c Bi t s Da t o s ;
r n a t u r a l : =c Ma : XNu mE t a p s l ;
g Ma x NUmAc c e s o s n a t u r a l :=c Ma x Nu mAc c e s o s l ;
g P a l a b r a s P o r Ac c e s o : n a t u r a l :=c P a l a b r a s P o r Ac c e s o l
);
port(
RelojFIR
I n i c i o N
Nu e v o S e n s o r l n
CargaRegs
Da t o l n
RegsOUt
in s t d , , _ l o g i c ;
in s t c ( l o g i c ;
in t Da t o P a l a b r a ;
o u t t Ac c e s o l Ve c t o r Da t o s ( Q to g Ma x Nu mAc c e s o s - II
);
end FIR1_REGS;
arehitecture FUNCIONALof FIR1_REGSIs
----------------------~----------~-------~---~-----:~~.----:------------..,-
- - Ba nc o de r e gi s t r o s de l f i l t r o
s i gna ! Ba nc o Re g: s t Da , t o s v ~, ~9r (O to gMa x NumEt a pa s - :J .).
be gi n
F OR1
F OR2
f o r ii n O to gMa x NwnAc c e s o s - 1 ge ne r a t e
f o r j i n O to gP a l a br a s P o r Ac c e s o - 1 ge ne r a t e
Re gs OUt ( i ) ( j ) ~=Ba nc o Re gs ( i * gP a l a br a s P o r Ac c e s o + j )
end ge ne r a t e ;
end ge ne r a t e ;
-~~-----------------------------------------------~------------------
- - Ca r ga s e r i e de l o s da t o s
----------------------'!""--------------------------,...~,~----- .... ------- ........ --
LOAD : pr o c e s s ( Re l o j F I R, I ni c i ON)
be gi n
i f I ni c i a N = ' 0' tban
f o r i inO to gMa x Nur nEt a pa s - 1 loop
Ba nc o Re gs ( i } <= ( o t he r s => ' 0' ) ;
end loop;
e l s i f Re l o j F I R' e v e nt and Re l o j F I R =" , i: t he n
i f Ca r ga Re gs = '1' then
Ba nc o Re gs (1 te gMa x NumEt a pa s - 1) <=
Ba nc o Re gs (O to gMaxNumE~ - A )
Ba nc o Re gs (O) <= Da , t o l n;
end i f ; .
i f Nue v o Se ns o r l n = '1' then
f o r i in 1 to gMa x Nur nEt a pa s - 1 loop
Ba nc o Re gs ( i ) <= ( o t he r s => . 'O') ;
end loop;
e nd i f ;
e ndi f ;
e nd pr o c e SB;
end FUNCI ONA L;
LISTADO 6-18. Utilizacin detipos complejos.
El siguiente ejemplo muestra un bloque decodificador para el acceso por parte
deuna CPU adiferentes registros deun circuito.
- - Es t a de f i ni c i n e s t e n e l pa que t e
- - de t i po s b s i c o s y c o ns t a nt e s
t y pe De c o s Se l Re c o r d i 8 record
Ca r ga Re gs F i r s t d_ l o gi c ;
Ca r ga Re gs Co nf s t d_ l o gi c ;
Ca r ga Re gI nt r s t d_ l o gi c ;
Ca r ga Re gs Co e f s t d_ l o gi c ;
LectBancoMuestras std_logic
end record;
entity Decod la
port(
DirecCPU instd_logic_V'eCtorlg-BitsDirecCPU - 1 downto O }
EscrN instd_logic;
Seleccion out DecodSelRecord
};
endDecod
LISTADO 6-19. Utilizacin de estructuras tipo registro.
En estecaso, las seales deseleccin sehan incluido enunaestructura tipo regis-
tro (record). Deestaforma, unaposibleinclusin futuradeuna seal deseleccin no
modifica lainterfaz, reduciendo el riesgo deerrores. La definicin delas seales que
contiene laestructura record serealiza en el paquete detipos bsicos y constantes.
El objetivo de estas estructuras de datos es que sean lo suficientemente flexi-
bles como para permitir cmodamente la variacin de los parmetros. Al mismo
tiempo deben facilitar el que posibles modificaciones afecten al menor nmero
posible de ficheros oentidades. "
6.5.3.5. Otras recomendaciones sobre la codificacin
La codificacin en VHDL de componentes genricos presenta algunos problemas
de tipo prctico que es necesario solucionar. En los siguientes apartados se dan
algunas soluciones a problemas tpicos que aparecen al realizar diseos genricos.
6.5.3.5.1. Problemas con los buses
Al hacer genricas las dimensiones delos buses aparecen, en algunos casos, proble-
mas decompatibilidad entre seales. En el siguiente ejemplo semuestra uncaso tpi-
co donde seasignan dos seales dedimensiones diferentes eindependientes entre s.
LECTURA2: process (Slecci6n~ BaricMuestras," NumIn.ttvePu)
: b e g i n
DatoO ut <= ( ot b e r s => ' O' )
i f Seleccion = '1' then .
DatoO ut (gBitsMaxNumMuestra - 1 downto O)
<= BancO Muesfras (NurnlntervCPu) ;
end i f
end process LECTURA2;
LISTADO 6-20. Asignacin de buses condiferentes tamaos. Puede dar lugar a
errores.
Si el tamao de la seal BancoMuestras (que viene determinado por la cons-
tante gAnchOBusDatos), es menor que el tamao de la seal DatoQut (determinado
por laconstante gBitsMaxNumMuestras), la asignacin ser correcta. Sin embargo,
si el tamao de BancoMuestras es mayor que el tamao de DatoOut ocurrir un
error al intentar simular o sintetizar el diseo.
En este caso es necesario considerar las distintas posibilidades y generar cdi-
go en consecuencia (o bien limitar los mrgenes de variacin de los parmetros
gBitsMaxNumMuestras y gAnchoBusDatos).
El mtodo ms sencillo para hacer esto es utilizar sentencias tipo genera te. El
siguiente segmento de cdigo muestra el mismo ejemplo corregido para aceptar
diferentes tamaos delas seales.
-- E]_ registro iritemo e s iriyor-que;erde d a t o s .de! mero'
- - L e o parte ' a l t a y baja
------------------_ ._ ------.-....;------.-....;~--,.;..- .... _ .,..-------.--------.;...-.--~--+-- .... - ... -- ...
COND1 : ifg Bi t s Ma x Nu mMu e s t r a s > g An c h o Bu s Da t o s g e n e r a t e
L E CT URA1 : p r o c e s s ( S e 1 e c c i o n , L e e r P a r t e Al t a , Ba n c o Mu e s t r a s , Nu ml n t e ~U)
begin .... .
Da t o Ou t <= ( o t h e r s => ' O' ) ;
i f S e l e c c i o n = ' 1 ' then
i f L e e r P a r t e Al t a = 'o' t h e n
Da t o Ou t <= Ba n c o Mu e s t r a s ( Nu r n l n t e r v CP U)
( g An c h o Bu s Da t o s - 1 d o wn t o O);..
e l s e
Da t o Ou t . ( g Bi t ! l Ma x Nu mMu e s t r a s - \ J , &l c h o Bu s Da t o s - 1 d o wn t o O )
<= Ba r l c o MU s t r a s ( Nu ml n t e r v CP j
. ( g Bi t s Ma x Nu mMu s t r a s - 1 d o wn t o
g An c h o Bu s Da t o s ) ;
end if;
end if;
e n d p r o c e s s L E CT URAl ;
r-:- : E;: ' bJs d e ~~~t r a s . ~)llel}pr_ C W ~ ~l . ~ , ~t o s ~l mi . c r o .
. - - S o l o hay parte fuaja
COND2 : i f g Bi t s Ma x Nu f f i Mu e s t r a s <= g An c h o Bu s Da t o s g e n e r a t e
L E CT URA2 : p r o c e s s ( S e l e c c i o n , Ba n c o MUe s t r a s , Nu ml n t e r v CP U)
begin
Da t o Ou t <= ( o t h e r s => ' O' ) ;
i f S e l e c c i o n = ' 1 ' t h e n
Da t o Ou t ( g ~i t ~u e s t r a s - 1 d o wn t o Ol
<= Ba n c o Mu e s t r a s ( Nu ml n t e r v CP U) ;
end if;
e n d p r o c e s s L E CT URA2 ;
LISTADO 6-21. Utilizacin de sentencias generate para evitar errores de ancho de
bus.
Es necesario hacer notar que una solucin alternativa mediante ifcondition
then dentro de un proceso no ser vlida. Si lo hicisemos as, el error antes
comentado no quedara solucionado, ya que la valoracin de la condicin irse
realiza en tiempo de simulacin y, por lo tanto, durante la elaboracin se podra
producir error si ladimensin deBancoMuestras es mayor que ladeDatoOut.
6.5.3.5.2. Problemas de definicin de los tipos
Para simplificar la escritura del cdigo sehace interesante, en muchas ocasiones, la
definicin de tipos estructurados (vectores, registros, etc.). Cuando estos tipos
dependen de algn parmetro puede ocurrir que sudefinicin dlugar aerrores. En
el siguiente cdigo semuestra unejemplo deeste tipo.
-- Esta definicin esta en el paquete de tipos bsicos
type tBancoMUestrPrevias la array (O to cMaxInterval - 2)
of tDatoPalabra
,
--------- .... ----- .... :--::r""~'!"",--~---------~-------- ... -----~,~,::"'-::~.i,rt~-:~-:.---:~.
aigIlal MuestraPrevia: tBaric~estrPrviasi
L OA_2 : process (R~l(.)jFI~ +ni9,i;p~( ..C~~, ~j.mo, NlJmInt~l)et)-
begi n
if InicioN = ' 0' then
MuestraPrevia <= (others => (others => ' O' 1) . .
BancoMuestras <= (others => (others => ' O' )) ... ~
elalf RelojFIR'event and RelojFIR = '1' then
lf CPUReq= ' rthen
for i in O to gMaxInterval - 2 loop
BancoMuestras (). < = MuestraPrevia (i)
end loop
BancoMuestrast~ntervDet) <= Maximo
end if
end if;
end process;
LISTADO 6-22. Problemas con la definicin de tipos.
En el L istado 6-22 la definicin del tipo tBancoMuestrPrevias depende de
la constante cMaxInterval que podra valer 1. Si esto ocurriese, la definicin
sera incorrecta, puesto que ladireccin de los ndices del vector no es correcta (de
hecho el tipo tBancoMuestrPrevias no debera generarse en dicho caso). Para
solventar este problema debe definirse el tipo dentro de una estructura block. En
el siguiente segmento de cdigo se muestra un ejemplo de cmo se ha resuelto el
problema.
GE NE R2 : i f g Ma x l n t e r v a l > 1 g e n e r a t e
B: BWCK
t y p e t Ba n c o Mu e s t r ! ' r e v i a s i s array (O.to ~~~qt - ~k.
o f t Da t o P a l a b r a ; . . . . >. ,..
s i g n a l Mu e s t r a P r e v i a !t Ba n c o Mu e s t r P r e v i a s ;
b e g i n
L OA_ 2 : p r o c e s a ( Re l o j F I R, I n i c i ON)
b e g i n
i f I n i c i o N = ' 0' then
Mu e s t r a P r e v i a <= ( o t h e r s =>( o t h e r s =>'0'-));
Ba n c o Mu e s t r a s <= ( o t h e r s =>( o t h e r s =>' O' ) ) ;
e l s i f Re l o j F I R' e v e n t a n d Re 1 0j F I R = ' 1 ' t h e n
i f CPUReq = ' l' then
f o r i in O to g Ma x l n t e r v a l - 2 l o o p
Ba n c o Mu e s t r a s ( i ) <= Mu e s t r a P r e v i a ( i ) ;
end l o o p ;
Ba n c o Mu e s t r a s ( Nu mI n t e r v De t ) <= Ma x i mo ;
end i f ;
e n d if;
e n d BL OCK B;
LISTADO 6-23. Solucin utilizando tipos locales dentro de sentencias block.
6.5.3.5.3. Sntesis y optimizacin
En los diseos genricos existen unidades funcionales o segmentos de cdigo que
deben generar hardware en unos casos y en otros no. Normalmente esto se llevar a
cabo mediante sentencias de tipo ifcondicin generate o mediante sentencia if
condicin then donde lacondicin aevaluar es unaconstante. El siguiente cdigo
muestraunejemplo de ambos casos.
GE Nl : i f c I mp l De t Ma x g e n e r a t e
MAX_ DE T : De t e c t Ma x i r n o s
port map (
Re l o j =>Re l o j ; , ; .c
I n i c i ON =>l I i i . c i o i j ; . . .
S e l Re g s Ma x =>s e e c c o i i , S e l Re g s Ma x ;
Da t o Ou t =>BUSCP U;
P P RAL : p r o c e s s ( Re l o j , I n i c i ON) .
b e g i n
i f I n i c i ON = ' 0' t h e n
e l s i f E e l o j ' e v e nt and Re l o j = ' 1' t he n
i f c Che qBa nc o Ge n then
-- Cdigo ge ne r a do s i c Che qBa nc o Ge n ' " true
e l s e
- - C di go generado en c a s o c o nt r a r i o
e nd i f ;
e nd i f ;
e nd pr o c e s s ;
LISTADO 6-24. Generacin condicional de unidades funcionales.
En el primer caso (sentencia generate) el segmento de cdigo no es sinte-
tizado si la condicin de la sentencia generate no se satisface. Si se utilizan
construcciones del tipo ifcond g~nerate, el proceso de sntesis, al resultar los
valores constantes, elimina la lgica que, en un principio, surgira del modelo RT
sintetizado.
Debe tenerse en cuenta que, en ambos casos, es necesario que los datos a eva-
luar sean declarados como constantes. En el siguiente ejemplo uno de los datos es
declarado como variable inicializada a un valor constante mediante una funcin
(que devuelve cierto o falso en funcin de una estructura de entrada donde sedefi-
nen las diferentes configuraciones del diseo).
P P RAL : pr o c e s a ( Re l o j , I ni c i o N)
v a r i a bl e v Che qBa nc o Ge n : boolean :.= c Obt e nOpc l I l pl e mt (gOpci9I_l~SJ i
be gi n
i f I ni c i e N = ' O' t he n
e l s i f Re l o j ' e v e nt and Re l o j = ' 1' then
if vCheqBancoGen then
- C di go ge ne r a do s i c ~s o Ge n ~ t r y e
e l s e
- C di go ge ne r a do e n ; c a . Soc o nt r a r i o
e nd i f ;
e ndi f ;
e nd pr o c e s s ;
LISTADO 6-25. Generacin condicional errnea de unidades funcionales.
Los sintetizadores no consideran normalmente la inicializacin en las variables
y las seales y, por tanto, les asigna inicialmente un valor por defecto. Al sintetizar el
cdigo nunca segenerara el cdigo correspondiente a la condicin vCheqBancoGen
= true ya que esta variable toma siempre suvalor por defecto (false).
6.5.3.5.4. Funciones de inicializacin
En algunos casos puede ser interesante utilizar funciones para inicializar parmetros
utilizados enel diseo. En el siguiente ejemplo, lafuncin cObtenlnicIntervalos() ge-
nera una estructura con valores deinicializacin parauna serie deregistros.
type tMinMaxls array(O to 1) of lnteger;
type tInicIntervalos ls array (Oto gMaxIntezya). - 1) of tMinMax;
architecture FUNCIONAL of. ~~s ls
constant ValorInic : tInicntervalos .-
gObtenIni~te+v;~Q'l'ip,p~q),,;
, ,,-,~. , -:-Sl'l':!.PoInic::c PO_Qe jni~alizaci6n
signal BancOIntervIS :"tBartcbDel:ntrvai6lt;
begin
P P RAL : process (Reloj, InicioN)
begi n
lf InicioN =' O' than .
for i in O to gMaxIntervai~:- 1) loop
BancoIntervalos(i) <='Wlorlnic(i);
end loop; ,
elsif Reloj'event and Reloj ='1';
end if;
end process;
end FUCIONAL;
LISTADO 6-26. Utilizacin de funciones para generacin de constantes.
De esta manera, el cdigo puede resultar ms legible y se tiene ms libertad
alahora de calcular los valores de inicializacin al no tener que ser la funcin sin-
tetizable. Sin embargo, hay que resaltar que, aunque la funcin no vaya a generar
hardware, en algunos sintetizadores debe escribirse con construcciones sintetiza-
bles. Esto supone no utilizar cierto tipo desentencias, como son:
Sentencias while cond loop. Deben ser sustituidas por sentencias for rango
loopjunto con sentencias if not cond then exi t.
No inicializar las variables en laparte declarativa delas funciones. En su ca-
so, inicializar las variables en el cuerpo delas funciones.
No utilizar ciertos atributos no soportados por la herramienta de sntesis
(ej. 'POS). En sulugar utilizar otros procedimientos.
Decualquier manera, antes derealizar este tipo defunciones debe comprobarse
que el sintetizador las acepta e interpreta correctamente. En caso contrario debern
buscarse otros procedimientos para inicializar los parmetros.
6.5.3.5.5. Nomenclatura
Cuando serealizan diseos genricos, segeneran una gran cantidad deconstantes y
tipos. Es necesario establecer un criterio claro para nombrar estos tipos y datos, ya
que, delo contrario, es fcil perderse en el significado decada nombre. Esto sehace
ms importante cuando el equipo de diseo est formado por varios diseadores.
A continuacin sedan algunos ejemplos deeste tipo dereglas.
Nombres de genricos: llevarn el prefijo g. Ejemplo: gMaxMemBloques.
Nombres de constantes: llevarn el prefijo c. Ejemplo: cBitsBusCPU.
Ancho de buses: cBitsNombreBus.
Mximo valor de datos: cMaxNombreDato.
Nmero de bits para codificar datos: cBitsMaxNombreDato.
ltimo valor de un dato: cUltimoNombreDato.
Declaracin de tipo: utilizar el prefijo t. Ejemplo: tBusCPU.
En el Listado 6-15 semuestra unpaquete dedefinicin detipos bsicos y cons-
tantes utilizando estas reglas. Conviene hacer un anlisis detallado al principio del
proyecto delos datos y estructuras autilizar con objeto degenerar unas normas cla-
ras y sencillas en este sentido.
6.6. DISEOS CONFIGURABLES
Entendemos por diseo configurable aquel que posee ciertos parmetros que, al va-
riarlos, modifican la funcionalidad anivel RT del componente. En este sentido, el
diseo configurable implica un grado mayor de flexibilidad que el diseo genrico.
Como ejemplo podemos fijarnos en laTabla 6-7. Esta tabla recoge los parme-
tros de configuracin de un diseo configurable de un transmisor/receptor serie
asncrono. Como puede verse en la tabla, existen una gran variedad de parmetros
que permiten mltiples configuraciones con muy distintas caractersticas. Seleccio-
nando los parmetros adecuados podramos configurar un transmisor, receptor o
transmisor/receptor, con frecuencias de funcionamiento fijas o programables, con
longitudes depalabra fijas oprogramables, etc.
Como resultado, en una tarde, un diseador podra estudiar varias alternativas,
analizar sucoste y escoger lasolucin ms adecuada asudiseo.
Los diseos configurables poseen ventajas parecidas, eincluso mayores, que el
diseo genrico en cuanto a la evaluacin de alternativas, anlisis y organizacin
del diseo, simplificacin del cambio de tecnologa, etc. Pero de igual manera que
comparte las ventajas, tambin comparte con el diseo genrico los mismos proble-
mas, acentuados adems en algunos casos. La complejidad del cdigo es mucho
mayor en los diseos configurables que en los diseos genricos. Asimismo, ladifi-
cultad de las pruebas y el tiempo de desarrollo crecen de forma exponencial con la
TABLA 6-7. Parmetros deconfiguracin de untransmisor/receptor asncrono
Parmetros del TRANSMISORlRECEPTOR
Codificacin delaseal NRZ, NRZI o programable
Paridad Odd, Even oprogramable
Longitud del dato 5, 6, 7, 8oprogramable
Bits deparada 1, 1,5,2 oprogramable
Frecuencia base 4,9152,6,8, 10, 16,20,25,32,40 MHz
Preescalado del reloj Programable o no programable
Frecuencias TxIRx Con preescalado modo tabla
Fuente dereloj Interna, externa o programable
Frecuencia demuestreo '2, 4, 8, 16muestras/bit programable
Parmetros del TRANSMISOR
Buffer detransmisin S o no
Tamao FlFO (O-N), N = natural
Modos deinterrupcin Ninguno, al escribir, al final, ambos
Parmetros del RECEPTOR
Buffer derecepcin S o no
Tamao FlFO 0-10
Errores detectados Ninguno, sobreescritura, error deformato, error deparidad, todos
Modos deinterrupcin .Ninguno, error, dato recibido, ambos
Modo Wake-Up No, s oprogramable
Direccin Receptor Programable o no programable
Ciclos por bit 1,2,4,8, 16o programable
configurabilidad del componente. Por otro lado, las prestaciones alcanzables con
los diseos configurables pueden ser menores que las que sealcanzan con los dise-
os genricos, yaque deben buscarse ms soluciones decompromiso.
6.6.1. Desarrollo de uncomponente configurable
Al contrario que los diseos genricos, los diseos configurables no son nunca un
resultado colateral deun proyecto, sino que son el resultado deun proyecto concre-
to derealizacin deuncomponente debiblioteca.
6.6.1.1. Seleccin de los parmetros de configuracin
Uno de los problemas fundamentales en el desarrollo de un componente configura-
ble es su especificacin. La especificacin de un componente configurable requiere
no slo la especificacin de la funcionalidad (o funcionalidades del componente),
sino tambin de la especificacin de las opciones de configuracin. Es necesario
decidir qu caractersticas del diseo sern configurables y cules no, y para cada
una de esas caractersticas hay que especificar qu posibles valores pueden tomar
los parmetros.
Estas decisiones requieren un conocimiento profundo de las aplicaciones a las
que va aestar dedicado el componente, y de lacomplejidad del desarrollo del com-
ponente en funcin desus parmetros. Como ejemplo podemos fijarnos en los par-
metros del transmisor/receptor serie asncrono mostrados en laTabla 6-7. Como ve-
mos, existe laposibilidad deconfigurar el componente con 1, 1,5Y 2bits deparada.
Con esta posibilidad se cubren prcticamente todos los modos de funcionamiento
(en cuanto abits deparada) delos transmisores/receptores existentes en el mercado.
Con ello tendremos un componente que sepuede adaptar acualquier requerimiento
de un potencial usuario. Sin embargo, un anlisis detallado de los componentes
existentes en el mercado nos indicar que el nmero detransmisores/receptores con
1,5bits deparada es relativamente pequeo comparado con los que slo poseen 1o
2 bits de parada. Por otro lado, el hardware necesario para introducir 1,5 bits de
parada supone un incremento considerable de lgica y complejidad respecto al
necesario para implementar slo 1o 2 bits de parada. Como resultado podramos
concluir que es econmicamente ms viable realizar un componente configurable
que no incluyese laposibilidad deimplementar 1,5bits deparada.
Este tipo de anlisis, que debe ser realizado para todos los parmetros del dise-
o, supone una de las mayores dificultades de los diseos genricos; si el compo-
nente no es 10 suficientemente flexible, puede resultar intil para algunas aplicacio-
nes; si el componente es demasiado configurable, su coste de desarrollo puede
hacerlo prohibitivo. El riesgo principal de esta seleccin es la sobreespecificacin
delos parmetros (seleccionamos ms parmetros delos necesarios). Seleccionados
los parmetros y los posibles valores para cada parmetro, la especificacin debe
incluir lafuncionalidad que debe cumplir el componente en cada configuracin.
6.6.1.2. Aspectos a considerar en la generacin de componentes
configurables en VHOL
Existen una serie de consideraciones que es necesario plantearse ala hora de desa-
rrollar uncomponente configurable en VHDL.
Diseo: como consideracin ms importante, es necesario tener en cuenta
que, en general, no es posible hacer un sistema configurable y ptimo al mis-
motiempo, El precio apagar por la flexibilidad y el ahorro en tiempo de di-
seo suele ser un diseo menos ptimo (al igual que ocurre con los diseos
asncronos y sncronos).
Pruebas: los diseos configurables son diffciles, de comprobar exhaustiva-
mente mediante simulacin. El nmero deconfiguraciones posibles suele ser
muy elevado y la verificacin de todas las posibilidades sehace prohibitiva.
Como sever, unparticionado adecuado puede reducir este problema.
Legibilidad: las descripciones delos componentes configurables sonbastan-
tecomplejas. El cdigo extra que hay que aadir para permitir las configura-
ciones y el particionado que es necesario realizar para facilitar el diseo con-
figurable dificultan mucho la extraccin de la funcionalidad a partir de la
lectura del cdigo. Una buena documentacin y buenos comentarios en el
cdigo reducen algo esteproblema.
Mantenimiento: para que la inversin en el desarrollo de la biblioteca no
sea intil, es necesario facilitar la tarea de aadir o quitar funcionalidad al
componente (actualizacin, correccin deerrores, etc.). Esto supone tener que
prestar especial atencin alaestructuracin del cdigo.
Tecnologas destino: en general, es necesario desarrollar labiblioteca consi-
derando una determinada tecnologa sobre la que sintetizar. Si las tecnolo-
gas sobre las que se va a sintetizar el componente dependen tambin de
algn parmetro, el problema secomplicara an ms.
6.6.1.3. Diseo arquitectural
Con objeto de simplificar el desarrollo de los componentes, especialmente si el n-
mero de parmetros que poseen es elevado, es necesario estudiar afondo cmo se
vaapartir el diseo.
Como norma general, se debe hacer el diseo de los mdulos partindolos en
bloques (ver como ejemplo laFigura 6-13) demanera quecada bloque seveaafecta-
do por un solo parmetro (odos como mximo). As sesimplifica el proceso deveri-
ficacin, ya que no es necesario comprobar todas las configuraciones posibles del
diseo sino las configuraciones posibles de cada bloque (una configuracin es un
implementacin particular donde los parmetros toman unos determinados valores).
Para realizar la particin, es necesario realizar un estudio exhaustivo de las
posibilidades de configuracin. De tal anlisis debe extraerse, por un lado, cmo
afectan los parmetros, identificando aquella funcionalidad comn a todas las
configuraciones y, por otro, aislar las funciones afectadas por cada parmetro.
Adems debe definirse un modo de comunicacin entre procesos, identificando el
mnimo nmero de seales necesarias y definiendo un protocolo para la comuni-
cacin entre bloques. Los bloques deberan resultar lo ms independientes entre s
como seaposible.
Este enfoque simplifica el proceso de verificacin, ya que los bloques funcio-
nan independientemente de la configuracin elegida. Adems, puede simplificar el
diseo, ya que se pueden aislar los problemas (en general slo afectarn aun blo-
que). Por ltimo, este modo de diseo facilita el mantenimiento y la modificacin
del cdigo al resultar las descripciones menos intrincadas.
Captura de
interrupciones
Control principal
(PR o RR)
(BCLRON o BCLROFF)
(TRUE/FALSE)
cGenintStatus, cirqDtack
FIGURA 6-13. Ejemplo de particin de un diseo configurable.
El inconveniente principal, aparte deque unaparticin deestetipono siempre es
posible, es la prdida de prestaciones en el diseo. Para simplificar la comunica-
cinentrebloques esnecesario enmuchos casos definir unprotocolo decomunicacin
tipo handshake, lo que obliga aperder ciclos dereloj. Por otro lado, en algunas oca-
siones conviene repetir parte delalgica que yaexiste en unbloque, en otro bloque
diferente. De esta manera los bloques resultan ms independientes entre s, pero se
puede duplicar lalgica y, por lo tanto, aumentar el rea del componente.
6.6.1.4. Mtodo de generacin
Otro aspecto que debe ser considerado al realizar un componente configurable es el
mtodo de generacin. El componente configurable debe contener una funcionali-
dad diferente segn sean los valores escogidos para sus parmetros.
El mtodo de parametrizacin debe definir dos aspectos. Por un lado, cmo se
le pasarn los valores de los parmetros al diseo; por otro lado, cmo se tratarn
esos valores internamente para generar lafuncionalidad adecuada.
Para pasar parmetros al diseo, el VHDL aporta los genricos. Sin embargo,
lautilizacin degenricos no resulta un mtodo adecuado en lamayora delos dise-
os configurables. Hoy por hoy, hay pocas herramientas desntesis que admitan ge-
nricos, y las que los admiten, slo admiten genricos detipo entero. Sin embargo,
los parmetros deundiseo configurable pueden admitir multitud devalores dedis-
tintos tipos. Siempre ser posible asignar un valor entero acada uno delos posibles
valores deunparmetro, pero eso dificulta lalegibilidad del cdigo.
En cuanto asuutilizacin interna, el VHDL aporta las sentencias tipo if con-
dicion generate, for rango generate, as como sentencias if condicion tben y
for rango loop en procesos concurrentes. Estas sentencias pueden ser utilizadas
con relativa comodidad para realizar lalgica configurable.
En lneas generales, podemos plantearnos tres mtodos para realizar laparame-
trizacin del componente, lo que dalugar atres tipos debibliotecas decomponentes
configurables:
Biblioteca cerrada: estaran formadas por un conjunto de componentes ce-
rrados de funcionalidad parecida, pero con ciertas caractersticas de imple-
mentacin que los haran distintos. La generacin debibliotecas de este tipo
tendra justificacin slo cuando el nmero de posibles configuraciones del
componente es pequeo, es decir, depende de pocos parmetros. Esta forma
de generar bibliotecas de componentes es caracterstica desituaciones en las
que no se ha previsto ningn tipo de planificacin. La Figura 6-14 presenta
un esquema deesteprocedimiento degeneracin.
En este caso, el componente no es realmente configurable, sino que se
dispone de un procedimiento cmodo de seleccin para escoger entre una
serie decomponentes cerrados.
Biblioteca generada por programa: en este caso, el cdigo VHDL asocia-
do al componente sera generado por un programa realizado en un determi-
nado lenguaje deprogramacin (C oPascal, por ejemplo). En funcin delos
parmetros introducidos por el usuario delabiblioteca segenerara un mode-
lo VHDL u otro (ver Figura 6-15). El modo de seleccin de los parmetros
podra realizarse a travs de un entorno grfico, o de forma textual a travs
decadenas decaracteres (mnemnicos).
Este mtodo presenta la ventaja de su facilidad de programacin y la
flexibilidad en cuanto a la seleccin de parmetros. Por otro lado, al poder
realizar entornos grficos para la configuracin del componente resulta ms
cmodo para el usuario. El inconveniente fundamental es la necesidad, por
parte del siseador de la biblioteca, de manejar dos entornos de trabajo: el
del VHDL y el del lenguaje de programacin que se utilice para realizar
el programa.
---
Sintetizador
---
8
.vhd .vhd .vhd
.vhd .vhd .vhd
FIGURA 6-14. Biblioteca de componentes cerrados.
-8
config. mod.vhd
FIGURA 6-15. Componente configurable generado por programa.
Biblioteca realizada en VHDL: la generacin de la biblioteca se realizara
ntegramente en VHDL. La parametrizacin del sistema se llevara a cabo
mediante unas funciones especiales (funciones de extraccin de parmetros),
desarrolladas ntegramente enVHDL. Estas funciones estaran encargadas de
traducir las cadenas de parmetros introducidas por el usuario aun conjunto
de constantes VHDL, que son las que posteriormente se utilizaran en las
descripciones del componente (ver Figura 6-16).
La ventaja de este procedimiento es que se trabaja slo dentro de un en-
torno; el diseador slo necesita conocer VHDL, y slo depura y elabora un
cdigo fuente. Sin embargo, puesto que la mayora de las herramientas de
sntesis no soportan genricos, es unmtodo aplicable enpocos casos.
6.6.1.5. Bancos de prueba
Uno de los aspectos que ms tiempo consume en el desarrollo de las bibliotecas
(como en el de cualquier diseo) es la elaboracin de los bancos de prueba. En un
principio seda necesario desarrollar bancos deprueba para cada una delas configu-
raciones posibles del componente, pero en general eso supone un esfuerzo prohibi-
~
config.vhd ~
-8
mod.vhd
FIGURA 6-16. Componente configurable generado en VHDL.
Verificador de seal 1(st)
...
SetPattern(seal
SetPattern(seal
...
wait unlil slrobe ='1';
CheckPattern( ... )
vectores
...
SetPattern(seal 1)
SetPattern(seal 2)
Verificador de seal 2(s2)
vectores
wail unlil strobe ='1';
CheckPattern( ... ) Seal de control (c2)
...
wait unlil slrobe = '1';
CheckPattern( ... }
FIGURA 6-17. Comprobacin automtica de resultados en los bancos de prueba.
tivo. Si el componente sehapartido en bloques adecuadamente, los bancos deprue-
ba slo deben probar cada una de las configuraciones de cada bloque por separado.
En cualquier caso, el nmero de yerificaciones que hay que realizar es elevado
y lacomprobacin resulta tediosa (lo que induce ms posibilidades de saltarse un
error). Para reducir este problema pueden elaborarse bancos de prueba que verifi-
quen automticamente si el resultado de las seales tras la simulacin es correcto.
Esto implica que los bancos de pruebas tambin deben hacerse configurables,
aplicndose diferentes vectores funcionales segn la configuracin. Asimismo, las
salidas esperadas deben estar parametrizadas (en funcin de un parmetro se esco-
genunas u otras salidas). En laFigura 6-17 semuestra un mtodo que puede seguir-
se en este caso (UUT es el circuito bajo prueba). El procedimiento SetPattern() se
encargara deponer los valores esperados mediante una cadena decaracteres. Dicha
cadena sepuede obtener atravs de una funcin que depende de los parmetros de
laconfiguracin. El procedimiento CheckPattern() seencargara de verificar los re-
sultados en base aun funcionamiento sncrono del circuito.
6.7. EJERCICIOS
1. Realizar, mediante VHDL, las especificaciones deun circuito convertidor dec-
digo BCD a7segmentos.
2. Realizar, mediante VHDL, laespecificacin del bloque ProgPrecio delamqui-
naexpendedora derefrescos del Apndice 1(serecomienda leer los documentos
de requisitos, especificaciones y diseo arquitectural incluidos en el apndice).
3. El siguiente cdigo VHDL corresponde alas especificaciones de un mdulo de
un determinado diseo. Cul es la funcionalidad del bloque? Cul es el mto-
do deoperacin?
e nt i t y CAL C_ SENO i s
por t
a inreal; -- Mt.r~0.0 Y 1..0
a2 inreal; --: cuadrado de a.
s t a r t instd_lOgic; .
x out real r
);
eDd CALC_SENO;
a r c hi t e c t ur e AL GORI T MO of CAL C~SENO 18
be gi n
CAL e : pr oc e s s
variable k, y, z: real:
variable n: ),nteger;
constant 1: integer :=3;
be gi n
walt until start = '1';,'
k :=1; y :=a ; z : ~ O; ' n : ~ O;
whi l e n < 1 l oop .
z :=z + y/k; h-,.s. U:O:.'L.
k :=k * ( k + 1) * ( k + 2) ;
y :=- a2 * y;
n :=n+ 1;
end l oop;
x <= z;
end pr oc e s s ;
end AL GORI T MO;
4. Realizar el diseo arquitectural del circuito especificado en el problema 3. Supo-
ner que el sintetizador ser capazde sintetizar mdulos divisores y multiplicado-
res. Para el diseo serecomienda realizar la operacin en varios ciclos dereloj.
Serecomienda utilizar un formato dedatos binario en coma fija, en complemen-
to ados.
5. Suponiendo que disponemos de un sintetizador que no es capaz de sintetizar
multiplicadores ni divisores, pero que disponemos de tales elementos en la
biblioteca del fabricante (se dispone de sus modelos VHDL), realizar el diseo
lgico del circuito del problema 4.
6. Al final del Apndice 11(apartado 11.6)seencuentra ladescripcin en VHDL de
un transmisor serie sncrono. Disear un banco depruebas que verifique el com-
ponente teniendo en cuenta las inicializaciones, terminaciones, funcionamientos
y valores no considerados. Disear el banco de pruebas tanto mediante un pro-
cedimiento orientado a la seal como mediante un procedimiento orientado al
modo defuncionamiento.
440 VHDL. Lenguaje estndar de Dseo Electrnco
7. Realizar undiseo genrico deun contador BCD cuyo nmero dedgitos seapa-
rametrizable entre 1y 4.
8. El siguiente cdigo VHDL secorresponde con un banco deregistros deun siste-
ma debsqueda indexada deinformacin (parte delapalabra buscada es el ndi-
ce, mientras que el resto es la informacin buscada). Modificar el diseo de for-
maque seaparametrizable el nmero debits decada palabra, el tamao del ban-
co deregistros y el nmero debits correspondiente al ndice.
e nt i t y BANCO_ I NDEX i 8
port (
Cl k
Bus c a
I ndi c e
S a l i da
);
end BANCO_ I NDEX;
in s t d_ l o gi c . ;
in s t d_ l 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 ( 31 do wnt o O)
a r c hi t e c t ur e F I J A o f BANCO_ I NDEX iI
t y pe Re gI nde x i 8 s t d_ l o gi c _ v e c t o r ( 7 do wnt o O) ;
t y pe Re gDa t o s i 8 s t d_ l o gi c _ v e c t o r ( 31 do wnt o O);
s i gna l Ba nc o I nde x i 8 a r r a y ( 20 do wnt o O) o f Re gI nde x ;
s i gna l Ba nc o Da t o s i 8 a r r a y ( 20 do wnt o O) o f Re gDa t o s ;
be gi n .
REGS : pr o c e s s ( Cl k )
be gi n
i f c l k ' e v e nt and c l k = ' 1' t he n
f o r iin o to 20 loop
i f I ndi c e = Ba nc o I nde x ( i ) t he n
i f Bus c a = ' 1' t be n
S a l i da . <: Re gDa t o s ( i ) ;
end i f ;
e nd if;
e nd l o o p;
e nd if;
e nd pr o c e s a ;
end F I J A;
9. Realizar un diseo configurable deun contador BCD de l, 2o 3dgitos, que ad-
mita cuenta ascendente, descendente o ascendente/descendente, con o sin carga
paralela y con seal de borrado sncrono activa por nivel bajo o alto. Los par-
metros del diseo sern pasados mediante genricos detipo entero.
6.8. BIBLIOGRAFA
[BLUM92] M. BLML,B. KIERDOFF, M. LENZEN,A. PAWLAK: A Methodology for the De-
velopment of High Quality Standard - Cell Models in VHDL, VHDL Forum
Spring'92, Santander, abril 1992.
[HAGEN] K. TENHAGEN,H. MEYR:Generic Design: Its Importance, Implementations and
Limitations .
[PREN96] PRENDA: Metodologa dediseo deASICs, Proyecto PRENDA, febrero 1996.
[OMI95] OMI: OMI 326: VHDL Coding Standard, OMI Standards (ESPRIT no. 7267)
J ulio 1995.
ESAlESTEC: VHDL Modelling Guidelines, ESAlESTEC, September 1995.
BERNCOHEN:VHDL Coding Styles and Methodologies, Kluwer Academic Publishers,
1995.
P. CAMURATI, P;PRlNErro: Formal Verification of Hardware Correctness: Introduction and
Survey of Current Research, IEEE Computer, pp. 8-19, J uly 1988.
[ALC92] Alcatel Espace: ESA CPTP ASIC Programme. C160 ASIC Design Manual, Al-
catel Espace, 1992.
[BERG] J ANICKBERGERON: Guidelines for writing VHDL Models in a Team Environ-
ment. Disponible vaftp avhdl.org en /vilmisclModelingGuidelines.paper.ps.
[ENGS93] R. ENGSTRAND, L. ERIKSSON, G. VICENTI:From Conceptual to Implementational
Model, A Top-down Design Method Based on VHDL. First Asian Pacific Conference
on Hardware Description Languages, Standards & Applications, 1993.
[GIAC89] 1. DI GIACOMO: VLSI Handbook. McGraw-Hill Publishing Company, 1989.
[HARR91] R. E. HARRand A. G. STANCULESCU, Editors: Applications of VHDL to Circuit
Design, Kluwer Academic Publishers, 1991
[HUBROS91] J . P. HUBER,M. W. ROSNECK:Successful ASIC Design the First Time
Through. VanNostrand Reinhold, 1991.
[lEEE94] IEEE Standard VHDL Language Reference Manual. IEEE, Inc., New York,
N. Y., J une 1994.
[KLEIN94] S. KLEINFELDT, M. GUINEY,J . K. MILLER,M. BARNES:Design Methodology
Management. Proceedings of theIEEE, Vol.82, No. 2, February 1994.
[MICH92] P. MICHEL,U. LAUTHER, P. Duzv, Editors: The Synthesis Approach To Digital
System Design. Kluwer Academic Publishers, 1992.
[MMS93] Matra Marconi Space: ESTEC CPTP ASIC Programme. C150-ASIC Life Cycle.
Final Report. Matra Marconi, 1993.
[NAGA92] V. NAGASAMY, N. BERRY, C. DANGELO: Specification, Planning, and Synthesis
inaVHDL Design Environment. IEEE Design and Test of Computers, J une 1992.
[NAIBIS88] P. NAISH,P. BISHOP:Designing ASICs. Ellis Horwood Limited, 1988.
[NAV93] Z. NAVABI: VHDL. Analysis and Modeling of Digital Systems. McGraw-Hill,
1993.
[PREN94b] PRENDA: Mtodos deespecificacin y control. v3.1, julio 1994.
[PREN94c] PRENDA: Mtodos dediseo y alternativas tecnolgicas. v2.1, julio 1994.
[RAMM91] F. J . RAMMIG, R. WAXMAN: Electronic Design Automation Frameworks. El-
sevier Science Publishers B.V., 1991.
[THOM90] D. E. THOMAS, E. D. LAGNESE, R. A. WALKER, J . A. NESTOR, J . V. RAJ AN,R. L.
BLACKBURN: Algorithmic and Register- Transfer Level Synthesis: The System Archi-
tect's Workbench. Kluwer Academic Publishers, 1990.
[TORR97] Y. TORROJ A, T. RIEsGO,E. DELATORRE,J . UCEDA:Design for Rensabilty: Ge-
neric and Configurable Desings, VUFE'97, Toledo, Spain, abril 1997.
[VERI91] Open Verilog International: Verilog Hardware Description Language Reference
Manual. Version LO, October 1991.
[VITAL94] VHDL Initiative Toward ASIC Libraries- Model Development Specification.
Version v2.2b. March 1994.
Apndice I
SISTEMA
COLAMATIC
DOCUMENTO DE REOUISITOS
Presentacin del cliente
El sistema Colamatic seva adesarrollar por peticin de laempresa XXX al Centro
de diseo de YYY. La empresa XXX tiene una larga tradicin en el desarrollo y la
explotacin demquinas expendedoras dedistintos tipos. Con este proyecto sepre-
tende dar un gran salto alas nuevas tecnologas microelectrnicas que permitir una
mejora delas prestaciones delas mquinas y una importante reduccin de sucoste.
Descripcin de la aplicacin
El primer demostrador sevaarealizar para uno delos productos dems difusin en
el mercado de la empresa XXX, que son las mquinas expendedoras de bebidas.
stas suponen un 70 por 100delas ventas delaempresa y el desarrollo deun ASIC
est justificado, ya que la produccin anual prevista inicialmente y tan slo para
consumo interno es de 10.000 unidades/ao.
El diseo deber ser realizado de forma que pueda ser adaptado anuevas apli-
caciones: dentro de la lnea productiva de XXX: otros tipos de mquinas, mayor
cantidad deproductos, etc.
443
En particular, y para esta aplicacin concreta, sepretende desarrollar un circui-
to integrado que sustituya la mayor parte de la lgica de control de una mquina
expendedora debebidas fras, que disponga delaposibilidad devender hasta cuatro
productos diferentes, cuyos precios puedan ser programados para cada producto
individualmente. El diseo deber contar con la posibilidad de ser adaptado fcil-
mente aun mayor nmero deproductos. Los requisitos precisos de la aplicacin se
detallan en un apartado posterior deeste documento.
Descripcin del entorno del ASIC
El ASIC Colamatic estar encargado del control delamquina expendedora. Suen-
torno estar compuesto por elementos sensores, botones einterruptores, que estarn
conectados con las entradas del sistema, y elementos actuadores y visualizadores
sobre los que el ASIC ejercer el control.
En particular, el entorno del ASIC sepuede dividir en los siguientes elemen-
tos:
Entradas
Sensores: Sensor de entrada de las monedas, que detectar el tipo de moneda que
sehaechado. Los tipos de moneda previstos inicialmente son seis (duro, cinco
duros, diez duros, veinte duros, doscientas pesetas yquinientas pesetas).
Botones: Botones de producto, que servirn para seleccionar el producto que se
quiere comprar y tambin para seleccionar el producto cuyo precio se quiere
programar. En principio estprevisto un nmero decuatro productos.
Botn de devolucin de monedas, que servir para que el usuario pueda
recuperar su dinero. Tambin sepodr utilizar este botn para indicar el fin de
laprogramacin del precio deunproducto determinado.
Botones de programacin de precio, sern dos botenes para programar el
precio deseado para cada producto. Un botn incrementar y otro decrementar
el precio por cada pulsacin. El intervalo de incremento se dejar abierto en
estaetapa del diseo, definindose ms claramente enetapas posteriores.
Interruptores: Interruptor de cambio de modo de funcionamiento, este interruptor
seleccionar entre los dos posibles modos de funcionamiento: funcionamiento
normal y modo deprogramacin deprecios.
Salidas
Actuadores: Apertura de las trampillas de los productos, el ASIC deber abrir,
cuando secumplan las condiciones necesarias para ello, las trampillas de cada
uno de los productos. En principio deber actuar sobre cada trampilla de pro-
ducto.
Apertura de las trampillas de las monedas, dispondr de tantos actuadores
como tipos de monedas para devolver el cambio. En principio habr cinco
trampillas para ladevolucin del cambio.
Apndice l. Sistema Colamatic 445
Apertura de la trampilla a la caja de recaudacin, esta trampilla se abrir
cuando sedetecte que los carriles internos delas monedas sehan llenado.
Visualizadores: Display externo (3 dgitos), sern tres visualizadores de 7 segmen-
tos, que indicarn al usuario el precio del producto seleccionado, el dinero que
lleva echado, el cambio que se le va a devolver, segn el estado del sistema.
Cuando se estn programando los precios, en estos visualizadores se mostrar
el precio que seprograma.
Indicador de falta de cambio, que ser un LEO que indique que no se dis-
pone decambio en lamquina.
Indicadores de falta de producto, que sern tantos LEOs como tipos depro-
ductos haya, que indicarn al exterior que el producto en cuestin seha termi-
nado.
Descripcin de la funcionalidad del ASle
El ASIC Colamatic, como se ha explicado anteriormente, deber realizar todas las
funciones de control de la mquina expendedora de bebidas en la que se incluir.
Las funciones principales del ASIC sonlas siguientes:
Control de apertura de las trampillas de los productos: deber conocer el dinero
que seha introducido en la mquina y el producto que se quiere adquirir. Una
vez que el usuario ha introducido el dinero suficiente, deber apretar el botn
del producto que quiere adquirir y seabrir latrampilla correspondiente. En el
caso deque no seintroduzca el precio exacto y no haya cambio, no seabrir la
trampilla y sedevolver el dinero introducido.
Control de la devolucin del cambio: deber calcular el cambio que hay que
devolver al usuario, teniendo como criterio principal el devolver el mnimo
nmero de monedas posible (monedas de mximo valor) siempre que estn
disponibles. Adems, deber conocer el nmero de monedas de cada tipo dis-
ponibles en el interior de la mquina y actualizarlos a medida que se vaya
introduciendo dinero. Se supondr que cada vez que se abre la mquina se
rellenan los cajetines de las monedas con un nmero de monedas que se
determinar ms adelante. Cada uno de los carriles de monedas tendr una
trampilla independiente.
Devolucin de las monedas: el dinero que ha echado un usuario sedevolver nte-
gro si sepulsa el botn dedevolucin demonedas o no hay cambio y no seha
introducido el importe exacto. Las monedas devueltas debern ser del mismo
tipo que las introducidas por el usuario.
Control de llenado de los monederos: cuando sedetecte que alguno de los almace-
nes demonedas sehallenado, seabrir una trampilla que har que las monedas
introducidas caigan en lacaja derecaudacin.
Control de la presencia de productos: el sistema deber saber cuntos productos
quedan de cada tipo para informar al exterior de que no hay producto en caso
deque seterminen. Se supondr que cuando seabre lamquina serellenan los
carriles detodos los productos hasta el mximo (30).
Programacin de los precios: deber controlar laprogramacin delos precios cuan-
do el interruptor demodo est en laposicin adecuada. Para programar los pre-
cios se irn pulsando los botones de incremento o decremento de precio hasta
alcanzar el importe deseado y despus se seleccionar el producto cuyo precio
se quiere programar. Para almacenar el nuevo precio en el sistema se deber
pulsar el botn de devolucin, que en este modo de funcionamiento servir
para almacenar el nuevo precio. Tambin se puede programar el precio se-
leccionando primero el producto y despus seleccionando el precio. En este
modo de funcionamiento se iluminar el LED correspondiente al producto
seleccionado y en el display aparecer el precio que sevaseleccionando.
Control de los visualizadores externos: los visualizadores de 7 segmentos mostra-
rn diferente informacin, dependiendo del estado del sistema: si se oprime el
botn de producto antes de introducir monedas, se mostrar el precio del pro-
ducto pulsado; si se empieza a introducir monedas en el display, aparecer el
importe introducido; si seha introducido una cantidad menor que el precio del
producto y sepulsa el botn dealgn producto, semostrar el importe que falta
por introducir; si hay que devolver cambio, se mostrar el dinero que falta por
devolver; si se est programando el precio, se mostrar el precio que se va
programando con los botones de incremento o decremento de precio; en cual-
quier otro caso el display permanecer acero (000).
Los LEDs defalta deproducto seiluminarn cuando sedetecte que falta algn
producto, en modo de funcionamiento normal, y cuando se selecciona un producto
para programar suprecio, en modo deprogramacin deprecios.
Restricciones del ASIC
El ASIC deber funcionar en las condiciones anteriormente descritas y sus restric-
ciones funcionales se irn definiendo a medida que se avance en la especificacin
final y en el diseo del mismo. Estas restricciones no podrn afectar en ningn caso
al funcionamiento anteriormente descrito y debern ser aprobadas por el grupo de
diseo y el cliente.
DOC-l PRENDA: Metodologa para el diseo deASICs UPM-DIE, 1996.
DOCUMENTO DE ESPECIFICACIONES
Introduccin
En este documento se presentan las especificaciones detalladas del ASIC
Colamatic. Este documento servir como base para el desarollo de las fases poste-
riores del diseo del ASIC.
Para formalizar la especificacin del sistema se ha realizado una descripcin
del mismo en VHDL. Esta descripcin seha realizado en un estilo puramente fun-
cional para definir claramente el comportamiento del sistema.
DOC-l PRENDA: Metodologa para el diseo deASICs. UPM-DIE, 1996.
DOC-2 Sistema Colamatic. Documentos derequisitos. XXX-YYY, 1997.
Discrepancias con el documento de requisitos
Ninguna conocida.
Terminologa usada
Los nombres de las seales de entrada y salida, as como los nombres de los
bloques funcionales, intentan facilitar la comprensin de su funcionalidad al m-
ximo.
Especificacin funcional del ASIC
Especificaciones globales
Sepretende desarrollar un circuito integrado que sustituya lamayor parte delalgi-
ca de control de una mquina expendedora de bebidas fras, que disponga de la
posibilidad de vender hasta cuatro productos diferentes, cuyos precios puedan ser
programados para cada producto individualmente. El diseo deber contar con la
posibilidad deser adaptado fcilmente aun mayor nmero deproductos.
En lasiguiente tabla semuestran las entradas y salidas del sistema Colamatic y
una breve descripcin desufuncionalidad:
Nombre Descripcin
ENTRADAS
Clk Reloj principal del sistema (frecuencia por determinar)
ResN Seal de inicializacin global del sistema (activa por nivel bajo)
Botn de seleccin del producto 1 BotProdl
Botn de seleccin del producto 2 BotProd2
Botn dedevolucin del importe introducido BotDevuelve
Botn para incrementar el precio en modo deprogramacin BotPVP/ncre
Botn para decrementar el precio en modo deprogramacin BotPVPDecre
/nteModo Interruptor de modo (='O' en modo normal; ='1' en modo de
programacin deprecios)
Moneda/nt Monedas introducidas desde el exterior. Secodificarn en tres bits
SALIDAS
TrampProd Seales que controlan laapertura delas trampillas de los productos
NoHayPl Seal que controla el LED correspondiente al producto 1
Seal que controla el LED correspondiente al producto 2 NoHayP2
NoHayCambio Seal que controla el LED que indica que no hay cambio
MoneUeno Seal que controla laapertura delatrampilla alacaja derecaudacin
Seales que controlan laapertura delas trampillas deladevolucin MonedaOut
Seales para controlar el visualizador de7segmentos (unidades) DispUnidad
Seales para controlar el visualizador de7segmentos (decenas) DispDecena
Seales para controlar el visualizador de7segmentos (centenas) DispCentena
En la tabla siguiente semuestra laparticin en bloques cuya funcionalidad de-
tallada sepresentar en el apartado siguiente:
Nombre Entradas Salidas Funcionalidad
AIExterior InteModo NoHayProd Este bloque es el encargado de
PrecioProd DispUnidad generar las salidas a los visuali-
Producto DispDecena zadores y los LEDs externos.
LineaVacia DispCentena
DineroInt
Monedero InteModo NoHayCambio Bloque principal de control que
BotDevuelve MonedaOut calcula el dinero que se ha echa-
Producto TrampProd do, abre las trampillas, calcula el
MonedaInt MoneLleno cambio, etc.
LineaVacia Dineolnt
Precios V
ProgPrecio Producto PrecioProd Bloque para programar el precio.
InteModo SelRegPVP Los precios de cada producto se
BotDevuelve almacenarn en el bloque Reg-
BotPVPlncre Precio.
BotPVPDecre
RegPrecio SelRegPVP Precios V Bloque para almacenar los pre-
PrecioProd cios de todos J osproductos.
Sirve Cola TrampProd LineaVacia Bloque para controlar la disponi-
Producto bilidad deproductos.
ProgPrecio
PrecioProd precioProd--r-:==l__
SelRegPVP SelRegpVp~ Precios V
SirveCola
AIExterior
Linea Vaca Dinero/nt
Especificaciones de los bloques funcionales
Bloque A1Exterior. Este bloque seencargar degenerar las seales para la visua-
lizacin externa atravs delos visualizadores de7segmentos y delos LEDs.
En modo de funcionamiento normal (InteModo = 'O'), seiluminarn los LEDs
correspondientes a aquellas lneas de producto que estn vacas. El visualizador
mostrar diferentes valores, dependiendo delas acciones del usuario:
Mientras vaechando dinero en lamquina el display mostrar lacantidad de
dinero echada.
Si sepulsa algn botn de seleccin deproducto sin haber echado dinero su-
ficiente para dicho producto, el display mostrar el dinero que falta para la
adquisicin dedicho producto.
Si se echa ms dinero del necesario y se debe devolver cambio, el display
mostrar el cambio que queda por devolver.
En modo defuncionamiento deprogramacin (InteModo = 'O'), seiluminar el
LED correspondiente al producto cuyo precio se est programando. El display ir
mostrando el precio que seest programando para dicho producto.
Bloque Monedero. Este ser el bloque principal decontrol delamquina. Serea-
lizarn las siguientes funciones:
Clculo del dinero.
Clculo del cambio y control de los monederos internos de la mquina. El
cambio sedevolver utilizando las monedas dems valor que seaposible. Se
supone que los monederos sellenan con 30monedas cada uno cuando seini-
cializa el sistema. Cuando los monederos sellenan (tienen ms de 50 mone-
das) el dinero echado pasar alacaja derecaudacin.
Devolucin de las monedas echadas al pulsar el botn BotDevuelve. Se de-
volvern las mismas monedas que sehan echado.
Apertura delatrampilla, que seindicar al bloque Sirve Cola que seencarga-
rdecomprobar ladisponibilidad del producto seleccionado. '
Bloque ProgPrecio. Este bloque es el encargado de realizar la programacin de
los precios. Para programar un precio, el interruptor InteModo deber estar a 'O'. El
usuario seleccionar un producto y despus podr hacer aumentar o disminuir el
precio pulsando los botones BotPVPlncre y BotPVPDecre, respectivamente. Al pul-
sar una vez uno de estos botones, el precio variar en 25 pesetas. Este parmetro
podra cambiarse si seprev necesario durante laetapa dedesarrollo. Una vez con-
seguido el precio deseado, que seir mostrando en el display externo, seprograma
el precio mediante lapulsacin del botn BotDevuelve.
Este bloque generar las seales de entrada alos registros de los precios (blo-
que RegPrecio). Generar unas seales que actuarn como habilitacin decada uno
de los registros de precio de los productos (SelRegPVP) y otra en la que se encon-
trar el precio aalmacenar (PrecioProd).
Bloque RegPrecio. En este bloque se almacenarn los precios programados para
cada uno de los productos. Como salida tendr unas seales que indicarn los pre-
cios decada uno dedichos productos.
Bloque Sirve Cola. Este bloque es el encargado del control de la trampilla de los
productos y de detectar la disponibilidad de productos. Generar las seales que
indiquen que no hay producto.
Especificaciones operacionales.
Formato y rango de los datos
A continuacin se describen cada una de las seales del sistema Colamatic,
especificando sus rangos, su origen y destino, atendiendo alos bloques funcionales
anteriormente descritos:
_\Nombre
Origen Destino Codificacin
Clk Exterior Todos los bloques 1bit
ResN Exterior Todos los bloques 1bit
r
E
BotProdl Exterior AIExterior; Monedero; ProgPrecio 1bit
N
BotProd2 Exterior AIExterior; Monedero; ProgPrecio 1bit
T
R
A
D
A
BotDevuelve Exterior Monedero; ProgPrecio 1bit
S
BotPVPlncre Exterior ProgPrecio 1bit
BotPVPDecre Exterior Progrecio 1bit
InteModo Exterior AIExterior; Monedero; ProgPrecio 1bit
Monedalnt Exterior Monedero 3bits
Nombre Origen Destino Codificacin
TrampProd Monedero
':":;,.'
Exterior; SirveCla
: :-",'
4bits
NoHayPl AIExterior Exterior 1bit
NoHayP2 AIExterior Exterior 1bit
S
i-.~; i
NoHayP3 AIExterior Exterior 1bit
A
L
NoHayP4 A1Exterior Exterior 1bit
1 NoHayCambio Monedero Exterior 1bit
D
MoneUeno Monedero Exterior 1bit
A
- .,.:~. ''~>
S
MonedaOut Monedero Exterior 3 bits
DispUnidad A1Exterior Exterior 7bits
DispDecena AIExterior Exterior 7bits
DispCentena AIExterior Exterior 7bits
1
PrecioProd ProgPrecio AIExterior, RegPrecio 10bits
N
T
LineaVacia SirveCola
-J
AIExterior, ProgPrecio, Monedero 4bits
E
R
Precios V RegPrecio Monedero 4X 10bits
N
A
SelRegPVP ProgPrecio RegPrecio 4bits
S
Especificaciones tecnolgicas globales
Parmetros elctricos
Tensin dealimentacin = 5V 0,5 V.
Consumo esttico y dinmico: el consumo no ser un parmetro crtico en este
diseo (TBD).
Caractersticas de las E/S
Tensiones mxima y mnima: las entradas y salidas del circuito sern compatibles
CMOS en sus niveles detensin.
Corrientes: la corriente en las salidas del sistema deber ser de 2 mA. Se defi-
nir demanera ms precisa en las fases posteriores del diseo.
Margen de temperaturas
El margen detemperaturas para el que sedebe probar el circuito es el industrial (de
-55 oC a+125 oC).
Frecuencia de funcionamiento
El circuito no tiene unos parmetros crticos en cuanto ala frecuencia de funciona-
miento. Lafrecuencia mnima alaque debe funcionar el circuito es de 1MHz.
Encapsulado
El circuito tiene un total de47 seales deentrada y salida. A esto hay que aadir las
necesarias para alimentacin y masa y la posibilidad de tener que aadir alguna
seal externa adicional para test. Esto sedefinir enlas etapas posteriores del diseo.
El encapsulado final del circuito no est definido, aunque seprev necesario un
PLCC de68pines.
DOCUMENTO DE DISEO ARQUITECTURAL
Introduccin
Este documento contiene lainformacin dediseo generada durante el diseo dela
arquitectura del Sistema Colomatic. El desarrollo de la arquitectura de este sistema
seha realizado en VHDL, siendo el resultado de esta etapa una descripcin VHDL
compatible con el sistema final anivel deciclos dereloj, aunque no necesariamente
sintetizable.
Para el desarrollo deesta fase seha seguido lamisma particin en bloques fun-
cionales definida en el documento de especificaciones y la funcionalidad de las
seales deinterconexin entre los mismos.
Documentos aplicables
DOC-l PRENDA: Metodologa para el diseo deASICs. UPM-DIE, 1996.
DOC-2 Sistema Colomatic. Documento derequisitos. XXX-YYY, 1997.
DOC- 2Sistema Colomatic. Documento deespecificaciones. XXX-YYY, 1997.
DOC-3 VHDL-Language Reference Manual. IEEE, 1993.
Discrepancias con el documento de especificaciones
Ninguna conocida.
Descripcin arquitectural
Particin del diseo
La particin del diseo seha tomado del documento deespecificaciones (DOC-2),
ya que sta se realiz basndose en la funcionalidad que debe cubrir el sistema y
seha preferido mantenerla. El diagrama debloques del sistema con las seales de
entrada y salida de cada bloque se encuentra en la figura siguiente. En DOC-3
encontrar ms detalles sobre la funcionalidad de cada una de estas seales y blo-
ques.
PrecioProd PrecioProd ~
SelRegPVP SelRegPVP ~ PrecosV
ProgPrecio
AIExteror
SirveCola
Monedero
PreciosV-'-- --l
Descripcin detallada de los bloques funcionales
Bloque AIExterior
Este bloque se encargar de generar las seales para la visualizacin externa a
travs de los visualizadores de 7 elementos y de los LEDs. En modo de funciona-
miento normal (InteModo = = 'O'), se iluminarn los LEDs correspondientes a aque-
llas lneas deproducto que estn vacas. El visualizador mostrar diferentes valores,
dependiendo de las acciones del usuario, datos que sern enviados por el bloque
Monedero atravs delaseal Dinerolnt.
En modo defuncionamiento deprogramacin (lnteModo = 'O'), seiluminar el
LED correspondiente al producto cuyo precio seest programando. El visualizador
irmostrando el precio que seestprogramando para dicho producto.
La figura siguiente muestra un diagrama de entradas y salidas del bloque, as
como un esquema delafuncionalidad interna del mismo.
l/nteMod~
-1NoHayProd
PrecioProd -
-iDispUnidad
IProduct9>-
A/Exterior
-1DispDecena
UneaVacia-
HDispCentena
<,
PrecioProd-
-------rl DispUnidad>
Convertidor
entero-
MUX HDispDecena>
Dinero/nt-
7segmentos
rl DispCentena>
_ ----
l/nteModo >---
"-.......
I Producto
MUX
H NoHayProd>
LineaVacia
l
\.
L--------
..J
Se trata de un bloque combinacional, en el que se realiza la interfaz con el
exterior. Por una parte, seconvierten los datos que semostrarn en el visualizador y
por otra segeneran las seales delos LEDs.
Las entradas PrecioProd yDinero/nt secodificarn como enteros variando entre
Oy 995 y las dems seales del bloque sern detipo std_logic ystd_logic_vector. La
eleccin de los tipos enteros para las seales PrecioProd y Dinerolnt facilita el tra-
tamiento dedichos datos.
Bloque ProgPrecio
Este bloque es el encargado derealizar la programacin delos precios. Para progra-
mar unprecio, el interruptor /nteModo deber estar a 'O'. El usuario seleccionar un
producto y despus podr hacer aumentar o disminuir el precio pulsando los boto-
nes BotPVP/ncre y BotPVPDecre, respectivamente. Al pulsar una vez uno de estos
botones el precio variar en 25 pesetas. Una vez conseguido el precio deseado, que
seir mostrando en el visualizador externo, seprograma el precio mediante lapul-
sacin del botn BotDevuelve.
Este bloque generar las seales de entrada a los registros de los precios (blo-
que RegPrecio). Generar unas seales que actuarn como habilitacin de cada uno
de los registros de precio de los productos (SeIRegPVP) y otra en la que se encon-
trar el precio a almacenar (PrecioProd).
ProgPrecio
PrecoProd
SelRegPVP
El bloque ProgPrecio contiene un contador que se incrementa o decrementa en
25 unidades cada vez que se pulsan los botones BotPVPlncre y BotPVPDecre, res-
pectivamente. Asimismo, tiene un registro para guardar la informacin sobre el pro-
ducto que se ha seleccionado al comienzo de la operacin. El bloque entero estar
inhabilitado cuando el sistema est en modo de funcionamiento normal.
Para probar la funcionalidad de este bloque se comprobar que:
En modo de funcionamiento normal no funciona.
Al pulsar el botn BotPVPlncre 40 veces el valor del precio vuelve a cero.
Igual con el botn BotPVPDecre.
Se generan correctamente las seales SelRegPVP al pulsar el botn Botl)e-
vuelve. Estas seales tendrn una duraccin de un ciclo de reloj, en el que el
valor a cargar en el registro est en PrecioProd.
La seleccin del producto cuyo precio se quiere programar se puede hacer
al comenzar la operacin, durante la misma o al final, justo antes de pulsar
BotDevuelve.
Bloque RegPrecio
En este bloque se almacenarn los precios programados para cada uno de los pro-
ductos. Como salda tendr unas seales (Precios V) que indicarn los precios de
cada uno de dichos productos.
Este bloque contiene cuatro registros en los que se almacenarn los precios
programados para cada producto, con las seales generadas por el bloque anterior-
mente descrito. Los precios se codifican con valores enteros que Valan entre O
y 975.
Apndice l. Sistema Co/amatc 457
PrecioProd -r:==L_
se/RegpVp~ . Precios V
PrecioProd
SeIRegPVP(O)
G/k
Se/RegPVP(1)
SeIRegPVP(2)
SeIRegPVP(3)
o Qf--
e n
O
Q,-----
e n
O QI--
e n
O Qf--
e n
PreciosV(O)
PreciosV(1 )
PreciosV(2)
PreciosV(3)
Bloque Sirve Cola
Este bloque es el encargado del control de latrampilla de los productos y de detec-
tar ladisponibilidad deproductos. Generar las seales que indican que no hay pro-
ducto (LineaVacia).
Linea Vaca
Este bloque es muy sencillo, yaque simplemente lleva lacuenta delos produc-
tos que quedan en cada lnea, Inicialmente se considera que la lnea est llena con
30productos,
Internamente contiene un contador que se decrementa cada vez que se abre la
trampilla del producto correspondiente (TrampProd(i) ='} ').
Bloque Monedero
SirveGola
Este bloque es el encargado del control general de la mquina. Las funciones prin-
cipales que serealizan en l son:
Clculo del dinero que sehaechado.
Clculo del cambio y control de los monederos internos de la mquina. El
cambio sedevolver utilizando las monedas dems valor que seaposible. Se
supone que los monederos sellenan con 30monedas cada uno cuando seini-
cializa el sistema. Cuando los monederos se llenan (tienen ms de 50 mone-
das) el dinero echado pasar alacaja derecaudacin.
Devolucin de las monedas echadas al pulsar el botn BotDevuelve. Se de-
volvern las mismas monedas que sehan echado (monedas del mismo tipo).
Apertura delatrampilla, que seindicar al bloque SirveCola que seencarga-
rdecomprobar ladisponibilidad del producto seleccionado.
Este bloque se harealizado mediante una mquina de estados, cuyo diagrama
semuestra acontinuacin.
HayCa
Los estados anteriormente mostrados tienen asociados un conjunto de funcio-
nes, que son:
Estado inicial: en este estado la mquina se encuentra en reposo, ya que no
sehacomenzado ninguna operacin por parte del usuario.
Estado ms-mon: en este estado seincrementa el nmero demonedas que se
han echado de un cierto tipo. Si se supera la capacidad de los monederos,
seabrir latrampilla alacaja derecaudacin (MoneLleno(i) = '1').
Estado reposo: este estado es similar al inicial, aunque la mquina se en-
cuentra dentro deunciclo decompra deproducto.
Estado sel-prod: una vez se ha seleccionado el producto, en este estado se
comprueba si seha echado el dinero justo para comprar el producto, caso en
el que pasar al estado abre para abrir latrampilla del mismo, si sehaechado
dinero de ms, caso en el que sepasa acalcular el cambio, o no seha echa-
do dinero suficiente, caso en el que sepasa al estado de reposo, hasta que se
haya echado dinero suficiente.
Estado cambio: en este estado se realiza el clculo del cambio que hay que
devolver, comprobndose si hay cambio suficiente en los monederos.
Estado devuelve: se entra en este estado cada vez que se pulsa el botn de
devolucin de monedas (BotDevuelve). En l se abren las trampillas de las
monedas correpondientes.
Estado abre: en este estado serealiza laapertura delatrampilla del producto
seleccionado.
Para la comprobacin de este bloque seprobarn diversas posibilidades de in-
troduccin de monedas, seleccin de cada uno de los productos, comprobacin del
clculo del cambio y deladevolucin delas monedas.
Descripcin del test funcional
Para larealizacin del test funcional del sistema serealizarn un conjunto de simu-
laciones de los bloques por separado y una simulacin general de todo el sistema.
La estrategia que se seguir ser comprobar de forma exhaustiva cada uno de los
requisitos del sistema, ponindolo en situacin lmite en algunos casos. Asimismo, se
comprobarn los cambios demodo del sistema (inicializacin ~ ... modo depro-
gramacin deprecios ~ ... modo defuncionamiento normal).
Requisitos Qusedebecomprobar?
Inicializacin Comprobacin del estado de los registros internos. (Mone-
deros y filas deproductos llenos; resto delos registros a '0').
Programacin deprecios Comprobacin de que se programan correctamente los pre-
cios de todos los productos. Comprobacin de que el precio
mximo es de 975 pesetas. Comprobacin de las salidas por
visualizador.
Requisitos Qu seha comprobado?
Insercin demonedas Comprobacin del control de los monederos. Comprobacin
del llenado de los monederos. Comprobacin de la mxima
cantidad dedinero que sepuede echar l.Comprobacin de la
salida por display.
Clculo del cambio Comprobacin del clculo del cambio para distintas circuns-
tancias (cuando hay todo tipo de monedas, cuando slo que-
dan monedas pequeas, etc.). Comprobacin del caso en el
que no hay cambio. Comprobacin de la salida por los vi-
sualizadores.
Devolucin demonedas Comprobacin de la devolucin del cambio. Comprobacin
de la devolucin de monedas al pulsar BotDevuelve. Com-
probacin de la devolucin de monedas al superar el mxi-
mo admitido l.
Compra deproducto Comprobacin de la apertura de las trampillas de producto.
Comprobacin de la "no apertura" cuando no se ha echado
dinero suficiente. Comprobacin delaausencia deproductos
en alguna lnea vaca.
IEste requisito no seencontraba explcito en las especificaciones. Si seecha ms dinero del mxi-
mo permitido (>1.000 pesetas), las monedas introducidas en lamquina sedevolvern.
En la tabla anterior se muestran los principales parmetros que se deben com-
probar en las simulaciones funcionales del sistema. La comprobacin funcional del
sistema se realizar por inspeccin visual de los resultados de las simulaciones
tanto en las salidas del circuito como en algunas seales internas del mismo (estado
delos monederos, delas lneas deproductos, delos precios programados, etc.).
CONCLUSIN
En este documento sehan expuesto las principales caractersticas dela arquitectura
del sistema Colamatic. El cdigo VHDL resultante de esta etapa del diseo servir
de entrada ala siguiente fase del diseo, en la cual se llegar adescripcin sinteti-
zable del mismo y seoptimizar para suposterior sntesis. Las simulaciones funcio-
nales del sistema podrn ser utilizadas asimismo para la simulacin del sistema a
nivel lgico.
Apndice 1 1
NORMAS
DE CODIFICACION
yMODELADO EN VHDL
En el presente apndice se muestran una serie de reglas de codificacin y modela-
do. Este tipo dereglas deberan ser implantadas en todos los equipos dediseo que
pretendan realizar diseos industrialmente. Las reglas mostradas son desde ideas
muy sencillas (uso ordenado demaysculas y minsculas, espaciado en las distintas
secciones del texto, etc.) hasta aspectos ms relacionados con la naturaleza del
VHDL (uso deunas sentencias en lugar deotras, organizacin delos ficheros, etc.).
Estas reglas nunca sedeben considerar como una imposicin, sino simplemen-
te como una serie deideas que puedan ayudar atomar determinadas decisiones ala
hora deorganizar un equipo dediseo.
Corno el VHDL es un lenguaje formal (como el C o el Pascal), muchas de las
reglas, en cuanto aestilo serefiere, estn inspiradas en las que usan los programado-
res. Asimismo, al ser el VHDL un lenguaje que es usado para lasimulacin dehard-
ware oincluso para lasntesis del mismo, estas reglas severn afectadas por ello.
11.1. ADVERTENCIA
Las reglas que aparecen en el texto no son ms que recomendaciones (su utilizacin
est pensada para una herramienta comercial especfica y pueden no ser aplicables
para otras). En ningn momento han de convertirse en una obligacin si el uso de
las mismas va en detrimento de la productividad. El director del equipo de diseo
461
tiene la responsabilidad de valorar las recomendaciones presentadas y elegir las
ms convenientes para suequipo dediseo.
Lo que siempre es recomendable es que estas reglas sean, en la medida de lo
posible, fijas y que no vayan cambiando deproyecto en proyecto. El centro dedise-
o debera publicar sus propias reglas de modelado VHDL que todos deberan
conocer y utilizar. En el caso en el que las descripciones VHDL fuesen ledas por
personas ajenas al centro dediseo, sedeberan acompaar por las reglas de mode-
lado que sehan seguido para realizar esas descripciones.
Las recomendaciones sedividen en cuatro partes:
l. Definicin del formato del fichero VHDL.
2. Convenios sobre utilizacin debibliotecas.
3. Nombre y ubicacin deficheros.
4. Modelos para sntesis.
Al final del apndice se muestra un ejemplo correspondiente a un transmisorl
receptor serie sncrono sintetizable por una herramienta comercial.
11.2. DEFINICiN DEL FORMATO DEL FICHERO VHDL
A lahora deescribir un fichero fuente deVHDL serecomienda seguir una serie de
reglas para que todos los ficheros que seusen, sea quien seael autor, tengan el mis-
mo aspecto.
11.2.1. Aspecto general del texto
El cdigo debe usar de un modo coherente las maysculas y minsculas, es decir,
las palabras reservadas del VHDL debern estar todas en maysculas o en minscu-
las. Serecomienda que los identificadores (nombres de variables, deseales, proce-
dimientos, etc.) utilicen maysculas y minsculas.
Usar solamente 80 caracteres por lnea, y solamente una instruccin por lnea.
No usar tabuladores. En sulugar usar dos espacios encada nivel deindentacin.
Agrupar las instrucciones si realizan una funcin comn. Estos grupos debern
separarse convenientemente (con una lnea enblanco ocon guiones).
Alinear los comentarios, identificadores, etc., verticalmente para favorecer la
lectura del cdigo.
11.2.2. Identificadores
Para facilitar la lectura de las descripciones, es muy til usar maysculas y mins-
culas en los nombres decualquier objeto del VHDL. Por ejemplo, en lugar deescri-
bir una funcin con el nombre detectordeflancopositivo, es mejor escribir el nombre
como DetectorDeFlancoPositivo. Esto es preferible ausar el carcter '_', que esta-
rareservado para otros cometidos.
Apndice 11.Normas de codificacin y modelado en VHDL 463
Usar una longitud mxima de los identificadores de 25 caracteres.
Si una seal o variable es activa por nivel bajo, indicarlo mediante el uso de un
sufijo adecuado (N, n, z, b, etc.).
En algunos casos puede ser aconsejable utilizar un prefijo en el nombre de las
variables, seales y funciones que determine el tipo de dato que representan. Existe
una serie de prefijos de uso comn, pero en el caso que por las necesidades del mo-
delo sea necesario usar un prefijo nuevo, se especificar mediante un comentario al
definir el tipo o subtipo al que pertenece ese prefijo. Los prefijos ms usuales son
los siguientes:
i:integer.
s:std_logic.
b:bit.
l:boo1ean.
u:std_u10gic.
t:Declaracin de tipos.
e:Declaracin de constantes ..
Si va acompaado con una 'v' ('sv', 'xv', ... ) indica que se trata de un vector.
Si va acompaado con una 'e' ('se', 'xve', ... ) indica que se trata de una constante.
De esta manera la funcin DevuelveUnEntero quedara iDevuelveUnEntero,
resultando explcito el tipo.
11.2.3. Comentarios
El objetivo de los comentarios es facilitar que el cdigo pueda ser entendido por
otra persona distinta a la que 10ha escrito.
Los comentarios deberan estar en un nico idioma (ingls si va a ser ledo por
personas de distintas nacionalidades).
Su contenido debe ser 10 ms descriptivo posible y no una mera repeticin o
traduccin del cdigo VHDL, al que complementa.
Deben situarse prximos a las partes del cdigo que describen; no es aceptable
una cabecera que explique todo el cdigo que aparezca a continuacin.
Los comentarios debern alinearse y estar justificados para facilitar su lectura.
Cada fichero debera incluir una cabecera que contenga, como mnimo, la
siguiente informacin:
Nombre de las unidades en el fichero.
Nombre del fichero.
Descripcin del hardware modelado (si procede).
Limitaciones del modelo, errores conocidos y cualesquiera restricciones im-
puestas.
Lista de dependencias (si procede).
Autor(es), incluida direccin de contacto.
Simu1ador(es) (incluida versiones) usados.
Lista de versiones, autores de las modificaciones y fechas de las mismas, as
como una lista de las modificaciones realizadas.
Cada declaracin de un subprograma, proceso, bloque, etc., debera estar pre-
cedido por una descripcin de su funcin, as como las limitaciones y restricciones
impuestas. En los subprogramas es conveniente comentar adems los parmetros y
resultados.
En ladeclaracin depuertos y genricos es til incluir comentarios describien-
do cada seal y parmetro. No serecomienda agrupar los comentarios por una parte
y las declaraciones por otro, yaque sepueden producir errores en el caso demodifi-
caciones.
11.2.4. Tipos
Es recomendable que el bit situado ala izquierda de un vector sea siempre el ms
significativo, independientemente del orden de los bits. Por ejemplo, en VectorDe-
Bits(O to 15), el bit Oes el bit ms significativo (MSB), mientras que en' Vector-
DeBits (15downto O), el bit Oes el bit menos significativo (LSB).
De este modo se recomienda que a la hora de declarar tipos, el orden, en el
caso en el que el ndice sea un entero (caso tpico de buses), sea descendente, es
decir, VectorDeBits(7 downto O). Esto facilitar la lectura del contenido de los bits
en las simulaciones.
Se recomienda escribir el cdigo de manera que sepueda modificar el tipo de
una seal ovariable sinmodificar el resultado de las simulaciones. Esto implica:
Evitar el depender delainicializacin por defecto delas variables o seales a
no ser que una poltica de reset asegure que el modelo es explcitamente ini-
cializado.
Evitar depender del nmero devalores deun tipo determinado.
Evitar depender del orden en el que sehan declarado los valores del tipo.
11.2.5. Seales y puertos
Siempre que sea posible se usar el mismo nombre para una seal a lo largo de la
jerarqua del diseo. En el caso en el que no se pueda usar exactamente el mismo
nombre seusar un nombre derivado del primero.
Laordenacin delos ndices debera ser lamisma alo largo delajerarqua, sea
sta ascendente (usando to) o descendente (usando downto). Se recomienda usar la
misma poltica deindexado en todo el modelo (todos los ndices ascendentes o des-
cendentes). En el caso en el que seproduzca una inversin en los ndices, sedeber
advertir claramente.
No es recomendable utilizar el modo buffer en la entidad de ms alto nivel del
diseo.
Ladeclaracin deentradas/salidas debera realizarse enun orden lgico:
Se recomienda poner primero las entradas, luego las seales bidireccionales
ypor ltimo las salidas.
Alternativamente sepueden agrupar atendiendo asufuncin.
Apndice 11. Normas de codificacin y modelado en VHDL 465
Opcin 1: Entradas/salidas
p o r t (
s Ha b
S C1 k
S Re s e t _ n
i n s t d _ l o g i c ;
i n " S t d _ l o g i c ;
Opcin 2: Por funcionalidad
p o r t (
s Ha b : i n s t d _ l o g i c ;
S VCUe n t a : out
s t d _ l o g i c _ v e c t o r ( 3 d o wn t o O)
- - f u n c i e n .
s F i n Cu e n t a o u t s t d _ l o g i c ; S F i n Cu e n t a o u t s t d _ l o g i c ;
S v Cu e n t a o u t
s t d _ l o g i c _ v e c t o r ( 3 d o wn t o O~
- - f u n c i o n
S Cl k
S Re s e t _ n
ins t d _ l o g i c ;
); );
En cualquier caso, las seales estarn comentadas, una auna, como sehadicho
anteriormente.
En las referencias alos componentes no seusar la asignacin por posicin, a
no ser que los nombres de las seales sean 10 suficientemente representativos (mis-
mo nombre o derivado). Lo mismo se aplicar a los parmetros genricos. Por
ejemplo:
a r c h i t e c t u r e F u n c i o n a l o f COI ; l t a d o r BCD i s
c a mp o n e n t Ca mp Co n t a d o r 1
g e n e r i c (
t S u b i d a T I ME ;
t Ba j a d a T I ME ) ;
p o r t (
s E n a b 1 e
s Cl k
- - T i e mp o d e s u b i d a d e l a s s a l i d a s
, ' - - T i e mp o d e b a j a d a d e l a s s a l i d a s
s Re s e t _ n
s F i n Cu e n t a
- - He b i 1 i t a c i 6 n d e c u e n t a
- - Re l o j d e l s i s t e ma
- - Re s e t g e n e r a l ( n i v e l b a j o )
- - F i n d e c u e n t a ( a c t i v o n i v e l a l t o )
- - ( a c t i v o u n s o l o c i c l o d e s C1 k )
o u t s t d _ l o g i c _ v e c t o r ( 3 d o wn t o O) ) ; - - Va l o r d e l c o n t a d o r
i n s t d ; : . _ 1 o g i c ;
s v Cu e n t a
s i g n a l s s l , s s 2 , s s 3 , s s 4 : s t d _ l o g i c ;
s i g n a 1 s v b 1 : s t d _ l o g i c _ v e c t o r ( 3 d o wn t o O) ;
b e g i n
Co n t a d o r 1 : Co mp Co n t a d o r 1
g E me r i c 1Il@(
t S u b i d a : = 2 n s ,
. t Ba j a d a : = 2 n s )
.poit map(
s E n a b 1 e => s s l ,
s C1 k => s s 2 ,
s Re s e t _ n => s s 3 ,
S F i n Cu e n t a => s s 4 ,
s v Cu e n t a => s v b 1 ) ;
e n d F u n c i o n a l ;
Todos los procesos contarn con una etiqueta descriptiva. Lo mismo seaplica a
cualquier sentencia concurrente siempre que esto mejore la legibilidad. De este
modo es ms fcil referirse aellos en las simulaciones interactivas.
RegistrQ1 process (... )
begin
end process Registro1;
Principal: process( .. )
begin
end process Princi.;lal;
Los procesos con una sola sentencia wait (tpico en procesos sintetizables)
debern usar en su lugar una lista de sensibilidad en lugar de la sentencia wait, ya
que esto mejora lalegibilidad.
La lista de sensibilidad de un proceso deber incluir TODAS las seales que
estn en la parte izquierda de una asignacin, as como las que vayan a ser usadas
en construcciones condicionales (if, case, etc.). Esto es especialmente importante en
aquellas descripciones orientadas alasntesis. Por ejemplo:
BIEN MAL
P1 : process (bClk, iAddress, bRequest)
begin
ifbClk' event and bClk = ' l' then
ifbRequest = ' l' then
bvSalida <= bvMemoria(iAddress) ;
end if;
end if;
end process P1;
Pl : p~ess (.bClk).
begin
ifbClk' event and bClk = ' l' then
if bRequest = ' l' then
bvSalida <= bvMemoria(iAddress) ;
end if;
end if;
end process P1;
Se deben evitar los procesos que modifiquen variables o seales no incluidas
como parmetros en lallamada alamisma.
Laentidad dems alto nivel deber tener el mismo nombre que el dispositivo o
hardware modelado.
Utilizar siempre los mismos nombres para las distintas arquitecturas de una
misma entidad. Serecomiendan los siguientes nombres:
Funcional.
Comportamiento.
Sntesis.
La arquitectura Funcional sera cualquiera que no est pensada para su sntesis
posterior. La arquitectura Sntesis sera cualquiera pensada para sntesis (bien sea
descripcin RTL, estructural o algortmica). Si hay varias arquitecturas, se puede
incluir un nmero al final del nombre (Funcionall, FuncionaI2 ... ).
11.2.6. Paquetes (packagesJ
Es preferible usar siempre los packages aprobados por la IEEE en lugar de cons-
truir packages defuncionalidad similar (por el momento el nico aprobado es el IE-
EE.std_logic_l164). Cualquier otro package deber ser suministrado en la misma
biblioteca dediseo que el propio modelo.
No se debe usar un nmero exagerado depackages a no ser que claramente
mejore lalegibilidad.
No se debern usar package s vacos o casi vacos. Se recomienda colocar el
cdigo VHDL de la misma funcionalidad en packages distintos (parmetros de
timing por una parte, procedimientos y funciones relacionados con el timing por
otra, etc.). No habr unpackage para cada entidad en el que sedefinan constantes,
etc., para esaentidad, ano ser que suuso mejore lalegibilidad deladescripcin.
Las declaraciones en el package body aparecern en el mismo orden que en la
declaracin del package.
La declaracin del package contendr una documentacin completa sobre los
tipos declarados, constantes, subprogramas, etc.
11.3. CREACiN y UTILIZACiN DE BIBLIOTECAS VHDL
Para evitar problemas deincompatibilidades entre los modelos descritos en VHDL,
hay una serie derecomendaciones en cuanto al uso y generacin debibliotecas. Es-
tas recomendaciones se dividen en dos partes. En primer lugar, hay unos consejos
para la correcta utilizacin de los tipos y componentes disponibles en las bibliote-
cas. Por otra parte, seexplica un mecanismo, que seaconseja seguir, que permitir
llevar un control de las revisiones de los componentes, procedimientos y funciones
que sevayan creando. Lautilizacin deesta recomendacin no dificulta en absoluto
la generacin de cdigo y simplificar enormemente el mantenimiento de bibliote-
cas, especialmente en diseos grandes.
11.3.1. Utilizacin de tipos, componentes y funciones
Usar solamente tipos bsicos y la lgica MVL9 (IEEE 1164), que est definida en
el paquete std_logic_1l64.
Hacer que los componentes bsicos lleven una referencia a la biblioteca a la
que serefieren. No es necesario que los componentes especficos deuna aplicacin
lleven dicha referencia.
Dentro de las arquitecturas se recomienda trabajar con tipos 'O1', 'XOl' Y
'XOIZ'. Esto acelera la simulacin y facilita la especificacin. De todas maneras,
los interfaces entre distintos bloques o componentes deberan usar siempre MVL9.
Limitar siempre el rango de las variables enteras (si ste se conoce). Esto es
especialmente necesario si ladescripcin estpensada para sntesis.
11.4. NOMBRE y UBICACIN DE ARCHIVOS
Serecomienda que en cada fichero que corresponda aundiseo seincluya:
Entidad.
Arquitectura (1arquitectura por fichero en el caso desntesis).
Configuracin.
Cada fichero ser nombrado de acuerdo con launidad de diseo que contiene,
es decir:
Entidad, Arquitectura &Configuracin: nombreEntidad. vhd
Entidad, Arquitectura & Configuracin: nombreEntidad-nombreArq. vhd
Package & Package Body: nombrePackage-pack.vhd
Los archivos seencontrarn en un solo subdirectorio, sinjerarqua explcita. Se
recomienda, sin embargo, documentar convenientemente lajerarqua en un fichero
detexto.
11.5. MODELOS PARA SNTESIS
Las siguientes recomendaciones han sido generadas para laelaboracin demodelos
VHDL orientados a la sntesis. Estas recomendaciones tienen validez para una
determinada herramienta de sntesis y pueden no ser vlidas para las herramientas
de las que disponga el lector. En cualquier caso, en cualquier equipo de diseo es
til disponer deestetipo derecomendaciones.
11.5.1. Recomendaciones generales
La manera de realizar las descripciones en VHDL orientadas a sntesis determinan
en gran medida la calidad del diseo sintetizado. Es por eso que hay que tener en
cuenta una serie de reglas fruto de la experiencia que evitan, no que el diseo no
sea adecuado funcionalmente, sino que el hardware generado no seatodo 10 ptimo
que sera deseable.
11.5.2. Variables y seales
Usar seales siempre que vayan a tener visibilidad fuera del proceso en el
que su valor sea modificado.
Apndice 11.Normas de codificacin y modelado en VHOL 469
-- Procesoquerepresenta uncontador conla. seal cuentavisible
,-- desdeel exterior.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - ~ ~ - - - - - - - - - - - - - ~ ~ - - - ~ ~ - ~ - - - - - - - - - - - ~ ~
signal cuenta: natural range._Oto 10;.
C ON T A OOR : process(reset_N , clk, cuenta)
begin
it reset_N '" '0' then
cuenta<= O;
elsif clk' event andclk = ' l' then
if cuenta< 10 then
cuenta<= cuenta+ 1;
else
cuenta= O;
endif;
endif;
enprocess C ON T A OOR ;
salida <= ' l' whencuenta= 7else
~O' ;
Usar variables siempre que no vayan a tener visibilidad juera del proceso en
el que son declaradas y usadas.
-- Procesoenel ques610nos interesa la seal salida.
: -- La variable cuentaquedadentrodel proceso.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~ ~ - - - - - - - - - - - - - - - - - - -
C ON T A DOR : process(reset_N , clk)
variable cuenta: natural rangeOto 10;
begin
if reset_N = ' 0' then
cuenta := O;
salida <= '0';
elsif clk'event andclk O'1' then
salida <= '0';
if cuenta< 10 then
cuenta := cudnta+ 1;
salida <= '1';
else
cuenta .- O;
endif;
endif;
endprocess C ON T A OOR ;
Para que una variable no genere un elemento de memoria es imprescindible
que se le asigne un valor en cada time-step (cada vez que se ejecute el pro-
ceso).
No depender nunca de los valores por defecto de las variables y seales.
- - L a s s i g u i e n t e s i n i c i a l i z a c i o n e s s o n v l i d a s p a r a S I MUL ACI N, NO p a r a
- - s n t e s i s .
------------------_ . . . . _---_ . . . _-------------------------. . . . . . . . . . . . . . ---~.-.~- . ."'~. ' ...~. . . .~. . . . . -
s i g n a l s l : s t Q_ l o g i c ;
s i g n a l s 2 b i t :
s i g n a l s 3 : i n t e g e r ;
- - t o ma p o r d e f e c t o e l v a l o r ' U'
- - t o ma p o r d e f e c t o e l v a l o r 'O'
- - t o ma p o r d e f e c t o e l v a l o r - 2 1 4 7 4 8 3 6 4 8
No usar nunca la inicializacin de variables y/o seales en la declaracin de
las mismas: en sntesis son ignoradas.
Las seales o variables cuyos valores sean asignados en bloques combinacio-
nales (bien procesos, bien asignaciones concurrentes), tomarn un valor siempre
que las seales delas que dependan lo tengan. Las seales y/o variables que proce-
dan debloques secuenciales debern contar con una inicializacin, bien secuencial,
bien combinacional.
- - I n i c i a l i z a c i o n e s p a r a s n t e s i s
- - As i g n a c i n concurrentes l a s e a l ' s l ' ~t : ! ; ; : i n t . c : i a l i z a d a
- - c o r r e c t a me n t e s i l a s s e a l e s ' e l ' , ' e 2 ' , ' e 3 ' e s t n
- - i n i c i a l i z a d a s :
s l <= ' 1 ' wh e n e l = ' 1 ' and e 2 = ' O' e l s e
'O' wh e n e 3 = ' 1 ' and e 2 = ' 1 ' e l s e
'Z' ;
- - P r o c e s o s : l a s e a l s 2 s e r i n i c i a l i z a d a c o r r e c t a me n t e g r a c i a s a
- - l a s s e a l e s ' r e s e t _ N' o ' c l e a r _ N' :
P 1 : p r o c e s s ( c l k , r e s e t _ J l , clear':'_N, dn)
I;legin
i f r e s e t _ N = ' O' t h e n
s 2 <= 'O'; -- I n i c i a l i z a c i n a s n c r o n a
e l s i f clk' e v e n t and clk = ' 1 ' t h e n
i f c l e a r j N = ' O' t h e n
s 2 <= 'O';
e l s e
d o u t <= d i n ;
end if;
e n d if;
end p r o c e s s P I ;
- - I n i c i a l i z a c i n s n c r o n a
11.5.3. Lgica combinacional
Hacer los bloques combinacionales con construcciones concurrentes, o bien
con proceso en los que no aparezca el reloj.
Esto hace que la herramienta de sntesis produzca un hardware ms eficiente
en cuanto area serefiere. En particular, esta regla sepuede aplicar alas seales de
seleccin deregistros:
entity pl is
p o r t ( sell, sel2
IW
in bit;
in bit;
in bit;
in bit;
in bit;
reset~N
c1k
datoin
datoout out bit);
end pl;
architecture a2 of pl is
signal datol, dato2, readl , read2,. Wl;"ite1, write2 bit)
begin .
-- Parte combinacional
readl
read2
write1
write2
<= IWand sell;
<= IWand sel2;
<= not (IW) and sa11;
<= not(IW) and sel2;
-- Senal de lectura de dato1
-- Senal de Iectura de dato2
-- Seal de escritura de dato1
-- Seal de escritura de datQ2
-- Salida combinacional
datoout <= dato1 whenreadl = ' l'else
dato2 when read2 = 'l'else
' O' ;
-- Parte secuencial
principal : proceSS(rest_N,Sel1; S12, IW, datn, clkT
begin
ifreset_N. = '0' then
dato! <= ' 0' ;
dato2 <= ' O' ;
elsif clk'event and clk = '1' then
if write1 = '1' then
dato1 <= datoin;
end inf;
ifwrite =. '1' then
dato2 <= datoin;
end if;
end if;
end process principal;
end a2; .
Tener cuidado con el uso de sentencias if-then-elsif: no hacer nunca exclu-
yentes bloques combinacionales independientes, ya que el hardware resul-
tante es ms complejo.
En el ejemplo anterior setiene el siguiente cdigo:
-- C OR R EC T O
i f wr i t e 1 = ' 1 ' t h e n
d a t o 1 <= d a t o n .
end i f
i f wr i t e 2 = ' 1 ' t h e n
d a t o 2 <= d a t o n :
e n d i f
Pero sepodra haber escrito (incorrectamente):
-- I NC OR R EX :'l'O: T a l y c o mo s e ha h e c h o l a d e s c r i p c i n , n u n c a s e p u e d e
- - p r o d u c i r e l c a s o e n e l q u e wr i t e 1 y wr i t e 2 e s t n a c t i v o s a l a v e z .
i f wr i t e 1 = ' 1 ' t h e n
d a t o 1 <= d a t o n .
e l s i f wr i t e 2 = ' 1 ' t h e n
d a t o 2 <= datonr
e n d i f
Para permitir que la herramienta de sntesis optimice bloques combinacio-
nales, se puede utilizar el valor '-' del tipo std_logic.
- - As i g n a c i n c o mb i n a c i o n a l
s a l i d a <= 0 0 0 wh e n e n t r a d a = 0 0 e l s e .
0 0 1 wh e n e n t r a d a = 0 1 e l s e
1 0 1 wh e n e n t r a d a = 0 1 e l s e
M
,
En procesos que describen lgica combinacional, asegurar que las salidas
toman un valor, sea cual sea el camino de control.
En muchos casos, la manera ms conveniente de hacer esto es hacer, al prin-
cipio del proceso secuencial, una asignacin de valores por defecto de todas las
salidas:
-- Se q u i e r e q u e s a l i d a s e a 0090 c u a n d o n o s e a n i n g u n a o p c i n
- - v l i d a '
s a l i d a <= ( o t h e r s => ' O' ) ;
i f o p c i o n = " l O t h e n
s a l i d a <= 1010 ;
end i f ; _
ifo p c i o n ' " 01" then
' s a l i d a <::; " 010V;
end if;
En otros casos se puede usar la sentencia else, siempre que haya decisiones
excluyentes con if-then-elsif:
- - E s i n Qi f e r e n t e e l v a l o r q u e t o me s a l i d a s i n o v a l e , p i n g u n a ,
- - o p c i n .
i f p r i me r a Qp c i o n = " l O t h e n
s a l i d a <= 1010 ;
e l s i f s e g u n d a Op c i o n = 01" t h e n
s a l i d a <= 0101" ;
e l s e
s a l i d a <= ( t h e r s => ' - ' ) ;
e n d if;
11.5.4. Procesos secuenciales
Hacer los bloques secuenciales con la construccin if clk'event and clk = 'L'
(o 'O'), no pudiendo aparecer ninguna otra condicin en dicha construc-
cin. En casos muy especiales se pueden usar otras construcciones (ver
apartado //.5.10).
-- CORROCTO: Biestable con enable
-----_ ..... -..;...---------.... _------:--~~;..~ ....
pl : process (reset_N., d, e, 'clk}
begin
if reset_N = 'O' then
,1<= 'O'
elsif clk' event and clk = '1' then
if e = 'O' then
q <= d
end if
end if
end process pI;
La mayora de las herramientas slo permiten el uso de un reloj en cada
proceso secuencial. En el caso de tener varios relojes en el sistema, o los dos
flancos de un mismo reloj, utilizar procesos distintos para cada reloj. Si
es necesaria la comunicacin, implementarla como se describe en el aparta-
do /1.5.7.
p1 : process(reset_N., datolnt, clk1)
begi n
if reset_N = ~O' then
,datolot <= 'O';
elsif clk1'event andclk1 =' '1' then
datolnt <= datolnt;
end if;
endprocess p1;
p2 : process(reset_N, datoInt,clk2)
begin "
if. reset_N = 'O' then
datoOut <= ' O';
elsif clk2' event andclk2 = '1' then
datoOut <= datolnt;
endif.;
endprocess p2;
No escribir el cdigo de manera que la construccin if clk'event and clk =
'L' (o 'O') est englobada en otra construccin if-then-else o en un buclefor.
S se pueden usar, sin embargo, bucles while (ver apartado /1.5.10).
-- INCORRECro: la lnea dondese usa el reloj est dentro deun bucle
- - - - - - - - - - - ~ ~ - - ~ - - ~ ~ . _ - - - ~ - - - - - - - - - - - - ~ - - - - - - - - - - - - - - - - - - - ~ ~ ~ - ~ - - ~ - ~ ~
for i i n O to 1 loop
if reset_N = ' 0' then
if b(i) = '1' and c(i) = '0' then
dato(i) <= T U " ,;
el.se
dato(i) <= '1';
end'if;
tflli:recctonc~reaaraddtess, mascara, mustra) tn
dato(i) <= datoin(i);
end ifl
end if;
end loop;
-- CORRECl': l" linea dondese usa el reloj est fuera del bucle
________ :... ..._~.:. ...~:...:..._:.:...;;., ......'~_ ..._~.... .. ;.;U .li..:..: ... _':.. ... ~__ ~-~ _
ifreset.)il = ' O' then
for i in O to 7 loop
ifb(i) :; '1' and c(i) '0' then
dato(il <= '0';
else
dato(i) <= '1';
end if;
for i in O to 7 loop
ifDireccionCorrecta(address, mascara, muestra) then
dato(i) <= datoin(i);
end if;
end loop;
end if;
Usar funciones para reducir la complejidad del cdigo (ver apartado 1/.5.5).
En algunas descripciones puede ser necesaria una gran cantidad dedecisiones
antes derealizar unaaccin determinada. El englobar esto enunafuncin oproce-
dimiento permite queel cdigo seams fcil deleer y haceque laherramienta de
sntesis cuente conunparticionado quelefacilita laoptimizacin. U nejemplo esel
siguiente:
if reset.)il = iO' then
dato <:; (others => ' 0' ) ;
elsH c:lk'event-imdclk = l
i
then
if DireccionCorrecta(address, mascara, muestra) then
date <= datoin;
endif;
endif;
No introducir cdigo que pueda generar lgica combinacional en procesos
secuenciales a no ser que se usen variables (ver apartado //.5.5).
-- Incorrecto: 'parte canbinacional dentro del proceso
process(reset..)l', clk, din, dato~anterior)
-J :ieijin - - ...'
Hreset_.N= '9' then
dato_andar <=..'-0';
elsif clk'evrit and clk = ,pthen
dato_anterior <= dn;
end if; .
if din = '1' and dato_anterior = ' O' then
--dUt <; '1';-
else
dout <= ' 0 ' ;
end if;
end process;
Correcto: parte cOOlbinacionalfuera del proceso
-- Parte secuencial
procesa lreset'"..:.1t,"''ctk; din)
bgin
-tfreSetJ { ;n(),then
dato anterior <= '0';
~lsif 'lx'I ~t ;aRdd_k- it, '1: then
dato_arlteior . <=_. din;
endif;
end process;
-- Parte combinacional
dout <= il'----when dato_anteri -= ' (}' and din ~-, l' else
' O ' i
No incluir en el mismo proceso operaciones secuenciales que se deben hacer
en paralelo o no tengan funcionalidad comn. Si tienen seales en comn,
implementar una comunicacin entre procesos como la descrita en el apar-
tado l/.S.7.
11.5.5. Procesos mixtos
Reducir al mnimo el uso de procesos mixtos. Slo es conveniente cuando se
usen variables que no vayan a tener visibilidad externa (juera del proceso).
11.5.6. Uso de subprogramas I
Agrupar en subprogramas todo el cdigo relacionado con una misma fun-
cionalidad. Esto es una pista para que el sintetizador pueda hacer una opti-
mizacin ms eficiente.
No usar llamadas recursivas afunciones.
-- Esta funcin se llamaa si misma
funCtionRestaUno(arg: integer) return integer is
begin
ifarg > Othen
return RestUno(arg)
end if
return I'g
endRestaUno
No usar atributos de seales dentro de funciones.
S sepueden usar atributos detipo y dearray.
No usar dentro de subprogramas seales o variables que no hayan sido
pasadas como parmetros en la llamada al subprograma.
-- INCORRECro: la seal Sa:).idanoes pasadacomo parmetro
procedure EnviaCdato.: std...,logi.c.)....Is,.... .
begin
-- Salida est definida enla entidad.
Salida <= dato
end Envia
I Porsubprogramas seentiende funciones (functions) y procedimientos (procedures).
-- C()RRECTO: la seal ~li& es e:viada como parmetro
procedure Envia(dato : std_logic; signal out : Salida) is
be gi n
Salida <= dato;
end Envia;
Se pueden usar subprogramas concurrentes para generar bloques combina-
cionales.
architecture Sintetizable of Bloquel i s
~;t
function BCDa7Segrnentos( codBcd: in std_logic_vector(3 downto O) )
return std_l:ogic_vetor(7 downto TI)\is
variable: LEOs : std_logic_vector{7 downto O);
be gi n
case codBcd is
when "0000" => LEOs .- "1111110";
when ".oGG1"=> LEOs := "lHlGGOO";
when "OUO" => LEDs
when "0111" :>LEOs
when "1000" => LEOs
when "1001" => LEOs
when others => LEOs
end case;
return LEOs;
end BCDa7Segrnentos;
.-
"OUUU" ;
.- "11Q0010";
.-
"m.UU;
.-
U10111" ;
.-
"0000000;
signal cuenta: std_logic_vectorO doento O);
be gi n
,-- Q.J .enta procede, por eje!li>lo, de un contador sncrono de 4; bits;
-- LEOes una salida Gel c.rcuno;
LEO<= BCDa7Segrnentos(Cuenta) ;
end Sintetizable;
11.5.7. Comunicacin entre procesos
A la hora de comunicar varios procesos, no presuponer nunca un orden de
ejecucin de dichos procesos. Se usar un sistema de comunicacin adecua-
do, bien un handshake explcito, si los procesos funcionan a distinta veloci-
dad, bien un sistema de comunicacin mediante seales de habilitacin de
procesos.
No mezclar nunca distintos sistemas de comunicacin entre procesos dentro
deun mismo bloque.
11.5.8. Mquinas de estados
Tanto para las mquinas de Moore como las de Mealy, conviene separar la
parte secuencial de la combinacional. Hacer las asignaciones de las salidas
con sentencias de asignacin concurrente; la asignacin del siguiente estado
con un proceso y una sentencia case; construir los registros en otro proceso
separado.
Representar los estados en las mquinas deestados con los valores deun tipo
especfico para cada mquina deestados. Estos valores sern nombres repre-
sentativos.
type tipoEstados 's (OOCIO, DEm:CT_l, A BORT, DETa:T_2, FIN);
COMBINA CIONA L : process (estado, entrada1, entradaz , entrada3 )
begin
case estado is
when INICIO =>
if entrada1 = '1' then
sigEstado <= AB0RT;
elsif entrada2 = 'O' and entrada3 = '1' then
sigEstado <= DETECT_2;
else
sigEstado <= INICIO;
end if ., .......
when DETECl'_ 1 =>
sigEstado <= F I N;
else
sigEstado <= DETECl' ....l;
end if;
when A BORT =>
if entrada2 ..,"",/1: then
sigstado' <~~riEm:T.. );
else
sigEstado <= DETECT ... J;
end if;
when DETECT_2=>
sigEstado <= FIN;
else
's~gESj;:ado <= AOORT
end if .
when FIN =>
if enl::i:c1dal = 'O' and'entrada2 = .'{}, and entrada3 = 'O tlien .'
sigEstado <= INICIO
else
sigEstado <= FIN;
end if
end case
end process C()ffilNACI~
SFX::UEOCIAL ': processtclk, reset_N; sigEstado)
begin
ifreset...N = .' O' then
estado <= INICIO
elsi; cWev~t and C;llt,,:;,'F .H~rn
estado, <=_ sigEstado . .,
ertd ffi ". ... , .
end process SECUENCIAL
-- 'Generacin de salidas
-- Si salidas = flestado actual, entradas)
-- Si salidas = f(estado actual)
-- En este caso es una mquina de Moore
salida1 .<= '1' when estado = INICIO el se
'1' when estado = DE'lEl'_3 else
'Ol
Mquina de Mealy
Mquina de Moore
salida2 <= '1' when estado = ABORTelse
'1' when estado = FIN else
'0' ;
11.5.9. Comparticin de recursos
Las herramientas de sntesis suelen hacer, cuando pueden, comparticin derecursos
que claramente no coinciden en el tiempo. En determinados casos se les puede
'ayudar'.
En el caso de contadores que se quieran compartir y estn dentro de una
descripcin funcional, se puede usar la misma seal en los dos casos.
11.5.10. Sistemas "muy secuenciales" (procesos
con mltiples waits)
Hay que tener en cuenta que estos procesos no recomienzan hasta que haya
acabado el ciclo anterior. Es por ello que slo se usarn en aquellos casos
en los que se desea realizar una funcin "indivisible" y "autnoma".
Todos los waits tienen que usar el reloj del sistema.
Apndice 1/. Normas de codificacin y modelado en VHDL 481
11.5.11. Uso de tipos
Las entradas y salidas de los bloques de ms alto nivel deberan ser de tipo
std_ulogic o std_logic. Para asegurarse de que no se estn haciendo cone-
xiones de seales no deseadas, se pueden usar tipos no resueltos (en este
caso, std_ulogic).
En bloques de menor jerarqua se pueden usar tipos no estndar, ya que
stos permiten una rpida ampliacin de la funcionalidad y son ms fciles
de mantener y entender por el equipo de diseo.
Cuando se necesiten varios resultados de una funcin, se podrn usar varia-
bles tipo registro. Estas variables tienen que tener los campos relacionados
para evitar confusiones.
11.5.12. Descripciones estructurales
Por limitaciones de algunas herramientas de Sntesis, las referencias a com-
ponentes tienen el mismo nombre que los bloques a los que se corresponden.
Las seales de entrada a un bloque que no vayan a ser usadas dentro de ese
bloque se pondrn a un valor fijo (para la optimizacin plena, ponerlo a
valor '-' de std_logic).
Las seales de salida de un bloque que no vayan a ser usadas se dejarn sin
conectar. La herramienta de sntesis eliminar el hardware que no sea nece-
sario.
Poner un nombre significativo a todas las seales que conecten bloques en
una descripcin estructural.
11.5.13. Uso de los parmetros
/1.5.13.1. Introduccin
En sntesis, como mucho, slo permite que los genricos sean enteros, o bien tipos
enumerados que puedan asimilarse aenteros. Es por ello que para hacer una para-
metrizacin eficaz, no es suficiente con el uso degenricos.
La solucin que aqu sepropone es el uso combinado degenricos y constantes
definidas en unpackage. El uso deestas constantes permite controlar el proceso de
sntesis, demodo que sepuede:
1. Modificar la funcionalidad: se puede cambiar el modo de funcionamiento.
Por ejemplo, el lmite de cuenta de un contador o los niveles activos de las
seales dee/s deuna entidad.
2. Modificar la estructura: se pueden eliminar determinados componentes o
funciones del bloque completo.
3. Elegir componentes individualmente para optimizar los resultados.
11.5.13.2. Modificacin de la funcionalidad
Los genricos y las constantes se pueden usar siempre que representen valo-
res escalares sin ningn problema:
entity Contador is
Generic( maxCuenta natural:= 10;
valActivo natural:= 7) ;
Port( ... );
endContador;
signal cuenta : natural range O to maxCuenta;
CO NTADO R: process(reset-N, clk, cuenta)
begin
if;reseCN ='O , then
cuenta <=O ;
els,if clk'event and c1k ='1' then
ifcuenta <maxCuentathen
cuenta <=cuenta + 1;
else
cuenta <=O ;
end if;
end if;
end process CO NrAO O R;
salida, <='1' whencuenta =valActi va.ei~e
' O ' ;
Los genricos y constantes tambin se pueden usar como si fuesen valores
booleanos:
constant cSincrono : boolean :=true;
-- IDsiguiente dependede unaconstante, 'por lo queal sintetizar, la
-- salida de este bloque ser, bien combinacional, bien secuencial.
Apndice 1 / . Normas de codificacin y modelado en VHDL 483
ifc S i n c r o n o = t r u e t h e n
_:: PaIte f c t . i E l f t c i a l ( o p c i o n a l )
ifr e s e t _ N = 'O' t h e n
.Sa,lida <:;: '.1';
e l s i f clk'event andclk = '1' then
Salida <= Entrada;
end i f ;
e l s e
_ _ P a r t e c o mb i n a c i o n a l ( o p c i o n a l )
Salida <= Entrada;
end if;
1 1 . 5. 1 3. 3. Modificacin de la estructura
Para sustituir bloques combinacionales representados mediante asignacio-
nes concurrentes se usar la sentencia generate.
c o n s t a n t T i p o Co n t a d o r : t Co u n t e r := 2 _ Op t s ;
i f T i p o Co n t a d o r = 2 _ Op t s g e n e r a t e
f i n c u e n t a <= 1 4 wh e n d e l a y ' I y p e = 1 e l s e
2 3 ;
i f T i p o Co n t a d o r = l _ Op t s g e n e r a t e
f i n c u e n t a <= 6 5 ;
end g e n e r a t e ;
i f T i p o Co n t a d o r = 3 _ Op t s g e n e r a t e
f i n c u e n t a <= 3 4 wh e n d e l a y T y p e = 1 e l s e
3 2 wh e n d e l a y ' I y p e = 2 e l s e
3 1 wh e n d e l a y ' I y p e = 3 e l s e
6 7;
Para sustituir bloques combinacionales representados mediante procesos, se
pueden usar genricos o constantes.
En descripciones estructurales, la sustitucin de componentes se har me-
diante la sentencia generate.
1/.6. EJEMPLOS
123 4 5 678
--34567890123456789Clf23456789012345678901234567890123456789012j45678~0234567890
--------------------------------------------_._ .......' --_.--..; ,: ._ ...._._--' ........ _--_.: .. ..... -_ ..... ..; .\ - ... __ .... _._-,._-
- - T RANS MI S OR ( E n t i d a d , Ar q Ui t e c t u r a y Co n f i g u r a c i n )
- - F i c h e r o t r a n s mi s o r . v h d
- - De s c r i p c i n T r a n s mi s o r s e r i e d e d a t o de l o n g i t u d c o n f i g u r a b l e
Or d e n d e t r a n s mi s i n : MS B a L S B
Bi t d e s t a r t : 1 b i t a c e r o .
Bi t d e s t o p : .1 b i t a u n o .
- - L i mi t a c i o n e s : Ca r g a d i r e c t a me n t e s o b r e e l r e g i s t r o d e d e s p l a z a mi e n t o
E s s n c r o n o c o n e l r e l o j d e l s i s t e ma . La v e l o c i d a d d e
t r a n s mi s i n l a d a CLK 'l'R ( ~~j r ~t a g j . n 9~~)'fLlC.~:
CLK _ 1 1 _ 1 1 _ 1 1 _ 1 1 _ 1 1 _ 1 1 _
~ \ - ~
CLKTR _1
I~
No ea.antet.aahle p o r q u e u s a . p r o c e d i mi e n t o s p a r a agrupar
a c c i o n e s ( p r o c e d i mi e n t o s Ca r g a y E n v i a ) .
___________ ~ ~i __:.....;__-_~:_;_.:-_ ..... ~... ..;;;:..~-_ ... _~, ~ _;;;._;i~-~~::L _:...;-_;;-.:..j __ .... .;..-:..-;.., - ...-
- - Au t o r e s : Y a g o T o r r o j a
J o s e S a n c h e z
- - F e c h a : 18/05/94
---------------------_ .... __ .... _.... _---------------------------,-------:-~--------------
UPM-DI E
- - - - - - - - - - - ~_ ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
u s e I E E E . s t q _ l o g i c _ 1 1 6 ~. a l l
u s e I E E E ; s t CL l o g i c J l s c : a l l
u s e I E E E . s t q _ l o g i c _ a r i t h . a l l ;
e n t i t y T r a n s mi s o r i s
Ge n e r i c ( n i n t e g e r : = 8 ); - - NUme r o d e b i t s
Port( Cl k i n
Cl k T r in
Da t a i n
LoaQ. in
Re s e t n : i n
s t d _ l o g i c - - Re l o j d e l s i s t e ma
std...J .ogic;; .. .~.' .,_".Frecuenci .. -de t r a n s m.
u n s i g n e d ( n - 1 d o wn t o o); '"- Da t o d e e n t r a d a
. s . t q _ ~OQ' ~~ , \ \ } ; ~~ ,qe -!=.rga.,t,cH =+o a 1.I I ,lO )
s t q _ l o g i c - - S e a l d e r e s ~t ( n i ~l l:la ),8 J .
Bu s y : o u t s t d. . . . l o g i c ;
T x : o u t s t d - I o g i c ) ;
e n d T r a n s mi s o r ;
~- S e f l a l d e o c u p d b (a u n o ) : .
-- salida serie .i:
architecture Comportamiento of Tr~smisor is
signal tempor unsignedIN..,l dormtct O)i
signal redDesp unsigned(N 'downt aJ;
signal temporLl~ bc;lqlean;
signal enviando boolean;
-signal contador integer range O to N+2;
begin
-- Buffer temporal
-- Registro de desplazamiento
-- Buffer temporal lleno (a uno)
-- Seal de envj.ando (a l.IlIO)
-- Contador de bits
-- Generacin de la seal de pcupado
busy <= '1' when temporLleno el se 'a';
PRINCIPAL
process(clk, resetn, tempor, regDesp, temporLleno, enviando, "contador)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ~ - - - - - - - - - - - - - - - - - - - - - -
:
-- PROCEDIMIENl'O CARGA:
-- Si se est enviando y llega un nuevo dato" se almacena sobre \ln buffer
-- auxiliar siempre y cuando est vaco.
-- El dato se pierde si no eS almacenado.
-- Este procedimiento acta sobre seales definidas en la arquitectura y que
-- no son enviadas comoparmetros.
procedure Carga is
ifnot temporLleno then
temporLleno <= true;
tempor <= data;
Ifnot enviando then
temporLleno <= false;
enviando <= true;
regDeSp <=< 'o' &data;
end if;
end if;
end Carga;
;.~-;-------------------.- ....,"'!' ... ...;--:--~,_ ....... _---_ .... - ........ -------------------------~~ ... --~ ... -
-- PROCEDIMIENl'O ENVIA:
-- Se encarga de envif'os datos del registro ~ desplazamiento a travs de
';;-lil seal tx. .
-- Se enva un solo bit cad.;vez que'se llama el procedimiento: se desplaza
r: el registro y se Incrarenta el contador de bits.
'..i_ C tnd acaba la transmi~i6n 'COl11Pruebasi hay algn dato pendiente en el
-'- buffer. Si lo hay, pasa auahSliUtir el nuevo dato.
-- Este procedimiento acta sobre seales. definidas en la arquitectura y que
-- no son enviadas como parmet:r;os." ,. .
procedure Envia(signal tx : out std.._ui<Sgic) is
begi n
-- Slo entra cuando est transmitiendo. La seal 'enviando' se activa en
-- el proceso PRINCIPAL(se pone a true)
ifenviando then
ifcontador <= Nthen
-- Transmisin de unbit
tx <= regDesp(N)
-- Desplazamiento
.;egOellP!Ndown.to 'll~:;_ J;egIlesp(N-l downto. O)"
regDesp(a) <= '1';
"-- Incremento del contador
contador <=contador "l;
else
--'Ya ha acabado de transmitir: se indica con enviando =false
enviando <=false;
-- Se borra el contador para la siguiente transmisin
contador <=O; -'A
-- Si hay un dato esperando, se prepara para ser enviado
iftenqx>rLlenothen
tenqx>rLleno<=false;
RegDesp <='o'&tenqx>r ;
enviando <=true:
end if;
end if;
end if;
end Envia;
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... - ... - ... - ' : " : , ...~ : T " ! ' - " ' : ' ... ~ ... ~...-~7-tt:" .. -~~-,~.,..~~-,~-'7','7--:'-,,":";~--.....
-- COI!liEm,Zo, del proces() PRINCIPAL ' '-, ,,", '"'' .', ,""
begin '
-- Inicializacin
if resetn =' O' then
enviando <=false;
tempdrLleno <=false;
tenqx>r <=(others => ' O' ) ;
regDesp <= (others => ' 1' ) ;
-- Funcionamiento sncrono
if load ='1' then
carga;
end if;
--, Slo se transmite un nuevo, bit si clkT-!= .'1'
ifclld'r = '1' then
Envia(1:xl;
end if;
end if;
end process PRINCIPAL;
end Ccmportamiento;
-- COnfigllraci6n
conf.iqurat.ion CFG_TRANSM ISOR_COM PORTAM IENTO of TRANSM ISOR is '
for COM PORTAM IENTO
end for;
end CFG_TRANSM ISOR_COM PORTAM IENTO
Glosario
ALU Arithmetic Logic Unit
Unidad Aritmtico-lgica
Application Specific Integrated Circuit
Circuito integrado deaplicacin especfica
Automatic Test Equipment
Equipo detest automtico
Automatic Test Pattern Generation
Generacin automtica devectores detest
Bipolar CMOS
CMOS Bipolar
Computer Aided Design
Diseo asistido por ordenador
Computer Aided Engineering
Ingeniera asistida por ordenador
Computer Aided Software Engineering
Ingeniera del software asistida por ordenador
CAD Framework Initiative
Iniciativa para laestandarizacin deentornos deCAD
Complementary Metal-Oxide Semiconductor
MOS complementaria
ASIC
ATE
ATPG
BiCMOS
CAD
CAE
CASE
CFI
CMOS
487
488 Glosario
CPLD
CPU
DFf
DRC
ECL
EDA
EMI
ERC
ESDA
FPGA
FPLD
FSM
FSMD
HDL
HLL
HLS
IC
IEEE
LSI
Complex Programmable Logic Device
Dispositivo lgico programable complejo
Central Processing Unit
Unidad central deproceso
Design For Testability
Diseo para latestabilidad
Des ign Rule Check
Verificacin delas reglas dediseo
Emitter Coupled Logic
Lgica acoplada por emisor
Electronic Design Automation
Automatizacin del diseo electrnico
Electromagnetic Interference
Interferencia Electromagntica
Electrical Rule Check
Verificacin dereglas elctricas
Electronic System Design Automation
Automatizacin del diseo desistemas electrnicos
Field-Programmable Gate Array
Matriz depuertas programable
Field-Programmable Logic Device
Dispositivo lgico programable
Finite State Machine
Mquina deestados finita
Finite State Machine with Data
Mquina deestados finita con datos
Hardware Description Language
Lenguaje dedescripcin dehardware
High Level Language
Lenguaje deprogramacin dealto nivel
High Level Synthesis
Sntesis dealto nivel
Integrated Circuit
Circuito integrado
Institute of Electronics and Electrical Engineers
Instituto de ingenieros electrnicos y elctricos
Large Scale Integration
Integracin agran escala
MCM
MOS
NMOS
OMF
PAL
PCB
PLA
PLD
PMOS
PRENDA
RTL
SDF
SOI-MOS
SoC
SoG
VIF
VITAL
VHDL-AMS
VLSI
Glosario 489
MultiChip Module
Mdulo multichip
Metal-Oxide-Semiconductor
Metal-xido-Semiconductor
MOS tipo N
Open Modeling Forum
Promueve lacreacin deun interfaz estndar para la simulacin
dedistintos modelos
Programmable Array Logic
Matriz lgica programable
Printed Circuit Board
Tarjeta decircuito impreso
Programmable Logic Array
Matriz lgica"programable
Programmable Logic Device
Dispositivo lgico programable
MOS tipo P
PRoyecto para laEspecificacin y Normalizacin en el Diseo
deASICs
Register Transfer Level
Nivel detransferencia deregistros
Standard Delay Format
Formato estndar para el retardo
Silicon on Insulator MOS
MOS desilicio sobre aislante
System on Chip
Sistema enuncircuito integrado
Sea ofGates
Mar depuertas
VHDL Intermediate Format
Formato intermedio para el VHDL
VHDL Initiative Toward ASIC Libraries
Iniciativa para lacreacin debibliotecas deceldas VHDL para
el diseo deASICS
VHDL Analog-Mixed Signal
Extensin del VHDL para el caso analgico y mixto
Very Large Scale Integration
Integracin amuy gran escala
,
Indice
Acceso, tipo, 72
Aceleradores hardware, 149
ADA, 13, 180
Agregados, 69
Alias, sentencia, 267, 283
Algoritmo, 146, 254
Analizador de
lxico,153
semntica esttica, 153
sintaxis, 153
Apuntador, 72
rboles sintcticos abstractos (Abstraet
Syntax Trees), 151
Arquitectura, 46, 199
ASIC, 4
celdas estndar precaracterizadas (semi-
eustomlstandard-eells), 5
lgica programable (CPLD, FPGA,
FPLD),5
matrices depuertas predifundidas (semi-
custom/gate-arrays), 5
totalmente amedida (jull-eustom), 5
Assert, sentencia, 98, 105
Atributos, 78
definicin, 81
rango devectores, 78
seales, 80
tipos dedatos, 79
Automatizacin del diseo electrnico
(Eleetronie Design Automation, EDA), 4,
8, 10, 147, 180
Baekannotation (vase Retroanotacin)
Bancos depruebas (Test-beneh), 26, 30, 286,
366,379,402
configurables, 483
Biblioteca de
componentes, 397
diseo, 53, 157,397,399
recursos, 397
Biblioteca, tipos, 397
Block, sentencia, 118, 212, 218
Bloqueo (Deadloek), 141
Buffer tri-estado, 212, 325
Buses, 125
Bsqueda deactividad, 141
CAD (vase Herramientas CAD)
CAD Framework Initiative, CFI, 12
491
492 ndice
Case, sentencia, 91, 215, 268
Causalidad, 143
Ciclo de simulacin, 40, 139-143
Ciclos deacceso amemoria, 272
Circuitos, evolucin, 3, 5, 9
Cliente, 359
Co-diseo dehardware y software (Hw/Sw
Co-Design), 10
Cola deeventos, 40, 140
Comparticin derecursos, 387
Compilador, 148
Complejidad funcional, 398
Componentes (Component), 37, 48,107
declaracin, 107
referencia, 107
Componentes debiblioteca, 378
Comprobacin de
diseo no considerado, 380
estilo decodificacin y nomenclatura,
383
estilo dedescripcin, 383
inicializaciones, 380
listas de sensibilidad, 384
terminaciones, 380
uso depuertos, seales, variables y
genricos, 383
valores constantes en el cdigo, 384
valores no considerados, 380
Concurrencia, 254
Configurabilidad, 398
Configurable, diseo (vase Diseo
configurable)
Configuracin (Configuration), 49, 112
definicin, 114
especificacin, 112
Configuracin, herramientas de, 404, 408
Constantes, 58
Control de
configuraciones, 404
versiones y cambios, 368
versiones y configuraciones, 401
Conversin deformato, 392
Co-rutinas, 167
Co-simulacin, 171
Co-sntesis, 149
Cronogramas, 169
Derechos depropiedad intelectual, 158,410
Descripcin en HDL (vase Modelado)
Depurado (Debugging), 144
Deteccin deerrores, 301,408
Determinismo, 254
Director, 374
Diseador, 359
Diseo. (vase tambin Etapas y Flujos de
diseo)
arquitectural, 2, 375
ascendente (bottom-up), 6, 23, 350
configurable, 431
de alto nivel, 10
descendente (top-down), 11,25,351,354
fsico, 2, 394
genrico, 368, 389,410
lgico, 2, 375, 385
organizacin del, 414, 416
reusable, 405
Diseo arquitectural, 375
documento de, 381
revisin del, 380, 383
Diseo configurable,
desarrollo, 432
legibilidad, 434
mantenimiento, 434
nivel arquitectural, 434
pruebas, 434
seleccin deparmetros, 419
Diseo lgico, 375
documento de, 390
revisin del, 390
Dispositivos programables, 5
Documentacin, 394
diseo, 407
diseo arquitectural, 381
diseo lgico, 390
especificaciones, 362, 369
gua dereferencia, 407
problemas y soluciones, 408
propuesta dedesarrollo, 361
requisitos, 361
EDA (vase Automatizacin del diseo
electrnico)
Ejecucin, 144
monitorizada, 154
Elementos lxicos, 54
Embedded Systems. (vase Sistemas
empotrados)
Emulacin, 148
Ensamblador, 147
Entero, tipo, 63, 200
Entidad, 44, 156
entidad vaca, 265
Entorno del circuito (vase Bancos de
pruebas)
Entorno virtual, 352
Equipo dediseo, 20, 372
ESDA, Electronic System Design
Automation (vase Automatizacin del
diseo electrnico)
Especificaciones, 26, 254, 286 (vase
tambin Etapas dediseo)
abiertas, 413
documento de, 369
en HDL, 26, 367
tecnolgicas, 370
Estado del modelo, 137
Estilo decodificacin y nomenclatura,
Estilo descriptivo, 16,46, 183,253,375
algortmico, 47,
estructural, 48
flujo dedatos, 47
mixto, 49
Estimadores, 408
Estmulos, 287, 289
Etapas de
anlisis deviabilidad, 357
diseo arquitectural, 357
diseo fsico, 357
diseo lgico o detallado, 357
especificaciones, 356
fabricacin y test, 357
requisitos, 356
Evaluacin de alternativas, 374
Event -driven, 139
Exit, sentencia, 96
Expresiones, 76
Fabricacin, fabricante, 378, 392
Fichero, tipo, 73, 402
Fichero, objeto, 60
Ficheros,
decomandos, 402
fuente, 402
objeto, 402
FPGA, FPW (vase Dispositivos
programables)
Fsico, tipo, 63, 200
ndice 493
Flujo decontrol, 137
Flujo dediseo, 21, 354
ascendente (Bottom-up), 5, 23, 354
descendente (Top-down), 10,25,354
Formato intermedio, 153, 180
FSM, FSMD (vase Mquinas deestados
finitos)
Funcionalidad, 251
funcionamiento no considerado, 380
Funciones
deconversin de tipo, 62, 252, 265
deresolucin, 125,256
declaracin, 120
definicin, 120
llamada concurrente, 106
llamada secuencial, 100
Generate, sentencia, 110, 199
Genricos, parmetros, 111, 116
Grado dedetalle, 16, 251
temporizacin, 16, 182
tipos dedatos, 17
Gramtica
con atributos, 152
independiente del contexto, 150
Gua dereferencia, 407
HDL (vase Lenguajes dedescripcin de
hardware)
descripcin mixta-multinivel, 11, 17,25
independencia deCAD, metodologa y
tecnologa, 14, 19,27
niveles de abstraccin, 16, 182
reusabilidad, 19, 405
Herramientas CAD, 3-12, 180
nivel depuertas, 6, 23, 28
nivel fsico, 3, 7
simulacin mixta-multinivel, 11, 17,25,30
simulador SPICE, 3, 180
sntesis, 10, 14, 17, 22, 26, 180
Heterarqua deprocesos, 156,159
Hoja decatlogo (data-sheet), 408
Identificadores, 54
If, sentencia, 89,216
Indeterminismo, 165,254
Ingeniera concurrente, 10
494 ndice
Inicializacin, 143,205,380
Instrucciones
aritmtico-lgicas, 261
deacceso amemoria, 260
de salto, 261
Intelectual Property Rights, IPRs (vase
Derechos depropiedad intelectual)
Interaccin deprocesos, 142
Interfaz, 253, 270
Interoperabilidad, 407
Intrprete, 147
J erarqua, 22
debloques, 159,270
deentidades dediseo, 159
Kernel,134
Latch,217
Layout (vase Topografa deun circuito)
Lazos, 216
Lenguajes dedescripcin de hardware,
HDL, 10,12-21,26-31,136, 180, 192
Lenguajes deProgramacin de alto nivel
(High Level Languajes, HLL), 13, 146,
147
Listas
decomponentes, 403
de sensibilidad, 112
Literales, 56
Lgica
asncrona, 218
combinacional, 210
sncrona, 218
Loop, sentencia, 94, 255, 279
Macroceldas, 352, 378
Mantenimiento, 414
Mquinas deestados finitos, 226
con datos (FSMD), 235
estilos explcitos, 226
estilos implcitos, 233
Mealy, 226, 231
Moore, 229, 233
Mscaras (vase Topografa deun circuito)
Matriz, tipo, 68
Memoria,
ROM,301
RAM,340
Metodologa dediseo, 21, 353 (vase
tambin Flujo dediseo)
Microoperaciones, 328, 334
Microinstrucciones, 328, 334
Microprogramas, 328, 334
Microsistemas, 9
Modelado, 144
arquitectural-RT, 27, 182
detallado, 28, 290, 303
funcional-comportamental,26, 182,
254
Hw versus Sw, 13
multiplexores, 211
sntesis versus simulacin, 13, 17, 30,
295,37
Temporal, 295
Realista, 296
Modelo
deinsercin preemptiva, 140
de simulacin, 398, 409
matemtico, 138
para fabricacin, 409
Modelos-HDL (vase Modelado)
Modulos Multichip (Multichip Modules,
MCM),9
Multiplexor, 297, 325
Next, sentencia, 97
Niveles deabstraccin; 2,15-18
arquitectural-RT, 182,253
fsico, 2, 16
funcional-comportamental, 182
lgico-puertas, 182
Normas decodificacin y modelado, 374
Notas deaplicacin, 408
Null, sentencia, 100
Nmero
deedicin, 403
de versin, 403
Objetos, 58
Open Modeling Forum, OMF, 21
Operadores, 76, 201, 207
Optimizacin de cdigo, 386
Ordenadores mixtos, 139
Palabras reservadas, 55
Paquete (Package)
cuerpo, 50
declaracin, 50
Paralelismo, 252
Parametrizacin, mtodo de, 435
Particionado, 370, 422
Plan
dedesarrollo, 370
depruebas, 370
Planificacin deeventos, 141
Plataformas hardware, 4,8, 12
Portabilidad, 167, 406
Prestaciones, 390
Problemas y soluciones, 408
Procedimientos (Procedure), 122
declaracin, 122
definicin, 122
llamada concurrente, 106, 199
Procesador
4004,8086,4
mquina rudimentaria, MR, 260
Procesador hardware, 147
Procesador MR, 260
rbitro debus, 271
arquitectura, 261
banco deregistros, 318,
ciclo deacceso amemoria, 272, 280
conjunto deinstrucciones, 260
diagrama deestados, 328, 333
estructura, 276
formato deinstruccin, 336
indicadores, 306
instrucciones, 323
seales decontrol, 330
unidad aritmtico lgica (VAL), 308
unidad decontrol, 274, 326
cableada, 328, 330
microprogramada, 328, 334
microprograma 336
unidad deproceso, 274, 304, 320
Procesador software, 147
Proceso, 38, 213
Procesos postpuestos, 164
Process, sentencia, 102
Real, tipo, 63, 200
Refinamiento progresivo, 16,27,294
ndice 495
Registro (Record), tipo, 71, 200, 423
Registros, 219
dedesplazamiento, 223
Report, sentencia, 98, 105
Requisitos
documento de, 361
etapa de, 356, 359
Restador, 308
Restricciones, 385
sintcticas, 150
Retardo, 216
cero, 143
delta (?-delay), 41, 165
inercial, 85
transporte, 85
unidad, 142
Retardo depin apin, 296
Retemporizacin, 237
Retroanotacin, 6, 24, 29, 182
Retum, sentencia, 100, 120, 122
Reusabilidad, 19, 158,405
Revisin del diseo, 381, 390
Segmentacin, 236, 389
Semforo, 255
Semntica, 150
denotacional, 153
operacional, 153
Sentencias
concurrentes, 101, 210
estructurales, 107
secuenciales, 82, 215
Seales, 39
asignacin concurrente, 103,210
asignacin concurrente con seleccin,
104,211
asignacin concurrente condicional, 103,
211
asignacin secuencial, 84, 215
decontrol, 198,231
reloj, 218
resueltas, 125
Smbolos, 56
Simulacin,
defallos, 174
design-off, 174
lgica, 173
peor y mejor caso, 390
por ordenador, 137
temporal, 174
496 ndice
Smulacin
comparativa, 395
realista, 298
Simulador lgico, 287
Sintaxis, 150
Sntesis, 22, 28
comportamental, 184
fsica, 181
lgica, 181, 196
mapeo tecnolgico, 181
transferencia de registros (RT), 181,
196
Sistemas embebidos o empotrados
(Embedded Systems), 149
Sistemas en chip (Systems on chip,
SOCoSystems on silicon, SOS), 9, 23,
410
Situaciones prohibidas, 303
Sobrecarga
operadores, 76, 125,201
subprogramas, 124
Sobre-especificacin, 367
Standard Delay Format, SDF, 30
Subprogramas, 119
llamada concurrente, 106
Subtipos dedatos, declaracin, 66
Sumador, 18
completo, 311
con acarreo anticipado, 313
con acarreo depropagacin , 311
Tareas
asignacin, 374
coordinacin, 374
Tecnologas, 3,9,378,385
Temporizacin,
funcional,182
lgica, 182
RT,182
Terminacin, 144
Test, 24, 30, 144
cobertura defaltas, 24
defabricacin, 390, 409
diseo para testabilidad (Design for
testability, DFT), 24
mquina de, 289
testabilidad, 24
vectores detest, 289
Tiempo,
de simulacin, 252
depropagacin, 297, 298, 299
Time-driven, 139
Tipos dedatos, 61,251
abstractos, 183
bit, 65,183
compuestos, 67
declaracin, 62
enumerado, 65, 200, 276
escalares, 63, 200
estructurados, 427
resueltos, 126,256
Topografa deun circuito, 3, 6, 24, 403
Traductor, 146
Ubicacin y conexionado, 6, 24, 27
UDL/I, 13,19
Unidad
decontrol, 197
dedatos, 197
dediseo, 155
Unit De/ay, 142
Validacin, 138,392,408
Valor
actual, 161
conducido, 161
efectivo, 161
Variables, 59
asignacin, 59, 88
globales, 254
Vector, tipo, 68
Vectores
desimulacin, 403
detest, 289
Verificacin, 286
automtica, 290
temporal, 303, 344
Verilog, 10, 13, 15, 18
VHDL, 9,13-21
VHDL-AMS,l1
VIF, 155
VITAL, 21, 30,188
Wait, sentencia, 82, 214, 219, 279
Zero Delay, 143

VHDL Lenguaje Estándar de Diseño Electrónico

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VHDL Lenguaje Estándar de Diseño Electrónico

Uploaded by

Copyright:

Available Formats

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

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

FIGURA 6-1. Flujodediseodeuncircuito integrado,

"<, Types.vhd I Nombre:VmeFuncs.vhd

You might also like