Inferring a single port RAM in Verilog

Question

I am trying to make a 32x4 (32 words, 4-bit) single port RAM block. Here is my Verilog code:

module RAM_array (input clk, wren, input [4:0] address,
                        input [3:0] data, output reg [3:0] q);

    reg [3:0] mem [31:0]; // a 4 bit wide 32 word RAM block.

    always @(posedge clk) begin
            if (wren)
                mem[address] <= data;
            q <= mem[address];
    end
endmodule

Since I'm using Altera's Cyclone V chip on a DE-1-SoC, I based my code on their guide here: http://quartushelp.altera.com/14.1/mergedProjects/hdl/vlog/vlog_pro_ram_inferred.htm

Question: Whenever I write a value to an address in the block I have to wait an extra clock cycle for it to get written. Why so?

Do you mean "wait an extra clock cycle for it to get written" or do you mean "wait an extra clock cycle for the q output to change"? Given how you have written your code, it takes 2 clock cycles for output q to change. — Matthew Taylor
Can you elaborate on in what sense an extra cycle of latency is inserted here? Try a blocking assignment if you want q to reflect the new value on the next cycle. At least Verilog is hardly my forte but I would be surprised if the synthesizer decided to map the logic to a block with different semantics than the code itself. — doynax
since you use 'non-blocking' assignment in the code, q will always get the old value of mem[address]. so, if data changed, say to '1' and mem[address] was '0' before, verilog will assign '1' to 'mem' but after it assignes '0' to q. So, you need next clock cycle to propagate the value to 'q'. — Serge
Ah, I see that now. If I wanted the value of q to change the very next clock cycle, would using a blocking assignment be the only way to achieve this? Isn't using blocking assignments in sequential always block poor style? Or would this be an exception to the guideline (I'm pretty sure there must be a way to improve my design rather than use blocking statements...) — cloudy_eclispse
Yes, using blocking on the outputs of the flop block is bad. You can use it on the internal temps though. But you are asking a different question now. And therefore a question for you: how it is supposed to work in your design? — Serge

EEliaz EEliaz · Accepted Answer · 2017-07-14T22:22:47

I'm guessing that you see the "extra clock cycle" when you try to read one clock cycle after you write, but still get the old value. This happens since you are using a non-blocking assignments when you write to mem, and when you drive the output q. Therefore, it takes you one clock cycle to write to mem and one clock cycle to read from it. In total it's two cycles.

If you want to reduce the memory latency, use concurrent statement and "assign" the output q. This will implement a simple wire from mem to the output q:

module RAM_array (input clk, wren, input [4:0] address,
                    input [3:0] data, output [3:0] q);

    reg [3:0] mem [31:0]; // a 4 bit wide 32 word RAM block.

    always @(posedge clk) 
            if (wren)
                mem[address] <= data;

    assign q = mem[address];

endmodule

The synthesizer should choose to implement this code with FFs, and not SRAM block (this is exactly the behavior of a FF --> zero cycles read latency, 1 cycle write latency). This is OK and shouldn't affect your synthesis since it's a very small array.

Inferring a single port RAM in Verilog

1 Answers