Related: Where to start when considering making a GPU?

I'm a pretty strong programmer, but I'm very new to hardware design, so apologies if I use strange terminology.

My long-term goal is to write a custom GPU, but I'm starting out with a basic framebuffer to get comfortable with hardware design. Here's a rundown of what I'm expecting to do with my project:

  1. Receive a frame of pixel data on a bus
  2. Store frame in a stack on the hardware
  3. Output frames at the monitor refresh rate

I can figure out #1 and #2, but I've never done anything like #3. I'm thinking the optimal development setup would be to have a virtual display that connects to the output pins of my design (VGA or DVI) and displays it in a window on my computer. I could probably do this with an FPGA and a small LCD, but I'm thinking it will be easier for development (esp. travelling) to have it all simulated.

Is there already a solution for this? If so, what can I search for to get more information about it? If not, what is the usual development setup for something like this?

I'm developing on Linux using Icarus Verilog, so a solution that works with that would be preferred.

  • 1
    \$\begingroup\$ I don't think you're going to find any out of the box software that lets you drive a virtual display on your desktop via a verilog simulation. Honestly I think the easiest way for you to go would be to get a cheapo VGA monitor and an FPGA with a VGA port. Write simple directed tests that can be verified in simulation, but as for actually watching your design drive a display, you'll probably need to synthesize and run it in real time. \$\endgroup\$
    – Tim
    Commented Jun 11, 2013 at 15:55
  • \$\begingroup\$ Seconded - outputting actual VGA will be much easier than trying to route it back into the computer. An osciliscope capable of handling video-speed signals (e.g. 100MHz) may be very useful if you can't get anything to appear. \$\endgroup\$
    – pjc50
    Commented Jun 11, 2013 at 18:44
  • \$\begingroup\$ @Tim - Dang, that's unfortunate. I guess it's not a very large market... \$\endgroup\$
    – beatgammit
    Commented Jun 11, 2013 at 21:33
  • \$\begingroup\$ @tjameson Realize too that simulations are generally much slower compared to actual realtime execution. On a large design it might take a computer one or more hours to advance a verilog simulation by 1 millisecond. That's not going to make any computer graphics very impressive :). I think it's probably more fun anyway to drive a real monitor, travel/portability issues aside. \$\endgroup\$
    – Tim
    Commented Jun 11, 2013 at 22:20
  • \$\begingroup\$ @Tim - Right. I was mostly looking for something I could do on an airplane or someplace where I don't have my dev stack. I guess this gets increasingly unrealistic the larger the design gets... Plugging it into a real monitor would definitely be much more fun though! Thanks! \$\endgroup\$
    – beatgammit
    Commented Jun 11, 2013 at 23:57

1 Answer 1


An alternative would be to use PLI/VPI to call out to some C code - so rather than doing the top level pin driving, call a system task that stores the pixel in a software frame buffer and renders that to a window.

I've used the same technique for a UART recently - instantiated another uart with the TX + RX crossed over, and when the one in the testbench receives data - feed it to some C code with a system task that writes to a PTY (and vice-versa).

Given that the simulation probably won't run that fast, writing image files or binary data then post-processing might make it more useful.

  • \$\begingroup\$ This sounds quite reasonable, and would very quite useful for writing software-based unittests. \$\endgroup\$
    – beatgammit
    Commented Jun 23, 2013 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.