¿Puede un Spartan-3A/AN/E implementar detección de bordes para una cámara de 5MP?

Estoy pensando en adquirir un kit de inicio de FPGA, busqué en el sitio web de Xilinx y descubrí que la serie Spartan 3 era bastante económica: Spartan3AN, Spartan3A y Spartan3E. La Spartan 3AN parece ser una placa nueva.

¿Puede el Spartan FPGA manejar el procesamiento de una cámara de 5 megapíxeles, la interfaz sería de datos paralelos de 8 bits en rgb sin formato y realizar una detección de bordes 15 veces por segundo?

Podría tomar algo de trabajo, pero sí, debería funcionar.
@Kellenjb: ¿No tiene suficientes puertas para construir el algoritmo? ¿Cuál es el problema real para que funcione en un Spartan?
@Kevin Boyd: eso depende de su algoritmo.
Básicamente, esta pregunta es imposible de responder. Se necesitan MUCHO más detalles. Básicamente, no será posible proporcionar una respuesta concluyente hasta que haya escrito el algoritmo de detección de bordes. Esa es la única forma de determinar cuántos elementos lógicos necesita para su diseño y, por lo tanto, qué tamaño de FPGA necesita.
Es posible hacer una estimación aproximada, pero para eso, necesitaríamos saber más sobre lo que está haciendo. Hay muchos algoritmos de detección de bordes (canny, sobel, etc...). Además, los aspectos ambientales entran en consideración. ¿Cuánto preprocesamiento se necesita? ¿Tiene el control completo de la iluminación, o está atascado con la iluminación ambiental? ¿Qué tan bueno es tu programador? Puede optimizar la basura de su diseño y VHDL/Verilog, pero se necesita a alguien con cierta habilidad para hacerlo.
Además, ¿realmente necesitas los 5 mpix? En muchas aplicaciones industriales de CV, el procesamiento real se realiza en imágenes muy reducidas (imágenes de ~200x200 px), porque simplemente no es necesaria más precisión. Ahora, ¿cuánta precisión necesitas? Además, los datos de la imagen se aplanarán al menos a escala de grises y probablemente en blanco y negro puro (quizás con un umbral adaptable) antes del procesamiento. Por lo tanto, ¿está haciendo algo inteligente con el color, que requiere una cámara RGB, o funcionaría una cámara en escala de grises, tal vez con un filtro de color en la lente?
en.wikipedia.org/wiki/Edge_detection es un buen lugar para comenzar a comprender cómo funciona esto
@Kevin, deberías dar tu opinión sobre lo que mencionó Fake Name. No creo que obtengas una buena respuesta sin abordar sus puntos. Debido a que no había abordado sus puntos, es por eso que comenté tan vagamente.
@Fake Name: En este momento necesito la foto de 5mp. Posiblemente, la mejor ruta en este momento sería simular todo el proceso en VHDL/Verilog y ver cuántos bloques lógicos necesitaría. Gracias por los comentarios.
xilinx.com/support/documentation/application_notes/xapp462.pdf dice que el rango de frecuencia i/p al sintetizador de frecuencia es de 1 a 280 Mhz y el máximo de frecuencia del sintetizador es 280 * 32/1 = 8960 Mhz. así que incluso si el reloj es de 50Mhz, debería obtener una salida de 50 * 32 = 1600Mhz. Entonces, ¿me estoy equivocando en estas cifras?

Respuestas (2)

En términos de interfaz con la cámara y registro de datos, estará bien si puede manejarlo. Es posible que no maneje las velocidades que le interesan.

5MP * 3 (colores, RGB) * 15 (veces por segundo) = 225*e6. (suponiendo una profundidad de color de 24 bits)

Eso significa que necesitará una velocidad de reloj de al menos 225 MHz, suponiendo que pueda mover datos en cada señal de reloj, lo que no puede hacer, según el sensor, por lo que es posible que deba duplicar esta cifra a alrededor de 450-500 MHz.

El Spartan que estás viendo tiene una señal de reloj de 50MHz.

Así que la respuesta corta es no, no a esas velocidades.

La otra consideración que debe aplicar es cuántos bloques lógicos requiere su lógica. para resolver esto, escriba su implementación en VHDL/verilog, simule y luego sintetice. Lea los resultados de la herramienta y le dirá cuántos bloques lógicos necesita, luego seleccione un FPGA apropiado que tenga un 50 % más de bloques lógicos para permitir bloques inutilizables debido a las restricciones de enrutamiento y le dé espacio para crecer.

También debe considerar la memoria RAM o algún otro tipo de memoria y cómo almacenará estas ráfagas. Si está disparando a 15 fps durante 1 segundo, necesita 225 MB, que es mucho o RAM para un sistema integrado.

Después de almacenar en la RAM, deberá descargar la ROM de algún tipo (por ejemplo, una memoria flash compacta).

