Investigación sobre herramientas de Codiseño Hardware-Software

Transcripción

1 ESCUELA SUPERIOR DE INGENIEROS DEPARTAMENTO DE INGENIERÍA ELECTRÓNICA UNIVERSIDAD DE SEVILLA Investigación sobre herramientas de Codiseño Hardware-Software Proyecto Fin de Carrera Hipólito Guzmán Miranda Ingeniero de Telecomunicación Tutor: Jon Tombs Sevilla, Mayo 2006

2 A mis padres

3 Índice general 1. Introducción Motivación Objetivo Alcance Flujo de diseño en codiseño Generalidades Tipos de problemas de codiseño System on Board System on Chip Codiseño con Softcore Flujo de diseño tradicional Flujo de diseño con herramientas de codiseño Especificación del Sistema Simulación Funcional Exploración del Espacio de Diseño Co-Simulación TLM Co-Verificación HW/SW Co-Simulación RTL Prototipado Síntesis del Sistema Trabajo sobre Unshades Descripción de la plataforma Unshades Herramientas Evaluadas Problemas Encontrados Conclusiones Cambio de plataforma Línea de trabajo sobre Unshades Consideraciones para una posible Unshades

4 4. Solución propuesta Descripción de la solución propuesta Procesador Leon Descripción Diagrama de bloques Bus Amba Alternativas al procesador Leon Configuración del modelo Añadiendo la parte HW de tu diseño a Leon Placa de desarrollo XSV Descripción Configuración Configuración de jumpers Frecuencia de reloj Reprogramación de la CPLD Xstools Snapgear Linux Necesidad de un sistema operativo Descripción Kernels para sistemas con y sin MMU Configuración Añadiendo la parte SW de tu diseño a snapgear Entorno de codiseño PeaCE Descripción y características Ventajas con respecto a otras soluciones Flujo de diseño en PeaCE Aplicación de demostración Visión general Parte hardware Parte software Conclusiones Futuras líneas de trabajo Adaptación de PeaCE a una plataforma propia Desarrollo de una plataforma HW opensource Bibliografía 73 4

5 Índice de figuras 2.1. Flujo de diseño tradicional Flujo de diseño utilizando herramientas de codiseño Unshades 2. Fotografía Diagrama de bloques del sistema Unshades Diagrama de bloques de la solución propuesta Diagrama de bloques del procesador Leon Mapa de memoria AHB del procesador Leon Herramienta de configuración del procesador Leon Esquema del cable serie en Y Xess XSV-800. Fotografía Configuración de jumpers empleada Diagrama de bloques de la plataforma Xess XSV Herramienta de configuración de Snapgear Captura de pantalla del programa minicom Herramienta de configuración de Snapgear, modificada Especificación del sistema en PeaCE Especificación de algoritmos en PeaCE Especificación de arquitectura en PeaCE Esquema de entradas y salidas del módulo HW Carga de Snapgear en la RAM de la XSV-800 utilizando grmon Aplicación de demostración en funcionamiento Prototipo en funcionamiento. Fotografía

6 Capítulo 1 Introducción A good beginning makes a good ending" English Proverb 1.1. Motivación Desde los principios de la tecnología de semiconductores, los sistemas electrónicos han venido experimentando un constante crecimiento en complejidad, debido a que las prestaciones que tiene que ofrecer una aplicación concreta son cada vez mayores y de naturalezas más diversas. Esto ha dado lugar a que se tengan a la vez, para un mismo sistema, restricciones aparentemente incompatibles, como pueden ser de trabajo en tiempo real, de tolerancia a fallos o de procesado de grandes flujos de datos. Este incremento de complejidad y diversidad en las restricciones que ha de cumplir un sistema dado ha motivado la aparición de sistemas híbridos en los que interactúan elementos hardware y software, ya que dichos elementos pueden complementarse para resolver problemas de distinta naturaleza. Actualmente se está tendiendo, cada vez más, en el diseño de dichos sistemas electrónicos, a estas soluciones en las que se mezclan elementos hardware y software, debido a las duras restricciones que deben cumplir estos sistemas, como son las condiciones de tiempo real y el procesamiento rápido de grandes flujos de datos. Estos sistemas híbridos se han venido diseñando prácticamente a mano, en el sentido en que, si bien existen desde hace años herramientas para realizar la compilación del software y la síntesis del hardware, las decisiones más importantes que han de tener en cuenta la interacción entre ambas partes (como el particionado HW/SW) se han ido tomando basándose en experiencias previas de diseño, por lo que se tiene una necesidad de poder aplicar una forma más global de ingeniería automatizada al problema del codiseño. Al encarar un problema de codiseño, el diseñador ha de explotar las ventajas 6

7 Introducción 1.2 Objetivo de la heterogeneidad del sistema objetivo, aprovechando los puntos fuertes del software (mayor flexibilidad, facilidad para ejecutar órdenes secuencialmente) y del hardware (mayor velocidad, posibilidad de realizar procesamiento concurrente), pero también debe procurar que los tiempos de desarrollo y depuración no sean excesivamente elevados. Esto crea la necesidad y conveniencia de trabajar en entornos integrados de desarrollo en el que se encare toda la problemática de este tipo de diseños de una forma global, y en el que se puedan automatizar la mayor parte de tareas a realizar durante el flujo de diseño Objetivo El objetivo de este proyecto es realizar una investigación sobre el estado del arte de las distintas herramientas de codiseño disponibles en el mercado, así como las distintas plataformas y procesadores (tanto ASIC como softcore) sobre los que se puedan implementar soluciones de codiseño, orientando el trabajo a poder realizar codiseño sobre alguna de las plataformas hardware de las que dispone el departamento. Se pretende también conocer y familiarizarse con el flujo de diseño de un sistema híbrido HW/SW, al igual que entender el resto de opciones y compromisos que puedan surgir, de forma que nos introduzcamos poco a poco en la problemática del codiseño Alcance El alcance del proyecto consiste en llegar a poder proponer, como resultado de las investigaciones realizadas, una solución viable para poder realizar codiseño en el departamento. Es requisito que esta solución pueda funcionar en alguna de las plataformas hardware de las que dispone el departamento. Como culminación del proyecto sería deseable llegar a realizar una aplicación sencilla que demuestre la viabilidad de dicha solución y del flujo de diseño propuesto. Esto puede acarrear ciertos problemas ya que las aplicaciones y plataformas que se suelen utilizar para resolver problemas de codiseño disponen normalmente de dispositivos muy potentes y cantidades más que suficientes de recursos como memoria RAM o espacio disponible en FPGA, y en este proyecto se ha trabajado con un hardware muy limitado. 1 Por ejemplo, sería deseable poder realizar la partición HW/SW de forma automatizada y transparente al programador, dada una descripción a alto nivel del sistema. 7

8 Capítulo 2 Flujo de diseño en codiseño Creativity is inventing, experimenting, growing, taking risks, breaking rules, making mistakes, and having fun" Mary Lou Cook 2.1. Generalidades Aunque el utilizar soluciones de codiseño para resolver un problema concreto reduce la complejidad individual (y por ello, el coste) de los elementos del sistema 1, como contrapartida, el proceso de diseño puede complicarse enormemente. El flujo de diseño de un sistema híbrido debe contemplar el desarrollo de forma conjunta de hardware y software e incluye, entre sus pasos, descripción a nivel de sistema, simulación funcional, particionado hardware-software, generación de interfaces, estimación de costes (de área y retrasos para el hardware y de tamaño de código y tiempo de ejecución para el software), co-simulación, síntesis e implementación de HW, SW e interfaces. Esta actividad interdisciplinar es lo que se conoce como codiseño Tipos de problemas de codiseño System on Board Si los elementos hardware y software se encuentran en distintos chips dentro de una misma placa, la interfaz que transmitirá información entre las partes hardware y software tendrá ciertas limitaciones, puesto que dicha interfaz ha de 1 Ya que en estos casos no es necesario que toda la funcionalidad se concentre en un único módulo hardware o software. 8

9 Flujo de diseño en codiseño 2.3 Flujo de diseño tradicional implementarse necesariamente a través de líneas de conexionado sobre la mencionada placa: tenemos lo que se conoce como un System on Board. Como veremos en el próximo capítulo, este es el caso del sistema UNSHADES System on Chip Cuando los elementos hardware y software forman parte del mismo circuito integrado, la interfaz que los separa puede tener una capacidad mucho mayor para transferir información, dado que esta interfaz está dentro de un circuito integrado: estaríamos, en este caso, ante un System on Chip. Ejemplos de estos sistemas son el A7S de Triscend, Excalibur de Altera, Virtex II Pro y Virtex 4 de Xilinx y FIPSOC [FAM + 97] Codiseño con Softcore La última opción para atacar la problemática del codiseño es utilizar un único circuito programable sobre el que se programarán tanto el procesador que ejecutará la parte software como el circuito que implementará la parte hardware. Nótese que, ya que tanto la parte software como la parte hardware del diseño estarán implementadas en un circuito programable, estamos nuevamente ante un System on Chip. Pero existen grandes diferencias: por ejemplo en este caso, la interfaz no está limitada a priori: podemos conectar los módulos del procesador al hardware como queramos. Incluso podemos implementar más de un procesador en la misma FPGA. También podemos añadir o eliminar funcionalidades del microprocesador en función de las necesidades de nuestra aplicación. La única limitación la establece la capacidad del circuito programable que utilicemos. Un par de ejemplos de softcores son MicroBlaze de Xilinx y Nios II de Altera Flujo de diseño tradicional En los sistemas híbridos de los que hablamos en la introducción, el diseño se ha venido haciendo prácticamente a mano en el sentido en que, si bien existen desde hace años herramientas para realizar la compilación del software y la síntesis del hardware, las decisiones más importantes que han de tener en cuenta la interacción entre ambas partes (como el particionado HW/SW) se han ido tomando basándose en experiencias previas de diseño. En general, el flujo de diseño que se puede realizar sin ayuda de ninguna herramienta de automatización es el que aparece en la figura 2.1, en la página 10. 9

10 Flujo de diseño en codiseño 2.3 Flujo de diseño tradicional Figura 2.1: Flujo de diseño tradicional Posiblemente el subproblema más significativo de todo el problema del codiseño sea la partición hardware-software (reparto de las tareas que debe realizar el sistema entre los módulos hardware y software). Esta partición puede realizarse atendiendo a distintos factores, como pueden ser el tamaño (de área y código fuente), la velocidad de proceso o el consumo de potencia. En la práctica es deseable establecer un equilibrio entre todos los factores, aunque se otorguen pesos 10

11 Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño relativos a cada uno de ellos. El particionado suele hacerse manualmente, probando distintas posibilidades y considerando que a priori hay ciertas tareas que deben implementarse en un dispositivo concreto. Para automatizar este paso, se han propuesto varios algoritmos [BGJ + 02, NB01, KHM04] Flujo de diseño con herramientas de codiseño Debido a que se han realizado múltiples investigaciones respecto al tema del codiseño Hardware/Software, existen hoy día múltiples entornos de desarrollo que atacan directamente a la mayor parte de los problemas asociados a la temática del codiseño. Existen tanto proyectos de investigación como POLIS [BGJ + 97], orientado al diseño de sistemas híbridos para control, y COOL [Nie], orientado a sistemas que procesan flujos de datos, como soluciones comerciales, como pueden ser CoWare Codeveloper, Celoxica DK Codesign Suite, Xilinx Embedded Development Kit o Altera Nios II Integrated Development Environment. Estas soluciones comerciales han ido reemplazando a los esfuerzos investigadores anteriormente mencionados, cada uno en su nicho de aplicación (por ejemplo, dispositivos de fabricantes concretos). De una forma general, utilizando herramientas software específicas para realizar codiseño HW/SW, podemos esperar un diagrama de flujo de diseño como el de la figura 2.2 (página 12). Normalmente cada uno de los pasos se realiza con una herramienta diferente, por lo que la integración de las distintas herramientas en un único flujo de diseño no es una tarea trivial. 11

