EZCheck - Static Analyzer

              
Overview     Use Model      User Customization     GUI Shots

Overview

Using high-level languages for verification is a popular and particularly efficient methodology to reduce verification time. The use of a high-level language for hardware verification is similar to the widespread use of a hardware description language (HDL) for hardware design. Consequently, high-level design verification engineers face the same problems and challenges as their counterparts in hardware design. Linting is a widely accepted technology used by hardware designers. Designers routinely depend on linters to detect simulation/synthesis mismatch, combinational feedback and latch inference problems in HDL designs. EZCheck applies lint methodology to OpenVera and SystemVerilog Hardware Verification Language (HVL) designs.

EZCheck can detect problems such as erroneous usage of concurrency constructs, missing function output assignments, thread-dependent code, and several other serious errors that are not normally uncovered without several hours of debugging. In addition to identifying errors in HVL code, EZCheck is invaluable in allowing companies to design and enforce a coding standard for HVL modules. It consists of 325+ rules that user may use to require a certain coding style, enforce a design-wide naming policy and/or restrict usage of certain constructs. A subset of rules can be assimilated into a “ruleset”, enhancing modularity and enabling the use of different rulesets for different applications.

Use model

The input to EZCheck is one or more HVL modules along with one or more rulesets. The output is a list of violations that pinpoints areas in the input that are not consistent with the required rulesets.

EZCheck comes standard with over 325+ predefined rules. Predefined rules may be classified into 4 broad categories:

• Verification errors: Rules in this category detect errors in HVL code that are not detected by a standard compiler. Examples include incomplete (or missing) assignments to function outputs, incomplete case statements and incorrect class constructs and hierarchy.
• Language rules: Rules in this category allow users to restrict or disallow the usage of certain language constructs. This feature is significant because a) some language constructs are more error-prone than others and b) downstream tools used in the verification flow may not be able to handle certain constructs.
• Naming rules: Rules in this category allow users to establish a module-wide naming policy. Consistent naming schemes will result in manageable and reusable HVL components. For example, enumeration item names can require the enumeration declaration name as a prefix to prevent clashes in the design namespace.
• Usage rules: Rules in this category enable the creation of consistent, reusable and easily maintainable code. For example, rules to encourage consistent class design are especially useful for engineers who come from a hardware background.
   

Pre-packaged rulesets

EZCheck comes standard over half a dozen pre-packaged rulesets: Verification Errors, Coverage,  Best Practices,  SystemVerilog Portability, SystemVerilog guidance, SVA best practices, and Reference Verification Methodology (RVM).

EZDesignLint: RTL Lint ruleset: The RTL errors ruleset is a collection of predefined rules that checks for typical lint errors. Examples of errors detected by this ruleset include:

• Unintentional latches
• Multiply driven signals
• Missing signals in sensitivity list
• Race conditions
• Value truncation

EZLint: Verification Errors ruleset: The Verification Errors ruleset is a collection of predefined rules that warns the user of critical errors in the design. Examples of errors detected by this ruleset include:

• Incomplete assignments to function outputs
• Common mistakes in use of concurrency constructs, missing timeouts
• Thread dependent code
• Multiply-driven/undriven signals
• Use of X or Z in relational, arithmetic and case operations

EZCoverage: Functional Coverage ruleset: The functional coverage ruleset is a collection of predefined rules that checks coverage models for best practices. Example checks in this ruleset are as follows:

• Explicit coverage_goal (defaults to 90)
• Incorrect "sensitivity list" for crosses
• User bins for enum-type coverpoint/samples
• Missing not_state bin (catch_all) in user bin specification

EZPort: SystemVerilog Portability ruleset (OpenVera only): The SystemVerilog Portability ruleset is a collection of rules that checks for OpenVera constructs that may NOT port easily to the SystemVerilog language. This ruleset is invaluable to companies who wish to adopt SystemVerilog in the future, but will be using OpenVera for implementation of current verification projects - this is true verification reuse! Examples of checks in this ruleset include:

• Keywords that may be used as identifiers in OpenVera (e.g. always_ff)
• SystemVerilog-incompatible usage of concurrency constructs (semaphore / mailbox usage)
• Usage of constructs that have no equivalent in SystemVerilog (e.g. regions, shadow variables)
• OpenVera system tasks and functions that have no equivalent (e.g. suspend_thread)

