Logic Design - Program Blocks in SystemVerilog

avatar

[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 the Program Block.

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


Design and Testbench

In Verilog, both the design and the testbench are defined as a module. Each such module can contain other modules (hierarchical design), nets, variables, procedural blocks etc. in order to describe the hardware functionality.

In order to separate the design and testbench, SystemVerilog introduces the program block. This block is all about verification and created in a way that allows it to be more effective and re-usable.


Program Block

A program block is enclosed within the program and endprogram keywords, and has the following syntax:

program <name> [port_list];
    ...
endprogram

So, it's quite similar to a module.

Reactive Region of Simulation Cycle

One of the main differences of modules and program blocks is that program blocks execute just before the simulation time advances. This region of the simulation cycle is known as the reactive region, allowing all of the design statements to execute correctly, and giving the testbench / program access to the correct updated values. In other words, the race conditions between the design and testbench are avoided.

Allowed Constructs

Program blocks are very similar to modules. They can contain ports, interfaces, and initial, final blocks, but not always blocks. That way the clocking of the design is used when driving or sampling signals.

Additionally, tasks and functions defined within modules (the design) can be called from within a program block. But, tasks and functions defined within a program block cannot be called from within modules (the design).

When the number of ports is large, interfaces should be used in order to connect with the design (DUT). This improves the readability by quite a bit.

Finally, the $exit control task should be added to the end of the testbench / program (at the end of some initial block) in order to close down all "spawned" threads.


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

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

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!

Posted with STEMGeeks



0
0
0.000
0 comments