Implementación de un Servidor Web basado en la FPGA DE2-70 de Altera

T reba ll F ina l de G rau

AUTOMÀTICA

Implementación de un Servidor Web basado en la FPGA DE2-70 de Altera

JOSEPH STEVEN ROMO ARTIEDA

Tutors

Dr. Jaume Agapit Segura Fuster Dr. Salvador Barceló Adrover

Escola Politècnica Superior

Universitat de les Illes Balears

INDUSTRIAL I AUTOMÀTICA

Implementación de un Servidor Web basado en la FPGA DE2-70 de

Altera

JOSEPH STEVEN ROMO ARTIEDA

Tutors

Dr. Jaume Agapit Segura Fuster Dr. Salvador Barceló Adrover

Escola Politècnica Superior

Universitat de les Illes Balears

Palma, 24 de septiembre de 2018

oportunidad de trabajar en este proyecto. Gracias a mi familia y amigos sin los cuales esto no sería posible. Gracias a Diego, Pascual y Andreu por los consejos.

"Si te parece que me voy por las ramas, si te parece que divago, recuerda que las historias reales pocas veces toman el camino más recto. Patrick-Rothfuss

Índice general v

Índice de figuras vii

Acrónimos ix

Resumen xi

1 Introducción 1

1.1 Motivación del proyecto . . . 1

1.2 Objetivos . . . 2

1.3 Proyectos Previos . . . 3

1.4 Marco teórico . . . 5

2 Diseño e Implementación 11 2.1 Diseño Hardware . . . 12

2.1.1 Componentes . . . 12

2.1.2 Proceso de Diseño . . . 17

2.2 Diseño Software . . . 24

2.2.1 Componentes . . . 26

2.2.2 Proceso de Diseño . . . 28

3 Pruebas Realizadas y Dificultades Encontradas 39 3.1 Pruebas Realizadas . . . 40

3.2 Dificultades Encontradas. . . 42

3.2.1 Entornos Obsoletos . . . 42

3.2.2 Firmware incompleto . . . 43

3.2.3 Librería TCP/IP . . . 43

3.2.4 Sistema Operativo . . . 44

3.2.5 Software Web Server . . . 44

3.2.6 Flash programmer . . . 45

3.2.7 Configuración Hardware . . . 45

4 Conclusiones 47 4.1 Limitaciones . . . 48

4.2 Propuestas De Mejoras . . . 49

5 Bibliografía 51

A Anexo A 55 A.1 Schematic-DE2-70. . . 55 A.2 Datasheet DM9000A . . . 58

1.1 Esquema del sistema Servidor-Web sobre placa DE2-70 . . . 2

1.2 Placa DE2-70 de Terasic con FPGA cyclone II [5] . . . 4

1.3 Esquema de dispositivo FPGA . . . 5

1.4 Proceso de sintetización de una configuración HDL a BitStream. . . 6

1.5 Visualización del proceso de activación de conexiones lógicas . . . 6

1.6 Esquema del empaquetamiento dentro del protocolo de comunicación TCP/IP . . . 7

1.7 Esquema del protocolo de comunicación TCP/IP . . . 7

1.8 Esquema de la capa de abstranciónHardware . . . 8

2.1 Diagrama de flujo de diseño. . . 11

2.2 Diagrama de bloque del sistema sobre la placaDE2-70. . . . 12

2.3 Cyclone II, Segunda generación de FPGA de bajo coste de Altera. . . 13

2.4 Listados de componentes hardwaredel sistema enQsys. . . . 16

2.5 Nuevo Proyecto enProject Wizard del entornoQuartus II en la versión 13.0.sp1. . . 17

2.6 Selección del dispositivo DE2-70 en elProject WizarddeQuartus II en la versión 13.0.sp1. . . 18

2.7 Vista general de los componentes Hardware del sistema. . . 19

2.8 Vista general de la pantalla de configuración de unPLLdel sistema enQsys. 20 2.9 mapa de memoriadel sistema enQsys. . . . 20

2.10 Diagrama de bloque del sistemaNioscreado enQsys. . . . 21

2.11 Captura de los archivos del proyectoEPSU 0998creado en Quartus. . . 21

2.12 Vista general delPin Plannerdel sistema. . . 22

2.13 Resume of Systemdel proyecto tras la compilación y análisis. . . 23

2.14 Vista general delprogrammerde Quartus II para la programación de la FPGA. 24 2.15 Esquema de aplicación Nios II (Template).. . . 25

2.16 Logotipo del sistema operativoMicroC-Os IIdeMicrium. . . . 26

2.17 Logotipo de la MarcaInternichefabricante del Stack de protocolosNicheS- tack. . . . 27

2.18 Project Wizarddel Nios II SBT. Primera Parte.. . . 28

2.19 Project Wizarddel Nios II SBT. Segunda Parte. . . 29

2.20 Selección de paquetes en elEditor BSP . . . 30

2.21 Ajustes de posicionamiento en memoria del paqueteRO-ZIPFS. . . 31

2.22 Ajustes comunes del sistema en el editorBSP. . . . 31

2.23 captura del códigoWeb-server.hdonde se define unaIP estática. . . 32

2.24 Diagrama de los componentes software del sistema. . . 33

2.25 Mensaje de error del Servidor Web en caso de Archivo No-Encontrado . . . 34

2.26 Flash programmerdel SBT con la configuración propia de nuestro sistema. 35 2.27 Botón 0asociado aResetdel sistema. . . 36

2.28 Capturas de las páginas almacenadas en elServidor Web. Parte 1. . . . 37

2.29 Capturas de las páginas almacenadas en elServidor Web. Parte 2. . . . 38

3.1 Imagen de la placa al iniciar el ejemplo Dummy DM9000A.. . . 40

3.2 Captura del ejemplo MicroC en ejecución.. . . 41

IP Intellectual Property IP Internet Protocol

FPGA Field Programmable Gate Array SOPC System On a Programmable Chip OS Operative System

TCP/IP Transmission Control Protocol/Internet Protocol TCP Transmission Control Protocol

RTOS Real Time Operative System ZIP Zone Improvement Plan DE Development and Education HDL Hardware Description Language RISC Reduced Instruction Set Computer CPU Central Processing Unit

LAB Logic BLock Array LE Logic Element LUT Look Up Table

GPIO General Purpose Input/Output OSI Open System Interconnection LWIP Light Weight Internet Protocol HAL Hardware Abstraction Layer SBT Software Building Tools BSP Board Support Package PLL Phase-Locked Loops

LCD Lyquid Cristal Display MAC Medium Access Crontol ISR Interrupt Service Routine

ICMP Internet control message protocol DHCP Dynamic host configuration protocol UDP User datagram protocol

ARP Address Resolution Protocol HTML HyperText Markup Language HTTP Hypertext Transfer Protocol CSS Cascading Style Sheets

SRAM Static Random-Access Memory

SDRAM Synchronous Dynamic Random-Access Memory IDE Integrated Development Environment

SSRAM Synchronous Static Random-Access Memory CFI Common Flash (Memory) Interface

PCB Printed Circuit Board) LED Light-Emitting Diode TSE Triple Speed Ethernet RO-ZIPFS Read-Only Zip Files SED Sistemas Electrónicos Digitales

Los dispositivos FPGA llevan bastante años de existencia como resultado de la con- vergencia de tecnologías como la Programmable Logic Devices (PLD) y Application- Specific Integrated Circuit (ASIC) y dada la flexibilidad y las altas prestaciones se han hecho muy relevantes para sistemas de control en sistemas críticos.

Inicialmente eran poco apreciados debido a su programación poco amigable y a su entorno cerrado en referencia a otros fabricantes. Actualmente estos aspectos mejoran y se empieza a popularizar en entornos de automoción o aeronáutica.

Una de las aplicaciones en entornos de educación o en laboratorios científicos es el desarrollo de sistemas de control y adquisición de datos.

La adquisición y tratamiento de los datos en paralelo es una de las principales ventajas, sin embargo se requiere de un sistema de almacenamiento de datos y que sea capaz de controlar el proceso de adquisición y el tratamiento de datos de ser preciso. Para dar una solución a estos requisitos se presentan los Servidores Web como una propuesta enfocada en permitir el acceso remoto a una placaFPGAy cuyo acceso se puede realizar desde una plataforma muy estandarizada como puede ser un navegador web.

