Sistema de neuroestimulación basado en PYNQ

Equation Chapter 1 Section 1 Trabajo Fin de Máster Ingeniería Electrónica, Robótica y Automática Sistema de neuroestimulación basado en PYNQ Autor: Alfredo Toro Jiménez Tutor: Hipólito Guzmán Miranda Dpto. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 iii Trabajo Fin de Máster Ingeniería Electrónica, Robótica y Automática Sistema de neuroestimulación basado en PYNQ Autor: Alfredo Toro Jiménez Tutor: Hipólito Guzmán Miranda Profesor titular Dpto. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2024 v Trabajo Fin de Máster: Sistema de neuroestimulación basado en PYNQ Autor: Alfredo Toro Jiménez Tutor: Hipólito Guzmán Miranda El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2024 El Secretario del Tribunal vii A mi familia A mis maestros ix Agradecimientos A Hipólito Guzmán Miranda, mi tutor, por su prestarme su ayuda de forma incansable y permitirme aprender de él. A Beatriz, por su apoyo en todo momento. Alfredo Toro Jiménez Sevilla, 2024 ÍNDICE DE TABLAS Tabla 3-1. Descripción del bloque stimulation control 14 Tabla 3-2. Descripción del bloque channel manager 16 Tabla 3-3. Definición de comandos 18 Tabla 3-4. Simulación del channel manager. Acción 1 19 Tabla 3-5. Simulación del channel manager. Acción 2 20 Tabla 3-6. Simulación del channel manager. Acción 3 20 Tabla 3-7. Tabla de frecuencias 21 Tabla 4-1. Block RAM Zynq-700 29 xvii ÍNDICE DE FIGURAS Figura 21. PYNQ Z2 4 Figura 22. PmodDA2 5 Figura 23. Osciloscopio 5 Figura 24. Protocolo AXI. Transacción de lectura. Fuente: 7 Figura 25. Protocolo AXI. Transacción de escritura. Fuente: 7 Figura 26. Protocolo SPI. Múltiples esclavos. Fuente 8 Figura 27. Protocolo SPI. Un solo esclavo. Fuente 8 Figura 28. Protocolo SPI. Transmisión de datos. Fuente 8 Figura 31. Arquitectura general del sistema a implementar 9 Figura 32. Bloque trigger 10 Figura 33. AXI Verification IP 11 Figura 34. Simulación del bloque trigger 11 Figura 35. Simulación del bloque trigger. Protocolo AXI 12 Figura 36. Diseño dividido por subsistemas 13 Figura 37. Bloque stimulation control 14 Figura 38. Simulación del stimulation control 15 Figura 39. Diseño del bloque channel manager 16 Figura 310. Simulación del channel manager 1 19 Figura 311. Simulación del channel manager 2 21 Figura 312. Bloque channels 22 Figura 313. Fase de escritura o configuración. Ejemplo de 2 transacciones, una en rojo y otra en amarillo. 23 Figura 314. Fase de lectura o estimulación. Ejemplo de escritura de tres datos. 23 Figura 315. Modo looped 24 Figura 41. Verificación del sistema completo 27 Figura 42. Simulación del sistema completo 28 Figura 43. Especificaciones del hardware de la familia Zynq-700 29 Figura 44. Recurso utilizados por la FPGA 29 1 INTRODUCCIÓN a neuroestimulación se ha convertido en una herramienta fundamental para la investigación y el tratamiento en neurociencia, ofreciendo posibilidades para el estudio y modulación de la actividad cerebral. Sin embargo, los equipos actuales presentan importantes limitaciones que no facilitan su accesibilidad y funcionalidad. Uno de los principales inconvenientes es el elevado costo de los dispositivos, la limitada cantidad de canales que ofrecen, y el uso de señales de solo dos niveles, lo cual es limitante para generar patrones complejos de estimulación. Una forma de avanzar en esta área sería contar con un número elevado de canales, lo que permitiría generar estímulos más complejos y personalizados. Sin embargo, para que este enfoque se lleve a cabo, es crucial que los canales estén adecuadamente sincronizados, evitando desfases e irregularidades en el tiempo. Estos requisitos convierten la tecnología FPGA (Field-Programmable Gate Array) en una opción idónea, ya que su arquitectura permite implementar sistemas de alta capacidad de paralelismo, garantizando la precisión y sincronización necesarias para aplicaciones de neuroestimulación. 1.1 Objetivos El objetivo de este trabajo consiste en explorar las distintas posibilidades que ofrecen las plataformas allprogrammable System-On-Chip (SoC), concretamente en este caso, la familia Zynq-7000 de AMD Xilinx, para el desarrollo de la lógica de neuroestimuladores paralelos de un número elevado de canales. Particularmente, se explorará el uso del microprocesador integrado en el dispositivo, así como la combinación de bloques diseñados en lenguaje VHDL con bloques dieñados en alto nivel utilizando una herramienta de síntesis C a hardware. Adicionalmente, se explorará la herramienta Jupyter Notebook para realizar manejo de los periféricos del microprocesador en lenguaje Python. 1.2 Alcance El alcance de este proyecto será desarrollar el diseño de un neuroestimulador capaz de estimular con el mayor número de canales en paralelo, para poder ser usado en laboratorio. Como requisito para llevar a cabo esta implementación, el dispositivo deberá leer los datos a través de un fichero csv ubicado en el microprocesador, el cual será interpretado con Jupyter Notebook. Una vez el hardware se encuentre configurado, deberá estimular a través de un interfaz SPI que lo conectará a un convertidor digital a analógico (DAC). L 2 RECURSOS UTILIZADOS l objetivo de este capítulo será desarrollar la información necesaria sobre cada uno de los recursos que se utilizarán en este proyecto. Gracias a la unión de todos estos, se podrá llevar a cabo el trabajo de forma adecuada. Los recursos englobarán los softwares utilizados, los hardware con los que se ha trabajado, los lenguajes de programación con los que se ha desarrollado el proyecto, y por último, una breve explicación sobre los protocolos de comunicación usados. 2.1 Software Durante el desarrollo de este trabajo se utilizarán diversos softwares, los cuales jugarán un papel fundamental en cada fase del proyecto y se encargarán de realizar las distintas tareas necesarias para poder construir el sistema de neuroestimulación deseado. 2.1.1 Vivado Vivado es un software de Xilinx para desarrollar diseños a través de lenguajes de descripción de hardware (HDL). Esta herramienta permite sintetizar, implementar y simular los diseños creados, orientado principalmente a la posterior programación de dispositivos FPGA o SoC (System on Chip) [1]. En el caso concreto de este proyecto, será el software principal utilizado para crear el diseño, analizarlo y posteriormente ejecutarlo mediante una simulación. De este modo se podrá verificar su funcionamiento antes de implementarlo en la FPGA mediante la generación del bitstream. 2.1.2 Vitis HLS Vitis HLS (High-Level Synthesis) es un software de Xilinx incluido en el paquete de Vivado, que permite desarrollar diseños de hardware a partir de código de alto nivel como C o C++ [2]. Esto tiene la ventaja de permitir a programadores realizar diseños sin tener la necesidad de conocer a fondo el diseño de hardware. Para el presente proyecto, se utilizará esta herramienta para diseñar dos de los bloques principales del diseño, a los que se accederá a través de protocolo AXI-Lite. Gracias a esta herramienta se han generado estos bloques mediante lenguaje C++, y posteriormente se han integrado en el diseño de Vivado. 2.1.3 Jupyter Notebook Jupyter notebook forma parte de un proyecto llamado Jupyter, el cual es un entorno de software libre, estándares E Recursos Utilizados 4 abiertos y servicios web para informática interactiva en distintos lenguajes de programación [3]. Concretamente Jupyter notebook es una aplicación web interactiva con la que poder crear y compartir documentos que combinan código ejecutable, texto, visualizaciones y otros tipos de elementos. Esta herramienta será utilizada principalmente para realizar la comunicación entre el microprocesador y la lógica programable de la PYNQ Z2. Entre estas tareas, destacarán las siguientes: • Transferir datos desde el microprocesador al tejido FPGA de la PYNQ. • Leer los diferentes bloques que están implementados en la FPGA. • Obtener las direcciones de memoria de los diferentes bloques del diseño. 2.2 Hardware 2.2.1 PYNQ Z2 El principal hardware elegido para este proyecto es la PYNQ Z2 de AMD [4]. Esta tarjeta de desarrollo basada es un SoC (System on Chip), la cual combina: • PL (Programmable Logic System): Se entiende PL como la parte lógica programable de un dispositivo, en este caso la FPGA. Concretamente la PYNQ lleva empotrado el modelo Zynq-700 SoC XC7Z020- 1CLG400. • PS (Processing System): Sección de procesamiento principal, donde se ubica el microprocesador. En este caso, el dispositivo cuenta con un procesador ARM dual-core Cortex-A9. A continuación, se podrá observar una imagen de la PYNQ Z2. Figura 2-1. PYNQ Z2 5 5 Sistema de neuroestimulación basado en PYNQ Como características principales de este hardware, se pueden destacar las siguientes: • Procesador y FPGA. Gracias a esta combinación, es posible ejecutar acciones en el procesador ARM y paralelamente realizar tareas más exigentes en el tejido FPGA. Esto permite que este dispositivo sea adecuado para aplicaciones de alto rendimiento. En el proyecto actual, será en el procesador donde se ejecuten las tareas necesarias para trasmitir los datos a la FPGA, que será la que se encargue de procesar toda la lógica del sistema. • Conectividad. Tiene un amplio rango de puertos, entradas, salidas e interfaces. Lo que convierte el dispositivo en un hardware muy versátil para diseñar todo tipo de proyectos. Concretamente en este trabajo, se utilizarán sobre todo los puertos Pmod, los cuales serán la salida para los datos. • Memoria: o 512 MB de memoria DDR3. Esta es la memoria principal que usa la PYNQ para almacenar y procesar datos. o 128 Mbit Quad-SPI Flash. Memoria no volátil utilizada para almacenar configuraciones de arranque. Esta tecnología permite leer y escribir en esta memoria de manera más rápida que con un SPI convencional. o Conector de Micro SD: Este conector permite utilizar almacenamiento adicional, contener el sistema operativo Linux y almacenar datos como scripts de Python o archivos de Jupyter Notebook. Estos últimos serán los que se utilicen para interactuar con la FPGA. 2.2.2 PmodDA2 El PmodDA2 es un módulo convertidor de digital a analógico de 2 canales y 12 bits, basado en el DAC12S101 de Texas Instrument [5]. Entre sus características se pueden destacar: • Dos canales de conversión simultáneos. • Consumo bajo de energía. • Conector Pmod de 6 pines con interfaz GPIO. Este módulo servirá para conectarlo a la salida del Pmod de la PYNQ Z2 y así conseguir convertir la señal digital que generemos a una señal analógica. Para ello, será necesario utilizar el protocolo SPI (Serial Peripheral Interface) 2.2.3 Osciloscopio Para poder realizar la verificación de que el sistema funciona de forma correcta, se utilizará un pequeño osciloscopio modelo SCO2. Este permitirá plasmar la señal final generada a la salida del PmodDA2. Figura 2-2. PmodDA2 Figura 2-3. Osciloscopio Diseño 12 Figura 3-5. Simulación del bloque trigger. Protocolo AXI Se pueden observar los cincos canales de los que se hablaba anteriormente en la definición del protocolo. Además, se puede ver el orden que sigue el protocolo en el proceso de escritura, por orden: Write Access, Write Data y Write Response. Tal y como se define en la Figura 3-6. Gracias al diseño y simulación del bloque trigger, se consiguen afianzar conceptos tanto como con las herramientas Vivado y Vitis HLS, como con el protocolo AXI. Todo esto, será de gran ayuda para el resto del proyecto. 3.2 Diseño de bloques y simulación por fases En este punto se desarrollará el diseño de la arquitectura a bajo nivel, pasando por cada bloque implementado y definiendo su funcionamiento. A su vez, se realizará la simulación de cada bloque. En el caso de este proyecto, se realizará una simulación por cada bloque que se añada al sistema, así se asegurará el correcto funcionamiento por cada fase del proyecto. Entonces, a continuación, se mostrará una imagen del sistema completo para simulación, dividido por subsistemas con los que se han realizado las distintas simulaciones: 13 13 Sistema de neuroestimulación basado en PYNQ Figura 3-6. Diseño dividido por subsistemas Diseño 14 3.2.1 Trigger Aprovechando la prueba de concepto realizada anteriormente, será este mismo trigger el que utilicemos para nuestro sistema. Este bloque será el encargado de indicar que debe comenzar la estimulación. Como ya se describió tanto el diseño, como la verificación del bloque, este punto queda completado con la prueba de concepto. 3.2.2 Stimulation control Diseño El stimulation control será el segundo bloque generado para el proyecto, y al igual que el trigger, será diseñado con Vitis HLS. El diseño de este bloque será el siguiente: Figura 3-7. Bloque stimulation control Los datos serán recibidos por el bloque, y este se encargará de dividirlos en distintos datos para su posterior uso. A continuación, se detallará cada puerto del stimulation control: Tabla 3-1. Descripción del bloque stimulation control IN ap_clk Señal de reloj ap_rst Señal de reset s_axi_control Señal de entrada de 32 bits definida por el usuario OUT vld Dato válido channel Canal cmd Comando freq Frecuencia 15 15 Sistema de neuroestimulación basado en PYNQ data Datos Básicamente, el stimulation control recibirá una señal de 32 bits a través del AXI, donde estará toda la información para el funcionamiento del neurosestimulador, y este encargará de separar este dato y dividirlo en las distintas señales que tenemos como salida. Luego, estas señales llegarán al channel manager, que será el encargado de realizar las acciones oportunas. Pero de momento, con saber que el stimulation control se encarga simplemente de dividir los datos, será suficiente para su entendimiento. Simulación Al igual que con el trigger, para simular este bloque también hará falta la ayuda del AXI Verification VIP, como se puede observar en la Figura 3-6. Se extraerá un fragmento de la simulación de Vivado para comprobar el funcionamiento del stimulation control: Figura 3-8. Simulación del stimulation control Como se puede comprobar, a la llegada de cada dato, el bloque se encarga de dividirlo en los datos necesarios para asignarlos a las salidas correspondientes. Con esta prueba, es suficiente para comprobar el funcionamiento de este bloque, ya que al igual que el trigger, estos bloques se encargan de poner los datos a la salida indistintamente de lo que llegue a la entrada. Al contrario que el channel manager, que tendrá la responsabilidad de actuar en consecuencia de los datos que reciba, lo cual se detallará a continuación. 3.2.3 Channel manager Diseño El gestor de canales será el primer bloque desarrollado con VHDL en Vivado. A este diseño llegarán todas las señales desde los bloques anteriores, trigger y stimulation control: Diseño 16 Figura 3-9. Diseño del bloque channel manager Este bloque estará definido por los siguientes puertos: Tabla 3-2. Descripción del bloque channel manager IN clk Señal de reloj rst Señal de reset p_in Bit 0 de la señal de salida p_out del trigger ap_vld Señal de dato válido de la salida del trigger vld Dato válido. Indicará que el dato recibido es válido. channel Canal cmd Comando Será la señal encargada de que el channel manager realice la acción deseada. freq Frecuencia. Indicará la frecuencia con la que se mandarán las muestras. data Datos OUT 17 17 Sistema de neuroestimulación basado en PYNQ data_channel Datos. Será la señal que envíe los datos al canal indicado. Valdrá exactamente lo mismo que la entrada data. N_channel Número de canal. Será la señal que indique sobre que canal estamos actuando. Valdrá lo mismo que la entrada channel. lpd Looped. Será la señal que, junto con channel, indicará que un canal está “loopeado”, es decir, que estimulará cíclicamente. ena Enabled. Será la señal que, junto con channel, indicará que una canal está habilidado. rst_rd_ptr Reset read pointer. Esta señal será el reset del puntero de lectura del canal deseado, por lo que actuará junto con channel. rst_wr_ptr Reset write pointer. Esta señal será el reset del puntero de escritura del canal deseado, por lo que actuará junto con channel. data_valid Dato válido. Esta señal se usará para indicar que el dato es válido para escribir en el canal deseado. send_next_sample Envía próxima muestra Esta señal actuará en consecuencia de la entrada freq, dependiendo de su valor, enviará las muestras con la frecuencia deseada. startstop Inicio-pausa. Esta señal indicará cuando empezará la estimulación o la parará cuando se desee. El channel manager será una pieza clave en el diseño del sistema, ya que deberá realizar las acciones necesarias dependiendo de los datos que le lleguen por parte del usuario. Principalmente, este bloque se fijará en cmd para tomar la acción que corresponda, se comportará como un intérprete de comandos. Para un mejor entendimiento del funcionamiento del bloque, se definirán las acciones existentes: Diseño 18 Tabla 3-3. Definición de comandos cmd Comando Acción 000 CMD_SET_LOOPED Comando looped o Si el bit menos significativo (LSB) de data es 1 → lpd = 1, junto con N_channel, indicarán al correspondiente canal que estará en modo “loop”, es decir, que una vez termine de estimular, debe empezar de nuevo. o Si el bit menos significativo de data es 0 → lpd = 0, junto con N_channel, indicarán al correspondiente canal que no estará en modo “loop”, es decir, que terminará de estimular cuando se acaben los datos. 001 CMD_SET_ENABLED Comando enabled o Si el bit menos significativo de data es 1 → ena = 1, junto con N_channel, indicarán al canal correspondiente que estará habilitado, es decir, una vez llegue la señal startstop, estimulará. o Si el bit menos significativo de data es 0 → ena = 0, junto con N_channel, indicarán al canal correspondiente que estará inhabilitado, es decir, una vez llegue la señal startstop, no estimulará. 010 CMD_RESET_WR_PTR Comando para reiniciar el puntero de escritura rst_wr_ptr = 1, junto con N_channel, indicarán al canal correspondiente que reinicie su puntero de escritura 011 CMD_RESET_RD_PTR Comando para reiniciar el puntero de escritura rst_rd_ptr = 1, junto con N_channel, indicarán al canal correspondiente que reinicie su puntero de escritura 100 CMD_ISDATA Comando de escritura data_valid = ‘1’, junto con N_chanel, indicarán al canal correspondiente que escriba el data en su memoria 101 CMD_NOP No se realiza ninguna acción Simulación A continuación, se simulará el comportamiento del channel manager junto a los bloques anteriores, este será una de las simulaciones más importantes, ya que será el que tenga que interpretar la lógica que procede de los bloques anteriores y actuar en base a ello. Entonces, no valdrá con realizar un testbench con unos estímulos cualquiera, sino que tendrán que enviarse los datos según el comportamiento que se desee. Se realizará la simulación con un mismo testbench para las próximas simulaciones, donde el objetivo será realizar las siguientes acciones: a. Enviar 16 datos al canal 1. b. Canal 1 looped 19 19 Sistema de neuroestimulación basado en PYNQ c. Canal 1 enabled d. Enviar 16 datos al canal 2 e. Canal 2 looped f. Canal 2 enabled g. Iniciar la neuroestimulación Se mostrará un fragmento de la simulación, donde ocurran varios comandos (cmd), para verificar que el channel manager está funcionando correctamente: Figura 3-10. Simulación del channel manager 1 En la simulación de vivado se pueden observar tres acciones, con tres comandos distintos (cmd). 1. Acción 1: Tabla 3-4. Simulación del channel manager. Acción 1 IN OUT Acciones vld = 1 Dato recibido es válido cmd = 4 CMD_ISDATA channel = 1 data_valid = 1 El dato es válido para escribir data_channel = 0x008f Dato N_channel = 1 Dato válido para escribir en el canal 1 Diseño 20 Canal 1 data = 0x008f Datos Canal 1 2. Acción 2: Tabla 3-5. Simulación del channel manager. Acción 2 IN OUT Acciones vld = 1 Dato recibido es válido cmd = 0 CMD_SET_LOOPED data = 0x0001 LSB = 1 channel = 1 Canal 1 N_channel = 1 Canal 1 lpd = 1 Looped Indica que el canal 1 estará en modo “loop” 3. Acción 3: Tabla 3-6. Simulación del channel manager. Acción 3 IN OUT Acciones vld = 1 Dato recibido es válido cmd = 1 CMD_SET_ENABLED data = 0x0001 LSB = 1 channel = 1 Canal 1 N_channel = 1 Canal 1 ena = 1 Looped Indica que el canal 1 estará habilitado Se extraerá otro fragmento de la silmulación, para comprobar el funcionamiento de send_next_sample y startstop: 21 21 Sistema de neuroestimulación basado en PYNQ Figura 3-11. Simulación del channel manager 2 Como se puede apreciar en el cronograma, dependiendo del valor de freq a la entrada, el channel manager enviará la señal de mandar la próxima muestra con una cierta frecuencia, a través de la señal send_next_sample. En el sistema se han implementado tres frecuencias para enviar los datos, las cuales serán parametrizables a través del bloque channel manager. Básicamente, a partir del valor que le asignemos al parámetro CLK_FREQ_HZ, se crearán tres frecuencias distintas, y la frecuencia que se aplique dependerá de la entrada freq: Tabla 3-7. Tabla de frecuencias freq Frecuencia 000 CLK_FREQ_HZ / 30000 001 CLK_FREQ_HZ / 50000 010 CLK_FREQ_HZ / 60000 Volviendo al cronograma, se puede observar que la señal sample_clk (interna del channel manager) es un vector de 3 bits, que cada uno corresponde con una de las frecuencias. Entonces, dependiendo del valor de freq, send_next_sample se alineará con esa frecuencia. La imagen presenta como va cambiado a frecuencia en consecuencia al valor de freq. En cuanto al comportamiento de startstop, se puede observar que se activa cuando p_in = 1 y ap_vld se activa, y luego, pasa a cero cuando p_in = 0 y ap_vld se activa. Este funcionamiento es el esperado para el startstop. 3.2.4 Channels Diseño El siguiente bloque será el encargado de configurar y guardar los datos en los canales, y posteriormente, mandar los datos de cada canal. Dentro de este, habrá un número de canales personalizable por el usuario, a través de un generic llamado CHANNELS. En caso de ampliar los canales, se deberá añadir también la cantidad correspondiente de PmodDA2, que será uno por cada dos canales. En el caso del actual sistema desarrollado, se dispondrá de dos canales, ya que serán los que se podrán comprobar posteriormente con el osciloscopio. Verificación 28 Figura 4-2. Simulación del sistema completo Como se puede observar, los datos de cada canal salen por el puerto MOSI correspondiente mediante el protocolo serie (SPI). Gracias a esta simulación, (al igual que en su momento con la simulación del trigger para entender el protocolo AXI) se puede demostrar el funcionamiento del protocolo SPI con un ejemplo práctico. Con esta última verificación del sistema completo, se puede confirmar que, al menos a ojos de la simulación, el neuroestimulador diseñado funciona correctamente. 4.2 Resultados experimentales en la PYNQ Z2 4.2.1 Implementación en la FPGA A la hora de implementar el diseño en el dispositivo, no se ha conseguido plasmar el resultado obtenido en la simulación. Se ha estudiado todo el diseño al detalle, depurando cada bloque y corrigiendo todos los errores que pudieran estar provocando este “miss match” entre la simulación y resultado experimental. 4.2.2 Capacidad de la FPGA La idea principal en este punto es comprobar la capacidad de canales que la PYNQ Z2 sería capaz de soportar. Para ello se realizarán unos cálculos teóricos de los resultados que se deberían obtener, dependiendo del número de canales que se implementen o el ancho de direcciones. Para llevar a cabo esta comparación entre lo teórico y lo experimental, se deben analizar las características técnicas del dispositivo. El hardware PYNQ Z2 está basado en la FPGA Zynq700, concretamente el part number es XC7Z020. Según esta referencia, se pueden encontrar las características en la ficha técnica correspondiente: 29 29 Sistema de neuroestimulación basado en PYNQ Figura 4-3. Especificaciones del hardware de la familia Zynq-700 En lo que a Block RAM respecta, se puede obtener la siguiente información: Tabla 4-1. Block RAM Zynq-700 Device Name Z-7020 Part Number XC7Z020 Block RAM (#36 Kb Blocks) 4.9 Mb (140) Es decir, esta FPGA tiene 140 bloques de 36Kb, lo que corresponde a 4.9 Mbits de capacidad sumando la totalidad de todos los bloques de memoria. Después de realizar la síntesis del sistema con un solo canal y ver la utilización de memoria se ha obtenido la siguiente tabla: Figura 4-4. Recursos utilizados por la FPGA Como se puede apreciar, con un solo canal de 1024 bits de ancho de banda y 16 bits de ancho de dato, la ocupación de memoria es de 0.5 de 140 disponibles. Por lo que sería un 0.36% de utilización de Block RAM. Verificación 30 Realizando una estimación del número máximo de canales que se podrían implementar en un dispositivo como el de este proyecto, se puede considerar que sería del orden de 90 canales. Teniendo en cuenta que la mayoría del resto de recursos serían comunes para todos los bloques. 5 CONCLUSIONES Y TRABAJOS FUTUROS 5.1 Conclusiones CONCLUSIÓN TÉCNICA Como conclusión personal, quiero destacar el nivel de aprendizaje obtenido en este proyecto. Gracias a este trabajo he podido adquirir conocimientos, algunos de ellos bastante más profundos de lo que esperaba, sobre software, hardware, protocolos de comunicación y plataformas. No tengo dudas de que todo este aprendizaje me servirá para un futuro. 5.2 Trabajos futuros Existen diversas vías o caminos en los que se podría seguir investigando en la línea de este proyecto. Desde actividades que no ha dado tiempo a realizar, o simplemente otras competencias que no entran dentro del alcance de este trabajo: 1. Verificación del sistema. Aunque en este proyecto se ha realizado la verificación por simulación, esto no es suficiente para cubrir todos los errores posibles que pudieran ocurrir. Por lo que, sería interesante realizar una verificación con alguna metodología de verificación como UVVM (Universal VHDL Verification Methodology), OSVVM (Open Source VHDL Verification Methodology) o Uunit, entre otras. 2. Protocolo de compresión y descompresión de datos basado en la transformada wavelet. En caso de tener una gran cantidad de datos, esta técnica sería idónea para reducir esta cantidad de datos que se deben almacenar o transmitir. Esta transformada es especialmente útil en señales que tienen redundancia en el dominio de la frecuencia. 3. Diseño de interfaz gráfico. En este trabajo los estímulos se han generado directamente a través números de 32 bits, sabiendo para qué se utiliza cada uno de los bits o grupos de bits. Pero como trabajo futuro, sería interesante desarrollar una interfaz gráfica para el usuario, orientada al personal técnico de laboratorio de investigación en ingeniería biomédica. Una interfaz completa y funcional donde el propio usuario pudiera configurar el neuroestimulador como considere oportuno. 4. Multiplicación de recursos. Está comprobando que con una FPGA se puede llegar a conseguir un número elevado de canales y llegar a realizar una estimulación con todos los canales en paralelo. Pero ¿y si se elevara el número de FPGAs? Se podría llegar a implementar un sistema mayor, con muchos más canales. Aunque, evidentemente, supondría tener que sincronizar todas las FPGAs entre ellas, muchos más recursos, front-ends, etc. 5. Generar estímulos más grandes que la memoria disponible. Otra futura característica para implementar sería generar los estímulos más grandes, tanto que sean mayores que la memoria disponible. En este caso los estímulos deberían generarse por partes y transferirlos al channel manager, entonces este iría generando los estímulos oportunos, pero entonces, habría que asegurarse de que no hay retrasos en los datos para que esto no se traduzca en inestabilidades en la señal generada. Seguramente habría que implementar un mecanismo de sincronización donde los canales avisen al microprocesador un tiempo antes de necesitar más datos, y que cantidad. De esta forma el software generaría nuevamente más datos, y los enviaría a los canales. 6. Implementar la parte digital del sistema en un chip. Una opción interesante sería implementar toda la parte del diseño digital, es decir, la parte implementada en el tejido FPGA, en un chip. Para ello se 33 33 Sistema de neuroestimulación basado en PYNQ podría utilizar la plataforma Tiny Tapeout, un proyecto educativo que simplifica el diseño y fabricación de chips personalizados. Permite a los usuarios crear sus propios diseños utilizando herramientas digitales y producirlos en chips de silicio. Cada una de estas opciones serían de gran interés a desarrollar como trabajos futuros, con el neuroestimulador implementado en este trabajo como punto de partida. REFERENCIAS [1] «AMD Vivado,» [En línea]. Available: https://www.amd.com/es/products/software/adaptive-socs-and- fpgas/vivado/vivado-buy.html. [Último acceso: 07 11 2024]. [2] «AMD Vitis HLS,» [En línea]. Available: https://www.amd.com/es/products/software/adaptive-socs-and- fpgas/vitis/vitis-hls.html. [Último acceso: 07 11 2024]. [3] «Jupyter Notebook,» [En línea]. Available: https://jupyter.org/. [Último acceso: 7 11 2024]. [4] «AMD PYNQ Z2,» [En línea]. Available: https://www.amd.com/es/corporate/university-program/aupboards/pynq-z2.html. [Último acceso: 07 11 2024]. [5] «Diligent,» [En línea]. Available: https://digilent.com/reference/pmod/pmodda2/referencemanual?srsltid=AfmBOoqzVLjV9XOPk6dpSf2YVXuax-ap8HzVcAZBUfH29MNulSREgOzU. [Último acceso: 07 11 2024]. [6] «All about circuits,» [En línea]. Available: https://www.allaboutcircuits.com/technical-articles/hardwaredescription-langauge-getting-started-vhdl-digital-circuit-design/. [Último acceso: 07 11 2024]. [7] «Tech target,» [En línea]. Available: https://www.techtarget.com/searchdatamanagement/definition/C. [Último acceso: 08 11 2024]. [8] «Verien,» [En línea]. Available: http://www.verien.com/axi-reference-guide.html. [Último acceso: 08 11 2024]. [9] «Circuits Basics,» [En línea]. Available: https://www.circuitbasics.com/basics-of-the-spi- communication-protocol/. [Último acceso: 08 11 2024]. [10] «Prodigy Technovations,» [En línea]. Available: https://www.prodigytechno.com/spi-protocol. [Último acceso: 08 11 2024].