Posts

WOSET 2024: Spotlight on yoYoLint - An Open-Source SystemVerilog RTL Linter

Image
As open-source electronic design automation (EDA) tools continue to grow in popularity, events like WOSET (Workshop on Open-Source EDA Technology) have become essential for showcasing community-driven advancements. The 2024 edition of WOSET features an exciting lineup, including yoYoLint—a new open-source SystemVerilog RTL linter designed for Yosys. Built on AsFigo’s innovative "Build Your Own Linter" (BYOL) model, yoYoLint adds a much-needed layer of quality control to open-source HDL flows, addressing the often-overlooked process of HDL linting. Understanding the Role of HDL Linting in EDA Linting is a critical phase in hardware description language (HDL) design flows, helping enforce design rules, style guides, and best practices to ensure code quality. A robust HDL linter for SystemVerilog helps identify errors early, such as unused variables, unsupported constructs, potential race conditions, or missing sensitivity list items, enabling teams to produce clean, consist

BYOL - a custom linter for Yosys; yoYoLint

yoYoLint is an opensource linter being developed to check SystemVerilog (SV) RTL code for compatibility with the Yosys open-source synthesis tool. Yosys, a popular, opensource  hardware description language (HDL) synthesis tool, has limited SystemVerilog support and often produces cryptic errors for unsupported constructs. As Yosys does not provide a comprehensive list of unsupported features, yoYoLint becomes essential in preemptively catching these issues before synthesis. Unlike off-the-shelf EDA tools, yoYoLint follows the BYOL (Build Your Own Linter) model, a concept proposed by AsFigo . This allows developers to customize and adapt the tool to their specific design needs and Yosys synthesis environment. Key Features Yosys-Specific Checks: yoYoLint flags unsupported SystemVerilog features, such as complex data types, advanced procedural blocks, and unsupported constructs in Yosys. RTL-Focused: Analyze

Bridging the Gap: When Formal Verification Catches What Simulation Misses

Image
In the intricate world of semiconductor design verification, the interplay between formal verification and simulation-based approaches continues to evolve. A recent case study highlights the complementary nature of these methodologies and underscores the importance of a comprehensive verification strategy. The Scenario During a routine IP verification using formal tools and SystemVerilog Assertions (SVA), a bug was uncovered that had previously eluded detection in subsystem-level simulation. This discovery prompted a deeper investigation into the verification process and the tools employed. Formal Verification's Unique Strength Formal verification's ability to exhaustively explore state spaces within specified bounds allowed it to uncover a corner case that simulation had missed. This strength stems from formal tools' capacity to: Examine all possible states and input combinations Operate without the need for specific test vectors Explore deep states that might be

Meet the team behind SystemVerilog Assertions Handbook

Image
The SystemVerilog Assertions Handbook The SystemVerilog Assertions Handbook is a popular publication in the field of hardware design and verification. Authored by Ben Cohen, Ajeetha Kumari, Srinivasan Venkataramanan, and Lisa Piper, it became the world’s first book solely dedicated to SystemVerilog Assertions (SVA) when it was first published in 2005. At a time when SystemVerilog was gaining widespread acceptance, the authors recognized the need for a focused resource that could demystify assertions and provide engineers with practical insights into their use in modern verification flows. Now in its fourth edition, the handbook has evolved in tandem with advancements in the SVA standard, making it an indispensable reference for both beginners and experienced verification engineers. What sets this book apart is its combination of theory and practical examples, offering real-world insights into the effective use of SVA for improving design verification quality.

VHDL testbenches made simple - BenchBot

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

Waves2UVM - an opensource bridge between Formal & UVM

Image
Waves2UVM is an app within the Go2UVM ecosystem that aids in the automatic generation of UVM testbenches from waveform data. This is especially valuable for engineers aiming to accelerate the design verification process of complex hardware systems. The tool works by translating waveform dumps (which capture signal behavior during simulations) into UVM verification components, thereby eliminating the manual coding typically required for testbench creation. The key advantage of Waves2UVM is its ability to work with formats like WaveDrom , offering a streamlined path from a structured, waveform data to a functional UVM testbench, which can be utilized within broader UVM verification flows. This improves productivity in hardware verification by reducing errors introduced during manual coding and speeding up the overall verification cycle. A recent customer usage of this handy technique deals with reproducing Formal Verification traces in simulation world. As Formal Verification tools such

Value of UVMLint - an anecdote from Race Conditions in UVM BCL code

Image
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 Switching fr