Creating FPGA designs

At the heart of every design are the modules and entities that compose it. From the testbench that’s used to verify the design to any instantiated components, they are all declared somewhere as a module or entity. For the example design that we’ll be covering in this chapter, we’ll be creating a set of underlying modules representing the functions that we can access via the buttons and switches on the evaluation board. We’ll use these switches to set values, and we’ll use five buttons to perform operations.

Project 1, Logic_ex, in Chapter 2 was our first project, so we’ll be starting our official project numbering here with project_2. Let’s look at the parts of a SystemVerilog module declaration:

module project_2
#(parameter SELECTOR,
  Parameter BITS = 16)
(input wire [BITS-1:0]          SW,
 input wire                     BTNC,
 input wire                     BTNU,
 input wire                     BTNL,
 input wire                     BTNR,
 input wire                     BTND,
 output logic signed [BITS-1:0] LED);

We are creating a module called project_2, which will be the top level of our design. The first section within #() is the parameter list, which allows us to define parameters that we can use within the port list or module. We can also define parameters anywhere within the module, and they can also be overridden during instantiation. However, parameters must be defined prior to use.

When writing or loading VHDL files into Vivado, make sure to specify the file type is VHDL 2008; by default, it will not be. This can be done when reading a VHDL file from the command line:

read_vhdl -vhdl2008 traffic_light.vhd

It can also be done in the properties pane of the GUI, as shown in Figure 3.1:

Figure 3.1: Specifying VHDL 2008

Let’s look at how we can create the same design interface using a VHDL entity.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use IEEE.math_real.all;

As we saw in Chapter 2, VHDL requires packages to be loaded for many operations and data types. Here, we are loading the std_logic_1164 package for a physical interface to our devices, numeric_std for some operations, and math_real for the log2 function that we will use for automatically sizing some of our buses:

entity project_2 is
  generic(
    SELECTOR : string;
    BITS     : integer := 16
  );
  port(
    SW   : in  std_logic_vector(BITS - 1 downto 0);
    BTNC : in  std_logic;
    BTNU : in  std_logic;
    BTNL : in  std_logic;
    BTNR : in  std_logic;
    BTND : in  std_logic;
    LED  : out std_logic_vector(BITS - 1 downto 0)
  );
end entity project_2;

The entity looks like the module of SystemVerilog. We have generics, which take the place of the parameters, and a port list.

How to create reusable code – parameters and generics

SystemVerilog provides a mechanism for configuring a design during instancing called parameters. VHDL provides a similar mechanism using generics. Both mechanisms can be used to override information in a design instantiation. The information can be used within the design to control the size of the data, as is the case with BITS, which has a default value of 16 if it’s not overridden.

If BITS is not overridden, then the instance of project_2 would use 16 switches as shown below:

Inst1 : project_2 generic_map(SELECTOR => "UNIQUE_CASE")…

If our board only had 8 switches, we could instance the design as follows:

Inst1 : project_2 generic_map(SELECTOR => "UNIQUE_CASE", BITS => 8)…

Parameters and generics can also control the instantiation of logic, entities, or modules, as we’ll see when we explore the case and if statements for the SystemVerilog module and VHDL architecture and the different ways we can find the leading one’s value. We can also create a parameter, SELECTOR, which has no default. This is a good way to make sure that something is set in the instantiation since there is no default. If it is not overridden, it will result in an error.

Parameters in SystemVerilog can be integers, strings, or even types:

#(parameter type SW_T = logic unsigned [15:0], …
(input  SW_T       SW, …

Here, we created a type named SW_T, which defaults to logic unsigned [15:0] and creates a port using this type named SW. When the module is instantiated, a new type can be passed, thus overriding the default and allowing for greater design reuse.

It is good practice to keep parameters intended to be overridden within the parameter list and use localparam, which cannot be overridden, within the module itself. Parameters provide us with a great way to express design intent. When you return to a design after a long period of time, magic numbers such as 3.14 have much less meaning than pi. For instance,

assign a = 3.14*(r**2);

is less clear than reading

assign a = pi*(r**2);

Also note that parameters can be derived from other parameters. This is especially useful when defining localparams.

Generics were a little more constrained pre-VHDL-2008. Prior to VHDL-2008, generics only allowed you to create constants that could be overridden when a design was instantiated. VHDL 2008 adds the capability of declaring generic types like the parameter list of SystemVerilog allows, as well as generic subprograms that can be specified upon instantiation:

generic(
    BITS : integer := 16;
    type SW_T;
    function no_func(SW : std_logic_vector(BITS-1 downto 0)) return unsigned);
  port(
    SW : in SW_T; ...
    );

Now that we have examined the module’s interface to the outside world, let’s look at the data types we’ll use in both languages.