En concreto la placa empleada será la DE2-70 de Terásic, sobre la cual se implementará un servidor web que permita la interacción con la placa de manera remota dentro de una red local. Haciendo uso de una aplicación software desarrollada en lenguaje C y una configuraciónhardwaredesarrollada en lenguajes Verilog y VHDL podremos llevar a cabo la implementación del sistema.

C

1

I NTRODUCCIÓN

En este capítulo se explicarán los objetivos que se plantearon al comienzo del proyecto.

Haremos mención de proyectos que se han consultado para el desarrollo o la verifica- ción de nuestro trabajo y explicaremos conceptos que son necesarios recordar antes de empezar el desarrollo de esta memoria.

1.1 Motivación del proyecto

La principal motivación del proyecto es el interés personal en la tecnología de dispositi- vosFPGAy en la necesidad actual en los laboratorios de monitorizar la adquisición de datos en experimentos y cuya transmisión de información se realiza desde el sistema de control hacia el usuario final. Esta comunicación suele realizarse en muchos casos mediante conexiones punto a punto, lo que suele implicar un cableado excesivo, o en su defecto, la necesidad de una estación próxima al punto de adquisición de datos.

Para evitar tener un exceso de cableado al intentar llevar datos muy lejos de la zona de adquisición y permitir que la visualización de estos pueda realizarse sin la necesidad de desplazamientos a la zona de adquisición, se plantea la creación de una interfaz web que realice la interacción remota con la placa. Dada la potencia de las placasFPGA, para la realización de este proyecto se emplea laDE2-70deTerasic.

A la hora de implementar el servidor se tiene en cuenta la gestión de las llamadas a interrupción, por lo que los microprocesadores emplean habitualmente sistemas operativos que realizan esta gestión. En lasFPGAtambién existen sistemas operativos con una reducida huella en memoria y este es uno de los aspectos más atractivos que se busca trabajar dada la versatilidad que proporciona para una aplicación.

1.2 Objetivos

El principal objetivo es adquirir mejores destrezas en el ámbito de diseño e implementa- ción dehardwareysoftwaresobre dispositivosFPGA, profundizar en los conocimientos adquiridos en la asignatura Sistemas Electrónicos Digitales (SED) y llevar a cabo la implementación de una interfaz web basada en el microprocesadorNios II, que per- mita una comunicaciónethernetmediante el protocolo de comunicaciónTCP/IPy controlado por un sistema operativoRTOS.

La aplicación final de este proyecto es proporcionar un servidor web basado enFPGA bastante genérico que pueda ser utilizado en múltiples aplicaciones de laboratorio y en el ámbito educativo.

Figura 1.1: Esquema del sistema Servidor-Web sobre placa DE2-70

1.3 Proyectos Previos

La implementación de servidores web enFPGAno es nuevo. De hecho Altera propor- ciona como ejemplo un proyecto para la placaDE2-115(que es otro modelo de placa FPGAde la misma familia que laDE2-70) llamadoDE2-115 Web Server[1] en el que se puede probar el funcionamiento de la comunicaciónethernetsobre un controlador Triple Speed Ethernet (TSE) mediante protocoloTCP/IPy haciendo uso de páginas web almacenadas en un ficheroZIPsolo de lectura.

Otras universidades también han trabajado en la implementación de un servidor web sobre este modelo concreto deFPGA, ya que el ejemplo proporcionado por el fabricante no cumple con todos los requisitos del proyecto, pero aún así nos sirve como un punto de partida para llevar a cabo el desarrollo. Esto demuestra antes de empezar el proyecto, que este es factible y da un punto de referencia para comparar los resultados.

Un ejemplo claro es el trabajo:Implementation of Web-Server Using Altera DE2-70 FPGA Development Kit. Proyecto realizado enSOPC[2].

La universidad de Alberta, en 2014, llevó cabo la implementación de un servidor Web sobre la placaDE2en el proyectoAltera DE2: DM9000A Ethernet Controller Applica- tion Notes[3]. Donde se enfocan en el desarrollo de un firmware para el controlador DM9000A.

Uno de los proyectos de demostración que más se aproximan a nuestro objetivo y es proporcionado por el fabricante para la placa DE2-70 (Fig:1.2), es la demoDE2-70 Net, que ha sido tomado como punto de partida para el desarrollo de este proyecto. Su propósito es visualizar la transmisión/recepción de paquetes de datos en una comuni- cación en modoLoopBack. Por tanto, haciendo uso de los recursos de la placa, muestra que es posible la comunicaciónethernetsin protocolos de comunicación ni sistemas operativos haciendo uso únicamente de llamadas por interrupción.

Figura 1.2: Placa DE2-70 de Terasic con FPGA cyclone II [5]

1.4 Marco teórico

Antes de detallar el proceso de implementación se repasarán varios conceptos que se deben tener en cuenta a la hora de llevar a cabo este proyecto.

FPGA

Las FPGAs son dispositivos semiconductores que poseen bloques lógicos digitales conectados de manera que la interconexión sea configurable y programable porsoftwa- re. Así estos dispositivos permiten diseñar circuitos digitales a un nivel de abstracción hardwareque pueden ser reutilizados. El diseño de esta configuraciónhardwareestá definido mediante un lenguaje de descripciónhardwareHDL. Los lenguajes más habi- tuales sonVHDLyVerilog.

UnaFPGAde altera contiene un número de Logic BLock Array (LAB) dependiendo del modelo (Fig:1.3), cadaLABcontiene 16LE, cadaLEcontiene 4 Look Up Table (LUT).

UnLUTes una tabla de verdad electrónica que implementa una variedad de puertas lógicas.

Figura 1.3: Esquema de dispositivo FPGA

El proceso de configuración(Fig:1.4)hardwareparte de la definición en lenguaje HDLque se sintetiza en una cadena de bits llamado BitStream. Esta conversión la realiza el compilador del fabricante (ya que cada empresa lo sintetiza de una manera distinta) para finalmente generar una secuencia de bits que se vuelcan sobre la placa y habilitan o deshabilitan conexiones entre bloques según el valor del Bit.

Como resultado de esta síntesis, al volcar la configuraciónhardwaresobre laFPGA, se carga elBitstreampara que active o desactive las interconexiones que habilitan o deshabilitan las puertas lógicas (Fig:1.5). Esta configuración refleja a nivelhardwarelo que estaba descrito en los archivosVHDL/Verilogdel sistema .

Figura 1.4: Proceso de sintetización de una configuración HDL a BitStream

Figura 1.5: Visualización del proceso de activación de conexiones lógicas La principal característica de lasFPGAes la capacidad de reconfigurar el diseño hardwaredel proyecto empleando el lenguajesHDL. Destacan también por el procesa- miento de señales a nivel eléctrico, ya que permiten procesos totalmente en paralelo a velocidades relativamente altas alcanzando frecuencias de reloj superiores a otras tecnologías como los micro-controladoresArduino, donde algunos modelos ofrecen frecuencias de alrededor de 10 MHz.

Sistemas Encastrados

Los sistemas encastrados son sistemas diseñados para cubrir funciones específicas que integran sus componentes en la propia placa. Se pueden programar en lenguaje ensamblador o emplear un compilador preparado para soportar lenguajeC/C++. Sus principales ventajas son la ejecución de un programa de forma cíclica y la capacidad de realizar cálculos y operaciones en tiempo real.

Pila de Protocolos TCP/IP

Una pila de protocolos es un conjunto de protocolos organizados por capas y api- ladas una encima de otra proporcionando la información encapsulada entre capas adyacentes (Fig:1.6). Una pila de protocolosTCP/IP(Fig:1.7) está formada por los protocolos necesarios para este tipo de comunicación.

Se compone de cuatro capas:

• La capa Acceso a la Red, usualmente ligada con el nivel 1 y 2 del modeloOSI.

• La capa de internet, similar al nivel 3 del modeloOSI.

• La capa de transporte, similar al nivel 4 del modeloOSI.

