diff --git a/Anexos/Codigo.tex b/Anexos/Codigo.tex index a825e47..3356353 100755 --- a/Anexos/Codigo.tex +++ b/Anexos/Codigo.tex @@ -4,3 +4,5 @@ \chapter{Código} % Título del Anexo \label{Codigo} % Etiqueta \ref{Planos} Aqui irá el código del diseño. + +%Enlace al repo de github diff --git a/Capitulos/Conclusiones.tex b/Capitulos/Conclusiones.tex index 2c8589b..f8e6b6f 100755 --- a/Capitulos/Conclusiones.tex +++ b/Capitulos/Conclusiones.tex @@ -10,3 +10,6 @@ \section{Conclusiones alcanzadas} \section{Líneas futuras} Aqui irán las líneas futuras. + +%Externalizar por completo los calculos referentes a las RNAs y tener un un modelo completo de RNA computado por un enfoque distribuido. Mejorar la gestion de memoria. Hasta ahora hardcodeada. Posibilidad de usar la DDR (controlador ddr de litex) de la Arty, jtag, debug Usb (issue 38). La unica aproximación se ha hecho utilizando la spi (issue 47) relaizada con exito pero no nos vale (comentario de umarcor) +%Añadir la compilación de software a CI diff --git a/Capitulos/Desarrollo.tex b/Capitulos/Desarrollo.tex index 0d3e7a2..92b6bed 100644 --- a/Capitulos/Desarrollo.tex +++ b/Capitulos/Desarrollo.tex @@ -29,10 +29,235 @@ \section{Selección del microcontrolador} En adición a todo lo mencionado, este microcontrolador cuenta con un \textit{datasheet} \cite{neorv32-ds} y una \textit{user guide} \cite{neorv32-ug} realizadas por el autor y actualizadas a la par que el código del proyecto, las cuales destacan por su calidad. Teniendo en cuenta todas estas consideraciones, el NEORV32 es el procesador seleccionado para este proyecto. -\section{Workflow} +\hspace{10 mm} + +\section{\textit{Workflow}} \label{Workf} +Las herramientas EDA FLOS y las propietarias/comerciales no son ecosistemas aislados. +Al contrario, en los últimos años se han visto colaboraciones de proyectos \textit{Open Source} con iniciativas privativas. +En este sentido, se puede destacar la integración de la herramienta RapidWright \cite{gh:rapid} a la \textit{Suite} de diseño Vivado. +En concreto, este proyeto \textit{Open Source} desarrollado por \textit{AMD Research and Advanced Development} tiene como objetivo permitir a los usuarios avanzados una mayor flexibilidad a la hora de personalizar sus soluciones mediante una metodología de diseño utilizando módulos pre-implementados. +En adición a esto, se han realizado concursos \cite{contest} patrocinados por AMD con el objetivo de promover y demostrar que el \textit{FPGA Interchange Format} (FPGAIF - Formato de Intercambio de FPGA) \cite{FPGAIF} es una representación intermediaria eficiente y robusta para trabajar en problemas de \textit{backends} de FPGAs, incluso a escala industrial. +Además, este tipo de iniciativas también tratan de fomentar la innovación de algoritmos de enrutamiento de FPGAs que den prioridad al tiempo de ejecución, con objeto de posibilitar su aplicación en la emulación de ASICs. +Cabe destacar que el FPGAIF es un estándar de formato de intercambio diseñado para proporcionar toda la información necesaria mediante la cual realizar el \textit{place and route} en un contexto \textit{Open Source}. +En la misma línea, Siemens ha observado un crecimiento saludable entorno a la \textit{Open Source VHDL Verification Methodology} (OSVVM - Metodología de Verificación VHDL de Código Abierto) \cite{osvvm} y la \textit{Universal VHDL Verification Methodology} (UVVM - Metodología de Verificación Universal VHDL) \cite{uvvm} desde 2018, lo que en sus propias palabras \say{es alentador} \cite{wilson-research}. +Por lo tanto, a la vista de estos ejemplos, podemos afirmar que los comerciales tradicionales de herramientas EDA están empezando a facilitar el uso de herramientas FLOS e incluso a integrar parte o la totalidad de las mismas en sus propuestas comerciales. +Este hecho refleja un futuro híbrido en lo referente al ecosistema de herramientas para FPGAs. + +\begin{figure}[h!] + \centering + \includegraphics[width=14cm]{Figuras/workflow.pdf} + \caption{\textit{Workflow} del \textit{Setup} personalizado.} + \label{fig:workf} +\end{figure} + +Atendiendo a este nuevo paradigma híbrido de herramientas, en el presente trabajo de investigación se propone el uso tanto de herramientas FLOS como privativas. +Como se observa en la figura \ref{fig:workf}, el flujo de trabajo propuesto es el siguiente: + +\begin{itemize} + \item Compilación: respecto a la compilación de software en C que posteriormente se cargará en la memoria de instrucciones del NEORV32, se emplea exclusivamente la herramienta FLOS GCC. + \item Implementación: respecto a las implementaciones en placa de los diseños, se efectúan todas ellas tanto para la Arty A7 35T como para la Arty A7 100T y mediante dos vías paralelas: + \begin{itemize} + \item Haciendo uso del conjunto de herramientas FLOS: GHDL \cite{gh:ghdl}, yosys \cite{gh:yosys}, GHDL yosys plugin \cite{gh:ghdl-plugin}, nextpnr-xilinx \cite{gh:nextpnr} y prjxray \cite{gh:prjxray} para realizar la elaboración, la síntesis y el \textit{place and route} y de la herramienta openFPGALoader \cite{gh:openFPGALoader} para cargar el \textit{bitstream} en la placa. + \item Haciendo uso de la \textit{Suite} de diseño privativa Vivado. + \end{itemize} + \item Simulación: respecto a las simulaciones realizadas a lo largo de las secciones \ref{Carac} y \ref{Integ} se emplea principalmente el \textit{framework} FLOS VUnit \cite{gh:vunit}, con el cual se realizan todas ellas. +No obstante, también se utiliza Vivado en ciertas ocasiones. +En concreto, en los ensayos en los que se hace uso de la funcionalidad ILA. +Esta funcionalidad se ha utilizado, por ejemplo, para testear la correcta operatividad de un \textit{wrapper} Wishbone. +\end{itemize} + +El conjunto de herramientas descritas en la explicación de este flujo de trabajo no solo se utilizan a nivel local, también se utilizan, todas o parte de ellas, en \textbf{integración continua (CI)} en repositorios \textit{online}, tanto en el GitLab del grupo de investigación como en el GitHub propio. +Para ello, se utilizan varios \textbf{contenedores}. +Para la generación de \textit{bitstream} mediante herramientas FLOS, se utiliza el contenedor mencionado en la sección \ref{ben}, el cual es generado a su vez en CI. +Este contenedor se utiliza en la integración continua tanto del repositorio ubicado en GitLab como del ubicado en GitHub. +Para la generación de \textit{bitstream} mediante Vivado, se utiliza una contenedor que solamente es accesible por los ordenadores del laboratorio del grupo de investigación, el cual está alojado en nuestro servidor Orion. +Esto es debido a que al ser un software privativo el contenedor no puede ser accesible sin licencia, es por ello que la generación de \textit{bitstream} mediante esta vía solo está disponible en la integración continua del repositorio del grupo (GitLab). +Para realizar los ensayos en simulación, se utilizan principalmente dos contenedores de VUnit. +El \href{https://console.cloud.google.com/gcr/images/hdl-containers/global/sim/osvb}{gcr.io/hdl-containers/sim/osvb:latest} con GHDL compilado con llvm como \textit{backend} y el \href{https://hub.docker.com/layers/ghdl/vunit/mcode-master/images/sha256-e32029c5be70a5fa0fc94bffd15d72fa8b84ad8aaf2dc7cfa8ab8324ef733ed0?context=explore}{docker.io/ghdl/vunit:mcode-master} con GHDL compilado con mcode como \textit{backend}. +Esto se debe a que la funcionalidad \href{https://github.com/stnolting/neorv32/discussions/886}{\textit{external names}}, para capturar señales de jerarquías inferiores, solo es soportada en GHDL si este está compilado con el \textit{backend} mcode. +En definitiva, haciendo uso de estos contenedores mediante la metodología de integración continua, se consigue generar de forma automatizada los resultados de todas las simulaciones, así como la generación de todos los \textit{bitstreams}, cada vez que se hace un \textit{push} al repositorio. +Cabe destacar que la compilación de software solo se realiza en local, aunque también se utiliza un contenedor \cite{gh:sim-conatiner}, no está automatizada en integración continua. + +\subsection{Cargar software en el NEORV32} + +Antes de entrar en los detalles del acoplamiento de periféricos \textit{custom}, se procede a realizar un repaso de como cargar un software en C al \textit{softcore} NEORV32. +Como se ha mencionado, el proyecto NEORV32 proporciona herramientas para realizar la compilación cruzada desde Linux a la arquitectura RISC-V. +Estas herramientas están acompañadas de archivos \textit{Makefiles} mediante los cuales se permiten añadir argumentos al comando \textit{Make}, con objeto de, entre otras cosas, proporcionar el programa compilado en diferentes formatos de salida. +A lo largo de esta sección, nos centraremos en tres de estos formatos: + +\begin{itemize} + \item Ejecutable, \textit{exe} (.bin) + \item app\_image (.vhd) + \item Hexadecimal (.hex) +\end{itemize} + +Cada una de estas salidas tiene la misma información, el programa compilado. +No obstante, cada una de ellas puede utilizarse para cargar el software en la IMEM (memoria de instrucciones) en diferentes puntos del \textit{Workflow}: + +\begin{itemize} + \item El \textit{exe} se puede cargar en el NEORV32 una vez que esté ejecutándose en la FPGA. Esta transferencia se realiza a través del \textit{bootloader}. + \item La app\_image remplaza el contenido por defecto de una de las fuentes RTL del diseño del NEORV32, de modo que su contenido se codifica cuando este se sintetiza. + \item El archivo .hex se lee durante la síntesis, por lo que es equivalente a la solución de la app\_image, pero no requiere modificar las fuentes RTL cada vez que se actualiza el software a cargar. +\end{itemize} + +Estas opciones se resumen en la siguiente tabla: + +\begin{table}[h!] +\centering +\caption{Tres formas de introducir software en la IMEM.} +\label{tab:2} +\begin{tabular}{|c|c|c|c|} +\hline +\textbf{Formato} & \textbf{Comando} & \textbf{Descripción} & \textbf{Bootloader} \\ \hline +.bin & make exe & \begin{tabular}[c]{@{}c@{}}Después de la implementación,\\ cargar el exe mediante la CMD\end{tabular} & Habilitado \\ \hline +.vhd & make image & \begin{tabular}[c]{@{}c@{}}Antes de la síntesis, \\ sustituir la app\_image por defecto\end{tabular} & Deshabilitado \\ \hline +.hex & make hex & Durante la síntesis, leer del .hex & Deshabilitado \\ \hline +\end{tabular} +\end{table} + +\subsubsection{\textit{Bootloader}} +\label{boot} + +El NEORV32 viene por defecto con un \textit{bootloader} que se encarga de establecer la comunicación serie vía UART y generar una CMD visible desde terminales como CuteCom \cite{gh:cutecom}, \href{https://man.openbsd.org/cu.1}{cu}, o \href{https://www.gnu.org/software/screen/}{screen} en GNU/Linux. +En este sentido, hay tres formas posibles de proceder: + +\begin{itemize} + \item Deshabilitar el \textit{bootloader} y cargar/iniciar un programa desde la app\_image o desde un archivo hexadecimal. + \begin{itemize} + \item No se utiliza el \textit{bootloader}. + \end{itemize} + \item Habilitar el \textit{bootloader} y cargar/iniciar un programa a través del \textit{Autoboot}. + \begin{itemize} + \item Después del \textit{reset}, cuando el \textit{bootloader} está habilitado, la primera secuencia que ocurre es el \textit{Autoboot}. + \item La secuencia de \textit{Autoboot} intenta obtener una imagen de arranque válida desde la flash SPI externa. + \item Si se encuentra una imagen de arranque válida que se pueda transferir correctamente a la IMEM (memoria de instrucciones), se inicia automáticamente la aplicación. + \item Si han pasado 8 segundos y no se ha detectado ninguna flash SPI o no se encuentra ninguna imagen de arranque válida, se mostrará el código de error \say{ERR EXE}, bloqueando la ejecución del \textit{bootloader}. + \item Durante esos 8 segundos, se puede detener la secuencia del \textit{Autoboot} pulsando cualquier tecla. +De esta manera, se pone a disposición una CMD lista para recibir comandos. + \end{itemize} + \item Habilitar el \textit{bootloader} y cargar/iniciar un programa a través de comandos en la CMD. +Los comandos soportados son los siguientes: + \begin{itemize} + \item \say{h} - Muestra el texto de ayuda. + \item \say{r} - Reiniciar el \textit{bootloader}. + \item \say{u} - Cargar un programa en formato ejecutable (\textit{neorv32\_exe.bin}) a la IMEM. + \item \say{s} - Almacenar un ejecutable en flash SPI. + \item \say{l} - Cargar un ejecutable desde flash SPI. + \item \say{x} - Arrancar un programa desde flash a través de XIP. + \item \say{e} - Iniciar un programa almacenado en la IMEM. + \end{itemize} +\end{itemize} + +Para elegir una de estas tres formas de proceder, se debe entender que el \textit{bootloader} es útil/necesario cuando: + + \begin{itemize} + \item La FPGA utilizada no permite inicializar la memoria en el \textit{bitstream}. +En consecuencia, no es posible cargar/arrancar programas a través de la app\_image. +Este es el caso de las FPGAs con SPRAM, como la Lattice ICE40 (UP3K, UP5K). + \item Múltiples programas deben ser cargados/arrancados durante el desarrollo, sin resintetizar el diseño. + \end{itemize} + +En la figura \ref{fig:boot} se muestra como cargar/iniciar un programa ejecutable (.exe) al NEORV32 mediante el \textit{bootloader}. +Concretamente, en ese caso se utiliza la terminal CuteCom \footnote {En CuteCom, el archivo que se carga a la terminal debe ser de tipo \textit{Plain} (como se muestra en la figura \ref{fig:boot}), de lo contrario se dará el error \say{ERR EXE}.}, empleando sucesivamente los comandos \say{u} (\textit{upload} - cargar) y \say{e} (\textit{execute} - ejecutar). + +\begin{figure}[h!] + \centering + \includegraphics[width=14cm]{Figuras/cutecom_cmd_upload.png} + \caption{Cargar un \textit{exe} a través del \textit{bootloader} de NEORV32 (terminal CuteCom).} + \label{fig:boot} +\end{figure} + + +\subsubsection{Habilitar/Deshabilitar el \textit{Bootloader}} + +Si el \textit{bootloader} no es útil/necesario para nuestra aplicación tendremos que considerar lo siguiente. +La IMEM se puede implementar de dos formas, como una RAM vacía o como una ROM inicializada a través del archivo que contiene el programa compilado, ya sea la \textit{neorv32\_application\_image.vhd} o el hexadecimal. +Con el genérico \mintinline[breaklines]{vhdl}{IMEM_AS_IROM} se selecciona la implementación de la IMEM mediante una de estas dos opciones. +Este genérico es + +\hspace{35mm} {\mintinline[breaklines]{vhdl}{IMEM_AS_IROM => imem_as_rom_c} } + +\noindent y se define como + +\hspace{17mm} \mintinline[breaklines]{vhdl}{imem_as_rom_c : boolean := not INT_BOOTLOADER_EN;} + +\noindent Por lo tanto, para cargar un programa desde la \textit{neorv32\_application\_image.vhd} (o desde el hexadecimal), la IMEM debe implementarse como una ROM inicializada mediante ese archivo, por lo que el \textit{bootloader} \textbf{debe estar deshabilitado}. +Se discutió con Stephan \href{https://github.com/stnolting/neorv32/discussions/824}{(\#824)} acerca de por qué la IMEM se inicializa como una RAM vacía cuando el \textit{bootloader} está activado. +Y según el diseñador del NEORV32, \say{si la IMEM se implementara como una RAM preinicializada, entonces la imagen podría corromperse durante el tiempo de ejecución (imagina algún puntero deshonesto escribiendo en la IMEM), lo que requeriría volver a cargar el programa original. +Por lo tanto, la carga del \textit{bootloader} se requeriría de todos modos.} + +El proceso para deshabilitar el \textit{bootloader} es sencillo, en el TOP del diseño del NEORV32, se debe cambiar la constante \mintinline[breaklines]{vhdl}{INT_BOOTLOADER_EN} de \textit{true} a \textit{false}, como se muestra en el extracto de código \ref{code:1}. + +\begin{listing}[h!] +\begin{minted}[frame=lines,framesep=2mm,baselinestretch=1.2,fontsize=\footnotesize]{vhdl} +neorv32_top_inst : neorv32_top +generic map( +---------------------------------- +INT_BOOTLOADER_EN => false, +---------------------------------- +) +\end{minted} +\caption{Constante para deshabilitar el \textit{bootloader}.} +\label{code:1} +\end{listing} + +\subsubsection{Cargar un programa compilado desde un archivo hexadecimal} + +Como se ha mencionado, en vez de cargar un programa compilado desde el archivo \textit{neorv32\_application\_image.vhd}, es posible cargar el programa compilado desde un archivo hexadecimal (.hex). +Para ello, se necesitan hacer unas pequeñas modificaciones en el código HDL del NEORV32. +En particular, se debe añadir una nueva función en el paquete \textit{neorve32\_package.vhd}. +Esta función se encargará de leer el archivo hexadecimal usando la librería \textit{std.textio.all}. \footnote{Esta librería está soportada desde la versión VHDL 2008.} +La función en cuestión es la descrita en el extracto de código \ref{code:2}. + +\begin{listing}[h!] +\begin{minted}[frame=lines,framesep=2mm,baselinestretch=1.2,fontsize=\footnotesize]{vhdl} +-- Initialize mem32_t from hex +-- MEMORY_SIZE is IMEM_SIZE/4, see neorv32_imem.default.vhd + +impure function mem32_init_hex(name : STRING; MEMORY_SIZE : natural) return mem32_t is + file rom_file : text open read_mode is name; + variable rom_line : line; + variable temp_word : std_ulogic_vector(31 downto 0); + variable temp_rom : mem32_t(0 to MEMORY_SIZE-1) := (others => (others => '0')); +begin + for i in 0 to MEMORY_SIZE - 1 loop + exit when endfile(rom_file); + readline(rom_file, rom_line); + hread(rom_line, temp_word); + temp_rom(i) := temp_word; + end loop; + + return temp_rom; +end function; +\end{minted} +\caption{Función a añadir al \textit{neorve32\_package.vhd} para leer un software compilado en formato hexadecimal.} +\label{code:2} +\end{listing} + +Además, el archivo \textit{neorv32\_imem.default.vhd} \footnote{En el archivo \textit{neorv32\_imem.default.vhd} el código relacionado con cargar la ROM desde la app\_image debe ser comentado.} se debe modificar para cargar el contenido del archivo hexadecimal a la memoria de instrucciones, usando la función definida en el extracto de código \ref{code:2}. +Para ello se debe añadir el extracto de código \ref{code:3}. + +\begin{listing}[h!] +\begin{minted}[frame=lines,framesep=2mm,baselinestretch=1.2,fontsize=\footnotesize]{vhdl} +constant ROM_INIT_FILE : string := "neorv32_raw_exe.hex"; +-- ROM - initialized with hex code -- +constant mem_rom_c : mem32_t(0 to IMEM_SIZE/4-1) := mem32_init_hex(ROM_INIT_FILE, IMEM_SIZE/4); +\end{minted} +\caption{Modificación del archivo \textit{neorv32\_imem.default.vhd} para cargar la IMEM mediante la función descrita en el extracto de código \ref{code:2}.} +\label{code:3} +\end{listing} + +En conclusión, este método propone leer desde un formato hexadecimal, el cual es una salida nativa del compilador, +a través de código VHDL, en lugar de autogenerar código HDL con el programa compilado. +Ambas opciones cargan la IMEM cuando se sintetiza el diseño, pero la opción de lectura del archivo .hex no modifica el código HDL del diseño. +Es decir, con esta opción conseguimos dos cosas, no autogenerar código en otro lenguaje y no modificar el código HDL cada vez que se actualiza el software a cargar. + +Por último, cabe destacar que a lo largo del desarrollo de este proyecto se ha cargado software compilado al NEORV32 mediante los tres formatos expuestos. +No obstante, mayoritariamente se ha utilizado el formato .vhd generando una \textit{neorv32 \_application\_image.vhd} para cada software empleado. + \section{Caracterización del rendimiento} \label{Carac} diff --git a/Capitulos/Memoria.tex b/Capitulos/Memoria.tex index 3a90599..7d24a32 100755 --- a/Capitulos/Memoria.tex +++ b/Capitulos/Memoria.tex @@ -372,7 +372,7 @@ \section{Beneficios que aporta el trabajo} Puesto que dicho artículo ha sido aceptado, se publicará en el IEEEXplore. Se considera un beneficio aportado por este trabajo la contribución en dicha base de datos. -También, se considera un beneficio aportado por este trabajo la publicación del contenedor \cite{gh:conatiner-implarty} desarrollado para realizar la síntesis, implementación y generación de bitstream para las FPGAs Arty A7 35t y 100t mediante las herramientas \textit{Open Source}: GHDL + yosys + GHDL yosys plugin + nextpnr-xilinx + prjxray. +También, se considera un beneficio aportado por este trabajo la publicación del contenedor \cite{gh:conatiner-implarty} desarrollado para realizar la síntesis, implementación y generación de \textit{bitstream} para las FPGAs Arty A7 35T y 100T mediante las herramientas \textit{Open Source}: GHDL + yosys + GHDL yosys plugin + nextpnr-xilinx + prjxray. En lo que respecta a los Objetivos de Desarrollo Sostenible (ODS), este trabajo de investigación pretende aportar beneficios en el marco del objetivo \textit{Industria, innovación e infraestructura} (ODS 9) y del objetivo \textit{Reducción de las desigualdades} (ODS 10). Respecto al ODS 9, se considera que la investigación entorno al enfoque distribuido para realizar IA en el borde supone fomentar la innovación en lo que respecta a este ámbito. @@ -380,7 +380,24 @@ \section{Beneficios que aporta el trabajo} \section{Análisis del estado del arte} -Aqui irá un análisis del estado del arte. +Haciendo un repaso por las principales bases de datos de ámbito electrónico, se observan varios proyectos con una filosofía similar a la presentada en este trabajo de investigación. +Un ejemplo muy interesante es el encontrado en una publicación titulada \textit{Tiny Neuron Network System based on RISC-V Processor: A Decentralized Approach for IoT Applications} \cite{9942990}. +En dicho \textit{paper}, se presenta una investigación sobre un pequeño acelerador de redes neuronales en un SoC basado en RISC-V para acelerar una IA empleada en aplicaciones de IoT. +Este coprocesador implementa una MAC (multiplicador y acumulador) de precisión variable en bits o una MAC estocástica para reducir el área de hardware y el consumo de energía. +Es curioso el hecho de que se emplea la misma tecnología FPGA que en el presente proyecto, una Arty A7 100T. +Los resultados presentados en este trabajo son destacables, consiguiendo realizar con precisión de 8 bits redes neuronales convolucionales (CNN) con una precisión del 98,55\%. +En su caso, el método optado para acoplar los aceleradores ha sido una interfaz AXI. + +Otro ejemplo muy interesante es el expuesto en una publicación titulada \textit{CNN Specific ISA Extensions Based on RISC-V Processors} \cite{9802445}. +En ella, se presenta una extensión de instrucciones basada en la ISA RISC-V destinada a aumentar la eficiencia computacional de las CNN en dispositivos en el borde. +En su caso emplean el core RISC-V \textit{Open Source} Zero-riscy \cite{8106976} \cite{gh:zero-riscy}. +Con objeto de evaluar el efecto de la extensión de instrucciones propuesta, se realiza una serie de cargas de trabajo en el núcleo de referencia y en el ampliado. +Se obtinen un ratio de aceleración de 1,5× cuando se ejecuta una CNN, y alcanza 2,48×-2,82× cuando sólo se realizan los cálculos de convolución. +Los resultados obtenidos en este \textit{paper} demuestran que las extensiones de ISA propuestas pueden mejorar eficazmente el rendimiento de las CNN. + +Los casos mencionados, así como otros de gran interés, se encuentran recogidos en una publicación titulada \textit{A Review of Edge Intelligence Applications Based on RISC-V} \cite{10336594}. +En ella se resume el uso de RISC-V en aplicaciones de IA en el borde desde un punto de vista hardware y software. +Además, a lo largo de la \textit{review} se analizan varios aceleradores, coprocesadores, compiladores y \textit{toolchains} basados en RISC-V, así como las principales aplicaciones software de la IA en el borde. \section{Análisis de alternativas} @@ -402,7 +419,11 @@ \section{Análisis de alternativas} Este hecho no impide integrar en él código en otros HDLs. De igual modo, es común generar diseños de LiteX en HDLs más tradicionales, como verilog. -%Quizá otra alternativa más +Por último, se encuentra la alternativa de comenzar la aproximación de IA a en el borde mediante la externalización a hardware específico de otro cálculo relativo a las RNAs. +Esta alternativa es bastante diversa y podría ir desde acelerar la activación mediante otra función disponible en el coprocesador configurable y programable basado en CRI hasta elegir otra operación para ser acelerada. +Un ejemplo de esta última propuesta es la detallada en una publicación titulada \textit{A Soft RISC-V Vector Processor for Edge-AI} \cite{9885953}. +En ella se presenta una unidad vectorial basada en un \textit{array} sistólico que está estrechamente integrada en el pipeline de un núcleo RISC-V de 32 bits. +Tras evaluar el rendimiento de este enfoque distribuido en una FPGA Xilinx Virtex 7, se concluye un aumento de velocidad de hasta 40,7 veces con respecto al núcleo escalar RISC-V en tareas de reconocimiento de imágenes, a costa de un aumento en el consumo energético y en los recursos hardaware de 1,2 y 1,8 veces respectivamente. \section{Descripción de la solución propuesta} @@ -412,7 +433,7 @@ \section{Descripción de la solución propuesta} Este hecho tiene como objetivo simplificar la gestión computacional en pos de implementar un primera aproximación de IA en el borde. En este sentido, se propone utilizar un coprocesador basado en la método CRI y acoplarlo a un procesador RISC-V. Mediante los argumentos descritos en la sección \ref{Selec} se elige el microcontrolador NEORV32. -Con objeto de generar un criterio de selección de modo de acoplamiento, se propone realizar una caracterización del rendimiento de los principales métodos de conexión con los que cuenta este microcontrolador. +Con objeto de generar un criterio de selección del modo de acoplamiento, se propone realizar una caracterización del rendimiento de los principales métodos de conexión con los que cuenta este microcontrolador. Esta caracterización se detalla en la sección \ref{Carac}. Por último, se acopla el coprocesador encargado de acelerar el cálculo de la FA sigmoide basado en CRI al NEORV32. Además, se verifica el beneficio de emplear este tipo de enfoque distribuido comparándolo con realizar los mismos cálculos utilizando únicamente el microcontrolador. diff --git a/Capitulos/Metodologia.tex b/Capitulos/Metodologia.tex index b2c1c68..6799491 100755 --- a/Capitulos/Metodologia.tex +++ b/Capitulos/Metodologia.tex @@ -11,12 +11,10 @@ \section{Diagrama de Gantt} Aqui irá el diagrama de Gantt. -\section{Algoritmos} - -Aqui irán los algoritmos. - \section{Análisis de los resultados} Aqui irá un análisis de los resultados. +%capturas resultados en CI de github + diff --git a/Figuras/cutecom_cmd_upload.png b/Figuras/cutecom_cmd_upload.png new file mode 100644 index 0000000..ca10ca0 Binary files /dev/null and b/Figuras/cutecom_cmd_upload.png differ diff --git a/Figuras/workflow.pdf b/Figuras/workflow.pdf new file mode 100644 index 0000000..e4b8b8f Binary files /dev/null and b/Figuras/workflow.pdf differ diff --git a/main.tex b/main.tex index d851852..2640a5a 100644 --- a/main.tex +++ b/main.tex @@ -51,6 +51,13 @@ \usepackage[skip=4pt plus1pt, indent=15pt]{parskip} \usepackage{pdfpages} \usepackage{amsmath} +\usepackage[ + left = \flqq{},% + right = \frqq{},% + leftsub = \flq{},% + rightsub = \frq{} % +]{dirtytalk} +\usepackage{minted} %---------------------------------------------------------------------------------------- % MARGIN SETTINGS @@ -225,10 +232,19 @@ \textbf{ReLU} & \textbf{Re}ctified \textbf{L}inear \textbf{U}nit\\ \textbf{FOSS} & \textbf{F}ree and \textbf{O}pen \textbf{S}ource \textbf{S}oftware\\ \textbf{ODS} & \textbf{O}bjetivos de \textbf{D}esarrollo \textbf{S}ostenible\\ +\textbf{MAC} & \textbf{M}ultiply–\textbf{AC}cumulate\\ +\textbf{CNN} & \textbf{C}onvolutional \textbf{N}eural \textbf{N}etwork\\ \textbf{DRAM} & \textbf{D}ynamic \textbf{R}andom \textbf{A}ccess \textbf{M}emory\\ \textbf{PCI} & \textbf{P}eripheral \textbf{C}omponent \textbf{I}nterconnect\\ \textbf{SATA} & \textbf{S}erial \textbf{A}dvanced \textbf{T}echnology \textbf{A}ttachment\\ - +\textbf{EDA} & \textbf{E}lectronic \textbf{D}esign \textbf{A}utomation\\ +\textbf{FLOS} & \textbf{F}ree/\textbf{L}ibre and/or \textbf{O}pen \textbf{S}ource\\ +\textbf{FPGAIF} & \textbf{FPGA} \textbf{I}nterchange \textbf{F}ormat\\ +\textbf{ASIC} & \textbf{A}pplication-\textbf{S}pecific \textbf{I}ntegrated \textbf{C}ircuit\\ +\textbf{GCC} & \textbf{G}NU \textbf{C}ompiler \textbf{C}ollection\\ +\textbf{ILA} & \textbf{I}ntegrated \textbf{L}ogic \textbf{A}nalyzer\\ +\textbf{IMEM} & \textbf{I}nstruction \textbf{MEM}ory\\ + \end{abbreviations} %---------------------------------------------------------------------------------------- diff --git a/references.bib b/references.bib index 695ce28..cdf23f2 100755 --- a/references.bib +++ b/references.bib @@ -386,6 +386,76 @@ @misc{gh:migen commit = {832a7240ba32af9cbd4fdd519ddcb4f912534726} } +@INPROCEEDINGS{9942990, + author={Nguyen, Ngo-Doanh and Bui, Duy-Hieu and Tran, Xuan-Tu}, + booktitle={2022 International Conference on Advanced Technologies for Communications (ATC)}, + title={Tiny Neuron Network System based on RISC-V Processor: A Decentralized Approach for IoT Applications}, + year={2022}, + volume={}, + number={}, + pages={98-103}, + keywords={Power demand;Neurons;AI accelerators;Hardware;System-on-chip;Internet of Things;Servers}, + doi={10.1109/ATC55345.2022.9942990} +} + +@INPROCEEDINGS{9802445, + author={Yu, Xiang and Yang, Zhijie and Peng, Linghui and Lin, Bo and Yang, Wenjing and Wang, Lei}, + booktitle={2022 5th International Conference on Circuits, Systems and Simulation (ICCSS)}, + title={CNN Specific ISA Extensions Based on RISC-V Processors}, + year={2022}, + volume={}, + number={}, + pages={116-120}, + keywords={Performance evaluation;Microarchitecture;Program processors;Convolution;Image edge detection;Data transfer;Pattern recognition;RISC-V;ISA extensions;CNN accelerating}, + doi={10.1109/ICCSS55260.2022.9802445} +} + +@INPROCEEDINGS{8106976, + author={Davide Schiavone, Pasquale and Conti, Francesco and Rossi, Davide and Gautschi, Michael and Pullini, Antonio and Flamand, Eric and Benini, Luca}, + booktitle={2017 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS)}, + title={Slow and steady wins the race? A comparison of ultra-low-power RISC-V cores for Internet-of-Things applications}, + year={2017}, + volume={}, + number={}, + pages={1-8}, + keywords={Multicore processing;Open source software;Program processors;Signal processing algorithms;Sensors;RISC-V;energy efficiency;area optimized;ultra-low-power;open-source;core;microprocessor;internet-of-things}, + doi={10.1109/PATMOS.2017.8106976} +} + +@misc{gh:zero-riscy, + author = {Gautschi, Michael and Wegmann, Markus and Schiavone, Davide}, + title = {{zero-riscy CPU Core )}}, + year = {2017}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/tom01h/zero-riscy}{tom01h/zero-riscy}}, + commit = {6f5711fa7020e9306c322afb9acec6c12a68fdf6} +} + +@INPROCEEDINGS{10336594, + author={Wei, Qian and Cui, Enfang and Gao, Yue and Li, Tianzheng}, + booktitle={2023 2nd International Conference on Computing, Communication, Perception and Quantum Technology (CCPQT)}, + title={A Review of Edge Intelligence Applications Based on RISC-V}, + year={2023}, + volume={}, + number={}, + pages={115-119}, + keywords={Trusted computing;Systematics;Image edge detection;Software algorithms;Computer architecture;Software;Hardware;RISC-V;edge intelligence;AI;energy efficiency}, + doi={10.1109/CCPQT60491.2023.00025} +} + +@INPROCEEDINGS{9885953, + author={Chander, V. Naveen and Varghese, Kuruvilla}, + booktitle={2022 35th International Conference on VLSI Design and 2022 21st International Conference on Embedded Systems (VLSID)}, + title={A Soft RISC-V Vector Processor for Edge-AI}, + year={2022}, + volume={}, + number={}, + pages={263-268}, + keywords={Deep learning;Image edge detection;Neural networks;Benchmark testing;Very large scale integration;Hardware;Systolic arrays}, + doi={10.1109/VLSID2022.2022.00058} +} + @misc{gh:neorv32-tool, author = {Nolting, Stephan and {Contributors}}, title = {{Prebuilt RISC-V GCC toolchains for x64 Linux.}}, @@ -419,3 +489,138 @@ @misc{neorv32-ug year = {2020} } +@misc{gh:rapid, + author = {{AMD Research and Advanced Development}}, + title = {{RapidWright}}, + year = {2018}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/Xilinx/RapidWright}{gh:Xilinx/RapidWright}}, + commit = {158ec6ac460230a3b1bcd01c3ea16f021de35223} +} + +@misc{contest, + author = {{AMD}}, + title = {{Runtime-First FPGA Interchange Routing Contes}}, + year = {2024}, + publisher = {AMD}, + journal = {Web page}, + howpublished = {\href{https://xilinx.github.io/fpga24_routing_contest/index.html}{xilinx.github.io/fpga24 \_routing\_contest/index}} +} + +@misc{FPGAIF, + author = {{CHIPS Alliance}}, + title = {{FPGA Interchange Format}}, + year = {2020}, + publisher = {CHIPS Alliance}, + journal = {Web page}, + howpublished = {\href{http://www.rapidwright.io/docs/FPGA_Interchange_Format.html}{rapidwright.io/docs/FPGA\_Interchange \_Format}} +} + +@misc{osvvm, + author = {Lewis, Jim and {Contributors}}, + title = {{Open Source VHDL Verification Methodology}}, + year = {2013}, + publisher = {OSVVM}, + journal = {Web page}, + howpublished = {\href{https://osvvm.org/}{osvvm.org}} +} + +@misc{uvvm, + author = {Tallaksen, Espen and {Contributors}}, + title = {{Universal VHDL Verification Methodology }}, + year = {2013}, + publisher = {UVVM}, + journal = {Web page}, + howpublished = {\href{https://www.uvvm.org/}{uvvm.org}} +} + +@misc{wilson-research, + author = {{Siemens}}, + title = {{The 2022 Wilson Research Group Functional Verification Study}}, + year = {2022}, + publisher = {Siemens}, + journal = {Web page}, + howpublished = {\href{https://blogs.sw.siemens.com/verificationhorizons/2022/11/21/part-6-the-2022-wilson-research-group-functional-verification-study/}{blogs.sw. siemens.com/verificationhorizons/2022/11/21/part-6-the-2022-wilson-research-group-functional-verification-study/}} +} + +@misc{gh:ghdl, + author = {Gingold, Tristan and {Contributors}}, + title = {{GHDL - VHDL 2008/93/87 simulator}}, + year = {2024}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/ghdl/ghdl}{gh:ghdl/ghdl}}, + commit = {f6e6df2d4909f6672673384ace215514de60ab8d} +} + +@misc{gh:yosys, + author = {Xenia Wolf, Claire and {Contributors}}, + title = {{YOSYS - Yosys Open SYnthesis Suite}}, + year = {2020}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/YosysHQ/yosys}{gh:YosysHQ/ yosys}}, + commit = {855ac285f49277ba9007f5808f5350ec656db852} +} + +@misc{gh:ghdl-plugin, + author = {Gingold, Tristan and {Contributors}}, + title = {{ghdl-yosys-plugin: VHDL synthesis (based on GHDL and Yosys)}}, + year = {2024}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/ghdl/ghdl-yosys-plugin}{gh:ghdl/ghdl-yosys-plugin}}, + commit = {511412f984d64ed7c46c4bdbd839f4b3c48f6fa5} +} + +@misc{gh:nextpnr, + author = {Shah, David and {Contributors}}, + title = {{Nextpnr-Xilinx - Experimental flows using nextpnr for Xilinx devices}}, + year = {2020}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/gatecat/nextpnr-xilinx}{gh:gatecat/nextpnr-xilinx}}, + commit = {f79387599b420bfadf3dc218e55e1e77b1edb304} +} + +@misc{gh:prjxray, + author = {{Project X-Ray Contributors}}, + title = {{Documenting the Xilinx 7-series bit-stream format}}, + year = {2020}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/f4pga/prjxray}{gh:f4pga/prjxray}}, + commit = {5d682fac45c7b52b0ec1a68c68450cee5834bb28} +} + +@misc{gh:openFPGALoader, + author = {Goavec-Merou, Gwenhael and {Contributors}}, + title = {{openFPGALoader: Universal utility for programming FPGA}}, + year = {2024}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/trabucayre/openFPGALoader}{gh:trabucayre/openFPGALoader}}, + commit = {81422b6ca3d05a7b7ab6964ccaf2c88bf7d59aff} +} + +@misc{gh:vunit, + author = {Asplund, Lars and Kraigher, Olof and {Contributors}}, + title = {{VUnit - Testing framework for VHDL/ SystemVerilog}}, + year = {2024}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/VUnit/vunit}{gh:VUnit/vunit}}, + commit = {3032da050f11bdf038053f67fc664c39ee19f9f6} +} + +@misc{gh:cutecom, + author = {Neundorf, Alexander and {Contributors}}, + title = {{CuteCom - A graphical serial terminal}}, + year = {2018}, + publisher = {GitHub}, + journal = {GitHub repository}, + howpublished = {\href{https://github.com/neundorf/CuteCom}{gh:neundorf/ CuteCom}}, + commit = {efc3f0efb72f9fc7d6506f6908ca83d689a09fe1} +} +