12 Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño Figura 2.2: Flujo de diseño utilizando herramientas de codiseño Especificación del Sistema El primer paso para atacar la problemática de diseñar un sistema híbrido Hardware/Software es el realizar una descripción del sistema que se pretende implementar en un lenguage de abstracción que esté por encima de los lenguages concretos en los que se describirán el software (por ejemplo, C) o el hardware (por ejemplo VHDL o Verilog). Esto es importante de cara a poder estudiar individualmente los bloques funcionales que compongan el diseño y su interacción abstrayéndose de si la implementación de estos bloques se hará en hardware o en software. En definitiva, si el diseñador no es capaz de realizar esta descripción a alto nivel, es porque está dando por supuesto que ciertos bloques funcionales de la aplicación se implementarán de cierta forma concreta. Algunos lenguajes que nos permiten realizar esta descripción a alto nivel del sistema son Matlab, Simulink, SystemC y los grafos de flujos de datos [SOIH97] de PeaCE. Es deseable que, en la medida de lo posible, estas descripciones de alto nivel sean directamente traducibles a descripciones software o hardware, de forma que, una vez decidido el particionado HW/SW, la síntesis de cada una de las partes sea automática. 12

13 Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño Simulación Funcional El siguiente paso consiste en realizar una simulación funcional del sistema descrito, para comprobar si realmente la aplicación descrita coincide con las especificaciones deseadas. Los lenguajes con los que se suelen realizar las descripciones a alto nivel del sistema se distribuyen normalmente con simuladores que permiten realizar simulaciones funcionales de los sistemas descritos, por lo que la disponibilidad de un simulador raramente es un problema. Sólo cuando nuestra descripción a alto nivel es completamente funcional tiene sentido seguir adelante con el flujo de diseño para buscar una arquitectura óptima Exploración del Espacio de Diseño La exploración del espacio de diseño, se hace manualmente utilizando una herramienta de simulación TLM. El objetivo es evaluar las distintas alternativas de particionado y catalogarlas según rendimiento, para tomar una decisión respecto al particionado HW/SW que cumpla con los requerimientos del sistema Co-Simulación TLM Se trata de una simulación a nivel transaccional 2. En un modelo transaccional, los detalles de la comunicación entre bloques computacionales están separados de las descripciones de dichos bloques. Los bloques computacionales y de comunicación se conectan a través de tipos abstractos de datos. La comunicación se modela a través de canales, de forma que las peticiones de transacción se realizan a través de funciones de interfaz correspondientes a los modelos de los canales de comunicación. Detalles innecesarios de la comunicación y la computación se ocultan en TLM pero pueden ser añadidos más adelante. TLM acelera la simulación y permite explorar y validar diferentes alternativas de diseño en un nivel superior de abstracción [CG03]. Algunas herramientas de simulación TLM disponibles en el mercado son Synopsys CoCentric Studio, CoWare ConvergenSC y Axys MaxSim (para ARM) Co-Verificación HW/SW El objetivo de este paso es comprobar que, tras el particionado, nuestro sistema tiene las mismas funcionalidades que en la descripción funcional y cumple con los requisitos adicionales que le hayamos impuesto 3. Esta co-verificación es 2 TLM son las siglas de Transactional Level Modelling 3 Por ejemplo, ciertos requisitos de timing. 13

14 Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño importante ya que si bien la simulación TLM realizada anteriormente es muy eficiente en tiempo, existen aspectos prácticos de los bloques computacionales del diseño que no se han considerado aún Co-Simulación RTL La coverificación HW/SW se hace normalmente a través de una cosimulación a nivel RTL 4. Esto es un problema complejo en sí mismo ya que para realizar esta cosimulación se necesita: Un programa que simule adecuadamente y de forma precisa el HW, por ejemplo un simulador de VHDL o Verilog. Un programa que simule adecuadamente y de forma precisa el comportamiento del SW, es decir, un ISS 5 del procesador utilizado. Integración fluida entre ambos programas. Esto se puede conseguir de distintas maneras, por ejemplo modificando los simuladores para añadirles interfaces a medida 6, consiguiendo una sincronización en tiempo de los simuladores, o aprovechando la capacidad que tienen algunos simuladores de generar ficheros de traza con los accesos a memoria para utilizar una técnica de sincronización virtual basada en la traza de memoria [KYH05], técnica que ofrece un mejor rendimiento en la simulación. La herramienta comercial más popular en la actualidad para realizar coverificación HW/SW es Mentor Seamless CVE, pero existen alternativas como Aldec HES (Hardware Embedded Simulation) Prototipado Una vez que se tienen las descripciones de las partes hardware, software, e interfaces, se pueden utilizar herramientas que existen desde hace años para realizar la síntesis del hardware (herramientas de síntesis, y placement and routing si el hardware se va a sintetizar sobre un circuito programable, como es nuestro caso) y del código objeto para el microprocesador (compiladores). En este momento 4 Register Transfer Level. 5 Instruction Set Simulator. 6 Lo cual no es posible normalmente, ya que difícilmente se tiene acceso al código fuente de los simuladores. 7 Pero a la hora de escoger las herramientas a utilizar, el aspecto más importante que hay que evaluar es si el procesador que se va a utilizar está soportado. Como se verá en el siguiente capítulo, en la plataforma inicialmente escogida para este proyecto se utiliza un procesador de señal (DSP) de Texas Instruments que carece totalmente de soporte en las herramientas comerciales 14

15 Flujo de diseño en codiseño 2.4 Flujo de diseño con herramientas de codiseño es cuando se fabrica un prototipo, sobre el que se demostrará de forma práctica el sistema híbrido funcionando. De esta experiencia se extraen conclusiones muy útiles de cara a la síntesis del sistema final Síntesis del Sistema Tras comprobar que el prototipo funciona correctamente y es apropiado para la aplicación que se quiere resolver, se procede a realizar la síntesis del sistema final. 15

16 Capítulo 3 Trabajo sobre Unshades-2 We used to dream about this stuff. Now, we get to build it. It s pretty neat" Steve Jobs 3.1. Descripción de la plataforma Unshades-2 Unshades-2 es una plataforma híbrida FPGA-DSP para codiseño y co- depuración diseñada en el Departamento de Ingeniería Electrónica de la Universidad de Sevilla [ATBT03]. Unshades-2 es la segunda plataforma de la familia Unshades 1, una familia de tarjetas de desarrollo, basadas en FPGAs de Xilinx, especialmente diseñadas para realizar depuración hardware en tiempo de ejecución de diseños reales. El propósito de la plataforma Unshades-2 es, por un lado, proporcionar información comprensible sobre el estado interno de sus elementos, tanto software como hardware, mientras están funcionando (es decir, el sistema está diseñado para ser observable) y, por el otro, permitir al diseñador realizar cambios sobre dichos estados (es decir, el sistema es controlable). Esta observación y control se realizan a través de unos puertos de entrada/salida que se conectan a un PC, que debe disponer de las herramientas adecuadas para realizar la comunicación con la placa, y presentar la información al usuario de forma comprensible (véase la figura 3.1, en la página 17). De esta forma, el sistema se puede utilizar para depurar los módulos HW y SW de un sistema híbrido. Otro aspecto atractivo de Unshades-2 es que, al facilitarnos tanta información para la depuración, es concebible un sistema de desarrollo en el que más que realizar simulaciones de distintas soluciones de particionado y síntesis, podríamos probarlas directamente sobre la placa y medir sus rendimientos (tiempos de procesado, consumo de potencia). 1 UNiversity of Seville HArdware DEbugging System. 16

17 Trabajo sobre Unshades Descripción de la plataforma Unshades-2 Figura 3.1: Unshades 2. Fotografía Unshades-2, al ser un sistema diseñado para la depuración simultánea de elementos hardware y software, se planteó en un principio como una plataforma interesante sobre la que investigar distintas soluciones a este problema, por la facilidad para extraer información útil que brinda. El trabajar sobre esta plataforma tiene en principio un cierto valor añadido, ya que aporta algo más que los elementos hardware y software: gracias a la controlabilidad y observabilidad que presenta al diseñador, es especialmente útil para proyectos de investigación y desarrollo, puesto que podemos comprobar fácilmente si las decisiones que se van tomando afectan positivamente o no al rendimiento de los módulos sintetizados. En la figura 3.2, en la página 18, podemos ver una fotografía del sistema de desarrollo. La plataforma Unshades-2 está construida alrededor de cuatro dispositivos: S-FPGA 2 FPGA Virtex 100E / 1000E, de Xilinx [Xil02], compatible con el encapsulado PQ240, con y puertas lógicas equivalentes respectivamente. 2 System FPGA, es la FPGA en la que se programan los diseños hardware. 17

18 Trabajo sobre Unshades Descripción de la plataforma Unshades-2 Figura 3.2: Diagrama de bloques del sistema Unshades-2 18

19 Trabajo sobre Unshades Herramientas Evaluadas C-FPGA 3 de la familia Spartan II, compatible con el encapsulado QFP 144. DSP TMS320VC33, de Texas Instruments, de 16 bits y coma flotante. Este procesador pertenece a la familia C3x [Tex04] y el encapsulado con el que aparece en Unshades-2 es el PGE150. Memoria flash de 256 kwords (512 kbytes), modelo Am29LV400B B-70R de AMD. La conexión entre estos elementos se puede apreciar en la figura 3.2. Además, Unshades-2 dispone de otros elementos, como los puertos de expansión, entrada/salida y enlace con PC Herramientas Evaluadas Durante el tiempo que se estuvo trabajando con Unshades-2, se estuvieron evaluando distintas herramientas de codiseño HW/SW. Desafortunadamente, las herramientas comerciales soportan sólo un pequeño subconjunto de los microprocesadores disponibles en el mercado, por lo que el primer escollo con el que nos encontramos al realizar el presente proyecto fue la falta de soporte para los procesadores de la familia C3x. Esto significa que, si queremos hacer codiseño con un procesador de esta familia, necesitaremos añadir nosotros mismos el soporte para este tipo de procesador, lo que nos hace descartar inmediatamente los programas que sean de código cerrado. Pero la mayoría de proyectos de codiseño que son de código abierto son proyectos de investigación que dejaron de actualizarse hace años 4. Entre los entornos de codiseño y herramientas que se evaluaron se encuentran: POLIS. Este trabajo académico ha sido realmente importante, y ha dado como fruto muchas publicaciones que han servido de punto de partida para el presente proyecto [BGJ + 97]. Incluso se planteó en principio como opción para el presente proyecto el realizar una adaptación de POLIS para añadirle la capacidad de realizar cosíntesis para la plataforma Unshades-2. El problema principal que se ha encontrado con POLIS es que como proyecto dejó de ser activo y de tener base de usuarios hace varios años. La última versión 3 Control FPGA, es una FPGA dedicada a realizar funciones de control como la programación de la S-FPGA, control de las señales de reloj, control del DSP a través del puerto JTAG y readback/writeback del estado interno de la S-FPGA a través de las líneas Selectmap. 4 Por ejemplo, la página web del proyecto Chinook (Department of Computer Science and Engineering, University of Washington) no ha sido actualizada desde 1999, y COSYMA (COSYnthesis for embedded Achitectures, de la Technical University of Braunschweig) dejó de desarrollarse alrededor de

20 Trabajo sobre Unshades Herramientas Evaluadas de POLIS (0.4), es del año 2000, y los recursos adicionales como la lista de correo para los usuarios 5 ya no están disponibles. Celoxica DK Design Suite. Este entorno de desarrollo de Celoxica está orientado a descripciones en alto nivel de sistemas híbridos en lenguajes de descripción no gráficos, como son HandelC y otras extensiones de C y C++. La herramienta da soporte para poder trabajar con los PowerPC 405 que se pueden encontrar en las FPGA Virtex II Pro y con el softcore Microblaze de Xilinx. El principal impedimento para poder utilizar esta herramienta comercial es que, como tantas otras, carece de soporte para DSPs de Texas Instruments. Impulse Codeveloper. Impulse CoDeveloper, al igual que Celoxica DK Desigh Suite, es una herramienta de codiseño hardware/software que permite describir un sistema híbrido utilizando una variante del ANSI C, en este caso Impulse C. Impulse C no es, técnicamente hablando, un subconjunto de ANSI C, ya que es posible hacer uso de todas las funcionalidades de C a la hora de programar un test bench o de describir los procesos SW que se ejecutarán en un microprocesador. Sin embargo, para los procesos que se traducirán directamente en diseños hardware, se imponen ciertas restricciones al código Impulse C 6. La herramienta soporta únicamente los microprocesadores Altera Nios, Xilinx Microblaze y los PowerPC de Xilinx Virtex II Pro. Las herramientas de Xilinx, como Xilinx EDK (Embedded Design Kit), que tuvieron que ser descartadas para el trabajo con Unshades-2 ya que únicamente soportan los procesadores que utilizan los dispositivos de Xilinx, como Microblaze o PowerPC. Únicamente utilizaremos las herramientas de Xilinx para hacer la síntesis de la parte HW de los diseños, ya que estamos trabajando con FPGAs de este fabricante. PeaCE 7 codesign environment. Más adelante, en el capítulo 8, se hará una descripción más detallada, pero por ahora comentaremos que de todas las aplicaciones evaluadas, es la única de la que realizar una adaptación a nuestra plataforma es factible: es software libre (licencia tipo BSD), por lo que es posible modificarlo para añadir soporte para Unshades-2, es uno de los 5 polis-users@ic.eecs.berkeley.edu 6 Básicamente: soporte limitado para punteros, carencia de soporte para funciones recursivas, y ciertas restricciones sobre las instrucciones de control de flujo. Esto tiene mucho sentido, ya que si se tradujera directamente un programa C sin restricciones en su código a hardware el resultado distaría mucho de ser eficiente. 7 Ptolemy extension as Codesign Environment. 20

