Stage: Production
Python has been used for functional verification for quite some time. When I began using Python, one thing I missed from SystemVerilog was access to SystemVerilog-style constraints and functional coverage. PyVSC provides a Python library that supports constrained randomization and functional coverage collection.
Stage: Production
Once collected, functional coverage data must be stored in an accessible manner to support analysis. Accellera UCIS defines an API for storing and retrieving coverage data, as well as an XML interchange format. PyUCIS is an object-oriented Python API on top of the UCIS API that can be used to store and access coverage data. Supported back-end implementations include commercial tool implementations of the UCIS API, the XML interchange format, and an in-memory representation.
Stage: Beta
Interactive graphical applications make getting an intuitive sense of coverage data simpler. PyUCIS Viewer is a Python application that uses the QT library to render coverage data.
Stage: Development
The PyVSC library uses the Boolector SMT solver to implement SAT solving. Additional algorithms are needed to implement iterative constraint (eg foreach) expansion, constraint partitioning, and uniform randomization. While Python is great as a front-end interface for the user, it doesn’t excel at high-performance computation.
libvsc is a new C++ implementation of the core data model, coverage collection, and randomization algorithms. Early measurements indicate that libvsc is roughly twice as fast as PyVSC.
Software-driven verification, and the techniques surrounding it, have been a continuing interest of mine. The projects below help to make software-driven verification simpler and more productive.
Stage: Alpha/Archived
The goal of bare-metal software is to have maximum control of the hardware. Bare-metal software still benefits from light-weight infrastructure and services that help to make test writing more productive. The Bare-Metal Kernel implements multi-core bring-up and threaded execution environment. Synchronization primitives are provided that support synchronization across hardware threads and cooperatively-scheduled software threads.
The BMK project worked for the use cases it was intended to support. However, going forward, I’ve decided to invest in supporting these use cases using the Zephyr RTOS kernel.
Stage: Alpha
A key challenge in SoC integration testing is obtaining and integrating driver firmware for use by the integration tests. The Zephyr-Cosim project helps to address these challenges by making it easy to develop driver firmware in the context of an IP-level verification environment. Because the driver firmware is developed using the Zephyr RTOS driver framework, it integrates easily with driver firmware for other IPs in the SoC environment.
Stage: Planning
The Zephyr RTOS implementation is tuned for running embedded application software on resource-constrained hardware platforms. Test software has similar requirements, but there are also differences. These patches are intended to better-support software-driven verification in simulation and hardware-assisted execution environments.
Stage: Development
The Zephyr RTOS uses the DeviceTree Specification to configure the software image. However, the description captured in the .dts file can be used in other ways as well. The DTS Tools project allows users to extract data from a DeviceTree Specification and use it to generate artifacts used in the verification environment, documentation, etc.
Stage: Development
Design verification in simulation is typically performed on a Verilog, VHDL, or SystemC representation. Connecting to outside code – testbench, reference model, checkers, etc – is a key aspect of a verification environment. Unfortunately, the integration APIs provided by various simulation environments are different, and have different capabilities. Furthermore, some of the code being integrated may support running in a thread, but might also require running as a separate process.
The goal of TbLink-RPC is to implement a simulation-aware integration API and code generation tools that simplify the process of connecting a new testbench/checker/etc to a simulation-based or hardware-assisted verification environment.
Design and Verification IP comes from many sources. While it would be nice to think of reusable IP as being ‘complete’ and ‘read-only’, in practice I often find myself co-developing projects. IVPM manages fetching project dependencies from a variety of sources (but with a focus on Git repositories) and creating a project-local set of package dependencies.
Stage: Beta / Internal Production
Stage: Development / Internal Production
The Featherweight-IP Library contains the open-source IP library I use when assembling SoCs. I’ve designed some of the IPs, such as the FWRisc RISC-V core that won 2nd place in the RISC-V Soft CPU Design Contest and various infrastructure components such as interconnects and system controllers. Other IP blocks leverage existing open-source IPs. The README for any IP that leverages a pre-existing block clearly states the origin of the foundational IP block.
Stage: Complete (Dec 2020)
Taping out a chip has been a long-term dream of mine, and one that seemed unlikely to be realized given the difficulty and expense of doing so. A few developments in the industry brought this dream within reach. First, the OpenROAD Project assembled an RTL-to-GDS flow using open-source tools. Next, Google partnered with SkyWater Technology to release the CMOS 130nm PDK as open source, and partnered with eFabless to run a series of multi-project wafer (MPW) tape-outs for open-source designs to validate the flow.
I participated in the first tapeout with a very simple SoC design. The design and testbench environment are shown below.
Learning about the tools and key considerations across the entire process was extremely educational – and, a learning project that I would have been unlikely to undertake as a personal project in the absence of an open-source toolflow.
Stage: Production / Archived
In 2008, when I started learning SystemVerilog, I had spent several years writing software using the Eclipse integrated development environment. My experience was that the language-support features Eclipse provided for Java and C/C++ made me significantly more productive vs using a plain-text editor like Emacs or Vi, and I found myself missing that when writing SystemVerilog.
SVEditor indexes a user-specified list of Verilog and SystemVerilog files, and uses the extracted symbols to support navigation across the codebase, context-specific content assist, and to automate creation of code.
SVEditor is no longer being actively developed, but I continue to use it almost any time I write Verilog and SystemVerilog code.