2
\$\begingroup\$

I am trying to understand the actual purpose of the read-enable signal on synchronous FPGA Block RAMs. I do not see the actual need of it.

But regardless of why it was put there in the first place, can read-enable being low during write operation or when we do not need to use output data actual conserve power in the design?

\$\endgroup\$
1
  • \$\begingroup\$ Just one data point from the power estimator for Lattice ECP5: 10 Blocks @ 200 MHz: 1 mW @ 1% read activity, 65 mW @ 100% read activity. Substantial difference... But it doesn't tell what the effect of high/low read enable with static addresses and data is. The magnitude of the power consumption means you can easily try it yourself with a small test design and a multimeter... \$\endgroup\$
    – asdfex
    Commented Jun 17 at 13:18

2 Answers 2

3
\$\begingroup\$

How much power it may save depends largely on the design and the structure of the RAM itself

If we assume that the read enable only acts on the output registers of the memory, then with the enable low, you will inevitably reduce some power consumption as the registers in the memory won't be updating, but this won't save you much power as there is only a few registers.

If instead the the structure of the RAM is such that the read enables are also acting on input registers (e.g. pipelining of the address bus), the saving may will be much more significant. This is because the whole memory matrix stops updating - a 1-bit change in the address bus will propagate through the entire RAM decoding matrix.

Furthermore how significant the overall saving relative to the total power consumption is again design dependent. If your design is primarily RAM cells, then the amount of power consumption may be a significant portion of the overall design power usage. However if your design contains a lot of other resources - registers, PLLs, DSP units, SERDES blocks, etc, the actual reduction may be a drop in the ocean compared to the overall power usage.


Regardless of the affect on power consuption, one of the main use cases is indeed simply that you can stop the output register from updating. That means you can hold on to a previous value while you are doing something else with the memory (e.g. starting to read/write a new address).

Consider a pipelined process. If your memory has a latency of say 1 clock cycle, then your result will appear 1 clock cycle after you try to read it. Let's also say on the next clock cycle you start reading another value, but in this cycle the logic that is supposed to accept the previous value stops being ready for it. If you can't stop the memories pipelining, you lose a value.

With the read enable you can effectively stall the memory pipeline until you are ready. It is allowing you to achieve 100% throughout on the memory when you are ready for data, whilst providing a way to not lose any data when you stop being ready. Great for a streaming FIFO.

You can achieve something similar with a skid buffer, but if you're RAM already has the read enables, it saves a load of extra logic.

\$\endgroup\$
7
  • \$\begingroup\$ The Intel true dual port RAM has separate read enable and write enable. However, this is not the case at all with the True Dual Port RAM of the Xilinx and Microsemi devices. This made me wonder what is even the significance of a dedicated read enable. \$\endgroup\$
    – quantum231
    Commented Jun 16 at 21:19
  • \$\begingroup\$ @quantum231 I seem to recall the separate read/write enable is only when you use the memory in one-port-readonly/one-port-writeonly mode. If you have two read/write ports, you don't get the rden port. Essentially there is one enable signal per port, so if you have a read-only port it becomes a read enable \$\endgroup\$ Commented Jun 16 at 21:23
  • \$\begingroup\$ @quantum231 For Xilinx TDP, you have a "port enable" and use the byte-wide write enable to decide (per byte) if you want to read or read+write. This is slightly inferior to RDEN + WREN because you can't not read while writing. But if you use the built-in output registers (which you usually want to anyway), those have a clock enable, which can be used pretty much like a read enable with an additional clock cycle of latency. \$\endgroup\$
    – Stefan
    Commented Jun 17 at 9:04
  • \$\begingroup\$ I think (but can't find it now) that Xilinx does say that keeping this "port enable" low while not using the port is important for saving power. \$\endgroup\$
    – Stefan
    Commented Jun 17 at 9:24
  • \$\begingroup\$ What do you mean by "Unlikely to save much power..."? If you mean as a fraction of the total design power, maybe, but as a fraction of BRAM power, in my experience with Xilinx FPGAs, keeping BRAM enables de-asserted is very important for saving power. \$\endgroup\$
    – Jason C
    Commented Jun 17 at 13:19
1
\$\begingroup\$

In my experience (with Xilinx FPGAs) block RAM power scales linearly with how often the enable is asserted, so I would expect a power savings from only asserting the enable as-needed.

Most vendors have power estimation tools that you can use to get a basic intuition for this sort of thing:

\$\endgroup\$

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.