Troubleshooting failures

Runs fail — especially early on, while you're still tuning a design. Vulkos is built to make failures readable rather than cryptic, so you can fix the cause and re-run quickly.

How Vulkos explains errors#

When a flow fails, you don't have to dig through raw logs alone. Vulkos surfaces the failing stage and the relevant log lines, and the built-in assistant can read the error in the context of your project and explain what went wrong in plain language — often with a concrete fix to try.

Common failure modes#

Config doesn't match your RTL

• DESIGN_NAMEdoesn't match your top module — synthesis can't find an entry point.
• A source is missing from VERILOG_FILES, or a testbench was added to it by mistake.
• CLOCK_PORTnames a port that doesn't exist on the top module.

RTL problems

Syntax errors and non-synthesizable constructs fail at synthesis. The lint problems view catches many of these before you spend compute on a full run — check it first.

Physical closure

• Timing:negative slack means the design can't hit the clock target. Relax CLOCK_PERIOD or simplify the critical path.
• Congestion: routing fails when the die is too full. Lower FP_CORE_UTIL to give the router more room.

Recovering from a failure#

A failed run doesn't cost you anything beyond the compute it used. The usual loop is:

• Read the failing stage and the assistant's explanation.
• Fix the config or RTL it points to.
• Re-run. Verifying with your testbench first avoids spending a full physical run on a logic bug.

For what each stage does and where errors originate, see Pipeline stages.