Verilog HDL: Hardware Description

Language
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
History and Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Modules and Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Significance and Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What is module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Guidelines for Declaring Module Names in Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Additional Tips:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Types of Module Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Types of Port Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Difference between Named and Position Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Benefits of Module Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Introduction
Verilog HDL (Hardware Description Language) is a standardized hardware description language
widely used in the electronic design automation (EDA) industry for designing, modeling, and
verifying digital circuits and systems. It is an IEEE standard language, with the latest version being
IEEE 1800-2017 (SystemVerilog).

Key Points
Hardware Description
Verilog HDL is a textual language that allows designers to describe the behavior and structure of
digital circuits at various levels of abstraction, from gate-level to system-level.

Design Entry
Verilog HDL code is used as the design entry for synthesizing digital circuits onto hardware
targets like FPGAs or ASICs.

Simulation
Verilog HDL code can be simulated using EDA tools to verify the functionality and timing of the
design before actual hardware implementation.

Levels of Abstraction
Verilog HDL supports different levels of abstraction, including gate-level (primitives like AND,

1
 OR, NOT), data-flow (assignments and operations), behavioral (algorithms and processes), and
system-level (modules and hierarchies).

Concurrency and Parallelism

Verilog HDL has constructs to model concurrent and parallel operations, which are essential for
describing hardware behavior.

Modules and Hierarchy

Verilog HDL designs are organized into modules, which can be instantiated and connected to
create hierarchical designs.

Testbench
Verilog HDL includes constructs for writing testbenches, which are used for verifying the
functionality of the design by applying test vectors and monitoring outputs.

Synthesis
Verilog HDL code can be synthesized by EDA tools to generate gate-level netlists, which can be
mapped onto target hardware devices like FPGAs or ASICs.

Language Standards
Verilog HDL has gone through several revisions and standardizations, with the latest version
being IEEE 1800-2017 (SystemVerilog).

Industry Adoption
Verilog HDL is widely adopted and supported by major EDA tool vendors and semiconductor
companies for digital design and verification.

History and Evolution

Origins (1980s)
Verilog HDL was originally developed at Gateway Design Automation in the mid-1980s as a
proprietary hardware description language for simulation and modeling. It was created by Phil
Moorby and became popular as an alternative to the HDL used by valid at the time.

Standardization (1990s)
In 1990, Cadence Design Systems hired the original developers of Verilog and began promoting it
as an open language. In 1995, Verilog HDL was officially standardized as IEEE 1364-1995 by the
IEEE Standards Association, allowing widespread adoption and compatibility across EDA tools.

Revisions and Updates

Verilog HDL underwent several revisions to enhance its capabilities and accommodate new
design requirements, including IEEE 1364-2001 (Verilog-2001), IEEE 1364-2005 (Verilog-2005),
IEEE 1800-2009 (SystemVerilog-2009), IEEE 1800-2012 (SystemVerilog-2012), and IEEE 1800-2017
(SystemVerilog-2017).

SystemVerilog
In the early 2000s, the need for a more robust and feature-rich language led to the development

2
 of SystemVerilog, a superset of Verilog HDL, incorporating additional features for design,
verification, and modeling at higher levels of abstraction. It was standardized by the IEEE and
became popular for complex system-on-chip (SoC) designs.

Continued Evolution
Verilog HDL and SystemVerilog continue to evolve to meet the demands of modern digital
design, incorporating features for advanced verification, low-power design, and emerging
technologies like quantum computing.

Modules and Instances

1. Module Definition: A module in Verilog HDL is a fundamental building block used to describe
and encapsulate a specific digital hardware design entity or component. It defines the interface
(ports) and the internal functionality (logic) of a digital circuit.

2. Hierarchical Design: Modules can be instantiated within other modules, enabling a hierarchical
design approach. This allows complex designs to be broken down into smaller, more
manageable components.

3. Reusability: Modules promote design reuse, as they can be instantiated multiple times within
the same design or across different designs.

4. Module Instance: A module instance is a specific occurrence or usage of a module within

another module or the top-level design. It is the process of creating an instance of a pre-defined
module and connecting it to the appropriate signals or ports.

