Metodología de síntesis ESL basada en TLM. Aplicación al diseño de un decodificador de vídeo

ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA PROYECTO FIN DE CARRERA METODOLOGÍA DE SÍNTESIS ESL BASADA EN TLM. APLICACIÓN AL DISEÑO DE UN DECODIFICADOR DE VÍDEO Titulación: Ingeniero de Telecomunicación Autor: Paloma Monzón Rodríguez Tutores: D. Pedro Pérez Carballo D. Pedro Hernández Fernández Fecha: Marzo 2015 ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA PROYECTO FIN DE CARRERA METODOLOGÍA DE SÍNTESIS ESL BASADA EN TLM. APLICACIÓN AL DISEÑO DE UN DECODIFICADOR DE VÍDEO HOJA DE FIRMAS Alumno/a Fdo.: Paloma Monzón Rodríguez Tutor/a Tutor/a Fdo.: Pedro Pérez Carballo Fdo.: Pedro Hernández Fernández Titulación: Ingeniero de Telecomunicación Fecha: Marzo 2015 ESCUELA DE INGENIERÍA DE TELECOMUNICACIÓN Y ELECTRÓNICA PROYECTO FIN DE CARRERA METODOLOGÍA DE SÍNTESIS ESL BASADA EN TLM. APLICACIÓN AL DISEÑO DE UN DECODIFICADOR DE VÍDEO HOJA DE EVALUACIÓN Calificación: ___________________________ Presidente Fdo.: Vocal Secretario/a Fdo.: Fdo.: Titulación: Ingeniero de Telecomunicación Fecha: ………………………………………......... Agradecimientos La realización y presentación de este proyecto supone el fin de una etapa que comenzó con la entrada en la Universidad y en la que, desde entonces, ha habido de todo: palabras de ánimo, consejos, risas, lágrimas, oportunidades, aprendizaje, amistad... Un largo sin fin que me ha ayudado a crecer y estar hoy aquí. Una etapa por la que han pasado muchas personas. Simplemente, a todos, gracias , Índice general Índice de figuras V Índice de tablas IX Acrónimos XI Resumen XV Abstract XVII 1. Introducción 1 1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1. Modelado a nivel de transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2. Estándar H.264/AVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.Objetivos............................................ 7 1.3. Peticionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Dominio de la aplicación 9 2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Características generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Decodificador de vídeo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1. Decodificación del bitstream ............................. 12 2.3.2. Transformación y cuantización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3. Predicción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.4. Filtrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Aplicación de referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Bloque inter_p ..................................... 15 I ÍNDICE DE FIGURAS 6.5. Síntesis lógica. Comparativa registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.6. Síntesis lógica. Comparativa BRAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.7. Síntesis lógica. Comparativa LUTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6.8. Síntesis lógica. Comparativa DSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 6.9. Síntesis lógica. Comparativa frecuencia de funcionamiento (MHz) . . . . . . . . . . . . . 135 6.10.Síntesis física. Comparativa registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.11.Síntesis física. Comparativa BRAMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.12.Síntesis física. Comparativa LUTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.13.Síntesis física. Comparativa DSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.14.Síntesis física. Comparativa frecuencia de funcionamiento (MHz) . . . . . . . . . . . . . 137 6.15.Síntesis física. Comparativa potencia (mW) . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.1. Líneas de código . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 VIII Índice de tablas 2.1. Comparación entre los diferentes estándares de codificación de vídeo . . . . . . . . . . 16 3.1. Interfaces blocking ynon-blocking .............................. 35 3.2. Interfaces TLM [3], [38] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Descripción de los puertos E/S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.2. Descripción de las funciones del bloque inter_p ....................... 62 4.3. Descripción de las funciones del testbench ......................... 67 4.4. Descripción de los puertos E/S del wrapper ......................... 72 4.5. Descripción de las funciones del wrapper del bloque inter_p ................ 75 4.6. Descripción de las funciones del wrapper del testbench .................. 78 4.7. Características de las librerías UMC de 65 nm . . . . . . . . . . . . . . . . . . . . . . . 89 4.8. Dispositivos FPGA utilizados en este proyecto y sus recursos disponibles . . . . . . . . . 89 4.9. ASIC. Resultados obtenidos en la síntesis lógica. Diseño con wrapper . . . . . . . . . . 105 4.10.Potencia dinámica y de pérdidas. Diseño con wrapper ...................105 4.11.FPGA. Resultados obtenidos en la síntesis lógica. Diseño con wrapper . . . . . . . . . . 107 4.12.FPGA. Resultados obtenidos en la síntesis física. Diseño con wrapper . . . . . . . . . . 111 5.1. ASIC. Resultados obtenidos en la síntesis lógica. Diseño TLM . . . . . . . . . . . . . . . 126 5.2. Potencia dinámica y de pérdidas. Diseño TLM . . . . . . . . . . . . . . . . . . . . . . . 126 5.3. FPGA. Resultados obtenidos en la síntesis lógica. Diseño TLM . . . . . . . . . . . . . . 127 5.4. FPGA. Resultados obtenidos en la síntesis física. Diseño TLM . . . . . . . . . . . . . . . 127 6.1. ASIC. Resultados obtenidos en la síntesis lógica. Diseño original . . . . . . . . . . . . . 129 6.2. Potencia dinámica y de pérdidas. Diseño original . . . . . . . . . . . . . . . . . . . . . . 130 6.3. FPGA. Resultados obtenidos en la síntesis lógica. Diseño original . . . . . . . . . . . . . 131 6.4. FPGA. Resultados obtenidos en la síntesis física. Diseño original . . . . . . . . . . . . . 131 6.5. Virtex5. Frecuencia límite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 IX ÍNDICE DE TABLAS 6.6. Zynq. Frecuencia límite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 X Acrónimos ACK Acknowledgement AMD Advanced Micro Devices ASIC Application-Specific Integrated Circuit ASIP Application-Specific Instruction-Set Processor AVC Advanced Video Coding BCA Bus Cycle Accurate BRAM Block RAM CABAC Context-Adaptive Binary Arithmetic Coding CAD Computer-Aided Design CAVLC Contex-Adaptive Variable Length Coding CAVLD Contex-Adaptive Variable Length Decoder CD Compact Disc CDFG Control and Data Flow Graph CLB Configurable Logic Block CMOS Complementary Metal-Oxide Semiconductor CtoS C-to-Silicon Compiler DCT Discrete Cosine Transform DPB Decoded Picture Buffer DSP Digital Signal Processor EDIF Electronic Design Interchange Format E/S Entrada/Salida ESL Electronic System Level FEC Forward Error Correction FIFO First-In First-Out buffer FPGA Field Programmable Gate Array FSM Finite State Machine XI ACRÓNIMOS GB Gigabyte GIMP GNU Image Manipulation Program GUI Graphical User Interface HDL Hardware Description Language HLS High-Level Synthesis HP Hewlett-Packard HW Hardware I/O In/Out IC Integrated Circuit IEEE Institute of Electrical and Electronics Engineers IGIC Impuesto General Indirecto Canario IP Intellectual Property ISE Integrated Software Environment IUMA Instituto Universitario de Microelectrónica Aplicada LUT Look-Up Table MB Macrobloque MPEG Moving Picture Experts Group NAL Network Abstraction Layer OSCI Open SystemC Initiative PA Pin Accurate PB Picture Buffer PSNR Peak Signal to Noise Ratio QoR Quality of Results RAM Random-Access Memory REQ Request RTL Register Transfer Level S/N Signal to Noise Ratio SICAD Sistemas Industriales y CAD SLD System Level Design SoC System on Chip SW Software TCL Tool Command Language TIC Tecnologías de la Información y las Comunicaciones TLM Transaction-Level Modeling XII ACRÓNIMOS TPB Temporal Picture Buffer UCF User Constraint File UMC United Microelectronics Corporation UUT Unit Under Test VCEG Video Coding Experts Group VCL Video Coding Layer VHDL Very High Speed Integrated Circuit Hardware Description Language VLC Variable Length Coding VLSI Very Large Scale Integration XPE Xilinx Power Estimator XPA XPower Analyzer XIII Resumen RTL es el nivel de abstracción de uso común para el diseño de circuitos integrados, cuya metodología de síntesis y verificación mediante el uso de lenguajes de descripción hardware permite reducir los tiempos e incrementar la calidad de los diseños obtenidos. La complejidad en los sistemas electrónicos actuales va en aumento, se requieren sistemas en chip (SoCs) funcionales, económicos, con un bajo consumo de potencia y con un alto nivel de integración que incorporen toda la funcionalidad. Ello dificulta la verificación funcional o la toma de decisiones en fases tempranas del flujo de diseño. Ante este panorama es necesario incrementar el nivel de abstracción para la especificación y verificación del diseño y desarrollar nuevas metodologías. El modelado a nivel de transacciones (TLM) implica un cambio del nivel de abstracción, donde se separan los aspectos de computación y los de comunicación de un sistema, facilitando el análisis de la arquitectura, reduciendo los esfuerzos en el modelado y aumentando la productividad del diseñador. El objetivo principal de este proyecto es el desarrollo de una metodología de síntesis basada en el modelado a nivel de transacciones, aplicándola sobre el diseño de uno de los bloques del decodificador de vídeo H.264/AVC perteneciente al Instituto Universitario de Microelectrónica Aplicada (IUMA). Para ello se sigue un flujo de diseño centrado en la síntesis de alto nivel con el fin de obtener modelos sintetizables para una futura implementación hardware tanto en ASIC como en FPGA, siendo el primer paso modelar el bloque con TLM. En definitiva, se pretende conocer en detalle TLM y más concretamente su aplicación en la síntesis de alto nivel, de manera que permita evaluar las cualidades de esta nueva metodología. Este proyecto se desarrolla en el marco de las líneas de trabajo de la División de Sistemas Industriales y CAD (SICAD) del IUMA. XV Abstract RTL is the commonly used level of abstraction for integrated circuits design, its synthesis and verification through hardware description languages allow reducing design time and increasing the quality of design. The complexity of current electronic systems is increasing, functional, economic, low power consumption and high level of integration systems on chip (SoCs) that incorporate full functionality are required. This complicates the functional verification or decision making in the early stages of the design flow. In this scenario it is necessary to raise the level of abstraction for design specification and verification and develop new design methodologies. Transaction level modeling (TLM) implies a change in the level of abstraction, where computing and communication aspects of the system are separated, facilitating the analysis of architecture, reducing modeling efforts and increasing productivity of the designer. The main aim of this project is the development of a synthesis methodology based on transaction level modeling, applied on the design of one of the blocks of H.264/AVC video decoder belonging to the Institute for Applied Microelectronics (IUMA). To achieve this, a design flow centered on high-level synthesis is used in order to obtain synthesizable models for future hardware implementation in both ASIC and FPGA, where the first step is modeling the block with TLM. In other words, TLM is studied in detail and more specifically its application in high-level synthesis, so as to assess the qualities of this new methodology. This project is developed in the context of the research lines of the Division of Industrial and Systems CAD (SICAD) of IUMA. XVII CAPÍTULO 1. INTRODUCCIÓN 1.1. ANTECEDENTES que permite la separación entre la funcionalidad y la comunicación. A partir del modelado a nivel de transacciones se plantea la realización de la síntesis de un decodificador de vídeo H.264/AVC. De esta manera se validará la metodología desarrollada y se plantearán las ventajas e inconvenientes de la misma. 1.1.2. Estándar H.264/AVC La historia sobre la codificación de vídeo se remonta a mediados de la década de los 80, con la creación del estándar H.120, precursor del H.261. Sobre este están basados todos los estándares siguientes: MPEG-1 Parte 2, H.262/MPEG-2 Parte 2, H.263, MPEG-4 Parte 2 y H.264/AVC [17]. El estándar H.264 Advanced Video Coding, o MPEG-4 parte 10, define un códec de vídeo de alta compresión [18]. Fue publicado en 2003, y es capaz de proporcionar una buena calidad de imagen con tasas binarias inferiores a los estándares previos. Está compuesto por: Un codificador, el cual se encarga, a partir de una secuencia de vídeo, de predecir, transformar y codificar, y así obtener una salida apta para ser enviada por un canal o ser almacenada en un fichero. Un decodificador, que hace la operación inversa: decodifica, realiza la transformada que corresponda y reconstruye la secuencia original de vídeo. Aunque este códec implica ahorros sustanciales en las tasas binarias y mejoras en la calidad de imagen, la complejidad de diseño supera significativamente a la de los estándares anteriores [19], [20]. La Figura 1.5 muestra como para un mismo bitrate se obtiene una mejor calidad y resolución con H.264 que con uno de sus predecesores, MPEG-2. En este proyecto se hará uso de un decodificador de vídeo H.264/AVC para demostrar el uso de la metodología explicada en el apartado anterior. Para ello se utilizará el bloque de predicción temporal (inter_p), al que se dotará de interfaces TLM con objeto de comprobar su viabilidad y comparar la calidad de los resultados obtenidos después de la síntesis. 6 CAPÍTULO 1. INTRODUCCIÓN 1.2. OBJETIVOS Figura 1.5: Calidad y resolución entre MPEG-2 y H.264 (adaptado de [21]) 1.2. Objetivos El objetivo principal de este proyecto es la definición de una metodología de diseño de sistemas electrónicos integrados a partir del modelado a nivel de transacciones (TLM), con énfasis en la creación de modelos sintetizables. La metodología se validará aplicándola al diseño del bloque inter_p de un decodificador de vídeo. Se partirá del código en SystemC del sistema, tratando los módulos del mismo como “cajas grises” (grey-box model), centrándose en las interfaces, y donde la funcionalidad está completamente definida. En concreto se abordarán los siguientes puntos: 1. Definición de la metodología de modelado, verificación y síntesis TLM. 2. Aplicación a diseños simples. 3. Estudio del software de referencia del decodificador H.264/AVC. 4. Descripción incremental a nivel TLM. 5. Síntesis de alto nivel del modelo. 6. Validación de la metodología. 7 CAPÍTULO 1. INTRODUCCIÓN 1.3. PETICIONARIO 1.3. Peticionario Actúa como peticionario de este Proyecto Fin de Carrera la División de Sistemas Industriales y CAD (SICAD) del Instituto Universitario de Microelectrónica Aplicada de la Universidad de Las Palmas de Gran Canaria, en el marco de las líneas de investigación promovidas por la citada división. Por otro lado, la realización de este Proyecto Fin de Carrera es requisito indispensable para la obtención del título de Ingeniero de Telecomunicación por la Escuela de Ingeniería de Telecomunicación y Electrónica de la Universidad de Las Palmas de Gran Canaria. 1.4. Estructura del documento El presente documento, a través de siete capítulos, describe el trabajo realizado. Se estructura de la siguiente manera: Capítulo 1: Introducción. Se muestra el marco en el que se recoge este Proyecto Fin de Carrera, para el cual se detallan los antecedentes, objetivos, peticionario y estructura del documento. Capítulo 2: Dominio de la aplicación. Se realiza una descripción del decodificador H.264/AVC, así como de la situación de partida. Capítulo 3: Metodología de diseño. Se introducen los elementos que forman parte del desarrollo del proyecto, como son las herramientas software utilizadas o el flujo de diseño seguido; y se expone el modelado a nivel de transacciones. Capítulo 4: Modelado TLM con wrapper.Se describe el modelado con wrapper, detallando las características del modelo. Capítulo 5: Modelado TLM de las interfaces. Se modela a nivel de transacciones el módulo en estudio. Capítulo 6: Comparativa de los resultados. Análisis de los resultados obtenidos mediante una comparativa de los mismos. Capítulo 7: Conclusiones y líneas futuras. Se presentan las conclusiones generales del proyecto y algunas líneas de trabajo que pueden derivarse de su realización. 8 Capítulo 2 Dominio de la aplicación 2.1. Introducción El objetivo principal de este Proyecto Fin de Carrera es estudiar la metodología de síntesis basada en TLM, aplicándola sobre el diseño de un decodificador de vídeo H.264/AVC, por lo que en los siguientes apartados se presentarán las características principales de dicho decodificador, prestando especial atención a los bloques que lo componen. Tras tener una visión global del estándar se realizará una descripción detallada de la aplicación de referencia que se va a utilizar. 2.2. Características generales Ya sea la transmisión de vídeo en tiempo real, streaming, o su almacenamiento multimedia, cualquiera que sea la forma, genera la necesidad de ofrecer unas mayores tasas de compresión. Este es el principal motivo por el que nace el estándar H.264/AVC. Este estándar define un formato y un método de compresión de vídeo, desarrollado conjuntamente por el Video Coding Experts Group (VCEG) y el Moving Picture Experts Group (MPEG) y con el que se trata de proporcionar una buena calidad de imagen reduciendo la tasa binaria respecto a los estándares anteriores [19], [20]. Una secuencia de vídeo se segmenta en fotogramas o frames, que se dividen en slices y, a su vez, estos son un conjunto de macrobloques, los cuales contienen los datos de luminancia y crominancia (muestras) [20]. 9 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.2. CARACTERÍSTICAS GENERALES Figura 2.1: Estructura de la secuencia de vídeo H.264, tanto el codificador como el decodificador, está compuesto por diferentes bloques funcionales como sus antecesores, y adopta un algoritmo híbrido de predicción y transformación para la reducción de la correlación espacial y de la señal residual, control de la velocidad binaria o bitrate, predicción por compensación del movimiento para reducir la redundancia temporal, así como codificación de la entropía para reducir la correlación estadística. Sin embargo, los cambios importantes están descritos en los detalles de cada bloque funcional, de manera que lo que proporciona una mayor eficiencia de codificación es cómo opera cada uno de ellos [18]. Algunas de las características más destacadas son las siguientes: Incluye predicción intra fotograma. Transformación por bloques de 4x4 muestras, siendo los coeficientes transformados enteros. Referencia múltiple para predicción temporal. Tamaño variable de los macrobloques a comprimir. Precisión de un cuarto de píxel para la compensación de movimiento. A nivel de decodificación utiliza métodos para incrementar la resistencia a errores, como puede ser el ordenamiento flexible de macrobloques, transmisión de slices redundantes de fotograma o particionado de datos [22], [23]. 10 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.2. CARACTERÍSTICAS GENERALES Figura 2.2: Esquema general del estándar H.264/AVC (adaptado de [19]) Las funciones y especificaciones necesarias del codificador y del decodificador se recogen en cada uno de los perfiles que define el estándar (Baseline,Main,Extended). Mientras que las limitaciones de los parámetros (velocidad, tamaño, memoria requerida, etc.) se indican a través de un conjunto de niveles [18]. En cuanto a la estructura, H.264 se compone de dos capas: la capa de abstracción de red (NAL) y la capa de codificación de vídeo (VCL). La primera abstrae los datos para hacer compatible la información de salida del codificador (bitstream) con los canales de comunicación o medios de almacenamiento; y la segunda es el núcleo de los datos codificados, la secuencia de vídeo a codificar [24]. En conclusión, H.264/AVC es un estándar nacido a partir de sus predecesores, pero con importantes mejoras respecto a ellos, como son: Mejor codificación de la entropía. Mejor compensación y predicción del movimiento. Bloques pequeños para la codificación. 11 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.3. DECODIFICADOR DE VÍDEO Mejor filtro deblocking. Bitrate inferior respecto a los estándares anteriores. Mejor calidad de imagen manteniendo la misma relación S/N. De esta manera se consigue una mayor eficiencia en la compresión, mejor calidad de vídeo, pudiendo ser esta de alta resolución; y flexibilidad en la compresión, transmisión y almacenamiento de vídeo [19]. Todo esto a cambio de un aumento de la complejidad de la arquitectura hardware del sistema. 2.3. Decodificador de vídeo El perfil básico del estándar H.264 es el Baseline. En este, los coeficientes cuantizados (bitstream) se decodifican utilizando un decodificador cuyo código es de longitud variable. Posteriormente, el error residual se descomprime con una transformada y se elimina con la cuantización, para luego realizar la predicción y finalmente el filtrado, reduciendo así las distorsiones introducidas durante los procesos anteriores. En la Figura 2.3 se puede observar el esquema general del decodificador de vídeo. Figura 2.3: Esquema del decodificador H.264/AVC (adaptado de [21]) 2.3.1. Decodificación del bitstream En los estándares anteriores la codificación de la entropía se basa en tablas previamente definidas y que contienen los códigos que se van a utilizar, siendo estos de longitud variable. El conjunto de 12 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.3. DECODIFICADOR DE VÍDEO códigos incluidos en dichas tablas se fundamenta en distribuciones de probabilidad de datos obtenidos en secuencias de vídeo genérico, en lugar de usar la codificación Huffman o aritmética exacta [25]. Sin embargo, H.264/AVC hace uso de diferentes códigos de longitud variable con la finalidad de igualar el símbolo que representa un dato de vídeo con un código basado en las características del contexto en el que se encuentra el mismo. Se realiza una búsqueda en zigzag o una búsqueda alternada (campos de fotograma de vídeo no entrelazados) con el objetivo de leer los datos residuales (coeficientes transformados y cuantizados). Para la decodificación de estos, utiliza un método más avanzado, usando un código adaptativo de longitud variable basado en el contexto (CAVLC) [20]. 2.3.2. Transformación y cuantización En H.264 los procesos de transformación y cuantización están diseñados para minimizar la complejidad de la implementación y que esta pueda realizarse de manera más simple, y por consiguiente, evitar la redundacia espacial. Esto se logra utilizando varias técnicas: Reduciendo el tamaño de los pasos de los cuantizadores para así aumentar la relación pico de señal a ruido (PSNR) a niveles que se consideren sin pérdidas desde un punto de vista visual. El rango de los pasos de cuantización se eleva en dos octavas, implicando una redefinición de las tablas de cuantización. Usando una transformada entera de 4x4 o de 8x8, que integra el proceso de transformación, cuantización y escalado. Este proceso se denomina transformación entera con post-escalado y disminuye el número de multiplicaciones. En algunos casos, además, emplea una estructura de transformación jerárquica, es decir, a los coeficientes obtenidos anteriormente se les aplica la DCT y a la salida de esta la transformada de Hadamard [19], [20], [26]. 2.3.3. Predicción Un codificador H.264/AVC hace un uso eficiente de la redundancia temporal y espacial de la información visual que se va codificando, así disminuye la cantidad de información que se necesita para la reproducción del vídeo. En el sentido temporal, procesa cada slice para buscar y comparar las texturas de los macrobloques anteriores y siguientes, una técnica que es conocida como estimación de movimiento. Por cada coincidencia que detecta, en el decodificador solo se necesita un vector que apunte 13 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.3. DECODIFICADOR DE VÍDEO a ella (textura de referencia) y la información requerida para hacer la corrección de cualquier posible diferencia o error. Cuando la estimación de movimiento no proporcione coincidencias suficientes, se pasa a trabajar en el sentido espacial, donde el codificador utiliza la textura de los macrobloques próximos dentro del mismo slice para hacer la predicción, almacenando solamente la diferencia entre esta y la textura real [27]. Las imágenes que previamente han sido decodificadas son almacenadas en un buffer llamado Decode Picture Buffer (DPB), donde se crea la lista con las imágenes de referencia. Una predicción del macrobloque actual es un modelo que se asemeja al mismo tanto como sea posible y se crea a partir de muestras de una imagen que ya ha sido codificada. Esta predicción es restada al macrobloque actual y el resultado de dicha resta, llamado residuo, se comprime y se transmite al decodificador. Existe dos tipos de predicción: intra, las muestras de un macrobloque se han predicho con muestras pertenecientes al slice actual que ya hayan sido codificadas, decodificadas y reconstruidas; e inter donde las muestras en un macrobloque se han predicho de muestras previamente codificadas [19], [20]. 2.3.4. Filtrado El proceso de decodificación involucra macrobloques con distintas características, algunos con mayor correlación que otros. Para mantener cierta tasa binaria, los bloques intra einter se han cuantizado utilizando diferentes cuantizadores, los cuales introducen una distorsión alrededor de los bloques construidos [28]. La imagen filtrada se usa para compensar el movimiento, por lo que se requiere que sea todo lo posible una reproducción fiel a la original. El filtro de desbloqueo reduce la distorsión en los bordes del bloque y evita que el ruido acumulado debido a la codificación se propague. En H.264 el filtrado se aplica adaptativamente en varios niveles [18]: A nivel de slice. El filtrado se puede ajustar a las características individuales de la secuencia de vídeo. A nivel de borde del bloque. El filtrado se vuelve independiente de la decisión intra/inter de las diferencias de movimiento y de la presencia de residuos codificados en los dos bloques participantes. 14 CAPÍTULO 2. DOMINIO DE LA APLICACIÓN 2.4. COMPARATIVA A nivel de muestra. El efecto del filtrado se puede anular dependiendo de los valores de las muestras y de los umbrales del cuantizador. 2.4. Comparativa La tabla 2.1 muestra un análisis comparativo entre los estándares de codificación de vídeo [28]. 2.5. Aplicación de referencia Como se indicó en el Capítulo 1 el objetivo principal de este proyecto es la definición de una metodología de síntesis de sistemas electrónicos integrados a partir del modelado a nivel de transacciones. Para ello se hará uso del decodificador de vídeo H.264/AVC. Se parte de un diseño en alto nivel descrito en SystemC desarrollado a partir del código de referencia del decodificador H.264/AVC por el Instituto Universitario de Microelectrónica Aplicada [29], [30]. En la Figura 2.4 se tiene un esquema de los módulos que lo componen. En este Proyecto Fin de Carrera se va a utilizar únicamente el bloque inter_p. Figura 2.4: Decodificador de vídeo H.264/AVC perteneciente al IUMA (adaptado de [29]) 2.5.1. Bloque inter_p El bloque inter_p pertenece al flujo de procesado de la predicción inter: crea macrobloques de predicción a partir de los vectores de movimiento y del fotograma de referencia. 15 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.2. FLUJO DE DISEÑO 3.2. Flujo de diseño Cabe destacar tres etapas importantes en la metodología o flujo de cualquier diseño, sea software ohardware: caracterización, diseño y verificación. Se trata de un proceso iterativo en el que se va refinando el sistema hasta obtener la versión a implementar. Figura 3.1: Flujo de diseño básico Antes de comenzar a abordar el diseño de un sistema es necesario poder describirlo de forma que permita establecer su funcionalidad y prestaciones requeridas. Con ello el diseñador puede tomar decisiones como la tecnología a utilizar, lenguajes, herramientas, colocación de los bloques, etc. y así obtener una primera versión funcional. Mediante simulación, se verifica que cumple con las especificaciones definidas, para que en caso de no ser así, aplicar las medidas correctoras necesarias y repetir el ciclo de diseño. El flujo de diseño tradicional de un ASIC es el que se muestra en la Figura 3.2. En cambio, el flujo de diseño basado en FPGA es más simple, ya que la fase de implementación se reduce a la programación del dispositivo, que cuenta con una arquitectura y recursos predefinidos. Las descripcio22 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.2. FLUJO DE DISEÑO nes a nivel de sistema son comunes en ambos flujos, mientras que las fases de síntesis RTL y lógica estarán optimizadas para la tecnología destino, pues son las que traducen la descripción en un nivel de abstracción superior a una descripción estructural con componentes del nivel de abstracción inferior. Figura 3.2: Flujo de diseño de un ASIC (adaptado de [31]) La descripción RTL es consecuencia de la planificación temporal y esta se obtendrá en función de los requerimientos de tiempo de ciclo, área y potencia. 23 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC 3.3. Lenguaje: SystemC Para realizar el modelado a nivel de transacciones se ha usado SystemC, lenguaje que permite la descripción de sistemas electrónicos a nivel de sistemas (ESL) [12], adecuar los niveles de abstracción y proveer los elementos que permiten llevar a cabo la separación entre la funcionalidad y la comunicación. SystemC es un lenguaje de diseño y verificación de sistemas electrónicos de alto nivel, estandarizado por el IEEE (IEEE 1666-2011) [3] para modelar sistemas. Está implementado como un conjunto de clases de C++ que soporta concurrencia, noción del tiempo y tipos de datos específicos para hardware.Está consolidado y es ampliamente usado. Su popularidad se atribuye a las siguientes características [32]: La tendencia de la industria se inclina hacia la reusabilidad de IPs frente al desarrollo interno. Consolidación de los flujos de diseño a nivel de sistemas ya existentes. Integración con los diferentes niveles de abstracción. Librería de código abierto (open-source). Además, soporta la simulación basada en eventos, la cual presenta unos tiempos de simulación más bajos; y el trazado de formas de onda. Con SystemC la funcionalidad puede ser separada de la comunicación. La primera es descrita usando módulos y procesos, mientras que la segunda mediante canales e interfaces. Esto permite el modelado de ambas partes en diferentes niveles de abstracción [33]. Además de ser una librería de clases C++, SystemC soporta una metodología de diseño que tiene como objetivo acelerar el ciclo de diseño. Entre sus ventajas se encuentra [35]: Refinamiento. No es necesario realizar una conversión desde un nivel de C/C++ a un lenguaje de alto nivel, sino que el diseño es refinado gradualmente, incluyendo las restricciones temporales y de hardware. El tiempo de desarrollo se reduce, tanto el de diseño como el de verificación. SystemC permite describir y verificar el diseño, y posteriormente sintetizarlo. 24 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC Los testbench pueden ser reutilizados. Las características y ventajas de SystemC hacen de él un lenguaje adecuado para el diseño a nivel de transacciones, pues incluye las interfaces y métodos necesarios para el mismo, dispone de FIFOs, interfaces de transporte bloqueantes y no bloqueantes, de acceso directo a memoria, de depurado, modelos de iniciadores y destinos, y modelos de payload genéricos; y además, soporta diferentes niveles de modelado temporal (untimed,loosely-time,approximately-time ycycle-accurate). 3.3.1. Estructura Un sistema descrito en SystemC consiste en un conjunto de módulos que se comunican entre ellos a través de canales o eventos. La estructura viene definida por módulos, interfaces, canales y puertos, tal como se describen a continuación [3], [34], [35]: Módulos. Se usan para modelar la estructura del diseño y contienen procesos concurrentes que describen la funcionalidad del sistema. Acceden a los canales a través de los puertos. SC_MODULE (nombre_módulo) { // Cuerpo } Interfaces. Son un conjunto de métodos que se utilizan para la comunicación entre los canales. Se basan en una clase abstracta de C++, donde únicamente hay métodos puros. Algunas de las interfaces que existen son sc_signal_in_if, sc_signal_inout_if, sc_fifo_in_if o sc_mutex_if. Canales. Representan el camino que sigue la comunicación entre dos procesos. Puede ser una simple señal o una estructura compleja, con procesos (canal jerárquico). Se accede a ellos a través de las interfaces. Las señales son internas a cada módulo y no son visibles desde otros módulos. Un ejemplo de canales primitivos son sc_signal o sc_fifo . 25 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC sc_signal<tipo_dato>nombre_señal_1, nombre_señal_2... Puertos. Son el punto de acceso a los módulos. Están relacionados con el tipo de interfaz con el que se conectan. sc_port<tipo_interfaz>nombre_puerto_1, nombre_puerto_2... Figura 3.3: Arquitectura de SystemC (adaptado de [33]) 3.3.2. Procesos En ellos se describe la funcionalidad del módulo. Se ejecutan concurrentemente, aunque cada proceso tiene un único hilo de ejecución. Deben ir en un módulo, no se puede crear un proceso dentro de una función. Sin embargo, un módulo puede contener varios procesos. SystemC distingue tres tipos de procesos [3], [32]: SC_METHOD. Se ejecutan cuando ocurre un evento en su lista de sensibilidad y no pueden ser suspendidos. Se suelen usar para simular el comportamiento combinacional, ya que se ejecutan en tiempo cero de simulación. 26 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC SC_MODULE (module) { SC_METHOD (method) ; sensitivein ; } void method () { out = in ; } SC_THREAD. Son ejecutados una vez al comienzo de la ejecución del sistema, aunque pueden quedar suspendidos por una llamada a la función wait() . En este caso, el proceso se reanudará en el mismo estado en el que fue suspendido cuando se produzca un evento. Si se indica el tiempo de suspensión del proceso, por ejemplo wait(10_SC_NS) , entonces la ejecución se reanudaría a los 10 ns. En general, este tipo de procesos suele definirse como un bucle infinito, de forma que cuando termina vuelve a ejecutarse. SC_MODULE (module) { SC_CTHREAD (thread) ; sensitivein ; } void thread () { for (i=1;i<10;i++) { wait() ; out = in ; } } SC_CTHREAD o proceso de reloj. Se trata de una modificación sobre el tipo anterior. Su principal diferencia es que en el registro se le añade un evento como sensiblidad, de forma que en la definición pueden realizarse nuevas formas de suspensión. Son usados principalmente en síntesis. 27 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC SC_MODULE (module) { SC_CTHREAD (cthread, clk.pos()) ; } void cthread () { wait() ; while (true) { out = in ; } } 3.3.3. Relojes Los relojes son señales con una notación temporal que permite dotar al sistema de relaciones temporales durante la simulación. La clase sc_time representa el tiempo. Es un entero de 64 bits. El tiempo de resolución es programable, tiene que ser potencia de 10 fs, y solo se puede poner una vez, antes de usarla y de simulación; por defecto es 1 ps. Las unidades que se pueden representar son: SC_FS, SC_PS, SC_NS, SC_US, SC_MS, SC_SEC [33]. sc_clock es un objeto que genera una forma de onda periódica. Tiene cuatro parámetros importantes: periodo, ciclo de trabajo, primer flanco y si el primer flanco es positivo ( posedge() ) o negativo ( negedge() ) [35]. sc_clock nombre_reloj (nombre, periodo, unidades_periodo, ciclo_trabajo, desfase, unidades_desfase); 28 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.3. LENGUAJE: SYSTEMC 3.3.4. Ejemplo En esta sección se presenta un ejemplo completo del diseño de un sumador (adder) descrito en SystemC. El modelo comprende dos ficheros: la cabecera (.h) y la definición (.cpp). En el primero se declaran los puertos y procesos, mientras que en el segundo se describe la funcionalidad. Para comprobar el correcto funcionamiento del sumador se debe hacer uso de un testbench, que será el que genere las entradas, y a su vez recibirá la salida para permitir monitorizarla. Por tanto, el diseño lo conforman tanto el testbench como el adder (UUT), formando una estructura jerárquica junto al sc_main , el cual conecta los dos módulos e indica el comienzo del procesamiento con sc_start() . Figura 3.4: Estructura de ficheros del modelo SystemC de un sumador 3.3.4.1. adder.h # include <systemc.h> // Se incluyen las librerías necesarias SC_MODULE (adder { // Módulo // Puertos sc_in<int>in1, in2 ; // in1 ein2 son dos puertos de entrada de tipo entero sc_out<int>out ; // out es el puerto de salida de tipo entero void add() ; // Función 29 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.4. MODELADO A NIVEL DE TRANSACCIONES // Constructor. SC_CTOR (adder) { // La función add se va a iniciar cuando in1 oin2 sufran algún cambio SC_METHOD (add) ; sensitivein1 in2 ; } }; El constructor es una función del mismo nombre que la clase, pero sin el tipo de retorno. Se utiliza para crear y para inicializar un módulo y las estructuras de datos del mismo. Además, se registran los procesos y los módulos instanciados dentro de él. 3.3.4.2. adder.cpp # include <adder.h> // Se incluye la cabecera void adder::add() { // Operación suma out = in1.read() + in2.read() ; } 3.4. Modelado a nivel de transacciones La complejidad de los sistemas electrónicos actuales es cada vez mayor. El objetivo es un SoC de pequeño tamaño que incluya diferentes IPs periféricos, buses, múltiples procesadores y memorias. Además, se persigue una mayor velocidad de simulación, desarrollo simultáneo de software, poder acceder al mercado lo antes posible (time-to-market), y todo esto a un bajo coste. Los diseñadores no son capaces de cubrir las deficiencias de los diseños tradicionales, por lo que tratan de desarrollar nuevas metodologías, como por ejemplo [47]: Hardware Emulation:Es muy costoso y está limitado por las capacidades de depuración. Además, se debe esperar por los diseños RTL. 30 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.4. MODELADO A NIVEL DE TRANSACCIONES Cycle Accurate Model:Requiere un gran esfuerzo en el modelado y es difícil hacer frente a la evolución RTL. Ante este panorama se presenta un nuevo nivel de abstracción, superior a RTL, donde los detalles de tiempo no son considerados y la comunicación entre módulos está modelada por canales en lugar de cables. Este nivel es llamado nivel de transacciones y el acto de modelar sistemas en él es conocido como modelado a nivel de transacciones (Transaction-Level Modeling, TLM) [10]. Figura 3.5: Velocidad de simulación de un frame de un decodificador MPEG-4 en modelos a diferentes niveles de abstracción (adaptado de [47]) La metodología basada en transacciones fue creada en busca de un nuevo enfoque que pudiera permitir la representación de un diseño en un nivel de abstracción intermedio entre las especificaciones y los modelos RTL. Una solución de alto nivel que integra el diseño a nivel de sistemas electrónicos con la implementación a nivel de bloques. Actualmente se ha publicado la versión 2.0 de esta metodología [3], donde está incluida la definición de TLM 1.0, siendo este la base del modelado a nivel de transacciones y cuyas características se exponen en los siguientes apartados. 31 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.4. MODELADO A NIVEL DE TRANSACCIONES También cuenta con una interfaz de análisis ( tlm_analysis_if ) que se usa para monitorizar las transacciones entre componentes conectados. Es unidireccional, no bloqueante y no negociante, es decir, el módulo que la recibe no tiene otra elección más que aceptar inmediatamente la transacción pasada como argumento [3]. 3.4.4. Canales TLM implementa tres canales [3], [53]: tlm_fifo. Es el canal primitivo predefinido de TLM, así como el más usado. Trata de modelar el comportamiento de una FIFO, la cual puede ser redimensionada después de que el objeto haya sido construido. Se utiliza para implementar todas las interfaces unidireccionales bloqueantes y no bloqueantes mencionadas anteriormente. tlm_req_rsp_channel. Consiste en dos FIFOs, una para la petición que será enviada al receptor y otra para la respuesta del mismo. Pueden ser de cualquier tamaño. tlm_transport_channel. Se trata de una FIFO que convierte una interfaz bidireccional en dos transacciones unidireccionales, una para la petición y otra para la respuesta. Su tamaño es 1. Figura 3.12: Diagrama de relaciones entre interfaces (adaptado de [54]) 38 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.4. MODELADO A NIVEL DE TRANSACCIONES Con el modelado a nivel de transacciones no es necesario implementar un protocolo de comunicación entre dos interfaces TLM, ya que cada transacción, internamente y no visibles para el diseñador, incluye una serie de señales que permiten la sincronización entre módulos. Figura 3.13: Canales: Estructura a nivel de señales (adaptado de [55]) 3.4.5. Ventajas Tras haber presentado esta nueva metodología, basada en modelar los sistemas a nivel de transacciones, se pueden indicar las siguientes ventajas [56]: Fácil modelado de las comunicaciones. Verificación funcional. Evaluación y corrección de errores en las primeras fases de diseño. Integración de los modelos HW/SW. Precisión en el modelado. Simulaciones mucho más rápidas que en RTL. 39 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.5. FLUJO DE DISEÑO PROPUESTO 3.5. Flujo de diseño propuesto En la Figura 3.14 se muestra el flujo de diseño que se propone seguir para poder conseguir modelos sintetizables, tanto para ASIC como para FPGA, a partir del modelado a nivel de transacciones. Figura 3.14: Flujo de diseño propuesto Partiendo del código en SystemC de la aplicación de referencia se procederá a realizar el modelado a nivel de transacciones, adecuando las interfaces de la misma y obteniendo así el diseño TLM. Se verificará su correcto funcionamiento, comparando siempre los resultados con la aplicación original y usando la herramienta de Cadence, SimVision. 40 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS Cuando la descripción ESL sea funcionalmente correcta se hará la síntesis de alto nivel mediante Cadence CtoS, indicando si el diseño será para ASIC o FPGA y así obtener el respectivo modelo RTL, del cual se comprobará si cumple con la funcionalidad. Una vez el paso anterior esté finalizado y se prosiga con el flujo se realizará la síntesis lógica, que dependiendo del modelo RTL obtenido, para ASIC o FPGA, se utilizará Synopsys Design Compiler o Synopsys Synplify Premiere, respectivamente. En este punto se tendrán modelos sintetizables a partir de la definición de una metodología de síntesis ESL basada en TLM, y por tanto, se habrá conseguido el objetivo principal de este proyecto. Por último, para demostrar la viabilidad del diseño y tener una referencia de su posible implementación en una FPGA, se llevará a cabo la síntesis física con PlanAhead y Vivado de Xilinx. 3.6. Herramientas En este apartado se enumerarán las herramientas que se han utilizado en la elaboración del proyecto, y que permiten reducir el tiempo de diseño en sistemas complejos, así como mejorar la calidad de los resultados (QoR). 3.6.1. Cadence C-to-Silicon Compiler Cadence C-to-Silicon Compiler (CtoS) es un entorno de diseño que permite realizar la síntesis de alto nivel de un sistema electrónico [38]. Además, ha desarrollado una librería de IPs sintetizables para poder usarlos con CtoS, incluye FIFOs, registros, interfaces de bus, operaciones en punto fijo, etc. Estos modelos están diseñados para que sean altamente configurables y provean una buena calidad de los resultados obtenidos durante la síntesis [36]. Hasta ahora la principal barrera para la adopción generalizada del diseño basado en TLM es que la síntesis automatizada no había sido capaz de proporcionar una calidad de los resultados similares a los obtenidos a partir de los modelos RTL codificados manualmente [37]. CtoS soporta las tareas de síntesis de alto nivel. Entre sus beneficios se encuentra [39]: Reducción del esfuerzo en la verificación con la introducción de menos errores (bugs), facilidad de depurado y simulaciones más rápidas que con RTL. 41 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS Alta productividad y reusabilidad, ya que ofrece mayor rapidez que trabajando con RTL, flexibilidad a la hora de analizar las arquitecturas y facilidad para refinar o recolocar los relojes. Figura 3.15: Interfaz de usuario de Cadence C-to-Silicon Compiler 3.6.1.1. Características principales Algunas de las características generales de este entorno son [38]: Acepta diseños con un nivel de abstracción alto, como puede ser TLM, descritos en SystemC, C o C++. Separa la funcionalidad de las restricciones. Permite elegir entre trabajar con interfaz gráfica (GUI) o de texto mediante scripts basados en TCL. Produce modelos sintetizables a nivel RTL en Verilog. CtoS acepta el modelado a nivel de transacciones y el estándar de OSCI TLM 1.0, del cual ofrece un completo soporte [39]. Por tanto, se ajusta perfectamente a una metodología orientada a la síntesis de alto nivel, permitiendo obtener modelos sintetizables, tanto para FPGA como para ASIC, a partir del modelado a nivel de transacciones. 42 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS Figura 3.16: Metodología orientada a la síntesis de alto nivel (adaptado de [37]) 3.6.1.2. Flujo de diseño El flujo de diseño de CtoS describe el orden en el que se debería realizar el proceso de síntesis, así como aporta los comandos, informes y modelos necesarios en cada paso. En la Figura 3.17 se muestra el flujo de diseño soportado. 1. Inicio. Se crea un nuevo diseño o se abre uno ya existente. 2. Configuración del diseño. Se especifica si el diseño es SystemC, C/C++ o TLM. Además, se define el reloj y se incluyen los ficheros fuente. Si se tratara de un diseño TLM también habrá que definir los transactors, que son aquellos que generan el protocolo de comunicación una vez se ha sintetizado. 43 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS Figura 3.17: Flujo de diseño de CtoS (adaptado de [38]) 3. Especificación de la micro-arquitectura. Se realizan las transformaciones en la arquitectura necesarias para hacer el diseño sintetizable. Esto implica resolver problemas de realimentación en funciones y bucles, entre otros aspectos. Algunas funciones no son sintetizables por tener caminos diferentes que requieren distinta latencia. Se soluciona haciendo las funciones “en línea” (inline), es decir, sustituir la llamada por el código que la describe. El efecto es un incremento en los recursos hardware necesarios para su implementación. 44 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS En el caso de los bucles combinacionales, deben ser eliminados porque estos no pueden ser implementados en hardware. Para ello, teniendo en cuenta las restricciones de área y de frecuencia, se puede realizar una de las siguientes acciones: Desenrollar el bucle para ser realizado enteramente en tiempo cero. Esto puede ser inviable para bucles de muchas iteraciones, pues sería la ruta crítica, con una latencia muy alta, ya que consume muchos recursos. En cambio, permite obtener mayor velocidad en el proceso. Romper el bucle para que cada iteración se realice en un ciclo de reloj, reutilizando recursos. Realizar una segmentación del bucle, lo cual significa dividir la ejecución del bucle en un número determinado de etapas, de tal forma que cada iteración se encuentra en una etapa, paralelizando así varias iteraciones. 4. Asignación de IPs. Se asignan las variables de tipo vector a memorias. 5. Análisis de la micro-arquitectura. Dado que el diseño ya está completamente transformado y CtoS puede realizar las últimas optimizaciones, se puede hacer un análisis temporal, de área o de potencia. 6. Planificación. El planificador del CtoS asignará recursos a las operaciones definidas en el diseño. En caso de que no pueda realizar esta operación, el diseñador puede ayudarle controlando: La dependencia con vectores de datos. Esto hará que el planificador conozca las dependencias y pueda añadir estados para resolverlas. Los estados. En caso de que el planificador no pueda resolver los conflictos secuenciales, el diseñador puede añadir manualmente estados para que CtoS pueda encontrar una solución. Los recursos. El diseñador podrá realizar una asignación inicial de recursos sobre los que realizar la asignación de las operaciones del diseño. 7. Asignación y control de registros. Se controlan los registros y se le asignan los valores requeridos. Se puede incluir una lógica de reset para aquellos registros que no lo tengan, registrar o no todas las salidas de los recursos de lógica combinacional asociados a operaciones del diseño, o minimizar los registros (asociados a los diseños basados en ASIC, donde el coste en área de los registros es alto) o el número de multiplexores (asociado a los diseños basados en FPGAs). 45 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS 8. Análisis e implementación. Se realizan informes de distinto tipo, como puede ser el consumo de recursos o de latencia en ciclos de reloj de cada bloque. También se podrán generar los ficheros de salida (la descripción RTL), un script que realice las mismas acciones que se han seguido a través de la interfaz gráfica, o un fichero contenedor en SystemC de la descripción RTL. 3.6.1.3. Transactors Una de las ventajas de CtoS es que soporta TLM y provee un versión sintetizable de la librería TLM 1.0, así como la librería que contiene los transactors básicos. Un transactor (TX en la Figura 3.18) permite refinar la interfaz TLM en el protocolo de comunicación a nivel de señales. El transactor espejo (MTX en la Figura 3.18) utiliza el protocolo handshake con el transactor. Para poder realizar la verificación del sistema, CtoS automáticamente genera el wrapper necesario. Este es un módulo que instancia el transactor espejo y el wrapper TLM generado durante la síntesis, el cual define el refinamiento de las interfaces externas en interfaces a nivel de señales. Figura 3.18: Transactors (adaptado de [38]) 3.6.2. Simulation Analysis Environment SimVision Con las nuevas tendencias de diseño, cada vez a más alto nivel, las herramientas de simulación deben adecuarse a los nuevos requerimientos. Para ello se hace uso de Cadence Incisive Enterprise Simulator, un entorno de verificación que soporta múltiples lenguajes (SystemVerilog, Verilog, VHDL, 46 CAPÍTULO 3. METODOLOGÍA DE DISEÑO 3.6. HERRAMIENTAS SystemC, C, C++, etc.) y diferentes herramientas para simulación y depuración del diseño en modo gráfico, como es SimVision. Figura 3.19: Interfaz de usuario de Simulation Analysis Environment SimVision SimVision se puede utilizar para depurar diseños TLM o RTL, soporta la representación de señales digitales, analógicas o mixtas, así como los lenguajes citados Verilog, System Verilog, VHDL o SystemC [40]. 3.6.2.1. Características principales Las características generales de SimVision son [41], [43]: Soporte multi-lenguaje y multi-señal, es decir, acepta todos los estándares del IEEE y Accellera. Verificación a todos los niveles de abstracción, desde TLM hasta código HDL. Simulación cruzada de sistemas escritos por combinación de los lenguajes soportados. Ejecución en línea de comandos (TCL) o en forma de onda. 47 Capítulo 4 Modelado TLM con wrapper 4.1. Introducción El modelado de un sistema electrónico transforma las especificaciones del sistema, utilizando un lenguaje existente, para realizar su posterior verificación del correcto funcionamiento mediante simulaciones. El siguiente paso sería la transformación de dicho modelo hacia una implementación, de manera que se irá optimizando el diseño a medida que se va desarrollando durante el proceso. Como se comentó en el Capítulo 2, se parte del diseño en alto nivel del código de referencia del decodificador H.264/AVC desarrollado por el Instituto Universitario de Microelectrónica Aplicada, descrito en SystemC, para luego modelarlo con TLM. Por tanto, primero se hará una descripción de la situación inicial de esta etapa, se verá desde dónde se parte, para después presentar la versión modelada a nivel de transacciones del módulo correspondiente con wrapper. 4.2. Diseño de referencia El objeto de estudio de este proyecto es el modelado TLM y la síntesis del bloque inter_p del decodificador de vídeo. No obstante, es necesario otro módulo (testbench) para poder realizar la verificación del bloque en cuestión. Ambos están interconectados y forman una estructura jerárquica junto al sc_main . En el archivo sc_main.cpp se instancian los módulos que se quieren conectar. Además, se declaran las señales para poder realizar dicha conexión y se establece el reloj, siendo en este caso un reloj 55 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA de nombre “clk”, con un periodo de 10 ns, un ciclo de trabajo del 50% y sin desfase. sc_clock clk (clk, 10, SC_NS, 0.5, 0.0, SC_PS); Figura 4.1: Estructura de ficheros del modelo inicial 4.2.1. Módulo inter_p El bloque inter_p crea macrobloques de predicción a partir de los vectores de movimiento y del fotograma de referencia. 4.2.1.1. Definición de las interfaces y los puertos Figura 4.2: Puertos de E/S del bloque inter_p 56 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA La Tabla 4.1 recoge la descripción de los puertos de entrada y salida del bloque. Puerto Ancho Descripción clk 1Reloj rst_n 1Reset, activa a nivel bajo start 1Comienzo de los procesos del inter_p finish 1Finalización de los procesos del inter_p ready 1Señalización de que los datos están preparados h_control_interface_data 64 Protocolo de comunicación con el módulo CAVLD h_control_interface_request 1 h_control_interface_validate 1 i_trans_interface_data 9Protocolo de comunicación con el módulo iqit i_trans_interface_request 1 i_trans_interface_validate 1 dma_interface_data 34 Protocolo de comunicación para el acceso a la memoria dma_interface_request 1 dma_interface_validate 1 mem_interface_data 8Protocolo de comunicación para la transferencia con la memoria mem_interface_request 1 mem_interface_validate 1 inter_p_unfiltered_interface_data 8Protocolo de comunicación con el módulo d_filter inter_p_unfiltered_interface_request 1 inter_p_unfiltered_interface_validate 1 d_filter_vector_interface_data 10 Vectores de movimiento d_filter_vector_interface_request 1 d_filter_vector_interface_validate 1 h_control_vector_interface_data 10 Vectores de movimiento h_control_vector_interface_request 1 h_control_vector_interface_validate 1 Tabla 4.1: Descripción de los puertos E/S 57 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA En el archivo inter_p.h se encuentran definidas tanto las interfaces como los puertos del módulo que se conectarán con el resto de módulos, aunque en este caso, solo lo harán con el testbench. SC_MODULE (inter_p) { // INTERFACES AND PORTS sc_in<bool>clk ; sc_in<bool>rst_n ; sc_in<bool>start ; sc_out<bool>finish ; sc_out<bool>ready ; // H_CONTROL interface sc_in< sc_uint<64> >h_control_interface_data ; sc_out<bool>h_control_interface_request ; sc_in<bool>h_control_interface_validate ; // I_TRANS interface sc_in< sc_int<9> >i_trans_interface_data ; sc_out<bool>i_trans_interface_request ; sc_in<bool>i_trans_interface_validate ; // Sample memory (reference frame) access request sc_out< sc_uint<34> >dma_interface_data ; sc_in<bool>dma_interface_request ; sc_out<bool>dma_interface_validate ; // Sample memory (reference frame) transfer sc_in< sc_uint<8> >mem_interface_data ; sc_out<bool>mem_interface_request ; sc_in<bool>mem_interface_validate ; 58 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA // Output data interface - unfiltered block sc_out< sc_uint<8> >inter_p_unfiltered_interface_data ; sc_in<bool>inter_p_unfiltered_interface_request ; sc_out<bool>inter_p_unfiltered_interface_validate ; // Output data interface - motion vectors sc_out< sc_int<10> >d_filter_vector_interface_data ; sc_in<bool>d_filter_vector_interface_request ; sc_out<bool>d_filter_vector_interface_validate ; sc_out< sc_int<10> >h_control_vector_interface_data ; sc_in<bool>h_control_vector_interface_request ; sc_out<bool>h_control_vector_interface_validate ; ... }; 4.2.1.2. Definición de las funciones y los procesos El bloque inter_p está compuesto por seis bloques funcionales y siete memorias que realizan las operaciones necesarias para poder llevar a cabo su función correctamente. En este proyecto los módulos se tratan como “cajas grises” (grey-box model), es decir, la funcionalidad está completamente definida, y el objetivo es introducir comunicaciones TLM en la interfaz. Por ello solo será de interés el módulo inter_p_if, que incluye el protocolo de comunicación. En el archivo inter_p_if.h están definidas las funciones y los procesos que hacen posible el funcionamiento de la interfaz de dicho módulo. 59 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA Figura 4.3: Módulo inter_p: Ficheros que lo componen 60 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA SC_MODULE (inter_p_if) { ... // FUNCTIONS AND PROCESS void main() ; void read_in() ; void write_out() ; void h_control_interface() ; void i_trans_interface() ; void unfiltered_interface() ; void vector_interface() ; void transfer_ref_frame() ; ... SC_CTOR(inter_p_if) { ... // Process registration SC_THREAD(main) ; sensitive clk.pos() ; SC_THREAD(h_control_interface) ; sensitive clk.pos() ; SC_THREAD(i_trans_interface) ; sensitive clk.pos() ; 61 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA SC_THREAD(unfiltered_interface) ; sensitive clk.pos() ; SC_THREAD(vector_interface) ; sensitive clk.pos() ; SC_THREAD(transfer_ref_frame) ; sensitive clk.pos() ; } }; La Tabla 4.2 recoge la descripción de las funciones. Función Descripción void main() Coordina todo el funcionamiento del módulo. Inicializa las señales de control ready y finish , e invoca a las funciones de lectura y escritura cuando corresponda void read_in() Realiza la lectura de datos y genera la señal ready void write_out() Realiza la escritura de los datos y genera la señal finish void h_control_interface() Genera el protocolo de comunicación con el módulo CAVLD void i_trans_interface() Genera el protocolo de comunicación con el módulo iqit void unfiltered_interface() Genera el protocolo de comunicación con el módulo d_filter void vector_interface() Genera el protocolo de comunicación para los vectores de movimiento void transfer_ref_frame() Genera el protocolo de comunicación con la memoria Tabla 4.2: Descripción de las funciones del bloque inter_p 62 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.2. DISEÑO DE REFERENCIA 4.2.1.3. Protocolo de comunicación Como se comentó en el Capítulo 2, el protocolo de comunicación que implementa el módulo utiliza un esquema de handshake, donde un primer módulo envía una petición a un segundo, y este prepara los datos y emite la validación de los mismos. En definitiva, se utilizan tres señales, siendo generalmente: request,data yvalidate (petición, datos y validación, respectivamente). Por cada conexión con cada módulo, el bloque inter_p aplica la idea anterior, es decir, para la comunicación con un módulo concreto usará una señal data, la señal request y la señal validate. En la Figura 4.4 se puede observar la comunicación del módulo bajo estudio con el CAVLD. En este caso, el primero es el que inicia la comunicación haciendo una petición al segundo (punto 1). Cuando se recibe la petición, se activa la señal de validación (punto 2) a la vez que inicia el envío de los datos (punto 3) y el inter_p desactiva la señal de request (punto 4). Cuando la transferencia de datos concluye el CAVLD desactiva la señal validate (punto 5). Figura 4.4: Comunicación entre el bloque inter_p y CAVLD Lo que envía el testbench el bloque inter_p espera recibirlo, y viceversa. Los datos que se transmiten son: 11 palabras de 64 bits ( h_control_interface_data ). 256 palabras de 9 bits ( i_trans_interface_data ). 1.024 palabras de 8 bits ( mem_interface_data ). 63 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES sc_signal< sc_uint<8> >inter_p_unfiltered_interface_data ; sc_signal<bool>inter_p_unfiltered_interface_request ; sc_signal<bool>inter_p_unfiltered_interface_validate ; sc_signal< sc_int<10> >d_filter_vector_interface_data ; sc_signal<bool>d_filter_vector_interface_request ; sc_signal<bool>d_filter_vector_interface_validate ; sc_signal< sc_int<10> >h_control_vector_interface_data ; sc_signal<bool>h_control_vector_interface_request ; sc_signal<bool>h_control_vector_interface_validate ; sc_clock clk (clk, 10, SC_NS, 0.5, 0.0, SC_PS); sc_signal<bool>rst_n ; sc_signal<bool>start ; sc_signal<bool>finish ; sc_signal<bool>ready ; ... // Instantiate FIFOs tlm_fifo< sc_uint<64> >h_control_fifo(h_control_fifo) ; tlm_fifo< sc_int<9> >i_trans_fifo(i_trans_fifo) ; tlm_fifo< sc_uint<8> >unfiltered_fifo(unfiltered_fifo) ; tlm_fifo< sc_int<10> >h_control_vector_fifo(h_control_vector_fifo) ; tlm_fifo< sc_int<10> >d_filter_vector_fifo(d_filter_vector_fifo) ; 70 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES tlm_fifo< sc_uint<34> >dma_fifo(dma_fifo) ; tlm_fifo< sc_uint<8> >mem_fifo(mem_fifo) ; Como se vio en el Capítulo 3, TLM implementa tres canales, de los cuales tlm_fifo es el que mejor se adapta a la situación de partida, pues el módulo está compuesto por interfaces unidireccionales, descartando así tlm_transport_channel . Además, es necesario una única FIFO, prescindiendo de tlm_req_rsp_channel . 4.3.1. Wrapper inter_p El objetivo del wrapper es poder implementar una interfaz TLM en el bloque y que este se pueda comunicar externamente usando la misma. No obstante, internamente continuará con el protocolo de comunicación propio del módulo inter_p. 4.3.1.1. Definición de las interfaces y los puertos La Tabla 4.4 recoge la descripción de los puertos de entrada y salida de este bloque. Figura 4.8: Puertos E/S del wrapper del bloque inter_p 71 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES Puerto Ancho Descripción clk 1 Reloj rst_n 1Reset, activo a nivel bajo start 1 Comienzo de los procesos finish 1 Finalización de los procesos ready 1 Señalización de que los datos están preparados h_control_data_tlm 64 Comunicación con el módulo CAVLD i_trans_data_tlm 9 Comunicación con el módulo iqit dma_data_tlm 34 Comunicación para el acceso a la memoria mem_data_tlm 8 Comunicación para la transferencia con la memoria unfiltered_data_tlm 8 Comunicación con el módulo d_filter d_filter_vector_data_tlm 10 Vectores de movimiento h_control_vector_data_tlm 10 Vectores de movimiento Tabla 4.4: Descripción de los puertos E/S del wrapper En el archivo inter_p_wrapper.h se encuentran definidas tanto las interfaces como los puertos. Como ya se dijo al principio de este apartado, el bloque inter_p contiene señales unidireccionales, por lo que se usan las interfaces get y put para la lectura y escritura de los datos respectivamente. La interfaz peek no está soportada por la herramienta de síntesis CtoS. Por otro lado, se utilizan interfaces bloqueantes, ya que para poder controlar el protocolo de comunicación interno es necesario el uso de la función wait() . SC_MODULE (inter_p_wrapper) { sc_in_clk clk ; sc_in<bool>rst_n ; sc_in<bool>start ; sc_out<bool>finish ; 72 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES sc_out<bool>ready ; sc_port< tlm_blocking_get_if< sc_uint<64> > >h_control_data_tlm ; sc_port< tlm_blocking_get_if< sc_int<9> > >i_trans_data_tlm ; sc_port< tlm_blocking_put_if< sc_uint<8> > >unfiltered_data_tlm ; sc_port< tlm_blocking_put_if< sc_int<10> > >h_control_vector_data_tlm ; sc_port< tlm_blocking_put_if< sc_int<10> > >d_filter_vector_data_tlm ; sc_port< tlm_blocking_put_if< sc_uint<34> > >dma_data_tlm ; sc_port< tlm_blocking_get_if< sc_uint<8> > >men_data_tlm ; ... }; 4.3.1.2. Definición de las funciones y los procesos El wrapper por un lado tiene que sincronizarse con el diseño de referencia, y por otro, adaptarse al modelado TLM, de manera que sus funciones tendrán que escribir o leer los datos enviados a través del canal TLM e implementar el protocolo de comunicación con los diferentes bloques que constituyen el modelo original, incluyendo la lectura o escritura de los datos. Al introducir el wrapper, este debe almacenar cada una de las memorias que conforman las interfaces del modelo de referencia. Por ejemplo, el inter_p_wrapper está a la espera de recibir las once palabras correspondientes a h_control_interface_data . Sin embargo, el tb_wrapper no puede transmitirlas hasta que el protocolo de comunicación con el testbench comience, y una vez se ha iniciado, debe almacenar las once palabras para luego enviarlas vía TLM. A continuación se muestra el código de las funciones y los procesos utilizados en este bloque: SC_MODULE (inter_p_wrapper) { ... 73 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES void h_control_process() ; void i_trans_process() ; void unfiltered_process() ; void vector_process() ; void memory_process() ; SC_CTOR(inter_p_wrapper) : ... SC_THREAD(h_control_process); sensitive clk.pos() ; SC_THREAD(i_trans_process); sensitive clk.pos() ; SC_THREAD(unfiltered_process); sensitive clk.pos() ; SC_THREAD(vector_process); sensitive clk.pos() ; SC_THREAD(memory_process); sensitive clk.pos() ; } }; En la siguiente tabla se recoge la descripción de las funciones. 74 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES Función Descripción void h_control_process() Lee los datos del puerto h_control_data_tlm . Implementa el protocolo de comunicación interno correspondiente al CAVLD void i_trans_process() Lee los datos del puerto i_trans_data_tlm . Implementa el protocolo de comunicación interno correspondiente al iqit void unfiltered_data() Escribe los datos en el puerto unfiltered_data_tlm . Implementa el protocolo de comunicación interno correspondiente al d_filter void vector_process() Escribe los datos en los puertos h_control_vector_data_tlm y d_filter_vector_data_tlm . Implementa el protocolo de comunicación interno correspondiente a los vectores de movimiento void memory_data() Lee los datos del puerto mem_data_tlm y escribe los datos en el puerto dma_data_tlm . Implementa el protocolo de comunicación interno correspondiente a la memoria Tabla 4.5: Descripción de las funciones del wrapper del bloque inter_p 4.3.2. Wrapper testbench Al igual que el wrapper del bloque inter_p, el wrapper del testbench dotará a este de una interfaz TLM. Las definiciones tanto de las interfaces como de las funciones y los procesos se encuentran en el archivo tb_wrapper.h. 4.3.2.1. Definición de las interfaces y los puertos La descripción de los puertos de entrada y salida es la misma que para el bloque en estudio (Tabla 4.4). 75 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES Figura 4.9: Puertos E/S del wrapper del testbench En TLM se deben implementar el mismo tipo de interfaces en los distintos módulos que se conecten, es decir, si en el bloque inter_p se usaron interfaces bloqueantes, en el testbench se utilizará el mismo tipo de interfaz. SC_MODULE (tb_wrapper) { sc_in_clk clk ; sc_out<bool>rst_n ; sc_in<bool>start ; sc_out<bool>finish ; sc_out<bool>ready ; sc_port< tlm_blocking_put_if< sc_uint<64> > >h_control_data_tlm ; sc_port< tlm_blocking_put_if< sc_int<9> > >i_trans_data_tlm ; sc_port< tlm_blocking_get_if< sc_uint<8> > >unfiltered_data_tlm ; sc_port< tlm_blocking_get_if< sc_int<10> > >h_control_vector_data_tlm ; sc_port< tlm_blocking_get_if< sc_int<10> > >d_filter_vector_data_tlm ; sc_port< tlm_blocking_get_if< sc_uint<34> > >dma_data_tlm ; 76 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES sc_port< tlm_blocking_put_if< sc_uint<8> > >men_data_tlm ; ... }; 4.3.2.2. Definición de las funciones y de los procesos El código de las funciones y los procesos establecidos es el que sigue: SC_MODULE (tb_wrapper) { ... void h_control_process() ; void i_trans_process() ; void unfiltered_process() ; void vector_process() ; void memory_process() ; SC_CTOR(tb_wrapper) : ... SC_THREAD(h_control_process); sensitive clk.pos() ; SC_THREAD(i_trans_process); sensitive clk.pos() ; SC_THREAD(unfiltered_process); sensitive clk.pos() ; SC_THREAD(vector_process); sensitive clk.pos() ; 77 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.3. MODELADO A NIVEL DE TRANSACCIONES SC_THREAD(memory_process); sensitive clk.pos() ; } }; Como se puede observar las funciones y procesos usados son exactamente los mismos que en el wrapper del bloque inter_p. Sin embargo, donde en aquel se lee un dato, en este se escribe. En la siguiente tabla se expone la descripción de las funciones. Función Descripción void h_control_process() Escribe los datos en el puerto h_control_data_tlm . Implementa el protocolo de comunicación interno correspondiente al CAVLD void i_trans_process() Escribe los datos en el puerto i_trans_data_tlm . Implementa el protocolo de comunicación interno correspondiente al iqit void unfiltered_data() Lee los datos del puerto unfiltered_data_tlm . Implementa el protocolo de comunicación interno correspondiente al d_filter void vector_process() Lee los datos de los puertos h_control_vector_data_tlm y d_filter_vector_data_tlm . Implementa el protocolo de comunicación interno correspondiente a los vectores de movimiento void memory_data() Escribe los datos en el puerto mem_data_tlm y lee los datos del puerto dma_data_tlm . Implementa el protocolo de comunicación interno correspondiente a la memoria Tabla 4.6: Descripción de las funciones del wrapper del testbench 78 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.4. VERIFICACIÓN FUNCIONAL 4.4. Verificación funcional Figura 4.10: Simulación del sistema original en SystemC 79 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS 4.5. Síntesis Tras el modelado y la verificación, la siguiente etapa del flujo de diseño es la síntesis. Consiste en convertir o traducir un modelo descrito en un nivel de abstracción alto a una descripción del mismo a un nivel inferior, añadiendo detalles de implementación al sistema, por ejemplo, tras la síntesis de un modelo en HDL se obtendría su descripción a nivel de puertas. Figura 4.18: Flujo de la síntesis El objetivo de este apartado es la presentación del proceso de síntesis, partiendo del modelado TLM y centrándose en la síntesis de alto nivel, a fin de obtener la microarquitectura a nivel RTL. 4.5.1. Consideraciones previas En la síntesis de alto nivel existen muchos grados de libertad a la hora de implementar una determinada función, intervienen variables como el consumo, el área ocupada, la velocidad de operación, etc. Dado que normalmente no es posible obtener un sistema sintetizado que optimice todos estos parámetros, es necesario establecer un compromiso entre los mismos o determinar cuál de ellos es el que más interesa. De ahí que el proceso de síntesis siempre vaya unido al de optimización [57]. Los tres parámetros básicos a optimizar son el área o recursos ocupado, la latencia, que es el número de ciclos necesarios para completar una función, y el tiempo de ciclo, que vendrá determinado 86 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS por el bloque más lento del sistema. Estos parámetros pueden usarse como restricciones del diseño y se deberán tener en cuenta a la hora de efectuar la optimización. Claramente, el objetivo principal de este proyecto es obtener modelos sintetizables a partir del modelado a nivel de transacciones. Para ello se tendrán en cuenta los parámetros indicados como restricciones de diseño, asegurando que el sistema tras la síntesis continúe funcionando correctamente. Por otro lado, existen dos enfoques basados en la partición del sistema en módulos más simples, que al interconectarlos consiguen la funcionalidad principal. Al módulo que integra y conecta al resto se le conoce como top del diseño. Las estrategias de síntesis que se pueden adoptar son las siguientes: 1. top-down, consiste en crear un único proyecto para la síntesis, cuyo módulo principal es el top y este instancia los demás bloques. El sistema se sintetiza a partir del top del diseño. 2. bottom-up, se basa en sintetizar cada bloque del sistema por separado y finalmente integrarlos todos mediante el módulo top, el cual está dedicado a definir la conectividad entre ellos. En este caso se va a utilizar la primera estrategia, top-down, ya que permite obtener mejores resultados de síntesis para los bloques del diseño. 4.5.2. Síntesis de alto nivel La síntesis de alto nivel o HLS (High-Level Synthesis) se basa en el principio de que todo sistema puede modelarse mediante una serie de operaciones y sus dependencias [57]. El primer paso de este proceso consiste en traducir la especificación que el diseñador propone utilizando uno de los lenguajes funcionales a nivel de sistemas, típicamente C/C++ o SystemC, en una representación RTL descrita en un HDL. Cadence C-to-Silicon Compiler (CtoS) es un entorno de trabajo que realiza la síntesis del diseño desde SystemC o TLM, transformando el mismo hasta una representación RTL en Verilog. Antes de comenzar con la síntesis se debe incluir una interfaz de reset en todos los procesos, requisito obligatorio para que los procesos se puedan implementar como sistemas síncronos. La forma de introducir la especificación del reset mantiene la compatibilidad del modelo con las herramientas de simulación y con otras de síntesis. Para ello se hace uso del preprocesador de C y de las macros 87 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS definidas por CtoS ( #if defined(__CTOS__) || defined(CTOS_MODEL) ). SC_THREAD (memory_process); sensitive clk.pos() ; reset_signal_is (rst_n, false); void inter_p_wrapper::memory_process() { // Reset #if defined(__CTOS__) || defined(CTOS_MODEL) dma_data_tlm->reset_put(); mem_data_tlm->reset_put(); #endif ... 4.5.2.1. Flujo de diseño CtoS Aunque en el Capítulo 3 se mostraba cuál era el flujo de diseño de la herramienta, ahora se describen en detalle los pasos seguidos. Además, CtoS permite escribir en un script las mismas acciones que se siguen a través de la interfaz gráfica y así facilitar el proceso de síntesis, con el consecuente ahorro de tiempo, por lo que también se indicará la sintaxis TCL de las operaciones llevadas a cabo. 1. Configuración del diseño El primer paso a realizar es la configuración del diseño, que incluye la selección del dispositivo o de las librerías tecnologícas, reloj, código fuente, macros definidos por el usuario, y otras opciones: Se especifica que se trata de un diseño TLM. Se indica el dispositivo de prototipado final y sus características. Para el caso del ASIC se referencian las librerías necesarias en formato Liberty, habiéndose usado en este proyecto UMC de 65 nm. 88 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Librería Tensión (V) Temperatura (oC) Caso Típico uk65lscsp10bbrccs_100c25_tc 1,0 25 Mejor Caso uk65lscsp10bbrccs_110c0_bc 1,1 0 Peor Caso uk65lscsp10bbrccs_090c125_wc 0,9 125 Tabla 4.7: Características de las librerías UMC de 65 nm Para el caso de la FPGA se identifica el fabricante y la familia de la misma. El diseño se implementará en tres FPGAs: Familia Dispositivo Registros BRAMs LUTs DSPs Xilinx Virtex5 xc5vfx130tff1738-1 81.920 298 81.920 320 Zynq xc7z045fbg676-2 437.200 545 437.200 900 Spartan6 xc6slx9csg225-2 11.440 32 5.720 16 Tabla 4.8: Dispositivos FPGA utilizados en este proyecto y sus recursos disponibles Se define el reloj, donde se indica la frecuencia y el ciclo de trabajo, el cual se da en términos de periodo de reloj y offset del flanco de bajada. Los valores se indican en picosegundos (ps). define_clock -name clk -period 10000 -rise 0 -fall 5000 Se establece una señal de reloj de nombre “clk”, frecuencia de 100 MHz (periodo de 10 ns) y ciclo de trabajo del 50%. El nombre del reloj debe ser el mismo que el usado en el diseño, pues luego será utilizado en el refinamiento de los puertos. Se definen los transactors,uno por cada interfaz. define_tlm_transactor 89 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS -name nombre_transactor -class {clase_transactor} -source_file ctos_transactors/ctos_transactors.h -clock nombre_reloj -reset nombre_reset -default_mirror_transactor {clase_transactor_espejo} Un ejemplo sería: define_tlm_transactor -name h_control_data_tlm_tx -class {tlm_blocking_put_tx< sc_uint<64> > >} -source_file ctos_transactors/ctos_transactors.h -clock clk -reset rst -default_mirror_transactor {tlm_blocking_put_mirror_tx< sc_uint<64> > >} Se refinan los puertos. refine_tlm_interface -port nombre_puerto -transactor {nombre_transactor} -clock nombre_reloj -reset nombre_reset -mirror_transactor {clase_transactor_espejo} Por ejemplo: 90 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS refine_tlm_interface -port h_control_data_tlm -transactor {h_control_data_tlm_tx} -clock clk -reset rst_n -mirror_transactor {tlm_blocking_put_mirror_tx< sc_uint<64> > >} Al igual que el nombre de la señal de reloj, el nombre de la señal de reset también debe ser el mismo que el especificado durante el modelado. Figura 4.19: CtoS. Definición de los transactors y refinamiento de los puertos 2. Especificación de la micro-arquitectura El siguiente paso es definir la microarquitectura del sistema: Resolución de los bucles combinacionales. Se puede optar por una de las siguientes estrategias: •Desenrollar el bucle. Se ejecutan las iteraciones en paralelo, en un único ciclo, ya que replica la lógica interna del bucle una vez por cada iteración. Se minimiza el número de 91 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS ciclos a costa de aumentar los recursos hardware necesarios y el periodo de reloj. El desenrollado puede ser completo o parcial. •Romper el bucle. Se añade una llamada a la función wait() al final de cada iteración, de manera que cada una se realice en un ciclo de reloj. Es la acción por defecto. En este caso se reutiliza el hardware y se procesa de forma secuencial cada iteración del bucle. •Realizar una segmentación del bucle o pipeline. Rompe el bucle de forma que se ejecuta en varios ciclos o etapas, y en cada una de ellas se lleva a cabo una iteración, paralelizando así varias. Se mejora el rendimiento para los mismos con gran carga en cada iteración, pero es ineficiente para aquellos sencillos pues añade lógica adicional. Depende de su tamaño y de la dependencia de datos. Figura 4.20: CtoS. Resolución de los bucles combinacionales El diseño presenta únicamente dos bucles combinacionales, por lo que la ruptura de ambos es la opción más acertada. set combo_loops [find_combinational_loops] foreach loop $combo_loops { puts breaking loop: $loop break_combinational_loop $loop } Resolución de las funciones no planificables. Algunas funciones no son sintetizables, 92 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS debido a latencias no constantes o por la llamada a la función desde distintos procesos concurrentes, entre otros casos. Para solucionarlo se hace la función “en línea” (inline), es decir, se sustituye la llamada por el código que la describe, replicando la función. Como consecuencia directa de esta acción aumenta el consumo de los recursos. inline /designs/proyecto/modules/modulo/behaviors/funcion Figura 4.21: CtoS. Resolución de las funciones no planificables 93 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Figura 4.22: Inline (adaptado de [39]) 3. Asignación de IPs En el caso de las variables de tipo vector se debe decidir qué tipo de recursos se utilizará para el almacenamiento hardware de los datos. Las posibles opciones son: RAM interna. Implementa una memoria lógica, bloques BRAM o LUTs. Es muy útil para mapear una RAM en una FPGA. Registros. Los datos se almacenan en registros. Es viable para casos de vectores de pocos elementos, y que estos no sean excesivamente grandes en términos de longitud de bits. RAM de terceros. Especifica que un array de gran tamaño será una memoria en la implementación hardware final. 94 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Figura 4.23: CtoS. Resolución de las variables de tipo vector La elección de una u otra opción dependerá de los objetivos de una específica implementación del diseño, y de cómo sea este. Utilizar registros es la mejor decisión para vectores pequeños, mientras que una RAM ofrecerá una implementación más eficiente para aquellos más grandes, por lo que las siete memorias con las que cuenta el diseño, se mapearán en una RAM, y para el resto de vectores se usarán registros. allocate_builtin_ram /designs/proyecto/modules/modulo/arrays/memoria 95 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Figura 4.30: ASIC. Verificación RTL 102 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Figura 4.31: FPGA. Verificación RTL 103 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Algunos aspectos que pueden dar lugar a diferencias entre el diseño en alto nivel y el sintetizado son: Uso de variables globales. CtoS soporta las variables globales dentro de un mismo proceso, de forma que una variable global es compartida tanto a la función principal como a las rutinas que sean llamadas desde la misma. Sin embargo, en los módulos donde existan dos o más hilos paralelos, el uso de esta no está permitido, provocando errores. En estos casos es necesario usar señales. Relajación de la latencia. Esta opción permite al planificador incrementar la latencia de un bloque para poder cumplir las restricciones temporales (ciclo de reloj) añadiendo registros intermedios. En las funciones de acceso a los puertos de salida o a las señales de control puede ocurrir que el diseño no cumpla las restricciones temporales impuestas por el protocolo de E/S. Por ejemplo, si se permite relajar la latencia en una función de control de lectura o escritura de una FIFO puede provocar que se inserten datos duplicados en la cola, o que se extraigan varios elementos. Inicialización de las memorias. Dado que las opciones para inicializar las memorias con SystemC implica acciones no soportadas en la síntesis, como por ejemplo usar bucles combinacionales, se obtienen memorias sin valores definidos. Para solucionar esto, en Verilog se ha usado la directiva $readmemb que permite la inicialización a través de un fichero externo que contenga los datos, separados por saltos de línea para cada posición. 4.5.4. Síntesis lógica Para obtener un mejor análisis del diseño, es necesario descender en el nivel de abstracción y realizar la síntesis lógica a partir de la descripción RTL obtenida. Dependiendo del dispositivo de prototipado final, Synopsys ofrece dos entornos de trabajo, Synplify para FPGA y Design Compiler para ASIC. En ambos casos los ficheros de entrada serán los generados por CtoS, tanto la descripción RTL en Verilog como las restricciones de entrada al entorno de síntesis. 4.5.4.1. Síntesis lógica para ASIC Los pasos a realizar del flujo de diseño de Design Compiler son los siguientes: Se cargan las librerías. Como se nombró anteriormente, se utilizan las librerías UMC de 65 nm. Se debe seleccionar aquella para el caso en el que se trabajará, pudiendo ser wc, worst case (peor caso); bc, best case (mejor caso) o tc, typical case (caso típico). 104 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Se lee el diseño, siendo los archivos RTL en Verilog obtenidos en la síntesis de alto nivel. Se define el reloj. Se especifica el entorno de diseño en el que va a operar, como el modelo de carga debido al interconexionado. Se definen las restricciones de diseño, por ejemplo el área máxima. Con las restricciones de diseño se le indica a la herramienta los objetivos de optimización. Se realiza la síntesis. Para compilar se pueden usar diferentes esfuerzos, dependiendo de la precisión que se quiera obtener. En este caso se deja la opción por defecto: esfuerzo medio, compromiso entre calidad y tiempo de optimización. Se obtienen los resultados. Como se puede apreciar en la Tabla 4.9, no se presentan variaciones significativas según el caso, ya que el tiempo de ciclo se mantiene, siendo aproximadamente igual a 10 ns; y el área está en torno a los 114 µm. La potencia en ninguno de los casos llega a 1 W. Área (µm2) Potencia (mW) Tiempo de ciclo (ns) Caso Típico 114.169,0695 47,0771 9,95 Mejor Caso 114.106,6095 102,7504 9,97 Peor Caso 113.876,9295 40,0152 9,96 Tabla 4.9: ASIC. Resultados obtenidos en la síntesis lógica. Diseño con wrapper En la tabla anterior se puede observar un incremento de aproximadamente 60 mW para el mejor caso respecto a los otros dos, que se corresponde con la menor frecuencia obtenida (100,3 MHz). Esto se debe a la potencia de pérdidas, ya que un aumento de la tensión de alimentación eleva significativamente el valor de las corrientes de fuga del transistor, y por consiguiente la potencia disipada por pérdidas. Potencia dinámica (mW) Potencia de pérdidas (mW) Caso Típico 41,021 6,056 Mejor Caso 53,008 49,709 Peor Caso 32,028 7,963 Tabla 4.10: Potencia dinámica y de pérdidas. Diseño con wrapper 105 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS 4.5.4.2. Síntesis lógica para FPGA El flujo de diseño de Synplify Premier permite obtener la implementación de la FPGA desde la entrada RTL en Verilog. Las etapas del mismo se explican a continuación: Se introducen los ficheros fuente, que serán los archivos RTL de la microarquitectura en Verilog obtenidos tras la síntesis de alto nivel. Se especifican los criterios de implementación, como la FPGA usada: Virtex5, Spartan6 o Zynq de la familia Xilinx. Además, se activan las siguientes opciones: •Disable I/O Insertion, impide la inserción de bloques de entrada/salida de la FPGA para las señales de entrada y salida del top del diseño. Esto se realiza cuando se está trabajando con bloques internos del diseño que permiten generar IPs para ser implementados en flujos más avanzados de la FPGA. •FSM Compiler, optimiza las máquinas de estado siguiendo una estrategia diferente de codificación de estados en función del número de estos. •Resource Sharing, comparte recursos con el fin de reducir el consumo de los recursos del dispositivo. •Pipelining, permite que varias operaciones se realicen a la vez sobre el mismo recurso, partiendo dicha ejecución en etapas, donde cada dato se encuentra en una de ellas. •Enable Advanced LUT Combining, prepara el netlist (fichero que describe la conectividad del diseño) de salida para una posterior combinación de LUTs en los diseños. Se añaden las restricciones de tiempo si las hubiera. En este caso se deja la opción por defecto, automático, ya que optimiza el diseño hasta obtener la máxima frecuencia. Se genera la síntesis. Se obtienen los resultados. El valor de la frecuencia de trabajo se supera tanto para la Virtex5 como para la Zynq, pues son FPGAs más avanzadas y por tanto, ofrecen mejores prestaciones. Sin embargo, la Spartan6 no llega a dicha frecuencia, así como en cuanto a la estimación de la ocupación del diseño en el dispositivo sobrepasa sus límites. 106 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.5. SÍNTESIS Registros BRAMs LUTs DSPs Frecuencia (MHz) Virtex5 63.287 11 71.780 14 122,6 Zynq 63.061 11 99.390 3 140,4 Spartan6 63.135 12 66.997 12 84,0 Tabla 4.11: FPGA. Resultados obtenidos en la síntesis lógica. Diseño con wrapper Figura 4.32: FPGA. Ocupación del diseño con wrapper tras la síntesis lógica Synplify Premiere ofrece la posibilidad de representar los diseños en dos vistas, RTL y tecnológica. En la primera no se muestran componentes específicos, sino genéricos como RAMs, puertas lógicas oflip-flops; mientras que en la segunda son las células básicas de la FPGA con la que se implementa el diseño. Esta vista, además, permite ver la ruta crítica. 107 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.6. IMPLEMENTACIÓN EN FPGA Figura 4.33: Vista RTL. Diseño original Figura 4.34: Esquema de la memoria 4.6. Implementación en FPGA El siguiente paso es realizar la implementación del diseño sobre las FPGAs elegidas. Se utilizarán las herramientas avanzadas de Xilinx, tanto PlanAhead como Vivado. 108 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.6. IMPLEMENTACIÓN EN FPGA Figura 4.35: Flujo de diseño: últimas etapas Para la implementación del sistema en la FPGA Zynq se utilizó el entorno de trabajo Vivado, que como ya se comentó en la presentación de las herrramientas en el Capítulo 3, en este proyecto este se usa bajo la interfaz de usuario de Synplify Premier. Una vez completada la síntesis lógica, tan solo se debe añadir la opción de Place & Route al diseño sintetizado y se genera la síntesis física. Mientras que para las FPGAs Spartan6 y Virtex5 PlanAhead de Xilinx es el entorno de diseño, que a partir de un fichero de tipo netlist implementa el diseño en el dispositivo que se le indique, proporcionando informes de los recursos utilizados así como de la frecuencia de funcionamiento. El flujo de diseño es el siguiente: Se crea el proyecto. Se indica la etapa de diseño desde la que se parte, siendo en este caso de ficheros que ya están sintetizados (EDIF); y se selecciona el dispositivo para trabajar. 109 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.6. IMPLEMENTACIÓN EN FPGA Figura 4.36: Selección del dispositivo. Ejemplo Virtex5 Se añade el fichero fuente (EDIF) obtenido en Synopsys Synplify Premier. Se introduce el fichero de restricciones del usuario (UCF), también generado por Synopsys Synplify Premier. Se elige la estrategia. PlanAhead ofrece la posibilidad de lanzar varias implementaciones con diferentes estrategias para luego poder optar por aquella que dé un mejor comportamiento temporal. Además, permite poder ejecutar en paralelo dichas estrategias, reduciendo así los tiempos de síntesis. Figura 4.37: Elección de la estrategia Se genera la síntesis. Se obtienen los resultados. Con el fin de poder tener una mejor visión de estos también se recogen los datos conseguidos con Vivado. 110 CAPÍTULO 4. MODELADO TLM CON WRAPPER 4.6. IMPLEMENTACIÓN EN FPGA Mientras que para la Spartan6 no se puede realizar la implementación, para las otras dos FPGAs los valores estimados en la síntesis lógica se mantienen, solo desciende el número de BRAMs finalmente implementadas. En cuanto a la frecuencia de funcionamiento desciende para el caso del dispositivo Virtex5 y aumenta para la Zynq. Figura 4.38: Spartan6. Error de implementación Para obtener la potencia y poder realizar un análisis de la misma de un diseño implementado, por un lado para la FPGA Virtex5, PlanAhead cuenta con la herramienta XPower Analyzer (XPA). Mientras que para la FPGA Zynq, Xilinx pone a disposición del diseñador Xilinx Power Estimator (XPE). Registros BRAMs LUTs DSPs Frecuencia (MHz) Potencia (W) Virtex5 63.287 7 71.829 14 72,595 4,407 Zynq 63.061 6 99.195 3 165,399 1,782 Tabla 4.12: FPGA. Resultados obtenidos en la síntesis física. Diseño con wrapper Esta herramienta permite visualizar el dispositivo y resalta con otro color el diseño, de manera que se pueda observar la ubicación del mismo. 111 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.2. MODELADO A NIVEL DE TRANSACCIONES 5.2. Modelado a nivel de transacciones El esquema de ficheros se mantiene como el diagrama inicial (Figura 4.1), cambiando el sc_main por el usado en el wrapper. sc_clock clk (clk, 10, SC_NS, 0.5, 0.0, SC_PS); sc_signal<bool>rst_n ; sc_signal<bool>start ; sc_signal<bool>finish ; sc_signal<bool>ready ; ... // Instantiate FIFOs tlm_fifo< sc_uint<64> >h_control_fifo(h_control_fifo) ; tlm_fifo< sc_int<9> >i_trans_fifo(i_trans_fifo) ; tlm_fifo< sc_uint<8> >unfiltered_fifo(unfiltered_fifo) ; tlm_fifo< sc_int<10> >h_control_vector_fifo(h_control_vector_fifo) ; tlm_fifo< sc_int<10> >d_filter_vector_fifo(d_filter_vector_fifo) ; tlm_fifo< sc_uint<34> >dma_fifo(dma_fifo) ; tlm_fifo< sc_uint<8> >mem_fifo(mem_fifo) ; Tanto la declaración de las interfaces y los puertos como la definición de las funciones y los procesos del wrapper se trasladan a los ficheros inter_p_if.h ytestbench.h. Por último, para implementar TLM se reescriben las interfaces incluidas en los archivos de definición testbench.cpp yinter_p_if.cpp, donde se pasa de read() y write() a get() y put() de TLM, respectivamente; y se establece un protocolo de comunicación a nivel puramente TLM, sin necesidad del handshake de señalización indicado en capítulos anteriores. A continuación se muestra el código correspondiente a la interfaz ( h_control_interface_data ): 118 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.3. VERIFICACIÓN FUNCIONAL while (h_control_interface_validate.read() == true) { write_h_control_word(k, h_control_interface_data.read()) ; k++ ; wait() ; } for (int i=0; i<11; i++) { h_control_data = h_contro_data_tlm->get() ; write_h_control_word(k, h_control_data) ; k++ ; wait() ; } 5.3. Verificación funcional Para comprobar el correcto funcionamiento del sistema tras el modelado TLM se realiza la verificación funcional, simulando el diseño con la herramienta de Cadence, SimVision, Figura 5.2. Como el wrapper introducía un retardo en el sistema, se han añadido dos marcadores (TimeA y TimeB) con el fin de ver qué ocurre con el mismo tras la implementación TLM del módulo inter_p. Comparando la Figura 5.3 con la simulación del sistema original, no solo no introduce retardo sino que el sistema es más rápido que el diseño de referencia. 119 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.3. VERIFICACIÓN FUNCIONAL Figura 5.2: Verificación funcional tras la implementación TLM (1) 120 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.3. VERIFICACIÓN FUNCIONAL Figura 5.3: Verificación funcional tras la implementación TLM (2) 121 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.4. SÍNTESIS 5.4. Síntesis Una vez modelado el sistema, y tras haber comprobado que es funcionalmente correcto, se procede a efectuar la síntesis, donde se mantendrán las consideraciones previas de la misma del Capítulo 4. 5.4.1. Síntesis de alto nivel Nuevamente, para la síntesis de alto nivel se debe añadir una interfaz de reset en todos los procesos: SC_THREAD (memory_process); sensitive clk.pos() ; reset_signal_is (rst_n, false); void inter_p_wrapper::memory_process() { // Reset #if defined(__CTOS__) || defined(CTOS_MODEL) dma_data_tlm->reset_put(); mem_data_tlm->reset_put(); #endif ... Las configuraciones, resoluciones, etc. indicadas en el flujo de diseño del CtoS son iguales que para el wrapper. Una vez se obtienen los modelos sintetizables se pueden realizar los primeros análisis. En las siguientes imágenes se puede observar un slack positivo para los dos dispositivos, ASIC y FPGA, lo que implica que la frecuencia de trabajo propuesta (100 MHz) es adecuada para el diseño en ambos casos, mientras que para la descripción basada en wrapper se obtiene un slack negativo para FPGA habiendo usado la misma frecuencia. 122 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.4. SÍNTESIS Figura 5.4: ASIC. Análisis de ciclos Figura 5.5: FPGA. Análisis de ciclos La funcionalidad de los modelos sintetizables obtenidos debe continuar siendo la misma que la del diseño original. Por lo que en este punto habrá que efectuar la verificación RTL. En las siguientes figuras se muestra una captura de las simulaciones llevadas a cabo tanto para ASIC como para FPGA. Comparándolas con la del diseño de referencia se puede verificar que el modelo es funcionalmente correcto. 123 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.4. SÍNTESIS Figura 5.6: ASIC. Verificación RTL 124 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.4. SÍNTESIS Figura 5.7: FPGA. Verificación RTL 125 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.4. SÍNTESIS 5.4.2. Síntesis lógica El flujo de diseño utilizado, tanto para el ASIC como para FPGA, es el mismo que se ha explicado con anterioridad, manteniendo las mismas restricciones. En el caso del ASIC, el tiempo de ciclo es de 10 ns y el área disminuye, siendo de 80 µm. La potencia también se reduce, continuando por debajo de 1 W; y se mantiene la mayor disipación de potencia con la menor frecuencia obtenida. Área (µm2) Potencia (mW) Tiempo de ciclo (ns) Caso Típico 80.442,613 37,598 9,95 Mejor Caso 80.371,045 81,578 9,99 Peor Caso 80.368,633 31,809 9,96 Tabla 5.1: ASIC. Resultados obtenidos en la síntesis lógica. Diseño TLM Potencia dinámica (mW) Potencia de pérdidas (mW) Caso Típico 32,949 4,615 Mejor Caso 42,571 38,994 Peor Caso 25,798 5,994 Tabla 5.2: Potencia dinámica y de pérdidas. Diseño TLM Por otro lado, el número de registros y LUTs utilizados en las FPGAs presenta mejores resultados, debidos a la eliminación de la necesidad de almacenar los datos localmente. La frecuencia de trabajo es mayor a la propuesta tanto para la Virtex5 como para la Zynq, mientras que la Spartan6 no llega a dicha frecuencia y además, el límite de LUTs lo vuelve a superar. 126 CAPÍTULO 5. MODELADO TLM DE LA INTERFAZ 5.5. IMPLEMENTACIÓN EN FPGA Registros BRAMs LUTs DSPs Frecuencia (MHz) Virtex5 8.180 11 14.783 14 131,1 Zynq 7.585 11 15.937 3 130,9 Spartan6 7.558 12 14.613 12 84,2 Tabla 5.3: FPGA. Resultados obtenidos en la síntesis lógica. Diseño TLM Figura 5.8: Ocupación del diseño TLM 5.5. Implementación en FPGA Las especificaciones del flujo de diseño seguido por PlanAhead y Vivado se mantienen. Registros BRAMs LUTs DSPs Frecuencia (MHz) Potencia (W) Virtex5 7.998 7 12.624 14 115,354 2,932 Zynq 7.585 6 15.831 3 153,420 0,540 Tabla 5.4: FPGA. Resultados obtenidos en la síntesis física. Diseño TLM 127