using a ram megafunction

While Quartus may infer a RAM from this code, it's not using best practices.

First, you should be using ieee.numeric_std.all instead of std_logic_arith, and std_logic_unsigned.

Second, your memory access process should have a sensitivity list and look something like this:

    access_memory : process( clock )
    begin
        if( rising_edge(clock) ) then
            dout <= ram( to_integer( addr ) ) ;
        end if ;
    end process ; -- access_memory

There are also some templates available inside of Quartus which may also be helpful.

--- Quote Start ---

While Quartus may infer a RAM from this code, it's not using best practices.

--- Quote End ---

It actually does.

Basically, I tried to focus on the original question. Further suggestions may be helpful, of course. I think, however, you should also give some explanation for what you regard as best practise.

--- Quote Start ---

First, you should be using ieee.numeric_std.all instead of std_logic_arith, and std_logic_unsigned.

--- Quote End ---

std_logic_unsigned may be regarded as bad practise. Personally, I dislike it too. But it simply introduces a Verilog-like behaviour in VHDL and may be appropriate for some simple applications. Regarding std_logic_arith, did you notice that all (or most) Altera VHDL IP is using it?

--- Quote Start ---

Second, your memory access process should have a sensitivity list and look something like this.

--- Quote End ---

It's fully legal VHDL code anyway. In an edge sensitive process, a sensitivity doesn't change the behaviour, neither in synthesis nor simulation. (Personally, I would use process(clock) at least to improve readbility and reserve wait until for simulation timing.)

As another comment: after 1 ns is valid in simulation only and ignored in synthesis. And the rw / memsave logic seems dubious to me, but may serve a purpose anyway.

--- Quote Start ---

Basically, I tried to focus on the original question. Further suggestions may be helpful, of course. I think, however, you should also give some explanation for what you regard as best practise.

--- Quote End ---

Agreed. Sorry about that. Thanks for clearing up my post. Just a few comments below.

--- Quote Start ---

std_logic_unsigned may be regarded as bad practise. Personally, I dislike it too. But it simply introduces a Verilog-like behaviour in VHDL and may be appropriate for some simple applications. Regarding std_logic_arith, did you notice that all (or most) Altera VHDL IP is using it?

--- Quote End ---

I do see Altera's IP using it, and I cringe every time I see them used.

On a side note, I don't like how all of their IP ports which are clearly fed with signed or unsigned data don't expose this datatype.

--- Quote Start ---

It's fully legal VHDL code anyway. In an edge sensitive process, a sensitivity doesn't change the behaviour, neither in synthesis nor simulation. (Personally, I would use process(clock) at least to improve readbility and reserve wait until for simulation timing.)

--- Quote End ---

Agreed and understandable. VHDL is extremely versatile, but not necessarily always the easiest to read - so maintaining a clear intent is important when writing code.

Hi ,

I agree this code infers a ram + mif data but needs some tidy-up.

The address bits 9 to 15 are not needed and are ignored by quartus.

the signal ready seems unnecessary since ram is ready when enabled and one can expect when to rd/wr from that.

Anyway if you prefer instaniation then use megawizard to generate a block of ram.

kaz