Doulos VHDL Training : HEGV : Components vs. Processes

Last month, it was suggested that designs could be created using a more software-oriented behavioural style of VHDL coding rather than the explicit structural coding style used to create the MUX_2 design. Before we look at how to describe a MUX_2 using a behavioural coding approach, let’s deal with how VHDL designs operate — the MUX_2 will serve as our example.

signal SELB, FB: STD_LOGIC;

begin
  G1: INV port map (SEL, SELB);
  G2: AOI port map (SEL, A, SELB, B, FB);
  G3: INV port map (FB, F);

Sequential, parallel or concurrent?

Conceptually, the AOI and INV components operate concurrently. They do not operate in parallel. Sorry for being pedantic but this subtlety is important. Parallel means operate simultaneously, usually without communication between the parallel elements (“never touching” in my dictionary). Concurrency means cooperating, taking place at the same time or location.

In VHDL, we usually speak of elements executing rather than operating (or cooperating), so in VHDL elements can execute concurrently, in parallel or in sequence. We can see that the AOI and INV components execute concurrently — they communicate via the internal signals. You might think that they execute in sequence. (Almost!) If SEL changes and A,B have the same value then the G1 instance of INV executes in parallel with AOI. As FB does not change value the G3 instance of INV does not execute. This simple scenario shows the absence of parallel execution (G3 doesn’t execute whilst G1 and G2 are executing) and sequential execution (G3 doesn’t execute after G2); this leaves us with concurrency.

We often say to ourselves that the AOI and INV are connected. We now know that being connected means concurrent execution. In our example, the functionality of the MUX_2 is implemented via components executing concurrently.

Processes

To create software-style VHDL, we first have to deal with processes. We can think of a VHDL process as a blob of hardware. Instead of instantiating a component in an architecture, we can instantiate a process.

For our MUX_2 example, let’s dispense with concurrency altogether. Let’s use a single process. Processes enable you to code up a design by describing the design’s functionality using statements executing in sequence. This is different from the way in which components create functionality. Components create functionality by executing concurrently with respect to each other.

A process can contain signal assignments to describe the functionality of a design. Thus, we can re-code our MUX_2 example using a single process rather than three component instantiations.

Processes do not have to exist in isolation. A process is a concurrent statement inside an architecture body just like a component instantiation. We know that components can be connected together using signals and so too can processes. So processes execute with respect to each other concurrently, but internally they execute statements in sequence. You can describe functionality using sequential statements inside processes. And you can create multiple processes within an architecture to create your design. But there’s a couple of things you can’t do — a component instance is not a sequential statement so you can’t execute a component inside a process. And you can’t embed one process inside another in the way that you can embed component instances within each other, so there’s no way to build a process hierarchy. To build a design hierarchy, you have to use components.

An extension to the approach of behavioural coding is to describe the functionality of the design by using software-oriented methods exclusively that don’t use components. In VHDL, this is accomplished using processes to replace component instances. Processes enable you to code up a design by describing the design’s functionality using statements executing in sequence. Instead of writing:

Now, of course it’s inside the processes that all the action takes place! Until next month...