Scaling Debug Wisdom with Bronco AI

In the business press today I still find a preference for reporting proof-of-concept accomplishments for AI applications: passing a bar exam with a top grade, finding cancerous tissue in X-rays more accurately than junior radiologists, and so on. Back in the day we knew that a proof-of-concept, however appealing, had to be followed by the hard work required to transition that technology to a scalable solution, robust in everyday use across a wide range of realistic use cases. A less glamorous assignment than the initial demo, but ultimately the only path to a truly successful product. The challenge in productization for AI-based systems is that the front-end of such products intrinsically depends on a weak component: our imperfect directions to AI. I recently talked to David Zhi LuoZhang, CEO of Bronco AI, on their agentic solution for verification debug. I came away with a new appreciation for how scaling our learned debug wisdom might work.

The challenge in everyday debug

When we verification types think of debug challenges we naturally gravitate towards corner case problems, exemplified by a strange misbehavior that takes weeks to isolate to a root cause before a designer can even start to think about a fix.

But those cases are not what consume the bulk of DV time in debug. Much more time-consuming is triage for the hundred failures you face after an overnight regression, getting to first pass judgment for root causes and assigning to the right teams for more detailed diagnosis. Here some of the biggest time sinks more likely come from mis-assignments rather than from difficult bugs. You thought the bug was in X but really it was in Y or in an unexpected interaction between Y and Z.

How do DV teams handle this analysis today? It’s tempting to imagine arcane arts practiced by seasoned veterans who alone can intuit their way from effects to causes. Tempting, but that’s not how engineering works and it would be difficult to scale to new DV intakes if they could only become effective after years of apprenticeship. Instead DV teams have developed disciplined and shared habits, in part documented, in part ingrained in the work culture. Consider this a playbook, or more probably multiple playbooks. Given a block or design context and a failure, a playbook defines where to start looking first, what else to look at (specs, RTL, recent checkins, testbench changes, …), what additional tests might need to be run, drilling down through a sequence of steps, ultimately narrowing down enough to likely handoff targets.

Tough stuff to automate before LLMs and agentic methods. Now automating a significant chunk of this process seems more within reach.

The Bronco.ai solution

The Bronco solution is agentic, designed to consume overnight regression results, to triage those result down to decently confident localizations, and to hand off tickets to the appropriate teams.

Playbooks are learned through interaction with experienced DV engineers. An engineer starts with a conversational request to Bronco AI, say

“I want to check that my AES FSMs are behaving properly. Check for alerts, interrupts, stalls, and that the AES CTR counter FSM is incrementing for the right number of cycles”

The engineer also provides references to RTL, testbench, specs, run log files, waveforms and so on. The tool then suggests a playbook to address this request as a refined description of the requirement. The engineer can modify that refined version if they choose, then the tool will execute the playbook, on just that block if they want, or more comprehensively across a subsystem or the full design and then will report back as required by the playbook. During this analysis, Bronco AI will take advantage of proprietary AI-native interfaces to tap into tool, design, spec and other data.

Playbooks evolve as DV experts interact with the Bronco tools. David was careful to stress while the tool continuously learns and self-improves through this process, it does not build models around customer design or test data but rather around the established yet intuitive debug process (what David calls the “Thinking Layer”), which becomes easier to interpret and compartmentalize (and if needed can be forgotten).

He also clarified an important point for me in connecting specs to RTL design behavior. There is an inevitable abstraction gap between specs and implementation with consequent ambiguity in how you bridge that gap. That ambiguity is one place where hallucinations and other bad behaviors can breed. David said that they have put a lot of work into “grounding” their system’s behavior to minimize such cases. Of course this is all company special sauce, but he did hint at a couple of examples, one being understanding the concept of backtracking through logic cones. Another is understanding application of tests to different instantiations of a target in the design hierarchy, obvious to us, not necessarily to an AI.

The Bronco.ai philosophy

David emphasized that the company’s current focus is on debug, which they view as a good motivating example to later address other opportunities for automation in verification and elsewhere in the design flow  He added that they emphasize working side by side with customers in production, rather than in experimental discovery in pre-sales trials.  Not as a service provider, but to experience and resolve real problems DV teams face in production, to refine their technology to scale.

I see this as good progress along a path to scaling debug wisdom. You can connect with Bronco.ai starting HERE.

Also Read:

Arm Lumex Pushes Further into Standalone GenAI on Mobile

The Impact of AI on Semiconductor Startups

MediaTek Dimensity 9500 Unleashes Best-in-Class Performance, AI Experiences, and Power Efficiency for the Next Generation of Mobile Devices