5. Regular Instance: A regular module instance is a single occurrence of a module within another
module or design.

6. Array of Instances: Verilog HDL also allows creating an array of module instances, which is
useful when you need multiple instances of the same module with a specific pattern or
indexing.

Significance and Impact

Verilog HDL, along with its extension SystemVerilog, plays a crucial role in the design and
verification of complex digital systems, enabling hardware designers to describe, simulate, and
synthesize their designs effectively. It has become an essential part of the digital design flow and is
widely taught in electrical engineering and computer science curricula.

Verilog HDL’s history exemplifies the evolution of hardware description languages, from
proprietary origins to industry-wide standardization and adoption, enabling the design and
verification of increasingly complex digital systems.

What is module
A module in VHDL or Verilog is a block of code that encapsulates a specific function or component. It
allows you to define ports and internal logic that can be instantiated and reused. Here is the basic
syntax for defining a module:

3
 module module_name ( port_list );

// Declarations (Optional)

// Statements (Optional)

// Instantiations (Optional)

endmodule

Explanation
• module_name: Name of the module.

• port_list: List of input and output ports with their directions specified. Example: input
[3:0] in_port, output reg out_port.

• Declarations: Declarations of internal signals, variables, and registers.

• Statements: Behavioral or procedural statements defining the functionality of the module.

• Instantiations: Instantiation of other modules or primitives within the current module.

Guidelines for Declaring Module

Names in Verilog
Verilog module names should follow certain conventions to ensure clarity, readability, and avoid
conflicts. Here are some recommended guidelines:

1. Use underscores: Verilog uses underscores to separate words in a module name. This enhances
readability. Example: adder_16bit instead of adder16bit

2. Use lowercase letters: While Verilog is case-insensitive, it’s good practice to stick to lowercase
letters for consistency. Example: adder_16bit instead of Adder_16bit

3. Avoid special characters: Refrain from using special characters like !, @, #, etc. in module
names. Example: adder_16bit instead of adder!16bit

4. Avoid numbers: Unless necessary (e.g., version numbers or unique identifiers), avoid using
numbers in module names. Example: adder_16bit instead of adder16bit

5. Keep it short: Aim for concise module names consisting of 1-2 words. Example: adder_16bit
instead of advanced_16_bit_adder

6. Use descriptive names: Choose names that clearly describe the module’s purpose or
functionality. Example: adder_16bit instead of x

7. Avoid ambiguity: Select module names that are specific and avoid ambiguity. Example:
adder_16bit instead of adder

8. Check for conflicts: Ensure that the chosen module name doesn’t conflict with existing
modules or packages. Example: adder_16bit instead of adder (which might already exist as a

4
 module in Verilog)

By adhering to these guidelines, developers can create Verilog modules with clear, descriptive, and
unique names, facilitating understanding and maintenance.

Additional Tips:
• Consistent naming convention: Maintain consistency in naming conventions across your
design.

• Avoid reserved words: Steer clear of using Verilog reserved words or keywords in module
names.

• Descriptive names: Use descriptive names to elucidate the purpose of each module.

• Avoid long names: Lengthy or convoluted names can hinder readability and comprehension.

Types of Module Instances

Structural instance
Used to create a hierarchical design by instantiating a module within another module.

module Adder (
input [3:0] A,
input [3:0] B,
output [4:0] Sum
);

assign Sum = A + B;

endmodule

module TopModule;

// Structural instance
Adder adder_instance (
.A(A_input),
.B(B_input),
.Sum(Sum_output)
);

// Input and output signals

reg [3:0] A_input;
reg [3:0] B_input;
wire [4:0] Sum_output;

// Testbench code or further module implementation here

endmodule

5
Behavioral instance
Utilized to create a behavioral model of a module.

module Counter (
input clk,
output reg [3:0] count
);

always @(posedge clk) begin

count <= count + 1;
end

endmodule

module TopModule;

// Behavioral instance
Counter counter_instance (
.clk(clock),
.count(counter_output)
);

// Clock signal
reg clock;

// Output signal
reg [3:0] counter_output;

