TrekSoC-Si: Achieving the Longstanding Goal of Horizontal Verification Reuse

All of us at Breker are excited as we write this post, since we’ve just made our most important product announcement in several years. We’ve expanded the Breker product line by adding TrekSoC-Si, a brand-new tool that generates multi-threaded, multi-processor, self-verifying C test cases for in-circuit emulation (ICE), FPGA-based prototypes, and actual production silicon. In other words, TrekSoC-Si does for hardware platforms what TrekSoC did for simulation.

We’ll talk more about how TrekSoC-Si works in a moment. But first it’s important to note that both TrekSoC and TrekSoC-Si use the same graph-based scenario models as input to describe the intended behavior of the SoC and provide a test plan. This means that, for the first time in the industry, you can achieve horizontal verification reuse across your entire project schedule, from high-level simulation models all the way through your first chips arriving from the foundry.

There are six distinct stages in your verification project schedule; our two products split them perfectly. TrekSoC was designed primarily to handle RTL simulation with a testbench, typically following the Universal Verification Methodology (UVM) standard. TrekSoC also supports simulation acceleration, in which some or all of the SoC design has been mapped into a hardware accelerator but the testbench remains in software simulation. Testbench hookup is the same or very similar to regular simulation.

Some of our customers have developed scenario models even earlier in the project, during the electronic system-level (ESL) design and verification phase. TrekSoC can generate test cases at this stage, and they tend to run very efficiently since the processor and the rest of the SoC are often modeled in SystemC at a level higher than RTL. The testbench may look quite different and use transaction-level modeling (TLM), but it’s still a form of simulation and TrekSoC can support it.

Once you move into in-circuit emulation, there is no longer any notion of a testbench. The SoC is fully mapped into hardware and connects to a target board or target system via its I/O pins. The same is true of an FPGA-based prototype, in which the SoC is mapped into an array of FPGAs in a commercial or custom-built system. Finally, of course, when the actual chips arrive from the foundry they are also plugged into some sort of target board or target system.

TrekSoC-Si generates test cases for any or all of these three hardware platforms. Most SoC projects have significant teams of engineers writing embedded diagnostics to run on the silicon and perhaps on the other two platforms as well. While the goal is to boot the embedded operating system and run applications on the silicon, in practice SoC teams do not attempt this when the silicon first arrives in the bring-up lab. Debugging problems found with production software running on production silicon is very difficult. Further, in many cases the SoC is too large to fit entirely into the ICE or prototyping system, so only subsets of production software can be run prior to silicon.

Thus, the diagnostics are important to test each part of the SoC, bringing it up incrementally before trying to boot an operating system. TrekSoC-Si automatically generates test cases that stress the SoC on any of the three hardware platforms, reducing or eliminating the need for hand-written diagnostics. Your embedded programmers can be redirected to work on real applications, adding far more value than hand-coding throw-away diagnostics that are used only for SoC bring-up.

You can see why we’re excited about TrekSoC-Si and its potential for radically transforming what happens in the SoC bring-up lab. We’ll discuss in a future post how TrekSoC-Si does something that no one has ever done before: gather coverage metrics from actual silicon. Until then, please read all about our new product and celebrate with us the achievement of full vertical and horizontal verification reuse with Breker’s graph-based scenario models.

Tom A.

Tags: Breker, EDA, functional verification, graph, reuse, scenario model, SoC verification, Trek, TrekSoC, TrekSoC-Si, verification IP, VIP

This entry was posted on Tuesday, October 15th, 2013 at 8:31 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.