I'm having an issue on an FPGA project I'm working on. I'm unable to write to defined memories within the FPGA, but writing to registers works fine. I was thinking about working around this problem by simply using registers as memory. I only need to store a max of ~1024 bits at a time, and there is plenty of register space available on the FPGA. The FPGA in question is an Altera Cyclone III model if that makes a difference.

Are there any disadvantages to using registers versus memory that I'm overlooking?

  • \$\begingroup\$ This gives nearly zero information about your problem. \$\endgroup\$
    – Eugene Sh.
    Mar 2, 2017 at 15:14
  • \$\begingroup\$ My question isn't "please solve my problem", that was simply background. I'm wondering whether registers have any disadvantages in terms of write speeds etc compared to external memories. \$\endgroup\$
    – Peyton B
    Mar 2, 2017 at 15:16
  • \$\begingroup\$ You risk running out of registers. That's about it. \$\endgroup\$
    – pjc50
    Mar 2, 2017 at 15:18
  • \$\begingroup\$ @pjc50, no there's much more to it than that. See WRB's answer below \$\endgroup\$
    – TonyM
    Mar 2, 2017 at 15:55

2 Answers 2


The actual storage elements for registers and RAM in an FPGA are the same. What matters is the routing resources available. RAM can be thought of as a dedicated array of registers with with a relatively small number of signal lines controlling a whole lot of registers. This allows you to handle a lot of data without using a whole lot of interconnect resources, which are actually the limiting factor in FPGAs.

So the answer is, yes, you can use registers instead of RAM. And no, using 1024 of them is not a great idea since it is likely to suck up a lot of your FPGA, both in functional cells and in operating speed.

You're much better off figuring out how to use your RAM.

  • \$\begingroup\$ Your conclusion is fine, but your opening statement is not. In most modern FPGAs, registers and RAM are very different structures. "RAM" exists in the form of small LUTs for implementing logic functions and large blocks of SRAM for storing data, etc. "Registers" are dedicated flip-flops. With either type of RAM, the value of only one address at a time can be accessed, while with registers, all outputs are available in parallel. \$\endgroup\$
    – Dave Tweed
    Mar 2, 2017 at 16:55
  • \$\begingroup\$ @DaveTweed - Yeah, you're right (more or less), but I was trying to match the truth to the OP's apparent experience level. Static RAM and registers both depend on flip-flops to do the actual storage, but the auxiliary circuitry is quite different. It was this core storage function I was referring to. Drawing the line in making gross simplifications can be hard. \$\endgroup\$ Mar 2, 2017 at 17:28
  • \$\begingroup\$ In Altera devices (and possibly some others brands too), using registers as memory also requires huge multiplexer trees, since there is no tri-state logic in routing. Using clever multiplexer restructuring in a Cyclone-IV, the mux for 1024x1 bits will use 2*256+2*64+2*16+2*4+2*1 = 682 LUTs. \$\endgroup\$
    – Andreas
    Mar 2, 2017 at 18:33

There are in general terms three distinct ways to instantiate storage in an FPGA, though they also have sub-varieties. Without your explicit attempt HDL or error output, it's impossible to know what happened, but it may be worthwhile to backup and understand the possible options:

Storage in the Fabric - if you just describe in HDL code something that acts like storage, it would in the case of a simplest toolchain end up implemented in the logic fabric of the FPGA - most implementations have at their basic cellular level a combination of logic (typically via a look up table) with a flipflop at the output of the cell, and so it is possible to store a few bits in those output flipflops. Combine enough of these together and you get small to medium size storage, most chips being able to support far more than your limited need. You also get the most flexibility this way - you can have multiple read and write ports (for example 3 ports in a classic CPU register file) and the most flexibility in clocking and clock timing - for example, while it is generally a bad idea you may be able to get away with using a write strobe rather than a clock and write enable.

Explicit Instantiation of Memory Blocks Because storage in the fabric is inefficient, most FPGAs also include substantial blocks of what is basically synchronous Static RAM, without logic threaded through it. This tends to be far more flexible than usual discrete IC RAMs - for example it is often dual port and has various width and clocking options, but there are restrictions in how it can be used. If you look into the FPGA documentation you will find what are effectively function prototypes for the various configurations, and you can choose one to explicitly include in your HDL code. Some FPGAs even include multiple types of Block RAMs on the same chip with different sizes and restrictions - for example, those that can and cannot have contents initialized from the bitstream to function as a ROM, perhaps (?) those that are only single port, those that have various timing, etc.

Inferred Storage Modern FPGA toolchains attempt to be pretty smart, so if your code describes behavior compatible with one of the Memory Blocks, the tool may well be able to implement what you have described by leveraging one or more of the hardware memory blocks rather than by implementing it in the fabric. However, changing one small detail could make it incompatible and force an implementation in the fabric instead. Often there will be synthesis settings that govern if it will try to do this, and the synthesis report is where you will find out what it has actually done.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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