[Nuevo Icestudio] Conceptos e ideas

[Jesús Arroyo]

En relación a lo que comenta NexusVI en este hilo, creo este hilo para hablar sobre conceptos para un "Nuevo Icestudio".

Llevo tiempo dándole vueltas al concepto del nuevo Icestudio. Hay muchos conceptos e ideas interesantes que experimentar. Aunque todavía no me he metido con ello hasta que no tengamos una versión (superestable) de Icestudio 0.3 desktop para los tutoriales.

Realmente es un cambio profunto y total, pero con la ventaja de que tenemos un know how sobre funcionalidad y arquitecturas.

Durante el desarrollo de Icestudio he aprendido sobre "tecnología web", pero también me he encontrado con limitaciones y la necesidad de "hackear" varios componentes de los que estoy utilizando porque cada uno utiliza un framework distinto: para que os hagáis un idea el framework principal de Icestudio está escrita en ES5 es AngularJS (que simplifica el desarrollo HTML/JS) sobre NW.js (que permite convertir aplicaciones Web en nativas gracias a Nodejs). Además de esto utilizo los componentes JointJS (para los gráficos, basado en BackboneJS), AlertifyJS para las notificaciones (basado en Jquery), ACE (como editor de texto), Select2 (como "smartcombo") y múltiples paquetes de node. Sin olvidar la toolchain Apio, que es un componente escrito en Python, que utiliza Scons y gestiona los componentes precompilados de Icestorm, Icarus verilog, etc... Con respecto a las herramientas de desarrllo utilizo Bower y npm para la instalación de paquetes y Grunt como gestor de tareas.

Al replantearme la estructura del proyecto, con la experiencia del desarrollo, he llegado a las siguientes conclusiones:

• Desarrollo modular: la idea es dividir la aplicación en componentes o módulos independientes que puedan ser reutilizados o integrados en otros proyectos como un editor web, por ejemplo: el editor gráfico, el gestor de toolchain, etc.
  
• Utilizar tests: además de las ventajas obvias de tener tests unitarios me gustaría explorar nuevos tests de alto nivel como Jasmine, etc.
  
• Bajo el mismo framework: este framework será Angular2 (con TypeScript). Aunque hay miles de frameworks "equivalentes" creo que angular2 tiene muchas papeletas de conventirse en el ganador, aunque eso sólo el tiempo lo dirá. No se nada de Angular2, pero lo poco que sé me gusta con respecto a AngularJS es más determinista (ya no hay muchas formas de hacer las cosas dentro del mismo framework) y se basa en TypeScript, un superset de ES6.
• Utilizar ES6: también conocido como ES2015. Es una nueva versión con respecto a ES5 que contiene nuevos e interesantes conceptos (que me recuerdan mucho a Python :D).
• Crear un Apio JavaScript: utilizando nodejs se puede obtener la funcionalidad equivalente de Apio pero con la ventaja de que se integra como un componente de node más en la aplicación, simplificando el proceso de instalación y los requisitos de la app. Además Apio depende de SCons, que no tiene versión para Python 3, y eso me anima más a migrarlo.
• Sustituir JointJS: este componente es muy interesante y potente, pero tiene, respecto a nuestras necesidades, unas desventajas considerables, como la gestión de los SVG y el HTLM la hace de forma independiente, comportandose estos elementos como el agua y el aceite :S. Además está basado en BackboneJS (otro framework distinto de Angular). Por eso me gustaría explorar una nueva interfaz gráfica orientada a nuestras necesidades. Todo un reto :)
  
• Utilizar Electron en vez de NWjs: actualmente utilizo la versión anterior de 0.12.3 de NWjs, una versión obsoleta, puesto que en la siguiente iteración quiero utilizar Electron. Parece que durante este último año ha ganado fuerza y tiene ventajas como empaquetados nativos para ARM, mejor soporte, etc. Otra cosa para explorar.
• Notificaciones, combos, etc nativos: reescribir estos componentes para Angular2. La integración será infinitamente más agradable y limpia.
  
• Utilizar yarn y Gulp en vez de npm y Grunt: estos programas son herramientas de desarrollador. El hecho de sustituirlos ya está entre el vicio de aprender y que parece que los propuestos son mejores y más utilizados.
• ... ∞

Además he visto que la comunidad ha empezado a desarrollar en JavaScript visualizadores del rutado de las FPGAs (https://knielsen.github.io/ice40_viewer/ice40_viewer.html), compresores de bajo nivel, generador de diagramas de señales (https://github.com/drom/wavedrom), ...

Como véis hay muchas cosas interesantes por hacer. Lo bueno de la orientación modular es que se simplifica el desarrollo ya que se pueden generar componentes independientes en paralelo y posteriormente combinarlos en una aplicación de usuario.

Si os interesa alguno de estos campos os animo a investigarlo y compartir el conocimiento aprendido en forma de Aprendizaje colectivo.

Un saludo.

[Carlos]

Que tal Jesús,

Nunca pude arrancar a aprender JS y creo que este nuevo planteamiento me puede servir para aprender esta tecnología. Me interesaría aportar en la generación de los gráficos, ¿Tienes pensado algún componente para esto?

Y ¿Podrías (o alguien más) sugerirme alguna fuente o tutoriales para comenzar con el desarrollo con JS?

Saludos
- Carlos

[Jesús Arroyo]

Hola Carlos,

La parte gráfica es muy interesante. Como comento al principio, me gustaría reemplazar JointJS por un módulo nuevo basado en Angular2. Lo que me gusta de Angular2 es que puedes tratar los SVGs y HTML de forma similar, aunque seguramente tenga otros inconvenientes que aún no conocemos. Te dejo un artículo que leí hace tiempo que muestra cómo trabajar con SVG: https://teropa.info/blog/2016/12/12/graphics-in-angular-2.html.

Hay mucha documentación disponible. Los cursos de https://www.codecademy.com/ suelen estar bien. Yo tengo pendiente hacer este tutorial: https://angular.io/docs/ts/latest/tutorial/. Y seguramente haya muchos más. Yo generalmente para aprender me leo la documentación y lo pongo en práctica con ejemplos. Yo sigo en nivel noob JS así que seguramente gente con más experiencia pueda indicarte mejores fuentes.

Un saludo.

[patripi]

Hola,

yo también tenía curiosidad y me estoy haciendo uno básico de este tío http://programmingwithmosh.com/angular/angular-2-tutorial/ que va bastante al grano y en 15 min tienes una app simplona corriendo en tu local server y entendiendo aceptablemente cómo lo hace. En udemy tiene uno de 9h por 15 eur que ya os diré qué tal, por ahora muy bien para alguien como yo que hace 15 años diseñé y piqué enterprise apps y portales en tres capas con tecnologías .jsp, .aspx c#, algo de js y a nivel detalle no tengo ni idea de nada posterior, incluido angular 1. Creo que tiene otro avanzado que entra ya en el unit testing, etc, pero es más caro solo lo vería solo útil si compensa por el ahorro de tiempo...

Saludos

[Carlos]

Que tal Jesús,

Gracias por los links, los estaré revisando. También encontré un tutorial de Mozilla sobre los conceptos básicos de JS [1], y algunos otros sobre TS [2], no había programado nada para la web pero parece "fácil".

Saludos
- Carlos

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript?redirectlocale=en-US&redirectslug=JavaScript
[2] https://code.tutsplus.com/tutorials/getting-started-with-typescript--net-28890

[NexusVI]

Hola.
La decision de elegir Angular2 me parece muy acertada. Yo de hecho tambien estaba aprendiendo este lenguaje por lo que me ofrezco para hechar un cable dado el caso.
Para los que les gusten mas los videos que los tutoriales escritos, os recomiendo los de Jesus Conde que son bastante estructurados y cortitos al mas puro estilo obijuan... https://www.youtube.com/watch?v=YBrlRGO-iCI

Con respecto a JointJS, has visto mxgraph? Yo no lo he probado pero es el que se utiliza en https://www.draw.io/ y tiene buena pinta... https://github.com/jgraph/mxgraph

No me habeis dicho que os parece la idea de deslocalizar el frontend del PC. Yo no le veo mas que ventajas... ^_^
En el peor de los casos habria que instalar un mini tool que levante un WebService en localhost para hablar con la web, implementando solo comunicacion con USB y drivers...

Un Saludo

[Jesús Arroyo]

Hola Carlos, gracias por los enlaces.

Hola NexusVI, le echaré un vistazo a los tutoriales. Draw.io es para dibujar diagramas, pero no es tan flexible como JointJS para Icestudio. De todas formas creo que se pueden aprender cosas interesantes de mxgraph.

Lo de la idea de hacerlo backend y frontend es muy factible, Con la orientación de módulos y paquetes independientes se puede por un lado envolver la funcionalidad de la toolchain con un API y acceder al API remotamente desde el editor en un browser o una aplicación híbrida. Ahora mismo el "backend" es Apio, aunque las llamadas se hacen directamente. En la versión actual de Icestudio implementé algo equivalente para programar la icoBoard en la Raspberry Pi desde un Icestudio en tu PC. Funciona ejecutando remotamente a través de SSH comandos de Apio instalado en la RPi. Tiene las ventajas de la ejecución remota, pero las desventajas de la velocidad, puesto que tarda mucho más en sintetizar desde la RPi.

Por ese motivo, al replantear de nuevo "Apio en Javascript" habría que implementar un API Rest o RPC para que se pueda acceder remotamente, pero con la posibilidad de instalar la toolchain o backend en el cliente por temas de velocidad de síntesis y consumo de ancho de banda. Todo esto se traduce en un montón de experimentos por hacer, así que os animo a probar las ideas que se os ocurran :)

