RAM uninferred due to asynchronous read logic

Regarding the RAM inference problem, as we haven't seen the real code, it's only guessing. The requirements for RAM inference are basically simple, but depending on the coding style, it may be more difficult, to see if they are met. In case of doubt, I would use the Altera RAM templates as a starting point.

I have tried moving the RAM block to a separate module and I get the same result. Synthesizing the module standalone gives the expected result, synthesizing it in my design gives the same error as before.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use work.mips_pkg.all;
entity bram_2p is
    generic (
        BRAM_SIZE : integer         := 1024;
        BRAM_WIDTH : integer        := 16
    );
    port(
        clk             : in std_logic;
        reset           : in std_logic;
        rd_addr         : in std_logic_vector(9 downto 0);--in std_logic_vector(log2(BRAM_SIZE)-1 downto 0);
        rd_data         : out std_logic_vector(BRAM_WIDTH-1 downto 0);
        
        wr_addr         : in std_logic_vector(9 downto 0);
        wr_data         : in std_logic_vector(BRAM_WIDTH-1 downto 0);
        
        we              : in std_logic
    );
end entity bram_2p;
architecture inferred of bram_2p is
type t_ram is array(BRAM_SIZE-1 downto 0) of std_logic_vector(BRAM_WIDTH-1 downto 0);
signal ram :                t_ram;
begin
memory:
process(clk)
begin
    if clk'event and clk='1' then
        if we='1' then
            ram(conv_integer(wr_addr)) <= wr_data;
        end if;
    
        rd_data <= ram(conv_integer(rd_addr));
    end if;
end process memory;
end architecture inferred;

Info: Found 1 instances of uninferred RAM logic
    Info: RAM logic "mips_cache:cache|bram_2p:code_line_memory|ram" is uninferred due to asynchronous read logic

I have discovered a fix:

Did you notice, that the Quartus template is using a different topology than your design? It's registering the read address rather than the output. This structure is corresponding to the actual hardware behaviour. Normally, Quartus is able to convert the output register you have defined in your code into an input register, but apparently this doesn't work in your full design. I guess, that the compiler pushes the register into the design part driven by the RAM before it starts to process the RAM part.

Hello,

Hello again,

In Quartus, from the Assignments menu, select "Design Partitions Window". Then from the Project Navigator window find all instances of your RAM and either right click to create a partition around it or click and drag it to the Design Partitions Window. If the code infers into memory when compiled at the top level, then I am pretty sure this will do the trick.

Yes, I have seen this exact circumstance - a register for the output of one RAM is the address register for another. QII synthesis makes an early decision of which register to pull in to each RAM to make it synchronous. Unfortunately, this is done independently for each RAM, so there's nothing to prevent the tool from choosing the same register for each RAM which then results in one RAM or the other not being inferred correctly. Does the second RAM have output registers in the RTL? I believe QII prefers to use the output register if available to make the RAM synchronous, so if you add the output register, it may stop the tool from trying to choose the read address register (which is the same as the output register already being chosen by the first RAM).