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 1076.1, Verilog-AMS, and SystemVerilog committees. He is a founder of Analogy, Inc (now owned by Synopsys). David W. Smith Synopsys Scientist Synopsys, Inc.

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

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

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

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

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

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

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

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

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

Synchronous Interfaces: Clocking Race-free cycle and transaction level abstraction device bus enable full clk empty data[7:0] Synchronous Interface clocking bus @(posedge 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

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

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