fpga_torture
Initial release
Il s'agit d'une conception simple qui permet d'utiliser le Stress-Test FPGA en consommant toutes les ressources logiques disponibles (LUTS + FFS). La conception implémente un Galois LFSR modifié pour générer beaucoup d'activité de commutation "chaotique" / consommation d'énergie dynamique pour également les alimentations FPGA de test de contrainte.
La plupart des concepts pour tester les exigences d'utilisation / puissance maximum utilisent un simple registre de quart de travail où chaque FF (flip flop / registre) bascule à chaque cycle. Ces types de concepts sont entièrement basés sur FFS mais fournissent également une activité de commutation maximale (dans le FFS uniquement). fpga_torture est également basé sur la consommation de tous les FF disponibles. De plus, il comprend également tous les LUT disponibles (tables de recherche) pour utiliser toutes les ressources logiques à usage général du FPGA pour produire un cas d'utilisation plus réaliste. De plus, l'activité de commutation résultante est plus chaotique (pas de basculement monotone) offrant également un comportement plus réel.
Le code VHDL fournit une description agnostique de la technologie, qui n'utilise aucune primitive, attributs ou autres éléments spécifiques à un appareil / plate-forme. Il a été testé sur les FPGA de réseau (Radiant, Sinplifypro) et Intel (Quartus prime).
La conception fpga_torture est basée sur une chaîne de registre, qui implémente essentiellement un Galois LFSR modifié "circulaire" (registre de changement de rétroaction linéaire). La taille de la chaîne est définie par les conceptions NUM_CELLS générique. Chaque cellule se compose d'un FF et d'un LUT. Le LUT en position de chaîne I utilise les sorties des trois FFS précédents pour calculer la valeur suivante du FF de la cellule:
chain(i) <= combine_f(chain(i-3), chain(i-2), chain(i-1));
Un XOR logique de toutes les entrées est utilisé comme fonction de combinaison ( combine_f() ).
Vue technologique (découpe, Quartus Prime): calcul de la valeur suivante pour chain[6] via un seul LUT en utilisant les états des trois précédents registres chain[3] , chain[4] et de chain[5] et de les combiner via XOR:
Le début de la chaîne utilise un FF supplémentaire, qui bascule chaque cycle d'horloge pour "démarrer" la chaîne. Après une courte "initialisation", la chaîne oscille de manière pseudo-aléatoire générant une activité de commutation chaotique très élevée et une consommation d'énergie dynamique.
L'entité supérieure est rtl/fpga_torture.vhd :
entity fpga_torture is
generic (
NUM_CELLS : positive -- number of LUT3+FF elements
);
port (
clk_i : in std_ulogic ; -- clock input
rstn_i : in std_ulogic ; -- low-active async reset
out_o : out std_ulogic -- dummy output (LED or unconnected FPGA pin)
);
end fpga_torture ; Le signal de réinitialisation rstn_i est facultatif si le FPGA cible prend en charge l'initialisation FF via Bitstream. Dans ce cas, le signal rstn_i peut être lié à 1 . Le signal de sortie out_o est nécessaire pour empêcher l'outil de synthèse de supprimer toute la logique de conception. Connectez ce signal à une broche de sortie FPGA non critique comme une LED ou une broche FPGA non connectée.
Simuler / tester la configuration de NUM_CELLS à l'aide du TestBench avant de faire de la synthèse. Certaines valeurs NUM_CELLS (comme 32) entraînent une activité de commutation maximale (tous les FFS bascutent dans chaque cycle).
Les projets fournissent un test simple ( sim/fpga_torture_tb.vhd ), qui peut être simulé par ghdl via le script fourni ( sim/ghdl.sh ):
fpga_torture/sim$ sh ghdl.sh
La simulation fonctionnera sur 1 ms à l'aide d'une horloge de 100 MHz. Les données de forme d'onde sont stockées sur sim/fpga_torture.vcd afin qu'elle puisse être consultée à l'aide de gtkwave :
fpga_torture/sim$ gtkwave fpga_torture.vcd
La taille totale de la chaîne est définie par le générique NUM_CELLS . La conception nécessitera NUM_CELLS+1 FFS (registres) et NUM_CELLS+2 LUT3S (tables de recherche, 3 entrées chacune). Certains FPGA / chaînes d'outils pourraient également introduire des LUT de route supplémentaires.
Exemple de cartographie: Lattice iCE40UP5K-UWG30ITR FPGA, Sinplifypro, NUM_CELLS = 5278
Number of slice registers: 5279 out of 5280 (100%)
Number of I/O registers: 0 out of 63 (0%)
Number of LUT4s: 5280 out of 5280 (100%)
Number of logic LUT4s: 5280
Number of ripple logic: 0 (0 LUT4s)
Number of IO sites used: 3 out of 21 (14%)
Number of Clocks: 1
Net clk_i_c: 5279 loads, 5279 rising, 0 falling (Driver: Port clk_i)
Number of LSRs: 1
Net rstn_i_c_i: 5279 loads, 5279 SLICEs
