6.2 Verilog Tasks

❮ Front End Engineers Required Skills Es6 Map Set ❯

6.2 Verilog Tasks

Classification Verilog Tutorial

Keywords: Tasks

Differences Between Tasks and Functions

Like functions, tasks can be used to describe common segments of code and can be called from any position within a module, making the code more intuitive and readable. Functions are generally used for various transformations and calculations in combinational logic, while tasks are more like processes, capable of not only performing the functions of a function but also including timing control logic. The following summarizes the differences between tasks and functions:

Comparison Point	Function	Task
Input	Functions must have at least one input, and port declarations cannot include inout types	Tasks can have zero or multiple inputs, and port declarations can be of inout type
Output	Functions have no outputs	Tasks can have zero or multiple outputs
Return Value	Functions must have at least one return value	Tasks have no return values
Simulation Time	Functions always start executing at time zero	Tasks can execute at non-zero times
Timing Logic	Functions cannot contain any timing control logic	Tasks cannot have always statements, but can include other timing controls, such as delay statements
Invocation	Functions can only call other functions, not tasks	Tasks can call both functions and tasks
Writing Conventions	Functions cannot appear alone as a statement, and can only be placed on the right side of an assignment language	Tasks can appear as a standalone statement within a statement block

Tasks

Task Declaration

Tasks are defined at any position within a module and are referenced at any position within the module, with their scope limited to this module.

If a subroutine within a module meets any of the following conditions, tasks must be used instead of functions:

1) The subroutine contains timing control logic, such as delays, event control, etc.
2) There are no input variables
3) There are no outputs or more than one output

The format for declaring a task in Verilog is as follows:

task       task_id ;
    port_declaration ;
    procedural_statement ;
endtask

Tasks use the keywords input, output, and inout to declare ports. Input and inout ports pass variables from outside the task to the inside, while output and inout ports pass the results back to the outside after the task is completed.

When designing the logic of a task, you can consider the port variables declared as input as wire type, and the port variables declared as output as reg type. However, there is no need to declare the output port with reg again.

When assigning a value to an output signal, do not use the keyword assign. To avoid timing confusion, it is recommended to use blocking assignments for output signals.

For example, a task description with a delay for an XOR function is as follows:

Example

task xor_oper_iner;
    input [N-1:0]   numa;
    input [N-1:0]   numb;
    output [N-1:0]  numco ;
    //output reg [N-1:0]  numco ; //No need to declare reg type again, although it might not be wrong
    #3  numco = numa ^ numb ;
    //assign #3 numco = numa ^ numb ; //No assign, because the output is default reg
endtask

When declaring a task, you can also add parentheses after the task name to enclose the port declarations.

The above design can be changed to:

Example

task xor_oper_iner（
    input [N-1:0]   numa,
    input [N-1:0]   numb,
    output [N-1:0]  numco  ） ; 
    #3  numco       = numa ^ numb ;
endtask

Task Invocation

Tasks can appear as a standalone statement in an initial or always block, and the calling format is as follows:

task_id(input1, input2, …,outpu1, output2, …);

When calling a task, ports must correspond in order.

The signals connected to the input ports can be of wire type or reg type. The signals connected to the output ports must be of reg type, which should be noted.

Make a call to the above XOR function task to cache the XOR result.

Example

module xor_oper
    #(parameter         N = 4)
     (
      input             clk ,
      input             rstn ,
      input [N-1:0]     a ,
      input [N-1:0]     b ,
      output [N-1:0]    co  );
 
    reg [
reg [3:0] cnt_temp;
initial begin
    en_cnt = 1;
    cnt_temp = 0;
    #25; en_cnt = 0;
end
always #10 cnt_temp = cnt_temp + 1;

reg [3:0] cnt1, cnt2;
always @(posedge clk) test_flag(2, en_cnt, cnt1); //task(1)
always @(posedge clk) test_flag(cnt_temp, !en_cnt, cnt2); //task(2)

The simulation results are as follows.

When en_cnt is high, the signal en in task (1) is valid, and cnt1 can output the correct logic value;

At this time, the signal en in task (2) is disabled, so the value of cnt2 is overwritten by the common variable cnt_temp driven by task (1).

When en_cnt is low, the signal en in task (2) is valid, so the signal cnt2 in task (2) can output the correct logic value; but at this time, the value of cnt1 is repeatedly overwritten by the common variable cnt_temp driven by task (2) under the drive of the clock.

It can be seen that the tasks have an impact on each other due to the common storage space when called concurrently twice.

Other descriptions remain unchanged, only add the keyword automatic when declaring the above task, as follows.


task automatic test_flag;

The simulation results are as follows.

When en_cnt is high, the signal cnt1 in task (1) can output the correct logic value, and the value of the signal cnt2 in task (2) is X;
When en_cnt is low, the signal cnt2 in task (2) can output the correct logic value, and the value of the signal cnt1 in task (1) is X;

It can be seen that the tasks have no impact on each other because the storage space is independent when called concurrently twice.