FPGA de interfaz y un dispositivo de almacenamiento

Estoy haciendo este proyecto llamado "Registrador de alta velocidad de datos".

Los requisitos para este proyecto son muestrear las 2 señales analógicas simultáneamente.

  • ADC de 14 bits de 2 canales
  • Almacene 60 MSps (megamuestras por segundo), que es aproximadamente una velocidad de escritura sostenida de 250 MBps
  • El medio de almacenamiento debe poder acomodar de 500 GB a 1 TB de datos

Medio de almacenamiento:

M.2 PCI-Express es la última interfaz para SSD (unidad de estado sólido). Pero no estoy seguro si puedo conectar un SSD a FPGA a través de la interfaz PCIe 2.0 x4 (PCI express generación 2, con 4 carriles), debido a sus complicaciones.

Un host que puede interactuar con las tarjetas anteriores:

Dado que no puedo encontrar un procesador que tenga líneas de entrada LVDS paralelas para conectarse a ADC, estoy pensando en proceder con un FPGA.

Pero en el otro extremo tengo que interconectar un medio de almacenamiento como SSD, tarjetas SD, memoria flash NAND o cualquier otra solución posible.

Hay muchas soluciones para el medio de almacenamiento con la memoria necesaria y la velocidad. Pero el problema es la interfaz. Algunas interfaces de memoria comunes son: PCI express, SATA III (6 Gbps), interfaz de tarjeta SD, etc.

Por lo tanto, le pediría a cualquiera que sugiera qué interfaz sería factible, más fácil y mejor para interactuar usando FPGA.

Si se selecciona una interfaz estándar adecuada, podría seguir adelante con la selección de un FPGA y el diseño de un registrador de datos.

Construya el ADC+FPGA en una tarjeta PCIe (este tipo de cosas está disponible comercialmente) y colóquelo en una PC. Haga que el software se transfiera desde PCI mapeado en memoria al disco. Es posible que desee comprimir los datos en la tarjeta para ahorrar ancho de banda y almacenamiento.
Hay tarjetas que ya tienen requisitos similares, como la Noctar SDR .
He pasado una cantidad significativa de tiempo escribiendo software que habla con un elegante analizador de espectro usb-3 . Puedo guardar un flujo de datos sin procesar a 140 MBytes/seg en un SSD en python . Usar una PC para este tipo de cosas es una muy buena idea, y debería ser muy viable.
Además, USB-3.0 también es una opción aquí. Eso sería mucho más plug+play que PCI-e, aunque el desarrollo del controlador puede ser más complicado.
Desarrollé un "Controlador SATA optimizado para transmisión" que está diseñado para transmisiones de lectura o escritura de alto ancho de banda en HDD o SSD. Este controlador es capaz de manejar hasta 585 MiB/s. También tiene una capa de abstracción física que es independiente del proveedor y del dispositivo, por lo que puede usar este controlador con Virtex-5, Kintex-7, Virtex-7, Stratix II, Stratix IV. Son posibles otras implementaciones de capa de abstracción. No recomendaré SATA/ATA8 sobre PCIe, porque tienes que desarrollar/depurar PCIe y SATA.
Bueno, para USB 3.0 debe usar un IC, que es la forma más fácil de transferir datos hacia/desde su placa. La IP ya está disponible en Cupress y no necesita escribir su propio controlador. PCIe puede ser una solución, pero luego debe implementar los niveles más altos del protocolo. No recomendaría la interfaz SATA o SD, a menos que tenga un presupuesto bastante grande para comprar esas IP.
@Paebbels ¿Dónde obtengo este producto "Streaming Optimized SATAController"? Entonces, al usar SATAController, ¿podré conectar una FPGA con SSD que tenga una interfaz SATA III (6 Gb/s)?
@FarhadA Nunca me encontré con un SSD con una capacidad de más de 256 GB que tuviera una interfaz USB-3.0. Por lo tanto, esto podría hacerse mediante una interfaz paralela de 4 SSD a FPGA, ¿verdad? ¿Qué tal usar 4 tarjetas SD con una capacidad de 256 GB y una velocidad de escritura de 90 MB/s? sandisk.com/products/memory-cards/sd/extremepro-sdxc-sdhc-uhs-3/… Dado que no tengo un límite de presupuesto específico para este proyecto, también podría considerar la opción de interfaz de tarjeta SD. Tengo una fecha límite para este proyecto, es decir, 5 meses a partir de ahora. Así que quiero que sea simple y fácil de interconectar.
@ pjc50 No creo que pueda usar una PC para almacenar los datos en SSD. En realidad, todo este sistema se pone en vuelo. Debe ser lo más compacto posible.
Probablemente esté en contra de la política del sitio hacer recomendaciones, pero mi antiguo empleador tiene experiencia en hacer este tipo de cosas como un dispositivo personalizado: argondesign.com/case-studies/2013/apr/29/… (7 canales, decenas de megabits por canal ). Las PC se pueden hacer bastante pequeñas, lo suficientemente pequeñas como para caber como backplane debajo de cuatro SSD.
@Vicky Este controlador establece un enlace SATA en Gen1/2/3 y lee la respuesta de los HDD o SSD al comando de identificación del dispositivo ATA8. Si se cumplen todos los requisitos (ATA8, modo de direccionamiento LBA48, compatibilidad con DMA, ...), la interfaz está lista para transferir datos. El controlador tiene 2 interfaces FIFO (RX y TX, cada una de 32 bits de ancho) y una interfaz de comando (comando {leer, escribir, vaciar, ...}, estado, error, StartAddress, BurstLength). Además, escribí un 'sistema de archivos' MasterTable simple que traduce los números de la base de datos en parámetros de desplazamiento y longitud para lectura y escritura. Si estás interesado, ponte en contacto conmigo.
@Vicky Nuestras mediciones muestran que el controlador SATA no es el factor limitante en la transferencia de datos hacia y desde SSD; en la mayoría de los casos, es el SSD o el HDD cuando los datos no están en la memoria caché o no se han obtenido previamente. También reconocemos que la limitación de velocidad (inserción de primitivas HOLD) solo la realiza el HDD o SSD, por lo que logramos una utilización del enlace cercana al 99%.
@vicky, el problema con la tarjeta SD es que necesita tener una IP para la interfaz SD, y debe crear un sistema de archivos especial para almacenar los datos en paralelo, a menos que solo cree 4 archivos diferentes y los trate como datos binarios independientes y combinarlos más tarde. Una alternativa es usar una placa como Jetson TK1 de NVIDIA que tiene tanto USB3 como SATA y conectarla a fpga usando PCIe.
Según su sugerencia, ADC se conectará a FPGA, SSD se conectará a Jetson TK1, FPGA y Jetson TK1 se conectarán entre sí a través de PCI express.
-1 Su edición de hoy daña seriamente la pregunta, al eliminar toda la información crítica de la aplicación. Tal como está la pregunta ahora, también podría usar una tarjeta SD en modo SPI, ya que no ha establecido ningún requisito que no pueda cumplirse con eso. Cambiar drásticamente las preguntas después de que hayan comenzado a recopilar respuestas es una mala idea, ya que hace que las respuestas parezcan irrelevantes.

