In the above example, the highlighted code differentiates between:

• keywords like ENTITY, ARCHITECTURE, and BEGIN which denote the structure of our code.
• identifiers like s1, a, mux_2x1, and df, which are just names we’ve chosen for different parts of our design.
• operators like <=, AND, et al, which can create and set values referenced by identifiers.

We’ve created a design entity (commonly referred to as a module).
3.1 in the IEEE Standard VHDL Language Reference Manual:

The design entity is the primary hardware abstraction in VHDL. It represents a portion of a hardware design that has well-defined inputs and outputs and performs a well-defined function. A design entity may represent an entire system, a subsystem, a board, a chip, a macro-cell, a logic gate, or any level of abstraction in-between.

To reduce confusion with the ENTITY keyword, we’ll call this a module from now on. Basically, a module is a full description of a thing. It describes:

• The ENTITY – the inputs and outputs; our interface to our mux.
• The ARCHITECTURE – the insides of our circuit; what happens to the inputs to create the output

Signals are the basic data values in VHDL. We don’t use the term variable because it is reserved for sequential processes which won’t be covered in this guide.

Because we’re modeling digital circuits, signals can be thought of as the wires connecting components together. On line 12 of our mux, we declare the existence of our three extra signals. These are the “internal” wires in our schematic. We also have to give them a type, of BIT. This is important so that we know they’re compatible with our inputs and outputs, which are also type BIT.

We assign signals with the <= operator. This also informs us of the direction of our data. For example, s1 <= s2 means data is being read in from s2 and written out to s2.

The ENTITY describes the interface to our thing. The inputs and outputs, the wires we can set and read from, is described in the ENTITY.

• Inputs can only be read and cannot be assigned: input <= a_signal will cause an error.
• Outputs can only be assigned and cannot be read: a_signal <= output will also cause an error.

These are referred to as ports. If we’re designing something that takes inputs from the outside world, does something with them, and then delivers the outputs back to the outside world, then we need to declare ports in our ENTITY:

ENTITY another_thing IS
   PORT ( from_the_outside_world    : IN BIT;
          back_to_the_outside_world : OUT BIT );
END another_thing;

You can see that each port is given 1) a name, 2) a direction, and 3) a type. For example: a : IN BIT; is named a, is an input from the outside world, and is a single bit. Ports need a direction because it makes it easier for someone to understand how the circuit is supposed to work and acts as a check that we aren’t connecting different circuits incorrectly. Because ports are technically signals, too, we can reuse their names in our ARCHITECTURE when reading their values in or writing their values out.

The ARCHITECTURE structure describes what goes on inside our schematic. On line 11 we start by giving our architecture a name: df, and declaring that this is the architecture OF mux_2x1. On line 18, we END our architecture with the same name, similar to our we structured our entity syntax.

Naming

The name df is shorthand for dataflow. Dataflow is the name of the style used. In the coming weeks, we’ll also discuss behavioral (behav) and structural (struct) styles. We could have named our architecture GooGooGaGa if we wanted to, but it’s clearer to choose names based on the architecture style. There can be overlap between styles, and there’s not always a clean distinction, so use your best judgement when naming.

In dataflow styles, the architecture is just a set of signal assignments and equations. We are just describing how data flows. Once you see examples of behavioral and structural styles, the distinction will be more clear.

Declarations and Statements

Any extra signal or component declarations will go between the ARCHITECTURE _ OF _ IS and BEGIN lines, which is line 12 in our example. We need to declare signals, so that we give them 1) a type, e.g. BIT, and 2) a name for us to use later. We need to declare components because…well you can check out the next section for that. After the BEGIN, we can put our statements. Statements are essentially lines which assign values to signals. They are how we make our circuit…well…work.

So to wrap up declarations go between ARCHITECTURE and BEGIN, and all the statements that do stuff go between BEGIN and END.

I alluded to extra components earlier, beyond simple NOT, AND, and OR gates. This is the cool part about VHDL! We can bit-by-bit (no pun intended 🤡) build up a bigger circuit from smaller component circuits.

Let’s look at another example where we use something we already made (the and4) and focus on the architecture body starting at line 14.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
ENTITY and4 IS
    PORT ( in1, in2, in3, in4 : IN BIT;
           out1 : OUT BIT);
END and4;

ARCHITECTURE df OF and4 IS
BEGIN
    out1 <= in1 and in2 and in3 and in4;
END df;

-- ... some time later...
-- ... a different ENTITY declaration for something_else...
-- ...
-- ... and its architecture
ARCHITECTURE struct OF something_else IS
    SIGNAL sig0, sig1, sig2, sig3, sig4 : BIT;
    
    COMPONENT and4_gate IS
        PORT ( in1, in2, in3, in4 : IN BIT;
               out1 : OUT BIT);
    END COMPONENT;
BEGIN
    -- ...
    a_name_for_this_part_of_my_schematic: and4 PORT MAP (sig0, sig1, sig2, sig3, sig4);
    -- ...
