Show simple item record

dc.contributor.advisorVillar Bonet, Eugenio 
dc.contributor.advisorSánchez Espeso, Pablo Pedro 
dc.contributor.authorVázquez Gutiérrez, José Luis
dc.contributor.otherUniversidad de Cantabriaes_ES
dc.date.accessioned2016-11-21T13:39:46Z
dc.date.available2016-11-21T13:39:46Z
dc.date.issued2016-02
dc.identifier.urihttp://hdl.handle.net/10902/9649
dc.description.abstractRESUMEN: Seguramente todos hemos pensado alguna vez algo similar a “¿por qué será tan lento mi PC?”, sea porque hemos utilizado uno más actualizado, porque nuestro sistema de refrigeración requiere una limpieza o porque tenemos demasiadas pestañas abiertas en el navegador de internet. Sea la razón que sea, me quiero centrar en el caso de haber utilizado un computador moderno, probablemente la causa más extendida. En otros campos de la computación, ese fue durante mucho tiempo el sistema de aceleración de código: esperar a un computador más nuevo, ya que en unos meses llegará un nuevo chip con una frecuencia de reloj mucho más elevada. Esta estrategia funcionó durante mucho tiempo, pero llegó un día en el que no resultaba viable debido al elevado consumo de energía[1]. Al fin y al cabo, la energía que consume un procesador es directamente proporcional a la frecuencia de su reloj[1], por lo que llegó el día en el que no se disponía de sistemas de refrigeración lo suficientemente avanzados para soportar una mayor frecuencia. La forma de conseguir programas más rápidos a partir de ese momento pasaba por realizar más instrucciones en paralelo, para poder conseguir mayor capacidad de cómputo con menor frecuencia. Primero con CPUs multinúcleo y después con GPGPU se fomentó la construcción de código paralelo o paralelizable, para poder explotar estas capacidades. Con el tiempo se vio que siguen siendo soluciones con un consumo energético relativamente elevado cuando hablamos de HPC y de sistemas de datacenter, por lo que algunos valientes se han decidido a tratar de acelerar el cómputo mediante hardware reconfigurable o FPGAs[2][3]. Estos son esfuerzos relativamente recientes, y a lo largo de este trabajo voy a tratar de presentar y explicar el por qué de estos esfuerzos, así como en qué consisten. También voy a presentar un acelerador desarrollado en gran medida por mí mismo, su configuración paso a paso y las partes de software que se necesitan para la comunicación con un programa corriendo en un PC. El trabajo se estructura de la siguiente manera. Tras esta introducción se hace una presentación del estado actual de la aceleración de código, tanto en tipos de aceleradores como en las distintas soluciones existentes en el mercado. Después presento mi acelerador, comparándolo con otros esfuerzos similares. Pasaremos a una fase en la que se habla del proceso de construcción, desde la investigación necesaria hasta un ejemplo funcional con resultados reales. Por último se extraen conclusiones de ese trabajo.es_ES
dc.description.abstractABSTRACT: We've all been there, where we are using our PC and we think "why is it running so slow?" It might be because we've used a more up-to-date one, because it needs some serious fan cleanup or because we have way too many tabs open in our web browser. While the appreciation might stem from any of those cases, I'd like to focus on the first one, which might be the most common one. In more advanced fields of computation, "a more up-to-date computer" was the general acceleration approach: you wated for a new chip with a faster clock because it would come around in a few months anyways. This was a viable strategy for a very long time, until power concerns made it no longer viable. After all, power draw is proportional to clock frequency, so a day came where we didn't have access to sufficiently powerful cooling systems to deal with the higher clock frequencies. At this point in time, code acceleration started heavily relying on parallelism, running several lines of code at a time so we could achieve greater performance with lower clock frequencies. First the multi-threaded CPU and later the GPGPU encouraged the writing of parallel or at least parallel-oriented code in order to exploit these systems. Over time we realized that these solutions were still very power-hungry, specially in HPC situations or large servers. That's why a few brave companies have tried to accelerate code execution via hardware, generally reconfigurable FPGA fabrics. These are recent efforts, and over the course of this project I will try to present the reason behind these efforts, as well as what they are all about. I will also present my own FPGA accelerator, its step-by-step configuration and the software needed to run on a PC host. This memory is structured as follows: After this introduction we make a brief presentation of the state of the art, both in types of code accelerators and in different market solutions, as well as making the case for FPGA accelerators. We then present our own effort, as opposed to other similar solutions. The following section will talk about the building process, from the first approaches to the running accelerator. Finally, I share my final thoughts on the subject.es_ES
dc.format.extent36 p.es_ES
dc.language.isospaes_ES
dc.rightsAtribución-NoComercial-SinDerivadas 3.0 Españaes_ES
dc.rights.urihttp://creativecommons.org/licenses/by-nc-nd/3.0/es/*
dc.titleAceleradores de código basados en FPGA: qué son y cómo hacerloses_ES
dc.title.alternativeFPGA-based code accelerators: what are they and how to build onees_ES
dc.typeinfo:eu-repo/semantics/bachelorThesises_ES
dc.rights.accessRightsopenAccesses_ES
dc.description.degreeGrado en Ingeniería Informáticaes_ES


Files in this item

Thumbnail

This item appears in the following Collection(s)

Show simple item record

Atribución-NoComercial-SinDerivadas 3.0 EspañaExcept where otherwise noted, this item's license is described as Atribución-NoComercial-SinDerivadas 3.0 España