GuideWare UserGuide PDF

SpyGlass®-GuideWare
User Guide
Version 4.4.1
October 2010
Atrenta, Inc.
2077 Gateway Place, Suite 300
San Jose, California 95110
1-408-ATRENTA (1-408-453-3333)
http://www.atrenta.com
©Copyright 2006-2010 Atrenta, Inc. All rights reserved.

Copyright Information
This document is protected by copyright and distributed under licenses

restricting its use, copying, and distribution. No part of this document
may be reproduced in any form by any means without prior written
authorization of Atrenta and its licensors, if any.
DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR

IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE
OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID.
Atrenta, SpyGlass, and Predictive Analysis are registered trademarks of

Atrenta Inc. All other trademarks are the property of their respective
owners.
Printed in the United States of America.

SpyGlass®-GuideWare User Guide
Table of Contents
Early Design Closure ..................................................................................................... 7

Challenges in the Development of SoC Designs..................................................................................7
Challenges Involved During New RTL Block/Subsystem Development.............................................8
Initial Block/Sub-System RTL Development ...............................................................................8
Detailed Block/Sub-System RTL Development...........................................................................8
Final Block/Sub-System RTL Design and Handoff .....................................................................8
Challenges Involved in the Selection of Third Party or Internal Legacy IP.........................................9
Challenges Involved During SoC Integration .....................................................................................9
Early Design Closure ............................................................................................................................10
Introducing SpyGlass ....................................................................................................................... 11
SpyGlass Features....................................................................................................................11
Introducing GuideWare Reference Methodology ...............................................................................12
Fields of Use ....................................................................................................................................12
New RTL Block Development ...................................................................................................13
IP Block Qualification ................................................................................................................14
SoC Integration and Implementation.........................................................................................15
Identifying Problems in Current Approaches to Early Design Closure .............................................15
GuideWare for Early Design Closure ...............................................................................................16
Introducing Atrenta Console ....................................................................................... 17

Overview.................................................................................................................................................17
Methodology Used by Atrenta Console............................................................................................17
Invoking Atrenta Console .....................................................................................................................17
Invoking Atrenta Console Graphical User Interface .........................................................................17
Invoking Atrenta Console in Batch Mode .........................................................................................18
The Project File......................................................................................................................................19
Performing SpyGlass Analysis in Atrenta Console ...........................................................................19
Setting up a Design (Design Setup) .................................................................................................20
Selecting a Goal (Goal Setup & Run)...............................................................................................21
Analyzing the Design (Analyze Results) ..........................................................................................24
Messages Flagged During the Design Read-In Process ...................................................................26
Version 4.4.1 October 2010 iii

Table of Contents
SpyGlass Built-in Checks .................................................................................................................27
Setting up the Design in Atrenta Console ..................................................................29

Introduction............................................................................................................................................29
Understanding SpyGlass Operations ..................................................................................................29
Inputs to SpyGlass ................................................................................................................................30
Managing the Design Hierarchy ...........................................................................................................31
SpyGlass Design Constraints ..............................................................................................................34
Using Parameters/Generics and Macros.............................................................................................36
Compiling Technology/Library Files....................................................................................................37
Handling DesignWare Components.....................................................................................................38
Using the Save Restore Feature...........................................................................................................38
Waiving Messages.................................................................................................................................39
When to Apply Waivers ....................................................................................................................40
Specifying Waivers ...........................................................................................................................41
Using the waive Constraint...............................................................................................................41
Using Embedded SpyGlass Waiver Pragmas ..................................................................................42
Handling Memories................................................................................................................................43
Limiting the Analysis of Memories ....................................................................................................43
Using the Memory Reduction Feature..............................................................................................43
Field of Use 1 - New RTL Development.......................................................................45

Overview.................................................................................................................................................45
Initial RTL Development ...................................................................................................................46
Detailed RTL Development ..............................................................................................................46
RTL Handoff .....................................................................................................................................46
IP Handoff.........................................................................................................................................47
Goals for Field of Use 1.........................................................................................................................47
iv October 2010 Version 4.4.1

Table of Contents
Field of Use 2 - IP Block Qualification ........................................................................ 57

Overview.................................................................................................................................................57
IP Audit.............................................................................................................................................58
IP Risk Analysis................................................................................................................................58
Goals for Field of Use 2 ........................................................................................................................58
The Datasheet Report ...........................................................................................................................64
Generating the Datasheet Report ....................................................................................................65
Field of Use 3 - SoC Integration and Implementation ............................................... 67

Overview.................................................................................................................................................67
SoC / Subsystem Integration (of RTL Blocks)..................................................................................68
SoC Preliminary Netlist ....................................................................................................................68
SoC Pre-layout Netlist ......................................................................................................................68
SoC Post-layout Netlist ....................................................................................................................69
Aligning GuideWare Methodology with Chip Development Phases.................................................69
Goals for Field of Use 3 ........................................................................................................................70
Customizing Methodology........................................................................................... 81
Introduction............................................................................................................................................81
The Methodology Configuration System Window..............................................................................81
Creating a New Methodology ...........................................................................................................83
Creating a New Sub Methodology....................................................................................................84
Creating New Goals .........................................................................................................................85
Importing Goals for a Methodology ..................................................................................................86
Adding Rules in a Goal.....................................................................................................................86
Searching Rules........................................................................................................................87
Modifying Parameter Values for a Goal............................................................................................87
Version 4.4.1 October 2010 v

Table of Contents
Appendix........................................................................................................................89
Specifying Hierarchical Waivers ..........................................................................................................89
Optional Rule Selection Guide for GuideWare Basic .........................................................................89
General Functional/Simulation Issues ..............................................................................................89
General Structural Issues .................................................................................................................90
Assignment/Connection Mismatches ...............................................................................................90
Tristates............................................................................................................................................91
casex/casez Constructs....................................................................................................................91
Tasks and Functions.........................................................................................................................91
Flip-flops, Latches, and Associated Signals .....................................................................................92
Potentially Unsynthesizable Constructs ...........................................................................................92
vi October 2010 Version 4.4.1

Early Design Closure
Challenges in the Development of SoC Designs

The development of large SoC designs typically involve integration of various disparate
sub-systems or blocks. Most of these blocks are sourced from legacy designs or third
party IP providers. A few blocks may involve significant changes before they are used in
the final SoC. In some cases, a new block is developed from scratch. All these blocks are
finally stitched together to develop large SoC design(s).
The development process of large designs is divided into various stages, as shown in the
following figure:
Figure 1: Design development flow

Architecture and Micro Architecture
VALIDATION
Block Budget and Targets/Constraints
New RTL block/subsystem development

VERIFICATION
Third party/internal legacy IP selection
SoC Integration
The above figure shows various stages of design development flow such as new RTL
block development, third party/internal legacy IP selection, and SoC integration. Each
of these stages have their own set of challenges, as listed below:
 Challenges Involved During New RTL Block/Subsystem Development
 Challenges Involved in the Selection of Third Party or Internal Legacy IP
SpyGlass®-GuideWare User Guide ©Copyright 2001-2010 Atrenta, Inc. All rights reserved.
 Challenges Involved During SoC Integration
Challenges Involved During New RTL Block/Subsystem Development

In the development of the new RTL for a block or a sub-system, the designer faces
multiple challenges as the design matures through the design cycle. These can be
broadly classified into the following three stages:
 Initial Block/Sub-System RTL Development
 Detailed Block/Sub-System RTL Development
 Final Block/Sub-System RTL Design and Handoff
Initial Block/Sub-System RTL Development

The design team faces the following challenges during this stage:
 Issues related with correct code capture
 Issues related with simulation and synthesis
 Issues with basic connectivity
Detailed Block/Sub-System RTL Development

 Issues related with correctly capturing the functionality
 Issues related with adherence to structured design practices such as glitch-free clocks
and proper usage of resets
 Issues related to implementation aspects such as clock domain crossings, constraints
validity, power dissipation, and testability
Final Block/Sub-System RTL Design and Handoff

 Issues related with verification regressions and associated bug fixes
 Issues related with incomplete handoff
An incomplete handoff results in expensive and unpredictable error-prone iterations
during the SoC integration phase.
8 October 2010 Version 4.4.1

 Providing closure on various implementation issues such as synthesizability, timing,

constraints, clock domain crossings, testability, congestion/routing, and power
management.
Challenges Involved in the Selection of Third Party or Internal Legacy IP

While selecting an IP, either internal or external, the design teams are usually concerned
about the following challenges:
 Understanding the profile of an IP
The information about IP profile is critical for effective integration of an IP into the
target SoC. This information includes the usual IP statistics about approximate block
size, number of flip-flops and latches, ROM/memory and other large structures used
in the IP block, overall clock and reset architecture, voltage/ power domain, and so
on.
 Identifying specific risks associated with an IP
Some of the challenges that must be considered are unsynchronized clock-domain
crossing, inaccurate or incomplete timing exception specification, inconsistency
within SDC or across SDC and RTL description, and errors in clock-gating/
isolation-logic or level-shifting logic, if applicable.
 Estimating the adaptability of an IP
The challenge involved in estimating the extend to which an IP is adaptable for a
given target application might relate to testability, power domain, and voltage
domain adaptation, and other fine-tuning to meet SoC performance targets (if
applicable).
Challenges Involved During SoC Integration

During SoC integration, the integration team faces the following challenges:
 Issues related with functional verification and implementation
 Issues related with interconnection of blocks
 Issues related with clock and reset planning, I/Os, floorplanning, testability, JTAG,
scan chains, and power management
Version 4.4.1 October 2010 9


Issues in the early stages of design design development usually surface as critical bugs
in the late stages of design implementation. Such issues, if not resolved in the early
stages, result in iterations that are costly and time-consuming.
For example, at a particular stage of design development, you might get feedback about
synthesizability, testability, or power from implementation or integration team. This
may require you to go back to a previous stage, and resolve those issues. Once those
issues are resolved, there might be another issue in some RTL block, which might cause
another global iteration through the process.
Essentially, resolving an issue late in the design cycle might require multiple iterations.
In addition, resolving an issue might lead to introducing another issue in the block/sub-
chip. Figure 2 shows that fixing issues that RTL designers encounter at different stages
of development is an iterative process. It also shows that identifying an issue late in the
development stage negatively impacts the project cost, schedule, and performance.
Figure 2
Spec Long iteration result in
negative impact on:
Early
RTL
Design SDC
RTL-SDC conflicts
Simulation-synthesis
Synthesis
mismatch Iterative
correction
Low fault coverage Test Cost
Schedule
Power-related issues Power Performance
Timing-related issues Timing

