Introduction to SystemVerilog for Testbench
Agenda
2
Introduction
Methodology Introduction
Getting Started
Testbench Environment
Language Basics
OOP Basics
Randomization
Controlling Threads
Virtual Interfaces
Functional Coverage
Coverage Driven Verification
Testbench Methodology
SystemVerilog Testbench with VCS
05/07/2007
Lecture Objectives
3
By the end of this class, you should be able to:
Develop self checking testbenches using VCS and SystemVerilog
How to connect your Design to a SV testbench How to perform random constrained testing How to take advantage of powerful concurrency How to implement Functional Coverage
Look for coding tips!
SystemVerilog Testbench with VCS
05/07/2007
Introduction SystemVerilog for Verification
Based on IEEE P1800-2005 Standard
Detailed in Language Reference Manual Verification-specific language features Constrained random stimulus generation Functional coverage SystemVerilog Assertions (SVA)
SystemVerilog Testbench with VCS
4
Agenda
Introduction
Methodology Introduction
Getting Started
Testbench Environment
Language Basics
OOP Basics
Randomization
Controlling Threads
Virtual Interfaces
Functional Coverage
Coverage Driven Verification
Testbench Methodology
SystemVerilog Testbench with VCS
5
Verification Environment
6
Definitions
Checks correctness
Creates stimulus
Testbench Verification Environment
Test
Executes transactions
Transactor
Scoreboard
Checker
Driver
Assertions
Monitor
Supplies data to the DUT
DUT
SystemVerilog Testbench with VCS
Identifies transactions Observes data from DUT
Methodology Introduction
To maximize design quality
Provides guidance:
Find bugs fast! Identify the best practices Make the most of Synopsys tools
Methodology One verification environment, many tests Minimize test-specific code Reuse Across tests Across blocks Across systems Across projects
SystemVerilog Testbench with VCS
7
Methodology Introduction
Testbench Design
Start with a fully randomizable testbench
Then with minimal code changes:
Run many randomized simulation runs Analyze cumulative coverage and coverage holes Add constrained stimulus to fill coverage holes
Finally:
Make few directed tests to hit the remaining holes
SystemVerilog Testbench with VCS
05/07/2007
8
Coverage-Driven Verification
9
Measure progress using functional coverage
% Coverage
With VIP
Coverage-Driven Methodology
Productivity gain Directed Methodology
Goal
Self-checking random environment development time
Time SystemVerilog Testbench with VCS
05/07/2007
Key Benefits: Testbench Environment
Environment Creation takes less time
Testbench is easy constrain from the top level file
All Legal Device Configurations are tested
Regression can select different DUT configurations Configuration object is randomized and constrained
Enables reuse
SystemVerilog Testbench with VCS
05/07/2007
10
Agenda
11
Introduction
Methodology Introduction
Getting Started
Testbench Environment
Language Basics
OOP Basics
Randomization
Controlling Threads
Virtual Interfaces
Functional Coverage
Coverage Driven Verification
Testbench Methodology
SystemVerilog Testbench with VCS
05/07/2007
Getting Started
12
What are We Going to Discuss?
SystemVerilog Testbench Verification Flow
Compiling and Running in VCS
Documentation and support
SystemVerilog Testbench with VCS
05/07/2007
Getting Started
13
Compiling and Running with VCS
Compile: vcs -sverilog –debug top.sv test.sv dut.sv -sverilog Enable SystemVerilog constructs -debug Enable debug except line stepping -debug_all Enable debug including line stepping
Run: simv +user_tb_runtime_options -l logfile Create log file -gui Run GUI -ucli Run with new command line debugger -i cmd.key Execute UCLI commands
See the VCS User Guide for all options SystemVerilog Testbench with VCS
05/07/2007
Getting Started Legacy Code Issues
SystemVerilog has dozens of new reserved keywords such as bit, packed, logic that might conflict with existing Verilog code
Keep your Verilog-2001 code separate from SystemVerilog code and compile with: vcs –sverilog new.v +verilog2001ext+.v2k old.v2k or vcs +systemverilogext+.sv old.v new.sv
// Old Verilog-1995/2001 legacy code integer bit, count; initial begin count = 0; for (bit = 0; bit < 8; bit = bit + 1) if (adrs[bit] === 1'bx) count = count + 1; end SystemVerilog Testbench with VCS 05/07/2007
14
Debug: Getting Started
Invoke DVE
> simv –gui -tbug
Source code tracing
Active threads Local variables
SystemVerilog Testbench with VCS
15
05/07/2007
Getting Started
16
Documentation and Support
SystemVerilog documentation
Examples
Email Support:
http://solvnet.synopsys.com
Testbench Discussion Forum
[email protected]
On-line knowledge database
$VCS_HOME/doc/examples
http://verificationguild.com
SystemVerilog LRM
www.Accellera.org or www.eda.org/sv
SystemVerilog Testbench with VCS
05/07/2007
> vcs -doc
Agenda
17
Introduction
Methodology Introduction
Getting Started
Testbench Environment
Language Basics
OOP Basics
Randomization
Controlling Threads
Virtual Interfaces
Functional Coverage
Coverage Driven Verification
Testbench Methodology
SystemVerilog Testbench with VCS
05/07/2007
Testbench Environment
18
How Should You Connect to DUT
Someone gives you a DUT, now what?
reset request[1:0] grant[1:0] clock
arb.sv
SystemVerilog Testbench with VCS
05/07/2007
Testbench Environment
19
Steps to hook up a DUT to a Testbench 1. Create DUT interface with modports and clocking blocks 2. Create testbench program 3. Create top module 4. Compile and run
top.sv
test.sv
arb.sv
clock
SystemVerilog Testbench with VCS
05/07/2007
Testbench Environment -- Interfaces
20
Introduction
The complexity of communication between blocks requires a new design entity
An interface encapsulates this communication
Connectivity (signals) Directional information (modports) Timing (clocking blocks) Functionality (routines, assertions, initial/always blocks)
An interface can be:
Top level net-lists are too verbose and error prone
Connected at compile-time (default) Connected at run-time – virtual interfaces
An interface can not:
Be hierarchical, or extended Device 1
SystemVerilog Testbench with VCS
05/07/2007
interface
Device 2
Testbench Environment -- Interfaces Before Interfaces
The RTL code was connect with a netlist mem
cpu top
module mem ( input bit req, bit clk, bit start, wire [1:0] mode, wire [7:0] addr, inout wire [7:0] data, output bit gnt, bit rdy); … module top;
module cpu ( input bit clk, bit gnt, bit rdy, inout wire [7:0] data, output bit req, bit start, wire [1:0] mode, wire [7:0] addr); …
logic req, gnt, start, rdy; bit clk; always #10 clk = !clk; logic [1:0] mode; logic [7:0] addr; wire [7:0] data; mem m1(req, clk, start, mode, addr, data, gnt, rdy); cpu c1(clk, gnt, rdy, data, req, start, mode, addr); endmodule SystemVerilog Testbench with VCS 05/07/2007
21
Testbench Environment -- Interfaces
22
Named Bundle of Signals
The RTL code is connected with bundled signals
mem
simple_bus clk
cpu
top interface simple_bus; module mem( module cpu( logic req, gnt; simple_bus sb, simple_bus sb, logic [7:0] addr; input bit clk); input bit clk); wire [7:0] data; … … logic [1:0] mode; endmodule endmodule logic start, rdy; module top; endinterface logic clk = 0; always #10 clk = !clk; simple_bus sb(); mem m1(sb, clk); cpu c1(sb, clk); endmodule SystemVerilog Testbench with VCS 05/07/2007
Testbench Environment -- Interfaces
23
Referencing Signals in Interface
Use hierarchical names for interface signals in a module module cpu(simple_bus sb, input bit clk); logic addr_reg; always @(posedge clk) sb.addr 0 Your testbench will always drive the signals at the right time!
Functionality:
An interface can contain multiple clocking blocks There is one clock per clocking block. Default is “default input #1step output #0;” “1step” specifies that the values are sampled immediately upon entering this time slot in Prepone region, before any design activity
SystemVerilog Testbench with VCS
05/07/2007
26
SystemVerilog Scheduling
27
SystemVerilog Scheduling Details
Each time slot is divided into 5 major regions (plus PLI) Prepone Sample signals before any changes (#1step) Active Design simulation (module), including NBA Observed Assertions evaluated after design executes Reactive Testbench activity (program) Postpone Read only phase Assertion and testbench events can trigger more design evaluations in this time slot
clock data REGION
Prepone Active Observed Reactive Postpone
ACTIVITY
sample
Previous
Current
SystemVerilog Testbench with VCS
design assertions testbench $monitor Next 05/07/2007
Testbench Environment - Program Block Program Block
Benefits:
Encapsulates the testbench Separates the testbench from the DUT Provides an entry point for execution Creates a scope to encapsulate program-wide data
Functionality:
Can be instantiated in any hierarchical location
Typically at the top level
Interfaces and ports can be connected in the same manner as any other module Leaf node, can not contain any hierarchy, just classes Code goes in initial blocks & routines, no always blocks Executes in the Reactive region
SystemVerilog Testbench with VCS
05/07/2007
28
Testbench Environment – Program
Create testbench program: test.sv
program test(arb_if.TB arbif); initial begin // Asynch drive reset arbif.reset