Un saludo.

[Carlos]

Hola,

Hasta ahora he utilizado el scratchpad y consola de Firefox para familiarizarme con JS, ¿recomiendan algo diferente, algún IDE?.
¿es posible hacer profiling en la aplicación?, no se si pueda ser útil.

Saludos
-Carlos

[NexusVI]

Jesus, estoy viendo realmente pocas librerias de diagramming en typescript  :-(

He visto que esta tiene buena pinta y esta escrita en typescript. Es para React pero igual se puede adaptar  a Angular..
https://github.com/projectstorm/react-diagrams

[Jesús Arroyo]

Hola NexusVI,

Sí, hay pocos recursos en Typescript para Angular, pero precisamente por eso. La idea es crearlo desde cero :)

Gracias por el enlace de react-diagrams! No lo conocía. Seguro que puede servir como referencia.

Un saludo.

[1138-4EB]

Hola Jesús y cía:

Siendo consciente de que el contexto que voy a plantear puede parecer lejano para un proyecto que acaba de cumplir un año, creo que el título y algunas de las ideas planteadas/referenciadas dan pie a su exposición. Si queréis ir al grano, saltad los tres primeros párrafos.

He seguido con cariño el desarrollo de Icestudio, ya que llevo varios años a la espera de que expiraran las patentes para que el contenido académico sobre P&R, bitstreams y reconfiguración pudiera empezar a ver la luz. Creo que dispondremos de hardware (electrónico) libre con la primera FPGA tostada con obleas libres. No quiero prender fuego con esto, ya que no me opongo al uso que se hace del término en Arduino/Genuino, RaspberryPi o en FPGAwars. Sirva únicamente para plasmar que llevamos casi cuarenta años de retraso, aunque el lenguaje nos permita jugar con los términos y el marketing.

Particularmente, llevo más de cinco años trabajando intensivamente con VHDL, FPGAs y SoCs de Xilinx; y es continua la frustración con las herramientas (no las de Xilinx sólo). Pasando por alto el tipo de licencias utilizado y el factor económico, simplemente se notan esos cuarenta años. Las suites son por lo general (muy) pesadas y, o muy poco user-friendly, o tan friendly que deciden todo por ti. Sin embargo, lo más descorazonador es que ninguna de las tres grandes que he probado permite editar diseños en modo esquemático (diagrama de bloques) y texto al mismo tiempo. Prácticamente todas permiten introducir diagramas por un lado y texto por otro, o usar uno/otro en función del nivel de abstracción (véase Vivado/Simulink). Pero cuando digo al mismo tiempo, me refiero al mismo fichero/módulo/componente. La explicación rápida, es que se notan esos cuarenta años, y en HDL se programa en Vim/Emacs. Si queréis nos extendemos en esto.

Sin embargo, yo encuentro necesario dibujar (al menos bocetar) cada uno de los módulos de un sistema antes de describirlo. Si habéis utilizado Tikz (LaTeX), seguro encontraréis el parecido con las descripciones estructurales en HDL. Más allá considero que una equivalencia directa entre un trozo de código y un símbolo es de mucha ayuda para quienes están aprendiendo. Especialmente para quitar los vicios del software, que a menudo traga más de lo que debería. Y muy particularmente para quienes empiezan la ESO, que para cuando acaben las carreras verán las FPGAs como si fueran Arduinos estos últimos años o PICs los diez anteriores.

---------------------------------

El grano, es que una vez al mes (más o menos :D) acumulo la mala leche e intento hacer algo productivo de ello revisando el estado del arte (léase gugle) para 'El IDE libre de lógica embebida/empotrada'. Y donde digo 'El', quiero decir 'Mi idealización'. He intentado un par de veces hacer algo yo mismo. Pero he acabado por asumir, parafraseando a Donald Knuth que 'software is hard'. La versión larga de referencias, más o menos ordenada, está aquí: https://github.com/1138-4EB/ghdl-tools/blob/master/wip/vhdled.md Naturalmente, hay muchos aspectos en común con Icestudio, pero al haberme centrado en VHDL he configurado una estructura de herramientas diferente. A continuación los aspectos diferentes:

