Introduction to Hardware Description Languages - 3 | Embedded Systems (Web) - Computer Science Engineering (CSE) PDF Download

Instructional Objectives 
At the end of the lesson the student should be able to
• Call a task and a function in a Verilog code and distinguish between them
• Plan and write test benches to a Verilog code such that it can be simulated to check the desired results and also test the source code
• Explain what are User Defined Primitives, classify them and use them in code

Task and Function

Task 
Tasks are used in all programming languages, generally known as procedures or sub- routines. Many lines of code are enclosed in -task....end task- brackets. Data is passed to the task, processing done, and the result returned to the main program. They have to be specifically called, with data in and out, rather than just wired in to the general netlist. Included in the main body of code, they can be called many times, reducing code repetition.

• Tasks are defined in the module in which they are used. it is possible to define a task in a separate file and use compile directive 'include to include the task in the file which instantiates the task.
• Tasks can include timing delays, like posedge, negedge, # delay and wait.
• Tasks can have any number of inputs and outputs
. • The variables declared within the task are local to that task. The order of declaration within the task defines how the variables passed to the task by the caller are used.
• Task can take, drive and source global variables, when no local variables are used. When local variables are used it assigns the output only at the end of task execution.
• One task can call another task or function.
• Task can be used for modeling both combinational and sequential logics.
• A task must be specifically called with a statement, it cannot be used within an expression as a function can.

Syntax
• task begins with the keyword task and ends with the keyword endtask
• Input and output are declared after the keyword task.
• Local variables are declared after input and output declaration.
module simple_task();
task convert;
input [7:0] temp_in;

output [7:0] temp_out;
begin
temp_out = (9/5) *( temp_in + 32)
end
endtask
endmodule
Example - Task using Global Variables
module task_global ();
reg[7:0] temp_in;
reg [7:0] temp_out;
task convert;
always@(temp_in) begin temp_out = (9/5) *( temp_in + 32)
end
endtask
endmodule

Calling a task

Lets assume that the task in example 1 is stored in a file called mytask.v. Advantage of coding the task in a separate file is that it can then be used in multiple modules.
module task_calling (temp_a, temp_b, temp_c, temp_d);
input [7:0] temp_a, temp_c;
output [7:0] temp_b, temp_d;
reg [7:0] temp_b, temp_d;
`include "mytask.v" always @ (temp_a) Begin convert (temp_a, temp_b);
End always @ (temp_c) Begin convert (temp_c, temp_d);

Automatic (Re-entrant) Tasks 
Tasks are normally static in nature. All declared items are statically allocated and they are shared across all uses of the task executing concurrently. Therefore if a task is called simultaneously from two places in the code, these task calls will operate on the same task variables. it is highly likely that the result of such operation be incorrect. Thus, keyword automatic is added in front of the task keyword to make the tasks re-entrant. All items declared within the automatic task are allocated dynamically for each invocation. Each task call operates in an independent space.
End
Endmodule

Example // Module that contains an automatic re-entrant task
//there are two clocks, clk2 runs at twice the frequency of clk and is synchronous with it.
module top;
reg[15:0] cd_xor, ef_xor;
// variables in module top reg[15:0] c,d,e,f ;
// variables in module top task automatic bitwise_xor output[15:0] ab_xor ;
// outputs from the task input[15:0] a,b ;
// inputs to the task begin #delay ab_and = a & b ab_or= a| b; ab_xor= a^ b;
end
endtask
// these two always blocks will call the bitwise_xor task
// concurrently at each positive edge of the clk, however since the task is re-entrant, the
//concurrent calls will work efficiently always @(posedge clk) bitwise_xor(ef_xor, e ,f );
always @(posedge clk2)// twice the frequency as that of the previous clk
bitwise_xor(cd_xor, c ,d );
endmodule

Function
Function is very much similar to a task, with very little difference, e.g., a function cannot drive more then one output and, also, it can not contain delays.
• Functions are defined in the module in which they are used. It is possible to define function in separate file and use compile directive 'include to include the function in the file which instantiates the task.
• Function can not include timing delays, like posedge, negedge, # delay. This means that a function should be executed in "zero" time delay.
• Function can have any number of inputs but only one output.
• The variables declared within the function are local to that function. The order of declaration within the function defines how the variables are passed to it by the caller. • Function can take, drive and source global variables when no local variables are used. When local variables are used, it basically assigns output only at the end of function execution.
• Function can be used for modeling combinational logic.
• Function can call other functions, but can not call a task.

Syntax
• A function begins with the keyword function and ends with the keyword endfunction

• Inputs are declared after the keyword function.
Example - Simple Function
module simple_function();
function myfunction;
input a, b, c, d; begin myfunction = ((a+b) + (c-d));
end
endfunction
endmodule

Example - Calling a Function
module function_calling(a, b, c, d, e, f);
input a, b, c, d, e ; output f;
wire f; `include "myfunction.v" assign f = (myfunction (a,b,c,d)) ? e :0;
endmodule

Automatic (Recursive) Function
Functions used normally are non recursive. But to eliminate problems when the same function is called concurrently from two locations automatic function is used.
Example // define a factorial with recursive function
module top; // define the function
function automatic integer
factorial: input[31:0] oper;
integer i: begin if (operan>=2) factorial= factorial(oper -1)* oper:// recursive call else factorial=1;
end endfunction // call the function i
nteger result;
initial
begin
result=factorial(4);
// call the factorial of 7
$ display (“Factorial of 4 is ”, result) ;\// Displays 24
end
endmodule

