Verify More in Less Time with VCS

Using VCS’ native testbench, assertion and coverage capabilities to find complex design bugs quickly

Feburary 2006

©2006 Synopsys, Inc.

©2006 Synopsys, Inc. 2

IntroductionRTL verification dominates most chip development schedules, with electronics firms pouring up to 70% oftheir engineering resources into the task. Unfortunately, this high level of investment hasn't always paid offin terms of first-silicon success. According to a recent survey1, 71% of all IC designs fail on first siliconand require at least one re-spin. 60% of these faulty designs have functional errors that could have beendetected with more thorough RTL verification.

Why aren't more designs successful on first silicon given the high level of investment? The answer lies inthe ever-increasing growth of design complexity and the corresponding exponential increase in verificationcomplexity. The experience of microprocessor development at Sun Microsystems2 illustrates this trend.During a four-year period, design complexity (measured by number of lines of RTL code) for its SPARCmicroprocessors increased by 6x, roughly in line with Moore's Law. However, verification complexity (measured by number of logic simulation cycles) grew by 100x during the same period.

Keeping up with this staggering growth in verification complexity requires new approaches. This paperdescribes how the VCS® RTL verification solution from Synopsys runs up to 5x faster than traditionalapproaches, enabling fundamental improvements in verification efficiency and thoroughness even for themost complex system-on-chip (SoC) projects. The result is a more predictable verification progress, converging more quickly toward coverage goals and taping out with a much greater chance of first-silicon success.

From Bolt-On to Built-In VerificationThe current era of functional verification began with the advent of HDL simulation in the late 1980s. HDLsimulators became the primary tool in the verification engineer's toolkit by the early 1990s. In subsequentyears HDL simulator performance and capacity advanced significantly, but verification engineers foundthat additional capabilities were needed. This resulted in the emergence of numerous “bolt-on” tools thatworked with simulation, for example, coverage analysis, assertion checking, and testbench automation.These tools enabled new methodologies that helped address the growth in verification complexity.

However, these bolt-on tools limited the performance of simulation and created an inefficient, fragmentedsolution requiring multiple methodologies and vendors. Project engineers were responsible for integratingthe tools together and trying to develop a coherent verification methodology-a huge investment of timeand effort. As large SoC designs emerged in the late 1990s and early 2000s, the weaknesses of thisfragmented verification approach began to draw the attention of the chip development community. Itbecame clear that a unified, comprehensive solution was needed.

Synopsys is the leader in the trend away from fragmented verification tools and methods, and has led theindustry to the next era of functional verification. The built-in capabilities of Synopsys' VCS enable a unified verification approach in which the best of the advanced technologies, including testbench automation, assertion checking and coverage analysis, are integrated with high-performance simulation.

The key is Synopsys' Native Testbench (NTB) technology, which compiles design, testbench, assertions andcoverage together. NTB unites disparate tools and methodologies in a single, high-performance solution.Every VCS user is able to deploy the most advanced verification methodologies available, including constrained-random test generation, powerful assertion checking, and comprehensive coverage analysis.

The benefits of these advanced verification methodologies are clear: engineers can detect more bugs inless time, and achieve a higher rate of first-pass silicon success. Synopsys users are experiencing thesebenefits today: a recent survey of Synopsys verification customers3 showed that 90% of their designswere functionally correct on first silicon.

Unifying key verification technologies into a single tool has many advantages in terms of performance andease of use. The remainder of this paper explores the features and benefits of VCS' built-in testbench,assertion and coverage technology, and how they can help verify complex designs more thoroughly in lesstime.

©2006 Synopsys, Inc. 3

Compiler OptimizationsThe biggest disadvantage of having multiple verification tools bolted together is that each tool compiles or interprets its own language independently. For example, an independent code coverage tool and a simulator analyze the RTL design separately, reading the code and building their own independent models.This is inefficient during the analysis/compilation phase and can lead to differences of interpretation forcertain RTL constructs in the design.

