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

Tengo una transformación de procesamiento de señal particularmente grande que necesita ser portada de matlab a VHDL. Definitivamente requiere algún tipo de intercambio de recursos. Un poco de cálculo me dio lo siguiente:

• 512 ffts de 64 puntos
• 41210 operaciones de adición múltiple

Teniendo en cuenta que el FPGA Virtex 6 más grande tiene ~ 2000 bloques DSP48E, sé que puedo compartir recursos para reutilizar los recursos varias veces. El tiempo de ejecución no es realmente un problema, el tiempo de procesamiento puede tomar relativamente tiempo en términos de FPGA.

Al observar el uso de recursos, el uso de la arquitectura radix-2 lite me da bloques de 4dsp / operación FFT = 2048 bloques DSP, un total de ~ 43k. El mayor Virtex FPGA tiene 2k bloques, o 20 operaciones / mux.

Obviamente, incluir muxes tan grandes en la tela también va a tomar rodajas. ¿Dónde encuentro el límite superior de este límite? No puedo compartir infinitamente los recursos de FPGA. ¿Los multiplicadores 41210 son demasiado grandes? ¿Cómo calculo lo que es demasiado grande?

También he visto otros recursos (Slices, Brams, etc.). Radix-2 Lite también da 4 x 18k brams / fft = 2048 brams más grande Xilinx FPGA contiene 2128 Brams. Muy limítrofe. Me preocupa que mi diseño sea demasiado grande.

ACTUALIZAR:

Un poco más de información sobre el diseño en sí. No puedo entrar en detalles, pero esto es lo que puedo dar:

Initial conditions -> 512 ffts -> 40k multipliers ---------|----> output data to host 

                 ^------re-calculate initial conditions----|

especificación de salida de datos: "más rápido que la simulación matlab"

cálculos sabios, aquí es donde estoy:

Etapa FFT: fácil. Puedo implementar 1/2/4/8 FFT, almacenar los resultados en SDRAM y acceder más tarde. Relativamente pequeño, incluso si lleva mucho tiempo, está bien. usando radix-2 lite puedo obtener 2 DSP48Es y 2 BRAMS / FFT de 18k. la transmisión da 6 DSP48Es 0BRAMS / FFT. en cualquier caso, la FFT de 64 puntos es pequeña en términos de recursos FPGA.

Multiplicadores : este es mi problema. Las entradas de multiplicación se toman de tablas de búsqueda o de datos FFT. Realmente es solo un montón de sumas múltiples. No hay mucho para optimizar. No es un filtro, pero tiene características similares a un filtro.

Considerando el uso compartido de recursos en el FPGA, las matemáticas funcionan de la siguiente manera: un LUT-6 puede usarse como un mux de 4 vías. La fórmula para un N-way, M bit mux es la siguiente:

N*M/3 = number of luts, or N*M/12 = slices (4 LUTS/slice).

No es bueno obtener cifras para mi implementación. El 90% de la familia virtix-6 no tiene suficientes sectores para compartir recursos en sus DSP para realizar 40k operaciones.

Me pregunto si hay otra forma de ver el problema.

Reproduciendo 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 tarda por FFT? (rendimiento, no latencia)? Digamos 64, o 1 ciclo por punto. Luego debe completar esas 42k operaciones de Mac en 64 ciclos, quizás 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 puedan reutilizarse. Cree núcleos para cada una de estas operaciones, con capacidad de reutilización (por ejemplo, filtros con diferentes conjuntos de coeficientes seleccionables) y pronto encontrará que se requieren relativamente pocos multiplexores entre núcleos relativamente grandes ...

Además, ¿es posible alguna reducción de fuerza? Tuve algunos casos en los que se requerían multiplicaciones en bucles para generar cuadráticos (y superiores). Al desenrollarlos, pude generarlos iterativamente sin multiplicación: ¡estaba 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.

Además, dado que parece que no tiene una plataforma definida en mente, considere si puede dividir entre múltiples FPGA ... eche un vistazo a esta placa o esta que ofrece múltiples FPGA en una plataforma conveniente. También tienen una placa con 100 dispositivos Spartan-3 ...

(PD: me decepcionó cuando los chicos del software cerraron esta otra pregunta, creo que al menos es lo apropiado allí)

Editar: re su edición - Creo que está comenzando a llegar allí. Si todas las entradas del multiplicador son salidas FFT o coeficientes "sin 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 MPY ahora es "meramente" una cuestión de organizar las direcciones ROM correctas en el momento correcto: un problema de organización, en lugar de un gran dolor de cabeza de MUX.

Sobre el rendimiento: creo que Dave Tweed estaba siendo innecesariamente pesimista: la FFT tomaba n * log (n) operaciones, pero puedes 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 esas combinaciones puede hacer que la estructura de multiplicación posterior a la FFT sea mucho más simple que otras ...

Si este problema no tiene restricciones duras en tiempo real, y parece que no lo tiene, solo desea que se ejecute "más rápido", entonces parece que podría ser bastante susceptible 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 aproximadamente 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 utilizar un hardware especializado o un FPGA (o incluso un CPLD) para acelerar en gran medida ciertos tipos de operaciones matemáticas. La clave para tener en cuenta al tratar de diseñar hardware (circuitos o lógica FPGA) para acelerar las operaciones matemáticas es averiguar qué datos de pedido necesitarán entrar y salir de su dispositivo. Un dispositivo con un diseño de E / S eficiente 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 una que he visto es la asistencia de hardware para grandes operaciones de multiplicación (como podría usarse para el cifrado RSA). Muchos microcontroladores, incluso aquellos con hardware especial de multiplicación rápida, no son terriblemente eficientes en tales operaciones porque requieren una gran cantidad de registros aleatorios. El hardware 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 canalizada de 16xN de dos bits a la vez (cambiando en dos bits inferiores de multiplicación 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, a pesar de que los primeros pueden tener menos circuitos (y, en virtud de la canalización, tienen una ruta de datos críticos más corta). La clave es descubrir cómo se verá el "bucle interno" del código necesario y determinar si hay alguna ineficiencia que pueda eliminarse fácilmente.

¿Qué tan poco nos preocupa el tiempo de ejecución?

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

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