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 a 80 MHz, operaciones de ciclo único 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 prueba para crear un prototipo). Realmente estoy obteniendo hasta el último bit de rendimiento al ejecutar el OSD: el chip tiene alrededor de 200 ns 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 estará escrito en asamblea.)
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 ejecutando el OSD. Una MCU manejaría cosas como dibujar líneas y código algorítmico, pero la salida real se haría con una 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:
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, dependiendo de cuánto depende 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 56kB de RAM en su 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 el bien del argumento, los CPLD son pequeños FPGA) que pueden estar en un paquete más pequeño (PLCC o QFN). En el lado positivo, serán más baratos (incluso solo $) en el lado negativo, lo más probable es que no tengan RAM adentro. Con CPLD probablemente necesite un chip SRAM externo.
ad 3. El consumo de corriente de los FPGA y CPLD depende en gran medida del diseño programado. Sin embargo, existe una buena posibilidad de que el diseño de FPGA y especialmente de CPLD consuma menos que su solución actual.
anuncio 4. FPGA tiene ese tipo de memoria interna, CPLD ciertamente no. Esto puede resolverse con un chip sram externo (o dos). Por ejemplo:
|SRAM 1| <--> |CPLD| <--> |uC|
|SRAM2| <-->
En tal arreglo, mientras el uC está escribiendo en SRAM 1, el CPLD mostrará datos de SRAM 2. El CPLD debería poder manejar ambas tareas simultáneamente.
Por supuesto, también puede resolver esto de otras maneras:
1) use un uController más rápido (ARM, por ejemplo)
2) use un dispositivo con algún tejido programable y uC dentro (por ejemplo, FPSLIC de Atmel, sin embargo, nunca he usado tales dispositivos y sé muy poco sobre eso)
Descargo de responsabilidad estándar -> ya que los diseños son problemas abiertos, con muchas restricciones y posibles soluciones, lo que escribí anteriormente puede no ser cierto para su caso. Sin embargo, creo que vale la pena revisar 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 en que tienen memoria de configuración en el 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 se esté usando.
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 un montón de RAM en el chip - 64k.
1) Sí, el FPGA será más caro. No solo el chip en sí es más caro, sino que también necesitará una memoria Flash para almacenar la programación. FPGA + Flash es probablemente 3 veces el costo de solo el dsPIC... alrededor de $10 por un FPGA pequeño y $3 por un Flash pequeño.
2) Es posible que existan, pero no conozco ningún FPGA que no sea de montaje superficial. La mayoría de ellos son probablemente QFP o BGA.
3) El FPGA probablemente consumirá alrededor de 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 espere al menos 150 mA.
4) Los FPGA generalmente tienen un bloque de RAM en su interior. Todos, excepto los FPGA más pequeños, deberían tener esa cantidad de 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 cambiar a un procesador de mayor potencia, probablemente ARM.
Programar un FPGA/CPLD en VHDL/Verilog es una curva de aprendizaje bastante empinada proveniente de C para muchas personas. Tampoco son piezas demasiado baratas.
¿Usando un ARM decentemente capaz, tal vez un LPC1769? (cortex-M3) probablemente también podrá 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 con pines expuestos, solo 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 excesivo. 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 cambiar ese registro 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 dice que hay un registro de desplazamiento disponible y el momento en que se deben desplazar todos los datos. Con tres registros de desplazamiento,
Tenga en cuenta que mientras que un FIFO de 1024 bits sería tan bueno como dos registros de desplazamiento de 1024 bits, y en un CPLD, un 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 hacer 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 baratos, es el enfoque que preferiría, pero usar una SRAM externa puede ser más barato que usar una FPGA con suficientes recursos para hacer múltiples registros de desplazamiento de 1024 bits. Para su resolución de salida, será necesario registrar 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 un pulso de sincronización no llega en el momento preciso esperado.
leon heller
Marca