Divergent process...
Routing congestion P&R getting worse as technology advances
Area limitation
To prevent a negative impact on the cost, performance, and schedule of the project, you
need to close the design early in the cycle. Atrenta provides you with the industry
standard solution, SpyGlass, for early design closure.

Introducing SpyGlass
Atrenta® SpyGlass® is a powerful and extendible tool for analyzing Hardware
Description Language (HDL) designs.
SpyGlass recognize the issues related with synthesis, simulation, test, power, clocks,
and constraints at an early stage (RTL or Netlist). In addition, it guides you to fix and
optimize your design and constraints that results in:
 Fewer synthesis iterations
 Higher test coverage
 Lower power consumption
 Properly implemented clock gating and voltage island strategies
 Faster timing closure with correct SDC, false paths, and multi cycle paths
 No silicon re-spin due to clock domain crossing issues
SpyGlass can analyze designs written in languages, Verilog (including SV) and VHDL.
In addition, SpyGlass supports mixed-language and DEF designs.
SpyGlass support both RTL and netlist abstraction for analysis.
SpyGlass Features
You can use SpyGlass to perform any of the several industry standard HDL analysis and
assessment programs, including OpenMORE™ and STARC™. You can also use
SpyGlass to analyze HDL source code early in the design stage for syntax, semantic,
and structural content, and perform complex checks later in the development process.
For example, you might initially use SpyGlass to check Register Transfer Level (RTL)
HDL descriptions. Later, you might use it to analyze gate-level designs or designs that
include both RTL and structural descriptions.
SpyGlass provides the following features:
 Support for Verilog (including SV) and VHDL
 Support for rich suite of built-in rules including the following checks:
 File checks such as file names, design units per file, and headers
 Naming checks on signals, ports, parameters, constants, clocks and other
constructs

Introducing GuideWare Reference Methodology
 Style and related checks

 Coding for synthesis and related checks
 Design practice and related checks
 Area, timing and synchronization checks
 Clock and reset checks
 DFT, LowPower, Constraints, and similar checks (cost options)
 Support for a variety of report format options
 Support for built-in engines, including RTL synthesis and flattening, to enable
detailed implementation tests including clocking, reset, and synchronization of
asynchronous signals
 Support for the following interfaces:
 Console Graphical User Interface
 Console batch interface
 Support for the following customization features:
 Perl interface that provides extensive programmability and customization of error
messages, error severity, and other parameters.
 User-programmable reporting that allows you to generate message reports as
screen displays, hard copies, files, e-mail, Web pages, and in other formats.

As described in the previous sections, it is imperative that all the implementation issues
should be addressed closest to their origin, that is, early in the design cycle. GuideWare
reference methodology provides guidance to the designers to address such issues by
running a set of goals that are fine tuned for high quality results and low noise. Each
goal is a collection of rules. These goals are organized in a specific manner in three
fields of use that GuideWare supports for the SoC design development flow.
Fields of Use
In the SoC design development flow process, GuideWare reference methodology
classifies GuideWare into the following fields of use:

 New RTL Block Development

 IP Block Qualification
 SoC Integration and Implementation
The above fields of use are highlighted in the following figure:
Figure 3: Three fields of use
VALIDATION Architecture and Micro Architecture
Block Budget and Targets/Constraints
New RTL block/subsystem development Field of use 1
Field of use 2
VERIFICATION
Third party/internal legacy IP selection
SoC RTL/Gates Field of use 3

SoC INTEGRATION
SoC logic synthesis
SoC scan, STA, power optimization
SoC place and route
TAPE OUT
Each field of use addresses the design goals that are specific to that activity. Each design
goal is directly addressed by a pre-packaged SpyGlass goals. These goals have been
tested and fine-tuned for high impact results and minimal noise.
New RTL Block Development

This field of use has the following characteristics:
 RTL being developed is mostly assumed to be new.

 No assumptions are made about the existing behavior or stability.

 The key concerns are feasibility and performance of the design.
 The design intent is mostly assumed to be known to the engineers.
 Checks and goals are organized to align with the evolution and maturity of the new
RTL block.
 The user is encouraged to capture and validate constraints as well as waivers
throughout the new RTL development process.
NOTE: The new RTL block can range from a single flat small block to sub-chip block
with many levels of hierarchy.
In this field of use, the GuideWare methodology recommends a three-stage flow that is
aligned with how RTL matures from initial composition to handoff. Following are the
four stages in this field of use:
 Initial RTL Development
 Detailed RTL Development
 RTL Handoff
 IP Handoff
IP Block Qualification
This field of use is defined for audit and risk analysis of an IP Block.
NOTE: In GuideWare, the term, IP block, has been used to include third-party IP block as
well as internal legacy design blocks (from a previously completed and verified design). In
both cases, the assumption is that the ‘block’ is stable and complete, and expected to be
validated by provider.
Currently, many subsystems are available as semiconductor IP (Intellectual Property).
An IP should be thoroughly tested for its quality and completeness before using it in the
SoC integration phase.
Following are the two stages in this field of use:
 IP Audit
 IP Risk Analysis

SoC Integration and Implementation

The SoC integration phase includes stitching of the new RTL blocks or IPs. Following
are the four stages in this field of use:
 SoC / Subsystem Integration (of RTL Blocks)
 SoC Preliminary Netlist
 SoC Pre-layout Netlist
 SoC Post-layout Netlist
Identifying Problems in Current Approaches to Early Design Closure

Current approaches to early design closure usually involve applying many disjoint
rule-checking type tools throughout the front-end design process. This approach has the
following drawbacks:
 Alignment and false violations
These rule checking tools are not tuned or aligned to the three fields of use, described
earlier. This leads to many false violations or noise issues.
Many designers tend to ignore or waive such false violations, defeating the whole
purpose of the tool.
 Issues with adaptability
These rule checking tools are not flexible enough to adapt to the design style
preferences specified by the designers. For example, different design teams may
want to specify any of the following design style preferences:
 Using handshaking scheme in the clock domain crossing approach
 Using synchronous resets
 Using asynchronous resets
The rule-checking system should be flexible enough to accommodate such design
style preferences.
 Issues relating to interdependency and platform aspects
Rule checks usually do not recognize the interdependent nature of issues. For
example, clock domain crossing issues should be checked when clock
transformations are made for power management or testability. Many rule checking

systems lack the platform-level advantage traversing across disciplines. A single

platform which can concurrently address interdependent checks is highly desired.
GuideWare for Early Design Closure

Designs evolve and mature in different dimensions in a few stages. In such a scenario,
there is a need to apply the right SpyGlass rules at the right time. The use of these rules
should be aligned with the design evolution. Without such an alignment between design
evolution and applicable SpyGlass rules, you may end up with too many violations.
Some users start with a very small subset of rules, and plan to add more SpyGlass rules
as required. This approach severely limits the potential to catch serious issues. To solve
such problems, Atrenta provides you with a pre-packaged set of goals and
methodologies called GuideWare™.
GuideWare identifies the optimal set of highest impact rules to be used at proper
evolutionary stages of design. The idea is to identify problems that, if not fixed, will
cause serious issues downstream either during implementation or verification.
GuideWare methodology provides you with a set of goals, where each goal is a
pre-packaged set of rules. This set includes the must have rules and the optional rules.
The must have rules are applicable to any design irrespective of the target domain,
whereas the optional rules allow rapid tailoring of the rule set for a design team's
preferences and practices. Atrenta provides you with a robust and an easy to use
environment for selecting and configuring these optional rules.
GuideWare essentially enables design teams to run the right rules at the right stage
resulting in a very good coverage of the issues with low and manageable noise across
the platform (addressing clocks, testability, power, and constraints, in addition to
linting).
Atrenta's SpyGlass platform is the basis of GuideWare.

Introducing Atrenta Console
Overview
Atrenta Console is used for configuring, selecting, and running the GuideWare
methodology. It uses a goal-centric approach that provides you step-by-step guidance to
analyze your HDL designs. It is the default GUI of SpyGlass.
NOTE: Before starting Atrenta Console, you should set the license file. For details on
setting the licence file, refer to the Before You Begin topic of Atrenta Console User Guide.
Methodology Used by Atrenta Console

By default, Atrenta Console uses GuideWare as the methodology for design analysis.
The GuideWare methodology provides a jump-start for design groups with SpyGlass
goals readily usable out-of-the-box at various phases of IC design flow (RTL, IP and
Chip Integration design phases). The GuideWare Reference Methodology can be
configured to map to customer specific design style and handoff requirements. If a
customized methodology has been created, it can be selected during an Atrenta Console
session or be made the default methodology at startup (refer to the The SpyGlass
Configuration File section of Atrenta Console Reference Guide for details).
Invoking Atrenta Console

You can invoke Atrenta Console in any of the following modes:
 Atrenta Console Graphical User Interface (GUI)
 Atrenta Console Batch Interface
Invoking Atrenta Console Graphical User Interface

To invoke Atrenta Console GUI, specify any of the following commands:
 spyglass -gui=console
 spyglass
 spyglass -gui
Invoking Atrenta Console
Following figure displays the Atrenta Console GUI:
The above window provides you a step-by-step guidance to analyze your HDL designs.
The process of analyzing HDL designs is divided into three stages that corresponds to
the three main tabs (Design Setup, Goal Setup & Run, and Analyze Results) in Console GUI.
Invoking Atrenta Console in Batch Mode

Besides the Atrenta Console GUI, you can also run Atrenta Console in the batch mode
by using SpyGlass command-line options.
You can use an already created project file (.prj) as an input to the batch command-line
to perform design read, run goals, and view goal status summary.
NOTE: The project file is mandatory to run Atrenta Console in batch mode. If the project

The Project File
file is not specified, SpyGlass assumes its normal batch mode, and console-specific
command-line options do not work.
You can invoke the batch mode by specifying the following command-line options:
spyglass -batch -project <project-file-name>
[ CONSOLE-Specific OPTIONS ] [ Other-Options ]
Here, the -project option accepts the name of the project file.
The Console-specific options are supported only when you run Atrenta Console in the
batch mode.
The other options include all other batch command-line options that are supported by
SpyGlass. For details on these command-line options, refer to the Using the Console
Batch Interface section of Atrenta Console User Guide.
The Project File

Atrenta Console stores data about the current project in a project file (.prj). This data
includes the following details:
 Input HDL files and language settings
 Run options
 Constraint files and parameters settings for goals
You can later re-start the GUI or batch session with all the saved data in the project file.
The results generated in the project file during GUI runs are visible in the batch mode
and vice-versa. This way, you can load the project file generated from the GUI run in
batch mode for further processing, and vice-versa.
By default, the project file is saved in the current working directory. However, you can
specify a different directory by using the File > Save Project As menu option.
Performing SpyGlass Analysis in Atrenta Console

