SystemVerilog 3.0d.VCS7.1 Beta

CUSTOMER EDUCATION SERVICES
System Verilog (VCS7.1B)

for Verilog users (v1.1B)
Workshop
Student and Lab Guide
50-I-051-XSLG-002
Developed and Presented By:

Willamette HDL, Inc.
7345 SW 165th Pl
Beaverton, OR 97007
(503) 590-8499
www.whdl.com
Synopsys Customer Education Services

700 East Middlefield Road
Mountain View, California 94043
Workshop Registration: 1-800-793-3448
www.synopsys.com
All trademarks used in this document are the property of their respective owners and should be treated as such.
Copyright Notice and Proprietary Information

Copyright 2003 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary
information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and
may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation
may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise,
without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.
Right to Copy Documentation

The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy
shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential
numbers to all copies. These copies shall contain the following legend on the cover page:
This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of
__________________________________________ and its employees. This is copy number __________.
Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to
nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to determine the applicable
regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO
THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE.
Registered Trademarks ()
Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Calaveras Algorithm, CoCentric, COSSAP, CSim, DelayMill,
DesignPower, DesignWare, Device Model Builder, Enterprise, EPIC, Formality, HSPICE, Hypermodel, I, InSpecs, in-Sync, LEDA,
MAST, Meta, Meta-Software, ModelAccess, ModelExpress, ModelTools, PathBlazer, PathMill, PowerArc, PowerMill, PrimeTime,
RailMill, Raphael, RapidScript, Saber, SmartLogic, SNUG, SolvNet, Stream Driven Simulator, Superlog, System Compiler,
TestBench Manager, Testify, TetraMAX, TimeMill, TMA, VERA, VeriasHDL, and WaveCalc are registered trademarks of
Synopsys, Inc.
Trademarks ()
Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora,
AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia,
Columbia-CE, Comet 3D, Cosmos, Cosmos SE, CosmosLE, Cosmos-Scope, Cyclelink, Davinci, DC Expert, DC Expert Plus,
DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Compiler, DesignerHDL, DesignTime,
DFM-Workbench, DFT Compiler SoCBIST, Direct RTL, Direct Silicon Access, DW8051, DWPCI, Dynamic-Macromodeling,
Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan
Manager, Formal Model Checker, FormalVera, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Frameway,
Gatran, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High
Performance Option, HotPlace, HSPICE-Link, Integrator, Interactive Waveform Viewer, iQBus, Jupiter, Jupiter-DP, JupiterXT,
JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, LRC, Mars, Mars-Rail, Mars-Xtalk, Medici,
Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, NanoSim,
Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, OpenVera, Optimum Silicon, Orion_ec,
Parasitic View, Passport, Physical Compiler, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler,
PowerCODE, PowerGate, ProFPGA, Progen, Prospector, Proteus OPC, Protocol Compiler, PSMGen, Raphael-NES,
RoadRunner, RTL Analyzer, Saber Co-Simulation, Saber for IC Design, SaberDesigner, SaberGuide, SaberRT, SaberScope,
SaberSketch, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early
Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC,
Star-Hspice, Star-HspiceLink, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-Sim XT, Star-Time,
Star-XP, SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-OPC, Taurus-Process, Taurus-Topography,
Taurus-Visual, Taurus-Workbench, Test Compiler, TestGen, TetraMAX TenX, The Power in Semiconductors, TheHDL, TimeSlice,
TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS, VCS
Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, VirSim, and VMC are trademarks of
Synopsys, Inc.
Service Marks (SM)

DesignSphere, SVP Caf, and TAP-in are service marks of Synopsys, Inc.
SystemC is a trademark of the Open SystemC Initiative and is used under license.
All other product or company names may be trademarks of their respective owners.
Printed in the U.S.A.
Document Order Number: 50-I-051-XSLG-002
SystemVerilog Workshop Student and Lab Guide
Synopsys Customer Education Services
System Verilog (VCS7.1)

for Verilog users (v1.1)
for
Intro to SystemVerilog 1
2003,2004 Willamette HDL, Inc.
Notes:
2003 Willamette HDL, Inc. &
Slide 1
This page was intentionally left blank.
2
Notes:
Slide 2
Course Outline
SV background
Timeline
System Verilog 3.0 pedigree
System Verilog 3.1 adds much more
VCS 7.1 Simulator
SystemVerilog
Variables
19
Data Types
Data Types: Basic & Integer
Data Types: Casting
23
Arrays
Structures
Unions
Unpacked Structures & Unions
Packed Structures & Unions
Lab 1 Union
27
Ports
Port Connection Rules
Lab 2: beh_sram
Implicit port connections
57
Verification
Modeling Characteristics & Models
Black & White Box testing
Transaction-level Verification
Interfaces
System Example: UART
UART beh. interface with methods
65
Course Outline
82
Notes:
Slide 3
Hierarchy
Module-centric time specifiers
$root
95
Other Enhancements
True 2-state simulation
literals, string, constant, user, enum
Parameters and redefine-able data types
Enhanced directives
Operators, Event Control - iff
New assignment/increment operators
Procedural Assignments
Continuous Assignments
for loop
disable, break, continue & return
105
RTL ambiguity
New always derivatives
Case/ifelse (unique, priority qualifiers)
Lab 3: Updated FSM style
129
Subroutines
Tasks & Functions
Minilab: automatic tasks/variables
default arguments, explicit calls, pass by reference
Data Scope and Lifetime
139
Interfaces Revisited
Lab 3 (UART): beh_uart.sv
Modports
Lab 4 (UART) : rtl_uart_1.sv
159
Course Outline 2
Notes:
Slide 4
Assertion based Verification
177
Course Outline 3
Background
SV 'Unified' Assertions
Immediate Assertions
Concurrent Assertions
Sequences
Operators
Properties
Assert / Cover
Binding
SV 3.1 Preview (Coming attractions)
237
$root in SV3.1
Explicit Hierarchy in SV3.1
Arrays dynamic & associative
Dynamic processes
Process control- wait/disable fork
Even more on interfaces
Classes / Randomization & Constraints
Program Block / Clocking Domains
Sample Solutions
267
Appendix A: VCS/Virsim introduction
285
Notes:
Slide 5
6
Notes:
Slide 6
SV background
In this section
Timeline Verilog to SystemVerilog

Verilog user profiles
What SystemVerilog offers
SV 3.0
SV 3.1
Notes:
Slide 7
Timeline
80's Verilog (Gateway Design Automation)
89
Cadence acquires Gateway
90
Verilog enters the Public Domain

Open Verilog International (OVI) formed
91
95
Verilog Standardized (IEE1364-1995)

VHDL International
Accellera
00
Verilog 2001 (IEEE 1364-2001)
01
02
Superlog (CoDesign)
OVL etc
03
SystemVerilog 3.0
Vera, OVA etc
SystemVerilog 3.1
Notes:
Slide 8
Verilog users today
Verification
Engineers
Architects
Verilog
VCS
Hardware
Designers
Notes:
Slide 9
Architectural Modeling
Architects
Use SystemC and/or C++ because:
Tuned language for Architectural/Algorithmic modeling

Speed
Features
Co-development of SW and HW
Notes:
Slide 10
Hardware
Designers
RTL Design
Most Verilog design is done at RTL for synthesis.

Problem:
Design complexity increases but Verilog is ANCIENT!
EDA industry has spend time & $$ improving design flows
but Verilog hasnt fundamentally changed in years
Verilog descriptions can be ambiguous and inefficient
Of course its still better than VHDL
Notes:
Slide 11
Verification
Engineers
Functional Verification
Most Verification in Verilog is done at the functional level.

Problem:
Design complexity increases but functional verification
cant keep pace.
Design:Verification ratio used to be 50:50, but now ~30:70
Verilog lacks modern coding capabilities
(Object Orientation, re-entrant tasks, dynamic memory
allocation etc)
Specialized verification languages like Vera are very popular
Notes:
Slide 12
The promise of System Verilog 3.0
Abstract Structures
Executable Spec
Interfaces/Protocols
Transaction-level Modeling
Architects
SystemC
Verification
Engineers
System Verilog
VCS
Hardware
Designers
High Level Models
RTL improvements
Timing
Notes:
Slide 13
System Verilog 3.0 pedigree

System Verilog expands the features of classic Verilog (Verilog 95?)
by adding Verilog 2001 and more.
Verilog 95
Concurrency & timing
Event Ordering
RTL/gate/switch simulation
Signal strength modeling
Verilog 2001
ANSI port/argument lists
Automatic tasks/functions
Generate statements
Signed Arithmetic
Multi-dim arrays
New ( Unique ) Features

$root
Interfaces
Combin/seq/latch processes
Assertions (orphaned)
C/C++
Data types
Structs & Unions
Dynamic memory
System Verilog 3.0

VCS 7.1
Notes:
Slide 14
System Verilog 3.1 adds much more
Verilog 95
Concurrency & timing
Event Ordering
RTL/gate/switch simulation
Signal strength modeling
Verilog 2001
ANSI port/argument lists
Automatic tasks/functions
Generate statements
Signed Arithmetic
Configurations
Multi-dim arrays
New ( Unique ) Features

Fork-join control options
Comb/seq/latch processes
Assertions (SVA/PSL/etc)
Interfaces
Classes
Program Blocks
Clocking Domains
Semaphores/Mailboxes
Random data Generation
Constraints
Handles (safe pointers)
Direct Programming I/F (DPI)
C/C++
Data types
Structs & Unions
Dynamic memory
System Verilog 3.1

VCS X.X
Notes:
Slide 15
Target audience
1.
Verification engineers experienced (frustrated?) at Verilog verification
2.
Designers already using Verilog for RTL design
3.
Support engineers with Verilog users, tools and flows
Notes:
Slide 16
VCS 7.1 Simulator

SystemVerilog
SystemVerilog
Code
Code
*.sv
*.sv
Verilog
Verilog
Code
Code
*.v
*.v
For an introduction to the VCS

Simulator and Virsim GUI
See Appendix A
VCS 7.1
+v2k
Runtime switch to enable Verilog 2001 features
+sysvcs
Runtime switch to enable SV features
Notes:
Slide 17
Version compatibility
Watch for these icons to tell you where SystemVerilog versions
and tool versions differ
SV
3.1
Not implemented yet: part of the SystemVerilog 3.1 language spec.
Part of the SystemVerilog 3.0 language spec. but NOT in the VCS 7.1 beta
DC
Not supported by Design Compiler (presto)
Notes:
Slide 18
Notes:
Slide 19
Verilog discovers the system

Verilog is one of the oldest Hardware Description Languages.
It was designed at a time when netlisting was still a novelty .
More recently and not least through the success of system level
design languages like SystemC (a C++ based HDL, targeted at
high-level simulation abstraction) the deficiencies of Verilog have
become obvious.
SystemVerilog is designed to redress the imbalance by:
1. Updating Verilog language/syntax to state-of-the-art
2. Supporting more abstract system-level modeling
Notes:
Slide 20
Variables
SystemVerilog is 100% backward compatible with Verilog 1995 and 2001.
In addition:
SystemVerilog inherits variables/types from C
SystemVerilog has additional types for system-level design and test
There are 2 types of variable in SystemVerilog
Static
Allocated and initialized at time zero
Exist for the entire simulation
Automatic
Designed to allow recursion in blocks, tasks and functions

Reallocated and initialized each time a block/task/function is entered
May NOT be used to trigger an event
May NOT be assigned by a non-blocking assignment
Notes:
Slide 21
22
Notes:
Slide 22
In this section
Basic / Integer types

User defined
Casting
Notes:
Slide 23
Data Types: Basic & Integer

Basic data types
time
64-bit integer, defaults to seconds
real
from Verilog, like C double, 64-bits
shortreal from C float, 32-bits
string
variable size array of char
void
non-existant data, used for functions
integer types can be signed or unsigned

integer sig; // signed by default
integer unsigned usig;
int unsigned usig;
bit, reg, logic default to unsigned
Others default to signed
Integer data types

char
shortint
int
longint
byte
bit
reg
integer
logic
from C (usually 8-bit signed integer)

16-bit signed integer
8-bit signed integer (usually same as char)
0 or 1
from Verilog (unsized: 0, 1, X, Z)
32-bit signed from Verilog (sized: 0, 1, X, Z)
like reg but with different usage rules
char
shortint
int
longint
byte
bit
reg
logic
integer
2-state
( 1, 0 )
4-state
( 1, 0, X, Z )
Notes:
Slide 24
Data Types: User defined

Not content with adding a wide set of new datatypes to the mix, SystemVerilog borrows
from C the syntax for declaring new types: typedef
typedef int mm ;
// mm becomes a new type
mm centi =10, metre = 1000;
// these are 2 new variables of type mm
Strange as it may seem, a type may be used before it is defined
typedef delay;
// known as an empty typedef
delay sec = 1 ;
// declare/initialize even though we dont know yet what it is
typedef int delay;
Notes:
Slide 25
Data Types: Casting

Type Casting
<type> (<value>)
Convert between data types with the cast (forward-tick):

int (2.0*3.0); // Cast result to integer
10 (a+b);
// implies a number of bits (10 here)
signed (a);
// works for sign-changing too
User defined types may also be cast:
mytype (b);
For compatibility these Verilog functions are supported:
$itor, $rtoi, $bitstoreal, $realtobits, $signed, $unsigned
Notes:
Slide 26
In this section
Multi-dimensional
Using Arrays
Supported datatypes
Supported operations
Array literals
Querying functions
Structure / Union
Initializing
Notes:
Slide 27
Arrays - Multidimensions
SystemVerilog supports multi-dimensional arrays just like Verilog
bit [7:0] mem [4:1]; // byte-wide memory with 4 addresses, like Verilog
mem[ i ] [6:1] = 0;
// 2D+ indexing supported (like Verilog 2001)
Also from Verilog 2001 we get multi-multi-dimensions phew!

bit [a:b] [n:m] [p:q] mem [ t:u] [v:w] [x:y]; // arbitrary dimensions
packed
unit
unpacked
SystemVerilog uses the terms packed and unpacked to refer to how the data is actually
stored in memory (e.g. packed => 8-bits to a byte, unpacked => 1 bit per word )
a0
a1
a2
a3
b3 b2 b1 b0
packed
unpacked
Notes:
Slide 28
Arrays Multidim. (simplified)

It may help you to think of these in the classic Verilog terminology
So its as if we have multi-dimensions of data and of address
bit [a:b] [n:m] [p:q] mem [ t:u] [v:w] [x:y]; // big ugly (5D) memory
(packed) data
address
(unpacked)
The packed dimensions describe how the data is arranged ( or packed)

and the unpacked dimensions describe how we map this data to a multi-dimension address
bit [3:0] [7:0] aa ;
byte3
byte2
// a single, packed 4-byte data word (4x8 = 32 bits)

byte1
bit [3:0] [7:0] bb [1:0];
byte0
aa[0] = aa[0] + 1; // byte increment
// 2-deep array of packed 4-byte data words
byte3
byte2
byte1
byte0
byte3
byte2
byte1
byte0
aa
bb[1]
bb[0]
bb[1] = bb[0]; // word assignment
Notes:
Slide 29
Array Access Example 1

bit [3:0] [7:0] aa ;
bit [3:0] [7:0] bb [10:1] ;
// packed 4-byte variable

// array of 10 4-byte words
10
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
Figuring out how to access these arrays can also be confusing

Remember, start with unpacked dimensions proceeding left to right,
then continue with the packed, proceeding left to right
bb[9] = bb[8] + bb[7];
bb[10][1:0] = bb [9][3:2] ;
// add 2 4-byte words
// copy 2 MS bytes
// from word 9 to word 10 (LS bytes)
10
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
10
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
7:0
Notes:
Slide 30
Array Access Example 2
7:0
10
9
7
6
5
7:0
7:0
7:0
packed
7:0
7:0
7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0

7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0
7:0
10
7:0
7:0
un
pa
ck
3
2
ed
7:0
7:0
// set that whole byte
7:0
7:0
NOTE
All unpacked indices must be provided, every time
Use packed indices as needed to slice the packed vector
cc[9] [1] [3] = 8hff;
7:0
7:0
// set the LSB of byte 3 of address 9x1
7:0
7:0 7:0 7:0

7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0
cc[9] [1] [3] [0] = 1b1;
7:0
7:0 7:0 7:0

7:0 7:0 7:0
7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0
7:0 7:0 7:0
bit [3:0] [7:0] cc [10:1] [3:1] ; // 2D array (10x3) of 4-byte words
7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0

7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0
7:0
7:0
7:0
7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0

7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0
7:0 7:0 7:0 7:0 7:0 7:0 7:0 7:0
7:0
10
7:0
7:0
7:0
Notes:
Slide 31
module use_arrays;
bit[3:0][7:0] bb [10:1];
bit[3:0][7:0] cc [10:1][3:1];
Arrays Using them 2
// This example code 'proves' the previous slide

initial
begin
$display("\n\nPart 1:\n");
$monitorh(bb[9],,bb[8],,bb[7]);
bb[9] = 'hff;
bb[8] = 'h55;
bb[7] = 'h22;
#100 bb[9] = bb[8] + bb[7];
#100 bb[10][1:0] = bb[9][3:2];
#100 $display("\n\nPart 2:\n");
Part 1:
000000ff 00000055 00000022
00000077 00000055 00000022
Part 2:
NOTE
$monitor cannot display the
whole of arrays bb or cc,
but it CAN show the packed
dimensions if you fully
define the unpacked ones!
00000000
33221100
b3221100
aa221100
$monitorh(cc[9][1]);
#100 cc[9][1] = 'h33221100; // initialize 32-bit vector
#100 cc[9][1][3][7] = 1'b1;
// set MSB of MSbyte of 32-bit vector
#100 cc[9][1][3] = 8'haa;
// load MSbyte of 32-bit vector
#100 $display("\n\n");
end
endmodule
Notes:
Slide 32
Arrays Allowed data types

Unpacked
Familiar from Verilog, may be ANY Datatype
Only access a single element at a time
Although whole arrays may be copied
Specified as a range ( int mem [256:1] )
unpacked
a0
a1
a2
a3
bit a [3:0]; // unpacked array of bits
Packed
Only bit-level types (reg, wire, logic, bit)
Access whole array or slice as a vector
Compatible with $monitor/$display etc.
Allows arbitrary length integers/arithmetic
bit
packed
bit [3:0] b; // packed array of bits
[3:0]
bit
b3 b2 b1 b0
[3:0]
Notes:
Slide 33
Arrays Supported Operations

int var=3;
bit[7:0] PA = 8'haa, PB = 8'hbb;
byte UA [7:0] = {default: 'haa}; byte UB [7:0] = {default: 'hbb};
bit[3:0][7:0] MPA;
0
10
20
30
40
50
60
PA: aa, PB: bb,

PA: bb, PB: bb,
PA: ab, PB: ba,
PA: aa, PB: ba,
MPA: 00000000
MPA: deadbeef
MPA: deadbef0
UA[4]:
UA[4]:
UA[4]:
UA[4]:
aa,
bb,
ab,
aa,
UB[4]:
UB[4]:
UB[4]:
UB[4]:
bb
bb
ba
ba
initial begin
$monitor($stime,,"PA: %h, PB: %h, UA[4]: %h, UB[4]: %h",PA,PB,UA[4],UB[4]);
Packed & unpacked arrays support:

#10 PA = PB;
UA = UB;
#10 PA[7:4] = 'hA;
PB[3:0] = PA[7:4];
UA[4][7:4] = 'hA;
UB[4][3:0] = UA[4][7:4];
#10 PA[var -:4] = PA[var+1 +:4];
UA[4][var -:4] = UA[4][var+1 +:4];
#10 $monitor($stime,,"MPA: %h",MPA);
#10 MPA = 32'hdeadbeef;
#10 MPA = MPA+1;
end
Read/write
Read/write of a slice
Read/write of a variable slice
Only packed arrays allow:

Assignment from an integer
Treatment as an integer in an expression
Notes:
Slide 34
module array_ops2;
Arrays and $readmemh/b

HINT
bit[7:0] PA [3:0];
bit[1:0][7:0] PB [3:0]; // two pkd dimensions
$readmemX supports only a

single unpacked dimension
byte UA [7:0];
byte UB [7:0][1:0];
initial
begin
#10 $readmemh("hex.dat",PA);
for(int i=0; i<=3;i++) $display("PA[%0h",i,"]: %b",PA[i]);
#10 $readmemh("hex.dat",PB);
$display("");
for(int i=0; i<=3;i++) $display("PB[%0h",i,"]: %b",PB[i]);
#10 $readmemh("hex.dat",UA);
$display("");
for(int i=0; i<=3;i++) $display("UA[%0h",i,"]: %b",UA[i]);
/* #10 $readmemh("hex.dat",UB); // ILLEGAL, only 1 unpkd dim allowed

for(int i=0; i<=3;i++) $display("UB[",i,"]: ",UB[i]); */
end
endmodule
PA[0]:
PA[1]:
PA[2]:
PA[3]:
00000000
00000001
10101010
11111111
PB[0]:
PB[1]:
PB[2]:
PB[3]:
0000000000000000
0000000000000001
0000000010101010
0000000011111111
UA[0]:
UA[1]:
UA[2]:
UA[3]:
00000000
00000001
10101010
11111111
Notes:
Slide 35
Arrays - Examples
bit [2:0][7:0] m = 24b0;
// packed 3-byte vector
bit [3:0] [7:0] abc [1:10],

def [1:9] [ 1:3];
// 2 arrays, same packed dimensions

// but different unpacked
typedef bit [1:6] bsix;

bsix [1:10] mine;
// 6-bit packed vector

// 60-bit packed vector
typedef bsix mem_type [0:3];

mem_type bar [0:7];
// unpacked array of 4 bsix elements

// unpacked array of 8 mem_type elements
Notes:
Slide 36
Array Querying functions

SystemVerilog allows querying of the attributes of an array:
$bits, $left, $right, $low, $high, $increment, $length, $dimensions
$dimensions:
returns the number of dimensions in the array (0 if scalar)

bit [3:0] [7:0] aa;
initial $display( $dimensions(aa) );
// prints 2
$bits:
Number of bits in a packed array or struct

initial $display( $bits(aa) );
// prints 32
${left|right}:
Bounds of a variable
bit [3:1] [7:4] bb;
bit [3:1] [7:4] cc [2:0];
initial begin
$display( $left(bb) , $right(bb) );
$display( $left(cc) , $right(cc) );
end
// $left => msb, $right => lsb
// prints 3
// prints 2
1
0
${low|high}:
Min|max bounds of a variable
$increment:
returns 1 if $left is greater than or equal to $right

returns 1 if $left is less than $right
$length:
returns number of elements in the dimension ( $high - $low +1 )
// min|max of $left and $right of variable
Notes:
Slide 37
Array Query - quiz

