Die richtige FPGA-Codierung wählen: Eine praxisnahe Studie mit Conways Game of Life

Drei Experimente veranschaulichen, wie man die geeignetste Codierung für ein FPGA-Design wählt.

Beim Design von FPGA-Logik wählt das Synthese-Tool typischerweise die Codierung; es ist generell am besten, seiner Entscheidung zu vertrauen. Doch das Verständnis der Nuancen von Binary-, Gray- und One-Hot-Darstellungen kann helfen, vorherzusehen, wann der Compiler eine der anderen bevorzugen könnte.

Dieser Artikel führt durch ein praktisches Experiment, das Conways Game of Life als Testbench nutzt, und beleuchtet die Trade-offs, die entstehen, wenn jede Codierung auf ein großes Array von Finite-State-Machines angewendet wird.

In dieser Serie haben wir FSM-Konstruktion in Verilog, den Einfluss von Initialzuständen und Speicher auf Codierung, und einen High-Level-Vergleich von Binary-, One-Hot- und Gray-Schemata behandelt.

Das System Under Test

Um Hardware-Unterschiede zu vergrößern, instanziierte ich eine Zustandsmaschine dutzendfach über ein 23×23-Gitter, was einen direkten Vergleich von Binary-, Gray- und One-Hot-Codierungen ermöglichte.

Conways Game of Life ist ein klassischer zellulärer Automat, der Geburt, Überleben und Tod von Zellen auf einem rechteckigen 2D-Gitter modelliert. Jede Zelle folgt in jedem Zyklus drei einfachen Regeln:

1. Lebende Zellen mit zwei oder drei lebenden Nachbarn überleben.
2. Tote Zellen mit drei lebenden Nachbarn werden lebendig.
3. Alle anderen Zellen sterben oder bleiben tot.

Diese Regeln erzeugen eine reiche Vielfalt emergenter Muster und bieten eine saubere, gut verstandene Workload für die Evaluierung von Codierungsstrategien.

Unten sehen Sie ein GIF von Bill Gospers Glider Gun, einem populären Muster im Game of Life.

Eine Variation von Conways Game of Life, bekannt als Bill Gospers Glider Gun. GIF erstellt von Lucas Vieira [CC BY-SA 3.0]

Verilog Code

Die Zellenlogik wird als 8-Zustands-FSM modelliert. Obwohl die Game-of-Life-Berechnung pro Zelle in einem Zyklus abgeschlossen ist, erzeugt das 8-Zustands-Design einen spürbaren Unterschied zwischen den Codierungen. Das folgende Verilog-Modul demonstriert die originale Binary-Codierung.

`define STATE_0 3'b000
`define STATE_1 3'b001
`define STATE_2 3'b010
`define STATE_3 3'b011
`define STATE_4 3'b100
`define STATE_5 3'b101
`define STATE_6 3'b110
`define STATE_7 3'b111

module LifeCell( input clk, input nrst, input seed, input [7:0] neighbors, output reg alive);
reg [2:0] state;
always @ (posedge clk) if (nrst == 0) state <= `STATE_0; else case(state) `STATE_0: begin // ... state <= `STATE_1; end `STATE_1: begin // ... state <= `STATE_2; end // ... `STATE_7: begin // ... state <= `STATE_1; end endcase endmodule

Für einen tieferen Einblick in den Code ist das vollständige Projekt auf GitHub verfügbar.

FPGA-Codierungs-Implementierungen

Das Design wurde auf einem 23×23-Zellen-Grid synthetisiert, was 27 distincte Implementierungen ergab: drei FSM-Varianten, jeweils kompiliert mit Binary-, Gray- und One-Hot-Codierung, auf drei Ziel-FPGAs.

FSM #1: Originalmodell

Dieser FSM führt einen Initialzustand einmal aus, dann zyklisch durch die verbleibenden sieben Zustände – eine Sequenz, die suggerierte, dass Gray-Codierung vorteilhaft sein könnte.

FSM #2: Eine Sequenz

Als simpler 3-Bit-Counter agierend, verstärkte dieser FSM die Erwartung, dass Gray-Codierung dominieren würde.

FSM #3: Ein willkürliches Gewirr

Diese Variante teilt den Critical Path von FSM #1, nimmt aber einen nicht-linearen Pfad, wenn die Nachbaranzahl drei übersteigt. One-Hot-Codierung schien die natürliche Wahl für solche irregulären Transitionen.

Zielarchitekturen

Die Implementierungen wurden mit den Vendor-Toolchains für folgende Devices gebaut:

• Xilinx Vivado Suite auf Artix-7 FPGA
• Intel Quartus Prime auf Cyclone-V FPGA
• Lattice Diamond auf LatticeXP2 FPGA

Vergleich der Ergebnisse

Benchmarking von FPGA-Designs ist inhärent metrisch getrieben. Ich wählte vier Schlüsselindikatoren – Logic Resource Usage, Register Count, geschätzte Maximum Frequency und On-Chip Power – und wies gewichtete Scores zu. Der Beste in jeder Metrik erhielt +1 (oder +2 für gewichtete Metriken), der Schlechteste -1 (oder -2), der Mittlere 0.

• Logic Units: LUTs (Xilinx/Lattice) oder ALMs (Intel). Gewicht 1.
• Registers: Gewicht 1.
• Maximum Frequency: Gewicht 2.
• On-Chip Power: Gewicht 2.

Die kumulierten Scores für jede der 27 Implementierungen sind unten dargestellt.

Ergebnistabelle für alle 27 Implementierungen. Grün markiert die beste Codierung, Rot die schlechteste, Gelb den Median (keine Unentschieden).

Über alle Boards hinweg erscheint One-Hot-Codierung in den unteren zwei Reihen, mit nur zwei Instanzen von Parität mit anderen Schemata. Im Gegensatz dazu taucht Gray-Codierung konsistent als Top-Performer auf, besonders wenn Frequenz und Power höher gewichtet sind.

Um die Gewinner hervorzuheben, isoliert die folgende Tabelle die führende Codierung für jede Variante.

Das Urteil

Während die Daten für diese spezifische Game-of-Life-Workload zu Gray-Codierung tendieren, hängt das Ergebnis davon ab, welche Metriken Sie priorisieren. Wenn Sie Resource Usage über Performance stellen, kann ein anderes Ranking auftauchen. Mein Ziel ist nicht, eine One-Size-Fits-All-Regel zu verschreiben, sondern zu illustrieren, wie empirische Evidenz Codierungsentscheidungen leiten kann.

Fühlen Sie sich frei, den Source Code, die 27 synthetisierten Implementierungen oder die Live Game-of-Life-Simulation im GitHub-Repository des Projekts zu erkunden.