The problem is more serious when different pieces of code are analyzed with different tools. For example,a testbench automation tool analyzes and compiles the testbench code while the simulator compiles thedesign itself. This independent analysis means that a single compiler cannot perform optimizations acrossthe design and testbench. Many decades of research have yielded highly sophisticated forms of compileroptimization, but these require visibility into the complete body of code for maximum effect.

Synopsys has leveraged this vast compiler experience to apply a wide range of optimizations to RTL codecompiled by VCS. These optimizations speed up RTL simulation and save memory for the design model.However, these optimizations cannot be extended to testbench, assertion or coverage code as long asthese portions of the verification environment are analyzed by separate tools.

The inclusion of built-in testbench, assertion and coverage capabilities within VCS allows its single NTBcompiler to apply code optimizations to both the design and verification components of the simulation environment. The same level of performance cannot be achieved by separate compilations, for example,with a bolt-on verification tool that compiles testbench or assertion code but not the design.

Elimination of Unnecessary SignalsOne of the most valuable optimizations performed by the VCS compiler is the elimination of design signalsthat are not needed in the verification environment. In a typical RTL design, there is a certain amount ofsignal redundancy as well as many intermediate signals that help with code readability. A smart compilercan often optimize away many such signals. The less that a simulator has to track, the faster it will run, sothis form of optimization can lead to significant performance improvement.

The problem arises when simulation optimization algorithms can't determine whether signals are reallyneeded. This is the case whenever bolt-on tools access the RTL design. Since these interfaces mayrequire access to any signal in the design, it is not safe to eliminate signals during the optimizationprocess. The testbench, in particular, might need to read or write any RTL signal at any time. As with otherforms of optimization, the compiler needs to see the full scope of the design and verification environmentfor best results.

By directly compiling the testbench, assertions and coverage code, as well as built-in functions such as theVerilog Change Dump (VCD) facility, VCS can determine which design signals need to be retained.Eliminating both unnecessary signals and the structures required to read and write these signals from bolt-on tools gains simulation speed and reduces the memory needed for the simulation model. This alsohelps VCS apply optimizations uniformly across the design, testbench, assertions and coverage code.

VCS eliminates unnecessary signals as an intrinsic part of its single compilation pass; no extra steps areneeded to “learn” which signals are needed and then try to optimize them away. Further, many signals forwhich access is needed are further optimized by the VCS compiler; bolt-on tools do not have the option toperform such optimizations.

Other Performance BenefitsAnother performance advantage of VCS arises from faster access to design data in cache memory duringverification. The ability for all components of the verification environment to share a common model meansthat most accesses happen in a smaller region of memory than for the independent models and representations produced by bolt-on verification tools. Thus, with VCS it is more likely that data will beavailable in cache rather than main memory.

©2006 Synopsys, Inc. 4

Finally, the NTB integration of testbench, assertion and coverage capabilities within VCS eliminates theoverhead of communication between the simulator and bolt-on tools. This inter-tool communication traditionally has been accomplished by the Programming Language Interface (PLI) in Verilog designs andby similar vendor-proprietary approaches for VHDL. Since VCS includes all components of the verificationenvironment, they share the same model and so data value changes are simply written and read from thecommon model. Elimination of PLI helps speed up simulation, although experience has shown that VCS'optimizations are a much larger factor.

Synopsys measurements on a wide range of customer chips have shown that the combined effect of optimizations and communication within VCS can typically improve simulation speed up to 5x over bolt-ontools. As shown in Figure 1, the amount of speedup depends upon the percentage of simulation timespent in the design versus the testbench. Because of the VCS optimizations that eliminate unnecessarysignals, usually the design and built-in testbench together run faster than the design itself does when hobbled by a bolt-on testbench.

Savings in Memory UtilizationThe common design and verification models enabled by VCS also lead to significant reductions in theamount of memory needed for verification. An example is shown in Figure 2, in which a testbench automation tool must maintain a model (data structure) for the signals in the design that it reads or writes.Of course, the simulator has its own model for the design, and so this leads to duplication of design dataand a resulting overhead in memory usage. Figure 3 shows the memory efficiency gained by VCS.

100%

80%

60%

40%

20%

0%

6.6X 4.4X 2.7X 1.4X

Testbench Design Unified Testbench and Design

Speedup

Sim

