[Roberto A. Dhios]

Excelente proyecto de una FPGA totalmente GPL incluso la síntesis.

https://github.com/FPGAwars/icezum/wiki

Podríamos replicarla acá, que opinan???

---

Roberto A. Dhios
email. rad...@gmail.com
msg.   gtalk,skype: radhios

in.    ar.linkedin.com/in/radhios

linux. https://www.linuxcounter.net/cert/374352.png

[martin ribelotta]

El 31 de agosto de 2016, 15:33, Roberto A. Dhios <rad...@gmail.com> escribió:

Excelente proyecto de una FPGA totalmente GPL incluso la síntesis.

https://github.com/FPGAwars/icezum/wiki

Podríamos replicarla acá, que opinan???

Si te interesa el asunto:

https://github.com/martinribelotta/poncho_fpga

Podríamos ir viendo de definir un poco mejor esto.

Algunas cosas que pienso después de un tiempo de haber hecho esto:

- Para que la SDRAM? No vamos a poder sintetizar nada que la aproveche o si lo hace, va a ser de lo mas doloroso usarla

- Porque LQFP? En el pais hay capacidad de soldar BGA y otras cosas peores (ufBGA, WLCSP) Porque no irnos a lago con mas pines

- ¿Porque poncho? ¿Porque no un dip40 o algo así?

- Si replicamos lo ya hecho, al menos que aporte algo nuevo no?

---

Roberto A. Dhios
email. rad...@gmail.com
msg.   gtalk,skype: radhios

in.    ar.linkedin.com/in/radhios

linux. https://www.linuxcounter.net/cert/374352.png

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Roberto A. Dhios]

Hola,

Esta bueno el proyecto. No se si lo haría poncho? Estoy de acuerdo con el tema de la ram, también con que tenga mas pines. Lo que me gusto de la icezum es el ftdi incluido para programarla y que tenga algunos leds y pulsadores para las primeras pruebas.

Saludos

---

Roberto A. Dhios
email. rad...@gmail.com
msg.   gtalk,skype: radhios

in.    ar.linkedin.com/in/radhios

linux. https://www.linuxcounter.net/cert/374352.png

[martin ribelotta]

El 31 de agosto de 2016, 16:20, Roberto A. Dhios <rad...@gmail.com> escribió:

Hola,

Esta bueno el proyecto. No se si lo haría poncho? Estoy de acuerdo con el tema de la ram, también con que tenga mas pines. Lo que me gusto de la icezum es el ftdi incluido para programarla y que tenga algunos leds y pulsadores para las primeras pruebas.

El FTDI es lo que NO me gusto para nada.

En el proyecto CIAA (y en otros que me a tocado pasar) los chips FTDI pueden parecer la mejor idea del mundo, pero como JTAG son un desastre en windows, en especial con openocd y otros de ese estilo.

Mejor un micro simple como un LPC11U35 o un stm32F042 que se puedan programar por usb (tienen bootloader usb en ROM) y se les baja un firmware que programe la flash SPI y/o haga la comunicación serie al FPGA (o cualquier interfaz que se nos ocurra)

Leds y pulsadores pueden estar buenos para las primeras pruebas pero luego se vuelven una molestia que ocupa pines nada mas. Si no se les da algun uso interno a la placa (dos leds como mucho, uno o dos pulsaodres como mucho) siempre terminan consumiendo recursos para cualquier proyecto serio. De hecho, plataformas como arduino /guacala) tienen un solo led como mucho.

[Fernando Lichtschein]

Martín,

¿guacala es un proyecto o un epíteto que agregaste por que dijiste la mala palabra "Arduino"?

Estoy de acuerdo con lo de la cantidad de LEDs/Botones.

Saludos,

Fernando

[martin ribelotta]

El 31 de agosto de 2016, 16:39, Fernando Lichtschein <flicht...@gmail.com> escribió:

Martín,

¿guacala es un proyecto o un epíteto que agregaste por que dijiste la mala palabra "Arduino"?

Es un error de typo, en realidad queria decir

...como arduino (guacala)...

Lamentablemente, arduino se ha hecho carne en todos lados y tiene demasiados defectos para enumerarlos todos aca.

En especial, que evoluciona a paso glaciar (todavía seguimos con el arduino uno en dip????)

Ya ni hablemos de la pobre adopción de micros de 32 bits.

[Fernando Lichtschein]

Ok, o sea que interpreté bien.

Al Arduino le debemos algunas cosas buenas, por ejemplo que haya muchos chirimbolitos que si no fuera por el Arduino acá no se conseguirían.

El modelo de uso no es malo para principiantes, aunque sabemos que cuando se aprieta el acelerador se queda en la largada.

El ecosistema es muy bueno, hay de todo y creo que es un modelo a copiar, sobre todo lo "plug and play".

No entiendo quién fue el nabo que puso ese gap ridículo en el medio de una de las tiras de pines, no te deja usar placas de prototipo perforadas.

Y lo último puede ser tanto un bendición como una maldición: cuando le comentás a un lego (como en "Falto de instrucción, ciencia o conocimientos", no un ladrillito) que estás trabajando con la CIAA o algún sistema embebido, el 90% de la población te va a decir "Ah, un Arduino". Grrrrrr

[martin ribelotta]

El 31 de agosto de 2016, 16:50, Fernando Lichtschein <flicht...@gmail.com> escribió:

Ok, o sea que interpreté bien.

Al Arduino le debemos algunas cosas buenas, por ejemplo que haya muchos chirimbolitos que si no fuera por el Arduino acá no se conseguirían.

Eso se lo devemos a varias cosas en el país pero bueno, arduino ha permitido que esas varias cosas se sorteen  (de alguna manera)

Yo lo que rescato del proyecto arduino es las herramientas open source, y que Adafruit hizo shields de todo lo habido y por haber.

Eso ultimo, es realmente la fortaleza de arduino.

 

El modelo de uso no es malo para principiantes, aunque sabemos que cuando se aprieta el acelerador se queda en la largada.

Ahí esta el problema, apenas empezamos a hacer algo mas avanzado del hola mundo terminamos en un enredo horripilante.

Mi experiencia de dar clases con arduino es de preguntas como estas:

- "Yo lei por ahí que los programas en C usan main, donde tengo main aca?"

- "Porque no puedo usar printf?"

- "Donde esta el compilador de esto?" (previamente habiamos tenido una charla de como se compilaba el codigo C/C++ a maquina y les mostre el proceso en linux)

- "Como le agrego opciones al compilador? Quiero usar C++11" (previamente les mostre las cosas nuevas que tenia C++11(

Y así un buen rato. Estos no eran pibes universitarios ni de posgrado, sino chicos de escuela secundaria tecnica que recien habian empesado a programar y las diferencias entre el entorno de Arduino y la PC les confundia bastante.

El ecosistema es muy bueno, hay de todo y creo que es un modelo a copiar, sobre todo lo "plug and play".

No entiendo quién fue el nabo que puso ese gap ridículo en el medio de una de las tiras de pines, no te deja usar placas de prototipo perforadas.

La explicación que dan de eso (tal vez ya la haz escuchado por ahí) es que así el mono capuchino que esta insertando cosas al tun tun no puede enchufarlo al revez... o_O

 

Y lo último puede ser tanto un bendición como una maldición: cuando le comentás a un lego (como en "Falto de instrucción, ciencia o conocimientos", no un ladrillito) que estás trabajando con la CIAA o algún sistema embebido, el 90% de la población te va a decir "Ah, un Arduino". Grrrrrr

Eso es enteramente marketing ;-)

[Guillermo Enrique VIDES]

otra alternativa un poco mas potente pero sin el ecosistema arduino

https://olimex.wordpress.com/2016/08/29/ice40hx8k-evb-oshw-prototypes-are-ready-to-test/

---

From: martinr...@gmail.com
Date: Wed, 31 Aug 2016 17:03:25 -0300
Subject: Re: [embeb32]
To: embeb...@googlegroups.com

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Carlos Pantelides]

Hola, ya que ha aparecido este tema de fpga en ciaa aviso que en las listas de firmware y hardware ha habido conversación[1] reciente e invito a quienes estén con deseos de aportar concretamente a considerar sumarse al proyecto. Por ahora sólo se hemos manifestado Martín y yo.

- ¿Porque poncho? ¿Porque no un dip40 o algo así?

Desde afuera, pues yo sólo tengo el deseo, un [2] y la posibilidad logística de participar recién en algunos meses, la propuesta de poncho es para relacionarlo educativamente con la edu-ciaa, como una paso intermedio a [3] y sin duda no responde a un uso industrial.


[1] https://groups.google.com/forum/?hl=en#!topic/ciaa-firmware/tzVEOcL-9WU
[2] http://www.latticesemi.com/icestick
[3] http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu_ciaa_xilinx

Saludos

[Fernando Lichtschein]

¿Se puede votar?

Me sumo a la opinión de Carlos Pantelides sobre la ventaja del poncho de relacionarlo educativamente con el ecosistema CIAA (ahí metí un término que garpa), además está la posibilidad de que aumente las prestaciones de la EDU-CIAA y es una forma de acceder a las nuevas funcionalidades. Por ejemplo, un analizador lógico donde la parte de disparo y captura se haga en la FPGA y el control y análisis lo hagan las CPUs de la EDU-CIAA.

Saludos.

[Carlos Pantelides]

pueden votar los que vayan a hacer algo, jeje

On Friday, September 9, 2016 at 3:51:17 PM UTC-3, Fernando Lichtschein wrote:

¿Se puede votar?

Me sumo a la opinión de Carlos Pantelides sobre la ventaja del poncho de relacionarlo educativamente con el ecosistema CIAA (ahí metí un término que garpa), además está la posibilidad de que aumente las prestaciones de la EDU-CIAA y es una forma de acceder a las nuevas funcionalidades. Por ejemplo, un analizador lógico donde la parte de disparo y captura se haga en la FPGA y el control y análisis lo hagan las CPUs de la EDU-CIAA.

Saludos.

El 9 de septiembre de 2016, 15:26, 'Carlos Pantelides' via Embebidos32 <embeb...@googlegroups.com> escribió:

Hola, ya que ha aparecido este tema de fpga en ciaa aviso que en las listas de firmware y hardware ha habido conversación[1] reciente e invito a quienes estén con deseos de aportar concretamente a considerar sumarse al proyecto. Por ahora sólo se hemos manifestado Martín y yo.


- ¿Porque poncho? ¿Porque no un dip40 o algo así?

Desde afuera, pues yo sólo tengo el deseo, un [2] y la posibilidad logística de participar recién en algunos meses, la propuesta de poncho es para relacionarlo educativamente con la edu-ciaa, como una paso intermedio a [3] y sin duda no responde a un uso industrial.


[1] https://groups.google.com/forum/?hl=en#!topic/ciaa-firmware/tzVEOcL-9WU
[2] http://www.latticesemi.com/icestick
[3] http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=desarrollo:edu-ciaa:edu_ciaa_xilinx

Saludos

On Wednesday, August 31, 2016 at 6:44:43 PM UTC-3, Guillermo Vides wrote:

otra alternativa un poco mas potente pero sin el ecosistema arduino