21 Trabajo sobre Unshades Problemas Encontrados pocos proyectos de investigación sobre codiseño que sigue activo y, como añadido, los desarrolladores del proyecto han demostrado interés en dar soporte a los usuarios del software que deseen utilizarlo con nuevas plataformas. En PeaCE, tanto los algoritmos como la arquitectura del sistema híbrido se especifican a través de un interfaz gráfico desarrollado en Java. Por todo ello, una vez estudiadas las distintas herramientas de codiseño, se decidió optar en principio por añadir soporte para la plataforma Unshades-2 al entorno de codiseño PeaCE Problemas Encontrados Ya hemos visto en el apartado anterior que los DSP de Texas Instruments, en particular los de la familia C3x, carecen de soporte en las herramientas de codiseño disponibles. La experiencia con Unshades-2 nos ha descubierto ciertas dificultades que la plataforma plantea para su uso como sistema híbrido: Falta de soporte para el procesador C33 por parte de las herramientas de codiseño HW/SW (como se ha visto anteriormente). Falta de toolchain GNU para el procesador. En realidad existe una adaptación del compilador gcc 8 para las familias de DSP C3x y C4x, llamado c4x-gcc, pero se necesita una versión concreta de una biblioteca runtime propietaria de Texas Intruments, de la que no disponíamos, para poderlo compilar. Sin esta biblioteca, el compilador únicamente puede generar ficheros objeto (.o), y no ejecutables. Al no poder utilizar el compilador de GNU, la única opción posible era utilizar un compilador propietario de Texas Instruments, que originaba otros problemas, entre ellos imposibilidad de utilizar el simulador libre del que disponíamos para el DSP (c4x-gdb 9 ). Carencia de ISS para el procesador. Esto ha sido sorprendente ya que se han evaluado tres simuladores distintos para el C33. La problemática aquí estriba en que para que un simulador del juego de instrucciones de un procesador pueda ser utilizado para hacer cosimulación HW/SW, debe de poderse interconectar a un simulador de VHDL o Verilog que simule la parte HW del diseño. Es decir, que para que un ISS pueda ser utilizado debe de tener 8 GCC son las siglas de Gnu Compiler Collection. 9 Realmente gdb es un depurador (Gnu Debugger), y c4x-gdb está diseñado para ser conectado a placas autónomas basadas en procesadores c3x/c4x a través de conexión por puerto serie o por socket TCP/IP. Pero aparte de esto, c4x-gdb incluye un modo de funcionamiento en el que se conecta a un simulador de estas familias de DSP desarrolado por Herman Ten Brugge. 21

22 Trabajo sobre Unshades Problemas Encontrados un modelo de memoria flexible que se pueda adaptar para conectarlo al simulador de la parte HW, o bien ser de código abierto para poder realizar las modificaciones necesarias, o en última instancia debe ser capaz de generar un fichero con la información de los accesos a memoria (un fichero de traza). El primer simulador que probamos fue Sim3x, un simulador desarrollado por Texas Instruments para ms-dos (que ejecutamos sin problemas bajo Linux utilizando Dosbox 10 ), y descubrimos que no se puede integrar con ninguna otra herramienta ya que el programa no está preparado para interactuar con otros programas, ni permite generar ficheros de traza. Por supuesto, la modificación del programa para añadirle esa funcionalidad era imposible ya que no disponíamos de su código fuente. La segunda alternativa estudiada fue la posibilidad de generar la información de traza con los accesos a memoria utilizando Code Composer (un programa para Windows que se ejecutaría en Linux a través de Wine), empleando un lenguage de scripting de Code Composer llamado GEL 11. Esta alternativa era de una complejidad considerable, ya que habría que escribir un programa que, tras la compilación del software, analizara el código objeto presente en el fichero.out, localizara en él los accesos a memoria, y posteriormente generara un script GEL que colocara breakpoints (puntos de ruptura) en cada uno de dichos accesos. Además, habría que definir funciones específicas en GEL para intentar recoger la información de los tiempos y ciclos de acceso. Aunque teóricamente este enfoque podría funcionar, la viabilidad práctica de esta solución depende de las capacidades reales del lenguaje GEL y aún no ha sido demostrada. Por otro lado, el trabajo necesario para implementar esta solución escapa al alcance de este proyecto, por lo que en su momento se prefirió centrar los esfuerzos en resolver los problemas que planteaba el simulador c4x-gdb. El último simulador que fue evaluado fue c4x-gdb, la única de las tres alternativas que es de código abierto. Ya hemos comentado que, al no poder utilizar el compilador c4x-gcc, por las razones comentadas anteriormente, era imposible utilizar el simulador c4x-gdb. Escasez de memoria RAM. Hemos visto en la sección 3.1 que la plataforma no posee ningún dispositivo de RAM on-board. Es posible instanciar pequeñas memorias RAM dentro de la FPGA, de forma para que el DSP pueda tener un mínimo espacio sobre el que trabajar con datos, pero como 10 Ya que PeaCE se ejecuta bajo Red Hat Linux 8.0, todo programa que queramos integrar con PeaCE debe funcionar a su vez en Linux, aunque sea tras una capa de emulación. 11 General Extension Language. 22

23 Trabajo sobre Unshades Conclusiones máximo disponemos de 393,216 bits (48KBytes) de block RAM en la Virtex 1000E [Xil02] (en el caso de Virtex 100E son únicamente 10KBytes). Si bien puede ser suficiente memoria para manejar ciertas cantidades de datos, hay que tener en cuenta que en un sistema híbrido HW/SW las tareas que han sido implementadas en software han de compartir el microprocesador, lo que significa que necesitamos memoria para guardar la información del contexto de los procesos y de la pila. Además, no podríamos tener un sistema operativo como Linux ejecutándose en la placa (ya que un sistema Linux necesita un mínimo de 1MB de RAM para ejecutarse, más RAM adicional para las aplicaciones), y es muy posible que ecos 12, si bien es un sistema operativo altamente configurable, tenga una huella mínima de uso de RAM superior a los 48KB. Recordemos que estos 48KB han de compartirse con los requerimientos de memoria de la parte SW del diseño. Interfaz FPGA-DSP fija, ya que son pistas en el PCB: es posible que la S-FPGA tenga que enviar ciertas señales al DSP y no pueda hacerlo porque esas pistas no estén conectadas a ella. Si bien este problema no ha sido estudiado a fondo, si llegara a ocurrir podría eliminar por completo la posibilidad de hacer codiseño con Unshades-2. Falta de sistemas operativos de tiempo real para el procesador. Actualmente no existen versiones de Linux o ecos para el procesador C33. Si bien es teóricamente posible realizar un portado de estos sistemas a nuestro DSP, ello escapa al alcance del presente proyecto. La única alternativa para poder conmutar entre las tareas en software es programar un mínimo planificador de tareas. Es por todas estas razones por lo que se decide abandonar el desarrollo sobre Unshades-2. En el siguiente apartado se exponen las conclusiones de la investigación sobre Unshades-2 y en el capítulo 4 se propone una solución alternativa para poder realizar codiseño, con otra plataforma hardware Conclusiones Cambio de plataforma Teniendo en cuenta los resultados expuestos en los apartados anteriores, realizar codiseño con Unshades-2 sin modificar la plataforma hardware es una tarea que roza lo imposible. Además, los esfuerzos necesarios para hacer codiseño en 12 embedded Configurable operating system. 23

24 Trabajo sobre Unshades Conclusiones dicha plataforma sobrepasan con creces el alcance de un proyecto de fin de carrera. Es por esto por lo que se propone un cambio de plataforma hardware: sabiendo tras la evaluación de las herramientas software (sección 3.2) que el soporte para ciertos softcores está sobradamente extendido, se plantea el realizar codiseño sobre una plataforma que únicamente disponga de una FPGA de gran capacidad. De esta forma se instanciarán un microprocesador y la parte HW del diseño en el mismo dispositivo. La plataforma propuesta es la placa de desarrollo XSV-800 de Xess. En el capítulo 6 se hará una descripción más detallada de dicha plataforma Línea de trabajo sobre Unshades-2 Otra conclusión del trabajo realizado, además del mencionado cambio de plataforma, es el trabajo concreto que habría que hacer para conseguir hacer codiseño con Unshades-2 utilizando herramientas de codiseño. Si se quisiera realizar el esfuerzo, habría que: Programar un simulador del procesador C33 o adaptar las c4x GNU tools para que funcionen utilizando Newlib (para esto necesitaríamos primero realizar el portado de Newlib al C33). Portar ecos (ya que no podemos utilizar Linux por falta de RAM) al C33. Nótese que para portar ecos también necesitamos haber portado primero Newlib. Si no queremos portar ecos, es necesario programar un planificador de tareas que se encargue de guardar los contextos de las tareas software y manejar la pila. De todas formas, es poco probable que toda esta funcionalidad se pueda conseguir con tan sólo 48KB de RAM. Con esto tendríamos las mínimas herramientas que hacen falta para poder empezar a integrar el soporte para Unshades-2 en PeaCE. Aún quedaría por realizar todo el trabajo de integración con el framework de codiseño Consideraciones para una posible Unshades-2.1 En mi opinión el trabajo mencionado en el apartado anterior no compensa el esfuerzo que es necesario realizar: sería más sencillo modificar Unshades-2 para permitir una adaptación más sencilla y realizable. Por ello se proponen las siguientes sugerencias y modificaciones, para que sean consideradas para una posible versión 2.1 de Unshades: Procesador: el primer cambio que se propone consiste en cambiar el DSP de Texas Instruments por un procesador ampliamente soportado, para el que 24

25 Trabajo sobre Unshades Conclusiones estén disponibles las herramientas anteriormente mencionadas, como podría ser un ARM 13 o un ASIC Leon. Interfaces FPGA-P : para evitar que el interfaz fijo FPGA-P sea una fuente de problemas, tenemos dos opciones: la primera es estudiar cuidadosamente alguna placa ya existente para codiseño HW/SW que utilice el procesador escogido, para que quede perfectamente claro qué pines del P deben conectarse a la FPGA. La segunda es que todos los pines del procesador pasen por la FPGA antes de llegar a los dispositivos de la placa, opción que añade muchísima flexibilidad a la plataforma y que curiosamente es es lo que ocurre cuando se utiliza un softcore. RAM: Es necesario añadir una cantidad suficiente de RAM on-board para poder tener un sistema operativo y trabajar de forma cómoda. Con un mínimo de 4 megas ya podemos tener sistemas Linux con aplicaciones específicas (sin soporte para TCP/IP 14 ) sin que la memoria sea una restricción preocupante. Lo ideal, para aprovechar toda la potencia que ofrece Linux, es utilizar módulos DIMM, que se pueden encontrar en cualquier tienda de informática y nos permiten tener una capacidad de RAM del orden de cientos de megabytes. 13 Si bien la mayoría de modelos de ARM goza de un buen soporte por parte de las herramientas de software libre típicas (gcc, ecos, newlib), recomendamos con más énfasis aquellos dos modelos de ARM que ya disponen de soporte completo en PeaCE: ARM 926EJS y ARM 720T. 14 El soporte para TCP/IP y las aplicaciones que lo utilizan consumen una gran cantidad de memoria. 25

