Verification Academy

Search form

My Account Menu

  • Register
  • Log In
  • Topics
  • Courses
  • Forums
  • Patterns Library
  • Cookbooks
  • Events
  • More
  • All Topics
    The Verification Academy offers users multiple entry points to find the information they need. One of these entry points is through Topic collections. These topics are industry standards that all design and verification engineers should recognize. While we continue to add new topics, users are encourage to further refine collection information to meet their specific interests.
    • Languages & Standards

      • Portable Test and Stimulus
      • Functional Safety
      • Design & Verification Languages
    • Methodologies

      • UVM - Universal Verification Methodology
      • UVM Framework
      • UVM Connect
      • FPGA Verification
      • Coverage
    • Techniques & Tools

      • Verification IP
      • Simulation-Based Techniques
      • Planning, Measurement, and Analysis
      • Formal-Based Techniques
      • Debug
      • Clock-Domain Crossing
      • Acceleration
  • All Courses
    The Verification Academy is organized into a collection of free online courses, focusing on various key aspects of advanced functional verification. Each course consists of multiple sessions—allowing the participant to pick and choose specific topics of interest, as well as revisit any specific topics for future reference. After completing a specific course, the participant should be armed with enough knowledge to then understand the necessary steps required for maturing their own organization’s skills and infrastructure on the specific topic of interest. The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization’s processes so that you can then reap the benefits that advanced functional verification offers.
    • Universal Verification Methodology (UVM)

      • Advanced UVM
      • Basic UVM
      • Introduction to UVM
      • UVM Connect
      • UVM Debug
      • UVMF - One Bite at a Time
    • Featured Courses

      • Introduction to ISO 26262
      • Introduction to DO-254
      • Clock-Domain Crossing Verification
      • Portable Stimulus Basics
      • Power Aware CDC Verification
      • Power Aware Verification
      • SystemVerilog OOP for UVM Verification
    • Additional Courses

      • Assertion-Based Verification
      • An Introduction to Unit Testing with SVUnit
      • Evolving FPGA Verification Capabilities
      • Metrics in SoC Verification
      • SystemVerilog Testbench Acceleration
      • Testbench Co-Emulation: SystemC & TLM-2.0
      • Verification Planning and Management
      • VHDL-2008 Why It Matters
    • Formal-Based Techniques

      • Formal Assertion-Based Verification
      • Formal-Based Technology: Automatic Formal Solutions
      • Formal Coverage
      • Getting Started with Formal-Based Technology
      • Handling Inconclusive Assertions in Formal Verification
      • Sequential Logic Equivalence Checking
    • Analog/Mixed Signal

      • AMS Design Configuration Schemes
      • Improve AMS Verification Performance
      • Improve AMS Verification Quality
  • All Forum Topics
    The Verification Community is eager to answer your UVM, SystemVerilog and Coverage related questions. We encourage you to take an active role in the Forums by answering and commenting to any questions that you are able to.
    • UVM Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • UVM Forum
    • SystemVerilog Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • SystemVerilog Forum
    • Coverage Forum

      • Active Questions
      • Solutions
      • Replies
      • No Replies
      • Search
      • Coverage Forum
    • Additional Forums

      • Announcements
      • Downloads
      • OVM Forum
  • Patterns Library
    The Verification Academy Patterns Library contains a collection of solutions to many of today's verification problems. The patterns contained in the library span across the entire domain of verification (i.e., from specification to methodology to implementation—and across multiple verification engines such as formal, simulation, and emulation).
    • Implementation Patterns

      • Environment Patterns
      • Stimulus Patterns
      • Analysis Patterns
      • All Implementation Patterns
    • Specification Patterns

      • Occurrence Property Patterns
      • Order Property Patterns
      • All Specification Patterns
    • Pattern Resources

      • Start Here - Patterns Library Overview
      • Whitepaper - Taking Reuse to the Next Level
      • Verification Horizons - The Verification Academy Patterns Library
      • Contribute a Pattern to the Library
  • All Cookbooks
    Find all the methodology you need in this comprehensive and vast collection. The UVM and Coverage Cookbooks contain dozens of informative, executable articles covering all aspects of UVM and Coverage.
    • UVM Cookbook

      • UVM Basics
      • Testbench Architecture
      • DUT-Testbench Connections
      • Configuring a Test Environment
      • Analysis Components & Techniques
      • End Of Test Mechanisms
      • Sequences
      • The UVM Messaging System
      • Other Stimulus Techniques
      • Register Abstraction Layer
      • Testbench Acceleration through Co-Emulation
      • Debug of SV and UVM
      • UVM Connect - SV-SystemC interoperability
      • UVM Versions and Compatibility
      • UVM Cookbook
    • Coding Guidelines & Deployment

      • Code Examples
      • UVM Verification Component
      • Package/Organization
      • Questa/Compiling UVM
      • SystemVerilog Guidelines
      • SystemVerilog Performance Guidelines
      • UVM Guidelines
      • UVM Performance Guidelines
    • Coverage Cookbook

      • Introduction
      • What is Coverage?
      • Kinds of Coverage
      • Specification to Testplan
      • Testplan to Functional Coverage
      • Bus Protocol Coverage
      • Block Level Coverage
      • Datapath Coverage
      • SoC Coverage Example
      • Requirements Writing Guidelines
      • Coverage Cookbook
  • All Events
    No one argues that the challenges of verification are growing exponentially. What is needed to meet these challenges are tools, methodologies and processes that can help you transform your verification environment. These recorded seminars from Verification Academy trainers and users provide examples for adoption of new technologies and how to evolve your verification process.
    • Upcoming & Featured Events

      • U2U MARLUG - January 26th
      • Creating an Optimal Safety Architecture  - February 9th
      • The ABC of Formal Verification - February 11th
      • Events Calendar
    • On Demand Seminars

      • I'm Excited About Formal...
      • Visualizer Coverage
      • Formal-based ‘X’ Verification
      • 2020 Functional Verification Study
      • All On-Demand Seminars
    • Recording Archive

      • Improving Your SystemVerilog & UVM Skills
      • Should I Kill My Formal Run?
      • Visualizer Debug Environment
      • All Recordings
    • Mentor Training Center

      • SystemVerilog for Verification
      • SystemVerilog UVM
      • UVM Framework
      • Instructor-led Training
    • Mentor Learning Center

      • SystemVerilog Fundamentals
      • SystemVerilog UVM
      • Questa Simulation Coverage Acceleration Apps with inFact
      • View all Learning Paths
  • About Verification Academy
    The Verification Academy will provide you with a unique opportunity to develop an understanding of how to mature your organization's processes so that you can then reap the benefits that advanced functional verification offers.
    • Blog & News

      • Verification Horizons Blog
      • Academy News
      • Academy Newsletter
      • Technical Resources
    • Verification Horizons Publication

      • Verification Horizons - November 2020
      • Verification Horizons - July 2020
      • Verification Horizons - March 2020
      • Issue Archive
    • About Us

      • Verification Academy Overview
      • Subject Matter Experts
      • Contact Us
    • Training

      • Questa® & ModelSim®
      • Questa® inFact
      • Functional Verification Library
  • Home /
  • Verification Horizons /
  • March 2018 /
  • A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs

A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs

Verification Horizons - Tom Fitzpatrick, Editor

A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs by Arun Chandra and Mike Bartley, T&VS

RISC-V (pronounced “risk-five”) is an open, free ISA enabling a new era of processor innovation through open standard collaboration. Born in academia and research, RISC-V ISA delivers a new level of free, extensible software and hardware freedom on architecture, paving the way for the next 50 years of computing design and innovation.

A RISC-V microprocessor can be configured in several architectural modes depending upon the target market and applications. Further, each microprocessor implementation can have different micro-architectural parameters depending upon performance, and power considerations. Examples of such micro-architectural parameters are cache sizes, the use of branch prediction, result forwarding, and pre-fetch to name a few.

This article outlines a hierarchical and configurable verification strategy for RISC-V based IP and SoCs. A three-level (unit, core and SoC) hierarchy is proposed for testbenches. Each level of the hierarchical testbench is configurable for both architectural and micro-architectural parameters. At the heart of the verification strategy is an ISG (Instruction Stream Generator) and a UVM testbench. The ISG can be configured according to the RISC-V architecture and then constrained to verify micro-architectural features. The generation of the specific configurable UVM testbench is automated based on a configuration file. The checkers, active testbench items like injectors, and coverage objects, are mostly portable across the various hierarchical levels, and are configurable based on the configuration file.

