SYSTEM VERILOG

SYSTEM VERILOG BASICS AND VERIFICATION TECHNIQUES:

SYSTEM VERILOG BASICS AND VERIFICATION TECHNIQUES Presented by, Arthiha.L.J M.Tech (VLSI Design)

SYSTEM VERILOG:

SYSTEM VERILOG Developed by Accellera . Extension of IEEE 1364-2001 Verilog language. Standard and powerful language that combines both the design and verification capabilities in a single language (HDVL). Also includes a powerful declarative language subset, that provides a means to capture the requirements of the design known as SYSTEM VERILOG ASSERTIONS.

DATA TYPES:

DATA TYPES 4-state data types – (0,1,x,z) – same as V erilog. [uninitialized variables = x, uninitialized nets = z]. 2-state data types – (0,1) – new in System Verilog. [uninitialized variables = 0, uninitialized nets = 0].

4-State Data Types:

4-State Data Types Reg r ; // 4-state, Verilog (sizeable) data type. Integer i ; // 4-state Verilog 32 bit signed data type. Logic w ; //4-state SYSTEM VERILOG sizeable data type. Logic data type either permits only a single driving source or procedural assignments from one or more procedural blocks. In System Verilog logic and reg are now the same. Wire net type is still required for multiply driven buses or bi-directional buses.

2-State Data Type:

2-State Data Type Bit b ; //sizeable 1 – bit ‘o’ or ‘1’. Byte b8 ; //8 – bit signed data type. Shortint s ; //16 bit signed integer. Int i ; 32-bit signed integer. Longint l ; 64-bit signed integer.

Verilog Data Types – Internal to the Module:

Verilog Data Types – Internal to the Module Module A ( out,in ); output out; input in; reg out; wire in; always @(in) out=in; endmodule Module B ( out,in ) output out; input in; reg out; wire in; assign out=in; endmodule

External to the Verilog Module:

External to the Verilog Module

System Verilog- Unrestricted Ports:

System Verilog- Unrestricted Ports

Logic Specific Processes:

Logic Specific Processes Three new logic specific processes to show the designers’ intent.

Always_comb:

Always_comb

Always_latch:

Always_latch

Always_ff:

Always_ff

Implicit Port Connections:

Implicit Port Connections Verilog and VHDL both have the ability to instantiate modules using named port connections. System V erilog solves top-level verbosity with two implicit port connection enhancements: - .name port connections - .* implicit port connections

Example of Implicit Port Connections:

Example of Implicit Port Connections Module counter (input logic [2:0]in, input logic clk , rst , output logic [2:0] out); integer count; always @( posedge clk ) begin if( rst ) count<=0; else count<=count+1; end endmodule Module counter_tb ; logic [2:0]in, out; logic clk,rst ; initial begin clk =1; forever #5 clk =~ clk;end initial begin rst =0; #50 rst =1; end counter counter1 (.in(in),. clk ( clk ),. rst ( rst ),.out(out )); // counter counter1(.*); endmodule

ENUMERATION:

ENUMERATION Strong typing at higher levels of abstraction. Very useful for declaring FSM states.

ENUMERATION EXAMPLE:

ENUMERATION EXAMPLE Module fsm_sva1 …. enum reg [1:0] { IDLE=2’b00, READ=2’b01, DLY=2’b10, DONE=2’b11 } state, next; …. endmodule

SIMULATION OUTPUT:

SIMULATION OUTPUT

ENHANCED FOR LOOP:

ENHANCED FOR LOOP VERILOG SYSTEM VERILOG

USER DEFINED DATA TYPES:

USER DEFINED DATA TYPES The type-def keyword allows user-defined data types. Types must be declared before they are used Outside of a module (visible to all design units). Inside a module (visible only to that design unit). Example : typedef logic [63:0] bus_t ; bus_t bus1, bus2;

DATA ORGANISATION:

DATA ORGANISATION Goal: To organize the data same as in high-level programming. System Verilog allows others to see explicit, meaningful relationships in the design. It adds structs , unions & arrays which can be used separately or combined to accurately capture design intent.

STRUCTS:

STRUCTS

ARRAYS:

ARRAYS Vector width – A dimension declared before the object name. Array dimension – A dimension declared after the object name. In Verilog-2001, all data types can be declared as arrays. For example, reg [7:0] MEMORY [1:256]; Where [7:0] is the vector width, [1:256] is the array size

Cont…:

