VC SpyGlass Lint UserGuide

VC SpyGlass Lint®
User Guide
Version P-2019.06-SP2, December 2019
Copyright Notice and Proprietary Information
© 2019 Synopsys, Inc. All rights reserved. This Synopsys software and all associated documentation are proprietary to
Synopsys, Inc. and may only be used pursuant to the terms and conditions of a written license agreement with Synopsys,
Inc. All other use, reproduction, modification, or distribution of the Synopsys software or the associated documentation is
strictly prohibited.
Destination Control Statement
All technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure
to nationals of other countries contrary to United States law is prohibited. It is the reader's responsibility to determine the
applicable regulations and to comply with them.
Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH
REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth at
http://www.synopsys.com/company/legal/trademarks-brands.html.
All other product or company names may be trademarks of their respective owners.
Free and Open-Source Software Licensing Notices
If applicable, Free and Open-Source Software (FOSS) licensing notices are available in the product installation.
Third-Party Links
Any links to third-party websites included in this document are for your convenience only. Synopsys does not endorse and is
not responsible for such websites and their practices, including privacy practices, availability, and content.
www.synopsys.com
VC Lint User Guide Contents
Contents
ChapterContents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Chapter
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
v About this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Contents of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 1
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Invoking VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1 VC SpyGlass Lint Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 SpyGlass Lint Use Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.3 VC SpyGlass Lint Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.4 General output files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 2
Migrating from SpyGlass Lint to VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Converting the .lib Files to the .db Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Reading the Project Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Reading Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Using Tags and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Working with SGDC Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Working with Violation Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Convert SpyGlass Waivers to VC SpyGlass Lint Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 3
Working with Methodologies and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Development Phases and Methodologies: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1 Development Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 Development phases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 RTL Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 RTL Handoff with block level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 RTL Handoff with SoC level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Netlist Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Netlist Handoff on block level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Netlist Handoff on SoC level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Layout Handoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Understanding GuideWare Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Synopsys, Inc. Feedback v

Contents VC Lint User Guide
3.7 Setting Up Methodology/Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8 Running Custom Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Invoking VC Spyglass Lint Using SpyGlass Project File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Chapter 4
Using VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Invoking VC SpyGlass Lint in Tcl Shell Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Sourcing a Tcl Script in VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Building a Design File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Building a Design Using Analyze and Elaborate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2 Building a Design With read_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Using Built-in Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Running Lint Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 Reporting Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.7 Language Check Early Shifting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Multiprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Using Waivers in VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.9.1 Native VC SpyGlass Lint Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 5
Using Tags in VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 About VC SpyGlass Lint tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Creating the Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3 Configuring Tag Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Using Black Boxes in VC SpyGlass Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Chapter 6
VC SpyGlass Lint Tcl Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 check_hdl_lib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Chapter 7
Getting Started with GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1 Invoking and Running Lint Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2 Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Analyzing the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.4 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.4.1 Creating a Filter for a Set of Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.4.2 Creating a Filter From a single Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.4.3 Creating an Exclusive Subsets for Filtered Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.5 Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.5.1 Using Multiple Waiver Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.5.2 Specifying the Waiver File While Creating Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.5.3 Removing Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.5.4 Editing Waivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.5.5 Creating Waivers Data View Spreadsheet and Information View . . . . . . . . . . . . . . . . . . . . . . . . 57
7.6 Pivot Tables to filter Violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.6.1 Creating A Pivot Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.6.2 Results of a Pivot Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.6.3 Cross-probing from Pivot Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.6.4 Creating Multiple Pivot tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.7 Exporting Violation Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
vi Feedback Synopsys, Inc.

VC Lint User Guide Introduction
Introduction
This chapter provides an overview of VC SpyGlass Lint and includes the following sections:
❖ “About this Guide” on page 7
❖ “Contents of this Manual” on page 7
About this Guide

The VC SpyGlass Lint User Guide describes the concepts, features, usage, and tags of VC SpyGlass Lint,
which enable you to use the Verilog or SystemVerilog designs against various coding standards and design
tags.
Contents of this Manual

The VC SpyGlass Lint User Guide consists of the following sections:
Section Description
Getting Started Provides an overview of VC SpyGlass Lint
Migrating from SpyGlass Lint to VC SpyGlass Provides information on migrating from SpyGlass Lint to VC
Lint SpyGlass Lint
Working with Methodology and Goals Provides information on using methodologies and goals
Using VC SpyGlass Lint Provides reference information for the built-in Tcl commands
implemented in VC SpyGlass Lint
Using tags in VC SpyGlass Lint Provides detailed procedures for how to configure and use the
prepackaged tags to check your HDL code
VC SpyGlass Lint Tcl Variables Explains the setup required to run VC SpyGlass Lint
Getting Started With GUI Describes using VC SpyGlass Lint in the GUI mode
Synopsys, Inc. Feedback 7

Introduction VC Lint User Guide
8 Feedback Synopsys, Inc.

VC Lint User Guide Getting Started
1
Getting Started
The VC Static Platform provides comprehensive high-performance and high capacity static verification
solutions for functional verification. Formal and static functional verification solutions may be used very
early in the design process and do not require complex setups, testbenches. Formal property checking needs
properties or assertions to be developed by the user. Formal mathematical techniques are used to test
properties or assertions to ensure correct operations of RTL designs. Static checking techniques analyze
design intent and structures to check conformance to specified intent and behaviors.
VC SpyGlass Lint is based on native VC platform, which provides enhanced performance and capacity. The
efficient framework of VC SpyGlass Lint is low noise and provides enhanced consistency.
This chapter provides an overview of VC SpyGlass Lint and includes the following sections:
❖ “Introduction”
❖ “Features”
❖ “Invoking VC SpyGlass Lint”
1.1 Introduction
VC SpyGlass Lint is a system-to-netlist checker tool that comes with prepackaged tags to check Verilog or
SystemVerilog designs against various coding standards and design tags.
After you elaborate your design in the VC SpyGlass Lint environment, you can use the built-in Tcl shell and
a set of predefined procedures to run interactive queries on your design. With full support for Verilog 2001
and IEEE Std 1800-2005 SystemVerilog design constructs, combined with extensive RTL and netlist checks,
VC SpyGlass Lint can check your designs for errors that may cause problems in the downstream simulation,
synthesis, and equivalence checking flows.The best way to learn the tool is to test one of your designs with
the Checker and the prepackaged policies (sets of tags). The prepackaged tags are designed to meet the best
coding guidelines and practices followed in the industry.
VC SpyGlass Lint is a design checker tool that comes with a rich set of prepackaged tags to check Verilog
and SystemVerilog designs against various coding standards and design tags.
You use the Checker to designate Verilog or SystemVerilog input files that you want to compare against
coding tags that you select with the click of a mouse. The Checker analyzes your Verilog and SystemVerilog
source code against the selected tags and generates a report indicating which lines in the code violate the
tags. You can then:
❖ Open the report in the GUI and debug the reported violations.

Getting Started VC Lint User Guide
❖ Generate schematics to debug structural checks.

❖ Navigate directly from the violation message in the GUI to its source code in your HDL files.
❖ Create filters and waivers for better report management
There are two general types of checks VC SpyGlass Lint performs, as shown in the following table:
Table 1-1 Types of Rules
Rule Type Description
Structural Rules Checks performed on the hardware inferred by the tool (Rules running on Netlist)
Language Rules Checks performed on the HDL language construct (Rules running on RTL code)
1.2 Features
VC SpyGlass Lint provides the following capabilities:
❖ Improved total runtime and PEAK memory.
❖ Unified compilation.
❖ Management of large memories and does not require options to handle large memories during
synthesis.
❖ Word-level traversal and avoidance of bit level traversal (if needed).
❖ Consistent handling of clocks and resets.
❖ Multi-message and multi-line support.
❖ Tag-specific reports.
❖ Noise reduction using the allviol parameter.
❖ V2k language support.
❖ VHDL2008 support
❖ Complete IEEE 1800-2005 System Verilog design constructs.
❖ Saving and restoring elaborated design view.
1.3 Invoking VC SpyGlass Lint

