3/6/2006

VCS SystemVerilog Assertions Training Exercises

LAB 1: SVA / VCS Overall Inline Tool Flow using checkers
Goal

Get Familiar with Inlined SVA Flow

Location

SVA/lab_1

Design

Traffic Light Controller

Allocated Time 45 minutes

The design file is named traffic.v. There are 2 state machines that control the lights
for the North/South traffic and for the East/West traffic. The state variables are named
ps0 and ps1. There are also 6 binary signals that are the outputs of the traffic module
and directly control the 2 traffic lights:
Signal

Functionality

ps0

5-bit FSM state variable, 1-hot encoded for North/South Lanes

ps1

5-bit FSM state variable, 1-hot encoded for East/West Lanes

g0

Green Light for N/S; 1 on, 0 off

y0

Yellow Light for N/S; 1 on, 0 off

r0

Red Light for N/S; 1 on, 0 off

g1

Green Light for E/W; 1 on, 0 off

y1

Yellow Light for E/W; 1 on, 0 off

r1

Red Light for E/W; 1 on, 0 off

It is required to verify the following invariant properties of the design:

1) The state codes of ps0 respect the one-hot encoding (1 bit asserted)
2) The state codes of ps1 respect the one-hot encoding (1 bit asserted)
3) At most 1 lane should have a green light at any time
4) At most 1 lane should have a yellow light at any time

2004 Synopsys, Inc.

1 of 9

3/6/2006

Use the appropriate checkers from the SVA Checker Library and instantiate them in the
design. Consider the following checkers:
Name
assert_one_hot

assert_mutex

Parameters
#(severity_level, width, options, msg, category)
severity_level: Default value is 0.
options: Unused. (The only supported option is
options=1, which defines the assertion as a
constraint for formal tools.) Default is 0.
width: Width of the port test_expr.
msg: String to be printed upon failure.
category: Category value for control over
assertions. Default is 0.
#(severity_level, edge_expr, msg, category)
severity_level: Default value is 0.
edge_expr: Defines clock sampling edge. 0 =
posedge, 1 = negedge. Default is 0.
msg: String to be printed upon failure.
category: Category value for control over
assertions. Default is 0.

Arguments
(clk,reset_n,test_expr)
reset_ n: reset signal,
active low
clk: sampling clock at
posedge
test_expr: expression to be
checked

(clk, reset_n, a, b)
reset_ n: reset signal,
active low
clk: sampling clock at
specified edge
a, b: two expressions that
must never be 1 at the
same time

To compile the design with the assertions in debug mode:

> vcs traffic.v -sverilog -PP -assert enable_diag \
+define+ASSERT_ON -y $VCS_HOME/packages/sva +libext+.v \
+incdir+$VCS_HOME/packages/sva
To run a simulation:
> simv -assert success assert verbose -assert report
The report will appear on screen and also in a report file named by default assert.report
in the current directory.
Note that these commands can also be found in the run file in the lab1 directory.
There should be assertion successes and failures reported. Can you identify the source of
the failures in the design and correct it?
A binary wave file called vcdplus.vpd is also created during the simulation. To view
the assertion results in Virsim enter the following command:
> vcs RPP &

2004 Synopsys, Inc.

2 of 9

3/6/2006
Open the file vcdplus.vpd and then in the hierarchy window open tb and then dut. You
should see 4 assertion groups. Each group contains the associated design signals as well
as another group of signals named clk_event, result and end_time. Drag all the signals
onto the wave panel and examine how the assertion successes and failures are presented.
To enable SVA coverage add the cm assert switch at compile and run times, i.e.:
> vcs traffic.v -sverilog -PP -assert enable_diag \
+define+ASSERT_ON -y $VCS_HOME/packages/sva +libext+.v \
+incdir+$VCS_HOME/packages/sva cm assert
> simv -assert success -assert report cm assert
> assertCovReport
To view the coverage results use Netscape:
> netscape simv.vdb/reports/report.index.html

2004 Synopsys, Inc.

3 of 9

3/6/2006

LAB 2: SVA / VCS Custom Flow Simple properties

Goal

Familiarization with Custom SVA Flow

Location

SVA/lab_2

Design

Traffic Light Controller

Allocated Time 45 minutes

In this lab the objective is to create a number of custom SVA assertions that will be
placed in a separate module and file. This checker module will then be bound to the
design using the bind statement.
Use the file traffic.sv as a template for the custom assertions. In the file the module
interface and the binding is already done.
Write SVA assertions to verify the following behaviors of the traffic controller:
1) Proper state transitions following the cycle green -> yellow -> red -> red ->
green, for both lights (Note that the light will remain in the red state for 2
cycles). More specifically, verify that
If (currently green) then (next is yellow)
If (currently yellow) then (next is red for two clock cycles)
If (changed to red in the past cycle and is red) then ( next it is green)
Hint: Create a property (sequence) |-> (sequence), and then assert that property,
repeat this 5 more times.
Hint: Consider using the built-in functions $past and $rose.
Should these properties hold also during reset? If not, what can you do about it?
2) Only one light (red or green or yellow) may be on for the N/S lane. Repeat for
the E/W lane.
Hint: Use the built-in function $countones.
3) Upon exiting reset, both lights should be red (reset is active high).
Hint: Use the built-in function $fell.
The following two built-in functions can be used when writing the properties:
2004 Synopsys, Inc.

4 of 9

3/6/2006

$countones( x )
$past( x, n )
$rose( x )
$fell( x )

Returns the number of bits set to 1 in the bitvector expression x

