¿Cómo crear un clon Ambilight basado en FPGA?

Algunos antecedentes rápidos:
Ambilight es un sistema en algunos televisores Philips que analiza la información de color en la pantalla y luego configura algunos LED en la parte posterior de la pantalla para proyectar el color de la pantalla en la pared. Es un efecto bastante ingenioso. Ahora hay clones de este sistema que usan una PC para procesar el video y controlar los LED. Encuentro que esto es un poco exagerado: usar una máquina completa para bailar algunos LED ...

Me gustaría modificar el NeTV de bunnie para procesar un encriptadoEl video HDMI alimenta y maneja algunos LED. Sé que el NeTV ha sido diseñado para otros fines, pero creo que se puede modificar para lograr mi objetivo. No me importa el subsistema Linux subyacente, la suplantación de identidad I2C, la superposición de video, etc. En este momento, no me preocupa trabajar con transmisiones cifradas HDCP.

Esquemas de NeTV

Código fuente NeTV

Diagrama de bloques de FPGA
Este es un diagrama de bloques de una de las diapositivas de presentación de bunnie.
El resto del conjunto de diapositivas está aquí .

Esta diapositiva parece implicar que los píxeles de video están, de hecho, decodificados (no necesariamente descifrados ) .

Finalmente ... algunos de mis pensamientos y preguntas:

1. ¿Se puede hacer esto en mi hardware deseado? Si "sí", ¡continúa! Si "no", ¡dime qué más necesito!

2. ¿Podré procesar información de video sin memoria externa? No hay memoria a la que el FPGA pueda acceder directamente, por lo que puedo decir. Esto probablemente depende de qué algoritmo use para procesar los datos de video: para usar la menor cantidad de RAM de bloque FPGA posible, supongo que me gustaría usar algún tipo de 'suma iterativa' de los píxeles que entran, en lugar de almacenar un todo marco de datos de imagen y luego promediando los colores. ¿Alguna pista con respecto a la implementación de este algoritmo? Cómo comenzar con esto es mi mayor obstáculo.

3. He investigado el código fuente en cuanto a dónde debo 'aprovechar' los datos del video.
   Este parece ser el lugar apropiado:
   
   lo sé, esta imagen es larga, es lo mejor que puedo hacer al mismo tiempo que la hago clara para leer. ¡Culpa a la herramienta de Xilinx por eso!
   Esto parece incluir los datos TMDS y la salida de 8 bits para cada color.

4. Debería tener algún tipo de máquina de estado para el controlador LED: en cada ciclo de reloj, obtiene la información de píxeles de cualquier módulo que cree para procesar los datos de video.

Lo siento si esto es extenso o largo, estoy tratando de ser minucioso ... Solo necesito ayuda para despegar con esto. Este es mi primer intento en un proyecto de FPGA, algunos pueden decir que es demasiado difícil para un principiante, pero yo digo ... tengo que comenzar en alguna parte :) Gracias por leer.

Estoy basando mi respuesta completamente en el código y la documentación del módulo dvi_decoder , y suponiendo que realmente funcione como se anuncia. Este archivo parece ser una copia (¿modificada?) De la IP en las notas de la aplicación Conectividad de video usando E / S TMDS en FPGA Spartan-3A y / o implementando una interfaz de video TMDS en el FPGA Spartan-6 . Estas notas de la aplicación están repletas de detalles importantes, y le sugiero que las lea detenidamente.

Como indicó en la pregunta, supondré que está tratando secuencias no cifradas, es decir, secuencias no HDCP. Estoy bastante seguro de que la información en el proyecto NeTV se puede adaptar para descifrar HDCP, pero implicaría una cantidad no trivial de trabajo adicional y estaría sobre bases legales cuestionables dependiendo de su jurisdicción.

Parece que podrá obtener los datos que necesita de las salidas del bloque dvi_decoder. El bloque de información de salidas de 24-bit de color usando los cables red, greeny blue, sincronizarse con el reloj de píxeles pclk. Las salidas hsyncy vsyncalertan al usuario sobre el final de una línea / pantalla respectivamente. En general, debe poder hacer promedios sobre la marcha utilizando estas salidas.

Se necesita algo de lógica básica de traducir hsync, vsyncy la frecuencia de píxel en una posición (X, Y). Solo crea una instancia de dos contadores, uno para Xy otro para Y. Incremento Xen cada reloj de píxeles. Restablecer Xa cero en hsync. Incremento Yen cada hsync. Restablecer Ya cero en cada vsync.

El uso de red, green, blue, Xy Y, se puede hacer sobre la marcha de promedio. Al comparar con Xy Y, puede determinar a qué cuadro debe contribuir cada píxel individual, si corresponde. Suma los valores de color en un registro de acumulación. Para obtener el valor promedio, debe dividir el valor en el registro por la cantidad de píxeles. Si es inteligente, se asegurará de que el número de píxeles sea una potencia de dos. Luego, puede simplemente conectar los MSB del registro a lo que desee manejar.

Debido a que queremos manejar pantallas mientras hacemos la acumulación, necesitaremos hacer doble búfer. Por lo tanto, necesitaremos dos registros por caja por componente. Si está utilizando una cadena de 25 leds, esto significa que necesitará 25 * 3 * 2 = 150 registros. Eso es bastante, por lo que es posible que desee usar block ram en lugar de registros. Todo depende de tus requisitos exactos, ¡experimenta!

Supongo que conducirá una cadena de led como la utilizada en el kit de proyecto adafruit original . Debería poder descubrir cómo manejarlo desde los valores en los registros con bastante facilidad utilizando SPI.

El módulo dvi_decoder es un kit bastante complejo. Le sugiero que estudie las notas de la aplicación en detalle.

Además, si aún no ha comprado un NeTV para usar en este proyecto, le recomiendo que también eche un vistazo al tablero Atlys de Digilent . Con dos entradas HDMI y dos salidas HDMI, parece estar hecho a medida para proyectos de este tipo.