For applications that require design on FPGA which shall make use of several image files, sound files or other forms of files, can they be simply included in the FPGA design configuration file? In any case if these things are stored in an external flash or EEPROM memory, is there a reference design that:

  1. Shows how to put them in this external memory
  2. Create a design which knows where to read in the external memory
  3. It reads it and then send this data to the output device?
  • \$\begingroup\$ It is possible that the design is purely in VHDL or rather makes use of a softcore to simplify the process. \$\endgroup\$
    – quantum231
    Jan 3, 2016 at 23:53
  • \$\begingroup\$ Xilinx provides tools to initialize external Flash memories via JTAG, PicoBlaze and MicroBlaze. Are you using a Xilinx FPGA? What's the board name? Does the image file exceed the BlockRAM capacity? If yes, it's not possible to solve it (hardcoded) in VHDL. \$\endgroup\$
    – Paebbels
    Jan 4, 2016 at 0:25
  • \$\begingroup\$ I am using Altera DE2-115 board. This is a general question to understand how this problem can be solved in various ways. \$\endgroup\$
    – quantum231
    Jan 4, 2016 at 0:55

2 Answers 2


Well, it really depends on how big your data is, how often you need access to it, and what sort of bandwidth you need. There is no good 'one size fits all' solution to this.

For small data, on-FPGA block RAM is a good option. The on-chip block RAM can be initialized from the bitstream data, so it can be used as a ROM. The on-chip location of the block RAM also provides the highest possible bandwidth. No external pins are required. However, the block RAM is very limited in size, so don't waste this resource unless absolutely necessary. It is also not really possible for the FPGA to edit the ROM entries as it would have to edit the initialization data for the block RAM in the bitstream (a far from trivial operation), so they are really only useful for constant storage or volatile storage.

Now, as for external nonvolatile memory, this is a bit more difficult. There are many different types of memory that could be used, with many different protocols. This could range from a simple I2C or SPI flash chip or SD card, to a parallel NOR flash or NAND flash, to an SSD or HDD connected via SATA or PATA, to accessing a file server or SAN over Ethernet. What makes sense depends on how big your data is, the access latency required, and the access bandwidth required. Connections over I2C or SPI will be very slow, perhaps up to a couple of MB per second. However, the protocols are very simple. So if you just need to stream 48 ksps audio data, this could be a good option. However, this will not work for something that requires a lot of bandwidth like full HD video. For something like that, you would need an interface with a lot more bandwidth. This is where the engineering can get a bit challenging - large, fast storage is not easy to interface with. One option might be to bring up a SATA interface and connect a large SSD. There will be some latency requesting the data, but you'll be able to stream many gigabytes of data off of the device at several hundred Mbps.

Also, don't forget that you will probably need some way to write to the nonvolatile storage as well. If this needs to be done at high bandwidth, then that means you will need some other interface to the outside world. Ethernet and USB 3 are reasonable options.


I think there is no general solution because:

  • EEPROMs use atleast 4 interface protocols
    • parallel
    • OneWire
    • I2C
    • SPI
    • JTAG
    • ...
  • Flash memory has as many interfaces plus some proprietary ones.

On top of an bus interface controller for the named protocols, there is a need of a read/write/erase controller, which addresses each possible memory type, size, ... and vendor.

On top of that you'll need a softcore CPU or a big FSM to read config streams from:

  • UART
  • Ethernet
  • PCIe
  • JTAG
  • ...

and write it to the external memory. After configuration this circuit needs to be bypassed, exchanged, ...

So an other bus controller plus several protocol layers is needed to read the input stream: e.g. MAC, IPv4, UDPv4

To bypass the memory configurator you could use:

  • double programming:
    1. upload the Flash programer
    2. send the Flash content
    3. upload the working design
  • bypassable programer with bus controller reuse:
    1. upload the design which starts in config mode
    2. redirect received contents to the Flash memory
    3. switch to the working mode / enable the main design to use the bus controller
  • dynamic reconfiguration to exchange the softcore / programing FSM with the real design.

Can you precise your question?

  • \$\begingroup\$ OK, a few images (lets say there are 10 of them) that won't be more than 800x600 pixels are to be read and sent off to VGA or a TFT display and a few sound files that are not compressed, let say 5 files that amount to 1MB. The data does not need to be changed once it has been put into the nonvolatile memory. It will only be read as and when needed. \$\endgroup\$
    – quantum231
    Jan 4, 2016 at 23:53

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.