• La capa de aplicación, equivalente al nivel 5,6 y 7 del modeloOSI.

Figura 1.6: Esquema del empaquetamiento dentro del protocolo de comunicación TCP/IP

Figura 1.7: Esquema del protocolo de comunicación TCP/IP

En lasFPGAs no es posible incluir amplias librerías de protocolos ya que la limitada memoria es compartida para albergar la aplicación software y los datos. Por este motivo se emplean las conocidas como Light Weight Internet Protocol (LWIP), que son pilas de protocolos que requieren pocos recursos. Al ser ligeras ofrecen menos herramientas, pero las suficientes para realizar una correcta comunicación.

Servidor Web

Un servidor web es un programa que mediante protocoloHTTPgestiona una aplicación desde el lado del servidor realizando conexiones bidireccionales y/o unidireccionales, síncronas o asíncronas. Se emplea para servir páginas web a los clientes que las solici- ten y cuyo código es compilado y ejecutado por el cliente mediante un navegador web desde el que cual se realiza la solicitud.

Board Support Package

Capasoftwareespecifica que contiene controladores para los elementoshardware del sistema y que incluye, además, los archivos necesarios para soportar un sistema operativos en caso de ser necesario. Puede incluir paquetes que actúan como código de apoyo para el sistema tales como librerías personalizadas o librerías de protocolos.

Hardware Abstraction Layer (HAL)

ElHAL(Fig:1.8) es un entorno encastrado y ligero que proporciona una interfaz entre la aplicación software y elhardwaredel sistema. Proporciona de este modo una plata- formahardwaresobre la que se ejecutan las aplicacionessoftware.

Permite que la aplicación sea independiente delhardwareya que abstrae la informa- ción del sistema, tal como el cache, buffers, registros y demás en un único formato.

Figura 1.8: Esquema de la capa de abstranciónHardware

En nuestro casoHALsirve como un paquete que almacena una abstracción dedrivers del dispositivo para el microprocesadorNios II. El entorno de desarrollo extrae infor- mación de nuestro sistema en el archivo.sopcinfoque es una completa descripción del sistema (Componentes y conexiones). AdicionalmenteNios IISoftware Building Tools (SBT) crea unHALpersonalizado y específico con la configuraciónhardwarey softwaredel sistema para nuestro Board Support Package (BSP).

HALpermite de esta forma, una clara distinción entre elsoftwarecreado para los drivers del dispositivos y elsoftwarede la aplicación. Esta abstracción permite que el código de la aplicación pueda ser independiente a modificaciones en la configuración hardwaredel sistema (ya que depende del archivo Sopcinfo) y permite ser consistente con la interacción con los periféricos y un sistema operativo, en caso de incluirlo.

Firmware

Es unsoftwareque permite establecer la lógica a bajo nivel que permite controlar los circuitos electrónicos de un dispositivo, actuando así como paso intermedio que comunicaHardwareysoftware. Se trata de un programa que controla un dispositivo hardwarea bajo nivel estableciendo la comunicación con los registros que lo gobiernan.

Se trata habitualmente de código que existe en la frontera entrehardwareysoftwareya que se encarga de facilitar el trabajo a aplicaciones de alto nivel a comunicarse con el hardwareque desean controlar.

System-on-chip

Es una plataforma que integra el procesador, la memoria y la red de interconexión en un solo chip, reduciendo la demanda de potencia necesaria. Habitualmente inte- gran procesadores de 32 bit.

On chip y Off-chip

Son referencias que indican si un controlador o dispositivos se encuentra en el Chip Integrado o si por el contrario es externo a este.

Real-Time Operative System

Un sistema operativo desarrollado para aplicaciones de tiempo real en donde se exige un tiempo de respuesta dentro de un rango establecido y en caso de no cumplir con esta restricción se considera un fallo del sistema. Para poder desempeñar esta tarea se requiere que el sistema sea predictivo. Es un sistema operativo que no requiere mucho espacio en memoria. Puede realizar una tarea como resultado de cualquier evento del soporte físico y siendo considerados multi-arquitectura ya que permiten su empleo en cualquier tipo deCPU.

C

2

D ^{ISEÑO E} I MPLEMENTACIÓN

El planteamiento inicial para el desarrollo del proyecto fue la realización de un servidor Web basándonos en el ejemploDE2-70 Nety sobre el cual realizamos las modificacio- nes necesarias. Lo mostrado a continuación es el proceso final mediante el cual se crea un proyecto desde cero. En el [Capítulo3] se presentaran las dificultades encontradas desde eseplanteamiento inicialhasta el proceso dediseño e implementaciónque se mostrará en este capítulo.

El diseño de configuraciónhardwarese ha realizado empleando la herramientaQsys[6]

y escrito en código Hardware Description Language (HDL) mediante lenguajes VHDL y Verilog en el entorno de Quartus II versión 13.0.sp1. El diseño software se realizó empleando NIOS II Software Building Tools (SBT) for eclipse (Eclipse Indigo) y escrito en lenguaje C. El protocolo de comunicaciónTCP/IPempleado se ha usado la pila de protocolosNichestackde la empresaInterNiche Technologies, Inc. El sistema operativo implementado sobre la placa es el MicroC-OSII de la empresaMicrium. La interfaz Web se realizó enHTMLversión 1.1 yCSS.

Los pasos en el diseño de un proyectoFPGAsuelen seguir la secuencia que se muestra en (Fig:2.1).

Figura 2.1: Diagrama de flujo de diseño.

2.1 Diseño Hardware

El desarrollo delDiseño Hardwareserá implementado sobre el entorno de desarrollo Quartus II versión 13.0.sp1, mientras que la configuración de componentes será elabo- rada enQsys(software incluido en Quartus II) con los componentes propios de altera e incluyendo módulos Intellectual Property (IP) de Altera considerados no estándar.

Las placas de la empresa Terasic con la denominación Development and Education (DE) suelen ser Kits de desarollo que són excelentes para aprendizaje y aplicaciones de entor- nos menos críticos. La placa DE2-70 de Terasic emplea unaFPGACyclone II de Altera, que es una familia deFPGAs de bajo coste y alto rendimiento.

Para que nuestro servidor funcione debemos asegurarnos que nuestro sistema sea considerado no-volátil, que incluya una pila de librerías que permitan el protocolo de comunicaciónTCP/IPy que gestione las solicitudes de manera eficiente con los limitados recursos que disponemos. Para considerar a nuestro sistema No-Volatil se consigue añadiendo unBridgeque nos permita establecer un camino lógico fijo entre controladores de dispositivos y no uno arbitrario como ocurriría por defecto en el Bus Avalon. A causa delBridgenecesitaremos un controladorTri-Stateque permita la configuración dedriversde dispositivos off-chip.

2.1.1 Componentes

Añadiremos los siguientes componentes a la configuraciónhardwaredesarrollada en Qsyspara nuestro sistema (Fig:2.2). Algunos componentes incluirán pequeñas explica- ciones para aclarar la razón por la cuál han sido añadidos o para dar más información acerca de sus características.

Figura 2.2: Diagrama de bloque del sistema sobre la placaDE2-70.

Características de la Cyclone II de Altera

Cyclone® II EP2C70F896C6(Fig:2.3) es un dispositivoFPGAfabricado con proce- so de90 nmusando material dieléctrico de tipoLow-k, es decir, de alta permitividad relativa cosa que permite reducir el valor de la capacidad parásita entre componentes que provoca diafonías.

Se trata de la segunda generación de la serie de bajo costecyclone. Posee un rango de Elementos LógicosLEs de 4.608 a 68.416 LEs, Memoria encastrada de 1.1 Mbits, De 13 a 150 multiplicadores encastrados y hasta 4 Phase-Locked Loops (PLL)s entre otras características.

Figura 2.3: Cyclone II, Segunda generación deFPGAde bajo coste de Altera.

BUS Avalon

Es un bus desarrollado por Altera como interfaz de comunicación con periféricos encastrados. Destaca debido al esquema de arbitrariedad de esclavos lo que permite la conexión de múltiples Maestros al bus. El bus tradicional de sistemas encastrados habitualmente sólo permite un Maestro por bus.