You can invoke VC SpyGlass Lint using one of the following two use models:
❖ “VC SpyGlass Lint Use Model”
❖ “SpyGlass Lint Use Model”
This section also explains the following topics:
❖ “VC SpyGlass Lint Commands”
❖ “General output files”

VC Lint User Guide Getting Started
1.3.1 VC SpyGlass Lint Use Model

Conventional VC Spyglass Lint platform provides VC-specific commands, such as, set app_var, analyze and
elaborate, check_lint, and report_lint. You can specify all these commands in a Tcl file, which is then
specified as an input to VC SpyGlass Lint.
The VC SpyGlass Lint Use Model consists of the following steps:
❖ Reading Tcl File
❖ Analyze and elaborate
❖ check_lint
❖ report_lint
However, the preferred way of invoking VC Spyglass Lint is the SGUM.
1.3.2 SpyGlass Lint Use Model

This is the recommended use model to run VC Spyglass Lint.
This use model uses conventional SpyGlass setup, including project files, constraints, waivers and
command line.
In SpyGlass Lint, you need to only use the sg_read_project command with a SpyGlass Project file, instead of
performing all the steps of VC SpyGlass Lint Use Mode (listed in“VC SpyGlass Lint Use Model”).
The violation messages and all the major reports are generated in SpyGlass format only.
However, for the Structural check (Checks on Netlist), VC SpyGlass Lint uses VC platform only. Therefore,
you may notice some differences due to the fact that the two tools are using two synthesis engines where VC
platform shows better performance.
To match the violation among conventional Spyglass and VC Spyglass Lint, use the utility Lint Comparison
Script utility.
1.3.3 VC SpyGlass Lint Commands

This user guide focuses on the basic operations of the VC SpyGlass Lint application only. Information on
how to invoke the vc_static_shell, GUI and usage of common commands across the platform is described in
the VC Static Platform User Guide.
For ease of access, a few commands are listed here:
❖ To run VC SpyGlass Lint, set the environment variable $VC_STATIC_HOME as follows:
setenv VC_STATIC_HOME <installation_directory>
set path = ($VC_STATIC_HOME/bin $path)
❖ vc_static_shell mode:
✦ To start the tool with an interactive shell:
% $VC_STATIC_HOME/bin/vc_static_shell
✦ To start the tool with a command script file:
vc_static_shell > source ip_filename.tcl
✦ To start the tool in the GUI:
vc_static_shell > start_gui
✦ To start the tool in the GUI with command script.

Getting Started VC Lint User Guide
vc_static_shell > source ip_filename.tcl

vc_static_shell > start_gui
✦ To run built-in command shell:
vc_static_shell > exec echo printme
vc_static_shell > exec cat README
✦ Quick help for commands
vc_static_shell > help start_gui
vc_static_shell > help set_app_var
vc_static_shell > help get_app_var
✦ Descriptive help for commands
vc_static_shell > man start_gui
vc_static_shell > man set_app_var
vc_static_shell > man get_app_var
✦ Quit from vc_static_shell mode
vc_static_shell > quit
❖ Command Line mode:
✦ To start the tool with a command script file:
% $VC_STATIC_HOME/bin/vc_static_shell -f ip_filename.tcl
All vc_static_shell commands can be mention in a file and fed as above
✦ To start the tool in the GUI:
% $VC_STATIC_HOME/bin/vc_static_shell -gui
✦ To start the tool in the GUI with command script.
% $VC_STATIC_HOME/bin/vc_static_shell -f ip_filename.tcl -gui
✦ To save the output in a log file:
% $VC_STATIC_HOME/bin/vc_static_shell -f ip_filename.tcl -output_log_file
filename
Default output log file is vcst_session.log
1.3.4 General output files

❖ vcst_session.log : Contains the terminal output of the vc_static_shell run. You can change the
filename by using the above described command-line option.
❖ vcst_command.log : Contains a list of all the commands which were specified using the
vc_static_shell.
❖ vcst_rtdb : Is the run directory.

VC Lint User Guide Migrating from SpyGlass Lint to VC SpyGlass Lint
2
Migrating from SpyGlass Lint to VC SpyGlass
Lint
VC SpyGlass Lint uses VC Static platform to compile/synthesize and elaborate the design netlist. It is
assumed that you have already converted all your SpyGlass library (.lib) files to VC Static database (.db)
format.
VC SpyGlass Lint translates SpyGlass waiver files, *.swl and *.awl files, to the VC SpyGlass Lint Tcl format
and applies it on the specified violations.
The following are the mandatory to migrate from SpyGlass Lint to VC SpyGlass Lint
❖ “Converting the .lib Files to the .db Files”
❖ “Reading the Project Files”
❖ “Reading Reports”
Also, the following topics provide additional information on using the VC SpyGlass Lint:
❖ “Using Tags and Parameters”
❖ “Working with SGDC Constraints”
❖ “Working with Violation Messages”
❖ “Convert SpyGlass Waivers to VC SpyGlass Lint Waivers,”
2.1 Converting the .lib Files to the .db Files

To convert a .lib file to the .db file, use the Synopsys Library Compiler or Synopsys Design Compiler
product. This is mandatory for running VC SpyGlass Lint.
For more, information see SolvNet article 2594331, “Translating .lib file to .db files and using it in SpyGlass”.
2.2 Reading the Project Files

The VC SpyGlass Lint product reads SpyGlass project (*.prj) files and translates it to the VC-Static Tcl file
format. This is mandatory for running VC SpyGlass Lint.
The VC SpyGlass Lint product reports a warning message for the SpyGlass project files that are not
successfully migrated to the VC SpyGlass Lint Tcl file format.
To migrate a SpyGlass project file to the VC SpyGlass Lint Tcl file, use one of the following options:
❖ Use the sg_read_project command as shown below

Migrating from SpyGlass Lint to VC SpyGlass Lint VC Lint User Guide
sg_read_project -project <project_file_name> -goal <goal_name> -tclfile

<tcl_file_name> -run
❖ Use the vc_static_shell to convert and then source the Tcl file:
vc_static_shell > sg_read_project -project <project_file_name> -goal <goal_name>
-tclfile <tcl_file_name>
vc_static_shell > source <tcl_file_name>
This command also has the following arguments:
❖ -tclfile: Specify this option to specify the name of the generated Tcl file.
❖ -run: Specify this option to generate and run the Tcl file.
The following describes a sample .tcl file:
set_app_var language_check_hierarchy_format yes
set_app_var fullname_with_top true
set_app_var hierarchy_delimiter .
sg_read_project -project test.prj -goal test_goal -run
If you do not specify -run option, VC SpyGlass Lint converts the project file to tcl file, but does not run it.
If a location and name to tcl file is not provided with '-tclfile' option, tcl file (internal.tcl) is generated into a
default location.
2.3 Reading Reports