module arrays_quiz;
bit [3:0][7:0] a;
bit
b [3:0];
bit
c [3:0][7:0];
bit
[5:0] d [3:0][31:0];
bit [7:0][5:0] e [3:0][31:0];
initial
begin
$display("bit [3:0][7:0] a;",
$bits(a),, $dimensions(a),, $length(a,1),, $length(a,2));
$display("bit
b [3:0];" ,
$bits(b),, $dimensions(b),, $length(b,1));
$display("bit
c [3:0][7:0]; ", $bits(c),, $dimensions(c),, $length(c,1),, $length(c,2));
$display("bit
[5:0] d [3:0][31:0]; " , $bits(d),, $dimensions(d),, $length(d,1),, $length(d,2),, $length(d,3));
$display("bit [7:0][5:0] e [3:0][31:0];" , $bits(e),, $dimensions(e),, $length(e,1),, $length(e,2),, $length(e,3),, $length(e,4));
end
endmodule
2
1
2
3
4
2
1
2
3
4
4
4
4
4
4
32
4
32
768
6144
4
4
4
4
4
8
32
32
8
6
8
32
4
32
768
6144
8
32
32
bit [3:0][7:0] a;
bit
b [3:0];
bit
c [3:0][7:0];
bit
[5:0] d [3:0][31:0];
bit [7:0][5:0] d [3:0][31:0];
bit [3:0][7:0] a;
bit
b [3:0];
bit
c [3:0][7:0];
bit
[5:0] d [3:0][31:0];
bit [7:0][5:0] d [3:0][31:0];
6
8
Notes:
Slide 38
Structures
From C SystemVerilog has acquired the idea of a structure.
Think of a structure as an object containing members of any type.
struct { bit[7:0] my_byte;
int
my_data;
char
my_char;
} my_struct;
// my_byte, my_data and my_char are "members" of my_struct.
The members can be referenced individually (using the

as a unit.
initial begin
my_struct.my_byte = 8hab;
my_struct = {0, 99, A};
end
. operator) or altogether
Structures may:
be packed or unpacked.
be assigned as a whole
pass to/from a function or task as a whole
contain arrays
Notes:
Slide 39
Unpacked Structures
By default, structs are unpacked. Their implementation is tool dependant for maximum
flexibility.
a0
a1
Unpacked
a2
a3
struct { bit[1:0]
bit[2:0]
bit[5:0]
bit[8:0]
} u_pkt;
a0;
a1;
a2;
a3;
You may think of an unpacked structure as a logical grouping of different objects,

different types etc.
They may be defined as a type:
typedef struct { byte RED,GRN,BLU;
} RGB;
// Named structure
RGB screen [0:399][0:639];
// declare screen of 640x400 pixels
Notes:
Slide 40
More structure examples

struct { bit[7:0] opcode;
bit[23:0] addr;
} INSTR;
// Referred to as an anonymous structure
INSTR.addr = 0;
// clear addr in INSTR
typedef struct { bit[7:0] opcode;

bit[23:0] addr;
} instruction; // Named structure
instruction INSTR;
// declare one!
Notes:
Slide 41
Packed Structures
Packed structs are more useful in hardware simulation. As with arrays, packing means
the elements of the structure are arranged in the form of a wide vector.
a0
a1
a2
a3
struct packed {
bit[1:0]
bit[2:0]
bit[5:0]
bit[8:0]
} p_pkt;
a0;
a1,
a2,
a3;
A declaration of "packed" offers advantages:

Easy conversion to bit-vectors
May be accessed as a whole
First member specified is most significant
May be declared as signed for arithmetic
and responsibilities:
Only bit-oriented datatypes (bit, logic, reg, net) are allowed.
Unpacked arrays/structures are NOT allowed
if any member is 4-state, all members are cast to 4-state
Notes:
Slide 42
Packed Structures - examples

struct packed signed { int a; shortint b; byte c; bit[7:0] d;} pack1; // signed, 2 state
struct packed unsigned { time a; logic[7:0] b;} pack2;
// unsigned, 4 state
typedef struct packed { // Packed struct/unions may also be typedefd
bit[3:0] f1;
bit[7:0] f2;
bit[11:0] f3;
bit f4;
bit[63:0] f5;
} a_packed_struct;
Notes:
Slide 43
Uses of structures
Structures are ideal way to encapsulate data "packets"
Use as data or control abstraction in architectural models
Use as abstraction for top-down I/O design
Behavioral: pass structures through ports,
as arguments to tasks/functions etc.
Use to refine structure size/content
RTL:
break structure apart

& define final I/O
Notes:
Slide 44
Lab 1 - Structures
Working directory: video1
Purpose: Declare and use structures
in a real video application
Background:
The file video.sv already contains the code to read in an image file i_mourne.bmp
and to write it out again as new_pic.bmp (using Verilog 2001 FileIO extensions).
The image i_mourne.bmp is 150x400 pixels and is a negative.
Your mission: Modify video.sv to develop the image and produce a positive
1.
View i_mourne.bmp image, notice that it looks like a photo negative.
2.
See following slides for more instructions
Notes:
Slide 45
Lab 1 - Video array

module video;
typedef
//
typedefstruct
of packed
packed
4-byte
{byte
struct
R, X,
RGB
G, B;} RGB;
RGB
//
Unpacked
vidbuf[1:150][1:400]
array vidbuf[1:150][1:400]
; // Unpacked
of type
array
RGB
of RGB
byte hdr [1:56];
int rfile, wfile, ifs, i, scale;
int histogram [0:255]; // array to hold histogram data
R
R
R
R
150
vertical
R
R
R
R
"X" is unused
bytelane
R X G
R RX XG GB
R RX XG GB
R R
X RX
G XG
B GB
RX R
XG X
GB G
B B
R X X GGB B
R X XGGB B
R X G
X G B
R R X XG GB
R R X X G G B
R R
X RX
G XG
B GB
RX R
XG X
GB G
B B
R X XG GB B
RX XG GB B
X G B
B
B
B
B
B
B
B
B
400
horizontal
32 bits
Instructions:
1.
Modify video.sv as follows:

a) Declare RGB struct and vidbuf array as described in comments
Notes:
Slide 46
Lab 1 invert task

2.
Modify video.sv as follows:

a) Add a task called invert which inverts each pixel in entire video array
(Algorithm: subtract each pixel value from 255)
b) Notice where your new task is invoked in the code
c) Compile/run the code and view the file new_pic.bmp
initial
begin
rfile = $fopen("i_mourne_32.bmp", "r");
wfile = $fopen("new_pic.bmp", "w");
i = $fread(hdr, rfile, 0, 56);
i = $fread(vidbuf, rfile);
ifs = $ftell(rfile);
$display("Loaded %0d pixels \n", ifs);
// Open the image file

// Open output img file
// Read 56-byte header
// Read the file into memory
// capture filesize in "ifs"
invert;
saveimg;
$fclose(rfile);
$fclose(wfile);
$finish;
end
Notes:
Slide 47
Unions
This is another concept borrowed from C.
In C/C++
Union is a specialized form of struct
Memory footprint is the size of the largest member
All members begin at the same memory address
Only one member may be assigned/read
This also describes unpacked unions in SV (Not very useful for h/w)
However, packed unions are VERY useful
NOTE: Unpacked unions are not supported in VCS7.1

Notes:
Slide 48
Packed Unions
A packed union contains 1 or more packed members
All members are the same size and occupy the same space
Data may be written via one member, read by another
The union may be accessed as a whole
union packed {
int
a;
integer b;
reg[31:0] c;
} p_union;
b
p_union
Characteristics
Easy conversion to bit-vectors
May be accessed as a whole
First member specified is most significant
May be declared as signed for arithmetic
Non-integer datatypes (e.g. real) are NOT allowed.
Unpacked arrays/structures are NOT allowed
if any member is 4-state, all members are cast to 4-state
Notes:
Slide 49
Packed Union - example

Since all members are same size and occupy the same memory space
The same data may be accessed via any of the members.
Permits one data element to exist in multiple name-spaces
typedef struct packed { // Default unsigned

bit[7:0] f1, f2;
bit[11:0] f3;
bit[2:0] f4;
bit f5;
bit[63:0] f6;
} my_packed_struct;
typedef union packed { // Default unsigned
my_packed_struct mps;
3
bit[95:0] bits;
members
bit[11:0] [7:0] bytes;
} my_packed_union;
my_packed_union u1;
Given:
byte b;
b = u1.bits[87:80];
b = u1.bytes[10];
b = u1.mps.f2;
Notes:
Slide 50
Lab 2 - Union
Working directory: union
Purpose: Reinforce the syntax and usage of union
Instructions:
Modify the file: pu_bytex.sv as follows
1.
2.
64 bits
Write a function called bytext to extract the specified byte from a 64-bit value.
Use a union within the function to achieve the byte extraction.
i.e. write one member with 64 bits, read from another member (8-byte lanes).
Notes:
Slide 51
Lab 2 Union (pu_bytex.sv)

module pu_bytex;
bit [63:0] bus;
aabbccddeeff0011
8
// Your function here
64 bits
initial
begin
bus = 64'haabbccddeeff0011;
for(int i=8; i>0; i--)
$displayh(bytext(bus,i));
end
aa
aa
bb
bb
cc
cc
dd
dd
ee
ee
ff
ff
00
00
11
11
endmodule
Notes:
Slide 52
module mod1;
Structure Expressions
typedef struct {
logic [7:0] a;
int b;
} my_struct;
my_struct s1 ;
NOTE
SV distinguishes between structure expressions (as shown here)
and ordinary concatenations by the context.
If the LHS of an assignment is an unpacked structure,
its a structure expression. Otherwise, { } represent concatenation.
initial begin
$monitor("my_struct s1.a: %h, s1.b: %h",s1.a, s1.b);
#10 s1 = {5, 6};

#10 s1 = {b:5, a:6};
#10 s1 = {default: 7};
#10 s1 = {int:9, default:1};
// #10 s1 = {logic[7:0]:2, b:3};
end
endmodule
// assign by position
// assign by name
// default: operator
// assign by type, others default
// assign by type and by name
my_struct
my_structs1.a:
s1.a:xx,
xx,s1.b:
s1.b:00000000
00000000
my_struct
s1.a:
05,
s1.b:
my_struct s1.a: 05, s1.b:00000006
00000006
my_struct
my_structs1.a:
s1.a:06,
06,s1.b:
s1.b:00000005
00000005
my_struct
my_structs1.a:
s1.a:07,
07,s1.b:
s1.b:00000007
00000007
my_struct
my_structs1.a:
s1.a:01,
01,s1.b:
s1.b:00000009
00000009
Notes:
Slide 53
Arrays - literals
Like C, SystemVerilog supports array literals but with the additional feature of
the replicate operator. The key to understanding array literals is to remember the
dimensions of the array and use { } to match those dimensions exactly.
int k [1:3][1:4] = {{1,2,3,4},{5,6,7,8},{9,10,11,12}};
int m [1:2][1:3] = {{0,1,2},{3{4}}};
// 3 groups of 4
// 2 groups of 3
char a [1:12] = {"H","e","l","l","o","J","W","o","r","l","d","\n"};
// a group of 12 chars
Notes:
Slide 54
Arrays literals 2
Sometimes it is handy not to have to explicitly define each value of the array. For this
the default keyword is provided:
int k [1:3][1:4] = {default: 5};
// All elements 5
int k [1:3][1:4] = { {1,2,3,4}, default: 5 };
// ILLEGAL: Cant mix positional syntax and default
int k [1:3][1:4] = { 1: {1,2,3,4}, default: 5 }; // k[1][1-4] defined, others 5
Default applies a value to each element of an array

that is not otherwise specified
Notes:
Slide 55
Quiz - Array literals

Part 1: Complete the following literal for values 1,2,3 etc. left to right
bit [3:0] b [2:0][3:0] = {{1,2,3,4},{5,6,7,8},{9,10,11,12}};
Part 2: Now, what will be the simulation output from the following code fragment?
initial
for(int i = 0; i<3; i++)
for(int j = 0; j<4; j++)
$display(b[i][j]);
12
11
10
9
8
7
6
5
4
3
2
1
Notes:
Slide 56
In this section
SV types and ports

Connection rules
Implicit connections
Notes:
Slide 57
Module Ports
Like Verilog 2001 SystemVerilog allows co-declaration of port AND type
port_direction port_type port_name, port_name ... ;
input wire a, into_here, george;
output reg [8:31] out_bus;
// scalar ports and nets

// vectored port and driving reg
Port declarations can also be made within the parentheses of the module
declaration (also in Verilog 2001).
module MUX2 (output logic [1:0]
input logic [1:0]
input
[1:0]
out,
in_a, in_b,
sel ) ;
Ports may be of ANY SystemVerilog type including events, structs, arrays etc.
typedef struct {
bit isfloat;
union { int i; shortreal f; } n;
} tagged; // named structure
module mh1 (input event e1, input int in1, output tagged out1);
...
endmodule
Notes:
Slide 58
Port Connection Rules

Since ports default to a net type (like Verilog) classic Verilog rules apply.
BUT for ports declared as non-net type (e.g. logic) things simplify a lot
wire
port type
(SV default)
Like Verilog
net,
reg,
logic
etc.
net
reg,
net,
logic
tri
tri
Any
compatible type
non-wire
port type
(e.g. logic)
net
Any
SystemVerilog type
module
tri
tri
SystemVerilog only
Any
SystemVerilog type
Net type
only
Notes:
Slide 59
SV types are flexible
NOTE
SV3.0 implied a difference
between reg and logic types.
Under SV3.1 reg and logic
are semantically identical.
For example, logic (and reg) are

can be treated as reg/wire (V2001)
4-state (0,1,X,Z)
Any width ( [MSB:LSB] )
May be declared as signed or unsigned (default)
VCS follows SV3.1
A variable of any SV type may be driven by any one of the following:

Choose
only one
Arbitrary number of procedural assignments (like reg in Verilog)

Single continuous assignment
Single primitive/module output
Synthesis rules still forbid
assignment from multiple
procedural blocks however
May let the simulator spot

common Verilog problem
of multiple drivers to a node
Notes:
Slide 60
Lab 3: beh_sram
Working directory: beh_sram
Purpose: Apply new features of SV like UDTs, structs, new SV port-types.
Instructions:
Write an abstract behavioral model of a syncrhonous sram memory
Memory is 1k deep x 32bits wide

2 ports (ip and op) both of type packet.
Testbench writes and reads packets over the 2 ports.
Memory access time is 5ns
beh_sram
ip
op
32bits
clk
rw_
mem
array 1k
Notes:
Slide 61
Lab 3: beh_sram
beh_sram
ip
op
typedef struct {
logic [9:0] addr;
logic[31:0] data;
} packet;
32bits
clk
rw_
mem
array 1k
Testbench: test_beh_sram.sv ( DO NOT LOOK AT IT! )
Packet definition shown above

sram operates on posedge of clk
rw_ signal is hi read, lo write
Memory access time is 5ns
Question: Where do you declare the packet typedef? Think about it, experiment!
Notes:
Slide 62
Lab 3 beh_sram (expected output)
40
40 Writing
Writing 0000000a
0000000a to
to address
address 005
005
80
Writing
00000002
to
address
001
80 Writing 00000002 to address 001
146
146 Read
Read successful:
successful: 0000000a
0000000a from
from address
address 005
005
186
Read
successful:
00000002
from
address
186 Read successful: 00000002 from address 001
001
200
Writing
0000aaaa
to
address
1ff
200 Writing 0000aaaa to address 1ff
266
266 Read
Read successful:
successful: 0000aaaa
0000aaaa from
from address
address 1ff
1ff
Notes:
Slide 63
64
Notes:
Slide 64
In this section
Modeling characteristics
Abstraction levels
White vs black box
Transaction level modeling
Interfaces
Who needs them and why
Simple bundled
Methods
Notes:
Slide 65
Verilog discovers the system

At the beginning of this course we said SystemVerilog achieves 2
goals:
1. Updating Verilog language/syntax to state-of-the-art
2. Supporting more abstract system-level modeling
But what exactly IS abstract system level modeling?
Let's explore some of the terminology used in verification today
and then how SV make such modeling easier
Notes:
Slide 66
Terms used to characterize models
UnTimed Functional (UTF)

Timed Functional (TF)
Bus Cycle Accurate (BCA)
Pin Cycle Accurate (PCA)
Register Transfer (RT) accurate
Model Functionality
Modeling Characteristics & Models

UT
TF
RT
UT
TF
BCA
Model Interface
PCA
Model types
System Architectural Model

System Performance Model
Transaction Level Model (TLM)
Functional Model
System Level Model
Behavioral Level Model (BLM)
Behavioral Synthesis Model
Bus Functional Model (BFM)
Register Transfer Level (RTL) model
Often
Oftenhave
haveoverlapping,
overlapping,
mixed,
definitions
mixed, definitions- source
sourceof
ofconfusion
confusion
Notes:
Slide 67
UTF refers to both the model interface

and model functionality
Time not used for execution
Processes execute in zero time
Transport of data executes in zero time
Model Functionality
UnTimed Functional (UTF)

UT
TF
RT
UT
TF
BCA
Model Interface
PCA
Time used only perhaps as an ordering

mechanism
Notes:
Slide 68
TF refers to both the model interface

and model functionality
Time used for execution
Processes assigned an execution time
Transport of data assigned time
Latency modeled
Model Functionality
Timed Functional (TF)

UT
TF
RT
UT
TF
BCA
Model Interface
PCA
UTF & TF may be mixed in the same

model
Notes:
Slide 69
BCA refers to the model interface

Cycle accurate
Not pin-level detail
Data transfer typically modeled
as transactions
Model Functionality
Bus Cycle Accurate (BCA)

UT
TF
RT
UT
TF
BCA
Model Interface
PCA
May have refined data types

New SystemVerilog types
struct, array, real
Notes:
Slide 70
PCA refers to the model interface

Cycle accurate
Pin-level detail
Refined data types
Model Functionality
Pin Cycle Accurate (PCA)

UT
TF
RT
UT
H/W SystemVerilog types
TF
BCA
Model Interface
PCA
bit, int, integer, reg, logic etc.
Clocks used for timing
Notes:
Slide 71
RT refers to the model functionality

Fully timed
Cycle accurate
Latency is modeled
Clocks used for synchronization

Complete detailed functional description
Model Functionality
Register Transfer (RT) Accurate

UT
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Every register, every bus, every bit described for every cycle
Synonymous with Register Transfer Level (RTL) models

Reduced ambiguity (always_comb, always_ff etc)
Notes:
Slide 72
Executable specification of system

HW & SW components
Usually generate/consume style
Model interface
UTF
No pin-level detail
Communication protocols
Model Functionality
System Architectural Model

UT
SAM
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Model functionality
UTF
Algorithmic behavior
Sequential behavior modeled
Useful for
Architecture exploration
Algorithm determination & proof
Notes:
Slide 73
Model interface
TF or UTF
No pin-level detail
Communication protocols
Communication behavior may be timed

May or may not be cycle accurate
Model Functionality
System Performance Model

UT
SAM
SPM
TF
RTL
RT
UT
TF
BCA
Model Interface
Model functionality
TF or UTF
Algorithmic behavior
Processes are assigned time
Concurrent behavior modeled
Not cycle accurate
Useful for high-level performance modeling and time budgeting
Notes:
Slide 74
After HW/SW split

Model Interface
TF
Not pin-level detail
Data transfer modeled as transactions
May or may not be BCA
Model Functionality
Transaction Level Model (TLM)

UT
SAM
SPM
TLM
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Model Functionality
TF
Not cycle accurate
Behavior described in terms of transactions
May have a system clock
Useful for modeling executable platform (HW)
Notes:
Slide 75
Used to refer to the modeling done at

levels of abstraction above
Transaction Level Models
Encompasses both
System Architectural
System Performance Models
Model Functionality
Functional Model
UT
FM
SAM
SPM
TLM
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Refers to either or both mixed
Notes:
Slide 76
Used to refer to models above RTL

models
Encompasses
System Architectural
System Performance Models
Transaction Level Model
Functional Model
Model Functionality
System Level Model

UT
SAM FLM
SLM
BLM
SPM
TLM
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Behavioral Level Model

"Older" term that means essentially the same as
System Level Model ("newer term")
Notes:
Slide 77
Model which follows behavioral

synthesis guidelines
Model interface
Pin Level Detail
Typically cycle accurate
Model Functionality
Behavioral Synthesis Model

UT
SAM FLM
SLM
BLM
SPM
BSyn
TLM
TF
RTL
RT
UT
TF
BCA
Model Interface
PCA
Module functionality
TF
Not cycle accurate
Useful for "Micro" architectural analysis
Notes:
Slide 78
Typically IP for simulation purposes

Models of processors etc.
Not intended for synthesis
Model interface
Model Functionality
Bus Functional Model (BFM)

UT
SAM FLM
SPM
BSyn
TLM
TF
BFM
RTL
RT
UT
PCA
SLM
BLM
TF
BCA
Model Interface
PCA
Module functionality
Typically described as transactions
BFM's are sometimes called transactors
Notes:
Slide 79
Transaction-level Verification (1)

Transaction-level Verification ( TLV ) applies TLM concepts to the test domain
Develop abstract models of pins/buses ( reduce detail, speed up simulation )
( SV Interfaces are ideal )
Develop abstract models of bus transactions ( typ. tasks, called transactors )
Use high-level language constructs to apply transactors to interfaces (OOP,
interface methods etc)
Testing is done at human-friendly level ( e.g. read, write, dma tasks )
Design still runs at lower more functional level but humans dont have to
TLV is very hard ( impossible? ) to implement in Verilog
Notes:
Slide 80
Transaction-level Verification (2)

SystemVerilog and TLV
Optimized language for Testing
New high-level coding structures
Interfaces
Arrays
Structs
Classes
Semaphores & Mailboxes
Program blocks
Clock Domains
Constrained random-number generation & coverage
Notes:
Slide 81
Interfaces
Great simulation efficiency can be achieved by modeling the blocks of a system at
different levels of abstraction, behavioral, rtl, gate etc.
Traditionally, the interface between these blocks has always remained at the lowest
wire level. High-performance system-level simulation requires the abstraction of interblock communication. To this end, SystemVerilog introduces the concept of interfaces.
data
MMU
addr
rw_
MEM
ena
interface
module mmu(d, a, rw_, en);

output [15:0] a;
output rw_, en;
inout [7:0] d;
...
endmodule
module mem(d, a, rw_, en);
input [15:0] a;
input rw_, en;
inout [7:0] d;
...
endmodule
module system;
wire [7:0] data;
wire [15:0] addr;
wire ena, rw_;
At its simplest
an interface is
like a module
for ports/wires
Traditional
Verilog code
mmu U1 (data, addr, rw_, ena);

mem U2 (data, addr, rw_, ena);
endmodule
interface interf;
logic [7:0] data;
logic [15:0] addr;
logic ena, rw_;
endinterface
SystemVerilog
module mmu(interf io);

io.addr <= ad;
...
endmodule
module mem(interf io);
adr = io.addr;
...
endmodule
module system;
interf i1;
mmu U1 (i1);
mem U2 (i1);
endmodule
Notes:
Slide 82
What is an Interface?
An interface defines a set of signals via which two or more modules may
communicate as well as a set of methods or tasks by which those modules
can communicate over the interface.
Interfaces bring abstraction-level enhancements to ports, not just internals.
At its simplest, an interface is like a module for the wires between modules.
An interface may contain any legal SystemVerilog code except module definitions
and/or instances. This includes tasks,functions, initial/always blocks, parameters
etc.
Interfaces are defined once and used widely, so it simplifies design.
e.g. Changing a bus spec (add a new signal?) means editing the interface only.
Interfaces may be hierarchical. This can allow modeling the interface at different
abstractions with all the performance benefits we see in design abstraction changes.
Notes:
Slide 83
Who needs interfaces?

Classic Verilog design/test strategy
Individual TB per unit
Uneven coverage
Duplication of effort (TB per block)
Bugs found: tend to be simple & local
CPU
Integration can be a nightmare

Bugs at this point are complex involving
interaction between blocks
Often caused by different interpretations
of bus spec. in TB1 and TB2
Peripheral
TB1
TB2
SYSTEM_TB
CPU
Peripheral
Notes:
Slide 84
Design needs interfaces (TLM)

TLM strategy example
Define interfaces for each communication channel

Interfaces share common methods (interchangeable)
Refine interface abstractions over time
Verify each interface independently
True interface-based design style

Greater flexibility
Communication what-if's done in interface
rather than module
Test interface cost/benefit without
changing module functionality
Choice of interfaces & abstractions
Interfaces may contain coverage counters
& bus monitors
FireW
PAR
USB
v2
SER
USB
V1
SYSTEM_TB
CPU
Communication
Interface
Peripheral
Notes:
Slide 85
Verification needs interfaces (TLV)

TLV strategy example
Define interfaces from the start
Separate communication from functionality
Refine interface abstraction over time
Communication refinement done in interface
rather than module
Support interface-based design style
Greater flexibility
Refine interface implementation without
Change interface protocol without
Verify each interface independently
Integration is smoother
Common interface(s) already debugged
Choice of I/F abstractions to suit
design abstractions & simulation goals
Interfaces may contain coverage counters
& bus monitors
RTL
UTF
TF
PCA
BCA
SYSTEM_TB
CPU
Interface
Peripheral
Notes:
Slide 86
Design Example w/o Interfaces

module memMod ( input bit req, bit clk, bit start,
logic[1:0] mode, logic[7:0] addr,
inout logic[7:0] data,
output bit gnt, bit rdy
);
logic avail;
...
endmodule
module definition
module cpuMod ( input bit clk, bit gnt, bit rdy,

inout logic [7:0] data,
output bit req, bit start,
logic[7:0] addr,
logic[1:0] mode
);
...
endmodule
module definition
module top;
logic req, gnt, start, rdy; // req is logic not bit here
logic clk = 0;
logic [1:0] mode;
logic [7:0] addr, data;
Top-level module definition
memMod mem(req, clk, start, mode, addr, data, gnt, rdy);