https://olimex.wordpress.com/2016/08/29/ice40hx8k-evb-oshw-prototypes-are-ready-to-test/

---

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Fernando Lichtschein]

Yo puedo opinar.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[martin ribelotta]

El 9 de septiembre de 2016, 15:50, Fernando Lichtschein <flicht...@gmail.com> escribió:

¿Se puede votar?

Me sumo a la opinión de Carlos Pantelides sobre la ventaja del poncho de relacionarlo educativamente con el ecosistema CIAA (ahí metí un término que garpa), además está la posibilidad de que aumente las prestaciones de la EDU-CIAA y es una forma de acceder a las nuevas funcionalidades. Por ejemplo, un analizador lógico donde la parte de disparo y captura se haga en la FPGA y el control y análisis lo hagan las CPUs de la EDU-CIAA.

Entonces van otras preguntas:

- Interfaz a la CIAA? SPI/I2C/Serial son las que van, pero también podrían ser paralelo aunque tenemos muchos menos pines ahí (compensado con el hecho de que se ganan pines con el FPGA)

- Memoria externa al FPGA? Requiere bastantes pines, pero por ejemplo, en un generador de vídeo estaría bueno tener mucha memoria de trabajo (16M o mas) Lo mismo va para un analizador lógico o un osciloscopio con ADC de alta velocidad.

- Conectores hacia afuera? Otro formato EDU-CIAA? En lo personal, yo lo giraría 90 grados, pero no se si es buena idea.

- Mas cosas? Esto obviamente encarecería la placa pero por ahi alguien quiere ADC/DAC, mas GPIOs, etc, etc.

- Posibilidad de funcionar stand-alone. Se programaría desde la CIAA, pero se podría usar sola.

Por obvias razones, descartamos las iCE40 (soportadas por iCEStorm) NO-LQFP (muy interesantes para hacer cosas tipo miniatura pero no aplica acá). Entonces, las que quedan son las siguientes:

http://www.digikey.com/product-search/en/integrated-circuits-ics/embedded-fpgas-field-programmable-gate-array/2556262?k=&pkeyword=&FV=ffec0437%2Cffec1788%2Cfffc00dc%2Cfff40027%2Cfff80166%2C400457%2C4004c7&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=25

Yo iria por la pieza mas grande (HX4K) en LQFP144 porque permite mayor cantidad de conexiones y tiene una cantidad decente de compuertas (bueno, su equivalente jejeje) En digikey, esta a 7 USD la pieza.

PD: Cualquiera que este interesado puede opinar ;-) independientemente de si colabora o no, ya que al final son los futuros usuarios.

[martin ribelotta]

Ok, vamos a ponerle un poco de Hype [0] a esto porque se esta muriendo:

https://github.com/martinribelotta/poncho_fpga/tree/vq144

[0] Hype: http://www.urbandictionary.com/define.php?term=hype

[Andres Cassagnes]

Buenas. No suelo participar activamente pero sigo los temas relacionados a la CIAA de cerca esperando siempre el momento para meterme más de lleno, casi como estar agazapado entre la maleza esperando el momento. Ese momento que espero depende más de mi que del proyecto ya que el quilombo de tiempos es mío.

Este tema en particular me interesó mucho ya que tengo pensado a futuro trabajar con FPGAs (en realidad, actualmente mi proyecto de tesis de grado las toca de cerca, pero pretendo hacerlo más de lleno y a nivel más profesional) y tener una plataforma dentro del proyecto CIAA me resultaría útil e interesante por igual. Por lo que además de verter mi opinión me gustaría sumarme al proyecto en esta rama y eventualmente en la ligada al desarrollo de la EDU-CIAA-Xilinx.

Yendo al tema en cuestión.

Me parece de gran utilidad tener un poncho FPGA que se conecte directamente a la EDU-CIAA pensado en principio como un "accesorio" para esta, en términos de ampliar sus capacidades y trabajar en conjunto, pero que tenga también la posibilidad de funcionar stand-alone ya que puede servir para pequeños desarrollos en FPGA, pero el objetivo de primera debería ser su funcionamiento en conjunto con la CIAA.

- En particular me inclino más por la idea de que la programación 'stand-alone' en caso de poseer, al igual que la interfaz usb ne general, se haga mediante un uC pequeño como propone Martin y no tener que lidiar con un ftdi, aunque talvez en un primer momento podría dejarse solo a programar desde la edu-CIAA aunque puede ser un poco incómodo tener que bajar un firmware a la CIAA para programar la FPGA y luego bajar el código 'funcional' a la CIAA para interactuar con la FPGA.

- Coincido con el tema de pulsadores/leds, incluso siendo un poncho para la EDU-CIAA estarían disponibles esos aunque pensaría también en miniponchitos con botones y leds si fuera necesario.

- Si le pondría memoria externa a la FPGA, puede ser muy útil.

- No se si agregarle más cosas en un principio, para no encarecer demasiado. Habría que aceitar bien el tema de los ponchos/miniponchos con cosas como ADC/DACs, al menos diseños de referencia para el que los quiera implementar.

Me gusta el diseño preliminar de la placa Martin, tendría que sentarme y estudiarlo un poco para ver que sugerencias hacer.

Por lo pronto me sumo al debate inicial y luego al desarrollo de la plataforma.

Saludos

Andrés C.

[martin ribelotta]

Va entre lineas...

El 13 de septiembre de 2016, 11:27, Andres Cassagnes <andre...@gmail.com> escribió:

Buenas. No suelo participar activamente pero sigo los temas relacionados a la CIAA de cerca esperando siempre el momento para meterme más de lleno, casi como estar agazapado entre la maleza esperando el momento. Ese momento que espero depende más de mi que del proyecto ya que el quilombo de tiempos es mío.

Siempre son bien recibidas las aportaciones aunque sea comentar y dar opiniones.

 

Este tema en particular me interesó mucho ya que tengo pensado a futuro trabajar con FPGAs (en realidad, actualmente mi proyecto de tesis de grado las toca de cerca, pero pretendo hacerlo más de lleno y a nivel más profesional) y tener una plataforma dentro del proyecto CIAA me resultaría útil e interesante por igual. Por lo que además de verter mi opinión me gustaría sumarme al proyecto en esta rama y eventualmente en la ligada al desarrollo de la EDU-CIAA-Xilinx.

El problema que le veo a la EDU-CIAA-Xilinx, que el propósito para el que fue creada (costar 100 usd o menos y servir como plataforma de desarrollo para universidades) fue ampliamente superado por el fabricante (Xilinx) al ofrecer EXACTAMENTE eso con sus placas de desarrollo (Arty-algo ahora no recuerdo) por 99 usd.

No se en que estado quedo el proyecto pero ojalá se siga.

 

Yendo al tema en cuestión.

Me parece de gran utilidad tener un poncho FPGA que se conecte directamente a la EDU-CIAA pensado en principio como un "accesorio" para esta, en términos de ampliar sus capacidades y trabajar en conjunto, pero que tenga también la posibilidad de funcionar stand-alone ya que puede servir para pequeños desarrollos en FPGA, pero el objetivo de primera debería ser su funcionamiento en conjunto con la CIAA.

Mas abajo detallo un poco el diagrama de bloques, pero mi idea es usarlo principalmente como FPGA stand alone. 

 

- En particular me inclino más por la idea de que la programación 'stand-alone' en caso de poseer, al igual que la interfaz usb ne general, se haga mediante un uC pequeño como propone Martin y no tener que lidiar con un ftdi, aunque talvez en un primer momento podría dejarse solo a programar desde la edu-CIAA aunque puede ser un poco incómodo tener que bajar un firmware a la CIAA para programar la FPGA y luego bajar el código 'funcional' a la CIAA para interactuar con la FPGA.

El grabar la "FPGA" es tan simple como mantenerla en RESET (lo que pone todos los pines de IO en alta impedancia) y grabar la flash externa con el *.bit generado por el software libre IceStrorm (bueno, una de sus herramientas) -Si, así como viene-

En principio, esto lo puede hacer cualquier cosa, desde la CIAA en modo maestro-esclavo, un JTAG externo o un micro interno a la placa (que me faltó incluir en el esquemático) como el LPC11U35 a través del USB (como un pendrive por ejemplo)

 

- Coincido con el tema de pulsadores/leds, incluso siendo un poncho para la EDU-CIAA estarían disponibles esos aunque pensaría también en miniponchitos con botones y leds si fuera necesario.

Un led es bastante recomendable para cualquier diseño de FPGA, mas que nada como indicativo de keep-alive.

Es bastante gracioso trabajar con placas de 22000 dolares y ponerse a mirar el heartbell para ver si tenes el core correcto o no (con distintos patrones de blinking jejejeje)

 

- Si le pondría memoria externa a la FPGA, puede ser muy útil.

Con el encapsulado de 100 pines es un dolor de OO, pero con el de 144 alcanza y sobra muy bien.

Me están quedando 52 GPIO con la SDRAM, la flash SPI, y las interfaces SPI/I2C/SERIAL a la CIAA-EDU. Estas ultimas quedarian libres de usarse stand-alone en vez de con la CIAA.

 

- No se si agregarle más cosas en un principio, para no encarecer demasiado. Habría que aceitar bien el tema de los ponchos/miniponchos con cosas como ADC/DACs, al menos diseños de referencia para el que los quiera implementar.

Eso también da para poder hacer placas simple faz mucho mas baratas con ADC/DAC o cualquier cosa que se le quiera poner (se me viene a la mente un poncho retro-arcade)

 

Me gusta el diseño preliminar de la placa Martin, tendría que sentarme y estudiarlo un poco para ver que sugerencias hacer.

A mi lo que me preocupa es que esto es un poncho que puede usar otros ponchos... como le llamariamos a eso? Poncho puneño????

 

Por lo pronto me sumo al debate inicial y luego al desarrollo de la plataforma.

Saludos

Andrés C.

Mi idea de diagrama de bloques la dejo acá:

https://docs.google.com/document/d/1aIACD3gf-0aKyBWzI8I7Sw8T8ErDxMdtqenEKCppgNY/edit?usp=sharing

Ahí se puede ver que, para programar el FPGA, solo hace falta programar la SPI (manteniendo en reset el FPGA) y eso se debería poder hacer a través de cualquier interfaz (por la CIAA, por JTAG o por un micro barato stand alone como el lpc11u35)

¿Porque el LPC11U35? Simple, la picoCIAA ya incorpora uno (con firmware trabajado de forma magistral por Pablo Ridolfi) y la CIAA-ACC va a incorporar uno en el mismo plan. El firmware de este micro, si bien es programable, podría ser tan simple como bajar la imagen de la SPI por usb usando el protocolo MSC (mass storage class -Un pendriver, vamos...-)

Saludos.

[Andres Cassagnes]

Coincido con prácticamente todos tus comentarios. Sobre los ADC/DACs/ponchos creo que habría que ponerse a laburar un poco más en el tema (bah, la realidad es que yo no se muy bien como viene el tema, tengo que ponerme a chusmear un poco en la wiki).

