Diagnosis, proposed patches and verification

When a simulation fails, Nelix Agent can diagnose it and propose a repair.

Start a diagnosis#

On the failed card choose Debug with Nelix Agent, or in the terminal:

nelix debug TST-20261005-0001

Use the id your own run printed.

What the diagnosis contains#

• The failing stage and the first step that failed.
• The evidence: the tool's own error, or signal values with their times from the waveform.
• The kind of cause: the design, the test, a build setting, or the environment (a limit reached, with no fault shown in the design).
• A proposed change, when the cause is in the design. It is the smallest change the evidence justifies.

Measured facts, the AI's reasoning and its recommendation are kept apart, so you can see which is which.

In a class set to No AI assistance, Evidence or Diagnosis, a student gets hints up to that level and no proposed patch: on graded work always, and on all their projects while one of the class's assignments is open. The same rule applies in Design Chat, analog drafting and Autopilot.

It works on a snapshot#

The diagnosis is based on the source as it was for the failed run. If you have edited the file since, the lab knows, and will not apply a repair made for an older version on top of newer work.

A repair is tested before you can accept it#

1. Nelix Agent proposes a patch.
2. The lab applies it to a separate copy of your project.
3. The lab runs your test on that copy.
4. Only after it passes can you accept it. While the test is running you may already see the change, marked as not tested yet.

Your working files are untouched throughout. The check does not use AI credits.

How Nelix checked this fix lists every check with its result. One of them is a formal check written from your design description. It is bounded: a solver tries every possible input on each of the first N clock cycles after reset (N is shown, often 6 to 24) and looks for a way to break the rules. Under the check, What this check covered shows each rule as its sentence from the description (and, for engineers, the assertion), the assumptions (reset held for 2 clock cycles, then any input) and what it does not cover. Something that takes longer than N clock cycles to happen, such as a counter reaching 255, is not covered. A bounded check is strong evidence, not a full proof. Students whose class limits AI help see the sentences only.

VHDL projects#

Diagnosis and repair work for VHDL too: the copy is tested with the lab's own GHDL simulation. A VHDL repair can be Verified when the formal rules written from your design description pass on the lab's Verilog translation of the fixed VHDL (GHDL + Yosys). Without a design description, or when the translation fails, it is Passes your tests at best. Read the change before you accept it. See VHDL projects.

You decide#

Review the change. Accept records that you agree with it; your design is not changed yet. Merge then writes it into your design, keeps a backup and runs your test again. If you do not accept and merge, nothing changes.

The test that Merge runs is a check, not a Simulate run: Overview keeps the old failed result until you run Simulate again. Undo the fix puts your file back as it was before the merge; like Accept and Merge, it asks first. After an undo the fix page says Rolled back, with the date, and the fix's history records who rolled it back and when. The fix stays accepted, so you can merge it again later.

What a repair will not do#

• It will not rewrite your test to make it pass.
• It will not change an expected value, remove a check, or relax a timing target.
• If the test itself is wrong, Nelix Agent says so and explains why. Correcting the test is a separate change that you make.