AsFigo - enabling opensource chip design and verification.

BenchBot: Automating OSVVM-based VHDL Testbenches BenchBot is a Python-based automation tool designed to generate testbench templates based on OSVVM (Open Source VHDL Verification Methodology) for VHDL testbenches. This tool is particularly useful in hardware verification for FPGA and ASIC designs. Below is a technical breakdown of BenchBot. Core Functionality At its core, BenchBot processes a YAML file containing DUT (Device Under Test) specifications, automating the creation of VHDL testbench components. This includes not only the entity and architecture for the testbench but also the DUT’s port declarations and integration within the generated testbench. Key Features Testbench Generation : Automatically creates a complete testbench structure, including both the entity and architecture necessary for simulation. DUT Integration : Parses DUT ports from the input YAML and generates corresponding port declarations, followed by ac...

OSDA is the premier European forum for open-source design automation. In 2024, this was co-hosted along with Design Automation & Test in Europe (DATE-24), the equivalent of USA's DAC.  Being held in the beautiful city of Valencia, Spain, AsFigo presented an insightful poster on "Adding Configurability to PySlint using TOML". This poster delved into the technical details and practical implications of integrating TOML (Tom's Obvious Minimal Language) into PySlint, a burgeoning SystemVerilog linter based on the open-source PySlang parser. The Need for Configurability in Linters Linting tools play a crucial role in maintaining code quality by enforcing coding standards and detecting potential issues early in the development process. SystemVerilog, a widely used language in ASIC and FPGA designs, often presents multiple ways to achieve the same functionality, making the role of linters even more ...

 YAML, which stands for "YAML Ain't Markup Language," is a human-readable data serialization standard that is ideal for configuration files. We at AsFigo are helping customers adopt YAML for documenting VHDL (VHSIC Hardware Description Language) designs, especially at the interface level. One of the primary benefits of using YAML for VHDL designs is that it makes the information easier to parse and modify. This structured format allows for straightforward code generation and updates, significantly improving workflow efficiency. With YAML, you can create an organized, easy-to-read representation of VHDL entity interfaces, detailing ports, libraries, and other configurations. This structured approach not only aids developers in understanding and managing complex designs but also facilitates tool integration.   Below is a simple example YAML for a trivial up-down counter: Take a look at our opensource OSVVM Testbench generator project that utilizes this idea at: https://gith...

VHDL holds a prominent position in the world of FPGA design, particularly within the military, aerospace, and defense sectors. It serves both as a Register Transfer Level (RTL) design language and as a tool for creating testbenches. The availability of open-source simulators, such as GHDL and NVC, alongside numerous free FPGA simulators and synthesis tools, has provided FPGA designers with a significant advantage over their SystemVerilog counterparts. While the Universal Verification Methodology (UVM) is widely adopted among SystemVerilog users, VHDL practitioners have traditionally relied on various homegrown methodologies and frameworks. Recently, however, off-the-shelf methodologies and frameworks such as OSVVM, UVVM, and VUnit have become available to VHDL users. Each of these options presents different levels of complexity, allowing users to choose the one that best meets their needs. Despite these advancements, the development of open-source utility tools supporting the latest me...

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

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