Santa Clara, CA
Breker provides solutions for the automated functional verification of large, complex chips, including system-on-chip (SoC) designs containing one or more embedded processors. Today’s deep submicron technologies have raised the bar for verification, posing significant challenges to development teams, often consuming more of a project’s resources than any other step. Many teams put all their effort into verifying the IP components that make up the chip, performing only minimal connectivity and sanity tests at the full-chip level. The Breker TrekUVM product enhances the power of Universal Verification Methodology (UVM) testbenches by automatically generating multi-threaded test cases in the form of UVM sequences for complete chips. The Breker TrekSoC product provides faster and more thorough verification of the SoC by leveraging the power of the embedded processors within the chip and connecting to the UVM testbench. The Breker TrekSoC-Si product extends this verification to hardware platforms such as in-circuit emulation (ICE), FPGA prototypes, and actual silicon in the lab. The Cache Coherency TrekApp provides a pushbutton solution for verifying system-level coherency in a multiprocessor SoC.
The Myths of SoC Verification
Breker is dedicated to providing faster and more thorough SoC verification by exploding the three myths of SoC verification.
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. These teams argue that IP components are relatively independent, 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 fabric, interrupts, GPIO, 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 the SoC level
Existing testbench-based verification solutions, typically using SystemVerilog and the Universal Verification Methodology (UVM), have proven themselves capable of verifying IP components and large chips without embedded processors. Some verification teams argue that the UVM’s scenario capabilities and extensibility enable system-level tests to be developed for the SoC.
Fact: The existing verification methodologies create testbenches designed to exercise hardware blocks and cannot generate system-level tests or create software C test cases. Testing a SoC containing one or more embedded processors requires a set of C test cases running on the processors. These test cases must activate the possible interactions between the IP components and exercise the paths between them. It is difficult to develop such SoC tests 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 test cases that are capable of running on multiple platforms. The complexity of this solution requires an automated approach to generating high-quality C test cases for SoC functional verification.
Myth #3: Standard APIs can make tests run on all environments
The industry has defined standard application programming interfaces (APIs) designed to enable a testbench developed within a simulation environment to be usable within an emulation or prototyping environment. Similar interfaces allow testbenches to be constructed out of reusable IP 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. A C test case contains specific information about how to drive IP components, 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 component is changed, all test cases 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.
The SoC Verification Iceberg
For the SoC with embedded processors and other bus agents sharing resources and interacting in unanticipated ways, verification of the individual IP components is not enough. Indeed, the top-level verification done by many SoC project teams is only the tip of the iceberg.
The SoC Verification Iceberg
Addressing the verification challenges beneath the surface requires robust test cases running on the embedded processors. It is too hard to exercise corner-case conditions using only an external testbench. Some SoC teams acknowledge this and develop manual tests to run on the processors. However, hand-writing code to run on multiple parallel, independent processors is in itself a major challenge. There is not enough time to understand, let alone verify, all possible system-level interactions.
The Breker SoC Verification Solution
The Breker TrekSoC and TrekSoC-Si products provide the solution to SoC verification challenges by automatically generating self-verifying C test cases for the embedded processors. These test cases exercise the corner cases of the design faster and more thoroughly than hand-written tests and trigger unusual conditions unlikely to occur even by running production code in the processors. TrekSoC generates test cases for architectural models, simulation, and acceleration, while TrekSoC-Si generates test cases for in-circuit emulation, FPGA-based prototypes, and production silicon. The same scenario models are used for generation across all these platforms.
In production use, TrekSoC and TrekSoC-Si address all of the major challenges faced by verification teams using traditional methods:
- Manual development of test cases: TrekSoC and TrekSoC-Si are fully automated, generating compiled C test cases that run in your SoC’s embedded processors
- Limited time and memory: full-chip simulation is often slow and SoCs have limited memory, but the test cases generated by TrekSoC and TrekSoC-Si make efficient use of both time and memory
- Difficulty controlling testbench actions: it is hard to coordinate corner cases from the testbench along; TrekSoC and TrekSoC-Si use the power of the embedded processors to verify your chip while controlling the input and outputs via bus functional models (BFMs) without the need of a testbench
- Need to support multiple environments: TrekSoC and TrekSoC-Si can integrate into multiple simulation environments as well as simulation acceleration, emulation and prototypes, with the generated C tests running in all these environments as well as in the final SoC
- Limited reuse of test cases: in addition to portability across multiple environments, the TrekSoC and TrekSoC-Si test cases can be reused from the IP block level all the way to your full chip or full system
- Lack of high-level coverage models: TrekSoC and TrekSoC-Si supplements the familiar low-level simulation coverage metrics with a scenario-based system-level coverage view that better represents system behavior and supports a more sophisticated SoC verification plan
TrekSoC and TrekSoC-Si provide a set of verification services that help you build high-level scenario models to describe the SoC’s operation. TrekSoC and TrekSoC-Si use these models to build a graph-based representation that the Trek constraint solver can use to generate the test cases. TrekSoC and TrekSoC-Si provide fast, efficient verification that catches corner-case bugs before silicon, decreasing your time to market and increasing the quality of the SoC and the end products containing it. The end result is increased profitability.