PROYECTO FIN DE CARRERA

Presentado a

LA UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y
ELECTRÓNICA

Para obtener el título de

INGENIERO ELECTRÓNICO
por

Franz Kevin Luepke Prieto

Una implementación de HPS y FPGA para rover de exploración

marciana

Sustentado el 9 de Julio de 2021 frente al jurado:

Composición del jurado

- Asesor: Fredy Segura, Profesor Asociado, Universidad de Los Andes.

- Coasesores: Josnelihurt Rodríguez, Software Architect, Globant.
Fernando A. Escobar, Leading Hardware Design Engineer, Imagination Technologies.
Nicolás Rocha, Estudiante maestría Ingeniería Electrónica, Universidad de Los Andes.
- Jurados: Mauricio Guerrero, Coordinador Académico Electrónica, Universidad de Los Andes.
Contenido
1. AGRADECIMIENTOS 4

2. INTRODUCCIÓN 5
2.1. Lista de acrónimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. OBJETIVOS 7
3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Alcance y productos finales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRA-

BAJO 8
4.1. Identificación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Contextualización del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Delimitación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Justificación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5. MARCO TEÓRICO, CONCEPTUAL E HISTÓRICO 10

5.1. Marco Teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. DE0 Nano SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Componentes de propiedad intelectual (IP Components) . . . . . . . . . . . 12
5.1.3. Interfaces estándar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.4. Kernel de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Codiseño hardware-software . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Proceso de arranque (Boot flow) . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Marco Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3.1. Trabajos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6. DEFINICION Y ESPECIFICACION DEL TRABAJO 14

6.1. Definición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.1. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Parámetros relevantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7. METODOLOGÍA DEL TRABAJO 16

7.1. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Búsqueda de información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Alternativas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3.1. Modificar los módulos de hardware . . . . . . . . . . . . . . . . . . . . . . . 17

1
8. TRABAJO REALIZADO 17
8.1. Descripción del Resultado Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.1. Investigación y contextualización . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.2. Revisión de módulos hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1.3. Configuración de ambiente de programación . . . . . . . . . . . . . . . . . . 19
8.1.4. Configuración de board de desarrollo . . . . . . . . . . . . . . . . . . . . . . 19
8.1.5. Generación de mapa de memoria . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1.6. Selección de protocolo de comunicaciones . . . . . . . . . . . . . . . . . . . . 20
8.2. Generación de drivers de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.3. Trabajo computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

9. VALIDACIÓN DEL TRABAJO 22

9.1. Metodología de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1.1. Pruebas de medición con osciloscopio . . . . . . . . . . . . . . . . . . . . . . 22
9.1.2. Pruebas de comunicación con ROS . . . . . . . . . . . . . . . . . . . . . . . 23
9.1.3. Banco de pruebas con motor DC . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1.4. Pruebas con joystick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1.5. Pruebas con interfaz web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Validación de los resultados del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3. Evaluación del plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

10.DISCUSIÓN 25
10.1. Desempeño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.3. Problemas encontrados y cómo pueden o fueron resueltos . . . . . . . . . . . . . . . 26
10.4. Trabajo que falta por ser realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.5. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

11.CONCLUSIONES 28

12.APÉNDICE 30