END struct;
-- ...

We can see that we declare the extra signals we plan on using. We mentioned earlier that we need to do this so we can use their names later on.
That’s simple enough. After that we have component declaration.

Okay, what’s that about?

Well, we need to declare the existence of any extra wires, and also declare the existence of any extra modules. We have to declare the existence of our custom 4-input AND gate in line 18. The component declaration looks very similar to our ENTITY declaration on line 1. In fact, VHDL has to match the component declaration exactly to a corresponding entity, for us to combine modules together. Otherwise, when we go to use it in line 24, VHDL will crash and say, “how in tarnation am I supposed to use something that doesn’t exist?”. Each module exists in its own little world, and we have to manually tell VHDL that each of those other little worlds exist when we want to use them together.

Whew.
This is a long section, I know, I know, hush child! There’s another picture coming soon and we’re almost done.

So speaking of line 24, what the devil is going on there? Besides assigning signals with operations like output <= my_signal, or another_signal <= s0 nand s1, we can also assign signals by using other modules we’ve built! And like we went over earlier, between the BEGIN and END of the architecture body is where all these assignments happen.

We already know how to do basic assignment and use basic operators, so I’m gonna skip on ahead to…

Port Maps

Port mapping is, quite simply, mapping signals to ports of other instances. In line 24, I decided to use the and4 we made earlier to connect up some signals in my circuit.

• First, we give a name to that particular and4 instance (a_name_for_this_part_of_my_schematic). Each and4 I create here is called making a new instance, compared to just declaring it as a component. Everything in our circuit needs a name unless it’s a basic AND, OR, NOT, NOR, et al gate.
• Then, we specify that we’re using an and4.
• Last, we specify how to connect our signals to the component.

We need to name them uniquely because we might have multiple and4’s, and then how do we refer to them? Here’s a pretty silly circuit:

I spared you the horror of seeing all the wire criss-crossings. The inputs are all going to each of the and4 units. Here’s the module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
ENTITY silly_circuit IS
    PORT ( in1, in2, in3, in4 : IN BIT;
           out1 : OUT BIT);
END silly_circuit;

ARCHITECTURE struct OF something_else IS
    SIGNAL s0, s1, s2 : BIT;

    COMPONENT and4_gate IS
        PORT ( in1, in2, in3, in4 : IN BIT;
               out1 : OUT BIT);
    END COMPONENT;

    COMPONENT and3_gate IS
        PORT ( in1, in2, in3 : IN BIT;
               out1 : OUT BIT);
    END COMPONENT;
BEGIN
    -- maps by position:
    -- maps in1 to the first port of the and4,
    --      in2 to the second port of the and4,
    --      etc, sig0 to the last port of the and4
    a4_1: and4 PORT MAP (in1, in2, in3, in4, sig0); 

    -- maps by position:
    -- maps in2 to the first port of the and4,
    --      in3 to the second port of the and4,
    --      etc
    a4_2: and4 PORT MAP (in2, in3, in4, in1, sig1);

    -- maps by named value (as PORT MAP ( to port => from signal, to port => from signal, ...)
    -- maps in2 to and4::in2,
    --      in3 to and4::in3,
    --      in4 to and4::in1, etc,
    a4_3: and4 PORT MAP (in2 => in2, in3 => in3, in1 => in4, in4 => in1, out1 => sig2);

    -- maps by named value
    -- maps sig0 to and3::in1,
    --      sig2 to and3::in2,
    --      sig1 to and3::in3,
    --      out1 to and3::out1
    a3_1: and4 PORT MAP (in1 => sig0, in3 => sig1, in2 => sig2, out1 => out1);
END struct;

The last takeaways of this code is:

• We named the and4’s and the and3 in our silly_circuit, just like we had to name the signals, because they aren’t basic gates.
• The architecture is named struct for structural style, which involves (structurally) building up logic with smaller components, as we are doing here.
• A common confusion is how the names don’t clash here. You might see all the in1’s and such and wonder which inN is referring to what? Well earlier I mentioned that each module exists in its own little world. The names exist in their own little world, too (called scope). When we’re in our architecture body, we’re in our silly_circuit world, so the in1 refers only to the actual input, as expected. Remember, the only reason we have the COMPONENT declaration is so that VHDL knows to go out and find that module somewhere. The names in the component declaration are only for matching against the original module.
• There’s two different way to map signals to our instances.
  1. The first way is positional. Each signal just maps directly to the first, second, third, etc port on the component. Obviously if we had more signals listed than ports, we’d get an error.
  2. The second is way is by naming which port is getting mapped to. This is generally clearer, but more verbose, and it won’t matter what order you put the signals in the list.
• If we were to mismatch the direction of the port mappings, and map our input to a component’s output, VHDL would give us an error. BUT, if we mismatched ports with the same type and direction, we’d just get really wonky behavior from our circuit…or not! So double check your ports!