At the SoC level the tests are less ISG based and tend more towards C-based integration and use case tests ideally suited to the use of portable stimulus (as defined in the Accellera Portable Test and Stimulus Specification and supported by Questa® inFact, Cadence® Perspec™ and Breker™ Systems Trek). This allows tests to be easily ported across multiple SoCs with minimum effort, and to also be used in silicon validation.

INTRODUCTION

A RISC-V based SoC can be configured into different implementations based on architectural or micro-architectural parameters. To address the verification challenge this poses, a hierarchical and configurable verification methodology is proposed. A three-level hierarchy is proposed. The lowest level of the hierarchy is the unit-level. Two unit-level testbenches are proposed. These are 1) Execution (Pipeline) Unit, and 2) Cache (L2) Unit.

The Execution (Pipeline) Unit consists of the major pipelines components like Instruction Fetch, Instruction Decode, Instruction Execute, and Load Store. Both the level one caches (instruction, and data) are included in this unit. The Cache (L2) unit consists of the second level cache. The second level of hierarchy is the Core Level. At this level multiple Execution Units and the L2 cache are connected via a coherent bus. Both the unit-level testbenches, and the core-level bench can be configured for a specific implementation. The highest level of the hierarchy is the SoC which consists of the core and peripherals like PCIe, and MIPI.

An important feature of the verification methodology is that a testbench at any level is configurable based on architectural and micro-architectural parameters. Further, based on a configuration file, the testbench is automatically generated for the desired level and configuration. Subsequently, tests both directed and automatically generated can be run on the testbench.

The stimulus for the testbenches can be instruction-based for ISA heavy components like the Execution Units (Pipeline), or transaction-based for testing the L2. Checkers are reference-model based or assertion based. Checking the pipeline is done using a reference model checker, and it is a same for the L2 where a L2 behavioral model is needed. Additional checking is done via assertions. An example of an assertion check is that READ and WRITE are mutually exclusive. Additionally, loaders and injectors are part of a generated testbench, and generated via a configuration file. An example is a 32KB two-way set associative cache pre-loader.

In the rest of this article we cover Testbench Architecture, the Stimulus, Checkers, Pre-loaders and Injectors, Coverage and Development Milestone, and Conclusion.

TESTBENCH ARCHITECTURE

The hierarchical testbench architecture is shown in Figure 1. The stimulus, portable checkers, and interfaces are show in this figure.

Figure 1: Hierarchical Testbench Architecture


Unit-Level Testbenches

There are two testbenches at the unit level, these are the execution unit (pipeline), and the second-level cache (L2).

RV Execution Unit (Pipeline) Testbench - The RV Execution (Pipeline) Unit Testbench verifies the single-issue, in-order pipeline. The five-stage pipeline consists of instruction fetch, instruction decode, execute, memory access, and write back. The instruction cache and data cache are also part of the execution unit. A unit to handle interrupts from the pipeline perspective is also part of the execution unit.

As the short pipeline does not have to deal with micro-architectural verification bottlenecks of a longer superscalar pipeline, it is recommended that all the components in the pipeline be treated and tested as one unit.

Examples of such bottlenecks are register renaming, floating point converts for non-committed instructions, stalls due to load store dependencies, integer and vector register un-naming due to branch misprediction, and reservation station stalls. However, one micro-architectural area that needs to be handled is branch prediction. The branch predictor comprises a branch target buffer (BTB), a branch history table (BHT), and a return-address stack (RAS).

The stimulus to this unit will be RISC-V instructions whose binary values will be loaded into a L2 behavioral model. These instructions could be directed hand-written tests, or tests output from a random Instruction Stream Generator (ISG). Additional inputs apart from instructions will be interrupts, and injected errors. The testbench also contains pre-loaders to preload the caches, and branch predictor array structures.

The reference-model checker for this unit will be an instruction-based instruction set simulator (ISS). A trace tool will monitor the RTL for PC, and Register Value Updates, and will compare against the output of the ISS. Additionally, micro-architectural checkers will be added especially with respect to branch prediction, and exception and interrupt handling.

