VCS SystemVerilog Assertions Training Exercises

Transcription

1 VCS SystemVerilog Assertions Training Exercises LAB : SVA / VCS Overall Inline Tool Flow using checkers Goal Get Familiar with Inlined SVA Flow Location SVA/lab_ 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 orth/south traffic and for the East/West traffic. The state variables are named ps0 and ps. There are also 6 binary signals that are the outputs of the traffic module and directly control the 2 traffic lights: Signal ps0 ps g0 y0 r0 g y r Functionality 5-bit FSM state variable, -hot encoded for orth/south Lanes 5-bit FSM state variable, -hot encoded for East/West Lanes Green Light for /S; on, 0 off Yellow Light for /S; on, 0 off Red Light for /S; on, 0 off Green Light for E/W; on, 0 off Yellow Light for E/W; on, 0 off Red Light for E/W; on, 0 off It is required to verify the following invariant properties of the design: ) The state codes of ps0 respect the one-hot encoding ( bit asserted) 2) The state codes of ps respect the one-hot encoding ( bit asserted) 3) At most lane should have a green light at any time 4) At most lane should have a yellow light at any time 2004 Synopsys, Inc. of 9

2 Use the appropriate checkers from the SVA Checker Library and instantiate them in the design. Consider the following checkers: ame 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=, 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. assert_mutex #(severity_level, edge_expr, msg, category) severity_level: Default value is 0. edge_expr: Defines clock sampling edge. 0 = posedge, = negedge. Default is 0. 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 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 at the same time To compile the design with the assertions in debug mode: > vcs traffic.v -sverilog -PP -assert enable_diag \ +define+assert_o -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. ote that these commands can also be found in the run file in the lab 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 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_o -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 etscape: > netscape simv.vdb/reports/report.index.html 2004 Synopsys, Inc. 3 of 9

4 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: ) Proper state transitions following the cycle green -> yellow -> red -> red -> green, for both lights (ote 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 /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

5 $countones( x ) Returns the number of bits set to in the bitvector expression x $past( x, n ) Returns the value of the bitvector expression x <n> cycles ago. $rose( x ) Returns true () iff the bit expression x changed value from 0 to as sampled by two consecutive clock ticks. $fell( x ) Returns true () iff the bit expression x changed value from 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_o -y $VCS_HOME/packages/sva +libext+.v \ +incdir+$vcs_home/packages/sva To run the simulation: > simv assert verbose -assert report ote 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. Questions:. 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 /S lane? 2004 Synopsys, Inc. 5 of 9

6 LAB 3: SVA / VCS Custom Flow Protocol checking Goal Location Design Familiarization with Custom SVA Flow SVA/lab_3 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 cntrlr_tb cntrlr Top level random stimulus generation, clock generation Bus functional models and memory model testbench 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 -cycle-wide pulse on adxstrb. If it is a Write operation, busrdwr_ is pulsed low at the same time. Read operation: busrdwr_ 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_ (x = 0,, 2, or 3) line is driven low for one cycle one cycle after adxstrb is sampled high. When cex_ is sampled low, the data on ramdata is driven to busdata for one cycle. This completes the Read operation. Write operation: busrdwr_ 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_ line low 2 cycles later, for one cycle. rdwr_ is driven low at the same time as cex_. busdata is sampled with adxstrb high and transferred to ramdata cycle later where it stays stable for 3 cycles. This completes the Write operation Synopsys, Inc. 6 of 9

7 2004 Synopsys, Inc. 7 of 9 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)

8 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_ high, and!reset Write operation starts when adxstrb is high, busrdwr_ low and!reset Write the following assertions for the memory controller: ) There are 4 memory chip enable signals (ce0_, ce_, ce2_, ce3_). 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_ should be one clock cycle wide. Take into account reset when this condition may not apply. 3) In a Read operation, the correct cex_ should be sampled low 2 cycles after adxstrb is sampled high. 4) In a Write operation, the correct cex_ should be sampled low 3 cycles after adxstrb is sampled high. 5) In a Read operation, the value on ramdata when cex_ 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: ) 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

9 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:. Once cex_ returns inactive (all deasserted), they all four must remain inactive until the next assertion of adxstrb. Use repetition [*M:] in the property. As it is not known when the next address strobe will arrive, you can specify an open-ended range for. You could specify a finite value of 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 pro s and con s, in particular regarding property 4? 2004 Synopsys, Inc. 9 of 9