• VHDL en lugar de Verilog. Al margen de preferencias, hay tipos de VHDL que no se pueden representar en Verilog. Por lo que una conversión VHDL a Verilog limita las posibilidades del VHDL. Ver formato GHW en la documentación de GtkWave.
• No he encontrado ningún parser de VHDL (hasta 2008) libre lo suficientemente maduro. De hecho, tampoco 'no libre'. Sin embargo, en este punto es digno de alabanza el trabajo de Tristan (GHDL), a quien ya conocéis. Tiene una herramienta muy potente y capaz, pero que requiere un refinamiento de la API, especialmente este último año que ha crecido notablemente la atención. Técnicamente no es muy difícil, pero el hecho de estar programado en Ada y que quince años de estructura del programa estén sólo en la cabeza de una persona, nos obligan a tener paciencia. Personalmente, estoy tratando de ayudarle en tareas auxiliares para i) que pueda centrarse en el código y reducir las 'consultas', ii) ir empapándome de cómo es GHDL por dentro para (con suerte) colaborar en alguna feature no crítica.
• ¿Por qué VHDL2008? Añade muchas características que facilitan la reutilización de los diseños, la sintaxis es ligeramente menos redundante, y en general resulta más cercano a quienes vienen del software.
• Hay un puñado de herramientas para verificación y generación de testbench que, junto con GHDL, hacen un ecosistema libre muy potente: VUnit, PoC, cocotb, OSVVM...
• Escalabilidad y optimización. No soy consciente de haber utilizado ninguna aplicación en Nodejs. Lo más parecido puede ser el editor Atom y no acabo de estar muy contento (aunque bien puede ser por la implementación y no por el framework). Por ello, puedo estar condicionado. En cualquier caso yo había puesto el ojo en Golang (por evitar C/C++), pensando en el IDE como un servicio (binario) conectado a un cliente ya sea en un navegador web u otro binario con Qt. La pregunta, de todos modos, no es si es mejor go, sino ¿habéis hecho alguna prueba para ver cómo ser comporta icestudio con diseños grandes? Todavía no hay soporte para añadir k instancias de un módulo/componente. Pero tan pronto como se añada una funcionalidad equivalente a los 'generate' de VHDL, es de esperar que los diseños crezcan. En una FPGA de la serie 7 de Xilinx como las que están empezando a analizar, entra muchísima lógica en comparación con las icestick. Quizá este sea un momento adecuado para valorar qué tareas pueden ser problemáticas en un futuro, y considerar con la modularidad no sólo la funcionalidad sino la preparación para una futura utilización de diferentes lenguajes.
• Para el layout de los diagramas, por ejemplo, http://www.ogdf.net/doc-ogdf/ puede ser una alternativa interesante si las cosas se ponen complicadas.
• No sé hasta qué punto 'mover' los bloques en un esquema puede ser exigente en diagramas con muchos bloques, por lo que JS haga llorar al navegador. En este caso el límite (si lo hay), obligaría a pasar a escritorio. Había considerado QML (con Go), pero no estoy seguro de que eso sea más eficiente que JS (por QML).
• Representación gráfica jerárquica y sincronizada con las fuentes. KiCad es otra herramienta técnicamente muy potente, y que está teniendo un desarrollo espectacular últimamente. El hecho de que el CERN se haya involucrado le da cierta cobertura. Es muy compleja para lo que estamos tratando, pero hay varios aspectos que merecen la atención:
• Soportan hojas jerárquicas, que en VHDL equivaldría a la instanciación de componentes.
• Cada componente en el esquemático es una caja negra con un número de patillas, a la que después se le asocia (referencia/puntero) una funcionalidad (de una librería). Si las patillas son las mismas, el esquema no cambia. Esto es exactamente el uso de las 'entities' y 'architectures' en VHDL. Jesús, creo que una aproximación así podría ayudarte con el problema que tiene al cambiar un módulo (que lo eliminas y lo vuelves a crear).
• Existe una doble representación para cada módulo y conexión: una en el esquemático y otra en el PCB. Todos los cambios de conexiones que se realizan en uno u otro se sincronizan. Se puede aprovechar la misma estructura para sincronizar el esquemático con HDL. Solo hay un posible problema: no todo en VHDL es descripción estructural. Se soluciona de la siguiente manera: cada estructura conocida es una caja (multiplexor, multiplicador, registro), cada proceso cuyo contenido no es conocido es una caja negra, y todas las sentencias concurrentes desconocidas se unen en una sola caja negra. En el 'peor' de los casos (que no se reconozca ninguna estructura), tendremos una serie de esquemas estructurales que nos permitan explorar/navegar la jerarquía del diseño, y cada caja el texto en crudo, como lo muestra icestudio.
• Ya que KiCad permite diseñar PCBs en los que un componente sea una FPGA/CPLD, la integración del punto anterior como una herramienta auxiliar en KiCad permitiría utilizar el mismo entorno para integrar todo el diseño. Teóricamente KiCad es modular, por lo que no es necesario tener todos los programas del paquete instalado. Así, quien vaya a hacer 'diseño lógico' sólo necesitará el de esquemático y el de HDL. Quien haga la placa sólo el esquemático y el PCB. Y si alguien quisiera soñar un poco más, utilizando todos los esquemáticos de ambos y las fuentes a las que referencian, dispondría de todos los datos para hacer una simulación mixta del sistema.
• Técnicamente se puede enlazar GHDL con Spice (http://ngspice.sourceforge.net/roadmap.html), pero no lo he probado. VPI o VHPI servirían para ello.
• He preguntado recientemente, y por lo visto en la actualidad los programas que componen KiCad no se distribuyen por separado. Aunque puede ejecutarse cada una directamente desde el binario correspondiente, y posiblemente aislarla sólo con las librerías de las que depende.
• Alternativamente, la idea de utilizar una representación intermedia entre el VHDL y el esquemático, contra el que se sincronicen ambos, se puede implementar imitando a git, o con git directamente. Es un workaround pesado, pero que puede evitar comprobar cómo lo hace KiCad, o tener que implementarlo desde cero. Sirve como prototipo.
  

A partir de aquí, repoker:

• Gamificación. La representación intermedia es especialmente interesante porque nos permite describir sistemas digitales muy complejos en VHDL y obtener una versión elaborada de GHDL adaptable a diferentes visualizaciones. La más directa es representar circuitos en 3D, como una serie de capas en 2D apiladas. Esto también está en KiCad, donde a partir del PCB existe una tercera representación basada en modelos sólidos. Visualmente, sería cómo separar las capas del PCB de forma que se dibujaran las pistas verticales. Sólo que en lugar de componentes del PCB lo que se dibujaría sería el esquemático (dando un pequeño volumen a cada caja).

• Se puede reutilizar la librería OGDF para posicionar elementos también en 3D y que no choquen, creo. Se pueden reutilizar los algoritmos de rutado de KiCad.
• La representación 3D de KiCad se puede exportar a FreeCad. Mejor aún a esa 'representación intermedia' que teníamos por ahí. En FreeCad se puede 'explorar' el circuito como si de Tron se tratara, mover y recolocar los componentes. Hacer click y abrir un editor de texto con el fichero en el que está definido ese bloque (no pidamos la línea).
• Lo anterior ya es un poco de gamificación, pero teniéndolo, se puede ejecutar GHDL y animar algunos de los bloques con las salidas. Lo que es un prototipo de videojuego de puzzles lógicos. O una herramienta para el aprendizaje de sistemas de control. O... ¡imaginación! En este sentido, me suena haber visto algún proyecto de una impresora 3D parametrizada/animada con Python en FreeCad. Volviendo a la optimización, dudo mucho que algo así funcionara bien. Pero el objetivo inicial era sólo editar texto y esquemáticos XD.
  

 
---------------------------------
 
Volviendo a la realidad, en el estado de desarrollo en el que está icestudio, creéis que merece la pena pensar en cuál es el formato más adecuado para esa 'representación intermedia'. Naturalmente no tiene que ser un fichero, pueden ser varios VHDL/Verilog, varios esquemáticos y uno que haga de puente entre ambos guardando únicamente referencias. Ese puente puede guardar un listado de entitades, arquitecturas, representaciones 2D de las cajas, y conexiones. Además, el modelo de sincronización no se limita a dos controladores/vistas, sino que puede haber más (que sólo modifican la adición/eliminación de referencias y conexiones). Cada vista se encarga de sincronizar su representación con la intermedia. Si desde una vista se solicita modificar un componente de otra forma, se busca la referencia y se inicializa la otra vista. Cuando termine, veremos el resultado en la actual. Todo lo anterior considerando que habrá muchas instancias iguales, en las que solo cambie el nombre y la posición.

Si no he entendido mal, icestudio tiene actualmente un formato propio que es esa 'representación intermedia' y tiene dos controladores/vistas: la gráfica y la exportación a Verilog. La gráfica es bidireccional, pero Verilog es sólo lectura.

Por otro lado, desconozco la complejidad de distribuir la aplicación en múltiples plataformas. Recientemente he empezado a utilizar Docker tanto en Travis-CI, como en Fedora y Windows 10, y estoy muy satisfecho con el resultado. En GNU/Linux se puede compartir un USB del Host, por lo que posiblemente podríais integrarlo todo en una imagen que se arranque con un comando y (opcionalmente) muera al dejar de usarla (manteniendo sólo los ficheros que el usuario haya querido guardar). En Windows no he probado a compartir USB. Por otro lado, en principio no se pueden ejecutar aplicaciones con GUI, pero teniendo en cuenta que icestudio puede tener una interfaz web, esto puede no ser un problema. La ventaja: cada usuario ejecutará exactamente la misma imagen que Jesús utilice para desarrollo, con las mismas librerías en las mismas ubicaciones y las mismas versiones.

Espero que alguno de estos planteamientos os hayan servido, al menos, para coger ideas o replantearos alguna. Me gustaría comentar los puntos que consideréis interesantes, para hacerme una idea de cuál es la ruta que va a tomar icestudio, y así continuar configurando el puzzle hacia ese IDE ideal.

Saludos

[Cristóbal Contreras Rubio]

Buenas Unai,

el correo es buenísimo, a mi me ha gustado mucho, está muy bien argumentado y coincido contigo en varias cosas.

Con respecto a lo que dices de icestudio, sinceramente es que creo que hay que verlo como un IDE de aprendizaje, "de juguete", o como se quiera decir. Es similar al IDE de Arduino, una herramienta educativa. Pero como herramienta "seria" / profesional, yo no la veo ni creo que sea el enfoque de los desarrolladores (que me corrija Jesus si me equivoco). Me explico:

• Uno de los mayores problemas de las herramientas profesionales es lo sumamente lentas que son.

• Otro de los problemas que tienen las herramientas profesionales es lo pesadas que son (el webpack de Vivado una vez instalado creo que se quedan en +10Gb).
• Icestudio está basado en tecnologías web para escritorio, que si por algo se caracterizan es por el mal rendimiento que dan (veo que tu eres otro de los que lo han sufrido con Atom).
  
• En cuanto tienes un equipo escaso (pongamos un ordenador de colegio, o viejo, o una Raspberry Pi), todas estas herramientas son un dolor.
• Si le añades que en cuanto lo exprimas con diseños gordos el rendimiento va a caer en picado, no lo hacen quizás una de las mejores elecciones para el IDE como tal crezca.
  

¿Estoy diciendo que Icestudio es una mala herramienta? ¡¡¡PARA NADA!!! Es un IDE que creo que tiene un nicho muy claro, que es el de aprendizaje y la iniciación. Tiene otro punto buenísimo a su favor: si se quiere hacer una versión web, ya tiene prácticamente todo el desarrollo hecho, evitando instalaciones y la pérdida de tiempo que eso conlleva por ejemplo para un taller (que no así en rendimiento).

Resumiendo, creo que en mi modesta opinión icestudio mola 1000, pero no podemos verlo como una herramienta profesional ni creo que sus creadores se lo hayan planteado así.

Espero que nadie se ofenda por mi comentario y en especial Jesus. Creo que el trabajo que estáis haciendo es brutal y encima desinteresadamente. Es muy fácil criticar sin pringarse las manos, y para nada es una crítica o al menos no destructiva.

Saludos

 

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a43d43ae-0325-4bb9-bd60-b86985025857%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Jesús Arroyo]

Buenas a todos,

Os comento brevemente.

Icestudio es un experimento orientado a:

• investigar y explorar el uso de las FPGAs libres
• aprender nuevas tecnologías de desarrollo web
• hacer más accesible la tecnología de las FPGAs
  
• ...

¿Por qué Verilog?: porque es el único soportado de forma estable por el proyecto Icestorm. ¿Node.js, Electron?: sí, son tecnologías muy potentes y cada vez más utilizadas incluso por grandes empresas.

Como siempre, os animo a realizar alguna contribución y compartirla. Al final ésta es la única forma de avanzar y enriquecer el patrimonio ;)


PD: en Windows podéis utilizar Visual Studio Code en vez de Atom. Me han comentado que está más optimizado para este sistema operativo, pero sigue utilizando Nodejs y electron.

[NexusVI]

Lo primero, dar las gracias a Unai por compartir!
He encontrado muchisima informacion en tu correo que me ha resultado super interesante. Gracias!

Despues, he hecho una prueba de estress en icestudio muy sencilla que creo puede ser interesante. Basicamente lo que he hecho es meter 1000 puertas AND en un diagrama. No las he conectado por que me he hecho un script super rapido en 5 minutos para generar un fichero .ice con esta informacion y meter cables me complicaba el tema... Os adjunto el fichero por si quereis probar vosotros mismos.
Las pruebas las he hecho en un Windows 7 64bits, el ordenador es un portatil i5 normalito del curro.

