¿Es viable un FPGA para un proyecto de este tipo?

En principio, este es un buen candidato para el diseño basado en FPGA. En cuanto a sus requisitos:

anuncio 1. Lo más probable es que el FPGA sea más caro, según la cantidad que dependa del dispositivo que elija. A primera vista, el Spartan 3 más pequeño de Xilinx (XC3S50AN) será más que suficiente para esta tarea (~ 10 £ de Farnell). Creo que puede asumir que este es el límite superior del costo (tiene 56 kB de RAM en su interior, por lo que es más de lo que necesita). Puede encontrar un dispositivo más barato ya sea de la oferta de Xilinx o de sus competidores Altera y Lattice.

anuncio 2. El paquete es el problema difícil, tampoco vi FPGA con una huella más pequeña. Sin embargo, tal vez pueda usar un dispositivo CPLD (por razones de argumento, los CPLD son FPGA pequeños) que pueden estar en un paquete más pequeño (PLCC o QFN). En el lado positivo, serán más baratos (incluso los $ solos) en el lado negativo, lo más probable es que no tengan RAM en su interior. Con CPLD probablemente necesitarías un chip SRAM externo.

ad 3. El consumo de corriente de FPGA y CPLD depende en gran medida del diseño programado. Sin embargo, hay muchas posibilidades de que el diseño de FPGA y especialmente el de CPLD consuman menos que su solución actual.

ad 4. FPGA tiene ese tipo de memoria dentro, CPLD ciertamente no. Esto se puede resolver con un chip sram externo (o dos). Por ejemplo:

| SRAM 1 | < - > | CPLD | < - > | uC |
| SRAM 2 | < - >

En dicha disposición, mientras la unidad de control de contenido escribe en la SRAM 1, la CPLD mostrará los datos de la SRAM 2. La CPLD debería poder manejar ambas tareas simultáneamente.

Por supuesto que también puedes resolver esto de otras maneras:
1) usar uController más rápido (ARM por ejemplo)
2) use un dispositivo con algún tejido programable y uC en el interior (por ejemplo, FPSLIC de Atmel, sin embargo, nunca he usado tales dispositivos y sé muy poco acerca de ellos)

Descargo de responsabilidad estándar - > como los diseños son problemas abiertos, con muchas limitaciones y posibles soluciones, lo que escribí anteriormente puede no ser cierto para su caso. Sin embargo, creo que vale la pena marcar esas opciones.

Podría usar un CPLD en lugar de un FPGA, como una de las partes de Altera MAX II. Están disponibles en paquetes QFP44, a diferencia de los FPGA. En realidad, son pequeños FPGA, pero Altera minimiza ese aspecto. Los CPLD tienen una ventaja sobre la mayoría de los FPGA, ya que tienen una memoria de configuración en el chip, los FPGA generalmente requieren un chip flash externo. Por supuesto, hay otros CPLD, pero me gusta el MAX II.

Es imposible decir cuál será el consumo actual, ya que depende de las velocidades del reloj y de la cantidad de lógica que realmente se esté usando.

Los FPGA generalmente tienen una cantidad limitada de memoria en chip que puede utilizar, pero necesitará una memoria externa con un CPLD.

Otra opción sería un chip XMOS , pero el más pequeño (el XS1-L1) está en un paquete QFP64. Tiene un montón de RAM en chip - 64k.

1) Sí, el FPGA será más caro. No solo el chip es más caro, sino que también necesitará memoria Flash para almacenar la programación. Es probable que FPGA + Flash sea 3 veces el costo de solo el dsPIC ... aproximadamente $ 10 por un FPGA pequeño y $ 3 por Flash pequeño.

2) Pueden existir, pero no estoy realmente al tanto de ningún FPGA que no esté montado en superficie. La mayoría de ellos son probablemente QFP o BGA.

3) Es probable que el FPGA extraiga aproximadamente 3 veces la corriente que hace el dsPIC, pero eso puede aumentar o disminuir según las funciones que use. Los FPGA tienen muchas características que pueden aumentar el consumo de energía. Pero espera al menos 150 mA.

4) Los FPGA generalmente tienen RAM de bloque dentro de ellos. Todos menos los FPGA más pequeños deberían tener tanta memoria.

Otros mencionan CPLDs. Si particiona cuidadosamente su diseño, probablemente podría mover algunas operaciones pequeñas pero costosas al CPLD. Sería como un mini coprocesador.

La solución más barata con la curva de aprendizaje más baja sería pasar a un procesador con mayor potencia, lo más probable es que ARM.

Programar un FPGA / CPLD en VHDL / Verilog es una curva de aprendizaje bastante pronunciada que viene de C para muchas personas. Tampoco son piezas demasiado baratas.

¿Usar un ARM con capacidad decente tal vez un LPC1769? (Cortex-M3) es probable que también puedas reemplazar el PIC18 en tu diseño.

En cuanto a la cuestión del agujero pasante, siempre que pueda obtener el SoC en un paquete tipo QFP de pin expuesto, simplemente tome algunos de estos adaptadores para el pin out necesario para su creación de prototipos.

Mi inclinación sería usar algo para amortiguar el tiempo entre el procesador y la pantalla. Tener hardware que pueda mostrar un cuadro completo de video sin la intervención del procesador puede ser bueno, pero quizás exagerar. Yo sugeriría que el mejor compromiso entre la complejidad del hardware y el software sería probablemente hacer algo con dos o tres registros de desplazamiento de 1024 bits independientes (dos bits por píxel, para permitir negro, blanco, gris o transparente) y un medio de cambiar entre ellos. Haga que el PIC cargue un registro de desplazamiento y, a continuación, haga que el hardware comience a cambiarlo mientras establece un indicador para que el PIC pueda cargar el siguiente. Con dos registros de desplazamiento, el PIC habría tenido 64 usd entre el momento en que se informa que un registro de desplazamiento está disponible y el momento en que todos los datos deben cambiarse. Con tres registros de turnos, el PIC tendría que promediar una línea cada 64us, pero podría tolerar un retraso de hasta 64us.

Tenga en cuenta que si bien una FIFO de 1024 bits sería tan buena como dos registros de desplazamiento de 1024 bits, y en una CPLD una FIFO solo cuesta una macrocélula por bit, más alguna lógica de control, en la mayoría de los otros tipos de lógica de dos bits El registro de turnos será más barato que un bit de FIFO.

Un enfoque alternativo sería conectar un CPLD a una SRAM y hacer un subsistema de video simple con eso. Estéticamente, me gusta la generación de videos sobre la marcha, y si alguien hiciera buenos chips de registro de desplazamiento de 1024 bits, ese es el enfoque que preferiría, pero usar una SRAM externa puede ser más económico que usar un FPGA con suficientes recursos para Hacer múltiples registros de desplazamiento de 1024 bits. Para la resolución de salida, será necesario sincronizar los datos a 12M píxeles / seg, o 3 MBytes / seg. Debería ser posible organizar cosas para permitir que los datos se registren a una velocidad de hasta 10 Mbps sin demasiada dificultad al intercalar los ciclos de memoria; el mayor truco sería prevenir la corrupción de datos si un pulso de sincronización no se produce en el momento preciso esperado.