Temporización de entrada de MT9M001 a FPGA

MT9M001 es un sensor de imagen CMOS. Como salida proporciona FRAME_VALID, LINE_VALID y DATA. Las señales de salida se sincronizan (alineadas con los bordes) mediante PIXCLK, que genera el sensor. La hoja de datos está, por ejemplo, en http://www.onsemi.com/pub_link/Collateral/MT9M001-D.PDF

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 borde descendente, lo que significa en la marca 10.416. Este es un diagrama de datahseet:

Diagrama de tiempo de salida de datos

Para configurar restricciones de tiempo válidas, tengo que concentrarme en t_PLH y t_PLL. Veamos cómo se definen (valores mínimo, típico, máximo):

ingrese la descripción de la imagen aquí

De acuerdo con estos datos, LINE_VALID va de menor a mayor hasta 7 ns después del flanco ascendente de PIXCLK, que es al menos 3,4 ns antes del flanco descendente (a 48 MHz). 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 mayor a menor a más tardar 13 ns después del flanco ascendente de PIXCLK. Pero el flanco descendente de PIXCLK ocurre 10,4 ns después del flanco ascendente de PIXCLK, por lo que el flanco descendente de LINE_VALID llega más tarde que el flanco descendente de PIXCLK. Pero solo a veces, porque no hay un valor típico o mínimo. Además, si t_LVS es 2 ns, t_PLL tendría que ser menor o igual a 8 ns.

¿Cómo manejar esto? Para mí, es un problema real, ya que a veces se desordenan las longitudes de mis líneas (especialmente cuando sobreilumino la cámara).

Según 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?

Respuestas (1)

El medio período 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 período medio debe ser inferior a 9,374 ns (20,833*0,45). Si también consideramos el tiempo de subida/bajada del reloj, 9 ns para min(t_LVS)+max(t_PLH)tiene sentido.

En caso de que LINE_VALID sea capturado por un flip-flop activado por negedge, el cuello de botella es min(t_LVS). Se puede restringir como se indica a continuación. 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 sube PIXCLK.

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 las líneas se arruinen. No sabemos min(t_PLL), por lo que LINE_VALID tiene la posibilidad de caer cerca del borde negativo de PIXCLK y puede volverse metaestable. Este problema debe manejarse funcionalmente.

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

Temporización de entrada de MT9M001 a FPGA
RespuestasAquíPolítica de privacidad1y, 0v