Primero incluimos dosTimerscuyos osciladores funcionan a una frecuencia distinta.

Escogemos untimerde 50 MHz para el sistema y otro de 25 MHz exclusivamente pa- ra el controladorethernetDM9000A siguiendo las indicaciones técnicas del controlador.

Controlador ethernet DM9000A [3]. Este módulo IP no está disponible en los paquetes estándar de Qsys, por lo que se extrae del proyecto DE2-70 Net [4] en cuya configuración se emplea. Se trata de un ControladorFast ethernet MACcompletamente integrado de bajo consumo. Incluye una interfaz de procesador general, una interfaz EEPROM, una unidad de control de acceso al medioMAC, un transceptor 10/100PHY y 16 kByte SRAM. El DM9000A soporta una interfaz de acceso a memoria interna de 8/16 bits. Ade- más, tiene un control de flujofull-dúplexy su función de autonegociación se configura automáticamente.

CPU Nios II processor versión Fast

Se trata de un procesador de propósito general diseñado en una arquitectura de sistema RISCde 32 bits. Esta arquitectura destaca por el reducido número de instrucciones de las cuales solo las de carga y almacenamiento acceden a memoria, también permite la segmentación y paralelismo en la ejecución de instrucciones. El procesador Nios II no se encuentra fijo en un núcleo de silicio por lo que puede ser incorporado en cualquier FPGAde Altera. La versiónFastofrece 4 Kbyte para la cache de instrucciones y 2 Kbyte para la caché de datos.

On-Chip Memory

Incluimos una memoria RAM para el sistema de 64 Kbyte, que es el tamaño máxi- mo disponible para nuestra versión deCPU.

GPIO

Los pines de entrada/salida de propósito generalGPIOse añaden al sistema para conec- tar dispositivos externos al chip como Leds, Switches, Botones y el display 7 segmentos, entre otros.

Synchronous Dynamic RAM

Añadimos doscontroladorespara poder incluir en el sistema dos módulosSDRAM.

Del mismo modo que todas las memorias, se selecciona la capacidad máxima disponi- ble para cada módulo en esta placa32 MByte.

System ID peripheral

Nos proporciona un mapeado de memoria de todos los esclavos del sistema, en este ca- so, los periféricos. Realiza una función similar al checksum cuando el nios II Integrated Development Environment (IDE) realiza la comprobación de los identificadores de componentes hardware y espera una confirmación del software antes de realizar la descarga de un programa para ejecutar.

Tri-State

Los componenteTri-State Conduitpermiten conectar controladores On-chip a dispo- sitivos Off-chip. De cada uno de los siguiente componentes Tri-State se incluye uno dedicado a la memoriaSSRAMde 2 Mbyte y otro alCFIde 8 Mbyte.

• Generic Tri-State ControllerIncluye los parámetros de control que necesitamos para el dispositivos off-chip como por ejemplo, el tamaño de memoria.

• Tri-State Conduit Pin-sharerpermite la arbitrariedad entre varios controladores tri-state. Conduce las señales propias del controlador que gestiona el dispositivo (Generic Tri-State controller) hacia el Tri-State conduit bridge asignado.

• Tri-State Conduit Bridge Realiza la conversión de la codificación on-chip de señales Tri-State en señales bidireccionales en laPCB

Figura 2.4: Listados de componentes hardwaredel sistema enQsys.

2.1.2 Proceso de Diseño

Todo el proceso de implementación de la configuración hardware será llevado a cabo sobre elIDEQuartus II en la versión 13.0.sp1y en el software de diseñoQsysque este entorno incluye. Una vez detallados los componentes que se incluyen, se realiza una descripción superficial del proceso de implementación del diseño escogido. Para esto mencionaremos los pasos a que se siguieron desde la creación del proyecto.

Dentro deQuartus II versión 13.0.sp1procedemos a crear un nuevo proyecto en el Project Wizard(Fig:2.5), al cual debemos asignar un nombre y seleccionar el dispo- sitivo sobre el cual trabajaremos. En nuestro caso la placaDE2-70lleva asociado el nombre dispositivo 2C70. Sin embargo se puede observar que existen variantes de este dispositivo por lo que podemos realizar el ejercicio de fijarse en las características lógicas asociadas a esta placa.

Figura 2.5: Nuevo Proyecto enProject Wizard del entornoQuartus IIen la versión 13.0.sp1.

De acuerdo con la FPGA montada en la placa DE2-70 se elige el dispositivo2C70F896C6 (Fig:2.6): que dispone de aproximadamente 70000LEs. Con esto se finaliza la creación de un proyecto vacío asociado al modelo de nuestra placa.

En este momento disponemos de un proyecto de Quartus vacío pero asociado al modelo de placa que emplearemos,a continuación abrimos el entorno Qsys y para la creación de una nueva configuración Hardware.

Figura 2.6: Selección del dispositivo DE2-70 en elProject WizarddeQuartus IIen la versión 13.0.sp1.

Para nuestro proyecto (Fig:2.7), los elementos que incluiremos ya se han listado en el [Apartado2.1.1]. Donde se han comentado aquellos más especiales para el siste- ma. Sin embargo, algo que no se mencionó anteriormente es que los elementos más destacados requieren de una configuración particular según las especificaciones del sistema, como los controladores de memorias, el componente PLL (Fig:2.8),etc. Estas configuraciones se realizan al añadir dicho componente dentro de Qsys y se realizan siguiendo dos factores.

• Disponer del espacio de memoria máximo disponible.

• Mantener las configuración de elementos del ejemploDE2-70 Net.

Una vez realizada la conexión de los componentes entre sí, establecido las direc- ciones de memoria enAddress Map(Fig:2.9) y establecido los identificadores de las interrupciones del sistema. Nuestro sistema Nios (Fig: 2.10) estará acabado yQsys generará los archivos.qipy.vhdldel proyecto (Fig:2.11). El archivoqipcontiene la información necesaria para que el quartus compile el procesador Nios II generado con el Qsys. Este archivo .qip deberá ser incluido entre los archivos del proyecto Quartus. El códigoVHDLgenerado por Qsys, al mismo tiempo que el archivo tipo qip describe los componentes del sistema y la conexión de señales entre componentes tal como se ha establecido dentro de Qsys. Por tanto, el archivo VHDL debe ser añadido al proyecto Quartus del mismo modo que el archivo qip.

Figura 2.7: Vista general de los componentes Hardware del sistema.

Figura 2.8: Vista general de la pantalla de configuración de unPLLdel sistema enQsys.

Figura 2.9: mapa de memoriadel sistema enQsys.

Figura 2.10: Diagrama de bloque del sistemaNioscreado enQsys.

Figura 2.11: Captura de los archivos del proyectoEPSU 0998creado en Quartus.

Procedemos a crear el archivo que hará la función deTop-Levelen lenguajeverilog.

Se ha escogido este lenguaje ya que partimos del ejemploDE2-70 NetcuyoTop-Level estaba escrito enVerilogy quisimos mantener la estructura de ese ejemplo en esta nueva configuración. Dado que la configuración actual es resultado de modificaciones del proyecto DE2-70 Net.

El haber empleado dos lenguajesHDLpara el proyecto no debe suponer un problema si se trata de archivos distintos. En nuestro caso tendremos el archivoTop-Levelescrito en verilog y el archivo de los componentes en VHDL.

El archivoTop-Levelse encargará de la declaración de las señales que nosotros consi- deraremos entradas y salidas del sistema. También incluiremos las señales que consi- deraremos necesarios para procesos intermedios dentro del sistema. Las señales de entrada y salida del sistema serán aquellas que se comunicarán con los pines físicos de la placa y cuya denominación será la que nosotros hayamos plasmado en elTop-Level.

Con esta denominación realizaremos la conexión de estas señales con las señales de los componentes que emplearemos y que previamente se han incluido en la configu- ración que creamos en Qsys. Una vez realizado elTop-Levelcontinuamos realizando elPin-Assignment(Fig:2.12). Se trata de la asignación de los pines de la placa a las señales descritas en elTop-Level. Con esto ya disponemos de lo necesario para realizar la compilación y análisisdel proyecto (Fig:2.13). Se puede comprobar que el sistema ocupa pocos recursos de los disponibles en la placa, esto es debido a que se ha previsto futuras aplicaciones del sistema y se ha buscado realizar las mínimas modificaciones a nivelhardware.