Cont… In System Verilog, arrays are of two types packed array - refer to the dimensions declared before the object name (what Verilog-2001 refers to as the vector width). bit [7:0] c1; // packed array unpacked array - refer to the dimensions declared after the object name. real u [7:0]; // unpacked array

ARRAY EXAMPLE:

ARRAY EXAMPLE

JUMP STATEMENTS:

JUMP STATEMENTS System Verilog adds C – like constructs: ‘break’ and ‘continue’. Break – exists from the loop; Continue - jump to the next iteration of the loop. For example: reg [3:0] b,a ; … for ( int I =0; i <=52;i++) begin a=1; #5 case (b) jump to next iteration of the loop 1: continue; 0: break; endcase a=0; Exit the loop end …

FORK-JOIN:

FORK-JOIN Enables the creation of concurrent processes from each of its parallel statements. The syntax to declare a fork ... join block is: type_of_block @( sensitivity_list ) //sensitivity list is optional fork statement1; statement2; ---- join One or more statements can be specified, each statement shall execute as a concurrent process.

Cont...:

Cont... A Verilog fork ... join block always causes the process executing the fork statement to block until the termination of all forked processes. System Verilog supports 3 types of fork – join processes, viz. Fork – join. Fork – join_any . Fork – join_none .

FORK – JOIN EXAMPLE:

FORK – JOIN EXAMPLE initial begin clk = 0; #5; fork #5  a = 0; #10 b = 0; join clk = 1; end // clk becomes 1 when //time=20 initial begin clk = 0; #5; fork #5  a = 0; #10 b = 0; join_any clk = 1; end // clk becomes 1 when //time=10 initial begin clk = 0; #5; fork #5  a = 0; #10 b = 0; join_none clk = 1; end // clk becomes 1 when //time=5

MAIL BOXES:

MAIL BOXES A communication mechanism that allows messages to be exchanged between processes. Data can be sent to a mailbox by one process and retrieved by another. Mailboxes are created as having either a bounded or unbounded queue size. A bounded mailbox becomes full when it contains the bounded number of messages. A process that attempts to place a message into a full mailbox shall be suspended until enough place becomes available in the mailbox queue. Unbounded mailboxes never suspend a thread in a send operation. An example of creating a mailbox is: mailbox mbox_pointer ;

METHODS OF USING MAIL BOX:

METHODS OF USING MAIL BOX Mailbox is a built-in class that provides the following methods: Create a mailbox: new () Place a message in a mailbox: put() Try to place a message in a mailbox without blocking: try_put () Retrieve a message from a mailbox: get() or peek() Try to retrieve a message from a mailbox without blocking: try_get () or try_peek () Retrieve the number of messages in the mailbox: num()

SYSTEM VERILOG ENHANCEMENTS FOR VERIFICATION:

SYSTEM VERILOG ENHANCEMENTS FOR VERIFICATION

Assertions:

Assertions Assertion is a statement that a certain property must be true. Used to validate the behavior of the design. Used to provide functional coverage and generate input stimulus for validation. Assertion mechanism for verifying – design intent – functional coverage intent. New property and sequence declarations. Assertions and coverage statements with action blocks.

SYSTEM VERILOG ASSERTIONS TYPES:

SYSTEM VERILOG ASSERTIONS TYPES Two types of assertions: - Immediate assertions. - Concurrent assertions. Immediate assertions: - Executed like a statement in the procedural block. - intended to be used with simulation. - keyword: ‘assert’. Concurrent assertions: - Based on clock semantics. - uses sampled values of variables. - keyword: ‘ assert property’.

Assertion usage- example:

Assertion usage- example After the request signal is asserted, acknowledge must arrive within 1 to 2 clocks.

Assertion examples:

Assertion examples Immediate assertion: always @( posedge clk )begin if( req )begin assert_req_check : assert( ack ) else $display(“ ack not received”); end end Concurrent assertion: property req_check ; @( posedge clk ) req |=> ack ; endproperty:req_ack assert_req_check : assert property( req_check );

SVA EXAMPLE:

SVA EXAMPLE

ASSERTION SEVERITY LEVELS:

ASSERTION SEVERITY LEVELS The assertion failure behavior can be specified. - $fatal – Terminates execution of the tool. - $error – A run-time error severity; software continues execution. - $warning – A run-time warning; software continues execution. - $info – No severity; jus prints the message.

SYSTEM FUNCTIONS:

