Posts

Showing posts with the label UVMLint

UVM on Verilator: Mapping the Minefield (The Technical Deep Dive)

While our previous posts focused on the strategic "Why," this post addresses the "How." Porting 50+ production-grade UVCs wasn't a matter of simple recompilation. It was an exercise in uncovering the delta between commercial simulator "permissiveness" and the strict reality of the SystemVerilog LRM and the Verilator execution model. Here are the some of the primary technical roadblocks we mapped and cleared.  You can learn lot more at our upcoming event on Thursda y, get your tickets today:  https://buytickets.at/asfigo/2091884   1. Strict LRM & Parsing Enforcement Commercial tools have historically been "lazy" with LRM enforcement. Verilator is not. Code that has run for years in proprietary silos often fails immediately here due to: SVA: Basic temporals do work, not complex ones. We have ported AHB, APB and AXI4-Lite SVA IPs to Verilator, so though this sounds very limiting, in reality, it is not that bad! Range Syntax: Not so...

Cracking the UVM-Verilator Code: 50+ IPs, AI Guardrails, and the Open-Source North Star

UVM on Verilator Isn’t Impossible. It’s Just Hard. We Did It Anyway. The “standard” line in the industry: UVM and Verilator don’t mix. Enterprise-grade open-source verification is a fantasy. So we put that claim under load. ✔ 50+ production UVCs ported ✔ 35 + non-obvious failure modes uncovered ✔ Converted into UVMLint and SVALint rules ✔ AI guardrails to prevent regressions This post is the why and what; the how and numbers are for the room at Hacker Dojo.  This is production-grade code—the kind that tapes out chips—running on open-source infrastructure. The implication is bigger than a port: Reduced dependency on closed ecosystems. Negotiating leverage with EDA vendors. Strategic control over your verification stack. If you’re a semiconductor company exploring Verilator for serious IP, don’t start from scratch. Start from the team that already mapped the minefield. 📅 Join us at the Hacker Dojo Next Thursday, the AsFigo team...

Catching Extra Semicolons After UVM Macros with UVMLint

A solution‑first guide to preventing the classic dangling else error caused by UVM reporting macros. UVMLint Rule: No Trailing Semicolon After UVM Reporting Macros Define a lint rule that flags any UVM reporting macro invocation immediately followed by a semicolon. Implementation detail: This rule should be parser‑aware . Avoid pure regex; require an AST/token stream so comments, strings, and macro line breaks are handled correctly. Why This Rule Exists Consider a simple user code as below:  // Buggy code if (debug_on) `uvm_info("DEBUG", "state info", UVM_LOW); // semicolon here else $display("Doing something else"); The UVM BCL defines  `uvm_info  as a  complete  begin...end  block . Adding a semicolon after the macro turns into a null statement that terminates the  if  prematurely, leaving the  else  orphaned. // UVM BCL (abridged) `define uvm_info(I...

Why Regex-Based Linters Fall Short for SystemVerilog/UVM — A Case for Parser-Based Tools

Image
Linting SystemVerilog and UVM testbench code is crucial to maintain quality and compatibility. Many teams start by writing quick regex or string-search scripts to catch problematic patterns—like deprecated variables, disallowed constructs, or outdated API usage. While regex-based linting can be tempting due to its simplicity, it often leads to false failures and missed issues because SystemVerilog’s syntax and preprocessing are too complex for simple text matching. In this series, we will explore common linting scenarios, we introduced this in an earlier post here:   https://asfigo.blogspot.com/2025/02/linting-systemverilog-testbench-code.html  Below is the next one in this series with a concrete example - detecting deprecated UVM constructs like uvm_top , and demonstrate why a proper parser-based approach using tools like Google’s Verible is superior. A Quick, regex style lint example When maintaining UVM code for compatibility, one common check is to detect the use of u...

From Guesswork to Metrics: Measuring Constraint Complexity in SystemVerilog (Part 1)

🚀 Why Care About Constraint Complexity? In SystemVerilog, constraint blocks are a core part of constrained-random verification. As your testbenches scale up, these blocks can become: Hard to read Difficult to debug Slow to solve Prone to over- or under-constraining Yet most teams rely on intuition or manual review to judge constraint quality. What if we could measure complexity more objectively? This is where Halstead Complexity Metrics come in. 📐 What Are Halstead Metrics? Originally developed by Maurice Halstead in the 1970s for software code analysis, these metrics: Count operators and operands Compute values like: Volume (how much information the code conveys) Difficulty (how hard it is to understand) Effort (how much mental work is required) Estimated bugs (how likely the code is to be error-prone) They’ve been applied in languages like C/C++, Java, and P...

Driving UVM Quality: Join Our Next UVMLint Meetup in Newbury - Jul 18, 2025

Following the positive reception and thoughtful engagement at our recent technical meetups in Reading and Cambridge , AsFigo is pleased to invite you to our next UVMLint Technical Meetup , taking place in Newbury — a region with a strong footprint in semiconductor design and verification. This free, hybrid event offers a focused technical forum for engineers seeking to enhance the quality and maintainability of their UVM environments through structured linting , metrics analysis , and practical methodology insights . 📍 Event Details Date: Friday, 18th July 2025 Time: 14:00 – 16:00 BST Venue: Oxford House, 12–20 Oxford Street, Newbury, Berkshire, RG14 1JB Meeting Room: Donnington Register at:   https://forms.gle/VCiVEiKgzKJgPiAD8  Remote Access:   Join the meeting now: https://teams.microsoft.com/l/meetup-join/19%3ameeting_OGNiY2RjYzEtNGI0OC00MDg3LTk2OGYtZGZiZWMzNTQyMGQ1%40thread.v2/0?context=%7b%22Tid%22%3a%22ce8c6d03-7521-4120-aa04-...