In addition to the standard VC-Static reports and tag-specific reports, VC SpyGlass Lint generates the
following additional general reports:
Table 2-1 General Reports
Report Name Description
moresimple The report lists the details of the violation messages for each tag.
moresimple_turbo The report lists the details of the violation messages for each tag.
in the turbo mode.
Note that the report is generated only for the language rules.
When you specify the set_option turbo yes option in the SpyGlass
project file, VC SpyGlass Lint generates the moresimple_turbo.rpt.
waiver The report lists the waived messages and the respective count.
count The report lists the number of violation messages reported for each
tag.
summary The report displays a summary of message counts by each rule type
along with the severity class and rule short help.
stop_summary This report lists design units and files that are skipped from SpyGlass
checking in the current run.
no_msg_reporting The report displays a list of rules that did not report any violation or
_rules waived during SpyGlass run.
These reports are generated in the .rpt format, which is the default SpyGlass report format.

You can generate these reports using the report_lint TCL proc as shown below:
report_lint -report { <report_type> } -file report_hdl.txt -verbose -limit 0
Where, <report_type> can have one of the following values:
❖ all: Specifying this report generates both Spyglass moresimple.rpt, waiver.rpt, count.rpt, and
report_hdl.txt. The report_hdl.txt is the VC Static report
❖ sg_moresimple: Specifying this option generates only the moresimple.rpt report.
❖ sg_waiver: Specifying this option generates only the waiver.rpt report.
❖ sg_count: Specifying this option generates the count.rpt report.
❖ default: Specifying this option generates VC Static default report.
Also, the report_hdl.txt file is the VC Static report, which reports the same violation in the VC Static format.
2.4 Using Tags and Parameters

In the Tcl file generated (as described in the previous section), a rule configuration file, tclfile_rules.tcl, is
created automatically and sourced. To enable a tag for the specified goals in this file, specify the following
command:
configure_lint_tag -enable -tag <tag_name> [-goal <goal_name>]
To enable a tag for the specified goal, use the following Tcl command:
configure_lint_tag_parameter -tag <tag-name> -parameter <param-name> -value <value> [-
goal <goal name>]
2.5 Working with SGDC Constraints

VC SpyGlass Lint does not support SDC and SGDC files. However, for back compatibility, VC SpyGlass
Lint automatically converts the set_case_analysis SGDC constraint of SpyGlass to the Tcl format in VC
SpyGlass Lint.
2.6 Working with Violation Messages

The format of the violation messages in VC SpyGlass Lint is the same as the format in SpyGlass Lint.
However, VC SpyGlass Lint reads SpyGlass specific waivers, *.swl and *.awl files. It translates the waivers
to VC-Static Tcl file based waivers and applies them on the reported violations.
VC Static uses the sg_read_waiver Tcl proc to convert the SpyGlass waiver file into the .Tcl file format.
Additionally all the message-based waivers are converted to the object-based Tcl filters/waivers.
The following example explains the migration of SpyGlass waivers to the VC Static Tcl file-based waivers:
Consider the contents of the waiver file, waive.swl:
waive -rule "FlopDataConstant" -msg "Data pin D on Flop test_unit/BM/cnt is tiedlow
(connected to VSS)
Now, SpyGlass uses the read_file command to read the waiver commands as shown below:
read_file type waiver waive.swl //SpyGlass waiver command

To convert the above SpyGlass waiver file to the VC Static format, use the sg_read_waiver Tcl proc, as
shown below:
sg_read_waiver file waive.swl //VC Static Tcl procedure to read waivers
When you specify the sg_read_waiver command, the waive.swl file is converted to waive.tcl file with
the following contents:
waive_lint -tag FlopDataConstant -filter { VariableName =~ "test_unit/BM/cnt" AND
NodeName =~ "VSS" }
2.7 Convert SpyGlass Waivers to VC SpyGlass Lint Waivers

To convert SpyGlass waivers to VC SpyGlass Lint waivers, perform the following steps:
1. Convert the SpyGlass waiver file to Tcl file using the prj2tcl conversion. This generates the Tcl file,
which is used by VC SpyGlass Lint for conversion of waivers.
2. Run VC SpyGlass Lint.
3. To convert the SpyGlass waiver file to a Tcl procedure, specify the following command:
sg_read_waiver -file <SpyGlass Waiver SWL file>
The sg_read_waiver Tcl proc is an independent Tcl proc, which can be run standalone.
Example 1
Consider the following example SpyGlass waiver command:
waive -rule AllocExpr -msg "Allocator expression may not be synthesizable"
The following is the corresponding VC SpyGlass Lint waiver command:
waive_lint -tag AllocExpr -add SgWaive2
Example 2
Consider the following tcl.prj file containing the waiver.swl file.
Figure 2-1 SpyGlass Project File

The following is the converted Tcl file with waivers:
Figure 2-2 Generated Tcl File
The following is the report generated after waiver:
Figure 2-3 Generated Reports


VC Lint User Guide Working with Methodologies and Goals
3
Working with Methodologies and Goals
GuideWare is the testing platform to check the functionality of various goals by running them on different
types of designs. The designer keeps modifying and adding goals until the desired coverage is achieved
from these goals.
This section explains the following topics:
❖ “Terminology”
❖ “Development Phases and Methodologies:”
❖ “RTL Handoff”
❖ “Layout Handoff”
❖ “Understanding GuideWare Goals”
❖ “Setting Up Methodology/Goals”
❖ “Running Custom Goals”
❖ “Invoking VC Spyglass Lint Using SpyGlass Project File”
3.1 Terminology
This section defines some commonly used terms that have a specific meaning in the VC SpyGlass
environment.
❖ Rule: In VC SpyGlass environment, a 'Rule' represents the atomic unit of RTL analysis and checking
performed by the VC SpyGlass software. Although a 'Rule' can be configured, it cannot be further
sub-divided to select what analysis is performed.
❖ Violation Message: A violation message (or simply a message) is unit of VC SpyGlass reporting.
When a VC SpyGlass 'rule' detects a design condition not consistent with the rule requirement, it
reports each such occurrence as a (violation) message. In addition to text message, such report
usually contains other supporting data, such as back-reference in RTL source code where such
problem originates, schematic highlight of the problem, detailed tables and graphs (as in power
activity over time), waveform for a formal 'witness' (such as a false path proven to be not a false
path), and so on.

Working with Methodologies and Goals VC Lint User Guide
❖ Parameter: In VC SpyGlass environment, a 'Parameter' is like an option to a rule that dictates the
rule behavior. Parameters are typically used to make the rule do specific or detailed analysis of the
RTL.
❖ Goal: A VC SpyGlass goal is a collection of relevant rules that are grouped together to perform a
specific task. In addition to the rule list, a goal may further configure the rule parameters and
redefine severity labels assigned to these rules. VC SpyGlass software release contains a useful set of
many widely applicable goals. However, a user may fine-tune existing goals or create new goals to
meet their specific design and workflow needs.
❖ methodology: A VC SpyGlass methodology is a set of relevant goals that are grouped together to
achieve a particular design goal. In addition to software, these sub-methodologies contain detailed
documentation to assist customer in understanding specific usage and debug nuances.
❖ Severity: A VC SpyGlass violation message is tagged with an attribute, called severity, which helps
to identify the criticality of reported message, within the context of a goal and sub-methodology
being run. VC SpyGlass supports four main severity classes: FATAL, ERROR, WARNING, and
INFO. A VC SpyGlass rule or goal can define a (severity) text label belonging to one of the above
classes, and attach it to a rule.
❖ Waivers: A VC SpyGlass 'waiver' is a method for user to review a rule (violation) message and flag a
specific occurrence (or set of occurrences) as acceptable in context of their design and workflow. This
is a very important mechanism to flag an apparently non-compliant design scenario as intended and
verified by actual design or verification engineer. In the SoC design workflow, the VC SpyGlass
waivers play a very significant role both in Block regressions and in Block handoff to SoC integration
and implementation teams.
❖ SGDC: SGDC is an abbreviation for 'VC SpyGlass Design Constraints', and is used to capture
additional designer intent of the block/SoC functionality which are not obvious at RTL/netlist.
SGDC is used for capturing a wide variety of design intent, related with clock domain crossing,
power, testability, etc.
❖
3.2 Development Phases and Methodologies:

