1. System Verilog Testbench Language David W. Smith Synopsys Scientist
This presentation provides an overview of System Verilog 3.1 testbench extensions
David Smith is a Synopsys Scientist in the Advanced Technology Group of Synopsys. He has been involved in System and Mixed-signal language development for the past 16 years. He has been a member of the IEEE , Verilog-AMS, and SystemVerilog committees. He is a founder of Analogy, Inc (now owned by Synopsys).
David W. Smith
Synopsys Scientist
Synopsys, Inc.

2. Sample SOC and Testbench
DUT
Testbench
Synchronous
Interface Boundaries
10/100M
Ethernet
External
Memory
AHB
APB
Ethernet
MAC
Memory
Controller
CPU
Core
1Gb
Ethernet
Ethernet
MAC
Serial
Ports
RS232 model
Ethernet
MAC
Parallel
Ports
10Gb
Ethernet
1284
model
Control
Logic
USB
Bluetooth
controller
USB model
Bluetooth
model
Proprietary
Bus Controller
Infrared
controller
Proprietary
model
IR device
model
At present, designers are incorporating multitude of functionalities into an SOC, thanks to advances in Integrated Circuits. This picture is a typical example of integrated ASICs that are being developed by system houses and semiconductor firms alike. Many of the component have become standard IP, such as USB/PCI/Ethernet, etc. however the major added value besides the software/firmware side, is the control/glue logic at the heart of the SOC.
The purple region represents the testbench environment with verification IP/bus-functional-models of the interfaces [standard or proprietary] are Instantiated within them. Typically activities from the interfaces are coordinated through the control and switching circuitry, it makes it very structured and controllable when the whole testbench and their associate modules interact at well defined boundaries, I.e, interfaces. These are usually synchronized signal boundaries with set bus protocols. It is beneficial if the bfm are developed in structured/layered way, with the lowest layer connecting through interface to the design.
Need to create complex test cases that generate real-life resource contention, resource saturation, aspect-sliding cases,multiple and concurrent end-to-end test cases, corner cases, random-test cases from all interfaces [concurrently]. Multiple independent test scenarios, embedded self-checking transaction and data validity as well as Assertions for protocol violations at the boundaries are basic elements of this overall testbench structure.
Take the Ethernet mac interface, the verification models link to the mac interface and take on a different clock domain, the base model is same and in fact can be an object which then uses inheritance to create the various modes.
In addition to the complexity of the design the languages used to describe the testbench and the design have historically been different.
PCI
Controller
Protocol Checkers
for Interface
PCI Model
5 December 2003
David W. Smith

