TrekSoC: Achieving the Longstanding Goal of Vertical Verification Reuse

One of the curious aspects of electronics is that most products are specified from the top down but implemented and verified from the bottom up. This is true for system-on-chip (SoC) development as well. As the onset, someone in product marketing specifies a chip that has a specific collection of functionality to meet a specific customer need. The architecture team develops a block diagram that defines the subsystems and perhaps some individual IP blocks as well.

When it comes time to develop the RTL that implements the SoC, designers tend to work from  the IP blocks upward. They select commercial IP where it makes sense and develop unique IP when needed. Designers are usually responsible for verifying their own blocks, perhaps with some assistance from verification engineers. There is usually minimal verification of commercial IP unless it has been customized for the SoC project.

Block-level verification usually involves a combination of techniques. Testbenches tend to be simple, relying mostly on hand-written test vectors and perhaps even visual inspection of waveforms. Formal analysis using assertions works well for verifying important block-level properties. Static analysis of the RTL can catch many common coding errors as well as clocking and power errors that otherwise would not be detected until full-chip verification.

The blocks are assembled together into subsystems, and at this point a dedicated verification team usually gets involved. They will develop testbenches, usually based on the Universal Verification Methodology (UVM) standard, for most of the subsystems. This typically involves writing drivers to stimulate the inputs, monitors to check the outputs, and scoreboards to keep track of multiple transactions. UVM defines the “virtual sequencer” as the testbench component controlling the overall flow.

Finally, the designers combine all  the subsystems together into a complete full-SoC hardware design containing one or more embedded processors. As this point, a complete UVM testbench becomes challenging since the methodology does not tie into the code running on the processors. It can also be hard to write a virtual sequencer for an SoC with many interconnected inputs and outputs. Verification engineers may hand-write some tests to run in the processors in simulation, but these usually have no link to UVM testbench components.

The result is that different verification components and techniques are used as the design grows “vertically” from  IP  blocks to subsystems to a complete SoC. Development teams have long had the goal of reusing aspects of the verification environment through this flow, but reuse is limited at best. Passive testbench components such as protocol monitors and results checkers are perhaps the most reusable since they can appear at any level where the signals being checked exist.

Assertions are also portable when used in simulation, but formal analysis does not scale to the full-SoC level except for a few specific applications. Also, as lower-level blocks are connected together into subsystems, many of the assertions that were used to drive the blocks with formal analysis are transformed into monitors as their block inputs are subsumed in the larger design.

The UVM was defined with verification reuse in mind, but it has some of the same limitations. Passive components can easily be reused. Drivers on block-level inputs that remain inputs to the SoC can generally be reused, but as with formal many block inputs become internal signals in the SoC and are driven by the design itself rather than by verification components.

Tests are also very hard to reuse. Block-level hand-written tests are by their nature throwaway and not reusable at the subsystem level. UVM-based subsystem tests generally need extensive modification at the chip level because the inputs and outputs change dramatically. Scoreboards and virtual sequencers in particular are likely to look very different for the full SoC and, as above, can be so complex that they’re never fully developed.

Is there any form of verification component or verification IP that can be reused from IP block to subsystem to full SoC? Of course! The graph-based scenario models used by TrekSoC fit the requirements perfectly. At the block level, the designer or the verification engineer can develop a scenario model for the IP. TrekSoC can use this model to generate transactional tests for the IP block, communicating directly with whatever form of bus-functional model (BFM) connects to the block’s inputs and outputs in the testbench.

At the subsystem level, the scenario models for the IP blocks can be combined together to form a higher-level scenario model. Again, TrekSoC can automatically generate transactional tests. This works all the way up to a “headless” form of the full SoC where the processors have been replaced by BFMs or UVM verification components. TrekSoC treats the processor interfaces as virtual inputs and outputs of the chip.

At the full-chip level, where the processor are included, TrekSoC adds the most value to the verification process by automatically generating multi-threaded, multi-processor, self-verifying C test cases. Some projects use TrekSoC and scenario models only at this level, although the project as a whole benefits when scenario models are developed for IP blocks and the full-SoC model can be developed more easily.

Design reuse has been well understood for years, and there is no SoC project that does not reuse IP blocks from previous projects, related projects, or external sources. SoC developers have had a longstanding goal to achieve a similar level of verification reuse. Assertions and the UVM took some steps in this direction, but the goal has finally been met through the use of Breker’s graph-based scenario models. They are, quite simply, the most reusable form of verification IP.

Tom A.

Tags: Breker, functional verification, integration verification, IP, reuse, scenario model, SoC verification, subsystem, use cases, verification IP, vertical, VIP

This entry was posted on Tuesday, October 8th, 2013 at 7:17 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.