IceStudio tarda en mi ordenador como 50 segundos en cargar el file. El desplazamiento de todo el diagrama no funciona bien con tantos elementos (era de esperar) y el zoom va bastante lento (mejor de lo que esperaba). Por lo demas me funciona bastante bien, los elementos se pueden mover de forma individual sin problemas y se puede cablear tambien sin problemas. Creo que es fastante factible optimizar el pan y el zoom con esto en mente, llegado el momento.

Sinceramente no creo que haga falta tener tantos elementos jamas dentro de un diagrama, ya que icestudio te permite diseñar modulos independientes y luego añadirlos como bloque (incluso anidados uno dentro de otro!) con lo que no creo que visualmente tengas necesidas de tener de golpe todos los elementos en pantalla...

Un Saludo

[Jesús Arroyo]

Hola NexusVI,

He probado el fichero test.ice en Linux. En este caso tarda 15 segundos en cargar, de los cuales 14 está JointJS creando celdas (otro motivo más para crear un nuevo framework gráfico!).

Es un caso de uso muy poco frecuente tener tantos bloques en un mismo diagrama, pero no está de más la prueba.

Un saludo.

[NexusVI]

Si, suponia que en linux funcionaria bastante mejor pero me parecia interesante probar el caso mas comun para un usuario normal... Y efectivamente es lo que yo decia, con los bloques seguramente nunca tengas tantos en pantalla.
Me mola mucho la idea de crear un nuevo framework grafico en typescript, me gustaria apuntarme!... ^_^

[Jesús Arroyo]

Apuntado! XD

Primer paso: aprender y empezar a hacer pequeños experimentos con Angular 2 y subirlos a GitHub.

Yo voy a intentar ir más rápido de lo que crece mi TODO list, pero en algún momento comenzaré también a experimentar con gráficos en Angular.

Si quieres puedes crear un hilo para ir comentando los experimentos.

Un saludo.

[Unai Martinez]

Buenas Cristóbal,

Como dijo Jack, vamos por partes:

2017-03-02, 8:20, Cristóbal Contreras Rubio:

Con respecto a lo que dices de icestudio, sinceramente es que creo que hay que verlo como un IDE de aprendizaje, "de juguete", o como se quiera decir. Es similar al IDE de Arduino, una herramienta educativa. Pero como herramienta "seria" / profesional, yo no la veo ni creo que sea el enfoque de los desarrolladores (que me corrija Jesus si me equivoco).

Eso lo entiendo y lo apoyo. Para avanzar hay que caminar. Sin embargo, la diferencia principal entre icestudio y el IDE de Arduino es que, en el segundo caso, pasar a Code::Blocks o AVR Studio es directo. Esto es así porque en el fondo todo son librerías escritas en C. De hecho, la potencia de Arduino es que cualquiera puede utilizar librerías 'profesionales' (ASM/C/C++) sin saberlo. Resulta impensable, por ejemplo, que usuarios nuevos puedan utilizar tres timers en un atmega de forma sincronizada. Aun así, lo hacen continuamente porque alguien ha hecho una librería que lo gestiona por ellos.

Sin embargo, AFAIK, icestudio actualmente está completamente desligado de cualquier input que no sea el propio formato ice. Este es un formato que mezcla información sobre la representación gráfica y código en el mismo fichero. En este sentido es diametralmente opuesto a Arduino, ya que para aprovechar el contenido existente exige que usuarios avanzados rehagan sus diseños y los adapten a un formato sin recorrido evidente. Creo que este hecho representa una barrera para aprovechar el contenido, que ya está bastante disperso (en mi mensaje anterior hay referencias a varios repositorios de diseños HDL con licencias libres).

Quiero que se entienda que cuando hablo de usos 'avanzados' lo hago siempre tomando el estado actual de icestudio como referencia. Por ejemplo, mi PFC fue un PID en VHDL para controlar un motorcito por PWM. Esta licenciado bajo GPL y CC, por lo que podéis ver la memoria, las fuentes y la presentación: http://ohkis.sourceforge.net/ (pestaña Anie). Si omitimos por completo la salida VGA, el LCD y los pulsadores, el sistema tiene exactamente dos salidas para un puente H externo, y dos entradas para el encoder incremental. La lógica está compuesta por:

• 2 Digital Clock Manager encadenados: para generar la frecuencia de reloj deseada.
  
• PID (pág. 1-43 o 60/259): tres multiplicadores, 5 sumadores/restadores, 4 registros y 2 bloques de saturación.

• Bloque de saturación: 1 comparador, 2 multiplexores y 2 inversores de signo; o 2 comparadores y 2 multiplexores.
• PWM (pág. 1-74 o 91/259): un contador, 1 o 2 comparadores por cada PWM, y 1 o 2 muxes de un bit.
  

Digamos que, grosso modo, son 25 componentes elementales (mult, mux, addsub, reg, cont...). No es un diseño tirado para quien no tiene experiencia previa con FPGAs. Pero es una tontería para cualquiera con un mínimo de experiencia. Puedo colaborar reescribiéndolo en Verilog (aunque nunca he profundizado en ello). También puedo hacer una descripción más genérica en VHDL/Verilog donde sustituya los multiplicadores, comparadores y multiplexores, por componentes descritos únicamente con puertas lógicas y/o full-adders de un sólo bit. Como es de coma fija con tamaño variable, puedo usar el mismo tamaño de palabra (8/16/32 bits) para que sea más cercano al software. También puedo sustituir los multiplicadores por tablas. Todo ello para adaptarlo a yosys y que se pueda utilizar en la Alhambra.

No obstante, mi objetivo principal es facilitar el aprendizaje del diseño de sistemas basados en FPGA. Ninguna de las anteriores es una solución didáctica. Lo que sí sería didáctico es poder ver y modificar esas fuentes en icestudio. Para entender, por ejemplo, cuándo es estúpido utilizar cuatro contadores si quieres generar cuatro PWM, pudiendo imitar a los uC y usar uno solo. Pero, para entender también por qué es ineficiente utilizar un solo contador si las PWM van a tener frecuencias o resoluciones muy dispares.

En este contexto, puedo esforzarme en entender el formato de ice y convertir el VHDL/Verilog. Como la figura de la memoria (pág 1-74) está hecha en Tikz, puedo coger las coordenadas y meter también el posicionamiento de cada bloque. Pero definitivamente no es algo que quiera hacer para cada uno de los bloques. Hay algún otro muy interesante como la salida VGA pág. (1-61 78/259), que con un reloj de 25MHz sólo necesita 2 contadores y 6 comparadores para una resolución VGA (640x480). Lo digo de memoria, pero creo que para 1024x768 sólo se necesitaba un reloj de 40MHz (sin cambiar la lógica). Tengo por ahí también, un controlador para el puente de motores BLDC.

Siguiendo sólo con el PID y PWM, supongamos que queremos controlar los cuatro motores de un dron. Para simplificarlo, toda la orquestación y algorítmica del control la hará una CPU, por lo que la lógica se limitará a los cuatro PID/PWM y los cuatro contadores para calcular la velocidad. Esto sigue siendo un toy example en el contexto de las FPGA, y un target muy interesante para que los nuevos entiendan qué sentido tiene usarlas en lugar de los uC (además de porque es 'nuevo' y guay). ¿Cómo introduzco eso en icestudio sin tener que posicionar y cablear a mano?

Entiéndase que no pretendo que icestudio lo permita ahora, ni dentro de un mes, ni dentro de dos años. Sólo quiero saber cuál es la opinión de los desarrolladores al respecto. Si se prevé para dentro de un año, se espera. Si no se prevé, otra vez será.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

Me explico:

• Uno de los mayores problemas de las herramientas profesionales es lo sumamente lentas que son.
• Otro de los problemas que tienen las herramientas profesionales es lo pesadas que son (el webpack de Vivado una vez instalado creo que se quedan en +10Gb).

Creo que nos estamos liando con los términos. No quisiera mezclar las herramientas profesionales, aquellas cuyo estado de desarrollo posibilita su utilización a nivel profesional, con las suites de pago dirigidas a un uso profesional. Para que nos entendamos, Windows ocupa más que GNU/Linux, 3DS/Maya ocupa más que Blender, AutoCAD ocupa más que FreeCAD, Photoshop ocupa más que GIMP... Considero todas las anteriores herramientas profesionales, las cerradas y las libres. Creo que son ejemplos evidentes de que no por ser más pesada y lenta es más potente una herramienta. O, al menos, que no todos los usos profesionales requieren las opciones más pesadas.

Como valor cuantitativo, GHDL y sus librerías ocupan 3-13 megas, dependiendo del compilador utilizado. Junto con GtkWave, son 45 megas en mi disco ahora mismo. En el contexto que nos movemos, no tienen absolutamente nada que envidiar al webpack que has comentado, hasta llegar a yosys, donde no puedo profundizar.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

• Icestudio está basado en tecnologías web para escritorio, que si por algo se caracterizan es por el mal rendimiento que dan (veo que tu eres otro de los que lo han sufrido con Atom).
  

