AsFigo - enabling opensource chip design and verification.

Race conditions are one of the dreaded aspects of Verilog/SystemVerilog. Race conditions in SystemVerilog  lead to unpredictable behavior due to competing threads or processes accessing shared resources without proper synchronization. Debugging race conditions is challenging due to their non-deterministic nature, which means issues may appear sporadically and be hard to reproduce, complicating the identification and resolution of the underlying problem. It gets compounded by the fact that different EDA tools can behave differently on your code (with race condition) and yet be 100% LRM compliant (meaning no one will fix it for you).  Would you believe that up until recently, UVM Base Class Library (BCL) had potential race conditions deep inside? Hard to believe? See for yourself a report from IEEE 1800.2 UVM core team members:  08376: 'static const xx ' class members with initialization - Accellera Mantis (mantishub.io) Understanding Race Conditions in UVM: Why S...

Our Director of Verification, Ajeetha Kumari took part in offering her review comments based on her decades of AMS design verification experience to Accellera's UVM-MS standard.  Overall, our focus is on  clarity, correctness, good coding practices, and ensuring UVM-MS follows standard verification methodologies .    Clarifications and Expansions Suggested explicitly stating IEEE 1800.2 UVM version to avoid ambiguity. Asked whether VHDL should also be considered in addition to SystemVerilog. Recommended good coding guidelines for UVM-MS lint rules . Pointed out grammatical issues , such as removing unnecessary "s" in certain words. Suggested formatting improvements, such as italicizing specific terms . Code and Implementation Improvements Recommended ensuring all UVM components/agents are in separate packages for better reuse. Questioned the lack of UVM factory registration for some proxy classes. Suggested adding function prototypes (like ne...

Introduction to MSIE Multi-Snapshot Incremental Elaboration (MSIE, Copyright Cadence Design Systems) is a powerful feature of Cadence Xcelium that optimizes the verification process for digital designs by enabling incremental changes to be elaborated without needing to re-elaborate the entire design. This approach significantly reduces the time required for compiling and elaborating designs, making verification faster and more efficient. Typical simulation flow (without MSIE)  The below figure depicts a traditional approach to running test scenarios in a design and verification environment.   Each scenario involves three stages:  Compilation of the environment (testbench + DUT),  Elaboration of the compiled environment,  and Simulation of the elaborated environment.  This sequential process is repeated for each test scenario. How MSIE Works Primary and Incremental Snapshots: MSIE works by creating pre-elaborated snapshots of the d...

In VHDL-based digital design, ensuring that every key aspect of your design is tested comprehensively is critical. Functional coverage plays a pivotal role in this process by quantifying how thoroughly the testbench exercises the design's functionality. In this article, we will demonstrate how to create a functional coverage model for a simple up/down counter ( af_up_dn_counter ) using BenchBot, a Python tool for generating templated testbenches, in conjunction with OSVVM (Open Source VHDL Verification Methodology), which provides a robust functional coverage package. Setting Up the Testbench with BenchBot BenchBot, a Python app simplifies the creation of VHDL testbenches by generating template files.  It serves as a starting point rather than a fully functional testbench with all tests. However, it goes way beyond basic testbench by creating functional coverage model for all relevant DUT ports.  We will show an example of this below. Overview of the Design The design ...

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

IEEE 1647 - e Language (Specman) & MathLib We at AsFigo have deep expertise in multitude of design verification and modeling techniques including IEEE 1647 e language. Our core team has contributed to development of the IEEE standard, presented at various industry events on Specman such as DAC. Fast forward to 2024 - we were approached by a customer to make their reference models run with native E. Erstwhile their reference models were DSP algorithms modeled in Matlab. While E language does provide similar functions, they are not always 100% compatible especially around negative values, corner cases, rounding limits etc. thereby leading to customers retaining Matlab + Specman in their flows. Based on AsFigo's MathLib success with SystemVerilog & VHDL (A brief report of that below), we did a porting of MathLib basic features to IEEE 1647 e. We will be thrilled to opensource a basic version of this implementation shortly, so watch out our GitHub repositories! Meanwhile ...

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