Not every red test is a bug.
Find out which before you open the waveform

The test failed. The design is fine.

class axi_driver extends uvm_driver #(axi_item);
	// `uvm_component_utils(axi_driver)

	function new(string name, uvm_component parent);
		super.new(name, parent);
	endfunction
endclass

The class compiles yet the factory has never heard of your axi_driver, so the override in your test does nothing. The failure shows up far from the root cause.

UVM-specific checks catch the registration while as the problem manifests, rather than leaving you in charge of finding the root cause of a symptom.

A missing library is not a code defect

library uvvm_util;
context uvvm_util.uvvm_util_context;

library bitvis_vip_axistream;
use bitvis_vip_axistream.vvc_methods_pkg.all;

These lines are perfectly fine, unless the VIP simply is not mapped in the project you are compiling. The simulator will give up and leave you searching the logs to figure out this mistake. Sigasi connects libraries to source references, immediately surfacing misconfigurations.

The language version is a project setting

library osvvm;
context osvvm.OsvvmContext;

architecture tb of axi_tb is
	shared variable Cov : CovPType;   -- protected type
begin

Whether that line is legal depends on the VHDL version the project is configured for. This isn’t visible in the file itself. OSVVM’s coverage and alert types are protected types, and a project still on an older revision is rejected by compilers and simulators. A tool that does not know your project settings cannot answer this. One that does will tell you which VHDL version supports the construct and help you migrate to it.

config_db is a string API

// env
uvm_config_db #(virtual axi_if)::set(this, "agent*", "vif", vif);

// driver
if (!uvm_config_db #(virtual axi_if)::get(this, "", "axi_vif", vif))
	`uvm_fatal("NOVIF", "virtual interface not set")

Two string literals that do not match, cause a fatal error at simulation time zero without a compilation error in sight.

• ➊ The set and the get are in different files, often written by different people.
• ➋ The only thing that connects them is a string, and nothing checks strings.

Across the boundary

// SystemVerilog testbench, VHDL design unit in library work
dut_core u_dut (
	.clk    (clk),
	.rst_n  (rst_n),
	.wr_en  (axi_vif.wr_en),
	.wdata  (axi_vif.wdata),
	.status (status)   // VHDL declares 12 bits
);

A UVM environment on top of a VHDL design isn’t some exotic use case. Yet support for mixed languages is lackluster. Sigasi’s mixed language project model blurs the separation so the port is checked against the VHDL declaration catching mistakes as they emerge.

What a coding agent is missing

An agent will write you a sequence, a scoreboard or a whole agent quickly. It does not know your library mappings, your compile order, which VIP this project actually uses, or the language revision you are on, because none of that is in the file it is reading.

Give it the project through MCP or the command line and what it proposes is checked against the real environment by the same engine you use, rather than graded by the model that wrote it. You still review it. Sigasi does not generate RTL or testbench code, and it does not decide.

Where your code goes

Analysis runs locally, on your machine or inside your own network. Project files are not sent to Sigasi servers for semantic analysis. Telemetry is optional on a commercial license and does not transmit source code.

What it does not do

It does not replace your simulator, formal tools, coverage analysis or sign-off, and it does not catch everything. Sigasi runs the most important checks before code ever reaches compilation or simulation.

Run it on your own environment

A demo says more than a thousand words. Ask for a trial and point Sigasi at a real testbench, with your VIP, your library mappings and your compile order. A field application engineer will be ready to set up with you at no charge during the trial.

Request a trial, or book a session on your own environment.