Submission to DATE’03
A Tutorial Introduction
on the New SystemC Verification Standard
Cadence Design Systems, Inc.
Abstract
This paper describes how SystemC 2.0 and the new
SystemC Verification Standard provide a robust standard
for developing test benches and verification IP for SoC
designs. The new SystemC Verification Standard includes
features for verification, such as transaction recording and
constrained randomization, which facilitate stimulus
generation, visualization, debugging and analysis of a
simulation run.
1. Introduction
While the SystemC 2.0 standard [1,2] can be used to
perform basic verification of a design, the new SystemC
Verification Standard [3] improves the capability by
providing APIs for transaction-based verification,
constrained and weighted randomization, exception
handling, and other verification tasks. In this paper, we
provide an overview of the new SystemC Verification
Standard through an example of a transaction-based test
bench. The following aspects of the Verification Standard
are discussed:
• transaction-based verification
• data introspection
• transaction recording
• constrained and weighted randomization
• miscellaneous features of the Standard, such as HDL
connection and detection of bugs and exceptions.
The basic structure of a transaction-based test bench is
shown in Figure 1.
Figure 1: Transaction-Based Verification
A transaction-based verification methodology
partitions the system into transaction-level tests, transactors,
and the design [5,6]. Communication between the tests and
the transactors is done through task invocation, at a level
above the RTL level of abstraction. The communication
between the transactors and the design is done through
RTL-level signals.
Manipulation of high-level data types is an important
element in this approach. A data introspection facility in the
Verification Standard enables the manipulation of arbitrary
data types in a consistent way, including C/C++ built-in
types, SystemC built-in types, user-defined composite types
and user-defined enumerations. As a result, arbitrary data
types can be used in variable recording, transaction
recording, randomization, constraints, assertions, and other
high-leveling activities.
Another important aspect of transaction-based
verification is transaction recording. The transaction
recording facility in the Verification Standard allows the
user to capture transaction-level activities during
simulation. Through a callback mechanism, these activities
can be monitored by another SystemC module at run-time,
or they can be recorded into a database for visualization,
debugging, and post-simulation analysis.
On the other hand, randomization allows a large amount
of stimulus to be generated with less manual effort than
directed tests. In order to improve coverage and focus on
specific aspects of the design, constraints or weights are
typically used in randomization. While many existing test
benches may be using rand() from the C library to generate
a random integer, the Verification Standard supports
randomization of any data type through the use of the data
introspection facility. Boolean predicates can be used as a
constraint, and weights can be used as a distribution from
which values are selected.
To complete the flow in a typical design environment,
we envision SystemC test benches to be used for designs
written in Verilog or VHDL as well. The Verification
Standard provides a minimal set of HDL connection API to
enable this use model. The Verification Standard also
includes a debugging interface and an exception reporting
API to facilitate debugging using a C++ debugger and to
maintain a consistent way of reporting detection of design
bugs or test bench bugs in verification models. Because of
space reason, they are not described in this paper.
This paper assumes some basic knowledge about C and
C++. The classes and functions in SystemC 2.0 use the
prefix sc_, and the classes and functions in the SystemC
Verification Standard use the prefix scv_.
2. Transaction-Based Test Bench in SystemC
It is desirable to write a test bench at the transaction
level, since it captures the design intent and test scenarios at
the level at which the architect thinks. Such a test bench can
designtransactortest
signals
tasks
C. Norris Ip
ip@cadence.com
Stuart Swan
stuart@cadence.com