MT9M001 a la sincronización de entrada FPGA

Navega tus respuestas
3

MT9M001 es un sensor de imagen CMOS. Como resultado, proporciona FRAME_VALID, LINE_VALID y DATA. Las señales de salida están sincronizadas (alineadas por el borde) por PIXCLK, que es generada por el sensor. La hoja de datos está, por ejemplo, en enlace

Leí la salida de senosr usando FPGA, de alguna manera funciona, pero me cuesta entender el tiempo de LINE_VALID. Dado que esta es la señal más crítica para la forma de la imagen, ya no puedo ignorar estos problemas.

La hoja de datos afirma que la frecuencia máxima de la cámara es de 48MHz. Esta es la frecuencia que uso, el período es 20.833. Se supone que debo leer en el flanco descendente, lo que significa en la marca 10.416. Este es un diagrama de datahseet:

Paraconfigurarrestriccionesdetiempoválidas,tengoqueconcentrarmeent_PLHyt_PLL.Veamoscómosedefinen(valoresmínimos,típicos,máximos):

De acuerdo con estos datos, LINE_VALID va de bajo a alto después de 7 ns después del flanco ascendente de PIXCLK, que es al menos 3.4 ns antes de caer (a 48MHz). Esto significa que el valor mínimo de t_LVS debe ser 3.4 ns, no 2 ns ...?

Pero no importa, veamos t_PLL. El valor máximo es 13 ns, lo que significa que LINE_VALID va de alto a bajo no más tarde de 13 ns después del borde ascendente de PIXCLK. Pero el borde descendente de PIXCLK ocurre 10.4 ns después del borde ascendente de PIXCLK, por lo que el borde descendente de LINE_VALID llega más tarde que el borde descendente de PIXCLK. Pero solo a veces, porque no hay valor típico o mínimo. Además, si t_LVS es 2 ns, t_PLL tendría que ser inferior o igual a 8 ns.

¿Cómo manejar esto? Para mí es un problema real, ya que la longitud de mi línea se desordena a veces (especialmente cuando me ilumino demasiado la cámara).

Basado en t_OS y t_OH, mis restricciones de señal de datos son: 

create_clock -period 20.833 -name cam_pixclk [get_ports CAM_PIXCLK]
create_clock -period 20.833 -name cam_pixclk_virt

set_input_delay -min -1 -clock cam_pixclk_virt [get_ports CAM_DATA*]
set_input_delay -max  1 -clock cam_pixclk_virt [get_ports CAM_DATA*]

derive_pll_clocks
derive_clock_uncertainty

¿Pero cómo continuar con LINE_VALID?

    
pregunta Adam Trhon

1 respuesta

1

El período medio no es 10.416 ns en el peor de los casos. Dado que el ciclo de trabajo mínimo del reloj es del 45%, el semestre debe ser inferior a 9.374 ns (20.833 * 0.45). Si consideramos el tiempo de subida / bajada del reloj, 9 ns para min(t_LVS)+max(t_PLH) tiene sentido.

En el caso de que LINE_VALID sea capturado por un flip-flop desencadenado por negedge, el cuello de botella es mínimo (t_LVS). Puede ser limitado como abajo. LINE_VALID sube 2 ns antes de que PIXCLK caiga. 

set_input_delay -max -2 -clock cam_pixclk_virt -clock_fall \
    -rise [get_ports LINE_VALID]

Además, LINE_VALID cae 13 ns (t_PLL) después de que PIXCLK aumenta. 

set_input_delay -max 13 -clock cam_pixclk_virt \
    -fall [get_ports LINE_VALID]

En realidad, estas restricciones no evitarán que las longitudes de línea se desordenen. No sabemos min (t_PLL), por lo que LINE_VALID tiene la posibilidad de caer cerca del borde negativo de PIXCLK y puede ser metaestable. Este problema debe ser manejado funcionalmente.

Una solución sería usar posedge de PIXCLK en lugar de negedge. Si los DATOS están lo suficientemente restringidos para un mínimo retraso de entrada (es -1 en tus restricciones), todas las señales serán seguras de capturar en la posición.

    
respondido por el ahmedus

Lea otras preguntas en las etiquetas

¿Cómo usar correctamente un balun? ¿Puede un campo magnético variable en el tiempo pasar una lámina de metal?