No sin antes felicitar a txipi en particular, y al e-ghost como grupo, por su constancia, me cuelo por alusiones :):
La actividad en la EUITI-BI ha entrado en standby en 2015 por las razones que vemos en muchos colectivos universitarios: dificultad para cuadrar las agendas de quienes actuaban de acicate, y saturación/desubicación del alumnado. No obstante, hago ping a quienes han organizado las últimas actividades, para ver si se animan. Personalmente, estos últimos 2-3 años he estado trabajando intensivamente en el diseño de sistemas digitales escritos en VHDL y prototipados en FPGAs. Tengo varias ideas sobre posibles charlas o debates alrededor del hardware libre/abierto, el movimiento maker y el cambio de paradigma de computación hacia el hardware reconfigurable (después de que las GPUs se hayan mostrado rápidas pero muy poco eficientes), entre otros. Pero no estoy seguro de que encajen como "cursillo", ya que preferiría escuchar diferentes puntos de vista y observar cómo se perciben estos aspectos en la comunidad local. Por ello, a continuación de estas líneas pego un texto en el que he tratado de plasmar muchas de esas ideas. Sobre ello, si consideráis que puede tener interés para los asistentes, y si es a partir del 14, puedo preparar alguna(s) de las siguientes: - "La judada *maestra* de FTDI, o como convertir un potosí en un ladrillo de la noche a la mañana". Como taller, incluiría cómo recuperar <https://github.com/FreeJaus/ardupi/wiki/Unbrick-FTDI> las placas "muertas", habiendo explicado previamente por qué dejaron de funcionar. Añadiría referencias a otros integrados que he visto en placas clónicas, que simplemente requieren otro driver diferente, y no es que estén afectadas. En función del interés, podría añadir explicaciones sobre las diferentes formas <https://github.com/FreeJaus/ardupi/wiki/Arduino-USB:-comunicaci%C3%B3n-serie-%28RS232,-USB,-TTL%29-y-programaci%C3%B3n-%28sketch,-bootloader,-ISP...%29> de implementar la comunicación serie entre un PC y un Arduino. También las formas de programar un microcontrolador. - "Introducción al hardware reconfigurable". Tomando como referencia las placas de bajo coste y shields basadas en la Spartan6 y pensadas para Arduino que están surgiendo, charla-taller de introducción al hardware reconfigurable. Si se limita a una charla-taller teórica, se podría realizar con software libre. Si se quiere probar, además de hablar con algún departamento/empresa que disponga de FPGAs y las ceda, habría que utilizar alguna parte cerrada. En cualquier caso creo que es interesante porque permite "jugar" aunque sea a nivel de simulación, y plantear algunos de los aspectos críticos que se subrayan en la siguiente. - "¿Es el Hardware Libre una quimera?". Como charla, explicando los diferentes modelos (Arduino/Adafruit, OpenCores, CERN, ASIC), y la deriva de los fabricantes de FPGAs. Terminaría apuntando la situación de las herramientas para trabajar con hardware reconfigurable, para abrir debate sobre la pregunta que da título a la charla. - "Embedded Logic IDE: ideas para un futuro híbrido". Como exposición de las razones que me llevaron a escribir el texto pegado a continuación, intercambio de ideas sobre estas y sobre la propuesta. El objetivo principal sería, en caso de que haya interés, aportar referencias o experiencias para enriquecer el diagnóstico. Sin duda tiene relación directa con Eclipse Avanzado. Supongo que, a riesgo de simplificar en exceso, podríais situarlo todo en la categoría "Arduino" (aunque la segunda y la cuarta, tienen mucha relación con CUDA y OpenCL). Por ello, dejo a vuestro criterio valorar la conveniencia, y quedo a la espera de una respuesta. Si tenéis alguna otra idea sobre Arduino a falta de ponente, podría mirarlo, pero si entramos en cuestiones de librerías concretas, shields ethernet, etc. no me he peleado con ellas. Si es sobre los diferentes tipos de motores, como funcionan y como se controlan, lo tengo más fácil. Ya dijo Knuth que el software es duro. Salud y ánimo! ---------------- En la Ingeniería Técnica, describí un PID para controlar un motorcillo DC como PFC [0], y, en el máster, un core (núcleo, arquitectura) para resolver la Singular Value Decomposition (*SVD*) [1], conocida en estadística como Principal Component Analysis <http://en.wikipedia.org/wiki/Principal_component_analysis> (*PCA*) o transformada de Hotelling, y que tiene casi tantos nombres como áreas y disciplinas hay en la Academia. En el caso del SVD, el origen se remonta al *siglo XIX*, de la mano de Jacobi <http://es.wikipedia.org/wiki/Carl_Gustav_Jakob_Jacobi>, pero todavía hoy Google Scholar ofrece más de 7K resultados en 2015 <https://scholar.google.es/scholar?as_ylo=2015&q=singular+value+decomposition&hl=es&as_sdt=0,5>. Eso me ha permitido, aunque desde un prisma muy particular, hacer una *revisión histórica de las arquitecturas "punteras" en cada generación*: las múltiples librerías de* álgebra lineal* en las que se basan, entre otros, MATLAB, como son LAPACK <http://www.netlib.org/lapack/>, LINPACK <http://www.netlib.org/linpack/> y, recientemente, MAGMA <http://icl.cs.utk.edu/magma/> (esponsorizados por AMD, Intel, Mathworks y NVIDIA); implementaciones en *supercomputadores* de finales de los 70 y principios de los 80 [2]; propuestas de los 80-90 para diseños *VLSI* con CORDIC <http://core.ac.uk/download/pdf/1509903.pdf> como base [3]; hasta soluciones recientes en redes *P2P* [4]. Sin embargo, mientras mi cabeza estaba viajando por el siglo XX, *el mundo ha seguido girando*, y además de las elecciones del 24, *ha explotado el movimiento maker*: Arduino <http://www.arduino.cc/> ha tenido una subida incesante, pero la lista de placas para aplicaciones empotradas/embebidas/incrustadas -ponga usted el término que prefiera- se está volviendo realmente difícil de seguir: Raspberry Pi <https://www.raspberrypi.org/>, Beaglebone <http://beagleboard.org/>, Banana Pi <http://www.bananapi.org/>, OLinuXino <https://www.olimex.com/Products/OLinuXino/open-source-hardware>*, *CHIP <https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-computer>, Mojo <https://www.kickstarter.com/projects/1106670630/mojo-digital-design-for-the-hobbyist/description>, LogiFPGA <https://www.kickstarter.com/projects/1575992013/logi-fpga-development-board-for-raspberry-pi-beagl/description>... a las que hay que sumar las de fabricantes y montadores "clásicos" como PIC, Atmel, ST, VIA... y el colofón final de mano de ARM con mbed <https://mbed.org/ecosystem/mbed-enabled-products/>. Esto se ha extendido a las impresoras 3D y, por necesidad, al software para modelado, con alternativas a los conocidos Blender, Maya/3DStudio, SketchUp, SolidWorks, etc. más sencillas y, en su mayoría libre: OpenSCAD <http://www.openscad.org/>, OpenCASCADE <http://www.opencascade.org/>/ FreeCAD <http://www.freecadweb.org/>, LibreCAD <http://librecad.org/cms/home.html>, etc. El resultado general ha sido una *simplificación de las herramientas e interfaces* para que prácticamente cualquiera (¡Que me traigan un niño de cuatro años!) pueda programar software con un flujo de trabajo libre y ejecutarlo en una muy amplia variedad de dispositivos de bajo coste, y accesibles. Lo cual, dado el nivel de cultura tecnológica que tenemos por estos lares, no sólo *es bueno*, sino inmejorable. Es innegable que desde el punto de vista de la defensa del *software libre*, la *subida en la base de usuarias* ha sido inaudita, lo que ha repercutido muy positivamente en el desarrollo de algunas áreas. A pesar de ello, a raíz de algunas noticias que he seguido este último año, no puedo evitar vernos en el* gatopardo* siciliano. En el centro, como siempre, está la *rentabilidad*. Y viendo ese indicador como referencia en un mundo mercantilizado, observo derivaciones que me plantean dudas éticas (no estoy seguro de que sea el mejor término). La primera: *¿es el Hardware Libre una quimera?* ¿somos capaces de trazar una línea entre el hardware libre y el abierto? ¿cómo se traslada al hardware el uso tendencioso del término "abierto" que hemos visto en el software? Planteo estas preguntas porque, centrado como estoy en el diseño de sistemas digitales, llego a preguntarme qué tiene Arduino de hardware libre: - La gran mayoría de *componentes* que se utilizan no sólo son *opacos* en el detalle de su *implementación y fabricación*, sino que están fuertemente protegidos por *acuerdos de confidencialidad*. - Aunque resulte paradójico, es complicado proteger el copyright del circuito, ya que pequeñas variaciones en el esquema, o la sustitución de componentes por equivalentes, pueden ser suficiente para sortearlo [5]. Por lo que la libertad de los esquemas de Arduino, en la práctica, sólo ofrece ventajas a quien quiera reproducir el diseño exactamente. Cualquier modificación que requiera recolocar algún componente y/o volver a realizar el rutado, es una placa nueva. - Arduino no es sólo el diseño de las placas. Es también una revolución pedagógica, un conjunto de librerías, un entorno de desarrollo.. Y también una *marca*, un *modelo de negocio basado en royalties*, y un entramado de *distribución complejo*. Por el momento, el hardware, a diferencia del software, *no puede ser reproducido y distribuido a coste cero*. Una de las noticias que mencionaba, y que ha hecho patente este último punto, es el *culebrón* entre arduino.cc <http://blog.arduino.cc/2015/03/20/dear-arduino-community/> y arduino.org <http://arduino.org/about-us> por los *derechos de la marca*, con el anuncio de Genuino <http://blog.arduino.cc/2015/05/22/the-state-of-arduino-a-new-sister-brand-announced/>. Tampoco es cuestión del todo nueva, ya que en los foros de wiring <http://forum.wiring.co/index.php/topic,37.msg452.html#msg452> (del que el IDE de arduino fue forkeado en 2005), hace unos años que ya se había apuntado. Otra de las noticias, fue la jugada "maestra" de* FTDI*, que en el otoño pasado subió una actualización automática del driver a windows, y quienes conectaron un dispositivo con un integrado "pirata" vieron sus placas "muertas". La importancia de ese hecho reside en que era el fabricante principal de conversores *USB-UART*, utilizados en multitud de placas de desarrollo. En los primeros ocho minutos de este <https://www.youtube.com/watch?v=eU66as4Bbds> vídeo puede verse un resumen del suceso y del cabreo generalizado. Por suerte, sólo se borraba el identificador, utilizando para ello una pequeña diferencia de implementación a la hora de escribir 32 bits de golpe o en dos pasos de 16 bits (como descubrió, siempre brillante, marcan [6]). Al margen del impacto real de este hecho, es un ejemplo cercano al tan abierto mundo maker de lo que supone la *opacidad de los circuitos* integrados, y la dependencia de unos *drivers cerrados*. Desde el prisma del software libre, y en el caso de los componentes comunes en PCs, el requerimiento de drivers abiertos se tiene muy en cuenta y es uno de los aspectos que diferencia a algunas grandes distribuciones. Por contrario, con la emoción de encender luces, mover motores, y entrar en la Internet de todo a base de "copiar y pegar", parece habérsenos olvidado ese aspecto al enarbolar la bandera del hardware libre. Más concretamente, cuando se solicita a la comunidad de usuarios que compren placas Arduino certificadas para apoyar el hardware libre, quienes *están haciendo el agosto* son Atmel, ARM y cia. No quisiera que se interpretara en mis palabras la más mínima crítica al grupo que inició Arduino (especialmente habiendo conocido de primera mano la experiencia de Cuartielles). Pero siendo puritano, en aras de incentivar el debate, el movimiento maker ha matado al hardware libre, se lo ha comido con patatas. Volviendo a la rentabilidad, *hoy día* *no se puede vivir de fabricar hardware libre*. Lo que sí es posible, y lo estamos viendo con tantas tiendas de shields y otros tantos complementos, es comprar componentes básicos y de muy bajo coste, ponerles unos conectores estandarizados de facto y ofrecer un servicio de montaje y distribución. ¿Cuál es la diferencia con respecto a cualquier placa de desarrollo "clásica"? Únicamente el coste y el tiempo requerido para montar un prototipo funcional, a costa de perder en el aprendizaje que supone el camino. Al fin y al cabo, cuanto más rápido circulamos, más díficil nos es apreciar el paisaje. En mi humilde opinión, es una revolución pedagógica, de universalización del acceso a contenidos antes escondidos en documentos poco agradables para el novicio. Mas, como es propio de estos tiempos, *estamos impulsando un hype*, que se está convirtiendo en pura mercantilización del término, y es un mercado cercano a la saturación. Con respecto al *aprendizaje*, creo urgente acompañar el "Arduino/RPi *es muy fácil*" con un "*porque nos estamos saltando muchos pasos para hacerlo rápido*". Aprovechar estas nuevas herramientas para acercar la programación, la electrónica, las (tele)comunicaciones.. de forma amena a un público muy amplio, sí. Pero *recordando que* fuera del ámbito maker/hobby, *más allá de la fabricación de prototipos, hay que conocer lo que nos estamos saltando*. Hace tiempo que se leen consultas sobre aplicaciones domóticas o de automoción que, personalmente, me dan miedo. Cuestiones como sensores o multimedia creo que son inofensivas. Pero cuando leo sobre controlar las luces o bombas de riego de forma remota, me empieza a chirriar un poco. Y al ver cuestiones sobre monitorizar y programar lavadoras, o controlar las ventanillas de un coche a través del CAN, me asusto. Por resumirlo, lo barato sale caro. No soy entendido en redes eléctricas ni en EMC, pero al margen de cortocircuitos/chispazos/riesgos de electrocución puntuales, me produce desasosiego el impacto con uso continuado que la baja fiabilidad pueda tener en las instalaciones y, en el caso de los vehículos, en carretera. Por lo tanto, hacer algo "serio" sin saber qué hace exactamente cada instrucción que has copiado, y cómo y cuándo puede fallar, es caca. Además, cuanto más se extienden los sistemas empotrados, tanto que General Motors licencia en lugar de vender <http://www.microsiervos.com/archivo/tecnologia/ese-coche-no-es-tuyo-es-de-gm-tu-solo-tienes-una-licencia-para-usarlo.html>, resulta necesario conferir unos conocimientos, al menos básicos, sobre el contexto, y sobre la importancia de conocer la limitaciones detalladas de las características. En otras palabras, *hay que leer la datasheet* además de los tutoriales y guías. Adcionalmente, *ahondando en la seguridad*, a veces la información disponible en la hoja de características es insuficiente. Se puede consultar al fabricante, pero, a menudo, se requieren acuerdos de confidencialidad, por lo que no está accesible a cualquiera. Lamentablemente, esta forma de trabajar, *basando la seguridad en la opacidad, sólo ofrece una ventaja temporal* [7], y aunque la complejidad de los diseños actuales hace más difícil analizarlos mediante técnicas de ingeniería inversa, ya hay resultados basados tanto en side-channel como "desmontando" físicamente los circuitos capa a capa, como se expone en esta <https://www.youtube.com/watch?v=KVmpBPbGPsQ> charla en el 25C3 del Chaos Computer Club. Gracias a proyectos como ese y Fedora Electronic Lab, sí *se dispone de herramientas y librerías libres tanto para analizar como para diseñar ASICs*, es decir, hardware puramente libre. Esto es especialmente relevante en la era de la información, porque permite potencialmente identificar troyanos y puertas traseras [8]. Ahora bien, la industria de la automatización del diseño electrónico (EDA) es ciertamente particular, tanto que a empresas con más de diez años se les sigue considerando startups. Lo cual sirve como referencia del coste y consiguiente dificultad de mantener un negocio basado en el diseño, fabricación, producción y distribución de ASICs. Puesto que las herramientas y el material de laboratorio necesario no están disponibles para el público en general, naturalmente, este tipo de hardware libre *sólo puede evolucionar muy lentamente, ya que la base de contribuidores es ínfima* si la comparamos con el software libre. Y en cualquier caso, es muy poco probable que los diseños completos verificados hasta el punto de ser fabricables sean distribuidos. De facto, *no existe el hardware puramente libre, en el sentido de* Open Source Ecology <http://opensourceecology.org/>. Como resultado, el "*hardware reconfigurable*" se está extendiendo. Desde mediados de los ochenta se utiliza Field Programmable Gate Array (FPGA) como sinónimo de hardware reconfigurable, aunque hoy en día los dispositivos que se comercializan son System-on-a-Programmable-Chip (SoPC), ya que incluyen LUTs, DSPs, bloques de memoria, PLLs o gestores de reloj digitales, entradas/salidas de alta velocidad, núcleos ethernet/USB...incluso procesadores y conversores A/D. En cualquier caso, como ha sucedido con las arquitecturas de los procesadores durante los últimos casi cuarenta años, ante la nula viabilidad de implementar todas las aplicaciones en ASICs, se están extendiendo* un conjunto limitado de arquitecturas* de FPGAs con las prestaciones suficientes como para resultar *rentables al abarcar una o varias áreas de aplicación*. Éstas son *más restringidas que el diseño de ASICs*, pero ofrecen una *versatilidad mucho mayor que los procesadores*, y permiten* aceleraciones de varios órdenes de magnitud* con respecto a las soluciones software. La "magia" de las FPGAs, es que los diseños escritos en lenguajes de descripción de hardware (HDL) pueden ser sintetizados para generar un bitstream con el que configurar el dispositivo. El mismo código fuente que posteriormente puede utilizarse, con las debidas concreciones de implementación, para fabricar ASICs (no en vano, un mercado importante para las FPGAs es la simulación de ASICs en empresas de desarrollo de hardware). Como resultado, análogamente al software libre, de hecho, *utilizando licencias GPL/LGPL/BSD*, han surgido multiples repositorios <https://github.com/FreeJaus/elide/wiki/Code-repositories-recipes> *con módulos libres*. En comparación con Arduino, este tipo de soluciones permiten incrustar uno o varios núcleos de procesador compatibles, en los que es posible definir el tipo y número de periféricos a utilizar. En otras palabras, se puede ajustar el tamaño/consumo del procesador a cada aplicación específica. Aunque tampoco es necesario que se describa un procesador, ya que muchas aplicaciones se pueden resolver a nivel de transferencia de registros. El repositorio del CERN <http://www.ohwr.org/>, por ejemplo, muestra diseños de placas completas en las que se incluyen componentes discretos y descripciones HDL a implementar en una FPGA. Sin embargo, los *lenguajes como VHDL o Verilog*, que *huelen a viejuno*, y el flujo de trabajo para diseñar en FPGAs, *no han terminado de cuajar entre los desarrolladores de software*. Cuestión lógica por una parte, ya que son herramientas de diseño de hardware. Pero, recordando la rentabilidad, el ahorro en tiempo, consumo y mantenimiento que puede suponer el cambio de un diseño basado en un microprocesador/microcontrolador a un diseño hardware implamentado en FPGA, por un lado, y, por otro, el hecho de que haya un ingeniero de hardware por cada diez de software en el mercado, han provocado un deriva estos últimos años. Asumiendo la imposibilidad de enseñar a los ingenieros de software cuestiones de arquitectura de computadores a bajo nivel, si no quieren aprender,* las herramientas se han simplificado para reducir la migración* desde los entornos que les son conocidos. Por un lado, los grandes fabricantes, Xilinx y Altera, han introducido núcleos ARM en silicio, y han adoptado lenguajes llamados de *síntesis de alto nivel* (HLS). Estos, prometen, permiten utilizar el mismo código fuente (con una sintaxis simila a C/C++) tanto para la parte software como la parte hardware, incluyendo la paralelización mediante rutinas de precompilación similares a las utilizadas en librerías para computación paralela. En el caso de Altera, de hecho, se utiliza OpenCL. Pero, del mismo modo que el IDE de Arduino y sus plantillas limitan el aprovechamiento óptimo del procesador, en sistemas medianamente complejos es poco probable que el mismo algoritmo sea eficiente en un módulo secuencial y en uno que explota la paralelización. Otros, como Mathworks o National Insruments, han incorporado la *generación automática de código* a partir de sus respectivos entornos de diseño basado en diagramas de bloques. También han surgido otros muchos lenguajes, basados en C, Python o Haskell, para facilitar la generación de código VHDL o Verilog, facilitando una sintaxis más moderna y cercana a los desarrolladores de software. Con todos ellos, pueden obtenerse mejores resultados con respecto al software, pero sin un planteamiento desde el punto de vista del hardware* es probable que los requerimientos estén sobredimensionados*.* En el peor de los casos*, el código puede ser válido en software pero* producir errores difíciles de trazar* en hardware. Una vez más, saltar varios pasos de golpe puede resultar peor a la larga. En este caso el hype lo están impulsando los fabricantes con el objetivo de extender sus mercados. Como tal, *el mercado del "hardware" está imitando al software*. Por un lado se están incorporando paulatinamente "novedades" como el control de versiones o la integración continua. Por otro lado se comercializan módulos denominados Intellectual Property Core (IP-core), que vienen a sustituir un componentes discretos. Estos, a diferencia de los componentes disponibles en los repositorios abiertos previamente, son generalmente facilitados junto con las librerías de verificación e implementan la comunicación externa a través de un bus estandarizado, de forma que pueden ser conectado como periférico/co-procesador a un sistema basado en microprocesador. Su adquisición conlleva, además, un servicio de asesoría. Por razones que no acierto a definir, pero supongo que tendrá que ver con la especifidad de los mercados, *no conozco ninguna empresa que trabaje con "hardware libre" siguiendo este modelo*. En muchos casos se facilita el "código fuente" HDL, porque es la única forma de asegurar su integración adecuadamente, pero en prácticamente todos ellos con licencias muy restrictivas. FloPoCo <http://flopoco.gforge.inria.fr/> es una muy honrosa excepción, que sin haber establecido explícitamente la licencia por cuestiones legales (son un colectivo de investigadores y no está en sus manos), explicitan su voluntad de liberar el contenido y facilitan todos los recursos necesarios para la generación automática de operadores aritméticos. Desde que se empezaran a publicar resultados de la incorporación de FPGAs en los *centros de datos de grandes multinacionales* como Google, Amazon o Microsoft, y con ARM queriendo entrar en el mercado, los movimientos entre las empresas dedicadas al diseño de CPUs, GPUs y FPGAs se están cruzando continuamente. Tanto es así, que* Intel ha anunciado la inclusión de FPGAs en los Xeon*, y desde primeros de año hay noticias sobre su intento de compra de Altera. El futuro apunta a *arquitecturas* cada vez más *híbridas que requieran el dominio de varios lenguajes de programación para sacar el mejor partido de cada una de las partes*. Cada cual tiene sus filias y fobias, y a la hora de afrontar la revolución en la computación a la que estamos por asistir, las del Profesor Reiner Hartenstein son el hardware reconfigurable y las arquitecturas Von Neumann, respectivamente. En su artículo The relevance of Reconfigurable Computing <http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCIQFjAA&url=http%3A%2F%2Fwww.springer.com%2Fcda%2Fcontent%2Fdocument%2Fcda_downloaddocument%2F9781461400608-c1.pdf%3FSGWID%3D0-0-45-1178140-p174119270&ei=jqFtVdKVEIW7swHKloHoCQ&usg=AFQjCNGztC-5RXRnzkIVrdXl6EXLom0ZVg&sig2=j0yWBgL-IV263gSK_o-nLQ>, señala, además de cuestiones de rentabilidad para la empresa desarrolladora, por qué es necesario un *cambio de paradigma* y abandonar paulatinamente arquitecturas generalistas ineficientes en un contexto donde el consumo energético crece a un ritmo difícilmente* sostenible*. Como se deriva de las múltiples ideas expresadas en estos últimos párrafos, personalmente estoy de acuerdo con el fondo, pero veo realmente lejos el día en que el público general disponga de un conjunto de herramientas modernas y libres que les permitan trabajar con FPGAs con la misma facilidad que con microcontradores o single-board-computers. Hoy día, existen diversas alternativas, libres y cerradas, tanto para editar como para simular multiples lenguajes orientados a la descripción de hardware. Sin embargo, aquellos con interfaces modernas no son transparetes para el usuario, y las que lo son generalmente son editores de texto. Lamentablemente, esto es debido a la complejidad muchísimo mayor que supone obtener un bitstream de programación, en comparación con la compilación de un programa. Y, por otro lado, por las patentes que están en vigor y que impiden publicar información detallada sobre algunas de las partes más importantes. En los muy interesantes comentarios de este <http://curtis.io/others-work/open-tooling-for-fpgas> artículo publicado en Hacker News [5], se exponen los múltiples factores, implicaciones, y el estado del arte. Son especialmente ilustrativas algunas de las explicaciones del usuario ChuckMcM: > *This does a good job of capturing the first part of the problem. Note > that Xilinx did make an "open" FPGA part, the 3000 series, it did not do > well for them.* > > *The critical thing to understand, is that FPGA users (the big ones, not > the casual ones) don't want them to be open. They want the information they > program into them to be secret so that their hardware is not easily > duplicated by the folks in China and mass produced to under cut them. You > can't patent schematics. So these folks want to have a way that a board can > be assembled in China but not reproduced there in a way that isn't an exact > clone (which you can get blocked as a counterfeit product).* > > *Ok, so where does that leave us? Well it might be easier to create your > own FPGA design, have TSMC make it on their cheapest process. And then try > to sell those chips.* > > *And if you're saying "Jeebus Chuck! That isn't 'easy' at all." you would > be right. And that is why a 200Mhz general purpose CPU is easier to turn > into a "custom chip" than an actual custom chip.* > > *So where does that leave us? Well, all the bits between HDL and chip can > be done, in a low scale way, either in simulation or on bulk small scale > hardware. You can program CPLDs to be simple Logic Units (LU) for your FPGA > and wire them together on a PC board. You can find the things that need to > be parameterized (intra-LU timing, global clocks, I/O configuration) and > build tools which can synthesize, place & route, and download to your > "pseudo" FPGA. And if you have all that tooling, and you can show it works, > you might be able to get a partner to make some small scale parts for you > (200 - 1000 LUs)* > > *It won't happen over night, that is a 5 year plan minimum I think. And > you have to get over the hump of developing tooling for an FPGA that may > never exist. On the plus side it should be good for several Masters level > projects and probably a PhD or two, and if your simulation work was robust > you might become the 'standard model' for testing assumptions about > reducibility of different constructs into hardware.* > > *If you create a circuit board which has all of the same chips as someone > else, if you've changed the layout, you are completely within your rights > to sell it as your own and keep all the money. However, if you copy > firmware, then creating a circuit board with the copied firmware is a > copyright violation and you can be found guilty of copyright infringement > at most of our trading partners. For folks who built cloned CPU boards with > a copyrighted BIOS they re-implemented the BIOS in a clean room to have > their own "work alike" version, which then gave them the right to sell > their boards. If however you copy an FPGA bitstream, which is the compiled > output of a copyrighted HDL description, you're in violation. But building > a 'clean room' implementation of an FPGA bitstream is generally infeasible > as it requires you to both know how the manufacturer encodes and encrypts > it, and all of the functions of the internal chip.* > > *A really great example of this in action was that the recent flap over > "clone" FTDI USB to serial chips, wasn't a clone of the chip at all. > Instead the cloners used an ARM M0 CPU with a USB peripheral and a UART > peripheral and a bit of code that responded in all of the same ways in > which the FTDI chip (which was presumably an ASIC) responded. That > 'workalike' implementation was only possible because the set of inputs and > outputs for that system are constrained, and the only IP violation was the > re-use of FTDI's VID/PID pair. If they had been forced to use a bitstream > file for an FPGA they would be liable for up to $30,000 per copy, and jail.* > > Asumo, por lo tanto, que *disponer* de aunque sólo sea un único modelo de > *FPGA de tamaño medio cuyo diseño y herramientas sean libres, es una utopía en estos momentos*. Es cierto que en Hackaday ha habido un par de noticias interesantes últimamente [9] [10], simbólicas pero. Del diagnóstico anterior, concluyo que vamos, al menos, veinte años por detrás del software. Y eso es una oportunidad, porque* hay mucho por hacer*. Concretamente, sintetizando gran parte de lo expuesto a lo largo de este texto, hace unas semanas inicié un proyecto en GitHub que provisionalmente se ha denominado Embedded Logic Integrated Development Environment <https://github.com/FreeJaus/elide/wiki> (elide). El propósito, romántico, no es otro que unir en un sólo entorno libre a desarrolladores tanto de hardware como de software, de forma que puedan compartir algunas de las herramientas y se facilite así la transferencia de conocimientos y paradigmas de trabajo. La palabra clave para ello es *Eclipse*: es "multiplataforma", libre y tiene una comunidad de desarrollo activa; está extendido entre desarrolladores de Java y C/C++; hay plugins para trabajar con Arduino/AVR; Microchip facilita Arriba, que está basado en Eclipse; el IDE de OpenCL es Eclipse; el SDK de Xilinx es Eclipse; el IDE de Sigasi, el editor HDL más moderno disponible actualmente, es Eclipse; es el entorno sobre el que se están construyendo algunas propuestas nuevas, como NgDesign de Synflow. Sobre esta base, por el momento el proyecto es una recopilación de referencias a las muchas y muy dispersas herramientas que ya existen. Junto con algunos compañeros de la EUITI, estamos planificando reunirnos unos días en julio para tratar de poner en común nuestros puntos de vista sobre cómo *construir un "estándar" basado en XML que contenga diagramas de flujo/clases y código fuente en múltiples lenguajes*. Así, quienes trabajamos en hardware y software encontramos nuestro punto en común en los dibujos y símbolos que tan bien nos han venido desde hace algún que otro milenio. Pero, al mismo tiempo, y sin tener que cambiar de ventana, podemos utilizar cada cual su lenguaje, el que mejor se adapte a la arquitectura o aplicación sobre la que trabaja. Idealmente, se podría empezar por un mindmap de la aplicación y hacer alguna prueba de muy alto nivel con Python/Ruby. Adicionalmente, se podrían escribir los módulos en C/C++ y utilizar el código en Python para verificación. Se podrían añadir múltiples versiones C/C++ para comparar rendimientos, o enfocadas a diferentes arquitecturas, desde x86, pasando por ARM, hasta AVR, PIC, LEON3, OpenRISC o Microblaze. En caso de que se requiera acelerar más alguna parte simple de la aplicación, se podrían añadir decripciones de algunos módulos en lenguajes HLS. Por último, el mismo esquema podría utilizarse para el diseño con lenguajes HDL. Lo cierto es que *ya existen muchas de las partes* requeridas para alcanzar un entorno como el propuesto, pero la mayoría de ellas se desarrollan de forma aislada y/o son cerradas. Falta averiguar cómo relacionarlas. *Nuestra idea no es, a corto plazo, desarrollar nada, porque no nos vemos capacitados para ello*. Pero sí *revisar el estado del arte y trazar un esquema *donde se apunten los requisitos que creemos necesarios y cómo de cerca estamos de cada uno de ellos. Creemos, de hecho, que hacerlo ya es una revolución personal para los participantes, pues proviniendo de Ingenierías Técnicas Industriales a Informáticas, es notablemente disruptivo con nuestro curriculum académico. [0] http://ohkis.sourceforge.net/ [1] https://addi.ehu.es/bitstream/10810/13397/2/bildosola14_cnotice.pdf [2] http://es.wikipedia.org/wiki/ILLIAC_IV [3] http://www.ece.rice.edu/~cavallar/papers/91elsevier_svd.pdf [4] http://www.p2p-conference.org/p2p14/wp-content/uploads/2014/09/206.P2P2014_033.pdf [5] https://news.ycombinator.com/item?id=9408881 [6] http://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270 [7] https://www.youtube.com/watch?v=2q_qXGIj-jg [8] https://www.youtube.com/watch?v=QGIKhJrb9aA [9] http://hackaday.com/2015/03/29/reverse-engineering-lattices-ice40-fpga-bitstream/ [10] http://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/ 2015 eka 1 13:35 igorleak hau idatzi du ("Dani Gutiérrez Porset" < [email protected]>): > Los cursillos de software libre de Deusto con sus más de 10 añazos son un > referente de gran valor para mucha gente, y desde luego el espíritu del > software libre ha de ser colaborar entre universidades, colectivos y > personas, más en tiempos en que las implicaciones de cada cual no son todo > lo activas que nos gustaría. Por tanto, es una buenísima idea que desde > itsas también aportemos en esto, así no sea nuestra universidad. > > Personalmente me he apuntado a dar el de shell scripting, por si a alguien > le puede venir bien a pesar de que sea un tema viejuno, y animo a la gente > de las distintas facultades a pensar qué podríais impartir. Me consta que > al menos en la EUITI ya se ha organizado alguna actividad de software libre > a lo largo de este curso que podría ser rescatable para la ocasión. > > Salud(os) > > > _______________________________________________ > ITSAS mailing list > [email protected] > http://list.ehu.eus/mailman/listinfo/itsas > >
_______________________________________________ ITSAS mailing list [email protected] http://list.ehu.eus/mailman/listinfo/itsas