Atrenta Console enables you to set up your design and libraries, set up the tool options,
clean design errors, perform a detailed analysis of the design, and debug the results.
Atrenta Console analyzes you HDL design in the following three stages:

1. Setting up a Design (Design Setup)

2. Selecting a Goal (Goal Setup & Run)
3. Analyzing the Design (Analyze Results)
Setting up a Design (Design Setup)

This is the first stage where you specify the design files, SGDC files, precompiled files,
and technology files. In addition, you can specify other design-read options that affect
the SpyGlass run. You should complete this stage without any fatal errors before
proceeding to the next stage. Fatal errors indicate illegal and unrecognizable HDL code.
To set up a design, click the Design Setup tab. This displays the screen, as shown in the
following figure:

Setting up a design involves the following steps:

1. Adding the Design Files
In this step, you add various files such as HDL files, HDL libraries, technology
libraries, and source list files. To add design files in your project, click the Add Design
Files tab, and then add the required files.
For details on adding design files, refer to the Adding the Design Files section of
Atrenta Console User Guide.
2. Specifying Design Read Options
In this step, you specify the design-related options that affect the SpyGlass run. To
specify these options, click the Set Read Options tab. This displays the available read
options that you can set as per your requirement.
For details on setting design read option, refer to the Design Read Options in Atrenta
Console section of Atrenta Console Reference Guide.
NOTE: Please also refer to the Setting up the Design in Atrenta Console chapter to
know the basic steps for setting up the design in Atrenta Console.
3. Running Design Read
In this step, you perform the first level of HDL analysis. To start HDL analysis, click
the Run Design Read link under the Run Design Read link tab.
For details on running design read, refer to the Running Design Read section of
Atrenta Console User Guide.
Once the design read is complete, SpyGlass flags various messages based on its
internal checks. For details, refer to Messages Flagged During the Design Read-In
Process topic. Among the available list of messages flagged, you must resolve all the
fatal messages before proceeding to the next stage of SpyGlass analysis.
Selecting a Goal (Goal Setup & Run)

During this stage, you select and run goal(s). A goal is a collection of rules that ensures
the accomplishment of that goal.

To go to this stage, click the Goal Setup & Run tab. This displays the following screen:
By default, the Select Goal tab is selected. Under this tab, Console displays a list of
domains (such as lint, audit, clock_reset_integrity, etc.) under each stage of the selected
methodology. For example, in the above figure, the selected methodology is New_RTL.
This methodology has three stages: initial_rtl, detailed_rtl, and rtl_handoff. For each domain
under a particular stage, Console displays a list of goals. For example, in the above
figure, the lint domain lists four goals: connectivity, simulation, synthesis, and structure. You
can view the goals of other domains by clicking the + sign adjacent to the domain name.
To display the goals of a different methodology, click the Select Methodology link. This
displays the Select Methodology dialog in which you can select the required methodology.
After selecting the required methodology, select the required goals that you want to run

and click the Run Selected Goal(s) link. This runs the selected goals. In addition, you can
also provide the design intent information necessary to complete the goal analysis. This
includes adding constraints and setting parameters. You can provide this information
under different tabs appearing during this stage.
The Goal Setup & Run stage involves the following steps:
1. Selecting a Goal
To select a goal, click the Select Goal tab. Under this tab, Atrenta Console displays a
list of goals based on the methodology selected.
NOTE: The default methodology is GuideWare New_RTL.
Once you select the required goal(s), click the Run Selected Goal(s) option to perform
analysis of the selected goal(s). Once the analysis is complete, Atrenta Console
creates a directory (under the <project-name> directory) by the name of the
methodology selected. In addition, Atrenta Console also creates a sub-directory by
the name of the goal selected. For details on the project working directory, refer to
the The Project Working Directory topic of Atrenta Console User Guide.
For mode details on selecting a goal, refer to the topic, Selecting a Goal, in Atrenta
Console User Guide.
2. Providing Setup Information
In this step, you identify blackboxes in the design, and provide the setup information
for those blackboxes. In addition, you also specify constraints for clocks and resets in
your design. You can provide all this information by using the setup wizard under the
Central Setup tab.
For details on this wizard, refer to the Central Design Setup topic of Atrenta Console
User Guide.
3. Setting up the Goal
In this step, you set the recommended parameters and specify the required
constraints for the goal.
Goals that have their setup status as Setup Recommended require additional setup
steps. SpyGlass enables you to perform these steps by using the setup wizard. To
invoke the setup wizard for such goals, select the goal, and click the Setup Goal tab.
The setup wizard then guides you to provide the required details.
For more details on setting up a goal, refer to the Setting up the Goal topic of Atrenta

Console User Guide.
Analyzing the Design (Analyze Results)

This is the last stage than runs SpyGlass analysis. In this stage, you analyze and debug
results.
To analyze the design, click the Analyze Results tab. This displays a screen, as shown in
the following figure:
In the above window, click the Run Goal <goal> link to perform goal analysis. Here,
<goal> refers to the goal that you have selected in the previous stage.
When analysis is complete, Atrenta Console displays the messages in the Results
window. You can double-click on a message to view the source file, which you can edit
to fix the violation messages. You can also view the schematic by double-clicking on a
violation message and selecting the Modular Sch or Incremental Sch link in the Results

section. If a message does not represent a serious problem, you can waive that message
by clicking the Waiver link in the Results section.
You can also analyze the rule violations and assign appropriate tags based on the actions
that you have performed (such as Fixed or VerifiedFixed) or intend to perform later (such
as Investigate or ToFix). In this way, you need not repeatedly run the analysis to update
the status of the violations after performing a set of corrective actions in your design. To
assign a tag, right-click on the message, and select the Tag menu option. This displays
another sub-menu from which you can select the required option, as shown in the
following figure:
Atrenta Console also generates various reports at the end of the analysis run. To view
these reports, select the Tools -> Report menu option. This displays a sub menu that

Messages Flagged During the Design Read-In Process
contain various categories for different type of reports, as shown in the following figure:
In the above figure, when you click the Default category, Console displays a list of all the
default report names. You can click on the required report name to open that report in a
separate window. Similarly, Console generates other reports (based on the goal being
run) under appropriate categories. For example, in the above figure, all the
clock-specific reports are listed under the clock-reset category.
NOTE: Reports that do not contain any relevant data appear disabled in the available list of
reports.
For more details on this stage, refer to the Stage 3: Analyzing the Design (Analyze
Results) section of Atrenta Console User Guide.

During the design read-in process, SpyGlass flags different types of issues in your

design, as mentioned in the following table:
Issues Related To.. Details

Syntax Errors For details, refer to the topic, Dealing with Syntax Errors, of SpyGlass
Design Read-In Methodology Guide.
Blackboxes For details, refer to the topic, Dealing with Blackboxes, of SpyGlass
Unsynthesized modules For details, refer to the topic, Dealing with Un-Synthesized Modules,
of SpyGlass Design Read-In Methodology Guide.
Multiple top-level modules For details, refer to the topic, Dealing with Multiple-Top Modules, of
Out of memory situations For details, refer to the topic, Dealing with “ Out of Memory”
Situations, of SpyGlass Design Read-In Methodology Guide.
Elaboration errors These are the elaboration-related violations.
SpyGlass Built-in Checks

While analyzing or synthesizing RTL designs, SpyGlass perform checks on the HDL
syntax and structure. These checks are the BuiltIn checks that are always performed
automatically.
If any syntax or structural issues are found, SpyGlass generates the corresponding
standard error or warning messages (known as built-in messages). These built-in
messages are different from the rule messages generated during rule-checking.
Various classes of such built-in messages are specified in the following table:
Message Type Message Prefix

Syntax errors STX_
Language warnings WRN_
Synthesis errors and warnings SYNTH_
Elaboration errors and warnings during ELAB_
elaboration
LEF file parsing messages LEFSTX_ and LEFWRN_
DEF file parsing messages DEFSTX_ and DEFWRN_

Message Type Message Prefix

SDC file parsing messages SDC_
PLIB file parsing messages PLIBSTX_ and PLIBWRN_
Constraints-specific checks SGDC_, checkSGDC_, SGDCSTX_, SGDCWRN_, and
SGDCINFO_
Syntax errors and language warning messages are language-specific, that is, there are
separate message sets for Verilog and VHDL. Synthesis warnings and errors are
language-neutral for the most part. See the SpyGlass Built-In Messages Reference for
details on different type of message sets.

Setting up the Design in Atrenta Console
Introduction
This chapter discusses some basic concepts of SpyGlass and some important features
that you may want to use while using SpyGlass. This chapter covers the following
topics:
 Understanding SpyGlass Operations
 Inputs to SpyGlass
 Managing the Design Hierarchy
 SpyGlass Design Constraints
 Using Parameters/Generics and Macros
 Compiling Technology/Library Files
 Handling DesignWare Components
 Using the Save Restore Feature
 Waiving Messages
 Handling Memories
Understanding SpyGlass Operations

Atrenta® SpyGlass® analyzes a set of source design files and associated library files, if
any, based on the specified command-line options. After successful analysis, the
SpyGlass generates a violation database (.vdb) and design schematic data if rule-
checking is configured to generate the schematic data. In addition, it generates a project
file (.prj) that contains various options used during SpyGlass analysis.
The following figure illustrates the SpyGlass functional model:
Inputs to SpyGlass
SpyGlass Functional Model
Source Files Schematic Data

Command-line Options
Project file (.prj)
Library Files
(Optional) SpyGlass Console GUI
SGDC File
(Optional) Violation Database
Goals/Rules Reports (.rpt)
When you run SpyGlass, it first performs some basic checks on your design such as
checks related with synthesis and elaboration. Once the basic checks are done, SpyGlass
runs domain-specific checks based on the rules requested.
Refer to the How SpyGlass analyzes your design topic of SpyGlass Predictive Analyzer
User Guide to know the details of the steps using which SpyGlass analyzes your design.
Inputs to SpyGlass
SpyGlass supports various data formats. The following tables lists the details of each of
the supported data format:
Data Version Applicable To

VHDL • IEEE 1076-1993 All SpyGlass capabilities
• VHDL 1987
Verilog • IEEE Standard 1364-2001 (v2k) All SpyGlass capabilities
• Verilog 95
System Verilog IEEE Standard 1800-2005 All SpyGlass capabilities

Managing the Design Hierarchy
Data Version Applicable To

