AsFigo - enabling opensource chip design and verification.

Join AsFigo—trailblazers in open-source SVA, UVM Lint, and simulation workflows since 2023—for an exclusive San Diego meetup where we will unpack the next era of semiconductor innovation. MS Teams link:  https://teams.microsoft.com/meet/39182483503977?p=BgU2EhioUoKoNVfOfR   Date: Thursday, July 30, 2026 Time: 5:30 PM – 7:30 PM (PDT) Location: Capital One Café - San Diego (Community Room 1) | 4311 La Jolla Village Drive, San Diego, CA, 92122 Format: Hybrid (In-Person & Virtual via MS Teams) Hosted By: AsFigo (UK) Cost: Free (Registration Mandatory) The Next Wave of Semiconductor Innovation The semiconductor landscape is undergoing a massive paradigm shift. As hardware complexity skyrockets, traditional Electronic Design Automation (EDA) workflows are meeting their match. Enter open-source EDA and artificial intelligence —a powerful combination that is tearing down barriers, accelerating innovation, and transforming how...

As we gear up for the 63rd Design Automation Conference (DAC) next week, the engineering team at AsFigo (in collaboration with VerifWorks) is rolling out a major extension to SVALint —our blazing-fast, Verible-backed SystemVerilog Assertion linter. Among our new suite of functional correctness checks, one major hazard we are targeting is the misapplication of liveness operators in dynamic simulation environments: specifically, bounded weak-strong patterns like eventually s_always . The Trap: A Common Scenario with pll_locked Consider a standard verification check for a clock generation block. An engineer writes an assertion expecting that within a reasonable window after reset, the PLL locks and remains permanently stable: // Risky Assertion Style property p_pll_stable; @(posedge clk) disable iff (!rst_n) eventually [1:10] always pll_locked; endproperty : p_pll_stable a_p_pll_stable : assert property (p_pll_stable) else begin `uvm_error("a_p_pll_s...

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...