cpuMod cpu(clk, gnt, rdy, data, req, start, addr, mode);
Complete portlist
Complete portlist
Signals to interconnect instances
Instantiate/connect everything
endmodule
Notes:
Slide 87
Simple Bundle interface

interface simple_bus; // Define the interface
logic req, gnt;
When an interface is used like a port
logic [1:0] mode;
all the signals of that interface are
logic start, rdy;
assumed to be inout ports
endinterface: simple_bus
simple_bus Interface definition
module memMod (simple_bus a, // port a is of 'type' simple_bus

input bit clk); // and separately hook up clk
logic avail;
// a.req is the req signal in the simple_bus interface
Declare a module and name

its simple_bus interface a
always @(posedge clk) a.gnt <= a.req & avail;
signals making up simple_bus
Access interface signals by name.signal
endmodule
module cpuMod(simple_bus b, input bit clk);
...
endmodule
Declare a module and name

its simple_bus interface b
module top;
logic clk = 0;
Top-level module
simple_bus sb_intf;
// Instantiate the interface
memMod mem(sb_intf, clk); // Connect the interface to the module instance
cpuMod cpu(.b(sb_intf), .clk(clk)); // Either by position or by name
Instantiate/connect everything
endmodule
Notes:
Slide 88
Interface Ports
Ports may be defined to an interface. This allows external connections to the
interface to be made and hence automatically to all modules which instantiate
the interface This is most commonly used for clk nets.
interface simple_bus (input bit clk); // Define the interface
logic req, gnt;
logic [1:0] mode;
logic start, rdy;

with one input port clk
module memMod(simple_bus a); // Uses just the interface

logic avail;
always @(posedge a.clk) // the clk signal from the interface
a.gnt <= a.req & avail; // a.req is in the simple_bus interface
endmodule
Module with interface a

Access interface signals by name.signal
module cpuMod(simple_bus b);

...
endmodule
module top;
logic clk = 0;
simple_bus sb_intf1(clk); // Instantiate the interface
simple_bus sb_intf2(clk); // Instantiate the interface
memMod mem1(.a(sb_intf1)); // Connect bus 1 to memory 1
cpuMod cpu1(.b(sb_intf1));
memMod mem2(.a(sb_intf2)); // Connect bus 2 to memory 2
cpuMod cpu2(.b(sb_intf2));
endmodule
2 simple_bus instances
cpu/memory pair 1
cpu/memory pair 2
Notes:
Slide 89
Interface methods (Task/function)

SystemVerilog supports access methods to be defined for controlling ports at any level
of abstraction. These may be defined in the interface OR in connecting modules.
logic req, gnt;
interface with methods
logic [1:0] mode;
logic start, rdy;
task masterRead(input logic[7:0] raddr); // masterRead method
// ...
endtask: masterRead
task slaveRead; // slaveRead method
// ...
endtask: slaveRead
module memMod(simple_bus a); // Uses simple_bus interface
logic avail;
a.gnt <= a.req & avail; // the gnt and req signals in the interface
always @(a.start)
a.slaveRead;
endmodule

enum {read, write} instr;
logic [7:0] raddr;
always @(posedge b.clk)
if (instr == read)
b.masterRead(raddr); // call Interface method
...
endmodule
Modules with
simple_bus interface
module top;
logic clk = 0;
simple_bus sb_intf(clk); // Instantiate the interface
memMod mem(.a(sb_intf));
cpuMod cpu(.b(sb_intf));
endmodule
Notes:
Slide 90
System Example: UART

For the next several labs we'll be modeling a simplified UART system, first behaviorally
and then RTL. Our simulation goal is to send strings of characters down the serial link
Here's a simple block diagram of the system (Only one direction for simplicity):
Stimulus
generator
Serial link
Response
check
At the behavioral level, we might abstract the serial link to a ridiculously trivial level
bit [0:31][7:0] serial_link;
initial
serial_link = "Mr Watson, come here...");
always @(serial_link)
if (serial_link === "Mr Watson, come here...")
$display("Correct string received")'
This is a silly abstraction but it does make you think: What if, at the highest level
testing were as simple as this?
What if, as we progress from algorithm-model to RTL, we were able to always test
from such a familiar abstract level, freeing our test language from low-level details
of the UART interface etc
Notes:
Slide 91
UART beh. interface with methods

To begin, the serial link is an obvious target for an SV interface. If we define an interface
to contain the signal-level details, we can add methods (tasks) to allow stimgen and
response_check to transact at a higher level. This is Transaction Level Modeling (TLM)
top_level
valid
I/F: rs232_beh
Serial link
stimgen
send_string
rcv_string
send_string
response_check
module stimgen( rs232_beh f);

initial
begin
@(posedge f.reset);
@(negedge f.reset);
f.send_string("Mr Watson, come here...");
f.send_string("I want to see you. ");
bit vector holds

up to 32 characters
interface rs232_beh;
bit [0:31][7:0] string;
logic valid = 0;
bit reset;
module response_check(
endmodule
Simple synch. signal
task send_string(input bit [0:31][7:0] text);

wait(valid ==0);
string = text;
valid = 1;
valid keeps
endtask
send and rcv
accesses in synch.
task rcv_string(
endtask
send_string
method
end
endmodule
rcv_string
rcv_string
method
endinterface
Notes:
Slide 92
Lab 4 (beh_uart): beh_uart.sv

Working directory: interface/beh_uart
Purpose: Introduction to interfaces
Instructions:
1.Edit the file "beh_uart.sv" and complete the behavioral model.
Add rcv_string method to interface (follow valid protocol)
Add response_check module (with calls to rcv_string)
Follow stimgen code as to structure.
Expected output
Correct
Correctstring
stringreceived:
received:
Correct
Correctstring
stringreceived:
received:
Mr
MrWatson,
Watson,come
comehere...
here...
I Iwant
wanttotosee
seeyou.
you.
Notes:
Slide 93
Lab 4 (UART) : beh_uart.sv

module top_level();
`timescale 1ns/1ns
bit clk, reset;
bit [0:31][7:0] string;
logic valid = 0;
bit reset;
wait(valid ==0);
string = text;
valid = 1;
endtask
endinterface
rs232_beh IB();
// Behavioral RS232 interface
stimgen ST1(IB);
// Behavioral transmitting host
assign IB.reset = reset;

initial
begin
clk = 0;
reset = 0;
forever #10 clk = !clk;
end

initial
begin
@(posedge f.reset);
@(negedge f.reset);
end
initial
begin
repeat(20) @(negedge clk);
reset = 1;
reset = 0;
end
endmodule // top_level
endmodule
Notes:
Slide 94
In this section
Enhancements
Time specifiers
$root
Notes:
Slide 95
Hierarchy
SystemVerilog adds several enhancements to design hierarchy:
A global declaration space $root

Variables defined within $root are visible to all modules
throughout hierarchy
timeunit and timeprecision specifications bound to modules
Interfaces to bundle connections between modules
Other enhancements ( not supported in VCS 7.1beta ) are:
Nested module declarations (declare one module inside another)

Simplified named port connections, using .name
Implicit port connections, using .*
Notes:
Slide 96
$root
In Verilog, all code (except `compiler directives) is contained in modules.
SystemVerilog defines a top-level called $root which exists outside of but
contains any/all design code. It typically spans multiple files.
$root may contain:
Explicitly declared & instantiated modules
Un-instantiated module declarations (auto-instantiated at $root)
Compatible with Verilog
Interfaces
Task, Function declarations, accessible throughout hierarchy
Constants, parameters and other global definitions
Gate, net, variable declarations, visible throughout design hierarchy
Typedefs in $root are allowed
$root variables may be accessed via $root.<var>
SV features unsupported in the current release
Procedural statement block (more later)
NOTE: In $root initial/always blocks are illegal
Notes:
Slide 97
Usefulness of $root?
1. As an abstract communication layer 'above' the hardware
behavioral modeling
testbench structure/control
2. Correct location for:
global functions & tasks
global typedefs
interface declarations
Implicit instantiation of global modules (Verilog 95 compat.)
NOTE
SystemVerilog encourages/expects the use of global typedefs (in $root).
BEWARE! This may require a specific order for file compilation!
Notes:
Slide 98
typedef struct{ logic [9:0] addr;

logic[31:0] data;
} global_pkt;
global_pkt root_pkt;
$root example
typedef in $root
task global_task (input global_pkt in1);

$display($stime,,"addr: %h, data: %h",in1.addr, in1.data);
endtask
module test;
Structure member reference
global_pkt b;
local1 U1();
initial
begin
#10 b.data = 1; b.addr = 1;
global_task(b);
end
endmodule
Local declarations of global typedef
module local1;
logic [7:0] x;
global_pkt y;
initial
begin
#20 y.data = 2; y.addr = 2;
global_task(y);
#20;
$root.root_pkt.data = 3;
$root.root_pkt.addr = 3;
global_task($root.root_pkt);
Local references to global task
// Global variable references

// are NOT synthesizable
10 addr: 001, data: 00000001

20 addr: 002, data: 00000002
40 addr: 003, data: 00000003
end
endmodule
$root.< > reference to global struct

Notes:
Slide 99
typedef in $root
typedef struct{ logic [9:0] addr;

logic[31:0] data;
} packet;
module beh_sram(input packet ip,
output packet op,
input bit cs, rw_);
packet ret_pkt;
bit doit;
reg [31:0] mem [0:1023];
always @(posedge cs)
if(rw_ ) // read
begin
ret_pkt.data = mem[ip.addr];
ret_pkt.addr = ip.addr;
op <= #5 ret_pkt;
end
else
// write
begin
mem[ip.addr] <= ip.data;
end
endmodule
module tb;
bit cs, rw_;
packet in_pkt, out_pkt;
beh_sram.sv
revisited
beh_sram U1(.ip(in_pkt), .op(out_pkt), .cs(cs), .rw_(rw_));

task wr_pkt(input logic [9:0] addr, logic[31:0] data);
rw_ = 0;
$display($stime,,"Writing %h to address %h",data, addr);
in_pkt = {addr,data};
cs = 1;
#1 cs = 0;
endtask
task rd_pkt(input logic [9:0] addr, logic[31:0] data);
in_pkt = {addr, 0};
rw_ = 1;
cs = 1;
#6;
if(out_pkt.data === data)
$display ($stime," Read successful: %h from address %h",
out_pkt.data, addr);
else
$display ($stime," Read failed: %h, expected: %h", out_pkt.data, data);
cs = 0;
endtask
initial
begin
$display("\n\n\n");
#10 wr_pkt(5,10);
#10 wr_pkt(1,2);
#10 rd_pkt(5,10);
#10 rd_pkt(1,2);
#10 wr_pkt('h1ff,'haaaa);
#10 rd_pkt('h1ff,'haaaa);
#10 $display("\n\n\n");
end
10 Writing 0000000a to address 005

35 Read successful: 0000000a from address 005
75 Read successful: 0000aaaa from address 1ff
endmodule
Notes:
Slide 100
Implicit port connections
SystemVerilog adds two new ways to reduce the chore of instantiation for the
common situation where port and connected signal match in name and size.
Consider this 4:1 mux:
module mux (output logic [2:0] out, input logic [2:0] a, b, c, d, sel);
Verilog 'by-name' instantiation (port d unconnected)

mux U1 ( .out(out), .a(a), .b(b), .c(c), .d(), .sel(sel) );
.name syntax instantiation
mux U2 ( .out, .a, .b, .c, .d(), .sel );
.* syntax instantiation
Unconnected port using 'by-name' syntax
mux U3 ( .*, .d());
Notes:
Slide 101
Implicit port connections 2
Both new SystemVerilog styles of instantiation require:

1.
2.
3.
Ports and their connecting variables must have same name and same width
Ports and their connecting variables must be of compatible type
Ports outside of the implicit list must be connected by port name (not order)
So, which to use, .name or .* ?

.name allows implicit connections but shows port & signal names for documentation
.* allows full wildcarding where listing port & signal names is not required
Notes:
Slide 102
Module-centric time specifiers

In Verilog, the `timescale directive has always caused problems.
(e.g a module can accidentally 'inherit' the `timescale of a previously
compiled module. )
SystemVerilog resolves this with an alternative to `timescale :
module timespec;
timeunit 1ns;
timeprecision 0.1ns;
// time accuracy local to this module !
initial
#5.19 $display(Current time is %f, $realtime); // SV3.1 will allow #5.19ns
endmodule
Current time is 5.200000
V C S S i m u l a t i o n
Time: 5200ps
R e p o r t
NOTE
timeunit & timeprecision are
local to a module, they are not
`directives that can affect
modules compiled later in
sequence.
Notes:
Slide 103
104
Notes:
Slide 104
Other
In this section
2-state simulation
C Operators
Event control
SV Event Queue
Reducing ambiguity
Combinational / Latch / Sequential
unique / priority qualifiers
Loops
break / return
Notes:
Slide 105
True 2-state simulation

SystemVerilog allows true 2-state simulation via new datatypes:
shortint, int, longint, byte, bit
To speed up functional verification, simply code with bit and int types
Simulators (including VCS) have offered pseudo 2state modeling but
results are not portable across simulators and certain assumptions
are always made.
SV makes it simpler!
Notes:
Slide 106
Literals
SystemVerilog allows easy specification of un-sized literal values
with the ( ) apostrophe:
0, 1, x, X, z, Z
// Notice, no base specifier needed
reg [23:0] a = z;
// All bits of a are set to z
String literals are written as in Verilog, between double quotes.

SystemVerilog adds new escaped characters:
" \v "
" \f "
" \a "
" \x02 "
// vertical tab
// form feed
// bell
// hexadecimal number
Notes:
Slide 107
Constants
SystemVerilog defines 3 types of constant:
localparam char colon1 = ":" ;
specparam int delay = 10 ;
const logic flag = 1 ;
// value is set at elaboration time (v2001)

// specparams are used within specify blocks (v95)
// declares a variable that is "non-changeable"
The const keyword effectively means the variable may not be written by user code.
It's value is set at run-time and it can contain an expression with any hierarchical path name.
const logic option = a.b.c ;
A const may be set during simulation within an automatic task (discussed later).
Notes:
Slide 108
String datatype
SV
3.1
String data type is a variable size array of characters, indexed from 0 to N-1 (N is array length).
Every element of the array is also a string
string st1, st2;
st1 = ;
st2 = abc;
st1 = { st1, st2 };
st2[0:1] = et;
// null string
// assigned from a string literal
// concatenation, st1 becomes abc
// st2 becomes etc
Supports relational operators (==, !=, <, <=, >, >=), concatenation ({}) and replication ({n{}})
e.g. (a<b) is true because a precedes b alphabetically.
By means of the . operator, strings support special methods:
len(), putc(), getc(), toupper(), tolower(), compare(), icompare(), substr(),
atoi(), atohex(), atooct(), atobin(), atoreal(),
itoa(), hextoa(), octtoa(), bintoa() and realtoa()
Notes:
Slide 109
Enumerated type
SystemVerilog provides enumeration as a very useful way of defining abstract variables.
Define an enumeration with enum (defaults to int type)
enum {red, green, yellow} traf_lite1, traf_lite2;
NOTE:
Default assigned values start at zero
Values can be cast to integer types and auto-incremented

enum { a=5, b, c} vars;
// b=6, c=7
0
1
2
enum {red, green, yellow} lite;
A sized constant can be used to set size of the type

enum {bronze=4h3, silver, gold} medal; // All medal members are (must be) 4-bits
QUESTION
What if this was declared:
Enumerated Type
typedef enum {YES, NO} boolean
Define a new type

typedef enum {NO, YES} boolean;
boolean myvar;
// boolean is NOT a SystemVerilog type

// but it just became one
myvar will now be checked for valid values in all

assignments, arguments and relational operators
Answer: No problem, but it is counterintuitive that YES should have value 0, and NO 1
Notes:
Slide 110
Enumeration (2)
Consider this enumeration
enum {red, green, yellow} lite1, lite2;
// anonymous int type assumed
Default anonymous int type cannot be assigned x or z

enum { a, b=x, c=z} vars;
// ILLEGAL assignment to x or z
enum logic { a, b=x, c=z} vars;
// legal assignment to x & z of logic type
An auto-incremented value cannot be assigned elsewhere
enum {bronze=4h3, silver, gold=4h4} medal; // ILLEGAL: silver and gold BOTH 4
enum {bronze=4h3, silver, gold=4h5} medal; // redundant but correct
NOTE
While int is the default type of an enum, all SV types are supported.
enum bit[7:0] {red = 7b0, grn, blu} RGB
Notes:
Slide 111
Good uses of enum

Finite State machines
Replace parameters as symbolic names
Strongly-typed preventing mis-assignment
enum [1:0] { S0, S1, S2 } state, next_state;
Symbolic names for indexing

Easier to read
Strong-typing benefits
typedef enum {b1=1,b2,b3,b4,b5,b6,b7,b8} byte_lane;
bit [8:1][7:0] bus;
initial
begin
$monitorh(bus);
bus = 'b0;
#10
bus[b1] = 'haa; // load LS Byte
#10
bus[b8] = 'hbb;// load MS Byte
#10;
end
0000000000000000
00000000000000aa
bb000000000000aa
Notes:
Slide 112
Parameters and redefinable data types

SystemVerilog extends Verilog parameters to allow their use as types.
This example shows a fifo, whose depth AND TYPE are parameterized:
module fifo ( input logic [31:0] datin, bit r_w, clk,
output logic [31:0] datout );
parameter depth = 32;
parameter type ft = bit;
// define this fifo as of type bit by default
ft [31:0] mem [(depth-1):0]; // declare fifo array & type (bit by default)
...
endmodule
module use_fifo;
logic [31:0] i, o;
bit clk, r_w;
fifo #(.depth(64), .ft(logic)) // override parameter ft as type logic
U1(.datout(o), .datin(i), .clk(clk), .r_w(r_w));
endmodule
Notes:
Slide 113
Enhanced directives
SystemVerilog extends `define macros to allow construction of strings and
identifiers.
For example:
module enh_direct;
bit[2:0][7:0]a[3:0];
int b;
byte c;
sig is an argument of this macro
`define p(sig) " sig: %0h",sig," "

