using VHDL gate models
3.2 Identifiers, spaces and comments
VHDL is not case-sensitive (unlike C). Thus, ‘architecture’, ‘ARCHITECTURE’
and ‘aRcHiTeCtUrE’ are all equivalent and acceptable to a compiler. Similarly, identifiers (such as ‘And2’) may be mixed-case. It is strongly recommended, however, that the usual software engineering rules about identifiers should be applied:
● Meaningful, non-cryptic names should be used, based on English words.
● Use mixed-case with consistent use of case.
● Don’t use excessively long identifiers (use 15 characters or fewer).
● Don’t use identifiers that may be confused (e.g. two identifiers that differ by an underscore).
● Don’t redefine predefined identifiers, such as BIT or TIME.
● Identifiers may consist of letters, numbers and underscores (‘_’), but the first char-acter must be a letter, and two underscores in succession are not allowed. Extended identifiers may consist of any character, provided that the entire identifier is enclosed in backslashes (‘\’), e.g. \0%$#___&\. The strings in extended identi-fiers are case-sensitive. Use extended identiidenti-fiers with extreme caution.
Whitespace (spaces, carriage returns) should be used to make models more readable.
There is no difference between one whitespace character and many.
Comments may be included in a VHDL description by putting two hyphens on a line (‘--’). All text between the hyphens and the end of the line is ignored. This is similar to the C++ style of comment, which uses two slashes (‘//’). There is no C-style block comment (‘/*. . . */’) in VHDL. It is strongly recommended that comments should be included to aid in the understanding of VHDL code. Each VHDL file should include a header, which typically contains:
● the name(s) of the design units in the file;
● file name;
● a description of the code;
● limitations and known errors;
● any operating system and tool dependencies;
● the author(s), including a full address;
● a revision list, including dates.
For example:
–––––––––––––––––––––--- Design unit : And2(Example) (Entity and Architecture) -- :
-- File name : and2.vhd -- :
-- Description : Dataflow model of basic 2 input and
-- : gate. Inputs of type BIT.
Netlists 41
-- Limitations : None -- :
-- System : VHDL'93
-- :
-- Author : Mark Zwolinski
-- : Department of Electronics and Computer
-- : Science
-- : University of Southampton
-- : Southampton SO17 1BJ, UK
-- : [email protected]
---- Revision : Version 1.0 04/02/99
---3.3 Netlists
We have seen in Section 3.1 how to describe a two-input AND gate. Combinational logic is seldom that simple! Suppose we wish to build a circuit to implement the following truth table:
A B C Z
0 0 0 0
0 0 1 0
0 1 0 1
0 1 1 1
1 0 0 0
1 0 1 1
1 1 0 0
1 1 1 1
From a K-map, we can deduce that a minimal form of this function is
Therefore a VHDL implementation of this function might be:
entity comb_function is
port (a, b, c : in BIT; z: out BIT);
end entity comb_function;
architecture expression of comb_function is begin
z <= (not a and b) or (a and c);
end architecture expression;
Note the use of parentheses to ensure the correct order of evaluation – and and or have the same precedence, as described earlier.
Z A.B A.C
42 Combinational logic using VHDL gate models
While this model is perfectly acceptable as a description of a particular logical function, it does not correspond to any normally available piece of circuitry. It could be imple-mented as a PLA function, but if we wished to build this function on an integrated circuit using only standard logic gates we would need to rewrite the model in terms of those gates.
This might be done using some EDA program, but let us see how we can do this manually.
Let us write models of an Or2 gate and a Not1 gate in addition to the And2 gate shown earlier.
entity Or2 is
port (x, y : in BIT; z: out BIT);
end entity Or2;
architecture ex1 of Or2 is begin
z <= x or y;
end architecture ex1;
entity Not1 is
port (x : in BIT; z: out BIT);
end entity Not1;
architecture ex1 of Not1 is begin
z <= not x;
end architecture ex1;
There is no conflict in calling each of the architectures ‘ex1’ as each applies to a dif-ferent entity.
A VHDL description of the function above using these gates might be written as:
architecture netlist of comb_function is signal p, q, r : BIT;
begin
g1: entity WORK.Not1(ex1) port map (a, p);
g2: entity WORK.And2(ex1) port map (p, b, q);
g3: entity WORK.And2(ex1) port map (a, c, r);
g4: entity WORK.Or2(ex1) port map (q, r, z);
end architecture netlist;
Several new pieces of VHDL are introduced here. Within the architecture, we need to create instances of each gate. We also need to identify the signals that connect the gates to the rest of the world.
To identify the signals connected to each gate within the model, we have a signal declaration, which simply lists the names of the signals and their types.
To create an instance of a gate, we include a reference to it between the begin and end in the architecture. Generally, in VHDL objects must be declared before they are used. Here, however, we do not declare each gate explicitly but we do have to define exactly where to find each model and which architecture to use.
Netlists 43
‘WORK’ refers to the current working library. As each entity and architecture is com-piled, it is stored in a directory. We don’t want to know exactly which operating sys-tem directory or file is to be used; thus WORK is an operating syssys-tem-independent way of specifying that the compiler should look in the current working directory.
This is good software engineering practice; we should avoid writing VHDL that is specific to a particular EDA tool or system. ‘(ex1)’ refers, in each case, to the architecture of each gate model. This style of hierarchy description is called direct instantiation.
The instance has a name (g1), the type of the gate (Not1) and a clause showing how external signal names are mapped to internal signal names. The reserved words port map are used to show these mappings. Note that, as shown, the order of signals is important. We can assign signals in a different order:
g2: entity WORK.And2(ex1) port map (z => q, x => p, y =>b);
The direct instantiation style is usually preferred for simple netlists. An alternative style has the components declared before they are used:
architecture netlist2 of comb_function is component And2 is
port (x, y : in BIT; z: out BIT);
end component And2;
component Or2 is
port (x, y : in BIT; z: out BIT);
end component Or2;
component Not1 is
port (x : in BIT; z: out BIT);
end component Not1;
signal p, q, r : BIT;
begin
g1: Not1 port map (a, p);
g2: And2 port map (p, b, q);
g3: And2 port map (a, c, r);
g4: Or2 port map (q, r, z);
end architecture netlist2;
The component declaration tells the compiler what each gate looks like. The com-ponent declaration is identical to an entity declaration, with the reserved word entity replaced by component. Here, the component declaration has the same name as the entity declaration and the ports also have the same names. We also assume here that there is only one architecture for each gate, or more accurately, that if more than one architecture exists, we will use the last one compiled. This is known as the default con-figuration. Later, we will see how different architectures can be explicitly mapped to particular instances, and how we can associate entities and components with different names.
44 Combinational logic using VHDL gate models
2 ns 5 ns
Suppressed pulse
4 ns 4 ns
X
Z
Figure 3.1 Inertial delay of 4 ns.