Why Breker?

Breker is committed to solving the escalating SoC verification challenge by providing users with a solution that allows them to upgrade their SoC verification flow from an ad-hoc approach to a deliberate assault. Supported by extensive field research and deployments, TrekSoc is an eloquent way to solve your SoC verification issues.

SoC Verification Myths

Each generation of system contains more features and capabilities. They also rely more heavily on IP reuse. Today,functional verification consumes more resources than design and the percentage is increasing. Many myths are beginning to inhibit the adoption of more robust and scalable solutions. Breker intends to expose those myths and provide solutions suitable for even the most complex of chips being designed today.

Myth#1 Stitch and ship is good enough

Due to time and resource pressures, many SoC verification teams are forced to take a "stitch-and-ship" mentality and assume that since each IP has been pre-verified, it is only necessary to perform basic integration testing at the system level. It is argued that IP components are relatively independent and have their reputations at stake, so it should be reasonable to hope that there will be no significant functional errors.

Fact

Even if the IP contains no functional errors, there are many shared resources within a SoC including memory, caches, page translation units, bus fabrics, interrupts, GPIO and clocking and power management logic. All of these shared resources create opportunities for unexpected interactions between seemingly independent IP blocks. An elegant way to capture these interactions is required.

Myth#2 Current solutions are scalable to SoC

Existing verification tools, such as SystemVerilog and UVM, have proven themselves capable of block level verification. Their scenario capabilities and extensibility enable system level tests to be developed.

Fact

The existing verification methodologies are testbenches designed to exercise hardware blocks and cannot generate system level tests or create software C tests. Testing a SoC requires a set of C test cases that activate the possible interactions between IP blocks and exercise the paths between them. As a result SoC tests are developed by hand.

A scalable verification solution that can meet multiple objectives such as concurrency, coherency and data ordering, is almost impossible without having a suite of C tests that are capable of running on multiple platforms. Manually creating these C tests is limiting and what is needed is an automated approach to generating high quality C tests for SoC functional verification.

Myth # 3 Standard APIs can make tests run on all environments

There are standard APIs designed to enable a testbench developed within a simulation environment to be useable within an emulation or prototyping environment.Similar interfaces allow testbenches to be constructed out of reusable components allowing for the verification of product families.

Fact

Reusing test cases across testbenches and across different SoC designs is difficult and requires manual porting of test cases. A C test case contains specific information about how to drive IPs such as a sequence of register operations. It contains information about the specific SoC the test is being run on, such as memory locations that may be used. If an IP is changed, all tests need to be manually updated.Different tradeoffs need to be made in verification techniques for different testbench environments, making it inefficient and schedule limiting to hit all the interesting cases across all environments.

This manual effort needs to be replaced by a way to generate "target aware" test cases for different testbenches and different SoC designs where information about IPs, SoCs and testbenches are maintained separately to allow for easy reuse.

The SoC Verification Iceberg

Figure 1: The SoC Verification Iceberg

Most SoC test cases are developed manually. Basic integration testing requires considerable effort and there is little time to understand, let alone test, all possible system-level interactions.

As a result only the tip of the iceberg is being addressed with SoC verification today, leaving large holes in system verification coverage. This manifests itself as bugs that are discovered post-silicon during software integration and product validation. These late stage bugs are difficult to track down and slow down an already long software validation cycle. This increases time-to-market, and directly reduces financial revenues.

Technical Challenges in SoC Verification

The desired objectives of the SoC verification team are unattainable today using the tools and languages developed for block level verification. Breker addresses each and every one of the issuesand challenges identified by the market. Those challenges include:

Manual Development of Test Cases

Testing a SoC requires a set of software C test cases. Existing verification languages,such as SystemVerilog and UVM, are designed to enable the verification of hardware blocks and cannot generate software C tests. As a result all SoC tests must be developed by hand. Manually creating C tests that combine multiple objectives such as concurrency, coherency and data ordering is almost impossible.

Limited Test Cycles and Memory

There are a limited number of embedded CPU cycles available for fullchip SoC verification, especially in RTL simulation. Cycles spent on test overhead represent lost verification opportunity, both in terms of the level of concurrency that can be serviced, and the total number of tests that can be run.

There is also limited SoC system memory, especially when creating long tests with large arrays of expect data.

Controlling Testbench Actions

Many test cases require the coordination of multiple activities such as driving specific bus operations,injection of faults, interrupts and resets, and controlling parameters such as memory stall rates.

Supporting Multiple Environments

SoC verification has to support several execution environments.Each environment has different requirements for a test to run. Manually developing a set of test cases that can run on more than one environment is restrictive and difficult.

A fullchip environment contains processormodels in addition to significant quantities of IPs. This is often beyond the capabilities of simulators.Replacing theprocessormodels with Bus Functional Models (BFMs)increases simulation performance, but makes realistic verification more difficult.

The use of emulation or prototypes can also enable more extensive test scenarios to be executed.

If a test fails and the fault can be isolated to a specific IP, it is desirable to have a mechanism for replaying the relevant portions of the test for the IP block in isolation.

When silicon returns from fabrication, it is desirable to have a source of tests to validate the silicon before software is run on the platform.

Communication and Review of Test Plans

The testing of anSoC requires several types of verification ranging from basic integration testing to running application use cases and includes performance verification. It is difficult to define a set of test cases that can ensure all verification objectives have been met.

Lack of Coverage Models

System level verification is concerned with testing interactions between IP components, exercising memory regions, access to caches etc. Measuring this kind of coverage with the mechanisms provided withinSystemVerilog is very difficult. Measuring coverage in post silicon is impossible.

Limited Reuse of Test Cases

Attempts have been made to develop cross platform APIs to enable test portability, but typically this is not enough. In general reusing test cases on several execution platformsor across different SoC designs variants is difficult and requires manual porting of test cases.

Breker provides a SoC verification solution that is easy to use, scalable and reusable. It addresses each and every one of these challenges.