Got SystemVerilog Testbench Code with UVM, SVA ? Let’s Lint It – For Free!

We're inviting all SystemVerilog developers to share their testbench code using #UVM and/or #SVA for a free lint-check as part of our upcoming technical meetup. ✅ Submit your repo path or URL ✅ We’ll run our lint tools on it ✅ Get a detailed report ✅ Your code might be featured in a live demo! 🗓️ Event: #UVMLint and #SVALint Meetup 📍 Location: Cambridge, UK (remote attendance available) 👥 113+ engineers already registered , and counting! Don’t miss the chance to get valuable insights into your testbench quality — from syntax to assertions to methodology compliance. Register now: https://lnkd.in/dW3nX_KC Join via:  UVMLint meetup - Cambridge, June 27 | Meeting-Join | Microsoft Teams   Special thanks to our collaborators: Ajeetha Kumari, Ben Cohen, Hemamalini Sundaram and the #AsFigo team. #SystemVerilog #UVM #SVA #Lint #EDA #Verification #OpenSource #Meetup

Join Us in Cambridge - Advancing Chip Verification with UVMLint & SVALint

AsFigo invites you to our next technical session, focused on enabling semiconductor design teams to adopt open-source EDA tools—especially for testbench linting workflows. Remote-dial-in link:  UVMLint meetup - Cambridge, June 27 | Meeting-Join | Microsoft Teams 📍 Event: UVMLint & SVALint – Enablers to Move Your Chip Design Ahead 📅 Date: Friday, June 27, 2025 🕙 Time: 10:00 AM to 12:00 Noon (UK Time) 📌 Location: Wellington House, East Road, Cambridge, CB1 1BH, United Kingdom ☎ Phone: +44 1223 451000 🌐 Format: Hybrid (in-person & remote via Microsoft Teams) 💡 Cost: Free (registration required - https://forms.gle/upzLGyWJbRnbgRzU7 ) After a successful SVALint session in Reading, UK, we’re bringing this discussion to Cambridge—one of the UK’s most active semiconductor hubs. This event is geared toward engineers working in UVM based verification, formal verification, and testbench architecture using UVM and SVA. Ag...

UVMLint user group at Chennai - Widened scope to OpenPOWER

Open Source Chip Design & Verification Event – Chennai 2025 Open Source Chip Design & Verification Event – Chennai 2025 The open-source hardware movement is shaping the future of semiconductor innovation, and you’re invited to be part of it! Join us at the Open Source Chip Design and Verification Event – Chennai 2025 , where experts in the field will share insights on open silicon, FPGA development, and SystemVerilog tooling. 📅 Date: April 5th, 2025 ⏰ Time: 3:00 PM – 5:00 PM 📍 Venue: Object Automation System Solutions Inc., Chennai Speakers Srinivasan Venkataramanan (AsFigo, UK)  – svck: A Lightweight and Extensible SystemVerilog Linter Kirupanithi RP (Object Automation) – Building Custom Chips with OpenPOWER Hemamalini Sundaram (VerifWorks) – UVMLint - case studies VP Sampath Ram (Bharath Semiconductor Society) – FPG...

Building an Open Source Lint Tool for UVM IEEE 1800.2 Core BCL

Image
We are excited to share our journey of developing an open-source lint tool for the Universal Verification Methodology (UVM) IEEE 1800.2 Core Base Class Library (BCL) At AsFigo, our aim is to enhance the UVM ecosystem by providing a robust, community-driven solution that ensures code quality and compliance with industry best practices. Our team will be presenting results from this activity at the upcoming ORConf 2024 in Gothenburg, Sweden this September!  Understanding the Need UVM IEEE 1800.2 is a standard that provides a comprehensive verification framework for SystemVerilog, facilitating the creation of reusable and scalable testbenches. However, ensuring that UVM code adheres to best practices and standards can be challenging. This is where a lint tool becomes handy, offering automated code analysis to detect potential issues early in the development cycle. Given the vast language that SystemVerilog is, a single lint tool does not truly fit all needs. In the ...

Customizing UVMLint for IEEE 1800.2 Base Class Library

Image
Universal Verification Methodology (UVM) stands as the pinnacle of design verification methodologies in the ASIC and FPGA domain. The integration of linting and static code analysis has emerged as a vital practice, particularly in projects with broad user bases, extended lifetimes, and distributed development teams. Recently, during the UVM IEEE 1800.2-2023 release cycle (at DVCon US 2024), the potential for a custom UVMLint solution to enhance the UVM Base Class Library (BCL) development process was recognized. Some of the lead developers of UVM BCL suggested to create a simple rule deck that focuses on specific issues seen by the core development team over last few years than a general-purpose linter that may end up throwing 1000s of violations.   At AsFigo, we've taken the initiative to develop custom linting rules tailored specifically for the UVM BCL. Our goal is to offer our community an open-source lint package that can be used by the UVM IEEE committee and the wider devel...

UVMLint - why not to "re-declare" is_active inside agent?

Image
 Building on PySlint, UVMLint is adding rules for UVM based testbenches. A recent user reported the following violation: That's just a short reporting, with detailed message to follow (users can add more information at their end with PySlint API soon). Let's understand why this is considered a bad practice in UVM.  To speed things up (and to add spice to it), we used Google Bard on "what is is_active in UVM agent" and below is a response:  The is_active variable in a UVM agent is an enum type of uvm_active_passive_enum . It specifies whether the agent is active or passive. An active agent has a driver and sequencer, while a passive agent only has a monitor. The is_active variable is a useful tool for controlling the behavior of UVM agents. By setting the is_active variable, you can control whether an agent has a driver and sequencer, or whether it only has a monitor. Not bad for a GenerativeAI conversation, isn't? As a quick recap, UVM agent is a specialized c...