System Verilog tasks to generate vcd file

Many times in verification activity, people requires to generate vcd file and mostly it is required by designers to see the value changes of design variables. So let's see, more about vcd file in system verilog.

2 types of vcd file can be generated through system verilog:

1. 4 state: which represent changes of variable values 0, 1, x and z
2. Extended: with 4 state values, it shows strength information

Below are the more details about generation of vcd files:

• Generation for 4 state vcd file:

          Following are few useful system verilog tasks, that can be used for 4 state vcd file:

• $dumpfile("file_name.vcd") => To generate vcd file with specified name. It is passed as its argument. If its not provided then default file name would be "dump.vcd".
• $dumpvars(0, top) => To specify which variables to be dumped into vcd file. It has 2 arguments but no arguments are specified then it dumps all variables of the design.

                   First argument indicates the hierarchy level below each specified module instance to be dumped. 

• 0 indicates dump of all variables in the specified module and all module instances and sub-instances specified in the current module.
• 1 indicates dump all the variable of current module
• 2 indicates dump all the variable of current module and the instances specified in the current module. It will not dump submodule information.
• ..... 

                    Second argument indicates the scope/hierarchy of the design to dump.

• $dumpoff => To suspend dumping information in the vcd file.
• $dumpon => To resume dumping information in the vcd file.
• $dumpall => Dump all selected variables when this task in invoked otherwise variables are dumped only when their values are changed.
• $dumplimit(file_size_in_bytes) => To specify the size limit of vcd file.
• Generation of Extended vcd file:

          Following are few useful system verilog tasks, that can be used for extended vcd file:

• $dumpports(module_identifier, "file_name.vcd") => To dump ports and specify the vcd file name. Only modules can be provided, not variables. More than one module can be provided by comma separation.
• $dumpportsoff("file_name.vcd") => To suspend port dumping information in vcd file.
• $dumpportson("file_name.vcd") => To resume port dumping information in vcd file. 
• $dumpportsall("file_name.vcd") => To dump all selected ports at a time when this method is called.
• $dumpportslimit(file_size_in_bytes, "file_name.vcd") => To specify the size limit of the file and the file name of vcd to be dumped.

Test Timeout in UVM

In verification activity, we usually expects regression shall be completed as soon as possible. So that, we can debug the failing testcases as well as check the coverage result. But sometime, few testcase takes a lot of simulation time or some testcase stuck in simulation which never ends. Due to that, regression takes a longer time than expected. To avoid this kind of problem, UVM defines time out mechanism i.e. if testcase simulation time reaches at defined time out then testcase ends with UVM_FATAL which eventually reduces regression time.

UVM has method "set_timeout" which is defined in "uvm_root". So, in environment class or in the base testcase, this time out shall be set to a proper value which affects to all testcases.

Definition: 

function void set_timeout(time timeout, bit overridable = 1)  

First argument: Time out value (Unit: time). Default value is 9200s. 

Second argument: Time out value could be override or not. If there's any strict limitation that, the test shall be ended in particular time, than this argument shall be set to 0. If there's any testcase which takes longer time in simulation than expected than this value shall be set to 1. Default value is 1.

Example:

package user_pkg;

import uvm_pkg::*;

`include "uvm_macros.svh"

class child extends uvm_component;

    function new (string name, uvm_component parent);

        super.new(name, parent);

    endfunction

    function void build_phase(uvm_phase phase);

        super.build_phase(phase);

        uvm_top.set_timeout(50, 1);

    endfunction 

    task run_phase(uvm_phase phase);

        phase.raise_objection(this);

        #10;

        phase.drop_objection(this);

    endtask

endclass

class base extends uvm_component;

    child l1;

    function new (string name, uvm_component parent);

        super.new(name, parent);

    endfunction

    function void build_phase(uvm_phase phase);

        super.build_phase(phase);

        l1 = new("l1", this);

    endfunction 

    task run_phase(uvm_phase phase);

        phase.raise_objection(this);

        uvm_top.set_timeout(100,1);

        #200; 

        phase.drop_objection(this);

    endtask

endclass

endpackage:user_pkg

module top;

    import uvm_pkg::*;

    import user_pkg::*;

    base mu = new("mu", null);

    initial begin

        run_test();

    end

endmodule

Output:

 UVM_FATAL ../../../../src/base/uvm_phase.svh(1506) @ 100: reporter [PH_TIMEOUT] Explicit timeout of 100 hit, indicating a probable testbench issue

In the above example, child class is set with default time out to 50t in build phase and it can be overridden. As it requires to override this value, in the run phase of parent class, the timeout is set to 100t. So, we expect, the test shall be completed successfully before 100t. But as the test is not completed in 100t, the test is ended forcefully with UVM_FATAL at 100t due to timeout. 

This timeout can be controlled through "+UVM_TIMEOUT=xx" command line argument at simulation time (xx defines the time). So that, it doesn't require to update the testcase.