sva excercise 1

8/9/2019 SVA Excercise 1

1/9

3/6/2006

© 2004 Synopsys, Inc. 1 of 9

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 moduleand 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


2/9

3/6/2006


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

Name Parameters Arguments

assert_one_hot #(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 aconstraint 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.

(clk,reset_n,test_expr)reset_ n: reset signal,

active lowclk : sampling clock at

posedgetest_expr : expression to be

checked

assert_mutex #(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 overassertions. Default is 0.

(clk, reset_n, a, b)

reset_ n: reset signal,

active lowclk : sampling clock atspecified edge

a, b: two expressions thatmust never be 1 at thesame 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 ofthe failures in the design and correct it?

A binary wave file called “vcdplus.vpd” is also created during the simulation. To viewthe assertion results in Virsim enter the following command:

> vcs –RPP &


3/9

3/6/2006


Open the file vcdplus.vpd and then in the hierarchy window open tb and then dut . Youshould see 4 assertion groups. Each group contains the associated design signals as wellas another group of signals named clk_event, result and end_time. Drag all the signalsonto 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


4/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


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 thedesign using the bind statement.

Use the file “traffic.sv” as a template for the custom assertions. In the file the moduleinterface 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 2cycles). 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 forthe 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:


5/9

3/6/2006


$countones( x ) Returns the number of bits set to 1 in the bitvector expression x

$past( x, n ) Returns the value of the bitvector expression x cycles ago.

$rose( x ) Returns true (1) iff the bit expression x changed value from 0 to 1as sampled by two consecutive clock ticks.

$fell( x ) Returns true (1) iff the bit expression x changed value from 1 to 0as 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 theassertion results in the GUI, invoke Virsim as in Lab 1.

Questions:

1. How many evaluation attempts of each assertion were made? How many ofthem were vacuously satisfied? Hint: Use the –cm assert option ____________________________________

2. How many times did the light cycle through (green, yellow, red) for the N/Slane?


6/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


The design file is named “design.v”. There is an SVA checker module started for you inthe file “design.sv” It already contains the module interface and some useful booleanexpressions. 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 orWrite 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 lowfor one cycle one cycle after adxStrb is sampled high. When cex_N is sampled low, thedata 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 sampledhigh, the address from busAddr [5:0] is transferred to ramAddr and remains stable for 4cycles. 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 withadxStrb high and transferred to ramData 1 cycle later where it stays stable for 3 cycles.This completes the Write operation.


7/9

3/6/2006


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

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

N

N

N

1

1

1

1

N

N

N

1

1

1

1

3

0

2


8/9

3/6/2006


The following are two useful boolean expressions that when true mark the beginning of aRead, resp. Write, operation:

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 intoaccount reset when this condition may not apply.

3) In a Read operation, the correct cex_N should be sampled low 2 cyclesafter adxStrb is sampled high.

4) In a Write operation, the correct cex_N should be sampled low 3 cyclesafter adxStrb is sampled high.

5)

In a Read operation, the value on ramData when cex_N is sampled lowshould appear (be sampled) on busData one cycle later.

6) Write cover property statements that detect the occurrence of a Readand 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)?

____________________________________

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

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


9/9

3/6/2006


LAB 4: Advanced SVA

Goal Advanced SVA

Location SVA/lab_4

Design Memory Controller


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 ofa watchdog timer check. However, in that case the finite delay is in fact verifyingthat 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 aWrite 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 interveningoperations 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 outshould be 0.

Question: Consider implementing the above assertions using SVA local variables andusing Verilog variables. What are the pro’s and con’s, in particular regarding property 4?

sva excercise 1

Documents