SDC 1.7 SpyGlass-CDC, SpyGlass-Constraints,
SpyGlass-Txv, SpyGlass-Power
.lib 2007.12 All SpyGlass capabilities
.plib 2007.03 SpyGlass-Power
LEF 5.6 SpyGlass-Power
DEF 5.6 SpyGlass-Power
SPEF IEEE 1481-1998 SpyGlass-Power
SAIF 2.0 SpyGlass-Power
VCD <standard> SpyGlass-CDC, SpyGlass-Power,
SpyGlass-Txv
FSDB Novas 2008.04 supported FSDB 4.2 SpyGlass-Power
CPF 1.0 SpyGlass-Power
UPF 1.0 SpyGlass-Power

SpyGlass enables you to specify the portions of your design that you want to consider
and/or exclude from the scope of SpyGlass analysis. You can specify this information
by making some design units as the top-level design units and by stopping some design

units from SpyGlass analysis. Consider a design, as shown in the following figure:
By default, all the design units (MEM_BLOCK, DSP_block, TEST_CONTROLLER,

and POWER_CONTROLLER) as well as the design units instantiated directly/indirectly
within these design units are considered for SpyGlass analysis. Now, among these these
units, you can specify the top-level design units that should be considered for SpyGlass
analysis by using the following command in the Console project file:
set_option top <module-name>
To exclude some design units from the scope of SpyGlass analysis, specify the
following command in the Console project file:
set_option stop <module-name>

Some examples of using the above commands are discussed in the following table:
Command Result
set_option top DSP_block Only the design unit, DSP_B, is considered
set_option stop DSP_A for SpyGlass analysis.
set_option top POWER_CONTROLLER The design units, POWER_inst,
set_option stop Block1 P_inst_A, and Block2 are considered
for SpyGlass analysis.
set_option stop P_inst_A Only P_inst_A is excluded from the scope
of SpyGlass analysis. All the other design
units including the design units instantiated
directly/indirectly within P_inst_A are
considered for SpyGlass analysis.
NOTE: For more details on managing the design hierarchy, refer to the Managing the
Design Hierarchy chapter of Atrenta Console User Guide.
You can also specify the design units to be included and/or excluded from the scope of
SpyGlass analysis under the Set Read Options tab of the Design Setup stage in Atrenta

SpyGlass Design Constraints
Console, as shown in the following figure:
In the above figure, Specify the top-level design units in the Value field corresponding to
the Top Level Design Unit(s) option name. Similarly, you can specify the design units to be
excluded from the scope of SpyGlass analysis in the Value field corresponding to the
Stop Design Unit(s) option name.

SpyGlass Design Constraints (SGDC) provide additional design information (such as
information related with clock/reset, case analysis, voltage/domain, etc.), which is not
apparent in the RTL description. You can specify this information in the form of SGDC
directives. These directives are written in an SGDC file (.sgdc) that can be specified by
using the -sgdc command-line option.

A sample SGDC file is shown in the following figure:
The following table lists some commonly used constraints:
Constraint Purpose
current_design Design unit name
clock Defines the clocks in the design
reset Specifies the resets signals in the design
set_case_analysis Specifies the case analysis conditions
test_mode Specifies the set of conditions, both pins and values, that when
simulated, will force the circuit in test mode
input Specifies the clock domain at input ports
output Specifies the clock domain at output ports
fifo Provides a mechanism to provide FIFO information so that
SpyGlass can perform complete recognition and verification of
FIFOs
ip_block Specifies the IP blocks in your design

Using Parameters/Generics and Macros
Constraint Purpose
voltage_domain Specifies the voltage/power domains in the design and its
information is used by voltage and power domain rules.
isolation_cell Specifies the isolation cells in power domains
levelshifter Specifies the names of design units to be used as level shifters
always_on_buffer Specifies the always-on buffers.
supply Specifies the supply and ground port names for all the LPPLIB
rules
sdc_data Specifies the SDC file
assume_path Specifies the paths that exist between the input pins and the
output pins of blackboxes
set_clock_gating_style Specifies the name of the cell that should be used as the clock
gating cell
select_wireload_model Specifies the wireload model for the design
wireload_selection Specifies the default wireload selection table to be used for power
estimation
For more details on constraints such as creating and processing SGDC file, refer to the
Working with SpyGlass Design Constraints chapter of the Atrenta Console User Guide.
Using Parameters/Generics and Macros

Console enables you to define parameters/generics for various modules. The value of
the parameter (in Verilog) or generic (in VHDL) for such modules is defined when that
module is instantiated in the hierarchy. However, if you choose to run SpyGlass on such
a module as a top module, the value passed to the parameter/generic will not be visible
to SpyGlass. In such cases, you can specify parameter values for such top-level
parameterizable design units under the Set Read Options tab during the Design Setup
stage. Under this tab, click the button corresponding to the Set HDL Parameter(s)

Compiling Technology/Library Files
Value option. This displays a dialog, as shown in the following figure:
In the above dialog, click the Add button to add a new row in which you can specify the
name of the parameter in the Key field and its corresponding value in the Value field.
You can also set parameters by specifying the following command in the Console
project file.
set_option param <name>
In addition to parameters/generics, Console also support macros. Macros enables you to
define constants in your design. To enter macros in your analysis, specify the following
command in the Console project file:
set_option define <list>
Here, <list> refers to a space-separated list of macro name-value pairs. For example,
you can specify various macros and their respective values by using this command, as
shown below:
set_option define fee=1 fi=2 fo=3 fum=4
Compiling Technology/Library Files

Atrenta Console provides the auto-compilation feature in which it automatically
compiles the specified technology/library files (.lib) into SpyGlass compatible format
library file (.sglib file). To turn on this feature in Atrenta Console, select the value No
corresponding to the Enable auto-compilation of gateslib into sglib option under the Set Read
Options tab. By default, this option is set to No.
You can also enable auto-compilation of gateslib (.lib) into sglib by specifying the
following command in the Console project file:
set_option enable_gateslib_autocompile yes

Handling DesignWare Components
Handling DesignWare Components

If your design has instances of Synopsys DesignWare components, you can map these
components in terms of the technological gates. To map these components in Atrenta
Console, select the value Yes corresponding to the Enable Analysis of Instantiated
DesignWare Components option under the Set Read Options tab. By default, this value is
set to No.
You can also map the DesignWare components in Console by specifying the following
command in the Console project file:
set_option dw yes
For details on DesignWare components, refer to the Dealing with Designware®
Components topic of Atrenta Console User Guide.
Using the Save Restore Feature

Atrenta Console provides the Design Save-Restore feature which re-uses the data from
a previous synthesis run. This saves significant amount of runtime whenever SpyGlass
analysis is run multiple times or iteratively for the same design.
By default, the Save-Restore is enabled in Atrenta Console. You can disable this feature
in the Preferences dialog (Tools-> Preferences), under the Miscellaneous category, as

Waiving Messages
shown in the following figure:
In the above figure, deselect the Enable Save restore Flow option to disable the Save/
Restore feature.
You can also enable save/restore feature by specifying the following command in the
Console project file:
set_option enable_save_restore yes
For more details on the Save/Restore feature, refer to the Saving and Restoring Designs
section of Atrenta Console User Guide.
Waiving Messages
During design analysis, you may want to suppress the display of certain violation
messages that may not represent a serious problem or messages that you may want to
ignore at that point of time. You can suppress the display of such messages by using
waivers.
Effective use of of waivers is significantly based on the overall use of GuideWare
methodology through out the SoC design cycle. To ensure effective use of waivers, you
should first perform the following steps:

Waiving Messages
1. Identify the GuideWare Field-of-Use for each block, that is, whether it is a new RTL
block, an IP/legacy block, or an SoC.
2. For each block and/or integrated SoC, identify the stage in which that block/SoC is
for that Field-of-Use.
3. For each block and/or integrated SoC, identify the goals that you want to run.
4. Run the selected goals
After performing the above steps, Console flags appropriate violation messages. At this
stage, if still there are messages that you want to waive, you can apply waivers to
suppress those messages.
When to Apply Waivers

The following points discuss few cases in which you can apply waivers:
 If your design is in early development stages, and some functionality, such as DFT or
power related, has not been implemented as yet
In such cases, you may add placeholders in your design for the required functionality
that you plan to implement later. However, you may want to check your design for
other functionalities that you have already implemented.
When you run specific goals to check for the already implemented functionalities,
Console may also report violations for the placeholders that you added. In such
cases, you can specify waivers to waive the violations reported for such placeholders
so that you can concentrate only on the violations reported for the already
implemented functionality.
 If one part of the design is ready and the other part is under development
In such cases, if you run goals to check for certain issues in your design, Console
may report violation for those parts of your design that are not yet ready. In such
cases, you can specify waivers on such parts to suppress the display of violations for
these parts.
 If some ports in your design have been intentionally left unconnected
In such cases, you can apply waivers for unconnected ports so that Console does not
display violations for such ports.

Waiving Messages
Specifying Waivers
Waivers are written in a separate file and can be used with the modified source files as
long as the modifications do not invalidate the design constraints. You can create
waivers in any of the following ways:
 Using the waive Constraint
 Using Embedded SpyGlass Waiver Pragmas
Atrenta Console provides the Waiver Editor window in which you can specify waivers.
For details on this window, refer to the topic, Tools -> Waiver Editor, in Atrenta Console
Reference Guide.
In addition, Atrenta Console enables you to specify various settings related with waivers
in the Preference dialog under the Waiver category, as shown in the following figure:
For details on the above page, refer to Waiver Page topic under the Tools > Preferences
section in Atrenta Console Reference Guide.
Using the waive Constraint

Use the waive constraint to waive a message by various categories such as by source
files, by design units, by rules, etc. The waive constraint specifications are supplied in
a file of the same format as that of an SGDC file.
A sample file containing waive constraint specifications is shown below:
################# Sample SpyGlass Waiver Constraints ##############

Waiving Messages
##### Single Opion(File/DU/Rule) Waivers ############

## Waive all violations for a design file or set of design files
waive -file "/apps/rtl/imp_controller.v"
## Waive all violations for a design module or group of design
## modules
waive -du "ahb_transmit"
## Waive all violations of a rule or group of rules
waive -rule "W164a"
################### Double Option Waivers #########################
## Waive all violations of a particular rule for a design module/
## file
waive -file "/apps/rtl/imp_controller.v" -rule "W164a"
waive -du "ahb_transmit" -rule "W164a"
################### Multi Options Waivers #########################
## Waive all violation of warning severity related to a particular
## net/design object for a design unit.
waive -regexp -du "ahb_tran" -severity="warning" -msg ".*test.*"
## Waive all clock rule violations arising due to black-boxes for a
## group of design units
waive -regexp -du "ahb_.*" -rule "Clk_.*" -msg ".*black-box.*"
For details on using the waive constraint, refer to the Waiving Messages Using the
SpyGlass waive Constraint section of Atrenta Console User Guide.
Using Embedded SpyGlass Waiver Pragmas

