AsFigo - enabling opensource chip design and verification.

Back in 2023, we started building open-source lint tools for the parts of SystemVerilog that commercial linters tend to treat as an afterthought — assertions, constraint blocks, and functional coverage. What began as a handful of rules has grown into a substantial rule set: SVALint , CNSTLint , and FCOVLint now collectively cover over 90 lint rules, all built on the Verible parser and the BYOL (Build Your Own Linter) framework. This post highlights the rules that catch real bugs, silent misbehaviour, and tool-specific pitfalls — not naming conventions. Full rationale, violation examples, and correct usage are in the linked docs. SVALint — Assertion Linting (52 rules) Repo: github.com/AsFigo/svalint  |  Docs: asfigo.github.io/svalint/ SVA is deceptively easy to write incorrectly. These rules catch issues that compile cleanly, pass elaboration, and then silently misbehave in simulation or formal verification. Rule ID Bug it catches DELAY_BEFORE_ROSE D...

Why Regex Is the Wrong Abstraction for SystemVerilog Coverage Linting When building a lint rule for SystemVerilog functional coverage, it is tempting to start with a regular expression. The problem can initially appear simple: find array-based coverpoint bins, calculate how many bins they expand into, and report a violation if the count exceeds the supported limit. A first implementation might read the source file, remove comments, and search for patterns such as bins foo[] = {[0:2048]}; . As a first-cut implementation, this is perfectly reasonable. It is small, easy to prototype, and useful for validating the basic rule logic. The problem is that regular expressions operate on source text , while a lint rule needs to reason about language structure . Consider: bins values[] = { [0:2048], [3000:4000] }; The rule now needs to understand that this is one array-bin declaration containing multiple ranges, and calculate the expansion represented by those ranges. A re...

Is your DPI-enabled SystemVerilog simulation running slow? Are you looking for ways to improve performance? Sometimes, a small remodelling of your DPI functions and using pure functions can help significantly. The Direct Programming Interface (DPI) allows SystemVerilog to interact with C code. Among the DPI constructs, pure functions are special because they are side-effect free and predictable. Using them correctly can improve simulation speed and reliability. However, SystemVerilog LRM imposes several subtle restrictions on imported pure  functions. Let's delve into one such nuance today a bit deeper! Referential Transparency Referential transparency is a concept from programming. An expression is referentially transparent if it can always be replaced by its value without changing the behaviour of the program. For example: The expression 2 + 3 can always be replaced with 5 . The expression rand() cannot, since each call may give a different result. In SystemVer...

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

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

Writing clean, maintainable, and consistent SystemVerilog testbench code is crucial for efficient verification. While functional correctness is the ultimate goal, enforcing coding styles helps improve readability, collaboration, and long-term maintainability. A well-structured codebase also reduces debugging time and ensures better reuse across projects. The Need for Linting and Style Enforcement Linting tools help enforce best practices by catching stylistic and structural violations early. Some fundamental style checks for SystemVerilog testbenches include: Encapsulation : Ensure proper use of class , local , protected , and virtual keywords to promote modularity. Line Length : Keep lines within a readable limit (e.g., 100 characters) to improve readability. Avoid Global Variables : Minimize or eliminate the use of global variables to prevent unintended side effects. Consistent Indentation and Naming : Follow a uniform inde...