SystemVerilog Test Suites Accelerate IP-to-SoC Reuse

Verifying complex SoCs takes a lot of effort. Our user surveys show that around 70% of the engineering resource involved in taping out a complex SoC is spent on verification, with half of that time consumed by debug.

You can get more information at VIP Test Suites.

Without a well-thought-out verification environment, verification teams waste a huge amount of time recreating verification environments at the SoC level to enable chip-level verification because they don’t consider reuse of the environments they originally developed to verify their block-level IP. Even across the same abstraction level, the inability to reuse the same verification IP and environment to support both simulation and emulation causes delays and consumes more engineering resources than necessary.

Being able to consistently reuse verification environments across an entire SoC project boosts verification productivity significantly. However, to gain from these productivity benefits requires verification teams to carefully plan their approach for all stages of the verification process.

The Verification Spectrum

Typically, verification teams develop separate flows to support verification at block and SoC levels. As well as supporting reuse between these different abstraction levels, the verification environment should be reusable at different stages of the verification process, to minimize effort.

Figure 1: Two dimensions of the verification spectrum

The starting point for every design is usually the system architecture, because it defines the overall performance requirements or constraints. From a design and verification perspective, the aim should be to reuse those performance constraints in subsequent phases and to ensure that the design continues to meet them as RTL is integrated and the design evolves.

For example, when constraints from the system architects such as bus throughput and latency have been verified at the block level, how does the verification team then ensure those constraints are met at the SoC level?

To achieve this, the verification team should aim to reuse the components, typically verification IP’s that monitor these constraints at both the block and SoC levels. The verification lead has to come up with a testbench architecture with common methodology, environment and verification IP that is reusable at block and SoC levels. The protocol verification IP must, of course, be able to take advantage of the performance constraints provided by the system architect and highlight any violations across the system interconnect. At the same time, for maximum productivity, the team should ensure that the tests written for block-level verification also work at the SoC-level and work in both simulation and emulation.

Consistency Is Key

The system architect is most likely using transaction-level modelling (TLM) techniques. The key to reuse is to ensure that the API is consistent between environments and abstraction levels. For example, the TLM API should be consistent with the C API for emulation – no matter what stage of the verification flow the team is working on.

What lies underneath each API – the drivers – will be unique to each environment, for example, a SystemVerilog driver for simulation and RTL driver for emulation. Regardless of what the API interfaces with at the driver level, it is the ability to reuse the API of the verification IP that is key to supporting reuse.

Supporting Block-to-SoC Reuse

While consistent APIs support reuse across the verification spectrum, IP-to-SoC reuse is one of the critical areas to improve productivity. It requires an approach based on adhering to best practice guidelines, consistent verification environments and consistent VIP.

Consistent Language and Methodology

Using a common language, such as SystemVerilog and UVM at the block and SoC levels and for all of the verification IP makes it easier and faster to integrate and test the design at each level.

Common Verification Plan

The principle of reuse should extend as far as is possible to the verification plan. The work done in defining the verification plan at the block level should transfer to the SoC level. This should include functional coverage definitions and tests that the verification team can reuse.

Shared Functional Coverage Database

Having a consistent coverage database at the outset can save tremendous time spent manually merging multiple, proprietary databases into a common format. A consistent database will enable the verification team to easily and quickly compare results from different abstraction levels.

Common Sequence Library and Debug

The ability to easily reuse stimulus between block and SoC level, by using a common sequence library, will boost verification productivity.

Design and verification teams spend a lot of time in debug. When finding a bug at the SoC level, it is likely that the engineer will have to transfer back to the IP level to investigate the problem. Being able to do that within a single, common debug environment minimizes the time that teams will have to spend in learning and becoming familiar with different environments.

Verification teams also benefit from having visibility across the test bench. Being able to view transactions within a debugger code window at both IP and SoC levels saves time that would otherwise be spent switching between different debug environments.

Common languages, methodology, planning and debug are the pre-requisites for enabling block-to-SoC reuse across different phases of the verification environment.

With the right infrastructure in place, teams can then focus on architecting the test suite that interfaces with the blocks.

Test Suite

Taking the wrong approach for test suites targeted at the block-level makes it difficult to reuse the block level verification environment and tests at the SoC level.

Figure 2 shows how a test suite is configured to support the verification of PCI Express IP at the block level, which is also suitable for reuse at the SoC level.

Figure 2: Test suite for PCI Express design

The test suite is designed to be modular. The blocks to the top-right of Figure 2 show how the PCI Express end-point RTL, AXI interface and associated drivers are encapsulated into one environment. The top-left side of the diagram shows the root complex VIP encapsulated in another environment. Isolating the overall environment from what’s ‘underneath’ is key to enabling a smooth transition between block and SoC-level verification.

In implementing the test suite, the aim should be to avoid making changes that will obstruct reuse; to avoid having to ‘touch’ tests more than once. Even relatively minor tasks, like changing the hierarchical path of an attribute will create a lot of work if there are hundreds or even thousands of tests hat have to be changed.

In order to minimize changes, verification teams should consider what has the potential to change between block and SoC levels when planning and writing tests, and ensure that tests don’t reference the internal environment. The best approach is to create tests that are ‘configuration aware,’ i.e. the tests should have knowledge of the overall environment and configuration. Tests should pass down the name of a configuration and have the driver decide how to apply the information.

Verification teams have to put all of these principles into practice in order to enable reuse from the block to the SoC level. Getting them wrong will create extra work in order to transition the IP test suite to the chip level.

Synopsys VC Verification IP

Synopsys has used SystemVerilog extensively in architecting its next-generation verification IP solutions to support ease of use and reuse. For example, Synopsys provides SystemVerilog source code for UVM-compliant (universal verification methodology) test suites, which can save a massive amount of development time and reduce the need for in-house expertise. The built-in features enable engineers to apply a consistent methodology across the entire verification spectrum for productive verification at both block and SoC level.

Synopsys verification IP and test suite solutions support the entire verification process from architectural analysis, to verification of blocks, to interconnect design, to SoC integration, and finally to hardware-software co-verification in emulation. The extensive Synopsys verification IP portfolio includes the latest protocols, interfaces and memories required to verify complex SoC designs. Deployed across thousands of projects, Synopsys VIP supports AMBA, PCI Express, USB, MIPI, DDR, LPDDR, HDMI, Ethernet, SATA/SAS, Fibre Channel, OCP and many others.

Summary

Verification IP has become a critical part of the verification flow, supporting a broad range of tasks, such as performance analysis, RTL verification of IP blocks, interconnects and SoCs, and in the form of transactors with emulation to enable full-chip verification including hardware-software co-verification.

IP-to-SoC level reuse in verification environments can boost productivity across the entire verification process. This approach requires verification teams to develop a reusable block test environment using the same language, methodology and verification IP, all of which must be built specifically to support reuse and have guidelines which are applied consistently.

Authored by Bernie DeLay