Conception du firmware FPGA: quelle taille est trop grande?


12

J'ai une transformation de traitement du signal particulièrement importante qui doit être transférée de matlab vers VHDL. Cela nécessite certainement une sorte de partage des ressources. Un peu de calcul m'a donné ce qui suit:

  • 512 pieds de 64 points
  • 41210 opérations de multiplication-ajout

Étant donné que le plus grand FPGA Virtex 6 a environ 2000 blocs DSP48E, je sais que je peux partager des ressources afin de réutiliser les ressources plusieurs fois. Le temps d'exécution n'est pas vraiment un problème, le temps de traitement peut prendre relativement longtemps en termes de FPGA.

En regardant l'utilisation des ressources, l'utilisation de l'architecture radix-2 lite me permet d'obtenir des blocs 4dsp / opération FFT = 2048 blocs DSP, un total de ~ 43k. le plus grand FPGA Virtex a 2k blocs, soit 20 opérations / multiplexeur.

De toute évidence, l'inclusion de tels grands multiplexeurs dans le tissu va également prendre des tranches. Où puis-je trouver l'extrémité supérieure de cette limite? Je ne peux pas partager à l'infini les ressources FPGA. Les multiplicateurs 41210 sont-ils trop grands? Comment calculer ce qui est trop grand?

J'ai également regardé d'autres ressources (Slices, Brams, etc.). Radix-2 Lite donne également 4 x 18 000 brams / pieds = 2048 brams, le plus grand FPGA Xilinx contient 2128 Brams. très limite. Je crains que mon design soit trop grand.


MISE À JOUR:

Quelques informations supplémentaires sur le design lui-même. Je ne peux pas entrer dans les détails, mais voici ce que je peux donner:

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

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

sortie datarate spec: "plus rapide que la simulation matlab"

en ce qui concerne les calculs, voici où j'en suis:

Étape FFT: facile. Je peux implémenter des FFT 1/2/4/8, stocker les résultats dans SDRAM et y accéder plus tard. Relativement petit, même si cela prend du temps, ça va. en utilisant radix-2 lite, je peux obtenir 2 DSP48E et 2 BRAMS / FFT 18k. le streaming donne 6 DSP48E 0BRAMS / FFT. dans les deux cas, la FFT à 64 points est petite en termes de ressources FPGA.

Multiplicateurs : c'est mon problème. Les entrées de multiplication proviennent de tables de recherche ou de données FFT. Ce n'est vraiment qu'un tas de multiplications. Il n'y a pas grand-chose à optimiser. Pas un filtre, mais a des caractéristiques similaires à un filtre.

Compte tenu du partage des ressources sur le FPGA, les calculs fonctionnent comme suit: Un LUT-6 peut être utilisé comme multiplexeur à 4 voies. La formule pour un multiplexeur N bits à M bits est la suivante:

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

croquer les chiffres pour ma mise en œuvre ne donne pas de bons résultats. 90% de la famille virtix-6 ne dispose pas de suffisamment de tranches pour partager les ressources de leurs DSP afin d'effectuer 40 000 opérations.


Les formes les plus efficaces de partage des ressources sont la sérialisation partielle où vous pouvez accéder aux données en adressant la mémoire. Bien sûr, à l'extrême, vous êtes de retour à un processeur de programme stocké conventionnel - le manque d'exigences de performances strictes commence à pointer vers la flexibilité d'une implémentation logicielle fonctionnant peut-être dans un nuage de calcul.
Chris Stratton

1
Cela ne fait pas partie de votre question, mais dans votre calcul des ressources, vous n'avez pas indiqué la taille de l'opérande. 512 FFT x 64 points x combien de bits? Dans un FPGA, la taille de l'opérande dépend entièrement de vous, vous devez donc en tenir compte lorsque vous déterminez la taille de votre problème.
Le Photon

Je ne sais pas si vous vous en êtes rendu compte, mais ces gros FPGA sont assez chers. Certains peuvent dépasser 5 000 $. Vous devriez peut-être aussi considérer cela, à moins que le coût ne soit pas un problème.
Gustavo Litovsky

1
Malheureusement, au-delà du type de suggestions de solutions alternatives que vous avez reçues dans les réponses jusqu'à présent, je doute que nous puissions faire beaucoup plus pour vous. Je veux dire, vous pouvez créer un seul cœur FFT et exécuter vos 512 entrées les unes après les autres, et évidemment, cela conviendrait même à un FPGA assez petit. Quelque part entre cela et tout faire en parallèle est le bon équilibre entre vitesse et ressources pour votre application ... mais il est difficile pour quiconque sauf vous de dire où cet équilibre devrait être.
The Photon

1
Avez-vous un numéro de budget pour cela? Comme l'a souligné Gustavo, les FPGA haut de gamme sont chers, tout comme le développement d'un PCB pour les installer. Alors que le simple fait de doubler (ou de quadrupler ou ...) la quantité de matériel informatique et de continuer à utiliser l'existant (?) Éprouvé, le code Matlab pourrait probablement répondre aux spécifications de vitesse données.
The Photon