A VC SpyGlass methodology is a set of relevant goals which represents a sign-off phase of ASIC
development. Methodology includes goals which are arranged with pre-defined parameter.
3.2.1 Development Levels.

Currently we use lint at two major development levels, block level SoC level.
3.2.1.1 Block level Development:

The process of the development of a new RTL goes through progressive RTL refinement starting with
simpler goals that meet the functional requirements, such as functional correctness and simulation and
synthesis readiness of the code. As the RTL code and design constraints mature, the design goals evolve to
performance, testability, and meeting handoff requirements. In this field of use, this design phase
recommends three methodology flow.
3.2.1.2 SoC level Integration and Implementation

During SoC design or a subset of design (sub-system) that has been integrated by using various blocks,
consistency across blocks is required.

This field of use involves checks related to inter-block/inter-IP issues. In addition, it ensures that block
constraints are consistent with SoC constraints. In this field of use, this design phase recommends a four-
stage flows.
3.2.2 Development phases.
3.2.2.1 Initial RTL Development

The initial RTL design goal set contains a set of checks for the stage of the project when the RTL is still in
coding development and may not be functionally complete. The idea is not necessarily to be clean all at once
but provide a starting point for getting to the clean RTL.
The design team faces the following lint related challenges during this stage:
❖ Issues related with correct code capture
❖ Issues related with simulation and synthesis
❖ Issues with basic connectivity
❖ Issues related with basic structure like combinational loops and multiple drivers
3.2.2.2 Initial RTL Development on block level

During this stage, an initial version of the RTL is completed, and an initial set of SGDC constraints are
available. This stage involves basic structural and sanity checks of the design (and constraints, wherever
appropriate). In addition, issues related to connectivity, synthesizability, preliminary clocks, and reset
integrity issues, such as glitches and clock-MUXing are also checked during this stage.
For this stage, methodology recommends a set of goals that can be used by individual RTL designers to
correct the issues within their own desktop environment before simulation and synthesis tasks can begin.
These goals are recommended to be used quite frequently. In some cases, designers use these goals before
checking-in their RTL code. Waivers, if any, should be captured on an ongoing basis.
This stage may involve some micro-architectural changes related with bus widths, RAM/ROM usage, and
clock phase/frequency refinements. It is important to ensure that the proposed micro-architectural changes
are reflected in the RTL without any adverse impact on the implementation issues.
3.3 RTL Handoff

The rtl_handoff goals are a super-set of the initial_rtl goals. This stage contains the complete set of
recommended RTL Handoff checks.
The design team faces the following lint related challenges during this stage:
❖ Issues related with verification regressions and associated bug fixes
❖ Issues related with incomplete handoff
❖ Providing closure on various implementation issues, such as synthesizability, timing, constraints,
clock domain crossings, testability, congestion/routing, and power management
An incomplete handoff results in expensive and unpredictable error-prone iterations during the SoC
integration phase. Handoff is assumed to be the hand-off from the RTL design team to the post-synthesis
implementation team or hand-off to System Integration (sub-system or SoC) integration.

Since the hand-off process is typically iterative, it is not necessarily expected that all goals will be clean at
the first hand-off, but at least the issues will be known and can be communicated to the consumers
downstream.
3.3.1 RTL Handoff with block level

This is the final completion and handoff stage for the RTL. By this stage, it is assumed that the RTL has
already been refined as per the methodology.
Most checks are applicable at this point before backend implementation begins. During this stage, the
micro-architecture and majority of the logic is stable. VC SpyGlass goals are used to perform handoff checks
with appropriate waiver definitions.
At this milestone, the block is expected to be clean and all the necessary inputs are expected to be in place
before you perform the final VC SpyGlass run. It is also expected that the user is able to share the setup,
constraints, waivers, reports, and so on, with the customer.
3.3.2 RTL Handoff with SoC level

During this stage, the SoC/sub-system integration team assembles the RTL blocks and IPs to form a
SoC/sub-system. These RTL blocks are usually designed by different teams. The design teams may also use
third party or legacy IPs.
The goals used during this stage target the following objectives:
❖ Check the complete design intent captured in individual blocks and their assembly
❖ Correct various inter-block issues, such as combinational loops and unconnected ports
❖ During this stage, the intent is to clean the RTL before production level synthesis begins.
3.4 Netlist Handoff

The netlist_handoff goals are designed to check post-synthesis netlist prior to layout. These checks are ideal
for hand-off to the backend physical implementation team or ASIC handoff
3.4.1 Netlist Handoff on block level

This stage when the handoff RTL is synthesized, and netlist is handed off for backend implementation. All
structural checks at RTL hand off are applicable here. In addition, certain ERC checks are appropriate at this
stage. This netlist is used by many groups as a starting point for their tasks (such as floor planning, test
insertion, power estimation, and reduction analysis). VC SpyGlass goals are used to perform handoff checks
with appropriate waiver definitions.
The following table describes recommended Base VC SpyGlass goals for each of the three stages of the new
Block/IP development.
3.4.2 Netlist Handoff on SoC level

This netlist is used by many groups as a starting point for their tasks (such as floor planning, test insertion,
power estimation, and reduction analysis). During this stage, third party tools modify the preliminary

netlist for scan and BIST insertion and power-related gating. This version of netlist is known as pre-layout
netlist by most of the design teams. The goals used
during this stage ensure that the original design intent is not adversely impacted during these
modifications. The goals and sub-methodologies recommended for this stage ensure the integrity of the
complete SoC-level netlist from ERC perspective.
3.5 Layout Handoff

This is only available for SoC level.
During this phase, the SoC post layout netlist is closest to silicon. It is important to ensure final integrity of
this post-layout netlist before tape-out.
Recommended goals allow the designer to ensure integrity of post-layout netlist during the ECOs and
before the final handoff for tape-out.
Goals and Methodologies:
Table 3-1 Goals and Methodologies
Methodology Goals Description
block/initial_rtl lint_rtl This goal performs following checks on block RTL
Basic connectivity issue in the

design, such as floating input,
width mismatch, etc.
simulation issues in the design,
such as incomplete sensitivity list,
incorrect use of block/ nonblocking
assignments, potential
functional errors and possible
simulation hang & simulation race
cases.
unsynthesizable constructs in the
design and code that can cause
RTL vs. gate simulation mismatch.
structural issues in design that
affect the post-implementation
functionality or performance of
the design. Examples include
multiple drivers, high fan-in MUX,
and synchronous/asynchronous
use of resets.
These checks should be run after
every change in RTL code prior to
code-check-in