Best Practices ruleset: The Best Practices ruleset is a collection of predefined rules that allows the user to follow certain policies that will result in maintainable, readable and reusable code. In addition to rules from the Basic ruleset, it also includes several rules to enhance maintainability. Examples of rules in this ruleset are as follows:

• Naming requirements for files, interfaces and programs
• Disallowing/requiring optional arguments in subroutines
• Disallowing global subroutines and variables
• Limiting levels of class hierarchy
• Requiring/disallowing skew for all interface outputs and inputs

EZVMM: RVM (Reference Verification Methodology) Compliance ruleset: The Reference Verification Methodology ruleset is a collection of rules from the Verification Methodology Manual (VMM), a popular book authored by recognized industry leaders, Synopsys and ARM. EZCheck can automatically check for a subset of rules from the VMM. Examples of rules in this ruleset are as follows:

• Non-blocking functions (OpenVera only)
• Naming requirements for files, tasks and functions
• Requirements for classes inheriting from VMM data class
• Subset of requirements for classes inheriting from various VMM classes (Transaction, Stimulus etc.)

EZAssert: Assertions ruleset (SystemVerilog only): This ruleset is a collection of predefined rules that allows the user to check for assertions quality in SystemVerilog code. Sample checks are as follows:

• Incorrect “eventuality” operator usage
• Non-synthesizable operator usage
• Implication in negated property
• $past() with large delays, ‘0’ in delay operators

EZGuide: SystemVerilog Guidance ruleset (SystemVerilog only): This ruleset is a collection of rules that allows Verilog-95 and Verilog-2001 users to quickly adopt SystemVerilog constructs. Predefined rules in this ruleset analyze users code and suggest SystemVerilog constructs or attributes that can be inserted. By writing SystemVerilog design and verification code, engineers can get better results from other tools in the design and verification flow. Sample checks are as follows:

• Using new constructs always_comb, always_ff, always_latch, always_* whenever possible
• Adopting new timeunit construct for consistency
• Using enumerations in place of parameters and pragmas for Finite State Machine design
• Qualifying branch statements with 'unique' or 'priority'
• Using SystemVerilog-compliant identifiers

EZOVM: Open Verification Methodology Rulechecks (SystemVerilog only): This ruleset can enable productivity for OVM-based teams by checking for errors in OVM usage and providing an easy mechanism to understand and apply the hierarchy present in OVM-based projects. OVM rules can check for inconsistencies in:

• Object Design
• OVM Best Practices
• Connectivity
• Verification Environment

EZ1800: SystemVerilog 1800 Compliance and Simulator Portability: The EZ1800 ruleset checks for compliance with the IEEE 1800 standard and for issues that can cause SystemVerilog code to not compile and simulate on all simulator platforms.

The SystemVerilog Portability module addresses a critical issue in today’s SystemVerilog environments. In part due to its status as an active and emerging standard, the SystemVerilog language is not supported consistently across synthesis and simulation platforms. This makes development of portable SystemVerilog modules impossible. The SystemVerilog Portability module’s 30+ checks keep the user informed about current requirements for writing portable and 1800-compliant SystemVerilog modules. Some sample checks are listed below:

• Mismatched class prototype and body description
• Function return value requirements
• Detection of non-standard SystemVerilog 3.1a constructs

User customization

EZCheck is highly customizable, allowing several levels of customization.

1. Input: EZCheck has an intuitive input interface that is highly configurable. Users may run the design through multiple rulesets at the same time. Individual rules may be disabled from the command line. In addition, the files to be read in may be provided in an input file (similar to the popular .f file format in Verilog).
2. Rule customization: Every rule in the tool may be customized; for e.g., the rule that disallows certain types of declarations in an HVL design can be used to disallow bit/reg declarations in one ruleset and integer declarations in another. Or, the maximum levels of class hierarchy can be set to 3 in one ruleset and 5 in another.
3. User-defined rules: The advanced user can use EZApi to create new rules. These rules can be used in rulesets just like predefined rules.
4. Custom rulesets: The user may create an infinite number of rulesets by combining any number of predefined and user-defined rules.
5. Custom Rules: The user may create any number of new rules using the Application Programming Interface provided by the tool.

BENEFITS

Detect design and verification errors