Issue 21: Using Revision Control Systems with the Visual Verification Suite

Continuous Integration and Continuous Deployment (CI/CD) used in the development of FPGA, ASIC and Intellectual Property cores is a process of build automation and RTL code testing each time the development team makes changes under version control. The practice is focused on improving hardware quality throughout the development life cycle via automation.

During the CI/CD process, developers share and merge their changes (code and unit tests) into a version control repository. Adopting a continuous integration approach is one of the most beneficial and low-cost practices individuals as well as teams can implement in terms of improved quality and efficiency.

Some of the advantages of adopting CI/CD tools include:

  1. Continuous feedback – Fault isolation so that when an error occurs, the negative consequences are limited in scope
  2. Reduced friction – Prevention of merge conflicts such as bugs and duplicate code, making for cleaner code and fewer issues later in the design cycle
  3. Higher speed / faster release rate – Accelerated code reviews and decreased development time by automating time consuming tasks
  4. Lower cost with easier maintenance and updates – With a CI/CD approach, developers can make sure that the product is updated and maintained at frequent intervals

In the development of FPGA, ASIC and Intellectual Property cores, projects may involve multiple team members with distributed responsibilities, such as sub-module design, device and system integration, verification, and timing closure. In such cases, it is useful to track and protect file revisions in an external revision control system.

Jenkins is an open-source, free CI/CD server written in Java. It works with multiple programming languages and can run on various platforms (Windows, Linux, and macOS). As such, Jenkins is one of the most popular open-source tools on the market for automating projects. The Visual Verification Suite has been designed to work with any version control system such as Bamboo, Buddy, TeamCity, GitLab, Jenkins and others. However, for this example we will take a closer look at Jenkins integration.

To recreate an analysis run initiated using the GUI, Blue Pearl recommends that the following files, written by the Visual Verification Suite GUI into the Results directory, are stored in the revision control system along with the RTL project source files:

  • bluepearl.runme.tcl
  • Project_Name.settings.tcl
  • Project_Name.bluepearlgenerated.f

Then run, in command line mode:
>BluePearlCLI -f Project_Name.bluepearlgenerated.f

The Visual Verification Suite will restore the project using the settings stored in the Project_Name.settings.tcl file. Please note that the two files that start with Project_Name are generated with explicit path references that may need to be edited. Relative path references are allowed.

After the analysis has been run, the bluepearl.runme.tcl script has a call to “exit” the Tcl shell. Users can edit this out if they wish to continue interactively with analysis and debug after restoring the project.

The tool creates the following databases required for analysis in the Visual Verification Suite:

  • bluepearl.bpsvdb – the Blue Pearl visual data base
  • modinfo.db – the database for the design
  • results.db – the database with the static analysis results

In addition, because the suite can be configured to run different features, we recommend having different directories for different options. For example, if the Analysis is configured for Long Path Analysis only in the Project_Name. bluepearlgenerated.f file, modify the output directory to have the name: Results_LP. Likewise, for just a CDC run, rename the directory to be: Results_CDC.

In addition, the waivers.xml file is a database of sorts. It contains all the waivers and their timestamp/owner combinations. This file may be source code controlled because it can be manually and graphically edited, thus changing results reported by the tool. It is also possible to use multiple waivers files simultaneously, so that different groups or designers can keep separate waivers files that can be configured to work both on submodules and the entire design.

When running a revision control system like Jenkins, it is possible to set it up to automatically run the Visual Verification Suite as a mandatory step prior to making source RTL changes. This will prevent structural RTL errors from entering the Simulation scripts. Additionally, it is also possible to set up to run prior to simulation. If no new messages are found, then simulation is called.

Blue Pearl has worked with Jenkins to be supported in the Jenkins Next Generation Warnings plugin where the tool performs a textual analysis of the log file, summarizing the number of warnings and errors. In addition, the Visual Verification Suite ships a Jenkins plugin called “RunBluePearl” that is used to integrate any specific version of Jenkins.

The “RunBluePearl” plugin allows the BluePearlCLI to be added as a build step in a Jenkins flow. In addition to design setup, global settings include licenses and installation, while the tool is configured to report all errors and warnings (not just the usual limited number of messages), to allow textual analysis of the log file.

Incorporating a CI/CT tool in the development of FPGAs, ASICs and Intellectual Property cores is a must-have element of the development process. When choosing a tool, make sure to pick the one that best fits your project and business requirements, and don’t worry, the Visual Verification Suite is designed to work with it, speeding and simplifying the development and verification processes at the same time.

To learn more about the Visual Verification suite or to discuss how you can integrate it inside your revision control system, please request a demonstration.