Diseño de firmware FPGA: ¿Qué tan grande es demasiado grande?

Me pregunto si hay otra forma de ver el problema.

Haciendo a un lado su estimación de 512 operaciones FFT (64 puntos cada una) y 42k operaciones MAC ... ¿Supongo que esto es lo que necesita para una pasada a través del algoritmo?

Ahora ha encontrado un núcleo FFT con 4 unidades DSP ... pero, ¿cuántos ciclos de reloj toma por FFT? (rendimiento, no latencia)? Digamos 64, o 1 ciclo por punto. Luego tiene que completar esas operaciones de 42k Mac en 64 ciclos, tal vez 1k MAC por ciclo, con cada MAC manejando 42 operaciones.

Ahora es el momento de ver el resto del algoritmo con más detalle: identifique no las MAC, sino las operaciones de nivel superior (filtrado, correlación, lo que sea) que se pueden reutilizar. Cree núcleos para cada una de estas operaciones, con reutilización (por ejemplo, filtros con diferentes conjuntos de coeficientes seleccionables) y pronto podrá encontrar relativamente pocos multiplexores entre núcleos relativamente grandes ...

También, ¿es posible alguna reducción de fuerza? Tuve algunos casos en los que se requerían multiplicaciones en bucles para generar cuadráticas (y superiores). Al desenrollarlos, podría generarlos de forma iterativa sin multiplicación: ¡Me sentí muy satisfecho conmigo mismo el día que construí un motor de diferencia en FPGA!

Sin conocer la aplicación, no puedo dar más detalles, pero es probable que algunos de estos análisis hagan posibles algunas simplificaciones importantes.

También, ya que suena como si no tuvieras una plataforma definida en mente, considera si puedes particionar entre múltiples FPGA ... mira esta placa o éste que ofrece múltiples FPGA en una plataforma conveniente. También tienen una placa con 100 dispositivos Spartan-3 ...

(p.s. Me decepcionó cuando los tipos de software cerraron esta otra pregunta; creo que es al menos tan apropiado allí)

Editar: vuelve a editar. Creo que estás empezando a llegar allí. Si todas las entradas del multiplicador son salidas FFT o coeficientes de "no filtro", está comenzando a ver el tipo de regularidad que necesita explotar. Una entrada a cada multiplicador se conecta a una salida FFT, la otra entrada a una ROM de coeficiente (BlockRam implementado como una matriz constante).

La secuenciación de diferentes operaciones FFT a través de la misma unidad FFT secuenciará automáticamente las salidas FFT más allá de este multiplicador. La secuenciación de los coeficientes correctos en la otra entrada de MPY ahora es "simplemente" una cuestión de organizar las direcciones ROM correctas en el momento correcto: un problema organizativo, en lugar de un enorme dolor de cabeza de MUXes.

Sobre el rendimiento: creo que Dave Tweed fue innecesariamente pesimista: la FFT realiza n * log (n) operaciones, pero puede elegir O (n) unidades de mariposa y O (logN) ciclos, o O (logN) unidades y O (n) ciclos, o alguna otra combinación para adaptarse a sus objetivos de recursos y velocidad. Una de estas combinaciones puede hacer que la estructura de multiplicación post-FFT sea mucho más sencilla que otras ...

Si este problema no tiene restricciones duras en tiempo real, y suena como si no lo hiciera, solo quiere que se ejecute "más rápido", entonces parece que podría ser bastante propenso a la aceleración en una o más GPU. Hay varias bibliotecas de software que hacen de esta una propuesta relativamente sencilla, y esto sería un orden de magnitud más fácil que ir directamente al hardware FPGA personalizado.

Solo Google para "Biblioteca habilitada para GPU" o "Biblioteca acelerada por GPU" para comenzar.

Es posible usar un hardware especializado o un FPGA (o incluso un CPLD) para acelerar en gran medida ciertos tipos de operaciones matemáticas. La clave a tener en cuenta cuando se trata de diseñar hardware (circuitos o lógica FPGA) para acelerar las operaciones matemáticas es averiguar qué orden de datos necesitarán para entrar y salir de su dispositivo. Un dispositivo con un diseño eficiente de E / S puede ofrecer un rendimiento mucho mejor que uno con un diseño ineficiente, incluso si este último dispositivo requiere muchos más circuitos.

No he intentado elaborar un diseño de asistencia de hardware para una FFT, pero he examinado la asistencia de hardware para grandes operaciones de multiplicación (como se podría usar para el cifrado RSA). Muchos microcontroladores, incluso aquellos con hardware especial de multiplicación rápida, no son tan eficientes en tales operaciones porque requieren una gran cantidad de registros aleatorizados. El hardware que fue diseñado para minimizar el intercambio de registros podría lograr un rendimiento mucho mejor con operaciones de multiplicación de precisión múltiple, incluso si el hardware en sí no fuera tan sofisticado. Por ejemplo, el hardware que puede realizar una multiplicación 16xN canalizada dos bits a la vez (cambiando en dos bits inferiores de multiplicar, y desplazando dos bits superiores de resultado) puede lograr un mejor rendimiento que el hardware que puede realizar una multiplicación de 8x8 en un ciclo, aunque el primero puede necesitar menos circuitos (y, en virtud de la canalización, tiene una ruta de datos crítica más corta). La clave es averiguar cómo se verá el "bucle interno" del código necesario, y averiguar si hay alguna ineficiencia que pueda eliminarse fácilmente.

¿Qué tan pequeño es un problema con el tiempo de ejecución?

Esto realmente parece ser una situación en la que realmente debería implementar una MCU suave, una FPGA con una MCU rígida integrada, o incluso un dispositivo MCU separado, y serializar todas sus operaciones.

Suponiendo que tienes el tiempo de ejecución, hacer tus FFT en el software será mucho más fácil de depurar, y probablemente mucho más simple de diseñar también.