Logic Design - Packages in SystemVerilog

[Edit of Image1]

Introduction

Hey it's a me again @drifter1!

Today we continue with the Logic Design series on SystemVerilog in order to talk about Packages.

So, without further ado, let's get straight into it!

Design Hierarchy

In Verilog all data and methods (functions, tasks) are defined in modules. Only system tasks and functions are global and can be accessed from anywhere. Thus, modules contain instances of other modules. But, this module hierarchy can easily becomes complicated, which leads to much time being spent in port list maintenance.

SystemVerilog enhances the hierarchical design introducing the module ports, that we've already discussed. These allow any data type to be passed. Additionally;

• modules can be nested (module declared within another module)
• port connections are named far simpler
• interfaces allow for bundled connections between modules
• time and precision specs are bound to modules

and then there are also packages, which we will discuss today.

Packages

Packages are introduced for sharing common code across multiple modules, programs, interfaces etc. This basically allows code to be re-usable by definition.

Package Definition

Packages are defined within the package and endpackage keywords:

package name;
    ...
endpackage

They can contain parameters, data, types, tasks, functions, sequences, properties, but not assign statements. Variables need to be declared before any initial and always blocks.

Hierarchical definitions are also forbidden, except if they are created within the package or are the cause of importing another package.

Importing Packages

Packages are imported using the import keyword followed by the package name and the scope resolution operator ::, which specifies what to import. Importing everything is as simple as adding a * after that operator.

For example:

import package1::myFunc;
import package2::*;

imports only the function myFunc from package1, and everything from package2.

Definition Collision

If the same definition (identifier) exists in both the top level and the imported package, we are talking about a collision of definitions. From these two the top level definition will be preferred by the simulator. For example, this could mean that the initial value of the top level would be used instead of the package's value for some variable.

In order to "apply" the package's value the package name has to be explicitly mentioned by using the :: operator, as shown below.

value = var;                // use top level definition
value = packageName::var;   // use package definition

RESOURCES:

References

1. https://www.chipverify.com/systemverilog/systemverilog-tutorial
2. https://www.asic-world.com/systemverilog/tutorial.html

Images

1. https://www.flickr.com/photos/creative_stock/5227842611

Block diagrams and other visualizations were made using draw.io

Previous articles of the series

Verilog

• Introduction → Basic Syntax, Data Types, Operators, Modules
• Combinational Logic → Assign Statement, Always Block, Control Blocks, Gate-Level Modeling and Primitives, User-Defined Primitives
• Combinational Logic Examples → One Circuit - Four Implementations, Encoder, Decoder, Multiplexer
• Sequential Logic → Procedural Blocks (Initial, Always), Blocking and Non-Blocking Assignments, Statement Groups
• Sequential Logic Examples → Flip Flops (DFF, TFF, JKFF, SRFF), N-bit Counter, Single-Port RAM
• Finite-State Machines → Finite-State Machine (FSM), FSM Types, State Encoding, Modeling FSMs in Verilog
• Finite-State Machine Examples → Moore FSM Example (1 and 2 always blocks), Mealy FSM Example (1, 2 and 3 always blocks)
• Testbenches and Simulation → Testbenches (DUT / UUT, Syntax, Test Cases), System Tasks, Simulation Tools
• Combinational Logic Testbench Example → Half Adder Implementation, Testbench and Simulation
• Sequential Logic Testbench Example → Sequence Detector FSM Implementation, Testbench and Simulation
• Functions and Tasks → Function and Task Syntax, Calling, Rules, Examples
• Module Parameters and Generate Block → Parameterized Module (Parameters, Instantiation and Overriding Parameters), Generate Blocks (For, If, Case)
• Compiler Directives → Summary of Verilog's Compiler Directives (Include, Macros, Timescale, Conditional Compilation, etc.)
• Switch Level Modeling → Transistors, Switch Primitives (NMOS, PMOS, CMOS, Bidirectional, Resistive), Signal Strengths

SystemVerilog

• From Verilog To SystemVerilog → Data Types, Arrays, Structures, Operators and Expressions
• Control Flow → Additional Procedural Blocks, Loops, Conditional Statements, Functions and Task Features
• Processes → Fork - Join in Verilog and SystemVerilog, Process Control (wait fork, disable fork)
• Events → Interprocess Communication, Events (Definition, Triggering, Waiting, Sequencing, Merging, as Arguments)
• Semaphores and Mailboxes → Semaphores (Creation, Methods), Mailboxes (Definition, Methods)
• Interfaces (part 1) → Interfaces (Definition, Port and Signal Lists, Instantiation), Modports
• Interfaces (part 2) → Parameters, Tasks and Functions (Importing, Exporting), Clocking Blocks (Input and Output Skews)
• Classes (part 1) → Classes (Definition, Constructor Function, Creating Objects, Accessing Class Members, Static and Constant Class Members, Arrays)
• Classes (part 2) → Copying Objects (Shallow and Deep Copy), Inheritance, Polymorphism, Virtual Methods
• Classes (part 3) → Parameterized Classes, Out-of-Block Method Declaration, Data Accessibility, Abstract / Virtual Classes
• Program Blocks → Design and Testbench, Program Block (Reactive Region, Allowed Constructs)

Final words | Next up

And this is actually it for today's post!

Next time we might start covering Constraints...

See Ya!

Keep on drifting!