Cornell's Enigma project: FPGA computation and interface costs
The Cornell demonstrator combines C on HPS with Verilog computation; its resource report makes the control interface as important as the accelerator.
Audience and applicability
For engineers dividing a task between an SoC processor and FPGA logic. The project offers a concrete example of selecting the transfer boundary and checking interface cost before planning more parallel compute units.
Where the hardware/software boundary sits
Erica Jiang, Kelvin Resch and Isabella Frank built this Spring 2026 Cornell ECE 5760 project as an educational system inspired by Enigma and the Bombe. The C program on HPS handles user interaction and orchestration; computational work runs in Verilog on the FPGA. Communication uses Avalon PIO. The report describes nested state machines, data structures shared across software stages and lookup tables moved into M10K memory.
Their partition avoids returning every intermediate candidate to the processor. More filtering remains in programmable logic, and the software exchanges larger units of work. The engineering point is the frequency and size of transfers across the processor/FPGA boundary; it is not a general claim that moving a complete algorithm into hardware is always faster.
The interface has a resource cost
| Property | Reported value | Condition |
|---|---|---|
| Demonstration clock | 25 MHz | Chosen for the final demonstration; no complete frequency analysis |
| Compute module | About 4,700 ALM | The reported Bombe module named alan |
| PIO | About 7,000 ALM | The authors identify it as the largest logic consumer |
The report gives approximate resource counts. They are not a new FPGA.camp measurement or a controlled CPU/FPGA speed comparison.
Data sourceLookup arrays initially became large multiplexers. Moving tables to M10K and changing the interface reduced logic use, yet the PIO remained a major part of the design. Additional parallel solvers were a proposed extension: the authors did not finish the top-level manager. Resource arithmetic alone therefore does not establish a working parallel implementation.
What can be carried into another SoC project
- Measure the rate and payload size of processor/FPGA exchanges before selecting the hardware partition.
- Inspect the implemented cost of control and data interfaces alongside the compute module. A replicated datapath does not remove a shared interface bottleneck.
- Check how lookup tables map to memory or logic, then re-run utilization and timing after changing their representation.
- Treat proposed parallel units as a separate integration task: scheduling, shared-memory access and result collection still need verification.
Artifacts and historical limits
The primary report links public Google Drive pages for the Verilog and C archives, plus course demonstration videos. We did not establish a project GitHub repository or a reuse license for those archives. Permission printed in the appendix covers the course website and YouTube channel; it is not a general license for republishing the authors' figures. This review uses an original diagram.
The Hackaday title compares the project with Bletchley Park. The authors describe an algorithmic educational implementation rather than a faithful mechanical reconstruction, and explicitly say that the diagonal board was not implemented. The National Museum of Computing identifies the historical Turing–Welchman Bombe as an electromechanical machine and explains the diagonal board's role. The report also leaves full frequency characterization and broader benchmark evaluation unfinished. FPGA.camp has not reproduced the hardware experiment.
Sources
Cornell: primary project report