Figura 2.12: Vista general delPin Plannerdel sistema.

Figura 2.13: Resume of Systemdel proyecto tras la compilación y análisis.

2.2 Diseño Software

Para una mejor práctica es necesario realizar la descarga de la configuraciónhardware (.sof) (Fig:2.14) sobre la placa antes de proceder a la implementaciónsoftware.

Figura 2.14: Vista general delprogrammerde Quartus II para la programación de la FPGA.

Como hemos visto el problema de implementar un servidor web reside en dividir los recursos que posee la placa. Por una parte debe estar pensada para la adquisición de datos y un sistema de control, por otro debe poseer recursos suficientes para mantener el servidor. Esto conlleva un coste de recursos que debe ser contemplado.

En el caso de lasFPGAla capacidad de procesos en paralelo juega a su favor. Ne- cesitamos permitir que el proyecto software sea fácilmente mantenido y actualizado en un futuro por lo que opta por un diseño basado enHAL.

Para la gestión de la aplicación, el uso de un sistema operativo (OS) sería una solución válida que permita dirigir procesos en paralelo a nivel software como la adquisición de datos y la comunicación ethernet.

Por otro lado la transmisión de datos debe estar diseñada de tal forma que permita un control en tiempo real y qué mejor manera que un Real Time Operative System (RTOS).

Nios IISBTfor Eclipse, al tratarse de un entorno de trabajo proporcionado por el fabricante contiene proyectos llamadosTemplates(Fig:2.15). Formados por una aplicación software escrita en librerías c/c++ y una carpeta que incluye un conjunto de paquetesBSP. Estostemplatessirven como ejemplos de aplicaciones software para realizar pruebas del sistema y de los paquetes que están disponibles, como elOS.

Figura 2.15: Esquema de aplicación Nios II (Template).

Para este proyecto, seleccionaremos elTemplate Web Serverque contiene una aplicación que ejecuta un servidor web y su correspondiente BSP. Estetemplateejecuta la aplicación software diseñada como ejemplo para la placaDE2-115por lo que a continuación veremos como se realiza la correcta implementación de estetemplatey también observaremos que cambios serán necesarios para adaptarlo a la placaDE2-70.

2.2.1 Componentes

Sistema operativo de Micrium modelo microC-OS II

Es un sistema operativo en tiempo Real Kernel que permite una gran eficiencia y una reducida huella en memoria. Incluye una pila de protocolos muy completa co- mo TCP/IP, USB , Bus CAN y MODBUS. Dentro de TCP/IP da soporte a IPV4 e IPV6, ethernet, wifi y controladores PHY. Se trata de un sistema operativo portátil, escalable, apropiativo en tiempo real y que permite multitarea kernel que asegura la ejecución de la tarea con prioridad más alta.

MicroC/OS-II(Fig:2.16) proporciona gestión sobre:

• Tasks (threads)

• Event flags

• Message passing

• Memory management

• Semaphores

• Time management

El núcleo de Micro C-OS II trabaja sobre la plataforma HAL del BSP para el procesa- dor NIOS II permitiendo las siguientes ventajas:

Programa compatibles con otros sistemasHardwarede Nios II.

Programas persistentes a cambios sobre elHardware.

Programas con acceso a serviciosHAL.

UnaISRde facil implementación y manejo.

Figura 2.16: Logotipo del sistema operativoMicroC-Os IIdeMicrium.

Stack de protocolos

La pila de protocolosTCP/IPNichestackes una implementación de los protocolos con una reducida huella en memoria. Lo que permite reducir los recursos necesarios mientras se mantiene una pila de protocolos completamente funcional. Diseño especí- ficamente para sistemas encastrados es perfectamente válido para un sistema basado en Nios II.

NicheStack(Fig:2.17) es un paquete que puede ser añadido a nuestroBSPdel proyecto en caso de necesitar incluir alguna de sus funciones:

• Internet Protocol (IP), para comunicación de datos.

• Internet control message protocol (ICMP), para control de mensaje deinternet.

• User datagram protocol (UDP), para intercambios dedatagramasen la capa de transporte.

• Transmission Control Protocol (TCP), para el control de transmisión de datos.

• Dynamic host configuration protocol (DHCP), para la asignación automática de direccionesIP.

• Address Resolution Protocol (ARP), para la localización de una direcciónMAC asociada a una direcciónIP.

Figura 2.17: Logotipo de la MarcaInternichefabricante del Stack de protocolosNi- cheStack.

2.2.2 Proceso de Diseño

Eldiseño softwareempieza por crear un proyecto nuevo dentro de Nios IISBTfor Eclip- se. Este proyecto debe estar basado en una configuraciónhardwareya compilada y cargada sobre la placa Por lo que será necesario disponer del archivo.sopcinfodel diseñohardwarepara que elProject wizardde Nios IISBTreconozca cual es la configu- raciónhardwareque se va a emplear. De esta manera el compilador podrá establecer una lista de los componentes que serán empleados por elsoftwarey permite crear un paqueteHALdentro delBSP. El Board Support Package (BSP) es un conjunto de librerías especializadas para dar código de apoyo al sistema.

En elProject Wizard(Fig:2.18) delSBTdebemos seleccionar eltemplatepara la aplica- ción de servidor web. Asignaremos un nombre al proyecto y por defecto se asignará el mismo nombre con la terminaciónBSP(Fig:2.19) para el paquete de soporte de la placa de nuestro proyecto. Estetemplateestá diseñado originalmente para trabajar con la placa DE2-115 que posee un controlador ethernetTSEde altera. Al elegir este templatese cargan de manera automática los siguientes paquetes sobre elBSP:

• Stack de protocolos:NicheStack.

• Sistema Operativo: MicroC-OSII.

• Read-Only ZIP files:RO-ZIPFS.

Figura 2.18: Project Wizarddel Nios II SBT. Primera Parte.

Figura 2.19: Project Wizarddel Nios II SBT. Segunda Parte.

Entre otros archivos también se puede encontrar el system.h que es la declaración software de la configuraciónhardwareseleccionada escrito en lenguaje C. Se trata de una lista de cada dispositivoshardwareque incluye el proyecto con sus nombre, direc- ciones, interrupciones en caso de emplearlas y más información que habitualmente emplea la aplicación software para referirse a un dispositivohardware.

Como se trata de un proyecto creado para otra placa, es necesario realizar ciertos cambios que permitan adaptar su funcionamiento. Debemos asegurarnos que los peri- féricos necesarios están disponibles en nuestra configuraciónhardwarey actualizar la nomenclatura, ya que el nombre de los dispositivos presentes en system.h serán distin- tos a los que originalmente llevaba el proyecto.sopcinfopensado para este template.

Este cambio surge de la discordancia entre la denominación escogida en qsys para nuestro proyecto y la preestablecida en eltemplate.

El siguiente paso es realizar la sustitución del controladorethernet. Eltemplatese- leccionado emplea el controlador de la placa DE2-115, un controladorTSE. Nuestra placa DE2-70 funciona con elDM9000Ade la marcaDavicom.

En este punto podemos observar que elfirmwareproporcionado por el fabricante en la demostraciónDE2-70 Netno está capacitado para operar con sistemas operativos ni protocolosTCP/IPy por lo tanto, tampoco es compatible conNichestack. Tras una investigación en la comunidad de altera podemos encontrar quela Universidad de Albertarealizó, en 2014 [7] , la adaptación delfirmwarepara hacerlo compatible con Nichestacky poder emplearlo en la implementación de unservidor websobre la placa DE2que también emplea el controlador ethernet DM9000A.

En este momento es necesario establecer la configuración que nos parezca más ade- cuada para el proyecto en elEditor BSPy añadir o quitar paquetes(Fig:2.20). ·Añadimos el paquete de Read-Only Zip Files (RO-ZIPFS) para poder almacenar los archivos nece- sarios en la memoria flash, como són todas las páginas web que almacene el servidor, los archivos CSS y las imagenes que emplean. Mas adelante el servidor accederá a estos archivos para suministrar a los clientes una página web cuando se realice una solicitud al servidor.

