Captura de datos a 500MHz

Tengo un muestreo ADC a 500 MHz (está recopilando datos de un sensor de ultrasonido). Necesito poder transmitir estos datos a mi PC (por el momento, esto se hará a través de una unidad inalámbrica). Estoy buscando una solución informática que se encuentre entre la unidad inalámbrica y el ADC. Estoy poniendo todo esto en un robot y estoy tratando de mantenerlo lo más pequeño posible (en términos de dimensiones) y espero mantener bajo el consumo de energía.

¿Hay alguna solución que sea mejor que usar un FPGA? He leído que es muy difícil hacer que un FPGA funcione a 500 MHz y que podría ser necesario algún tipo de computación paralela. ¿Eso significa que se supone que debo usar GPU?

¿Hablas en serio, ultrasonido a 500 MHz?
Bien, digamos que está utilizando un ADC de 10 bits y desea enviar estos datos a 500 MHz. Llegamos a la siguiente tasa: 5Gbps. Si está intentando transferir 5 Gbps a través de un enlace inalámbrico, creo que es un poco utópico.
Es un sensor de ultrasonido de 250MHz. El muestreo se realiza a una velocidad mayor. Lo siento, no he pensado en cuanto al enlace inalámbrico. Estaba principalmente preocupado por el enlace ADC. Podría promediar (para evitar el ruido) y/o comprimir los datos antes de enviarlos a través del enlace inalámbrico. Entonces, probablemente tendría una etapa intermedia de almacenamiento en búfer.
¿Qué estás tratando de lograr con frecuencias tan extremas? La longitud de onda de 250 MHz en el aire es de aproximadamente 1,3 micrones, y el aire tiene pérdidas extremas en estas frecuencias. Un sensor de 250 kHz, muestreado a 500 kHz o tal vez a 1 MHz, tendría mucho más sentido.
Aparentemente, 250MHz no es un error tipográfico, hay personas que lo usan para obtener imágenes de la piel. No es difícil lograr que los FPGA funcionen a 500 MHz; de hecho, creo que esa es la única opción realista. El ADC probablemente generará LVDS: ¿qué número de pieza está usando? He estado involucrado en un proyecto similar y te advierto que no es ni barato ni fácil.
@ pjc50: Pero no tiene mucho sentido en el contexto de un proyecto de robot.
@DaveTweed, quién sabe, tal vez sea un robot que se arrastra por la piel.
@DaveTweed Sí, pensé lo mismo, pero luego vi esto: ieeexplore.ieee.org/xpl/…
@GleisonStorto: estaría dispuesto a apostar que se trata de un sonar en el agua , donde tiene sentido. Supongo que el robot del OP está en el aire, ya que está hablando de usar un enlace inalámbrico (presumiblemente RF).
No estoy seguro de lo que está haciendo el OP, pero si está en un líquido o sólido, entonces son comunes los anchos de pulso ultrasónico de menos de 1uS, y si quisiera ver la forma del reflejo, puedo imaginar un muestreo tan rápido.
¿A qué está conectado ahora el ADC de 500 MHz? ¿Una placa personalizada, o algo para lo que pueda proporcionar especificaciones o un enlace? Obviamente, la velocidad de datos es demasiado alta para Wifi. Pero si no muestrea continuamente, o si puede realizar alguna reducción de datos antes de la transmisión, eso ayudará. Hace 10 años trabajé con Xilinx VirtexII FPGA que podía funcionar a 400 MHz. No descartaría los FPGA sin una investigación independiente.
El sensor puede transmitir a 250 MHz, pero su ancho de banda casi seguramente es solo una fracción de eso, probablemente menos del 10%. Solo necesita muestrear varias veces ese ancho de banda, lo que reduciría considerablemente la velocidad de datos.
Sin ir a un IC personalizado, FPGA en realidad podría ser su única opción para la interfaz inicial del ADC. Ahora obtienes estos bytes de datos en el FPGA, llegando a 500 MHz, qué hacer con ellos. Tiene dos opciones implícitas, hacer algún procesamiento dentro de la FPGA, o de alguna manera pasarlas a algún arreglo de procesadores. Y luego qué... Nada de esto va a ser fácil.

Respuestas (1)

Una solución es usar un demux para reducir la frecuencia de muestreo del ADC y aprovechar la gran cantidad de pines en el FPGA.

Por ejemplo, el ADC podría sincronizarse a 500 MHz y el FPGA a 125 MHz, que es más razonable. Luego, se puede usar un demux 4: 1, recolectando 4 muestras de ADC para cada marca del FPGA. El bus se vuelve 4 veces más ancho, por lo que en cada marca la FPGA necesita ingerir 40 bits, no 10, pero eso no es difícil de manejar.

En mi aplicación, el ADC 2Gsps y el demux 8:1 se venden como un par, por lo que su salida se convierte en 88 bits a 250 Mbps. No hay otra forma de usar el ADC.

Asumo que no tomará muestras por mucho tiempo, a ese ritmo. Los requisitos de procesamiento estarán determinados por la cantidad de muestras que se deben usar y la rapidez con la que necesita las respuestas. Por ejemplo, podría usar fibra de 10 GbE para transportar los datos de su robot a una PC normal, para el procesamiento fuera de línea, sin necesidad de hardware o software exótico.

Los enlaces inalámbricos disponibles en el mercado solo funcionan a quizás 100 Mbps, y solo en condiciones ideales, que no se encuentran en un robot en movimiento. Algo tendrá que almacenar en búfer toda la señal antes de descargarla. DRAM en la FPGA? PC integrado? ¡Buena suerte!

125MHz es REALMENTE lento para un FPGA. Con un Stratix IV, podría alcanzar fácilmente los 250MHz. Depende del tipo de operaciones que vaya a realizar con estos datos y de la resolución del ADC. Una adición de 32 bits es perfectamente posible a 250 MHz, una de 64 bits tendría que dividirla en dos ciclos.
Sí, puedes ir mucho más rápido que 125 MHz. Tengo un diseño sobre un Spartan 6 que funciona a 250 MHz. Y el núcleo PCIe gen3 x8 sale a 256 bits a 250 MHz. Los segmentos DSP en los FPGA Virtex 6 pueden alcanzar hasta 600 MHz y hasta 700 MHz en Virtex 7.
Captura de datos a 500MHz
RespuestasAquíPolítica de privacidad1y, 0v