L2 Testbench - The L2 testbench will verify the second-level cache. Both its interface to the level-one (I and D) caches, and main memory will be verified. The stimulus to this unit will be transactions including, Read, Write, Invalidate, and Refill. The stimulus to this unit will come from a constrained-random transaction generator like a UVM sequencer. Additional inputs to this unit will be injected errors to test the ECC mechanisms. The testbench also contains pre-loaders to preload the caches.

The reference-model checker for this unit will be a reference model (L2 Behavioral Model). This model will model the L2 at the transaction level. The L2 state, in addition to transactions output will be compared against the RTL. Additionally, micro-architectural checkers will be added, especially if there are low-power features included in the implementations.

Core Testbench

The Core-Level Testbench tests the component in the core complex. These include the RISC-V Execution units, the Coherent Bus, and the L2 Cache. It also contains the interrupt units, and the debug unit. The stimulus into the core will be both instruction-based, and transaction-based. As the RISC-V execution units, and the L2 have been verified at the unit level, the focus of core-level verification will be stressing the interconnect fabric, and the interrupt, and debug units.

The stimulus for this bench will come from the various ports. RISC-V assembly stimulus generated by hand, or using a random instruction generator or ISG will come from the main memory behavioral model connected to the memory port. The instruction-based tests should generate traffic to the system port for un-cached access to high bandwidth peripherals. The instruction-based tests should also be able to generate traffic to the peripheral port for accessing peripheral devices. The system port and peripheral port can be mapped into two different address ranges.

The stimulus for the Front Port is transaction-based and comes in the form of requests to the ITIM, and DTIM. In addition, the core-level testbench has transaction-based stimulus for interrupts, and debug requests.

All the checkers from the unit-level are ported to the core level. Additionally, at least four categories of checkers are added at the core-level. These area: 1) An interface checker to check for bus transactions on the coherent bus, 2) A checker to check interrupt request, and subsequent servicing, 3) A checker for debug requests, and servicing, and 4) A checker for Port requests and servicing. These checkers can be implemented as UVM style scoreboards.

Checkers for arbitration and micro-architectural checkers will be added as needed. An example of an arbitration checker is to guarantee that the I/O ports get fair access and are not timed out. An interrupt priority checkers checks that if two interrupts are pending, the higher priority one gets serviced first.

SoC Testbench

The SoC testbench is the top-level bench and exercises the interfaces between the core complex and the peripherals like PCIe and MIPI. The input into the SoC bench is based on the Portable Stimulus standard proposed by Accellera and supported by Mentor, Cadence and Breker Systems.

Portable stimulus provides a specification of test intent and coverage at a higher-level of abstraction. Also, it provides graph-based randomization. The Portable Stimulus will be generated for a specific implementation using the configuration file.

All the checkers from the unit-level and core level are ported to the SoC level. Additional VIP checkers from the PCIe, and MIPI will be integrated. Finally, interface checkers will be built at the SoC level.

Configurable Testbench Generation

The generation of an implementation specific testbench is based on a configuration file shown in Figure 2. The fields in the configuration file, which are both architectural and micro-architectural determine the implementation specific testbench. The major fields in the configuration are described below.

Figure 2: Configuration File for Testbench Generation


The SoC-COMPONENTS field lists all the components of the implementation. The example shown below shows a RISC-V cores complex, PCIe, L2, and MIPI amongst other components.

The RVEXE-COMPONENT-ARCH field lists the ISA variant for the RISC-V core. This describes the number of general purpose registers, and the various extensions (M, C, A, F, D, and Q). The example below shows a RISC-V execution unit supporting 32 registers, multiply and divide, and single precision floating point.

The RVEXE-COMPONENT-UARCH field lists the micro-architectural features for the specific implementation. These include the cache sizes, and associativity, and branch prediction structures. The example below shows a two-way set associative 32KB instruction and data cache, a BTB, a single-level BHT, and a RAS.

The L2-COMPONENT-UARCH lists the second-level cache micro-architectural features. This includes the cache size and associativity, and error correction if enabled. The example below shows a 4-way set associative 2 MB cache.

The L2-COMPONENT-POWER field lists the number of power domains for the second level cache. This is a low-power feature.

