Resolve Design Errors

Detecting Design Errors (SLDV DED + Root Cause Analysis)

When to Use

• User asks to check a Simulink model for design errors (division-by-zero, overflow, dead logic, out-of-bounds)
• User asks to find root causes of DED findings
• User asks to fix or understand an analysis finding
• User asks why there is missing coverage due to dead logic (dead logic gates prevent coverage objectives from being satisfied)
• User has SLDV artifacts (.mat file) and wants analysis without re-running DED

When NOT to Use

• Requirement verification — checking if a model satisfies a requirement
• Test generation or test authoring — creating test cases from requirements or for coverage
• Comprehensive verification — this skill is a quick defect scan, not an exhaustive proof; a clean result does not guarantee the model is free of all errors
• Coverage measurement — this skill does not measure or report model coverage; use Simulink Coverage tools

Safety Rules

1. Never patch the original model directly. Always clone first before applying any fix.
2. NEVER apply fixes without explicit user approval. After root cause analysis, present findings and suggest a fix strategy — then STOP and wait for the user to say "yes, apply it" or "go ahead." Even if the user's prompt says "suggest a fix" or "fix it," you must present the plan first and wait for confirmation. Do NOT create clone models, set parameters, or run verification until the user explicitly approves.
3. SLDV results are always sound. Never assume SLDV returns false positives. If SLDV reports a defect, it is a real defect — treat every finding as a true positive and investigate accordingly.

Requires: MATLAB R2023b+, Simulink Design Verifier, Simulink Check / Model Slicer.

Prerequisites

All script functions live in the skill's scripts/ directory. Use evaluate_matlab_code with project_path set to that folder so MATLAB can find them.

Workflow

This skill provides two functions that automate SLDV-driven analysis the agent otherwise gets wrong when hand-rolling it, then hands you the facts to classify and fix findings. The workflow is four steps:

Copy code
1. Detect errors      → sldv_run_defect_checker   (use the function; don't hand-roll DED)
2. Root cause errors  → sldv_find_de_root_cause    (use the function; don't hand-roll slicing)
3. Classify errors    → agent step (dead logic: intentional vs. design_error)
4. Fix errors         → agent step (propose, get approval, clone-fix-verify)

Steps 1–2 are the two functions. Steps 3–4 are agent judgment based on their output. Full API detail (return fields, options, caching, sub-functions) is in references/api-reference.md — load it when you need exact fields or options.

Step 1 — Detect errors

Call sldv_run_defect_checker(model) instead of writing your own SLDV DED invocation or parsing objectives by hand — it configures the analysis, runs DED, and auto-loads cached *_sldvdata.mat results when available.

matlabCopy code
result = sldv_run_defect_checker("my_model", OutputDir="artifacts/ded")

If result.Status == "pass": STOP. Report "No design errors of the checked types were detected" and end the workflow. Do NOT call sldv_find_de_root_cause or investigate further. DED is a quick scan, not an exhaustive proof — tell the user no defects of the checked types were found, not that the model is error-free.

Proceed to Step 2 only when result.Status == "fail".

Step 2 — Root cause errors

Call sldv_find_de_root_cause(model, DedResult=result.DedResult) instead of hand-building slices — it returns backward slices, counterexamples, locality (blast-radius) measures, and shared-root cascade annotations for every finding.

matlabCopy code
rca = sldv_find_de_root_cause("my_model", DedResult=result.DedResult, OutputDir="artifacts/ded")

Then trace each finding to its root cause:

1. Follow the counterexample through rca.SliceBlocks to find which block produces the defect-triggering value
2. Use model_overview / model_read to understand each block's role
3. Prefer high-Locality blocks (narrow blast radius, safer) and high-FindingCount blocks (fix resolves more defects); check rca.Cascades — a shared-root fix resolves multiple findings at once

When the slice is shallow (< 3 blocks) or stops at a Stateflow / MATLAB Function block: the Model Slicer cannot trace through those constructs. Do NOT stop and report only what the tool returned — fall back to model_read / model_overview to interpret the finding: read the defect block and its upstream connections, read the Stateflow chart or MATLAB Function logic the slice stopped at, and cross-reference counterexample values to see which branch is active.

Step 3 — Classify errors (dead logic)

Classification happens after root cause analysis — you need to see the root cause (which block, what value) before deciding whether dead logic is intentional.

Findings arrive pre-enriched. For every dead logic finding, sldv_find_de_root_cause attaches on the finding struct:

• finding.ModelContext — a model_read dump of the block's surrounding scope. You do not need to call model_read again for this. (If empty — model_read was unavailable — fall back to model_overview / model_read yourself for that block.)
• finding.PatternCatalog — the entire dead-logic pattern library (catalog index + every pattern), concatenated. You do not need to open the YAML files yourself.
• finding.Classification — "pending", awaiting your decision.

How to classify. For each dead logic finding, using ModelContext and PatternCatalog:

1. Look at the root cause block — what value does it produce that makes the branch dead?
2. Compare the model context against the patterns in PatternCatalog.
3. Decide: is the block INTENTIONALLY producing this value (safety guard, disabled feature, complementary Stateflow guards) or is it a BUG (wrong parameter, cascading error)?

Set the classification:

• "intentional" — defensive logic, enable-as-input, negation guard pairs → no fix needed; report to the user as expected behavior
• "design_error" — wrong parameter, cascading dead logic, short-circuit → fix the root cause
• "unclassified" — unclear → ask the user

Only apply fixes for "design_error" findings.

Step 4 — Fix errors

The functions provide facts; you identify root causes and decide fixes — there is no hardcoded defect-to-fix mapping.

When you are ready to propose or apply a fix, load and follow references/fix-strategy.md. It covers root-cause identification, the clone-fix-verify procedure, fix principles, and the blast-radius discussion required for every proposal.

Two rules that always apply (see Safety Rules): present findings and wait for explicit approval before applying anything, and propose a fix for every design_error finding — 2–3 ranked options each when possible — rather than stopping after only some.

Common Mistakes

Copyright 2026 The MathWorks, Inc.