Comment identifier les zones d'une conception FPGA qui utilisent le plus de ressources et d'espace?


11

Je travaille sur une grande conception FPGA, et je suis très proche des limites de ressources du FPGA que j'utilise actuellement, le Xilinx LX16 dans le package CSG225.

La conception est également presque terminée, mais pour le moment, elle ne rentrera plus dans le FPGA. Je peux désactiver les pièces pour les adapter, mais je dois réduire l'utilisation des ressources afin de terminer la conception et de la faire respecter les exigences de calendrier et de taille.

J'aimerais savoir s'il existe des outils dans nos rapports qui peuvent m'aider à identifier les parties de ma conception qui consomment le plus de ressources. Ma conception n'est pas partitionnée et est répartie sur une douzaine de modules VHDL ou plus.

Les rapports de synchronisation Xilinx sont fantastiques, mais maintenant je dois savoir où je peux obtenir mon meilleur rapport qualité-prix en termes d'économie d'espace.

J'ai également du mal à dire de quel type de ressources je suis en train de manquer, ou quels effets ces ressources.

Un autre inconvénient est que, à mesure que la conception grossit, les composants utilisés pour respecter le calendrier commencent à échouer car leur placement n'est plus aussi idéal.

Actuellement, j'utilise les rapports de synchronisation Post-Place et Route Static et j'utilise SmartXplorer. J'utilise des stratégies de conception pour optimiser le timing.

Après avoir désactivé une partie de ma conception pour l'adapter, voici quelques résultats:

utilisation de registre de tranche: 42% utilisation de LUT de tranche: 96% nombre de paires LUT-FF pleinement utilisées: 38% Cela signifie-t-il que je suis léger sur les registres, mais lourd sur l'utilisation de la porte?

Existe-t-il des outils pour aider les développeurs à optimiser leur domaine, ou du moins à leur donner plus de détails sur leur code?

Mise à jour: Après avoir regardé l'utilisation du niveau du module, j'ai découvert que j'avais de petits fifos asynchrones de colle partout qui occupaient environ 30% du total des LUT. Je les utilise comme colle cross-clock-domain pour les bus à grande vitesse. Je devrais pouvoir les éliminer, car les horloges sont étroitement liées. (Entrée 120 MHz, produit 100 MHz et 200 MHz via DCM)


Il semble que vous ayez beaucoup d'interconnexions entre les signaux, je suis sûr que vous pouvez résoudre ce problème en modifiant les niveaux d'optimisation, de partage des ressources, etc. Quel outil utilisez-vous? ISE ou Vivado?
FarhadA

1
J'utilise ISE (Vivado ne prend pas en charge Spartan-6) J'ai posté cela sur les forums Xilinx, et ils ont dit d'activer le rapport détaillé de la carte. Je l'ai fait, et le fichier * .mrp contient maintenant la section 13 - Utilisation par hiérarchie. Je publierai les données une fois que je les aurai mieux formatées.
Marcus10110

Réponses:


5

J'ai croisé cette question sur le forum Xilinx ici: http://forums.xilinx.com/t5/Implementation/How-to-determine-what-part-of-the-design-consumes-the-most/td-p / 393247

Cette réponse est largement basée sur les commentaires qu'il contient. Merci à Deepika, Sikta et Gabor.

Tout d'abord, activez «Générer un rapport MAP détaillé» dans les propriétés du processus de carte (-détail).

Ensuite, ouvrez le résumé de la conception et accédez à Utilisation au niveau du module. Voici la hiérarchie complète, montrant l'utilisation exclusive et inclusive de la conception.

Chaque ligne affichera une paire de chiffres comme 0/5392. Cela signifie que ce module contient zéro de cet élément spécifique, mais ce module et tous ses sous-modules contiennent un total de 5392 éléments.

Voici ma sortie (partiellement développée) Rapport d'utilisation

Lorsque vous travaillez sur la réduction de la taille, Gabor recommande de passer à un FPGA plus grand dans les outils de synthé afin qu'il puisse complètement mapper même s'il est trop grand pour tenir dans votre FPGA actuel, et cela accélérera les outils.


3

