Not knowing all the details, in principle it is not a bug. This is a process that occurs whenever there is a falling edge on the associated clock. You can imagine that all signal reads happen right before the edge, and all the writes happen at the edge.
So having inside a clocked process:
a <= b; -- after the edge, a will have the contents of b
c <= a; -- after the edge, c will have the contents of a (NOT THE CONTENTS OF b).
The order of the above assignments does not matter, and can be represented by the following schematic:
simulate this circuit – Schematic created using CircuitLab
As you can see in the above schematic, each Flip-Flop has a 'queued' value D
and it becomes the output Q
at the clock's edge. a
has b
queued, and c
has a
queued. So in a single clock, b
can't propagate all the way to c
(it requires 2 clock cycles). So specifying the signal 'queuing' in code does not need any particular order.
In your specific example, when ADC_Counter
is 13
, ADC_temp(7)
has ADC_Data
queued, and ADC_Reg_1
has ADC_Temp
queued. ADC_Reg_1
is not getting corrupted with the new data bit, in the same way that our c
is not getting corrupted with b
.
Note: This would be different if talking about variables (you'd be using the :=
operator instead of <=
), but your code only contains signals.
The statements inside a process
are indeed executed sequentially, but they are all executed each time the process is activated (as defined by its sensitivity list).
Typically, the entire process will be executed once per clock edge, which means that any outputs (signals or variables) that get assigned within the process can all be updated on any given clock edge.
In this case, "sequential" refers to the relationships among the statements inside the process, but it has no bearing on its interaction with the rest of the design.
Best Answer
When there is no dependance between two assignments in a VHDL process, as in your second example, the synthesiser can choose how to infer the logic from the code as long as the output is equivelent and meets the supplied constraints.
In practice the two statements will be executed in parallel as the synthesiser will work out that they are not connected and create separate logic to deal with the two assignments.
The best way I find to understand how the synthesiser is inferring logic from your VHDL code is to look at the schematics representation of the tool's output after the elaboration and synthesis steps for a simple design and tweak things to see how it changes.