Most "sensor to screen" demos hide a microcontroller doing the work. I wanted to do it the hard way: bridge an ADXL345 accelerometer to a 640×480 @ 60 Hz VGA display on an Intel MAX10 FPGA with no soft-core processor — just register-transfer logic. Tilt the board and the on-screen graphics and colors respond live.
No CPU, just RTL
The whole system is SystemVerilog: an 11-module design across four subsystems with 58 top-level port signals. Without a CPU there's no firmware to lean on — every behavior is an explicit state machine running in parallel hardware. It forces a different, sharper way of thinking about a problem.
Talking to the sensor
I wrote a custom SPI master controller and FSM to configure the ADXL345 and continuously stream X-axis tilt data. No library, no abstraction layer — just the protocol, timed correctly in hardware.
Three clocks, one system
The trickiest part: the system runs on three clock domains — 50 MHz logic, 2 MHz SPI, and 25 MHz VGA — generated by two PLLs. Moving data between clocks naively causes metastability and corruption, so I handled clock-domain crossing deliberately. CDC is exactly where subtle hardware bugs live.
Closing the loop
Finally, a feedback loop: extreme tilt (shown on a 10-bit LED array) triggers dynamic RGB color changes on the VGA output, with a parallel 7-segment readout. Input to pixels, entirely in silicon.
What I took away
- Clock-domain crossing deserves real respect — design for it, don't discover it.
- No-CPU forces parallel thinking — everything is a concurrent state machine.
- Timing is a first-class constraint, not an afterthought.
Being comfortable down at the hardware level changes how I reason about software too — about latency, concurrency, and what's really happening under the abstraction.