BMOW title
Floppy Emu banner

FPGA Research

Over the past few days I’ve done a huge amount of reading about both 3D graphics hardware and FPGAs, and I’m starting to get a better picture in my mind of how this 3D Graphics Thingy might be built. My surprising conclusion is that 3DGT may not require any custom hardware at all, but could be entirely implemented using an off-the-shelf FPGA development board. This is either good or bad, depending on your point of view.

Looking back at my earlier “construction notes” posting, I described a vision of 3DGT as a single-board computer with a CPU, FPGA, RAM, ROM, keyboard, USB, and VGA output. That more or less exactly describes an FPGA development board. All the work would then go into creating the HDL for the graphics pipeline, which would be programmed into the FPGA, turning 3DGT into a mostly firmware project. There would still be a few missing hardware pieces when using an FPGA development board, however:

  • CPU – I still need a CPU to drive the graphics pipeline, and determine what to draw. Some high-end FPGAs actually have a CPU built-in, but those are out of my price range. My first approach will be to embed a “soft CPU” into the FPGA along with everything else. Xilinx provides a PicoBlaze 8-bit soft CPU that only consumes about 5% of the space in a Spartan 3 FPGA. There’s also the OpenRISC soft CPU from OpenCores.org, if something more powerful is needed. And if a soft CPU doesn’t work out, I can add a real CPU on a daughter card, attached to the development board’s expansion connector.
  • VGA – There are lots of development boards with integrated VGA hardware. However, the cheaper boards are all limited to a few bits per color channel. The best I’ve seen is 4:4:4 12-bit color. That will be great for initial testing, but ultimately I’ll need to add a separate 8:8:8 video DAC on a daughter card.
  • Joystick, etc – Connecting a gamepad will require a bit of custom hardware, also on a daughter card. Any sound hardware would need to be external to the daughter board too. For initial testing, I can use the built-in keyboard connection.

I like where this is going, although it’s a lot less hardware-oriented than I’d initially expected. Essentially, I can purchase an FPGA development board and get started immediately, using a soft CPU, low bit-depth VGA, and keyboard input. Once the guts of the graphics pipeline are mostly working, I can expand by adding a daughter card with a CPU, video DAC, gamepad connector, etc. For the final version I might create a custom single-board PCB for exactly the hardware I need, and ditch the development board, or just keep the development board + daughter board as the final hardware.

The development boards I’m considering are Xilinx’s Spartan-3E Starter Kit and Spartan-3A Starter Kit. These seem to be the best fit as far as including the parts I need, without a lot of other parts I don’t need, or costing a million dollars. There’s also a wealth of information and tutorials online about how to use these boards, from Xilinx and third parties.

Both boards include the FPGA, 32MB RAM, 16 or 32MB Flash ROM, VGA, USB, PS/2 keyboard input, two serial ports, ethernet, and a two-line LCD. I don’t need the serial ports or Ethernet, of course, but there they are. Both kits come with 50MHz clock oscillators built-in, but I couldn’t find any data on their maximum possible speeds, or the speed grades of the specific FPGAs.

  • 3E – The $149 3E is the older board, with a XC3S500E sporting 10476 logic cells, 360K bits of block RAM, and 20 dedicated multipliers. The major drawback is that the VGA output is 1:1:1, allowing for just 8 colors. That would let me work on triangle rasterization, but not color interpolation or texturing. If I ever want to ditch the development board and make a custom PCB, though, the 3E kit is the way to go. The exact same FPGA is available from Sparkfun in a breakout board, as well as from other vendors, or it can also be purchased as a bare IC with leads that I can solder myself.
  • 3A – The $189 3A is the newer board, hosting a XC3S700A. The 3A has 13248 logic cells, 360K bits of block RAM, and 20 dedicated multipliers. The larger number of logic cells is nice, but the big advantage of this kit is the 4:4:4 VGA interface, enabling 4096 colors. The drawback is that if I later want to drop the development board and make a custom PCB, it’ll be difficult to do without switching away from the 3A. It’s only available in a leadless BGA package that I can’t hand-solder, and I haven’t found any 3A breakout boards or adapters advertised online.

