Is it possible two or more sequential run for a process in VHDL?
What will happen if another event happen (on sensitivity signal list) while the sequential execution of a process is not completed ?
Is it possible or my VHDL model in mind for process is completely wrong?
No event will ever occur while a process is running!
When a process is woken by an event, it runs to completion ("end process") or an explicit "wait" statement, and goes to sleep. This takes, notionally, ZERO time. Which means that if you have loops in your process, they are effectively unrolled completely, and when you synthesise, you will generate enough hardware to run EVERY iteration in parallel. Also, any procedures, functions etc, take zero time - unless they contained an explicit "wait" statement (in which case the process suspends at the "wait", as if the procedure had been inlined).
Throughout this process, all signals have the value they originally had when the process woke up, and any signal assignments are stored up, to happen later. (Variables update immediately; later statements in the process see the new value).
When the process suspends (at "wait" or "end process"), nothing happens until ALL the other processes also suspend. (But remember they all take zero time!). If a process suspends at "end process" it will restart from the beginning when its sensitivity list wakes it up. If it suspends at an explicit "wait", that "wait" will specify an event or future time, which will restart it after the "Wait". (NOTES: 1 : do not mix the sensitivity list and Wait styles in the same process! 2: Wait Until some event is synthesisable (though some tools may object) ; Wait for some time is simulation only)
THEN all the signal assignments are performed. Since all processes are asleep, this eliminates all race conditions and timing hazards. Some of these assignments (like '1' to a clock) will cause events to be scheduled on processes sensitive to them.
After all the signal assignments are done, the time steps forward one infinitely short tick (called a delta cycle), and then all the processes with scheduled events are woken.
This continues until a delta cycle occurs in which NO new events are scheduled, and finally the simulation can advance by a real time step.
Thus
process(clk)
begin
if rising_edge(clk) then
A <= B;
B <= A;
end if;
end process;
is hazard-free in VHDL.
If you ever need to use Verilog, be aware that some of this happens differently there, and you cannot rely on the same level of predictability in simulation results.
In synthesis, of course, we generate hardware which will take some real time to execute this process. However, the synthesis and back-end tools (place and route) guarantee to either obey this model faithfully, or fail and report why they failed. For example, they will add up all the real delays and verify that the sum is less than your specified clock period. (Unless you have set the clock speed too high!).
So the upshot is, as long as the tools report success (and you are setting the timing constraints like clock speed correctly) you can pretend the above "zero time" model is true, and the real hardware behaviour will match the simulation. Guaranteed, barring tool bugs!
When starting out using VHDL (or any other HDL for that matter), it is hugely important to discard all notions of sequential code, and instead focus on the flow of data through the hardware. In hardware, everything is inherently parallel (everything happens simultaneously), but uses constantly changing data (input signals) to calculate constantly changing results (output signals)!
Without going into more advanced topics such as variables, wait commands etc., everything within a process happens simultaneously. If conflicting things occur within the same process (multiple writes to the same signal), the last statement in the process wins, which is often where confusion about "sequential" code in VHDL comes from.
This works due to the way that values are assigned to signals. When assigning a value to a signal, the value of the signal does not immediately change! Instead, the assigned value is remembered and will be committed as the actual signal value later (in preparation for the next delta cycle, which is effectively the next quantum of time).
Since the next delta cycle will not begin until all processes from the previous delta cycle have completed, signal values will only change when no process is running. Once all signals have changed, the next delta cycle begins and any process sensitive to one of the changed signals will be executed.
If a process is sensitive to a signal it also writes, you have what is known as a combinatorial loop, e.g., a gate where the output feeds an input. This is (almost) always an error in your circuit, and will usually cause simulators to enter an infinite delta-cycle loop.
That's all I'll write for now, as Brian Drummond's answer just popped up as I was writing this, but feel free to leave a comment and I'll add some more details.
Once a process starts to run (due to an event), it runs to completion before any other events are allowed to trigger anything else.
