Comment by wildzzz
5 days ago
I remember working on a project like that in my Digital Design II class. We built a VGA driver to display a chessboard but the real challenge was that we couldn't use a framebuffer, that would have been too easy. We had to build a logic circuit to display the chessboard, a piece on the board (a bitmap), and then use inputs to move the chess piece around. We also used the ARM processor onboard the Cyclone FPGA to run Linux where we wrote a program in C to send board positions to that chessboard logic circuit.
It was kinda hard and I struggled a bit but got it working in the end.
I did a LabVIEW project to run on an FPGA in a college extracurricular. LabVIEW is capable of taking your serial CPU code and cross-compiling it for FPGA but I wrote mine in actual FPGA style with everything being parallel and impressed everyone with the compile/synthesis speed (still 5 minutes instead of 30 minutes) and low area use. Also people thought it was impressive I could control our SPI peripherals with only two virtual toggle switches... their learned helplessness I suppose, it's a dead simple protocol.
Writing code in everything-parallel style takes a different mindset but you can certainly get used to it. Do not fall victim to the trap of learned helplessness. If you can make something in Logisim-NG then you can program an FPGA.
Unfortunately the standard languages for FPGA are ones derived from simulators that run sequentially on CPUs, so for the most part people are writing sequential imperative code and the compilers are pattern-matching for things that can run in parallel. That's why writing VHDL or Verilog is universally a fairly miserable experience. To make it work, you have to think backwards from the compiler - think of the circuit you want to implement, then how to template-expand it into code the compiler can pattern-match.