Respuestas (2)

Acabamos de construir un registrador con una tasa de datos de ese orden de magnitud. Los datos se capturan en un FPGA y luego se envían a una PC usando USB3.0 que luego los escribe en el disco.

Suponiendo que su latencia de registro no sea crítica (que generalmente no lo es), imagino que podría hacer lo mismo.

Si utiliza una placa FPGA Opal Kelly , las interfaces HDL y el desarrollo del controlador son muy sencillos. ¡No tengo otra conexión que no sea como un cliente satisfecho!

Alternativamente, el uso de una tarjeta de complemento PCIe con el controlador Xillybus proporciona otra experiencia de controlador y HDL sencilla. 250 MB/s lo está presionando para un solo carril de PCIe, pero como usted dice, una interfaz x4 estará bien.

O el enfoque completamente personalizado de construirlo todo desde cero, por supuesto, está abierto para usted si tiene tiempo, pero no dinero. Sin embargo, todavía construiría algo para interactuar con una PC, en lugar de intentar ir directamente al disco desde el FPGA.

El conductor de Xillybus es muy caro. Preferiría construirlo desde cero. Para construirlo desde cero me gustaría saber qué interfaz sería menos complicada: 1) FPGA-SSD: PCIexpress 2) FPGA-SSD: SATA III 3) Tarjeta FPGA-SD: SDXC y SDXC-I (UHS-I) 4 ) Tarjeta FPGA-SD : CompactFlash o alguna otra solución recomendada???
¿A qué te refieres con construir desde cero? ¿Quiere escribir sus propias direcciones IP para SATA y SDHC?
@Vicky "¿qué interfaz sería menos complicada"? - FPGA-SSD (SATA III) es una implementación sencilla si tiene un transceptor/capa física en funcionamiento. La capa de comandos es un conjunto de comandos ATA8 que solo necesita implementar un puñado de comandos, los otros comandos están desactualizados, por compatibilidad o para dispositivos CompactFlash o ATAPI. Los FSM de capa de enlace y de transporte se proporcionan en el estándar SATA y se pueden reducir si ahorra algunas funciones. Pero la capa física es difícil de depurar y necesita buenas habilidades en FPGA y diseño de dominios de múltiples relojes.
@Vicky FPGA-SSD (PCIe): No conozco ningún desarrollador de FPGA. tablero o ext. placa que conecta una FPGA a una SSD por PCIe (SATAe, M.2) => por lo que no hay sistema de prueba. Ni siquiera estoy seguro de si las tarjetas SSD M.2 usan el enlace PCIe. Los generadores centrales de proveedores de FPGA pueden crear PCIe IPCores, que generan código utilizable, pero debe escribir la capa de transacción muy compleja (control de flujo basado en créditos, reordenación, ...), un motor DMA y una capa de comando en la parte superior de este. A diferencia de SATA, creo que no puede prescindir de tantas funciones para reducir el trabajo de implementación.
Tarjeta @Vicky FPGA-SD (CF): ¿Quién quiere implementar un protocolo heredado? CompactFlash es IDE. ¿O te refieres a CFast? - Esto también es SATA para el factor de forma de flash compacto :)

Estrategia alternativa: construye tu propio dispositivo de almacenamiento masivo.

Haga que el FPGA escriba directamente en una colección de chips NAND Flash. ¡No olvide la fase de colación y verificación! También debería poder organizar el borrado previo de toda la matriz antes de iniciar la captura (borrar es más lento que escribir) y mantener su propia lista de bloques defectuosos. Puede escribir en varios chips en paralelo si es necesario para el ancho de banda de escritura. Una vez más, recomiendo enfáticamente alguna forma de compresión; gzip es adecuado para la transmisión y no tiene pérdidas.

Luego puede presentar una interfaz USB a una PC que expone toda la captura como un dispositivo de bloque, o un sistema de archivos que contiene un solo archivo "mágico" para toda la captura.