26 Capítulo 4 Solución propuesta A real decision is measured by the fact that you ve taken a new action. If there s no action, you haven t truly decided." Anthony Robbins Tras encarar los problemas encontrados en Unshades-2, se propuso una solución para hacer codiseño utilizando una plataforma hardware distinta, basada en una FPGA suficientemente potente como para albergar el softcore y la parte HW de un diseño híbrido. En principio teníamos dos placas disponibles, FT-Unshades 1 y Xess XSV-800. Escogimos la segunda por varias razones: por tener ésta una disponibilidad mayor (ya que las placas FT-Unshades de las que dispone el departamento están normalmente ocupadas en proyectos de investigación), porque las herramientas para programar los dispositivos on-board están disponibles para Linux 2, y porque la distribución del softcore Leon 2 soporta oficialmente la placa XSV-800, lo que en principio facilita una de las tareas a realizar, que es la implementación correcta del softcore en la placa de desarrollo Descripción de la solución propuesta La solución que aquí se propone consiste básicamente en una solución softcore en la que todos los elementos del sistema híbrido están implementados en la FPGA. Esto permite extender el trabajo realizado a otras placas con un poco de esfuerzo adicional. 1 Fault-Tolerant Unshades, la plataforma más moderna (a fecha de 2006) de la familia Unshades, desarrollada por el Área de Ingeniería Electrónica en un proyecto para la Agencia Espacial Europea, y especialmente preparada para realizar pruebas de tolerancia a fallos sobre circuitos para aplicaciones espaciales. 2 Cuando se comenzó el presente proyecto, las herramientas de FT-Unshades únicamente estaban disponibles para Windows. Actualmente las herramientas de FT-Unshades funcionan perfectamente bajo Linux, ya que fueron portadas en Marzo de

27 Solución propuesta 4.1 Descripción de la solución propuesta La plataforma sobre la que implementaremos el sistema es la placa de desarrollo XSV-800, de la X Engineering Software Systems Corporation (Xess). Esta placa posee suficiente RAM (2MBytes) y demás recursos on board y será descrita en más profundidad en el capítulo 6. De dicha placa bastará comentar por ahora que dispone de una FPGA Virtex XCV-800 [X E01b, Xil00], que dispone de aproximadamente puertas equivalentes (contando RAMs internas), lo cual es suficiente para implementar un softcore con varios periféricos y algún módulo hardware específico. En la FPGA Virtex XCV-800 implementaremos un procesador Leon 2, un modelo VHDL sintetizable de un procesador de 32 bits que cumple con el estándar Sparc V8. Las fuentes de este softcore están disponibles libremente bajo licencia GNU LGPL. Este procesador, junto con las razones por las que se ha escogido en lugar de alternativas como Microblaze, serán descrito en el capítulo 5 y, entre sus características, podemos destacar el hecho de que incluye una implementación del bus AMBA (versión 2.0), lo que permite añadir periféricos y otros módulos hardware de manera sencilla. Dado que necesitamos un sistema operativo sobre el que se ejecuten las tareas software, la parte SW del diseño correrá sobre Snapgear Linux, una distribución de Linux para sistemas integrados con soporte para el procesador Leon. Snapgear Linux es una variante de Clinux y en el capítulo 7 la describiremos y comentaremos las ventajas que nos ofrece. El entorno de codiseño propuesto para realizar codiseño es PeaCE, debido a las ventajas que ofrece, que se han comentado en el capítulo anterior y se verán en más profundidad en el capítulo 8. Además, otra razón para utilizar este entorno es que al no existir herramientas comerciales de codiseño HW/SW que tengan soporte para la familia de procesadores Leon, hemos de escoger una herramienta de código abierto a la que se pueda añadir soporte para estos procesadores. 27

28 Solución propuesta 4.1 Descripción de la solución propuesta Figura 4.1: Diagrama de bloques de la solución propuesta 28

29 Capítulo 5 Procesador Leon 2 You should probably read the manual" Jiri Gaisler, almost daily, on the leon-sparc mailing list Tras considerar las alternativas como Microblaze o softcores basados en ARM, se llegó a la conclusión de que el softcore más apropiado para ser utilizado en un proyecto basado en Linux es el procesador Leon 2, ya que es de código abierto y viene acompañado de las herramientas necesarias, que también son de código abierto: compiladores C, versión de Newlib, y versiones de ecos y Linux. En la sección 5.2 justificaremos en profundidad esta decisión Descripción El procesador Leon [Gai05] es una implementación en VHDL de un procesador de 32 bits compatible con el juego de instrucciones Sparc V8 [SPA92], desarrollado para la Agencia Espacial Europea y mantenido en la actualidad por Gaisler Research. Este procesador no sólo es de código abierto, sino que además no está ligado a ninguna tecnología de FPGA concreta, a diferencia de soluciones dependientes de fabricantes como Microblaze de Xilinx o Nios II de Altera. Entre sus características se pueden destacar: Cachés de instrucción y datos independientes Alu para mutiplicación y división hardware Interfaz para unidades de coma flotante y coprocesadores Bus AMBA 2.0 Controlador de interrupciones 29

30 Procesador Leon Descripción Controlador de memoria flexible, capaz de trabajar con SDRAM en modo 32 bits y con SRAM y ROM en modos configurables de 8, 16 o 32 bits Puerto de entrada y salida de 16 bits Dos UARTs Dos timers de 24 bits Unidad de Soporte de Depuración (DSU) Diagrama de bloques Figura 5.1: Diagrama de bloques del procesador Leon 2 El elemento central del procesador Leon 2 es su Integer Unit de 5 etapas pipelined. Esta Integer Unit está conectada a las cachés de instrucción y datos, y a la MMU 1. Ambas cachés son de tamaño configurable y pueden incluso no ser sintetizadas. La MMU también es opcional, y en este proyecto no se ha utilizado. En la figura 5.1 (página 30) se puede observar también la presencia de una unidad de punto flotante (Floating Point Unit o FPU) y de un co-procesador (CP), aunque en realidad el procesador Leon 2 no se distribuye con ninguno de estos elementos, sino que Gaisler Research dispone una unidad de punto flotante que se licencia de forma separada 2, y es el usuario el que puede o no implementar su propio coprocesador: el procesador Leon 2 implementa únicamente los interfaces a los que 1 Memory Management Unit. 2 Se trata de la GRFPU (Gaisler Research Floating Point Unit), aunque existen otras alternativas como la Meiko FPU y la LTH FPU. 30

31 Procesador Leon Descripción se conectarían el co-procesador y la FPU. No obstante, una síntesis del procesador Leon 2 sin ninguno de estos elementos es perfectamente funcional, aunque tenga menor rendimiento, y es la implementación que se ha realizado en este proyecto. Otro elemento muy interesante de este procesador es la Unidad de Soporte de Depuración (Debug Support Unit o DSU), que permite conectar un PC al procesador a través del puerto serie, ethernet o JTAG, para ayudar a la depuración de software, permitiendo la depuración on-line. Gracias a la DSU se pueden cargar programas directamente desde el PC, pausar y resetear el procesador, establecer puntos de ruptura (breakpoints) e incluso realizar ejecución paso a paso Bus Amba El procesador Leon implementa dos buses AMBA: AHB y APB. El bus APB 3 se utiliza para acceder a los registros on-chip de los periféricos, mientras que el bus AHB 4 se utiliza para transferencia de datos a alta velocidad. El bus AMBA hace muy sencillo extender la funcionalidad del procesador añadiendo módulos hardware. Incluso permite reutilización de código hardware, tanto del propio que desarrolle el diseñador como de módulos IP de otros desarrolladores [ARM99]. El mercado de propiedad intelectual pone al alcance de cualquier diseñador una biblioteca enorme de diferentes periféricos y unidades de proceso de datos [Gai04, Ope]. Debido a la gran aceptación que tiene el bus AMBA en la industria, se pueden encontrar fácilmente módulos hardware ya preparados para su conexión a dicho bus. Rango de direcciones Tamaño Registro Módulo 0x x1FFFFFFF 512 M Prom Controlador 0x x3FFFFFFF 512 M Memory bus I/O de memoria 0x x7FFFFFFF 1G SRAM y/o SDRAM 0x x9FFFFFFF 256 M DSU DSU 0xB xB001FFFF 128 K Registros Ethernet ethernet MAC Figura 5.2: Mapa de memoria AHB del procesador Leon 2 El mapa de memoria que aparece en la figura 5.2, en la página 31, es el mapa que se encuentra por defecto en la distribución oficial del procesador Leon 2, pero 3 Advanced Peripheral Bus. 4 AMBA High-performance Bus. 31

32 Procesador Leon Alternativas al procesador Leon 2 si fuera necesario podría modificarse. Además, el mapa de memoria del procesador no acaba aquí: los periféricos del procesador están conectados al bus APB, cuyo mapeo en memoria empieza en la dirección 0x (Memory configuration register 1), y la última dirección ocupada es la 0x800000CC (DSU UART scaler register), por lo que a partir de la dirección 0x800000D0 5 se pueden añadir periféricos custom (teniendo en cuenta que a partir de la 0x vuelven a estar ocupadas, en este caso por la DSU). La tabla con los registros concretos y las direcciones de memoria en las que están situados es demasiado extensa como para colocarla en el presente documento pero puede ser encontrada en el manual del procesador Leon 2 [Gai05] Alternativas al procesador Leon 2 El procesador Leon 2 no es el único softcore que se puede implementar en una FPGA, por lo que en su momento se realizó un estudio de softcores disponibles, para tomar una decisión informada sobre cuál utilizar: 1. Procesadores basados en ARM: la primera alternativa de softcore que se consideró fue una implementación de un procesador ARM que se realizó como proyecto de fin de carrera en el departamento en 2002 [CTAT02]. No se usó porque, si bien las instrucciones del juego ARM fueron probadas una por una con éxito, para garantizar el cumplimiento total de las especificaciones ARM de este procesador habría que utilizar vectores de test propietarios que sólo están disponibles para los desarrolladores que tengan licencia de ARM, por lo que se desconoce si este softcore funcionará adecuadamente al ejecutar programas complejos, como los producidos por un compilador C (en contraposición a los generados manualmente en ensamblador). Además, si bien el código VHDL del proyecto tiene una licencia de libre distribución, es posible que la distribución e implementación del core ARM en sí viole ciertas patentes de ARM. Todas estas dificultades, que surgen a causa de la proliferación de estándares cerrados, impiden el uso de este interesante core VHDL para nuevos proyectos. Esta situación es bastante desafortunada, ya que los procesadores ARM disponen de muchísimas herramientas como simuladores (Armulator), bibliotecas runtime (glibc y Newlib), compiladores e incluso un port de la distribución Debian GNU/Linux 6. 5 Realmente es a partir de la E0, ya que estudiando detalladamente el código del procesador Leon 2 se ha visto que en la dirección 0x800000D0 hay asignado un registro correspondiente al PCI target mapping. 6 Véase 32