SYSTEM FUNCTIONS $rose (expression) – function returns true if expression transition from low to high. $fell (expression) – function returns true if expression transition from high to low. $past (expression) – function returns previous value of the expression in the previous clock cycle. $stable (expression) – function returns true if the value is unchanged from previous cycle. $ isunknown (expression) – function returns true if expression has any bits other than 1 or 0. $ countones (expression) – function returns a count of the number of bits in an expression that have a value of 1. $ onehot (expression) – function returns true if only one bit of an expression has a value of 1.

SEVERITY LEVELS EXAMPLE:

SEVERITY LEVELS EXAMPLE always @( negedge reset) assert(state==load) else $fatal(“fatal error at state”); always @( posedge clk ) assert(state==load) else $warning(“state and load are not equal”); always @( posedge clk ) assert ($ countones ( decode_out )==30) else $error(“number of ones in the decoder outout is not 30”);

WHERE ASSERTIONS CAN BE SPECIFIED:

WHERE ASSERTIONS CAN BE SPECIFIED Can be embedded in RTL code. In the design model, as a separate concurrent block of code. External to the design model, in a separate file.

CONCURRENT ASSSERTION BUILDING BLOCKS:

CONCURRENT ASSSERTION BUILDING BLOCKS

PROPERTY BLOCKS:

PROPERTY BLOCKS The argument to assert property is a property specification. – can be defined in a named property block. – contains a definition of a sequence of events.

SEQUENCE BLOCKS:

SEQUENCE BLOCKS A complex sequence can be partitioned into sequence blocks. A simple sequence can be specified in the assert property.

Assertion Benefits:

Assertion Benefits Testing requirements : - Assertions require only proper input stimulus to activate the bug and to propagate the bug to the DUT outputs. Reduces debug time : - Assertions enable bug detection exactly when and where they occur. - HDL testing typically detects a bug only multiple clocks after it happened.

Binding properties to instances:

Binding properties to instances System Verilog has an advantage of binding the verification code to DUT designed using any HDL language. Facilitates verification, separate from design.

Binding - Example:

Binding - Example

INTERFACE:

INTERFACE Provides a new hierarchical structure Encapsulates interconnect and communication. Separates communication from functionality. Eliminates “wiring” errors. Enables abstraction in the RTL.

INTERFACE EXAMPLE:

INTERFACE EXAMPLE

EXAMPLE WITHOUT INTERFACE:

EXAMPLE WITHOUT INTERFACE

EXAMPLE WITH INTERFACE:

