Open-Source LLM-Driven Formal Verification: A Multi-Agent Pipeline for RTL Repair

Imagine you are building a massive, intricate castle out of digital Lego bricks. This is what engineers do when they design computer chips: they write code called RTL (Register Transfer Level) that tells the tiny transistors how to behave. But here's the catch: if even one brick is placed in the wrong spot, the whole castle might collapse when the power is turned on. Checking for these mistakes is the hardest part of the job, often taking up more than half the time. Traditionally, engineers have used two main ways to check their work. The first is like a "test drive," where they run the chip through a few specific scenarios to see if it breaks. The second is "formal verification," which is like a super-mathematical proof that guarantees the castle will stand up under every possible condition, not just the ones they tested. However, this super-proof method usually requires expensive, locked-down software that only big companies can afford.

Enter the new kid on the block: Large Language Models (LLMs). You might know them as the AI chatbots that can write stories or code. Recently, people started asking: "Can an AI be the architect that fixes our broken digital castles?" The big question is whether an AI can not only spot a mistake but also fix it in a way that is mathematically proven to be perfect, without needing to buy a million-dollar software license. This paper dives right into that question, trying to build a bridge between the creativity of AI and the strict, unyielding logic of formal math, using only free, open-source tools.

The AI Detective and the Open-Source Toolbox

In this study, a researcher named Ha Trung Tran built a clever team of AI agents to act as a repair crew for broken chip designs. Think of it as a high-tech detective squad working in a loop. Instead of one AI trying to do everything at once, the team is split up: one agent reads the blueprints, another writes the rules for what the chip should do, a third checks the work, and a fourth actually fixes the code.

The secret sauce here is how they check for mistakes. Most AI repair tools just run a few test drives (simulations) to see if the chip works. But this team uses a "formal backend"—a free, open-source math engine made of tools called Yosys, SymbiYosys, and Z3. This engine doesn't just guess; it tries to prove mathematically that the chip is correct. If the chip fails, the engine doesn't just say "it's broken." It hands the AI a specific "counterexample," which is like a video replay showing exactly how the castle collapsed. The AI then watches this video, figures out what went wrong, and tries to fix it. They keep doing this—check, find the crash, fix, check again—until the math proves the chip is perfect or they run out of tries.

The Good News: It Works (Sometimes)

The researchers tested this system on six different types of digital designs, ranging from a simple calculator part (an ALU) to more complex traffic controllers and memory units. The results were a mix of triumph and clear limitations.

The star of the show was the ALU (Arithmetic Logic Unit), which is like the calculator brain of a chip. The researchers intentionally broke it by swapping an "AND" operation for an "OR" operation. The AI team spotted the error immediately. In just two rounds of checking and fixing, they repaired the code. More importantly, the open-source math engine proved with 100% certainty that the fix was correct for every possible number the chip could ever process. This happened in all five test runs, taking an average of just 16.5 seconds. It proved that the idea works: an AI, guided by open-source math tools, can find and fix a real bug with a mathematical guarantee.

The Bad News: Where the AI Got Stuck

However, the story isn't a total victory. When the researchers tried the same process on the other five designs, the AI team hit a wall. They couldn't fix any of them reliably. The paper carefully breaks down why they failed, identifying four distinct "failure modes" that act like traps for the AI:

1. The "Too Deep" Trap (Bounded-Cover Vacuity): In one case (a counter), the math engine said "FAIL" even though the fix was actually correct. Why? Because the design needed to run for 256 cycles to reach a specific state, but the tool only looked 256 cycles deep. It was like trying to prove a car can drive across the country by only driving it for one mile; the tool couldn't see the destination, so it gave up. The paper notes this is a limit of the tool, not the AI.
2. The "Confusing Instructions" Trap (Specification Ambiguity): For another design (an arbiter), the AI tried to follow the written rules, but the rules asked for something impossible (like a traffic light that changes without a clock). The AI faithfully followed the impossible instructions, leading to a dead end.
3. The "Time Travel" Trap (Temporal Logic Bugs): In two cases (a UART transmitter and a FIFO memory), the bugs involved events happening over multiple time steps. The AI was great at fixing single-step logic (like the calculator), but it struggled to reason about sequences of events that happened over time.
4. The "Too Many Rules" Trap (Multi-Property Pressure): In the final case (an AXI Lite slave), there were so many rules the chip had to follow at once that fixing one rule broke another. The AI got stuck in a loop, unable to find a solution that satisfied everyone.

A Hidden Glitch in the Toolbox

There was also a surprising discovery about the open-source tools themselves. The researchers found that the Yosys tool, which helps process the code, has a hidden quirk. If you try to attach the safety checks (assertions) to the design using a specific method called "bind," the tool silently ignores them. It's like putting a security camera in a room but having the camera unplugged; the system thinks everything is fine because it never sees the camera. The researchers had to change their method to "inject" the checks directly into the code to make sure the math engine actually saw them. This is a helpful tip for anyone else using these free tools.

The Bottom Line

This paper is a "feasibility study," which is a fancy way of saying, "We tried it, and here is exactly where it works and where it breaks." The main finding is that it is possible to use an AI to fix chip designs with a mathematical proof of correctness, but only if you use open-source tools and if the problem isn't too complex.

The author is honest about the limits: the system is great at fixing simple, immediate logic errors (like the calculator), but it currently struggles with complex timing issues, deep memory states, or designs with conflicting rules. They didn't claim to have solved the problem of chip repair; instead, they drew a clear map showing the "safe zone" where the AI works and the "danger zone" where it gets lost. By using only free tools, they hope to lower the cost of entry for this kind of research, proving that you don't need a million-dollar budget to start building the future of reliable hardware design.