Questa Xprop Enable and Disable Through Testbench

2024-10-30T21:45:01.000-0400
Simulation

Summary

Until recently, enabling and disabling X propagation functionality during simulation were performed only by Questa tcl commands outside the test. This article demonstrate a new way to enable and disable xprop directly in the testbench via system tasks on Verilog/SV projects. This feature provides flexibility, efficiency and reusability in different tests.


Details

Motivation:

Testbenches play a critical role in verifying the correctness of a design. Adding xprop system tasks to the design testbench provides a way to control X-propagation settings within the testbench itself. Thus, this feature enables users to dynamically enable or disable X-propagation for specific scenarios during simulation. For instance, on reset phase, there may be X's that should not propagate, and undesirably impact after reset. Xprop should be turned on later when user knows that design is stable.

 

So far, to enable/disable xprop during simulation for a certain period of time, we would normally execute xprop enable and xprop disable manually in the terminal or by running a *.do file. For instance:

run 5ns

xprop disable

run 100ns

xprop enable

run -all

 

Now, assume a certain task is being changed in the project. The user then needs to modify the above procedure accordingly. With this new feature, starting from Questa release 2024.1, xprop enablement is based on the context in the code, not only on numeric time values that could be subject to changes.

 

 

Steps:

  1. Invoke vopt with -xprop option, to enable xprop capabilities in the test:
    vopt test -xprop -o out

X propagation is now set to the entire simulation.

  1. Place these system tasks anywhere in the testbench, multiple times as needed:

$xprop_enable
$xprop_disable

Whenever xprop is disabled, simulation runs with the default RTL X-propagation, which is a more optimistic mode.

 

Comment:
starting Questa version 2024.1 & 2024.4_3, Questa TCL command may be handy:

xprop status

It returns information whether X propagation is enabled, and in which mode:

 

Value

Description

-1

No xprop during vopt.

0

 Xprop is disabled but was enabled during vopt.

1

 Trap

2

 Pass

3

 Resolve enabled

 

 

Simple Example:

 

test.sv

module Mux2(input d1, input d2, input select, output reg q);

    always @(select or d1 or d2) begin

        case (select)

            0 : q = d1;

            1 : q = d2;

        endcase

    end

endmodule

 

module test();

    reg clk, sel, a, b, q;

    Mux2 mux(a,b,sel,q);

    always begin

        a = 0;

        b = 1;

        clk = 0;

        sel = 0;

        #5

        $xprop_disable;

        sel = 1'bx;

        #5

        $xprop_enable;

        sel = 1;

        #5

        sel = 1'bx;

        #5

        sel = 0;

        #5

        $finish;

    end

    always begin

        #1 clk = ~clk;

    end

endmodule

 

 



Contradicting commands Notes:

  1. Starting from Questa version 2024.2, there is a specific vopt option to disable xprop for time 0:  

-xprop_disable=timezerocorrupt

In case it contradicts the system tasks $xprop_enable at time 0, then system tasks wins, and X propagation is enabled.

  1. In case xprop system tasks and Questa TCL xprop commands are used together, the last command or task to be executed is effective. Running the following run.do file for the simple example above on live simulation can demonstrate this behavior:

run.do

onbreak {resume}

if [file exists work] {

    vdel -all

}

 

vlib work

vlog -sv test.sv

vopt test -xprop -o out -debug,livesim -designfile design.bin

vsim -visualizer=design.bin out -qwavedb=+signal

 

if {![batch_mode]} {

     log -r *

     add wave /test/clk

     add wave /test/sel

     add wave /test/q

     wave zoomfull

}

 

run 5 ns

xprop enable  #at time 5ns  with $xprop_disable (system task executed after TCL cmd)

run 5 ns

xprop disable #at time 10ns with $xprop_enable  (TCL cmd executed after system task)

run -all

 

if {[batch_mode]} {

    quit -f

}

 

UVM Note:

 

These system tasks can be used within UVM phases. Useful idea will be to place them in run_phase, or specifically in its sub-phases. For instance: $xprop_disable on one phase and $xprop_enable on another phase. Reminder:

 

UVM Run-Time Phases

The run-time schedule is the pre-defined phase schedule which runs concurrently to the uvm_run_phase global run phase.

uvm_pre_reset_phase

Before reset is asserted.

uvm_reset_phase

Reset is asserted.

uvm_post_reset_phase

After reset is de-asserted.

uvm_pre_configure_phase

Before the DUT is configured by the SW.

uvm_configure_phase

The SW configures the DUT.

uvm_post_configure_phase

After the SW has configured the DUT.

uvm_pre_main_phase

Before the primary test stimulus starts.

uvm_main_phase

Primary test stimulus.

uvm_post_main_phase

After enough of the primary test stimulus.

uvm_pre_shutdown_phase

Before things settle down.

uvm_shutdown_phase

Letting things settle down.

uvm_post_shutdown_phase

After things have settled down.

KB Article ID# KB000155237_EN_US

Contents

SummaryDetails

Associated Components

Questa Core/Prime Questa SV/AFV Questa Base