Al menos un led seguro tiene que tener, en una empresa en que trabajé le poníamos el "led loco" a todas las pacas, aunque después quedara dentro del gabinete del producto, para desarrollo era fundamental.

Respecto a la "programación" de la FPGA, más allá de su facilidad me parece lo mejor que el poncho tenga directamente un uC para ese tema y a modo de interfaz usb. Habría que ver eso en el firmware de ese micro, pero no es nada complejo.

Lo del jenga de ponchos no me parece malo en si mismo, el tema es ver la forma de que eso no sea perjudicial. Si bien no me gusta eso de tener cuatro shields apilados, si viene bien tener por ejemplo la edu-CIAA, arriba el poncho FPGA y arriba un ponchito ADC/DAC que se yo, o con un ponchito con salida HDMI o cualquier otra cosa (me gustó lo del poncho retro-arcade, podemos armar una rama del proyecto CIAA para esto?). Me gusta la foma en que quedan los conectores en el diseño preliminar.

De todo este hilo lo que saco en conclusión sería:

- FPGA ICE40HX4K-TQ144144 pines

- SDRAM on board (voto por esto)
- LPC11U35 para interfaz usb de la FPGA y carga del .bit.

Como decía, este proyecto me interesa bastante y me gustaría participar más activamente, así que me engancho para cualquier cosa que haya que ir haciendo. Por lo pronto me voy a poner a ver el diagrama en bloques y el esquemático que tenés en github.

Saludos

Andrés C.

[martin ribelotta]

El 13 de septiembre de 2016, 15:20, Andres Cassagnes <andre...@gmail.com> escribió:

Coincido con prácticamente todos tus comentarios. Sobre los ADC/DACs/ponchos creo que habría que ponerse a laburar un poco más en el tema (bah, la realidad es que yo no se muy bien como viene el tema, tengo que ponerme a chusmear un poco en la wiki).

Al menos un led seguro tiene que tener, en una empresa en que trabajé le poníamos el "led loco" a todas las pacas, aunque después quedara dentro del gabinete del producto, para desarrollo era fundamental.

Respecto a la "programación" de la FPGA, más allá de su facilidad me parece lo mejor que el poncho tenga directamente un uC para ese tema y a modo de interfaz usb. Habría que ver eso en el firmware de ese micro, pero no es nada complejo.

No deberia ser muy dificil, es retocar un poco el ejemplo de MSC bootloader que en vez de escribir en flash interna escriba en la FLASH spi (lo digo apenas habiendo tocado un poco del firmware de Pablo Ridolfi jejejeje)

 

Lo del jenga de ponchos no me parece malo en si mismo, el tema es ver la forma de que eso no sea perjudicial. Si bien no me gusta eso de tener cuatro shields apilados, si viene bien tener por ejemplo la edu-CIAA, arriba el poncho FPGA y arriba un ponchito ADC/DAC que se yo, o con un ponchito con salida HDMI o cualquier otra cosa (me gustó lo del poncho retro-arcade, podemos armar una rama del proyecto CIAA para esto?). Me gusta la foma en que quedan los conectores en el diseño preliminar.