Esto lo compartimos, aunque bien puede ser un prejuicio en muchos casos. De todas formas, quiero que se entienda que me da bastante igual, porque yo no soy el público objetivo de icestudio. Entiendo que el objetivo son los usuarios nuevos, y me interesa muy especialmente que llegue a gente más joven que yo: a las clases de tecnología de la ESO, centros de formación, primeras semanas de universidades... Esos colectivos son los que tienen que juzgar lo bonito, intuitivo o cómodo que es, tanto su uso como instalación y portabilidad. A mí en estos momentos me interesa colaborar aportando ejemplos. Más concretamente, tratando de idear una forma más o menos eficiente para que se puedan aportar. Particularmente, no quisiera ponerme a hacer scripts para convertir algunos de los diseños 'fáciles' y descubrir luego que no sirven porque el formato ha cambiado o alguna característica del mismo se interpreta de forma diferente. Más allá, puestos a especificar el formato para tener documentado su estado y su roadmap, con el objetivo de favorecer las aportaciones de la comunidad, me parece sensato mirar a la misma antes. De ahí todas las referencias de mi mensaje anterior.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

• En cuanto tienes un equipo escaso (pongamos un ordenador de colegio, o viejo, o una Raspberry Pi), todas estas herramientas son un dolor.

¿Cuáles son todas estas herramientas? En el toolchain de las FPGAs hay una diferencia sustancial entre la compilación/simulación, la síntesis, el posicionamiento y el rutado. Lo realmente doloroso es el posicionamiento y el rutado. Y se hace muy llevadero si el uso de los recursos lógicos se mantiene en un porcentaje bajo. Después está la síntesis, cuya duración depende principalmente del esfuerzo de optimización. La compilación/simulación es comparativamente despreciable. A modo de referencia, una simulación de cinco minutos de reloj, puede tardar cuarenta en sintetizar y más de una hora en P&R. Y yo no trabajo con diseños especialmente complejos. En proyectos avanzados las dos últimas fases se pueden medir en días.

Lo cual nos lleva a tres puntos:

• Mencionabas webpack. Pues bien, Vivado se ofrece oficialmente como una suite para placement y routing, sólo. En la documentación especifican que el editor, sintetizador y simulador son complementos, y que si quieres algo bueno uses los de terceros. De hecho, durante bastante tiempo Isim era ModelSim/QuestaSim, y en general está pensado para enlazar editores externos.
  
• Nos permite intuir que el P&R no es baladí, y que por mucha basura que pueda tener, esos algoritmos de optimización son pesados de narices. No sólo eso, sino que el editor de posicionamiento permite colocar a mano cada una de las LUT y conexiones de la FPGA. Si a eso le sumamos el particionamiento, los dominios de reloj y la reconfiguración parcial dinámica, empezamos a entender un poco por qué las herramientas muy avanzadas de FPGA/ASIC ocupas gigas. Todo lo anterior, no es hacerlo una vez, sino evaluar la mejor de entre decenas, cientos, miles... de combinaciones posibles.
  
• Por suerte, no tenemos que tratar con nada de eso, ya que yosys lo hace todo :D. Efectivamente, compara Vivado con yosys y échate las manos a la cabeza.
  
• He de decir que algunas de las opciones auxiliares de Vivado son exclusivas e interesantes, como por ejemplo la estimación de consumo de potencia. Algo absolutamente fuera de nuestro contexto, por otra parte.
• El flujo de trabajo/diseño con hardware no es el mismo que con software. Aunque se llame 'hardware libre', Arduino es un proyecto exclusivamente de software. En PC y embebido, pero software todo. La amplísima mayoría de proyectos, especialmente los iniciales, fueron adaptaciones de diseños existentes con PIC, probadísimos y refinadísimos por aficionados durante años. Por ello, hay una lección básica que se ha relajado: en hardware las cosas se queman y se rompen por lo que los diseños tienen que sostenerse sobre papel antes de encender el interruptor. Apliquemos esto al diseño con FPGAs:
• La placa no se programa hasta no tener certeza de que nada va a explotar.
• La certeza de que no va a explotar se tiene comprobando en el PC cada posibilidad previamente.
• Si se cumplen las reglas básicas de diseño síncrono y se utilizan únicamente estructuras con analogía evidente en la síntesis, la simulación 'behavioural' es igual a la post-síntesis y post-P&R. Especialmente con frecuencias de reloj bajas (por debajo de 50MHz).
• Para no aburrirnos esperando tras cada iteración, daremos la simulación 'behavioural' por buena, y utilizaremos los resultados de la misma para verificar que la simulación post-P&R no ha cambiado.
  
• Conclusión 1, aunque en Arduino te puedas saltar el debugger con la Alhambra deberías adorar tu simulador. Por lo que didácticamente Icestudio necesita urgentemente la integración con un simulador. Cuestión sobre la que no he puesto énfasis, porque he visto que ya está en el roadmap.
• Conclusión 2, cuando se cumpla el punto anterior, los estudiantes/usuarios podrán aprender en su casa o donde quieran, sin tener la placa delante. Dejándoles acceso a las placas de forma de forma motivadamente limitada, se puede reforzar la importante diferenciación entre el HDL y su verificación por un lado, y el diseño de circuitos electrónicos por otro. Tal como está evolucionando el mercado, dentro de relativamente pocos años el mercado de IP-cores empezará a comerse al del software embebido. Lo está haciendo ya en muchos ámbitos. Los proyectos físicos son divertidos, pero el diseño para FPGAs se hace sin ver ni tocar un PCB. Ver algún motor moviéndose es el premio por un trabajo bien hecho, pero definitivamente no la plataforma en la que quieres probar un algoritmo chusquero.
• Estas herramientas son un dolor en la RPi de un colegio, ¡y también en un i5 de una universidad! Lo que no puede ser, no puede ser, y además es imposible XD.
• Una 'trampa' habitual es dar a los alumnos un testbench contra el que probar sus diseños. Cuando todas han entregado la tarea, dependiendo del tiempo disponible, se prueba sólo una síntesis previamente hecha por el o la profesora en la placa y el correspondiente montaje. Si hay tiempo, se sintetizan y prueban uno o varios de los diseños. Si todos los diseños pasaron el testbench, y éste estaba bien hecho, todos son funcionalmente equivalentes, por lo que no tiene sentido sintetizar cada uno.
• Esta forma de trabajar tiene una ventaja notable: así funciona el desarrollo profesional. Esto es por influencia directa del software y la integración continua.
• Alternativamente, principalmente por tema de licencias, algunos centros tienen un ordenador/servidor. Los alumnos pueden conectarse, subir el diseño y simularlo ahí. A veces, también sintetizarlo y hacer el P&R para programarlo en su placa. Otras, tienen una o varias FPGAs conectadas al servidor y una webcam, para que se prueben los diseños que hayan pasado el testbench y hayan generado un bitstream correcto. Visité hace no mucho alguna página de una universidad alemana que tenía esto último abierto, pero no he vuelto a encontrarlo:S.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

• Si le añades que en cuanto lo exprimas con diseños gordos el rendimiento va a caer en picado, no lo hacen quizás una de las mejores elecciones para el IDE como tal crezca.
  

Espero que con el ejemplo del PID y la PWM se haya entendido el tamaño al que me refiero.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

¿Estoy diciendo que Icestudio es una mala herramienta? ¡¡¡PARA NADA!!! Es un IDE que creo que tiene un nicho muy claro, que es el de aprendizaje y la iniciación.

De hecho, si estamos aquí es porque es lo más cercano a un IDE libre para HDL.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

Tiene otro punto buenísimo a su favor: si se quiere hacer una versión web, ya tiene prácticamente todo el desarrollo hecho, evitando instalaciones y la pérdida de tiempo que eso conlleva por ejemplo para un taller (que no así en rendimiento).

Aunque todavía sólo soporte microejemplos, creo que en caso de hacer una versión web, es sensato echar un vistazo a los sistemas que he mencionado.

2017-03-02, 8:20, Cristóbal Contreras Rubio:

Resumiendo, creo que en mi modesta opinión icestudio mola 1000, pero no podemos verlo como una herramienta profesional ni creo que sus creadores se lo hayan planteado así.

Siento que se ha malinterpretado el motivo de mis referencias. Todos los proyectos indicados empezaron como experimentos, y la gran mayoría nunca pasaron de ello. La razón principal, a mi juicio, es la bendita ignorancia. Muchos empezaron aislados como proyectos ambiciosos, convencidos de que no había casi nada parecido, inventándolo todo desde cero. Como es un ámbito que tiene su complejidad, llegado un punto la cuesta se inclina demasiado, surgen otras prioridades, se abren a la comunidad tal cual y se abandonan. Al estar tal cual y ser soluciones incompletas, la comunidad las ve y sigue a lo suyo. El hardware libre reinventa la rueda un par de veces al año, al menos.

En este caso, el desarrollador principal ha hecho hincapié desde un inicio en el aprendizaje colectivo. Lo cual me ha invitado a pensar que icestudio mola 1000 y va a molar mucho más porque podremos utilizar su estructura para escalarla a otros contextos. Por ello, mi mensaje anterior se puede plantear alternativamente como: si voy a hacer una pequeña aplicación que convierta Verilog/VHDL a una representación gráfica editable, ¿Por qué debería optar por ice? ¿Qué aporta a la comunidad de las 'herramientas libres para FPGAs' una solución unidireccional? ¿Se planea en algún momento integrar icestudio en la comunidad o se espera que la comunidad se integre en icestudio? ¿Cuáles son las decisiones de diseño que se prevén para facilitarlo?