Réponses:


8

Je me demande s'il y a une autre façon de voir le problème?

Jouer votre estimation de 512 opérations FFT (64 points chacune) et 42k opérations MAC ... Je suppose que c'est ce dont vous avez besoin pour un passage dans l'algorithme?

Vous avez maintenant trouvé un noyau FFT utilisant 4 unités DSP ... mais combien de cycles d'horloge faut-il par FFT? (débit, pas latence)? Disons 64, ou 1 cycle par point. Ensuite, vous devez effectuer ces 42 000 opérations Mac en 64 cycles - peut-être 1 000 MAC par cycle, chaque MAC gérant 42 opérations.

Il est maintenant temps de regarder le reste de l'algorithme plus en détail: identifiez non pas les MAC mais les opérations de niveau supérieur (filtrage, corrélation, etc.) qui peuvent être réutilisées. Construisez des cœurs pour chacune de ces opérations, avec une réutilisabilité (par exemple des filtres avec différents ensembles de coefficients sélectionnables) et bientôt vous trouverez peut-être relativement peu de multiplexeurs requis entre des cœurs relativement grands ...

De plus, une réduction de la résistance est-elle possible? J'ai eu quelques cas où des multiplications en boucles étaient nécessaires pour générer des quadratiques (et plus). En les déroulant, j'ai pu les générer itérativement sans multiplication: j'étais assez content de moi le jour où j'ai construit un moteur de différence sur FPGA!

Sans connaître l'application, je ne peux pas donner plus de détails, mais une telle analyse est susceptible de permettre certaines simplifications majeures.

En outre - comme il semble que vous n'ayez pas de plate-forme définie à l'esprit - demandez-vous si vous pouvez partitionner sur plusieurs FPGA ... jetez un œil à cette carte ou à celle qui propose plusieurs FPGA dans une plate-forme pratique. Ils ont également une carte avec 100 appareils Spartan-3 ...

(ps j'ai été déçu quand les gars du logiciel ont fermé cette autre question - je pense que c'est au moins aussi approprié)

Edit: re votre edit - je pense que vous commencez à y arriver. Si toutes les entrées du multiplicateur sont soit des sorties FFT, soit des coefficients "non filtrés", vous commencez à voir le type de régularité que vous devez exploiter. Une entrée de chaque multiplicateur se connecte à une sortie FFT, l'autre entrée à une ROM à coefficient (BlockRam implémentée sous forme de tableau constant).

Le séquençage de différentes opérations FFT via la même unité FFT séquencera automatiquement les sorties FFT au-delà de ce multiplicateur. Le séquençage des coefficients corrects dans l'autre entrée MPY consiste désormais «simplement» à organiser les bonnes adresses ROM au bon moment: un problème d'organisation plutôt qu'un énorme casse-tête de MUX.

Sur les performances: je pense que Dave Tweed était inutilement pessimiste - la FFT prenant n * log (n) opérations, mais vous pouvez choisir O (n) unités papillon et O (logN) cycles, ou O (logN) unités et O ( n) cycles ou toute autre combinaison adaptée à vos objectifs de ressources et de vitesse. Une telle combinaison peut rendre la structure de multiplication post-FFT beaucoup plus simple que d'autres ...


Une FFT implémentée avec un seul papillon matériel va nécessiter des cycles d'horloge NlogN pour se terminer; pour 512 points, ce serait 256 * 8 papillons, soit 2048 horloges. Cela signifie que les MAC 41210 (ou 32768?) Ne nécessiteraient que 8 à 10 multiplicateurs matériels pour se faire dans le même laps de temps.
Dave Tweed

Je veux dire, 16-20 multiplicateurs.
Dave Tweed

Désolé, je viens de réaliser que je l'ai fait à l'envers. Les FFT individuelles sont de 64 points, donc l'implémentation à papillon unique nécessitera 32 * 5 = 160 horloges. Les MAC peuvent ensuite être effectués avec des multiplicateurs matériels 200-250.
Dave Tweed

c'est ce qui me bloque. Comment xilinx peut-il concevoir un noyau capable de faire des fft 16k / 32k qui nécessitent des opérations de multiplication-ajout (NlogN) 400k et pourtant je rencontre des difficultés avec mon 41k? il doit y avoir un moyen!
stanri

@ Dave: Je pense que tu veux dire 160 multiplications, pas 160 cycles, sûrement? Il n'y a rien de si intrinsèquement sérialisé dans une FFT ...
Brian Drummond

2

Si ce problème n'a pas de contraintes en temps réel et qu'il semble que ce ne soit pas le cas - vous voulez juste qu'il s'exécute "plus vite", alors il semble qu'il pourrait être tout à fait adapté à l'accélération sur un ou plusieurs GPU. Il existe plusieurs bibliothèques de logiciels qui en font une proposition relativement simple, et ce serait environ un ordre de grandeur plus facile que d'aller directement au matériel FPGA personnalisé.

Il suffit de Google pour «bibliothèque compatible GPU» ou «bibliothèque accélérée par GPU» pour commencer.