Lo del jenga de ponchos me parece aberrante pero bueno, no encontré otra forma de hacerlo (la otra seria usar un conector tipo SODIMM/DIMM y hacer placas con el edge en esa forma, no se si es lo mas "planchable" (por ahí un dimm estándar si lo sea)

Por ahora queda como "poncho jenga" porque es la mas facil de tirar cablecitos y probar.

 

De todo este hilo lo que saco en conclusión sería:

- FPGA ICE40HX4K-TQ144144 pines

- SDRAM on board (voto por esto)
- LPC11U35 para interfaz usb de la FPGA y carga del .bit.

Como decía, este proyecto me interesa bastante y me gustaría participar más activamente, así que me engancho para cualquier cosa que haya que ir haciendo. Por lo pronto me voy a poner a ver el diagrama en bloques y el esquemático que tenés en github.

No drama, dale tranquilo que entre todos vamos haciendo algo :-

[Pedro Martos]

Hola,

La edu-ciaa-xilinx es una idea mia, precisamente para difundir el uso de fpgas a traves de una plataforma de bajo costo y conseguible/armable. Aprovecho el thread para comentar su estado:

El 13 de septiembre de 2016, 15:00, martin ribelotta<martinr...@gmail.com> escribió:

El problema que le veo a la EDU-CIAA-Xilinx, que el propósito para el que fue creada (costar 100 usd o menos y servir como plataforma de desarrollo para universidades) fue ampliamente superado por el fabricante (Xilinx) al ofrecer EXACTAMENTE eso con sus placas de desarrollo (Arty-algo ahora no recuerdo) por 99 usd.

No se en que estado quedo el proyecto pero ojalá se siga.

 

El diagrama esquematico esta terminado y revisado de acuerdo a las recomendaciones de las UG de xilinx (estaria bueno si alguien mas lo puede revisar), ahora habria que empezar el pcb. (en el repo esta toda la informacion) 

Con respecto al pcb hay 2 temas: usar kicad para esto es, por decirlo suavemente, como apretarse los dedos con una puerta lentamente, le faltan cosas que estaban presentes en el tango pcb que usaba hace 20 años para hacer mis primeras placas, por lo que no me siento muy motivado para usarlo. Por otra parte, como comenta Martin, Xilinx esta haciendo un esfuerzo heroico por imponer vivado como herramienta de desarrollo. Eso lo hace en 2 frentes, por un lado trazo una linea y las fpga de linea-7 para arriba solo se pueden trabajar con vivado y las fpga linea-6 para abajo solo se pueden trabajar con ISE; cosa de forzarte a migrar a vivado. Al mismo tiempo sacaron la placa Arty a u$s 99; la fpga sola sale u$s 35 en digikey, por lo que ese precio solo es posible sin ganancia y en cantidades del orden de  1K.

Asimismo si ahora se compran 3 unidades puerta a puerta, se tienen u$s 297 de placas + u$s 48 de shipment + nacionalizacion (supongamos 50%) + iva (21%); lo que da un costo unitario de alrededor de u$s180; en el repo hay un costeo con precios de digikey que da alrededor de u$s 150. O sea que fabricarlas aca da mas o menos lo mismo que traerlas de digikey, lo cual hace poco atractivo hacer el esfuerzo de fabricarlas aqui.

cordialmente,

Pedro

[martin ribelotta]

Hola Pedro, va entre lineas

El 13 de septiembre de 2016, 16:00, Pedro Martos <pima...@gmail.com> escribió:

Hola,

La edu-ciaa-xilinx es una idea mia, precisamente para difundir el uso de fpgas a traves de una plataforma de bajo costo y conseguible/armable. Aprovecho el thread para comentar su estado:

El 13 de septiembre de 2016, 15:00, martin ribelotta<martinribelotta@gmail.com> escribió:

El problema que le veo a la EDU-CIAA-Xilinx, que el propósito para el que fue creada (costar 100 usd o menos y servir como plataforma de desarrollo para universidades) fue ampliamente superado por el fabricante (Xilinx) al ofrecer EXACTAMENTE eso con sus placas de desarrollo (Arty-algo ahora no recuerdo) por 99 usd.

No se en que estado quedo el proyecto pero ojalá se siga.

 

El diagrama esquematico esta terminado y revisado de acuerdo a las recomendaciones de las UG de xilinx (estaria bueno si alguien mas lo puede revisar), ahora habria que empezar el pcb. (en el repo esta toda la informacion) 

Lo vi pero no he tenido tiempo de darle una chequeada, sumale a eso que estoy con mil cosas :-(

 

Con respecto al pcb hay 2 temas: usar kicad para esto es, por decirlo suavemente, como apretarse los dedos con una puerta lentamente, le faltan cosas que estaban presentes en el tango pcb que usaba hace 20 años para hacer mis primeras placas, por lo que no me siento muy motivado para usarlo.

Me extraña mucho de KiCAD, no se que version estaras usando pero la ultima estable (4.0.algo creo) es bastante decente y tiene de todo lo necesario para hacer ruteo complejo (track len matching, diferencial routing, DRC electrico, etc, etc)

Otra cosa es que no integre analisis de señal/potencia pero eso creo que se lo dejaria para cosas como Hyperlinx porque todos los software que he usado (Altium, Orcad, Eagle, PADs) dejan bastatnte que desear en lo que es analisis serio.

 

Por otra parte, como comenta Martin, Xilinx esta haciendo un esfuerzo heroico por imponer vivado como herramienta de desarrollo. Eso lo hace en 2 frentes, por un lado trazo una linea y las fpga de linea-7 para arriba solo se pueden trabajar con vivado y las fpga linea-6 para abajo solo se pueden trabajar con ISE; cosa de forzarte a migrar a vivado.

El salto a Vivado era totalmente necesario debido a que las FPGA cada vez eran mas inmanejables por el viejo ISE (y sus herrameitnas de fondo) Todavia recuerdo cuando los P&R no eran consistentes entre ejecuciones sin cambiar nada sobre una Virtex6 (eso o es un bug o es algo que no encaja en los nuevos diseños de FPGA V6-7)

Vivado como herramienta tiene los problemas de un sistema nuevo (mucho del flujo de trabajo no esta pulido) pero en vista de lo estable de su sintesis creo que no habia mas opcion que cambiar...

 

Al mismo tiempo sacaron la placa Arty a u$s 99; la fpga sola sale u$s 35 en digikey, por lo que ese precio solo es posible sin ganancia y en cantidades del orden de  1K.

Yo igual no usaria una Arty ni en pedo para algo que no sea home/personal, normalmente me gusta ver cosas con mayor base para los clientes. De todas formas, es ideal para aprender.

En cuanto al costo, es obvio que a Xilinx no le sale 35 usd fabricar una Artyx ni a palos, posiblemente, el silicio salga centavos de dolar y lo que realmente haya que pagar es la propiedad intelectual de las cosas que luego van arriba (backend de vivado por ejemplo o IP Cores de integracion propia)

 

Asimismo si ahora se compran 3 unidades puerta a puerta, se tienen u$s 297 de placas + u$s 48 de shipment + nacionalizacion (supongamos 50%) + iva (21%); lo que da un costo unitario de alrededor de u$s180; en el repo hay un costeo con precios de digikey que da alrededor de u$s 150. O sea que fabricarlas aca da mas o menos lo mismo que traerlas de digikey, lo cual hace poco atractivo hacer el esfuerzo de fabricarlas aqui.

Yo soy de la idea de no reinventar la rueda. Cuando empesaste con el proyecto, no existia nada parecido en el mercado (al menos no al costo planeado), hoy, todo hijo de vecino hace una placa con Artyx y la vende con formato <<inserte aqui el que mejor le convenga>>

Por eso es que esta placa la basamos en iCE40 con herramientas 100% libres y orientandola a poder correr algo como un RISC-V completamente stand alone.

Igual el proyecto CIAA-Xilinx esta para quien quiera aportar y me parece un trabajo muy grande de Pedro que no deberia desperdiciarse asi nomas.

Un saludo grande!

 

cordialmente,

Pedro

[Pablo Cayuela]

Estimados colegas de la lista:

Plataformas abiertas de lógica programable universitarias

En UTN FRC (Córdoba), se realizó ya hace unos 10 años un proyecto de kit CPLD en el CUDAR (Centro Universitario de Desarrollo en Automación y Robótica) que lo dirigió y llevó adelante el Ing. Sergio Olmedo; actualmente es la plataforma con la que se entrenan los estudiantes de Técnicas Digitales 1 todo el año y Técnicas Digitales 4 (electiva) en algunos proyectos de control de motores con cierre de lazo.

http://www.profesores.frc.utn.edu.ar/electronica/tecnicasdigitalesi/pub/file/Manual_kitCPLD_v3.0.pdf
http://www.profesores.frc.utn.edu.ar/electronica/tecnicasdigitalesI/?pIs=1039
https://www.youtube.com/watch?v=kjzDoRWLfjs

Este material es completamente libre y con los años muchos estudiantes se han construido su propio kit hasta con el método de la plancha. Algunas universidades del oeste del país manifestaron interés en armarse de estos kits y les facilitamos ayuda en su momento.

Se construyeron en el CUDAR unos 10 kits de este proyecto con CPLD que fueron financiadas con distintos programas académicos de apoyo, y se dejaron disponibles en el LTDI (Laboratorio de Técnicas Digitales e Informática) unas 8, mientras 2 quedaron en el CUDAR.

Este proyecto estaba dentro de un plan mayor en función de una propuesta que teníamos para renovar algunos contenidos en las carreras de Ingeniería Electrónica e Ingeniería en Sistemas:

http://www.jidis.frc.utn.edu.ar/papers/f5e88d7ae719840d819fb2ca4ad1.pdf

También en el CUDAR-UTN FRC se realizó un proyecto de kit FPGA que lo dirigió y llevó adelante el Ing. Luis Guanuco, inicialmente como proyecto de fin de carrera siendo becario.

Es completamente abierto, desde los PCBs a los manuales, está todo publicado en OpenCores:

http://opencores.org/project,phr

Se construyeron también unos 10 kits de este proyecto PHR que fueron financiadas con distintos programas académicos de apoyo, y se dejaron disponibles en el LTDI (Laboratorio de Técnicas Digitales e Informática) unas 8, mientras 2 quedaron en el CUDAR.

Como detalle constructivo hay que tener en cuenta que siguiendo los lineamientos de Xilinx hizo falta utilizar 4 capas en el PCB de la placa principal. El proyecto incluye a su vez una placa de fuente de alimentación y otra para programación derivada del OpenOCD.

La fuente es un diseño original del INTI, origen del sitio FPGALibre (http://fpgalibre.sourceforge.net/), donde también desarrollan hardware abierto sin importar el fabricante, y se evita el software propietario en la medida de lo posible, facilitando donde sea viable el desarrollo de herramientas propias:

http://www.inti.gob.ar/microynanoelectronica/pdf/S3Proto_mini.pdf

Brengi, Tropea y otros integrantes del INTI han sido para nosotros grandes guías en nuestro desarrollo y uso de lógica programable en UTN FRC.

Otras plataformas abiertas de origen comercial

A modo de comentario de plataformas abiertas, he encontrado la XULA de XESS, que si quisieran replicarla o imitarla están disponibles los diseños de PCB, el código del microcontrolador que hace la comunicación y depuración, el libro y manual:

http://www.xess.com/shop/product/xula-50/
http://www.xess.com/shop/product/xula-200/
http://www.xess.com/shop/product/xula2-lx9/
http://www.xess.com/shop/product/xula2-lx25/

Estas placas son muy interesantes pues incluyen memoria estática externa y un circuito de programación y depuración; en el manual se da una buena introducción de su uso en diseños de aprendizaje.

En particular me pareció interesante el uso del microcontrolador y su firmware para ser empleado como herramienta de depuración para viejas placas que solo poseen una conexión JTAG y no una USB, de las que disponemos en el laboratorio, ya que el código está disponible completamente sobre un microcontrolador pequeño y versátil.

Dado de que nuestra plataforma PHR usa la misma FPGA de una XULA-200 el manual de esta es aplicable en las clases que damos con la nuestra en alta medida.

También estamos desarrollando módulos de memoria estática en forma de módulos exteriores para esta y otras placas de Digilent más viejas, con lo que potenciaremos los tipos de práctica realizables.

Espero que les sirva de referencia a todos los que desarrollan en este ámbito en especial en entornos educativos; quedo a su disposición para cualquier consulta.

Aprovecho para felicitar a los desarrolladores, impulsores y usuarios de la CIAA, EDU-CIAA y sus derivados como la PicoCIAA y esta CIAA-FPGA que ojalá pronto esté entre nosotros.

Ing. Sist. Inf. e Ing. Electrónico Pablo Cayuela

Laboratorio de Técnicas Digitales e Informática

y

Centro Universitario de Desarrollo en Automación y Robótica

Prof. en Depto. Ing. Electrónica y Depto. Ing. Sist. Inf.

UTN FRC

Córdoba

Argentina

[Pedro Martos]

Hola, comento entrelineas

El 14 de septiembre de 2016, 00:18, martin ribelotta<martinr...@gmail.com> escribió:

Hola Pedro, va entre lineas

El 13 de septiembre de 2016, 16:00, Pedro Martos <pima...@gmail.com> escribió:

Hola,

La edu-ciaa-xilinx es una idea mia, precisamente para difundir el uso de fpgas a traves de una plataforma de bajo costo y conseguible/armable. Aprovecho el thread para comentar su estado:

El 13 de septiembre de 2016, 15:00, martin ribelotta<martinribelotta@gmail.com> escribió:

El problema que le veo a la EDU-CIAA-Xilinx, que el propósito para el que fue creada (costar 100 usd o menos y servir como plataforma de desarrollo para universidades) fue ampliamente superado por el fabricante (Xilinx) al ofrecer EXACTAMENTE eso con sus placas de desarrollo (Arty-algo ahora no recuerdo) por 99 usd.

No se en que estado quedo el proyecto pero ojalá se siga.

 

El diagrama esquematico esta terminado y revisado de acuerdo a las recomendaciones de las UG de xilinx (estaria bueno si alguien mas lo puede revisar), ahora habria que empezar el pcb. (en el repo esta toda la informacion) 

Lo vi pero no he tenido tiempo de darle una chequeada, sumale a eso que estoy con mil cosas :-(

No hay problema, todo esto es 100% a pulmon y toda ayuda es mas que bienvenida (:-D

 

 

Con respecto al pcb hay 2 temas: usar kicad para esto es, por decirlo suavemente, como apretarse los dedos con una puerta lentamente, le faltan cosas que estaban presentes en el tango pcb que usaba hace 20 años para hacer mis primeras placas, por lo que no me siento muy motivado para usarlo.

Me extraña mucho de KiCAD, no se que version estaras usando pero la ultima estable (4.0.algo creo) es bastante decente y tiene de todo lo necesario para hacer ruteo complejo (track len matching, diferencial routing, DRC electrico, etc, etc)

Otra cosa es que no integre analisis de señal/potencia pero eso creo que se lo dejaria para cosas como Hyperlinx porque todos los software que he usado (Altium, Orcad, Eagle, PADs) dejan bastatnte que desear en lo que es analisis serio.

No llegue a jugar con la parte pcb. en la parte de captura de esquematicos le falta cosas tan elementales como la capacidad de crear librerias sin necesidad de crear una libreria vacia "a mano", cargarla y agregarle los componentes. El simbolo de los resistores es un rectangulo; ¿es mucho pedir que tambien incluya un simbolo de tipo resorte/fuelle? Obviamente le faltan todas las fpga, pero eso es esperable (termine haciendo un programa que levanta el .cvs de xilinx con la descripcion de pines y genera la libreria del componente en formato kicad). Tambien las capacidades de edicion grupal son limitadas (en encapsulados de 256 pines es algo bastante necesario cuando uno necesita hacer cambios globales). 

 

 

Por otra parte, como comenta Martin, Xilinx esta haciendo un esfuerzo heroico por imponer vivado como herramienta de desarrollo. Eso lo hace en 2 frentes, por un lado trazo una linea y las fpga de linea-7 para arriba solo se pueden trabajar con vivado y las fpga linea-6 para abajo solo se pueden trabajar con ISE; cosa de forzarte a migrar a vivado.

El salto a Vivado era totalmente necesario debido a que las FPGA cada vez eran mas inmanejables por el viejo ISE (y sus herrameitnas de fondo) Todavia recuerdo cuando los P&R no eran consistentes entre ejecuciones sin cambiar nada sobre una Virtex6 (eso o es un bug o es algo que no encaja en los nuevos diseños de FPGA V6-7)

Eso puede ser porque las herramientas de ise usan un algoritmo pseudoaleatorio para el P&R: uno de los parametros que le pasas es la semilla. xilinx te garantiza que si usas la misma semilla, obtenes el mismo ruteo en una nueva iteracion, pero la semilla cambia iteracion a iteracion, por lo que si tenes un ruteo que cumple las restricciones, tenes que tomar nota de la semilla que se uso para generarlo. Tambien las herramientas de ise son monothread, lo cual en diseños grandes genera tiempos eternos de sintesis e implementacion.

El tema con vivado es que es demasiado alto nivel para mi gusto. todo es muy bonito y generas diseños complejos facilmente, pero me gustaria saber si los puedo hacer andar a 500MSPs de entrada o si tengo que ponerme a jugar con el verilog/vhdl generado.

 

Vivado como herramienta tiene los problemas de un sistema nuevo (mucho del flujo de trabajo no esta pulido) pero en vista de lo estable de su sintesis creo que no habia mas opcion que cambiar...

Si usas -7 para arriba, no hay opcion... ise sintetiza muy pocas partes de esa familia; tarde o temprano hay que migrar, pero nuevamente me pregunto como sera el ciclo de desarrollo cuando se necesita velocidad (+ de 300 MHz)

 

 

Al mismo tiempo sacaron la placa Arty a u$s 99; la fpga sola sale u$s 35 en digikey, por lo que ese precio solo es posible sin ganancia y en cantidades del orden de  1K.

Yo igual no usaria una Arty ni en pedo para algo que no sea home/personal, normalmente me gusta ver cosas con mayor base para los clientes. De todas formas, es ideal para aprender.

Para aprender es perfecta: un tamaño aceptable, un costo mas que aceptable. La unica ventaja de la edu-ciaa-xilinx sobre la arty es que su encapsulado FTG256 tiene una distancia de 1mm entre bolitas; la arty tiene un encapsulado csg324 de 0.8, lo que hace mas cara la placa y el montaje en argentina (de hecho no estoy seguro si se puede hacer 0.8 multicapa en argentina por el ancho de track que exige).

 

En cuanto al costo, es obvio que a Xilinx no le sale 35 usd fabricar una Artyx ni a palos, posiblemente, el silicio salga centavos de dolar y lo que realmente haya que pagar es la propiedad intelectual de las cosas que luego van arriba (backend de vivado por ejemplo o IP Cores de integracion propia)

En realidad por lo que hable con la gente de digilent, es algo separado de xilinx. Xilinx le subvenciona cosas, le da informacion por adelantado, y le atiende el telefono cuando tienen dudas, pero digilent no es xilinx (de hecho la arty no es diseño de digilent, sino de avnet) 

 

 

Asimismo si ahora se compran 3 unidades puerta a puerta, se tienen u$s 297 de placas + u$s 48 de shipment + nacionalizacion (supongamos 50%) + iva (21%); lo que da un costo unitario de alrededor de u$s180; en el repo hay un costeo con precios de digikey que da alrededor de u$s 150. O sea que fabricarlas aca da mas o menos lo mismo que traerlas de digikey, lo cual hace poco atractivo hacer el esfuerzo de fabricarlas aqui.

Yo soy de la idea de no reinventar la rueda. Cuando empesaste con el proyecto, no existia nada parecido en el mercado (al menos no al costo planeado), hoy, todo hijo de vecino hace una placa con Artyx y la vende con formato <<inserte aqui el que mejor le convenga>>

Por eso es que esta placa la basamos en iCE40 con herramientas 100% libres y orientandola a poder correr algo como un RISC-V completamente stand alone.

Igual el proyecto CIAA-Xilinx esta para quien quiera aportar y me parece un trabajo muy grande de Pedro que no deberia desperdiciarse asi nomas.

Un saludo grande!

Muchisimas gracias por el apoyo! =)

Quizas (cuando disponga de algo mas de tiempo) la termine y haga una pequeña tirada (en un panel entrarian 25 placas) como ejercicio de desarrollo (ver que la ddr funciona a la maxima velocidad posible, que el controlador de memoria quedo bien instanciado, etc); todo ello apuntando a una placa mas high-end, tipo zynq ultrascale+  con capacidad de conectarle una fmcomms3 o una fmcomms5. Creo que hay un nicho de mercado ahi para exportar tecnologia, pero para correr maratones primero hay que caminar... 

cordialmente,

Pedro

(perdon por la catarsis)

[Andres Cassagnes]

Creo que la CIAA-Xilinx apuntaría a otro propósito, como bien dice Pedro, distinto al poncho-FPGA del que estábamos hablando. Son dos proyectos que se pueden llevar en paralelo y que sería interesante llevar a cabo.

El 14 de septiembre de 2016, 12:14, Pedro Martos <pima...@gmail.com> escribió:

Hola, comento entrelineas

--

[martin ribelotta]

Aporto algunas cosas:

El 14 de septiembre de 2016, 12:14, Pedro Martos <pima...@gmail.com> escribió:

Hola, comento entrelineas

El 14 de septiembre de 2016, 00:18, martin ribelotta<martinribelotta@gmail.com> escribió:

Hola Pedro, va entre lineas

El 13 de septiembre de 2016, 16:00, Pedro Martos <pima...@gmail.com> escribió:

Hola,

La edu-ciaa-xilinx es una idea mia, precisamente para difundir el uso de fpgas a traves de una plataforma de bajo costo y conseguible/armable. Aprovecho el thread para comentar su estado:

El 13 de septiembre de 2016, 15:00, martin ribelotta<martinribelotta@gmail.com> escribió:

El problema que le veo a la EDU-CIAA-Xilinx, que el propósito para el que fue creada (costar 100 usd o menos y servir como plataforma de desarrollo para universidades) fue ampliamente superado por el fabricante (Xilinx) al ofrecer EXACTAMENTE eso con sus placas de desarrollo (Arty-algo ahora no recuerdo) por 99 usd.

No se en que estado quedo el proyecto pero ojalá se siga.

 

El diagrama esquematico esta terminado y revisado de acuerdo a las recomendaciones de las UG de xilinx (estaria bueno si alguien mas lo puede revisar), ahora habria que empezar el pcb. (en el repo esta toda la informacion) 

Lo vi pero no he tenido tiempo de darle una chequeada, sumale a eso que estoy con mil cosas :-(

No hay problema, todo esto es 100% a pulmon y toda ayuda es mas que bienvenida (:-D

 

 

Con respecto al pcb hay 2 temas: usar kicad para esto es, por decirlo suavemente, como apretarse los dedos con una puerta lentamente, le faltan cosas que estaban presentes en el tango pcb que usaba hace 20 años para hacer mis primeras placas, por lo que no me siento muy motivado para usarlo.

Me extraña mucho de KiCAD, no se que version estaras usando pero la ultima estable (4.0.algo creo) es bastante decente y tiene de todo lo necesario para hacer ruteo complejo (track len matching, diferencial routing, DRC electrico, etc, etc)

Otra cosa es que no integre analisis de señal/potencia pero eso creo que se lo dejaria para cosas como Hyperlinx porque todos los software que he usado (Altium, Orcad, Eagle, PADs) dejan bastatnte que desear en lo que es analisis serio.

No llegue a jugar con la parte pcb. en la parte de captura de esquematicos le falta cosas tan elementales como la capacidad de crear librerias sin necesidad de crear una libreria vacia "a mano", cargarla y agregarle los componentes. El simbolo de los resistores es un rectangulo; ¿es mucho pedir que tambien incluya un simbolo de tipo resorte/fuelle? Obviamente le faltan todas las fpga, pero eso es esperable (termine haciendo un programa que levanta el .cvs de xilinx con la descripcion de pines y genera la libreria del componente en formato kicad). Tambien las capacidades de edicion grupal son limitadas (en encapsulados de 256 pines es algo bastante necesario cuando uno necesita hacer cambios globales). 

El workflow es un tanto rudimentario, pero después de haber trabajado con Eagle/OrCAD para DOS cualquier cosa me parece respetable... Tal vez mi no-problema con kicad sea justamente ese, que estoy acostumbrado a hacer scripts para todo y como KiCAD hace todo con texto plano es super facil automatizar la mayoría de las tareas.

Por desgracia, ninguno de los scripts que uso/use, son demasiado publicables por ahí o ya hay cosas mejores.

La idea es que todo eso se convierta en scripts de python, pero todavía el engine esta muy verde.,

 

 

 

Por otra parte, como comenta Martin, Xilinx esta haciendo un esfuerzo heroico por imponer vivado como herramienta de desarrollo. Eso lo hace en 2 frentes, por un lado trazo una linea y las fpga de linea-7 para arriba solo se pueden trabajar con vivado y las fpga linea-6 para abajo solo se pueden trabajar con ISE; cosa de forzarte a migrar a vivado.

El salto a Vivado era totalmente necesario debido a que las FPGA cada vez eran mas inmanejables por el viejo ISE (y sus herrameitnas de fondo) Todavia recuerdo cuando los P&R no eran consistentes entre ejecuciones sin cambiar nada sobre una Virtex6 (eso o es un bug o es algo que no encaja en los nuevos diseños de FPGA V6-7)

Eso puede ser porque las herramientas de ise usan un algoritmo pseudoaleatorio para el P&R: uno de los parametros que le pasas es la semilla. xilinx te garantiza que si usas la misma semilla, obtenes el mismo ruteo en una nueva iteracion, pero la semilla cambia iteracion a iteracion, por lo que si tenes un ruteo que cumple las restricciones, tenes que tomar nota de la semilla que se uso para generarlo. Tambien las herramientas de ise son monothread, lo cual en diseños grandes genera tiempos eternos de sintesis e implementacion.

Si, luego averigüe estas cosas, pero sigue siendo un muy mal diseño desde el punto del software (ok, en el momento que la EDA dio a luz el ISE y sus herramientas no se comprendia del todo como hacer las cosas)

 

El tema con vivado es que es demasiado alto nivel para mi gusto. todo es muy bonito y generas diseños complejos facilmente, pero me gustaria saber si los puedo hacer andar a 500MSPs de entrada o si tengo que ponerme a jugar con el verilog/vhdl generado.

Eso te lo da el timing report, pero eso tambien pasaba con ISE, de hecho, recuerdo una anécdota bastante bizarra donde mis constrainst en el dominio de clock en el que trabajaba decian 5ns (200MHz) pero la herramienta de sintesis del ISE no estaba segura ella misma de sus estimaciones asi que me lo ponia como un Warning en vez de como un error.

Por logica, al llevarlo al FPGA en cuestion (una Virtex6 sobre una carrier board conectada a un PCIe por un lado y a un par de DACs por el otro) se tiraba unos pedos de colores que no sabias que pensar.

Lo facil, bajarle la frecuencia, y andaba, pero el requisito eran 200MHz asi que a tragar...

El reporte decia algo asi (en mis coloquilaes palabras):

- Maximum logic delay: 2.xxx nS

- Maximum fly time delay: 3.yyy nS

- Critical time path 5.9 nS >.<!!!!!!

Por supuesto, eso lo vi tres dias despues mientras buceaba en 200 millones de warnings (que eran del framework del fabricante y siempre estuvieron ahi)

O sea, el ruteo (que obviamente pasaba por LUTs para poder completarse -estaba al 70% de slices-) tenia mas retardo que la logica empleada >.<

Todavia me acuerdo el "Ponele mas pilepiles..." y yo diciendo "Al que! al cable!!!" Que calenturas con esas placas jajajaja.

 

Vivado como herramienta tiene los problemas de un sistema nuevo (mucho del flujo de trabajo no esta pulido) pero en vista de lo estable de su sintesis creo que no habia mas opcion que cambiar...

Si usas -7 para arriba, no hay opcion... ise sintetiza muy pocas partes de esa familia; tarde o temprano hay que migrar, pero nuevamente me pregunto como sera el ciclo de desarrollo cuando se necesita velocidad (+ de 300 MHz)

Mas arriba cuento mis desventuras con el ISE, pero con el Vivado he llegado a sintetizar a 300MHz sobre un XZ7020 con speed grade de -1 y aca, el delay de vuelo era menor o similar al delay de compuertas, asi que mi conclucion es que las nuevas FPGA de Xilinx tienen un mejor mecanismo de ruteo de señales (o el vivado es mas inteligente en ese aspecto)

Por supuesto, el timing que entregaba el reporte era consistente con lo que se veia en la realidad y no habia duda alguna de que funcionara (le poniamos constraints mas chicos y explotaba en el P&R con un termendo error como debe ser)

 

 

 

Al mismo tiempo sacaron la placa Arty a u$s 99; la fpga sola sale u$s 35 en digikey, por lo que ese precio solo es posible sin ganancia y en cantidades del orden de  1K.

Yo igual no usaria una Arty ni en pedo para algo que no sea home/personal, normalmente me gusta ver cosas con mayor base para los clientes. De todas formas, es ideal para aprender.

Para aprender es perfecta: un tamaño aceptable, un costo mas que aceptable. La unica ventaja de la edu-ciaa-xilinx sobre la arty es que su encapsulado FTG256 tiene una distancia de 1mm entre bolitas; la arty tiene un encapsulado csg324 de 0.8, lo que hace mas cara la placa y el montaje en argentina (de hecho no estoy seguro si se puede hacer 0.8 multicapa en argentina por el ancho de track que exige).

Hablando de la Arty, me encantaria que se pudiera hacer la EDU-CIAA-XILINX a un costo similar solo porque es diseño de aca.

 

 

En cuanto al costo, es obvio que a Xilinx no le sale 35 usd fabricar una Artyx ni a palos, posiblemente, el silicio salga centavos de dolar y lo que realmente haya que pagar es la propiedad intelectual de las cosas que luego van arriba (backend de vivado por ejemplo o IP Cores de integracion propia)

En realidad por lo que hable con la gente de digilent, es algo separado de xilinx. Xilinx le subvenciona cosas, le da informacion por adelantado, y le atiende el telefono cuando tienen dudas, pero digilent no es xilinx (de hecho la arty no es diseño de digilent, sino de avnet) 

(bis con lo de arriba)

 

 

 

Asimismo si ahora se compran 3 unidades puerta a puerta, se tienen u$s 297 de placas + u$s 48 de shipment + nacionalizacion (supongamos 50%) + iva (21%); lo que da un costo unitario de alrededor de u$s180; en el repo hay un costeo con precios de digikey que da alrededor de u$s 150. O sea que fabricarlas aca da mas o menos lo mismo que traerlas de digikey, lo cual hace poco atractivo hacer el esfuerzo de fabricarlas aqui.

Yo soy de la idea de no reinventar la rueda. Cuando empesaste con el proyecto, no existia nada parecido en el mercado (al menos no al costo planeado), hoy, todo hijo de vecino hace una placa con Artyx y la vende con formato <<inserte aqui el que mejor le convenga>>

Por eso es que esta placa la basamos en iCE40 con herramientas 100% libres y orientandola a poder correr algo como un RISC-V completamente stand alone.

Igual el proyecto CIAA-Xilinx esta para quien quiera aportar y me parece un trabajo muy grande de Pedro que no deberia desperdiciarse asi nomas.

Un saludo grande!

Muchisimas gracias por el apoyo! =)

Quizas (cuando disponga de algo mas de tiempo) la termine y haga una pequeña tirada (en un panel entrarian 25 placas) como ejercicio de desarrollo (ver que la ddr funciona a la maxima velocidad posible, que el controlador de memoria quedo bien instanciado, etc); todo ello apuntando a una placa mas high-end, tipo zynq ultrascale+  con capacidad de conectarle una fmcomms3 o una fmcomms5. Creo que hay un nicho de mercado ahi para exportar tecnologia, pero para correr maratones primero hay que caminar... 

Seria algo como un powerup de la CIAA-ACC???? Los ZynqMPSoc los propuse en su momento para hacerla, pero se descartaron porque todavia no existia silicio (en realidad si, pero era y es todavia para los MVC -most value clients- que si se lo pedimos a Xilinx, seguro que acepta)

 

cordialmente,

Pedro

(perdon por la catarsis)

No hay problema, hay que hacer un subforo de FPGAs para tener un consultorio sobre estas cosas jajajajajaja 

[martin ribelotta]

Por supuesto, estaria genial si se puede dar un empujon a la CIAA-Xilinx.

Por otro lado, ya agregue el LPC11U35 con capacidad para reprogramar la FLASH SPI del FPGA:

https://github.com/martinribelotta/poncho_fpga/tree/vq144

Me faltaria agregarle un pin de sensado al LPC11U35 para que vea si tiene una EDU-CIAA conectada abajo y ponga en Hi-Z los pines correspondientes.

Por el momento, queda como sustituto stand alone el micro chico y la EDU como posible master.

Para seguir alimentando el hype de esto les dejo otra captura de la placa en 3D:

[Andres Cassagnes]

Muy bueno. Al menos conmigo funcionan las capturas de la placa en 3D y me levanta el hype. Bajé los aarchivos de la placa y me voy a poner a ver con mas atención el esquemático. También me tengo que poner a leer un poco más de info sobre la FPGA como para ir entrando en tema y empezar a ver para adelante que se podría hacer en cuanto a entornos de desarrollo y cosas así.

Coincido en seguir para adelante también con la CIAA-Xilinx, apuntándola a un desempeño mayor que esta.

Saludos

Andrés C.

[martin ribelotta]

Call for revisions:

https://github.com/martinribelotta/poncho_fpga

- Esquematico completo

- Place&Route completo

- Pendiente BOM

- Pendiente gerbers

- Pendiente fabricar

Por favor, quienes estén interesados, mirenlo, saquenle el cuero y lo vamos arreglando.

Seguro que hay mil cosas para mejorarle.

[Andres Cassagnes]

Martin, estuve chusmeando un poco el esquemático. Veo que en la parte de Power Supply de la FPGA, al pin Vpp_2V5 lo alimentas desde la net +1V2 pero a través de un diodo con lo que le estarían llegando unos 600mV. A ese pin no habría que mandarle 3V3 a través del diodo para que queden 2.7V?

Sigo revisando.

Saludos

Andrés C.

[martin ribelotta]

El 29 de septiembre de 2016, 12:21, Andres Cassagnes <andre...@gmail.com> escribió:

Martin, estuve chusmeando un poco el esquemático. Veo que en la parte de Power Supply de la FPGA, al pin Vpp_2V5 lo alimentas desde la net +1V2 pero a través de un diodo con lo que le estarían llegando unos 600mV. A ese pin no habría que mandarle 3V3 a través del diodo para que queden 2.7V?

Correcto totalmente.

Si queres cambiarlo y hacer el pull request puede ser una, sino esta noche llego y lo cambio.

 

Sigo revisando.

Gracias!

[Andres Cassagnes]

dame un rato y lo cambio. Va a haber que rerutear despues pero podemos esperar a cerrar los cambios en el esquemático

[martin ribelotta]

El 29 de septiembre de 2016, 12:26, Andres Cassagnes <andre...@gmail.com> escribió:

dame un rato y lo cambio. Va a haber que rerutear despues pero podemos esperar a cerrar los cambios en el esquemático

El reruteo es facil si es solo eso (3v3 esta muy cerca del diodo)

Igual quiero que se mire lo mejor posible esto porque de esas puede haber varias.

[Ariel Lutenberg]

Bien ahí!!!

Eso es trabajo en equipo!

Y además seguramente sirva para inspirar a muchos otros, que pueden ver con qué poco se puede hacer un gran aporte. =)

De hecho, si alguien quiere puede ayudar ahora mismo revisando entre otras cosas el esquemático de la CIAA-Safety, basada en un TMS570 de Texas, que están por empezar a diseñar el circuito impreso Diego Fusari (UNRC) y Matias Ferraro (UNCA) a quienes aprovecho para poner en copia.

Acá está la info que ellos están manejando:

- https://drive.google.com/drive/folders/0B93ns4SKxOhhamIweHdQbU1xTUE

Saludos,

Ariel.

El 29 de septiembre de 2016, 12:26, Andres Cassagnes <andre...@gmail.com> escribió:

[Andres Cassagnes]

Martin, ese fue el único detalle que encontré, al menos yo. Creo que lo más fácil es que lo modifiques vos directamente por ser únicamente una net.

[martin ribelotta]

Fixed it.

Igual me voy a tomar el fin de semana para mirarlo en profundidad y hacer un checklist completo.

Cualquier aporte es mas que vienvenido.

[Andres Cassagnes]

Me parece bien. Yo voy a pegarle otra mirada y voy a pasar al PCB. Cualquier cosa que vea te digo

[martin ribelotta]

@Andres, ahi hice algunos cambios en el PCB/Diseño principalmente para que se pueda usar alimentado desde cualquier lado (como poncho, por power usb o debug usb) a costa de perder los 5v exactos (5v - 0.2v del diodo schottky -lo escribí bien!!!-)

Ahora que lo pienso, ¿Porque tener dos usb, uno para power y otro para debug exclusivo? ¿Les parece si hacemos el power usb un conector distinto? ¿Cual quedaría mejor?

Por otro lado, le estoy poniendo los rótulos y demás cosas y me surgio la idea de si ponerle el logo de la CIAA ya que esto es en realidad un proyecto paralelo surgido de emb32 y no algo oficial de CIAA :-/

No se si queda bueno enarbolar el nombre Proyecto CIAA así como así. @Ridolfi a usted que le parece?

Ahora algo mas técnico, no se si estoy conforme con el desacople del chip. Le puse lo recomendado por Lattice en su hardware checklist, pero he sentido de problemas de ruido en estos FPGA cuando estan con mucho switching adentro (ergo mucho consumo)

¿Cual seria una red de desacople fuerte? LC? RLC? Normalmente cuando tenia dudas le mandaba 100n y 100p a cada pin, luego 10u a cada bloque independiente de power (en este caso, a cada banco) y ademas dividía en sectores de no mas de 100-200mA los bloques con una L de 150-200uH. Atrás ponía normalmente un C también de 10uF pero eso me parece exagerar con este circuito.

No va a 500Mhz, no consume 1...@0.8V, no tiene lineas de transmisión -al menos no criticas- ni esta sometido a deltas violentos de corriente, pero el hecho de hacerlo en doble faz con un plano de masa que alterna entre distintos VCC me hace querer filtrar lo mas posible.

Recuerden que la SDRAM, si bien no exige una impedancia controlada en sus lineas y las distancias me permiten no ecualizar el largo de las pistas (y que con mucha suerte lleguemos a 75Mhz y no a 100 o 133 que se aguante la SDRAM) el plano de masa debe ser lo mas estable posible para permitir estabilidad en las señales (no quiero que me salga radio rivadavia en los datos)

La idea es no encarecer la placa al dope porque es algo super básico y no tiene sentido hacer muchos cálculos de PCB porque las tolerancias en las que se va a fabricar dejan todo eso inutil.

Cualquier aporte es bienvenido ;-) Saludos.

[Ariel Lutenberg]

El 3 de octubre de 2016, 0:03, martin ribelotta <martinr...@gmail.com> escribió:

Por otro lado, le estoy poniendo los rótulos y demás cosas y me surgio la idea de si ponerle el logo de la CIAA ya que esto es en realidad un proyecto paralelo surgido de emb32 y no algo oficial de CIAA :-/

Martin,

Yo no veo ningún problema en ponerle el logo de la CIAA.

Eso sería más o menos similar al caso de la picoCIAA, no?

Yo creo que va a sumar usuarios a esta placa si la pones bajo ese paraguas.

Abrazos,

Ariel.

[Andres Cassagnes]

Va entre líneas.

El 3 de octubre de 2016, 0:03, martin ribelotta <martinr...@gmail.com> escribió:

@Andres, ahi hice algunos cambios en el PCB/Diseño principalmente para que se pueda usar alimentado desde cualquier lado (como poncho, por power usb o debug usb) a costa de perder los 5v exactos (5v - 0.2v del diodo schottky -lo escribí bien!!!-)

Me parece buena idea así no hay necedidad de tener siempre el conector USB de alimentación conectado si ya hay otro cable usb conectado de alguna forma a la placa.

Ahora que lo pienso, ¿Porque tener dos usb, uno para power y otro para debug exclusivo? ¿Les parece si hacemos el power usb un conector distinto? ¿Cual quedaría mejor?

Esto también me parece buena idea. Dejar un solo USB para alimentación y programación (a través LPC11) y poner un conector de alimentación externa. No se me ocurre cual conector quedaría mejor peor se podría poner un header de dos pines como tiene la EDU-CIAA como para poder conectarle fácil un cable desde cualquier fuente de alimentación.

Por otro lado, le estoy poniendo los rótulos y demás cosas y me surgio la idea de si ponerle el logo de la CIAA ya que esto es en realidad un proyecto paralelo surgido de emb32 y no algo oficial de CIAA :-/

No se si queda bueno enarbolar el nombre Proyecto CIAA así como así. @Ridolfi a usted que le parece?

Ahora algo mas técnico, no se si estoy conforme con el desacople del chip. Le puse lo recomendado por Lattice en su hardware checklist, pero he sentido de problemas de ruido en estos FPGA cuando estan con mucho switching adentro (ergo mucho consumo)

¿Cual seria una red de desacople fuerte? LC? RLC? Normalmente cuando tenia dudas le mandaba 100n y 100p a cada pin, luego 10u a cada bloque independiente de power (en este caso, a cada banco) y ademas dividía en sectores de no mas de 100-200mA los bloques con una L de 150-200uH. Atrás ponía normalmente un C también de 10uF pero eso me parece exagerar con este circuito.

No va a 500Mhz, no consume 1...@0.8V, no tiene lineas de transmisión -al menos no criticas- ni esta sometido a deltas violentos de corriente, pero el hecho de hacerlo en doble faz con un plano de masa que alterna entre distintos VCC me hace querer filtrar lo mas posible.

Recuerden que la SDRAM, si bien no exige una impedancia controlada en sus lineas y las distancias me permiten no ecualizar el largo de las pistas (y que con mucha suerte lleguemos a 75Mhz y no a 100 o 133 que se aguante la SDRAM) el plano de masa debe ser lo mas estable posible para permitir estabilidad en las señales (no quiero que me salga radio rivadavia en los datos)

Separar los bloques FPGA-uC-SDRAM con L no me parece exagerado. En cuanto al desacople de la FPGA, se podría poner un LC como para asegurar. Yo también siempre fui mas bien práctico y le metía caps de 100n y 100p como para asegurar. Lo que más me preocupa es el tema del plano de masa, tenemos uno solo compartido por todos los planos de VCC donde encima hay bichos ruidosos como la FPGA. No le escatimaría en filtrado al menos a la memoria.
 

La idea es no encarecer la placa al dope porque es algo super básico y no tiene sentido hacer muchos cálculos de PCB porque las tolerancias en las que se va a fabricar dejan todo eso inutil.

Agregarle unos capacitores no creo que la encarezca demasiado y creo que vale la pena para asegurar que funcione bien.

 

Cualquier aporte es bienvenido ;-) Saludos

Lo que vi revisando los componentes es que la Serial Flash figura discontinuada en varios sitios de venta de compoentes (Digikey por ejemplo) y directamente no la encontré en la página del fabricante.

Todavía tengo pendiente revisar el PCB, cosa que quiero hacer entre hoy y mañana.

Creo que estaría bueno ponerle el logo de la CIAA, más allá de que surgió en esta lista y no dentro del proyecto se podría llegar a incluir como parte del mismo.

Saludos

Andrés C.

[Salvador Tropea]

¡Hola!

Con respecto a este tema les comento que ya tengo funcionando una placa con iCE40 que tiene las siguientes características:

- FPGA: iCE40HX4K-TQ144, también puede usarse una iCE40HX1K-TQ144, para soldarla basta con un soldador que tenga punta fina (y una lupa o videoscopio)

- Memoria de configuración: SPI de 4 Mib, por lo que le sobran casi 3 Mib

- Botones: ninguno físico, tiene 4 CapSense que están funcionando perfectamente.

- LEDs: 4 LEDs de uso general (+ power + DONE)

- Conectores GPIO: (3,3 V)

  * Tiene los conectores de ChipKit, que son los de Arduino UNO, pero con el doble de I/Os. Esto es parecido a lo que tiene la iCE Blink de Lattice.

  * Tiene 2 conectores PMOD de 12 pines (8 I/Os + 2 GND + 2 Vcc)

- Entradas analógicas: 8 canales de 10 bits aprox. 100 ks/s (MCP3008)

- USB: driver USB TUSB1106 (LS/FS), es económico y permite cumplir con la norma USB, que establece tensiones diferenciales desde 200 mV. Sirve para implementar USB devices en la FPGA, ya probé implementando un joystick.

- Alimentación: Se alimenta con 3,3 V, por lo que la placa sólo tiene un LDO de 1,2 V. 

- Reloj: zócalo para colocar un oscilador tipo DIP-8/14. De esta manera no consumimos 1 PLL todo el tiempo, como le pasa a placas como la Blink.

- Puerto de comunicación y configuración: 2 conectores de 20 pines c/u. No tiene ningún micro, ni ningún FTDI que quede "capturado" en la placa.

Esta placa se "alimenta" desde otra, que hace las veces de fuente de alimentación, comunicación y configuración. Las características de la otra placa son:

- FTDI FT2232H

- Memoria de configuración que permite customizarla.

- Regulador de 3,3 V (desde la tensión de USB alimenta al FT2232H y provee los 3,3 V para la placa anterior)

- Level shifters bidireccionales en el 2do canal del FT2232H. Permiten soportar señalizaciones tan bajas como 0,95 V.

Esta placa permite configurar la memoria de la iCE40 y, sin desconectar nada, comunicarse por el otro canal con cualquier core implementado en la iCE40. Por ahora sólo probe RS-232, pero es posible usar los modos FIFOs de alta velocidad.

Esta funcionalidad se encuentra en una placa separada porque al desconectarla nos queda un "cable" que soporta:

- RS-232 (0,9 a 5,5 V, hay un plug-in para -6/6 V que cumple con el nivel físico de la norma RS-232)

- SPI (configuración de la iCE40, debug con AVR, etc.)

- JTAG (configuración de FPGAs de Xilinx, debug con ARM, etc.)

- I2C (aún no verificado)

De esta manera el FT2232H, que es un chip caro si lo comparamos con la iCE40, no queda "pegado" a la placa de FPGA y lo podemos usar para muchos otros usos.

Ambos PCBs son de 2 capas y fueron fabricados nacionalmente por proveedores locales.

Ambas placas pueden soldarse manualmente, no es necesario un horno de reflow o dispositivo similar. Sólo paciencia.

La idea es que se puedan mandar a fabricar, o soldarse artesanalmente.

La segunda placa ya lleva meses de uso en las aplicaciones mencionadas. En mi caso reemplazó a todos los cables de configuración que usaba.

La primera lleva sólo unas semanas de validación. Todo lo que tiene funciona perfectamente. Pero está en proceso de revisión para mejorar detalles menores. Las validaciones realizadas hasta ahora fueron:

- Funcionamiento correcto de los LEDs

- Funcionamiento correcto de los CapSense (y determinación de la frecuencia de muestreo y poleo adecuadas)

- Funcionamiento correcto del A/D, muestrea continuamente a 55 ks/s, probado con un preset y cables "volando", el LSB queda estable (salvo que acerques el dedo a los cables, ya que la resolución son 3,2 mV ;-)

- Funcionamiento correcto de la comunicación RS-232 sobre USB: probado sintetizando un clon del ATtiny22 corriendo a 24 MHz y comunicándose a 115200 8N1.

- Funcionamiento correcto del driver USB: 2 USB devices probados, uno es un joystick estándar y otro un core que permite leer los CapSense y controlar los LEDs.

Un "goal" interesante del proyecto sería lograr que la placa se pueda usar exáctamente igual que un Arduino UNO. Esto parece factible ya que el ATtiny22 que menciono ocupa un 30% del área de la FPGA. Pero implica bastante trabajo de soft. 

Ambas placas serán publicadas como hardware abierto.

La segunda en pocos días, cuando termine una serie de trámites burocráticos. La primera pronto, pero los trámites no empezaron todavía.

Si alguien tiene interés en estos proyectos por favor conteste el mail con copia a salv...@inti.gob.ar porque no leo mucho esta lista.

Saludos, Salvador

P.D. Los que todavía no conocen mucho de la iCE40 pueden visitar: http://fpgalibre.sourceforge.net/ice40.html

El 31 de agosto de 2016, 15:33, Roberto A. Dhios <rad...@gmail.com> escribió:

Excelente proyecto de una FPGA totalmente GPL incluso la síntesis.

https://github.com/FPGAwars/icezum/wiki

Podríamos replicarla acá, que opinan???

---

Roberto A. Dhios
email. rad...@gmail.com
msg.   gtalk,skype: radhios

in.    ar.linkedin.com/in/radhios

linux. https://www.linuxcounter.net/cert/374352.png

[martin ribelotta]

Bueeeeeno, ahi hice los cambios....

El día 3 de octubre de 2016, 14:59, Andres Cassagnes
<andre...@gmail.com> escribió:

> Va entre líneas.
>
> El 3 de octubre de 2016, 0:03, martin ribelotta <martinr...@gmail.com>
> escribió:
>>
>> @Andres, ahi hice algunos cambios en el PCB/Diseño principalmente para que
>> se pueda usar alimentado desde cualquier lado (como poncho, por power usb o
>> debug usb) a costa de perder los 5v exactos (5v - 0.2v del diodo schottky
>> -lo escribí bien!!!-)
>
> Me parece buena idea así no hay necedidad de tener siempre el conector USB
> de alimentación conectado si ya hay otro cable usb conectado de alguna forma
> a la placa.
>>
>>
>> Ahora que lo pienso, ¿Porque tener dos usb, uno para power y otro para
>> debug exclusivo? ¿Les parece si hacemos el power usb un conector distinto?
>> ¿Cual quedaría mejor?
>
> Esto también me parece buena idea. Dejar un solo USB para alimentación y
> programación (a través LPC11) y poner un conector de alimentación externa.
> No se me ocurre cual conector quedaría mejor peor se podría poner un header
> de dos pines como tiene la EDU-CIAA como para poder conectarle fácil un
> cable desde cualquier fuente de alimentación.
>

Cambio hecho, al final elegí un screw convencional (porque tiene diodo
protector):
http://www.digikey.com/product-detail/en/on-shore-technology-inc/OSTVN02A150/ED10561-ND/1588862
Que en digikey estan tremendamente baratos comparados con los precios de aca.

Definitivamente prefiero hacer un prototipo primero, me parece que no
es el momento de hacer overengining.

Seguramente la SDRAM no se pueda usar a mas de 60-70MHz por una
cuestion del FPGA mas que por el impreso.

>>
>>
>> La idea es no encarecer la placa al dope porque es algo super básico y no
>> tiene sentido hacer muchos cálculos de PCB porque las tolerancias en las que
>> se va a fabricar dejan todo eso inutil.
>
>
> Agregarle unos capacitores no creo que la encarezca demasiado y creo que
> vale la pena para asegurar que funcione bien.
>
>>
>>
>> Cualquier aporte es bienvenido ;-) Saludos
>
>
> Lo que vi revisando los componentes es que la Serial Flash figura
> discontinuada en varios sitios de venta de compoentes (Digikey por ejemplo)
> y directamente no la encontré en la página del fabricante.
>

Cambiado, y por una de 16M para que quede espacio de usuario.

> Todavía tengo pendiente revisar el PCB, cosa que quiero hacer entre hoy y
> mañana.
> Creo que estaría bueno ponerle el logo de la CIAA, más allá de que surgió en
> esta lista y no dentro del proyecto se podría llegar a incluir como parte
> del mismo.
>

Logos puestos.

Ahora, si bien no lo he dedicado mucho tiempo, tengo que ponerle a
hacer el BOM para digikey que de por si es un trabajito.

Si alguien se sabe alguna para evitar tener que hacerlo a mano (mas
allá de los scripts como KiCOST que no he logrado hacer andar) le
agradesco la mano.

@Andres: Voy a esperar tu revisión del PCB antes de mandarlo a
fabricar (cosa que va a ocurrir a mediados de mes mas o menos y en
china porque no tengo la plata para costear un prototipo aca -ademas
que me estoy chamullando a la china-)

> Saludos
>
> Andrés C.

>
> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google
> Embebidos32. Para postear en este grupo, escribe un email a
> embeb...@googlegroups.com. Para des-suscribirte, envía un email a

> embebidos32...@googlegroups.com. Para más opciones, visita el sitio

> del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
> Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,

> envía un correo electrónico a embebidos32...@googlegroups.com.

[martin ribelotta]

Tremendo tu laburo Salvador!

Estoy seguro que con esta placa vamos a tener una sinergia muy buena
porque todos los cores hechos en una son portables a la otra.

El día 6 de octubre de 2016, 9:02, Salvador Tropea
<seti...@gmail.com> escribió:

Si te interesa, podemos verlo. No creo que sea mucho mas complicado
que armar un bootloader en rom (lindo si fuera por el USB de la placa)
y agregar la descripción de todo esto en el IDE de arduino (tal vez
con alguna que otra libreria para manejar los perifericos "de mas" que
se le agreguen)

> Ambas placas serán publicadas como hardware abierto.
> La segunda en pocos días, cuando termine una serie de trámites burocráticos.
> La primera pronto, pero los trámites no empezaron todavía.
>
> Si alguien tiene interés en estos proyectos por favor conteste el mail con
> copia a salv...@inti.gob.ar porque no leo mucho esta lista.
>
> Saludos, Salvador
>
> P.D. Los que todavía no conocen mucho de la iCE40 pueden visitar:
> http://fpgalibre.sourceforge.net/ice40.html
>
> El 31 de agosto de 2016, 15:33, Roberto A. Dhios <rad...@gmail.com>
> escribió:
>>
>> Excelente proyecto de una FPGA totalmente GPL incluso la síntesis.
>>
>> https://github.com/FPGAwars/icezum/wiki
>>
>> Podríamos replicarla acá, que opinan???
>>
>>
>> ---
>> Roberto A. Dhios
>> email. rad...@gmail.com
>> msg. gtalk,skype: radhios
>> in. ar.linkedin.com/in/radhios
>> linux. https://www.linuxcounter.net/cert/374352.png
>>
>> --
>> -- Recibiste este mensaje porque estás suscripto al Grupo Google
>> Embebidos32. Para postear en este grupo, escribe un email a
>> embeb...@googlegroups.com. Para des-suscribirte, envía un email a

>> embebidos32...@googlegroups.com. Para más opciones, visita el sitio

>> del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
>> ---
>> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
>> Grupos de Google.
>> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,

>> envía un correo electrónico a embebidos32...@googlegroups.com.

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

> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google
> Embebidos32. Para postear en este grupo, escribe un email a
> embeb...@googlegroups.com. Para des-suscribirte, envía un email a

> embebidos32...@googlegroups.com. Para más opciones, visita el sitio

> del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
> Grupos de Google.
> Para anular la suscripción a este grupo y dejar de recibir sus mensajes,

> envía un correo electrónico a embebidos32...@googlegroups.com.

[Salvador Eduardo Tropea]

:-)