33 Procesador Leon Alternativas al procesador Leon 2 Además, como se ha comentado en el capítulo 3, PeaCE ya trabaja con dos modelos de ARM (ARM 926EJS y ARM 720T). Dichos modelos están perfectamente integrados en el entorno, lo que significa que existe mucho trabajo ya realizado que se podría reutilizar. 2. Microblaze: este procesador, en principio, y ya que nosotros trabajamos con FPGAs de Xilinx, es una alternativa igual de válida que el procesador Leon 2. Pero hagamos unas consideraciones adicionales, pensando en la posibilidad de reutilizar los esfuerzos del presente proyecto en otros proyectos de investigación, sabiendo que muchos de los que se realizan actualmente en el Departamento de Ingeniería Electrónica comprenden la depuración hardware y/o la realización de pruebas de tolerancia a fallos: Cómo se hace depuración de HW/SW sobre Microblaze si es cerrado? Dónde introduces un SEU 7 para hacer pruebas de tolerancia a fallos? Cómo sabes bien qué estás leyendo o modificando? Será posible hacer ingeniería inversa, pero, merece la pena el esfuerzo? Además, en general para estos softcores dependes de las herramientas (compilador, simulador, c runtime library, S.O. en tiempo real) que te proporcione el fabricante 8. Por otro lado, la reutilización de software se complica si se utilizan sistemas operativos propietarios del fabricante (Nucleus o Xilkernel, en el caso de Microblaze), aunque también existe una versión de Clinux para Microblaze. 3. Nios II: para este procesador de Altera son válidas las consideraciones realizadas para Microblaze, pero con el agravante adicional de que difícilmente la implementación podrá realizarse y, en caso de que se pueda, no será nada eficiente en una FPGA de Xilinx. 4. Leon 3: este procesador, que es la evolución natural del procesador Leon 2, está escrito en un VHDL más difícil de entender que Leon 2, no posee compatibilidad binaria con éste, está peor documentado (a fecha de Octubre de 2005), y el único simulador disponible para él es el propietario TSIM. No obstante, ofrece mejores prestaciones 9 por lo que en el futuro, a medida que Leon 3 se vaya imponiendo como estándar de facto y Leon 2 vaya dejando de tener soporte, será inevitable considerar Leon 3 para proyectos de investigación y aplicación. 7 Single Event Upset. 8 Aunque en muchos de los casos, las herramientas de diseño de los fabricantes ejecutan en segundo plano versiones parcheadas de las herramientas GNU, como por ejemplo el mb-gcc, compilador de c para microblaze, lo cual da que pensar. 9 A costa de una mayor ocupación en área, por lo que para nuestra tarjeta de desarrollo es mejor idea utilizar Leon 2. 33

34 Procesador Leon Alternativas al procesador Leon 2 5. Leon 2: Leon 2 es un procesador con mayor base de usuarios (a fecha de Octubre de 2005, cuando se hicieron estas consideraciones), con todas las herramientas necesarias disponibles, incluso tenemos la opción de simular tanto con TSIM como con el simulador generado por ArchC [RABA04, ARB + 05], una herramienta de libre distribución que nos permite generar simuladores interpretados, simuladores compilados y ensambladores a partir de una descripción de la arquitectura del procesador 10. Como se ha comentado anteriormente, nos hemos fijado en Leon por ser de código abierto, y por no estar ligado a ninguna tecnología de FPGA concreta. Además de lo que se ha comentado anteriormente sobre Leon 3, una de las razones por las que se ha escogido para este proyecto Leon 2 es porque existe un board support package para la placa XSV-800 para Leon 2 que no existe para Leon Distintos cores del proyecto opencores [Ope]: se estuvieron evaluando algunos diseños del proyecto opencores, y en su momento se encontró que algunos no están terminados, otros están hechos pero no tienen todas las herramientas que necesitamos (diseñar el procesador es sólo el primer paso, el segundo es portar el toolchain GNU, y partir de ahí se pueden portar las herramientas y bibliotecas necesarias, pero ello requiere un esfuerzo considerable), y un problema mayor que plantean es que se desconoce si violan patentes, copyrights u otra clase de propiedad intelectual 12. De entre los procesadores evaluados, hay uno muy interesante, OpenRisc, descrito en Verilog, cuyo desarrollo está completo y tiene su propio port del toolchain GNU e incluso un ISS. Este procesador se plantea como una buena alternativa a Leon, pero dado que nosotros vamos a trabajar la parte HW de nuestro diseño en VHDL (ya que PeaCE trabaja con VHDL), e integrar VHDL con Verilog, si bien es factible, es poco conveniente y en algún momento podría causarnos problemas, por lo que finalmente se optó por utilizar el procesador Leon Actualmente, los desarrolladores del proyecto ArchC están trabajando en la descripción ArchC del procesador Leon 2 11 Más adelante comprobamos que dicho board support package no producía los resultados que eran de esperar, resultando en una netlist incorrecta, por lo que se tuvo que realizar la síntesis manualmente utilizando Xilinx ISE. 12 De hecho, entre los disclaimers que acompañan a los diseños de opencores, se pueden encontrar mensajes como: "I have no idea if implementing this core will or will not violate patents, copyrights or cause any other type of lawsuits. I provide this core as is, without any warranties." 34

35 Procesador Leon Configuración del modelo 5.3. Configuración del modelo El modelo se configura utilizando una herramienta basada en Tk que se distribuye con el mismo, por lo que hay que asegurarse de tener instaladas dichas herramientas. En Red Hat 8.0 se puede indicar durante el proceso de instalación del sistema operativo que queremos instalar las herramientas Tk. La figura 5.3 es una captura de pantalla de la herramienta de configuración que muestra la configuración de las memorias caché on-chip. La versión concreta de Leon 2 que se ha utilizado es la xst, y las características fundamentales de la configuración utilizada son: Ausencia de unidad de manejo de memoria (MMU), unidad de punto flotante (FPU) y coprocesador (CP). La unidad de enteros (integer unit) se ha configurado de forma que pueda responder a las instrucciones MUL/DIV del juego de instrucciones de Sparc V8, y se ha inferido un multiplicador para que estas instrucciones no tengan un tiempo de ejecución excesivo. Tecnología objetivo Virtex. Cachés de instrucciones y datos, cada una consta de 1 set de 4Kbytes y 32 bytes por línea. Unidad de Soporte de Depuración (DSU) habilitada. Controlador de memoria SRAM de 16 bits de ancho del bus de datos. Además, hemos modificado el wrapper leon_eth_xsv800.vhd, uniendo los pines RTS 13 y CTS 14 de la UART 1 (señales PIO(13) y PIO(12) del procesador), que es la que utilizaremos para establecer una comunicación con Snapgear Linux, a través del programa minicom 15. Es necesario realizar esto ya que, en caso contrario, Snapgear se cuelga al arrancar, durante la inicialización de la UART, ya que los pines que pretende utilizar para realizar el control de flujo por hardware (RTS y CTS) no están mapeados al exterior de la FPGA. Esto es así ya que la placa XSV-800 sólo dispone de un chip MAX232, lo cual significa que sólo tenemos cuatro señales disponibles: TX, RX, CTS y RTS, de forma que la UART1 de Leon 2 utiliza únicamente TX y RX, y la DSU transmite y recibe utilizando las pistas CTS y RTS. De hecho, para la realización de este proyecto se ha fabricado un 13 Request To Send. 14 Clear To Send. 15 Unir los pines CTS y RTS de una UART no es ninguna novedad: es lo que muchísimos cable modem nulos (null modem cables) hacen ya. 35

36 Procesador Leon Configuración del modelo Figura 5.3: Herramienta de configuración del procesador Leon 2 36

