Know Your Unknowns: Building Knowledge Bases for Your VLSI Engineering Organization (Practical Rules)
- Adi Fuchs
- May 12
- 3 min read
AI coding agents are often introduced as productivity 'boosters,' yet they frequently fail in the high-precision world of hardware design. The limiting factor in VSLI design isn’t model strength, it’s whether the agent is operating inside your workflow and your context.
To make AI coding agents useful in VLSI, you need a small set of repeatable guidelines that turn “AI help” into an engineering capability other teams can adopt. Based on our experience at Speedata, we recommend the following:
High-level guiding rules:
Skills, Skills, Skills. As AI platforms enter the agentic era, one must harness (pun intended) the capabilities of an agent running and carrying out routine tasks. Look at common tasks that your engineers repetitively do and distill them into a “skill” which is a set of instructions, actions and guidelines of how the AI agent would carry out this task - for example, we developed a skill for “verification environment stabilization”.
It defines how a verification environment is structured, how it should run a test, and how it interfaces with the DUT. In the beginning the agent would prompt the user for the directories of the VE and DUT code, and a pointer for the spec. The agent runs the test, compares the expected results against the spec, fixes the VE code, and rerun the test. It loops until the test passes, or until the AI agent has determined there’s a DUT bug.
BE CAREFUL: you must add a constitutional rule for the AI agent to fix the verification environment only based on the spec and it must never, under any condition, use the DUT as reference. otherwise , it might get tainted by the DUT and mimic potentially erroneous behavior.
Pair instructions with examples. Detailed instructions matter, but examples matter more: command lines, directory patterns, “good” diffs, and existing test/coverage patterns. The agent should be learning your local distribution, not inventing a generic one.
Make context explicit and persistent. Treat context as an artifact: keep a living state.md that the agent must read before acting and update after changes. This prevents repeated mistakes and “confident déjà vu” bugs across iterations.
Practical rules for building an AI-ready VLSI environment:
Standardize the workflow boundaries. Provide “golden commands” for lint/sim/regress/coverage and a known folder structure. Most AI waste comes from ambiguity about where things go and how to run them.
Require traceability, not just output. Every generated test, sequence, or coverage item should map back to a plan item or a known gap, and every RTL change should map back to a specific tool finding or failing test.
Default to minimal diffs and incremental progress. Keep changes small, local, and reversible. Agents are great at producing volume; your environment should force reviewable, staged edits.
Use evidence as the gate. The agent proposes; tools decide. Require logs, repro commands, or tool outputs for claims (“this fixes X,” “this improves Y”).
Separate stable methodology from changing project state. Keep reusable rules (UVM structure, reset/CDC conventions, review expectations) separate from dynamic context (current failures, exceptions, temporary constraints). This keeps the system portable and prevents stale context from poisoning results.
Define human-only decisions up front. Let agents draft fixes and scaffolding, but reserve architectural decisions, CDC sign-off, and tapeout readiness for humans. Autonomy should be a deliberate budget, not an accident.
The following infographic from Gemini 3 pro is useful for people (like me) who are visual cue learners:
Conclusions and the future
Today we covered what it actually takes to apply AI coding agents inside real VLSI development environments. At Speedata, we’re already implementing this and getting meaningful value (faster iteration, better triage, more automation), but it’s equally clear that “using today’s tools” isn’t the finish line. The bigger enterprise challenge shows up fast: most organizations take an infrastructure stack built for humans and simply bolt AI onto it.
That pattern can work as a starting point, but it’s inherently limiting. As Sam Altman put it on the Big Technology Podcast, bolting AI onto the existing way of doing things is unlikely to be as effective as reimagining the whole system in an AI-first world.
VLSI won’t be an exception. The real game changer is “Build for AI”: redesigning the VLSI engineering process, stack, and tooling from first principles so human engineers and AI agents collaborate natively. That means workflows that assume agents are present, artifacts that are machine-readable by default, and environments where context, intent, and state are not tribal knowledge scattered across scripts, wikis, and Slack, but rather first-class citizens.