Table 3-1 Goals and Methodologies
Methodology Goals Description
block/rtl_handoff lint_rtl This is similar to block lint_rtl but applicable only for
netlist_handoff.
soc/initial_rtl lint_rtl This goal performs following checks on SoC RTL
soc/rtl_handoff lint_rtl
• Basic connectivity issue in the design, such as floating
input, width mismatch, etc.
• simulation issues in the design, such as incomplete
sensitivity list, incorrect use of block/ non-blocking
assignments, potential functional errors and possible
simulation hang & simulation race cases.
• unsynthesizable constructs in the design and code that
can cause RTL vs. gate simulation mismatch.
• structural issues in design that affect the post-
implementation functionality or performance of the
design. Examples include multiple drivers, high fan-in
MUX, and synchronous/asynchronous use of resets.
These checks should be run after every
change in RTL code prior to code-check-in.
soc/netlist_handof lint_netlist This is similar to SoC lint_rtl but applicable only for
f netlist_handoff
soc/layout_handof lint_netlist This goal checks basic connectivity issues in the design,
f such as floating input and width mismatch. These checks
should be run after every change.
This goal performs netlist integrity checks such as
connectivity, simulation and structural issues.
This goal must be run when synthesis is complete and after
each major step in SoC implementation ,such as scan-
insertion, and power-gating.
3.6 Understanding GuideWare Goals

A goal is a collection of relevant tags that are grouped together to perform a specific task. In addition to the
tag list, a goal may further configure the tag parameters and redefine severity labels assigned to these tags.
VC SpyGlass Lint contains a useful set of many widely applicable goals. However, you can fine-tune
existing goals or create new goals to meet their specific design and workflow needs.
3.7 Setting Up Methodology/Goals

To view the default methodology and goal, select the expand button for Check Lint panel, as shown in the
following figure:

Figure 3-1 Select Methodology

When you select a methodology in the GuideWare Methodology section, the goals in the Goal section
change accordingly.
When you click on the Check Lint option after you select a methodology and a goal, the corresponding Tcl
commands are run.
For example, in Figure 3-1, the Block/inital_rtl methodology and the lint_rtl goal is selected. Now, when
you click the Check Lint option, the following Tcl commands are run:
#configure_lint_methodology -path
$::env(VC_STATIC_HOME)/auxx/monet/tcl/GuideWare//block/netlist_handoff/lint/ -goal
lint_netlist ; check_lint -goal lint_netlist
The following table lists the supported methodologies in VC SpyGlass Lint and their corresponding goals:
Table 3-2 Goal/Methodology Setup Commands
Command Description
configure_lint_methodology Sets the current methodology.
configure_lint_tag -enable -tag Enables the tag for the respective goal name.
<tag-name> [-goal <goal-
name>]
configure_lint_tag_parameter Configure the parameter for the respective goal name.

-tag <tag-name> -parameter
<param-name> -value
<value> [-goal <goal-name>]

Table 3-2 Goal/Methodology Setup Commands
Command Description
check_lint [-goal <goal- Runs specific goal. If not specified, runs the default goal.
name>]
report_lint [-filter <goal- Reports results for a given goal. Without this option report_lint reports all
name>] available results from every goal which has been executed.
If check_lint command is used without configure_lint_tag command, the lint_rtl GuideWare goal, is
Note executed.
3.8 Running Custom Goals

To run a custom goal, in the Lint Checks dialog, specify a Tcl file, which contains goal details.
The following figure illustrates how to specify the custom goal through the GUI:
Figure 3-2 Custom Goals

Alternatively, you can specify the custom goal in the SpyGlass project file.
Consider the following example, where test_goal is a user-specified goal defined in a SpyGlass project file as
shown below:
define_goal test_goal -policy { lint,openmore,morelint,starc,starc2002,starc2005 } {
set_parameter fullpolicy 1}
3.9 Invoking VC Spyglass Lint Using SpyGlass Project File

To invoke VC Spyglass Lint through conventional Spyglass project file, create a top file containing the
following command:
### [Optional] Setting app_var to Start Language Rules (RTL Rules) checks before
elaboration and netlist creation for performance improvement.
### Spyglass project read and perform Lint checks

sg_read_project -project spyglass.prj -goal test_goal -tclfile tclfile_rules.tcl -run
Alternatively, you can also specify the above commands directly on the vc_static_shell.
In addition, the sg_read_project command converts the conventional SpyGlass project file to VC Use model
Tcl and runs specified lint checks.
In addition to the above specified application variable, you can also use the following application variables
to improve the compatibility for the comparison script:
❖ language_check_hierarchy_format
❖ fullname_with_top
❖ hierarchy_delimiter
For more information on these application variables, see the VC SpyGlass Lint Migration Guide.


VC Lint User Guide Using VC SpyGlass Lint
4
Using VC SpyGlass Lint
This section provides reference information for the built-in Tcl commands implemented in VC SpyGlass
Lint. You can use these Tcl commands to configure tags, manage projects, and control your VC SpyGlass
Lint Checker runs.
This section provides you the information on using Tcl Shell under the following topics:
❖ “Invoking VC SpyGlass Lint in Tcl Shell Mode”
❖ “Sourcing a Tcl Script in VC SpyGlass Lint”
❖ “Building a Design File”
❖ “Using Built-in Tcl Commands”
❖ “Running Lint Checks”
❖ “Reporting Violations”
❖ “Language Check Early Shifting”
❖ “Multiprocessing”
❖ “Using Waivers in VC SpyGlass Lint”
4.1 Invoking VC SpyGlass Lint in Tcl Shell Mode

To run VC SpyGlass Lint, set the environment variable $VC_STATIC_HOME as follows:
setenv VC_STATIC_HOME <installation_directory>
set path = ($VC_STATIC_HOME/bin $path)
4.2 Sourcing a Tcl Script in VC SpyGlass Lint

You can write the run script as a .tcl file, for example, vc_lint.tcl, and then pass this file to the command line
as follows:
$VC_STATIC_HOME/bin/vc_static_shell -f vc_lint.tcl
When running VC SpyGlass Lint Tcl scripts the -restore option is also supported in VC SpyGlass Lint.
4.3 Building a Design File

You can compile and elaborate the RTL design in the following two ways:
❖ “Building a Design Using Analyze and Elaborate”
❖ “Building a Design With read_file”

Using VC SpyGlass Lint VC Lint User Guide
4.3.1 Building a Design Using Analyze and Elaborate

The following Tcl commands shows how you can build an elaborated database in VC SpyGlass Lint using
the analyze and elaborate commands:
set search_path "./DB"
set link_library "GTECH.DB"
analyze -format verilog top.v
elaborate top
VCS mode to read files is also supported. Add the VCS options into the double quote followed by vcs as
follows:
analyze -format verilog –vcs “-f file_list”
elaborate top
4.3.2 Building a Design With read_file

The following Tcl commands shows how you can build an elaborated database in VC SpyGlass Lint using
the read_file command:
read_file -format verilog -top top top.v
This command is generally used for reading netlist design.
VCS mode format:
read_file -format verilog -top top –vcs {-f file_list}
4.4 Using Built-in Tcl Commands

The following built-in Tcl commands are available with VC SpyGlass Lint:
❖ check_lint
❖ configure_lint_tag
❖ configure_lint_tag_parameter
❖ report_lint
❖ waive_lint
4.5 Running Lint Checks

The following Tcl commands shows how you can run both language and structural checks in VC SpyGlass
Lint:
configure_lint_tag -enable –tag <TAG_NAME>
elaborate top
check_lint

4.6 Reporting Violations

The following Tcl commands dumps all the violations into the file report_hdl.txt. If you just want to get the
summary of violations, you can turn off the switch verbose.
By default, report_lint reports up to 100 violations for each tag, if you want to report all the violations,
you can use option –limit 0 in report_lint.
set search_path "./"
set link_library " "
set quick_lint_mode true
configure_lint_tag -enable -tag <TAG_NAME>
elaborate top
check_lint
report_lint -file report_hdl.txt -verbose -limit 0
quit
4.7 Language Check Early Shifting