37 Procesador Leon Añadiendo la parte HW de tu diseño a Leon 2 XSV-800 Conector serie 1 (UART) Conector serie 2 (DSU) (conectará con minicom) (conectará con grmon TD RD - RD TD - CTS (Rx) - TD RTS (Tx) - RD GND GND GND Figura 5.4: Esquema del cable serie en Y cable en Y que permite realizar dos comunicaciones serie con la placa XSV-800 (ver figura 5.4 en la página 37). Para evitar las optimizaciones agresivas, hemos mapeado esta señal rts-cts a un pin de la FPGA (concretamente, a uno de los leds del diagrama de barras). Tenemos que añadir que en principio se intentó realizar la síntesis del procesador Leon con el módulo ethernet, pero esto no fue posible debido a un problema con los IOB 16 de la FPGA. Si bien este problema es solucionable, no se le prestó demasiada atención ya que nuestra placa de desarrollo está tan limitada en sus recursos RAM que aunque implementemos el módulo ethernet no podremos tener ninguna aplicación de red significativa, ya que este tipo de aplicaciones suelen demandar bastante RAM durante su ejecución Añadiendo la parte HW de tu diseño a Leon 2 Para añadir la parte hardware de un diseño a Leon 2, tenemos en principio 3 opciones: 1. Utilizar el interfaz genérico para conectar el Leon a un co-procesador: de esta forma, el bloque HW haría las veces de coprocesador. Como ventaja tiene que tendrá una rapidez considerable, ya que el interfaz conecta de una forma muy directa con el núcleo de la CPU, pero como desventajas tiene que el interfaz es bastante específico, por lo que no es extensible a otros procesadores, y además puede ser muy complicado realizar una exploración del espacio de diseño, y que para utilizar este enfoque se requiere obviamente que no dispongamos ya de un co-procesador que queramos utilizar. Como nota a considerar, comentaremos que realmente en muchos casos el codiseño hardware/software se plantea como el sintetizar ciertas tareas en 16 In/Out Blocks. 37

38 Procesador Leon Añadiendo la parte HW de tu diseño a Leon 2 un módulo hardware que actúa de co-procesador (recordemos el caso de Impulse C). 2. Añadir la parte HW del diseño como un periférico AHB, muy útil si queremos transferir grandes cantidades de información entre las partes HW y SW del diseño. 3. Añadir la parte HW del diseño como un periférico APB, con una tasa de transferencia de información menor, pero mucho más sencillo de implementar, es la elección ideal si las operaciones que se realizan en el interfaz HW/SW son operaciones de control más que de transferencia de grandes volúmenes de datos. En la aplicación de demostración realizada en el capítulo 9 utilizamos el bus APB, para demostrar lo sencillo que es añadir módulos HW, y también porque se trata de una aplicación de muy poca complejidad que no necesita de interfaces avanzados. Para añadir la parte HW de la aplicación de demostración, hay que definir dos señales en el módulo que correspondan a los buses de entrada y salida APB, modificar el fichero mcore.vhd para añadir nuestro componente hwpart como un periférico APB esclavo, y modificar apbmst.vhd para que extender la decodificación de las direcciones, de forma que nuestro periférico sea reconocido en la dirección de memoria que hemos escogido (concretamente la E0). Además, ya que la parte HW del diseño actúa directamente sobre leds de la placa, hay que modificar todos los ficheros de los niveles superiores en la jerarquía hasta llegar al wrapper externo (mcore.vhd, leon_eth.vhd y leon_eth_xsv800), y además añadir los pines de los leds al ucf. 38

39 Capítulo 6 Placa de desarrollo XSV-800 Playfully doing something difficult, whether useful or not, that is hacking" Richard Stallman, attributed 6.1. Descripción La plataforma sobre la que se ha implementado el sistema es la placa de desarrollo XSV-800 de Xess [X E01b]. Esta plataforma nos permite demostrar un sistema mínimo sobre una FPGA Virtex XCV800, de aproximadamente puertas equivalentes, si en la cuenta de puertas equivalentes incluimos a las RAM internas. Tanto la FPGA como la placa de desarrollo están ya descatalogadas, y los recursos en la placa están bastante limitados en relación a lo disponible hoy en día. La placa de desarrollo dispone únicamente 2MB de memoria SRAM, que se han de compartir entre la imagen desde la que se arrancará el sistema operativo y la memoria disponible para los procesos del sistema, ya que no vamos a utilizar la Flash. Esta Flash comparte pines del bus de direcciones con los interruptores DIP presentes en la placa, que utilizamos para activar la DSU del procesador, por lo que no podemos utilizar la Flash. 39

40 Placa de desarrollo XSV Descripción Figura 6.1: Xess XSV-800. Fotografía 40

41 Placa de desarrollo XSV Configuración 6.2. Configuración Configuración de jumpers La figura 6.2 muestra la configuración de jumpers utilizada. Jumper Configuración Efecto J13 y J14 Abiertos Alimentación utilizando fuente ATX J32 Shunt en pines 1-2 La alimentación de 2.5V para la FPGA se genera en la placa J22 Shunt en pines 2-3 Oscilador programado Shunt en pines 1-2 Oscilador en modo programación J36 Shunt en pines 1-2 CLK interno (generado por el oscilador) J23 Abierto La CPLD no puede ser reprogramada Cerrado La CPLD puede ser reprogramada J29, J30 y J31 Shunts en pines 2-3 Permiten el uso de xsload Figura 6.2: Configuración de jumpers empleada Los jumpers J37, J18, J34, J33, J16 sirven para configurar el puerto USB, y su disposición concreta no influye en nuestra aplicación ya que no utilizamos dicho puerto. Igualmente ocurre con los jumpers de otros dispositivos on-board, como el RAMDAC VGA. Para los jumpers para los que aparecen dos configuraciones, se utiliza una u otra según el efecto deseado Frecuencia de reloj Se ha programado el reloj de la FPGA a 20MHz. Como el oscilador es de 100MHz, esto significa que hemos programado el divisor de frecuencias a un valor de 5. Esto se hace utilizando la utilidad xssetclk, siempre que hayamos configurado adecuadamente el jumper J Reprogramación de la CPLD Ha sido necesario reconfigurar la CPLD presente en la placa para permitir el acceso por el puerto serie al procesador que implementaremos en la Virtex. Esto es indispensable para nuestro sistema, ya que el sistema operativo que introduciremos en la placa de desarrollo mapeará su entrada y salida de consola a través del puerto serie. 41

42 Placa de desarrollo XSV Xstools Figura 6.3: Diagrama de bloques de la plataforma Xess XSV-800 Para ello, se ha modificado el fichero de programación de la CPLD, dwnldpar.vhd, siguiendo las notas de [X E00]. Reprogramar la CPLD de la placa es una acción potencialmente peligrosa, ya que si se programaran los pines del JTAG de la CPLD como pines de salida 1, no podríamos volver a programarla, siendo la única solución en ese caso el extraer el dispositivo de la placa y sustituirlo por otro Xstools El paquete XSTOOLs [X E01a] contiene las siguientes herramientas GUI y sus alternativas de línea de comandos: GXSTEST / XSTEST: Esta utilidad permite hacer un test a la placa para comprobar que su funcionamiento es correcto. 1 Realmente, los pines 63, 71, 73 y 78 se podrían programar como salidas, pero en ese caso es indispensable que entren en un estado de alta impedancia cuando el pin DONE de la Virtex esté a nivel bajo (de forma que la CPLD se pueda reprogramar al encender la placa, cuando la FPGA aún no ha sido programada). 42

43 Placa de desarrollo XSV Xstools GXSSETCLK / XSSETCLK: Esta utilidad permite configurar la frecuencia de reloj del oscilador programable de la placa. GXSLOAD / XSLOAD: Esta utilidad permite programar la FPGA y la CPLD y leer y escribir ficheros de datos en la RAM y la Flash de la placa. GXSPORT / XSPORT: Esta utilidad permite enviar entradas lógicas a una placa XS cambiando los pines de datos del puerto paralelo. Las mismas herramientas sirven para toda la familia de placas XS, ya que su arquitectura es similar, basada en un dispositivo programable de configuración no volátil (la CPLD) en el cual se centralizan las acciones de programación y configuración de los distintos dispositivos on-board. El código fuente de las herramientas XSTOOLs fue liberado al dominio público por Xess, lo que ha posibilitado que exista un port de estas herramientas para Linux, y es este port el que hemos compilado y utilizado con éxito en este proyecto. 43

44 Capítulo 7 Snapgear Linux All the best people in life seem to like Linux" Stephen Wozniak 7.1. Necesidad de un sistema operativo Utilizar un sistema operativo en nuestro sistema integrado, en lugar de programar directamente las rutinas específicas de nuestra aplicación en código ensamblador, ofrece una serie de ventajas, siendo la más importante la capacidad de tener múltiples tareas ejecutándose en el microprocesador, y esto es de gran importancia para hacer codiseño HW/SW, ya que es de esperar que se tengan varias tareas ejecutándose en software. Para nuestro sistema, se ha decidido utilizar Snapgear Linux, una distribución de Linux específica para sistemas integrados con soporte para la familia de procesadores Leon Descripción Linux es un sistema operativo muy conocido, maduro y con soporte, multitarea, con posibilidad de trabajo en tiempo real, y con muchas aplicaciones estables que se pueden utilizar sin que sea necesario modificarlas. Con respecto a otros sistemas operativos para sistemas integrados, Linux para sistemas integrados tiene la ventaja de presentar la misma interfaz a las aplicaciones que su versión para ordenadores personales, de forma que es posible utilizar, para el desarrollo de las aplicaciones, una plataforma muy semejante, con un entorno de ejecución y herramientas muy similares (las mismas), a las que luego estarán disponibles en el sistema integrado. El desarrollo y la posterior depuración de las aplicaciones son 44

45 Snapgear Linux 7.2 Descripción mucho más sencillos para el diseñador cuando el sistema operativo y el entorno de ejecución son los mismos en el PC de desarrollo y en el sistema final. Además, Linux, al ser un sistema UNIX, es un sistema tan interactivo que ofrece la posibilidad de realizar actualizaciones del software desde dentro del mismo, es decir, si el sistema dispone de suficiente memoria, es posible instalar el compilador de c (gcc) y, con este compilador recompilar las aplicaciones que necesitemos modificar, sin necesidad de parar el sistema completo ni las aplicaciones que no se modifiquen. En lugar de Linux, podíamos habernos decantado por ecos, un sistema operativo en tiempo real desarrollado inicialmente por Cygnus Solutions y en la actualidad mantenido por ecoscentric. Este sistema operativo es especialmente útil cuando se tiene una plataforma con muy poca memoria disponible (su huella se puede reducir hasta los cientos o decenas de KBytes), pero ya que en nuestra plataforma tenemos memoria suficiente como para implementar un sistema Linux mínimo, sabiendo que Linux tiene mayor base de usuarios y una ingente cantidad de colaboradores y usuarios y, considerando además la posibilidad de reutilizar los conocimientos aprendidos de este proyecto en plataformas con mayores prestaciones, hemos decidido finalmente utilizar Linux en lugar de ecos Kernels para sistemas con y sin MMU Para que un sistema operativo como Linux pueda funcionar en un procesador, normalmente es necesario que dicho procesador disponga de una unidad de manejo de memoria (MMU), que se encarga de dar a cada proceso un espacio de memoria protegida, y de proteger al kernel de los procesos. Además, la MMU se encarga de realizar la traducción de las direcciones de memoria virtuales a direcciones físicas antes de cada acceso a memoria, presentando al núcleo y a los procesos una interfaz estándar para el acceso a memoria. Afortunadamente existen versiones del núcleo de Linux que han sido adaptadas para su uso en procesadores que carecen de MMU [DL02]. Snapgear Linux ofrece la posibilidad de ejecutar kernels tanto para sistemas con unidades de manejo de memoria tanto para sistemas que carecen de ella. El procesador leon 2 incluye una unidad de manejo de memoria que se puede implementar, como se ha comentado en el capítulo 5, si le da la opción correspondiente en el menú de configuración del procesador, con el consecuente incremento del tamaño del diseño. Dado que la plataforma utilizada tiene ciertas limitaciones, ha sido necesario sintetizar el procesador sin unidad de manejo de memoria, por lo que finalmente se ha configurado el sistema Linux con un kernel con soporte para sistemas non-mmu. Concretamente, en la implementación aquí descrita se ha utilizado un kernel con este soporte. La herramienta de configuración (ver figura 7.1) ofrece la posibilidad de ajus- 45

46 Snapgear Linux 7.3 Configuración tar las opciones concretas del núcleo Linux que se implementarán, así como las aplicaciones concretas que se compilarán en el sistema, de forma que se puede ganar espacio eliminando las funcionalidades que no se necesiten. Snapgear Linux permite añadir de forma sencilla aplicaciones específicas, que se compilarán junto al resto del sistema. Ya que el entorno utilizado comprende lenguaje C, las herramientas de desarrollo UNIX normales (gcc, make) y el API de un sistema POSIX, existen muchas facilidades para la reutilización del código. Esto, unido a, como se ha comentado anteriormente, que el entorno de ejecución final es el mismo que el de desarrollo de la aplicación, permite construir versiones integradas de aplicaciones previamente desarrolladas sobre ordenadores personales Configuración La versión concreta de snapgear que hemos utilizado es la versión p-17. Al igual que el procesador Leon 2, Snapgear Linux se configura utilizando una herramienta basada en Tk. Se ha tenido especial cuidado en la configuración de Snapgear Linux ya que nuestra placa está bastante limitada en lo que a recursos respecta. Ya que únicamente disponemos de 2MB de RAM, espacio que ha de compartirse con la imagen RAM, y Clinux necesita alrededor de 1MB de RAM para poder ejecutar un sistema mínimo 1, hemos reducido la imagen RAM todo lo posible eliminando funcionalidades no necesarias. La ocupación en RAM de la imagen de Linux obtenida finalmente ha sido de alrededor de 600KB, por lo que queda más de 1MB de memoria para uso de las aplicaciones. Las características fundamentales de la configuración utilizada son: Parámetros del procesador: Fabricante Gaisler y Modelo Leon 2 Versión del núcleo: linux nommu Biblioteca estándar C: uclibc Tipo de ram: SRAM. 2 bancos de 8 MBytes cada uno. Estados de espera en lectura (rws), escritura (wws) y modificación (rms): 1. Configuración del núcleo: Sin soporte para aplicaciones de red 1 En el caso de tener menos memoria, tendremos errores de tipo failed to free page, debido a que Linux no puede reservar la memoria necesaria para los procesos que se quieren ejecutar. En estos casos no es raro observar que la memoria que requiere un proceso es menor que la memoria libre total, pero aún así no se puede ejecutar el proceso. Esto se debe a que toda la memoria que se asigne inicialmente a un proceso debe ser contigua. 46

47 Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear Huella reducida Soporte para el sistema de archivos /proc 2 Soporte para comunicaciones serie Versiones de kmalloc.c/page_alloc.c que hacen un mejor aprovechamiento de la memoria. Configuración de las aplicaciones: se han eliminado todas las aplicaciones de red, lo cual ha ayudado mucho a reducir el tamaño de la imagen RAM. Además, utilizamos un programa muy compacto llamado BusyBox que hace las veces de init y se puede configurar para que proporcione las funcionalidades de múltiples comandos de shell, como ls o ps. El shell que hemos utilizado es sash (stand-alone shell), un shell frecuentemente usado en sistemas integrados y en operaciones de recuperación de sistemas ya que está enlazado estáticamente, por lo que no necesita de librerías dinámicas para su funcionamiento. Para la conexión con Snapgear Linux, configuramos al programa minicom con los siguientes parámetros: 1. Parámetros de comunicación: a) Velocidad: baudios b) Datos: Palabras de 8 bits c) Paridad: Ninguna d) Bits de parada: 1 2. Carácter que envía la tecla Backspace: DEL 3. Line wrapping (evita que aparezcan en pantalla líneas que se salgan del margen de la consola): ON La figura 7.2 es una captura de pantalla del programa minicom, a través del cual establecemos una comunicación serie con el sistema integrado. En la figura se puede apreciar el shell del sistema tras un arranque satisfactorio Añadiendo la parte SW de tu diseño a snapgear Añadir la parte software de un diseño híbrido es bastante sencillo, y básicamente consiste en añadir un programa a la distribución Snapgear. Dicho programa 2 /proc es un sistema de archivos virtual que proporciona información útil del sistema. 47

48 Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear Figura 7.1: Herramienta de configuración de Snapgear 48

49 Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear Figura 7.2: Captura de pantalla del programa minicom 49

50 Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear interactuará con el HW leyendo y escribiendo en los registros del bus AMBA que pertenezcan a la parte hardware. Los pasos que se han seguido para añadir la parte SW de la aplicación de demostración descrita en el capítulo 9 han sido los siguientes: Crear la carpeta <snapgear>/user/swpart, siendo <snapgear> el directorio raíz de las fuentes de la distribución. Escribir el código fuente del programa, dentro de user/swpart. En nuestro caso, ya que se trata de una aplicación sencilla, el código fuente consiste únicamente de un fichero: swpart.c Escribir un Makefile, dentro de user/swpart, para automatizar la compilación del SW y para integrarlo en snapgear, de forma que se compile automáticamente junto con el resto de la distribución. El makefile tendrá tres reglas que son invocadas automáticamente por los Makefiles generales de Snapgear: all, que compila el programa y crea los binarios y ejecutables, romfs, que copia los binarios al directorio romfs (a partir del cual se creará la imagen RAM), y clean, que elimina los archivos temporales y productos de la compilación. #Makefile para la parte SW de la aplicación de demostración EXEC1 = swpart OBJS1 = swpart.o %o : %cxx $(CXX) -v -I /opt/sparc-linux/include/c++/ I /opt/sparc-linux/include/c++/3.2.2/backward -I /opt/sparc-linux/include/c++/3.2.2/sparc-linux $(CFLAGS) -c -o $@ $< #Los makefiles de snapgear llamaran a este haciendo make all all: $(EXEC1) $(EXEC1): $(OBJS1) echo "LDFLAGS: $(LDFLAGS)" $(CC) $(LDFLAGS) -o $@ $(OBJS1) $(LDLIBS$(LDLIBS_$@)) -lm -lgcc -lm -lgcc romfs: clean: $(ROMFSINST) /bin/$(exec1) -rm -f $(EXEC1) *.elf *.gdb *.o 50