You can waive rule messages in the waiver/sgdc files by using embedding SpyGlass
waiver pragma directives (disable_block and enable_block) at appropriate
places. Consider the following example:
//spyglass disable_block R1
...
...<cmd>
...
//spyglass enable_block R1

Handling Memories
In the above example, SpyGlass disables rule checking for the R1 rule in the lines after
//spyglass disable_block R1. However, SpyGlass resumes rule checking for
the R1 rule in the lines after //spyglass enable_block R1. Here, <cmd>
continue to work, if specified correctly, irrespective of the pragmas.
You can also use # instead of // while specifying the disable_block and
enable_block pragmas.
For more details on using SpyGlass pragmas, refer to the Waiving Messages using
SpyGlass Pragmas section of Atrenta Console User Guide.
Handling Memories
SpyGlass provides the following features to handle memories in your design:
 Limiting the Analysis of Memories
 Using the Memory Reduction Feature
Limiting the Analysis of Memories

When you include memories in your design, SpyGlass generates a register and
associated connections for each bit of memory it compiles. However, as the size of
memory arrays increase, the memory and runtime requirements for the analysis increase
dramatically. At some point, you compile small arrays into registers and treat larger
arrays as blackboxes. In such cases, you can specify an upper threshold for compiling
memories in Atrenta Console. To do so, specify the upper threshold value in the Value
field corresponding to the Upper Threshold for Compiling Memories option under Set Read
Options tab. By default, this value is set to 4K bits. You can also set an upper threshold
value by specifying the following command in the Console project file:
set_option mthresh <value>
Using the Memory Reduction Feature

It may happen that you may not be able to read-in your design because that design
consumes a large memory. In such cases, you can use the memory reduction feature of
SpyGlass to process memories in an optimized manner. To use the memory reduction
feature in Atrenta Console, specify the value Yes in the Value field corresponding to the

Handling Memories
Enable Handle Memories option, under the Set Read Options tab, as shown in the following
figure
Alternatively, you can also specify the following command in Console project file to
process memories in an optimized manner:
set_option handlememory yes
For more details on this feature, refer to the Memory Reduction Feature section of
Atrenta ConsoleUser Guide.

Field of Use 1 - New RTL Development
Overview
Field of use 1 involves the development of a new RTL. 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, the GuideWare methodology recommends a four-stage flow, as
The above flow represents an ecosystem of goals. You can customize this flow based on
your specific requirements and workflow of your design project.
The following sections describe the details of each stage.
Overview
Initial RTL Development

During this stage, an initial version of the RTL is completed, and an initial set of
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, GuideWare 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 everytime before
checking-in their RTL code. Waivers, if any, should be captured on an ongoing basis.
Detailed RTL Development

During this stage, the RTL is mostly functional, and constraints start becoming more
mature.
The implementation issues are of more concern during this stage. These issues are
related with clock domain crossings, power-related clock gating, some timing
exceptions, and preliminary DFT setup.
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.
Verification-related bug discoveries may result in significant changes in RTL. In such
cases, you need to ensure that RTL changes do not result in an unintentional adverse
impact on implementation aspects.
RTL Handoff
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 GuideWare 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. Local bug fixes due to verification
may however still continue. Constraints, power gating, and testability strategies are well
defined and captured. SpyGlass goals are used to perform hand-off checks with

Goals for Field of Use 1
appropriate waiver definitions.

The collection of recommended SpyGlass goals and coherent collection of waivers
allows a design team to establish an objective go/no-go criterion for new block hand-off
for integration and implementation.
IP Handoff
This is the milestone for an RTL block that is targeted for use (or reuse) as an IP by an
internal or external customer. It is expected that before reaching this milestone, you
have already executed the previous stages of the GuideWare methodology and the IP
block is ready for customer handoff.
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 SpyGlass run. It is also expected
that the user is able to share the setup, constraints, waivers, reports, etc. with the
customer.
There is a large overlap between this milestone and a superset of all the first three stages
of Field of Use 1. Similarly there is a large overlap between this milestone and the goals
of Field of Use 2 - IP Block Qualification. This ensures that the consumer and supplier
sees the same issues if they are waived for some reason. Communication between the
two sides is enhanced much more efficiently with a similar workflow and a common set
of templates.

The following table describes GuideWare recommended goals for each of the four

stages of the new RTL development.
initial_ detailed rtl_ ip_

Domain Goal rtl _rtl handoff handoff
lint connectivity
Checks the design for basic
connectivity issues
simulation
simulation issues
synthesis
synthesis issues
structure
Checks the design for
recommended design practices
and structural issues


audit block_profile
Reports informational data
related to the design
rtl_audit Optional Optional Optional Optional
Provides summary information
about the RTL data.
structure_audit Optional Optional Optional Optional
about the detailed design
structure implied by the RTL
description
datasheet_io_audit Optional Optional Optional Optional
This goal helps in populating
data for datasheet generation. It
populates the following
information:
1. Chip-level port registered or
not
2. Chip-level port details such as
width, direction, comments, etc.
3. Information related to various
pragma's
cdc_prep cdc_setup Optional Optional Optional Optional
Find the clocks and resets in a
design
cdc_setup_check Optional Optional Optional
Checks setup correctness and
completeness


clock_reset_i power_gated_clock Optional Optional Optional
ntegrity Performs checks on gated clock
clock_reset_integri Optional Optional
ty
Performs sanity checks for
clocks and resets
cdc_verif cdc_verif_base Optional Optional
Ensures all clock domain
crossings are properly
synchronized
cdc_verif Optional Optional
Verifies all aspects of clock
domain crossings
cdc_exhaustiv cdc_verif_base_stri Optional Optional
e ct
Implements clock domain
crossing metastability checks
with pessimistic approach
cdc_verif_strict Optional Optional
Implements clock domain
crossing verification with
pessimistic approach
For more details on the clock goals, refer to the SpyGlass-CDC-Methodology.pdf document.
constraint_ge gen_sdc Optional
neration Enables the designers to create
SDC goals from RTL or netlist


constraint sdc_quick_check
Finds syntax errors in the SDC
file
sdc_coverage
Enables you to compute design
coverage, and report uncovered
objects
clock_consis
Ensures basic consistency and
clean clock definition
io_delay Optional
Cleans delay constraints
combo_path_check Optional
Implements constraint validation
for combinational path
structural_exceptio
n
Checks that timing exceptions
specified in a constraints file are
on paths which are structurally
connected
hierarchical_check Optional Optional Optional
Ensures that constraints are
consistent across block
hierarchies
redundancy_check Optional Optional Optional
Removes any redundancy in the
constraints, and perform checks
that might facilitate better
retargeting


sdc_equiv Optional Optional Optional
Ensures that versions of the
constraints file are equivalent for
the same design.
For more details on the constraints-related goals, refer to the SpyGlass-Constraints-
Methodology.pdf document.
power activity_check Optional Optional
Analyzes activity for a simulation
testbench
power_pre_reduction Optional
Locates opportunities for power
reduction early in the design flow
power_audit Optional
Performs an audit of the design
to list the key parameters used
in power estimation
power_est_average Optional
Estimates the average power of
the design
power_reduction Optional
Finds power reduction
opportunities in the design
power_est_cycle Optional Optional Optional Optional
Calculates power for each clock
cycle of a simulation
power_best_practice Optional Optional
Checks the RTL and find certain
structures which may be
inefficient from the power
standpoint


voltage_domai power_verif_rtl Optional Optional Optional Optional
n Verifies the proper usage of
power management circuitry in
the earliest possible design
stage
power_verif_postsyn Optional Optional
th
Verifies the proper usage of
power management circuitry
after synthesis.
For more details on the power goals, refer to the SpyGlass-Power-Methodology.pdf
document.
txv_verificat fp_verification Optional
ion Verifies false paths in timing
constraints
mcp_verification Optional
Verifies multicycle paths in
timing constraints by analyzing
the sequential state space
fp_mcp_verification Optional
Verifies false paths and
multicycle paths in timing
constraints
For more details on the Txv goals, refer to the SpyGlass-TXV-Methodology.pdf document.


dft_readiness dft_setup Optional
Specifies the information related
with the clocks to be used as
test clocks and the conditions
necessary to switch the circuit
from function mode to test
mode. From design perspective,
this step profiles design based
on different categories that affect
test and fault coverage.
dft_stuck_at_covera Optional Optional Optional
ge_audit
Profiles a design based on
different categories that impact
its coverage.
dft_best_practices Optional
Checks the design for best
practices to find issues that may
decrease the ATPG
effectiveness
dft_dsm_best_practi Optional
ce
Addresses special needs of
cases such as d-pin
controllability, test clock
domains, and path issues.


dft_latches
Make latches transparent
dft_scan_ready
Make registers scannable
dft_dsm_clocks
Define clocks that will be used
for atspeed testing and any
associated PLLs and
captureATspeed testmode
requirements
dft_test_points Optional
Increase coverage by improving
controllability and observability
dft_block_check Optional Optional Optional
Checks unit level test
requirements at the block level
dft_dsm_transition_ Optional Optional Optional
coverage
Provides an estimate of
transition coverage
dft_dsm_transition_ Optional Optional Optional
coverage_audit
Provides an estimate of
transition coverage
For more details on the DFT goals, refer to the SpyGlass-DFT-Methodology.pdf and
SpyGlass-DSM-Methodology.pdf documents.


Field of Use 2 - IP Block Qualification
Overview
Field of use 2 involves a careful selection of an IP for a given target SoC design. Quality
and completeness of an IP should be determined prior to its introduction into the SoC
integration phase.
In GuideWare, the term IP block refers to a third-party IP block as well as internal
legacy design blocks (from a previously completed and verified design). In both the
cases, the assumption is that the block is stable and complete and is expected to be
validated by provider.
This field of use involves a two-stage flow, as shown in the following figure:
The above flow represents an ecosystem of goals that are grouped to perform specific
task at each stage.
The following sections describe the details of each stage and the goals used in each of
these stages.
IP Audit
This stage involves initial auditing of a legacy or third-party IP block.
It is highly recommended that an IP provider delivers the complete design intent (in the
form of SGDC constraints and waivers) as a part of the IP delivery kit. Such a
mechanism improves the efficiency of IP qualification by the IP acceptance groups as
well as enables ease of use by eventual design groups.
The composition of goals during this stage helps the customer to get a fairly high-level
view of an IP by assessing the following goals:
 Determine the basic characteristics of an IP. For example design statistics, such as
approximate size, hierarchy information, clock and reset information, register count,
blackboxes, and other profiling data.
 Determine basic connectivity and synthesizability checks if an IP is captured as RTL