2
Índice de figuras
1. Prototipo de rover de exploración marciana de Robocol en el European Rover Cha-
llenge (ERC) 2019. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Tarjeta embebida DE0 Nano SoC. [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Diagrama de Cyclone V. Se diferencia las secciones de FPGA y HPS (partida por
la mitad de manera demostrativa) junto con la conexión de sus componentes a una
de estas 2 secciones. (Altera, 2015) [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. BootFlow. [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Diagrama de bloques de conexión entre SoC Cyclone V y equipo host. . . . . . . . . 18
6. Diagrama de bloques de conexión entre SoC Cyclone V y equipo host. . . . . . . . . 18
7. Mapa de memoria para módulos de hardware. . . . . . . . . . . . . . . . . . . . . . 20
8. Tabla comparativa de diferentes protocolos de red. . . . . . . . . . . . . . . . . . . . 20
9. Pruebas de PWM con osciloscopio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Pruebas de comunicación de ROS entre un host y la tarjeta DE0 Nano SoC. . . . . 23
11. Pruebas de comunicación de ROS entre un equipo host y la tarjeta de desarrollo
DE0 Nano SoC. La señal PWM de color azul es para la derecha y la de color amarillo
para la izquierda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Pruebas de página web conectada a tópicos de ROS. . . . . . . . . . . . . . . . . . . 24
13. Diagrama UML de funciones de alto nivel para parametrización y lectura de los
módulos de hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Índice de cuadros
1. Lista de acrónimos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Características principales de secciones de FPGA y HPS en SoC Cyclone V. [1] . . . 11
3. Comparación de variables de desempeño entre el estado inicial y el mínimo deseado. 15
4. Herramientas configuradas para funcionar como compiladores cruzados. . . . . . . . 21
5. Comparación de variables de desempeño entre el estado inicial y el mínimo deseado. 25

3
1. AGRADECIMIENTOS

Agradezco mi asesor Fredy Segura por todo su apoyo, dirección y conocimiento, a mi coasesor
principal Josnelihurt Rodríguez por su dedicación, paciencia y grandes enseñanzas, a mis coasesores
Fernando Escobar y Nicolás Rocha por sus consejos, retroalimentación y ayuda en la mejora de este
proyecto. Al equipo Robocol por ser el principal responsable de haber escogido este tema, y por la
formación complementaria que pude obtener reafirmando lo aprendido en mis materías del pregrado
en la universidad. A mis padre Francisco Luepke, mi madre Azucena Prieto y mi novia Natalia
López por su gran soporte, por escucharme tantas veces al hablar de este proyecto, interesarse en
conocer más al respecto y darme retroalimentación acerca de mis avances, así como por escucharme
en mis momentos de angustia por el proyecto. A mis amigos y compañeros de carrera y del equipo
Robocol Eloy Briceño, Jhoan León, Sebastián Sierra y Jorge Gaviria por aconsejarme acerca del
proyecto a nivel técnico, asistir a mis reuniones de preparación de la sustentación y aconsejarme
de la mejor manera para la mejoría de la misma. A Oscar Díaz por su gran labor en el equipo
Robocol y por ser de manera indirecta el impulsor de este proyecto ya que sus códigos fueron un
gran punto de partida para este proyecto.

4
2. INTRODUCCIÓN

Desde la creación de los primeros ordenadores se ha venido buscando con los avances de la
tecnología la mejor interacción posible entre los dispositivos electrónicos físicos y los códigos reali-
zados. Esta búsqueda por la mejor experiencia de usuario de una manera cómoda, veloz y eficiente
es en lo que el codiseño de hardware-software se centra. Buscando aprovechar al máximo las ven-
tajas de los componentes físicos junto con las utilidades del software. "Gartner (Gartner, 2000)
vaticina que en el 2004 la mayor parte de los diseños electrónicos digitales necesitarán de una fase
previa, en la que serán descritos usando un lenguaje de alto nivel (HLL, High Level Language)."[4]

Este proyecto aborda una metodología específica de codiseño para el circuito integrado Cyclone
V, el cual tiene capacidades para configurar hardware por medio de la sintetización en FPGA, al
igual que cuenta con un procesador de dos núcleos. Estos dos sistemas se encuentran embebidos en
el mismo silicio por me dio de la tecnología SoC (System on Chip). Adicional a esto, el integrado
cuenta con periféricos y buses de datos para lograr una conexión muy estable y veloz entre ambas
secciones principales, además de dar la capacidad del uso de distintos protocolos de comunicación.

Para demostrar los conceptos y la efectividad de la metodología se tiene el caso de estudio del
prototipo de rover de exploración marciana del grupo Robocol de la Universidad de los Andes. Este
grupo tiene una trayectoria de 10 años trabajando en proyectos de robótica y la participación en
varios concursos, especialmente en el área de robótica espacial, en los cuales ha realizado prototipos
de robots lunares y marcianos, representando a la universidad, el país y a recibiendo premios a
lo largo de su recorrido. [17] Para este proyecto se parte de una configuración en hardware inicial
sintetizada en FPGA [16], permitiendo que este proyecto se pueda concentrar de manera especial
en lo que respecta a la conexión del hardware al software y las aplicaciones a nivel de usuario y
kernel para el desarrollo en software, teniendo que hacer algunas modificaciones al hardware para
llevar a cabo la cadena completa de conexión.

5
2.1. Lista de acrónimos

Acrónimo Significado
ADC Analog-to-Digital Conversion
AMBA Advanced Microcontroller Bus Architecture
ARM Advanced RISC Machine
Avalon-MM Avalon Memory-Mapped
Avalon-ST Avalon Streaming Interface
AXI Advanced eXtensible Interace
CAN Controller Area Network
CD Compact Disc
CPR Counts Per Revolution
DC Direct Current
DDR3 Double Data Rate type three
DDS Data Distribution Service
FPGA Field Programmable Gate Array
GPIO General Purpose Input/Output
HDL Hardware Description Language
HPS Hard Processor System
I2C Inter Integrated Circuits
IP Intellectual Property
JTAG Joint Test Action Group
LED Light Emitting Diode
MQTT Message Queuing Telemetry Transport
OPC OLE for Process Control
OTG On-The-Go
PHY PHYsical layer
PID Proportional–Integral–Derivative
PKI Public Key Infrastructure
RAM Random Access Memory
ROS Robot Operating System
RPC Remote Procedure Call
RPM Revolutions per minute
SD Secure Digital
SHM Shared Memory Extension
OS Operating System
SoC System on Chip
SPI Serial Peripheral Interface
TCP Transmission Control Protocol
UART Asynchronous Receiver-Transmitter
UDP User Datagram Protocol
USB Universal Serial Bus

Tabla 1. Lista de acrónimos.

6
3. OBJETIVOS
3.1. Objetivo General
El objetivo del trabajo está enfocado en añadir mayores funcionalidades, versatilidad y facilidad
de cambios de parámetros por medio de software al rover de Robocol que se encuentra programado
completamente en módulos de hardware. Esto se logrará haciendo uso del HPS (Hard Processor
System) existente en la tarjeta DE0 Nano SoC, el cual se compone de un procesador Dual-Core
ARM Cortex-A9 que está conectado por medio una serie de buses paralelos de muy alta velocidad
internamente con la FPGA.

3.2. Objetivos Específicos

Proponer una metodología de trabajo para el flujo de diseño híbrido hardware/software en
la tarjeta de desarrollo embebido DE0 Nano SoC.

Establecer comunicación entre los módulos hardware de la FPGA y el procesador embebido

HPS para realizar múltiples tareas de manera simultánea con instrucciones de alto nivel.

Hacer un cambio en el paradigma de programación actual del rover de Robocol, el cual

permite tener nuevas funcionalidades y más accesibilidad.

Seleccionar adecuadamente la capa de transporte de datos que será usada en la tarjeta de

desarrollo para el rover, independizando su uso y configuración de la tarjeta Jetson TX2.

3.3. Alcance y productos finales

Con este proyecto se busca llegar a proponer una solución viable de codiseño hardware/software
implementada con herramientas existentes en la universidad que permita aprovechar las ventajas
de ambos mundos en sistema embebidos. Este permitiría tener módulos implementados en hard-
ware, permitiendo mayor velocidad y funciones en paralelo, y también aprovechar las ventajas
del software, facilitando los cambios y comunicación con los módulos de hardware por medio de
lenguaje de alto nivel.

Entregable Objetivo logrado

Cambio de paradigma actual del rover.
Repositorio de código Comunicación entra módulos hardware y software.
Capa de transporte seleccionada e implementada.
Wiki de repositorio Metodología de flujo de diseño hardware/software.
Pestaña Página Web Comunicación entra módulos hardware y software.
Capacitación Robocol Cambio de paradigma actual del rover.

7
4. DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFI-
CACIÓN DEL TRABAJO
4.1. Identificación del problema
El trabajo en FPGA trae beneficios a nivel de rendimiento, velocidad de procesamiento y
cantidad de tareas en paralelo. "Las FPGA (Field Programmable Gate Array) son dispositivos
compuestos por bloques lógicos que permiten ser reprogramados a voluntad del usuario (...) El
procesamiento en paralelo como técnica de programación permite ejecutar de manera simultánea
varias instrucciones,"[7] Sin embargo, la comunicación, la reparametrización y la conectividad
es más complicada y costosa (en términos de dinero y tiempo) de lograr solo con este tipo de
dispositivos. Generalmente se requiere de módulo hardware muy complicados o tarjetas embebidas
externas para lograr estas últimas tareas, y el uso de protocolos de comunicación para el manejo
de los datos.
En el caso del prototipo de rover de exploración marciana de Robocol, el cual será el caso
de estudio sobre el cual se diseñará y probará la metodología de codiseño que se desea adoptar,
aunque se pueda aplicar a muchos otros proyectos diferentes. El rover cual cuenta con una tarjeta
DE0 Nano SoC (FPGA+HPS) y solo se han usado sus capacidades de FPGA. Adicional a esto,
el rover tiene una tarjeta de desarrollo Jetson TX2 que se basa en un procesador ARM. Estas se
conectan por medio de protocolo serial, de manera que la Jetson realiza todas las tareas que la DE0
Nano SoC no puede, o que son de muy alta complejidad para implementar en hardware. Teniendo
en cuenta que la DE0 Nano Soc tiene un HPS embebido en el mismo silicio en que la FPGA
se encuentra, los cuales se comunican por buses de alta velocidad lo ideal sería implementar las
funciones que realiza la Jetson en su procesador ARM, dejando la Jetson libre para otras labores
de procesamiento y machine learning para lo que fue diseñada.

4.2. Contextualización del problema

El tema del codiseño hardware/software no es nuevo. Ya desde la década de los 80 era un tema
de estudio, especialmente con la creación de los dispositivos FPGA que permitieron la reconfigu-
ración de hardware por medio de código. En la academia, se ha hecho el esfuerzo por mejorar
la comunicación entre estos dos aspectos (el software y el hardware) de la mejor manera posible,
aprovechando lo que cada uno tiene para ofrecer, pero los procesos son muy variados entre los
diferentes desarrollos que salen al mercado. No obstante, cada día hay mayores esfuerzos por es-
tandarizar y simplificar esta comunicación. Nuevas herramientas han surgido en los últimos años
y se siguen mejorando para lograr una manera más efectiva de realizar desarrollos en torno a estos
temas.

4.3. Delimitación del problema

Con la constante creación de nuevas plataformas e interconexión de dispositivos microcontrola-
dores es muy sencillo conseguir generar buenos proyectos a nivel electrónico con poco esfuerzo y de
bajo costo. Pese a esto, cuando los diseños son de muy alta complejidad o superan las capacidades
de los microcontroladores, es común tornarse a dispositivos con mayor rendimiento, este hecho
generalmente conlleva un mayor nivel de complejidad y largos tiempos de desarrollo, incluso en
casos donde se requiere hacer cambios menores en los diseños.

8
4.4. Justificación del problema
Teniendo en cuenta la realización de proyectos que tienden a ir más allá de la capacidad de
un microcontrolador o donde gran cantidad de hardware dedicado es necesario, el diseño a nivel
electrónico es de mayor complejidad y los costos pueden llegar a elevarse más allá del presupuesto.
En muchos de estos casos, el desarrollo en dispositivos FPGA se convierte en una gran alternativa.
Permitiendo con hardware dedicado y reconfigurable en un espacio reducido y de bajo costo. A
pesar de la gran ventaja ofrecida por estos dispositivos, se presentan nuevas desventajas como la
complejidad del diseño y los grandes tiempos de sintetización que se requieren para la reparame-
trización del hardware.

4.5. Formulación del problema

El trabajo con hardware reconfigurable en los dispositivos FPGA ofrece ventajas frente al diseño
en otros sistemas como microcontroladores, no obstante estas ventajas se dan a un alto precio de
complejidad y tiempo de desarrollo, y esto es cierto incluso para pequeñas modificaciones futuras
que se deseen realizar. Es en este campo, donde los sistemas de programación en software juegan
un papel importante, dado a la baja complejidad y alta velocidad de reconfiguración.
El caso de estudio sobre el cual se quiere trabajar, para demostrar las ventajas de la metodo-
logía de codiseño hardware/software, es el prototipo de rover de exploración marciana del grupo
estudiantil de la Universidad de los Andes, Robocol. El cual comprende un robot móvil de 4 o 6
ruedas estándar simples acopladas a motores DC que cuentan con encoders de cuadratura de 9600
cuentas por una revolución de la llanta. [18]

Figura 1. Prototipo de rover de exploración marciana de Robocol en el European Rover Challenge

(ERC) 2019.

9
5. MARCO TEÓRICO, CONCEPTUAL E HISTÓRICO
5.1. Marco Teórico
5.1.1. DE0 Nano SoC
La tarjeta de desarrollo DE0 Nano SoC es una plataforma de desarrollo embebido que se basa
en la tecnología SoC. Esta tarjeta de desarrollo permite tener el alto rendimiento de una FPGA
junto a la alta reconfigurabilidad de un HPS, todo en un diseño muy compacto, de bajo consumo
y bajo costo. La tarjeta cuenta con RAM, circuito ADC, Ethernet y lo necesario para programar y
comunicarse con ella por medio de puertos USB. Así mismo, integrar varios periféricos, entre ellos
pines GPIO, botones, dip switches y hardware dedicado para protocolos de comunicación (UART,
SPI, I2C y CAN).

Figura 2. Tarjeta embebida DE0 Nano SoC. [1]

Cyclone V
Este es el componente más importante de la tarjeta de desarrollo DE0 Nano SoC creado por
Altera usando la tecnología SoC. Su principal característica es que combina una FPGA con un
procesador embebido dual-core Cortex A9 en el mismo silicio y los interconecta por medio de buses
internos de alta velocidad. En la Figura 3 se muestra como están conectados los diferentes sistemas
a la sección de la FPGA o del HPS, unicamente el JTAG está conectado a ambos, es por esto que
para lograr utlizar todas sus capacidades de conexión es absolutamente necesario trabajar con sus
2 secciones. La mayor parte de los periféricos están unidos a la FPGA, mientras que la mayoría de
la capacidades de conectividad y almacenamiento externo se encuentran en el HPS. La tabla 2 se
resumen las capacidades más relevantes de cada una de las secciones del integrado Cyclone V. [1]

10
Figura 3. Diagrama de Cyclone V. Se diferencia las secciones de FPGA y HPS (partida por
la mitad de manera demostrativa) junto con la conexión de sus componentes a una de estas 2
secciones. (Altera, 2015) [1]

FPGA HPS
- Altera Cyclone V SE 5CSEMA4U23C6N - 925 MHz Dual core ARM Cortex A9 pro-
device cessor
- Serial configuration device EPCS128 - 1GB DDR3 SDRAM (32-bit data bus)
- USB Blaster II onboard for programming; - 1 Gigabit Ethernet PHY with RJ45 con-
JTAG Mode nector
- 2 push buttons - USB OTG port, USB Micro-AB connector
- 4 slide switches - Micro SD card socket
- 8 green user LEDs - Accelerometer (I2C interface + interrupt)
- Three 50MHz clock sources from the clock - UART to USB, USB Mini-B connector
generator
- Two 40 pin expansion header - Warm reset button and cold reset button
- One Arduino Uno R3 expansion header - One user button and one user LED
- One 10 pin Analog input expansion header - LTC 2x7 expansion header
- ADC converter, 4 wire SPI interface with
FPGA

Tabla 2. Características principales de secciones de FPGA y HPS en SoC Cyclone V. [1]

11
5.1.2. Componentes de propiedad intelectual (IP Components)
Un componente IP es un bloque de diseño de hardware definido por el usuario creado para ser
incluido y conectado a un sistema de Platform Designer. Estos bloques permiten crear código en
Verilog de manera automatizada con la herramienta de Platform Designer para la generación de
HDL. Contar con estos bloques es de gran ayuda para simplificar el proceso de diseño sin perder
capacidades, además de que es posible usar bloques IP ya existentes para añadir funcionalidades
al sistemas como por ejemplo módulos de punto flotante. [10]

5.1.3. Interfaces estándar

Las interfaces estándar son usadas para interconectar los componentes IP en Platform Designer.
Dentro de las más importantes se encuentran los buses de datos de conexión entre la FPGA y el
HPS, los cuales se listan a continuación. [8] [9]

Avalon-MM: Interfaz utilizada para comunicaciones entre dispositivos maestros y esclavos,

basada en direcciones para lectura y escritura.

Avalon-ST: Esta interfaz soporta comunicación unidireccional y componentes IP de baja

latencia y alto ancho de banda.

5.1.4. Kernel de Linux

Historia de Linux
El software Linux es contado como el primer desarrollo de software libre para sistemas operativos
basado en Unix. Este sistema tiene algunas bases en Minix, un sistema operativo que había surgió
poco antes de la creación de Linux, el cual buscaba simplificar algunas tareas con respecto a la
manera de realizarlas en Minix. “El núcleo Linux fue concebido por el entonces estudiante de
ciencias de la computación finlandés, Linus Torvalds, en 1991.” [3] Linus tenía la edad de 21 años
cuando creó este OS y su objetivo era hacerlo por hobby, pero las cosas cambiaron cuando muchos
desarrolladores decidieron adoptar Linux y colaborar con el código.

¿Qué es el kernel de Linux?

“El kernel de Linux es el elemento principal de los sistemas operativos (SO) Linux, y es la interfaz
fundamental entre el hardware de una computadora y sus procesos. Los comunica entre sí y gestiona
los recursos de la manera más eficiente posible.” [15] Este permite contar con software de alto nivel
y se encarga de labores esenciales para el sistema por medio de sus drivers. El kernel está en
constantes actualizaciones y mejoras para proporcionar una herramienta segura y confiable.

Espacio de kernel y espacio de usuario

Un módulo corre en espacio de kernel, mientras que una aplicación corre en espacio de usuario
[5]. La diferencia entre estos 2 básicamente es que el espacio de usuario es el que usamos normal-
mente al trabajar en un computador, comprende las aplicaciones y tiene una alta abstracción del
bajo nivel. El espacio de kernel por el contrario es de muy bajo nivel y se encuentra en las últimas
capas del software antes de convertirse en hardware, tiene mayores capacidades de interacción con
el sistema, especialmente con el hardware y es mucho más delicado trabajar en este espacio ya que
los permiso son absolutos y los fallos pueden dar paso a la corrupción del sistema.

12
5.2. Marco Conceptual
5.2.1. Codiseño hardware-software
El codiseño hardware-software es definido como el “proceso de diseño de un sistema (desde las
especificaciones hasta la implementación final) que combina tanto componentes hardware como
software.” [6]. Este proceso por tanto contempla toda la cadena que se debe de seguir desde lo
físico a lo virtual hasta el punto donde el usuario final interactúa con el software a fin de tener
un resultado en los componentes de hardware. Este codiseño es el que permite la interacción de
teclados, ratones, parlantes y pantallas ser una fuentes de entrada y salida del sistema.

5.2.2. Proceso de arranque (Boot flow)

El proceso de arranque es la secuencia que sigue el sigue el sistema al ser encendido. Cada
sistema tiene su propio proceso de arranque que depende del hardware, sistema operativo y la
configuración requerida. Este proceso puede ser llevado a cabo desde muchos dispositivos llamados
dispositivos de arranque (boot devices), como el disco duro, dispositivo USB, CD, o incluso desde
una tarjeta SD.
En el caso de la tarjeta de desarrollo DE0 Nano SoC la Figura 4 muestra el proceso que se
sigue desde el momento en que es encendida. Empezando por el vector de reset se salta a una
inicialización que no puede ser modificada sino que ya viene programada en la tarjeta y tiene la
labor de reconocer las fuente desde donde será configurada la FPGA. Luego pasa al preloader que
es la primera etapa que puede ser compilada por el usuario para acomodarse a la características y
que tiene como principal objetivo el iniciar la SDRAM. Esta etapa además da paso al U-Boot que
es el encargado de cargar Linux y dar paso para acceder al sistema operativo desde el espacio de
usuario. [19]

Figura 4. BootFlow. [19]

13
5.3. Marco Histórico
5.3.1. Trabajos previos
El tema del codiseño hardware-software se estudia desde hace varios años y es la base del
funcionamiento de los computadores permitiendo conectar dispositivos físicos entre sí para dar una
experiencia de manejo agradable, cómoda y veloz al usuario. La siguiente es una lista de trabajo
previos que se han realizado con respecto a este tema. Los siguientes documentos se usaron como
referencia y material de estudio para la recolección de información y estudio para la elaboración
del proyecto de grado y el documento.

Diseño de una interfaz HPS-FPGA para la Plataforma SocKit [13] Este proyecto desarrolla
una interfaz usando el circuito integrado de la misma familia pero una tarjeta de desarrollo
distinta. Los objetivos aún así no son los mismos y tiene un enfoque hacia el hardware, se
utilizó como un buen punto de partida para el desarrollo del proyecto.
Codificador JPEG: Caso de estudio de Co-diseño Hardware/Software [6] En este trabajo
aunque no se usa la misma tecnología y tarjeta de desarrollo si es de mucha utilidad para
comprender mejor la utilidad del codiseño hardware-software y dar un acercamiento. En este
proyecto se menciona la posibilidad del uso de una combinación ARM-FPGA, sin embargo en
esta ocasión no se usa por sus limitaciones y por no contar con la capacidad de procesamiento
para lo planteado ya que se tenía una tarjeta en la Universidad con menos prestaciones que
la usada en este proyecto.
A methodology for hardware-software codesign [11] Este proyecto se aprovechó principalmen-
te por su gran contenido en términos de la teoría específica a muy bajo nivel, en términos de
hardware especializado y comunicación de este con el software.
Metodología de codiseño hardware-software para procesamiento de señales radar en sistemas
embebidos [20] Para este proyecto se tiene un aplicación muy específica del uso del codiseño
hardware-software. Su principal aporte fue en la toma de decisiones de como abordar una
implementación muy específica usando una metodología y lograr tener éxito, su mayor aporte
para este trabajo fue el de dar herramientas para la correcta implementación de sistemas con
el uso del codiseño.

6. DEFINICION Y ESPECIFICACION DEL TRABAJO

6.1. Definición
Para poder aprovechar las ventajas del hardware y el software de manera conjunta los de-
sarrolladores de sistemas embebidos trabajan en la actualidad en diseño de tecnologías SoC, las
cuales pueden integran dispositivos reconfigurables en hardware (como una FPGA) y dispositivos
reprogramables en software (como procesadores o microcontroladores). Estos, al estar en un mismo
circuito integrado cuentan con interconexiones especiales.
El diseño a nivel de hardware reconfigurable con FPGA ofrece ventajas en procesamiento y
velocidad de los sistemas, además de un alto paralelismo en la ejecución de las tareas. Sin embargo,
su reconfigurabilidad es por lo general compleja, demorada y muy limitada. Se requiere de software
especializado, conexión física con el sistema a reconfigurar, buen conocimiento de HDL y una gran
cantidad de tiempo para sintetizar y probar los cambios. Aunque es una tarea necesaria en la

14
mayoría de las ocasiones, en muchos casos solo se busca cambiar una variable ya definida, hacer
lectura de variables internas para depuración o reconfigurar la forma en que el hardware dedicado
ya de por si trabaja.
Al unir las cacacidades de una FPGA con las de un procesador con un conexión veloz y estable se
puede hacer uso de lo mejor de ambos mundo (el hardware y el software), aprovechando al máximo
lo que cada uno tiene por ofrecer. Bajo esta idea se busca plantear una metodología sencilla basada
sobre la tarjeta de desarrollo DE0 Nano SoC que permita entablar esta comunicación a nivel de
programación de una manera clara. sencilla y eficiente. Al final, se espera contar con una serie de
pasos que se pueden seguir para poder interactuar con los módulos de hardware desde el lado del
software, tanto en espacio de usuario como en el de kernel.

6.2. Especificaciones
6.2.1. Restricciones
A continuación se muestran una serie de restricciones del proyecto, las cuales permiten delimitar
el modo y casos de uso del mismo.
Solo es aplicable a configuraciones SoC de FPGA+HPS con interconexión AXI.
El proyecto se centra únicamente en poder realizar una conexión de un hardware en HDL que
puede ser sintetizado en la FPGA. A pesar de que es necesario hacer cambios en el hardware
solo se realizan los cambios estrictamente necesario y no se trata el diseño de hardware en
FPGA.
El proyecto está restringido a un único bus de datos de los 3 posibles de la tarjeta, los otros
se pueden usar pero no se habla, ni se enseña acerca de estos en este proyecto.

6.2.2. Funciones
Es una herramienta de gran utilidad para lograr una conexión efectiva entre código de soft-
ware y el hardware sintetizado que no requiere de tarjetas externas de desarrollo.
Permite lograr una eficiente parametrización de la tarjeta de desarrollo, siempre que esas
señales sean tenidas en cuenta en la creación de los bloques IP.
Simplifica el proceso de comunicación de la tarjeta al no requerir la implementación de
módulos comunicación en hardware sino el uso de implementaciones de red por software.

6.2.3. Parámetros relevantes

La Tabla 3 muestra las variables que se querían mejorar empezando con el diseño inicial (solo
FPGA) y lo mínimo que se espera al terminar el nuevo diseño (FPGA+HPS).

Variable a mejorar Solo FPGA FPGA+HPS

Tiempo de reparametrización 20-30 mins <20 mins
Reprogramación remota No Sí, por TCP.
Dependencia de otra tarjeta Sí No.
Limitante de máxima velocidad de transmisión Protocolo UART Protocolo de red

Tabla 3. Comparación de variables de desempeño entre el estado inicial y el mínimo deseado.

15
7. METODOLOGÍA DEL TRABAJO
Para poder lograr el proyecto propuesto se requirió separar las tareas de manera independiente
de manera consecutiva, teniendo en cuenta el plazo máximo para cumplir con los objetivos plan-
teados. El tema central que se escogió se basa en conceptos estudiados a lo largo de la carrera,
pero de igual manera tiene varios conceptos que no se estudiaron a profundidad y por tanto la
primera etapa de desarrollo se basó en la correcta investigación, recopilación de información y en-
tendimiento de manera más profunda de los temas a ser tratados. Con el objetivo de comprender
de mejor manera los temas y llevar un buen proceso se contó con el apoyo de diferentes coasesores
involucrados en el área, especialmente desde un punto de vista industrial y laboral.

7.1. Plan de trabajo

Reuniones semanales con asesor Fredy Segura y coasesor Josnelihurt Rodríguez.
Reuniones semanales con asesor Fredy Segura, coasesor Fernando Escobar, coasesor Nicolás
Rocha y estudiantes que realizaron el proyecto de grado con el mismo asesor.
Tareas asignadas cada semana en Teams.
Informe de avances de mitad de semestre.

7.2. Búsqueda de información

Las siguientes fueron las fuentes de información utilizadas para el correcto desarrollo del trabajo.
Principales recursos electrónicos.
• Rocket Boards
• Linux Device Drivers
• Terasic
• Intel
Asesoramiento de asesor y coasesores.
• Fredy Segura. (Asesor)
• Josnelihurt Rodríguez. (Coasesor)
• Fernando Escobar. (Coasesor)
• Nicolás Rocha. (Coasesor)
Cursos de Coursera.
• Introduction to FPGA Design for Embedded Systems.
• Hardware Description Languages for FPGA Design.
• FPGA Softcore Processors and IP Acquisition.
Cursos de Intel® FPGA Technical Training Catalog.
• Introduction to the Platform Designer System Integration Tool.
• Custom IP Development Using Avalon® and Arm* AMBA* AXI Interfaces.
• Software Design Flow for an Arm*-based Intel® SoC FPGA.

16
7.3. Alternativas de desarrollo
7.3.1. Modificar los módulos de hardware
En un principio, se contempló la idea de modificar los módulos de hardware para incluir las
herramientas que le permitan conectarse al HPS sin necesidad de la creación de nuevos módulos
que cumplieran esta labor.

Ventajas de modificar

Menos cantidad de archivos de código.

Revisión de hardware y conexión al HPS en un mismo archivo para cada sistema.

Desventajas de modificar

Mayores posibilidades de error debido a la incorrecta modificación de los módulos.

Mayor densidad de código en cada archivo y menos orden.
Mayor dificultad de revisar y realizar una correcta depuración de errores.

Esta idea no se realizó debido a que se podía convertir fácilmente en una fuente de error
donde no se sabía si lo que estaba fallando era el módulo o la conexión. Al estar los módulos de
hardware funcionales y ya probados de manera extensiva se decidió no tocarlos sino que generar
nuevos módulos que se comunicaran con estos y con el HPS por el otro lado, de esta manera se
pudo dar una detección rápida de las fallas, se conservó un orden estándar y se pudo desarrollar
una metodología organizada y que se puede replicar de la misma manera para gran cantidad de
módulos.

8. TRABAJO REALIZADO
La realización del proyecto para demostrar la funcionalidad de la metodología de codiseño se
basó en la implementación del caso de estudio, este se tiene como un ejemplo de sus capacidades
y no es un limitante, ya que la metodología se puede aplicar a otro tipo de proyectos, ni siquiera
deben de ser temas de robótica sino en general casos donde se requiera manejo de funciones con
gran cantidad de datos, se requieran buenas velocidades de trabajo o gran cantidad de tareas en
paralelo.
En el caso del rover de exploración marciana, en la Figura 5 se muestra un diagrama de conexión
de alto nivel, donde se tiene en cuenta el SoC Cyclone V y un equipo host el cual está corriendo
un nodo para comunicación con una interfaz web. Esta conexión entre el Nodo FPGA y el Nodo
ROS del Host se realiza por medio de la red teniendo conectada la tarjeta DE0 Nano SoC a un
router por medio de un cable Ethernet. Los módulos en azul de la Figura 5 que se encuentran a
la izquierda representan los bloques de hardware configurado en la FPGA, los cuales se conectan
todos a un módulo llamada SoC system, el cual se encarga de realizar la conexión con el HPS los
diferentes drivers que se crearon para cada una de las funcionalidades.

17
 Figura 5. Diagrama de bloques de conexión entre SoC Cyclone V y equipo host.

De manera más específica, la Figura 6 muestra un diagrama de conexiones más detallado, donde
los bloques en azules están configurados en la FPGA y se cuentan con ellos desde un principio,
mientras que los que están en amarillo son implementados en software y hacen parte del trabajo
realizado para realizar la labor de codiseño. En este caso, no se muestra la sección del soc system
para poder mostrar de mejor manera las conexiones entre los módulos, sin embargo, este módulo
es escencial y de no contarse con él habría que realizar toda la configuración en hardware para
exportar las señales al HPS. Esto último no es necesario ya que se parte del GHRD que es el diseño
de referencia que ofrece Altera para empezar.

Figura 6. Diagrama de bloques de conexión entre SoC Cyclone V y equipo host.

En la figura 6, los bloques de hardware (azules) que no tienen una conexión directa a los
amarillos representan módulos de hardware que no tendrán una conexión al HPS ya que no serán
contemplados para el proyecto, esto debido a que la implementación se basó en tracción y muchos
de ellos aún están en proceso de diseño y por lo tanto no hay una hardware estable sobre el cual
trabajar aún.

18
8.1. Descripción del Resultado Final
Para llegar al resultado final se requirió seguir de manera ordenada una serie de etapas las
cuales comenzaron por contextualizar e investigar sobre los temas a tratar, luego revisar con
detenimiento los códigos sobre los cuales se dio el punto de partida, lograr pequeñas tareas de
manera independiente que contribuyeran al objetivo final, generar un sistema básico del sistema
que se busque generan y finalmente empezar a unir todas las piezas que darán paso al resultado
final.

Investigación y contextualización.
Revisión de módulos hardware.
Configuración de ambiente de programación.
Configuración de board de desarrollo.
Generación de mapa de memoria.
Selección de protocolo de comunicaciones.
8.1.1. Investigación y contextualización
Dada la complejidad del tema tratado se requirió tener un tiempo largo de investigación y
contextualización con el tema a tratar al comienzo del proyecto de manera exclusiva y a lo largo
del proyecto en menor manera pero aún así de forma continua. Este se basó principalmente en el
estudio del kernel de Linux y en el desarrollo de drivers de dispositivos para este sistema operativo.

8.1.2. Revisión de módulos hardware

Para poder realizar la conexión de los módulos hardware al software fue necesario analizar los
bloque diseñados en Verilog y estudiar cuales y cuantas señales serían conectadas, así como su
tamaño, ya que el tamaño del bus de datos es de 32 bits. [8] Algunas señales eran mayores a este
valor en bits, por lo cual era necesario separarlas en 2 registros de 32 bits o truncar la señal para que
se pudiera enviar en una única transmisión. Separar las señales es sencillo pero requiere un poco
más de código y es un poco más demorado, mientras que truncar la señal afecta el funcionamiento
de los módulos hardware, por tanto es necesario analizar los efectos que esto tendría.
Luego de analizar las señales y comprobar que existían señales mayores a 32 bits de longitud
se hizo un análisis del efecto de truncarlas y se pudo comprobar que no había inconveniente en
hacerlo ya que aunque reducía las capacidades de los módulos eran más que suficientes para la
aplicaciones de uso del rover. El repositorio base sobre el cual se basó el proyecto se encuentra en
el siguiente link.

8.1.3. Configuración de ambiente de programación

En esta etapa se hizo la instalación de los programas necesarios para el correcto desarrollo del
proyecto, empezando por Ubuntu 18.04 y la herramienta principal de desarrollo llamada Quartus.

8.1.4. Configuración de board de desarrollo

Para la configuración de la board fue necesario escoger una versión del kernel de Linux que fuera
compatible con Ubuntu 18.04, y configurar el U-Boot de manera apropiada para el uso del proyecto
habilitando la opción para hacer el kernel modularizable y la conexión del bus de datos Lightweight

19
HPS-FPGA Bridge el cual sería el modo de comunicación entre componentes. La razón para usar
este bus de datos y no los otros 2 disponibles es debido a que la metodología se hace más sencilla
usando esta interfaz estándar, además del hecho de que para la cantidad y velocidad de transmisión
de datos de la mayoría de aplicaciones su uso es suficiente entregando un alto rendimiento. De ser
necesario un mayor ancho de banda o velocidad de transmisión aprovechar los buses de datos
adicionales es una opción pero de mayor complejidad ya que requiere más configuración.
8.1.5. Generación de mapa de memoria
Para lograr la correcta conexión entre los módulos hardware y los drivers en software fue
necesario seleccionar las entradas y salidas, son tamaños en bits y la cantidad de módulos que se
requiere conectar.

Figura 7. Mapa de memoria para módulos de hardware.

8.1.6. Selección de protocolo de comunicaciones
Para poder comunicar los datos de entrada y salida con otro equipo es necesario contar con
un protocolo de red adecuado que permita transportar los datos de manera bidireccional. En esta
etapa del proyecto se tuvieron en cuenta diferentes protocolos de red para estudiar sus ventajas y
desventajas. Con esta información se pudo seleccionar uno adecuado para la aplicación. La Tabla
8 muestra un resumen las características de varios diferentes protocolos de red.

Figura 8. Tabla comparativa de diferentes protocolos de red.

20
 Al final se decidió seleccionar el protocolo de ROS, ya que a pesar de que no trae todas las
ventajas que pueden traer otros, sus habilidades son suficientes para la aplicación en el proyecto y
el equipo Robocol ya hace uso de este protocolo lo cual simplifica la conexión a los demás sistemas.

8.2. Generación de drivers de dispositivos

Esta etapa ya se concentró en el software necesario para escribir a los módulos hardware y
leer información de ellos y poder exponer esta información al espacio de usuario por medio de la
creación de dispositivos alojados en /dev. Estos drivers se crearon en lenguaje C y cuentan con
unas características muy especiales de como deben de ser abiertos y cerrados y de que funciones
realizar cuando un hardware con las características deseadas es detectado. [14] [12]

8.3. Trabajo computacional

Para poder realizar el trabajo se requiere de un software especializado para el trabajo con la
tarjeta DE0 Nano SoC. En la configuración del ambiente de programación en el equipo host se
usaron los siguientes programas con las versiones indicadas a continuación:

Ubuntu 18.04.5 LTS

Quartus Prime Lite 19.1
SoC Embedded Development Suite 19.1.0.670
Arm Development Studio 2020.1 (Opcional)

Con las herramientas de desarrollo configuradas fue necesario generar los compiladores cruzados
para poder usar el equipo host como equipo de desarrollo y solo requerir la transferencia de los
ejecutables compilados a la tarjeta de desarrollo para su ejecución y realización de pruebas. En
la Tabla 4 se pueden ver los ambientes que se configuración como compiladores cruzados con sus
versiones para este proyecto.

Herramienta Versión específica

Linaro Toolchain gcc-linaro-6.5.0-2018.12-x86_64_arm-linux-gnueabihf
Linux Kernel Linux 4.9.78-ltsi

Tabla 4. Herramientas configuradas para funcionar como compiladores cruzados.

El resultado final del trabajo se resumió en las siguientes entregas que se realizaron:

Repositorio de código en GitHub.

Wiki del repositorio..
Capacitaciones virtuales al grupo Robocol.

21
9. VALIDACIÓN DEL TRABAJO
9.1. Metodología de prueba
En la etapa de validación se contaran con varias etapas que permitieron tener un avance pro-
gresivo, desde lo más específico a lo más general. Las siguientes fueron las etapas para la validación
del trabajo.

Pruebas de medición con osciloscopio.

Pruebas de comunicación de ROS.
Banco de pruebas con motor DC.
Pruebas con joystick.
Pruebas con interfaz web.

9.1.1. Pruebas de medición con osciloscopio

Para poder verificar de manera adecuada el correcto funcionamiento del hardware y su velo-
cidad de respuesta a las instrucciones de software se empezó realizando pruebas de medición con
osciloscopio de las señales generadas en los pines GPIO, así como la comprobación de las señales
de entrada comparadas con la respuesta obtenida en la lectura del procesador. En la Figura 9 se
muestra una señal cuadrada de 20 KHz y un ciclo útil del 50 % aproximadamente, el cual representa
una señal PWM al ser probada.

Figura 9. Pruebas de PWM con osciloscopio.

22
9.1.2. Pruebas de comunicación con ROS
Luego de comprobar las señales de entrada y salida con el osciloscopio haciendo uso del software
se validó que estos datos se escribieran y leyeran de manera correcta por medio del protocolo
ROSTCP para completar la cadena completa de transferencia de datos, desde un equipo host
conectado a la red, hasta las salidas y entradas GPIO de la tarjeta de desarrollo DE0 Nano Soc.

Figura 10. Pruebas de comunicación de ROS entre un host y la tarjeta DE0 Nano SoC.

9.1.3. Banco de pruebas con motor DC

Con el objetivo de verificar de manera física el correcto funcionamiento, luego de haber realizado
las pruebas con el osciloscopio se armó un banco de pruebas con el que se pudiera comprobar el
correcto funcionamiento de los sistemas desde el software.

Para el banco de prueba se utilizaron los siguientes elementos

Tarjeta de desarrollo DE0 Nano SoC.
Adaptador de 5V DC.
Router Ethernet.
Cable Ethernet.
Equipo host con conexión al router (WiFi o Ethernet).
Motor DC 24 VDC.
Encoder con 500 CPR.
Driver 24 VDC.
Fuente DC 24 VDC.

9.1.4. Pruebas con joystick

Al comprobar la generación de la señales PWM, la lectura de los encoders y los demás módulos
de hardware desde las aplicaciones usuario del software se conectaron al nodo de ROS para manejo
del joystick por medio de tópicos y se comprobó la correcta generación de las señales PWM al
guiarlo variar la posición del joystick.

23
 (a) Giro izquierda. (b) Avance de frente (c) Giro derecha PWM azul de 0

Figura 11. Pruebas de comunicación de ROS entre un equipo host y la tarjeta de desarrollo DE0
Nano SoC. La señal PWM de color azul es para la derecha y la de color amarillo para la izquierda.
9.1.5. Pruebas con interfaz web
Luego de realizar las pruebas con el joystick y comprobar el correcto funcionamiento se modificó
la interfaz web del grupo Robocol creando una nueva pestaña, la cual se puede ver en la Figura
12. Esta lista las entradas y salidas que se programaron en la FPGA, el estado de los LEDs y dip
switches. Así mismo permite reparametrizar los controladores y encoders en caso de ser necesario,
leer los valores de PWM y corrientes, así como el envió de comandos de manera manual para
realizar pruebas. Esta interfaz se conecta directamente con un nodo de ROS que se encarga de
escribir en los tópicos correspondientes la información requerida. El repositorio que contiene los
códigos usados para levantar la aplicación web se encuentra en el siguiente link.

Figura 12. Pruebas de página web conectada a tópicos de ROS.

Para estas pruebas se requirieron los siguientes elementos

DE0 Nano SoC.
Adaptador de 5V DC.
Equipo host con conexión al router (WiFi o Ethernet).

24
 Interfaz web de Robocol.

9.2. Validación de los resultados del trabajo

De acuerdo a las variables deseadas al comenzar el trabajo y los resultados esperados se realizó
una comprobación de las variables que se deseaban mejorar. La Tabla 5 resume la validación

Variable a mejorar FPGA+HPS

Tiempo de reparametrización Alrededor de 1 a 5 segs.
Reprogramación remota Sí, por red.
Dependencia de otra tarjeta No.
Limitante de máxima velocidad de transmisión Velocidad de la red.

Tabla 5. Comparación de variables de desempeño entre el estado inicial y el mínimo deseado.

Luego de validar los tiempos de reparametrización fue posible comprobar que se pasó de un
tiempo de sintetización de 20 a 40 minutos a una solicitud por un request a través de un tópico
de ROS la cual dura unos segundos (de 1 a 5) en realizarse y comprobarse el cambio por medio
de una lectura. Esto implica una mejora en rendimiento de alrededor de 600 veces, esto sumado a
que no se requiere una conexión por USB con el programador de Quartus sino que esta conexión
se da por medio de la red, habilitando el uso de WiFi para la reparametrización.

9.3. Evaluación del plan de trabajo

La mayor parte de las actividades se realizaron de acuerdo al cronograma. Sin embargo,
algunas de ellas tuvieron diferentes duraciones de las esperadas, y otras se modificaron para
ir más acorde a los objetivos.
Algunas de las tareas que fueron propuestas en el cronograma carecían de sentido con el
proyecto debido al desconocimiento de los temas que se trataron. Es por esto que debieron
ser modificadas acorde con la investigación.
El desarrollo de las tareas relacionadas con el kernel fue subestimado en tiempo. Este aspecto
también tuvo que ver con el desconocimiento que se tenía acerca del diseño de drivers.
Afortunadamente, aún con estos retrasos fue posible cumplir los objetivos con un esfuerzo
mayor al presupuestado de manera inicial.
El tiempo extra al terminar el semestre fue de gran ayuda para concluir todo de la mejor
manera y ayudó a tener un código y wiki más organizados.
A lo largo del semestres se requirió la creación de nuevas tareas de complejidad media las
cuales no se tenían pensadas.

10. DISCUSIÓN
10.1. Desempeño
Se tenía un objetivo claro pero una idea muy básica de como se iba a realizar. Muchos
conceptos no eran claros al comenzar a realizar el proyecto.

25
 El trabajo requirió gran cantidad de investigación y dejó muchas interrogantes interesantes
de trabajo futuro que se puede lograr con la metodología.
La documentación de la tarjeta de desarrollo es muy básica y se encuentra mejor documen-
tación de otras tarjetas de desarrollo similares. Además la información que se encuentra está
muy dispersa, así que se realizó un trabajo de recopilación de información de varias fuentes.

10.2. Limitaciones
Este proyecto no es una opción para prototipado rápido. De hecho, requiere una gran can-
tidad de tiempo de diseño y pruebas para una correcta implementación, no está pensado
para proyectos sencillos, sino que al contrario su principal uso se da cuando los sistemas
embedidos como microcontroladores son insuficientes y se requiere de una mayor capacidad
de procesamiento.
A nivel electrónico se categoriza dentro de un proyecto de alta complejidad, debido a que
se requiere buen conocimiento de ciertos aspectos del funcionamiento del kernel de Linux,
además del uso de lenguajes de bajo nivel como C y C++. Incluso, aunque el objetivo no la
implementación de hardware es necesario tener conocimientos de lenguajes HDL, especial-
mente Verilog que fue el que se utilizó para este proyecto, esto debido a que es necesario
generar ciertos módulos sencillos en el hardware para que la conexión de señales entre la
FPGA y el HPS.

10.3. Problemas encontrados y cómo pueden o fueron resueltos

No existía una versión de ROS Melodic para Angstrom.

- Debido a que no existía una versión de ROS Melodic para la distribución Angstrom, que viene
por defecto en la tarjeta de desarrollo, se decidió instalar Ubuntu 18.04 LTS que si lo permite.

El Preloader no pudo ser compilado

- Al intentar generar el preloader para la tarjeta SD usada en la tarjeta de desarrollo, dado a que
las nuevas versiones de las herramientas no contemplan el uso de un preloader, se tomó el preloader
de la imagen original de Terasic.

10.4. Trabajo que falta por ser realizado

Pruebas extensivas en el rover. Aunque el sistema quedó implementado y probado para ser
funcional en el rover, debido a los problemas del aislamiento social actual no ha sido posible
hacer pruebas extensivas de sus ventajas.
Como cualquier proyecto de código o metodología, siempre se puede mejorar. Muchas herra-
mientas adicionales que se podrían realizar con la tarjeta no se tuvieron en cuenta debido al
tiempo y al cumplimiento de los objetivos planteados al comienzo del proyecto.

26
10.5. Trabajo futuro
Aplicar el mismo diseño al subsistema de brazo. Este no se pudo realizar en este proyecto dado
que los módulos de hardware no se habían terminado al momento de comenzar el proyecto
y dada la complejidad del proyecto se requería trabajar sobre hardware ya implementado y
probado para poder concentrarse mayormente en las etapas de software que al comenzar el
proyecto eran inexistentes.
A pesar de contar con un caso de prueba para validación, es posible aplicar la metodología
a muchos otros diseños y proyectos. El trabajo se realizó de manera tal que fuera posible
concentrarse en la tecnología y metodología que se estaba estudiando para no limitar o entrar
en detalles del diseño en el caso del rover, sino solo los que aportaran de manera significativa
al cumplimiento de los objetivos.
Contando con una series organizada de pasos documentada a través de la wiki del proyecto. Es
posible realizar la generación de nuevos módulos de hardware sin tener una preocupación tan
grande por su conexión a nivel de software. Esto debido a que la metodología acá planteada
tiene como propósito la discriminación de los pasos necesarios para lograr comunicar la
información al software sin que esto sea un gran problema.

27
11. CONCLUSIONES

Las pruebas físicas que se realizaron con el osciloscopio, el banco de pruebas y por medio
de la página web fueron de utilidad para comprobar el correcto funcionamiento del sistema
y de los módulos hardware a través de lecturas y escrituras desde el software implementado
en el HPS. Adicionalmente, se logró comprobar la independencia del integrado SoC de otras
tarjetas de desarrollo para su comunicación con directa a la red por medio de TCP/IP.

La metodología de codiseño permitió conectar la tarjeta de desarrollo DE0 Nano SoC a la

red de manera directa sin ningún intermediario a diferencia anteriormente que era necesario
tener otra tarjeta de desarrollo (específicamente una Jetson TX2) la cual se comunicaba por
serial y luego transmitía los datos a la red.

Las mediciones realizadas mostraron que los tiempos de respuesta de la recepción de los
comandos y la lectura de las señales de los módulos de hardware en las aplicaciones de
usuario fueron apropiados y consecuentes con lo deseado, pasando de tiempo de 20 a 40
minutos de sintetización para modificar un parámetro a poder modificar por software en
tiempos menores a 5 minutos. Además de permitir la reparametrización de las variables
seleccionadas para las componentes IP a partir del software desde el espacio de usuario.

El trabajo resumió una metodología de codiseño hardware software en la tarjeta de desarrollo

DE0 Nano SoC por medio del bus de datos Lightweight HPS-FPGA Bridge y el uso de la
FPGA y el HPS embebidos en el SoC. Esta metodología quedó documentada en la Wiki del
repositorio de GitHub que contiene el código del caso de estudio y una explicación detallada
del uso de esta.

28
Referencias
[1] Altera (2015) DE0-Nano-SoC Development Kit User Manual. [Online] https://www.terasic.com.tw/attac
hment/archive/941/DE0-Nano-SoC_User_manual.pdf
[2] Altera (2016) WS3 – Developing Drivers for Altera SoC [Online] https://rocketboards.org/foswiki/pub
/Documentation/WS3DevelopingDriversForAlteraSoCLinux/WS3_Developing_Drivers_for_Altera_SoC
.pdf
[3] Ametzazurra X. (2012) Historia de Linux. [Online] https://www.eoi.es/blogs/fpentumovil/2012/02/29/
historia-de-linux/
[4] Basil M. Al-Hadithi, Juan Suardíaz Muro (2004) NUEVAS TENDENCIAS EN EL DISEÑO ELECTRÓNICO
DIGITAL: CODISEÑO HARDWARE/SOFTWARE. [Online] https://revistas.uax.es/index.php/tec_d
es/article/download/519/475
[5] Corbet J., Rubini A., and Kroah G., (2005) Linux Device Drivers. [Online] https://www.eoi.es/blogs/fpe
ntumovil/2012/02/29/historia-de-linux/
[6] Escobar F. (2007) Codificador JPEG: Caso de estudio de Co-diseño Hardware/Software. [Online] https:
//repositorio.uniandes.edu.co/bitstream/handle/1992/23718/u303355.pdf?sequence=1
[7] Giral D., Romero R. & Martínez F. (2015) Procesamiento paralelo en FPGA para convolución de imágenes
usando Matlab. [Online] http://www.scielo.org.co/pdf/tecn/v19n43/v19n43a10.pdf
[8] Intel (2021) Avalon Interface Specifications. [Online] https://www.intel.com/content/www/us/en/progra
mmable/documentation/nik1412467993397.html
[9] Intel (2019) Intel Quartus Prime Standard Edition User Guide [Online] https://www.intel.com/content/
dam/www/programmable/us/en/pdfs/literature/ug/ug-qps-platform-designer.pdf
[10] Intel (2017) Introduction to Intel FPGA IP Cores. [Online] https://www.intel.com/content/www/us/en/
programmable/documentation/mwh1409960636914.html
[11] King M. (2013) A methodology for hardware-software codesign. [Online] https://dspace.mit.edu/handle/
1721.1/84891
[12] Mao H. (s.f.) Exploring the Arrow SoCKit Part X - Sending and Handling Interrupts. [Online] https://zheh
aomao.com/blog/fpga/2014/05/24/sockit-10.html
[13] Martínez J. (2018) Diseño de una Interfaz HPS-FPGA para la Plataforma SocKit. [Online] http://oa.upm.e
s/53167/
[14] Meteer O. (2017) Building embedded Linux for the Terasic DE10-Nano (and other Cyclone V SoC FPGAs).
[Online] https://bitlog.it/20170820_building_embedded_linux_for_the_terasic_de10-nano.html
[15] RedHat (s.f.) ¿Qué es el kernel de Linux? [Online] https://www.redhat.com/es/topics/linux/what-is-t
he-linux-kernel
[16] Robocol Uniandes. (2019) REM-U Verilog control code (Repositorio GitHub). [Online] https://github.com
/robocol-rem-u/REM-U_Control_Verilog
[17] Robocol Uniandes. (s.f.) Robocol. [Online] https://robocol.uniandes.edu.co/es/
[18] Robocol Uniandes. (s.f.) Rover. [Online] https://robocol.uniandes.edu.co/es/proyectos/rover
[19] RocketBoards.org (2015) Embedded Linux Beginners Guide. [Online] https://rocketboards.org/foswiki
/Documentation/EmbeddedLinuxBeginnerSGuide
[20] Silva F. (s.f.) Metodología de codiseño hardware-software para procesamiento de señales radar en sistemas
embebidos. [Online] https://repository.javeriana.edu.co/bitstream/handle/10554/34080/SilvaGome
zFelipeAndres2018.pdf?sequence=3&isAllowed=y

29
12. APÉNDICE

Figura 13. Diagrama UML de funciones de alto nivel para parametrización y lectura de los
módulos de hardware.

30