Evolution or Revolution in System-Level Verification?

Recently, SemiconductorEngineering published the three–part series “System-Level Verification Tackles New Role” as part of its ongoing “Experts at the Table” discussions. The format is simple–an editor sits down with four or five industry experts to discuss a particular topic–but the debate can be lively and the result educational. Breker participates in these roundtables as often as we can, focusing of course on verification among the many technical topics covered by the site.

In advertising a “new role” for system-level verification, this particular series was not overstating the case. We tend to talk a lot about the evolution of verification in general, especially for system-on-chip (SoC) devices and multi-SoC systems. But in some ways what is happening now with our products and the Accellera portable stimulus standardization effort is more revolutionary than evolutionary. So which is it? We’ll attempt to answer that question in today’s post here on The Breker Trekker blog.

When considering what the new role might be for system verification, first we must consider the old (traditional) role. Once upon a time, when chips were much smaller and less complex, much of the verification was performed at the top level, on the complete chip. The verification team would build a simulation testbench around the RTL design and try to exercise all of its key functionality with some combination of hand-written and automated tests. Design features were enumerated in a test plan and checked off as each was verified.

At least four things have changed for today’s verification team. The first is the availability of high-quality, well-verified IP blocks from internal and external sources. Most of the time, the verification engineers do not focus on these blocks, specifically not trying to exercise their complete functionality at the full-chip level. For new design blocks, the team spends time verifying them thoroughly in stand-alone testbenches to raise their quality level as well. The goal is for all blocks to be well-verified before the complete chip is assembled.

The hope may be that the complete chip can be verified with a relatively small amount of effort. Some teams verify only that the IP blocks have been properly integrated into the full-chip design. As we have discussed at length, this is not sufficient. It is critical to string IP blocks into realistic scenarios that represent actual use cases for the chip. We have also described how trying to stimulate these system-level scenarios purely from a testbench is like pushing on a rope.

Most complex chips these days are SoCs with embedded processors. The good news is that these processors have the power to verify the design from the inside out, so it’s much easier to set up multi-IP scenarios with C test cases running on the processors than with testbench transactions alone. But this creates the second big shift for the verification team: they must learn how to write interacting, multi-threaded, multiprocessor test cases or find a way to generate them automatically.

Another challenge is that some aspects of the design can only be verified at the full-chip level, regardless of how robust the IP blocks may be. In the roundtable, Imperas called these “extra-functional properties” that include power management, safety, security, and performance. The full scope of these properties is visible and verifiable only at the top level of the system. Specific test cases are required for this verification, ideally generated rather than hand-written.

The final change is that it may be impossible to run the entire SoC in simulation due to slow speed and impractical to model the entire SoC in an emulator or FPGA prototyping system because of the cost. Sometimes, as in a recent project at Cavium, the first time that the entire chip can be run together is using fabricated silicon in the lab. Such a project needs a solution that can automatically generate test cases for all verification platforms (simulation to silicon) from a single representation of verification intent.

The scope of the portable stimulus standard under development and the solutions available from Breker today in our TrekSoC family address all four of the new complexities for chip verification. In some ways this is a revolution: automatically generating highly sophisticated portable test cases with full debug capabilities plus coverage and performance metrics is a big step for the industry. But, for the sake of deployment and wide adoption, the effort by the verification team must be incremental.

The scenario models that capture verification intent are based on graphs, which have been used in verification for many years, and look much like standard data-flow diagrams. Test case generation can be guided by constraints that are familiar and easily understood by all verification engineers. The generated test cases connect directly into existing testbenches built using the Universal Verification Methodology (UVM). Finally, debug and coverage analysis are performed using established industry tools.

As we say in the roundtable, portable stimulus is “the next big thing in system-level verification” so the result is a revolution, but the effort involved is evolutionary. Breker is not in business to tout some exotic methodology that only a few experts can use. We provide proven solutions that can be used by all verification engineers to realize extraordinary benefits on their SoC products. Please contact us to learn more.

Tom Anderson

The truth is out there … sometimes it’s in a blog.

Tags: acceleration, applications, apps, bandwidth, Breker, cache coherency, Cadence, coverage, debug, EDA, emulation, FPGA prototyping, functional verification, graph, Imperas, mentor, multi-SoC, multi-threaded, multiprocessor, performance analysis, portable stimulus, reuse, scenario model, simulation, SoC verification, system coverage, transactional, TrekApp, TrekBox, TrekSoC, TrekSoC-Si, UVC, uvm

This entry was posted on Thursday, July 14th, 2016 at 5:13 pm. 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.