code.
 Verify the completeness of constraints and other IP inventory data.
IP Risk Analysis
Goals used during this stage target the following goals:
 Highlight potential use risks of an IP. These risks may arise due to issues related with
synthesizability, power, and constraints.
 Highlight non-standard design practices, as well as issues related to the
synchronization of clock domains and correctness of timing exceptions.
 Establish readiness of an IP from testability perspective
 Review issues that might hamper porting of an IP to a new/different silicon
technology

The following table describes GuideWare recommended goals for each of the two stages
of IP block qualification:
NOTE: The qualifier, (RTL) or (netlist), where a goal is applicable only to the RTL or the

netlist version of an IP.
Domain Goal ip_audit ip_risk

lint ip_rtl Optional
Contains essential rules to determine the profile (RTL)
and basic design quality related to design (RTL)
connectivity, simulation/synthesis issues, and
potential structural issues
ip_netlist Optional
Determines the profile and basic design quality (netlist)
related to design connectivity, simulation issues (netlist)
and potential structural issues
audit ip_rtl_profile
Helps in profiling the IP and gathering some
useful statistics for the IP (IP_RTL)
ip_netlist_profile
Helps in profiling the IP as well as gathering
some useful statistics for the IP (IP_Netlist)
datasheet_io_audit Optional
This goal helps in populating data for datasheet
generation. It populates the following
information:
1. Chip-level port registered or not
2. Chip-level port details such as width,
direction, comments, etc.
3. Information related to various pragma's
cdc_prep cdc_setup Optional Optional
Finds clocks and resets in a design
cdc_setup_check Optional Optional
Checks setup correctness and completeness


clock_reset_in clock_reset_integrity Optional
tegrity Ensures that clocks and resets trees are
properly designed, and they are free of glitches,
races, and other hazards
cdc_exhaustive cdc_verifbase_strict
Ensures that all clock domain crossings are
properly synchronized with the pessimistic
parameter values
cdc_verif_strict
Verifies all aspects of clock domain crossings
with the pessimistic parameter settings
constraint_gen gen_sdc Optional
eration Enables the designers to create SDC goals from (netlist)
RTL or netlist


Checks for syntax errors in given SDC file
sdc_coverage
Computes design coverage and reports
uncovered objects
clock_consis
Detects inconsistencies in specification of
clocks, generated clocks, and perform basic
checks on overwritten and conflicting constraints
io_delay
Detects inconsistencies in specification of input/
output delays, clock latency, clock uncertainty
combo_path_check
Checks that all the combinational paths are
constrained correctly
mode_mismatch Optional
Checks consistency in constraints across
modes and corners
structural_exception
Check that timing exceptions specified in a
constraints file are on the paths which are
structurally connected
dft_gated_clock
Ensures that test logic is properly hooked up
and clock gating and power-targets are properly (netlist)
set for power tools. Incorrect test logic hook-up
affect the testability
For more details on the constraints-related goals, refer to the SpyGlass-Constraints-Methodology.pdf
document.


power activity_check
Analyzes activity for a simulation testbench
power_audit
Performs an audit of the design to list the key
parameters that will be used in a power
estimation
power_est_average
Estimates the average power of the design
power_gated_clock Optional
Performs checks on gated clock
power_est_cycle Optional
Calculates power for each clock cycle of a
simulation
power_reduction
Finds power reduction opportunities in the
design
power_verif_rtl
Verifies the proper usage of power management
circuitry in the earliest possible design stage (RTL)
power_best_practice Optional
Checks the RTL and find certain structures
which may be inefficient from the power
standpoint
power_verif_postroute Optional
Verifies the proper usage of power management (Netlist)
circuitry after routing
power_verif_postsynth
Verifies the proper usage of power management
circuitry after synthesis (Netlist)
For more details on the power goals, refer to the SpyGlass-Power-Methodology.pdf document.


txv_verificati fp_verification
on Verifies false paths in timing constraints
mcp_verification
Verifies multicycle paths in timing constraints by
analyzing the sequential state space
fp_mcp_verification
Verifies false paths and multicycle paths in
timing constraints
dft_readiness dft_setup
Ensures valid constraints for defining testclocks,
testmode conditions, and profiles design
providing incremental coverage at each step
dft_stuck_at_coverage_audit
Profiles a design based on different categories
that impact its coverage
dft_best_practice
Checks the designs for best practices even
without testmode setup knowledge
dft_dsm_best_practice
Diagnose transition rule violations
dft_latches
Ensures that latches are transparent when the
capture mode conditions are simulated with
testclocks at their "return to" state

The Datasheet Report

dft_scan_ready
Ensure that as many registers in the RTL as
possible can easily be replaced with scan
equivalents either during logic synthesis or in a
post-synthesis step
dft_dsm_clocks
Facilitates the creation of necessary constraints
to achieve high transition test coverage
dft_test_points
Provides recommendations for adding test-
points to improve controllability/observability of
the IP block
dft_dsm_transition_coverage Optional
Predicts transition test coverage
dft_dsm_transition_coverage_a Optional
udit
Predicts transition test coverage
dft_scan_chain dft_scan_chain
Contains scan chain related rules
(netlist)
For more details on the DFT goals, refer to the SpyGlass-DFT-Methodology.pdf and SpyGlass-DSM-
Methodology.pdf documents.

The Datasheet report highlights design characteristic and qualities of an IP. It provides
summarized information for an IP such as IO details, clock trees, reset trees, power and
test characteristics of an IP, blackbox characteristics, gate count estimates, etc.

Following figure displays a sample Datasheet report:
You can view the Datasheet report to review design characteristics during design review
or as a way of communicating design characteristics during design handoff and IP
sharing.
For details on this report, refer to Atrenta Console User Guide.
Generating the Datasheet Report

In GUI
You can generate the Datasheet report containing data for the current project or the data
for multiple projects and/or batch run dump directories. Based on your requirement,

select any of the following menu options:

 Tools -> Datasheet Report -> Project Report
Select this menu option to generate the Datasheet report for the current project.
 Tools -> Datasheet Report -> Aggregated Report
Select this menu option to generate the Datasheet report containing data for multiple
projects.
In Batch
You can generate the Datasheet report in the batch mode by using the
gen_aggregate_report command-line option, as shown below.
spyglass -gen_aggregate_report datasheet -config_file <cfg-file> |
-project <prj-file> [ -aggregate_reportdir <dir>] [-DEBUG]
[ -LICENSEDEBUG ]

Field of Use 3 - SoC Integration and Implementation
Overview
Field of use 3 involves the verification of an SoC design or a subset of design
(subsystem) that has been integrated by using various blocks. This field of use involves
checks related to inter-block/inter-IP issues and consistency across blocks. In addition, it
ensures that block constraints are consistent with SoC constraints.
In this field of use, the GuideWare methodology recommends a four-stage flow, as
The above flow represents an ecosystem of goals that are grouped to allow relevant and
pertinent verification, and ensure minimization of noise at each stage of SoC integration
and implementation. However, you can customize this flow based on your specific
requirements.
The following sections describe the details of each stage and the goals used in each of
Overview
these stages.
SoC / Subsystem Integration (of RTL Blocks)

During this stage, the SoC/subsystem integration team assembles the RTL blocks and
IPs to form an SoC/subsystem. 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 goals:
 Check the complete design intent captured in individual blocks and their assembly
 Correct various inter-block issues, such as combinational loops and unconnected
ports
 Correct inter-block clock domain synchronization issues
 Identify additional power gating/saving opportunities
 Identify testability modifications
During this stage, the intent is to clean the RTL before production level synthesis
begins.
SoC Preliminary Netlist

During this stage, SoC level RTL is synthesized to produce preliminary structural netlist
of the design by using target technology. 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).
The goals and sub-methodologies recommended for this stage ensure the integrity of the
complete SoC-level netlist from ERC perspective, constraints completeness, correctness
and coherency, high testability, and robust clock domain synchronization.
SoC Pre-layout Netlist

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 target the following goals:

Aligning GuideWare Methodology with Chip Development Phases
 Ensure that the original design intent is not adversely impacted during these
modifications
 Ensure that the intended power savings are achieved in pre-layout netlist
 Ensure that the intended testability is achieved at gate-level netlist
 Ensure the correctness, completeness, and coherency of constraints before beginning
the expensive place-and-route phase
SoC Post-layout Netlist

During this phase, the SoC post layout netlist is closest to silicon.
Final clock buffer insertion, scan chain optimizations, power/voltage island level
shifters and isolation cells are fully represented in this version of the netlist. It is
important to ensure final integrity of this post-layout netlist before tape-out.
At this stage, many timing-closure and verification-related ECOs cause iterations of this
netlist. Timing closure is the most important activity at this stage. Atrenta tools provide
assistance in false path pruning for faster timing closure.
Recommended goals allow the designer to ensure integrity of post-layout netlist during
the ECOs and before the final hand-off for tape-out.
Aligning GuideWare Methodology with Chip Development

Phases
During chip development process, waivers and constraints (SGDC and SDC) generated
in Field of Use 1 and Field of Use 2 can be used in Field of Use 3. The following figure

illustrates the alignment of these fields of use during chip development process:
Existing blocks Field of Use 2

(Legacy, third party IP)
RTL, waivers,
constraints (SGDC, SDC)
SoC Integration
and Implementation
Field of Use 3
RTL, waivers,
constraints (SGDC, SDC)
New RTL Development
Field of Use 1

The following table describes GuideWare recommended goals for each of the four
stages of SoC integration and implementation:
soc_
soc_prel soc_post postlayo
Domain Goal soc_rtl im synth ut
lint soc_rtl
Checks for design connectivity,
simulation/synthesis issues, and
potential structural issues at SoC
level
soc_netlist Optional
Performs netlist integrity checks
such as connectivity, simulation,
and structural issues

soc_
audit soc_rtl_profile
Helps in profiling the SoC and
gathering some useful statistics
for the SoC
soc_netlist_profile Optional
Helps in profiling the SoC and
gathering some useful statistics
for the SoC
rtl_audit Optional
about the RTL data
structure_audit Optional Optional Optional Optional
about the detailed design
structure implied by the RTL
description
datasheet_io_audit Optional Optional Optional Optional
This goal helps in populating data
for datasheet generation. It
populates the following
information:
1. Chip-level port registered or not
2. Chip-level port details such as
width, direction, comments, etc.
3. Information related to various
pragma's
cdc_prep cdc_setup Optional Optional Optional Optional
Finds clocks and resets in a
design
cdc_setup_check Optional Optional Optional Optional
Checks the correctness and
completeness of the setup