EXAMPLE WITH INTERFACE Interface simple_bus ; logic req ,grant ; logic [7:0] addr,data ; logic [1:0] mode; logic start,rdy ; endinterface module memMod ( interface a, input bit clk ); logic avail; always @( posedge clk ) a.gnt<= a.req & avail; endmodule module cpuMod (interface b, input bit clk ); endmodule Module top; bit clk =0; simple_bus sb_intf ; memMod mem (.a( sb_intf ),(. clk ( clk )); cpuMod cpu (.b( sb_intf ),. clk ( clk )); endmodule

Coverage Metrics:

Coverage Metrics Coverage metrics are used to gain a confidence by comparing the obtained coverage values after simulation to the specifications of the design. It can be obtained in two ways: Code coverage Functional coverage

CODE COVERAGE:

CODE COVERAGE Describes the degree to which the source code have been implemented. Evaluates the effectiveness of the test benches. Used to motivate improvements in the test suite.

CODE COVERAGE METRICS:

CODE COVERAGE METRICS Statement coverage. Branch coverage. Condition coverage. Toggle coverage. Finite State Machine (FSM) coverage.

Cont…:

Cont… Statement coverage : analyses whether each statement executed at least once. Branch coverage : analyses whether each conditional branch and case alternative has been executed at least once. Condition coverage : analyses sub-expressions within a branch condition. Toggle coverage : analyses state changes of the nodes. FSM coverage : Determines how many states have been reached during simulation. Also determines how many transitions have been exercised in the simulation of the state machine.

FUNCTIONAL COVERAGE:

FUNCTIONAL COVERAGE System Verilog provides a mechanism to know the untested feature using functional coverage. Functional Coverage is "instrumentation" that is manually added to the Test Bench. Functional coverage is better than code coverage where the code coverage reports what was exercised rather that what was tested. System Verilog provides Assertion Coverage method to mention functional coverage.

ASSERTIONS COVERAGE:

ASSERTIONS COVERAGE Assertion coverage looks for the desired behaviour in RTL. It uses assertion language and has direct access to design variables. The specifications are defined using SVA (System Verilog Assertions) language. SVA can be written with in the same design code or as a separate file. Specifications are defined as properties and sequences.

VERIFICATION MANAGEMENT:

VERIFICATION MANAGEMENT Verification management starts with the verification plan. Verification plan contains the specification of the design. It defines the functional coverage model. It collects, merge coverage from multiple sources. Reports coverage data. Imports and links test plan to merged coverage results.

VERIFICATION OF A DESIGN:

VERIFICATION OF A DESIGN

VERIFICATION MANAGEMENT FLOW:

VERIFICATION MANAGEMENT FLOW

VERIFICATION OF VLSI DESIGN SYSTEM (SLFIT) USING QUESTASIM:

VERIFICATION OF VLSI DESIGN SYSTEM (SLFIT) USING QUESTASIM

SLFIT (SAFETY LOGIC WITH FINE IMPULSE TEST):

SLFIT (SAFETY LOGIC WITH FINE IMPULSE TEST)

METHOD CHOSEN TO VERIFY THE SYSTEM:

METHOD CHOSEN TO VERIFY THE SYSTEM

SAFETY LOGIC BLOCK:

SAFETY LOGIC BLOCK

TIMER MODULE:

TIMER MODULE Check for the SCRAM condition of the input signals Ga and Gb . sequence sa_check ; @( posedge clk ) ! Ga ##1 $stable(! Ga )[*5:$]; endsequence:sa_check property pa_check ; @( posedge clk )disable iff (!mode) sa_check |=>! timer_o ; endproperty:pa_check assert_pa_check:assert property( pa_check ); cover_pa_check:cover property( pa_check ); If the inputs or the test input is greater than 50 ms, the output must be latched and must be latched until reset is given. property preset_function ; @( posedge clk )disable iff ( timer_o ==1) $fell( timer_o )|->! timer_o [*1:$] ##1 $rose(reset); endproperty assert_preset_function:assert property( preset_function ); cover_preset_function:cover property( preset_function );

QUESTASIM REPORT IN GUI:

QUESTASIM REPORT IN GUI

QUESTASIM COVERAGE REPORT:

QUESTASIM COVERAGE REPORT

2/3 LOGIC:

2/3 LOGIC

SAFETY LOGIC MODULE:

SAFETY LOGIC MODULE If MI is ‘1’ then, all DND parameters’ 2/3 outputs must be ‘1’ and hence timer output must be ‘1’. MI|->(DND1 ##0 DND3  ##0   DND5  ##0   DND7 ) |-> Ga_or |-> timer_o ; MI|->(DND2  ##0  DND4  ##0  DND6  ##0  DND8) |-> Gb_or |-> timer_o ;

ADDRESS SEQUENCE VERIFICATION:

ADDRESS SEQUENCE VERIFICATION The parameter addresses must be generated according to the interlock signals. Load_state = {LogN2IL, LogP1IL, LinP1IL, RPSBIL} If load_state =0100, then LinP , LinPv , DND1 to DND8, LogP , ԏ p signals’ address must alone be generated. Property addr_seq ; @( clk_fsm ) ( load_state ==0100) |->( LinP ##1 LinPv ##1 DND1 ##1 DND2 ##1 DND3 ##1 DND4 ##1 DND5 ##1 DND6 ##1 DND7 ##1 DND8 ##1 LogP ##1 ԏ p) |=> $rose( addr_count_rst ); endproperty Assert_addr_seq : assert property( addr_seq );

FINE IMPULSE TEST BLOCK:

FINE IMPULSE TEST BLOCK

FINE IMPULSE TEST MODULE:

FINE IMPULSE TEST MODULE Safe fault : disable iff ( Ga_or ==1 && group==GB) ! Ga_or |->! safe_fault_op_Ga |-> safe_fault_op_Ga [*1:$]); New Unsafe fault: disable iff ( profile_il ==1 && group== Gb ) ($fell( unsafe_fault_op_Ga ) &$past( unsafe_fault_op_Ga )==1) |-> ( new_unsafe _ fault_op_Ga ==1) ; Ga_or |->! new_unsafe_fault_op_Ga ==0;

Summary :

Summary Improved communication between Hardware Design and Verification teams. Easy to learn since design and verification are integrated. Less coding with advanced constructs and hence earlier bug detection. Provides easier view of the coverage metrics of the DUT to the verification engineer.

References:

References System Verilog LRM 3.1 System Verilog Assertions Handbook by BenCohen www.testbench.in CummingsDesignCon2005_SystemVerilog_ImplicitPorts. SV_Symposium_2003 pdf sva_gate_paper_dvcon2006

Thank You:

Thank You