Storing User Data On Your FPGA

We’ve seen FPGAs used to recreate everything from classic arcade games to ancient computers, but with each of these builds a common problem arises. Once you’ve got the hardware emulated on an FPGA, you’ve also got to get the ROMs into the project as well. In a very interesting hack, [Mike] figured out that the serial Flash chip that stores the FPGA settings has a lot of space free, so why not store user data there?

[Mike] got the idea from seeing a recreation of the classic BombJack arcade game we featured last month. In that build, [Alex] needed to store 112Kb of game data stored in 16 ROM chips. Unfortunately, [Alex]’s FPGA only had space for 40Kb of data. After realizing his FPGA had a 512Kb SRAM chip, [Alex] decided to put all the sprites, sounds, and levels of BombJack in the SRAM.

Impressed with [Alex]’s build, [Mike] set to work generalizing the hack to work with other projects. [Mike] notes that only a few FPGA boards are capable of storing user data next to the  configuration bitstream; the hack is impossible on the Digilent Basys2 board, but it works wonderfully on a Papilio One 250K.

As a very cool build that makes FPGA-related builds even easier, we’ve got to tip our hat to [Mike] for writing up a great tutorial.

14 thoughts on “Storing User Data On Your FPGA

  1. Why not just use a discrete storage chip and save yourself the hassle? Then you wouldn’t need to take care to save the data when you rewrite the FPGA, since it’s stored separately.

    1. The idea behind it is to avoid adding extra chips, unless there is a good reason to.

      When using a soft processor it gives you somewhere to store a bootloader (or maybe your entire application) without the extra engineering needed to add a second flash chip to the board – and of course if you are making the board you can always use the flash that gives you the storage capacity you need.

      For hobbyists like me, it allows others to also run your project on their stock-standard dev board, and avoids the need for me to have a second set of tools to program the extra chip. Without JTAG access the programming flash chips wired to arbitrary pins on an FPGA takes a bit of work – you need to build a design to make the FPGA to act as a pass-through for your programming tools.

      As a bonus, this design it also allows others to merge different data into an existing FPGA bitstream without the hassle of installing the FPGA vendor’s tools to rebuild the project, making it a great place to store unique non-volatile data MAC addresses.

      And yes, you can use it to smuggle data across the boarder. The FPGA project will work as designed, then you can download a bitstream to the FPGA to read back the “hidden” stuff.

  2. Nice Hack.

    Site has some beginner friendly FPGA HDL Tutorials too if anyones interested in this fascinating area.

    I made a FPGA homebrew CPU a few years back on a digilent board, got it to execute a small program but ultimately never found a real life use for these devices as they are quite expensive to develop with and most of my customers and projects worked happily with PIC 18F devices.

  3. Xilinx has an old app note with an executable that combined user data and the FPGA image into a single memory file that could be stored in the required configuration memory IC.

    After the FPGA booted, the memory could be read. A sync word indicated where the config image ended and the user memory began. The app note used a soft processor to read the memory, the memory read out could easily be written in anyone’s preferred HDL language.

    It was App note, xapp482.
    link: http://www.xilinx.com/support/documentation/application_notes/xapp482.pdf

  4. Most Digilent FPGA boards I’ve worked with include an extra flash chip and an extra RAM chip on the board. There should be no need on these boards to hack the platform flash.

    I can understand any confusion with these boards; IIRC, the Nexys 2 has 2 different flash chips on it, and it took me forever to figure that out, because I could only find one.

    1. Darn – I must start reading more app notes. I might learn a thing or two without all the hard thinking :-)

      I have salvaged a little bit of pride from this project though – I am just submitting a patch for the Papilio Loader application to merge the data at programming time…

    2. wait, if i have a filled 5 liter water bottle (flash) and a empty 1 liter bottle (fpga) and i pour from the 5 liter bottle (flash) into the 1 liter bottle (fpga) until the 1 liter bottle (fpga) is full, i still have 4 liter left in the 5 liter bottle, right?

      1. Correct, and you can use that extra 4 liters to water the garden with.

        You can ,aybe hold long string constants in it (a bit like using PROGMEM in Arduino), or audio samples for a whoop whoop alarm rather than a silly beep beep, or use it to hold large precomputed trig tables.

        I plan to use my 4 liters to hold non-performance critical code – serial flash can still run at 4MB/s for sequential access, 1MB/s for random 16 bit words, and keep the data and critical code in the 200MB/s block RAM.

      2. In a ‘normal’ computer you have ram ,which you then load a program & data into for execution.

        so when some designers work with FPGA’s they carry this sort of thinking with them, it is perfectly understandable.

        However since you need to ‘configure’ an FPGA at startup via a bit source, there is absolutely no reason to require part of the data/program to come from a secondary source rather than the initial bit source.
        I have even seen experienced machine ‘designers’ implement an 8051 core, then design in an external eeprom to load the program from into the internal FPGA ram!!, so that they can ‘re-program it if needed!!!, completely overlooking the fact that FPGA’s are reprogrammable anyway.

        So there is nothing to be embarrassed about.

  5. >After realizing his FPGA had a 512Kb SRAM chip

    A bit of proof reading would go a long way..

    Anyhow Xilinx FPGAs can be configured from a few different sources. If you didn’t want to have a config ROM and parallel flash or loading data from the config ROM into SRAM you can apparently have your FPGA configuration on parallel flash along with your other data.. The interface is only 8 bits wide on the Spartan 3? parts I think though.

Leave a Reply to ejonesssCancel 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.