Open-Source RISC-V Verification for the Nation

July 10, 2018

By Jeremy Ralph, Principal Verification Engineer

Many moons ago, as a new grad straight out of university, I started as an ASIC designer at a small startup where I took on the design, microcode, and verification of a custom VLIW microprocessor.  That was back in 2000, before there was much commercially available in terms of extensible soft processor cores and toolchains.

Fast forward to today, and there are many soft cores (ARM, ARC, MIPS, Tensilica, RISC-V, Altera NIOS II, Xilinx MicroBlaze…) and entire ecosystems at the disposal of SoC designers.  Were this available back in 2000, I bet I’d have been working with a RISC-V core instead.

That custom VLIW core back in 2000 was the last time I verified a processor.  Since then I’ve focused on verifying the custom logic blocks in the SoC and the full chip testing – using the ARM core as trusted and verified.

Verification techniques have changed a lot since then, too.  In 2000, random-constrained, coverage-driven verification wasn’t yet proliferated, and Specman was just in its early days.  Since then, I’ve learned a lot about verification at all levels from block to full SoC.

In early 2018, when I started working at XtremeEDA, a RISC-V Foundation member, the company was interested in increasing focus into the RISC-V realm so I started reading the RISC-V ISA spec.  I had my verification hat on and started to think about corner cases and possible bugs. The RISC-V ISA has many sets of instructions and is modular to suit different purposes. Furthermore, RISC-V implementations are available in many different pre- and post-si products from different companies and organizations. This creates verification and debug challenges for verification of new RISC-V cores and systems.  

In the verification world of random-constrained, coverage-driven verification, there are important commercially available VIPs for all sorts of things from PCIe, to AXI, etc.  This third party VIP allows for more focus on differentiating work rather than building VIP in house. Knowing this, and looking at the RISC-V, I started to wonder… is there a need in the RISC-V community for some UVM SystemVerilog VIP for RISC-V verification?  What aspect of verification would be most immediately useful to the ecosystem? What better way to answer these questions than with a new open source project?

With the support of XtremeEDA, I started to plan out some VIP and start writing some SystemVerilog code. The state space for RISC-V possibilities is huge and a monolithic swiss army knife of a VIP would take too much time to develop.   Also, how do we know if there is a need and market here? Getting something, even something basic or simple to market, is our strategy – something that can be built upon.

For the initial development, the strategy is a narrow focus on something manageable.  Based on the lean nature of this development, we will get something to market early to get feedback and input from those in the trenches, feedback from those actually building and working with real RISC-V cores and SoCs.

Hence, we’ve launched the riscv-vip project.  This is an Apache licensed UVM SystemVerilog project hosted on GitHub.  The initial focus is on modelling instructions for debug tracing and functional coverage for the RV32UI base subset.  We want something that can passively be attached to existing verification work and report functional coverage. We want to get valuable feedback from the ecosystem and collectively make this better and more useful to the community.  Check it out; we’d like your feedback.

Leave a Comment

Comments are closed.

More Articles