This is a byproduct of the "Apply block replacements" option in the Design Verifier configuration settings.
Block replacement is designed to enhance the analysis by substituting certain blocks with alternative ones from our built-in library. This process aims to refine the quality of the generated test cases. For instance, when the switch block in your model is replaced with a built-in model replacement, it results in the generation of additional test cases. These cases facilitate the observation of the switch position through its outputs. Please refer to the picture below for a visual explanation.
In the model where the switch block has been replaced, we identify six objectives, compared to only two objectives without block replacement. The four additional objectives are conditional and only present in the replacement model prior to the analysis. Specifically, the objectives related to the Relational block create extra test cases to ensure the switch position can be observed by its outputs. The objective forces input1 ~= input3, which is where the additional condition objectives come from.
However, since the switch port is driven by constants, this condition can never be true, rendering it dead logic. It's important to note that this condition is exclusive to the replacement model and does not exist in the original design model. For further details on block replacement, please consult the documentation below:
As previously mentioned, block replacements are primarily focused on facilitating test generation. Most of them do not pertain to the detection of design errors. You can find more information on this in "blkrep_rule_switch_normal.m" available at the provided link above.
The documentation states, "A rule that replaces Switch blocks with an implementation that includes test objectives, requiring that each switch position be exercised when the values of the first and third input ports are different." While there are certain cases, like the sine function replacement with a lookup table, that block replacement is recommended to achieve better results, generally, this is not advised for the Design Error Detection (DED) workflow.