soc_
clock_reset power_gated_clock Optional Optional Optional Optional
_integrity Verifies existing gated clocks in
the design
clock_reset_integrit
y
Ensures that clocks and resets
trees are properly designed and
they are free of glitches, races,
and other hazards
cdc_verif cdc_verif_base Optional
synchronized
cdc_verif Optional
domain crossings
cdc_exhaust cdc_verif_base_stric Optional Optional
ive t
synchronized with the pessimistic
parameter values
cdc_verif_strict Optional Optional
domain crossings with the
pessimistic parameter settings
constraint_ gen_sdc Optional
generation Enables the designers to create
SDC goals from RTL or netlist

soc_
Checks for syntax errors in given
SDC file
sdc_coverage
Computes design coverage and
report uncovered objects
clock_consis
Detects inconsistencies in the
specification of clocks, generated (netlist) (netlist)
clocks, and perform basic checks
on overwritten and conflicting
constraints
io_delay
Detects inconsistencies in the
specification of input/output (netlist) (netlist)
delays, clock latency, clock
uncertainty
mode_mismatch Optional
Checks consistency in constraints
across modes and corners

soc_
combo_path_check
Checks that all the combinational
paths are constrained correctly
structural_exception
Checks that timing exceptions
specified in a constraints file are
on paths which are structurally
connected
hierarchical_check Optional
Ensures that constraints are
consistent across block
hierarchies
redundancy_check Optional
Removes any redundancy in the
constraints and perform checks
that might facilitate better
retargeting
dft_gated_clock Optional
Ensures that test logic is properly
hooked up and clock gating and
power-targets are properly set for
the power tools
sdc_equiv Optional
Ensures that versions of
constraints file are equivalent for
the same design

soc_
soc_handoff
Ensures that all steps in this
phase are run together before
netlist handoff and is prescribed
for clean handoff to floor-planning
and P&R.
For more details on the constraints-related goals, refer to the SpyGlass-Constraints-Methodology.pdf
document.

soc_
power activity_check
Analyzes activity for a simulation
testbench
power_pre_reduction Optional
Analyzes the design to find power
savings opportunities
power_audit
Performs an audit of the design to
list the key parameters that will be
used in a power estimation
power_est_average
Estimates the average power of
the design
power_reduction
Finds power reduction
opportunities in the design
power_est_cycle Optional Optional Optional Optional
Calculates power for each clock
cycle of a simulation
power_best_practice Optional
Checks the RTL and find certain
structures which may be
inefficient from the power
standpoint

soc_
voltage_dom power_verif_rtl
ain Verifies proper usage of power
management circuitry in the
earliest possible design stage
power_verif_postsynt
h
Verifies proper usage of power
management circuitry after
synthesis
power_verif_postrout
e
Verifies proper usage of power
management circuitry after
routing
For more details on the power goals, refer to the SpyGlass-Power-Methodology.pdf document.
txv_verific fp_verification
ation Verifies false paths in timing
constraints
mcp_verification
Verifies multicycle paths in timing
constraints by analyzing the
sequential state space
fp_mcp_verification
Verifies false paths and multicycle
paths in timing constraints.

soc_
txv_identif fp_verification
ication Verifies false paths in timing
constraints.
mcp_verification
Verifies multicycle paths in timing
constraints by analyzing the
sequential state space
fp_mcp_verification
Verifies false paths and multicycle
paths in timing constraints
dft_readine dft_setup Optional Optional
ss Ensures that valid constraints for
defining testclocks, testmode
conditions, and profiles design
providing incremental coverage at
each step
dft_stuck_at_coverag Optional Optional Optional
e_audit
Profiles a design based on
different categories that impact its
coverage
dft_best_practice Optional Optional
Checks designs for best practices
even without testmode setup
knowledge
dft_dsm_best_practic Optional
e
Diagnose transition rule violations

soc_
dft_latches Optional Optional
Ensures that latches are
transparent when the capture
mode conditions are simulated
with testclocks at their "return to"
state
dft_scan_ready Optional Optional
Ensures that as many registers in
the RTL as possible can easily be
replaced with scan equivalents
either during logic synthesis or in
a post-synthesis step
dft_dsm_clocks Optional Optional
Defines clocks that will be used
for atspeed testing and any
associated PLLs and
captureATspeed testmode
requirements
dft_test_points Optional Optional
Provides recommendations for
adding test-points to improve
controllability/ observability of the
design
dft_block_check Optional Optional
Checks the consistency of test
signal connections across the
sub-block hierarchical
boundaries, and further ensures
test setup at SoC level satisfies
the test setup requirement of
individual blocks

soc_
dft_dsm_transition_c Optional
overage
Estimates transition coverage
dft_dsm_transition_c Optional
overage_audit
Provides estimation of transition
coverage as different stages
dft_scan_ch dft_scan_chain Optional Optional
ain Verifies the integrity of the scan-
chains in individual blocks, prior to
SoC level scan insertion, and
stitching of block scan chains
For more details on the DFT goals, refer to the SpyGlass-DFT-Methodology.pdf and SpyGlass-DSM-
Methodology.pdf documents.

Customizing Methodology
Introduction
Atrenta Console provides the Methodology Configuration System (MCS) window that
enables you to modify an existing methodology or create your own custom
methodology. For a methodology selected, this window lists all goals of that
methodology, where each goal contains a set of rules.
The Methodology Configuration System Window

To display the Methodology Configuration System window, select the Methodology
Configuration System option from the Tools menu. Alternatively, click the Select
Methodology link under the Select Goal tab. This displays the Select Methodology dialog, as
In the above dialog, click the Click here link to load the currently selected methodology
in the Methodology Configuration System window.
The following figure displays the Methodology Configuration System window:
The above window contains various sections such as the Goals section, Rules section,
Parameters section, etc. The Goals section lists all the goals under each domain. For
example, in the above figure, the lint domain lists four goals: connectivity, simulation,
synthesis, and structure. If the ( ) symbol appears adjacent to a goal name, that goal is
considered as enabled (mandatory). If you want to disable that goal (that is, make it as
optional), click the ( ) symbol adjacent to that goal name. This disables the goal, and
the ( ) symbol appears adjacent to that goal name.
NOTE: When you close the MCS window, the disabled goals do not appear in the available
goal list under the Select Goal tab.
When you select a particular goal, Console lists all the rules of that goal in the Rules
section. You can enable or disable a rule in the same way as it is done for a goal. In
addition, Console also lists all the parameters for the selected goal in the Parameters
section. You can specify value to the parameters in the Value field corresponding to each
parameter name. You can also assign default values to all the parameters by clicking the
Restore Defaults link.

The MCS window enables you to perform the following functions:

 Creating a New Methodology
 Creating a New Sub Methodology
 Creating New Goals
 Importing Goals for a Methodology
 Adding Rules in a Goal
 Modifying Parameter Values for a Goal
Creating a New Methodology

To create a new methodology, select the New Methodology option from the File menu.
This displays the New Methodology dialog, as shown in the following figure:
After specifying the required details in the above dialog, click the OK button. This
displays the new methodology in the MCS window. After creating the new methodology,
you can either create new goals or import existing goals for that methodology. For
details, refer to Creating New Goals and Importing Goals for a Methodology.
NOTE: For more details on creating a new methodology, refer to the Creating a New
Methodology topic of Atrenta Console User Guide.
NOTE: To modify an existing methodology, select the Methodology Properties option
from the File menu. This displays Methodology Properties dialog in which you can make
the required updates for that methodology. For details on modifying an existing

methodology, refer to the Modifying a Methodology topic of Atrenta Console User Guide.
Creating a New Sub Methodology

To add a sub methodology to an already existing methodology, right-click on the
methodology name, and select the Add Sub-Methodology context menu option. This
displays the New Sub-Methodology dialog, as shown in the following figure:
In the above dialog, specify the name and help description for the sub methodology. You
can select the help format as Text Format or HTML Format. If you select the format as
HTML, two additional buttons, Import/Update HTML Description and Delete HTML Help,
appear in the New Sub-Methodology dialog. Click the Import/Update HTML Description
button to import the HTML file containing the help for that sub-methodology.
After specifying the required details in this dialog, click the OK button. This adds the
new sub-methodology in the Goals section under the tree structure of the selected
methodology in the Methodology Configuration System window.
For more details on creating a new sub methodology, refer to the Adding a
Sub-Methodology topic of Atrenta Console User Guide.
NOTE: Please note the following points:
 To modify an existing sub methodology, right-click on that sub methodology name, and select
the Sub-Methodology Properties context menu option. This displays the Sub-Methodology
Properties dialog in which you can make the required updates.
 To delete a sub-methodology, right-click the methodology, and select the Delete Sub-
Methodology context menu option.

Creating New Goals

To create a goal for a methodology (or a sub methodology), perform any of the
following:
 Right-click the methodology, and select the Add New Goal context menu option.
 Select the Add New Goal option from the Edit menu
 Click the Add New Goal option on the MCS window toolbar.
 Use the <Ctrl> + <G> key combination on the keyboard.
On performing any of the above steps, the New Goal dialog appears, as shown in the
following figure:
After specifying the required details in the above dialog, click the OK button. This adds
the new goal in the Goals section under the tree structure of the selected methodology of
the Methodology Configuration System window.
By default, the newly added goal is enabled for the methodology. To disable a goal,
click the ( ) symbol adjacent to the goal name. This disables that goal, and the ( )
symbol appears adjacent to that goal name.
After adding a goal for a methodology, you can rules for that goal. See Adding Rules in
a Goal for details.

NOTE: To modify an existing goal, right-click on the goal name, and select the Goal
Properties context menu option. This displays the Goal Properties dialog in which you can
perform the required updates.
Importing Goals for a Methodology

To import a goal for a methodology, perform any of the following:
 Right-click the methodology, and select the Import Goal(s) context menu option.
 Select the Import Goal(s) option from the Edit menu.
 Click the Import Goal(s) link in the MCS window toolbar.
On performing any of the above steps, Atrenta Console displays the Import Goal(s)
dialog, as shown in the following figure:
In the above dialog, specify the path of the directory in the Look In text field where the
goals are located. After locating the goal(s), select the goal and click the Add button to
add that goal to the methodology. To add all the goals present in the directory, click the
Add All button. You can also import sgs files along with the goal(s) by selecting the
Import sgs file(s) option.
Once you have added the required goals, click the OK button. This adds the goal(s) to
the selected methodology.
Adding Rules in a Goal

To add rules in a goal, perform the following steps:

1. Search for the specific rules, which you want to add in a goal, in the Search section of
the MCS window. For details on searching rules, refer to the Searching Rules topic.
2. Select the required rules to be added in a goal from the filtered rule list obtained after
the search operation. You can select multiple rules by pressing the <Ctrl> key and
clicking the required rules.
3. Right-click on the selected rule(s), and select the Add Rule(s) to Goal context menu
option. Alternatively, you can select the Add Rule(s) to Goal option in the Search
section.
When you perform the above steps, Atrenta Console displays the selected rules for that
goal in the Rule List section of the MCS window.
Searching Rules
You can search for the required rule(s), which you want to add for a goal, under the
Search section of the MCS window, as shown in the following figure:
In the above section, when you specify the search text in the Search textbox and click
the Go link, Atrenta Console displays all those rules (in spreadsheet format) that
matches the specified search criteria. By default, Atrenta Console searches all the rules
in SpyGlass. However, to confine the search among the rules of only the selected
methodology, select the Current Methodology option from the In drop-down list.
Modifying Parameter Values for a Goal

When you select a goal, the parameters related to that goal are displayed in the

Parameter(s) section of the MCS window. By default, Atrenta Console displays only the
commonly-used parameters in this section. However, you can view the complete list of
parameters by selecting the All Parameters option from the Show drop-down menu.
You can assign values to the parameters in the Value field in the Parameter(s) section.
You can also restore the default values of all the parameter by clicking the Restore
Defaults option in the Parameter(s) section.

Appendix
Specifying Hierarchical Waivers

While integrating blocks into the final SoC, Console provides a capability to the
chip-level designers to use all the waivers of a block specified by the block-level
designer. This can be implemented by using the the -import option of the waive
constraint, as shown below:
waive –import <block-name> <block-waive-file>
The above command imports the waiver file, <block-waiver-file>, of the block,
<block-name>.
You can specify waivers for individual blocks separately in the top-level chip by
specifying multiple waive -import constraint specifications. You can also specify
multiple waiver files for a given block in multiple waive -import constraint
specifications.
Consider the following example in which B1 and B2 are the two blocks inside the
top-level chip, and B1.swl and B2.swl are the waiver files applied to these blocks,
respectively:
waive –import B1 B1.swl
waive –import B2 B2.swl
Optional Rule Selection Guide for GuideWare Basic

This section provides a quick overview of optional rules available in GuideWare basic
methodology, BaseSpyGlass. You are recommended to review this list, and select
applicable rules in the specified templates.
General Functional/Simulation Issues

The following table describes the basic checks for general functional/simulation issues
and the corresponding recommended optional rule(s) to implement those checks:
Checks Suitable Optional Rule

To check that no tasks are called in combinational blocks simulation/W428
If you are concerned about ‘x’ or ‘z’ extension of constants simulation/W342 or simulation/W343
or simulation/W491
To check for race conditions simulation/sim_race01, simulation/
sim_race03, simulation/sim_race07
General Structural Issues

The following table describes the basic checks for general structural issues and the
corresponding recommended optional rule(s) to implement those checks:

To check for an assignment to a supply net connectivity/W317
To check for mux select lines tied constant structure/MuxSelConst
Check to ensure that sequential and combinational parts of structure/STARC-2.11.3.1
FSMs are separated
To check that divisors for “/” and “%” are a power of 2 structure/W339b
If you are concerned about long paths in your design audit/LogicDepth
To check for gates in the reset tree clock_reset_integrity/Reset_check02
To check for disabled gates connectivity/DisabledAnd,
connectivity/DisabledOr
Assignment/Connection Mismatches
The following table describes the basic checks for assignment/connection mismatches
and the corresponding recommended optional rule(s) to implement those checks:

To check for LHS versus RHS assignment width connectivity/W164a, connectivity/
mismatches W164b
To check for instance port connection width mismatches connectivity/W110


To check for assignment overflows simulation/AsgnOverflow-ML
Tristates
The following table describes the basic checks for tristates and the corresponding
recommended optional rule(s) to implement those checks:

To check for tristated busses structure/UseMuxBusses
Check to have a limit on how many drivers a tristate can have structure/STARC-2.5.1.4
To check that logic does not exist in tristated enable structure/STARC-2.5.1.2
conditions
If you concerned about multiply-driven non-tristate nets simulation/STARC-2.5.1.5a
Tto check that tristated gate enables are not a constant structure/TristateConst
casex/casez Constructs
The following table describes the basic checks for casex/casez constructs and the

To check whether you have a policy of not using casex/casez structure/DisallowCaseX, structure/
constructs DisallowCaseZ
To check whether you have a policy of not using signals in simulation/NoSignCaseX-ML
casex/casez constructs
To ensure that casez statements do not use ‘x’ structure/DisallowXInCaseZ
Tasks and Functions

The following table describes the basic checks related with tasks and functions and the

To check for the use of global variables in functions/tasks simulation/W425, simulation/W427


To check for unused tasks/procedures simulation/W190
Flip-flops, Latches, and Associated Signals

The following table describes the basic checks related with flip-flops, latches, and
associated signals and the corresponding recommended optional rule(s) to implement
those checks:

To check for blocking assignments to latch outputs simulation/W336L
To check for cases in which you want to avoid flip-flops with structure/Async_04
both asynchronous set and reset
To check for cases in which you need to avoid latches with structure/LatchReset
both asynchronous and synchronous resets
To check for latches driven by both edges of a clock structure/ClockEdges
To check for flip-flop/latch data pins driven by constants structure/FlopDataConstant,
structure/LatchDataConstant
To check if latch enable pins are driven by constants structure/LatchEnableConstant
To check that gated/internally generated resets are not used structure/GatedReset
to reset latches
To check that gated/internally generated clocks are not used structure/LatchGatedClock
to drive latches
Tto check that asynchronous reset signals are not used as structure/STARC-1.3.1.3
non-reset/synchronous signals
To check that flip-flop clock signals are not used as non-clock structure/STARC-1.4.3.4
signals
Check to ensure that an RS latch is not created by using structure/STARC-1.2.1.2
primitive cells
Cheks to avoid combinational loops containing latches structure/STARC02-2.4.1.4
Potentially Unsynthesizable Constructs

The following table describes the basic checks related with potentially unsynthesizable

constructs and the corresponding recommended optional rule(s) to implement those

checks:

To check for allocator expressions synthesis/AllocExpr
To check for arrays that are defined by using an enumeration synthesis/ArrayEnumIndex
type as index
To check for unsynthesizable clocking styles synthesis/ClockStyle
Too check for deferred constants synthesis/DeferConst
To check for disconnect specifications synthesis/DisconnSpec
To check that the left operand of exponentiation operators are synthesis/ExponOp
not static and not a power of 2
To check for WAIT statements in a FOR-loop synthesis/ForLoopWait
To check for incomplete type declarations synthesis/IncompleteType
To check for non-integer generic declarations synthesis/IntGeneric
To check for linkage ports synthesis/LinkagePort
To ensure that loop range bounds are locally or globally static synthesis/LoopBound
To check for multi-dimensional arrays synthesis/MultiDimArr
To check for multiple wait statements that use the same clock synthesis/MultipleWait
expression
To check for timeout expressions in wait statements synthesis/NoTimeOut
To check for unconstrained ports synthesis/PortType
To check for unsynthesizable predefined attributes synthesis/PreDefAttr
To check for user-defined attributes synthesis/UserDefAttr
To check for resolution functions synthesis/ResFunction
To check for initial values (this is ignored by some synthesis synthesis/SigVarInit, synthesis/W430
tools) or initial statements
To check for unsynthesizable IF statements synthesis/SynthIfStmt
To check for unsynthesizable time statements synthesis/W182c
To check for tri0, tri1, or trireg statements synthesis/W182g, synthesis/W182h,
synthesis/W182k
To check for unsynthesizable switches (cmos, pmos, nmos)? synthesis/W182n


Do you need to check for PLI tasks/functions synthesis/W213
To check for hierarchical references synthesis/W239
To check for the use of the disable statement synthesis/W250
To check for real variables synthesis/W294
To check for unrecognized synthesis directives synthesis/W464
To check for case statements marked full_case with default synthesis/W551
clauses
To check for while statements used in subprograms synthesis/WhileInSubProg

GuideWare UserGuide PDF

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

GuideWare UserGuide PDF

Uploaded by

Copyright:

Available Formats

SpyGlass®-GuideWare

©Copyright 2006-2010 Atrenta, Inc. All rights reserved.

This document is protected by copyright and distributed under licenses

DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR

Atrenta, SpyGlass, and Predictive Analysis are registered trademarks of

Printed in the United States of America.

Early Design Closure ..................................................................................................... 7

Introducing Atrenta Console ....................................................................................... 17

Version 4.4.1 October 2010 iii

SpyGlass Built-in Checks .................................................................................................................27

Setting up the Design in Atrenta Console ..................................................................29

Field of Use 1 - New RTL Development.......................................................................45

iv October 2010 Version 4.4.1

Field of Use 2 - IP Block Qualification ........................................................................ 57

Field of Use 3 - SoC Integration and Implementation ............................................... 67

Version 4.4.1 October 2010 v

vi October 2010 Version 4.4.1

Challenges in the Development of SoC Designs

Figure 1: Design development flow

New RTL block/subsystem development

Third party/internal legacy IP selection

 Challenges Involved During SoC Integration

Challenges Involved During New RTL Block/Subsystem Development

Initial Block/Sub-System RTL Development

Detailed Block/Sub-System RTL Development

Final Block/Sub-System RTL Design and Handoff

8 October 2010 Version 4.4.1

 Providing closure on various implementation issues such as synthesizability, timing,

Challenges Involved in the Selection of Third Party or Internal Legacy IP

Challenges Involved During SoC Integration

Version 4.4.1 October 2010 9

Early Design Closure

Timing-related issues Timing

10 October 2010 Version 4.4.1

Version 4.4.1 October 2010 11

 Style and related checks

Introducing GuideWare Reference Methodology

12 October 2010 Version 4.4.1

 New RTL Block Development

New RTL block/subsystem development Field of use 1

Third party/internal legacy IP selection

SoC RTL/Gates Field of use 3

SoC logic synthesis

SoC scan, STA, power optimization

SoC place and route

New RTL Block Development

Version 4.4.1 October 2010 13

 No assumptions are made about the existing behavior or stability.

14 October 2010 Version 4.4.1

SoC Integration and Implementation

Identifying Problems in Current Approaches to Early Design Closure

Version 4.4.1 October 2010 15

systems lack the platform-level advantage traversing across disciplines. A single

GuideWare for Early Design Closure

16 October 2010 Version 4.4.1

Methodology Used by Atrenta Console

Invoking Atrenta Console

Invoking Atrenta Console Graphical User Interface

Following figure displays the Atrenta Console GUI:

Invoking Atrenta Console in Batch Mode

18 October 2010 Version 4.4.1

The Project File

Performing SpyGlass Analysis in Atrenta Console