Oscilador de 50 MHz: los PLL pueden hacer que el FPGA sea mucho más alto. Y el 3A Starter viene con un oscilador de 133 MHz para alimentar sus puertos DDR2. Entonces podría hacer la E/S, pero depende de más aspectos de diseño. Dependiendo del algoritmo, el 3A DSP puede funcionar mejor.
tienes razón sobre el PLL y ejecutarlo más rápido, eso será posible. Sin embargo, es posible que aún no sea lo suficientemente rápido para la cantidad de datos que deben transferirse, además, no hay suficiente memoria RAM integrada en el dispositivo, menos de 2 MB y el kit de desarrollo tiene soporte para 64 MB, que no es suficiente.
Así que volvemos a depender del algoritmo. Un algoritmo de detección de bordes podría salirse con la suya con solo unas pocas líneas de exploración de memoria, pero eso suponiendo que también genera los datos con muy poco retraso. Kevin Boyd no ha indicado que sea necesaria la grabación ni ningún detalle adicional. Me imagino que no hay suficiente información, todavía.
No, no dependemos del algoritmo. Esa placa de demostración no tiene suficiente RAM para poder almacenar imágenes durante un período de tiempo real, cuatro fotogramas como máximo, lo que equivale a 375 mS. Sin considerar si la detección de bordes encajará, la placa de demostración no es adecuada.
@smashtastic: Con sus cálculos, parece que la velocidad del Spartan3a no es suficiente para los 5 MP a 15 fps. ¿Puede el Spartan3A DSP hacer el trabajo (como sugirió LoneTech)? Si 15 fps no es factible, ¿es posible obtener 5 fps del Spartan3A? Con respecto a la memoria RAM Si la demostración no es adecuada, ¿se puede ejecutar el spartan3A fpga a> 50 MHz cuando hago mi propio prototipo y se puede conectar para decir 1 GB de memoria RAM externa?
Con respecto a la memoria RAM Si la demostración no es adecuada, ¿se puede ejecutar el spartan3A fpga a> 50 MHz cuando hago mi propio prototipo y se puede conectar para decir 1 GB de memoria RAM externa?
¿Se puede sincronizar el Spartan3A externamente a 100 MHz para que el PLL interno pueda generar frecuencias más altas o estamos limitados a 133 MHz?
Se puede sincronizar más alto externamente, y tampoco está limitado a 133 MHz; eso es justo lo que usa el segundo oscilador externo en la placa de inicio 3A. Los límites dependen de la complejidad de la lógica, pero la canalización puede llevarlos bastante alto. La verdadera pregunta es aún más qué hacer con los datos después de leerlos. Ciertamente puede conectarse a cualquier cantidad de RAM, pero eventualmente querrá usar los datos en alguna parte.
Recuerde que también necesitará colocar un controlador SDRAM/SDR/DDR/DDR2 en la FPGA...
Kevin, ¿puede ser más claro acerca de sus requisitos, en particular, cuánto tiempo desea poder disparar ráfagas a 15 fps, qué procesamiento tiene la intención de realizar en el FPGA, si es que lo desea, y cuál es su almacenamiento no volátil?
@Smashtastic: Esto es lo que he estado pensando últimamente. En lugar de hacer todo en tiempo real, obtendría 5 MP a 15 fps durante aproximadamente 15 segundos almacenando los datos en la RAM y sigo sumergiendo los datos almacenados en una MMC o alguna memoria flash al mismo tiempo, considerando que la MMC es más lenta. Si pudiera tomar datos directamente de la cámara y enrutarlos al flash, sería maravilloso. Sin embargo, me pregunto si MMC o alguna otra tecnología flash puede lograr estas velocidades de datos. Después de la adquisición de los marcos, puedo procesar la imagen y capturarla nuevamente si es necesario.

Simplemente no sabemos lo suficiente de la pregunta y los comentarios (todavía). Internamente, un chip de la familia Spartan 3 probablemente podría hacer la detección de bordes, pero leer el sensor de imagen a esa velocidad es más una pregunta abierta: depende más de la interfaz del sensor y el diseño de la placa. Luego está la cuestión de qué hacer con todos los datos: es factible volver a enviarlos, posiblemente usando conexiones más amplias, pero el FPGA en sí mismo ciertamente no puede almacenarlos.

Desafortunadamente, esta pregunta se está convirtiendo en una discusión para la cual este sitio no fue diseñado. Seguimos teniendo que escarbar para encontrar los nuevos comentarios. Para dar una respuesta correcta verificable, tendríamos que hacer la mitad del trabajo de diseño, hasta la selección de componentes y el flujo de datos del algoritmo.

¿Hay algo malo en tener una discusión en este foro? Entiendo que la intención puede ser tener preguntas y respuestas para atraer a más usuarios y tráfico, pero discutir los detalles técnicos sigue ayudando al OP a trabajar en su solución. Estoy seguro de que si el OP pudiera responder a todas las preguntas adicionales planteadas, no preguntarían nada en este foro, ya que la respuesta habría surgido en el proceso de diseño. solo algunos pensamientos....
No hay nada malo con la discusión como tal, solo que el diseño no es muy bueno. Parece que hay planes para agregar la función (función de chat bajo reputación), pero aún no está lista. Lo habría vinculado pero parece estar en beta cerrada. electronics.stackexchange.com/privileges/chat-rooms
¿Puede un Spartan-3A/AN/E implementar detección de bordes para una cámara de 5MP?
RespuestasAquíPolítica de privacidad1y, 0v