Para una aplicación de conmutación, quiero sincronizar dos señales HDMI. ¿Hay alguna forma de negociar las señales de reloj entre una fuente HDMI y un receptor o dos fuentes (preferiblemente sin desmontar dispositivos e introducir mi CLK)?
¿También es posible que los relojes internos para el procesamiento (no los relojes HDMI) puedan diferir en las fuentes, por lo que un forzamiento global de un CLK global puede no ser una posibilidad?
HDMI es un enlace punto a punto en lo que se refiere a los datos de video, ya que lo único que normalmente se remonta al otro lado es EDID y algunas cosas que tienen que ver con HDCP. En general, lo más cercano a la negociación del reloj es la información de EDID, pero eso no hará lo que necesita.
El enfoque habitual para esto es un FPGA con suficiente IO para manejar el video. El FPGA también necesitará algo de SDRAM para un búfer de cuadros y generalmente uno de los generadores de reloj de SiLabs (típicamente) para obtener las tasas de línea apropiadas para los diversos modos.
Esto es suficiente para una conmutación limpia y una escala uniforme, pero para evitar la pérdida de cuadros si se realiza la mezcla, se necesita sincronización interna para garantizar que la velocidad de cuadros de las dos fuentes esté bloqueada.
El ADV7511 y sus amigos son la manera fácil de generar la salida HDMI, ya que todo lo que algunos FPGA pueden hacer TMDS como un estándar de IO, los pines IO de propósito general por lo general alcanzan los 1,2 Gb / s, por lo que uno de los los chips codificadores de propósito todavía son la forma de jugar, especialmente si quieres HDMI 2.0.
Los dispositivos analógicos también hacen conjuntos de chips HDMI RX que le brindarán un bus paralelo a velocidades razonables desde un puerto HDMI que probablemente sean rentables, ya que eliminan la necesidad de serdes de alta velocidad en el FPGA.
Prepárate para NDA graves y aranceles de licencia si quieres jugar con las cosas HDCP.