WP_Term Object
(
    [term_id] => 42
    [name] => AMIQ EDA
    [slug] => amiq-eda
    [term_group] => 0
    [term_taxonomy_id] => 42
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 24
    [filter] => raw
    [cat_ID] => 42
    [category_count] => 24
    [category_description] => 
    [cat_name] => AMIQ EDA
    [category_nicename] => amiq-eda
    [category_parent] => 157
)
            
AMIQ Banner
WP_Term Object
(
    [term_id] => 42
    [name] => AMIQ EDA
    [slug] => amiq-eda
    [term_group] => 0
    [term_taxonomy_id] => 42
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 24
    [filter] => raw
    [cat_ID] => 42
    [category_count] => 24
    [category_description] => 
    [cat_name] => AMIQ EDA
    [category_nicename] => amiq-eda
    [category_parent] => 157
)

Continuous Integration of RISC-V Testbenches

Continuous Integration of RISC-V Testbenches
by Daniel Nenni on 12-02-2021 at 6:00 am

In my last blog post about AMIQ EDA, I talked with CEO and co-founder Cristian Amitroaie about their support for continuous integration (CI). We discussed in some detail how their Design and Verification Tools (DVT) Eclipse Integrated Development Environment (IDE) and Verissimo SystemVerilog Linter are used in CI flows. Cristian gave a fascinating example: AMIQ EDA runs CI lint checks every few hours on the contents of the Github repository for the Universal Verification Methodology (UVM) reference implementation, and makes the results publicly available. Any time that anyone contributing to this project checks in new or changed code, it will be linted quickly. This helps to improve the quality of the code, and publishing the reports fits the whole open-source ethos.

Cristian concluded by hinting that this same process could be applied to other SystemVerilog/UVM design and verification IP available from public repositories. Last week we found out what he meant, in a new press release announcing that they have set up a CI flow for the open-source UVM RISC-V verification environment from OpenHW Group. The members of the group are using the AMIQ EDA tool results to enhance the quality, portability, and readability of their code. I asked Cristian to tell me more and, when we talked, he was kind enough to bring along Mike Thompson, the OpenHW Group Director of Engineering, Verification Task Group and Gabriel Raducan, R&D Team Lead at AMIQ EDA. Here are the highlights of our conversation.

Thanks for joining me today. Can you please start by telling me about OpenHW Group?

Mike: I expect that your readers know about RISC-V, the widely adopted free and open instruction set architecture (ISA). Many companies, organizations, and academic institutions have developed processor cores, verification tools, and many kinds of supporting software for this ISA. Of course, there is widely varying quality across these offerings. We formed OpenHW Group to develop very robust and flexible RISC-V open-source cores and best-in-class open-source verification testbench environments.

Cristian: We’re seeing increasing interest in RISC-V among our users. It’s clearly a hot topic in the industry.

So where does AMIQ EDA come into the picture?

Mike:  As individual members of the OpenHW Group use their own simulators to develop testbenches, it is important to have readable and maintainable SystemVerilog/UVM code that can run on any commercial simulator. We looked for a lint tool that could play the central role in this effort, but there are few, if any, open-source or commercial linters that support testbench code, particularly SystemVerilog/UVM. I looked at the available options and tried Verissimo because I heard good things about it.

Cristian: Mike contacted us, and we collaborated to set up an environment to check the OpenHW testbench code with our tool and then deploy it.

What does that mean? What specifically did you do?

Gabriel: There were really four parts to the project. The first was us doing some initial linting runs on the testbench and discussing the results with Mike and members of his team.

Mike: Next, Gabriel explained that the rules to be checked by Verissimo are highly customizable and he proposed an initial set. We worked together to refine this set to fit our verification goals. If we didn’t deem a particular rule important, it was easy to waive or suppress the check.

Gabriel: The third phase was setting up the CI flow that we mentioned in the press release. Any time that anyone in the Verification Task Group checks in code, it is linted within a few hours and the results are posted openly in a dashboard format. These regression runs ensure that everyone’s contributions meet the OpenHW coding guidelines and quality metrics. Finally, we added the rule and waiver files to the OpenHW repository so that they are accessible to the team.

RISC-V Results

Isn’t this a whole lot like the UVM CI flow we talked about last time?

Cristian: It’s really very similar; in both cases we run regular lint regressions on an open-source repository. Engineers working on open-source projects invest a lot of time and energy, and we are happy if we can help. We see this as an ongoing collaborative process from which both parties benefit. In fact, we constantly monitor OpenHW discussions on Github to help with linting topics and interact with more team members.

Have you found any issues with the RISC-V testbench code in this process?

Mike: Yes, we have fixed many dozens of issues reported by Verissimo. Some were violations of our SystemVerilog/UVM coding guidelines that we previously had no automated way to detect, and some were due to rules we had not considered before. I especially like the rules that warn us about constructs that may work inconsistently on different simulators or that are not even supported on all simulators. It is important for our code to be vendor-neutral and portable.

Could you give some examples of these issues?

Gabriel: Sure! SystemVerilog prohibits using a null class in a logical expression. Some simulators allow this, but we report it as non-standard code. UVM specifies that the Verilog “$random” call should be avoided, but we found a few usages in some older testbench code. We also detected some cases of overrides that didn’t actually make any changes to the base classes, which is a waste of simulation time and resources.

How has the experience been working together?

Mike: AMIQ EDA has been a wonderful partner. They’ve been proactive, responsive, and fully supportive of our project goals.

Cristian: The same is true of Mike and the OpenHW folks. Like our other advanced users, their feedback is extremely valuable in improving our products and adding useful new features.

Where do you go from here?

Mike: I think that Verissimo is now an indispensable part of our RISC-V testbench development efforts. We are using GitHub issues to track lint violations flagged by Verissimo so that individual members can address the issues found in their sections of code. This will be an on-going process. Even with only a few months of experience so far, I can’t imagine not having Verissimo in our flow.

Thank you both very much for your time.

Cristian and Gabriel: Thank you, Dan, and thank you, Mike, for making time to join us today.

Mike: Thanks to the three of you as well; it’s been a pleasure!

Also Read

Continuous Integration of UVM Testbenches

What’s New with UVM and UVM Checking?

Why Would Anyone Perform Non-Standard Language Checks?

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.