El 10/10/16 a las 23:48, martin ribelotta escribió:

> Tremendo tu laburo Salvador!
>
> Estoy seguro que con esta placa vamos a tener una sinergia muy buena
> porque todos los cores hechos en una son portables a la otra.
>
>

--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Andres Cassagnes]

Buenas.

Martin, ahí bajé los cambios y hoy me pongo a ver el PCB. Me parece buena idea el cambio de la memoria a una de 16M. En cuanto a la velocidad de la SDRAM me parece una buena velocidad para las aplicaciones que se puedan encarar con la placa.

En cuanto a la fabricación, me parece un buen deadline para mandar a fabricar, cualquier cosa por el tema presupuesto lo hablamos y colaboro (suerte con la china ;) ) tanto con la fabricación de PCBs como con la compra de componentes. En cuanto a la BOM podría llegar a ponerme recién la semana que viene.

Cuando termine de revisar el PCB te aviso.

Salvador, me parece muy copado el diseño que hiciste, tengo que sentarme a mirar con detenimiento, pero me parece muy buena la idea de la compatibilidad con arduino (a pesar de todas las cosas que tengo en contra de la plataforma, si me gusta para este tipo de proyectos).

Saludos

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

--- Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Andres Cassagnes]

Estuve revisando el PCB.

Consulta, a las líneas del I2C entre la FPGA y el LPC11 no habría que ponerle unos pull-ups? (es una consulta en serio, no retórica).

