JacVerify

Autonomous chip verification—from design specs to verified RTL, testbenches, and coverage reports.

Inspiration

AI can generate RTL faster than ever, but generating code is not the same as proving that it is correct. Chip verification remains a fragmented, manual loop across specifications, RTL, testbenches, logs, waveforms, and coverage data.

This bottleneck is growing with the industry. Global semiconductor sales reached $795.6 billion in 2025, up 26.2% year over year (WSTS), yet only 14% of IC/ASIC projects achieved first-silicon success in the 2024 Siemens/Wilson Research study (Siemens). Verification engineers also spend roughly 41–46% of their time debugging, depending on the type of project (Semiconductor Engineering).

Hiring alone cannot close the gap: Deloitte estimates that the semiconductor industry will need more than one million additional skilled workers by 2030 (Deloitte).

Based on verification-tool and engineering-labor spending, we estimate a long-term market opportunity of approximately $20 billion. We begin with smaller fabless, FPGA, university, and open-source teams—especially the RISC-V ecosystem, which has grown from 236 to more than 4,600 members across 70 countries (RISC-V International).

Inspired by our team's hands-on experience in chip verification, software engineering, and AI products, we built JacVerify to turn this manual process into an auditable agentic workflow.

What it does

Users upload an RTL design and its design specification. JacVerify turns the specification into structured requirements, generates testbenches, and runs the design through real verification tools.

When a test fails, JacVerify collects evidence and determines whether the issue is in the testbench or the RTL. It then modifies the appropriate artifact while continuing to treat the specification as the source of truth. The system re-runs targeted tests and regressions until the updated flow reaches its verification goals.

The final outputs include:

Updated RTL design
Updated testbench
Coverage report generated from the updated test flow
Requirement-to-test-and-evidence traceability

The complete loop is:

Design + Specification → Tests → Simulation → Diagnosis → Test or RTL Update → Re-verification → Coverage Report

How we built it

JacVerify uses Jac and Jaseci as its workflow and memory layer. Requirements, modules, tests, runs, failures, hypotheses, artifacts, and coverage results are stored as nodes in a persistent verification graph. Their relationships form an auditable evidence chain.

Jac Walkers drive each stage of the workflow: specification ingestion, requirement extraction, test generation, simulation, failure diagnosis, artifact modification, re-verification, and reporting.

We use byLLM, Spark1, and LiteLLM for constrained semantic tasks and model routing, including interpreting requirements, generating tests, and ranking root-cause hypotheses. Passing or failing is never decided by the LLM. It must come from real tool results.

Our implementation stack includes:

Icarus Verilog for compiling and simulating Verilog and SystemVerilog RTL
Python and pytest for generated tests, regression execution, result parsing, and coverage aggregation
Firecrawl for ingesting web-based specifications and supporting context
React, Vite, JSX, Zod, and CSS for the interactive dashboard, typed validation, and interface
Jac, Jaseci, and byLLM for graph memory, agent orchestration, and constrained reasoning

Built with: Jac, Jaseci, byLLM, Icarus Verilog, SystemVerilog, Verilog, EDA, RTL, Firecrawl, Spark1, LiteLLM, Python, pytest, React, Vite, JSX, Zod, and CSS.

Challenges we ran into

The first challenge was translating natural-language specifications into precise, testable requirements without losing their original intent.

The second was distinguishing a faulty design from a faulty testbench. A failed test does not automatically mean the RTL is wrong, so every proposed change must be checked against the specification.

We also had to prevent the LLM from judging its own work. Generated tests and RTL changes can look plausible while still being incorrect. We addressed this by requiring every artifact to compile, simulate, and produce reproducible evidence through real tools.

Finally, hackathon time forced us to focus on one complete end-to-end loop instead of many disconnected features.

Accomplishments that we're proud of

Built a complete specification-to-verification workflow
Generated tests directly from design requirements
Used real simulator feedback to diagnose failures
Supported updates to either the testbench or RTL
Re-verified modified artifacts instead of trusting AI output
Generated a coverage report from the final test flow
Preserved a traceable graph connecting requirements, tests, runs, failures, and evidence

What we learned

We learned that useful AI verification is not primarily about generating more code—it is about managing evidence.

Persistent memory, explicit workflow state, reproducible tool execution, and requirement traceability are what make an agent trustworthy. Test generation and design repair must remain grounded in the same specification, while deterministic EDA tools—not model confidence—must make the final pass/fail decision.

What's next for JacVerify

Next, we plan to support larger SystemVerilog and RISC-V designs, add formal verification through SymbiYosys, improve coverage-gap analysis, and introduce human approval gates for higher-risk RTL changes.

We also plan to integrate JacVerify into CI workflows so that teams can continuously turn changing design specifications into updated tests, verified RTL, measurable coverage, and auditable evidence.

Our long-term vision is a chip verification engineer that never sleeps.