First FPGA project ideas

I decided recently that I want to really learn computer hardware design. Not just the theoretical “I know how the machine works” understanding, but actually having done it. So, the obvious thing was to get an FPGA and design stuff using it. fpga4fun was some of the inspiration for this. I ended up ordering one of their Cyclone II boards after deciding that I was going to play with the Altera stuff (Xilinx has comparable parts. For more sources of FPGA dev boards, see Sparkfun(only one), Digilent, and XESS.) The Altera software (Quartus II) seemed a little bit less obtuse. Otherwise I can’t say I found myself strongly in favor of one or the other. As for Verilog versus VHDL, I’m learning Verilog because it’s more readable, and more commercially popular (at least in the USA). Once I understand what I’m doing, I’m sure I can learn VHDL later.

Over the weekend, I’d been playing with the free version of Altera’s Quartus II software, writing a bit of Verilog and seeing what it compiles into. The Cyclone II EP2C5 is a reasonably capable part — 4608 “Logic Elements” (each is a 4-input lookup table — 4 bits in, 1 bit out, any truth table), carry chain logic, a register on the output, various stuff to connect it locally, across the chip, and to the clock distribution network), 119808 bits of ram in “block ram” scattered about the chip, 13 18×18 multipliers, and 2 PLLs for clock generation.

So, I got to thinking that a suitably hard project is a modern reimplementation of the 1980s home computer / game console. This would consist of a number of subprojects:

  • a CPU — probably early MIPS, R2000/R3000 or something. a subset of MIPS32. Not too hard to understand, I still have the Patterson and Hennessy textbook that gave a pretty nice introduction to it. Also, existing GCC support.
  • SDRAM controller — having looked at a datasheet, supporting a single 4Mx16 SDRAM chip shouldn’t be that hard.
  • Display controller. Low-color-depth VGA wouldn’t be too hard, but then I’d constantly have to hook a VGA monitor up, etc. A more interesting choice seems to be to support one these Sharp LCDs
  • SPI interface to an SD card. Have the first stage bootloader in the FPGA block ram load code from here into the SDRAM.
  • USB low-speed host controller, really only supporting keyboard/mouse/joystick. Another challenging piece, but not that bad
  • Serial port for debugging software.
  • Sound controller. Maybe an all-digital implementation of the SID in a C-64, or maybe the much simpler sound chip found in the TI 99/4a, IBM PC Jr., Sega Master System, etc.

So far, I’ve written Verilog for parts of a 3 voice + 1 noise sound chip (the simple one above), and I’ve implemented a register file and an ALU. Most importantly, I figured out how to use the right idioms to make the register file out of block ram, instead of consuming a quarter of all the logic elements on the chip.

But, wow, that’s a big first project. While I can design and test it piece by piece, I think it might be more fun to start out with something simple: A 16 bit stack-based CPU, interfaced to the on-board block ram (only about 13K bytes), with a serial console. I’ll have to cobble together some sort of assembler, but that’s not that hard. Especially when the instruction set is simple. I’ve been reading Stack Computers for inspiration.

Another possibility, instead of a stack CPU is some kind of stripped-down mips-like 16 bit architecture. You get into some compromises with 16 bit instructions if you want a reasonable number of instructions and the usual 3-operand instruction format, though.

(For more links, see my del.icio.us.)

5 Comments

  1. Abhishek Shrestha
    Posted July 10, 2008 at 4:04 am | Permalink

    Thanks, it would be better to get some more ideas

  2. Michael
    Posted December 11, 2008 at 9:16 am | Permalink

    I built a 16 bit CPU a couple of years ago. It is similar to Tanenbaum’s in his Architecture book, but the microcode is all original. The machine is stack based because I have a friend who loves Forth. The only advice I have is you will need a way to debug a running system. In my case, I came up with a single clock step (not single instruction step) and I provided an external mechanism which allowed me to set switchs to output the value of any register (programmer visible or not) to the 7 segment LED’s on my Digilent board. This step was invaluable.

  3. Michael Magin
    Posted December 11, 2008 at 9:44 am | Permalink

    Yes, I expect to spend some time debugging the hardware. So far, I have a simulator on my computer working, so I can write an assembler and a forth. I expect that I’ll need to instrument the real hardware pretty well to debug any hardware issues. I expect to learn a bit about what Altera lets you do via the JTAG interface and their design software — I know it can instantiate a pseudo-logic-analyzer to inspect what’s going on in your design. (Admittedly taking up some space in the FPGA, but with this FPGA, a simple 16 bit CPU shouldn’t take up too much space.)

    Though, for more software level debugging, I’ll probably just load some minimal code that lets me inspect/manipulate memory on the running system via a serial port. (and eventually from there to a full interactive forth session on the target.)

  4. Posted July 13, 2009 at 8:01 pm | Permalink

    Mike, that’s a very interesting project. I always wanted to do something with the LCD’s.
    If you are willing to share the verilog code for the sharp LCD’s please mail’em to me. Thanks a lot.

  5. Neo Cambell
    Posted November 4, 2009 at 8:06 am | Permalink

    Very good starting points…

    Neo
    http://www.expertcore.org

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*