Customizing UVMLint for IEEE 1800.2 Base Class Library

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 developer community via GitHub. Our aim is to establish these rules as gatekeepers through GitHub actions, ensuring that all future additions to the UVM BCL are free from common pitfalls.

Why custom lint?

Unlike typical UVMLint rules tailored for Verification IP (VIP) users, which focus on different requirements, our  custom UVMLint checker is specifically designed for the UVM BCL codebase. For instance, while a typical VIP rule might ensure agent reusability, such a rule is impractical for the UVM BCL, which serves as the foundation for a vast number of engineers globally.  

Sample UVMLint Rules:

- Avoid race conditions around "static const" (use localparam instead)

- Avoid one-liner conditional statements and code in loops

- Use endlabels for elements such as endclass, endfunction, endtask, etc.

- Flag non-virtual methods

Below snapshots highlight potential coding enhancement opportunities




Summary:

Above snapshots summarize the custom UVMLint result for BCL. The development of a custom UVMLint solution represents a significant step forward in enhancing the UVM BCL development process. By leveraging Python code and rigorous testing methodologies, we've tailored linting rules to suit the unique requirements of the UVM BCL codebase. As we present our UVMLint findings on the latest IEEE 1800.2-2023 codebase, we anticipate that these efforts will contribute to the ongoing refinement and improvement of UVM verification practices worldwide.

Comments

Post a Comment

Popular posts from this blog

Don't go "wild" with Associative arrays in SystemVerilog - PySlint it!

Image
 Hash tables, modeled via Associative arrays is a powerful data structure in SystemVerilog. Python calls it as "dictionary". One of the "wild" features of SystemVerilog is that it allows associative arrays to be declared with arbitrary key type. An example:           class wild_c;             string wild_hash_table [*];           endclass : wild_c While the above is a legal SystemVerilog code, may even be seen as "easier" to write, it is bad from a reuse perspective. Some of the side effects (mostly bad) are: Unclear data structure to begin with - for writer and then the reader/maintainer of the code.  As the key can be anything, SV does not allow wildcard indexed associative array to be iterated via foreach loop. It cannot be passed as function parameter. Many find*  methods do not work on wild-card indexed associative arrays. For instance, find_first would need to return a queue of the keys, and when used on wild-card indexed array, it would be a queue o
Read more

Porting a complete UVC to Verilator + UVM - an anecdote!

Image
 So, here we are on Day-1 of UVM + Verilator becoming available to the public, start of democratizing chip design verification. In case you just woke-up/started on this topic, read the release of UVM + Verilator with some intricate details on the challenge on the way by Antmicro via:  https://antmicro.com/blog/2023/10/running-simple-uvm-testbenches-in-verilator/  Awesome work by the folks at Antmicro and fantastic support by the ecosystem specifically Western Digital, kudos!  At AsFigo , we are committed to fueling open-source driven chip design and verification. So we took this opportunity to port a commercial-grade UVC (Universal Verification Component or a Verification IP) and ported it to compile and run on Verilator. Below are our reflections from this experiment. Get in touch with us to discuss how AsFigo can help your VIPs and testbenches to be ported to opensource EDA.  Case study: VLBus - a simple peripheral bus intended for write/read to configuration registers (like the pop
Read more

This single character can provide shift-left in your coverage closure cycle - SystemVerilog dist, PySlint

Image
In SystemVerilog based testbenches, functional coverage models and constraint models are like the yin and yang.  In a good testbench, coverage model should specify what-to-observe using coverpoints/bins/crosses. An accompanying transaction model would capture transaction attributes along with constraints on variables and their relationships. This is specifically applicable to the input/stimuli-based coverage models. As part of coverage closure cycle, verification engineers run the random generator multiple times and measure the progress using coverage metrics. At times this cycle takes far too long and one of the possible causes could be wrong coding/models to begin with. It can be too-wide a state-space modeled using coverage constructs or too tight a constraint model (over constrained). Using static analysis one can identify a set of issues in coverage model and/or constraint model. Let's take a  case study of a wrong constraint model as shown below: class data; rand bit [15:0]
Read more