Along with all this research into the development hardware, I also did some reading about other similar 3D graphics FPGA projects, hoping I might learn from them. Maybe I didn’t dig hard enough, but I didn’t find much, and what I did find were all unfinished projects:

  • Manticore – A project started by two students at the University of Alberta in 2002, but never finished. They implemented a basic rasterizer that will be very interesting to examine, as well as a memory controller to arbitrate memory requests and talk to DRAM. They never worked out all the bugs in the rasterizer though, and the design lacks a z-buffer and texture mapping.
  • Niklas Knutsson Thesis Project – A 2005 Master’s thesis from Linköping University, Sweden. This is a great description of the task of implementing a 3D graphics pipeline in an FPGA, but the implementation was never finished. He got as far as drawing some basic test patterns, but most of the design time was spent on the CPU and memory controller, so the 3D pipeline wasn’t fully fleshed out. The HDL source and schematics don’t seem to be available online, unfortunately.
  • Open Graphics Project – This is an ongoing project to build a fully PC-compatible graphics card, using a pair of FPGAs on a PCI card. Coincidentally, it was featured on the front page of Slashdot just yesterday. The majority of the development so far appears to have centered on the PCI interface, and support for legacy VGA modes. The documentation on the 3D pipeline is fairly skeletal, and it appears that little of it has actually been implemented so far.

I’m surprised there aren’t more projects out there like this, and apparently none that were ever successful. I’m guessing that such projects do exist, and I’ll just have to dig a little deeper to find them.

Read 7 comments and join the conversation 

7 Comments so far

  1. Steve - May 3rd, 2009 11:58 am

    I forgot to add that I’m unsure if 10000 logic cells is “a lot”, or whether I should be more concerned about speed or memory than logic area. The only reference point I have is that the 8-bit PicoBlaze soft-CPU can be implemented in 96 “slices”, which is about 216 logic cells.

  2. Erik Petrich - May 3rd, 2009 7:58 pm

    The 3E board is made for Xilinx by Digilent (www.digilentinc.com); I don’t know for sure about the 3A board, but it suspiciously looks like it is too. If you go with either of these boards, you might want to consider getting Digilent’s FX2 Wirewrap board (about $20) so that you can more easily interface your own hardware to the FPGA (it mates with the 100 pin I/O expansion connector that is otherwise not easy to prototype with).

    The VGA interfaces are not very sophisticated on these boards, so you could go with the 3E board and duplicate the 3A board’s video interface (it’s just 14 resistors!). For that matter, you could extend the existing interfaces past 4 bits per color with more resistors (the resistance of each new LSB is just double that of the previous bit’s resistor). The main limitation is that because of the resistor’s tolerances, the doubling is not exact and so the error in linearity increases as you add more bits. If this matters then at some point you are better off buying a video DAC chip, but until then adding resistors is a quick and easy hack.

    PicoBlaze is a very simple architecture… I think too simple for your project (and last I checked, there’s no C compiler available for it). Xilinx’s 32-bit MicroBlaze core would be more suitable, but I don’t think it’s free.

  3. kmike - May 30th, 2009 6:29 am

    Why don’t you help the existing Open Graphics project instead of starting from scratch? It looks like your expertise in 3D field would help it immensely.

  4. nano - May 30th, 2009 10:18 am

    If I was starting from scratch, I would create an engine based on either voxels or raytracing. Implementing mass parallel ALUs and doing the rest in the driver seems to be the way modern cards are going, but you’ll want to minimise CPU use and do most of the driver in hardware. Whichever path you take some interesting design decisions lay ahead of you. Best of luck with your project.

  5. Steve - June 1st, 2009 8:29 pm

    @kmike: I looked at the Open Graphics project, and it seems pretty similar on the surface, but their goal is to make an actual PC graphics card. That means lots of work on a PCI interface, and support for old DOS video modes. I’m more interested in a custom computer with custom graphics hardware, where I can choose to support whatever features and modes I wish, without needing to be compatible with something else.

    @nano: I’m no expert on ray tracing or voxels, but I’m not sure they’re applicable here. For voxels, you still need to use some algorithm to reduce your volume to polygons for rendering, and then you’re right back at polygon rendering. Ray tracing doesn’t really lend itself well to hardware parallelization, I think. Polygon transformation and rasterization is a pretty well-studied field in comparison, so I’ll have more to work from, and can potentially even build hardware that implements a subset of the OpenGL API.

  6. Steve - June 3rd, 2009 7:23 pm

    I ordered the Spartan 3A starter kit today. http://www.xilinx.com/products/devkits/HW-SPAR3A-SK-UNI-G.htm

  7. Peter Lund - June 10th, 2009 7:13 pm

    MicroBlaze has gcc support and the Linux port is in the process of being merged into the mainline kernel.

    OpenFire seems to be an open-source reimplementation. Dunno how well it works with Linux, though.

    (It’s been 4 years since I worked with FPGAs)

Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.