AsFigo - enabling opensource chip design and verification.

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

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

 SystemVerilog is a vast language with long history. With any history, you have the problem of legacy - sometimes bad too, unfortunately. One such bad legacy is the use of "DPI" as spec-string in SystemVerilog Direct Programming Interface (DPI) code, used to interface C with SystemVerilog. It is a very commonly used feature in certain classes of systems as it allows reuse of reference models as-is in Design Verification. Jumping straight into a potential compatibility issue with DPI, historically Accellera SV (3.1a) allowed the following code: import "DPI" function int c_sum (int f1, f2);     However, as LRM matured and became an IEEE 1800 version, the above got refined to be "DPI-C". This is often referred to as "spec-string". Now, what's the big deal - one may ask, well below is a quote from IEEE 1800 LRM: So, if your old SV code was using "DPI" as spec-string, potentially: You have confusing 2-state, 4-state value passing across ...

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

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

As we prepare for Verification Futures 2023 , Austin event, an enthusiastic user ran PySlint on a small SPI VIP and found the following violation (among others). As expected, first reaction from the user was - what's the big deal? Below is our attempt in rationalizing why this rule is important especially for VIP developers and users.  A quick recap - The extern keyword in SystemVerilog is an optional qualifier to class methods. As in C++, Java and other languages, this is a highly recommended coding style, some benefits include: Improves readability - By declaring the method prototype in one place and the implementation in another, it can be easier to "read" the code for end users (not only the original developers) - to quickly glance the list of APIs/methods without scrolling 1000s of lines of code (if the implementation is mixed with declaration).  To hide implementation details. If the method implementation is defined in a separate file, it can be hidden fr...

  Linting is a well-known, popular technique in large code development projects. Software engineers have been using Lint based rule checking to maintain high quality code adhering to a set of predefined coding guidelines. In hardware design field, Lint tools have been very popular in RTL design phase and designers use lint to ensure the design is synthesis friendly, DFT compliant etc.   Several popular coding guidelines have evolved over the last few decades such as Reuse Methodology Manual (RMM), Japan’s STARC standard etc. Often tools group a set of rules and create policies to ensure design code is RMM compliant etc. Verification on the other hand does not enjoy the same level of lint tools.   ensure that SystemVerilog is well established as the design verification language in semiconductor design flow. While rule checking (a la Linting) is well established for synthesizable code well over a decade, the verification counterpart lacked such technology in the past. With ...