Va Vol6 Iss3 f6

verificationavenue
The Synopsys technical bulletin for design and verification engineers Vol. 6, Issue 3, October 2006
SystemVerilog-OpenVera Moving to the Next Level in

Interoperability in VCS
Alex Wakefield, Synopsys, Inc.
Verification Productivity and
Predictability
contents
Shekhar Mahatme, Synopsys, Inc. PRODUCT UPDATES
Simon Lacroix, Ross Video
Janick Bergeron, Synopsys, Inc. 2 ......... What’s New in VCS® 2006.06
Video production equipment provider 2 ......... Open Cores Protocol
Introduction Ross Video successfully combined (OCP) VIP Added to VCS
SystemVerilog is the first industry- Verification Library
Synopsys’ VCS® Native Testbench (NTB)
standard language to combine high- and the Verification Methodology Manual CONCEPTS (Synopsys Authored)
level verification constructs with design (VMM) for SystemVerilog to dramatically 1 ......... SystemVerilog-OpenVera
and modeling constructs in the same Interoperability in VCS
improve both productivity and pre-
language. Much of the verification and 3 ......... Accelerating Functional
dictability when verifying their latest Closure
testbench technology in SystemVerilog FPGA design. 8 ......... Using Unidirectional
was based on Synopsys’ donation of Constraints to Break
the OpenVera® language to Accellera, System Context Constraint Loops
providing a solid implementation to Targeting a Xilinx Virtex FPGA, the 13 . . . . . . . . . Combinational Equivalence
prove the utility and effectiveness of design implements a next-generation Checking for Retimed
these enhancements. With SystemVerilog, high-definition TV Warp processor that Designs
verification engineers have a single performs realtime 3D video effects. CONCEPTS (Partner Authored)
integrated language supporting the The complete system design includes 1 ......... Moving to the Next Level in
methodologies that Vera® tool users multiple high speed DSPs and a control Verification Productivity and
microprocessor to perform complex Predictability
have used successfully for years, 19 . . . . . . . . . Understanding the Key
including object-oriented programming, video processing for a new product
Elements of a VMM-based
constrained-random data generation, within Ross Video’s Synergy MD Testbench
transaction-level modeling and Series of multi-definition production QUESTIONS AND ANSWERS
functional coverage. switchers. The DSPs and multiple
26 . . . . . . . . . How do I enable the X-
FPGAs interact at high speed with a tracing feature in DVE?
SystemVerilog is a fully backwards- DDR memory buffer to create the video 26 . . . . . . . . . Can I generate a text
compatible enhancement to Verilog, warp transformation. based report with the
enabling Verilog users to adopt Unified Report Generator?
SystemVerilog at their leisure and Key Challenges: Time-to-Market and 26 . . . . . . . . . Can I merge groups of
transparently leverage all of their existing Verification Predictability coverage data and save
Verilog code. OpenVera users looking to The Ross Video team was motivated to them so they can be used
use a new verification methodology for for final merging at a later
adopt SystemVerilog would undoubtedly point of time?
want to have the ability to re-use their the design in order to reduce time-to-
26 . . . . . . . . . How can I view my MDA’s
existing OpenVera code. Enabling the market, and improve verification pre- (Multi-Dimensional Array)
reuse of OpenVera code verification IP dictability. Previously, the company had in DVE?
(VIP) on SystemVerilog projects is an used hand-generated directed tests with NEWS & EVENTS
important capability for providing a C and C++ models of video-processing 27 ......... Events Calendar
smooth SystemVerilog adoption path algorithms. This approach verified the 28 ......... Training
for OpenVera users. video data path well, but it didn’t provide 30 ......... Recommended Reading
sufficiently high coverage of control 32 ......... Documentation
This paper introduces the SystemVerilog- logic, resulting in many functional fail- 33 ......... News
OpenVera interoperability feature available ures in the lab that were difficult to 35 ......... Programs
continued on page 10 continued on page 17
The Synopsys Verification Avenue Technical Bulletin Vol. 6, Issue 3, October 2006
product updates
What's New in VCS 2006.06
®
The latest version of the VCS functional
verification solution adds many useful
Open Cores Protocol (OCP)
VIP Added to VCS Verification
Library
Editor:
Tom Borgstrom
features for fans of SystemVerilog. Synopsys recently announced the Program Manager:
Tess Cahayag
Additional SystemVerilog language upcoming release of DesignWare®
verification IP (VIP) for the Open Core Contributing Authors:
functionality has been added, such as
Janick Bergeron, Albert Chiang, Ben Cohen,
support for testbench constructs inside Protocol (OCP) version 2.1, to be
Ajeetha Kumari, Simon Lacroix, Shekhar
modules to enable creation of high-level included in the VCS Verification Library Mahatme, Neill Mullinger, Hemendra
models. Final blocks allow for cleanup and DesignWare® Library. OCP is a Talesara, Mike Tarsi, Robert Vallelunga,
calls at the end of simulation. Support common standard IP core interface, or Alex Wakefield, Isela Warner
for time-consuming functions in DPI socket, that facilitates plug-and-play General Manager, Verification Group:
permits VCS to call C code concurrently systems-on-chip (SoC) design. The Manoj Gandhi
with processes. SystemVerilog exten- DesignWare OCP VIP enables the
Publication: Quarterly
sions to VPI enable C code to access verification of master and slave devices
in OCP systems and cores and provides Address:
internal data structures and functionality. Synopsys, Inc.
To aid in debugging, the Dynamic 100% functional coverage as defined in
700 East Middlefield Road
Memory Profiler helps assure users are section 4 of the OCP-IP 2.0/2.1 Mountain View, CA 94043
writing efficient code. Compliance Checks document. The
Subscribe:
DesignWare VIP for OCP is natively
The VCS solution now provides a http://www.synopsys.com/cgi-
compiled by VCS Native Testbench bin/verif/tb/reg01.cgi?d=s
Unified Report Generator (URG), which (NTB) for up to 5x faster performance,
creates a single HTML-based report of Unsubscribe:
supports the VMM methodology for vtg-news@synopsys.com
functional, assertion and code coverage. SystemVerilog, and also supports
OpenVera-SystemVerilog interoperability Verilog, VHDL and OpenVera test- Feedback:
enables OpenVera testbench compo- http://www.synopsys.com/cgi-
benches. For more information, please bin/verif/tb/reg01.cgi
nents to be re-used in new SystemVerilog visit the Synopsys IP directory:
environments running in VCS NTB, with http://www.synopsys.com/products/ © 2006 Synopsys, Inc. All rights reserved.
full native performance. Verification IP designware/vip_solutions.html
from the VCS Verification Library can
now be natively compiled in VCS with
the design and testbench, offering up to
5x faster performance and support for
the VMM methodology.
For more information on the VCS
2006.06 release, please review the
release notes in the VCS section of
https://solvnet.synopsys.com/ReleaseNotes.
To download VCS 2006.06 please visit
http://solvnet.synopsys.com/EST.
Release notes and documentation is
also included with the distribution and can
be accessed via the command ‘vcs –doc’.
Example code is located in the directory
$VCS_HOME/doc/examples/nativetest
bench. You can also e-mail questions to
your local Synopsys application consultant
or to vcs_support@synopsys.com.
www.synopsys.com page 2
concepts synopsys
Accelerating Functional Closure
Neill Mullinger, Synopsys, Inc.
Hemendra Talesara, Spansion
more complete verification and reduces
the time taken to develop an advanced
testbench environment.
Verification Compute Farms
It is common today for companies to
deploy batch simulation runs via a load
sharing utility over some form of compute
Directed-Test Methodology
Abstract farm. As verification methodologies
Building a directed verification environment
This paper focuses on practical aspects evolve towards heavier usage of con-
with a comprehensive set of directed
of the verification process that can strained random verification (CRV), the
tests is time-consuming, difficult, and
help reduce the time taken to reach utilization of these compute farms has
does not scale well. Also, since directed
functional closure. It is based on increased; CRV ideally maximizes the
tests only cover conditions that have
experiences of working directly with many utilization of a compute farm by spreading
been anticipated by the verification
leading edge semiconductor companies parallel seeds across all available CPUs.
team, they do a poor job of exhaustively
implementing modern verification
covering corner cases. This can lead to Unified Coverage
technologies and methodologies. It
costly re-spins or, worse still, missed One consequence of a coverage driven
will discuss the power of constrained-
market windows. In a directed method- methodology is the need for effective
random simulation using an object-
ology, the process of writing the tests and methods to process a massive amount
oriented testbench and verification IP
validating the response is an enormous of coverage information that is generated
(VIP) to provide better control and reuse.
task that must be replicated for every during verification. Historically there has
It will then show how this leads to more
important functional aspect of the been a number of different coverage
effective use of available resources
design. The verification team frequently metrics used to assess verification
such as simulation compute farms and
runs out of time before the tape-out progress towards a prescribed goal.
engineers’ time. Since coverage is a
date. However, the bigger issue is that Code coverage is the oldest and least
measure of how effectively the design
directed tests only check for predicted sophisticated type of coverage mea-
is being verified, this paper will address
behavior while it is typically the unfore- surement: line, toggle, branch, and FSM
when and how to implement code and
seen behavior that trips up design coverage all provide insight into which
functional coverage and use it to
teams and leads to extremely costly parts of the RTL are being stressed, but
achieve functional closure.
bugs found in silicon. they do not guarantee that all function-
Introduction ality has been tested; code coverage
Constrained-Random Verification
As ASIC and system-on-chip (SoC) tools do not account for design intent
(CRV) Methodology
designs continue to increase in size or context. Functional coverage is a
The advent of constrained-random veri-
and complexity, there is also a significant more meaningful metric since it records
fication gives verification engineers an
increase in the amount of verification that specific functionality has been
effective method to achieve coverage
required to achieve functional coverage verified. Functional data can be collected
goals faster while also helping to find
goals. This has led to a trend away from in two ways: by adding coverage monitors
corner-case problems. It moves the
hand-authored directed test methodolo- to the testbench that track behavior at
emphasis from writing an enormous
gies, towards machine-generated stimulus the extremities of the design, or by
number of directed tests to writing a
using a constrained-random methodology. using assertions embedded in the actual
smaller set of constrained-random
The use of simulation compute farms design RTL. Assertions are a powerful
scenarios which use randomly generated
is ideally suited to accelerating the way to ensure that the design’s important
parallel seeds to let the compute
larger number of tests created by this intended behavior is verified. A unified
resources do the work. The time taken
approach by allowing parallel simulations. coverage approach is inclusive of each
to reach coverage goals is not gated by
type of coverage analysis without over-
With the corresponding emergence of the manual labor required to hand-write
whelming engineers with too much data.
faster, more complex bus standards to directed tests but by the number of
handle today’s massive volume of data processors that can be utilized to run Four Steps to Verification Closure
traffic there has also been a renewed random seeds on a smaller number of All projects must start with a good
interest in commercially available test scenarios. On a simulation farm, verification plan that defines all of the
verification IP. VIP that supports con- this can significantly reduce the time verification objectives and the specific
strained-random verification enables required to achieve coverage goals. attributes to be measured. Coverage is
one of the key metrics used in verifica- companies create reusable and scalable Synopsys and ARM, defines a standard
tion and plays a role in each of four flows based on their Pilot Design coverage-driven methodology for the
major phases in the verification process. Environment. Much of this paper has creation of a constrained-random envi-
been realized from these experiences. ronment with the goal of reducing the
1. Create a reusable and scalable
time to achieve coverage goals. It defines
verification flow Step 2: Creating a reusable test-
the VMM Standard Library — a collection
2. Create a reusable testbench archi- bench architecture
of SystemVerilog base class building
tecture One of the most important decisions of
blocks that enable faster development
the verification process is to create a
3. Divide testing into three phases to of the verification environment.
testbench that can support the chosen
optimize critical resource utilization methodology and meet the needs for One of the major building blocks in any
4. Perform regression to achieve scalability, flexibility and reuse of the testbench is the VIP needed to generate
functional closure. verification flow. The testbench archi- stimulus through the standard bus
tecture should maximize the benefits of protocols used in the design. Similar to
Step 1: Create a reusable and scal- constrained random testing. In order to the way that SoC design teams benefit
able verification flow be manageable and reusable as the from the use of pre-verified IP, pre-
Verification flows integrate tools and design environment grows, the testbench verified commercial VIP from a trusted
methodologies with the intent of making should leverage Object-Oriented coding source accelerates testbench develop-
it simple to execute on the verification techniques. Object-Oriented testbench ment and improves quality. Verification
tasks and analyze results. Past experi- languages such as SystemVerilog are IP provides off-the-shelf testbench
ences have shown that flows live a lot ideal for writing reliable, reusable code. building blocks for widely used protocols
longer than planned so creating a They solve many of the data scoping like AMBA AXI, OCP, USB, PCI
reusable and scalable verification flow problems encountered with large pro- Express and so on.
is critical. Once the flow is defined it cedural programs, and include a reuse
should be reusable across multiple When used with VMM, VIP converts
model that years of experience have
projects with enough flexibility to cater randomized scenarios from the generators
shown to work. This is something that
to individual project needs. The flow into pin-level traffic at the interface to
procedural code (C or HDL-based
must be open to using tools from multiple throw a wide spectrum of varied traffic
Testbenches) never did well.
vendors and be flexible enough to at the design with the minimum of effort
adopt new technologies. Sticking with The Verification Methodology Manual from the test writer. Figure 1 shows how
widely supported industry standards is (VMM) for SystemVerilog, co-authored by the VIP and VMM work together.
a safe way of achieving this goal.
Layer
Test
A verification flow should be reusable Test

