Integración de memoria AM335x FPGA

Actualmente estoy diseñando una mesa de mezclas digital. Tenemos una cantidad algo grande de ADC y DAC (más de los que puede manejar el puerto serie de audio multicanal del procesador). Decidimos que la solución para esto era usar un FPGA para interactuar con los convertidores de datos y dejar que el procesador accediera a los datos a través de la RAM en el FPGA. Todavía no hemos elegido un FPGA.

Por lo que he leído, podemos configurar la FPGA RAM como un dispositivo NOR de 16 bits no multiplexado a través de la GPMC. ¿Es esto correcto? Y mi otra pregunta es que probablemente sería demasiado lento mantener los datos en la RAM de la FPGA, entonces, ¿sería posible configurar una transferencia DMA desde la RAM de la FPGA a otra memoria en el procesador que sea más fácil y rápida de acceder? ¿O necesitaríamos usar una PRU para copiar los datos?

¿GPMC, PRU? ¿Cómo se relaciona esta pregunta con TI? ¿Cómo se relacionan NOR y no multiplexados con la RAM en una FPGA? Los FPGA tienen SRAM internos. Esta RAM (BlockRAM, Embedded BlockRAM o Distributed RAM) es muy rápida, al menos más rápida de lo que puede manejar un ARM. La pregunta es: ¿Qué interfaz usarás? El factor limitante es su interfaz ARM-FPGA y su latencia.
El procesador TI AM335x tiene un GPMC (controlador de memoria de uso general) y 2 PRU (unidades programables en tiempo real). La SRAM es más rápida, pero no puedo acceder a ella lo suficientemente rápido. No creo a través de la interfaz GPMC. Estoy preguntando cómo interactúo. con la SRAM en la FPGA.
Entonces, podría implementar una interfaz de memoria en la FPGA, para que actúe como un chip de memoria normal. La ventaja podría ser que la SRAM de la FPGA es visible en el espacio de direcciones global de ARM, lo que permite DMA. Tienes otras interfaces: PCIe, buses paralelos, AMBA.... ? ¿Qué interfaces de memoria son compatibles con GPMC: (S)SRAM, DRAM, Flash, SD-Card (QuadSPI)...?
La GPMC es compatible con NOR, NAND y SRAM. Pero en la herramienta pin mux que ofrece TI, ofrece opciones para NOR y NAND multiplexadas y no multiplexadas, y leí en alguna parte que las interfaces SRAM son como NOR.
No conozco este ARM, pero la interfaz NOR paralela habitual proporcionada por las CPU es compatible con las SRAM paralelas. Que es probablemente lo que quieres usar. Los NOR en serie y los SRAM en serie están completamente fuera de discusión (generalmente son interfaces SPI de uno o varios bits de datos), lo mismo ocurre con la interfaz NAND, y es muy poco probable que desee emular una DRAM con su FPGA para el ARM. Ya sea para usar una interfaz multiplexada o no multiplexada: eso depende de la cantidad de pines disponibles y la velocidad que desea lograr.
Sí, la interfaz paralela de 16 u 8 bits es lo que planeo usar. ¡Gracias por la aclaración!

Respuestas (1)

Haré algunas suposiciones: dado que se trata de una mezcla de audio, querrá leer secuencialmente todos los ADC a una velocidad sincrónica fija (como 96 kHz) y escribir secuencialmente todos los DAC a la misma velocidad. Creo que la PRU será la forma más fácil de implementar un canal de datos rápido hacia/desde una FPGA.

Hay dos procesadores PRU en un procesador AM335x Sitara, y cada uno tiene 32 pines de entrada y 32 pines de salida. Dado que probablemente necesite algunas señales de control y probablemente esté usando códecs de 24 bits, eso debería funcionar bien. Podría dedicar una PRU para recibir datos y la otra para enviar datos. Con un código C estricto, estimo que podría obtener al menos 10 muestras por microsegundo en cada dirección (30 megabytes/segundo) y más con lenguaje ensamblador.

He puesto múltiples interfaces de audio I2S en un FPGA y no es tan difícil. Como dijiste, los códecs podrían mover datos hacia/desde FPGA sram, y después de cada ciclo de códec (cada 10.417 microsegundos a 96 kHz), las PRU podrían leer/escribir los datos como un bloque contiguo. Un secuenciador simple en la FPGA podría responder a las luces estroboscópicas de la PRU para recorrer el bloque de datos. En Sitara, un proceso de Linux puede asignar un bloque de memoria para compartir con la PRU. He puesto matrices y estructuras de C en la memoria ARM/PRU compartida para permitir que el proceso de Linux y la PRU compartan datos como variables de C.

Espero que ayude.

Sí, esto es muy útil. Y tus suposiciones eran correctas. Estaba pensando en lo mismo que decías, sin embargo, asumo datos justificados a la izquierda porque uno de mis ADC no es compatible con I2S. Pero, la complejidad es la misma. Y tampoco sabía si podía usar la transferencia DMA desde la FPGA SRAM. Si puedo, lo usaré, si no, puedo usar las PRU como dijiste. De cualquier manera estoy bien con.
Sí, I2S y Left-Justified son casi idénticos: permití que mi interfaz de códec FPGA manejara ambos simplemente agregando dos D-flops y un mux 2: 1.
Solo tengo curiosidad, ¿qué FPGA usaste? No estoy exactamente seguro de qué tan poderoso debe ser mi FPGA.
Nunca he usado DMA en Sitara, porque las PRU pueden depositar datos directamente en la memoria de la aplicación de Linux, como DMA (pero bajo el control de un programa C). Programar DMA me parece desalentador.
Creo que casi todos los FPGA serán lo suficientemente rápidos, es más una cuestión del tamaño correcto. Utilicé un Actel 42MX16 (una pieza basada en antifusibles) para la interfaz del códec (también hizo muchas otras cosas, como capturar velocidades y posiciones del motor). Registré todo a 18.432 MHz, y la parte estaba holgazaneando a esa velocidad. Hoy, usaría algo basado en flash, como una parte A3P. Actel ahora es MicroSemi.
DMA parece desalentador... pero si puedo resolverlo, podría hacer mi vida más fácil. Pero si no lo obtengo de inmediato, probablemente tendré que optar por la idea de PRU. Quería usar la PRU para manejar los protocolos de Ethernet con un módulo externo, pero si lo necesito, siempre puedo dejar que el núcleo ARM también lo haga.
Obtengo un buen rendimiento del controlador Ethernet estándar de Linux que se ejecuta en ARM. Estoy transmitiendo datos a hasta 1000 paquetes por segundo (solo cargas útiles de 56 bytes sobre UDP) con 100M Ethernet y nunca pierde el ritmo. Sin embargo, la PRU puede ser necesaria para 1G Ethernet.
Estoy bien con la ethernet de 100MHz. Pero estoy bastante seguro de que tengo las cosas de la transferencia DMA resueltas. Solo obtengo 1 canal DMA. Pero esto debería ser suficiente porque puedo transferir los datos ADC, luego tener un enlace a otra estructura de parámetros de transferencia DMA y luego iniciará automáticamente la transferencia de datos DAC, solo cambio entre los 2 con enlaces y no debería tener mucha sobrecarga . Y si lo hago, todavía tengo PRU. Ahora todo lo que tengo que hacer es escribir el códec de audio FPGA y averiguar cómo interactuar con la SRAM.
Integración de memoria AM335x FPGA
RespuestasAquíPolítica de privacidad1y, 0v