Choosing the Right FPGA Encoding: A Hands‑On Study with Conway’s Game of Life

Follow three experiments that illustrate how to choose the most suitable encoding for an FPGA design.

When designing FPGA logic, the synthesis tool typically selects the encoding; it’s generally best to trust its decision. However, understanding the nuances of binary, Gray, and one‑hot representations can help you anticipate when the compiler may favor one over the others.

This article walks through a practical experiment that uses Conway’s Game of Life as a testbench, highlighting the trade‑offs that emerge when each encoding is applied to a large array of finite‑state machines.

In this series we’ve covered FSM construction in Verilog, the impact of initial states and memory on encoding, and a high‑level comparison of binary, one‑hot, and Gray schemes.

 

The System Under Test

To magnify the hardware differences, I instantiated a state machine dozens of times across a 23×23 grid, allowing a direct comparison of binary, Gray, and one‑hot encodings.

Conway’s Game of Life is a classic cellular automaton that models the birth, survival, and death of cells on a rectangular 2‑D lattice. Each cell follows three simple rules in each cycle:

1. Living cells with two or three living neighbors survive.
2. Dead cells with three live neighbors become alive.
3. All other cells die or remain dead.

These rules give rise to a rich variety of emergent patterns, and they provide a clean, well‑understood workload for evaluating encoding strategies.

Below is a GIF of Bill Gosper’s Glider Gun, a popular pattern in the Game of Life.

A variation of Conway’s Game of Life, known as Bill Gosper’s Glider Gun. Gif created by Lucas Vieira [CC BY‑SA 3.0]

 

Verilog Code

The cell logic is modeled as an 8‑state FSM. Although the Game of Life’s per‑cell computation completes in a single cycle, the 8‑state design creates a noticeable difference across encodings. The following Verilog module demonstrates the original binary encoding.

 

`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

If you’d like a deeper dive into the code, the full project is available on GitHub.

 

FPGA Encoding Implementations

The design was synthesized on a 23×23 cell grid, resulting in 27 distinct implementations: three FSM variants, each compiled with binary, Gray, and one‑hot encodings, across three target FPGAs.

 

FSM #1: Original Model

This FSM runs an initial state once, then cycles through the remaining seven states—a sequence that suggested Gray encoding might be advantageous.

 

 

FSM #2: A Sequence

Acting as a simple 3‑bit counter, this FSM further reinforced my expectation that Gray encoding would dominate.

 

 

FSM #3: An Arbitrary Tangle

This variant shares the critical path of FSM #1 but takes a non‑linear route when the neighbor count exceeds three. One‑hot encoding seemed like the natural fit for such irregular transitions.

 

 

Target Architectures

The implementations were built with the vendor toolchains for the following devices:

• Xilinx Vivado Suite on an Artix‑7 FPGA
• Intel Quartus Prime on a Cyclone‑V FPGA
• Lattice Diamond on a LatticeXP2 FPGA

 

Comparing the Results

Benchmarking FPGA designs is inherently metric‑driven. I chose four key indicators—logic resource usage, register count, estimated maximum frequency, and on‑chip power—and assigned weighted scores to each. The best performer in each metric earned +1 (or +2 for the weighted metrics), the worst received –1 (or –2), and the middle received 0.

• Logic Units: LUTs (Xilinx/Lattice) or ALMs (Intel). Weight 1.
• Registers: Weight 1.
• Maximum Frequency: Weight 2.
• On‑Chip Power: Weight 2.

The cumulative scores for each of the 27 implementations are shown below.

Results table for all 27 implementations. Green highlights the best encoding, red the worst, and yellow the median (no ties).

Across the board, one‑hot encoding appears in the bottom two rows, with only two instances of parity with other schemes. In contrast, Gray encoding consistently emerges as the top performer, especially when frequency and power are weighted more heavily.

To highlight the winners, the table below isolates the leading encoding for each variant.

The Verdict

While the data lean toward Gray encoding for this particular Game‑of‑Life workload, the outcome depends on which metrics you prioritize. If you value resource usage over performance, a different ranking may surface. My goal here is not to prescribe a one‑size‑fits‑all rule but to illustrate how empirical evidence can guide encoding choices.

Feel free to explore the source code, the 27 synthesized implementations, or the live Game‑of‑Life simulation on the project’s GitHub repository.