across multiple levels of the project:
Scenario
block level, sub-system, chip-level and

Layer
Generator
full system tests. It needs to scale to
meet the needs of future generations
Command Functional
and be reusable on similar projects

Coverage
Layer
VIP Transactor Self Check Checker

across the company.
As the size of verification has increased,
Layer
many companies have built large simu- Driver Monitor Assertions DUT Monitor
lation farms. The verification flow should
take advantage of these farms and
Signal
Layer
help assimilate the resulting data for DUT

further analysis.
Synopsys Professional Services have bus protocol
gained a wealth of experience from helping Figure 1: Verification IP and the VMM methodology
Verification IP falls into two similar but achieve coverage of the possible Primary concerns are that resources
distinct categories. Transactors model transaction types and sequences. This are often squeezed and coverage data
the behavior of a device on the bus or has a significant effect on overall analysis takes up time when basic bugs
interface, and generate all of the trans- verification productivity. are still being wrung out of the system.
actions and sequences that can be Based on this experience, the following
A whitepaper, Five Vital Steps to a Robust
used throughout the full breadth of the three phase approach has been devel-
Testbench with DesignWare Verification
protocol. The traffic they generate can IP and Verification Methodology Manual
oped that many project managers find
be used to stress the design under test (VMM) for SystemVerilog, describes how more effective and practical.
and verify that it deals correctly with to rapidly create a constrained-random 1. Specification-Driven Testing
error conditions. Monitors are used to testbench. This whitepaper is available at:
snoop the bus or interface to create a 2. Bug-Driven Testing
www.synopsys.com/cgi-bin/systemverilog/
log of the transactions and to provide pdfr1.cgi?file=vip_in_rvm.pdf 3. Coverage-Driven Testing
functional coverage information so that
verification engineers can see which A follow-up whitepaper, Advanced This section elaborates the role of cov-
types of transactions have been verified. Techniques for Robust Testbench erage as these testing phases proceed.
This protocol-based coverage information Development with DesignWare Verification Figure 2 shows a typical bug rate and
is included in the overall coverage IP and Verification Methodology Manual coverage profile over the testing lifecycle.
results for the design under test. (VMM) for SystemVerilog, describes
Phase 1: Specification-driven testing
how to use such advanced techniques
Commercial Verification IP In this initial phase of verification, the
as callbacks and scenario generation
One of the key values of commercial design is immature. Coverage does not
in a constrained random testbench.
VIP is that it significantly reduces test- play a significant role here because the
This whitepaper is available at:
bench development time by eliminating primary concern is identifying as many
www.synopsys.com/cgibin/systemverilog/
the need to write, test, and maintain bugs as possible to get the design in a
pdfr1.cgi?file=dw_vip_and_rvm_wp.pdf
many thousands of lines of user-devel- relatively stable operational state. This
oped code. Building VIP is extremely Step 3: Divide testing into three phase is not really concerned with the
challenging and time consuming, phases to optimize critical resource completeness of testing, just finding
requiring development of transactors, utilization the critical functional bugs.
monitors, and scenario generators. For Working with many companies, it was
In this phase the CRV environment is
today’s complex standards such as found that not everyone feels quite ready
heavily constrained to focus on key
PCI Express it can take more that to adopt a coverage-driven methodology.
functional elements. This makes the
250,000 lines of code to model the
protocol, and add to that a similar 120
Coverage
number of lines for the VIP’s own
Bug Rates
regression environment. 100
How VIP's DesignWare helps
DesignWare® VIP supports the layered 80
VMM methodology, reducing the effort
required to develop the testbench envi- 60
ronment and resulting in a faster time
to first test. It builds on the VMM 40
Standard Library and includes protocol-
specific scenario generators that make 20
it simple to generate the desired ran-
dom bus behavior. The use of DesignWare 0
VIP can be distributed over the available Spec Driven Bug Driven Coverage Regression
simulators to generate many random Driven
protocol-based scenarios that rapidly Figure 2: Bug finding rate and Coverage profile
focused effort more like a directed-test It is also important during this time to regression runs are short, others run
methodology which is valuable to weed complete the implementation of cover- over night and depending on the
out early bugs. It is also a part of ramping age points in the design to check the design, some regression suites may run
the CRV environment for wider testing various features that will be tested in for multiple days.
when the constraints are relaxed. the next phase.
This is the phase where we believe we
This phase continues as long as the
Phase 3: Coverage-driven testing have found and fixed most bugs and
design is unstable. Designers are on the
Finally as the design reaches a fairly bug finding rates are in single digits
critical path spending much of their
stable stage and all of the obvious bugs per week. This is also the point where
time fixing bugs.
have been eliminated, it’s time to go typically we are running short on time,
Even though coverage is not required, after corner case behavior and difficult as tape out is looming just around the
implementation of coverage points can to find bugs. It’s critical to start tracking corner. The goal is to get to zero bugs
proceed and some coverage metrics can full coverage at this stage. The testing while pushing coverage numbers higher.
be collected if resources are available. is now driven by coverage or more Regressions are being run and catego-
While running coverage gives some appropriately coverage “holes”. The rized by coverage.
sense of progress on the quality of coverage holes drive the next set of
At this time coverage goals can easily
tests, its value at this stage is somewhat modifications in constraint programming.
become a victim of the schedule at the
limited and therefore can be easily
In the past, the rate at which bugs are same time as they are most important!
deferred if need be.
found has often been the primary tape Priority and weighting in the verifica-
Phase 2: Bug-driven testing out criteria. But severe consequences tion/coverage plan may be reviewed
As the testing proceeds we enter a result from bugs in untested parts of and reassigned if necessary. If original
phase where a broader stimulus gener- the design; Bug rate is only meaningful goals are curtailed, quality is most likely
ation capability becomes important. if you have achieved coverage goals. compromised leading to higher risk of
Even though the design is relatively Reaching the coverage goal is a critical costly re-spins.
stable, and regardless of whether it is a part of the functional closure for any
How Unified Coverage helps
design block, subsystem or full system project. Typically, project goals will
Synopsys and other vendors have pro-
that is under test the sheer number of include functional coverage (features,
vided tools and capabilities that can
test conditions spread across an entire protocol, stimulus, assertion) and code
generate coverage information. They
farm leads to the discovery of many coverage (line, state machine, condi-
can monitor and collect data on execut-
new bugs. A slight tweaking of tests tional, and path).
ed design code, exercised design fea-
and constraints can lead to the discovery
At this time, the volume and variety of tures, triggered assertions, exercised
of new sets of bugs. This is also when
coverage data coming from the many bus protocol transactions, and executed
verification IP adds high value by stimu-
parallel verifications running across a testbench code.
lating the design interfaces with widely
regression farm can be overwhelming.
varied traffic and testing their response Synopsys enables multiple views of
The need for a tool to help analyze
to protocol errors. coverage to be viewed together
coverage data is tremendous. A uni-
through the VCS unified coverage
Coverage point implementation as well fied coverage view can help with a
report generator (URG). URG gener-
as tracking of coverage metrics should comprehensive view of the progress
ates unified reports with code, asser-
ramp up during this phase. Although and completion. This is discussed in
tion and functional coverage. The views
not critical, coverage is becoming more detail as part of the final step of
that are supported are
important late in this phase. It is impor- verification.
tant at this time to make sure that the • Design Hierarchy
Step 4: Perform regressions to
testbench is able to generate tests for • Module Lists
achieve functional closure
all possible configurations and that
In this final step, verification is graded • Cover Groups
there is coverage of the stimulus. This
on comprehensive views of coverage
makes it easier to track and modify • Dashboard – overall summary
over multiple tiers of regressions. Some
stimulus generation.
Figure 3 shows the Design Hierarchy In this step, the regression suite also modern verification technologies and
view of a URG report. At the left is a evolves and matures as a qualification methodologies that make more effec-
customized score number based on suite for tape-out of the design. The tive use of available resources such as
assigned weights to various types of tests are graded and those with higher engineer’s time and simulation farms.
coverage used. The support for code coverage in shorter run-time are
It presented the important concepts of
coverage, assertion coverage and func- retained for the qualification regression
architecting a verification environment
tional coverage is provided. The other suite. This allows any last minute
to leverage pre-verified VIP and the
views that are available help engineers changes to the design to be optimally
power of constrained random simulation
and managers with comprehension. regressed before the design is
using an object-oriented testbench to
released. The metrics collected during
This provides a comprehensive view of provide better control and more reuse.
the verification process, which include
coverage and helps correlate the results
data on bug rates, the number of ran- It discussed the importance of cover-
with the project tape-out targets. The
dom cycles, and coverage statistics has age to provide a better understanding
real benefit is that enormous amounts
helped numerous customers achieve of how effectively the design is being
of data from multiple sources have
successful tape outs. verified, and tool capabilities that aid in
been filtered and integrated to focus
visibility of coverage leading to
attention on achieving functional closure. Summary
improved predictability and increased
While engineers focus on improving This paper focused on practical aspects
confidence at tape-out.
coverage on various design modules, of the verification process that can
the project manager can make plans help accelerate functional closure. It is
to optimize and focus resources and based on Synopsys experiences of About the Author
apply testing efforts where the need is working directly with many leading-edge Neill Mullinger, Synopsys
most critical. semiconductor companies implementing
Neill Mullinger is a Group
Marketing Manager at
Synopsys. In this role he focus-
es on verification IP and
methodology support, including
responsibility for Synopsys PCI
Express Verification IP. Neill joined Synopsys in
2000 and has over 20 years experience in the
hardware and EDA industries, bringing an extensive
background of verification experience to product
and methodology definition. Previous to Synopsys,
Neill was employed at Mentor Graphics, where he
held positions as an applications engineer and as a
marketing manager.
Hemendra Talesara, Spansion
Hemendra Talesara is a Sr.

