Difference in timing while getting values from ROM or RAM - process

Question

So I am having a hard time understanding the time it takes to get values from ram or rom in vhdl. To insert data into ram I know happens on the rising edge of the clock and takes one clock such as the example I have, but in terms of getting data out does it take one clock to get the data from memory and then get then another clock cycle to get the data to output meaning it takes 2 clock cycles to get data?
process(clk)
begin
if(rising_edge(clk)) then
if(write_en = '1') then
mem(to_integer(unsigned(address))) <= incoming_data;--insert data
end if;
end if;
end process;
out_data <= mem(to_integer(unsigned(address))); -- takes 2 clock cycles to get data ?

Answer 1

No, it takes 1 clock cycle:
In your code you have two concurrent processes. One is explicit:
process(clk)
begin
if(rising_edge(clk)) then
if(write_en = '1') then
mem(to_integer(unsigned(address))) <= incoming_data;--insert data
end if;
end if;
end process;
The other is implicit; it is a concurrent signal assignment:
out_data <= mem(to_integer(unsigned(address))); -- takes 2 clock cycles to get data ?
The concurrent signal assignment is exactly equivalent to this:
process(address, mem)
begin
out_data <= mem(to_integer(unsigned(address))); -- takes 2 clock cycles to get data ?
end process;
In other words, it is equivalent to a process with address and mem in the sensitivity list. Any concurrent signal assignment is equivalent to a process with all the inputs in the sensitivity list. An input to a concurrent signal assignment is any signal on the right hand side of the signal assignment operator (<=). So, you get a sensitivity list for free and that is an advantage of using concurrent signal assignments: you cannot accidentally miss out a signal from the sensitivity list, because the compiler creates it for you.
So, lets consider what happens when each process is executed. The first process has just the signal clk in its sensitivity list, so the process executes whenever there is a change (an event) on clk. If this change is not a rising edge then the rising_edge function returns FALSE and the process immediately suspends. If this change is a rising edge then the rising_edge function returns TRUE and if the expression write_en = '1' is also TRUE then this line gets executed:
mem(to_integer(unsigned(address))) <= incoming_data;--insert data
The effect of this line is to put an event on the event queue to drive the correct value of mem on the next delta cycle (assuming there is some change to the signal mem as a result). The event queue is the simulator's "to do" list; a delta cycle is one iteration of the simulator; the next iteration will occur once all the processes that are executing in the current iteration suspend.
So, the next iteration cycle occurs and the signal mem gets its new value. The signal mem is in the implicit sensitivity list of the second (implicit) process (the concurrent signal assignment). So, this second process starts executing and the line with the signal assignment to out_data is executed and (as with the executing of any line containing a signal assignment) an event is put on the event queue to drive the target signal - out_data in this case - to a new value (again assuming the value should change).
So, the change to the signal out_data always occurs one delta cycle after a change on the signal mem. We've already established that the signal mem changes one delta cycle after any rising edge on the signal clk, so we can see that the signal out_data changes two delta cycles after any rising edge on the signal clk.
Whilst it is vital to be aware of delta cycles when writing VHDL, we don't usually need to worry about them if we adopt a good, conventional style. So, we can just say that the signal out_data changes on any rising edge of the signal clk or, in other words, there is a delay of one clock cycle between any changes on the signals write_en, incoming_data or address and any corresponding change on the signal out_data.