VHDL signal versus variable: why does my signal still show the old value inside the process?

A signal assignment with <= does not change the signal while the process is running. It schedules a new value that takes effect only after the process suspends, one delta cycle later. Every read of the signal during that pass returns the value it had when the process started. A variable assignment with := takes effect immediately, and the next statement sees the new value.

If a signal is assigned several times in one pass, only the last scheduled value survives. That is useful for defaults, and it is also what breaks your loop.

Tracing your process for "11110000": the clear at the top schedules 0. Then each loop iteration with a set bit schedules ones + 1, but ones on the right-hand side is still the value from before the clock edge, so all four iterations schedule the same number, the old value plus 1, and the earlier clear is overridden. The net effect per clock is ones <= ones + 1: a counter, not a bit count.

With a variable, cnt := 0; followed by cnt := cnt + 1; in the loop accumulates 1, 2, 3, 4 within the single pass, and a final ones <= cnt; registers the result.

In hardware terms, inside a clocked process every signal that is assigned becomes a flip-flop, and reading a signal reads the flip-flop's output, the value from the previous edge. So b <= a; c <= b; is two registers in series, and c lags a by two clocks.

A variable depends on the order of use. If it is written before it is read in the same pass, it is just a name for a piece of combinational logic: v := a; c <= v; gives one register. If it is read before it is written, the value must come from the previous pass, and the synthesiser creates a register for it. Keeping to write-before-read avoids surprises.

Practical guidance: use signals for anything that leaves the process or represents state, such as registers, state machine state and ports. Use variables for intermediate calculations inside one process: loop accumulators, a computed index, a wide sum that is then truncated. Variables are visible only in their own process, which also keeps them from becoming accidental shared state.

Two smaller points. Variables simulate faster because no event scheduling is involved, and some waveform viewers need them added explicitly before they are displayed. And a process with variables behaves like sequential software, so statement order matters there in a way it does not for signal assignments.

The same delayed-update rule explains a frequent off-by-one in counters. In count <= count + 1; if count = 9 then count <= 0; end if; the comparison sees the value before the increment, so the wrap happens on the edge where count was 9, and the sequence is 0 to 9, ten states. People expecting software semantics compare against the wrong number and get a period that is off by one clock.

When the period matters, write the terminal value as a named constant and check one full cycle in simulation.