Main Content

Detect Data Store Access Violations

Simulink® Design Verifier™ design error detection analysis identifies unintended sequences of data store reads and writes that occur during simulation. The analysis detects these data store access violations:

  • Read-before-write

  • Write-after-read

  • Write-after-write

To detect data store access violations in your model:

  1. On the Design Verifier tab, in the Mode section, select Design Error Detection.

  2. Click Error Detection Settings.

  3. In the Configuration Parameters dialog box, in the Design Error Detection pane, select Data store access violations. Click OK.

  4. Click Detect Design Errors.

After the analysis is complete, the software highlights the model with the analysis results and the Results Summary window displays the summary of the analysis.

Detect Data Store Access Violations in a Model

This example shows how to detect data store access violations and review the analysis results. The sldvexDataStoreAccessViolations example model consists of Data Store Memory blocks that define the alpha and beta data stores. In the example model, the Write Subsystem writes the data to the data store by using Data Store Write blocks and the Read Subsystem reads the data from the data store by using the Data Store Read blocks.

Step 1: Open the Model

At the command prompt, enter:

open_system('sldvexDataStoreAccessViolations');

Step 2: Configure Analysis Options to Detect Data Store Access Violations

The model is preconfigured with the Data store access violations parameter set to On.

Step 3: Perform Design Error Detection Analysis

On the Design Verifier tab, click Detect Design Errors. Simulink Design Verifier analyzes the model for data store access violations. After the analysis completes, the Results Summary window displays that one objective was falsified.

Step 4: Review Analysis Results

The model is highlighted with the analysis results.

(1) Open the Read Subsystem and click Data Store Read1 block that is highlighted in red. The Results Inspector window displays the Read-before-write objective that violates the data store access order.

(2) To view the test case that replicates the error, click View test case. The harness model and the Signal Builder block open that displays the test case.

(3) To simulate the test case, in the Signal Builder dialog box, click Start simulation. After the simulation completes, the Diagnostic Viewer window displays this warning message:

The block 'sldvexDataStoreAccessViolations_harness/Test Unit (copied from sldvexDataStoreAccessViolations)/Read Subsystem/Data Store Read1' is reading from the data store 'sldvexDataStoreAccessViolations_harness/Test Unit (copied from sldvexDataStoreAccessViolations)/Data Store Memory1' before any blocks have written to this entire region of memory at time 0.0. For performance reasons, occurrences of this diagnostic for this memory at other simulation time steps will be suppressed.

Step 5: Fix the Data Store Access Violation Error

The read-before-write objective results in error because no block has been written to the beta data store before the read operation executes.

Open the Write Subsystem and double-click Write "alpha". In the Write "alpha" subsystem, only the alpha data store is written with a constant value. Hence, the read-before-write data store access violation occurs for the "beta" Data Store Read block.

To fix the error, in the Write "alpha" subsystem, add a Constant block and write its value to beta data store by using the Data Store Write block (highlighted in figure below).

On the Design Verifier tab, click Detect Design Errors. After the analysis completes, the software reports that all the objectives are valid.

See Also

Limitations

Reads from and writes to data stores which result from initialization logic, are not checked for violations.

For example, initialization logic that occurs from an Initialize Function, is ignored when checking for data store access violations.

For any type of logic called outside or inside of initialization, it is analyzed for the behaviors which are not related to initialization.

Related Topics