Main Content

What Is Block Replacement?

Using Simulink® Design Verifier™, you can define rules to replace blocks automatically in your model. For example, you can work around a block that is incompatible with the software by creating a rule that replaces an unsupported Simulink block in your model with a supported block that is functionally equivalent. Or, you can customize blocks for analysis by creating a rule that adds constraints or objectives to particular blocks in your model.

When performing block replacements, the software makes a copy of your model and replaces blocks in the copy, without altering your original model. In this way, you can easily customize a model for analysis.

The Simulink Design Verifier software replaces blocks automatically in a model using:

  • Libraries of replacement blocks

  • Rules that define which blocks to replace and under what conditions

You replace any block with any built-in block, library block, or subsystem.

Block replacements are extensible, allowing you to define your own libraries of replacement blocks and custom block replacement rules. Using block replacements, you can

  • Work around an incompatibility, such as the presence of unsupported blocks in your model.

  • Customize a block for analysis, such as:

    • Adding constraints to its input signals

    • Adding objectives to its output signals

    • Eliminating the contents of a subsystem or Model block to simplify your analysis


You can use automatic stubbing as an alternative to block replacements to resolve incompatibilities. Automatic stubbing replaces unsupported blocks with elements that have the same interface. For more information, see Handle Incompatibilities with Automatic Stubbing.

Block Replacement Effects on Test Generation

Replacing blocks can affect test case generation if the replaced blocks share functionality with other parts of your model. Before you replace blocks, understand functional dependencies on those blocks or on shared signals. See Highlight Functional Dependencies. Replacement blocks can also affect other analysis workflows such as property proving.

For example, you can customize a block for analysis using a replacement block that adds objectives to an input signal. If another subsystem depends on that signal, the replacement block effectively adds an objective for the subsystem.

In this example, the breakpoint range of u1 in the 2-D Lookup Table is 5–7. The switch threshold 8 falls outside the u1 lookup table range.

Tests generated without replacing the 2D Lookup Table satisfy two objectives: that the trigger is not greater than the Switch block threshold 8, and that the trigger is greater than the Switch block threshold 8.

Objective Satisfied

Test generation with block replacement returns a different analysis. The blkrep_rule_lookup2D_normal.m block replacement rule replaces the 2D Lookup Table with a masked subsystem containing the 2D Lookup Table and a verification subsystem.

The verification subsystem constrains the analysis within the breakpoint bounds of the table. The additional constraints prevent generating tests that exercise the second objective for the Switch block. The condition that the input signal In1 > 8 is unsatisfiable.

Objectives Satisfied

Objectives Proven Unsatisfiable