ulat

ion

Tim

e (N

orm

aliz

ed)

Figure 1: Built-in testbench support can speed up the entire simulation, including the design.

©2006 Synopsys, Inc. 5

VCS is very efficient in its storage allocation for the design and verification data, another benefit of itssophisticated compiler technology. Synopsys measurements and customer experiences have shown thatVCS can reduce total memory consumption by up to 3x over the combination of a traditional simulator andbolt-on verification tools.

Additional VCS BenefitsThe combination of higher performance and lower memory usage means that VCS can run chip verificationon older CPUs with less memory than competitive solutions, thus preserving the huge investment that project teams make in their server farms. Likewise, the same advantages of VCS allow larger projects torun on a given platform than other tools can handle. This gives VCS greater capacity to handle very largedesigns with complex verification environments.

Code CoverageTool

Assertion Tool

RTL Design

Data 1

Data 2

Data 3

Data 4

Data 5

Data 6

Data n-1

Data nTestbench Automation Tool

Testbench

Drivers Data 1Data 2

Data 7

Data 9

Monitors Data n

PLI

Simulator

Figure 2: Simulator bolt-on tools create data redundancy.

RTL Design

Testbench

Drivers

Monitors

CodeCoverage

Assertions

VCS

Data 1

Data 2

Data 3

Data 4

Data 5

Data 6

Data n-1

Data n

Figure 3: VCS’ built-in verification technology eliminates

data redundancy.

©2006 Synopsys, Inc. 6

VCS also has significant ease-of-use advantages. Learning how to use multiple verification tools is alwaysa challenge, made especially difficult because each tool has its own compile-time switches, run-timeoptions, command set and user interface. Even after the chip verification team does all the work to engineers are still faced with learning each tool and its user interface.

In addition to the performance gain and memory reduction, building verification functionality into a simulator also provides much greater ease of use. In the case of VCS, options to control the design, testbench, assertions and coverage can all be specified at the same time in a common format. Simulationresults can be viewed using a common interface-the Discovery Visualization Environment (DVE)-minimizingthe learning process for design and verification engineers, and allowing them to become productive inmuch less time.

Naturally, a set of verification capabilities developed by a single vendor will be better integrated, betterdocumented, and architected under the guidance of a shared vision and a unified, coherent methodology.In addition, dealing with a single verification vendor makes it easier to evolve the verification environment,report and track any problems encountered, and obtain support when needed.

VCS' Testbench CapabilitiesVCS provides built-in support for testbenches written in SystemVerilog, the industry's first hardware designand verification language, the OpenVera® hardware verification language, or a combination of the two.Native simulator support for testbenches is critical to achieve the benefits outlined thus far, while languagesupport for testbench constructs is essential for coding efficiency and the use of advanced verificationtechniques.

Hardware verification languages, including OpenVera, exist precisely because RTL design languages arenot expressive enough for modern verification techniques such as constrained-random stimulus generation. Verilog was enhanced to produce SystemVerilog partly to add these same verification capabilities. Accordingly, expanding a simulator such as VCS into a full-fledged RTL verification solutionrequires constrained-random stimulus-generation support.

Verification engineers have known for many years that they can't possibly think of all possible design scenarios and manually write directed test cases to verify them. The solution has been to introduce randomness into stimulus generation, which both automates the process and exercises corner cases thatmight not be hit by hand-written directed tests. RTL languages are good enough for coding basic directedtests, but not powerful enough to use random testing as the foundation for verification.

However, purely random functions can only be used to generate random values unrelated to previous orsubsequent values. Therefore, they cannot be used to generate significant stimulus values, such as thedestination address in a network packet or the instruction opcode in an instruction. These require constrained-random stimulus generation, which uses constraints to guide the generation of the values.Constraints can be efficiently described in any order, then easily added, removed or modified to obtain different data streams, all without requiring any modification to the stimulus-generation code.

As shown in Figure 4, the constrained-random approach converges to complete verification more quicklyand predictably than hand-written directed tests. An initial effort is required to set up the constraints, typically followed by some refinement, and then the automatically-generated tests rapidly converge on thecoverage goals.