Constant function
A constant function is a regular verilog function and is used to reference complex values, can be used instead of constants.

Signed function 

These functions allow the use of signed operation on function return values.
module top;
// signed function declaration
// returns a 64 bit signed value function signed [63:0] compute _signed (input [63:0] vector);
--
--
endfunction
// call to the signed function from a higher module

if ( compute_signed(vector)<-3)

begin

--
end
--
endmodule

System tasks and functions 

Introduction 
There are tasks and functions that are used to generate inputs and check the output during simulation. Their names begin with a dollar sign ($). The synthesis tools parse and ignore system functions, and, hence, they can be included even in synthesizable models.

$display, $strobe, $monitor
These commands have the same syntax, and display text on the screen during simulation. They are much less convenient than waveform display tools like GTKWave. or Undertow. $display and $strobe display once every time they are executed, whereas $monitor displays every time one of its parameters changes. The difference between $display and $strobe is that $strobe displays the parameters at the very end of the current simulation time unit rather than exactly where a change in it took place. The format string is like that in C/C++, and may contain format characters. Format characters include %d (decimal), %h (hexadecimal), %b (binary), %c (character), %s (string) and %t (time), %m (hierarchy level). ], [. b, h, o can be appended to the task names to change the default format to binary, octal or hexadecimal.

Syntax
• $display ("format_string", par_1, par_2, ... );
• $strobe ("format_string", par_1, par_2, ... );
• $monitor ("format_string", par_1, par_2, ... );
• $displayb ( as above but defaults to binary..);
• $strobeh (as above but defaults to hex..);
• $monitoro (as above but defaults to octal..);

$time, $stime, $realtime 
These return the current simulation time as a 64-bit integer, a 32-bit integer, and a real number, respectively.

$reset, $stop, $finish
$reset resets the simulation back to time 0; $stop halts the simulator and puts it in the interactive mode where the user can enter commands; $finish exits the simulator back to the operating system

$scope, $showscope 
$scope(hierarchy_name) sets the current hierarchical scope to hierarchy_name. $showscopes(n) lists all modules, tasks and block names in (and below, if n is set to 1) the current scope. $random $random generates a random integer every time it is called. If the sequence is to be repeatable, the first time one invokes random give it a numerical argument (a seed). Otherwise, the seed is derived from the computer clock.

$dumpfile, $dumpvar, $dumpon, $dumpoff, $dumpall 
These can dump variable changes to a simulation viewer like Debussy. The dump files are capable of dumping all the variables in a simulation. This is convenient for debugging, but can be very slow.

Syntax
• $dumpfile("filename.dmp")
• $dumpvar dumps all variables in the design.
• $dumpvar(1, top) dumps all the variables in module top and below, but not modules instantiated in top.
• $dumpvar(2, top) dumps all the variables in module top and 1 level below.
• $dumpvar(n, top) dumps all the variables in module top and n-1 levels below.
• $dumpvar(0, top) dumps all the variables in module top and all level below. • $dumpon initiates the dump. • $dumpoff stop dumping.

$fopen, $fdisplay, $fstrobe $fmonitor and $fwrite

These commands write more selectively to files.

• $fopen opens an output file and gives the open file a handle for use by the other commands.

• $fclose closes the file and lets other programs access it.

• $fdisplay and $fwrite write formatted data to a file whenever they are executed. They are the same except $fdisplay inserts a new line after every execution and $write does not.

• $strobe also writes to a file when executed, but it waits until all other operations in the time step are complete before writing. Thus initial #1 a=1; b=0;

• $fstrobe(hand1, a,b); b=1; will write write 1 1 for a and b. $monitor writes to a file whenever any one of its arguments changes.

Syntax

• handle1=$fopen("filenam1.suffix")
• handle2=$fopen("filenam2.suffix")
• $fstrobe(handle1, format, variable list) //strobe data into filenam1.suffix
• $fdisplay(handle2, format, variable list) //write data into filenam2.suffix
• $fwrite(handle2, format, variable list) //write data into filenam2.suffix all on one line. //put in the format string where a new line is // desired.

Writing Testbenches
 Testbenches
are codes written in HDL to test the design blocks. A testbench is also known as stimulus, because the coding is such that a stimulus is applied to the designed block and its functionality is tested by checking the results. For writing a testbench it is important to have the design specifications of the "design under test" (DUT). Specifications need to be understood clearly and test plan made accordingly. The test plan, basically, documents the test bench architecture and the test scenarios (test cases) in detail. Example – Counter Consider a simple 4-bit up counter, which increments its count when ever enable is high and resets to zero, when reset is asserted high. Reset is synchronous with clock.

Code for Counter
// Function : 4 bit up counter
module counter (clk, reset, enable, count);
input clk, reset, enable;
output [3:0] count;
reg [3:0] count;
always @ (posedge clk)
if (reset == 1'b1) begin
count <= 0; end else if ( enable == 1'b1) begin count <= count + 1;
end
endmodule

2.2.2 Test Plan
We will write self checking test bench, but we will do this in steps to help you understand the concept of writing automated test benches. Our testbench environment will look something like shown in the figure.

DUT is instantiated in testbench which contains a clock generator, reset generator, enable logic generator, compare logic. The compare logic calculates the expected count value of the counter and compares its output with the calculated value.

Test Cases
• Reset Test : We can start with reset deasserted, followed by asserting reset for few clock ticks and deasserting the reset, See if counter sets its output to zero.
• Enable Test : Assert/deassert enable after reset is applied.
• Random Assert/deassert of enable and reset.