The Language check Early Shifting feature is used to improve the performance when language check takes
significant time in VC SpyGlass Lint.
With Early shifting feature, VC SpyGlass Lint checks for language rules (RTL checks) before elaboration and
netlist creation.
To enable the Language Check Early Shift feature in VCUM, use the following commands as shown below:
4.8 Multiprocessing
Use the Multiprocessing feature to reduce run time when language check is taking significant time in VC-
Spyglass lint.
The Multiprocessing feature splits the goal into multiple goals and finally merges all the results in the
default VC Spyglass Lint database.
Note that the Multiprocessing feature in language checks is supported only in VCUM.
To enable the Multiprocessing feature, use the following App Var:
set_app_var lint_enable_multi_process true

Also, to set the number of processes, specify the following App Var:
set_app_var lint_number_of_processes <num>
4.9 Using Waivers in VC SpyGlass Lint

VC SpyGlass Lint provides a waiver mechanism that lets you selectively waive-off specific categories of
violations based on your requirement. This functionality is provided with the waive_lint command. Using
this command, you can select the violations to be waived-off based on the stage, family, severity or ID.
VC SpyGlass Lint provides the following waiver mechanisms:
❖ Native VC SpyGlass Lint Waivers
❖ Convert SpyGlass Waivers to VC SpyGlass Lint Waivers
4.9.1 Native VC SpyGlass Lint Waivers

You can add basic waivers to waive any particular rule in VC SpyGlass Lint using the following command:
waive_lint -tag [rule_name] -add [waiver_name]
Example
Consider the following waive command:

The following is the report file generated before applying the waiver:
Figure 4-1 Report Before Waiver

However, the following report is generated after applying the waiver:
Figure 4-2 Report After Waiver


VC Lint User Guide Using Tags in VC SpyGlass Lint
5
Using Tags in VC SpyGlass Lint
This section provides detailed procedures for how to configure and use the prepackaged tags to check your
HDL code under the following topics:
❖ “About VC SpyGlass Lint tags”
❖ “Creating the Configuration File”
❖ “Configuring Tag Parameters”
❖ “Using Black Boxes in VC SpyGlass Lint”
5.1 About VC SpyGlass Lint tags

The VC SpyGlass Lint tool offers a rich set of prepackaged tags. You can select and configure these tags to
ensure that a design strictly follows those tags. A tag is a coding guideline that should be either followed or
avoided strictly.
5.2 Creating the Configuration File

Create the configuration file where you can specify the list of tags that the design has to be checked against.
You can select or deselect a tag based on your requirement.
Use the Tcl command configure_lint_tag to select/deselect a tag. For example,
configure_lint_tag -enable/-disable -tag <TAG_NAME>
5.3 Configuring Tag Parameters

Some of the tags have parameters that provide the capability to either extend or minimize the scope the tag.
All the parameters of such tags have certain default values. If you wish to use the parameter to
extend/reduce the scope of the tag, use the Tcl command configure_lint_tag with the -parameter option
as follows:
configure_lint_tag -enable -tag <TAG_NAME>
configure_lint_tag_parameter -tag <TAG_NAME> parameter <PARAMETER> value <VALUE>
elaborate top
5.4 Using Black Boxes in VC SpyGlass Lint

A black box is either categorized as an automatic black box or a user-defined black box as described below:

Using Tags in VC SpyGlass Lint VC Lint User Guide
❖ A user defined black box is created using the Tcl command set_blackbox. This needs to be done
before using the analyze/read_file commands.
For example, to black-box the module moduleA, use the following command:
set_blackbox -designs {moduleA}
read_file -format verilog -top top top.v
❖ An automatic black box is marked by the tool automatically. To see the designs marked as a black
box, use the following command:
vc_static_shell> get_blackbox -designs
VC SpyGlass Lint issues the following message for each black boxed module instance:
Note-[SM_BB_SKIP] Skipping blackboxed Module/Entity
In a design that contains one or more black boxes, the black boxes are elaborated with the following implicit
hardware:
❖ Each input port of a black box is connected inside the corresponding module entity to one input of
one implicit combinatorial gate (of undefined type).
❖ Each output port of a black box is driven inside the corresponding module by one output of one
implicit combinatorial gate (of undefined type).
❖ Each inout port of a black box has both characteristics above as an input and an output port.
VC SpyGlass Lint does not perform tag checking for black-boxed modules and all modules that are
instantiated in a black-boxed module.

VC Lint User Guide VC SpyGlass Lint Tcl Variables
6
VC SpyGlass Lint Tcl Variables
To use VC SpyGlass Lint, ensure that the environment is set up correctly. You need to set different
environment variables correctly to be able to perform specific tasks using VC SpyGlass Lint.
The check_hdl_lib environment variable in VC SpyGlass Lint enables you to perform tag checking on the
library files passed with -v and -y options. The default value of this variable is false.
6.1 check_hdl_lib
Command Line Example
set search_path "./"
set link_library " "
set synth_preserve_sequential true
set_app_var sync_reset_signal_threshold 0
set_app_var analyze_skip_translate_body true
set_app_var enable_verdi_debug true
set_app_var report_sibling_violation true
compress_hdl -enable
configure_lint_tag enable -tag <TAG_NAME>
analyze -format sverilog -vcs " -f file.list "

elaborate top -verbose
check_hdl_lib -all
check_lint
report_lint -file report_hdl.txt -verbose
quit
For more information on application variables, see Lint Commands section in the VC Static Platform
Command Reference Guide.

VC SpyGlass Lint Tcl Variables VC Lint User Guide

VC Lint User Guide Getting Started with GUI
7
Getting Started with GUI

❖ “Invoking and Running Lint Checks”
❖ “Summary View”
❖ “Analyzing the Results”
❖ “Filters”
❖ “Waivers”
❖ “Pivot Tables to filter Violations”
❖ “Exporting Violation Table”
7.1 Invoking and Running Lint Checks

All tasks that can be performed in the batch mode can be performed in the GUI mode as well. You can
invoke the GUI from vc_static_shell by using the following sequence of commands:
%vc_static_shell
vc_static_shell> start_gui
Alternatively, you can use the following sequence of commands to invoke the GUI:
%vc_static_shell
vc_static_shell> view_activity

Getting Started with GUI VC Lint User Guide
These commands bring up the VCst Activity View window as shown in Figure 7-1.
Figure 7-1 VC Static Activity View

There are two panes available in the GUI at this stage:
❖ The left pane is called the activity tree
❖ The right pane is called the data view
To set up the design using the GUI, click Design Setup in the VC Static (VCst) tree shown in the activity tree.
The data view appears in the right pane displaying all the Tcl files found in the current directory as shown
in Figure 7-2. These Tcl files contain the commands required to set up the design.

Figure 7-2 Data View with Tcl Files

Click the required Tcl file to set up the design. The Tcl file runs and the log can be seen on the
vc_static_shell output.
After the Tcl file run completes successfully, the design read violations are shown in the Design Setup as
shown in Figure 7-3. To stop displaying design read violations, set the following application variable, which
has a default value of 2, to 0.
enable_message_database_migration
Also the activity tree shows the Verification tree element under the VC Static (VCst) tree, below Design Setup
as shown in Figure 7-3.

Figure 7-3 Activity View with Design Set Up

Click Verification in the activity tree to see the data view that displays the checks you can perform on the
design as shown in Figure 7-4.
Figure 7-4 Activity View - Running Lint Checks

Click the Lint Checks: Show Check Controls to see the Check_Lint panel as shown in Figure 7-5.

