SpyGlass®-GuideWare User Guide - linkedic.cn · SpyGlass®-GuideWare User Guide Early Design Closure Introducing SpyGlass Atrenta® SpyGlass® is a powerful and extendible tool for

SpyGlass®-GuideWare User Guide

Version 4.4.1

October 2010

Atrenta, Inc.2077 Gateway Place, Suite 300San Jose, California 951101-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.

Table of Contents


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

Challenges in the Development of SoC Designs..................................................................................7Challenges Involved During New RTL Block/Subsystem Development.............................................8

Initial Block/Sub-System RTL Development ...............................................................................8Detailed Block/Sub-System RTL Development...........................................................................8Final Block/Sub-System RTL Design and Handoff .....................................................................8

Challenges Involved in the Selection of Third Party or Internal Legacy IP.........................................9Challenges Involved During SoC Integration .....................................................................................9

Early Design Closure ............................................................................................................................10Introducing SpyGlass ....................................................................................................................... 11

SpyGlass Features....................................................................................................................11

Introducing GuideWare Reference Methodology ...............................................................................12Fields of Use ....................................................................................................................................12

New RTL Block Development ...................................................................................................13IP Block Qualification ................................................................................................................14SoC Integration and Implementation.........................................................................................15

Identifying Problems in Current Approaches to Early Design Closure .............................................15GuideWare for Early Design Closure ...............................................................................................16

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

Overview.................................................................................................................................................17Methodology Used by Atrenta Console............................................................................................17

Invoking Atrenta Console .....................................................................................................................17Invoking Atrenta Console Graphical User Interface .........................................................................17Invoking Atrenta Console in Batch Mode .........................................................................................18

The Project File......................................................................................................................................19

Performing SpyGlass Analysis in Atrenta Console ...........................................................................19Setting up a Design (Design Setup) .................................................................................................20Selecting a Goal (Goal Setup & Run)...............................................................................................21Analyzing 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.................................................................................................................................39When to Apply Waivers ....................................................................................................................40Specifying Waivers ...........................................................................................................................41Using the waive Constraint...............................................................................................................41Using Embedded SpyGlass Waiver Pragmas ..................................................................................42

Handling Memories................................................................................................................................43Limiting the Analysis of Memories ....................................................................................................43Using the Memory Reduction Feature..............................................................................................43

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

Overview.................................................................................................................................................45Initial RTL Development ...................................................................................................................46Detailed RTL Development ..............................................................................................................46RTL Handoff .....................................................................................................................................46IP 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.................................................................................................................................................57IP Audit.............................................................................................................................................58IP Risk Analysis................................................................................................................................58

Goals for Field of Use 2 ........................................................................................................................58

The Datasheet Report ...........................................................................................................................64Generating the Datasheet Report ....................................................................................................65

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

Overview.................................................................................................................................................67SoC / Subsystem Integration (of RTL Blocks) ..................................................................................68SoC Preliminary Netlist ....................................................................................................................68SoC Pre-layout Netlist ......................................................................................................................68SoC 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..............................................................................81Creating a New Methodology ...........................................................................................................83Creating a New Sub Methodology....................................................................................................84Creating New Goals .........................................................................................................................85Importing Goals for a Methodology ..................................................................................................86Adding Rules in a Goal.....................................................................................................................86

Searching Rules........................................................................................................................87Modifying 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 .........................................................................89General Functional/Simulation Issues ..............................................................................................89General Structural Issues .................................................................................................................90Assignment/Connection Mismatches ...............................................................................................90Tristates............................................................................................................................................91casex/casez Constructs....................................................................................................................91Tasks and Functions.........................................................................................................................91Flip-flops, Latches, and Associated Signals .....................................................................................92Potentially Unsynthesizable Constructs ...........................................................................................92

vi October 2010 Version 4.4.1

Early Design Closure

Challenges in the Development of SoC DesignsThe 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

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

VALIDATION

VE

RIF

ICA

TIO

N

Architecture and Micro Architecture

Block Budget and Targets/Constraints

New RTL block/subsystem development

Third party/internal legacy IP selection

SoC Integration

