Difference between revisions of "VHDL"
Line 1: | Line 1: | ||
[[Category:FPGAs]][[Category:Software]] | [[Category:FPGAs]][[Category:Software]] | ||
− | VHDL stands for VHSIC-HDL, which in turn stands for Very High Speed Integrated Circuit Hardware Description Language. It is one way in which hardware can be described. The guide below was adapted by notes originally written by Samuel Ginsberg, which can be downloaded as a PDF here. [[File:VHDL Notes 2016 updated SamuelGinsberg.pdf | + | VHDL stands for VHSIC-HDL, which in turn stands for Very High Speed Integrated Circuit Hardware Description Language. It is one way in which hardware can be described. The guide below was adapted by notes originally written by Samuel Ginsberg, which can be downloaded as a PDF here. [[File:VHDL Notes 2016 updated SamuelGinsberg.pdf]] |
Revision as of 10:45, 16 July 2020
VHDL stands for VHSIC-HDL, which in turn stands for Very High Speed Integrated Circuit Hardware Description Language. It is one way in which hardware can be described. The guide below was adapted by notes originally written by Samuel Ginsberg, which can be downloaded as a PDF here. File:VHDL Notes 2016 updated SamuelGinsberg.pdf
Contents
Structure and Behaviour
There are two fundamentally different ways of specifying logic. The first method is to specify the structure of the logic and the other method is to specify the behaviour of the system.
[Show/hide]
Structure
[Show/hide]
The structure of a system describes that system in terms of "what is connected to what". The system is thus broken down into smaller units which are connected together to form a whole. The whole unit is called an entity. Inputs and outputs to/from the entity are called ports.
TODO: IMAGE
In this illustration the overall entity is called Z. The input ports are called A, B and C. The output ports are called D and E. The interconnections inside the entity Z are called signals. You will observe that X and Y are themselves entities. The entities X and Y would in turn have to be specified in terms of either their behaviour or their structure. This nested definition system implies that by using structural descriptions very big and complex blocks may be built up out of a number of simple blocks. This is fundamental to problem solving of almost any type.
Behaviour
[Show/hide]
You will see that structural descriptions are extremely useful for building systems from smaller components. Ultimately we need to specify what each component actually does. In this case structural descriptions are of limited use. We need some way of describing the behaviour of the entities that we use. At the very minimum we need to specify the behaviour of the entities at the bottom of the hierarchical structure. VHDL thus provides a means of specifying the behaviour of entities by means of a behavioural description. Behavioural descriptions resemble a programming language. We will discuss syntax as we need it to implement the concepts that follow. Please bear in mind as we go that, despite the similarities, a VHDL description is a hardware description, and that the analogy to a programming language is actually fairly weak.
Entities
[Show/hide]
As we have mentioned an entity is a "box" with inputs and outputs called ports. We need to give the ports names and associate them with an entity. Here is an example of this:
1 entity hadder is
2 port
3 (inA, inB : in std_logic;
4 sum,carry : out std_logic); --note the semicolon
5 end hadder;
This entity declaration states that we are creating an entity called hadder. This entity has two inputs called inA and inB and two outputs called sum and carry. Further we have declared that the ports are all 'std_logic' values. A std_logic value is basically a binary bit, which can take on the value 0 and 1. Std_logic bits can also take on a few other states, such as high impedance and undefined, in order to closely model the behaviour of real logic bits. The entity is shown graphically here:
TODO: IMAGE
Architectures
[Show/hide]
Once we have declared the entity we need to describe how it works. We use an architecture to do this. We could use either a structural description or a behavioural one.
Suppose for the sake of the illustration that the above entity implements a half adder. Our adder's circuit diagram is as follows:
TODO: IMAGE
Here is an example of structural description:
1 architecture structure of hadder is
2 --We now need to describe the interface to the components that we are
3 --using. These components are described in the ALTERA MAXPLUS2 library.
4 component a_7408 --AND gate
5 port (a_2: in STD_LOGIC;
6 a_3: in STD_LOGIC;
7 a_1: out STD_LOGIC);
8 end component;
9 component a_7486 --XOR gate
10 port (a_2: in STD_LOGIC;
11 a_3: in STD_LOGIC;
12 a_1: out STD_LOGIC);
13 end component;
14 --Signals are like wires used to connect components
15 signal inputA,inputB : std_logic;
16 begin
17 --see equivalent diagram in notes to understand this.
18 inputA<=inA;
19 inputB<=inB;
20 myAND: a_7408 port map (a_2=>inputA,a_3=>inputB,a_1=>carry);
21 myXOR: a_7486 port map (a_2=>inputA,a_3=>inputB,a_1=>sum);
22 end structure;
The first thing that we do is state which components are contained in our box. These are an AND gate and an XOR gate. We also define the ports of these components. Note that the components were created previously and we are only using them here. We then define two signals. These signals are the internal "wires" which connect components together. The signals are inputA and inputB.
After we have defined all of the types of things that go into our description we need to instantiate them. We do that in the next section of code. We make an instance of the AND gate called myAND and an instance of the XOR gate called myXOR. When we instantiate the components we list how the inputs are connected to the signals. This effectively creates a netlist. A netlist is a list of how components connect together. The first two statements connect the internal signals inputA and inputB to the input ports, as shown in the circuit diagram.
Processes
[Show/hide]
We sometimes want a set of VHDL statements to execute sequentially, one after the other. This allows us to build up a set of instructions that are 'executed' one after the other. The execution of this list is triggered by some event happening, very often on a port of the entity.
As an example consider this simple flip flop design:
1 LIBRARY ieee;
2 USE ieee.std_logic_1164.all;
3 ENTITY test_proc1 IS
4 PORT
5 (D_input : IN STD_LOGIC;
6 clk_input : IN STD_LOGIC;
7 Q_output : OUT STD_LOGIC);
8 END test_proc1;
9 ARCHITECTURE a OF test_proc1 IS
10 BEGIN
11 PROCESS (clk_input) --trigger this when clk_input changes
12 BEGIN
13 if (clk_input='1') then
14 Q_output <= D_input;
15 end if;
16 END
In this example we are describing the behavior of a D type flip flop. The flip flop's D input is transferred to the Q output and held there on the rising edge of the clock signal. We declare an entity as before.
The architecture begins with the keyword 'Process' followed by a list of port names, in this case clk_input. This list is called a 'sensitivity list'. Whenever one (or more) of the items in the sensitivity list changes the code that is contained in the process is executed. In this example when clk_input changes, the code within the process is executed. This code examines the state of the clk_input bit and if it is high the Q output is updated to be equal to the D input. We achieve the rising edge triggered action by looking for a change in clk_input and then examining to see if the change was a rising or a falling edge.