Figure 7-5 Check Lint
Click Check_Lint to perform Lint related checks. After the successful completion of Check_Lint, Verification
tree elements are displayed as shown in Figure 10-4.
Figure 7-6 Activity View - Running Lint Checks

After the successful completion of Check_Lint the activity tree is populated with the following:
❖ Lint tree element under Verification in the VC Static (VCst) tree.
❖ Error, warning and information tags are flagged.
❖ The number of violations for an error/warning/information is displayed in brackets.
❖ All error/warning/information tags are bucketed into the stages at which they were flagged
❖ The number of violations for each stage is flagged
7.2 Summary View

The Message Summary View displays the summary of the checks run on the design, both with respect to the
stages as well as the severity as shown in Figure 7-7 and Figure 7-8 respectively.
To see the Summary View, click the Lint tree element under Verification in the activity tree.
Figure 7-7 Summary View - Stage Order
Figure 7-8 Summary View - Severity Order
In the flow explained above, tasks, such as setting up the design and performing Lint checks, are
accomplished after invoking the GUI. Alternatively, GUI can be invoked after performing design setup and

Lint checks in the batch mode by using relevant Tcl commands. GUI is populated with the results of already
performance checks.
When start_gui or view_activity commands are invoked, VC SpyGlass Lint internally launches Verdi
in the background for improved performance. To disable launching Verdi in the background, set the
following application variable, which has a default value of true, to false.
enable_verdi_background
Even though this application variable disables launching Verdi, all Verdi related data will be created by
VCst while running the design. To disable this process as well, set the following application variable, which
has a default value of true, to false.
enable_verdi_debug
This application variable takes precedence over the enable_verdi_background application variable.
7.3 Analyzing the Results

You can analyze the results of the Lint-related checks run on a design using the GUI.
1. Click any tag of interest in the VC Static (VCst) tree to see a group of similar tags reported for various
Lint checks by the tool. All similar tags are displayed in the data view of the GUI.
2. Click any tag to analyze the tag in the group as shown in Figure 7-9.
Figure 7-9 Data view - Analyzing Results

The pane that appears in the right bottom is called the information view or detailed view. This is
only available for the Open node and any node below the Open node.
3. Click the More Info…(Help) link in the Information view to understand more about the error and its
resolution.

4. Locators in the schematics are used to see the source and destination points of the domain crossing.
This helps you understand the violation better. Locators are enabled by default. Click the Add
Locator icon on data view Toolbar to disable locators.
5. To see the information view of a violation, select a violation in the VC Static (VCst) tree.
All the required information to understand the error is populated in the information view, as shown
in Figure 7-10.
Figure 7-10 Information View

As shown in Figure 7-11 adjust the locators to clearly observe the violation. The GUI shows color
coded flip-flops for each domain. Flip-flops of the same color belong to a single domain.
By default, the Verdi GUI shows 4 or more gates inside a schematic cloud. Use the
schematic_cloud_gate_threshold application variable to configure the Verdi GUI to show a
reduced number of gates in a schematic cloud.

Figure 7-11 Schematic View
7.4 Filters
Filters are useful in highlighting unknown clock domain crossing violations.
Filters are used to filter out violations from many violations that meet the criteria specified in the filter. This
helps you focus on a group of violations and resolve them quickly.
❖ “Creating a Filter for a Set of Violations”
❖ “Creating a Filter From a single Violation”
❖ “Creating an Exclusive Subsets for Filtered Violations”
7.4.1 Creating a Filter for a Set of Violations

You can create filters by using the Create a Filter for the fields link on the information view as shown in the
following figure:

Figure 7-12 Creating Filters

Click the Create a Filter for the fields option to display the regular filtering screen as shown in Figure 7-13.
Figure 7-13 Select Filters

You can select different fields based on different operators and apply filters.

7.4.2 Creating a Filter From a single Violation

You can create a filter by using a selected violation from data view. To create a filter, perform the following
steps:
1. Select any violation from data view. The information view shows the Create a Filter Template option
as shown in Figure 7-14.
2. Click the Create a Filter Template option to create a filter from the selected violation as shown in
Figure 7-14.
Figure 7-14
7.4.3 Creating an Exclusive Subsets for Filtered Violations

Exclusive subset is the set of unfiltered violations of a tag. When there are filters applied for a tag, the Create
Exclusive Subset feature can be used to filter out the violations which are not included in any of the filters
applied under the tag.
This feature is available only for tags and levels below tags in the activity tree. The feature is enabled only
when there are one or more filters applied. The following options are available to create an exclusive subset:
❖ Activity tree right-click menu command Create Exclusive Subset
❖ Create Exclusive Subset link from the information view

Figure 7-15 Create Exclusive Subset

Once the exclusive subset is created, it is displayed in the activity tree as a new sibling node under the tag as
shown in Figure 7-16. The violation count for the exclusive subset is calculated by subtracting the total
count of filtered violations from the total violation count of the violation tag. The violation count of the
violation tag is also reduced and updated accordingly.
Figure 7-16 Violation Count for Exclusive Subset

Unlike a normal filter, exclusive subset is displayed with a green color.

You can create filters for an exclusive subset, Therefore, it is possible to create an exclusive subset inside an
existing exclusive subset.
7.5 Waivers
Waivers are useful in highlighting unknown clock domain crossing violations.
Waivers are used to waive off tags/violations related to known issues or issues that have already been
analyzed. By introducing waivers, you can keep track of the violations that are yet to be analyzed.
This section covers the following topics:
❖ Using Multiple Waiver Files
❖ Specifying the Waiver File While Creating Waivers
❖ Removing Waivers
❖ Editing Waivers
❖ Creating Waivers Data View Spreadsheet and Information View
7.5.1 Using Multiple Waiver Files

VCst GUI supports multiple waiver files. This enables you to maintain more than one waiver file. You can
set one of them as the default waiver file where the newly created waivers are included by default.
You can add multiple waiver files using GUI or Tcl commands (see the Setting Waiver Files and Default
Waiver File using Tcl Commands section).
There are two options to set waiver file in GUI:
❖ Using the Set Default Waiver File Option
❖ Using the Add New Waiver File Option
7.5.1.1 Using the Set Default Waiver File Option

To set default waiver file, perform the following steps:
1. Right click on activity tree > Set Default Waiver File.
If there are no existing waiver files, a pop-up menu, as shown in the following figure, appears:

The following popup menu appears when waiver files are already present, and one of them is
selected as 'default'.
As displayed, the popup menu shows the check mark corresponding to the current selected default
waiver file. To change the default waiver file, right click on the activity tree, click > Set Default Waiver
File, and select another file name. The check mark is updated to the selected file and the setting is
applied.
2. Click the Add waiver file option to add a waiver file.
The Enter/Choose a Waiver File Name dialog box appears.
You can choose an existing waiver file from the list of available waiver files. If you want to create a
new waiver file, type a new name (such as, new_waiver.tcl) in the File name box.

Figure 7-17 Chose a Waiver File Name

The Set this as Default Waiver File option is selected by default. This option sets the selected file as the
default waiver file.
7.5.1.2 Using the Add New Waiver File Option

To set the waiver file, perform the following steps:
1. Right click on activity tree > Add New Waiver File.

