Aportaciones a la metodología de diseño basada en Síntesis de Alto Nivel. Aportaciones al diseño de IPs para procesado de eventos complejos y codificación de vídeo

Tesis Doctoral Aportaciones a la metodología de diseño basada en Síntesis de Alto Nivel. Aplicaciones al diseño de IPs para procesado de eventos complejos y codificación de vídeo Pedro Francisco Pérez Carballo Noviembre 2015 Las Palmas de Gran Canaria D. ROBERTO ESPER-CHAíN FALCÓN, SECRETARIO DEL DEPARTAMENTO DE INGENIERíA ELECTRÓNICA Y AUTOMÁTICA DE LA UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA, CERTIFICA, Que el Consejo de Doctores del Departamento en su sesión de fecha 17 de noviembre de 2015, tomó el acuerdo de dar el consentimiento para su tramitación, a la tesis doctoral titulada "Aportaciones a la metodología de diseño basada en síntesis de alto nivel. Aplicaciones al diseño de IPs para procesado de eventos complejos y codificación de vídeo" presentada por el doctorando D. Pedro Francisco Pérez Carballo y dirigida por el Doctor D. Antonio Núñez Ordóñez y para que así conste, y a efectos de lo previsto en el ArtO 6 del Reglamento para la elaboración, defensa, tribunal y evaluación de tesis doctorales de la Universidad de Las Palmas de Gran Canaria, firmo la presente en Las Palmas de Gran Canaria, a 17 de noviembre de dos mil quince. NIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Departamento de Ingeniería de Electrónica y Automática (OlEA) Programa de Doctorado en Ingeniería de Telecomunicación Avanzada Título de la Tesis: Aportaciones a la metodología de diseño basada en Síntesis de Alto Nivel. Aplicaciones al diseño de IPs para procesado de eventos complejos y codificación de vídeo Tesis doctoral presentada por D. Pedro Francisco Pérez Carballo Dirigida por el Dr. D. Antonio Núñez Ordóñez Las Palmas de Gran Canaria, 12 de noviembre de 2015 El Director - El Doctorando . • Fdo.: Dr. D. Antonio Núñez Ordóñez D. Pedro Francisco Pérez Carballo UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Tesis Doctoral Aportaciones a la metodología de diseño basada en Síntesis de Alto Nivel. Aplicaciones al diseño de IPs para procesado de eventos complejos y codificación de vídeo Pedro Pérez Carballo Las Palmas de Gran Canaria, noviembre de 2015 iv Resumen Ya en los años 90 se adoptaron técnicas de diseño RTL, en las que los lenguajes de descripción de hardware (VHDL/Verilog) y la síntesis lógica desde RTL han contribuido a reducir la complejidad asociada a los problemas complejos. En la actualidad hay consenso en la comunidad científica internacional en el campo de Tecnología del Diseño en que es necesario subir el nivel de abstracción en la especificación del sistema para poder realmente aprovechar eficientemente el número de transistores disponibles. Más aún, ese nuevo nivel de abstracción es necesario para cubrir la brecha entre la creciente complejidad de los algoritmos y la gran densidad de transistores disponible. El problema planteado es el de obtener métodos y mejores prácticas que contribuyan a la eficiencia y productividad de la tecnología de diseño. Se trata de poder manejar ese muy elevado número de transistores de forma inteligente. La adopción de descripciones a nivel algorítmico y a nivel de sistema permite al diseñador centrar su atención en la funcionalidad y en la organización de la arquitectura del sistema y dejar a procedimientos automáticos guiados los detalles de la implementación. Sin embargo la excesiva automatización pretendida no siempre conduce a soluciones eficientes. La síntesis desde el nivel sistema o ESL es un campo en evolución y busca métodos para obtener implementaciones eficientes. ESL está demostrando su potencial en la exploración del espacio de diseño a nivel sistema buscando una correspondencia adecuada con el espacio de arquitecturas disponibles, pero está encontrando limitaciones en los intentos de convertir los flujos ESL en flujos de síntesis e implementación final. Un recurso disponible para ESL es la descomposición en algoritmos y la aplicación de SAN en el paradigma antes descrito de síntesis de aceleradores hardware. Esta tesis se desarrolla en este escenario, y en este recurso metodológico de la descomposición del sistema en algoritmos como técnica de reducción de la magnitud del problema. Aquí la síntesis de alto nivel juega un papel central al permitir generar implementaciones RTL controladas y verdaderamente adaptadas a las condiciones de la aplicación. Si es importante en la productividad del diseño la reutilización de implementaciones hardware como bloques Intellectual Property (IPs), la SAN permite además introducir el concepto análogo de reutilización a nivel algorítmico. Para lograrlo ha sido un avance clave la introducción del modelado TLM al nivel de transacciones, ya que permite abordar por separado la implementación de la funcionalidad y de las interfaces. Esta estructuración del diseño está conduciendo a implementaciones más eficientes, dentro de un uso inteligente de los flujos de síntesis, y de un uso controlado y verificable de los resultados intermedios del proceso de síntesis. La utilización de lenguajes de alto nivel, tales como C/C++ y SystemC, permiten reducir la distancia semántica entre la descripción algorítmica y su implementación hardware. Sin embargo esta transformación requiere tener un conocimiento de las principales características de la tecnología de implementación para obtener la calidad deseable en los resultados finales, medida en términos de prestaciones (latencia y tiempo de ejecución), potencia y área (PPA), y en término de esfuerzo (tiempo y costo) de diseño. II. Aportaciones 1. Esta tesis aporta en primer lugar un estudio de las diferentes opciones existentes para la realización de la síntesis de alto nivel. Este estudio está acompañado de la experiencia de diseño del autor en el seno del equipo de investigación en EDA en el IUMA. La tesis aporta un conjunto de recomendaciones probadas para el flujo de diseño mediante SAN, v Resum en Resumen organizadas en un conjunto de principios que hemos consolidado en numerosos diseños, un conjunto de ideas prácticas experimentales en el uso de las herramientas del flujo de diseño, y finalmente un flujo de síntesis que se ha contrastado cuantitativamente en esos diseños. 2. La tesis aporta en segundo lugar la implementación en FPGA y en ASIC de dos aplicaciones de aceleración hardware distantes entre sí, como casos de uso del flujo de síntesis establecido y como cuantificación, contraste y criba de las recomendaciones realizadas y obtención de recomendaciones y estrategias adicionales. a. En el primero de los casos se trata de una aplicación para el procesado de eventos complejos. Es una aplicación dominada por el flujo del control, es decir por la aplicación de numerosas reglas de decisión fuertemente entrelazadas y condicionadas, a partir de datos que llegan en ritmos exigentes para el procesado en tiempo real. b. En el segundo caso se trata de un filtro de bucle adaptativo para la decodificación de vídeo siguiendo el estándar H.264/AVC-SVC. Este bloque es de nuevo un bloque complejo y cuello de botella en la implementación de códec hardware del estándar. Es una aplicación dominada por el flujo de los datos e intensiva en procesamiento y en uso de memoria. c. Para ambos casos se ha utilizado el flujo SAN aportado en la primera parte. En este flujo se parte de SystemC como lenguaje de especificación. La descripción en SystemC se obtiene transformando y descomponiendo la especificación algorítmica de entrada. Se aplica SAN a esta descomposición y se guía la síntesis asegurando la verificabilidad de cada etapa. d. Para ambos problemas de referencia se ha realizado una implementación FPGA sobre una plataforma basada en un dispositivo Xilinx Virtex-5 FX, que incluye procesadores PowerPC440. Igualmente se ha realizado la implementación de ambos problemas en un IP ASIC. Para cada problema y para cada tecnología objetivo se ha seguido el flujo SAN establecido. Esta experimentación ha permitido refinar el flujo SAN utilizado y formular nuevas aportaciones sobre mejores prácticas de diseño y nuevas recomendaciones. Los resultados han sido comparados con el estado del arte y con resultados generados por otros flujos de diseño y otros enfoques. 3. Durante el desarrollo de este trabajo de investigación se han creado experiencias de uso que reflejan la necesidad de una integración vertical y sin costuras de los flujos de diseño para poder obtener una convergencia de los aspectos temporales. Obtener esta convergencia temporal se identifica como uno de los principales retos de la nueva generación de herramientas de síntesis de alto nivel. Se aportan orientaciones para explotar los recursos disponibles en las herramientas para lograr convergencia temporal. 4. Se ha observado la necesidad de mantener el nivel RTL como punto clave de la verificación del sistema, especialmente para la síntesis a partir de C/C++ donde no se dispone de información temporal ni de estructura del modelo, ya que solo el nivel RTL dispone de la información precisa necesaria tanto a nivel de precisión de ciclos de bus como de precisión vi Resumen de bits y pines, para validar la implementación realizada durante la fase de síntesis de alto nivel. 5. Igualmente se han evaluado otros aspectos claves que afectan a la implementación del sistema, como puede ser la organización del modelo en cuanto a partición y jerarquía, la arquitectura de la memoria y la estructura de los datos. Igualmente se han tenido en cuenta aspectos relacionados con la ejecución paralela de funciones y bucles, y el control de los protocolos de comunicación. 6. El flujo de SAN para el diseño se ha organizado teniendo en cuenta los requisitos de integridad de los datos y facilidad de uso, requeridos para cubrir la brecha entre la poca productividad de los flujos de diseño y la productividad de la gran densidad de transistores disponible. La utilización de scripts basados en Tcl ha permitido definir estrategias de uso para cada caso concreto lo que facilita la reproducibilidad de resultados, y su portabilidad a distintas tecnologías. Todos los resultados se aportan como contribuciones a la creación de flujos SAN eficientes para diseños complejos. Abstract The increased capacity for circuit integration in semiconductor technology has brought about an increase in the complexity of electronic systems and therefore in their design. This integration capability has helped to address new problems requiring high computing capacity with ever reduced energy costs. Currently, the use of heterogeneous systems are a generalized solution. These hardware accelerators are adapted to the problem to be addressed in order to achieve results within acceptable response times. In these cases, high-level synthesis (HLS) can play a central role. In the 90s, RTL techniques were adopted, including hardware description languages (VHDL/Verilog) and logic synthesis. They have helped to reduce the complexity associated with these designs. At the present time the design community has established the need to raise the level of abstraction in the system specification, in order to take advantage of the number of transistors available. The adoption of algorithmic descriptions and system level descriptions viii Abstract allows the designer to focus on the functionality and architecture of the system, and leave to guided automatic procedures the details of its implementation. This thesis is developed in this scenario, where high-level synthesis plays a central role, generating RTL implementations adapted to the conditions of the application. This introduces the concept of IP reuse at algorithmic level. The introduction of transaction level modelling (TLM) is key to this approach, separating implementation of functionality from interfaces. The use of high-level languages, such as C/C++ and SystemC, reduces the gap between the algorithmic description and hardware implementation. However the transformations required to have a knowledge of the main features of the implementation technology for a desirable quality of results in terms of performance (latency and throughput), power and area (PPA), and design effort (time and cost). This thesis, after a study of the different options for performing high-level synthesis, in which the main contributions are indicated, presents a design flow based on high-level synthesis for hardware accelerators, and it is validated using two applications belonging to opposite application domains (control driven and dataflow driven). The first one is an application for complex event processing. The second, a deblocking filter for H.264/AVC-SVC video decoder. In both cases, the high-level synthesis flow starts from a model done in SystemC language, obtained from the transformation of algorithmic specification, and applying the HLS flow established. For both problems we have targeted FPGA implementations of a platform based on a Xilinx Virtex-5 FX device, including a PowerPC440 Hard IP, as well as IP ASIC implementations. During the development of this research work, we have captured and extracted user experiences that reflect the need for a seamless vertical integration of the design flows to obtain a proper timing closure for performance, as well as a reduction in time and effort in the design cost. It is also applicable to objectives of power and area. This vertical integration is currently one of the main challenges of the new generation tools in high-level synthesis. We observed the need to maintain the RTL level as a key point of the HSL and verification flow, especially for the synthesis from C/C++, where no temporal information nor model structure is available yet. In a C/C++ description, the necessary details in terms of bus cycles and bit and pin accurate signals, only available at RTL level, are included during the high-level synthesis. Other key issues affecting the implementation of the system were also evaluated, as the organization of the model in terms of partition and hierarchy, memory architecture and structure of the data. The recommendations also take into account issues related to function and loop parallelization, and issues concerning control of the communication protocols. The HLS design flow is organized taking into account aspects of data integrity and ease of use as required to bridge the gap between Design productivity and Semiconductor productivity (transistors density). By using Tcl scripts it is possible to define strategies to reproduce the synthesis results. Índice de contenidos Capítulo 1. Introducción ........................................................................................................ 1 1.1. Planteamiento del problema ...................................................................................... 1 1.2. Motivación de la investigación ................................................................................... 8 1.3. Objetivos ................................................................................................................... 11 1.4. Organización de la tesis doctoral .............................................................................. 13 Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas ......................... 17 2.1. Introducción .............................................................................................................. 17 2.2. Conceptos establecidos en síntesis de alto nivel ...................................................... 19 2.3. Visión de la evolución de la síntesis y experiencia previa ........................................ 23 2.4. Situación actual en SAN ............................................................................................ 33 2.4.1. Calypto/Mentor Catapult ................................................................................... 34 2.4.2. Altera OpenCL .................................................................................................... 36 2.4.3. Xilinx Vivado HLS ................................................................................................ 39 2.4.4. C-to-Silicon (CtoS) .............................................................................................. 43 x Índice de contenidos Índice de contenidos 2.4.5. Otros entornos de síntesis de alto nivel ............................................................. 45 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse ....................... 46 2.5.1. Lenguajes para SAN ............................................................................................ 47 2.5.2. Verificación del diseño a sintetizar ..................................................................... 51 2.5.3. Plataformas heterogéneas personalizadas ........................................................ 53 2.5.4. Convergencia temporal y calidad de los resultados ........................................... 54 2.6. Reflexiones sobre los mejores flujos y prácticas en SAN ......................................... 55 2.7. Conclusiones ............................................................................................................. 61 Capítulo 3. Caso de aplicación: diseño de un procesador de eventos ................................ 65 3.1. Introducción .............................................................................................................. 65 3.1.1. Sistema de eventos complejos ........................................................................... 66 3.2. Sistemas en Tiempo Real (STR) ................................................................................. 66 3.3. Alternativas de implementación ............................................................................... 68 3.4. Arquitectura de los procesadores de eventos .......................................................... 69 3.5. Aplicación de referencia............................................................................................ 72 3.6. Requerimientos del sistema ...................................................................................... 74 3.7. Soluciones arquitecturales ........................................................................................ 75 3.7.1. Arquitectura basada en núcleos de tipo soft-processor integrados .................. 75 3.7.2. Arquitectura de implementación hardware....................................................... 75 3.7.3. Arquitectura de implementación híbrida ........................................................... 76 3.7.4. Comparativa entre arquitecturas ....................................................................... 77 3.8. Paradigma de modelado ........................................................................................... 78 3.9. Metodología de diseño ............................................................................................. 80 3.9.1. Fase de análisis ................................................................................................... 81 3.9.2. Diseño del procesador de eventos ..................................................................... 81 3.9.3. Diseño de la plataforma ..................................................................................... 83 3.9.4. Verificación y validación del sistema .................................................................. 84 3.10. Síntesis del procesador de eventos......................................................................... 84 3.10.1. Criterios de optimización ................................................................................. 85 3.10.2. Estrategias de síntesis ...................................................................................... 85 3.10.3. Síntesis de alto nivel ......................................................................................... 86 3.10.3.1. Análisis de resultados ............................................................................... 91 3.11. Verificación RTL ....................................................................................................... 98 3.11.1. Diseño del testbench ........................................................................................ 99 3.11.2. Simulación del diseño ..................................................................................... 100 3.11.3. Interacción RTL-SystemC ................................................................................ 102 3.12. Implementación FPGA .......................................................................................... 106 xi Índice de contenidos Índice de contenidos 3.12.1. Síntesis lógica ................................................................................................. 106 3.12.2. Estrategias de síntesis lógica .......................................................................... 106 3.12.3. Opciones de síntesis ....................................................................................... 108 3.12.4. Resultados ...................................................................................................... 109 3.13. Implementación física y validación de la plataforma ........................................... 111 3.13.1. Plataforma de validación ............................................................................... 111 3.13.2. Validación ....................................................................................................... 118 3.14. Implementación ASIC ............................................................................................ 120 3.14.1. Tecnología elegida.......................................................................................... 120 3.14.2. Síntesis de alto nivel ....................................................................................... 121 3.14.3. Síntesis lógica ................................................................................................. 126 3.14.4. Implementación física .................................................................................... 131 3.15. Conclusiones ......................................................................................................... 135 Capítulo 4. Aplicación al diseño de un filtro de bucle adaptativo para H.264/AVC-SVC .. 139 4.1. Introducción ............................................................................................................ 139 4.2. Decodificador OpenSVC .......................................................................................... 140 4.3. Funcionalidad del DF ............................................................................................... 141 4.4. Arquitectura propuesta del DF ............................................................................... 144 4.5. Implementación FPGA ............................................................................................ 145 4.5.1. Arquitectura del DF .......................................................................................... 145 4.5.2. Interfaz LocalLink ............................................................................................. 146 4.5.2.1. Interfaz LocalLink de un bloque DMA ...................................................... 148 4.5.3. Flujo de diseño ................................................................................................. 149 4.5.3.1. Análisis del diseño .................................................................................... 149 4.5.3.2. Captura del diseño.................................................................................... 150 4.5.3.3. Simulación ESL .......................................................................................... 150 4.5.3.4. Síntesis de alto nivel ................................................................................. 150 4.5.3.5. Simulación RTL .......................................................................................... 153 4.5.3.6. Síntesis lógica ........................................................................................... 154 4.5.3.7. Validación del diseño ................................................................................ 155 4.5.4. Flujo de datos ................................................................................................... 157 4.5.5. Software empotrado ........................................................................................ 157 4.5.6. Resultados de síntesis ...................................................................................... 158 4.5.6.1. Plano de base de la FPGA ......................................................................... 158 4.5.6.2. Recursos FPGA .......................................................................................... 158 4.5.6.3. Rendimiento y frecuencia ........................................................................ 158 xii Índice de contenidos Índice de contenidos 4.5.6.4. Análisis del Consumo de potencia ............................................................ 160 4.5.7. Prototipado del sistema ................................................................................... 161 4.6. Implementación ASIC .............................................................................................. 161 4.6.1. Flujo de diseño ................................................................................................. 162 4.6.2. Resultados de síntesis ...................................................................................... 164 4.6.3. Implementación física ...................................................................................... 164 4.7. Conclusiones ........................................................................................................... 166 Capítulo 5. Conclusiones y líneas futuras .......................................................................... 167 5.1. Introducción ............................................................................................................ 167 5.2. Conclusiones ........................................................................................................... 168 5.2.1. Escenario .......................................................................................................... 168 5.2.2. Aportaciones .................................................................................................... 170 5.3. Líneas futuras .......................................................................................................... 172 Referencias ........................................................................................................................ 175 Índice de figuras Figura 1. Crecimiento de la capacidad de integración de un SOC según el ITRS ................... 3 Figura 2. Evolución de los costes del CI y del efecto de la introducción de las herramientas de diseño (adaptada de [6]) ........................................................... 3 Figura 3. Evolución de la capacidad de integración y del diseño (adaptada de [7]) .............. 4 Figura 4. Ejemplo de sistema de procesamiento heterogéneo (adaptada de [5] ) ............... 5 Figura 5. Diagrama en V del proceso de diseño electrónico (derivada de [7]) ...................... 6 Figura 6. Diseño basado en plataformas – PBD (adaptada de [17] ) .................................... 7 Figura 7. Reducción de los tiempos de búsqueda en la plataforma Bing de Microsoft (adaptada de [19]) ................................................................................................ 8 Figura 8. Flujo de síntesis del diseño ................................................................................... 12 Figura 9. Diagrama en Y ubicando la síntesis de alto nivel .................................................. 20 Figura 10. Flujo de síntesis de alto nivel .............................................................................. 21 Figura 11. Efecto de la SAN en la exploración del espacio del diseño ................................. 22 Figura 12. Breve evolución histórica de la síntesis de alto nivel.......................................... 23 Figura 13. Tabla de reservas ................................................................................................ 26 Figura 14. Calypto/Mentor Catapult HLS ............................................................................. 28 Figura 15. Flujo de diseño de Forte Cynthesizer .................................................................. 28 Figura 16. NEC Cyber Workbench (partnership con Aldec) ................................................. 29 xx Índice de acrónimos Índice de acrónimos ASIC Application-Specific Integrated Circuit ASM Algorithmic State Machine ASSP Application Specific Signal Processor AT Algorithmic Trading o Algo Trading AVC Advanced Video Coding AXI Advanced eXtensible Interface AXI3 Advanced eXtensible Interface versión 3 AXI4 Advanced eXtensible Interface versión 4 AXI4-LITE Advanced eXtensible Interface versión 4 modalidad Lite AXI4S Advanced eXtensible Interface versión 4 modalidad streaming B BC Behavioral Compiler BCA Bus Cycle Accurate BRAM Block RAM BS Boundary Strength BSV Bluespec SystemVerilog C CA Cycle Accurate CABA Cycle-Accurate Bit-Accurate CAD Computer Aided Design CDC Clock Domain Crossing CDFG Control Data Flow Graph CE Coprocesador de Eventos CF Compact Flash CHP Customizable Heterogenuos Platform CI Circuito Integrado CIF Common Intermediate Format CLB Configurable Logic Block CMOS Complementary Metal–Oxide–Semiconductor CMU Carnegie Mellon University CONLAN CONsensus LANGuage CPU Central Processing Unit CSELT Centro Studi e Laboratori Telecomunicazioni CtoS Cadence C-to-Silicon Compiler CX Ciclo aproXimado D DC Design Compiler DCR Device Control Register DCT Digital Cosine Transform DDR Double Data Rate DDR2 Double Data Rate segunda generación DF Deblocking Filter DHCP Dynamic Host Configuration Protocol DMA Direct Memory Access DPB Decoded Picture Buffer DSE Design Space Exploration xxi Índice de acrónimos DSP Digital Signal Processor DUT Device Under test DVFS Dynamic Voltage and Frequency Scaling DVI Digital Visual Interface E E/S Entrada/Salida EDA Electronic Design Automation EDIF Electronic Data Interchange Format EEUU Estados Unidos ELF Executable and Linkable Format EOF End Of Frame EOP End Of Payload EPLF Ecole Polytechnique Fédérale de Lausanne EPR Elementos de Procesamiento Reconfigurables ESL Electronic System Level F FF Flip-flops FFT Fast Fourier Transform FIFO First In, First Out FIR Finite Impulse Response FPGA Field Programmable Gate Array FSM Finite-State Machine FU Factor de Utilización G GaAs Gallium Arsenide GALS Globally Asyncronous Locally Synchronous GPGPU General Purpose computing on Graphics Processing Unit GPMC General Purpose Memory Controller GPP General Purpose Processor GPU Graphics Processing Unit GUI Graphical User Interface H HDL Hardware Description Language HLS High-Level Synthesis HPC High Performance Computing HTG Hierarchical Task Graph HW Hardware HW/SW Hardware/Software I ICMP Internet Control Message Protocol ICON Integrated Controller IDaSS Interactive Design and Simulation System IDE Integrated Development Environment IDEA International Data Encryption Algorithm IES Incisive Enterprise Simulator IETR Institut d'Électronique et de Télécommunications de Rennes xxii Índice de acrónimos Índice de acrónimos ILA In-Circuit Logic Analyzer ILP Instruction Level Paralelism IMEC Interuniversitair Micro-Elektronica Centrum IOB Input Output Block IoT Internet of Things IP Intellectual Property IR Intermediate Representation ISA Instruction Set Architecture ISO International Organization for Standardization ISP Instruction Set Processor ISPA Instruction Set Processor Architecture ISPL Instruction Set Processor Language ISPS Instruction Set Processor Specification ITRS International Technology Roadmap for Semiconductors IUMA Instituto Universitario de Microelectrónica Aplicada IUS Incisive Unified Simulator J JM Joint Model JTAG Joint Test Action Group K KARL Kaiserslautern Register Transfer Language L LAB Logic Array Block LEF Cadence Library Exchange Format LIS Latency Insensitivy System LL Low Leakage LLVM Low-Level Virtual Machine LSI EPFL Laboratoire des Systèmes Intégrés LUT LookUp Table M M1 Metal 1 MAC Multiplicación/Acumulación MB Macro Bloque MCI Memory Controller Interface MIPS Microprocessor without Interlocked Pipeline Stages MMU Memory Management Unit MPI Message-Passing Interface Standard MPI-3 Message-Passing Interface Standard versión 3.0 MPLB Master PLB MPSoC Multiprocessor System-on-Chip MPU Microprocessor Unit N NASDAQ National Association of Securities Dealers Automated Quotations NCD Xilinx Native Circuit Description NEC Nippon Electric Company NGC Xilinx Netlist Native Generic Compiler xxiii Índice de acrónimos O OMAP Texas Instruments Open Multimedia Applications Platform OpenMP OpenMP API OpenSVC Open Scalable Video Coding OSCI Open SystemC Initiative OSI Open System Interconnection P P&R Placement and Routing PA Pin Accurate PB Picture Buffer PCAP Packet CAPture PCCMUTE Power Consumption Control in MUltimedia Terminals PDP Programmed Data Processor PLB Processor Local Bus PMS Processor Memory Switch PPA Prestaciones, Potencia, Área Q QCIF Quarter CIF QoE Quality Of Experience QoR Quality of Results R RAL Rutherford Appleton Laboratory RAM Random Access Memory RAMB BRAM RC RTL Compiler RGB Red Green Blue RMM Reuse Methodology Manual ROCCC Riverside Optimizing Compiler for Configurable Circuits RT Real Time RT-CORE Real Time - Core RTL Register Transfer Level S SAN Síntesis de Alto Nivel SDC Synopsys Desing Constraints SDK Software Developer Kit SDRAM Synchronous Dynamic Random-Access Memory SIF Synthesis Internal Format SIMD Single Instruction Multiple Data SL Síntesis Lógica SLEC Sequential Logic Equivalence Checking SoC System-on-Chip SOP Start Of Payload SP Standard Performance SPICE Simulation Program with Integrated Circuit Emphasis SPLB Slave Processor Local Bus SPMD Single Program Multiple Data xxiv Índice de acrónimos Índice de acrónimos SRAM Static Random Access Memory SRFF Synchronous Reset Flip Flop STH Servicio de Tecnologías y Herramientas del IUMA STR Sistemas en Tiempo Real SVC Scalable Video Coding SW Software T Tcl Tool Command Language TCP/IP Transmission Control Protocol/Internet Protocol TEMAC Tri-mode Ethernet MAC TFT Thin-Film Transistor TIC Tecnologías de la Información y las Comunicaciones TLF Timing Library Format TLM Transaction-Level Modeling TPB Temporal Picture Buffer TRS Term Rewriting System TTM Time To Market U UART Universal Asynchronous Receiver-Transmitter UMC United Microelectronics Corporation USB Universal Serial Bus V VCD Value Change Dump VCS Verilog Compiled Simulator VHDL Very High Speed Integrated Circuit Hardware Description Language VLSI Very-large Scale Integration VP Virtual Prototype X XML eXtensible Markup Language XPS Xilinx Platform Studio XST Xilinx Synthesis Technology Y YUV YUV Color Space Capítulo 1. Introducción 1.1. Planteamiento del problema La necesidad de cómputo seguirá creciendo en los próximos años para resolver problemas de procesamiento complejos que hasta ahora no se han podido solucionar. Entre ellos se encuentran el estudio del clima y sus modelos, la gestión de las redes de energía, la variación del genoma humano, la astrofísica, la dinámica de los océanos o la gestión del tráfico en las grandes ciudades [1]. Otra clase de grandes problemas actuales deriva del incremento del número de dispositivos con conectividad a internet mediante conexiones inalámbricas, que crece a un 30% de tasa interanual hasta alcanzar 4.900 millones de dispositivos en 2015 y del orden de 25.000 millones en 2020 según un estudio realizado por Gartner [2] en lo que se denomina de forma genérica Internet de la cosas (IoT). En ambas clases, ya sea por los propios modelos de cada sistema o por sus interacciones, se genera un volumen importante de datos cuyo procesamiento requiere sistemas electrónicos de computación adaptados al problema en cuestión y sistemas de comunicación especializados. La red europea de excelencia High Performance and Embedded Architecture and Compilation (HiPEAC) [3] en su propia denominación y en su serie de estudios sobre la hoja de ruta previsible en ese campo, señala los 2 Capítul o 1. Introducció n Capítulo 1. Introducción desafíos que se afrontan. Con frecuencia tanto el diseño de sistemas para computación de altas prestaciones como para sistemas empotrados necesitan incluir circuitos específicos o aceleradores. La consecuencia directa que afecta a las metodologías de diseño es disponer de métodos y herramientas que sean capaces de abordar estas necesidades. Uno de los factores que afectan al coste de un sistema electrónico es su tiempo de desarrollo debido, por una parte, a la naturaleza de los productos obtenidos y, por otra, a los estrictos plazos que impone el mercado. En este sentido existen numerosas iniciativas tanto en la industria como en los centros de investigación y en la Academia que tratan de acortar el tiempo de diseño aumentando el nivel de abstracción y paralelizando tareas durante su desarrollo. A lo largo del tiempo se ha ido elevando el paradigma de modelado pasando desde la captura del layout (geometrías), al modelo eléctrico de transistores y puertas lógicas, a la transferencia entre registros, y hasta puros modelos funcionales o de comportamiento. La abstracción del diseño se ha demostrado como uno de los métodos más efectivos para controlar la complejidad y aumentar la productividad. Por ejemplo para un diseño de 1M de puertas se requieren unas 300K líneas de código RTL frente a las 30K-40K de un diseño modelado a nivel de comportamiento en C, C++ o SystemC. Esto supone una reducción de 7x-10X [4]. Este tipo de alternativas aprovechan mejor la gran capacidad de integración en silicio disponible. La tendencia actual es integrar en un único sistema en chip (SoC) la mayor funcionalidad posible, debida a esa capacidad del silicio. La integración en un solo chip de tanta funcionalidad tiene limitaciones por la potencia que es posible disipar. Esta dependencia es cuadrática con la tensión y lineal con la frecuencia de operación. El aumento de prestaciones viene entonces dado no por un mayor aumento de la frecuencia de operación sino por la paralelización de los procesos de cómputo. En la figura 1 se muestra la tendencia de los modelos predictivos del International Technology Roadmap for Semiconductors (ITRS) [5] sobre la complejidad de los sistemas en cuanto a elementos de procesamiento, memoria y lógica incluida. Como se aprecia la tendencia es hacia un crecimiento exponencial en todos los aspectos citados. En este caso se trata de datos para productos portables, pero la tendencia indicada es similar en otros campos. Todo este proceso de integración lleva consigo un incremento de coste de los proyectos que ha sido modelado por el IRTS [5]. Como se aprecia en la figura 2, el coste del diseño ha ido creciendo de forma significativa a lo largo del tiempo. Igualmente se muestra el efecto de la introducción de las diferentes herramientas CAD de diseño sobre el modelo de costes del SoC. Diferentes propuestas metodologías, fruto del trabajo de investigación en herramientas y métodos de automatización del diseño electrónico (EDA), han ido introduciendo cambios que han aportado puntos de inflexión y avances significativos en los flujos de diseño hacia una disminución de esos costes derivados del incremento de complejidad del diseño. En la figura 2 se resaltan en líneas verticales las novedades más significativas en tecnologías de diseño y su efecto de disminución del coste. Junto con las herramientas CAD es cada vez más necesario considerar el creciente papel del software empotrado en el SOC final (figura 3). La disponibilidad de núcleos procesadores, procesadores programables, y gran cantidad de memoria disponible en los SoC, reclama ahora la gestión del software en los SoC. Es necesario por tanto introducir nuevos métodos de diseño que generen puntos de inflexión que frenen los costes. 3 1.1. Planteamie nto del problema 1.1. Planteamiento del problema Figura 1. Crecimiento de la capacidad de integración de un SOC según el ITRS Figura 2. Evolución de los costes del CI y del efecto de la introducción de las herramientas de diseño (adaptada de [6]) El impacto de la ley de Moore y su evolución hacia propuestas More Moore (más densidad FinFET/CMOS) y More than Moore (más funciones, incluso MEMS) hace que durante la fase del diseño del sistema y su exploración la diversidad funcional que se puede incluir en el diseño se incremente de forma notable, por lo que para manejarla es necesario introducir niveles de abstracción que hagan de puente entre los niveles muy altos, a nivel de requisitos, y aquellos otros cuya misión sea la implementación electrónica directa de un bloque funcional, como es 4 Capítul o 1. Introducció n Capítulo 1. Introducción por ejemplo el nivel RTL. La figura 3 muestra la gran brecha de diseño software que ha aparecido, y que se suma a la gran brecha existente entre la productividad del diseño hardware (herramientas CAD y diseño EDA) y la capacidad de integración. Figura 3. Evolución de la capacidad de integración y del diseño (adaptada de [7]) Ante este escenario ha surgido la integración de IPs específicos y memorias como medio de incrementar la productividad del diseño HW y reducir la brecha de diseño. Y la integración de más procesadores. Combinando ambas estrategias, los modelos de arquitectura de procesamiento que se proponen para la integración en un SoC son heterogéneos (figura 4), estando formados por uno o varios núcleos microprocesadores de propósito general, una unidad de E/S y un conjunto de elementos de procesamiento específico comunicados por un sistema de interconexión en chip que puede ser desde un simple bus, hasta una red conmutada en el chip, pasando por una arquitectura de interconexión con una variedad de buses en chip con capacidad de gestión de las transferencias [8][9]. Una consecuencia inmediata es la necesidad de crear diferentes esquemas de sincronización. El diseño de estos elementos de procesamiento con funcionalidad diferenciada se realiza a partir de su funcionalidad o algoritmo. La transformación de estos algoritmos se realiza mediante síntesis de alto nivel SAN, apoyándose en el modelado a nivel de transacciones TLM para obtener la implementación final del sistema. En el diagrama en V de la figura 5 se indica la ubicación de la síntesis de alto nivel en el flujo de síntesis, partiendo de la especificación del diseño. La SAN enlaza con el diseño más tradicional basado en RTL. Por encima de RTL se suele considerar el front-end del diseño. Por debajo de RTL estamos en las etapas del back-end. Esta tesis no realiza aportaciones en los niveles de síntesis ESL (ni de exploración del espacio de diseño a niveles aún superiores). Vamos a suponer que en esos niveles se han hecho ya las adecuadas particiones del problema en tareas y éstas en tareas HW y en tareas SW. Sin embargo respecto al back-end las aportaciones que se hacen en esta tesis en SAN conducen en muchos casos a señalar las consecuencias que se derivan para la síntesis lógica y la síntesis física, así como para la verificación. 5 1.1. Planteamie nto del problema 1.1. Planteamiento del problema Figura 4. Ejemplo de sistema de procesamiento heterogéneo (adaptada de [5] ) Hemos resaltado ya la necesidad de disponer de IPs que se modelen a nivel de comportamiento para mejorar la productividad de diseño HW. Este modelado a nivel comportamiento de los IPs hace que puedan adaptarse a diferentes casos de aplicación según las necesidades y aporta gran flexibilidad y productividad al proceso de diseño. EL nivel de reutilización de los IPs ahora se desplaza hacia una mayor abstracción que el nivel RTL, pero se requiere que todo este camino esté guiado por un conjunto de especificaciones y restricciones funcionales y de rendimiento, impuestas al diseño, acordes al nivel de abstracción, para obtener calidad en los resultados. El riesgo a evitar es perder la calidad natural de la síntesis RTL. Por esta razón todo el proceso de síntesis ahora ampliado al alto nivel debe ser acompañado de técnicas de verificación que permitan asegurar el correcto comportamiento funcional y temporal del sistema, tal como se describe en el esquema en V de la figura 5. En estos niveles de abstracción, con la introducción de uno o varios núcleos microprocesadores se aporta aún otro nivel más de flexibilidad a los sistemas mediante software empotrado, tal como se indicó en figura 3. Para desarrollar software empotrado de forma productiva se están desarrollando modelos de alto grado de abstracción del sistema, tales que permitan hacer prototipado virtual del sistema. Una plataforma virtual VP (o VSP) es un conjunto de modelos del sistema empotrado que facilita el desarrollo del software empotrado en etapas tempranas del diseño. En esta plataforma se separa el desarrollo del diseño hardware del diseño software mediante la correspondiente interfaz API, que facilite la iteración del software empotrado, primero con la plataforma virtual o modelo de simulación abstracto durante etapas tempranas de diseño, y después con la plataforma real, una vez se ha completado su diseño hardware. La metodología de prototipado virtual está fuera del alcance de esta tesis. El lector puede encontrar más información en prototipado virtual en [10]. 12 Capítul o 1. Introducció n Capítulo 1. Introducción Figura 8. Flujo de síntesis del diseño Este flujo de diseño debe ser validado. Una completa validación y crítica es la que provenga de su amplio uso. Sin embargo es necesario validarlo inicialmente. Al menos -tal y como se ha comentadocomo medio para enriquecer desde la experiencia de estos diseños adicionales la propuesta de mejores prácticas obtenidas a lo largo de los años y de los diseños realizados, así como del estudio de los casos de uso de las herramientas más avanzadas. Se ha aplicado el flujo de síntesis y las recomendaciones a dos casos de uso: aceleración de una aplicación de procesamiento de eventos complejos y una aplicación de decodificación de vídeo. Para ambos casos se establecen los principios de uso del flujo, directrices de síntesis y estrategias que faciliten el diseño y verificación del sistema. Por tanto se pretende cubrir los siguientes objetivos operativos: 13 1.4. Organizació n de la tesis doctoral 1.4. Organización de la tesis doctoral 1. Desde un punto de vista del modelado del sistema, definir las ideas generales de referencia con el suficiente grado de abstracción para facilitar su reutilización y reducción de los tiempos de desarrollo. Estas ideas están soportadas sobre lenguajes estandarizados y ampliamente aceptados tales como C/C++ y SystemC 2. Desde un punto de vista metodológico, establecer un conjunto de tareas y restricciones que permitan ofrecer una metodología de síntesis de alto nivel para la implementación en FPGA y ASIC/SoC a partir de descripciones algorítmicas en un lenguaje de alto nivel tal como los mencionados anteriormente. 3. Desde un punto de vista metodológico, propiciar la reutilización de bancos de test desde verificaciones algorítmicas hasta el nivel RTL, favoreciendo el incremento de la productividad y minimizando la posibilidad de errores introducidos por la intervención manual. En este mismo objetivo se tendrán en cuenta aspectos tales como las modificaciones temporales introducidas por la herramienta de SAN. 4. Identificar y establecer puntos singulares en el espacio de diseño, a tener en cuenta durante la implementación. Se trata de bloques que ofrecen discontinuidad en el espacio de soluciones (hard macros, memorias, bloques DSP). Identificar procedimientos y soluciones ya sean a medida o de tipo general. 5. Identificar y establecer mecanismos de continuidad en la transformación de restricciones de diseño desde alto nivel hasta restricciones de implementación física. 6. Establecer la metodología de análisis necesaria para comparar los resultados obtenidos, a diferentes niveles de abstracción, principalmente basados en parámetros PPA y latencias asociadas. Estos resultados se comparan al menos para dos implementaciones, una en FPGA y otra en ASIC. 7. Validación del flujo de diseño sobre demostrador para el caso de la implementación sobre FPGA. Y validación del flujo de diseño para ASIC/SoC en términos de timing closure y verificación post-layout (los circuitos ASIC no se fabrican por razones económicas). 1.4. Organización de la tesis doctoral El trabajo desarrollado en esta tesis doctoral se ha estructurado en cinco capítulos, tal como se describe a continuación: Capítulo 1. Introducción. Se presenta el planteamiento del problema que ha motivado la realización de esta tesis doctoral, se esbozan las soluciones que se van a desarrollar y se detallan los objetivos de la misma. Para ello se da una visión global de las necesidades de capacidad de diseño para abordar el diseño de sistemas en chip (SoC) necesarios para la solución de problemas complejos actuales, en el ámbito de soluciones heterogéneas, en las que se integran aceleradores hardware adaptables a diferentes dominios de aplicaciones (IoT, HPC, Vídeo...). Se presentan los métodos de diseño de alto nivel más amplios que SAN, y se centra 14 Capítul o 1. Introducció n Capítulo 1. Introducción el problema en la Síntesis de Alto Nivel (SAN) como la alternativa al diseño directo RTL. Se concreta el problema de la transformación algoritmo-RTL y se apunta el esquema de “Doble X” que se desarrolla en la tesis, introduciendo un primer punto intermedio de diseño TLM y un segundo punto intermedio RTL, en el camino hacia el hardware final. Se anticipan las ventajas en productividad del diseño, consistencia de la verificabilidad, flexibilidad, portabilidad, y reutilización no sólo como IP hardware sino también como IP a nivel de comportamiento. Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas. En este capítulo se da una visión global de la SAN, presentando la estructura general de toda herramienta de síntesis de alto nivel, un análisis de los hitos y las aportaciones consolidadas en la evolución histórica de las principales herramientas de SAN, juntamente con anotaciones de experiencias del autor, obtenidas durante su participación en diferentes proyectos y trabajos de investigación relacionadas con esta tesis doctoral. Igualmente se presentan los retos que deben abordar las herramientas de SAN para su total integración en el flujo de diseño, poniendo énfasis en su integración con la verificación del diseño y la calidad de los resultados obtenidos. A continuación se presenta una relación de mejores prácticas en flujos de síntesis de alto nivel, estructurada en principios, ideas prácticas, recomendaciones y estrategias generales. Ente estas estrategias y en el flujo de síntesis resultante se resalta el modelo “Doble X” que mantiene el nivel RTL e introduce el nivel TLM como puntos intermedios que ayudan eficientemente al progreso de la síntesis de los algoritmos. Se describen sus ventajas y los riesgos inherentes a otros flujos que intentan prescindir de estos puntos. El capítulo se cierra con un capítulo de conclusiones. Capítulo 3. Caso de aplicación: diseño de un procesador de eventos. Este es un capítulo central de la tesis donde se explica en detalle el proceso de síntesis de alto nivel, según el flujo propuesto y las recomendaciones aportadas, de un acelerador hardware para una aplicación de procesado de eventos desarrollada como parte de un proyecto más amplio realizado en el IUMA. Se explica la arquitectura de referencia, el flujo de diseño de SAN desarrollado, su conexión con flujos de implementación para FPGAs y se expande a la implementación hacia un ASIC. Se demuestra la validez del flujo explicado, integrando el IP obtenido en una plataforma FPGA y validando su diseño sobre una plataforma Xilinx ML-510 que incluye un dispositivo Virtex-5 FX, así como un ASIC en tecnología UMC CMOS 65nm. Capítulo 4. Aplicación al diseño de un filtro de bucle adaptativo para H.264/AVC-SVC. En este otro capítulo central de la tesis se extiende la validez de la metodología al diseño de un Deblocking Filter de un decodificador H.264/AVC-SVC desarrollado en el IUMA para el proyecto PCCMUTE. Igual que en el caso anterior, se valida la aplicación del flujo y la guía de mejores prácticas mediante 15 1.4. Organizació n de la tesis doctoral 1.4. Organización de la tesis doctoral la realización de un prototipo sobre una plataforma FPGA Xilinx ML507 que soporta un dispositivo Virtex-5 FX como en el caso anterior, y un ASIC en tecnología UMC CMOS 65nm. Capítulo 5. Conclusiones y trabajo futuro. Se presentan las conclusiones del trabajo de investigación y se enumeran posibles trabajos futuros que se han anotado como necesarios durante el desarrollo de esta tesis doctoral. Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas 2.1. Introducción El Diseño Electrónico es una tecnología, un método, unos procedimientos, unas herramientas y un arte. Es parte del proceso de creación intelectual, de concepción de una idea, y de cómo llevarla a la práctica mediante los principios físicos y procedimientos de ingeniería propios del campo. La Síntesis de Alto Nivel (SAN) ha aparecido en el camino de las innumerables experiencias de hacer diseños en la industria y la universidad, al ritmo de la evolución de las herramientas EDA y del reto de hacer posible el diseño abstrayendo la complejidad creciente de las implementaciones. Se trata de reducir las brechas entre la falta de productividad humana y la riqueza creciente que ha surgido por “arriba y por abajo en la escala de abstracción”, es decir tanto el crecimiento de riqueza y complejidad en la idea algorítmica, como el crecimiento del número de transistores disponibles en Silicio. 18 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas La expresión Estado del Arte se aplica en este contexto en su más directa acepción. Cómo está el arte actual del diseño, con qué herramientas se cuenta, qué aportaciones previas se han consolidado y se han establecido en herramientas actuales, qué aportaciones han fallado, cuáles son los retos pendientes, y qué lecciones ha aprendido la industria, es decir han aprendido los equipos de diseñadores durante el camino. Sin una visión evolutiva es muy difícil poder ver en las herramientas actuales tanto sus rasgos sobresalientes como sus carencias. En este capítulo pretendemos aportar esa visión evolutiva y critica desde la visión que el autor tiene como testigo de algunos aspectos de esa evolución. En virtud de esa experiencia acumulada, decantada, y de éste breve meta-estudio o estudio de estudios, se pretende poder aportar un conjunto de recomendaciones de método, recomendaciones y elecciones sobre el uso de herramientas, y aportaciones sobre las mejores prácticas elaboradas en el grupo y personalmente, en ese proceso de maduración en el arte del diseño en problemas complejos. Se presenta por tanto una visión del estado actual de las herramientas de síntesis de alto nivel y de las actividades de diseño asociadas. Se presentan igualmente los lenguajes utilizados para la captura, modelado y simulación de diseños, y el impacto de la elección del lenguaje en el estilo de síntesis y verificación a utilizar. Se hace especial énfasis en las características de las herramientas SAN de Synopsys (BC +DC), Cadence (CtoS, Cynthesizer, Stratus), Mentor Graphics (Catapult). Y se adopta la posición de contrastar las características destacadas en su comercialización técnica, con las características de la experiencia en el uso real, tanto directas como referenciadas. Para poder subrayar las características sobresalientes, aquellas consolidadas, y las deficiencias de las herramientas, en donde quede patente la potencialidad, la eficacia, y las mejores prácticas de la SAN, se elabora una visión evolutiva que trata de poner en contexto los avances obtenidos y el sentido de las recomendaciones que se hacen en esta tesis. Se presentan en primer lugar los conceptos establecidos en SAN (2.2), luego la visión evolutiva con la experiencia acumulada en el grupo y por el autor como diseñador y como consultor de muchos diseños realizados desde el STH del IUMA con una gran variedad de herramientas –lo que denominamos trabajo previo (2.3)– y también en las secciones sobre la situación actual en SAN y la hoja de ruta que puede preverse (2.4), dedicando una sección monográfica a los retos actuales de la SAN (2.5), campos objetos que están abiertos a la investigación. Con este punto de partida se hace una reflexión sobre los flujos de diseño y las mejores prácticas disponibles, y se aportan otras nuevas (2.6) que cierran el capítulo, resumiendo finalmente estas a modo de conclusiones. En los capítulos siguientes 3 y 4 se aplican estas mejores prácticas en cuanto al flujo a dos casos que tomamos como referencia, opuestos el uno al otro, para una vez más poner bajo escrutinio las recomendaciones y mejores prácticas y confirmar unas, desechar otras y aportar otras nuevas. Este escrutinio se hace apoyando las afirmaciones en las evidencias cuantitativas que arrojan los diseños, así como su comparativa con otros diseños o con la experiencia acumulada en los años de trabajo previo. El capítulo de conclusiones recoge el resultado de esta 19 2.2. Conceptos establecido s en síntesis de alto nivel 2.2. Conceptos establecidos en síntesis de alto nivel criba metodológica, la identificación de deficiencias y las propuestas de nuevos avances. En fin se dará una visión desde el punto de vista de la calidad de la experiencia (QoE) obtenida. 2.2. Conceptos establecidos en síntesis de alto nivel En términos generales, la síntesis es la traducción de una descripción del comportamiento (con frecuencia en lenguaje natural o algorítmico, o funcional, o con formulación matemática o analítica de “solución de problemas”) en una representación estructural, donde cada componente de la descripción estructural es a su vez definido por su propia descripción de comportamiento [27] que en principio ha quedado rebajada en nivel de complejidad. El proceso de síntesis implica un refinamiento del sistema ya que se añade la información detallada requerida para el siguiente nivel (inferior) de abstracción. Este diseño con un nivel de detalle incrementado según se desciende en nivel de abstracción, debe satisfacer las restricciones de diseño proporcionadas en la primera descripción, restricciones que capturan limitaciones del entorno del diseño pretendido (tiempo, área, potencia por ejemplo). En el contexto de esta tesis distinguiremos la SAN de otro nivel superior el ESL (Electronic System Level). Este último incluye la organización de una aplicación en tareas, la planificación de tareas, la descomposición HW/SW y su mapeado en arquitecturas, la asignación de tareas a elementos de proceso, y la sincronización entre tareas. La SAN parte de los resultados de exploración del espacio de diseño –o contribuye a esa exploración– y parte también de la descomposición del problema o aplicación en tareas. Este nivel ESL excede a los objetivos de la tesis aunque se ha aportado a diversos trabajos del grupo [23][28][29][30][31][32] en ese campo. Igualmente distinguiremos la SAN del nivel inferior o de Síntesis Lógica (SL) y del nivel de implementación física, aunque el tratamiento que hacemos señala como veremos que los procesos de SAN y de SL deben realizarse en estrecha cooperación [33]. La síntesis de alto nivel se denomina también síntesis del comportamiento (por ser la entrada el comportamiento, a nivel de una tarea o equivalente) o síntesis a nivel arquitectural [34] (por ser la salida una estructura arquitectural). Es la etapa o actividad que mapea tarea algorítmica en una arquitectura. La SAN es un paso en la evolución de las tecnologías de diseño que busca incrementar la productividad, moviendo las decisiones de diseño a niveles más altos de abstracción, tal como se recoge por ejemplo en el diagrama en Y de Gajski y Kuhn [35] (figura 9). En el diagrama en Y se presenta el alto nivel como la abstracción de nivel superior a RTL y la síntesis de alto nivel como la transformación desde el dominio de comportamiento en alto nivel al nivel RTL. Con esta formulación de partida podemos decir por tanto que el principal objetivo de la SAN es la obtención de la microarquitectura del sistema electrónico planteada en base a unidades de procesamiento activadas por unidades de control asociadas al procesamiento. La síntesis de alto nivel mejora la productividad del diseño automatizando el refinamiento desde el nivel algorítmico hacia RTL, de tal forma que las funciones escritas en un lenguaje de alto nivel (C/C++/Matlab) se transforman y detallan mediante un conjunto de operaciones bien 20 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas Figura 9. Diagrama en Y ubicando la síntesis de alto nivel definidas, entre las que se encuentran las siguientes operaciones básicas plenamente establecidas (figura 10):  Análisis del código y optimización (lexical analysis) para crear la estructura de representación de alto nivel generalmente formada por un Programa Ejecutable, una Descripción Ejecutable, una Máquina de Estados Algorítmica Generalizada (ASM), un Grafo del Flujo de Datos y del Control (CDFG), un Grafo de Especificación Ejecutable o un Grafo Jerárquico de Tareas (HTG) [36]  Asignación de operadores y de variables (allocation), identificando el tipo de operadores y el tipo de almacenamiento necesarios, y asignación de cada variable y estructura de datos a determinada memoria o registro, así como el uso agrupado o potencialmente compartido de esas unidades (binding y sharing)  Planificación temporal (scheduling) de tal forma que cada operación se asigna a uno o varios pasos de control o ciclo de reloj  Asignación de cada operación a una unidad funcional determinada (binding y sharing)  Síntesis de los elementos de interconexión y multiplexores de los que resulta el datapath, la ruta de datos o cauce de procesamiento del flujo de esos datos; y las necesidades de control del cauce, el flujo del control Sistema Algorítmico RTL Lógico Circuital Comportamiento Físico Estructural Especificación del sistema Síntesis de alto nivel Síntesis RTL P&R Transformación Manual 21 2.2. Conceptos establecido s en síntesis de alto nivel 2.2. Conceptos establecidos en síntesis de alto nivel  Segmentación del cauce o de las unidades, y adaptación de la estructura de control  Visión clave del datapath como una estructura mixta formada por lógica combinacional de procesamiento conectada con registros cuyos valores se leen, trasfieren y escriben una vez procesados. Es la creación de la visión de nivel RTL. La SAN queda establecida como una síntesis que genera esta estructura RTL  Síntesis de interfaces de Entrada/Salida Figura 10. Flujo de síntesis de alto nivel En todo caso, un entorno de síntesis de alto nivel debe proporcionar tres funciones básicas: mapear el comportamiento del sistema a su estructura, estimar y analizar las prestaciones del sistema con objeto de tomar decisiones y verificar la concordancia de la representación de alto nivel con la representación detallada obtenida. Flujo simplificado de Síntesis de Alto Nivel Especificación en alto nivel Arquitectura RTL Síntesis lógica Compilación Representación intermedia (CDFG) Generación HDL RTL HDL Allocation Scheduling Binding Librería componentes 28 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas Existe una larga lista de herramientas [72], entre las que podemos citar SpecC [73], ImpulseC [74], Calypto/Mentor Catapult C Synthesis [75] (figura 14), Forte Cynthesizer [76] (ahora adquirida por Cadence) (figura 15), Celoxica Agility [77] , Bluespec [78], NEC CyberWorkBench [4] (figura 16), Synopsys SynphonyC [79] (figura 17), AutoESL AutoPilot [80] (ahora Xilinx Vivado HLS) y Cadence C-to-Silicon (CtoS) [81]. Algunas de estas herramientas han aparecido en este periodo temporal y han evolucionado, soportando ahora nuevas funcionalidades y podemos incluirlas como herramientas de 4ª generación, la generación actual, como veremos. Figura 14. Calypto/Mentor Catapult HLS Figura 15. Flujo de diseño de Forte Cynthesizer 29 2.3. Visión de la evolución de la síntesis y experiencia previa 2.3. Visión de la evolución de la síntesis y experiencia previa Figura 16. NEC Cyber Workbench (partnership con Aldec) Figura 17. Arquitectura de Synopsys Synphony Compiler Muchas de estas herramientas están centradas en ASIC y ASSP y otras son específicas para FPGAs. También algunas están centradas en el diseño de soluciones para DSPs (arquitecturas tipo Dataflow, dominadas por el flujo de datos) mientras que otras añaden soporte al diseño orientado a problemas dominados por el control. Como veremos más adelante, las herramientas actuales, que podemos considerar como de 4º generación soportan ambos dominios. La entrada del diseño, como se indicó anteriormente, se realiza desde C/C++ o SystemC, si bien con determinadas librerías y estilos de especificación o variaciones del lenguaje con tipos de datos dedicados (Algorithmic C de Mentor [75]). Otras opciones utilizan SystemVerilog 30 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas (BlueSpec) o Esterel. Por ejemplo BlueSpec [78] parte de una descripción SystemVerilog o un subconjunto de SystemC y ofrece un entorno para realizar refinamientos sucesivos del diseño inicial en alto nivel que garantiza la corrección del diseño usando técnicas TRS [82]. Igualmente herramientas orientadas al diseño de circuitos de procesado de señal utilizan Matlab+Simulink como entorno de captura del diseño, si bien utilizan C como paso intermedio. C/C++ soporta la captura de la funcionalidad del diseño pero no está preparado para modelar la estructura y el comportamiento temporal del mismo. Por ello la mayoría de las herramientas que utilizan C/C++ utilizan un conjunto de pragmas que permiten al diseñador guiar al compilador hacia la solución deseada. Este conjunto de pragmas soporta, por ejemplo la definición del protocolo de E/S, el control de los bucles o la protección de determinadas zonas de código para indicar la implementación de protocolos con dependencias estrictas. En cualquier caso el conjunto de directivas es finito y muy enfocado a un determinado estilo de diseño. SystemC en cambio ha sido diseñado para dar soporte a estos tres dominios de modelado del diseño. Al tratarse de clases de C++ y un kernel de simulación basado en eventos, soporta el modelado en varios niveles, como por ejemplo untimed, BCA, con abstracción de datos, etc. SystemC soporta estructura en el diseño, permitiendo gestionar su complejidad [21]. Igualmente en este caso se separa la especificación de las comunicaciones del procesamiento de datos, utilizando metodologías orientadas a transacciones. De hecho la aparición de las clases de Verificación en C++ (VIP), y luego las clases de Interfaz en SystemC, han dado lugar en el 2001 al estándar Transaction Level Modeling (TLM) [83][84]. El uso del lenguaje apropiado al dominio de aplicación de la herramienta es un factor decisivo para su aceptación y para la obtención de la mejor calidad de resultados. Otro aspecto importante en la elección del lenguaje apropiado es la utilización de las mejoras en las técnicas de optimización de los compiladores, muchas de ellas comunes con las técnicas de optimización de los lenguajes de alto nivel. Otro de los aspectos a tener en cuenta es que el nivel de integración a nivel de sistema (SoC) genera la necesidad de integrar diferentes tipos de unidades de procesamiento creando plataformas heterogéneas. Con ello las herramientas de SAN deben soportar diferentes dominios de diseño, ya sea de tipo flujo de datos (dataflow) o de control. La mayor parte de estos recursos se implementan conformando aceleradores hardware para algoritmos complejos (procesado de señal, multimedia, aplicaciones de bioingeniería, etc.). Aunque la gran industria apunta siempre a aceleradores en ASIC o ASSP o integrados en SoC, esos aceleradores muchas veces se integran en FPGAs, ya sea como etapa de prototipado ya sea como implementación final. Por lo tanto los parámetros a utilizar para la selección de la arquitectura son diferentes en FPGA que para el caso del ASIC o ASSP. En la FPGA, aparte de que se cumplan los requisitos temporales, se utiliza el criterio de si el acelerador se puede mapear o no en la FPGA con los recursos disponibles. Diferente situación se produce en el ASIC donde el espacio de soluciones área-tiempo es más flexible que para el caso de las FPGAs. Esta tercera generación de herramientas SAN ha tenido en cuenta estos aspectos, diferenciando los tipos de soluciones y dominios, los lenguajes de entrada y conectando las 31 2.3. Visión de la evolución de la síntesis y experiencia previa 2.3. Visión de la evolución de la síntesis y experiencia previa salidas a herramientas de implementación. En aquellos casos en los que se han especializado en implementaciones FPGAs, aprovechan los recursos de mayor granularidad de la FPGA tales como bloques de memoria y recursos tipo MAC/DSP para mapear variables y unidades aritméticas complejas. La experiencia adquirida con estas herramientas ha facilitado una mejor comprensión de los procesos de síntesis que traen como consecuencia una mejora en la calidad de los resultados, al estar derivados del uso de mejores prácticas. En concreto comentamos ahora la utilización de Agility Compiler durante el desarrollo del proyecto ARTEMI+ [85] en el que se ha diseñado un decodificador de vídeo H.264/AVC-SVC con perfil baseline desde su descripción algorítmica basada en JM versión 12.4 [86]. Relacionados con este proyecto podemos citar además los trabajos de prototipado mediante síntesis a partir de SystemC del bloque de estimación de movimiento [87] y el diseño y simulación del bloque de mejora de vídeo [88]. Agility Compiler soporta el subconjunto sintetizable de SystemC, generando descripciones RTL para los flujos de diseño síntesis lógica y simulación para tecnologías ASIC y FPGAs (figura 18). Integra un IDE con soporte a los procesos de captura del diseño, simulación y síntesis. Dispone de generación automática de código para FPGAs de Actel, Altera y Xilinx. Al utilizar SystemC es necesario definir procesos, definir listas de sensibilidad, y describir el modelo al nivel de transacciones (TLM) separando los detalles de la comunicación entre módulos de su implementación, modelándose como canales. Estos canales se implementarán como FIFOs o buses. Las transacciones se gestionan a través de las funciones de las interfaces de los módulos. Durante la fase de verificación es preciso escribir el testbench en SystemC y adaptarlo a nivel RTL. Algunas de las capacidades de optimización incluidas son la posibilidad de integrar bloques predefinidos como cajas negras, definir resets globales asíncronos e inicializar valores a las señales. Igualmente es posible realizar retiming, equilibrado y compartición de lógica y su reorganización en forma de árbol para reducir latencias. Asimismo puede hacer la reescritura de condiciones para ajustarlas a la lógica utilizada en el netlist final. Es posible la utilización de punteros que se resuelven en tiempo de compilación y desenrollar bucles bajo condiciones determinadas. La herramienta Agility Compiler genera informes de utilización de recursos y ayudas gráficas (CDFG). Utiliza formatos estándar para la salida del diseño, ya sea en VHDL, Verilog o EDIF para el caso de las FPGAs. Igualmente se genera SystemC a nivel RTL optimizado para simulación. Durante la transformación del decodificador H.264/AVC-SVC desde una solución software a una implementación hardware, uno de los aspectos claves es realizar la partición del algoritmo de tal forma que se agrupe la funcionalidad en los bloques para disminuir los requerimientos de comunicación. En este trabajo se ha utilizado una aproximación TLM, separando interfaces y procesamiento para cada bloque principal. Para el modelado de los bloques se ha utilizado SystemC OSCI con el estilo de modelado soportado por Agility Compiler. Para modelar las comunicaciones se ha utilizado TLM-2.0 que después ha sido refinado de forma manual definiendo las interfaces finales utilizadas por los bloques principales. Dichas interfaces TLM se han sustituido por una interfaz de señalización request/validate, conjuntamente con la interfaz de datos correspondiente adaptada al tipo de datos a transmitir. Además se han definido las correspondiente interfaces a las memorias necesarias en el decodificador: Temporal Picture 32 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas Buffer (TPB), Decoded Picture Buffer (DPB), Picture Buffer (PB) y memorias internas. Las últimas versiones de Agility Compiler usadas en el proyecto soportan la capacidad de inferir memorias. Figura 18. Flujo de diseño con Agility Compiler Con objeto de mejorar las rutas críticas el proceso de planificación ha sido guiado por el diseñador, de tal manera que, apoyándose en la utilización de sentencias wait(), el diseñador puede segmentar las rutas críticas aumentando la frecuencia de funcionamiento, manteniendo o cumpliendo las restricciones de latencia requeridas. Esto no es automático. Se necesita acometer un proceso de mejoras iterativas que requiere la intervención del diseñador para la toma de decisiones. Igualmente los resultados obtenidos en alto nivel en términos de área/tiempo eran muy conservadores por lo que era preciso apoyarse en los resultados de las herramientas de síntesis lógica. Creación y test del código C++ en un IDE de desarrollo Refinado del código para transformarlo en SystemC sintetizable en un IDE C++ Verificación usando un testbench Síntesis del código a SystemC RTL en Agility Síntesis del código a HDL en Agility Síntesis del código a EDIF en Agility P&R 33 2.4. Situación actual en SAN 2.4. Situación actual en SAN 2.4. Situación actual en SAN Hemos visto que la síntesis de alto nivel toma una descripción de comportamiento o algorítmica de un sistema digital y crea una estructura a nivel RTL que implementa dicho comportamiento. Las herramientas de SAN pueden generar representaciones RTL del diseño de una forma más eficiente, de mejor calidad y más rápida que si abordamos el diseño de forma manual en determinados dominios de aplicación. Como se ha indicado, la SAN está ganando importancia en el diseño de sistemas electrónicos digitales ya que permite abordar la complejidad creciente del diseño del sistema, reduce los esfuerzos de verificación, facilita la exploración del espacio de diseño y la optimización del diseño para varios factores tales como latencia, potencia y área/recursos y facilita la migración entre diferentes tecnologías de implementación del diseño, ya sea ASIC, ASSP o FPGA. Se ha producido un cambio de paradigma en los métodos de entrada usados para la SAN donde las representaciones de comportamientos basadas en HDL han sido sustituidas por lenguajes de alto nivel más cercanos a la creación de algoritmos y bloques de procesamiento de señal. Ello implica que se haya incrementado el interés de los usuarios industriales por la síntesis de alto nivel. Esta tercera generación de la SAN se ha ido consolidando en el sector industrial de tal forma que en el año 2010, 30 de las mayores compañías de semiconductores a nivel mundial ya habían adoptado SAN como método de diseño de sus productos. En 2014 la adopción de la síntesis de alto nivel es un hecho en la empresa, quedando demostrado su valor desde el punto de vista industrial como método de diseño [89]. Consideramos ahora la situación actual, fijando el horizonte de 2015 como ya indicamos en la figura 12. Los tipos de diseños en que actualmente se adopta la síntesis de alto nivel son aquellos con contenido algorítmico complejo, diseños cuyas especificaciones cambian rápidamente o los estándares evolucionan y aquellos diseños que deben implementarse rápidamente para tener un producto en el marcado, ya sea en FPGA o ASIC. Estos tipos de diseño se implementan mucho más rápidamente usando SAN que estilos de diseño RTL. Entre estos tipos de diseño podemos encontrar soluciones complejas desde Wireless 3G/4GLTE, hasta codificación/decodificación de vídeo H.264/AVC, H.265/HEVC, VP9, etc. La mayor parte de las herramientas utilizadas en SAN actualmente utilizan C/C++ y SystemC como entrada del diseño. Para este trabajo vamos a realizar un estudio más detallado sobre los entornos de Calypto/Mentor Catapult, Altera OpenCL, Vivado HLS y Cadence CtoS, aportando también nuestra propia experiencia de diseño con ellos, para extraer mejores prácticas para entornos de producción de diseños. Otros entornos y herramientas están descritos en [90]. En el apartado siguiente (2.5) se indicarán algunos aspectos de tendencias en la evolución de estos entornos debido a avances científicos en la tecnología de diseño y de construcción de herramientas. 34 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas 2.4.1. Calypto/Mentor Catapult Catapult C Synthesis [91] parte de un algoritmo escrito en ANSI C++ y mediante un conjunto de directivas de síntesis genera un diseño a nivel RTL optimizado para una determinada tecnología, ya sea ASIC o FPGA. Las directivas no modifican el comportamiento funcional de la especificación de entrada sino que añaden la información precisa para crear la estructura del diseño, incluyendo las interfaces. Es posible su utilización tanto en aplicaciones intensivas en cómputo como de control o en sistemas que incluyan ambos dominios. La entrada del diseño es totalmente funcional, sin incluir conceptos temporales o estructurales de forma explícita, tales como la arquitectura del diseño o sus interfaces de E/S. Esto permite una exploración completa del espacio de diseño a nivel de arquitectura. Las directivas especifican la tecnología de implementación, y sus componentes, el periodo de reloj, la síntesis de interfaces, la arquitectura de memorias, el tipo de paralelismo a aplicar en los bucles (desenrollado total o parcial, segmentación), jerarquía de bloques. Igualmente se dan restricciones de planificación tales como latencia o ciclos de reloj. También incluye directivas para el control de las tareas básicas de síntesis de alto nivel tales como planificación temporal (control de latencia/ciclos), o asignación de recursos (tipo de recursos y cantidad). En cuanto al tipo de datos, se soportan tanto los tipos integer nativos de C++, enteros con operaciones con precisión de bits en C++ y coma flotante. Soporta los tipos propietarios definidos como Algorithmic C [75], incluyendo clases denominadas como Algorithmic C Window para portar arrays multidimensionales. Igualmente soporta tipos de datos en coma flotante (división, raíces, etc.) pero los transforma a coma fija. También soporta los tipos sintetizables de SystemC [92]. El proceso de creación del diseño con Catapult C se organiza en los siguientes pasos: 1. Crear/adaptar, encapsular y verificar el código fuente utilizando los tipos de datos y la estructura soportada. Es necesario identificar el nivel más alto de jerarquía mediante la correspondiente directiva o pragma. 2. Analizar el algoritmo con respecto a la tecnología a utilizar y al reloj definido, ya que representan las dos restricciones más importantes del diseño. Existen herramientas de análisis tales como el diagrama de Gantt. A este análisis sigue la generación de la arquitectura RTL. 3. Creación del diseño hardware. En este paso se hace la asignación de recursos hardware, las restricciones tecnológicas, la arquitectura de memoria en función de las restricciones de la tecnología y el esquema de E/S. Por último se genera el código RTL en HDL (VHDL o Verilog). 4. Realización de la simulación, con información precisa de ciclos. 5. Síntesis del diseño RTL apoyándose en herramientas de síntesis lógica integradas en el entono. Tal como se ha indicado, las interfaces y la arquitectura del hardware generado puede controlarse mediante directivas de síntesis, ya sea como pragmas en el código fuente, como 35 2.4. Situación actual en SAN 2.4. Situación actual en SAN directivas introducidas mediante la interfaz gráfica o un fichero Tcl, o incluso valores por defecto incluidos en la configuración del proyecto. Todas las señales necesarias y las restricciones temporales se generan durante el proceso de síntesis de tal forma que el código RTL optimizado generado es conforme con las interfaces. Por ejemplo una variable de tipo array en C/C++ puede generar una interfaz de memoria (dirección/dato/enable/write o read) o una interfaz de flujo de datos (Stream) de tal forma que los datos son proporcionados de forma secuencial. Catapult C incluye una base de datos orientadas hacia síntesis (Synthesis Internal Format – SIF) que da soporte a la exploración del espacio de diseño para diferentes soluciones y tecnologías. Durante la fase de síntesis de alto nivel se generan las restricciones necesarias para utilizarlas en la síntesis RTL. La síntesis de las interfaces se realiza para un conjunto definido de canales y con su correspondiente señalización, incluyendo interfaces de memoria, FIFOs, interfaces en flujo de datos, etc. La jerarquía del diseño, que implica la creación de bloques que se ejecutan de forma concurrente, se especifica también con directivas de tal forma que una función se puede implementar en un bloque separado, reutilizando su implementación en caso de no ser requerida en el mismo ciclo. Igualmente se pueden especificar bloques interconectados mediante FIFOS, utilizando un modelo de redes de Kahn (KPN). Los bloques se pueden implementar en diferentes dominios de reloj, y la lógica de sincronización entre dominios se genera de forma automática. La comunicación entre bloques se optimiza utilizando FIFOs, Memorias ping/pong o señalización request/validate. Para obtener convergencia en las prestaciones entre los resultados de alto nivel y RTL se utiliza una librería de componentes precaracterizados para la tecnología objeto, ya sea FPGA o ASIC, con diferentes alternativas retardo–área–potencia. Durante el flujo de síntesis (figura 19) se genera el testbench que encapsula la descripción RTL obtenida en SystemC, reutilizando el testbench original en C/C++. Igualmente es posible realizar un análisis de potencia preciso a partir de la actividad obtenida del modelo RTL de tal forma que se obtiene una información detallada de las prestaciones del diseño con objeto de analizar varias opciones en la implementación de la arquitectura que cumplan con las restricciones del diseño. Durante la realización de este trabajo se ha utilizado Catapult para la implementación de parte del procesador de eventos que se describe como caso de aplicación en el capítulo 3 a partir de la descripción SystemC. Sin embargo la versión universitaria utilizada estaba restringida a un único bloque por lo que los tiempos de síntesis para realizar la exploración del espacio de diseño eran prohibitivos dato el tamaño de la aplicación. Utilizar un nivel de granularidad más fino para implementar el acelerador implica un esfuerzo adicional en la creación de entornos de test e interfaces de comunicación y ello hace perder la ventaja de la utilización de una herramienta de SAN. Las versiones actuales ya no incluyen esta restricción, permitiendo controlar de forma eficiente la jerarquía de tal forma que cambios en un bloque no afectan totalmente al resto del diseño. 36 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas La herramienta presenta una curva de aprendizaje relativamente rápida, si bien para obtener un rendimiento elevado y mejorar la calidad de los resultados se exige una comprensión detallada de las alternativas de optimización. En otros casos de uso, con problemas de dimensiones relativamente menores, como es el caso de diferentes bloques del filtro de desbloqueo – DF del capítulo 4, las prestaciones están acorde a los valores obtenidos durante la síntesis lógica. En todos los casos se ha hecho uso de los modelos SystemC. Figura 19. Flujo de diseño en Catapult 2.4.2. Altera OpenCL Altera ha desarrollado un entorno de síntesis orientado a la implementación rápida de aceleradores hardware y basado en OpenCL [93]. Open Computing Language (OpenCL) es un estándar abierto para la programación de sistemas de computación heterogéneos que incluye un lenguaje de programación paralela para la parte del dispositivo y una API en C para la parte del host. Por tanto el software que se ejecuta en el host es totalmente secuencial y se puede ejecutar tanto en un procesador soft-core embebido en la FPGA (o en varios cores) como en un procesador externo, o en varios. OpenCL está basado ISO C99 y permite crear aplicaciones con paralelismo a nivel de datos y de tareas que pueden ejecutarse en una serie de núcleos de computación disponibles, CPUs, GPUs, DSPs y FPGAs. Desarrollo y verificación del código fuente Síntesis RTL C/C++ SystemC RTL Netlist C/C++/SystemC Reloj/Tecnología RTL IPs/Bloques RTL Restricciones temporales (SDC) Síntesis de Alto Nivel en Catapult:  Creación/adaptación, encapsulado y verificación del código fuente  Análisis del algoritmo y generación de la arquitectura RTL.  Creación del diseño hardware.  Simulación BCA  Síntesis del diseño RTL 37 2.4. Situación actual en SAN 2.4. Situación actual en SAN Altera ha creado su propio kit de desarrollo de software (SDK) [94] orientado hacia la implementación de aceleradores sobre FPGAs. El programa desarrollado en OpenCL para la parte del dispositivo se transforma en un núcleo IP en Verilog/VHDL que se toma como referencia para generar el bitstream de configuración de la FPGA. La parte del host se utiliza para configurar y controlar la FPGA para el procesado de datos. La implementación de Altera de OpenCL [95] facilita la comunicación con el procesador, la planificación de los procesos y la transferencia de los datos en alto nivel. Dispone de un conjunto de funciones que abstraen la comunicación entre el procesador y el acelerador tal como se muestra en la figura 20. En la figura 21 se muestra la arquitectura de programación vista desde el host y en la figura 22 el flujo de diseño completo. Altera OpenCL utiliza el compilador aoc (Altera Offline Compiler) para transformar la descripción algorítmica de los núcleos de procesamiento en una arquitectura RTL y genera la descripción Verilog que luego puede ser transformada por las herramientas de Quartus II en la implementación hardware de los núcleos. Durante el proceso se genera también un fichero binario (.aocx) que contiene la configuración de la plataforma. Los procesos realizados por el aoc son los siguientes:  Compilación, cuyo objetivo es detectar errores sintácticos  Emulación, que ejecuta los núcleos en una arquitectura x86 para depurar su funcionalidad  Perfilado, que instrumenta el código Verilog generado para obtener perfiles de ejecución con objeto de optimizar la arquitectura del núcleo  Ejecución del flujo, que genera los ficheros binarios .aocx para su implementación en la FPGA El compilador aocx utiliza directivas basadas en pragmas y atributos para controlar el proceso de generación de la arquitectura RTL usando técnicas de SAN. Entre ellas podemos encontrar el control del desenrollado de bucles. Igualmente el compilador posee directivas de control para especificar el número de unidades de computación, replicar el número de núcleos en una arquitectura SIMD, o especificar la posición de los buffers de memoria, tanto local como global. Igualmente hace un uso extensivo del preprocesador de C para parametrizar la descripción. Figura 20. Ejemplo de código OpenCL main() { Read_data( … ); manipulate( … ); clEnqueueWriteBuffer( … ); // Copiar datos a la FPGA clEnqueueTask(…, my_kernel, …); // Procesar datos en la FPGA clEnqueueReadBuffer( … ); // Copiar datos desde la FPGA display_result( … ); } 44 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas Figura 27. Diagrama de bloques de CtoS CtoS utiliza un CDFG para mostrar el comportamiento de las funciones incluidas en el diseño, donde es posible imponer restricciones de diverso tipo, incluidas las de latencia (figura 28). Presenta un conjunto de utilidades para el análisis temporal, de área y potencia del diseño. Además del diseño RTL, exporta otros productos tales como el fichero de restricciones para su uso durante el proceso de síntesis lógica. Figura 28. Ejemplo de CDFG de Cadence CtoS La herramienta posee una interfaz de análisis enlazada con el código fuente en SystemC. La interfaz incluye el análisis de la ruta crítica, el mapa de memoria y de potencia, entre otras ayudas (figura 29). 45 2.4. Situación actual en SAN 2.4. Situación actual en SAN Figura 29. Interfaz de análisis de Cadence CtoS La literatura muestra que CtoS puede conseguir diseños a partir de un modelo con una reducción x3 de las líneas de código y conseguir una reducción del 35% en área y 51% menos de potencia, con un incremento del 35% de prestaciones, que un diseño RTL a partir de las mismas especificaciones [102]. Nuestra experiencia de utilización de este entorno es amplia, demostrando el flujo de diseño basado en SystemC hasta su implementación hardware sobre FPGA y sobre ASIC [53, 54] partiendo de SystemC. En [105] se ha evaluado la capacidad de CtoS para soportar el modelado TLM orientado a la síntesis. En este caso se ha dotado de interfaz TLM a un bloque de predicción de movimiento de un decodificador de vídeo mediante los métodos get() y put() de la interfaz y se han modificado los puertos orientados al handshake de señales por FIFOs. Los resultados demuestran que las prestaciones de este estilo de modelado no se ven afectadas por el estilo de modelado y por el contrario hace que el proceso de modelado sea más simple. Como esta herramienta ha sido extensivamente usada en este trabajo de investigación se mostrarán más detalles y conclusiones sobre mejores prácticas en los siguientes capítulos. 2.4.5. Otros entornos de síntesis de alto nivel Aparte de los entornos citados que representan el estado de la industria EDA en cuanto a la SAN, existen diferentes grupos de investigación que están generando nuevas herramientas, generalmente de código abierto, que cubren diferentes aspectos ya sean desde el punto de vista metodológico o para aplicarlos en dominios especializados. GAUT [38] es una herramienta de código abierto para la SAN. Parte de una especificación precisa a nivel de bits en C/C++ y genera de forma automática una arquitectura RTL en VHDL para implementarla en FPGAs (usando Quartus II o Xilinx ISE). Genera modelos de simulación 46 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas TLM y Cycle-Accurate Bit-Accurate (CABA) en SystemC para integrarlos en un prototipo virtual. Está orientado hacia el procesamiento de señales. Su modelo de arquitectura integra unidades de procesamiento, una unidad de memoria, una unidad de comunicación e interfaces GALS/LIS (Globally Asyncronous Locally Synchronous/Latency Insensitive System). ROCCC (Riverside Optimizing Compiler for Configurable Circuits) [106] es una herramienta de código abierto para la SAN desarrollado en la Universidad de California Riverside. Utiliza Eclipse como entorno de diseño desde donde se ejecuta ROCCC. Utiliza un subconjunto de construcciones de C como lenguaje de entrada del algoritmo. Soporta el tipo de datos de enteros de ancho arbitrario usando construcciones typedef del lenguaje. Genera una descripción VHDL de salida que puede ser implementada en FPGAs. El objetivo es extraer las funciones, o parte de ellas, de la aplicación con mayor carga computacional y mapearlas en aceleradores hardware. Soporta el concepto de Smart buffers que hace un análisis de localidad de los datos, almacenando en memoria local aquellos datos reutilizados por el algoritmo, reduciendo así el tráfico con memoria. Esta técnica es de interés en aplicaciones de procesamiento de vídeo o de comunicaciones inalámbricas o celulares. LegUp [107] acepta un algoritmo escrito en C estándar y lo compila en una plataforma heterogénea basada en FPGA que incluye un procesador soft-core MIPS y aceleradores hardware que se comunican a través de interfaces de buses estandarizados. El flujo de diseño incluye un compilador estándar de C que genera código para su ejecución en el procesador MIPS. Una vez se compila el código, este se perfila para extraer los núcleos de computación elevada que se transforman mediante técnicas de SAN en aceleradores hardware. LegUP está basado en la infraestructura de compilación LLVM (Low-level Virtual Machine) que transforma el código en una representación intermedia IR de tal forma que, mediante nuevos procesos de transformación y optimización, se convierte en una representación muy cercana al hardware. A partir de esta representación se realizan las operaciones de planificación, asignación de funciones y recursos. El resultado final es la obtención de una solución hardware/software, siendo de interés para este trabajo los aspectos relativos a la implementación de los aceleradores. 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse En este apartado vamos a describir los principales retos que debe acometer aún la SAN para consolidarse como metodología de diseño plenamente aceptada en la industria que cubra efectivamente la distancia entra la capacidad de integración existente y la capacidad de diseño. A lo largo de este capítulo se ha explicado cómo diferentes entornos de diseño abordan el problema de transformar un algoritmo, con un comportamiento intrínsecamente secuencial, a una arquitectura hardware que ejecuta de forma concurrente diferentes procesos en los bloques que la forman. En el núcleo del problema, todas las herramientas realizan tareas de análisis del código, planificación, asignación de recursos y selección de unidades funcionales y, por último, realizan la tarea de generar código HDL a nivel RTL. 47 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse Sin embargo las principales diferencias estriban en las restricciones impuestas por los dominios de aplicación, ya que condicionan el tipo de solución arquitectural y por tanto imponen restricciones en el espacio de soluciones a explorar por la SAN. Existen varios factores que están favoreciendo la plena adopción de la metodología de diseño de SAN, entre ellos:  La necesidad de crear el diseño en niveles más altos de abstracción para poder cubrir la ya inmensa y creciente capacidad de integración del silicio  Mejorar la reutilización del diseño adoptando los niveles de comportamiento  La necesidad de disponer de modelos de alto nivel que faciliten la verificación  La utilización masiva de aceleradores implementados en hardware que requieren los algoritmos actuales para una eficiente utilización del binomio tiempo y energía  La utilización de plataformas heterogéneas que requieren que una parte del problema se solucione y desarrolle en un lenguaje de alto nivel  En todo caso, la plena adopción de una nueva metodología está condicionada por varios factores claves: la calidad de los resultados obtenidos, la reducción de los tiempos de puesta en mercado del producto y de sus costes y la curva de aprendizaje de la metodología. A continuación se muestran algunos retos que aún debe abordar la metodología de SAN. 2.5.1. Lenguajes para SAN Existen diferentes opciones para la captura del modelo de entrada a la SAN. C/C++ presenta facilidad de aprendizaje y velocidad de simulación mientras que SystemC incluye además características para dar soporte al diseño hardware a nivel de sistema. Por otro lado BSV (Bluespec SystemVerilog) soporta el nivel arquitectural para establecer estructuras del control. BSV (Bluespec SystemVerilog) incluye varias características de un lenguaje de alto nivel (Haskell) y las características de SystemVerilog. El objetivo es reducir la distancia desde el modelo de comportamiento al modelo RTL. El lenguaje adopta el aspecto de transacciones atómicas para expresar y describir comportamientos concurrentes complejos. La ventaja de esta propuesta es ofrecer un lenguaje común en varios niveles de abstracción. MATLAB y especialmente Simulink ha sido una herramienta ampliamente usada para el diseño algorítmico debido a que se trata de un lenguaje maduro con módulos especializados (toolboxes), conjuntamente con la posibilidad de integrar código C. El problema se centra entonces en migrar a hardware el algoritmo o parte de él. Algunos proveedores de FPGAs han desarrollado toolkits de Simulink que permite sintetizar de forma eficiente algunas funciones predefinidas en sus dispositivos. Algunos ejemplos son Altera DSP Builder o Xilinx Vivado System Generator. Aunque se trata de entornos fáciles de usar, estas herramientas están limitadas a los bloques suministrados por el fabricante y están disponibles únicamente para dispositivos propios. Existen otros intentos de crear una herramienta genérica de síntesis a partir de código M de Matlab. 48 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas Podemos entonces resumir los requerimientos básicos que debe poseer un lenguaje especializado para SAN[108]. El primer requisito de un lenguaje de entrada a la SAN es que haya sido utilizado para escribir los algoritmos que se van a implementar en hardware. Para este requerimiento C/C++ o lenguajes basados en ellos es la elección apropiada. Se trata de lenguajes maduros, con soporte de diferentes herramientas tales como depuradores, compiladores, optimizadores, analizadores estáticos y dinámicos. El punto de partida es el amplio conjunto de algoritmos en C que es posible implementar en hardware. El segundo requisito es que el lenguaje debe soportar mecanismos de abstracción. Si el lenguaje posee un único nivel de abstracción no es apto para la gran variedad de diseño hardware existente. Por tanto la idea es usar un lenguaje orientado a objetos (C++). El tercer requisito es que el lenguaje debe soportar el nivel de abstracción relacionado con el hardware, proporcionando una conexión entre el modelo de alto nivel y la implementación hardware. Esto implica soportar una representación que se mapee directamente en RTL, proporcionando una integración directa entre los diferentes niveles de abstracción desde RTL. Los elementos que se requieren para esta integración son el soporte a jerarquía, concurrencia y precisión a nivel de bits. Sin estos elementos no es posible representar todos los aspectos del diseño hardware. SystemC ha sido concebido para incluir estas características. Se trata de un conjunto de clases C++ que soportan las nociones de concurrencia, tiempo y otras características tales como aritmética de punto fijo. Además incluye un kernel de simulación orientado a eventos. ANSI C++ es el lenguaje de modelado más ampliamente usado a nivel algorítmico en los niveles de abstracción de sistema. Proporciona clases y plantillas para modelar tipos de datos a nivel de precisión de bits, y soporta encapsulación modular y parametrización. La especificación secuencial en C++ es compacta, fácil de depurar y verificar y ofrece buena velocidad de simulación. Por tanto es un buen candidato para crear arquitecturas e interfaces hardware utilizando SAN. SystemC se apoya en C++ como lenguaje y añade características específicas para el modelado de interfaces hardware y concurrencia para la integración y verificación de sistemas complejos, que incluyen buses de comunicación y componentes modelados a nivel RTL. La metodología TLM soportada por SystemC separa las especificaciones de los núcleos de computación sin información temporal por un lado, de las especificaciones de interfaces precisas a nivel de ciclo por otro lado. En la tabla 1 se muestran las principales características aportadas al diseño de alto nivel por los lenguajes citados. La implementación eficiente desde algoritmos en C/C++ requiere un compilador con capacidad de paralelización y optimización para cumplir los objetivos de área, latencias y potencia requeridos. Todos los detalles hardware pueden inferirse desde el modelo de alto nivel y las restricciones de diseño. El modelado a nivel de sistema y el desarrollo temprano del software requiere modelos que reflejan el paralelismo del diseño hardware. Aunque este paralelismo no se expresa directamente en la especificación C/C++, el modelo TLM en SystemC, que sí incluye paralelismo 49 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse hardware de forma explícita (microarquitectura) puede ser generado de forma automática por el compilador cumpliendo con las especificaciones. Tabla 1. Soporte de los lenguajes a diferentes aspectos del diseño en alto nivel (adaptada de [26]) Lenguaje Construcciones del lenguaje Características aportadas al diseño de alto nivel C Tipos enteros de precisión arbitraria Mejora de la calidad de los resultados al obtener diseños precisos a nivel de bits Tipos de datos para representación de reales con coma flotante Soportan la aritmética de coma flotante Estructura y llamada de funciones en C Soporte al diseño jerárquico Punteros Eficiencia y flexibilidad en el uso de los recursos para el acceso a datos Estructuras y uniones Encapsulación de datos C++ Tipos de coma fija Aritmética de coma fija, Compromiso precisión-costo Plantillas de C++ Diseño parametrizable Clases Modelado orientado a objetos (encapsulado, herencia, polimorfismo …) SystemC Módulos y Procesos Jerarquía y concurrencia a nivel de bloques Relojes SystemC Soporte diseño síncrono y diseños con múltiples dominios de reloj. Protocolos TLM Separación de la computación y comunicación. Simulación más rápida del modelo. Prototipos virtuales con precisión de ciclo Modelo de eventos Simulación. Coexistencia de varios niveles de abstracción Un lenguaje adecuado para SAN debe soportar por un lado descripciones funcionales, ya sean con información temporal o no, e igualmente soportar por otro lado la tecnología de síntesis apropiada para producir rutas de datos y lógica de control optimizadas a nivel RTL. Los niveles de abstracción más elevados separan los núcleos de computación (untimed) de la implementación hardware ya que estos núcleos son más fáciles de simular y depurar, dejando a las herramientas de SAN la generación de las interfaces correspondientes, lo que conlleva la posibilidad de obtener varios tipos de arquitectura a partir de la misma descripción inicial. TLM típicamente separa la descripción funcional de los módulos respecto de los medios y métodos usados para comunicarse entre ellos (separación de la computación de la comunicación). Ello permite un alto nivel de abstracción que puede usarse para maximizar las velocidades de simulación y para minimizar los tiempos de exploración de la arquitectura. Tanto la funcionalidad como la comunicación pueden ser refinadas de forma gradual hasta conseguir una comunicación precisa a nivel de señales. Los núcleos de computación (untimed C) pueden usarse incorporados en un nivel TLM. Así, los algoritmos escritos a nivel TLM con SystemC aportan en sí mismos un medio de enlace entre 50 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas el código de alto nivel y su implementación RTL. Además la herramienta puede usarse durante la verificación mediante un bloque TLM que integre el bloque RTL optimizado. Los SoCs diseñados hoy en día reutilizan del orden del 70% de los diseños a los que se añaden otros propios para diferenciar los productos y añadir características propias o nuevas del producto. Los nuevos bloques pueden ser tanto aceleradores hardware como bloques de control. Los aceleradores de aplicaciones implementados en hardware proporcionan ventajas en términos de prestaciones y de ahorro de potencia en relación a su implementación software. Estas funciones se diseñan normalmente en C/C++ para verificar su funcionalidad y para aprovechar las ventajas de la velocidad de simulación. La implementación de estas funciones directamente desde C/C++ proporciona el nivel más alto de abstracción y da la mayor ventaja en productividad del diseño. Para el caso del diseño de aceleradores, el diseño del algoritmo está condicionado por las restricciones impuestas por la arquitectura particular en la que se va a ejecutar. A diferencia del diseño software, donde la arquitectura de la plataforma es fija, en el diseño de alto nivel, la arquitectura y el algoritmo se crean conjuntamente. En contraste con los aceleradores de aplicaciones, los bloques de control interaccionan con el entorno y requieren una especificación detallada a nivel de ciclo. Las soluciones integradas que soporten ambos aspectos -bloques aceleradores (dataflow) y bloques de control a partir de especificaciones abstractasson necesarias para los sistemas actuales. Las herramientas poseen directivas para controlar la latencia, el tiempo de ciclo y el comportamiento temporal del diseño o de parte de él. Igualmente es posible interactuar para controlar la asignación de recursos, la asignación de entradas y salidas, la arquitectura de memoria y el uso de librerías de IPs. El reto es reducir el tiempo de puesta en mercado del sistema electrónico, tanto del hardware como del software en forma de SoC complejos. Esto requiere lenguajes que vayan más allá del diseño lógico y den soporte al diseño del software empotrado mediante la creación de prototipos virtuales (VP) de altas prestaciones. SystemC permite la interoperatibilidad y estandarización de los modelos utilizados. La verificación supone el mayor coste en la producción de nuevos SoC, por lo que la utilización de niveles tales como TLM, donde sea posible depurar el diseño a alta velocidad es una ventaja de productividad. Esto requiere que se adopten técnicas de SAN para los diferentes IPs incluidos en el diseño. Para poder realizar una exploración arquitectural del diseño, evaluar sus prestaciones y realizar su verificación, es necesario ejecutar las aplicaciones reales, a veces incluyendo un sistema operativo, sobre diferentes configuraciones que representan el sistema real. Cada configuración incluye modelos, bancos de test, IPs usados para realizar la implementación en diferentes niveles de abstracción, por lo que se requiere un lenguaje estandarizado y aceptado por la comunidad de diseñadores para incluir esta diversidad. Los aspectos de verificación son claves para validar el diseño obtenido. Por tanto las herramientas actuales tratan de verificar el diseño en dos etapas: durante la creación del 51 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse algoritmo que representa el código de entrada del diseño y durante una segunda etapa en la que se verifica el diseño RTL obtenido. El primer paso se realiza mediante simulación mientras que el segundo se puede realizar mediante simulación pero también mediante verificación formal. El nivel de abstracción del modelo de entrada ofrece una velocidad de simulación mayor que el de los HDLs. Para verificar el modelo RTL la mayor parte de los flujos de diseño ofrecen procesos automáticos que permiten la reutilización de los bancos de test, verificando el modelo RTL contra el modelo funcional inicial. La productividad, calidad de resultados (QoR) facilidad de verificación y reutilización son razones claves por las que los diseñadores han adoptado métodos de diseño basados en síntesis de alto nivel. El soporte del lenguaje es relevante si puede ayudar a estos objetivos. Las herramientas de SAN deben soportar el mayor conjunto de lenguajes de entrada posible que ayuden a describir otros aspectos del flujo de diseño. Podemos concluir que la utilización de un lenguaje de especificación de alto nivel que permita la reutilización del diseño y soporte el paralelismo intrínseco del hardware contribuirá a la consolidación de la metodología. Debido a las continuas mejoras en las técnicas de compilación, se han aprovechado las optimizaciones introducidas en los compiladores para transferir de forma rápida esa evolución al diseño hardware. Esto requiere la especificación de algoritmos precisos a nivel de bits y la identificación o extracción de tareas que se puedan paralelizar, por la ausencia de dependencia de datos. C/C++ y SystemC suponen la alternativa elegida y consolidada como lenguaje por lo que el reto es establecer mecanismos de convergencia para la compatibilidad entre herramientas de síntesis, facilitando la reutilización de los IPs definidos a nivel de comportamiento (figura 30). Figura 30. Niveles de modelado de C++ y SystemC (adaptada de [109]) 2.5.2. Verificación del diseño a sintetizar Como se ha indicado a lo largo de este capítulo la SAN presenta muchas ventajas sobre el diseño RTL, entre ellas la mejora en la eficiencia de la verificación del diseño en niveles de abstracción más altos. Parece evidente que en estos niveles de abstracción el número de errores 52 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas que se producen será menor pero siempre va a ser necesario verificar las transformaciones que se aplican al diseño desde su creación hasta que es implementado. La mayor parte de las metodologías que utilizan el nivel algorítmico como entrada del diseño sin aportar información temporal (modelos untimed) requieren su transformación hacia nivel RTL para realizar la verificación. Ello se debe a que durante la transformación del diseño se han añadido dos aspectos claves y diferenciadores: el dominio estructural (modularidad, jerarquía, comunicaciones) y el dominio temporal (concurrencia, protocolos, entre otros). Es decir en RTL disponemos de un modelo preciso a nivel de ciclos de bus y preciso a nivel de bits (Cycle Accurate Bus Accurate – CABA) no existente al nivel algorítmico. Esta falta de información en los dominios indicados trae consigo que, dependiendo de la complejidad del diseño, la verificación realizada a nivel algorítmico no represente el comportamiento de la arquitectura mapeada. La solución adoptada por la mayoría de los entornos de SAN estudiados es realizar la verificación del diseño solo a nivel RTL. Esto implica la necesidad de introducir adaptadores que transformen las señales RTL para obtener los valores de E/S del modelo simulado para su utilización en el testbench. Por tanto se quiere verificar que hay concordancia entre el modelo de comportamiento y el modelo RTL obtenido. Esta aproximación a la verificación del modelo de alto nivel es complicada y tediosa, difícil de verificar y produce resultados inesperados, especialmente en el dominio temporal, y más concretamente en los protocolos de comunicación entre bloques. El modelo C/C++ no se puede depurar hasta que no se realice la síntesis de alto nivel ya que no se dispone de estructuras de comunicación ni de modelo temporal definido. Sin embargo, el encapsulado del algoritmo en SystemC facilita la verificación del modelo antes de ser sintetizado (figura 31). El modelo SystemC dispone de la información necesaria para dar soporte a los dominios de representación del modelo hardware. La idea clave aquí es que el diseño debe ser verificado antes de su síntesis de alto nivel de tal forma que el diseño enviado a síntesis esté libre de errores [110] (figura 31). Para el incremento efectivo de la productividad es necesario verificar el diseño antes de su síntesis de alto nivel, y puede hacerse en SystemC. Como puede observarse, los modelos a nivel TLM como los descritos en [111][112][113] facilitan la simulación del sistema. Figura 31. Simulación y síntesis del Modelo SystemC Simulación Síntesis de Alto Nivel RTL Modelo de Simulación TLM SystemC SystemC SystemC Librerías de IPs TLM Modelo SystemC 53 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse 2.5. Retos de la síntesis de alto nivel y hoja de ruta que puede preverse 2.5.3. Plataformas heterogéneas personalizadas Numerosas aplicaciones de aceleración se están desarrollando bajo el paradigma de las plataformas heterogéneas personalizadas (Customizable Heterogenuos Platform – CHP) mediante la inclusión de aceleradores adaptados a la aplicación de tal manera que la mayor parte del cómputo se produce en los aceleradores, que son más eficientes en términos de energía. Por ejemplo en casos típicos de consumo de potencia, las prestaciones de transferencias de datos en una FPGA están en el orden de 2,5 Gbps/W mientras que en un procesador de propósito general dicha transferencia baja a 0,015 Gpbs/W [114]. En este escenario, la síntesis de alto nivel presenta ventajas bien definidas para la creación de dichos aceleradores a partir de algoritmos escritos en C/C++. En la literatura se pueden encontrar referencias a aplicaciones para el procesamiento que usan aceleradores basados en FPGA, creados a partir de especificaciones de alto nivel usando SAN. Algunos ejemplos son: identificación de ADN [115], aplicaciones financieras [116], de optimización de redes inalámbricas [117], de aceleración en bases de datos [118] o de computación en la nube [18]. Existen aproximaciones para crear aceleradores implementados mediante técnicas de reconfiguración parcial de la FPGA creando el concepto de FPGA Virtual [119]. Para ello es clave la utilización de técnicas de SAN automatizadas que resuelvan algunos problemas actuales que presentan estas plataformas heterogéneas:  Análisis de la dependencia de datos para extraer el paralelismo necesario que guie al planificador.  Inferencia de la arquitectura de memoria necesaria para optimizar el uso de recursos en la FPGA, especialmente para aplicaciones intensivas en datos o para tener en cuenta las restricciones físicas impuestas por la tecnología de implementación (número de puertos, tamaños de los bloques). Estas restricciones provocan problemas de contención y obligan a generar arquitecturas no optimizadas en términos de latencia.  Aunque en el modelado TLM se separa la computación de la comunicación, lo que ocurre durante la fase de SAN es que hay una dependencia mutua: la elección de la arquitectura de comunicación influirá en la planificación y asignación de recursos y viceversa. Una comunicación orientada al flujo de datos generará una arquitectura también orientada a flujo de datos, con capacidad de optimización como ruta de datos segmentada. Pero esto también influye en la arquitectura de memoria. Se requiere por tanto una optimización de ambos aspectos de forma concurrente.  Es necesario hacer una aproximación holística al problema, optimizando la transferencia de datos y el acelerador como un todo. En [18] se apuesta por integrar lenguajes especializados, tales como OpenCL, con la transformación automática del código C en aceleradores hardware haciendo uso de herramientas de síntesis de alto nivel para incrementar la productividad del diseño, especialmente para el caso de las FPGAs. 60 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas 21) Las decisiones tomadas en alto nivel se deben propagar hasta la implementación final. Es necesario tener en cuenta que la calidad de los resultados finales no depende únicamente de la herramienta de SAN usada sino también de la integración con el flujo de diseño de las herramientas de implementación y con las librerías de diseño. Todas estas recomendaciones se resumen en la tabla 3. Tabla 3. Recomendaciones de modelado N Recomendaciones sobre estilo de modelado y de síntesis 1 Usar tipos de datos ajustados a nivel de bits para reducir área/recursos 2 Usar datos abstractos para facilitar su encapsulado 3 Usar librerías optimizadas para operaciones en coma flotante 4 Usar range() para acceder a los bits 5 Definir valores por defecto para salidas 6 Estructurar el código en funciones 7 Las funciones añaden modularidad al diseño hardware 8 Evitar problemas de comunicación entre procesos 9 No utilizar modelado recursivo ya que no está soportado en hardware 10 Modelado apropiado del protocolo de comunicación a utilizar 11 Proteger zonas dedicadas a protocolos de la acción del planificador 12 Dividir expresiones complejas en varias líneas para su referencia 13 Centralizar parámetros, separar estructura y comportamiento y utilizar un único bloque por fichero facilita la gestión del proyecto 14 Uso del preprocesador para facilitar la portabilidad entre entornos 15 Organizar los objetos de gran tamaño como arrays para su implementación como memorias 16 Inicialización del contenido de los arrays. Diferentes opciones en función de la tecnología 17 Utilizar restricciones en Tcl para facilitar la reutilización de los modelos 18 Atención a la planificación de bucles 19 Aplicar las directivas de síntesis sin generar sobre-restricciones al diseño 20 Realizar la simulación a nivel RTL 21 Las decisiones tomadas en alto nivel se deben propagar hasta la implementación 61 2.7. Conclusione s 2.7. Conclusiones 2.7. Conclusiones En este capítulo se ha realizado una revisión global de la SAN, de su evolución y la presentación de herramientas significativas durante su evolución. Igualmente se han descrito diferentes casos de uso que han permitido crear la experiencia necesaria para abordar este trabajo. Se ha puesto especial hincapié en la necesidad de utilizar lenguajes cercanos a la creación del algoritmo, ya sea en C/C++ o SystemC. Se ha hecho una descripción del estado actual de las herramientas disponibles y se ha esbozado dentro del alcance de este trabajo sus principales características. Para terminar se han resumido, a modo de criterios generales y breves recetas prácticas, algunos de los aspectos que debe tener en cuenta el diseñador para la utilización de metodologías de diseño basadas en SAN con el mayor aprovechamiento posible. Constituyen unos modos de hacer o mejores prácticas en el diseño. Como principales conclusiones de este capítulo podemos resaltar las siguientes: 1) La síntesis de alto nivel está siendo adoptada por la industria con el objetivo de mitigar la crisis de diseño y poder hacer frente a la demanda de aceleración de problemas de gran complejidad y magnitud en los datos. Igualmente está siendo adoptada como metodología de diseño en aquellos casos que requieren una rápida puesta en el mercado del producto y en aquellos casos donde los estándares cambian rápidamente. 2) Se ha producido una evolución y madurez de la SAN basadas, entre otros, en varios aspectos fundamentales: la adopción de un lenguaje apropiado al nivel del problema tratado, la facilidad de verificación en alto nivel y una mejora continua en la calidad de los resultados. Por ello, en SAN es muy importante dar soporte a la “síntesis para la verificación y calidad del diseño”. 3) Desde el punto de vista de alto nivel hay un interés creciente en identificar de forma temprana problemas asociados a la calidad del código C/C++/SystemC para identificar problemas que afectan a los parámetros PPA (Prestaciones, Potencia, Área) del diseño final. Entre estos aspectos podemos citar la detección de código muerto, errores por lectura de memoria no inicializadas, casos no cubiertos en múltiples ramas de decisión, errores de desbordamiento y de división por cero entre otros. 4) A lo largo del capítulo se ha visto la importancia de mantener el nivel RTL como paso intermedio para la verificación y la síntesis de tal forma que no se puede prescindir de este nivel por dos razones principales: a) para verificar el diseño, ya sea mediante simulación, cosimulación o incluso mediante búsqueda de equivalencias con el código fuente (SLEC – Sequential Logic Equivalence Checking), y b) para conectar con flujos de diseño existentes en la industria con alto grado de calidad en los resultados de prestaciones, potencia y área (PPA). Diferentes enfoques para compilar desde el nivel algorítmico, o incluso desde el nivel TLM de transacciones hasta un netlist han resultado insuficientes. Solo en casos muy específicos un compilador de silicio desde el nivel algorítmico funciona bien (compilar una ALU, un filtro, un array...). Una de las mayores preocupaciones de los diseñadores que adoptan metodologías SAN aparece en la verificación tanto del modelo de alto nivel como de las discrepancias de comportamiento del modelo original y del modelo RTL. 62 Capítul o 2. Trabajo previo, estado actual del arte y propuestas prácticas Capítulo 2. Trabajo previo, estado actual del arte y propuestas prácticas 5) Conviene introducir un nivel intermedio entre el algorítmico y el RTL. Este enfoque lo hemos llamado “Doble X”. Es muy útil el nivel de transacciones (TLM2.0 y otros lenguajes equivalentes). La razón es que la visión explícita de las transacciones es la que introduce por primera vez una visión de nivel arquitectural, donde la computación (o funciones algorítmicas), las estructuras de datos, y la comunicación, que componen toda arquitectura, aparecen definidas y separadas. Eso no lo hace el nivel algorítmico, ni mucho menos los modelos de computación. Ese nivel está muy bien soportado hoy por SystemC. Como consecuencia de visualizar y establecer estos dos niveles intermedios, es necesario proporcionar mecanismos que controlen la coherencia de los datos, de las descripciones y las adaptaciones de los resultados de una etapa de síntesis hacia la siguiente. Adaptar (y estandarizar) las salidas de una herramienta del flujo de diseño a la siguiente. Este aspecto de ingeniería del flujo de herramientas y datos en SAN es central en la experiencia de diseño, y en esta tesis. Ejemplos de este flujo se muestran en los casos de estudio y se han comentado en el apartado anterior, como es el caso de hacer uso del preprocesador de C para compatibilizar diferentes vistas del diseño y la utilización de flujos controlados con Makefiles para garantizar la actualización de los datos. Igualmente la utilización sistemática de scripts garantiza la repetitividad de los resultados obtenidos. 6) La adaptación de datos en la ingeniería del flujo de síntesis, incluye el proceso de controlabilidad de la verificación a distintos niveles de la síntesis, incluida la verificación funcional y arquitectural temprana. Es cuantificable el ahorro de esfuerzo de diseño y la mejora en la calidad del diseño si la verificación se hace mediante verificación por etapas. Igualmente la reutilización del testbench desarrollado con altos niveles de abstracción genera ahorros significativos en los tiempos de diseño. 7) Como se ha indicado, es cuantificable que la estructuración al nivel TLM/SystemC, es decir al primer nivel arquitectural, incide fuertemente en la optimización del diseño resultante, con efectos significativos en los parámetros de prestaciones PPA. 8) La síntesis de los mecanismos de generación de transferencias, la síntesis de protocolos, es determinante en el éxito de la adopción de técnicas de SAN. En parte debido al desacoplo computación-datos-comunicación (interconexión). En parte debido a la potencia de las infraestructuras de interconexión que han ido emergiendo, al ritmo del aumento del número de niveles de metal en los circuitos, y de la densidad de transistores para incluir la gestión de los buses y el control de protocolos. 9) Es importante y práctico encapsular la síntesis SAN en diseños IP, es decir completos y reutilizables, standalone. Es debido a que según el enfoque platform based design -de éxito industrialla integración de estos bloques IP en plataformas permite ahorrar tiempo y esfuerzo en la etapa de transformación del diseño desde la plataforma intermedia al target final. Por eso es necesario seguir avanzando en técnicas para flexibilizar el diseño, el IP, para que sea portable para diferentes targets. 10) Se propone una visión de “Doble X” vertical (figura 33). En la primera se mapean tareas y funciones a estructuras TLM o de transacciones definidas por la arquitectura. En la 63 2.7. Conclusione s 2.7. Conclusiones segunda se mapean estas arquitecturas a la clase de plataforma intermedia elegida. La salida de esta segunda X es la implementación del algoritmo ya estructurado y sintetizado en los IPs componentes de la arquitectura de la plataforma, en el target final. Figura 33. Flujo de diseño en “Doble X” Un comentario final. Es útil la exploración del espacio de diseño DSE y el estudio de los diversos algorithm to architecture mapping, (transformación, correspondencia). Pero ese estudio, al igual que el System Level ESL, exceden la temática de esta tesis sobre SAN, que se refiere siempre a descender en la abstracción desde una funcionalidad definida a nivel tarea hasta niveles de implementación inferiores, más detallados, al menos RTL sintetizable, procesable por las herramientas de síntesis lógica. En ESL y System Synthesis debe tratarse apropiadamente la descomposición en tareas, la planificación de las tareas resultantes y su concurrencia y sincronización, la descomposición HW/SW, o la extracción de paralelismo que habilite un mapeado a MPSoC o múltiples núcleos en SW. Pero desde el punto de vista de la SAN para implementación, es importante no desenfocarse en su utilidad, en su objetivo: es mejor no centrarse en las búsqueda de maneras de “extraer” el paralelismo que pueda existir en una descripción secuencial, y centrarse en cambio en facilitar -para el arte del diseñoque los diseñadores puedan expresar fácilmente y con poco costo la concurrencia existente. Y a partir de ahí poder construir implementaciones eficientes -más eficientesde aplicaciones útiles, significativas. Capítulo 3. Caso de aplicación: diseño de un procesador de eventos 3.1. Introducción Recientemente se ha producido un avance importante en las aplicaciones empotradas al poder incorporar aceleradores para aquellas tareas que tienen exigentes requisitos de funcionamiento en tiempo real. Algunos ejemplos de tales aplicaciones son la detección de fraudes para tarjetas de crédito, la detección de intrusión en redes de ordenadores, las transacciones en los mercados financieros o los sistemas de supervisión de la salud de los pacientes. En ellas se requiere el procesamiento de un gran volumen de datos a lo largo de intervalos temporales determinados, o de series temporales, para extraer información significativa. Esta extracción se puede caracterizar por estar basada en eventos complejos que incluyen además una gran cantidad de información a procesar. Se entiende que el procesamiento de eventos complejos es un paradigma de cómputo que partiendo de una secuencia de eventos en tiempo real, extrae información significativa basada en algoritmos o reglas definidos por el usuario y la transforma en nuevos datos que permitan manejar dichos eventos o tomar decisiones sobre ellos, y en otros datos, asociados, de forma integrada. 66 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos En muchos casos el tiempo de respuesta es un factor crítico de cara a la toma de decisiones. Por ejemplo, en aplicaciones del mercado electrónico de valores se especifican tiempos de respuesta del orden de 1 ms, tiempo en que el operador deberá tomar posición para obtener ventaja competitiva. En estos casos una solución completamente software pudiera no asegurar las cortas latencias que se necesitan, ni siquiera cuando explota al máximo el paralelismo de la aplicación. Por ello se puede considerar este tipo de sistemas como candidatos a su implementación con aceleradores hardware. La viabilidad científica e industrial de este proceso en aplicaciones muy variadas depende mucho de la creación y utilización apropiada de metodologías de diseño que faciliten la implementación de los algoritmos y reglas desde el código C/C++, desde el alto nivel. 3.1.1. Sistema de eventos complejos El procesamiento de eventos complejos es un paradigma de computación que permite monitorizar los eventos que se reciben de forma continua en un escenario de tiempo real (soft or hard real time) y reaccionar ante ellos. Los aceleradores de procesamiento de eventos se utilizan en diferentes escenarios críticos tales como detección de fraudes, monitorización de tráfico, mercados de valores, gestión de redes o unidades de cuidados intensivos. En todos estos casos se necesita tener disponible capacidad de cómputo para cumplir con las prestaciones, entre las que frecuentemente se encuentran una alta capacidad de procesamiento y una baja latencia [121]. Los sistemas de procesamiento de eventos complejos se diseñan para procesar flujos de eventos recibidos en tiempo real. Soportan reglas de tipo reactivo que se disparan cuando se encuentran combinaciones de patrones específicos. Para ello se obtienen eventos desde el flujo de datos de entrada (por ejemplo, mediante un análisis sintáctico) obteniéndose una secuencia de eventos que se analiza de acuerdo a patrones de eventos complejos. Este es el caso, por ejemplo, de un broker que querría estar informado al instante de cuando un stock presenta movimientos al alza y a la baja (eventos derivados) [80]. Por ello se emplea el término de “mercado del microsegundo”. En la edad del mercado de valores tecnológico, la latencia en la recepción y el procesamiento de los eventos del mercado es un aspecto crítico que determina una posición estratégica. El aumento de actividad del mercado de valores tecnológico es notable y está basado no sólo en las mejoras introducidas en las redes de datos, sino también en las soluciones algorítmicas para el procesamiento de eventos (78% de incremento entre 1995 y 2009 [122]). 3.2. Sistemas en Tiempo Real (STR) Se ha indicado anteriormente que un procesador de eventos puede ser considerado como un sistema en tiempo real. Y se puede definir un sistema en tiempo real (STR) como aquel sistema digital que interactúa activamente con su entorno con una dinámica conocida entre sus entradas, salidas y restricciones temporales, para establecer un correcto funcionamiento de acuerdo con los conceptos de predictibilidad, estabilidad y controlabilidad [123]. 67 3.2. Sistemas en Tiempo Real (STR) 3.2. Sistemas en Tiempo Real (STR) Se puede hablar de dos tipos básicos de STR: Hard RT y Soft RT. Para el primero de los casos la restricción es completa, con tiempos de respuesta estrictos. Para el segundo, los tiempos de procesamiento pueden estar comprendidos en un determinado margen pero no son críticos cuando la salida sigue una determinada cadencia, aunque presente cierta latencia inicial. Un ejemplo típico de sistema en tiempo real tipo Hard RT es el sistema antibloqueo de las ruedas de un automóvil (ABS). En este caso el tiempo límite en el que debe operar es aquel en el que las ruedas deban liberarse antes de que se bloqueen. Si el sistema libera las ruedas una vez que ya se han bloqueado, habrá fallado [5, 6]. Un ejemplo de sistema Soft RT puede ser un sistema de codificación, transmisión de vídeo y decodificación de vídeo [126]. Figura 34. Esquema básico de un procesador de eventos complejos Un sistema de procesado de eventos es un tipo de sistema en tiempo real. Existe una tasa de llegada de eventos que deben ser procesados en un tiempo, determinado por el periodo de muestreo de eventos. En general existirán unas condiciones y reglas que determinan la reacción del sistema ante determinados eventos. El procesado consiste en comprobar si cada evento de entrada cumple o no algunas de las condiciones impuestas con anterioridad y decidir, en base a ello, la acción a realizar. Un ejemplo son los sistemas automatizados de compra y venta en el mercado de valores. Estos sistemas deben decidir realizar una acción de compra o venta en función de los cambios y tendencia en los precios de los productos y de unas estrategias previamente establecidas [127]. El funcionamiento de los sistemas de procesado de eventos se puede dividir en las siguientes tareas: captura y filtrado de eventos, procesado de los eventos y generación de las acciones (figura 34). Durante la captura y filtrado, se requerirá que el sistema obtenga los eventos temporales que se producen en su entorno y filtre aquellos parámetros que sean de utilidad para su posterior procesado, descartando aquella información sobrante que pueda sobrecargar innecesariamente al resto de tareas. Durante el procesamiento se realizarán las operaciones definidas mediante reglas de procesamiento con el fin de comprobar si se cumplen una o varias condiciones previamente establecidas. En la fase final, la generación de acciones, se activan las acciones a realizar en función de las reglas activadas. Para poder procesar los eventos entrantes en el sistema debe cumplirse la siguiente restricción temporal: 𝑡𝑐+ 𝑡𝑝+ 𝑡𝑎≤ 𝑡𝑟 donde tc es el tiempo de captura, tp es el tiempo de procesado, ta es el tiempo requerido para la generación de acciones y tr es la restricción impuesta de tiempo real. (1) 68 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos 3.3. Alternativas de implementación Los sistemas de procesado de eventos se pueden ejecutar sobre diferentes plataformas arquitecturales con objeto de cumplir con la restricción temporal indicada anteriormente y con la flexibilidad requerida en cuanto a costes del sistema. Las diferentes soluciones encontradas en la literatura científica van desde el uso de circuitos integrados de aplicación específica (ASIC) hasta el uso de microprocesadores de propósito general. La solución más flexible es ejecutar el STR sobre un procesador de propósito general (General Purpose Processor – GPP). Un GPP está preparado para poder realizar cualquier tarea, mediante la ejecución de un determinado programa, lo que representa una solución muy adaptable a diferentes tipos de procesamiento. Sin embargo tiene la desventaja de ser poco eficiente para determinadas operaciones, especialmente las orientadas a tratar bits de forma individual, e igualmente su consumo de potencia puede no ser aceptable en determinados escenarios. Esta solución GPP se centra en el dominio software, donde las aplicaciones se pueden compilar, modificar y recompilar, permitiendo así optimizar el diseño tras varias iteraciones. La concurrencia explotable tiene las limitaciones propias del algoritmo y de la dependencia de datos, pero también varias limitaciones adicionales derivadas del compilador. Por contra, una ventaja es que la programación de las aplicaciones se puede hacer en lenguajes de alto nivel como Java, C++, etc. En el lado opuesto se ubican soluciones a medida basadas en circuitos integrados de aplicación específica (ASIC). Al contrario que los GPP, se trata de soluciones circuitales diseñadas de forma optimizada para una aplicación concreta, restringiendo su programabilidad pero incrementando su eficiencia. Otra característica fundamental de esta alternativa es la posibilidad de concurrencia real entre tareas, al incluir en el circuito integrado diferentes módulos que realizan el procesamiento paralelo de los flujos de datos capturados. En un ASIC, el flujo de diseño parte de una descripción, normalmente realizada en lenguajes de descripción hardware (HDL), tales como Verilog o VHDL, tradicionalmente a nivel RTL. Los bloques descritos en estos lenguajes se sintetizan posteriormente haciendo uso de las librerías tecnológicas de los fabricantes. Como se ha comentado ampliamente en el capítulo anterior, en la actualidad se ha incrementado el nivel de abstracción pasando a usar lenguajes de descripción de sistemas electrónicos (ESL), generalmente basados en C/C++ o SystemC [83], que tras una síntesis de alto nivel (HLS), transforma la descripción algorítmica en una microarquitectura a nivel RTL. La microarquitectura resultante se optimiza e implementa siguiendo flujos de síntesis de alto nivel [9, 10, 11]. El ASIC requiere un proceso de verificación complejo para garantizar su funcionamiento desde el primer diseño. Por ello las FPGAs facilitan las tareas iniciales de prototipado, y pueden también ser consideradas como alternativas de implementación frente a los GPP y los ASIC. Las FPGAs poseen recursos de memoria internos, bloques funcionales, en algunos casos incluso uno o varios núcleos procesadores, y otros bloques funcionales de interfaz que facilitan la implementación de un sistema electrónico en chip (SoC) [128]. 69 3.4. Arquitectur a de los procesador es de eventos 3.4. Arquitectura de los procesadores de eventos Las principales ventajas del uso de FPGAs frente a otras soluciones de diseño electrónico son el bajo coste durante las fases de desarrollo del sistema, la producción de un reducido número de unidades (frente al coste de fabricar un ASIC) y su sencilla reprogramabilidad. Esta última propiedad permite una optimización post-diseño. Es aquí donde esta tecnología tiene una ventaja competitiva para este tipo de problemas de procesado de eventos. Los kits de diseño que proporcionan los fabricantes incluyen placas sobre las que vienen interconectadas las FPGA con diversos recursos, entre ellos bloques de interfaz como pueden ser USB, Ethernet, etc. Además, también incluyen sus propias fuentes de reloj, bloques de memoria e incluso, como se ha dicho, CPUs. Otra posible implementación es el uso de GPUs (Graphics Processing Unit). Los entornos de desarrollo proporcionados por los fabricantes, hacen que la GPU -originalmente creada para explotar el paralelismo existente en el procesamiento de gráficossea cada vez más flexible, permitiendo su uso para la ejecución de aplicaciones genéricas (GPGPU – General Purpose computing on GPU). Aunque su programación no es tan flexible como para el caso de las CPUs de propósito general, su gran cantidad de elementos de cómputo, junto a su arquitectura optimizada para la concurrencia mediante paradigmas SIMD (Single Instruction Multiple Data) y SPMD (Single Program Multiple Data), puede ser de utilidad en el procesamiento de eventos, cuando se requiera realizar la comparación de una gran cantidad de ellos sobre una misma condición. Por último podemos citar los DSPs (Digital Signal Processor), que son procesadores optimizados para el procesado de señales, siendo normalmente especializados en operaciones del tipo MAC (Multiplicación/Acumulación). Este tipo de procesadores son más eficientes que las CPUs o las GPUs, pero mucho menos flexibles en su programación. En la figura 35 se comparan las diferentes soluciones indicadas, teniendo en cuenta su eficiencia frente a su flexibilidad. Se aumenta la eficiencia del sistema moviendo funciones del dominio software –por tanto ejecutadas en un GPP, más flexibles– a su implementación en el dominio hardware, más eficientes pero menos flexibles. En este caso, con objeto de mantener una cierta flexibilidad en el desarrollo de estas funciones, se emplean técnicas de diseño basadas en la síntesis de alto nivel. 3.4. Arquitectura de los procesadores de eventos Se define un procesador de eventos, en su versión más simple, como un sistema que ejecuta una acción en el caso de que se presenten determinadas condiciones en un conjunto de eventos de entrada. La arquitectura del procesador puede dividirse en cuatro grandes bloques: interfaz de entrada, núcleo de procesamiento, ejecutor de resultados e interfaz de salida (figura 36). 76 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos A diferencia del caso anterior, el esfuerzo de diseño se centra en la síntesis de los procesadores de eventos, su interconexión y su integración con los módulos de entrada y salida de eventos. En la figura 41 se representa la arquitectura general de esta solución. Como se puede observar, el sistema consta de una interfaz de red Gigabit Ethernet, conectada al microprocesador externo, que envía las tramas de eventos a los bloques de procesamiento (que incluyen la interfaz, el núcleo de procesamiento, el ejecutor de resultados y las memorias que almacenan el estado del procesador). Existe una interfaz con memoria de alta velocidad DDR usada por la CPU. La principal característica de esta arquitectura es que las estrategias de comparación son las que definen el esquema lógico de los procesadores, consiguiendo una mayor tasa de procesado, a costa de la flexibilidad, ya que no se modifican las estrategias en tiempo de ejecución. Figura 40. Arquitectura basada en multi-core soft-processor 3.7.3. Arquitectura de implementación híbrida Esta solución plantea un punto intermedio en el espacio de soluciones, entre las dos descritas anteriormente. La principal característica de esta implementación es que dispone de núcleo CPU interno en tareas de planificación y supervisión y comunicación, y elementos hardware de proceso, en forma de aceleradores, cuyas estrategias de procesamiento y reglas se almacenan en memoria interna del dispositivo, en memoria de configuración de cada elemento de proceso. Mantener la configuración en memoria, aunque los accesos a memoria ralentizan el procesado frente a la solución hardware, permite una mayor flexibilidad, ya que facilita la 77 3.7. Soluciones arquitectur ales 3.7. Soluciones arquitecturales modificación de las estrategias mediante la alteración de los parámetros y datos almacenados en dichas memorias. Además de esto, pueden reutilizarse los núcleos de procesamiento para varias estrategias, permitiendo así una mayor capacidad. Figura 41. Arquitectura de implementación hardware Para permitir la modificación del contenido de los bloques de memoria internos existen dos posibilidades: Modificarlas a través del puerto JTAG para una implementación basada en FPGA, opción dependiente de la tecnología. Integrar un bloque dedicado a la recepción de tramas de estrategia que modifiquen el contenido de las memorias, solución general. Para implementaciones basadas en FPGA, en función de la ocupación del procesador de eventos y de la capacidad del dispositivo programable, puede replicarse el núcleo de procesamiento para aumentar el rendimiento del sistema final. En este caso es necesario implementar una unidad de despacho, que identifique eventos asociados a una u otra estrategia. En este tipo de soluciones, no es posible realizar procesado de eventos fuera de orden, al existir condiciones de disparo que hacen alusión a tendencias de atributos de títulos. En la figura 42 se muestra un ejemplo de arquitectura híbrida. 3.7.4. Comparativa entre arquitecturas Las tres soluciones planteadas proporcionan tres puntos diferentes del espacio de soluciones entre prestaciones y flexibilidad/capacidad del sistema. En la figura 43 se presenta de forma cualitativa la relación entre estas arquitecturas, presentando los resultados sobre los ejes ya comentados. La relación entre las prestaciones y la carga de eventos se representa en la figura 44. También cabe destacar que, en función de las necesidades del sistema, puede descartarse algunas de las soluciones. Un ejemplo es la necesidad de modificar las estrategias en tiempo de 78 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos ejecución, lo cual no es viable con una solución hardware, siendo necesaria una solución híbrida o basada en soft-processor. Figura 42. Arquitectura híbrida Figura 43. Comparativa entre arquitecturas 3.8. Paradigma de modelado Para el modelado del sistema se parte de la aplicación RT-CORE ya desarrollada y escrita en C/C++, que servirá como modelo de referencia para la verificación de la funcionalidad. De igual forma se utilizará para la realización de las medidas de rendimiento y para las mejoras del diseño planteado. A partir de la aplicación se realiza su perfilado estático y dinámico. El objetivo es determinar aquellas funciones, que representan el núcleo de procesamiento del sistema con mayor carga computacional, candidatas a ser implementadas como aceleradores hardware. Las técnicas utilizadas se pueden resumir en el análisis de ciclos de computación, ocupación de memoria, grafo de llamadas dinámico, iteraciones, saltos. Este tipo de análisis está soportado por herramientas tipo gprof, valgrind o kcachegrind. 79 3.8. Paradigma de modelado 3.8. Paradigma de modelado Figura 44. Efecto sobre las prestaciones de la carga de eventos procesados para las tres alternativas A partir de este análisis se realiza la partición del sistema en bloques funcionales, utilizando módulos descritos en SystemC para cada bloque funcional. La aplicación se ha descompuesto en 34 módulos de procesamiento y 29 módulos de gestión de acceso a memoria local. Para la partición del sistema es necesario definir la interfaz de señalización entre módulos. Se ha utilizado un modelado a nivel de transacciones (TLM) de ciclo aproximado (CX)[134], en el que se abstraen los tipos de datos y se define un protocolo de señalización basado en petición respuesta (Request/Validate). La definición de los buses de datos y de señalización a nivel de ciclo será una de las tareas de la herramienta de síntesis de alto nivel para obtener una representación precisa a nivel de pines y de ciclos (Pin Accurate/Cycle Accurate – PA/CA). Durante el proceso de partición en bloques funcionales se ha mantenido agrupada la funcionalidad de la aplicación original para facilitar la localidad de los datos y facilitar su agrupamiento en estructuras fácilmente asignables a memorias locales. El modelado de los tipos de datos es un aspecto clave por varias razones. En primer lugar la aplicación utiliza operaciones de suma, multiplicación y división en punto flotante cuya implementación en hardware es costosa. Para ello se han transformado las operaciones indicadas a sus operaciones equivalentes en punto fijo. En este proceso la pérdida de precisión puede ocasionar problemas en la funcionalidad del sistema (operaciones de comparación, etc.). Por ello ha sido necesario determinar los límites máximos y mínimos en los valores de los parámetros y variables de la aplicación. Para dar soporte a las operaciones se ha utilizado una librería de operadores optimizada para operaciones en punto fijo. Por otra parte, para parametrizar los buses de datos y mantener la flexibilidad de propagación de cambios en el modelo se ha optado por definir tipos de datos organizados en estructuras de datos parametrizables. La compatibilidad de tipos de datos representa otra de las fortalezas del modelo, siendo necesario utilizar las funciones de conversión de tipos 80 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos aportados por SystemC de forma explícita para evitar incongruencias en la construcción del modelo final del sistema. Los bloques de procesamiento pueden dividirse, según su funcionalidad, entre los bloques conceptuales presentados anteriormente: interfaz, núcleo de procesamiento, ejecutor de resultados y estado del procesador. De acuerdo con la metodología de diseño y el flujo de síntesis propuesto el desarrollo del entorno de verificación se ha realizado también en SystemC. En este modelo SystemC se incluye una parte de las funciones que se implementarán posteriormente en el dominio software y que forman parte fundamental del sistema. Además será necesario incluir algunas funciones auxiliares, como por ejemplo la lectura de datos de test desde ficheros, que después serán sustituidas por lecturas desde los sockets de la interfaz Ethernet. Este entorno de verificación será reutilizado a lo largo del flujo de diseño como se ha comentado, mediante la creación de adaptadores o wrappers que adaptan las señales a nivel RTL. 3.9. Metodología de diseño En todo diseño, ya sea hardware y/o software se pueden enumerar tres fases claves en la metodología de diseño: especificación, diseño y verificación. En la fase inicial se analizan las especificaciones del sistema a realizar, ya sean estas funcionales, temporales o estructurales. Una vez definidas y acotadas, se procede al diseño del sistema en el que se decide la tecnología, las etapas de desarrollo, la partición del diseño (si la hubiese), etc. Esto produce una primera versión funcional del sistema, que se utiliza para una primera verificación a ese nivel funcional. En el diseño del procesador de eventos, los datos de entrada al sistema se recogen como tramas TCP/IP. El tratamiento de la comunicación implica la extracción de la carga útil de datos de los paquetes y el tratamiento de los paquetes de control. Para dar solución a estos requerimientos se diseña un System-on-chip (SoC) heterogéneo del tipo híbrido definido más arriba, y formado por un microprocesador empotrado, un conjunto de aceleradores hardware, y un conjunto de periféricos interconectados (Buses, DMA, etc.). De esta forma, el procesador de eventos se comporta como un procesador dedicado integrado en una plataforma SoC heterogénea, siendo el microprocesador principal el encargado de preparar las tramas de datos y hacerlas disponibles. Los datos de entrada del procesador de eventos se estructuran como un paquete de datos organizados al byte, con un formato definido y que son analizados por la aplicación software que es ejecutada en el microprocesador empotrado. Dichos datos, una vez compactados se envían al bloque acelerador que los procesa [23]. Es necesario por tanto abordar las siguientes tareas: Diseño de la plataforma, en el que se incluye la selección de aquellos bloques IP necesarios, así como del diseño del software embebido a ejecutar en el microprocesador. 81 3.9. Metodologí a de diseño 3.9. Metodología de diseño  Diseño del procesador de eventos, tomando como especificación la aplicación software disponible. La metodología incluye la etapa de validación. Para validar esta opción de diseño se han realizado dos implementaciones. En primer lugar se ha optado por la implementación sobre una FPGA Virtex-5 disponible en la tarjeta de desarrollo ML510 de Xilinx. Este dispositivo posee dos núcleos microprocesadores PowerPC440 empotrados en la FPGA como hard IP. De igual forma, la tarjeta posee dos puertos Gigabit Ethernet que permiten disponer de ancho de banda suficiente para la implementación del prototipo. En segundo lugar se ha realizado una implementación ASIC del bloque IP diseñado para el procesador de eventos. En la figura 45 se muestra el flujo de diseño utilizado para el caso de la FPGA. Este flujo incluye el diseño de la plataforma. En general, se parte de la misma descripción funcional del sistema por lo que las etapas iniciales del flujo serán comunes con el diseño del ASIC, aunque optimizadas para la tecnología destino. La síntesis de alto nivel y la síntesis lógica serán -en cambiomuy dependientes de la tecnología a utilizar, siendo el espacio de soluciones más reducido en el caso de las FPGAs. Además de esto, la fase de implementación está mucho más acotada en un dispositivo como una FPGA donde los recursos están pre-asignados a una posición definida, siendo necesaria únicamente su programación. En las siguientes secciones se describen en más detalle las fases seguidas en el diseño. 3.9.1. Fase de análisis En esta fase de análisis del diseño se obtiene el perfil de ejecución de la aplicación original. El objetivo es disponer de la información relativa a la complejidad de la aplicación, su modularidad, así como características de coste computacional y temporal de las distintas funciones que la componen. Esta información, junto a un estudio de la dependencia de datos, facilita la toma de decisiones relacionadas con la partición de la aplicación, las necesidades de comunicación y su conectividad durante la fase de diseño, produciendo como resultado la jerarquía del diseño del procesador y los elementos de procesamiento y sus respectivos recursos. 3.9.2. Diseño del procesador de eventos En el diseño del procesador de eventos se sigue el flujo de síntesis de alto nivel establecido. La primera fase consiste en la captura del diseño, es decir, traducir la aplicación a una descripción funcional de alto nivel en SystemC. En esta primera fase se definen las particiones internas del procesador de eventos, los protocolos de comunicación y sincronismo, así como las memorias que son accedidas por distintos módulos. Es también en esta etapa donde debe definirse la interfaz del procesador de eventos mediante el protocolo con el que se comunicará con el resto del sistema siguiendo metodologías TLM. 82 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Figura 45. Diagrama del flujo de diseño Cuando la descripción del procesador de eventos haya sido verificada mediante simulación a nivel ESL, comparando su funcionalidad con la de la aplicación original en términos de entrada/salida, se pasa a la primera fase de síntesis o síntesis de alto nivel, que traducirá el diseño a una descripción a nivel RTL en VHDL o Verilog. Existen parámetros objeto de optimización a la hora de sintetizar el diseño, entre los cuales se destacan las prestaciones, la potencia y el área (PPA). En muchos casos habrá que establecer una estrategia final ya que no es posible optimizar todos los parámetros indicados de forma simultánea. Es decisión del diseñador, en función de sus requisitos, guiar la síntesis con el fin de obtener la solución 83 3.9. Metodologí a de diseño 3.9. Metodología de diseño deseada. Conviene tener presente que todo diseño es en última instancia un proceso creativo. Estas decisiones de optimización se incluirán en todos los niveles de síntesis, tanto de alto nivel y lógica, como en la síntesis física. En la siguiente fase es preciso verificar que la solución obtenida tras la síntesis de alto nivel mantiene la funcionalidad especificada inicialmente. En caso contrario será necesario ajustar las restricciones impuestas al diseño e incluso la descripción de alto nivel, de forma que la funcionalidad de la solución obtenida a nivel RTL coincida con la de su diseño capturado, de entrada. Una vez obtenida una descripción a nivel RTL, se realiza la fase de síntesis lógica que lo traduce a un diseño compuesto por la interconexión de células básicas de la librería tecnológica. Esta fase tiene por objetivo la obtención de un netlist (fichero de instancias de células básicas y sus conexiones), generalmente NGC o EDIF para el caso de FPGA, normalmente Verilog para el caso de un ASIC. Los parámetros objetivo son, por una parte, la determinación del tiempo de ciclo y, por otra, la optimización del área/recursos utilizados (figura 46). Figura 46. Diseño del procesador de eventos 3.9.3. Diseño de la plataforma A continuación se acomete la implementación en la plataforma. El diseño de la plataforma hardware comienza con la creación del sistema, fase en la que se instanciarán los diferentes bloques IP necesarios, configurando aquellos atributos parametrizables en su caso. En este paso se importará también el procesador de eventos y se conectará al resto del sistema usando una interfaz de interconexión estandarizada, en este caso LocalLink, bus propietario de Xilinx [23]. Será necesario seguir el flujo de diseño apropiado para la implementación sobre una FPGA, es decir, sintetizar el diseño (desde la descripción HDL correspondiente), asignarlo o hacerlo 84 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos corresponder (mapearlo) sobre los elementos disponibles en la tecnología sobre la que se implementa el diseño, y decidir la colocación de cada uno de estos elementos y su ruta de interconexión. El siguiente paso consiste en el diseño del software del sistema, eligiendo el sistema operativo sobre el que se ejecutará la partición software de la aplicación y las tareas auxiliares, así como aquellas librerías necesarias para dar soporte a los periféricos. El último paso es añadir la aplicación de usuario, en este caso la aplicación que recibe los eventos por la interfaz de entrada al sistema –en el caso que nos ocupa se trata de tramas TCP/IP–, que realiza su preprocesamiento si fuera necesario, y los envía al acelerador hardware diseñado anteriormente. A continuación, la aplicación software, así como las librerías asociadas, deberán compilarse y enlazarse para generar un fichero ejecutable, típicamente en formato ELF, que se ejecutará en el microprocesador de la plataforma. El siguiente paso es la validación de la plataforma. Con el fin de validar el correcto funcionamiento del sistema se deberá descargar el fichero de configuración de la FPGA generado tras la implementación, así como el ejecutable para el microprocesador. Hecho esto, se enviarán eventos a través de la interfaz Gigabit Ethernet y se esperarán las tramas de salida del mismo. 3.9.4. Verificación y validación del sistema La fase de verificación se realiza a distintos niveles de abstracción, así como sobre distintas vistas del diseño. Para ello, se realiza la verificación funcional del sistema tanto en su descripción ESL como a nivel RTL, la verificación física tras su implementación, y la verificación del comportamiento temporal mediante un análisis del slack (u holguras) de todas las rutas lógicas del diseño. Finalmente se realiza el prototipado del sistema, verificando así su funcionalidad final y en tiempo real. Esta última verificación la denominamos validación del sistema. 3.10. Síntesis del procesador de eventos En este apartado se describen las etapas de síntesis de alto nivel y verificación del diseño RTL generado para el procesador de eventos del sistema. Se pretende mostrar el flujo de diseño partiendo de un software de referencia que se transforma a una especificación funcional en SystemC (captura del diseño), y desde ella obtener un modelo sintetizado y optimizado, que pueda posteriormente integrarse en la plataforma para el desarrollo y validación del sistema final. Se trata de obtener un diseño SystemC, particionado y basado en la aplicación software original que describe su funcionalidad, transformado la aplicación para ser así ejecutada en hardware aprovechando las mejoras que esto supone. Desde SystemC se trata de sintetizar el sistema. Se pretende en este apartado definir directrices sobre los pasos a seguir para la síntesis y verificación de un sistema hardware complejo formado por un conjunto de bloques funcionales interconectados. 85 3.10. Síntesis del procesador de eventos 3.10. Síntesis del procesador de eventos 3.10.1. Criterios de optimización En general, a la hora de realizar la transformación de una descripción funcional a una microarquitectura, existen varios factores a optimizar: ciclos de latencia, periodo de reloj, uso de recursos y potencia consumida, entre otros. En general, estos factores dependen entre sí, de tal forma que disminuir el tiempo de ciclo de reloj puede ir asociado a un incremento en el uso de recursos o a un mayor número de ciclos de latencia. Esta dependencia entre los factores hace imposible optimizar todos conjuntamente, siendo necesario establecer un compromiso en función de los requisitos del sistema como veremos. 3.10.2. Estrategias de síntesis A la hora de realizar la síntesis, existen principalmente dos estrategias a valorar: top-down y bottom-up. Ambas se basan en la partición del sistema en módulos más simples y ligeros, que al interconectarlos consiguen la funcionalidad del módulo principal. En general, al módulo que integra e interconecta al resto se le conoce como “top del diseño”. La estrategia top-down (figura 47) consiste en crear un proyecto único para la síntesis, que tenga como módulo principal el top, el cual instancia el resto de bloques, y causa también que la propia herramienta los sintetice y conecte. Por el contrario, una estrategia bottom-up (figura 48) se basa en la síntesis por separado de cada bloque integrado en el sistema para finalmente integrarlos todos mediante un módulo top dedicado únicamente a definir la conectividad entre ellos. Es necesario también tener en cuenta los efectos en los bordes de los módulos para facilitar la interconexión. Veremos más adelante que ambos procesos se pueden combinar para llegar a un compromiso entre tiempo de síntesis y calidad de los resultados. Figura 47. Estrategia top-down 92 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Figura 49. Vista del Control and Data Flow Graph (CDFG) Figura 50. Análisis de ruta crítica Análisis de área En un diseño sobre FPGAs los análisis de área están orientados a conocer los recursos consumidos por el diseño. En el caso del ASIC por el contrario, este análisis mostrará los distintos tipos de recursos utilizados por el diseño, en función de la información disponible en la librería tecnológica del fabricante. La herramienta de síntesis de alto nivel permite, tras obtener la arquitectura RTL del módulo estimar el área consumida por cada módulo del diseño, tal y como se muestra en la figura 51, organizado como área combinacional y área secuencial. La herramienta de síntesis genera un bloque para cada función del código SystemC, y además 93 3.10. Síntesis del procesador de eventos 3.10. Síntesis del procesador de eventos incluye lógica adicional para las llamadas a cada función. El consumo de área puede visualizarse organizado por funciones. Figura 51. Análisis de área Análisis de potencia Otro de los resultados a analizar para determinar la calidad de la arquitectura obtenida es el “consumo” o nivel de potencia y por tanto la energía consumida. La potencia influye en el diseño de la fuente de alimentación y en el diseño de las interconexiones. La potencia disipada en el circuito es un factor determinante de su coste y fiabilidad. En el caso de que el circuito vaya a ser utilizado en sistemas de altas prestaciones es preciso reducir los costes de enfriamiento (encapsulados, sistemas de refrigeración) e incrementar la fiabilidad de los mismos. Para el caso de sistemas portables alimentados por baterías, el objetivo es alargar su duración entre recargas y minimizar el número de recargas durante su vida útil. Aquí el factor predominante es la energía determinada por la expresión 𝐸 = ∑𝑃𝑖× 𝑡𝑖𝑖 . Las decisiones tomadas en la síntesis de alto nivel tienen gran impacto en términos de calidad de resultados (QoR) (figura 52). Esto es aplicable tanto a nivel de recursos (área) como de prestaciones (potencia consumida y tiempo de ejecución). Es posible reducir hasta el 80% el consumo con decisiones adecuadas en alto nivel. Estas decisiones en alto nivel intervienen de forma determinante en el comportamiento del dispositivo final [135]. A nivel RTL, los principales métodos referenciados de reducción del nivel de potencia son los siguientes [136]:  Clock gating: utilizado para reducir la potencia dinámica de conmutación en la ruta del reloj. Es el método más utilizado (54%).  Power gating: permite la reducción de la potencia disipada por corrientes de fuga desconectando la fuente de alimentación en las zonas no operativas del circuito 94 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos para determinados modos de operación. Para ello se utilizan elementos básicos tales como switches de control de VDD y GND, células de aislamiento y Flip-Flops de retención de estados SRFFs. Su utilización es del orden del 48%. Combinación entre clock gating, y escalado dinámico de tensión y frecuencia (DVFS) (40%) (figura 53) [135]. Figura 52. Oportunidades de optimización de potencia en diferentes etapas del diseño A diferencia de los métodos citados a nivel RTL, en síntesis de alto nivel es posible optimizar el consumo de potencia con otros métodos. Durante la fase de modelado, la realización de optimizaciones en el código fuente ya permite reducir el consumo de potencia, ya sea en la fase de computación, de comunicación o de almacenamiento del modelo, tal como se muestra en la figura 54. a) Impacto de la arquitectura de memorias en la potencia El diseño de alto nivel de la arquitectura de memoria igualmente afecta al consumo de potencia, al igual que a las prestaciones del sistema final. Ejemplos de medidas a adoptar pueden ser, entre otras, las siguientes: acceso a datos locales para disminuir el tráfico de datos con memoria, organización de la memoria en bloques para activar únicamente aquellos que son accedidos y dejar el resto inactivos. Durante la síntesis de alto nivel es también posible utilizar diferentes configuraciones de direccionamiento, ancho de palabras y relación de aspecto de los arrays de tal forma que se habiliten los recursos precisos, especialmente sensibles para el caso de las FPGAs. Por ejemplo en CtoS, durante la fase de definición de la microarquitectura es posible realizar la separación (split) en múltiples bancos de memoria independientes y la unión (merge) del array para su posterior implementación como una memoria o banco de registros. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Arquitectura Síntesis Netlist Layout Potencial de optimización de potencia 95 3.10. Síntesis del procesador de eventos 3.10. Síntesis del procesador de eventos Figura 53. Efecto de la reducción de la tensión de alimentación Figura 54. Modificaciones del código fuente para aumentar la calidad de resultados Este proceso puede basarse en el esquema de direccionamiento (por ejemplo, se implementan en bloques separados las direcciones pares e impares –bit menos significativo– o cualquier otro) o en datos (por ejemplo, se separa la palabra en dos partes y se implementa cada una de ellas en bloques de memoria separada). La primera opción produce mejores resultados en términos de consumo de potencia ya que se activa únicamente el bloque en el que se produce la lectura/escritura. Si generalizamos este concepto, desde el punto de vista de la optimización de potencia es más eficiente partir la memoria local y asignarla a los diferentes bloques de procesamiento. Esta decisión de diseño, especialmente para el caso de utilización de bloques de memoria RAM (BRAM) en las FPGAs puede generar implementaciones poco eficientes desde el punto de vista de los recursos. 96 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Es posible reestructurar los arrays multidimensionales presentes en el modelo funcional para su implementación RTL, realizando una utilización eficiente de los recursos, a la vez que una reducción del consumo de potencia (figura 55). Con ello es posible adaptar el array al tamaño real del bloque disponible, ya sea para librerías ASICs o de FPGAs, en las que existen unos determinados módulos, con una relación de aspecto y tamaños definidos. Mediante esta operación, el diseñador puede acomodar el array original en una librería de IPs concreta. En el diseño objeto de este trabajo se ha utilizado un modelo monolítico de memoria de tal manera que las estructuras de datos definidas por el diseñador se mapean en memoria de forma directa, concatenando los campos de las estructuras, para obtener memorias cuyo ancho de palabra es la suma de los campos componentes y el tamaño en palabras es equivalente al definido en el array cuyo tipo depende de la estructura definida. La alternativa es usar un modelo fragmentado por campos de la estructura de datos. Si bien esto facilita el acceso a cada componente de la estructura al estar ubicada en diferentes bloques de memoria, se incrementa de forma notable el correspondiente uso de recursos para el caso de la FPGA e incrementa la complejidad de gestión de los bloques de memoria en la implementación ASIC. b) Impacto de la arquitectura de conexiones en la potencia La utilización de buses locales dedicados entre bloques contribuye a la reducción del consumo de potencia ya que reduce el acceso a buses globales, con alto grado de actividad. El objetivo a conseguir consiste en añadir recursos para consumir menos potencia, hasta un cierto compromiso. Esto puede ir acompañado de técnicas de explotación de la regularidad (productor/consumidor) que simplifiquen el esquema de interconexión. c) Impacto de la arquitectura de la ruta de datos en la potencia Igualmente, la utilización de técnicas de segmentación en la ruta de datos y de aumento del paralelismo permite aumentar o disminuir la frecuencia de funcionamiento para obtener las prestaciones requeridas, con la correspondiente consecuencia en el consumo de potencia. d) Guiado de la síntesis en la planificación: CtoS, Cynthesizer, Vivado La síntesis de alto nivel da soporte a todas estas decisiones arquitecturales durante la etapa de planificación temporal o scheduling. CtoS posee métodos para optimizar el diseño para bajo consumo de potencia usando la opción –low_power durante la fase de planificación schedule –low_power. En este modo el planificador realiza un análisis temporal multi-ciclo y evalúa las operaciones que están en la ruta crítica. Usando estos resultados, el planificador elige el mejor conjunto de recursos en términos de retardo, área y potencia. El análisis se repite en diferentes etapas del proceso de planificación. Aquellas operaciones no críticas se sintetizan e implementan usando recursos más eficientes en término de uso de recursos y potencia, para obtener menor área. Igualmente, en el caso de que aparezca slack negativo, este será más equilibrado o balanceado entre las etapas planificadas, y por tanto será de más fácil corrección. 97 3.10. Síntesis del procesador de eventos 3.10. Síntesis del procesador de eventos Figura 55. Modificación del factor de forma de los arrays para su implementación[81] 98 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Se puede obtener un informe detallado del consumo de potencia estimado de todos los recursos del diseño mediante la orden report_power después de utilizar el comando analyze -power para anotar la información de potencia en la base de datos. Esta información puede obtenerse antes de la planificación del diseño o post-planificación, siendo más precisa en este último caso. Desde el punto de vista del flujo de diseño es preferible hacer una planificación con poco esfuerzo (schedule_effort low) y anotar los resultados obtenidos postplanificación. El número de diferentes arquitecturas que es posible explorar está limitado principalmente por la duración del proyecto, siendo este un factor crítico que afecta a la calidad de los resultados. Por ello la síntesis de alto nivel ayuda a la toma de decisiones sobre la determinación de la arquitectura final. A partir de la decisión tomada, la síntesis de alto nivel proporciona un rápido camino hacia la implementación final. Como se ha indicado, la arquitectura de memoria posee un gran impacto en el consumo de potencia y por tanto es preciso darle prioridad en el proceso de diseño. Cynthesizer [137] pone énfasis en tres aspectos de la optimización de potencia. Por una parte utiliza la técnica de clock-gating en los registros del diseño. Igualmente reduce el porcentaje de nodos que conmutan en las salidas de las máquinas de estado finito eligiendo la codificación apropiada, y por último, optimiza (reduce) el número de lecturas especulativas de memoria. Stratus [120] minimiza el consumo de potencia reordenando la planificación de operaciones. En general, el consumo de potencia se incrementa con el uso agresivo de las técnicas de pipelining ya que incrementa la utilización de los recursos, pero con un comportamiento no lineal ya que el uso de los recursos en el caso de que no se use segmentación (puramente secuencial) es muy bajo y poco eficiente [138]. Vivado HLS [139] es un entorno de síntesis de alto nivel desde C/C+/SystemC integrado en el entorno Vivado de Xilinx [140]. Los criterios de optimización de potencia aplicados son de tipo genéricos, ya citados en el presente apartado. 3.11. Verificación RTL Durante el proceso de síntesis de alto nivel el diseño se transforma desde una descripción algorítmica -con información temporal en las interfaces de comunicaciones y relajada en la de procesamiento y, en nuestro caso, con interfaces de datos abstractasa una descripción RTL, constituida por bloques en HDL (VHDL/Verilog) e interfaces precisas a nivel de señales y de ciclos. Durante el proceso de síntesis de alto nivel, con el objeto de cumplir las prestaciones requeridas, se toman decisiones que pueden afectar a la funcionalidad del diseño. Esta situación se presenta tanto en la planificación de las interfaces (mapeado o asignación de datos a señales, mapeado de estados, precisión del modelo de datos utilizado, mapeado de interfaces con memoria) como en la generación de la ruta de datos. 99 3.11. Verificación RTL 3.11. Verificación RTL Otra situación que es normal en el flujo de diseño de un sistema complejo es realizar la partición del sistema en bloques manejables por el diseñador, creando la correspondiente jerarquía de diseño, sintetizando cada bloque por separado. Las situaciones descritas requieren una coverificación del código RTL generado, con el objetivo de comprobar que el modelo continúa siendo funcionalmente equivalente al diseño original. Las descripciones en C, SystemC y RTL son ejecutables. Esto conduce a una verificación mediante simulación, que puede ser interactiva y cooperativa. Las ventajas de la cosimulación radican en que se generan transacciones desde el testbench original en alto nivel (C/C++/SystemC/SystemVerilog) hacia el modelo RTL encapsulado en un adaptador o wrapper. La comparación de las respuestas obtenidas con ambos modelos, funcional y RTL, permite observar las posibles diferencias de comportamiento entre ambos modelos. Por tanto, se utiliza el modelo funcional como modelo de referencia (golden reference). Generalmente la arquitectura del wrapper se diseña para obtener la salida del módulo RTL (objeto de esta etapa de verificación) aplicando los mismos estímulos de entrada, mientras que las salidas del módulo de referencia se utilizan para realizar la comparación de dichas salidas. Igualmente es posible cosimular únicamente el módulo RTL utilizando el testbench original. En CtoS se pueden encontrar ejemplos de utilización de este tipo de arquitectura de verificación. CtoS genera un wrapper en SystemC que instancia un modelo en Verilog durante la síntesis de alto nivel. Permite así realizar una simulación usando el mismo testbench en SystemC y RTL. Y, por otro lado, este wrapper realiza dos instancias del diseño en cuestión, una del modelo original en alto nivel en SystemC y otro del sintetizado en Verilog. Este mismo mecanismo de verificación también está implementado en Xilinx Vivado HLS. La figura 56 muestra la jerarquía de bloques del testbench del sistema en alto nivel y la figura 57 representa el proceso de reutilización del testbench para simular el diseño sintetizado a nivel RTL. Además de la información funcional y dependiendo de las estrategias de diseño del testbench, durante la simulación RTL es necesario tener en cuenta las latencias de procesamiento obtenidas durante la síntesis de alto nivel de tal manera que el comportamiento sea concordante en ciclos de procesamiento. Todo el proceso de verificación a diferentes niveles de abstracción se realiza en el entorno de simulación de Cadence Incisive Enterprise Simulator (IES). Al igual que la herramienta de síntesis, permite lanzarlo tanto en modo batch como en modo gráfico en el que se representan las señales como formas de onda y otras vistas gráficas y de depurado del diseño. 3.11.1. Diseño del testbench Para el diseño del testbench del procesador de eventos cabe destacar que los datos de entrada se encuentran almacenados, individualmente en ficheros binarios, en el formato en el que son recibidos por la red. Por eso, teniendo en cuenta la necesidad de preparar las tramas para su posterior procesado (etapa de pre-procesado que en el sistema final será realizada por el procesador empotrado PowerPC 440 de la FPGA), esta tarea deberá realizarla el testbench antes de enviar los datos al CE. 100 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Además de leer los ficheros binarios y realizar el pre-procesado de las tramas, el testbench debe implementar el protocolo de comunicación del bloque a simular, en este caso LocalLink. Esto implica que el testbench pasa de ser un simple generador de tramas, a ser un sistema que se realimenta del dispositivo bajo test, sincronizando las transmisiones cuando este deja de estar listo para la recepción de nuevos datos. Está formado por dos hilos de ejecución para modelar las interfaces LocalLink, proporcionando así una comunicación full-duplex. La figura 58 representa en un diagrama de flujo la ejecución del testbench. 3.11.2. Simulación del diseño Para la simulación y consecuente verificación del diseño generador por CtoS se ha usado el wrapper que instancia el modelo original en alto nivel y el diseño sintetizado RTL. La estrategia de verificación implica los siguientes pasos. Se envía una regla de configuración, generándose notificaciones de creación de la regla en el sistema, y de las órdenes de ejecución que esta contiene. En la figura 59 se han introducido cinco marcadores, con nombres TimeA, TimeB, TimeC, TimeD y TimeE. El primero, marca el comienzo de transmisión de la regla, por parte del testbench, y con destino al modelo hardware bajo test. Los sufijos de tx y rx para denominar las señales de un sentido u otro de la comunicación han sido nombrados desde el punto de vista del bloque hardware, por lo que las señales con sufijo rx implican el sentido con origen el testbench (o el DMA en el sistema completo) y destino el procesador de eventos, y viceversa para las señales tx. Figura 56. Simulación en alto nivel 101 3.11. Verificación RTL 3.11. Verificación RTL Figura 57. Esquema de simulación RTL usando el modelo SystemC como Golden Reference Figura 58. Arquitectura del testbench incluyendo la interfaz LocalLink En las transmisiones, tanto de tramas de reglas como de eventos, se han simulado las interrupciones en la comunicación que se producirán en el sistema real, debido a la compartición de la matriz de interconexión interna del bloque de procesador, que impedirá que todos los 108 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos En el caso de la estrategia bottom-up, normalmente se realiza una optimización global tras la síntesis de todos los sub-módulos del diseño, incrementando ligeramente el tiempo de síntesis pero consiguiendo una mejora notable en la calidad de los resultados, ahorrando recursos innecesarios en los bordes de los bloques. 3.12.3. Opciones de síntesis Con el objetivo de obtener un netlist optimizado para incorporarlo al diseño de la plataforma se incluyen diferentes opciones durante la fase de síntesis lógica del bloque IP. Disable I/O Insertion Normalmente durante la fase de síntesis lógica para la FPGA se insertan los bloques de entrada/salida (IOB) del diseño, correspondientes a las señales de entrada y salida en el bloque de mayor jerarquía del IP, entendiendo que dichas señales estarán asociadas a pines de la FPGA. En nuestro caso el diseño formará parte de una plataforma en la que se ubicarán las interfaces de E/S. FSM Compiler La utilización de un compilador simbólico de máquinas de estado (FSM) permite optimizar la codificación de los estados en términos de área y retardos. La elección de un esquema de codificación se realiza en función del número de estados y del impacto de la lógica de decodificación. Por ejemplo, una codificación binaria se utiliza cuando el número de estados es reducido (<5) o una codificación de Gray cuando el número de estados es alto (>25). Normalmente, para el caso de FPGAs, la utilización de codificación one-hot es la alternativa adecuada para la mayoría de los casos no contemplados entre los extremos indicados anteriormente. Resource Sharing Se habilita la opción de compartición de recursos de procesamiento, con el fin de reducir el consumo de recursos en el dispositivo, para aquellos casos en los que es posible hacerlo porque su uso es mutualmente excluyente como por ejemplo en una sentencia case. Esto implica la introducción de multiplexores en las entradas y salidas, incrementando los retardos en la lógica. Otro efecto es el incremento en el fan-out de los puertos de salida. Si los recursos están en la ruta crítica del diseño es preferible no compartir recursos y evitar así retardos adicionales. Pipelining Durante el proceso de optimización de la síntesis lógica es posible segmentar la lógica para incrementar las prestaciones del sistema, permitiendo que se estén procesando diferentes datos en diferentes etapas de la unidad de procesamiento. Esta segmentación es posible bajo determinadas condiciones, compartiendo señales de reloj, de reset y de enable. También es posible segmentar las propias unidades funcionales (multiplicadores, memorias, DSPs). 109 3.12. Implementa ción FPGA 3.12. Implementación FPGA Retiming El proceso de retiming está orientado a la optimización temporal y también a la reducción del uso de recursos. La aplicación de retiming implica el movimiento legal de registros y lógica sin alterar el comportamiento temporal del sistema en cuanto al número de ciclos totales. Dado que el tiempo de ciclo viene definido por la etapa lógica más lenta del sistema, el retiming tiene por objetivo equilibrar las etapas lógicas, reduciendo el tiempo de ciclo y por tanto reduciendo la latencia global del sistema. Igualmente es posible aplicar técnicas de retiming para mover registros desde las entradas a las salidas y por tanto reducir, en algunos casos, la utilización de registros. 3.12.4. Resultados En este apartado se presenta la comparación ente los resultados de síntesis, en términos de consumo de recursos y frecuencia máxima de utilización, para las estrategias de síntesis bottom-up y top-down. Los resultados, en los casos de estrategia bottom-up, serán además presentados desglosados para los módulos de la partición realizada del diseño: interfaz, estado del sistema, núcleo de procesado y ejecutor de resultados. La interfaz incluye la funcionalidad de control del protocolo LocalLink y las FIFOs de comunicación. El módulo de estado del sistema comprende todas las memorias internas que almacenan las reglas activas y por activar, que actualmente ha recibido el sistema, así como el bloque encargado de reconocer una trama de reglas recibida por LocalLink y mapearla en las memorias internas. El núcleo de procesado es el encargado de comprobar -una vez recibido un eventosi los valores recibidos están asociados a una regla activa y realizar las operaciones necesarias. En caso de que se cumpla la condición, el ejecutor de resultados realizará las tareas asociadas a dicha regla. En la tabla 4 y en la figura 63 se muestran los resultados obtenidos durante la fase de síntesis lógica utilizando una estrategia bottom-up. La mayor parte de lógica programable, como son las LUTs y los FlipFlops se utiliza en los bloques del núcleo de procesamiento y el ejecutor de resultados. Las LUTs y los FlipFlops del bloque de estado son los usados por el módulo responsable de actualizar el estado del procesador cuando este recibe nuevas estrategias para su preparación y almacenamiento en memoria. Tabla 4. Resultado de la síntesis lógica con estrategia bottom-up Bloque Ruta crítica (ns) Frecuencia (MHz) LUTs DSPs FlipFlops BRAM Interfaz 7,6 131,8 3.218 0 1.477 0 Estado 5,7 176,2 9.890 0 14.223 53 Núcleo 5,4 183,6 10.120 4 18.800 0 Ejecutor 6,8 147,5 11.544 24 14.484 0 Total agregado 7,6 131,8 35.772 28 48.984 53 Sistema optimizado 6,7 149,5 35.772 28 36.922 53 110 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Los bloques DSPs son usados únicamente por el núcleo de procesamiento y el ejecutor de resultados, ya que realizan operaciones con números reales. A su vez los bloques BRAMs están concentradas en el módulo de estado del sistema ya que este se encarga de almacenar las estrategias, acciones e histórico de cotizaciones. Igualmente el módulo de interfaz hace uso de LUTs para implementar RAM distribuida haciendo uso de los SLICEM de la FPGA. En cuanto a la frecuencia máxima de funcionamiento, todo el diseño se ha referenciado a un único reloj de entrada para el IP. La frecuencia de funcionamiento del IP acelerador vendrá por tanto, determinada por la ruta crítica del sistema, que en este caso se encuentra en la interfaz de entrada/salida (figura 64). Esto se debe a la funcionalidad incluida en dicho módulo de desempaquetado de datos que afecta a la ruta crítica del sistema. Aunque parezca que interfiere en las prestaciones finales del sistema, la ventaja de recibir los datos empaquetados es que disminuye la latencia debida a la transferencia de datos y por tanto en realidad mejora las prestaciones globales del sistema. Figura 63. Distribución de recursos utilizados en cada módulo del diseño Figura 64. Frecuencia máxima de cada bloque 3.218 1.477 9.890 14.223 53 10.120 18.800 4 11.544 14.484 24 0,0% 10,0% 20,0% 30,0% 40,0% 50,0% 60,0% 70,0% 80,0% 90,0% 100,0% LUTs FlipFlops DSPs BRAM Interfaz Estado Núcleo Ejecutor 0 50 100 150 200 0 1 2 3 4 5 6 7 8 Interfaz Estado Núcleo Ejecutor Frecuencia (MHz) Retardo (ns) Módulos del diseño Ruta crítica (ns) Frecuencia (MHz) 111 3.13. Implementa ción física y validación de la plataforma 3.13. Implementación física y validación de la plataforma Igualmente se muestran los resultados de la síntesis lógica realizada con estrategia topdown, en la que se muestran las esperadas mejoras en cuestión de consumo de recursos arquitecturales frente a la síntesis bottom-up (tabla 5 y figura 65). Tabla 5. Resultados de síntesis con estrategias bottom-up y top-down Estrategia Ruta crítica (ns) Frecuencia (MHz) LUTs DSPs FlipFlops BRAM bottom-up 6,688 149,5 35.772 28 36.922 53 top-down 6,888 145,2 30.708 28 32.291 46 Diferencia -3,0% -2,9% 14,2% 0,0% 12,5% 13,2% Puede observarse que, menos en el caso de los bloques DSPs, el resto de resultados varían con la estrategia top-down, mejorando en el consumo de recursos, pero empeorando en la frecuencia máxima del diseño. Figura 65.Comparación entre los resultados de las dos estrategias utilizadas 3.13. Implementación física y validación de la plataforma El flujo de diseño establecido prevé como siguientes etapas realizar la implementación física integrando el diseño en la plataforma, y entonces validar la implementación completa en la plataforma. Para validar los resultados obtenidos en las etapas de síntesis se realiza en primer lugar la integración del acelerador hardware en la plataforma y luego la implementación final de ésta. Con ello se genera un fichero de configuración para la programación de la FPGA. Igualmente es preciso generar el software empotrado para la generación y envío de tramas de validación a través de la interfaz de red Ethernet. 3.13.1. Plataforma de validación Para la implementación física del procesador y para su validación se ha utilizado la plataforma mostrada en la figura 66. El sistema se organiza alrededor del bloque empotrado que incluye el PowerPC 440 y un conjunto de elementos de interconexión para crear la infraestructura necesaria (interfaces de bus PLB maestra y esclavas, interfaces LocalLink con sus -2,9% 14,2% 0,0% 12,5% 13,2% Frecuencia (MHz) LUTs DSPs FlipFlops BRAM -4,0% -2,0% 0,0% 2,0% 4,0% 6,0% 8,0% 10,0% 12,0% 14,0% 16,0% 112 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos correspondientes bloques DMA, así como otras interfaces para el controlador de memoria y otras interfaces de control. Asimismo el sistema incluye un conjunto de IPs interconectados mediante el bus CoreConnect PLB así como interfaces LocalLink dedicadas (figura 67). La plataforma incluye un controlador de acceso a memoria DDR, un controlador TEMAC para acceso Ethernet, una UART, un controlador de interrupciones, así como un controlador para acceder a la memoria CompactFlash. Asimismo incluye un bloque ILA/ICON para el depurado de la plataforma mediante un analizador lógico integrado. El acelerador hardware se conecta al PowerPC mediante un enlace punto a punto full-duplex LocalLink que permite las transferencias de datos a través de DMAs dedicados. Figura 66. Plataforma de referencia para la validación del acelerador hardware Figura 67. Bloque procesador empotrado Virtex-5 PowerPC 440 [143] 113 3.13. Implementa ción física y validación de la plataforma 3.13. Implementación física y validación de la plataforma La integración del procesador de eventos en la plataforma exige la creación de un wrapper VHDL para conectar el netlist EDIF generado en Synplify durante la fase de síntesis lógica que será tratada como una blackbox. A continuación se muestra el wrapper VHDL utilizado. library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity rt_core is port( ll_clk : in std_logic; ll_rst : in std_logic; tx_data : in std_logic_vector(31 downto 0); tx_rem : in std_logic_vector(3 downto 0); tx_sof_n : in std_logic; tx_eof_n : in std_logic; tx_sop_n : in std_logic; tx_eop_n : in std_logic; tx_src_rdy_n : in std_logic; tx_dst_rdy_n : out std_logic; rx_data : out std_logic_vector(31 downto 0); rx_rem : out std_logic_vector(3 downto 0); rx_sof_n : out std_logic; rx_eof_n : out std_logic; rx_sop_n : out std_logic; rx_eop_n : out std_logic; rx_src_rdy_n : out std_logic; rx_dst_rdy_n : in std_logic ); end rt_core; architecture arch of rt_core is component procesador_rtl port( clock : in std_logic; rst_n : in std_logic; ll_src_rdy_rx_n : in std_logic; ll_dst_rdy_rx_n : out std_logic; ll_sof_rx_n : in std_logic; ll_sop_rx_n : in std_logic; ll_data_rx : in std_logic_vector(31 downto 0); ll_rem_rx : in std_logic_vector(3 downto 0); ll_eop_rx_n : in std_logic; ll_eof_rx_n : in std_logic; ll_src_rdy_tx_n : out std_logic; ll_dst_rdy_tx_n : in std_logic; ll_sof_tx_n : out std_logic; ll_sop_tx_n : out std_logic; ll_data_tx : out std_logic_vector(31 downto 0); ll_rem_tx : out std_logic_vector(3 downto 0); ll_eop_tx_n : out std_logic; ll_eof_tx_n : out std_logic ); end component; begin procesador_inst : procesador_rtl port map ( clock => ll_clk, rst_n => ll_rst, 114 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos ll_src_rdy_rx_n => tx_src_rdy_n, ll_dst_rdy_rx_n => tx_dst_rdy_n, ll_sof_rx_n => tx_sof_n, ll_sop_rx_n => tx_sop_n, ll_data_rx => tx_data, ll_rem_rx => tx_rem, ll_eop_rx_n => tx_eop_n, ll_eof_rx_n => tx_eof_n, ll_src_rdy_tx_n => rx_src_rdy_n, ll_dst_rdy_tx_n => rx_dst_rdy_n, ll_sof_tx_n => rx_sof_n, ll_sop_tx_n => rx_sop_n, ll_data_tx => rx_data, ll_rem_tx => rx_rem, ll_eop_tx_n => rx_eop_n, ll_eof_tx_n => rx_eof_n); end arch; Para realizar la implementación física del diseño, y a la vista del elevado número de recursos utilizados de la FPGA, se han utilizado distintas estrategias con el objetivo de obtener una implementación válida que cumpla con los objetivos temporales. Se parte de un netlist completo de la plataforma creado a partir de sus bloques IPs componentes en sus formatos nativos (EDIF, NGC, etc.) y de la definición de las interconexiones de los mismos obtenidos en Xilinx Platform Studio (XPS). PlanAhead soporta la ejecución paralela (en diferentes servidores de cómputo) con diferentes estrategias, con y sin optimización global, para luego optar por aquella válida con un mejor análisis temporal. En la figura 68 se muestran distintas estrategias disponibles en PlanAhead, algunas de ellas optimizadas en área mientras que otras están diseñadas para la optimización temporal. Figura 68. Estrategias de las implementaciones En la figura 69, se observa el resultado de los procesos de implementación planificados con diferentes estrategias, en total nueve. De ellas se ha finalizado una completamente, en concreto 115 3.13. Implementa ción física y validación de la plataforma 3.13. Implementación física y validación de la plataforma la impl_10, que aplica un esfuerzo alto de colocado y ruteado. Dos de ellas (impl_3 e impl_5) han completado las fase de colocado y ruteado aplicando igualmente esfuerzos elevados de optimización temporal guiada por prestaciones temporales (en impl_3) y de mapeado con un esfuerzo adicional (en impl_4). La impl_7 y la impl_8 han fallado durante la fase de mapeado y el resto no ha completado esta fase de diseño, lo que suele indicar que no se encontrará una solución válida. Como se ve, la utilización de diferentes estrategias de implementación es esencial y permite encontrar soluciones aceptables desde el punto de vista de ocupación de la FPGA y de cumplimiento de los requisitos temporales. En cuanto a los resultados finales obtenidos, se resume en la tabla 6 y figura 70, en términos de recursos utilizados, la utilización de los bloques de la FPGA y la frecuencia de funcionamiento de la FPGA y su ruta crítica. Figura 69. Estrategias de implementación utilizadas Tabla 6. Utilización de recursos Recursos BRAMs DSPs LUTs FlipFlops Slices Utilizados 62 28 38.777 52.982 18.562 Totales 298 320 81.920 81.920 20.480 Porcentaje de ocupación 21% 9% 47% 65% 91% Figura 70. Ocupación de la FPGA Virtex-5 FX 130T 21% 9% 47% 65% 91% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% BRAMs DSPs LUTs FlipFlops Slices Utilizados Totales 116 Capítul o 3. Caso de aplicación: diseño de un procesador de eventos Capítulo 3. Caso de aplicación: diseño de un procesador de eventos Para hacer un análisis del área ocupada por el diseño y de su complejidad, se debe observar el número de Slices utilizados, ya que el Slice es la unidad básica de programabilidad de las FPGAs de la familia Virtex-5 de Xilinx. En la arquitectura Virtex-5 cada Slice está formado por cuatro LUTs y cuatro FlipFlops (FF), por lo que dado un número de LUTs y FlipFlops usados, el factor de utilización (FU) de los slices se puede calcular, tanto para LUTS como para FFs, como: 𝐹𝑈𝐿𝑈𝑇𝑠 = 𝑁𝐿𝑈𝑇𝑆 𝑁𝑆𝐿𝐼𝐶𝐸𝑆 = 2,85 𝐹𝑈𝐹𝐹 = 𝑁𝐹𝐹 𝑁𝑆𝐿𝐼𝐶𝐸𝑆 = 2,09 Los factores de utilización indicados dependen de la naturaleza del diseño y del estilo de diseño utilizado. En la FPGA para poder incrementar la utilización de slices es necesario que compartan las señales de control. La utilización de resets globales puede aumentar del orden del 10% el factor de utilización, aunque disminuye el control sobre el diseño durante su simulación. Este proceso de empaquetado de señales de control está influenciado por las restricciones temporales impuestas al diseño. La tabla 7 resume los resultados del factor de utilización para diferentes diseños realizados siguiendo el flujo de diseño mostrado y comparándolo con flujos de diseño basados en Vivado HLS. Tabla 7. Factor de utilización de los slices Tipo diseño Herramienta FPGA Factor de Utilización LUTS FFs Diseño 1 Plataforma + IP Vivado HLS Xilinx Zynq 7z020 2,21 2,90 Diseño 2 IP CtoS Xilinx Zynq 7z045 3,32 1,64 Diseño 3 Plataforma + IP Vivado HLS Xilinx Zynq 7z045 2,29 3,05 Diseño 4 IP Vivado HLS Xilinx Zynq 7z045 2,12 2,79 Este diseño Plataforma + IP CtoS Xilinx Virtex-5 FX 130t 2,85 2,09 En la figura 71 se muestra el layout final del diseño. En a) se presentan resaltados los principales bloques de la plataforma, mostrando el acelerador hardware, el controlador DDR2, el adaptador del bloque TEMAC y el procesador empotrado PowerPC 440. En b) se muestra la distribución de los bloques que componen el acelerador hardware, y que incluye los bloques BRAM, organizados en columnas, el bloque de estado del procesador de eventos, y el bloque de interfaz, más próximo al PowerPC. Igualmente se incluye el bloque de procesamiento y el bloque ejecutor de resultados. En cuanto al análisis temporal estático realizado después de la implementación se ha comprobado que el sistema cumple las restricciones temporales para una frecuencia a 100 MHz para el acelerador hardware, tal como se especifica en el fichero de restricciones temporales. Los resultados obtenidos son los siguientes: Periodo mínimo: 9,996 ns Máxima frecuencia: 100,040 MHz 117 3.13. Implementa ción física y validación de la plataforma 3.13. Implementación física y validación de la plataforma Figura 71. Layout final del diseño: a) bloques de la plataforma. b) bloques del acelerador hardware En el informe obtenido durante el análisis temporal se presentan las rutas con los correspondientes slack para cada reloj del sistema. A continuación se muestra el resumen de una ruta con su correspondiente slack del procesador de eventos. Slack: 0.024ns (requirement - (data path - clock path skew + uncertainty)) Source: .../state_leer_acciones_0_rep1 (FF) Destination: .../mux_limite_m_mant_ln392_Z_0_0[6] (FF) Requirement: 10.000ns Data Path Delay: 9.896ns (Levels of Logic = 3) Clock Path Skew: 0.001ns (1.241 - 1.240) Source Clock: ll_clk_100MHz rising at 0.000ns Destination Clock: ll_clk_100MHz rising at 10.000ns Clock Uncertainty: 0.081ns Clock Uncertainty: 0.081ns ((TSJ^2 + DJ^2)^1/2) / 2 + PE Total System Jitter (TSJ): 0.070ns Discrete Jitter (DJ): 0.146ns Phase Error (PE): 0.000ns