Detecting Boundary Condition Bugs through System Verilog Functional Coverage Jayabrata Chakraborty HCL Technologies Ltd. Noida, India.

Transcription

1 Detecting Boundary Condition Bugs through System Verilog Functional Coverage Jayabrata Chakraborty HCL Technologies Ltd. Noida, India. November,2008

2 Abstract This document describes the necessity to identify the boundary condition bugs present in design modules; and discusses about the effective solution provided through functional coverage over code (condition) coverage in making sure that such scenarios are identified during verification. 1. Introduction Boundary conditions present in a design module are crucial check items which should be identified and listed by the module designer for the purpose of verification. The boundary conditions are not covered in code coverage; so there should be some other way to make sure that they are not missed during verification. If the boundary conditions are not verified thoroughly during the block level verification of a module then there remains a possibility of a major bug being carried over to the system level. Since through code coverage (condition coverage) it is not possible to know whether boundary conditions have been covered or not, it is necessary to use functional coverage. Properties for identified boundary conditions can be created and covered. The covered properties can be tracked through coverpoints in covergroups. The boundary conditions identified and covered through coverpoints in covergroups at the block level can be carried forward to the system level, also enabling a robust verification at the system level. The following sections analyze a real boundary condition bug scenario and discuss about how code coverage was not sufficient in tracking it. The possible boundary conditions for the bug scenario are listed and the implementation detail of one using System Verilog is mentioned. 2

3 2. Boundary condition bug analysis In this section a boundary condition bug present in a line of code is described with the help of a waveform and the associated condition coverage report for that line of code is discussed. After the discussion we can conclude that the verification of that boundary condition bug scenario does not get reflected in the condition coverage report Example Code: The concerned line of code whose boundary conditions are to be verified is shown below, related to the signal run : run : (posedge CLK_N or posedge init) begin else if (! Req && nstate==ncptrans) run <= 1'b1; The following code templates will help to understand the Bug Description and Waveform portions better: Req is asserted or (posedge CLK). Req_r : (posedge CLK or posedge init) begin if (Req) Req_r <= 1'b1; else Req_r <= 1'b0; Sel : (posedge CLK or posedge init) begin else if (cstate== Ncptrans &&! Req_r) Sel <= 1'b1; 3

4 cstate : (posedge CLK or posedge init) begin else if (! Req_r) cstate <= nstate; outdata : (posedge CLK or posedge init) begin if (Sel) outdata <= output_t; else outdata <= other_data ; output_t : Consider output_t to be a variable whose value CLK) when run is asserted Bug Description In the waveform shown below the negation of Req takes (posedge CLK); 1 CLK cycle after the nstate Init -> Ncptrans transition; causing an early assertion of run with respect to Sel; which causes the loss of the first data of output_t ee27fef1 in the output outdata Waveform 4

5 2.4. Code Coverage (Condition Coverage) For the mentioned line of code; the following Condition Coverage report was generated showing 100% coverage The below mentioned Condition Coverage report gives no idea about; whether any boundary conditions have been covered or not. In fact the bug was identified after obtaining the successful code coverage report. In the next section the identification of the associated boundary conditions for the mentioned line of code; and the implementation of functional coverage to make sure that those boundary conditions are covered; have been discussed: 3. Identification of Boundary Condition & Implementation of Functional Coverage 3.1.Step I: Listing Of Boundary Conditions CODE: else if (! Req && nstate==ncptrans) run <= 1'b1; For determining the boundary conditions of this portion of code two points can be considered: Negation of Req; and Transition of nstate from Init -> Ncptrans; 5