The RVCORE-COMPONENTS field lists all the core components for the specific implementation. The example below shows, four RV Execution units, the L2 cache, the inter-connect, the interrupt, and debug unit, and the I/O ports.

The LOW-POWER field describes the low power techniques used in the SoC like clock-gating, and multiple power domains.

LOW-POWER = Domain(1), Clock-Gating(ON)

The desired testbenches are generated based on a command line that specifies the benches needs, and the configuration file. As an example, all the testbenches (Unit, Core. SoC) are generated using the configuration file, and the unit-level (RVEXE) bench shown in Figure 3 is generated using the second command line.

Cmd1: rvtbgen –all rv101.config

Cmd2: rvtbgen –rvexe rv102.config

Figure 3: Unit-Level (EXE) Testbench


Subsequently, after the appropriate testbench is generated, random tests using the test pattern generators are generated. Additionally, directed tests can also be written to run on the appropriate testbench. The overall methodology for configurable testbench generation is shown in Figure 4.

Figure 3: Unit-Level (EXE) Testbench


STIMULUS

Areas Under Test

The configuration file is key to generating the constrained-random stimulus. As an example, no floating instructions will be generated if the F mode is not supported. Another example is that back to back branch instruction generation-weight will be lower if branch prediction is not supported. At the unit level, stimulus will be provided to the RVEXE unit or L2 unit. Examples are integer instructions for the RVEXE unit, and L2 DCache interaction for the L2 unit.
The core complex unit stimulus will include Cache Coherency, and Virtual Memory and Protection handling. Finally at the SoC-level interrupt handling, reset, and Low Power features will be tested.

IINSTRUCTION-BASED STIMULUS

Instruction-based stimulus comes from a RISC-V instruction stream generator, constrained by both architectural and micro-architectural constraints. Additionally, instruction-based stimulus can also come from directed tests. Examples are integer instruction, branch instructions, floating point instructions, or memory instructions.

Transaction-Based Stimulus

Transaction-based stimulus used in the L2 and Core is constrained by both architectural and micro-architectural constraints. It is generated by UVM-Style sequencers, which subsequently call sequences. Additionally, transaction-based stimulus can also come from directed tests. Examples are L2-I/D Cache interactions, L2-Memory interaction, and L2-Error Handling.

CHECKERS

Reference Model-Based Checkers

The following reference-model checkers are needed. They will be generated from the configuration file. As an example, the L2 cache size and associativity will determine the L2 behavioral model, and subsequent checker. Also, the branch prediction checker can be customized based on the RAS availability.

  1. Pipeline Checker
  2. Branch Prediction Checker
  3. L2 Checker

At the unit-level, for the RVEXE unit the following reference-model based checkers will be needed:

Pipeline Checker – The reference model for this checker will be the ISS. A pipeline monitor from the RTL will extract PC update, and Register updates at instruction commit. These values will be checked against the output of the ISS.

Branch Prediction Checker – To accurately verify branch prediction, a reference model will be built to model the branch prediction structures (BTB, BHT, RAS).

For the L2 unit, the following reference model checker will be needed:

L2 Checker – To accurately verify the L2, a L2 behavioral model will be built. The output of this checker will be checked against the RTL at a transaction granularity.

These reference model checkers will be portable to the core complex and SoC level.

Assertion Checkers

Two kinds of assertion checks will be needed, these are low-level assertion checks, and high-level assertion checks. All these assertion checks will be portable for all three hierarchical levels, unit, core, and SoC.

Low-level assertions are written at the unit-level for the RVEXE, and L2 and are internal to the module. It is highly recommended that the RTL writer creates these assertions in conjunction with the RTL. Examples of low-level assertions are:

  • Request-Grant: A request is granted within a certain number of cycles.
  • One-Hot: The output of a signal is always one-hot.
  • Mutually-Exclusive: Read and Write are mutually exclusive.

High-level assertion checks can be written using low-level assertion checks, and it is recommended that the verification engineer write these checks. Areas where high-level assertion checks are recommended are:

Interface Checks – Checking the interface between the various components of a SoC. As an example, the interface between the L2 and the RVEXE.

Cache Coherence Protocol Checks – The cache coherence protocol can be verified by providing a high-level SVA-based checker to check the finite-state machine. In some cases developing a reference model can also check coherence.