On dirait que vous utilisez presque toutes les ressources logiques tout en utilisant seulement la moitié des registres. Il semble que vous ayez besoin de comprendre ce qui dévore toutes vos LUT. Il existe des moyens d'optimiser des composants particuliers et de les rendre un peu plus économes en espace - des choses comme les RAM, les registres à décalage et les machines à états. Regardez le fichier .log résultant du synthétiseur. Il vous dira quel type de composants sont déduits. Assurez-vous qu'il déduit correctement les composants. Si ce n'est pas le cas, il se peut qu'il ne génère pas de netlist particulièrement efficace. Vous pouvez en dire beaucoup en consultant les fichiers journaux de synthèse. Il est possible que quelques modifications mineures de votre code permettent au synthétiseur de déduire divers composants, alors jetez un œil au manuel du synthétiseur pour un modèle. Vous devrez peut-être basculer le synthétiseur pour optimiser la zone plutôt que la vitesse. Vérifiez également que les paramètres d'inférence ne sont pas désactivés. J'ai essayé une fois de synthétiser un composant de conception qui consommait 40% d'un Spartan 3E 500 (9 312 paires de LUT / FF à 4 entrées, 5,6 Ko de RAM de bloc) pour un Virtex 6 HXT 565 (354 240 paires de LUT / double FF à 6 entrées, 32 MB bloc RAM). Il a fallu 7 heures à Xilinx pour terminer et a pris environ 40% de la puce. ?!?!?!? Il s'avère que la RAM du bloc d'inférence a été désactivée, et le synthétiseur a transformé plusieurs Ko de RAM en LUT. Pas la décision la plus efficace de tous les temps. Après avoir modifié le paramètre, il occupait 1% de la puce. Allez comprendre. 312 paires LUT / FF à 4 entrées, 5,6 Ko de RAM de bloc) pour un Virtex 6 HXT 565 (354 240 paires LUT / double FF à 6 entrées, 32 Mo de RAM de bloc). Il a fallu 7 heures à Xilinx pour terminer et a pris environ 40% de la puce. ?!?!?!? Il s'avère que la RAM du bloc d'inférence a été désactivée, et le synthétiseur a transformé plusieurs Ko de RAM en LUT. Pas la décision la plus efficace de tous les temps. Après avoir modifié le paramètre, il occupait 1% de la puce. Allez comprendre. 312 paires LUT / FF à 4 entrées, 5,6 Ko de RAM de bloc) pour un Virtex 6 HXT 565 (354 240 paires LUT / double FF à 6 entrées, 32 Mo de RAM de bloc). Il a fallu 7 heures à Xilinx pour terminer et a pris environ 40% de la puce. ?!?!?!? Il s'avère que la RAM du bloc d'inférence a été désactivée, et le synthétiseur a transformé plusieurs Ko de RAM en LUT. Pas la décision la plus efficace de tous les temps. Après avoir modifié le paramètre, il occupait 1% de la puce. Allez comprendre.


3

Il serait intéressant de publier l'intégralité de la section «utilisation des ressources» à partir de la sortie de l'outil.

Utilisez-vous toutes les RAM de bloc? Il est courant de pouvoir remplacer les fonctions logiques / mathématiques par des tables de recherche RAM équivalentes si le domaine est suffisamment restreint et qu'elles sont suffisamment complexes pour être précalculées.

En plus de l'inférence de la mémoire, il en va de même pour les multiplicateurs. Parfois, un petit écart par rapport au modèle d'instanciation recommandé peut éliminer le multiplicateur déduit des unités DSP48A.

Si vous utilisez le contrôleur PCIe, pouvez-vous réduire l'espace tampon total réservé aux charges utiles TLP ou la taille maximale des paquets TLP? Cela peut réduire l'utilisation RAM / logique du cœur IP au détriment de la bande passante bien pensée / totale.

Avec (Altera) Quartus, vous pouvez sélectionner plusieurs éléments dans la vue de la hiérarchie de conception et y voir un code couleur / cluster pour l'utilisation de la zone post-p & r. Cela peut donner une idée visuelle de l'utilisation relative de vos modules de conception.


Merci. J'utilise les macros IP dures pour les multiplicateurs et j'ai utilisé CoreGen pour créer les FIFO, bien que j'aie sélectionné certaines des petites fifos pour utiliser la RAM distribuée (au lieu de la RAM de bloc). Je vais examiner leur utilisation.
Marcus10110
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.