3. System with Multiple SOC’s
Packet Switched Bus
FPU
Cache
Mem
CPU
AMBA
FPU
Cache
Mem
CPU
AMBA
FPU
Cache
Mem
CPU
AMBA
SOC 1
SOC 2
SOC 3
This is actually an abstract representation of a high-end multiprocessor system which was the driving force behind the formation of Vera.
Cache-coherent shared memory SMP system based on Packet-switched center-plane system bus
Multi-cpu, cache-coherent shared memory Symmetric Multi-Processor systems, with advanced arbitration mechanism and based on Packet-switched system bus, [many new interconnect busses are similar in nature today – HyperTransport, etc]. When we talk about each of the features, for example semaphore you can refer back to this and next picture and pinpoint the usage model. What is needed is at the boundaries, controllable and observable nodes within the system stimulus generated, data/address/control validity checked as well as assertion checkers for protocol correctness at each interface.
[ FOR DISCUSSION/REFERENCE ONLY
Testbench abstraction to model interface behavior and interactions for:
distributed arbitration mechanisms
Split transaction snooping protocol with no transient states
Large number of outstanding transactions: out-of-order completion
Dynamic memory modeling, and response/data checking.
Perform System-level, sub-system and chip-in-isolation tests.
Easily be able to start concurrent transactions with complete self-checking mechanisms
And of course develop Structured verification environment with underlying shareable and reusable/maintainable code
[FOR DISCUSSION ONLY: Of course you can notice that this is a huge system, with multiple boards, multiple ASIC and not practical to use entire system model.
Correctness of the system, need to check the closed-loop aspect: reply is returned within a reasonable time]
DUT
At System Level Problem is Exacerbated
Abstractions and Re-use are Necessary!
5 December 2003
David W. Smith

4. Testbench Requirements
Stimulus Generation
Directed, Random, ATPG, ...
Checkers
Data
Protocols
Structured Connection to Multiple Independent Interfaces
Interconnect
Clocking Domain
Protocol
Abstract Modeling
High-level data structures
Dynamic Memory
Memory Management
Re-entrant Processes
Inter-process Synchronization, Control, and Communication
Re-usability
Single language for design (HDL) and verification (HVL)  HDVL
Testbench development/modeling has become the central point in the simulation based verification of ASICs, SOC and digital Systems.
These complex SOC/systems with have multiple independent interfaces need smart stimulus generation and full self-checking mechanism as part and parcel of testbench component.
Model the real environment:
Bus Functional Models/Bus Transactor models
Inter-leaved transaction based model development.
Dynamic thread/process synchronization mechanism to allow Arbitration schemes and nodes, multiple serial and parallel transaction, out-of order execution, etc, modeling. [Mutual exclusivity constructs]
Connection at Observable and controllable interface
Create separate interfaces, use it for above modeling of protocol transactions and assertions generation.
Allow stimulus generation and self-check at all levels.
Reusable and highly structured code essential for testbench
[ ALSO MENTION verification IP by name and model synchronization.]
POINT -> This is what is collectively known as a Testbench!
5 December 2003
David W. Smith

5. Basic Types Strings Associative arrays Dynamic arrays Linked Lists
arbitrary and dynamic length
methods to manipulate and convert strings
operators for comparison, concatenation and replication
Associative arrays
Indexed by integer, string, or class
first(index), last(index), next(index), prev(index), delete(index), and exist(index) methods
Dynamic arrays
integer mem[*];
mem.size();
Linked Lists
doubly linked list of any data type
iterator, modification, access methods
Classes, Objects and Methods
Object Oriented
Encapsulation, Inheritance, and Polymorphism
Objects referenced with handles (Safe Pointers)
SystemVerilog has added a number of new capabilities that can be used for both abstract system modeling and for testbench development. Included are basic types such as strings, associative and dynamic arrays, linked lists, object orient objects defined using classes. Classes provide encapsulation, inheritance, polymorphism, and handles for objects (safe pointers).
Random variables and user-defined constraints have been provided in order to generate stimulus for the testbench.
Some other additions are wild-card equality/inequality operators to support matching with x and z acting as wildcards, pass-by-reference (for passing arrays, structures and objects efficiently), aliases for nets (within a given module) to “short” them together, and automatically managed memory support for dynamic objects.
5 December 2003
David W. Smith

6. Random Variables and Constraints
Test Scenarios
Valid Inputs Specified as Constraints
Declarative
Constraints
Constraints
Input Space
Valid
Design
Constraint Solver
Find solutions
5 December 2003
David W. Smith

7. Random Variables and Constraints
rand, randc, and constraint added to class definition
class Bus;
rand bit[15:0] addr;
rand bit[31:0] data;
constraint word_align { addr[1:0] == 2’b0; }
endclass
Generate 50 data and quad-aligned addresses
Bus bus = new;
repeat(50)
begin
integer result = bus.randomize();
end
5 December 2003
David W. Smith

8. Basic Additions Wild card operators (=?= and !?=) Pass by reference
Argument default values and pass by name
Alias for nets
Short nets in a module
Dynamic Memory
Objects, threads, strings, dynamic and associative arrays
Automatically Managed
Declaration: task tk( var int[1000:1] ar );
Use: tk( my_array ); // no & needed
Declaration: task foo( int j = 5, int k = 8 );
Use: foo(); foo( 6 ); foo( ,9 ); foo( 6, 9 ); foo(.k(9));
SystemVerilog has added a number of new capabilities that can be used for both abstract system modeling and for testbench development. Included are basic types such as strings, associative and dynamic arrays, linked lists, object orient objects defined using classes. Classes provide encapsulation, inheritance, polymorphism, and handles for objects (safe pointers).
Random variables and user-defined constraints have been provided in order to generate stimulus for the testbench.
Some other additions are wild-card equality/inequality operators to support matching with x and z acting as wildcards, pass-by-reference (for passing arrays, structures and objects efficiently), aliases for nets (within a given module) to “short” them together, and automatically managed memory support for dynamic objects.
5 December 2003
David W. Smith

9. Process Control/Synchronization
Verilog thread support from fork…join with continuation when all threads complete
SV threads use fork…join with continuation control
all
any
none
Threads execute until a blocking statement
wait for event, mailbox, semaphore, variable change, ...
Enhanced events (value and duration, passed as arguments)
Threads are controlled by
$terminate
$wait_child
$suspend_thread
$exit
all
any
priority
none
3.0 process
There are also some major additions to the language for managing threads or processes. This is can be used both for system design and for coordinating different threads within the test bench. Threads are implemented in Verilog using the fork....join command. Each statement can be viewed as a separate process or thread of execution.
The fork...join command has been enhanced to provide for three different ways for execution to continue after the fork...join command. The Verilog fork...join is the same as the fork...join all which requires all threads to finish before execution continues.
In SystemVerilog 3.0 the process command was added which is equivalent to the fork...join none with a single statement. The fork...join none creates the threads for each statement and then immediately returns.
In SystemVerilog 3.1 the additional ability has been provided to wait for any thread to return before continuing execution using the fork...join any.
Each of the threads will execute until a blocking statement is reached. Examples of blocking statements are wait for event (using the enhanced event support in 3.1 where an event has both value – on,off – and duration), mailboxes, semaphores, variable change , etc...
Control of threads has been provided using the $terminate, $wait_child, $suspend_thread, and $exit system tasks and statement.
5 December 2003
David W. Smith

10. Clocking Domain
A clocking domain defines a synchronous interface for testbench and properties
Every clocking domain has only one clock event
Sample and drive timing specified with respect to clock
A signal may appear in multiple clocking domains
Input - multiple samples
Output – default bus resolution
Clocking domain creates a scope
5 December 2003
David W. Smith

11. Synchronous Interfaces: Clocking
Race-free cycle and transaction level abstraction
device
bus
enable
full
clk
empty
data[7:0]
Synchronous
Interface
clocking clk);
default input #1ns output #2ns;
input enable, full;
inout data;
output empty;
output #6ns reset = top.u1.reset;
endclocking
Clocking Event “clock”
Default I/O skew
Hierarchical signal
The clocking domains defines a clock and the collection of input and output signals that are sampled and driven with respect to this clock. The signal is connected to a port in the program or a hierarchical reference to a signal anywhere in the design. The signal operations define how the signal in the design is sampled or driven from within the clocking domain.
The purpose of the clocking domain is to provide synchronous and race-free interfaces between the testbench and the design.
Testbench Uses:
bus.enable
bus.data
...
Override Output skew
5 December 2003
David W. Smith

12. Testbench Program Block
Purpose: contains testbench verification code
program is similar to a module
Only one implicit initial block
Special semantics
Execute in verification phase
design  clocking  verification  read_only
program name ( port_list );
declarations (class, type, function, clocking...)
statements
endprogram
The program block provides for the definition of the tests and how the tests interact with other program blocks and the device under test (the design). The program block can be considered to be a special type of module that can be instantiated with port connections. The program contains all of the variables, objects, procedural, clocking domains, etc required to define the test program.
5 December 2003
David W. Smith

13. System Verilog Testbench
Verification Extensions
Basic Types
Random Constraints
References
Aliases
Process Control/Synchronization
Testbench Specific
Clocking Domains
Program Block
By adding a number of new features to the SystemVerilog language the ability to model more complex systems has been extended.
Adding the testbench specific extensions and using them with the other new extensions provides for modeling complex and rich testbenches.
5 December 2003
David W. Smith