FPGA Memory vs Registers

Question

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?

Answer 1

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.

Answer 2

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.