51 Snapgear Linux 7.4 Añadiendo la parte SW de tu diseño a snapgear Para que en el menú de configuración de Snapgear aparezca nuestra aplicación, añadir una entrada al fichero <snapgear>/config/config.in, concretamente en nuestro caso: bool SW part of codesign application CONFIG_USER_SWPART Para que la configuración anterior se traduzca efectivamente en una compilación de nuestra aplicación, hay que añadir una entrada al fichero <snapgear>/user/makefile: dir_$(config_user_swpart) += swpart El último paso, opcional, consiste en escribir unas líneas de información para el fichero de ayuda <snapgear>/config/configure.help: Prompt to include or not the SW part of the design CONFIG_USER_SWPART Compile and include the SW part of the sample hybrid design. The executable name will be swpart. Tras esto sólo queda arrancar la herramienta de configuración (haciendo make xconfig en el directorio raíz de snapgear) y seleccionar swpart como aplicación a añadir. Figura 7.3: Herramienta de configuración de Snapgear, modificada 51

52 Capítulo 8 Entorno de codiseño PeaCE I think the best way to overcome this hurdle is that you visit our lab. during the summer season for one month with your board for PeaCE customization. We are also very interested in supporting you and your system." Soonhoi Ha, director del proyecto PeaCE 8.1. Descripción y características El proyecto PeaCE (Ptolemy extension as Codesign Environment) nace a partir de los esfuerzos de investigación de Ptolemy, un proyecto desarrollado en el Center for Hybrid and Embedded Software Systems (CHESS) del Department of Electrical Engineering and Computer Sciences de la Universidad de California, en Berkeley [BHLM92, Pto]. El proyecto estudiaba el modelado, la simulación y el diseño de sistemas integrados concurrentes en tiempo real, y su enfoque principal es la yuxtaposición de componentes concurrentes. El principio clave y gran acierto de Ptolemy es el uso de modelos formales 1 de computación, que gobiernan la interacción entre componentes, de forma que se pueden utilizar mezclas heterogéneas de modelos de computación. PeaCE, un proyecto del Codesign And Parallel Processing Laboratory (CAP Lab.), de la Universidad Nacional de Seoul, hereda estas características con la intención de abarcar una metodología completa para co-especificar, co-simular y co-sintetizar módulos de diferentes características en el mismo entorno de trabajo [CAP04, CAP05]. El objetivo del proyecto PeaCE es cubrir las múltiples facetas de las tareas de codiseño: codiseño de módulos hardware y software, y codiseño de módulos de control y función. 1 La idea esencial de la formalidad de estos modelos es que están perfectamente definidos, de forma que no puedan existir ambiguedades sobre el comportamiento de un sistema especificado en base a estos modelos, por muy complejo o heterogéneo que sea. 52

53 Entorno de codiseño PeaCE 8.1 Descripción y características Las características clave de PeaCE son las siguientes: Framework opensource, que incentiva la colaboración entre desarrolladores. Entorno altamente reconfigurable, de forma que se pueden integrar en él herramientas de otros desarrolladores en el entorno. Para este propósito, los distintos pasos del flujo de diseño están todo lo desacoplados que se puede desde un punto de vista práctico, y se utiliza un interfaz basado en ficheros (concretamente en ficheros XML) entre los pasos del flujo de diseño. La utilidad de estos interfaces se ha demostrado ya, al haberse conseguido la integración de la herramienta de cosimulación Seamless CVE en el flujo de diseño de PeaCE. GUI Java (Hae) independiente del núcleo. De esta forma se tiene un interfaz de usuario gráfico y sencillo, que además es independiente de la plataforma. Núcleo C++ orientado a objetos heredado de Ptolemy. El núcleo, desacoplado del interfaz de usuario, está diseñado para tener altas prestaciones. Esta arquitectura cliente-servidor permite tener un servidor dedicado al que se conecten clientes desde distintos sistemas operativos. Diseño de sistema multilingüe. La decisión de qué lenguaje utilizar para realizar la descripción del sistema en un entorno de codiseño siempre ha sido motivo de discusión. Por ello PeaCE permite el uso de múltiples lenguajes, definiendo cuidadosamente cómo se integran en el diseño de un único sistema. PeaCE utiliza distintos modelos de computación para representaciones funcionales y de control, y estos modelos residen en otro modelo de computación que se encarga de la integración de los distintos bloques a nivel de sistema 2. Síntesis automática de hardware y software: a partir de las especificaciones iniciales, se genera el código C y/o VHDL necesario. Particionado HW/SW automático: la exploración del espacio de diseño se efectúa en un bucle jerárquico para reducir el tiempo de exploración sin sacrificar la calidad de la solución encontrada. Nótese que muy pocas herramientas de codiseño ofrecen la posibilidad de realizar el particionado HW/SW de forma automatizada. 2 Concretamente: SPDF (Synchronous Piggybacked DataFlow Model) para modelado y especificación de elementos Dataflow (función), DE (Discrete Event) Model para modelado y especificación de Eventos Discretos, ffsm (flexible Finite State Machine) Model para modelado y especificación de máquinas de estados finitas (control), y por último BP (BackPlane) para modelado de tareas, es decir, para modelar a un nivel superior (nivel de sistema) las interconexiones entre los bloques, que internamente pueden ser ffsm o SPDF. 53

54 Entorno de codiseño PeaCE 8.2 Ventajas con respecto a otras soluciones 8.2. Ventajas con respecto a otras soluciones Todas las características de este entorno de codiseño se traducen en una serie de ventajas que ofrece PeaCE a un grupo de investigación como los del Departamento de Ingeniería Electrónica y que se pueden resumir de la siguiente manera: Entorno de código abierto, lo que permite extenderlo, añadiéndole soporte para nuevas plataformas y procesadores. Además, el hecho de que el código sea abierto permite entender mejor los pasos del flujo de diseño e incluso permite ampliar las líneas de investigación del departamento, por ejemplo, es posible implementar un nuevo algoritmo de particionado HW/SW, integrarlo en PeaCE, y realizar una comparativa con el que ya ofrece el entorno. Es un proyecto de codiseño que está vivo y sus desarrolladores están siempre dispuestos dar soporte. De hecho, es el único entorno de codiseño de código abierto que es un proyecto vivo a fecha de Como añadido, si se cambia de fabricante de hardware no se tiene por qué cambiar de entorno de codiseño, lo que permite reutilizar las descripciones a alto nivel que ya se tengan, ya que seguirían siendo válidas. La peculiar arquitectura cliente-servidor nos permite tener un único servidor Linux y clientes accediendo desde cualquier sistema operativo. 54

55 Entorno de codiseño PeaCE 8.3 Flujo de diseño en PeaCE 8.3. Flujo de diseño en PeaCE El flujo de diseño en PeaCE consta de 8 pasos [CAP05]. En la figura 8.1 se puede apreciar que a través de las pestañas de la ventana de proyecto se puede accerder a los distintos pasos del flujo de diseño. Figura 8.1: Especificación del sistema en PeaCE 1. Especificación de algoritmos y simulación funcional. Esta especificación se realiza utilizando el interfaz gráfico proporcionado por Hae, el cliente Java. La especificación es jerárquica y haciendo doble click sobre un bloque se abre una ventana con la descripción interna del bloque, hasta que se llega al nivel mínimo de detalle. En este nivel mínimo lo que se ve es una descripción, en modo texto, del funcionamiento de este bloque en PeaCE (ver figura 8.2). 55

56 Entorno de codiseño PeaCE 8.3 Flujo de diseño en PeaCE Figura 8.2: Especificación de algoritmos en PeaCE 2. Descripción de la arquitectura. En este paso se describe la arquitectura del sistema de una forma abstracta (CPUs, ASICs, buses). Esta descripción de arquitectura proporciona al algoritmo de particionado HW/SW información sobre los elementos de procesado disponibles (figura 8.3). 56

57 Entorno de codiseño PeaCE 8.3 Flujo de diseño en PeaCE Figura 8.3: Especificación de arquitectura en PeaCE 3. Estimación de rendimiento. La estimación de rendimiento de los bloques HW debe ser realizada a priori por el diseñador del bloque, y la estimación del rendimiento del SW se realiza utilizando un ISS 3. Esta estimación es necesaria para poder realizar el particionado automático HW/SW. 4. Generación de ficheros XML de interfaz, que sirven para poder integrar otras herramientas en el flujo de codiseño de PeaCE. En este paso se generan 3 ficheros: <proj-name>.xml con la topología del sistema, <projname>_timecost.xml, con los resultados de la estimación de rendimiento, y <proj-name>_mode.xml, con las restricciones de timing de cada tarea. 5. Particionado HW/SW. PeaCE permite realizar un particionado HW/SW automático, utilizando los resultados de los pasos anteriores, o bien realizar un particionado manual. En el caso de no disponer de una estimación de rendimiento, la única opción es el particionado manual. 6. Exploración del espacio de diseño (DSE o Design Space Exploration). Tras el particionado, el siguiente paso consiste en explorar la arquitectura de comunicaciones, basándonos en la traza de memoria de cada elemento del 3 Aunque también se podría realizar sobre una placa prototipo de la que podamos extraer información. 57

58 Entorno de codiseño PeaCE 8.3 Flujo de diseño en PeaCE sistema y en el orden en el que deben ejecutarse las tareas. Este paso también necesita de un simulador para cada recurso computacional del sistema (CPUs y hardware programable). 7. Cosimulación HW/SW para co-verificación. En el penúltimo paso se realiza una simulación del sistema completo, para verificar que su funcionamiento es correcto. PeaCE da la posibilidad de realizar la cosimulación utilizando un ISS y un simulador de VHDL, gracias a la sincronización virtual basada en la traza de memoria, aunque también permite utilizar Seamless CVE para realizar la cosimulación. Dado que Seamless CVE no tiene soporte para la familia de procesadores Leon, nuestra única opción sería utilizar un ISS. 8. Cosíntesis: En este paso, PeaCE genera automáticamente código VHDL y C para el hardware y software respectivamente, además de los drivers para Linux necesarios para que las tareas que se implementan en software puedan comunicarse con el hardware. Aunque es factible, desafortunadamente no sea ha realizado aún la adaptación de PeaCE para la plataforma XSV-800 y el procesador Leon 2, ya que la tarea escapa del alcance del proyecto. No obstante, se propone como posibilidad de ampliación. 58

59 Capítulo 9 Aplicación de demostración Now we ll play salsa. The way we know it." Tito Puente 9.1. Visión general Se ha realizado una mínima aplicación de codiseño, de forma manual, como conclusión del presente proyecto y demostración de las capacidades de la solución propuesta. El objetivo de esta aplicación es demostrar el co-funcionamiento HW/SW, la interfaz HW/SW (basada en bus AMBA, concretamente en el bus APB), y los interfaces con el exterior: tanto a través de pines específicos de la FPGA (en este caso, los pines que encienden los displays LED de siete segmentos de la placa XSV-800) como a través de línea de comandos (interfaz con un operador), todo ello utilizando un sistema mínimo con recursos limitados. Un beneficio añadido de esta aplicación realizada de forma manual es que sirve de punto de partida para añadir soporte para Leon 2 a PeaCE 1. La aplicación hibrída, como no puede ser de otra forma, consta de una parte hardware, que se añade y sintetiza junto al resto del modelo del procesador Leon 2, y de una parte software que se añade y compila junto a Snapgear Linux. La generación del interfaz HW/SW, una tarea muy significativa y vital para toda aplicación de codiseño, ha sido facilitada enormemente gracias a la implementación del bus AMBA de la que dispone Leon 2. Básicamente nuestra aplicación es un contador de segundos, implementado en hardware, con sentidos de cuenta tanto creciente como decreciente, y con máximo 1 Normalmente, para añadir soporte para nuevos procesadores y plataformas a PeaCE, primero se porta o diseña una aplicación híbrida manualmente y luego, una vez que se ha demostrado el funcionamiento de la aplicación en la plataforma objetivo, se automatiza el proceso de co-síntesis de PeaCE para dicha plataforma. 59

