VHDL - How does a process run concurrent with other processes and components while it executes sequentially?

Question

Just as the title says, how does this occur? I'm trying to wrap my head around processes vs components and I don't understand how this mechanism works. This may not be a proper question so please help me formulate it to be more specific, but I just really need to understand this concept to keep moving forward in my design.

For example:

count: process (x)
  variable cnt : integer := -1;
begin
  cnt:=cnt+1;

  if (cnt > '9') then
    cnt:=0;
    OVERFLOW <= '1';
  endif;
end process;

I understand that the if statement is dependent on the previous increment statement. I also understand why order is important (logically it makes sense - I check condition after updating), but what doesn't make sense to me is without any kind of clocking or other sequential mechanism, how does OVERFLOW (which is a signal in this example, not shown) get it's value updated concurrently with all the other signals in the design when it depends on cnt being updated first? Furthermore, any other signals which have implied processes associated with OVERFLOW are assigned concurrently, making them dependent on cnt by proxy as well.

Answer 1

Signals are always evaluated in a concurrent way. Variables are really just a convenience for making calculations or used as helpers in loops or generates. In general, they contain combinatorial evaluations or are used as iterators. In that sense they produce synthesis, but the sequentiality in their assignment is not synthesized per se, they will never make a signal change more than once in a single pass of a process (signals retain the last value assigned to them in a process).

This phrase that I use "single pass of a process" sounds very academic, and does not properly convey its relationship with hardware (hardware in this context being basically logic gates and flip flops). The process is evaluated when any signal in its sensitivity list changes. What this means in hardware is that the inputs to a combinatorial block changed, therefore it may be possible that the output or outputs of this block change as well. A signal may be assigned multiple times in a process, but this is only a way to code priority in evaluations (in describing how the combinatorial block works), not actual changes in the outputs in sequential manner. That is why it is said that the signals retain the last assignment in a process.

The best way to understand all this is to see how digital blocks that you can see in a schematic are coded in vhdl (or the language of your preference). When you get the hang of it, and start using variables as 'helpers', you'll see why they are what they are, why they are not the same as signals, and why the sequentiality in their assignment inside processes is not synthesized as such.

Answer 2

This is a hard one to answer. Not because the answer is difficult, but because it requires that yo twist your brain in a certain way that is hard to describe.

The most important thing to remember is that once it is put into hardware then everything is running concurrently. Even if it is written as if it were sequential.

The second thing is that even if you are writing sequential logic, it is still ran concurrently. In this case the logic that results from your code will behave in the same way as your sequential code, but not itself be sequential. Of course this can result in code that cannot be turned into digital logic. When we write VHDL there are two types of code: Synthesizeable and simulatable. Synthesizeable code can be turned into an FPGA or ASIC. While simulatable code can only be ran in a simulator, and cannot generate valid hardware.

Simulatable code is useful for testbenches and the like. Other things that make code non-synthesizeable are certain wait statements, some accesses to files, and the use of data types that are not supported for synthesis. Simulateable code is ran sequentially, not concurrently.

Finally, your code is very incorrect. The sensitivity list is wrong. It is not clocked (it is not synchronous logic), and once OVERFLOW goes high, it will never go low again.

If your code were turned into logic it would be optimized down to just "OVERFLOW<='1'". Since you have no clocking, it is assumed that cnt goes from -1 to 9 in no time at all which results in OVERFLOW being set immediately.