SpyGlass®-GuideWare User Guide ©Copyright 2001-2010 Atrenta, Inc. All rights reserved.

SpyGlass®-GuideWare User GuideChallenges in the Development of SoC Designs

Challenges Involved During SoC Integration

Challenges Involved During New RTL Block/Subsystem DevelopmentIn 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 DevelopmentThe 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 DevelopmentThe design team faces the following challenges during this stage:

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 HandoffThe design team faces the following challenges during this stage:

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

SpyGlass®-GuideWare User GuideChallenges in the Development of SoC Designs

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 IntegrationDuring 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

SpyGlass®-GuideWare User GuideEarly Design Closure

Early Design ClosureIssues 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

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.

EarlyDesign

Test

Power

Timing

P&R

RTL

Spec

Iterativecorrection

Synthesis

SDC

Simulation-synthesismismatch

Low fault coverage

Power-related issues

Timing-related issues

Routing congestionArea limitation

RTL-SDC conflicts

Cost

Schedule

Performance

Long iteration result innegative impact on:

Divergent process...getting worse as technology advances


SpyGlass®-GuideWare User GuideEarly Design Closure

Introducing SpyGlassAtrenta® 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 FeaturesYou 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


SpyGlass®-GuideWare User GuideIntroducing 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.

Introducing GuideWare Reference MethodologyAs 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 UseIn 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

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 DevelopmentThis field of use has the following characteristics:

RTL being developed is mostly assumed to be new.

VALIDATION

VE

RIF

ICA

TIO

N

Architecture and Micro Architecture

Block Budget and Targets/Constraints

New RTL block/subsystem development

Third party/internal legacy IP selection

SoC RTL/Gates

SoC logic synthesis

SoC scan, STA, power optimization

SoC place and route

TAPE OUT

SoC

IN

TE

GR

AT

ION

Field of use 1

Field of use 2

Field of use 3



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 QualificationThis 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 ImplementationThe 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 ClosureCurrent 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 ClosureDesigns 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

OverviewAtrenta 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 ConsoleBy 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 InterfaceTo invoke Atrenta Console GUI, specify any of the following commands:

spyglass -gui=console

spyglass

spyglass -gui


SpyGlass®-GuideWare User GuideInvoking 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 ModeBesides 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


SpyGlass®-GuideWare User GuideThe 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 FileAtrenta 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 ConsoleAtrenta 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:


SpyGlass®-GuideWare User GuidePerforming SpyGlass Analysis in Atrenta Console

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


SpyGlass®-GuideWare User GuideMessages 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.

Messages Flagged During the Design Read-In ProcessDuring the design read-in process, SpyGlass flags different types of issues in your



design, as mentioned in the following table:

SpyGlass Built-in ChecksWhile 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:

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 Design Read-In Methodology Guide.

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 Design Read-In Methodology Guide.

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.

Message Type Message Prefix

Syntax errors STX_

Language warnings WRN_

Synthesis errors and warnings SYNTH_

Elaboration errors and warnings during elaboration

ELAB_

LEF file parsing messages LEFSTX_ and LEFWRN_

DEF file parsing messages DEFSTX_ and DEFWRN_



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.

SDC file parsing messages SDC_

PLIB file parsing messages PLIBSTX_ and PLIBWRN_

Constraints-specific checks SGDC_, checkSGDC_, SGDCSTX_, SGDCWRN_, and SGDCINFO_

Message Type Message Prefix


Setting up the Design in Atrenta Console

IntroductionThis 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 OperationsAtrenta® 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:


SpyGlass®-GuideWare User GuideInputs to SpyGlass

SpyGlass Functional Model

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 SpyGlassSpyGlass 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

• VHDL 1987

All SpyGlass capabilities

Verilog • IEEE Standard 1364-2001 (v2k)

• Verilog 95

All SpyGlass capabilities

System Verilog IEEE Standard 1800-2005 All SpyGlass capabilities

SpyGlass

Source Files

Library Files(Optional)

Command-line Options

Violation Database

Schematic Data

Console GUI

Reports (.rpt)Goals/Rules

Project file (.prj)

SGDC File(Optional)