©2006 Synopsys, Inc. 7

Verification engineers strive to complete testing of all functionality in a chip design before tapeout. Whatactually happens on many projects is that a tapeout deadline is enforced even when verification is notcomplete, leading to a low-quality design with many problems discovered in silicon. The greater rate of verification convergence provided by the constrained-random approach makes verification completionmuch more likely prior to tapeout and yields a much higher-quality result whenever tapeout occurs.

Synopsys' Constrained-Random TechnologyConstrained-random capability requires the ability to specify constraints efficiently plus constraint-solverengines to generate high-quality stimulus within the bounds of these constraints. Synopsys provides industry-leading capabilities in both of these areas. OpenVera is a powerful hardware verification languagethat provides all the constructs necessary to describe constraints in an efficient and natural manner.OpenVera strongly influenced the verification capabilities of SystemVerilog, including constraint specification.

Synopsys' Vera® testbench automation tool pioneered a very powerful constraint solver that generatescomprehensive, high-coverage stimulus even in the presence of complex constraints. More recently,Synopsys' Pioneer-NTB leveraged the Vera technology to add support for SystemVerilog as well asOpenVera.

The same production-proven constraint solver used in Vera and Pioneer-NTB is included in VCS, so thattestbenches running entirely within VCS have the same capabilities. The constraint solver actually usesmultiple engines and analyzes constraints in parallel. This allows solutions to combinations of constraintsacross verification objects. Many other constraint solvers handle only one constraint at a time, serially,which severely limits their ability to find solutions to complex, interacting sets of constraints and often generates false constraint conflicts that are time-consuming to diagnose and work around.

The VCS solver never reports false constraint contradictions; it is guaranteed to find a constraint solution ifone exists and if it can be found in the time allocated. If constraint conflicts prevent a solution, VCS makesit easy to diagnose and fix the error by calculating and displaying the minimal conflicting subset of constraints.

Given the complex nature of SoC protocols, many constraint-driven stimulus sequences simply cannot beset up, debugged, nor generated by any non-Synopsys tool or method.

Time Savings

Directed Approach

Constrained-RandomApproach

100%

Time

Percent ofFunctionalityTested and

Design Quality

Figure 4: Constrained-random verification is much more efficient than writing directed tests.

©2006 Synopsys, Inc. 8

VCS' Assertion CapabilitiesOne key aspect of effective verification is getting the designers involved in the design-for-verification(DFV) process early. Effective DFV entails a number of changes in the way that designers do their job andinteract with the verification team. These may include following specific design rules to make verificationeasier or employing advanced RTL coding methods-such as using the SystemVerilog design constructssupported by VCS-that reduce the likelihood of errors in the code.

One essential part of DFV is a way for designers to express their intent concisely and naturally as part ofthe design process, so that it can be objectively verified. They express this intent in the form of assertions,ideally added by the designers in the process of writing their RTL code. Verification engineers often addadditional assertions during the verification process, especially on interfaces for which specifications areavailable.

Assertions make block-level verification with simulation or formal analysis more effective, another importantpart of good DFV practice. During chip-level simulations, assertions pinpoint design errors at their source,reducing the time it takes to diagnose and fix bugs. Assertions also have value just by their very existence:since they document intent while it is still fresh in the designer's mind, they are very valuable if the designis reused or even if the original designer revisits the code after an extended period of time.

Various forms of assertions and assertion-checker libraries have been used by leading-edge chip development teams for quite a few years. Simple assertions can be written directly in RTL code, althoughcapabilities are limited. More sophisticated forms of assertions have usually been implemented as plug-inverification components. These suffer from the same performance degradation and memory overheadproblems as other bolt-on tools and models.

VCS completely avoids these issues by natively supporting two powerful formats: SystemVerilog assertionsand OpenVera assertions. These assertions are read by the same compiler that handles the RTL and testbench code, so that the full range of compiler optimizations can include assertions as well as the designand testbench. In addition, both of these assertion formats can be specified in the testbench, in a separatefile, or in-line within the RTL code itself, taking advantage of the context of the surrounding design.