initial
2 insertions of argument
begin
b = 1;
c = 2;
$display($stime, `p(a[3][2]), `p(b), `p(c) );
end
10 a[3][2]: 0 b: 1 c: 2
endmodule
Notes:
Slide 114
Operators
In addition to the standard Verilog operators, SystemVerilog adds C operators:
Assignment:
Bump:
+=, -=, *=, /=, %=, &=, ^=, |=, <<=, >>=, <<<=, >>>=
// Implemented as blocking assignments
++a, --a, a++, a
// available as blocking assignments only
NO RHS timing constructs
Power:
**
Also, assignments may be used in expressions:
b = 1;
if( (a=b) )
WARNING: While 'cool' in principle, this creates a HUGE likelihood for mistakes
// notice the double-parens!!

// ONLY blocking assignments and NO timing constructs
$display(b is true, and now, so is a);
Notes:
Slide 115
New assignment operators

SystemVerilog extends standard Verilog assignment syntax like C/C++:
Consider: logic signed [3:0] a = 2; // 4b0010
logic signed [3:0] b = 3; // 4b0011
Then each of these individual assignments would work as follows:
a = b;
a *= b;
a /= b;
a %= b;
a += b;
a -= b;
// a <// a <// a <// a <// a <// a <-
a <<= b-1;
a >>= b;
a &= b;
a ^= b;
a |= b;
// a <- 16
// a <- 0
// a <- 2
// a <- 1
// a <- 3
3
6
0
2
5
-1
Notes:
Slide 116
New bump operators
SystemVerilog also adds bump operators ala C/C++. These may be used in expressions
but may NOT be associated with timing controls:
module pre_post_inc;
integer a;
++i
--i
// pre increment
// pre-decrement
i++
i--
// post-increment
// post-decrement
initial
begin
a = 3;
$display("%0d", a);
$display("%0d", a++, " <-post increment");
$display("%0d", a);
a = 3; $display("");
$display("%0d", a);
$display("%0d", ++a, " <-pre increment");
$display("%0d", a);
end
endmodule
3
3 <- post increment
4
3
4 <- pre increment
4
Notes:
Slide 117
Event Control - iff
SystemVerilog adds conditionals to standard Verilog event control:

Event conditionals:
q
Transp
latch
always @(d iff en == 1)

q <= d; // transparent latch (not sensitive to en)
en
- Here the event expression triggers only if the conditional is met at that instant.
- Useful simulation speedup ( avoid unnecessary assignments to q )
Notes:
Slide 118
Procedural Assignment Quiz 1

always
always@
@(posedge
(posedgeclk)
clk)
aa==b;
b;
always
always@
@(posedge
(posedgeclk)
clk)
bb==c;c;
After the first @ (posedge clk)

what is the value of a?
Notes:
Slide 119

always
always@
@(posedge
(posedgeclk)
clk)
begin
begin
aa==b;
b;
bb==a;
a;
end
end
After the first @ (posedge clk),

does this do a swap?
Notes:
Slide 120

b
#2
10
20
40 41
1:
always @ (b)
a = b;
2:
always @ (b)
#2 a = b;
3:
always @ (b)
a = #2 b;
4:
always @ (b)
a <= b;
5:
always @ (b)
#2 a <= b;
6:
always @ (b)
a <= #2 b;
12
22
42 43
Draw the waveform of a for each code snippet

10
20
40 41
b
1
:
2
:
Notes:
3
:
4
:
5
:
always @ (b)
a = b;
always @ (b)
#2 a = b;
always @ (b)
a = #2 b;
always @ (b)
a <= b;
always @ (b)
#2 a <= b;
always @ (b)
a <= #2 b;
Slide 121
Procedural Assignments
WHDL's famous rules of thumb:
always @(a or b)
c = a & b;
always @(posedge clk)

q <= #2 d;
Blocking assignments for combinational logic

and NO combinational delay
Non-blocking assignments for sequential logic

Optional small sequential delay on RHS only
Notes:
Slide 122
Continuous Assignments
In Verilog, continuous assignments apply only to wires.
SystemVerilog allows continuous assignments to all data types INCLUDING registers.
reg a, b;
bit enable;
assign a = enable ? b : z;
A variable may only be driven by a single continuous assignment or by one output port.
Variables may not also be initialized or assigned in procedural code
logic a = 0, b;
bit enable;
assign a = enable ? b : z; // ILLEGAL because a was initialized
module uu (input logic b, output logic a); // dummy module
endmodule
uu U1(.a(a), .b(b)); // ILLEGAL because a is driven by contin. assign above (and initialized )
Notes:
Slide 123
Loops
SystemVerilog supports standard Verilog loop constructs: repeat, forever, while and for
but also adds:
do <statement> while <expression>
Like a while loop, but evaluates after the loop executes rather than before.
examples
while (i < 10)

begin
i = i +1;
end
Loop would NEVER

execute if i >= 10
So programmer has to
setup value of i before loop
do
begin
i = i +1;
end
while (i < 10) ;
Guaranteed to execute
AT LEAST once
Notes:
Slide 124
for loop
SystemVerilog allows the loop variable to be declared within the loop.
Verilog 2001:
int j;
initial
for ( j = 0; j <= 20; j = j+1) // j is global and could be accidentally
// modified elsewhere
$display(j);
SystemVerilog:
initial
for ( int j = 0; j <= 20; j++) // j is local
$display(j);
Never again worry about double-use of
a variable because of CUT/PASTE
Notes:
Slide 125
disable, break & continue

The use of disable to terminate a loop is discouraged for style and other reasons.
Instead, System Verilog adds C-like constructs: break and continue.
These offer similar functionality but do NOT require an explicit block/task name.
for ( i=0; i<52; i++ )

begin
a = 1;
#5 case(b)
1: continue;
0: break;
endcase
a = 0;
end
jump to next iteration of loop
exit the loop (as in C )

NOTE
break and continue may only
be used inside a loop
Notes:
Slide 126
return
Within a function we can specify a return value by assignment to the function-name
or by using the new C-like return.
Tasks containing a return statement will terminate when the return is executed.
function bit uniq_vals;

input[7:0] a,b;
uniq_vals = 0;
if ((a !=b)
return (1); // a,b unique
endfunction
Notes:
Slide 127
128
Notes:
Slide 128
RTL
In this section

always_comb - Combinational
always_latch - Latch
always_ff - Sequential
unique / priority qualifiers
Notes:
Slide 129

SystemVerilog has several special purpose always derivatives which remove the
ambiguity that RTL designers have had to live with:
Combinational logic:
always_comb <statement> // NB: Follow standard latch avoidance style for synth
//
simulator can now warn of latch inference
Latch logic:
always_latch <statement> // latch inference doesnt trigger a simulator warning
- the sensitivity list is every variable read by the statement

- triggered once at t0 after every other initial/always block has started
- variables written in one of these blocks may not be written by any other process
Edge Sensitive:
always_ff @(posedge clk or negedge rst)
q <= !rst ? 0 : d;
- only one event control may be used in the procedure
Notes:
Slide 130
Statement labels and named blocks

Verilog has always provided for naming a block of procedural code by naming the begin
or fork statement that precedes it. SystemVerilog allows the name to appear at end as well:
initial
begin: hier_name
a = 0;
$display(hello);
end: hier_name
Gives the code in this block

a hierarchical name
Allows for local variables and
use of the disable statement
initial
fork: hier_name
a = 0;
$display(hello);
join: hier_name
SV allows for the name to appear after the block for

improved documentation and compile-time checking
More importantly, SystemVerilog allows any statement to be labeled as in C:

initial
begin
label1:
end
label: syntax
b = bus_b;
NOTES:
1. begin or end statements may be labeled but NOT if
they are also named.
2. Verilog allows local variables to be defined within a
named_block. SystemVerilog allows local variables
to be declared inside ANY begin..end, fork..join block
Notes:
Slide 131
Example: always_comb
module test_always_comb;
logic [7:0] a=0,b=0,c,d;
always_comb
begin
$display($stime,,"always_comb: func(%d)",a);
c = func(a);
end
always @*
begin
$display($stime,,"always @*: func(%d)",a);
d = func(a);
end
function logic[7:0] func (logic[7:0] a);
return a & b;
endfunction
initial begin
$monitor($stime,,"a:%d, b:%d, | c:%d, d:%d \n",a,b,c,d);
#10 a = 1;
#10 b = 1;
#10 a = 0;
#10 a = 1;
#10 $stop;
end
endmodule
NOTE
always_comb is sensitive to
variable changes within
functions ( unlike @* )
0 always_comb: func(
0 always @*: func( 0)
0 a: 0, b: 0, | c: 0, d:
0)
0)
0)
0
@*: triggered by a=0

comb: triggered at T0
triggered by a = 0
triggered by b = 0
10 always_comb: func( 1)
10 a: 1, b: 0, | c: 0, d: 0
@*: triggered by a -> 1

comb: triggered by a -> 1
20 a: 1, b: 1, | c: 1, d: 0
comb: triggered by b -> 1
30 a: 0, b: 1, | c: 0, d: 0

40 a: 1, b: 1, | c: 1, d: 1

Notes:
Slide 132
Better Coding Style : always_comb

always @*
begin
do_this
do_that
do_the_other
end
always_comb
begin
do_this_func();
do_that_func();
do_the_other_func();
end
Long, convoluted procedural block

Hard to read
Not easily reusable
Functions, if present, complicate sensitivity list
Shorter structured procedural block

More easily read/written
Reuse friendly (extract any function)
Notes:
Slide 133
Case (unique, priority qualifiers)
Allowed but ignored
Verilog case statement variants case, casex & casez are enhanced to improve
synthesis results. This should allow identical interpretation by simulators, synthesis tools
and others without the ambiguities of Verilog 95:
bit[2:0] a
unique case(a)
// values for a of 3,5,6 or 7 produce runtime warnings
0,1: $display(0 or 1);
VCS7.1b does not give runtime warnings
2: $display(2);
4: $display(3);
endcase
// unique - checks to ensure no overlapping case values
priority casez(a)
3b00?: $display(0 or 1);
3b0??: $display(2 or 3);
default: $display(4, 5, 6 or 7);
endcase
// priority act on first match and ignore others if any.
NOTE
These qualifiers should obsolete the synthesis pragmas:
// syn parallel_case full_case
A good coding style is to avoid using ANY of these pragmas/qualifiers by writing
completely thorough case/if-else structures
Notes:
Slide 134
if-else (unique, priority qualifiers)
Allowed but ignored
Just as with case statements, SystemVerilog allows qualifiers to the if statement.

bit[2:0] a;
unique if ((a==0) || (a==1))
$display(0 or 1);
else if (a==2)
$display(2);
else if (a==4)
$display(4);
// values for a of 3, 5, 6 or 7 produce runtime warnings
priority if (a[2:1]==0)
$display(0 or 1);
else if (a[2]==0)
$display(2 or 3);
else $display(4 to 7); // covers all possible values, so no error
If either unique or priority is used and there is no explicit else, a run-time error triggers
if no match occurs.
Notes:
Slide 135
Lab 5 - Updated FSM

Working directory: fsm
Purpose: Rewrite fsm_ex.v to full SV specification
Instructions:
Copy/modify the existing file to make fsm_ex.sv as follows:
1. Testbench: test_fsm_ex.sv
2. Implement fully ANSI compatible ports
3. Update data-types ( e.g. state variables to enum) as appropriate
4. Use new always block styles ( always_ff, always_comb )
5. Qualify the next_state logic using unique
6. Implement output decode logic using continuous assignments ( to a, b)
7. Compare the output between the old and new versions.
Are they identical?
Notes:
Slide 136
Lab 5 fsm_ex.sv (expected output)

00 xx clk:
clk: 00 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: xx ,outb:
,outb: xx
100
x
clk:
1
,rst:
0
,in1:
0
,in2:
0
,outa:
x
,outb:
100 x clk: 1 ,rst: 0 ,in1: 0 ,in2: 0 ,outa: x ,outb: xx
101
101 00 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
200
0
clk:
0
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
200 0 clk: 0 ,rst: 0 ,in1: 0 ,in2: 0 ,outa: 0 ,outb: 00
300
300 00 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
400
0
clk:
0
,rst:
1
,in1:
0
,in2:
0
,outa:
0
,outb:
500
500 00 clk:
clk: 11 ,rst:
,rst: 11 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
600
0
clk:
0
,rst:
1
,in1:
0
,in2:
0
,outa:
0
,outb:
700
700 00 clk:
clk: 11 ,rst:
,rst: 11 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
800
0
clk:
0
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
900
900 00 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
1000
0
clk:
0
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
1100
1100 00 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
1200
0
clk:
0
,rst:
0
,in1:
1
,in2:
0
,outa:
1
,outb:
1300
1300 00 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 11 ,in2:
,in2: 00 ,outa:
,outa: 11 ,outb:
,outb: 00
1301
1
clk:
1
,rst:
0
,in1:
1
,in2:
0
,outa:
0
,outb:
1400
1400 11 clk:
clk: 00 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 11 ,outa:
,outa: 00 ,outb:
,outb: 11
1500
1
clk:
1
,rst:
0
,in1:
0
,in2:
1
,outa:
0
,outb:
1501
1501 22 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 11 ,outa:
,outa: 00 ,outb:
,outb: 00
1600
2
clk:
0
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
1700
1700 22 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
1701
0
clk:
1
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
1800
1800 00 clk:
clk: 00 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 00
1900
0
clk:
1
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
2000
2000 00 clk:
clk: 00 ,rst:
,rst: 00 ,in1:
,in1: 11 ,in2:
,in2: 00 ,outa:
,outa: 11 ,outb:
,outb: 00
2100
0
clk:
1
,rst:
0
,in1:
1
,in2:
0
,outa:
1
,outb:
2101
2101 11 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 11 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 11
2200
1
clk:
0
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
2300
2300 11 clk:
clk: 11 ,rst:
,rst: 00 ,in1:
,in1: 00 ,in2:
,in2: 00 ,outa:
,outa: 00 ,outb:
,outb: 11
2301
0
clk:
1
,rst:
0
,in1:
0
,in2:
0
,outa:
0
,outb:
Notes:
Slide 137
138
Notes:
Slide 138
In this section
Task enhancements
Function enhancements
Recursion
Default arguments (3.1)
Explicit calls
Pass by reference (3.1)
Data scope and lifetime
Notes:
Slide 139
Tasks & Functions
Fully Verilog compatible

Default type is logic but all SV types are supported
Extensions to address limitations
System Verilog type support
Dynamic memory allocation (recursion allowed)
Default input values
Default argument values
Argument pass-by-reference
SV
3.1
Notes:
Slide 140
Tasks (new features)

SystemVerilog makes a number of extensions to basic Verilog syntax.
ANSI-C style formal declarations (plus a new one: ref in SV3.1)

Arguments can be any SystemVerilog type (default is logic)
Default direction is input
task-endtask implies a begin-end structure
return statement can end the task call before endtask
task write_vector( input int data,

logic[11:0] addr);
@(negedge clk);
if (bus_error) return;
// cancel operation if bus_error true
data_bus = data;
addr_bus = addr;
return is supported in tasks but NOT return(value)
write = 1;
@(posedge clk);
#5 write = 0;
endtask
Notes:
Slide 141
Tasks (Recursion)
SystemVerilog makes major extensions to basic Verilog syntax.
Supports automatic keyword (from Verilog 2001)
Unlike Verilog, all local variables are dynamically declared.
Full recursion is supported (automatic variables/arguments stored on stack)
task automatic my_task( input int local_a,
int local_b);
if (local_a == local_b)
begin
my_task(local_a-1,local_b+1);
return;
end
global_a = local_a;
global_b = local_b;
// detect where arguments are identical

// fix by incrementing/decrementing
// end this copy of task
// drive the outputs
endtask
Notes:
Slide 142
Minilab automatic task

Working directory: tasks
Purpose: See for yourself what an automatic task means...
Instructions:
Compile/simulate the two example modules in the working directory.
vcs R +sysvcs auto_task.sv
vcs R +sysvcs seq_task.v
See if you can understand what is going on in each case!
Notes:
Slide 143
Task example : auto_task.sv

task automatic super_task( input [3:0] a,
output [3:0] b );
task classic_task;
input [3:0] a;
output [3:0] b;
begin
#10 b = a;
$display ($stime,,"Input: %h,
Output: %h", a,b);
end
#10 b = a;
Output: %h", a,b);
endtask
endtask
1. ANSI style ports

2. Implicit begin-end
3. Dynamic memory allocation
logic [3:0] out_1, out_2;
initial
fork
classic_task (4, out_1);
// input value 4
#5 classic_task (8, out_2); // input value 8
join
initial
fork
super_task( 4, out_1 );
// input value 4
#5 super_task (8, out_2); // input value 8
join
10
10Input:
Input:8,8, Output:
Output:88
15
15Input:
Input:8,8, Output:
Output:88
25
25Input:
Input:4,4, Output:
Output:44
30
30Input:
Input:8,8, Output:
Output:88
Notes:
Slide 144
Task example : seq_task.v

task classic_task;
input [3:0] a;
output [3:0] b;
Obviously this problem must exist in SV for compatibility

but it is NOT a problem with automatic variables because
Non-blocking assignments are not allowed to automatic variables

begin
#10 b = a;
a <= a + 1; // increment the input
Output: %h", a,b);
end
endtask
initial
begin
#5
end
// input value 4
// input value 8
15
15Input:
Input:5,5, Output:
Output:55
25
25Input:
Input:6,6, Output:
Output:66
Notes:
Slide 145
Functions
function automatic int factorial (int n);
if (n==0) return(1);
// factorial 0 is 1
else return(factorial(n-1)*n);
endfunction
Extends the basic Verilog function syntax.
ANSI-C style formal declarations (plus new one: ref in SV3.1)

Arguments can be any SystemVerilog type
Return value can be a structure or union
Default direction is input, but also supports output
Function-endfunction implies a begin-end structure
return statement supported as well as assignment to function name
Supports automatic keyword, allowing recursion just like tasks
Supports void return values
Notes:
Slide 146
Data Type: void

void
The void datatype represents a non-existent value.
It is used in function declarations to indicate that they do NOT return a value.
In Verilog is was common to discard a functions return value by assigning
it to a junk variable no longer
function void invert();
// Invert the image ( pos -> neg, neg -> pos )
for(int ver=1; ver <= 150; ver++)
for(int hor=1; hor <= 400; hor++)
begin
vidbuf[ver][hor].R = 255 - vidbuf[ver][hor].R; // invert
vidbuf[ver][hor].B = 255 - vidbuf[ver][hor].B; // invert
vidbuf[ver][hor].G = 255 - vidbuf[ver][hor].G; // invert
end
endfunction
initial
invert(); // function called like a task
Notes:
Slide 147
module super_func;
int n;
parameter MAX = 10;
Functions (direct calls)
initial
begin
$display("The factorials from 1 to %d", MAX);
for (n=0; n<=MAX; n=n+1)
$display("%d! = %d", n, factorial(n));
$display("And again, the factorials from 1 to %d", MAX);
v_factorial(MAX);
end
function automatic int factorial (int n);
if (n==0) return (1); // factorial 0 is 1
else return (factorial(n-1)*n);
endfunction
Function calls itself

recursively
function automatic void v_factorial (int m);

for (n=0; n<=m; n=n+1)
$display("%d! = %d", n, factorial(n));
endfunction
endmodule
The factorials from 1 to

10
0! =
1
1! =
1
2! =
2
3! =
6
4! =
24
5! =
120
6! =
720
7! =
5040
8! =
40320
9! =
362880
10! = 3628800
And again, the factorials from 1 to
0! =
1
1! =
1
2! =
2
3! =
6
4! =
24
5! =
120
6! =
720
7! =
5040
8! =
40320
9! =
362880
10! = 3628800
10
Notes:
Slide 148
Task/function default arguments
SV
3.1
SystemVerilog allows specification of default argument values for subroutines.

If an argument is passed to the task/function it overrides the default.
Notice Verilog placeholder syntax has a new significance for default arguments:
task do_this( input int data = 0, addr = 0,
logic[1:0] ctrl = 2'b10);
endtask
// both default to 0
// default to 2
Notice Verilog placeholder syntax has a new significance for default arguments:
initial
begin
do_this(5,2,0);
do_this(5,2);
do_this( , ,0);
end
// data(5), addr(2), ctrl(0)

// data(5), addr(2), default: ctrl(2)
// ctrl(0) default: data(0), addr(0),
Notes:
Slide 149
Task/function - explicit calls

int x,y,z;
function bit f_compare ( input int n,
int m = 5 );
if ( n === m ) return(1); else return(0);
endfunction
function void vf_compare ( input int n,
int m = 5 );
if ( n === m ) z = 1; else z = 0; // global!
endfunction
task t_compare ( input
int a = 0,
int b = 1,
output int c );
if ( a === b )
c = 1;
else
c = 0;
endtask
int a = f_compare( x, y );
int b = f_compare( .m(5), .n(5) );
int c = f_compare( .n(3) );
// n=x, m=y implicit

// n=5, m=5 explicit
// n=3, m=5 explicit
initial begin
#10 t_compare( 1, 8, z );
#10 t_compare( .b(2), .a(4), .c(z) );
#10 t_compare( .c(z), .a(1) );
#10 vf_compare(.n(9) );
end
// a=1, b=8, c=z

// a=4, b=2, c=z
// a=1, b=1, c=z
// n=9, m=5
SV
3.1
implicit
explicit
explicit
explicit
NOTE
SystemVerilog 3.1 allows
tasks and functions to be
called with a syntax similar
to module instantiation-byport-name
Cannot mix explicit and
implicit parameter-passing
styles
Notes:
Slide 150
Task/Function pass by reference
SV
3.1
Tasks and functions can be passed an argument by 2 means:

Pass by value (Verilog compatible)
Copy each argument into the subroutine 'space'
If subroutine is automatic, then subroutine retains a local copy on stack
If arguments change within subroutine, this is invisible outside the subroutine
At end of subroutine, inout/output arguments are returned by value
Obviously inefficient for larger arguments
Pass by reference
Arguments passed by reference are not copied into the subroutine 'space'
Subroutine accesses the argument data via the reference
If arguments change within subroutine, original updates immediately
Reference is indicated by ref keyword
task/function <name> ( input/output/ref [type] <name>, );
end{task/function}
Tasks also support inout
Notes:
Slide 151
Pass by reference - examples
SV
3.1
function int crc( ref byte packet [1000:1] );

for( int j= 1; j <= 1000; j++ ) begin
crc ^= packet[j];
end
endfunction
const is used here to prevent modification of the reference/original
and is legal for both tasks and functions
task show ( const ref byte[7:0] data );

for ( int j = 0; j < 8 ; j++ )
$display( data[j] ); // data can be read but not written
endtask
Notes:
Slide 152
Static vs Automatic
In Verilog 2001 and of course in SystemVerilog, a variable can be:
static
storage allocated on instantiation and never de-allocated
automatic
stack storage allocated on entry to a task, function

or named block and de-allocated on exit.
As in Verilog, data items default to static, but SV allows use of the static
keyword within an automatic task/function/named block to override the
default for any variable.
Notes:
Slide 153
Data Scope and Lifetime

SystemVerilog has broader scope and lifetime variation than Verilog which is primarily
a static language.
The rules for SystemVerilog are as follows:
Data
Scope
Lifetime
Any data declared outside of a

module, interface, task or function
global
Data declared as automatic

(default for any declaration in
an automatic task or function)
local
duration of call **
Data declared as static
local
static
**
static
Data declared as automatic, even if inside a static task, function or block will have a lifetime the
same as the call. Automatic variables may not be used to trigger event expressions or be written
by a non-blocking assignment.
Notes:
Slide 154
Remember the histogram exercise?

module video1;
typedef struct packed {bit[7:0] R, X, B, G;} RGB;
RGB vidbuf[1:150][1:400] ; // Unpacked array of RGB structs
bit[7:0] hdr [1:56];
SV and V2001 File-I/O

NOTE
File-I/O can target arrays/structs
function void saveimg ();

// Save the new image to an output file
//
for(int i=1; i<57; i=i+4) //write 56-byte header
initial
begin
ìfdef SPARC
rfile = $fopen("i_mourne_32.bmp", "r"); // Open the image file
$fwrite(wfile,"%u",{hdr[i],hdr[i+1],hdr[i+2],hdr[i+3]});
wfile = $fopen("new_pic.bmp", "w");
// Open output img file èndif
Notice byte-swaps
i = $fread(hdr, rfile, 0, 56); // Read 56-byte header
ìfdef INTEL
$fwrite(wfile,"%u",{hdr[i+3],hdr[i+2],hdr[i+1],hdr[i]});
èndif
ìfdef SPARC
for(int ver=150; ver >= 1; ver--)
invert;
for(int hor=400; hor >= 1; hor--)
saveimg;
$fwrite(wfile,"%u",{vidbuf[ver][hor].R,
$fclose(rfile);
vidbuf[ver][hor].X,
$fclose(wfile);
$finish;
vidbuf[ver][hor].B,
end
vidbuf[ver][hor].G});
èndif
function void invert(); // Invert the image (pos-neg-pos etc)
ìfdef INTEL
Notice byte-swaps
begin
vidbuf[ver][hor].X = 'hf;
$fwrite(wfile,"%u",{vidbuf[ver][hor].G,
vidbuf[ver][hor].B,
vidbuf[ver][hor].X,
vidbuf[ver][hor].R});
end
endfunction
èndif
endfunction
endmodule
Notes:
Slide 155
Lab 6 histogram
Working directory: video6
Purpose: Derive histogram of the image.
Background:
In digital images, each pixel is described by 8-bit values of RED, GREEN & BLUE.
So, for a particular color plane, each pixel can be of value 0 (off) to 255 (full-on).
# of pixels
A popular means of measuring image content is called a histogram. This is a

bar-graph showing the number of pixels of each intensity (0-255) in a color plane.
0 1 2 3
. . . .
...
255
(Dynamic range)
Notes:
Slide 156
# of pixels
Lab 6 histogram
Instructions:
1.
2.
3.
. . . .
...
255
(Dynamic range)
Declare an unpacked array( 0:255) of type int called histogram.

Add function buildhist to video.sv to derive the histogram of the RED color plane
Using nested for loops implement the following algorithm within buildhist:
a)
b)
c)
4.
5.
0 1 2 3
Walk the entire video array (150x400) and count the number of pixels of
each intensity (0-255)
Find the largest of these numbers (most common pixel intensity N)
Determine an int value called scale from the formula: scale = N / 72
This will be used when drawing the histogram to scale the graph.
Return int scale value from function buildhist as shown on next page
Compile/run video.sv and view output file new_pic.bmp
Notes:
Slide 157
Lab 6 histogram
module video6;
typedef struct packed {byte R, X, G, B;} RGB;
RGB vidbuf[1:150][1:400] ; // Unpacked array of RGB
byte hdr [1:56];
// invert task not shown
// function saveimg not shown
function void painthist(input int scale);
// Paint histogram on top of image
//
int ver = 30, hor = 72; // centre hist on pic
for(int pixels=1; pixels<256; pixels++)
for(int i=1; i <= histogram[pixels]/scale; i++)
vidbuf[150 - ver - i][400 - hor - pixels] = 'hff;
endfunction
Expected output
initial
begin
rfile = $fopen("mourne_32.bmp", "r"); // Open the image file
wfile = $fopen("new_pic.bmp", "w"); // Open output img file
invert;
scale = buildhist() ; // Build histogram and return scale factor
painthist(scale);
painthist is a void function that

draws the histogram data in green
on top of the image.
saveimg;
$fclose(rfile);
$fclose(wfile);
$finish;
end
endmodule
Notes:
Slide 158
Revisited
In this section
Mailbox
Modports
Controlling methods by modports
Method import & export
Notes:
Slide 159
TLM downside & fix!

The rs232_beh example illustrates a limitation of TLM using SV 3.0
While enjoying the high-level of abstraction provided by method calls
we still need to synchronize those calls ( e.g. using the valid signal in earlier lab )
SV 3.1 will remedy this by providing a new feature called a "Mailbox" (More in Preview section)
A mailbox is an automatic FIFO queuing mechanism between threads
top_level
I/F: rs232_beh
Serial link
stimgen
send_string
response_check
send_mailbox
rcv_string
rcv_mailbox
Mailboxes allow stimgen and response_check routines to operate independently but never get out of synch
For example, an attempt by response_check to read an empty rcv_mailbox will block until a string arrives
Stimgen can queue up as many send_string calls as desired, they will always execute in the right order
or it might be setup to block stimgen until each send_string completes (send_mailbox FIFO depth == 1)
Notes:
Slide 160
UART 2 RTL interfaces

with methods
top_level
rs232_host_tx
stimgen
clk
send_string
rs232_host_rx
rs232tx
clock_gen
rs232rx
rcv_string
response_check
Serial clk
Here, at a later stage in development, 3 RTL UART modules have been written
rs232tx (serial transmit), rs232rx (serial receive), clock_gen (support circuitry)
2 new interfaces ( rs232_host_tx and rs232_host_rx ) connect the RTL UART code
to the original stimgen and response_check modules from the behavioral model.
This means the same test harness can operate on a behavioral --or-- RTL model of the system.
All code contained in the file: interface/rtl_uart/rtl_uart.sv
Notes:
Slide 161
interface rs232_host_tx(input wire clk, reset,

input wire tx_clk);
bit tx_clk;
logic load_request, load = 0, txd;
logic [7:0] tx_data;
UART rs232_host_tx
task send_string(input bit [0:23][7:0] txt);

integer i, ok;
load_request
for( i=0; i<= 23 ; i++ )

Interface:
begin
rs232_host_tx
ok = 0;
fork :ss_start
begin
Wait for load_request
wait(load_request) ok = 1;
disable ss_start;
-orend
timeout after 2000 tx_clks
begin
repeat(2000) @(posedge tx_clk);
load_request
disable ss_start;
end
join
load
if (!ok) $display("load_request timeout");
@(negedge clk);
tx_data = txt[i];
tx_data
@(negedge clk);
load = 1;
ok = 0;
serial_out
fork : ss_done
begin
@(posedge load_request) ok=1;
disable ss_done; //tout;
Wait for next load_request to
end
begin
indicate the last xfer completed
-ordisable ss_done;
timeout after 1000 tx_clks
end
join
if(!ok) $display("rs232txmit timeout");
@(negedge clk);
load = 0;
end
rs232_tx
tx_data
serial_out
load
clk
reset
data_byte
start_bit
stop_bit
endtask
endinterface
Notes:
Slide 162
UART rs232_host_rx
data_ready
rs232_rx
serial_in
rx_data
Interface:
rs232_host_rx
read
clk
rx_clk
reset
error_over_run
error_under_run
error_all_low
serial_in
rx_data
data_ready
read
error_over_run,
error_under_run,
error_all_low
interface rs232_host_rx(input wire clk, reset,

input wire rx_clk);
logic rxd, read = 0, data_ready, error_over_run,
error_under_run, error_all_low;
logic [7:0] rx_data;
task rcv_string(input bit [0:23][7:0] txt);
integer i, ok;
bit [0:23][7:0] rcvd_text;
ok = 0;
fork :rs_start
begin
@(posedge data_ready) ok = 1;
disable rs_start;
end
begin
repeat(2000) @(posedge rx_clk);
disable rs_start;
end
join
if (!ok) $display("rs232rcv timeout");
Wait for data_ready

-ortimeout after 2000 rx_clks
for(i=0; i<= 23; i++)

begin
ok = 0;
read = 1;
Start read operation
fork :rs_forkjoin
begin
disable rs_forkjoin;
end
Wait for data_ready
begin
-or@(negedge data_ready) ok=1;
1 of 3 possible error conditions
end
(timeout after 1000 rx_clks)
begin
@(posedge error_over_run) ok=2;
end
begin
@(posedge error_under_run) ok=3;
end
begin
@(posedge error_all_low) ok=4;
end
join
if(txt[i] !== rx_data)
$display("ERROR: Incorrect character, exp: %s, act: %s",txt[i], rx_data);
rcvd_text = {rcvd_text, rx_data};
read = 0;
case(ok)
8'h0: $display("rs232txmit timeout");
Display status:
8'h1: $display("%s",rcvd_text);
8'h2: $display("rs232txmit error_over_run");
8'h3: $display("rs232txmit error_under_run");
8'h4: $display("rs232txmit error_all_low");
endcase
end
rcvd_text = 0; // not reqd, just makes incoming message more readable
endtask
endinterface
Notes:
Slide 163
RTL top_level
module top_level(); //(stimgen, response_check);

bit clk,
reset;
wire sub_clk;
wire serial_link;
reg[4:0] freq;
rs232_host_tx I2(.clk(clk), .reset(reset), .tx_clk(sub_clk));
rs232_host_rx I3(.clk(clk), .reset(reset) , .rx_clk(sub_clk));
// RTL transmitting host interface

// RTL receiving host interface
rs232tx T1(.serial_out(serial_link), .tif(I2)); // RTL rs232 transmit

rs232rx R1(.serial_in(serial_link), .rif(I3));
// RTL rs232 receive
stimgen ST1(I2);
// (stimulus generator)
response_check RC1(I3);
// (response checker)
clock_gen CK(.clk(clk), .frequency(freq),
// RTL clock generator
.reset(reset), .clk_out(sub_clk));
initial
begin
clk = 0;
reset = 0;
freq = 4'd12;
end
initial
begin
reset = 1;
reset = 0;
end
top_level
rs232_host_tx
stimgen
clk
send_string
rs232_host_rx
rs232tx
clock_gen
rs232rx
response_check
rcv_string
Serial clk
Notes:
Slide 164
Minilab rtl_uart.sv
Working directory: interface/rtl_uart
Purpose: Verify correct simulation of the previous example...
M
MrM
MrMr
MrMr
W
MrMr
WaW
Wa
MrMr
Wat
Wat
MrMr
Wats
Wats
MrMr
Watso
Watso
MrMr
Watson
Mr
Watson
Mr Watson,
Watson,
MrMr
Watson,
Watson,
MrMr
Watson,
c
Mr
Watson,
Mr Watson, coc
Watson,
co
MrMr
Watson,
com
Watson,
com
MrMr
Watson,
come
Mr
Watson,
come
Mr Watson, come
Watson,
come
MrMr
Watson,
come
h
Watson,
come
MrMr
Watson,
come
heh
Mr
Watson,
come
Mr Watson, come herhe
Watson,
come
her
MrMr
Watson,
come
here
Watson,
come
here
MrMr
Watson,
come
here.
Mr
Watson,
come
here.
Mr Watson, come here..
Instructions:
Compile/simulate the example design:
vcs R +sysvcs rtl_uart.sv
Expected output
I
I I
I wI
Iw
I wa
I wa
I wan
I
wan
I want
I want
I want
I want
I want
t
I want
I want
to t
I want
I want
to to
I want
I want
to to
s
I want
I want
to to
ses
I want
se
I want
to to
see
I want
see
I want
to to
see
I
want
to
see
I want to see y
I want
see
I want
to to
see
yoy
I want
see
yo
I want
to to
see
you
I
want
to
see
you
I want to see you.
I want
see
you.
I want
to to
see
you.
I want to see you.
Notes:
Slide 165
UART : reduce to a single interface

So far we've seen a behavioral model (using one SV interface) of this system
and an RTL model (using 2 SV interfaces).
What would the RTL solution look like with just one interface?
This interface would encompass both rs232_host_tx and rs232_host_rx interfaces we've seen.
Lots of signals
( load_request, load, read, txd, rxd, data_ready, error_over_run, error_under_run, error_all_low, tx_data, rx_data )
May be hard to keep straight which signals belong to rs232tx and rs232rx modules.
To answer these kinds of problems SV defines modports.
An interface can contain any number of modports.
Each modport is like a port into an interface, helping modules that connect to that interface to
know which signals they need to connect to and the direction of those signals (read / write).
Signal direction as defined in a modport is from the point of view of the module using it
(hence the name modport).
NOTE
modports make most sense for larger complex interfaces and synthesis
Notes:
Slide 166
Modports
In any interfaced design, some modules drive the interface (master), some read from it
(slave) and some may do both. To keep things straight, SystemVerilog provides modport
lists. These can describe ports AND/OR interface access methods.
interface i2;
wire a, b, c, d, e, f;
modport master (input a, b, output c, d, e);
modport slave (output a, b, input c, d, f);
endinterface
Interface i2 with
master and slave modports
modport keyword implies how the ports are accessed
from the point of view of the module
The modport list name can be specified in a couple ways:

module m (i2.master i);
...
endmodule
module s (i2.slave i);
...
endmodule
module top;
i2 i;
m u1(.i(i));
s u2(.i(i));
endmodule
Specify modport list name

in module header
module m (i2 i);

...
endmodule
i is instance name of interface i2
module s (i2 i);

...
endmodule
Modport name indicates direction
Interface name acts as a type
module top;
i2 i;
m u1(.i(i.master));
s u2(.i(i.slave));
endmodule
Specify modport list name

in module instantiation
Notes:
Slide 167
Example Modports and simple port bundle

logic req, gnt;
logic [1:0] mode;
logic start, rdy;
modport slave ( input req, addr, mode, start, clk,
output gnt, rdy, inout data);
modport master( input gnt, rdy, clk,
output req, addr, mode, start, inout data);
module memMod (simple_bus.slave a); // interface name and modport name

logic avail;
a.gnt <= a.req & avail; // the gnt and req signal in the interface
endmodule
Declare module with slave

simple_bus interface a
module cpuMod (simple_bus.master b);

...
endmodule
modport list name specified in module header
Declare module with master

simple_bus interface b
2 modports of simple_bus
module top;
logic clk = 0;
initial repeat(10) #10 clk++;
memMod mem(.a(sb_intf)); // Connect the interface to the module instance
cpuMod cpu(.b(sb_intf));
endmodule
Notes:
Slide 168
Example Modports and simple port bundle 2

logic req, gnt;
logic [1:0] mode;
logic start, rdy;
modport slave ( input req, addr, mode, start, clk,
modport master( input gnt, rdy, clk,
module memMod (simple_bus a); // interface name and modport name

logic avail;
endmodule
Declare module with

simple_bus interface a
module cpuMod (simple_bus b);

...
endmodule
Declare module with

simple_bus interface b
2 modports of simple_bus
module top;
logic clk = 0;
modport list name specified in module instantiation
memMod mem (sb_intf.slave); // Connect the interface to the module instance

cpuMod cpu (sb_intf.master);
endmodule
Master/slave association
Notes:
Slide 169
Lab 7 (rtl_uart) : rtl_uart_1.sv

Working directory: interface/rtl_uart
Purpose: Create a new interface
Instructions:
Starting with the results of the previous lab, define a new interface combining
the features of two interfaces into one.
top_level
stimgen
clk
response_check
rs232_if
rcv_string
send_string
txmit
recv
rs232tx
rs232rx
clock_gen
Serial clk
Notes:
Slide 170
Lab 7 (rtl_uart) : rtl_uart_1.sv

top_level
stimgen
clk
response_check
rs232_if
rcv_string
send_string
txmit
recv
rs232tx
rs232rx
clock_gen
Serial clk
Expected output
Instructions:
Edit the file "rtl_uart.sv" and make the following changes.
1. Make one new interface ( rs232_if ) from 2 existing interfaces

1. Incorporate 2 tasks ( send_string, rcv_string) from existing interfaces
2. Declare 2 modports (txmit and recv)
2. Modify module top_level
1. Instantiate the new interface rs232_if
2. Edit instantiations of rs232tx and rs232rx modules to support modports
3. Edit portlists of rs232tx and rs232rx modules to new modport name rs232_if
M
MrM
MrMr
MrMr
W
MrMr
WaW
Mr
Wa
Mr Wat
Wat
MrMr
Wats
Wats
MrMr
Watso
Watso
MrMr
Watson
Watson
MrMr
Watson,
Watson,
MrMr
Watson,
Watson,
MrMr
Watson,
c
Watson,
MrMr
Watson,
coc
Watson,
co
MrMr
Watson,
com
Watson,
com
MrMr
Watson,
come
Watson,
come
MrMr
Watson,
come
Watson,
come
MrMr
Watson,
come
h
Watson,
come
MrMr
Watson,
come
heh
Watson,
come
MrMr
Watson,
come
herhe
Watson,
come
her
MrMr
Watson,
come
here
Watson,
come
here
MrMr
Watson,
come
here.
Watson,
come
here.
MrMr
Watson,
come
here..
I
I I
I wI
Iw
I wa
I wa
I wan
I
wan
I want
I want
I want
I want
I want
t
I want
I want
to t
I want
I want
to to
I want
I want
to to
s
I want
I want
to to
ses
I want
se
I want
to to
see
I want
see
I want
to to
see
I
want
to
see
I want to see y
I want
see
I want
to to
see
yoy
I want
see
yo
I want
to to
see
you
I
want
to
see
you
I want to see you.
I want
see
you.
I want
to to
see
you.
I want to see you.
Notes:
Slide 171
Controlling methods via modports pt1

Weve seen how modports can define/control portlists and directions. They may
also be used to control task access. Heres an interface with methods:
logic req, gnt;
logic [1:0] mode;
logic start, rdy;
modport slave (input req, addr, mode, start, clk,
output gnt, rdy,
inout data,
import task slaveRead(), task slaveWrite() );
Define methods to use

// import into module that uses the modport
modport master(input gnt, rdy, clk,

output req, addr, mode, start,
Define methods to use
inout data,
import task masterRead(input logic[7:0] raddr), // import requires the full task prototype
task masterWrite(input logic[7:0] waddr) ); // This requirement goes away in SV 3.1 !!!
task masterRead(input logic[7:0] raddr); // masterRead method
// ...
endtask
// ...
task slaveWrite;
endtask
//...
task masterWrite(input logic[7:0] waddr);
endtask
//...
endtask
Notes:
Slide 172
Controlling methods via modports pt2

module memMod(simple_bus a); // Uses just the interface
logic avail;
b.gnt <= b.req & avail; // the gnt and req signals in the interface
always @(a.start)
if (a.mode[0] == 1b0)
a.slaveRead;
else
a.slaveWrite;
endmodule
Method calls

enum {read, write} instr = $rand();
logic [7:0] raddr = $rand();
if (instr == read)
b.masterRead(raddr); // call the Interface method
// ...
module top;
else
logic clk = 0;
b.masterWrite(raddr);
endmodule
simple_bus sb_intf(clk);
memMod mem(.a(sb_intf.slave));
module omniMod(interface b);
cpuMod cpu(.b(sb_intf.master));
//...
omniMod omni(sb_intf);
endmodule: omniMod

// only has access to the slaveRead task
// only has access to the masterRead task
// has access to all master and slave tasks
endmodule
Notes:
Slide 173
Modport & import tasks rtl_uart_2.sv

interface rs232_if(input wire clk,
input wire reset,
input wire tx_clk,
input wire rx_clk);
logic load_request,
load = 0, read = 0,
txd, rxd,
data_ready, error_over_run,
logic [7:0] tx_data, rx_data;
Only the rs232_if interface has changed
modport txmit (output tx_clk, load, tx_data,

input load_request,
import task send_string(input bit [0:23][7:0] txt)
);
modport recv ( output rx_clk, read,
input data_ready, rx_data,
error_over_run,
error_under_run,
error_all_low,
import task rcv_string(input bit [0:23][7:0] txt)
);
Notes:
Slide 174
Exporting methods pt1

It is sometimes convenient to define tasks in one module and call them in another,
using modports to control task access. Look for the keywords export & import.
logic req, gnt;
logic [1:0] mode;
logic start, rdy;
modport slave( input req, addr, mode, start, clk,

output gnt, rdy, inout data,
export task Read(), task Write());
// export from module that defines the tasks

output req, addr, mode, start, inout data,
import task Read(input logic[7:0] raddr),
task Write(input logic[7:0] waddr));
// import requires the full task prototype
Example:
System with one master and N slaves (all connected via a common modport).
Each slave exports a reset method
Master invokes reset and invokes all slave reset methods at the same time.
Notes:
Slide 175
Exporting methods pt2

module memMod(simple_bus a); // Uses just the interface keyword
logic avail;
task a.Read; // Read method
avail = 0;
...
avail = 1;
endtask
module with onboard methods
task a.Write;
avail = 0;
...
avail = 1;
endtask
endmodule
logic [7:0] raddr;
module top;
logic clk = 0;
memMod mem(a.(sb_intf.slave));
cpuMod cpu(b.(sb_intf.master));
endmodule

// exports the Read and Write tasks
// imports the Read and Write tasks

if (instr == read)
b.Read(raddr); // call the slave method via the interface
...
else
b.Write(raddr);
endmodule
Notes:
Slide 176
In this section
What is ABV
Types of Assertions
Accellera
Analysis
Formal
Notes:
Slide 177
The Challenge
19
98
Effort required to verify these new designs

doubles every 6 to 9 months
19
96
19
94
Verification productivity has not kept pace
19
92
19
90
Design productivity has risen tenfold since

1990
19
88
160
140
120
100
80
60
40
20
0
19
86
Designs continue to grow in accordance with

Moores law
Hardware Design Productivity
19
84
Half of all chips today

require 1 or more re-spins
74% of all re-spins are due to
functional errors
19
82
33%
31%
31%
24%
October 2000
23%
Collett International
21%
14%
11%
10%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Gates Per Day
74%
19
80
Functional
Noise
Clocking
Slow Path
Race Condition
Yield
Mixed Signal Intf
Power
IR Drops
Firmware
Year
Notes:
Slide 178
Traditional Testbench Structure

SYSTEM_TB
CPU
Peripheral
TB1
CPU
Peripheral
TB2
Traditional testbenches treat the DUT as a black box. Stimulus is

applied and results are measured from external pins only.
OK for simple designs.
For complex designs:
It is computationally impractical to test all potential input

sequences
What if an internal error occurred, but the design still had a proper
output response?
How do you know when you are done?
Notes:
Slide 179
Assertion-Based Verification
The core of design verification is to ensure that a design

implementation behaves according to a given specification.
Typically, the specification consists of a list of natural language (i.e.

not machine-readable) assertions, each of which must be verified.
An assertion is a statement about a design's intended behavior which

must be verified. That statement itself is called a property of the
design.
SV assertions may appear in a number of places in your system:
Inside the design (perhaps the DUT module itself)
In an interface or program block
$root
Procedurally, within an initial/always block
Notes:
Slide 180
Types of Assertions
System Bus
(e.g. AHB or PCI)
I/O Assertions
uP Core
FIFO
Arbiter
Structural Assertions
Protocol Assertions
Notes:
Slide 181
Types of Assertions
Intended internal functionality of blocks
Designers can catch errors more quickly
I/O Assertions
Input combinational relationships (e.g. read_en, write_en)
Basic sequential behavior (e.g. reset, handshake)
Ensures block is being used correctly in external context
Protocol Assertions
Higher-level than interface
Transaction descriptions
Required responses
Ensures conformance to standards
Notes:
Slide 182
Examples of Assertions
I/O Assertions
"The read and write enables are mutually exclusive."
"Reset must be held low for three rising edges of the clock."
"A grant never occurs without a request."
"A request must always be acknowledged."
"The state vector is one-hot."
"When opcode is READ_WD, state goes from IDLE to S1 to S2,

then back to IDLE."
"An illegal state is never reached."
Protocol Assertions
"If a master sets the transfer type to BUSY during a burst cycle, then in the
next cycle, the slave must assert HREADY and set HRESP to 'OKAY' ."
Notes:
Slide 183
White-box Monitoring
Assertions increase observability of errors in the DUT
"Open" the black box and observe internal behavior
Add extra code inside DUT that monitors for problems

Dont have to wait for error to propagate to external pins
Error detection closer in both time and physical proximity to error
source
Monitor
ìfdef MONITOR_ON
always @(state) begin
if ((state & (state - 1)) != 2'b0) begin
$display("STATE_NOT_ONE_HOT,%t",$time);
end
end
èndif
Notes:
Slide 184
OVL Checker Library
Verilog does not have an assertion construct.
Instead, checks can be coded as procedural blocks

ìfdef MONITOR_ON
always @(a or b) begin
if (!(a^b)) begin)
$display("Error: a and b must be inverted");
$finish;
end
end
èndif
These blocks can be single-event or temporal, but are not very

reusable.
OVL is a set of predefined, standard tests implemented as modules

for ease of reuse.
OVL checks are concurrent, not embedded in procedural code.
Notes:
Slide 185
Property Languages: Sugar,

ForSpec, CBV
These languages come from theoretical research into formal

verification and internal customer tools (IBM, Intel, Motorola).
They are intended to declare design properties that are verified by

formal (i.e. static) methods.
They provide a concise and easy syntax for specifying single-event

and temporal properties.
assert always req -> next (!req until ack);
Whenever req is asserted, it is de-asserted in the next cycle and

continues so until signal ack is asserted.
Notes:
Slide 186
The Accellera Standardization Effort
Accellera standardized OVL in 2002 for embedded RTL assertions.
The formal verification working group selected the Sugar proposal as

its base for a standard language in 2002.
Accellera approved and released it as PSL (Property Specification

Language) in early 2003, and has received tremendous vendor
support.
SystemVerilog 3.1 will support a "unified" assertion syntax.
Notes:
Slide 187
Does ABV Really Work?

Assertions in real designs:
Assertion Monitors
34%
Cache Coherency Checkers

Register File Trace Compare
Memory State Compare
End-of-Run State Compare
PC Trace Compare
Self-Checking Test
Simulation Output Inspection
Simulation hang
Other
9%
8%
7%
6%
4%
11%
7%
6%
8%
34% of all bugs were found were identified by

assertions on DEC Alpha 21164 project
[Kantrowitz and Noack DAC 1996]

assertions on Cyrix M3(p1) project.
[Krolnik '98]

assertions on DEC Alpha 21264 project.
Kantrowitz and Noack [DAC 1996]
[Taylor et at.DAC 1998]
50% of all bugs found were identified

by assertions on Cyrix M3(p2) project
Assertion Monitors
25%
Register Miscompare
Simulation "No Progress
PC Miscompare
Memory State Miscompare
Manual Inspection
Self-Checking Test
Cache Coherency Check
SAVES Check
22%
15%
14%
8%
6%
5%
3%
2%
Taylor et al. [DAC 1998]
[Krolnik 98]
85% of all bugs were found using

over 4000 assertions on HP
[Foster and Coelho HDLCon 2000]
10,000 assertions in Cisco RTL project

[Sean Smith 2002]
Thousands of assertions in Intel Pentium project

[Bentley 2001]
2003, Harry D. Foster. All rights reserved.
Notes:
Slide 188
In this section
SVA Checker Library
Immediate / Concurrent
Boolean
Sequences
Repetition etc.
Property block
Sequence Implication
Assert/Cover blocks
VCS/Virsim and assertions
Notes:
Slide 189
SVA Checker Library

The SVA Checker Library is a collection of temporal expressions and
assertions for a variety of commonly needed tests.
The library is based upon the OVL checker library but extends upon it
Using these checkers will reduce coding of your own assertions.
Base SVA Checker Library
assert_always
assert_always_on_edge
assert_change
assert_cycle_sequence
assert_decrement
assert_delta
assert_even_parity
assert_fifo_index
assert_frame
assert_handshake
assert_implication
assert_increment
assert_never
assert_next
assert_no_overflow
assert_no_transition
assert_no_underflow
assert_odd_parity
assert_one_cold
assert_one_hot
assert_proposition
assert_quiescent_state
assert_range
assert_time
assert_transition
assert_unchange
assert_width
assert_win_change
assert_win_unchange
assert_window
assert_zero_one_hot
SVA Advanced Checkers

assert_arbiter
assert_bits
assert_code_distance
assert_data_used
assert_driven
assert_dual_clk_fifo
assert_fifo
assert_hold_value
assert_memory_async
assert_memory_sync
assert_mutex
assert_next_state
assert_no_contention
assert_reg_loaded
assert_req_ack_unique
assert_stack
assert_valid_id
assert_value
Notes:
Slide 190
Using the SVA Checker Library

SVA Checker Library components are available as modules or interfaces.
Module is default, to instantiate as an interface use:
`define SVA_STD_INTERFACE
To use the Library, simply instantiate any number of checkers in the SV

design code, enable them and point VCS to the library install directory as
follows.
Required `define
vcs +sysvcs +define+ASSERT_ON

-y $VCS_HOME/packages/sva +libext+.v
+incdir+$VCS_HOME/packages/sva
<design_files.sv>
\
\
\
Notes:
Slide 191
SVA Checker Library

example
$VCS_HOME/packages/sva/assert_mutex.v
/*
assert_mutex
Ensures that <a> and <b> never evaluate true at the same time. The check
is not enabled unless <reset_n> evaluates true (1). The checks is
performed on the active <clk> edge specification.
module test_design();
.
.
Failure modes:
The assertion assert_mutex will report failure when <a> and <b> are
both sampled 1 at the positive edge of <clk>.
design DUT (dat, addr, rd, wr, enable_1, enable_2, clk, rst_);
assert_mutex mutex_inst( clk, 1, gnt[0], gnt[1]);
.
.
verifies that gnt[0] and gnt[1] are never 1 at the same time as
sampled by posedge of clk. The checker is always enabled because
<reset_n> is constant 1.
*/
// SVA module instantiation

ìfdef SVA
assert_mutex MUTEX ( clk, rst_, enable_1, enable_2);
èndif
endmodule
Example:
ìfdef SVA_STD_INTERFACE
interface assert_mutex(clk, reset_n, a, b);
èlse
module assert_mutex( clk, reset_n, a, b);
èndif
parameter
severity_level
= 0;
parameter
edge_expr
= 0;
parameter
msg
= "VIOLATION";
.
.
ìfdef SVA_STD_INTERFACE
endinterface
èlse
endmodule
èndif
Notes:
Slide 192
Assertions Lab 1 : checker lib

Working directory: sv_assertions/fsm
Purpose: Test for one_hot state variable...
Instructions:
Edit the design (file: fsm_ex.sv)
Use the "assert_one_hot" checker from the SVA Checker library to test for
one-hot behavior of the state vector state.
Verify your assertion in simulation by changing the states enumeration.
Notice the run.csh script which should make invoking vcs easier.
Notes:
Slide 193
Assertions Immediate / Concurrent
Immediate
Simulation use primarily
Execute under simulator control inside a procedural block
Imm. assertion is triggered

in procedural code/time
always @( posedge clk )

traf_light : assert ( green && !red && !yellow & go );
Failure triggers a default message
Concurrent
Partial support
Usable by other tools as well ( e.g. formal verification )
Clocked/sampled paradigm
Distinguishable by the keyword property within assert or
cover verification statements
Conc. assertions may be
triggered in various ways
(including procedural code),
but time is spec'd internally
and may include sequential
checks over time
traf_light : assert property ( @ ( posedge clk )

( green && !red && !yellow & go );
do_traf_prop : assert property ( traf_light );
Notes:
Slide 194
Immediate Assertions
Tested when the assert statement is executed in procedural code

Pass statements not yet supported
in VCS 7.1b
time t;

if ( state == REQ )
req_assert : assert ( req1 || req2 ) $display( "%m OK" );
else
Notice if-else style where if is implicit.
begin
else is also optional in this context
Notice optional req_assert label
t = $time;
and the use of %m to implicitly
#5 $display( "%m failed at time %0t",t );
insert that label in messages
end
NOTE
assert statements resolve X and Z expression values
much like if-else statements they will fail on 0, X or Z
Notes:
Slide 195
Severity system tasks
Several new system tasks provide control over severity of a failing assertion.
These new tasks all follow $display symantics.
$fatal()
$error()
$warning()
$info()
- run-time fatal, terminate simulation

- run-time error
- run-time warning, varies by tool
- no severity per se, just informative
$display()
- like $info, no severity per se,
By default, an assertion (with no severity task) that fails triggers $error
Notes:
Slide 196
Concurrent Assertions
Partial support
Concurrent assert statements describe behavior over time.

clock-based (clock may be user-defined but glitchless!!!)
structured for simplicity, flexibility & reuse
Verification Statements
assert , cover, bind
Property Declarations
property , disable iff, not, |->, |=>
Sequence Regular
Expressions
and, or, intersect, first_match, <time_ shift>,

*<repeat>, within, throughout, $past, $stable, $rose,
$fell, sequence
Boolean Expressions
<Verilog expr, excl. +=, ++, -- etc.>,

System functions: $countones, $inset, $isunknown etc.
ended, matched
Notes:
Slide 197
Boolean expressions
Basic building blocks of assertions.
Evaluate sampled values of variables used
0, X or Z interpret as false
Excludes certain types:
time, shortreal, real, realtime
string, event, chandle, class
Associative/dynamic arrays
Variables used must be static
Excludes these operators:
C-assignments (+=, -=, >>= etc)
Bump operators ( i++, i--, ++i etc)
Notes:
Slide 198
Handy System Functions
$onehot (<expression>)
$inset (<expression>, <expression> {, <expression> } )

returns true if the first expression matches
at least one of the subsequent expressions.
$insetz (<expression>,<expression> {, <expression> } )

same as $inset but using casez semantics
$isunknown (<expression>) returns true if any bit of the expression is x.
returns true if only one bit of the expression is high.
$countones (<expression>) returns the # of 1's in a bit-vector
Notes:
Slide 199
Concurrent Assertion Basics

Consider two signals, req/ack that handshake together
req
ack
clk
clock ticks
ticks
simulation ticks
Signals change over time and interlock to implement handshake

A Verilog design models the algorithm
A Verilog testbench duplicates this algorithm
Traditional Verification runs both versions against one another to spot:
Logic errors
Sequence errors
Time errors
Concurrent Assertions describe the sequence of changes in signals over time

Introduces the concept of a clock to sample signal changes and capture
the sequence. This may be a real clock or a virtual one (simulator ticks?).
Notes:
Slide 200
Concurrent Assertion Basics 2

req
ack
clk
Say we sample both signals on the posedge of clk

The waveforms effectively become:
sequences
req
ack
e1
e2
e3
e4
clk
Sequence
start
Events:
Remember, this diagram shows what the signals look like from
the point of view of the sampling clock which must be at least as
fast as the system clock
Assuming we start
with req and ack hi
SVA events are:
e1
e2
e3
e4
( !req )
( !ack )
( req )
( ack )
Notes:
Slide 201
Sequence
A list of SV boolean expressions in linear order of increasing time.

Boolean test for whether a signal matches a given sequence or not.
Assumes an appropriate sampling clock and start/end times
If all samples in the sequence match the simulation result
then the assertion matches. Otherwise it is said to fail.
Sequences are described efficiently using regular expressions to

specify values over time
(req && ack) ##1 !req ##1 !ack ##1 req ##1 (req && ack)
Assuming we start
with req and ack hi
SVA events are:
e1
e2
e3
e4
( !req )
( !ack )
( req )
( ack )
e1
e2
e3
e4
req
ack
clk
Sequence
start
Sequence
matches
Sequence
mismatch
Sequence
end
Notes:
Slide 202
Sequence Operators
Available sequence operators (in order of precedence):
[*
[*->
[*=
- consecutive repetition operator

- goto repetition (non-consecutive, exact)
- non-consecutive repetition
and
intersect
- all sequences expected to match, end times may differ

- all sequences expected to match, end times are the SAME
or
- 1 or more sequences expected to match
throughout
- expression expected to match throughout a sequence
within
##
- containment of a sequence expression

- sequence delay specifier
Notes:
Slide 203
Delay & range

Delay:
##[N]
a ##1 b
a ##0 b
a ##1 b ##1 c
// represents a sequential delay of N cycles (default 0)

// a is true on current tick, b will be true on next tick
// a is true on current tick, so is b (Overlapping!)
// a is true, b true on next tick, c true on next again
Range:
a ##[3:5] b
a ##[3:$] b
// a is true on current tick, b will be true 3-5 ticks from now

// a is true on current tick, b will be true after 3 ticks
$ represents a non-zero
number up to infinity
Notes:
Slide 204
Sequence block
Sequence blocks identify and encapsulate a sequence definition
sequence s1;
@ (posedge clk)
a ##1 b ##1 c;
endsequence
// s1 evaluates on each successive edge of clk
sequence s2 (data,en);
// sequence with name AND arguments
(!frame && (data==data_bus)) ##1 (c_be[0:3] == en);
endsequence
Notice no clock is defined. This may be inherited from
a higher hierarchical statement like property or assert
(More on this later)
sequence s3;
start_sig ##1 s2 ##1 end_sig;
endsequence
// sequence as sub-expression
Where: s3 - is same as - start_sig ##1 (!frame && (data==data_bus)) ##1 (c_be[0:3] == en) ##1 end_sig
Notes:
Slide 205
Repetition [*N [*m:n

Repetition:
a ##1 b ##1 b ##1 b ##1 c
a ##1 b [*3] ##1 c
b [*3]
// long-winded sequence expression

// same using efficient *N syntax
- same as - b ##1 b ##1 b
// b true over 3 ticks total
(a ##2 b) [*3] - same as - (a ##2 b ##1 a ##2 b ##1 a ##2 b )

(a ##2 b) [*1:3] - same as - (a ##2 b)
or (a ##2 b ##1 a ##2 b)
or (a ##2 b ##1 a ##2 b ##1 a ##2 b)
(a[*0:3] ##1 b ##1 c) - same as - (b ##1 c)
or (a ##1 b ##1 c)
or (a ##1 a ##1 b ##1 c)
or (a ##1 a ##1 a ##1 b ##1c)
Notes:
Slide 206
Repetition [*-> [*=
goto repetition: (repeats a boolean expression)

a ##1 b [*->min:max] ##1 c
- same as - a ##1 ((!b [*0:$] ##1 b)) [*min:max]) ##1 c
a ##1 b [*->1:N] ##1 c
// a followed by at most N samples of b

// followed by c
Non-consecutive repetition:
a ##1 b [*=min:max] ##1 c
- same as - a ##1 ((!b [*0:$] ##1 b)) [*min:max])
##1 !b [*0:$] ##1 c;
Notes:
Slide 207
Preponed
Pre-active
Current events
(processed in any order)
Events to be evaluated
after active events (e.g. # )
SystemVerilog
Event Scheduler
Active
Inactive
Pre-NBA
Non-blocking assignment
updates occur here
NBA
Post-NBA
Observed
Evaluation of property expressions

e.g. assertions
Reactive
Execution of Program Block

and pass/fail code from property expressions
Post-observed
Postponed
Verilog 95
PLI
SystemVerilog
Verilog 2001+
Notes:
Slide 208
Value Change Functions

These functions detect transitions between 2 consecutive ticks
$rose ( <expression> )
- true if LSB of expression went lo-hi
$fell (<expression> )
- true if LSB of expression went hi-lo
$stable ( <expression> )
- true if no change
$past ( <expression>, [#_of_ticks] ) - # of ticks into the past to look

(defaults to 1)
Use with $stable to detect glitches?
property e2;
@(posedge clk) (read_cycle) |-> ##3 (busData == mem[$past( busAddr,3 )]);
endproperty
Notes:
Slide 209
Seq. expressions: and / or / intersect

sequence s1;
a ##1 b ##1 c;
endsequence
s1
s2 s2
o_s
sequence s2;
d ##[1:3] e ##1 f;
endsequence
a_s
i_s
Sequence expressions may be logically and / or d together

sequence o_s;
s1 or s2
// o_s matches if at least one sub-sequence matches
endsequence
sequence a_s;
s1 and s2;
endsequence
// both expressions must match

// (first to match waits for the other)
// a_s matches only after BOTH sequences have matched
// both expressions must match

s1 intersect s2;// (both sequences must be same length)
endsequence
// i_s matches only if e occurs 1 cycle after d
sequence i_s;
Notes:
Slide 210
Lab design: uart_xmitter

For the next few labs we'll be developing assertions to verify an RTL UART
transmitter module. Design hierarchy and pin-names are described below:
module test_u_xmit
Signals
module u_xmit
sys_clk
uart_clk
sys_rst_l
U1
done
uart_out
xmit
data
Checker routines
sys_clk
System clock
uart_clk
Serial clock ( sys_clk
sys_rst_l
Reset ( active low )
xmit
Load data and start transmission
data
Byte of data to transmit
done
Done flag (low during transmission
uart_out
Serial bitstream out
16 )
On the next slid we will examine the "specification" waveforms we will be

assertion-checking.
Notes:
Slide 211
Reset
waveform
Timing diagram
uart_clk = sys_clk/16
sys_clk
uart_clk
sys_rst_l
1 sys_clk
xmit
1 sys_clk
data
XX
done
uart_out
byte
XX
After posedge sys_rst_l done stays hi (inactive) until xmit asserts

Start
bit 0
b0
Notes:
Slide 212
Byte transmit
waveform
Signals
sys_clk
System clock
uart_clk
Serial clock ( sys_clk
sys_rst_l
Reset ( active low )
xmit
Load data and start transmission
data
Byte of data to transmit
done
Done flag (low during transmission
uart_out
Serial bitstream out
16 )
Timing diagram
sys_clk
uart_clk
xmit pulse lasts 16 sys_clk
xmit
Data unchanging while xmit hi
data
XX
byte
XX
done stays low
175 sys_clks
or 11 uart_clks
done
1 sys_clk
uart_out
Start
bit 0
b0
b1
b2
b3
b4
b5
b6
b7
Stop
bit 1
Data transmits LSB first, with 1 start-bit, 1 stop-bit

Notes:
Slide 213
Assertions Lab 2 : sequences

Working directory: sv_assertions/u_xmit
u_xmit.sv
Purpose: Write 3 reset-related sequences...
//XXXXXXXXXXXXXXXXXXXX LAB 2 XXXXXXXXXXXXXXXXXXXX

//XXXXXXXXXXXXXXXXXXXX STARTS XXXXXXXXXXXXXXXXXXXX
//XXXXXXXXXXXXXXXXXXXX HERE XXXXXXXXXXXXXXXXXXXX
WRITE YOUR SEQUENCES HERE!!!
Instructions:
//XXXXXXXXXXXXXXXXXXXX END OF LAB 2

Edit the design (file: test_u_xmit.sv)

At the indicated area of the file, write 3 sequences to verify rest behavior.
XXXXXXXXXXXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXX
1.
"s_rst_sigs" : verify for uart_out(hi) and done(lo) 1 sys_clk after sys_rst_l(negedge)
2.
"s_rst_done" : verify signals done(hi) and xmit(lo) 1 sys_clk after sys_rst_l

goes inactive(posedge) and remain so until xmit(posedge)
3.
"s_rst_pair" : sequence verifying that BOTH previous sequences match simult.
4.
Verify your assertions in simulation by inserting errors in the design etc.
Assume all 3 sequences use sys_clk for reference. Don't worry with how this is
accomplished or how the sequences are attempted, we will cover that in the next lab.
Notes:
Slide 214
Seq. expressions: first_match
sequence t1;
te1 ##[2:5]te2;
endsequence
sequence ts1;
first_match(te1 ##[2:5]te2);
endsequence
Each attempt of sequence t1 can result in matches for up to four cycles:
te1 ##2 te2
te1 ##3 te2
te1 ##4 te2
te1 ##5 te2
t1 s2
t1
ts1
But, sequence ts1 will match for ONLY the first of the four t1's.
Notes:
Slide 215
Conditions over sequences - throughout

Often, some preconditions exist to enable or forbid sequences of events.
A sequence may only make sense in a particular mode, or may be forbidden
to occur in another mode.
sequence burst_rule;
@(posedge clk)
$fell (burst) ##0
(!burst) throughout (##2 (!trdy [*4]);
endsequence
burst
trdy
burst1
Here, when burst goes true (low), it is expected to stay low for the next 2 ticks
and also for the following 4 clock ticks, during which trdy is also to stay low.
Notes:
Slide 216
Seq. expressions: within
within allows containment of one sequence within another
!trdy[*7] within (($fell irdy) ##1 !irdy[*8])

Here, trdy must be low for 7 consecutive cycles entirely contained
within the second expression.
Notes:
Slide 217
Seq. expressions: ended

.ended allows detection that a sequence expression has ended (matched)
s1
s2
s1 ##1 s2.ended
sequence e1;
@(posedge clk) $rose(ready) ##1 proc1 ##1 proc2;
endsequence
sequence rule;
@(posedge clk) reset ##1 inst ##1 e1.ended ##1 branch_back;
endsequence
Here, sequence e1 must end one tick after inst.
Notes:
Slide 218
Property block
Property blocks describe behavior in a design, giving it a name for reference
and allowing a range of tools to test/check/cover/etc that behavior.
Properties are often built from sequences (though NOT vice-versa)
Properties can appear in modules, interfaces, programs, clocking domains
even in $root.
Properties have special operators: disable iff, not, |->/|=>
By themselves, properties do nothing must appear in assert or cover
Optional parameters (reuse?)

Asynchronous reset?
property p1(a,b,c,d);
@ (posedge clk) disable iff (reset)
(a) |-> not ( b ##[2:3] c ##1 d );
endproperty
implication
Reversal: sequence must NEVER evaluate true
Here, when a is true the b/c/d expr. is forbidden

Notes:
Slide 219
Implication |-> |=>

Using the implication ( |->, |=> ) operators you can specify a prerequisite
sequence that implies another sequence. Typically this reduces failures
that you expect and wish to ignore.
Only boolean antecedents supported
<antecedent seq_expr> |->/|=> ( <consequent seq_expr> );

Think of it this way: If the antecedent matches, the consequent must too.
If the antecedent fails, the consequent is not tested and a true result is
forced.
Two forms of the implication operator are supported:
( a ##1 b ##1 c ) |-> ( d ##1 e );
// overlapping form
If a/b/c matches, then d is evaluated on THAT tick.
( a ##1 b ##1 c ) |=> ( d ##1 e );
// non-overlapping form
If a/b/c matches, then d is evaluated on the NEXT tick.
Notes:
Slide 220
Implication Example |-> |=>

sequence s_rst_sigs;
##1 (uart_out && !done);
endsequence
sequence s_rst_done;
(!sys_rst_l) [*1:$] ##1 $rose( sys_rst_l )##1 (done && !xmit) [*1:$] ##1 $rose( xmit );
endsequence
sequence s_rst_pair;
s_rst_done and s_rst_sigs;
endsequence
The property attempts a match on every posedge of sys_clk.
property p_post_rst;
@(posedge sys_clk) (!sys_rst_l) |-> s_rst_pair;
endproperty
BUT thanks to the implication operator
sys_rst_l (active, low) is a prerequisite for testing the
sequences
This avoids countless "FAILS" earlier/later in simulation
Notes:
Slide 221
Multi-clock support
Most systems have more than a single clock and SV assertions allow
for this by supporting the use of multiple clocks, even within a single
property/assert. A new syntax ( ## ) is introduced:
sequence m_clk_ex;
@(posedge clk0) a ## @(posedge clk1) b
endsequence
NOTE: no N
Here, assuming a matches on clk0, b is checked on the next edge of clk1
Implication is supported but ONLY the non-overlapping form |=>

property m_clk_ex2;
@(posedge clk0) a ## @(posedge clk1) b |=> @(posedge clk2) c;
endproperty
property m_clk_ex3;
m_clk_ex |=> m_clk_ex;
endproperty
Notes:
Slide 222
Multi-clock support 2
A particularly interesting case is detecting the endpoint of a sequence
running on a different clock. For this purpose, use the matched method
which is like the ended method but for multiple clocks.
NOTE: no N
sequence e1;
@(posedge clk) $rose(ready) ##1 proc1 ##1 proc2;
endsequence
sequence rule;
@(posedge clk2) reset ##1 inst ##1 e1.matched [*->1] ##1 branch_back;
endsequence
Here, sequence e1(evaluated on clk) must end sometime after inst (evaluated on
clk2).
NOTE: sequence rule verifies that sequence e1 has ended, it does NOT start e1
evaluating.
Notes:
Slide 223
Data-use within a sequence
Sequence verification is very useful, but data must be functionally verified too.
SV allows local variables to be defined/assigned in a sequence or property.
All SV types are supported and are dynamic across different attempts on the
sequence.
logic [7:0] d_1, d_2, d_3;
property e1;
logic[7:0] x;
@(posedge clk) ( valid, x = d_in )
|-> ##4 d_out = ~x;
endproperty
always @ (posedge clk)

if(valid)
begin
d_1 <= #5 d_in;
d_2 <= #5 d_1;
d_3 <= #5 d_2;
d_out<= #5 ~d_3;
end
Here, when valid is true x samples d_in. Sequence e1 matches

4 cycles later, if d_out == ~x
Notes:
Slide 224
Assert block
A property by itself does nothing. It must appear within a verification
statement to be evaluated.
Two types of verification statement
[always] assert property - enforces a property as "checker"
[always] cover property - tracks metrics (# attempts, # match, # fail etc)
Properties can appear in modules, interfaces, programs, clocking domains
even in $root.
property p1(a,b,c);
disable iff (a) not @clk ( b ##1 c );
endproperty
assert_p1: assert property (p1(rst,in1,in2))
$info("%m OK")
else $error("%m Failed");
Notes:
Slide 225
sequence/property/ assert example

endsequence
endsequence
endsequence
endproperty
assert_post_rst: assert property ( p_post_rst ) //$display("%m :OK!");
else $display("%m : device did not reset fully");
Notes:
Slide 226
Embedded assertion statements
Assert / cover statements may be embedded in procedural code.

Best reason for this is to reduce maintenance
sequence s1;
( req && !gnt) [*0:5] ##1 gnt && req ##1 !req;
endsequence
always @( posedge clk or negedge reset)
if ( !reset ) do_reset;
Enabling condition is always current with
else if ( mode )
design changes etc.
GOTCHA: Design flaws may be masked

if (!arb)
st <= REQ2;
Must be maintained by hand
PA: assert property (s1);
BUT: implies double-blind checking
property p1;
@( posedge clk ) ( reset && mode && !arb ) |=> s1
endproperty
Notes:
Slide 227
Clock inference
Assertions embedded in procedural code may infer a clock.
property p1;
a ##1 b ##1 c;
endproperty
Inferred clock

assert property ( p1 );
NOTE
Assertions embedded in initial blocks
execute just once, at time t0
Variables a,b,c MUST not be

used inside the procedural block
If the embedded property specifies a clock, it must match the inferred clock
Variables monitored by a property must not be used within the inferring block
Notes:
Slide 228
Clock specification
The clock a property works from may be specified in several ways
1.
Specified within the property ( clk1 below )

property p1; @(posedge clk1) a ##2 b; endproperty
ap1: assert property (p1);
2.
Inherited from a sub-sequence ( clk2 below )

sequence s1; @(posedge clk2) a ##2 b; endsequence
property p1; not s1; endproperty
ap1: assert property (p1);
3.
From an embedding procedural block ( clk 3 below )

always @(posedge clk3) assert property ( not ( a ##2 b ));
4.
From a clocking domain ( clk 4 or clk5 below )

clocking master_clk @(posedge clk4)
property p1; not ( a ##2 b ); endproperty
endclocking
ap1: assert property (master_clk.p1);
default clocking
master_clk @(posedge clk5);
Notes:
Slide 229
Bind directive
As we saw, embedded assertions have advantages/disadvantages.
Another approach is to keep verification code separate from the design
and use the bind directive to associate them.
bind can connect a module, interface or program instance (with checkers?)
to a module or module instance.
bind may appear in a module or in $root.
bind
<module>
<module_instance>
cpu1
cpu2
cpu_chk
<module_instantiation>
<program_instantiation>
<interface_instantiation>
<instance_name>
module cpu_chk (input a,b,c,d);

property p1; @ (posedge clk) a |-> ##1 (b !== (c ^ d)); endproperty
cpu_p1: assert property (p1);
endmodule
bind cpu cpu_chk CHK1(enable, d_out, d_in, op);
Notes:
Slide 230
Assertion Guidelines
Like any new methodology, ABV users can benefit from guidelines:
1.
2.
3.
Start with simple assertions and build up to more complex

Use sequences/booleans wherever you can predict/expect reuse
Start by writing assertions that only use a single signal (plus clock)
Check how long signals are active, etc.
Easy to write
Help verify your methodology/structure (embedded or not?)
4.
Follow up by writing assertions that only use two signals, plus a clock
(req and gnt, or mut-ex signals).
Continue this way before getting to the complex assertions.
Complex systems are often described using a flow chart.
In this case, write one assertion for each arrow in the flow chart.
(simpler assertions, easy estimation how many).
Consider the Checker Library (SVA Checker Lib) of functions
provided with VCS. These can help with common checker situations
like mutex, one-hot, handshake, fifo, memory etc.
5.
6.
7.
Notes:
Slide 231
SV Assertions and VCS

To control SV assertions, VCS supports a compile-time option:
-assert <enable_diag> / <filter_past>
<enable_diag> enables further options at run-time
-assert <arg>
Some of the supported <arg> values are:
quiet
- disable messages to stdout
success
- report matches in addition to failures
maxfail=N
- limit failures of each assertion to N
quiet
- disable messages to stdout
report[=<path/filename>]
- report file (default is: ./assert.report)
verbose
- verbose form of report
Notes:
Slide 232
Typical VCS run.csh script

It's often convenient to invoke VCS within a simple csh script e.g.
vcs +sysvcs \
-assert enable_diag \
+define+SVA \
<design_files>
simv -assert report+verbose+success
Notice the `define for SVA, which might be used as follows:

ìfdef SVA
Conditional compilation of assertion blocks
a_one_enable : assert property ( @ ( posedge clk)

not ( enable_1 && enable_2));
èndif
Notes:
Slide 233
Virsim and assertions

Virsim shows start time graphically
but NOT end-time which may be
much later or never
VirSim displays assertions like signals, but indicates their start/end times, not value.
It also indicates their status by color:
green - success
red - failure
grey - incomplete (Notice the X for finish time above)
Expand the assertion by double-clicking: revealing the clock ticks, result and end-time per attempt.
Notes:
Slide 234
Assertions Lab 3 : assert

Working directory: sv_assertions/u_xmit
Purpose: Continue assertion based verification of the UART...
Instructions:
Edit the design (file: test_u_xmit.sv)
Code up the following assertions:
1.
2.
3.
4.
Count 16 sys_clk cycles per uart_clk cycle

One sys_clk after xmit (assert, hi), we see done(de-assert, lo) & uart_out(lo)
Transmitting a byte (i.e. done (de-asserted, lo) lasts 175 sys_clk cycles.
While xmit is asserted(hi) data value is unchanging ($stable() ?)
5.
Verify your assertions in simulation by inserting errors in the design etc.
Got any assertion ideas of your own?

Suggestion: Repeat #1 and #3, but this time use uart_clk as reference.
Notes:
Slide 235
236
Notes:
Slide 236
In this section
More on interfaces
More on $root
Dynamic / associative arrays
Dynamic processes
Process control
Classes
Randomization and Constraints
Clocking Domains
Notes:
Slide 237
More on interfaces
Notes:
Slide 238
Implicit ports
If an interface is given the same name in all the modules that use it
(instead of a and b as on previous example) then implicit ports can be used
to make instantiation much easier.
module memMod (simple_bus sb_intf, input bit clk);
...
endmodule
Same name for both instances
module cpuMod (simple_bus sb_intf, input bit clk);

...
endmodule
module top;
logic clk = 0;
simple_bus sb_intf;
memMod mem (.*); // implicit port connections
cpuMod cpu (.*);
// implicit port connections
endmodule
Notes:
Slide 239
Generic bundle
Use the generic interface keyword in module declaration and choose (for example)
which level of abstraction is desired for that interface at instantiation
// memMod and cpuMod can use any interface
module memMod (interface a, input bit clk);
...
endmodule
Declare 2 modules with generic

interface placeholders
module cpuMod(interface b, input bit clk);

...
endmodule
interface simple_bus; // Define the interface
logic req, gnt;
logic [1:0] mode;
logic start, rdy;

signals making up simple_bus
module top;
logic clk = 0;
simple_bus sb_intf; // Instantiate the interface
memMod mem (.a(sb_intf), .clk(clk));
cpuMod cpu (.b(sb_intf), .clk(clk));
endmodule
Connect the sb_intf instance

of the simple_bus interface
to the generic interfaces of
the memMod and cpuMod
modules
NOTE
implicit ports cannot be used
with generic interfaces
(use named ports)
Notes:
Slide 240
Hierarchical interfaces
Interfaces can be declared/used hierarchically.
interface i1;
interface i3;
wire a, b, c, d;
modport master (input a, b, output c, d);
modport slave (output a, b, input c, d);
endinterface
i3 ch1, ch2;
modport master2 (ch1.master, ch2.master);
endinterface
Declare interfaces ( i3 within i1 )

2 modports of i3
modport of i1
Notice how modport master2 of i1 uses a

hierarchical reference to define direction
Notes:
Slide 241
Example Modports and generic interface

logic req, gnt;
logic [1:0] mode;
logic start, rdy;
modport slave (input req, addr, mode, start, clk,
module memMod(interface a); // Uses just the interface
logic avail;
endmodule
module cpuMod(interface b);
...
endmodule
Declare a module with generic

interface placeholder
Connect sb_intf modports to the

generic interfaces on memMod
and cpuMod modules
module top;
logic clk = 0;
memMod mem(sb_intf.slave); // Connect the modport to the module instance
cpuMod cpu(sb_intf.master);
endmodule
Notes:
Slide 242
Generic Interface - beware

At first blush generic interfaces are tremendously useful
Design code uses a 'generic' interface
Alternative abstractions easily selected by swapping in different interfaces
with NO mods needed to design code
However, remember that design code must make certain assumptions about
signals/methods/etc available inside the generic interface
Each interchangeable interface must comply to avoid compile errors
This can complicate design/refinement of interfaces
TIP:
Use generic keyword in conjunction with hierarchical interfaces
All abstraction levels share same method 'prototypes' of parent interface
Methods can even be declared outside interface and imported
Notes:
Slide 243
Parameterized interfaces pt1

Interfaces can be declared with redefinable parameters.
interface simple_bus #(parameter AWIDTH = 8, DWIDTH = 8;)
(input bit clk); // Define the interface
interface with parameters
logic req, gnt;
logic [AWIDTH-1:0] addr;
logic [DWIDTH-1:0] data;
logic [1:0] mode;
logic start, rdy;
modport slave( input req, addr, mode, start, clk,
output gnt, rdy, inout data,
import task slaveRead(),
task slaveWrite()); // import into module that uses the modport
output req, addr, mode, start, inout data,
import task masterRead(input logic[AWIDTH-1:0] raddr),
task masterWrite(input logic[AWIDTH-1:0] waddr)); // import requires the full task prototype
task masterRead(input logic[AWIDTH-1:0] raddr); // masterRead method
...
endtask
...
endtask
task masterWrite(input logic[AWIDTH-1:0] waddr);
...
endtask
task slaveWrite;
...
endtask
Notes:
Slide 244
Parameterized interfaces pt2

module memMod(interface a); // Uses just the interface keyword
logic avail;
always @(posedge b.clk) // the clk signal from the interface
a.gnt <= a.req & avail; //the gnt and req signals in the interface
always @(b.start)
if (a.mode[0] == 1b0)
a.slaveRead;
else
a.slaveWrite;
endmodule
module cpuMod(interface b);
logic [7:0] raddr;
if (instr == read)
b.masterRead(raddr); // call the Interface method
Redefine parameter DWIDTH to 16
// ...
else
b.masterWrite(raddr);
module top;
endmodule
logic clk = 0;
// Instantiate default interface
simple_bus #(.DWIDTH(16)) wide_intf(clk);
// Interface with 16-bit data
memMod mem(sb_intf.slave);
// only has access to the slaveRead task
cpuMod cpu(sb_intf.master);
// only has access to the masterRead task
memMod memW(wide_intf.slave);
// 16-bit wide memory
cpuMod cpuW(wide_intf.master);
// 16-bit wide cpu
endmodule
Notes:
Slide 245
logic [7:0] a = 0;
event global_event;
Procedural code, implied initial block
$root in SV3.1
begin
$monitor("%2t: a =%d, U1.a =%d",$time,a,U1.a);
#20 -> global_event;
end
local1 U1;
Standard Verilog hierarchical reference works
module local1;
logic [7:0] a;
always @(global_event) begin
$display(" global_event detected in: %m");
a = 1;
end
local2 U2;
Alternative names for same global signal
endmodule
module local2;
always @($root.global_event) begin
$display(" global_event detected in: %m");
#20;
a = 2;
// assign $root.a
#20;
U1.a = 2;
// assign U1.a
#20
$root.a = 4;
// assign $root.a
end
Alternative names for same global signal
endmodule
0: a = 0, U1.a = x
global_event detected in: $root.U1.U2
global_event detected in: $root.U1
20: a = 0, U1.a = 1
40: a = 2, U1.a = 1
60: a = 2, U1.a = 2
80: a = 4, U1.a = 2
Notes:
Slide 246
module test;
logic [7:0] a = 0, b = 0;
event global_event;
Explicit Hierarchy in SV3.1
initial
begin
process $monitor(%2t: test.a =%d, test.b =%d, local1.a =%d",$stime,a,b,U1.a);
#20 -> global_event;
end
Simulator output...
local1 U1;
0: test.a =
module local1;
logic [7:0] a;
always @(global_event)
begin
$display(global_event detected in: %m");
a = 1;
b = 1;
end
0, test.b =
0, local1.a =
global_event detected in: test.U1.U2

global_event detected in: test.U1
20: test.a = 0, test.b = 1, local1.a =
40: test.a =
0, test.b =
2, local1.a =
60: test.a =
4, test.b =
2, local1.a =
t20
local2 U2;
NOTES
module local2;
always @(global_event)
begin
$display(global_event detected in: %m");
#20 a = 2;
b = 2;
#20 test.a = 4; // Verilog hier. ref.
end
endmodule
endmodule
endmodule
1. Structure is entirely explicit (declare nested modules)

This means children share name-space of parent(s)
e.g. global_event is visible throughout hierarchy
2. Child may have variable of same-name as parent
e.g. a appears in local1 and in parent module test
3. Standard Verilog hierarchical references still work
Notes:
Slide 247
Arrays dynamic
This is another exciting feature of SystemVerilog 3.1, allowing declaration of a
one-dimensional array with no specific size. The size can change during
simulation and array space is allocated by method call.
Syntax:
data_type array_name [ ];
Example:
bit [3:0] nibble[];
integer mem[];
// Dynamic array of 4-bit vectors

// Dynamic array of integers
3 new methods support the creation, destruction and querying of dynamic arrays
new[ ]
is used to set or change the size of the array

Example:
integer addr[ ];
addr = new[100];
addr = new[200](addr);
size()
// Declare the dynamic array.

// Create a 100-element array.
// Double the array size, preserving previous values.
returns the current size of the array ( e.g. int j = addr.size(); )
delete() dumps array contents and zero-sizes it ( e.g. addr.delete(); )
Notes:
Slide 248
Arrays associative
Associative arrays ( sometimes called indexed arrays ) go further than dynamic
arrays, they support situations where data set size is totally unpredictable and
elements may be added or removed individually to grow/shrink the array.
Associative arrays are implemented as a look up table and so require an index.
Syntax:
data_type array_id [ index_type ]; // index type is the datatype to use as index
// examples include string, int, class, struct
Example:
bit i_array[*];
// associative array of bits (unspecified index)

// unspecified index (*) implies any integral value
bit [20:0] array_b[string];
// associative array of 21-bit vector, indexed by string
event ev_array[myClass]; // associative array of event indexed by class myClass
7 new methods support associative arrays

num(), delete(), exists(), first(), last(), next(), prev()
Notes:
Slide 249
Processes
Verilog had simple process spawning capability via the fork-join statement.
For modern more sophisticated design and verification however, this isnt
enough.
SystemVerilog provides a much greater flexibility to spawn and control
Dynamic processes:
Spawning Dynamic processes: fork..join_any, fork..join_none
Process control wait_fork, disable_fork
Notes:
Slide 250
Dynamic processes
Inspired by Vera and other languages, SystemVerilog 3.1 defines 2 new
special cases of forkjoin with associated keywords join_any & join_none
join_any
join
fork
join
// all blocks finished
fork
join_any // any block finished
join_none
fork
join_none // no waiting at all
Notes:
Slide 251
forkjoin_any
Here, the parent process blocks until any one of the spawned processes
completes
fork
begin
#100
end
begin
wait (status == 0)
end
begin
@(sig)
end
join_any
// executes when first block finishes
Notes:
Slide 252
forkjoin_none
The SystemVerilog 3.0 spec. defined a process statement for spawning off
parallel processes. SystemVerilog 3.1 replaces process by join_none. This
allows any number of processes to be spawned simultaneously without any
impact on the flow of the main process.
fork
begin
#100
end
begin
wait (status == 0)
end
begin
@(sig)
end
join_none
@(sigb); // executes immediately
NOTE
The child processes spawned
by a forkjoin_none do not
start executing until the parent
process hits a blocking
statement
Notes:
Slide 253
Process control- wait fork

With Dynamic processes SystemVerilog needed to provide more global
detection that spawned processes have completed.
The wait fork statement is used to ensure that all child processes have
completed execution.
begin
fork
task1();
task2();
join_any
fork
task3();
task4();
join_none
wait fork;
end
// continue when either task completes
// continue regardless
// block until tasks 1-4 complete
Notes:
Slide 254
Process control- disable fork

The disable fork statement terminates all active child processes of the
process where it is called. Termination is recursive, in other words it terminates
child processes, grandchild processes etc.
task test_with_timeout;
fork
run_test();
timeout( 1000 );
join_any
disable fork;
endtask
task test_with_timeout;
fork
begin
run_test();
disable timeout;
end
begin
timeout( 1000 );
disable run_test;
end
join_any
endtask
// 2 child tasks spawned in parallel, first to finish triggers join_any

// Kills the slower task
At first glance, this code may appear to do the same thing as

the disable fork example above.
However, what if the timeout task was a global one, used in many places?
The disable timeout line would terminate this occurrence of timeout but ALSO
any other occurrences that happen to be executing elsewhere in the system.
disable fork terminates only copies of the timeout task spawned by the
current block
Notes:
Slide 255
Classes
Object Oriented programming is a common programming paradigm based
on the idea that data and the means to manipulate it can be described
together in a formal structure called a class.
A class is a datatype, similar to a struct but in addition to data elements
(called properties) a class also contains functions and tasks (called methods)
through which class properties may be manipulated. An instance of a class
is referred to as an object.
SystemVerilog classes can be dynamically created and destroyed but unlike
their C++ cousins memory allocation and deallocation (garbage collection) is
handled automatically. Since pointers are a key ingredient in the flexibility
of classes, SystemVerilog implements them too, but in a safer form, called
handles.
Notes:
Slide 256
Class example
class Packet ;
//data or class properties
bit [3:0] command;
bit [40:0] address;
bit [4:0] master_id;
integer time_requested;
integer time_issued;
integer status;
// initialization
function new();
command = IDLE;
address = 41b0;
master_id = 5bx;
endfunction
// methods
// public access entry points
task clean();
command = 0; address = 0; master_id = 5bx;
endtask
task issue_request( int delay );
// send request to bus
endtask
function integer current_status();
current_status = status;
endfunction
endclass
Notes:
Slide 257
Randomization & Constraints

Verilog has always had simple pseudo-random data generation capability.
Usefulness was limited since the data could not be constrained or directed.
Special classes aid in the generation of more sophisticated random
number sequences and also to constrain them by precise algorithms.
Directed Tests
Traditional method for testbenches
Weighted Randomization
Focuses stimulus on interesting cases
Constrained Randomization
Enables complex and thorough tests to be developed quickly
Combination of above
Notes:
Slide 258
Random class extensions

New System Functions
$urandom
generate unsigned 32- bit random numbers
$urandom_ range
like $urandom but within a specified range
$srandom
Seed the random number generator
New random modifiers

rand
distributed random number generator where a value

can occur more than once before 100% of range
randc
cyclic random number generator where all values

will occur once and then new sequence begins
Built-in methods
randomize()
pre_randomize
post_randomize
select new values for all of the random variables in an object

overload-able method called just prior to randomize()
overload-able method called just after randomize()
Notes:
Slide 259
Constraint class extensions

Constraint Block
constraint
list of expressions restricting the range of a variable
Constraint Expressions
inside
specifies hi-lo bounds for a constraint set
dist
specifies weights for ranges/values in a set
if..else
conditional constraint selection
Built-in methods
randomize()with
in-line constraint where randomize() is called
rand_mode()
enable/disable random variables
constraint_mode
enable/disable a constraint
Notes:
Slide 260
Randomization & Constraint - example
Bus bus = new;

repeat (50) begin
if ( bus.randomize() == 1 )
$display ("addr = %16h data = %h\n", bus.addr, bus.data);
else
$display ("Randomization failed.\n");
end
class Bus;
rand bit[15:0] addr;
rand bit[31:0] data;
constraint word_align {addr[1:0] == 2b0;}
endclass
typedef enum {low, mid, high} AddrType;

class MyBus extends Bus;
rand AddrType atype;
constraint addr_range {
(atype == low ) => addr inside { [0 : 15] };
(atype == mid ) => addr inside { [16 : 127]};
(atype == high) => addr inside {[128 : 255]};
}
endclass
task exercise_bus (MyBus bus);

int res;
// EXAMPLE 1: restrict to low addresses
res = bus.randomize() with {atype == low;};
// EXAMPLE 2: restrict to address between 10 and 20
res = bus.randomize() with {10 <= addr && addr <= 20;};
// EXAMPLE 3: restrict data values to powers-of-two
res = bus.randomize() with {data & (data - 1) == 0;};
endtask
Notes:
Slide 261
Preponed
Pre-active
Current events
(processed in any order)
Events to be evaluated
after active events (e.g. # )
SystemVerilog
Event Scheduler
Active
NOTE
SystemVerilog defines
a special timeunit 1step
defined as the smallest possible
timeunit (like delta time in VHDL)
Inactive
Pre-NBA
Non-blocking assignment
updates occur here
NBA
Post-NBA
Observed
Evaluation of property expressions

e.g. assertions
Reactive
Execution of Program Block

and pass/fail code from property expressions
Post-observed
Postponed
Verilog 95
PLI
SystemVerilog
Verilog 2001+
Notes:
Slide 262
Program Block
In Verilog a testbench looks just like the DUT, yet requirements are different.
For example, testbenches require a stable time/place to drive/monitor/sample
in order to avoid race conditions.
SystemVerilog defines a programendprogram block.
PB Code executes in reactive region
Outputs transition together
Ideal location for code that reacts to assertion pass/fail
Notes:
Slide 263
Program Block Examples

program test (input clk, input logic [15:0] addr,
output logic [3:0] status, inout tri [7:0] data);
logic[15:0] s_addr;
initial
begin
@(posedge clk);
s_addr = addr;
if ( (s_addr > h50) || (s_addr < h10) )
status <= 4hf; // error status
end
endprogram
NOTE
SystemVerilog simulation stops (i.e.
simulator will exit) when all initial
blocks inside program blocks have
finished. This occurs even if other
code is still executing.
program test ( interface device_ifc );

initial
begin
end
endprogram
Notes:
Slide 264
Clocking Domains
In Verilog testbenches, race conditions on the ports of the DUT are a constant worry.
The classic workaround is to make testbenches operate on the opposite edge of clk
to the DUT. This isnt always practical however
SystemVerilog introduces a new block: clockingendclocking which identifies
clock signals and specifies explicit timing characteristics for all signals synchronous
to that clock.
By specifying skew values for driving and sampling, testbench code can simply
reference a clock edge and the simulator (observing skew specs) will sample
prior to and drive just after the active edge, avoiding race conditions with
the DUT.
output skew
clocking dram @(posedge clk);

default input #10ps output #15ps;
input #5ps output #6ps data;
endclocking
input skew
Input skew is always negative ( default 1step )

Output skew is always positive ( default )
Notes:
Slide 265
Interprocess synch. & communication

Dynamic processes and OOP techniques require more sophistication than
Verilog named events. SystemVerilog introduces several new features:
Semaphores
Synchronization/arbitration for shared resources (keys)
Mutex control
get() blocks thread execution until a key is available
Methods: get(), put(), try_get()
Mailboxes
FIFO queuing mechanism between threads (bounded/unbounded)
Can block
Methods: new(), num(), put(), get(), peek(), put(), get(), peek() block thread
execution until mail is available
try_put(), try_get(), try_peek()
Enhanced events
Event datatype supports copying, comparison etc.
Persistency (value and duration)
Passable as arguments
Ordering: wait_order(e1,e2,e3); // wait for 3 events in order
Notes:
Slide 266
Notes:
Slide 267
Solution to Array literals Quiz

bit [3:0] b [2:0][3:0] = {{1,2,3,4},{5,6,7,8},{9,10,11,12}};
initial
for(int i = 0; i<3; i++)
for(int j = 0; j<4; j++)
$display(b[i][j]);
Starts at 12 and descends because of the

way we defined the unpacked dimensions
of the array b [2:0][3:0]
12
11
10
9
8
7
6
5
4
3
2
1
Notes:
Slide 268
Sample solution Lab 1
`define INTEL
//`define SPARC
module video1;
bit[7:0] hdr [1:56];
// Invert the image (pos-neg-pos etc)
for(int hor=1; hor <= 400; hor++) begin
vidbuf[ver][hor].X = 'hf;
end
endfunction
initial begin
rfile = $fopen("i_mourne_32.bmp", "r");// Open the image file
invert;
saveimg;
$fclose(rfile);
$fclose(wfile);
$finish;
end
endmodule

//
ìfdef SPARC
èndif
ìfdef INTEL
èndif
ìfdef SPARC
vidbuf[ver][hor].X,
vidbuf[ver][hor].B,
èndif
ìfdef INTEL
vidbuf[ver][hor].B,
vidbuf[ver][hor].X,
èndif
endfunction
Notes:
Slide 269
Sample solution Lab 2 ( Union )

module pu_bytex;
bit [63:0] bus;
typedef union packed { bit [63:0] bus;
bit [8:1][7:0] b;
} bex;
function bit[7:0] bytext(input bit[63:0] bb, int lane);
bex a;
a.bus = bb;
return a.b[lane];
endfunction
initial
begin
bus = 64'haabbccddeeff0011;
for(int i=8; i>0; i--)
$displayh(bytext(bus,i));
end
endmodule
Notes:
Slide 270
Sample Solution Lab 3: beh_sram

module beh_sram(input packet ip, output packet op,
typedef struct {
input bit cs, rw_);
logic [9:0] addr;
packet ret_pkt;
Note: typedef must appear in $root.
logic[31:0] data;
bit doit;
bit rw_, doit;
reg [31:0] mem [0:1023];
} packet;
always @(posedge cs)
if(rw_ ) // read
begin
ret_pkt.data = mem[ip.addr];
ret_pkt.addr = ip.addr;
op <= #5 ret_pkt;
end
else
// write
begin
mem[ip.addr] <= ip.data;
end
10 Writing 0000000a to address 005

38 Read successful: 0000000a from address 005
81 Read successful: 0000aaaa from address 1ff
endmodule
Notes:
Slide 271

initial
begin
@(posedge f.reset);
@(negedge f.reset);
end
Sample Solution Lab 4:

beh_uart.sv
`timescale 1ns/1ns
module top_level();
bit clk, reset;
endmodule
module response_check( rs232_beh f);
rs232_beh IB();
// Behavioral RS232 interface
stimgen ST1(IB);
// Behavioral transmitting host
response_check RC1(IB); // Behavioral receiving host
initial
begin
@(posedge f.reset);
@(negedge f.reset);
f.rcv_string("Mr Watson, come here...");
f.rcv_string("I want to see you. ");
$stop;
end
bit [0:31][7:0] string;
endmodule
logic valid = 0;
bit reset;
assign IB.reset = reset;

initial
begin
clk = 0;
reset = 0;
end

wait(valid ==0);
string = text;
valid = 1;
endtask
initial
begin
reset = 1;
reset = 0;
end
task rcv_string(input bit [0:31][7:0] text);

wait(valid == 1);
if (text === string)
$display("\n Correct string received: %s \n",text);
else
$display("\n ERROR: Expected string %s, Received %s \n",text, string);
valid = 0;
endtask
endinterface
Notes:
Slide 272
Solution to Procedural Assignment Quiz 3

b
#2
1:
always @ (b)
a = b;
2:
always @ (b)
#2 a = b;
3:
always @ (b)
a = #2 b;
4:
always @ (b)
a <= b;
5:
always @ (b)
#2 a <= b;
6:
always @ (b)
a <= #2 b;
10
20
40 41
b
ROT #1
ROT #2
12
22
42 43
Notes:
Slide 273
Sample Solution Lab 5: fsm_ex.sv

typedef enum [1:0] { S0 = 2'h0, S1 = 2'h1, S2 = 2'h2 } states;
module fsm_ex( input logic clk, rst, input_sig_1, input_sig_2,
output logic a, b);
states state, next_state;
assign a = (input_sig_1 || input_sig_2 ) && (state == S0);
assign b = (state == S1);
always_ff @ (posedge clk)
if (rst)
// Fully synchronous reset
state <= #1 S0;
else
state <= #1 next_state;
always_comb
begin
unique case (state)
S0:
begin
if(input_sig_1 == `TRUE)
next_state = S1;
else
next_state = S0;
end
S1:
begin
if(input_sig_2 == `TRUE)
next_state = S2;
else
next_state = S0;
end
S2:
next_state = S0;
endcase
end
NOTE
To compile this example:
endmodule
vcs fsm_ex.v +v2k +sysvcs
Notes:
Slide 274
Sample solution Lab 6 ( Histogram 1 )

`define INTEL
//`define SPARC
module video6;
bit[7:0] hdr [1:56];
function int buildhist();
// For a given color plane, count the total number of pixels
// of each intensity 0-255
// Then determine the most common intensity
// and scale the display
//
int lrgst = 0;
histogram[ vidbuf[ver][hor].R]++; // count #
if(histogram[pixels] > lrgst)
lrgst = histogram[pixels]; // locate largest number
$display("Scale Factor: %d",lrgst/72);
return lrgst/72;
// derive scale factor
endfunction
function void painthist(input int scale);

// Paint histogram on top of image
//
int ver = 50, hor = 72;
for(int i=1; i <= histogram[pixels]/scale; i++)
vidbuf[ver + i][hor + pixels] = 'hff;
endfunction
function void printhist(input int scale);
// Print the histogram (e.g. ....) to std out.
//
for(int pixels=0; pixels<256; pixels=pixels+5)
begin
// print histogram
$write("%3d",pixels);
repeat(histogram[pixels]/scale)$write("."); // draw bar
$write("\n");
end
endfunction
// Invert the image (pos-neg-pos etc)
for(int hor=1; hor <= 400; hor++) begin
end
endfunction
Notes:
Slide 275
Sample solution Lab 6 ( Histogram 2 )

//
ìfdef SPARC
èndif
ìfdef INTEL
èndif
ìfdef SPARC
vidbuf[ver][hor].X,
vidbuf[ver][hor].B,
èndif
ìfdef INTEL
vidbuf[ver][hor].B,
vidbuf[ver][hor].X,
èndif
endfunction
initial
begin
rfile = $fopen("i_mourne_32.bmp", "r");// Open the image file
// Read the file into
memory
invert;
scale = buildhist(); // Build histogram and return scale factor
//
printhist(scale);
painthist(scale);
saveimg;
$fclose(rfile);
$fclose(wfile);
$finish;
end
endmodule
Notes:
Slide 276
Sample Solution Lab 7:

rtl_uart_1.sv
interface rs232_if(input wire clk, input wire reset,

input wire tx_clk, input wire rx_clk);
logic load_request,
for(i=0; i<= 23; i++)
load = 0, read = 0,
begin
txd, rxd, data_ready, error_over_run,
ok = 0; read = 1;
fork :rs_forkjoin
logic [7:0] tx_data, rx_data;
task send_string(input bit [0:23][7:0] txt);
begin
integer i, ok;
modport txmit (output tx_clk, load, tx_data,
input load_request);
for( i=0; i<= 23 ; i++ )
end
begin
begin
modport recv (output rx_clk, read,
ok = 0;
@(negedge data_ready) ok=1;
input data_ready, rx_data, error_over_run,
fork :ss_start
error_under_run, error_all_low);
begin
end
wait(load_request) ok = 1;
begin
disable ss_start;
@(posedge error_over_run) ok=2;
end
begin
end
task rcv_string(input bit [0:23][7:0] txt);
begin
integer i, ok;
disable ss_start;
@(posedge error_under_run) ok=3;
bit [0:23][7:0] rcvd_text;
end
ok = 0;
join
end
fork :rs_start
if (!ok) $display("load_request timeout");
begin
begin
@(negedge clk);
@(posedge error_all_low) ok=4;
@(posedge data_ready) ok = 1;
tx_data = txt[i];
disable rs_start;
@(negedge clk);
end
end
load = 1;
join
begin
ok = 0;
if(txt[i] !== rx_data)
fork : ss_done
$display("ERROR: Incorrect character, exp: %s, act: %s",
disable rs_start;
begin //:ss_tout
txt[i], rx_data);
end
join
disable ss_done;
rcvd_text = {rcvd_text, rx_data};
if (!ok) $display("rs232rcv timeout");
end
read = 0;
begin //:ss_done
case(ok)
@(posedge load_request) ok=1;
8'h0: $display("rs232txmit timeout");
disable ss_done; //tout;
8'h1: $display("%s",rcvd_text);
end
8'h2: $display("rs232txmit error_over_run");
join
8'h3: $display("rs232txmit error_under_run");
if(!ok) $display("rs232txmit timeout");
8'h4: $display("rs232txmit error_all_low");
@(negedge clk);
endcase
load = 0;
end
end
rcvd_text = 0;
endtask
endtask
endinterface // rs232_if
Notes:
Slide 277
Sample Solution Lab 7: rtl_uart_1.sv

module stimgen( rs232_if f);
module top_level(); //(stimgen, response_check);
initial
begin
@(posedge f.reset);
@(negedge f.reset);
f.send_string("Mr Watson, come here..");
end
bit clk,
reset;
wire sub_clk;
wire serial_link;
reg[4:0] freq;
rs232_if I2(.clk(clk), .reset(reset), .tx_clk(sub_clk),
.rx_clk(sub_clk)); // RTL UART interface
endmodule
rs232tx T1(.serial_out(serial_link), .tif(I2.txmit)); // RTL rs232 transmit
rs232rx R1(.serial_in(serial_link), .rif(I2.recv)); // RTL rs232 receive
stimgen ST1(I2); // RTL transmitting host (stimulus generator)
response_check RC1(I2); // RTL receiving host (response checker)
clock_gen CK(.clk(clk), .frequency(freq), .reset(reset), .clk_out(sub_clk));
initial
begin
clk = 0;
reset = 0;
freq = 4'd12;
end
initial
begin
reset = 1;
reset = 0;
end
module response_check( rs232_if /* .rs232rcv */ f);

initial
begin
@(posedge f.reset);
@(negedge f.reset);
f.rcv_string("Mr Watson, come here..");
f.rcv_string("I want to see you. ");
$stop;
end
endmodule
module rs232rx ( wire serial_in, rs232_if rif );
module rs232tx ( wire serial_out, rs232_if tif);
Notes:
Slide 278
Sample Solution, Assertion Lab 1

fsm_ex.sv
//typedef enum [2:0] { S0 = 3'h1, S1 = 3'h2, S2 = 3'h4 } states;
typedef enum [1:0] { S0 = 2'h0, S1 = 2'h1, S2 = 2'h2 } states;
module fsm_ex( input logic clk, rst, input_sig_1, input_sig_2,
output logic a, b);
ìfdef SVA
assert_one_hot #(.width(2), .msg("state variable should be one_hot"))
A1 (.clk(clk), .reset_n(!rst), .test_expr(state));
èndif
endmodule
"/work/synopsys/vcs/packages/sva/assert_one_hot.v", 87: test_fsm_ex.u1.A1.assert_one_hot:
started at 100s failed at 100s, "state variable should be one_hot" Offending '$countones(test_expr)==1'
"/work/synopsys/vcs/packages/sva/assert_one_hot.v", 87: test_fsm_ex.u1.A1.assert_one_hot:
started at 300s failed at 300s, "state variable should be one_hot" Offending '$countones(test_expr)==1'
Notes:
Slide 279
Sample Solution, Assertion Lab 2:

test_u_xmit.sv
endsequence
endsequence
endsequence
endproperty
assert_post_rst: assert property ( p_post_rst ) //$display("%m :OK!");
else $display("%m : device did not reset fully");
Notes:
Slide 280
ìfdef SVA
test_u_xmit.sv
Sample Solution
Assertion Lab 3:
// sys_clk divider checker
property p_uart_sys16;
@(posedge sys_clk) $rose(uart_clk) |-> ##8 $fell(uart_clk) ##8 $rose(uart_clk);
endproperty
// xmit and data checks
sequence s_val_bit_stream(x_byte);
bit[7:0] x_byte;
##8 (uart_out == 0) #16
(uart_out == x_byte[0]) ##16
(uart_out == 1) ##16 (uart_out == 1) #16
(done == 1);
endsequence
assert_uart_sys16: assert property (p_uart_sys16)

else $display("%m : uart_clk should = sys_clk/16");
assert_val_bit_stream: assert property (p_val_bit_stream)
else $display("%m : uart_out bitstream incorrect");
property p_val_bit_stream;
@(posedge sys_clk) ($fall(done) && xmit ) |-> s_val_bit_steam(data);
endproperty
Notes:
Slide 281
// xmit and data checks

property p_xmit_hi16;
@(posedge sys_clk) $rose(xmit) |-> ##16 $fell(xmit);
endproperty
Sample Solution
Assertion Lab 3:
property p_xmit_done;
@(posedge sys_clk) $rose(xmit) |-> ##1 $fell(done) && $fell(uart_out);
endproperty
// Serial protocol checkers
property p_xmit_nc_data;
@(posedge sys_clk) $rose(xmit) |=> $stable(data) [*1:$] ##1 $fell(xmit);
endproperty
property p_done_175;
@(posedge sys_clk) ($fell(done) && sys_rst_l) |-> ##175 $rose(done);
endproperty
// assertions
assert_xmit_hi16: assert property (p_xmit_hi16) //$display("%m :OK!");
else $display("%m : Signal xmit should stay hi for 16 sys_clks");
assert_xmit_done: assert property (p_xmit_done) //$display("%m :OK!");
else $display("%m : Posedge xmit should take done and uart_out low.");
assert_xmit_nc_data: assert property (p_xmit_nc_data) //$display("%m :OK!");
else $display("%m : data should not change while xmit asserted");
assert_done_175: assert property (p_done_175) //$display("%m :OK!");
else $display("%m : Byte transmission (done low) should take 175 sys_clk");
Notes:
Slide 282
Sample solution:
Assertion Lab3
// uart_clk checkers
//####################
//
//
sequence s_val_bit_stream_uart_clk(x_byte);
bit[7:0] x_byte;
##1 (uart_out == 0) #1
assert_xmit_hi1: assert property (p_xmit_hi1)
else $display("%m : Signal xmit should stay hi for 1 uart_clk");
assert_done_11: assert property (p_done_11)
else $display("%m : Byte transmission (done low) should take 11 uart_clk"
assert_val_bit_stream_uart_clk: assert property (p_val_bit_stream_uart_clk)
else $display("%m : uart_out bitstream incorrect");
(uart_out == 1) ##1 (uart_out == 1) #1
(done == 1);
endsequence
èndif
property p_xmit_hi1;
@(posedge uart_clk) $rose(xmit) |-> ##1 $fell(xmit);
endproperty
property p_done_11;
@(posedge uart_clk) ($fell(done) && sys_rst_l) |-> ##11 $rose(done);
endproperty
property p_val_bit_stream_uart_clk;
@(posedge sys_clk) ($fall(done) && xmit ) |-> s_val_bit_steam_uart_clk(data);
endproperty
Notes:
Slide 283
284
Notes:
Slide 284
Appendix A
Notes:
Slide 285
VCS
VCS stands for Verilog Compiled Simulator
There are two different types of Verilog event based simulators:
Interpreted - example is Verilog-XL
Compiled - VCS
Depending upon platform, VCS first generates C code from the Verilog
source, then it compiles and links the object files to the simulation
engine to create an executable.
Win, Alpha, SGI, IBM
platforms only
Verilog
Source
(mem.v
cpu.v)
C language
files
(mem.c
cpu.c)
Object
files
(mem.o
cpu.o)
On Sun & HP compile

direct to object code
Link
simv
(executable)
PLI code links to simv

not to VCS
Notes:
Slide 286
Running the Simulator - VCS

vcs -help
lists compile options, runtime options, environment variables
Basic invocation:
vcs file1.v file2.v file3.v filen.v
simv
Verilog executable generated by VCS
Command line options (commonly used):
-I
Compile for interactive simulation
-Mupdate
Incremental compilation (only changed files are compiled)
-R
Run after compilation
-RI
Run interactively (with VirSim GUI) after compilation
-line
Enable line, next and trace commands
-f <filename> read host command arguments from file
-l<filename> set log file name
-s
Stop simulation before it begins; enter interactive mode
+v2k
Compile with support for Verilog 2001 extensions
+sysvcs
Compile with support for System Verilog extensions
Notes:
Slide 287
VCS Incremental Compilation

Faster compilation by compiling
only the modules you have changed
If you made a change to module mem in mem.v, then VCS compiles only
the module mem. The cpu module object code is used from a previous
compilation and linked with the new mem object code in the creation of
the executable.
Verilog
Source
(mem.v)
C language
files
(mem.c)
Object
files
(mem.o
cpu.o)
Link
simv
(executable)
Notes:
Slide 288
VCS -Mupdate
Creates a makefile that is built and maintained by vcs:
Example
vcs file1.v file2.v file3.v -Mupdate:
Compiles Verilog source files, puts c files in directory called csrc
Makefile created in csrc directory
C compilation accomplished via makefile
Object files linked to produce simv
Subsequent compilations will be incremental:
Appropriate c files updated
Makefile adjusted
Incremental C compilation as appropriate
Object files re-linked
Handy
Handytip:
tip: The
TheMupdate
Mupdateswitch
switchcan
canbe
beshortened
shortenedtotoM
Mbut
butthis
thiswill
willmake
makeuse
useofof
an
existing
makefile
whereas
Mupdate
generates
a
brand
new
makefile
an existing makefile whereas Mupdate generates a brand new makefile
Notes:
Slide 289
module simple;
reg clk, a;
wire b;
initial
// initialize registers and generate the clk
begin
a = 0;
clk = 0;
end
always @ (posedge clk)
a = !a;
inv_things inv1 (a,b);
//toggle a every clock cycle
Parent
Module
//module instantiation of module inv_things
always @ (b)
$display ("a = %b and b = %b",a,b);
initial
#1000 $stop;
simple.v
// stop after 1000 time steps
endmodule
module inv_things (a,b);
input a;
output b;
reg b;
always @ (a)
b<= #5!a;
Child
Module
// invert a, delay 5 and assign to b
endmodule
Quiz: What coding style problems can you see with this code?
Notes:
Slide 290
Graphical User Interface: VirSim

A great way to study/debug your HDL code is by means of the GUI
(like having a programmable logic analyzer hooked to the simulator)
The next few slides are a quick tour using our previous code example
Working directory: virsim_tutorial
NOTE: parameter order does not matter
To start: invoke vcs by typing:
vcs simple.v -RI -line -s
Simulator binary
Design file
Run & use the VirSim GUI
Allow line commands
Stop at time zero
Notes:
Slide 291
VirSim GUI
Other Window
launch buttons
( VCS v7.0 shown here )
VirSim Interactive
Window (IW)
Available VirSim windows:

Hierarchy navigate around the design hierarchy
Run Simulation
button
Waveform display simulation output as waves

Register - create custom views of signals
Source show sourcecode, set breakpoints etc.
Logic show connectivity info up & down hierarchy
User defined
Buttons
Left Mouse Button

Right Mouse Button
(LMB)
(RMB)
For selecting,
For pop-up
pulldown
menus
menus, text
(little-used)
etc
Middle
Mouse Button
(MMB)
for drag-drop
operations
VCS Control
Notes:
Slide 292
VirSim: Waveforms
#1
1. Click the Hierarchy and Waveform buttons

using the Left Mouse Button (LMB).
Notice 2 new windows open
Hierarchy Browser (HB) window, which shows
the structure of your design graphically.
Waveform Window (WW) which looks like a
logic analyzer connected to your design.
2. Select the gray simple icon from the HB
window using the Middle Mouse Button (MMB)
and drag-drop it into the WW window.
Notice how WW updates with the names of
all signals in module simple (a, b & clk).
#2
Answer: They show that no waveform data has been logged yet (Simulation hasnt started).
Question:
What do these gray bars in WW mean?
Notes:
Slide 293
VirSim: Window Links

#3
3. Some VirSim windows have a chain-link

icon in the top-right corner
Clicking this icon brings up a menu which
allows windows to be related together in
groups: SIM, A, B etc (more info. below).
Initially new windows are grouped together
into the A group.
Shortly youll see why we want to change
this for simulation.
Window Linking:
Some VirSim windows (Waveform Window, Source Window, Logic Browser,
and Register Window) may be linked in order to synchronize operations,such
as breakpoint searches, value changes, and change times.
For example, changing the time in one linked window automatically changes
the view in the other linked windows to that time. Linked windows display a
common link letter (A ,B etc.) in the upper-right corner of the window (next to
the chain icon). SIM is the main Simulator group.
Notes:
Slide 294
VirSim: Hierarchy Browsing

4. Notice icons for simple and inv1 in the HB window.
Remember the parent/child, simple/inv1 slide?
This is a graphical representation of that
relationship.
#4
#5
5. A single click of the Left Mouse Button (LMB) on

either icon (simple or inv1) causes a list of the
signals within that module to be displayed in the
bottom right pane.
Handy GUI Tip:

To select ALL signals in a module to be displayed,
select its icon from the Design Hierarchy pane of HB
and drop it on the WW as you did in step #2.
To select a specific signal to be displayed in the
waveform window, drag it from the Signal Select
pane of HB and drop it on the WW.
Notes:
Slide 295
VirSim: Run the Simulator

#6
#7
6. Click the Run Simulation button in IW.

7. Notice simulation output appears in IW.
8. See WW update with signal data.
Waveforms
#8
Answer: Its in several places, like the bottom pane of IW and its where waves end and gray bars begin in WW.
Question:
How can you tell the
current simulation time?
Time
Notes:
Slide 296
#9
VirSim: Waveform controls

9. Handy buttons allow zoom in, out etc.
10. Click the Z% button now and
select 100% from the popup.
Notice the window redraws to
show all signal activity logged so far.
WW has 3 cursors (Icur, C1 & C2) which
are described below.
#10
3 Cursors:
The main 2 cursors (C1 & C2) are user-controlled by a mouse
click close to a signal edge in WW:
LMB for C1, MMB for C2.
Current location (in time) for any 2 cursors is shown in the
pane at top-left (C1 & C2 show here).
The third cursor Icur shows current simulation time
when WW is linked with the SIM group (not shown here).
Delta indicates the time delta between the cursors
(handy for measuring pulse widths etc.).
These 2 gadgets allow a choice of which cursors to display.
Notes:
Slide 297
VirSim: Restarting Simulation

#11
11. In the IW click the Sim pulldown &

choose Re-exec.
The simulator resets to time zero
and the WW grays out all waveforms
again because no data has been logged.
NOTE: Even if source-code has been changed

Re-exec simply restarts the SAME simulation,
it does NOT recompile the source.
Notes:
Slide 298
VirSim: Source window
#12
12. Click the Source button in VirSim.

The Source window (SW) opens. SW
shows code execution and allows you
to set & clear line breakpoints. Notice
that its empty until you click-drag an icon
from HB into SW just as you did for WW
earlier. Click-drag the simple icon now.
Important GUI Tip:

No green or red dots in your
source window?
You forgot the -line command line switch
#13
13. Take notice of the green dots in SW.

These indicate executable lines, or in
other words, lines where a breakpoint
may be set...
#14
14. Click on the green dot for line 18.

Notice that a red-dot appears to show
a breakpoint has been set at line 18.
AND
the Run to Next Breakpoint gadget
becomes active (red)
.
(Do not do it now, but you could clear this
breakpoint by clicking the red dot )
Notes:
Slide 299
#15
VirSim: Hitting a breakpoint

15.
The red double-arrow icon at the top of

SW is a quick way to advance simulation
to the next breakpoint. Click it now!
The simulation time should advance to 25
Did nothing happen?. Did you hear a beep?
#16
16.
#17
The problem may be that SW is not part

of the SIM group, so it cannot advance the
simulation.
If necessary, use the chain gadget to
link SW with SIM and then click the red
double-arrow again
Notice that simulation hits a breakpoint
at time 25, where line 18 is scheduled
to be executed.
Handy GUI Tip:

During debug, you probably want all your
windows linked to the SIM group.
17. Take notice of the arrows in SW.
Yellow: Indicates the currently executing line
Blue: Indicates other lines that have executed
in this same timestep (more on this later)
Notes:
Slide 300
VirSim: Code profiling

#18
18. In the SW click the Display pulldown

and select Show Coverage.
Notice the arrows have been replaced
by numbers at the very left of the SW.
19. These numbers are a count of how
many times the corresponding line of
code has been executed in the
simulation. This information can be
very helpful in analyzing the
performance of your code as well as
the quality of your test vectors
(More on this later)
#19
Question:
What does an execution count
of zero tell us?
Answer: Well, perhaps there is some line of code that CANNOT be executed,
but more likely, they were missed by our test vectors. GOOD TO KNOW!
Notes:
Slide 301
VirSim: Exiting Simulation

19. To exit simulation, select Exit from the File
pulldown in any VirSim Window (or type Ctl-x).
Notice a new dialog box opens, asking if
you want to save your current configuration
#19
20. Click Yes and specify a filename (my.cfg)

in the Save File Dialog window that opens.
Notice, the file is saved and the VirSim
environment closes.
#20
21. Rerun VCS in the same way as before:

vcs -RI -line -s -Mupdate simple.v
#22
#23
Handy GUI Tip:

22. In IW, click Load Configuration from
the File pulldown.
23. Select the configuration file you just
saved (my.cfg) and click OK.
VirSim returns itself to the saved configuration,
windows, contents and all.
Notes:
Slide 302
#25
VirSim: Rebuild & Re-exec

24. What if you make a code change in your editor
and want to re-simulate with the new code?
Can you do this without saving a configuration
and exiting/restarting the GUI as you just did
in steps #17-21?
#24
Just edit your code and save the changes.
Then, in the IW click the Sim pulldown &
choose Rebuild & Re-exec
25. Notice that the simulator exits but the GUI
remains open. Once the simulator has
recompiled your sourcecode, it reconnects
to the GUI. Next, click the green run arrow
in IW to rerun the simulation and update all
active GUI windows (SW, WW etc).
Notes:
Slide 303
Slide 304
Customer Support
2003 Synopsys, Inc. All Rights Reserved
Customer Support
2003
CS- 1
CS-1
Synopsys Support Resources

1. Build Your Expertise:
Customer Education Services
z www.synopsys.com
Workshop schedule and registration

Download materials (SolvNet id
required)
2. Empower Yourself:
solvnet.synopsys.com
Online technical information and
access to support resources
z Documentation & Media
z
3. Access Synopsys Experts:

Support Center
CS- 2
Customer Support
2003
CS-2
SolvNet Online Support Offers:
Immediate access to the

latest technical
information
Thousands of expertauthored articles, Q&As,

scripts and tool tips
Enter-a-call online
Support Center access
Release information
Online documentation
License keys
Electronic software
downloads
Synopsys
announcements (latest
tool, event and product
information)
CS- 3
Customer Support
2003
CS-3
SolvNet Registration is Easy

1. Go to solvnet.synopsys.com/
ProcessRegistration to
<register>.
2. Following the instructions link to
Site ID, if you need to
determine your Site ID.
3. Pick a username and password.
4. Authorization typically takes just
a few minutes.
CS- 4
Customer Support
2003
CS-4
Support Center: AE-based Support
Industry seasoned Application Engineers:

z
z
z
Great wealth of applied knowledge:

z
Service >2000 issues per month
Remote access and debug via ViewConnect

Contact us:
z
z
z
50% of the support staff has > 5 years applied experience

Many tool specialist AEs with > 12 years industry experience
Access to internal support resources
Fastest access
Web
Enter A Call from solvnet.synopsys.com
E-Mail
Phone
support_center@synopsys.com
1-800-245-8005
Business Hours: Monday - Friday, 7am - 5:30pm PST
CS- 5
Customer Support
2003
CS-5
Other Technical Sources
Application Consultants (ACs):

z
Tool and methodology pre-sales support
Contact your Sales Account Manager for more information
Synopsys Professional Services (SPS) Consultants:

z
Available for in-depth, on-site, dedicated, custom consulting
Contact your Sales Account Manager for more details
SNUG (Synopsys Users Group):

z
www.snug-universal.org
CS- 6
Customer Support
2003
CS-6
Summary: Getting Support
Customer Education Services
SolvNet
Support Center
SNUG
CS- 7
Customer Support
2003
CS-7
CS- 8
Customer Support
2003
CS-8

SystemVerilog 3.0d.VCS7.1 Beta

Uploaded by

Document Information

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

SystemVerilog 3.0d.VCS7.1 Beta

Uploaded by

Copyright:

Available Formats

CUSTOMER EDUCATION SERVICES

System Verilog (VCS7.1B)

Developed and Presented By:

Synopsys Customer Education Services

Copyright Notice and Proprietary Information

Right to Copy Documentation

Destination Control Statement

Service Marks (SM)

System Verilog (VCS7.1)

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

This page was intentionally left blank.

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Assertion based Verification

Appendix A: VCS/Virsim introduction

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

This page was intentionally left blank.

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Timeline Verilog to SystemVerilog

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Cadence acquires Gateway

Verilog enters the Public Domain

Verilog Standardized (IEE1364-1995)

Verilog 2001 (IEEE 1364-2001)

Vera, OVA etc

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Verilog users today

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Use SystemC and/or C++ because:

Tuned language for Architectural/Algorithmic modeling

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Most Verilog design is done at RTL for synthesis.

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

Most Verification in Verilog is done at the functional level.

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

The promise of System Verilog 3.0

2003,2004 Willamette HDL, Inc.

2003 Willamette HDL, Inc. &

System Verilog 3.0 pedigree

New ( Unique ) Features