// Testbench code or further module implementation here

endmodule

Parameterized instance
Applied to create a module instance with parameters that can be changed at instantiation time.

module ParameterizedModule #(
parameter WIDTH = 8
)(
input [WIDTH-1:0] data_in,
output [WIDTH-1:0] data_out
);

// Some parameterized logic

assign data_out = data_in + 1;

endmodule

module TopModule;

6
 // Parameterized instance
ParameterizedModule #(4) param_instance (
.data_in(input_data),
.data_out(output_data)
);

// Input and output signals

reg [3:0] input_data;
wire [3:0] output_data;

// Testbench code or further module implementation here

endmodule

Array instance
Employed to create an array of module instances.

module TopModule;

// Array instance
Adder adder_instances [3:0] (
.A(A_inputs),
.B(B_inputs),
.Sum(Sum_outputs)
);

// Input and output arrays

reg [3:0] A_inputs [3:0];
reg [3:0] B_inputs [3:0];
wire [4:0] Sum_outputs [3:0];

// Testbench code or further module implementation here

endmodule

Types of Port Association

Named association
Preferred method where each port in the module is explicitly connected to a specific wire or
signal in the instance. This enhances readability and reduces errors.

module Adder (
input [3:0] A,
input [3:0] B,
output [4:0] Sum
);

7
 assign Sum = A + B;

endmodule

module TopModule;

// Named association
Adder adder_instance (
.A(A_input), // Connect A_input to A port
.B(B_input), // Connect B_input to B port
.Sum(Sum_output) // Connect Sum_output to Sum port
);

// Input and output signals

reg [3:0] A_input;
reg [3:0] B_input;
wire [4:0] Sum_output;

// Testbench code or further module implementation here

endmodule

Positional association
Involves matching the order of ports in the instance’s definition with the order in the module’s
definition. This approach can lead to errors if the order changes.

module Adder (
input [3:0] A,
input [3:0] B,
output [4:0] Sum
);

assign Sum = A + B;

endmodule

module TopModule;

// Positional association
Adder adder_instance (
A_input, // Connect A_input to A port
B_input, // Connect B_input to B port
Sum_output // Connect Sum_output to Sum port
);

// Input and output signals

reg [3:0] A_input;
reg [3:0] B_input;
wire [4:0] Sum_output;

8
 // Testbench code or further module implementation here

endmodule

Difference between Named and

Position Instance
Aspect Named Association Positional Association

Syntax module_instance module_instance

(.port_name(wire_name)); (.port1(wire1), .port2(wire2),
…);

Port Connection Explicitly specify the port Implicitly connect ports in the
connection order they are defined

Error Prone Less error-prone due to explicit More error-prone due to

port connection implicit port connection

Readability More readable due to explicit Less readable due to implicit

port connection port connection

Maintainability Easier to maintain due to More difficult to maintain due

explicit port connection to implicit port connection

Reusability More reusable due to explicit Less reusable due to implicit

port connection port connection

Example module top; wire w; my_module module top; wire w; my_module

my_instance (.w(w)); endmodule my_instance (.a(w)); endmodule

In named association, the port connection is explicitly specified using the .port_name(wire_name)
syntax. This makes it easier to read and maintain the code, as the port connection is clearly
specified.

In positional association, the port connection is implicitly specified by the order in which the ports
are defined. This can lead to errors if the order of the ports is changed, making it less readable and
maintainable.

In general, named association is recommended over positional association due to its improved
readability, maintainability, and reusability.

Benefits of Module Instances

• Code Reusability:

◦ Modules promote code reuse by encapsulating functionality.

◦ Instances of modules can be created multiple times within a program or design, saving time
and effort.

9
 • Modular Design:

◦ Modules encourage a modular design approach, breaking down complex problems into
smaller, manageable units.

◦ This improves code organization and maintainability by separating concerns into distinct
modules.

• Scalability:

◦ Module instances facilitate scalability in designs.

◦ You can easily adjust the complexity of your program or design by adding or removing
instances as needed.

◦ This flexibility allows for easier adaptation to changing requirements or system

specifications.

10