The Enter/Choose a Waiver File Name dialog box appears. See Step 2 for details.
7.5.1.2.1 Setting Waiver Files and Default Waiver File using Tcl Commands
Use the manage_waiver_file command to manage file-based waivers. This command enables you to add
waiver files while performing VC runs.
Syntax
%vc_static_shell> manage_waiver_file -help
Usage: manage_waiver_file Read waivers from a file
-add (Add waiver file)
<file_name> (Waiver file name)
Note
An error is issued if the file does not exist or is not readable.
You must set the default_waiver_file application variable to set a file as the default waiver file.
Example
Adding the following commands in the Tcl script adds three files, and sets new1.tcl as default waiver file:
manage_waiver_file -add waiver2.tcl
manage_waiver_file -add waiver4.tcl
manage_waiver_file -add new1.tcl
set_app_var default_waiver_file new1.tcl
7.5.2 Specifying the Waiver File While Creating Waivers

You can also select the waiver file while creating waivers. For most waiver creation flows (for example,
Create a waiver or create a waiver based on existing filter), the following waiver setup page is displayed. The
Waiver File drop-down list is added for such cases.

Select the default waiver file name from the Waiver File list to change the default waiver file name. If any file
is not selected from the Waiver File list, waiver is added to the waiver file that is set as the default waiver
file.
The Waiver File list also shows Add waiver option. You can use the Add Waiver option to set additional file
directly without going to the activity tree right-click menu.
The following messages are reported if you have not set up any waiver file and try to add waivers in the UI:
❖ If you are using one-click waiver (Waive this Item), the Enter/Choose a Waiver File Name dialog box
appears to select a waiver file. Closing this dialog generates the following error message:
❖ If you are using the two-click waiver creation (example, 'Create a waiver'), or when you create a
filter and then generate a waiver based on that filter, the waiver setup page comes up without any
waiver files in the corresponding 'Waiver File' drop-down list. If you continue to create waiver by
selecting the ADD Waiver option, the error message as shown in the following figure appears.

7.5.3 Removing Waivers

To remove a loaded waiver, perform the following steps:
1. Click activity tree right-click menu command > Remove Waiver File as shown in the following figure.
A dialog box appears showing all the existing loaded waiver files.
2. The Remove Waiver Files dialog box appears showing all the existing loaded waiver files as shown in
the following figure.
3. Select the check box corresponding to the file/files to be removed and click the Remove button to
remove waiver files.

7.5.4 Editing Waivers

To edit a waiver, use the Edit this Waiver option in Waiver Control Console as shown in the following figure.
When you click the Edit this Waiver option, the regular waiver setup page appears as shown in the following
figure. You can select fields from the table.
The fields are populated from the existing waiver file. The non-existing fields in the selected waiver are
disabled and have "*" as the Match value. You can specify the match value to waive specific message sets.
After editing, click the ADD Waiver option to overwrite the existing waiver file.
7.5.5 Creating Waivers Data View Spreadsheet and Information View

The following options are available in right-click menu of the data view spreadsheet and in the information
view.

To create waivers, right-click on the data view spreadsheet to show the popup menu that has the Waive this
Item and the Create a Waiver items. You can start creating the waiver from either of the data view
spreadsheet or the links on the information view as highlighted in the above figure.
7.6 Pivot Tables to filter Violations

Pivot table is quite useful in generating meaningful information from a large-scale data set. This can be
considered as an extended support for filtering.
❖ “Creating A Pivot Table”
❖ “Results of a Pivot Table”
❖ “Cross-probing from Pivot Table”
❖ “Creating Multiple Pivot tables”
7.6.1 Creating A Pivot Table

You can select a combination of fields (visible in the data view also) of the considered set of violations to
create a pivot table.
A pivot table can be created using the activity tree right-click command Create a Pivot Table as shown in
following figure. This option is available for tags and higher-level activity nodes, up to the Open node of the
Activity Tree.

This command opens Configure Pivot Table dialog appears with the respective available Fields List as shown
in the following figure.
Check one or two fields to add them as Pivot rows and click the Add button corresponding to Rows list box.
Check another item from the Fields List and click the Add button corresponding to Columns list box to add it
as a Pivot column (not mandatory). Click the OK button to create the pivot table.
7.6.2 Results of a Pivot Table

The following figure shows a pivot table.

The first and Second column represents the two selected 'Row' fields (Only first column if one row field is
selected) and the values will be combination of rows. If 'Column' field is selected, the corresponding unique
values of that field will show as each additional column with violation message counts.
The last column shows the total counts of the row (If no column field selected, then it will be count of row
combinations)
7.6.3 Cross-probing from Pivot Table

Selecting a non-zero cell on a row will update the data view and shows the corresponding violation
messages matching to the count as displayed in the pivot table, as shown in following figure.

7.6.4 Creating Multiple Pivot tables

You can create multiple pivot tables by going back to any desired Activity Tree node and use the same
procedure to create another pivot table. User can give a different name to the pivot table in the Pivot table
Configuration dialog. The new pivot table will be opened in a new tab in the already opened Pivot Table
display dialog.
7.7 Exporting Violation Table

You can export the violation table displayed in the data view by using Export Table for this Set of Violations
link in the information view. A snapshot of the currently displayed set of violations in the data view is saved
as a CSV file.


VC SpyGlass Lint UserGuide

Uploaded by

Copyright:

Available Formats

You might also like

VC SpyGlass Lint UserGuide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VC SpyGlass Lint UserGuide

Uploaded by

Copyright:

Available Formats

VC SpyGlass Lint®

Synopsys, Inc. Feedback v

3.7 Setting Up Methodology/Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

vi Feedback Synopsys, Inc.

About this Guide

Contents of this Manual

Getting Started Provides an overview of VC SpyGlass Lint

Synopsys, Inc. Feedback 7

8 Feedback Synopsys, Inc.

Synopsys, Inc. Feedback 9

❖ Generate schematics to debug structural checks.

Rule Type Description

1.3 Invoking VC SpyGlass Lint

10 Feedback Synopsys, Inc.

1.3.1 VC SpyGlass Lint Use Model

1.3.2 SpyGlass Lint Use Model

1.3.3 VC SpyGlass Lint Commands

Synopsys, Inc. Feedback 11

vc_static_shell > source ip_filename.tcl

1.3.4 General output files

12 Feedback Synopsys, Inc.

2.1 Converting the .lib Files to the .db Files

2.2 Reading the Project Files

Synopsys, Inc. Feedback 13

sg_read_project -project <project_file_name> -goal <goal_name> -tclfile

2.3 Reading Reports

Table 2-1 General Reports

Report Name Description

14 Feedback Synopsys, Inc.

2.4 Using Tags and Parameters

2.5 Working with SGDC Constraints

2.6 Working with Violation Messages

Synopsys, Inc. Feedback 15

2.7 Convert SpyGlass Waivers to VC SpyGlass Lint Waivers

Figure 2-1 SpyGlass Project File

16 Feedback Synopsys, Inc.

The following is the converted Tcl file with waivers:

Figure 2-2 Generated Tcl File

The following is the report generated after waiver:

Figure 2-3 Generated Reports

Synopsys, Inc. Feedback 17

18 Feedback Synopsys, Inc.

Synopsys, Inc. Feedback 19

3.2 Development Phases and Methodologies:

3.2.1 Development Levels.

3.2.1.1 Block level Development:

3.2.1.2 SoC level Integration and Implementation

20 Feedback Synopsys, Inc.

3.2.2 Development phases.

3.2.2.1 Initial RTL Development

3.2.2.2 Initial RTL Development on block level

3.3 RTL Handoff

Synopsys, Inc. Feedback 21

3.3.1 RTL Handoff with block level

3.3.2 RTL Handoff with SoC level

3.4 Netlist Handoff

3.4.1 Netlist Handoff on block level

3.4.2 Netlist Handoff on SoC level