RAM uninferred due to asynchronous read logic

Is code_word_addr the output of some other set of logic? It may be complaining because it cant place the read address in a register internal to the ram. The code you posted shows a registered output, rather than a registered read address. All the code templates that altera provides ask for a registered read address.

The read data is then asynchronously read out from the registered read address with optional output registers.

just to show you what I mean, here are two lots of code, one that should infer a ram and another that might not. They are similar but subtly different.

signal read_addr : integer;
signal mem       : some_ram_t;
  
  
--------------------------------
--Should infer a ram
--------------------------------
process(clk)
begin
  if rising_edge(clk) then
    read_addr <= some_logic;
  end if;
end process;
output <= mem(read_addr);
-------------------------------------
--Async read - cant infer a ram
-------------------------------------
read_addr <= some_logic;
process(clk)
begin
  if rising_edge(clk) then
    output <= mem(read_addr);
  end if;
end process;

Thanks for your reply!

I have tried registering the address (and then reading from the array outside of the synchronous process) and it makes no difference. Even if I do this it still fails:

...
code_line_memory:
process(clk)
begin
    if clk'event and clk='1' then
        if ps=code_refill_bram_1 or ps=code_refill_sram8_3 or ps=code_refill_sram_1 then
            code_line_table(conv_integer(code_word_addr_wr)) <= code_refill_data;
        end if;
        -- register address 
        code_word_addr <= code_rd_addr(11 downto 2);
        code_cache_rd <= code_line_table(conv_integer(code_word_addr));
    end if;
end process code_line_memory;
...

I have tried registering the address in a separate process, just in case I was confusing the synthesizer. Still didn't work.

The only thing that seems to work so far is registering code_cache_rd (that is, registering it again, by loading it on a register). But I can't accomodate an extra delay cycle in my design.

The templates I talk about are those included in Quartus-2 and those shown in the manual (chap. 6 'recommended hdl coding styles'). Both are analogous to the code snippet I posted, i.e. unregistered address and registered output (though the actual hardware implementation may be different, I realize). I mean, my code is almost verbatim from the Quartus-2 manual template:

...
PROCESS (clock)
BEGIN
IF (clock'event AND clock = '1') THEN
IF (we = '1') THEN
ram_block(write_address) <= data;
END IF;
q <= ram_block(read_address);
-- VHDL semantics imply that q doesn't get data
-- in this clock cycle
END IF;
...
END PROCESS;

Note that I don't care about the read-during-write behavior in this design so reading old data is fine.

have you tried it in a newer version of quartus?

I can only think then there is something wrong elsewhere in the code. Have you tried raising a Mysupport request?

I too guess there is something wrong with the code but I'm now reduced to changing it at random hoping to get some clue...

I have tried the same code with ISE and the synthesis looks OK (the code is vendor-agnostic). I will search the warnings and will try using synplify, to see if I can find what's wrong (though that'll have to wait until monday).

It will take me days to try another version of quartus; it's a 3GB download and a full reinstall. I hope to catch the error before the download is finished :) Note there are no service packs for the web edition of Quartus that I'm using, it's full download or nothing.

As for the MySupport, this is a private project not related to any company (i.e. I can't use a company email as required by MySupport) so I can't open a case. The web application won't even let me search existing cases (?). I will search the forum more carefully...

Thanks for your help. Any hints or ideas are welcome!

I'll keep track of my progress in this thread.

I am trying to install Quartus 2 10.1 on Kubuntu... a nightmare on its own right. I wonder if the guys at Altera have ever heard of apt-get or Ubuntu... When and if I get the install done I will try my code on it.

As for the partition, I have first to figure what a 'partition' is in this context :) thanks for the tip.

The manual warns you that RAM inference can fail of the RAM output goes straight to a hierarchy boundary (which it does). But I have used this exact same construct in the past with no trouble, and as I said, when you compile the cache module separately (i.e. not connected to a parent module) it works fine.

I will try moving the RAM to a separate module and see if it helps...

i think i've run into this before

are code_word_addr and code_word_addr_wr registered or combinational? try registering them

Hello,

Signals code_word_addr and code_word_addr_wr are slices of an input signal that itself is the output of an adder. They are combinational.

I have tried registering the read address (code_word_addr) with no result. I haven't tried registering the write address, though. I will try.

Anyway, registering the addresses may be useful for diagnostic but I can't accomodate the extra latency cycle in the design.

Neither can I 'move' the module boundaries so that the RAM output does not go straight to the module output (the manual suggested that might be the problem).

You see, this BRAM is the line store of a direct-mapped code cache for a MIPS core. The core already works with a 'stub' 1-word cache (which uses no RAM). The trouble started when I began implementing the real cache. The cache is meant to be wired directly to the CPU ports. In this particular case, the output of the code line store goes to the CPU module, where it is registered. BUT, before registering, a slice the unregistered CPU input (i.e. the cache RAM output) is used as the address input for the register bank (which itself is another RAM block). So I just have to use the RAM block output. I hope that made sense...

The point is I have used this construct several times in this very design (register bank, startup ROM, etc.) and in many other designs with this and previous versions of Quartus and this is the first time I see this problem...

I have to find a way to put a block ram there. I will try to put the block in a separate module (which will complicate the code unnecessarily, but oh well...). Eventually I may have to surrender and just instantiate a Cyclone-2 block (so far the code is vendor agnostic and works with no changes on Xilinx tools).

On an unrelated note, I have been unable to install and run Quartus on my Kubuntu machine. Installation errors, missing instructions, program crashes, etc. etc. etc. In my opinion, the Linux version of Quartus-2 is so desperately buggy that Altera should just honestly admit that Linux is not supported -- supporting a small percentage of Linux users on an essentially random basis is not enough. Compare this to Eclipse, Kdevelop, CodeBlocks, OpenOffice, etc.

Thank you for your tips!

its quite stable on supported distros ;)

even on some unsupported...