Sprite Graphics Accelerator On An FPGA

A demo running on a FPGA sprite accelerator

Graphics accelerators move operations to hardware, where they can be executed much faster. This is what allows your Raspberry Pi to display high definition video decently. [Andy]’s latest build is a 2D sprite engine, featuring hardware accelerated graphics on an FPGA.

In the simplest mode, the sprite engine just passes commands through to the LCD. This allows for basic control. The fun part sprite mode, which allows for sprites to be loaded onto the FPGA. At that point, you can show, hide, and move the sprite. By overlapping many sprites, you something like the demo shown above.

The FPGA is from Xilinx, and uses their Block RAM IP to store the state of the sprites. The actual sprite data is contained on a 128 Mb external flash chip, since they require significant space.

The game logic runs on a STM32 Cortex M4 microcontroller which communicates with the FPGA and orders the sprites around. The FPGA then deals with generating frames and sending them to the LCD screen, freeing up the microcontroller.

If you’re wondering about the LCD itself, it’s 3.2″, 640 x 360, and taken from a Ericsson U5 Vivaz cellphone. [Andy] has a detailed writeup on reverse engineering it. After the break, he gives us a video overview of the whole system.

16 thoughts on “Sprite Graphics Accelerator On An FPGA

  1. Seriously cool stuff! One would think you’d need a tilemap for the background layer(s), but this is exactly how the classic Neo Geo hardware worked: No tilemaps, just loads and loads of sprites. Great work!

  2. Seems like a lot of this could be done with FTDI’s EVE chip, but doing it in a Spartan opens up some other things (extra I/O pins for other features, etc.), so this can be a very interesting approach.

      1. Doesn’t matter. ‘behavioural’ is not a VHDL keyword. You could also write

        architecture tewkr of module1 is
        end twekr; –This line should match with the architecture definition. I think you can also write end architecture but I am not sure.

        1. yes the name after end architecture, process, component… can be omitted.
          you can also omit the word “is”
          vhdl is one of the ugliest and most inconsistent languages i’ve ever seen

  3. Glad to see the author have a section of signal integrity on the project, but I disagree with the conclusion:
    >A very promising feature implemented in the more modern Xilinx FPGAs is Digitally Controlled Impedence (DCI). ….
    >I would certainly enable this feature if it were available in the device I was using.

    DCI is not a magical tools that automatically eliminates signal integrity issues. The main goal is to let you match the driver impedance to the usual 25 ohms/50 ohms etc without having to worry about FPGA process/voltage variations. One would need a controlled impedance that is matched to the *actual* PCB tracks impedance within may be 20%. You are typically looking at a 4 layers with thin dielectric material to be able to keep the board density up.

    On a 0.062″ thick double sided PCB, that’s a fool’s errant.
    A 117 mil wide track would give you close to 50 ohms on that topology. My power rails are even that thick. :P

    130 ohms or so is doable (10 mils). So this means DCI won’t help you at all. Just about the only things you could do is slow down the slew rate, keep the track short relative to the slew rate, switch to a low current drive (i.e. increase the I/O cell driver impedance indirectly so that they match your board impedance) or have to add series terminations.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.