La posición base de este paquete (Fig:2.21) será aquella, que en nuestro diseño hardwareasignamos a la memoriaflash. Eloffsetserá 0x100000 para nuestro proyecto, pero no importa siempre y cuando eloffsetdefinido coincida con el que se introduzca a la hora de la programación de la memoria flash.

Figura 2.21: Ajustes de posicionamiento en memoria del paqueteRO-ZIPFS Se añade el paquete para protocolos llamadoAltera-inichey dentro se realizan los siguiente cambios:

• Se elimina la opción de una configuración DHCP ya que se considera que es contraproducente para un servidor disponer de una IP dinámica. Más adelante se establecerá una IP estática.

• Debemos asegurarnos de habilitar el protocolo TCP y los fragmentos IP.

Dentro los ajustes comunes del proyectoBSP[2.22]asegurar que tenemos la selec- ción siguiente.

(a) Primera Parte.

(b) Segunda Parte.

Figura 2.22: Ajustes comunes del sistema en el editorBSP.

Una vez configurado, se debe regenerar el proyectoBSPpara incluir los cambios realizados.

Se procede a modificar las librerías del proyectoWeb Serverpara incluir:

• Modificar la detección de la direcciónMACde laFPGA.

• Una direcciónIPestática definida por nosotros y que puede ser modifica desde el código en el archivoweb-server.hal igual que la máscara de red y la delgateway.

• Se añaden librerías para el control de elementos comoLCDy el display7 segmen- tos.

• Se añaden las librerías delfirmware DM9000A.

Al tratarse de un servidor web planteado para un entorno de laboratorio, estará situado en unared localpor lo que aquellos que deseen acceder al servidor deben realizar un acceso mediante una IP que conozcan y no cambie, por lo que es necesario establecer una IP estática, una máscara de red y un gateway. Establecemos una IP está- tica (Fig:2.23) que está definida al inicio del archivo web-server.h . Se ha seleccionado esta opción para dar facilidad en caso de querer modificar la dirección pero obligando al usuario a modificar el software por lo que deberá estar seguro de querer realizar este cambio.

Figura 2.23: captura del códigoWeb-server.hdonde se define unaIP estática

Añadimos las librerías (Fig:2.24) .c y .h para el control de periféricos tales como LCDy 7 segmentos ya que al contrario que otros periféricos comoLEDs estos requieren un proceso de control un poco más complejo. Es posible incluir una libreríaLEDs para realizar funciones más visuales para el usuario pero de momento no se contempla.

• La libreríaLCDes obtenida del ejemploDE2-70 Nety solo ha sido necesario modificaciones mínimas para ajustar el funcionamiento a lo esperado por el proyecto.

• La librería7 Segmentoses obtenida del ejemploDE2-70 NETy no ha sido ne- cesario modificaciones más allá de la actualización de las definiciones de los componentes en el código.

• Para añadir la librería del controladorDM9000Aha sido necesario un proceso de investigación previo ya que no se disponía de unfirmwareoficial proporcionado por el fabricante del controlador, ni del fabricante de la placa. Se ha optado por el software deLa Universidad de Albertaya que se trata de un proyecto ya probado, que ha dado buenos resultados en la comunidad del foro de Altera y que los pro- pios miembros de la comunidad han recomendado. Su instalación en el proyecto Web Serverha consistido en añadir la librería y actualizar la denominación de los componentes.

Figura 2.24: Diagrama de los componentes software del sistema.

Programación flash

Este proceso se desarrolla en el entorno de nios IISBTfor eclipse dentro delflash programmer(Fig:2.26) propio del entorno.

Se crea una configuración nueva y se selecciona el proyectoBSPsobre el que esta- mos trabajando web-server-BSP. Se emplea el proyectoBSPdebido a que ya incluye la configuraciónhardwarey además la configuración del sistema para la aplicación software. Se selecciona la opciónerase before programmingde modo que se realice un borrado de lo almacenado en la memoria flash antes de realizar la programación.

A continuación, se selecciona el archivoZIP que deseemos almacenar. Cabe men- cionar que este archivo debe estar ubicado dentro del proyectoBSPy ser un archivo No-Comprimido. Se selecciona eloffset que previamente elegimos en eleditor BSP de modo que ambos concuerden. Realizamos la programación y nos aseguramos que se ha completado con éxito antes de cerrar el programador. En este punto podemos guardar la configuración de la programación flash para futuras modificaciones.

Una vez compilado el proyecto se realiza la ejecución de la aplicación. Se puede obser- var que en primera instancia muestra la identificación de la placa y la asignación de la dirección escogida. Un vez arrancada la tarea del servidor web estamos listos para realizar una solicitud desde un cliente a nuestro servidor.

Cuando se recibe la solicitud el servidor accede a su memoria flash para suminis- trar el archivo necesario en cada solicitud. En caso de no poder proporcionar el archivo deseado mostrará el mensaje de error asignado (Fig:2.25).

(a) Fetching file error.

(b) 404 Error.File Not Found.

Figura 2.25: Mensaje de error del Servidor Web en caso de Archivo No-Encontrado

Figura 2.26: Flash programmerdel SBT con la configuración propia de nuestro siste- ma.

Nuestro servidor web puede responder a solicitudesGetdel cliente, solicitando páginas web. o solicitudesPostdel cliente solicitando ejecutar una función sobre la placa.

Elmétodo getes necesario para poder mostrar las web almacenadas en la memoria flash, que de otra manera nunca serían visibles. Así establecemos una comunicación Servidor a Cliente ya que proporcionamos archivos desde la placa.

Elmétodo postes el que nos permite la ejecución de determinadas funciones desde la interfaz web y que son realizadas sobre la placa. Así establecemos una comunicación Cliente a Servidor. Son interesantes este tipo de solicitudes, ya que su aplicación es muy variada, desde conseguir que interactúe con la placa encendiendoLEDs o mostrando un mensaje sobre la pantallaLCDhasta conseguir iniciar una secuencia de adquisición de datos o de un sistema de control.

Comprobado el correcto funcionamiento del servidor web(Fig:2.28)(Fig:2.29) es posible cerrar el entorno de programación y tener el servidor funcionando de manera independiente a un terminal fijo.

Pulsando el botón 0 de la placa se realiza un reset global del sistema. (Fig:2.27).

Figura 2.27: Botón 0asociado aResetdel sistema.

(a) Home.

(b) Nios System.

Figura 2.28: Capturas de las páginas almacenadas en elServidor Web. Parte 1.

(a) Summary.

(b) Contact Us.

Figura 2.29: Capturas de las páginas almacenadas en elServidor Web. Parte 2.

C

3

P ^RUEBAS R EALIZADAS Y D IFICULTADES

E ^NCONTRADAS

El desarrollo mostrado en el [Capítulo2] es el resultado de un proceso de continuo avance frente a los problemas encontrados en el desarrollo desde el planteamiento ini- cial. En este capítulo realizaremos un análisis de los problemas que hemos encontrado, de como nos han afectado y de las soluciones que hemos propuesto para solucionarlos.

La redacción de este capítulo sigue la linea temporal en la que los problemas fue- ron detectados por lo que reflejan bien el proceso de cambio continuo que sufrió el proyecto.

3.1 Pruebas Realizadas

El banco de pruebas realizadas no ha sido planificado con antelación por lo que la ma- yoría de pruebas han surgido de la necesidad del momento, durante la comprobación del funcionamiento de un factor del sistema.

Dummy DM9000A

Se realizó la prueba del ejemploDE2-70 Net(Fig:3.1) ya migrado a Qsys para constatar que la migración había sido correcta y la transmisión de paquetes víaethernetse eje- cutaba con normalidad. El resultado fue correcto y nos proporcionó una idea clara de cómo debía interactuar elfirmwaredel controladorethernetcon las libreríasTCP/IP para nuestro proyecto.

Figura 3.1: Imagen de la placa al iniciar el ejemplo Dummy DM9000A.

DE2-70 MicroC