MTS in the Media Storage
Division of Spansion, LLC. He
is leading efforts on systems
architecture modeling, analysis
and performance validation.
He has an MSE from the
University of Texas at Austin, is
a certified project manager and has over 20 years
of experience in developing and deploying advanced
verification methodologies for Processors, ASIC,
and SoCs. He has authored numerous papers,
articles, and case studies on state of the art verifi-
cation technology and methodology.
Figure 3: Coverage Design Hierarchy View
concepts synopsys
Using Unidirectional Constraints
to Break Constraint Loops
Albert Chiang, Synopsys, Inc.
array means that both the content
and length of the array is randomized.
Here is a sample using the OpenVera®
or in more clear form:
len
language:
Constrained random stimulus genera- class Packet {
tion is a key component of many mod- data[tmp] ——> data.size()
ern verification environments. This rand reg [7:0] data[$];
approach uses a constraint solver to rand integer len; The constraint solver engine is simulta-
automatically generate interesting and constraint cons_1 { neously solving for elements in array
valid stimulus that otherwise may not data.size() == len; “data”, but it cannot do that until the size
have been thought of and created dur- len > 3; len < 10; of array “data” is known. The size of
ing directed test writing. Constraint foreach(data,tmp) { array “data” is controlled by variable “len”.
solvers use sophisticated mathematical data[tmp] == len; A loop is formed when 1. elements of
algorithms to find possible solutions } the array needs to solved simultaneous
for a given set of constraints, while at } to 2. the size of the array. The solver
the same time minimizing bias (i.e. a } engine detects the loop, preserves the
skew in the distribution of random program main { previous value of data.size() to 0 (instead
solutions) when picking values from of randomizing it), and produces the
the solution space. Packet p; error message seen above.
The constraint solvers built into the p = new(); To break the loop, a unidirectional con-
VCS® functional verification solution void = p.randomize();
straint can be written to break the loop
can handle large constraint sets, even }
between elements of array “data” and
those with thousands of constraints the size of the array defined by “len”.
and variables. The VCS solvers If we run the simulation, you will see
The unidirectional constraint will guide
process all constraints in parallel, using this run-time error message when class
the constraint solver engine to solve
a technique called “bi-directionality”. Packet is randomized.
for a random variable first before
This approach enables VCS’ solvers to The solver will not solve for data.size() because solving the other random variable. The
avoid spurious constraint failures and it is either unconstrained or has a bi-directional unidirectional constraint construct is void
to minimize bias, common problems dependency with a variable that is indexed by a or solve-before-hard:
associated with solvers that use a loop variable, which cannot be broken. As a
result, the solver will preserve the original value class Packet {
serial approach.
of 32'h0 for data.size()data.size() = 32'h0 rand reg [7:0] data[$];
There are times when constraints are
rand integer len;
written such that unsolvable loops are What is happening here is that the con-
unintentionally created. A loop is created straint solver will solve simultaneously for: constraint cons_1 {
when random variable A needs to be data.size() == len;
solved before random variable B, but 1. len len > 3; len < 10;
random variable B needs to be solved foreach(data, tmp) {
2. data.size()
before random variable A. // solution 1 – using void
3. data[tmp]
In order to break this loop and find a // solve for len first to break the loop
solution, hints can be provided to the If a diagram is drawn to show the rela- data[tmp] == void(len);
constraint solver. In VCS, hints are pro- tionship between these three random
variables, it will look like this: // solution 2 - using solve before hard
vided via a unidirectional constraint (void
solve len before data[tmp] hard;
or solve-before-hard). Here is an example: len <—--—> data.size() data[tmp] == len;
Let's say that you want to create a data[tmp] <—--—> len }
data[tmp] —--—> data.size() }
Packet class that contains an array of
random bytes (called data). A random }
With the use of the unidirectional con-

straint, the loop is now broken between
len, data[tmp], and data.size():
len
data[tmp] ——> data.size()
With the loop broken via a unidirectional

constraint, the constraint solver engine
will produce a valid output. For example:
data[0]=6 data[1]=6 data[2]=6 data[3]=6
data[4]=6 data[5]=6
The constraint solver in VCS is a pow-

erful feature that enables testbench
authors to create complex constraint
sets with full confidence that they will
be solved quickly and efficiently during
simulation. Unidirectional constraints
can be used to break inadvertent,
unsolvable constraint loops.
For more information about using
unidirectional constraints, please go to
https://solvnet.synopsys.com
For VCS NTB users, please refer to
$VCS_HOME/doc/UserGuide/NTB_lrm.pdf
For Vera users, please refer to
$VERA_HOME/doc?user_guide.pdf
About the Author

Albert Chiang, Synopsys
Albert Chiang is a Staff

Applications Engineer in the
VCS group, specializing in test-
bench technology. Prior to
Synopsys, he was a design
engineer at Intel and VLSI
Technology. He has a BSEE from California
State University.
concepts synopsys continued from page 1
today in the VCS® functional verification

common internal format. Then, the
combination of design, assertions, VIP
and testbench is compiled and optimized
• Simple usage model with no additional
switches or header file generation
required
solution. This important feature allows the together to generate the simulation • Integrated testbench and RTL debug
creation of SystemVerilog testbenches executable. This approach provides support
and verification environments incorporat- excellent simulation runtime perfor-
ing OpenVera components with no per- mance and fosters a high level of A key aspect of VCS’ mixed-HVL
formance impact. This paper also interaction among the elements of the support is that SystemVerilog objects
provides guidelines for continuing to verification environment. can instantiate and extend an
develop or upgrade OpenVera verification OpenVera object and use its data
The OpenVera-SystemVerilog interop- members and methods. This implies
assets to allow full and easy interoper- erability feature of the VCS solution
ability with SystemVerilog. that objects can be passed freely
offers the following capabilities: between the two languages. Objects
OpenVera/SystemVerilog • Existing OpenVera code parsed into created using OpenVera can be used
Support in VCS the OpenVera package and modified using SystemVerilog
Over the years, the VCS solution has code. Virtual methods in an OpenVera
evolved from the highest performance • OpenVera code can be imported into
object can be extended in
Verilog simulator into a comprehensive any SystemVerilog scope
SystemVerilog, effectively enabling
functional verification platform. The • SystemVerilog code can instantiate existing OpenVera code to execute
VCS solution now has built-in support OpenVera objects SystemVerilog extensions.
for code coverage, assertions, functional
• SystemVerilog classes can inherit No syntax extensions to either the
coverage, OpenVera testbench constructs
from OpenVera classes SystemVerilog or OpenVera languages
and SystemVerilog. This built-in support
means that OpenVera or SystemVerilog • No performance degradation compared are required to support this integration.
testbench code, assertions, and to a similar code structure implemented The classes from the foreign language
OpenVera-based or SystemVerilog- purely in SystemVerilog are simply imported using the
based VIP, including Synopsys’ VCS
Verification Library, are natively compiled
and optimized together with the design. OpenVera Code SystemVerilog Code
Since all design, testbench and VIP
code resides within the VCS solution,
integration is simplified and perfor-
mance is enhanced. OpenVera Parser SystemVerilog Parser
Because OpenVera and the verification
constructs of SystemVerilog have so
much in common, the VCS solution is
able to compile both into the same
Common Internal Format
internal representation using a common
code generation engine. This unique
native compilation process allows exten- VCS Code Generation
sive interaction and optimizations and Optimization
between both languages. This all hap-
pens without sacrificing ease of use,
debugging capabilities or performance. simv Executable
As shown in Figure 1, code from
OpenVera (testbench) and SystemVerilog
(testbench and design) is parsed to a Figure 1: VCS' built-in support for OpenVera and SystemVerilog
SystemVerilog import keyword. VMM share the same base infrastructure, In this trivial example, a transaction
the RVM-VMM interoperability feature descriptor “packet”, implemented in
import OpenVera::packet;
of the VCS solution offers the following OpenVera, is extended from the rvm_data
The interoperability feature of the VCS capabilities, transparently to the user: base class. A transactor, extended from
solution is enabled through a simple the rvm_xactor base class, produces packet
• Mapping of rvm_channel classes to
command-line argument. OpenVera instances on an output rvm_channel. A
vmm_channel classes, allowing RVM-
source files can then be specified like any SystemVerilog, testbench instantiates then
and VMM-compliant transactors to be
other SystemVerilog or Verilog source starts the RVM transactor. The generated
connected together.
file. The VCS solution uses the .vr, .vrh packets are received on a vmm_channel into
and .vri suffixes to identify source files • Mapping of rvm_data classes to a vmm_data variable and displayed by calling
expected to contain OpenVera code. vmm_data classes, allowing RVM- the vmm_data::display() virtual void function.
compliant transactions descriptors to The SystemVerilog testbench can use the
% vcs -sverilog -ntb_opts interop \
flow through VMM utilities. OpenVera RVM transactor and transaction
packet.vr tb.sv dut.v
• Mapping of rvm_notify classes to descriptor as if they has been written in
With this flexible and easy-to-use solution, SystemVerilog, using the VMM base classes.
vmm_notify classes, allowing synchro-
the VCS mixed-HVL solution enables
nization infrastructure and functional Verification IP
engineers to continue to use OpenVera
coverage model to work across The DesignWare Verification IP in the VCS
today, secure in their ability to preserve
RVM- and VMM-compliant transactors. Verification Library was designed to work
their investments in code and methodology.
VCS also allows verification groups to • Mapping of rvm_xactor to vmm_xactor, in an RVM methodology and provides the
start using SystemVerilog without risks allowing environments to identically scenario generators and transactors to
today, using a phased migration process manage VMM-compliant and RVM- significantly reduce testbench develop-
to suit internal project schedules. compliant transactors. ment time. The VIP transactors model
the behavior of a device on the bus or
VMM Methodology Support in VCS Consider the example shown in Figure 2: interface, and generate all of the transactions
The VMM methodology, defined in the and sequences that can be used
ARM-Synopsys Verification Methodology //OpenVera Code
Manual (VMM) for SystemVerilog, builds
class packet extends
on and extends the Synopsys Reference
rvm_data
Verification Methodology (RVM) used { //SV Code
with OpenVera. Both methodologies rvm_log log = new program test;
implement an equivalent Standard (“Packet Data”,
Library of utility and base classes that import OpenVera::*;
“Class”);
enable verification engineers to build pktgen g1 = new();
powerful verification environments rand integer
srce_port ; initial
much more rapidly.
rand integer begin
But, while the VMM base classes and dest_port; g1.start_xactor();
methods are identical to RVM’s, they rand reg payload[]; repeat (100) begin
are incompatible at the language level vmm_data tmpRvm;
virtual task
because each is a different data type. display(…); g1.out_chan.get (tmpRvm);
For example, from a pure language } p1.display();
perspective, it would not be possible ‘rvm_channel (packet)
to connect an OpenVera transactor
class pktgen extends
(expecting a rvm_channel) to a
rvm_xactor
SystemVerilog transactor offering a {
vmm_channel. To address this, the VCS packet channel
solution also offers methodology-level
interoperability. Because RVM and Figure 2: Methodology-Level Interoperability
throughout the breadth of the protocol. The

About the Authors
DesignWare Verification IP can be used in
a VMM methodology testbench that uses Janick Bergeron, Synopsys
either OpenVera or SystemVerilog. Janick Bergeron is a Scientist

within Synopsys’ Verification
Conclusion Group, where he helps define
the state-of-the-art in functional
The similar semantics of OpenVera and verification methodology and
SystemVerilog, and the integrated VCS the tools that support it. He is
the author of Writing Testbenches Using
verification platform create a unique SystemVerilog, co-author of Verification Methodology
opportunity for OpenVera users to leverage Manual for SystemVerilog, and the moderator of the
their verification assets when adopting Verification Guild. Prior to joining Synopsys, Janick
was the CTO of Qualis Inc. and a Member of
SystemVerilog. By offering a simple Scientific Staff at Nortel Networks. Janick holds an
mechanism where OpenVera code and VIP MBA from the University of Oregon, an M.A.Sc in
EE from the University of Waterloo and a B.Eng
can be transparently reused in SystemVerilog, from the University du Quebec a Chicoutimi.
VCS enables a smooth, high-perfor-
Shekhar Mahatme, Synopsys
mance adoption path for SystemVerilog.
Shekhar Mahatme joined
Synopsys ten years ago and is
currently a Senior Applications
Engineer with the Verification
Group. He supports the deploy-
ment of, state of the art func-
tional verification methodologies and tools. As a
verification and tool expert, Shekhar has success-
fully executed numerous verification projects and
technologies such as mixed signal verification,
mixed HDL simulation, VMM, OpenVera and
SystemVerilog testbench. Prior to joining Synopsys,
Shekhar was a senior member of Silicon Interfaces,
Inc., a design and verification consulting group.
Shekhar holds an M.S. in Electronic Engineering
from the University of Iowa and a B.S. in Electronic
Engineering from the University of Poona in India.
Alex Wakefield, Synopsys
Alex Wakefield is a Senior Staff

Applications Engineer with the
Synopsys Verification Group, who
specializes in verification tools
and methodologies. Since join-
ing Synopsys eight years ago,
Alex has consulted on multiple projects involving
Verilog, VHDL, OpenVera, SystemVerilog, C++ and
VMM. He holds bachelor degrees in both Electronic
Engineering and Science from the University of
Adelaide, Australia.
concepts synopsys
Combinational Equivalence
Checking for Retimed Designs
Robert Vallelunga, Synopsys, Inc.
correspond to each other. This is known
as the “matching” phase. The functional
equivalence of each matched compare
Reference
Reg_1
Unmatched
Matched
point pair is then proved or disproved. Out_1

Mike Tarsi, Synopsys, Inc.
When all relevant compare point pairs are
Equivalence checking is an important and determined to be functionally equivalent,
necessary step to verify the functional design verification succeeds.
Reg_2
correctness of a design’s implementation.
Retiming shifts registers across combi-
However, circuit retiming introduces changes Implementation
national logic to transfer the associated
that strike at the fundamental techniques
delay from a path with negative slack to Reg_1_2
used by combinational equivalency check- Out_1
a neighboring path with available slack.
ing technology. Retiming changes can
During synthesis, retimed registers can
make formal verification of large designs a
be moved either forwards or backwards
complex and often impossible task.
through logic. In many cases, the register
Formality® has developed a breakthrough Figure 3: Simple retimed circuit with
moves will result in forking (duplicating)
approach to verify the functional correct- logic cones highlighted
or combining registers. Figure 2 high-
ness of large retimed designs.
lights examples of register retiming. results in compare points that cannot
The Retiming Verification Problem Register classes, those with the same be matched between the two designs;
Combinational equivalence-checking clock/set/clear functionality, are denoted moreover, those that are matched may
(EC) tools verify whether two versions by class names C1, C2, and C3. G1 no longer be functionally equivalent.
of a design at different stages of and G2 represent combinational cells. When taken as a whole the design is
implementation are functionally equiva- functionally equivalent, but since the
Since the registers have been moved,
lent. The known functionally correct individual matched compare points are
added, and/or combined; retiming
design is referred to as the reference not, the verification will fail. This result
changes the number, structure, and size
design. The design being verified is referred to as a “false difference.”
of logic cones as well as the logic con-
against the reference is referred to as
tained within a given logic cone. Consider the very simple pre- and post-
the implementation design.
Changing the number of logic cones retimed circuit of Figure 3.
As an EC tool reads a design, it is seg-
mented into smaller components called Forward Retiming
logic cones. A logic cone is simply a set C3
C2 G2
of logic bounded by registers, primary C2 C1
G2
C3 C1
inputs/outputs, or black boxes (Figure

C2
1). Logic cone outputs are referred to C2 C1
G1 G1
as compare points.
C1 C1 C3 C1 C1 C3
After the designs are read, EC tools
determine which compare points in the Before After
reference and implementation designs
Backward Retiming
C3
Registers C2 C1 C3 C2 C1 C3
G2 G2
BB
C2 C1 C2 C1 C3
Logic G1 G1
Cone
C1 C1 C3 C1 C1 C3
Ports
Black Boxes BB
Before After Retiming G2 then G1
Figure 1: Logic cone Figure 2: Examples of Register Retiming
In this example, the EC tool will identify the reference and implementation start with function only. It will not need to be
logic cones as indicated. The reference different loops, they cannot be normalized implemented and in actuality is typically
design contains three logic cones that to a common structure. impossible to implement. If these two
can be identified by compare points Reg_1, boxes are connected in series, in either
A third approach, a guided approach, is
Reg_2, and Out_1. The implementation order, the function and its inverse cancel
possible if the retiming moves can be
design contains two logic cones identified each other out. By introducing this
recorded during the optimization process.
by compare points Reg_1_2 and Out_1. function/inverse combination into the
The record can then be provided to the
Compare points Out_1 will be easily designs we can maintain design func-
EC tool to guide it during the compare
matched between the two designs, but tionality and provide a solution using
point matching process. Unfortunately, the
the other compare points will not, pre- combinational equivalency checking.
EC tool cannot simply apply the moves to
venting a complete verification. Additionally,
one design in an attempt to create the
the matched Out_1 compare points are a a’
same state space. In RTL-to-gate verifi-
not functionally equivalent and the f(x) f’(x)
cations, the record defines moves made
verification will fail (a false difference). b b’
by synthesis after it elaborates the RTL
Traditional Retiming Verification into a gate-level representation. EC tools
Approaches have their own independent elaboration Figure 4: A “white” and “black” box
Sequential equivalence checking is one process. The elaborated RTL netlist with-
approach that may be used to verify in the EC tool may be structurally differ- The introduction of the white and black
retimed designs. Unlike EC tools that ent from that within the synthesis tool, box has the effect of creating additional
rely on one-to-one state point match- and it is not possible to simply duplicate compare points in both the reference
ing, sequential tools do not. Here the the retiming moves across registers from and implementation designs so that the
state space of a design is transformed a structurally different starting point. designs can be matched for verification.
while the behavior of the primary out- If verification succeeds, the retimed designs
Comprehensive Retiming Verification are sequentially equivalent despite the
puts remains the same. Sequential
To verify today’s large and complex combinational differences due to retiming.
equivalence checking is currently limited
designs, the only potentially compre- If verification fails, Formality will identify
to relatively small circuits and state
hensive and scalable solution is the the area in the implementation which
machines, and cannot be readily applied
guided approach. The recorded moves has caused the problem.
to large circuits where thousands of
can be used to define logical transfor-
retiming moves have been introduced. The following series of diagrams illus-
mations between the two designs, but
Another approach to verifying retimed new technology is required to understand trates Formality’s pioneering technique.
designs is to normalize both the reference how to apply the transformations. The Figure 5 shows the white box and black
and implementation designs into a standard Synopsys Formality equivalence checker box that are added to the retimed reference
canonical form. Once a standard form is has solved the problem and brought design found in Figure 3. The white box
obtained, the designs are then compared. retiming verification into the domain of represents the register-traversed logic that
This approach has been successful for combinational equivalence checking. was recorded during the retiming, in this
several classes of designs, including case an “or” gate. The black box represents
The solution centers on introducing the
pipelined multipliers, but it suffers from the theoretical inverse of the traversed
recorded transformations into Formality’s
two shortcomings. First, the normalization logic. The inclusion of these blocks has no
design representations without altering
process can be quite time consuming. net affect on the functionality of the design.
design functionality. To achieve this, two
Second, and more importantly, a single
new functional components are created Reference
canonical form for each design does not Reg_1
and are shown in Figure 4. The first, des-
always exist. Designs that contain loops
ignated the “white box,” contains the logic
of registers, where retiming has occurred
transformation as recorded during retiming.
somewhere along the path of the loop, is
The second, designated the “black box,”
a commonly occurring example. Registers
is an abstract representation whose function Reg_2
within these loops will remain throughout
is defined to be the “inverse” of the white Figure 5: Addition of traversed logic and
the normalization process. When the its inverse to the reference design
box. The “inverse” function is a theoretical
The next step is to recognize from the implementation design, no register shift applying the recorded information.
recorded information that a register is necessary since the register transfor- However, it should be sufficient to note
transformation occurred during retiming. mation was already accounted for in the that the gates contained within white
Reg_1 and Reg_2 have combined to representation of the reference design. boxes are always verified against original
form a single register. This combination logic. It is a complete contextual check
can be accomplished by pulling the Implementation and does not allow an incorrect trans-
register to the input of the black box. formation to generate a false equiva-
Figure 6 shows Formality’s resulting Reg_1_2 lence. Furthermore, the addition of the
representation for the reference design. white box and black box components
do not change the functionality of the
Reference designs. These components create
Figure 8: The new implementation compare points that allow Formality to
Out_1 design representation proceed with its task of verifying the
The new reference and implementation designs and presenting any functional
design representations can now be differences. If for any reason the
easily matched for verification as recorded information is incorrect, equiv-
Figure 6: Register is pulled through the alence checking would fail, and an error
black box shown in Figure 9.
would be detected by Formality. In such
Note that there is a direct relationship Matching logic cones cases, Formality’s Error-ID Technology
Reference will quickly isolate the problem to the
between the original (pre-application)
and new (post-application) RTL netlist logic within the white box.
representation. This is highlighted in Results
Figure 7. The new white box, black box, With this approach, Formality has been
and register collectively represent the able to extend the reach of EC technol-
footprint of Reg_1 and Reg_2 from the ogy to include retimed designs previ-
Implementation
original elaborated RTL representation. ously unsolvable. In addition, these
verifications have been accomplished
Pre-application Reference
efficiently. Table 1 illustrates a small
Reg_1
sampling of the results obtained using
Formality’s new approach.
Figure 9: New design representations Number of
are easily matched Test Compare Old Result New Result CPU (s)
Reg_2 Points
Though this is a trivial example, it 1 1863 False Difference Succeeds 14.29
Reg_1_D
undoubtedly highlights the technical 2 1093 False Difference Succeeds 12.68
Reg_1_Q
application. Consider if the OR gate 3 1670 False Difference Succeeds 32.10
had been optimized into a larger set of 4 403 False Difference Succeeds 6.43
Reg_2_Q neighboring logic or if the retimed 5 264 False Difference Succeeds 3.33
Reg_2_D
6 26242 Inconclusive Succeeds 487.78
registers numbered in the thousands.
7 8534 Inconclusive Succeeds 2025.00
Post-application Reference Such cases are not trivial, but Formality 8 128 False Difference Succeeds 2.47
will be able to verify the functional
Figure 7: Conceptual mapping between equivalence of the two designs. Table 1: Sampling of Retiming
original and new RTL Verification Results
Built-in Safety
Figure 8 illustrates the resulting It is beyond the scope of this paper to Conclusion
implementation design after applying provide the mathematical proof showing A record of retiming information gener-
the recorded information. Within the that no false equivalence can result by ated from Design Compiler enables
Formality to easily solve previously

unverifiable retimed designs. This capa-
bility allows users take full advantage of
Design Compiler’s timing optimizations
to maximize QoR without compromising
the ability to verify the design. Retiming
verification is available today to Synopsys
customers via Formality’s Guided Setup
flow (SVF).
About Formality
Formality is a full-chip functional
equivalence checker. With Formality’s
exhaustive static verification methodology,
designers can fully verify multimillion-
gate designs in relatively short times.
Formality’s industry-leading capacity,
performance, and completion make
Formality the customer-preferred EC
solution. Formality supports 32-bit and
64-bit platforms, is supported in all
major vendor flows, and is part of
Synopsys’ industry-leading, full-flow
design solution.
About the Author

Michael Tarsi, Synopsys
Michael Tarsi joined Synopsys

in 2004 as Senior R&D
Manager for Formality. Prior to
Synopsys, he has held various
product management positions
within Tera Systems, Mentor
Graphics, and Silicon Compiler Systems. He holds
an MSEE from Stanford University and a BSEE
from MIT.
Robert Vallelunga, Synopsys
Robert Vallelunga, Product

Manager, joined Synopsys in
2000. In his current role he
investigates and defines areas
of opportunity for verification
products. Vallelunga has
previously worked at Preview Systems as a Senior
Product Marketing Manager for software volume
licensing, at Mentor Graphics as a Product
Marketing Manager for design physical
implementation tools, and AMD as a Product
Engineer for microprocessor design. He holds a
BSEE degree from Arizona State University.
concepts partners continued from page 1
probe and debug. Each test took about

the Warp MD project, we needed a
new verification methodology to handle
the increased complexity of the design,”
through many interfaces, it was really
helpful to make use of constrained-
random verification in order to cover as
half a day for development, with about said Ross Video’s Simon Lacroix, the much access sequence and interaction
15 tests developed initially. hardware developer who managed both as possible without having to write a lot
design and verification on the project. of tests,” Lacroix commented. “In the end,
Additional time was required to diagnose
it saved a significant amount of time.”
lab failures. RTL bugs were routinely Although Lacroix’s team had not used
found during lab testing, after which a constrained-random verification previ- A New Approach
register dump of the FPGA was fed ously, they had studied the approach After an extensive evaluation to find
back into the simulator for diagnosis. and knew that it promised to be the the best verification language, tools and
Bug detection, diagnosis and process ideal way to address the verification methodology, the engineers at Ross
retesting would typically take between issues presented by the Warp MD Video decided to use SystemVerilog for
one and three days. On occasion, up to design. “I became convinced that this testbench automation with Synopsys’
40 such iterations were needed, so the was the right approach,” said Lacroix. VCS Native Testbench (NTB), and to
whole process could take up to four “Unlike in previous video processing implement the VMM methodology, doc-
months to complete. The iterative designs that were more datapath umented in the Verification Methodology
nature of this lab-based diagnosis intensive, this new chip was designed Manual (VMM) for SystemVerilog. They
process greatly reduced the pre- primarily for data transport using determined that the VMM methodology
dictability of verification schedules. proprietary protocols, and it was more provided a clean, modular and elegant
suitable for constrained-random tests.” approach to verification and that it
Constrained-Random Verification
could be quickly deployed.
The Warp MD design included signifi- Ross Video worked with both asynchro-
cantly more complex control logic nous and synchronous interfaces on “The VMM book provided good advice
than previous designs, presenting each DSP: a processor interface and a for setting up many aspects of the
both new challenges and new oppor- gigabit interface. “Since we had so many environment,” Lacroix said. “So we
tunities to the verification team. “For entities interacting with the FPGA decided to follow it extensively.” The
team quickly created a robust verifica-
tion environment utilizing the VMM
methodology’s built-in self-checking,
scenario generation, transaction-level
channels, transactors, and messaging
services. For checking, they also made
extensive use of SystemVerilog asser-
tions (SVA), both custom-written and
selected from the Synopsys SVA
assertion-checker library, and then
added functional coverage using
cover properties.
At first, about half of the bugs were
found in the verification environment
and half were found in RTL. It took
around three weeks to get the initial
verification environment running. The
Ross Video team initially had some
difficulty debugging the environment,
but the VMM methodology’s standard-
“Deciding to use the VMM methodology was the best thing we could have done” ized messaging service provided them
with a standard means of generating,

About the Author
formatting, and filtering messages that
enabled both design and environment Simon Lacroix, Ross Video
issues to be quickly diagnosed without Simon Lacroix is a hardware

developer at Ross Video who
having to use the waveform viewer. was the lead designer on the
Warp FPGA project. He has
Several of the design bugs found by been with the company for
the new environment were in very four years. Lacroix received a
Bachelor’s degree in Computer Engineering at the
complex arbitration logic that would University of Ottawa, Ontario, Canada.
have required extensive lab debug
About Ross Video
resolution time had a purely directed-
Ross Video designs, manufactures and supports a
test approach been used instead of wide range of innovative products for use in
assertions and constrained-random broadcast, distribution, live event and production
simulation. applications. Ross products are used to produce
and distribute video and audio signals in over 100
Lacroix commented that, “The previous countries daily. Ross’ award winning product line
includes the Synergy SD, Synergy MD and MD-X
testbench was not verbose with error Video Production Switchers, openGear, RossGear
messages, so it was hard to diagnose and GearLite Terminal Gear, Ross Routing Systems
and the OverDrive Production Control System.
the problem from the error message.
The VMM log file, on the other hand,
was very helpful in diagnosing errors so
that we could resolve issues quickly.”
In the end, the VMM methodology
helped the team create a good, well-
structured, scalable testbench, which
helped to make the verification process
more predictable. Even as new users of
constrained-random verification and
SystemVerilog, adopting the VMM
methodology allowed the team to finish
verification about a month ahead of an
already aggressive schedule. “Having to
create a framework like the one offered
by VMM from scratch would have
required a significant investment in time
that our schedule didn't allow,” Lacroix
noted. “The VMM provided us with a
good foundation and guidelines that, in
the end, made it possible for a small
design team such as ours to efficiently
move into a new methodology using
SystemVerilog. All that was achieved in
a reasonable timeframe. Deciding to
use the VMM methodology was the
best thing we could have done.”
concepts partners
Understanding the Key
Elements of a VMM-based
Testbench
VMM allows you to very quickly create
a testbench “with style”, even for a
novice user, as it starts with simple
The essence of verification through
simulation is to provide the design-
under-test (DUT) with stimuli, verify
TLM concepts and generators that the accuracy of the responses with
Ben Cohen, VHDL Cohen Publishing
are easy to use. However, during the respect to the requirements, and
Ajeetha Kumari, Contemporary
verification task the demands on the ensure that sufficient tests were per-
Verification Consultants
verification environment will be taxing formed. However, the problems tend
Abstract because additional tests, changes, to be more complex because the
This article identifies several key ele- configurations, monitor, and coverage architecture of a verification environment
ments of the VMM methodology for the will be required— it’s the nature of the is typically layered for easier decompo-
design of verification environment of beast! VMM is very rich in capabilities sition and control of the model, and
digital designs, including the communi- and is designed to easily adapt the includes several components that need
cation between verification components; modeling to meet those demands. In to communicate among each other, as
the generation of transactions with the course of writing our VMM adoption shown in Figure 1. The actions performed
atomic, or scenario generators; the book, we experienced and appreciated by these components include the
control flow of the environment; and the this flexibility and found it to be very generation of transactions with possible
customization for the logging of results. critical and essential for verification. constrained-randomization and scenarios;
This is what makes VMM unique, the channeling of those transactions
Introduction compared with other verification through the various levels of hierarchy
Why is the VMM methodology an methodologies that support only a for decomposition of those transactions
excellent framework for verification of simplistic implementation, thus burdening (needed for complex models); the
digital designs? Is it because VMM is: the user in creating much more code decomposition of the transactions to
• Transaction-based to support the requirements of the DUT driving signals; the injection of
advanced verification. We have found error by the DUT BFM; the monitoring
• Supported by several base classes
the VMM methodology to successfully of transpired DUT interface activities;
• Provides automation in the creation integrate industry best-practices, the scoreboarding and checking of
of channels, generators, and flow control allowing the user to concentrate on DUT responses and the coverage of
• Supports SystemVerilog and OOP verifying the design rather than fight- tests being performed. In addition to
ing the testbench. the inter-component communication
• Provides solid foundation for verification
Based on our positive experience with
the use of VMM, we believe that the
real answer to the question is not just Test Testcase A
for all of the above properties, but Constraints, Directed Stimulus
also because of the following addition- Generator

Scenario
al benefits:
Functional Coverage
High-level Transactions
• VMM provides documented techniques
suitable for a wide variety of application Functional Driver Self Check Monitor
domains and use models.
Atomic Transactions
• It helps to create a reusable and Checker Checker
Command Driver Properties Monitor
extensible verification testbench
that has a common look-and-feel 1s & 0s
across projects. DUT
Signal
• VMM scales nicely to meet the needs
of the verification tasks from simple
to very complex designs. Figure 1: Layered verification environment architecture
support, there is a need for a general- actor) puts a randomized transaction call another callback task to perform
ized test flow that controls how all of into a channel, which is a class that post analysis of the correctness of
these different components are built holds handles to transaction objects. the executed transaction through
and interact with each other in both Another transactor, such as a BFM, results obtained from the monitor; and
spatial and temporal contexts. can extract that transaction (via the send results of this analysis back to
channel peek() method); call a callback the generator though a notification
The VMM methodology gives great
to inject a possible exception (e.g., message or through a separate chan-
consideration given for reusability and
error); execute the (potentially modified) nel. That feedback can be used by
extensibility by providing for inter-
transaction per the protocol; call a the generator to reissue or modify the
component communication; the
callback task to perform coverage; original transaction if the protocol
generators of transactions with atomic,
scenario, or custom generators; the
control flow of the environment; and Component Communication Applications
the customizable logging of results. Virtual interface Connects to DUT.
This breath allows the user a choice
Channel Primary transaction and data interface mechanism used between
as to what is best for the task at transactors. Buffers a stream of transactions from consumers of
hand. VMM also defines a style in the those transactions. Allows parallel development of a complex
creation of testbenches including verification environment with little or no dependency between trans-
proper use of OOP, such as the actors. Used with broadcasters and schedulers to build complex
factory pattern, and the application of environments and TLMs.
assertions. Many of these topics are
Tee A task to retrieve a copy of the transaction descriptor references that
addressed in the following sections.
have been retrieved by the get() or activate() methods. Should be
Communication Techniques reserved for coverage measurement.
As shown in Figure 1, VMM recommends
Broadcast A transactor verification component. Enables a source channel to be
a well structured, layered verification broadcasted to multiple output channels. Can be used to model the
architecture with each component/layer packet generation from one central location and have it broadcasted
responsible for its identified functional- to multiple ports.
ity. For example, the generator layer
deals with details such as “how many Scheduler A transactor verification component. Enables the scheduling of multi-
ple transactions to a shared resource in a pre-defined or random
objects to generate”, the kind of
order. Scheduling mechanism can be round-robin or random. Can be
objects being generated etc. but not
used to mimic various scenarios, such as networking or multiple CPU
about who uses the objects down- resources accessing a common resource.
stream. This allows independent
development of these layers/components Notification An indication that a certain condition has occurred. Three notification
and also reduces interdependencies synchronization modes available to match specific needs. Enables the
among the various components thereby transfer of any associated status/data/ to another transactor with an
object derived from vmm_data.
easing maintenance. We will look at
some of the components later in this Callback Defines a set of methods that can be extended by the user to add
paper, and in this section let’s focus on functionality initially not defined by identifying “strategic” insertion/call-
how these layers communicate with back points. Can be used to inject errors; add a test; stretch a gap in
each other. the protocol; drop or delay a transaction; synchronize multiple genera-
tors; monitor coverage points; test the behavior of a hard to reach
Table 1 summarizes the various com- condition; add or save channel transactions for later reuse; provide
munication techniques and mechanisms information to scoreboards for verification; provide information to a
supported by VMM. This variety of debug interface for display of class variables in waveform viewer and
mechanisms allows the verification for computation of assertions based on those variables and on inter-
methodology to adapt to various needs. face signals.
For example, a generator (a.k.a. trans-
Table 1: The VMM methodology supports many communication techniques
requires such actions. Figure 2

represents a view of these communi- class S2p_xactn extends vmm_data;
cation paths. rand logic [31:0] pkt_pld;
rand logic err_pkt;
A transaction represents the job to be rand bit [7:0] pkt_length;
performed, such as Read / Write / time xactn_time;
packet length / data. Figure 3
represents a transaction for a serial to constraint cst_no_err_pkt {
parallel model. //err_pkt == 0;
} // cst_no_err_pkt
Transaction Generator
static vmm_log log = new("s2p_xactn", "");
In its simplest form, a transaction gen-
erator is a transactor that creates trans- function new();
actions as per the constraints of the super.new(this.log);
transaction descriptor class, and puts endfunction : new
the created transactions into an output extern virtual function string psdisplay(string prefix = "");
channel. Generators can be classified extern virtual function vmm_data copy(vmm_data cpy = null);
as: atomic, scenario, and custom. extern virtual function vmm_data allocate();
Atomic generator extern virtual function bit compare(vmm_data to,
Conceptually, an atomic transaction output string diff,
generator generates individual input int kind = -1
instances of a specified transaction );
endclass:S2p_xactn
class, and puts those instances into a
channel for consumption by another
transactor. This can be used to quickly Figure 3: Transaction model
create transactions in a testbench. The
fastest and recommended method to What is interesting about the created
to generate instances of the specified
implement an atomic generator is to atomic generator is that it is designed
class. Using the same style, channels
use the VMM macro: with several built-in features to support
are generated with the macro
`vmm_atomic_gen(class_name, Class_Description) `vmm_channel (transaction_class_name). reusability and extensibility. Specifically,
The macro creates an external class the atomic generator uses a factory
That macro defines an atomic generator declaration with the name pattern to adapt the use of the generator
class named <class_name>_atomic_gen <class_name>_channel. via the randomized_obj class property.
The generator also includes a “stop
after n transactions” control, and the
indication of a “DONE” notification
Monitor and (more than just a flag as it can have
Coverage data/status) after the generation of n
Transactors transactions. This notification can be
Transactions used by the environment to stop the
Interfaces transactors and proceed to the next
steps of verification.
Notification Callback Scenario generator
Unlike an atomic generator that gener-
Command ates individual random transactions, a
Generator
Channel Transactor scenario generator creates sequences
DUT made up of random atomic transactions
Figure 2: Examples of communication paths in a verification environment
organized to create a specific scenario. • It should allow constraints on the For example, `vmm_scenario_gen(S2p_xactn)
While the atomic generator creates a individual elements in the items so macro creates the required infrastructure
single object of the transaction, the that we can get to a final count given for a scenario generator. From a user
scenario generator creates a queue of a random starting point. perspective, it does the following:
objects of the transaction. Aside from
How can such scenario be generated • Creates a transactor named
this difference, the two generators are
using SystemVerilog? While there are S2p_xactn_scenario_gen — this is
very similar—they both send their output
several ways to achieve it, we will show the top level scenario generator for
to a single channel. Conceptually, a
a piece of code using iterative con- our design.
scenario generator imposes con-
straints. Figure 4 shows the simple • Creates a skeleton scenario class
straints on the individual transactions
code to achieve this. named S2p_xactn_scenario.
with reference to the previous (or
next) transactions. The code in Figure 4 describes just one • This scenario base class contains a
possible scenario. However, you typically SystemVerilog dynamic array named
The concept of creating a grammar-
need a set of such scenarios referred S2p_xactn_scenario::items[ ] of type
based scenarios with constraints seems
to as scenario_set[$]. The scenario_set[$] S2p_xactn.
strange, but after some experience
represents the set of available scenario
does make sense. Consider the verifi- • Declares a variable S2p_xactn_sce-
descriptors that may be repeatedly ran-
cation of a vending machine design nario::scenario_kind to identify the
domized to create the random content
that accepts the following coins: dimes, scenario.
of the output stream. VMM provides the
quarters and dollars. Let us assume
`vmm_scenario_gen pre-built macro to • Provides a mechanism to associate
that a soft drink costs $2. What are the
build a scenario generator. It is used with an unique identifier to a scenario via
possible input sequences (or scenarios)
the basic transaction class as an argument. S2p_xactn_scenario::define_scenario()
to get to a soft drink? Following are
method.
some of them:
typedef enum {DIME, QUARTER, DOLLAR} coin_t; Some of the key elements of the
• 5 Dimes, 2 Quarters and a Dollar
class Vend_inp_c; VMM scenario generator (called
• 2 back-to-back Dollars //Instantiate an array of items to be generated. S2p_xactn_scenario_gen in our
• 8 continuous Quarters rand coin_t items []; example) are:
// How many items? i.e. the length field
• 2 Quarters, a Dollar and 2 Quarters rand bit [3:0] length; • A single scenario is represented by
constraint cst_size { an array of atomic transactions. This
The above list is non-exhaustive, but it
items.size() == length; length > 0; is named as items[]. The length of
represents the kind of scenarios needed
solve length before items;} this array is user constrainable.
for verification. An atomic transaction
// Describe one scenario • Individual elements of this items
represents a single coin being constraint cst_2Q_1D_2Q_seq {
inserted —a Dime, a Quarter or a Dollar. array can be constrained using the
this.length == 4;
However, a scenario generator repre- SystemVerilog constraint block.
foreach (this.items [i] ) {
sents a sequence of coins being // i==0, i==1, 2 Quarters • In a system there can be many dif-
inserted, where the sequence satisfies (i < 2) -> this.items[i] == QUARTER; ferent scenarios. Every single sce-
a set of related constraints. Some of nario is of a unique kind and hence
the requirements for a scenario // i==2, 1 Dollar
needs to be identified with a unique
generator are: (i == 2) -> this.items[i] == DOLLAR;
// i==3, i==4, 2 Quarters ID referred as scenario_kind. When
• It should be able to generate a (i > 2 && i < 5) -> this.items[i] == QUARTER; this object is randomized, it selects
sequence of atomic transactions, } // foreach the identifier of the scenario that
called items. These items represent } // cst_2Q_1D_2Q is generated.
one single scenario for the user endclass : Vend_inp_c To create mixed scenarios, the VMM
(such as 2 back-to-back Dollars). scenario generator provides the follow-
The length of such a scenario should Figure 4: Scenario generator using ing infrastructure:
be constrainable. iterative constraints
• A SystemVerilog Queue of scenarios, • A generalized test flow segment program. Hence the top level testbench
scenario_set[$] that represents a set that controls how all of these different has essentially three components:
of scenarios, with each scenario con- components interact with each other
1. The SystemVerilog program that
taining a number of transactions. in both spatial and temporal contexts.
wraps the VMM environment
• A mechanism to choose one of the The structural segment of the environ- 2. The DUT instantiation
scenarios as the next candidate. This ment contains instantiation of various
is supported via an election class named verification components such as: 3. The Clock generators
<class_name>_scenario_election. The In a VMM testbench, a testcase is
default mechanism in VMM is round- • Transaction generators (Atomic or
Scenario) implemented inside a SystemVerilog
robin and user can choose a different program block. One of the benefits of
election scheme by overriding the • Functional transactors, if needed for using the vmm_env base class to
constraint inside this class if need be. the system to emulate hardware build a verification environment is that
resources not yet developed or to the sequencing of these individual
With this you can create a few scenarios
introduce higher abstractions (e.g., steps is maintained under the hood.
of interesting combinations, and have
mid-level protocol translator, image
them added to the scenario_set[$]
reformatter, etc.).
queue. You can have the election class
pick one of the scenarios as per a • Command level transactors — drivers Generate test
configuration gen_cfg()
pre-defined election policy. as well as monitor (a.k.a BFMs)
Custom Generator • Channels to hook up different trans-
Build the
A custom generator is a user-defined actors build()
environment
transactor that creates transactions to • Signal layer connections — via
meet specific needs, such as directed SystemVerilog virtual interfaces
Reset DUT reset dut()
tests that may be followed by con-
• Any reactive response generators
strained-random tests. VMM provides
(slave models) cfg_dut()
the facilities and guidelines to create a Configure DUT
custom generator. There are three • Scoreboards
important aspects of a basic transac- • Functional coverage unit Start transactors start()
tion generator: the transaction, the
channel, and the notification of comple- • Logger
No
tion. The transaction object must use a VMM standardizes the test flow and End of
factory pattern to determine the trans- recommends a nine-step sequence as Simulation
action object of choice. The channel is illustrated through a flowchart in Figure 5 reached?
local to the transactor. In the construc- along with the actual method names Yes
tor, that channel is associated with the being used in VMM. The VMM framework
environment channel, which is passed Stop transactors wait_for end()
automatically controls the sequencing
as an argument during the build step. of these steps needed to create the
The generator must provide a notification verification of the DUT. That framework Cleanup DUT/TB stop()
of completion through the use of the relieves you from the task to create
VMM notification services. this flow control. These steps are cleanup()
Report status
Control Flow implemented using SystemVerilog virtual
Broadly speaking, a VMM compliant methods as this allows you to easily
annotate and customize a given step Report status report()
verification environment consists of two
major segments: for your design.
THE END
• A structural segment that hooks up Once an environment is created using
different verification components, vmm_env, the last phase is to instantiate
that environment in a SystemVerilog Figure 5: Test flow of the environment
The user needs to only call the log message handler can be surprisingly simulator including log data, coverage
vmm_env::run() method and the test much larger than what it initially conceived. analysis flow, etc. A generic methodol-
sequencing will be automatically taken More often than not, every design team ogy, such as VMM, needs to cater to a
care of. Note that within the program thinks about such huge list of require- wide audience to be acceptable. One
block customization that reflects spe- ments, but given the amount of time it of the fundamental tools for a verifica-
cific testcases can be defined without would take to create such an infrastructure tion engineer is the simulation log
impacting the stable environment. and the effort to maintain it, this activity file. In our experience, a good 40%
Examples of customizations include a is put in the back burner and never gets of a verification engineer’s time is
change in the selection of transaction done. A significant advantage of the spent in analyzing the log file(s). This
subclass, the number of transactions VMM framework is that it already has a means that the format of log file that
to be executed, the registration or built in library to handle most of these displays the messages needs to be
exclusion of callbacks, etc. For exam- requirements (and much more). The base highly customizable.
ple, when the very first test is being class vmm_log is the VMM’s message
Typically users extract key information
run, you may prefer to have a fairly service that offers a very flexible and
from log files via PERL, UNIX-Shell
simple, directed-like test case with convenient way to handle the messages
script etc. Thus, while adopting or
only one transaction. This is easily in a simulation environment. Some of the
migrating to VMM, teams may want to
achievable in the VMM framework by key features of vmm_log are:
reuse their existing scripts and have
redefining the number of transactions
• Easy to use, pre-built macros to the log files produced in the format
from within the program, as shown in
hide the complexity and to present that their scripts expect. For example,
Figure 6.
users with a syntax resembling consider a sample VMM code:
Verilog’s $display.
`vmm_error(this.log, “Sample Error”);
program first_test(); • Consistency in message format
//the include files + log fifo_env_0 instantiations across the entire project. The default format of vmm_log is
`include "test.svh" spread across two lines in the output
• Customizable message format as shown Figure 7.
initial begin : b1 capability.
fifo_env_0.gen_cfg(); // from vmm_env::gen_cfg
// Override the number of xactions field • Promotion and demotion capabilities
!ERROR![FAILURE] on Pgm_Logger() at 1950:
fifo_env_0.test_cfg_0.no_of_xactions = 1; of the message severities — to turn
Sample Error!
// Do the rest of the flow as usual errors to warnings for example.
fifo_env_0.run(); • Tracking of the number of errors in
end : b1 Figure 7: Sample vmm_log with default
the system. This allows users to format
endprogram : first_test
react to a pre-specified error count
in order to avoid running a simula-
Figure 6: Redefining the number of trans-
While this 2-line format may be seen
tion beyond a certain number of
actions for simulation as useful by some, other design teams
errors (Such a run with 1000 errors
prefer to have every output message in
is often meaningless; a threshold of
Logging one single line. That eases post-pro-
10 is often a good choice to stop
A typical verification environment produces cessing of log files via commands such
the simulation).
significant amount of log messages to as UNIX grep etc. VMM allows the
inform the users about the progress and • Determines the PASS/FAIL condi- entire message to be customizable.
activities during a simulation run. Often the tion of a simulation run based on To be able to customize the message
messages are added by newcomers and error counts. format, you need to overload the virtual
a consistent style in printing the information Customizing VMM message output function format_msg in the
may not be followed. A consistent style format vmm_log_format class.
of message logging helps in extracting Almost every design verification team To have the output formatted in single
the needed information from a log file. has its own style preferences in line such as “1950.00 ns [*ERROR*:FAILURE]
The requirements for a comprehensive extracting information out of the | Sample Error”, you can use the
vmm_log_format::format_msg function
as shown in Figure 8. About the Author
Ben Cohen, VHDL Cohen
Publishing
class s2p_log_fmt extends vmm_log_format;
virtual function string format_msg( string name, Ben Cohen is currently a
trainer for the application of
string instance, assertions and VMM. He has
string msg_type, technical experience in digital
string severity, and analog hardware design,
computer architecture, ASIC design, synthesis, and
ref string lines[$]); use of hardware description languages for model-
ing of statistical simulations (with ECSS and
$sformat(format_msg, "%0t %s [%0s:%0s] |", Simscript), instruction set descriptions (with ISPS),
$time, name, severity, msg_type); and hardware models (VHDL, Verilog). He applied
VHDL since 1990 to model various bus functional
foreach (lines [ l ] ) models of computer interfaces. He authored
$sformat(format_msg, "%s %s", format_msg, lines[l]); VHDL Coding Styles and Methodologies, first and
endfunction : format_msg second editions; VHDL Answers to Frequently
Asked Questions, first and second editions;
endclass : s2p_log_fmt Component Design by Example; Real Chip
Design and Verification Using Verilog and VHDL;
and Using PSL/SUGAR with Verilog and VHDL.
Figure 8: Customizing VMM log messages He also co-authored Using PSL/Sugar for Formal
and Dynamic Verification, 2nd Edition;
SystemVerilog Assertions Handbook (also translat-
A single derived class can alter the ed to Japanese); and A Pragmatic Approach to
message format of all vmm_log VMM Adoption.
instances in the environment; this is very
convenient for design teams to customize Ajeetha Kumari, Contemporary
Verification Consultants
all log messages from a single place.
Ajeetha Kumari is running a
Conclusion Bangalore-based Verification
Consultancy firm named
We have found the VMM methodology Contemporary Verification
to provide a robust foundation for the Consultants (CVC), and con-
sults for various customers on high end verifica-
verification of digital designs, providing tion methodologies and languages. CVC offers
the techniques and building-block corporate and educational training in areas such
libraries suitable for a wide variety of as VHDL, SystemVerilog, SVA, PSL, VMM, etc.
She co-authored the following books: Using
designs and usage models. With the PSL/Sugar for Formal and Dynamic Verification,
VMM methodology, users can rapidly 2nd Edition; SystemVerilog Assertions
Handbook; and A Pragmatic Approach to VMM
create a reusable and extendable Adoption. Her interests include front-end design
verification environment with a common and verification methodologies including the appli-
cation of VMM. She has also been involved in
look-and-feel across projects, while EDA tool evaluations. She has experience with
improving verification productivity for several HDLs and HVLs including Verilog, VHDL,
both simple and complex designs. SystemVerilog, PSL, SystemVerilog Assertions and
Vera. She currently maintains a Verification centric
web site. She received her M.S. in Electrical engi-
neering from the prestigious Indian Institute of
Technology (IIT), Madras and Bachelors from
TCE, Madurai.
q&a
Questions & Answers
How do I enable the X-tracing

create a merged coverage database you
can use following commandline
Q feature in DVE?
% urg -dir simv.cm -dbname mydir/merged -noreport
The merged database will be created under
A To show a design or path schematic,

turn on the value annotation in the
schematic, select a signal that has the
'mydir/mydir.cm/coverage/verilog/merged.*
The option ‘-noreport’ tells URG not to
value “X” and call the menu “Trace X”. generate reports, but to create a merged
The use algorithm is not based on active database only
driver or driver technology, is an algo-
How can I view my MDA’s
rithm for gate-level. It traces from the
output all inputs that are “X”. It stops if
no input is “X” anymore. It’s done on the
Q (Multi-Dimensional Array) in
DVE? I have a $vcdplusmem call in my
full fanin cone. source code already, and my MDA’s
don’t show any data in the waveform
Can I generate a text-based window. (I am running my simulation
Q report with the Unified Report
Generator?
in batch mode.)
A There are two solutions.
A The default reports in URG are in

html. However if you are interested
in generating text based report, you can
Solution1: If you are generating a vpd
file in batch mode and then opening
do so by passing “-format text” to URG this file in DVE, you will need to add
command line. This generates text report $vcdplusmemon() call in your code.
instead of html report.
Solution2: Instead of adding the
%urg -dir simv.cm -format text <other optional $vcdplusmemon() call in your code, you
arguments> can enable dumping using the UCLI
(unified command line interface)
Can I merge groups of coverage
Q data and save them, so they
can be used for final merging at a
% simv -ucli
# At UCLI prompt issue
later point of time? ucli% dump -file vcdplus.vpd # the file to
dump the MDA's is called "vcdplus.vpd"
ucli% dump -add / -aggregates # dump entire
A You can merge the coverage data
from a group of tests and save them
in an intermediate coverage database. It is
hierarchy, including MDA's
ucli% run # run the simulation
not necessary to store the individual test
coverage data anymore. At a later point Now the vcdplus.vpd file will contain values
of time, you can merge this intermediate for your MDA’s and you can open this
coverage database with other coverage file in DVE.
data to create a final report. However,
once you merge the coverage data from
tests to create a intermediate database,
you lose the coverage data per test basis.
For example, if you have run a set of
tests with code coverage, and want to
news and events

Calendar
Customers are encouraged to register for any of the upcoming events.
Event Dates
2006 CS Week November 12-14
San Antonio, TX
Interoperability Developer’s Forum November 19th
Santa Clara, CA
IP/SoC 2006 December 6-7
Grenoble, France
Electronic Design and Solutions Fair 2007 January 25-26
Kanagawa, Japan
SNUG Israel February 14
Israel
DVCon 2007 February 21-23
San Jose, CA
SNUG San Jose April 2-4
San Jose, CA
DATE 2007 April 16-20
Nice, France
DAC 2007 June 4-8
San Diego, CA
news and events

Training
SYNOPSYS CUSTOMER EDUCATION
SystemVerilog Testbench
In this intensive, three-day course, you will learn the key features and benefits of the SystemVerilog test-
bench language and its use in the VCS® functional verification solution. You will learn how to develop an
interface between the SystemVerilog test program and the Device Under Test (DUT), while using intuitive
object-oriented technology in SystemVerilog testbench. This course concludes with an in-depth discussion
of functional coverage including a uniform, measurable definition of functionality and the SystemVerilog
constructs that allow you to assess the percentage of functionality covered.
Dates: October 24, 2006 - October 26, 2006
To register, please visit http://synopsys.com/support/support.html
VERA I
This course is a hands-on workshop that re-enforces the verification concepts taught in lecture through a
series of intense labs. At the end of this class, students should have the skills required to write an object-
oriented OpenVera testbench to verify a device under test with coverage-driven random stimulus using
VCS and Vera®.
Dates: October 31, 2006 - November 2, 2006
To register, please visit http://synopsys.com/support/support.html
UNIVERSITY OF CALIFORNIA EXTENSION, SANTA CRUZ (UCSC)
VMM for SystemVerilog Workshop

The Verification Methodology Manual (VMM) for SystemVerilog addresses important aspects of structured
verification development for today's chip and system designs. This workshop explores key benefits and
other important aspects of structured verification methodology and practices embedded in the VMM for
SystemVerilog. You will be introduced to the methodology and strategy for building reusable verification
components and structured verification environments.
Topics Include:
• Verification planning and goal setting
• High-level structures for building a generic verification environment
• Object-oriented test-bench partitioning, interface definition, and encapsulation
• Constrained-random stimulus generation
• Coverage-driven verification
• VMM standard library base classes and checker library overview
Dates: November 11, 2006
To register, please visit http://www.ucsc-extension.edu/ucsc
news and events

Training
Digital Design Functional Verification, Advanced
This course explores key benefits and important aspects of the unified verification methodology and
verification practices developed by Synopsys and ARM in the Verification Methodology Manual (VMM) for
SystemVerilog and offers a structured blueprint and a consistent methodology for building reusable
verification components and complete verification environments. Concepts are reinforced by implementing
a VMM testbench for a digital audio application using VMM, SVTB, and VCS®.
Upon successful completion of the course, you will be able to manage or contribute to a functional
solution (either individually or as part of a team) to problems encountered on advanced verification
projects. You will be familiar with the key benefits of the VMM methodology.
Topics Include:
• Structural approaches to creating a generic verification environment
• Object-oriented test-bench partitioning, interface definition, and encapsulation
• Code reuse (commonality of objects within a single project or across projects)
• Establishing tangible milestones during test-bench development
• Constrained-random stimulus generation
• Coverage-driven verification
• Tests, generators, transactors, scoreboards, checkers, channels, callbacks
Dates: January 25, 2007 to March 29, 2007
To register, please visit: http://www.ucsc-extension.edu/ucsc
SILICON VALLEY TECHNICAL INSTITUTE

Practical Application of the Verification Methodology Manual (VMM)
Practical Application of the Verification Methodology Manual (VMM) is a two-day comprehensive train-
ing workshop that teaches how to write a SystemVerilog transaction-based testbench compliant to the
Verification Methodology Manual for SystemVerilog (VMM) by Janick Bergeron, et. al. The VMM provides
the details of a powerful methodology, but the VMM is not a tutorial. This workshop fills that gap,
teaching how to apply the VMM concepts in a practical, realistic design environment. A FIFO design
and a serial-to-parallel design are used to illustrate using the VMM methodology for the creation of a
comprehensive constrained random verification environment. Labs reinforce these VMM concepts.
Students receive a comprehensive training guide that will serve as an invaluable aid in applying the
concepts in the VMM.
Dates: October 26, 2006 – October 27, 2006
news and events

Recommended Reading
The Art of Verification with SystemVerilog Assertions (SVA) NEW!
by Faisal I. Haque, Jonathan Michelson, Khizer A. Khan
The Art of Verification with SystemVerilog Assertions teaches the SVA language
and its usage with both simulation and formal verification (model checking).
SVA syntax and features are explained in simple and very easy-to-understand
language. The usage of Booleans, sequences, properties, and assertion layer
directives are illustrated with both simple examples and examples drawn from
common verification problems.
After SVA syntax and semantics are covered, assertion-based verification techniques are explained,
as are model-checking techniques. Covered subjects include where to add checking and coverage
assertions, who writes assertions, assertion libraries, and assertion-coding guidelines. These tech-
niques are used to develop an effective, SVA -based verification strategy for a real-world design.
A Pragmatic Approach to VMM Adoption

by Ben Cohen, Srinivasan Venkataramanan and Ajeetha Kumari
VHDL Cohen has published A Pragmatic Approach to VMM Adoption by verifi-
cation authors Ben Cohen, Srinivasan Venkataramanan and Ajeetha Kumari.
This book is intended to help design and verification engineers come up to
speed in the design of SystemVerilog transaction-based testbenches that
comply with the Verification Methodology Manual (VMM) for SystemVerilog. It will
help users adopt, with complete, compilable, and executable examples, the
VMM methodology in the creation of comprehensive constrained-random and directed verification
environments using a transaction-level modeling approach.
SystemVerilog for Verification

by Chris Spear
This book is an introduction to the testbench features of the SystemVerilog
language. It is meant for anyone who knows basic Verilog (1995) and needs
to verify a design. SystemVerilog for Verification teaches the reader how to use
the power of the new SystemVerilog testbench constructs plus guidelines
explaining why to choose one style over another. The book clearly explains the
concepts of object-oriented programming, constrained-random testing, and
functional coverage.
Writing Testbenches Using SystemVerilog

by Janick Bergeron
This book offers a clear blueprint of a verification process that aims for first-time
success using the SystemVerilog language, presents many of the functional
verification features that were added to the Verilog language as part of
SystemVerilog, and introduces the reader to all elements of a modern, scalable
verification methodology. It is an introduction and prelude to the verification
methodology detailed in the Verification Methodology Manual for SystemVerilog.
news and events

Recommended Reading
Verification Methodology Manual for SystemVerilog
by Janick Bergeron, Eduard Cerny, Alan Hunter, and Andrew Nightingale
The VMM for SystemVerilog is a blueprint for verification success, guiding SoC
teams in building a reusable verification environment taking full advantage of
design-for-verification techniques, constrained random stimulus generation,
coverage-driven verification, formal verification, and other advanced technologies
to help solve their current and future verification problems. This book is also
available in Japanese: visit http://www.synopsys.co.jp/vmm-sv_japan/index.html for more information.
A Practical Guide for SystemVerilog Assertions

by Srikanth Vijayaraghavan and Meyyappan Ramanathan
SystemVerilog assertions (SVA) form a declarative and temporal language that
provides excellent control over time and parallelism. This provides the designers
a very strong tool to solve their verification problems.
SystemVerilog Assertions Handbook

by Ben Cohen, Srinivasan Venkataramanan, and Ajeetha Kumari
This book discusses the syntax of SystemVerilog assertions (SVA), their use in
simulation and formal verification, and their impact on verification methodology.
SystemVerilog for Design

by Stuart Sutherland, Simon Davidmann, and Peter Flake
This is the guide to using SystemVerilog for hardware and design modeling.
Emphasis is placed on the proper usage of these enhancements for simula-
tion and synthesis.
news and events

Documentation
Webcasts
SystemVerilog for e Experts
Faster Verification Performance with Synopsys' VCS Native Testbench and Reference Verification
Methodology
Introduction to SystemVerilog
Leverage Transaction-Level Modeling for your AMBA Interconnect-Based Design
Synopsys’ Comprehensive Full-Chip Verification Solution for Mixed-Signal
Technical Papers
SystemVerilog for e Experts
Transaction-Level Modeling: SystemC or SystemVerilog?
Five Vital Steps to a Robust Testbench with DesignWare Verification IP and Verification
Methodology Manual (VMM) for SystemVerilog
Advanced Techniques for Robust Testbench Development with DesignWare Verification IP and
Verification Methodology Manual (VMM) for SystemVerilog
Mixed-level Modeling Allows IC Virtual Prototypes
Verify More in Less Time with VCS
Algorithm to System-On-Chip Design Flow that Leverages System Studio and SystemC 2.0.1
Verification Methods Applied to the ST Microelectronics GreenSIDE Project
Attacking the Verification IP Challenges
Discovery AMS White Paper
Assertions in SystemVerilog: A Unified Language for More Efficient Verification
SystemVerilog: A Synthesis Perspective
SystemVerilog Assertions Unify Design and Verification
Discovery Verification Platform Data Sheets

DesignWare Verification IP AMBA RTL On-Chip Bus Data Sheet
DesignWare Verification IP AMBA SystemC On-Chip Bus Data Sheet
DesignWare Verification IP ARM 926 SystemC TL-Processor Data Sheet
DesignWare Verification IP ARM 946 SystemC TL-Processor Data Sheet
Discovery AMS
Comprehensive Mixed-Signal Verification
Formality Data Sheet
High performance equivalence checking for minimizing time-to-results
HSIM Data Sheet
Comprehensive simulation and analysis of high performance analog, mixed-signal, memory, and
system-on-chip designs including important post-layout effects.
news and events

Documentation
HSPICE Data Sheet
Golden accuracy circuit simulator
Leda Programmable Design and Code Checker Data Sheet
Programmable coding and design guideline checker that delivers full chip mixed-language (Verilog
and VHDL) capability
Magellan Data Sheet
Hybrid RTL formal verification product for finding deeply embedded bugs
NanoSim Data Sheet
Advanced circuit simulation/analysis tool for analog, digital and mixed-signal design verification
Pioneer-NTB SystemVerilog Testbench Automation Data Sheet
SystemVerilog testbench automation tool for use with popular VHDL and Verilog simulators.
System Studio Data Sheet
Architecture design and analysis at the system level
VCS Data Sheet
High-performance, high-capacity HDL simulation with native assertions, testbench and coverage
VCS MX Data Sheet
High-performance mixed-HDL simulation platform
Vera Data Sheet
Comprehensive testbench generation automation for block, module and system verification
News
October 2006
10/19 Synopsys Design Compiler Topographical Technology Accelerates Tapeout of 90nm
Multimedia Chip at ETRI
10/17 Synopsys Enhances Saber Simulator Integration with UGS Software Through Global UGS
Partner Program
10/17 Semiconductor Firms Collaborate with Synopsys to Validate New ATPG Technology
10/16 Synopsys Unveils New Breed of DFM Products to Solve Process-Related Variation Issues
at 45NM and Beyond
10/13 Hua Hong NEC and Synopsys Jointly Develop Reference Design Flow 2.0 (China
Distribution Only)
10/11 Exar Selects JupiterXT Power Network Synthesis to Achieve Optimized Power Layout
10/9 Synopsys Introduces ‘MinChip’ Technology Delivering Smallest Possible Chip Size for
Volume Applications
10/9 San Jose State University Receives Charles Babbage Grant From Synopsys and Intel
news and events

News
10/4 Synopsys and ARM Announce Immediate Availability of CCS Noise Models for ARM
Physical IP
10/3 Enterasys Adopts Synopsys’ VCS Native Testbench for Accelerated Verification Productivity
10/2 Displaytech Switches to Synopsys Design Compiler Tool for Next-Generation FLCOS
Microdisplays
September 2006
9/28 Synopsys Recognizes Engineers’ Technical Excellence with Best Paper Awards at SNUG
Boston Conference
9/27 Synopsys Triples Automatic Test Pattern Generation Performance for TetraMAX Test Tool
9/25 Synopsys and First Silicon Solutions Speed Development of Large PCI Express Designs
9/21 ADVISORY/Synopsys at Intel Developer Forum
9/20 Nikon and Synopsys Collaborate to Deliver Advanced DFM Lithography Solutions for 45nm and Below
9/20 Virage Logic Adopts Synopsys’ HSPICE Simulator as Golden Simulator for 65-nm Library Sign-off
9/19 Samsung Extends Use of Synopsys’ ALT-PSM Technology for Advanced SRAM ICs
9/19 Synopsys Donates Technology for Low Power Design to Accellera Standards Organization
9/13 Synopsys Releases Verification IP for the OCP Interface
9/11 Alchip Standardizes on Synopsys’ Galaxy Design Platform for 90-nm SoC Designs
9/8 Synopsys Appoints Joe Logan as Senior Vice President of Worldwide Sales
9/5 SMIC and Synopsys Deliver Reference Design Flow 3.0 for 90-Nanometer Designs
9/5 Synopsys Releases Mixed-Signal PHY IP for SMIC 130-nm Process
August 2006
8/28 Synopsys IC Compiler Enables Toshiba’s Tapeout of High-Performance 90-nm Consumer
Wireless Chip
8/21 Progate Adopts Design Compiler Topographical Technology for Faster Time-to-Results
8/16 Synopsys Posts Financial Results for Q3 Fiscal Year 2006
8/16 Synopsys Broadens DFM and TCAD Portfolio with Acquisition of SIGMA-C Software AG
8/2 ADVISORY: Synopsys Announces Earnings Release Date and Conference Call Information for the
Third Quarter Fiscal Year 2006
8/2 Synopsys Extends Liberty Modeling Standard to Enable Variation-Aware Design
news and events

Programs
SVP Café – SVP Café SM provides customers with the latest design flow and support information for
Synopsys tools from leading foundries and IP, library and ASIC/FPGA vendors.
SystemVerilog Catalyst Program

Synopsys' SystemVerilog Catalyst Program promotes the development and use of EDA tools, verification IP
and training services supporting the SystemVerilog standard for design and verification.
Synopsys in-Sync Program

Synopsys in-Sync® Program’s mission is to establish relationships with EDA vendors to identify, facilitate
and help develop optimal joint flows and solutions that result in improved tool interoperability and maxi-
mized productivity for our mutual customers. The in-Sync Program is for EDA Vendors ONLY.
Feedback
We welcome your comments and suggestions to improve future issues of Verification Avenue.
Subscribe, unsubscribe, or let us know what you think.

Va Vol6 Iss3 f6

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Va Vol6 Iss3 f6

Uploaded by

Copyright:

Available Formats

verificationavenue

SystemVerilog-OpenVera Moving to the Next Level in

A verification flow should be reusable Test

block level, sub-system, chip-level and

and be reusable on similar projects

VIP Transactor Self Check Checker

help assimilate the resulting data for DUT

Hemendra Talesara, Spansion

Hemendra Talesara is a Sr.

Figure 3: Coverage Design Hierarchy View

With the use of the unidirectional con-

data[tmp] ——> data.size()

With the loop broken via a unidirectional

The constraint solver in VCS is a pow-

About the Author

Albert Chiang is a Staff

concepts synopsys continued from page 1

today in the VCS® functional verification

throughout the breadth of the protocol. The

either OpenVera or SystemVerilog. Janick Bergeron is a Scientist

Alex Wakefield, Synopsys

Alex Wakefield is a Senior Staff

point pair is then proved or disproved. Out_1

inputs/outputs, or black boxes (Figure

Formality to easily solve previously

About the Author

Michael Tarsi joined Synopsys

Robert Vallelunga, Synopsys

Robert Vallelunga, Product

concepts partners continued from page 1

probe and debug. Each test took about

with a standard means of generating,

issues to be quickly diagnosed without Simon Lacroix is a hardware

also because of the following addition- Generator

requires such actions. Figure 2

How do I enable the X-tracing

The merged database will be created under

A To show a design or path schematic,

A There are two solutions.

A The default reports in URG are in

news and events

news and events

UNIVERSITY OF CALIFORNIA EXTENSION, SANTA CRUZ (UCSC)

VMM for SystemVerilog Workshop

news and events

SILICON VALLEY TECHNICAL INSTITUTE

news and events

A Pragmatic Approach to VMM Adoption

SystemVerilog for Verification

Writing Testbenches Using SystemVerilog

news and events

A Practical Guide for SystemVerilog Assertions

SystemVerilog Assertions Handbook

SystemVerilog for Design

news and events

Discovery Verification Platform Data Sheets

news and events

news and events

news and events

SystemVerilog Catalyst Program

Synopsys in-Sync Program

You might also like