Espero haber aclarado mi postura, y que las explicaciones auxiliares sobre las herramientas y el flujo de trabajo te hayan resultado interesantes.

Saludos!

[Unai Martinez]

Hola Roy? Pris? Rachel? Rick???

2017-03-02, 13:07, NexusVI:

Lo primero, dar las gracias a Unai por compartir!
He encontrado muchisima informacion en tu correo que me ha resultado super interesante. Gracias!

¡Gracias a vosotros por la recepción! Me alegro de te/os resultara interesante.

2017-03-02, 13:07, NexusVI:

Despues, he hecho una prueba de estress en icestudio muy sencilla que creo puede ser interesante. Basicamente lo que he hecho es meter 1000 puertas AND en un diagrama. No las he conectado por que me he hecho un script super rapido en 5 minutos para generar un fichero .ice con esta informacion y meter cables me complicaba el tema... Os adjunto el fichero por si quereis probar vosotros mismos.
Las pruebas las he hecho en un Windows 7 64bits, el ordenador es un portatil i5 normalito del curro.

Es interesante como prueba de estres, pero es excesivamente sintética, ya que ninguna GUI debería dar más información que la que el usuario es capaz de procesar. En un diseño práctico con 1k puertas:

• Con el zoom suficiente para poder apreciar éstas y sus conexiones, posiblemente no se podrían mostrar todas en pantalla, por lo que el frontend sólo debería procesar la parte visible. En ese caso, habría que estimar el tamaño mínimo en el que se pueden representar los elementos para que sean apreciables en una resolutión habitual-baja. Con ello el número máximo que deje procesar el frontend.
  

• Lo habitual es que 1k puertas estén agrupadas en módulos, por lo que el frontend simplificaría todos aquellos que no estén 'desplegados', además de los que estén fuera de pantalla (desplegados o no).
  

En cualquier caso, las preguntas sobre el rendimiento era una forma retórica de introducir el tema de la optimización y las posibilidades de escalado de la aplicación. En cierta manera los números son irrelevantes mientras el input sea insuficiente para saturar el frontend. En otras palabras: JS es más rápido que tú; no sufrirá hasta que no te sustituya un script. Y en esta línea la pregunta implicita era, y es, si los desarrolladores han pensado en ello, si tienen pensado hacerlo, o si no contemplan que la herramienta llegue nunca a tener problemas de ese tipo.

 
2017-03-02, 13:07, NexusVI:

Sinceramente no creo que haga falta tener tantos elementos jamas dentro de un diagrama, ya que icestudio te permite diseñar modulos independientes y luego añadirlos como bloque (incluso anidados uno dentro de otro!) con lo que no creo que visualmente tengas necesidas de tener de golpe todos los elementos en pantalla...

Coincidiendo en ello, entenderás que mi pregunta va dirigida a una etapa entre el parseo y la visualización. Icestudio te permite diseñar módulos independientes y añadirlos como bloque, lo cual no quiere decir que el usuario vaya a hacerlo. Un ejercicio básico para aprender qué son los 'generate' es por ejemplo, hacer un multiplicador a base de sumadores. Ahí quieres verlo todo. Si es de 4 bits no hay problema. ¿Y si es de 32? Cambiando un sólo parámetro se genera un circuito ocho veces más grande. ¿Cómo gestiona eso icestudio?

De hecho, ahora mismo no se entera, porque no revisa si ha cambiado después de abrirlo. Si lo hiciera, debería considerar ficheros mal formateados. Por ejemplo, 0.3.0-beta3 Win10, si un campo 'x' o 'y' de un bloque existe pero está vacío, no se abre el fichero y no se muestra ningún error. Sin embargo, si ese campo no existe, se considera que es cero, se carga y dibuja en consecuencia, y al guardarlo de nuevo se añade el campo con el valor cero. Lo primero puede ser un bug, y se puede tratar como el segundo caso.

Aunque considerara múltiples posibilidades en que estén mal formateados y los añada, es evidente que actualmente no se intentan recolocar. ¿En qué parte del flujo de ejecución de icestudio entra eso? ¿Está suficientemente aislado y parametrizado como para poder recolocar entradas/salidas/bloques nuevos? Me respondo: no, porque si hay cuatro salidas alineadas en una columna y tratas de meter un quinto bloque en medio, no aparta el resto. Por lo que no existe, o no se ejecuta, una función que analice un esquema concreto y coloque los elementos.

Sirva el párrafo anterior para entender que puedo hacer en uno o dos ratos un script, que se pueda añadir como bloque, y que genere un multiplicador basado en full-adders de un solo bit. Parametrizado, lo cual quiere decir que se pueda elegir el tamaño de palabra de cualquiera de las dos entradas y de la salida. Me refiero a un script que 'dibuje' la estructura en Icestudio, no a un solo bloque con código en Verilog. La clave está en que tendría que calcular la posición de cada bloque a mano. No es que no quiera hacerlo, es que algo no cuadra en el flujo de procesado si estoy obligado a ello. Icestudio es un IDE gráfico, debería hacerlo él.

Si voy a usar una librería externa como graphviz OGDF o mxgraph, me gustaría discutir la idoneidad de usar una u otra, y su posible integración. O asumir que deberá mantenerse como una aplicación paralela. O saber que antes o después algo así se añadirá. Además:

• Consciente de que Icestudio tiene limitaciones justificadas por su nicho, en caso de integración, me gustaría valorar cómo hacerlo más o menos independiente de la aplicación. De ahí mi mención en el primer mensaje sobre el hecho de que la 'representación de referencia' del diseño no sea un único fichero.
• Para usar cualquiera de las librerías anteriores, es necesario reinterpretar el formato ice para pasar sólo la información gráfica con la sintaxis esperada. Por lo tanto, ésta podría omitirse de ice, y usar un fichero solidario que la contenga.

Teniendo en cuenta lo anterior, sigamos estos pasos:

• Al formato ice le quitamos la información gráfica (que incluye las conexiones). Las conexiones se guardan en un fichero al que llamaremos netlist. Las propiedades graficas (anchura y altura, color, bordes, etc.) en otro al que llamamos CSS.
  
• En el ice nos quedan el código y las 'board rules' Por lo tanto, el siguiente paso evidente es guardar el código en un fichero (que podemos llamar Verilog) y las board rules en otro (que llamaremos User Constraints File o UCF).
• Cogemos los cuatro ficheros, los metemos en un tar (o mejor, comprimimos con zlib) y lo renombramos a ice (como hacen odt y docx, entre otros).

¡Voilà! Para el usuario sigue siendo el fichero del proyecto, pero está todo ordenado y permite diferenciar qué se modifica en cada etapa. Además, hemos escogido los nombres con la suficiente habilidad para percatarnos de que estamos utilizando una rueda de madera, y en cuanto le hagamos un par de agujeros se parecerá mucho a las que usan radios. Y ¡qué cantidad de radios y cubiertas diferentes hay en la red!

Evidentemente lo anterior es mucho más sencillo de decir que de implementar. Por lo que repito que mi intención no es que esté hecho ni mañana ni en dos años. Sin embargo, puesto que icestudio necesariamente hace un desglose similar del ice, me pregunto cuáles son las preguntas que les han surgido a los desarrolladores al hacer este ejercicio de abstracción. Hacer lo anterior requeriría de entrada, cuatro parses (que pueden reuitilizarse parcialmente, ya que icestudio tiene generadores). ¿Qué más?

Saludos!

[Unai Martinez]

