Testbench Linter: Automated Rule Checker Framework for Testbenches

TM

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t

he Energy Efficient Solutions logo, mobileGT, PowerQUICC, QorIQ, StarCore and Symphony

are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack,

ColdFire+, CoreNet, Flexis, Kinetis, MXC, Platform in a Package, Processor Expert, QorIQ

Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks

of Freescale Semiconductor, Inc. All other product or service names are the property

of their respective owners. © 2011 Freescale Semiconductor, Inc.

• Intelligent checking tool for Testbenches

written in SystemVerilog and Verilog

• Perform checks on Testbenches prior to

simulation

• Identify the mistakes which are otherwise hard

TM

Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, the Energy Efficient Solutions logo, mobileGT, PowerQUICC, QorIQ, StarCore

and Symphony are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, ColdFire+, CoreNet, Flexis, Kinetis, MXC, Platform in a

Package, Processor Expert, QorIQ Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks of Freescale Semiconductor, Inc.

All other product or service names are the property of their respective owners. © 2011 Freescale Semiconductor, Inc.

2

• Identify the mistakes which are otherwise hard

to detect

• Written in Perl

• A Rich repository of Universal Verification

Methodology and SystemVerilog guidelines

class slave_address_map_info extends uvm_object;

bit [1:0] i;

function new(string name =

"slave_address_map_info");

super.new(name);

for(i = 0; i<8; i++)

begin

... ....

Violation 1

TM





3

... ....

end

endfunction

function void print();

`uvm_info(“ID”,”PRINT FUNCTION”,UVM_MEDIUM)

endfunction

uvm_object_utils_begin(slave_address_map_info);

Violation3

Violation 2

TM





4

• Developed in a generic form where rules can be updated

without updating the script

• New rules can be added for custom checks according to the

prescribed format of the input rule file.

• Ability to generate the entire hierarchy tree

• Built in repository of rules written in accordance with UVM and

SV guidelines

TM





5

SV guidelines

• Checks layered on different levels of severity such as error,

warning and informative

TM





6

• Testbench Linter provides a thorough static analysis of source

code

• The rules fall into four major categories:

− Category1: Global Rule Checks

− Category2: Scope Limited Rule Checks

− Category3: Mixed Scope Rule Checks

TM





7

− Category4: Hierarchical Rule Checks

• Rules that are checked globally.

• No constraints of scope.

• Single line checks not limited to a particular scope.

• Not dependent on the variables and objects declared within

different scopes.

TM





8

“uvm macros represent text

substitutions, not statements, so they

should not be terminated with semi-

colons”

• Rules that are limited to a particular scope.

• Scope specific rules.

• Scope can be class, module, function, task and program etc.

“The implementation of do_pack must

TM





9

“The implementation of do_pack must

call super.do_pack”

• Defines the mixed scope rules

• Checked by storing the variable names, sizes and other details.

• Checks for the rules in which dependency is there.

• Checked within different scopes.

TM





10

““Avoid the assignment of 4 State

variables to 2 State variables”

• Defines the hierarchical rules.

• Rules that require complete hierarchy of the Testbench.

“All the function declared static must

be called as- class name (in which

TM





11

be called as- class name (in which

function is declared):: function name”

• Save precious amount of verification cycle time.

• Ease of removal of coding violations.

• A step towards automation of Proving Testbenches

TM





12

Testbenches

TM





13

• Auto-correctness can be added to the Testbench

Linter for certain violations.

• User will not have to work on correcting the

Testbench code manually.

• By reviewing the log file user can determine the

TM





14

violation to be corrected.

• Providing the rule id(s) script shall correct the

Testbench.

Q & A

TM





15

Q & A

Technology

Testbench Linter: Automated Rule Checker Framework for Testbenches