Bus Transactions – Checking that the bus or the interconnect, handled all requests, and handled them in order with the right priority.

All assertion-based checkers should be written in SystemVerilog, to be fully compatible with UVM. All assertions can be input into a formal verification tool for static formal verification.

PRE-LOADERS/INJECTORS

Cache/Array Loaders

The cache pre-loaders will be generated based on a specific implementation configuration (cache size, associativity) provided in the configuration file. The cache loaders will be needed to preload the level one and level two caches during reset. This is to prevent running through the entire boot sequence. Additionally, cache preloading is required to get the cache initialized to a certain state to verify interesting scenarios (cache coherence) in an accelerated fashion.

The array pre-loaders will be generated based on a specific implementation configuration (BTB size) provided in the configuration file. The array loaders will have the ability to preload array structures in the design, like the BHT. The primary use for array pre-loaders will be to be verify hard to test features in an accelerated fashion.

Injectors

Injectors can be used in all three levels of hierarchical testbenches. These injectors will be generated based on the configuration file. For example, for ECC supported memory single bit errors, and double bit errors can be injected. Three categories of injectors will be needed:

Interrupt Injection – To test both local and global interrupts, the interrupt injector will inject an interrupt as a request.

Error Injection – To test the reliability features in the design like ECC the error injector will be needed to inject single or double bit errors.

Event Injector – Debug requests, and other interesting events will be injected by the event injection mechanism.

All injectors will be portable in all hierarchical levels, and configurable via the configuration file.

COVERAGE

Coverage-Based Methodology

At each level of the hierarchy unit, core, or SoC a coverage-based methodology will be used. Coverage categories are listed below:

  • Machine-Generated Code Coverage: Line, Code, Toggle, Expression.
  • Functional Internal: Internal coverage objects.
  • Functional Interface: Interface coverage objects.

Functional coverage objects are generated from a test plan. Also, functional coverage objects will leverage assertions both low-level, and high-level.

CONCLUSION

This article shows hierarchical and configurable verification strategy for RISC-V based SoCs. A three-level hierarchy is proposed for testbenches. The three levels are:

  1. Unit
  2. Core
  3. SoC

Each level of the hierarchical testbench is configurable for both architectural and micro-architectural parameters. The generation of the specific configurable testbench is automated based on a configuration file.

This article also lists the areas under test, and stimulus and checkers needed.

REFERENCES

SiFive, “U54-MC Core Complex Manual,” Oct 4, 2017.
A. Waterman and K. Asanovic, Eds.,The RISC-V Instruction Set Manual, Volume I:User-Level ISA, Version 2.2, May 2017.
The RISC-V Instruction Set Manual Volume II: Privileged Architecture Version 1.10, May 2017.
"Accellera, Portable Stimulus Early Adopter Specification,” June, 2017.
S. Gupta, “Efficient Verification of Mobile SoCs with Perspec and Portable Stimulus", CDN Live Conference, April 2017.
University of Berkeley Architecture Research, “TileLink Protocol v0.3.3,” 2017.

About T&VS: Test and Verification Solutions Ltd (T&VS) provides services and products to organizations developing complex products in the microelectronics and embedded software and systems industries.

T&VS operates globally with offices in the UK, France, Germany, India, Singapore, the USA plus a network of international partners.

www.testandverification.com

All product or service names are the property of their respective owners.

Back to Top

Table of Contents

Verification Horizons Articles:

  • Achieving Your Team Goals Is Similar to Winning a Super Bowl Championship

  • Make Your Constraints More Dynamic with Portable Stimulus

  • Configuring Memory Read Completions Sent by PCIe® QVIP

  • SATA Specification 3.3 Gaps Filled by SATA QVIP

  • Part I: Power Aware Static Verification - From Power Intent to Microarchitectural Checks of Low-Power Designs

  • SVA Alternative for Complex Assertions

  • A Hierarchical and Configurable Strategy to Verify RISC-V based SoCs

© Mentor, a Siemens Business, All rights reserved www.mentor.com

Footer Menu

  • Sitemap
  • Terms & Conditions
  • Verification Horizons Blog
  • LinkedIn Group
SiteLock