Para ilustrar de forma práctica lo que estoy planteando, he cogido el ejemplo 'complex' de la documentación (http://icestudio.readthedocs.io/en/latest/source/project.html?highlight=complex#complex) y lo he dividido y adaptado ligeramente. He mantenido todo en JSON para que la modificación de la estructura sea más evidente. Salvo error mío al copiar y pegar, la propuesta en https://github.com/1138-4EB/icestudio/blob/master/tar.md tiene exactamente la misma información que el ejemplo.

Hay cinco tipos de fichero/estructura: project, block, view, code y ucf. Todos ellos tienen un campo 'version' que hace referencia a la version de icestudio para la que están pensados. Y también un campo 'type' que indica el tipo que son. Además:

• project
• main: id del package que hace de top entity/module
• board: tarjeta en la que se quiere implementar el diseño
• block
• id: único global (si se implementan librerías, único en la librería)
• ref: puede ser 'package', libreria.identificador o #identificador.
• data: depende de ref.
• #identificador: es una copia exacta de un bloque ya definido. data no tiene contenido.
• Cualquiera de los otros incluyen:
• version: version del package
• description:
• author:
• devices: dispositivos, no placas con los que es compatible
• Además, si es package:
• name: nombre del package
• blocks: listado de identificadores de bloques
• wires: listado de parejas del tipo ["bloquedesalida.puerto","bloquedellegada.puerto"]
• dependencies: listado de identificadores únicos o librerías (no #)
• Si es libreria.identificador: el contenido depende del tipo de bloque, como en la implementación actual de icestudio.
• view
• id: identificador del bloque al que corresponde
• Si el bloque es un package, incluye tambien:
• wires: grosor de cada uno de los cables
• vertices: una estructura por cada cable que tenga algún punto adicional, indicando el número de cable y un listado de puntos por los que debe pasar.
• image
• state
• Si el bloque no es un package, incluye:
• position
• size
• code: módulos escritos en verilog directamente
• ucf
• id: identificador del bloque al que corresponde
• boards: tarjetas para las que esta pensado
• pins: listado de pines con el formato ["iddelbloque","puerto(bit)",nombre,valor]
  

Ventajas que le veo a esta estructura:

- Todas las partes de un proyecto pueden estar en uno o en tantos ficheros como se quiera. Excepto los de tipo 'code', el resto son todo estructuras JSON debidamente identificadas para que puedan juntarse en una sola lista.
    - Por lo tanto, se pueden procesar en paralelo e ir añadiendo el contenido a variables temporales que finalmente se unan en una sola.
- Sólo con los fichero block, se puede generar una netlist, ignorando view, code y ucf. Se puede pasar esa netlist a una librería para obtener posicionamientos para los nodos.
    - Opcionalmente, se puede consultar parte de la información en view para conocer el tamaño de los nodos.
    - Se pueden expandir los packages recursivamente y en paralelo.
- En general, se reduce la profundidad de las estructuras, y en particular se comprimen las listas en los niveles más profundos. El resultado final es una longitud de fichero similar.
    - En el ejemplo enlazado, las instancias de packages son redundantes. Las he puesto a modo ilustrativo.
- Los diseños lógicos están asociados a los recuros de un dispositivo o familia de dispositivos, no a una tarjeta. El fichero UCF es lo último que se añade al diseño, ya que sólo es relevante para implementación.
    - La conversión del UCF en JSON a un UCF "real" es directa.
- Para utilizar directamente verilog sólo hay que parsear los puertos de los ficheros .v y se obtiene un bloque tipo basic.code. Mientras no se modifiquen los puertos, al resto de la aplicación le da igual qué se haga dentro.
- La visualización (grosor de cables, tamaño de cajas, imágenes, etc.) está completamente desligada del resto de información, lo que facilita el desarrollo de vistas diferentes, incluso a nivel de bloque.
    - Si se opta por CSS, no es necesario incluir el tipo 'view', ya que se puede asociar la extensión.
    - No lo he añadido, pero creo que sería interesante poder posicionar los puertos libremente en cualquiera de los lados de una caja.
- Desde una entidad superior, se pueden intercambiar los bloques libreria.identificador por los de tipo package semidirectamente: los package no tienen un listado explícito de puertos, pero tienen un listado de bloques y otro de cables, por lo que se puede deducir cuáles están sin conectar.
    - La utilidad principal es sustituir un basic.code, que es verilog directamente, por un package que incluya una representación gráfica. Puede ser útil especialmente al empezar el paso del diseño exclusivamente visual a escribir verilog, ya que permite tener dos bloques en paralelo y comparar el comportamiento.
- Quien quiera colabora sólo en alguna de las áreas, tiene una referencia clara sobre qué tiene que mirar.
   
Posibles desventajas:

- ¿Cuánto depende icestudio de la estructura del fichero ice? Un cambio como el propuesto, ¿requiere rehacerlo 'desde cero'? ¿O es suficientemente modular como para meter una interfaz donde antes había un estructura?

[Jesús Arroyo]

Hola Unai,

Te respondo brevemente a algunas cuestiones que planteas:

• Actualmente el formato ice es el único que maneja Icestudio. El motivo de su existencia es principalmente la simplicidad. Aunque se podrían añadir nuevos formatos más complejos, como el que planteas, (https://github.com/FPGAwars/icestudio/blob/develop/app/scripts/services/project.js), el enfoque que quiero darle al desarrollo a partir de ahora es que sea todavía más modular, es decir, desarrollar módulos o funciones independientes que realicen funciones concretas y en un futuro integrarlo todo en un mismo IDE. Por ejemplo, en el formato que planteas se podría implementar ya un "compilador" o "traductor" a Verilog y PCF para integrarlo con Icestorm, o por ejemplo un generador de dot para visualizarlo con graphviz, etc (Os recomendaría probar con JavaScript, o C/C++). Este formato tiene conceptos interesantes, un comentario que haría es que en JSON generalmente se suelen utilizar objetos en vez de listas u objetos con "." por varios motivos, uno de ellos es la claridad y simplicidad en la descripción e implementación, por ejemplo queda más claro acceder al elemento "size.width" que al elemento "size[0]".
• ¿Qué aporta? Icestudio es una herramienta experimental y aporta por lo tanto resultados de experimentos. Concretamente hemos visto que permite que la gente que está empezando pierda el miedo al hardware y sea capaz de crear electrónica digital real de forma intuitiva. Los perfiles de usuarios son muy variados, pero todos son capaces de realizar diseños y entenderlos, por lo tanto el enfoque del IDE gráfico es muy positivo. También permite crear bloques todo lo complejos que quieras (puedes incluir ficheros .v completos) por lo que resulta sencillo encapsular funcionalidad como el bloque ServoBit, Click, etc.También ha resultado muy útil para presentar todo el stack de herramientas de FPGAs libres, por ejemplo con charlas, ya que se ve más claramente el potencial que simplemente ejecutando comandos de consola, pero el que sabe más entiende que puede acceder a cualquier herramienta del stack. Conclusión, estamos viendo cómo un modesto proyecto ha conseguido unificar y motivar a usuarios, educadores, etc en el desarrollo de diseños digitales libres, pero como siempre digo, aún queda mucho por hacer :)
• ¿Integración con la comunidad? Icestudio ha nacido en la comunidad libre, y de hecho no sería lo que es ahora sin muchas aportaciones y contribuciones, tanto de ideas y conceptos como código, incluso traducciones de la propia comunidad. ¿Decisiones de diseño? como comento, quiero que la nueva funcionalidad se realice de forma modular, es decir, animar a la gente a que proponga e implemente y experimente con cuestiones concretas que posteriormente podrán ser maduradas e integradas y por lo tanto que se tomen decisiones de forma descentralizada.
• ¿Simulación? es importante pero, en mi opinión, hay que replantear la interfaz y experimentar formas gráficas más intuitivas que posteriormente generen testbenches compatibles con Icestorm. Hay que reinventar el enfoque, pero el concepto sería el mismo: un editor gráfico que genere ficheros *_tb.v.

Siento no explarme más pero el tiempo apremia.

Un saludo.

[Unai Martinez]

Hola Jesús:

2017-03-03, 9:31, Jesús Arroyo:

• Actualmente el formato ice es el único que maneja Icestudio. El motivo de su existencia es principalmente la simplicidad. Aunque se podrían añadir nuevos formatos más complejos, como el que planteas, (https://github.com/FPGAwars/icestudio/blob/develop/app/scripts/services/project.js), el enfoque que quiero darle al desarrollo a partir de ahora es que sea todavía más modular, es decir, desarrollar módulos o funciones independientes que realicen funciones concretas y en un futuro integrarlo todo en un mismo IDE.

• El uso de 'aunque' y el condicional dan a entender una dicotomía entre el uso de otros formatos y hacer el desarrollo más modular. Desde mi punto de vista son tareas complementarias. ¿Qué es necesario para pasar a 'se pueden añadir'?
• Haces referencia al boceto de formato que puse como ejemplo en mi mensaje anterior utilizando el término 'complejo'. ¿Podrías elaborar esta valoración?
• He metido todas las partes en un sólo JSON y me sale un fichero de 413 líneas que ocupa 12.288 bytes. En comparación el ICE actual tiene 566 líneas y 20.480 bytes. Eso supone un ahorro del 30% en número de líneas y del 40% en el tamaño del archivo.
• Personalmente me resulta más human-friendly tener las estructuras separadas por funcionalidad, en lugar de todas mezcladas (aunque sólo sea por ahorrar scroll).
• Cualquier módulo que no requiera toda la información, tiene que cargar menos información en memoria y tiene que perder menos tiempo recorriendo el árbol para buscar lo que le interesa. Por lo que es menos compleja para estas tareas.
  

2017-03-03, 9:31, Jesús Arroyo:

• Por ejemplo, en el formato que planteas se podría implementar ya un "compilador" o "traductor" a Verilog y PCF para integrarlo con Icestorm

 De hecho, por eso he escogido ese boceto. Pero la pregunta es ¿qué hay que hacer para que icestudio lo use?
 

2017-03-03, 9:31, Jesús Arroyo:

• o por ejemplo un generador de dot para visualizarlo con graphviz, etc (Os recomendaría probar con JavaScript, o C/C++). Este formato tiene conceptos interesantes,

Te recomiendo encarecidamente que eches un vistazo a las 3-4 primeras páginas de este documento: https://cs.brown.edu/~rt/gdhandbook/chapters/ogdf.pdf , que está portado a Javascript: https://github.com/Saheb/GSoC-2013

2017-03-03, 9:31, Jesús Arroyo:

• un comentario que haría es que en JSON generalmente se suelen utilizar objetos en vez de listas u objetos con "." por varios motivos, uno de ellos es la claridad y simplicidad en la descripción e implementación, por ejemplo queda más claro acceder al elemento "size.width" que al elemento "size[0]".

Lo sé, y es uno de los malos vicios. No quiero decir que no se deban usar estructuras con objetos nombrados, pero evitar por completo cualquier lista es una fuente de ineficiencia (ver comparación de tamaño anterior). Por ejemplo,

• Para un listado de puntos en ejes cartesianos, añadir 'x', 'y' y/o 'z' es duplicar o triplicar el espacio requerido (y tiempo de parseo/acceso). Las dimensiones, idem.
  
• En los puertos el nombre es un string y el rango es un rango, por lo que se puede identificar inequívocamente cuál de los se quiere, aunque no se dieran ordenados en la lista.
• Dependiendo de la implementación, una lectura secuencial de los elementos de una lista es una lectura secuencial en memoria, lo que provecha la localidad de los datos. Utilizando hash maps (parejas llave-valor) normalmente perdemos la referencia, ya que se dispersan.
• Hay datos que se pueden calcular en tiempo de lectura, si es útil tenerlos precomputados, pero no tiene sentido guardarlos en el fichero. Por ejemplo, la longitud de los puertos, si ya existe el campo range.
• Podrás apreciar que las listas sólo están en los níveles más profundos del árbol, o cuando efectivamente la posición de los elementos es irrelevante.

2017-03-03, 9:31, Jesús Arroyo:

• ¿Qué aporta? Icestudio es una herramienta experimental y aporta por lo tanto resultados de experimentos. Concretamente hemos visto que permite que la gente que está empezando pierda el miedo al hardware y sea capaz de crear electrónica digital real de forma intuitiva. Los perfiles de usuarios son muy variados, pero todos son capaces de realizar diseños y entenderlos, por lo tanto el enfoque del IDE gráfico es muy positivo.

No quiero que se desprenda la más mínima acritud, pero todo eso es conocido desde los ochenta. Más allá, no soy un sujeto al que debas 'vender' el proyecto. Quiero conocer la aplicación. Cuando hablo de aportes a la comunidad, me refiero a soluciones técnicas concretas y diferentes para los problemas que ya son conocidos. Naturalmente, que sean mejores en algún aspecto concreto. O bien, algún problema que no esté debidamente identificado y que hayas aislado. Por ejemplo, los cambios dinámicos en los ficheros que mencionaba en la respuesta a NexusVI.

 
2017-03-03, 9:31, Jesús Arroyo:

• También permite crear bloques todo lo complejos que quieras (puedes incluir ficheros .v completos) por lo que resulta sencillo encapsular funcionalidad como el bloque ServoBit, Click, etc.

Lo he visto en algún ejemplo. No obstante, es una 'trampa' porque, a diferencia de Arduino, no permite utilizar partes del verilog. Me refiero a que para un usuario el módulo es una verdadera caja negra, y depende de los parámetros que le haya facilitado el diseñador del mismo. ¿Me equivoco?

Lo anterior no sería una limitación si icestudio dispusiera de un input mediante scripting para describir estructuras regulares. En VHDL están los generate. En Verilog no conozco el término, pero seguro que lo hay. Repito, que lo mismo me da cualquiera de las tres opciones. Por tus intervenciones asumo que VHDL no es una opción, ni siquiera en estilo puramente estructural. Entre interpretar Verilog para extraer la jerarquía interna de bloques o inventarte tú una sintaxis/API para generar ICE sin escribir en JSON, ¿qué opción vas a coger?

 
2017-03-03, 9:31, Jesús Arroyo:

• También ha resultado muy útil para presentar todo el stack de herramientas de FPGAs libres, por ejemplo con charlas, ya que se ve más claramente el potencial que simplemente ejecutando comandos de consola, pero el que sabe más entiende que puede acceder a cualquier herramienta del stack.

Aun sin haberlo visto, estoy de acuerdo. No obstante, por favor, 'stack de herramientas libres para FPGAs'. Un gatito muere en las dependencias de Lattice cada vez que se utiliza 'FPGA libre'.

2017-03-03, 9:31, Jesús Arroyo:

• Conclusión, estamos viendo cómo un modesto proyecto ha conseguido unificar y motivar a usuarios, educadores, etc en el desarrollo de diseños digitales libres, pero como siempre digo, aún queda mucho por hacer :)

¡Y en esas estamos!

2017-03-03, 9:31, Jesús Arroyo:

• ¿Integración con la comunidad? Icestudio ha nacido en la comunidad libre, y de hecho no sería lo que es ahora sin muchas aportaciones y contribuciones, tanto de ideas y conceptos como código, incluso traducciones de la propia comunidad.

A eso justamente me refería al diferenciar 'que la comunidad se integre en icestudio' de 'que icestudio se integre en la comunidad'. Tal como lo veo, y tus intervenciones anteriores no me sirven para enfocarlo de otra manera, es un proyecto tuyo al 99% (literalmente), por lo haces lo que te apetece. Lo cual incluye que la documentación necesaria para poder hacer aportaciones estructurales es prácticamente inexistente. Está muy bien que la comunidad traduzca la aplicación a aquellos idiomas que desconoces, añada recursos a las librerías y aporte ideas que gestiones a tu libre parecer.

Pero ninguno de esos aspectos sirve para que icestudio haga más o menos de lo que hace. Sobre todo, impide que el core avance más rápido de lo que tú sólo eres capaz de gestionar. Es una estructura jerárquica con un sólo lider. Muchos proyectos de software libre funcionan así, y no lo desprecio. Pero choca un poco con el aprendizaje colectivo que reclama el primer mensaje de este hilo. Por ello, ¿tienes intención de democratizar la estructura de colaboración o seguirá así hasta nueva orden? A mí me vale con saber que el aprendizaje se circunscribe al debate en los foros, mas quisiera confirmarlo.

2017-03-03, 9:31, Jesús Arroyo:

• ¿Decisiones de diseño? como comento, quiero que la nueva funcionalidad se realice de forma modular, es decir, animar a la gente a que proponga e implemente y experimente con cuestiones concretas que posteriormente podrán ser maduradas e integradas y por lo tanto que se tomen decisiones de forma descentralizada.

Llevo varios mensajes intentándolo... muy especialmente en los dos últimos con propuestas y preguntas muy concretas. Agradecería un mínimo de concreción en las respuestas. Si esa concreción es que no vas a poder responder debidamente hasta el mes que viene, me vale. Pero tengo la sensación de que estás saltando justamente los detalles técnicos que son de interés.

2017-03-03, 9:31, Jesús Arroyo:

• ¿Simulación? es importante pero, en mi opinión, hay que replantear la interfaz y experimentar formas gráficas más intuitivas que posteriormente generen testbenches compatibles con Icestorm. Hay que reinventar el enfoque, pero el concepto sería el mismo: un editor gráfico que genere ficheros *_tb.v.

No entiendo este párrafo. Un testbench no es más que un módulo (normalmente sin puertos de entrada/salida) que tiene otro módulo instanciado dentro. ¿Por qué es necesario replantear la interfaz y experimentar formas gráficas más intuitivas? ¿Te refieres a escribir un testbench como una serie de entradas o patrones predefinidos leídos desde un fichero?

Yo iba a algo mucho más simple, como generar el mismo verilog que ya creas para síntesis, simularlo para generar un VCD, FST o el formato que sea, y cambiar la sintaxis para mostrarlo en WaveDrom (que es Javascript). Al nivel experimental que estamos tratando, no creo que te lleve más de un par de horas. WaveDrom tienen bastantes pegas sintácticas, pero es lo más fácil para empotrar el resultado y que sea 'editable'.

Un saludo

[Jesús Arroyo]

Hola,

Todas las contribuciones de código son bienvenidas, ya sea directamente a Icestudio o indirectamente en proyectos independientes, como por ejemplo lo que está haciendo NexusVI con la parte de interfaz. Todo aquello que sea desarrollado y aporte un valor tiene el potencial de ser incluido en Icestudio e incluso en otras aplicaciones.

Con respecto al formato de descripción de hardware, está todo por experimentar. Quizá el nuevo Icestudio soporte Migen, MyHDL (Python). Esto dependerá de las contribuciones y experimentos de la comunidad.

Finalmente, con respecto a la simulación, actualmente Icestudio tiene la capacidad de exportar un testbench a partir del diseño, aunque la inicialización se tiene que hacer a mano en el mismo verilog. Para futuras versiones quiero explorar formas de descripción gráfica de la simulación (en vez de que el usuario tenga que escribir código, ya sea HDL o WaveDrom).

Un saludo.



Te contesto brevemente.

[Andrés Prieto-Moreno]

La leche ;-) , que mal me siento (es broma).

Al leer esto me doy cuenta que por mas que uno quiera no puede abarcar todo... creo que de todos los terminos que mencionas solo conozco uno o dos !!!!

El IceStudio como esta ahora me parece magico... tal vez por mi propia ignorancia . Seguro que el siguiente sera mucho mejor, y si no es asi que nos quiten lo bailao ;-)

En algun momento intentare hacer una contribucion a este proyecto, por lo pronto he sido capaz de clonarlo .

Gracias

[Jesús Arroyo]

Jaja sí, pestañeas y te quedas obsoleto :), pero eso es lo bueno que quede mucho por aprender y por hacer.

Como siempre digo, cualquier contribución será bienvenida. Aprovecho además para agradecerte todo tu apoyo al proyecto!

Un saludo y gracias!