These same assertions can be used as properties with formal analysis tools such as Synopsys' Magellan™to enable even more extensive verification. This avoids having to re-write assertions in some specializedproperty language to take advantage of formal tools. The ability to leverage a single description for multiple verification approaches saves time and effort.

Synopsys includes with VCS a library of assertion checkers for common types of design structures andinterface rules. These checkers provide a very valuable way to capture complex assertions without havingto write a lot of code. Since engineers can make mistakes when writing assertions just as they do whenwriting design or testbench code, a pre-verified library reduces the number of incorrectly-specified assertions. Available in both SystemVerilog and OpenVera, the assertion checkers are optimized for efficient simulation with VCS and formal analysis with Magellan.

Synopsys also provides a library of assertion IP for standard protocols such as PCI, PCI-X, AMBA andUSB. Capturing the complete set of protocol rules with assertions enables both simulation and formalanalysis for verification of designs using these standard interfaces. Both the VCS assertion checkers andassertion IP contain functional coverage points that supplement those specified by design and verificationengineers.

©2006 Synopsys, Inc. 9

Assertions should at least print out an error message if they are violated during simulation, but they can domuch more. For example, a testbench can report a test failure whenever an assertion fails, even if theresults-checking passes. In other cases, the testbench might want to detect and react to assertion failuresin specific ways, such as dumping out contents of registers that can help with debugging the assertion violations.

These techniques require close interaction between the testbench and the assertions, which adds considerable overhead if the design, testbench and assertions are running in different bolt-on tools. Sinceall three components can run within VCS, all interaction remains within the simulation kernel and so there'sno performance impact. Thus, VCS supports fast, real-time reactivity to assertion violations.

Finally, VCS provides several features to help debug assertions. With the visualization capabilities of DVE,engineers can easily see why assertion violations occur. This makes it possible to distinguish betweendesign bugs and incorrectly specified assertions, change the appropriate code, and verify the fix when simulation is rerun.

VCS' Coverage CapabilitiesCoverage metrics serve three critical roles in all verification environments:

n They identify “holes” in the process by identifying areas of the design that have not yet been sufficientlyverified.

n They help to direct the verification effort by indicating what to do next, such as which directed test towrite or how to expand constrained-random testing.

n They provide a quantitative measure of verification progress that helps gauge when verification is thorough enough to tape out.

VCS provides a comprehensive set of unified coverage metrics:

n Code coverage- Statement coverage- Block coverage- Line coverage- Finite state machine (FSM) coverage- State coverage- Transition coverage- Sequence coverage- Branch coverage- Path coverage- Toggle coverage- Condition coverage

n Functional coverage- Cover properties- Cover groups- Assertion coverage

The most widely used form of coverage is code coverage, an automated process that reports whether allof the code in an RTL design description was exercised during a particular simulation test or set of tests.Although some tools may equate code coverage with line coverage, line coverage by itself is of limitedvalue. There may be many ways to reach a particular line of code, and VCS' more sophisticated coveragemetrics allow every possibility to be tracked.

Code coverage was the first verification capability outside of the RTL code itself that VCS supportednatively. Unlike bolt-on code coverage tools, VCS does not require any special pragmas to be added to theRTL code. In addition, the overhead of running code coverage in VCS is low enough that SoC verificationteams can turn on the metrics for every simulation test, even during regression runs.

While code coverage has significant value, it should be supplemented by functional coverage to providemetrics that have specific meaning to the verification team. Designers and verification engineers can useSystemVerilog or OpenVera to explicitly specify functional coverage points for their design that are thentracked by the simulator along with the other forms of coverage. This allows the team to check whethertests are exercising the right areas of the design as per the test plan and to measure whether all possiblecombinations of stimulus were tried.

SystemVerilog and OpenVera allow design or verification engineers to write cover properties, which lookvery much like assertions but represent legal corner-case behavior that the engineers want to track ratherthan illegal behavior that should generate an error if it occurs. VCS automatically tracks and reportswhether the specified conditions were exercised along with other forms of coverage.