No le encontré nada que haya que corregir, gran trabajo lograr esos planos de GND y de power en solo dos capas.

Si me pongo en hinchahuevos por ejemplo la conexión de 3V3 al pin 37 del conector 1 la haría con una via para no tener esa bajada brutal de ancho de pista, pero es de puro hincha nomás. O algunos quiebres raros y conexiones desaliñadas en la pista iCE40-CDONE desde el LPC11 al conector FPGA-SSP, pero nuevamente, no es para nada un error o algo operacional.

Por mi, está para darle para adelante.

Esto me lleva a otra cosa. Tema IDE, plataforma de desarrollo, etc. tenés alguna idea de que usar, hacer algo nuevo, adaptar tu embedded-IDE?

Saludos

[martin ribelotta]

El 13 de octubre de 2016, 10:16, Andres Cassagnes <andre...@gmail.com> escribió:

Estuve revisando el PCB.

Consulta, a las líneas del I2C entre la FPGA y el LPC11 no habría que ponerle unos pull-ups? (es una consulta en serio, no retórica).

Teóricamente correcto y debería ser un valor de 4K7 aunque he visto de 10-12-22K, pero según entiendo, según esta nota:

http://www.latticesemi.com/en/Support/AnswerDatabase/4/3/2/4325.aspx