SpyGlass®-GuideWare User GuideManaging the Design Hierarchy

Managing the Design HierarchySpyGlass 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

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

Data Version Applicable To



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:

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

Command Result

set_option top DSP_block set_option stop DSP_A

Only the design unit, DSP_B, is considered for SpyGlass analysis.

set_option top POWER_CONTROLLER

set_option stop Block1

The design units, POWER_inst, 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.


SpyGlass®-GuideWare User GuideSpyGlass 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 ConstraintsSpyGlass 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.


SpyGlass®-GuideWare User GuideSpyGlass Design Constraints

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


SpyGlass®-GuideWare User GuideUsing Parameters/Generics and Macros

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 MacrosConsole 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)

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

Constraint Purpose


SpyGlass®-GuideWare User GuideCompiling 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 FilesAtrenta 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


SpyGlass®-GuideWare User GuideHandling DesignWare Components

Handling DesignWare ComponentsIf 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 FeatureAtrenta 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


SpyGlass®-GuideWare User GuideWaiving 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 MessagesDuring 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:



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 WaiversThe 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.



Specifying WaiversWaivers 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 ConstraintUse 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 ##############



##### 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 PragmasYou 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


SpyGlass®-GuideWare User GuideHandling 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 MemoriesSpyGlass provides the following features to handle memories in your design:

Limiting the Analysis of Memories

Using the Memory Reduction Feature

Limiting the Analysis of MemoriesWhen 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 FeatureIt 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


SpyGlass®-GuideWare User GuideHandling 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

OverviewField 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 shown in the following figure:

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.


SpyGlass®-GuideWare User GuideOverview

Initial RTL DevelopmentDuring 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 DevelopmentDuring 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 HandoffThis 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


SpyGlass®-GuideWare User GuideGoals 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 HandoffThis 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.

Goals for Field of Use 1The following table describes GuideWare recommended goals for each of the four



stages of the new RTL development.

Domain Goalinitial_ rtl

detailed_rtl

rtl_handoff

ip_handoff

lint connectivity

Checks the design for basic connectivity issues

simulation

Checks the design for basic simulation issues

synthesis

Checks the design for basic 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

Provides summary information about the RTL data.

Optional Optional Optional Optional

structure_audit

Provides summary information about the detailed design structure implied by the RTL description


datasheet_io_audit

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

Find the clocks and resets in a design


cdc_setup_check

Checks setup correctness and completeness

Optional Optional Optional


detailed_rtl

rtl_handoff

ip_handoff



clock_reset_integrity

power_gated_clock

Performs checks on gated clock



Performs sanity checks for clocks and resets

Optional Optional

cdc_verif cdc_verif_base

Ensures all clock domain crossings are properly synchronized

Optional Optional

cdc_verif

Verifies all aspects of clock domain crossings

Optional Optional

cdc_exhaustive

cdc_verif_base_strict

Implements clock domain crossing metastability checks with pessimistic approach

Optional Optional

cdc_verif_strict

Implements clock domain crossing verification with pessimistic approach

Optional Optional

For more details on the clock goals, refer to the SpyGlass-CDC-Methodology.pdf document.

constraint_generation

gen_sdc

Enables the designers to create SDC goals from RTL or netlist

Optional


detailed_rtl

rtl_handoff

ip_handoff



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

Cleans delay constraints

Optional

combo_path_check

Implements constraint validation for combinational path

Optional

structural_exception

Checks that timing exceptions specified in a constraints file are on paths which are structurally connected

hierarchical_check

Ensures that constraints are consistent across block hierarchies


redundancy_check

Removes any redundancy in the constraints, and perform checks that might facilitate better retargeting



detailed_rtl

rtl_handoff

ip_handoff



sdc_equiv

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

Analyzes activity for a simulation testbench

Optional Optional

power_pre_reduction

Locates opportunities for power reduction early in the design flow

Optional

power_audit

Performs an audit of the design to list the key parameters used in power estimation

Optional

power_est_average

Estimates the average power of the design

Optional

power_reduction

Finds power reduction opportunities in the design

Optional

power_est_cycle

Calculates power for each clock cycle of a simulation