Cover groups support higher-level functional coverage, for example which values of a range are exercised.Cover groups are most commonly specified in the testbench rather than the design, and are often used tojudge whether constrained-random stimulus is reaching all desired categories of behavior. Examplesinclude tracking opcodes in an instruction stream and monitoring transaction types on a complex bus. VCS supports the cross-coverage constructs of SystemVerilog and OpenVera, for example, to track all combinations of opcodes and operand types or transaction types and packet sizes.

VCS also provides assertion coverage, including tracking which assertions passed and which failed duringeach simulation test. VCS has an optional mode in which coverage points within assertions can be automatically tracked. This is very useful to detect situations in which assertions passed simulation onlybecause the logic related to the assertions (sometimes called assertion preconditions) was not exercised.

The unified coverage features of VCS allow all of the coverage metrics to be generated for a single test,combining code, functional and assertion coverage together using a user-specified weighting for eachmetric. Further, the results for multiple tests can be merged together to yield composite metrics across allthe tests in a regression suite. This provides a comprehensive, quantitative measure of verification completeness that helps the development teams make the difficult decision of when to tape out.

Putting the Capabilities TogetherThe combined capabilities of VCS enable a complete RTL verification environment with a single tool.Designers capture their designs in RTL form, adding assertions at the same time to capture their designintent. Verification engineers typically get involved once a group of blocks is assembled into a major sub-unit of the chip, often called a cluster.

At this stage, the verification engineers will establish a test plan, set up a testbench, define appropriateconstraints, and run constrained-random stimulus generation to verify proper operation of the cluster. Theymay specify additional assertions for the design and establish links with the testbench to detect assertionviolations and react as desired. The verification team may also run code coverage and other coverage metrics, although some teams wait until the full-chip level.

©2006 Synopsys, Inc. 11

When the complete chip is assembled, constrained-random simulation running with assertions and a widerange of coverage metrics are essential to verify the design thoroughly and to track verification progress.Whenever coverage is not sufficient, the verification team modifies constraints or perhaps writes a fewdirected tests to fill in the coverage holes. This approach allows the team to reach their coverage goalsmore quickly and more predictably.

The chip-level testbench may contain SystemC™ models for some verification components. In other cases,for example, when doing performance measurements, some portions of the RTL design might be replacedby SystemC models. VCS also supports this approach, since it natively compiles SystemC as well as RTLand verification code.

The complete development process happens entirely within VCS, so that the development team can takeadvantage of advanced verification techniques without paying for it in terms of performance, memory utilization or complicated setup.

Using the advanced capabilities of VCS requires a comprehensive, unified methodology to make the mosteffective use of each verification technique. The Synopsys Reference Verification Methodology (RVM) provides just such guidance, covering how to use assertions and coverage, build a sophisticated constrained-random testbench and develop reusable verification components. RVM is fully compliant with the industry-standard methodology documented in the book Verification Methodology Manual forSystemVerilog4, co-authored by experts from ARM and Synopsys.

ConclusionVCS is leading the industry from the era of inefficient bolt-on verification tools to built-in testbench, assertion and coverage capabilities. With these technologies encapsulated, VCS is much more than a simulator; it truly is the verification environment. VCS' native support for verification can yield up to a 5xperformance speedup and a 3x reduction in memory usage over bolt-on tools. VCS enables the thoroughverification of complex SoC designs, in much less time than with other tools and methods. The result is apredictable verification process with a far higher likelihood of first-silicon success, the goal of every projectmanager, designer and verification engineer.

1. Collett International Research, Inc. 2005 IC/ASIC Design Closure Study

2. Case study presented at the April 11, 2000 EDAC meeting by Anant Agrawal of Sun Microsystems

3. 2004 survey of Vera users by Synopsys, Inc.

4. Published in 2004 by Springer Science+Business Media, Inc.

700 East Middlefield Road, Mountain View, CA 94043 T 650 584 5000 www.synopsys.com

Synopsys, VCS and Vera are registered trademarks of Synopsys, Inc. Magellan and OpenVera are trademarks of Synopsys, Inc.

All other trademarks or registered trademarks mentioned in this paper are the intellectual property

of their respective owners and should be treated as such. All rights reserved. Printed in the U.S.A.

©2006 Synopsys, Inc. 02/06.CC.06-14014