VHDL code

This falls into the difference between C code and HDL.

Starting near the top of the process you have:

temp <= '1';

temp is a signal, not a variable(which is good. I advise using signals as much as possible as it is closest to hardware). The only place is gets assigned a value is in this one line. There is no conditional on this, so it will basically power up to 1. (It could power up to 0 and go to 1 on the first clock of the design, but I don't believe that is your intent). Next you have the case statement which looks good(I'm not following what you're doing with the integer range, but assume it is necessary. Note that most HDL does not use integer ranges like this...).

Finally, at the end is:

out_ready <= '1';

wait for 25 ns; -- ERROR

out_ready <= '0';

Not that all signal updates in a process occur concurrently, i.e. at the same time. You're telling out_ready to get a '1' and a '0' at the same time. The wait for 25ns is purely a simulation symantic. The FPGA has no internal sense of time. It doesn't know what 25ns, as you're providing the clock and it could be any frequency(timing analysis can probably be looked at later). Most people are suggesting you build a counter(although 25ns) is pretty quick. So if you're clock period is 5ns, which is a relatively fast 5ns period , then you would decode when this has counted to 5 and send an output signal to tell out_ready that it can change. Even if synthesis could infer a counter out of this, there are many things it would miss. Would you want an asynchronous output on the counter? Do you want it to count to 4(20ns) and then send a signal so it can be evaluated on the next clock cycle, at time 25ns. Etc.

This is where you need to understand the target technology, which is LUTs(combinatorial logic), registers, RAMs and in some parts DSP blocks. Most of your code will target the first two. Think of HDL as a low-level description of logic and registers, and remember that registers all occur concurrently, i.e. they can toggle on every clock cycle unless you explicitly tell them not to. To be honest, in learning an HDL I would get a book that shows schematics with every example. I feel that's the best way to get started and learn how what you write translates into the FPGA. Good HDL designers understand the logic they're targeting and mentally have a good image of what their code will map to. If you write HDL from a more algorithmic standpoint(i.e. I know what I want done, but have no idea how it will get synthesized), you can write some good-looking code that gives horrible results.