power_best_practice

Checks the RTL and find certain structures which may be inefficient from the power standpoint

Optional Optional


detailed_rtl

rtl_handoff

ip_handoff



voltage_domain

power_verif_rtl

Verifies the proper usage of power management circuitry in the earliest possible design stage


power_verif_postsynth

Verifies the proper usage of power management circuitry after synthesis.

Optional Optional

For more details on the power goals, refer to the SpyGlass-Power-Methodology.pdf document.

txv_verification

fp_verification

Verifies false paths in timing constraints

Optional

mcp_verification

Verifies multicycle paths in timing constraints by analyzing the sequential state space

Optional

fp_mcp_verification

Verifies false paths and multicycle paths in timing constraints

Optional

For more details on the Txv goals, refer to the SpyGlass-TXV-Methodology.pdf document.


detailed_rtl

rtl_handoff

ip_handoff



dft_readiness dft_setup

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.

Optional

dft_stuck_at_coverage_audit

Profiles a design based on different categories that impact its coverage.


dft_best_practices

Checks the design for best practices to find issues that may decrease the ATPG effectiveness

Optional

dft_dsm_best_practice

Addresses special needs of cases such as d-pin controllability, test clock domains, and path issues.

Optional


detailed_rtl

rtl_handoff

ip_handoff



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

Increase coverage by improving controllability and observability

Optional

dft_block_check

Checks unit level test requirements at the block level


dft_dsm_transition_coverage

Provides an estimate of transition coverage


dft_dsm_transition_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.


detailed_rtl

rtl_handoff

ip_handoff




Field of Use 2 - IP Block Qualification

OverviewField 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 AuditThis 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 AnalysisGoals 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

Goals for Field of Use 2The 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

Contains essential rules to determine the profile and basic design quality related to design connectivity, simulation/synthesis issues, and potential structural issues

Optional

(RTL)(RTL)

ip_netlist

Determines the profile and basic design quality related to design connectivity, simulation issues and potential structural issues

Optional

(netlist)(netlist)

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

cdc_prep cdc_setup

Finds clocks and resets in a design

Optional Optional

cdc_setup_check

Checks setup correctness and completeness

Optional Optional





Ensures that clocks and resets trees are properly designed, and they are free of glitches, races, and other hazards

Optional

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

For more details on the clock goals, refer to the SpyGlass-CDC-Methodology.pdf document.

constraint_generation

gen_sdc


Optional

