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
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
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
*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]
[8]
[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" <
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
http://list.ehu.eus/mailman/listinfo/itsas