The Death of the Waveform Viewer: Veriest’s Predrag Nikolic on Where AI Really Works in Chip Verification
On episode 10 of Wearing Flip-Flops, the semiconductor and chip design podcast hosted by Ronen Laviv, our AI Tech lead, Predrag Nikolic, gave a practitioner’s view of AI in design verification: what works today, what still breaks, and why simulation runtime may become the bottleneck that matters most. Listen to the full episode on the Wearing Flip-Flops website.
Every verification engineer has the same muscle memory. A regression fails, the log is not enough, and you open the waves. Predrag expects a lot less of that in the next couple of years, and he is careful to frame it as a hope rather than a prediction. The reasoning behind it, and the gaps that still stand in the way, make this one of the most grounded conversations about AI in verification we have had on the show.
Key takeaways
- Debug and simulation time are the two big bottlenecks. AI is shortening debug, which makes the time to rerun SoC regressions the next wall.
- General-purpose AI handles simple debug well. When the symptom and the root cause sit in the same place, tools like GitHub Copilot and Cursor do the job. Multi-hop root cause analysis at SoC level is where they fail.
- AI across the UVM flow works best step by step. Specification review, verification plans from templates, and testbench code built one component at a time.
- Build the simple parts, buy the hard ones. Code generation can be built in-house. Complex root cause analysis and coverage closure need specialized tools or real machine learning teams.
- SystemVerilog stays while humans review the code. The reviewer, not the model, is the constraint.
- Waveform viewers become the fallback, opened only when AI cannot be trusted with the answer.
Why a practitioner view matters
As a design and verification services house, Our engineers work inside customer teams, with the customer’s tools and flows, across many companies at once. As our AI lead, Predrag has an unusual vantage point. He is a verification engineer by background, leads Veriest’s internal AI development unit, and has moderated DAC sessions featuring more than a dozen AI EDA startups. What Predrag describes is a pattern across many SoC verification flows, not one team’s experience.
His unit’s mandate is practical: find where AI actually works and where it does not, then translate that into customer projects, both by delivering verification with AI and by helping customers build their own AI skills and agents.
The two key bottlenecks: debug and simulation time
Chips keep getting more complex, and the core challenge stays the same: deliver on time. AI already helps with understanding specifications and generating code. Debug is where Predrag sees the most room to improve, which matches the industry data. The 2024 Wilson Research Group functional verification study commissioned by Siemens EDA again found debug to be the largest single slice of a verification engineer’s time, and reported first-silicon success at just 14 percent, the lowest in two decades.
The second bottleneck arrives at subsystem and SoC level, where several blocks or clusters talk to each other over NoCs in long, complex scenarios. There, simulation time takes over.
“SoC simulation time is a significant problem. So even if AI solves all the code generation and debugging, we will still need to rerun the tests, and the turnaround time of the tests is very long.”
Speeding up simulation, whether through emulation or other approaches, is already one of the main pain points. As AI improves everything else, Predrag expects it to become the main one.
Where general-purpose AI works, and where it breaks
Most semiconductor companies today use general-purpose platforms like GitHub Copilot and Cursor, mostly to generate code. For debug, these tools work well when the symptom and the root cause are in the same place. That covers compilation failures and simpler simulation failures, typically at IP level, where there is not much code or data involved.
Real debug is rarely that tidy. The failure shows up in a log print, you step back, find that the first step is only where the bug propagated, and step back again. At subsystem or SoC level this multi-hop root cause analysis (RCA) involves large amounts of code and specification, and it breaks the LLM’s context window. The workarounds exist but they are not perfect. Worse, the model does not know when it is lost.
“It will never come back and say I don’t have a solution. It will give some solution, but it will be wrong, and then you will continue iterating, wasting time and tokens.”
This is where the AI EDA startups shine. Their tools structure and interpret large amounts of debug data and help the AI trace root causes backward efficiently rather than parsing raw data all at once. Better hypotheses mean fewer regression reruns, and on an SoC, every avoided rerun saves both tokens and days.
AI across the UVM verification flow, step by step
Specification and verification planning
AI can find gaps in a specification and suggest fixes, then draft the verification plan, test plan and coverage plan. The catch is in the prompt. Ask it to “create a verification plan from this specification” and you will get the wrong template, uneven detail and weak diagrams. The approach Predrag recommends is to give it the company template, with sections and expected level of detail, and have one engineer iterate with the AI until the output is right. That engineer then packages the workflow into skills or agents: one that reads and describes the spec’s diagrams, one that fills the template, and one that draws new diagrams. Done properly, and with a template used company-wide, the output is 90 to 95 percent of the way there.
Testbench and SystemVerilog code generation
Code generation works well, but not if you ask for the entire environment at once. Asking for the complete testbench and tests in one go usually produces a mess you then have to clean up. The better path mirrors how an engineer would build it by hand: start with an empty shell that compiles, then add the sequencer and driver, clean up, then the monitor, the configuration, master and slave agents, and so on. One artifact, or one group of related artifacts, at a time.
Coverage closure
AI is very good at writing coverage code. Coverage closure is harder. According to Predrag, AI can help close roughly 90 percent of functional coverage, but the last 10 percent, which is also the hardest part for human engineers, still needs substantial human guidance or manual work. This is another area where specialized AI EDA tools currently outperform general-purpose LLMs.
Build or buy AI verification infrastructure?
Most companies Predrag sees still lean toward building their own AI solutions. Some stop early: if the AI cannot debug from logs and waves, they conclude AI is not ready yet and wait for the next model. His view is that a team made up only of design and verification engineers and architects cannot build a good RCA solution today, because it takes more than prompting skills. It takes software and machine learning engineers who know how to structure large amounts of data, realistically three to ten of them depending on company size, for a solution that is maintainable.
“Build your solutions for code generation and specification understanding, but for complex debugging and complex coverage closure, it’s better to look for the solutions that are already on the market.”
Large companies with in-house software teams have an advantage if they can free those people up. Whether it pays off against buying an existing tool is still an open question.
Will SystemVerilog survive? Will waveform viewers?
Predrag does not expect verification languages to change in the next two years. LLMs are better at Python because there is far more of it in their training data, but a human still reviews every line, and that human is a verification engineer who knows SystemVerilog.
“I think that until a human is in the loop to do the code review, SystemVerilog will remain dominant.”
Waveform viewers are a different story. A waveform viewer is a human debug interface; AI can already work with waveform data directly, without the picture.
“I think AI will improve significantly in the debugging domain in the next year or two, and simply we will have less need to open waveforms.”
Waves become the fallback, opened when the AI is clearly struggling. Predrag also flagged a field he finds promising: predicting coverage from the RTL, the verification environment and the specification before simulation, and improving tests and constraints so the first regression lands near 90 percent coverage instead of 50 to 70. He noted that formal verification also has a lot of potential to combine with AI, though it sits outside his own expertise.
Productivity, juniors, and the next bottleneck
Asked to quantify the impact, Predrag put the overall productivity gain at below 50 percent, while stressing that it is significant across every domain. Some tasks collapse dramatically: SoC connectivity checks across hundreds or thousands of ports, which take a long time by hand, close in about ten minutes with AI.
The side effect he is watching is lower demand for junior engineers, since a senior who operates AI well gains the most and still reviews code faster. His hope is that the gains translate into shorter project cycles and more projects delivered, rather than fewer people.
After simulation time, the next frontier is making autonomous flows actually work. Closed-loop verification, where AI debugs a failure, proposes a fix, reruns the regression and moves on, exists at most serious shops. Almost nobody runs it day to day, because if the AI debugger does not produce good hypotheses, the loop iterates endlessly.
What EDA vendors need to deliver
Predrag expects the big EDA companies to use their data and experience to close the gaps he described, ideally with push-button solutions for debug and coverage closure. Multi-vendor flows already work: a startup tool can sit alongside a Cadence, Synopsys or Siemens simulator, connected through MCP or other interfaces, because you will always need the simulator. The harder question is deeper access to each simulator’s internal databases, and that, he says, is as much a business decision as an engineering one.
How verification engineers should prepare
Everyone needs to use AI, and that starts with training. Many engineers assume prompting is easy, but prompting strategies and how to divide a task make a large difference. Veriest runs internal AI training and also offers it to customers. Beyond training, Predrag’s advice is simple: be open-minded, be creative, and use AI as much as possible. Engineers who embrace it will stay relevant, even if their work takes a somewhat different shape.
Frequently asked questions
Can AI replace the waveform viewer in chip verification?
Not yet, but its role is shrinking. Predrag Nikolic, AI Tech Lead at Veriest, expects AI debug that reads simulation data directly to cut how often engineers open waveforms within the next one to two years. Waves become the fallback when the AI answer cannot be trusted, rather than the first step.
Where does AI help most in UVM verification today?
Specification review, verification plan drafting from a company template, SystemVerilog and UVM code generation built step by step, coverage code generation, and repetitive SoC connectivity checks. It still struggles with multi-hop root cause analysis at subsystem and SoC level and with the last 10 percent of coverage closure.
Should chip companies build or buy AI verification tools?
Predrag recommends building in-house for code generation and specification understanding, and buying specialized AI EDA tools for complex root cause analysis and coverage closure, which need dedicated machine learning and software engineering skills.
Will Python replace SystemVerilog for verification?
Not while humans review the code. LLMs write better Python because there is far more of it in their training data, but verification engineers review every line and they know SystemVerilog. Predrag expects SystemVerilog and UVM to remain dominant for at least the next two years.
What is the next bottleneck in verification once AI speeds up debug?
Simulation runtime. Even if AI generates and debugs the code, every fix still needs a regression rerun, and SoC-level simulations can take hours to days.
Where can I listen to this semiconductor podcast episode?
On the Wearing Flip-Flops website at wearing-flip-flops.com, and on Apple Podcasts, Spotify and YouTube.
Listen to the full episode
The complete conversation, “The Death of the Waveform Viewer,” is episode 10 of Wearing Flip-Flops. Find it, with show notes, on the Wearing Flip-Flops website.
The episode is also available on all major podcast platforms: Apple Podcasts, Spotify and YouTube. If you enjoyed Predrag’s insights, please rate the episode on your preferred platform. It helps other chip designers and verification engineers find the show.
About Wearing Flip-Flops
Wearing Flip-Flops is a semiconductor and chip design podcast hosted by Ronen Laviv, for the engineers, architects and leaders who actually build chips. Episodes go deep on functional verification, SystemVerilog and UVM, RTL design, emulation, EDA, silicon architecture, the engineering behind the AI hardware buildout, and the semiconductor geopolitics that shape the supply chain. Browse all episodes or follow the show on LinkedIn and YouTube.
About Veriest
Veriest provides design and verification, backend and DFT, and ASIC and FPGA engineering services, working hands-on inside customer teams from offices in Israel, Serbia, Hungary and the UK. Veriest’s AI development unit helps customers deliver verification with AI and build their own AI skills and agents. Contact Veriest to learn more.
About the author: Ronen Laviv is the host of Wearing Flip-Flops, the hardware and semiconductor podcast. He has more than 25 years in semiconductors, starting in SoC development at National Semiconductor, followed by 14 years at Cadence working with the world’s largest design teams on frontend, backend, analog, emulation and IP, and then AWS, helping chip companies move to the cloud.