La FPGA tiene una fuente de corriente que actúa como resistencia interna, y a 3v3 da 10K y moneda.

El problema de ponerle resistencias externas viene por el lado de que la CIAA tiene incorporadas resistencias de 2K2 en las lineas de I2C, lo que de por si, es demasiado bajo para mi gusto, si le agrego mas resistencia, estaría llevando el pull up a valor poco manejables por los estándares i2c,

Por eso pensé en usar los pull up internos del FPGA si no existiera conexión a la EDU-CIAA.

 

No le encontré nada que haya que corregir, gran trabajo lograr esos planos de GND y de power en solo dos capas.

Si me pongo en hinchahuevos por ejemplo la conexión de 3V3 al pin 37 del conector 1 la haría con una via para no tener esa bajada brutal de ancho de pista, pero es de puro hincha nomás. O algunos quiebres raros y conexiones desaliñadas en la pista iCE40-CDONE desde el LPC11 al conector FPGA-SSP, pero nuevamente, no es para nada un error o algo operacional.

Por mi, está para darle para adelante.

Mmmmmm no esta mal revisar esas cositas, el pin 37 de P6 se fácilmente ruteable por otro lado, la pista de CDONE tenia una vía de mas (no jode, pero es desprolijo)

Los quiebres no se me ocurre mucho como evitarlos, salvo que recoloque el conector feo ese en otro lugar. Por ahora lo voy a dejar así, hacer las modificaciones que me planteas (las cuales veo totalmente acertadas) y mandar a cotizar.

 