Proyecto híbrido que es resultado de implementar el sistema operativoMicroC-OS II sobre nuestro proyecto migradoDE2-70 Net(Fig:3.2). Permite la transmisión y recep- ción de paquetes víaethernetsin protocolosTCP/IPpero con el añadido de realizar las transmisiones en procesos del sistema en paralelo.

El resultado mostró la potencia de incluir un sistema operativo al sistema, aspecto que inicialmente parecía un trabajo demasiado complejo pero cuyas ventajas favorecen su uso.

Figura 3.2: Captura del ejemplo MicroC en ejecución.

Web Server Sobre Hardware Migrado de DE2-70 Net

La implementación delTemplate Web Serversobre la configuraciónhardwarefue una prueba para la aplicaciónsoftware, ya que se quería probar si la modificación realizada era compatible con una configuración que ya había sido probada en los ejemplos ante- riores. El motivo principal de realizar esta prueba antes de la creación de una nueva configuraciónhardwarefue la de reducir posibles errores en cada parte del proyecto.

El resultado de la prueba fue un servidor que permite la visualización de las páginas web almacenadas en la memoria flash y la interacción con la placa de manera remota.

EPSU 0998 Web Server

Tras la nueva configuraciónhardwarese volvió a probar el servidor y se comprobó su correcto funcionamiento. Se probaron las funciones de interacción con la placa como el control deLEDs, mensaje deLCDy display de7 segmentos, permitiendo observar el control remoto de la placa. Se probó el acceso al servidor desde dispositivos móviles y desde ordenadores de sobremesa, por separado y de manera simultánea. Observando su correcto funcionamiento en ambas opciones si bien con velocidades de transmisión relativamente bajas, obteniendopingsdel sistema del orden dems.

3.2 Dificultades Encontradas

Inicialmente pensamos emplear el ejemploDE2-70 Netcomo punto de partida para realizar las modificaciones necesarias sobre este ejemplo con el fin de adaptarlo a la función de servidor web. Este ejemplo no posee librerías de protocolosTCP/IP, sistema operativo ni el almacenamiento de archivos sobre la memoria flash. Consideramos al inicio del proyecto que añadir un sistema operativo debía resultar complicado por lo que de primera instancia fue algo que se dejo en segundo plano. Con respecto a las librerías TCP/IP tras la fase de investigación nuestro planteamiento inicial fue modificar las funciones del controlador o emplear librerías de código abierto para evitar trabajar con lincencias de desarrollo.

3.2.1 Entornos Obsoletos

Se comprobó que el proyecto del ejemplo fue creado en el entorno de diseñohardware SOPCy que la versión 13.0.sp1 del software Quartus II [9] que se posee en la Universi- dad de las Islas Baleares ya no dispone del editorSOPC, ya que se considera obsoleto por el fabricante. Este problema implicaba que no era posible ninguna modificación hardware sobre el sistema por lo que consideramos necesario realizar una migración del entornoSOPCaQSYS, un nuevo entorno de diseñohardware. La migración del sistema a un entorno más actual no resulto complicada en exceso ya que ambos son propiedad del fabricante Altera pero el no haber contemplado una migración en el planteamiento resulto en una semana de investigación y otra semana de implementa- ción para llevarla a cabo.

La migración del proyecto se realizó siguiendo las adaptaciones de componentes mencionados en los manuales de altera para la migración de proyectos [10] [11] y con la ayuda del asistente deqsyspara la actualización automática de componentes de los cuales existan nuevas versiones.

Dentro de la configuración en Qsys no ha sido necesario cambios muy grandes pero a la hora de generar códigoHDLen verilog y vhdl, si se requiere de adaptación para solucionar errores que genera qsys durante una migración, y que se comentan y solucionan en la wikipedia de altera [8].

En este punto el proyectoDE2-70 Netya migrado, emplea todos los periféricos y recursos disponibles en la placa. Este proyecto sobre dimensionado a nivelhardware se sustituirá más adelante ya que desde nuestro criterio, con la migración realizada damos prioridad a las modificaciones delsoftware.

3.2.2 Firmware incompleto

Tras realizar pruebas sobre el proyecto migradoDE2-70 Netse puede observar que el firmwaredel controlador ethernetDM9000Aproporcionado en el ejemplo solo con- templa las transmisiones y recepciones activados por interrupción de paquetes vía ethernet (sin emplear protocolos de comunicación).

La modificación delfirmwaresupondría la implementación de funciones nuevas y necesarias para soportar una libreríaTCP/IP. Al no disponer de unfirmwareapto para nuestro proyecto ni de conocimientos previos en el desarrollo de uno, se procede a una nueva fase de investigación y por consejo de la comunidad del foro de Altera procedemos a leer el trabajo de la universidad de Alberta sobre este controlador [7].

Elfirmwareque desarrollan es compatible con una libreríaTCP/IP,Nichestack.

3.2.3 Librería TCP/IP

Consideramos la posibilidad de crear una librería de protocolosTCP/IPteniendo en cuenta la definición de Light Weight Internet Protocol (LWIP), sin embargo conside- ramos que la carga de trabajo es excesiva para desarrollar una librería de cero y por lo tanto se busca una librería ya creada. Fabricantes comoInterNicheyMicriumpro- porcionan libreríasLWIPpero bajo licencia. Motivo por el cual se estudió emplear una librería de código abierto comoLwIP.LwIPes un proyecto de protocoloTCP/IPde reducida huella en memoria desarrollado inicalmente porAdam Dunkels. Finalmente esta opción quedó descartada al observar que la codificación delfirmwaredebería mo- dificarse y consideramos como un proyecto independiente la creación de unfirmware adaptado a librerías de código libre.

El motivo de descartar la opción de librerías de código abierto es que cada librería debe estar adaptada a laFPGAy al controladorethernet que está emplea. Dar con una librería preparada para trabajar conNios IIno resultó difícil pero desarrollar un firmwareespecífico que sea apto paraLwIPy compatible con elDM9000-Asuponía un trabajo extra que por falta de tiempo no consideramos adecuado. Mencionar también que en este tipo de librerías se recomienda el uso de sistemas operativos y en caso de no querer emplear el proyecto debería ejecutarse en un bucle infinito y gestionado mediante interrupciones.

La opción deMicriumMicroC-TCP/IP[12] fue descartada debido a que considera- mos más fiable el empleo delfirmwarede la universidad de Alberta sobre una librería ya probada como laNichestackde la empresaInterNiche. También mencionar que las personas de la comunidad del Foro de Altera recomendaron su uso debido a su fácil instalación sobre nuestro proyecto. OriginalmenteInternicheOfrecía soporte en Nichestacka los usuarios de Altera pero este acuerdo ya quedo cancelado, por lo que no disponemos de versiones actualizadas de esta librería más allá delTemplate de demostración.

3.2.4 Sistema Operativo

Al optar por librerías bajo licencia de los fabricantes ya mencionados, encontramos la necesidad de emplear un sistema operativo al igual que con la libreríaLwIP. Algo que inicialmente había sido descartado.

Estas librerías ya han sido probadas y en el caso de microC-TCP/IP posee un soporte técnico detrás en caso de necesitar ayuda. En el caso de micrium propone emplear su sistema operativo microC-OS II [13].

Podemos encontrar distintos sistemas operativos disponibles para sistemas encas- trados. Sistemas operativos de código abierto comoFreeRTOSe Incluso basados en Linux, pero finalmente los descartamos debido a la falta de conocimiento en estos entornos. Nosotros optamos por elMicroC-OS IIdebido a que el personal deMicrium nos proporcionó una licencia gratuita para desarrolladores particulares que permite su uso, soporte técnico y cuya validez es de 1 año. Este hecho sumado a que su implemen- tación ya estaba prevista entemplatesde demostración en el Nios IISBT, fue el factor decisivo para optar por este sistema operativo.

3.2.5 Software Web Server

Es necesario replantearse el uso del software del ejemploDE2-70 Netpara el desarrollo de este proyecto ya que carece de todos los elementos requeridos para un servidor.