60 Aplicación de demostración 9.2 Parte hardware y mínimo configurables que se programan desde la parte software del diseño. El funcionamiento de la aplicación realizada se puede observar en las imágenes 9.2, 9.3 y Parte hardware La parte hardware del diseño se ha definido en un fichero vhdl, hwpart.vhd. Este módulo HW recibe, además de las señales globales de reset y clk, la señal de entrada del bus APB (apbi) y sus salidas son la señal de salida del bus APB (apbo) y las señales que encenderán los leds del display de siete segmentos. Las señales apbi y apbo son las entradas y salidas APB, y son de tipo APB_Slv_In_Type y APB_Slv_Out_Type, que son records, o conjunto de señales 2 : cada uno contiene todas las señales que se utilizan para la entrada (o salida) de señales APB al módulo. Figura 9.1: Esquema de entradas y salidas del módulo HW Los records APB_Slv_In_Type y APB_Slv_Out_Type se definen en el fichero 2 Unir las señales por grupos funcionales es una muy buena idea y simplifica enormemente el conexionado de los elementos de la jerarquía de un diseño. 60

61 Aplicación de demostración 9.2 Parte hardware amba.vhd del modelo de Leon 2: Constant definitions for AMBA(TM) APB constant PDMAX: Positive range 8 to 32 := 32; -- data width constant PAMAX: Positive range 8 to 32 := 32; -- address width Definitions for AMBA(TM) APB Slaves APB slave inputs (PCLK and PRESETn routed separately) type APB_Slv_In_Type is record PSEL: Std_ULogic; -- slave select PENABLE: Std_ULogic; -- strobe PADDR: Std_Logic_Vector(PAMAX-1 downto 0); -- address bus (byte) PWRITE: Std_ULogic; -- write PWDATA: Std_Logic_Vector(PDMAX-1 downto 0); -- write data bus end record; -- APB slave outputs type APB_Slv_Out_Type is record PRDATA: Std_Logic_Vector(PDMAX-1 downto 0); -- read data bus end record; El comportamiento del módulo hwpart está definido básicamente por cuatro procesos concurrentes: 1. El proceso calc_p_value implementa el comportamiento del contador: cada segundo, si el valor del contador llega al máximo, se cambia el comportamiento a decrecer (going_up = 0 ) y reduce su valor, y si llega al mínimo, cambia el comportamiento (going_up = 1 ). Además, si los valores mínimo y máximo son el mismo, el contador toma ese valor, lo que nos permite precargar el contador a un valor concreto. 2. Los procesos calc_left_led y calc_right_led calculan las señales que irán a los displays de 7 segmentos a partir del valor del contador. Para aprovechar todo el rango entre 0 y 255, cada uno de los dígitos led representará un dígito en hexadecimal (es decir, tomará valores entre 0 y F). 3. Por último, el proceso sinc se encarga de capturar los valores de las señales síncronas. El módulo hwpart interpreta la información que recibe por el bus APB de la siguiente forma: los 8 bits menos significativos del dato recibido serán el valor mínimo del contador, y los siguientes 8 bits serán el valor máximo. El resto de bits recibidos se descarta. Por lo que a la salida respecta, el módulo hardware siempre está comunicando el valor del contador por el bus APB, pero sólo se podrá leer dicho valor cuando la dirección en el bus AMBA sea la del módulo hardware. 61

62 Aplicación de demostración 9.2 Parte hardware This file is a heavily modified version of ioport.vhd -- as a derived work of the file and also of the Leon 2 processor, -- the license which applies is -- the GNU Lesser General Public License. -- See below for details The original file is a part of the LEON VHDL model -- and has Copyright (C) 1999 European Space Agency (ESA) This library is free software; you can redistribute it and/or -- modify it under the terms of the GNU Lesser General Public -- License as published by the Free Software Foundation; either -- version 2 of the License, or (at your option) any later version See the file COPYING.LGPL for the full details of the license Entity: hwpart -- File: hwpart.vhd -- Author: Hipólito Guzmán Miranda (based on J. Gaisler s ioport.vhd) -- Description: HW part of a sample codesign application library IEEE; use IEEE.std_logic_1164.all; --use IEEE.std_logic_signed."-"; use IEEE.std_logic_arith.all; use IEEE.std_logic_unsigned.all; use work.config.all; use work.iface.all; use work.macro.genmux; use work.amba.all; entity hwpart is port ( rst : in std_logic; clk : in clk_type; apbi : in apb_slv_in_type; apbo : out apb_slv_out_type; left_led : out std_logic_vector (6 downto 0); right_led : out std_logic_vector (6 downto 0) ); end; architecture rtl of hwpart is constant CYCLESPERSECOND : integer := ; signal value, p_value : integer range 0 to 255; -- 8 bits signal value_max, value_min : integer range 0 to 255; -- 8 bits signal value_bits : std_logic_vector (7 downto 0); signal left_digit, right_digit : std_logic_vector (3 downto 0); --digits signal cyclecount, p_cyclecount : integer range 0 to ; bits -- this is not optimal and could be split into a cycle counter -- and a msec counter 62

63 Aplicación de demostración 9.2 Parte hardware signal filler : std_logic_vector(pdmax-1 downto 8); signal received_apb_data, p_received_apb_data : std_logic_vector(pdmax-1 downto 0); signal going_up, p_going_up : std_logic; -- direction of the count begin filler <= (others => 0 ); p_cyclecount <= 0 when cyclecount = CYCLESPERSECOND else cyclecount + 1; value_bits <= conv_std_logic_vector(value,8); left_digit(3 downto 0) <= value_bits(7 downto 4); right_digit(3 downto 0) <= value_bits(3 downto 0); -- The APB input: p_received_apb_data <= apbi.pwdata when (apbi.psel and apbi.penable and apbi.pwrite) = 1 else received_apb_data; value_max <= conv_integer(received_apb_data (15 downto 8)); value_min <= conv_integer(received_apb_data (7 downto 0)); sinc: process (rst, clk) begin if (rst= 0 ) then value <= 0; cyclecount <= 0; received_apb_data <= (others => 0 ); going_up <= 1 ; elsif (clk= 1 AND clk event) then value <= p_value; cyclecount <= p_cyclecount; received_apb_data <= p_received_apb_data; going_up <= p_going_up; end if; end process sinc; calc_p_value: process (cyclecount, value, value_max, value_min) begin if (cyclecount = CYCLESPERSECOND) then if (value_max = value_min) then p_value <= value_max; -- this allows us to preload the counter p_going_up <= going_up; elsif (value = value_max) then p_going_up <= 0 ; p_value <= value - 1; elsif (value = value_min) then p_going_up <= 1 ; p_value <= value + 1; else if (going_up = 1 ) then p_value <= value + 1; else p_value <= value - 1; end if; p_going_up <= going_up; end if; else p_value <= value; end if; end process calc_p_value; -- Here we convert HEX to BCD calc_left_led: process (left_digit) 63

64 Aplicación de demostración 9.2 Parte hardware begin case left_digit is when "0000" => left_led <= " "; -- 0 when "0001" => left_led <= " "; -- 1 when "0010" => left_led <= " "; -- 2 when "0011" => left_led <= " "; -- 3 when "0100" => left_led <= " "; -- 4 when "0101" => left_led <= " "; -- 5 when "0110" => left_led <= " "; -- 6 when "0111" => left_led <= " "; -- 7 when "1000" => left_led <= " "; -- 8 when "1001" => left_led <= " "; -- 9 when "1010" => left_led <= " "; -- A when "1011" => left_led <= " "; -- b when "1100" => left_led <= " "; -- C when "1101" => left_led <= " "; -- d when "1110" => left_led <= " "; -- E when "1111" => left_led <= " "; -- F when others => left_led <= " "; end case; end process calc_left_led; -- default calc_right_led: process (right_digit) begin case right_digit is when "0000" => right_led <= " "; -- 0 when "0001" => right_led <= " "; -- 1 when "0010" => right_led <= " "; -- 2 when "0011" => right_led <= " "; -- 3 when "0100" => right_led <= " "; -- 4 when "0101" => right_led <= " "; -- 5 when "0110" => right_led <= " "; -- 6 when "0111" => right_led <= " "; -- 7 when "1000" => right_led <= " "; -- 8 when "1001" => 64

65 Aplicación de demostración 9.3 Parte software right_led <= " "; -- 9 when "1010" => right_led <= " "; -- A when "1011" => right_led <= " "; -- b when "1100" => right_led <= " "; -- C when "1101" => right_led <= " "; -- d when "1110" => right_led <= " "; -- E when "1111" => right_led <= " "; -- F when others => right_led <= " "; -- default end case; end process calc_right_led; -- The APB output: apbo.prdata(pdmax-1 downto 8) <= filler; apbo.prdata(7 downto 0) <= value_bits; end; 9.3. Parte software La parte software del diseño es también muy sencilla, y sirve para demostrar, además de la sinergia entre el hardware y el software, la interfaz con el usuario a través de la línea de comandos. El usuario invoca al programa con el comando swpart <value1> <value2>, donde <value1> y <value2> son dos números entre 0 y 255. El programa se encarga de determinar cuál de los dos números es el mayor, tras lo cual genera el valor que ha de enviar por el bus APB a la dirección del módulo hwpart (0x800000E0), y escribe el valor adecuado en dicha dirección. Tras esta operación, el programa espera 3 segundos, para permitir al usuario comprobar el valor que se ha enviado a la parte hardware, y entra en un bucle infinito en el que realiza una lectura del valor del contador cada segundo y saca su valor (en decimal y en hexadecimal) por pantalla. La lectura y escritura en la dirección de memoria en la que está ubicada la parte hardware se puede realizar directamente definiendo un puntero con el valor de dicha dirección, ya que el sistema carece de unidad de manejo de memoria, por lo que no existen las direcciones virtuales, de forma que las direcciones que aparecen en el código C son direcciones físicas reales. En el caso de que el procesador Leon 2 hubiera sido implementado con una MMU, habría que utilizar la llamada al sistema mmap, que nos devolvería un puntero a una dirección de memoria virtual que, a ser traducida a dirección física por la MMU, daría la dirección del módulo hardware. Es este puntero el que se utilizaría para acceder al módulo hardware en 65

66 Aplicación de demostración 9.3 Parte software lectura y escritura. Es muy importante el uso adecuado del modificador volatile, que avisa al compilador de que el objeto concreto (variable o contenido del puntero) está sujeto a cambios por razones que no pueden ser predeterminadas por un estudio del programa en sí mismo, y fuerza a que todas las referencias al objeto sean referencias genuinas. Esto básicamente significa que el compilador C no realizará optimizaciones sobre el código que puedan afectar a la interacción con los periféricos HW, cuyos registros le indicamos al compilador que son volatile: por ejemplo, cierto registro de un periférico puede necesitar ser leído o escrito n veces seguidas para ser inicializado, y una optimización del compilador puede convertir esos n accesos en uno sólo. /* SW part of custom codesign applicatio */ /* Hipólito Guzmán Miranda */ /* Licensed under GNU LGPL */ #include <math.h> #include <stdlib.h> #define HW_REGISTER_ADDR 0x800000E0 int main(int argc,char **argv) { volatile unsigned int* addr_timer0 = (volatile unsigned int*) HW_REGISTER_ADDR; int max_value, min_value; int value_to_apb_register = 0; if (argc!= 3) { printf("\nusage: %s <value1> <value2>\n", argv[0]); printf("values must be between 0 and 255\n"); } else { if ( atoi(argv[1]) > atoi(argv[2])) { max_value = atoi(argv[1]); min_value = atoi(argv[2]); } else { max_value = atoi(argv[2]); min_value = atoi(argv[1]); } value_to_apb_register += min_value; value_to_apb_register += (max_value << 8); printf("initializing HW register with the value %i\n", value_to_apb_register); *addr_timer0 = value_to_apb_register; usleep( ); while (1) { usleep( ); printf("reading the value of the HW register\n"); printf("the HW register value is %i DEC, %X HEX\n",*addr_timer0, *addr_timer0); }; } return 0; } 66

67 Aplicación de demostración 9.3 Parte software Figura 9.2: Carga de Snapgear en la RAM de la XSV-800 utilizando grmon Figura 9.3: Aplicación de demostración en funcionamiento 67

68 Aplicación de demostración 9.3 Parte software Figura 9.4: Prototipo en funcionamiento. Fotografía 68