Project Orac: Reviving the Illiac IV's Vector Processing Architecture for Modern AI Workloads

This project aims to systematically reverse-engineer the Illiac IV's processing element (PE) array and control unit, then simulate its behavior on modern FPGAs. By implementing key algorithms from the 1970s (matrix multiplication, FFT, sorting) alongside modern neural network layers (convolutions, transformers), we can benchmark whether the Illiac's approach to fine-grained parallelism offers any power or throughput advantages over today's GPUs. The project will produce a documented open-source simulator, a set of optimized kernel implementations, and a white paper analyzing the architecture's relevance to AI. We target a proof-of-concept that runs a small convolutional neural network on a FPGA-based emulation of a 32x32 PE array, achieving competitive performance per watt.

Modern AI accelerators (GPUs, TPUs) are massive, power-hungry monolithic chips. The Illiac IV, though limited in 1972, used a distributed array of simple processors with local memory—each PE was a complete but tiny computer. This design granted extreme scalability and fault tolerance, but was abandoned due to programming complexity. Today's AI workloads demand high throughput for small operations (e.g., 8-bit quantized convolutions), exactly the kind of fine-grained parallelism the Illiac excelled at. By revisiting its architecture with modern fabrication (28nm FPGA), we may uncover a low-power alternative to massive SIMD cores for edge AI.

• Build a cycle-accurate simulator of the Illiac IV PE array in C++/SystemC.
• Implement a Verilog model of a single PE and scale to a 32x32 array on a Xilinx FPGA.
• Port 3 classic Illiac programs (matrix multiply, 2D FFT, particle simulation) to the simulator.
• Implement a small CNN (LeNet-5) on the FPGA emulation, quantized to 8-bit.
• Measure power consumption vs. a Jetson Nano running the same CNN.
• Publish a paper analyzing the architectural lessons for modern AI accelerators.

• Not building a production AI chip.
• Not creating a fully general-purpose processor; the focus is strictly SIMD.
• Not optimizing compilers; we will hand-craft assembly for the PE array.
• Not including a full memory hierarchy; we assume external SRAM for program/data.

• Verilog/SystemVerilog for FPGA design
• Xilinx Vivado for synthesis and implementation
• Python for test automation and data analysis
• C++ for cycle-accurate simulation
• Xilinx VCU118 FPGA board (Virtex UltraScale+)
• Power measurement tools (e.g., TI INA226 sensor)
• Academic papers: Illiac IV documentation, Barnes and Rutenbar 1976 microarchitecture details

The Illiac IV PE array was a 64x64 grid of simple processors, each with 2K words of local memory, connected to its four neighbors. The control unit broadcast instructions to all PEs simultaneously—true SIMD. Our emulation will replicate this with modern twist: 32x32 PE array on a single FPGA, each PE implemented as a small custom CPU with an ALU, 256 bytes of local memory, and a network interface. The control unit will be a simplified RISC-V core that issues vector instructions over a broadcast bus. Inter-PE communication uses a 2D torus with configurable routing. We'll build a specialized assembly language (ILLASM) for writing kernels, then assemble to raw control vectors. The FPGA will run at 100 MHz, with a host PC loading programs via UART.

• The Illiac IV's 64-bit word and 48-bit floating point are overkill; re-adapting to 8-bit integer may lose architectural essence.
• FPGA resource limits: 32x32 PEs may not fit on a single mid-range FPGA; may need to reduce to 16x16.
• Programming complexity: writing hand-optimized SIMD code for an obscure architecture is time-consuming.
• Lack of original documentation: some control unit details are lost; educated guesses required.

• Can the Illiac's routing mesh keep up with modern convolution dataflows?
• Is the overhead of local memory (per PE) worth it compared to shared memory in GPUs?
• What is the optimal PE count for edge inference: 16x16 or 32x32?
• How to handle non-uniform computations (e.g., varying filter sizes) in a lockstep SIMD model?

The project was conceived as a side interest during a sabbatical, but the researcher's day job priorities shifted. The FPGA board and timeline were in place, but the kernel implementation hit a wall when the original Illiac IV documentation proved harder to obtain than expected. Life moved on, and the plan remains on a GitHub wiki as a detailed what-if.

This research could also inform energy-efficient architectures for space or medical implants. The open-source simulator would be a unique resource for computer architecture courses. If successful, it might inspire a new class of ultra-low-power AI accelerators for IoT.