Consideramos necesario buscar una alternativa para la aplicaciónsoftwarey se propuso eltemplate Web Serverdiseñado originalmente paraDE2-115y realizar la adaptación sobre elsoftwareen elNios II SBTfor eclipse. En este punto, el sistema estaría com- puesto por la configuraciónhardwareya migrada del propio del ejemploDE2-70 Net y una aplicaciónsoftwareobtenida delTemplatepara las placaDE2-115que ha sido modificado.

A continuación incluimos el Sistema operativo, las libreríasTCP/IPy la aplicación del servidor web. Todo con sus correspondientes modificaciones.

3.2.6 Flash programmer

A pesar de ser un punto de complejidad reducida, la falta de información al respecto, dio como resultado problemas en la visualización del servidor web debido a que la programación flash no se había ejecutado correctamente. Como consecuencia, las solicitudes de los clientes no podían ser respondidas ya que no se encontraban los archivos que en un principio debía estar almacenados en la memoria flash. Tras la revisión de los manuales de altera Architecture Desing [14] y Flash Programmer user guide [15], se pudo establecer el procedimiento básico que necesitaba elnios IISBT para realizar la programación correctamente.

3.2.7 Configuración Hardware

En el momento de obtener una aplicación funcional pudimos ocuparnos de otro pro- blema que habíamos dejado aparcado.

Para resolver el sobredimensionado fue necesario generar una configuraciónhardware nueva. Establecimos una lista de componentes que se puede observar en el [Aparta- do2.1.1] y cuyos componentes son necesarios para que el servidor pueda funcionar.

También se puede ver que incluimos algunos que no son necesarios pero permiten realizar pruebas sobre el sistema, como es el caso de losLEDs o los displays7 segmentos.

Como en el desarrolloHardwaredel [Capítulo2], ya se comentó la lista de compo- nentes que se incluyen en el proyecto. Solo cabe mencionar que por seguridad y tener un cierto margen de recursos establecimos el procesador y memorias de la placa a su dimensionado máximo, de manera que en caso de modificaciones futuras del servidor solo sea necesario realizarlas sobre el software hasta cierto punto.

En este momento ya disponemos de un diseñohardwarepropio que sólo implemen- ta los periféricos que se están previstos emplear. Se dispone también de un diseño softwareprocedente de unTemplateque ha sido modificado para nuestro objetivo.

C

4

C ONCLUSIONES

En este capítulo se repasa el proyecto para analizar los aspectos mas notorios referentes al cumplimiento de los objetivos, el desarrollo del trabajo y las etapas que hemos realizado.

• El proceso de elaboración de este trabajo empezó con la fase de investigación donde se procedió a la lectura de varios manuales relacionados con la placa y los componentes, para entender mejor el funcionamiento de la placa sobre la cual trabajaríamos. Se investigó también la historia de los servidores web y se busco información en libros y proyectos de otras universidades sobre la imple- mentación de servidores web enFPGA. En esta fase, se decide partir del ejemplo DE2-70 Net y realizar la migración a Qsys. Se prepara la lista de componentes que más adelante servirán para una nueva configuración del sistema. Todo este proceso de decisión inicial ocupa cerca de mes y medio.

• El proceso de desarrollo del proyecto se dividió en varias fases como ya vimos en el [Apartado3.2] y se pudo comprobar que aspectos que inicialmente se descar- taron como el uso de un sistema operativo o la implementación de una librería de código abierto acabaron siendo sustituidas a medida que los proyectos iban avanzando y era mas visible la carga de trabajo que conlleva. En esta fase del desarrollo encontramos bastantes problemas ya descritos pero el mas impor- tante puede ser la carencia de unfirmwarepara el controladorDM9000A. Este problema nos mostró en gran detalle el desarrollo de software para dispositivos electrónicos y en especial como debería interactuar este controlador con la libre- ría.

Esta fase fue la más larga y ocupó aproximadamente 6 meses desde su inicio has- ta el punto de cumplir nuestro objetivo de tener un servidor web funcional sobre una configuraciónhardwarede la placa DE2-70, haciendo uso de un sistema operativo y las librerías de protocolos.

• El proceso de verificación o fase de pruebas es co-dependiente de la fase de desarrollo ya que en este proyecto cada fase se probó por separa tal y como se menciona en el [Apartado3.1]. Dado que cada fase de desarrollo tuvo su fase de pruebas correspondiente es complicado indicar un periodo de tiempo concreto pero podemos intuir que al menos un mes de los 6 que llevo la fase de desarrollo ha sido dedicado a la prueba de las distintas partes del proyecto.

El resultado del proyecto es un servidor web implementado sobre una placaFPGA funcional y que permite la interacción con la placa de manera remota. Con esto pode- mos asumir cumplidos los objetivos planteado. sin embargo aún cabe mencionar las limitaciones y los aspectos a mejorar del proyecto.

4.1 Limitaciones

Podemos distinguir varios puntos que suponen una limitación para el sistema.

• La primera y más destacable es la carencia de una base de datos que pueda permitir a la placa el almacenamiento de datos recogidos por los periféricos.

• Otra limitación es la falta de soporte de lenguajePHP, cosa que limita mucho ciertas aplicaciones sobre la interfaz web.

• A pesar de que los ArchivosRead-only Zip filesposeen soportejavascript, es- ta funcionalidad no ha sido explotada en este proyecto cosa que supone otra limitación de la interfaz web.

• La necesidad de modificar el código de la aplicación para cambiar la dirección de red IP estática que se le asignó a la placa.

• Otra limitación que no afecta a su funcionalidad es la carencia de un sistema de seguridad

• El sistema no contempla conexión víaWi-Fidebido a la carencia de un módulo de red inalambrica en la placa.

4.2 Propuestas De Mejoras

Este proyecto puede tener multitud de aplicaciones en el entorno educativo y en labo- ratorio. Desde interactuar con las placa o instrumentos de manera remota, hasta ser un sistema de control y adquisición de datos en algún laboratorio. La gran adaptación del proyecto permite estudiar varios puntos de mejora para una futura continuación del proyecto.

• La adaptación del proyecto a un sistema operativo en baseLinux.

• La adaptación delfirmwaredel controladorDM9000Apara ser empleado sobre una libreríaTCP/IPde código abierto.

• Estudiar la posibilidad de la actualización del sistema operativoMicroC-OS IIa la versiónMicroC-OS IIIdeMicrium

• Estudiar la posibilidad del almacenamiento de datos sobre una memoriaSD.

• Implementación de un sistema operativo de código abierto.

• Implementación de un sistema de seguridad de acceso a la placa.

C

5

B IBLIOGRAFÍA

ftp://​ftp.altera.com/up/pub/Altera_Material/Boards/DE2-115/DE2_115_User_Manual.p df

[2] “Implementation of Web-Server Using Altera DE2-70 FPGA Development Kit. BTech thesis” - Sharma, Sahil and Pal, Anupam

National Institue of Technology of Rourkela, (2010)

[3] “DM9000A Ethernet Controller with General Processor Interface ” - Davicom

http://www.cs.columbia.edu/~sedwards/classes/2008/4840/Davicom-DM9000A-Ether net-controller.pdf

[4] “DE2-70 User Guide” - Altera And Terasic

https://www.terasic.com.tw/attachment/archive/226/DE2_70_User_manual_v105.pdf

[5] “DE2-70” - Terasic

https://www.terasic.com.tw/cgi-bin/page/archive.pl?No=226

[6] “Qsys System Design Tutorial” - Altera

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/tt/tt_qsys _intro.pdf

[7] “Altera DE2: DM9000A Ethernet Controller Application Notes” - Brent Erickson, Mavis Chan, Sydney Bitner (2014)

https://sites.ualberta.ca/~delliott/ece492/appnotes/2014w/G9_ETHERNET/G9_DM90 00_Ethernet.pdf

[8] “Intel FPGA Wiki” - Intel community

https://fpgawiki.intel.com/wiki/Intel_FPGA_Wiki

[9] “Introduction to Quartus II Manual” - Altera 

{​http://www.cin.ufpe.br/~if675/arquivos/referencias/manuais/intro_to_quartus2.pdf​} 

[10] Documentación migración 1

“an748” - Altera

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an74 8.pdf

[11] Documentación migración 2

“SOPc builder to Qsys migration Guidelines AN 632” - Altera

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an63 2.pdf