(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

Checks consistency in constraints across modes and corners

Optional

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 set for power tools. Incorrect test logic hook-up affect the testability

(netlist)






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

Performs checks on gated clock

Optional

power_est_cycle


Optional

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

power_verif_postroute

Verifies the proper usage of power management circuitry after routing

Optional

(Netlist)

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_verification

fp_verification

Verifies false paths in timing constraints

mcp_verification

Verifies multicycle paths in timing constraints by analyzing the sequential state space

fp_mcp_verification


For more details on the Txv goals, refer to the SpyGlass-TXV-Methodology.pdf document.

dft_readiness dft_setup

Ensures valid constraints for defining testclocks, testmode conditions, and profiles design providing incremental coverage at each step


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


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



SpyGlass®-GuideWare User GuideThe Datasheet Report

The Datasheet ReportThe 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.

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


Predicts transition test coverage

Optional


Predicts transition test coverage

Optional

dft_scan_chain dft_scan_chain

Contains scan chain related rules(netlist)





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

OverviewField 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 shown in the following figure:

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


SpyGlass®-GuideWare User GuideOverview

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 NetlistDuring 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 NetlistDuring 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:


SpyGlass®-GuideWare User GuideAligning 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 NetlistDuring 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:

Goals for Field of Use 3The following table describes GuideWare recommended goals for each of the four stages of SoC integration and implementation:

Domain Goal soc_rtlsoc_prelim

soc_postsynth

soc_ postlayout

lint soc_rtl

Checks for design connectivity, simulation/synthesis issues, and potential structural issues at SoC levelsoc_netlist

Performs netlist integrity checks such as connectivity, simulation, and structural issues

Optional

Existing blocks (Legacy, third party IP)

New RTL Development

Field of Use 1

Field of Use 2

RTL, waivers, constraints (SGDC, SDC)

RTL, waivers, constraints (SGDC, SDC)

SoC Integrationand Implementation

Field of Use 3



audit soc_rtl_profile

Helps in profiling the SoC and gathering some useful statistics for the SoCsoc_netlist_profile

Helps in profiling the SoC and gathering some useful statistics for the SoC

Optional

rtl_audit

Provides summary information about the RTL data

Optional

structure_audit

Provides summary information about the detailed design structure implied by the RTL description


datasheet_io_audit






cdc_prep cdc_setup

Finds clocks and resets in a design


cdc_setup_check

Checks the correctness and completeness of the setup



soc_postsynth

soc_ postlayout




power_gated_clock

Verifies existing gated clocks in the design



Ensures that clocks and resets trees are properly designed and they are free of glitches, races, and other hazards

cdc_verif cdc_verif_base

Ensures all clock domain crossings are properly synchronized

Optional

cdc_verif

Verifies all aspects of clock domain crossings

Optional

cdc_exhaustive

cdc_verif_base_strict

Ensures all clock domain crossings are properly synchronized with the pessimistic parameter values

Optional Optional

cdc_verif_strict

Verifies all aspects of clock domain crossings with the pessimistic parameter settings

Optional Optional

For more details on the clock goals, refer to the SpyGlass-CDC-Methodology.pdf document.constraint_generation

gen_sdc


Optional


soc_postsynth

soc_ postlayout




Checks for syntax errors in given SDC filesdc_coverage

Computes design coverage and report uncovered objectsclock_consis

Detects inconsistencies in the specification of clocks, generated clocks, and perform basic checks on overwritten and conflicting constraints

(netlist) (netlist)

io_delay

Detects inconsistencies in the specification of input/output delays, clock latency, clock uncertainty

(netlist) (netlist)

mode_mismatch

Checks consistency in constraints across modes and corners

Optional


soc_postsynth

soc_ postlayout



combo_path_check

Checks that all the combinational paths are constrained correctlystructural_exception

Checks that timing exceptions specified in a constraints file are on paths which are structurally connectedhierarchical_check

Ensures that constraints are consistent across block hierarchies

Optional

redundancy_check

Removes any redundancy in the constraints and perform checks that might facilitate better retargeting

Optional

dft_gated_clock

Ensures that test logic is properly hooked up and clock gating and power-targets are properly set for the power tools

Optional

sdc_equiv

Ensures that versions of constraints file are equivalent for the same design

Optional


soc_postsynth

soc_ postlayout



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.



soc_postsynth

soc_ postlayout




Analyzes activity for a simulation testbenchpower_pre_reduction

Analyzes the design to find power savings opportunities

Optional

power_audit

Performs an audit of the design to list the key parameters that will be used in a power estimationpower_est_average

Estimates the average power of the designpower_reduction

Finds power reduction opportunities in the designpower_est_cycle



power_best_practice


Optional


soc_postsynth

soc_ postlayout



voltage_domain

power_verif_rtl

Verifies proper usage of power management circuitry in the earliest possible design stagepower_verif_postsynth

Verifies proper usage of power management circuitry after synthesispower_verif_postroute

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_verification

fp_verification

Verifies false paths in timing constraintsmcp_verification

Verifies multicycle paths in timing constraints by analyzing the sequential state spacefp_mcp_verification

Verifies false paths and multicycle paths in timing constraints.


soc_postsynth

soc_ postlayout



txv_identification

fp_verification

Verifies false paths in timing constraints. mcp_verification

Verifies multicycle paths in timing constraints by analyzing the sequential state spacefp_mcp_verification


For more details on the Txv goals, refer to the SpyGlass-TXV-Methodology.pdf document.dft_readiness

dft_setup

Ensures that valid constraints for defining testclocks, testmode conditions, and profiles design providing incremental coverage at each step

Optional Optional


Profiles a design based on different categories that impact its coverage


dft_best_practice

Checks designs for best practices even without testmode setup knowledge

Optional Optional


Diagnose transition rule violations

Optional


soc_postsynth

soc_ postlayout



dft_latches

Ensures that latches are transparent when the capture mode conditions are simulated with testclocks at their "return to" state

Optional Optional

dft_scan_ready

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

Optional Optional

dft_dsm_clocks

Defines clocks that will be used for atspeed testing and any associated PLLs and captureATspeed testmode requirements

Optional Optional

dft_test_points

Provides recommendations for adding test-points to improve controllability/ observability of the design

Optional Optional

dft_block_check

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

Optional Optional


soc_postsynth

soc_ postlayout




Estimates transition coverage

Optional


Provides estimation of transition coverage as different stages

Optional

dft_scan_chain

dft_scan_chain

Verifies the integrity of the scan-chains in individual blocks, prior to SoC level scan insertion, and stitching of block scan chains

Optional Optional



soc_postsynth

soc_ postlayout


Customizing Methodology

IntroductionAtrenta 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 WindowTo 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 shown in the following figure:

In the above dialog, click the Click here link to load the currently selected methodology in the Methodology Configuration System window.


SpyGlass®-GuideWare User GuideThe 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 MethodologyTo 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 MethodologyTo 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 GoalsTo 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 MethodologyTo 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 GoalTo 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 RulesYou 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 GoalWhen 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 WaiversWhile 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.swlwaive –import B2 B2.swl

Optional Rule Selection Guide for GuideWare BasicThis 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 IssuesThe following table describes the basic checks for general functional/simulation issues


SpyGlass®-GuideWare User GuideOptional Rule Selection Guide for GuideWare Basic

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

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

Assignment/Connection MismatchesThe following table describes the basic checks for assignment/connection mismatches 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


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 FSMs are separated

structure/STARC-2.11.3.1

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


To check for LHS versus RHS assignment width mismatches

connectivity/W164a, connectivity/W164b

To check for instance port connection width mismatches connectivity/W110



TristatesThe following table describes the basic checks for tristates and the corresponding recommended optional rule(s) to implement those checks:

casex/casez ConstructsThe following table describes the basic checks for casex/casez constructs and the corresponding recommended optional rule(s) to implement those checks:

Tasks and FunctionsThe following table describes the basic checks related with tasks and functions and the corresponding recommended optional rule(s) to implement those checks:

To check for assignment overflows simulation/AsgnOverflow-ML


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 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


To check whether you have a policy of not using casex/casez constructs

structure/DisallowCaseX, structure/DisallowCaseZ

To check whether you have a policy of not using signals in casex/casez constructs

simulation/NoSignCaseX-ML

To ensure that casez statements do not use ‘x’ structure/DisallowXInCaseZ


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




Flip-flops, Latches, and Associated SignalsThe 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:

Potentially Unsynthesizable ConstructsThe following table describes the basic checks related with potentially unsynthesizable

To check for unused tasks/procedures simulation/W190


To check for blocking assignments to latch outputs simulation/W336L

To check for cases in which you want to avoid flip-flops with both asynchronous set and reset

structure/Async_04

To check for cases in which you need to avoid latches with both asynchronous and synchronous resets

structure/LatchReset

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 to reset latches

structure/GatedReset

To check that gated/internally generated clocks are not used to drive latches

structure/LatchGatedClock

Tto check that asynchronous reset signals are not used as non-reset/synchronous signals


To check that flip-flop clock signals are not used as non-clock signals


Check to ensure that an RS latch is not created by using primitive cells


Cheks to avoid combinational loops containing latches structure/STARC02-2.4.1.4




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 type as index

synthesis/ArrayEnumIndex

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 not static and not a power of 2

synthesis/ExponOp

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 expression

synthesis/MultipleWait

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 tools) or initial statements

synthesis/SigVarInit, synthesis/W430

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 clauses

synthesis/W551

To check for while statements used in subprograms synthesis/WhileInSubProg



Documents

SpyGlass®-GuideWare User Guide - linkedic.cn · SpyGlass®-GuideWare User Guide Early Design Closure Introducing SpyGlass Atrenta® SpyGlass® is a powerful and extendible tool for