Esto me lleva a otra cosa. Tema IDE, plataforma de desarrollo, etc. tenés alguna idea de que usar, hacer algo nuevo, adaptar tu embedded-IDE?

Podriiiiamos pensar en hacer un conjunto de Makefiles para el embedded-ide pero me gustaría probar esto:

https://github.com/FPGAwars/apio-ide

Lo que si, es un bardo instalaro, habría que hacer un bundle con todo (Atom/APIO/APIO-IDE) de forma de poder trabajar con esto fácilmente.

[Andres Cassagnes]

Joya. Lo de las resistencias pull-up del I2C en la EDU-CIAA lo pensé después de enviar el mail, me parece la mejor decisión no poner en esta placa.

En cuanto a las otras cosas, eran solo observaciones de hincha que soy nomás, pero son cosas completametne justificadas ya que por algún lado las pistas tienen que pasar.

Voy a mirar el apio-ide a ver que onda.

Saludos

[martin ribelotta]

Debería abrir otro hilo para esto, pero me da fiaca.

Tengo en mi poder las placas hechas por los compadres de OurPCB en chinalandia.

La cotización por cinco PCBs doble faz, fue algo así:

Esto lo encargue un viernes y en cinco días hábiles estaba fabricado y enviándose por FedEx (el costo de 48 USD extra, sino todo salia 87 USD)

En tres días estuvo en Bs.As. y fue sacado de Aduana por FedEx sin pedirme datos de AFIP ni nada (vale aclarar que ya he hecho transacciones con ellos y tienen mi CUIL y Nro fiscal, estoy registrado en AFIP con clave fiscal nivel 3)

Hace 20min. llego el representante de FedEx en bariloche y me cobro 561 pesos de cargos de importación, luego voy a sacar la cuenta de que es que. Matemáticamente representa el 27-28% del valor total (incluido flete) o el 43% del valor sin flete (posiblemente eso ultimo sea lo correcto)

En estos días estoy confeccionando la lista de materiales para comprar en Digikey (me llevo mas tiempo del pensado porque estoy feteando mi tiempo libre entre esto y el preparar las charlas de micropython para la PyConAR de bahía a fin de mes)

Acá unas fotos:

PD: Hace unos 10-15 días, Ernesto Mayer hizo una promoción con costos similares a esto, pero yo ya habia mandado a producir en china y pagado todo. Al menos en doble faz, argentina no esta tan lejos del mundo.

Saludos.

[Andres Cassagnes]

Uh, que buenas se ven las placas.

Disculpá que no colaboré con las BOM, la verdad que hasta fin de año estoy con un par de cosas que me están ocupando todo el tiempo y energía.

Después me gustaría charlar bien cuanto te costaron, una vez que estén ensambladas o cuando queiras, porqueme gustaría hacerme con alguna para empezar a laburar cuando empecemos a hacer cosas con ellas.

Asi que estás en Barilo? No sabía, eso puede simplificar algunas cosas, to estoy acá también.

Tremendo laburo estás haciendo.

Saludos

Andrés

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

[martin ribelotta]

Voy a dejar esto por acá y me alejare lentamente...

PD: Espero en unos días tenerlo una o dos placas armadas... y si andan, hay que ver a cuantos les interesa una en su casa y como fabricarlas... :-D