Chose intéressante, j'ai mentionné les GPU au client lorsque j'ai entendu parler de ce projet, et il n'était pas intéressé.
stanri

@StaceyAnneRieck: At-il dit pourquoi?
Dave Tweed

Il n'a pas vraiment dit pourquoi, juste qu'il y avait réfléchi avant d'utiliser un FPGA semblait être moins de travail, apparemment. Je vais devoir en reparler.
stanri

@stanri: Même si vous vous retrouvez finalement dans une implémentation FPGA, il me semble que le GPU pourrait être un bon moyen de "tester" l'architecture globale du système. Avez-vous (et pourriez-vous partager?) Une sorte de graphique de flux de données de haut niveau pour l'algorithme, et pouvez-vous nous donner une idée de la quantité de données impliquées? Sans réponses à de telles questions, il sera très difficile de vous donner autre chose que des conseils très génériques.
Dave Tweed

C'est en fait un algorithme très très simple, c'est juste l'échelle qui le rend si compliqué. Fondamentalement, comme suit: conditions initiales -> 512 fft en parallèle -> 32768 multiplier les opérations sur la sortie FFT -> ajuster les conditions initiales -> rincer et répéter
stanri

1

Il est possible d'utiliser un matériel spécialisé ou un FPGA (ou même un CPLD) pour accélérer considérablement certains types d'opérations mathématiques. La chose clé à garder à l'esprit lorsque vous essayez de concevoir du matériel (circuits ou logique FPGA) pour accélérer les opérations mathématiques est de déterminer quel ordre les données devront entrer et sortir de votre appareil. Un périphérique avec une configuration d'E / S efficace peut offrir de bien meilleures performances qu'un périphérique avec une configuration inefficace, même si ce dernier périphérique nécessite beaucoup plus de circuits.

Je n'ai pas essayé d'élaborer une conception d'assistance matérielle pour une FFT, mais celle que j'ai examinée est l'assistance matérielle pour les opérations de multiplication à grande échelle (comme cela pourrait être utilisé pour le chiffrement RSA). De nombreux microcontrôleurs, même ceux dotés d'un matériel spécial à multiplication rapide, ne sont pas très efficaces dans de telles opérations car ils nécessitent beaucoup de réarrangement des registres. Un matériel conçu pour minimiser l'échange de registres pourrait obtenir de bien meilleures performances avec des opérations de multiplication multi-précision, même si le matériel lui-même n'était pas aussi sophistiqué. Par exemple, le matériel qui peut effectuer une multiplication 16xN en pipeline deux bits à la fois (décalage dans deux bits inférieurs de multiplcand et décalage de deux bits supérieurs de résultat) peut obtenir de meilleures performances que le matériel qui peut effectuer une multiplication 8x8 en un cycle, même si le premier peut prendre moins de circuits (et, en raison du pipelining, avoir un chemin de données critiques plus court). La clé est de comprendre à quoi ressemblera la "boucle intérieure" du code nécessaire et de déterminer s'il y a des inefficacités qui peuvent être facilement éliminées.


Quels types d'opérations sont particulièrement adaptés à cette forme d'optimisation? J'ai édité la question ci-dessus pour détailler un peu plus la nature de l'opération de multiplication. La conception assistée par matériel semble vraiment intéressante!
stanri

0

Comment peu d'un problème nous le temps d'exécution?

Cela semble vraiment une situation où vous devriez vraiment implémenter un soft-MCU, un FPGA avec un hard-MCU intégré, ou même un périphérique MCU séparé, et sérialiser toutes vos opérations.

En supposant que vous ayez le temps d'exécution, faire vos FFT dans un logiciel sera à la fois beaucoup plus facile à déboguer et probablement beaucoup plus simple à concevoir aussi.


1
Faire des calculs lourds dans un CPU soft core sur un FPGA est idiot; si vous allez faire le calcul dans une architecture de programme stockée (quelque chose qui devrait être pris en compte), en raison de cela sur des processeurs durs haute performance / dollar où vous ne payez pas la pénalité de vitesse de la logique flexible sur des fabriques comparables génération de logique dure.
Chris Stratton

@ChrisStratton - Bon point. Ajout d'une note supplémentaire à cet effet.
Connor Wolf

1
Même les processeurs durs intégrés ne résisteront pas aux processeurs / GPU conventionnels pour les tâches logicielles, et coûteront considérablement plus cher.
Chris Stratton

@ChrisStratton - Je pensais que les architectures de CPU intégrées les plus courantes étaient ARM ou POWER? Dans ce cas, il s'agit essentiellement d' un processeur standard.
Connor Wolf

1
Compte tenu de votre autre question sur le FPGA, la construction de la carte FPGA est susceptible d'être une expérience d'apprentissage qui coûtera un peu plus cher que prévu. Je pense que la chose à faire à ce stade serait de donner au client des chiffres de prix / performances durs à partir des exécutions de cloud de calcul d'essai (qui pourraient éventuellement devenir du matériel acheté), par rapport à une idée du prix plus élevé et du risque beaucoup plus élevé de l'effort FPGA .
Chris Stratton
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.