X-prop
Why X-prop?
Designers use RTL constructs to describe hardware behaviors. However, certain RTL simulation semantics are insufficient to accurately model the hardware behaviors. Therefore, simulation results are either too optimistic or pessimistic than the actual hardware behaviors.
Standard RTL simulations ignore the uncertainty of X-valued control signals and assign predictable output values. As a result, RTL simulations often fail to detect design problems related to the lack of X-Propagation. However, the same design problems can be detected in gate-level simulations. With X-Propagation support in RTL simulations, engineers can save time and effort in debugging differences between RTL and gate-level simulation results.
Gate-level simulations and pseudo-exhaustive 2-state simulations are techniques used to expose X-Propagation (Xprop) problems. However, as designs grow in size, these techniques become increasingly expensive and time consuming, often covering only a fraction of the overall design space.
Additional comments: However, gate-sim have a different problem, known as X-pessimism. We often switch to low-effort gates to reduce the incidence of x-pessimism, however the low-effort gates still aren’t guaranteed to eliminate all cases of x-pessimism. Also, even in the absence of x-pessimism tracing back x’s in gates can be time-consuming.
VCS Xprop Introduction
The VCS Xprop simulator provides an effective simulation model that allows Xprop problems to be exposed by standard RTL simulations.
The VCS Xprop simulator provides two built-in merge modes that you can choose at either compile time or runtime:
-
xmerge mode : This mode is more pessimistic than a standard gate-level simulation.
-
tmerge mode : This mode is closer to actual hardware behavior and is the more commonly used mode.The merge result yields X when all output values of logic 0 and logic 1 control signal are different, similar to a ternary operator.
-
vmerge mode : This mode is the classic Verilog (optimistic) behavior, which effectively disables the enhanced Xprop semantics
If a flip-flop is sensitive to the rising edge of its clock signal, an X to 1 transition triggers the flip-flop and pass the value from input to output when coded using the Verilog posedge event type of usage. Effectively, the RTL constructs in these cases consider the X to 1
How to use Xprop
The -xprop compile-time option is used to enable Xprop and to specify the merge mode at run time. By default, VCS uses the tmerge merge mode.
Following is the syntax of the -xprop option:
vcs -xprop[=tmerge|xmerge|xprop_config_file]
[-xprop=flowctrl]
[-xprop=nestLimit=]
other_vcs_options
The merge mode can also be modified at runtime via the $set_x_prop() system task.
Xprop Config file
You can define the scope of the Xprop instrumentation and select the merge mode in the configuration file. The Xprop configuration file is used to define the scope of Xprop instrumentation in a design. The file allows you to specify the design hierarchies or modules to be excluded or included for Xprop.
If you use an Xprop configuration file, by default VCS does not perform Xprop instrumentation. You must use the xpropOn attribute to specify the design hierarchies or modules for Xprop instrumentation.
For instance,
tree { bridge } { xpropOff } ;
instance { top.bridge.cpu } { xpropOn } ;
module { sram } { xpropOff } ;
merge = merge_mode
Compile Time Diagnostic Report
When you compile a design with Xprop enabled, VCS generate reports that record all the statements considered for Xprop instrumentation, whether or not the statements are instrumented, and the reason for statements not being instrumented. Reports are generated with the name xprop.log for Verilog.
Querying X-Propagation at Runtime
You can use the $is_xprop_active Verilog system function to query the X-prop status for a particular module or an entity instance. The function returns an 1 if Xprop is enabled in the current instance