6 There can be three possible scenarios: SCENARIO CLK: Req is negated 1 CLK before nstate Init -> Ncptrans transition takes place; SCENARIO CLK: Req is negated simultaneously when nstate Init -> Ncptrans transition takes place; SCENARIO CLK: Req is negated 1 CLK after nstate Init -> Ncptrans transition takes place; Out of the three mentioned scenarios, SCENARIO 3, when created and encountered; identified the major bug that caused the transmission without the first data. The loss of first DWORD data during transmission was a major bug. 3.2.Step II: Creating Sequence, Property And Cover For Boundary Conditions Whether the boundary conditions have been covered in a simulation run, can be easily identified with the implementation of functional coverage for each and every boundary condition. Example: Functional Coverage Implementation for SCENARIO 3 SCENARIO 3: Check boundary condition Req negated 1 CLK after nstate Init -> Ncptrans transition: SEQUENCE: sequence (posedge `TOP.mod.CLK) (`TOP.mod.nstate == 3'h1) ##1 (`TOP.mod.nstate == 3'h4) ##1 $fell (`TOP.mod.Req); sequence PROPERTY: property Req_0_1CLK_after_Init_to_Ncptrans_run_prop; Req_0_1CLK_after_Init_to_Ncptrans_run_seq; property 6

7 COVER PROPERTY: Req_0_1CLK_after_Init_to_Ncptrans_run_cov: cover property (Req_0_1CLK_after_Init_to_Ncptrans_run_prop) begin mod_bc.req_0_1clk_after_init_to_ncptrans_run = 1'b1; $ d i s p l a y ( " % 1 0 d C o v e r e d Req_0_1CLK_after_Init_to_Ncptrans_run condition\n", $time); The variable mod_bc.req_0_1clk_after_init_to_ncptrans_run is a class property accessible through the class instance mod_bc of the class mod_bc_cls shown in the next section. In the current example the sequence, property and cover property are considered to be inside a program block where the class mod_bc_cls is also instantiated. So, the class property can be accessed by the cover property. For further reusability the above mentioned sequence, property and cover property can be created inside a module say mod_cov which will be compiled with the testbench. In that case, the Req_0_1CLK_after_Init_to_Ncptrans_run in the cover property can be declared as a variable inside this module. As; logic Req_0_1CLK_after_Init_to_Ncptrans_run; This variable can be accessed by the coverpoint in the class through the module name. As; mod_cov. Req_0_1CLK_after_Init_to_Ncptrans_run The next level of implementation shows the inclusion of a covergroup and the coverpoints in a class which will help those features to be carried over from the block level to the system level verification. 3.3.Step III: Implementation Of Covergroup And Coverpoints In Class class mod_bc_cls; logic Req_0_1CLK_after_Init_to_Ncptrans_run; covergroup (posedge `TOP.mod.CLK); Req_0_1CLK_after_Init_to_Ncptrans_run_cp: coverpoint 7

8 Re q _ 0 _ 1 C L K _ a f t e r _ I n i t _ t o _ N c p t r a n s _ r u n { b i n s Req_0_1CLK_after_Init_to_Ncptrans_run_b = {1} ;} group: mod_cg function new; mod_cg = new; function: new class: mod_bc_cls The functional coverage contents of the class mod_bc_cls when instantiated in a Test Case will help track the boundary condition. T h e c o v e r g r o u p m o d _ c g a n d t h e c o v e r p o i n t Req_0_1CLK_after_Init_to_Ncptrans_run_cp help obtain the result of the boundary condition being covered or not. 4. Conclusion Identifying the possible boundary conditions present in a design module is a necessary and important task to be efficiently carried out by the designer himself; The identified conditions can then be provided to the verification engineer for creating functional coverage; System Verilog contains many features to implement functional coverage for such boundary conditions through sequence, property, cover, bins, coverpoint, covergroup and many more; Implementing covergroups in classes can help carry the coverage of identified boundary conditions from the module level to the system level; Using the VCS Unified Coverage Report Generator (URG) the covergroups and coverpoints can be tracked; Constrained Random Verification (CRV) is the best way to cover those boundary conditions; Implementing functional coverage for boundary conditions results in a very robust verification environment and flawless verification. 5. References SystemVerilog 3.1a Language Reference Manual; Verification methodology manual for SystemVerilog, J. Bergeron, E. Cerny, A.Hunter, Nightingale, Springer,

9 Hello, I m from HCL!. We work behind the scenes, helping our customers to shift paradigms & start revolutions. We use digital engineering to build superhuman capabilities. We make sure that the rate of progress far exceeds the price. And right now, 56,000 of us bright sparks are busy developing solutions for 500 customers in 19 countries across the world. How can I help you? 9