¿Es viable un FPGA para tal proyecto?

Actualmente estoy trabajando en Super OSD, un proyecto de visualización en pantalla. http://code.google.com/p/super-osd tiene todos los detalles.

En este momento estoy usando una MCU dsPIC para hacer el trabajo. Este es un DSP muy potente (40 MIPS @ 80 MHz, operaciones de un solo ciclo de tres registros y una unidad MAC) y, lo que es más importante, viene en un paquete DIP (porque estoy usando una placa de pruebas para crear un prototipo). Realmente estoy obteniendo hasta el último rendimiento ejecutando el OSD: el chip tiene aproximadamente 200ns o 10 ciclos por píxel en la etapa de salida, por lo que el código debe estar muy optimizado en esta parte (por esta razón, siempre se escribirá en montaje.)

Ahora estaba considerando usar un FPGA para esto porque debido a la arquitectura paralela de dicho chip, es posible tener un programa lógico simple que ejecute el OSD. Cosas como dibujar líneas y código algorítmico serían manejados por un MCU, pero la salida real se haría con un FPGA. Y algunas cosas simples como configurar píxeles o dibujar líneas horizontales y verticales que me gustaría integrar en el FPGA, para mejorar la velocidad.

Tengo algunas preguntas:

1. ¿Costará mucho más? Los FPGA más baratos que encontré fueron de ~ £ 5 cada uno y el dsPIC es de £ 3 cada uno. Entonces costará más, pero ¿por cuánto?
2. El dsPIC cabe en un paquete SO28. No me gustaría ir más grande que SO28 o TQFP44. La mayoría de los FPGA que he visto vienen en paquetes BGA o TQFP> 100, que no son una opción en este momento, debido al tamaño de corte y la dificultad de soldarlos yo mismo.
3. ¿Cuánta corriente utiliza un FPGA? La solución dsPIC actualmente consume aproximadamente 55 mA +/- 10 mA, lo cual está bien en este momento. ¿Un FPGA consumiría más o menos? ¿Es variable, o es bastante estático, como el dsPIC?
4. Necesito al menos 12 KB de memoria gráfica para almacenar los gráficos OSD. ¿Los FPGA tienen este tipo de memoria disponible en el chip o solo está disponible con chips externos?

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

anuncio 1. Lo más probable es que el FPGA sea más costoso, según cuánto 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 suponer que este es el límite superior para el costo (tiene 56kB de RAM en el interior, por lo que es más de lo que necesita). Puede encontrar un dispositivo más barato en la oferta de Xilinx o en sus competidores Altera y Lattice.

anuncio 2. El paquete es el tema 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 pequeños FPGA) que pueden estar en paquetes más pequeños (PLCC o QFN). En el lado positivo, serán más baratos (incluso $ individuales) en el lado negativo, lo más probable es que no tengan RAM en el interior. Con CPLD probablemente necesitaría 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 FPGA y especialmente el diseño de CPLD consuman menos que su solución actual.

ad 4. FPGA tiene ese tipo de memoria adentro, CPLD ciertamente no. Esto puede resolverse mediante un chip sram externo (o dos). Por ejemplo:

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

En tal disposición, mientras el uC escribe en la SRAM 1, el CPLD mostrará los datos de la SRAM 2. El CPLD debería poder manejar ambas tareas simultáneamente.

Por supuesto, también puede resolver esto de otras maneras:
1) use uController más rápido (ARM, por ejemplo)
2) use un dispositivo con algún tejido programable y uC adentro (por ejemplo, FPSLIC de Atmel, sin embargo, nunca he usado tales dispositivos y sé muy bien poco sobre eso)

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

Puede 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 en que tienen memoria de configuración en chip, los FPGA generalmente requieren un chip flash externo. Hay otros CPLD, por supuesto, pero me gusta el MAX II.

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

Los FPGA generalmente tienen una cantidad limitada de memoria en el chip que puede usar, 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 mucha RAM en chip: 64k.

1) Sí, el FPGA será más caro. El chip no solo es más costoso, sino que también necesitará memoria Flash para almacenar la programación. FPGA + Flash es probablemente el triple del costo de dsPIC ... alrededor de $ 10 por un pequeño FPGA y $ 3 por un pequeño Flash.

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

3) El FPGA probablemente extraerá aproximadamente 3 veces la corriente que hace el dsPIC, pero eso puede subir o bajar dependiendo de las características que use. Los FPGA tienen muchas características que pueden aumentar el consumo de energía. Pero espere al menos 150 mA.

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

Otros mencionan los CPLD. Si divide 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 de mayor potencia, ARM muy probablemente.

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

¿Usando un BRAZO decentemente capaz tal vez un LPC1769? (cortex-M3) también es probable que pueda reemplazar el PIC18 en su diseño.

En cuanto al problema del orificio pasante, siempre que pueda obtener el SoC en un paquete de tipo QFP de pin expuesto, simplemente tome algunos de estos adaptadores para el pin 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 fotograma completo de video sin la intervención del procesador puede ser bueno, pero quizás exagerado. Sugeriría que el mejor compromiso entre la complejidad del hardware y el software probablemente sería hacer algo con dos o tres registros de desplazamiento independientes de 1024 bits (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 luego haga que el hardware comience a desplazarlo mientras establece una bandera para que el PIC pueda cargar el siguiente. Con dos registros de desplazamiento, el PIC tendría 64us entre el momento en que se le informa que un registro de desplazamiento está disponible y el momento en que todos los datos tienen que ser desplazados. Con tres registros de desplazamiento,

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 un CPLD, una FIFO solo cuesta una macrocelda por bit, más algo de lógica de control, en la mayoría de los otros tipos de lógica, dos bits de registro de desplazamiento será más barato que un bit de FIFO.

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