AsFigo - enabling opensource chip design and verification.

We are heading to the Design Automation Conference (DAC) to participate in the Open-Source EDA Birds of a Feather (BoF) session on Tuesday, July 28 . If you are attending DAC and are interested in how AI is changing our workflows, or if you want to streamline your verification process, we’d love for you to join us. Srinivasan Venkataramanan (Srini) will be representing AsFigo in two different sessions during the evening. Here is where you can find us: 1. Panel Q&A: Rethinking Skill Sets in the Age of AI Session: V. Workforce Development and Training ( https://open-source-eda-birds-of-a-feather.github.io/ ) Time: 8:30 PM - 9:10 PM Topic: From “How” to “What”: Rethinking Skill Sets in the Age of AI What it’s about: As generative AI tools find their way into silicon design, the day-to-day role of the engineer is shifting. This panel brings together perspectives from industry and academia (including ASU, Columbia...

At AsFigo , we have always believed that the best verification tools grow organically from real engineering friction. Over the last couple of years, as AI coding assistants have flooded into hardware workflows, that friction has fundamentally shifted. The core bottleneck is no longer just writing code—it is safely and predictably integrating AI-generated code into complex, existing environments. As a small but dedicated contributor to the open-source EDA community, we want to share the journey of how SVALint evolved from a localized parser experiment into an essential guardrail for modern AI-assisted verification. From Experiment to Ecosystem: The SVALint Journey Our work on SVALint began in early 2023, we began experimenting with the early stages of slang and PySlang . That work led to PySlint , and eventually, we built out a custom linting infrastructure specifically focused on SystemVerilog testbench (including SVA). We took those early iterations to the community, gatheri...

At the Verification Futures 2026 conference at the University of Reading, a distinct shift was evident on the floor. While traditional vendor tracks dominated their usual slots, the parallel sessions focused on open-source and license-free verification tools drew a heavily engaged technical crowd. The conversations between engineers like Srinivasan Venkataramanan and core Verilator maintainer Geza Lore centered on a major milestone: the real-world production stability of running Universal Verification Methodology (UVM) natively on Verilator's public master branch. Nearby, discussions with contributors like Yogish Sekhar tracked how this foundation is now letting developers expand into native FSM code coverage extraction and advanced random constraint solving engines. But this current stability wasn't achieved through sweeping architectural changes. It came down to breaking a single, frustrating bottleneck earlier this year: the time-0 scheduling deadlock. The Ba...

The Invisible Include: Why SystemVerilog Migration Drag Demands a "Build Your Own Linter" (BYOL) Approach Tool migration is rarely a weekend project. When a team decides to switch SystemVerilog (SV) simulators—whether for faster execution, better coverage metrics, or licensing reasons—the expectation is usually a straightforward port. The RTL compiles in Tool A, so it should compile in Tool B, right? Then reality sets in. The migration timeline begins to stretch, not because of major architecture rewrites, but because of a grinding stream of minor environment and language compliance discrepancies. One of the most elusive "gotchas" in large codebases stems from how different simulators handle a seemingly simple task: finding an include file. The Local Include Trap Consider a standard file structure where an RTL file includes a local header located in the exact same directory: src/ └── core/ ├── cpu_top.sv └── cpu_defines.svh Inside cpu_top.sv ,...

Troubleshooting UVM Report Server Fractures: When UVM 1.2+ Code Meets a UVM 1.1d Environment When maintaining legacy testbenches or integrating modern third-party Verification IPs (VIP), engineers frequently hit a brick wall: code written using modern UVM idioms fails with catastrophic compile errors when forced into a UVM 1.1d environment. The root cause is a silent, backward-incompatible structural redesign of the UVM reporting API that occurred between UVM 1.1d and UVM 1.2. The Architectural Shift If your code was written for UVM 1.2 or IEEE 1800.2, it likely utilizes uvm_default_report_server and overrides compose_report_message . When this code hits a UVM 1.1d simulator, the compilation crashes because those components literally do not exist yet. In UVM 1.1d , uvm_report_server is a concrete base class, and formatting relies on scalar string/integer arguments. In UVM 1.2+ , uvm_report_server was turned into a virtual class, its concrete imp...

We opened our DVCon US ’26 Birds of a Feather session with the most electrifying—and anxious—question in the industry today: Is AI going to take your engineering job? To answer this, we turned to Clifford Cummings , world-renowned HDL Synthesis trainer, and Yatin Trivedi . Their consensus was a much-needed reality check: The tools are changing rapidly, but the need for fundamental engineering expertise is more critical than ever. The Trust Gap and the Junior Engineer Dilemma One of the biggest risks discussed in the panel is the assumption of correctness. AI tools can, and often do, get things "completely wrong." There is a growing concern that junior engineers, impressed by the speed of generative AI, often assume the output is correct and submit it without proper verification. This creates a dangerous Trust Gap . You cannot fix what you do not understand. Maintaining a strong foundational background in chip design is absolutely essential to identify, de...