Returns the value of the bitvector expression x <n> cycles ago.
Returns true (1) iff the bit expression x changed value from 0 to 1
as sampled by two consecutive clock ticks.
Returns true (1) iff the bit expression x changed value from 1 to 0
as sampled by two consecutive clock ticks.

Again, to compile the design with the assertions in debug mode:

> vcs traffic.v traffic.sv -sverilog -PP -assert enable_diag
\
+define+ASSERT_ON -y $VCS_HOME/packages/sva +libext+.v \
+incdir+$VCS_HOME/packages/sva
To run the simulation:
> simv assert verbose -assert report
Note that the above commands can be found in the run file.
There should not be any assertion failures.
A binary wave file called vcdplus.vpd is created during the simulation. To see the
assertion results in the GUI, invoke Virsim as in Lab 1.
Questions:
1. How many evaluation attempts of each assertion were made? How many of
them were vacuously satisfied? Hint: Use the cm assert option
____________________________________
2. How many times did the light cycle through (green, yellow, red) for the N/S
lane?

2004 Synopsys, Inc.

5 of 9

3/6/2006

LAB 3: SVA / VCS Custom Flow Protocol checking

Goal

Familiarization with Custom SVA Flow

Location

SVA/lab_3

Design

Memory Controller

Allocated Time 60 minutes

The design file is named design.v. There is an SVA checker module started for you in
the file design.sv It already contains the module interface and some useful boolean
expressions. The bind statements is also in that file.

The design hierarchy is as follows:

cntrlr_top Top level random stimulus generation, clock generation

cntrlr_tb Bus functional models and memory model testbench
cntrlr
DUT - Memory controller

The protocol followed by the controller is shown on the next page. The start of Read or
Write operation is marked by a 1-cycle-wide pulse on adxStrb. If it is a Write operation,
busRdWr_N is pulsed low at the same time.
Read operation: busRdWr_N is held high with adxStrb. When adxStrb is sampled high,
the address is transferred from busAddr[5:0] to ramAddr and remains stable for 2 cycles.
busAddr[7:0] is decoded and the appropriate cex_N (x = 0, 1, 2, or 3) line is driven low
for one cycle one cycle after adxStrb is sampled high. When cex_N is sampled low, the
data on ramData is driven to busData for one cycle. This completes the Read operation.
Write operation: busRdWr_N is pulsed low with adxStrb high. When adxStrb is sampled
high, the address from busAddr [5:0] is transferred to ramAddr and remains stable for 4
cycles. busAddr[7:0] are decoded and drive the appropriate cex_N line low 2 cycles later,
for one cycle. rdWr_N is driven low at the same time as cex_N. busData is sampled with
adxStrb high and transferred to ramData 1 cycle later where it stays stable for 3 cycles.
This completes the Write operation.

2004 Synopsys, Inc.

6 of 9

3/6/2006
The memory Read protocol is as shown in the following diagram (delays in cycles).

2
N
The memory Write protocol is as shown in the following diagram (delays in cycles).

1
3
4

N
2004 Synopsys, Inc.

7 of 9

3/6/2006
The following are two useful boolean expressions that when true mark the beginning of a
Read, resp. Write, operation:
read_req
write_req

Read operation starts when adxStrb is high, busRdWr_N high, and !reset
Write operation starts when adxStrb is high, busRdWr_N low and !reset

Write the following assertions for the memory controller:

1) There are 4 memory chip enable signals (ce0_N, ce1_N, ce2_N,
ce3_N). At most one of them should ever be asserted low.
Are there any assertion failures? If yes, locate the error in the design,
correct it and re-simulate.
Hint: There are two nested case statements (one for read and one for
write) where nxCe_ is assigned.
2) Any pulse on cex_N should be one clock cycle wide. Take into
account reset when this condition may not apply.
3) In a Read operation, the correct cex_N should be sampled low 2 cycles
after adxStrb is sampled high.
4) In a Write operation, the correct cex_N should be sampled low 3 cycles
after adxStrb is sampled high.
5) In a Read operation, the value on ramData when cex_N is sampled low
should appear (be sampled) on busData one cycle later.
6) Write cover property statements that detect the occurrence of a Read
and of a Write operation.

Questions:
1) How many times did a Read operation occur?
____________________________________
2) How many times did a memory operation occur (Read + Write)?
____________________________________

2004 Synopsys, Inc.

8 of 9

3/6/2006

LAB 4: Advanced SVA

Goal

Advanced SVA

Location

SVA/lab_4

Design

Memory Controller

Allocated Time 90 minutes

The design is the same as in Lab 3. Write assertions that verify the following behaviors:
1. Once cex_N returns inactive (all deasserted), they all four must remain inactive until
the next assertion of adxStrb.
Use repetition [*M:N] in the property.
As it is not known when the next address strobe will arrive, you can specify an
open-ended range for N. You could specify a finite value of N as an equivalent of
a watchdog timer check. However, in that case the finite delay is in fact verifying
that the environment is behaving correctly, while the assertion is to verify the
behavior of the DUT. Would this be a correct formulation of the property?
2. Verify that
the address is correctly transferred from busAddr to ramAddr, and
it remains stable for the required number of clock cycles, in both Read and Write
operations.
3. Verify that the controller correctly transfers data from busData to ramData during a
Write operation.
4. Verification of the memory and controller: Verify that
the memory retains the last written value to an address. I.e., after a Write, a
subsequent Read operation will read back that value, regardless other intervening
operations to different addresses, as observed from the bus signals.
after a reset, as long as an address has not been written into, the value read out
should be 0.
Question: Consider implementing the above assertions using SVA local variables and
using Verilog variables. What are the pros and cons, in particular regarding property 4?

2004 Synopsys, Inc.

9 of 9